Bug 1173447 - bustage fix followup
authorSteve Fink <sfink@mozilla.com>
Thu, 03 Mar 2016 13:19:15 -0800
changeset 323051 715c9c3fc90bc6ac92c7d8627ef8582bae5d706a
parent 323050 7cace407920cbb008f0dd2f0308293820ac058d4
child 323052 4e5549c719d0c1c6851f18fdc14e3799ba456836
push id5913
push userjlund@mozilla.com
push dateMon, 25 Apr 2016 16:57:49 +0000
treeherdermozilla-beta@dcaf0a6fa115 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1173447
milestone47.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1173447 - bustage fix followup MozReview-Commit-ID: IsQ1EtCypX8
js/src/jsapi-tests/testGCMarking.cpp
--- a/js/src/jsapi-tests/testGCMarking.cpp
+++ b/js/src/jsapi-tests/testGCMarking.cpp
@@ -168,19 +168,21 @@ BEGIN_TEST(testIncrementalRoots)
     // that is turned off.)
     MOZ_ASSERT(JS::IsIncrementalGCInProgress(rt));
 
     // And assert that the mark bits are as we expect them to be.
     MOZ_ASSERT(vec[0]->asTenured().isMarked());
     MOZ_ASSERT(!leafHandle->asTenured().isMarked());
     MOZ_ASSERT(!leafOwnerHandle->asTenured().isMarked());
 
+#ifdef DEBUG
     // Remember the current GC number so we can assert that no GC occurs
     // between operations.
     auto currentGCNumber = rt->gc.gcNumber();
+#endif
 
     // Now do the incremental GC's worst nightmare: rip an unmarked object
     // 'leaf' out of the graph and stick it into an already-marked region (hang
     // it off the un-prebarriered root, in fact). The pre-barrier on the
     // overwrite of the source location should cause this object to be marked.
     if (!JS_SetProperty(cx, leafOwnerHandle, "obj", JS::UndefinedHandleValue))
         return false;
     MOZ_ASSERT(rt->gc.gcNumber() == currentGCNumber);