<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi folks,<div class=""><br class=""></div><div class="">Ever wanted to run tests with Debug ASSERTs enabled but the speed of the Debug build is so slow that it is a drag on your productivity? Well, now you can get a faster testing build in one of two ways:</div><div class=""><br class=""></div><div class="">1. Build WebKit with "make testing” (or “make t”)</div><div class="">2. Build WebKit with “make release+assert” (or “make ra”)</div><div class=""><br class=""></div><div class=""><b class="">testing</b></div><div class="">The “testing” make target builds a Debug build with the clang optimization level forced to -O3. </div><div class=""><br class=""></div><div class=""> The forcing of -O3 is achieved using "Tools/Scripts/set-webkit-configuration --force-optimization-level=O3”. See <a href="http://trac.webkit.org/r254080" class="">trac.webkit.org/r254080</a>.</div><div class=""> With this configuration, you can run JSC tests or layout tests like normal, except it will run faster.</div><div class=""><br class=""></div><div class=""> How much faster?</div><div class=""> Using a normal debug build, the JSC tests takes about 6 hours to complete.</div><div class=""> Using the “testing” build, the JSC tests takes less than 30 minutes to complete.</div><div class=""><br class=""></div><div class=""><b class="">release+assert</b></div><div class="">The “release+assert” make target builds a Release build with ASSERT_ENABLED=1 defined.</div><div class=""><br class=""></div><div class=""> With this configuration, you can run JSC tests.</div><div class=""> Currently, if you run this on the layout tests, you will see a lot of ASSERT failures, which brings us to ...</div><div class=""><br class=""></div><div class=""><b class="">#if ASSERT_ENABLED vs #ifndef NDEBUG</b></div><div class="">Since <a href="http://trac.webkit.org/r254087" class="">trac.webkit.org/r254087</a>, the ASSERT_DISABLED flag has been completely replaced with ASSERT_ENABLED. </div><div class=""><br class=""></div><div class="">For code that guards fields and code needed to support debug ASSERTs, please use #if ASSERT_ENABLED going forward.</div><div class=""><br class=""></div><div class="">Please do NOT use #ifndef NDEBUG.</div><div class=""><br class=""></div><div class="">The reason the layout tests are failing ASSERTs when run on the “release+assert” build is because there are assertion support code above JavaScriptCore that are still guarded with #ifndef NDEBUG. If you would like to help fix some of these, do the following:</div><div class=""><br class=""></div><div class="">1. Build WebKit with “make release+assert”.</div><div class="">2. Run "Tools/Scripts/run-webkit-tests —release”.</div><div class="">3. Look for tests that crashed with “ASSERTION FAILED: “ in the crash log e.g. "<span style="white-space: pre-wrap;" class="">ASSERTION FAILED: m_tokenizer.isInDataState()</span>”.</div><div class="">4. Find anything that the assertion depends on which is guarded by #ifndef NDEBUG, and replace it with #if ASSERT_ENABLED.</div><div class="">5. Re-build WebKit and retest.</div><div class=""><br class=""></div><div class="">In general, there is probably no reason to ever use #ifndef NDEBUG. Apart from assertion code, logging (and possibly other) code may also be affected by this same issue.</div><div class=""><br class=""></div><div class=""><b class="">Miscellaneous details</b></div><div class="">The “testing” and “release+assert” make targets are available to use starting in <a href="http://trac.webkit.org/r254227" class="">trac.webkit.org/r254227</a>. I only tested these make targets on Mac. For other ports, some work may be required to get the builds configured similarly.</div><div class=""><br class=""></div><div class="">One caution about using the “testing” target: it configures the build environment using set-webkit-configuration. That means unless you clear the configuration using "set-webkit-configuration --force-optimization-level=none”, it will force the clang optimization level to -O3 for all builds that follow, debug or release. This is similar to how "set-webkit-configuration --asan” works. Alternatively, you can also do "set-webkit-configuration —reset” to clear all configurations set using set-webkit-configuration.</div><div class=""><br class=""></div><div class="">If typing “--force-optimization-level” is too long and painful, “--force-opt” also works.</div><div class=""><br class=""></div><div class=""><div class="">Thanks.</div><div class=""><br class=""></div></div><div class="">Mark</div><div class=""><br class=""></div></body></html>