How high are he memory costs of polymorphic inline caches?

[Mark Roos]

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140818/6c15c5fd/attachment.html>