[9] RFR(S): 8053886: assert(false) failed: Should not allocate with exception pending
Zoltán Majó
zoltan.majo at oracle.com
Thu Sep 4 12:07:33 UTC 2014
Hi,
please review the following patch.
Bug: assert(false) failed: Should not allocate with exception pending.
Problem: The above assert fails on 32-bit Windows. Nightly failure that
is triggered with two tests
metaspace/shrink_grow/ShrinkGrowMultiJVM
metaspace/shrink_grow/ShrinkGrowTest
The tests are designed to use up all metaspace and then free it up again.
The reason for the failing assert is: The method possibly_flush() calls
Method::build_method_counters() that attempts to allocate method
counters (in metaspace). When there is no free memory in available in
metaspace, an OOM is reported, but execution continues. When
possibly_flush() calls Method::build_method_counter() the next time
(this time with an exception pending), the assert fails in
Metaspace::allocate().
Solution: Method counters are used for "code aging" (controlled by
UseCodeAging flag, enabled by default). Not having method counters
disables code aging. That is not a correctness issue but rather a
potential performance problem.
We change the way method counters are obtained: We use
Method::get_method_counters() instead of calling
Method::build_method_counters(). Method::get_method_counters() clears
pending exceptions before returning.
Method::get_method_counters() is used by at other places to obtain
method counters (e.g. in ciMethod:ensure_method_counters() and also in
the interpreter). At some places, the interpreter calls
build_method_counters() directly, but it always checks and clears OOMs
before returning.
Webrev: http://cr.openjdk.java.net/~zmajo/8053886/webrev.00/
Testing:
Failing tests pass on sc11d1921.us.oracle.com (where nightly failure was
reported)
JPRT
JTREG
Thank you and best regards
Zoltan Majo
More information about the hotspot-compiler-dev
mailing list