groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Using indy vs call-site
Date Wed, 24 Aug 2016 20:33:16 GMT
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) {

for (Shape s in (large list of squares, triangles, circles, etc.)) {

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


-----Original Message-----
From: Jochen Theodorou [] 
Sent: Wednesday, August 24, 2016 4:02 PM
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:
> I googled it up and found these:
>   *
>   * 
> 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.
View raw message