@pinned classes

[Justin Spahr-Summers]

On Wed, 31 Mar 2010 22:59:08 -0400, bearophile 
<bearophileHUGS at lycos.com> 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