RFC: JEP JDK-8221828: New Invoke Bindings

[Stefan Reich]

Hi Erik, I understand, thanks for the explanation. Sounds reasonable.

On Fri, 11 Oct 2019 at 13:24, <erik.osterlund at oracle.com> wrote:

> 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> 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
>
>
>

-- 
Stefan Reich
BotCompany.de // Java-based operating systems