Re: Forcing a GC collection from within the allocator?

["Peter Cawley" <lua@...>]

The reason for the custom allocator was to speed things up, and firing
off the GC all the time costs time.

A rough idea of what I'm doing, for lots (i.e. 100s to 1000s) of Lua files:
read them from disk and load them into Lua using lua_load
extract a Proto* to the loaded file
scan through the instruction array looking for a particular sequence
do something with the constant which the sequence referenced
throw the loaded file away (lua_pop) and move onto the next

One of the slow things in that inner loop is memory (de)allocation.
Specifically, Lua is allocating a bunch of stuff when loading a file,
keeping it for a short while, then throwing it away, then allocating a
similar amount for the next file, and so on. The custom allocator is
designed to be very fast at (re)allocating and freeing blocks of
memory upto 4kb in size (for my input, Lua rarely requests blocks over
4kb)

As I'm trying to remove as much as possible from the inner loop,
adding a GC collection is not something I'd like to do in this
situation

2008/8/25 Mark Hamburg <mark@grubmah.com>:
> Note that for non-Lua allocations you can frequently fire off a GC if you
> run out of space. Be careful if you are running multi-threaded. You don't
> want a background thread starting a GC while the foreground thread is
> running regular Lua logic. You may even want to run the GC a few times to
> flush through finalization logic.
>
> Mark
>
>