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

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

And some new results (attached). A few changes in the log file:

- the "fixed" allocator is out for good.
- there is now a column called "Peak", which is the peak memory
requested by Lua during the script's lifetime (it is similar to
Robert's info->peak_memused field). The "Min. size" column is still
the _actual_ memory needed by the allocator to run the test. If you
were on an embedded system without any allocator at all (and without
MMU) you'd need at least "Min.size" _physical_ memory to give to the
allocator in order to run the script, even if Lua itself wouldn't
report more than "Peak" bytes of memory requested. The difference
between the two values could be considered a measure of the allocator
overhead (people would be probably be happier to see percentages here,
I'll add this soon).
- there is now a memory limiting mode that limits the memory used to a
given value, and this value is specified at the end of the "TEST ID: "
line. This mode finds the minimum amount of _physical_ memory (the
"Min.size" column) you'd actually need to give to your allocator in
order to run the script with the specified memory limit (again,
allocator overhead).
- a new encoding in the "Lim" column:

"none" - no memory limiting
"cl" - complete garbage collection only when the memory limit (from
the "TEST ID:" line) is reached
"cf" - complete garbage collection only when an allocation fails
"ca" - complete garbage collection before any allocation
"sl" - step garbage collection only when the memory limit (from the
"TEST ID:" line) is reached
"sf" - step garbage collection only when an allocation fails
"sa" - step garbage collection before any allocation

The "s" modes (sl, sf, sa) seem to be a good compromise between speed
and memory consumption (when compared to the "none" mode and the "c"
modes (cl, cf, ca)). The "sa" mode could be a good candidate for real
life applications.

To Robert: I tried to run "factorial.lua" and "bisect.lua" with a
memory limit of 20000 bytes (using the default system allocator this
time (malloc from Linux), so this is not an allocator issue) and it
seems that Lua enters an infinite loop somehow. I didn't have the time
to investigate this.

On Thu, May 8, 2008 at 4:49 AM, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
> Updated patch attached 'emergency_gc-5.1.3.patch'.  I fixed a few bug with
>  doing a step collection from the allocator instead of a full collection.
>
>  Also the attached 'lua_memlimit.c' program has support for full collection or
>  step collection from the allocator and a '-m' option for settings the
>  memlimit from the commandline instead of the hard coded 64k limit.  The
>  default is still 64k.  The step collection mode will keep calling lua_gc()
>  until the required amount of free space has been freed or until the collector
>  finishes two full collection cycles.

Attachment: log.out
Description: Binary data