Field access optimisations inside loops (question).

[Dawid Weiss]

> In my last post, I have forgotten, that fields can also be modified from
> reflection access, if I remember right, even on final fields, so I'm afraid,
> HotSpot could optimize here.

As far as I know up from Java 1.3 the final fields can be modified
(from default values) only once and
if setAccessible is called on the Field descriptor... Still, from a
theoretical point of view I truly don't see anything in the JVM spec
that would prevent the compiler from doing the caching if it wanted to
do it; from the JVM spec, 2.9.1 Field Modifiers:

"Once a final field has been initialized, it always contains the same value."

and a little bit below is exactly what I had in mind:

"The Java programming language allows threads that access shared
variables to keep private working copies of the variables; this allows
a more efficient implementation of multiple threads (§2.19). These
working copies need to be reconciled with the master copies in the
shared main memory only at prescribed synchronization points, namely,
when objects are locked or unlocked (§2.19). As a rule, to make sure
that shared variables are consistently and reliably updated, a thread
should ensure that it has exclusive access to such variables by
obtaining a lock that conventionally enforces mutual exclusion for
those shared variables."

I suppose aggresive optimisations such as caching the state of a
(non-volatile) field locally would cause many (incorrect) programs not
run at all. I'd still argue that in the above program such an
optimisation would be perfectly legitimate...

Dawid