Re: PATCH: fixes bug with calling garbage collector from custom lua_Alloc

["Bogdan Marinescu" <bogdan.marinescu@...>]

I did a few tests concerning memory consumption of some Lua scripts
using different allocators and your patch. I finally managed to
integrate dlmalloc in my simulated test environment, so this is the
list of allocators used in the test:

dlmalloc: http://g.oswego.edu/dl/html/malloc.html (nothing was
modified, it was just a matter of finding the correct compiler
switches)
tlsf: http://tlsf.baisoku.org/ (modified SL_INDEX_COUNT_LOG2 from 5 to
4 to reduce the number of entries on the second level directory, and
also lowered FL_INDEX_MAX to 30 as I don't need to allocate too much
memory).
fixed: nothing is "fixed" about this allocator (it used to be, thus
the name); it's a very simple chained allocator (DOS-like) that does
best-fit and tries to coalesce free blocks as much as possible.

All of them work on a contigous memory buffer provided by the system's malloc().

I also write a script that finds the minimum memory needed to run a
script using the divide&conquer strategy: it starts with two extremes
(4k and 1M) and tries to constrain a script to a memory amount at the
middle of this interval, going to the lower half of the interval if
the script runs, or to the upper half if the script doesn't run. The
results are attached (it's a text file, but the text would probably
wrap in some e-mail clients, this is why I attached it). There are two
tests there:

- 'not patched': the original Lua 5.1.3
- 'patched': Lua 5.1.3 + "emergency_gc_fixes.patch" provided by Robert
(_without_ the latest 'allow_tmp_allocs' add-on, I won't be able to
run that till later this evening).

The semnification of the columns:

- 'Test': figure it out :)
- 'Allocator': the name of the allocator, as above
- 'Memlimit': 'none' if the allocator doesn't ever call lua_gc, 'a' if
the allocator always calls lua_gc before satisying a new request, 'f'
is the allocator calls lua_gc only if it was unable to satisfy a new
memory request
- 'Min.size': the minimum memory size that allowed the script to run properly
- 'Total time': execution time for the complete test (all the runs
from 4k to 1M), second-accurate
- 'Min. time': execution time for the test case that correspond with
the 'min.size' column, second-accurate

The tests with '----' in the last 3 columns failed to run properly
(most probably because of a segfault).

Test system:

- Intel Core2 Duo @ 3GHz, 4G of RAM
- Ubuntu64 (but everything is compiled with -m32, to simulate the real
requirements of a 32-bit system).

Some conclusions:

- dlmalloc and tlsf exhibit similar performance, dlmalloc seems to
perform better in a more intensive test ('life.lua' does a lot of
memory operations, many of which are reallocs). Right now I tend to
favour dlmalloc over tlsf, but this needs more testing.
- the memlimit 'a' mode can decrease the required memory space
dramatically, but it can also increase the execution time
dramatically. If you're memory constrained and the speed loss is less
important to you, this is definetely the way to go. But it still has
some bugs, as can be seen from the table ('factorial.lua' doesn't run
in 'a' mode). According to Robert, this happens because his patch
doesn't yet handle closures.
- the 'fixed' alocator works, but it's clearly worse than the others.
Plus, it can't take advantage of the 'f' memlimit mode because of its
internal structure (non-segregated). Plus it's very slow (as it uses
'best fit' on a chains of blocks and does coallescing whenever
possible). Of course, this whole thing needs more testing, but I'm
willing to bet that 'fixed' will loose the battle with both dlmalloc
and tlsf.
- the 'f' mode also improves the memory consumption, without having
much impact on the performance.
- overall, Robert's patch is a Good Thing if you need the 'a' mode.

I need to run this on more scripts, of course, but it's not that easy,
as the whole 'look for the least memory needed' process takes quite a
while to execute. Plus, I don't really want to go beyond the 1M high
memory limit, as I'm testing this for an embedded system and I
probably won't have much memory anyway. I will change this though if I
won't find any 'good' scripts to run in 1M of memory.
If I had to choose a combination right now I'd probably go with
dlmalloc and the 'f' mode. Fortunately, I don't have to choose right
now, I can do more testing :)

HTH,
Bogdan

PS. Anybody knows an easy way to get millisecond-accurate timers with
Lua under Linux?

Attachment: log.out
Description: Binary data