Valhalla EG minutes October 25, 2017

[Karen Kinnear]

Attendees: Remi, Dan H, John, Mr Simms, Frederic, Lois, Karen

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

IV Nestmates: 
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?
1-2 weeks
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

thanks,
Karen