<font size=3 face="sans-serif">Hi Raffaello,  Mark of RTALK here.</font>
<br>
<br><tt><font size=2>        Thanks for the
references. Unfortunately, some of them seem dormant <br>
        projects, others seem more experimental
than production-ready.</font></tt>
<br>
<br><font size=3 face="sans-serif">It sounds like you are at the place
we were four years ago.  A mission critical</font>
<br><font size=3 face="sans-serif">application written in Smalltalk which
we wanted to move to a modern set</font>
<br><font size=3 face="sans-serif">of underpinnings.  In our case
the Smalltalk was Digitalk's Smalltalk VPM.</font>
<br>
<br><font size=3 face="sans-serif">While our application is smaller ( 4000
classes 300K+methods ) the experiences</font>
<br><font size=3 face="sans-serif">are probably similar.  I have made
three public presentations on these but due</font>
<br><font size=3 face="sans-serif">to lack of interest by others I have
not been publishing the code.  We are using</font>
<br><font size=3 face="sans-serif">it internally for a production application
and are quite happy.  I would be more than</font>
<br><font size=3 face="sans-serif">happy to share experiences with you.</font>
<br>
<br><font size=3 face="sans-serif">To more directly answer your question
( well perhaps not that direct) our initial</font>
<br><font size=3 face="sans-serif">porting involved some analysis of methods
and usages.  For us a typical use</font>
<br><font size=3 face="sans-serif">case only invoked about 15-20% of the
total methods and of these methods</font>
<br><font size=3 face="sans-serif">the involved call sites were monomorphic
about 75%, trimorphic or less 97%</font>
<br><font size=3 face="sans-serif">and megamorphic (> 10 receivers )
very rarely.  Only those call sites invoked</font>
<br><font size=3 face="sans-serif">generate java methods.  So based
on Charles comment I doubt that memory </font>
<br><font size=3 face="sans-serif">expansion would be an issue.  We
have set our max pic size to 10 for now but</font>
<br><font size=3 face="sans-serif">5 would be enough.</font>
<br>
<br><font size=3 face="sans-serif">A more interesting issue is related
to the depth of the GWT chain in the PIC.</font>
<br><font size=3 face="sans-serif">If too deep it could prevent inlining
of the code slowing things down.  I have</font>
<br><font size=3 face="sans-serif">not researched that yet but others have
commented on it.</font>
<br>
<br><tt><font size=2>        In addition, we
are using a "persistent" Smalltalk platform, where <br>
        objects are automatically persisted
if reachable from persisted roots <br>
        and everything happens inside ACID
transactions. This functionality, <br>
        essential to our business, is not supported
by the products you mention, <br>
        but this is another story.</font></tt>
<br>
<br><font size=3 face="sans-serif">I assume by this you mean persistent
to disk.  We use a variant the Datomic</font>
<br><font size=3 face="sans-serif">concepts for this but I don't immediately
see how this would affect an implementation</font>
<br><font size=3 face="sans-serif">on the JVM.  Do you do something
special to handle this outside of normal</font>
<br><font size=3 face="sans-serif">Smaltalk byte codes or primitives></font>
<br>
<br><font size=3 face="sans-serif">regards</font>
<br>
<br><font size=3 face="sans-serif">mark</font>
<br><tt><font size=2><br>
<br>
<br>
<br>
</font></tt>