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