[
https://issues.apache.org/jira/browse/GROOVY-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142908#comment-16142908
]
John Wagenleitner commented on GROOVY-8298:
-------------------------------------------
I have seen the problem and have recently added a [callsite benchmark
test|https://github.com/apache/groovy/blob/482e8d3699e5593a60cc8db5523895fbf7235367/subprojects/performance/src/jmh/java/org/apache/groovy/bench/dispatch/CallsiteBench.java]
that shows indy's performance issue with poly and mega morphic calls.
Currently each time a new receiver is found at a callsite it is relinked.
{quote}It would be nice if Groovy could at least identify this situation and
prevent itself from getting in to the de-opt storm.{quote}
I think a PIC is needed in order to improve performance in this situation.
[~blackdrag] might be able to correct me if I'm wrong about Groovy currently
having a single inline cache.
> 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
>
> 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
(v6.4.14#64029)
