[9] RFR(S): 8129937: compiler/codecache/jmx/UsageThresholdIncreasedTest.java fails with "Usage threshold was hit"

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Jun 30 15:25:20 UTC 2015


Looks fine to me. Let author (Igor Ignatyev?) to review it too.

Thanks,
Vladimir

On 6/30/15 2:54 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch.
>
> https://bugs.openjdk.java.net/browse/JDK-8129937
> http://cr.openjdk.java.net/~thartmann/8129937/webrev.00/
>
> Problem:
> The jmx test disables compilation, sets a usage threshold for the non-profiled code heap and verifies that the threshold is not hit while allocating code with an overall size < threshold. The test fails because even if we disable compilation with -XX:CompileCommand=compileonly,null::*, we still generate compiled versions of MH intrinsics on method resolution and since those are stored in the non-profiled code heap we may hit the threshold. This problem potentially affects the other jmx tests as well.
> Of course, with -Xint we would not generate any compiled MH intrinsics because we can guarantee that we have no compiled code. However, for testing purposes we want to make sure that we have all code heaps available and therefore need to use -XX:CompileCommand=compileonly,null::*.
>
> Solution:
> I changed the jmx tests to not assume that the usage of the non-profiled code heap is predictable (see CodeCacheUtils::isCodeHeapPredictable). I added the method CodeCacheUtils::assertEQorGTE to verify that two values are equal if the corresponding code heap is predictable or fall back to the weaker condition of checking that the values are greater or equal if the code heap is not predictable. I changed the tests to use this method.
>
> Testing:
> JPRT with failing test
>
> Thanks,
> Tobias
>


More information about the hotspot-compiler-dev mailing list