On 12/18/2011 11:13 AM, Jeroen Frijters wrote:
Rémi Forax wrote:
I've written a blog entry about how to write a static volatile final
variable, i.e. a variable which is considered as constant by the
compiler (the JIT) and if the variable changes, the JITed code is
deoptimized and jump back in interpreter mode to eventually optimize it
again later.
http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-
almost-static-final-field
The code is a little bit more convoluted than it should because there is
no invokedynamic in Java but you can emulate it.
This nicely illustrates the challenge that JSR 292 poses for me. On IKVM.NET
the best solution for an almost static final field, is simply a normal (or
volatile) field and so I would really need to be able to detect this pattern
and strip it all out, but because JSR 292 is so powerful (and general) it is
hard to detect these patterns. So my guess is that when I start looking
seriously at JSR 292 perf, I will have to cheat and simply look at the specific
patterns that (e.g.) JRuby uses and support them.
As far as I understand your code, you're creating one delegate by
OpenJDK method handle.
I think it's better to create one only when you actually calls the
MethodHandle,
i.e. when or invokeExact, invoke or CallSite.setTarget are called so
you will be able to use one ILGenerator for the whole method handle tree.
A nice way to do that is to record a stub delegate that will trigger the
generation of the IL
and replace itself.
For the SwitchPoint, you can just generate the code corresponding to the
target method handle
if the method handle tree is constant (i.e stored in a CallSite or a in
a static final variable and
if you record all CallSite/static final vars that will use the
SwitchPoint. When the switch point
is invalidated, you will have to update all of them with new delegates
that will only use
the fallback target of the SwitchPoint guard. And you can do that lazily
by just setting the stub delegate.
The only question is should the delegate of the MethodHandle/Callsite be
volatile or not.
By default, it should be volatile because if you update it because the
SwitchPoint is invalidated,
the code of the delegate as to be changed (you dont have this problem
with the stub delegate).
Maybe you can do better, it seems you can debug the CLR on the fly, this
should trigger
a deoptimisation of the debugging codes so you may be able to use it to
deopt all codes
that use a specific CallSite/static final method handle to force the
code to reload its
variable from the fields that should be marked volatile otherwise.
This is basically how the JSR292 backport works :)
BTW, I assume you'll trust I know the answer to your two casts question, so
please remind me of the free beer at FOSDEM :-)
:)
Regards,
Jeroen
regards,
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
