[
https://issues.apache.org/jira/browse/GROOVY-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18074745#comment-18074745
]
ASF GitHub Bot commented on GROOVY-11935:
-----------------------------------------
blackdrag commented on code in PR #2473:
URL: https://github.com/apache/groovy/pull/2473#discussion_r3107787815
##########
src/main/java/org/codehaus/groovy/vmplugin/v8/IndyInterface.java:
##########
@@ -320,48 +320,50 @@ public static Object fromCache(CacheableCallSite
callSite, Class<?> sender, Stri
*/
private static MethodHandle fromCacheHandle(CacheableCallSite callSite,
Class<?> sender, String methodName, int callID, Boolean safeNavigation, Boolean
thisCall, Boolean spreadCall, Object dummyReceiver, Object[] arguments) throws
Throwable {
FallbackSupplier fallbackSupplier = new FallbackSupplier(callSite,
sender, methodName, callID, safeNavigation, thisCall, spreadCall,
dummyReceiver, arguments);
+ final Object receiver = arguments[0];
Review Comment:
So what will happen in this case?
```
def foo(receiver){receiver.bar()}
class A{ static bar(){1} }
class B{ static bar(){2} }
foo(A)
foo(B)
foo(new A())
foo(new B())
```
for the first two calls the class is the same, since receiver.getClass will
return Class for both. But that is imho a bug, that existed already before
`callSite.getAndPut(receiverClassName,...`. Also I think the later two cases
are not considered here... why not? If we really only want to optimize
`A.bar()` style calls, then we should check the receiver type through the
callsite type, not the runtime type.
> Set invokedynamic call site target immediately for static method calls to
> enable earlier JIT inlining
> -----------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11935
> URL: https://issues.apache.org/jira/browse/GROOVY-11935
> Project: Groovy
> Issue Type: Improvement
> Reporter: Daniel Sun
> Priority: Major
>
> Static calls are inherently monomorphic (receiver is always a Class object) ,
> so no need to wait for the 1,000-hit threshold.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
