How high are he memory costs of polymorphic inline caches?

MacGregor, Duncan (GE Energy Management) duncan.macgregor at ge.com
Wed Aug 20 09:08:44 UTC 2014


The memory costs are highly dependent on what combinators are being used
and and how many entries are in the cache, and whether you¹re caching and
reusing any adaption needed to the base method handles. It¹s also going to
change quite radically for the better in 8y40 when various patches have
landed.

A naïve implementation with some combinators wrapping each target method
will normally result in about 100 bytes of retained heap per PIC entry,
but there may be more attached to anonymous class constant pools and so
forth. This memory usage can be reduced through careful caching and reuse,
and as I said there are patches incoming for 8u40 which make a great
improvement.

Regards, Duncan.

On 18/08/2014 11:01, "Raffaello Giulietti" <raffaello.giulietti at gmail.com>
wrote:

>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
>
>



More information about the mlvm-dev mailing list