JDK-7081933 : Use zeroing elimination optimization for large array
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs22
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-22
  • Updated: 2012-01-23
  • Resolved: 2012-01-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 Other
8Fixed hs23Fixed
Related Reports
Relates :  
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
07-10-2011

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

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