> 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 the
> 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 probabl
- 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
>>
> 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 (o
> 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", wh
> 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 classes
- 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.
>
> Identity-freed
> 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 have
- 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 & __zero-ok
- 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 defe
> 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.
> (Please,
> 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 th
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
> 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 `
> 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 APIs
> 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;
>>> introducing
> 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
> 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 letters
> 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: [
> https://docs.google.com/document/d/1J
- 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 Object().hasIde
> 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 < [ mailto:daniel.sm...@o
- 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 i
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
has
- 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.
- 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
> d
> 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 f
- 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
- 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 with
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 wor
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
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 ne
- 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
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 cl
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Thursday, December 23, 2021 6:14:43 PM
> Subject: Updated State of Valhalla documents
> Just in time for Christmas, the latest State of Valhalla is available!
> [
> https://openjdk.java.net/projects/valhalla/design-notes/state-of-valha
Brian,
the last time we talked about IdentityObject and ValueObject, you said that you
were aware that introducing those interfaces will break some existing codes,
but you wanted to know if it was a lot of codes or not.
So i do not understand now why you want to mix IdentityObject/ValueObject
> From: "Kevin Bourrillion"
> To: "valhalla-spec-experts"
> Sent: Mercredi 15 Décembre 2021 19:42:55
> Subject: We have to talk about "primitive".
> (Okay, so we're doing this)
> I think the rename to "primitive classes" happened during my outage last year.
> When I came back I made the decision
> 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,
> 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 ] > w
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 begin
> From: "Brian Goetz"
> To: "Kevin Bourrillion"
> Cc: "Dan Heidinga" , "daniel smith"
> , "valhalla-spec-experts"
>
> Sent: Jeudi 18 Novembre 2021 23:34:51
> Subject: Re: EG meeting, 2021-11-17
> I think it is reasonable to consider allowing bucket two classes to be
> abstract.
> They could be
> From: "John Rose"
> To: "daniel smith"
> Cc: "Kevin Bourrillion" , "Brian Goetz"
> , "valhalla-spec-experts"
>
> Sent: Jeudi 4 Novembre 2021 02:34:52
> Subject: Re: [External] : Re: Consolidating the user model
> On Nov 3, 2021, at 4:05 PM, Dan Smith < [ mailto:daniel.sm...@oracle.com |
> dan
> From: "Kevin Bourrillion"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Sent: Jeudi 4 Novembre 2021 22:34:54
> Subject: Re: identityless objects and the type hierarchy
> On Wed, Nov 3, 2021 at 12:43 PM Brian Goetz < [ mailto:brian.go...@oracle.com
> |
> brian.go...@oracle.com ] > wrote
I really like this, it's far better than how i was seeing Valhalla, pushing
.ref into a corner is a good move.
I still hope that moving from B1 to B2 can be almost backward compatible, if no
direct access to the constructor, no synchronized and reasonable uses of ==.
My only concern now is th
I've sent a mail about considering all primitive types as always nullable on
stack (as parameters or local variables).
Rémi
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mercredi 20 Octobre 2021 16:03:12
> Subject: EG meeting *canceled*, 2021-10-20
On October 6, 2021 10:07:09 AM UTC, Maurizio Cimadamore
wrote:
>
>On 06/10/2021 10:56, Remi Forax wrote:
>>> - Existing class types like LocalDate are both nullable and atomic. These
>>> are
>>> useful properties to preserve during migration; nullability, in
Sadly, i will not be able to attend this meeting :(
regards,
Rémi
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mercredi 6 Octobre 2021 00:52:20
> Subject: EG meeting, 2021-10-06
> EG Zoom meeting tomorrow, Wednesday October 6, at 4pm UTC (9am PDT, 1
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mardi 5 Octobre 2021 01:34:37
> Subject: Addressing the full range of use cases
> When we talk about use cases for Valhalla, we've often considered a very broad
> set of class abstractions that represent im
- Original Message -
> From: "Brian Goetz"
> To: "daniel smith" , "Dan Heidinga"
>
> Cc: "valhalla-spec-experts"
> Sent: Vendredi 10 Septembre 2021 20:25:50
> Subject: Re: Factory methods & the language model
>> I'm not particularly interested in settling on a bikeshed color, but am
>>
I will take the scenic road to answer :)
There is currently an issue with the fact that we present primitive class as
constructor in Java the language but is translated not to a constructor in the
class file.
This introduce a false sense of compatibility, the code is identical if it's a
classic
- 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 to
> 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 explore
- 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
>> additio
> 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. (Th
- 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
- 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:
>>
>> http://openjdk.java.n
> 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
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
abs
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
- 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": Updat
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 guilt
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)
I wonder if the ParameterBinding should not have kind of name or at least a
textual representation so you can see them in stacktraces,
it will be really helpful for debugging.
Rémi
In the sub-section "other upcalls",
for type-testing, the VM does an upcall to the method "isAssignableFrom" of the
Species but it's not clear for me how a user can creates such "Species" given
that it seems that the way to configure a species is to return a
ParameterBinding properly configured.
Hi all,
slowly reading the Parametric-vm spec.
With my ASM hat,
"As a structural constraint, it is illegal for a CONSTANT_Parameter constant to
be unused."
This is different of all other CONSTANTs and doesn't work well with the idea
that you can patch a classfile by copying the existing constan
cool !
Rémi
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 10 Mars 2021 17:12:46
> Objet: EG meeting, 2021-03-10
> The next EG Zoom meeting is today at 5pm UTC (9am PST, 12pm EST).
>
> No new email threads, but John would like to spend some time
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 java.lang.Record
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 stanc
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
- 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 tal
- Mail original -
> De: "John Rose"
> À: "daniel smith"
> Cc: "valhalla-spec-experts"
> Envoyé: Mercredi 28 Octobre 2020 05:56:29
> Objet: Re: Source code analysis: calls to wrapper class constructors
> On Oct 27, 2020, at 12:27 PM, Dan Smith wrote:
>>
>> This tooling will support com
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mardi 27 Octobre 2020 20:27:39
> Objet: Re: Source code analysis: calls to wrapper class constructors
>> On Oct 19, 2020, at 6:01 PM, Dan Smith wrote:
>>
>> In the context of the Warnings for Value-Based Clas
RestrictedField ?
https://bugs.openjdk.java.net/browse/JDK-8254022
Rémi
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 7 Octobre 2020 16:28:55
> Objet: EG meeting, 2020-10-07
> The next EG Zoom meeting is today at 4pm UTC (9am PDT, 12pm EDT).
>
I'm fine with that change.
For me, it's more where you put the emphasis
- how it behaves on stack, it behavse like a primitive type ,the "pass by
value" Dan is talking about
- how it behaves on heap, it behaves by inlining itdelf in its container.
So they are a primitive inlining class :)
I will still be on the road :)
following the JEP draft, I wonder if all functional interfaces (at least the
ones tagged with @FunctionalInterface) should also be considered as inline
candidates, so synchronizing on them should report a warning too.
the other question is how to declare your own
- Mail original -
> De: "Brian Goetz"
> À: "John Rose"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 1 Août 2020 16:41:11
> Objet: Re: no good default issue
>> Personally, I view such tactics as possible but expensive,
>> and would like to try to get by without JVM support for
>> them,
So the default value may a valid value or may be an invalid value,
if it's an invalid value it should be the author of the class that say that
because in Java we prefer declaration site to use site.
One way is to try to teach the VM how to do the conversions, i want to explore
another way where
>From valhalla-spec-observers,
- Mail original -
> De: "Gernot Neppert"
> À: "Valhalla Expert Group Observers"
>
> Envoyé: Vendredi 10 Juillet 2020 12:06:32
> Objet: Clarification needed about primitive wrappers?
> Hello,
>
> it seems some clarification is needed about the fate of the
> De: "Brian Goetz"
> À: "Tobi Ajila"
> Cc: "valhalla-spec-experts" ,
> "valhalla-spec-experts"
> Envoyé: Vendredi 19 Juin 2020 20:18:09
> Objet: Re: Evolving the wrapper classes
> Zooming out, what we've been trying to do is shake out the places where the
> JVM
> treats primitives and referen
- Mail original -
> De: "Frederic Parain"
> À: "valhalla-spec-experts"
> Envoyé: Lundi 13 Avril 2020 15:24:18
> Objet: Re: null checks vs. class resolution, and translation strategy for
> casts
>> On Apr 8, 2020, at 14:43, John Rose wrote:
>>
>> I have a proposal for a translation str
I don't fully understand why not using checkcast because from the user POV the
message will be better than just NPE.
Rémi
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Jeudi 9 Avril 2020 22:16:06
> Objet: Re: null checks vs. class resol
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Vendredi 27 Mars 2020 20:59:38
> Objet: Updated SoV documents
> I've updated the SoV documents, including the new sections on VM model and
> translation:
> [ http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html |
> htt
Hi,
currently a record can only be an IdentityObject but at some point, we want to
introduce an inline record ?
Now the question: What the subtyping relation between java.lang.Record and
InlineObject/IdentityObject ?
An identity record (resp. an inline record) should be a subtype of both
java.
[Moving to valhalla-spec-experts]
- Mail original -
> De: "John Rose"
> À: "Tobias Hartmann"
> Cc: "valhalla-dev"
> Envoyé: Vendredi 21 Février 2020 11:23:14
> Objet: Re: for review: 8236522: "always atomic" modifier for inline classes
> to enforce atomicity
> I’ve come back around to
> 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
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, peop
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
It occurs to me that we may have jump into the conclusion that we should use
inheritance/implementation a little to fast.
At least, i think it worth exploring another complementary option.
In Java, you have several ways to have subtyping,
saying a FooInline is a subclass FooInline.ref is one way,
- Mail original -
> De: "Brian Goetz"
> À: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
>
> Envoyé: Lundi 16 Décembre 2019 15:27:59
> Objet: Re: Lifting operations from inline classes to reference projections
>>
>> I'm not too worried about having a V.ref with its own members - aft
Hi Brian,
really nice write-up.
I've not a lot to say apart about IdentityObject and InlineObject because I
fully agree on the major points (and i've promised to not tak about == but wait
and see instead).
As we briefly talk last Wednesday, i believe there is a less disruptive way to
add Identi
sorry wrong list.
Rémi
- Mail original -
> De: "Remi Forax"
> À: "valhalla-spec-experts"
> Envoyé: Dimanche 1 Septembre 2019 17:27:13
> Objet: Record classfile and runtime API
> Hi all,
> i think the current generated classfile bytecodes can be i
Hi all,
i think the current generated classfile bytecodes can be improved.
For a record Point(int x, int y) { }
The classfile contains:
- a specific class attribute Record
Record:
int x;
descriptor: I
int y;
descriptor: I
which allows compiler separate compilatio
I think we should take a step back on that subject,
because you are all jumping to the conclusion too fast in my opinion.
Let starts by the beginning,
the question about supporting == on inline type should first be guided by what
we should have decided if inline types were present from the incept
> De: "Brian Goetz"
> À: "Frederic Parain"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 6 Août 2019 18:50:26
> Objet: Re: Collapsing the requirements
>> So, legal signatures will be:
>> - QV;
>> - LI;
>> and that’s it, right?
>> Q will continue to have its current semantic (flattenable, non-n
- Mail original -
> De: "Remi Forax"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 3 Août 2019 19:48:01
> Objet: Re: Collapsing the requirements
> - Mail original -
>> De: "Brian Goetz"
>&
- Mail original -
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Samedi 3 Août 2019 18:37:56
> Objet: Collapsing the requirements
> As Remi noted, we had some good discussions at JVMLS this week. Combining
> that
> with some discussions John and I have been having over the
Hi all,
We (Maurizio, John and i) have spent some time to play with another proposal of
what LW10 can be based on the "confinent" idea i.e. an inine type can not
appear in a public API and you need an interface to use it in erased generics.
So the idea is to have at Java language level a constr
Hi all, here is my takeaway of the valhalla face to face meeting we had
yesterday.
On the VM side, the model can be simplified by having all classes being either
a Q-type or a L-type but not both at the same time. This will simplify the JVMS
and solve the naming issue i have with Dan because th
Hi Daniel,
section 4.1: in the table 4.1-A,
13/57/45..57 is missing given you talk about later in this section.
section 4.3.2:
I don't think that using null as a diferentiator (Nullable/NonNullable) is a
good idea.
Yes, an inline type is not nullable, but it's also flattenable, loaded early
Let's say i have this interface:
interface Orderable> {
boolean lessThan(T t);
}
and i want my inline class to implement it:
@__inline__ class FooOrderable implements Orderable {
...
@Override
public boolean lessThan(FooOrderable? foo) {
return false;
}
}
how i'm
I would like to propose an alternative to the V? syntax we are currently using
for representing an inline class encoded as a L-type.
I propose to use Coffer instead of Complex? (with Complex an inline
class).
as notice several of us, the V? syntax as several shortcoming:
- as Brian said, using
1 - 100 of 190 matches
Mail list logo
