No Valhalla EG meeting July 3rd, minutes from June 19th
karen.kinnear at oracle.com
Tue Jul 2 21:24:42 UTC 2019
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
> 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>
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.
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
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!
More information about the valhalla-spec-observers