On Wed, 31 Mar 2010 22:59:08 -0400, bearophile <[email protected]> wrote: > > Thinking more about some of the things I've recently written to Mike S, I > think the situation of the D GC can be improved not teaching the D type > system how to tell apart three types of pointers, but introducing the @pinned > for classes: > > @pinned class Foo {} > > Unpinned memory can be moved, allowing a generational moving GC, that's > efficient. > > All objects instantiated from a unpinned class are unpinned. This is a little > limiting (you can think of allowing both pinned and unpinned instances) but > this keeps the situation simpler for the compiler and the programmer. > > With unpinned classed Java/C# programmers can program in D in a style similar > to the one they are used too in their languages. This is good. > > Classes are unpinned on default (the opposite of the current situation) to > maximize the amount of unpinned objects. > > The @pinned attribute can't be used with structs and enums, they are always > pinned becasue Java programmers don't use them, they are usually used for > performance in a lower level way, and because they don't have a virtual table > pointer that the GC can use, etc. > > Normal unpinned classes can't contain pointers to their fields or to unpinned > memory, in a transitive way. They can contain pointers to pinned memory. > > In system (unsafe) modules you can of course cast a unpinned class referent > to a pointer, but this is nearly, because the GC can move the class in memory > in any moment. It can be useful for a short time if you disable the GC. > > Pinned classes act as now, they can contain pointers to their fields too. > > The GC can move around unpinned objects and must keep in place the pineed > ones, the GC has to modify the references to unpinned classes (references on > the stack, inside other objects, etc), to update them to their new positions. > > Probably enums can't contain references to unpinned memory, to keep things > tidy. > > This can be a compile error, prbably Bar too has to be unpinned: > class Foo {} > @pinned class Bar: Foo {} > > I'm sure I'm forgetting several things :-) > > Bye, > bearophile
I think the D2 spec puts restrictions on what you can do with GC- allocated pointers (can't convert them to integers, can't perform arithmetic on them outside of their bounds, etc.), and I think they're restrictive enough that a copying garbage collector could work with no changes to compliant code. - Justin Spahr-Summers
