-
Bug
-
Resolution: Fixed
-
P3
-
5.0
-
b42
-
generic
-
generic
#Number of threads: 1
#Run the test for : 1 iteration(s)
#
#Iteration: 0
#
#Size of each brick is 3352160 bytes (419020 stones).
## To suppress the following error report, specify this argument
## after -XX: or in .hotspotrc: SuppressErrorAt=/concurrentMarkSweepGeneration
.cpp:1501]
##
## An unexpected error has been detected by HotSpot Virtual Machine:
##
## Internal Error (/net/prt-solsparc-q1-5/tmp/PrtBuildDir/workspace/src/share/
vm/memory/concurrentMarkSweepGeneration.cpp, 1501 [ Patched ]), pid=15490, tid=
9
##
## Java VM: Java HotSpot(TM) Server VM (20040301113318.pbk.4962463-debug mixed
mode)
##
## Error: assert(_cmsGen->_virtual_space.uncommitted_size() < gch->get_gen(0)->
used(),"Else partial cannot possibly fail")
## An error report file with more information is saved as hs_err_pid15490.log
##
## If you would like to submit a bug report, please visit:
## http://java.sun.com/webapps/bugreport/crash.jsp
##
#Current thread is 9
#Dumping core ...
The assertion is here:
// Inform cms gen if this was due to partial collection failing.
// The CMS gen may use this fact to determine its expansion policy.
if (gch->incremental_collection_will_fail()) {
assert(_cmsGen->_virtual_space.uncommitted_size() <
gch->get_gen(0)->used(),
"Else partial cannot possibly fail");
assert(!_cmsGen->incremental_collection_failed(),
"Should have been noticed, reacted to and cleared");
_cmsGen->set_incremental_collection_failed();
}
And is too strong, since it does not account for the possibility of
object dilation at promotion (because min object size in old gen may
be larger than that in young gen). Since there are already sufficient
checks in other places (promotion_attempt_is_safe() etc.), I think
we can just kill this assert -- the alternative is to strengthen it
by multiplying the dilation factor to the comparand on the right.
I think that is overkill.
#Run the test for : 1 iteration(s)
#
#Iteration: 0
#
#Size of each brick is 3352160 bytes (419020 stones).
## To suppress the following error report, specify this argument
## after -XX: or in .hotspotrc: SuppressErrorAt=/concurrentMarkSweepGeneration
.cpp:1501]
##
## An unexpected error has been detected by HotSpot Virtual Machine:
##
## Internal Error (/net/prt-solsparc-q1-5/tmp/PrtBuildDir/workspace/src/share/
vm/memory/concurrentMarkSweepGeneration.cpp, 1501 [ Patched ]), pid=15490, tid=
9
##
## Java VM: Java HotSpot(TM) Server VM (20040301113318.pbk.4962463-debug mixed
mode)
##
## Error: assert(_cmsGen->_virtual_space.uncommitted_size() < gch->get_gen(0)->
used(),"Else partial cannot possibly fail")
## An error report file with more information is saved as hs_err_pid15490.log
##
## If you would like to submit a bug report, please visit:
## http://java.sun.com/webapps/bugreport/crash.jsp
##
#Current thread is 9
#Dumping core ...
The assertion is here:
// Inform cms gen if this was due to partial collection failing.
// The CMS gen may use this fact to determine its expansion policy.
if (gch->incremental_collection_will_fail()) {
assert(_cmsGen->_virtual_space.uncommitted_size() <
gch->get_gen(0)->used(),
"Else partial cannot possibly fail");
assert(!_cmsGen->incremental_collection_failed(),
"Should have been noticed, reacted to and cleared");
_cmsGen->set_incremental_collection_failed();
}
And is too strong, since it does not account for the possibility of
object dilation at promotion (because min object size in old gen may
be larger than that in young gen). Since there are already sufficient
checks in other places (promotion_attempt_is_safe() etc.), I think
we can just kill this assert -- the alternative is to strengthen it
by multiplying the dilation factor to the comparand on the right.
I think that is overkill.