How high are he memory costs of polymorphic inline caches?
raffaello.giulietti at gmail.com
Mon Aug 18 14:54:05 UTC 2014
On 2014-08-18 15:15, Remi Forax wrote:
> On 08/18/2014 12:01 PM, Raffaello Giulietti wrote:
>> 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.
>> More generally, apart from toy examples, are there studies in
>> real-world usage of indy and PICs in large applications?
>> Perhaps some figures from the JRuby folks, or better, their users'
>> applications would be interesting.
>> Thanks for numbers
>> Raffaello Giulietti
> There are several Smalltalk implementations that already use
> invokedynamic, so you can ask their maintainers for data, on top of my
> head you have Rtalk by Mark Roos , Magic (smalltalk like), you can
> ask Duncan Mac Gregor , Redline Smalltalk by James Ladd  and
> Gravel Smalltalk by Wouter Gazendam .
> I hope I've not forgotten somebody :)
>  http://www.drdobbs.com/jvm/rtalk-smalltalk-on-the-jvm/231500288
>  http://www.infoq.com/news/2012/12/magik-jvm-port
>  https://github.com/redline-smalltalk/redline-smalltalk
>  https://github.com/gravel-st/gravel
Thanks for the references. Unfortunately, some of them seem dormant
projects, others seem more experimental than production-ready.
In addition, we are using a "persistent" Smalltalk platform, where
objects are automatically persisted if reachable from persisted roots
and everything happens inside ACID transactions. This functionality,
essential to our business, is not supported by the products you mention,
but this is another story.
Apart from Nashorn, JRuby and Groovy, are there other *widely* used
dynamic language implementations known to run on the JVM and using indy
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3764 bytes
Desc: S/MIME Cryptographic Signature
More information about the mlvm-dev