[Issue 679] New: Spec needs allowances for copying garbage collection

December 12, 2006
Posted by d-bugmail
Permalink
d-bugmail
Permalink
http://d.puremagic.com/issues/show_bug.cgi?id=679

           Summary: Spec needs allowances for copying garbage collection
           Product: D
           Version: 0.177
          Platform: All
               URL: http://www.digitalmars.com/d/garbage.html
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: www.digitalmars.com
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: smjg@iname.com
OtherBugsDependingO 677
             nThis:


The specification is to the effect that a D implementation may use a garbage collector that moves objects around in memory.  However, there are issues that still need to be addressed before this'll work.

http://www.digitalmars.com/d/archives/26273.html http://www.digitalmars.com/d/archives/digitalmars/D/learn/3492.html

To summarise, these issues are:
(a) unions
(b) pointers into the GC heap held by foreign code
(c) crocky APIs, which may sometimes use pointer types to hold non-pointer data
(e.g. in the Windows API, handles and numeric resource IDs) or vice versa (I
think there are one or two instances of this in the Windows API)

Moreover, gc.html indicates that, for (b), it is sufficient to "Maintain a root to the object in an area the collector does scan for roots".  (At least they _appear_ to be "or" bullet points, considering that it can't be necessary to do all three, and sometimes doing all three isn't even possible.)  However, this won't work if the GC may still move the object in memory, as it isn't going to update the pointer held by the foreign code.

Several people have proposed a method of pinning as a way to deal with this. Walter also indicated (see the second linked-to post) that there would be implicit pinning in certain circumstances.  However, none of this is documented yet.  It needs to be.

A possibility is to specify that the following will implicitly pin something in
the GC heap:
- storing a pointer to it in a union
- storing a pointer to it on the stack
- making the object's memory address a root using using std.gc.addRoot or
std.gc.addRange
- having a pointer to it in any foreign memory that the GC happens to stumble
upon

The option to "Maintain a root to the object in an area the collector does scan for roots" would have to be removed.  In order for it to be pinned so that a copying GC doesn't invalidate the pointer held by the foreign code, it's necessary (in the general case) to addRoot the pointer itself or use one of the other pinning mechanisms.  Maintaining a root to the foreign memory where the pointer is held may not be an option - even if the foreign API documents the conditions under which it keeps the pointer, it need not release to the outside world anything about _where_ it keeps it.


--
Forums
