How high are he memory costs of polymorphic inline caches?

[Raffaello Giulietti]

Starting with Java 7, the recommended way to implement dynamic languages 
is to build upon invokedynamic (indy), method handles (MH) and their 
combinators, all of which are intrinsically known to the JVM. This 
intimacy allows the JVM to leverage many JIT optimizations already at 
our service for ordinary Java code.

A standard optimization is polymorphic inline caches (PIC). To support 
PICs for dynamic languages on the JVM, best practices recommend to build 
a tree-like structure at each active indy call site, where a (very 
limited) cascade of guard-with-test (GWT) MHs represents the spine of 
the cache.

It seems to me, however, that all this requires a lot of objects for 
each single indy site. Even granted that the JVM can beautifully inline 
the code of the specialized MHs like GWT MHs and bound-MHs (for the 
test), it still needs to maintain a large number of PIC trees. And PIC 
trees cannot usually be shared, since each call site has its own usage 
profile.

So, the question is whether some of you has experience with large scale 
projects written in a dynamic language implemented on the JVM, that 
makes heavy use of indy and PICs. I'm curious about the memory load for 
the PICs. I'm also interested whether the standard Oracle server JVM 
satisfactorily keeps up with the load.

For example, we have a large Smalltalk application with about 50'000 
classes and about 600'000 methods. In Smalltalk, almost everything in 
code is a method invocation, including operators like +, <=, etc. I 
estimate some 5-10 millions method invocation sites. How many of them 
are active during a typical execution, I couldn't tell. But if the 
Smalltalk runtime were implemented on the JVM, PICs would quite 
certainly represent a formidable share of the memory footprint.

More generally, apart from toy examples, are there studies in real-world 
usage of indy and PICs in large applications?
Perhaps some figures from the JRuby folks, or better, their users' 
applications would be interesting.

Thanks for numbers

Raffaello Giulietti


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3764 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140818/a9e793ec/smime-0001.p7s>