On Jul 13, 2018, at 3:55 AM, fo...@univ-mlv.fr wrote: > > Let's try …
OK! (Caveat: I am certain this is post-LW1.) > First, what we want is to have an algorithm that find the calling layout of a > method, unlike with references were there is only one possible calling > layout, because value types can be flattened, there are several possible > calling layouts when value types are involved. > > We want: > - to defer the loading of a value type class until we need to actually call a > method that contains that value type in its descriptor > - a familly of methods (the tree of overridden methods) to have the same > calling layout so VMs can use vtables if they want > > The ideas: > - decouple the construction of the vtable from finding the calling layout of > a method, so instead of having one pass that constructs the vtable, creates > the slots etc and determines the calling layout, we now separate in two > phases. Building the vtable only find the slots but not the calling layout of > the methods, we need a supplementary phase to determine the calling layout of > a method > - the calling layout of a method is determined by the information (the value > types declared in the ValueTypes attribute) of the class that creates the > vtable slot for that method > > So vtables are created as usual, and when the interpreter does a method call, > after having found the vtable slot, it will try to resolve the calling layout > using the ValueTypes attribute of the class that have created that slot. So > value type of that ValueTypes attribute that are part of the method > descriptor will be loaded at that point. Yes. What we are talking about here is a new resolution step for method descriptors. The v-table setup (and/or override tree detection) looks only at the strings, but before the first call the strings (parts of them) need resolution. It looks like we are inventing a new JVM phase here: value type resolution. Or (calling Dan!) maybe we just add a bit of language to the JVMS that says that resolving a method call entails resolving its value types. No, it's not just a little bit of language, because the resolution needs to walk up and down the class/interface hierarchy that defines the method's override family. These are the same paths as are walked by class loader constraint checking, which is one of the more complex parts of the JVMS. Basically, method overriding needs to re-run class loader constraint checking, just for one override family, but with newly-loaded knowledge about value types. That raises a possible counter-argument to the point that eager resolution of VTs is "not JVM-like". Yes, eager loading is not JVM-like, but if the alternative is a new JVM phase, which is *even less* JVM-like, then maybe we just do the early load and call it good. It's a judgement call: Is the complexity of the new phase warranted? > For default methods (which are injected in the vtable hierarchy), if we > follow this algorithm, the calling layout of a default method should be > deteermined using the information of the class that receives the default > methods (the one that creates the vtable slot) and not from the ValueTypes > attribute of the interface making the attribute ValueTypes in an interface > useless. I don't know if it's a good idea or not ? I think in practice it will be necessary, especially given the delay in reporting errors. A program will be too busy doing work to tolerate ICCE's on random method calls due to non-local effects (somebody else got to the interface method first, with a different opinion). This means interface default methods (at least) need suites of varying adapters. For me this re-raises the question of what happens if a *class* in an override tree tries to inject a bad opinion. That mustn't be allowed to spoil scalarization but OTOH two bad classes might want to exchange nulls through their own part of the override tree. (Dirty habit!) A full story needs to say how those guys can continue with their nulls, without hurting optimization for the new code, in the same override tree. Or else we need grounds for telling the null-users to go elsewhere, with with prejudice (ICCE) or permission (separate calling sequence, separate v-table slot). Yuck.
