Boxed types and constat propagation
Charles Oliver Nutter
headius at headius.com
Mon Apr 23 10:12:59 PDT 2012
On Mon, Apr 23, 2012 at 4:57 PM, Kohsuke Kawaguchi <kk at 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
More information about the mlvm-dev
mailing list