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