> De: "Daniel Heidinga" <daniel_heidi...@ca.ibm.com> > À: "daniel smith" <daniel.sm...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 19 Juillet 2017 16:31:18 > Objet: Re: Valhalla EG minutes 6/21/17
> 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 > work for the VM. Hopefully, we're all thinking about the same behaviour > semantics and are just using different terms but I think it's worth > clarifying. > 1) JEP 11 does a good job of describing incubator and makes it clear that it > refers to non-standard modules / java-level code. Not VM features. > 2) An optional feature is something you can chose to implement (or not) but > must > exist as part of the current JVM spec. All of its JVM spec changes would need > to be in the spec and their enablement / enforcement would depend on whether > the VM chose to implement that optional feature. Removal of the optional > feature from the JVM spec would basically be impossible - it may fall into > disuse through VMs not implementing it, but it would be hard to remove. > 3) An experimental feature on the other hand, is something that would be > allowed > to have an appendix or set of experimental JVM spec changes that are only > enabled by command line option + present in classes with new minor classfile > versions. These features would start life deprecated and expectation is that > classfiles with this particular minor version would no longer be recognized by > future VMs when the experimental features graduate to the real JVM features, > providing freedom to experiment without requiring the VM to carry the support > burden long term. > My understanding has been that with the MVT prototype work, we've been aiming > for the 3rd case. Does this match everyone's expectations? Anyone think we're > aiming for some other point on the spectrum? I agree, it's an experimental feature, like invokedynamic was at its time, at least for the MVT. > One of my fears is that we're going to end up with the VM required to support > multiple ways of recognizing ValueCapableClasses / ValueTypes, especially if > there are spec changes between the different ways (think the mess that is > invokespecial and the ACC_Super flag) based on attribute vs annotation or > classfile version, etc. Rémi > >> On Jul 5, 2017, at 8:12 AM, Karen Kinnear <karen.kinn...@oracle.com> wrote: > >>> > Dan S: class loading in the proposed JVMS: if you see $Value > >>> > 1) first derive the VCC name and see if already resolved > >>> > 2) if not - load the VCC, check properties and derive > >>> > (ed. note - if see VCC - lazily derive derived value class on touch) > >>> It's not a requirement that the value class derivation is lazy, correct? > >> Let’s double-check with Dan Smith at today’s meeting. > >> The way I read 5.3 Creation and Loading in >>> [ http://cr.openjdk.java.net/~dlsmith/values.html | > >> http://cr.openjdk.java.net/~dlsmith/values.html ] >>> it appears to allow lazy derivation as well as eager derivation, which I >>> think > >> is what we both want > >> since it allows implementations to optimize. > >> Our current derivation is also eager. >> Summary of today's discussion, supplemented with some reflection on what I >> see > > as the requirements: >> - The specification shouldn't care when the class is derived (though it must >> occur, naturally, no later than resolution of "Foo$Value"); the specification > > *might* care when error checking occurs, because that's observable. >> - Current specification draft says error checking occurs when Foo$Value is >> loaded (5.3), and that "Class or interface creation is triggered by another >> class or interface D, which references C through its run-time constant pool." >> So, as a test case: if my program has no references to Foo$Value (direct or > > reflective), no VCC-related errors would occur. >> - We could redesign this so that the VCC properties are checked during >> loading/verification of Foo. I am concerned that, where Foo is version 54.0 >> and >> has attribute ValueCapableClass, this sort of error checking will violate the > > Java SE 10 spec. > Doesn't the use of experimental features allow the new classfile versions to > define new behaviour? I would expect the ValueCapableClass attribute to b e > ignored in a v.54 classfile and only take affect in a v.54.1 classfile so that > the semantics can be changed in the future. >> Elaborating: we're presenting values as an optional feature of Java SE 10. >> For a >> JVM that does not implement the optional feature, JVMS 10 says that a >> ValueCapableClass attribute on a version 54.0 class file will be ignored. >> JVMS >> 4.7.1: "any attribute not defined as part of the class file specification >> must >> not affect the semantics of the class file. Java Virtual Machine >> implementations are required to silently ignore attributes they do not >> recognize." My interpretation of our mission, in adding an optional feature, >> is >> to provide new capabilities while having no impact on existing behavior. We >> can >> do new things where JVMS 10 specifies an error; we can't generate new errors > > where JVMS 10 specifies none. > New classfile version == new behaviour, right? >> - We could limit usage/interpretation of "ValueCapableClass" to 54.1 class >> files. Then eager error checks when loading Foo would be fine. But the >> ability > > to work with 54.0 ValueCapableClass class files is an important use case. > The model here is that using a JVM 10 javac, a classfile with the annotation > is > v54 and on a VM with some -XX:EnableExperimentalFeatures flag, this derives a > v.54.1 class for the DVT? This basically gives new behavior to v.54 classfiles > which makes it very hard to change when Java 11 comes along and fully > specifies > ValueTypes. Customers will still have these annotated v.54 classes and expect > them to keep working as values, meaning the JVMs will need to support both the > annotation and the new way. > Limiting the new behaviour to v.54.1 classfiles and then making them illegal > in > Java 11 makes it obvious to the user that the experimental classfiles won't > work the same way and likely need to be refactored to the new "real" > ValueTypes > way. > Would the annotation be in an incubator module so that it can be deprecated / > removed easily in a future release? >> - Actually, examining that use case more closely, we discussed how attributes >> are not the right tool at all. We want clients of MVT to be able to generate >> interesting programs using a vanilla Java SE 10 compiler. The best mechanism >> to >> communicate "I'm a value-capable class" using a vanilla Java compiler is > > annotations, not attributes. > Because we're dealing with experimental features, can we require a similar > -XX:EnableExperimentalFeatures flag (or -D option) for javac to convert the > annotation into a v.54.1 classfile with the attribute? This makes it easy to > write the code but keeps it sandboxed to the experimental classfile version. > > Tentatively, the spec should be revised so that: >> - The "ValueCapableClass" attribute no longer exists. Delete changes to 4.7 >> and > > delete new section 4.7.25. >> - A "value capable class" is a class whose RuntimeVisibleAnnotations >> includes a >> ValueCapableClass annotation (package TBD; whether the referenced class must >> be > > loaded TBD) > > - As usual, this annotation doesn't impact behavior of class Foo >> - When loading Foo$Value, as specified in 5.3, we'll check that Foo is a >> value > > capable class and that it has the right properties > > —Dan > Annotations are typically more expensive to read in the VM than attributes. If > not for the vanilla-java concerns, a feature like this would have an attribute > in the JVMS. Shouldn't we try to start with the attribute to keep us close to > the path we'd pick for a future java release? > --Dan
