[9] RFR(S): 8053886: assert(false) failed: Should not allocate with exception pending

[Tobias Hartmann]

Hi Zoltan,

that looks good.

Best,
Tobias

On 04.09.2014 14:07, Zoltán Majó wrote:
> 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
>