Attendees: Remi, Tobi, Dan H, Frederic, John, Karen
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html
<http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html>
Thanks to John for the above link to a proposal for dealing with nullable value
types
I. Nestmates follow-on
status of Lookup.defineClass - RFE JDK-8171335 - links to JDK-8205939
We will need to have discussions about restrictions on referring to
nonfindable classes at some point in the future before
we can target this to a release.
II. status of JEP 334 - JVM Constants API
links to JDK-8203252
Note: Condy/BSM follow-on:
There is a related rfe: JDK-8211334 "ConstantDesc types should be Constable"
which depends on
JDK-8210685 - which is the implementation side of “expression Bootstrap
methods”.
We will need to have discussions about the expression bootstrap methods,
JVMS changes, impact on
JVMTI etc. at some point in the future before we can target this to a
release.
III. Value Types:
1. Remi: would like primitives as Value Types ASAP, Karen translated to a
request to deliver before generic specialization :-)
2. Substitutability
Remi: lambda examples use ==. None use == followed by .equals, in fact none use
.equals.
Karen: other searches have found 10-50% use == followed by .equals
Remi: Hard to find cases with static Object/Interface and dynamic Lambda today
Karen: Challenges:
component-wise substitutability
- primitives - usual check (floating point extra care)
- pojos - non-Object/Interface - reference comparison
- value type - static or dynamic (Object/Interface) - requires recursive
check
Concerns:
performance - due to lots of fields or depth or both
could get StackOverflowError from unbounded links
e.g. for a valid use case - tree-node
Is it appropriate for acmp to perform a substitutability check? It was intended
as a short circuit pretest to a longer test.
LW1: acmp always returns false if either is dynamically a value type
John: Should we consider expanding acmp to for example check 1 level deep?
Dan H: 1 level deep is worse than none -> surprise factor
John: acmp: 0 level, 1 level - performance and SOE surprises
John: Additional concerns:
Cycles: if acmp -> substitutability -> acmp - no way to break the cycle
note: no infinite loops: “well-founded” - use 1 instance to create another -
but still potential exponential size/complexity
Frederic: Can make infinite loops today - if you have an Object/Interface field
Remi: What if you do not perform substitutability checks for non-flattened
value types?
Frederic: Can NOT base this on flattened or not
(ed. note - I suspect Remi meant non-flattenable, you also can not base this on
flattenable or not - random potential same/different reference to a value )
Remi: What if e.g. Object/Interface with dynamic value type and not perform
substitutability check
John: push surprise elsewhere (ed. note - again - random potential
same/different reference to a value type)
possible to improve one case - that of potential infinite nullability
More exploration needed
3. Nullability
Editor’s note: LW2: QPoint; null-free reference to Point. LPoint; nullable box
for Point.
Discussion of nullability post-LW2 …
John:
Problem: Value-based class migration to value types which are null friendly -
rare
Proposal: opt-in new definition of “nullable” value type vs. “regular” value
type which is null-free and requires boxing to allow nulls
T.default is null
heap: use T.default as “vull” - or value null
stack: convert to null
withfield needs to consume and deliver nulls
“no new nulls”
Dan H: getfield needs to convert?
John: yes and aaload/aastore/*field
Remi: can user decide discriminator?
John: can define a pivot field for the null test
alternative: specialized test for null - isPresent, isAbsent etc.
Karen: performance cost for user specific field
John: low incremental cost
places that need to know the information need to know layout and
nullability at the same time, check pivot field or all fields for default value
-> null
note: if not flattened, could store null
Helps recursion problem for acmp
Proposal
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html
<http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html>
4. Locking
Karen:
Discussed with Brian (ed note: who discussed with Doug Lea)
1. propose disallowing locking if statically known to be a value type
2. issue narrowed to Object/Interface with VT
At this point, if in existing code a user is locking an Object or
Interface and dynamically finds a value type -
they did not know what object they were actually locking, so already at
risk.
Could consider - just say “yes” or allow deadlocking
Remi: Loom does not like sync
Agree there are already deadlock problems here
Corrections welcome,
thanks,
Karen
