Joseph Athman created GROOVY-8298:
-------------------------------------
Summary: 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}
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)
