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

[Evgeny Nikitin]

On Tue, 22 Sep 2020 20:13:13 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.

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

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