No Valhalla EG meeting July 3rd, minutes from June 19th

[Karen Kinnear]

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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190702/2ae86499/attachment.html>