[Gc] Re: Combining collected and uncollected heaps
J.Wielemaker at vu.nl
Wed Jan 4 06:23:18 PST 2012
On 01/04/2012 02:59 PM, Hans Aberg 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
> 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.
Regards --- Jan
More information about the Gc