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

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 newarraynozeroJava 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 allocatecommon(int length, bool nozero, TRAPS); + typeArrayOop allocate(int length, TRAPS) { return allocatecommon(length, false, THREAD); } I personally would prefer to have the nozero argument inverted (maybe zeroing or dozeroing): ! typeArrayOop allocatecommon(int length, bool dozeroing, TRAPS); + typeArrayOop allocate(int length, TRAPS) { return allocatecommon(length, true, THREAD); } Otherwise this looks good. Nice speedup. -- Christian

Thanks, Vladimir

More information about the hotspot-compiler-dev mailing list