Testing RTALK on JDK8 MLVM

[John Rose]

On Jul 18, 2012, at 4:24 PM, Mark Roos wrote:

> While generally faster than 7u2 I do have a strangeness in that when my 
> target is a chain of methodHandles its much slower then when my target 
> is a methodHandle-callsite-chain of handles.  My second case is where I add 
> a debugging trap at the start of each chain.  Its slower by  4 to 1. 

The use case of a MH/CS chain is interesting.  I have made a note to build a micro benchmark and see if anything is obviously wrong.

(I will also gladly accept micro benchmarks from the community!)

> 7U2 does not seem to do this. 
> 
> I would guess the issue is that hot spot optimizes the second but not the 
> first.  Perhaps some inline depth or related limit?  Are they any runtime flags 
> I should play with?  ( tiered compile?) 

The best peak performance comes from -server, which (IIRC) is the same as -XX:-TieredCompilation.
If you run with -XX:+PrintCompilation and -XX:+TieredCompilation, you will see methods getting compiled twice at levels 3 and 4.  For example:

…
    144   43       3       java.lang.String::indexOf (7 bytes)
                              @ 3   java.lang.String::indexOf (70 bytes)   callee is too large
…
   4972  550       4       java.lang.String::indexOf (7 bytes)
                              @ 3   java.lang.String::indexOf (70 bytes)   inline (hot)
                                @ 66   java.lang.String::indexOfSupplementary (71 bytes)   too big
…

This says that at 0.144 seconds, we got a profiled-client (tier 3) compilation, and after almost 5 seconds it was recompiled by the server compiler (tier 4).

The "@" lines come from -XX:+PrintInlining.

> In summary I am happy with the progress.  Currently my fully dynamic implementation 
> of Hanoi is about 2x slower than a pure Java version. ( 20% better than 7u2). 

Thanks, Mark.  It's great working with you on the bleeding edge.

We think the new format for MHs will allow us to make optimizations more easily.  In other words, there is suddenly lots of low-hanging fruit.  Chris Thalinger did a small change yesterday that sped up one of our benchmarks by a factor of 1.8.  This is probably reflected in your numbers already.  But we'll do more!

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120719/7cc8599d/attachment-0001.html