On 11-12-2012 22:38, Rainer Schuetze wrote:


On 11.12.2012 22:08, Alex Rønne Petersen wrote:
On 11-12-2012 21:24, Rainer Schuetze wrote:

This stores the type info with the reference, not with the memory block,
but it does not make a big difference. (Actually it does: if the
reference only is a reference a base class of the actual instance, type
info is lost.)

This got me thinking a bit.

In the current on-going precise GC work, what is type info actually used
for? It seems to me that given the current GC semantics, the only thing
it's useful for is figuring out what parts of memory do /not/ contain
pointers, and nothing else.

Yes, it is only interested in pointers. The current implementation
creates a bitmap from type introspection at compile time, where each bit
specifies whether the respective word of an instance is a pointer. When
a memory block is allocated, the bitmap is copied (with some
complications) from the TypeInfo object into a memory bitmap that is
used for GC scanning later. This seems slightly inefficient with respect
to memory usage, but it allows to scan faster, as the complications have
to be dealt with only once, not every time when scanning. It also allows
changing the scanning information of only a part later e.g. to integrate
emplace!T with precise scanning (though this isn't implemented yet).

OK, makes sense, and point taken. The D GC would not benefit from getting rid of interior pointers in any significant way. The only advantage would then be for VMs like the CLI.



I understand that the CLI forbids interior pointers, but that seems an
implementation detail of its GC.

It's standardized: Ecma 335, I.8.2.1.1.

I still read that restriction as driven by an implementation detail
("For performance reasons..."), not by some design necessity.

Oh, sure, all I'm saying is that since it is in the standard (and both MS.NET and Mono require it), we have to deal with it one way or another.



And it's something we need to deal with if we care about D on the CLI.



--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Reply via email to