How high are he memory costs of polymorphic inline caches?

Raffaello Giulietti raffaello.giulietti at
Wed Aug 20 12:18:24 UTC 2014

On 2014-08-20 12:51, Jochen Theodorou wrote:
> Am 19.08.2014 12:49, schrieb Raffaello Giulietti:
>> On 2014-08-18 20:48, Jochen Theodorou wrote:
>>> Am 18.08.2014 12:01, schrieb Raffaello Giulietti:
>>> [...]


>> hundreds of people. Unfortunately, not so for most Smalltalk VMs,
>> perhaps with the exception of Cog.
> Yes... given the background it is no wonder. That's why I was wondering
> about the constraints of the decision. Imho the JVM could be a better
> host for all the reasons you pointed out above. But the step comes not
> for free and extended memory costs will most likely be one of them...
> given that the old VM did its job properly ;)
> But given your application no doubt you will have to face two very big
> problems if you want to make use of those advantages. One is the
> translation of the Java memory model to smalltalk and your application
> being aware of that. The other is integration with Java libraries. Java
> has a different object model than smalltalk. And that is fine till you
> have to interface with Java, that expects a Java object of a certain
> class and wants to interact with it. This can turn into a huge amount of
> plumbing code, that you cannot always hide. So you should be aware, that
> you may end up translating more and more of your code to a JVM language
> that uses the Java object model more or less.
>> To be clear, we have no real pressure to switch to an implementation of
>> Smalltalk/JVM in the short term, we are just exploring the possibility.
>> Apart from the lack of support for modern multi-everything hardware
>> architectures, we are quite happy with our Smalltalk platforms. But in
>> the long term general purpose Smalltalk implementations must face
>> reality and become multi-*, less they face extinction.
> I agree. And if you see it as a long term investment, then things should
> be fine. I mean even if you take on of the existing implementations it
> may take a while to get it to behave like you want. I would contact some
> of the authors and ask for their opinion. Well... at least one of them
> is answering here already ;)
> [...]


>> to be very worried about this point. Have you some figures, in
>> bytes/callsite perhaps?
> I am not sure you can really give definitive numbers. I could talk now
> about bugs and all, but fact is that this area in the JVM is not done
> and still undergoes bigger changes.
> My opinion is based on the experience that some users did complain about
> the indy version needing more memory and my personal observations for
> example about a simple Groovy program being able to run in about 40MB
> memory, but needing quite a bit more with indy. Since I can observe the
> memory drain with a small program already, and since I know that handles
> are not that reusable yet...
> But I think Mark Roos gave some figures ;)
> bye Jochen

Thanks Jochen
I very much appreciate all opinions based on real-world experience.

More information about the mlvm-dev mailing list