Valhalla EG Notes June 20, 2018

[Karen Kinnear]

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