From karen.kinnear at oracle.com Mon Apr 9 20:51:42 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 9 Apr 2018 16:51:42 -0400 Subject: Cancelling Valhalla EG meeting Wednesday April 11 Message-ID: <2661E8CC-C783-43B7-A41B-D4B2CDADABB7@oracle.com> Apologies, we have an internal conflicting meeting. Our next meeting will be Wednesday April 25th. I will send minutes from our last meeting. thanks, Karen From karen.kinnear at oracle.com Mon Apr 16 20:40:06 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 16 Apr 2018 16:40:06 -0400 Subject: Valhalla EG meeting notes March 28, 2018 Message-ID: attendees: Frederic, Tobi, Karen, Remi (corrections welcome) AIs: Karen: updated https://bugs.openjdk.java.net/browse/JDK-8171335 with requests from meeting (done) Remi: https://bugs.openjdk.java.net/browse/JDK-8171335 - please add ?privileged? annotations you would like in the new MH.Lookup.defineClass API and why you need them Remi: https://bugs.openjdk.java.net/browse/JDK-8158765 - ?isolated methods? - please add details of what parts of a current class container you need and what parts you do not. I. l-world value types JVMS update: 4c: http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4c.pdf Added class file format related changes 2. Nullability concerns: Goal: future vision - value types as non-nullable and flattenable Challenges: 1. Migration of value-based-classes 2. backward compatibility - for APIs and bytecodes that take Object, Interface, [Object, [Interface 3. generics - want them to work with value types - want benefits of flattening - how does that work with erasure to Object - how does that work with current APIs e.g. Collections: assume [Object 4. longer-term: primitive handling To handle migration of value-based-classes: proposing that the JVM be lenient: allowing passing nulls for value type arguments allowing nulls for local variables and the operand stack only catching nulls for putfield and aastore In classfile: field will be declared as ACC_FLATTENABLE (which implies non-nullable) or not Proposing javac changes for leniency for value-based-class migration: - mark value-based-class as migrating with an annotation: java.lang.ValueBased (for prototyping) - javac still considers identity based violations as errors - javac allows nullability violations to be warnings rather than errors - default @ValueBased is not flattened, container author must opt-in Note: At this time non @ValueBased classes are by default assumed always flattenable by javac arrays of any value types, including ValueBased classes are considered flattenable by javac Still trying to figure out how to handle backward compatibility and generics and primitives in the future Specific issues with arrays and sub typing: [Object and [Interface accept null subtypes of [ValueType do not accept null - runtime throws NPE how does this work with generics and erasure? we do not want any array type conversion under the covers option 1: what if [ValueType is NOT a subtype of [Interface and [Object (ValueType is a subtype of the Interface)? identity assumptions still work, arrays are still identitiful would we want javac to explicitly insert conversions to e.g. [Object ? trade-off: with [ValueType subtype of [Object, generics just work ? except for storing nulls ? no interest in conversions to Objects and Interfaces -> that leads to accidental temporary identity Tobi: what if we do not allow migration of value-based-classes to value types? Or only for JDK value-based-classes and others get ICCE? Frederic: Still need to solve the backward compatibility and generics issues Remi joined ? Remi: how tell the difference with a migrating value-based-class? Frederic: annotation II. Nestmates 1. Related to migration of Unsafe_defineAnonymousClass to Lookup.defineClass extensions: Remi: highlighted an assumption of Unsafe_defineAnonymousClass: These classes today are ?privileged? in the sense that they are allowed to use privileged annotations (e.g. @stable, @hidden, etc.) These are used for lambda proxies - and by lots of other folks Discussed with John at Belgium Devoxx expecting that Lookup.defineClass will allow this behavior as well - e.g. @hidden - not seen in stack trace - e.g. @forceinline - like performance - e.g. @stable Remi: My notes are not clear on @stable - ?final is final? - and the limitations of enforcing this - Can you please add a detailed request to https://bugs.openjdk.java.net/browse/JDK-8171335 ? Challenges with ?final? fields that are not really final - the VM optimizes based on assuming finality vs. Serialization has to write the fields John & Remi are discussing - moving to condy in the language rather than propagating constants that may actually change 2. Dynamic nestmate plans MH.Lookup.defineClass Karen proposed that you need the Lookup for the nesthost (rather than any random nest member) to be allowed to dynamically add a nestmate (also added to comment in JDK-8171335) Other than that is the proposal ok as is? 3. Remi: concern with dynamic nestmates and Reflection Reflection today only returns the static members. Will it also return the dynamic members when they are added? No reflection APIs today distinguish between static and dynamic 4. Who can get to the proposed user data? Anyone with the Lookup used to create the class? Or just the class containing the userData? 5. editor added: What happens if your nesthost is a Temporary class? is it kept alive as the nesthost? Or do we disallow temporary nest hosts? What are the use cases for temporary? Karen: Can we require that a nest host can NOT be a temporary class? We have to keep the dynamic nesthost alive as long as any nestmates live since we do not allow reducing access controls dynamically. 6. Remi: concern about unnamed There is a hidden performance cost with unnamed classes, which is that you can not generate bytecodes to reference them, you have to use MethodHandles and invokeBasic What he wants is - unloading for named methods and fast MethodHandles Karen: constant pool resolution rules guarantee that we always give you the same answer. We can?t do that if you can unload the class - the user can replace the class - on disk, on the net, etc. so the next request could load a completely different classfile for the same name. Remi: wants bytecodes with no promises for getting the same answer, in fact, he wants ability to do type profiling optimization, e.g. replacing a generic with a more specialized type ? only chance today is to use condy - once Really want functions, classless methods Karen: In earlier discussion for https://bugs.openjdk.java.net/browse/JDK-8158765 I asked the question: If you were to have an isolated method, which parts of the current class container capabilities would you want, and which would you be willing to do without? Initial response from JVMLS was a request for debug information Remi: only need static methods, debug symbols and good stack traces Karen: request - please add details to https://bugs.openjdk.java.net/browse/JDK-8158765 - easiest if you go through JVMS chapter 4 - and clarify what you actually DO need and do NOT need - e.g. no fields (not even static), no class level annotations, ? thanks, Karen