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