How high are he memory costs of polymorphic inline caches?
raffaello.giulietti at gmail.com
Mon Aug 18 10:01:52 UTC 2014
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3764 bytes
Desc: S/MIME Cryptographic Signature
More information about the mlvm-dev