Summary: Could we please allow eager loading for value types in the locally declared method signatures prior to preparation for LW1?
Without that we seriously risk being able to offer an LW1 early access binary for the JVMLS. We believe it is more important to get this into people’s hands for experimentation and feedback than to delay the eager loading at this time. Details: At our EG discussion on June 20, 2018, we discussed the proposal for Value Types Consistency checking at http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf <http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf> Part of the proposal for checking value type consistency relative to the actual type was for locally declared methods. The proposal was to check the value types in arguments/return type before preparation of the declaring class. During the meeting, there was a request to explore whether we could either: 1) delay checking the value type consistency until an attempt to resolve the method for invocation, or 2) write the JVMS is such as way as to allow eager loading, but only throw an error related to the eager loading at method resolution. My understanding is that the goals of this are two-fold: 1) if the method is never called, the rest of the code will continue to run 2) reduce eager loading We have started this investigation, and there is non-trivial complexity in implementing either of these approaches, and we would like more time to explore how to make this possible, after making LW1 available. Some aspects of the implementation complexity that we have identified so far: a) At method resolution time, if there is a mismatch in value type consistency between the declaring class and the actual type in the signature, then there is also a mismatch in all classes that have overridden the current method. This is particularly painful with default methods in interfaces. b) We need to ensure that we catch all method resolution, through all of the alternate accessor paths, including MethodHandles, VarHandles, Reflection, JNI, so that we catch both the specification and implementation changes. c) Our favorite, invokespecial ACC_SUPER, needs special handling, since it performs selection which is not based on overriding, but based on virtually re-resolving. d) Pass by value calling convention optimizations depend on loading the actual type. Loading of the parameter types on first method resolution implies that if the caller is compiled, the caller method requires deoptimization/recompilation to pass arguments by value for future calls, which is a performance cost. e) If we modify the specification to allow eager loading, and save errors to throw at method resolution, we need to work through the JVMS question of which errors would be saved (e.g. OOME, SOE might be thrown as part of the implementation vs. saving LinkageError), as well as designing a new implementation mechanism to repeat exceptions relative to signatures used for method resolution. thanks, Karen
