groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Wagenleitner (JIRA)" <>
Subject [jira] [Commented] (GROOVY-8298) Slow Performance Caused by Invoke Dynamic
Date Sat, 26 Aug 2017 19:54:00 GMT


John Wagenleitner commented on GROOVY-8298:

I have seen the problem and have recently added a [callsite benchmark test|]
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:
>             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|]
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(
> 	at java.lang.invoke.MutableCallSite.setTarget(
> 	at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(
> 	at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(
> 	at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(
> 	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

View raw message