[BigInt] Add ValueBitLShift into DFG
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-07-12  Caio Lima  <ticaiolima@gmail.com>
2
3         [BigInt] Add ValueBitLShift into DFG
4         https://bugs.webkit.org/show_bug.cgi?id=192664
5
6         Reviewed by Saam Barati.
7
8         This patch is splitting the `BitLShift` into `ArithBitLShift` and
9         `ValueBitLShift` to handle BigInt speculation more efficiently during
10         DFG and FTL layers. Following the same approach of other `ValueBitOps`,
11         `ValueBitLShift` handles Untyped and BigInt speculations, while
12         `ArithBitLShift` handles number and boolean operands and always results into
13         Int32. 
14
15         * bytecode/BytecodeList.rb:
16         * bytecode/CodeBlock.cpp:
17         (JSC::CodeBlock::finishCreation):
18         * bytecode/Opcode.h:
19         * dfg/DFGAbstractInterpreter.h:
20         * dfg/DFGAbstractInterpreterInlines.h:
21         (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantBinaryBitwiseOp):
22         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
23
24         We moved `BitLShift` constant fold rules to a new method
25         `handleConstantBinaryBitwiseOp` to be reused by `ArithBitLShift` and
26         `ValueBitLShift`. This also enables support of constant folding on other
27         bitwise operations like `ValueBitAnd`, `ValueBitOr` and `ValueBitXor`, when
28         their binary use kind is UntypedUse. Such cases can happen on those
29         nodes because fixup phase is conservative.
30
31         * dfg/DFGBackwardsPropagationPhase.cpp:
32         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
33         (JSC::DFG::BackwardsPropagationPhase::propagate):
34         * dfg/DFGByteCodeParser.cpp:
35         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
36         (JSC::DFG::ByteCodeParser::parseBlock):
37
38         We parse `op_lshift` as `ArithBitLShift` when its operands are numbers.
39         Otherwise, we fallback to `ValueBitLShift` and rely on fixup phase to
40         convert `ValueBitLShift` into `ArithBitLShift` when possible.
41
42         * dfg/DFGClobberize.h:
43         (JSC::DFG::clobberize):
44
45         `ArithBitLShift` has the same clobberize rules as former `BitLShift`.
46         `ValueBitLShift` only clobberize world when it is UntypedUse.
47
48         * dfg/DFGDoesGC.cpp:
49         (JSC::DFG::doesGC):
50
51         `ValueBitLShift` can GC when `BigIntUse` because it allocates new
52         JSBigInts to perform this operation. It also can GC on UntypedUse
53         because of observable user code.
54
55         * dfg/DFGFixupPhase.cpp:
56         (JSC::DFG::FixupPhase::fixupNode):
57
58         `ValueBitLShift` and `ArithBitLShift` has the same fixup rules of
59         other binary bitwise operations. In the case of `ValueBitLShift`
60         We check if we should speculate on BigInt or Untyped and fallback to
61         `ArithBitLShift` when both cheks fail.
62
63         * dfg/DFGNode.h:
64         (JSC::DFG::Node::hasHeapPrediction):
65         * dfg/DFGNodeType.h:
66         * dfg/DFGOperations.cpp:
67
68         We updated `operationValueBitLShift` to handle BigInt cases. Also, we
69         added `operationBitLShiftBigInt` that is used when we compile
70         `ValueBitLValueBitLShift(BigIntUse)`.
71
72         * dfg/DFGOperations.h:
73         * dfg/DFGPredictionPropagationPhase.cpp:
74
75         `ValueBitLShift`'s prediction propagation rules differs from other
76         bitwise operations, because using only heap prediction for this node causes
77         significant performance regression on Octane's zlib and mandreel.
78         The reason is because of cases where a function is compiled but the
79         instruction `op_lshift` was never executed before. If we use
80         `getPrediction()` we will emit a `ForceOSRExit`, resulting in more OSR
81         than desired. To solve such issue, we are then using
82         `getPredictionWithoutOSR()` and falling back to `getHeapPrediction()`
83         only on cases where we can't rely on node's input types.
84
85         * dfg/DFGSafeToExecute.h:
86         (JSC::DFG::safeToExecute):
87         * dfg/DFGSpeculativeJIT.cpp:
88         (JSC::DFG::SpeculativeJIT::compileValueLShiftOp):
89         (JSC::DFG::SpeculativeJIT::compileShiftOp):
90         * dfg/DFGSpeculativeJIT.h:
91         (JSC::DFG::SpeculativeJIT::shiftOp):
92         * dfg/DFGSpeculativeJIT32_64.cpp:
93         (JSC::DFG::SpeculativeJIT::compile):
94         * dfg/DFGSpeculativeJIT64.cpp:
95         (JSC::DFG::SpeculativeJIT::compile):
96         * dfg/DFGStrengthReductionPhase.cpp:
97         (JSC::DFG::StrengthReductionPhase::handleNode):
98         * ftl/FTLCapabilities.cpp:
99         (JSC::FTL::canCompile):
100         * ftl/FTLLowerDFGToB3.cpp:
101         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
102         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitLShift):
103         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
104         (JSC::FTL::DFG::LowerDFGToB3::compileBitLShift): Deleted.
105         * llint/LowLevelInterpreter32_64.asm:
106         * llint/LowLevelInterpreter64.asm:
107         * runtime/CommonSlowPaths.cpp:
108         (JSC::SLOW_PATH_DECL):
109
110 2019-07-12  Keith Miller  <keith_miller@apple.com>
111
112         getIndexQuickly should be const
113         https://bugs.webkit.org/show_bug.cgi?id=199747
114
115         Reviewed by Yusuke Suzuki.
116
117         * runtime/Butterfly.h:
118         (JSC::Butterfly::indexingPayload const):
119         (JSC::Butterfly::arrayStorage const):
120         (JSC::Butterfly::contiguousInt32 const):
121         (JSC::Butterfly::contiguousDouble const):
122         (JSC::Butterfly::contiguous const):
123         * runtime/JSObject.h:
124         (JSC::JSObject::canGetIndexQuickly const):
125         (JSC::JSObject::getIndexQuickly const):
126         (JSC::JSObject::tryGetIndexQuickly const):
127         (JSC::JSObject::canGetIndexQuickly): Deleted.
128         (JSC::JSObject::getIndexQuickly): Deleted.
129
130 2019-07-11  Justin Michaud  <justin_michaud@apple.com>
131
132         Add b3 macro lowering for CheckMul on arm64
133         https://bugs.webkit.org/show_bug.cgi?id=199251
134
135         Reviewed by Robin Morisset.
136
137         - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
138         - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
139         - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
140         - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
141           and no change on the no-constant benchmark.
142         Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
143         to completion.
144
145         * assembler/MacroAssemblerARM64.h:
146         (JSC::MacroAssemblerARM64::multiplySignExtend32):
147         * assembler/testmasm.cpp:
148         (JSC::testMul32SignExtend):
149         (JSC::run):
150         * b3/B3LowerMacros.cpp:
151         * b3/B3LowerToAir.cpp:
152         * b3/air/AirOpcode.opcodes:
153         * b3/testb3.cpp:
154         (JSC::B3::testMulArgs32SignExtend):
155         (JSC::B3::testMulImm32SignExtend):
156         (JSC::B3::testMemoryFence):
157         (JSC::B3::testStoreFence):
158         (JSC::B3::testLoadFence):
159         (JSC::B3::testPinRegisters):
160         (JSC::B3::run):
161
162 2019-07-11  Yusuke Suzuki  <ysuzuki@apple.com>
163
164         Unreviewed, revert r243617.
165         https://bugs.webkit.org/show_bug.cgi?id=196341
166
167         Mark pointed out that JSVirtualMachine can be gone in the other thread while we are executing GC constraint-solving.
168         This patch does not account that JavaScriptCore.framework is multi-thread safe: JSVirtualMachine wrapper can be destroyed,
169         and [JSVirtualMachine dealloc] can be executed in any threads while the VM is retained and used in the other thread (e.g.
170         destroyed from AutoReleasePool in some thread).
171
172         * API/JSContext.mm:
173         (-[JSContext initWithVirtualMachine:]):
174         (-[JSContext dealloc]):
175         (-[JSContext initWithGlobalContextRef:]):
176         (-[JSContext wrapperMap]):
177         (+[JSContext contextWithJSGlobalContextRef:]):
178         * API/JSVirtualMachine.mm:
179         (initWrapperCache):
180         (wrapperCache):
181         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
182         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
183         (-[JSVirtualMachine initWithContextGroupRef:]):
184         (-[JSVirtualMachine dealloc]):
185         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
186         (-[JSVirtualMachine contextForGlobalContextRef:]):
187         (-[JSVirtualMachine addContext:forGlobalContextRef:]):
188         (scanExternalObjectGraph):
189         (scanExternalRememberedSet):
190         * API/JSVirtualMachineInternal.h:
191         * runtime/JSGlobalObject.h:
192         (JSC::JSGlobalObject::setWrapperMap):
193         (JSC::JSGlobalObject::setAPIWrapper): Deleted.
194         (JSC::JSGlobalObject::apiWrapper const): Deleted.
195         * runtime/VM.h:
196
197 2019-07-10  Tadeu Zagallo  <tzagallo@apple.com>
198
199         Optimize join of large empty arrays
200         https://bugs.webkit.org/show_bug.cgi?id=199636
201
202         Reviewed by Mark Lam.
203
204         Replicate the behavior of `str.repeat(count)` when performing `new Array(count + 1).join(str)`.
205         I added two new microbenchmarks:
206         - large-empty-array-join, which does not use the result of the join and runs ~44x faster and uses ~18x less memory.
207         - large-empty-array-join-resolve-rope, which uses the result of the join and runs 2x faster.
208
209                                                     baseline                    diff
210         large-empty-array-join                2713.9698+-72.7621    ^     61.2335+-10.4836       ^ definitely 44.3217x faster
211         large-empty-array-join-resolve-string   26.5517+-0.3995     ^     12.9309+-0.5516        ^ definitely 2.0533x faster
212
213         large-empty-array-join memory usage with baseline (dirty):
214             733012 kB current_mem
215             756824 kB lifetime_peak
216
217         large-empty-array-join memory usage with diff (dirty):
218             41904 kB current_mem
219             41972 kB lifetime_peak
220
221         Additionally, I ran JetStream2, sunspider and v8-spider and all were neutral.
222
223         * runtime/ArrayPrototype.cpp:
224         (JSC::fastJoin):
225
226 2019-07-08  Keith Miller  <keith_miller@apple.com>
227
228         Enable Intl.PluralRules and Intl.NumberFormatToParts by default
229         https://bugs.webkit.org/show_bug.cgi?id=199288
230
231         Reviewed by Yusuke Suzuki.
232
233         These features have been around for a while. We should turn them on by default.
234
235         * runtime/IntlNumberFormatPrototype.cpp:
236         (JSC::IntlNumberFormatPrototype::finishCreation):
237         * runtime/IntlObject.cpp:
238         (JSC::IntlObject::finishCreation): Deleted.
239         * runtime/IntlObject.h:
240         * runtime/Options.h:
241
242 2019-07-08  Antoine Quint  <graouts@apple.com>
243
244         [Pointer Events] Enable only on the most recent version of the supported iOS family
245         https://bugs.webkit.org/show_bug.cgi?id=199562
246         <rdar://problem/52766511>
247
248         Reviewed by Dean Jackson.
249
250         * Configurations/FeatureDefines.xcconfig:
251
252 2019-07-06  Michael Saboff  <msaboff@apple.com>
253
254         switch(String) needs to check for exceptions when resolving the string
255         https://bugs.webkit.org/show_bug.cgi?id=199541
256
257         Reviewed by Mark Lam.
258
259         Added exception checks for resolved Strings in switch processing for all tiers.
260
261         * dfg/DFGOperations.cpp:
262         * jit/JITOperations.cpp:
263         * llint/LLIntSlowPaths.cpp:
264         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
265
266 2019-07-05  Mark Lam  <mark.lam@apple.com>
267
268         ArgumentsEliminationPhase::eliminateCandidatesThatInterfere() should not decrement nodeIndex pass zero.
269         https://bugs.webkit.org/show_bug.cgi?id=199533
270         <rdar://problem/52669111>
271
272         Reviewed by Filip Pizlo.
273
274         * dfg/DFGArgumentsEliminationPhase.cpp:
275
276 2019-07-05  Yusuke Suzuki  <ysuzuki@apple.com>
277
278         Unreviewed, fix build failure on ARM64_32
279         https://bugs.webkit.org/show_bug.cgi?id=182434
280
281         Implicit narrowing from uint64_t to uint32_t happens. We should explicitly narrow it because we already checked
282         the `length` is <= UINT32_MAX.
283
284         * runtime/ArrayPrototype.cpp:
285         (JSC::arrayProtoFuncSpeciesCreate):
286
287 2019-07-05  Alexey Shvayka  <shvaikalesh@gmail.com>
288
289         [JSC] Clean up ArraySpeciesCreate
290         https://bugs.webkit.org/show_bug.cgi?id=182434
291
292         Reviewed by Yusuke Suzuki.
293
294         We have duplicate code in arraySpeciesCreate, filter, map, concatSlowPath of ArrayPrototype.js
295         and speciesConstructArray of ArrayPrototype.cpp. This patch fixes cross-realm Array constructor
296         detection in native speciesConstructArray, upgrades `length` type to correctly handle large integers,
297         and exposes it as @arraySpeciesCreate. Also removes now unused @isArrayConstructor private function.
298         Native speciesConstructArray is preferred because it has fast path via speciesWatchpointIsValid.
299
300         Thoroughly benchmarked: this change progresses ARES-6 by 0-1%.
301
302         * builtins/ArrayPrototype.js:
303         (filter):
304         (map):
305         (globalPrivate.concatSlowPath):
306         (globalPrivate.arraySpeciesCreate): Deleted.
307         * builtins/BuiltinNames.h:
308         * runtime/ArrayConstructor.cpp:
309         (JSC::arrayConstructorPrivateFuncIsArrayConstructor): Deleted.
310         * runtime/ArrayConstructor.h:
311         * runtime/ArrayPrototype.cpp:
312         (JSC::arrayProtoFuncSpeciesCreate):
313         * runtime/ArrayPrototype.h:
314         * runtime/JSGlobalObject.cpp:
315         (JSC::JSGlobalObject::init):
316
317 2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>
318
319         Unreviewed, change the value used to scribble Heap::m_worldState
320         https://bugs.webkit.org/show_bug.cgi?id=199498
321
322         Follow-up after r247160. The value used to scribble should have the
323         conn bit set.
324
325         * heap/Heap.cpp:
326         (JSC::Heap::~Heap):
327
328 2019-07-05  Ryan Haddad  <ryanhaddad@apple.com>
329
330         Unreviewed, rolling out r247115.
331
332         Breaks lldbWebKitTester (and by extension, test-webkitpy)
333
334         Reverted changeset:
335
336         "[WHLSL] Standard library is too big to directly include in
337         WebCore"
338         https://bugs.webkit.org/show_bug.cgi?id=198186
339         https://trac.webkit.org/changeset/247115
340
341 2019-07-05  Tadeu Zagallo  <tzagallo@apple.com>
342
343         Scribble Heap::m_worldState on destructor
344         https://bugs.webkit.org/show_bug.cgi?id=199498
345
346         Reviewed by Sam Weinig.
347
348         The worldState is dumped when we crash due to a failed checkConn, and
349         this will make it clear if the heap has already been destroyed.
350
351         * heap/Heap.cpp:
352         (JSC::Heap::~Heap):
353
354 2019-07-03  Sam Weinig  <weinig@apple.com>
355
356         Adopt simple structured bindings in more places
357         https://bugs.webkit.org/show_bug.cgi?id=199247
358
359         Reviewed by Alex Christensen.
360
361         Replaces simple uses of std::tie() with structured bindings. Does not touch
362         uses of std::tie() that are not initial declarations, use std::ignore or in
363         case where the binding is captured by a lambda, as structured bindings don't
364         work for those cases yet.
365
366         * runtime/PromiseDeferredTimer.cpp:
367         (JSC::PromiseDeferredTimer::doWork):
368         * wasm/WasmFaultSignalHandler.cpp:
369         (JSC::Wasm::trapHandler):
370         * wasm/js/JSWebAssemblyHelpers.h:
371         (JSC::createSourceBufferFromValue):
372         * wasm/js/WebAssemblyPrototype.cpp:
373         (JSC::webAssemblyValidateFunc):
374
375 2019-07-03  Keith Miller  <keith_miller@apple.com>
376
377         PACCage should first cage leaving PAC bits intact then authenticate
378         https://bugs.webkit.org/show_bug.cgi?id=199372
379
380         Reviewed by Saam Barati.
381
382         This ordering prevents someone from taking a signed pointer from
383         outside the gigacage and using it in a struct that expects a caged
384         pointer. Previously, the PACCaging just double checked that the PAC
385         bits were valid for the original pointer.
386
387
388                +---------------------------+
389                |       |        |          |
390                | "PAC" | "base" | "offset" +----+
391                |       |        |          |    |
392                +---------------------------+    | Caging
393                 |                               |
394                 |                               |
395                 |                               v
396                 |                +---------------------------+
397                 |                |       |        |          |
398                 | Bit Merge      | 00000 |  base  | "offset" |
399                 |                |       |        |          |
400                 |                +---------------------------+
401                 |                               |
402                 |                               |
403                 v                               |  Bit Merge
404           +---------------------------+         |
405           |       |        |          |         |
406           | "PAC" |  base  | "offset" +<--------+
407           |       |        |          |
408           +---------------------------+
409                       |
410                       |
411                       | Authenticate
412                       |
413                       v
414           +---------------------------+
415           |       |        |          |
416           | Auth  |  base  | "offset" |
417           |       |        |          |
418           +---------------------------+
419
420         The above ascii art graph shows how the PACCage system works. The
421         key take away is that even if someone passes in a valid, signed
422         pointer outside the cage it will still fail to authenticate as the
423         "base" bits will change before authentication.
424
425
426         * assembler/MacroAssemblerARM64E.h:
427         * assembler/testmasm.cpp:
428         (JSC::testCagePreservesPACFailureBit):
429         * ftl/FTLLowerDFGToB3.cpp:
430         (JSC::FTL::DFG::LowerDFGToB3::caged):
431         * jit/AssemblyHelpers.h:
432         (JSC::AssemblyHelpers::cageConditionally):
433         * llint/LowLevelInterpreter64.asm:
434
435 2019-07-03  Paulo Matos  <pmatos@igalia.com>
436
437         Refactoring of architectural Register Information
438         https://bugs.webkit.org/show_bug.cgi?id=198604
439
440         Reviewed by Keith Miller.
441
442         The goal of this patch is to centralize the register information per platform
443         but access it in a platform independent way. The patch as been implemented for all
444         known platforms: ARM64, ARMv7, MIPS, X86 and X86_64. Register information has
445         been centralized in an architecture per-file: each file is called assembler/<arch>Registers.h.
446
447         RegisterInfo.h is used as a forwarding header to choose which register information to load.
448         assembler/<arch>Assembler.h and jit/RegisterSet.cpp use this information in a platform
449         independent way.
450
451         * CMakeLists.txt:
452         * JavaScriptCore.xcodeproj/project.pbxproj:
453         * assembler/ARM64Assembler.h:
454         (JSC::ARM64Assembler::gprName): Use register names from register info file.
455         (JSC::ARM64Assembler::sprName): likewise.
456         (JSC::ARM64Assembler::fprName): likewise.
457         * assembler/ARM64Registers.h: Added.
458         * assembler/ARMv7Assembler.h:
459         (JSC::ARMv7Assembler::gprName): Use register names from register info file.
460         (JSC::ARMv7Assembler::sprName): likewise.
461         (JSC::ARMv7Assembler::fprName): likewise.
462         * assembler/ARMv7Registers.h: Added.
463         * assembler/MIPSAssembler.h:
464         (JSC::MIPSAssembler::gprName): Use register names from register info file.
465         (JSC::MIPSAssembler::sprName): likewise.
466         (JSC::MIPSAssembler::fprName): likewise.
467         * assembler/MIPSRegisters.h: Added.
468         * assembler/RegisterInfo.h: Added.
469         * assembler/X86Assembler.h:
470         (JSC::X86Assembler::gprName): Use register names from register info file.
471         (JSC::X86Assembler::sprName): likewise.
472         (JSC::X86Assembler::fprName): likewise.
473         * assembler/X86Registers.h: Added.
474         * assembler/X86_64Registers.h: Added.
475         * jit/GPRInfo.h: Fix typo in comment (s/basline/baseline).
476         * jit/RegisterSet.cpp:
477         (JSC::RegisterSet::reservedHardwareRegisters): Use register properties from register info file.
478         (JSC::RegisterSet::calleeSaveRegisters): likewise.
479
480 2019-07-02  Michael Saboff  <msaboff@apple.com>
481
482         Exception from For..of loop destructured assignment eliminates TDZ checks in subsequent code
483         https://bugs.webkit.org/show_bug.cgi?id=199395
484
485         Reviewed by Filip Pizlo.
486
487         For destructuring assignmests, the assignment might throw a reference error if
488         the RHS cannot be coerced.  The current bytecode generated for such assignments
489         optimizes out the TDZ check after the coercible check.
490
491         By saving the current state of the TDZ stack before processing the setting of 
492         target destructured values and then restoring afterwards, we won't optimize out
493         later TDZ check(s).
494
495         A similar change of saving / restoring the TDZ stack where exceptions might
496         happen was done for for..in loops in change set r232219.
497
498         * bytecompiler/NodesCodegen.cpp:
499         (JSC::ObjectPatternNode::bindValue const):
500
501 2019-07-02  Commit Queue  <commit-queue@webkit.org>
502
503         Unreviewed, rolling out r247041.
504         https://bugs.webkit.org/show_bug.cgi?id=199425
505
506         broke some iOS arm64e tests (Requested by keith_miller on
507         #webkit).
508
509         Reverted changeset:
510
511         "PACCage should first cage leaving PAC bits intact then
512         authenticate"
513         https://bugs.webkit.org/show_bug.cgi?id=199372
514         https://trac.webkit.org/changeset/247041
515
516 2019-07-02  Keith Miller  <keith_miller@apple.com>
517
518         Frozen Arrays length assignment should throw in strict mode
519         https://bugs.webkit.org/show_bug.cgi?id=199365
520
521         Reviewed by Yusuke Suzuki.
522
523         * runtime/JSArray.cpp:
524         (JSC::JSArray::put):
525
526 2019-07-02  Paulo Matos  <pmatos@linki.tools>
527
528         Fix typo in if/else block and remove dead assignment
529         https://bugs.webkit.org/show_bug.cgi?id=199352
530
531         Reviewed by Alexey Proskuryakov.
532
533         * yarr/YarrPattern.cpp:
534         (JSC::Yarr::YarrPattern::dumpPattern): Fix typo in if/else block and remove dead assignment
535
536 2019-07-02  Keith Miller  <keith_miller@apple.com>
537
538         PACCage should first cage leaving PAC bits intact then authenticate
539         https://bugs.webkit.org/show_bug.cgi?id=199372
540
541         Reviewed by Saam Barati.
542
543         This ordering prevents someone from taking a signed pointer from
544         outside the gigacage and using it in a struct that expects a caged
545         pointer. Previously, the PACCaging just double checked that the PAC
546         bits were valid for the original pointer.
547
548
549                +---------------------------+
550                |       |        |          |
551                | "PAC" | "base" | "offset" +----+
552                |       |        |          |    |
553                +---------------------------+    | Caging
554                 |                               |
555                 |                               |
556                 |                               v
557                 |                +---------------------------+
558                 |                |       |        |          |
559                 | Bit Merge      | 00000 |  base  | "offset" |
560                 |                |       |        |          |
561                 |                +---------------------------+
562                 |                               |
563                 |                               |
564                 v                               |  Bit Merge
565           +---------------------------+         |
566           |       |        |          |         |
567           | "PAC" |  base  | "offset" +<--------+
568           |       |        |          |
569           +---------------------------+
570                       |
571                       |
572                       | Authenticate
573                       |
574                       v
575           +---------------------------+
576           |       |        |          |
577           | Auth  |  base  | "offset" |
578           |       |        |          |
579           +---------------------------+
580
581         The above ascii art graph shows how the PACCage system works. The
582         key take away is that even if someone passes in a valid, signed
583         pointer outside the cage it will still fail to authenticate as the
584         "base" bits will change before authentication.
585
586
587         * assembler/MacroAssemblerARM64E.h:
588         * assembler/testmasm.cpp:
589         (JSC::testCagePreservesPACFailureBit):
590         * ftl/FTLLowerDFGToB3.cpp:
591         (JSC::FTL::DFG::LowerDFGToB3::caged):
592         * jit/AssemblyHelpers.h:
593         (JSC::AssemblyHelpers::cageConditionally):
594         * llint/LowLevelInterpreter64.asm:
595
596 2019-07-01  Justin Michaud  <justin_michaud@apple.com>
597
598         [Wasm-References] Disable references by default
599         https://bugs.webkit.org/show_bug.cgi?id=199390
600
601         Reviewed by Saam Barati.
602
603         * runtime/Options.h:
604
605 2019-07-01  Ryan Haddad  <ryanhaddad@apple.com>
606
607         Unreviewed, rolling out r246946.
608
609         Caused JSC test crashes on arm64
610
611         Reverted changeset:
612
613         "Add b3 macro lowering for CheckMul on arm64"
614         https://bugs.webkit.org/show_bug.cgi?id=199251
615         https://trac.webkit.org/changeset/246946
616
617 2019-06-28  Justin Michaud  <justin_michaud@apple.com>
618
619         Add b3 macro lowering for CheckMul on arm64
620         https://bugs.webkit.org/show_bug.cgi?id=199251
621
622         Reviewed by Robin Morisset.
623
624         - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check.
625         - Add a new opcode to air on arm64 for smull (multiplySignExtend32).
626         - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). 
627         - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, 
628           and no change on the no-constant benchmark.
629         Also, skip some of the b3 tests that were failing before this patch so that the new tests can run
630         to completion.
631
632         * assembler/MacroAssemblerARM64.h:
633         (JSC::MacroAssemblerARM64::multiplySignExtend32):
634         * assembler/testmasm.cpp:
635         (JSC::testMul32SignExtend):
636         (JSC::run):
637         * b3/B3LowerMacros.cpp:
638         * b3/B3LowerToAir.cpp:
639         * b3/air/AirOpcode.opcodes:
640         * b3/testb3.cpp:
641         (JSC::B3::testMulArgs32SignExtend):
642         (JSC::B3::testMulImm32SignExtend):
643         (JSC::B3::testMemoryFence):
644         (JSC::B3::testStoreFence):
645         (JSC::B3::testLoadFence):
646         (JSC::B3::testPinRegisters):
647         (JSC::B3::run):
648
649 2019-06-28  Konstantin Tokarev  <annulen@yandex.ru>
650
651         Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733
652         https://bugs.webkit.org/show_bug.cgi?id=199317
653
654         Reviewed by Michael Catanzaro.
655
656         While IconDatabase and all code using it was removed,
657         ENABLE_ICONDATABASE still exists as build option and C++ macro.
658
659         * Configurations/FeatureDefines.xcconfig:
660
661 2019-06-27  Mark Lam  <mark.lam@apple.com>
662
663         FTL keepAlive()'s patchpoint should also declare that it reads HeapRange::top().
664         https://bugs.webkit.org/show_bug.cgi?id=199291
665
666         Reviewed by Yusuke Suzuki and Filip Pizlo.
667
668         The sole purpose of keepAlive() is to communicate to B3 that an LValue
669         needs to be kept alive past the last opportunity for a GC.  The only way
670         we can get a GC is via a function call.  Hence, what keepAlive() really
671         needs to communicate is that the LValue needs to be kept alive past the
672         last function call.  Function calls read and write HeapRange::top().
673         Currently, B3 does not shuffle writes.  Hence, simply inserting the
674         keepAlive() after the calls that can GC is sufficient.
675
676         But to be strictly correct, keepAlive() should also declare that it reads
677         HeapRange::top().  This will guarantee that the keepAlive patchpoint won't
678         ever be moved before the function call should B3 gain the ability to shuffle
679         writes in the future.
680
681         * ftl/FTLLowerDFGToB3.cpp:
682         (JSC::FTL::DFG::LowerDFGToB3::keepAlive):
683
684 2019-06-27  Beth Dakin  <bdakin@apple.com>
685
686         Upstream use of MACCATALYST
687         https://bugs.webkit.org/show_bug.cgi?id=199245
688         rdar://problem/51687723
689
690         Reviewed by Tim Horton.
691
692         * Configurations/Base.xcconfig:
693         * Configurations/FeatureDefines.xcconfig:
694         * Configurations/JavaScriptCore.xcconfig:
695         * Configurations/SDKVariant.xcconfig:
696
697 2019-06-27  Saam Barati  <sbarati@apple.com>
698
699         Make WEBGPU enabled only on Mojave and later.
700
701         Rubber-stamped by Myles C. Maxfield.
702
703         * Configurations/FeatureDefines.xcconfig:
704
705 2019-06-27  Don Olmstead  <don.olmstead@sony.com>
706
707         [FTW] Build JavaScriptCore
708         https://bugs.webkit.org/show_bug.cgi?id=199254
709
710         Reviewed by Brent Fulgham.
711
712         * PlatformFTW.cmake: Added.
713
714 2019-06-27  Konstantin Tokarev  <annulen@yandex.ru>
715
716         Use JSC_GLIB_API_ENABLED instead of USE(GLIB) as a compile-time check for GLib JSC API
717         https://bugs.webkit.org/show_bug.cgi?id=199270
718
719         Reviewed by Michael Catanzaro.
720
721         This change allows building code with enabled USE(GLIB) but without
722         GLib JSC API.
723
724         * heap/Heap.cpp:
725         (JSC::Heap::releaseDelayedReleasedObjects):
726         * heap/Heap.h:
727         * heap/HeapInlines.h:
728
729 2019-06-27  Devin Rousso  <drousso@apple.com>
730
731         Web Inspector: throw an error if console.count/console.countReset is called with an object that throws an error from toString
732         https://bugs.webkit.org/show_bug.cgi?id=199252
733
734         Reviewed by Joseph Pecoraro.
735
736         Parse the arguments passed to `console.count` and `console.countReset` before sending it to
737         the `ConsoleClient` so that an error can be thrown if the first argument doesn't `toString`
738         nicely (e.g. without throwing an error).
739
740         Generate call stacks for `console.countReset` to match other `console` methods. Also do this
741         for `console.time`, `console.timeLog`, and `console.timeEnd`. Limit the call stack to only
742         have the top frame, so no unnecessary/extra data is sent to the frontend (right now, only
743         the call location is displayed).
744
745         Rename `title` to `label` for `console.time`, `console.timeLog`, and `console.timeEnd` to
746         better match the spec.
747
748         * runtime/ConsoleClient.h:
749         * runtime/ConsoleObject.cpp:
750         (JSC::valueOrDefaultLabelString):
751         (JSC::consoleProtoFuncCount):
752         (JSC::consoleProtoFuncCountReset):
753         (JSC::consoleProtoFuncTime):
754         (JSC::consoleProtoFuncTimeLog):
755         (JSC::consoleProtoFuncTimeEnd):
756
757         * inspector/JSGlobalObjectConsoleClient.h:
758         * inspector/JSGlobalObjectConsoleClient.cpp:
759         (Inspector::JSGlobalObjectConsoleClient::count):
760         (Inspector::JSGlobalObjectConsoleClient::countReset):
761         (Inspector::JSGlobalObjectConsoleClient::time):
762         (Inspector::JSGlobalObjectConsoleClient::timeLog):
763         (Inspector::JSGlobalObjectConsoleClient::timeEnd):
764
765         * inspector/agents/InspectorConsoleAgent.h:
766         * inspector/agents/InspectorConsoleAgent.cpp:
767         (Inspector::InspectorConsoleAgent::startTiming):
768         (Inspector::InspectorConsoleAgent::logTiming):
769         (Inspector::InspectorConsoleAgent::stopTiming):
770         (Inspector::InspectorConsoleAgent::count):
771         (Inspector::InspectorConsoleAgent::countReset):
772         (Inspector::InspectorConsoleAgent::getCounterLabel): Deleted.
773
774         * inspector/ConsoleMessage.h:
775         * inspector/ConsoleMessage.cpp:
776         (Inspector::ConsoleMessage::ConsoleMessage):
777         Allow `ConsoleMessage`s to be created with both `ScriptArguments` and a `ScriptCallStack`.
778
779 2019-06-27  Fujii Hironori  <Hironori.Fujii@sony.com>
780
781         [CMake] Bump cmake_minimum_required version to 3.10
782         https://bugs.webkit.org/show_bug.cgi?id=199181
783
784         Reviewed by Don Olmstead.
785
786         * CMakeLists.txt:
787
788 2019-06-26  Basuke Suzuki  <Basuke.Suzuki@sony.com>
789
790         [RemoteInspector] Add address argument to listen for RemoteInspectorServer Socket implementation.
791         https://bugs.webkit.org/show_bug.cgi?id=199035
792
793         Reviewed by Ross Kirsling.
794
795         Added new argument `address` to start listening. 
796
797         * inspector/remote/socket/RemoteInspectorServer.cpp:
798         (Inspector::RemoteInspectorServer::start):
799         * inspector/remote/socket/RemoteInspectorServer.h:
800         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
801         (Inspector::Socket::listen):
802         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp:
803         (Inspector::Socket::listen):
804
805 2019-06-26  Keith Miller  <keith_miller@apple.com>
806
807         speciesConstruct needs to throw if the result is a DataView
808         https://bugs.webkit.org/show_bug.cgi?id=199231
809
810         Reviewed by Mark Lam.
811
812         Previously, we only checked that the result was a
813         JSArrayBufferView, which can include DataViews. This is incorrect
814         as the result should be only be a TypedArray.
815
816         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
817         (JSC::speciesConstruct):
818
819 2019-06-26  Joseph Pecoraro  <pecoraro@apple.com>
820
821         Web Inspector: Implement console.countReset
822         https://bugs.webkit.org/show_bug.cgi?id=199200
823
824         Reviewed by Devin Rousso.
825
826         * inspector/JSGlobalObjectConsoleClient.cpp:
827         (Inspector::JSGlobalObjectConsoleClient::countReset):
828         * inspector/JSGlobalObjectConsoleClient.h:
829         * inspector/agents/InspectorConsoleAgent.cpp:
830         (Inspector::InspectorConsoleAgent::getCounterLabel):
831         (Inspector::InspectorConsoleAgent::count):
832         (Inspector::InspectorConsoleAgent::countReset):
833         * inspector/agents/InspectorConsoleAgent.h:
834         * runtime/ConsoleClient.h:
835         * runtime/ConsoleObject.cpp:
836         (JSC::ConsoleObject::finishCreation):
837         (JSC::consoleProtoFuncCountReset):
838
839 2019-06-26  Keith Miller  <keith_miller@apple.com>
840
841         remove unneeded didBecomePrototype() calls
842         https://bugs.webkit.org/show_bug.cgi?id=199221
843
844         Reviewed by Saam Barati.
845
846         Since we now set didBecomePrototype in Structure::create we don't
847         need to set it expliticly in most of our finishCreation
848         methods. The only exception to this is object prototype, which we
849         set as the prototype of function prototype late (via
850         setPrototypeWithoutTransition).
851
852         * inspector/JSInjectedScriptHostPrototype.cpp:
853         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
854         * inspector/JSJavaScriptCallFramePrototype.cpp:
855         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
856         * runtime/ArrayIteratorPrototype.cpp:
857         (JSC::ArrayIteratorPrototype::finishCreation):
858         * runtime/ArrayPrototype.cpp:
859         (JSC::ArrayPrototype::finishCreation):
860         * runtime/AsyncFromSyncIteratorPrototype.cpp:
861         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
862         * runtime/AsyncFunctionPrototype.cpp:
863         (JSC::AsyncFunctionPrototype::finishCreation):
864         * runtime/AsyncGeneratorFunctionPrototype.cpp:
865         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
866         * runtime/AsyncGeneratorPrototype.cpp:
867         (JSC::AsyncGeneratorPrototype::finishCreation):
868         * runtime/AsyncIteratorPrototype.cpp:
869         (JSC::AsyncIteratorPrototype::finishCreation):
870         * runtime/GeneratorFunctionPrototype.cpp:
871         (JSC::GeneratorFunctionPrototype::finishCreation):
872         * runtime/GeneratorPrototype.cpp:
873         (JSC::GeneratorPrototype::finishCreation):
874         * runtime/IteratorPrototype.cpp:
875         (JSC::IteratorPrototype::finishCreation):
876         * runtime/JSGlobalObject.cpp:
877         (JSC::JSGlobalObject::init):
878         * runtime/MapIteratorPrototype.cpp:
879         (JSC::MapIteratorPrototype::finishCreation):
880         * runtime/MapPrototype.cpp:
881         (JSC::MapPrototype::finishCreation):
882         * runtime/ObjectPrototype.cpp:
883         (JSC::ObjectPrototype::finishCreation):
884         * runtime/RegExpStringIteratorPrototype.cpp:
885         (JSC::RegExpStringIteratorPrototype::finishCreation):
886         * runtime/SetIteratorPrototype.cpp:
887         (JSC::SetIteratorPrototype::finishCreation):
888         * runtime/SetPrototype.cpp:
889         (JSC::SetPrototype::finishCreation):
890         * runtime/StringIteratorPrototype.cpp:
891         (JSC::StringIteratorPrototype::finishCreation):
892         * runtime/WeakMapPrototype.cpp:
893         (JSC::WeakMapPrototype::finishCreation):
894         * runtime/WeakObjectRefPrototype.cpp:
895         (JSC::WeakObjectRefPrototype::finishCreation):
896         * runtime/WeakSetPrototype.cpp:
897         (JSC::WeakSetPrototype::finishCreation):
898
899 2019-06-25  Keith Miller  <keith_miller@apple.com>
900
901         Structure::create should call didBecomePrototype()
902         https://bugs.webkit.org/show_bug.cgi?id=196315
903
904         Reviewed by Filip Pizlo.
905
906         Structure::create should also assert that the indexing type makes sense
907         for the prototype being used.
908
909         * runtime/JSObject.h:
910         * runtime/Structure.cpp:
911         (JSC::Structure::isValidPrototype):
912         (JSC::Structure::changePrototypeTransition):
913         * runtime/Structure.h:
914         (JSC::Structure::create): Deleted.
915         * runtime/StructureInlines.h:
916         (JSC::Structure::create):
917         (JSC::Structure::setPrototypeWithoutTransition):
918
919 2019-06-25  Joseph Pecoraro  <pecoraro@apple.com>
920
921         Web Inspector: Implement console.timeLog
922         https://bugs.webkit.org/show_bug.cgi?id=199184
923
924         Reviewed by Devin Rousso.
925
926         * inspector/JSGlobalObjectConsoleClient.cpp:
927         (Inspector::JSGlobalObjectConsoleClient::timeLog):
928         * inspector/JSGlobalObjectConsoleClient.h:
929         * inspector/agents/InspectorConsoleAgent.cpp:
930         (Inspector::InspectorConsoleAgent::logTiming):
931         (Inspector::InspectorConsoleAgent::stopTiming):
932         * inspector/agents/InspectorConsoleAgent.h:
933         * runtime/ConsoleClient.h:
934         * runtime/ConsoleObject.cpp:
935         (JSC::ConsoleObject::finishCreation):
936         (JSC::consoleProtoFuncTimeLog):
937
938 2019-06-25  Michael Catanzaro  <mcatanzaro@igalia.com>
939
940         REGRESSION(r245586): static assertion failed: Match result and EncodedMatchResult should be the same size
941         https://bugs.webkit.org/show_bug.cgi?id=198518
942
943         Reviewed by Keith Miller.
944
945         r245586 made some bad assumptions about the size of size_t, which we can solve using the
946         CPU(ADDRESS32) guard that I didn't know about.
947
948         This solution was developed by Mark Lam and Keith Miller. I'm just preparing the patch.
949
950         * runtime/MatchResult.h:
951
952 2019-06-24  Commit Queue  <commit-queue@webkit.org>
953
954         Unreviewed, rolling out r246714.
955         https://bugs.webkit.org/show_bug.cgi?id=199179
956
957         revert to do patch in a different way. (Requested by keith_mi_
958         on #webkit).
959
960         Reverted changeset:
961
962         "All prototypes should call didBecomePrototype()"
963         https://bugs.webkit.org/show_bug.cgi?id=196315
964         https://trac.webkit.org/changeset/246714
965
966 2019-06-24  Alexey Shvayka  <shvaikalesh@gmail.com>
967
968         Add Array.prototype.{flat,flatMap} to unscopables
969         https://bugs.webkit.org/show_bug.cgi?id=194322
970
971         Reviewed by Keith Miller.
972
973         * runtime/ArrayPrototype.cpp:
974         (JSC::ArrayPrototype::finishCreation):
975
976 2019-06-24  Mark Lam  <mark.lam@apple.com>
977
978         ArraySlice needs to keep the source array alive.
979         https://bugs.webkit.org/show_bug.cgi?id=197374
980         <rdar://problem/50304429>
981
982         Reviewed by Michael Saboff and Filip Pizlo.
983
984         The implementation of the FTL ArraySlice intrinsics may GC while allocating the
985         result array and its butterfly.  Previously, ArraySlice already keeps the source
986         butterfly alive in order to copy from it to the new butterfly after the allocation.
987         Unfortunately, this is not enough.  We also need to keep the source array alive
988         so that GC will scan the values in the butterfly as well.  Note: the butterfly
989         does not have a visitChildren() method to do this scan.  It's the parent object's
990         responsibility to do the scanning.
991
992         This patch fixes this by introducing a keepAlive() utility method, and we use it
993         to keep the source array alive while allocating the result array and butterfly.
994
995         keepAlive() works by using a patchpoint to communicate to B3 that a value (the
996         source array in this case) is still in use.  It also uses a fence to keep B3 from
997         relocating the patchpoint, which may defeat the fix.
998
999         For the DFG's SpeculativeJIT::compileArraySlice(), we may have lucked out and the
1000         source array cell is kept alive.  This patch makes it explicit that we should
1001         keep its cell alive till after the result array has been allocated.
1002
1003         For the Baseline JIT and LLInt, we use the arrayProtoFuncSlice() runtime function
1004         and there is no issue because the source array (in "thisObj") is in the element
1005         copying loop that follows the allocation of the result array.  However, for
1006         documentation purposes, this patch adds a call to HeapCell::use() to indicate that
1007         the source array need to kept alive at least until after the allocation of the
1008         result array.
1009
1010         * dfg/DFGSpeculativeJIT.cpp:
1011         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1012         * ftl/FTLLowerDFGToB3.cpp:
1013         (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
1014         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
1015         (JSC::FTL::DFG::LowerDFGToB3::keepAlive):
1016         * runtime/ArrayPrototype.cpp:
1017         (JSC::arrayProtoFuncSlice):
1018
1019 2019-06-22  Robin Morisset  <rmorisset@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>
1020
1021         All prototypes should call didBecomePrototype()
1022         https://bugs.webkit.org/show_bug.cgi?id=196315
1023
1024         Reviewed by Saam Barati.
1025
1026         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
1027
1028         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
1029         create structures with invalid prototypes.
1030         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
1031         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
1032
1033         * runtime/BigIntPrototype.cpp:
1034         (JSC::BigIntPrototype::finishCreation):
1035         * runtime/BooleanPrototype.cpp:
1036         (JSC::BooleanPrototype::finishCreation):
1037         * runtime/DatePrototype.cpp:
1038         (JSC::DatePrototype::finishCreation):
1039         * runtime/ErrorConstructor.cpp:
1040         (JSC::ErrorConstructor::finishCreation):
1041         * runtime/ErrorPrototype.cpp:
1042         (JSC::ErrorPrototype::finishCreation):
1043         * runtime/FunctionConstructor.cpp:
1044         (JSC::FunctionConstructor::finishCreation):
1045         * runtime/FunctionPrototype.cpp:
1046         (JSC::FunctionPrototype::finishCreation):
1047         * runtime/IntlCollatorPrototype.cpp:
1048         (JSC::IntlCollatorPrototype::finishCreation):
1049         * runtime/IntlDateTimeFormatPrototype.cpp:
1050         (JSC::IntlDateTimeFormatPrototype::finishCreation):
1051         * runtime/IntlNumberFormatPrototype.cpp:
1052         (JSC::IntlNumberFormatPrototype::finishCreation):
1053         * runtime/IntlPluralRulesPrototype.cpp:
1054         (JSC::IntlPluralRulesPrototype::finishCreation):
1055         * runtime/JSArrayBufferPrototype.cpp:
1056         (JSC::JSArrayBufferPrototype::finishCreation):
1057         * runtime/JSDataViewPrototype.cpp:
1058         (JSC::JSDataViewPrototype::finishCreation):
1059         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1060         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1061         * runtime/JSGlobalObject.cpp:
1062         (JSC::createConsoleProperty):
1063         * runtime/JSPromisePrototype.cpp:
1064         (JSC::JSPromisePrototype::finishCreation):
1065         * runtime/JSTypedArrayViewConstructor.cpp:
1066         (JSC::JSTypedArrayViewConstructor::finishCreation):
1067         * runtime/JSTypedArrayViewPrototype.cpp:
1068         (JSC::JSTypedArrayViewPrototype::finishCreation):
1069         * runtime/NumberPrototype.cpp:
1070         (JSC::NumberPrototype::finishCreation):
1071         * runtime/RegExpPrototype.cpp:
1072         (JSC::RegExpPrototype::finishCreation):
1073         * runtime/StringPrototype.cpp:
1074         (JSC::StringPrototype::finishCreation):
1075         * runtime/Structure.cpp:
1076         (JSC::Structure::isValidPrototype):
1077         (JSC::Structure::changePrototypeTransition):
1078         * runtime/Structure.h:
1079         * runtime/StructureInlines.h:
1080         (JSC::Structure::setPrototypeWithoutTransition):
1081         * runtime/SymbolPrototype.cpp:
1082         (JSC::SymbolPrototype::finishCreation):
1083         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
1084         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
1085         * wasm/js/WebAssemblyInstancePrototype.cpp:
1086         (JSC::WebAssemblyInstancePrototype::finishCreation):
1087         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
1088         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1089         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1090         (JSC::WebAssemblyMemoryPrototype::finishCreation):
1091         * wasm/js/WebAssemblyModulePrototype.cpp:
1092         (JSC::WebAssemblyModulePrototype::finishCreation):
1093         * wasm/js/WebAssemblyPrototype.cpp:
1094         (JSC::WebAssemblyPrototype::finishCreation):
1095         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
1096         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
1097         * wasm/js/WebAssemblyTablePrototype.cpp:
1098         (JSC::WebAssemblyTablePrototype::finishCreation):
1099
1100 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
1101
1102         [JSC] Strict, Sloppy and Arrow functions should have different classInfo
1103         https://bugs.webkit.org/show_bug.cgi?id=197631
1104
1105         Reviewed by Saam Barati.
1106
1107         If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class.
1108         This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we
1109         cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked
1110         by comparing classInfo of the cached structure and the given base structure. This implicitly assume that
1111         each builtin class's InternalFunction creates an instance based on one structure.
1112
1113         However, Function constructor is an exception: Function constructor creates an instance which has different
1114         structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function
1115         instance with strict function structure.
1116
1117         As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code.
1118
1119             class A extends Function { };
1120             let a = new A("'use strict'");
1121             let b = new A("");
1122
1123         While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given
1124         code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions
1125         because they have different properties. However, in the above case, a and b have the same structure while they have
1126         different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache.
1127
1128         In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design
1129         works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each
1130         structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the
1131         cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL
1132         optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization.
1133
1134         Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array
1135         structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile.
1136
1137         * runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that
1138         sizeof(JSAsyncFunction) == sizeof(JSFunction).
1139         * runtime/JSAsyncGeneratorFunction.cpp:
1140         * runtime/JSAsyncGeneratorFunction.h: Ditto.
1141         * runtime/JSFunction.cpp:
1142         * runtime/JSFunction.h:
1143         * runtime/JSGeneratorFunction.h: Ditto.
1144         * runtime/JSGlobalObject.cpp:
1145         (JSC::JSGlobalObject::init):
1146
1147 2019-06-22  Yusuke Suzuki  <ysuzuki@apple.com>
1148
1149         [JSC] ClassExpr should not store result in the middle of evaluation
1150         https://bugs.webkit.org/show_bug.cgi?id=199106
1151
1152         Reviewed by Tadeu Zagallo.
1153
1154         Let's consider the case,
1155
1156             let a = class A {
1157                 static get[a=0x12345678]() {
1158                 }
1159             };
1160
1161         When evaluating `class A` expression, we should not use the local register for `let a`
1162         until we finally store it to that register. Otherwise, `a=0x12345678` will override it.
1163         Out BytecodeGenerator does that this by using tempDestination and finalDestination, but
1164         we did not do that in ClassExprNode.
1165
1166         This patch leverages tempDestination and finalDestination to store `class A` result finally,
1167         while we attempt to reduce mov.
1168
1169         * bytecompiler/NodesCodegen.cpp:
1170         (JSC::ClassExprNode::emitBytecode):
1171
1172 2019-06-21  Sihui Liu  <sihui_liu@apple.com>
1173
1174         openDatabase should return an empty object when WebSQL is disabled
1175         https://bugs.webkit.org/show_bug.cgi?id=198805
1176
1177         Reviewed by Geoffrey Garen.
1178
1179         * runtime/JSFunction.cpp:
1180         (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined):
1181         * runtime/JSFunction.h:
1182
1183 2019-06-21  Alexey Shvayka  <shvaikalesh@gmail.com>
1184
1185         Remove extra check in RegExp @matchSlow
1186         https://bugs.webkit.org/show_bug.cgi?id=198846
1187
1188         Reviewed by Joseph Pecoraro.
1189
1190         Type of RegExp `exec` result is already asserted in @regExpExec.
1191
1192         * builtins/RegExpPrototype.js:
1193         (globalPrivate.matchSlow): Remove isObject check.
1194
1195 2019-06-20  Justin Michaud  <justin_michaud@apple.com>
1196
1197         [WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs
1198         https://bugs.webkit.org/show_bug.cgi?id=199044
1199
1200         Reviewed by Saam Barati.
1201
1202         Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index.
1203         Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs.
1204
1205         * wasm/WasmAirIRGenerator.cpp:
1206         (JSC::Wasm::AirIRGenerator::unify):
1207         * wasm/WasmSectionParser.cpp:
1208         (JSC::Wasm::SectionParser::parseElement):
1209         * wasm/WasmValidate.cpp:
1210         (JSC::Wasm::Validate::unify):
1211
1212 2019-06-18  Darin Adler  <darin@apple.com>
1213
1214         Tidy up the remaining bits of the AtomicString to AtomString rename
1215         https://bugs.webkit.org/show_bug.cgi?id=198990
1216
1217         Reviewed by Michael Catanzaro.
1218
1219         * dfg/DFGSpeculativeJIT.cpp:
1220         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom.
1221         * dfg/DFGSpeculativeJIT32_64.cpp:
1222         (JSC::DFG::SpeculativeJIT::compile): Ditto.
1223         * dfg/DFGSpeculativeJIT64.cpp:
1224         (JSC::DFG::SpeculativeJIT::compile): Ditto.
1225         * ftl/FTLLowerDFGToB3.cpp:
1226         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto.
1227         (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto.
1228
1229 2019-06-19  Alexey Shvayka  <shvaikalesh@gmail.com>
1230
1231         Optimize `resolve` method lookup in Promise static methods
1232         https://bugs.webkit.org/show_bug.cgi?id=198864
1233
1234         Reviewed by Yusuke Suzuki.
1235
1236         Lookup `resolve` method only once in Promise.{all,allSettled,race}.
1237         (https://github.com/tc39/ecma262/pull/1506)
1238
1239         Already implemented in V8.
1240
1241         * builtins/PromiseConstructor.js:
1242
1243 2019-06-19  Tadeu Zagallo  <tzagallo@apple.com>
1244
1245         Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs
1246         https://bugs.webkit.org/show_bug.cgi?id=199030
1247
1248         Reviewed by Mark Lam.
1249
1250         These assertions represent strong assumptions that the cache makes so
1251         it's not safe to keep executing if they fail.
1252
1253         * runtime/CachedTypes.cpp:
1254         (JSC::Encoder::malloc):
1255         (JSC::Encoder::Page::alignEnd):
1256         (JSC::Decoder::ptrForOffsetFromBase):
1257         (JSC::Decoder::handleForEnvironment const):
1258         (JSC::Decoder::setHandleForEnvironment):
1259         (JSC::CachedPtr::get const):
1260         (JSC::CachedOptional::encode):
1261         (JSC::CachedOptional::decodeAsPtr const): Deleted.
1262
1263 2019-06-19  Adrian Perez de Castro  <aperez@igalia.com>
1264
1265         [WPE][GTK] Fix build with unified sources disabled
1266         https://bugs.webkit.org/show_bug.cgi?id=198752
1267
1268         Reviewed by Michael Catanzaro.
1269
1270         * runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h
1271         and forward declaration of WeakObjectRefPrototype.
1272         * wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h
1273
1274 2019-06-19  Justin Michaud  <justin_michaud@apple.com>
1275
1276         [WASM-References] Rename anyfunc to funcref
1277         https://bugs.webkit.org/show_bug.cgi?id=198983
1278
1279         Reviewed by Yusuke Suzuki.
1280
1281         Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is 
1282         the only non-binary-format place where it is exposed to users.
1283
1284         * wasm/WasmAirIRGenerator.cpp:
1285         (JSC::Wasm::AirIRGenerator::gFuncref):
1286         (JSC::Wasm::AirIRGenerator::tmpForType):
1287         (JSC::Wasm::AirIRGenerator::emitCCall):
1288         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
1289         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1290         (JSC::Wasm::AirIRGenerator::addLocal):
1291         (JSC::Wasm::AirIRGenerator::addConstant):
1292         (JSC::Wasm::AirIRGenerator::addRefFunc):
1293         (JSC::Wasm::AirIRGenerator::addReturn):
1294         (JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted.
1295         * wasm/WasmCallingConvention.h:
1296         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1297         (JSC::Wasm::CallingConventionAir::setupCall const):
1298         * wasm/WasmExceptionType.h:
1299         * wasm/WasmFormat.h:
1300         (JSC::Wasm::isValueType):
1301         (JSC::Wasm::isSubtype):
1302         (JSC::Wasm::TableInformation::wasmType const):
1303         * wasm/WasmFunctionParser.h:
1304         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1305         * wasm/WasmSectionParser.cpp:
1306         (JSC::Wasm::SectionParser::parseTableHelper):
1307         (JSC::Wasm::SectionParser::parseElement):
1308         (JSC::Wasm::SectionParser::parseInitExpr):
1309         * wasm/WasmValidate.cpp:
1310         (JSC::Wasm::Validate::addRefFunc):
1311         * wasm/js/JSToWasm.cpp:
1312         (JSC::Wasm::createJSToWasmWrapper):
1313         * wasm/js/WasmToJS.cpp:
1314         (JSC::Wasm::wasmToJS):
1315         * wasm/js/WebAssemblyFunction.cpp:
1316         (JSC::callWebAssemblyFunction):
1317         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1318         * wasm/js/WebAssemblyModuleRecord.cpp:
1319         (JSC::WebAssemblyModuleRecord::link):
1320         * wasm/js/WebAssemblyTableConstructor.cpp:
1321         (JSC::constructJSWebAssemblyTable):
1322         * wasm/wasm.json:
1323
1324 2019-06-19  Fujii Hironori  <Hironori.Fujii@sony.com>
1325
1326         [CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects
1327         https://bugs.webkit.org/show_bug.cgi?id=198853
1328
1329         Reviewed by Don Olmstead.
1330
1331         JavaScriptCore_CopyPrivateHeaders target needs to have a direct or
1332         indirect dependency of JavaScriptCore target for CMake Visual
1333         Studio generator to eliminate duplicated custom commands.
1334
1335         * CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders.
1336
1337 2019-06-18  Yusuke Suzuki  <ysuzuki@apple.com>
1338
1339         [JSC] JSLock should be WebThread aware
1340         https://bugs.webkit.org/show_bug.cgi?id=198911
1341
1342         Reviewed by Geoffrey Garen.
1343
1344         Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs
1345         to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content.
1346         But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However,
1347         since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be
1348         modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs.
1349
1350         This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation,
1351         we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since
1352         JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore.
1353
1354         Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking.
1355         We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order.
1356
1357         In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released
1358         automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except
1359         for some edge cases.
1360
1361         * API/JSVirtualMachine.mm:
1362         (-[JSVirtualMachine isWebThreadAware]):
1363         * API/JSVirtualMachineInternal.h:
1364         * runtime/JSLock.cpp:
1365         (JSC::JSLockHolder::JSLockHolder):
1366         (JSC::JSLock::lock):
1367         (JSC::JSLockHolder::init): Deleted.
1368         * runtime/JSLock.h:
1369         (JSC::JSLock::makeWebThreadAware):
1370         (JSC::JSLock::isWebThreadAware const):
1371
1372 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
1373
1374         [WASM-References] Add support for Table.size, grow and fill instructions
1375         https://bugs.webkit.org/show_bug.cgi?id=198761
1376
1377         Reviewed by Yusuke Suzuki.
1378
1379         Add support for Table.size, grow and fill instructions. This also required
1380         adding support for two-byte opcodes to the ops generator.
1381
1382         * wasm/WasmAirIRGenerator.cpp:
1383         (JSC::Wasm::AirIRGenerator::gAnyref):
1384         (JSC::Wasm::AirIRGenerator::tmpForType):
1385         (JSC::Wasm::AirIRGenerator::addTableSize):
1386         (JSC::Wasm::AirIRGenerator::addTableGrow):
1387         (JSC::Wasm::AirIRGenerator::addTableFill):
1388         * wasm/WasmB3IRGenerator.cpp:
1389         (JSC::Wasm::B3IRGenerator::addTableSize):
1390         (JSC::Wasm::B3IRGenerator::addTableGrow):
1391         (JSC::Wasm::B3IRGenerator::addTableFill):
1392         * wasm/WasmExceptionType.h:
1393         * wasm/WasmFormat.h:
1394         (JSC::Wasm::TableInformation::wasmType const):
1395         * wasm/WasmFunctionParser.h:
1396         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1397         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1398         * wasm/WasmInstance.cpp:
1399         (JSC::Wasm::doWasmTableGrow):
1400         (JSC::Wasm::doWasmTableFill):
1401         * wasm/WasmInstance.h:
1402         * wasm/WasmTable.cpp:
1403         (JSC::Wasm::Table::grow):
1404         * wasm/WasmValidate.cpp:
1405         (JSC::Wasm::Validate::addTableSize):
1406         (JSC::Wasm::Validate::addTableGrow):
1407         (JSC::Wasm::Validate::addTableFill):
1408         * wasm/generateWasmOpsHeader.py:
1409         (opcodeMacroizer):
1410         (ExtTableOpType):
1411         * wasm/wasm.json:
1412
1413 2019-06-18  Keith Miller  <keith_miller@apple.com>
1414
1415         Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t.
1416
1417         * runtime/VM.h:
1418         (JSC::VM::currentWeakRefVersion const):
1419
1420 2019-06-18  Justin Michaud  <justin_michaud@apple.com>
1421
1422         [WASM-References] Add support for multiple tables
1423         https://bugs.webkit.org/show_bug.cgi?id=198760
1424
1425         Reviewed by Saam Barati.
1426
1427         Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the
1428         existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail
1429         to make it easier to use from jit code. 
1430
1431         * wasm/WasmAirIRGenerator.cpp:
1432         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1433         (JSC::Wasm::AirIRGenerator::addTableGet):
1434         (JSC::Wasm::AirIRGenerator::addTableSet):
1435         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1436         * wasm/WasmB3IRGenerator.cpp:
1437         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1438         (JSC::Wasm::B3IRGenerator::addTableGet):
1439         (JSC::Wasm::B3IRGenerator::addTableSet):
1440         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1441         * wasm/WasmExceptionType.h:
1442         * wasm/WasmFormat.h:
1443         (JSC::Wasm::Element::Element):
1444         * wasm/WasmFunctionParser.h:
1445         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1446         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1447         * wasm/WasmInstance.cpp:
1448         (JSC::Wasm::Instance::Instance):
1449         (JSC::Wasm::Instance::create):
1450         (JSC::Wasm::Instance::extraMemoryAllocated const):
1451         (JSC::Wasm::Instance::table):
1452         (JSC::Wasm::Instance::setTable):
1453         * wasm/WasmInstance.h:
1454         (JSC::Wasm::Instance::updateCachedMemory):
1455         (JSC::Wasm::Instance::offsetOfGlobals):
1456         (JSC::Wasm::Instance::offsetOfTablePtr):
1457         (JSC::Wasm::Instance::allocationSize):
1458         (JSC::Wasm::Instance::table): Deleted.
1459         (JSC::Wasm::Instance::setTable): Deleted.
1460         (JSC::Wasm::Instance::offsetOfTable): Deleted.
1461         * wasm/WasmModuleInformation.h:
1462         (JSC::Wasm::ModuleInformation::tableCount const):
1463         * wasm/WasmSectionParser.cpp:
1464         (JSC::Wasm::SectionParser::parseImport):
1465         (JSC::Wasm::SectionParser::parseTableHelper):
1466         (JSC::Wasm::SectionParser::parseTable):
1467         (JSC::Wasm::SectionParser::parseElement):
1468         * wasm/WasmTable.h:
1469         (JSC::Wasm::Table::owner const):
1470         * wasm/WasmValidate.cpp:
1471         (JSC::Wasm::Validate::addTableGet):
1472         (JSC::Wasm::Validate::addTableSet):
1473         (JSC::Wasm::Validate::addCallIndirect):
1474         * wasm/js/JSWebAssemblyInstance.cpp:
1475         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1476         (JSC::JSWebAssemblyInstance::visitChildren):
1477         * wasm/js/JSWebAssemblyInstance.h:
1478         * wasm/js/WebAssemblyModuleRecord.cpp:
1479         (JSC::WebAssemblyModuleRecord::link):
1480         (JSC::WebAssemblyModuleRecord::evaluate):
1481         * wasm/wasm.json:
1482
1483 2019-06-18  Alexey Shvayka  <shvaikalesh@gmail.com>
1484
1485         [ESNExt] String.prototype.matchAll
1486         https://bugs.webkit.org/show_bug.cgi?id=186694
1487
1488         Reviewed by Yusuke Suzuki.
1489
1490         Implement String.prototype.matchAll.
1491         (https://tc39.es/ecma262/#sec-string.prototype.matchall)
1492
1493         Also rename @globalPrivate @constructor functions and C++ variables holding them.
1494
1495         Shipping in Chrome since version 73.
1496         Shipping in Firefox since version 67.
1497
1498         * CMakeLists.txt:
1499         * DerivedSources-input.xcfilelist:
1500         * DerivedSources.make:
1501         * JavaScriptCore.xcodeproj/project.pbxproj:
1502         * Scripts/wkbuiltins/builtins_generate_combined_header.py:
1503         (get_var_name):
1504         (generate_section_for_global_private_code_name_macro):
1505         * Sources.txt:
1506         * builtins/ArrayPrototype.js:
1507         (globalPrivate.ArrayIterator):
1508         (values):
1509         (keys):
1510         (entries):
1511         (globalPrivate.createArrayIterator): Deleted.
1512         * builtins/AsyncFromSyncIteratorPrototype.js:
1513         (globalPrivate.createAsyncFromSyncIterator):
1514         (globalPrivate.AsyncFromSyncIterator):
1515         (globalPrivate.AsyncFromSyncIteratorConstructor): Deleted.
1516         * builtins/BuiltinNames.h:
1517         * builtins/MapPrototype.js:
1518         (globalPrivate.MapIterator):
1519         (values):
1520         (keys):
1521         (entries):
1522         (globalPrivate.createMapIterator): Deleted.
1523         * builtins/RegExpPrototype.js:
1524         (globalPrivate.RegExpStringIterator):
1525         (overriddenName.string_appeared_here.matchAll):
1526         * builtins/RegExpStringIteratorPrototype.js: Added.
1527         (next):
1528         * builtins/SetPrototype.js:
1529         (globalPrivate.SetIterator):
1530         (values):
1531         (entries):
1532         (globalPrivate.createSetIterator): Deleted.
1533         * builtins/StringPrototype.js:
1534         (matchAll):
1535         * builtins/TypedArrayPrototype.js:
1536         (values):
1537         (keys):
1538         (entries):
1539         * runtime/CommonIdentifiers.h:
1540         * runtime/JSGlobalObject.cpp:
1541         (JSC::JSGlobalObject::init):
1542         * runtime/RegExpPrototype.cpp:
1543         (JSC::RegExpPrototype::finishCreation):
1544         * runtime/RegExpStringIteratorPrototype.cpp: Added.
1545         (JSC::RegExpStringIteratorPrototype::finishCreation):
1546         * runtime/RegExpStringIteratorPrototype.h: Added.
1547         * runtime/StringPrototype.cpp:
1548
1549 2019-06-18  Keith Miller  <keith_miller@apple.com>
1550
1551         Add support for WeakRef
1552         https://bugs.webkit.org/show_bug.cgi?id=198710
1553
1554         Reviewed by Yusuke Suzuki.
1555
1556         Add support for WeakRefs which are now at stage 3
1557         (https://tc39.es/proposal-weakrefs). This patch doesn't add
1558         support for FinalizationGroups, which I'll add in another patch.
1559
1560         Some other things of interest. Per the spec, we cannot collect a
1561         weak refs target unless it has not been dereffed (or created) in
1562         the current microtask turn. i.e. WeakRefs are only allowed to be
1563         collected at the end of a drain of the Microtask queue. My
1564         understanding for this behavior is to reduce implementation
1565         dependence on specific GC behavior in a given browser.
1566
1567         We track if a WeakRef is retaining its target by using a version
1568         number on each WeakRef as well as on the VM. Whenever a WeakRef is
1569         derefed we update its version number to match the VM's then
1570         WriteBarrier ourselves. During marking if the VM and the WeakRef
1571         have the same version number, the target is visited.
1572
1573         * JavaScriptCore.xcodeproj/project.pbxproj:
1574         * Sources.txt:
1575         * heap/Heap.cpp:
1576         (JSC::Heap::finalizeUnconditionalFinalizers):
1577         * jsc.cpp:
1578         (GlobalObject::finishCreation):
1579         (functionReleaseWeakRefs):
1580         * runtime/CommonIdentifiers.h:
1581         * runtime/JSGlobalObject.cpp:
1582         * runtime/JSGlobalObject.h:
1583         * runtime/JSWeakObjectRef.cpp: Added.
1584         (JSC::JSWeakObjectRef::finishCreation):
1585         (JSC::JSWeakObjectRef::visitChildren):
1586         (JSC::JSWeakObjectRef::finalizeUnconditionally):
1587         (JSC::JSWeakObjectRef::toStringName):
1588         * runtime/JSWeakObjectRef.h: Added.
1589         * runtime/VM.cpp:
1590         (JSC::VM::drainMicrotasks):
1591         * runtime/VM.h:
1592         (JSC::VM::setOnEachMicrotaskTick):
1593         (JSC::VM::finalizeSynchronousJSExecution):
1594         (JSC::VM::currentWeakRefVersion const):
1595         * runtime/WeakObjectRefConstructor.cpp: Added.
1596         (JSC::WeakObjectRefConstructor::finishCreation):
1597         (JSC::WeakObjectRefConstructor::WeakObjectRefConstructor):
1598         (JSC::callWeakRef):
1599         (JSC::constructWeakRef):
1600         * runtime/WeakObjectRefConstructor.h: Added.
1601         (JSC::WeakObjectRefConstructor::create):
1602         (JSC::WeakObjectRefConstructor::createStructure):
1603         * runtime/WeakObjectRefPrototype.cpp: Added.
1604         (JSC::WeakObjectRefPrototype::finishCreation):
1605         (JSC::getWeakRef):
1606         (JSC::protoFuncWeakRefDeref):
1607         * runtime/WeakObjectRefPrototype.h: Added.
1608
1609 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
1610
1611         Add missing mutator fence in compileNewFunction
1612         https://bugs.webkit.org/show_bug.cgi?id=198849
1613         <rdar://problem/51733890>
1614
1615         Reviewed by Saam Barati.
1616
1617         Follow-up after r246553. Saam pointed out that we still need a mutator
1618         fence before allocating the FunctionRareData, since the allocation
1619         might trigger a slow path call.
1620
1621         * dfg/DFGSpeculativeJIT.cpp:
1622         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1623         * ftl/FTLLowerDFGToB3.cpp:
1624         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1625
1626 2019-06-18  Tadeu Zagallo  <tzagallo@apple.com>
1627
1628         DFG code should not reify the names of builtin functions with private names
1629         https://bugs.webkit.org/show_bug.cgi?id=198849
1630         <rdar://problem/51733890>
1631
1632         Reviewed by Filip Pizlo.
1633
1634         Builtin functions that have a private name call setHasReifiedName from finishCreation.
1635         When compiled with DFG and FTL, that does not get called and the function ends up reifying
1636         its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to
1637         true from compileNewFunction in both DFG and FTL.
1638
1639         * bytecode/InternalFunctionAllocationProfile.h:
1640         (JSC::InternalFunctionAllocationProfile::offsetOfStructure):
1641         * bytecode/ObjectAllocationProfile.h:
1642         (JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype):
1643         * bytecode/UnlinkedFunctionExecutable.h:
1644         * dfg/DFGSpeculativeJIT.cpp:
1645         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
1646         * ftl/FTLAbstractHeapRepository.h:
1647         * ftl/FTLLowerDFGToB3.cpp:
1648         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1649         * runtime/FunctionExecutable.h:
1650         * runtime/FunctionRareData.h:
1651         * runtime/JSFunction.cpp:
1652         (JSC::JSFunction::finishCreation):
1653         * runtime/JSFunction.h:
1654         * runtime/JSFunctionInlines.h:
1655         (JSC::JSFunction::isAnonymousBuiltinFunction const):
1656
1657 2019-06-18  Keith Miller  <keith_miller@apple.com>
1658
1659         MaybeParseAsGeneratorForScope sometimes loses track of its scope ref
1660         https://bugs.webkit.org/show_bug.cgi?id=198969
1661         <rdar://problem/51620714>
1662
1663         Reviewed by Tadeu Zagallo.
1664
1665         Sometimes if the parser has enough nested scopes
1666         MaybeParseAsGeneratorForScope can lose track of the ScopeRef it
1667         should be tracking. This is because the parser sometimes relocates
1668         its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should
1669         hold the scope ref it's watching.
1670
1671         * parser/Parser.cpp:
1672         (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope):
1673         (JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope):
1674
1675 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
1676
1677         Validate that table element type is funcref if using an element section
1678         https://bugs.webkit.org/show_bug.cgi?id=198910
1679
1680         Reviewed by Yusuke Suzuki.
1681
1682         Add missing validation when attempting to add an element section to an anyref table.
1683
1684         * wasm/WasmSectionParser.cpp:
1685         (JSC::Wasm::SectionParser::parseElement):
1686
1687 2019-06-17  Tadeu Zagallo  <tzagallo@apple.com>
1688
1689         Concurrent GC should check the conn before starting a new collection cycle
1690         https://bugs.webkit.org/show_bug.cgi?id=198913
1691         <rdar://problem/49515149>
1692
1693         Reviewed by Filip Pizlo.
1694
1695         Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector
1696         thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections
1697         and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent
1698         GC has finished processing the last pending request. The collector thread will runEndPhase and immediately
1699         start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in
1700         the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn,
1701         since the collector is running but doesn't have the conn anymore.
1702
1703         To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator
1704         has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem
1705         trivial to determine.
1706
1707         * heap/Heap.cpp:
1708         (JSC::Heap::runNotRunningPhase):
1709
1710 2019-06-17  Yusuke Suzuki  <ysuzuki@apple.com>
1711
1712         [JSC] Introduce DisposableCallSiteIndex to enforce type-safety
1713         https://bugs.webkit.org/show_bug.cgi?id=197378
1714
1715         Reviewed by Saam Barati.
1716
1717         Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time).
1718         The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex,
1719         we will create a new CallSiteIndex continuously and leak memory.
1720
1721         The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients.
1722         But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex
1723         at runtime.
1724
1725         To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and
1726         enforce type-safety to some degree.
1727
1728         We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex.
1729
1730         * bytecode/CodeBlock.cpp:
1731         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
1732         (JSC::CodeBlock::removeExceptionHandlerForCallSite):
1733         * bytecode/CodeBlock.h:
1734         * bytecode/PolymorphicAccess.cpp:
1735         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
1736         (JSC::PolymorphicAccess::regenerate):
1737         * bytecode/PolymorphicAccess.h:
1738         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted.
1739         * dfg/DFGCommonData.cpp:
1740         (JSC::DFG::CommonData::addUniqueCallSiteIndex):
1741         (JSC::DFG::CommonData::addDisposableCallSiteIndex):
1742         (JSC::DFG::CommonData::removeDisposableCallSiteIndex):
1743         (JSC::DFG::CommonData::removeCallSiteIndex): Deleted.
1744         * dfg/DFGCommonData.h:
1745         * interpreter/CallFrame.h:
1746         (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex):
1747         (JSC::DisposableCallSiteIndex::fromCallSiteIndex):
1748         * jit/GCAwareJITStubRoutine.cpp:
1749         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
1750         (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
1751         (JSC::createJITStubRoutine):
1752         * jit/GCAwareJITStubRoutine.h:
1753         * jit/JITInlineCacheGenerator.h:
1754
1755 2019-06-17  Justin Michaud  <justin_michaud@apple.com>
1756
1757         [WASM-References] Add support for Funcref in parameters and return types
1758         https://bugs.webkit.org/show_bug.cgi?id=198157
1759
1760         Reviewed by Yusuke Suzuki.
1761
1762         Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to 
1763         a funcref (nee anyfunc), we first make sure it is an exported wasm function or null. 
1764
1765         We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper
1766         for it so that we never need to construct JSValues when handling references. This should make threads
1767         easier to implement.
1768
1769         Finally, we add some missing bounds checks for table.get/set.
1770
1771         * wasm/WasmAirIRGenerator.cpp:
1772         (JSC::Wasm::AirIRGenerator::tmpForType):
1773         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
1774         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1775         (JSC::Wasm::AirIRGenerator::addLocal):
1776         (JSC::Wasm::AirIRGenerator::addConstant):
1777         (JSC::Wasm::AirIRGenerator::addRefFunc):
1778         (JSC::Wasm::AirIRGenerator::addTableSet):
1779         (JSC::Wasm::AirIRGenerator::setGlobal):
1780         (JSC::Wasm::AirIRGenerator::addReturn):
1781         * wasm/WasmB3IRGenerator.cpp:
1782         (JSC::Wasm::B3IRGenerator::addLocal):
1783         (JSC::Wasm::B3IRGenerator::addTableSet):
1784         (JSC::Wasm::B3IRGenerator::addRefFunc):
1785         (JSC::Wasm::B3IRGenerator::setGlobal):
1786         * wasm/WasmBBQPlan.cpp:
1787         (JSC::Wasm::BBQPlan::compileFunctions):
1788         * wasm/WasmCallingConvention.h:
1789         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1790         (JSC::Wasm::CallingConventionAir::setupCall const):
1791         * wasm/WasmExceptionType.h:
1792         * wasm/WasmFormat.h:
1793         (JSC::Wasm::isValueType):
1794         (JSC::Wasm::isSubtype):
1795         * wasm/WasmFunctionParser.h:
1796         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1797         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1798         * wasm/WasmInstance.cpp:
1799         (JSC::Wasm::Instance::Instance):
1800         (JSC::Wasm::Instance::getFunctionWrapper const):
1801         (JSC::Wasm::Instance::setFunctionWrapper):
1802         * wasm/WasmInstance.h:
1803         * wasm/WasmModuleInformation.h:
1804         (JSC::Wasm::ModuleInformation::referencedFunctions const):
1805         (JSC::Wasm::ModuleInformation::addReferencedFunction const):
1806         * wasm/WasmSectionParser.cpp:
1807         (JSC::Wasm::SectionParser::parseGlobal):
1808         (JSC::Wasm::SectionParser::parseInitExpr):
1809         * wasm/WasmValidate.cpp:
1810         (JSC::Wasm::Validate::addTableGet):
1811         (JSC::Wasm::Validate::addTableSet):
1812         (JSC::Wasm::Validate::addRefIsNull):
1813         (JSC::Wasm::Validate::addRefFunc):
1814         (JSC::Wasm::Validate::setLocal):
1815         (JSC::Wasm::Validate::addCall):
1816         (JSC::Wasm::Validate::addCallIndirect):
1817         * wasm/js/JSToWasm.cpp:
1818         (JSC::Wasm::createJSToWasmWrapper):
1819         * wasm/js/JSWebAssemblyHelpers.h:
1820         (JSC::isWebAssemblyHostFunction):
1821         * wasm/js/JSWebAssemblyInstance.cpp:
1822         (JSC::JSWebAssemblyInstance::visitChildren):
1823         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1824         (JSC::createJSWebAssemblyRuntimeError):
1825         * wasm/js/JSWebAssemblyRuntimeError.h:
1826         * wasm/js/WasmToJS.cpp:
1827         (JSC::Wasm::handleBadI64Use):
1828         (JSC::Wasm::wasmToJS):
1829         (JSC::Wasm::emitWasmToJSException):
1830         * wasm/js/WasmToJS.h:
1831         * wasm/js/WebAssemblyFunction.cpp:
1832         (JSC::callWebAssemblyFunction):
1833         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1834         * wasm/js/WebAssemblyModuleRecord.cpp:
1835         (JSC::WebAssemblyModuleRecord::link):
1836         * wasm/wasm.json:
1837
1838 2019-06-16  Darin Adler  <darin@apple.com>
1839
1840         Rename AtomicString to AtomString
1841         https://bugs.webkit.org/show_bug.cgi?id=195276
1842
1843         Reviewed by Michael Catanzaro.
1844
1845         * many files: Let do-webcore-rename do the renaming.
1846
1847 2019-06-16  Yusuke Suzuki  <ysuzuki@apple.com>
1848
1849         [JSC] Grown region of WasmTable should be initialized with null
1850         https://bugs.webkit.org/show_bug.cgi?id=198903
1851
1852         Reviewed by Saam Barati.
1853
1854         Grown region of Wasmtable is now empty. We should initialize it with null.
1855         We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to
1856         align to the naming convention.
1857
1858         * wasm/WasmTable.cpp:
1859         (JSC::Wasm::Table::grow):
1860         (JSC::Wasm::Table::visitAggregate):
1861         (JSC::Wasm::Table::visitChildren): Deleted.
1862         * wasm/WasmTable.h:
1863         * wasm/js/JSWebAssemblyTable.cpp:
1864         (JSC::JSWebAssemblyTable::visitChildren):
1865
1866 2019-06-14  Keith Miller  <keith_miller@apple.com>
1867
1868         Restore PAC based cage.
1869         https://bugs.webkit.org/show_bug.cgi?id=198872
1870
1871         Rubber-stamped by Saam Barati.
1872
1873         * assembler/MacroAssemblerARM64.h:
1874         (JSC::MacroAssemblerARM64::bitFieldInsert64):
1875         * assembler/MacroAssemblerARM64E.h:
1876         * assembler/testmasm.cpp:
1877         (JSC::testCagePreservesPACFailureBit):
1878         (JSC::run):
1879         * dfg/DFGSpeculativeJIT.cpp:
1880         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
1881         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
1882         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1883         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
1884         * ftl/FTLLowerDFGToB3.cpp:
1885         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1886         (JSC::FTL::DFG::LowerDFGToB3::caged):
1887         * jit/AssemblyHelpers.h:
1888         (JSC::AssemblyHelpers::cageWithoutUntagging):
1889         (JSC::AssemblyHelpers::cageConditionally):
1890         (JSC::AssemblyHelpers::cage): Deleted.
1891         * jit/JITPropertyAccess.cpp:
1892         (JSC::JIT::emitIntTypedArrayGetByVal):
1893         (JSC::JIT::emitFloatTypedArrayGetByVal):
1894         (JSC::JIT::emitIntTypedArrayPutByVal):
1895         (JSC::JIT::emitFloatTypedArrayPutByVal):
1896         * llint/LowLevelInterpreter.asm:
1897         * llint/LowLevelInterpreter64.asm:
1898         * offlineasm/arm64.rb:
1899         * offlineasm/instructions.rb:
1900         * offlineasm/registers.rb:
1901         * wasm/WasmAirIRGenerator.cpp:
1902         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1903         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1904         * wasm/WasmB3IRGenerator.cpp:
1905         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1906         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1907         * wasm/WasmBinding.cpp:
1908         (JSC::Wasm::wasmToWasm):
1909         * wasm/js/JSToWasm.cpp:
1910         (JSC::Wasm::createJSToWasmWrapper):
1911         * wasm/js/WebAssemblyFunction.cpp:
1912         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1913
1914 2019-06-13  Yusuke Suzuki  <ysuzuki@apple.com>
1915
1916         Yarr bytecode compilation failure should be gracefully handled
1917         https://bugs.webkit.org/show_bug.cgi?id=198700
1918
1919         Reviewed by Michael Saboff.
1920
1921         Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail.
1922         We should gracefully handle this failure as a runtime error, as we did for parse errors in [1].
1923         We also harden Yarr's consumed character calculation by using Checked.
1924
1925         [1]: https://bugs.webkit.org/show_bug.cgi?id=185755
1926
1927         * inspector/ContentSearchUtilities.cpp:
1928         (Inspector::ContentSearchUtilities::findMagicComment):
1929         * runtime/RegExp.cpp:
1930         (JSC::RegExp::byteCodeCompileIfNecessary):
1931         (JSC::RegExp::compile):
1932         (JSC::RegExp::compileMatchOnly):
1933         * runtime/RegExpInlines.h:
1934         (JSC::RegExp::matchInline):
1935         * yarr/YarrErrorCode.cpp:
1936         (JSC::Yarr::errorMessage):
1937         (JSC::Yarr::errorToThrow):
1938         * yarr/YarrErrorCode.h:
1939         * yarr/YarrInterpreter.cpp:
1940         (JSC::Yarr::ByteCompiler::ByteCompiler):
1941         (JSC::Yarr::ByteCompiler::compile):
1942         (JSC::Yarr::ByteCompiler::atomCharacterClass):
1943         (JSC::Yarr::ByteCompiler::atomBackReference):
1944         (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin):
1945         (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin):
1946         (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin):
1947         (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin):
1948         (JSC::Yarr::ByteCompiler::popParenthesesStack):
1949         (JSC::Yarr::ByteCompiler::closeAlternative):
1950         (JSC::Yarr::ByteCompiler::closeBodyAlternative):
1951         (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction):
1952         (JSC::Yarr::ByteCompiler::alternativeDisjunction):
1953         (JSC::Yarr::ByteCompiler::emitDisjunction):
1954
1955 2019-06-12  Yusuke Suzuki  <ysuzuki@apple.com>
1956
1957         [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call
1958         https://bugs.webkit.org/show_bug.cgi?id=198770
1959
1960         Reviewed by Saam Barati.
1961
1962         Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls
1963         are the following.
1964
1965             if (callee == patchableCallee) {
1966                 restore callee saves for tail call
1967                 prepare for tail call
1968                 jump to the target function
1969             }
1970             restore callee saves for slow path
1971             call the slow path function
1972
1973         And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub
1974         patches the above `if` statement with the jump to the stub.
1975
1976             jump to the polymorphic call stub
1977
1978         This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result,
1979         "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is
1980         correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves.
1981         This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled
1982         in that path.
1983
1984         This patch does that skips after restoring callee saves.
1985
1986         * bytecode/CallLinkInfo.cpp:
1987         (JSC::CallLinkInfo::CallLinkInfo):
1988         * bytecode/CallLinkInfo.h:
1989         (JSC::CallLinkInfo::setUpCall):
1990         (JSC::CallLinkInfo::calleeGPR):
1991         (JSC::CallLinkInfo::setCalleeGPR): Deleted.
1992         * jit/Repatch.cpp:
1993         (JSC::revertCall):
1994         (JSC::linkVirtualFor):
1995         (JSC::linkPolymorphicCall):
1996         * jit/Repatch.h:
1997         * jit/ThunkGenerators.cpp:
1998         (JSC::virtualThunkFor):
1999
2000 2019-06-12  Commit Queue  <commit-queue@webkit.org>
2001
2002         Unreviewed, rolling out r246322.
2003         https://bugs.webkit.org/show_bug.cgi?id=198796
2004
2005         "It's a huge page load regression on iOS" (Requested by
2006         saamyjoon on #webkit).
2007
2008         Reverted changeset:
2009
2010         "Roll out PAC cage"
2011         https://bugs.webkit.org/show_bug.cgi?id=198726
2012         https://trac.webkit.org/changeset/246322
2013
2014 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
2015
2016         JSC should throw if proxy set returns falsish in strict mode context
2017         https://bugs.webkit.org/show_bug.cgi?id=177398
2018
2019         Reviewed by Yusuke Suzuki.
2020
2021         Throw TypeError exception if Proxy's `set` trap returns falsy value.
2022         (step 6.c of https://tc39.es/ecma262/#sec-putvalue)
2023
2024         * runtime/ProxyObject.cpp:
2025         (JSC::ProxyObject::performPut):
2026         (JSC::ProxyObject::put):
2027         (JSC::ProxyObject::putByIndexCommon):
2028         * runtime/ProxyObject.h:
2029
2030 2019-06-11  Alexey Shvayka  <shvaikalesh@gmail.com>
2031
2032         Error message for non-callable Proxy `construct` trap is misleading
2033         https://bugs.webkit.org/show_bug.cgi?id=198637
2034
2035         Reviewed by Saam Barati.
2036
2037         Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]].
2038
2039         * runtime/ProxyObject.cpp:
2040         (JSC::performProxyConstruct): Tweak error message.
2041
2042 2019-06-10  Tadeu Zagallo  <tzagallo@apple.com>
2043
2044         AI BitURShift's result should not be unsigned
2045         https://bugs.webkit.org/show_bug.cgi?id=198689
2046         <rdar://problem/51550063>
2047
2048         Reviewed by Saam Barati.
2049
2050         Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it.
2051         This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but
2052         get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber,
2053         all we have to do is store the result as a signed int32.
2054
2055         * dfg/DFGAbstractInterpreterInlines.h:
2056
2057 2019-06-11  Michael Catanzaro  <mcatanzaro@igalia.com>
2058
2059         Unreviewed build warning fixes
2060
2061         Silence -Wreturn-type warning
2062
2063         * wasm/WasmTable.cpp:
2064         (JSC::Wasm::Table::tryCreate):
2065
2066 2019-06-11  Saam Barati  <sbarati@apple.com>
2067
2068         Roll out PAC cage
2069         https://bugs.webkit.org/show_bug.cgi?id=198726
2070
2071         Reviewed by Keith Miller.
2072
2073         This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622.
2074         
2075         The resulting state we're in is we have Gigacage enabled on arm64.
2076         There is no more PAC caging.
2077
2078         We're doing this because there are performance issues with PAC caging
2079         that we haven't resolved yet.
2080
2081         * assembler/CPU.h:
2082         (JSC::isARM64E): Deleted.
2083         * assembler/MacroAssemblerARM64E.h:
2084         (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted.
2085         (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted.
2086         (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted.
2087         * b3/B3LowerToAir.cpp:
2088         * b3/B3PatchpointSpecial.cpp:
2089         (JSC::B3::PatchpointSpecial::admitsStack):
2090         * b3/B3StackmapSpecial.cpp:
2091         (JSC::B3::StackmapSpecial::forEachArgImpl):
2092         (JSC::B3::StackmapSpecial::isArgValidForRep):
2093         * b3/B3Validate.cpp:
2094         * b3/B3ValueRep.cpp:
2095         (JSC::B3::ValueRep::addUsedRegistersTo const):
2096         (JSC::B3::ValueRep::dump const):
2097         (WTF::printInternal):
2098         * b3/B3ValueRep.h:
2099         (JSC::B3::ValueRep::ValueRep):
2100         (JSC::B3::ValueRep::isReg const):
2101         * dfg/DFGOperations.cpp:
2102         (JSC::DFG::newTypedArrayWithSize):
2103         * dfg/DFGSpeculativeJIT.cpp:
2104         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
2105         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2106         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
2107         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2108         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2109         * dfg/DFGSpeculativeJIT.h:
2110         * dfg/DFGSpeculativeJIT64.cpp:
2111         (JSC::DFG::SpeculativeJIT::compile):
2112         * ftl/FTLLowerDFGToB3.cpp:
2113         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
2114         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
2115         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2116         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
2117         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
2118         (JSC::FTL::DFG::LowerDFGToB3::caged):
2119         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
2120         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted.
2121         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted.
2122         * heap/ConservativeRoots.cpp:
2123         (JSC::ConservativeRoots::genericAddPointer):
2124         * jit/AssemblyHelpers.h:
2125         (JSC::AssemblyHelpers::cageConditionally):
2126         * jit/IntrinsicEmitter.cpp:
2127         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2128         * jit/JITPropertyAccess.cpp:
2129         (JSC::JIT::emitDirectArgumentsGetByVal):
2130         (JSC::JIT::emitIntTypedArrayGetByVal):
2131         (JSC::JIT::emitFloatTypedArrayGetByVal):
2132         (JSC::JIT::emitIntTypedArrayPutByVal):
2133         (JSC::JIT::emitFloatTypedArrayPutByVal):
2134         * jit/PolymorphicCallStubRoutine.cpp:
2135         (JSC::PolymorphicCallNode::clearCallLinkInfo):
2136         * jit/RegisterSet.h:
2137         * llint/LowLevelInterpreter64.asm:
2138         * runtime/ArrayBuffer.cpp:
2139         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
2140         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
2141         (JSC::ArrayBufferContents::ArrayBufferContents):
2142         (JSC::ArrayBufferContents::destroy):
2143         (JSC::ArrayBufferContents::tryAllocate):
2144         (JSC::ArrayBufferContents::makeShared):
2145         (JSC::ArrayBufferContents::copyTo):
2146         * runtime/ArrayBuffer.h:
2147         (JSC::SharedArrayBufferContents::data const):
2148         (JSC::ArrayBufferContents::data const):
2149         (JSC::ArrayBuffer::data):
2150         (JSC::ArrayBuffer::data const):
2151         (JSC::ArrayBuffer::byteLength const):
2152         * runtime/ArrayBufferView.cpp:
2153         (JSC::ArrayBufferView::ArrayBufferView):
2154         * runtime/ArrayBufferView.h:
2155         (JSC::ArrayBufferView::baseAddress const):
2156         (JSC::ArrayBufferView::setRangeImpl):
2157         (JSC::ArrayBufferView::getRangeImpl):
2158         (JSC::ArrayBufferView::byteLength const): Deleted.
2159         * runtime/CachedTypes.cpp:
2160         (JSC::CachedScopedArgumentsTable::encode):
2161         (JSC::CachedScopedArgumentsTable::decode const):
2162         * runtime/CagedBarrierPtr.h:
2163         (JSC::CagedBarrierPtr::CagedBarrierPtr):
2164         (JSC::CagedBarrierPtr::set):
2165         (JSC::CagedBarrierPtr::get const):
2166         (JSC::CagedBarrierPtr::getMayBeNull const):
2167         (JSC::CagedBarrierPtr::operator== const):
2168         (JSC::CagedBarrierPtr::operator!= const):
2169         (JSC::CagedBarrierPtr::operator bool const):
2170         (JSC::CagedBarrierPtr::setWithoutBarrier):
2171         (JSC::CagedBarrierPtr::operator* const):
2172         (JSC::CagedBarrierPtr::operator-> const):
2173         (JSC::CagedBarrierPtr::operator[] const):
2174         (JSC::CagedBarrierPtr::getUnsafe const): Deleted.
2175         (JSC::CagedBarrierPtr::at const): Deleted.
2176         * runtime/DataView.cpp:
2177         (JSC::DataView::DataView):
2178         * runtime/DataView.h:
2179         (JSC::DataView::get):
2180         (JSC::DataView::set):
2181         * runtime/DirectArguments.cpp:
2182         (JSC::DirectArguments::visitChildren):
2183         (JSC::DirectArguments::overrideThings):
2184         (JSC::DirectArguments::unmapArgument):
2185         * runtime/DirectArguments.h:
2186         * runtime/GenericArguments.h:
2187         * runtime/GenericArgumentsInlines.h:
2188         (JSC::GenericArguments<Type>::visitChildren):
2189         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
2190         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
2191         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
2192         * runtime/GenericTypedArrayView.h:
2193         * runtime/GenericTypedArrayViewInlines.h:
2194         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
2195         * runtime/JSArrayBufferView.cpp:
2196         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2197         (JSC::JSArrayBufferView::JSArrayBufferView):
2198         (JSC::JSArrayBufferView::finalize):
2199         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
2200         * runtime/JSArrayBufferView.h:
2201         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2202         (JSC::JSArrayBufferView::isNeutered):
2203         (JSC::JSArrayBufferView::vector const):
2204         (JSC::JSArrayBufferView::hasVector const): Deleted.
2205         * runtime/JSGenericTypedArrayViewInlines.h:
2206         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
2207         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
2208         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2209         * runtime/Options.h:
2210         * runtime/ScopedArgumentsTable.cpp:
2211         (JSC::ScopedArgumentsTable::clone):
2212         (JSC::ScopedArgumentsTable::setLength):
2213         * runtime/ScopedArgumentsTable.h:
2214         * runtime/SymbolTable.h:
2215         * wasm/WasmAirIRGenerator.cpp:
2216         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2217         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2218         * wasm/WasmB3IRGenerator.cpp:
2219         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2220         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2221         * wasm/WasmBBQPlan.cpp:
2222         (JSC::Wasm::BBQPlan::complete):
2223         * wasm/WasmBinding.cpp:
2224         (JSC::Wasm::wasmToWasm):
2225         * wasm/WasmInstance.h:
2226         (JSC::Wasm::Instance::cachedMemory const):
2227         (JSC::Wasm::Instance::updateCachedMemory):
2228         * wasm/WasmMemory.cpp:
2229         (JSC::Wasm::Memory::Memory):
2230         (JSC::Wasm::Memory::~Memory):
2231         (JSC::Wasm::Memory::grow):
2232         (JSC::Wasm::Memory::dump const):
2233         * wasm/WasmMemory.h:
2234         (JSC::Wasm::Memory::memory const):
2235         * wasm/js/JSToWasm.cpp:
2236         (JSC::Wasm::createJSToWasmWrapper):
2237         * wasm/js/WebAssemblyFunction.cpp:
2238         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2239
2240 2019-06-10  Basuke Suzuki  <Basuke.Suzuki@sony.com>
2241
2242         [WinCairo] Remove build warning from RemoteInspector.
2243         https://bugs.webkit.org/show_bug.cgi?id=198724
2244
2245         Reviewed by Joseph Pecoraro.
2246
2247         In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation.
2248         This method is to be overwritten by sub classes so that parameter name is important
2249         so they are commented out rather than just removing from the definition.
2250
2251         * inspector/remote/RemoteInspector.h:
2252
2253 2019-06-10  Sam Weinig  <weinig@apple.com>
2254
2255         Remove Dashboard support
2256         https://bugs.webkit.org/show_bug.cgi?id=198615
2257
2258         Reviewed by Ryosuke Niwa.
2259
2260         * Configurations/FeatureDefines.xcconfig:
2261
2262 2019-06-10  Devin Rousso  <drousso@apple.com>
2263
2264         Web Automation: add notifications for when remote automation is enabled/disabled
2265         https://bugs.webkit.org/show_bug.cgi?id=198703
2266         <rdar://problem/50588975>
2267
2268         Reviewed by Timothy Hatcher.
2269
2270         * inspector/remote/RemoteInspectorConstants.h:
2271
2272 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2273
2274         Unreviewed, build fix for non-DFG configurations, part 2
2275         https://bugs.webkit.org/show_bug.cgi?id=198023
2276
2277         * bytecode/CodeBlock.cpp:
2278         (JSC::CodeBlock::finalizeUnconditionally):
2279
2280 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2281
2282         Unreviewed, build fix for non-DFG configurations
2283         https://bugs.webkit.org/show_bug.cgi?id=198023
2284
2285         * bytecode/CodeBlock.cpp:
2286         (JSC::CodeBlock::finalizeUnconditionally):
2287
2288 2019-06-10  Yusuke Suzuki  <ysuzuki@apple.com>
2289
2290         [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode
2291         https://bugs.webkit.org/show_bug.cgi?id=198023
2292
2293         Reviewed by Saam Barati.
2294
2295         While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications.
2296         When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable.
2297         And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge
2298         UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually
2299         be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have
2300         navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in
2301         web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will
2302         hit the uppermost of memory footprint. But until that, we increase our memory footprint.
2303
2304         However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any
2305         time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain.
2306         One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused.
2307         But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression.
2308
2309         But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never
2310         reuse these CodeCache since we do not have the navigation.
2311
2312         This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC
2313         cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a
2314         heuristic. In a super pathological case, it could increase memory footprint. Consider the following example.
2315
2316             UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1)
2317                                                                                                              ^
2318                                                                                                          CodeBlock(E1)
2319
2320         We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and
2321         we will create duplicate UnlinkedCodeBlock and instructions stream for D1.
2322
2323                                                                                                          UnlinkedCodeBlock(D1)
2324                                                                                                              ^
2325                                                                                                          CodeBlock(E1)
2326
2327             UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2)
2328
2329         But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do
2330         not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB).
2331         While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64,
2332         while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation.
2333         Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising.
2334
2335         If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode
2336         cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption
2337         will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK.
2338
2339         This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable ->
2340         UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed
2341         While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable ->
2342         UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held
2343         by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old.
2344         If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first
2345         heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying
2346         the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a
2347         good starting point.
2348
2349         Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times.
2350         It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0).
2351         If we want to get more memory reduction for the sake of performance, we could decrease this age limit.
2352
2353         Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves
2354         memory footprint of our target application from about 6.5 MB to about 5.9 MB.
2355
2356         * bytecode/CodeBlock.cpp:
2357         (JSC::CodeBlock::finalizeUnconditionally):
2358         * bytecode/CodeBlock.h:
2359         * bytecode/UnlinkedCodeBlock.cpp:
2360         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2361         (JSC::UnlinkedCodeBlock::visitChildren):
2362         * bytecode/UnlinkedCodeBlock.h:
2363         (JSC::UnlinkedCodeBlock::age const):
2364         (JSC::UnlinkedCodeBlock::resetAge):
2365         * bytecode/UnlinkedFunctionExecutable.cpp:
2366         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2367         (JSC::UnlinkedFunctionExecutable::visitChildren):
2368         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2369         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
2370         (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally):
2371         * bytecode/UnlinkedFunctionExecutable.h:
2372         * heap/Heap.cpp:
2373         (JSC::Heap::finalizeUnconditionalFinalizers):
2374         * runtime/CachedTypes.cpp:
2375         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2376         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2377         * runtime/CodeSpecializationKind.h:
2378         * runtime/Options.h:
2379         * runtime/VM.cpp:
2380         (JSC::VM::isInMiniMode): Deleted.
2381         * runtime/VM.h:
2382         (JSC::VM::isInMiniMode):
2383         (JSC::VM::useUnlinkedCodeBlockJettisoning):
2384
2385 2019-06-10  Timothy Hatcher  <timothy@apple.com>
2386
2387         Integrate dark mode support for iOS.
2388         https://bugs.webkit.org/show_bug.cgi?id=198687
2389         rdar://problem/51545643
2390
2391         Reviewed by Tim Horton.
2392
2393         * Configurations/FeatureDefines.xcconfig:
2394
2395 2019-06-10  Adrian Perez de Castro  <aperez@igalia.com>
2396
2397         [JSC] Linker fails when unified sources are not in use
2398         https://bugs.webkit.org/show_bug.cgi?id=198722
2399
2400         Reviewed by Keith Miller.
2401
2402         Added missing inclusions of headers in several files which make use of inline functions.
2403
2404         * b3/B3AtomicValue.cpp:
2405         * b3/B3BlockInsertionSet.cpp:
2406         * b3/B3FenceValue.cpp:
2407         * b3/B3LowerMacrosAfterOptimizations.cpp:
2408         * b3/B3PureCSE.cpp:
2409         * b3/B3StackmapValue.cpp:
2410         * b3/B3SwitchValue.cpp:
2411         * b3/B3UseCounts.cpp:
2412         * b3/B3VariableValue.cpp:
2413         * b3/B3WasmAddressValue.cpp:
2414         * b3/B3WasmBoundsCheckValue.cpp:
2415         * ftl/FTLCompile.cpp:
2416         * wasm/WasmSectionParser.cpp:
2417         * wasm/WasmTable.cpp:
2418         * wasm/WasmValidate.cpp:
2419
2420 2019-06-10  Keith Miller  <keith_miller@apple.com>
2421
2422         Make new Symbol/Promise API public
2423         https://bugs.webkit.org/show_bug.cgi?id=198709
2424
2425         Reviewed by Saam Barati.
2426
2427         We also need to #ifdef some tests when building for older
2428         platforms because the signatures for some methods are outdated on
2429         those platforms.
2430
2431         * API/JSObjectRef.h:
2432         * API/JSObjectRefPrivate.h:
2433         * API/JSValue.h:
2434         * API/JSValuePrivate.h:
2435         * API/JSValueRef.h:
2436         * API/tests/testapi.mm:
2437         (testObjectiveCAPIMain):
2438
2439 2019-06-09  Commit Queue  <commit-queue@webkit.org>
2440
2441         Unreviewed, rolling out r246150, r246160, and r246166.
2442         https://bugs.webkit.org/show_bug.cgi?id=198698
2443
2444         Regresses page loading time on iOS 13 (Requested by keith_m__
2445         on #webkit).
2446
2447         Reverted changesets:
2448
2449         "Reenable Gigacage on ARM64."
2450         https://bugs.webkit.org/show_bug.cgi?id=198453
2451         https://trac.webkit.org/changeset/246150
2452
2453         "Unrevied build fix for FTL without Gigacage."
2454         https://trac.webkit.org/changeset/246160
2455
2456         "Fix typo in cageWithoutUntagging"
2457         https://bugs.webkit.org/show_bug.cgi?id=198617
2458         https://trac.webkit.org/changeset/246166
2459
2460 2019-06-09  Yusuke Suzuki  <ysuzuki@apple.com>
2461
2462         [JSC] Use mergePrediction in ValuePow prediction propagation
2463         https://bugs.webkit.org/show_bug.cgi?id=198648
2464
2465         Reviewed by Saam Barati.
2466
2467         We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant)
2468         must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard
2469         previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead.
2470
2471         * dfg/DFGPredictionPropagationPhase.cpp:
2472
2473 2019-06-07  Tadeu Zagallo  <tzagallo@apple.com>
2474
2475         AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset
2476         https://bugs.webkit.org/show_bug.cgi?id=198581
2477         <rdar://problem/51099753>
2478
2479         Reviewed by Saam Barati.
2480
2481         For GetGetterSetterByOffset, when the abstract interpreter fails to read the property
2482         from the object, it gets the GetterSetter structure from the CodeBlock's global object.
2483         However, that's not correct, since the global object for the base object might differ
2484         from the CodeBlock's. Instead, we try to get the global object from the base, when it's
2485         a constant object. Otherwise, we can't infer the value and only set the type.
2486
2487         * dfg/DFGAbstractInterpreterInlines.h:
2488         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2489
2490 2019-06-06  Devin Rousso  <drousso@apple.com>
2491
2492         Web Inspector: create CommandLineAPIHost lazily like the other agents
2493         https://bugs.webkit.org/show_bug.cgi?id=196047
2494         <rdar://problem/49087835>
2495
2496         Reviewed by Timothy Hatcher.
2497
2498         * inspector/InjectedScriptManager.h:
2499         * inspector/InjectedScriptManager.cpp:
2500         (Inspector::InjectedScriptManager::connect): Added.
2501
2502 2019-06-06  Keith Miller  <keith_miller@apple.com>
2503
2504         Fix typo in cageWithoutUntagging
2505         https://bugs.webkit.org/show_bug.cgi?id=198617
2506
2507         Reviewed by Saam Barati.
2508
2509         * assembler/testmasm.cpp:
2510         (JSC::testCagePreservesPACFailureBit):
2511         * dfg/DFGSpeculativeJIT.cpp:
2512         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2513         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2514         * jit/AssemblyHelpers.h:
2515         (JSC::AssemblyHelpers::cageWithoutUntagging):
2516         (JSC::AssemblyHelpers::cageConditionally):
2517         (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted.
2518
2519 2019-06-06  Alexey Shvayka  <shvaikalesh@gmail.com>
2520
2521         JSON.parse throws incorrect exception when called w/o arguments
2522         https://bugs.webkit.org/show_bug.cgi?id=198574
2523
2524         Reviewed by Yusuke Suzuki.
2525
2526         Always coerce first argument to string and attempt to parse it.
2527         (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse)
2528
2529         * runtime/JSONObject.cpp:
2530         (JSC::JSONProtoFuncParse): Remove argumentCount check.
2531
2532 2019-06-06  Keith Miller  <keith_miller@apple.com>
2533
2534         Unrevied build fix for FTL without Gigacage.
2535
2536         * ftl/FTLLowerDFGToB3.cpp:
2537         (JSC::FTL::DFG::LowerDFGToB3::caged):
2538
2539 2019-06-06  Michael Catanzaro  <mcatanzaro@igalia.com>
2540
2541         aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’}
2542         https://bugs.webkit.org/show_bug.cgi?id=198014
2543
2544         Reviewed by Yusuke Suzuki.
2545
2546         When building for aarch64, there is a huge warning spam here. It's impossible to see any
2547         other warnings. This has been ongoing for so long I've begun to suspect that nobody works
2548         on this architecture.
2549
2550         Anyway, the problem is because we need eight bits to store all possible RegisterID values,
2551         but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this
2552         struct is still happy, so I presume the change is OK.
2553
2554         * assembler/ARM64Assembler.h:
2555
2556 2019-06-06  Keith Miller  <keith_miller@apple.com>
2557
2558         Reenable Gigacage on ARM64.
2559         https://bugs.webkit.org/show_bug.cgi?id=198453
2560
2561         Reviewed by Michael Saboff.
2562
2563         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
2564         old Gigacage however, arm64e uses both Gigacaging and PAC. In
2565         order to ensure the PAC bits are not stripped in the caging
2566         process we use the bit field insert instruction to take the low
2567         bits from caging and the high bits from the PAC authentication.
2568
2569         * assembler/MacroAssemblerARM64.h:
2570         (JSC::MacroAssemblerARM64::bitFieldInsert64):
2571         * assembler/MacroAssemblerARM64E.h:
2572         * assembler/testmasm.cpp:
2573         (JSC::testCagePreservesPACFailureBit):
2574         (JSC::run):
2575         * dfg/DFGSpeculativeJIT.cpp:
2576         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
2577         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2578         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2579         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2580         * ftl/FTLLowerDFGToB3.cpp:
2581         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2582         (JSC::FTL::DFG::LowerDFGToB3::caged):
2583         * jit/AssemblyHelpers.h:
2584         (JSC::AssemblyHelpers::cageWithoutUntaging):
2585         (JSC::AssemblyHelpers::cageConditionally):
2586         (JSC::AssemblyHelpers::cage): Deleted.
2587         * jit/JITPropertyAccess.cpp:
2588         (JSC::JIT::emitIntTypedArrayGetByVal):
2589         (JSC::JIT::emitFloatTypedArrayGetByVal):
2590         (JSC::JIT::emitIntTypedArrayPutByVal):
2591         (JSC::JIT::emitFloatTypedArrayPutByVal):
2592         * llint/LowLevelInterpreter.asm:
2593         * llint/LowLevelInterpreter64.asm:
2594         * offlineasm/arm64.rb:
2595         * offlineasm/instructions.rb:
2596         * offlineasm/registers.rb:
2597         * wasm/WasmAirIRGenerator.cpp:
2598         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2599         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2600         * wasm/WasmB3IRGenerator.cpp:
2601         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2602         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2603         * wasm/WasmBinding.cpp:
2604         (JSC::Wasm::wasmToWasm):
2605         * wasm/js/JSToWasm.cpp:
2606         (JSC::Wasm::createJSToWasmWrapper):
2607         * wasm/js/WebAssemblyFunction.cpp:
2608         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2609
2610 2019-06-06  Michael Saboff  <msaboff@apple.com>
2611
2612         [ARM64E]: Add disassembler support for authenticated instructions
2613         https://bugs.webkit.org/show_bug.cgi?id=198562
2614
2615         Reviewed by Keith Miller.
2616
2617         Added support for all the instructions supported in ARM64EAssembler.h.
2618
2619         * disassembler/ARM64/A64DOpcode.cpp:
2620         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
2621         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
2622         (JSC::ARM64Disassembler::A64DOpcodeHint::format):
2623         (JSC::ARM64Disassembler::A64DOpcodeHint::opName):
2624         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format):
2625         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName):
2626         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format):
2627         * disassembler/ARM64/A64DOpcode.h:
2628         (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex):
2629         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName):
2630         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum):
2631         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit):
2632         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit):
2633         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit):
2634         (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10):
2635         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode):
2636         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2):
2637         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3):
2638         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4):
2639         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit):
2640         (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm):
2641         (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted.
2642
2643 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
2644
2645         [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only).
2646         https://bugs.webkit.org/show_bug.cgi?id=198398
2647
2648         Reviewed by Saam Barati.
2649
2650         Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec).
2651         Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to
2652         support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because
2653         we need to write barrier it (so it should not restrict how we implement threads). This patch does, however,
2654         restrict the implementation of function references to require every Ref.func to have an associated wrapper. This
2655         can be done statically, so this too should not restrict our threads implementation. 
2656
2657         * wasm/WasmAirIRGenerator.cpp:
2658         (JSC::Wasm::AirIRGenerator::addTableGet):
2659         (JSC::Wasm::AirIRGenerator::addTableSet):
2660         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2661         * wasm/WasmB3IRGenerator.cpp:
2662         (JSC::Wasm::B3IRGenerator::addLocal):
2663         (JSC::Wasm::B3IRGenerator::addTableGet):
2664         (JSC::Wasm::B3IRGenerator::addTableSet):
2665         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2666         * wasm/WasmFormat.h:
2667         (JSC::Wasm::TableInformation::TableInformation):
2668         (JSC::Wasm::TableInformation::type const):
2669         * wasm/WasmFunctionParser.h:
2670         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2671         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
2672         * wasm/WasmSectionParser.cpp:
2673         (JSC::Wasm::SectionParser::parseTableHelper):
2674         * wasm/WasmTable.cpp:
2675         (JSC::Wasm::Table::Table):
2676         (JSC::Wasm::Table::tryCreate):
2677         (JSC::Wasm::Table::grow):
2678         (JSC::Wasm::Table::clear):
2679         (JSC::Wasm::Table::set):
2680         (JSC::Wasm::Table::get):
2681         (JSC::Wasm::Table::visitChildren):
2682         (JSC::Wasm::FuncRefTable::FuncRefTable):
2683         (JSC::Wasm::FuncRefTable::setFunction):
2684         (JSC::Wasm::Table::~Table): Deleted.
2685         (JSC::Wasm::Table::clearFunction): Deleted.
2686         (JSC::Wasm::Table::setFunction): Deleted.
2687         * wasm/WasmTable.h:
2688         (JSC::Wasm::Table::length const):
2689         (JSC::Wasm::Table::type const):
2690         (JSC::Wasm::Table::setOwner):
2691         (JSC::Wasm::FuncRefTable::offsetOfFunctions):
2692         (JSC::Wasm::FuncRefTable::offsetOfInstances):
2693         (JSC::Wasm::Table::offsetOfFunctions): Deleted.
2694         (JSC::Wasm::Table::offsetOfInstances): Deleted.
2695         * wasm/WasmValidate.cpp:
2696         (JSC::Wasm::Validate::addTableGet):
2697         (JSC::Wasm::Validate::addTableSet):
2698         (JSC::Wasm::Validate::addCallIndirect):
2699         * wasm/js/JSWebAssemblyTable.cpp:
2700         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
2701         (JSC::JSWebAssemblyTable::finishCreation):
2702         (JSC::JSWebAssemblyTable::visitChildren):
2703         (JSC::JSWebAssemblyTable::grow):
2704         (JSC::JSWebAssemblyTable::get):
2705         (JSC::JSWebAssemblyTable::set):
2706         (JSC::JSWebAssemblyTable::clear):
2707         (JSC::JSWebAssemblyTable::getFunction): Deleted.
2708         (JSC::JSWebAssemblyTable::clearFunction): Deleted.
2709         (JSC::JSWebAssemblyTable::setFunction): Deleted.
2710         * wasm/js/JSWebAssemblyTable.h:
2711         * wasm/js/WebAssemblyModuleRecord.cpp:
2712         (JSC::WebAssemblyModuleRecord::link):
2713         (JSC::WebAssemblyModuleRecord::evaluate):
2714         * wasm/js/WebAssemblyTableConstructor.cpp:
2715         (JSC::constructJSWebAssemblyTable):
2716         * wasm/js/WebAssemblyTablePrototype.cpp:
2717         (JSC::webAssemblyTableProtoFuncGet):
2718         (JSC::webAssemblyTableProtoFuncSet):
2719         * wasm/wasm.json:
2720
2721 2019-06-05  Justin Michaud  <justin_michaud@apple.com>
2722
2723         WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0
2724         https://bugs.webkit.org/show_bug.cgi?id=198106
2725
2726         Reviewed by Saam Barati.
2727
2728         Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32.
2729
2730         * assembler/MacroAssemblerARM64.h:
2731         (JSC::MacroAssemblerARM64::moveDoubleConditionally32):
2732
2733 2019-06-05  Alex Christensen  <achristensen@webkit.org>
2734
2735         Progress towards resurrecting Mac CMake build
2736         https://bugs.webkit.org/show_bug.cgi?id=197132
2737
2738         Reviewed by Don Olmstead.
2739
2740         * API/JSScript.mm:
2741         (-[JSScript readCache]):
2742         (-[JSScript sourceCode]):
2743         (-[JSScript jsSourceCode]):
2744         (-[JSScript writeCache:]):
2745         * CMakeLists.txt:
2746
2747 == Rolled over to ChangeLog-2019-06-05 ==