[Gc] Problems with GC_size_map

Boehm, Hans hans.boehm at hp.com
Mon Feb 1 20:35:46 PST 2010


From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Juan Jose Garcia-Ripoll
Sent: Monday, February 01, 2010 7:05 AM
To: gc at napali.hpl.hp.com
Subject: [Gc] Problems with GC_size_map

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 (https://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 think that should be OK, particularly for fixed size datatypes.  For variable-size datatypes, you may end up with two many different kinds of heap blocks, since objects are segregated by both kind and size.

* 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?

There are examples of mark procedures in gcj's libjava runtime. The GC_malloc_explicitly_typed implementation also does this internally in some cases, as I recall.

* 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?

You're using GC_MALLOC_WORDS in gc_inline.h?  The idea here was that you supply a freelist array that is used for fast inline allocation of small objects.  The fast path shouldn't access GC_arrays.  The slow path uses function calls into the collector.  This code is also used by thread-local-allocation, but otherwise may not be tremendously well tested.

The problem you describe has been encountered before.  The current gc_inline.h was an attempt to work around it.  It was added around 7.0, but had more bugs early on.



Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20100202/824d9305/attachment.htm

More information about the Gc mailing list