Re[4]: [Gc] About "Disclaim" patch for BDWGC

Ivan Maidanski ivmai at
Sat Sep 10 00:53:51 PDT 2011

Hi Petter,

I think it would be ok if you send me a merge request for this (to master branch).

I've recently changed GC version in master to 7.3alpha1 i.e. the branch serves as the next release development branch, while "release" is now set to 7.2alpha7 and only bug fixes will be applied to it until final GC release. (Same for libatomic_ops).


09 08 2011, 11:14 Petter Urkedal <urkedal at>:
> On 2011-08-09, Boehm, Hans wrote:
> > Could someone extract the patch and either post it, or mail it to me.
> I already published it here:
> It needs autoreconf after applying.
> > 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 should add that I think if the disclaim call-backs as a low-level
> mechanism, on which to develop the real useful things, but still this
> bothers me.  I'm open to suggestions.
> I just tough of one possibility, but I'll have to look at the source
> code later today:  The linear scanning of blocks in reclaim.c should
> construct free-lists of the same structure.  That is, the last object
> should point to the previous free object in the same block.  If that
> could be reversed, we could maintain the pointer to the next free
> object:
>     for obj in block
> 	if next_free_ptr == obj
> 	    next_free_ptr = ((void **)obj)[0]
> 	else
> 	    check and reclaim
> Though we'd need to determine the first pointer.
> > 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.
> Are you worried about the time it may take before (and if) the reclaim
> call-back is called?  I haven't worried much about it since I only used
> it for tidying associated memory which amounts to a constant factor of
> the non-reclaimed memory.
> However, I think it might be nice to run the scanning of these blocks in
> a separate thread.
> I've been using the patch for myself for several years, but mainly for
> hash-consing in a single library, so my code may have limited coverage.
> _______________________________________________
> Gc mailing list
> Gc at

More information about the Gc mailing list