From daniel.smith at oracle.com  Wed Apr  7 15:04:30 2021
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 7 Apr 2021 15:04:30 +0000
Subject: EG meeting *canceled*, 2021-04-07
Message-ID: <33ABB14C-83DE-43AB-8F3F-FAC7F4EE597F@oracle.com>

I'm on vacation this week, and it looks like we don't have anything new in the mailing list. No meeting today.

From forax at univ-mlv.fr  Tue Apr 20 16:40:49 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 20 Apr 2021 18:40:49 +0200 (CEST)
Subject: Parametric VM class file format
Message-ID: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>

Hi all,
at least as an exercise to understand the proposed class file format for the parametric VM, i will update ASM soon (in a branch) to see how things work.

As usual with ASM, there is the question of sharing the same index in the constant pool,
i.e. should two anchors (SpecializationAnchor) that have the same kind and the same BSM + constant arguments share the same constant pool index ?
And same question with two linkages (SpecializationLinkage).

I believe the answer is yes for both, the index is shared.

The other questions are about "ldc Linkage", first, why do we need a ldc Linkage with a Linkage that reference a class given that we already have Condy ?
And second question, is there a ldc Linkage with the linkage referencing something else than a class ?

regards,
R?mi



From daniel.smith at oracle.com  Wed Apr 21 02:22:47 2021
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 21 Apr 2021 02:22:47 +0000
Subject: EG meeting, 2021-04-21
Message-ID: <E4EA4DA6-C421-4599-99EB-9D0D046850AB@oracle.com>

The next EG Zoom meeting is Wednesday at 4pm UTC (9am PDT, 12pm EDT).

May be a short meeting, but we can discuss Remi's "Parametric VM class file format" questions, along with any other followup thoughts about the Parametric VM design.


From john.r.rose at oracle.com  Wed Apr 21 06:43:34 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 21 Apr 2021 06:43:34 +0000
Subject: Parametric VM class file format
In-Reply-To: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>
References: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>
Message-ID: <90BDC091-BF0A-4BAF-91AC-F8E9BD6BAB87@oracle.com>

On Apr 20, 2021, at 9:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi all,
> at least as an exercise to understand the proposed class file format for the parametric VM, i will update ASM soon (in a branch) to see how things work.

Thank you!

> As usual with ASM, there is the question of sharing the same index in the constant pool,
> i.e. should two anchors (SpecializationAnchor) that have the same kind and the same BSM + constant arguments share the same constant pool index ?

Yes, I don?t see why not.  For a Class-level SA it would
be a bug if there were two of them in one classfile.

> And same question with two linkages (SpecializationLinkage).

Definitely.  Just like you?d want to unique-ify
CONSTANT_Class items.

> I believe the answer is yes for both, the index is shared.
> 
> The other questions are about "ldc Linkage", first, why do we need a ldc Linkage with a Linkage that reference a class given that we already have Condy ?

Condy can do a lot of this stuff, but it shouldn?t duplicate
work that the JVM is already likely to have done.
If you have code using a C_Linkage[C_Class,] the JVM
has probably resolved it to a species.  In that case,
a condy is wasted work.

We did without ldc C_Class for a while but added it
for similar reasons.  Once we added it we had no
desire to go back to the workarounds.  I predict the
same for ?C_Species? which is C_Linkage[C_Class,].

> And second question, is there a ldc Linkage with the linkage referencing something else than a class ?

No!  It would be possible to find a meaning for such
a thing, but it would probably interfere with ldc
of C_Linkage[C_Class,].  (I tried.)  The workaround
is not bad:  Just wrap the C_Linkage[C_Methodref]
in a C_MethodHandle, et voil?.

An earlier draft made ldc of a C_Linkage recover
the SpecializationAnchor object, with the theory
that from there condy gets you everything.  But
I turned away from that design because (a) it was
clunky to use, and (b) it exposed SA objects which,
as I came to understand, should really be encapsulated
and private to their defining class.

? John

From john.r.rose at oracle.com  Wed Apr 21 06:51:08 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 21 Apr 2021 06:51:08 +0000
Subject: consolidated VM notes for primitive classes
Message-ID: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>

Brian and I hammered out a document this week that
captures what we think is emerging as our shared
understanding of how adapt the JVM to support
primitive classes.

It is still white-hot, not even off the press, but I think
it is worth looking it even in its unfinished state.

https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md

That is the JVM side, only.  Most of it is already
prototyped in HotSpot, some is not.

I?ll let Brian speak for the valhalla-doc repository
as a whole, but I wanted to get this out there for
tomorrow?s meeting.

? John

From forax at univ-mlv.fr  Wed Apr 21 15:32:32 2021
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 21 Apr 2021 17:32:32 +0200 (CEST)
Subject: Parametric VM class file format
In-Reply-To: <90BDC091-BF0A-4BAF-91AC-F8E9BD6BAB87@oracle.com>
References: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>
 <90BDC091-BF0A-4BAF-91AC-F8E9BD6BAB87@oracle.com>
Message-ID: <52395807.1964111.1619019152957.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoy?: Mercredi 21 Avril 2021 08:43:34
> Objet: Re: Parametric VM class file format

> On Apr 20, 2021, at 9:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi all,
>> at least as an exercise to understand the proposed class file format for the
>> parametric VM, i will update ASM soon (in a branch) to see how things work.
> 
> Thank you!
> 
>> As usual with ASM, there is the question of sharing the same index in the
>> constant pool,
>> i.e. should two anchors (SpecializationAnchor) that have the same kind and the
>> same BSM + constant arguments share the same constant pool index ?
> 
> Yes, I don?t see why not.  For a Class-level SA it would
> be a bug if there were two of them in one classfile.


As i said earlier, I hope the spec will say that you can have more than one SpecializationAnchor with the kind class, given that only one will be used by the VM, the one referenced by the Parametric attribute at class level.

> 
>> And same question with two linkages (SpecializationLinkage).
> 
> Definitely.  Just like you?d want to unique-ify
> CONSTANT_Class items.

yes !

> 
>> I believe the answer is yes for both, the index is shared.
>> 
>> The other questions are about "ldc Linkage", first, why do we need a ldc Linkage
>> with a Linkage that reference a class given that we already have Condy ?
> 
> Condy can do a lot of this stuff, but it shouldn?t duplicate
> work that the JVM is already likely to have done.
> If you have code using a C_Linkage[C_Class,] the JVM
> has probably resolved it to a species.  In that case,
> a condy is wasted work.
> 
> We did without ldc C_Class for a while but added it
> for similar reasons.  Once we added it we had no
> desire to go back to the workarounds.  I predict the
> same for ?C_Species? which is C_Linkage[C_Class,].

It may not be a problem but it means that ArrayList<String>.class is represented by C_Linkage[C_Class] while ArrayList<T>.class is represented by Condy[C_Class, C_SpecializationAnchor] which is not very symmetric.

Also ldc C_Class is now subsumed by Condy, so having everything be managed by Condy may make more sense now that Condy exists.

> 
>> And second question, is there a ldc Linkage with the linkage referencing
>> something else than a class ?
> 
> No!  It would be possible to find a meaning for such
> a thing, but it would probably interfere with ldc
> of C_Linkage[C_Class,].  (I tried.)  The workaround
> is not bad:  Just wrap the C_Linkage[C_Methodref]
> in a C_MethodHandle, et voil?.
> 
> An earlier draft made ldc of a C_Linkage recover
> the SpecializationAnchor object, with the theory
> that from there condy gets you everything.  But
> I turned away from that design because (a) it was
> clunky to use, and (b) it exposed SA objects which,
> as I came to understand, should really be encapsulated
> and private to their defining class.

ahh, i'm lost, it's not clear to me if a SpecializationAnchor can be a bootstrap constant or not ?

> 
> ? John

R?mi

From john.r.rose at oracle.com  Wed Apr 21 22:40:44 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 21 Apr 2021 22:40:44 +0000
Subject: [External] : Re: Parametric VM class file format
In-Reply-To: <52395807.1964111.1619019152957.JavaMail.zimbra@u-pem.fr>
References: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>
 <90BDC091-BF0A-4BAF-91AC-F8E9BD6BAB87@oracle.com>
 <52395807.1964111.1619019152957.JavaMail.zimbra@u-pem.fr>
Message-ID: <AEB28655-ACA2-4562-87D4-C1DA9A5E5FA3@oracle.com>

On Apr 21, 2021, at 8:32 AM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>> Envoy?: Mercredi 21 Avril 2021 08:43:34
>> Objet: Re: Parametric VM class file format
> 
>> On Apr 20, 2021, at 9:40 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Hi all,
>>> at least as an exercise to understand the proposed class file format for the
>>> parametric VM, i will update ASM soon (in a branch) to see how things work.
>> 
>> Thank you!
>> 
>>> As usual with ASM, there is the question of sharing the same index in the
>>> constant pool,
>>> i.e. should two anchors (SpecializationAnchor) that have the same kind and the
>>> same BSM + constant arguments share the same constant pool index ?
>> 
>> Yes, I don?t see why not.  For a Class-level SA it would
>> be a bug if there were two of them in one classfile.
> 
> 
> As i said earlier, I hope the spec will say that you can have more than one SpecializationAnchor with the kind class, given that only one will be used by the VM, the one referenced by the Parametric attribute at class level.

I added this:

> It is permitted for a constant pool to contain
`CONSTANT_SpecializationAnchor` items which are unused.  But typically
a `PARAM_Class` anchor, if it exists, will be unique in its `class`
file, and be referenced by the `Parametric` attribute of the class,
and other anchors will be used to assign parametricity to the class's
methods, either singly or in groups.  It is highly probable that two
specialization anchors with the same kind and bootstrap method are in
fact interchangeable: Just as with `CONSTANT_Dynamic`, there is no
intention to provide "hooks" for structurally identical constants that
have different meanings.
> 
>> We did without ldc C_Class for a while but added it
>> for similar reasons.  Once we added it we had no
>> desire to go back to the workarounds.  I predict the
>> same for ?C_Species? which is C_Linkage[C_Class,].
> 
> It may not be a problem but it means that ArrayList<String>.class is represented by C_Linkage[C_Class] while ArrayList<T>.class is represented by Condy[C_Class, C_SpecializationAnchor] which is not very symmetric.

The asymmetry is intentional because T is not a named
entity in the JVM while every class is.  As the document
says, we can consider adding CP sugar to perform common
tasks, such as reifying a type parameter from a specialization
anchor, but for now condy is our friend.

(It occurs to me that we *might* do, as sugar, CLR-like
syntaxes where an internal constant CONSTANT_Class[T1;]
could be specially decoded into some sequence of hardwired
operations that go and fetch something at position 1 in some
local specialization anchor.  The bigger adventure of putting
T1; into descriptors, making an even more CLR-like system,
will have to wait a long time.  What we are building has
fewer magic names, and more metaprogramming, than
CLR generics.)

> Also ldc C_Class is now subsumed by Condy, so having everything be managed by Condy may make more sense now that Condy exists.

But why?  If I have a nice little nail file C_Class
why should I reach for my chainsaw C_Condy?

> 
>> 
>>> And second question, is there a ldc Linkage with the linkage referencing
>>> something else than a class ?
>> 
>> No!  It would be possible to find a meaning for such
>> a thing, but it would probably interfere with ldc
>> of C_Linkage[C_Class,].  (I tried.)  The workaround
>> is not bad:  Just wrap the C_Linkage[C_Methodref]
>> in a C_MethodHandle, et voil?.
>> 
>> An earlier draft made ldc of a C_Linkage recover
>> the SpecializationAnchor object, with the theory
>> that from there condy gets you everything.  But
>> I turned away from that design because (a) it was
>> clunky to use, and (b) it exposed SA objects which,
>> as I came to understand, should really be encapsulated
>> and private to their defining class.
> 
> ahh, i'm lost, it's not clear to me if a SpecializationAnchor can be a bootstrap constant or not ?

(Is there a residual place in the doc which seems to say that
it would be good to ldc a C_Linkage?  I thought I removed
all of those statements.)

Anyway, you can ldc a C_Anchor and/or observe it in a BSM,
and that?s how you start the metaprogramming adventure:

> A `CONSTANT_SpecializationAnchor` constant is a (new sort of) loadable
> constant (?5.1).  The resolved value of this constant is a mirror to a
> set of specialization decisions, also called a `SpecializationAnchor`
> (?4.1).

Then you look at the rather wide SA API, and condy is
your friend from there on.  If we want, we can add more
sugar, but first we should go light on sugar.

? John

From john.r.rose at oracle.com  Thu Apr 22 02:30:13 2021
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 22 Apr 2021 02:30:13 +0000
Subject: [External] : Re: Parametric VM class file format
In-Reply-To: <AEB28655-ACA2-4562-87D4-C1DA9A5E5FA3@oracle.com>
References: <54064030.1371532.1618936849563.JavaMail.zimbra@u-pem.fr>
 <90BDC091-BF0A-4BAF-91AC-F8E9BD6BAB87@oracle.com>
 <52395807.1964111.1619019152957.JavaMail.zimbra@u-pem.fr>
 <AEB28655-ACA2-4562-87D4-C1DA9A5E5FA3@oracle.com>
Message-ID: <C358BEA3-509A-40C3-A8D4-1D361E2C4910@oracle.com>

I pushed an updated version of the PVM document
to its new home in valhalla-docs:

https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/parametric-vm/parametric-vm.md

Here is the produced HTML (we don?t have this
automated yet):

http://cr.openjdk.java.net/~jrose/values/parametric-vm.html

It attempts to address recent EG comments.  In order
to track our progress I committed the first public version
to github, and then immediately overwrote it with the
current version.

Here are the most recent changes:

https://github.com/openjdk/valhalla-docs/commit/e6d16bfed0768ade802e58808b79c4c44b5ec1cb

At you prompting, Remi, I have changed ?parameter? to
?selector? as the term which describes the cookie that
a client uses to request a specialization.

? John

From brian.goetz at oracle.com  Mon Apr 26 20:11:40 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 26 Apr 2021 16:11:40 -0400
Subject: consolidated VM notes for primitive classes
In-Reply-To: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
Message-ID: <a7de2556-265d-0dc7-ffac-262f5a08e1c1@oracle.com>

I also lightly updated the 01- and 02- documents based on recent 
discussions.

On 4/21/2021 2:51 AM, John Rose wrote:
> Brian and I hammered out a document this week that
> captures what we think is emerging as our shared
> understanding of how adapt the JVM to support
> primitive classes.
>
> It is still white-hot, not even off the press, but I think
> it is worth looking it even in its unfinished state.
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md 
> <https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md>
>
> That is the JVM side, only. ?Most of it is already
> prototyped in HotSpot, some is not.
>
> I?ll let Brian speak for the valhalla-doc repository
> as a whole, but I wanted to get this out there for
> tomorrow?s meeting.
>
> ? John


From mcnepp02 at googlemail.com  Tue Apr 27 05:18:28 2021
From: mcnepp02 at googlemail.com (Gernot Neppert)
Date: Tue, 27 Apr 2021 07:18:28 +0200
Subject: consolidated VM notes for primitive classes
In-Reply-To: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
Message-ID: <6855f0a8-8027-d5ad-2c49-9016d2aa75aa@gmail.com>

Hi John,

the most recent update to this document was the insertion of the 
paragraph starting with

"JVM-inserted supers are *not* visible to reflection via 
`Class::getInterfaces`"

The text goes to great lengths to explain the very complicated (or 
should I say "convoluted") way by which you could still find out 
reliably via reflection whether you were looking at a Class implementing 
one of the Marker interfaces...

And then, when I was eagerly reading on to find the rationale for this 
inconsistent design, I finally came to this sentence:

"Keeping secrets from reflection is a risky business, but in this
case it seems safer to do so, lest a large fraction of existing Java classes
suddenly grow new items in their `Class::getInterfaces` arrays."

To be honest, this seems to be the most unconvincing reason one could 
think of. How could the addition of an interface in 
"Class::getInterfaces" ever be a problem?

Regards,

Gernot

Am 21.04.2021 um 08:51 schrieb John Rose:
> Brian and I hammered out a document this week that
> captures what we think is emerging as our shared
> understanding of how adapt the JVM to support
> primitive classes.
>
> It is still white-hot, not even off the press, but I think
> it is worth looking it even in its unfinished state.
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md
>
> That is the JVM side, only.  Most of it is already
> prototyped in HotSpot, some is not.
>
> I?ll let Brian speak for the valhalla-doc repository
> as a whole, but I wanted to get this out there for
> tomorrow?s meeting.
>
> ? John



From peter.levart at gmail.com  Tue Apr 27 14:17:02 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Apr 2021 16:17:02 +0200
Subject: consolidated VM notes for primitive classes
In-Reply-To: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
Message-ID: <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>

Hi,

I just noticed the following statement in the presented document:

 > If a primitive object is composed of a combination of scalars and 
references to identity objects, the problem is less hopeless, though 
still complicated. A primitive object becomes unreachable (in the 
modified definition of the previous paragraph) if and only if at least 
one of its component identity object references becomes unreachable.

If this did see an implementation in the VM, we would essentially get 
muti-referent Ephemeron(s) out of it. Not very easy to implement though.


Regards, Peter


On 4/21/21 8:51 AM, John Rose wrote:
> Brian and I hammered out a document this week that
> captures what we think is emerging as our shared
> understanding of how adapt the JVM to support
> primitive classes.
>
> It is still white-hot, not even off the press, but I think
> it is worth looking it even in its unfinished state.
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md 
> <https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md>
>
> That is the JVM side, only. ?Most of it is already
> prototyped in HotSpot, some is not.
>
> I?ll let Brian speak for the valhalla-doc repository
> as a whole, but I wanted to get this out there for
> tomorrow?s meeting.
>
> ? John

From peter.levart at gmail.com  Tue Apr 27 14:27:11 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Apr 2021 16:27:11 +0200
Subject: consolidated VM notes for primitive classes
In-Reply-To: <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
 <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>
Message-ID: <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>


On 4/27/21 4:17 PM, Peter Levart wrote:
> Hi,
>
> I just noticed the following statement in the presented document:
>
> > If a primitive object is composed of a combination of scalars and 
> references to identity objects, the problem is less hopeless, though 
> still complicated. A primitive object becomes unreachable (in the 
> modified definition of the previous paragraph) if and only if at least 
> one of its component identity object references becomes unreachable.
>
> If this did see an implementation in the VM, we would essentially get 
> muti-referent Ephemeron(s) out of it. Not very easy to implement though.


Sorry, this is not correct. The rules for Ephemeron(s) are different. If 
primitive object became unreachable when all of its component identity 
object references became unreachable, then we would get Ephemeron. The 
rules in the document (at least one) are easier to implement.

Peter


>
>
> Regards, Peter
>
>
> On 4/21/21 8:51 AM, John Rose wrote:
>> Brian and I hammered out a document this week that
>> captures what we think is emerging as our shared
>> understanding of how adapt the JVM to support
>> primitive classes.
>>
>> It is still white-hot, not even off the press, but I think
>> it is worth looking it even in its unfinished state.
>>
>> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md 
>> <https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md> 
>>
>>
>> That is the JVM side, only. ?Most of it is already
>> prototyped in HotSpot, some is not.
>>
>> I?ll let Brian speak for the valhalla-doc repository
>> as a whole, but I wanted to get this out there for
>> tomorrow?s meeting.
>>
>> ? John

From peter.levart at gmail.com  Tue Apr 27 14:37:59 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 27 Apr 2021 16:37:59 +0200
Subject: consolidated VM notes for primitive classes
In-Reply-To: <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
 <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>
 <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>
Message-ID: <9c431bb7-cbb2-74ea-c468-a06bc62d1332@gmail.com>


On 4/27/21 4:27 PM, Peter Levart wrote:
>
> On 4/27/21 4:17 PM, Peter Levart wrote:
>> Hi,
>>
>> I just noticed the following statement in the presented document:
>>
>> > If a primitive object is composed of a combination of scalars and 
>> references to identity objects, the problem is less hopeless, though 
>> still complicated. A primitive object becomes unreachable (in the 
>> modified definition of the previous paragraph) if and only if at 
>> least one of its component identity object references becomes 
>> unreachable.
>>
>> If this did see an implementation in the VM, we would essentially get 
>> muti-referent Ephemeron(s) out of it. Not very easy to implement though.
>
>
> Sorry, this is not correct. The rules for Ephemeron(s) are different. 
> If primitive object became unreachable when all of its component 
> identity object references became unreachable, then we would get 
> Ephemeron. The rules in the document (at least one) are easier to 
> implement.


And neither is that. I had to look back at the specification. Ephemeron 
refers to a pair of referents, but they are not equivalent. The 
reachability of the 1st referent governs the reachability of the 2nd. 
Sorry for these inappropriate comments.


>
> Peter
>
>
>>
>>
>> Regards, Peter
>>
>>
>> On 4/21/21 8:51 AM, John Rose wrote:
>>> Brian and I hammered out a document this week that
>>> captures what we think is emerging as our shared
>>> understanding of how adapt the JVM to support
>>> primitive classes.
>>>
>>> It is still white-hot, not even off the press, but I think
>>> it is worth looking it even in its unfinished state.
>>>
>>> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md 
>>> <https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md> 
>>>
>>>
>>> That is the JVM side, only. ?Most of it is already
>>> prototyped in HotSpot, some is not.
>>>
>>> I?ll let Brian speak for the valhalla-doc repository
>>> as a whole, but I wanted to get this out there for
>>> tomorrow?s meeting.
>>>
>>> ? John

From john.r.rose at oracle.com  Wed Apr 28 01:17:44 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 Apr 2021 01:17:44 +0000
Subject: [External] : Re: consolidated VM notes for primitive classes
In-Reply-To: <9c431bb7-cbb2-74ea-c468-a06bc62d1332@gmail.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
 <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>
 <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>
 <9c431bb7-cbb2-74ea-c468-a06bc62d1332@gmail.com>
Message-ID: <0CE0CC9F-1EDF-4178-8078-756F40AA4B65@oracle.com>

On Apr 27, 2021, at 7:37 AM, Peter Levart <peter.levart at gmail.com<mailto:peter.levart at gmail.com>> wrote:


And neither is that. I had to look back at the specification. Ephemeron refers to a pair of referents, but they are not equivalent. The reachability of the 1st referent governs the reachability of the 2nd. Sorry for these inappropriate comments.


I?m glad you l0oked it up!  Perhaps there is
a logical implication connective in that third
definition.

From john.r.rose at oracle.com  Wed Apr 28 01:17:03 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 Apr 2021 01:17:03 +0000
Subject: [External] : Re: consolidated VM notes for primitive classes
In-Reply-To: <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
 <ea54d025-d31f-e4a7-c82a-d01093c71259@gmail.com>
 <5801cd83-1f96-08a0-241f-730878e8de03@gmail.com>
Message-ID: <010F8BE0-8160-42D7-A4BF-00DB03F0B9A0@oracle.com>

On Apr 27, 2021, at 7:27 AM, Peter Levart <peter.levart at gmail.com<mailto:peter.levart at gmail.com>> wrote:

If this did see an implementation in the VM, we would essentially get muti-referent Ephemeron(s) out of it. Not very easy to implement though.


Sorry, this is not correct. The rules for Ephemeron(s) are different. If primitive object became unreachable when all of its component identity object references became unreachable, then we would get Ephemeron. The rules in the document (at least one) are easier to implement.

Yep.  Brian and Jim Laskey have a POC that works.
Also (as the GC folks observe) this is similar to the
rule we use in HotSpot for liveness of ?n-methods?
(compiled code blobs).  As soon as one weak ref in
a code blob goes dead, the whole thing can be
recycled.

The difference here is between ?and? and ?or?
connectives.  In one case, a weak ref is queued
when *any* of its sub-references is queueable,
while in the other (ephemeron) case, we wait
until *all* are queueable.

? John

From brian.goetz at oracle.com  Wed Apr 28 20:12:49 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 28 Apr 2021 16:12:49 -0400
Subject: Classfile artifacts to support compilation/reflection
Message-ID: <07f9880a-758c-689a-dc07-5b7decc33df5@oracle.com>

I'm updating the SoV documents and it raises a few questions about what 
classfile surface we need for capturing the language model.? The good 
news is that with the single-classfile model, the translation complexity 
collapses almost to zero.? But there are a few questions of "what do we 
retain in the classfile."

1.? Ref-favoring vs val-favoring.? Whether a primitive class P is 
ref-favoring or val-favoring no longer affects translation of the 
classfile (yay), it only affects translation of _type uses_ of the 
unadorned name.? But, this has to be capture somewhere in the classfile, 
so that the compiler can read in P.class and know what the name `P` 
means.? There are a few choices here:

 ?- An ACC_ bit.? Meh, these are pretty expensive.
 ?- An attribute, which only javac and reflection would need to pay 
attention to.
 ?- A supertype (implements RefFavoring).

My preference is an attribute; this feels closest to `Signature` to me.? 
Reflection might want to reflect the ref-favoring bit.

2.? Whether abstract classes are primitive superclass candidates.? The 
static compiler will check this at compilation time when it sees a 
superclass of a primitive class, but the JVM will want to recheck 
anyway.? There are two sensible ways to handle this in the classfile:

 ?- An attribute that says "I am a primitive superclass candidate."? The 
static compiler puts it there, and the JVM checks it.
 ?- Infer and tag.? If an abstract class is loaded that is not a 
primitive superclass candidate, the JVM injects IdentityObject as a 
superinterface of the newly loaded class; when we go to load a primitive 
subclass, this will fail because primitive classes cannot implement both 
IdentityObject and PrimitiveObject.

Reflection probably doesn't have to reflect whether a class is primitive 
superclass candidate; it already reflects the things needed to make this 
determination.

3.? T.ref.? In generic code, we can say `T.ref`, which is a total 
operator on types; if T is already a reference type, then T.ref = T, and 
if it is a primitive value type P.val., then T.ref = P.ref.? The 
Signature attribute should be extended to support the distinction 
between a use of `T` and a use of `T.ref`.? (T.val is partial, so 
doesn't make sense in the general case, and in the specific cases where 
it does make sense, does not currently look worth supporting.)

4.? Other flavors, as needed.? We've considered a "null-default" 
primitive class; if so, this has to be captured in a similar way as 
(1).? These can probably all be folded into a single PrimitiveClass 
attribute.



From brian.goetz at oracle.com  Wed Apr 28 20:31:17 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 28 Apr 2021 16:31:17 -0400
Subject: consolidated VM notes for primitive classes
In-Reply-To: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
References: <60764734-931E-40F9-B917-4B17B88106CF@oracle.com>
Message-ID: <c93ecb2c-8791-ce62-729d-c35746f77643@oracle.com>

I've updated this document to subsume the translation details from 
source to classfile.? With the new single-file translation, this part, 
which used to be its own whole document, is now a small-ish (and mostly 
obvious) section at the end of the VM Model document.

On 4/21/2021 2:51 AM, John Rose wrote:
> Brian and I hammered out a document this week that
> captures what we think is emerging as our shared
> understanding of how adapt the JVM to support
> primitive classes.
>
> It is still white-hot, not even off the press, but I think
> it is worth looking it even in its unfinished state.
>
> https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md 
> <https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md>
>
> That is the JVM side, only. ?Most of it is already
> prototyped in HotSpot, some is not.
>
> I?ll let Brian speak for the valhalla-doc repository
> as a whole, but I wanted to get this out there for
> tomorrow?s meeting.
>
> ? John


From maurizio.cimadamore at oracle.com  Thu Apr 29 11:29:35 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 29 Apr 2021 12:29:35 +0100
Subject: Classfile artifacts to support compilation/reflection
In-Reply-To: <07f9880a-758c-689a-dc07-5b7decc33df5@oracle.com>
References: <07f9880a-758c-689a-dc07-5b7decc33df5@oracle.com>
Message-ID: <553ee62d-abc2-140a-e91c-23b31ab4ec7b@oracle.com>


On 28/04/2021 21:12, Brian Goetz wrote:
> I'm updating the SoV documents and it raises a few questions about 
> what classfile surface we need for capturing the language model.? The 
> good news is that with the single-classfile model, the translation 
> complexity collapses almost to zero.? But there are a few questions of 
> "what do we retain in the classfile."
>
> 1.? Ref-favoring vs val-favoring.? Whether a primitive class P is 
> ref-favoring or val-favoring no longer affects translation of the 
> classfile (yay), it only affects translation of _type uses_ of the 
> unadorned name.? But, this has to be capture somewhere in the 
> classfile, so that the compiler can read in P.class and know what the 
> name `P` means.? There are a few choices here:
>
> ?- An ACC_ bit.? Meh, these are pretty expensive.
> ?- An attribute, which only javac and reflection would need to pay 
> attention to.
> ?- A supertype (implements RefFavoring).
>
> My preference is an attribute; this feels closest to `Signature` to 
> me.? Reflection might want to reflect the ref-favoring bit.
In fact, I think we could even roll it in the Signature attribute itself?
>
> 2.? Whether abstract classes are primitive superclass candidates.? The 
> static compiler will check this at compilation time when it sees a 
> superclass of a primitive class, but the JVM will want to recheck 
> anyway.? There are two sensible ways to handle this in the classfile:
>
> ?- An attribute that says "I am a primitive superclass candidate."? 
> The static compiler puts it there, and the JVM checks it.
> ?- Infer and tag.? If an abstract class is loaded that is not a 
> primitive superclass candidate, the JVM injects IdentityObject as a 
> superinterface of the newly loaded class; when we go to load a 
> primitive subclass, this will fail because primitive classes cannot 
> implement both IdentityObject and PrimitiveObject.
Can't we check this lazily, when a primitive class is loaded? That 
triggers loading of supers, at which point we can check the various 
constraints and throw if needed. Tagging is an impl detail of the VM 
(and javac) IMHO - in case we don't want to repeat the checks multiple 
times - but injecting extra supertypes as a way of tagging seems a bit 
on the "too public" side of things (as I view this as, essentially, an 
optimization).
>
> Reflection probably doesn't have to reflect whether a class is 
> primitive superclass candidate; it already reflects the things needed 
> to make this determination.
>
> 3.? T.ref.? In generic code, we can say `T.ref`, which is a total 
> operator on types; if T is already a reference type, then T.ref = T, 
> and if it is a primitive value type P.val., then T.ref = P.ref.? The 
> Signature attribute should be extended to support the distinction 
> between a use of `T` and a use of `T.ref`.? (T.val is partial, so 
> doesn't make sense in the general case, and in the specific cases 
> where it does make sense, does not currently look worth supporting.)
Yep, we need signature attribute support for all this stuff. Unless we 
want to get clever and infer some things for side channels - but this 
probably won't work in all cases.
>
> 4.? Other flavors, as needed.? We've considered a "null-default" 
> primitive class; if so, this has to be captured in a similar way as 
> (1).? These can probably all be folded into a single PrimitiveClass 
> attribute.

True - if we do have a PrimitiveClass attr, I agree that null-default, 
ref-default and such would belong there.

Maurizio

>
>