Please review fix for 7120481 storeStore barrier in constructor with final field
Jiangli Zhou
jiangli.zhou at oracle.com
Wed Feb 8 16:36:19 PST 2012
Hi Vitaly,
Thanks for the comments! The LIR_Assembler APIs only supports membar(),
membar_acquire() and membar_release() currently. Looks like we need to
add more APIs and LIR_Code in order to support more fine grained memory
barriers in compiled code for ARM. I will make the change. The ARM
interpreter is using the correct barrier as we can choose the specific
one to use.
Thanks,
Jiangli
On 02/08/2012 04:06 PM, Vitaly Davidovich wrote:
>
> Hi Jiangli,
>
> Isn't the "sy" option a full membar? I think the "st" option is
> equivalent to StoreStore.
>
> Vitaly
>
> Sent from my phone
>
> On Feb 8, 2012 6:37 PM, "Jiangli Zhou" <jiangli.zhou at oracle.com
> <mailto:jiangli.zhou at oracle.com>> wrote:
>
> 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/%7Ejianzhou/webrev.storestore/>
> http://javaweb.sfbay.sun.com/~jianzhou/webrev.storestore.closed/
> <http://javaweb.sfbay.sun.com/%7Ejianzhou/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/9903e9ae/attachment-0001.html
More information about the hotspot-compiler-dev
mailing list