NO meeting July 4th, 2018 - US Independence day holiday. Next Meeting July 18th. Karen will be on vacation week of July 18th - looking for a volunteer to run the meeting please.
AIs: All: review Nestmates GetNestHost minor rewording of javadoc All: review Value Type Consistency Checking proposal: http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf All: see follow-up request - please approve LW1 temporary static method consistency checking before preparation, to be revisited: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000717.html Karen: update Value Types Consistency Checking proposal with BootStrapMethod info attendees: John, Dan S, Tobias, Dan H, Frederic, Remi, Karen I. Nestmates: Please review GetNestHost minor javadoc request II. Condy Remi: when will javac use condy for constant lambdas? Dan S: some experiments have been done, would like to do this, no timeframe yet Condy next step: not require Looking and Name&Type argument Remi: ElasticSearch guy: indy metafactory not do all the needed casting - works for java but not for scala and other languages - will dig and find III. Value Types 1. Equals/Hashcode/toString Remi - saw initial prototype implementation - two different approaches - Records in Amber vs. Valhalla Remi has a version he could clean up and offer for all us to use - weave custom MethodHandles for each type John: using loop combinators? Remi - try not to John: good - love to see it ** follow-on email (many thanks Remi!) 2. Value Types Consistency Checking proposal Karen walked through overview Summary: Two types of checks 1. Value Types attribute vs. reality 2. Value Types attribute of two different classes - e.g. caller-callee Users of Value Types attribute: 1. verifier (with no loading) - catching mismatched bytecode usage 2. optimizations Goal: avoid eager loading Terminology: pre-load: load before completing load of containing class - analogous to supertype handling - only proposed for flattenable instance fields, information needed for layout - risk of circularity eager loading: loading at other times - e.g. linking, preparation, etc. Proposed checking against reality: 1. instance fields (all flattenable in LW1) - pre-loaded: test vs. real 2. flattenable static fields - link phase, prior to preparation (post-LW1): test vs. real 3. local methods: prior to preparation check all (in ValueTypes attribute or not) parameters/return vs. real 4. CONSTANT_Class resolution: for all classes (in ValueTypes attribute or not)test vs. real Proposed checking inter-class consistency 5. Preparation (selection cache creation): method declarer vs. method overrider consistency 6. Field or Method Resolution: For all types in signatures, check caller-callee consistency Note: these checks should essentially match where loader constraint checks are performed today. Note: all the inter-class consistency checks check all the signature types, whether or not they are in the Value Types attribute Remi: if a method is never called, why load parameters? Tobi: why not load one first invocation? John: if load before call - add a new barrier. - challenge with overriding hierarchy - deopt - sudden unpredictable performance drop - preparation is better than 1st call Karen: note: if there is a null on the stack, they might not have loaded a parameter at first call Frederic: Overriding example A.m, B.m, C.m if A is correct, B is incorrect, C is maybe wrong - body of the local method may be incorrect Remi: if the super type is correct but the subtype is not Karen: preparation checks are NOT vs. the real type - they just check overrider/overridden - they could both be wrong and pass that check Frederic: This is more complex with interfaces Dan H: if never call method, want to continue to run, throw an exception when realize inconsistency Dan S: alternative - hotspot implementation could perform the check early and cache and throw the exception at first invocation AI: Karen - investigate possibilities including either delaying checking or offering the option to check earlier but delay throwing any exceptions ed. note - sent follow-up email: started the exploration - too complex for LW1 timeframe - asked for approval to keep proposal for now and revisit after we get early access binaries into people’s hands John: Constant_Class resolution - need to also check BootStrapMethod evaluation for indy and condy - spec says “as if by ldc”. Karen: Issue 1: Note that it is possible for class A to declare a field of V, not know it is a value type, and class C to also not know and to store null in the field, because field resolution only checks between the caller-callee, not reality. Folks were ok with letting this work. III. Static fields - flattenability Karen summarized some of the issues and options outlined in the Value Types Consistency Checking: - risk of circularity errors if we pre-load static fields that are (flattenable) value types. Since there is a requirement to allow a static field to contain an instance of the container type, we obviously can not pre-load. - Preparation time issues: - Preparation is prior to class initialization - challenge in creating a default value instance of a class which has not yet been initialized - theory is that you can’t actually get to the static without initializing the class choices: 1. trigger class initialization early 2. prevent a leak John: bytecodes and MH-like bytecodes know how to make a default instance before class initialization Note: there is a risk of the default value instance escaping prior to initialization — e.g. JVMTI - maybe spec bug - getFieldIDs/getMethodIDs - require a class to be prepared - should require a class to be initialized (since the jfieldIDs/jmethodIDs will be used by JNI which requires the class to be initialized, and the getField/getStatic etc. JNI methods do NOT ensure this for performance). This is a bug. — JLS is explicit about hole during <clinit> that allows the initializer to create an instance of itself and publish it for external view - this is an actual problem - Note that once the instance escapes - there are no class initialization barriers on bytecodes for instances - it is assumed that these are caught at “new” or “defaultvalue” Remi: agree with John - go ahead and initialize during preparation to a default value and do not trigger class initialization Dan S: prefer get static trigger class initialization rather than preparation John: concern about circularities for class initialization Karen: circularities - only for class loading, not for initialization - logic explicitly allows same thread to “successfully” initialize if already in initialization Karen: class initialization of a container should trigger class initialization of all flattenable fields John: any additional class initialization barriers for hiding default - e.g. anewarray Preparation essentially creates storage, AI: Karen - double check potential JVMTI bug Corrections welcome, thanks, Karen
