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
