Re: VM model and aconst_init

2022-01-31 Thread forax
> 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

Re: [External] : Re: VM model and aconst_init

2022-01-31 Thread forax
> 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.

Re: VM model and aconst_init

2022-01-29 Thread Brian Goetz
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

Re: VM model and aconst_init

2022-01-28 Thread Dan Smith
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

Re: [External] : Re: VM model and aconst_init

2022-01-27 Thread John Rose
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

Re: VM model and aconst_init

2022-01-25 Thread forax
> 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

Re: VM model and aconst_init

2022-01-25 Thread Brian Goetz
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

Re: VM model and aconst_init

2022-01-25 Thread Dan Heidinga
> (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

Re: VM model and aconst_init

2022-01-25 Thread forax
> 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-

Re: [External] : Re: VM model and aconst_init

2022-01-19 Thread John Rose
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

Re: VM model and aconst_init

2022-01-19 Thread John Rose
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

Re: VM model and aconst_init

2022-01-19 Thread John Rose
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

Re: [External] : Re: VM model and aconst_init

2022-01-12 Thread forax
> 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 &

Re: [External] : Re: VM model and aconst_init

2022-01-12 Thread Brian Goetz
...@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.

Re: VM model and aconst_init

2022-01-12 Thread forax
> 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

Re: VM model and aconst_init

2022-01-12 Thread Brian Goetz
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

VM model and aconst_init

2022-01-12 Thread Remi Forax
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

Re: aconst_init

2021-12-01 Thread John Rose
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,

aconst_init

2021-12-01 Thread Dan Heidinga
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