side note on static array constants and final fields

[Ulf Zibis]

Hi John,

thanks for your interesting additional info.

Just for interest, I run my benchmark with non-final arrays.
The warmup and the +128 trick became much slower, but surprise, the 
inlined version for map[a & 0xFF] became faster, so there is not anymore 
a difference between inlined and non-inlined version. Anybody understand 
this?

My results by JDK 1.6.0_03 (-server mode, arrays non-final):

time for 1st warm up: 1827 ms
time for 2nd warm up: 1782 ms
time for map[a & 0xFF]: 5188 ms
time for map[a + 0x80]: 4943 ms
time for inlined map[a & 0xFF]: 5133 ms
time for inlined map[a + 0x80]: 4928 ms

In client mode, surprisingly the run became faster with non-final arrays.
My results by JDK 1.6.0_03 (arrays non-final):

time for 1st warm up: 2906 ms
time for 2nd warm up: 2940 ms
time for map[a & 0xFF]: 7276 ms
time for map[a + 0x80]: 7270 ms
time for inlined map[a & 0xFF]: 7291 ms
time for inlined map[a + 0x80]: 7278 ms

-Ulf


Am 18.01.2009 03:58, John Rose schrieb:
> A side note on the unsigned-byte conversation:
>
> Static finals are treated by the JIT as constants, and a few of their 
> built-in immutable fields are (recursively) compile time constants.
>
> The oop _klass and array _length fields are both compile-time 
> constants, whenever the enclosing object reference is constant.  This 
> is why you get benefit from making static arrays final; their range 
> checks fold up.
>
> Some day we'll extend this treatment to user-written final instance 
> fields, so whole nests of objects can be folded more aggressively in 
> the JIT.  It's tricky, though, since user-written finals are not truly 
> immutable:  According to the verifier, they can be written and even 
> rewritten in their own constructors.
>
> -- John
>
> On Jan 17, 2009, at 1:35 PM, Ulf Zibis wrote:
>
>> + the map should be defined final.
>>
>
>