[jira] [Comment Edited] (GROOVY-8298) Slow Performance Caused by Invoke Dynamic

["Daniel Sun (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833085#comment-16833085 ] 

Daniel Sun edited comment on GROOVY-8298 at 5/4/19 3:35 PM:
------------------------------------------------------------

[https://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy]

[~blackdrag] said:
{quote}The answer is easy actually quite easy, Groovy does not have a PIC yet.

... or you can say that we usually have an inline cache of size 1. This means every time you change the list array type, it will invalidate all caches that did exist before and the cached version is thrown away. That is for normal Groovy almost the same as for indy, only that normal Groovy uses runtime generated classes and indy uses invokedynamic/lambda forms. But lambda forms are initially slower, while peak performance is better. Basically what you do is let hotspot start from scratch for most of the method calls, preventing it to apply the optimizations all the time. Of course that is not your fault, but the fault of Groovy for not having a PIC yet. and just to make this very clear... this is no problem of the language, it is simply something I did not yet get to implement.

JRuby on the other hand has a PIC and thus has not to suffer from the overhead of creating new method handles all the time.
{quote}


was (Author: daniel_sun):
https://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
{quote}
The answer is easy actually quite easy, Groovy does not have a PIC yet.

... or you can say that we usually have an inline cache of size 1. This means every time you change the list array type, it will invalidate all caches that did exist before and the cached version is thrown away. That is for normal Groovy almost the same as for indy, only that normal Groovy uses runtime generated classes and indy uses invokedynamic/lambda forms. But lambda forms are initially slower, while peak performance is better. Basically what you do is let hotspot start from scratch for most of the method calls, preventing it to apply the optimizations all the time. Of course that is not your fault, but the fault of Groovy for not having a PIC yet. and just to make this very clear... this is no problem of the language, it is simply something I did not yet get to implement.

JRuby on the other hand has a PIC and thus has not to suffer from the overhead of creating new method handles all the time.
{quote}

> Slow Performance Caused by Invoke Dynamic
> -----------------------------------------
>
>                 Key: GROOVY-8298
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8298
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.12
>            Reporter: Joseph Athman
>            Priority: Critical
>
> I have been researching a problem my application is having where performance seems to be much slower than I would expect. After a lot of research I found GROOVY-6583 which seems to have the same symptoms (though not caused by the same method calls). After more research I found someone who reported a similar issue and created a [sample application|https://github.com/dwclark/deopt-storm] which reproduces the issue. I am seeing the same behavior he discusses which is that using the JIT probe I'm able to see that our production application is constantly uses a large amount of CPU on JIT activities for days on end, it never gets better. 
> When doing a thread dump of our application we often see 20-50 threads all stuck on this same stack trace:
> {code:none}
> "qtp2078714399-360525": running, holding [771bcf60]
> 	at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native Method)
> 	at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258)
> 	at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)
> 	at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909)
> 	at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969)
> 	at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228)
> 	at java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH)
> 	at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH)
> 	at java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker)
> 	at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH)
> 	at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH)
> {code}
> No matter how long the application runs it will continue to show this behavior. From what I've read I think our code causes this problem because we run code that looks like this:
> {code:java}
> // List of objects will consistent of 2-20 instances of classes 
> // which all implement the same interface which defines the runMethod. 
> // Each concrete implementation will have it's own unique behavior
> def resultList = listOfObjects*.runMethod()
> {code}
> Turning off invoke dynamic compilation and using the regular groovy-all jar seems to eliminate the issue and result it overall better performance.
> It would be nice if Groovy could at least identify this situation and prevent itself from getting in to the de-opt storm.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)