How high are he memory costs of polymorphic inline caches?

[Jochen Theodorou]

Am 18.08.2014 12:01, schrieb Raffaello Giulietti:
[...]
> For example, we have a large Smalltalk application with about 50'000
> classes and about 600'000 methods. In Smalltalk, almost everything in
> code is a method invocation, including operators like +, <=, etc. I
> estimate some 5-10 millions method invocation sites. How many of them
> are active during a typical execution, I couldn't tell. But if the
> 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.

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)

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.

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