attendees: Tobi, Dan S, Simms, Frederic, Karen corrections welcome. 1. JVMLS talks LWorld - Tobi & Simms Condy - Dan H & Paul Sandoz Nestmates - Just a Small Change -> actual impact: Karen LWorld discussion - multiple folks willing to participate if this is wanted
Abstracts (were) due May 25. 2. Nestmates Reviewed and approved David Holmes’ update on java doc for java.lang.class::getNestHost() http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000694.html key points: 1. clarified LinkageError vs. e.g. RuntimeError handling 2. clarified primitive and array class handling - member of nest consisting only of itself 3. all nestmates implicitly in same runtime package Remi sent mail that 6.2 ASM is available supporting Nestmates, Condy and preview versioning - many thanks Remi! 3. Value Types Karen described Towards Minimal LWorld discussion and additional thoughts: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000674.html Key messages: 1. We need to phase in the LWorld support LW1: get minimal LWorld/LW1 out as Early Access binaries ASAP - goal pre-JVMLS LW10: initial preview version LW100: we got there and multiple stages in between 2. Scaled back LW1 requirements 1. No support for erased generics: javac disallow value type may not be used for a type argument 2. No requirement for for migration value-based-class to Value Type: nullability issues not yet resolved 3. LW10: 1. support erased generics (but not specialized) 2. preview quality 3. may discuss other requirements, e.g. from feedback from EA users 4. Nullability discussion 1. Agreed on adding ValueTypes attribute Decouple value type consistency checking from nullability discussion. LW1 would disallow any classfiles to not buy in to the global consistency checking of being a value type. Verifier can check value type/non-value type relative to valid bytecodes (defaultvalue/withfield vs. new/monitor*/putfield) ed. note - see follow-on email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000705.html 2. Nullability direction: Longer-term goal: decouple non-nullability of a type, make this a property of a container could use this for atomicity and immutability Dan H: long-long term: similar to Arrays 2.0, e.g. frozen arrays 3. Nullability handling for LW1 - very much still under discussion Option 1: LW1: all references to value types are non-nullable start with non-nullability as property of a container - specifically fields and arrays in the heap non-nullable fields are marked as ACC_FLATTENABLE (LW1: all fields containing value types from ValueTypes attribute are marked ACC_FLATTENABLE, so remove source keyword) arrays of value types are by default non-nullable/flattenable LW10: will need to evolve to handle nullable references to support erased generics will need to develop model for array handling that allows distinguishing arrays of value types that may contain null Option 2: LW1: all value types are non-nullable - based on type verifier check to ensure static null not stored via putfield, putstatic, withfield, nor passed in invocation/areturn for value type signature - to provide guarantee null is never seen in a value type signature use Object[] if you need an array that may contain null 4. verifier discussion Karen voiced concerns about guarantees that static null checking would ensure no dynamic nulls in value types in the longer term. Dan H: runtime checks would be prohibitive AI: all see if there are holes here ed. note: potential holes: JNI: native method can return null erased generics can return null for a value type, will need a way to support null future: value-based-classes will be value types that allow null note: aastore does no verifier checks, the type-checks are dynamic, the null checks would also need to be dynamic Dan H: worth exploring VT implement interfaces 5. ValueTypes attribute: 5.1 Value-type eager loading ed. note: see same follow-on email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000705.html 1. value type fields: pre-load (after pre-loading supertypes) only if flattenable (LW1: all in ValueTypes attribute flattenable) 2. eager load for methods: at link time before preparation 3. challenge: initialization of statics before loading type and getting a default value ed. note: see follow-on email on statics: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000699.html 5.2 other uses of default value - must require class initialization e.g. arrays (anewarray, multianewarray) 6. JVMTI implications of ValueTypes attribute agreed: not remove entries, ok to add or reorder 7. Constructor - LW1 will leave alone for LW10 - see email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000680.html Feedback on ideas above? Dan H: like the idea of something smaller, early, need to study more thanks, Karen
