Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64

Tue Sep 15 10:04:10 UTC 2020

Thanks for your quick reply.

>    I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub.
> every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test.
>    Below is test result on my machines, it looks slow loop has more improvement than origin one.

Good, thanks for the numbers. I'm curious have you observed any 
improvements on larger scale benchmarks or real world apps?

I'm asking because linear scan is already far from optimal when there 
are many superinterfaces present.

Kevin: itable_stub was found hot on several online applications. So I started to work on this. Now I don't have chance to verify it online. So I uses microbenchmarks to verify. I will
test with some benchmarks. 

>    I think lookup_interface_method can be reused as fast path. And it is also used by templateTable::invoke_interface and generate_method_handle_dispatch.
> My implementation in slow path need more registers (6 registers so far), I need to check if there's register conflict in these methods. I'd like to keep a separate
> slow path implementation. How do you think about it?

Frankly speaking, I'd like to avoid the duplication.

Kevin: Ok, I will try to merge them.

Also, absence of guarantees about order of interfaces in the itable 
complicates things: REFC and DECC can be encountered in arbitrary order 
and the pass should take that into account. For example, I don't see 
early exit on success in slow variant, so every lookup has to go through 
the whole itable irrespective of whether it succeeds or fails. I 
attribute that to the complications induced by aforementioned aspect.

Kevin: I use a counter for matching. If it reaches zero, the iteration can exit early.

And speaking of the overall approach (as it is implemented now), IMO 
increased complexity doesn't worth it. If interface calls become a 
bottleneck, the problem lies not in itable stub, but the overall design 
which requires linear scan over itables. It's better to put the effort 
there than micro-optimizing the stub.

Kevin: I agree we can improve itable design. My initial think is jvm may reorder itable at safepoint. I can take it as a follow up optimization.

But I'm happy to change my mind if the rewritten implementation makes it 
easier to reason about the code.

(FTR subtype checks suffer from a similar problem: unless 
Klass::_secondary_super_cache catches it, subtype check for an interface 
does a linear scan over _secondary_supers array.)

Regards,
Kevin

------------------------------------------------------------------
From:Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Send Time:2020年9月15日(星期二) 17:03
To:蒯微(麦庶) <kuaiwei.kw at alibaba-inc.com>; hotspot-dev <hotspot-dev-retn at openjdk.java.net>; kuaiwei <github.com+1981974+kuaiwei at openjdk.java.net>; hotspot-dev <hotspot-dev at openjdk.java.net>; hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64

>    I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub.
> every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test.
>    Below is test result on my machines, it looks slow loop has more improvement than origin one.