It certainly seems that all the choices are bad.
The "obvious" choice is to simply say that WeakReference makes no
sense, in that it sidesteps the hard semantics questions. My fear is
that this will cause new failures, where existing libraries that toss
objects into WHMs to cache derived resu
In the Dec 2021 update to State of Valhalla, part 2: The language
model, the section on "Identity-sensitive operations" states this
about weak references:
> Weak references to value objects that contain no references to identity
> objects should never be
> cleared; weak references to value object
On 12 Jan 2022, at 8:45, fo...@univ-mlv.fr wrote:
>> From: "Brian Goetz"
>> To: "Remi Forax"
>> Cc: "valhalla-spec-experts"
>> Sent: Wednesday, January 12, 2022 2:30:00 PM
>> Subject: Re: [External] : Re: VM model and aconst_init
>
>> The operand of C_Class is a weird beast. It can be an intern
On 12 Jan 2022, at 5:14, fo...@univ-mlv.fr wrote:
Ok, but in that case how the verifiers know if aconst_init generate a
Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and
not a descriptor as parameter.
In the terms of my previous message, the `CONSTANT_Class` item
in the CP
I think (based on our most recent conversations)
that `aconst_init` can return a Q-type for B3 types
and an L-type for B2 types. And likewise for the input
and output of `withfield`.
The net result is that both bytecodes need to be
permissive about L and Q types, because B2 and B3
translation st
