Why are void[] contents marked as having pointers?
Vladimir Panteleev
thecybershadow at gmail.com
Tue Jun 2 04:29:54 PDT 2009
On Tue, 02 Jun 2009 01:01:00 +0300, Christopher Wright <dhasenan at gmail.com> wrote:
> Vladimir Panteleev wrote:
>> On Mon, 01 Jun 2009 14:10:57 +0300, Christopher Wright
>> <dhasenan at gmail.com> wrote:
>>
>>> Vladimir Panteleev wrote:
>>>> On Mon, 01 Jun 2009 05:28:39 +0300, Christopher Wright
>>>> <dhasenan at gmail.com> wrote:
>>>>
>>>>> Vladimir Panteleev wrote:
>>>>>> std.boxer is actually a valid counter-example for my post.
>>>>>> The specific fix is simple: replace the void[] with void*[].
>>>>>> The generic "fix" is just to add a line to
>>>>>> http://www.digitalmars.com/d/garbage.html adding that hiding your
>>>>>> only reference in a void[] results in undefined behavior. I don't
>>>>>> think this should be an inconvenience to any projects?
>>>>> What do you use for "may contain unaligned pointers"?
>>>> Sorry, what do you mean? I don't understand why such a type is
>>>> needed? Implementing support for scanning memory ranges for
>>>> unaligned pointers will slow down the GC even more.
>>> Because you can have a struct with align(1) that contains pointers.
>>> Then these pointers can be unaligned. Then an array of those structs
>>> cast to a void*[] would contain pointers, but as an optimization, the
>>> GC would consider the pointers in this array aligned because you tell
>>> it they are.
>> The GC will not "see" unaligned pointers, regardless if they're in a
>> struct or void[] array. The GC doesn't know the type of the data it's
>> scanning - it just knows if it might contain pointers or it definitely
>> doesn't contain pointers.
>
> Okay, so currently the GC doesn't do anything interesting with its type
> information. You're suggesting that that be enforced and codified.
I wasn't suggesting any GC modifications, I was just suggesting that void[]'s TypeInfo "has pointers" flag be set to false.
--
Best regards,
Vladimir mailto:thecybershadow at gmail.com
More information about the Digitalmars-d
mailing list