switching on keys of type long

[Andreas Woess]

In general, JVM bytecodes do not have to come from javac, and the JVM
spec seems to allow for this case. Although Graal will probably optimize
away such a switch.

- andreas

On 2013-11-07 23:02, Doug Simon wrote:
> On Nov 7, 2013, at 9:49 PM, Venkatachalam, Vasanth <Vasanth.Venkatachalam at amd.com> wrote:
>
>> I assume that the case for handling Object keys also comes from TypeSwitchNOde? 
>>
>> I  also had a similar question about LIRGenerator.emitSwitch( )
>>
>> The line that says:
>>
>> If(keyCount == 0) { ...
>>
>> Javac optimizes away switch statements that have no keys (e.g., cases) so that the switch doesn't appear in bytecode.
>> Was this condition also added to handle the TypeSwitchNode?
> Not necessarily. It used to be that javac generated switch bytecodes for switch statements that have only a default case.
> If you want to find out, run Graal over a number of applications/benchmarks in a debugger and place a breakpoint on the code path of interest.
> That’s what I’d have to do to provide you with a more accurate answer ;-)
>
> -Doug
>
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com] 
>> Sent: Wednesday, November 06, 2013 12:58 PM
>> To: Venkatachalam, Vasanth
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: switching on keys of type long
>>
>> This comes from TypeSwitchNode.
>>
>> On Nov 6, 2013, at 7:43 PM, Venkatachalam, Vasanth <Vasanth.Venkatachalam at amd.com> wrote:
>>
>>> Can someone explain why the emitCode( ) routine of AMD64ControlFlow.SequentialSwitchOp is handling the case:
>>>
>>> else if (key.getKind() = Kind.Long)  ?
>>>
>>>> From my understanding of Java, it's not possible to switch on keys of type long. You get a compile time error.
>>> Vasanth
>>
>>