You mentioned the PIC limitation of 1 in Groovy, suggesting that monomorphic
call sites are efficient in dynamic Groovy, but not polymorphic or megamorphic
ones. Is the call site considered polymorphic or monomorphic if the method
called is via a common interface?
void rot90(Shape s) {
s.rotate(90)
}
for (Shape s in (large list of squares, triangles, circles, etc.)) {
rot90(s)
}
You mentioned that indy takes more setup for call site caching, does that imply
that an application relying on a large number of poly/megamorphic call sites is
better served by the pre-indy method?
Jason
-----Original Message-----
From: Jochen Theodorou [mailto:[email protected]]
Sent: Wednesday, August 24, 2016 4:02 PM
To: [email protected]
Subject: Re: Using indy vs call-site
On 24.08.2016 20:42, Raviteja Lokineni wrote:
> Hi all,
>
> Just wanted to gather feedback on which is preferred and why?
> benchmarks too, if any?
>
> Indy source: http://www.groovy-lang.org/indy.html
>
> I googled it up and found these:
>
> *
> http://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
> *
> http://blackdragsview.blogspot.com/2015/01/indy-and-compilestatic-as-t
> ag-team-to.html
>
> What is PIC (from the stack-overflow answer link above), I mean
> abbreviation?
PIC means polymorphic inline cache. Example:
def foo(x) {
x.toString() //1
}
foo(1) //2
foo("a string") //3
foo(1G) //4
during runtime the places 1-4 will be call sites, places of method calls in
this case. The callsites in 2-4 always use the same type, which is why they are
called monomorphic. The callsite in 1 is called with 3 different types: int,
String, BigDecimal and called polymorphic or megamorpic. The distinction is
usually done by how many different types the polymorphic version allows before
it turns megamorphic. A PIC is then a cache with a fast method call path for
the n different types the PIC supports There are different approaches to this,
so I hope I am forgiven for a little bit of oversimplification. Anyway... Java
supports I think a PIC of 3, Groovy currently has only monomorphic versions....
or a PIC of size 1. Well, worse actually, we miss the fallback for the
megamorphic sites. This is the same for Groovy with and without indy.
The difference is that the setup code in indy takes much longer than the older
callsite caching code based on runtime class generation.
But this is something which will be fixed in the future.. for indy. for the
runtime class generation approach I am unsure
bye Jochen
This email message and any attachments are for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message and any attachments.
