Hi Raffaello, Mark of RTALK here.
Thanks for the references. Unfortunately, some of them seem
dormant
projects, others seem more experimental than production-ready.
It sounds like you are at the place we were four years ago. A mission
critical
application written in Smalltalk which we wanted to move to a modern set
of underpinnings. In our case the Smalltalk was Digitalk's Smalltalk VPM.
While our application is smaller ( 4000 classes 300K+methods ) the
experiences
are probably similar. I have made three public presentations on these but
due
to lack of interest by others I have not been publishing the code. We are
using
it internally for a production application and are quite happy. I would
be more than
happy to share experiences with you.
To more directly answer your question ( well perhaps not that direct) our
initial
porting involved some analysis of methods and usages. For us a typical
use
case only invoked about 15-20% of the total methods and of these methods
the involved call sites were monomorphic about 75%, trimorphic or less 97%
and megamorphic (> 10 receivers ) very rarely. Only those call sites
invoked
generate java methods. So based on Charles comment I doubt that memory
expansion would be an issue. We have set our max pic size to 10 for now
but
5 would be enough.
A more interesting issue is related to the depth of the GWT chain in the
PIC.
If too deep it could prevent inlining of the code slowing things down. I
have
not researched that yet but others have commented on it.
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>
regards
mark
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
