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

[d-bugmail at puremagic.com]

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 at digitalmars.com
        ReportedBy: smjg at 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.


--