The attached test (MTStaticAssignment.java), derived from the code at fault in 4282941, shows that the store of the result of a thread local Eden allocation into a (possibly static) field can move above the stores which initialize the object's fields to zero or their user-defined value. This test crashes the VM in under a minute on a 2-CPU Ultra 60. The bug has only been verified on Solaris, but Cliff says the bug is present on all platforms. The current workaround is to use -XX:+ZeroTLE.

Once this bug is fixed, we should revisit 4282941 to ensure that it no longer crashes.

Here is an excerpt of the print of opto's output for MTStaticAssignment.getOop10.

040 MOV R_TLS,R_L0
044 LD [R_L0 + #60],R_L2 !ptr
048 LD [R_L0 + #56],R_O0 !ptr
04c ADD R_O0,#48,R_L3
050 STW R_L3,[R_L0 + #56] !ptr
054 SUBCC R_L3,R_L2,R_G0
058 BPgt B7 # 0x0dc P=0.000010 C=-1.000000
060
060 B4: # B5 <- B8 B3 Freq: 0.734267 Count: -1 RegPressure: 5 IHRP Index: 28 FRegPressure: 0 FHRP Index: 28
060 SET precise klass MTStaticAssignment: 0x1ec358 *,R_L1 !ptr
068 STW R_L1,[R_O0 + #4] !ptr
06c SET precise klass MTStaticAssignment: 0x1ec358 *,R_L0 !ptr
// NOTE: this is the store of the as-yet uninitialized object into the
// static variable which should not float above the initialization steps
// under it.
074 STW R_O0,[R_L0 + #216] !ptr
078 STW NULL,[R_O0 + #12] !ptr
07c STW NULL,[R_O0 + #16] !ptr
080 STW NULL,[R_O0 + #20] !ptr
084 STW NULL,[R_O0 + #24] !ptr
088 STW NULL,[R_O0 + #28] !ptr
08c STW NULL,[R_O0 + #32] !ptr
090 STW NULL,[R_O0 + #36] !ptr
094 STW NULL,[R_O0 + #40] !ptr
098 STW NULL,[R_O0 + #44] !ptr
09c STW NULL,[R_O0 + #8] !ptr