series of switchpoints or better

[Remi Forax]

Hi Jochen, 
hi Chris, 

> De: "Chris Seaton" <chris.seaton at oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Mercredi 5 Octobre 2016 14:47:24
> Objet: Re: series of switchpoints or better

> Hi Jochen,

> I’m not an expert on the implementation of switch points, but my understanding
> is that they don’t appear in the dynamically compiled machine code at all. They
> use the safe point mechanism of the VM (the same thing that does the
> stop-the-world in the garbage collectors) for which polling instructions are
> already there anyway.

> http://chrisseaton.com/rubytruffle/icooolps15-safepoints/safepoints.pdf

> See figure 6 (no significant difference in runtime with switch points there or
> not), and figure 9 (machine code contains no trace of them). So switch points
> aren’t just fast - they don’t take any time at all. (Ignore the references to
> Truffle if you aren’t using that.)

> I don’t think any of this would change no matter how many of them you have.

The only cost, if the code is JITed is that the VM has to maintain a dependency list in order to know which JITed code should be marked as dead when the switchpoint is invalidated. 
It's not usually a big deal and don't forget that using a MutableCallSite also creates the same dependency list. 

> I’m sure they do have an impact on interpreter performance, of course, where
> they can’t be optimised away.

it's just a volatile read in the interpreter, the cost is negligible compared to the cost of invoking the method handle by itself. 

> I suppose it could conceivably be the case that a great many switch points may
> start to upset the compiler in terms of things like inlining budgets? I’m not
> sure, but seems unlikely.

no, as you said a switchpoint is compiled to zero assembly code and more generally method handles are not counted in the inlining budget. 

> Chris

>> On 5 Oct 2016, at 13:37, Jochen Theodorou < blackdrag at gmx.org > wrote:

>> Hi all,

>> I am constructing a new meta class system for Groovy (ok, I say that for several
>> years already, but bear with me) and I was wondering about the actual
>> performance of switchpoints.

>> In my current scenario I would need a way to say a certain group of meta classes
>> got updated and the method for this callsite needs potentially be reselected.

>> So if I have class A, class B and then I have a meta class for Object and one
>> for A.

>> If the meta class for A is changed, all handles operating on instances of A may
>> have to reselect. the handles for B and Object need not to be affected. If the
>> meta class for Object changes, I need to invalidate all the handles for A, B
>> and Object.

>> Doing this with switchpoints means probably one switchpoint per metaclass and a
>> small number of meta classes per class (in total 3 in my example). This would
>> mean my MethodHandle would have to get through a bunch of switchpoints, before
>> it can do the actual method invocation. And while switchpoints might be fast it
>> does not sound good to me.

>> Or I can do one switchpoint for all methodhandles in the system, which makes me
>> wonder if after a meta class change the callsite ever gets Jitted again. The
>> later performance penalty is actually also not very attractive to me.

>> So what is the way to go here? Or is there an even better way?

You can crawle the hierarchy from the class that is changed to all the subclasses, gather all the switchpoints and invalidate them all at once. 
In that case, you will only have one switchpoint by metaclass. 

see https://github.com/qmx/jsr292-cookbook/tree/master/metaclass 

And don't be afraid of the number of switchpoints you use, Nashorn will use more than you :) 

>> bye Jochen

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20161005/61675295/attachment.html>