typed objects and value types

[Dmitry Lomov]

On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller <erights at google.com> wrote:

> You can't recreate a given fat pointer out of thin air. You need at least
> the same backing buffer, or something (e.g., another fat pointer) which
> retains the same backing buffer.
>
> The backing buffer has generative identity, so the WeakMap should hold on
> to the backing buffer weakly[1], but it should use the entire fat pointer
> to compare for key equality.
>
> [1] In the normal ephemeron sense of "weakly".
>
>
> Note that I am only pointing out that all this is possible, and is the
> least surprising extension of the semantics of the various objects
> involved. If implementors say this isn't worth it and would rather just
> reject typed objects as keys, I'm ok with that, as long as we all agree to
> reject.
>

Point taken, yes, there are conditions that ensure that this typed object
can never be recreated, but I am not sure this will in practice be the
least surprising extension (from the practical point of view of "why my
WeakMap still holds on to these values? Oh it is because there is this one
typed object that shares the buffer with all these other objects"). From
practical standpoint, it feels like once we have made GC observable
(through WeakMaps), we just can't have objects (weak map keys) with
non-generative identity.

So as an implementor, I feel that we should reject typed objects as weak
map keys.

Dmitry


>
>
>
> On Wed, Apr 2, 2014 at 12:25 PM, Dmitry Lomov <dslomov at chromium.org>wrote:
>
>>
>>
>>
>> On Wed, Apr 2, 2014 at 9:11 PM, Dmitry Lomov <dslomov at chromium.org>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller <erights at google.com>wrote:
>>>
>>>>
>>>>
>>>> We could specify that WeakMaps can use typed objects as keys. The
>>>> current discussion in your article confuses semantics with implementation
>>>> when it speaks of typed objects comparing structurally. Typed objects have
>>>> identity, characterized by the four-tuple you explain. Just as all the bits
>>>> of a thin pointer are significant when comparing two thin pointers to see
>>>> if they point at the same semantic object identity, so are all the bits in
>>>> your fat pointer significant. Don't get confused by the bits in the pointer
>>>> to the fat pointer, when the fat pointer happens to be boxed.
>>>>
>>>
>>> It is unclear to me how WeakMaps can ever use typed objects as keys,
>>> since typed objects do not have their unique identity. Or rather, the only
>>> possible semantics I see is "hold to the value forever". So for example:
>>>
>>>    w = new WeakMap();
>>>    w[Point(buffer, 0)] = "abc"; // 1
>>>
>>>    w[Point(buffer,0)] = ? // 2
>>>
>>> I believe that in line 2, result should always be "abc" (since
>>> Point(buffer, 0) === Point(buffer, 0)).
>>> This is something we can spec, but it is probably not behavior we want.
>>>
>>
>> (to put it another way, for "normal" objects/thin pointers, the user
>> cannot construct the new identical thin pointer out of thin air, therefore
>> garbage collection is possible; whereas the typed objects/fat pointers are
>> user-reconstructable at any point of time - so garbage collection is
>> impossible).
>>
>>>
>>> Dmitry
>>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140402/71d940c2/attachment-0001.html>