www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 679] New: Spec needs allowances for copying garbage collection

reply d-bugmail puremagic.com writes:
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.


--
Dec 12 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=679






 A possibility is to specify that the following will implicitly pin 
 something in the GC heap:


Add to this list:

- Storing a pointer to it in an allocated block referenced by a void* or
void[].

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 25 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=679


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED



15:49:37 PST ---
http://www.dsource.org/projects/phobos/changeset/2138

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 08 2010