United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7081933 Use zeroing elimination optimization for large array
7081933 : Use zeroing elimination optimization for large array

Details
Type:
Enhancement
Submit Date:
2011-08-22
Status:
Closed
Updated Date:
2012-01-23
Project Name:
JDK
Resolved Date:
2012-01-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs23

Related Reports
Backport:
JDK-2215467 - Use zeroing elimination optimization for large array
Relates:
JDK-7109887 - java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot

Sub Tasks

Description
Currently when array is large (>FastAllocateSizeLimit) C2 calls runtime which does allocation and zeroing. As result when large array allocation is followed by arraycopy zeroing elimination optimization does not happened.

Add a new runtime call for large arrays which will only return the pointer to new array without zeroing it. And the compiled code will do zeroing elimination and using ClearArray to zero the rest of array. We need to watch out for safepoints/deoptimization on the return from runtime call where it is expected that arrays are initialized. Also ClearArray should be precise since a large array could be allocated not in TLAB and is followed by an other object.

Comments
EVALUATION

See main CR
2011-10-07 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a92cdbac8b9e
2011-09-26 
PUBLIC COMMENTS

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.
2011-09-26


Hardware and Software, Engineered to Work Together