RFC: JEP JDK-8221828: New Invoke Bindings

[erik.osterlund at oracle.com]

Hi Stefan,

On 10/11/19 1:02 PM, Stefan Reich wrote:
>  > The proposal for invokevirtual calls is to flatten the vtable to 
> have direct code pointers at a negative offset from the class pointer. 
> This allows dispatching with a single indirect branch (compared to two 
> direct branches for dynamically monomorphic calls today).
>
> Isn't that even independent from the rest of the proposal? Sounds like 
> a smart thing to do. Would there be any downside to putting the vtable 
> directly in the klass structure?

The vtable is already embedded into Klass instances today. However, 
given a base pointer, you have the ability to address at most two 
dynamically sized data structures with statically known offsets from 
that base pointer; one data structure at a negative offset from the base 
pointer, and one at a positive offset. Today, both the vtable and itable 
have positive offsets from the base pointers, hence there is a 
dynamically loaded offset to one of the two. Vtable has been chosen to 
claim that static offset, while itable offsets are dynamically looked 
up, which I guess makes sense because such itable dispatching is already 
quite inefficient today (linearly walking itables twice among other 
things). The idea of putting one of them at a negative offset, could 
indeed be done with today's data structures as well.

Having said that, today's inline cache dispatching mechanism is less 
reliant on the megamorphic bindings that perform table lookup are fast. 
The inline caches exist to hide the poor performance of megamorphic 
calls, by speculating that they are monomorphic. Most are indeed 
dynamically monomorphic, and then no table lookups are performed. My 
approach is to dodge the type speculation machinery and instead optimize 
the megamorphic call mechanism (by optimizing the data structures they 
use) so that the reliance on speculation for monomorphic call 
performance is significantly less. That's why it makes sense with my 
approach to perform more data structure optimizations than makes sense 
with the mechanism we have today. Because I expose all callsites to 
potentially megamorphic calls, leaving the monomorphic speculation trick 
to the branch target buffering mechanisms that hardware has become so 
good at.

/Erik

> Hey, we'd be back to Turbo Pascal speeds where the vtable WAS the 
> class (I believe).
>
> Stefan
>
> On Fri, 11 Oct 2019 at 11:01, <erik.osterlund at oracle.com 
> <mailto:erik.osterlund at oracle.com>> wrote:
> >
> > Hi,
> >
> > I prepared a new JEP [1], about rewriting the method invocation
> > mechanisms in HotSpot. In particular, the aim is to remove inline
> > caches, in an effort to make our code more robust and maintainable
> > (remove 3 nmethod states, ~10000 LOC concurrent code patching stuff,
> > make redefinition and unloading much more straight forward). Instead, it
> > is to be replaced with a table driven approach, leaving speculation
> > machinery to the hardware instead of software. More details are in the
> > JEP description.
> >
> > Feedback is more than welcome.
> >
> > Thanks,
> > /Erik
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8221828
>
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems