Apologies for the late notice - there will be no Valhalla EG meeting July 3rd (extended US holiday).
That gives folks more time for the AI from June 19th - which is to review Dan Smith’s draft of the JVMS FOR LW2. Reminder - this is an LW2 draft, and we are highlighting issues which are still under discussion. We are not trying to resolve their final direction as part of the LW2 JVMS review. > Updated spec: > > http://cr.openjdk.java.net/~dlsmith/lw2/lw2-20190628/specs/inline-classes-jvms.html > > <http://cr.openjdk.java.net/~dlsmith/lw2/lw2-20190628/specs/inline-classes-jvms.html> http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-June/001090.html Minutes from Valhalla EG meeting June 19th: Attendees: Remi, Tobi, Dan H, John, David Simms, Dan S, Karen I. component-wise acmp Remi: not a good idea, already discussed concern about a private field which would be visible John: W/A - any private field can be an Object Karen: do you see any good alternatives? They all require trade-offs Remi: for complex - want substitutable for other cases, better to return false (ed. note - did I get that right Remi?) Dan H: e.g. iteration through an array or circular list, could loop forever if not returning false Remi: use as sentienl Dan H: it is too confusing if comparing an inline class to itself returns false John: this is a continuation of an existing discussion. We need to understand and record alternatives and then choose. http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-April/000950.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-April/000950.html> AI: Remi - if you want to add to the discussion, concerns, alternatives, please do II. JVMS for LW2 Karen: clarify potential confusion: With LW2, we have both Point, Point? Point - QPoint; descriptor - is a zero-default inline class: identity-free, immutable - null-free, flattenable Point? - LPoint; descriptor - is STILL an inline class - identity-free, immutable - nullable, not flattenable Remi: JVMS draft does not talk about flattenable Karen: I did not see flattenable either Dan S: picked nullable John: concern about nullable long-term Karen: in LW2 the meaning is null-free/nullable - the JVMS draft is for LW2 John: expect no null friendly inline types (ed. note - did I get that right John?) Karen: future plans: - we will introduce null-default inline types - we need to do a Proof-of-Concept that we can write generic code which is specializable for both identity and inline classes - which includes both null-default and null-free - the source author is going to need to see how much common code they can write and whether they need different code/algorithms to handle null-free vs. references that accept null John: That is a language level issue In the forward-looking communications, we want to hold lightly to non-nullable types, there may be more kinds of types JVMS Discussion boxes try to highlight some of the ideas that are evolving Karen: need to prototype null-default inline types John: concern about setting expectations Dan S: At the JVMS feel, flattenable is meaningless, so left it out John: agrees, need a knob, e.g. inlinability For the advanced user - dealing with circularity or array performance -> indirect, i.e. don’t inline Karen: nullable is orthogonal to indirect John: not completely orthogonal because we don’t support all the combinations of boxes Concern about complexity if we don’t have good use cases Karen : Agree that we don’t and maybe won’t support all boxes (ed. note - that doesn’t make the properties non-orthogonal, opting to not support all combinations) Remi: Concern about LW2 prototype: if you choose to use Point?, you fall off a performance cliff - and this is easy to do Karen: Brian wants to minimize use of Point? - it is for erased generics and circularity (and some array performance if you copy them a lot) Is the language syntax too similar? Remi: No, this is a fundamental issue, we should provide a nullable version 1. migration, e.g. value-based-class like LOptional; 2. Erased generics vs. specialized generics goal is the final design - still want nullable Karen: trying to design to the end goal, migration is secondary Remi: may have alternatives in migration e.g. nullable inline class - null-default inline class We need a better answer Karen: I agree. We have all been searching for one. What if we used Optional<Point> - instead of Point? (ed. note - sub typing alternative we have today saves copying so better performance if we need to use it frequently) Remi: concern: whatever scaffolding we add will stay in the language - will we need it in the end? What if we limited migration to e.g. java.base (or ed.note - to modules) - so we could teach the vm what has migrated? Remi: If null-default value type, can use in erased generics (ed. note - then we need a different way to clarify if we want erased or specialized generic instance) What if null-free inline classes never worked with Erased generics? Karen: phasing problem - specialized generics will take significant time to deliver Remi: tried to explain current model both to students and at DevOxx - far from obvious Dan S: Do we have an alternative design? John: Goal is binary compatibility, and changes to class file on recompilation Remi is proposing we keep 1 piece of behavior Remi: If it is an “L” descriptor, and we load it and see an inline class -> throw an error? Karen: we need to define what “L” descriptor means Remi: what about an old class with a value-based-class that becomes an inline class? Karen: ALL VBCs migrating to inline class will be null-default, no null-free plans Remi: main issue is Point and Point; John: the user sees a single source of truth for all types the vm sees a different picture Remi: propose: as soon as load - if loaded via “L” descriptor path -> throw error allows use of null under that descriptor John - are you looking for auto bridging? AI: Remi - can you please write up your concerns? Remi: we want to design from the final goal and work backwards LPoint; as an inline class, does not make a lot of sense John: this is often done - we can remove the scaffolding e.g. no atomicity annotation - use volatility Remi: is there a ptr to our goal without this? Karen: 1. we don’t need Point/Point? for migration of VBC -> inline class 2. erased generics - expect nullability 3. circularity and array performance - request to not flatten -> these could be container properties John: not flatten, nullability - adhoc cases push to the translation strategy, may never need LPoint; could choose to erase to Object Remi: For erased generics - perhaps only handle null-default inline class, not handle null-free inline class gets rid of LPoint; as an inline class Karen: Could use container properties - e.g. flattenable - e.g. annotation John: need a full chart of adhoc cases sometimes old behaviors with new types could outlaw some combinations, or use out-of-band-bits need all use cases e.g. Map: functions need to return sentinel of null, even for non generics Karen: Challenges - timing of specialized generics null-default inline classes -> not expect same performance and inlining potential as null-free Remi: Nullable inline type - null-default zero-default/null-free performance is better Karen: goal - minimize use of nullable inline type John: must work like an int - no space for extra value Remi: “works like an int” - is a fairy tail John: now it works better than an int Remi: if the type escapes and needs to support nullability, now JIT is counting on escape analysis John: no calling convention benefits if nullable Remi: In addition to performance concerns, also concern about needing two versions of methods With null-default inline types we don’t need a “nullable” counterpart Karen: Please all keep exploring I think we agree on the goals and the high order bit is performance John: Also concerned about size in memory Remi: Perhaps ok if not supported by erased generics Dan S: Comments please in email on JVMS draft for LW2 John: email - and identify issues to discuss verbally thanks, Karen p.s. corrections welcome p.p.s. If you read this far, Karen Kinnear is retiring as of July 12, 2019. Good luck to this great team and exciting project going forward!
