Performance of instanceof with interfaces is multiple times slower than with classes
John Rose
john.r.rose at oracle.com
Fri Aug 7 23:50:05 UTC 2020
P.S. I filed https://bugs.openjdk.java.net/browse/JDK-8251318 to record
the suggested fixes in JBS.
> On Aug 7, 2020, at 3:45 PM, John Rose <john.r.rose at oracle.com> wrote:
>
> On Aug 7, 2020, at 12:41 PM, Christoph Dreis <christoph.dreis at freenet.de> wrote:
>>
>> thanks for your elaborate answer. That helps a lot indeed and explains some dead ends I - as a non Hotspot engineer - could have not solved without some hints.
>>
>> I will dig a bit deeper into this now and also follow up on the "big discussion" in the past.
>>
>> Thank you for taking the time - I really appreciate it.
>
> You are welcome!
>
> One thing mentioned in checktype.txt is a lookaside negative cache,
> of one element. That might make your micro go faster (maybe; it’s
> already plenty fast given the short SS array), but wouldn’t scale so well
> to Scala’s use cases. I suspect there’s useful future work to be done.
>
> But, to emphasize: The really interesting improvements, IMO, involve
> both negative and positive tests on *long* secondary super arrays,
> and *less frequent updates* of cross-thread state.
>
> Your benchmark doesn’t touch on either of those questions.
>
> One thing it *might* touch on is a relative slowness for traversing
> a zero-element SS array. I think the repne_scan idiom (scasq) might
> be past its sell-by date; is may no longer be faster than just a regular
> tight loop of load/cmp/jcc. So, a quick experiment you might wish
> to try is to patch out the use of scasq with a bit of replacement code
> and see if it helps. Further down that rabbit hole would be an attempt
> to recognize longer SS arrays and call an out-of-line routine, which
> then could be upgraded to binary search.
>
> — John
More information about the hotspot-runtime-dev
mailing list