[Gc] Problems with GC_size_map

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Feb 1 07:05:25 PST 2010


Hi everybody,

I am back with a couple of questions, once more related to the interplay of
the garbage collector and the ECL implementation of Common Lisp (
http://ecls.sf.net)

I have discovered that the garbage collector provides a simple way to
improve the precission of the the mark phase, using bitmap descriptors. I
also peeked into typd_mlc.c and learnt how to create new object types and
even to inline allocation. My questions are thus related to both.

* ECL uses about 20 datatypes. Currently what I do is to rely on
GC_malloc_explicitely_typed() to store a single-word bitmap which is enough
for all types, but I would like to get rid of that overhead. Would creating
about 14 different garbage collector kinds be stupid?

* I also played with custom marking procedures to avoid the bitmap, but I
did not manage to get it working. Somehow the mark code got stuck. I also
read the documentation and says it is not recommended to use custom marking
because code is slow due to lack of inlining. Is this true, or are there
simple examples showing how to properly use this technique?

* I tried inlining the object allocation to use the fact that all objects
are small. However, this does not work: I have serious problems because in
the private headers (this is 7.1) the content of the structure GC_arrays
depends on the compiler flags. More precisely, GC_size_table has a different
address in my compiled code and in the GC library. Now, sorry if I sound
rude, but this is foolish to do specially when the users of the library do
not have access to those compiler flags -- they are not stored in any
header, just used when building the garbage collector --. Is there a
workaround? Does 7.2a* solve this problem?

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20100201/a8b5933f/attachment.htm


More information about the Gc mailing list