JDK-8150717 : Bootstrapping invokedynamic call sites can significantly increase time spent in the VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-02-26
  • Updated: 2016-02-26
  • Resolved: 2016-02-26
Related Reports
Duplicate :  
JDK-8086045 - Improve the java.lang.invoke first initialization costs
Relates :  
JDK-8148940 - java/lang/ref/FinalizeOverride.java can time out due to frequent safepointing
Relates :  
JDK-8148483 - JEP 280 Integration
Description
Replacing a single invokestatic call with an invokedynamic call is sufficient to increase the number of compilations by 2X, the time spent in the compiler by 2-3X, and in general the time spent in the VM (when the user application is not making progress). The startup time of the VM is also likely to increase, as for a number of methods bootstrapping happen when the method is first executed during VM startup.

A good example of this problem is JDK-8148940 that was triggered by the the Indify String Concatenation project (JDK-8148483). The Indify String Concatenation project changes 'javac' to generate invokedynamic calls for string concatenations (instead of "traditional" invokes") and as a result is a good example of the problem.

It would be good to understand how much slowdown this problem affects VM startup time and the VM's performance in general. It would be also good to know if other invokedynamic calls sites, e.g., those generated for lambda expressions or by nashorn, suffer from the same problem.
Comments
Aleksey, thank you for the data! So, initializing the java.lang.invoke infrastructure causes more methods to be executed and also more methods to be compiled that can contribute to the startup overhead of the VM. So I'm wondering: Is this a problem for us? We have to execute more methods, so we loose time with that anyway. We can try to make the execution fast, e.g., by AOT compiling the whole or part of the infrastructure. I'm wondering what fraction of the java.lang.invoke infrastructure can an AOT compiler successfully deal with (given that some part of the infrastructure is generate at runtime, if I understand well how the infrastructure works).
26-02-2016
Vladimir, the number of compilations also increases with -Xmixed. For example: linux-x86_64, -Xmixed configuration | execution time | #GC safepoints | #compiled methods ========================================== no-ISC | 0.2s | 8 | 21 ISC | 2.8s | 247 | 102 solaris_sparcv9, -Xmixed configuration | execution time | #GC safepoints | #compiled methods ========================================== no-ISC | 9s | 6 | 30 ISC | 32s | 105 | 91 All data comes from JDK-8148940 https://bugs.openjdk.java.net/browse/JDK-8148940?focusedCommentId=13904102&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13904102
26-02-2016
Yes, there's definitely much more code touched when linking an invokedynamic call site. But it is mostly a one-time activity since the j.l.i framework is shared and compiled only once (there are much less code generated on-demand). But I don't see any problem here - -Xcomp is designed to stress JIT compilers and it does pretty good job considering the compilation logs provided.
26-02-2016
FTR, a simple -XX:+PrintCompilation experiment with a single String concatenation with and without -Xcomp: http://cr.openjdk.java.net/~shade/8150717/compilation-oob.txt http://cr.openjdk.java.net/~shade/8150717/compilation-Xcomp.txt While going through java.lang.invoke infra, of course, causes more compilations, it is unlikely we can or should do anything here. In oob case, we seem to be mostly tripping the already warm methods into hot ones; and in -Xcomp case we just go through many methods that constitute java.lang.invoke infra.
26-02-2016
[~vlivanov], you have more knowledge about invokedynamic/lambda expressions work. Could you please take a look at this?
26-02-2016