Expected performance difference between ConstantCallSite and unchanging MutableCallSite

[Rémi Forax]

  Le 16/05/2011 15:29, Charles Oliver Nutter a écrit :
> On Mon, May 16, 2011 at 2:50 AM, Rémi Forax<forax at univ-mlv.fr>  wrote:
>> Theoretically, the is no speed difference between a  ConstantCallSite
>> and a MutableCallSite that at some point never mutate.
>> The difference is more that a MutableCallsite has to keep metada
>> to trigger a de-optimization and not the ConstantCallSite.
>>
>> Now, practically, I don't know if hotspot make a difference between them.
>>
>> Charles, in your case you have two options:
>> First, you are able to serialize the literal in the bytecode, the trick is
>> that you can see an array of byte as a String, Terence Parr explains that
>> 2 or 3 years ago at the JVM Summit.
> Yes, I have been using this trick on and off since I started working
> on JRuby in 2006...it works, but it still requires unpacking the bytes
> and constructing a new byte[] every time, which is quite a bit more
> overhead than being able to bind a byte[] or ByteList directly into a
> constant MH.

if you combine it with the bootstrap method mecanism,
you can do the unpacking once when needed.

>> Second, if you know the org.jruby.Ruby instance when generating
>> the code, you can cache it and look it up in the BSM.
> Well, that's a bridge I'm going to have to cross soon. Because the the
> call sites are associated with code at the bytecode level, and the
> call sites are not localized to a given JRuby runtime, we will need to
> isolate jitted code across JRuby instances. At the moment, we do allow
> sharing that code...disallowing that sharing should not be
> particularly difficult.
>
> More difficult, however, will be allowing precompiled code to have
> unique call site information for each JRuby runtime. Normally it's all
> loaded in the same classloader, so isolating them will be trickier and
> require manual intervention. Currently all generated bytecode isolates
> call sites by instantiating a cache and associating it with an
> instance of the script. Each runtime then has its own instance of the
> script, and call sites are isolated. invokedynamic call sites
> essentially move call site information to a static level.
>
> This will affect other languages, I'm sure...so other language
> implementers probably should keep it in mind; invokedynamic call sites
> are bound on a classloader-global basis.

I've this problem with the web part of PHP.reboot:
should I have one runtime by HTTP request or one global ?
I've started with one runtime by request and switch to one global
because it was easier to implement. Clearly the relation between
a runtime and the callsites is far from obvious.

> - Charlie

Rémi