United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7148109 C2 compiler consumes too much heap resources
JDK-7148109 : C2 compiler consumes too much heap resources

Details
Type:
Bug
Submit Date:
2012-02-23
Status:
Resolved
Updated Date:
2013-04-30
Project Name:
JDK
Resolved Date:
2012-09-05
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u25
Fixed Versions:
hs24 (b22)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

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
SUGGESTED FIX

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

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

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



Hardware and Software, Engineered to Work Together