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