side note on static array constants and final fields
Ulf.Zibis at gmx.de
Sun Jan 18 12:50:47 PST 2009
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
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
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.
More information about the hotspot-dev