RFR(S): 8129937: compiler/codecache/jmx/UsageThresholdIncreasedTest.java fails with "Usage threshold was hit"
dmitrij.pochepko at oracle.com
Tue Jun 30 16:09:12 UTC 2015
looks good (i'm not a reviewer)
> Thanks, Vladimir.
> The author of the original change  is Dmitrij Pochepko (CC'ed).
> Dmitrij, could you have a look?
>  https://bugs.openjdk.java.net/browse/JDK-8059613
> On 30.06.2015 17:25, Vladimir Kozlov wrote:
>> Looks fine to me. Let author (Igor Ignatyev?) to review it too.
>> On 6/30/15 2:54 AM, Tobias Hartmann wrote:
>>> please review the following patch.
>>> 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::*.
>>> 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.
>>> JPRT with failing test
More information about the hotspot-compiler-dev