How high are he memory costs of polymorphic inline caches?

[Raffaello Giulietti]

Hi Mark, hi Charles,

thanks for your interesting figures. The impression is that our code has 
a similar profile, the vast majority of site calls being tri-morphic or 
less, but frankly we never measured it systematically.

It's encouraging to hear from two independent sides that shallow GWT 
PICs have an acceptable memory footprint and that they really enhance 
performance at reasonable costs. In our case, I think that a max depth 
of 4 or even less would make for a nice choice.


To Charles:
> The only "studies" we have are the handful of JRuby users running with
> indy enabled in production. They love the higher performance, hate the
> startup/warmup time, and most of them had to either bump permgen up or
> switch to Java 8 to handle the extra code generation happening in
> indy.
In our case, if at all, we would switch directly to Java 8 or higher to 
avoid permgen related issues. We also hope that tiered compilation can 
amortize startup/warmup costs.


To Mark:
>         In addition, we are using a "persistent" Smalltalk platform, 
> where
>        objects are automatically persisted if reachable from persisted 
> roots
>        and everything happens inside ACID transactions. This 
> functionality,
>        essential to our business, is not supported by the products you 
> mention,
>        but this is another story.
>
> I assume by this you mean persistent to disk.  We use a variant the 
> Datomic
> concepts for this but I don't immediately see how this would affect an 
> implementation
> on the JVM.  Do you do something special to handle this outside of normal
> Smaltalk byte codes or primitives>
>
We are using VisualWorks for development and GemStone/S for 24x7 
production. Yes, by "persistent" I mean "to disk", not in the sense of a 
classical Smalltalk image file but in the sense of an OODB. If we decide 
to experiment with the JVM and indy, we would also need to build the 
underlying support for persistency and ACID transactions.


Cheers
Raffaello

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140819/570412b5/attachment.html>