Valhalla EG Notes June 20, 2018

Fri Jul 13 20:00:17 UTC 2018

Hearing no volunteers for running July 18th meeting - I am cancelling it. Hope to see some of you
at the JVMLS.

Tobi - I owe you a response to your proposal - we are prototyping the proposal I sent out and learning a lot
which may help inform where we end up.

thanks,
Karen

> On Jun 29, 2018, at 6:36 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> 