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

Erik Gahlin erik.gahlin at oracle.com
Mon Mar 23 16:33:45 UTC 2020


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



More information about the hotspot-jfr-dev mailing list