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 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
