Valhalla EG notes November 21, 2018

[Karen Kinnear]

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