How high are he memory costs of polymorphic inline caches?
mroos at roos.com
Mon Aug 18 19:27:09 UTC 2014
Hi Raffaello, Mark of RTALK here.
Thanks for the references. Unfortunately, some of them seem
projects, others seem more experimental than production-ready.
It sounds like you are at the place we were four years ago. A mission
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
are probably similar. I have made three public presentations on these but
to lack of interest by others I have not been publishing the code. We are
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
porting involved some analysis of methods and usages. For us a typical
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
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
5 would be enough.
A more interesting issue is related to the depth of the GWT chain in the
If too deep it could prevent inlining of the code slowing things down. I
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
and everything happens inside ACID transactions. This
essential to our business, is not supported by the products you
but this is another story.
I assume by this you mean persistent to disk. We use a variant the
concepts for this but I don't immediately see how this would affect an
on the JVM. Do you do something special to handle this outside of normal
Smaltalk byte codes or primitives>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev