Finding MAX_ARGS

[chanwit]

Hello all,

Here's a result so far from profiling my Grails app to find the
possible MAX_ARGS for MethodCallerMultiAdapter.

N=0 : 9755
N=1 : 17451
N=2 : 7059
N=3 : 812
N=4 : 231
N=5 : 0
N=6 : 46
N=7 : 0
N=8 : 0

So, I think the possible value of MAX_ARGS would be 6 or 7. I think if
ScriptBytecodeAdapter can have methods invoke*0 to invoke*7 then
invoke*N, it will help much for JIT in the future. What do you think?

Cheers,

Chanwit

--
Chanwit Kaewkasi
PhD Student,
Centre for Novel Computing
School of Computer Science
The University of Manchester
Oxford Road
Manchester
M13 9PL, UK

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Chanwit Kaewkasi schrieb:

> Hello all,
>
> Here's a result so far from profiling my Grails app to find the
> possible MAX_ARGS for MethodCallerMultiAdapter.
>
> N=0 : 9755
> N=1 : 17451
> N=2 : 7059
> N=3 : 812
> N=4 : 231
> N=5 : 0
> N=6 : 46
> N=7 : 0
> N=8 : 0
>
> So, I think the possible value of MAX_ARGS would be 6 or 7. I think if
> ScriptBytecodeAdapter can have methods invoke*0 to invoke*7 then
> invoke*N, it will help much for JIT in the future. What do you think?

well, with call site caching ScriptBytecodeAdapter is loosing its
importance. What you describe was indeed planed in the past, but those
invoke methods create mega morphic call sites, which hotspot doesn't like.

If it were a ScriptBytecodeAdapter per class, then this would look
different already. So basically this part is still there as fallback and
for compatibility.

Of course MethodCallerMultiAdapter is not used only for that. It is for
example also used to directly interface with DefaultTypeTransformation.
But the pattern is a bit different there.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jochen Theodorou schrieb:
[...]

> well, with call site caching ScriptBytecodeAdapter is loosing its
> importance. What you describe was indeed planed in the past, but those
> invoke methods create mega morphic call sites, which hotspot doesn't like.
>
> If it were a ScriptBytecodeAdapter per class, then this would look
> different already. So basically this part is still there as fallback and
> for compatibility.
>
> Of course MethodCallerMultiAdapter is not used only for that. It is for
> example also used to directly interface with DefaultTypeTransformation.
> But the pattern is a bit different there.

woah, that mail poped up for no reason... sorry guys.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email