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> > 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> > Sent by: "valhalla-spec-experts" > <valhalla-spec-experts-boun...@openjdk.java.net> > To: valhalla-spec-experts <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 > > > > > > > > > >
