How high are he memory costs of polymorphic inline caches?
raffaello.giulietti at gmail.com
Tue Aug 19 10:10:49 UTC 2014
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.
> 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
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.
> In addition, we are using a "persistent" Smalltalk platform,
> objects are automatically persisted if reachable from persisted
> and everything happens inside ACID transactions. This
> essential to our business, is not supported by the products you
> but this is another story.
> I assume by this you mean persistent to disk. We use a variant the
> concepts for this but I don't immediately see how this would affect an
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev