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