[Gc] Re: Combining collected and uncollected heaps

Hans Aberg haberg-1 at telia.com
Wed Jan 4 06:31:30 PST 2012


On 4 Jan 2012, at 15:23, Jan Wielemaker wrote:

>>>> The objects on the heap that is not collected by the GC should
>>>> initially be marked uncollected. Only pointers to the GC heap
>>>> should be traced.
>>> 
>>> Not sure I get this. What does `marked uncollected' mean here. In
>>> my view, objects can be under GC, but be marked `permanently' (or
>>> `unmanaged'). Then I distinguish three possibilities for a block:
>>> (1) all objects are managed: do the usual stuff, (2) all objects in
>>> the block are marked unmanaged: simply skip the block for all GC
>>> phases and (3) some blocks are managed, some not. Now,
>>> clear_hdr_marks() only clears the marks on the objects that are
>>> managed. As unmanaged objects are considered marked, they will
>>> never be placed on the mark agenda, and thus not be scanned for
>>> pointers.
>> 
>> What seems lacking in the GC interface is the ability to dynamically
>> change the status.
> 
> Yes, but my experiments show it isn't hard to add. About 100 lines of
> modifications; not 100% complete, but probably close. The performance
> impact of the modifications seems neglectable.
> 
>>>> When an object expires on the uncollected heap, it should be
>>>> marked for for collection by the GC. It will then stay alive
>>>> until the GC finds it is dead.
>>> 
>>> I think that is exactly what I propose.  What is your `general
>>> problem' with this?
>> 
>> My impressions is that you want rather intrusively write your own GC
>> collector, tailored to your specific implementation. I'm not sure if
>> my description would fit your ideas.
> 
> Well, I've written two garbage collectors in my life, and that was
> enough :-) One of them, the SWI-Prolog atom garbage collector, doing
> things somewhat comparable to BoehmGC, but in a more isolated
> context. The other one is the SWI-Prolog stack GC. That is indeed a task
> for which a dedicated collector is appropriate.
> 
> I've learned some tricks digging in the BoehmGC code. I now need
> something much closer to BoehmGC than my code. BoehmGC has solved
> portability issues I had not yet solved. My short term plan is to use
> them together and my long term plan is to drop my own. Reusing BoehmGC
> definitely saves a lot of work. Using a custom version would be a pity
> (although git makes such enterprises a lot more manageable).
> 
> 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.

Hans





More information about the Gc mailing list