[Gc] About "Disclaim" patch for BDWGC
hans.boehm at hp.com
Mon Aug 8 21:44:27 PDT 2011
Could someone extract the patch and either post it, or mail it to me.
In general, this makes sense to me, though it seems to add more complexity to the finalization support, which has already accumulated a bunch of bells and whistles over the years.
I agree with Petter that disclaim call-backs on objects already in a freelist are problematic. I'm also a bit concerned about the treatment of objects that were already dead in the last cycle, but are in a low demand block that didn't get reclaimed. It would be nice to make sure that all of this works cleanly before putting it in the main branch.
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Saturday, August 06, 2011 10:30 AM
> To: Petter Urkedal; Boehm, Hans
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] About "Disclaim" patch for BDWGC
> Hi Petter and Hans,
> Hans -
> Do you have any objection against this feature in the HEAD branch (the
> feature is off by default on build)?
> Petter -
> It looks like Hans is on a vocation these days. And, I'm going too in 2
> weeks... So, let's wait...
> Yes, it would be nice if prepare clean patch for the HEAD.
> Here's another question (since you mentioned auto-generated files, I'd
> like to hear you option):
> As might notice, I've moved libatomic_ops out of bdwgc (as the former
> has no dependencies to libgc and has standalone usage). What do you
> think would it be ok for bdwgc clients on Unix hosts (or we'd better
> release still continue to release bdwgc with libatomic_ops included)?
> How the build scripts in bdwgc should be adjusted?
> Thanks. Regards.
> 06 09 2011, 16:48 Petter Urkedal <urkedal at nbi.dk>:
> > On 2011-08-05, Ivan Maidanski wrote:
> > > Hi Petter,
> > >
> > > I've found your patches for GC in culibs adding "alternative
> finalization interface" (ENABLE_DISCLAIM).
> > >
> > > 1. Do you have a repo containing your branch? (I'd like to import
> it as a separate branch in bdwgc repo)
> > Hi Ivan,
> > Yes,
> > https://git.eideticdew.org/cgit/~urkedal/bdwgc/, but as I noticed
> > your github repo, I've rebased my patches an that:
> > https://github.com/paurkedal/bdwgc
> > The changes are contained in the range clean..dispatch, excluding
> > generated files (master..clean). I can prepare something you can
> > but the generated files will have a few Gentoo-related autotools
> > additions.
> > > 2. Have you talked to Hans about merging it with the head BDWGC
> > We discussed a patch with similar functionality, but before we
> > (no pun) it, I was looking at the current approach, which is more
> > efficient.
> > I would like to see this added. I'm not sure whether my explanation
> > (
> > https://www.eideticdew.org/culibs/bdwgc-rn.html) is clear, so please
> > ask. To summarise, it improves speed and memory overhead for
> > finalization, but as it requires using a dedicated object kind, it
> > completely replace the current API. It can also be used to create
> > maps more directly.
> > The main change is in reclaim.c, with handing of the callback on
> > finalizable objects. Note that the callback may indicate that the
> > object should be kept. This is essential for weak data-structures,
> > since a lookup which occurred after the last collection may have
> > new references to the object.
> > There is another change in mark.c to allow objects in an object kind
> > be treated as roots, to protect pointers which may be referenced by
> > finalizer. This is usually not needed by weak data-structures.
> > There is one thing I'm not completely satisfied with: The disclaim
> > call-back is applied to all objects of a block, some which may
> > have been finalized and put in a free list. The call-back thus needs
> > way to distinguish the two cases. I utilize the fact that free-links
> > are aligned pointers, which puts a constraint on the first word of
> > objects. There may be a way to avoid this.
> > P.S. Thanks for CCing me in the initial post, I'm only reading the
> > occasionally unless I'm following a thread.
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
More information about the Gc