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

[Igor Ignatyev]

On Tue, 22 Sep 2020 20:50:27 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> 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.

or are you saying that `breakpointOtherStratum` test is not (and most probably has never been) affected by
[8058176](https://bugs.openjdk.java.net/browse/JDK-8058176)?

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

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