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