[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