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