How high are he memory costs of polymorphic inline caches?

[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.


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.



> Or are we talking about a Smalltalk version on the JVM with a PIC vs a
> simple inline cache? If done right, then imho the PIC can beat the
> simple inline cache in most cases, if not too big (how big may depend on
> the application, but 5 seems to be a good number)
>

5 seems to be a recurring figure.



> 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?


Cheers
Raffaello



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3764 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140819/b325440d/smime.p7s>