Re: series of switchpoints or better

[Mark Roos]

Charlie said
        or
finer, like switchpoint-per-class-and-method-name, which I am playing with
now

Did you ever come to a conclusion here?

And also
         polymorphic
caching, with each entry being a GWT (to check type) and a SP (to check
modification)

What happens when the SP triggers?  Do
you drop the entire cache or just replace the method guarded by the SP?
Seems like the later would require a
mutable call site as the target for the guard before the SP.

thx

mark


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Charles Oliver Nutter]

On Wed, Oct 5, 2016 at 6:26 PM, Jochen Theodorou  wrote:

> There is one more special problem I have though: per instance meta
> classes. So even if a x and y have the same class as per JVM, they can have
> differing meta classes. Which means a switchpoint alone is not enough...
> well, trying to get rid of that in the new MOP.


JRuby also has per-instance classes (so-called "singleton classes"). We
treat them like any other class. HOWEVER...if there's a singleton class
that does not override any methods from the original class, it shares a
SwitchPoint until such time that it is modified.

I've also considered caching singleton classes of various shapes, so we can
just choose based on known shapes...but never went further with that
experiment.

- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Jochen Theodorou]

On 06.10.2016 00:51, Charles Oliver Nutter wrote:
[...]

JRuby does this invalidation
eagerly, but the cost can be high for changes to classes close to the
root of the hierarchy. You have fewer guards at each call site, though.


I think that is ok for Groovy.

There is one more special problem I have though: per instance meta 
classes. So even if a x and y have the same class as per JVM, they can 
have differing meta classes. Which means a switchpoint alone is not 
enough... well, trying to get rid of that in the new MOP.



John's description of how Hotspot does this is also helpful; at least in
JRuby, searching up-hierarchy for overridden methods is just a name
lookup since Ruby does not overload.


not overloading solves many problems ;)


I've prototyped a similar system,
with a SwitchPoint per method, but ran into some hairy class structures
that made it complicated. The override search may be the answer for me.


yeah, I can imagine.

bye Jochen

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Charles Oliver Nutter]

On Oct 5, 2016 17:43, "Jochen Theodorou"  wrote:
> I see... the problem is actually similar, only that I do not have to do
something like that on a per "subclass added" event, but on a per "method
crud operation" event. And instead of going up to check for a
devirtualization, I have to actually propagate the change to all meta
classes of subclasses... and interface implementation (if the change was
made to an interface). So far I was thinking of making this lazy... but
maybe I should actually mark the classes as "dirty" eagerly... sorry... not
part of the discussion I guess ;)

Oh I think it is certainly relevant! JRuby does this invalidation eagerly,
but the cost can be high for changes to classes close to the root of the
hierarchy. You have fewer guards at each call site, though.

John's description of how Hotspot does this is also helpful; at least in
JRuby, searching up-hierarchy for overridden methods is just a name lookup
since Ruby does not overload. I've prototyped a similar system, with a
SwitchPoint per method, but ran into some hairy class structures that made
it complicated. The override search may be the answer for me.

- Charlie (mobile)
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Jochen Theodorou]

On 05.10.2016 22:22, John Rose wrote:
[...]

For the classic devirtualization trick, the JVM uses something that
works like a cross between a switchpoint per super-class and a
switchpoint per method:  When you load a new sub-class, each of its
supers S is walked, causing a search for any devirtualized methods S.m
in any compiled code.  A compiled code blob ("nmethod") contains a list
of dependencies which might (under suitable conditions) require it to be
discarded and recompiled.  This list can contain something like "S.m was
devirtualized and hasn't been overridden yet", or something else like
"switchpoint x has not been triggered yet".

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/codeCache.cpp#l1180

The logic which handles switchpoints is (as Remi said) built on top of
mutable call sites, which are handled in the JVM here:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/dependencies.cpp#l1740

I'm always glad when this stuff works like it's supposed to.  It
emboldens me to try more!


I see... the problem is actually similar, only that I do not have to do 
something like that on a per "subclass added" event, but on a per 
"method crud operation" event. And instead of going up to check for a 
devirtualization, I have to actually propagate the change to all meta 
classes of subclasses... and interface implementation (if the change was 
made to an interface). So far I was thinking of making this lazy... but 
maybe I should actually mark the classes as "dirty" eagerly... sorry... 
not part of the discussion I guess ;)


bye Jochen

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: EXT: Re: series of switchpoints or better

[Jochen Theodorou]

On 05.10.2016 21:45, Charles Oliver Nutter wrote:

On Wed, Oct 5, 2016 at 1:36 PM, Jochen Theodorou > wrote:

If I hear Remi saying volatile read... then it does not sound free
to me actually. In my experience volatile reads still present
inlining barriers. But if Remi and all of you tell me it is still
basically free, then I will not look too much at the volatile ;)

The volatile read is only used in the interpreter.


ah... I see.. nice. I get the feeling Remi actually already said this...


In Groovy we use SwitchPoint as well, but only one for the whole
meta class system that could clearly improved it seems. Having a
Switchpoint per method is actually a very interesting approach I
would not have considered before, since it means creating a ton of
Switchpoint objects. Not sure if that works in practice for me since
it is difficult to make a switchpoint for a method that does not
exist in the super class, but may come into existence later on -
still it seems I should be considering this.

I suspect Groovy developers are also less likely to modify classes at
runtime? In Ruby, it's not uncommon to keep creating new classes or
modifying existing ones at runtime, though it is generally discouraged
(all runtimes suffer).


It depends a bit on the style if it is done more or less often. But I 
think the majority barely changes the classes. but compared to Ruby 
probably a lot less.


We have a construct, that adds dynamically methods to multiple classes 
with a limited thread visibility and lifetime (Categories), but those 
are actually not realized as meta class changes. Creating a new class 
can happen any time, but they tend not to be build, they are declared 
with all the methods you want in there already usually.



cold performance is a consideration for me as well though. The heavy
creation time of MethodHandles is one of the reasons we do not use
invokedynamic as much as we could... especially considering that
creating a new cache entry via runtime class generation and still
invoking the method via reflection is actually faster than producing
one of our complex method handles right now.

Creating a new cache entry via class generation? Can you elaborate on
that? JRuby has a non-indy mode, but it doesn't do any code generation
per call site.


well, the code generation is optional, otherwise we use reflection in 
that mode. WE use the technique since I think 2008. And basically you 
have an interface call(Object[]), which we produce an implementation for 
at runtime and then call it. We use MagicAccessorImpl to avoid bytecode 
validation... well... if existing/accessible, not sure that is still the 
case in jdk9 though


[...]

Ahh, so when you invalidate, you only invalidate one class, but every
call site would have a SwitchPoint for the target class and all of its
superclasses. That will be more problematic for cold performance than
JRuby's way, but less overhead when invalidating. I'm not which
trade-off is better.


have to test it out in the future.


We also use this invalidation mechanism when calling dynamic methods
from Java (since we also use call site caches there) but those sites are
not (yet) guarded by a SwitchPoint.


yes, we have a very few cases like this as well.

[...]

With recent improvements to MH boot time and cold performance, I've
started to use indy by default in more places, carefully measuring
startup overhead along the way. I'm well on my way toward having fully
invokedynamic-aware jitted code basically be all invokedynamics.


invokedynamic by default is the way to go ;)


It is also good to hear that the old "once invalidated, it will not
optimized again - ever" is no longer valid.

And hopefully it will stay that way as long as we keep making noise :-)


indeed ;)

bye Jochen

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: EXT: Re: series of switchpoints or better

[John Rose]

On Oct 5, 2016, at 12:45 PM, Charles Oliver Nutter  wrote:
>  
> It is also good to hear that the old "once invalidated, it will not optimized 
> again - ever" is no longer valid.
> 
> And hopefully it will stay that way as long as we keep making noise :-)

Go ahead, be that way!___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[John Rose]

On Oct 5, 2016, at 7:00 AM, Charles Oliver Nutter  wrote:
> 
> I will say that using SwitchPoints is FAR better than our alternative 
> mechanism: pinging the (meta)class each time and checking a serial number.

This makes my day!  That's exactly what SwitchPoints are designed to deliver.  
They are intended to hook into the same mechanism the JVM uses to invalidate 
code that has out-of-date devirtualized methods.  (I.e., when you load the 
second definition overriding a method, you might cause some call sites to 
recompile.  That stuff is too good not to share with language implementors.)
 
> 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.
> 
> We have fought to keep the JIT from giving up on us, and I believe that as of 
> today you can invalidate call sites forever and the JIT will still recompile 
> them (within memory, code cache, and other limits of course).

I'm glad of that.  It has been a fight to tuned everything up just so.  Can you 
say (or blog) more about what you had to tweak to keep the JIT happen?  That 
may help other users, and/or help us make the JIT less irritable.

> However, you'll be invalidating every call site for every modification. If 
> the system eventually settles, that's fine. If it doesn't, you're going to be 
> stuck with cold call site performance most of the time.
>  
> So what is the way to go here? Or is there an even better way?
> 
> I strongly recommend the switchpoint-per-class granularity (or finer, like 
> switchpoint-per-class-and-method-name, which I am playing with now).

For the classic devirtualization trick, the JVM uses something that works like 
a cross between a switchpoint per super-class and a switchpoint per method:  
When you load a new sub-class, each of its supers S is walked, causing a search 
for any devirtualized methods S.m in any compiled code.  A compiled code blob 
("nmethod") contains a list of dependencies which might (under suitable 
conditions) require it to be discarded and recompiled.  This list can contain 
something like "S.m was devirtualized and hasn't been overridden yet", or 
something else like "switchpoint x has not been triggered yet".

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/codeCache.cpp#l1180
 


The logic which handles switchpoints is (as Remi said) built on top of mutable 
call sites, which are handled in the JVM here:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/08492e67bf32/src/share/vm/code/dependencies.cpp#l1740
 


I'm always glad when this stuff works like it's supposed to.  It emboldens me 
to try more!

— John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: EXT: Re: series of switchpoints or better

[Charles Oliver Nutter]

On Wed, Oct 5, 2016 at 1:36 PM, Jochen Theodorou  wrote:

> If I hear Remi saying volatile read... then it does not sound free to me
> actually. In my experience volatile reads still present inlining barriers.
> But if Remi and all of you tell me it is still basically free, then I will
> not look too much at the volatile ;)
>

The volatile read is only used in the interpreter.

In Groovy we use SwitchPoint as well, but only one for the whole meta class
> system that could clearly improved it seems. Having a Switchpoint per
> method is actually a very interesting approach I would not have considered
> before, since it means creating a ton of Switchpoint objects. Not sure if
> that works in practice for me since it is difficult to make a switchpoint
> for a method that does not exist in the super class, but may come into
> existence later on - still it seems I should be considering this.
>

I suspect Groovy developers are also less likely to modify classes at
runtime? In Ruby, it's not uncommon to keep creating new classes or
modifying existing ones at runtime, though it is generally discouraged (all
runtimes suffer).


> cold performance is a consideration for me as well though. The heavy
> creation time of MethodHandles is one of the reasons we do not use
> invokedynamic as much as we could... especially considering that creating a
> new cache entry via runtime class generation and still invoking the method
> via reflection is actually faster than producing one of our complex method
> handles right now.
>

Creating a new cache entry via class generation? Can you elaborate on that?
JRuby has a non-indy mode, but it doesn't do any code generation per call
site.


> As for Charles question:
>
>> Can you elaborate on the structure? JRuby has 6-deep (configurable)
>> polymorphic caching, with each entry being a GWT (to check type) and a SP
>> (to check modification) before hitting the plumbing for the method itself.
>>
>
> right now we use a 1-deep cache with several GWT (check type and argument
> types) and one SP plus several transformations. My goal is of course also
> the 6-deep polymorphic caching in the end. Just motivation for this was not
> so high before. If I use several SwitchPoint, then of course each of them
> would be there for each cache entry. How many depends on the receiver type.
> But at least one for each super class (and interface)
>

Ahh, so when you invalidate, you only invalidate one class, but every call
site would have a SwitchPoint for the target class and all of its
superclasses. That will be more problematic for cold performance than
JRuby's way, but less overhead when invalidating. I'm not which trade-off
is better.

We also use this invalidation mechanism when calling dynamic methods from
Java (since we also use call site caches there) but those sites are not
(yet) guarded by a SwitchPoint.


> To me horror I just found one pice of code commented with:
> //TODO: remove this method if possible by switchpoint usage
>

With recent improvements to MH boot time and cold performance, I've started
to use indy by default in more places, carefully measuring startup overhead
along the way. I'm well on my way toward having fully invokedynamic-aware
jitted code basically be all invokedynamics.


> It is also good to hear that the old "once invalidated, it will not
> optimized again - ever" is no longer valid.
>

And hopefully it will stay that way as long as we keep making noise :-)

- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: EXT: Re: series of switchpoints or better

[Jochen Theodorou]

On 05.10.2016 18:21, MacGregor, Duncan (GE Energy Connections) wrote:

I second (third?) Charlie and Remi’s comments. SwitchPoint per method has 
worked very nicely to reduce the amount of code invalidated by meta-programming 
shenanigans. You could go further and try for a class-and-method switch point, 
but that makes it harder to eliminate class checks or use CHA.

The downside of all this kind of thing is that when stuff is invalidated it’s 
often fairly heavy weight, so it’s worth putting some thought into designing 
things to minimise the amount of code which will be invalidated when you flip a 
SwitchPoint and only invalidating things that really need it (that’s where a 
switch point per method often pays off).


well you know... even if people tell you it is basically for free, it 
usually is not, which is why I wanted a confirmation.


If I hear Remi saying volatile read... then it does not sound free to me 
actually. In my experience volatile reads still present inlining 
barriers. But if Remi and all of you tell me it is still basically free, 
then I will not look too much at the volatile ;)


In Groovy we use SwitchPoint as well, but only one for the whole meta 
class system that could clearly improved it seems. Having a 
Switchpoint per method is actually a very interesting approach I would 
not have considered before, since it means creating a ton of Switchpoint 
objects. Not sure if that works in practice for me since it is difficult 
to make a switchpoint for a method that does not exist in the super 
class, but may come into existence later on - still it seems I should be 
considering this.


cold performance is a consideration for me as well though. The heavy 
creation time of MethodHandles is one of the reasons we do not use 
invokedynamic as much as we could... especially considering that 
creating a new cache entry via runtime class generation and still 
invoking the method via reflection is actually faster than producing one 
of our complex method handles right now.


As for Charles question:

Can you elaborate on the structure? JRuby has 6-deep (configurable) polymorphic 
caching, with each entry being a GWT (to check type) and a SP (to check 
modification) before hitting the plumbing for the method itself.


right now we use a 1-deep cache with several GWT (check type and 
argument types) and one SP plus several transformations. My goal is of 
course also the 6-deep polymorphic caching in the end. Just motivation 
for this was not so high before. If I use several SwitchPoint, then of 
course each of them would be there for each cache entry. How many 
depends on the receiver type. But at least one for each super class (and 
interface)


To me horror I just found one pice of code commented with:
//TODO: remove this method if possible by switchpoint usage

which means we are currently using switchpoint as well as pinging?! 
Commit incoming ;)


It is also good to hear that the old "once invalidated, it will not 
optimized again - ever" is no longer valid.


thx a lot guys
Jochen
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: EXT: Re: series of switchpoints or better

[MacGregor, Duncan (GE Energy Connections)]

I second (third?) Charlie and Remi’s comments. SwitchPoint per method has 
worked very nicely to reduce the amount of code invalidated by meta-programming 
shenanigans. You could go further and try for a class-and-method switch point, 
but that makes it harder to eliminate class checks or use CHA.

The downside of all this kind of thing is that when stuff is invalidated it’s 
often fairly heavy weight, so it’s worth putting some thought into designing 
things to minimise the amount of code which will be invalidated when you flip a 
SwitchPoint and only invalidating things that really need it (that’s where a 
switch point per method often pays off).

Duncan.

From: mlvm-dev 
<mlvm-dev-boun...@openjdk.java.net<mailto:mlvm-dev-boun...@openjdk.java.net>> 
on behalf of Charles Oliver Nutter 
<head...@headius.com<mailto:head...@headius.com>>
Reply-To: Da Vinci Machine Project 
<mlvm-dev@openjdk.java.net<mailto:mlvm-dev@openjdk.java.net>>
Date: Wednesday, 5 October 2016 at 15:00
To: Da Vinci Machine Project 
<mlvm-dev@openjdk.java.net<mailto:mlvm-dev@openjdk.java.net>>
Subject: EXT: Re: series of switchpoints or better

Hi Jochen!

On Wed, Oct 5, 2016 at 7:37 AM, Jochen Theodorou 
<blackd...@gmx.org<mailto:blackd...@gmx.org>> wrote:
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.

This is exactly how JRuby's type-modification guards work. We've used this 
technique since our first implementation of indy call sites.

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.

>From what I've seen, it's fine as far as hot performance. Adding complexity to 
>your handle chains likely impacts cold perf, of course.

Can you elaborate on the structure? JRuby has 6-deep (configurable) polymorphic 
caching, with each entry being a GWT (to check type) and a SP (to check 
modification) before hitting the plumbing for the method itself.

I will say that using SwitchPoints is FAR better than our alternative 
mechanism: pinging the (meta)class each time and checking a serial number.

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.

We have fought to keep the JIT from giving up on us, and I believe that as of 
today you can invalidate call sites forever and the JIT will still recompile 
them (within memory, code cache, and other limits of course).

However, you'll be invalidating every call site for every modification. If the 
system eventually settles, that's fine. If it doesn't, you're going to be stuck 
with cold call site performance most of the time.

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

I strongly recommend the switchpoint-per-class granularity (or finer, like 
switchpoint-per-class-and-method-name, which I am playing with now).

- Charlie



___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Charles Oliver Nutter]

Hi Jochen!

On Wed, Oct 5, 2016 at 7:37 AM, Jochen Theodorou  wrote:
>
> 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.
>

This is exactly how JRuby's type-modification guards work. We've used this
technique since our first implementation of indy call sites.


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

>From what I've seen, it's fine as far as hot performance. Adding complexity
to your handle chains likely impacts cold perf, of course.

Can you elaborate on the structure? JRuby has 6-deep (configurable)
polymorphic caching, with each entry being a GWT (to check type) and a SP
(to check modification) before hitting the plumbing for the method itself.

I will say that using SwitchPoints is FAR better than our alternative
mechanism: pinging the (meta)class each time and checking a serial number.


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

We have fought to keep the JIT from giving up on us, and I believe that as
of today you can invalidate call sites forever and the JIT will still
recompile them (within memory, code cache, and other limits of course).

However, you'll be invalidating every call site for every modification. If
the system eventually settles, that's fine. If it doesn't, you're going to
be stuck with cold call site performance most of the time.


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

I strongly recommend the switchpoint-per-class granularity (or finer, like
switchpoint-per-class-and-method-name, which I am playing with now).

- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Remi Forax]

Hi Jochen, 
hi Chris, 

> De: "Chris Seaton" <chris.sea...@oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev@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 < blackd...@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 
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: series of switchpoints or better

[Chris Seaton]

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.

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

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.

Chris

> On 5 Oct 2016, at 13:37, Jochen Theodorou  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?
> 
> bye Jochen
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

series of switchpoints or better

[Jochen Theodorou]

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?

bye Jochen

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev