Bug 1868629 - Don't attempt to recover from failure when creating GC markers for the first time r=sfink

The recovery behaviour was added so that attempting to enable parallel marking
by setting a GC parameter didn't cause a hard failure if there was an
allocation failure initializing the extra markers. However the change made it
so we would ignore failing to allocate the first marker (required) on
initialization.

This would have been caught by the OOM test we have for creating contexts, but
this uses the 'always fail' OOM injection mode. This means that an earlier
unhandled OOM condtions can be masked by a later one that is handled. For peace
of mind I changed the test to run in both single failure and permanent failure
modes.

Differential Revision: https://phabricator.services.mozilla.com/D195770

UltraBlame original commit: 12b53a3f19ff688bf80bd723e03511678147b7a7

Author: marco-c

js/src/gc/GC.cpp

@@ -4031,10 +4031,18 @@ size
 }
 #
 endif
-initOrDisableParallelMarking
+if
+(
+!
+updateMarkersVector
 (
 )
+)
+{
+return
+false
 ;
+}
 {
 AutoLockGCBgAlloc
 lock
@@ -6332,6 +6340,18 @@ initOrDisableParallelMarking
 (
 )
 {
+MOZ_ASSERT
+(
+markers
+.
+length
+(
+)
+!
+=
+0
+)
+;
 if
 (
 !

js/src/jsapi-tests/testOOM.cpp

@@ -166,17 +166,52 @@ testName
 name
 ;
 \
+for
+(
+bool
+always
+:
+{
+false
+true
+}
+)
+{
+\
+const
+char
+*
+subTest
+=
+always
+?
+"
+fail
+always
+"
+:
+"
+fail
+once
+"
+;
+\
 printf
 (
 "
 Test
 %
 s
+(
+%
+s
+)
 :
 started
 :
 "
 testName
+subTest
 )
 ;
 \
@@ -226,7 +261,7 @@ js
 :
 :
 THREAD_TYPE_MAIN
-true
+always
 )
 #
 define
@@ -254,6 +289,10 @@ printf
 nTest
 %
 s
+(
+%
+s
+)
 :
 finished
 with
@@ -265,8 +304,9 @@ allocations
 \
 n
 "
-testName
 \
+testName
+subTest
 oomAfter
 -
 1
@@ -280,6 +320,8 @@ break
 \
 }
 \
+}
+\
 js
 :
 :