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
