5759efa4e1b0a974bf79e4bc9bb78af867d4625d
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-09-20  Paulo Matos  <pmatos@igalia.com>
2
3         Implement memory monitoring functions for Linux OS
4         https://bugs.webkit.org/show_bug.cgi?id=200391
5
6         Reviewed by Žan Doberšek.
7
8         * jsc.cpp:
9
10 2019-09-20  Devin Rousso  <drousso@apple.com>
11
12         ASSERT NOT REACHED in Inspector::InjectedScriptModule::ensureInjected() seen with inspector/heap/getRemoteObject.html
13         https://bugs.webkit.org/show_bug.cgi?id=201713
14         <rdar://problem/55290349>
15
16         Reviewed by Joseph Pecoraro.
17
18         Expose the `Exception` object by leveraging an `Expected` of `JSValue` as the return value
19         instead of using a referenced `bool` (which wouldn't include any of the exception's info).
20
21         * bindings/ScriptFunctionCall.h:
22         * bindings/ScriptFunctionCall.cpp:
23         (Deprecated::ScriptFunctionCall::call):
24
25         * inspector/InjectedScript.cpp:
26         (Inspector::InjectedScript::wrapCallFrames const):
27         (Inspector::InjectedScript::wrapObject const):
28         (Inspector::InjectedScript::wrapJSONString const):
29         (Inspector::InjectedScript::wrapTable const):
30         (Inspector::InjectedScript::previewValue const):
31         (Inspector::InjectedScript::findObjectById const):
32         (Inspector::InjectedScript::releaseObjectGroup):
33
34         * inspector/InjectedScriptBase.h:
35         * inspector/InjectedScriptBase.cpp:
36         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled const):
37         (Inspector::InjectedScriptBase::makeCall):
38         (Inspector::InjectedScriptBase::makeAsyncCall):
39
40         * inspector/InjectedScriptManager.h:
41         * inspector/InjectedScriptManager.cpp:
42         (Inspector::InjectedScriptManager::createInjectedScript):
43         (Inspector::InjectedScriptManager::injectedScriptFor):
44
45         * inspector/InjectedScriptModule.cpp:
46         (Inspector::InjectedScriptModule::ensureInjected):
47
48 2019-09-19  Yusuke Suzuki  <ysuzuki@apple.com>
49
50         [JSC] DFG op_call_varargs should not assume that one-previous-local of freeReg is usable
51         https://bugs.webkit.org/show_bug.cgi?id=202014
52
53         Reviewed by Saam Barati.
54
55         Let's look into the bytecode generated by the test.
56
57             [   0] enter
58             [   1] get_scope          loc4
59             [   3] mov                loc5, loc4
60             [   6] check_traps
61             [   7] mov                loc6, callee
62             [  10] create_direct_arguments loc7
63             [  12] to_this            this
64             [  15] mov                loc8, loc7
65             [  18] mov                loc9, loc6
66             [  21] mov                loc12, Undefined(const0)
67             [  24] get_by_id          loc11, loc6, 0
68             [  29] jneq_ptr           loc11, ApplyFunction, 18(->47)
69             [  34] mov                loc11, loc6
70             [  37] call_varargs       loc11, loc11, this, loc8, loc13, 0
71             [  45] jmp                17(->62)
72             [  47] mov                loc16, loc6
73             [  50] mov                loc15, this
74             [  53] mov                loc14, loc8
75             [  56] call               loc11, loc11, 3, 22
76             ...
77
78         call_varargs uses loc13 as firstFreeReg (first usable bottom register in the current stack-frame to spread variadic arguments after this).
79         This is correct. And call_varargs uses |this| as this argument for the call_varargs. This |this| argument is not in a region starting from loc13.
80         And it is not in the previous place to loc13 (|this| is not loc12).
81
82         On the other hand, DFG::ByteCodeParser's inlining path is always assuming that the previous to firstFreeReg is usable and part of arguments.
83         But this is wrong. loc12 in the above bytecode is used for `[  56] call               loc11, loc11, 3, 22`'s argument later, and this call assumes
84         that loc12 is not clobbered by call_varargs. But DFG and FTL clobbers it.
85
86         The test is recursively calling the same function, and we inline the same function one-level. And stack-overflow error happens when inlined
87         CallForwardVarargs (from op_call_varargs) is called. FTL recovers the frames, and at this point, outer function's loc12 is recovered to garbage since
88         LoadVarargs clobbers it. And we eventually use it and crash.
89
90             60:<!0:-> LoadVarargs(Check:Untyped:Kill:@30, MustGen, start = loc13, count = loc15, machineStart = loc7, machineCount = loc9, offset = 0, mandatoryMinimum = 0, limit = 2, R:World, W:Stack(-16),Stack(-14),Stack(-13),Heap, Exits, ClobbersExit, bc#37, ExitValid)
91
92         This LoadVarargs clobbers loc12, loc13, and loc15 while loc12 is used.
93
94         In all the tiers, op_call_varargs first allocates enough region to hold varargs including |this|. And we store |this| value to a correct place.
95         DFG should not assume that the previous register to firstFreeReg is used for |this|.
96
97         This patch fixes DFG::ByteCodeParser's stack region calculation for op_call_varargs inlining. And we rename maxNumArguments to maxArgumentCountIncludingThis to
98         represent that `maxArgumentCountIncludingThis` includes |this| count.
99
100         * bytecode/CallLinkInfo.cpp:
101         (JSC::CallLinkInfo::setMaxArgumentCountIncludingThis):
102         (JSC::CallLinkInfo::setMaxNumArguments): Deleted.
103         * bytecode/CallLinkInfo.h:
104         (JSC::CallLinkInfo::addressOfMaxArgumentCountIncludingThis):
105         (JSC::CallLinkInfo::maxArgumentCountIncludingThis):
106         (JSC::CallLinkInfo::addressOfMaxNumArguments): Deleted.
107         (JSC::CallLinkInfo::maxNumArguments): Deleted.
108         * bytecode/CallLinkStatus.cpp:
109         (JSC::CallLinkStatus::computeFor):
110         (JSC::CallLinkStatus::dump const):
111         * bytecode/CallLinkStatus.h:
112         (JSC::CallLinkStatus::maxArgumentCountIncludingThis const):
113         (JSC::CallLinkStatus::maxNumArguments const): Deleted.
114         * dfg/DFGByteCodeParser.cpp:
115         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
116         * dfg/DFGSpeculativeJIT32_64.cpp:
117         (JSC::DFG::SpeculativeJIT::emitCall):
118         * dfg/DFGSpeculativeJIT64.cpp:
119         (JSC::DFG::SpeculativeJIT::emitCall):
120         * ftl/FTLLowerDFGToB3.cpp:
121         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
122         * jit/JITCall.cpp:
123         (JSC::JIT::compileSetupFrame):
124         * jit/JITCall32_64.cpp:
125         (JSC::JIT::compileSetupFrame):
126         * jit/JITOperations.cpp:
127
128 2019-09-19  Devin Rousso  <drousso@apple.com>
129
130         Web Inspector: Canvas: show WebGPU shader pipelines
131         https://bugs.webkit.org/show_bug.cgi?id=201675
132
133         Reviewed by Joseph Pecoraro.
134
135         * inspector/protocol/Canvas.json:
136         Add a `ProgramType` enum that conveys the type of shader program/pipeline when notifying the
137         frontend of a new program
138
139 2019-09-19  Mark Lam  <mark.lam@apple.com>
140
141         Rename VMInspector::m_list to m_vmList.
142         https://bugs.webkit.org/show_bug.cgi?id=202015
143
144         Reviewed by Yusuke Suzuki.
145
146         m_vmList is more descriptive, and this rename helps grep-ability by disambiguating
147         it from other m_lists in the code base.
148
149         * tools/VMInspector.cpp:
150         (JSC::VMInspector::add):
151         (JSC::VMInspector::remove):
152         * tools/VMInspector.h:
153         (JSC::VMInspector::iterate):
154
155 2019-09-19  Mark Lam  <mark.lam@apple.com>
156
157         Reduce the number of required tag bits for the JSValue.
158         https://bugs.webkit.org/show_bug.cgi?id=201990
159
160         Reviewed by Yusuke Suzuki.
161
162         We're reducing the number of tag bits to 15.  It should just work.
163
164         How did we arrive at 15 bits?
165         ============================
166         Currently, the minimum number of top bits used by doubles is 13-bits.  The
167         highest double bit encoding are:
168
169             "negative" pureNaN: starts with 0xfff8
170             negative infinity:  starts with 0xfff0
171             highest number:     starts with 0xffe*
172             lowest number:      starts with 0x0000
173
174         Requirements:
175         1. We need tags for 2 range of numbers: pointers (all 0s at the top), and ints
176            (all 1s at the top).
177
178         2. We want to be able to add an offset to double bits and ensure that they never
179            end up in the ranges for pointers and ints.
180
181         3. The int tag must be higher than whatever value is produced in the top bits
182            when boxing a double.  We have code that relies on this relationship being
183            true and checks if a JSValue is an int by checking if the tag bits are above
184            or equal to the int tag.
185
186         4. We don't want to burn more than 2 CPU registers for tag / mask registers.
187
188         Based on the bit encoding of doubles, the full number range of the top 13 bits
189         are used in valid double numbers.  This means the minimum tag bits must be greater
190         than 13.
191
192         Consider a 14-bit tag.  The DoubleEncodeOffset will be 1 << 50 i.e. starts with
193         0x0004.  With this encoding,
194             "negative" pureNaN: maps to 0xfff8 + 0x0004 => 0xfffc
195
196         i.e. the top 14 bits are all set.  This conflicts with the int number range.
197
198         Next, consider a 15-bit tag.  The DoubleEncodeOffset will be 1 << 49 i.e. starts
199         with 0x0002.  With this encoding:
200             "negative" pureNaN: maps to 0xfff8 + 0x0002 => 0xfffa
201             negative infinity:  maps to 0xfff0 + 0x0002 => 0xfff2
202
203         i.e. 0xfffe (top 5 bits set) is available to represent ints.  This is the encoding
204         that we'll adopt in this patch.
205
206         Alternate encodings schemes to consider in the future:
207         =====================================================
208         1. If we're willing and able to purifyNaN at all the places that can produce a
209            "negative" pureNaN, e.g. after a division, then we can remove the "negative"
210            pureNaN as a valid double bit encoding.  With this, we can now box doubles
211            with just a 14-bit tag, and DoubleEncodeOffset will be 1 << 50 i.e. starts with
212            0x0004.
213
214            With this encoding, the top double, negative infinity, is encoded as follows:
215
216                 negative infinity:  maps to 0xfff0 + 0x0004 => 0xfff4
217
218            i.e. leaving 0xfffc as the tag for ints.
219
220            We didn't adopt this scheme at this time because it adds complexity, and may
221            have performance impact from the extra purifyNaN checks.
222
223            Ref: https://bugs.webkit.org/show_bug.cgi?id=202002
224
225         2. If we're willing to use 3 tag registers or always materialize one of them, we
226            can also adopt a 14-bit tag as follows:
227
228                Pointer {  0000:PPPP:PPPP:PPPP
229                         / 0002:****:****:****
230                Double  {         ...
231                         \ FFFC:****:****:****
232                Integer {  FFFF:0000:IIII:IIII
233
234            where ...
235                NumberMask is 0xfffc: any bits set in the top 14 bits is a number.
236                IntMask is 0xffff: value is int if value & IntMask == IntMask.
237                NotCellMask is NumberMask | OtherTag.
238
239            Since the highest double is "negative" pureNaN i.e. starts with 0xfff8, adding
240            a DoubleEncodeOffset of 1<<50 (starts with 0x0004) produces 0xfffc which is
241            still less than 0xffff.
242
243            We didn't adopt this scheme at this time because it adds complexity and may
244            have a performance impact from either burning another register, or materializing
245            the 3rd mask.
246
247            Ref: https://bugs.webkit.org/show_bug.cgi?id=202005
248
249         * runtime/JSCJSValue.h:
250
251 2019-09-19  Mark Lam  <mark.lam@apple.com>
252
253         Refactoring: fix broken indentation in JSNonDestructibleProxy.h.
254         https://bugs.webkit.org/show_bug.cgi?id=201989
255
256         Reviewed by Saam Barati.
257
258         This patch only unindent the code to get it back to compliant formatting.
259         There is no actual code change.
260
261         * runtime/JSNonDestructibleProxy.h:
262         (JSC::JSNonDestructibleProxy::subspaceFor):
263         (JSC::JSNonDestructibleProxy::create):
264         (JSC::JSNonDestructibleProxy::createStructure):
265         (JSC::JSNonDestructibleProxy::JSNonDestructibleProxy):
266
267 2019-09-19  Tadeu Zagallo  <tzagallo@apple.com>
268
269         Syntax checker should report duplicate __proto__ properties
270         https://bugs.webkit.org/show_bug.cgi?id=201897
271         <rdar://problem/53201788>
272
273         Reviewed by Mark Lam.
274
275         Currently we have two ways of parsing object literals:
276         - parseObjectLiteral: this is called in sloppy mode, and as an optimization for syntax checking,
277           it doesn't allocate string literals while parsing properties. It does still allocate identifiers,
278           but it won't store them in the Property object that it creates for each parsed property. This
279           method backtracks and calls parseObjectStrictLiteral if it finds any getters or setters.
280         - parseObjectStrictLiteral: this is called in strict mode, or when the object contains getters/setters
281           as stated above. This will always allocate string literals as well as identifiers and store them in
282           the Property object, even during syntax checking.
283
284         From looking at the history, it seems that there was a distinction between these two methods:
285         parseStrictObjectLiteral was introduced in r62848 and contained an extra check for duplicate
286         getters/setters or properties defined as both getters/setters and constants. That distinction
287         was removed and the only distinction that remained was whether we build strings and store the
288         strings and properties as part of the Property object created by SyntaxChecker::createProperty.
289         However, this optimization is no longer valid, since we need to throw a SyntaxError for duplicate
290         __proto__ properties in object literals even in sloppy mode, which means that we do need to build
291         the strings and identifiers and store them as part of the Property objects.
292
293         * parser/Parser.cpp:
294         (JSC::Parser<LexerType>::parseObjectLiteral):
295         (JSC::Parser<LexerType>::parsePrimaryExpression):
296         (JSC::Parser<LexerType>::parseStrictObjectLiteral): Deleted.
297         * parser/Parser.h:
298
299 2019-09-19  Mark Lam  <mark.lam@apple.com>
300
301         Remove a now unnecessary hack to work around static const needing external linkage.
302         https://bugs.webkit.org/show_bug.cgi?id=201988
303
304         Reviewed by Saam Barati.
305
306         MacroAssembler::dataTempRegister is now a constexpr, thereby ensuring that it's
307         inlinable.
308
309         * b3/B3Common.cpp:
310         (JSC::B3::pinnedExtendedOffsetAddrRegister):
311
312 2019-09-19  Mark Lam  <mark.lam@apple.com>
313
314         Replace JSValue #defines with static constexpr values.
315         https://bugs.webkit.org/show_bug.cgi?id=201966
316
317         Reviewed by Yusuke Suzuki.
318
319         static constexpr is the modern C++ way to define these constants.
320
321         Some of the values are typed int64_t and some are int32_t.  The original #define
322         values are int64_t.  Hence, we adopt int64_t as the default type to use here.
323
324         However, some of these constants are being used as 32-bit values, and the code
325         was static_cast'ing them into int32_t.  This set of constants are all the small
326         values that fit in an int32_t anyway.  So, we're putting these in int32_t instead
327         so that we don't have to keep casting them.  In the few places where they are
328         used as int64_t, they will automatically get up-casted anyway.
329
330         In this patch, we also did the following:
331
332         1. Renamed TagMask to NotCellMask, because everywhere in the code, we're
333            basically using it to filter out cells like this:
334
335               if (value & NotCellMask) then goto handleNotCellCase;
336
337         2. Renamed TagTypeNumber to NumberTag for a shorter name.
338
339            Ditto for TagBitTypeOther, TagBitBool, TagBitUndefined, TagBitsWasm, and TagWasmMask.
340            They are now OtherTag, BoolTag, UndefinedTag, WasmTag, and WasmMask.
341
342         3. Introduced DoubleEncodeOffsetBit so that client code do not embed this value
343            as a literal constant.  We now define DoubleEncodeOffset based on
344            DoubleEncodeOffsetBit ensuring consistency.
345
346         4. Introduced MiscTag so that clients don't have to put this set of tags together
347            themselves.
348
349         5. Removed static asserts for tags in LLIntData.cpp because the offlineasm now
350            captures these values correctly with constexpr statements.  These static
351            asserts were holdovers from the old days back when we had to define LLInt
352            constant values manually, and we needed a mechanism to detect when the values
353            have changed in the source.
354
355         6. Replaced some runtime asserts in RegisterSet.cpp with static_asserts.
356
357         7. In Wasm::wasmToJS(), we were constructing the value of JSValue::DoubleEncodeOffset
358            constant by left shifting 1 by JSValue::DoubleEncodeOffsetBit.  There's no need
359            to do this for ARM64 because the constant can be loaded efficiently with a single
360            MOVZ instruction.  So, we add a CPU(ARM64) case to just move the constant into
361            the target register.
362
363         * assembler/AbortReason.h:
364         * bytecode/AccessCase.cpp:
365         (JSC::AccessCase::generateWithGuard):
366         * dfg/DFGOSRExit.cpp:
367         (JSC::DFG::OSRExit::executeOSRExit):
368         (JSC::DFG::OSRExit::compileExit):
369         * dfg/DFGSpeculativeJIT.cpp:
370         (JSC::DFG::SpeculativeJIT::silentFill):
371         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
372         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
373         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
374         (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
375         (JSC::DFG::SpeculativeJIT::speculateMisc):
376         * dfg/DFGSpeculativeJIT.h:
377         (JSC::DFG::SpeculativeJIT::spill):
378         * dfg/DFGSpeculativeJIT64.cpp:
379         (JSC::DFG::SpeculativeJIT::fillJSValue):
380         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
381         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
382         (JSC::DFG::SpeculativeJIT::emitCall):
383         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
384         (JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
385         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
386         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
387         (JSC::DFG::SpeculativeJIT::compileInt52Compare):
388         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
389         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
390         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
391         (JSC::DFG::SpeculativeJIT::emitBranch):
392         (JSC::DFG::SpeculativeJIT::compile):
393         (JSC::DFG::SpeculativeJIT::moveTrueTo):
394         (JSC::DFG::SpeculativeJIT::moveFalseTo):
395         (JSC::DFG::SpeculativeJIT::blessBoolean):
396         * ftl/FTLLowerDFGToB3.cpp:
397         (JSC::FTL::DFG::LowerDFGToB3::lower):
398         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
399         (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
400         (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
401         (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
402         (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
403         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
404         (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf):
405         (JSC::FTL::DFG::LowerDFGToB3::compileGetArgument):
406         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
407         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
408         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
409         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
410         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
411         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
412         (JSC::FTL::DFG::LowerDFGToB3::compileInById):
413         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
414         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
415         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
416         (JSC::FTL::DFG::LowerDFGToB3::getById):
417         (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
418         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
419         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
420         (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
421         (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
422         (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
423         (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
424         (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
425         (JSC::FTL::DFG::LowerDFGToB3::isInt32):
426         (JSC::FTL::DFG::LowerDFGToB3::isNotInt32):
427         (JSC::FTL::DFG::LowerDFGToB3::boxInt32):
428         (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
429         (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
430         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
431         (JSC::FTL::DFG::LowerDFGToB3::boxDouble):
432         (JSC::FTL::DFG::LowerDFGToB3::isNotCell):
433         (JSC::FTL::DFG::LowerDFGToB3::isCell):
434         (JSC::FTL::DFG::LowerDFGToB3::isNotMisc):
435         (JSC::FTL::DFG::LowerDFGToB3::isNotBoolean):
436         (JSC::FTL::DFG::LowerDFGToB3::boxBoolean):
437         (JSC::FTL::DFG::LowerDFGToB3::isNotOther):
438         (JSC::FTL::DFG::LowerDFGToB3::isOther):
439         * ftl/FTLOSRExitCompiler.cpp:
440         (JSC::FTL::reboxAccordingToFormat):
441         (JSC::FTL::compileStub):
442         * interpreter/CalleeBits.h:
443         (JSC::CalleeBits::boxWasm):
444         (JSC::CalleeBits::isWasm const):
445         (JSC::CalleeBits::asWasmCallee const):
446         * jit/AssemblyHelpers.cpp:
447         (JSC::AssemblyHelpers::jitAssertIsJSInt32):
448         (JSC::AssemblyHelpers::jitAssertIsJSNumber):
449         (JSC::AssemblyHelpers::jitAssertIsJSDouble):
450         (JSC::AssemblyHelpers::jitAssertIsCell):
451         (JSC::AssemblyHelpers::jitAssertTagsInPlace):
452         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
453         * jit/AssemblyHelpers.h:
454         (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters):
455         (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
456         (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
457         (JSC::AssemblyHelpers::branchIfNotCell):
458         (JSC::AssemblyHelpers::branchIfCell):
459         (JSC::AssemblyHelpers::branchIfOther):
460         (JSC::AssemblyHelpers::branchIfNotOther):
461         (JSC::AssemblyHelpers::branchIfInt32):
462         (JSC::AssemblyHelpers::branchIfNotInt32):
463         (JSC::AssemblyHelpers::branchIfNumber):
464         (JSC::AssemblyHelpers::branchIfNotNumber):
465         (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
466         (JSC::AssemblyHelpers::branchIfBoolean):
467         (JSC::AssemblyHelpers::branchIfNotBoolean):
468         (JSC::AssemblyHelpers::boxDouble):
469         (JSC::AssemblyHelpers::unboxDoubleWithoutAssertions):
470         (JSC::AssemblyHelpers::boxInt52):
471         (JSC::AssemblyHelpers::boxBooleanPayload):
472         (JSC::AssemblyHelpers::boxInt32):
473         * jit/CallFrameShuffleData.h:
474         * jit/CallFrameShuffler.cpp:
475         (JSC::CallFrameShuffler::CallFrameShuffler):
476         (JSC::CallFrameShuffler::dump const):
477         (JSC::CallFrameShuffler::prepareAny):
478         * jit/CallFrameShuffler.h:
479         (JSC::CallFrameShuffler::getFreeRegister const):
480         * jit/CallFrameShuffler64.cpp:
481         (JSC::CallFrameShuffler::emitBox):
482         (JSC::CallFrameShuffler::tryAcquireNumberTagRegister):
483         (JSC::CallFrameShuffler::tryAcquireTagTypeNumber): Deleted.
484         * jit/GPRInfo.h:
485         (JSC::GPRInfo::reservedRegisters):
486         * jit/JITArithmetic.cpp:
487         (JSC::JIT::emit_compareAndJumpSlow):
488         * jit/JITBitAndGenerator.cpp:
489         (JSC::JITBitAndGenerator::generateFastPath):
490         * jit/JITBitOrGenerator.cpp:
491         (JSC::JITBitOrGenerator::generateFastPath):
492         * jit/JITBitXorGenerator.cpp:
493         (JSC::JITBitXorGenerator::generateFastPath):
494         * jit/JITCall.cpp:
495         (JSC::JIT::compileTailCall):
496         * jit/JITDivGenerator.cpp:
497         (JSC::JITDivGenerator::generateFastPath):
498         * jit/JITInlines.h:
499         (JSC::JIT::emitPatchableJumpIfNotInt):
500         * jit/JITLeftShiftGenerator.cpp:
501         (JSC::JITLeftShiftGenerator::generateFastPath):
502         * jit/JITMulGenerator.cpp:
503         (JSC::JITMulGenerator::generateFastPath):
504         * jit/JITOpcodes.cpp:
505         (JSC::JIT::emit_op_overrides_has_instance):
506         (JSC::JIT::emit_op_is_undefined):
507         (JSC::JIT::emit_op_is_undefined_or_null):
508         (JSC::JIT::emit_op_is_boolean):
509         (JSC::JIT::emit_op_is_number):
510         (JSC::JIT::emit_op_is_cell_with_type):
511         (JSC::JIT::emit_op_is_object):
512         (JSC::JIT::emit_op_not):
513         (JSC::JIT::emit_op_jeq_null):
514         (JSC::JIT::emit_op_jneq_null):
515         (JSC::JIT::emit_op_jundefined_or_null):
516         (JSC::JIT::emit_op_jnundefined_or_null):
517         (JSC::JIT::emit_op_eq_null):
518         (JSC::JIT::emit_op_neq_null):
519         * jit/JITPropertyAccess.cpp:
520         (JSC::JIT::emitGenericContiguousPutByVal):
521         (JSC::JIT::emitFloatTypedArrayPutByVal):
522         * jit/JITRightShiftGenerator.cpp:
523         (JSC::JITRightShiftGenerator::generateFastPath):
524         * jit/RegisterSet.cpp:
525         (JSC::RegisterSet::runtimeTagRegisters):
526         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
527         (JSC::RegisterSet::dfgCalleeSaveRegisters):
528         (JSC::RegisterSet::ftlCalleeSaveRegisters):
529         * jit/SpecializedThunkJIT.h:
530         (JSC::SpecializedThunkJIT::returnDouble):
531         (JSC::SpecializedThunkJIT::tagReturnAsInt32):
532         * jit/ThunkGenerators.cpp:
533         (JSC::virtualThunkFor):
534         (JSC::nativeForGenerator):
535         (JSC::arityFixupGenerator):
536         (JSC::absThunkGenerator):
537         * llint/LLIntData.cpp:
538         (JSC::LLInt::Data::performAssertions):
539         * llint/LowLevelInterpreter.asm:
540         * llint/LowLevelInterpreter.cpp:
541         (JSC::CLoop::execute):
542         * llint/LowLevelInterpreter64.asm:
543         * offlineasm/arm64.rb:
544         * offlineasm/cloop.rb:
545         * offlineasm/x86.rb:
546         * runtime/JSCJSValue.h:
547         * runtime/JSCJSValueInlines.h:
548         (JSC::JSValue::isUndefinedOrNull const):
549         (JSC::JSValue::isCell const):
550         (JSC::JSValue::isInt32 const):
551         (JSC::JSValue::JSValue):
552         (JSC::JSValue::asDouble const):
553         (JSC::JSValue::isNumber const):
554         * wasm/js/WasmToJS.cpp:
555         (JSC::Wasm::wasmToJS):
556         * wasm/js/WebAssemblyFunction.cpp:
557         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
558
559 2019-09-18  Devin Rousso  <drousso@apple.com>
560
561         Web Inspector: Better handling for large arrays and collections in Object Trees
562         https://bugs.webkit.org/show_bug.cgi?id=143589
563         <rdar://problem/16135388>
564
565         Reviewed by Joseph Pecoraro.
566
567         Adds two buttons before the "Prototype" item in expanded object/collection previews:
568          - Show %d More
569          - Show All (%d More)
570
571         The default `fetchCount` increment is `100`. The first button will only be shown if there
572         are more than `100` items remaining (haven't been shown).
573
574         * inspector/InjectedScriptSource.js:
575         (InjectedScript.prototype.getProperties):
576         (InjectedScript.prototype.getDisplayableProperties):
577         (InjectedScript.prototype.getCollectionEntries):
578         (InjectedScript.prototype._getProperties):
579         (InjectedScript.prototype._internalPropertyDescriptors):
580         (InjectedScript.prototype._propertyDescriptors):
581         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
582         (InjectedScript.prototype._propertyDescriptors.processProperties):
583         (InjectedScript.prototype._getSetEntries):
584         (InjectedScript.prototype._getMapEntries):
585         (InjectedScript.prototype._getWeakMapEntries):
586         (InjectedScript.prototype._getWeakSetEntries):
587         (InjectedScript.prototype._getIteratorEntries):
588         (InjectedScript.prototype._entries):
589         (RemoteObject.prototype._generatePreview):
590         (InjectedScript.prototype._propertyDescriptors.arrayIndexPropertyNames): Deleted.
591         Don't include boolean property descriptor values if they are `false.
592
593         * inspector/JSInjectedScriptHost.cpp:
594         (Inspector::JSInjectedScriptHost::weakMapEntries):
595         (Inspector::JSInjectedScriptHost::weakSetEntries):
596
597         * inspector/InjectedScript.h:
598         * inspector/InjectedScript.cpp:
599         (Inspector::InjectedScript::getProperties):
600         (Inspector::InjectedScript::getDisplayableProperties):
601         (Inspector::InjectedScript::getCollectionEntries):
602
603         * inspector/agents/InspectorRuntimeAgent.h:
604         * inspector/agents/InspectorRuntimeAgent.cpp:
605         (Inspector::asInt): Added.
606         (Inspector::InspectorRuntimeAgent::getProperties):
607         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
608         (Inspector::InspectorRuntimeAgent::getCollectionEntries):
609
610         * inspector/protocol/Runtime.json:
611         Add `fetchStart`/`fetchCount` to `getProperties`/`getDisplayableProperties`/`getCollectionEntries`.
612         Mark boolean properties as optional so they can be omitted if `false`.
613
614 2019-09-18  Joonghun Park  <pjh0718@gmail.com>
615
616         Unreviewed. Remove build warning since r249976.
617
618         No new tests, no behavioral changes.
619
620         This patch removes the build warning below.
621         warning: control reaches end of non-void function [-Wreturn-type]
622
623         * dfg/DFGArrayMode.cpp:
624         (JSC::DFG::ArrayMode::alreadyChecked const):
625
626 2019-09-18  Saam Barati  <sbarati@apple.com>
627
628         TOCTOU bug in havingABadTime related assertion in DFGSpeculativeJIT
629         https://bugs.webkit.org/show_bug.cgi?id=201953
630         <rdar://problem/53803524>
631
632         Reviewed by Yusuke Suzuki.
633
634         We had code in DFGSpeculativeJIT like:
635         
636         if (!globalObject->isHavingABadTime()) {
637             <-- here -->
638             Structure* s = globalObject->arrayStructureForIndexingTypeDuringAllocation(node->indexingType()));
639             assert 's' has expected indexing type
640         }
641         
642         The problem is, we may have a bad time before we actually load the structure
643         inside the if. We may have a bad time while we're at the "<-- here -->" in the
644         above program. The fix is to first load the structure, then check if we're
645         having a bad time. If we're still not having a bad time, it's valid to assert
646         things about the structure.
647
648         * dfg/DFGSpeculativeJIT.cpp:
649         (JSC::DFG::SpeculativeJIT::compileNewArray):
650
651 2019-09-18  Chris Dumez  <cdumez@apple.com>
652
653         Stop calling WTF::initializeMainThread() in JSGlobalContextCreate*()
654         https://bugs.webkit.org/show_bug.cgi?id=201947
655         <rdar://problem/55453612>
656
657         Reviewed by Mark Lam.
658
659         Stop calling WTF::initializeMainThread() in JSGlobalContextCreate*(). I started doing so in <https://trac.webkit.org/changeset/248533>
660         but it is causing crashes for apps using this JS API on background threads. It is also no longer necessary as of
661         <https://trac.webkit.org/changeset/249064>.
662
663         * API/JSContextRef.cpp:
664         (JSContextGroupCreate):
665         (JSGlobalContextCreate):
666         (JSGlobalContextCreateInGroup):
667
668 2019-09-18  Saam Barati  <sbarati@apple.com>
669
670         Phantom insertion phase may disagree with arguments forwarding about live ranges
671         https://bugs.webkit.org/show_bug.cgi?id=200715
672         <rdar://problem/54301717>
673
674         Reviewed by Yusuke Suzuki.
675
676         The issue is that Phantom insertion phase was disagreeing about live ranges
677         from the arguments forwarding phase. The effect is that Phantom insertion
678         would insert a Phantom creating a longer live range than what arguments
679         forwarding was analyzing. Arguments forwarding will look for the last DFG
680         use or the last bytecode use of a variable it wants to eliminate. It then
681         does an interference analysis to ensure that nothing clobbers other variables
682         it needs to recover the sunken allocation during OSR exit.
683         
684         Phantom insertion works by ordering the program into OSR exit epochs. If a value was used
685         in the current epoch, there is no need to insert a phantom for it. We
686         determine where we might need a Phantom by looking at bytecode kills. In this
687         analysis, we have a mapping from bytecode local to DFG node. However, we
688         sometimes forgot to remove the entry when a local is killed. So, if the first
689         kill of a variable is in the same OSR exit epoch, we won't insert a Phantom by design.
690         However, if the variable gets killed again, we might errantly insert a Phantom
691         for the prior variable which should've already been killed. The solution is to
692         clear the entry in our mapping when a variable is killed.
693         
694         The program in question was like this:
695         
696         1: DirectArguments
697         ...
698         2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1
699         ...
700         clobber things needed for recovery
701         ...
702         
703         Arguments elimination would transform the program since between @1 and
704         @2, nothing clobbers values needed for exit and nothing escapes @1. The
705         program becomes:
706         
707         1: PhantomDirectArguments
708         ...
709         2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1
710         ...
711         clobber things needed for recovery of @1
712         ...
713         
714         
715         Phantom insertion would then transform the program into:
716         
717         1: PhantomDirectArguments
718         ...
719         2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1
720         ...
721         clobber things needed for recovery of @1
722         ...
723         3: Phantom(@1)
724         ...
725         
726         This is wrong because Phantom insertion and arguments forwarding must agree on live
727         ranges, otherwise the interference analysis performed by arguments forwarding will
728         not correctly analyze up until where the value might be recovered.
729
730         * dfg/DFGPhantomInsertionPhase.cpp:
731
732 2019-09-18  Commit Queue  <commit-queue@webkit.org>
733
734         Unreviewed, rolling out r250002.
735         https://bugs.webkit.org/show_bug.cgi?id=201943
736
737         Patching of the callee and call is not atomic (Requested by
738         tadeuzagallo on #webkit).
739
740         Reverted changeset:
741
742         "Change WebAssembly calling conventions"
743         https://bugs.webkit.org/show_bug.cgi?id=201799
744         https://trac.webkit.org/changeset/250002
745
746 2019-09-17  Yusuke Suzuki  <ysuzuki@apple.com>
747
748         [JSC] Generator should have internal fields
749         https://bugs.webkit.org/show_bug.cgi?id=201159
750
751         Reviewed by Keith Miller.
752
753         This patch makes generator's internal states InternalField instead of private properties.
754         Each generator function produces a generator with different [[Prototype]], which makes generators have different Structures.
755         As a result, Generator.prototype.next etc.'s implementation becomes megamorphic even if it is not necessary.
756
757         If we make these structures adaptively poly-proto, some generators get poly-proto structures while others are not, resulting
758         in megamorphic lookup in Generator.prototype.next. If we make all the generator's structure poly-proto, it makes Generator.prototype.next
759         lookup suboptimal for now.
760
761         In this patch, we start with a relatively simple solution. This patch introduces JSGenerator class, and it has internal fields for generator's internal
762         states. We extend promise-internal-field access bytecodes to access to these fields from bytecode so that Generator.prototype.next can access
763         these fields without using megamorphic get_by_id_direct.
764
765         And we attach JSGeneratorType to JSGenerator so that we can efficiently implement `@isGenerator()` check in bytecode.
766
767         We reserve the offset = 0 slot for the future poly-proto extension for JSGenerator. By reserving this slot, non-poly-proto JSGenerator and poly-proto
768         JSGenerator still can offer the way to access to the same Generator internal fields with the same offset while poly-proto JSGenerator can get offset = 0
769         inline-storage slot for PolyProto implementation.
770
771         This patch adds op_create_generator since it is distinct from op_create_promise once we add PolyProto support.
772         In the future when we introduce some kind of op_create_async_generator we will probably share only one bytecode for both generator and async generator.
773
774         This patch offers around 10% improvement in JetStream2/Basic. And this patch is the basis of optimization of JetStream2/async-fs which leverages async generators significantly.
775
776         This patch includes several design decisions.
777
778             1. We add a new JSGenerator instead of leveraging JSFinalObject. The main reason is that we would like to have JSGeneratorType to quickly query `@isGenerator`.
779             2. This patch currently does not include object-allocation-sinking support for JSGenerator, but it is trivial, and will be added. And this patch also does not include poly-proto
780                support for JSGenerator. The main reason is simply because this patch is already large enough, and I do not want to make this patch larger and larger.
781             3. We can support arbitrary sized inline-storage: Reserving 0-5 offsets for internal fields, and start putting all the other things to the subsequent internal fields. But for now,
782                we are not taking this approach just because I'm not sure this is necessary. If we found such a pattern, we can easily extend the current one but for now, I would like to keep
783                this patch simple.
784
785         * JavaScriptCore.xcodeproj/project.pbxproj:
786         * Sources.txt:
787         * builtins/AsyncFunctionPrototype.js:
788         (globalPrivate.asyncFunctionResume):
789         * builtins/GeneratorPrototype.js:
790         (globalPrivate.generatorResume):
791         (next):
792         (return):
793         (throw):
794         * bytecode/BytecodeGeneratorification.cpp:
795         (JSC::BytecodeGeneratorification::run):
796         * bytecode/BytecodeIntrinsicRegistry.cpp:
797         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
798         * bytecode/BytecodeIntrinsicRegistry.h:
799         * bytecode/BytecodeList.rb:
800         * bytecode/BytecodeUseDef.h:
801         (JSC::computeUsesForBytecodeOffset):
802         (JSC::computeDefsForBytecodeOffset):
803         * bytecode/CodeBlock.cpp:
804         (JSC::CodeBlock::finishCreation):
805         (JSC::CodeBlock::finalizeLLIntInlineCaches):
806         * bytecode/SpeculatedType.cpp:
807         (JSC::speculationFromJSType):
808         * bytecode/SpeculatedType.h:
809         * bytecompiler/BytecodeGenerator.cpp:
810         (JSC::BytecodeGenerator::BytecodeGenerator):
811         (JSC::BytecodeGenerator::emitPutGeneratorFields):
812         (JSC::BytecodeGenerator::emitCreateGenerator):
813         (JSC::BytecodeGenerator::emitNewGenerator):
814         (JSC::BytecodeGenerator::emitYield):
815         (JSC::BytecodeGenerator::emitDelegateYield):
816         (JSC::BytecodeGenerator::emitGeneratorStateChange):
817         * bytecompiler/BytecodeGenerator.h:
818         (JSC::BytecodeGenerator::emitIsGenerator):
819         (JSC::BytecodeGenerator::generatorStateRegister):
820         (JSC::BytecodeGenerator::generatorValueRegister):
821         (JSC::BytecodeGenerator::generatorResumeModeRegister):
822         (JSC::BytecodeGenerator::generatorFrameRegister):
823         * bytecompiler/NodesCodegen.cpp:
824         (JSC::generatorInternalFieldIndex):
825         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getGeneratorInternalField):
826         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putGeneratorInternalField):
827         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isGenerator):
828         (JSC::FunctionNode::emitBytecode):
829         * dfg/DFGAbstractInterpreterInlines.h:
830         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
831         * dfg/DFGByteCodeParser.cpp:
832         (JSC::DFG::ByteCodeParser::parseBlock):
833         * dfg/DFGCapabilities.cpp:
834         (JSC::DFG::capabilityLevel):
835         * dfg/DFGClobberize.h:
836         (JSC::DFG::clobberize):
837         * dfg/DFGClobbersExitState.cpp:
838         (JSC::DFG::clobbersExitState):
839         * dfg/DFGConstantFoldingPhase.cpp:
840         (JSC::DFG::ConstantFoldingPhase::foldConstants):
841         * dfg/DFGDoesGC.cpp:
842         (JSC::DFG::doesGC):
843         * dfg/DFGFixupPhase.cpp:
844         (JSC::DFG::FixupPhase::fixupNode):
845         (JSC::DFG::FixupPhase::fixupIsCellWithType):
846         * dfg/DFGGraph.cpp:
847         (JSC::DFG::Graph::dump):
848         * dfg/DFGNode.h:
849         (JSC::DFG::Node::convertToNewGenerator):
850         (JSC::DFG::Node::speculatedTypeForQuery):
851         (JSC::DFG::Node::hasStructure):
852         * dfg/DFGNodeType.h:
853         * dfg/DFGOperations.cpp:
854         * dfg/DFGOperations.h:
855         * dfg/DFGPredictionPropagationPhase.cpp:
856         * dfg/DFGSafeToExecute.h:
857         (JSC::DFG::safeToExecute):
858         * dfg/DFGSpeculativeJIT.cpp:
859         (JSC::DFG::SpeculativeJIT::compileCreatePromise):
860         (JSC::DFG::SpeculativeJIT::compileCreateGenerator):
861         (JSC::DFG::SpeculativeJIT::compileNewGenerator):
862         * dfg/DFGSpeculativeJIT.h:
863         * dfg/DFGSpeculativeJIT32_64.cpp:
864         (JSC::DFG::SpeculativeJIT::compile):
865         * dfg/DFGSpeculativeJIT64.cpp:
866         (JSC::DFG::SpeculativeJIT::compile):
867         * dfg/DFGStoreBarrierInsertionPhase.cpp:
868         * ftl/FTLCapabilities.cpp:
869         (JSC::FTL::canCompile):
870         * ftl/FTLLowerDFGToB3.cpp:
871         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
872         (JSC::FTL::DFG::LowerDFGToB3::compileNewGenerator):
873         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
874         (JSC::FTL::DFG::LowerDFGToB3::compileCreateGenerator):
875         (JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
876         * jit/JIT.cpp:
877         (JSC::JIT::privateCompileMainPass):
878         (JSC::JIT::privateCompileSlowCases):
879         * jit/JITOperations.cpp:
880         * jit/JITOperations.h:
881         * jit/JITPropertyAccess.cpp:
882         (JSC::JIT::emit_op_get_internal_field):
883         (JSC::JIT::emit_op_put_internal_field):
884         * llint/LowLevelInterpreter.asm:
885         * runtime/CommonSlowPaths.cpp:
886         (JSC::SLOW_PATH_DECL):
887         * runtime/CommonSlowPaths.h:
888         * runtime/InternalFunction.cpp:
889         (JSC::InternalFunction::createSubclassStructureSlow):
890         * runtime/InternalFunction.h:
891         (JSC::InternalFunction::createSubclassStructure):
892         * runtime/JSGenerator.cpp: Added.
893         (JSC::JSGenerator::create):
894         (JSC::JSGenerator::createStructure):
895         (JSC::JSGenerator::JSGenerator):
896         (JSC::JSGenerator::finishCreation):
897         (JSC::JSGenerator::visitChildren):
898         * runtime/JSGenerator.h: Copied from Source/JavaScriptCore/runtime/JSGeneratorFunction.h.
899         * runtime/JSGeneratorFunction.h:
900         * runtime/JSGlobalObject.cpp:
901         (JSC::JSGlobalObject::init):
902         (JSC::JSGlobalObject::visitChildren):
903         * runtime/JSGlobalObject.h:
904         (JSC::JSGlobalObject::generatorStructure const):
905         * runtime/JSType.cpp:
906         (WTF::printInternal):
907         * runtime/JSType.h:
908
909 2019-09-17  Keith Miller  <keith_miller@apple.com>
910
911         Move comment explaining our Options to OptionsList.h
912         https://bugs.webkit.org/show_bug.cgi?id=201891
913
914         Rubber-stamped by Mark Lam.
915
916         We moved the list so we should move the comment.
917
918         * runtime/Options.h:
919         * runtime/OptionsList.h:
920
921 2019-09-17  Keith Miller  <keith_miller@apple.com>
922
923         Elide unnecessary moves in Air O0
924         https://bugs.webkit.org/show_bug.cgi?id=201703
925
926         Reviewed by Saam Barati.
927
928         This patch also removes the code that would try to reuse temps in
929         WasmAirIRGenerator. That code makes it hard to accurately
930         determine where a temp dies as it could be reused again
931         later. Thus every temp, may appear to live for a long time in the
932         global ordering.
933
934         This appears to be a minor progression on the overall score of
935         wasm subtests in JS2 and a 10% wasm-JIT memory usage reduction.
936
937         This patch also fixes an issue where we didn't ask Patchpoints
938         for early clobber registers when determining what callee saves
939         were used by the program.
940
941         * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
942         (JSC::B3::Air::GenerateAndAllocateRegisters::generate):
943         * b3/air/AirBasicBlock.h:
944         * b3/air/AirCode.h:
945         * b3/air/AirHandleCalleeSaves.cpp:
946         (JSC::B3::Air::handleCalleeSaves):
947         * b3/air/testair.cpp:
948         * wasm/WasmAirIRGenerator.cpp:
949         (JSC::Wasm::AirIRGenerator::didKill): Deleted.
950         * wasm/WasmB3IRGenerator.cpp:
951         (JSC::Wasm::B3IRGenerator::didKill): Deleted.
952         * wasm/WasmFunctionParser.h:
953         (JSC::Wasm::FunctionParser<Context>::parseBody):
954         (JSC::Wasm::FunctionParser<Context>::parseExpression):
955         * wasm/WasmValidate.cpp:
956         (JSC::Wasm::Validate::didKill): Deleted.
957
958 2019-09-17  Mark Lam  <mark.lam@apple.com>
959
960         Use constexpr instead of const in symbol definitions that are obviously constexpr.
961         https://bugs.webkit.org/show_bug.cgi?id=201879
962
963         Rubber-stamped by Joseph Pecoraro.
964
965         const may require external storage  (at the compiler's whim) though these
966         currently do not.  constexpr makes it clear that the value is a literal constant
967         that can be inlined.  In most cases in the code, when we say static const, we
968         actually mean static constexpr.  I'm changing the code to reflect this.
969
970         * API/JSAPIValueWrapper.h:
971         * API/JSCallbackConstructor.h:
972         * API/JSCallbackObject.h:
973         * API/JSContextRef.cpp:
974         * API/JSWrapperMap.mm:
975         * API/tests/CompareAndSwapTest.cpp:
976         * API/tests/TypedArrayCTest.cpp:
977         * API/tests/testapi.mm:
978         (testObjectiveCAPIMain):
979         * KeywordLookupGenerator.py:
980         (Trie.printAsC):
981         * assembler/ARMv7Assembler.h:
982         * assembler/AssemblerBuffer.h:
983         * assembler/AssemblerCommon.h:
984         * assembler/MacroAssembler.h:
985         * assembler/MacroAssemblerARM64.h:
986         * assembler/MacroAssemblerARM64E.h:
987         * assembler/MacroAssemblerARMv7.h:
988         * assembler/MacroAssemblerCodeRef.h:
989         * assembler/MacroAssemblerMIPS.h:
990         * assembler/MacroAssemblerX86.h:
991         * assembler/MacroAssemblerX86Common.h:
992         (JSC::MacroAssemblerX86Common::absDouble):
993         (JSC::MacroAssemblerX86Common::negateDouble):
994         * assembler/MacroAssemblerX86_64.h:
995         * assembler/X86Assembler.h:
996         * b3/B3Bank.h:
997         * b3/B3CheckSpecial.h:
998         * b3/B3DuplicateTails.cpp:
999         * b3/B3EliminateCommonSubexpressions.cpp:
1000         * b3/B3FixSSA.cpp:
1001         * b3/B3FoldPathConstants.cpp:
1002         * b3/B3InferSwitches.cpp:
1003         * b3/B3Kind.h:
1004         * b3/B3LowerToAir.cpp:
1005         * b3/B3NativeTraits.h:
1006         * b3/B3ReduceDoubleToFloat.cpp:
1007         * b3/B3ReduceLoopStrength.cpp:
1008         * b3/B3ReduceStrength.cpp:
1009         * b3/B3ValueKey.h:
1010         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
1011         * b3/air/AirAllocateStackByGraphColoring.cpp:
1012         * b3/air/AirArg.h:
1013         * b3/air/AirCCallSpecial.h:
1014         * b3/air/AirEmitShuffle.cpp:
1015         * b3/air/AirFixObviousSpills.cpp:
1016         * b3/air/AirFormTable.h:
1017         * b3/air/AirLowerAfterRegAlloc.cpp:
1018         * b3/air/AirPrintSpecial.h:
1019         * b3/air/AirStackAllocation.cpp:
1020         * b3/air/AirTmp.h:
1021         * b3/testb3_6.cpp:
1022         (testInterpreter):
1023         * bytecode/AccessCase.cpp:
1024         * bytecode/CallLinkStatus.cpp:
1025         * bytecode/CallVariant.h:
1026         * bytecode/CodeBlock.h:
1027         * bytecode/CodeOrigin.h:
1028         * bytecode/DFGExitProfile.h:
1029         * bytecode/DirectEvalCodeCache.h:
1030         * bytecode/ExecutableToCodeBlockEdge.h:
1031         * bytecode/GetterSetterAccessCase.cpp:
1032         * bytecode/LazyOperandValueProfile.h:
1033         * bytecode/ObjectPropertyCondition.h:
1034         * bytecode/ObjectPropertyConditionSet.cpp:
1035         * bytecode/PolymorphicAccess.cpp:
1036         * bytecode/PropertyCondition.h:
1037         * bytecode/SpeculatedType.h:
1038         * bytecode/StructureStubInfo.cpp:
1039         * bytecode/UnlinkedCodeBlock.cpp:
1040         (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset):
1041         * bytecode/UnlinkedCodeBlock.h:
1042         * bytecode/UnlinkedEvalCodeBlock.h:
1043         * bytecode/UnlinkedFunctionCodeBlock.h:
1044         * bytecode/UnlinkedFunctionExecutable.h:
1045         * bytecode/UnlinkedModuleProgramCodeBlock.h:
1046         * bytecode/UnlinkedProgramCodeBlock.h:
1047         * bytecode/ValueProfile.h:
1048         * bytecode/VirtualRegister.h:
1049         * bytecode/Watchpoint.h:
1050         * bytecompiler/BytecodeGenerator.h:
1051         * bytecompiler/Label.h:
1052         * bytecompiler/NodesCodegen.cpp:
1053         (JSC::ThisNode::emitBytecode):
1054         * bytecompiler/RegisterID.h:
1055         * debugger/Breakpoint.h:
1056         * debugger/DebuggerParseData.cpp:
1057         * debugger/DebuggerPrimitives.h:
1058         * debugger/DebuggerScope.h:
1059         * dfg/DFGAbstractHeap.h:
1060         * dfg/DFGAbstractValue.h:
1061         * dfg/DFGArgumentsEliminationPhase.cpp:
1062         * dfg/DFGByteCodeParser.cpp:
1063         * dfg/DFGCSEPhase.cpp:
1064         * dfg/DFGCommon.h:
1065         * dfg/DFGCompilationKey.h:
1066         * dfg/DFGDesiredGlobalProperty.h:
1067         * dfg/DFGEdgeDominates.h:
1068         * dfg/DFGEpoch.h:
1069         * dfg/DFGForAllKills.h:
1070         (JSC::DFG::forAllKilledNodesAtNodeIndex):
1071         * dfg/DFGGraph.cpp:
1072         (JSC::DFG::Graph::isLiveInBytecode):
1073         * dfg/DFGHeapLocation.h:
1074         * dfg/DFGInPlaceAbstractState.cpp:
1075         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1076         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1077         * dfg/DFGInvalidationPointInjectionPhase.cpp:
1078         * dfg/DFGLICMPhase.cpp:
1079         * dfg/DFGLazyNode.h:
1080         * dfg/DFGMinifiedID.h:
1081         * dfg/DFGMovHintRemovalPhase.cpp:
1082         * dfg/DFGNodeFlowProjection.h:
1083         * dfg/DFGNodeType.h:
1084         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1085         * dfg/DFGPhantomInsertionPhase.cpp:
1086         * dfg/DFGPromotedHeapLocation.h:
1087         * dfg/DFGPropertyTypeKey.h:
1088         * dfg/DFGPureValue.h:
1089         * dfg/DFGPutStackSinkingPhase.cpp:
1090         * dfg/DFGRegisterBank.h:
1091         * dfg/DFGSSAConversionPhase.cpp:
1092         * dfg/DFGSSALoweringPhase.cpp:
1093         * dfg/DFGSpeculativeJIT.cpp:
1094         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
1095         (JSC::DFG::compileClampDoubleToByte):
1096         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1097         (JSC::DFG::compileArithPowIntegerFastPath):
1098         (JSC::DFG::SpeculativeJIT::compileArithPow):
1099         (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse):
1100         * dfg/DFGStackLayoutPhase.cpp:
1101         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1102         * dfg/DFGStrengthReductionPhase.cpp:
1103         * dfg/DFGStructureAbstractValue.h:
1104         * dfg/DFGVarargsForwardingPhase.cpp:
1105         * dfg/DFGVariableEventStream.cpp:
1106         (JSC::DFG::VariableEventStream::reconstruct const):
1107         * dfg/DFGWatchpointCollectionPhase.cpp:
1108         * disassembler/ARM64/A64DOpcode.h:
1109         * ftl/FTLLocation.h:
1110         * ftl/FTLLowerDFGToB3.cpp:
1111         (JSC::FTL::DFG::LowerDFGToB3::compileArithRandom):
1112         * ftl/FTLSlowPathCall.cpp:
1113         * ftl/FTLSlowPathCallKey.h:
1114         * heap/CellContainer.h:
1115         * heap/CellState.h:
1116         * heap/ConservativeRoots.h:
1117         * heap/GCSegmentedArray.h:
1118         * heap/HandleBlock.h:
1119         * heap/Heap.cpp:
1120         (JSC::Heap::updateAllocationLimits):
1121         * heap/Heap.h:
1122         * heap/HeapSnapshot.h:
1123         * heap/HeapUtil.h:
1124         (JSC::HeapUtil::findGCObjectPointersForMarking):
1125         * heap/IncrementalSweeper.cpp:
1126         * heap/LargeAllocation.h:
1127         * heap/MarkedBlock.cpp:
1128         * heap/Strong.h:
1129         * heap/VisitRaceKey.h:
1130         * heap/Weak.h:
1131         * heap/WeakBlock.h:
1132         * inspector/JSInjectedScriptHost.h:
1133         * inspector/JSInjectedScriptHostPrototype.h:
1134         * inspector/JSJavaScriptCallFrame.h:
1135         * inspector/JSJavaScriptCallFramePrototype.h:
1136         * inspector/agents/InspectorConsoleAgent.cpp:
1137         * inspector/agents/InspectorRuntimeAgent.cpp:
1138         (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
1139         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
1140         (CppProtocolTypesHeaderGenerator._generate_versions):
1141         * inspector/scripts/tests/generic/expected/version.json-result:
1142         * interpreter/Interpreter.h:
1143         * interpreter/ShadowChicken.cpp:
1144         * jit/BinarySwitch.cpp:
1145         * jit/CallFrameShuffler.h:
1146         * jit/ExecutableAllocator.h:
1147         * jit/FPRInfo.h:
1148         * jit/GPRInfo.h:
1149         * jit/ICStats.h:
1150         * jit/JITThunks.h:
1151         * jit/Reg.h:
1152         * jit/RegisterSet.h:
1153         * jit/TempRegisterSet.h:
1154         * jsc.cpp:
1155         * parser/ASTBuilder.h:
1156         * parser/Nodes.h:
1157         * parser/SourceCodeKey.h:
1158         * parser/SyntaxChecker.h:
1159         * parser/VariableEnvironment.h:
1160         * profiler/ProfilerOrigin.h:
1161         * profiler/ProfilerOriginStack.h:
1162         * profiler/ProfilerUID.h:
1163         * runtime/AbstractModuleRecord.cpp:
1164         * runtime/ArrayBufferNeuteringWatchpointSet.h:
1165         * runtime/ArrayConstructor.h:
1166         * runtime/ArrayConventions.h:
1167         * runtime/ArrayIteratorPrototype.h:
1168         * runtime/ArrayPrototype.cpp:
1169         (JSC::setLength):
1170         * runtime/AsyncFromSyncIteratorPrototype.h:
1171         * runtime/AsyncGeneratorFunctionPrototype.h:
1172         * runtime/AsyncGeneratorPrototype.h:
1173         * runtime/AsyncIteratorPrototype.h:
1174         * runtime/AtomicsObject.cpp:
1175         * runtime/BigIntConstructor.h:
1176         * runtime/BigIntPrototype.h:
1177         * runtime/BooleanPrototype.h:
1178         * runtime/ClonedArguments.h:
1179         * runtime/CodeCache.h:
1180         * runtime/ControlFlowProfiler.h:
1181         * runtime/CustomGetterSetter.h:
1182         * runtime/DateConstructor.h:
1183         * runtime/DatePrototype.h:
1184         * runtime/DefinePropertyAttributes.h:
1185         * runtime/ErrorPrototype.h:
1186         * runtime/EvalExecutable.h:
1187         * runtime/Exception.h:
1188         * runtime/ExceptionHelpers.cpp:
1189         (JSC::invalidParameterInSourceAppender):
1190         (JSC::invalidParameterInstanceofSourceAppender):
1191         * runtime/ExceptionHelpers.h:
1192         * runtime/ExecutableBase.h:
1193         * runtime/FunctionExecutable.h:
1194         * runtime/FunctionRareData.h:
1195         * runtime/GeneratorPrototype.h:
1196         * runtime/GenericArguments.h:
1197         * runtime/GenericOffset.h:
1198         * runtime/GetPutInfo.h:
1199         * runtime/GetterSetter.h:
1200         * runtime/GlobalExecutable.h:
1201         * runtime/Identifier.h:
1202         * runtime/InspectorInstrumentationObject.h:
1203         * runtime/InternalFunction.h:
1204         * runtime/IntlCollatorConstructor.h:
1205         * runtime/IntlCollatorPrototype.h:
1206         * runtime/IntlDateTimeFormatConstructor.h:
1207         * runtime/IntlDateTimeFormatPrototype.h:
1208         * runtime/IntlNumberFormatConstructor.h:
1209         * runtime/IntlNumberFormatPrototype.h:
1210         * runtime/IntlObject.h:
1211         * runtime/IntlPluralRulesConstructor.h:
1212         * runtime/IntlPluralRulesPrototype.h:
1213         * runtime/IteratorPrototype.h:
1214         * runtime/JSArray.cpp:
1215         (JSC::JSArray::tryCreateUninitializedRestricted):
1216         * runtime/JSArray.h:
1217         * runtime/JSArrayBuffer.h:
1218         * runtime/JSArrayBufferView.h:
1219         * runtime/JSBigInt.h:
1220         * runtime/JSCJSValue.h:
1221         * runtime/JSCell.h:
1222         * runtime/JSCustomGetterSetterFunction.h:
1223         * runtime/JSDataView.h:
1224         * runtime/JSDataViewPrototype.h:
1225         * runtime/JSDestructibleObject.h:
1226         * runtime/JSFixedArray.h:
1227         * runtime/JSGenericTypedArrayView.h:
1228         * runtime/JSGlobalLexicalEnvironment.h:
1229         * runtime/JSGlobalObject.h:
1230         * runtime/JSImmutableButterfly.h:
1231         * runtime/JSInternalPromiseConstructor.h:
1232         * runtime/JSInternalPromiseDeferred.h:
1233         * runtime/JSInternalPromisePrototype.h:
1234         * runtime/JSLexicalEnvironment.h:
1235         * runtime/JSModuleEnvironment.h:
1236         * runtime/JSModuleLoader.h:
1237         * runtime/JSModuleNamespaceObject.h:
1238         * runtime/JSNonDestructibleProxy.h:
1239         * runtime/JSONObject.cpp:
1240         * runtime/JSONObject.h:
1241         * runtime/JSObject.h:
1242         * runtime/JSPromiseConstructor.h:
1243         * runtime/JSPromiseDeferred.h:
1244         * runtime/JSPromisePrototype.h:
1245         * runtime/JSPropertyNameEnumerator.h:
1246         * runtime/JSProxy.h:
1247         * runtime/JSScope.h:
1248         * runtime/JSScriptFetchParameters.h:
1249         * runtime/JSScriptFetcher.h:
1250         * runtime/JSSegmentedVariableObject.h:
1251         * runtime/JSSourceCode.h:
1252         * runtime/JSString.cpp:
1253         * runtime/JSString.h:
1254         * runtime/JSSymbolTableObject.h:
1255         * runtime/JSTemplateObjectDescriptor.h:
1256         * runtime/JSTypeInfo.h:
1257         * runtime/MapPrototype.h:
1258         * runtime/MinimumReservedZoneSize.h:
1259         * runtime/ModuleProgramExecutable.h:
1260         * runtime/NativeExecutable.h:
1261         * runtime/NativeFunction.h:
1262         * runtime/NativeStdFunctionCell.h:
1263         * runtime/NumberConstructor.h:
1264         * runtime/NumberPrototype.h:
1265         * runtime/ObjectConstructor.h:
1266         * runtime/ObjectPrototype.h:
1267         * runtime/ProgramExecutable.h:
1268         * runtime/PromiseDeferredTimer.cpp:
1269         * runtime/PropertyMapHashTable.h:
1270         * runtime/PropertyNameArray.h:
1271         (JSC::PropertyNameArray::add):
1272         * runtime/PrototypeKey.h:
1273         * runtime/ProxyConstructor.h:
1274         * runtime/ProxyObject.cpp:
1275         (JSC::ProxyObject::performGetOwnPropertyNames):
1276         * runtime/ProxyRevoke.h:
1277         * runtime/ReflectObject.h:
1278         * runtime/RegExp.h:
1279         * runtime/RegExpCache.h:
1280         * runtime/RegExpConstructor.h:
1281         * runtime/RegExpKey.h:
1282         * runtime/RegExpObject.h:
1283         * runtime/RegExpPrototype.h:
1284         * runtime/RegExpStringIteratorPrototype.h:
1285         * runtime/SamplingProfiler.cpp:
1286         * runtime/ScopedArgumentsTable.h:
1287         * runtime/ScriptExecutable.h:
1288         * runtime/SetPrototype.h:
1289         * runtime/SmallStrings.h:
1290         * runtime/SparseArrayValueMap.h:
1291         * runtime/StringConstructor.h:
1292         * runtime/StringIteratorPrototype.h:
1293         * runtime/StringObject.h:
1294         * runtime/StringPrototype.h:
1295         * runtime/Structure.h:
1296         * runtime/StructureChain.h:
1297         * runtime/StructureRareData.h:
1298         * runtime/StructureTransitionTable.h:
1299         * runtime/Symbol.h:
1300         * runtime/SymbolConstructor.h:
1301         * runtime/SymbolPrototype.h:
1302         * runtime/SymbolTable.h:
1303         * runtime/TemplateObjectDescriptor.h:
1304         * runtime/TypeProfiler.cpp:
1305         * runtime/TypeProfiler.h:
1306         * runtime/TypeProfilerLog.cpp:
1307         * runtime/VarOffset.h:
1308         * testRegExp.cpp:
1309         * tools/HeapVerifier.cpp:
1310         (JSC::HeapVerifier::checkIfRecorded):
1311         * tools/JSDollarVM.cpp:
1312         * wasm/WasmB3IRGenerator.cpp:
1313         * wasm/WasmBBQPlan.cpp:
1314         * wasm/WasmFaultSignalHandler.cpp:
1315         * wasm/WasmFunctionParser.h:
1316         * wasm/WasmOMGForOSREntryPlan.cpp:
1317         * wasm/WasmOMGPlan.cpp:
1318         * wasm/WasmPlan.cpp:
1319         * wasm/WasmSignature.cpp:
1320         * wasm/WasmSignature.h:
1321         * wasm/WasmWorklist.cpp:
1322         * wasm/js/JSWebAssembly.h:
1323         * wasm/js/JSWebAssemblyCodeBlock.h:
1324         * wasm/js/WebAssemblyCompileErrorConstructor.h:
1325         * wasm/js/WebAssemblyCompileErrorPrototype.h:
1326         * wasm/js/WebAssemblyFunction.h:
1327         * wasm/js/WebAssemblyInstanceConstructor.h:
1328         * wasm/js/WebAssemblyInstancePrototype.h:
1329         * wasm/js/WebAssemblyLinkErrorConstructor.h:
1330         * wasm/js/WebAssemblyLinkErrorPrototype.h:
1331         * wasm/js/WebAssemblyMemoryConstructor.h:
1332         * wasm/js/WebAssemblyMemoryPrototype.h:
1333         * wasm/js/WebAssemblyModuleConstructor.h:
1334         * wasm/js/WebAssemblyModulePrototype.h:
1335         * wasm/js/WebAssemblyRuntimeErrorConstructor.h:
1336         * wasm/js/WebAssemblyRuntimeErrorPrototype.h:
1337         * wasm/js/WebAssemblyTableConstructor.h:
1338         * wasm/js/WebAssemblyTablePrototype.h:
1339         * wasm/js/WebAssemblyToJSCallee.h:
1340         * yarr/Yarr.h:
1341         * yarr/YarrParser.h:
1342         * yarr/generateYarrCanonicalizeUnicode:
1343
1344 2019-09-17  Yusuke Suzuki  <ysuzuki@apple.com>
1345
1346         Follow-up after String.codePointAt optimization
1347         https://bugs.webkit.org/show_bug.cgi?id=201889
1348
1349         Reviewed by Saam Barati.
1350
1351         Follow-up after string.codePointAt DFG / FTL optimizations,
1352
1353         1. Gracefully accept arguments more than expected for intrinsics
1354         2. Check BadType in String.codePointAt, String.charAt, and String.charCodeAt.
1355
1356         * dfg/DFGByteCodeParser.cpp:
1357         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1358
1359 2019-09-17  Tadeu Zagallo  <tzagallo@apple.com>
1360
1361         Change WebAssembly calling conventions
1362         https://bugs.webkit.org/show_bug.cgi?id=201799
1363
1364         Reviewed by Saam Barati.
1365
1366         Currently, the Wasm::Callee writes itself to CallFrameSlot::callee. However, this won't work when
1367         we have the Wasm interpreter, since we need the callee in order to know which function are we executing.
1368         This patch changes the calling conventions in preparation for the interpreter, so that the caller
1369         becomes responsible for writing the callee into the call frame.
1370         However, there are exceptions to this rule: stubs can still write to the callee slot, since they are individually
1371         generated and will still be present in the interpreter. We keep this design to avoid emitting unnecessary
1372         code when we know statically who is the callee:
1373         - Caller writes to call frame: intra-module direct wasm calls, indirect wasm calls, JS-to-wasm stub (new frame), JS-to-wasm IC.
1374         - Callee writes to call frame: inter-module wasm-to-wasm stub, JS-to-wasm stub (callee frame), wasm-to-JS stub, OMG osr entry
1375
1376         Additionally, this patch also changes it so that the callee keeps track of its callers, instead of having a global mapping
1377         of calls in the Wasm::CodeBlock. This makes it easier to repatch all callers of a given Callee when it tiers up.
1378
1379         * CMakeLists.txt:
1380         * JavaScriptCore.xcodeproj/project.pbxproj:
1381         * wasm/WasmAirIRGenerator.cpp:
1382         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1383         (JSC::Wasm::AirIRGenerator::addCall):
1384         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1385         (JSC::Wasm::parseAndCompileAir):
1386         * wasm/WasmAirIRGenerator.h:
1387         * wasm/WasmB3IRGenerator.cpp:
1388         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1389         (JSC::Wasm::B3IRGenerator::addCall):
1390         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1391         (JSC::Wasm::parseAndCompile):
1392         * wasm/WasmB3IRGenerator.h:
1393         * wasm/WasmBBQPlan.cpp:
1394         (JSC::Wasm::BBQPlan::BBQPlan):
1395         (JSC::Wasm::BBQPlan::prepare):
1396         (JSC::Wasm::BBQPlan::compileFunctions):
1397         (JSC::Wasm::BBQPlan::complete):
1398         * wasm/WasmBBQPlan.h:
1399         * wasm/WasmBBQPlanInlines.h:
1400         (JSC::Wasm::BBQPlan::initializeCallees):
1401         * wasm/WasmBinding.cpp:
1402         (JSC::Wasm::wasmToWasm):
1403         * wasm/WasmCallee.cpp:
1404         (JSC::Wasm::Callee::Callee):
1405         (JSC::Wasm::repatchMove):
1406         (JSC::Wasm::repatchCall):
1407         (JSC::Wasm::BBQCallee::addCaller):
1408         (JSC::Wasm::BBQCallee::addAndLinkCaller):
1409         (JSC::Wasm::BBQCallee::repatchCallers):
1410         * wasm/WasmCallee.h:
1411         (JSC::Wasm::Callee::entrypoint):
1412         (JSC::Wasm::Callee::code const):
1413         (JSC::Wasm::Callee::calleeSaveRegisters):
1414         * wasm/WasmCallingConvention.h:
1415         (JSC::Wasm::CallingConvention::setupFrameInPrologue const):
1416         * wasm/WasmCodeBlock.cpp:
1417         (JSC::Wasm::CodeBlock::CodeBlock):
1418         * wasm/WasmCodeBlock.h:
1419         (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
1420         (JSC::Wasm::CodeBlock::wasmBBQCalleeFromFunctionIndexSpace):
1421         (JSC::Wasm::CodeBlock::entrypointLoadLocationFromFunctionIndexSpace):
1422         (JSC::Wasm::CodeBlock::boxedCalleeLoadLocationFromFunctionIndexSpace):
1423         * wasm/WasmEmbedder.h:
1424         * wasm/WasmFormat.h:
1425         (JSC::Wasm::WasmToWasmImportableFunction::offsetOfBoxedCalleeLoadLocation):
1426         * wasm/WasmInstance.h:
1427         (JSC::Wasm::Instance::offsetOfBoxedCalleeLoadLocation):
1428         * wasm/WasmOMGForOSREntryPlan.cpp:
1429         (JSC::Wasm::OMGForOSREntryPlan::OMGForOSREntryPlan):
1430         (JSC::Wasm::OMGForOSREntryPlan::work):
1431         * wasm/WasmOMGForOSREntryPlan.h:
1432         * wasm/WasmOMGPlan.cpp:
1433         (JSC::Wasm::OMGPlan::OMGPlan):
1434         (JSC::Wasm::OMGPlan::work):
1435         * wasm/WasmOMGPlan.h:
1436         * wasm/WasmOperations.cpp:
1437         (JSC::Wasm::triggerOMGReplacementCompile):
1438         (JSC::Wasm::doOSREntry):
1439         (JSC::Wasm::triggerOSREntryNow):
1440         * wasm/js/JSToWasm.cpp:
1441         (JSC::Wasm::createJSToWasmWrapper):
1442         * wasm/js/JSToWasm.h:
1443         * wasm/js/WebAssemblyFunction.cpp:
1444         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1445         (JSC::WebAssemblyFunction::create):
1446         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1447         * wasm/js/WebAssemblyFunction.h:
1448         * wasm/js/WebAssemblyModuleRecord.cpp:
1449         (JSC::WebAssemblyModuleRecord::link):
1450         (JSC::WebAssemblyModuleRecord::evaluate):
1451         * wasm/js/WebAssemblyWrapperFunction.cpp:
1452         (JSC::WebAssemblyWrapperFunction::create):
1453
1454 2019-09-17  Yusuke Suzuki  <ysuzuki@apple.com>
1455
1456         [JSC] CheckArray+NonArray is not filtering out Array in AI
1457         https://bugs.webkit.org/show_bug.cgi?id=201857
1458         <rdar://problem/54194820>
1459
1460         Reviewed by Keith Miller.
1461
1462         The code of DFG::ArrayMode::alreadyChecked is different from SpeculativeJIT's CheckArray / CheckStructure.
1463         While we assume CheckArray+NonArray ensures it only passes non-array inputs, DFG::ArrayMode::alreadyChecked
1464         accepts arrays too. So CheckArray+NonArray is removed in AI if the input is proven that it is an array.
1465         This patch aligns DFG::ArrayMode::alreadyChecked to the checks done at runtime.
1466
1467         * dfg/DFGArrayMode.cpp:
1468         (JSC::DFG::ArrayMode::alreadyChecked const):
1469
1470 2019-09-17  Saam Barati  <sbarati@apple.com>
1471
1472         CheckArray on DirectArguments/ScopedArguments does not filter out slow put array storage
1473         https://bugs.webkit.org/show_bug.cgi?id=201853
1474         <rdar://problem/53805461>
1475
1476         Reviewed by Yusuke Suzuki.
1477
1478         We were claiming CheckArray for ScopedArguments/DirectArguments was filtering
1479         out SlowPutArrayStorage. It does no such thing. We just check that the object
1480         is either ScopedArguments/DirectArguments.
1481
1482         * dfg/DFGArrayMode.h:
1483         (JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
1484         (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes const):
1485         (JSC::DFG::ArrayMode::arrayModesWithIndexingShape const): Deleted.
1486
1487 2019-09-16  Tadeu Zagallo  <tzagallo@apple.com>
1488
1489         Wasm StreamingParser should validate that number of functions matches number of declarations
1490         https://bugs.webkit.org/show_bug.cgi?id=201850
1491         <rdar://problem/55290186>
1492
1493         Reviewed by Yusuke Suzuki.
1494
1495         Currently, when parsing the code section, we check that the number of functions matches the number
1496         of declarations in the function section. However, that check is never performed if the module does
1497         not have a code section. To fix that, we perform the check again in StreamingParser::finalize.
1498
1499         * wasm/WasmStreamingParser.cpp:
1500         (JSC::Wasm::StreamingParser::finalize):
1501
1502 2019-09-16  Michael Saboff  <msaboff@apple.com>
1503
1504         [JSC] Perform check again when we found non-BMP characters
1505         https://bugs.webkit.org/show_bug.cgi?id=201647
1506
1507         Reviewed by Yusuke Suzuki.
1508
1509         We need to check for end of input for non-BMP characters when matching a character class that contains
1510         both BMP and non-BMP characters.  In advanceIndexAfterCharacterClassTermMatch() we were checking for
1511         end of input for both BMP and non-BMP characters.  For BMP characters, this check is redundant.
1512         After moving the check to after the "is BMP check", we need to decrement index after reaching the failure
1513         label to back out the index++ for the first surrogate of the non-BMP character.
1514
1515         Added the same kind of check in generateCharacterClassOnce().  In that case, we have pre-checked the
1516         first character (surrogate) for a non-BMP codepoint, so we just need to check for end of input before
1517         we increment for the second surrogate.
1518
1519         While writing tests, I found an off by one error in backtrackCharacterClassGreedy() and changed the
1520         loop to check the count at loop top instead of loop bottom.
1521
1522         * yarr/YarrJIT.cpp:
1523         (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
1524         (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
1525         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
1526         (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
1527         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
1528
1529 2019-09-16  Ross Kirsling  <ross.kirsling@sony.com>
1530
1531         [JSC] Add missing syntax errors for await in function parameter default expressions
1532         https://bugs.webkit.org/show_bug.cgi?id=201615
1533
1534         Reviewed by Darin Adler.
1535
1536         This patch rectifies two oversights:
1537           1. We were prohibiting `async function f(x = (await) => {}) {}` but not `async function f(x = await => {}) {}`
1538              (and likewise for async arrow functions).
1539           2. We were not prohibiting `(x = await => {}) => {}` in an async context
1540              (regardless of parentheses, but note that this one *only* applies to arrow functions).
1541
1542         * parser/Parser.cpp:
1543         (JSC::Parser<LexerType>::isArrowFunctionParameters): Fix case (1).
1544         (JSC::Parser<LexerType>::parseFunctionInfo): Fix case (2).
1545         (JSC::Parser<LexerType>::parseAwaitExpression): Convert unfailing check into an ASSERT.
1546         (JSC::Parser<LexerType>::parsePrimaryExpression): Adjust error message for case (2).
1547
1548 2019-09-16  Tadeu Zagallo  <tzagallo@apple.com>
1549
1550         SamplingProfiler should hold API lock before reporting results
1551         https://bugs.webkit.org/show_bug.cgi?id=201829
1552
1553         Reviewed by Yusuke Suzuki.
1554
1555         Right now, the SamplingProfiler crashes in debug builds when trying
1556         report results if it finds a JSFunction on the stack that doesn't have
1557         RareData. It tries to allocate the function's rare data when we call
1558         getOwnPropertySlot in order to get the function's name, but that fails
1559         because we are not holding the VM's API lock. We fix it by just holding
1560         the lock before reporting the results.
1561
1562         * runtime/SamplingProfiler.cpp:
1563         (JSC::SamplingProfiler::reportDataToOptionFile):
1564
1565 2019-09-16  David Kilzer  <ddkilzer@apple.com>
1566
1567         [JSC] REGRESSION (r248938): Leak of uint32_t arrays in testFastForwardCopy32()
1568         <https://webkit.org/b/201804>
1569
1570         Reviewed by Saam Barati.
1571
1572         * b3/testb3_8.cpp:
1573         (testFastForwardCopy32): Allocate arrays using
1574         WTF::makeUniqueArray<uint32_t> to fix leaks caused by continue
1575         statements.
1576
1577 2019-09-16  Saam Barati  <sbarati@apple.com>
1578
1579         JSObject::putInlineSlow should not ignore "__proto__" for Proxy
1580         https://bugs.webkit.org/show_bug.cgi?id=200386
1581         <rdar://problem/53854946>
1582
1583         Reviewed by Yusuke Suzuki.
1584
1585         We used to ignore '__proto__' in putInlineSlow when the object in question
1586         was Proxy. There is no reason for this, and it goes against the spec. So
1587         I've removed that condition. This also has the effect that it fixes an
1588         assertion firing inside our inline caching code which dictates that for a
1589         property replace that the base value's structure must be equal to the
1590         structure when we grabbed the structure prior to the put operation.
1591         The old code caused a weird edge case where we broke this invariant.
1592
1593         * runtime/JSObject.cpp:
1594         (JSC::JSObject::putInlineSlow):
1595
1596 2019-09-15  David Kilzer  <ddkilzer@apple.com>
1597
1598         Leak of NSMapTable in -[JSVirtualMachine addManagedReference:withOwner:]
1599         <https://webkit.org/b/201803>
1600
1601         Reviewed by Dan Bernstein.
1602
1603         * API/JSVirtualMachine.mm:
1604         (-[JSVirtualMachine addManagedReference:withOwner:]): Use
1605         RetainPtr<> to fix the leak.
1606
1607 2019-09-14  Yusuke Suzuki  <ysuzuki@apple.com>
1608
1609         Retire x86 32bit JIT support
1610         https://bugs.webkit.org/show_bug.cgi?id=201790
1611
1612         Reviewed by Mark Lam.
1613
1614         Now, Xcode no longer has ability to build 32bit binary, so we cannot even test it on macOS.
1615         Fedora stops shipping x86 32bit kernel. Our x86/x86_64 JIT requires SSE2, and so such relatively modern CPUs
1616         can use JIT by switching x86 to x86_64. And these CPUs are modern enough to run CLoop at high speed.
1617         WebKit already disabled x86 JIT by default while the implementation exists. So literary, it is not tested.
1618
1619         While x86 32bit becomes less useful, x86 32bit JIT backend is very complicated and is being a major maintenance burden.
1620         This is due to very few # of registers. Which scatters a lot of isX86 / CPU(X86) in Baseline, DFG, and Yarr.
1621
1622         This patch retires x86 JIT support from JavaScriptCore and CSS JIT. We still keep MacroAssembler and GPRInfo / FPRInfo,
1623         MachineContext information since they are useful even though JIT is not supported.
1624
1625         * dfg/DFGArrayMode.cpp:
1626         (JSC::DFG::ArrayMode::refine const):
1627         * dfg/DFGByteCodeParser.cpp:
1628         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1629         (JSC::DFG::ByteCodeParser::parseBlock):
1630         * dfg/DFGFixupPhase.cpp:
1631         (JSC::DFG::FixupPhase::fixupNode):
1632         * dfg/DFGJITCompiler.cpp:
1633         (JSC::DFG::JITCompiler::compileExceptionHandlers):
1634         * dfg/DFGOSRExitCompilerCommon.cpp:
1635         (JSC::DFG::osrWriteBarrier):
1636         * dfg/DFGSpeculativeJIT.cpp:
1637         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1638         (JSC::DFG::SpeculativeJIT::compileArithMod):
1639         (JSC::DFG::SpeculativeJIT::compileCreateRest):
1640         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
1641         * dfg/DFGSpeculativeJIT.h:
1642         * dfg/DFGSpeculativeJIT32_64.cpp:
1643         (JSC::DFG::SpeculativeJIT::emitCall):
1644         (JSC::DFG::SpeculativeJIT::compile):
1645         * dfg/DFGThunks.cpp:
1646         (JSC::DFG::osrExitGenerationThunkGenerator):
1647         * ftl/FTLThunks.cpp:
1648         (JSC::FTL::slowPathCallThunkGenerator):
1649         * jit/AssemblyHelpers.cpp:
1650         (JSC::AssemblyHelpers::callExceptionFuzz):
1651         (JSC::AssemblyHelpers::debugCall):
1652         * jit/AssemblyHelpers.h:
1653         (JSC::AssemblyHelpers::emitComputeButterflyIndexingMask):
1654         * jit/CCallHelpers.h:
1655         (JSC::CCallHelpers::setupArgumentsImpl):
1656         (JSC::CCallHelpers::prepareForTailCallSlow):
1657         * jit/CallFrameShuffler.cpp:
1658         (JSC::CallFrameShuffler::prepareForTailCall):
1659         * jit/JIT.cpp:
1660         (JSC::JIT::privateCompileExceptionHandlers):
1661         * jit/JITArithmetic32_64.cpp:
1662         (JSC::JIT::emit_op_mod):
1663         (JSC::JIT::emitSlow_op_mod):
1664         * jit/SlowPathCall.h:
1665         (JSC::JITSlowPathCall::call):
1666         * jit/ThunkGenerators.cpp:
1667         (JSC::nativeForGenerator):
1668         (JSC::arityFixupGenerator):
1669         * wasm/WasmAirIRGenerator.cpp:
1670         (JSC::Wasm::AirIRGenerator::emitModOrDiv):
1671         * yarr/YarrJIT.cpp:
1672         (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
1673         (JSC::Yarr::YarrGenerator::generateEnter):
1674         (JSC::Yarr::YarrGenerator::generateReturn):
1675         (JSC::Yarr::YarrGenerator::compile):
1676         * yarr/YarrJIT.h:
1677
1678 2019-09-13  Mark Lam  <mark.lam@apple.com>
1679
1680         jsc -d stopped working.
1681         https://bugs.webkit.org/show_bug.cgi?id=201787
1682
1683         Reviewed by Joseph Pecoraro.
1684
1685         The reason is because, in this case, the jsc shell is trying to set an option
1686         after the VM has been instantiated.  The fix is simply to move all options
1687         initialization before the VM is instantiated.
1688
1689         * jsc.cpp:
1690         (runWithOptions):
1691         (jscmain):
1692
1693 2019-09-13  Mark Lam  <mark.lam@apple.com>
1694
1695         watchOS requires PageSize alignment of 16K for JSC::Config.
1696         https://bugs.webkit.org/show_bug.cgi?id=201786
1697         <rdar://problem/55357890>
1698
1699         Reviewed by Yusuke Suzuki.
1700
1701         * runtime/JSCConfig.h:
1702
1703 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
1704
1705         Unreviewed, follow-up fix after r249842
1706         https://bugs.webkit.org/show_bug.cgi?id=201750
1707
1708         Michael reviewed this offline. When performing nearCall, we need to invalidate cache registers.
1709
1710         * assembler/MacroAssemblerARM64.h:
1711         (JSC::MacroAssemblerARM64::nearCall):
1712         (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
1713
1714 2019-09-13  Alexey Shvayka  <shvaikalesh@gmail.com>
1715
1716         Date.prototype.toJSON does not execute steps 1-2
1717         https://bugs.webkit.org/show_bug.cgi?id=105282
1718
1719         Reviewed by Ross Kirsling.
1720
1721         According to https://tc39.es/ecma262/#sec-built-in-function-objects, built-in methods must be
1722         strict mode functions. Before this change, `this` value in Date.prototype.toJSON was resolved
1723         using sloppy mode semantics, resulting in `toISOString` being called on global object if `this`
1724         value equals `null` or `undefined`.
1725
1726         * runtime/DatePrototype.cpp:
1727         (JSC::dateProtoFuncToJSON): Resolve thisValue using strict semantics and simplify std::isfinite check.
1728
1729 2019-09-13  Mark Lam  <mark.lam@apple.com>
1730
1731         performJITMemcpy() should do its !Gigacage assertion on exit.
1732         https://bugs.webkit.org/show_bug.cgi?id=201780
1733         <rdar://problem/55354867>
1734
1735         Reviewed by Robin Morisset.
1736
1737         Re-doing previous fix.
1738
1739         * jit/ExecutableAllocator.h:
1740         (JSC::performJITMemcpy):
1741         (JSC::GigacageAssertScope::GigacageAssertScope): Deleted.
1742         (JSC::GigacageAssertScope::~GigacageAssertScope): Deleted.
1743
1744 2019-09-13  Mark Lam  <mark.lam@apple.com>
1745
1746         performJITMemcpy() should do its !Gigacage assertion on exit.
1747         https://bugs.webkit.org/show_bug.cgi?id=201780
1748         <rdar://problem/55354867>
1749
1750         Reviewed by Robin Morisset.
1751
1752         * jit/ExecutableAllocator.h:
1753         (JSC::GigacageAssertScope::GigacageAssertScope):
1754         (JSC::GigacageAssertScope::~GigacageAssertScope):
1755         (JSC::performJITMemcpy):
1756
1757 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
1758
1759         [JSC] Micro-optimize YarrJIT's surrogate pair handling
1760         https://bugs.webkit.org/show_bug.cgi?id=201750
1761
1762         Reviewed by Michael Saboff.
1763
1764         Optimize sequence of machine code used to get code-point with unicode flag.
1765
1766         * yarr/YarrJIT.cpp:
1767         (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
1768
1769 2019-09-13  Mark Lam  <mark.lam@apple.com>
1770
1771         We should assert $vm is enabled on entry and exit in its functions.
1772         https://bugs.webkit.org/show_bug.cgi?id=201762
1773         <rdar://problem/55338742>
1774
1775         Rubber-stamped by Michael Saboff.
1776
1777         1. Also do the same for FunctionOverrides.
1778         2. Added the DollarVMAssertScope and FunctionOverridesAssertScope to achieve this.
1779         3. Also added assertions to lambda functions in $vm.
1780
1781         * tools/FunctionOverrides.cpp:
1782         (JSC::FunctionOverridesAssertScope::FunctionOverridesAssertScope):
1783         (JSC::FunctionOverridesAssertScope::~FunctionOverridesAssertScope):
1784         (JSC::FunctionOverrides::overrides):
1785         (JSC::FunctionOverrides::FunctionOverrides):
1786         (JSC::FunctionOverrides::reinstallOverrides):
1787         (JSC::initializeOverrideInfo):
1788         (JSC::FunctionOverrides::initializeOverrideFor):
1789         (JSC::parseClause):
1790         (JSC::FunctionOverrides::parseOverridesInFile):
1791         * tools/JSDollarVM.cpp:
1792         (JSC::JSDollarVMCallFrame::JSDollarVMCallFrame):
1793         (JSC::JSDollarVMCallFrame::createStructure):
1794         (JSC::JSDollarVMCallFrame::create):
1795         (JSC::JSDollarVMCallFrame::finishCreation):
1796         (JSC::JSDollarVMCallFrame::addProperty):
1797         (JSC::Element::Element):
1798         (JSC::Element::create):
1799         (JSC::Element::visitChildren):
1800         (JSC::Element::createStructure):
1801         (JSC::Root::Root):
1802         (JSC::Root::setElement):
1803         (JSC::Root::create):
1804         (JSC::Root::createStructure):
1805         (JSC::Root::visitChildren):
1806         (JSC::SimpleObject::SimpleObject):
1807         (JSC::SimpleObject::create):
1808         (JSC::SimpleObject::visitChildren):
1809         (JSC::SimpleObject::createStructure):
1810         (JSC::ImpureGetter::ImpureGetter):
1811         (JSC::ImpureGetter::createStructure):
1812         (JSC::ImpureGetter::create):
1813         (JSC::ImpureGetter::finishCreation):
1814         (JSC::ImpureGetter::getOwnPropertySlot):
1815         (JSC::ImpureGetter::visitChildren):
1816         (JSC::CustomGetter::CustomGetter):
1817         (JSC::CustomGetter::createStructure):
1818         (JSC::CustomGetter::create):
1819         (JSC::CustomGetter::getOwnPropertySlot):
1820         (JSC::CustomGetter::customGetter):
1821         (JSC::CustomGetter::customGetterAcessor):
1822         (JSC::RuntimeArray::create):
1823         (JSC::RuntimeArray::destroy):
1824         (JSC::RuntimeArray::getOwnPropertySlot):
1825         (JSC::RuntimeArray::getOwnPropertySlotByIndex):
1826         (JSC::RuntimeArray::createPrototype):
1827         (JSC::RuntimeArray::createStructure):
1828         (JSC::RuntimeArray::finishCreation):
1829         (JSC::RuntimeArray::RuntimeArray):
1830         (JSC::RuntimeArray::lengthGetter):
1831         (JSC::DOMJITNode::DOMJITNode):
1832         (JSC::DOMJITNode::createStructure):
1833         (JSC::DOMJITNode::checkSubClassSnippet):
1834         (JSC::DOMJITNode::create):
1835         (JSC::DOMJITGetter::DOMJITGetter):
1836         (JSC::DOMJITGetter::createStructure):
1837         (JSC::DOMJITGetter::create):
1838         (JSC::DOMJITGetter::DOMJITAttribute::slowCall):
1839         (JSC::DOMJITGetter::DOMJITAttribute::callDOMGetter):
1840         (JSC::DOMJITGetter::customGetter):
1841         (JSC::DOMJITGetter::finishCreation):
1842         (JSC::DOMJITGetterComplex::DOMJITGetterComplex):
1843         (JSC::DOMJITGetterComplex::createStructure):
1844         (JSC::DOMJITGetterComplex::create):
1845         (JSC::DOMJITGetterComplex::DOMJITAttribute::slowCall):
1846         (JSC::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
1847         (JSC::DOMJITGetterComplex::functionEnableException):
1848         (JSC::DOMJITGetterComplex::customGetter):
1849         (JSC::DOMJITGetterComplex::finishCreation):
1850         (JSC::DOMJITFunctionObject::DOMJITFunctionObject):
1851         (JSC::DOMJITFunctionObject::createStructure):
1852         (JSC::DOMJITFunctionObject::create):
1853         (JSC::DOMJITFunctionObject::functionWithTypeCheck):
1854         (JSC::DOMJITFunctionObject::functionWithoutTypeCheck):
1855         (JSC::DOMJITFunctionObject::checkSubClassSnippet):
1856         (JSC::DOMJITFunctionObject::finishCreation):
1857         (JSC::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
1858         (JSC::DOMJITCheckSubClassObject::createStructure):
1859         (JSC::DOMJITCheckSubClassObject::create):
1860         (JSC::DOMJITCheckSubClassObject::functionWithTypeCheck):
1861         (JSC::DOMJITCheckSubClassObject::functionWithoutTypeCheck):
1862         (JSC::DOMJITCheckSubClassObject::finishCreation):
1863         (JSC::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
1864         (JSC::DOMJITGetterBaseJSObject::createStructure):
1865         (JSC::DOMJITGetterBaseJSObject::create):
1866         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
1867         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
1868         (JSC::DOMJITGetterBaseJSObject::customGetter):
1869         (JSC::DOMJITGetterBaseJSObject::finishCreation):
1870         (JSC::JSTestCustomGetterSetter::JSTestCustomGetterSetter):
1871         (JSC::JSTestCustomGetterSetter::create):
1872         (JSC::JSTestCustomGetterSetter::createStructure):
1873         (JSC::customSetAccessor):
1874         (JSC::customSetValue):
1875         (JSC::JSTestCustomGetterSetter::finishCreation):
1876         (JSC::Element::handleOwner):
1877         (JSC::Element::finishCreation):
1878         (JSC::WasmStreamingParser::WasmStreamingParser):
1879         (JSC::WasmStreamingParser::create):
1880         (JSC::WasmStreamingParser::createStructure):
1881         (JSC::WasmStreamingParser::finishCreation):
1882         (JSC::functionWasmStreamingParserAddBytes):
1883         (JSC::functionWasmStreamingParserFinalize):
1884         (JSC::functionCrash):
1885         (JSC::functionBreakpoint):
1886         (JSC::functionDFGTrue):
1887         (JSC::functionFTLTrue):
1888         (JSC::functionCpuMfence):
1889         (JSC::functionCpuRdtsc):
1890         (JSC::functionCpuCpuid):
1891         (JSC::functionCpuPause):
1892         (JSC::functionCpuClflush):
1893         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
1894         (JSC::getExecutableForFunction):
1895         (JSC::functionLLintTrue):
1896         (JSC::functionJITTrue):
1897         (JSC::functionNoInline):
1898         (JSC::functionGC):
1899         (JSC::functionEdenGC):
1900         (JSC::functionDumpSubspaceHashes):
1901         (JSC::functionCallFrame):
1902         (JSC::functionCodeBlockForFrame):
1903         (JSC::codeBlockFromArg):
1904         (JSC::functionCodeBlockFor):
1905         (JSC::functionDumpSourceFor):
1906         (JSC::functionDumpBytecodeFor):
1907         (JSC::doPrint):
1908         (JSC::functionDataLog):
1909         (JSC::functionPrint):
1910         (JSC::functionDumpCallFrame):
1911         (JSC::functionDumpStack):
1912         (JSC::functionDumpRegisters):
1913         (JSC::functionDumpCell):
1914         (JSC::functionIndexingMode):
1915         (JSC::functionInlineCapacity):
1916         (JSC::functionValue):
1917         (JSC::functionGetPID):
1918         (JSC::functionHaveABadTime):
1919         (JSC::functionIsHavingABadTime):
1920         (JSC::functionCreateGlobalObject):
1921         (JSC::functionCreateProxy):
1922         (JSC::functionCreateRuntimeArray):
1923         (JSC::functionCreateNullRopeString):
1924         (JSC::functionCreateImpureGetter):
1925         (JSC::functionCreateCustomGetterObject):
1926         (JSC::functionCreateDOMJITNodeObject):
1927         (JSC::functionCreateDOMJITGetterObject):
1928         (JSC::functionCreateDOMJITGetterComplexObject):
1929         (JSC::functionCreateDOMJITFunctionObject):
1930         (JSC::functionCreateDOMJITCheckSubClassObject):
1931         (JSC::functionCreateDOMJITGetterBaseJSObject):
1932         (JSC::functionCreateWasmStreamingParser):
1933         (JSC::functionSetImpureGetterDelegate):
1934         (JSC::functionCreateBuiltin):
1935         (JSC::functionGetPrivateProperty):
1936         (JSC::functionCreateRoot):
1937         (JSC::functionCreateElement):
1938         (JSC::functionGetElement):
1939         (JSC::functionCreateSimpleObject):
1940         (JSC::functionGetHiddenValue):
1941         (JSC::functionSetHiddenValue):
1942         (JSC::functionShadowChickenFunctionsOnStack):
1943         (JSC::functionSetGlobalConstRedeclarationShouldNotThrow):
1944         (JSC::functionFindTypeForExpression):
1945         (JSC::functionReturnTypeFor):
1946         (JSC::functionFlattenDictionaryObject):
1947         (JSC::functionDumpBasicBlockExecutionRanges):
1948         (JSC::functionHasBasicBlockExecuted):
1949         (JSC::functionBasicBlockExecutionCount):
1950         (JSC::functionEnableExceptionFuzz):
1951         (JSC::changeDebuggerModeWhenIdle):
1952         (JSC::functionEnableDebuggerModeWhenIdle):
1953         (JSC::functionDisableDebuggerModeWhenIdle):
1954         (JSC::functionDeleteAllCodeWhenIdle):
1955         (JSC::functionGlobalObjectCount):
1956         (JSC::functionGlobalObjectForObject):
1957         (JSC::functionGetGetterSetter):
1958         (JSC::functionLoadGetterFromGetterSetter):
1959         (JSC::functionCreateCustomTestGetterSetter):
1960         (JSC::functionDeltaBetweenButterflies):
1961         (JSC::functionTotalGCTime):
1962         (JSC::functionParseCount):
1963         (JSC::functionIsWasmSupported):
1964         (JSC::JSDollarVM::finishCreation):
1965         (JSC::JSDollarVM::addFunction):
1966         (JSC::JSDollarVM::addConstructibleFunction):
1967         * tools/JSDollarVM.h:
1968         (JSC::DollarVMAssertScope::DollarVMAssertScope):
1969         (JSC::DollarVMAssertScope::~DollarVMAssertScope):
1970
1971 2019-09-13  Joseph Pecoraro  <pecoraro@apple.com>
1972
1973         Web Inspector: Formatter: Pretty Print HTML resources (including inline <script>/<style>)
1974         https://bugs.webkit.org/show_bug.cgi?id=201535
1975         <rdar://problem/29119232>
1976
1977         Reviewed by Devin Rousso.
1978
1979         * debugger/Debugger.cpp:
1980         (JSC::Debugger::resolveBreakpoint):
1981         When resolving a breakpoint inside of an inline <script> we need to adjust
1982         based on the starting position of the <script> in the HTML resource.
1983
1984 2019-09-13  Yusuke Suzuki  <ysuzuki@apple.com>
1985
1986         [JSC] X86Registers.h callee-save register definition is wrong
1987         https://bugs.webkit.org/show_bug.cgi?id=201756
1988
1989         Reviewed by Mark Lam.
1990
1991         I think nobody is using X86 JIT backend, but it is simply wrong.
1992         edi and esi should be callee-save.
1993
1994         * assembler/X86Registers.h:
1995
1996 2019-09-12  Mark Lam  <mark.lam@apple.com>
1997
1998         Harden JSC against the abuse of runtime options.
1999         https://bugs.webkit.org/show_bug.cgi?id=201597
2000         <rdar://problem/55167068>
2001
2002         Reviewed by Filip Pizlo.
2003
2004         Linux parts contributed by Carlos Garcia Campos <cgarcia@igalia.com>.
2005
2006         1. Introduce a JSC::Config struct that will be protected as ReadOnly once the
2007            first VM instance is constructed.  The end of the VM constructor calls
2008            Config::permanentlyFreeze() which will make the Config ReadOnly.
2009
2010            Note: this is currently only supported for OS(DARWIN) and OS(LINUX).
2011            OS(WINDOWS) will need to implement some missing pieces before it can enable
2012            this hardening (see FIXME in JSCConfig.cpp).
2013
2014            The hardening strategy here is to put immutable global values into the Config.
2015            Any modifications that need to be made to these values must be done before the
2016            first VM instance is done instantiating.  This ensures that no script will
2017            ever run while the Config is still writable.
2018
2019            Also, the policy for this hardening is that a process is opted in by default.
2020            If there's a valid need to disable this hardening (e.g. for some test
2021            environments), the relevant process will need to opt itself out by calling
2022            Config::configureForTesting().
2023
2024            The jsc shell, WK2 UI and WebContent processes are opted in by default.
2025            Only test processes may be opt out.
2026
2027         2. Put all JSC::Options in the Config.  This enforces the invariant that options
2028            can only be changed before we instantiate a VM.  Once a VM is instantiated,
2029            the options are immutable.
2030
2031         3. Remove functionForceGCSlowPaths() from the jsc shell.  Setting
2032            Options::forceGCSlowPaths this way is no longer allowed.
2033
2034         4. Re-factored the Options code (Options.h) into:
2035            - OptionEntry.h: the data structure that stores the option values.
2036            - OptionsList.h: the list of options.
2037            - Options.h: the Options singleton object which is the interface for accessing options.
2038
2039            Renamed the JSC_OPTIONS macro to FOR_EACH_JSC_OPTION, because
2040            "FOR_EACH_JSC_OPTION(SET_OPTION_VALUE)" reads a lot better than
2041            "JSC_OPTIONS(FOR_EACH_OPTION)".
2042
2043         5. Change testapi to call Config::configureForTesting().  Parts of testapi makes
2044            use of setting options in its tests.  Hence, this hardening is disabled for
2045            testapi.
2046
2047            Note: the jsc shell does enable this hardening.
2048
2049         6. Put ExecutableAllocator's immutable globals in the Config.
2050
2051         7. RELEASE_ASSERT that restrictedOptionsEnabled in order to use the
2052            FunctionOverrides test utility.
2053
2054         8. RELEASE_ASSERT that Options::useDollarVM() is enabled in order to use the $vm.
2055
2056            We must RELEASE_ASSERT(Options::useDollarVM()) in all JSDollarVM functions
2057            that are non-trivial at an eye's glance.  This includes (but is not limited to):
2058                constructors
2059                create() factory
2060                createStructure() factory
2061                finishCreation()
2062                HOST_CALL or operation functions
2063                Constructors and methods of utility and test classes
2064
2065            The only exception are some constexpr constructors used for instantiating
2066            globals (since these must have trivial constructors) e.g. DOMJITAttribute.
2067            Instead, these constructors should always be ALWAYS_INLINE.
2068
2069         * API/glib/JSCOptions.cpp:
2070         (jscOptionsSetValue):
2071         (jscOptionsGetValue):
2072         (jsc_options_foreach):
2073         (jsc_options_get_option_group):
2074         * API/tests/testapi.c:
2075         (main):
2076         * API/tests/testapi.cpp:
2077         (configureJSCForTesting):
2078         * CMakeLists.txt:
2079         * JavaScriptCore.xcodeproj/project.pbxproj:
2080         * Sources.txt:
2081         * jit/ExecutableAllocator.cpp:
2082         (JSC::isJITEnabled):
2083         (JSC::ExecutableAllocator::setJITEnabled):
2084         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
2085         (JSC::ExecutableAllocator::isValid const):
2086         (JSC::ExecutableAllocator::underMemoryPressure):
2087         (JSC::ExecutableAllocator::memoryPressureMultiplier):
2088         (JSC::ExecutableAllocator::allocate):
2089         (JSC::ExecutableAllocator::isValidExecutableMemory):
2090         (JSC::ExecutableAllocator::getLock const):
2091         (JSC::ExecutableAllocator::committedByteCount):
2092         (JSC::ExecutableAllocator::dumpProfile):
2093         (JSC::startOfFixedExecutableMemoryPoolImpl):
2094         (JSC::endOfFixedExecutableMemoryPoolImpl):
2095         (JSC::isJITPC):
2096         (JSC::dumpJITMemory):
2097         (JSC::ExecutableAllocator::initialize):
2098         (JSC::ExecutableAllocator::singleton):
2099         * jit/ExecutableAllocator.h:
2100         (JSC::performJITMemcpy):
2101         * jsc.cpp:
2102         (GlobalObject::finishCreation):
2103         (functionJSCOptions):
2104         (jscmain):
2105         (functionForceGCSlowPaths): Deleted.
2106         * runtime/ConfigFile.cpp:
2107         (JSC::ConfigFile::parse):
2108         * runtime/InitializeThreading.cpp:
2109         (JSC::initializeThreading):
2110         * runtime/JSCConfig.cpp: Added.
2111         (JSC::Config::disableFreezingForTesting):
2112         (JSC::Config::enableRestrictedOptions):
2113         (JSC::Config::permanentlyFreeze):
2114         * runtime/JSCConfig.h: Added.
2115         (JSC::Config::configureForTesting):
2116         * runtime/JSGlobalObject.cpp:
2117         (JSC::JSGlobalObject::exposeDollarVM):
2118         * runtime/OptionEntry.h: Added.
2119         (JSC::OptionRange::operator= ):
2120         (JSC::OptionRange::rangeString const):
2121         * runtime/Options.cpp:
2122         (JSC::Options::isAvailable):
2123         (JSC::scaleJITPolicy):
2124         (JSC::Options::initialize):
2125         (JSC::Options::setOptions):
2126         (JSC::Options::setOptionWithoutAlias):
2127         (JSC::Options::setAliasedOption):
2128         (JSC::Option::dump const):
2129         (JSC::Option::operator== const):
2130         (): Deleted.
2131         (JSC::Options::enableRestrictedOptions): Deleted.
2132         * runtime/Options.h:
2133         (JSC::Option::Option):
2134         (JSC::Option::defaultOption const):
2135         (JSC::Option::boolVal):
2136         (JSC::Option::unsignedVal):
2137         (JSC::Option::doubleVal):
2138         (JSC::Option::int32Val):
2139         (JSC::Option::optionRangeVal):
2140         (JSC::Option::optionStringVal):
2141         (JSC::Option::gcLogLevelVal):
2142         (JSC::OptionRange::operator= ): Deleted.
2143         (JSC::OptionRange::rangeString const): Deleted.
2144         * runtime/OptionsList.h: Added.
2145         (JSC::countNumberOfJSCOptions):
2146         * runtime/VM.cpp:
2147         (JSC::VM::VM):
2148         * tools/FunctionOverrides.cpp:
2149         (JSC::FunctionOverrides::FunctionOverrides):
2150         (JSC::FunctionOverrides::reinstallOverrides):
2151         (JSC::FunctionOverrides::initializeOverrideFor):
2152         (JSC::FunctionOverrides::parseOverridesInFile):
2153         * tools/JSDollarVM.cpp:
2154         (JSC::JSDollarVMCallFrame::JSDollarVMCallFrame):
2155         (JSC::JSDollarVMCallFrame::createStructure):
2156         (JSC::JSDollarVMCallFrame::create):
2157         (JSC::JSDollarVMCallFrame::finishCreation):
2158         (JSC::JSDollarVMCallFrame::addProperty):
2159         (JSC::Element::Element):
2160         (JSC::Element::create):
2161         (JSC::Element::createStructure):
2162         (JSC::Root::Root):
2163         (JSC::Root::create):
2164         (JSC::Root::createStructure):
2165         (JSC::SimpleObject::SimpleObject):
2166         (JSC::SimpleObject::create):
2167         (JSC::SimpleObject::createStructure):
2168         (JSC::ImpureGetter::ImpureGetter):
2169         (JSC::ImpureGetter::createStructure):
2170         (JSC::ImpureGetter::create):
2171         (JSC::ImpureGetter::finishCreation):
2172         (JSC::ImpureGetter::getOwnPropertySlot):
2173         (JSC::CustomGetter::CustomGetter):
2174         (JSC::CustomGetter::createStructure):
2175         (JSC::CustomGetter::create):
2176         (JSC::CustomGetter::getOwnPropertySlot):
2177         (JSC::CustomGetter::customGetter):
2178         (JSC::CustomGetter::customGetterAcessor):
2179         (JSC::RuntimeArray::create):
2180         (JSC::RuntimeArray::destroy):
2181         (JSC::RuntimeArray::getOwnPropertySlot):
2182         (JSC::RuntimeArray::getOwnPropertySlotByIndex):
2183         (JSC::RuntimeArray::createPrototype):
2184         (JSC::RuntimeArray::createStructure):
2185         (JSC::RuntimeArray::finishCreation):
2186         (JSC::RuntimeArray::RuntimeArray):
2187         (JSC::RuntimeArray::lengthGetter):
2188         (JSC::DOMJITNode::DOMJITNode):
2189         (JSC::DOMJITNode::createStructure):
2190         (JSC::DOMJITNode::checkSubClassSnippet):
2191         (JSC::DOMJITNode::create):
2192         (JSC::DOMJITGetter::DOMJITGetter):
2193         (JSC::DOMJITGetter::createStructure):
2194         (JSC::DOMJITGetter::create):
2195         (JSC::DOMJITGetter::DOMJITAttribute::DOMJITAttribute):
2196         (JSC::DOMJITGetter::DOMJITAttribute::slowCall):
2197         (JSC::DOMJITGetter::DOMJITAttribute::callDOMGetter):
2198         (JSC::DOMJITGetter::customGetter):
2199         (JSC::DOMJITGetter::finishCreation):
2200         (JSC::DOMJITGetterComplex::DOMJITGetterComplex):
2201         (JSC::DOMJITGetterComplex::createStructure):
2202         (JSC::DOMJITGetterComplex::create):
2203         (JSC::DOMJITGetterComplex::DOMJITAttribute::DOMJITAttribute):
2204         (JSC::DOMJITGetterComplex::DOMJITAttribute::slowCall):
2205         (JSC::DOMJITGetterComplex::DOMJITAttribute::callDOMGetter):
2206         (JSC::DOMJITGetterComplex::functionEnableException):
2207         (JSC::DOMJITGetterComplex::customGetter):
2208         (JSC::DOMJITGetterComplex::finishCreation):
2209         (JSC::DOMJITFunctionObject::DOMJITFunctionObject):
2210         (JSC::DOMJITFunctionObject::createStructure):
2211         (JSC::DOMJITFunctionObject::create):
2212         (JSC::DOMJITFunctionObject::functionWithTypeCheck):
2213         (JSC::DOMJITFunctionObject::functionWithoutTypeCheck):
2214         (JSC::DOMJITFunctionObject::checkSubClassSnippet):
2215         (JSC::DOMJITFunctionObject::finishCreation):
2216         (JSC::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
2217         (JSC::DOMJITCheckSubClassObject::createStructure):
2218         (JSC::DOMJITCheckSubClassObject::create):
2219         (JSC::DOMJITCheckSubClassObject::functionWithTypeCheck):
2220         (JSC::DOMJITCheckSubClassObject::functionWithoutTypeCheck):
2221         (JSC::DOMJITCheckSubClassObject::finishCreation):
2222         (JSC::DOMJITGetterBaseJSObject::DOMJITGetterBaseJSObject):
2223         (JSC::DOMJITGetterBaseJSObject::createStructure):
2224         (JSC::DOMJITGetterBaseJSObject::create):
2225         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::DOMJITAttribute):
2226         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
2227         (JSC::DOMJITGetterBaseJSObject::DOMJITAttribute::callDOMGetter):
2228         (JSC::DOMJITGetterBaseJSObject::customGetter):
2229         (JSC::DOMJITGetterBaseJSObject::finishCreation):
2230         (JSC::JSTestCustomGetterSetter::JSTestCustomGetterSetter):
2231         (JSC::JSTestCustomGetterSetter::create):
2232         (JSC::JSTestCustomGetterSetter::createStructure):
2233         (JSC::customSetAccessor):
2234         (JSC::customSetValue):
2235         (JSC::JSTestCustomGetterSetter::finishCreation):
2236         (JSC::Element::handleOwner):
2237         (JSC::Element::finishCreation):
2238         (JSC::WasmStreamingParser::WasmStreamingParser):
2239         (JSC::WasmStreamingParser::create):
2240         (JSC::WasmStreamingParser::createStructure):
2241         (JSC::WasmStreamingParser::finishCreation):
2242         (JSC::functionWasmStreamingParserAddBytes):
2243         (JSC::functionWasmStreamingParserFinalize):
2244         (JSC::functionCrash):
2245         (JSC::functionBreakpoint):
2246         (JSC::functionDFGTrue):
2247         (JSC::functionFTLTrue):
2248         (JSC::functionCpuMfence):
2249         (JSC::functionCpuRdtsc):
2250         (JSC::functionCpuCpuid):
2251         (JSC::functionCpuPause):
2252         (JSC::functionCpuClflush):
2253         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2254         (JSC::getExecutableForFunction):
2255         (JSC::functionLLintTrue):
2256         (JSC::functionJITTrue):
2257         (JSC::functionNoInline):
2258         (JSC::functionGC):
2259         (JSC::functionEdenGC):
2260         (JSC::functionDumpSubspaceHashes):
2261         (JSC::functionCallFrame):
2262         (JSC::functionCodeBlockForFrame):
2263         (JSC::codeBlockFromArg):
2264         (JSC::functionCodeBlockFor):
2265         (JSC::functionDumpSourceFor):
2266         (JSC::functionDumpBytecodeFor):
2267         (JSC::doPrint):
2268         (JSC::functionDataLog):
2269         (JSC::functionPrint):
2270         (JSC::functionDumpCallFrame):
2271         (JSC::functionDumpStack):
2272         (JSC::functionDumpRegisters):
2273         (JSC::functionDumpCell):
2274         (JSC::functionIndexingMode):
2275         (JSC::functionInlineCapacity):
2276         (JSC::functionValue):
2277         (JSC::functionGetPID):
2278         (JSC::functionHaveABadTime):
2279         (JSC::functionIsHavingABadTime):
2280         (JSC::functionCreateGlobalObject):
2281         (JSC::functionCreateProxy):
2282         (JSC::functionCreateRuntimeArray):
2283         (JSC::functionCreateNullRopeString):
2284         (JSC::functionCreateImpureGetter):
2285         (JSC::functionCreateCustomGetterObject):
2286         (JSC::functionCreateDOMJITNodeObject):
2287         (JSC::functionCreateDOMJITGetterObject):
2288         (JSC::functionCreateDOMJITGetterComplexObject):
2289         (JSC::functionCreateDOMJITFunctionObject):
2290         (JSC::functionCreateDOMJITCheckSubClassObject):
2291         (JSC::functionCreateDOMJITGetterBaseJSObject):
2292         (JSC::functionCreateWasmStreamingParser):
2293         (JSC::functionSetImpureGetterDelegate):
2294         (JSC::functionCreateBuiltin):
2295         (JSC::functionGetPrivateProperty):
2296         (JSC::functionCreateRoot):
2297         (JSC::functionCreateElement):
2298         (JSC::functionGetElement):
2299         (JSC::functionCreateSimpleObject):
2300         (JSC::functionGetHiddenValue):
2301         (JSC::functionSetHiddenValue):
2302         (JSC::functionShadowChickenFunctionsOnStack):
2303         (JSC::functionSetGlobalConstRedeclarationShouldNotThrow):
2304         (JSC::functionFindTypeForExpression):
2305         (JSC::functionReturnTypeFor):
2306         (JSC::functionFlattenDictionaryObject):
2307         (JSC::functionDumpBasicBlockExecutionRanges):
2308         (JSC::functionHasBasicBlockExecuted):
2309         (JSC::functionBasicBlockExecutionCount):
2310         (JSC::functionEnableExceptionFuzz):
2311         (JSC::changeDebuggerModeWhenIdle):
2312         (JSC::functionEnableDebuggerModeWhenIdle):
2313         (JSC::functionDisableDebuggerModeWhenIdle):
2314         (JSC::functionDeleteAllCodeWhenIdle):
2315         (JSC::functionGlobalObjectCount):
2316         (JSC::functionGlobalObjectForObject):
2317         (JSC::functionGetGetterSetter):
2318         (JSC::functionLoadGetterFromGetterSetter):
2319         (JSC::functionCreateCustomTestGetterSetter):
2320         (JSC::functionDeltaBetweenButterflies):
2321         (JSC::functionTotalGCTime):
2322         (JSC::functionParseCount):
2323         (JSC::functionIsWasmSupported):
2324         (JSC::JSDollarVM::finishCreation):
2325         (JSC::JSDollarVM::addFunction):
2326         (JSC::JSDollarVM::addConstructibleFunction):
2327         * tools/JSDollarVM.h:
2328
2329 2019-09-11  Devin Rousso  <drousso@apple.com>
2330
2331         Web Inspector: Canvas: instrument WebGPUDevice instead of GPUCanvasContext
2332         https://bugs.webkit.org/show_bug.cgi?id=201650
2333
2334         Reviewed by Joseph Pecoraro.
2335
2336         Most of the actual "work" done with Web GPU actually uses a `WebGPUDevice`.
2337
2338         A `GPUCanvasContext` is basically just a display "client" of the device, and isn't even
2339         required (e.g. compute pipeline).  We should treat the `GPUCanvasContext` almost like a
2340         `-webkit-canvas` client of a `WebGPUDevice`.
2341
2342         * inspector/protocol/Canvas.json:
2343          - Add `powerPreference` key to `ContextAttributes` type.
2344          - Rename `requestCSSCanvasClientNodes` command to `requestClientNodes` for the above reason.
2345          - Rename `cssCanvasClientNodesChanged` event to `clientNodesChanged` for the above reason.
2346          - Rename `resolveCanvasContext` command to `resolveContext` since a `WebGPUDevice` isn't
2347            really a "canvas".
2348
2349 2019-09-11  Yusuke Suzuki  <ysuzuki@apple.com>
2350
2351         [JSC] Add StringCodePointAt intrinsic
2352         https://bugs.webkit.org/show_bug.cgi?id=201673
2353
2354         Reviewed by Michael Saboff.
2355
2356         JetStream2/UniPoker executes String#codePointAt frequently. We should handle it in ThunkGenerator, DFG, and FTL like we are doing so for String#charCodeAt.
2357         This patch adds these supports for String#codePointAt to get ~10% score improvement in JetStream2/UniPoker.
2358
2359         In ThunkGenerator, we add a thunk for String#codePointAt, which accelerates LLInt and Baseline. In DFG, we handle this as StringCodePointAt node, and emit
2360         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
2361         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
2362         check. This thing is just the same to the existing StringCharCodeAt mechanism.
2363
2364         * dfg/DFGAbstractInterpreterInlines.h:
2365         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2366         * dfg/DFGBackwardsPropagationPhase.cpp:
2367         (JSC::DFG::BackwardsPropagationPhase::propagate):
2368         * dfg/DFGByteCodeParser.cpp:
2369         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2370         * dfg/DFGClobberize.h:
2371         (JSC::DFG::clobberize):
2372         * dfg/DFGDoesGC.cpp:
2373         (JSC::DFG::doesGC):
2374         * dfg/DFGFixupPhase.cpp:
2375         (JSC::DFG::FixupPhase::fixupNode):
2376         * dfg/DFGNode.h:
2377         (JSC::DFG::Node::hasArrayMode):
2378         * dfg/DFGNodeType.h:
2379         * dfg/DFGPredictionPropagationPhase.cpp:
2380         * dfg/DFGSafeToExecute.h:
2381         (JSC::DFG::safeToExecute):
2382         * dfg/DFGSpeculativeJIT.h:
2383         * dfg/DFGSpeculativeJIT32_64.cpp:
2384         (JSC::DFG::SpeculativeJIT::compile):
2385         * dfg/DFGSpeculativeJIT64.cpp:
2386         (JSC::DFG::SpeculativeJIT::compile):
2387         (JSC::DFG::SpeculativeJIT::compileStringCodePointAt):
2388         * ftl/FTLCapabilities.cpp:
2389         (JSC::FTL::canCompile):
2390         * ftl/FTLLowerDFGToB3.cpp:
2391         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2392         (JSC::FTL::DFG::LowerDFGToB3::compileStringCodePointAt):
2393         * jit/JITInlines.h:
2394         (JSC::JIT::emitLoadCharacterString):
2395         * jit/ThunkGenerators.cpp:
2396         (JSC::stringGetByValGenerator):
2397         (JSC::stringCharLoad):
2398         (JSC::stringPrototypeCodePointAtThunkGenerator):
2399         * jit/ThunkGenerators.h:
2400         * runtime/Intrinsic.cpp:
2401         (JSC::intrinsicName):
2402         * runtime/Intrinsic.h:
2403         * runtime/StringPrototype.cpp:
2404         (JSC::StringPrototype::finishCreation):
2405         * runtime/VM.cpp:
2406         (JSC::thunkGeneratorForIntrinsic):
2407
2408 2019-09-11  Michael Saboff  <msaboff@apple.com>
2409
2410         JSC crashes due to stack overflow while building RegExp
2411         https://bugs.webkit.org/show_bug.cgi?id=201649
2412
2413         Reviewed by Yusuke Suzuki.
2414
2415         Check for running out of stack when we are optimizing RegExp containing BOL terms or
2416         other deep copying of disjunctions.
2417
2418         * yarr/YarrPattern.cpp:
2419         (JSC::Yarr::YarrPatternConstructor::copyDisjunction):
2420         (JSC::Yarr::YarrPatternConstructor::copyTerm):
2421         (JSC::Yarr::YarrPatternConstructor::error):
2422         (JSC::Yarr::YarrPattern::compile):
2423
2424 2019-09-11  Truitt Savell  <tsavell@apple.com>
2425
2426         Unreviewed, rolling out r249753.
2427
2428         caused inspector/canvas/shaderProgram-add-remove-webgl.html to
2429         crash on all Mac platforms.
2430
2431         Reverted changeset:
2432
2433         "Web Inspector: Canvas: instrument WebGPUDevice instead of
2434         GPUCanvasContext"
2435         https://bugs.webkit.org/show_bug.cgi?id=201650
2436         https://trac.webkit.org/changeset/249753
2437
2438 2019-09-10  Devin Rousso  <drousso@apple.com>
2439
2440         Web Inspector: Canvas: instrument WebGPUDevice instead of GPUCanvasContext
2441         https://bugs.webkit.org/show_bug.cgi?id=201650
2442
2443         Reviewed by Joseph Pecoraro.
2444
2445         Most of the actual "work" done with Web GPU actually uses a `WebGPUDevice`.
2446
2447         A `GPUCanvasContext` is basically just a display "client" of the device, and isn't even
2448         required (e.g. compute pipeline).  We should treat the `GPUCanvasContext` almost like a
2449         `-webkit-canvas` client of a `WebGPUDevice`.
2450
2451         * inspector/protocol/Canvas.json:
2452          - Add `powerPreference` key to `ContextAttributes` type.
2453          - Rename `requestCSSCanvasClientNodes` command to `requestClientNodes` for the above reason.
2454          - Rename `cssCanvasClientNodesChanged` event to `clientNodesChanged` for the above reason.
2455          - Rename `resolveCanvasContext` command to `resolveContext` since a `WebGPUDevice` isn't
2456            really a "canvas".
2457
2458 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
2459
2460         [JSC] 32bit bitwide operation with all-one (-1) is wrong in B3
2461         https://bugs.webkit.org/show_bug.cgi?id=201634
2462
2463         Reviewed by Mark Lam and Robin Morisset.
2464
2465         This patch includes two things. One is fixing 32bit bitwise operation with allOne constants. Another is fixing the existing bug in BitAnd strength reduction.
2466
2467         1. 32bit bitwise operation with allOne constants
2468
2469             Accidentally, the B3::Value is ConstInt32(-1), `value->isInt(std::numeric_limits<uint32_t>::max())` returns `false`!
2470             For example, in BitAnd strength reduction,
2471
2472                 1034             // Turn this: BitAnd(value, all-ones)
2473                 1035             // Into this: value.
2474                 1036             if ((m_value->type() == Int64 && m_value->child(1)->isInt(std::numeric_limits<uint64_t>::max()))
2475                 1037                 || (m_value->type() == Int32 && m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max()))) {
2476                 1038                 replaceWithIdentity(m_value->child(0));
2477                 1039                 break;
2478                 1040             }
2479
2480             We use `m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max())`. However, Value::isInt is,
2481
2482                 262 inline bool Value::isInt(int64_t value) const
2483                 263 {
2484                 264     return hasInt() && asInt() == value;
2485                 265 }
2486
2487             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,
2488
2489                 257 inline int64_t Value::asInt() const
2490                 258 {
2491                 259     return hasInt32() ? asInt32() : asInt64();
2492                 260 }
2493
2494             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!
2495             We should use `isInt32` and `isInt64` for bit patterns (like, operands for Bitwise opcodes).
2496
2497         2. BitAnd and BitOr strength reduction bug
2498
2499             We also fix the following optimization.
2500
2501                 // Turn this: BitAnd(Op(value, constant1), constant2)
2502                 //     where !(constant1 & constant2)
2503                 //       and Op is BitOr or BitXor
2504                 // into this: BitAnd(value, constant2)
2505
2506             Since we stop further optimization when we match `if (m_value->child(1)->hasInt())`, the following optimization is never taken.
2507
2508                 // Turn this: BitAnd(BitXor(x, allOnes), c)
2509                 // Into this: BitXor(BitOr(x, ~c), allOnes)
2510
2511             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.
2512
2513         For both, this patch adds tests. And (2) fix can be ensured that the testb3 does not crash with validate-graph option.
2514
2515         * b3/B3LowerToAir.cpp:
2516         * b3/B3ReduceStrength.cpp:
2517         * b3/testb3.h:
2518         * b3/testb3_2.cpp:
2519         (testBitAndNotNot32):
2520         (testBitAndNotImm):
2521         (testBitAndNotImm32):
2522         (testBitOrAndAndArgs32):
2523         (testBitOrAndSameArgs32):
2524         (testBitOrNotNot32):
2525         (testBitOrNotImm32):
2526         (addBitTests):
2527         * b3/testb3_3.cpp:
2528         (testBitXorAndAndArgs32):
2529         (testBitXorAndSameArgs32):
2530
2531 2019-09-10  Commit Queue  <commit-queue@webkit.org>
2532
2533         Unreviewed, rolling out r249721.
2534         https://bugs.webkit.org/show_bug.cgi?id=201667
2535
2536         Discovering existing bug (Requested by yusukesuzuki on
2537         #webkit).
2538
2539         Reverted changeset:
2540
2541         "[JSC] 32bit bitwide operation with all-one (-1) is wrong in
2542         B3"
2543         https://bugs.webkit.org/show_bug.cgi?id=201634
2544         https://trac.webkit.org/changeset/249721
2545
2546 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
2547
2548         [JSC] CodeBlock::calleeSaveRegisters should not see half-baked JITData
2549         https://bugs.webkit.org/show_bug.cgi?id=201664
2550         <rdar://problem/52126927>
2551
2552         Reviewed by Tadeu Zagallo.
2553
2554         We are hitting the crash accessing invalid-pointer as CodeBlock::calleeSaveRegisters result.
2555         This is because concurrent Baseline JIT compiler can access m_jitData without taking a lock through CodeBlock::calleeSaveRegisters.
2556         Since m_jitData can be initialized in the main thread while calling CodeBlock::calleeSaveRegisters from concurrent Baseline JIT compiler thread,
2557         we can see half-baked JITData structure which holds garbage pointers.
2558
2559         But we do not want to make CodeBlock::calleeSaveRegisters() call with CodeBlock::m_lock due to several reasons.
2560
2561         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
2562            called while taking this exact same lock, so dead-lock can happen.
2563         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
2564            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.
2565
2566         Instead of guarding CodeBlock::calleeSaveRegisters() function with CodeBlock::m_lock, this patch inserts WTF::storeStoreFence when filling m_jitData. This ensures that
2567         JITData::m_calleeSaveRegisters is initialized with nullptr when this JITData pointer is exposed to concurrent Baseline JIT compiler thread.
2568
2569         * bytecode/CodeBlock.cpp:
2570         (JSC::CodeBlock::ensureJITDataSlow):
2571
2572 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
2573
2574         [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
2575         https://bugs.webkit.org/show_bug.cgi?id=198253
2576
2577         Reviewed by Mark Lam.
2578
2579         ResultType of bitwise operation needs to include TypeMaybeNumber. TypeInt32 is something like a flag indicating the number looks like a int32.
2580         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
2581         it with Int32 ArithDiv while that div always produces double. And unnecessary OSR exit happens.
2582
2583         In this patch, we add TypeMaybeNumber to bigIntOrInt32Type correctly.
2584
2585         * parser/ResultType.h:
2586         (JSC::ResultType::bigIntOrInt32Type):
2587
2588 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
2589
2590         [JSC] 32bit bitwide operation with all-one (-1) is wrong in B3
2591         https://bugs.webkit.org/show_bug.cgi?id=201634
2592
2593         Reviewed by Mark Lam.
2594
2595         Accidentally, the B3::Value is ConstInt32(-1), `value->isInt(std::numeric_limits<uint32_t>::max())` returns `false`!
2596         For example, in BitAnd strength reduction,
2597
2598             1034             // Turn this: BitAnd(value, all-ones)
2599             1035             // Into this: value.
2600             1036             if ((m_value->type() == Int64 && m_value->child(1)->isInt(std::numeric_limits<uint64_t>::max()))
2601             1037                 || (m_value->type() == Int32 && m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max()))) {
2602             1038                 replaceWithIdentity(m_value->child(0));
2603             1039                 break;
2604             1040             }
2605
2606         We use `m_value->child(1)->isInt(std::numeric_limits<uint32_t>::max())`. However, Value::isInt is,
2607
2608             262 inline bool Value::isInt(int64_t value) const
2609             263 {
2610             264     return hasInt() && asInt() == value;
2611             265 }
2612
2613         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,
2614
2615             257 inline int64_t Value::asInt() const
2616             258 {
2617             259     return hasInt32() ? asInt32() : asInt64();
2618             260 }
2619
2620         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!
2621         We should use `isInt32` and `isInt64` for bit patterns (like, operands for Bitwise opcodes).
2622
2623         We also fix the following optimization.
2624
2625             // Turn this: BitAnd(Op(value, constant1), constant2)
2626             //     where !(constant1 & constant2)
2627             //       and Op is BitOr or BitXor
2628             // into this: BitAnd(value, constant2)
2629
2630         Since we stop further optimization when we match `if (m_value->child(1)->hasInt())`, the following optimization is never taken.
2631
2632             // Turn this: BitAnd(BitXor(x, allOnes), c)
2633             // Into this: BitXor(BitOr(x, ~c), allOnes)
2634
2635         We add 32bit version of B3 tests for these optimizations.
2636
2637         * b3/B3LowerToAir.cpp:
2638         * b3/B3ReduceStrength.cpp:
2639         * b3/testb3.h:
2640         * b3/testb3_2.cpp:
2641         (testBitAndNotNot32):
2642         (testBitAndNotImm):
2643         (testBitAndNotImm32):
2644         (testBitOrAndAndArgs32):
2645         (testBitOrAndSameArgs32):
2646         (testBitOrNotNot32):
2647         (testBitOrNotImm32):
2648         (addBitTests):
2649         * b3/testb3_3.cpp:
2650         (testBitXorAndAndArgs32):
2651         (testBitXorAndSameArgs32):
2652
2653 2019-09-10  Yusuke Suzuki  <ysuzuki@apple.com>
2654
2655         [WebAssembly] Use StreamingParser in existing Wasm::BBQPlan
2656         https://bugs.webkit.org/show_bug.cgi?id=189043
2657
2658         Reviewed by Keith Miller.
2659
2660         This patch integrates Wasm::StreamingParser into the existing Wasm::BBQPlan.
2661         And remove Wasm::ModuleParser. This patch paves the way to implementing Wasm streaming features by
2662         using Wasm::StreamingParser.
2663
2664         Currently, we are not using streaming feature of StreamingParser. In a subsequent patch, we will
2665         create a mechanism to pipe a chunk of data to streaming parser to enable WebAssembly.compileStreaming
2666         and instantiateStreaming.
2667
2668         * JavaScriptCore.xcodeproj/project.pbxproj:
2669         * Sources.txt:
2670         * tools/JSDollarVM.cpp:
2671         (JSC::WasmStreamingParser::WasmStreamingParser):
2672         * wasm/WasmAirIRGenerator.cpp:
2673         (JSC::Wasm::parseAndCompileAir):
2674         * wasm/WasmAirIRGenerator.h:
2675         * wasm/WasmB3IRGenerator.cpp:
2676         (JSC::Wasm::parseAndCompile): Use FunctionData, it is good since it is more strongly typed.
2677         * wasm/WasmB3IRGenerator.h:
2678         * wasm/WasmBBQPlan.cpp:
2679         (JSC::Wasm::BBQPlan::BBQPlan):
2680         (JSC::Wasm::BBQPlan::didReceiveFunctionData): Add a callback, which invokes validation.
2681         (JSC::Wasm::BBQPlan::parseAndValidateModule): Use StreamingParser instead of old ModuleParser.
2682         (JSC::Wasm::BBQPlan::compileFunctions):
2683         (JSC::Wasm::BBQPlan::complete):
2684         * wasm/WasmBBQPlan.h:
2685         * wasm/WasmModuleParser.cpp: Removed.
2686         * wasm/WasmModuleParser.h: Removed.
2687         * wasm/WasmOMGForOSREntryPlan.cpp:
2688         (JSC::Wasm::OMGForOSREntryPlan::work):
2689         * wasm/WasmOMGPlan.cpp:
2690         (JSC::Wasm::OMGPlan::work):
2691         * wasm/WasmPlan.cpp:
2692         (JSC::Wasm::Plan::fail): Make fail function callable multiple times. The first error will be used.
2693         * wasm/WasmSectionParser.cpp:
2694         (JSC::Wasm::SectionParser::parseCode): Since the Code section is specially handled in StreamingParser, this code is never used.
2695         * wasm/WasmStreamingParser.cpp:
2696         (JSC::Wasm::StreamingParser::StreamingParser):
2697         (JSC::Wasm::StreamingParser::parseCodeSectionSize):
2698         (JSC::Wasm::StreamingParser::parseFunctionPayload):
2699         (JSC::Wasm::StreamingParser::parseSectionPayload):
2700         (JSC::Wasm::StreamingParser::finalize): Call client's callbacks at appropriate timings.
2701         * wasm/WasmStreamingParser.h:
2702         (JSC::Wasm::StreamingParserClient::didReceiveSectionData):
2703         (JSC::Wasm::StreamingParserClient::didReceiveFunctionData):
2704         (JSC::Wasm::StreamingParserClient::didFinishParsing): Add StreamingParserClient,
2705         which has 3 callbacks right now. StreamingParser gets this client and call these callbacks
2706         at appropriate timings.
2707         * wasm/WasmValidate.cpp:
2708         (JSC::Wasm::validateFunction):
2709         * wasm/WasmValidate.h: Use FunctionData, it is good since it is more strongly typed.
2710
2711 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
2712
2713         [JSC] CodeBlock::m_constantRegisters should be guarded by ConcurrentJSLock when Vector reallocate memory
2714         https://bugs.webkit.org/show_bug.cgi?id=201622
2715
2716         Reviewed by Mark Lam.
2717
2718         CodeBlock::visitChildren takes ConcurrentJSLock while iterating m_constantRegisters, some of the places reallocate
2719         this Vector without taking a lock. If a Vector memory is reallocated while iterating it in concurrent collector,
2720         the concurrent collector can see a garbage. This patch guards m_constantRegisters reallocation with ConcurrentJSLock.
2721
2722         * bytecode/CodeBlock.cpp:
2723         (JSC::CodeBlock::finishCreation):
2724         (JSC::CodeBlock::setConstantRegisters):
2725         * bytecode/CodeBlock.h:
2726         (JSC::CodeBlock::addConstant):
2727         (JSC::CodeBlock::addConstantLazily):
2728         * dfg/DFGDesiredWatchpoints.cpp:
2729         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
2730         (JSC::DFG::SymbolTableAdaptor::add):
2731         (JSC::DFG::FunctionExecutableAdaptor::add):
2732         * dfg/DFGGraph.cpp:
2733         (JSC::DFG::Graph::registerFrozenValues):
2734         * dfg/DFGJITFinalizer.cpp:
2735         (JSC::DFG::JITFinalizer::finalizeCommon):
2736         * dfg/DFGLazyJSValue.cpp:
2737         (JSC::DFG::LazyJSValue::emit const):
2738
2739 2019-09-09  Robin Morisset  <rmorisset@apple.com>
2740
2741         [Air] highOrderAdjacents in AbstractColoringAllocator::conservativeHeuristic should be some kind of array
2742         https://bugs.webkit.org/show_bug.cgi?id=197305
2743
2744         Reviewed by Keith Miller.
2745
2746         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.
2747         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).
2748
2749         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.
2750         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).
2751
2752         The time spent in the register allocator throughout JetStream2 on this MacBook Pro moves from 3767 / 3710 / 3785 ms to 3551 / 3454 / 3503 ms.
2753         So about a 6% speedup for that phase, and between 1 and 1.5% speedup for FTL/OMG compilation overall.
2754
2755         No new tests as there is no intended change to the code being generated, and this was already tested by running testb3 + JetStream2.
2756
2757         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
2758
2759 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
2760
2761         [JSC] Use metadata table to iterate specific bytecode metadata instead of propertyAccessInstructions vector
2762         https://bugs.webkit.org/show_bug.cgi?id=201613
2763
2764         Reviewed by Mark Lam.
2765
2766         We do not need to maintain propertyAccessInstructions vector to access metadata tied to a specific bytecode opcode
2767         since we have MetadataTable::forEach<Op> feature. This removes propertyAccessInstructions entirely, and fixes the
2768         issue that `op_create_promise` missed propertyAccessInstructions registration (a name "propertyAccessInstructions" is
2769         misleading, it is like "instructions-requires-llint-finalize").
2770
2771         * bytecode/CodeBlock.cpp:
2772         (JSC::CodeBlock::propagateTransitions):
2773         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2774         * bytecode/UnlinkedCodeBlock.cpp:
2775         (JSC::UnlinkedCodeBlock::applyModification):
2776         (JSC::UnlinkedCodeBlock::shrinkToFit):
2777         * bytecode/UnlinkedCodeBlock.h:
2778         (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
2779         (JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions const): Deleted.
2780         (JSC::UnlinkedCodeBlock::propertyAccessInstructions const): Deleted.
2781         * bytecompiler/BytecodeGenerator.cpp:
2782         (JSC::BytecodeGenerator::emitResolveScope):
2783         (JSC::BytecodeGenerator::emitGetFromScope):
2784         (JSC::BytecodeGenerator::emitPutToScope):
2785         (JSC::BytecodeGenerator::emitGetById):
2786         (JSC::BytecodeGenerator::emitDirectGetById):
2787         (JSC::BytecodeGenerator::emitPutById):
2788         (JSC::BytecodeGenerator::emitDirectPutById):
2789         (JSC::BytecodeGenerator::emitCreateThis):
2790         (JSC::BytecodeGenerator::emitToThis):
2791         * runtime/CachedTypes.cpp:
2792         (JSC::CachedCodeBlock<CodeBlockType>::decode const):
2793         (JSC::CachedCodeBlock<CodeBlockType>::encode):
2794
2795 2019-09-07  Keith Miller  <keith_miller@apple.com>
2796
2797         OSR entry into wasm misses some contexts
2798         https://bugs.webkit.org/show_bug.cgi?id=201569
2799
2800         Reviewed by Yusuke Suzuki.
2801
2802         This patch fixes an issue where we could fail to capture some of
2803         our contexts when OSR entering into wasm code. Before we would
2804         only capture the state of the block immediately surrounding the
2805         entrance loop block header. We actually need to capture all
2806         enclosed stacks.
2807
2808         Additionally, we don't need to use variables for all the captured
2809         values. We can use a Phi and insert an upsilon just below the
2810         captured value.
2811
2812         * interpreter/CallFrame.h:
2813         * jsc.cpp:
2814         (GlobalObject::finishCreation):
2815         (functionCallerIsOMGCompiled):
2816         * wasm/WasmAirIRGenerator.cpp:
2817         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
2818         (JSC::Wasm::AirIRGenerator::emitEntryTierUpCheck):
2819         (JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
2820         (JSC::Wasm::AirIRGenerator::addLoop):
2821         * wasm/WasmB3IRGenerator.cpp:
2822         (JSC::Wasm::B3IRGenerator::createStack):
2823         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2824         (JSC::Wasm::B3IRGenerator::addConstant):
2825         (JSC::Wasm::B3IRGenerator::emitEntryTierUpCheck):
2826         (JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
2827         (JSC::Wasm::B3IRGenerator::addLoop):
2828         (JSC::Wasm::B3IRGenerator::addEndToUnreachable):
2829         (JSC::Wasm::dumpExpressionStack):
2830         (JSC::Wasm::B3IRGenerator::dump):
2831         (JSC::Wasm::B3IRGenerator::Stack::Stack): Deleted.
2832         (JSC::Wasm::B3IRGenerator::Stack::append): Deleted.
2833         (JSC::Wasm::B3IRGenerator::Stack::takeLast): Deleted.
2834         (JSC::Wasm::B3IRGenerator::Stack::last): Deleted.
2835         (JSC::Wasm::B3IRGenerator::Stack::size const): Deleted.
2836         (JSC::Wasm::B3IRGenerator::Stack::isEmpty const): Deleted.
2837         (JSC::Wasm::B3IRGenerator::Stack::convertToExpressionList): Deleted.
2838         (JSC::Wasm::B3IRGenerator::Stack::at const): Deleted.
2839         (JSC::Wasm::B3IRGenerator::Stack::variableAt const): Deleted.
2840         (JSC::Wasm::B3IRGenerator::Stack::shrink): Deleted.
2841         (JSC::Wasm::B3IRGenerator::Stack::swap): Deleted.
2842         (JSC::Wasm::B3IRGenerator::Stack::dump const): Deleted.
2843         * wasm/WasmFunctionParser.h:
2844         (JSC::Wasm::FunctionParser::controlStack):
2845
2846 2019-09-09  Yusuke Suzuki  <ysuzuki@apple.com>
2847
2848         [JSC] Promise resolve/reject functions should be created more efficiently
2849         https://bugs.webkit.org/show_bug.cgi?id=201488
2850
2851         Reviewed by Mark Lam.
2852
2853         While r246553 fixed an important issue, it makes anonymous-builtin-function creation costly since it enforces FunctionRareData allocations.
2854         Unfortunately, anonymous-builtin-function function can be created frequently since this type of function is used
2855         for `resolve` and `reject` arguments of Promise's executor (e.g. `new Promise((resolve, reject) => ...)`'s resolve and reject).
2856         Since we are now always creating FunctionRareData for these functions, this additional allocation makes promise creation slower.
2857
2858         In this patch, we use `isAnonymousBuiltinFunction` information for `hasReifiedName` correctly. And we propagate `isAnonymousBuiltinFunction` information
2859         to FunctionRareData to initialize `m_hasReifiedName` correctly. Then we can avoid unnecessary FunctionRareData allocation, which makes
2860         anonymous-builtin-function creation faster.
2861
2862         We can ensure that this patch does not revert r246553's fix by running JSTests/stress/builtin-private-function-name.js test.
2863         The simple microbenchmark shows 1.7x improvement.
2864
2865                                               ToT                     Patched
2866
2867             promise-creation-many       45.6701+-0.1488     ^     26.8663+-1.8336        ^ definitely 1.6999x faster
2868
2869         * dfg/DFGSpeculativeJIT.cpp:
2870         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2871         * ftl/FTLLowerDFGToB3.cpp:
2872         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
2873         * runtime/FunctionRareData.cpp:
2874         (JSC::FunctionRareData::create):
2875         (JSC::FunctionRareData::FunctionRareData):
2876         * runtime/FunctionRareData.h:
2877         * runtime/JSFunction.cpp:
2878         (JSC::JSFunction::finishCreation):
2879         (JSC::JSFunction::allocateRareData):
2880         (JSC::JSFunction::allocateAndInitializeRareData):
2881         * runtime/JSFunctionInlines.h:
2882         (JSC::JSFunction::hasReifiedName const):
2883
2884 2019-09-07  Mark Lam  <mark.lam@apple.com>
2885
2886         performJITMemcpy() source buffer should not be in the Gigacage.
2887         https://bugs.webkit.org/show_bug.cgi?id=201577
2888         <rdar://problem/55142606>
2889
2890         Reviewed by Michael Saboff.
2891
2892         Add a RELEASE_ASSERT in performJITMemcpy() to ensure that the passed in source
2893         buffer is not in the Gigacage.
2894
2895         * jit/ExecutableAllocator.h:
2896         (JSC::performJITMemcpy):
2897
2898 2019-09-07  Mark Lam  <mark.lam@apple.com>
2899
2900         The jsc shell should allow disabling of the Gigacage for testing purposes.
2901         https://bugs.webkit.org/show_bug.cgi?id=201579
2902
2903         Reviewed by Michael Saboff.
2904
2905         Check for the same GIGACAGE_ENABLED env var that is checked by Gigacage code.  If
2906         this env var is present and it has a falsy value, then do not
2907         forbidDisablingPrimitiveGigacage() in the jsc shell.
2908
2909         * jsc.cpp:
2910         (jscmain):
2911
2912 2019-09-06  Mark Lam  <mark.lam@apple.com>
2913
2914         Harden protection of the Gigacage Config parameters.
2915         https://bugs.webkit.org/show_bug.cgi?id=201570
2916         <rdar://problem/55134229>
2917
2918         Reviewed by Saam Barati.
2919
2920         Just renaming some function names here.
2921
2922         * assembler/testmasm.cpp:
2923         (JSC::testCagePreservesPACFailureBit):
2924         * jit/AssemblyHelpers.h:
2925         (JSC::AssemblyHelpers::cageConditionally):
2926         * jsc.cpp:
2927         (jscmain):
2928
2929 2019-09-06  Ross Kirsling  <ross.kirsling@sony.com>
2930
2931         Math.round() produces wrong result for value prior to 0.5
2932         https://bugs.webkit.org/show_bug.cgi?id=185115
2933
2934         Reviewed by Saam Barati.
2935
2936         Our Math.round implementation goes in the wrong direction for double values like 0.49999999999999994.
2937         This requires just a subtle adjustment for three of our four versions; only baseline JIT needed a full rewrite.
2938
2939         Specifically:
2940           - While 0.49999999999999994 is representable, 1 - 0.49999999999999994 is not (it turns into 0.5),
2941             so taking the difference between ceil(value)` and `value` is problematic.
2942           - The baseline implementation was doing `floor(x + 0.5)` for positive doubles and slowpathing negative ones
2943             (by falling back to jsRound). This patch gives baseline a legitimate implementation too.
2944
2945         * dfg/DFGSpeculativeJIT.cpp:
2946         (JSC::DFG::SpeculativeJIT::compileArithRounding):
2947         * ftl/FTLLowerDFGToB3.cpp:
2948         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
2949         * jit/ThunkGenerators.cpp:
2950         (JSC::roundThunkGenerator):
2951         * runtime/MathCommon.cpp:
2952
2953 2019-09-05  Joseph Pecoraro  <pecoraro@apple.com>
2954
2955         Tail Deleted Frames shown in Web Inspector are sometimes incorrect (Shadow Chicken)
2956         https://bugs.webkit.org/show_bug.cgi?id=201366
2957
2958         Reviewed by Saam Barati.
2959
2960         It is possible for the log buffer to be full right as someone is trying to
2961         log a function prologue. In such a case the machine stack has already been
2962         updated to include the new JavaScript call frame, but the prologue packet
2963         cannot be included in the update because the log is full. This would mean
2964         that the update fails to rationalize the machine stack with the shadow
2965         log / stack. Namely, the current JavaScript call frame is unable to
2966         find a matching prologue (the one we are holding to include after the update)
2967         and inserts a questionable value into the stack; and in the process
2968         missing and removing real potential tail calls.
2969
2970         For example:
2971         
2972             "use strict";
2973             function third() { return 1; }
2974             function second() { return third(); }
2975             function first() { return second(); }
2976             function start() { return first(); }
2977
2978         If the the log fills up just as we are entering `b` then we may have a list
2979         full log of packets looking like:
2980
2981           Shadow Log:
2982             ...
2983             { prologue-packet: entering `start` ... }
2984             { prologue-packet: entering `first` ... }
2985             { tail-packet: leaving `first` with a tail call }
2986
2987           Incoming Packet:
2988             { prologue-packet: entering `second` ... }
2989
2990           Current JS Stack:
2991             second
2992             start
2993
2994         Since the Current JavaScript stack already has `second`, if we process the
2995         log without the prologue for `second` then we push a confused entry on the
2996         shadow stack and clear the log such that we eventually lose the tail-call
2997         information for `first` to `second`.
2998
2999         This patch solves this issue by providing enough extra space in the log
3000         to always process the incoming packet when that forces an update. This way
3001         clients can continue to behave exactly as they are.
3002
3003         --
3004
3005         We also document a corner case in some circumstances where the shadow
3006         log may currently be insufficient to know how to reconcile:
3007         
3008         For example:
3009
3010             "use strict";
3011             function third() { return 1; }
3012             function second() { return third(); }
3013             function first() { return second(); }
3014             function doNothingTail() { return Math.random() }
3015             function start() {
3016                 for (i=0;i<1000;++i) doNothingTail();
3017                 return first();
3018             }
3019
3020         In this case the ShadowChicken log may be processed multiple times due
3021         to the many calls to `doNothingTail` / `Math.random()`. When calling the
3022         Native function no prologue packet is emitted, so it is unclear that we
3023         temporarly go deeper and come back out on the stack, so the log appears
3024         to have lots of doNothingTail calls reusing the same frame:
3025
3026           Shadow Log:
3027             ...
3028             , [123] {callee = 0x72a21aee0, frame = 0x7ffeef897270, callerFrame = 0x7ffeef8972e0, name = start}
3029             , [124] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3030             , [125] tail-packet:{frame = 0x7ffeef8971f0}
3031             , [126] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3032             , [127] tail-packet:{frame = 0x7ffeef8971f0}
3033             ...
3034             , [140] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3035             , [141] tail-packet:{frame = 0x7ffeef8971f0}
3036             , [142] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3037             , [143] tail-packet:{frame = 0x7ffeef8971f0}
3038             , [144] {callee = 0x72a21aeb0, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = first}
3039             , [145] tail-packet:{frame = 0x7ffeef8971f0}
3040             , [146] {callee = 0x72a21ae80, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = second}
3041             ...
3042
3043         This log would seem to be indistinguishable from real tail recursion, such as:
3044
3045             "use strict";
3046             function third() { return 1; }
3047             function second() { return third(); }
3048             function first() { return second(); }
3049             function doNothingTail(n) {
3050                 return n ? doNothingTail(n-1) : first();
3051             }
3052             function start() {
3053                 return doNothingTail(1000);
3054             }
3055
3056         Likewise there are more cases where the shadow log appears to be ambiguous with determining
3057         the appropriate parent call frame with intermediate function calls. In practice this may
3058         not be too problematic, as this is a best effort reconstruction of tail deleted frames.
3059         It seems likely we would only show additional frames that did in fact happen serially
3060         between JavaScript call frames, but may not actually be the proper parent frames
3061         heirachy in the stack.
3062
3063         * interpreter/ShadowChicken.cpp:
3064         (JSC::ShadowChicken::Packet::dump const):
3065         (JSC::ShadowChicken::Frame::dump const):
3066         (JSC::ShadowChicken::dump const):
3067         Improved debugging output. Especially for functions.
3068
3069         (JSC::ShadowChicken::ShadowChicken):
3070         Make space in the log for 1 additional packet to process when we slow log.
3071
3072         (JSC::ShadowChicken::log):
3073         Include this packet in our update.
3074
3075         (JSC::ShadowChicken::update):
3076         Address an edge case where we can eliminate tail-deleted frames that don't make sense.
3077
3078 2019-09-06  Ryan Haddad  <ryanhaddad@apple.com>
3079
3080         Unreviewed, rolling out r249566.
3081
3082         Causes inspector layout test crashes under GuardMalloc
3083
3084         Reverted changeset:
3085
3086         "Tail Deleted Frames shown in Web Inspector are sometimes
3087         incorrect (Shadow Chicken)"
3088         https://bugs.webkit.org/show_bug.cgi?id=201366
3089         https://trac.webkit.org/changeset/249566
3090
3091 2019-09-06  Guillaume Emont  <guijemont@igalia.com>
3092
3093         testmasm: save r6 in JIT'ed code on ARM_THUMB2
3094         https://bugs.webkit.org/show_bug.cgi?id=201138
3095
3096         Reviewed by Mark Lam.
3097
3098         MacroAssemblerArmv7 uses r6 as a temporary register, and it is a
3099         callee-saved register. The JITs use
3100         AssemblyHelpers::emitSaveCalleeSaves() and friends to save
3101         callee-saved registers, but there is no such mechanism in testmasm,
3102         which seems to make the assumption that the macroassembler does not
3103         use callee-saved registers (which I guess is true for all other
3104         architectures, but not for Armv7).
3105
3106         This issue means that testmasm crashes on Armv7 since code generated
3107         by gcc uses r6, and it gets modified by JIT'ed code.
3108
3109         This change makes sure that we save and restore r6 for all code
3110         compiled by testmasm on Armv7.
3111
3112         * assembler/testmasm.cpp:
3113         (JSC::emitFunctionPrologue):
3114         (JSC::emitFunctionEpilogue):
3115         (JSC::testSimple):
3116         (JSC::testGetEffectiveAddress):
3117         (JSC::testBranchTruncateDoubleToInt32):
3118         (JSC::testBranchTestBit32RegReg):
3119         (JSC::testBranchTestBit32RegImm):
3120         (JSC::testBranchTestBit32AddrImm):
3121         (JSC::testBranchTestBit64RegReg):
3122         (JSC::testBranchTestBit64RegImm):
3123         (JSC::testBranchTestBit64AddrImm):
3124         (JSC::testCompareDouble):
3125         (JSC::testMul32WithImmediates):
3126         (JSC::testMul32SignExtend):
3127         (JSC::testCompareFloat):
3128         (JSC::testProbeReadsArgumentRegisters):
3129         (JSC::testProbeWritesArgumentRegisters):
3130         (JSC::testProbePreservesGPRS):
3131         (JSC::testProbeModifiesStackPointer):
3132         (JSC::testProbeModifiesProgramCounter):
3133         (JSC::testProbeModifiesStackValues):
3134         (JSC::testByteSwap):
3135         (JSC::testMoveDoubleConditionally32):
3136         (JSC::testMoveDoubleConditionally64):
3137         (JSC::testCagePreservesPACFailureBit):
3138
3139 2019-09-05  Joseph Pecoraro  <pecoraro@apple.com>
3140
3141         Tail Deleted Frames shown in Web Inspector are sometimes incorrect (Shadow Chicken)
3142         https://bugs.webkit.org/show_bug.cgi?id=201366
3143
3144         Reviewed by Saam Barati.
3145
3146         It is possible for the log buffer to be full right as someone is trying to
3147         log a function prologue. In such a case the machine stack has already been
3148         updated to include the new JavaScript call frame, but the prologue packet
3149         cannot be included in the update because the log is full. This would mean
3150         that the update fails to rationalize the machine stack with the shadow
3151         log / stack. Namely, the current JavaScript call frame is unable to
3152         find a matching prologue (the one we are holding to include after the update)
3153         and inserts a questionable value into the stack; and in the process
3154         missing and removing real potential tail calls.
3155
3156         For example:
3157         
3158             "use strict";
3159             function third() { return 1; }
3160             function second() { return third(); }
3161             function first() { return second(); }
3162             function start() { return first(); }
3163
3164         If the the log fills up just as we are entering `b` then we may have a list
3165         full log of packets looking like:
3166
3167           Shadow Log:
3168             ...
3169             { prologue-packet: entering `start` ... }
3170             { prologue-packet: entering `first` ... }
3171             { tail-packet: leaving `first` with a tail call }
3172
3173           Incoming Packet:
3174             { prologue-packet: entering `second` ... }
3175
3176           Current JS Stack:
3177             second
3178             start
3179
3180         Since the Current JavaScript stack already has `second`, if we process the
3181         log without the prologue for `second` then we push a confused entry on the
3182         shadow stack and clear the log such that we eventually lose the tail-call
3183         information for `first` to `second`.
3184
3185         This patch solves this issue by providing enough extra space in the log
3186         to always process the incoming packet when that forces an update. This way
3187         clients can continue to behave exactly as they are.
3188
3189         --
3190
3191         We also document a corner case in some circumstances where the shadow
3192         log may currently be insufficient to know how to reconcile:
3193         
3194         For example:
3195
3196             "use strict";
3197             function third() { return 1; }
3198             function second() { return third(); }
3199             function first() { return second(); }
3200             function doNothingTail() { return Math.random() }
3201             function start() {
3202                 for (i=0;i<1000;++i) doNothingTail();
3203                 return first();
3204             }
3205
3206         In this case the ShadowChicken log may be processed multiple times due
3207         to the many calls to `doNothingTail` / `Math.random()`. When calling the
3208         Native function no prologue packet is emitted, so it is unclear that we
3209         temporarly go deeper and come back out on the stack, so the log appears
3210         to have lots of doNothingTail calls reusing the same frame:
3211
3212           Shadow Log:
3213             ...
3214             , [123] {callee = 0x72a21aee0, frame = 0x7ffeef897270, callerFrame = 0x7ffeef8972e0, name = start}
3215             , [124] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3216             , [125] tail-packet:{frame = 0x7ffeef8971f0}
3217             , [126] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3218             , [127] tail-packet:{frame = 0x7ffeef8971f0}
3219             ...
3220             , [140] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3221             , [141] tail-packet:{frame = 0x7ffeef8971f0}
3222             , [142] {callee = 0x72a21af10, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = doNothingTail}
3223             , [143] tail-packet:{frame = 0x7ffeef8971f0}
3224             , [144] {callee = 0x72a21aeb0, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = first}
3225             , [145] tail-packet:{frame = 0x7ffeef8971f0}
3226             , [146] {callee = 0x72a21ae80, frame = 0x7ffeef8971f0, callerFrame = 0x7ffeef897270, name = second}
3227             ...
3228
3229         This log would seem to be indistinguishable from real tail recursion, such as:
3230
3231             "use strict";
3232             function third() { return 1; }
3233             function second() { return third(); }
3234             function first() { return second(); }
3235             function doNothingTail(n) {
3236                 return n ? doNothingTail(n-1) : first();
3237             }
3238             function start() {
3239                 return doNothingTail(1000);
3240             }
3241
3242         Likewise there are more cases where the shadow log appears to be ambiguous with determining
3243         the appropriate parent call frame with intermediate function calls. In practice this may
3244         not be too problematic, as this is a best effort reconstruction of tail deleted frames.
3245         It seems likely we would only show additional frames that did in fact happen serially
3246         between JavaScript call frames, but may not actually be the proper parent frames
3247         heirachy in the stack.
3248
3249         * interpreter/ShadowChicken.cpp:
3250         (JSC::ShadowChicken::Packet::dump const):
3251         (JSC::ShadowChicken::Frame::dump const):
3252         (JSC::ShadowChicken::dump const):
3253         Improved debugging output. Especially for functions.
3254
3255         (JSC::ShadowChicken::ShadowChicken):
3256         Make space in the log for 1 additional packet to process when we slow log.
3257
3258         (JSC::ShadowChicken::log):
3259         Include this packet in our update.
3260
3261         (JSC::ShadowChicken::update):
3262         Address an edge case where we can eliminate tail-deleted frames that don't make sense.
3263
3264 2019-09-05  Mark Lam  <mark.lam@apple.com>
3265
3266         Refactor the Gigacage code to require less pointer casting.
3267         https://bugs.webkit.org/show_bug.cgi?id=201521
3268
3269         Reviewed by Saam Barati.
3270
3271         Change LLInt's loadCagedJSValue() to skip the caging if Gigacage is not enabled
3272         in the build.  This allows us to remove the unneeded stubs in WTF Gigacage.h.
3273
3274         * jit/AssemblyHelpers.h:
3275         (JSC::AssemblyHelpers::cageConditionally):
3276         * llint/LowLevelInterpreter.asm:
3277         * llint/LowLevelInterpreter64.asm:
3278         * runtime/VM.h:
3279         (JSC::VM::gigacageAuxiliarySpace):
3280
3281 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
3282
3283         Unreviewed, follow-up after r249530 and r249509
3284         https://bugs.webkit.org/show_bug.cgi?id=201495
3285
3286         Rename FTLOutput::weakPointer to alreadyRegisteredWeakPointer and alreadyRegisteredFrozenPointer.
3287
3288         * builtins/PromiseConstructor.js:
3289         (nakedConstructor.Promise.resolve):
3290         (nakedConstructor.Promise.reject):
3291         (nakedConstructor.Promise):
3292         (nakedConstructor.InternalPromise.resolve):
3293         (nakedConstructor.InternalPromise.reject):
3294         (nakedConstructor.InternalPromise):
3295         * ftl/FTLLowerDFGToB3.cpp:
3296         (JSC::FTL::DFG::LowerDFGToB3::weakPointer):
3297         (JSC::FTL::DFG::LowerDFGToB3::frozenPointer):
3298         (JSC::FTL::DFG::LowerDFGToB3::weakStructure):
3299         * ftl/FTLOutput.h:
3300         (JSC::FTL::Output::alreadyRegisteredWeakPointer):
3301         (JSC::FTL::Output::alreadyRegisteredFrozenPointer):
3302         (JSC::FTL::Output::weakPointer): Deleted.
3303
3304 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
3305
3306         [JSC] Generalize Get/PutPromiseInternalField for InternalFieldObjectImpl
3307         https://bugs.webkit.org/show_bug.cgi?id=201513
3308
3309         Reviewed by Ross Kirsling.
3310
3311         This patch extracts JSPromise's internal fields mechanism as JSInternalFieldsObjectImpl, and make it reusable for the other objects.
3312         It is preparation for using this internal fields mechanism for generators, async functions, async generators, array iterators and so on.
3313
3314         The profiler is telling many recompilation of Generator's resume function (including async generator's one). We are using properties
3315         with private-symbols as a storage for internal state of generators. However, the spec defines that each generator from different generator-functions
3316         has different [[Prototype]]. While we need to share one Generator.prototype.next function, generators tend to have different Structures due to
3317         different [[Prototype]] and accessing internal fields with `get_by_id_direct` sadly becomes super megamorphic while it is not necessary.
3318         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
3319         emits super generic code unfortunately. By using internal fields for storing these state, we can avoid this performance problem.
3320
3321         Bytecodes and corresponding DFG nodes are just renamed. JSPromise is now inheriting JSInternalFieldsObjectImpl, which can holds specified
3322         number of internal fields. And op_get_internal_field / op_put_internal_field can access these internal fields.
3323
3324         * CMakeLists.txt:
3325         * JavaScriptCore.xcodeproj/project.pbxproj:
3326         * bytecode/BytecodeList.rb:
3327         * bytecode/BytecodeUseDef.h:
3328         (JSC::computeUsesForBytecodeOffset):
3329         (JSC::computeDefsForBytecodeOffset):
3330         * bytecode/CodeBlock.cpp:
3331         (JSC::CodeBlock::finishCreation):
3332         * bytecode/Opcode.h:
3333         * bytecompiler/BytecodeGenerator.cpp:
3334         (JSC::BytecodeGenerator::emitGetInternalField):
3335         (JSC::BytecodeGenerator::emitPutInternalField):
3336         (JSC::BytecodeGenerator::emitGetPromiseInternalField): Deleted.
3337         (JSC::BytecodeGenerator::emitPutPromiseInternalField): Deleted.
3338         * bytecompiler/BytecodeGenerator.h:
3339         * bytecompiler/NodesCodegen.cpp:
3340         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getPromiseInternalField):
3341         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putPromiseInternalField):
3342         * dfg/DFGAbstractInterpreterInlines.h:
3343         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3344         * dfg/DFGByteCodeParser.cpp:
3345         (JSC::DFG::ByteCodeParser::parseBlock):
3346         * dfg/DFGCapabilities.cpp:
3347         (JSC::DFG::capabilityLevel):
3348         * dfg/DFGClobberize.h:
3349         (JSC::DFG::clobberize):
3350         * dfg/DFGDoesGC.cpp:
3351         (JSC::DFG::doesGC):
3352         * dfg/DFGFixupPhase.cpp:
3353         (JSC::DFG::FixupPhase::fixupNode):
3354         * dfg/DFGMayExit.cpp:
3355         * dfg/DFGNode.h:
3356         (JSC::DFG::Node::hasInternalFieldIndex):
3357         (JSC::DFG::Node::hasHeapPrediction):
3358         * dfg/DFGNodeType.h:
3359         * dfg/DFGPredictionPropagationPhase.cpp:
3360         * dfg/DFGSafeToExecute.h:
3361         (JSC::DFG::safeToExecute):
3362         * dfg/DFGSpeculativeJIT.cpp:
3363         (JSC::DFG::SpeculativeJIT::compileGetInternalField):
3364         (JSC::DFG::SpeculativeJIT::compilePutInternalField):
3365         (JSC::DFG::SpeculativeJIT::compileCreatePromise):
3366         (JSC::DFG::SpeculativeJIT::compileNewPromise):
3367         (JSC::DFG::SpeculativeJIT::compileGetPromiseInternalField): Deleted.
3368         (JSC::DFG::SpeculativeJIT::compilePutPromiseInternalField): Deleted.
3369         * dfg/DFGSpeculativeJIT.h:
3370         * dfg/DFGSpeculativeJIT32_64.cpp:
3371         (JSC::DFG::SpeculativeJIT::compile):
3372         * dfg/DFGSpeculativeJIT64.cpp:
3373         (JSC::DFG::SpeculativeJIT::compile):
3374         * dfg/DFGStoreBarrierInsertionPhase.cpp:
3375         * ftl/FTLAbstractHeapRepository.h:
3376         * ftl/FTLCapabilities.cpp:
3377         (JSC::FTL::canCompile):
3378         * ftl/FTLLowerDFGToB3.cpp:
3379         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3380         (JSC::FTL::DFG::LowerDFGToB3::compileNewPromise):
3381         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
3382         (JSC::FTL::DFG::LowerDFGToB3::compileGetInternalField):
3383         (JSC::FTL::DFG::LowerDFGToB3::compilePutInternalField):
3384         (JSC::FTL::DFG::LowerDFGToB3::compileGetPromiseInternalField): Deleted.
3385         (JSC::FTL::DFG::LowerDFGToB3::compilePutPromiseInternalField): Deleted.
3386         * jit/JIT.cpp:
3387         (JSC::JIT::privateCompileMainPass):
3388         * jit/JIT.h:
3389         * jit/JITPropertyAccess.cpp:
3390         (JSC::JIT::emit_op_get_internal_field):
3391         (JSC::JIT::emit_op_put_internal_field):
3392         (JSC::JIT::emit_op_get_promise_internal_field): Deleted.
3393         (JSC::JIT::emit_op_put_promise_internal_field): Deleted.
3394         * jit/JITPropertyAccess32_64.cpp:
3395         (JSC::JIT::emit_op_get_internal_field):
3396         (JSC::JIT::emit_op_put_internal_field):
3397         (JSC::JIT::emit_op_get_promise_internal_field): Deleted.
3398         (JSC::JIT::emit_op_put_promise_internal_field): Deleted.
3399         * llint/LLIntOffsetsExtractor.cpp:
3400         * llint/LowLevelInterpreter.asm:
3401         * llint/LowLevelInterpreter32_64.asm:
3402         * llint/LowLevelInterpreter64.asm:
3403         * runtime/JSInternalFieldObjectImpl.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
3404         (JSC::JSInternalFieldObjectImpl::allocationSize):
3405         (JSC::JSInternalFieldObjectImpl::internalField const):
3406         (JSC::JSInternalFieldObjectImpl::internalField):
3407         (JSC::JSInternalFieldObjectImpl::offsetOfInternalFields):
3408         (JSC::JSInternalFieldObjectImpl::offsetOfInternalField):
3409         (JSC::JSInternalFieldObjectImpl::JSInternalFieldObjectImpl):
3410         * runtime/JSInternalFieldObjectImplInlines.h: Added.
3411         (JSC::JSInternalFieldObjectImpl<passedNumberOfInternalFields>::visitChildren):
3412         * runtime/JSPromise.cpp:
3413         (JSC::JSPromise::finishCreation):
3414         (JSC::JSPromise::visitChildren):
3415         (JSC::JSPromise::status const):
3416         (JSC::JSPromise::result const):
3417         (JSC::JSPromise::isHandled const):
3418         * runtime/JSPromise.h:
3419         (JSC::JSPromise::allocationSize): Deleted.
3420         (JSC::JSPromise::offsetOfInternalFields): Deleted.
3421         (JSC::JSPromise::offsetOfInternalField): Deleted.
3422         (): Deleted.
3423
3424 2019-09-05  Commit Queue  <commit-queue@webkit.org>
3425
3426         Unreviewed, rolling out r247463.
3427         https://bugs.webkit.org/show_bug.cgi?id=201515
3428
3429         JetStream2 code-load related regression (Requested by
3430         yusukesuzuki on #webkit).
3431
3432         Reverted changeset:
3433
3434         "Keyword lookup can use memcmp to get around unaligned load
3435         undefined behavior"
3436         https://bugs.webkit.org/show_bug.cgi?id=199650
3437         https://trac.webkit.org/changeset/247463
3438
3439 2019-09-05  Tadeu Zagallo  <tzagallo@apple.com>
3440
3441         LazyClassStructure::setConstructor should not store the constructor to the global object
3442         https://bugs.webkit.org/show_bug.cgi?id=201484
3443         <rdar://problem/50400451>
3444
3445         Reviewed by Yusuke Suzuki.
3446
3447         LazyClassStructure::setConstructor sets the constructor as a property of the global object.
3448         This became a problem when it started being used for WebAssembly constructors, such as Module
3449         and Instance, since they are properties of the WebAssembly object, not the global object. That
3450         resulted in properties of the global object replaced whenever a lazy WebAssembly constructor
3451         was first accessed. e.g.
3452
3453         globalThis.Module = x;
3454         WebAssembly.Module;
3455         globalThis.Module === WebAssembly.Module;
3456
3457         * runtime/LazyClassStructure.cpp:
3458         (JSC::LazyClassStructure::Initializer::setConstructor):
3459         * runtime/LazyClassStructure.h:
3460         * runtime/Lookup.h:
3461         (JSC::reifyStaticProperty):
3462
3463 2019-09-05  Yusuke Suzuki  <ysuzuki@apple.com>
3464
3465         [JSC] Do not use FTLOutput::weakPointer directly
3466         https://bugs.webkit.org/show_bug.cgi?id=201495
3467
3468         Reviewed by Filip Pizlo.
3469
3470         FTLOutput::weakPointer does not register the cell as a weak pointer.
3471         CreatePromise's implementation is accidentally using m_out.weakPointer and hits the debug assertion.
3472         While the current implementation is not posing correctness issue since these cells are live so long as JSGlobalObject is live,
3473         and we register JSGlobalObject as a weakPointer, we should always use FTLLowerDFGToB3's helper function.
3474         For FrozenValue, we should use frozenPointer helper function.
3475
3476         * ftl/FTLLowerDFGToB3.cpp:
3477         (JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
3478         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
3479
3480 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
3481
3482         Unreviewed, partial roll out r249372 due to JetStream2/Basic ~10% regression
3483         https://bugs.webkit.org/show_bug.cgi?id=201373
3484
3485         * bytecode/BytecodeList.rb:
3486         * bytecode/BytecodeUseDef.h:
3487         (JSC::computeUsesForBytecodeOffset):
3488         (JSC::computeDefsForBytecodeOffset):
3489         * bytecompiler/BytecodeGenerator.cpp:
3490         (JSC::BytecodeGenerator::BytecodeGenerator):
3491         (JSC::BytecodeGenerator::emitLoopHint):
3492         (JSC::BytecodeGenerator::emitCheckTraps):
3493         * bytecompiler/BytecodeGenerator.h:
3494         * dfg/DFGByteCodeParser.cpp:
3495         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
3496         (JSC::DFG::ByteCodeParser::parseBlock):
3497         * dfg/DFGCapabilities.cpp:
3498         (JSC::DFG::capabilityLevel):
3499         * jit/JIT.cpp:
3500         (JSC::JIT::emitEnterOptimizationCheck):
3501         (JSC::JIT::privateCompileMainPass):
3502         (JSC::JIT::privateCompileSlowCases):
3503         * jit/JIT.h:
3504         * jit/JITOpcodes.cpp:
3505         (JSC::JIT::emit_op_enter):
3506         (JSC::JIT::emit_op_loop_hint):
3507         (JSC::JIT::emitSlow_op_loop_hint):
3508         (JSC::JIT::emit_op_check_traps):
3509         (JSC::JIT::emitSlow_op_check_traps):
3510         (JSC::JIT::emitSlow_op_enter): Deleted.
3511         * jit/JITOpcodes32_64.cpp:
3512         (JSC::JIT::emit_op_enter):
3513         * llint/LowLevelInterpreter.asm:
3514         * llint/LowLevelInterpreter32_64.asm:
3515         * llint/LowLevelInterpreter64.asm:
3516         * runtime/CommonSlowPaths.cpp:
3517         (JSC::SLOW_PATH_DECL):
3518         * runtime/CommonSlowPaths.h:
3519
3520 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
3521
3522         Unreviewed, rebaseline builtin generator test results
3523         https://bugs.webkit.org/show_bug.cgi?id=200898
3524
3525         Rebaseline the result files.
3526
3527         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
3528         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
3529         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
3530         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
3531         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
3532         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
3533         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
3534         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
3535         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
3536         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
3537         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3538         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
3539         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
3540
3541 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
3542
3543         [JSC] FunctionOverrides should have a lock to ensure concurrent access to hash table does not happen
3544         https://bugs.webkit.org/show_bug.cgi?id=201485
3545
3546         Reviewed by Tadeu Zagallo.
3547
3548         FunctionOverrides is a per-process singleton for registering overrides information. But we are accessing
3549         it without taking a lock. If multiple threads with multiple VMs are accessing this concurrently, we have
3550         a race issue like,
3551
3552         1. While one thread is adding overrides information,
3553         2. Another thread is accessing this hash table.
3554
3555         This patch adds a lock to make sure that only one thread can access this registry.
3556
3557         * tools/FunctionOverrides.cpp:
3558         (JSC::FunctionOverrides::FunctionOverrides):
3559         (JSC::FunctionOverrides::reinstallOverrides):
3560         (JSC::FunctionOverrides::initializeOverrideFor):
3561         (JSC::FunctionOverrides::parseOverridesInFile):
3562         * tools/FunctionOverrides.h:
3563         (JSC::FunctionOverrides::clear):
3564
3565 2019-09-04  Yusuke Suzuki  <ysuzuki@apple.com>
3566
3567         [JSC] Make Promise implementation faster
3568         https://bugs.webkit.org/show_bug.cgi?id=200898
3569
3570         Reviewed by Saam Barati.
3571
3572         This is the major change of the Promise implementation and it improves JetStream2/async-fs by 62%.
3573
3574         1. Make JSPromise C++ friendly
3575
3576             Instead of using objects with private properties (properties with private symbols), we put internal fields in JSPromise.
3577             This avoids allocating unnecessary butterflies for these private fields, and makes allocating JSPromise and accessing these
3578             fields from C++ easy. Moreover, this patch reduces # of fields of JSPromise from 4 to 2 to make JSPromise compact. To access these internal
3579             fields efficiently from JS, we add `op_get_promise_internal_field` and `op_put_promise_internal_field` bytecodes, and corresponding DFG/FTL
3580             supports. They are similar to GetClosureVar / PutClosureVar implementation. These two bytecodes are intentionally generic to later expand
3581             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].
3582
3583             We also add JSPromiseType as JSType. And structures for JSPromise should have that. So that now `@isPromise` is efficiently implemented.
3584             This also requires adding SpecPromiseObject and PromiseObjectUse to DFG.
3585
3586             Further, by introducing another bit flag representing `alreadyResolved` to JSPromise's flags, we can remove JSPromiseDeferred. This extension
3587             is filed in [2].
3588
3589         2. Make JSPromise constructor JS friendly
3590
3591             The old JSPromise constructor was very inefficient: JSPromise constructor is InternalFunction in C++, and in it, it
3592             calls `initializePromise` JS function. And this `initializePromise` function invokes `executor` function passed by user program.
3593             If we can implement JSPromise constructor fully in JS, we can recognize `executor` and we have a chance to fully inline them.
3594             Unfortunately, we cannot inline JSPromise constructor for now since it takes 120 bytecode cost while our inlining threshold for
3595             construct is 100. We might want to investigate getting it inlined in the future[3].
3596
3597             We can avoid C++ <-> JS dance in such an important operation, allocating JSPromise. This patch introduces @nakedConstructor
3598             annotation to builtin JS. And this is propagated as `ConstructorKind::Naked`. If this kind is attached, the bytecode generator
3599             do not emit `op_create_this` implicitly and the constructor does not return `this` object implicitly. The naked constructor allows
3600             us to emit bare-metal bytecode, specifically necessary to allocate non-final JSObject from JS constructor. We introduce op_create_promise,
3601             which is similar to op_create_this, but it allocates JSPromise. And by using @createPromise bytecode intrinsic, we implement
3602             JSPromise constructor fully in JS.
3603             With this, we can start introducing object-allocation-sinking for JSPromise too. It is filed in [4].
3604
3605         3. DFG supports for JSPromise operations
3606
3607             This patch adds four DFG nodes, CreatePromise, NewPromise, GetPromiseInternalField, and PutPromiseInternalField. CreatePromise mimics CreateThis,
3608             and NewPromise mimics NewObject. CreatePromise can be converted to NewPromise with some condition checks and NewPromise can efficiently allocate
3609             promises. CreatePromise and NewPromise have `isInternalPromise` flag so that InternalPromise is also correctly handled in DFG.
3610             When converting CreatePromise to NewPromise, we need to get the correct structure with a specified `callee.prototype`. We mimic the mechanism
3611             used in CreateThis, but we use InternalFunctionAllocationProfile instead of ObjectAllocationProfile because (1) InternalFunctionAllocationProfile
3612             can handle non-final JSObjects and (2) we do not need to handle inline-capacity for promises. To make InternalFunctionAllocationProfile usable
3613             in DFG, we connect watchpoint to InternalFunctionAllocationProfile's invalidation so that DFG code can notice when InternalFunctionAllocationProfile's
3614             structure is invalidated: `callee.prototype` is replaced.
3615
3616         4. Avoid creating unnecessary promises
3617
3618             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.
3619             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
3620             intermediate promise. To handle these things well, we introduce `@resolveWithoutPromise`, `@rejectWithoutPromise`, and `@fulfillWithoutPromise`. They
3621             take `onFulfilled` and `onRejected` handlers and they do not need an intermediate promise for resolving. This removes internal promise allocations
3622             in major cases and makes promise / async-functions efficient. And we also expose builtin `then` function as `@then`, and insert `@isPromise(xxx) && then === @then`
3623             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.
3624
3625         5. Avoid creating resolving-functions and promise capabilities
3626
3627             Resolving functions have `alreadyResolved` flag to prevent calling `resolve` and `reject` multiple times. For the first resolving function creation, this
3628             patch embeds one bit flag to JSPromise itself which indicates `alreadyResolved` in the first created resolving functions (resolving functions can be later
3629             created again for the same promise. In that case, we just create a usual resolving functions). By doing so, we avoid unnecessary resolving functions
3630             and promise capability allocations. We introduce a wrapper function `@resolvePromiseWithFirstResolvingFunctionCallCheck` and `@rejectPromiseWithFirstResolvingFunctionCallCheck`.
3631             The resolving functions which are first created with `@newPromiseCapability` can be mechanically replaced with the calls to these functions, e.g. replacing
3632             `promiseCapability.@resolve.@call(@undefined, value)` with `@resolvePromiseWithFirstResolvingFunctionCallCheck(promise, value)`.
3633             This mechanism will be used to drop JSPromiseDeferred in a separate patch.
3634
3635         JetStream2/async-fs results.
3636             ToT:
3637                 Running async-fs:
3638                     Startup: 116.279
3639                     Worst Case: 151.515
3640                     Average: 176.630
3641                     Score: 145.996
3642                     Wall time: 0:01.149
3643
3644             Patched:
3645                 Running async-fs:
3646                     Startup: 166.667
3647                     Worst Case: 267.857
3648                     Average: 299.080
3649                     Score: 237.235
3650                     Wall time: 0:00.683
3651
3652         [1]: https://bugs.webkit.org/show_bug.cgi?id=201159
3653         [2]: https://bugs.webkit.org/show_bug.cgi?id=201160
3654         [3]: https://bugs.webkit.org/show_bug.cgi?id=201452
3655         [4]: https://bugs.webkit.org/show_bug.cgi?id=201158
3656
3657         * CMakeLists.txt:
3658         * JavaScriptCore.xcodeproj/project.pbxproj:
3659         * Scripts/wkbuiltins/builtins_generate_combined_header.py:
3660         (ConstructAbility):
3661         (ConstructorKind):
3662         * Scripts/wkbuiltins/builtins_generate_separate_header.py:
3663         * Scripts/wkbuiltins/builtins_generator.py:
3664         (BuiltinsGenerator.generate_embedded_code_data_for_function):
3665         (BuiltinsGenerator.generate_embedded_code_string_section_for_data):
3666         * Scripts/wkbuiltins/builtins_model.py:
3667         (BuiltinFunction.__init__):
3668         (BuiltinFunction.fromString):
3669         * Scripts/wkbuiltins/builtins_templates.py:
3670         * builtins/AsyncFromSyncIteratorPrototype.js:
3671         (next.try):
3672         (next):
3673         (return.try):
3674         (return):
3675         (throw.try):
3676         (throw):
3677         * builtins/AsyncFunctionPrototype.js:
3678         (globalPrivate.asyncFunctionResume):
3679         * builtins/AsyncGeneratorPrototype.js:
3680         (globalPrivate.asyncGeneratorQueueIsEmpty):
3681         (globalPrivate.asyncGeneratorQueueEnqueue):
3682         (globalPrivate.asyncGeneratorQueueDequeue):
3683         (globalPrivate.asyncGeneratorReject):
3684         (globalPrivate.asyncGeneratorResolve):
3685         (globalPrivate.asyncGeneratorYield):
3686         (onRejected):
3687         (globalPrivate.awaitValue):
3688         (onFulfilled):
3689         (globalPrivate.doAsyncGeneratorBodyCall):
3690         (globalPrivate.asyncGeneratorResumeNext):
3691         (globalPrivate.asyncGeneratorEnqueue):
3692         (globalPrivate.asyncGeneratorDequeue): Deleted.
3693         (const.onRejected): Deleted.
3694         (const.onFulfilled): Deleted.
3695         (globalPrivate.asyncGeneratorResumeNext.): Deleted.
3696         * builtins/BuiltinExecutableCreator.h:
3697         * builtins/BuiltinExecutables.cpp:
3698         (JSC::BuiltinExecutables::defaultConstructorSourceCode):
3699         (JSC::BuiltinExecutables::createDefaultConstructor):
3700         (JSC::BuiltinExecutables::createBuiltinExecutable):
3701         (JSC::BuiltinExecutables::createExecutable):
3702         (JSC::createBuiltinExecutable): Deleted.
3703         * builtins/BuiltinExecutables.h:
3704         * builtins/BuiltinNames.h:
3705         * builtins/BuiltinUtils.h:
3706         * builtins/ModuleLoader.js:
3707         (forceFulfillPromise):
3708         * builtins/PromiseConstructor.js:
3709         (nakedConstructor.Promise.resolve):
3710         (nakedConstructor.Promise.reject):
3711         (nakedConstructor.Promise):
3712         (nakedConstructor.InternalPromise.resolve):
3713         (nakedConstructor.InternalPromise.reject):
3714         (nakedConstructor.InternalPromise):
3715         * builtins/PromiseOperations.js:
3716         (globalPrivate.newPromiseReaction):
3717         (globalPrivate.newPromiseCapability):
3718         (globalPrivate.newHandledRejectedPromise):
3719         (globalPrivate.triggerPromiseReactions):
3720         (globalPrivate.resolvePromise):
3721         (globalPrivate.rejectPromise):
3722         (globalPrivate.fulfillPromise):
3723         (globalPrivate.resolvePromiseWithFirstResolvingFunctionCallCheck):
3724         (globalPrivate.rejectPromiseWithFirstResolvingFunctionCallCheck):
3725         (globalPrivate.createResolvingFunctions.resolve):
3726         (globalPrivate.createResolvingFunctions.reject):
3727         (globalPrivate.createResolvingFunctions):
3728         (globalPrivate.promiseReactionJobWithoutPromise):
3729         (globalPrivate.resolveWithoutPromise):
3730         (globalPrivate.rejectWithoutPromise):
3731         (globalPrivate.fulfillWithoutPromise):
3732         (resolve):
3733         (reject):
3734         (globalPrivate.createResolvingFunctionsWithoutPromise):
3735         (globalPrivate.promiseReactionJob):
3736         (globalPrivate.promiseResolveThenableJobFast):
3737         (globalPrivate.promiseResolveThenableJobWithoutPromiseFast):
3738         (globalPrivate.promiseResolveThenableJob):
3739         (globalPrivate.isPromise): Deleted.
3740         (globalPrivate.newPromiseCapability.executor): Deleted.
3741         (globalPrivate.initializePromise): Deleted.
3742         * builtins/PromisePrototype.js:
3743         (then):
3744         * bytecode/BytecodeIntrinsicRegistry.cpp:
3745         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3746         * bytecode/BytecodeIntrinsicRegistry.h:
3747         * bytecode/BytecodeList.rb:
3748         * bytecode/BytecodeUseDef.h:
3749         (JSC::computeUsesForBytecodeOffset):
3750         (JSC::computeDefsForBytecodeOffset):
3751         * bytecode/CodeBlock.cpp:
3752         (JSC::CodeBlock::finishCreation):
3753         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3754         * bytecode/Opcode.h:
3755         * bytecode/SpeculatedType.cpp:
3756         (JSC::dumpSpeculation):
3757         (JSC::speculationFromClassInfo):
3758         (JSC::speculationFromJSType):
3759         (JSC::speculationFromString):
3760         * bytecode/SpeculatedType.h:
3761         * bytecode/UnlinkedFunctionExecutable.h:
3762         * bytecompiler/BytecodeGenerator.cpp:
3763         (JSC::BytecodeGenerator::generate):
3764         (JSC::BytecodeGenerator::BytecodeGenerator):
3765         (JSC::BytecodeGenerator::emitGetPromiseInternalField):
3766         (JSC::BytecodeGenerator::emitPutPromiseInternalField):
3767         (JSC::BytecodeGenerator::emitCreatePromise):
3768         (JSC::BytecodeGenerator::emitNewPromise):
3769         (JSC::BytecodeGenerator::emitReturn):
3770         * bytecompiler/BytecodeGenerator.h:
3771         (JSC::BytecodeGenerator::promiseRegister):
3772         (JSC::BytecodeGenerator::emitIsPromise):
3773         (JSC::BytecodeGenerator::promiseCapabilityRegister): Deleted.
3774         * bytecompiler/NodesCodegen.cpp:
3775         (JSC::promiseInternalFieldIndex):
3776         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getPromiseInternalField):
3777         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putPromiseInternalField):
3778         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isPromise):
3779         (JSC::BytecodeIntrinsicNode::emit_intrinsic_createPromise):
3780         (JSC::BytecodeIntrinsicNode::emit_intrinsic_newPromise):
3781         (JSC::FunctionNode::emitBytecode):
3782         * dfg/DFGAbstractHeap.h:
3783         * dfg/DFGAbstractInterpreterInlines.h:
3784         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3785         * dfg/DFGByteCodeParser.cpp:
3786         (JSC::DFG::ByteCodeParser::parseBlock):
3787         * dfg/DFGCapabilities.cpp:
3788         (JSC::DFG::capabilityLevel):
3789         * dfg/DFGClobberize.h:
3790         (JSC::DFG::clobberize):
3791         * dfg/DFGClobbersExitState.cpp:
3792         (JSC::DFG::clobbersExitState):
3793         * dfg/DFGConstantFoldingPhase.cpp:
3794         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3795         * dfg/DFGDoesGC.cpp:
3796         (JSC::DFG::doesGC):
3797         * dfg/DFGFixupPhase.cpp:
3798         (JSC::DFG::FixupPhase::fixupNode):
3799         * dfg/DFGGraph.cpp:
3800         (JSC::DFG::Graph::dump):
3801         * dfg/DFGHeapLocation.cpp:
3802         (WTF::printInternal):
3803         * dfg/DFGHeapLocation.h:
3804         * dfg/DFGMayExit.cpp:
3805         * dfg/DFGNode.h:
3806         (JSC::DFG::Node::convertToNewPromise):
3807         (JSC::DFG::Node::hasIsInternalPromise):
3808         (JSC::DFG::Node::isInternalPromise):