Dan, tracking via https://bugs.openjdk.java.net/browse/JDK-8205061
thanks, Karen > On Jul 9, 2018, at 2:50 PM, Karen Kinnear <karen.kinn...@oracle.com> wrote: > > > Many thanks for checking Dan and agreeing that this needs a spec fix. Working > on moving that forward. > > thanks, > Karen > >> On Jul 6, 2018, at 11:26 AM, Daniel Heidinga <daniel_heidi...@ca.ibm.com >> <mailto:daniel_heidi...@ca.ibm.com>> wrote: >> >> > AI: Karen - double check potential JVMTI bug >> >> I checked our code base for this and we have the same behaviour. Would be >> good to get this fixed at the spec level. >> >> --Dan >> >> ----- Original message ----- >> From: Karen Kinnear <karen.kinn...@oracle.com >> <mailto:karen.kinn...@oracle.com>> >> Sent by: "valhalla-spec-experts" >> <valhalla-spec-experts-boun...@openjdk.java.net >> <mailto:valhalla-spec-experts-boun...@openjdk.java.net>> >> To: valhalla-spec-experts <valhalla-spec-experts@openjdk.java.net >> <mailto:valhalla-spec-experts@openjdk.java.net>> >> Cc: >> Subject: Valhalla EG Notes June 20, 2018 >> Date: Fri, Jun 29, 2018 6:36 PM >> >> 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 >> >> <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 >> >> <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 >> >> >> >> >> >> >> >> >> >> >
