David Holmes wrote:
Hi Mandy,
Mandy Chung said the following on 08/13/10 09:22:
On 08/12/10 12:00, Rémi Forax wrote:
The "detailMessage" is not final because the VM in fact
preallocates Throwable object (OOME and ArithmeticException) and
then sets the 'detailMessage' field directly (as the constructor is
not invoked).
I am pretty sure the VM can set this field even if it is declared
final.
I think I don't see the problem.
I will file a CR to address this and separate from this bug fix. I
believe that the VM has no problem setting this field even if it's
declared final. I may be overly cautious but I think we need the VM
team to evaluate this.
The VM doesn't even look at the finality of the field it just does a
direct store into memory.
The issue with having the VM modify final fields in general is that
the compiler might reorder/hoist a load of a final field not knowing
that it might be changed by the VM. However that would only be a
problem if the object concerned was already accessible at the Java
level and that is not the case with the preallocated exception objects.
Making the detail message final should be fine - though not essential.
Thanks for the confirmation, David. The preallocated exception objects
will only be passed to Java level after the detailMessage field is set
(and not changed again) and so it's a non-issue.
I filed 6976861 and will update the CR.
Thanks
Mandy
