[Gc] Re: Combining collected and uncollected heaps

Jan Wielemaker J.Wielemaker at vu.nl
Thu Jan 5 00:18:16 PST 2012

Hi Bruce,

That is almost what I've done.  I just steal bits of the mark-byte
instead of having a separate array.  I guess there are tradeoffs here
that are better answered by the implementation experts.  My trick makes
marking and checking marks slightly more expensive, but according to
valgrind this is peanuts.

It seems that what needs to be done first is convince the community
that there are good use-cases for this.  Funny is that you have been
claiming I was doing the wrong thing in the first place (which I
appreciate; it is always better to look at the alternatives one
more time).

Do you recall why you did this?

	Cheers --- Jan

On 01/05/2012 01:14 AM, Bruce Hoult wrote:
> This reply is out of order, but I just recalled that I solved a
> similar problem some years ago.
> The high performance way to make some objects temporarily (for some
> possibly large value of temporary) "atomic" and "uncollectable" is to
> modify GC_clear_marks (GC_clear_hdr_marks, really) to set the mark for
> such objects instead of clearing it. When tracing finds the mark bet
> set then it won't trace it (it thinks it's already been done). And the
> object obviously won't be collected as it's been marked.
> This can be done by keeping a parallel array of "initial mark bits",
> and changing the BZERO to a BCOPY.
> An additional optimization (making this virtually cost-free with
> modern caches) is to make any page where all the objects are "normal"
> share the same copy of an "all mark bits initially cleared" array.
> On Thu, Jan 5, 2012 at 3:58 AM, Jan Wielemaker<J.Wielemaker at vu.nl>  wrote:
>> On 01/04/2012 03:31 PM, Hans Aberg wrote:
>>>>> I also think that my problem is not unique. I shouldn't be the
>>>>> only one who hits scalability limits of BoehmGC and for which a
>>>>> similar trick is a sensible alternative.
>>> Your description looked very specific, though it might be more
>>> general. My guess is that the developers of the GC will only want to
>>> maintain things in the latter category.
>> I understand that. As lead developer of SWI-Prolog I often have to make
>> such trade-offs.
>> I think the general case boils down to this:
>> My modified GC can support applications with a huge heap that wish to
>> use GC for safe reclamation of lock-free objects. Such applications are
>> becoming increasingly important. Using GC is much simpler than using
>> e.g., Hazard Pointers, in particular if you need it anyway in the
>> application.
>>         Regards --- Jan
>> _______________________________________________
>> Gc mailing list
>> Gc at linux.hpl.hp.com
>> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.

More information about the Gc mailing list