Re: [External] : Re: On tearing

On 27 Apr 2022, at 9:50, Brian Goetz wrote: …This whole area seems extremely prone to wishful thinking; we hate the idea of making something slower than it could be, that we convince ourselves that “the user can reason about this.” Whether or not it is “too big a leap”, I think it is a bigge

Re: EG meeting, 2022-05-04

On 4 May 2022, at 11:36, Kevin Bourrillion wrote: >> - "Foo / Foo.ref is a backward default": Kevin and Brian argued that we >> should prefer treating B3 classes as reference-default, with something like >> '.val' to opt in to a primitive value type >> > > I will say that I have not personally fou

Re: [External] : Re: User model stacking

On 27 Apr 2022, at 16:12, Brian Goetz wrote: > We can divide the VM flattening strategy into three rough categories (would > you like some milk with your eclair?): > > - non-flat — use a pointer > - full-flat — inline the layout into the enclosing container, access with > narrow loads > - low

Re: Abstract class with fields implementing ValueObject

That could be one of very many edge conditions in the JVMS that are not diagnosed directly by a validation, but that will eventually cause an error when the broken classfile is further used. I don’t think there needs to be a special rule for this. We don’t try to comprehensively diagnose all “

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 for and methods. Answer: JVM doesn't care about methods in abstract classes, the rules about methods still uncertain. On the question of JVM validation of `` methods, I’m in favor of as f

Re: [External] : Re: VM model and aconst_init

On 25 Jan 2022, at 2:50, fo...@univ-mlv.fr wrote: Let's talk a bit about having the L world and the Q world completely disjoint at least from the bytecode verifier POV. Yes please; indeed, that is my strong recommendation. Doing this (`Q>:interpreter (as well as verifier) to concentrate one

Re: The interfaces IdentityObject and ValueObject must die !

On 26 Jan 2022, at 16:36, Dan Smith wrote: An instance of a class is also an instance of (and carries the properties of) its superclasses. Value objects are instances of the class Object. I can imagine a design in which we say that instances of Object may be either identity or value objects,

Re: The interfaces IdentityObject and ValueObject must die !

On 26 Jan 2022, at 16:55, Dan Smith wrote: On Jan 26, 2022, at 4:55 PM, John Rose wrote: Independently of that, for the specific case of Object , having a query function Class.instanceKind , which returns “NONE” for abstracts else “VALUE” or “IDENTITY”, would encode the same information

Re: The interfaces IdentityObject and ValueObject must die !

[Sorry disregard last content-free message. Still getting used to a new mail client.] On 26 Jan 2022, at 7:42, Dan Smith wrote: If we do not use interfaces, the runtime class of java.lang.Object can be Object, being an identity class or not is a just a bit in the reified class, not a compile

Re: The interfaces IdentityObject and ValueObject must die !

On 26 Jan 2022, at 7:42, Dan Smith wrote: On Jan 26, 2022, at 2:18 AM, fo...@univ-mlv.fr wrote: In other words: I don't see a use case for distinguishing between primitive and value classes with different interfaces. Primitive classes does not allow nulls and are

Re: The interfaces IdentityObject and ValueObject must die !

On 26 Jan 2022, at 7:42, Dan Smith wrote: > For me, it's like opening the door of your house to an elephant because it > has a nice hat and saying you will fix that with scotch-tape each time it > touches something. > > Ha. This sounds like maybe there's a French idiom involved, but anyway we >

Re: [External] : Re: VM model and aconst_init

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_init > >> The operand of C_Class is a weird beast. It can be an intern

Re: VM model and aconst_init

On 12 Jan 2022, at 5:14, fo...@univ-mlv.fr wrote: Ok, but in that case how the verifiers know if aconst_init generate a Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and not a descriptor as parameter. In the terms of my previous message, the `CONSTANT_Class` item in the CP

Re: VM model and aconst_init

I think (based on our most recent conversations) that `aconst_init` can return a Q-type for B3 types and an L-type for B2 types. And likewise for the input and output of `withfield`. The net result is that both bytecodes need to be permissive about L and Q types, because B2 and B3 translation st

Re: Terminology bikeshedding summary

#3 is more like: primitive value vs. bare object Or primitive value vs. [something else] object Where object is split not only into value object and identity objects, but bare (value) objects are another split. You get bare vs heap just as you get value vs identity as cleavage planes in the un

Re: Updated State of Valhalla documents

> On Jan 5, 2022, at 4:45 PM, Dan Smith wrote: > > Not talking about the VM. I'm talking about the language model. > >> A primitive (B3) does not provide proper encapsulation unlike a classical >> Java class (the one spelt "class" in the language), > > You should say "object" here, not "clas

Re: [External] : Re: Updated State of Valhalla documents

On 23 Dec 2021, at 11:26, fo...@univ-mlv.fr wrote: For "value", we know that we want value class and value record, so it's more like a modifier. For primitive, do we want a primitive record ? The VM supports it, but do we want to offer that possibility in Java ? My gut feeling is that the answe

Re: Updated State of Valhalla documents

On Dec 23, 2021, at 10:35 AM, Remi Forax wrote:  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!

Re: We have to talk about "primitive".

On 15 Dec 2021, at 10:42, Kevin Bourrillion wrote: … The main problem I think we can't escape is that we'll still need some word that means only the eight predefined types. (For the sake of argument let's assume we can pick one and lean hard on it, whether that's "predefined", "built-in", "e

Re: [External] : Re: We have to talk about "primitive".

On 15 Dec 2021, at 15:06, Brian Goetz wrote: It took us a while to unravel this one, but I think we did. … What this says is that tearing/non-tearing is a property of reference-vs-primitive-ness; accessing a (fat) value through a reference gives you *more guarantees* than accessing it directly

Re: [External] : Re: basic conceptual model

On 13 Dec 2021, at 19:05, Kevin Bourrillion wrote: > … > Yes, in general I am sure that I can't accomplish actual ground up > non-cyclical definition-definitions here. I think it should suffice to be > descriptive enough for the reader to course-correct their previous notions > in this direction (

Re: basic conceptual model

” in operations on units of data familiar to assembly programmers. They are indivisible units, but even more important, their operations are natural to real computers. On 13 Dec 2021, at 18:40, John Rose wrote: > I have some comments. Since the doc invites directly stuck-on comments, I

Re: basic conceptual model

I have some comments. Since the doc invites directly stuck-on comments, I’ve requested edit permission, as that seems necessary for me to stick on a comment. Some free-floating notes: Good use of “freely copyable” as a concept. There’s a tough case, happily not relevant to Java, of linear typ

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

On 9 Dec 2021, at 7:25, fo...@univ-mlv.fr wrote: We may do something like that in a possible future, but i think it's more important to make the semantics of B3 visible front and center. If you can only say one thing in such an explicit no-arg constructor (true initially and maybe forever) th

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

On Dec 8, 2021, at 11:12 PM, Remi Forax wrote: > > I fully agree, i think it's better to do the opposite I snapped a few neurons trying to read that the first time. > and force the fact that all primitive value classes (Bucket 3) must have a > default constructor and that constructor have a f

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

We have considered, at various points in the last six years or more, allowing user-defined primitive types to define (under user control) their own default values. The syntax is unimportant, but the concept is simple: Surely the user who defines a primitive type can also define default initia

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

On Dec 1, 2021, at 3:56 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: There is the converse problem that comes from the redundancy: What happens if the class directly implements or inherits ValueObject and ACC_VALUE is not set? I guess that is an error also. I hit send too soon:

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

On Dec 1, 2021, at 3:29 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: So we went down the path of "maybe there's no need for a flag at all" in today's meeting, and it might be worth more consideration, but I convinced myself that the ACC_VALUE flag serves a useful purpose for validation

Re: aconst_init

On Dec 1, 2021, at 7:58 AM, Dan Heidinga wrote: > > Splitting a new thread off from Dan's email about the jep draft to > talk about the `aconst_init` bytecode: > >> aconst_init, with a CONSTANT_Class operand, produces an instance of the >> named value class, with all fields set to their default

Re: JEP update: Value Objects

figure out exactly what we want these Primitives to be, relative to other concepts. Just a suggestion.) On Nov 29, 2021, at 10:53 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: Two points from me for the record: 1. I re-read the JEP draft now titled Value Objects, and liked everyt

Re: JEP update: Value Objects

Two points from me for the record: 1. I re-read the JEP draft now titled Value Objects, and liked everything I saw, including the new/old term “Value” replacing “Pure” and “Inline”. 2. In your mail, and in the companion JEP draft titled Primitive Objects, you refer to “primitive classes” and th

Re: [External] : Re: EG meeting, 2021-11-17

On Nov 22, 2021, at 5:13 PM, Dan Smith wrote: > >> On Nov 22, 2021, at 2:07 PM, Kevin Bourrillion wrote: >> >>> On Mon, Nov 22, 2021 at 6:27 AM Dan Heidinga wrote: >>> >>> I'll echo Brian's comment that I'd like to understand Kevin's use >>> cases better to see if there's something we're miss

Re: EG meeting, 2021-11-17

Thanks, Brian, for many useful suggestions about the diagram. I have updated it in place. Its message should be clearer now. On Nov 21, 2021, at 9:05 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: http://cr.openjdk.java.net/~jrose/values/type-kinds-venn.pdf

Re: identityless objects and the type hierarchy

On Nov 4, 2021, at 3:25 PM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: I don't think a second bifurcation is needed. At runtime bucket 2 and bucket 3 behave the same apart from null. Given that IdentitylessObject (or whatever the name we choose) is an interface, it always accept null, so if t

Re: [External] : Re: EG meeting, 2021-11-17

On Nov 19, 2021, at 5:32 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: And this is not inconsistent with abstract superclasses contributing fields. For me the poster child is Enum as much as Record. I want pure enums, some day, but in order to make this work we need a way for the ordin

Re: EG meeting, 2021-11-17

On Nov 18, 2021, at 2:58 PM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: I suppose you are talking about empty (no field) abstract classes. We need that for j.l.Object, j.l.Number or j.l.Record. From a user POV, it's not very different from an interface with default methods. Yes. The key thin

Re: EG meeting, 2021-11-17

Yes. One way I like to think about the Old Bucket is that it is characterized by *concrete* representations which have somehow opted into object identity. Confusingly, the Old Bucket also contains interfaces which are non-concrete and also Object, which might as well be non-concrete. (I’m not sa

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 4:05 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: (It is, I suppose, part of the model that objects of a given class all have a finite, matching layout when accessed by value, even if the details of that layout are kept abstract. Which is why value types are monomorp

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 11:34 AM, Brian Goetz wrote: > > There's lots of great stuff on subtyping in chapters 15 and 16 of TAPL (esp > 15.6, "Coercion semantics"), which might be helpful. But as a tl;dr, I would > suggest treating subtyping strictly as an is-a relation within our nominal > type sy

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 10:23 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: I think this fits neatly with the current design: `Point` has no supertypes*, not even `Object`, but `Point.ref` does. (*I mean "supertype" in the polymorphic sense, not the "has a conversion" sense or the "can in

Consequences of null for flattenable representations

As we just discussed in the EG, allowing null to co-exist with flattenable representations is a challenge. It is one we have in the past tried to avoid, but the very legitimate needs for (what we now call) reference semantics for all of Bucket 2 and some of Bucket 3 require us to give null a place

Re: [External] : Equality operator for identityless classes

One of the long standing fixtures in the ecosystem is the set of idioms for correct use of op==/acmp. Another is lots of articles and IDE checkers which detect other uses which are dubious. It’s a problem that you cannot use op==/acmp by itself in most cases; you have to accompany it by a call to

Re: [External] : Re: Consolidating the user model

On Nov 2, 2021, at 4:53 PM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: Actually, that makes me start to wonder if `getClass()` should be another method like `notify` that simply doesn't make sense to call on value types. (But we still need the two distinct Class instances per class an

Re: Consolidating the user model

On Nov 2, 2021, at 3:44 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: new X().getClass() == X.class Seems like part of the goal would be making it fit naturally with the current int/Integer relationship (of course, `42.getClass()` is uncommitted to any precedent). It seems lik

Re: Consolidating the user model

On Nov 2, 2021, at 3:44 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: Btw, am I right that for the middle bucket, `==` will fail (at compile-time when possible)? I don’t see how middle bucket references, which behave very much like old-bucket references (id-classes), would tend to fa

Re: Consolidating the user model

+100; great summary > On Nov 2, 2021, at 2:18 PM, Brian Goetz wrote: > > which means that the `L*` types might work out here. Stay tuned for more > details. A footnote, FTR, about L*-descriptors, in case it doesn’t ring a bell. Brian is referring here to the thing we have talked about sev

Re: Revisiting default values

> On Jul 1, 2021, at 5:48 AM, Brian Goetz wrote: > > >> >> Which reminds me: I think we should >> allow calls to methods on `this` inside a >> constructor. (Do we?) A clean way to >> statically exclude incomplete values of `this` >> would be to outlaw such self-calls until all >> final fie

Re: Revisiting default values

On Jun 29, 2021, at 2:36 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: Speaking of orthogonality, there *is* an open question about how we interpret , and this is orthogonal to the question of whether should be the "default default". We've talked about: - It's interchangeable with n

Re: [External] : Re: Revisiting default values

d the notion I cannot endure!” On Jun 30, 2021, at 5:16 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: Maybe, in some of these schemes, null is not a primitive, but boojums and boxes are the primitives, and null is a (safely) boxed boojum?

Re: [External] : Re: Revisiting default values

> On Jun 30, 2021, at 8:39 AM, Brian Goetz wrote: > > Now, let's talk more about null. Null is a *reference* that refers to no > object. For a flattened/direct object (P.val), null cannot be in the value > set (it's the wrong "kind"), though we can arrange for a primitive to behave > like n

Re: [External] : Re: Making Object abstract

On Jun 17, 2021, at 4:40 AM, Remi Forax mailto:fo...@univ-mlv.fr>> wrote: As a stretch move, I think we can even retro-upgrade the type checking of Objects::newIdentity with type variable trickery, when IdentityObject becomes real. Please see: https://bugs.openjdk.java.net/secure/attachment/951

Re: Making Object abstract

On Jun 2, 2021, at 7:57 AM, Brian Goetz wrote: > > A minor bikeshed comment: We're asking users to change their `new Object()` > to `IdentityObject.newIdentity()`, and they may ask "why do I have to say > 'Identity' twice"? (And by ask, I mean grumble, because we're already asking > them to c

Re: JEP draft: Universal Generics

On Jun 8, 2021, at 2:21 PM, Dan Smith wrote: > > Please see this JEP draft: > > http://openjdk.java.net/jeps/8261529 > > This is the third anticipated piece in our initial suite of Valhalla preview > features (along with JEPs 401 and 402). It's also the first step in the > revised generics st

Re: [External] : Re: consolidated VM notes for primitive classes

On Apr 27, 2021, at 7:27 AM, Peter Levart mailto:peter.lev...@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.

Re: [External] : Re: consolidated VM notes for primitive classes

On Apr 27, 2021, at 7:37 AM, Peter Levart mailto:peter.lev...@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 f

Re: [External] : Re: Parametric VM class file format

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-

Re: [External] : Re: Parametric VM class file format

On Apr 21, 2021, at 8:32 AM, fo...@univ-mlv.fr wrote: > > - Mail original - >> De: "John Rose" >> À: "Remi Forax" >> Cc: "valhalla-spec-experts" >> Envoyé: Mercredi 21 Avril 2021 08:43:34 >> Objet: Re: Parametric VM clas

consolidated VM notes for primitive classes

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/o

Re: Parametric VM class file format

On Apr 20, 2021, at 9:40 AM, Remi Forax 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 inde

Re: Parametric-vm spec / unused CONSTANT_Parameter is illegal

On Mar 10, 2021, at 1:59 PM, Remi Forax wrote: > > 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 i

Re: EG meeting, 2020-12-16

On Dec 16, 2020, at 11:00 AM, Dan Smith wrote: > > Rémi raised some questions about our story for int vs. Integer vs. legacy > uses of 'new Integer'—how many implementation classes are there? (should we > use species?); what does reflection look like? We agreed it still needs some > polishing.

Re: Inline Record vs JLS / Reflection

On Dec 16, 2020, at 12:39 PM, fo...@univ-mlv.fr wrote: > > De: "John Rose" > > The last is cleanest; the cost is resolving some technical > debt in Valhalla, which is allowing more kinds of supers > for primitive classes. There’s no firm reason, IMO, why > Reco

Re: Inline Record vs JLS / Reflection

On Dec 16, 2020, at 11:07 AM, Dan Smith wrote: > > I don't think we have a good answer right now, but it's something we will > want to address at some point. A solution would have to look like one of: > > - Ask clients (e.g., "is this a record?" code) to adapt to the presence of > the '$ref' c

Re: Using a Condy instead of a Constant_Utf8

On Dec 2, 2020, at 2:53 AM, Remi Forax wrote: > > There is one case where i dynamically patch a method descriptor so I can > select how many arguments will be sent to a closure, > i.e. in the bytecode i put all arguments on the stack but because i've > patched the callee descriptor, only some o

Re: Source code analysis: calls to wrapper class constructors

On Oct 28, 2020, at 1:05 PM, fo...@univ-mlv.fr wrote: > > I've never seen such bytecode shapes but I don't think i've ever seen a > classfile compiled with a version which was less that Java 1.2. …I’ve seen bytecode shapes, such bytecode shapes as would freeze the marrow. It was dark and rainy,

Re: Source code analysis: calls to wrapper class constructors

On Oct 28, 2020, at 2:32 PM, John Rose wrote: > > invokestatic Integer.$pop2$valueOf(Object,int)V That would be invokestatic Integer.$pop2$valueOf(String,int,String)V And the dummy object could be an Integer (using a condy) if we don’t want to edit the stack maps that might mention the I

Re: Source code analysis: calls to wrapper class constructors

On Oct 28, 2020, at 10:49 AM, Dan Smith wrote: > > You're right that this disrupts verification; I think we can address this > pre-verification by rewriting the StackMapTable, eliminating all references > to 'uninitialized(Offset)' and shrinking the stack by two. Or we can try to keep the veri

Re: Source code analysis: calls to wrapper class constructors

locals during expression evaluation is if there is some kind of complicated control flow inside the expression. Different javac’s historically have different policies about stuff like that. > On Oct 28, 2020, at 4:25 AM, Remi Forax wrote: > > - Mail original - >> De: &q

Re: Source code analysis: calls to wrapper class constructors

On Oct 27, 2020, at 12:27 PM, Dan Smith wrote: > > This tooling will support common bytecode patterns like 'new Foo; dup; ...; > invokespecial Foo.;', but will not be a comprehensive solution. > (Mimicking the behavior of instance initialization method invocation in full > generality would be

Re: Source code analysis: calls to wrapper class constructors

On Oct 27, 2020, at 1:36 PM, Dan Smith wrote: > > I'm not sure whether there's a mechanism in HotSpot to generate warnings > about deprecated APIs at link/run time. It does seem like it would be a > reasonable feature... +1 There is no such feature at present; maybe something could be built o

Re: no good default issue

On Jul 31, 2020, at 12:41 PM, Brian Goetz wrote: > > As far as I can tell what you're suggesting, it is that, when we detect a > field is not initialized, we initialize it for you with some sort of default. > But that brings us back to the main problem: what if the class _has no good > defaul

Re: access control for withfield bytecode, compared to putfield

+1 > On Jun 8, 2020, at 4:29 PM, Dan Smith wrote: > >  >> >> On Apr 8, 2020, at 11:29 PM, John Rose wrote: >> >> To summarize: The simplest rule for access checking a >> withfield instruction is to say, “pretend the field was >> declared priva

Re: The fate of int, int.ref, and Integer

On Jun 5, 2020, at 5:43 AM, Brian Goetz wrote: > > The move of saying `Integer` *is* `int.ref` makes these problems go away. > This seems too good to pass up preemptively. I agree. And this leads us into a maze of twisty passages. Full of uninsulated electrified wires and third rails to avoid

Re: The fate of int, int.ref, and Integer

On Jun 4, 2020, at 7:00 PM, Kevin Bourrillion wrote: > > Hello friends, > > A couple thoughts on the fate of the primitives and wrappers. > > First, on nomenclature, I think the most useful definitions of what it means > to be an "inline type" are those that reveal the primitives to already be

Re: Valhalla basic concepts / terminology

I like this discussion! Smart questions and solid answers all the way through. Weaving in my $0.02… On May 22, 2020, at 12:36 PM, Brian Goetz wrote: > > Hi Kevin! >> >> • There are two kinds of objects/instances; the notions "object" and >> "instance" apply equally to both kinds. These

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 10, 2020, at 4:19 AM, fo...@univ-mlv.fr wrote: > >> So, here’s a recommendation: Use indy, and use a clunkier >> fallback in the same places that today use a clunkier fallback >> for string concatenation. And, record a line item of technical >> debt that we should further explore indy int

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 2:31 PM, fo...@univ-mlv.fr wrote: > > yes, indy is a way to create any new bytecode, but it also has some > restrictions, > the major one being that you can not using it before it has been bootstrapped. Good point; we found that with string concatenation, didn’t we? If we use

Re: IdentityObject and InlineObject

On Apr 8, 2020, at 9:54 AM, Brian Goetz wrote: > > This is a good time to review the motivations for Identity/InlineObject, and > see if there's anything we want to tweak about it. > > There are two main branches of the motivation here: pedagogical and > functional. > > Pedagogically, we'

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 2:07 PM, John Rose wrote: > > Perhaps we want another (intrinsically optimized) version > of Objects::requireNonNull, which takes a second argument > that assists in generating a better diagnostic. (D’oh; there it stands in the the JDK already.)

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 1:58 PM, Remi Forax wrote: > > I don't fully understand why not using checkcast because from the user POV > the message will be better than just NPE. When today I try unbox an Integer but encounter a null, my experience is “NPE” rather than a more informative “failed to unbox

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 1:20 PM, John Rose wrote: > > No specs were harmed in making this proposal. P.P.S. Although there’s no precedent yet for it except static code rewriters, we could also intrinsify certain indy instructions in the same way, as early as the interpreter. Then we’

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 1:16 PM, John Rose wrote: > > On Apr 9, 2020, at 1:03 PM, Brian Goetz wrote: >> >> >>> I have a proposal for a translation strategy: >> >> Casts to inline classes from their reference projections will be frequent. >> Because

Re: null checks vs. class resolution, and translation strategy for casts

On Apr 9, 2020, at 1:03 PM, Brian Goetz wrote: > > >> I have a proposal for a translation strategy: > > Casts to inline classes from their reference projections will be frequent. > Because the reference projection is sealed to permit only the value > projection, a cast is morally equivalent

Re: null checks vs. class resolution, and translation strategy for casts

Correction… The recommended reflective approach has a flaw (easily fixed), which makes indy my real recommendation. On Apr 8, 2020, at 11:43 AM, John Rose wrote: > … > I have a proposal for a translation strategy: > > 1. Translate casts to inline classes differently from “clas

access control for withfield bytecode, compared to putfield

In the Java language fields can be final or not, and independently can be access controlled at one of four levels of access: public, protected, package, and private. Final fields cannot be written to except under very narrow circumstances: (a) In an initialization block (static initializer or co

ClassValue performance model and Record::toString

This note is prompted by work in a parallel project, Amber, on the implementation record types, but is properly a JVM question about JSR 292 functionality. Since we’ve got a quorum of experts here, and since we briefly raised the topic this morning on a Zoom chat, I’ll raise the question here of C

null checks vs. class resolution, and translation strategy for casts

The latest translation strategies for inline classes involve two classfiles, one for the actual inline class C and one for its reference projection N. The reference projection N exists to provide a name for the type “C or null”. As we all know on this list, this is a surprisingly pleasant way to

Re: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

On Mar 7, 2020, at 2:22 PM, fo...@univ-mlv.fr wrote: > > Marker interface are usually problematic because: > - they can inherited, for inline classes, you can put them on our new kind of > abstract class, which will make things just harder to diagnose. As always the flexibility of inheritance cu

Re: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

On Mar 7, 2020, at 1:41 PM, Remi Forax wrote: > > [Moving to valhalla-spec-experts] > > - Mail original ----- >> De: "John Rose" >> À: "Tobias Hartmann" >> Cc: "valhalla-dev" >> Envoyé: Vendredi 21 Février 2020 11:23:

Re: Reference-default style

be “abstract all the way up.” > > Sent from my iPad > >> On Feb 9, 2020, at 1:08 AM, John Rose wrote: >> >>> On Feb 8, 2020, at 9:08 PM, Dan Smith wrote: >>> >>> Oh, yeah, if we need to make sure that code gets executed (for identity >

Re: Reference-default style

On Feb 8, 2020, at 9:08 PM, Dan Smith wrote: > > Oh, yeah, if we need to make sure that code gets executed (for identity > classes), that will affect the design. That’s the root of the stuff you found perhaps unnecessary. It could be done the way you propose also, but adding the ability of the

Re: Reference-default style

So, unless someone else comes up with something surprising, I think we know enough to prototype vigorously on your proposal, Brian. (Brian would say, “why don’t we run with this for now”.) My queasiness about hollowing out C.val will either gain some practical shape from experience in prototyping

Re: Reference-default style

On Feb 7, 2020, at 3:39 PM, Brian Goetz wrote: > > >> (To remind everyone: We are using two half-buckets rather than one bucket >> mainly so that Optional can be migrated. If it were just supporting V? then >> we’d use an empty marker type, I think, probably just an interface.) > > The two ha

Re: Reference-default style

(Replying second to your first.) On Feb 7, 2020, at 9:34 AM, Brian Goetz wrote: > > I want to combine this discussion with the question about whether inline > classes can extend abstract classes, and with the "reference projection" > story in general. Thanks for your “John would say…”; I’ll

Re: Reference-default style

On Feb 7, 2020, at 2:39 PM, Dan Smith wrote: > >> On Feb 7, 2020, at 3:05 PM, Brian Goetz wrote: >> >> - Supertypes, methods (including static methods, and including the static >> "constructor" factory), and static fields are lifted onto the ref projection. > > This deserves highlighting: in

Re: Reference-default style

On Feb 7, 2020, at 2:05 PM, Brian Goetz wrote: >> >> So, summary: >> >> - Yes, we should figure out how to support abstract class supertypes of >> inline classes, if only at the VM level; >> - There should be one way to declare an inline class, with a modifier >> saying which projection gets

Re: atomicity for value types

On Jan 14, 2020, at 4:52 PM, Remi Forax wrote: > > In the context of Java, we are already using the term 'atomic', in > AtomicInteger, AtomicLong, etc, Even more fundamentally, the term “atomic” is in the JLS, JVMS, and JMM with the same meaning being proposed here, and *not* subsumed by nor id

Re: atomicity for value types

On Dec 18, 2019, at 5:46 PM, John Rose wrote: > > - Define a contextual keyword “alwaysatomic" (working title “__AlwaysAtomic”). I just referred more carefully to the draft JEP on keyword management https://openjdk.java.net/jeps/8223002 and realize that it guides us toward

Re: atomicity for value types

On Jan 14, 2020, at 9:11 AM, Doug Lea wrote: > > On 1/13/20 4:44 PM, Tobi Ajila wrote: >> Hi John >> >> Given that inline types can be flattened there is a possibility that >> data races will occur in places where users were not expecting it >> before. So your `__AlwaysAtomic` modifier is a nece

Re: atomicity for value types

On Jan 13, 2020, at 1:44 PM, Tobi Ajila wrote: > > Hi John > > Given that inline types can be flattened there is a possibility that data > races will occur in places where users were not expecting it before. So your > `__AlwaysAtomic` modifier is a necessary tool as the existing spec will only

  1   2   3   4   >