code generation of a switch on an enum

[Vitaly Davidovich]

>
> Yes, because condition codes are not modeled as live ranges that can be
> tracked.
> They could be tracked but the register allocator would need the power to
> spill also.
> So they are always materialized immediately before the branch that uses
> them.


Ok, probably not a big deal in grand scheme of things.

 The bytecodes are equivalent syntaxes for the same IR.  It doesn't matter
> which switch bytecode javac emits.
> The JIT decides based on its own heuristics whether to use a decision tree
> or something else.


Sorry, I think I wasn't clear.  I'm asking why the JIT decided to do a
decision tree rather than a jump table.  Naively, this example seems like a
classic jump table approach.  If there's no strong profile indicating that
a given value is always used and the value range is dense, the jump table
should be preferred as (a) the JIT already loads the switch table I
believe, so there's a memory access already and (b) this becomes an
unconditional jump rather than a mess of branches.

Thanks John


On Fri, Sep 12, 2014 at 3:44 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 10, 2014, at 8:14 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> Is there a reason the code is generated like this?
>
> Yes, because condition codes are not modeled as live ranges that can be
> tracked.
> They could be tracked but the register allocator would need the power to
> spill also.
> So they are always materialized immediately before the branch that uses
> them.
>
> Besides not special casing the FOUR constant here (which the bug report
> addresses), why is a lookup switch used and not a table switch?
>
>
> The bytecodes are equivalent syntaxes for the same IR.  It doesn't matter
> which switch bytecode javac emits.
> The JIT decides based on its own heuristics whether to use a decision tree
> or something else.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140912/00392958/attachment-0001.html>