JDK-7148109 : C2 compiler consumes too much heap resources
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2012-02-23
  • Updated: 2015-11-20
  • Resolved: 2012-09-05
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 6 JDK 7 JDK 8 Other
6u111Fixed 7u40Fixed 8Fixed hs24Fixed
Description
A JavaSE source licensee reports that c2 compiler comsumes too much heap memory.
They want Oracle to resolve this in the existing JDK5.

Although they has not been able to create test case or the way how to reproduce.
JLE files this problem for future escaltion and future releases.

The licensee and Oracle has been doing precise discussion.
JLE attached the discussion as a text file and their suggested fix for jdk5u34.

For more details, please see the comment section.

=====CUSTOMER Report =====
Our customer faces with JVM crash because of lack of c heap.
C2 compiler seems to use the heap area too much.

We compared
 gcore gotten when the consumption  of c heap begins toincrease
with
 core gotten when java process aborts because of lack of c heap.
(The above 2 cores are in the same process.)

c heap consumption:

            Thread::_resource_area     Compile::_node_arena
gcore          358,591,840              5,010,804
core(abort)    516,066,440              5,633,016

Both cores are compiling same thread.

Compiling Time:
gcore          187[sec]
core(abort)    209[sec]

Both cores are executing  PhaseChaitin::Split().

Split() is handling Block.
 - The num. of Block (_cfg._num_blocks) is 2325.
 - block idx(bidx) runs from 1164(gcore) to 1416 (abort).
 - Compile::_unique grows 36509 --> 43442


                        bidx Compile::_unique
gcore       line 495    1164 36509
core(abort) line 837    1416 43442

      (A) _cfg._num_blocks = 2325
      (B) spill_cnt = 1386

The above (A) and (B) are corresponding to (A) and (B) in the following
soource code portion respectively.

jdk5.0_25:
----./hotspot/share/vm/opto/reg_split.cpp ----

....
393 uint PhaseChaitin::Split( uint maxlrg ) {
...
465 //----------PASS 1----------
466 //----------Propagation & Node Insertion Code----------
467 // Walk the Blocks in RPO for DEF & USE info
468 for( bidx = 0; bidx < _cfg._num_blocks; bidx++ ) { ----(A)
469
...
489   for( slidx = 0; slidx < spill_cnt; slidx++ ) { ----(B)
...

495      if( lrgs(lidx)._def != NodeSentinel && <=== gore
496          lrgs(lidx)._def->rematerialize() ) {
...

631    }    // end for all spilling live ranges
...


661    //----------Walk Instructions in the Block and Split----------
662    // For all non-phi instructions in the block
663    for( insidx = 1; insidx <= b->end_idx(); insidx++ ) {
...
715        for( slidx = 0; slidx < spill_cnt; slidx++ ) {
...
751               maxlrg = split_DEF( n1, b, insert_point, maxlrg,Reachblock, debug_defs, splits, slidx);
...
770        }  // end for all spilling live ranges
...

837              def = split_Rematerialize( def, b, insidx, maxlrg, <=== core(abort) splits, slidx, lrg2reach, Reachblock, true );

...
1110   }  // End For All Instructions in Block - Non-PHI Pass
...
---------------------------------------------------------------- 
<============================

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a1c7f6472621
27-08-2012

EVALUATION I am fixing this by using first suggested fix: reg_split.cpp.fix1.
24-08-2012

SUGGESTED FIX We should use ResourceMark in such case as suggested in reg_split.cpp.fix1.
08-08-2012