Keyframe animation doesn't 't show up in the Animations timeline
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2020-06-23  Devin Rousso  <drousso@apple.com>
2
3         Keyframe animation doesn't 't show up in the Animations timeline
4         https://bugs.webkit.org/show_bug.cgi?id=213441
5
6         Reviewed by Brian Burg.
7
8         * inspector/protocol/Animation.json:
9         An `interationCount` of `Infinity` is not JSON serializable, so represent it as `-1` instead.
10
11 2020-06-22  Saam Barati  <sbarati@apple.com>
12
13         Attempt to fix watchOS simulator build.
14
15         * assembler/FastJITPermissions.h:
16         (threadSelfRestrictRWXToRW):
17         (threadSelfRestrictRWXToRX):
18
19 2020-06-22  Saam Barati  <sbarati@apple.com>
20
21         Allow building JavaScriptCore Mac+arm64 in public SDK build
22         https://bugs.webkit.org/show_bug.cgi?id=213472
23
24         Reviewed by Sam Weinig.
25
26         We used to only builld code for fast permission switching when using the
27         Apple internal SDK. However, with arm64 on macOS, this is no longer a viable
28         implementation strategy.
29         
30         This patch makes it so we can build JSC on macOS+arm64 using the public Xcode
31         SDK.
32         
33         - ENABLE_FAST_JIT_PERMISSIONS is removed. We now use runtime checks instead.
34         - In the new suite of OS betas, pthreads has added API for fast permissions
35           switching. We now use this API instead of using the non-public SDK found in
36           the kernel headers.
37         - We fall back to the separated W/X heaps when fast permissions checking is
38           not supported. This all happens at runtime.
39
40         * CMakeLists.txt:
41         * JavaScriptCore.xcodeproj/project.pbxproj:
42         * assembler/ARM64Assembler.h:
43         (JSC::ARM64Assembler::fillNops):
44         * assembler/ARMv7Assembler.h:
45         (JSC::ARMv7Assembler::fillNops):
46         * assembler/FastJITPermissions.h: Added.
47         (useFastJITPermissions):
48         (threadSelfRestrictRWXToRW):
49         (threadSelfRestrictRWXToRX):
50         (fastJITPermissionsIsSupported):
51         * assembler/LinkBuffer.cpp:
52         (JSC::memcpyWrapper):
53         (JSC::LinkBuffer::copyCompactAndLinkCode):
54         * assembler/MIPSAssembler.h:
55         (JSC::MIPSAssembler::fillNops):
56         * assembler/MacroAssemblerARM64.h:
57         (JSC::MacroAssemblerARM64::link):
58         * assembler/MacroAssemblerARMv7.h:
59         (JSC::MacroAssemblerARMv7::link):
60         * jit/ExecutableAllocator.cpp:
61         (JSC::initializeJITPageReservation):
62         * jit/ExecutableAllocator.h:
63         (JSC::performJITMemcpy):
64         (JSC::useFastJITPermissions): Deleted.
65         * runtime/JSCConfig.h:
66         * runtime/Options.cpp:
67         (JSC::Options::recomputeDependentOptions):
68         * runtime/OptionsList.h:
69
70 2020-06-22  Tim Horton  <timothy_horton@apple.com>
71
72         Disable the JS JIT when running in a translated process
73         https://bugs.webkit.org/show_bug.cgi?id=213478
74
75         Reviewed by Saam Barati.
76
77         * runtime/Options.cpp:
78         (JSC::Options::recomputeDependentOptions):
79         Based on our performance experiements, disable the JavaScript JIT
80         (but not the regular expression, DOM, or Wasm JIT) when running
81         in a translated process.
82
83 2020-06-22  Tim Horton  <timothy_horton@apple.com>
84
85         Update macOS version macros
86         https://bugs.webkit.org/show_bug.cgi?id=213484
87
88         Reviewed by Alexey Proskuryakov.
89
90         * Configurations/Base.xcconfig:
91         * Configurations/DebugRelease.xcconfig:
92         * Configurations/Version.xcconfig:
93         * Configurations/WebKitTargetConditionals.xcconfig:
94
95 2020-06-19  Yusuke Suzuki  <ysuzuki@apple.com>
96
97         [JSC] Check Gigacage usage before launching VM
98         https://bugs.webkit.org/show_bug.cgi?id=213410
99
100         Reviewed by Mark Lam.
101
102         Since VM allocates JSBigInt from Gigacage, it is possible that VM creation fails when Gigacage is exhausted.
103         As a work-around for internal testing, we insert ad-hoc Gigacage usage check before launching a new agent.
104         If 80% of Gigacage is used, we fail to launch a new VM gracefully.
105
106         * assembler/testmasm.cpp:
107         (JSC::testCagePreservesPACFailureBit):
108         * jsc.cpp:
109         (functionDollarAgentStart):
110
111 2020-06-19  James Darpinian  <jdarpinian@chromium.org>
112
113         Typed array constructor behaves differently when length is not passed or when undefined is passed
114         https://bugs.webkit.org/show_bug.cgi?id=184232
115
116         Reviewed by Yusuke Suzuki.
117
118         Passing undefined for length should have the same effect as omitting the argument. It was being
119         treated as 0 instead.
120
121         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
122         (JSC::constructGenericTypedArrayView):
123
124 2020-06-19  Yusuke Suzuki  <ysuzuki@apple.com>
125
126         [JSC] Attempt to reduce timeout failures on Apple Watch Series 3
127         https://bugs.webkit.org/show_bug.cgi?id=213419
128
129         Reviewed by Mark Lam.
130
131         * tools/JSDollarVM.cpp:
132         (JSC::functionUseJIT):
133         (JSC::JSDollarVM::finishCreation):
134
135 2020-06-19  Mark Lam  <mark.lam@apple.com>
136
137         toString of String doesn't check integrity of structureID in one path.
138         https://bugs.webkit.org/show_bug.cgi?id=213338
139
140         Reviewed by Saam Barati.
141
142         * runtime/StringPrototype.cpp:
143         (JSC::stringProtoFuncToString):
144
145 2020-06-19  Saam Barati  <sbarati@apple.com>
146
147         Have a memory monitor thread in jsc shell when running tests using --memory-limited
148         https://bugs.webkit.org/show_bug.cgi?id=213389
149
150         Reviewed by Mark Lam.
151
152         When testing on iOS, there are times high memory usage from a JSC test
153         will jetsam our entire test runner. This makes it so we don't get any test
154         results from that test run, which can make it difficult to track testing
155         results.
156         
157         This patch introduces an optional memory monitoring thread to the JSC
158         shell. It's a best effort approach. If memory usage exceeds the passed
159         in threshold, we crash the process. Similar to how the timeout mechanism
160         works. On Cocoa platforms, we also perform this check in the low memory 
161         warning handler.
162         
163         Currently, we use this feature when running JSC stress tests in
164         "--memory-limited" mode.
165
166         * jsc.cpp:
167         (crashIfExceedingMemoryLimit):
168         (startMemoryMonitoringThreadIfNeeded):
169         (jscmain):
170
171 2020-06-19  Mark Lam  <mark.lam@apple.com>
172
173         Make $vm properties non-configurable, non-enumerable, and non-writable.
174         https://bugs.webkit.org/show_bug.cgi?id=213395
175
176         Reviewed by Saam Barati and Yusuke Suzuki.
177
178         $vm provides functions for test development and VM debugging.  There's no reason
179         for them to be configurable, enumerable, and writable.
180
181         We particularly don't want them to be enumerable as this can trip up some fuzzers.
182         Fuzzers should not be fuzzing the $vm object which doesn't exist in real world
183         uses of JavaScriptCore.
184
185         * tools/JSDollarVM.cpp:
186         (JSC::JSDollarVM::finishCreation):
187         (JSC::JSDollarVM::addFunction):
188         (JSC::JSDollarVM::addConstructibleFunction):
189
190 2020-06-19  Tuomas Karkkainen  <tuomas.webkit@apple.com>
191
192         functionCpuClflush checks that the second argument is Int32 but it actually expects it to be UInt32
193         https://bugs.webkit.org/show_bug.cgi?id=213388
194
195         Reviewed by Saam Barati.
196
197         This changes the check from isInt32() to isUInt32() so that the logic is consistent.
198
199         * tools/JSDollarVM.cpp:
200
201 2020-06-18  Mark Lam  <mark.lam@apple.com>
202
203         Unify Bitmap math loops in MarkedBlock::Handle::specializedSweep().
204         https://bugs.webkit.org/show_bug.cgi?id=213345
205
206         Reviewed by Robin Morisset and Saam Barati.
207
208         This change appears to be performance neutral.  However, we'll take the change
209         because we know that it does less work, and the new way of expressing the Bitmap
210         math in MarkedBlock::Handle::specializedSweep() does appear to be easier to
211         understand than the old code.
212
213         Also addressed feedback from Robin and Saam in https://bugs.webkit.org/show_bug.cgi?id=213071.
214
215         Changes made:
216
217         1. Use the new Bitmap::words() API to get direct access to the underlying bits
218            storage.  With this, we can do the merging of the marked and newlyAllocated
219            bits with a single pass looping thru the bitmap words.
220
221         2. In MarkedBlock::Handle::specializedSweep()'s Bitmap free list code, moved the
222            implementation of handleDeadCells lambda down to the call to freeAtoms.forEachSetBit()
223            because this is the only place it is used.
224
225         3. Fixed MarkedBlock::Handle::specializedSweep()'s Bitmap free list code to
226            handle the dead cells unconditionally.  This condition check was wrongly
227            adapted from the linked list implementation where handleDeadCell() was called
228            in 2 places depending on the destruction mode.  With the Bitmap free list,
229            there is only once place to handle the dead cells, and it should be executed
230            unconditionally.
231
232            This fixes a bug where the FreeList::originalSize() never gets computed if the
233            cells in the block does not need destruction.
234
235         4. Renamed FreeList::bitmapRows() to FreeList::bitmapRowsMinusOne().
236            Renamed FreeList::offsetOfBitmapRows() to FreeList::offsetOfBitmapRowsMinusOne().
237
238         5. Also fixed some typos in comments.
239
240         * heap/FreeList.h:
241         (JSC::FreeList::bitmapIsEmpty const):
242         (JSC::FreeList::offsetOfBitmapRowsMinusOne):
243         (JSC::FreeList::bitmapRowsMinusOne const):
244         (JSC::FreeList::offsetOfBitmapRows): Deleted.
245         (JSC::FreeList::bitmapRows const): Deleted.
246         * heap/FreeListInlines.h:
247         (JSC::FreeList::allocate):
248         (JSC::FreeList::forEach const):
249         * heap/MarkedBlockInlines.h:
250         (JSC::MarkedBlock::Handle::specializedSweep):
251         * jit/AssemblyHelpers.cpp:
252         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
253
254 2020-06-18  Yusuke Suzuki  <ysuzuki@apple.com>
255
256         [JSC] Remove dead non-ICU locale Date code since we are always using ICU version
257         https://bugs.webkit.org/show_bug.cgi?id=213362
258
259         Reviewed by Ross Kirsling.
260
261         There are old non-ICU version of Date locale code. But this is now dead code since we are always using ICU version,
262         which is invoked from builtin JS DatePrototype.js. We should remove these dead code.
263
264         * runtime/DatePrototype.cpp:
265         (JSC::DatePrototype::finishCreation):
266         (): Deleted.
267         (JSC::styleFromArgString): Deleted.
268         (JSC::formatLocaleDate): Deleted.
269         (JSC::dateProtoFuncToLocaleString): Deleted.
270         (JSC::dateProtoFuncToLocaleDateString): Deleted.
271         (JSC::dateProtoFuncToLocaleTimeString): Deleted.
272
273 2020-06-18  Ross Kirsling  <ross.kirsling@sony.com>
274
275         Unreviewed, address Darin's feedback on r263227.
276
277         * runtime/IntlRelativeTimeFormat.cpp:
278         (JSC::IntlRelativeTimeFormat::UNumberFormatDeleter::operator() const):
279         (JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
280         (JSC::IntlRelativeTimeFormat::formatToParts const):
281         * runtime/IntlRelativeTimeFormat.h:
282         Keep ownership over our UNumberFormat instance after all,
283         to avoid relying on behavior ICU isn't explicitly guaranteeing.
284
285 2020-06-18  Ross Kirsling  <ross.kirsling@sony.com>
286
287         [Intl] Enable RelativeTimeFormat and Locale by default
288         https://bugs.webkit.org/show_bug.cgi?id=213324
289
290         Reviewed by Yusuke Suzuki.
291
292         * runtime/IntlObject.cpp:
293         (JSC::createDateTimeFormatConstructor):
294         (JSC::createLocaleConstructor):
295         (JSC::createNumberFormatConstructor):
296         (JSC::createRelativeTimeFormatConstructor):
297         (JSC::IntlObject::finishCreation):
298         Unconditionalize creation of RelativeTimeFormat and Locale constructors.
299
300         * runtime/IntlRelativeTimeFormat.cpp:
301         (JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
302         (JSC::IntlRelativeTimeFormat::formatToParts const):
303         (JSC::IntlRelativeTimeFormat::UNumberFormatDeleter::operator() const): Deleted.
304         * runtime/IntlRelativeTimeFormat.h:
305         Fix an actual bug -- URelativeDateTimeFormatter *adopts* the UNumberFormat it's instantiated with,
306         so we can't keep a unique_ptr to it.
307
308         * runtime/OptionsList.h:
309         Remove feature flags.
310
311 2020-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>
312
313         Promise built-in functions should be anonymous non-constructors
314         https://bugs.webkit.org/show_bug.cgi?id=213317
315
316         Reviewed by Darin Adler.
317
318         This patch makes userland-exposed Promise built-in functions
319         non-constructors and sets their "name" properties to empty strings
320         as per spec [1], aligning JSC with V8 and SpiderMonkey.
321
322         @createResolvingFunctionsWithoutPromise change is covered by test262's
323         async-generator/yield-thenable-create-resolving-functions-*.js cases.
324
325         Promise microbenchmarks are neutral. Promise constructors bytecode is
326         unchanged, while @createResolvingFunctions* bytecode is reduced by 2
327         instructions.
328
329         [1]: https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects
330
331         * builtins/PromiseConstructor.js:
332         (nakedConstructor.Promise):
333         (nakedConstructor.InternalPromise):
334         * builtins/PromiseOperations.js:
335         (globalPrivate.newPromiseCapabilitySlow):
336         (globalPrivate.createResolvingFunctions):
337         (globalPrivate.createResolvingFunctionsWithoutPromise):
338         (globalPrivate.createResolvingFunctions.resolve): Deleted.
339         (globalPrivate.createResolvingFunctions.reject): Deleted.
340         (resolve): Deleted.
341         (reject): Deleted.
342         * builtins/PromisePrototype.js:
343         (globalPrivate.getThenFinally):
344         (globalPrivate.getCatchFinally):
345         (valueThunk): Deleted.
346         (thrower): Deleted.
347
348 2020-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>
349
350         TypedArray.prototype.set is incorrect with primitives
351         https://bugs.webkit.org/show_bug.cgi?id=212730
352
353         Reviewed by Yusuke Suzuki.
354
355         This change implements step 14 of %TypedArray%.prototype.set [1],
356         which coerces primitives to objects instead of throwing an error,
357         aligning JSC with V8 and SpiderMonkey.
358
359         [1]: https://tc39.es/ecma262/#sec-%typedarray%.prototype.set-array-offset
360
361         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
362         (JSC::genericTypedArrayViewProtoFuncSet):
363
364 2020-06-17  Mark Lam  <mark.lam@apple.com>
365
366         Replace JSC::FreeList linked list with a Bitmap.
367         https://bugs.webkit.org/show_bug.cgi?id=213071
368
369         Reviewed by Filip Pizlo.
370
371         Implement an alternative to the linked list FreeList.  This alternative uses
372         a Bitmap to record which atom in the block is available for allocation.
373
374         The intuition here is that allocation using the Bitmap implementation will do:
375             2 loads - m_currentRowBitmap, m_currentMarkedBlockRowAddress
376             1 store - m_currentRowBitmap
377
378         whereas the linked list implementation will do:
379             3 loads - m_scrambledHead, m_secret, result->scrambledNext
380             1 store - m_scrambledHead
381
382         and result->scrambledNext is from a different region of code and therefore not
383         in the same cache line.
384
385         The downside of the Bitmap implementation is that it uses more instructions.
386
387         This change is currently only enabled for x86_64, which shows about a 0.8%
388         progression on Speedometer 2.
389
390         It appears to be about a 1% regression on ARM64E.  Hence, for now, we keep the
391         linked list implementation for ARM64 builds.
392
393         This is how the Bitmap FreeList works:
394
395         1. The Bitmap implementation only replaces the linked list implementation.  It
396            does not replace the bump allocator.
397
398         2. The Bitmap allocator keeps a m_bitmap that is initialized in
399            MarkedBlock::Handle::specializedSweep() to have a bit set for each atom
400            location that is available for allocation (i.e. is free).  Note that a cell
401            is usually allocated using more than 1 atom.  Only the bit corresponding to
402            the first atom (in that cell length range of free atoms) will be set.
403
404            This is consistent with how bits in MarkedBlock::Footer::m_marks and
405            MarkedBlock::Footer::m_newlyAllocated are set i.e. only the bit for the first
406            atom in the cell can be set.
407
408         3. The allocation algorithm thinks of the MarkedBlock as consisting of rows
409            of atoms, where the number of atoms in a row equals the number of bits in
410            a AtomsBitmap::Word.  On 64-bit CPUs, this would be 64.
411
412            We will start allocating from the last (highest numbered) row down to the
413            first (row 0).  As we allocate, we will only update m_currentRowIndex and
414            m_currentRowBitmap.  m_bitmap will not be updated.  This is so in order to
415            reduce the number of instructions executed during an allocation.
416
417            When m_currentRowIndex points to N, the AtomsBitmap::Word for row N in
418            m_bitmap will have been copied into m_currentRowBitmap.  This is the row
419            that we will be allocating from until the row is exhausted.
420
421            This is how we know whether an atom is available for allocation or not:
422              i. Atoms in any rows above m_currentRowIndex are guaranteed to be
423                 allocated already (because we allocate downwards), and hence, are not
424                 available.
425             ii. For row m_currentRowIndex, m_currentRowBitmap is the source of truth
426                 on which atoms in the row are available for allocation.
427            iii. For rows below m_currentRowIndex, m_bitmap is the source of truth on
428                 which atoms are available for allocation.
429
430            When m_currentRowIndex reaches 0, the info in m_bitmap is completely
431            obsoleted, and m_currentRowBitmap holds the availability info for row 0.
432            When both m_currentRowIndex and m_currentRowBitmap are 0, then we have
433            completely exhausted the block and no more atoms are available for
434            allocation.
435
436         4. Allocation happens in 3 paths: fast, middle, slow.
437
438            The fast path checks m_currentRowBitmap.  If it's not 0, then we compute the
439            bit number of the lowest set bit in it.  That bit number will be used together
440            with m_currentMarkedBlockRowAddress to compute the address of the atom
441            location available for allocation.  m_currentRowBitmap will be updated to clear
442            the bit for the atom that has just ben allocated.
443
444            If m_currentRowBitmap is 0, then we'll go to the middle path.
445
446            The middle path checks m_currentRowIndex to see if we have more rows to allocate
447            from.  For each m_currentRowIndex, we check its corresponding AtomsBitmap::Word
448            in m_bitmap.  If the word is non-zero, we copy it to m_currentRowBitmap and
449            jump to the fast path to do the allocation.  The middle path will update
450            m_currentRowIndex to point to the current row we're allocating from.
451
452            If we have decremented m_currentRowIndex down to 0 but still can't find a
453            non-zero AtomsBitmap::Word in m_bitmap, then the block has been exhausted, and
454            we'll go to the slow path.
455
456            The slow path is analogous to the old slow path i.e. we try to refill the
457            LocalAllocator with a new MarkedBlock.
458
459         5. On the layout of fields in FreeList (see changes in FreeList.h), we try to
460            preserve the positions of the bump allocator fields.  The only change we made
461            there is in the location of m_cellSize.  It is now moved up next to m_remaining,
462            and m_originalSize is moved down.  This is because m_originalSize is only
463            accessed in the slow path, and m_cellSize is accessed in the bump allocation
464            path.
465
466            Next, we try to put Bitmap allocation fields where the linked list fields
467            would have been.  The one bit of trickiness is that we'll put
468            m_currentMarkedBlockRowAddress in a union with m_payloadEnd.  This is because
469            m_payloadEnd is only used in the bump allocation path.  If m_remaining is 0,
470            then we can reuse this location for m_currentMarkedBlockRowAddress.
471
472            With this, we would have 4 bytes of padding after m_currentRowIndex.  For
473            compactness, we put m_originalSize there in that space.  For builds that use
474            the linked list implementation, m_originalSize will be located below after
475            m_cellSize.
476
477         * ftl/FTLLowerDFGToB3.cpp:
478         (JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
479         * heap/FreeList.cpp:
480         (JSC::FreeList::clear):
481         (JSC::FreeList::initializeAtomsBitmap):
482         (JSC::FreeList::initializeBump):
483         (JSC::FreeList::contains const):
484         (JSC::FreeList::dump const):
485         * heap/FreeList.h:
486         (JSC::FreeList::bitmapIsEmpty const):
487         (JSC::FreeList::allocationWillFail const):
488         (JSC::FreeList::offsetOfCurrentRowBitmap):
489         (JSC::FreeList::offsetOfBitmapRows):
490         (JSC::FreeList::offsetOfCurrentRowIndex):
491         (JSC::FreeList::offsetOfCurrentMarkedBlockRowAddress):
492         (JSC::FreeList::offsetOfRemaining):
493         (JSC::FreeList::atomsBitmap):
494         (JSC::FreeList::bitmapRows const):
495         (JSC::FreeList::offsetOfOriginalSize): Deleted.
496         * heap/FreeListInlines.h:
497         (JSC::FreeList::allocate):
498         (JSC::FreeList::forEach const):
499         * heap/LocalAllocator.cpp:
500         (JSC::LocalAllocator::isFreeListedCell const):
501         * heap/MarkedBlock.h:
502         (JSC::MarkedBlock::Handle::atomAt const):
503         * heap/MarkedBlockInlines.h:
504         (JSC::MarkedBlock::Handle::specializedSweep):
505         * jit/AssemblyHelpers.cpp:
506         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
507         * jit/AssemblyHelpers.h:
508         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
509
510 2020-06-17  Mark Lam  <mark.lam@apple.com>
511
512         StructureIDTable::validate() doesn't work when compiled with GCC.
513         https://bugs.webkit.org/show_bug.cgi?id=213302
514         <rdar://problem/64452172>
515
516         Reviewed by Yusuke Suzuki.
517
518         I was previously using ensureStillAliveHere() to force the validation load to
519         not be elided.  However, this is not how ensureStillAliveHere() works.  The proper
520         way to force the load is to use a volatile pointer instead, which is applied in
521         this patch.
522
523         With Clang, the ensureStillAliveHere() happened to do what I expected, but with
524         GCC it did not.  The compiler is at liberty to elide the load because there is
525         no memory clobbering operation between the load and the call to
526         ensureStillAliveHere().  Switching to using the volatile pointer solution.
527
528         * runtime/StructureIDTable.h:
529         (JSC::StructureIDTable::validate):
530
531 2020-06-17  Yusuke Suzuki  <ysuzuki@apple.com>
532
533         [JSC] Freeze JSBigInt when setting it as a constant in AI
534         https://bugs.webkit.org/show_bug.cgi?id=213310
535         <rdar://problem/64450410>
536
537         Reviewed by Mark Lam.
538
539         JSCells should be explicitly frozen via DFG::Graph::freeze or DFG::Graph::freezeStrong. And heap JSBigInt is JSCell.
540         We should freeze it before setting it as a parameter of setConstant in AI. We use DFG::Graph::freeze since we know
541         that this is coming from somewhere in DFG graph: this ToNumeric node itself is not newly producing this JSBigInt.
542
543         * dfg/DFGAbstractInterpreterInlines.h:
544         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
545
546 2020-06-17  Keith Miller  <keith_miller@apple.com>
547
548         $vm.haveABadTime/isHavingABadTime should work with non-globalObject parameters
549         https://bugs.webkit.org/show_bug.cgi?id=213304
550
551         Reviewed by Mark Lam.
552
553         Previously, $vm.haveABadTime would crash if passed a
554         non-globalObject object as the first parameter because it was
555         missing a `return` in front the error handling case. This patch
556         resolves that issue but also extends the semantics of
557         haveABadTime/isHavingABadTime to either use the global object of
558         the first parameter even if it's not a JSGlobalObject. If no
559         argument is passed, haveABadTime/isHavingABadTime instead use the
560         global object of the callee.
561
562         * tools/JSDollarVM.cpp:
563         (JSC::functionHaveABadTime):
564         (JSC::functionIsHavingABadTime):
565
566 2020-06-17  Mark Lam  <mark.lam@apple.com>
567
568         Gardening: move some unused data inside ENABLE(JIT) to unbreak the CLoop build.
569         https://bugs.webkit.org/show_bug.cgi?id=213255
570
571         Not reviewed.
572
573         * assembler/testmasm.cpp:
574
575 2020-06-17  Yusuke Suzuki  <ysuzuki@apple.com>
576
577         Unreviewed, avoid node access in link-task
578         https://bugs.webkit.org/show_bug.cgi?id=213266
579         <rdar://problem/64453001>
580
581         * ftl/FTLLowerDFGToB3.cpp:
582         (JSC::FTL::DFG::LowerDFGToB3::compileCheckJSCast):
583
584 2020-06-17  Mark Lam  <mark.lam@apple.com>
585
586         Add a shiftAndAdd() emitter in AssemblyHelpers.
587         https://bugs.webkit.org/show_bug.cgi?id=213255
588
589         Reviewed by Michael Saboff.
590
591         void shiftAndAdd(RegisterID base, RegisterID index, uint8_t shift, RegisterID dest, Optional<RegisterID> = { });
592
593         Emits code to compute: dest = base + index << shift.
594
595         * assembler/testmasm.cpp:
596         (doubleOperands):
597         (floatOperands):
598         (int32Operands):
599         (int64Operands):
600         (JSC::testShiftAndAdd):
601         (JSC::run):
602         (JSC::doubleOperands): Deleted.
603         (JSC::floatOperands): Deleted.
604         (JSC::int32Operands): Deleted.
605         (JSC::int64Operands): Deleted.
606         * jit/AssemblyHelpers.h:
607         (JSC::AssemblyHelpers::shiftAndAdd):
608
609 2020-06-17  Michael Saboff  <msaboff@apple.com>
610
611         [Wasm] Reduce the amount of memory used by the Air register coloring allocator
612         https://bugs.webkit.org/show_bug.cgi?id=212106
613
614         Reviewed by Yusuke Suzuki.
615
616         Changed InterferenceEdge to be a templated class so we can instantiate an unsigned
617         short version to cut memory in half for code that has less than 2^16 temps.
618         Through instrumentation, my testing showed that almost all compilations use the
619         16bit implementation.  Although this change is for all B3/Air compilations at O2,
620         Wasm compilations are usally larger and therefore get the greatest benefit.
621
622         This allowed increasing the default value for the option webAssemblyBBQFallbackSize,
623         with a small increase in memory usage.
624
625         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
626         * runtime/OptionsList.h:
627
628 2020-06-16  Yusuke Suzuki  <ysuzuki@apple.com>
629
630         [JSC] Check NullSetterFunction under strict-mode context since structure / PropertyCondition are unaware of this
631         https://bugs.webkit.org/show_bug.cgi?id=213266
632
633         Reviewed by Mark Lam.
634
635         Our PropertyCondition is tracking the shape of Structure. This is enough for IC except for one case: throwing an error when invoking null setters in strict code.
636
637             "use strict";
638             var object = { get value() { return 42; } }
639             object.value = 42;
640
641         In the above case, we need to throw an error. Let's consider the following scenario.
642
643             1. Object has valid setter.
644             2. IC is buffering OPC which includes (1)'s object in [[Prototype]] hit.
645             3. IC commits buffered AccessCase with OPC. And PropertyCondition says Object + setter-offset => Presence.
646             4. Object deletes its setter.
647             5. Just after (4), DFG concurrently reads buffered committed OPCs.
648             6. DFG see that PropertyCondition is valid even after (4) since accessor property does exist.
649             7. Set up DFG sequence `GetSetter, Call`.
650             8. DFG calls null-setter under strict code, which is not assumed to be called.
651
652         In this patch, we insert NullSetterFunction check before setter invocation under strict mode. In IC, if we see NullSetterFunction,
653         we replace the calling target with special function which throws an error. In DFG / FTL, we emit `CheckNotJSCast` DFG node which
654         ensures that this setter is not null setter.
655
656         In IC code, we already have null-setter checking code before. So this change does not have any impact in terms of performance.
657         In DFG / FTL code, we only insert this check when we do not inline this setter. This is because inlining emits `CheckCell` anyway so
658         we can know that this is not NullSetterFunction. And this means that DFG Call opcode exists after CheckNotJSCast. Since Call opcode
659         loads the fields of call target anyway, this also does not affect on performance.
660
661         * bytecode/AccessCase.cpp:
662         (JSC::AccessCase::generateImpl):
663         * bytecode/PolymorphicAccess.cpp:
664         (JSC::PolymorphicAccess::regenerate):
665         * bytecode/PolymorphicAccess.h:
666         (JSC::AccessGenerationState::AccessGenerationState):
667         * bytecode/StructureStubInfo.cpp:
668         (JSC::StructureStubInfo::addAccessCase):
669         * bytecode/StructureStubInfo.h:
670         * dfg/DFGAbstractInterpreterInlines.h:
671         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
672         * dfg/DFGByteCodeParser.cpp:
673         (JSC::DFG::ByteCodeParser::handleCall):
674         (JSC::DFG::ByteCodeParser::handleInlining):
675         (JSC::DFG::ByteCodeParser::handlePutById):
676         * dfg/DFGClobberize.h:
677         (JSC::DFG::clobberize):
678         * dfg/DFGConstantFoldingPhase.cpp:
679         (JSC::DFG::ConstantFoldingPhase::foldConstants):
680         * dfg/DFGDoesGC.cpp:
681         (JSC::DFG::doesGC):
682         * dfg/DFGFixupPhase.cpp:
683         (JSC::DFG::FixupPhase::fixupNode):
684         * dfg/DFGNode.h:
685         (JSC::DFG::Node::hasClassInfo const):
686         * dfg/DFGNodeType.h:
687         * dfg/DFGPredictionPropagationPhase.cpp:
688         * dfg/DFGSafeToExecute.h:
689         (JSC::DFG::safeToExecute):
690         * dfg/DFGSpeculativeJIT.cpp:
691         (JSC::DFG::SpeculativeJIT::compileCheckJSCast):
692         * dfg/DFGSpeculativeJIT32_64.cpp:
693         (JSC::DFG::SpeculativeJIT::compile):
694         * dfg/DFGSpeculativeJIT64.cpp:
695         (JSC::DFG::SpeculativeJIT::compile):
696         * dfg/DFGStructureAbstractValue.cpp:
697         (JSC::DFG::StructureAbstractValue::isNotSubClassOf const):
698         * dfg/DFGStructureAbstractValue.h:
699         * ftl/FTLCapabilities.cpp:
700         (JSC::FTL::canCompile):
701         * ftl/FTLLowerDFGToB3.cpp:
702         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
703         (JSC::FTL::DFG::LowerDFGToB3::compileCheckJSCast):
704         * jit/Repatch.cpp:
705         (JSC::tryCacheGetBy):
706         (JSC::tryCacheArrayGetByVal):
707         (JSC::tryCachePutByID):
708         (JSC::tryCacheDeleteBy):
709         (JSC::tryCacheInByID):
710         (JSC::tryCacheInstanceOf):
711         * jit/ThunkGenerators.cpp:
712         (JSC::virtualThunkFor):
713         * runtime/InternalFunction.cpp:
714         (JSC::InternalFunction::finishCreation):
715         * runtime/JSCast.h:
716         * runtime/JSGlobalObject.cpp:
717         (JSC::JSGlobalObject::init):
718         (JSC::JSGlobalObject::visitChildren):
719         * runtime/JSGlobalObject.h:
720         (JSC::JSGlobalObject::nullSetterStrictFunction const):
721         * runtime/JSType.cpp:
722         (WTF::printInternal):
723         * runtime/JSType.h:
724         * runtime/NullSetterFunction.cpp:
725         (JSC::NullSetterFunctionInternal::callThrowError):
726         (JSC::NullSetterFunction::NullSetterFunction):
727         * runtime/NullSetterFunction.h:
728
729 2020-06-16  Mark Lam  <mark.lam@apple.com>
730
731         Make Options::useJIT() be the canonical source of truth on whether we should use the JIT.
732         https://bugs.webkit.org/show_bug.cgi?id=212556
733         <rdar://problem/63780436>
734
735         Reviewed by Saam Barati.
736
737         After r263055, Options::useJIT() always equals VM::canUseJIT() after canUseJIT()
738         has been computed.  This patch removes VM::canUseJIT(), and replaces all calls to
739         it with calls to Options::useJIT().
740
741         In the old code, VM::canUseJIT() would assert s_canUseJITIsSet to ensure that
742         its clients will not access s_canUseJIT before it is initialized.  We not have an
743         equivalent mechanism with Options.  This is how it works:
744
745         1. There are 2 new Options flags in the g_jscConfig:
746                 g_jscConfig.options.isFinalized
747                 g_jscConfig.options.allowUnfinalizedAccess
748
749            g_jscConfig.options.isFinalized means that all Options values are finalized
750            i.e. initialization is complete and ready to be frozen in the Config.
751
752            g_jscConfig.options.isFinalized is set by initializeThreading() by calling
753            Options::finalize() once options initialization is complete.
754
755            g_jscConfig.options.allowUnfinalizedAccess is an allowance for clients to
756            access Options values before they are finalized.  This is only needed in
757            options initialization code where Options values are read and written to.
758
759            g_jscConfig.options.allowUnfinalizedAccess is set and cleared using the
760            Options::AllowUnfinalizedAccessScope RAII object.  The few pieces of code that
761            do options initialization will instantiate this scope object.
762
763         2. All Options accessors (e.g. Option::useJIT()) will now assert that either
764            g_jscConfig.options.allowUnfinalizedAccess or g_jscConfig.options.isFinalized
765            is set.
766
767         3. Since r263055, Options::recomputeDependentOptions() ensures that if useJIT() is
768            false, all other JIT options (e.g. useBaselineJIT(), useDFTJIT(), useFTLJIT(),
769            etc.) are also false.  This patch also adds useBBQJIT() and useOMGJIT() to that
770            list.
771
772            With this, checks for useJIT() are now redundant if there's also another JIT
773            option check, e.g. useRegExpJIT() or useDFGJIT().  When redundant, this patch
774            elides the useJIT() check (which used to be a VM::canUseJIT() check).
775
776         Ideally, we should also introduce a separate abstraction for requested option
777         values before finalization than the finalized option values that will be adopted
778         by the system.  We'll do this as a separate exercise in a later patch.
779
780         * API/tests/ExecutionTimeLimitTest.cpp:
781         (testExecutionTimeLimit):
782         * API/tests/FunctionOverridesTest.cpp:
783         (testFunctionOverrides):
784         * API/tests/PingPongStackOverflowTest.cpp:
785         (testPingPongStackOverflow):
786         - Removed redundant calls to Options::initialize().
787
788         * API/tests/testapi.c:
789         (main):
790         - move the call to testExecutionTimeLimit() to after finalizeMultithreadedMultiVMExecutionTest()
791           returns.  This is because testExecutionTimeLimit() modifies JIT options at runtime
792           as part of its testing.  This can wreak havoc on the rest of the system that expects
793           the options to be frozen.  Ideally, we'll find a way for testExecutionTimeLimit() to
794           do its work without changing JIT options, but that is not easy to do.  For now,
795           we'll just run it at the end as a workaround.
796
797         * bytecode/CodeBlock.cpp:
798         (JSC::CodeBlock::setNumParameters):
799         * bytecode/CodeBlock.h:
800         (JSC::CodeBlock::numberOfArgumentValueProfiles):
801         (JSC::CodeBlock::valueProfileForArgument):
802         * dfg/DFGCapabilities.cpp:
803         (JSC::DFG::isSupported):
804         * heap/Heap.cpp:
805         (JSC::Heap::completeAllJITPlans):
806         (JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
807         (JSC::Heap::gatherScratchBufferRoots):
808         (JSC::Heap::removeDeadCompilerWorklistEntries):
809         (JSC::Heap::stopThePeriphery):
810         (JSC::Heap::suspendCompilerThreads):
811         (JSC::Heap::resumeCompilerThreads):
812         (JSC::Heap::addCoreConstraints):
813         * interpreter/AbstractPC.cpp:
814         (JSC::AbstractPC::AbstractPC):
815         * jit/JITThunks.cpp:
816         (JSC::JITThunks::ctiNativeCall):
817         (JSC::JITThunks::ctiNativeConstruct):
818         (JSC::JITThunks::ctiNativeTailCall):
819         (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
820         (JSC::JITThunks::ctiInternalFunctionCall):
821         (JSC::JITThunks::ctiInternalFunctionConstruct):
822         (JSC::JITThunks::hostFunctionStub):
823         * jsc.cpp:
824         (CommandLine::parseArguments):
825         (jscmain):
826         * llint/LLIntEntrypoint.cpp:
827         (JSC::LLInt::setFunctionEntrypoint):
828         (JSC::LLInt::setEvalEntrypoint):
829         (JSC::LLInt::setProgramEntrypoint):
830         (JSC::LLInt::setModuleProgramEntrypoint):
831         * llint/LLIntSlowPaths.cpp:
832         (JSC::LLInt::shouldJIT):
833         (JSC::LLInt::jitCompileAndSetHeuristics):
834         * runtime/InitializeThreading.cpp:
835         (JSC::initializeThreading):
836         * runtime/JSCConfig.h:
837         * runtime/JSGlobalObject.cpp:
838         (JSC::JSGlobalObject::init):
839         * runtime/JSGlobalObject.h:
840         (JSC::JSGlobalObject::numberToStringWatchpointSet):
841         * runtime/Options.cpp:
842         (JSC::jitEnabledByDefault):
843         (JSC::disableAllJITOptions):
844
845         (JSC::Options::initialize):
846         - Move the calls to dumpOptionsIfNeeded() and ensureOptionsAreCoherent() to the
847           end after all the options have been initialized because this where they belong.
848
849         (JSC::Options::finalize):
850         (JSC::Options::setOptions):
851         (JSC::Options::setOption):
852         (JSC::Options::dumpAllOptions):
853         (JSC::Options::ensureOptionsAreCoherent):
854         * runtime/Options.h:
855         (JSC::Options::AllowUnfinalizedAccessScope::AllowUnfinalizedAccessScope):
856         (JSC::Options::AllowUnfinalizedAccessScope::~AllowUnfinalizedAccessScope):
857         * runtime/OptionsList.h:
858         * runtime/RegExp.cpp:
859         (JSC::RegExp::compile):
860         (JSC::RegExp::compileMatchOnly):
861         * runtime/SymbolTable.h:
862         (JSC::SymbolTableEntry::isWatchable const):
863         * runtime/VM.cpp:
864         (JSC::VM::computeCanUseJIT):
865         (JSC::VM::VM):
866         (JSC::VM::getHostFunction):
867         (JSC::VM::getCTIInternalFunctionTrampolineFor):
868         * runtime/VM.h:
869         (JSC::VM::isInMiniMode):
870         (JSC::VM::canUseJIT): Deleted.
871         * wasm/WasmCapabilities.h:
872         (JSC::Wasm::isSupported):
873         * wasm/WasmOperations.cpp:
874         (JSC::Wasm::shouldJIT):
875         * wasm/WasmSlowPaths.cpp:
876         (JSC::LLInt::shouldJIT):
877
878 2020-06-16  Robin Morisset  <rmorisset@apple.com>
879
880         Optimize Air::TmpWidth analysis in IRC
881         https://bugs.webkit.org/show_bug.cgi?id=152478
882
883         Reviewed by Filip Pizlo.
884
885         AirTmpWidth currently uses a HashMap to map tmps to their width.
886         Since tmps have consecutive indices, we can instead use vectors (one for GP and one for FP tmps).
887         As a bonus, we can just compute the width of the tmps of the bank the register allocator is currently looking at.
888         This cuts the time spent in the register allocator in JetStream2 by about 100ms out of 3.4s
889         (or sometimes 80ms out of 2.4, the bimodality of the time spent is due to a huge function in tagcloud-SP which usually but not always reach the FTL, I'll check later if it can be fixed by tweaking the inliner).
890
891         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
892         (JSC::B3::Air::allocateRegistersByGraphColoring):
893         * b3/air/AirTmpWidth.cpp:
894         (JSC::B3::Air::TmpWidth::TmpWidth):
895         (JSC::B3::Air::TmpWidth::recompute):
896         * b3/air/AirTmpWidth.h:
897         (JSC::B3::Air::TmpWidth::width const):
898         (JSC::B3::Air::TmpWidth::requiredWidth):
899         (JSC::B3::Air::TmpWidth::defWidth const):
900         (JSC::B3::Air::TmpWidth::useWidth const):
901         (JSC::B3::Air::TmpWidth::Widths::Widths):
902         (JSC::B3::Air::TmpWidth::widths):
903         (JSC::B3::Air::TmpWidth::widths const):
904         (JSC::B3::Air::TmpWidth::addWidths):
905         (JSC::B3::Air::TmpWidth::widthsVector):
906
907 2020-06-16  Fujii Hironori  <Hironori.Fujii@sony.com>
908
909         [CMake][Visual Studio] CombinedDomains.json is generated twice in JavaScriptCore.vcxproj and InspectorBackendCommands.vcxproj
910         https://bugs.webkit.org/show_bug.cgi?id=213225
911
912         Reviewed by Don Olmstead.
913
914         Since r262203 (Bug 210014) added a new target
915         InspectorBackendCommands, CombinedDomains.json is generated twice
916         in JavaScriptCore.vcxproj and InspectorBackendCommands.vcxproj.
917         This caused unnecessary incremental builds.
918
919         The fundamental issue of this issue was fixed in CMake side.
920         <https://gitlab.kitware.com/cmake/cmake/issues/16767>
921         However, JavaScriptCore target needs to have a direct or indirect
922         dependency of InspectorBackendCommands target for CMake Visual
923         Studio generator to eliminate duplicated custom commands.
924
925         * CMakeLists.txt: Added add_dependencies(JavaScriptCore InspectorBackendCommands).
926
927 2020-06-16  Mark Lam  <mark.lam@apple.com>
928
929         Add SIGABRT handler for non OS(DARWIN) builds to the jsc shell with the -s option.
930         https://bugs.webkit.org/show_bug.cgi?id=213200
931
932         Reviewed by Michael Catanzaro.
933
934         This is needed because non OS(DARWIN) builds uses abort as their "CRASH"ing
935         mechanism.
936
937         * jsc.cpp:
938         (CommandLine::parseArguments):
939
940 2020-06-15  Michael Catanzaro  <mcatanzaro@gnome.org>
941
942         WTF signal machinery is guarded by #if USE(PTHREADS) && HAVE(MACHINE_CONTEXT) but does not use pthreads or machine context
943         https://bugs.webkit.org/show_bug.cgi?id=213223
944
945         Reviewed by Mark Lam.
946
947         Use #if OS(UNIX) here too. This should fix stress/ensure-crash.js when
948         HAVE(MACHINE_CONTEXT) is false.
949
950         * jsc.cpp:
951         (printUsageStatement):
952         (CommandLine::parseArguments):
953
954 2020-06-15  Pavel Feldman  <pavel.feldman@gmail.com>
955
956         Web Inspector: introduce request interception
957         https://bugs.webkit.org/show_bug.cgi?id=207446
958
959         Reviewed by Devin Rousso.
960
961         This change introduces network request interception to the Network 
962         protocol domain. It adds Network.interceptWithRequest notification that
963         can be continued, modified or fulfilled. NetworkStage enum can now have
964         'request' and 'response' values.
965
966         * inspector/protocol/Network.json:
967
968 2020-06-15  Tadeu Zagallo  <tzagallo@apple.com>
969
970         op_iterator_open getNext checkpoint needs to declare it uses m_iterator
971         https://bugs.webkit.org/show_bug.cgi?id=213106
972         <rdar://problem/63416838>
973
974          Reviewed by Keith Miller.
975
976         Currently, we have no way of specifying that a checkpoint uses an operand defined at an earlier
977         point in the same bytecode, which is the case for op_iterator_open: we assume that it will have
978         already allocated the iterator and stored it in m_iterator by the time we get to the getNext
979         checkpoint. In order to support that, we change tmpLivenessForCheckpoint to livenessForCheckpoint
980         and allow it to also declare the use of the operands defined within the bytecode.
981
982         * bytecode/BytecodeLivenessAnalysis.cpp:
983         (JSC::livenessForCheckpoint):
984         (JSC::tmpLivenessForCheckpoint): Deleted.
985         * bytecode/BytecodeLivenessAnalysis.h:
986         * bytecode/FullBytecodeLiveness.h:
987         * dfg/DFGForAllKills.h:
988         (JSC::DFG::forAllKilledOperands):
989         * dfg/DFGGraph.cpp:
990         (JSC::DFG::Graph::isLiveInBytecode):
991         * dfg/DFGGraph.h:
992
993 2020-06-15  Alexey Shvayka  <shvaikalesh@gmail.com>
994
995         Expand JSObject::defineOwnIndexedProperty() fast path for existing properties
996         https://bugs.webkit.org/show_bug.cgi?id=213133
997
998         Reviewed by Yusuke Suzuki.
999
1000         This patch expands fast path of JSObject::defineOwnIndexedProperty() to cover existing properties
1001         if given data descriptor has no falsy attributes, preventing the object from entering SparseMode.
1002         The optimization is possible due to this invariant: indexed properties of non-SparseMode objects
1003         have attributes of PropertyAttribute::None (except for typed arrays; added assert covers it).
1004
1005         PropertyDescriptor::attributesOverridingCurrent() with PropertyAttribute::None descriptor
1006         is used to support partial descriptors like {value: 1, writable: true}.
1007
1008         This change advances Object.defineProperty microbenchmark by 35%; array read/write benchmark
1009         following property redefinition is progressed by a factor of 16 due to avoiding SparseMode.
1010
1011         * runtime/JSObject.cpp:
1012         (JSC::JSObject::defineOwnIndexedProperty):
1013
1014 2020-06-15  Robin Morisset  <rmorisset@apple.com>
1015
1016         testB3::testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead() has a validation failure in debug mode
1017         https://bugs.webkit.org/show_bug.cgi?id=196103
1018         <rdar://problem/57808549>
1019
1020         Reviewed by Keith Miller.
1021
1022         The problem was trivial: patchpoints were referring to constants that were defined after them.
1023         Just exchanging the order of the definition was enough to make this test pass.
1024
1025         * b3/testb3_1.cpp:
1026         (shouldRun):
1027         * b3/testb3_7.cpp:
1028         (testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
1029
1030 2020-06-15  Mark Lam  <mark.lam@apple.com>
1031
1032         Do not install the VMTraps signal handler if Options::useJIT=false.
1033         https://bugs.webkit.org/show_bug.cgi?id=212543
1034         <rdar://problem/63772519>
1035
1036         Reviewed by Keith Miller.
1037
1038         VMTraps is only needed for JITted code.  Hence, if the JIT is disabled, we should
1039         set Options::usePollingTraps() to true to indicate that we won't be using VMTraps.
1040
1041         With this change, we no longer install any signal handling machinery if
1042         Options::useJIT() is false.
1043
1044         Because we may still disable the JIT even if useJIT() is true (due to failure to
1045         allocate JIT memory or a number of other factors), we will also add a check of
1046         VM::canUseJIT() in initializeThreading(), and disable useJIT() if needed.  Of
1047         course, this also means we need to call Options::recomputeDependentOptions() to
1048         make other options consistent with useJIT() being false.
1049
1050         * runtime/InitializeThreading.cpp:
1051         (JSC::initializeThreading):
1052         * runtime/Options.cpp:
1053         (JSC::disableAllJITOptions):
1054         (JSC::Options::recomputeDependentOptions):
1055         (JSC::recomputeDependentOptions): Deleted.
1056         * runtime/Options.h:
1057         * runtime/VMTraps.cpp:
1058         (JSC::VMTraps::initializeSignals):
1059         * tools/SigillCrashAnalyzer.cpp:
1060         (JSC::SigillCrashAnalyzer::instance):
1061
1062 2020-06-15  Keith Miller  <keith_miller@apple.com>
1063
1064         CheckIsConstant should not use BadCache exit kind
1065         https://bugs.webkit.org/show_bug.cgi?id=213141
1066
1067         Reviewed by Yusuke Suzuki.
1068
1069         The BadCache exit kind causes the OSR exit compilers to try to
1070         update ArrayProfiles.  This is just incorrect for CheckIsConstant
1071         since the node's origin may not even have an
1072         ArrayProfile... BadCache also strongly assumes the value it's
1073         profiling is a cell, which is clearly not always the case for
1074         CheckIsConstant.
1075
1076         CheckIsConstant now uses the BadConstantValue (BadValue conflicts
1077         with macros exported by X11 on GTK) exit kind for all use kinds,
1078         which is just a rename of BadCell.  All existing places where we
1079         can emit a CheckIsConstant already have a story for BadConstantValue.
1080
1081         * bytecode/CallLinkStatus.cpp:
1082         (JSC::CallLinkStatus::computeFromLLInt):
1083         (JSC::CallLinkStatus::computeExitSiteData):
1084         * bytecode/ExitKind.cpp:
1085         (JSC::exitKindToString):
1086         * bytecode/ExitKind.h:
1087         * dfg/DFGAbstractInterpreterInlines.h:
1088         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1089         * dfg/DFGByteCodeParser.cpp:
1090         (JSC::DFG::ByteCodeParser::handleInlining):
1091         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1092         (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
1093         (JSC::DFG::ByteCodeParser::parseBlock):
1094         (JSC::DFG::ByteCodeParser::handlePutByVal):
1095         (JSC::DFG::ByteCodeParser::handleCreateInternalFieldObject):
1096         * dfg/DFGClobberize.h:
1097         (JSC::DFG::clobberize):
1098         * dfg/DFGDoesGC.cpp:
1099         (JSC::DFG::doesGC):
1100         * dfg/DFGFixupPhase.cpp:
1101         (JSC::DFG::FixupPhase::fixupNode):
1102         * dfg/DFGNode.h:
1103         (JSC::DFG::Node::isPseudoTerminal):
1104         * dfg/DFGNodeType.h:
1105         * dfg/DFGPredictionPropagationPhase.cpp:
1106         * dfg/DFGSafeToExecute.h:
1107         (JSC::DFG::safeToExecute):
1108         * dfg/DFGSpeculativeJIT.cpp:
1109         (JSC::DFG::SpeculativeJIT::compileCheckIsConstant):
1110         * dfg/DFGSpeculativeJIT32_64.cpp:
1111         (JSC::DFG::SpeculativeJIT::compile):
1112         * dfg/DFGSpeculativeJIT64.cpp:
1113         (JSC::DFG::SpeculativeJIT::compile):
1114         * ftl/FTLCapabilities.cpp:
1115         (JSC::FTL::canCompile):
1116         * ftl/FTLLowerDFGToB3.cpp:
1117         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1118         (JSC::FTL::DFG::LowerDFGToB3::compileCheckIsConstant):
1119         (JSC::FTL::DFG::LowerDFGToB3::compileCheckBadValue):
1120         (JSC::FTL::DFG::LowerDFGToB3::compileCheckBadCell): Deleted.
1121
1122 2020-06-15  Yusuke Suzuki  <ysuzuki@apple.com>
1123
1124         Webkit Feature BigInt on webkit.org
1125         https://bugs.webkit.org/show_bug.cgi?id=197546
1126
1127         Reviewed by Sam Weinig.
1128
1129         Add BigInt entry to JSC features.json.
1130
1131         * features.json:
1132
1133 2020-06-15  Keith Miller  <keith_miller@apple.com>
1134
1135         JIT thunks should work on arm64_32
1136         https://bugs.webkit.org/show_bug.cgi?id=213103
1137
1138         Reviewed by Saam Barati.
1139
1140         This patch fixes various issues when running JSC on arm64_32 with
1141         useJIT=1 and useBaselineJIT=0. In particular this patch makes the
1142         following changes:
1143
1144         1) ScalePtr is now just part of the Scale enum and is set based on
1145         the size of the address space.
1146
1147         2) MacroAssembler::*Ptr functions call 32/64 bit variants based on
1148         Address space size rather than cpu architecture. Vetting of callsites
1149         using Ptr as 64 will happen in future patches since it's hard to
1150         comprehensively vet.
1151
1152         3) Add some missing variants of functions for when pointers are 32-bit.
1153
1154         4) Add a load/storeReg function that stores a full register regardless
1155         of pointer size for storing/loading callee saves.
1156
1157         5) numberOfDFGCompiles should report a big number for
1158         useBaselineJIT=0 as some tests fail by default if useBaselineJIT=0
1159         but useJIT=1.
1160
1161         6) Assert BaseIndex has a scale of PtrSize or TimesOne (for pre-scaled
1162         values) when passed to a load/storePtr function.
1163
1164         * assembler/AbstractMacroAssembler.h:
1165         (JSC::AbstractMacroAssembler::timesPtr): Deleted.
1166         * assembler/MacroAssembler.h:
1167         (JSC::MacroAssembler::rotateRightPtr):
1168         (JSC::MacroAssembler::loadPtr):
1169         (JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch):
1170         (JSC::MacroAssembler::branchPtr):
1171         (JSC::MacroAssembler::storePtr):
1172         (JSC::MacroAssembler::shouldBlindDouble):
1173         (JSC::MacroAssembler::moveDouble):
1174         (JSC::MacroAssembler::store64):
1175         * assembler/MacroAssemblerARM64.h:
1176         (JSC::MacroAssemblerARM64::add32):
1177         (JSC::MacroAssemblerARM64::signExtend32ToPtr):
1178         (JSC::MacroAssemblerARM64::loadPtr):
1179         (JSC::MacroAssemblerARM64::call):
1180         (JSC::MacroAssemblerARM64::farJump):
1181         * assembler/MacroAssemblerARMv7.h:
1182         (JSC::MacroAssemblerARMv7::rotateRight32):
1183         * assembler/MacroAssemblerMIPS.h:
1184         (JSC::MacroAssemblerMIPS::rotateRight32):
1185         * assembler/MacroAssemblerX86.h:
1186         * assembler/MacroAssemblerX86_64.h:
1187         * b3/B3LowerMacros.cpp:
1188         * b3/testb3_6.cpp:
1189         (testInterpreter):
1190         * dfg/DFGSpeculativeJIT.cpp:
1191         (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
1192         * jit/AssemblyHelpers.cpp:
1193         (JSC::AssemblyHelpers::emitLoadStructure):
1194         (JSC::AssemblyHelpers::emitAllocateVariableSized):
1195         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1196         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1197         * jit/AssemblyHelpers.h:
1198         (JSC::AssemblyHelpers::storeReg):
1199         (JSC::AssemblyHelpers::loadReg):
1200         (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
1201         (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
1202         (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
1203         (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
1204         (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
1205         * jit/JITOpcodes32_64.cpp:
1206         (JSC::JIT::emit_op_enumerator_structure_pname):
1207         (JSC::JIT::emit_op_enumerator_generic_pname):
1208         * jit/ThunkGenerators.cpp:
1209         (JSC::nativeForGenerator):
1210         * runtime/TestRunnerUtils.cpp:
1211         (JSC::numberOfDFGCompiles):
1212
1213 2020-06-15  Caitlin Potter  <caitp@igalia.com>
1214
1215         [JSC] add machinery to disable JIT tiers when experimental features are enabled
1216         https://bugs.webkit.org/show_bug.cgi?id=213193
1217
1218         Reviewed by Mark Lam.
1219
1220         A new macro FOR_EACH_JSC_EXPERIMENTAL_OPTION() supplies flags indicating the supported
1221         JIT tiers (or, in the future, other options) of a particular feature,
1222         in an easy to understand format. These flags are then used to
1223         recompute dependent feature flags.
1224
1225         This should simplify the incremental development of language features.
1226
1227         * dfg/DFGCapabilities.cpp:
1228         (JSC::DFG::capabilityLevel):
1229         * runtime/Options.cpp:
1230         (JSC::recomputeDependentOptions):
1231         * runtime/OptionsList.h:
1232
1233 2020-06-15  Keith Miller  <keith_miller@apple.com>
1234
1235         Signal handlers should have a two phase installation.
1236         https://bugs.webkit.org/show_bug.cgi?id=213160
1237
1238         Reviewed by Mark Lam.
1239
1240         * jsc.cpp:
1241         (CommandLine::parseArguments):
1242         (jscmain):
1243         * runtime/InitializeThreading.cpp:
1244         (JSC::initializeThreading):
1245         * runtime/VMTraps.cpp:
1246         * tools/SigillCrashAnalyzer.cpp:
1247         (JSC::installCrashHandler):
1248         * wasm/WasmFaultSignalHandler.cpp:
1249         (JSC::Wasm::enableFastMemory):
1250         (JSC::Wasm::prepareFastMemory):
1251         * wasm/WasmFaultSignalHandler.h:
1252
1253 2020-06-15  Yusuke Suzuki  <ysuzuki@apple.com>
1254
1255         Unreviewed, fix LLInt
1256         https://bugs.webkit.org/show_bug.cgi?id=157972
1257
1258         loadi only takes address.
1259
1260         * llint/LowLevelInterpreter64.asm:
1261
1262 2020-06-15  Alexey Shvayka  <shvaikalesh@gmail.com>
1263
1264         super should not depend on __proto__
1265         https://bugs.webkit.org/show_bug.cgi?id=157972
1266
1267         Reviewed by Saam Barati.
1268
1269         Before this change, both super() call [1] and super.property [2] relied on
1270         Object.prototype.__proto__ to acquire super base, which was observable and
1271         incorrect if __proto__ gets removed.
1272
1273         This patch introduces get_prototype_of bytecode, ensuring returned values
1274         are profiled so the op can be wired to existing DFG and FTL implementations.
1275         In order to avoid performance regression w/o DFG (__proto__ is optimized via
1276         IntrinsicGetterAccessCase), fast paths for LLInt and baseline JIT are added
1277         (64-bit only), utilizing OverridesGetPrototypeOutOfLine type info flag.
1278
1279         This change aligns JSC with V8 and SpiderMonkey, progressing microbenchmarks/
1280         super-get-by-{id,val}-with-this-monomorphic.js by 7-10%. SixSpeed is neutral.
1281
1282         Also, extracts JSValue::getPrototype() method to avoid code duplication and
1283         utilizes it in objectConstructorGetPrototypeOf(), advancing provided
1284         microbenchmark by 40%.
1285
1286         [1]: https://tc39.es/ecma262/#sec-getsuperconstructor (step 5)
1287         [2]: https://tc39.es/ecma262/#sec-getsuperbase (step 5)
1288
1289         * builtins/BuiltinNames.h:
1290         * bytecode/BytecodeIntrinsicRegistry.h:
1291         * bytecode/BytecodeList.rb:
1292         * bytecode/BytecodeUseDef.cpp:
1293         (JSC::computeUsesForBytecodeIndexImpl):
1294         (JSC::computeDefsForBytecodeIndexImpl):
1295         * bytecode/CodeBlock.cpp:
1296         (JSC::CodeBlock::finishCreation):
1297         * bytecode/Opcode.h:
1298         * bytecompiler/BytecodeGenerator.cpp:
1299         (JSC::BytecodeGenerator::emitGetPrototypeOf):
1300         * bytecompiler/BytecodeGenerator.h:
1301         * bytecompiler/NodesCodegen.cpp:
1302         (JSC::emitSuperBaseForCallee):
1303         (JSC::emitGetSuperFunctionForConstruct):
1304         (JSC::BytecodeIntrinsicNode::emit_intrinsic_getPrototypeOf):
1305         * dfg/DFGAbstractInterpreterInlines.h:
1306         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1307         * dfg/DFGByteCodeParser.cpp:
1308         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1309         (JSC::DFG::ByteCodeParser::parseBlock):
1310         * dfg/DFGCapabilities.cpp:
1311         (JSC::DFG::capabilityLevel):
1312         * dfg/DFGOperations.cpp:
1313         * jit/IntrinsicEmitter.cpp:
1314         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1315         * jit/JIT.cpp:
1316         (JSC::JIT::privateCompileMainPass):
1317         (JSC::JIT::privateCompileSlowCases):
1318         * jit/JIT.h:
1319         * jit/JITOpcodes.cpp:
1320         (JSC::JIT::emit_op_get_prototype_of):
1321         * llint/LowLevelInterpreter.asm:
1322         * llint/LowLevelInterpreter64.asm:
1323         * runtime/CommonSlowPaths.cpp:
1324         (JSC::SLOW_PATH_DECL):
1325         * runtime/CommonSlowPaths.h:
1326         * runtime/JSCJSValue.h:
1327         * runtime/JSCJSValueInlines.h:
1328         (JSC::JSValue::getPrototype const):
1329         * runtime/JSGlobalObjectFunctions.cpp:
1330         (JSC::globalFuncProtoGetter):
1331         * runtime/JSObject.cpp:
1332         (JSC::JSObject::calculatedClassName):
1333         * runtime/JSObject.h:
1334         (JSC::JSObject::getPrototype):
1335         * runtime/JSObjectInlines.h:
1336         (JSC::JSObject::canPerformFastPutInlineExcludingProto):
1337         (JSC::JSObject::getPropertySlot):
1338         (JSC::JSObject::getNonIndexPropertySlot):
1339         * runtime/JSProxy.h:
1340         * runtime/JSTypeInfo.h:
1341         (JSC::TypeInfo::overridesGetPrototype const):
1342         * runtime/ObjectConstructor.cpp:
1343         (JSC::objectConstructorGetPrototypeOf):
1344         * runtime/ProxyObject.h:
1345         * runtime/Structure.h:
1346         * runtime/Structure.cpp:
1347         (JSC::Structure::validateFlags):
1348
1349 2020-06-13  Devin Rousso  <drousso@apple.com>
1350
1351         Make `errors` an own property of `AggregateError` instead of a prototype accessor
1352         https://bugs.webkit.org/show_bug.cgi?id=212677
1353
1354         Reviewed by Yusuke Suzuki.
1355
1356         * runtime/AggregateError.h:
1357         (JSC::AggregateError::destroy): Deleted.
1358         (JSC::AggregateError::subspaceFor): Deleted.
1359         (JSC::AggregateError::errors): Deleted.
1360         * runtime/AggregateError.cpp:
1361         (JSC::AggregateError::AggregateError):
1362         (JSC::AggregateError::finishCreation): Added.
1363         (JSC::AggregateError::visitChildren): Deleted.
1364
1365         * runtime/AggregateErrorPrototype.h:
1366         * runtime/AggregateErrorPrototype.cpp:
1367         (JSC::AggregateErrorPrototype::finishCreation):
1368         (JSC::aggregateErrorPrototypeAccessorErrors): Deleted.
1369         * runtime/JSGlobalObject.cpp:
1370         (JSC::JSGlobalObject::initializeAggregateErrorConstructor):
1371
1372         * runtime/VM.h:
1373         * runtime/VM.cpp:
1374         (JSC::VM::VM):
1375         * heap/Heap.cpp:
1376         (JSC::Heap::finalizeUnconditionalFinalizers):
1377         Remove `aggregateErrorSpace` since `AggregateError` doesn't add any new member variables.
1378         Ensure that it can share an `IsoSubspace` with `ErrorInstance`.
1379
1380         * runtime/CommonIdentifiers.h:
1381         Add `errors`.
1382
1383 2020-06-12  Robin Morisset  <rmorisset@apple.com>
1384
1385         The ||= operator (and similar ones) should produce valid bytecode even if the right side is a static error
1386         https://bugs.webkit.org/show_bug.cgi?id=213154
1387
1388         Reviewed by Devin Rousso.
1389
1390         There were two minor issues here that interacted:
1391         - emitThrowReferenceError did not take an optional `dst` argument like everything else, and instead always returned a new temporary.
1392           As a result, the various functions that sometimes did "return emitThrowReferenceError(..);" could return a different RegisterID than the one
1393           provided to them through `dst`, breaking the invariant stated at the top of the file.
1394         - ShortCircuitReadModifyResolveNode::emitBytecode used the result of such a function, unnecessarily, and (correctly) relied on the invariant being upheld.
1395         The combination of these led to the bytecode trying to do a move of a temporary that was only defined in one of the predecessors of the basic block it was on,
1396         which was caught by validateBytecode.
1397
1398         I fixed both issues, and verified that either fix is enough to stop the bug.
1399         I fixed the first because other code may depend on that invariant in more subtle ways.
1400         I fixed the second because it was just unnecessary complexity and made the code misleading.
1401
1402         I also reworded the comment at the top of NodesCodegen.cpp based on Keith's explanation and Mark's advice to make it less cryptic.
1403
1404         * bytecompiler/NodesCodegen.cpp:
1405         (JSC::ThrowableExpressionData::emitThrowReferenceError):
1406         (JSC::PostfixNode::emitBytecode):
1407         (JSC::DeleteBracketNode::emitBytecode):
1408         (JSC::DeleteDotNode::emitBytecode):
1409         (JSC::PrefixNode::emitBytecode):
1410         (JSC::ShortCircuitReadModifyResolveNode::emitBytecode):
1411         (JSC::AssignErrorNode::emitBytecode):
1412         * parser/Nodes.h:
1413
1414 2020-06-12  Yusuke Suzuki  <ysuzuki@apple.com>
1415
1416         [JSC] el(Greek) characters' upper-case conversion is locale-sensitive
1417         https://bugs.webkit.org/show_bug.cgi?id=213155
1418         <rdar://problem/55018467>
1419
1420         Reviewed by Darin Adler.
1421
1422         CLDR defines 4 locales which has language-sensitive case conversions. "az", "el", "lt", and "tr", where,
1423
1424             az = Azerbaijani
1425             el = Greek
1426             lt = Lithuanian
1427             tr = Turkish
1428
1429         We can ensure it easily like this.
1430
1431             1. Download CLDR data
1432             2. `ls common/transforms/*Upper.xml`
1433
1434                 common/transforms/az-Upper.xml
1435                 common/transforms/el-Upper.xml
1436                 common/transforms/lt-Upper.xml
1437                 common/transforms/tr-Upper.xml
1438
1439         And ECMA-402 String.prototype.{toLocaleLowerCase,toLocaleUpperCase} requires these locales are listed as `availableLocales`.
1440
1441             > 7. Let availableLocales be a List with language tags that includes the languages for which the Unicode Character
1442             >    Database contains language sensitive case mappings. Implementations may add additional language tags if they
1443             >    support case mapping for additional locales.
1444
1445             https://tc39.es/ecma402/#sup-string.prototype.tolocalelowercase
1446
1447         This patch adds "el" to our maintained availableLocales list. Previously we only had "az", "lt", and "tr".
1448
1449         * runtime/StringPrototype.cpp:
1450         (JSC::toLocaleCase):
1451         (JSC::stringProtoFuncToLocaleUpperCase):
1452
1453 2020-06-12  Keith Miller  <keith_miller@apple.com>
1454
1455         Tests expecting a crash should use a signal handler in the JSC CLI process
1456         https://bugs.webkit.org/show_bug.cgi?id=212479
1457
1458         Reviewed by Yusuke Suzuki.
1459
1460         Have the -s option use WTF::Signals and make sure it adds breakpoint catching
1461         as well.
1462
1463         * jsc.cpp:
1464         (printUsageStatement):
1465         (CommandLine::parseArguments):
1466         * tools/SigillCrashAnalyzer.cpp:
1467         (JSC::installCrashHandler):
1468
1469 2020-06-12  Alexey Shvayka  <shvaikalesh@gmail.com>
1470
1471         AsyncGenerator should await "return" completions
1472         https://bugs.webkit.org/show_bug.cgi?id=212774
1473
1474         Reviewed by Ross Kirsling.
1475
1476         This patch fixes 2 spec discrepancies, observable with async generators if the
1477         value of "return" completion is a Promise, aligning JSC with V8 and SpiderMonkey.
1478
1479         * builtins/AsyncGeneratorPrototype.js:
1480         (onFulfilled):
1481         This change implements step 8 of AsyncGeneratorYield [1], that is executed after
1482         step 15 of AsyncGeneratorResumeNext [2] (implemented as @doAsyncGeneratorBodyCall).
1483         We are safe to rely on [[AsyncGeneratorState]] being "suspendedYield" (set in
1484         step 6 of AsyncGeneratorYield [1]) instead of adding extra field to AsyncGenerator:
1485         AsyncGeneratorResumeNext [2] does not overwrite "suspendedYield" state.
1486         This change fixes most of test262 cases.
1487
1488         [1]: https://tc39.es/ecma262/#sec-asyncgeneratoryield
1489         [2]: https://tc39.es/ecma262/#sec-asyncgeneratorresumenext
1490
1491         * bytecompiler/BytecodeGenerator.cpp:
1492         (JSC::BytecodeGenerator::emitDelegateYield):
1493         This change implements step 7.c.iii.1 of yield* runtime semantics [3], that is
1494         observable only if [[Value]] has userland "then" getter. Awaited result is discarded.
1495         This change fixes async-generator/yield-star-return-then-getter-ticks.js test262 case.
1496
1497         [3]: https://tc39.es/ecma262/#sec-generator-function-definitions-runtime-semantics-evaluation
1498
1499 2020-06-12  Ross Kirsling  <ross.kirsling@sony.com>
1500
1501         Unreviewed, address Darin's feedback on r262890.
1502
1503         * runtime/IntlObject.cpp:
1504         (JSC::addScriptlessLocaleIfNeeded):
1505         Use != instead of < for clarity.
1506
1507 2020-06-12  Adrian Perez de Castro  <aperez@igalia.com>
1508
1509         Build is broken with EVENT_LOOP_TYPE=GLib
1510         https://bugs.webkit.org/show_bug.cgi?id=212987
1511
1512         Reviewed by Konstantin Tokarev.
1513
1514         * PlatformJSCOnly.cmake: Add sources needed to support the remote inspector to
1515         JavaScriptCore_SOURCES.
1516
1517 2020-06-11  Saam Barati  <sbarati@apple.com>
1518
1519         Linear Scan uses the wrong Interval for spills for tmps with roles of early def or late use
1520         https://bugs.webkit.org/show_bug.cgi?id=213055
1521         <rdar://problem/59874018>
1522
1523         Reviewed by Yusuke Suzuki.
1524
1525         There was a bug in linear scan when computing the live range interval for
1526         spill tmps that had early defs or late uses.  When linear scan spills a
1527         tmp, it creates a new tmp that it loads to and stores from, and replaces the old tmp
1528         with the new tmp, and emits stores/loads around pertinent instructions. The live
1529         interval for such tmps is small by nature, it's contained in the interval for the
1530         instruction itself. However, we'd build this interval purely based off the
1531         original tmp's arg timing. So, for example, let's consider a program like this:
1532         
1533         RandoInsn: LateUse:Tmp1, Use:Tmp2, [early = N, late = N+1]
1534         Let's say that Tmp1's last use is RandoInsn, and it had a def before
1535         RandoInsn, therefore, its live range will be something like:
1536         [J where J < N, N+1]
1537         
1538         and now imagine we spilled Tmp1 for some reason, and rewrote the
1539         program to be:
1540         Move Addr(spill for Tmp1), TmpSpill
1541         RandoInsn: LateUse:TmpSpill, Use:Tmp2, [early = N, late = N+1]
1542         
1543         We used to incorrectly mark the live range for TmpSpill to just be [N+1, N+2).
1544         However, the bug here is that we neglected that TmpSpill actually had an earlier
1545         def at [N, N+1). So, the live range for TmpSpill was wrong. This could incorrectly
1546         lead us to allocate Tmp2 and TmpSpill to the same register, since their live
1547         ranges may not intersect if Tmp2 dies at RandoInsn.
1548         
1549         We also had the symmetric bug for EarlyDefs: we wouldn't account for the
1550         store-spill that'd happen after something like RandoInsn.
1551         
1552         The fix is to account for the loads/stores of spill tmps when assigning
1553         them a live range.
1554         
1555         This patch contains a standalone test in testair. It also fixes crashes we had when
1556         running B3O1 tests using typed arrays on arm64e since we had patchpoints that utilized
1557         LateUse for signing and auth.
1558
1559         * b3/B3Procedure.h:
1560         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
1561         * b3/air/testair.cpp:
1562
1563 2020-06-11  Saam Barati  <sbarati@apple.com>
1564
1565         Replace uses of black/white list with block/allow list
1566         https://bugs.webkit.org/show_bug.cgi?id=213084
1567
1568         Reviewed by Keith Miller.
1569
1570         We should be using racially neutral names in our code. From Chromium style guide:
1571         
1572         "Terms such as 'blacklist' and 'whitelist' reinforce the notion that
1573         black==bad and white==good."
1574
1575         * JavaScriptCore.xcodeproj/project.pbxproj:
1576         * Sources.txt:
1577         * b3/air/AirLowerAfterRegAlloc.cpp:
1578         (JSC::B3::Air::lowerAfterRegAlloc):
1579         * dfg/DFGDriver.cpp:
1580         (JSC::DFG::ensureGlobalDFGAllowlist):
1581         (JSC::DFG::compileImpl):
1582         (JSC::DFG::ensureGlobalDFGWhitelist): Deleted.
1583         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1584         (JSC::DFG::ensureGlobalFTLAllowlist):
1585         (JSC::DFG::TierUpCheckInjectionPhase::run):
1586         (JSC::DFG::ensureGlobalFTLWhitelist): Deleted.
1587         * heap/MachineStackMarker.cpp:
1588         * inspector/scripts/codegen/objc_generator.py:
1589         (ObjCGenerator.should_generate_types_for_domain):
1590         (ObjCGenerator.should_generate_commands_for_domain):
1591         (ObjCGenerator.should_generate_events_for_domain):
1592         * llint/LLIntSlowPaths.cpp:
1593         (JSC::LLInt::ensureGlobalJITAllowlist):
1594         (JSC::LLInt::shouldJIT):
1595         (JSC::LLInt::ensureGlobalJITWhitelist): Deleted.
1596         * runtime/OptionsList.h:
1597         * tools/FunctionAllowlist.cpp: Copied from Source/JavaScriptCore/tools/FunctionWhitelist.cpp.
1598         (JSC::FunctionAllowlist::FunctionAllowlist):
1599         (JSC::FunctionAllowlist::contains const):
1600         (JSC::FunctionWhitelist::FunctionWhitelist): Deleted.
1601         (JSC::FunctionWhitelist::contains const): Deleted.
1602         * tools/FunctionAllowlist.h: Copied from Source/JavaScriptCore/tools/FunctionWhitelist.h.
1603         * tools/FunctionWhitelist.cpp: Removed.
1604         * tools/FunctionWhitelist.h: Removed.
1605
1606 2020-06-11  Yusuke Suzuki  <ysuzuki@apple.com>
1607
1608         [JSC] Return DisposableCallSiteIndex when destroying GCAwareJITStubRoutineWithExceptionHandler
1609         https://bugs.webkit.org/show_bug.cgi?id=213069
1610         <rdar://problem/64205186>
1611
1612         Reviewed by Saam Barati.
1613
1614         Inside GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount, we are returning DisposableCallSiteIndex to freelist.
1615         However, GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount can be called even if the code of GCAwareJITStubRoutineWithExceptionHandler is
1616         on the stack. Let's consider the following scenario.
1617
1618             1. Execute GCAwareJITStubRoutineWithExceptionHandler's code. Set CallSiteIndex to the stack.
1619             2. Execute more code. (1)'s GCAwareJITStubRoutineWithExceptionHandler's code is on the stack.
1620             3. (1)'s GCAwareJITStubRoutineWithExceptionHandler's refcount becomes zero.
1621             4. CallSiteIndex of GCAwareJITStubRoutineWithExceptionHandler is returned.
1622             5. Execute StackVisitor to construct frames. But we cannot find CodeOrigin corresponding to CallSiteIndex stored in (1) since it is already returned.
1623
1624         DisposableCallSiteIndex should be returned after ensuring that GCAwareJITStubRoutineWithExceptionHandler's code is not on the stack. Detecting this is the functionality
1625         what GCAwareJITStubRoutineWithExceptionHandler can offer. It is destroyed after ensuring that GCAwareJITStubRoutineWithExceptionHandler's code is not on the stack.
1626
1627         This patch delays DisposableCallSiteIndex returning until we destroy owner GCAwareJITStubRoutineWithExceptionHandler. But it is possible that CodeBlock* corresponding to
1628         GCAwareJITStubRoutineWithExceptionHandler is already destroyed. To avoid this condition, we extract CodeOrigins vector as Ref<DFG::CodeOriginPool> and keep it alive from
1629         GCAwareJITStubRoutineWithExceptionHandler too. And since CodeOrigin addition / removal happens only from the main thread after finishing the compilation, and
1630         GCAwareJITStubRoutineWithExceptionHandler's destructor is called from the Heap's finalizer, which must be executed from the main thread, we can just modify it without a lock.
1631
1632         * CMakeLists.txt:
1633         * JavaScriptCore.xcodeproj/project.pbxproj:
1634         * Sources.txt:
1635         * bytecode/CodeBlock.cpp:
1636         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
1637         (JSC::CodeBlock::codeOrigins):
1638         * bytecode/CodeBlock.h:
1639         (JSC::CodeBlock::codeOrigin):
1640         * dfg/DFGCodeOriginPool.cpp: Added.
1641         (JSC::DFG::CodeOriginPool::addCodeOrigin):
1642         (JSC::DFG::CodeOriginPool::addUniqueCallSiteIndex):
1643         (JSC::DFG::CodeOriginPool::lastCallSite const):
1644         (JSC::DFG::CodeOriginPool::addDisposableCallSiteIndex):
1645         (JSC::DFG::CodeOriginPool::removeDisposableCallSiteIndex):
1646         (JSC::DFG::CodeOriginPool::shrinkToFit):
1647         * dfg/DFGCodeOriginPool.h: Added.
1648         (JSC::DFG::CodeOriginPool::create):
1649         (JSC::DFG::CodeOriginPool::get):
1650         (JSC::DFG::CodeOriginPool::size const):
1651         * dfg/DFGCommonData.cpp:
1652         (JSC::DFG::CommonData::shrinkToFit):
1653         (JSC::DFG::CommonData::addCodeOrigin): Deleted.
1654         (JSC::DFG::CommonData::addUniqueCallSiteIndex): Deleted.
1655         (JSC::DFG::CommonData::lastCallSite const): Deleted.
1656         (JSC::DFG::CommonData::addDisposableCallSiteIndex): Deleted.
1657         (JSC::DFG::CommonData::removeDisposableCallSiteIndex): Deleted.
1658         * dfg/DFGCommonData.h:
1659         (JSC::DFG::CommonData::CommonData):
1660         * dfg/DFGJITCompiler.cpp:
1661         (JSC::DFG::JITCompiler::exceptionCheck):
1662         * dfg/DFGJITCompiler.h:
1663         (JSC::DFG::JITCompiler::addCallSite):
1664         * ftl/FTLLowerDFGToB3.cpp:
1665         (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
1666         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1667         (JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
1668         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
1669         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
1670         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
1671         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
1672         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
1673         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
1674         (JSC::FTL::DFG::LowerDFGToB3::compileInById):
1675         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1676         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
1677         (JSC::FTL::DFG::LowerDFGToB3::getById):
1678         (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
1679         (JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
1680         (JSC::FTL::DFG::LowerDFGToB3::callPreflight):
1681         * ftl/FTLSlowPathCall.cpp:
1682         (JSC::FTL::callSiteIndexForCodeOrigin):
1683         * jit/GCAwareJITStubRoutine.cpp:
1684         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
1685         (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
1686         (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
1687         (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
1688         * jit/GCAwareJITStubRoutine.h:
1689
1690 2020-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
1691
1692         RegExp.prototype getters should throw on cross-realm access
1693         https://bugs.webkit.org/show_bug.cgi?id=213075
1694
1695         Reviewed by Saam Barati.
1696
1697         This patch makes RegExp.prototype getters throw TypeError when called on
1698         RegExp.prototype object from another realm, aligning JSC with V8 and SpiderMonkey.
1699
1700         The spec [1] allows same-realm access to avoid breaking the web, while makes
1701         RegExp.prototype an ordinary object (rather than RegExp instance) where possible.
1702
1703         [1]: https://tc39.es/ecma262/#sec-get-regexp.prototype.global (step 3.a)
1704
1705         * runtime/RegExpPrototype.cpp:
1706         (JSC::regExpProtoGetterGlobal):
1707         (JSC::regExpProtoGetterIgnoreCase):
1708         (JSC::regExpProtoGetterMultiline):
1709         (JSC::regExpProtoGetterDotAll):
1710         (JSC::regExpProtoGetterSticky):
1711         (JSC::regExpProtoGetterUnicode):
1712         (JSC::regExpProtoGetterSource):
1713
1714 2020-06-11  Paulo Matos  <pmatos@igalia.com>
1715
1716         Add missing include to JSONObject.cpp - non-unified build
1717         https://bugs.webkit.org/show_bug.cgi?id=213073
1718
1719         Reviewed by Adrian Perez de Castro.
1720
1721         * runtime/JSONObject.cpp:
1722
1723 2020-06-10  Ross Kirsling  <ross.kirsling@sony.com>
1724
1725         REGRESSION(r260697): [Intl] "missing script" locales like zh-TW are no longer mapped
1726         https://bugs.webkit.org/show_bug.cgi?id=213007
1727
1728         Reviewed by Darin Adler.
1729
1730         addMissingScriptLocales was removed from IntlObject when changing our locale resolution to depend more directly
1731         on ICU, but apparently even latest ICU won't perform this legacy "region implies script" mapping for us.
1732
1733         ICU 65+ does have uloc_openAvailableByType which will do the trick, so perhaps we should use this in the future,
1734         but it still doesn't seem to help us with Collator, which has its own separate set of "available locales".
1735
1736         The exact set of locales which should be mapped is currently under discussion here:
1737         https://github.com/tc39/ecma402/issues/159
1738         But the crux seems to be that we should ensure we have an xx-ZZ alias for all available xx-Yyyy-ZZ locales.
1739
1740         * runtime/IntlObject.cpp:
1741         (JSC::addScriptlessLocaleIfNeeded):
1742         (JSC::intlAvailableLocales):
1743         (JSC::intlCollatorAvailableLocales):
1744
1745 2020-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
1746
1747         [JSC] JSCallbackObject::deleteProperty should redirect to Parent::deletePropertyByIndex if propertyName is index
1748         https://bugs.webkit.org/show_bug.cgi?id=213041
1749         <rdar://problem/64204300>
1750
1751         Reviewed by Darin Adler.
1752
1753         We have an infinite recursion here.
1754
1755         -> JSCallbackObject::deletePropertyByIndex
1756             -> JSCell::deleteProperty
1757                 -> JSCallbackObject::deleteProperty
1758                     -> JSObject::deleteProperty
1759                         -> JSCallbackObject::deletePropertyByIndex
1760
1761         When propertyName in JSCallbackObject::deleteProperty is an index, we should go to JSObject::deletePropertyByIndex instead of JSObject::deleteProperty.
1762
1763         * API/JSCallbackObjectFunctions.h:
1764         (JSC::JSCallbackObject<Parent>::deleteProperty):
1765
1766 2020-06-09  Mark Lam  <mark.lam@apple.com>
1767
1768         Stringifier::appendStringifiedValue() should not assume it is always safe to recurse.
1769         https://bugs.webkit.org/show_bug.cgi?id=213006
1770         <rdar://problem/64154840>
1771
1772         Reviewed by Keith Miller.
1773
1774         In r262727, I suggested that Alexey Shvayka add an assertion in
1775         Stringifier::appendStringifiedValue() to assert that it is safe to recurse because
1776         we don't expect it to recurse into itself.  Turns out this is a bad idea because
1777         a client may be doing the recursing before calling Stringifier::appendStringifiedValue().
1778         As a result, Stringifier::appendStringifiedValue() ends up being executed with
1779         the stack pointer already in the reserved zone.  This is legal, and is what the
1780         reserved zone is intended for as long as we don't recurse from here.  However,
1781         this also means that asserting vm.isSafeToRecurseSoft() here will surely fail
1782         because we are already in the reserved zone area.  The fix is simply to remove
1783         this faulty assertion.
1784
1785         * runtime/JSONObject.cpp:
1786         (JSC::Stringifier::appendStringifiedValue):
1787
1788 2020-06-09  Mark Lam  <mark.lam@apple.com>
1789
1790         Disambiguate the OverridesGetPropertyNames structure flag
1791         https://bugs.webkit.org/show_bug.cgi?id=212909
1792         <rdar://problem/63823557>
1793
1794         Reviewed by Saam Barati.
1795
1796         Previously, the OverridesGetPropertyNames structure flag could mean 2 different
1797         things:
1798         1. the getPropertyNames() method is overridden, or
1799         2. any of the forms of getPropertyName() is overridden:
1800            getPropertyName, getOwnPropertyNames, getOwnNonIndexPropertyNames
1801
1802         Some parts of the code expects one definition while other parts expect the other.
1803         This patch disambiguates between the 2 by introducing OverridesAnyFormOfGetPropertyNames
1804         for definition (2).  OverridesGetPropertyNames now only means definition (1).
1805
1806         Note: we could have implemented overridesGetPropertyNames() by doing a comparison
1807         of the getPropertyNames pointer in the MethodTable.  This is a little slower than
1808         checking a TypeInfo flag, but probably doesn't matter a lot in the code paths
1809         where overridesGetPropertyNames() is called.  However, we have bits in TypeInfo
1810         left.  So, we'll might as well use it.
1811
1812         This ambiguity resulted in JSObject::getPropertyNames() recursing infinitely
1813         when it didn't think it could recurse.  This is demonstrated in
1814         JSTests/stress/unexpected-stack-overflow-below-JSObject-getPropertyNames.js as
1815         follows:
1816
1817         1. The test case invokes JSObject::getPropertyNames on a JSArray.
1818
1819         2. In the while loop at the bottom of JSObject::getPropertynames(), we check
1820            `if (prototype->structure(vm)->typeInfo().overridesGetPropertyNames()) {`.
1821
1822         3. The test overrides proto as follows:
1823            `arg0.__proto__ = arr1` where both arg0 and arr1 are JArrays.
1824
1825         4. In the old code, JSArray sets OverridesGetPropertyNames but does not override
1826            getPropertyNames().  It actually meant to set OverridesAnyFormOfGetPropertyNames
1827            (after we disambiguated it) because JSArray overrides getOwnNonIndexPropertyNames().
1828
1829         5. When we get to the check at (2), we ask if the prototype overridesGetPropertyNames().
1830            Since JSArray sets OverridesGetPropertyNames, the answer is yes / true.
1831
1832            JSObject::getPropertynames() then proceeds to invoke
1833            `prototype->methodTable(vm)->getPropertyNames(prototype, globalObject, propertyNames, mode);`
1834
1835            But because JSArray does not actually overrides getPropertyNames(), we're
1836            actually invoking JSObject::getPropertyNames() here.  Viola!  Infinite loop.
1837
1838         With this patch, JSArray is disambiguated to set OverridesAnyFormOfGetPropertyNames
1839         instead of OverridesGetPropertyNames, and this infinite loop no longer exists.
1840
1841         This patch also made the following changes:
1842
1843         1. Templatized TypeInfo::isSetOnFlags1() and TypeInfo::isSetOnFlags2() so that
1844            we can used static_asserts instead of a debug ASSERT to verify the integrity of
1845            the flag we're checking against.
1846
1847         2. Added a Structure::validateFlags() called from the Structure constructor.
1848            validateFlags() will verify the following:
1849            a. OverridesGetOwnPropertySlot must be set in the flags if getOwnPropertySlot
1850               is overridden in the MethodTable.
1851            b. InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero must be set in
1852               the flags if getOwnPropertySlotByIndex is overridden in the MethodTable.
1853            c. HasPutPropertySecurityCheck must be set in the flags if doPutPropertySecurityCheck
1854               is overridden in the MethodTable.
1855            d. OverridesGetPropertyNames must be set in the flags if getPropertyNames
1856               is overridden in the MethodTable.
1857            e. OverridesAnyFormOfGetPropertyNames must be set in the flags if any of
1858               getPropertyNames, getOwnPropertyNames, or getOwnNonIndexPropertyNames are
1859               overridden in the MethodTable.
1860
1861            An alternate solution would be to automatically set these flags if we detect
1862            their corresponding methods are overridden.  However, this alternate solution
1863            requires this laundry list to be checked every time a structure is constructed.
1864            The current implementation of having the required flags already pre-determined
1865            as a constant is more efficient in terms of performance and code space.
1866
1867            Also, it only takes one instantiation of the structure to verify that the flags
1868            are valid.  Since we only write JSCell / JSObject classes when we need them
1869            and we always write tests to exercise new code (especially such classes), we're
1870            guaranteed the flags validation will be exercised.
1871
1872         3. Made JSObject::getOwnPropertySlot() and JSObject::doPutPropertySecurityCheck()
1873            not inlined when ASSERT_ENABLED.  This is needed in order for Structure::validateFlags()
1874            to do its checks using function pointer comparisons.  Otherwise, the inline
1875            functions can result in multiple instantiations of these functions.  For
1876            example, WebCore can get its own copy of JSObject::getOwnPropertySlot() and
1877            the comparisons will think the function is overridden even when it's not.
1878
1879         4. Structure::validateFlags() found the following problems which are now fixed:
1880
1881            GetterSetter was not using its StructureFlags.  As a result, it was missing the
1882            OverridesGetOwnPropertySlot flag.
1883
1884            JSDataView did not define its StructureFlags.  It was missing the
1885            OverridesGetOwnPropertySlot and OverridesAnyFormOfGetPropertyNames flags.
1886
1887         5. Changed a TypeInfo constructor to not have a default argument for the flags value.
1888            Also grepped for all uses of this constructor to make sure that it is passed
1889            the StructureFlags field.  This exercise found the following issue:
1890
1891            JSAPIValueWrapper was not using its StructureFlags when creating its structure.
1892            Previously, it was just ignoring the StructureIsImmortal flag in StructureFlags.
1893
1894         6. Hardened the assertions for hasReadOnlyOrGetterSetterPropertiesExcludingProto()
1895            and hasGetterSetterProperties() in the Structure constructor.
1896
1897            Previously, if the flag is set, it verifies that the ClassInfo has the
1898            appropriate data expected by the flag.  However, it does not assert the reverse
1899            i.e. that if the ClassInfo data exists, then the flag must also be set.
1900            The new assertions now checks both.
1901
1902            Moved the overridesGetCallData() assertion into Structure::validateFlags()
1903            because it concerns the OverridesGetCallData flag.  This assertion has also
1904            ben hardened.
1905
1906         * API/JSAPIValueWrapper.h:
1907         * API/JSCallbackObject.h:
1908         * debugger/DebuggerScope.h:
1909         * inspector/JSInjectedScriptHostPrototype.h:
1910         * inspector/JSJavaScriptCallFramePrototype.h:
1911         * runtime/ClonedArguments.h:
1912         * runtime/ErrorInstance.h:
1913         * runtime/GenericArguments.h:
1914         * runtime/GetterSetter.h:
1915         * runtime/JSArray.h:
1916         * runtime/JSDataView.h:
1917         * runtime/JSFunction.h:
1918         * runtime/JSGenericTypedArrayView.h:
1919         * runtime/JSGlobalObject.h:
1920         * runtime/JSLexicalEnvironment.h:
1921         * runtime/JSModuleEnvironment.h:
1922         * runtime/JSModuleNamespaceObject.h:
1923         * runtime/JSObject.cpp:
1924         (JSC::JSObject::doPutPropertySecurityCheck):
1925         (JSC::JSObject::getOwnPropertySlot):
1926         * runtime/JSObject.h:
1927         (JSC::JSObject::getOwnPropertySlotImpl):
1928         (JSC::JSObject::getOwnPropertySlot):
1929         * runtime/JSProxy.h:
1930         * runtime/JSString.h:
1931         * runtime/JSSymbolTableObject.h:
1932         * runtime/JSTypeInfo.h:
1933         (JSC::TypeInfo::TypeInfo):
1934         (JSC::TypeInfo::masqueradesAsUndefined const):
1935         (JSC::TypeInfo::implementsHasInstance const):
1936         (JSC::TypeInfo::implementsDefaultHasInstance const):
1937         (JSC::TypeInfo::overridesGetCallData const):
1938         (JSC::TypeInfo::overridesToThis const):
1939         (JSC::TypeInfo::structureIsImmortal const):
1940         (JSC::TypeInfo::overridesGetPropertyNames const):
1941         (JSC::TypeInfo::overridesAnyFormOfGetPropertyNames const):
1942         (JSC::TypeInfo::prohibitsPropertyCaching const):
1943         (JSC::TypeInfo::getOwnPropertySlotIsImpure const):
1944         (JSC::TypeInfo::getOwnPropertySlotIsImpureForPropertyAbsence const):
1945         (JSC::TypeInfo::hasPutPropertySecurityCheck const):
1946         (JSC::TypeInfo::newImpurePropertyFiresWatchpoints const):
1947         (JSC::TypeInfo::isImmutablePrototypeExoticObject const):
1948         (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero const):
1949         (JSC::TypeInfo::isSetOnFlags1 const):
1950         (JSC::TypeInfo::isSetOnFlags2 const):
1951         * runtime/ObjectConstructor.cpp:
1952         (JSC::objectConstructorAssign):
1953         * runtime/ProxyObject.h:
1954         * runtime/RegExpObject.h:
1955         * runtime/StringObject.h:
1956         * runtime/Structure.cpp:
1957         (JSC::Structure::validateFlags):
1958         (JSC::Structure::Structure):
1959         * runtime/Structure.h:
1960         * runtime/StructureInlines.h:
1961         (JSC::Structure::canCacheOwnKeys const):
1962         * tools/JSDollarVM.cpp:
1963
1964 2020-06-09  Jonathan Bedard  <jbedard@apple.com>
1965
1966         JavaScriptCore: Support tvOS and watchOS builds with the public SDK
1967         https://bugs.webkit.org/show_bug.cgi?id=212788
1968         <rdar://problem/64000087>
1969
1970         Reviewed by Tim Horton.
1971
1972         * Configurations/Base.xcconfig: Link to tvOS and watchOS framework stubs.
1973         * Configurations/JavaScriptCore.xcconfig: Use iOS flags for all embedded platforms.
1974
1975 2020-06-09  Yusuke Suzuki  <ysuzuki@apple.com>
1976
1977         [JSC] Shrink __DATA,(__data,__bss,__common) more
1978         https://bugs.webkit.org/show_bug.cgi?id=212863
1979
1980         Reviewed by Sam Weinig.
1981
1982         1. Use `unsigned` instead of `size_t` in GC size-class array. We know that this number never exceeds largeCutoff,
1983            which must be much maller than UINT32_MAX.
1984         2. Add missing const to various variables to put them DATA,__const instead of DATA,__data etc.
1985
1986         * heap/MarkedSpace.cpp:
1987         (JSC::MarkedSpace::initializeSizeClassForStepSize):
1988         * heap/MarkedSpace.h:
1989         * heap/VisitRaceKey.cpp:
1990         * heap/VisitRaceKey.h:
1991         * inspector/agents/InspectorDebuggerAgent.cpp:
1992         * inspector/agents/InspectorDebuggerAgent.h:
1993         * runtime/PropertyDescriptor.cpp:
1994         * runtime/PropertyDescriptor.h:
1995
1996 2020-06-08  Keith Miller  <keith_miller@apple.com>
1997
1998         Removed unneeded POINTER_WIDTH macro from b3
1999         https://bugs.webkit.org/show_bug.cgi?id=212927
2000
2001         Reviewed by Yusuke Suzuki.
2002
2003         C++20 has real constexpr functions so we don't need the
2004         POINTER_WIDTH macro anymore.
2005
2006         * b3/B3Width.h:
2007         (JSC::B3::pointerWidth):
2008         * b3/air/opcode_generator.rb:
2009
2010 2020-06-08  Alexey Shvayka  <shvaikalesh@gmail.com>
2011
2012         JSON.stringify should throw stack overflow error
2013         https://bugs.webkit.org/show_bug.cgi?id=143511
2014
2015         Reviewed by Ross Kirsling and Mark Lam.
2016
2017         This change adds m_holderStack.size() check, reusing the limit of JSON.parse,
2018         and throws StackOverflowError if exceeded, aligning JSC with V8 and SpiderMonkey.
2019         Even with all the cyclic structure checks in place, excess is possible due to
2020         very deeply nested object, user-provided "toJSON" method or functional replacer.
2021
2022         While Stringifier::appendStringifiedValue() and Holder::appendNextProperty()
2023         mutually call each other, recursion is avoided by !holderStackWasEmpty check and
2024         do/while loop at the end of appendStringifiedValue(), as well as cyclic structure
2025         check as per spec [1].
2026
2027         [1]: https://tc39.es/ecma262/#sec-serializejsonobject (step 1)
2028
2029         * runtime/JSONObject.cpp:
2030         (JSC::Stringifier::appendStringifiedValue):
2031         (JSC::Walker::walk):
2032
2033 2020-06-08  Jonathan Bedard  <jbedard@apple.com>
2034
2035         JavaScriptCore: Fix PLATFORM(TVOS) macro
2036         https://bugs.webkit.org/show_bug.cgi?id=212900
2037         <rdar://problem/64118879>
2038
2039         Unreviewed build fix.
2040
2041         * tools/JSDollarVM.cpp:
2042         (JSC::functionIsMemoryLimited): PLATFORM(TVOS) should be PLATFORM(APPLETV).
2043
2044 2020-06-07  Philippe Normand  <pnormand@igalia.com>
2045
2046         Remove ENABLE_VIDEO_TRACK ifdef guards
2047         https://bugs.webkit.org/show_bug.cgi?id=212568
2048
2049         Reviewed by Youenn Fablet.
2050
2051         * Configurations/FeatureDefines.xcconfig: Remove ENABLE_VIDEO_TRACK, which is now enabled by
2052         default under the ENABLE_VIDEO guard.
2053
2054 2020-06-07  Yusuke Suzuki  <ysuzuki@apple.com>
2055
2056         [JSC] Checksum for generated files should be emitted at the end of the files
2057         https://bugs.webkit.org/show_bug.cgi?id=212875
2058
2059         Reviewed by Mark Lam.
2060
2061         If the offlineasm file generation is interrupted in the middle of the generation, it already emitted checksum.
2062         So next file generation can accept this broken file as a result of offlineasm and skip file generation.
2063         We should emit checksum at the end of files. For now, this patch takes a quick way: just iterating lines, getting
2064         a last line and use it for checksum comparison.
2065
2066         * generator/GeneratedFile.rb:
2067         * offlineasm/asm.rb:
2068
2069 2020-06-06  Mark Lam  <mark.lam@apple.com>
2070
2071         Make CodeBlockHash robust against unreasonably long source code.
2072         https://bugs.webkit.org/show_bug.cgi?id=212847
2073         <rdar://problem/64024279>
2074
2075         Reviewed by Saam Barati.
2076
2077         This patch adds a heuristic to avoid trying to compute the CodeBlockHash on
2078         unreasonably long source code strings.  This is done by first applying a length
2079         check and, if needed, computing the hash with an alternate method.
2080
2081         This is OK to do because:
2082         1. CodeBlockHash is not a critical hash.
2083         2. In practice, reasonable source code are not that long.
2084         3. And if they are that long, then we are still diversifying the hash on their
2085            length. But if they do collide, it's OK.
2086
2087         The only invariant here is that we should always produce the same hash for the
2088         same source string.  Since the algorithm is deterministic, this invariant is not
2089         violated.
2090
2091         * bytecode/CodeBlockHash.cpp:
2092         (JSC::CodeBlockHash::CodeBlockHash):
2093
2094 2020-06-06  Devin Rousso  <drousso@apple.com>
2095
2096         Web Inspector: unify the naming scheme for agents used by instrumentation
2097         https://bugs.webkit.org/show_bug.cgi?id=212859
2098
2099         Reviewed by Timothy Hatcher.
2100
2101         Inspector agents fall into one of three categories:
2102          - "persistent" when Web Inspector is connected
2103          - "enabled" when that agent is `enable`d, such as if the corresponding tab is visible
2104          - "tracking" when that agent is part of a timeline recording.
2105
2106         The only exception to this is the Console agent, as that exists regardless of whether Web
2107         Inspector is connected as it needs to preserve messages logged before Web Inspector connects.
2108
2109         Also remove the "Inspector" prefix from getter/setter methods as it adds confusion if that
2110         agent also has subclasses (e.g. `InspectorRuntimeAgent` and `PageRuntimeAgent`).
2111
2112         * inspector/JSGlobalObjectConsoleClient.h:
2113         * inspector/JSGlobalObjectInspectorController.cpp:
2114         * inspector/agents/InspectorConsoleAgent.h:
2115
2116 2020-06-05  Michael Saboff  <msaboff@apple.com>
2117
2118         Make FAST_JIT_PERMISSIONS check in LinkBuffer::copyCompactAndLinkCode a runtime check
2119         https://bugs.webkit.org/show_bug.cgi?id=212825
2120
2121         Reviewed by Saam Barati.
2122
2123         Added useFastJITPermissions() for runtime checks of FAST_JIT_PERMISSIONS
2124         including the cases where it is conditional on OS settings. This is now
2125         used in a few places to declutter the code.
2126
2127         When using the fast JIT permissions path, the JIT memory is the direct output
2128         of the linking. Modified BranchCompactionLinkBuffer to hold a pointer to that
2129         output "buffer" or a temporarily allocated buffer depending on if fast JIT
2130         permissions are enabled.
2131
2132         Broke out the "verify hash" conditionally compiled code with a file local
2133         ENABLE_VERIFY_JIT_HASH macro for readability.
2134
2135         * assembler/LinkBuffer.cpp:
2136         (JSC::BranchCompactionLinkBuffer::BranchCompactionLinkBuffer):
2137         (JSC::BranchCompactionLinkBuffer::~BranchCompactionLinkBuffer):
2138         Changed this to use a provided buffer or a malloc'ed buffer. When using
2139         a malloc'ed buffer, we put it in a thread local cache.
2140
2141         (JSC::LinkBuffer::copyCompactAndLinkCode):
2142         * jit/ExecutableAllocator.h:
2143         (JSC::useFastJITPermissions):
2144         (JSC::performJITMemcpy):
2145
2146 2020-06-05  Yusuke Suzuki  <ysuzuki@apple.com>
2147
2148         [JSC] Put dfgOpNames in __DATA,__const section instead of __DATA,__data
2149         https://bugs.webkit.org/show_bug.cgi?id=212840
2150
2151         Reviewed by Saam Barati.
2152
2153         dfgOpNames array itself is not const annotated, and the compiler makes it __DATA,__data instead of __DATA,__const.
2154         We should annotate it with const to ensure that this is compiled into __DATA,__const. We also remove unused CallFrame::describeFrame
2155         since it allocates some bss memory, while we have more sophisticated mechanism (VMInspector) for this functionality and this function
2156         is no longer used.
2157
2158         * dfg/DFGDoesGCCheck.cpp:
2159         (JSC::DFG::DoesGCCheck::verifyCanGC):
2160         * dfg/DFGGraph.cpp:
2161         * dfg/DFGGraph.h:
2162         * interpreter/CallFrame.cpp:
2163         (JSC::CallFrame::describeFrame): Deleted.
2164         * interpreter/CallFrame.h:
2165
2166 2020-06-05  Tadeu Zagallo  <tzagallo@apple.com>
2167
2168         REGRESSION(r262523): Fix testb3
2169         https://bugs.webkit.org/show_bug.cgi?id=212791
2170
2171         Reviewed by Mark Lam.
2172
2173         * b3/testb3_1.cpp:
2174         (run):
2175         (main):
2176
2177 2020-06-05  Paulo Matos  <pmatos@igalia.com>
2178
2179         Add missing ECMAMode header to fix NonUnified Build
2180         https://bugs.webkit.org/show_bug.cgi?id=212838
2181
2182         Reviewed by Darin Adler.
2183
2184         * bytecode/PutByValFlags.h:
2185
2186 2020-06-05  Saam Barati  <sbarati@apple.com>
2187
2188         Audit safe to execute
2189         https://bugs.webkit.org/show_bug.cgi?id=207075
2190         <rdar://problem/59085094>
2191
2192         Reviewed by Yusuke Suzuki.
2193
2194         This audit found one interesting case for DOMJIT nodes. We emit safety checks
2195         for CallDOM/CallDOMGetter inside fixup phase and the bytecode parser. When
2196         determining if these nodes are safe to execute, we need to also ensure that
2197         these checks hold.
2198         
2199         I've also added a helper to JSDollarVM to ensure that this patch doesn't break
2200         LICM of DOMJIT.
2201         
2202         This patch also moves some nodes we will never hoist to return false.
2203
2204         * dfg/DFGByteCodeParser.cpp:
2205         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2206         * dfg/DFGFixupPhase.cpp:
2207         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
2208         * dfg/DFGNode.h:
2209         (JSC::DFG::Node::classInfo):
2210         (JSC::DFG::Node::requiredDOMJITClassInfo):
2211         * dfg/DFGSafeToExecute.h:
2212         (JSC::DFG::safeToExecute):
2213         * tools/JSDollarVM.cpp:
2214         (JSC::functionCreateDOMJITGetterNoEffectsObject):
2215         (JSC::JSDollarVM::finishCreation):
2216
2217 2020-06-05  Devin Rousso  <drousso@apple.com>
2218
2219         Logical Assignment: perform NamedEvaluation of anonymous functions
2220         https://bugs.webkit.org/show_bug.cgi?id=212679
2221
2222         Reviewed by Ross Kirsling.
2223
2224         * parser/ASTBuilder.h:
2225         (JSC::ASTBuilder::makeAssignNode):
2226
2227 2020-06-05  Yusuke Suzuki  <ysuzuki@apple.com>
2228
2229         DOM constructor should only accept Ref<> / ExceptionOr<Ref<>> for creation to ensure toJSNewlyCreated is always returning object
2230         https://bugs.webkit.org/show_bug.cgi?id=212767
2231
2232         Reviewed by Darin Adler.
2233
2234         * runtime/JSObject.h:
2235         (JSC::asObject):
2236
2237 2020-06-05  Andy Estes  <aestes@apple.com>
2238
2239         [Apple Pay] Remove conditionals for ENABLE_APPLE_PAY_SESSION_V(3|4)
2240         https://bugs.webkit.org/show_bug.cgi?id=212541
2241         <rdar://problem/63781452>
2242
2243         Reviewed by Darin Adler.
2244
2245         APPLE_PAY_SESSION_V(3|4) is now enabled whenever APPLE_PAY itself is enabled.
2246
2247         * Configurations/FeatureDefines.xcconfig:
2248
2249 2020-06-05  Caitlin Potter  <caitp@igalia.com>
2250
2251         [JSC] Add support for private class fields
2252         https://bugs.webkit.org/show_bug.cgi?id=206431
2253
2254         Reviewed by Saam Barati.
2255
2256         Expanding upon the earlier public class fields patch, we implement the remaining (and
2257         significant parts) of the instance fields (https://tc39.es/proposal-class-fields/).
2258
2259         There are a variety of key changes here:
2260
2261             - Parser now understands the concept of private names (Token PRIVATENAME).
2262             - 1 new opcode (op_get_private_name), one changed opcode (op_put_by_val_direct).
2263             - A method for creating Symbol objects with a null PrivateSymbolImpl is exposed as a
2264               LinkTimeConstant (@createPrivateSymbol).
2265             - Null Private Symbols are stored by name (not a valid identifier) in a JSScope, and
2266               are loaded from the outer scope whenever they are used by the modified opcodes.
2267
2268         The changes to op_put_by_val_direct include a new bytecode operand (PutByValFlags) which are
2269         used to distinguish between overwriting or defining a new private field. Specifically, when it
2270         comes to private field accesses, it's necessary to throw an exception when accessing a field
2271         which does not exist, or when attempting to define a private field which has already been
2272         defined.
2273
2274         During the evaluation of a class expression, before the class element list is evaluated (in case
2275         any computed property names expressions refer to a new private field), a new PrivateSymbol is
2276         created for each individual private field name, and stored in the class lexical scope.
2277
2278         Private field names are loaded from scope before their use. This prevents multiple evaluations
2279         of the same class source from accessing each other's private fields, because the values of the
2280         symbols loaded from the class scope would be distinct. This is required by the proposal text,
2281         and is the key reason why we use ByVal lookups rather than ById lookups.
2282
2283         To illustrate, typical private field access will look like:
2284
2285         <Field Reads>
2286         resolve_scope      <scope=>, <currentScope>, "#x", GlobalProperty, 0
2287         get_from_scope     <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
2288         get_private_name   <value=>, <receiver --- probably 'this'>, <symbol>
2289
2290         <Field Writes>
2291         resolve_scope      <scope=>, <currentScope>, "#x", GlobalProperty, 0
2292         get_from_scope     <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
2293         put_by_val_direct  <receiver, probably 'this'>, <symbol>, <value>, <PutByValPrivateName>
2294
2295         <Field Definition>
2296         resolve_scope      <scope=>, <currentScope>, "#x", GlobalProperty, 0
2297         get_from_scope     <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
2298         put_by_val_direct  <receiver, probably 'this'>, <symbol>, <value>, <PutByValPrivateName|PutByValThrowIfExists>
2299
2300         The feature is currently hidden behind the feature flag JSC::Options::usePrivateClassFields.
2301
2302         * CMakeLists.txt:
2303         * JavaScriptCore.xcodeproj/project.pbxproj:
2304         * Sources.txt:
2305         * builtins/BuiltinNames.h:
2306         * bytecode/BytecodeList.rb:
2307         * bytecode/BytecodeUseDef.cpp:
2308         (JSC::computeUsesForBytecodeIndexImpl):
2309         (JSC::computeDefsForBytecodeIndexImpl):
2310         * bytecode/CodeBlock.cpp:
2311         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2312         * bytecode/Fits.h:
2313         * bytecode/LinkTimeConstant.h:
2314         * bytecode/PutByValFlags.cpp: Copied from Source/JavaScriptCore/bytecode/PutKind.h.
2315         (WTF::printInternal):
2316         * bytecode/PutByValFlags.h: Added.
2317         (JSC::PutByValFlags::create):
2318         (JSC::PutByValFlags::createDirect):
2319         (JSC::PutByValFlags::createDefinePrivateField):
2320         (JSC::PutByValFlags::createPutPrivateField):
2321         (JSC::PutByValFlags::isDirect const):
2322         (JSC::PutByValFlags::ecmaMode const):
2323         (JSC::PutByValFlags::privateFieldAccessKind const):
2324         (JSC::PutByValFlags::isPrivateFieldAccess const):
2325         (JSC::PutByValFlags::isPrivateFieldPut const):
2326         (JSC::PutByValFlags::isPrivateFieldAdd const):
2327         (JSC::PutByValFlags::PutByValFlags):
2328         * bytecode/PutKind.h:
2329         * bytecode/UnlinkedFunctionExecutable.cpp:
2330         (JSC::generateUnlinkedFunctionCodeBlock):
2331         * bytecompiler/BytecodeGenerator.cpp:
2332         (JSC::BytecodeGenerator::instantiateLexicalVariables):
2333         (JSC::BytecodeGenerator::emitDirectGetByVal):
2334         (JSC::BytecodeGenerator::emitDirectPutByVal):
2335         (JSC::BytecodeGenerator::emitDefinePrivateField):
2336         (JSC::BytecodeGenerator::emitPrivateFieldPut):
2337         * bytecompiler/BytecodeGenerator.h:
2338         * bytecompiler/NodesCodegen.cpp:
2339         (JSC::PropertyListNode::emitDeclarePrivateFieldNames):
2340         (JSC::PropertyListNode::emitBytecode):
2341         (JSC::PropertyListNode::emitPutConstantProperty):
2342         (JSC::DotAccessorNode::emitBytecode):
2343         (JSC::BaseDotNode::emitGetPropertyValue):
2344         (JSC::BaseDotNode::emitPutProperty):
2345         (JSC::FunctionCallDotNode::emitBytecode):
2346         (JSC::PostfixNode::emitDot):
2347         (JSC::PrefixNode::emitDot):
2348         (JSC::AssignDotNode::emitBytecode):
2349         (JSC::ReadModifyDotNode::emitBytecode):
2350         (JSC::DefineFieldNode::emitBytecode):
2351         (JSC::ClassExprNode::emitBytecode):
2352         * dfg/DFGByteCodeParser.cpp:
2353         (JSC::DFG::ecmaMode):
2354         (JSC::DFG::ecmaMode<OpPutByValDirect>):
2355         (JSC::DFG::ByteCodeParser::handlePutByVal):
2356         * dfg/DFGCapabilities.cpp:
2357         (JSC::DFG::capabilityLevel):
2358         * dfg/DFGSpeculativeJIT.cpp:
2359         (JSC::DFG::SpeculativeJIT::cachedPutById):
2360         * ftl/FTLLowerDFGToB3.cpp:
2361         (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
2362         * generator/DSL.rb:
2363         * jit/ICStats.h:
2364         * jit/JIT.cpp:
2365         (JSC::JIT::privateCompileMainPass):
2366         * jit/JIT.h:
2367         * jit/JITInlineCacheGenerator.cpp:
2368         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2369         (JSC::JITPutByIdGenerator::slowPathFunction):
2370         * jit/JITInlineCacheGenerator.h:
2371         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2372         * jit/JITInlines.h:
2373         (JSC::JIT::ecmaMode):
2374         (JSC::JIT::ecmaMode<OpPutById>):
2375         (JSC::JIT::ecmaMode<OpPutByValDirect>):
2376         (JSC::JIT::privateFieldAccessKind):
2377         (JSC::JIT::privateFieldAccessKind<OpPutByValDirect>):
2378         * jit/JITOperations.cpp:
2379         (JSC::putPrivateField):
2380         (JSC::definePrivateField):
2381         * jit/JITOperations.h:
2382         * jit/JITPropertyAccess.cpp:
2383         (JSC::JIT::emitPutByValWithCachedId):
2384         (JSC::JIT::emitSlow_op_put_by_val):
2385         (JSC::JIT::emit_op_put_by_id):
2386         * jit/JITPropertyAccess32_64.cpp:
2387         (JSC::JIT::emitSlow_op_put_by_val):
2388         (JSC::JIT::emit_op_put_by_id):
2389         * jit/Repatch.cpp:
2390         (JSC::appropriateGenericPutByIdFunction):
2391         (JSC::appropriateOptimizingPutByIdFunction):
2392         (JSC::tryCachePutByID):
2393         * llint/LLIntOffsetsExtractor.cpp:
2394         * llint/LLIntSlowPaths.cpp:
2395         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2396         * llint/LLIntSlowPaths.h:
2397         * llint/LowLevelInterpreter32_64.asm:
2398         * llint/LowLevelInterpreter64.asm:
2399         * parser/ASTBuilder.h:
2400         (JSC::ASTBuilder::createDotAccess):
2401         (JSC::ASTBuilder::isPrivateLocation):
2402         (JSC::ASTBuilder::makeFunctionCallNode):
2403         (JSC::ASTBuilder::makeAssignNode):
2404         * parser/Lexer.cpp:
2405         (JSC::Lexer<LChar>::parseIdentifier):
2406         (JSC::Lexer<UChar>::parseIdentifier):
2407         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2408         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
2409         * parser/NodeConstructors.h:
2410         (JSC::BaseDotNode::BaseDotNode):
2411         (JSC::DotAccessorNode::DotAccessorNode):
2412         (JSC::FunctionCallDotNode::FunctionCallDotNode):
2413         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
2414         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
2415         (JSC::HasOwnPropertyFunctionCallDotNode::HasOwnPropertyFunctionCallDotNode):
2416         (JSC::AssignDotNode::AssignDotNode):
2417         (JSC::ReadModifyDotNode::ReadModifyDotNode):
2418         * parser/Nodes.cpp:
2419         (JSC::PropertyListNode::shouldCreateLexicalScopeForClass):
2420         * parser/Nodes.h:
2421         (JSC::ExpressionNode::isPrivateLocation const):
2422         (JSC::BaseDotNode::base const):
2423         (JSC::BaseDotNode::identifier const):
2424         (JSC::BaseDotNode::type const):
2425         (JSC::BaseDotNode::isPrivateField const):
2426         * parser/Parser.cpp:
2427         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2428         (JSC::Parser<LexerType>::parseDestructuringPattern):
2429         (JSC::Parser<LexerType>::parseClass):
2430         (JSC::Parser<LexerType>::parseInstanceFieldInitializerSourceElements):
2431         (JSC::Parser<LexerType>::usePrivateName):
2432         (JSC::Parser<LexerType>::parseMemberExpression):
2433         (JSC::Parser<LexerType>::parseUnaryExpression):
2434         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2435         * parser/Parser.h:
2436         (JSC::Scope::isPrivateNameScope const):
2437         (JSC::Scope::setIsPrivateNameScope):
2438         (JSC::Scope::hasPrivateName):
2439         (JSC::Scope::copyUndeclaredPrivateNamesTo):
2440         (JSC::Scope::hasUsedButUndeclaredPrivateNames const):
2441         (JSC::Scope::usePrivateName):
2442         (JSC::Scope::declarePrivateName):
2443         (JSC::Parser::findPrivateNameScope):
2444         (JSC::Parser::privateNameScope):
2445         (JSC::Parser::copyUndeclaredPrivateNamesToOuterScope):
2446         (JSC::Parser::matchAndUpdate):
2447         (JSC::Parser<LexerType>::parse):
2448         (JSC::parse):
2449         * parser/ParserTokens.h:
2450         * parser/SyntaxChecker.h:
2451         (JSC::SyntaxChecker::createDotAccess):
2452         (JSC::SyntaxChecker::operatorStackPop):
2453         * parser/VariableEnvironment.cpp:
2454         (JSC::VariableEnvironment::operator=):
2455         (JSC::VariableEnvironment::swap):
2456         (JSC::CompactVariableEnvironment::CompactVariableEnvironment):
2457         * parser/VariableEnvironment.h:
2458         (JSC::VariableEnvironmentEntry::isPrivateName const):
2459         (JSC::VariableEnvironmentEntry::setIsPrivateName):
2460         (JSC::PrivateNameEntry::PrivateNameEntry):
2461         (JSC::PrivateNameEntry::isUsed const):
2462         (JSC::PrivateNameEntry::isDeclared const):
2463         (JSC::PrivateNameEntry::setIsUsed):
2464         (JSC::PrivateNameEntry::setIsDeclared):
2465         (JSC::PrivateNameEntry::bits const):
2466         (JSC::PrivateNameEntry::operator== const):
2467         (JSC::VariableEnvironment::VariableEnvironment):
2468         (JSC::VariableEnvironment::size const):
2469         (JSC::VariableEnvironment::mapSize const):
2470         (JSC::VariableEnvironment::declarePrivateName):
2471         (JSC::VariableEnvironment::usePrivateName):
2472         (JSC::VariableEnvironment::privateNames const):
2473         (JSC::VariableEnvironment::privateNamesSize const):
2474         (JSC::VariableEnvironment::hasPrivateName):
2475         (JSC::VariableEnvironment::copyPrivateNamesTo const):
2476         (JSC::VariableEnvironment::copyUndeclaredPrivateNamesTo const):
2477         (JSC::VariableEnvironment::RareData::RareData):
2478         (JSC::VariableEnvironment::getOrAddPrivateName):
2479         * runtime/CachedTypes.cpp:
2480         (JSC::CachedOptional::decodeAsPtr const):
2481         (JSC::CachedVariableEnvironmentRareData::encode):
2482         (JSC::CachedVariableEnvironmentRareData::decode const):
2483         (JSC::CachedVariableEnvironment::encode):
2484         (JSC::CachedVariableEnvironment::decode const):
2485         (JSC::CachedSymbolTableRareData::encode):
2486         (JSC::CachedSymbolTableRareData::decode const):
2487         (JSC::CachedSymbolTable::encode):
2488         (JSC::CachedSymbolTable::decode const):
2489         * runtime/CodeCache.cpp:
2490         (JSC::generateUnlinkedCodeBlockImpl):
2491         * runtime/CommonIdentifiers.cpp:
2492         (JSC::CommonIdentifiers::CommonIdentifiers):
2493         * runtime/CommonIdentifiers.h:
2494         * runtime/CommonSlowPaths.cpp:
2495         (JSC::SLOW_PATH_DECL):
2496         * runtime/CommonSlowPaths.h:
2497         * runtime/ExceptionHelpers.cpp:
2498         (JSC::createInvalidPrivateNameError):
2499         (JSC::createRedefinedPrivateNameError):
2500         * runtime/ExceptionHelpers.h:
2501         * runtime/JSGlobalObject.cpp:
2502         (JSC::createPrivateSymbol):
2503         (JSC::JSGlobalObject::init):
2504         * runtime/JSObject.h:
2505         * runtime/JSObjectInlines.h:
2506         (JSC::JSObject::getPrivateFieldSlot):
2507         (JSC::JSObject::getPrivateField):
2508         (JSC::JSObject::putPrivateField):
2509         (JSC::JSObject::definePrivateField):
2510         * runtime/JSScope.cpp:
2511         (JSC::JSScope::collectClosureVariablesUnderTDZ):
2512         * runtime/OptionsList.h:
2513         * runtime/SymbolTable.cpp:
2514         (JSC::SymbolTable::cloneScopePart):
2515         * runtime/SymbolTable.h:
2516
2517 2020-06-05  Paulo Matos  <pmatos@igalia.com>
2518
2519         Fix includes to fix latest non-unified builds breakages
2520         https://bugs.webkit.org/show_bug.cgi?id=212802
2521
2522         Reviewed by Adrian Perez de Castro.
2523
2524         * dfg/DFGDoesGCCheck.cpp:
2525         * runtime/JSDateMath.h:
2526
2527 2020-06-04  Yusuke Suzuki  <ysuzuki@apple.com>
2528
2529         [JSC] Report extra memory allocation from PropertyTable
2530         https://bugs.webkit.org/show_bug.cgi?id=212793
2531
2532         Reviewed by Saam Barati.
2533
2534         This patch adds extra memory reporting from PropertyTable to make GC
2535         responsive to the increase of memory in PropertyTable.
2536
2537         * runtime/PropertyMapHashTable.h:
2538         (JSC::PropertyTable::add):
2539         (JSC::PropertyTable::remove):
2540         (JSC::PropertyTable::rehash):
2541         (JSC::PropertyTable::dataSize):
2542         * runtime/PropertyTable.cpp:
2543         (JSC::PropertyTable::finishCreation):
2544         (JSC::PropertyTable::visitChildren):
2545         * runtime/Structure.cpp:
2546         (JSC::Structure::materializePropertyTable):
2547         * runtime/StructureInlines.h:
2548         (JSC::Structure::add):
2549         (JSC::Structure::remove):
2550
2551 2020-06-04  Commit Queue  <commit-queue@webkit.org>
2552
2553         Unreviewed, reverting r262583.
2554         https://bugs.webkit.org/show_bug.cgi?id=212799
2555
2556         Internal source code has the same bug, needs to be landed
2557         after fixing internal source
2558
2559         Reverted changeset:
2560
2561         "DOM constructor should only accept Ref<> / ExceptionOr<Ref<>>
2562         for creation to ensure toJSNewlyCreated is always returning
2563         object"
2564         https://bugs.webkit.org/show_bug.cgi?id=212767
2565         https://trac.webkit.org/changeset/262583
2566
2567 2020-06-04  Michael Saboff  <msaboff@apple.com>
2568
2569         Add a Thread Specific Cache for LinkBuffer::CompactAndLinkCode()
2570         https://bugs.webkit.org/show_bug.cgi?id=212765
2571
2572         Reviewed by Saam Barati.
2573
2574         Added a thread local buffer for CPU types that use a second buffer when compacting.
2575         This is very similary to the work done in https://bugs.webkit.org/show_bug.cgi?id=212562.
2576
2577         * assembler/LinkBuffer.cpp:
2578         (JSC::threadSpecificBranchCompactionLinkBuffer):
2579         (JSC::BranchCompactionLinkBuffer::BranchCompactionLinkBuffer):
2580         (JSC::BranchCompactionLinkBuffer::~BranchCompactionLinkBuffer):
2581         (JSC::BranchCompactionLinkBuffer::data):
2582         (JSC::BranchCompactionLinkBuffer::takeBufferIfLarger):
2583         (JSC::BranchCompactionLinkBuffer::size):
2584         (JSC::LinkBuffer::copyCompactAndLinkCode):
2585
2586 2020-06-04  Mark Lam  <mark.lam@apple.com>
2587
2588         Add Options::validateDoesGC() for turning DoesGC validation on/off.
2589         https://bugs.webkit.org/show_bug.cgi?id=212773
2590
2591         Reviewed by Saam Barati.
2592
2593         It will default to on if ASSERT_ENABLED because we want testing to be done with
2594         the validation on.  When needed, we can turn it off if we need to e.g. to
2595         de-clutter disassembly dumps while debugging.
2596
2597         If Options::validateDoesGC() is false, we turn off JIT code emission for this
2598         check, as well as skip the validation checks.  There are still places in C++
2599         code that store to DoesGC::m_value without checking Options::validateDoesGC().
2600         It doesn't hurt to just let these stores proceed, and performance-wise, it's
2601         probably cheaper to just do the store unconditionally than to gate it on a load of
2602         Options::validateDoesGC() first.
2603
2604         Also made it explicit that the check on validateDFGDoesGC is a constexpr check.
2605
2606         * dfg/DFGDoesGCCheck.cpp:
2607         (JSC::DFG::DoesGCCheck::verifyCanGC):
2608         * dfg/DFGOSRExit.cpp:
2609         (JSC::DFG::OSRExit::compileExit):
2610         * dfg/DFGSpeculativeJIT32_64.cpp:
2611         (JSC::DFG::SpeculativeJIT::compile):
2612         * dfg/DFGSpeculativeJIT64.cpp:
2613         (JSC::DFG::SpeculativeJIT::compile):
2614         * ftl/FTLLowerDFGToB3.cpp:
2615         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2616         * ftl/FTLOSRExitCompiler.cpp:
2617         (JSC::FTL::compileStub):
2618         * runtime/OptionsList.h:
2619
2620 2020-06-04  Ross Kirsling  <ross.kirsling@sony.com>
2621
2622         Intl classes should have meaningful @@toStringTag values
2623         https://bugs.webkit.org/show_bug.cgi?id=212769
2624
2625         Reviewed by Yusuke Suzuki.
2626
2627         Implementation of https://github.com/tc39/ecma402/pull/430, which achieved consensus this week.
2628         This ensures we get "[object Intl.Collator]" (etc.) instead "[object Object]" for older Intl classes.
2629
2630         * runtime/IntlCollatorPrototype.cpp:
2631         * runtime/IntlDateTimeFormatPrototype.cpp:
2632         * runtime/IntlNumberFormatPrototype.cpp:
2633         * runtime/IntlPluralRulesPrototype.cpp:
2634
2635 2020-06-04  Alexey Shvayka  <shvaikalesh@gmail.com>
2636
2637         GetMethod isn't performed properly on iterators
2638         https://bugs.webkit.org/show_bug.cgi?id=212771
2639
2640         Reviewed by Saam Barati.
2641
2642         Before this change, iterator's "return" and "throw" methods with value of `null` were
2643         considered incorrect rather than missing, causing TypeError to be thrown.
2644
2645         This patch aligns method lookup of iterators with the spec [1], V8, and SpiderMonkey
2646         by utilizing isUndefinedOrNull(), which doesn't special-case [[IsHTMLDDA]] objects [2],
2647         fixing a few Annex B tests.
2648
2649         for/of microbenchmarks are neutral.
2650
2651         [1]: https://tc39.es/ecma262/#sec-getmethod (step 3)
2652         [2]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
2653
2654         * builtins/AsyncFromSyncIteratorPrototype.js:
2655         * bytecompiler/BytecodeGenerator.cpp:
2656         (JSC::BytecodeGenerator::emitIteratorGenericClose):
2657         (JSC::BytecodeGenerator::emitGetAsyncIterator):
2658         (JSC::BytecodeGenerator::emitDelegateYield):
2659         * runtime/IteratorOperations.cpp:
2660         (JSC::iteratorClose):
2661         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2662         (JSC::constructGenericTypedArrayViewWithArguments):
2663
2664 2020-06-04  Mark Lam  <mark.lam@apple.com>
2665
2666         Reduce DFGDoesGCCheck to only storing a uint32_t.
2667         https://bugs.webkit.org/show_bug.cgi?id=212734
2668
2669         Reviewed by Saam Barati and Caio Lima.
2670
2671         This patch changes the encoding of DoesGCCheck so that it will fit better in a
2672         uint32_t.  This has the following benefits:
2673         1. speed improvement for debug builds because it now takes less instructions
2674            (especially in JITted code) to store to DoesGCCheck::m_value.
2675         2. enables this check for 32-bit platforms as well.
2676
2677         Fun fact: we currently have 373 DFG::NodeTypes.  Hence, 9 bits for nodeOp.
2678
2679         The new encoding provides 21 bis for the nodeIndex.  This gives us up to 2097152
2680         node indexes.  In my experience, I've never seen more than 3 decimal digits for
2681         the nodeIndex so far.  If we ever find that we need more than 21 bits of nodeIndex,
2682         we have 2 options to deal with it:
2683
2684         1. We can just ignore the high bits.  After all, it is the nodeOp that is the
2685            most interesting piece of data we need to debug doesGC issues.
2686
2687         2. We can make DoesGCCheck use uint64_t for storage.  This encoding automatically
2688            scales to 64-bit, while still allowing the more efficient form of storing a
2689            32-bit immediate to be used for the common cases.
2690
2691         This patch also makes ENABLE_DFG_DOES_GC_VALIDATION dependent on ENABLE(DFG_JIT).
2692         DoesGC is only relevant for the DFG and FTL JITs.
2693
2694         * dfg/DFGDoesGCCheck.cpp:
2695         (JSC::DFG::DoesGCCheck::verifyCanGC):
2696         * dfg/DFGDoesGCCheck.h:
2697         (JSC::DFG::DoesGCCheck::encode):
2698         (JSC::DFG::DoesGCCheck::expectDoesGC const):
2699         (JSC::DFG::DoesGCCheck::isSpecial const):
2700         (JSC::DFG::DoesGCCheck::special):
2701         (JSC::DFG::DoesGCCheck::nodeOp):
2702         (JSC::DFG::DoesGCCheck::nodeIndex):
2703         (JSC::DFG::DoesGCCheck::expectDoesGC): Deleted.
2704         (JSC::DFG::DoesGCCheck::isSpecial): Deleted.
2705         (JSC::DFG::DoesGCCheck::specialIndex): Deleted.
2706         (JSC::DFG::DoesGCCheck::bits): Deleted.
2707         * dfg/DFGNodeType.h:
2708         * dfg/DFGOSRExit.cpp:
2709         (JSC::DFG::OSRExit::compileExit):
2710         * dfg/DFGSpeculativeJIT32_64.cpp:
2711         (JSC::DFG::SpeculativeJIT::compile):
2712         * dfg/DFGSpeculativeJIT64.cpp:
2713         (JSC::DFG::SpeculativeJIT::compile):
2714         * ftl/FTLLowerDFGToB3.cpp:
2715         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2716         * ftl/FTLOSRExitCompiler.cpp:
2717         (JSC::FTL::compileStub):
2718         * heap/Heap.h:
2719
2720 2020-06-04  Tim Horton  <timothy_horton@apple.com>
2721
2722         Work around broken system version macro
2723         https://bugs.webkit.org/show_bug.cgi?id=212726
2724
2725         Reviewed by Dan Bernstein.
2726
2727         * Configurations/DebugRelease.xcconfig:
2728
2729 2020-06-04  Andy Estes  <aestes@apple.com>
2730
2731         [watchOS] Re-enable content filtering in the simulator build
2732         https://bugs.webkit.org/show_bug.cgi?id=212711
2733         <rdar://problem/63938350>
2734
2735         Reviewed by Wenson Hsieh.
2736
2737         * Configurations/FeatureDefines.xcconfig:
2738
2739 2020-06-04  Mark Lam  <mark.lam@apple.com>
2740
2741         SpeculativeJIT::compileDateGet()'s slow path does not need an exception check.
2742         https://bugs.webkit.org/show_bug.cgi?id=212645
2743
2744         Reviewed by Yusuke Suzuki.
2745
2746         SpeculativeJIT::compileDateGet() implements a bunch of Date intrinsics which call
2747         into a C++ operation function do their work.  However, the call to these operation
2748         functions were done using a slow path generator configured to automatically
2749         emit exception checks after the call.  These exception checks are unneeded because
2750         those functions will not throw any exceptions.
2751
2752         This issue was found with JSC stress test runs on a debug build.  The doesGC
2753         verifier was failing on the exceptionFuzz/date-format-xparb.js test.  The reason
2754         is because doesGC does not expect any these Date intrinsics to throw any exceptions,
2755         but SpeculativeJIT was emitting the unneeded exception checks there.  These
2756         exception check sites get turned into throw sites by the exceptionFuzzer, and
2757         they allocate an Error object there.  This allocation made the doesGC verifier
2758         not happy.
2759
2760         This patch fixes this issue by changing SpeculativeJIT::compileDateGet() to
2761         pass ExceptionCheckRequirement::CheckNotNeeded to the slow path generator.
2762
2763         The patch also proves that all the operation functions cannot throw any exceptions.
2764         Previously, the operations passes a VM& to the Date functions.  The purpose for
2765         doing this is so that the Date functions can work with a few date cache data
2766         structures stored as VM fields.
2767
2768         This patch refactors those VM fields into a VM::DateCache struct, and changed all
2769         those Date functions to take a VM::DateCache& instead of a VM&.  Since the Date
2770         functions no longer take a VM&, this proves that they cannot throw because they
2771         would need a VM& to make a ThrowScope in order to throw.
2772
2773         Update: Yusuke pointed out that the lack of a JSGlobalObject* argument is sufficient
2774         to guarantee that the Date functions cannot throw.  However, we'll keep this
2775         DateCache refactoring since it provides additional info that the Date functions
2776         only operate on the DateCache fields and nothing else in VM.
2777
2778         Also removed DFG::JITCompile's fastExceptionCheck() which is unused.
2779
2780         * dfg/DFGJITCompiler.h:
2781         (JSC::DFG::JITCompiler::fastExceptionCheck): Deleted.
2782         * dfg/DFGOperations.cpp:
2783         * dfg/DFGSpeculativeJIT64.cpp:
2784         (JSC::DFG::SpeculativeJIT::compileDateGet):
2785         * runtime/DateConstructor.cpp:
2786         (JSC::millisecondsFromComponents):
2787         (JSC::callDate):
2788         * runtime/DateInstance.cpp:
2789         (JSC::DateInstance::calculateGregorianDateTime const):
2790         (JSC::DateInstance::calculateGregorianDateTimeUTC const):
2791         * runtime/DateInstance.h:
2792         * runtime/DatePrototype.cpp:
2793         (JSC::formatLocaleDate):
2794         (JSC::formateDateInstance):
2795         (JSC::dateProtoFuncToISOString):
2796         (JSC::dateProtoFuncGetFullYear):
2797         (JSC::dateProtoFuncGetUTCFullYear):
2798         (JSC::dateProtoFuncGetMonth):
2799         (JSC::dateProtoFuncGetUTCMonth):
2800         (JSC::dateProtoFuncGetDate):
2801         (JSC::dateProtoFuncGetUTCDate):
2802         (JSC::dateProtoFuncGetDay):
2803         (JSC::dateProtoFuncGetUTCDay):
2804         (JSC::dateProtoFuncGetHours):
2805         (JSC::dateProtoFuncGetUTCHours):
2806         (JSC::dateProtoFuncGetMinutes):
2807         (JSC::dateProtoFuncGetUTCMinutes):
2808         (JSC::dateProtoFuncGetSeconds):
2809         (JSC::dateProtoFuncGetUTCSeconds):
2810         (JSC::dateProtoFuncGetTimezoneOffset):
2811         (JSC::setNewValueFromTimeArgs):
2812         (JSC::setNewValueFromDateArgs):
2813         (JSC::dateProtoFuncSetYear):
2814         (JSC::dateProtoFuncGetYear):
2815         * runtime/JSDateMath.cpp:
2816         (JSC::localTimeOffset):
2817         (JSC::gregorianDateTimeToMS):
2818         (JSC::msToGregorianDateTime):
2819         (JSC::parseDate):
2820         * runtime/JSDateMath.h:
2821         * runtime/VM.cpp:
2822         (JSC::VM::resetDateCache):
2823         * runtime/VM.h:
2824
2825 2020-06-04  Paulo Matos  <pmatos@igalia.com>
2826
2827         Fix 32bit build broken at r262513
2828         https://bugs.webkit.org/show_bug.cgi?id=212735
2829
2830         Unreviewed Gardening.
2831
2832         Proper fix is being worked out under https://bugs.webkit.org/show_bug.cgi?id=212734
2833
2834         * dfg/DFGOSRExit.cpp:
2835         (JSC::DFG::OSRExit::compileExit):
2836
2837 2020-06-03  Tadeu Zagallo  <tzagallo@apple.com>
2838
2839         Disable B3 hoistLoopInvariantValues by default
2840         https://bugs.webkit.org/show_bug.cgi?id=212511
2841         <rdar://problem/63813245>
2842
2843         Reviewed by Mark Lam.
2844
2845         The hoistLoopInvariantValues optimization in B3 does not calculate the cost of hoisting the candidates.
2846         For example, in the test case provided with the bug, a switch inside a loop can lead to hoisting the body
2847         of several switch cases which would never be executed. Other than leading to worse runtime, this also
2848         increases the pressure in the register allocate, leading to worse compile times (~10x worse in this case).
2849         I have added a FIXME to consider adding cost calculation and re-enabling this pass, but given that we
2850         already have LICM in DFG, it should be ok to disable it for now.
2851
2852         * b3/B3Generate.cpp:
2853         (JSC::B3::generateToAir):
2854         * runtime/OptionsList.h:
2855
2856 2020-06-03  Mark Lam  <mark.lam@apple.com>
2857
2858         Gardening: fix broken Windows debug build.
2859         https://bugs.webkit.org/show_bug.cgi?id=212680
2860
2861         Not reviewed.
2862
2863         * dfg/DFGDoesGCCheck.cpp:
2864         (JSC::DFG::DoesGCCheck::verifyCanGC):
2865         * dfg/DFGDoesGCCheck.h:
2866
2867 2020-06-03  Mark Lam  <mark.lam@apple.com>
2868
2869         [Re-landing] Enhance DoesGC verification to print more useful info when verification fails.
2870         https://bugs.webkit.org/show_bug.cgi?id=212680
2871
2872         Reviewed by Yusuke Susuki.
2873
2874         When DoesGC verification fails, the first step of debugging it would be to find
2875         out what and which DFG node resulted in the failed verification.  In pre-existing
2876         code, all we get is an assertion failure.
2877
2878         This patch makes it so that the verifier will dump useful info.  Here's an example:
2879
2880             Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
2881                 [0] frame 0x7ffee8285660 {
2882                   name: 
2883                   sourceURL: 
2884                   isInlinedFrame: false
2885                   callee: 0x1135f6820
2886                   returnPC: 0x50ce61248ae6
2887                   callerFrame: 0x7ffee82856f0
2888                   rawLocationBits: 5 0x5
2889                   codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
2890                     hasCodeOrigins: true
2891                     callSiteIndex: 5 of 13
2892                     jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
2893                     line: 1
2894                     column: 60
2895                   EntryFrame: 0x7ffee8285860
2896                 }
2897                 [1] frame 0x7ffee82856f0 {
2898                   name: 
2899                   sourceURL: date-format-xparb.js
2900                   isInlinedFrame: false
2901                   callee: 0x1135f65a0
2902                   returnPC: 0x50ce61227e99
2903                   callerFrame: 0x7ffee8285770
2904                   rawLocationBits: 4 0x4
2905                   codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
2906                     hasCodeOrigins: true
2907                     callSiteIndex: 4 of 12
2908                     jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
2909                     line: 26
2910                     column: 22
2911                   EntryFrame: 0x7ffee8285860
2912                 }
2913                 [2] frame 0x7ffee8285770 {
2914                   name: 
2915                   sourceURL: date-format-xparb.js
2916                   isInlinedFrame: false
2917                   callee: 0x1135f64e0
2918                   returnPC: 0x108058eb1
2919                   callerFrame: 0x7ffee82857e0
2920                   rawLocationBits: 1001 0x3e9
2921                   codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
2922                     bc#1001 of 1149
2923                     line: 417
2924                     column: 38
2925                   EntryFrame: 0x7ffee8285860
2926                 }
2927                 [3] frame 0x7ffee82857e0 {
2928                   name: global code
2929                   sourceURL: date-format-xparb.js
2930                   isInlinedFrame: false
2931                   callee: 0x1130f97b8
2932                   returnPC: 0x108039043
2933                   callerFrame: 0x0
2934                   rawLocationBits: 23 0x17
2935                   codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
2936                     bc#23 of 81
2937                     line: 425
2938                     column: 3
2939                   EntryFrame: 0x7ffee8285860
2940                 }
2941
2942             ASSERTION FAILED: expectDoesGC()
2943
2944         The error message now comes with the node index, NodeType, codeBlock which this
2945         failure was found in, and the JS call stack that led to the failure.
2946
2947         Changes made:
2948
2949         1. Introduced a DoesGCCheck value that is used to encode some of the above data.
2950
2951            Previously, we only recorded whether doesGC() returns true or false for the
2952            Node.  Now, we record the nodeIndex and nodeOp as well.
2953
2954            Note that we also set DoesGC expectations for OSR exits.  So, DoesGCCheck
2955            includes Special cases for those.
2956
2957         2. Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64.
2958            Also added a test for this new emitter in testmasm.
2959
2960         * CMakeLists.txt:
2961         * JavaScriptCore.xcodeproj/project.pbxproj:
2962         * Sources.txt:
2963         * assembler/MacroAssemblerARM64.h:
2964         (JSC::MacroAssemblerARM64::store64):
2965         * assembler/MacroAssemblerX86_64.h:
2966         (JSC::MacroAssemblerX86_64::store64):
2967         * assembler/testmasm.cpp:
2968         (JSC::testStore64Imm64AddressPointer):
2969         (JSC::run):
2970         * dfg/DFGDoesGCCheck.cpp: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.cpp.
2971         * dfg/DFGDoesGCCheck.h: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.h.
2972         * dfg/DFGGraph.cpp:
2973         * dfg/DFGOSRExit.cpp:
2974         (JSC::DFG::operationCompileOSRExit):
2975         (JSC::DFG::OSRExit::compileExit):
2976         * dfg/DFGSpeculativeJIT64.cpp:
2977         (JSC::DFG::SpeculativeJIT::compile):
2978         * ftl/FTLLowerDFGToB3.cpp:
2979         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2980         * ftl/FTLOSRExitCompiler.cpp:
2981         (JSC::FTL::compileStub):
2982         (JSC::FTL::operationCompileFTLOSRExit):
2983         * heap/CompleteSubspace.cpp:
2984         (JSC::CompleteSubspace::tryAllocateSlow):
2985         (JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
2986         * heap/CompleteSubspaceInlines.h:
2987         (JSC::CompleteSubspace::allocateNonVirtual):
2988         * heap/DeferGC.h:
2989         (JSC::DeferGC::~DeferGC):
2990         * heap/GCDeferralContextInlines.h:
2991         (JSC::GCDeferralContext::~GCDeferralContext):
2992         * heap/Heap.cpp:
2993         (JSC::Heap::collectNow):
2994         (JSC::Heap::collectAsync):
2995         (JSC::Heap::collectSync):
2996         (JSC::Heap::stopIfNecessarySlow):
2997         (JSC::Heap::collectIfNecessaryOrDefer):
2998         * heap/Heap.h:
2999         (JSC::Heap::addressOfDoesGC):
3000         (JSC::Heap::setDoesGCExpectation):
3001         (JSC::Heap::verifyCanGC):
3002         (JSC::Heap::expectDoesGC const): Deleted.
3003         (JSC::Heap::setExpectDoesGC): Deleted.
3004         (JSC::Heap::addressOfExpectDoesGC): Deleted.
3005         * heap/HeapInlines.h:
3006         (JSC::Heap::acquireAccess):
3007         (JSC::Heap::stopIfNecessary):
3008         * heap/LocalAllocatorInlines.h:
3009         (JSC::LocalAllocator::allocate):
3010         * heap/PreciseAllocation.cpp:
3011         (JSC::PreciseAllocation::tryCreate):
3012         (JSC::PreciseAllocation::createForLowerTier):
3013         * runtime/JSString.h:
3014         (JSC::jsSingleCharacterString):
3015         (JSC::JSString::toAtomString const):
3016         (JSC::JSString::toExistingAtomString const):
3017         (JSC::JSString::value const):
3018         (JSC::JSString::tryGetValue const):
3019         (JSC::JSRopeString::unsafeView const):
3020         (JSC::JSRopeString::viewWithUnderlyingString const):
3021         (JSC::JSString::unsafeView const):
3022         * runtime/RegExpMatchesArray.h:
3023         (JSC::createRegExpMatchesArray):
3024
3025 2020-06-03  Mark Lam  <mark.lam@apple.com>
3026
3027         DFGSSAConversionPhase.cpp needs to #include OperandsInlines.h.
3028         https://bugs.webkit.org/show_bug.cgi?id=212687
3029
3030         Reviewed by Keith Miller.
3031
3032         Without this, strange build failures can happen with unified builds.
3033
3034         For example, the Windows build started failing due a linkage error in this file
3035         when the patch from https://bugs.webkit.org/show_bug.cgi?id=212680 landed.
3036         212680 introduced a new .cpp file, and that probably bumped DFGSSAConversionPhase.cpp
3037         into another unified unit, thereby depriving it from seeing the OperandsInlines.h
3038         #include'd by another .cpp.
3039
3040         * dfg/DFGSSAConversionPhase.cpp:
3041
3042 2020-06-03  Mark Lam  <mark.lam@apple.com>
3043
3044         Fix non-unified --jsc-only build.
3045         https://bugs.webkit.org/show_bug.cgi?id=212707
3046
3047         Reviewed by Yusuke Suzuki.
3048
3049         These files need JSGlobalObjectInlines.h.  But rather than adding yet another
3050         #include, we'll just remove many individual ones and just #include JSCInlines.h
3051         instead.
3052
3053         * wasm/js/JSToWasmICCallee.cpp:
3054         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
3055         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
3056         * wasm/js/WebAssemblyGlobalPrototype.cpp:
3057         * wasm/js/WebAssemblyInstanceConstructor.cpp:
3058         * wasm/js/WebAssemblyInstancePrototype.cpp:
3059         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
3060         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
3061         * wasm/js/WebAssemblyModulePrototype.cpp:
3062         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
3063         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
3064
3065 2020-06-03  Rob Buis  <rbuis@igalia.com>
3066
3067         Make generated C++ code use modern C++
3068         https://bugs.webkit.org/show_bug.cgi?id=190714
3069
3070         Reviewed by Jonathan Bedard.
3071
3072         Update inspector protocol generator and rebaseline the tests.
3073
3074         * inspector/scripts/codegen/cpp_generator_templates.py:
3075         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
3076         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
3077         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
3078         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
3079         * inspector/scripts/tests/expected/enum-values.json-result:
3080         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
3081         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
3082         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
3083         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
3084         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
3085         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
3086         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
3087         * yarr/generateYarrUnicodePropertyTables.py:
3088
3089 2020-06-02  Mark Lam  <mark.lam@apple.com>
3090
3091         Rolling out r262475 to unbreak Windows bot.
3092         https://bugs.webkit.org/show_bug.cgi?id=212680
3093
3094         Not reviewed.
3095
3096         * CMakeLists.txt:
3097         * JavaScriptCore.xcodeproj/project.pbxproj:
3098         * Sources.txt:
3099         * assembler/MacroAssemblerARM64.h:
3100         * assembler/MacroAssemblerX86_64.h:
3101         * assembler/testmasm.cpp:
3102         (JSC::testCountTrailingZeros64WithoutNullCheck):
3103         (JSC::run):
3104         (JSC::testStore64Imm64AddressPointer): Deleted.
3105         * dfg/DFGDoesGCCheck.cpp: Removed.
3106         * dfg/DFGDoesGCCheck.h: Removed.
3107         * dfg/DFGGraph.cpp:
3108         * dfg/DFGOSRExit.cpp:
3109         (JSC::DFG::operationCompileOSRExit):
3110         (JSC::DFG::OSRExit::compileExit):
3111         * dfg/DFGSpeculativeJIT64.cpp:
3112         (JSC::DFG::SpeculativeJIT::compile):
3113         * ftl/FTLLowerDFGToB3.cpp:
3114         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3115         * ftl/FTLOSRExitCompiler.cpp:
3116         (JSC::FTL::compileStub):
3117         (JSC::FTL::operationCompileFTLOSRExit):
3118         * heap/CompleteSubspace.cpp:
3119         (JSC::CompleteSubspace::tryAllocateSlow):
3120         (JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
3121         * heap/CompleteSubspaceInlines.h:
3122         (JSC::CompleteSubspace::allocateNonVirtual):
3123         * heap/DeferGC.h:
3124         (JSC::DeferGC::~DeferGC):
3125         * heap/GCDeferralContextInlines.h:
3126         (JSC::GCDeferralContext::~GCDeferralContext):
3127         * heap/Heap.cpp:
3128         (JSC::Heap::collectNow):
3129         (JSC::Heap::collectAsync):
3130         (JSC::Heap::collectSync):
3131         (JSC::Heap::stopIfNecessarySlow):
3132         (JSC::Heap::collectIfNecessaryOrDefer):
3133         * heap/Heap.h:
3134         (JSC::Heap::expectDoesGC const):
3135         (JSC::Heap::setExpectDoesGC):
3136         (JSC::Heap::addressOfExpectDoesGC):
3137         (JSC::Heap::addressOfDoesGC): Deleted.
3138         (JSC::Heap::setDoesGCExpectation): Deleted.
3139         (JSC::Heap::verifyCanGC): Deleted.
3140         * heap/HeapInlines.h:
3141         (JSC::Heap::acquireAccess):
3142         (JSC::Heap::stopIfNecessary):
3143         * heap/LocalAllocatorInlines.h:
3144         (JSC::LocalAllocator::allocate):
3145         * heap/PreciseAllocation.cpp:
3146         (JSC::PreciseAllocation::tryCreate):
3147         (JSC::PreciseAllocation::createForLowerTier):
3148         * runtime/JSString.h:
3149         (JSC::jsSingleCharacterString):
3150         (JSC::JSString::toAtomString const):
3151         (JSC::JSString::toExistingAtomString const):
3152         (JSC::JSString::value const):
3153         (JSC::JSString::tryGetValue const):
3154         (JSC::JSRopeString::unsafeView const):
3155         (JSC::JSRopeString::viewWithUnderlyingString const):
3156         (JSC::JSString::unsafeView const):
3157         * runtime/RegExpMatchesArray.h:
3158         (JSC::createRegExpMatchesArray):
3159
3160 2020-06-02  Mark Lam  <mark.lam@apple.com>
3161
3162         Enhance DoesGC verification to print more useful info when verification fails.
3163         https://bugs.webkit.org/show_bug.cgi?id=212680
3164
3165         Reviewed by Yusuke Suzuki.
3166
3167         When DoesGC verification fails, the first step of debugging it would be to find
3168         out what and which DFG node resulted in the failed verification.  In pre-existing
3169         code, all we get is an assertion failure.
3170
3171         This patch makes it so that the verifier will dump useful info.  Here's an example:
3172
3173             Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
3174                 [0] frame 0x7ffee8285660 {
3175                   name: 
3176                   sourceURL: 
3177                   isInlinedFrame: false
3178                   callee: 0x1135f6820
3179                   returnPC: 0x50ce61248ae6
3180                   callerFrame: 0x7ffee82856f0
3181                   rawLocationBits: 5 0x5
3182                   codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
3183                     hasCodeOrigins: true
3184                     callSiteIndex: 5 of 13
3185                     jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
3186                     line: 1
3187                     column: 60
3188                   EntryFrame: 0x7ffee8285860
3189                 }
3190                 [1] frame 0x7ffee82856f0 {
3191                   name: 
3192                   sourceURL: date-format-xparb.js
3193                   isInlinedFrame: false
3194                   callee: 0x1135f65a0
3195                   returnPC: 0x50ce61227e99
3196                   callerFrame: 0x7ffee8285770
3197                   rawLocationBits: 4 0x4
3198                   codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
3199                     hasCodeOrigins: true
3200                     callSiteIndex: 4 of 12
3201                     jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
3202                     line: 26
3203                     column: 22
3204                   EntryFrame: 0x7ffee8285860
3205                 }
3206                 [2] frame 0x7ffee8285770 {
3207                   name: 
3208                   sourceURL: date-format-xparb.js
3209                   isInlinedFrame: false
3210                   callee: 0x1135f64e0
3211                   returnPC: 0x108058eb1
3212                   callerFrame: 0x7ffee82857e0
3213                   rawLocationBits: 1001 0x3e9
3214                   codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
3215                     bc#1001 of 1149
3216                     line: 417
3217                     column: 38
3218                   EntryFrame: 0x7ffee8285860
3219                 }
3220                 [3] frame 0x7ffee82857e0 {
3221                   name: global code
3222                   sourceURL: date-format-xparb.js
3223                   isInlinedFrame: false
3224                   callee: 0x1130f97b8
3225                   returnPC: 0x108039043
3226                   callerFrame: 0x0
3227                   rawLocationBits: 23 0x17
3228                   codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
3229                     bc#23 of 81
3230                     line: 425
3231                     column: 3
3232                   EntryFrame: 0x7ffee8285860
3233                 }
3234
3235             ASSERTION FAILED: expectDoesGC()
3236
3237         The error message now comes with the node index, NodeType, codeBlock which this
3238         failure was found in, and the JS call stack that led to the failure.
3239
3240         Changes made:
3241
3242         1. Introduced a DoesGCCheck value that is used to encode some of the above data.
3243
3244            Previously, we only recorded whether doesGC() returns true or false for the
3245            Node.  Now, we record the nodeIndex and nodeOp as well.
3246
3247            Note that we also set DoesGC expectations for OSR exits.  So, DoesGCCheck
3248            includes Special cases for those.
3249
3250         2. Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64.
3251            Also added a test for this new emitter in testmasm.
3252
3253         * CMakeLists.txt:
3254         * JavaScriptCore.xcodeproj/project.pbxproj:
3255         * Sources.txt:
3256         * assembler/MacroAssemblerARM64.h:
3257         (JSC::MacroAssemblerARM64::store64):
3258         * assembler/MacroAssemblerX86_64.h:
3259         (JSC::MacroAssemblerX86_64::store64):
3260         * assembler/testmasm.cpp:
3261         (JSC::testStore64Imm64AddressPointer):
3262         (JSC::run):
3263         * dfg/DFGDoesGCCheck.cpp: Added.
3264         (JSC::DFG::DoesGCCheck::verifyCanGC):
3265         * dfg/DFGDoesGCCheck.h: Added.
3266         (JSC::DFG::DoesGCCheck::DoesGCCheck):
3267         (JSC::DFG::DoesGCCheck::encode):
3268         (JSC::DFG::DoesGCCheck::set):
3269         (JSC::DFG::DoesGCCheck::expectDoesGC):
3270         (JSC::DFG::DoesGCCheck::special):
3271         (JSC::DFG::DoesGCCheck::nodeIndex):
3272         (JSC::DFG::DoesGCCheck::nodeOp):
3273         (JSC::DFG::DoesGCCheck::isSpecial):
3274         (JSC::DFG::DoesGCCheck::specialIndex):
3275         (JSC::DFG::DoesGCCheck::bits):
3276         * dfg/DFGGraph.cpp:
3277         * dfg/DFGOSRExit.cpp:
3278         (JSC::DFG::operationCompileOSRExit):
3279         (JSC::DFG::OSRExit::compileExit):
3280         * dfg/DFGSpeculativeJIT64.cpp:
3281         (JSC::DFG::SpeculativeJIT::compile):
3282         * ftl/FTLLowerDFGToB3.cpp:
3283         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3284         * ftl/FTLOSRExitCompiler.cpp:
3285         (JSC::FTL::compileStub):
3286         (JSC::FTL::operationCompileFTLOSRExit):
3287         * heap/CompleteSubspace.cpp:
3288         (JSC::CompleteSubspace::tryAllocateSlow):
3289         (JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
3290         * heap/CompleteSubspaceInlines.h:
3291         (JSC::CompleteSubspace::allocateNonVirtual):
3292         * heap/DeferGC.h:
3293         (JSC::DeferGC::~DeferGC):
3294         * heap/GCDeferralContextInlines.h:
3295         (JSC::GCDeferralContext::~GCDeferralContext):
3296         * heap/Heap.cpp:
3297         (JSC::Heap::collectNow):
3298         (JSC::Heap::collectAsync):
3299         (JSC::Heap::collectSync):
3300         (JSC::Heap::stopIfNecessarySlow):
3301         (JSC::Heap::collectIfNecessaryOrDefer):
3302         * heap/Heap.h:
3303         (JSC::Heap::addressOfDoesGC):