How high are he memory costs of polymorphic inline caches?

[Jochen Theodorou]

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:
>> [...]
>>> Smalltalk runtime were implemented on the JVM, PICs would quite
>>> certainly represent a formidable share of the memory footprint.
>>
>> What are the option we are talking about here? Staying with a native
>> Smalltalk VM vs going on the JVM? Because in my opinion a native
>> Smalltalk VM will always be able to shine with a much lower memory
>> footprint than whatever Java can offer today.
>>
>
> The benefits of native Smalltalk VMs are clear, the disadvantages are
> less so:
>
> * Most VMs are not multi-core aware. They only expose green-threads to
> users (they call them "processes") and do not even implement concurrent
> and/or parallel garbage collectors under the hood.
>
> * Smalltalk on the JVM can leverage the sheer amount of Java libraries
> in a way that a programmer could feel very natural. Native VMs need a
> much less transparent approach, e.g., to memory management, when
> invoking Java code (if at all).
>
> * Development of the JVM is very active, involving dozen or maybe
> 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 ;)

[...]
>> And since Groovy was mentioned... Groovy does not have a PIC, only a
>> simple inline cache. And that is mostly because I am still trying to
>> work out a memory sensitive PIC (I think I can write it just didn't yet
>> get the time doing it and compare numbers). But what I can tell is that
>> all those lambda forms in uncompiled callsites are quite a memory toll
>> to pay.
>
> Your opinion about memory usage for the PICs differs from that of Mark
> Roos for his Smalltalk and of Charles Nutter for JRuby. They don't seem
> 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

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org