> From: "Brian Goetz"
> To: "daniel smith" , "John Rose"
>
> Cc: "Remi Forax" , "valhalla-spec-experts"
>
> Sent: Saturday, January 29, 2022 6:40:13 PM
> Subject: Re: VM model and aconst_init
> I think we're kind of
> From: "John Rose"
> To: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Sent: Thursday, January 27, 2022 10:00:20 PM
> Subject: Re: [External] : Re: VM model and aconst_init
> On 25 Jan 2022, at 2:50, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.
I think we're kind of stuck with a model like this, whether we admit it
or not, because we have to allow for pervasive erasure and be able to
fall back to looser linkage conventions. SO the type restriction was
always optimistic; we might say "Object restricted to QPoint", but
someone could sh
I'll chime in that I am coming around to disjoint Q/L, and here are a couple of
thoughts on how to reconcile that with VM generics.
On Jan 27, 2022, at 2:00 PM, John Rose
mailto:john.r.r...@oracle.com>> wrote:
Furthermore, i believe that subtyping is a key to avoid multiple bytecode
verificati
On 25 Jan 2022, at 2:50, fo...@univ-mlv.fr wrote:
Let's talk a bit about having the L world and the Q world completely
disjoint at least from the bytecode verifier POV.
Yes please; indeed, that is my strong recommendation. Doing this
(`Q>:interpreter (as well as verifier) to concentrate one
> From: "Brian Goetz"
> To: "Dan Heidinga"
> Cc: "Remi Forax" , "John Rose" ,
> "valhalla-spec-experts"
> Sent: Tuesday, January 25, 2022 3:57:17 PM
> Subject: Re: VM model and aconst_init
> The motivation for this co
More explicitly, this is a set of use cases for using
Q-types in C_Class entries in the constant pool to switch
to Q-mode for bytecodes that refer to classes, including
withfield and aconst_init.
Let's talk a bit about having the L world and the Q world completely disjoint
at least from t
> (Q-Foo not a subtype of L-Foo in the verifier) so that
> each mode stays “in its own lane”.
>
> More explicitly, this is a set of use cases for using
> Q-types in C_Class entries in the constant pool to switch
> to Q-mode for bytecodes that refer to classes, including
> withfield
> From: "John Rose"
> To: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, January 19, 2022 9:40:15 AM
> Subject: Re: VM model and aconst_init
> I think (based on our most recent conversations)
> that aconst_init can return a Q-
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_ini
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
> 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 internal name
&
...@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.
> From: "Brian Goetz"
> To: "Remi Forax" , "valhalla-spec-experts"
>
> Sent: Wednesday, January 12, 2022 1:45:34 PM
> Subject: Re: VM model and aconst_init
> Both value and primitive classes use the aconst_init / withfield
> initializatio
Both value and primitive classes use the aconst_init / withfield
initialization protocol. The former is an L-type (QOptional is
illegal); the latter uses Q types for initialization.
Value classes
-> are L types
-> which are references
-> references can be null
-> VM manag
I've some troubles to wrap my head around those two sentences
"""
aconst_init is the analogue of new for value objects; it leaves a reference to
the initial value for a value class on the stack. This initial value is
guaranteed to not be equal to null. The sole operand o
On Dec 1, 2021, at 7:58 AM, Dan Heidinga wrote:
>
> Splitting a new thread off from Dan's email about the jep draft to
> talk about the `aconst_init` bytecode:
>
>> aconst_init, with a CONSTANT_Class operand, produces an instance of the
>> named value class,
Splitting a new thread off from Dan's email about the jep draft to
talk about the `aconst_init` bytecode:
> aconst_init, with a CONSTANT_Class operand, produces an instance of the named
> value class, with all fields set to their default values. This operation
> always has pri
19 matches
Mail list logo