I have a mode in JRuby where I am doing essentially the same thing, eliminating accesses to "essentially final" values that are initialized lazily but never updated again. I don't have it on by default because the additional indy+MH does tips many methods over the inlining budget, making them slower as a result. It may become a very useful pattern in the future, once the new indy opto logic lands (in u4, I think).
My pattern is similar to yours, but since the fields are never updated I have no SwitchPoint in front. They're bound directly as constants and never rebound. I've been thinking about using your pattern to make some "mostly constant" values be a bit cheaper. - Charlie On Sat, Dec 17, 2011 at 12:33 PM, Rémi Forax <fo...@univ-mlv.fr> 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. > > 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. > -- 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.
