[Gc] Re: Combining collected and uncollected heaps
bruce at hoult.org
Wed Jan 4 16:14:04 PST 2012
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
> Regards --- Jan
> Gc mailing list
> Gc at linux.hpl.hp.com
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
More information about the Gc