[
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)
