Array Slices and Interior Pointers

Alex Rønne Petersen alex at lycus.org
Wed Dec 12 06:55:15 PST 2012


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
alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list