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
mlvm-dev mailing list

Reply via email to