Expected performance difference between ConstantCallSite and unchanging MutableCallSite

[Rémi Forax]

On 05/16/2011 09:52 AM, John Rose wrote:
> On May 15, 2011, at 5:36 PM, Charles Oliver Nutter wrote:
>
>> Can I get a rough guesstimate from the JVM guys how much more overhead
>> is involved in accessing a never-changed MutableCallSite versus a
>> ConstantCallSite? I have a few places where I want to use
>> invokedynamic to lazily initialize some literals. They'll never change
>> after the initial construction, but I can't create them in the
>> bootstrap because I need the state they pass in (e.g. the
>> org.jruby.Ruby instance they're associated with). I'd like to bind a
>> constant method handle into the site after the first call and never
>> change it again.
> At this point, the overhead is nil, because we don't special-case CCS yet.  :-(
>
> When we do a pass of performance tuning, we'll fix that, and then the overhead (MCS/CCS) is likely to be a memory reference or two, plus a branch.
>
> If you are building bytecodes which are specific to a particular org.jruby.Ruby instance, see if you can put a backpointer to the instance onto the Class containing the bytecodes, using ClassValue or a static field or a similar mechanism.  Then you can access the Ruby instance in the BSM, and use a CCS.  You are trying to do something pretty normal here, and I'm an intrigued that it is so hard to get the right info in the BSM; it shouldn't be.

You need a kind of serialization (using bootstrap arguments) or to store 
the value somewhere
to get it after in the BSM, note that this pattern creates a memory 
leak, I think the only way to avoid it
is to have a special Class.define (a la AnonymousClassLoader) that takes 
a class with placeholders
and the corresponding runtime values

> -- John

Rémi