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