Re: Equality

On Dec 21, 2015, at 8:50 AM, Doug Lea wrote: > > On 12/19/2015 05:20 PM, Brian Goetz wrote: > >>> Right. I agree that the signature must compatibly change, >>> but not necessarily that anything else does. >> >> OK, we're on the same page. > > Where I think this page says that interfaces with e

Re: 64 bit collections, and API migration in general (was Re: Migrating methods in Collections)

On Dec 18, 2015, at 8:55 AM, Brian Goetz wrote: > >> 2. It seems irresponsible to spend so much effort on >> Collections without also somehow addressing 32bit size/index >> limitations. Yes? Yes it would be, and we are aware of this question, and expecting to address it later in the light of pri

Re: Nestmates

On Jan 22, 2016, at 1:03 AM, Peter Levart wrote: > > a symmetric configuration where each nest-mate lists all nest-mates in a > single Nest attribute That uses storage quadratic in the number of nestmates. A big price for beauty! Better to go with transitive closure on a graph (linear storage)

Re: Nestmates

On Jan 21, 2016, at 3:10 PM, Vlad Ureche wrote: > > Thank you for sharing these insights Brian! > > I think I understand the problem and the solution, but let me ask three > questions to make sure I understood well: > > 1) The NestTop attribute must contain the child classes (except > special

Re: Nestmates

On Jan 28, 2016, at 8:06 AM, Eric Lippert wrote: > > Later versions generated a private bridge method in Bravo that called > Alpha.Echo and then had the generated closure invoke that helper method. FTR here's the a version of Eric's example, coded with lambdas and then with inner classes. Some

Re: Nestmates

On Jan 31, 2016, at 11:52 PM, Brian Goetz wrote: > >> First, I think it might make sense to share the use cases we have for >> nestmates in Kotlin (those that will work out): >> - same as Java: nested/inner classes >> - multi-file classes (this is how we emulate free functions that are >> logic

Re: Nestmates

On Feb 13, 2016, at 7:24 AM, Brian Goetz wrote: > > > On 2/12/2016 5:04 PM, Bjorn B Vardal wrote: >> • The Top<->Child handshake only needs to happen when the Child is >> loaded (which will load Top as a dependency), and access request from Child1 >> to Child2 is reduced to Child1->nestTo

Re: Nestmates

load. It would be a faster indication of a bug in the compile-time logic, which had fouled the nest. > On Feb 16, 2016, at 3:30 PM, John Rose wrote: > > On Feb 13, 2016, at 7:24 AM, Brian Goetz <mailto:brian.go...@oracle.com>> wrote: >> >> >> On 2/1

Re: Nestmates

On Feb 17, 2016, at 12:15 PM, Peter Levart wrote: > > Suppose javac generates a random nest id for each nest (say 128 bit UUID). > Two classes are nest-mates if they belong to the same module *and* share the > same nest id. There are two parts to this proposal: 1. New naming convention for ne

Re: Model 3 classfile design document

The full display of type variables, with all their definition sites, strikes me as clunky, from a VM perspective. It's a large amount of AST info. For inner classes, we flatten up level references by introducing synthetic variables and fields. In a few places core reflection needs an attribute

Re: Value types questions & comments

On May 2, 2016, at 4:34 PM, Kevin Bourrillion wrote: > … > On Mon, Apr 11, 2016 at 4:13 PM, Brian Goetz > wrote: > > For example, I see no reason why `int` can’t implement Comparable or > Serializable ... > > We might even take this further — by actually describi

Re: Value types questions & comments

On Apr 12, 2016, at 1:51 PM, Brian Goetz wrote: > >> >> Using a value type for something that isn't a value raises alarm bells for >> me. At the minimum I would expect this user to have to implement eq/hc by >> hand, because the default behavior users want 99% of the time is (deep) >> content

Re: Value equality (was: Value types questions and comments)

On May 16, 2016, at 8:29 PM, Kevin Bourrillion wrote: > > And by "deep equals" I mean equivalent behavior to > > https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#deepEquals-java.lang.Object:A-java.lang.Object:A- > >

Re: Value equality

On May 17, 2016, at 12:20 PM, Peter Levart wrote: > > Hi, > > I think that, to avoid confusion, there should be no special treatment of > arrays. They should be treated as any other reference. Why? > > Reason #1: To me, your reason #1 boils down to saying that special treatment of arrays req

Re: Value equality

On May 16, 2016, at 11:20 AM, Brian Goetz wrote: > > We have two choices in front of us regarding equality on value types: > > 1. What does `==` on values do? Choices include a bitwise comparison, a > componentwise comparision (identical to bitwise unless there are float > members), or invok

Re: Value equality

On May 18, 2016, at 7:57 AM, Brian Goetz wrote: > > [1] John points out that if == is CE, then (a==b||a.equals(b)) will > redundantly load the fields on failed ==. But, many equals implementations > start with "a==b" as a short-circuiting optimization, which means "a==b" will > be a common (p

minimal value types proposal

} span.smaller { font-size: 95%; } # Minimal Value Types August 2016: Shady Edition John Rose, Brian Goetz _"What we do in the shadows reveals our true values."_ ## Background In the two years since the [first public proposal [values]][values] there have been [vigorous

Re: minimal value types proposal

On Aug 29, 2016, at 4:17 PM, Dan Smith wrote: > > Some high-level feedback from me: > > I think the idea is reasonable. In other circles, we might call this a > "milestone". Should we define a first milestone that we're willing to commit > to strongly, with some sort of distribution channel (s

Re: minimal value types proposal

On Aug 30, 2016, at 10:56 AM, Dan Smith wrote: > >> On Aug 29, 2016, at 6:04 PM, John Rose wrote: >> ... >> For the user, a boxed representation is needed for basic debuggability. >> What does println or JVMTI do unless there's a box? > > One option is

Re: minimal value types proposal

> >> On Aug 31, 2016, at 6:14 PM, John Rose wrote: >> >>> It's a given that you have statics (see your Int128 declaration, for >>> example). If instance methods are practically free after that, fine. But if >>> not, there's no particular re

Re: minimal value types proposal

P.S. A couple of paragraphs were sent broken. Here are the fixes. On Aug 31, 2016, at 5:14 PM, John Rose wrote: > > The fields are wrapped in a primitive value struct with no > methods. That struct can be be referred to by Q-types > (including bytecode descriptors but not

Re: minimal value types proposal

I have updated of this document to reflect comments so far. It is stored to CR (in place) and enclosed here. — John Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html Title: Minimal Value Types (Shady Edition) Minimal Value Types August 2016: Shady Edition John Rose

Re: minimal value types proposal

On Aug 31, 2016, at 11:59 PM, John Rose wrote: > > I have updated of this document to reflect comments so far. > It is stored to CR (in place) and enclosed here. > — John > > Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html > > I have updated the d

Re: Value Type on stack in the interpreter

On Mar 31, 2017, at 8:57 AM, Remi Forax wrote: > > I've some trouble to see how value types are laid on stack (conceptually, not > necessary the real implementation). > > First, i may be wrong but it seems that vload do not reference the > corresponding Q-type, so i wonder how the verifier kno

Re: Value Type on stack in the interpreter

On Mar 31, 2017, at 4:30 PM, fo...@univ-mlv.fr wrote: > > - Mail original - >> De: "John Rose" >> À: "Rémi Forax" >> Cc: valhalla-spec-experts@openjdk.java.net >> Envoyé: Samedi 1 Avril 2017 01:06:07 >> Objet: Re: Value Type on st

Re: Value Type on stack in the interpreter

On Mar 31, 2017, at 5:00 PM, John Rose wrote: > > There are two choices: 1. store the type metadata in the carrier (on stack > and in local), > or 2. reaffirm the type metadata at every use site (not just vload/vstore). > #1 allows > simpler bytecodes which put less load o

Re: Valhalla Minimal Value Types review invitation

inimal Edition (v. 0.3) John Rose, Brian Goetz “What we do in the shadows reveals our true values.” Background In the three years since the first public proposal [values] of value types, there have been vigorous discussions [valhalla-dev] of how to get there, and vigorous prototyping in the Ja

Re: Draft JVMS changes for Nestmates

On Apr 18, 2017, at 11:58 AM, Brian Goetz wrote: > > Minimal candidate: > >class Nest { >Class hostClass() { ... } >boolean isMember(Class clazz) { } >} > >class Class { > Nest getNest() { ... } >} Or just: class Class { Class getNestHost(); // =

Re: Draft JVMS changes for Nestmates

On Apr 18, 2017, at 1:49 PM, Dan Smith wrote: > > >> On Apr 18, 2017, at 2:12 PM, Remi Forax > > wrote: >> Verification of MemberOfNest I include a discussion block about different options of validating MemberOfNest. I think the consensus, an

Re: Draft JVMS changes for Nestmates

On Apr 18, 2017, at 11:42 AM, Dan Smith wrote: > > Hi, all. > > I've uploaded a draft of JVMS changes for JEP 181 "Align JVM Checks with Java > Language Rules for Nested Classes" to: > http://cr.openjdk.java.net/~dlsmith/private-access.html Nice. More comments on that later. > Some comments

Re: Draft JVMS changes for Nestmates

On Apr 19, 2017, at 12:14 AM, David Holmes wrote: > > Some of these are a lot more awkward to do during classfile parsing and will > require symbol comparisons. I was wanting to avoid "deep validation" of NMs > as it penalizes all the good code. Having a "bad" NM entry seems harmless as > thes

Re: Draft JVMS changes for Nestmates

On Apr 19, 2017, at 9:47 AM, Dan Smith wrote: > > Something like "AllowedInNest" would better convey the actual meaning of that > attribute. It's true that this is what the attribute does, which is a plus. But it also is less directional than NMs. (Am I claiming I am allowed in some nest or am

Re: Draft JVMS changes for Nestmates

On Apr 19, 2017, at 2:10 PM, David Holmes wrote: > > I find these names very good - granted I've been working with them more than > anyone else (but didn't define them). The plurality makes it clear to me. +1 for plurality; that does it for me too, although it is a one-letter hint. I'm happy w

Re: Draft JVMS changes for Nestmates

On Apr 19, 2017, at 12:56 AM, David Holmes wrote: > >> I don't see how that is a significant concern. The symbol bodies are >> hot in cache >> at the point we would check prefixes, since they are already being >> scanned for other >> purposes, such as initial interning, and also syntax checking.

Re: Draft JVMS changes for Nestmates

On Apr 18, 2017, at 11:40 PM, David Holmes wrote: > > I have not yet seen a follow up from John as to whether we require or just > allow, an empty NestMembers attribute to indicate a singleton nest member. I think we should neither require nor allow an empty NestMembers attribute. Dan may pref

Re: Draft JVMS changes for Nestmates

On Apr 18, 2017, at 11:40 PM, David Holmes wrote: > > 4.7.26 The MemberOfNest Attribute > > "the class is implicitly a member of its own nest" > > I suggest changing "a" to "the sole". Otherwise "a" implies there may be > other members. As these are static properties being defined I don't thin

Nestmate same-package check

On Apr 18, 2017, at 11:42 AM, Dan Smith wrote: > I've uploaded a draft of JVMS changes for JEP 181 "Align JVM Checks with Java > Language Rules for Nested Classes" to: > http://cr.openjdk.java.net/~dlsmith/private-access.html > > classH

Re: Nestmate same-package check

On Apr 19, 2017, at 7:46 PM, Brian Goetz wrote: > > >> The way I visualize this is that each newly arrived class >> checks in with its host. If the name is on the list, it gets in. >> > > Right, and if it's not on the list? Does it get assigned its own > nest-of-one, or do we reject the cla

Re: Valhalla Minimal Value Types review invitation

On Apr 19, 2017, at 8:16 AM, Bjorn B Vardal wrote: > > I'm writing up my notes from the meeting, and I have a question about the > box's no-arg constructor. My notes say that this constructor is > automatically provided and may not be replaced by the user. My understanding > is that this is d

Re: Valhalla Minimal Value Types review invitation

(Note to Oracle people: This is a duplicate of my message on an internal list!) I have rolled most of the effect of these comments into the Shady doc also. (Below I say that vunbox doesn't belong on the same list with vdefault, but I changed the presentation again in the Shady doc, of vunbox. It

updates for May 10 meeting

ototype - simplify reflection:  no sourceClass, VCC does everything as a POJO - reminder: all this will change - under "more bytecodes" add guidance on carriers and U-types— JohnTitle: Minimal Value Types (Shady Edition) Minimal Value Types April 2017: Minimal Edition (v. 0.4) J

cleaning up the CP in JDK 999 (and thinking clearly about the CP in JDK 10/11)

This message needs an "Impractical Content" warning, but I want to log an interesting line of thought raised today in our Valhalla meeting with IBM. It actually is practical to think about, as a mental model. We could, if we chose to do it at some far-future date, clarify the roles of CP entri

What's in a CONSTANT_Class?

(From today's discussion internally and with IBM.) Dan Smith and Maurizio point out that a C_Class CP entry has many uses. Some of them are type-like, and some are file-like. Example file-like uses are this_class, InnerClasses, EnclosingClass (refer to a class-file). Example type-like uses are l

Re: What's in a CONSTANT_Class?

On Jun 8, 2017, at 5:00 PM, Dan Smith wrote: > > Some initial notes below attempting to flesh out what our two long-term > options look like. I like both of your sketches. I think we should also try this variation: CONSTANT_Class is legacy only. That way folks won't encounter CONSTANT_Class a

Re: What's in a CONSTANT_Class?

(more comments) On Jun 8, 2017, at 5:00 PM, Dan Smith wrote: > > > CONSTANT_Class_info { >u1 tag; // 7 >u2 name_index; // Utf8 > } If we decide to sideline the previous guy as a False Friend, then this is the place where resolution really happens: CONSTANT_ClassFile_info { u1 tag;

Re: What's in a CONSTANT_Class?

Whatever tag numbering scheme we do will have to move up by two, since CONSTANT_Module_info.tag = 19 and CONSTANT_Package_info.tag = 20. I think we can take our next node at tag 21, for CONSTANT_Q or CONSTANT_Value or whatever we were calling it on Wednesday. I particularly like your ClassType_i

Re: What's in a CONSTANT_Class?

On Jun 9, 2017, at 8:43 AM, Dan Smith wrote: > > I prefer the discipline of making 'void' a separate entity (CONSTANT_Void?) > that we don't necessarily call a "type", although not sure that carries its > weight. I think on balance the JLS would be cleaner if we admitted void is a type, with

Re: notes from Valhalla meeting 5/24/17

We have talked about "condy" (a constant-pool friend for indy).Enclosed is the javadoc portion of a draft spec.The JVM spec. is not ready and will be sent separately.This javadoc reflects code checked into the condy branch of Amber.On Jun 5, 2017, at 4:21 PM, Karen Kinnear

Re: What's in a CONSTANT_Class?

On Jun 9, 2017, at 1:45 PM, John Rose wrote: > > Allowing in return position to assume will be attractive with new > generics. Allowing Map to assume V=void with no layout footprint derives Set. This is a trick Rust plays successfully. I've always wanted to pull that trick.

Re: What's in a CONSTANT_Class?

On Jun 14, 2017, at 9:22 AM, Remi Forax wrote: > > With my ASM Hat, > both CONSTANT_Class_info “;Q” and CONSTANT_ValueType_info that > references an UTF8 are Ok for me. Between those two I prefer the first since it doesn't require a new CP tag. > Weirdly, having a CONSTANT_Value_info that refe

Re: What's in a CONSTANT_Class?

On Jun 14, 2017, at 8:54 AM, Karen Kinnear wrote: > > We would like to request that for the MVT Early Access we keep the TEMPORARY > CONSTANT_Class_info “;Q”. Nit: For uniformity, the syntax wants to be ";" + field_signature, which implies ";Q;". Without that uniformity you need to specify a t

Re: What's in a CONSTANT_Class?

On Jun 15, 2017, at 3:09 PM, fo...@univ-mlv.fr wrote: > > > (BTW, neither you nor Karen did answer to my mail asking why we need UFoo; ) I'm working on a manifesto about this. Short answer is Q-Foo and L-Foo need to be disjoint types, so that interpreter processing of L-Foo is undisturbed and

Re: notes from Valhalla meeting 5/24/17

On Jun 9, 2017, at 1:51 PM, John Rose wrote: > > We have talked about "condy" (a constant-pool friend for indy). > Enclosed is the javadoc portion of a draft spec. > The JVM spec. is not ready and will be sent separately. > This javadoc reflects code checked into the

Re: notes from Valhalla meeting 5/24/17

On Jun 19, 2017, at 6:28 PM, John Rose wrote: > > I have updated the javadoc portion of the spec for constant-dynamic. > There are small but strategic changes to MethodType and MethodHandle, > as well as new classes to represent the "pull mode" of constant resolution. >

Re: minutes Valhalla EG June 07, 2017

On Jun 21, 2017, at 6:55 AM, Daniel Heidinga wrote: > > > AI: John - send out javadoc to EG > > derived class := Class.derivedClassFactory(Class mainClass, T userData, > > String name) > > In the spirit of the usual "5 min before the meeting" ritual action item > panic, I'm trying to review

Re: minutes Valhalla EG June 07, 2017

On Jun 21, 2017, at 8:56 AM, Remi Forax wrote: > > John, > Do we agree that this API can also replace the constant pool patching done by > unsafe.defineAnonymousClass, > i.e. that the Object can be any live Object? This seems close to possible, although I would imagine that a nest-injected clas

Re: notes from Valhalla meeting 5/24/17

On Jun 21, 2017, at 8:46 AM, Remi Forax wrote: > > but i do not like with this proposal as is, i will explain why and how to fix > it: > - condy is linked to a static final field but unlike invokedynamic which is a > link from an invokedynamic instruction to a CONSTANT_InvokeDynamic_info, > th

Re: notes from Valhalla meeting 5/24/17

Thanks; all fixed. On Jun 21, 2017, at 1:45 PM, Paul Sandoz wrote: > > > "This allows the bootstrap logic the ability to order the resolution of > constants and catch linkage exceptions.” > > And possibly still link a constant rather than re-throwing a linkage > exception? > No, there's no

Re: notes from Valhalla meeting 5/24/17

On Jun 21, 2017, at 1:59 PM, Paul Sandoz wrote: > > Relevant bit: > > CONSTANT_ConstantDynamic_info { > u1 tag; > u2 bootstrap_method_attr_index; > u2 name_and_type_index; > } > > The value of the name_and_type_index item must be a valid index into the > constant_pool table.

Re: notes from Valhalla meeting 5/24/17

On Jun 21, 2017, at 12:03 PM, Frederic Parain wrote: > >> >> Can we get away with changing all static final fields to be lazily >> initialized without some explicit opt-in? It would be nice but it might >> induce subtle changes in behaviour and expectations (especially for where >> exception

Re: notes from Valhalla meeting 5/24/17

On Jun 21, 2017, at 4:44 PM, Paul Sandoz wrote: > > A BSM called to resolve a constant can choose when pulling it’s static args > to catch and swallow linkage exceptions, keep on trucking, and return a > value. Should this be allowed? Absolutely. The BSM might have an API-specific fallback.

Re: notes from Valhalla meeting 5/24/17

On Jun 21, 2017, at 4:44 PM, Paul Sandoz wrote: > > A BSM called to resolve a constant can choose when pulling it’s static args > to catch and swallow linkage exceptions, keep on trucking, and return a > value. Should this be allowed? Suppose you have a pattern-matching switch with 100 cases,

constant-dynamic specification, updated

I have updated the javadoc API that is relevant to the proposed JVM features for dynamic constants and more powerful bootstrap methods. http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html Here is a rough draft of the corresponding JVMS changes: http://cr.openjdk.java.net/~jrose/jvm/s

class, type, instance, object, value

So, I'm writing more and more documentation that discusses objects and primitives while bringing values into the mix. What seems right to me is that we allow the terms "class", "type", and "instance" to symmetrically cover both legacy object types and new value types. We should continue to use th

Re: class, type, instance, object, value

On Jun 25, 2017, at 7:17 PM, John Rose wrote: > > object: (ambig.) a reference to an object instance OR context-dependent > ellipsis for value type/class/instance s/ellipsis for value/ellipsis for object/

Re: class, type, instance, object, value

On Jun 26, 2017, at 5:16 AM, Bjorn B Vardal wrote: > >> > value field: (ambig.) field whose type is a value type (in any kind of >> > class) OR a field in a value class (of any type) > > If you want to resolve this ambiguity, I've been referring to the former as a > "value typed field" and th

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 7:26 AM, Karen Kinnear wrote: > > John’s longer term plan is that ultimately the byte code can only be executed > in the value class itself Slight correction: ultimately the byte code requires private access to the value class itself. This means that nestmates can use that

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 10:59 AM, Paul Sandoz wrote: > > I strongly suspect we can specify a safe version of > Unsafe.defineAnonymousClass (minus constant pool patching) independent of > nest mates. I believe that is desirable on it’s own as part of the replace > unsafe functionality and if that ca

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 11:39 AM, Paul Sandoz wrote: > > > I was unsure if we require a new method L.defineAnonClass or could leverage > the existing L.defineClass. IIUC for expediency the current hooks in the VM > lean towards anon classes, since there is already code to defer to the host > class

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 12:13 PM, Dan Smith wrote: > Summary of today's discussion, supplemented with some reflection on what I > see as the requirements: Thanks! > - The specification shouldn't care when the class is derived (though it must > occur, naturally, no later than resolution of "Foo$Valu

Re: Valhalla EG minutes 6/21/17

On Jul 6, 2017, at 1:02 PM, Paul Sandoz wrote: > > In terms of what we have today we could easily do: > > // lookup must have private access to the lookup class, which becomes the > “host” class > Class defineAnonymousClass(byte[] data) > > is that ending gaining too much? Sure, that's OK,

Re: constant-dynamic specification, updated

he system can check or enforce, of course. > > Also, related: what sort of facilities might we want to provide for > caching/interning of equivalent constants across classes? I could easily > imagine a BSM wanting to preserve the invariant that any LDC with a given set > of a

Re: constant-dynamic specification, updated

On Jul 6, 2017, at 5:13 PM, Brian Goetz wrote: > > I was asking a slightly different question Ok, thanks. (D'oh.) I'll put in some guidance.

Re: off-list Re: Valhalla EG minutes 6/21/17

On Jul 11, 2017, at 4:36 PM, Paul Sandoz wrote: > > Sigh, email fail, looks like i just have :-) Well played, sir!

Re: off-list Re: Valhalla EG minutes 6/21/17

On Jul 11, 2017, at 4:34 PM, Paul Sandoz wrote: > > That leaves the more general nested named class support which requires more > fundamental hotspot work. > > So in terms of progress order it could be: 2), 3), 1). But if we throw > isolated methods into the mix then the plot thickens. I thin

Re: Valhalla EG minutes 6/21/17

On Jul 12, 2017, at 11:10 AM, Karen Kinnear wrote: > > > And if I understand the proposal correctly, we are replacing constant pool > patching > with Lookup.getConstant() with a private Lookup, which uses an ldc of condy > underneath, > so essentially the BSM is filling in new types in the con

Re: Valhalla EG minutes 6/21/17

On Jul 12, 2017, at 12:08 PM, Paul Sandoz wrote: > > A ClassValue kind of map might be more efficient than say a ConcurrentHM. A cell in the java.lang.Class is better. It requires JVM collaboration. The trick can be done 99% correctly with ThreadLocal and ClassValue. The defineClass guy sets u

Re: Valhalla EG minutes 6/21/17

On Jul 19, 2017, at 7:31 AM, Daniel Heidinga wrote: > > There are a couple of different terms that have been used to describe early > access features - incubator (jep 11), experiment, or optional. At least for > me, these different terms result in different mental models for how this > should

Re: ConstantDynamic bootstrap specifier resolution

On Aug 31, 2017, at 1:36 PM, Karen Kinnear wrote: > > So today we re-resolve the callsite specifier for EACH BCI. Yes, for invokedynamic. In order to make this work we have to allocate a distinct CP cache cell for each individual indy instruction. This is done in the Rewriter, and uses all 4 o

Re: ConstantDynamic JVMS comments

(Going back to a dropped response!) On Jul 19, 2017, at 8:48 AM, Karen Kinnear wrote: > > ...small questions/comments: > > 1. 4.5 fields > in 5.4.3.6 you have a much clearer description of the argument types > could you either reference that or include the bullets here? (the syntax is > n

[BSM-RETURNS-MH] allow invokedynamic BSM to return MethodHandle instead of CallSite

http://mail.openjdk.java.net/pipermail/mlvm-dev/2017-October/006782.html Begin forwarded message: As we use BSMs more and more, we will want to dispense with the CallSite infrastructure, in many cases. I filed an RFE to track this. If we can agree on specification, it will be fairly easy to impl

Re: nestmates spec open issues

On Oct 25, 2017, at 8:39 AM, Brian Goetz wrote: > > John Rose proposed: >> a) Class.getnestHost() - defaults to itself if there is a resolution error > > (or if there is no Nest attribute) (yes) >> b) Class.getNestMembers() - returns full nest, fallback of self if a

Re: nestmates spec open issues

On Oct 25, 2017, at 3:33 PM, Remi Forax wrote: > > getClasses() throws an exception but getAnnotations() skips unavailable > annotations. > > that said, i'm not against throwing in this case. I'm not against throwing either, but I think scrubbing (like annotations) is a little better, because

Re: nestmates spec open issues

On Oct 25, 2017, at 8:07 PM, John Rose wrote: > > On Oct 25, 2017, at 3:33 PM, Remi Forax <mailto:fo...@univ-mlv.fr>> wrote: >> >> getClasses() throws an exception but getAnnotations() skips unavailable >> annotations. >> >> that said, i'

Re: nestmates spec open issues

On Oct 25, 2017, at 8:54 PM, David Holmes wrote: > > On 26/10/2017 1:11 PM, John Rose wrote: >> On Oct 25, 2017, at 8:07 PM, John Rose wrote: >>> >>> On Oct 25, 2017, at 3:33 PM, Remi Forax >> <mailto:fo...@univ-mlv.fr>> wrote: >>>>

Re: nestmates spec open issues

On Oct 25, 2017, at 11:11 PM, David Holmes wrote: > >> Please don't throw IAE that case. I don't want to bikeshed exception types, >> but I think we have a strong precedent for using ICCE when encountering >> a questionable classfile configuration (one that shouldn't have come out of >> javac).

Re: Minutes Valhalla EG Oct 11 2017

FTR, Dan's draft is posted at: http://cr.openjdk.java.net/~dlsmith/constant-dynamic.html One thing I like very much about Dan's work is the refactoring of information that used to be co-located with invokedynamic-specific sections of the spec, into their own sections, where indy and condy can re

Re: Minutes Valhalla EG Oct 11 2017

On Oct 27, 2017, at 7:57 AM, Martijn Verburg wrote: > > Just for my reading benefit :-), did you mean: > > "Format should be self-explanatory. My new text is in yellow, stuff of > Dan's *is green*, *stuff* I deleted is in crossed-out *red*."? Heh. Here's the secret decoder key: white - uncha

Re: nestmates spec open issues

On Oct 30, 2017, at 6:45 PM, David Holmes wrote: > > Hi John, > > On 26/10/2017 2:03 PM, John Rose wrote: >> On Oct 25, 2017, at 8:54 PM, David Holmes wrote: >>> Though I still feel uncomfortable lying about the nest-host. I don't see >>> what usec

Re: [Nestmates] Draft core reflection API

On Nov 6, 2017, at 11:26 PM, David Holmes wrote: > > For comment: > > http://cr.openjdk.java.net/~dholmes/8188075/webrev/raw_files/new/java/lang/Class.html#getNestHost() > > > Looks good. A

Re: [Nestmates] Draft core reflection API

On Nov 7, 2017, at 2:31 AM, David Holmes wrote: > > a top-level class is always a nest host The ad hoc explanation you suggest is OK with me but this last statement is TMI. There's no physical reason that must be true; it is an arbitrary convention which will probably go away as we use nestmate

Re: [Nestmates] Draft core reflection API

> On Nov 8, 2017, at 11:25 PM, David Holmes wrote: > > http://cr.openjdk.java.net/~dholmes/8188075/webrev/raw_files/new/java/lang/Class.html#getNestHost() > > I hope it isn't TMI for John. > Looks good to me. I don’t want to rule out other uses of nest mates, and that language is loose enou

Re: class, type, instance, object, value

ame&mode to find a class-for-the-box vs. > class-for-the-value, the java.lang.Class itself > would be unique, wouldn’t it? Hmmm… If we do both "crasses" and boxes then there could be a proper class mirror for a real value class like java.math.FloatComplex, and then a "cra

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

We just had a 50-hour week of face-to-face meetings by the Valhalla VM team. We learned a lot and surprised ourselves by coming to a consensus that a promising design for value types uses mainly the same legacy L-type descriptors, makes relatively little use of Q-type descriptors, and does not app

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

On Nov 19, 2017, at 2:47 PM, Remi Forax wrote: > > 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(). Object and interfaces play the role of top types. One view is that we are making object act

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

On Nov 19, 2017, at 3:33 PM, fo...@univ-mlv.fr wrote: > > but you need a way disambiguate a reference type from a value type at runtime > in the interpreter. > You also nedd to teach JITs to propagate L vs which Q info on local variables > for generics specialization (and it works even if the in

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

On Nov 22, 2017, at 5:48 AM, Brian Goetz wrote: > > What's the L-world story for array subtyping? For any R-type, R[] <: > Object[]. If everything is an L type and everything is <: Object, are arrays > of Q-types/primitives also subtypes of Object[]? > > We didn't have a story for this in QU

Re: More on seeing the L world as a U world

Good comments. On Nov 22, 2017, at 3:05 AM, Remi Forax wrote: > > Primitive types: > primitive types are seen by the VM as value types, int.class.isValueType() > returns true. > there is no need to see those class in the JDK, so like currently there are > synthetize by the VM. So storing an in

Re: Final nestmates spec

On Dec 1, 2017, at 4:41 PM, Dan Smith wrote: > > I've uploaded what I believe could be a final spec for nestmates, here: > http://cr.openjdk.java.net/~dlsmith/nestmates.html > > Since October, changes include: > > - Tweaks to the explanatory material in 2.11.8 and 3.7 > > - Some restructuring

stricter symbolic references to protected methods

(This came up while reviewing the nestmates stuff. I'm sending it in its own thread, FTR.) Here's a question to mull over for the future. It belongs in the "strict VM" bucket of ideas, which I have occasionally spoken about. There is a lot of (IMO needless) complexity in the JVM dealing with a

  1   2   3   4   >