digitalmars.D.bugs - [Issue 679] New: Spec needs allowances for copying garbage collection
- d-bugmail puremagic.com (54/54) Dec 12 2006 http://d.puremagic.com/issues/show_bug.cgi?id=679
- d-bugmail puremagic.com (9/11) Oct 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=679
- d-bugmail puremagic.com (12/12) Nov 08 2010 http://d.puremagic.com/issues/show_bug.cgi?id=679
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
http://d.puremagic.com/issues/show_bug.cgi?id=679A 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
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