lua-users home
lua-l archive

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

On Win32 / Lua 5.1.3 the loop test published on this thread shows some interesting behavior.

With gcpause set to 200 the memory growth unbounded.
With gcpause set to 199 the unbound growth is gone and the memory fluctuates around 4-6MB. As the number approaches 190 the behavior starts to match linux version with sizeof(TValue) aligned to 12 bytes and becomes relatively insensitive to the value change.

So the impact of the gcpause on the GC heuristics is highly non-linear. Going from 200-199 make huge difference while changes bellow 190 make almost no difference at all.

The alignment affects behavior of luaC_step - for 16 byte alignment the setthreshold gets called while the amount of memory still used is pretty close to gctotal - this effectively doubles the memory threshold for next collection. The do {} while(lim>0) loop is mixing together real memory released with predefined constant cost for certain GC operations - looks like these numbers are thrown out of balance when the sizeof(TValue) is changed.

This can have pretty high impact on various non-double number lua distribution - it is not very obvious that the the link between GC and sizeof(TValue) is as strong as it is.

Lowering the default limit is probably the easiest way to mitigate the issue - without significant changes to the GC code itself. Golden ratio (162) works pretty nicely. The alignment on Windows can be forced to match linux via #pragma pack() but that is non ANSI C and non-portable solution.