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