Re: JEP update: Value Objects

Hi Daniel, this is really nice. Here are my remarks. "It generally requires that an object's data be located at a fixed memory location" remove "fixed", all OpenJDK GCs move objects. Again later, remove "fixed" in "That is, a value object does not have a fixed memory address ...". At the

Re: [External] : Re: JEP update: Value Objects

> From: "John Rose" > To: "daniel smith" > Cc: "Dan Heidinga" , "valhalla-spec-experts" > > Sent: Jeudi 2 Décembre 2021 00:56:02 > Subject: Re: [External] : Re: JEP update: Value Objects > On Dec 1, 2021, at 3:29 PM, Dan Smith < [ mailto:daniel.sm...@oracle.com | > daniel.sm...@oracle.com ] >

Re: Proposal: Static/final constructors for bucket-3 primitive classes.

> From: "John Rose" > To: "Brian Goetz" > Cc: "valhalla-spec-experts" , "clement > cherlin" > Sent: Thursday, December 9, 2021 5:30:50 AM > Subject: Re: Proposal: Static/final constructors for bucket-3 primitive > classes. > We have considered, at various points in the last six years or more,

Re: Objects.newIdentity update

- Original Message - > From: "daniel smith" > To: "valhalla-spec-experts" > Cc: "Roger Riggs" > Sent: Lundi 19 Juillet 2021 19:59:03 > Subject: Objects.newIdentity update [I've added Mark in CC] > An update on Objects.newIdentity for Java 17: Roger did some work to put the > feature

VM model and aconst_init

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

L-type, Q-type and class mirrors

Hi all, i want to propose a way to reconcile builtin primitive types and primitive classes in the B1/B2/B3 world. Let's take a detour, and try to answer to the question, how do we do reflection on method with Q-types ? Given that reflection is using the class java.lang.Class, it means that we

Re: Evolving instance creation

- Original Message - > From: "Dan Heidinga" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Thursday, February 24, 2022 4:39:52 PM > Subject: Re: Evolving instance creation > Repeating what I said in the EG meeting: > > * "new" carries the mental model of allocating space.

Re: Alternative to IdentityObject & ValueObject interfaces

Hi Brian, i've maybe have twisted mind but i read your email as a rebuttal of both IdentityObject/ValueObject and identity/value modifiers. As you said, an identity object and a value object are less dis-similar now that they were in the past: a value class now reuse the method equals and

Re: Alternative to IdentityObject & ValueObject interfaces

- Original Message - > From: "Maurizio Cimadamore" > To: "daniel smith" , "valhalla-spec-experts" > > Sent: Wednesday, March 23, 2022 11:23:26 AM > Subject: Re: Alternative to IdentityObject & ValueObject interfaces > On 22/03/2022 23:56, Dan Smith wrote: >> Other abstract classes and

Re: Alternative to IdentityObject & ValueObject interfaces

> From: "Brian Goetz" > To: "daniel smith" , "valhalla-spec-experts" > > Sent: Thursday, March 24, 2022 1:46:44 PM > Subject: Re: Alternative to IdentityObject & ValueObject interfaces > On 3/23/2022 10:51 PM, Dan Smith wrote: >>> On Mar 22, 2022, at 5:56 PM, Dan Smith < [

Re: Object as a concrete class

- Original Message - > From: "Dan Heidinga" > To: "Brian Goetz" > Cc: "daniel smith" , "valhalla-spec-experts" > > Sent: Friday, April 1, 2022 3:50:20 PM > Subject: Re: Object as a concrete class > On Fri, Apr 1, 2022 at 9:29 AM Brian Goetz wrote: >> >> >> > assert new

Re: SoV-2: weak references

- Original Message - > From: "Dan Heidinga" > To: "Brian Goetz" > Cc: "valhalla-spec-experts" > Sent: Wednesday, February 9, 2022 5:50:29 PM > Subject: Re: SoV-2: weak references > One option is to look at what we can do to help users prepare for IAE > when using value-based classes as

Re: SoV-3: constructor questions

- Original Message - > From: "Dan Heidinga" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Thursday, January 27, 2022 4:09:58 PM > Subject: Re: SoV-3: constructor questions > (Resending as I forgot to CC the list - Sorry for the duplicate email Dan) > >> We can come up

Re: Abstract class with fields implementing ValueObject

- Original Message - > From: "John Rose" > To: "Frederic Parain" > Cc: "valhalla-spec-experts" > Sent: Thursday, February 10, 2022 12:02:53 AM > Subject: Re: Abstract class with fields implementing ValueObject > That could be one of very many edge conditions in the JVMS that are not >

Re: EG meeting, 2022-02-09 [SoV-3: constructor questions]

> From: "John Rose" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Wednesday, February 9, 2022 7:32:07 PM > Subject: Re: EG meeting, 2022-02-09 [SoV-3: constructor questions] > On 8 Feb 2022, at 19:04, Dan Smith wrote: >> "SoV-3: constructor questions": Dan asked about validation

Re: Why do we need .ref class for primtive class ?

- Original Message - > From: "Remi Forax" > To: "valhalla-spec-experts" > Sent: Thursday, January 6, 2022 7:50:54 PM > Subject: Why do we need .ref class for primtive class ? > It just occurs to me that while ACC_VALUE is a bit that change the runt

Why do we need .ref class for primtive class ?

It just occurs to me that while ACC_VALUE is a bit that change the runtime semantics, something the VM should take care of, ACC_PRIMITIVE is not a bit that change the runtime semantics, only the javac translation strategy, javac emits Q-types instead of L-type + the Preload attribute. If value

The interfaces IdentityObject and ValueObject must die !

I think we should revisit the idea of having the interfaces IdentityObject/ValueObject. They serve two purposes 1/ documentation: explain the difference between an identity class and a value class 2/ type restriction: can be used as type or bound of type parameter for algorithms that only

Re: Objects vs. values, the continuation

> From: "Kevin Bourrillion" > To: "valhalla-spec-experts" > Sent: Saturday, April 23, 2022 12:38:12 AM > Subject: Objects vs. values, the continuation > I'd like to remind everyone about this (self-important-sounding) document I > shared some months ago: [ >

Re: Objects vs. values, the continuation

> From: "Brian Goetz" > To: "Kevin Bourrillion" > Cc: "valhalla-spec-experts" > Sent: Sunday, April 24, 2022 5:57:57 PM > Subject: Re: Objects vs. values, the continuation > Overall I find a lot to like about this presentation. I’m still a little iffy > about whether we can redefine the

Re: Objects vs. values, the continuation

> From: "Remi Forax" > To: "Kevin Bourrillion" > Cc: "valhalla-spec-experts" > Sent: Monday, April 25, 2022 12:23:32 AM > Subject: Re: Objects vs. values, the continuation >> From: "Kevin Bourrillion" >> To: "valhalla

Re: We need help to migrate from bucket 1 to 2; and, the == problem

> From: "Kevin Bourrillion" > To: "valhalla-spec-experts" > Sent: Tuesday, April 26, 2022 5:12:54 AM > Subject: We need help to migrate from bucket 1 to 2; and, the == problem > So I want to make my class identityless. But -- whoops! -- I released it years > ago and it has lots of usages. And

Re: [External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

> From: "Brian Goetz" > To: "Dan Heidinga" > Cc: "Kevin Bourrillion" , "valhalla-spec-experts" > > Sent: Monday, April 25, 2022 8:26:02 PM > Subject: Re: [External] Foo / Foo.ref is a backward default; should be > Foo.val / > Foo >>> What I’m thinking here about migration is that existing

Re: [External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

> From: "Kevin Bourrillion" > To: "valhalla-spec-experts" > Sent: Monday, April 25, 2022 4:52:50 AM > Subject: [External] Foo / Foo.ref is a backward default; should be Foo.val / > Foo > Hi, > The current plan for `primitive class Foo` -- to call the value type `Foo` and > the reference type

B3 ref model

Ok, maybe i've not understood correctly how B3 model works, for me being a B3 is a runtime property, not a type property. By example, if there is an Object but the VM knows the only possible type is a B3 and the value is not null then the VM is free to emit several stores, because it's a B3, so

128bits value type and VarHande.compareAndSet() Was: Objects vs. values, the continuation

> From: "Brian Goetz" > To: "Dan Heidinga" > Cc: "Kevin Bourrillion" , "valhalla-spec-experts" > > Sent: Monday, April 25, 2022 4:59:14 PM > Subject: Re: Objects vs. values, the continuation >>> The fact that these are "small" (at most 64 bits) is incidental, not >>> essential; >>>

Re: User model stacking: current status

> From: "Brian Goetz" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Friday, June 3, 2022 9:14:39 PM > Subject: Re: User model stacking: current status > Continuing to shake this tree. > I'm glad we went through the exploration of "flattenable B3.ref"; while I > think > we

Re: User model stacking: current status

> From: "Brian Goetz" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Tuesday, June 14, 2022 1:04:39 AM > Subject: Re: User model stacking: current status > I've done a little more shaking of this tree. It involves keeping the notion > that the non-identity buckets differ only in

Re: Anonymous value classes

- Original Message - > From: "daniel smith" > To: "valhalla-spec-experts" > Sent: Friday, June 3, 2022 6:18:42 PM > Subject: Re: Anonymous value classes >> On Jun 3, 2022, at 10:15 AM, Dan Smith wrote: >> >> Our javac prototype has long included support for a 'value' keyword after >>

Re: Anonymous value classes

> From: "Brian Goetz" > To: "daniel smith" , "valhalla-spec-experts" > > Sent: Friday, June 3, 2022 6:21:26 PM > Subject: Re: Anonymous value classes > There is no chance to get any calling-convention optimization here, since the > concrete class name will not show up in any method descriptor

Re: User model: terminology

> From: "Brian Goetz" > To: "valhalla-spec-experts" > Sent: Wednesday, May 4, 2022 5:05:24 PM > Subject: User model: terminology > Let's talk about terminology. (This is getting dangerously close to a > call-for-bikeshed, so let's exercise restraint.) > Currently, we have primitives and

Re: [External] : Re: User model stacking

> From: "Brian Goetz" > To: "Dan Heidinga" > Cc: "valhalla-spec-experts" > Sent: Thursday, April 28, 2022 1:15:08 AM > Subject: Re: [External] : Re: User model stacking > Let me try and put some more color on the bike shed (but, again, let’s focus > on > model, not syntax, for now.) > We

Re: On tearing

> From: "Brian Goetz" > To: "valhalla-spec-experts" > Sent: Wednesday, April 27, 2022 3:59:31 PM > Subject: On tearing > Several people have asked why I am so paranoid about tearing. This mail is > about > tearing; there’ll be another about user model stacking and performance models. >

Re: Null channels (was: User model stacking)

- Original Message - > From: "Brian Goetz" [...] > > What I'm trying to do here is decomplect flattening from nullity. Right > now, we have an unfortunate interaction which both makes certain > combinations impossible, and makes the user model harder to reason about. > >

Re: User model stacking: current status

> From: "Brian Goetz" > To: "daniel smith" > Cc: "valhalla-spec-experts" > Sent: Sunday, May 8, 2022 6:32:09 PM > Subject: Re: User model stacking: current status > To track the progress of the spiral: > - We originally came up with the B2/B3 division to carve off B2 as the "safe > subset",

Re: User model stacking

- Original Message - > From: "Brian Goetz" > To: "valhalla-spec-experts" > Sent: Wednesday, April 27, 2022 6:44:01 PM > Subject: User model stacking > Here’s some considerations for stacking the user model. (Again, please let’s > resist the temptation to jump to the answer and then

Re: User model stacking

- Original Message - > From: "Dan Heidinga" > To: "Brian Goetz" > Cc: "valhalla-spec-experts" > Sent: Wednesday, April 27, 2022 8:51:15 PM > Subject: Re: User model stacking > I'm trying to understand how this refactoring fits the VM physics. > > In particular, __non-atomic &

Re: Design notes for next values iteration

Interesting ! here is my current view of the problem. Lets say we are in the R/Q/U world, we want U interface to abstract over a reference type or a value type, we want UObject because object is basically an interface, we also want U object like UOptional to be able to painlessly move a

More on seeing the L world as a U world

complex, which means that it will impose a real burden when we will want to maintain or tweak it again in the future. The model i propose is far simpler. Rémi - Mail original - > De: "Remi Forax" <fo...@univ-mlv.fr> > À: "daniel smith" <daniel.sm.

Re: abandon all U-types, welcome to L-world (or, what I learned in Burlington)

> De: "John Rose" > À: "Brian Goetz" > Cc: "valhalla-spec-experts" > Envoyé: Mercredi 22 Novembre 2017 19:48:18 > Objet: Re: abandon all U-types, welcome to L-world (or, what I learned in > Burlington) > On

Re: Doubling down on the erasure vs constant pool specialization

alue types and generics specialization are parts of the same mechanism. Rémi - Mail original - > De: "Remi Forax" <fo...@univ-mlv.fr> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 6 Décembre 2017 15:47:41 >

Re: abandon all U-types, welcome to L-world (or, what I learned in Burlington)

To summarize for myself, we already know that we only need only one U, java.lang.__Value, let try to make it java.lang.Object (with no boxing). The claim is that Object is used more as the root of any types like in collections than as the root of all references like in System.out.println().

Re: [Nestmates] Draft core reflection API

Apart for the corrections already mentioned, this is perfect. Rémi - Mail original - > De: "David Holmes" > À: "valhalla-spec-experts" > Envoyé: Mardi 7 Novembre 2017 08:26:47 > Objet: [Nestmates] Draft core reflection

Re: nestmates spec open issues

getClasses() throws an exception but getAnnotations() skips unavailable annotations. that said, i'm not against throwing in this case. Rémi - Mail original - > De: "David Holmes" > À: "Valhalla Expert Group Observers" >

Re: nestmates spec open issues

> De: "Karen Kinnear" > À: "valhalla-spec-experts" > Envoyé: Mercredi 25 Octobre 2017 16:45:51 > Objet: nestmates spec open issues > ... > 2. Core reflection APIs [ https://bugs.openjdk.java.net/browse/JDK-8188075 | >

Fix Parameter Runtime*ParameterAnnotations spec

[I've trouble to find what is the right list for the JVMS spec change describe below, so i apologize in advance for the spam] Hi all, the spec of the Runtime*ParameterAnnotations attribute [1], allow the number of parameter annotations to be different from the number of parameter from the

Re: nestmates JVMTI spec proposal changes

Given that we will have a NestMate phase 2, i agree with Dan, we can revisit that point later. Rémi > De: "Daniel Heidinga" > À: "Karen Kinnear" > Cc: "valhalla-spec-experts" > Envoyé: Mercredi 20

value based class vs nullable value type

Hi all, just to write my current state of thinking somewhere, I see 3 ways to implement value based class which all have their pros and cons - the value based class bit, a value based class is tagged with ACC_VALUE_BASED, which means that they have no identity. It's not a value class so

Nullable ValueType, Generics and other vexations

Hi all, just to formalize a little more my thinking about the interaction between (nullable) value types and erased generics. With LW1, the VM enforces that a value type can not be null, so each time there is a conversion between an Object to a value type, a nullcheck is inserted. This works

Re: EG help please with getting to LW1 re: Value Types Consistency Checking

Hi all, > De: "John Rose" > À: "Tobi Ajila" > Cc: "valhalla-spec-experts" > Envoyé: Samedi 7 Juillet 2018 23:08:27 > Objet: Re: EG help please with getting to LW1 re: Value Types Consistency > Checking > Hi Tobi. Thanks for the write-up. > To be brief, your proposed technique will seems to

Anonymous value class ?

While testing how value types can be used, i had to find workarounds around the fact that there is no way to create an anonymous value class using the compiler. If we follow the idea of having a classical constructor being transformed to a factory method, i think we should also allow anonymous

val and box

Hi, from the language perspective, one can create a value type using a "value class" VT or a nullable value type NVT with the annonation @ValueBased. The language let you automatically derive - a nullable value type VT.box from a value type VT and VT.val is equivalent to VT. - a non nullable

Re: Finding the spirit of L-World

- Mail original - > De: "Brian Goetz" > À: "valhalla-spec-experts" > Envoyé: Lundi 7 Janvier 2019 18:21:26 > Objet: Finding the spirit of L-World > I’ve been processing the discussions at the Burlington meeting. While I think > we made a lot of progress, I think we fell into a few

Re: Finding the spirit of L-World

But i agree that having all these Q-ref in the bytecode will not help the introduction of generics. I think that the way to implement the reification of generics is: - do the specialization of the data shape by asking a boostrap method with the restriction that the data shape has to be

Re: Valhalla EG meeting notes Sep 12 2018

Hi Tobias, [Switching back to valhalla-spec-experts] - Mail original - > De: "Tobias Hartmann" > À: "valhalla-dev" > Envoyé: Jeudi 13 Septembre 2018 09:33:19 > Objet: Re: Valhalla EG meeting notes Sep 12 2018 > [Switching from valhalla-spec-experts to valhalla-dev] > > Just wanted to

Reified generics - shadow class edition

Reified generics - shadow class edition. I believe that try to make method descriptor variant is a bad idea, it comes from the model 1...3 experimentation but it's an artifact of such implementations, not a concept. Here i describe a way to keep generics erased even if they are reified. If the

Re: Migrating the primitive boxes to values

For 5, the first idea is to forward the call to the constructor to the factory method, but detecting the new + dup + invokespecial may be hard especially in the interpreter. The other solution is to redirect the call to new to create a larval value type and have the invokespecial call to fill

Re: Bridge methods in the VM

> De: "Brian Goetz" > À: "valhalla-spec-experts" > Envoyé: Mardi 22 Janvier 2019 14:51:35 > Objet: Bridge methods in the VM > We’ve been thinking for a long time about the possibilities of pushing > bridging > down into the VM. The reasons we have had until now have not been strong > enough,

Re: Superclasses for inline classes

Hi all, sorry, was not available for the meeting today (i'm officially on vacation). I prefer (2) with a restriction like (1). I don't think users should be able to declare this kind of abstract class because you can not evolve them easily. I'm worried that if they become a tool available,

Re: Locking on primitive boxes

> De: "Brian Goetz" > À: "valhalla-spec-experts" > Envoyé: Mercredi 19 Février 2020 17:45:38 > Objet: Locking on primitive boxes > One of the main impediments to migrating the primitive wrappers to be the > reference projection of an inline class is locking -- there may be code out > there that

Re: atomicity for value types

In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc, and in that case the semantics is volatile + atomic operations (at least CAS), so i think using atomic or any keyword derived from it will not help to our users to understand the semantics for an

Using a Condy instead of a Constant_Utf8

Using a condy that returns a String instead of a method descriptor in the bytecode ? I'm currently trying to remove the uses of Unsafe.defineAnonymousClass to use Lookup.defineHiddenClass instead. There is one case where i dynamically patch a method descriptor so I can select how many arguments

Use of Class.getSimpleName() in java.lang.invoke and InnerClass attribute verification

Most of the error message form the error that can be thrown by classes of java.lang.invoke are using Class.getSimpleName() which makes debugging hidden classes painful because getSimpleName() scrubs the hexadecimal number part of a hidden class name. It also seems that the VM has a zealot

Inline Record vs JLS / Reflection

Hi all, currently an inline record like this public @__inline__ record IntBox(int value) { } generates two classes, IntBox and IntBox$ref, IntBox being the record itself and IntBox$ref being the abstract class representing the nullable version of an inline that inherits from

Re: EG meeting, 2020-11-04

- Mail original - > De: "daniel smith" > À: "valhalla-spec-experts" > Envoyé: Mercredi 4 Novembre 2020 19:18:02 > Objet: Re: EG meeting, 2020-11-04 >> On Nov 3, 2020, at 4:53 PM, Dan Smith wrote: >> >> The next EG Zoom meeting is Wednesday, 5pm UTC (12pm EST, 9am PST). >> >> We'll

Re: Making Object abstract

- Mail original - > De: "John Rose" > À: "Brian Goetz" > Cc: "daniel smith" , "valhalla-spec-experts" > > Envoyé: Mercredi 16 Juin 2021 23:50:35 > Objet: Re: Making Object abstract > On Jun 2, 2021, at 7:57 AM, Brian Goetz wrote: >> >> A minor bikeshed comment: We're asking users to

Make new Object() backward compatible

I think there is a way to avoid all the issues we have with new Object(). The problem: We want to inject the interface IdentityObject on all classes that are neither a "no field" abstract class nor a primtive class. But java.lang.Object acts as a "no field" abstract class but it's not an

Re: [External] : Re: Making Object abstract

> De: "Brian Goetz" > À: "Dan Heidinga" > Cc: "daniel smith" , "valhalla-spec-experts" > > Envoyé: Samedi 5 Juin 2021 17:21:11 > Objet: Re: [External] : Re: Making Object abstract > Rampdown is next week; time is fleeting. > I think the path of adding Objects::newIdentity in 17 seems the best

Re: JEP draft: Better-defined JVM class file validation

- Mail original - > De: "daniel smith" > À: "valhalla-spec-experts" > Envoyé: Vendredi 4 Juin 2021 19:11:11 > Objet: Re: JEP draft: Better-defined JVM class file validation >> On Jun 4, 2021, at 10:41 AM, Dan Smith wrote: >> >> Posted a new JEP draft, here: >> >>

Re: JEP 401 -- reflection and class literals

> From: "Brian Goetz" > To: "valhalla-spec-experts" > Sent: Mardi 29 Juin 2021 18:48:25 > Subject: Re: JEP 401 -- reflection and class literals > The general consensus here is that this stacking is slightly better than the > previous one, so let's take this as the plan of record. Now, to

Re: JEP 401 -- reflection and class literals

> From: "Brian Goetz" > To: "valhalla-spec-experts" > Sent: Mercredi 23 Juin 2021 17:13:27 > Subject: JEP 401 -- reflection and class literals > In working through the details of reflective support in JEP 401, I think we've > fallen into a slight "false consistency" regarding class literals.

Re: [External] : Re: JEP 401 -- reflection and class literals

- Original Message - > From: "Brian Goetz" > To: "Peter Levart" > Cc: "valhalla-spec-experts" > Sent: Dimanche 27 Juin 2021 22:01:21 > Subject: Re: [External] : Re: JEP 401 -- reflection and class literals >> >> >> Seems like we are forced to re-use Class objects to hold this >>

Re: EG meeting, 2021-05-05

- Mail original - > De: "daniel smith" > À: "valhalla-spec-experts" > Envoyé: Mercredi 5 Mai 2021 16:23:08 > Objet: EG meeting, 2021-05-05 > The next EG Zoom meeting is today at 4pm UTC (9am PDT, 12pm EDT). > > Topics to discuss: > > "consolidated VM notes for primitive classes":

Meeting today: IdentityClass

If it's possible, i would like to discuss about IdentityClass again. As noted in the last draft, adding IdentityClass automatically at runtime is not a compatible change if tests that uses Class::getInterfaces() are not written correctly, and sadly, a lot of tests are written that way. I'm

Re: Meeting today: IdentityObject

java.lang.Object; Rémi - Mail original - > De: "Remi Forax" > À: "valhalla-spec-experts" > Envoyé: Mercredi 5 Mai 2021 16:39:01 > Objet: Meeting today: IdentityClass > If it's possible, i would like to discuss about IdentityClass again. > > As note

<    1   2   3