On 12/17/2011 07:54 PM, Charles Oliver Nutter wrote:
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).
So there is a bug in the way the inlining budget is computed. The pattern doesn't use any side methods is the fast path, only method handle adapters so it should not entail the inlining budget at all. I've only tested on small examples, so it was always fully inlined but I think it worth investigating why there is a problem with the inlining budget. Or it's not an inlining budget problem, the other problem I see is that if the code is not yet JITed, it's slow, far slower than a field access even a volatile one, so if the method is not hot but only warm, you may have trouble.
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.
Not sure it's really my pattern, it's more a JSR 292 pattern :)
- Charlie
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.
