JDK-8298863 : Allow max_jint array length for all element types
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2022-12-15
  • Updated: 2023-11-20
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8029587 - Jdk 7u45 > java.lang.outofmemoryerror: requested array size exceeds vm limit
Relates :  
JDK-8246725 - Provide MAX_ARRAY_SIZE publicly
Relates :  
JDK-8059914 - Cannot allocate array with Integer.MAX_VALUE elements
Description
Currently, according to the comment in arrayOop.hpp, arrayOopDesc::max_array_length() we need to restrict array length for some element types:

     // It should be ok to return max_jint here, but parts of the code
      // (CollectedHeap, Klass::oop_oop_iterate(), and more) uses an int for
      // passing around the size (in words) of an object. So, we need to avoid
      // overflowing an int when we add the header. See CRs 4718400 and 7110613.

This should probably be fixed. The parts of code that use int for passing object size should use size_t or similar instead, in order to allow max_jint sized objects.
Comments
This has been a long standing limitation that has slowly been chipped away at, but my recollection from when people have looked at this previously is that removing these last few limits is non-trivial. By the way we have a number of pre-existing bugs for this.
16-12-2022