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

[mikhailo.seledtsov at oracle.com]

Here is an updated webrev: 
http://cr.openjdk.java.net/~mseledtsov/8241230.03/

Updates:

   - added /manual to @run for the tests, since the tests are intended 
for experimental, performance or stress execution, not a regular 
regression testing

   - updated test comments

   - new location for the tests: jdk/jdk/jfr/smallapps


Please review.


Thanks,

Misha

On 3/24/20 8:08 PM, mikhailo.seledtsov at oracle.com wrote:
> 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
>>>
>>