[Gc] About "Disclaim" patch for BDWGC
urkedal at nbi.dk
Tue Aug 9 00:03:32 PDT 2011
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
for obj in block
if next_free_ptr == obj
next_free_ptr = ((void **)obj)
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.
More information about the Gc