Request for reviews (M): 7081933: Use zeroing elimination optimization for large array

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Sep 23 08:07:28 PDT 2011


Thank you, Christian

I will do as you suggested.

Thanks,
Vladimir

On 9/23/11 12:55 AM, Christian Thalinger wrote:
>
> On Sep 23, 2011, at 12:35 AM, Vladimir Kozlov wrote:
>
>> http://cr.openjdk.java.net/~kvn/7081933/webrev
>>
>> 7081933: Use zeroing elimination optimization for large array
>>
>> Currently when a new array does not fit into TLAB (big array (FastAllocateSizeLimit) or most common case when no space left in TLAB) C2 calls runtime which does allocation and zeroing. But zeroing is not needed if allocation is followed by arraycopy which initialize it (ReduceBulkZeroing optimization).
>>
>> Add a new runtime call _new_array_nozero_Java for such case and use it only for type arrays since obj arrays have to be initialized if deoptimization happened on the return from RT to compiled code.
>>
>> These changes does not affect refworkload scores (including jbb2005). But
>> crypto.aes (jvm2008) score improved around 10% on sparc. I don't see improvement on x86, may by because it has different crypto code.
>>
>> Added small fix to prefetch code in sparc arraycopy stub.
>
> src/share/vm/oops/typeArrayKlass.hpp:
>
> !   typeArrayOop allocate_common(int length, bool nozero, TRAPS);
> +   typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, false, THREAD); }
>
> I personally would prefer to have the nozero argument inverted (maybe zeroing or do_zeroing):
>
> !   typeArrayOop allocate_common(int length, bool do_zeroing, TRAPS);
> +   typeArrayOop allocate(int length, TRAPS) { return allocate_common(length, true, THREAD); }
>
> Otherwise this looks good.  Nice speedup.
>
> -- Christian
>
>>
>> Thanks,
>> Vladimir
>


More information about the hotspot-gc-dev mailing list