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