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