RFR: 8208257: [mlvm] Add randomness keyword to vm/mlvm/meth/func/jdi/breakpointOtherStratum

[Igor Ignatyev]

On Tue, 22 Sep 2020 20:37:53 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> Pre-Scara thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039557.html).
>> 
>> I tried to reproduce the test multiple times with different VM parameters, but it always passes. I suggest removing it
>> from ProblemList.txt.
>> Second change is marking the test with randomness keyword from the
>> [JDK-8243427](https://bugs.openjdk.java.net/browse/JDK-8243427) (using reproducible random for mlvm tests).
>> Tested using mach5 on the 4 platforms, 50 runs each.
>
> A question by Igor Ignatyev:
> 
>> looks good to me, you will need to update 8208257's title in JBS and close 8058176 as CNR.
> 
> **The answer:**
> 
> 8058176 is creating lots of i2/c2i adapters and eats the code cache very intensively. I added a code cache monitor to
> the test (0e99acf3efb28108d79780aa7825af9d24cd84b3), and it eats 8M of cache almost immediately:
>> 00:00.001 Cache Monitor started
> 00:00.009 Cache Monitor: 16% (1.3 MB) used
> 00:00.131 Cache Monitor: 20% (1.6 MB) used
> 00:00.232 Cache Monitor: 27% (2.2 MB) used
> 00:00.332 Cache Monitor: 36% (2.9 MB) used
> 00:00.434 Cache Monitor: 45% (3.6 MB) used
> 00:00.535 Cache Monitor: 60% (4.9 MB) used
> 00:00.637 Cache Monitor: 71% (5.7 MB) used
> 00:00.745 Cache Monitor: 79% (6.3 MB) used
> 00:00.847 Cache Monitor: 86% (7 MB) used
> 00:00.982 Cache Monitor: 92% (7.4 MB) used
> 00:01.084 Cache Monitor: 84% (6.8 MB) used
> 00:01.188 Cache Monitor: 89% (7.2 MB) used
> 00:01.292 Cache Monitor: 88% (7.1 MB) used
> 00:01.394 Cache Monitor: 89% (7.2 MB) used
> 00:01.496 Cache Monitor: 92% (7.4 MB) used
> 00:01.598 Cache Monitor: 96% (7.7 MB) used
> 00:01.700 Cache Monitor: 98% (7.9 MB) used
>>[1.865s][warning][codecache] CodeCache is full. Compiler has been disabled.
>>[1.865s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize=
> 
> breakpointTheOtherStratum, in its turn, was hanging, I guess, because of some logical problems (debuggee hanged,
> debugger crashed, etc.). Not a performance/cache exhaustion. Please check similar output for the
> breakpointTheOtherStratum (b826254e5040a6af1305a2cd9242cd1069ff504a):
>> binder> Launching debugee
> 00:00.240 Cache Monitor: 24% (1.9 MB) used
> 00:00.341 Cache Monitor: 26% (2.1 MB) used
> binder> Waiting for VM initialized
> Initial VMStartEvent received: VMStartEvent in thread main
> 00:00.442 Cache Monitor: 29% (2.4 MB) used
> 00:00.543 Cache Monitor: 32% (2.6 MB) used
> 00:00.644 Cache Monitor: 33% (2.7 MB) used
> 00:00.745 Cache Monitor: 34% (2.7 MB) used
> 00:00.845 Cache Monitor: 35% (2.8 MB) used
> 00:00.946 Cache Monitor: 35% (2.8 MB) used
> 00:01.047 Cache Monitor: 33% (2.7 MB) used
> 00:01.149 Cache Monitor: 34% (2.7 MB) used
> 00:01.250 Cache Monitor: 34% (2.7 MB) used
> 00:01.351 Cache Monitor: 36% (3 MB) used
> 00:01.452 Cache Monitor: 39% (3.2 MB) used
> 00:01.554 Cache Monitor: 41% (3.3 MB) used
> 00:01.655 Cache Monitor: 43% (3.5 MB) used
> 00:01.756 Cache Monitor: 45% (3.6 MB) used
> 00:01.858 Cache Monitor: 47% (3.8 MB) used
> 00:01.959 Cache Monitor: 49% (4 MB) used
> debugee.stdout> ### TRACE 1: DEBUGGEE PASSED
> 
> The second one does not eat memory that aggressively, the difference between lowest and highest amounts is just 2MB.

> A question by Igor Ignatyev:
> 
> > looks good to me, you will need to update 8208257's title in JBS and close 8058176 as CNR.
> 
> **The answer:**
> 
> 8058176 is creating lots of i2/c2i adapters and eats the code cache very intensively. I added a code cache monitor to
> the test ([0e99acf](https://github.com/openjdk/jdk/commit/0e99acf3efb28108d79780aa7825af9d24cd84b3)), and it eats 8M of
> cache almost immediately: <...>
> breakpointTheOtherStratum, in its turn, was hanging, I guess, because of some logical problems (debuggee hanged,
> debugger crashed, etc.). Not a performance/cache exhaustion. Please check similar output for the
> breakpointTheOtherStratum ([b826254](https://github.com/openjdk/jdk/commit/b826254e5040a6af1305a2cd9242cd1069ff504a)):
> <...>

the reason I suggested to close [8058176](https://bugs.openjdk.java.net/browse/JDK-8058176) as CNR is b/c this test is
problem-listed due to [8208257](https://bugs.openjdk.java.net/browse/JDK-8208257) and
[8058176](https://bugs.openjdk.java.net/browse/JDK-8058176). so the absence of the failure in your rerun would mean
that both 8058176 and 8208257 can not be reproduced, hence both should be closed.

I also would like to change my statement about changing 8208257's title, I think it would be better to restore the
original title, open a new issue to unproblem-list the test, close both 8208257 and 8058176 as CNR. adding `randomness`
k/w can be done as a part of this new issue or by a separate RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/309