On Mon, Apr 23, 2012 at 4:57 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote: > Let me try my question in another way, given this context. > > In p.11 of Nahi's JRuby/invokedynamic presentation [1], I see that > JRuby already does something to make Ruby constants (or "variables > that gets updated less frequently" as Nahi puts it) go fast, with the > use of MethodHandle that returns a constant. So if I had code like > this: > > def foo > if !DEBUG then > ... meat ... > end > end > > ... and DEBUG==false, wouldn't you expect the above to optimize it to: > > def foo > ... meat ... > end > > ... modulo de-optimization via switch point? But if my observation is > correct, then such optimization isn't happening.
In our case, the constant lookup should be bound tightly to a "true" object (RubyBoolean) that gets its trueness from a bit on an int field in the object. So there's two cases... if DEBUG ... ... Hotspot can't eliminate accessing the object in this case even though it's provably a constant since there's a non-final field access involved. Trueness is coming from elsewhere in memory that could be updated by someone else (though it never is). if DEBUG == false Hotspot probably *could* eliminate the code in this case, since both DEBUG and false could get bound to constant object references. In practice, we don't (yet) implement literals like "false" to use indy, but it's planned. For the first case, one way we plan to mitigate this is to compile constants and methods in boolean conditions differently, so the conditional always returns a proper Java boolean rather than an object we then inspect for trueness. In this case, we'd compile it as an invokedynamic "booleanConstant", the constant lookup would see that it's our "false" object, and the bound value would be Java boolean false, with the same constant invalidation wrappers. Then it would actually optimize like you expect, but it requires additional logic in the compiler. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
