Valhalla EG minutes October 25, 2017
karen.kinnear at oracle.com
Wed Nov 1 15:01:02 UTC 2017
Attendees: Remi, Dan H, John, Mr Simms, Frederic, Lois, Karen
1. All - review updated ConDy spec
2. Dan H, Dan S - review Karen’s summary of transitive overriding implementation - once
we agree on that, we can sanity check if the specification update matches (the intention was not
to change the meaning, but to improve consistency of the overall selection and overriding specifications)
3. Dan S - respond to concerns below
4. Remi - send link to latest ASM - with fixes for stackmap generation for wide prefixes?
I. ConDy spec:
latest copies linked off of: https://bugs.openjdk.java.net/browse/JDK-8189199
1. Issue - why do we have to rename Constant_InvokeDynamic to Constant_DynamicCallSite?
Remi brought up a serious concern here
Summary: there are three levels of impact here:
1. JDK tools and JVM implementations
e.g. IBM ROM classes today convert back to using constant pool names
2. All byte code tools - e.g. ASM, e.g. IDEs, debuggers, profilers
a) would need to change to accept either one *** see level 3 for how long this must be supported
b) when you print - must choose which one - so you there is not simple “support both”
- so user would need to use flags to specify which one they want
- goal is to reduce flags, this goes in the wrong direction
3. users of byte code tools
- e.g. tests - (e.g. IBM and Oracle both raised concerns here)
- those who use ASM and other bytecode generation/modification APIs for byte code generation
*** If the byte code tools do not maintain both names forever, then the level 3: users of byte code tools
will have to change all their code
Concern is - this is a significant change for the ecosystem and it does not appear to be justified given a cost/benefit analysis
— perhaps - this name’s ship has sailed?
2. ConDy spec update
Dan S and John have been working on this - John will send an update (see above link)
Open Issue: nested conDy handling - risk of infinite recursion
- please feel free to make suggestions
- in future we hope to clarify this using the lazy resolution/BootstrapCallInfo, so a bit vague now
III. Futures - ConDy futures and some Amber projects
John: planning to improve BSM handling in future, with a bit more clarification of VM <-> library interaction
Karen: we want to allow flexibility of implementation
John: under Amber - more coming -
- specification on reflecting ConstantPool entries coming and ways to express unresolved constants, e.g. lambda metafactory only needs symbolic form, not live types
Remi: OK if the API does not see if we have a a resolved or not resolved constant
John: ok 95% of the time
Remi: please send a use case for a edge case
John: e.g. might be where we care about the order of exceptions
Remi: concern about transition from live types to symbolic forms
Remi: how do we decide what projects are discussed under Amber vs. Valhalla so we don’t miss knowing what is coming?
Amber covers language features, if they require nontrivial JVM changes, they move to Valhalla for discussion - e.g. ConDy, nestmates, expect future sealed interfaces and sealed fields and frozen arrays
Folks here are not yet on Amber mailing lists, so useful to bring periodic Amber updates to this discussion
John: Sealed classes, sealed interfaces:
asymmetric access controls
for an interface - today we use the same access flags for ability to call and ability to subtype
for a field - today we use the same access flags for ability to read and ability to write
- e.g. Builders may have special permission to write, as an extended constructor and then publish
as immutable fields
Remi: interface can be hidden via module export for calling, but not for sub typing
Dan H: field - limited form of properties
John: very very limited - we not stepping in to properties, use methods to simulate properties
Remi: like frozen objects?
John: can simulate that via publishing
Karen: concern vdefault/vwithfield - could expose partially/inconsistenty formed value types
Remi: plans for named parameters?
John: not planning
summary of spec issues:
1. Reflection APIs - being discussed in an email with David Holmes
2. additional exception information - David Holmes proposed adding a cause to IllegalAccessError,
e.g. as a way to report class not found or verifier error or ...
Dan H ok with that approach
3. transitive overriding - Karen sent an email
Dan H will check out - then we can re-review the JVMS overriding description with Dan S
V. MVT binary timing?
We are racing stability bug fixing and binary release process
Remi: The build takes 40 minutes, Running a test takes 4-5 seconds - so looking forward to pre-built binary
Good luck to Bjorn in his new job - we will miss working with you .
Tobi Ajila will be attending these meetings
More information about the valhalla-spec-observers