Valhalla EG minutes Feb 14, 2018

[John Rose]

On Feb 21, 2018, at 10:51 AM, Daniel Heidinga <Daniel_Heidinga at ca.ibm.com> wrote:
> 
> By "private methods" does that imply both static and instance methods?  I hope not.  
>  
> With NestMates, the JVMS has been updated with the (non-normative) text:
> ---
> Because private methods may now be invoked from a nestmate class, it is no longer recommended to compile their invocation to invokespecial. (invokespecial may only be used for methods declared in the current class or a superclass.) A standard usage of invokevirtual or invokeinterface works just fine instead, with no special discussion necessary.
> ---
> implies that private instance methods will have vtable slots and adding a new private instance method will be a heavy weight operation due to modifying a vtable(!).

vtable slots are an implementation technique not mentioned in the JVMS.
Although it's hard to imagine a good JVM without vtables, the JVMS allows
a range of approaches to them.  Specifically, there's nothing in the JVMS
(AFAIK) that requires private instance methods to be supported by vtable
slots.  The mere fact that we are using the bytecode point named "invokevirtual"
says nothing whether it resolves to a vtable slot or uses some other mechanism
for linkage, as needed.  HotSpot happens to link such instructions in whatever
way most directly reflects the access and morphism of the underlying
method.

All this is to say, what you are saying sounds like a difficultly with one
or more implementations, and not with the logic of the spec.  Am I missing
something?

— John
>  
> Adding static methods, private or not, is less problematic apart from interfaces due to the knock-on effects to iTables.  
>  
> We can live with the later (static) though we'd like to avoid the former (instance).
>