How high are he memory costs of polymorphic inline caches?

[Florin Mateoc]

Raffaello Giulietti <raffaello.giulietti at ...> writes:

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

I don't think this is really an issue for an already written massive
application such as yours. We have a similarly large Smalltalk application
that we successfully translated to Java (source-to-source, that's yet
another option) and, since it is already very complex, mapping it to a more
complicated concurrency model (native threads vs green threads) is quite a
challenge. The only place where we are truly using multiprocessing is to
parallelize the startup which is now much longer, since Java does not have a
snapshotting capability - in short, I don't think there is any gain to be
had here.

> * 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).
> 

Even this comes with pitfalls for a large application. We now have multiple
libraries, sometimes different versions of the same library, coming from
different prerequisite chains, many of them providing again and again the
same little utility which was already implemented in the main application,
but nobody bothered to look for it - not that it's an easy challenge to
already know what's there for new developers.

I should also add that the memory footprint has at least doubled compared to
Smalltalk, and this is with a 32-bit JRE (we run with both).

At least it does not run slower (nor faster).

That said, the other arguments still stand.

Cheers,

Florin