< prev index next >

doc/testing.html

Print this page

        

*** 1,26 **** <!DOCTYPE html> ! <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang=""> <head> ! <meta charset="utf-8" /> ! <meta name="generator" content="pandoc" /> ! <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" /> <title>Testing the JDK</title> ! <style type="text/css"> ! code{white-space: pre-wrap;} ! span.smallcaps{font-variant: small-caps;} ! span.underline{text-decoration: underline;} ! div.column{display: inline-block; vertical-align: top; width: 50%;} ! </style> ! <link rel="stylesheet" href="../make/data/docs-resources/resources/jdk-default.css" /> <!--[if lt IE 9]> <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script> <![endif]--> <style type="text/css">pre, code, tt { color: #1d6ae5; }</style> </head> <body> ! <header id="title-block-header"> <h1 class="title">Testing the JDK</h1> </header> <nav id="TOC"> <ul> <li><a href="#using-make-test-the-run-test-framework">Using &quot;make test&quot; (the run-test framework)</a><ul> --- 1,21 ---- <!DOCTYPE html> ! <html> <head> ! <meta charset="utf-8"> ! <meta name="generator" content="pandoc"> ! <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes"> <title>Testing the JDK</title> ! <style type="text/css">code{white-space: pre;}</style> ! <link rel="stylesheet" href="../make/data/docs-resources/resources/jdk-default.css"> <!--[if lt IE 9]> <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script> <![endif]--> <style type="text/css">pre, code, tt { color: #1d6ae5; }</style> </head> <body> ! <header> <h1 class="title">Testing the JDK</h1> </header> <nav id="TOC"> <ul> <li><a href="#using-make-test-the-run-test-framework">Using &quot;make test&quot; (the run-test framework)</a><ul>
*** 32,56 **** <li><a href="#microbenchmarks">Microbenchmarks</a></li> <li><a href="#special-tests">Special tests</a></li> </ul></li> <li><a href="#test-results-and-summary">Test results and summary</a></li> <li><a href="#test-suite-control">Test suite control</a><ul> - <li><a href="#general-keywords-test_opts">General keywords (TEST_OPTS)</a></li> <li><a href="#jtreg-keywords">JTReg keywords</a></li> <li><a href="#gtest-keywords">Gtest keywords</a></li> <li><a href="#microbenchmark-keywords">Microbenchmark keywords</a></li> </ul></li> - <li><a href="#notes-for-specific-tests">Notes for Specific Tests</a><ul> - <li><a href="#docker-tests">Docker Tests</a></li> - <li><a href="#non-us-locale">Non-US locale</a></li> - </ul></li> </ul> </nav> <h2 id="using-make-test-the-run-test-framework">Using &quot;make test&quot; (the run-test framework)</h2> <p>This new way of running tests is developer-centric. It assumes that you have built a JDK locally and want to test it. Running common test targets is simple, and more complex ad-hoc combination of tests is possible. The user interface is forgiving, and clearly report errors it cannot resolve.</p> <p>The main target <code>test</code> uses the jdk-image as the tested product. There is also an alternate target <code>exploded-test</code> that uses the exploded image instead. Not all tests will run successfully on the exploded image, but using this target can greatly improve rebuild times for certain workflows.</p> ! <p>Previously, <code>make test</code> was used to invoke an old system for running tests, and <code>make run-test</code> was used for the new test framework. For backward compatibility with scripts and muscle memory, <code>run-test</code> (and variants like <code>exploded-run-test</code> or <code>run-test-tier1</code>) are kept as aliases.</p> <p>Some example command-lines:</p> <pre><code>$ make test-tier1 $ make test-jdk_lang JTREG=&quot;JOBS=8&quot; $ make test TEST=jdk_lang $ make test-only TEST=&quot;gtest:LogTagSet gtest:LogTagSetDescriptions&quot; GTEST=&quot;REPEAT=-1&quot; --- 27,46 ---- <li><a href="#microbenchmarks">Microbenchmarks</a></li> <li><a href="#special-tests">Special tests</a></li> </ul></li> <li><a href="#test-results-and-summary">Test results and summary</a></li> <li><a href="#test-suite-control">Test suite control</a><ul> <li><a href="#jtreg-keywords">JTReg keywords</a></li> <li><a href="#gtest-keywords">Gtest keywords</a></li> <li><a href="#microbenchmark-keywords">Microbenchmark keywords</a></li> </ul></li> </ul> </nav> <h2 id="using-make-test-the-run-test-framework">Using &quot;make test&quot; (the run-test framework)</h2> <p>This new way of running tests is developer-centric. It assumes that you have built a JDK locally and want to test it. Running common test targets is simple, and more complex ad-hoc combination of tests is possible. The user interface is forgiving, and clearly report errors it cannot resolve.</p> <p>The main target <code>test</code> uses the jdk-image as the tested product. There is also an alternate target <code>exploded-test</code> that uses the exploded image instead. Not all tests will run successfully on the exploded image, but using this target can greatly improve rebuild times for certain workflows.</p> ! <p>Previously, <code>make test</code> was used invoke an old system for running test, and <code>make run-test</code> was used for the new test framework. For backward compatibility with scripts and muscle memory, <code>run-test</code> (and variants like <code>exploded-run-test</code> or <code>run-test-tier1</code>) are kept as aliases. The old system can still be accessed for some time using <code>cd test &amp;&amp; make</code>.</p> <p>Some example command-lines:</p> <pre><code>$ make test-tier1 $ make test-jdk_lang JTREG=&quot;JOBS=8&quot; $ make test TEST=jdk_lang $ make test-only TEST=&quot;gtest:LogTagSet gtest:LogTagSetDescriptions&quot; GTEST=&quot;REPEAT=-1&quot;
*** 105,137 **** <p>It is possible to control various aspects of the test suites using make control variables.</p> <p>These variables use a keyword=value approach to allow multiple values to be set. So, for instance, <code>JTREG=&quot;JOBS=1;TIMEOUT=8&quot;</code> will set the JTReg concurrency level to 1 and the timeout factor to 8. This is equivalent to setting <code>JTREG_JOBS=1 JTREG_TIMEOUT=8</code>, but using the keyword format means that the <code>JTREG</code> variable is parsed and verified for correctness, so <code>JTREG=&quot;TMIEOUT=8&quot;</code> would give an error, while <code>JTREG_TMIEOUT=8</code> would just pass unnoticed.</p> <p>To separate multiple keyword=value pairs, use <code>;</code> (semicolon). Since the shell normally eats <code>;</code>, the recommended usage is to write the assignment inside qoutes, e.g. <code>JTREG=&quot;...;...&quot;</code>. This will also make sure spaces are preserved, as in <code>JTREG=&quot;VM_OPTIONS=-XshowSettings -Xlog:gc+ref=debug&quot;</code>.</p> <p>(Other ways are possible, e.g. using backslash: <code>JTREG=JOBS=1\;TIMEOUT=8</code>. Also, as a special technique, the string <code>%20</code> will be replaced with space for certain options, e.g. <code>JTREG=VM_OPTIONS=-XshowSettings%20-Xlog:gc+ref=debug</code>. This can be useful if you have layers of scripts and have trouble getting proper quoting of command line arguments through.)</p> <p>As far as possible, the names of the keywords have been standardized between test suites.</p> - <h3 id="general-keywords-test_opts">General keywords (TEST_OPTS)</h3> - <p>Some keywords are valid across different test suites. If you want to run tests from multiple test suites, or just don't want to care which test suite specific control variable to use, then you can use the general TEST_OPTS control variable.</p> - <p>There are also some keywords that applies globally to the test runner system, not to any specific test suites. These are also available as TEST_OPTS keywords.</p> - <h4 id="jobs">JOBS</h4> - <p>Currently only applies to JTReg.</p> - <h4 id="timeout_factor">TIMEOUT_FACTOR</h4> - <p>Currently only applies to JTReg.</p> - <h4 id="vm_options">VM_OPTIONS</h4> - <p>Applies to JTReg, GTest and Micro.</p> - <h4 id="java_options">JAVA_OPTIONS</h4> - <p>Applies to JTReg, GTest and Micro.</p> - <h4 id="aot_modules">AOT_MODULES</h4> - <p>Applies to JTReg and GTest.</p> - <h4 id="jcov">JCOV</h4> - <p>This keywords applies globally to the test runner system. If set to <code>true</code>, it enables JCov coverage reporting for all tests run. To be useful, the JDK under test must be run with a JDK built with JCov instrumentation (<code>configure --with-jcov=&lt;path to directory containing lib/jcov.jar&gt;</code>, <code>make jcov-image</code>).</p> - <p>The simplest way to run tests with JCov coverage report is to use the special target <code>jcov-test</code> instead of <code>test</code>, e.g. <code>make jcov-test TEST=jdk_lang</code>. This will make sure the JCov image is built, and that JCov reporting is enabled.</p> - <p>The JCov report is stored in <code>build/$BUILD/test-results/jcov-output</code>.</p> - <p>Please note that running with JCov reporting can be very memory intensive.</p> <h3 id="jtreg-keywords">JTReg keywords</h3> ! <h4 id="jobs-1">JOBS</h4> <p>The test concurrency (<code>-concurrency</code>).</p> ! <p>Defaults to TEST_JOBS (if set by <code>--with-test-jobs=</code>), otherwise it defaults to JOBS, except for Hotspot, where the default is <em>number of CPU cores/2</em> (for sparc, if more than 16 cpus, then <em>number of CPU cores/5</em>, otherwise <em>number of CPU cores/4</em>), but never more than <em>memory size in GB/2</em>.</p> ! <h4 id="timeout_factor-1">TIMEOUT_FACTOR</h4> <p>The timeout factor (<code>-timeoutFactor</code>).</p> <p>Defaults to 4.</p> <h4 id="test_mode">TEST_MODE</h4> <p>The test mode (<code>-agentvm</code>, <code>-samevm</code> or <code>-othervm</code>).</p> <p>Defaults to <code>-agentvm</code>.</p> --- 95,109 ---- <p>It is possible to control various aspects of the test suites using make control variables.</p> <p>These variables use a keyword=value approach to allow multiple values to be set. So, for instance, <code>JTREG=&quot;JOBS=1;TIMEOUT=8&quot;</code> will set the JTReg concurrency level to 1 and the timeout factor to 8. This is equivalent to setting <code>JTREG_JOBS=1 JTREG_TIMEOUT=8</code>, but using the keyword format means that the <code>JTREG</code> variable is parsed and verified for correctness, so <code>JTREG=&quot;TMIEOUT=8&quot;</code> would give an error, while <code>JTREG_TMIEOUT=8</code> would just pass unnoticed.</p> <p>To separate multiple keyword=value pairs, use <code>;</code> (semicolon). Since the shell normally eats <code>;</code>, the recommended usage is to write the assignment inside qoutes, e.g. <code>JTREG=&quot;...;...&quot;</code>. This will also make sure spaces are preserved, as in <code>JTREG=&quot;VM_OPTIONS=-XshowSettings -Xlog:gc+ref=debug&quot;</code>.</p> <p>(Other ways are possible, e.g. using backslash: <code>JTREG=JOBS=1\;TIMEOUT=8</code>. Also, as a special technique, the string <code>%20</code> will be replaced with space for certain options, e.g. <code>JTREG=VM_OPTIONS=-XshowSettings%20-Xlog:gc+ref=debug</code>. This can be useful if you have layers of scripts and have trouble getting proper quoting of command line arguments through.)</p> <p>As far as possible, the names of the keywords have been standardized between test suites.</p> <h3 id="jtreg-keywords">JTReg keywords</h3> ! <h4 id="jobs">JOBS</h4> <p>The test concurrency (<code>-concurrency</code>).</p> ! <p>Defaults to TEST_JOBS (if set by <code>--with-test-jobs=</code>), otherwise it defaults to JOBS, except for Hotspot, where the default is <em>number of CPU cores/2</em>, but never more than 12.</p> ! <h4 id="timeout">TIMEOUT</h4> <p>The timeout factor (<code>-timeoutFactor</code>).</p> <p>Defaults to 4.</p> <h4 id="test_mode">TEST_MODE</h4> <p>The test mode (<code>-agentvm</code>, <code>-samevm</code> or <code>-othervm</code>).</p> <p>Defaults to <code>-agentvm</code>.</p>
*** 146,179 **** <p>Defaults to <code>fail,error</code>.</p> <h4 id="max_mem">MAX_MEM</h4> <p>Limit memory consumption (<code>-Xmx</code> and <code>-vmoption:-Xmx</code>, or none).</p> <p>Limit memory consumption for JTReg test framework and VM under test. Set to 0 to disable the limits.</p> <p>Defaults to 512m, except for hotspot, where it defaults to 0 (no limit).</p> - <h4 id="keywords">KEYWORDS</h4> - <p>JTReg kewords sent to JTReg using <code>-k</code>. Please be careful in making sure that spaces and special characters (like <code>!</code>) are properly quoted. To avoid some issues, the special value <code>%20</code> can be used instead of space.</p> - <h4 id="extra_problem_lists">EXTRA_PROBLEM_LISTS</h4> - <p>Use additional problem lists file or files, in addition to the default ProblemList.txt located at the JTReg test roots.</p> - <p>If multiple file names are specified, they should be separated by space (or, to help avoid quoting issues, the special value <code>%20</code>).</p> - <p>The file names should be either absolute, or relative to the JTReg test root of the tests to be run.</p> <h4 id="options">OPTIONS</h4> <p>Additional options to the JTReg test framework.</p> <p>Use <code>JTREG=&quot;OPTIONS=--help all&quot;</code> to see all available JTReg options.</p> ! <h4 id="java_options-1">JAVA_OPTIONS</h4> <p>Additional Java options to JTReg (<code>-javaoption</code>).</p> ! <h4 id="vm_options-1">VM_OPTIONS</h4> <p>Additional VM options to JTReg (<code>-vmoption</code>).</p> - <h4 id="aot_modules-1">AOT_MODULES</h4> - <p>Generate AOT modules before testing for the specified module, or set of modules. If multiple modules are specified, they should be separated by space (or, to help avoid quoting issues, the special value <code>%20</code>).</p> <h3 id="gtest-keywords">Gtest keywords</h3> <h4 id="repeat">REPEAT</h4> <p>The number of times to repeat the tests (<code>--gtest_repeat</code>).</p> <p>Default is 1. Set to -1 to repeat indefinitely. This can be especially useful combined with <code>OPTIONS=--gtest_break_on_failure</code> to reproduce an intermittent problem.</p> <h4 id="options-1">OPTIONS</h4> <p>Additional options to the Gtest test framework.</p> <p>Use <code>GTEST=&quot;OPTIONS=--help&quot;</code> to see all available Gtest options.</p> - <h4 id="aot_modules-2">AOT_MODULES</h4> - <p>Generate AOT modules before testing for the specified module, or set of modules. If multiple modules are specified, they should be separated by space (or, to help avoid quoting issues, the special value <code>%20</code>).</p> <h3 id="microbenchmark-keywords">Microbenchmark keywords</h3> <h4 id="fork">FORK</h4> <p>Override the number of benchmark forks to spawn. Same as specifying <code>-f &lt;num&gt;</code>.</p> <h4 id="iter">ITER</h4> <p>Number of measurement iterations per fork. Same as specifying <code>-i &lt;num&gt;</code>.</p> --- 118,141 ---- <p>Defaults to <code>fail,error</code>.</p> <h4 id="max_mem">MAX_MEM</h4> <p>Limit memory consumption (<code>-Xmx</code> and <code>-vmoption:-Xmx</code>, or none).</p> <p>Limit memory consumption for JTReg test framework and VM under test. Set to 0 to disable the limits.</p> <p>Defaults to 512m, except for hotspot, where it defaults to 0 (no limit).</p> <h4 id="options">OPTIONS</h4> <p>Additional options to the JTReg test framework.</p> <p>Use <code>JTREG=&quot;OPTIONS=--help all&quot;</code> to see all available JTReg options.</p> ! <h4 id="java_options">JAVA_OPTIONS</h4> <p>Additional Java options to JTReg (<code>-javaoption</code>).</p> ! <h4 id="vm_options">VM_OPTIONS</h4> <p>Additional VM options to JTReg (<code>-vmoption</code>).</p> <h3 id="gtest-keywords">Gtest keywords</h3> <h4 id="repeat">REPEAT</h4> <p>The number of times to repeat the tests (<code>--gtest_repeat</code>).</p> <p>Default is 1. Set to -1 to repeat indefinitely. This can be especially useful combined with <code>OPTIONS=--gtest_break_on_failure</code> to reproduce an intermittent problem.</p> <h4 id="options-1">OPTIONS</h4> <p>Additional options to the Gtest test framework.</p> <p>Use <code>GTEST=&quot;OPTIONS=--help&quot;</code> to see all available Gtest options.</p> <h3 id="microbenchmark-keywords">Microbenchmark keywords</h3> <h4 id="fork">FORK</h4> <p>Override the number of benchmark forks to spawn. Same as specifying <code>-f &lt;num&gt;</code>.</p> <h4 id="iter">ITER</h4> <p>Number of measurement iterations per fork. Same as specifying <code>-i &lt;num&gt;</code>.</p>
*** 183,203 **** <p>Number of warmup iterations to run before the measurement phase in each fork. Same as specifying <code>-wi &lt;num&gt;</code>.</p> <h4 id="warmup_time">WARMUP_TIME</h4> <p>Amount of time to spend in each warmup iteration. Same as specifying <code>-w &lt;num&gt;</code>.</p> <h4 id="results_format">RESULTS_FORMAT</h4> <p>Specify to have the test run save a log of the values. Accepts the same values as <code>-rff</code>, i.e., <code>text</code>, <code>csv</code>, <code>scsv</code>, <code>json</code>, or <code>latex</code>.</p> ! <h4 id="vm_options-2">VM_OPTIONS</h4> <p>Additional VM arguments to provide to forked off VMs. Same as <code>-jvmArgs &lt;args&gt;</code></p> <h4 id="options-2">OPTIONS</h4> <p>Additional arguments to send to JMH.</p> - <h2 id="notes-for-specific-tests">Notes for Specific Tests</h2> - <h3 id="docker-tests">Docker Tests</h3> - <p>Docker tests with default parameters may fail on systems with glibc versions not compatible with the one used in the default docker image (e.g., Oracle Linux 7.6 for x86). For example, they pass on Ubuntu 16.04 but fail on Ubuntu 18.04 if run like this on x86:</p> - <pre><code>$ make test TEST=&quot;jtreg:test/hotspot/jtreg/containers/docker&quot;</code></pre> - <p>To run these tests correctly, additional parameters for the correct docker image are required on Ubuntu 18.04 by using <code>JAVA_OPTIONS</code>.</p> - <pre><code>$ make test TEST=&quot;jtreg:test/hotspot/jtreg/containers/docker&quot; JTREG=&quot;JAVA_OPTIONS=-Djdk.test.docker.image.name=ubuntu -Djdk.test.docker.image.version=latest&quot;</code></pre> - <h3 id="non-us-locale">Non-US locale</h3> - <p>If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting <code>LANG=&quot;en_US&quot;</code> in the environment before running tests should work. On Windows, setting <code>JTREG=&quot;VM_OPTIONS=-Duser.language=en -Duser.country=US&quot;</code> helps for most, but not all test cases. For example:</p> - <pre><code>$ export LANG=&quot;en_US&quot; &amp;&amp; make test TEST=... - $ make test JTREG=&quot;VM_OPTIONS=-Duser.language=en -Duser.country=US&quot; TEST=...</code></pre> </body> </html> --- 145,155 ---- <p>Number of warmup iterations to run before the measurement phase in each fork. Same as specifying <code>-wi &lt;num&gt;</code>.</p> <h4 id="warmup_time">WARMUP_TIME</h4> <p>Amount of time to spend in each warmup iteration. Same as specifying <code>-w &lt;num&gt;</code>.</p> <h4 id="results_format">RESULTS_FORMAT</h4> <p>Specify to have the test run save a log of the values. Accepts the same values as <code>-rff</code>, i.e., <code>text</code>, <code>csv</code>, <code>scsv</code>, <code>json</code>, or <code>latex</code>.</p> ! <h4 id="vm_options-1">VM_OPTIONS</h4> <p>Additional VM arguments to provide to forked off VMs. Same as <code>-jvmArgs &lt;args&gt;</code></p> <h4 id="options-2">OPTIONS</h4> <p>Additional arguments to send to JMH.</p> </body> </html>
< prev index next >