Please review fix for 7120481 storeStore barrier in constructor with final field

Jiangli Zhou jiangli.zhou at oracle.com
Wed Feb 8 15:35:33 PST 2012


Hi,

Please review the following webrevs for 7120481 storeStore barrier in 
constructor with final field:

http://javaweb.sfbay.sun.com/~jianzhou/webrev.storestore/
http://javaweb.sfbay.sun.com/~jianzhou/webrev.storestore.closed/

Both c1 and the template interpreter are fixed to add the needed memory 
barrier. For a constructor that writes final field, a release barrier is 
added in the compiled method before the constructor returns if the 
constructor is not inlined. When the constructor is inlined, a release 
barrier is added at the end of the inlined constructor. The changes are 
done in the shared c1 code only, the platform specific code already 
knows whether memory barrier instructions should be generated for the 
platform. Following are ARM examples of a compiled constructor that 
writes final field after the fix. For the template interpreter, a new 
opcode '_return_with_membar' is added. During method rewriting, the VM 
detects if a constructor writes final. If so, the _return opcode is 
changed into _return_with_membar for the constructor. The ARM and PPC 
template interpreter code are changed to issue a storesotre barrier for 
the new opcode.

Not inlined:

   0x41386450: mov    r1, r0
   0x41386454: mov    r0, r1          ;*invokespecial <init>
                                         ; - HasFinal::<init>@1 (line 19)
   0x41386458: str    r1, [sp, #16]
   0x4138645c: bl    0x41325d00      ; OopMap{[16]=Oop off=48}
                                         ;*invokespecial <init>
                                         ; - HasFinal::<init>@1 (line 19)
                                         ;   {optimized virtual_call}
   0x41386460: mov    r0, #100    ; 0x64
   0x41386464: ldr    r1, [sp, #16]
   0x41386468: str    r0, [r1, #8]    ;*putfield x
                                         ; - HasFinal::<init>@7 (line 20)
0x4138646c: dmb    sy
   0x41386470: add    sp, sp, #24
   0x41386474: pop    {fp, lr}
   0x41386478: movw    ip, #53248    ; 0xd000
   0x4138647c: movt    ip, #16397    ; 0x400d
   0x41386480: ldr    ip, [ip]        ;   {poll_return}
   0x41386484: bx    lr
   0x41386488: nop            ; (mov r0, r0)


Inlined:

   0x413797e0: mov    r1, r0
   0x413797e4: mov    r0, r1          ;*invokespecial <init>
                                         ; - HasFinal::<init>@1 (line 19)
                                         ; - FinalTest::main at 25 (line 11)
   0x413797e8: str    r1, [sp, #32]
   0x413797ec: bl    0x41318d00      ; OopMap{[32]=Oop off=272}
                                         ;*invokespecial <init>
                                         ; - HasFinal::<init>@1 (line 19)
                                         ; - FinalTest::main at 25 (line 11)
                                         ;   {optimized virtual_call}
   0x413797f0: mov    r0, #100    ; 0x64
   0x413797f4: ldr    r1, [sp, #32]
   0x413797f8: str    r0, [r1, #8]    ;*putfield x
                                         ; - HasFinal::<init>@7 (line 20)
                                         ; - FinalTest::main at 25 (line 11)
0x413797fc: dmb    sy
   0x41379800: movw    r0, #23416    ; 0x5b78
                                         ;   {oop(a 'java/lang/Class' = 
'FinalTest')}
   0x41379804: movt    r0, #17206    ; 0x4336
   0x41379808: str    r1, [r0, #104]    ; 0x68

Thanks,

Jiangli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120208/236e4a9e/attachment.html 


More information about the hotspot-compiler-dev mailing list