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