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
The motivation for this comes from erasure. Even if we specialize, we need to be able to use specialized generics in an erased context, because there will be erased clients. If we have class Foo { T m(); T[] arr(); } we can use also sorts of bridging/casting tricks to ma

Re: VM model and aconst_init

2022-01-25 Thread Dan Heidinga
> Can you mix and match both modes in the same method? > Probably, since the interpreter doesn’t care about > multi-bytecode patterns. Dunno if this causes a testing > problem, and if so how to fix it. I think it’s probably > OK, especially if we require the two-way checkcast > (Q-Foo not a subtype

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 st

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
The operand of C_Class is a weird beast.  It can be an internal name (com/foo/Bar), but it can also be a *descriptor* for an array type.  Valhalla extends it to allow Q descriptors as well (but not L descriptors -- there should be one way to say C_Class[String].) On 1/12/2022 8:14 AM, fo...@un

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 manages where the nulli

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 of this bytecode is a ref