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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev