lua-users home
lua-l archive

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


On 3/16/06, SevenThunders <mattcbro@earthlink.net> wrote:

A conservative garbage collector like the Boehm collector has to do it's tree
walk thing to flag all buffers that have references somewhere in memory.
That is the memory it can 'see'.  So as it's processing memory it has to
check to see if a particular word is in fact a pointer to perhaps some other
buffer.  How does it do this?  The only way it can check this is by seeing
if a particular word is in it's current list of allocated buffers. In theory
one could do this, at least in windows, by calling the Windows API function
IsBadReadPtr, however this wouldn't be very portable.  I don't even know if
linux has an equivalent.

Thus any buffer allocated by malloc is not in the Boehm gc's list, since it
didn't call GC_MALLOC().  It can't tree walk those regular malloc  buffers.
Currently the default allocator for LUA is whatever realloc and free gives
you on your system.  The Boehm garbage collector will be 'blind' to these
buffers and anything put in them would be found to be unreachable.  The
solution, as suggested earlier, is to overload realloc and free with
GC_REALLOC() and GC_FREE().

  I'm not sure what kind of performance hit this would give.  One could I
suppose actually replace free with a no-op function instead of GC_FREE.  The
result would be that both LUA and C would be using the Boehm garbage
collector.  This would allow Lua objects to persist in C if so desired.
Perhaps this would be considered dangerous, I don't know.
--
View this message in context: http://www.nabble.com/Using-Lua-and-C-with-a-Garbage-Collector-t1281804.html#a3444624
Sent from the Lua - General forum at Nabble.com.


OK, we're missing each other here and I grow weary.  ;)

The Lua user data _would_ in fact have a pointer to memory allocated with GC_MALLOC so your C garbage would be able to see it just fine.  That's the reference I was talking about.

--
// Chris