lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 control GC
manually, as far as I understand, by doing

collectgarbage("stop ")

	collectgarbage("step", application_GC_step)
if(app_thinks_it_is_a_good_time_and_place_to_GC ())
	collectgarbage("step", application_GC_step)

Plugging a custom application allocator allows gathering Lua allocation statistics on the application side as well. So, looking back at this, it feels like application can already do whatever it needs with respect to
GC as it is.


-----Original Message-----
[] 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.