RFR(S): 8053886: assert(false) failed: Should not allocate with exception pending
zoltan.majo at oracle.com
Fri Sep 5 14:11:47 UTC 2014
Thank you, Vladimir, Tobias, and Albert, for the feedback.
As this is a one-line change, I assume we can push it with one
Reviewer's and two Commiters' review.
On 09/04/2014 09:01 PM, Vladimir Kozlov wrote:
> PS: please, include the link to the bug report into your RFR.
Missed that, sorry. I hope I won't forget that in future RFR's.
Here is the link to the current issue (just for the record):
Thank you and best regards,
> On 9/4/14 5:07 AM, Zoltán Majó wrote:
>> 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
>> The tests are designed to use up all metaspace and then free it up
>> 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
>> 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/
>> Failing tests pass on sc11d1921.us.oracle.com (where nightly failure was
>> Thank you and best regards
>> Zoltan Majo
More information about the hotspot-compiler-dev