> 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
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
> 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
> 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 st
> 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
&
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
> 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 manages where the nulli
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
17 matches
Mail list logo