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

Reply via email to