[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: GC tuning idea
- From: Mark Hamburg <mark@...>
- Date: Sun, 10 Aug 2008 10:16:46 -0700
The differences relative to my proposal is:
1. I don't want to stop the GC entirely. I just want to stop the
atomic step from running. Incremental work would be viewed as safe
(though of course a really big table could cause issues there as well).
2. I would allow the callback to decide that memory load was high
enough that we should let the atomic step proceed even with the risk
that it will cause a noticeable pause since we're probably at the
point where we're going to be taking paging pauses.
On Aug 8, 2008, at 11:54 AM, Bilyk, Alex wrote:
I was thinking this is a great idea. However, one can already
manually, as far as I understand, by doing
Plugging a custom application allocator allows gathering Lua
statistics on the application side as well. So, looking back at
feels like application can already do whatever it needs with respect
GC as it is.
[mailto:firstname.lastname@example.org] On Behalf Of Mark Hamburg
Sent: Thursday, August 07, 2008 11:32 PM
To: Lua list
Subject: GC tuning idea
Just a quick thought...
It might be interesting to provide a hook in the GC process so that
clients could postpone the atomic phase for the GC. One would probably
need to pass in some statistics regarding memory usage so that the
client could decide whether the memory usage outweighed the risk of
taking a GC pause.