RFR(M): 8241230: JFR: Extreme value testing: initial drop

[mikhailo.seledtsov at oracle.com]

Leonid, Erik,

    Thank you for reviewing the code and your feedback. After 
discussions with JFR team I better understand the requirements for this 
RFE, and changing the direction to develop these tests as simple stress 
mini-apps, in the style recommended by Erik.

Here is an updated WebRev:

http://cr.openjdk.java.net/~mseledtsov/8241230.02/


We are still in discussion about the location for these tests.


Thank you,

Misha


On 3/23/20 9:33 AM, Erik Gahlin wrote:
> Hi Misha,
>
> I think it would be nice if the test apps were kept as simple as 
> possible, i.e. no system properties, everything written in main, no 
> dependencies test-libs etc. This is easy to debug and understand.
>
> For example, to see how the string pool scales I would write something 
> like this:
>
> // Usage: java TestStringPool <string-count> <min-string-length>
> public class TestStringPool {
>     private class TestEvent extends Event {
>         String message;
>     }
>     public static void main(String... args) {
>         int stringCount = Integer.parseInt(args[0]);
>         int length = Integer.parseInt(args[1]);
>         String message = "A".repeat(length);
>         TestEvent event = new TestEvent();
>         for (int i = 0; i < stringCount / 2 ; i++) {
>             String msg = message + i;
>             event.message = msg;
> event.commit();
>             event.message = msg;
> event.commit(); // need to commit twice to use string pool
>         }
>     }
> }
>
> and then test it like this:
>
> $ time java -XX:StartFlightRecording:settings=profile 
> TestStringPool.java 1000 56
> $ time java -XX:StartFlightRecording:settings=profile 
> TestStringPool.java 100000 56
> $ time java -XX:StartFlightRecording:settings=profile 
> TestStringPool.java 10000000 56
>
> I don’t think it is necessary to create a jtreg test, run it on 
> multiple platform or have a test framework. The problems are algorithmic.
>
> I added some text in the bug 
> https://bugs.openjdk.java.net/browse/JDK-8230571 that describes 
> further how scaling issues can be investigated by looking at memory 
> events, vm operation events etc.
>
> Thanks
> Erik
>
>> On 19 Mar 2020, at 21:18, mikhailo.seledtsov at oracle.com 
>> <mailto:mikhailo.seledtsov at oracle.com> wrote:
>>
>> This is an initial drop for larger effort tracked by "8230571: 
>> [TESTBUG] JFR: Extreme value testing".
>> The goal of 8230571 is to create stress JFR tests using extreme 
>> values, such as large number of
>> unique events, large number of active recordings, large number of 
>> threads and more. See 8230571 for details.
>>
>> This issue (8241230) was created for initial drop. It contains 3 
>> tests: large number of unique JFR event types,
>> large number of active recordings and large number of strings. Goals 
>> for this drop are:
>>     - review and agree upon naming and location: location of tests, 
>> package name, test naming, etc.
>>     - review patterns used for this testing (see comments in 8241230 
>> for details)
>>     - agree upon parameterized scaling via test properties
>>     - and avoid "all at once" large drops
>>
>> Once this change is integrated, more tests will follow as per plan 
>> outlined in 8241230. The tests will largely follow
>> naming conventions and patterns agreed for this change.
>>
>>
>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8241230
>>     Webrev: http://cr.openjdk.java.net/~mseledtsov/8241230.00/
>>     Testing:
>>         Ran tests on Linux-x64, Win-x64 and MAC, with default stress 
>> level - All PASS
>>         Running with higher stress levels: in progress
>>
>>
>> Thank you,
>> Misha
>>
>