[Pkg-gauche-devel] [Gauche-devel] Gauche and bundled GC - still needed?

Shiro Kawai shiro at lava.net
Sun Nov 4 23:58:40 UTC 2012


I gave some more thought on the issue.

First, I found a way to use libraries linked with standard libgc
in the extensions, even if Gauche is linked with
libgc-no-added-byte.so.  So your biggest concern about building
evrey libraries with two versions can be addressed.

However, while writing the detailed explanation of it,
I actually got an idea to use Gauche with standard GC.
It is tricky, but I think it doesn't violate Boehm GC's interface.
I'll try it out to see if it actually works.

Here's the outline of the idea, for whoever interested.

IIUC, the reason Boehm GC adds an extra byte at the end of every
object is to allow libgc to be used as a drop-in replacement of
standard malloc.  C standard says a pointer is valid even if
it points "right past the end" of the object.  I think it's
rather unusual to have such situation be an issue and it's
easily avoidable with programmer's care.  But not recognizing
such pointers can break some valid C programs when GC_malloc
is used in place of malloc.
That's why DONT_ADD_BYTE_AT_END isn't on by default.

With the default configuration, GC knows that the last word of
the object won't contain a traceable pointer because of this
added byte, so it won't trace the last word.  This is one of
the reasons the libgc and libgc-no-added-byte are incompatible
and can't be changed at runtime.

However, what if GC can distinguish objects that are allocated
with objects that has added byte, and that don't?

In fact, there's already a mechanism in Boehm GC that allows
us to add custom mark handler.

So, when I allocate Gauche objects, I can (1) ask the memory
with one less byte, so that GC gives me the desired size of
the memory, and (2) attach custom mark handler that does scan
the last word of the object.

--shiro



More information about the Pkg-gauche-devel mailing list