Valhalla EG Notes June 20, 2018

Karen Kinnear karen.kinnear at
Fri Jun 29 22:36:11 UTC 2018

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.

All: review Nestmates GetNestHost minor rewording of javadoc
All: review Value Type Consistency Checking proposal:
All: see follow-up request - please approve LW1 temporary static method consistency checking before preparation, to be revisited:

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

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

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

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,

More information about the valhalla-spec-experts mailing list