OK, we got some more information on the problem Paul Jakubik sent in.
Greg Thain was able to grab the code generated by the Symantec JIT:
<Thain>
singletons[i].reference = new Singleton();
Symantec JIT compiles this to:
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ; allocate space for
; Singleton, return
result in eax
02061074 mov dword ptr [ebp],eax ; EBP is
;
&singletons[i].reference - store the unconstructed
; object here. THIS
IS A BUG (IMHO!)
02061077 mov ecx,dword ptr [eax] ; dereference the handle to
; get the raw pointer
02061079 mov dword ptr [ecx],100h ; Next 4 lines are
0206107F mov dword ptr [ecx+4],200h ; Singleton's
inlined constructor
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
02061094 mov eax,ebx
02061096 call 01F6B2F0 ; exit monitor
Note that the store happens before the construction. I wonder if the
constructor had a side effect (i.e. threw a null pointer exception)
if you could see a similar problem with single-threaded code?
</Thain>
I ran some checks, and the problem does not occur if the constructor could
throw an exception, perform synchronization or do anything complicated.
So in that situation, the transformation being performed by the Symantec JIT is
100% legal (although unexpected).
Turns out that if you declare the fields of the Singleton as final
fields, it has absolutely
no effect -- you still see the uninitialized final fields.
Could this open up a security hole? Could be...
I'm guessing that the reason I don't see the problem on Windows 98 is
that Windows98 doesn't
do preemptive multithreading (or at least, that is my impression).
Bill
P.S. Thanks to Paul Jakubik and Greg Thain for the info.
P.P.S. How hard is it to grab code generated by the symantec jit? I
would love to be able
to do that to check out some other aspects of this "feature".
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:26 EDT