-
Bug
-
Resolution: Not an Issue
-
P4
-
16
-
generic
-
generic
I run my personal stress kit on promoted JDK bits and I
noticed a big execution time increase of the VM/NSK M&M
tests starting in jdk-16+15.
Here's the end of my bisection analysis for the changesets
that went into jdk-16+15:
redo_7:
@closed changeset: 4b8a3d (HEAD, tag: jdk-16+15) 8252814: Disable client tests until lab systems back on line
@open changeset: 1262ae36af0 (HEAD) 8252679: Two windows specific FileDIalog tests may fail on some Windows_Server_2016_Standard
$ elapsed_times jdk-16+14_redo_7/logs.linux-x86_64/*
jdk-16+14_redo_7/logs.linux-x86_64/start_run.log 0 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_java_bld.log 29 minutes 26 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-release.log 31 minutes 16 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-fastdebug.log 37 minutes 35 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-slowdebug.log 1 hours 1 minutes 5 seconds
And here's the results for the problematic changeset:
redo_8:
@closed changeset: 4b8a3d (HEAD, tag: jdk-16+15) 8252814: Disable client tests until lab systems back on line
@open changeset: 5f76deb2e06 (HEAD) 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor
$ elapsed_times jdk-16+14_redo_8/logs.linux-x86_64/*
jdk-16+14_redo_8/logs.linux-x86_64/start_run.log 0 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_java_bld.log 29 minutes 16 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-release.log 1 hours 42 minutes 4 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-fastdebug.log 2 hours 42 minutes 0 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-slowdebug.log 5 hours 54 minutes 38 seconds
release bits went from 31 minutes → 102 minutes
fastdebug bits went from 38 minutes → 162 minutes
slowdebug bits went from 61 minutes → 355 minutes
So for release bits, we have:
(102 - 31) / 31 * 100 => 229% increase
for fastdebug bits we have:
(162 - 38) / 38 * 100 => 326% increase
and for slowdebug bits we have:
(355 - 61) / 61 * 100 => 481% increase
noticed a big execution time increase of the VM/NSK M&M
tests starting in jdk-16+15.
Here's the end of my bisection analysis for the changesets
that went into jdk-16+15:
redo_7:
@closed changeset: 4b8a3d (HEAD, tag: jdk-16+15) 8252814: Disable client tests until lab systems back on line
@open changeset: 1262ae36af0 (HEAD) 8252679: Two windows specific FileDIalog tests may fail on some Windows_Server_2016_Standard
$ elapsed_times jdk-16+14_redo_7/logs.linux-x86_64/*
jdk-16+14_redo_7/logs.linux-x86_64/start_run.log 0 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_java_bld.log 29 minutes 26 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-release.log 31 minutes 16 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-fastdebug.log 37 minutes 35 seconds
jdk-16+14_redo_7/logs.linux-x86_64/do_monitoring_tests-slowdebug.log 1 hours 1 minutes 5 seconds
And here's the results for the problematic changeset:
redo_8:
@closed changeset: 4b8a3d (HEAD, tag: jdk-16+15) 8252814: Disable client tests until lab systems back on line
@open changeset: 5f76deb2e06 (HEAD) 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor
$ elapsed_times jdk-16+14_redo_8/logs.linux-x86_64/*
jdk-16+14_redo_8/logs.linux-x86_64/start_run.log 0 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_java_bld.log 29 minutes 16 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-release.log 1 hours 42 minutes 4 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-fastdebug.log 2 hours 42 minutes 0 seconds
jdk-16+14_redo_8/logs.linux-x86_64/do_monitoring_tests-slowdebug.log 5 hours 54 minutes 38 seconds
release bits went from 31 minutes → 102 minutes
fastdebug bits went from 38 minutes → 162 minutes
slowdebug bits went from 61 minutes → 355 minutes
So for release bits, we have:
(102 - 31) / 31 * 100 => 229% increase
for fastdebug bits we have:
(162 - 38) / 38 * 100 => 326% increase
and for slowdebug bits we have:
(355 - 61) / 61 * 100 => 481% increase
- relates to
-
JDK-8252522 nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor
-
- Resolved
-