@pinned classes

[Justin Johansson]

Sounds like a revisitation of Microsoft extensions to C++ a number of years
(maybe a decade) ago.  I distinctly recall a short-lived new version of Visual C++
christening a declspec like "__pinned" to C++ pointers and/or class declarations
in respect of their up and coming garbage-collected platform.  It was not called
.Net then but from memory, this particular version of Visual C++ was the precursor
to C# / .Net and then the next version of VC++ promptly forgot about "__pinned".

A similar MS C++ declspec, "__based", happened a decade or two before "__pinned"
in relation to a pointer being just an offset into a 64KB block in the old 80286 segment/offset
memory model.

If history were to repeat itself, perhaps D will evolve to D#.

egards,
Justin Johansson



bearophile 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