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

Ivan Maidanski ivmai at mail.ru
Sat Aug 6 10:30:25 PDT 2011


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, 
> http://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 pull,
>  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 branch?
>  
>  We discussed a patch with similar functionality, but before we finalized
>  (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
>  (
> http://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 can't
>  completely replace the current API. It can also be used to create weak
>  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 created
>  new references to the object.
>  
>  There is another change in mark.c to allow objects in an object kind to
>  be treated as roots, to protect pointers which may be referenced by the
>  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 already
>  have been finalized and put in a free list. The call-back thus needs a
>  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 live
>  objects. There may be a way to avoid this.
>  
>  P.S. Thanks for CCing me in the initial post, I'm only reading the list
>  occasionally unless I'm following a thread.
>  _______________________________________________
>  Gc mailing list
>  
> Gc at linux.hpl.hp.com
>  
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>   
>    



More information about the Gc mailing list