Valhalla EG minutes Aug 30

[Karen Kinnear]

Reminder, next meeting Wednesday Sept 13, 9am PT/noon ET/
new dial-in: https://oracle.zoom.us/j/5249803466

AI: All - review feedback on JVMS for nestmates for meeting on September 13th
AI: Dan/Bjorn - do some experimentation with condy and give feedback on condy JVMS
AI: All - nestmates attribute name proposals for Dan Smith
AI: Dan Smith - invoke interface allowing private method invocation - is it ok to allow for older class file versions?
AI: All - for nestmates - send to Dan Smith (and copy us all) implementation paths that would need to check for
nest mate membership - so we can ensure the JVMS reflects potential LinkageErrors etc.
AI: Maurizio - send example to Bjorn of code that works today, but would not work with eager nest top loading
AI: What does reflection get_enclosing_class do if for example the enclosing class has been deleted?
AI: Spec leads: discuss with Groovy & Scala folks any issues with removing ACC_SUPER support. Also whether this change needs to be class file version specific.

Attendees: Remi, Bjorn, Dan Smith, John, Frederic, Lois, Maurizio, Karen

MVT JVMS
1. getfield 
Remi: getfield bytecode for reading of field in Derived Value Class needs similar special handling as vwithfield in allowing the Value Capable Class read access to a private field in the DVC. Dan ok with proposed change

Question: timing of nestmates relative to MVT so we could propose VCC and DVC as nestmates in MVT?
Answer: Expect MVT to be available as early access, so before nestmates
Q: Remi: How do you add to a nest if you can’t add to the nest members attribute?
A: John: You can add dynamic nest members
Editor’s note: I think we need to clarify what reflection shows 

Implementation note: Remi: vwithfield currently has a bug - VCC can not change the field in DVC - throws IAE
====
Condy JVMS:

Remi: Request for a true constant pool constant - today restricted to LDC or indy in BSM
Want to use for constant pool patching like unsafe.defineAnonymousClass
Bjorn: can we dynamically load the BSM name?
John: Larger changes could lead to security issues. We are expecting MethodHandle Combinators.
Want constant pool template abilities, prefer to use MethodHandles as template carrier. Goal is
to quantify over types not over names

Bjorn: BSM args can be condy? 
A: Yes
Discussion of implementation optimizations for condy. Note it uses a BootstrapMethod.

Remi: bootstrap issue - can’t use lambdas - just like today you can’t use BSM until e.g. java.lang.invoke is loaded
John: think about constant lambdas during bootstrap. Longer term AOT and jlink should help with condy

Karen: concern about JVMTI spec and redefineclasses ability to change attributes, so BSM attribute could change.
John: sent an email reply

John:
Condy phasing:
1) basic condy
2) jumbo arty with args for BSM in general
3) BootStrapCallInfo - API point - later
4) Constant_Group - even later - not yet spec’d

Lazy resolution may be delayed, initially all resolution will be eager

Remi: Constant_Group in constant pool or as an attribute?
John: due to size - potentially 1000’s, maybe attribute
Bjorn: what is a “kiddie pool”? What about constant pool holes?
John: specialization - plugs small number of constant pool holes
[editor’s note: John - what was a kiddie pool referring to?]

Dan Smith: Why 2 arguments? What a Lookup and a separate BSCI?
John: Put Lookup separately - it is uniquely security sensitive
Remi: Lookup isn’t constant
John: can LDC a Lookup

====
Nest mates

Remi: Good with not changing invokespecial
Naming bikeshed: What about changing “MemberofNest” to “Nest” - similar to superclass
John: original challenge was the direction - was this the declarer/owner of nest or a member?
See AIs for attribute name proposals.

Q: Are the invoke interface changes classfile version specific?
Note: Can still do invoke special of a local private interface method since it falls under the superclass method invocation
If Invokeinterface throws an exception today for invocation of a private method, is it ok to eliminate this error in future with
existing class file version? 
AI: Dan to investigate
Note: check current TCK tests

John: LONGER TERM: goal to deprecate invoke interface and just have a single virtual invocation with either a MethodReference
or an Interface MethodReference. 
Editor’s note: internally sounds like both IBM and Hotspot would continue to use an internal byte code - at least for now - the
MethodReference and InterfaceMethodReference rules are different, and for hotspot the caching of resolved method is different - for
classes we need a virtual method table index, for interfaces we need an interface method table index relative to the super interface, i.e. two pieces of information

Karen: Future: would like to evolve away from ACC_SUPER allowing invoke special to refer to an indirect super class which requires re-resolution relative to the direct super class.
John: File a specification RFE and get started.
Karen: Need javac to stop using invoke special on java.lang.Object references that have not been overridden at compile time.
John: longer term goal: stricter vm - 
AI: discuss with Groovy & Scala folks any issues with this change. Also whether this change needs to be class file version specific.

Dan: Bigger discussion - can we remove support for older class file versions?
Remi: Sees 1% still running 1.0, 1.1. Tools like ASM can choose not to support
John: defacto policy - continue to run older version


Maurizio:
Need to clarify in specification the timing of checking nest membership. We do not want this in the verifier since it can cause
errors in code that works today.
   If you take an existing example of code in which javac generates a trampoline to access for example an outer class member,
if you then delete the outer class, or if the inner class can not see the outer class due to it being loaded by a different class loader
 - today if you run code that does not use the trampoline it will succeed. 
With nestmates, if the outer class is the nest holder, if you delete that class, then you can not run the inner class since the
verifier will fail trying to check nest membership.

Bjorn: propose load supers and nest top at the same time - issue if a subclass is the nest owner, you can run into circularity issues,
so proposed delay until after loading the class but before verifying the class to avoid circularity.

Maurizio: propose changing the specification to first touch
i.e. first access check of a private member trying to touch a nest mate
Dan: note: if the member is actually private, should not need to perform the nest mate check, so no need to touch the nest
— method handle, access checks which need to know membership would trigger the check and potentially
throw an exception. i.e. any path that would check nest membership.
Bjorn: agreed with proposal

Karen: Dynamically adding a class into a nest should throw an exception for an invalid nest mate.

Remi: A dynamic check would throw a more meaningful error at a time that would be expected - e.g. an IllegalAccessError with
a meaningful message (or cause)

AI: send to Dan Smith - implementation paths that run into checking nest membership

Bjorn: Issues with checking nest membership
- not find a nest top, not claim me in the nest 
[Bjorn - my notes were not clear on what you were asking]
John: For example, an IAE may wrap a LinkageException
Karen: Reflection - what should reflection return when it runs into errors finding nest members
   e.g. if you ask for all
Possible approach? What does get_enclosing_class do today? T
Remi: for dynamic languages - use reflection to check if you can do something so need behavior to be the same as byte code
behavior