JSObject::putInlineSlow should not ignore "__proto__" for Proxy
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-09-16  Saam Barati  <sbarati@apple.com>
2
3         JSObject::putInlineSlow should not ignore "__proto__" for Proxy
4         https://bugs.webkit.org/show_bug.cgi?id=200386
5         <rdar://problem/53854946>
6
7         Reviewed by Yusuke Suzuki.
8
9         We used to ignore '__proto__' in putInlineSlow when the object in question
10         was Proxy. There is no reason for this, and it goes against the spec. So
11         I've removed that condition. This also has the effect that it fixes an
12         assertion firing inside our inline caching code which dictates that for a
13         property replace that the base value's structure must be equal to the
14         structure when we grabbed the structure prior to the put operation.
15         The old code caused a weird edge case where we broke this invariant.
16
17         * runtime/JSObject.cpp:
18         (JSC::JSObject::putInlineSlow):
19
20 2019-09-15  David Kilzer  <ddkilzer@apple.com>
21
22         Leak of NSMapTable in -[JSVirtualMachine addManagedReference:withOwner:]
23         <https://webkit.org/b/201803>
24
25         Reviewed by Dan Bernstein.
26
27         * API/JSVirtualMachine.mm:
28         (-[JSVirtualMachine addManagedReference:withOwner:]): Use
29         RetainPtr<> to fix the leak.
30
31 2019-09-14  Yusuke Suzuki  <ysuzuki@apple.com>
32
33         Retire x86 32bit JIT support
34         https://bugs.webkit.org/show_bug.cgi?id=201790
35
36         Reviewed by Mark Lam.
37
38         Now, Xcode no longer has ability to build 32bit binary, so we cannot even test it on macOS.
39         Fedora stops shipping x86 32bit kernel. Our x86/x86_64 JIT requires SSE2, and so such relatively modern CPUs
40         can use JIT by switching x86 to x86_64. And these CPUs are modern enough to run CLoop at high speed.
41         WebKit already disabled x86 JIT by default while the implementation exists. So literary, it is not tested.
42
43         While x86 32bit becomes less useful, x86 32bit JIT backend is very complicated and is being a major maintenance burden.
44         This is due to very few # of registers. Which scatters a lot of isX86 / CPU(X86) in Baseline, DFG, and Yarr.
45
46         This patch retires x86 JIT support from JavaScriptCore and CSS JIT. We still keep MacroAssembler and GPRInfo / FPRInfo,
47         MachineContext information since they are useful even though JIT is not supported.
48
49         * dfg/DFGArrayMode.cpp:
50         (JSC::DFG::ArrayMode::refine const):
51         * dfg/DFGByteCodeParser.cpp:
52         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
53         (JSC::DFG::ByteCodeParser::parseBlock):
54         * dfg/DFGFixupPhase.cpp:
55         (JSC::DFG::FixupPhase::fixupNode):
56         * dfg/DFGJITCompiler.cpp:
57         (JSC::DFG::JITCompiler::compileExceptionHandlers):
58         * dfg/DFGOSRExitCompilerCommon.cpp:
59         (JSC::DFG::osrWriteBarrier):
60         * dfg/DFGSpeculativeJIT.cpp:
61         (JSC::DFG::SpeculativeJIT::compileArithDiv):
62         (JSC::DFG::SpeculativeJIT::compileArithMod):
63         (JSC::DFG::SpeculativeJIT::compileCreateRest):
64         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
65         * dfg/DFGSpeculativeJIT.h:
66         * dfg/DFGSpeculativeJIT32_64.cpp:
67         (JSC::DFG::SpeculativeJIT::emitCall):
68         (JSC::DFG::SpeculativeJIT::compile):
69         * dfg/DFGThunks.cpp:
70         (JSC::DFG::osrExitGenerationThunkGenerator):
71         * ftl/FTLThunks.cpp:
72         (JSC::FTL::slowPathCallThunkGenerator):
73         * jit/AssemblyHelpers.cpp:
74         (JSC::AssemblyHelpers::callExceptionFuzz):
75         (JSC::AssemblyHelpers::debugCall):
76         * jit/AssemblyHelpers.h:
77         (JSC::AssemblyHelpers::emitComputeButterflyIndexingMask):
78         * jit/CCallHelpers.h:
79         (JSC::CCallHelpers::setupArgumentsImpl):
80         (JSC::CCallHelpers::prepareForTailCallSlow):
81         * jit/CallFrameShuffler.cpp:
82         (JSC::CallFrameShuffler::prepareForTailCall):
83         * jit/JIT.cpp:
84         (JSC::JIT::privateCompileExceptionHandlers):
85         * jit/JITArithmetic32_64.cpp:
86         (JSC::JIT::emit_op_mod):
87         (JSC::JIT::emitSlow_op_mod):
88         * jit/SlowPathCall.h:
89         (JSC::JITSlowPathCall::call):
90         * jit/ThunkGenerators.cpp:
91         (JSC::nativeForGenerator):
92         (JSC::arityFixupGenerator):
93         * wasm/WasmAirIRGenerator.cpp:
94         (JSC::Wasm::AirIRGenerator::emitModOrDiv):
95         * yarr/YarrJIT.cpp:
96         (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
97         (JSC::Yarr::YarrGenerator::generateEnter):
98         (JSC::Yarr::YarrGenerator::generateReturn):
99         (JSC::Yarr::YarrGenerator::compile):
100         * yarr/YarrJIT.h:
101
102 2019-09-13  Mark Lam  <mark.lam@apple.com>
103
104         jsc -d stopped working.
105         https://bugs.webkit.org/show_bug.cgi?id=201787
106
107         Reviewed by Joseph Pecoraro.
108
109         The reason is because, in this case, the jsc shell is trying to set an option
110         after the VM has been instantiated.  The fix is simply to move all options
111         initialization before the VM is instantiated.
112
113         * jsc.cpp:
114         (runWithOptions):
115         (jscmain):
116
117 2019-09-13  Mark Lam  <mark.lam@apple.com>
118
119         watchOS requires PageSize alignment of 16K for JSC::Config.
120         https://bugs.webkit.org/show_bug.cgi?id=201786
121         <rdar://problem/55357890>
122
123         Reviewed by Yusuke Suzuki.
124
125         * runtime/JSCConfig.h:
126
127 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
128
129         Unreviewed, follow-up fix after r249842
130         https://bugs.webkit.org/show_bug.cgi?id=201750
131
132         Michael reviewed this offline. When performing nearCall, we need to invalidate cache registers.
133
134         * assembler/MacroAssemblerARM64.h:
135         (JSC::MacroAssemblerARM64::nearCall):
136         (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
137
138 2019-09-13  Alexey Shvayka  <shvaikalesh@gmail.com>
139
140         Date.prototype.toJSON does not execute steps 1-2
141         https://bugs.webkit.org/show_bug.cgi?id=105282
142
143         Reviewed by Ross Kirsling.
144
145         According to https://tc39.es/ecma262/#sec-built-in-function-objects, built-in methods must be
146         strict mode functions. Before this change, `this` value in Date.prototype.toJSON was resolved
147         using sloppy mode semantics, resulting in `toISOString` being called on global object if `this`
148         value equals `null` or `undefined`.
149
150         * runtime/DatePrototype.cpp:
151         (JSC::dateProtoFuncToJSON): Resolve thisValue using strict semantics and simplify std::isfinite check.
152
153 2019-09-13  Mark Lam  <mark.lam@apple.com>
154
155         performJITMemcpy() should do its !Gigacage assertion on exit.
156         https://bugs.webkit.org/show_bug.cgi?id=201780
157         <rdar://problem/55354867>
158
159         Reviewed by Robin Morisset.
160
161         Re-doing previous fix.
162
163         * jit/ExecutableAllocator.h:
164         (JSC::performJITMemcpy):
165         (JSC::GigacageAssertScope::GigacageAssertScope): Deleted.
166         (JSC::GigacageAssertScope::~GigacageAssertScope): Deleted.
167
168 2019-09-13  Mark Lam  <mark.lam@apple.com>
169
170         performJITMemcpy() should do its !Gigacage assertion on exit.
171         https://bugs.webkit.org/show_bug.cgi?id=201780
172         <rdar://problem/55354867>
173
174         Reviewed by Robin Morisset.
175
176         * jit/ExecutableAllocator.h:
177         (JSC::GigacageAssertScope::GigacageAssertScope):
178         (JSC::GigacageAssertScope::~GigacageAssertScope):
179         (JSC::performJITMemcpy):
180
181 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
182
183         [JSC] Micro-optimize YarrJIT's surrogate pair handling
184         https://bugs.webkit.org/show_bug.cgi?id=201750
185
186         Reviewed by Michael Saboff.
187
188         Optimize sequence of machine code used to get code-point with unicode flag.
189
190         * yarr/YarrJIT.cpp:
191         (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
192
193 2019-09-13  Mark Lam  <mark.lam@apple.com>
194
195         We should assert $vm is enabled on entry and exit in its functions.
196         https://bugs.webkit.org/show_bug.cgi?id=201762
197         <rdar://problem/55338742>
198
199         Rubber-stamped by Michael Saboff.
200
201         1. Also do the same for FunctionOverrides.
202         2. Added the DollarVMAssertScope and FunctionOverridesAssertScope to achieve this.
203         3. Also added assertions to lambda functions in $vm.
204
205         * tools/FunctionOverrides.cpp:
206         (JSC::FunctionOverridesAssertScope::FunctionOverridesAssertScope):
207         (JSC::FunctionOverridesAssertScope::~FunctionOverridesAssertScope):
208         (JSC::FunctionOverrides::overrides):
209         (JSC::FunctionOverrides::FunctionOverrides):
210         (JSC::FunctionOverrides::reinstallOverrides):
211         (JSC::initializeOverrideInfo):
212         (JSC::FunctionOverrides::initializeOverrideFor):
213         (JSC::parseClause):
214         (JSC::FunctionOverrides::parseOverridesInFile):
215         * tools/JSDollarVM.cpp:
216         (JSC::JSDollarVMCallFrame::JSDollarVMCallFrame):
217         (JSC::JSDollarVMCallFrame::createStructure):
218         (JSC::JSDollarVMCallFrame::create):
219         (JSC::JSDollarVMCallFrame::finishCreation):
220         (JSC::JSDollarVMCallFrame::addProperty):
221         (JSC::Element::Element):
222         (JSC::Element::create):
223         (JSC::Element::visitChildren):
224         (JSC::Element::createStructure):
225         (JSC::Root::Root):
226         (JSC::Root::setElement):
227         (JSC::Root::create):
228         (JSC::Root::createStructure):
229         (JSC::Root::visitChildren):
230         (JSC::SimpleObject::SimpleObject):
231         (JSC::SimpleObject::create):
232         (JSC::SimpleObject::visitChildren):
233         (JSC::SimpleObject::createStructure):
234         (JSC::ImpureGetter::ImpureGetter):
235         (JSC::ImpureGetter::createStructure):
236         (JSC::ImpureGetter::create):
237         (JSC::ImpureGetter::finishCreation):
238         (JSC::ImpureGetter::getOwnPropertySlot):
239         (JSC::ImpureGetter::visitChildren):
240         (JSC::CustomGetter::CustomGetter):
241         (JSC::CustomGetter::createStructure):
242         (JSC::CustomGetter::create):
243         (JSC::CustomGetter::getOwnPropertySlot):
244         (JSC::CustomGetter::customGetter):
245         (JSC::CustomGetter::customGetterAcessor):
246         (JSC::RuntimeArray::create):
247         (JSC::RuntimeArray::destroy):
248         (JSC::RuntimeArray::getOwnPropertySlot):
249         (JSC::RuntimeArray::getOwnPropertySlotByIndex):
250         (JSC::RuntimeArray::createPrototype):
251         (JSC::RuntimeArray::createStructure):
252         (JSC::RuntimeArray::finishCreation):
253         (JSC::RuntimeArray::RuntimeArray):
254         (JSC::RuntimeArray::lengthGetter):
255         (JSC::DOMJITNode::DOMJITNode):
256         (JSC::DOMJITNode::createStructure):
257         (JSC::DOMJITNode::checkSubClassSnippet):
258         (JSC::DOMJITNode::create):
259         (JSC::DOMJITGetter::DOMJITGetter):
260         (JSC::DOMJITGetter::createStructure):
261         (JSC::DOMJITGetter::create):
262         (JSC::DOMJITGetter::DOMJITAttribute::slowCall):
263         (JSC::DOMJITGetter::DOMJITAttribute::callDOMGetter):
264         (JSC::DOMJITGetter::customGetter):
265         (JSC::DOMJITGetter::finishCreation):
266         (JSC::DOMJITGetterComplex::DOMJITGetterComplex):
267         (JSC::DOMJITGetterComplex::createStructure):
268         (JSC::DOMJITGetterComplex::create):
269         (JSC::DOMJITGetterComplex::DOMJITAttribute::slowCall):
270         (JSC::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
271         (JSC::DOMJITGetterComplex::functionEnableException):
272         (JSC::DOMJITGetterComplex::customGetter):
273         (JSC::DOMJITGetterComplex::finishCreation):
274         (JSC::DOMJITFunctionObject::DOMJITFunctionObject):
275         (JSC::DOMJITFunctionObject::createStructure):
276         (JSC::DOMJITFunctionObject::create):
277         (JSC::DOMJITFunctionObject::functionWithTypeCheck):
278         (JSC::DOMJITFunctionObject::functionWithoutTypeCheck):
279         (JSC::DOMJITFunctionObject::checkSubClassSnippet):
280         (JSC::DOMJITFunctionObject::finishCreation):
281         (JSC::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
282         (JSC::DOMJITCheckSubClassObject::createStructure):
283         (JSC::DOMJITCheckSubClassObject::create):
284         (JSC::DOMJITCheckSubClassObject::functionWithTypeCheck):
285         (JSC::DOMJITCheckSubClassObject::functionWithoutTypeCheck):
286         (JSC::DOMJITCheckSubClassObject::finishCreation):
287         (JSC::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
288         (JSC::DOMJITGetterBaseJSObject::createStructure):
289         (JSC::DOMJITGetterBaseJSObject::create):
290         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
291         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
292         (JSC::DOMJITGetterBaseJSObject::customGetter):
293         (JSC::DOMJITGetterBaseJSObject::finishCreation):
294         (JSC::JSTestCustomGetterSetter::JSTestCustomGetterSetter):
295         (JSC::JSTestCustomGetterSetter::create):
296         (JSC::JSTestCustomGetterSetter::createStructure):
297         (JSC::customSetAccessor):
298         (JSC::customSetValue):
299         (JSC::JSTestCustomGetterSetter::finishCreation):
300         (JSC::Element::handleOwner):
301         (JSC::Element::finishCreation):
302         (JSC::WasmStreamingParser::WasmStreamingParser):
303         (JSC::WasmStreamingParser::create):
304         (JSC::WasmStreamingParser::createStructure):
305         (JSC::WasmStreamingParser::finishCreation):
306         (JSC::functionWasmStreamingParserAddBytes):
307         (JSC::functionWasmStreamingParserFinalize):
308         (JSC::functionCrash):
309         (JSC::functionBreakpoint):
310         (JSC::functionDFGTrue):
311         (JSC::functionFTLTrue):
312         (JSC::functionCpuMfence):
313         (JSC::functionCpuRdtsc):
314         (JSC::functionCpuCpuid):
315         (JSC::functionCpuPause):
316         (JSC::functionCpuClflush):
317         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
318         (JSC::getExecutableForFunction):
319         (JSC::functionLLintTrue):
320         (JSC::functionJITTrue):
321         (JSC::functionNoInline):
322         (JSC::functionGC):
323         (JSC::functionEdenGC):
324         (JSC::functionDumpSubspaceHashes):
325         (JSC::functionCallFrame):
326         (JSC::functionCodeBlockForFrame):
327         (JSC::codeBlockFromArg):
328         (JSC::functionCodeBlockFor):
329         (JSC::functionDumpSourceFor):
330         (JSC::functionDumpBytecodeFor):
331         (JSC::doPrint):
332         (JSC::functionDataLog):
333         (JSC::functionPrint):
334         (JSC::functionDumpCallFrame):
335         (JSC::functionDumpStack):
336         (JSC::functionDumpRegisters):
337         (JSC::functionDumpCell):
338         (JSC::functionIndexingMode):
339         (JSC::functionInlineCapacity):
340         (JSC::functionValue):
341         (JSC::functionGetPID):
342         (JSC::functionHaveABadTime):
343         (JSC::functionIsHavingABadTime):
344         (JSC::functionCreateGlobalObject):
345         (JSC::functionCreateProxy):
346         (JSC::functionCreateRuntimeArray):
347         (JSC::functionCreateNullRopeString):
348         (JSC::functionCreateImpureGetter):
349         (JSC::functionCreateCustomGetterObject):
350         (JSC::functionCreateDOMJITNodeObject):
351         (JSC::functionCreateDOMJITGetterObject):
352         (JSC::functionCreateDOMJITGetterComplexObject):
353         (JSC::functionCreateDOMJITFunctionObject):
354         (JSC::functionCreateDOMJITCheckSubClassObject):
355         (JSC::functionCreateDOMJITGetterBaseJSObject):
356         (JSC::functionCreateWasmStreamingParser):
357         (JSC::functionSetImpureGetterDelegate):
358         (JSC::functionCreateBuiltin):
359         (JSC::functionGetPrivateProperty):
360         (JSC::functionCreateRoot):
361         (JSC::functionCreateElement):
362         (JSC::functionGetElement):
363         (JSC::functionCreateSimpleObject):
364         (JSC::functionGetHiddenValue):
365         (JSC::functionSetHiddenValue):
366         (JSC::functionShadowChickenFunctionsOnStack):
367         (JSC::functionSetGlobalConstRedeclarationShouldNotThrow):
368         (JSC::functionFindTypeForExpression):
369         (JSC::functionReturnTypeFor):
370         (JSC::functionFlattenDictionaryObject):
371         (JSC::functionDumpBasicBlockExecutionRanges):
372         (JSC::functionHasBasicBlockExecuted):
373         (JSC::functionBasicBlockExecutionCount):
374         (JSC::functionEnableExceptionFuzz):
375         (JSC::changeDebuggerModeWhenIdle):
376         (JSC::functionEnableDebuggerModeWhenIdle):
377         (JSC::functionDisableDebuggerModeWhenIdle):
378         (JSC::functionDeleteAllCodeWhenIdle):
379         (JSC::functionGlobalObjectCount):
380         (JSC::functionGlobalObjectForObject):
381         (JSC::functionGetGetterSetter):
382         (JSC::functionLoadGetterFromGetterSetter):
383         (JSC::functionCreateCustomTestGetterSetter):
384         (JSC::functionDeltaBetweenButterflies):
385         (JSC::functionTotalGCTime):
386         (JSC::functionParseCount):
387         (JSC::functionIsWasmSupported):
388         (JSC::JSDollarVM::finishCreation):
389         (JSC::JSDollarVM::addFunction):
390         (JSC::JSDollarVM::addConstructibleFunction):
391         * tools/JSDollarVM.h:
392         (JSC::DollarVMAssertScope::DollarVMAssertScope):
393         (JSC::DollarVMAssertScope::~DollarVMAssertScope):
394
395 2019-09-13  Joseph Pecoraro  <pecoraro@apple.com>
396
397         Web Inspector: Formatter: Pretty Print HTML resources (including inline <script>/<style>)
398         https://bugs.webkit.org/show_bug.cgi?id=201535
399         <rdar://problem/29119232>
400
401         Reviewed by Devin Rousso.
402
403         * debugger/Debugger.cpp:
404         (JSC::Debugger::resolveBreakpoint):
405         When resolving a breakpoint inside of an inline <script> we need to adjust
406         based on the starting position of the <script> in the HTML resource.
407
408 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
409
410         [JSC] X86Registers.h callee-save register definition is wrong
411         https://bugs.webkit.org/show_bug.cgi?id=201756
412
413         Reviewed by Mark Lam.
414
415         I think nobody is using X86 JIT backend, but it is simply wrong.
416         edi and esi should be callee-save.
417
418         * assembler/X86Registers.h:
419
420 2019-09-12  Mark Lam  <mark.lam@apple.com>
421
422         Harden JSC against the abuse of runtime options.
423         https://bugs.webkit.org/show_bug.cgi?id=201597
424         <rdar://problem/55167068>
425
426         Reviewed by Filip Pizlo.
427
428         Linux parts contributed by Carlos Garcia Campos <cgarcia@igalia.com>.
429
430         1. Introduce a JSC::Config struct that will be protected as ReadOnly once the
431            first VM instance is constructed.  The end of the VM constructor calls
432            Config::permanentlyFreeze() which will make the Config ReadOnly.
433
434            Note: this is currently only supported for OS(DARWIN) and OS(LINUX).
435            OS(WINDOWS) will need to implement some missing pieces before it can enable
436            this hardening (see FIXME in JSCConfig.cpp).
437
438            The hardening strategy here is to put immutable global values into the Config.
439            Any modifications that need to be made to these values must be done before the
440            first VM instance is done instantiating.  This ensures that no script will
441            ever run while the Config is still writable.
442
443            Also, the policy for this hardening is that a process is opted in by default.
444            If there's a valid need to disable this hardening (e.g. for some test
445            environments), the relevant process will need to opt itself out by calling
446            Config::configureForTesting().
447
448            The jsc shell, WK2 UI and WebContent processes are opted in by default.
449            Only test processes may be opt out.
450
451         2. Put all JSC::Options in the Config.  This enforces the invariant that options
452            can only be changed before we instantiate a VM.  Once a VM is instantiated,
453            the options are immutable.
454
455         3. Remove functionForceGCSlowPaths() from the jsc shell.  Setting
456            Options::forceGCSlowPaths this way is no longer allowed.
457
458         4. Re-factored the Options code (Options.h) into:
459            - OptionEntry.h: the data structure that stores the option values.
460            - OptionsList.h: the list of options.
461            - Options.h: the Options singleton object which is the interface for accessing options.
462
463            Renamed the JSC_OPTIONS macro to FOR_EACH_JSC_OPTION, because
464            "FOR_EACH_JSC_OPTION(SET_OPTION_VALUE)" reads a lot better than
465            "JSC_OPTIONS(FOR_EACH_OPTION)".
466
467         5. Change testapi to call Config::configureForTesting().  Parts of testapi makes
468            use of setting options in its tests.  Hence, this hardening is disabled for
469            testapi.
470
471            Note: the jsc shell does enable this hardening.
472
473         6. Put ExecutableAllocator's immutable globals in the Config.
474
475         7. RELEASE_ASSERT that restrictedOptionsEnabled in order to use the
476            FunctionOverrides test utility.
477
478         8. RELEASE_ASSERT that Options::useDollarVM() is enabled in order to use the $vm.
479
480            We must RELEASE_ASSERT(Options::useDollarVM()) in all JSDollarVM functions
481            that are non-trivial at an eye's glance.  This includes (but is not limited to):
482                constructors
483                create() factory
484                createStructure() factory
485                finishCreation()
486                HOST_CALL or operation functions
487                Constructors and methods of utility and test classes
488
489            The only exception are some constexpr constructors used for instantiating
490            globals (since these must have trivial constructors) e.g. DOMJITAttribute.
491            Instead, these constructors should always be ALWAYS_INLINE.
492
493         * API/glib/JSCOptions.cpp:
494         (jscOptionsSetValue):
495         (jscOptionsGetValue):
496         (jsc_options_foreach):
497         (jsc_options_get_option_group):
498         * API/tests/testapi.c:
499         (main):
500         * API/tests/testapi.cpp:
501         (configureJSCForTesting):
502         * CMakeLists.txt:
503         * JavaScriptCore.xcodeproj/project.pbxproj:
504         * Sources.txt:
505         * jit/ExecutableAllocator.cpp:
506         (JSC::isJITEnabled):
507         (JSC::ExecutableAllocator::setJITEnabled):
508         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
509         (JSC::ExecutableAllocator::isValid const):
510         (JSC::ExecutableAllocator::underMemoryPressure):
511         (JSC::ExecutableAllocator::memoryPressureMultiplier):
512         (JSC::ExecutableAllocator::allocate):
513         (JSC::ExecutableAllocator::isValidExecutableMemory):
514         (JSC::ExecutableAllocator::getLock const):
515         (JSC::ExecutableAllocator::committedByteCount):
516         (JSC::ExecutableAllocator::dumpProfile):
517         (JSC::startOfFixedExecutableMemoryPoolImpl):
518         (JSC::endOfFixedExecutableMemoryPoolImpl):
519         (JSC::isJITPC):
520         (JSC::dumpJITMemory):
521         (JSC::ExecutableAllocator::initialize):
522         (JSC::ExecutableAllocator::singleton):
523         * jit/ExecutableAllocator.h:
524         (JSC::performJITMemcpy):
525         * jsc.cpp:
526         (GlobalObject::finishCreation):
527         (functionJSCOptions):
528         (jscmain):
529         (functionForceGCSlowPaths): Deleted.
530         * runtime/ConfigFile.cpp:
531         (JSC::ConfigFile::parse):
532         * runtime/InitializeThreading.cpp:
533         (JSC::initializeThreading):
534         * runtime/JSCConfig.cpp: Added.
535         (JSC::Config::disableFreezingForTesting):
536         (JSC::Config::enableRestrictedOptions):
537         (JSC::Config::permanentlyFreeze):
538         * runtime/JSCConfig.h: Added.
539         (JSC::Config::configureForTesting):
540         * runtime/JSGlobalObject.cpp:
541         (JSC::JSGlobalObject::exposeDollarVM):
542         * runtime/OptionEntry.h: Added.
543         (JSC::OptionRange::operator= ):
544         (JSC::OptionRange::rangeString const):
545         * runtime/Options.cpp:
546         (JSC::Options::isAvailable):
547         (JSC::scaleJITPolicy):
548         (JSC::Options::initialize):
549         (JSC::Options::setOptions):
550         (JSC::Options::setOptionWithoutAlias):
551         (JSC::Options::setAliasedOption):
552         (JSC::Option::dump const):
553         (JSC::Option::operator== const):
554         (): Deleted.
555         (JSC::Options::enableRestrictedOptions): Deleted.
556         * runtime/Options.h:
557         (JSC::Option::Option):
558         (JSC::Option::defaultOption const):
559         (JSC::Option::boolVal):
560         (JSC::Option::unsignedVal):
561         (JSC::Option::doubleVal):
562         (JSC::Option::int32Val):
563         (JSC::Option::optionRangeVal):
564         (JSC::Option::optionStringVal):
565         (JSC::Option::gcLogLevelVal):
566         (JSC::OptionRange::operator= ): Deleted.
567         (JSC::OptionRange::rangeString const): Deleted.
568         * runtime/OptionsList.h: Added.
569         (JSC::countNumberOfJSCOptions):
570         * runtime/VM.cpp:
571         (JSC::VM::VM):
572         * tools/FunctionOverrides.cpp:
573         (JSC::FunctionOverrides::FunctionOverrides):
574         (JSC::FunctionOverrides::reinstallOverrides):
575         (JSC::FunctionOverrides::initializeOverrideFor):
576         (JSC::FunctionOverrides::parseOverridesInFile):
577         * tools/JSDollarVM.cpp:
578         (JSC::JSDollarVMCallFrame::JSDollarVMCallFrame):
579         (JSC::JSDollarVMCallFrame::createStructure):
580         (JSC::JSDollarVMCallFrame::create):
581         (JSC::JSDollarVMCallFrame::finishCreation):
582         (JSC::JSDollarVMCallFrame::addProperty):
583         (JSC::Element::Element):
584         (JSC::Element::create):
585         (JSC::Element::createStructure):
586         (JSC::Root::Root):
587         (JSC::Root::create):
588         (JSC::Root::createStructure):
589         (JSC::SimpleObject::SimpleObject):
590         (JSC::SimpleObject::create):
591         (JSC::SimpleObject::createStructure):
592         (JSC::ImpureGetter::ImpureGetter):
593         (JSC::ImpureGetter::createStructure):
594         (JSC::ImpureGetter::create):
595         (JSC::ImpureGetter::finishCreation):
596         (JSC::ImpureGetter::getOwnPropertySlot):
597         (JSC::CustomGetter::CustomGetter):
598         (JSC::CustomGetter::createStructure):
599         (JSC::CustomGetter::create):
600         (JSC::CustomGetter::getOwnPropertySlot):
601         (JSC::CustomGetter::customGetter):
602         (JSC::CustomGetter::customGetterAcessor):
603         (JSC::RuntimeArray::create):
604         (JSC::RuntimeArray::destroy):
605         (JSC::RuntimeArray::getOwnPropertySlot):
606         (JSC::RuntimeArray::getOwnPropertySlotByIndex):
607         (JSC::RuntimeArray::createPrototype):
608         (JSC::RuntimeArray::createStructure):
609         (JSC::RuntimeArray::finishCreation):
610         (JSC::RuntimeArray::RuntimeArray):
611         (JSC::RuntimeArray::lengthGetter):
612         (JSC::DOMJITNode::DOMJITNode):
613         (JSC::DOMJITNode::createStructure):
614         (JSC::DOMJITNode::checkSubClassSnippet):
615         (JSC::DOMJITNode::create):
616         (JSC::DOMJITGetter::DOMJITGetter):
617         (JSC::DOMJITGetter::createStructure):
618         (JSC::DOMJITGetter::create):
619         (JSC::DOMJITGetter::DOMJITAttribute::DOMJITAttribute):
620         (JSC::DOMJITGetter::DOMJITAttribute::slowCall):
621         (JSC::DOMJITGetter::DOMJITAttribute::callDOMGetter):
622         (JSC::DOMJITGetter::customGetter):
623         (JSC::DOMJITGetter::finishCreation):
624         (JSC::DOMJITGetterComplex::DOMJITGetterComplex):
625         (JSC::DOMJITGetterComplex::createStructure):
626         (JSC::DOMJITGetterComplex::create):
627         (JSC::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute):
628         (JSC::DOMJITGetterComplex::DOMJITAttribute::slowCall):
629         (JSC::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
630         (JSC::DOMJITGetterComplex::functionEnableException):
631         (JSC::DOMJITGetterComplex::customGetter):
632         (JSC::DOMJITGetterComplex::finishCreation):
633         (JSC::DOMJITFunctionObject::DOMJITFunctionObject):
634         (JSC::DOMJITFunctionObject::createStructure):
635         (JSC::DOMJITFunctionObject::create):
636         (JSC::DOMJITFunctionObject::functionWithTypeCheck):
637         (JSC::DOMJITFunctionObject::functionWithoutTypeCheck):
638         (JSC::DOMJITFunctionObject::checkSubClassSnippet):
639         (JSC::DOMJITFunctionObject::finishCreation):
640         (JSC::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
641         (JSC::DOMJITCheckSubClassObject::createStructure):
642         (JSC::DOMJITCheckSubClassObject::create):
643         (JSC::DOMJITCheckSubClassObject::functionWithTypeCheck):
644         (JSC::DOMJITCheckSubClassObject::functionWithoutTypeCheck):
645         (JSC::DOMJITCheckSubClassObject::finishCreation):
646         (JSC::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
647         (JSC::DOMJITGetterBaseJSObject::createStructure):
648         (JSC::DOMJITGetterBaseJSObject::create):
649         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
650         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
651         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
652         (JSC::DOMJITGetterBaseJSObject::customGetter):
653         (JSC::DOMJITGetterBaseJSObject::finishCreation):
654         (JSC::JSTestCustomGetterSetter::JSTestCustomGetterSetter):
655         (JSC::JSTestCustomGetterSetter::create):
656         (JSC::JSTestCustomGetterSetter::createStructure):
657         (JSC::customSetAccessor):
658         (JSC::customSetValue):
659         (JSC::JSTestCustomGetterSetter::finishCreation):
660         (JSC::Element::handleOwner):
661         (JSC::Element::finishCreation):
662         (JSC::WasmStreamingParser::WasmStreamingParser):
663         (JSC::WasmStreamingParser::create):
664         (JSC::WasmStreamingParser::createStructure):
665         (JSC::WasmStreamingParser::finishCreation):
666         (JSC::functionWasmStreamingParserAddBytes):
667         (JSC::functionWasmStreamingParserFinalize):
668         (JSC::functionCrash):
669         (JSC::functionBreakpoint):
670         (JSC::functionDFGTrue):
671         (JSC::functionFTLTrue):
672         (JSC::functionCpuMfence):
673         (JSC::functionCpuRdtsc):
674         (JSC::functionCpuCpuid):
675         (JSC::functionCpuPause):
676         (JSC::functionCpuClflush):
677         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
678         (JSC::getExecutableForFunction):
679         (JSC::functionLLintTrue):
680         (JSC::functionJITTrue):
681         (JSC::functionNoInline):
682         (JSC::functionGC):
683         (JSC::functionEdenGC):
684         (JSC::functionDumpSubspaceHashes):
685         (JSC::functionCallFrame):
686         (JSC::functionCodeBlockForFrame):
687         (JSC::codeBlockFromArg):
688         (JSC::functionCodeBlockFor):
689         (JSC::functionDumpSourceFor):
690         (JSC::functionDumpBytecodeFor):
691         (JSC::doPrint):
692         (JSC::functionDataLog):
693         (JSC::functionPrint):
694         (JSC::functionDumpCallFrame):
695         (JSC::functionDumpStack):
696         (JSC::functionDumpRegisters):
697         (JSC::functionDumpCell):
698         (JSC::functionIndexingMode):
699         (JSC::functionInlineCapacity):
700         (JSC::functionValue):
701         (JSC::functionGetPID):
702         (JSC::functionHaveABadTime):
703         (JSC::functionIsHavingABadTime):
704         (JSC::functionCreateGlobalObject):
705         (JSC::functionCreateProxy):
706         (JSC::functionCreateRuntimeArray):
707         (JSC::functionCreateNullRopeString):
708         (JSC::functionCreateImpureGetter):
709         (JSC::functionCreateCustomGetterObject):
710         (JSC::functionCreateDOMJITNodeObject):
711         (JSC::functionCreateDOMJITGetterObject):
712         (JSC::functionCreateDOMJITGetterComplexObject):
713         (JSC::functionCreateDOMJITFunctionObject):
714         (JSC::functionCreateDOMJITCheckSubClassObject):
715         (JSC::functionCreateDOMJITGetterBaseJSObject):
716         (JSC::functionCreateWasmStreamingParser):
717         (JSC::functionSetImpureGetterDelegate):
718         (JSC::functionCreateBuiltin):
719         (JSC::functionGetPrivateProperty):
720         (JSC::functionCreateRoot):
721         (JSC::functionCreateElement):
722         (JSC::functionGetElement):
723         (JSC::functionCreateSimpleObject):
724         (JSC::functionGetHiddenValue):
725         (JSC::functionSetHiddenValue):
726         (JSC::functionShadowChickenFunctionsOnStack):
727         (JSC::functionSetGlobalConstRedeclarationShouldNotThrow):
728         (JSC::functionFindTypeForExpression):
729         (JSC::functionReturnTypeFor):
730         (JSC::functionFlattenDictionaryObject):
731         (JSC::functionDumpBasicBlockExecutionRanges):
732         (JSC::functionHasBasicBlockExecuted):
733         (JSC::functionBasicBlockExecutionCount):
734         (JSC::functionEnableExceptionFuzz):
735         (JSC::changeDebuggerModeWhenIdle):
736         (JSC::functionEnableDebuggerModeWhenIdle):
737         (JSC::functionDisableDebuggerModeWhenIdle):
738         (JSC::functionDeleteAllCodeWhenIdle):
739         (JSC::functionGlobalObjectCount):
740         (JSC::functionGlobalObjectForObject):
741         (JSC::functionGetGetterSetter):
742         (JSC::functionLoadGetterFromGetterSetter):
743         (JSC::functionCreateCustomTestGetterSetter):
744         (JSC::functionDeltaBetweenButterflies):
745         (JSC::functionTotalGCTime):
746         (JSC::functionParseCount):
747         (JSC::functionIsWasmSupported):
748         (JSC::JSDollarVM::finishCreation):
749         (JSC::JSDollarVM::addFunction):
750         (JSC::JSDollarVM::addConstructibleFunction):
751         * tools/JSDollarVM.h:
752
753 2019-09-11  Devin Rousso  <drousso@apple.com>
754
755         Web Inspector: Canvas: instrument WebGPUDevice instead of GPUCanvasContext
756         https://bugs.webkit.org/show_bug.cgi?id=201650
757
758         Reviewed by Joseph Pecoraro.
759
760         Most of the actual "work" done with Web GPU actually uses a `WebGPUDevice`.
761
762         A `GPUCanvasContext` is basically just a display "client" of the device, and isn't even
763         required (e.g. compute pipeline).  We should treat the `GPUCanvasContext` almost like a
764         `-webkit-canvas` client of a `WebGPUDevice`.
765
766         * inspector/protocol/Canvas.json:
767          - Add `powerPreference` key to `ContextAttributes` type.
768          - Rename `requestCSSCanvasClientNodes` command to `requestClientNodes` for the above reason.
769          - Rename `cssCanvasClientNodesChanged` event to `clientNodesChanged` for the above reason.
770          - Rename `resolveCanvasContext` command to `resolveContext` since a `WebGPUDevice` isn't
771            really a "canvas".
772
773 2019-09-11  Yusuke Suzuki  <ysuzuki@apple.com>
774
775         [JSC] Add StringCodePointAt intrinsic
776         https://bugs.webkit.org/show_bug.cgi?id=201673
777
778         Reviewed by Michael Saboff.
779
780         JetStream2/UniPoker executes String#codePointAt frequently. We should handle it in ThunkGenerator, DFG, and FTL like we are doing so for String#charCodeAt.
781         This patch adds these supports for String#codePointAt to get ~10% score improvement in JetStream2/UniPoker.
782
783         In ThunkGenerator, we add a thunk for String#codePointAt, which accelerates LLInt and Baseline. In DFG, we handle this as StringCodePointAt node, and emit
784         inlined code in DFG and FTL. The characteristics of StringCodePointAt node is basically the same to StringCharAt. It has String array-mode, so it emits
785         preceding CheckArray. This ensures that (1) StringCodePointAt node itself does not do GC since the string is always resolved, and (2) we can skip the rope
786         check. This thing is just the same to the existing StringCharCodeAt mechanism.
787
788         * dfg/DFGAbstractInterpreterInlines.h:
789         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
790         * dfg/DFGBackwardsPropagationPhase.cpp:
791         (JSC::DFG::BackwardsPropagationPhase::propagate):
792         * dfg/DFGByteCodeParser.cpp:
793         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
794         * dfg/DFGClobberize.h:
795         (JSC::DFG::clobberize):
796         * dfg/DFGDoesGC.cpp:
797         (JSC::DFG::doesGC):
798         * dfg/DFGFixupPhase.cpp:
799         (JSC::DFG::FixupPhase::fixupNode):
800         * dfg/DFGNode.h:
801         (JSC::DFG::Node::hasArrayMode):
802         * dfg/DFGNodeType.h:
803         * dfg/DFGPredictionPropagationPhase.cpp:
804         * dfg/DFGSafeToExecute.h:
805         (JSC::DFG::safeToExecute):
806         * dfg/DFGSpeculativeJIT.h:
807         * dfg/DFGSpeculativeJIT32_64.cpp:
808         (JSC::DFG::SpeculativeJIT::compile):
809         * dfg/DFGSpeculativeJIT64.cpp:
810         (JSC::DFG::SpeculativeJIT::compile):
811         (JSC::DFG::SpeculativeJIT::compileStringCodePointAt):
812         * ftl/FTLCapabilities.cpp:
813         (JSC::FTL::canCompile):
814         * ftl/FTLLowerDFGToB3.cpp:
815         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
816         (JSC::FTL::DFG::LowerDFGToB3::compileStringCodePointAt):
817         * jit/JITInlines.h:
818         (JSC::JIT::emitLoadCharacterString):
819         * jit/ThunkGenerators.cpp:
820         (JSC::stringGetByValGenerator):
821         (JSC::stringCharLoad):
822         (JSC::stringPrototypeCodePointAtThunkGenerator):
823         * jit/ThunkGenerators.h:
824         * runtime/Intrinsic.cpp:
825         (JSC::intrinsicName):
826         * runtime/Intrinsic.h:
827         * runtime/StringPrototype.cpp:
828         (JSC::StringPrototype::finishCreation):
829         * runtime/VM.cpp:
830         (JSC::thunkGeneratorForIntrinsic):
831
832 2019-09-11  Michael Saboff  <msaboff@apple.com>
833
834         JSC crashes due to stack overflow while building RegExp
835         https://bugs.webkit.org/show_bug.cgi?id=201649
836
837         Reviewed by Yusuke Suzuki.
838
839         Check for running out of stack when we are optimizing RegExp containing BOL terms or
840         other deep copying of disjunctions.
841
842         * yarr/YarrPattern.cpp:
843         (JSC::Yarr::YarrPatternConstructor::copyDisjunction):
844         (JSC::Yarr::YarrPatternConstructor::copyTerm):
845         (JSC::Yarr::YarrPatternConstructor::error):
846         (JSC::Yarr::YarrPattern::compile):
847
848 2019-09-11  Truitt Savell  <tsavell@apple.com>
849
850         Unreviewed, rolling out r249753.
851
852         caused inspector/canvas/shaderProgram-add-remove-webgl.html to
853         crash on all Mac platforms.
854
855         Reverted changeset:
856
857         "Web Inspector: Canvas: instrument WebGPUDevice instead of
858         GPUCanvasContext"
859         https://bugs.webkit.org/show_bug.cgi?id=201650
860         https://trac.webkit.org/changeset/249753
861
862 2019-09-10  Devin Rousso  <drousso@apple.com>
863
864         Web Inspector: Canvas: instrument WebGPUDevice instead of GPUCanvasContext
865         https://bugs.webkit.org/show_bug.cgi?id=201650
866
867         Reviewed by Joseph Pecoraro.
868
869         Most of the actual "work" done with Web GPU actually uses a `WebGPUDevice`.
870
871         A `GPUCanvasContext` is basically just a display "client" of the device, and isn't even
872         required (e.g. compute pipeline).  We should treat the `GPUCanvasContext` almost like a
873         `-webkit-canvas` client of a `WebGPUDevice`.
874
875         * inspector/protocol/Canvas.json:
876          - Add `powerPreference` key to `ContextAttributes` type.
877          - Rename `requestCSSCanvasClientNodes` command to `requestClientNodes` for the above reason.
878          - Rename `cssCanvasClientNodesChanged` event to `clientNodesChanged` for the above reason.
879          - Rename `resolveCanvasContext` command to `resolveContext` since a `WebGPUDevice` isn't
880            really a "canvas".
881
882 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
883
884         [JSC] 32bit bitwide operation with all-one (-1) is wrong in B3
885         https://bugs.webkit.org/show_bug.cgi?id=201634
886
887         Reviewed by Mark Lam and Robin Morisset.
888
889         This patch includes two things. One is fixing 32bit bitwise operation with allOne constants. Another is fixing the existing bug in BitAnd strength reduction.
890
891         1. 32bit bitwise operation with allOne constants
892
893             Accidentally, the B3::Value is ConstInt32(-1), `value->isInt(std::numeric_limits<uint32_t>::max())` returns `false`!
894             For example, in BitAnd strength reduction,
895
896                 1034             // Turn this: BitAnd(value, all-ones)
897                 1035             // Into this: value.
898                 1036             if ((m_value->type() == Int64 && m_value->child(1)->isInt(std::numeric_limits<uint64_t>::max()))
899                 1037                 || (m_value->type() == Int32 && m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max()))) {
900                 1038                 replaceWithIdentity(m_value->child(0));
901                 1039                 break;
902                 1040             }
903
904             We use `m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max())`. However, Value::isInt is,
905
906                 262 inline bool Value::isInt(int64_t value) const
907                 263 {
908                 264     return hasInt() && asInt() == value;
909                 265 }
910
911             So, UINT32_MAX is expanded to int64_t, but it is not -1 since UINT32_MAX can be representable in int64_t. And Value::asInt implementation is,
912
913                 257 inline int64_t Value::asInt() const
914                 258 {
915                 259     return hasInt32() ? asInt32() : asInt64();
916                 260 }
917
918             So, we perform `static_cast<int64_t>(-1) == static_cast<int64_t>(UINT32_MAX)`. This is false, but this comparison is not what we want!
919             We should use `isInt32` and `isInt64` for bit patterns (like, operands for Bitwise opcodes).
920
921         2. BitAnd and BitOr strength reduction bug
922
923             We also fix the following optimization.
924
925                 // Turn this: BitAnd(Op(value, constant1), constant2)
926                 //     where !(constant1 & constant2)
927                 //       and Op is BitOr or BitXor
928                 // into this: BitAnd(value, constant2)
929
930             Since we stop further optimization when we match `if (m_value->child(1)->hasInt())`, the following optimization is never taken.
931
932                 // Turn this: BitAnd(BitXor(x, allOnes), c)
933                 // Into this: BitXor(BitOr(x, ~c), allOnes)
934
935             And we also found that this not-used optimization has a bug not inserting a newly produced constant B3::Value. This patch also fixes it.
936
937         For both, this patch adds tests. And (2) fix can be ensured that the testb3 does not crash with validate-graph option.
938
939         * b3/B3LowerToAir.cpp:
940         * b3/B3ReduceStrength.cpp:
941         * b3/testb3.h:
942         * b3/testb3_2.cpp:
943         (testBitAndNotNot32):
944         (testBitAndNotImm):
945         (testBitAndNotImm32):
946         (testBitOrAndAndArgs32):
947         (testBitOrAndSameArgs32):
948         (testBitOrNotNot32):
949         (testBitOrNotImm32):
950         (addBitTests):
951         * b3/testb3_3.cpp:
952         (testBitXorAndAndArgs32):
953         (testBitXorAndSameArgs32):
954
955 2019-09-10  Commit Queue  <commit-queue@webkit.org>
956
957         Unreviewed, rolling out r249721.
958         https://bugs.webkit.org/show_bug.cgi?id=201667
959
960         Discovering existing bug (Requested by yusukesuzuki on
961         #webkit).
962
963         Reverted changeset:
964
965         "[JSC] 32bit bitwide operation with all-one (-1) is wrong in
966         B3"
967         https://bugs.webkit.org/show_bug.cgi?id=201634
968         https://trac.webkit.org/changeset/249721
969
970 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
971
972         [JSC] CodeBlock::calleeSaveRegisters should not see half-baked JITData
973         https://bugs.webkit.org/show_bug.cgi?id=201664
974         <rdar://problem/52126927>
975
976         Reviewed by Tadeu Zagallo.
977
978         We are hitting the crash accessing invalid-pointer as CodeBlock::calleeSaveRegisters result.
979         This is because concurrent Baseline JIT compiler can access m_jitData without taking a lock through CodeBlock::calleeSaveRegisters.
980         Since m_jitData can be initialized in the main thread while calling CodeBlock::calleeSaveRegisters from concurrent Baseline JIT compiler thread,
981         we can see half-baked JITData structure which holds garbage pointers.
982
983         But we do not want to make CodeBlock::calleeSaveRegisters() call with CodeBlock::m_lock due to several reasons.
984
985         1. This function is very primitive one and it is called from various AssemblyHelpers functions and other code-generation functions. Some of these functions are
986            called while taking this exact same lock, so dead-lock can happen.
987         2. JITData::m_calleeSaveRegisters is filled only for DFG and FTL CodeBlock. And DFG and FTL code accesses these field after initializing properly. For Baseline JIT
988            compiler case, only thing we should do is that JITData should say m_calleeSaveRegisters is nullptr and it won't be filled for this CodeBlock.
989
990         Instead of guarding CodeBlock::calleeSaveRegisters() function with CodeBlock::m_lock, this patch inserts WTF::storeStoreFence when filling m_jitData. This ensures that
991         JITData::m_calleeSaveRegisters is initialized with nullptr when this JITData pointer is exposed to concurrent Baseline JIT compiler thread.
992
993         * bytecode/CodeBlock.cpp:
994         (JSC::CodeBlock::ensureJITDataSlow):
995
996 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
997
998         [JSC] ResultType implementation is wrong for bit ops, and ends up making ArithDiv take the DFG Int32 fast path even if Baseline constantly produces Double result
999         https://bugs.webkit.org/show_bug.cgi?id=198253
1000
1001         Reviewed by Mark Lam.
1002
1003         ResultType of bitwise operation needs to include TypeMaybeNumber. TypeInt32 is something like a flag indicating the number looks like a int32.
1004         When it is specified, TypeMaybeNumber must exist too. This issue compiles op_div in JetStream2/async-fs slow-path. And eventually DFG first mis-compiles
1005         it with Int32 ArithDiv while that div always produces double. And unnecessary OSR exit happens.
1006
1007         In this patch, we add TypeMaybeNumber to bigIntOrInt32Type correctly.
1008
1009         * parser/ResultType.h:
1010         (JSC::ResultType::bigIntOrInt32Type):
1011
1012 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
1013
1014         [JSC] 32bit bitwide operation with all-one (-1) is wrong in B3
1015         https://bugs.webkit.org/show_bug.cgi?id=201634
1016
1017         Reviewed by Mark Lam.
1018
1019         Accidentally, the B3::Value is ConstInt32(-1), `value->isInt(std::numeric_limits<uint32_t>::max())` returns `false`!
1020         For example, in BitAnd strength reduction,
1021
1022             1034             // Turn this: BitAnd(value, all-ones)
1023             1035             // Into this: value.
1024             1036             if ((m_value->type() == Int64 && m_value->child(1)->isInt(std::numeric_limits<uint64_t>::max()))
1025             1037                 || (m_value->type() == Int32 && m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max()))) {
1026             1038                 replaceWithIdentity(m_value->child(0));
1027             1039                 break;
1028             1040             }
1029
1030         We use `m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max())`. However, Value::isInt is,
1031
1032             262 inline bool Value::isInt(int64_t value) const
1033             263 {
1034             264     return hasInt() && asInt() == value;
1035             265 }
1036
1037         So, UINT32_MAX is expanded to int64_t, but it is not -1 since UINT32_MAX can be representable in int64_t. And Value::asInt implementation is,
1038
1039             257 inline int64_t Value::asInt() const
1040             258 {
1041             259     return hasInt32() ? asInt32() : asInt64();
1042             260 }
1043
1044         So, we perform `static_cast<int64_t>(-1) == static_cast<int64_t>(UINT32_MAX)`. This is false, but this comparison is not what we want!
1045         We should use `isInt32` and `isInt64` for bit patterns (like, operands for Bitwise opcodes).
1046
1047         We also fix the following optimization.
1048
1049             // Turn this: BitAnd(Op(value, constant1), constant2)
1050             //     where !(constant1 & constant2)
1051             //       and Op is BitOr or BitXor
1052             // into this: BitAnd(value, constant2)
1053
1054         Since we stop further optimization when we match `if (m_value->child(1)->hasInt())`, the following optimization is never taken.
1055
1056             // Turn this: BitAnd(BitXor(x, allOnes), c)
1057             // Into this: BitXor(BitOr(x, ~c), allOnes)
1058
1059         We add 32bit version of B3 tests for these optimizations.
1060
1061         * b3/B3LowerToAir.cpp:
1062         * b3/B3ReduceStrength.cpp:
1063         * b3/testb3.h:
1064         * b3/testb3_2.cpp:
1065         (testBitAndNotNot32):
1066         (testBitAndNotImm):
1067         (testBitAndNotImm32):
1068         (testBitOrAndAndArgs32):
1069         (testBitOrAndSameArgs32):
1070         (testBitOrNotNot32):
1071         (testBitOrNotImm32):
1072         (addBitTests):
1073         * b3/testb3_3.cpp:
1074         (testBitXorAndAndArgs32):
1075         (testBitXorAndSameArgs32):
1076
1077 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
1078
1079         [WebAssembly] Use StreamingParser in existing Wasm::BBQPlan
1080         https://bugs.webkit.org/show_bug.cgi?id=189043
1081
1082         Reviewed by Keith Miller.
1083
1084         This patch integrates Wasm::StreamingParser into the existing Wasm::BBQPlan.
1085         And remove Wasm::ModuleParser. This patch paves the way to implementing Wasm streaming features by
1086         using Wasm::StreamingParser.
1087
1088         Currently, we are not using streaming feature of StreamingParser. In a subsequent patch, we will
1089         create a mechanism to pipe a chunk of data to streaming parser to enable WebAssembly.compileStreaming
1090         and instantiateStreaming.
1091
1092         * JavaScriptCore.xcodeproj/project.pbxproj:
1093         * Sources.txt:
1094         * tools/JSDollarVM.cpp:
1095         (JSC::WasmStreamingParser::WasmStreamingParser):
1096         * wasm/WasmAirIRGenerator.cpp:
1097         (JSC::Wasm::parseAndCompileAir):
1098         * wasm/WasmAirIRGenerator.h:
1099         * wasm/WasmB3IRGenerator.cpp:
1100         (JSC::Wasm::parseAndCompile): Use FunctionData, it is good since it is more strongly typed.
1101         * wasm/WasmB3IRGenerator.h:
1102         * wasm/WasmBBQPlan.cpp:
1103         (JSC::Wasm::BBQPlan::BBQPlan):
1104         (JSC::Wasm::BBQPlan::didReceiveFunctionData): Add a callback, which invokes validation.
1105         (JSC::Wasm::BBQPlan::parseAndValidateModule): Use StreamingParser instead of old ModuleParser.
1106         (JSC::Wasm::BBQPlan::compileFunctions):
1107         (JSC::Wasm::BBQPlan::complete):
1108         * wasm/WasmBBQPlan.h:
1109         * wasm/WasmModuleParser.cpp: Removed.
1110         * wasm/WasmModuleParser.h: Removed.
1111         * wasm/WasmOMGForOSREntryPlan.cpp:
1112         (JSC::Wasm::OMGForOSREntryPlan::work):
1113         * wasm/WasmOMGPlan.cpp:
1114         (JSC::Wasm::OMGPlan::work):
1115         * wasm/WasmPlan.cpp:
1116         (JSC::Wasm::Plan::fail): Make fail function callable multiple times. The first error will be used.
1117         * wasm/WasmSectionParser.cpp:
1118         (JSC::Wasm::SectionParser::parseCode): Since the Code section is specially handled in StreamingParser, this code is never used.
1119         * wasm/WasmStreamingParser.cpp:
1120         (JSC::Wasm::StreamingParser::StreamingParser):
1121         (JSC::Wasm::StreamingParser::parseCodeSectionSize):
1122         (JSC::Wasm::StreamingParser::parseFunctionPayload):
1123         (JSC::Wasm::StreamingParser::parseSectionPayload):
1124         (JSC::Wasm::StreamingParser::finalize): Call client's callbacks at appropriate timings.
1125         * wasm/WasmStreamingParser.h:
1126         (JSC::Wasm::StreamingParserClient::didReceiveSectionData):
1127         (JSC::Wasm::StreamingParserClient::didReceiveFunctionData):
1128         (JSC::Wasm::StreamingParserClient::didFinishParsing): Add StreamingParserClient,
1129         which has 3 callbacks right now. StreamingParser gets this client and call these callbacks
1130         at appropriate timings.
1131         * wasm/WasmValidate.cpp:
1132         (JSC::Wasm::validateFunction):
1133         * wasm/WasmValidate.h: Use FunctionData, it is good since it is more strongly typed.
1134
1135 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
1136
1137         [JSC] CodeBlock::m_constantRegisters should be guarded by ConcurrentJSLock when Vector reallocate memory
1138         https://bugs.webkit.org/show_bug.cgi?id=201622
1139
1140         Reviewed by Mark Lam.
1141
1142         CodeBlock::visitChildren takes ConcurrentJSLock while iterating m_constantRegisters, some of the places reallocate
1143         this Vector without taking a lock. If a Vector memory is reallocated while iterating it in concurrent collector,
1144         the concurrent collector can see a garbage. This patch guards m_constantRegisters reallocation with ConcurrentJSLock.
1145
1146         * bytecode/CodeBlock.cpp:
1147         (JSC::CodeBlock::finishCreation):
1148         (JSC::CodeBlock::setConstantRegisters):
1149         * bytecode/CodeBlock.h:
1150         (JSC::CodeBlock::addConstant):
1151         (JSC::CodeBlock::addConstantLazily):
1152         * dfg/DFGDesiredWatchpoints.cpp:
1153         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
1154         (JSC::DFG::SymbolTableAdaptor::add):
1155         (JSC::DFG::FunctionExecutableAdaptor::add):
1156         * dfg/DFGGraph.cpp:
1157         (JSC::DFG::Graph::registerFrozenValues):
1158         * dfg/DFGJITFinalizer.cpp:
1159         (JSC::DFG::JITFinalizer::finalizeCommon):
1160         * dfg/DFGLazyJSValue.cpp:
1161         (JSC::DFG::LazyJSValue::emit const):
1162
1163 2019-09-09  Robin Morisset  <rmorisset@apple.com>
1164
1165         [Air] highOrderAdjacents in AbstractColoringAllocator::conservativeHeuristic should be some kind of array
1166         https://bugs.webkit.org/show_bug.cgi?id=197305
1167
1168         Reviewed by Keith Miller.
1169
1170         Currently it is a HashSet, but it only ever holds at most registerCount() items. And linear search tends to be faster on such a small collection than hashing + searching in a HashSet.
1171         Further benefits include avoiding the allocation of the HashSet, not actually adding the nodes adjacent to V (since there are no duplicates in the adjacency lists).
1172
1173         This patch also contains a trivial optimization: if the remaining number of nodes to consider + the number of highOrderAdjacents already seen is smaller than registerCount() we can return true directly.
1174         Apart from that, the patch got some trivial cleanup of GraphColoringRegisterAllocation::allocateOnBank() (that for example was only logging the number of iterations for FP registers, and not the more interesting number for GP registers).
1175
1176         The time spent in the register allocator throughout JetStream2 on this MacBook Pro moves from 3767 / 3710 / 3785 ms to 3551 / 3454 / 3503 ms.
1177         So about a 6% speedup for that phase, and between 1 and 1.5% speedup for FTL/OMG compilation overall.
1178
1179         No new tests as there is no intended change to the code being generated, and this was already tested by running testb3 + JetStream2.
1180
1181         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
1182
1183 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
1184
1185         [JSC] Use metadata table to iterate specific bytecode metadata instead of propertyAccessInstructions vector
1186         https://bugs.webkit.org/show_bug.cgi?id=201613
1187
1188         Reviewed by Mark Lam.
1189
1190         We do not need to maintain propertyAccessInstructions vector to access metadata tied to a specific bytecode opcode
1191         since we have MetadataTable::forEach<Op> feature. This removes propertyAccessInstructions entirely, and fixes the
1192         issue that `op_create_promise` missed propertyAccessInstructions registration (a name "propertyAccessInstructions" is
1193         misleading, it is like "instructions-requires-llint-finalize").
1194
1195         * bytecode/CodeBlock.cpp:
1196         (JSC::CodeBlock::propagateTransitions):
1197         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1198         * bytecode/UnlinkedCodeBlock.cpp:
1199         (JSC::UnlinkedCodeBlock::applyModification):
1200         (JSC::UnlinkedCodeBlock::shrinkToFit):
1201         * bytecode/UnlinkedCodeBlock.h:
1202         (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
1203         (JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions const): Deleted.
1204         (JSC::UnlinkedCodeBlock::propertyAccessInstructions const): Deleted.
1205         * bytecompiler/BytecodeGenerator.cpp:
1206         (JSC::BytecodeGenerator::emitResolveScope):
1207         (JSC::BytecodeGenerator::emitGetFromScope):
1208         (JSC::BytecodeGenerator::emitPutToScope):
1209         (JSC::BytecodeGenerator::emitGetById):
1210         (JSC::BytecodeGenerator::emitDirectGetById):
1211         (JSC::BytecodeGenerator::emitPutById):
1212         (JSC::BytecodeGenerator::emitDirectPutById):
1213         (JSC::BytecodeGenerator::emitCreateThis):
1214         (JSC::BytecodeGenerator::emitToThis):
1215         * runtime/CachedTypes.cpp:
1216         (JSC::CachedCodeBlock<CodeBlockType>::decode const):
1217         (JSC::CachedCodeBlock<CodeBlockType>::encode):
1218
1219 2019-09-07  Keith Miller  <keith_miller@apple.com>
1220
1221         OSR entry into wasm misses some contexts
1222         https://bugs.webkit.org/show_bug.cgi?id=201569
1223
1224         Reviewed by Yusuke Suzuki.
1225
1226         This patch fixes an issue where we could fail to capture some of
1227         our contexts when OSR entering into wasm code. Before we would
1228         only capture the state of the block immediately surrounding the
1229         entrance loop block header. We actually need to capture all
1230         enclosed stacks.
1231
1232         Additionally, we don't need to use variables for all the captured
1233         values. We can use a Phi and insert an upsilon just below the
1234         captured value.
1235
1236         * interpreter/CallFrame.h:
1237         * jsc.cpp:
1238         (GlobalObject::finishCreation):
1239         (functionCallerIsOMGCompiled):
1240         * wasm/WasmAirIRGenerator.cpp:
1241         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1242         (JSC::Wasm::AirIRGenerator::emitEntryTierUpCheck):
1243         (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
1244         (JSC::Wasm::AirIRGenerator::addLoop):
1245         * wasm/WasmB3IRGenerator.cpp:
1246         (JSC::Wasm::B3IRGenerator::createStack):
1247         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1248         (JSC::Wasm::B3IRGenerator::addConstant):
1249         (JSC::Wasm::B3IRGenerator::emitEntryTierUpCheck):
1250         (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
1251         (JSC::Wasm::B3IRGenerator::addLoop):
1252         (JSC::Wasm::B3IRGenerator::addEndToUnreachable):
1253         (JSC::Wasm::dumpExpressionStack):
1254         (JSC::Wasm::B3IRGenerator::dump):
1255         (JSC::Wasm::B3IRGenerator::Stack::Stack): Deleted.
1256         (JSC::Wasm::B3IRGenerator::Stack::append): Deleted.
1257         (JSC::Wasm::B3IRGenerator::Stack::takeLast): Deleted.
1258         (JSC::Wasm::B3IRGenerator::Stack::last): Deleted.
1259         (JSC::Wasm::B3IRGenerator::Stack::size const): Deleted.
1260         (JSC::Wasm::B3IRGenerator::Stack::isEmpty const): Deleted.
1261         (JSC::Wasm::B3IRGenerator::Stack::convertToExpressionList): Deleted.
1262         (JSC::Wasm::B3IRGenerator::Stack::at const): Deleted.
1263         (JSC::Wasm::B3IRGenerator::Stack::variableAt const): Deleted.
1264         (JSC::Wasm::B3IRGenerator::Stack::shrink): Deleted.
1265         (JSC::Wasm::B3IRGenerator::Stack::swap): Deleted.
1266         (JSC::Wasm::B3IRGenerator::Stack::dump const): Deleted.
1267         * wasm/WasmFunctionParser.h:
1268         (JSC::Wasm::FunctionParser::controlStack):
1269
1270 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
1271
1272         [JSC] Promise resolve/reject functions should be created more efficiently
1273         https://bugs.webkit.org/show_bug.cgi?id=201488
1274
1275         Reviewed by Mark Lam.
1276
1277         While r246553 fixed an important issue, it makes anonymous-builtin-function creation costly since it enforces FunctionRareData allocations.
1278         Unfortunately, anonymous-builtin-function function can be created frequently since this type of function is used
1279         for `resolve` and `reject` arguments of Promise's executor (e.g. `new Promise((resolve, reject) => ...)`'s resolve and reject).
1280         Since we are now always creating FunctionRareData for these functions, this additional allocation makes promise creation slower.
1281
1282         In this patch, we use `isAnonymousBuiltinFunction` information for `hasReifiedName` correctly. And we propagate `isAnonymousBuiltinFunction` information
1283         to FunctionRareData to initialize `m_hasReifiedName` correctly. Then we can avoid unnecessary FunctionRareData allocation, which makes
1284         anonymous-builtin-function creation faster.
1285
1286         We can ensure that this patch does not revert r246553's fix by running JSTests/stress/builtin-private-function-name.js test.
1287         The simple microbenchmark shows 1.7x improvement.
1288
1289                                               ToT                     Patched
1290
1291             promise-creation-many       45.6701+-0.1488     ^     26.8663+-1.8336        ^ definitely 1.6999x faster
1292
1293         * dfg/DFGSpeculativeJIT.cpp:
1294         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1295         * ftl/FTLLowerDFGToB3.cpp:
1296         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1297         * runtime/FunctionRareData.cpp:
1298         (JSC::FunctionRareData::create):
1299         (JSC::FunctionRareData::FunctionRareData):
1300         * runtime/FunctionRareData.h:
1301         * runtime/JSFunction.cpp:
1302         (JSC::JSFunction::finishCreation):
1303         (JSC::JSFunction::allocateRareData):
1304         (JSC::JSFunction::allocateAndInitializeRareData):
1305         * runtime/JSFunctionInlines.h:
1306         (JSC::JSFunction::hasReifiedName const):
1307
1308 2019-09-07  Mark Lam  <mark.lam@apple.com>
1309
1310         performJITMemcpy() source buffer should not be in the Gigacage.
1311         https://bugs.webkit.org/show_bug.cgi?id=201577
1312         <rdar://problem/55142606>
1313
1314         Reviewed by Michael Saboff.
1315
1316         Add a RELEASE_ASSERT in performJITMemcpy() to ensure that the passed in source
1317         buffer is not in the Gigacage.
1318
1319         * jit/ExecutableAllocator.h:
1320         (JSC::performJITMemcpy):
1321
1322 2019-09-07  Mark Lam  <mark.lam@apple.com>
1323
1324         The jsc shell should allow disabling of the Gigacage for testing purposes.
1325         https://bugs.webkit.org/show_bug.cgi?id=201579
1326
1327         Reviewed by Michael Saboff.
1328
1329         Check for the same GIGACAGE_ENABLED env var that is checked by Gigacage code.  If
1330         this env var is present and it has a falsy value, then do not
1331         forbidDisablingPrimitiveGigacage() in the jsc shell.
1332
1333         * jsc.cpp:
1334         (jscmain):
1335
1336 2019-09-06  Mark Lam  <mark.lam@apple.com>
1337
1338         Harden protection of the Gigacage Config parameters.
1339         https://bugs.webkit.org/show_bug.cgi?id=201570
1340         <rdar://problem/55134229>
1341
1342         Reviewed by Saam Barati.
1343
1344         Just renaming some function names here.
1345
1346         * assembler/testmasm.cpp:
1347         (JSC::testCagePreservesPACFailureBit):
1348         * jit/AssemblyHelpers.h:
1349         (JSC::AssemblyHelpers::cageConditionally):
1350         * jsc.cpp:
1351         (jscmain):
1352
1353 2019-09-06  Ross Kirsling  <ross.kirsling@sony.com>
1354
1355         Math.round() produces wrong result for value prior to 0.5
1356         https://bugs.webkit.org/show_bug.cgi?id=185115
1357
1358         Reviewed by Saam Barati.
1359
1360         Our Math.round implementation goes in the wrong direction for double values like 0.49999999999999994.
1361         This requires just a subtle adjustment for three of our four versions; only baseline JIT needed a full rewrite.
1362
1363         Specifically:
1364           - While 0.49999999999999994 is representable, 1 - 0.49999999999999994 is not (it turns into 0.5),
1365             so taking the difference between ceil(value)` and `value` is problematic.
1366           - The baseline implementation was doing `floor(x + 0.5)` for positive doubles and slowpathing negative ones
1367             (by falling back to jsRound). This patch gives baseline a legitimate implementation too.
1368
1369         * dfg/DFGSpeculativeJIT.cpp:
1370         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1371         * ftl/FTLLowerDFGToB3.cpp:
1372         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1373         * jit/ThunkGenerators.cpp:
1374         (JSC::roundThunkGenerator):
1375         * runtime/MathCommon.cpp:
1376
1377 2019-09-05  Joseph Pecoraro  <pecoraro@apple.com>
1378
1379         Tail Deleted Frames shown in Web Inspector are sometimes incorrect (Shadow Chicken)
1380         https://bugs.webkit.org/show_bug.cgi?id=201366
1381
1382         Reviewed by Saam Barati.
1383
1384         It is possible for the log buffer to be full right as someone is trying to
1385         log a function prologue. In such a case the machine stack has already been
1386         updated to include the new JavaScript call frame, but the prologue packet
1387         cannot be included in the update because the log is full. This would mean
1388         that the update fails to rationalize the machine stack with the shadow
1389         log / stack. Namely, the current JavaScript call frame is unable to
1390         find a matching prologue (the one we are holding to include after the update)
1391         and inserts a questionable value into the stack; and in the process
1392         missing and removing real potential tail calls.
1393
1394         For example:
1395         
1396             "use strict";
1397             function third() { return 1; }
1398             function second() { return third(); }
1399             function first() { return second(); }
1400             function start() { return first(); }
1401
1402         If the the log fills up just as we are entering `b` then we may have a list
1403         full log of packets looking like:
1404
1405           Shadow Log:
1406             ...
1407             { prologue-packet: entering `start` ... }
1408             { prologue-packet: entering `first` ... }
1409             { tail-packet: leaving `first` with a tail call }
1410
1411           Incoming Packet:
1412             { prologue-packet: entering `second` ... }
1413
1414           Current JS Stack:
1415             second
1416             start
1417
1418         Since the Current JavaScript stack already has `second`, if we process the
1419         log without the prologue for `second` then we push a confused entry on the
1420         shadow stack and clear the log such that we eventually lose the tail-call
1421         information for `first` to `second`.
1422
1423         This patch solves this issue by providing enough extra space in the log
1424         to always process the incoming packet when that forces an update. This way
1425         clients can continue to behave exactly as they are.
1426
1427         --
1428
1429         We also document a corner case in some circumstances where the shadow
1430         log may currently be insufficient to know how to reconcile:
1431         
1432         For example:
1433
1434             "use strict";
1435             function third() { return 1; }
1436             function second() { return third(); }
1437             function first() { return second(); }
1438             function doNothingTail() { return Math.random() }
1439             function start() {
1440                 for (i=0;i<1000;++i) doNothingTail();
1441                 return first();
1442             }
1443
1444         In this case the ShadowChicken log may be processed multiple times due
1445         to the many calls to `doNothingTail` / `Math.random()`. When calling the
1446         Native function no prologue packet is emitted, so it is unclear that we
1447         temporarly go deeper and come back out on the stack, so the log appears
1448         to have lots of doNothingTail calls reusing the same frame:
1449
1450           Shadow Log:
1451             ...
1452             , [123] {callee = 0x72a21aee0, frame = 0x7ffeef897270, callerFrame = 0x7ffeef8972e0, name = start}
1453             , [124] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1454             , [125] tail-packet:{frame = 0x7ffeef8971f0}
1455             , [126] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1456             , [127] tail-packet:{frame = 0x7ffeef8971f0}
1457             ...
1458             , [140] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1459             , [141] tail-packet:{frame = 0x7ffeef8971f0}
1460             , [142] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1461             , [143] tail-packet:{frame = 0x7ffeef8971f0}
1462             , [144] {callee = 0x72a21aeb0, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = first}
1463             , [145] tail-packet:{frame = 0x7ffeef8971f0}
1464             , [146] {callee = 0x72a21ae80, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = second}
1465             ...
1466
1467         This log would seem to be indistinguishable from real tail recursion, such as:
1468
1469             "use strict";
1470             function third() { return 1; }
1471             function second() { return third(); }
1472             function first() { return second(); }
1473             function doNothingTail(n) {
1474                 return n ? doNothingTail(n-1) : first();
1475             }
1476             function start() {
1477                 return doNothingTail(1000);
1478             }
1479
1480         Likewise there are more cases where the shadow log appears to be ambiguous with determining
1481         the appropriate parent call frame with intermediate function calls. In practice this may
1482         not be too problematic, as this is a best effort reconstruction of tail deleted frames.
1483         It seems likely we would only show additional frames that did in fact happen serially
1484         between JavaScript call frames, but may not actually be the proper parent frames
1485         heirachy in the stack.
1486
1487         * interpreter/ShadowChicken.cpp:
1488         (JSC::ShadowChicken::Packet::dump const):
1489         (JSC::ShadowChicken::Frame::dump const):
1490         (JSC::ShadowChicken::dump const):
1491         Improved debugging output. Especially for functions.
1492
1493         (JSC::ShadowChicken::ShadowChicken):
1494         Make space in the log for 1 additional packet to process when we slow log.
1495
1496         (JSC::ShadowChicken::log):
1497         Include this packet in our update.
1498
1499         (JSC::ShadowChicken::update):
1500         Address an edge case where we can eliminate tail-deleted frames that don't make sense.
1501
1502 2019-09-06  Ryan Haddad  <ryanhaddad@apple.com>
1503
1504         Unreviewed, rolling out r249566.
1505
1506         Causes inspector layout test crashes under GuardMalloc
1507
1508         Reverted changeset:
1509
1510         "Tail Deleted Frames shown in Web Inspector are sometimes
1511         incorrect (Shadow Chicken)"
1512         https://bugs.webkit.org/show_bug.cgi?id=201366
1513         https://trac.webkit.org/changeset/249566
1514
1515 2019-09-06  Guillaume Emont  <guijemont@igalia.com>
1516
1517         testmasm: save r6 in JIT'ed code on ARM_THUMB2
1518         https://bugs.webkit.org/show_bug.cgi?id=201138
1519
1520         Reviewed by Mark Lam.
1521
1522         MacroAssemblerArmv7 uses r6 as a temporary register, and it is a
1523         callee-saved register. The JITs use
1524         AssemblyHelpers::emitSaveCalleeSaves() and friends to save
1525         callee-saved registers, but there is no such mechanism in testmasm,
1526         which seems to make the assumption that the macroassembler does not
1527         use callee-saved registers (which I guess is true for all other
1528         architectures, but not for Armv7).
1529
1530         This issue means that testmasm crashes on Armv7 since code generated
1531         by gcc uses r6, and it gets modified by JIT'ed code.
1532
1533         This change makes sure that we save and restore r6 for all code
1534         compiled by testmasm on Armv7.
1535
1536         * assembler/testmasm.cpp:
1537         (JSC::emitFunctionPrologue):
1538         (JSC::emitFunctionEpilogue):
1539         (JSC::testSimple):
1540         (JSC::testGetEffectiveAddress):
1541         (JSC::testBranchTruncateDoubleToInt32):
1542         (JSC::testBranchTestBit32RegReg):
1543         (JSC::testBranchTestBit32RegImm):
1544         (JSC::testBranchTestBit32AddrImm):
1545         (JSC::testBranchTestBit64RegReg):
1546         (JSC::testBranchTestBit64RegImm):
1547         (JSC::testBranchTestBit64AddrImm):
1548         (JSC::testCompareDouble):
1549         (JSC::testMul32WithImmediates):
1550         (JSC::testMul32SignExtend):
1551         (JSC::testCompareFloat):
1552         (JSC::testProbeReadsArgumentRegisters):
1553         (JSC::testProbeWritesArgumentRegisters):
1554         (JSC::testProbePreservesGPRS):
1555         (JSC::testProbeModifiesStackPointer):
1556         (JSC::testProbeModifiesProgramCounter):
1557         (JSC::testProbeModifiesStackValues):
1558         (JSC::testByteSwap):
1559         (JSC::testMoveDoubleConditionally32):
1560         (JSC::testMoveDoubleConditionally64):
1561         (JSC::testCagePreservesPACFailureBit):
1562
1563 2019-09-05  Joseph Pecoraro  <pecoraro@apple.com>
1564
1565         Tail Deleted Frames shown in Web Inspector are sometimes incorrect (Shadow Chicken)
1566         https://bugs.webkit.org/show_bug.cgi?id=201366
1567
1568         Reviewed by Saam Barati.
1569
1570         It is possible for the log buffer to be full right as someone is trying to
1571         log a function prologue. In such a case the machine stack has already been
1572         updated to include the new JavaScript call frame, but the prologue packet
1573         cannot be included in the update because the log is full. This would mean
1574         that the update fails to rationalize the machine stack with the shadow
1575         log / stack. Namely, the current JavaScript call frame is unable to
1576         find a matching prologue (the one we are holding to include after the update)
1577         and inserts a questionable value into the stack; and in the process
1578         missing and removing real potential tail calls.
1579
1580         For example:
1581         
1582             "use strict";
1583             function third() { return 1; }
1584             function second() { return third(); }
1585             function first() { return second(); }
1586             function start() { return first(); }
1587
1588         If the the log fills up just as we are entering `b` then we may have a list
1589         full log of packets looking like:
1590
1591           Shadow Log:
1592             ...
1593             { prologue-packet: entering `start` ... }
1594             { prologue-packet: entering `first` ... }
1595             { tail-packet: leaving `first` with a tail call }
1596
1597           Incoming Packet:
1598             { prologue-packet: entering `second` ... }
1599
1600           Current JS Stack:
1601             second
1602             start
1603
1604         Since the Current JavaScript stack already has `second`, if we process the
1605         log without the prologue for `second` then we push a confused entry on the
1606         shadow stack and clear the log such that we eventually lose the tail-call
1607         information for `first` to `second`.
1608
1609         This patch solves this issue by providing enough extra space in the log
1610         to always process the incoming packet when that forces an update. This way
1611         clients can continue to behave exactly as they are.
1612
1613         --
1614
1615         We also document a corner case in some circumstances where the shadow
1616         log may currently be insufficient to know how to reconcile:
1617         
1618         For example:
1619
1620             "use strict";
1621             function third() { return 1; }
1622             function second() { return third(); }
1623             function first() { return second(); }
1624             function doNothingTail() { return Math.random() }
1625             function start() {
1626                 for (i=0;i<1000;++i) doNothingTail();
1627                 return first();
1628             }
1629
1630         In this case the ShadowChicken log may be processed multiple times due
1631         to the many calls to `doNothingTail` / `Math.random()`. When calling the
1632         Native function no prologue packet is emitted, so it is unclear that we
1633         temporarly go deeper and come back out on the stack, so the log appears
1634         to have lots of doNothingTail calls reusing the same frame:
1635
1636           Shadow Log:
1637             ...
1638             , [123] {callee = 0x72a21aee0, frame = 0x7ffeef897270, callerFrame = 0x7ffeef8972e0, name = start}
1639             , [124] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1640             , [125] tail-packet:{frame = 0x7ffeef8971f0}
1641             , [126] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1642             , [127] tail-packet:{frame = 0x7ffeef8971f0}
1643             ...
1644             , [140] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1645             , [141] tail-packet:{frame = 0x7ffeef8971f0}
1646             , [142] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
1647             , [143] tail-packet:{frame = 0x7ffeef8971f0}
1648             , [144] {callee = 0x72a21aeb0, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = first}
1649             , [145] tail-packet:{frame = 0x7ffeef8971f0}
1650             , [146] {callee = 0x72a21ae80, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = second}
1651             ...
1652
1653         This log would seem to be indistinguishable from real tail recursion, such as:
1654
1655             "use strict";
1656             function third() { return 1; }
1657             function second() { return third(); }
1658             function first() { return second(); }
1659             function doNothingTail(n) {
1660                 return n ? doNothingTail(n-1) : first();
1661             }
1662             function start() {
1663                 return doNothingTail(1000);
1664             }
1665
1666         Likewise there are more cases where the shadow log appears to be ambiguous with determining
1667         the appropriate parent call frame with intermediate function calls. In practice this may
1668         not be too problematic, as this is a best effort reconstruction of tail deleted frames.
1669         It seems likely we would only show additional frames that did in fact happen serially
1670         between JavaScript call frames, but may not actually be the proper parent frames
1671         heirachy in the stack.
1672
1673         * interpreter/ShadowChicken.cpp:
1674         (JSC::ShadowChicken::Packet::dump const):
1675         (JSC::ShadowChicken::Frame::dump const):
1676         (JSC::ShadowChicken::dump const):
1677         Improved debugging output. Especially for functions.
1678
1679         (JSC::ShadowChicken::ShadowChicken):
1680         Make space in the log for 1 additional packet to process when we slow log.
1681
1682         (JSC::ShadowChicken::log):
1683         Include this packet in our update.
1684
1685         (JSC::ShadowChicken::update):
1686         Address an edge case where we can eliminate tail-deleted frames that don't make sense.
1687
1688 2019-09-05  Mark Lam  <mark.lam@apple.com>
1689
1690         Refactor the Gigacage code to require less pointer casting.
1691         https://bugs.webkit.org/show_bug.cgi?id=201521
1692
1693         Reviewed by Saam Barati.
1694
1695         Change LLInt's loadCagedJSValue() to skip the caging if Gigacage is not enabled
1696         in the build.  This allows us to remove the unneeded stubs in WTF Gigacage.h.
1697
1698         * jit/AssemblyHelpers.h:
1699         (JSC::AssemblyHelpers::cageConditionally):
1700         * llint/LowLevelInterpreter.asm:
1701         * llint/LowLevelInterpreter64.asm:
1702         * runtime/VM.h:
1703         (JSC::VM::gigacageAuxiliarySpace):
1704
1705 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
1706
1707         Unreviewed, follow-up after r249530 and r249509
1708         https://bugs.webkit.org/show_bug.cgi?id=201495
1709
1710         Rename FTLOutput::weakPointer to alreadyRegisteredWeakPointer and alreadyRegisteredFrozenPointer.
1711
1712         * builtins/PromiseConstructor.js:
1713         (nakedConstructor.Promise.resolve):
1714         (nakedConstructor.Promise.reject):
1715         (nakedConstructor.Promise):
1716         (nakedConstructor.InternalPromise.resolve):
1717         (nakedConstructor.InternalPromise.reject):
1718         (nakedConstructor.InternalPromise):
1719         * ftl/FTLLowerDFGToB3.cpp:
1720         (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
1721         (JSC::FTL::DFG::LowerDFGToB3::frozenPointer):
1722         (JSC::FTL::DFG::LowerDFGToB3::weakStructure):
1723         * ftl/FTLOutput.h:
1724         (JSC::FTL::Output::alreadyRegisteredWeakPointer):
1725         (JSC::FTL::Output::alreadyRegisteredFrozenPointer):
1726         (JSC::FTL::Output::weakPointer): Deleted.
1727
1728 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
1729
1730         [JSC] Generalize Get/PutPromiseInternalField for InternalFieldObjectImpl
1731         https://bugs.webkit.org/show_bug.cgi?id=201513
1732
1733         Reviewed by Ross Kirsling.
1734
1735         This patch extracts JSPromise's internal fields mechanism as JSInternalFieldsObjectImpl, and make it reusable for the other objects.
1736         It is preparation for using this internal fields mechanism for generators, async functions, async generators, array iterators and so on.
1737
1738         The profiler is telling many recompilation of Generator's resume function (including async generator's one). We are using properties
1739         with private-symbols as a storage for internal state of generators. However, the spec defines that each generator from different generator-functions
1740         has different [[Prototype]]. While we need to share one Generator.prototype.next function, generators tend to have different Structures due to
1741         different [[Prototype]] and accessing internal fields with `get_by_id_direct` sadly becomes super megamorphic while it is not necessary.
1742         And every time new Structure for new generator pops up, DFG/FTL code for generator resume function gets OSR exit or eventually this function gets
1743         emits super generic code unfortunately. By using internal fields for storing these state, we can avoid this performance problem.
1744
1745         Bytecodes and corresponding DFG nodes are just renamed. JSPromise is now inheriting JSInternalFieldsObjectImpl, which can holds specified
1746         number of internal fields. And op_get_internal_field / op_put_internal_field can access these internal fields.
1747
1748         * CMakeLists.txt:
1749         * JavaScriptCore.xcodeproj/project.pbxproj:
1750         * bytecode/BytecodeList.rb:
1751         * bytecode/BytecodeUseDef.h:
1752         (JSC::computeUsesForBytecodeOffset):
1753         (JSC::computeDefsForBytecodeOffset):
1754         * bytecode/CodeBlock.cpp:
1755         (JSC::CodeBlock::finishCreation):
1756         * bytecode/Opcode.h:
1757         * bytecompiler/BytecodeGenerator.cpp:
1758         (JSC::BytecodeGenerator::emitGetInternalField):
1759         (JSC::BytecodeGenerator::emitPutInternalField):
1760         (JSC::BytecodeGenerator::emitGetPromiseInternalField): Deleted.
1761         (JSC::BytecodeGenerator::emitPutPromiseInternalField): Deleted.
1762         * bytecompiler/BytecodeGenerator.h:
1763         * bytecompiler/NodesCodegen.cpp:
1764         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getPromiseInternalField):
1765         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putPromiseInternalField):
1766         * dfg/DFGAbstractInterpreterInlines.h:
1767         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1768         * dfg/DFGByteCodeParser.cpp:
1769         (JSC::DFG::ByteCodeParser::parseBlock):
1770         * dfg/DFGCapabilities.cpp:
1771         (JSC::DFG::capabilityLevel):
1772         * dfg/DFGClobberize.h:
1773         (JSC::DFG::clobberize):
1774         * dfg/DFGDoesGC.cpp:
1775         (JSC::DFG::doesGC):
1776         * dfg/DFGFixupPhase.cpp:
1777         (JSC::DFG::FixupPhase::fixupNode):
1778         * dfg/DFGMayExit.cpp:
1779         * dfg/DFGNode.h:
1780         (JSC::DFG::Node::hasInternalFieldIndex):
1781         (JSC::DFG::Node::hasHeapPrediction):
1782         * dfg/DFGNodeType.h:
1783         * dfg/DFGPredictionPropagationPhase.cpp:
1784         * dfg/DFGSafeToExecute.h:
1785         (JSC::DFG::safeToExecute):
1786         * dfg/DFGSpeculativeJIT.cpp:
1787         (JSC::DFG::SpeculativeJIT::compileGetInternalField):
1788         (JSC::DFG::SpeculativeJIT::compilePutInternalField):
1789         (JSC::DFG::SpeculativeJIT::compileCreatePromise):
1790         (JSC::DFG::SpeculativeJIT::compileNewPromise):
1791         (JSC::DFG::SpeculativeJIT::compileGetPromiseInternalField): Deleted.
1792         (JSC::DFG::SpeculativeJIT::compilePutPromiseInternalField): Deleted.
1793         * dfg/DFGSpeculativeJIT.h:
1794         * dfg/DFGSpeculativeJIT32_64.cpp:
1795         (JSC::DFG::SpeculativeJIT::compile):
1796         * dfg/DFGSpeculativeJIT64.cpp:
1797         (JSC::DFG::SpeculativeJIT::compile):
1798         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1799         * ftl/FTLAbstractHeapRepository.h:
1800         * ftl/FTLCapabilities.cpp:
1801         (JSC::FTL::canCompile):
1802         * ftl/FTLLowerDFGToB3.cpp:
1803         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1804         (JSC::FTL::DFG::LowerDFGToB3::compileNewPromise):
1805         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
1806         (JSC::FTL::DFG::LowerDFGToB3::compileGetInternalField):
1807         (JSC::FTL::DFG::LowerDFGToB3::compilePutInternalField):
1808         (JSC::FTL::DFG::LowerDFGToB3::compileGetPromiseInternalField): Deleted.
1809         (JSC::FTL::DFG::LowerDFGToB3::compilePutPromiseInternalField): Deleted.
1810         * jit/JIT.cpp:
1811         (JSC::JIT::privateCompileMainPass):
1812         * jit/JIT.h:
1813         * jit/JITPropertyAccess.cpp:
1814         (JSC::JIT::emit_op_get_internal_field):
1815         (JSC::JIT::emit_op_put_internal_field):
1816         (JSC::JIT::emit_op_get_promise_internal_field): Deleted.
1817         (JSC::JIT::emit_op_put_promise_internal_field): Deleted.
1818         * jit/JITPropertyAccess32_64.cpp:
1819         (JSC::JIT::emit_op_get_internal_field):
1820         (JSC::JIT::emit_op_put_internal_field):
1821         (JSC::JIT::emit_op_get_promise_internal_field): Deleted.
1822         (JSC::JIT::emit_op_put_promise_internal_field): Deleted.
1823         * llint/LLIntOffsetsExtractor.cpp:
1824         * llint/LowLevelInterpreter.asm:
1825         * llint/LowLevelInterpreter32_64.asm:
1826         * llint/LowLevelInterpreter64.asm:
1827         * runtime/JSInternalFieldObjectImpl.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
1828         (JSC::JSInternalFieldObjectImpl::allocationSize):
1829         (JSC::JSInternalFieldObjectImpl::internalField const):
1830         (JSC::JSInternalFieldObjectImpl::internalField):
1831         (JSC::JSInternalFieldObjectImpl::offsetOfInternalFields):
1832         (JSC::JSInternalFieldObjectImpl::offsetOfInternalField):
1833         (JSC::JSInternalFieldObjectImpl::JSInternalFieldObjectImpl):
1834         * runtime/JSInternalFieldObjectImplInlines.h: Added.
1835         (JSC::JSInternalFieldObjectImpl<passedNumberOfInternalFields>::visitChildren):
1836         * runtime/JSPromise.cpp:
1837         (JSC::JSPromise::finishCreation):
1838         (JSC::JSPromise::visitChildren):
1839         (JSC::JSPromise::status const):
1840         (JSC::JSPromise::result const):
1841         (JSC::JSPromise::isHandled const):
1842         * runtime/JSPromise.h:
1843         (JSC::JSPromise::allocationSize): Deleted.
1844         (JSC::JSPromise::offsetOfInternalFields): Deleted.
1845         (JSC::JSPromise::offsetOfInternalField): Deleted.
1846         (): Deleted.
1847
1848 2019-09-05  Commit Queue  <commit-queue@webkit.org>
1849
1850         Unreviewed, rolling out r247463.
1851         https://bugs.webkit.org/show_bug.cgi?id=201515
1852
1853         JetStream2 code-load related regression (Requested by
1854         yusukesuzuki on #webkit).
1855
1856         Reverted changeset:
1857
1858         "Keyword lookup can use memcmp to get around unaligned load
1859         undefined behavior"
1860         https://bugs.webkit.org/show_bug.cgi?id=199650
1861         https://trac.webkit.org/changeset/247463
1862
1863 2019-09-05  Tadeu Zagallo  <tzagallo@apple.com>
1864
1865         LazyClassStructure::setConstructor should not store the constructor to the global object
1866         https://bugs.webkit.org/show_bug.cgi?id=201484
1867         <rdar://problem/50400451>
1868
1869         Reviewed by Yusuke Suzuki.
1870
1871         LazyClassStructure::setConstructor sets the constructor as a property of the global object.
1872         This became a problem when it started being used for WebAssembly constructors, such as Module
1873         and Instance, since they are properties of the WebAssembly object, not the global object. That
1874         resulted in properties of the global object replaced whenever a lazy WebAssembly constructor
1875         was first accessed. e.g.
1876
1877         globalThis.Module = x;
1878         WebAssembly.Module;
1879         globalThis.Module === WebAssembly.Module;
1880
1881         * runtime/LazyClassStructure.cpp:
1882         (JSC::LazyClassStructure::Initializer::setConstructor):
1883         * runtime/LazyClassStructure.h:
1884         * runtime/Lookup.h:
1885         (JSC::reifyStaticProperty):
1886
1887 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
1888
1889         [JSC] Do not use FTLOutput::weakPointer directly
1890         https://bugs.webkit.org/show_bug.cgi?id=201495
1891
1892         Reviewed by Filip Pizlo.
1893
1894         FTLOutput::weakPointer does not register the cell as a weak pointer.
1895         CreatePromise's implementation is accidentally using m_out.weakPointer and hits the debug assertion.
1896         While the current implementation is not posing correctness issue since these cells are live so long as JSGlobalObject is live,
1897         and we register JSGlobalObject as a weakPointer, we should always use FTLLowerDFGToB3's helper function.
1898         For FrozenValue, we should use frozenPointer helper function.
1899
1900         * ftl/FTLLowerDFGToB3.cpp:
1901         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
1902         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
1903
1904 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
1905
1906         Unreviewed, partial roll out r249372 due to JetStream2/Basic ~10% regression
1907         https://bugs.webkit.org/show_bug.cgi?id=201373
1908
1909         * bytecode/BytecodeList.rb:
1910         * bytecode/BytecodeUseDef.h:
1911         (JSC::computeUsesForBytecodeOffset):
1912         (JSC::computeDefsForBytecodeOffset):
1913         * bytecompiler/BytecodeGenerator.cpp:
1914         (JSC::BytecodeGenerator::BytecodeGenerator):
1915         (JSC::BytecodeGenerator::emitLoopHint):
1916         (JSC::BytecodeGenerator::emitCheckTraps):
1917         * bytecompiler/BytecodeGenerator.h:
1918         * dfg/DFGByteCodeParser.cpp:
1919         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1920         (JSC::DFG::ByteCodeParser::parseBlock):
1921         * dfg/DFGCapabilities.cpp:
1922         (JSC::DFG::capabilityLevel):
1923         * jit/JIT.cpp:
1924         (JSC::JIT::emitEnterOptimizationCheck):
1925         (JSC::JIT::privateCompileMainPass):
1926         (JSC::JIT::privateCompileSlowCases):
1927         * jit/JIT.h:
1928         * jit/JITOpcodes.cpp:
1929         (JSC::JIT::emit_op_enter):
1930         (JSC::JIT::emit_op_loop_hint):
1931         (JSC::JIT::emitSlow_op_loop_hint):
1932         (JSC::JIT::emit_op_check_traps):
1933         (JSC::JIT::emitSlow_op_check_traps):
1934         (JSC::JIT::emitSlow_op_enter): Deleted.
1935         * jit/JITOpcodes32_64.cpp:
1936         (JSC::JIT::emit_op_enter):
1937         * llint/LowLevelInterpreter.asm:
1938         * llint/LowLevelInterpreter32_64.asm:
1939         * llint/LowLevelInterpreter64.asm:
1940         * runtime/CommonSlowPaths.cpp:
1941         (JSC::SLOW_PATH_DECL):
1942         * runtime/CommonSlowPaths.h:
1943
1944 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
1945
1946         Unreviewed, rebaseline builtin generator test results
1947         https://bugs.webkit.org/show_bug.cgi?id=200898
1948
1949         Rebaseline the result files.
1950
1951         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
1952         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
1953         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
1954         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
1955         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
1956         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
1957         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
1958         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
1959         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
1960         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
1961         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
1962         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
1963         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
1964
1965 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
1966
1967         [JSC] FunctionOverrides should have a lock to ensure concurrent access to hash table does not happen
1968         https://bugs.webkit.org/show_bug.cgi?id=201485
1969
1970         Reviewed by Tadeu Zagallo.
1971
1972         FunctionOverrides is a per-process singleton for registering overrides information. But we are accessing
1973         it without taking a lock. If multiple threads with multiple VMs are accessing this concurrently, we have
1974         a race issue like,
1975
1976         1. While one thread is adding overrides information,
1977         2. Another thread is accessing this hash table.
1978
1979         This patch adds a lock to make sure that only one thread can access this registry.
1980
1981         * tools/FunctionOverrides.cpp:
1982         (JSC::FunctionOverrides::FunctionOverrides):
1983         (JSC::FunctionOverrides::reinstallOverrides):
1984         (JSC::FunctionOverrides::initializeOverrideFor):
1985         (JSC::FunctionOverrides::parseOverridesInFile):
1986         * tools/FunctionOverrides.h:
1987         (JSC::FunctionOverrides::clear):
1988
1989 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
1990
1991         [JSC] Make Promise implementation faster
1992         https://bugs.webkit.org/show_bug.cgi?id=200898
1993
1994         Reviewed by Saam Barati.
1995
1996         This is the major change of the Promise implementation and it improves JetStream2/async-fs by 62%.
1997
1998         1. Make JSPromise C++ friendly
1999
2000             Instead of using objects with private properties (properties with private symbols), we put internal fields in JSPromise.
2001             This avoids allocating unnecessary butterflies for these private fields, and makes allocating JSPromise and accessing these
2002             fields from C++ easy. Moreover, this patch reduces # of fields of JSPromise from 4 to 2 to make JSPromise compact. To access these internal
2003             fields efficiently from JS, we add `op_get_promise_internal_field` and `op_put_promise_internal_field` bytecodes, and corresponding DFG/FTL
2004             supports. They are similar to GetClosureVar / PutClosureVar implementation. These two bytecodes are intentionally generic to later expand
2005             this support to generator and async-generator by renaming them to `op_get_internal_field` and `op_put_internal_field`. It is filed in [1].
2006
2007             We also add JSPromiseType as JSType. And structures for JSPromise should have that. So that now `@isPromise` is efficiently implemented.
2008             This also requires adding SpecPromiseObject and PromiseObjectUse to DFG.
2009
2010             Further, by introducing another bit flag representing `alreadyResolved` to JSPromise's flags, we can remove JSPromiseDeferred. This extension
2011             is filed in [2].
2012
2013         2. Make JSPromise constructor JS friendly
2014
2015             The old JSPromise constructor was very inefficient: JSPromise constructor is InternalFunction in C++, and in it, it
2016             calls `initializePromise` JS function. And this `initializePromise` function invokes `executor` function passed by user program.
2017             If we can implement JSPromise constructor fully in JS, we can recognize `executor` and we have a chance to fully inline them.
2018             Unfortunately, we cannot inline JSPromise constructor for now since it takes 120 bytecode cost while our inlining threshold for
2019             construct is 100. We might want to investigate getting it inlined in the future[3].
2020
2021             We can avoid C++ <-> JS dance in such an important operation, allocating JSPromise. This patch introduces @nakedConstructor
2022             annotation to builtin JS. And this is propagated as `ConstructorKind::Naked`. If this kind is attached, the bytecode generator
2023             do not emit `op_create_this` implicitly and the constructor does not return `this` object implicitly. The naked constructor allows
2024             us to emit bare-metal bytecode, specifically necessary to allocate non-final JSObject from JS constructor. We introduce op_create_promise,
2025             which is similar to op_create_this, but it allocates JSPromise. And by using @createPromise bytecode intrinsic, we implement
2026             JSPromise constructor fully in JS.
2027             With this, we can start introducing object-allocation-sinking for JSPromise too. It is filed in [4].
2028
2029         3. DFG supports for JSPromise operations
2030
2031             This patch adds four DFG nodes, CreatePromise, NewPromise, GetPromiseInternalField, and PutPromiseInternalField. CreatePromise mimics CreateThis,
2032             and NewPromise mimics NewObject. CreatePromise can be converted to NewPromise with some condition checks and NewPromise can efficiently allocate
2033             promises. CreatePromise and NewPromise have `isInternalPromise` flag so that InternalPromise is also correctly handled in DFG.
2034             When converting CreatePromise to NewPromise, we need to get the correct structure with a specified `callee.prototype`. We mimic the mechanism
2035             used in CreateThis, but we use InternalFunctionAllocationProfile instead of ObjectAllocationProfile because (1) InternalFunctionAllocationProfile
2036             can handle non-final JSObjects and (2) we do not need to handle inline-capacity for promises. To make InternalFunctionAllocationProfile usable
2037             in DFG, we connect watchpoint to InternalFunctionAllocationProfile's invalidation so that DFG code can notice when InternalFunctionAllocationProfile's
2038             structure is invalidated: `callee.prototype` is replaced.
2039
2040         4. Avoid creating unnecessary promises
2041
2042             Some promises are never shown to users, and they are never rejected. One example is `await`'s promise. And some of promise creation can be avoided.
2043             For example, when resolving a value with `Promise.resolve`, if a value is promise and if it's `then` method is the builtin `then`, we can avoid creating
2044             intermediate promise. To handle these things well, we introduce `@resolveWithoutPromise`, `@rejectWithoutPromise`, and `@fulfillWithoutPromise`. They
2045             take `onFulfilled` and `onRejected` handlers and they do not need an intermediate promise for resolving. This removes internal promise allocations
2046             in major cases and makes promise / async-functions efficient. And we also expose builtin `then` function as `@then`, and insert `@isPromise(xxx) && then === @then`
2047             check to take a fast path. We introduced four types of promise reactions to avoid some of object allocations. And microtask reaction is handling these four types.
2048
2049         5. Avoid creating resolving-functions and promise capabilities
2050
2051             Resolving functions have `alreadyResolved` flag to prevent calling `resolve` and `reject` multiple times. For the first resolving function creation, this
2052             patch embeds one bit flag to JSPromise itself which indicates `alreadyResolved` in the first created resolving functions (resolving functions can be later
2053             created again for the same promise. In that case, we just create a usual resolving functions). By doing so, we avoid unnecessary resolving functions
2054             and promise capability allocations. We introduce a wrapper function `@resolvePromiseWithFirstResolvingFunctionCallCheck` and `@rejectPromiseWithFirstResolvingFunctionCallCheck`.
2055             The resolving functions which are first created with `@newPromiseCapability` can be mechanically replaced with the calls to these functions, e.g. replacing
2056             `promiseCapability.@resolve.@call(@undefined, value)` with `@resolvePromiseWithFirstResolvingFunctionCallCheck(promise, value)`.
2057             This mechanism will be used to drop JSPromiseDeferred in a separate patch.
2058
2059         JetStream2/async-fs results.
2060             ToT:
2061                 Running async-fs:
2062                     Startup: 116.279
2063                     Worst Case: 151.515
2064                     Average: 176.630
2065                     Score: 145.996
2066                     Wall time: 0:01.149
2067
2068             Patched:
2069                 Running async-fs:
2070                     Startup: 166.667
2071                     Worst Case: 267.857
2072                     Average: 299.080
2073                     Score: 237.235
2074                     Wall time: 0:00.683
2075
2076         [1]: https://bugs.webkit.org/show_bug.cgi?id=201159
2077         [2]: https://bugs.webkit.org/show_bug.cgi?id=201160
2078         [3]: https://bugs.webkit.org/show_bug.cgi?id=201452
2079         [4]: https://bugs.webkit.org/show_bug.cgi?id=201158
2080
2081         * CMakeLists.txt:
2082         * JavaScriptCore.xcodeproj/project.pbxproj:
2083         * Scripts/wkbuiltins/builtins_generate_combined_header.py:
2084         (ConstructAbility):
2085         (ConstructorKind):
2086         * Scripts/wkbuiltins/builtins_generate_separate_header.py:
2087         * Scripts/wkbuiltins/builtins_generator.py:
2088         (BuiltinsGenerator.generate_embedded_code_data_for_function):
2089         (BuiltinsGenerator.generate_embedded_code_string_section_for_data):
2090         * Scripts/wkbuiltins/builtins_model.py:
2091         (BuiltinFunction.__init__):
2092         (BuiltinFunction.fromString):
2093         * Scripts/wkbuiltins/builtins_templates.py:
2094         * builtins/AsyncFromSyncIteratorPrototype.js:
2095         (next.try):
2096         (next):
2097         (return.try):
2098         (return):
2099         (throw.try):
2100         (throw):
2101         * builtins/AsyncFunctionPrototype.js:
2102         (globalPrivate.asyncFunctionResume):
2103         * builtins/AsyncGeneratorPrototype.js:
2104         (globalPrivate.asyncGeneratorQueueIsEmpty):
2105         (globalPrivate.asyncGeneratorQueueEnqueue):
2106         (globalPrivate.asyncGeneratorQueueDequeue):
2107         (globalPrivate.asyncGeneratorReject):
2108         (globalPrivate.asyncGeneratorResolve):
2109         (globalPrivate.asyncGeneratorYield):
2110         (onRejected):
2111         (globalPrivate.awaitValue):
2112         (onFulfilled):
2113         (globalPrivate.doAsyncGeneratorBodyCall):
2114         (globalPrivate.asyncGeneratorResumeNext):
2115         (globalPrivate.asyncGeneratorEnqueue):
2116         (globalPrivate.asyncGeneratorDequeue): Deleted.
2117         (const.onRejected): Deleted.
2118         (const.onFulfilled): Deleted.
2119         (globalPrivate.asyncGeneratorResumeNext.): Deleted.
2120         * builtins/BuiltinExecutableCreator.h:
2121         * builtins/BuiltinExecutables.cpp:
2122         (JSC::BuiltinExecutables::defaultConstructorSourceCode):
2123         (JSC::BuiltinExecutables::createDefaultConstructor):
2124         (JSC::BuiltinExecutables::createBuiltinExecutable):
2125         (JSC::BuiltinExecutables::createExecutable):
2126         (JSC::createBuiltinExecutable): Deleted.
2127         * builtins/BuiltinExecutables.h:
2128         * builtins/BuiltinNames.h:
2129         * builtins/BuiltinUtils.h:
2130         * builtins/ModuleLoader.js:
2131         (forceFulfillPromise):
2132         * builtins/PromiseConstructor.js:
2133         (nakedConstructor.Promise.resolve):
2134         (nakedConstructor.Promise.reject):
2135         (nakedConstructor.Promise):
2136         (nakedConstructor.InternalPromise.resolve):
2137         (nakedConstructor.InternalPromise.reject):
2138         (nakedConstructor.InternalPromise):
2139         * builtins/PromiseOperations.js:
2140         (globalPrivate.newPromiseReaction):
2141         (globalPrivate.newPromiseCapability):
2142         (globalPrivate.newHandledRejectedPromise):
2143         (globalPrivate.triggerPromiseReactions):
2144         (globalPrivate.resolvePromise):
2145         (globalPrivate.rejectPromise):
2146         (globalPrivate.fulfillPromise):
2147         (globalPrivate.resolvePromiseWithFirstResolvingFunctionCallCheck):
2148         (globalPrivate.rejectPromiseWithFirstResolvingFunctionCallCheck):
2149         (globalPrivate.createResolvingFunctions.resolve):
2150         (globalPrivate.createResolvingFunctions.reject):
2151         (globalPrivate.createResolvingFunctions):
2152         (globalPrivate.promiseReactionJobWithoutPromise):
2153         (globalPrivate.resolveWithoutPromise):
2154         (globalPrivate.rejectWithoutPromise):
2155         (globalPrivate.fulfillWithoutPromise):
2156         (resolve):
2157         (reject):
2158         (globalPrivate.createResolvingFunctionsWithoutPromise):
2159         (globalPrivate.promiseReactionJob):
2160         (globalPrivate.promiseResolveThenableJobFast):
2161         (globalPrivate.promiseResolveThenableJobWithoutPromiseFast):
2162         (globalPrivate.promiseResolveThenableJob):
2163         (globalPrivate.isPromise): Deleted.
2164         (globalPrivate.newPromiseCapability.executor): Deleted.
2165         (globalPrivate.initializePromise): Deleted.
2166         * builtins/PromisePrototype.js:
2167         (then):
2168         * bytecode/BytecodeIntrinsicRegistry.cpp:
2169         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2170         * bytecode/BytecodeIntrinsicRegistry.h:
2171         * bytecode/BytecodeList.rb:
2172         * bytecode/BytecodeUseDef.h:
2173         (JSC::computeUsesForBytecodeOffset):
2174         (JSC::computeDefsForBytecodeOffset):
2175         * bytecode/CodeBlock.cpp:
2176         (JSC::CodeBlock::finishCreation):
2177         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2178         * bytecode/Opcode.h:
2179         * bytecode/SpeculatedType.cpp:
2180         (JSC::dumpSpeculation):
2181         (JSC::speculationFromClassInfo):
2182         (JSC::speculationFromJSType):
2183         (JSC::speculationFromString):
2184         * bytecode/SpeculatedType.h:
2185         * bytecode/UnlinkedFunctionExecutable.h:
2186         * bytecompiler/BytecodeGenerator.cpp:
2187         (JSC::BytecodeGenerator::generate):
2188         (JSC::BytecodeGenerator::BytecodeGenerator):
2189         (JSC::BytecodeGenerator::emitGetPromiseInternalField):
2190         (JSC::BytecodeGenerator::emitPutPromiseInternalField):
2191         (JSC::BytecodeGenerator::emitCreatePromise):
2192         (JSC::BytecodeGenerator::emitNewPromise):
2193         (JSC::BytecodeGenerator::emitReturn):
2194         * bytecompiler/BytecodeGenerator.h:
2195         (JSC::BytecodeGenerator::promiseRegister):
2196         (JSC::BytecodeGenerator::emitIsPromise):
2197         (JSC::BytecodeGenerator::promiseCapabilityRegister): Deleted.
2198         * bytecompiler/NodesCodegen.cpp:
2199         (JSC::promiseInternalFieldIndex):
2200         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getPromiseInternalField):
2201         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putPromiseInternalField):
2202         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isPromise):
2203         (JSC::BytecodeIntrinsicNode::emit_intrinsic_createPromise):
2204         (JSC::BytecodeIntrinsicNode::emit_intrinsic_newPromise):
2205         (JSC::FunctionNode::emitBytecode):
2206         * dfg/DFGAbstractHeap.h:
2207         * dfg/DFGAbstractInterpreterInlines.h:
2208         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2209         * dfg/DFGByteCodeParser.cpp:
2210         (JSC::DFG::ByteCodeParser::parseBlock):
2211         * dfg/DFGCapabilities.cpp:
2212         (JSC::DFG::capabilityLevel):
2213         * dfg/DFGClobberize.h:
2214         (JSC::DFG::clobberize):
2215         * dfg/DFGClobbersExitState.cpp:
2216         (JSC::DFG::clobbersExitState):
2217         * dfg/DFGConstantFoldingPhase.cpp:
2218         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2219         * dfg/DFGDoesGC.cpp:
2220         (JSC::DFG::doesGC):
2221         * dfg/DFGFixupPhase.cpp:
2222         (JSC::DFG::FixupPhase::fixupNode):
2223         * dfg/DFGGraph.cpp:
2224         (JSC::DFG::Graph::dump):
2225         * dfg/DFGHeapLocation.cpp:
2226         (WTF::printInternal):
2227         * dfg/DFGHeapLocation.h:
2228         * dfg/DFGMayExit.cpp:
2229         * dfg/DFGNode.h:
2230         (JSC::DFG::Node::convertToNewPromise):
2231         (JSC::DFG::Node::hasIsInternalPromise):
2232         (JSC::DFG::Node::isInternalPromise):
2233         (JSC::DFG::Node::hasInternalFieldIndex):
2234         (JSC::DFG::Node::internalFieldIndex):
2235         (JSC::DFG::Node::hasHeapPrediction):
2236         (JSC::DFG::Node::hasStructure):
2237         * dfg/DFGNodeType.h:
2238         * dfg/DFGOperations.cpp:
2239         * dfg/DFGOperations.h:
2240         * dfg/DFGPredictionPropagationPhase.cpp:
2241         * dfg/DFGPromotedHeapLocation.cpp:
2242         (WTF::printInternal):
2243         * dfg/DFGPromotedHeapLocation.h:
2244         * dfg/DFGSafeToExecute.h:
2245         (JSC::DFG::SafeToExecuteEdge::operator()):
2246         (JSC::DFG::safeToExecute):
2247         * dfg/DFGSpeculativeJIT.cpp:
2248         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2249         (JSC::DFG::SpeculativeJIT::speculatePromiseObject):
2250         (JSC::DFG::SpeculativeJIT::speculate):
2251         (JSC::DFG::SpeculativeJIT::compileGetPromiseInternalField):
2252         (JSC::DFG::SpeculativeJIT::compilePutPromiseInternalField):
2253         (JSC::DFG::SpeculativeJIT::compileCreatePromise):
2254         (JSC::DFG::SpeculativeJIT::compileNewPromise):
2255         * dfg/DFGSpeculativeJIT.h:
2256         * dfg/DFGSpeculativeJIT32_64.cpp:
2257         (JSC::DFG::SpeculativeJIT::compile):
2258         * dfg/DFGSpeculativeJIT64.cpp:
2259         (JSC::DFG::SpeculativeJIT::compile):
2260         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2261         * dfg/DFGUseKind.cpp:
2262         (WTF::printInternal):
2263         * dfg/DFGUseKind.h:
2264         (JSC::DFG::typeFilterFor):
2265         (JSC::DFG::isCell):
2266         * ftl/FTLAbstractHeapRepository.h:
2267         * ftl/FTLCapabilities.cpp:
2268         (JSC::FTL::canCompile):
2269         * ftl/FTLLowerDFGToB3.cpp:
2270         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2271         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2272         (JSC::FTL::DFG::LowerDFGToB3::compileNewPromise):
2273         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
2274         (JSC::FTL::DFG::LowerDFGToB3::compileGetPromiseInternalField):
2275         (JSC::FTL::DFG::LowerDFGToB3::compilePutPromiseInternalField):
2276         (JSC::FTL::DFG::LowerDFGToB3::speculate):
2277         (JSC::FTL::DFG::LowerDFGToB3::speculatePromiseObject):
2278         * jit/JIT.cpp:
2279         (JSC::JIT::privateCompileMainPass):
2280         (JSC::JIT::privateCompileSlowCases):
2281         * jit/JIT.h:
2282         * jit/JITOperations.cpp:
2283         * jit/JITOperations.h:
2284         * jit/JITPropertyAccess.cpp:
2285         (JSC::JIT::emit_op_get_promise_internal_field):
2286         (JSC::JIT::emit_op_put_promise_internal_field):
2287         * jit/JITPropertyAccess32_64.cpp:
2288         (JSC::JIT::emit_op_get_promise_internal_field):
2289         (JSC::JIT::emit_op_put_promise_internal_field):
2290         * llint/LowLevelInterpreter.asm:
2291         * llint/LowLevelInterpreter32_64.asm:
2292         * llint/LowLevelInterpreter64.asm:
2293         * parser/Parser.cpp:
2294         (JSC::Parser<LexerType>::Parser):
2295         (JSC::Parser<LexerType>::parseFunctionInfo):
2296         * parser/Parser.h:
2297         (JSC::parse):
2298         * parser/ParserModes.h:
2299         * runtime/CommonSlowPaths.cpp:
2300         (JSC::SLOW_PATH_DECL):
2301         * runtime/CommonSlowPaths.h:
2302         * runtime/ConstructAbility.h:
2303         * runtime/ConstructorKind.h: Copied from Source/JavaScriptCore/runtime/ConstructAbility.h.
2304         * runtime/FunctionRareData.cpp:
2305         (JSC::FunctionRareData::FunctionRareData):
2306         (JSC::FunctionRareData::initializeObjectAllocationProfile):
2307         (JSC::FunctionRareData::clear):
2308         * runtime/FunctionRareData.h:
2309         * runtime/InternalFunction.cpp:
2310         (JSC::InternalFunction::createSubclassStructureSlow):
2311         * runtime/InternalFunction.h:
2312         (JSC::InternalFunction::createSubclassStructure):
2313         * runtime/JSCast.h:
2314         * runtime/JSGlobalObject.cpp:
2315         (JSC::enqueueJob):
2316         (JSC::JSGlobalObject::init):
2317         (JSC::JSGlobalObject::visitChildren):
2318         * runtime/JSGlobalObject.h:
2319         (JSC::JSGlobalObject::arrayProtoValuesFunction const):
2320         (JSC::JSGlobalObject::promiseProtoThenFunction const):
2321         (JSC::JSGlobalObject::initializePromiseFunction const): Deleted.
2322         * runtime/JSInternalPromise.cpp:
2323         (JSC::JSInternalPromise::createStructure):
2324         * runtime/JSInternalPromiseConstructor.cpp:
2325         (JSC::JSInternalPromiseConstructor::create):
2326         (JSC::JSInternalPromiseConstructor::createStructure):
2327         (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
2328         (JSC::constructPromise): Deleted.
2329         * runtime/JSInternalPromiseConstructor.h:
2330         * runtime/JSInternalPromisePrototype.cpp:
2331         (JSC::JSInternalPromisePrototype::create):
2332         * runtime/JSMicrotask.cpp:
2333         (JSC::createJSMicrotask):
2334         (JSC::JSMicrotask::run):
2335         * runtime/JSMicrotask.h:
2336         * runtime/JSPromise.cpp:
2337         (JSC::JSPromise::createStructure):
2338         (JSC::JSPromise::finishCreation):
2339         (JSC::JSPromise::visitChildren):
2340         (JSC::JSPromise::status const):
2341         (JSC::JSPromise::result const):
2342         (JSC::JSPromise::isHandled const):
2343         (JSC::JSPromise::initialize): Deleted.
2344         * runtime/JSPromise.h:
2345         (JSC::JSPromise::allocationSize):
2346         (JSC::JSPromise::offsetOfInternalFields):
2347         (JSC::JSPromise::offsetOfInternalField):
2348         * runtime/JSPromiseConstructor.cpp:
2349         (JSC::JSPromiseConstructor::create):
2350         (JSC::JSPromiseConstructor::createStructure):
2351         (JSC::JSPromiseConstructor::JSPromiseConstructor):
2352         (JSC::JSPromiseConstructor::finishCreation):
2353         (JSC::constructPromise): Deleted.
2354         (JSC::callPromise): Deleted.
2355         * runtime/JSPromiseConstructor.h:
2356         * runtime/JSPromisePrototype.cpp:
2357         (JSC::JSPromisePrototype::create):
2358         (JSC::JSPromisePrototype::finishCreation):
2359         (JSC::JSPromisePrototype::addOwnInternalSlots):
2360         * runtime/JSPromisePrototype.h:
2361         * runtime/JSType.cpp:
2362         (WTF::printInternal):
2363         * runtime/JSType.h:
2364
2365 2019-09-04  Joseph Pecoraro  <pecoraro@apple.com>
2366
2367         Web Inspector: Local Overrides - Provide substitution content for resource loads (URL based)
2368         https://bugs.webkit.org/show_bug.cgi?id=201262
2369         <rdar://problem/13108764>
2370
2371         Reviewed by Devin Rousso.
2372
2373         When interception is enabled, Network requests that match any of the configured
2374         interception patterns will be paused on the backend and allowed to be modified
2375         by the frontend.
2376
2377         Currently the only time a network request can be intercepted is during the
2378         HTTP response. However, this intercepting interface is mean to extend to
2379         HTTP requests as well.
2380
2381         When a response is to be intercepted a new event is sent to the frontend:
2382
2383           `Network.responseIntercepted` event
2384
2385         With a `requestId` to identify that network request. The frontend
2386         must respond with one of the following commands to continue:
2387
2388           `Network.interceptContinue`     - proceed with the response unmodified
2389           `Network.interceptWithResponse` - provide a response
2390
2391         The response is paused in the meantime.
2392
2393         * inspector/protocol/Network.json:
2394         New interfaces for intercepting network responses and suppling override content.
2395
2396         * Scripts/generate-combined-inspector-json.py:
2397         * inspector/scripts/generate-inspector-protocol-bindings.py:
2398         (generate_from_specification.load_specification):
2399         Complete allowing comments in JSON protocol files.
2400
2401         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
2402         (ObjCBackendDispatcherImplementationGenerator._generate_invocation_for_command):
2403         * inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
2404         Allow optional enums in ObjC interfaces.
2405
2406 2019-09-03  Mark Lam  <mark.lam@apple.com>
2407
2408         Structure::storedPrototype() and storedPrototypeObject() should assert with isCompilationThread(), not !isMainThread().
2409         https://bugs.webkit.org/show_bug.cgi?id=201449
2410
2411         Reviewed by Yusuke Suzuki.
2412
2413         Using !isMainThread() in the assertion also disables the assertion for the mutator
2414         of worker threads.  This is not what we intended.
2415
2416         * runtime/StructureInlines.h:
2417         (JSC::Structure::storedPrototype const):
2418         (JSC::Structure::storedPrototypeObject const):
2419
2420 2019-09-04  Mark Lam  <mark.lam@apple.com>
2421
2422         Disambiguate a symbol used in JSDollarVM.
2423         https://bugs.webkit.org/show_bug.cgi?id=201466
2424         <rdar://problem/51826672>
2425
2426         Reviewed by Tadeu Zagallo.
2427
2428         This was causing a build issue on some internal build.
2429
2430         * tools/JSDollarVM.cpp:
2431
2432 2019-09-03  Mark Lam  <mark.lam@apple.com>
2433
2434         Assertions in JSArrayBufferView::byteOffset() are only valid for the mutator thread.
2435         https://bugs.webkit.org/show_bug.cgi?id=201309
2436         <rdar://problem/54832121>
2437
2438         Reviewed by Yusuke Suzuki.
2439
2440         * dfg/DFGAbstractInterpreterInlines.h:
2441         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2442         * runtime/JSArrayBufferView.h:
2443         * runtime/JSArrayBufferViewInlines.h:
2444         (JSC::JSArrayBufferView::possiblySharedBufferImpl):
2445         (JSC::JSArrayBufferView::possiblySharedBuffer):
2446         (JSC::JSArrayBufferView::byteOffsetImpl):
2447         (JSC::JSArrayBufferView::byteOffset):
2448         (JSC::JSArrayBufferView::byteOffsetConcurrently):
2449
2450 2019-09-03  Devin Rousso  <drousso@apple.com>
2451
2452         Web Inspector: implement blackboxing of script resources
2453         https://bugs.webkit.org/show_bug.cgi?id=17240
2454         <rdar://problem/5732847>
2455
2456         Reviewed by Joseph Pecoraro.
2457
2458         When a script is blackboxed and the debugger attempts to pause in that script, the pause
2459         reason/data will be saved and execution will continue until it has left the blackboxed
2460         script. Once outside, execution is paused with the saved reason/data.
2461
2462         This is especially useful when debugging issues using libraries/frameworks, as it allows the
2463         developer to "skip" the internal logic of the library/framework and instead focus only on
2464         how they're using it.
2465
2466         * inspector/protocol/Debugger.json:
2467         Add `setShouldBlackboxURL` command.
2468
2469         * inspector/agents/InspectorDebuggerAgent.h:
2470         * inspector/agents/InspectorDebuggerAgent.cpp:
2471         (Inspector::InspectorDebuggerAgent):
2472         (Inspector::InspectorDebuggerAgent::enable):
2473         (Inspector::InspectorDebuggerAgent::updatePauseReasonAndData): Added.
2474         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
2475         (Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
2476         (Inspector::InspectorDebuggerAgent::setShouldBlackboxURL): Added.
2477         (Inspector::InspectorDebuggerAgent::setPauseForInternalScripts):
2478         (Inspector::InspectorDebuggerAgent::didParseSource):
2479         (Inspector::InspectorDebuggerAgent::didPause):
2480         (Inspector::InspectorDebuggerAgent::didContinue):
2481         (Inspector::InspectorDebuggerAgent::breakProgram):
2482         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
2483         (Inspector::InspectorDebuggerAgent::clearPauseDetails): Added.
2484         (Inspector::InspectorDebuggerAgent::clearBreakDetails): Deleted.
2485         Renamed "break" to "pause" to match `Debugger` naming.
2486
2487         * debugger/Debugger.h:
2488         * debugger/Debugger.cpp:
2489         (JSC::Debugger::pauseIfNeeded):
2490         (JSC::Debugger::setBlackboxType): Added.
2491         (JSC::Debugger::clearBlackbox): Added.
2492         (JSC::Debugger::isBlacklisted const): Deleted.
2493         (JSC::Debugger::addToBlacklist): Deleted.
2494         (JSC::Debugger::clearBlacklist): Deleted.
2495
2496 2019-09-03  Mark Lam  <mark.lam@apple.com>
2497
2498         Remove the need to pass performJITMemcpy as a pointer.
2499         https://bugs.webkit.org/show_bug.cgi?id=201413
2500
2501         Reviewed by Michael Saboff.
2502
2503         We want performJITMemcpy to always be inlined.  In this patch, we also clean up
2504         some template parameters to use enums instead of booleans to better document the
2505         intent of the code.
2506
2507         * assembler/ARM64Assembler.h:
2508         (JSC::ARM64Assembler::fillNops):
2509         (JSC::ARM64Assembler::linkJump):
2510         (JSC::ARM64Assembler::linkCall):
2511         (JSC::ARM64Assembler::relinkJump):
2512         (JSC::ARM64Assembler::relinkCall):
2513         (JSC::ARM64Assembler::link):
2514         (JSC::ARM64Assembler::linkJumpOrCall):
2515         (JSC::ARM64Assembler::linkCompareAndBranch):
2516         (JSC::ARM64Assembler::linkConditionalBranch):
2517         (JSC::ARM64Assembler::linkTestAndBranch):
2518         (JSC::ARM64Assembler::relinkJumpOrCall):
2519         (JSC::ARM64Assembler::CopyFunction::CopyFunction): Deleted.
2520         (JSC::ARM64Assembler::CopyFunction::operator()): Deleted.
2521         * assembler/ARMv7Assembler.h:
2522         (JSC::ARMv7Assembler::fillNops):
2523         (JSC::ARMv7Assembler::link):
2524         (JSC::ARMv7Assembler::linkJumpT1):
2525         (JSC::ARMv7Assembler::linkJumpT2):
2526         (JSC::ARMv7Assembler::linkJumpT3):
2527         (JSC::ARMv7Assembler::linkJumpT4):
2528         (JSC::ARMv7Assembler::linkConditionalJumpT4):
2529         (JSC::ARMv7Assembler::linkBX):
2530         (JSC::ARMv7Assembler::linkConditionalBX):
2531         * assembler/AbstractMacroAssembler.h:
2532         (JSC::AbstractMacroAssembler::emitNops):
2533         * assembler/LinkBuffer.cpp:
2534         (JSC::LinkBuffer::copyCompactAndLinkCode):
2535         * assembler/MIPSAssembler.h:
2536         (JSC::MIPSAssembler::fillNops):
2537         * assembler/MacroAssemblerARM64.h:
2538         (JSC::MacroAssemblerARM64::link):
2539         * assembler/MacroAssemblerARMv7.h:
2540         (JSC::MacroAssemblerARMv7::link):
2541         * assembler/X86Assembler.h:
2542         (JSC::X86Assembler::fillNops):
2543         * jit/ExecutableAllocator.h:
2544         (JSC::performJITMemcpy):
2545         * runtime/JSCPtrTag.h:
2546
2547 2019-09-03  Devin Rousso  <drousso@apple.com>
2548
2549         REGRESSION (r249078): Flaky crash in com.apple.JavaScriptCore: Inspector::InjectedScriptModule::ensureInjected
2550         https://bugs.webkit.org/show_bug.cgi?id=201201
2551         <rdar://problem/54771560>
2552
2553         Reviewed by Joseph Pecoraro.
2554
2555         * inspector/InjectedScriptSource.js:
2556         (let.InjectedScript.prototype.injectModule):
2557         (let.InjectedScript.prototype._evaluateOn):
2558         (CommandLineAPI):
2559         (let.InjectedScript.prototype.setInspectObject): Deleted.
2560         (let.InjectedScript.prototype.addCommandLineAPIGetter): Deleted.
2561         (let.InjectedScript.prototype.addCommandLineAPIMethod.func.toString): Deleted.
2562         (let.InjectedScript.prototype.addCommandLineAPIMethod): Deleted.
2563         (InjectedScript.CommandLineAPI): Deleted.
2564         Allow injected script "extensions" (e.g. CommandLineAPIModuleSource.js) to modify objects
2565         directly, instead of having them call functions.
2566
2567         * inspector/InjectedScriptModule.cpp:
2568         (Inspector::InjectedScriptModule::ensureInjected):
2569         Make sure to reset `hadException` to `false` before making another call.
2570
2571 2019-09-03  Yusuke Suzuki  <ysuzuki@apple.com>
2572
2573         [JSC] Remove BytecodeGenerator::emitPopScope
2574         https://bugs.webkit.org/show_bug.cgi?id=201395
2575
2576         Reviewed by Saam Barati.
2577
2578         Use emitGetParentScope. And this patch also removes several unnecessary mov bytecode emissions.
2579
2580         * bytecompiler/BytecodeGenerator.cpp:
2581         (JSC::BytecodeGenerator::popLexicalScopeInternal):
2582         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
2583         (JSC::BytecodeGenerator::emitPopWithScope):
2584         (JSC::BytecodeGenerator::emitPopScope): Deleted.
2585         * bytecompiler/BytecodeGenerator.h:
2586
2587 2019-09-01  Yusuke Suzuki  <ysuzuki@apple.com>
2588
2589         [JSC] Merge op_check_traps into op_enter and op_loop_hint
2590         https://bugs.webkit.org/show_bug.cgi?id=201373
2591
2592         Reviewed by Mark Lam.
2593
2594         This patch removes op_check_traps. Previously we were conditionally emitting op_check_traps based on Options and Platform configurations.
2595         But now we are always emitting op_check_traps. So it is not necessary to have separate bytecode as op_check_traps. We can do checking in
2596         op_enter and op_loop_hint.
2597
2598         While this patch moves check_traps implementation to op_enter and op_loop_hint, we keep separate DFG nodes (CheckTraps or InvalidationPoint),
2599         since inserted nodes are different based on configurations and options. And emitting multiple DFG nodes from one bytecode is easy.
2600
2601         We also inline op_enter's slow path's write-barrier emission in LLInt.
2602
2603         * bytecode/BytecodeList.rb:
2604         * bytecode/BytecodeUseDef.h:
2605         (JSC::computeUsesForBytecodeOffset):
2606         (JSC::computeDefsForBytecodeOffset):
2607         * bytecompiler/BytecodeGenerator.cpp:
2608         (JSC::BytecodeGenerator::BytecodeGenerator):
2609         (JSC::BytecodeGenerator::emitLoopHint):
2610         (JSC::BytecodeGenerator::emitCheckTraps): Deleted.
2611         * bytecompiler/BytecodeGenerator.h:
2612         * dfg/DFGByteCodeParser.cpp:
2613         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2614         (JSC::DFG::ByteCodeParser::parseBlock):
2615         * dfg/DFGCapabilities.cpp:
2616         (JSC::DFG::capabilityLevel):
2617         * jit/JIT.cpp:
2618         (JSC::JIT::privateCompileMainPass):
2619         (JSC::JIT::privateCompileSlowCases):
2620         (JSC::JIT::emitEnterOptimizationCheck): Deleted.
2621         * jit/JIT.h:
2622         * jit/JITOpcodes.cpp:
2623         (JSC::JIT::emit_op_loop_hint):
2624         (JSC::JIT::emitSlow_op_loop_hint):
2625         (JSC::JIT::emit_op_enter):
2626         (JSC::JIT::emitSlow_op_enter):
2627         (JSC::JIT::emit_op_check_traps): Deleted.
2628         (JSC::JIT::emitSlow_op_check_traps): Deleted.
2629         * jit/JITOpcodes32_64.cpp:
2630         (JSC::JIT::emit_op_enter): Deleted.
2631         * llint/LowLevelInterpreter.asm:
2632         * llint/LowLevelInterpreter32_64.asm:
2633         * llint/LowLevelInterpreter64.asm:
2634         * runtime/CommonSlowPaths.cpp:
2635         * runtime/CommonSlowPaths.h:
2636
2637 2019-09-01  Yusuke Suzuki  <ysuzuki@apple.com>
2638
2639         [JSC] Fix testb3 debug failures
2640         https://bugs.webkit.org/show_bug.cgi?id=201382
2641
2642         Reviewed by Mark Lam.
2643
2644         Fix testb3 debug failures due to incorrect types of operations like pointer + int32.
2645
2646         * b3/testb3_8.cpp:
2647         (testByteCopyLoop):
2648         (testByteCopyLoopStartIsLoopDependent):
2649         (testByteCopyLoopBoundIsLoopDependent):
2650
2651 2019-09-01  Mark Lam  <mark.lam@apple.com>
2652
2653         Speculative build fix for ARMv7 and MIPS.
2654         https://bugs.webkit.org/show_bug.cgi?id=201389
2655
2656         Not reviewed.
2657
2658         * bytecode/CodeBlock.cpp:
2659         (JSC::CodeBlock::jettison):
2660
2661 2019-08-30  Yusuke Suzuki  <ysuzuki@apple.com>
2662
2663         [JSC] LLInt op should not emit the same code three times
2664         https://bugs.webkit.org/show_bug.cgi?id=201370
2665
2666         Reviewed by Mark Lam.
2667
2668         LLInt op macro (not llintOp macro) is used to generate some stub code like llint_program_prologue.
2669         But now it generates the same code three times for narrow, wide16, and wide32. We should emit code only once.
2670
2671         * llint/LowLevelInterpreter.asm:
2672
2673 2019-08-30  Mark Lam  <mark.lam@apple.com>
2674
2675         Remove some obsolete statements that have no effect.
2676         https://bugs.webkit.org/show_bug.cgi?id=201357
2677
2678         Reviewed by Saam Barati.
2679
2680         This patch removes 3 statements that look like this:
2681
2682             result->butterfly(); // Ensure that the butterfly is in to-space.
2683
2684         The statement just reads a field and does nothing with it.  This is a no-op
2685         logic-wise, and the comment that accompanies it is obsolete.
2686
2687         * dfg/DFGOperations.cpp:
2688
2689 2019-08-30  Mark Lam  <mark.lam@apple.com>
2690
2691         Fix a bug in SlotVisitor::reportZappedCellAndCrash() and also capture more information.
2692         https://bugs.webkit.org/show_bug.cgi?id=201345
2693
2694         Reviewed by Yusuke Suzuki.
2695
2696         This patch fixes a bug where SlotVisitor::reportZappedCellAndCrash() was using
2697         the wrong pointer for capture the cell headerWord and zapReason.  As a result,
2698         we get junk for those 2 values.
2699
2700         Previously, we were only capturing the upper 32-bits of the cell header slot,
2701         and the lower 32-bit of the next slot in the zapped cell.  We now capture the
2702         full 64-bits of both slots.  If the second slot did not contain a zapReason as we
2703         expect, the upper 32-bits might give us a clue as to what type of value the slot
2704         contains.
2705
2706         This patch also adds capturing of the found MarkedBlock address for the zapped
2707         cell, as well as some state bit values.
2708
2709         * heap/SlotVisitor.cpp:
2710         (JSC::SlotVisitor::reportZappedCellAndCrash):
2711
2712 2019-08-30  Yusuke Suzuki  <ysuzuki@apple.com>
2713
2714         [JSC] Generate new.target register only when it is used
2715         https://bugs.webkit.org/show_bug.cgi?id=201335
2716
2717         Reviewed by Mark Lam.
2718
2719         Since bytecode generator knows whether new.target register can be used, we should emit and use new.target register
2720         only when it is actually required.
2721
2722         * bytecompiler/BytecodeGenerator.cpp:
2723         (JSC::BytecodeGenerator::BytecodeGenerator):
2724         * bytecompiler/BytecodeGenerator.h:
2725         (JSC::BytecodeGenerator::newTarget):
2726         * parser/Nodes.h:
2727         (JSC::ScopeNode::needsNewTargetRegisterForThisScope const):
2728
2729 2019-08-30  Yusuke Suzuki  <ysuzuki@apple.com>
2730
2731         [JSC] DFG ByteCodeParser should not copy JIT-related part of SimpleJumpTable
2732         https://bugs.webkit.org/show_bug.cgi?id=201331
2733
2734         Reviewed by Mark Lam.
2735
2736         SimpleJumpTable's non-JIT part is not changed after CodeBlock is finalized well. On the other hand, JIT related part is allocated on-demand.
2737         For example, ctiOffsets can be grown by Baseline JIT compiler. There is race condition as follows.
2738
2739             1. DFG ByteCodeParser is inlining and copying SimpleJumpTable
2740             2. Baseline JIT compiler is expanding JIT-related part of SimpleJumpTable
2741
2742         Then, (1) reads the broken Vector, and crashes. Since JIT-related part is unnecessary in (1), we should not clone that.
2743         This patch adds CodeBlock::addSwitchJumpTableFromProfiledCodeBlock, which only copies non JIT-related part of the given SimpleJumpTable offered
2744         by profiled CodeBlock.
2745
2746         * bytecode/CodeBlock.h:
2747         (JSC::CodeBlock::addSwitchJumpTableFromProfiledCodeBlock):
2748         * bytecode/JumpTable.h:
2749         (JSC::SimpleJumpTable::cloneNonJITPart const):
2750         (JSC::SimpleJumpTable::clear):
2751         * dfg/DFGByteCodeParser.cpp:
2752         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2753
2754 2019-08-30  Yusuke Suzuki  <ysuzuki@apple.com>
2755
2756         [JSC] DFG inlining CheckBadCell slow path does not assume result VirtualRegister can be invalid
2757         https://bugs.webkit.org/show_bug.cgi?id=201332
2758
2759         Reviewed by Mark Lam.
2760
2761         When inlining setter calls in DFG, result VirtualRegister becomes invalid one. While other call-related DFG code correctly assumes
2762         that `result` may be invalid, only CheckBadCell slow path missed this case. Since this is OSR exit path and VirtualRegister result
2763         does not exist, set BottomValue only when "result" is valid as the other DFG code is doing.
2764
2765         * dfg/DFGByteCodeParser.cpp:
2766         (JSC::DFG::ByteCodeParser::handleInlining):
2767
2768 2019-08-29  Devin Rousso  <drousso@apple.com>
2769
2770         Web Inspector: Debugger: async event listener stack traces should be available in Workers
2771         https://bugs.webkit.org/show_bug.cgi?id=200903
2772
2773         Reviewed by Joseph Pecoraro.
2774
2775         * inspector/agents/InspectorDebuggerAgent.h:
2776         (Inspector::InspectorDebuggerAgent::enabled): Added.
2777         * inspector/agents/InspectorDebuggerAgent.cpp:
2778         (Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
2779         (Inspector::InspectorDebuggerAgent::enable):
2780         (Inspector::InspectorDebuggerAgent::disable):
2781         Allow subclasses to extend what it means for the `InspectorDebuggerAgent` to be `enabled`.
2782
2783 2019-08-29  Keith Rollin  <krollin@apple.com>
2784
2785         Update .xcconfig symbols to reflect the current set of past and future product versions.
2786         https://bugs.webkit.org/show_bug.cgi?id=200720
2787         <rdar://problem/54305032>
2788
2789         Reviewed by Alex Christensen.
2790
2791         Remove version symbols related to old OS's we no longer support,
2792         ensure that version symbols are defined for OS's we do support.
2793
2794         * Configurations/Base.xcconfig:
2795         * Configurations/DebugRelease.xcconfig:
2796         * Configurations/Version.xcconfig:
2797
2798 2019-08-29  Yusuke Suzuki  <ysuzuki@apple.com>
2799
2800         [JSC] Repatch should construct CallCases and CasesValue at the same time
2801         https://bugs.webkit.org/show_bug.cgi?id=201325
2802
2803         Reviewed by Saam Barati.
2804
2805         In linkPolymorphicCall, we should create callCases and casesValue at the same time to assert `callCases.size() == casesValue.size()`.
2806         If the call variant is isClosureCall and InternalFunction, we skip adding it to casesValue. So we should not add this variant to callCases too.
2807
2808         * jit/Repatch.cpp:
2809         (JSC::linkPolymorphicCall):
2810
2811 2019-08-29  Yusuke Suzuki  <ysuzuki@apple.com>
2812
2813         [JSC] ObjectAllocationSinkingPhase wrongly deals with always-taken branches during interpretation
2814         https://bugs.webkit.org/show_bug.cgi?id=198650
2815
2816         Reviewed by Saam Barati.
2817
2818         Object Allocation Sinking phase has a lightweight abstract interpreter which interprets DFG nodes related to allocations and properties.
2819         This interpreter is lightweight since it does not track abstract values and conditions as deeply as AI does. It can happen that this
2820         interpreter interpret the control-flow edge that AI proved that is never taken.
2821         AI already knows some control-flow edges are never taken, and based on this information, AI can remove CheckStructure nodes. But
2822         ObjectAllocationSinking phase can trace this never-taken edges and propagate structure information that contradicts to the analysis
2823         done in ObjectAllocationSinking.
2824
2825         Let's see the example.
2826
2827             BB#0
2828                 35: NewObject([%AM:Object])
2829                 ...
2830                 47: Branch(ConstantTrue, T:#1, F:#2)
2831
2832             BB#1 // This basic block is never taken due to @47's jump.
2833                 ...
2834                 71: PutByOffset(@35, @66, id2{a}, 0, W:NamedProperties(2))
2835                 72: PutStructure(@35, %AM:Object -> %Dx:Object, ID:60066)
2836                 ...
2837                 XX: Jump(#2)
2838
2839             BB#2
2840                 ...
2841                 92: CheckStructure(@35, [%Dx:Object])
2842                 93: PutByOffset(@35, @35, id2{a}, 0, W:NamedProperties(2))
2843                 ...
2844
2845         AI removes @92 because AI knows BB#0 only takes BB#1 branch. @35's Structure is always %Dx so @92 is redundant.
2846         AI proved that @71 and @72 are always executed while BB#0 -> BB#2 edge is never taken so that @35 object's structure is proven at @92.
2847         After AI removes @92, ObjectAllocationSinking starts looking into this graph.
2848
2849             BB#0
2850                 35: NewObject([%AM:Object])
2851                 ...
2852                 47: Branch(ConstantTrue, T:#1, F:#2)
2853
2854             BB#1 // This basic block is never taken due to @47's jump.
2855                 ...
2856                 71: PutByOffset(@35, @66, id2{a}, 0, W:NamedProperties(2))
2857                 72: PutStructure(@35, %AM:Object -> %Dx:Object, ID:60066)
2858                 ...
2859                 XX: Jump(#2)
2860
2861             BB#2
2862                 ...
2863                 93: PutByOffset(@35, @35, id2{a}, 0, W:NamedProperties(2))
2864                 ...
2865                 YY: Jump(#3)
2866
2867             BB#3
2868                 ...
2869                 ZZ: <HERE> want to materialize @35's sunk object.
2870
2871         Since AI does not change the @47 Branch to Jump (it is OK anyway), BB#0 -> BB#2 edge remains and ObjectAllocationSinking phase propagates information in
2872         BB#0's %AM structure information to BB#2. ObjectAllocationSinking phase converts @35 to PhantomNewObject, removes PutByOffset and PutStructure, and
2873         insert MaterializeNewObject in @ZZ. At this point, ObjectAllocationSinking lightweight interpreter gets two structures while AI gets one: @35's original
2874         one (%AM) and @72's replaced one (%Dx). Since AI already proved @ZZ only gets %Dx, AI removed @92 CheckStructure. But this is not known to ObjectAllocationSinking
2875         phase's interpretation. So when creating recovery data, MultiPutByOffset includes two structures, %AM and %Dx. This is OK since MultiPutByOffset takes
2876         conservative set of structures and performs switching. But the problem here is that %AM's id2{a} offset is -1 since %AM does not have such a property.
2877         So when creating MultiPutByOffset in ObjectAllocationSinking, we accidentally create MultiPutByOffset with -1 offset data, and lowering phase hits the debug
2878         assertion.
2879
2880             187: MultiPutByOffset(@138, @138, id2{a}, <Replace: [%AM:Object], offset = -1, >, <Replace: [%Dx:Object], offset = 0, >)
2881
2882         This bug is harmless since %AM structure comparison never meets at runtime. But we are not considering the case including `-1` offset property in MultiPutByOffset data.
2883         In this patch, we just filter out apparently wrong structures when creating MultiPutByOffset in ObjectAllocationSinking. This is OK since it never comes at runtime.
2884
2885         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2886
2887 2019-08-29  Devin Rousso  <drousso@apple.com>
2888
2889         Web Inspector: DOMDebugger: support event breakpoints in Worker contexts
2890         https://bugs.webkit.org/show_bug.cgi?id=200651
2891
2892         Reviewed by Joseph Pecoraro.
2893
2894         * inspector/protocol/DOMDebugger.json:
2895         Make the domain available in "worker" contexts as well.
2896
2897 2019-08-29  Keith Rollin  <krollin@apple.com>
2898
2899         Remove 32-bit macOS support
2900         https://bugs.webkit.org/show_bug.cgi?id=201282
2901         <rdar://problem/54821667>
2902
2903         Reviewed by Anders Carlsson.
2904
2905         WebKit doesn’t support 32-bit Mac any more, so remove checks and code
2906         for that platform.
2907
2908         * API/JSBase.h:
2909         * runtime/VM.h:
2910
2911 2019-08-29  Keith Rollin  <krollin@apple.com>
2912
2913         Remove support for macOS < 10.13 (part 3)
2914         https://bugs.webkit.org/show_bug.cgi?id=201224
2915         <rdar://problem/54795934>
2916
2917         Reviewed by Darin Adler.
2918
2919         Remove symbols in WebKitTargetConditionals.xcconfig related to macOS
2920         10.13, including WK_MACOS_1013 and WK_MACOS_BEFORE_1013, and suffixes
2921         like _MACOS_SINCE_1013.
2922
2923         * Configurations/WebKitTargetConditionals.xcconfig:
2924
2925 2019-08-29  Mark Lam  <mark.lam@apple.com>
2926
2927         Remove a bad assertion in ByteCodeParser::inlineCall().
2928         https://bugs.webkit.org/show_bug.cgi?id=201292
2929         <rdar://problem/54121659>
2930
2931         Reviewed by Michael Saboff.
2932
2933         In the DFG bytecode parser, we've already computed the inlining cost of a candidate
2934         inlining target, and determine that it is worth inlining before invoking
2935         ByteCodeParser::inlineCall().  However, in ByteCodeParser::inlineCall(), it
2936         recomputes the inlining cost again only for the purpose of asserting that it isn't
2937         too high.
2938
2939         Not consider a badly written test that does the following:
2940
2941             function bar() {
2942                 ...
2943                 foo(); // Call in a hot loop here.
2944                 ...
2945             }
2946
2947             bar(); // <===== foo is inlineable into bar here.
2948             noInline(foo); // <===== Change mind, and make foo not inlineable.
2949             bar();
2950
2951         With this bad test, the following racy scenario can occur:
2952
2953         1. the first invocation of bar() gets hot, and a concurrent compile is kicked off.
2954         2. the compiler thread computes foo()'s inliningCost() and determines that it is
2955            worthy to be inlined, and will imminently call inlineCall().
2956         3. the mutator calls the noInline() test utility on foo(), thereby making it NOT
2957            inlineable.
2958         4. the compiler thread calls inlineCall().  In inlineCall(), it re-computes the
2959            inliningCost for foo() and now finds that it is not inlineable.  An assertion
2960            failure follows.
2961
2962         Technically, the test is in error because noInline() shouldn't be used that way.
2963         However, fuzzers that are not clued into noInline()'s proper usage may generate
2964         code like this.
2965
2966         On the other hand, ByteCodeParser::inlineCall() should not be recomputing that the
2967         inlining cost and asserting on it.  The only reason inlineCall() is invoked is
2968         because it was already previously determined that a target function is inlineable
2969         based on its inlining cost.  Today, in practice, I don't think we have any real
2970         world condition where the mutator can affect the inlining cost of a target
2971         function midway through execution.  So, this assertion isn't a problem if no one
2972         writes a test that abuses noInline().  However, should things change such that the
2973         mutator is able to affect the inlining cost of a target function, then it is
2974         incorrect for the compiler to assume that the inlining cost is immutable.  Once
2975         the compiler decides to inline a function, it should just follow through.
2976
2977         This patch removes this assertion in ByteCodeParser::inlineCall().  It is an
2978         annoyance at best (for fuzzers), and at worst, incorrect if the mutator gains the
2979         ability to affect the inlining cost of a target function.
2980
2981         * dfg/DFGByteCodeParser.cpp:
2982         (JSC::DFG::ByteCodeParser::inlineCall):
2983
2984 2019-08-28  Mark Lam  <mark.lam@apple.com>
2985
2986         DFG/FTL: We should prefetch structures and do a loadLoadFence before doing PrototypeChainIsSane checks.
2987         https://bugs.webkit.org/show_bug.cgi?id=201281
2988         <rdar://problem/54028228>
2989
2990         Reviewed by Yusuke Suzuki and Saam Barati.
2991
2992         This (see title above) is already the preferred idiom used in most places in our
2993         compiler, except for 2: DFG's SpeculativeJIT::compileGetByValOnString() and FTL's
2994         compileStringCharAt().  Consider the following:
2995
2996             bool prototypeChainIsSane = false;
2997             if (globalObject->stringPrototypeChainIsSane()) {
2998                 ...
2999                 m_graph.registerAndWatchStructureTransition(globalObject->stringPrototype()->structure(vm()));
3000                 m_graph.registerAndWatchStructureTransition(globalObject->objectPrototype()->structure(vm()));
3001
3002                 prototypeChainIsSane = globalObject->stringPrototypeChainIsSane();
3003             }
3004
3005         What's essential for correctness here is that the stringPrototype and objectPrototype
3006         structures be loaded before the loads in the second stringPrototypeChainIsSane()
3007         check.  Without a loadLoadFence before the second stringPrototypeChainIsSane()
3008         check, we can't guarantee that.  Elsewhere in the compiler, the preferred idiom
3009         for doing this right is to pre-load the structures first, do a loadLoadFence, and
3010         then do the IsSane check just once after e.g.
3011
3012             Structure* arrayPrototypeStructure = globalObject->arrayPrototype()->structure(m_vm);
3013             Structure* objectPrototypeStructure = globalObject->objectPrototype()->structure(m_vm);
3014
3015             if (arrayPrototypeStructure->transitionWatchpointSetIsStillValid() // has loadLoadFences.
3016                 && objectPrototypeStructure->transitionWatchpointSetIsStillValid() // has loadLoadFences.
3017                 && globalObject->arrayPrototypeChainIsSane()) {
3018
3019                 m_graph.registerAndWatchStructureTransition(arrayPrototypeStructure);
3020                 m_graph.registerAndWatchStructureTransition(objectPrototypeStructure);
3021                 ...
3022             }
3023
3024         This patch changes DFG's SpeculativeJIT::compileGetByValOnString() and FTL's
3025         compileStringCharAt() to follow the same idiom.
3026
3027         We also fix a bad assertion in Structure::storedPrototype() and
3028         Structure::storedPrototypeObject().  The assertion is only correct when those
3029         methods are called from the mutator thread.  The assertion has been updated to
3030         only check its test condition if the current thread is the mutator thread.
3031
3032         * dfg/DFGSpeculativeJIT.cpp:
3033         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
3034         * ftl/FTLLowerDFGToB3.cpp:
3035         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
3036         * runtime/StructureInlines.h:
3037         (JSC::Structure::storedPrototype const):
3038         (JSC::Structure::storedPrototypeObject const):
3039
3040 2019-08-28  Mark Lam  <mark.lam@apple.com>
3041
3042         Placate exception check validation in DFG's operationHasGenericProperty().
3043         https://bugs.webkit.org/show_bug.cgi?id=201245
3044         <rdar://problem/54777512>
3045
3046         Reviewed by Robin Morisset.
3047
3048         * dfg/DFGOperations.cpp:
3049
3050 2019-08-28  Ross Kirsling  <ross.kirsling@sony.com>
3051
3052         Unreviewed. Restabilize non-unified build.
3053
3054         * runtime/PropertySlot.h:
3055
3056 2019-08-28  Mark Lam  <mark.lam@apple.com>
3057
3058         Wasm's AirIRGenerator::addLocal() and B3IRGenerator::addLocal() are doing unnecessary overflow checks.
3059         https://bugs.webkit.org/show_bug.cgi?id=201006
3060         <rdar://problem/52053991>
3061
3062         Reviewed by Yusuke Suzuki.
3063
3064         We already ensured that it is not possible to overflow in Wasm::FunctionParser's
3065         parse().  It is unnecessary and misleading to do those overflow checks in
3066         AirIRGenerator and B3IRGenerator.  The only check that is necessary is that
3067         m_locals.tryReserveCapacity() is successful, otherwise, we have an out of memory
3068         situation.
3069
3070         This patch changes these unnecessary checks to assertions instead.
3071
3072         * wasm/WasmAirIRGenerator.cpp:
3073         (JSC::Wasm::AirIRGenerator::addLocal):
3074         * wasm/WasmB3IRGenerator.cpp:
3075         (JSC::Wasm::B3IRGenerator::addLocal):
3076         * wasm/WasmValidate.cpp:
3077         (JSC::Wasm::Validate::addLocal):
3078
3079 2019-08-28  Keith Rollin  <krollin@apple.com>
3080
3081         Remove support for macOS < 10.13 (part 2)
3082         https://bugs.webkit.org/show_bug.cgi?id=201197
3083         <rdar://problem/54759985>
3084
3085         Update conditionals that reference WK_MACOS_1013 and suffixes like
3086         _MACOS_SINCE_1013, assuming that we're always building on 10.13 or
3087         later and that these conditionals are always True or False.
3088
3089         See Bug 200694 for earlier changes in this area.
3090
3091         Reviewed by Darin Adler.
3092
3093         * Configurations/FeatureDefines.xcconfig:
3094
3095 2019-08-28  Mark Lam  <mark.lam@apple.com>
3096
3097         Gardening: Rebase test results after r249175.
3098         https://bugs.webkit.org/show_bug.cgi?id=201172
3099
3100         Not reviewed.
3101
3102         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
3103         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
3104         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
3105         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3106         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
3107         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
3108         * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
3109
3110 2019-08-27  Michael Saboff  <msaboff@apple.com>
3111
3112         Update PACCage changes for builds without Gigacage, but with signed pointers
3113         https://bugs.webkit.org/show_bug.cgi?id=201202
3114
3115         Reviewed by Saam Barati.
3116
3117         Factored out the untagging of pointers and added that to both the Gigacage enabled
3118         and disabled code paths.  Did this for the LLInt as well as the JITs.
3119
3120         * JavaScriptCore.xcodeproj/project.pbxproj: Added arm64e.rb to offlineasm file list.
3121         * dfg/DFGSpeculativeJIT.cpp:
3122         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
3123         * ftl/FTLLowerDFGToB3.cpp:
3124         (JSC::FTL::DFG::LowerDFGToB3::caged):
3125         * llint/LowLevelInterpreter64.asm:
3126
3127 2019-08-27  Mark Lam  <mark.lam@apple.com>
3128
3129         Refactor to use VM& instead of VM* at as many places as possible.
3130         https://bugs.webkit.org/show_bug.cgi?id=201172
3131
3132         Reviewed by Yusuke Suzuki.
3133
3134         Using VM& documents more clearly that the VM pointer is expected to never be null
3135         in most cases.  There are a few places where it can be null (e.g JSLock, and
3136         DFG::Plan).  Those will be left using a VM*.
3137
3138         Also converted some uses of ExecState* to using VM& instead since the ExecState*
3139         is only there to fetch the VM pointer.  Doing this also reduces the number of
3140         times we have to compute VM* from ExecState*.
3141
3142         This patch is not exhaustive in converting to use VM&, but applies the change to
3143         many commonly used pieces of code for a start.
3144
3145         Also fixed a missing exception check in JSString::toIdentifier() and
3146         JSValue::toPropertyKey() exposed by this patch.
3147
3148         * API/APICast.h:
3149         (toJS):
3150         * API/JSAPIGlobalObject.mm:
3151         (JSC::JSAPIGlobalObject::moduleLoaderResolve):
3152         (JSC::JSAPIGlobalObject::moduleLoaderImportModule):
3153         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
3154         (JSC::JSAPIGlobalObject::moduleLoaderCreateImportMetaProperties):
3155         (JSC::JSAPIGlobalObject::loadAndEvaluateJSScriptModule):
3156         * API/JSCallbackConstructor.cpp:
3157         (JSC::JSCallbackConstructor::finishCreation):
3158         * API/JSCallbackObjectFunctions.h:
3159         (JSC::JSCallbackObject<Parent>::asCallbackObject):
3160         (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
3161         (JSC::JSCallbackObject<Parent>::getOwnPropertySlotByIndex):
3162         (JSC::JSCallbackObject<Parent>::putByIndex):
3163         (JSC::JSCallbackObject<Parent>::deletePropertyByIndex):
3164         (JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
3165         * API/JSContext.mm:
3166         (-[JSContext dependencyIdentifiersForModuleJSScript:]):
3167         * API/JSObjectRef.cpp:
3168         (JSObjectMakeFunction):
3169         (classInfoPrivate):
3170         (JSObjectGetPrivate):
3171         (JSObjectSetPrivate):
3172         (JSObjectCopyPropertyNames):
3173         (JSPropertyNameAccumulatorAddName):
3174         (JSObjectGetProxyTarget):
3175         * API/JSScriptRef.cpp:
3176         (parseScript):
3177         * API/JSValueRef.cpp:
3178         (JSValueMakeString):
3179         * API/OpaqueJSString.cpp:
3180         (OpaqueJSString::identifier const):
3181         * API/glib/JSCContext.cpp:
3182         (jsc_context_check_syntax):
3183         * KeywordLookupGenerator.py:
3184         (Trie.printSubTreeAsC):
3185         * Scripts/wkbuiltins/builtins_generate_wrapper_header.py:
3186         (BuiltinsWrapperHeaderGenerator.generate_constructor):
3187         * Scripts/wkbuiltins/builtins_templates.py:
3188         * bindings/ScriptFunctionCall.cpp:
3189         (Deprecated::ScriptCallArgumentHandler::appendArgument):
3190         (Deprecated::ScriptFunctionCall::call):
3191         * bindings/ScriptValue.cpp:
3192         (Inspector::jsToInspectorValue):
3193         * builtins/BuiltinExecutables.cpp:
3194         (JSC::BuiltinExecutables::createExecutable):
3195         * builtins/BuiltinNames.cpp:
3196         (JSC::BuiltinNames::BuiltinNames):
3197         * builtins/BuiltinNames.h:
3198         (JSC::BuiltinNames::getPublicName const):
3199         * bytecode/BytecodeDumper.cpp:
3200         (JSC::BytecodeDumper<Block>::vm const):
3201         * bytecode/BytecodeDumper.h:
3202         * bytecode/BytecodeGeneratorification.cpp:
3203         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
3204         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
3205         (JSC::BytecodeGeneratorification::run):
3206         * bytecode/BytecodeIntrinsicRegistry.cpp:
3207         (JSC::BytecodeIntrinsicRegistry::sentinelMapBucketValue):
3208         (JSC::BytecodeIntrinsicRegistry::sentinelSetBucketValue):
3209         * bytecode/CallVariant.h:
3210         (JSC::CallVariant::internalFunction const):
3211         (JSC::CallVariant::function const):
3212         (JSC::CallVariant::isClosureCall const):
3213         (JSC::CallVariant::executable const):
3214         (JSC::CallVariant::functionExecutable const):
3215         (JSC::CallVariant::nativeExecutable const):
3216         * bytecode/CodeBlock.cpp:
3217         (JSC::CodeBlock::dumpSource):
3218         (JSC::CodeBlock::CodeBlock):
3219         (JSC::CodeBlock::setConstantIdentifierSetRegisters):
3220         (JSC::CodeBlock::setNumParameters):
3221         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
3222         (JSC::CodeBlock::unlinkIncomingCalls):
3223         (JSC::CodeBlock::replacement):
3224         (JSC::CodeBlock::computeCapabilityLevel):
3225         (JSC::CodeBlock::noticeIncomingCall):
3226         (JSC::CodeBlock::nameForRegister):
3227         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
3228         * bytecode/CodeBlock.h:
3229         (JSC::CodeBlock::vm const):
3230         (JSC::CodeBlock::numberOfArgumentValueProfiles):
3231         (JSC::CodeBlock::valueProfileForArgument):
3232         * bytecode/DeferredSourceDump.cpp:
3233         (JSC::DeferredSourceDump::DeferredSourceDump):
3234         * bytecode/EvalCodeBlock.h:
3235         * bytecode/FunctionCodeBlock.h:
3236         * bytecode/GetByIdStatus.cpp:
3237         (JSC::GetByIdStatus::computeFromLLInt):
3238         * bytecode/GlobalCodeBlock.h:
3239         (JSC::GlobalCodeBlock::GlobalCodeBlock):
3240         * bytecode/ModuleProgramCodeBlock.h:
3241         * bytecode/ObjectAllocationProfileInlines.h:
3242         (JSC::ObjectAllocationProfileBase<Derived>::possibleDefaultPropertyCount):
3243         * bytecode/PolyProtoAccessChain.cpp:
3244         (JSC::PolyProtoAccessChain::create):
3245         * bytecode/ProgramCodeBlock.h:
3246         * bytecode/PropertyCondition.cpp:
3247         (JSC::PropertyCondition::isWatchableWhenValid const):
3248         * bytecode/PutByIdStatus.cpp:
3249         (JSC::PutByIdStatus::computeFromLLInt):
3250         * bytecode/StructureStubInfo.cpp:
3251         (JSC::StructureStubInfo::initGetByIdSelf):
3252         (JSC::StructureStubInfo::initPutByIdReplace):
3253         (JSC::StructureStubInfo::initInByIdSelf):
3254         (JSC::StructureStubInfo::addAccessCase):
3255         (JSC::StructureStubInfo::visitWeakReferences):
3256         * bytecode/UnlinkedCodeBlock.cpp:
3257         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3258         * bytecode/UnlinkedCodeBlock.h:
3259         (JSC::UnlinkedCodeBlock::addSetConstant):
3260         (JSC::UnlinkedCodeBlock::addConstant):
3261         (JSC::UnlinkedCodeBlock::addFunctionDecl):
3262         (JSC::UnlinkedCodeBlock::addFunctionExpr):
3263         * bytecode/UnlinkedEvalCodeBlock.h:
3264         * bytecode/UnlinkedFunctionCodeBlock.h:
3265         * bytecode/UnlinkedFunctionExecutable.cpp:
3266         (JSC::generateUnlinkedFunctionCodeBlock):
3267         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3268         * bytecode/UnlinkedFunctionExecutable.h:
3269         * bytecode/UnlinkedGlobalCodeBlock.h:
3270         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
3271         * bytecode/UnlinkedModuleProgramCodeBlock.h:
3272         * bytecode/UnlinkedProgramCodeBlock.h:
3273         * bytecompiler/BytecodeGenerator.cpp:
3274         (JSC::BytecodeGenerator::BytecodeGenerator):
3275         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
3276         (JSC::BytecodeGenerator::emitDirectPutById):
3277         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
3278         (JSC::BytecodeGenerator::addBigIntConstant):
3279         (JSC::BytecodeGenerator::addTemplateObjectConstant):
3280         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
3281         (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
3282         * bytecompiler/BytecodeGenerator.h:
3283         (JSC::BytecodeGenerator::vm const):
3284         (JSC::BytecodeGenerator::propertyNames const):
3285         (JSC::BytecodeGenerator::emitNodeInTailPosition):
3286         (JSC::BytecodeGenerator::emitDefineClassElements):
3287         (JSC::BytecodeGenerator::emitNodeInConditionContext):
3288        &n