compiling Enum.ordinal() into constant inside a method

[Vitaly Davidovich]

Ah, this comes back to that topic -- thanks; naively, I would've thought
that Enums would get the "trusted" treatment as well.

I believe Vladimir Ivanov is doing some work to allow more "trust" of final
fields, right? But aside from that, would it be useful to trust
java.lang.Enum's fields (i.e. name, ordinal) in addition to existing
trusted classes? Or not worth it given Vladimir I.'s work?

Thanks

On Fri, Feb 27, 2015 at 8:29 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> C2 doesn't treat final fields as constants:
>
>  private final int ordinal;
>
> Only (@Stable) and special final cases:
>
>       // Treat final non-static fields of trusted classes (classes in
>       // java.lang.invoke and sun.invoke packages and subpackages) as
>       // compile time constants.
>
> Regards,
> Vladimir
>
>
> On 2/27/15 10:08 AM, Vitaly Davidovich wrote:
>
>> Hi guys,
>>
>> Suppose we have an enum like this:
>>
>> enum E { ONE, TWO }
>>
>> Then we have a method like so:
>>
>> static E valueOf(int ordinal) {
>>     if (ordinal == E.ONE.ordinal()) return E.ONE;
>>     if (ordinal == E.TWO.ordinal()) return E.TWO;
>>     throw new <some_exception>; // this path never taken
>> }
>>
>> On 7u60 (sorry, can't easily test on a later version now), the compiled
>> code (C2) is actually loading the ordinal field for both comparisons.
>> Of course doing the following:
>>
>> static final int ONE = E.ONE.ordinal();
>> static final int TWO = E.TWO.ordinal();
>>
>> static E valueOf(int ordinal) {
>>     if (ordinal == ONE) return E.ONE;
>>     if (ordinal == TWO) return E.TWO;
>>     throw new <some_exception>; // this path never taken
>> }
>>
>> uses constant comparisons (well, the zero case is just a test, but 1
>> uses cmp).
>>
>> Is there a good reason why the first version of the method cannot be
>> compiled into the second one? Apologies if this is actually the case on
>> later hotspot versions, in which case I'd be happy to hear that.
>>
>> Thanks
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150227/5fb64158/attachment.html>