Valhalla EG meeting Sept 27 - and Sept 13 minutes

[Karen Kinnear]

Write-up on preparation relative to selection and nest mate JVMS changes. Feedback welcome.


> On Sep 27, 2017, at 9:50 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Reminder - meeting TODAY, Sept 27 9am PT/noon ET/
> dial-in:  https://oracle.zoom.us/j/5249803466 <https://oracle.zoom.us/j/5249803466>
> 
> AI: Karen send Dan H example in which a BSM can be used for both indy and condy
> AI: Dan Smith version of Condy JVMS changes (not an appendix
> AI: nestmates JVMS comments: http://cr.openjdk.java.net/~dlsmith/private-access.html <http://cr.openjdk.java.net/~dlsmith/private-access.html>
>      Remi proposal: rename attribute to “NestHost"
> AI: Karen: write-up preparation relative to selection
> AI: Karen - ask Paul progress on VarHandles and atomicity relative to Value Types
> 
> Question for EG:
> 
> Doug, Charlie - does it work for you if we provide MVT as Early Access Binaries instead of part of 18.3?
> 
> 
> Attendees: Remi, Frederic, Brian, Dan H, Karen
> 
> 1. JDK version numbers relative to class file versions
> Would be useful to find a way to document the mapping for users
> 
> 2. Delivery vehicles
> Discussion of making MVT available via an Early Access Binary vs. part of 18.3 experimentally
> 
> pros and cons:
> 1. late in the cycle to be adding to 18.3, specifically relative to JVMS/JCP process
> 2. with EA binary we can make this available sooner than 18.3, and update it more often in response to requests
> and prototype progress
> 3. EA is less cost to productize and support
> 4. - the risk of not being in 18.3 is that we will get fewer adopters
>    - the hoped for benefit of an EA is that we will get more of the advanced early adopters who can give us valuable
>      feedback and use cases
> 5. No 18.3 features are dependent on MVT (note: pattern matching is not dependent on MVT, and not targeted for 18.3)
>     current goal for features: Local Variable Type Inference and Condy (not experimental) in 18.3
>     goal: nestmates early in the 18.9 cycle to shake it out (meeting attendees ok with delaying nestmates)
> 4. As an EA binary, we are ok with having a javac with MVT support behind a flag
> 5. Benefit of 18.3 experimental: 2nd level customer, i.e. user of Scala or JRuby could enable this with a flag
>     - the theory is that those trying the experimental compiler would be able to download an experimental JDK binary to try it on
> 6. Time to get an experimental feature through JCP process - into experimental appendix with disclaimers
>     - Brian working with JCP to reduce lag time, see JSR 383 for 18.3
> 7. IBM can find a way to do external binaries
>     - both IBM and Hotspot are working on internal processes to make this happen
>     - we will keep in contact on the target date - not expected to be exactly in sync
>     - Hotspot expect ~ 4-6 weeks from Sept 13
> 
> 3. ConstantDynamic concerns:
>    1. BootstrapCallInfo - i.e. lazy resolution - IBM less confident (Hotspot agree)
>    Remi wants to continue the discussion
>    There are ways to handle > 251 arguments with varargs, rather than requiring BSCI
>    channeling John: one of the goals of lazy resolution is to allow only evaluating a subset of constants that may succeed
> 
>    2. Question - can a condy and an indy share the same BSM?
>        In practice yes - if the BSM specifies a java.lang.Object for the MethodType returned, then it can return a java.lang.Class for the condy
>        and a CallSite for the invoke dynamic. The verifier does not check the BSM MethodType, deliberately. The verifier does minimal checking
>        for BSMs deliberately, according to Remi - this provides requested flexibility for dynamic languages
> 
>     3. Remi - we want condy without java.lang.invoke, and we want it to work during vm bootstrapping.
>     
> 
> 4. Nestmates
>   1. Question: how do we handle invokeinterface for methods in java.lang.Object?
> AI: Karen to email details of invocation including corner cases - relative to the specification changes
> 
>    2. Lazy loading - what should reflection do?
>       Request from last meeting to lazily load the nest top so as to not break current nested class examples that work today (e.g. someone deletes the outer class)
>       Proposal:
>            get list of Nestmates: model on getAnnotations - if you can’t find a nest member, skip it, do not throw an exception
> [ed. note: what if you can not find the nest top?]
>            check if two types are nestmates: throw LinkageError if nest top can not be found
> 
>    3. Attribute renaming: Proposal “NestHost” from last time -> tell Dan Smith
> 
> 5. MVT 
>     1. Remi: OutOfMemoryError if 15 million element array of ValueTypes
>     If fail due to OOME, could consider falling back to allocating in the heap, this would be slower
>     Remi: prefer OOME to not performant
>     note: choosing to flatten is an implementation detail which could be architecture dependent, depend on atomicity requirements, etc. - no user control
> 
>     2. Atomic operations
>        Karen: request changing VarHandles to require declaration site atomicity and consistency across byte code and VarHandle access relative to non-tearing
>        Remi - less than 64 bits no need to declare
>        AI: Karen ask Paul to work with Doug on this
>        Remi: please do not reuse volatile, do not use atomic - want e.g. untearable
> 
> optional flattening work in progress - should be there in a couple of weeks
>        
> 
> 
>