[gclist] Another question on Boehm-Demers-Weiser

[Hans Boehm]

On Jul 7,  2:49pm, Chris Smith wrote:
> Subject: [gclist] Another question on Boehm-Demers-Weiser
>
> Hi.
>
> While we're on the topic of discussing the Boehm-Demers-Weiser collector,
> I have been wondering about something.  I believe Hans Boehm said earlier
> that an earlier version of the collector was concurrent, but that he had
> decided to make it incremental to spread work around threads more fairly.
> Does one of the earlier versions still do this?  Would it be too much of a
> step backwards in performance terms if I grabbed and modified a concurrent
> version instead of the current version?  Are the changes that large, so
> that it would take a while to retrace the collector back to its concurrent
> state?
The collector used in the old Xerox PCR ran concurrently with the client.
I believe you can still get the code from ftp://parcftp.xerox.com/pub/pcr.
I don't think I would recommend it for this reason, though.
>
> The reason that I ask is that, because the first two generations of my VM
> are collected with stop-and-copy, I would end up performing all allocation
> in the Boehm collector when the entire process is suspended except for
> collection.  This means that if collection is performed incrementally on
> allocation, stop times would probably increase greatly with an incremental
> version over a concurrent one.
If you don't mind changing the source, it's probably fairly easy to perform
GC work mostly at other times.  There are only a few calls to
GC_collect_a_little_inner in the code.  Alternatively, you might try just
calling GC_collect_a_little from another thread.  The trick again is to give it
the right fraction of available processor time.
>
> Also, I'm assuming from my own intuition that it wouldn't be too difficult
> to modify the collector to do precise collection based on a reference
> bitmap in a per-object type descriptor (always reachable through the first
> word of an object),
Pretty much there already.  See gc_typed.h, and possibly the code that
implements it.

> and that it won't be much of a pain to modify the
> collector to stop scanning the root set (that's scanned at stop times,
> anyway, and you've gotta be at a gc point for it to be safely done.)
> Would either of these tasks spawn great difficulties that anyone can
> foresee?
The hooks to do that should also be there, though they're not well documented.
Modulo any oversights on my part, nothing except changing the incremental
collection scheme should require actually changing the collector code.



-- 
Hans-J. Boehm
boehm@sgi.com