-
Bug
-
Resolution: Fixed
-
P3
-
5.0u25
-
b22
-
sparc
-
solaris_10
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2229446 | 8 | Vladimir Kozlov | P3 | Resolved | Fixed | b55 |
JDK-8017974 | 7u45 | Vladimir Kozlov | P3 | Closed | Fixed | b01 |
JDK-8002834 | 7u40 | Vladimir Kozlov | P3 | Resolved | Fixed | b01 |
JDK-8134936 | 6u111 | Cheleswer Sahu | P3 | Resolved | Fixed | b03 |
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
...
----------------------------------------------------------------
<============================
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
...
----------------------------------------------------------------
<============================
- backported by
-
JDK-2229446 C2 compiler consumes too much heap resources
- Resolved
-
JDK-8002834 C2 compiler consumes too much heap resources
- Resolved
-
JDK-8134936 C2 compiler consumes too much heap resources
- Resolved
-
JDK-8002835 C2 compiler consumes too much heap resources
- Closed
-
JDK-8002836 C2 compiler consumes too much heap resources
- Closed
-
JDK-8017974 C2 compiler consumes too much heap resources
- Closed
(1 backported by)