Enable new build rule for post-processing headers when using XCBuild
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-04-26  Keith Rollin  <krollin@apple.com>
2
3         Enable new build rule for post-processing headers when using XCBuild
4         https://bugs.webkit.org/show_bug.cgi?id=197340
5         <rdar://problem/50226685>
6
7         Reviewed by Brent Fulgham.
8
9         In Bug 197116, we conditionally disabled the old method for
10         post-processing header files when we are using the new XCBuild build
11         system. This check-in conditionally enables the new post-processing
12         facility. Note that the old system is disabled and the new system
13         enabled only when the USE_NEW_BUILD_SYSTEM environment variable is set
14         to YES.
15
16         * Configurations/JavaScriptCore.xcconfig:
17
18 2019-04-26  Jessie Berlin  <jberlin@webkit.org>
19
20         Add new mac target numbers
21         https://bugs.webkit.org/show_bug.cgi?id=197313
22
23         Reviewed by Alex Christensen.
24
25         * Configurations/Version.xcconfig:
26         * Configurations/WebKitTargetConditionals.xcconfig:
27
28 2019-04-26  Commit Queue  <commit-queue@webkit.org>
29
30         Unreviewed, rolling out r244708.
31         https://bugs.webkit.org/show_bug.cgi?id=197334
32
33         "Broke the debug build" (Requested by rmorisset on #webkit).
34
35         Reverted changeset:
36
37         "All prototypes should call didBecomePrototype()"
38         https://bugs.webkit.org/show_bug.cgi?id=196315
39         https://trac.webkit.org/changeset/244708
40
41 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
42
43         [CMake] Add WEBKIT_EXECUTABLE macro
44         https://bugs.webkit.org/show_bug.cgi?id=197206
45
46         Reviewed by Konstantin Tokarev.
47
48         Migrate to WEBKIT_EXECUTABLE for the jsc and test targets.
49
50         * b3/air/testair.cpp:
51         * b3/testb3.cpp:
52         * dfg/testdfg.cpp:
53         * shell/CMakeLists.txt:
54         * shell/PlatformGTK.cmake:
55         * shell/PlatformJSCOnly.cmake: Removed.
56         * shell/PlatformMac.cmake:
57         * shell/PlatformPlayStation.cmake:
58         * shell/PlatformWPE.cmake:
59         * shell/PlatformWin.cmake:
60
61 2019-04-25  Yusuke Suzuki  <ysuzuki@apple.com>
62
63         [JSC] linkPolymorphicCall now does GC
64         https://bugs.webkit.org/show_bug.cgi?id=197306
65
66         Reviewed by Saam Barati.
67
68         Previously, we assumed that linkPolymorphicCall does not perform allocations. So we put CallVariant into a Vector<>.
69         But now, WebAssemblyFunction's entrypoint generation can allocate JSToWasmICCallee and cause GC. Since CallLinkInfo
70         does not hold these cells, they can be collected, and we will see dead cells in the middle of linkPolymorphicCall.
71         We should defer GC for a while in linkPolymorphicCall. We use DeferGCForAWhile instead of DeferGC because the
72         caller "operationLinkPolymorphicCall" assumes that this function does not cause GC.
73
74         * jit/Repatch.cpp:
75         (JSC::linkPolymorphicCall):
76
77 2019-04-26  Robin Morisset  <rmorisset@apple.com>
78
79         All prototypes should call didBecomePrototype()
80         https://bugs.webkit.org/show_bug.cgi?id=196315
81
82         Reviewed by Saam Barati.
83
84         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
85
86         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
87         create structures with invalid prototypes.
88         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
89         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
90
91         * runtime/BigIntPrototype.cpp:
92         (JSC::BigIntPrototype::finishCreation):
93         * runtime/BooleanPrototype.cpp:
94         (JSC::BooleanPrototype::finishCreation):
95         * runtime/DatePrototype.cpp:
96         (JSC::DatePrototype::finishCreation):
97         * runtime/ErrorConstructor.cpp:
98         (JSC::ErrorConstructor::finishCreation):
99         * runtime/ErrorPrototype.cpp:
100         (JSC::ErrorPrototype::finishCreation):
101         * runtime/FunctionConstructor.cpp:
102         (JSC::FunctionConstructor::finishCreation):
103         * runtime/FunctionPrototype.cpp:
104         (JSC::FunctionPrototype::finishCreation):
105         * runtime/IntlCollatorPrototype.cpp:
106         (JSC::IntlCollatorPrototype::finishCreation):
107         * runtime/IntlDateTimeFormatPrototype.cpp:
108         (JSC::IntlDateTimeFormatPrototype::finishCreation):
109         * runtime/IntlNumberFormatPrototype.cpp:
110         (JSC::IntlNumberFormatPrototype::finishCreation):
111         * runtime/IntlPluralRulesPrototype.cpp:
112         (JSC::IntlPluralRulesPrototype::finishCreation):
113         * runtime/JSArrayBufferPrototype.cpp:
114         (JSC::JSArrayBufferPrototype::finishCreation):
115         * runtime/JSDataViewPrototype.cpp:
116         (JSC::JSDataViewPrototype::finishCreation):
117         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
118         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
119         * runtime/JSGlobalObject.cpp:
120         (JSC::createConsoleProperty):
121         * runtime/JSPromisePrototype.cpp:
122         (JSC::JSPromisePrototype::finishCreation):
123         * runtime/JSTypedArrayViewConstructor.cpp:
124         (JSC::JSTypedArrayViewConstructor::finishCreation):
125         * runtime/JSTypedArrayViewPrototype.cpp:
126         (JSC::JSTypedArrayViewPrototype::finishCreation):
127         * runtime/NumberPrototype.cpp:
128         (JSC::NumberPrototype::finishCreation):
129         * runtime/RegExpPrototype.cpp:
130         (JSC::RegExpPrototype::finishCreation):
131         * runtime/StringPrototype.cpp:
132         (JSC::StringPrototype::finishCreation):
133         * runtime/Structure.cpp:
134         (JSC::Structure::isValidPrototype):
135         (JSC::Structure::changePrototypeTransition):
136         * runtime/Structure.h:
137         * runtime/SymbolPrototype.cpp:
138         (JSC::SymbolPrototype::finishCreation):
139         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
140         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
141         * wasm/js/WebAssemblyInstancePrototype.cpp:
142         (JSC::WebAssemblyInstancePrototype::finishCreation):
143         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
144         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
145         * wasm/js/WebAssemblyMemoryPrototype.cpp:
146         (JSC::WebAssemblyMemoryPrototype::finishCreation):
147         * wasm/js/WebAssemblyModulePrototype.cpp:
148         (JSC::WebAssemblyModulePrototype::finishCreation):
149         * wasm/js/WebAssemblyPrototype.cpp:
150         (JSC::WebAssemblyPrototype::finishCreation):
151         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
152         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
153         * wasm/js/WebAssemblyTablePrototype.cpp:
154         (JSC::WebAssemblyTablePrototype::finishCreation):
155
156 2019-04-26  Don Olmstead  <don.olmstead@sony.com>
157
158         Add WTF::findIgnoringASCIICaseWithoutLength to replace strcasestr
159         https://bugs.webkit.org/show_bug.cgi?id=197291
160
161         Reviewed by Konstantin Tokarev.
162
163         Replace uses of strcasestr with WTF::findIgnoringASCIICaseWithoutLength.
164
165         * API/tests/testapi.cpp:
166         * assembler/testmasm.cpp:
167         * b3/air/testair.cpp:
168         * b3/testb3.cpp:
169         * dfg/testdfg.cpp:
170         * dynbench.cpp:
171
172 2019-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
173
174         Unreviewed, rolling out r244669.
175
176         Windows ports can't clean build.
177
178         Reverted changeset:
179
180         "[Win] Add flag to enable version information stamping and
181         disable by default."
182         https://bugs.webkit.org/show_bug.cgi?id=197249
183         https://trac.webkit.org/changeset/244669
184
185 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
186
187         [Win] Add flag to enable version information stamping and disable by default.
188         https://bugs.webkit.org/show_bug.cgi?id=197249
189
190         Reviewed by Ross Kirsling.
191
192         This feature is only used in AppleWin port. Add flag for this task and make it OFF by default.
193         Then enable it by default on AppleWin.
194
195         * CMakeLists.txt:
196
197 2019-04-25  Timothy Hatcher  <timothy@apple.com>
198
199         Disable date and time inputs on iOSMac.
200         https://bugs.webkit.org/show_bug.cgi?id=197287
201         rdar://problem/46794376
202
203         Reviewed by Wenson Hsieh.
204
205         * Configurations/FeatureDefines.xcconfig:
206
207 2019-04-25  Alex Christensen  <achristensen@webkit.org>
208
209         Fix more builds after r244653
210         https://bugs.webkit.org/show_bug.cgi?id=197131
211
212         * b3/B3Value.h:
213         There is an older system with libc++ headers that don't have std::conjunction.  Just use constexpr and && instead for the one use of it in WebKit.
214
215 2019-04-25  Basuke Suzuki  <Basuke.Suzuki@sony.com>
216
217         [RemoteInspector] Fix connection and target identifier types.
218         https://bugs.webkit.org/show_bug.cgi?id=197243
219
220         Reviewed by Ross Kirsling.
221
222         Give dedicated type for RemoteControllableTarget's identifier as Inspector::TargetID.
223
224         Also rename ClientID type used in Socket backend to ConnectionID because this is the identifier
225         socket endpoint assign to the newly created connection. The size was changed to uint32_t.
226         Enough size for managing connections.
227
228         * inspector/remote/RemoteConnectionToTarget.cpp:
229         (Inspector::RemoteConnectionToTarget::setup):
230         (Inspector::RemoteConnectionToTarget::close):
231         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
232         * inspector/remote/RemoteConnectionToTarget.h:
233         * inspector/remote/RemoteControllableTarget.h:
234         * inspector/remote/RemoteInspector.cpp:
235         (Inspector::RemoteInspector::nextAvailableTargetIdentifier):
236         (Inspector::RemoteInspector::registerTarget):
237         (Inspector::RemoteInspector::unregisterTarget):
238         (Inspector::RemoteInspector::updateTarget):
239         (Inspector::RemoteInspector::setupFailed):
240         (Inspector::RemoteInspector::setupCompleted):
241         (Inspector::RemoteInspector::waitingForAutomaticInspection):
242         (Inspector::RemoteInspector::updateTargetListing):
243         * inspector/remote/RemoteInspector.h:
244         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
245         (Inspector::RemoteConnectionToTarget::targetIdentifier const):
246         (Inspector::RemoteConnectionToTarget::setup):
247         (Inspector::RemoteConnectionToTarget::close):
248         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
249         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
250         (Inspector::RemoteInspector::sendMessageToRemote):
251         (Inspector::RemoteInspector::receivedSetupMessage):
252         (Inspector::RemoteInspector::receivedDataMessage):
253         (Inspector::RemoteInspector::receivedDidCloseMessage):
254         (Inspector::RemoteInspector::receivedIndicateMessage):
255         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
256         * inspector/remote/glib/RemoteInspectorGlib.cpp:
257         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
258         (Inspector::RemoteInspector::sendMessageToRemote):
259         (Inspector::RemoteInspector::receivedSetupMessage):
260         (Inspector::RemoteInspector::receivedDataMessage):
261         (Inspector::RemoteInspector::receivedCloseMessage):
262         (Inspector::RemoteInspector::setup):
263         (Inspector::RemoteInspector::sendMessageToTarget):
264         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
265         (Inspector::RemoteInspectorConnectionClient::didReceiveWebInspectorEvent):
266         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
267         (Inspector::RemoteInspectorConnectionClient::didAccept):
268         * inspector/remote/socket/RemoteInspectorMessageParser.cpp:
269         (Inspector::MessageParser::MessageParser):
270         (Inspector::MessageParser::parse):
271         * inspector/remote/socket/RemoteInspectorMessageParser.h:
272         (Inspector::MessageParser::setDidParseMessageListener):
273         * inspector/remote/socket/RemoteInspectorServer.cpp:
274         (Inspector::RemoteInspectorServer::didAccept):
275         (Inspector::RemoteInspectorServer::didClose):
276         (Inspector::RemoteInspectorServer::dispatchMap):
277         (Inspector::RemoteInspectorServer::sendWebInspectorEvent):
278         (Inspector::RemoteInspectorServer::sendCloseEvent):
279         (Inspector::RemoteInspectorServer::connectionClosed):
280         * inspector/remote/socket/RemoteInspectorServer.h:
281         * inspector/remote/socket/RemoteInspectorSocket.cpp:
282         (Inspector::RemoteInspector::didClose):
283         (Inspector::RemoteInspector::sendMessageToRemote):
284         (Inspector::RemoteInspector::setup):
285         (Inspector::RemoteInspector::sendMessageToTarget):
286         * inspector/remote/socket/RemoteInspectorSocket.h:
287         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
288         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
289         (Inspector::RemoteInspectorSocketEndpoint::isListening):
290         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
291         (Inspector::RemoteInspectorSocketEndpoint::createClient):
292         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
293         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
294         (Inspector::RemoteInspectorSocketEndpoint::send):
295         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
296         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
297
298 2019-04-25  Alex Christensen  <achristensen@webkit.org>
299
300         Start using C++17
301         https://bugs.webkit.org/show_bug.cgi?id=197131
302
303         Reviewed by Darin Alder.
304
305         * Configurations/Base.xcconfig:
306
307 2019-04-25  Alex Christensen  <achristensen@webkit.org>
308
309         Remove DeprecatedOptional
310         https://bugs.webkit.org/show_bug.cgi?id=197161
311
312         Reviewed by Darin Adler.
313
314         We need to keep a symbol exported from JavaScriptCore for binary compatibility with iOS12.
315         We need this symbol to be in a file that doesn't include anything because libcxx's implementation of
316         std::optional is actually std::__1::optional, which has a different mangled name.  This change will
317         prevent protocol errors from being reported if you are running the iOS12 simulator with a custom build of WebKit
318         and using the web inspector with it, but it's necessary to allow us to start using C++17 in WebKit.
319
320         * JavaScriptCore.xcodeproj/project.pbxproj:
321         * inspector/InspectorBackendDispatcher.cpp:
322         * inspector/InspectorBackendDispatcher.h:
323         * inspector/InspectorBackendDispatcherCompatibility.cpp: Added.
324         (Inspector::BackendDispatcher::reportProtocolError):
325         * inspector/InspectorBackendDispatcherCompatibility.h: Added.
326
327 2019-04-24  Saam Barati  <sbarati@apple.com>
328
329         Add SPI callbacks for before and after module execution
330         https://bugs.webkit.org/show_bug.cgi?id=197244
331         <rdar://problem/50180511>
332
333         Reviewed by Yusuke Suzuki.
334
335         This is helpful for clients that want to profile execution of modules
336         in some way. E.g, if they want to time module execution time.
337
338         * API/JSAPIGlobalObject.h:
339         * API/JSAPIGlobalObject.mm:
340         (JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
341         * API/JSContextPrivate.h:
342         * API/tests/testapi.mm:
343         (+[JSContextFetchDelegate contextWithBlockForFetch:]):
344         (-[JSContextFetchDelegate willEvaluateModule:]):
345         (-[JSContextFetchDelegate didEvaluateModule:]):
346         (testFetch):
347         (testFetchWithTwoCycle):
348         (testFetchWithThreeCycle):
349         (testLoaderResolvesAbsoluteScriptURL):
350         (testLoaderRejectsNilScriptURL):
351         * runtime/JSModuleLoader.cpp:
352         (JSC::JSModuleLoader::evaluate):
353         (JSC::JSModuleLoader::evaluateNonVirtual):
354         * runtime/JSModuleLoader.h:
355
356 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
357
358         [JSC] Shrink DFG::MinifiedNode
359         https://bugs.webkit.org/show_bug.cgi?id=197224
360
361         Reviewed by Filip Pizlo.
362
363         Since it is kept alive with compiled DFG code, we should shrink it to save memory.
364         If it is effective, we should consider minimizing these OSR exit data more aggressively.
365
366         * dfg/DFGMinifiedNode.h:
367
368 2019-04-23  Saam Barati  <sbarati@apple.com>
369
370         LICM incorrectly assumes it'll never insert a node which provably OSR exits
371         https://bugs.webkit.org/show_bug.cgi?id=196721
372         <rdar://problem/49556479> 
373
374         Reviewed by Filip Pizlo.
375
376         Previously, we assumed LICM could never hoist code that caused us
377         to provably OSR exit. This is a bad assumption, as we may very well
378         hoist such code. Obviously hoisting such code is not ideal. We shouldn't
379         hoist something we provably know will OSR exit. However, this is super rare,
380         and the phase is written in such a way where it's easier to gracefully
381         handle this case than to prevent us from hoisting such code.
382         
383         If we wanted to ensure we never hoisted code that would provably exit, we'd
384         have to teach the phase to know when it inserted code that provably exits. I
385         saw two ways to do that:
386         1: Save and restore the AI state before actually hoisting.
387         2: Write an analysis that can determine if such a node would exit.
388         
389         (1) is bad because it costs in memory and compile time. (2) will inevitably
390         have bugs as running into this condition is rare.
391         
392         So instead of (1) or (2), I opted to have LICM gracefully handle when
393         it causes a provable exit. When we encounter this, we mark all blocks
394         in the loop as !cfaHasVisited and !cfaDidFinish.
395
396         * dfg/DFGLICMPhase.cpp:
397         (JSC::DFG::LICMPhase::attemptHoist):
398
399 2019-04-23  Yusuke Suzuki  <ysuzuki@apple.com>
400
401         [JSC] Use node index as DFG::MinifiedID
402         https://bugs.webkit.org/show_bug.cgi?id=197186
403
404         Reviewed by Saam Barati.
405
406         DFG Nodes can be identified with index if the graph is given. We should use unsigned index as a DFG::MinifiedID's underlying
407         source instead of Node* to reduce the size of VariableEvent from 16 to 12. Vector<VariableEvent> is the main data in DFG's OSR
408         tracking. It is kept after DFG compilation is done to make OSR work. We saw that this is allocated with large size in GMail.
409
410         * JavaScriptCore.xcodeproj/project.pbxproj:
411         * bytecode/DataFormat.h:
412         * bytecode/ValueRecovery.h:
413         * dfg/DFGGenerationInfo.h:
414         * dfg/DFGMinifiedID.h:
415         (JSC::DFG::MinifiedID::MinifiedID):
416         (JSC::DFG::MinifiedID::operator! const):
417         (JSC::DFG::MinifiedID::operator== const):
418         (JSC::DFG::MinifiedID::operator!= const):
419         (JSC::DFG::MinifiedID::operator< const):
420         (JSC::DFG::MinifiedID::operator> const):
421         (JSC::DFG::MinifiedID::operator<= const):
422         (JSC::DFG::MinifiedID::operator>= const):
423         (JSC::DFG::MinifiedID::hash const):
424         (JSC::DFG::MinifiedID::dump const):
425         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
426         (JSC::DFG::MinifiedID::fromBits):
427         (JSC::DFG::MinifiedID::bits const):
428         (JSC::DFG::MinifiedID::invalidIndex):
429         (JSC::DFG::MinifiedID::otherInvalidIndex):
430         (JSC::DFG::MinifiedID::node const): Deleted.
431         (JSC::DFG::MinifiedID::invalidID): Deleted.
432         (JSC::DFG::MinifiedID::otherInvalidID): Deleted.
433         * dfg/DFGMinifiedIDInlines.h: Copied from Source/JavaScriptCore/dfg/DFGMinifiedNode.cpp.
434         (JSC::DFG::MinifiedID::MinifiedID):
435         * dfg/DFGMinifiedNode.cpp:
436         * dfg/DFGValueSource.h:
437         (JSC::DFG::ValueSource::ValueSource):
438         * dfg/DFGVariableEvent.h:
439         (JSC::DFG::VariableEvent::dataFormat const):
440
441 2019-04-23  Keith Rollin  <krollin@apple.com>
442
443         Add Xcode version check for Header post-processing scripts
444         https://bugs.webkit.org/show_bug.cgi?id=197116
445         <rdar://problem/50058968>
446
447         Reviewed by Brent Fulgham.
448
449         There are several places in our Xcode projects that post-process
450         header files after they've been exported. Because of XCBuild, we're
451         moving to a model where the post-processing is performed at the same
452         time the header files are exported, rather than as a distinct
453         post-processing step. This patch disables the distinct step when the
454         inline processing is available.
455
456         In practice, this means prefixing appropriate post-processing Custom
457         Build phases with:
458
459         if [ "${XCODE_VERSION_MAJOR}" -ge "1100" -a "${USE_NEW_BUILD_SYSTEM}" = "YES" ]; then
460             # In this configuration, post-processing is performed at the same time as copying in the postprocess-header-rule script, so there's no need for this separate step.
461             exit 0
462         fi
463
464         * JavaScriptCore.xcodeproj/project.pbxproj:
465
466 2019-04-23  Commit Queue  <commit-queue@webkit.org>
467
468         Unreviewed, rolling out r244558.
469         https://bugs.webkit.org/show_bug.cgi?id=197219
470
471         Causing crashes on iOS Sim Release and Debug (Requested by
472         ShawnRoberts on #webkit).
473
474         Reverted changeset:
475
476         "Remove DeprecatedOptional"
477         https://bugs.webkit.org/show_bug.cgi?id=197161
478         https://trac.webkit.org/changeset/244558
479
480 2019-04-23  Devin Rousso  <drousso@apple.com>
481
482         Web Inspector: Uncaught Exception: null is not an object (evaluating 'this.ownerDocument.frameIdentifier')
483         https://bugs.webkit.org/show_bug.cgi?id=196420
484         <rdar://problem/49444205>
485
486         Reviewed by Timothy Hatcher.
487
488         * inspector/protocol/DOM.json:
489         Modify the existing `frameId` to represent the owner frame of the node, rather than the
490         frame it holds (in the case of an `<iframe>`).
491
492 2019-04-23  Alex Christensen  <achristensen@webkit.org>
493
494         Remove DeprecatedOptional
495         https://bugs.webkit.org/show_bug.cgi?id=197161
496
497         Reviewed by Darin Adler.
498
499         * inspector/InspectorBackendDispatcher.cpp:
500         * inspector/InspectorBackendDispatcher.h:
501
502 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
503
504         [JSC] Use volatile load to populate backing page in MarkedBlock::Footer instead of using holdLock
505         https://bugs.webkit.org/show_bug.cgi?id=197152
506
507         Reviewed by Saam Barati.
508
509         Emit volatile load instead of using holdLock to populate backing page in MarkedBlock::Footer.
510
511         * heap/BlockDirectory.cpp:
512         (JSC::BlockDirectory::isPagedOut):
513         * heap/MarkedBlock.h:
514         (JSC::MarkedBlock::populatePage const):
515
516 2019-04-22  Yusuke Suzuki  <ysuzuki@apple.com>
517
518         [JSC] useJIT should subsume useRegExpJIT
519         https://bugs.webkit.org/show_bug.cgi?id=197153
520
521         Reviewed by Alex Christensen.
522
523         useJIT should subsume useRegExpJIT. We should immediately disable JIT feature if useJIT = false,
524         even if useRegExpJIT is true.
525
526         * dfg/DFGCapabilities.cpp:
527         (JSC::DFG::isSupported):
528         * runtime/Options.cpp:
529         (JSC::recomputeDependentOptions):
530         * runtime/RegExp.cpp:
531         (JSC::RegExp::compile):
532         (JSC::RegExp::compileMatchOnly):
533         * runtime/VM.cpp:
534         (JSC::enableAssembler):
535         (JSC::VM::canUseRegExpJIT): Deleted.
536         * runtime/VM.h:
537
538 2019-04-22  Basuke Suzuki  <basuke.suzuki@sony.com>
539
540         [PlayStation] Restructuring Remote Inspector classes to support multiple platform.
541         https://bugs.webkit.org/show_bug.cgi?id=197030
542
543         Reviewed by Don Olmstead.
544
545         Restructuring the PlayStation's RemoteInspector backend which uses native socket for the communication to be ready for WinCairo.
546
547         What we did is basically:
548         - Renamed `remote/playstation/` to `remote/socket/`. This directory is now platform independent implementation of socket backend. 
549         - Renamed `RemoteInspectorSocket` class to `RemoteInspectorSocketEndpoint`. This class is platform independent and core of the backend.
550         - Merged `RemoteInspectorSocket{Client|Server}` classes into `RemoteInspectorSocketEndpoint` class because the differences are little.
551         - Defined a new interface functions in `Inspector::Socket` (new) namespace.
552         - Moved POSIX socket implementation into `posix\RemoteInspectorSocketPOSIX.{h|cpp}`.
553
554         * PlatformPlayStation.cmake:
555         * inspector/remote/RemoteInspector.h:
556         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Merged into RemoteInspectorSocketEndpoint.
557         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
558         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Removed.
559         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Merged into RemoteInspectorSocketEndpoint.
560         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Merged into RemoteInspectorSocketEndpoint.
561         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClientPlayStation.cpp.
562         * inspector/remote/socket/RemoteInspectorConnectionClient.h: Renamed from inspector\remote\playstation\RemoteInspectorConnectionClient.h.
563         (Inspector::RemoteInspectorConnectionClient::didAccept):
564         * inspector/remote/socket/RemoteInspectorMessageParser.cpp: Renamed from inspector\remote\playstation\RemoteInspectorMessageParserPlayStation.cpp.
565         * inspector/remote/socket/RemoteInspectorMessageParser.h: Renamed from inspector\remote\playstation\RemoteInspectorMessageParser.h.
566         * inspector/remote/socket/RemoteInspectorServer.cpp: Renamed from inspector\remote\playstation\RemoteInspectorServerPlayStation.cpp.
567         (Inspector::RemoteInspectorServer::didAccept):
568         (Inspector::RemoteInspectorServer::start):
569         * inspector/remote/socket/RemoteInspectorServer.h: Renamed from inspector\remote\playstation\RemoteInspectorServer.h.
570         * inspector/remote/socket/RemoteInspectorSocket.cpp: Renamed from inspector\remote\playstation\RemoteInspectorPlayStation.cpp.
571         (Inspector::RemoteInspector::start):
572         * inspector/remote/socket/RemoteInspectorSocket.h: Copied from inspector\remote\playstation\RemoteInspectorSocket.h.
573         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp: Added.
574         (Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
575         (Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
576         (Inspector::RemoteInspectorSocketEndpoint::wakeupWorkerThread):
577         (Inspector::RemoteInspectorSocketEndpoint::connectInet):
578         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
579         (Inspector::RemoteInspectorSocketEndpoint::isListening):
580         (Inspector::RemoteInspectorSocketEndpoint::workerThread):
581         (Inspector::RemoteInspectorSocketEndpoint::createClient):
582         (Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
583         (Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
584         (Inspector::RemoteInspectorSocketEndpoint::send):
585         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
586         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h: Renamed from inspector\remote\playstation\RemoteInspectorSocket.h.
587         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: Added.
588         (Inspector::Socket::connect):
589         (Inspector::Socket::listen):
590         (Inspector::Socket::accept):
591         (Inspector::Socket::createPair):
592         (Inspector::Socket::setup):
593         (Inspector::Socket::isValid):
594         (Inspector::Socket::isListening):
595         (Inspector::Socket::read):
596         (Inspector::Socket::write):
597         (Inspector::Socket::close):
598         (Inspector::Socket::preparePolling):
599         (Inspector::Socket::poll):
600         (Inspector::Socket::isReadable):
601         (Inspector::Socket::isWritable):
602         (Inspector::Socket::markWaitingWritable):
603         (Inspector::Socket::clearWaitingWritable):
604
605 2019-04-20  Yusuke Suzuki  <ysuzuki@apple.com>
606
607         Unreviewed, suppress warnings in non Darwin environments
608
609         * jit/ExecutableAllocator.cpp:
610         (JSC::dumpJITMemory):
611
612 2019-04-19  Saam Barati  <sbarati@apple.com>
613
614         AbstractValue can represent more than int52
615         https://bugs.webkit.org/show_bug.cgi?id=197118
616         <rdar://problem/49969960>
617
618         Reviewed by Michael Saboff.
619
620         Let's analyze this control flow diamond:
621         
622         #0
623         branch #1, #2
624         
625         #1:
626         PutStack(JSValue, loc42)
627         Jump #3
628         
629         #2:
630         PutStack(Int52, loc42)
631         Jump #3
632         
633         #3:
634         ...
635         
636         Our abstract value for loc42 at the head of #3 will contain an abstract
637         value that us the union of Int52 with other things. Obviously in the
638         above program, a GetStack for loc42 would be inavlid, since it might
639         be loading either JSValue or Int52. However, the abstract interpreter
640         just tracks what the value could be, and it could be Int52 or JSValue.
641         
642         When I did the Int52 refactoring, I expected such things to never happen,
643         but it turns out it does. We should just allow for this instead of asserting
644         against it since it's valid IR to do the above.
645
646         * bytecode/SpeculatedType.cpp:
647         (JSC::dumpSpeculation):
648         * dfg/DFGAbstractValue.cpp:
649         (JSC::DFG::AbstractValue::checkConsistency const):
650         * dfg/DFGAbstractValue.h:
651         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
652
653 2019-04-19  Tadeu Zagallo  <tzagallo@apple.com>
654
655         Add option to dump JIT memory
656         https://bugs.webkit.org/show_bug.cgi?id=197062
657         <rdar://problem/49744332>
658
659         Reviewed by Saam Barati.
660
661         Dump all writes into JIT memory to the specified file. The format is:
662         - 64-bit destination address for the write
663         - 64-bit size of the content written
664         - Copy of the data that was written to JIT memory
665
666         * assembler/LinkBuffer.cpp:
667         (JSC::LinkBuffer::copyCompactAndLinkCode):
668         * jit/ExecutableAllocator.cpp:
669         (JSC::dumpJITMemory):
670         * jit/ExecutableAllocator.h:
671         (JSC::performJITMemcpy):
672         * runtime/Options.h:
673
674 2019-04-19  Keith Rollin  <krollin@apple.com>
675
676         Add postprocess-header-rule scripts
677         https://bugs.webkit.org/show_bug.cgi?id=197072
678         <rdar://problem/50027299>
679
680         Reviewed by Brent Fulgham.
681
682         Several projects have post-processing build phases where exported
683         headers are tweaked after they've been copied. This post-processing is
684         performed via scripts called postprocess-headers.sh. For reasons
685         related to XCBuild, we are now transitioning to a build process where
686         the post-processing is performed at the same time as the
687         exporting/copying. To support this process, add similar scripts named
688         postprocess-header-rule, which are geared towards processing a single
689         file at a time rather than all exported files at once. Also add a
690         build rule that makes use of these scripts. These scripts and build
691         rules are not used at the moment; they will come into use in an
692         imminent patch.
693
694         Note that I've named these postprocess-header-rule rather than
695         postprocess-header-rule.sh. Scripts in Tools/Scripts do not have
696         suffixes indicating how the tool is implemented. Scripts in
697         per-project Scripts folders appear to be mixed regarding the use of
698         suffixes. I'm opting here to follow the Tools/Scripts convention, with
699         the expectation that over time we completely standardize on that.
700
701         * JavaScriptCore.xcodeproj/project.pbxproj:
702         * Scripts/postprocess-header-rule: Added.
703
704 2019-04-18  Saam barati  <sbarati@apple.com>
705
706         Remove useConcurrentBarriers option
707         https://bugs.webkit.org/show_bug.cgi?id=197066
708
709         Reviewed by Michael Saboff.
710
711         This isn't a helpful option as it will lead us to crash when using the
712         concurrent GC.
713
714         * dfg/DFGStoreBarrierClusteringPhase.cpp:
715         * dfg/DFGStoreBarrierInsertionPhase.cpp:
716         * jit/AssemblyHelpers.h:
717         (JSC::AssemblyHelpers::barrierStoreLoadFence):
718         * runtime/Options.h:
719
720 2019-04-17  Saam Barati  <sbarati@apple.com>
721
722         Remove deprecated JSScript SPI
723         https://bugs.webkit.org/show_bug.cgi?id=194909
724         <rdar://problem/48283499>
725
726         Reviewed by Keith Miller.
727
728         * API/JSAPIGlobalObject.mm:
729         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
730         * API/JSScript.h:
731         * API/JSScript.mm:
732         (+[JSScript scriptWithSource:inVirtualMachine:]): Deleted.
733         (fillBufferWithContentsOfFile): Deleted.
734         (+[JSScript scriptFromASCIIFile:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
735         (+[JSScript scriptFromUTF8File:inVirtualMachine:withCodeSigning:andBytecodeCache:]): Deleted.
736         (-[JSScript setSourceURL:]): Deleted.
737         * API/JSScriptInternal.h:
738         * API/tests/testapi.mm:
739         (testFetch):
740         (testFetchWithTwoCycle):
741         (testFetchWithThreeCycle):
742         (testLoaderResolvesAbsoluteScriptURL):
743         (testImportModuleTwice):
744         (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]):
745
746 2019-04-17  Keith Rollin  <krollin@apple.com>
747
748         Remove JSCBuiltins.cpp from Copy Headers phase
749         https://bugs.webkit.org/show_bug.cgi?id=196981
750         <rdar://problem/49952133>
751
752         Reviewed by Alex Christensen.
753
754         JSCBuiltins.cpp is not a header and so doesn't need to be in the Copy
755         Headers phase. Checking its history, it seems to have been added
756         accidentally at the same time that JSCBuiltins.h was added.
757
758         * JavaScriptCore.xcodeproj/project.pbxproj:
759
760 2019-04-16  Stephan Szabo  <stephan.szabo@sony.com>
761
762         [PlayStation] Update port for system library changes
763         https://bugs.webkit.org/show_bug.cgi?id=196978
764
765         Reviewed by Ross Kirsling.
766
767         * shell/playstation/Initializer.cpp:
768         Add reference to new posix compatibility library.
769
770 2019-04-16  Robin Morisset  <rmorisset@apple.com>
771
772         [WTF] holdLock should be marked WARN_UNUSED_RETURN
773         https://bugs.webkit.org/show_bug.cgi?id=196922
774
775         Reviewed by Keith Miller.
776
777         There was one case where holdLock was used and the result ignored.
778         From a comment that was deleted in https://bugs.webkit.org/attachment.cgi?id=328438&action=prettypatch, I believe that it is on purpose.
779         So I brought back a variant of the comment, and made the ignoring of the return explicit.
780
781         * heap/BlockDirectory.cpp:
782         (JSC::BlockDirectory::isPagedOut):
783
784 2019-04-16  Caitlin Potter  <caitp@igalia.com>
785
786         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
787         https://bugs.webkit.org/show_bug.cgi?id=176810
788
789         Reviewed by Saam Barati.
790
791         This adds conditional logic following the invariant checks, to perform
792         filtering in common uses of getOwnPropertyNames.
793
794         While this would ideally only be done in JSPropertyNameEnumerator, adding
795         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
796         invariant that the EnumerationMode is properly followed.
797
798         This was originally rolled out in r244020, as DontEnum filtering code
799         in ObjectConstructor.cpp's ownPropertyKeys() had not been removed. It's
800         now redundant due to being handled in ProxyObject::getOwnPropertyNames().
801
802         * runtime/PropertyNameArray.h:
803         (JSC::PropertyNameArray::reset):
804         * runtime/ProxyObject.cpp:
805         (JSC::ProxyObject::performGetOwnPropertyNames):
806
807 2019-04-15  Saam barati  <sbarati@apple.com>
808
809         Modify how we do SetArgument when we inline varargs calls
810         https://bugs.webkit.org/show_bug.cgi?id=196712
811         <rdar://problem/49605012>
812
813         Reviewed by Michael Saboff.
814
815         When we inline varargs calls, we guarantee that the number of arguments that
816         go on the stack are somewhere between the "mandatoryMinimum" and the "limit - 1".
817         However, we can't statically guarantee that the arguments between these two
818         ranges was filled out by Load/ForwardVarargs. This is because in the general
819         case we don't know the argument count statically.
820         
821         However, we used to always emit SetArgumentDefinitely up to "limit - 1" for
822         all arguments, even when some arguments aren't guaranteed to be in a valid
823         state. Emitting these SetArgumentDefinitely were helpful because they let us
824         handle variable liveness and OSR exit metadata. However, when we converted
825         to SSA, we ended up emitting a GetStack for each such SetArgumentDefinitely.
826         
827         This is wrong, as we can't guarantee such SetArgumentDefinitely nodes are
828         actually looking at a range of the stack that are guaranteed to be initialized.
829         This patch introduces a new form of SetArgument node: SetArgumentMaybe. In terms
830         of OSR exit metadata and variable liveness tracking, it behaves like SetArgumentDefinitely.
831         
832         However, it differs in a couple key ways:
833         1. In ThreadedCPS, GetLocal(@SetArgumentMaybe) is invalid IR, as this implies
834         you might be loading uninitialized stack. (This same rule applies when you do
835         the full data flow reachability analysis over CPS Phis.) If someone logically
836         wanted to emit code like this, the correct node to emit would be GetArgument,
837         not GetLocal. For similar reasons, PhantomLocal(@SetArgumentMaybe) is also
838         invalid IR.
839         2. To track liveness, Flush(@SetArgumentMaybe) is valid, and is the main user
840         of SetArgumentMaybe.
841         3. In SSA conversion, we don't lower SetArgumentMaybe to GetStack, as there
842         should be no data flow user of SetArgumentMaybe.
843         
844         SetArgumentDefinitely guarantees that the stack slot is initialized.
845         SetArgumentMaybe makes no such guarantee.
846
847         * dfg/DFGAbstractInterpreterInlines.h:
848         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
849         * dfg/DFGByteCodeParser.cpp:
850         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
851         * dfg/DFGCPSRethreadingPhase.cpp:
852         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
853         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
854         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
855         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
856         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
857         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
858         * dfg/DFGClobberize.h:
859         (JSC::DFG::clobberize):
860         * dfg/DFGCommon.h:
861         * dfg/DFGDoesGC.cpp:
862         (JSC::DFG::doesGC):
863         * dfg/DFGFixupPhase.cpp:
864         (JSC::DFG::FixupPhase::fixupNode):
865         * dfg/DFGInPlaceAbstractState.cpp:
866         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
867         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
868         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
869         * dfg/DFGMaximalFlushInsertionPhase.cpp:
870         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
871         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
872         * dfg/DFGMayExit.cpp:
873         * dfg/DFGNode.cpp:
874         (JSC::DFG::Node::hasVariableAccessData):
875         * dfg/DFGNodeType.h:
876         * dfg/DFGPhantomInsertionPhase.cpp:
877         * dfg/DFGPredictionPropagationPhase.cpp:
878         * dfg/DFGSSAConversionPhase.cpp:
879         (JSC::DFG::SSAConversionPhase::run):
880         * dfg/DFGSafeToExecute.h:
881         (JSC::DFG::safeToExecute):
882         * dfg/DFGSpeculativeJIT32_64.cpp:
883         (JSC::DFG::SpeculativeJIT::compile):
884         * dfg/DFGSpeculativeJIT64.cpp:
885         (JSC::DFG::SpeculativeJIT::compile):
886         * dfg/DFGValidate.cpp:
887         * ftl/FTLCapabilities.cpp:
888         (JSC::FTL::canCompile):
889
890 2019-04-15  Commit Queue  <commit-queue@webkit.org>
891
892         Unreviewed, rolling out r243672.
893         https://bugs.webkit.org/show_bug.cgi?id=196952
894
895         [JSValue release] should be thread-safe (Requested by
896         yusukesuzuki on #webkit).
897
898         Reverted changeset:
899
900         "[JSC] JSWrapperMap should not use Objective-C Weak map
901         (NSMapTable with NSPointerFunctionsWeakMemory) for
902         m_cachedObjCWrappers"
903         https://bugs.webkit.org/show_bug.cgi?id=196392
904         https://trac.webkit.org/changeset/243672
905
906 2019-04-15  Saam barati  <sbarati@apple.com>
907
908         SafeToExecute for GetByOffset/GetGetterByOffset/PutByOffset is using the wrong child for the base
909         https://bugs.webkit.org/show_bug.cgi?id=196945
910         <rdar://problem/49802750>
911
912         Reviewed by Filip Pizlo.
913
914         * dfg/DFGSafeToExecute.h:
915         (JSC::DFG::safeToExecute):
916
917 2019-04-15  Robin Morisset  <rmorisset@apple.com>
918
919         DFG should be able to constant fold Object.create() with a constant prototype operand
920         https://bugs.webkit.org/show_bug.cgi?id=196886
921
922         Reviewed by Yusuke Suzuki.
923
924
925         It is a fairly simple and limited patch, as it only works when the DFG can prove the exact object used as prototype.
926         But when it applies it can be a significant win:
927                                                         Baseline                   Optim                                       
928         object-create-constant-prototype              3.6082+-0.0979     ^      1.6947+-0.0756        ^ definitely 2.1292x faster
929         object-create-null                           11.4492+-0.2510     ?     11.5030+-0.2402        ?
930         object-create-unknown-object-prototype       15.6067+-0.1851     ?     15.7500+-0.2322        ?
931         object-create-untyped-prototype               8.8873+-0.1240     ?      8.9806+-0.1202        ? might be 1.0105x slower
932         <geometric>                                   8.6967+-0.1208     ^      7.2408+-0.1367        ^ definitely 1.2011x faster
933
934         The only subtlety is that we need to to access the StructureCache concurrently from the compiler thread (see https://bugs.webkit.org/show_bug.cgi?id=186199)
935         I solved this with a simple lock, taken when the compiler thread tries to read it, and when the main thread tries to modify it.
936         I expect it to be extremely low contention, but will watch the bots just in case.
937         The lock is taken neither when the main thread is only reading the cache (it has no-one to race with), nor when the GC purges it of dead entries (it does not free anything while a compiler thread is in the middle of a phase).
938
939         * dfg/DFGAbstractInterpreterInlines.h:
940         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
941         * dfg/DFGConstantFoldingPhase.cpp:
942         (JSC::DFG::ConstantFoldingPhase::foldConstants):
943         * runtime/StructureCache.cpp:
944         (JSC::StructureCache::createEmptyStructure):
945         (JSC::StructureCache::tryEmptyObjectStructureForPrototypeFromCompilerThread):
946         * runtime/StructureCache.h:
947
948 2019-04-15  Devin Rousso  <drousso@apple.com>
949
950         Web Inspector: fake value descriptors for promises add a catch handler, preventing "rejectionhandled" events from being fired
951         https://bugs.webkit.org/show_bug.cgi?id=196484
952         <rdar://problem/49114725>
953
954         Reviewed by Joseph Pecoraro.
955
956         Only add a catch handler when the promise is reachable via a native getter and is known to
957         have rejected. A non-rejected promise doesn't need a catch handler, and any promise that
958         isn't reachable via a getter won't actually be reached, as `InjectedScript` doesn't call any
959         functions, instead only getting the function object itself.
960
961         * inspector/InjectedScriptSource.js:
962         (InjectedScript.prototype._propertyDescriptors.createFakeValueDescriptor):
963
964         * inspector/JSInjectedScriptHost.h:
965         * inspector/JSInjectedScriptHost.cpp:
966         (Inspector::JSInjectedScriptHost::isPromiseRejectedWithNativeGetterTypeError): Added.
967         * inspector/JSInjectedScriptHostPrototype.cpp:
968         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
969         (Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Added.
970
971         * runtime/ErrorInstance.h:
972         (JSC::ErrorInstance::setNativeGetterTypeError): Added.
973         (JSC::ErrorInstance::isNativeGetterTypeError const): Added.
974
975         * runtime/Error.h:
976         (JSC::throwVMGetterTypeError): Added.
977         * runtime/Error.cpp:
978         (JSC::createGetterTypeError): Added.
979         (JSC::throwGetterTypeError): Added.
980         (JSC::throwDOMAttributeGetterTypeError):
981
982 2019-04-15  Robin Morisset  <rmorisset@apple.com>
983
984         B3::Value should have different kinds of adjacency lists
985         https://bugs.webkit.org/show_bug.cgi?id=196091
986
987         Reviewed by Filip Pizlo.
988
989         The key idea of this optimization is to replace the Vector<Value*, 3> m_children in B3::Value (40 bytes on 64-bits platform) by one of the following:
990         - Nothing (0 bytes)
991         - 1 Value* (8 bytes)
992         - 2 Value* (16 bytes)
993         - 3 Value* (24 bytes)
994         - A Vector<Value*, 3>
995         after the end of the Value object, depending on the kind of the Value.
996         So for example, when allocating an Add, we would allocate an extra 16 bytes into which to store 2 Values.
997         This would halve the memory consumption of Const64/Const32/Nop/Identity and a bunch more kinds of values, and reduce by a more moderate amount the memory consumption of the rest of non-varargs values (e.g. Add would go from 72 to 48 bytes).
998
999         A few implementation points:
1000         - Even if there is no children, we must remember to allocate at least enough space for replaceWithIdentity to work later. It needs sizeof(Value) (for the object itself) + sizeof(Value*) (for the pointer to its child)
1001         - We must make sure to destroy the vector whenever we destroy a Value which is VarArgs
1002         - We must remember how many elements there are in the case where we did not allocate a Vector. We cannot do it purely by relying on the kind, both for speed reasons and because Return can have either 0 or 1 argument in B3
1003           Thankfully, we have an extra byte of padding to use in the middle of B3::Value
1004         - In order to support clone(), we must have a separate version of allocate, which extracts the opcode from the to-be-cloned object instead of from the call to the constructor
1005         - Speaking of which, we need a special templated function opcodeFromConstructor, because some of the constructors of subclasses of Value don't take an explicit Opcode as argument, typically because they match a single one.
1006         - To maximize performance, we provide specialized versions of child/lastChild/numChildren/children in the subclasses of Value, skipping checks when the actual type of the Value is already known.
1007           This is done through the B3_SPECIALIZE_VALUE_FOR_... defined at the bottom of B3Value.h
1008         - In the constructors of Value, we convert all extra children arguments to Value* eagerly. It is not required for correctness (they will be converted when put into a Vector<Value*> or a Value* in the end), but it helps limit an explosion in the number of template instantiations.
1009         - I moved DeepValueDump::dump from the .h to the .cpp, as there is no good reason to inline it, and recompiling JSC is already slow enough
1010
1011         * JavaScriptCore.xcodeproj/project.pbxproj:
1012         * b3/B3ArgumentRegValue.cpp:
1013         (JSC::B3::ArgumentRegValue::cloneImpl const): Deleted.
1014         * b3/B3ArgumentRegValue.h:
1015         * b3/B3AtomicValue.cpp:
1016         (JSC::B3::AtomicValue::AtomicValue):
1017         (JSC::B3::AtomicValue::cloneImpl const): Deleted.
1018         * b3/B3AtomicValue.h:
1019         * b3/B3BasicBlock.h:
1020         * b3/B3BasicBlockInlines.h:
1021         (JSC::B3::BasicBlock::appendNewNonTerminal): Deleted.
1022         * b3/B3CCallValue.cpp:
1023         (JSC::B3::CCallValue::appendArgs):
1024         (JSC::B3::CCallValue::cloneImpl const): Deleted.
1025         * b3/B3CCallValue.h:
1026         * b3/B3CheckValue.cpp:
1027         (JSC::B3::CheckValue::cloneImpl const): Deleted.
1028         * b3/B3CheckValue.h:
1029         * b3/B3Const32Value.cpp:
1030         (JSC::B3::Const32Value::cloneImpl const): Deleted.
1031         * b3/B3Const32Value.h:
1032         * b3/B3Const64Value.cpp:
1033         (JSC::B3::Const64Value::cloneImpl const): Deleted.
1034         * b3/B3Const64Value.h:
1035         * b3/B3ConstDoubleValue.cpp:
1036         (JSC::B3::ConstDoubleValue::cloneImpl const): Deleted.
1037         * b3/B3ConstDoubleValue.h:
1038         * b3/B3ConstFloatValue.cpp:
1039         (JSC::B3::ConstFloatValue::cloneImpl const): Deleted.
1040         * b3/B3ConstFloatValue.h:
1041         * b3/B3ConstPtrValue.h:
1042         (JSC::B3::ConstPtrValue::opcodeFromConstructor):
1043         * b3/B3FenceValue.cpp:
1044         (JSC::B3::FenceValue::FenceValue):
1045         (JSC::B3::FenceValue::cloneImpl const): Deleted.
1046         * b3/B3FenceValue.h:
1047         * b3/B3MemoryValue.cpp:
1048         (JSC::B3::MemoryValue::MemoryValue):
1049         (JSC::B3::MemoryValue::cloneImpl const): Deleted.
1050         * b3/B3MemoryValue.h:
1051         * b3/B3MoveConstants.cpp:
1052         * b3/B3PatchpointValue.cpp:
1053         (JSC::B3::PatchpointValue::cloneImpl const): Deleted.
1054         * b3/B3PatchpointValue.h:
1055         (JSC::B3::PatchpointValue::opcodeFromConstructor):
1056         * b3/B3Procedure.cpp:
1057         * b3/B3Procedure.h:
1058         * b3/B3ProcedureInlines.h:
1059         (JSC::B3::Procedure::add):
1060         * b3/B3SlotBaseValue.cpp:
1061         (JSC::B3::SlotBaseValue::cloneImpl const): Deleted.
1062         * b3/B3SlotBaseValue.h:
1063         * b3/B3StackmapSpecial.cpp:
1064         (JSC::B3::StackmapSpecial::forEachArgImpl):
1065         (JSC::B3::StackmapSpecial::isValidImpl):
1066         * b3/B3StackmapValue.cpp:
1067         (JSC::B3::StackmapValue::append):
1068         (JSC::B3::StackmapValue::StackmapValue):
1069         * b3/B3StackmapValue.h:
1070         * b3/B3SwitchValue.cpp:
1071         (JSC::B3::SwitchValue::SwitchValue):
1072         (JSC::B3::SwitchValue::cloneImpl const): Deleted.
1073         * b3/B3SwitchValue.h:
1074         (JSC::B3::SwitchValue::opcodeFromConstructor):
1075         * b3/B3UpsilonValue.cpp:
1076         (JSC::B3::UpsilonValue::cloneImpl const): Deleted.
1077         * b3/B3UpsilonValue.h:
1078         * b3/B3Value.cpp:
1079         (JSC::B3::DeepValueDump::dump const):
1080         (JSC::B3::Value::~Value):
1081         (JSC::B3::Value::replaceWithIdentity):
1082         (JSC::B3::Value::replaceWithNopIgnoringType):
1083         (JSC::B3::Value::replaceWithPhi):
1084         (JSC::B3::Value::replaceWithJump):
1085         (JSC::B3::Value::replaceWithOops):
1086         (JSC::B3::Value::replaceWith):
1087         (JSC::B3::Value::invertedCompare const):
1088         (JSC::B3::Value::returnsBool const):
1089         (JSC::B3::Value::cloneImpl const): Deleted.
1090         * b3/B3Value.h:
1091         (JSC::B3::DeepValueDump::dump const): Deleted.
1092         * b3/B3ValueInlines.h:
1093         (JSC::B3::Value::adjacencyListOffset const):
1094         (JSC::B3::Value::cloneImpl const):
1095         * b3/B3VariableValue.cpp:
1096         (JSC::B3::VariableValue::VariableValue):
1097         (JSC::B3::VariableValue::cloneImpl const): Deleted.
1098         * b3/B3VariableValue.h:
1099         * b3/B3WasmAddressValue.cpp:
1100         (JSC::B3::WasmAddressValue::WasmAddressValue):
1101         (JSC::B3::WasmAddressValue::cloneImpl const): Deleted.
1102         * b3/B3WasmAddressValue.h:
1103         * b3/B3WasmBoundsCheckValue.cpp:
1104         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1105         (JSC::B3::WasmBoundsCheckValue::cloneImpl const): Deleted.
1106         * b3/B3WasmBoundsCheckValue.h:
1107         (JSC::B3::WasmBoundsCheckValue::accepts):
1108         (JSC::B3::WasmBoundsCheckValue::opcodeFromConstructor):
1109         * b3/testb3.cpp:
1110         (JSC::B3::testCallFunctionWithHellaArguments):
1111         (JSC::B3::testCallFunctionWithHellaArguments2):
1112         (JSC::B3::testCallFunctionWithHellaArguments3):
1113         (JSC::B3::testCallFunctionWithHellaDoubleArguments):
1114         (JSC::B3::testCallFunctionWithHellaFloatArguments):
1115         * ftl/FTLOutput.h:
1116         (JSC::FTL::Output::call):
1117
1118 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
1119
1120         Bytecode cache should not encode the SourceProvider for UnlinkedFunctionExecutable's classSource
1121         https://bugs.webkit.org/show_bug.cgi?id=196878
1122
1123         Reviewed by Saam Barati.
1124
1125         Every time we encode an (Unlinked)SourceCode, we encode its SourceProvider,
1126         including the full source if it's a StringSourceProvider. This wasn't an issue,
1127         since the SourceCode contains a RefPtr to the SourceProvider, and the Encoder
1128         would avoid encoding the provider multiple times. With the addition of the
1129         incremental cache, each UnlinkedFunctionCodeBlock is encoded in isolation, which
1130         means we can no longer deduplicate it and the full program text was being encoded
1131         multiple times in the cache.
1132         As a work around, this patch adds a custom cached type for encoding the SourceCode
1133         without its provider, and later injects the SourceProvider through the Decoder.
1134
1135         * parser/SourceCode.h:
1136         * parser/UnlinkedSourceCode.h:
1137         (JSC::UnlinkedSourceCode::provider const):
1138         * runtime/CachedTypes.cpp:
1139         (JSC::Decoder::Decoder):
1140         (JSC::Decoder::create):
1141         (JSC::Decoder::provider const):
1142         (JSC::CachedSourceCodeWithoutProvider::encode):
1143         (JSC::CachedSourceCodeWithoutProvider::decode const):
1144         (JSC::decodeCodeBlockImpl):
1145         * runtime/CachedTypes.h:
1146
1147 2019-04-15  Robin Morisset  <rmorisset@apple.com>
1148
1149         MarkedSpace.cpp is not in the Xcode workspace
1150         https://bugs.webkit.org/show_bug.cgi?id=196928
1151
1152         Reviewed by Saam Barati.
1153
1154         * JavaScriptCore.xcodeproj/project.pbxproj:
1155
1156 2019-04-15  Tadeu Zagallo  <tzagallo@apple.com>
1157
1158         Incremental bytecode cache should not append function updates when loaded from memory
1159         https://bugs.webkit.org/show_bug.cgi?id=196865
1160
1161         Reviewed by Filip Pizlo.
1162
1163         Function updates hold the assumption that a function can only be executed/cached
1164         after its containing code block has already been cached. This assumptions does
1165         not hold if the UnlinkedCodeBlock is loaded from memory by the CodeCache, since
1166         we might have two independent SourceProviders executing different paths of the
1167         code and causing the same UnlinkedCodeBlock to be modified in memory.
1168         Use a RefPtr instead of Ref for m_cachedBytecode in ShellSourceProvider to distinguish
1169         between a new, empty cache and a cache that was not loaded and therefore cannot be updated.
1170
1171         * jsc.cpp:
1172         (ShellSourceProvider::ShellSourceProvider):
1173
1174 2019-04-15  Saam barati  <sbarati@apple.com>
1175
1176         mergeOSREntryValue is wrong when the incoming value does not match up with the flush format
1177         https://bugs.webkit.org/show_bug.cgi?id=196918
1178
1179         Reviewed by Yusuke Suzuki.
1180
1181         r244238 lead to some debug failures because we were calling checkConsistency()
1182         before doing fixTypeForRepresentation when merging in must handle values in
1183         CFA. This patch fixes that.
1184         
1185         However, as I was reading over mergeOSREntryValue, I realized it was wrong. It
1186         was possible it could merge in a value/type outside of the variable's flushed type.
1187         Once the flush format types are locked in, we can't introduce a type out of
1188         that range. This probably never lead to any crashes as our profiling injection
1189         and speculation decision code is solid. However, what we were doing is clearly
1190         wrong, and something a fuzzer could have found if we fuzzed the must handle
1191         values inside prediction injection. We should do that fuzzing:
1192         https://bugs.webkit.org/show_bug.cgi?id=196924
1193
1194         * dfg/DFGAbstractValue.cpp:
1195         (JSC::DFG::AbstractValue::mergeOSREntryValue):
1196         * dfg/DFGAbstractValue.h:
1197         * dfg/DFGCFAPhase.cpp:
1198         (JSC::DFG::CFAPhase::injectOSR):
1199
1200 2019-04-15  Robin Morisset  <rmorisset@apple.com>
1201
1202         Several structures and enums in the Yarr interpreter can be shrunk
1203         https://bugs.webkit.org/show_bug.cgi?id=196923
1204
1205         Reviewed by Saam Barati.
1206
1207         YarrOp: 88 -> 80
1208         RegularExpression: 40 -> 32
1209         ByteTerm: 56 -> 48
1210         PatternTerm: 56 -> 48
1211
1212         * yarr/RegularExpression.cpp:
1213         * yarr/YarrInterpreter.h:
1214         * yarr/YarrJIT.cpp:
1215         (JSC::Yarr::YarrGenerator::YarrOp::YarrOp):
1216         * yarr/YarrParser.h:
1217         * yarr/YarrPattern.h:
1218
1219 2019-04-15  Devin Rousso  <drousso@apple.com>
1220
1221         Web Inspector: REGRESSION(r244172): crash when trying to add extra domain while inspecting JSContext
1222         https://bugs.webkit.org/show_bug.cgi?id=196925
1223         <rdar://problem/49873994>
1224
1225         Reviewed by Joseph Pecoraro.
1226
1227         Move the logic for creating the `InspectorAgent` and `InspectorDebuggerAgent` into separate
1228         functions so that callers can be guaranteed to have a valid instance of the agent.
1229
1230         * inspector/JSGlobalObjectInspectorController.h:
1231         * inspector/JSGlobalObjectInspectorController.cpp:
1232         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
1233         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
1234         (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
1235         (Inspector::JSGlobalObjectInspectorController::ensureInspectorAgent): Added.
1236         (Inspector::JSGlobalObjectInspectorController::ensureDebuggerAgent): Added.
1237         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1238
1239 2019-04-14  Don Olmstead  <don.olmstead@sony.com>
1240
1241         [CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
1242         https://bugs.webkit.org/show_bug.cgi?id=196742
1243
1244         Reviewed by Konstantin Tokarev.
1245
1246         Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
1247         to support moving the JavaScriptCore derived sources outside of a shared directory.
1248
1249         Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.
1250
1251         * CMakeLists.txt:
1252
1253 2019-04-13  Tadeu Zagallo  <tzagallo@apple.com>
1254
1255         CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
1256         https://bugs.webkit.org/show_bug.cgi?id=196880
1257
1258         Reviewed by Yusuke Suzuki.
1259
1260         CodeCache should not tell the SourceProvider to cache the bytecode if it failed
1261         to create the UnlinkedCodeBlock.
1262
1263         * runtime/CodeCache.cpp:
1264         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
1265
1266 2019-04-12  Saam barati  <sbarati@apple.com>
1267
1268         r244079 logically broke shouldSpeculateInt52
1269         https://bugs.webkit.org/show_bug.cgi?id=196884
1270
1271         Reviewed by Yusuke Suzuki.
1272
1273         In r244079, I changed shouldSpeculateInt52 to only return true
1274         when the prediction is isAnyInt52Speculation(). However, it was
1275         wrong to not to include SpecInt32 in this for two reasons:
1276
1277         1. We diligently write code that first checks if we should speculate Int32.
1278         For example:
1279         if (shouldSpeculateInt32()) ... 
1280         else if (shouldSpeculateInt52()) ...
1281
1282         It would be wrong not to fall back to Int52 if we're dealing with the union of
1283         Int32 and Int52.
1284
1285         It would be a performance mistake to not include Int32 here because
1286         data flow can easily tell us that we have variables that are the union
1287         of Int32 and Int52 values. It's better to speculate Int52 than Double
1288         in that situation.
1289
1290         2. We also write code where we ask if the inputs can be Int52, e.g, if
1291         we know via profiling that an Add overflows, we may not emit an Int32 add.
1292         However, we only emit such an add if both inputs can be Int52, and Int32
1293         can trivially become Int52.
1294
1295        This patch recovers the 0.5-1% regression r244079 caused on JetStream 2.
1296
1297         * bytecode/SpeculatedType.h:
1298         (JSC::isInt32SpeculationForArithmetic):
1299         (JSC::isInt32OrBooleanSpeculationForArithmetic):
1300         (JSC::isInt32OrInt52Speculation):
1301         * dfg/DFGFixupPhase.cpp:
1302         (JSC::DFG::FixupPhase::observeUseKindOnNode):
1303         * dfg/DFGNode.h:
1304         (JSC::DFG::Node::shouldSpeculateInt52):
1305         * dfg/DFGPredictionPropagationPhase.cpp:
1306         * dfg/DFGVariableAccessData.cpp:
1307         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
1308
1309 2019-04-12  Saam barati  <sbarati@apple.com>
1310
1311         Unreviewed. Build fix after r244233.
1312
1313         * assembler/CPU.cpp:
1314
1315 2019-04-12  Saam barati  <sbarati@apple.com>
1316
1317         Sometimes we need to user fewer CPUs in our threading calculations
1318         https://bugs.webkit.org/show_bug.cgi?id=196794
1319         <rdar://problem/49389497>
1320
1321         Reviewed by Yusuke Suzuki.
1322
1323         * JavaScriptCore.xcodeproj/project.pbxproj:
1324         * Sources.txt:
1325         * assembler/CPU.cpp: Added.
1326         (JSC::isKernTCSMAvailable):
1327         (JSC::enableKernTCSM):
1328         (JSC::kernTCSMAwareNumberOfProcessorCores):
1329         * assembler/CPU.h:
1330         (JSC::isKernTCSMAvailable):
1331         (JSC::enableKernTCSM):
1332         (JSC::kernTCSMAwareNumberOfProcessorCores):
1333         * heap/MachineStackMarker.h:
1334         (JSC::MachineThreads::addCurrentThread):
1335         * runtime/JSLock.cpp:
1336         (JSC::JSLock::didAcquireLock):
1337         * runtime/Options.cpp:
1338         (JSC::computeNumberOfWorkerThreads):
1339         (JSC::computePriorityDeltaOfWorkerThreads):
1340         * wasm/WasmWorklist.cpp:
1341         (JSC::Wasm::Worklist::Worklist):
1342
1343 2019-04-12  Robin Morisset  <rmorisset@apple.com>
1344
1345         Use padding at end of ArrayBuffer
1346         https://bugs.webkit.org/show_bug.cgi?id=196823
1347
1348         Reviewed by Filip Pizlo.
1349
1350         * runtime/ArrayBuffer.h:
1351
1352 2019-04-11  Yusuke Suzuki  <ysuzuki@apple.com>
1353
1354         [JSC] op_has_indexed_property should not assume subscript part is Uint32
1355         https://bugs.webkit.org/show_bug.cgi?id=196850
1356
1357         Reviewed by Saam Barati.
1358
1359         op_has_indexed_property assumed that subscript part is always Uint32. However, this is just a load from non-constant RegisterID,
1360         DFG can store it in double format and can perform OSR exit. op_has_indexed_property should not assume that.
1361         In this patch, instead, we check it with isAnyInt and get uint32_t from AnyInt.
1362
1363         * jit/JITOpcodes.cpp:
1364         (JSC::JIT::emit_op_has_indexed_property):
1365         * jit/JITOpcodes32_64.cpp:
1366         (JSC::JIT::emit_op_has_indexed_property):
1367         * jit/JITOperations.cpp:
1368         * runtime/CommonSlowPaths.cpp:
1369         (JSC::SLOW_PATH_DECL):
1370
1371 2019-04-11  Saam barati  <sbarati@apple.com>
1372
1373         Remove invalid assertion in operationInstanceOfCustom
1374         https://bugs.webkit.org/show_bug.cgi?id=196842
1375         <rdar://problem/49725493>
1376
1377         Reviewed by Michael Saboff.
1378
1379         In the generated JIT code, we go to the slow path when the incoming function
1380         isn't the Node's CodeOrigin's functionProtoHasInstanceSymbolFunction. However,
1381         in the JIT operation, we were asserting against exec->lexicalGlobalObject()'s
1382         functionProtoHasInstanceSymbolFunction. That assertion might be wrong when
1383         inlining across global objects as exec->lexicalGlobalObject() uses the machine
1384         frame for procuring the global object. There is no harm when this assertion fails
1385         as we just execute the slow path. This patch removes the assertion. (However, this
1386         does shed light on the deficiency in our exec->lexicalGlobalObject() function with
1387         respect to inlining. However, this isn't new -- we've known about this for a while.)
1388
1389         * jit/JITOperations.cpp:
1390
1391 2019-04-11  Michael Saboff  <msaboff@apple.com>
1392
1393         Improve the Inline Cache Stats code
1394         https://bugs.webkit.org/show_bug.cgi?id=196836
1395
1396         Reviewed by Saam Barati.
1397
1398         Needed to handle the case where the Identifier could be null, for example with InstanceOfAddAccessCase
1399         and InstanceOfReplaceWithJump.
1400
1401         Added the ability to log the location of a GetBy and PutBy property as either on self or up the
1402         protocol chain.
1403
1404         * jit/ICStats.cpp:
1405         (JSC::ICEvent::operator< const):
1406         (JSC::ICEvent::dump const):
1407         * jit/ICStats.h:
1408         (JSC::ICEvent::ICEvent):
1409         (JSC::ICEvent::hash const):
1410         * jit/JITOperations.cpp:
1411         * jit/Repatch.cpp:
1412         (JSC::tryCacheGetByID):
1413         (JSC::tryCachePutByID):
1414         (JSC::tryCacheInByID):
1415
1416 2019-04-11  Devin Rousso  <drousso@apple.com>
1417
1418         Web Inspector: Timelines: can't reliably stop/start a recording
1419         https://bugs.webkit.org/show_bug.cgi?id=196778
1420         <rdar://problem/47606798>
1421
1422         Reviewed by Timothy Hatcher.
1423
1424         * inspector/protocol/ScriptProfiler.json:
1425         * inspector/protocol/Timeline.json:
1426         It is possible to determine when programmatic capturing starts/stops in the frontend based
1427         on the state when the backend causes the state to change, such as if the state is "inactive"
1428         when the frontend is told that the backend has started capturing.
1429
1430         * inspector/protocol/CPUProfiler.json:
1431         * inspector/protocol/Memory.json:
1432         Send an end timestamp to match other instruments.
1433
1434         * inspector/JSGlobalObjectConsoleClient.cpp:
1435         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1436         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1437
1438         * inspector/agents/InspectorScriptProfilerAgent.h:
1439         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1440         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
1441         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
1442         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
1443
1444 2019-04-11  Saam barati  <sbarati@apple.com>
1445
1446         Rename SetArgument to SetArgumentDefinitely
1447         https://bugs.webkit.org/show_bug.cgi?id=196828
1448
1449         Reviewed by Yusuke Suzuki.
1450
1451         This is in preparation for https://bugs.webkit.org/show_bug.cgi?id=196712
1452         where we will introduce a node named SetArgumentMaybe. Doing this refactoring
1453         first will make reviewing that other patch easier.
1454
1455         * dfg/DFGAbstractInterpreterInlines.h:
1456         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1457         * dfg/DFGByteCodeParser.cpp:
1458         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
1459         (JSC::DFG::ByteCodeParser::parseBlock):
1460         * dfg/DFGCPSRethreadingPhase.cpp:
1461         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
1462         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
1463         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1464         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1465         (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
1466         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
1467         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
1468         * dfg/DFGClobberize.h:
1469         (JSC::DFG::clobberize):
1470         * dfg/DFGCommon.h:
1471         * dfg/DFGDoesGC.cpp:
1472         (JSC::DFG::doesGC):
1473         * dfg/DFGFixupPhase.cpp:
1474         (JSC::DFG::FixupPhase::fixupNode):
1475         * dfg/DFGGraph.cpp:
1476         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1477         * dfg/DFGGraph.h:
1478         * dfg/DFGInPlaceAbstractState.cpp:
1479         (JSC::DFG::InPlaceAbstractState::initialize):
1480         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
1481         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
1482         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
1483         * dfg/DFGMaximalFlushInsertionPhase.cpp:
1484         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
1485         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
1486         * dfg/DFGMayExit.cpp:
1487         * dfg/DFGNode.cpp:
1488         (JSC::DFG::Node::hasVariableAccessData):
1489         * dfg/DFGNode.h:
1490         (JSC::DFG::Node::convertPhantomToPhantomLocal):
1491         * dfg/DFGNodeType.h:
1492         * dfg/DFGOSREntrypointCreationPhase.cpp:
1493         (JSC::DFG::OSREntrypointCreationPhase::run):
1494         * dfg/DFGPhantomInsertionPhase.cpp:
1495         * dfg/DFGPredictionPropagationPhase.cpp:
1496         * dfg/DFGSSAConversionPhase.cpp:
1497         (JSC::DFG::SSAConversionPhase::run):
1498         * dfg/DFGSafeToExecute.h:
1499         (JSC::DFG::safeToExecute):
1500         * dfg/DFGSpeculativeJIT.cpp:
1501         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
1502         * dfg/DFGSpeculativeJIT32_64.cpp:
1503         (JSC::DFG::SpeculativeJIT::compile):
1504         * dfg/DFGSpeculativeJIT64.cpp:
1505         (JSC::DFG::SpeculativeJIT::compile):
1506         * dfg/DFGTypeCheckHoistingPhase.cpp:
1507         (JSC::DFG::TypeCheckHoistingPhase::run):
1508         * dfg/DFGValidate.cpp:
1509         * ftl/FTLCapabilities.cpp:
1510         (JSC::FTL::canCompile):
1511
1512 2019-04-11  Truitt Savell  <tsavell@apple.com>
1513
1514         Unreviewed, rolling out r244158.
1515
1516         Casued 8 inspector/timeline/ test failures.
1517
1518         Reverted changeset:
1519
1520         "Web Inspector: Timelines: can't reliably stop/start a
1521         recording"
1522         https://bugs.webkit.org/show_bug.cgi?id=196778
1523         https://trac.webkit.org/changeset/244158
1524
1525 2019-04-10  Saam Barati  <sbarati@apple.com>
1526
1527         AbstractValue::validateOSREntryValue is wrong for Int52 constants
1528         https://bugs.webkit.org/show_bug.cgi?id=196801
1529         <rdar://problem/49771122>
1530
1531         Reviewed by Yusuke Suzuki.
1532
1533         validateOSREntryValue should not care about the format of the incoming
1534         value for Int52s. This patch normalizes the format of m_value and
1535         the incoming value when comparing them.
1536
1537         * dfg/DFGAbstractValue.h:
1538         (JSC::DFG::AbstractValue::validateOSREntryValue const):
1539
1540 2019-04-10  Saam Barati  <sbarati@apple.com>
1541
1542         ArithSub over Int52 has shouldCheckOverflow as always true
1543         https://bugs.webkit.org/show_bug.cgi?id=196796
1544
1545         Reviewed by Yusuke Suzuki.
1546
1547         AI was checking for ArithSub over Int52 if !shouldCheckOverflow. However,
1548         shouldCheckOverflow is always true, so !shouldCheckOverflow is always
1549         false. We shouldn't check something we assert against.
1550
1551         * dfg/DFGAbstractInterpreterInlines.h:
1552         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1553
1554 2019-04-10  Basuke Suzuki  <basuke.suzuki@sony.com>
1555
1556         [PlayStation] Specify byte order clearly on Remote Inspector Protocol
1557         https://bugs.webkit.org/show_bug.cgi?id=196790
1558
1559         Reviewed by Ross Kirsling.
1560
1561         Original implementation lacks byte order specification. Network byte order is the
1562         good candidate if there's no strong reason to choose other.
1563         Currently no client exists for PlayStation remote inspector protocol, so we can
1564         change the byte order without care.
1565
1566         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp:
1567         (Inspector::MessageParser::createMessage):
1568         (Inspector::MessageParser::parse):
1569
1570 2019-04-10  Devin Rousso  <drousso@apple.com>
1571
1572        Web Inspector: Inspector: lazily create the agent
1573        https://bugs.webkit.org/show_bug.cgi?id=195971
1574        <rdar://problem/49039645>
1575
1576        Reviewed by Joseph Pecoraro.
1577
1578        * inspector/JSGlobalObjectInspectorController.cpp:
1579        (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1580        (Inspector::JSGlobalObjectInspectorController::connectFrontend):
1581        (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
1582        (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
1583
1584        * inspector/agents/InspectorAgent.h:
1585        * inspector/agents/InspectorAgent.cpp:
1586
1587 2019-04-10  Saam Barati  <sbarati@apple.com>
1588
1589         Work around an arm64_32 LLVM miscompile bug
1590         https://bugs.webkit.org/show_bug.cgi?id=196788
1591
1592         Reviewed by Yusuke Suzuki.
1593
1594         * runtime/CachedTypes.cpp:
1595
1596 2019-04-10  Devin Rousso  <drousso@apple.com>
1597
1598         Web Inspector: Timelines: can't reliably stop/start a recording
1599         https://bugs.webkit.org/show_bug.cgi?id=196778
1600         <rdar://problem/47606798>
1601
1602         Reviewed by Timothy Hatcher.
1603
1604         * inspector/protocol/ScriptProfiler.json:
1605         * inspector/protocol/Timeline.json:
1606         It is possible to determine when programmatic capturing starts/stops in the frontend based
1607         on the state when the backend causes the state to change, such as if the state is "inactive"
1608         when the frontend is told that the backend has started capturing.
1609
1610         * inspector/protocol/CPUProfiler.json:
1611         * inspector/protocol/Memory.json:
1612         Send an end timestamp to match other instruments.
1613
1614         * inspector/JSGlobalObjectConsoleClient.cpp:
1615         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1616         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1617
1618         * inspector/agents/InspectorScriptProfilerAgent.h:
1619         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1620         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
1621         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): Deleted.
1622         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): Deleted.
1623
1624 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
1625
1626         Unreviewed, fix watch build after r244143
1627         https://bugs.webkit.org/show_bug.cgi?id=195000
1628
1629         The result of `lseek` should be `off_t` rather than `int`.
1630
1631         * jsc.cpp:
1632
1633 2019-04-10  Tadeu Zagallo  <tzagallo@apple.com>
1634
1635         Add support for incremental bytecode cache updates
1636         https://bugs.webkit.org/show_bug.cgi?id=195000
1637
1638         Reviewed by Filip Pizlo.
1639
1640         Add support for incremental updates to the bytecode cache. The cache
1641         is constructed as follows:
1642         - When the cache is empty, the initial payload can be added to the BytecodeCache
1643         by calling BytecodeCache::addGlobalUpdate. This represents the encoded
1644         top-level UnlinkedCodeBlock.
1645         - Afterwards, updates can be added by calling BytecodeCache::addFunctionUpdate.
1646         The update is applied by appending the encoded UnlinkedFunctionCodeBlock
1647         to the existing cache and updating the CachedFunctionExecutableMetadata
1648         and the offset of the new CachedFunctionCodeBlock in the owner CachedFunctionExecutable.
1649
1650         * API/JSScript.mm:
1651         (-[JSScript readCache]):
1652         (-[JSScript isUsingBytecodeCache]):
1653         (-[JSScript init]):
1654         (-[JSScript cachedBytecode]):
1655         (-[JSScript writeCache:]):
1656         * API/JSScriptInternal.h:
1657         * API/JSScriptSourceProvider.h:
1658         * API/JSScriptSourceProvider.mm:
1659         (JSScriptSourceProvider::cachedBytecode const):
1660         * CMakeLists.txt:
1661         * JavaScriptCore.xcodeproj/project.pbxproj:
1662         * Sources.txt:
1663         * bytecode/UnlinkedFunctionExecutable.cpp:
1664         (JSC::generateUnlinkedFunctionCodeBlock):
1665         * jsc.cpp:
1666         (ShellSourceProvider::~ShellSourceProvider):
1667         (ShellSourceProvider::cachePath const):
1668         (ShellSourceProvider::loadBytecode const):
1669         (ShellSourceProvider::ShellSourceProvider):
1670         (ShellSourceProvider::cacheEnabled):
1671         * parser/SourceProvider.h:
1672         (JSC::SourceProvider::cachedBytecode const):
1673         (JSC::SourceProvider::updateCache const):
1674         (JSC::SourceProvider::commitCachedBytecode const):
1675         * runtime/CachePayload.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
1676         (JSC::CachePayload::makeMappedPayload):
1677         (JSC::CachePayload::makeMallocPayload):
1678         (JSC::CachePayload::makeEmptyPayload):
1679         (JSC::CachePayload::CachePayload):
1680         (JSC::CachePayload::~CachePayload):
1681         (JSC::CachePayload::operator=):
1682         (JSC::CachePayload::freeData):
1683         * runtime/CachePayload.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
1684         (JSC::CachePayload::data const):
1685         (JSC::CachePayload::size const):
1686         (JSC::CachePayload::CachePayload):
1687         * runtime/CacheUpdate.cpp: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
1688         (JSC::CacheUpdate::CacheUpdate):
1689         (JSC::CacheUpdate::operator=):
1690         (JSC::CacheUpdate::isGlobal const):
1691         (JSC::CacheUpdate::asGlobal const):
1692         (JSC::CacheUpdate::asFunction const):
1693         * runtime/CacheUpdate.h: Copied from Source/JavaScriptCore/API/JSScriptInternal.h.
1694         * runtime/CachedBytecode.cpp: Added.
1695         (JSC::CachedBytecode::addGlobalUpdate):
1696         (JSC::CachedBytecode::addFunctionUpdate):
1697         (JSC::CachedBytecode::copyLeafExecutables):
1698         (JSC::CachedBytecode::commitUpdates const):
1699         * runtime/CachedBytecode.h: Added.
1700         (JSC::CachedBytecode::create):
1701         (JSC::CachedBytecode::leafExecutables):
1702         (JSC::CachedBytecode::data const):
1703         (JSC::CachedBytecode::size const):
1704         (JSC::CachedBytecode::hasUpdates const):
1705         (JSC::CachedBytecode::sizeForUpdate const):
1706         (JSC::CachedBytecode::CachedBytecode):
1707         * runtime/CachedTypes.cpp:
1708         (JSC::Encoder::addLeafExecutable):
1709         (JSC::Encoder::release):
1710         (JSC::Decoder::Decoder):
1711         (JSC::Decoder::create):
1712         (JSC::Decoder::size const):
1713         (JSC::Decoder::offsetOf):
1714         (JSC::Decoder::ptrForOffsetFromBase):
1715         (JSC::Decoder::addLeafExecutable):
1716         (JSC::VariableLengthObject::VariableLengthObject):
1717         (JSC::VariableLengthObject::buffer const):
1718         (JSC::CachedPtrOffsets::offsetOffset):
1719         (JSC::CachedWriteBarrierOffsets::ptrOffset):
1720         (JSC::CachedFunctionExecutable::features const):
1721         (JSC::CachedFunctionExecutable::hasCapturedVariables const):
1722         (JSC::CachedFunctionExecutableOffsets::codeBlockForCallOffset):
1723         (JSC::CachedFunctionExecutableOffsets::codeBlockForConstructOffset):
1724         (JSC::CachedFunctionExecutableOffsets::metadataOffset):
1725         (JSC::CachedFunctionExecutable::encode):
1726         (JSC::CachedFunctionExecutable::decode const):
1727         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1728         (JSC::encodeCodeBlock):
1729         (JSC::encodeFunctionCodeBlock):
1730         (JSC::decodeCodeBlockImpl):
1731         (JSC::isCachedBytecodeStillValid):
1732         * runtime/CachedTypes.h:
1733         (JSC::VariableLengthObjectBase::VariableLengthObjectBase):
1734         (JSC::decodeCodeBlock):
1735         * runtime/CodeCache.cpp:
1736         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
1737         (JSC::CodeCache::updateCache):
1738         (JSC::CodeCache::write):
1739         (JSC::writeCodeBlock):
1740         (JSC::serializeBytecode):
1741         * runtime/CodeCache.h:
1742         (JSC::SourceCodeValue::SourceCodeValue):
1743         (JSC::CodeCacheMap::findCacheAndUpdateAge):
1744         (JSC::CodeCacheMap::fetchFromDiskImpl):
1745         * runtime/Completion.cpp:
1746         (JSC::generateProgramBytecode):
1747         (JSC::generateModuleBytecode):
1748         * runtime/Completion.h:
1749         * runtime/LeafExecutable.cpp: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
1750         (JSC::LeafExecutable::operator+ const):
1751         * runtime/LeafExecutable.h: Copied from Source/JavaScriptCore/API/JSScriptSourceProvider.mm.
1752         (JSC::LeafExecutable::LeafExecutable):
1753         (JSC::LeafExecutable::base const):
1754
1755 2019-04-10  Michael Catanzaro  <mcatanzaro@igalia.com>
1756
1757         Unreviewed, rolling out r243989.
1758
1759         Broke i686 builds
1760
1761         Reverted changeset:
1762
1763         "[CMake] Detect SSE2 at compile time"
1764         https://bugs.webkit.org/show_bug.cgi?id=196488
1765         https://trac.webkit.org/changeset/243989
1766
1767 2019-04-10  Robin Morisset  <rmorisset@apple.com>
1768
1769         We should clear m_needsOverflowCheck when hitting an exception in defineProperties in ObjectConstructor.cpp
1770         https://bugs.webkit.org/show_bug.cgi?id=196746
1771
1772         Reviewed by Yusuke Suzuki..
1773
1774         It should be safe as in that case we are not completing the operation, and so not going to have any buffer overflow.
1775
1776         * runtime/ObjectConstructor.cpp:
1777         (JSC::defineProperties):
1778
1779 2019-04-10  Antoine Quint  <graouts@apple.com>
1780
1781         Enable Pointer Events on watchOS
1782         https://bugs.webkit.org/show_bug.cgi?id=196771
1783         <rdar://problem/49040909>
1784
1785         Reviewed by Dean Jackson.
1786
1787         * Configurations/FeatureDefines.xcconfig:
1788
1789 2019-04-09  Keith Rollin  <krollin@apple.com>
1790
1791         Unreviewed build maintenance -- update .xcfilelists.
1792
1793         * DerivedSources-input.xcfilelist:
1794
1795 2019-04-09  Ross Kirsling  <ross.kirsling@sony.com>
1796
1797         JSC should build successfully even with -DENABLE_UNIFIED_BUILDS=OFF
1798         https://bugs.webkit.org/show_bug.cgi?id=193073
1799
1800         Reviewed by Keith Miller.
1801
1802         * bytecompiler/BytecodeGenerator.cpp:
1803         (JSC::BytecodeGenerator::emitEqualityOpImpl):
1804         (JSC::BytecodeGenerator::emitEqualityOp): Deleted.
1805         * bytecompiler/BytecodeGenerator.h:
1806         (JSC::BytecodeGenerator::emitEqualityOp):
1807         Factor out the logic that uses the template parameter and keep it in the header.
1808
1809         * jit/JITPropertyAccess.cpp:
1810         List off the template specializations needed by JITOperations.cpp.
1811         This is unfortunate but at least there are only two (x2) by definition?
1812         Trying to do away with this incurs a severe domino effect...
1813
1814         * API/JSValueRef.cpp:
1815         * b3/B3OptimizeAssociativeExpressionTrees.cpp:
1816         * b3/air/AirHandleCalleeSaves.cpp:
1817         * builtins/BuiltinNames.cpp:
1818         * bytecode/AccessCase.cpp:
1819         * bytecode/BytecodeIntrinsicRegistry.cpp:
1820         * bytecode/BytecodeIntrinsicRegistry.h:
1821         * bytecode/BytecodeRewriter.cpp:
1822         * bytecode/BytecodeUseDef.h:
1823         * bytecode/CodeBlock.cpp:
1824         * bytecode/InstanceOfAccessCase.cpp:
1825         * bytecode/MetadataTable.cpp:
1826         * bytecode/PolyProtoAccessChain.cpp:
1827         * bytecode/StructureSet.cpp:
1828         * bytecompiler/NodesCodegen.cpp:
1829         * dfg/DFGCFAPhase.cpp:
1830         * dfg/DFGPureValue.cpp:
1831         * heap/GCSegmentedArray.h:
1832         * heap/HeapInlines.h:
1833         * heap/IsoSubspace.cpp:
1834         * heap/LocalAllocator.cpp:
1835         * heap/LocalAllocator.h:
1836         * heap/LocalAllocatorInlines.h:
1837         * heap/MarkingConstraintSolver.cpp:
1838         * inspector/ScriptArguments.cpp:
1839         (Inspector::ScriptArguments::isEqual const):
1840         * inspector/ScriptCallStackFactory.cpp:
1841         * interpreter/CallFrame.h:
1842         * interpreter/Interpreter.cpp:
1843         * interpreter/StackVisitor.cpp:
1844         * llint/LLIntEntrypoint.cpp:
1845         * runtime/ArrayIteratorPrototype.cpp:
1846         * runtime/BigIntPrototype.cpp:
1847         * runtime/CachedTypes.cpp:
1848         * runtime/ErrorType.cpp:
1849         * runtime/IndexingType.cpp:
1850         * runtime/JSCellInlines.h:
1851         * runtime/JSImmutableButterfly.h:
1852         * runtime/Operations.h:
1853         * runtime/RegExpCachedResult.cpp:
1854         * runtime/RegExpConstructor.cpp:
1855         * runtime/RegExpGlobalData.cpp:
1856         * runtime/StackFrame.h:
1857         * wasm/WasmSignature.cpp:
1858         * wasm/js/JSToWasm.cpp:
1859         * wasm/js/JSToWasmICCallee.cpp:
1860         * wasm/js/WebAssemblyFunction.h:
1861         Fix includes / forward declarations (and a couple of nearby clang warnings).
1862
1863 2019-04-09  Don Olmstead  <don.olmstead@sony.com>
1864
1865         [CMake] Apple builds should use ICU_INCLUDE_DIRS
1866         https://bugs.webkit.org/show_bug.cgi?id=196720
1867
1868         Reviewed by Konstantin Tokarev.
1869
1870         * PlatformMac.cmake:
1871
1872 2019-04-09  Saam barati  <sbarati@apple.com>
1873
1874         Clean up Int52 code and some bugs in it
1875         https://bugs.webkit.org/show_bug.cgi?id=196639
1876         <rdar://problem/49515757>
1877
1878         Reviewed by Yusuke Suzuki.
1879
1880         This patch fixes bugs in our Int52 code. The primary change in this patch is
1881         adopting a segregated type lattice for Int52. Previously, for Int52 values,
1882         we represented them with SpecInt32Only and SpecInt52Only. For an Int52,
1883         SpecInt32Only meant that the value is in int32 range. And SpecInt52Only meant
1884         that the is outside of the int32 range.
1885         
1886         However, this got confusing because we reused SpecInt32Only both for JSValue
1887         representations and Int52 representations. This actually lead to some bugs.
1888         
1889         1. It's possible that roundtripping through Int52 representation would say
1890         it produces the wrong type. For example, consider this program and how we
1891         used to annotate types in AI:
1892         a: JSConstant(10.0) => m_type is SpecAnyIntAsDouble
1893         b: Int52Rep(@a) => m_type is SpecInt52Only
1894         c: ValueRep(@b) => m_type is SpecAnyIntAsDouble
1895         
1896         In AI, for the above program, we'd say that @c produces SpecAnyIntAsDouble.
1897         However, the execution semantics are such that it'd actually produce a boxed
1898         Int32. This patch fixes the bug where we'd say that Int52Rep over SpecAnyIntAsDouble
1899         would produce SpecInt52Only. This is clearly wrong, as SpecAnyIntAsDouble can
1900         mean an int value in either int32 or int52 range.
1901         
1902         2. AsbstractValue::validateTypeAcceptingBoxedInt52 was wrong in how it
1903         accepted Int52 values. It was wrong in two different ways:
1904         a: If the AbstractValue's type was SpecInt52Only, and the incoming value
1905         was a boxed double, but represented a value in int32 range, the incoming
1906         value would incorrectly validate as being acceptable. However, we should
1907         have rejected this value.
1908         b: If the AbstractValue's type was SpecInt32Only, and the incoming value
1909         was an Int32 boxed in a double, this would not validate, even though
1910         it should have validated.
1911         
1912         Solving 2 was easiest if we segregated out the Int52 type into its own
1913         lattice. This patch makes a new Int52 lattice, which is composed of
1914         SpecInt32AsInt52 and SpecNonInt32AsInt52.
1915         
1916         The conversion rules are now really simple.
1917         
1918         Int52 rep => JSValue rep
1919         SpecInt32AsInt52 => SpecInt32Only
1920         SpecNonInt32AsInt52 => SpecAnyIntAsDouble
1921         
1922         JSValue rep => Int52 rep
1923         SpecInt32Only => SpecInt32AsInt52
1924         SpecAnyIntAsDouble => SpecInt52Any
1925         
1926         With these rules, the program in (1) will now correctly report that @c
1927         returns SpecInt32Only | SpecAnyIntAsDouble.
1928
1929         * bytecode/SpeculatedType.cpp:
1930         (JSC::dumpSpeculation):
1931         (JSC::speculationToAbbreviatedString):
1932         (JSC::int52AwareSpeculationFromValue):
1933         (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
1934         (JSC::speculationFromString):
1935         * bytecode/SpeculatedType.h:
1936         (JSC::isInt32SpeculationForArithmetic):
1937         (JSC::isInt32OrBooleanSpeculationForArithmetic):
1938         (JSC::isAnyInt52Speculation):
1939         (JSC::isIntAnyFormat):
1940         (JSC::isInt52Speculation): Deleted.
1941         (JSC::isAnyIntSpeculation): Deleted.
1942         * dfg/DFGAbstractInterpreterInlines.h:
1943         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1944         * dfg/DFGAbstractValue.cpp:
1945         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
1946         (JSC::DFG::AbstractValue::checkConsistency const):
1947         * dfg/DFGAbstractValue.h:
1948         (JSC::DFG::AbstractValue::isInt52Any const):
1949         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
1950         * dfg/DFGFixupPhase.cpp:
1951         (JSC::DFG::FixupPhase::fixupArithMul):
1952         (JSC::DFG::FixupPhase::fixupNode):
1953         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1954         (JSC::DFG::FixupPhase::fixupToThis):
1955         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
1956         (JSC::DFG::FixupPhase::observeUseKindOnNode):
1957         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1958         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
1959         (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
1960         (JSC::DFG::FixupPhase::fixupChecksInBlock):
1961         * dfg/DFGGraph.h:
1962         (JSC::DFG::Graph::addShouldSpeculateInt52):
1963         (JSC::DFG::Graph::binaryArithShouldSpeculateInt52):
1964         (JSC::DFG::Graph::unaryArithShouldSpeculateInt52):
1965         (JSC::DFG::Graph::addShouldSpeculateAnyInt): Deleted.
1966         (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): Deleted.
1967         (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): Deleted.
1968         * dfg/DFGNode.h:
1969         (JSC::DFG::Node::shouldSpeculateInt52):
1970         (JSC::DFG::Node::shouldSpeculateAnyInt): Deleted.
1971         * dfg/DFGPredictionPropagationPhase.cpp:
1972         * dfg/DFGSpeculativeJIT.cpp:
1973         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
1974         (JSC::DFG::SpeculativeJIT::compileArithAdd):
1975         (JSC::DFG::SpeculativeJIT::compileArithSub):
1976         (JSC::DFG::SpeculativeJIT::compileArithNegate):
1977         * dfg/DFGSpeculativeJIT64.cpp:
1978         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
1979         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
1980         * dfg/DFGUseKind.h:
1981         (JSC::DFG::typeFilterFor):
1982         * dfg/DFGVariableAccessData.cpp:
1983         (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
1984         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
1985         * ftl/FTLLowerDFGToB3.cpp:
1986         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1987         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
1988         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
1989
1990 2019-04-09  Tadeu Zagallo  <tzagallo@apple.com>
1991
1992         ASSERTION FAILED: !scope.exception() || !hasProperty in JSObject::get
1993         https://bugs.webkit.org/show_bug.cgi?id=196708
1994         <rdar://problem/49556803>
1995
1996         Reviewed by Yusuke Suzuki.
1997
1998         `operationPutToScope` needs to return early if an exception is thrown while
1999         checking if `hasProperty`.
2000
2001         * jit/JITOperations.cpp:
2002
2003 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
2004
2005         [JSC] DFG should respect node's strict flag
2006         https://bugs.webkit.org/show_bug.cgi?id=196617
2007
2008         Reviewed by Saam Barati.
2009
2010         We accidentally use codeBlock->isStrictMode() directly in DFG and FTL. But this is wrong since this CodeBlock is the top level DFG/FTL CodeBlock,
2011         and this code does not respect the isStrictMode flag for the inlined CodeBlocks. In this patch, we start using isStrictModeFor(CodeOrigin) consistently
2012         in DFG and FTL to get the right isStrictMode flag for the DFG node.
2013         And we also split compilePutDynamicVar into compilePutDynamicVarStrict and compilePutDynamicVarNonStrict since (1) it is cleaner than accessing inlined
2014         callframe in the operation function, and (2) it is aligned to the other functions like operationPutByValDirectNonStrict etc.
2015         This bug is discovered by RandomizingFuzzerAgent by expanding the DFG coverage.
2016
2017         * dfg/DFGAbstractInterpreterInlines.h:
2018         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2019         * dfg/DFGConstantFoldingPhase.cpp:
2020         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2021         * dfg/DFGFixupPhase.cpp:
2022         (JSC::DFG::FixupPhase::fixupToThis):
2023         * dfg/DFGOperations.cpp:
2024         * dfg/DFGOperations.h:
2025         * dfg/DFGPredictionPropagationPhase.cpp:
2026         * dfg/DFGSpeculativeJIT.cpp:
2027         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
2028         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
2029         (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
2030         (JSC::DFG::SpeculativeJIT::compileToThis):
2031         * dfg/DFGSpeculativeJIT32_64.cpp:
2032         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
2033         (JSC::DFG::SpeculativeJIT::compile):
2034         * dfg/DFGSpeculativeJIT64.cpp:
2035         (JSC::DFG::SpeculativeJIT::compile):
2036         * ftl/FTLLowerDFGToB3.cpp:
2037         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
2038         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
2039
2040 2019-04-08  Don Olmstead  <don.olmstead@sony.com>
2041
2042         [CMake][WinCairo] Separate copied headers into different directories
2043         https://bugs.webkit.org/show_bug.cgi?id=196655
2044
2045         Reviewed by Michael Catanzaro.
2046
2047         * CMakeLists.txt:
2048         * shell/PlatformWin.cmake:
2049
2050 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
2051
2052         [JSC] isRope jump in StringSlice should not jump over register allocations
2053         https://bugs.webkit.org/show_bug.cgi?id=196716
2054
2055         Reviewed by Saam Barati.
2056
2057         Jumping over the register allocation code in DFG (like the following) is wrong.
2058
2059             auto jump = m_jit.branchXXX();
2060             {
2061                 GPRTemporary reg(this);
2062                 GPRReg regGPR = reg.gpr();
2063                 ...
2064             }
2065             jump.link(&m_jit);
2066
2067         When GPRTemporary::gpr allocates a new register, it can flush the previous register value into the stack and make the register usable.
2068         Jumping over this register allocation code skips the flushing code, and makes the DFG's stack and register content tracking inconsistent:
2069         DFG thinks that the content is flushed and stored in particular stack slot even while this flushing code is skipped.
2070         In this patch, we perform register allocations before jumping to the slow path based on `isRope` condition in StringSlice.
2071
2072         * dfg/DFGSpeculativeJIT.cpp:
2073         (JSC::DFG::SpeculativeJIT::compileStringSlice):
2074
2075 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
2076
2077         [JSC] to_index_string should not assume incoming value is Uint32
2078         https://bugs.webkit.org/show_bug.cgi?id=196713
2079
2080         Reviewed by Saam Barati.
2081
2082         The slow path of to_index_string assumes that incoming value is Uint32. But we should not have
2083         this assumption since DFG may decide we should have it double format. This patch removes this
2084         assumption, and instead, we should assume that incoming value is AnyInt and the range of this
2085         is within Uint32.
2086
2087         * runtime/CommonSlowPaths.cpp:
2088         (JSC::SLOW_PATH_DECL):
2089
2090 2019-04-08  Justin Fan  <justin_fan@apple.com>
2091
2092         [Web GPU] Fix Web GPU experimental feature on iOS
2093         https://bugs.webkit.org/show_bug.cgi?id=196632
2094
2095         Reviewed by Myles C. Maxfield.
2096
2097         Properly make Web GPU available on iOS 11+.
2098
2099         * Configurations/FeatureDefines.xcconfig:
2100         * Configurations/WebKitTargetConditionals.xcconfig:
2101
2102 2019-04-08  Ross Kirsling  <ross.kirsling@sony.com>
2103
2104         -f[no-]var-tracking-assignments is GCC-only
2105         https://bugs.webkit.org/show_bug.cgi?id=196699
2106
2107         Reviewed by Don Olmstead.
2108
2109         * CMakeLists.txt:
2110         Just remove the build flag altogether -- it supposedly doesn't solve the problem it was meant to
2111         and said problem evidently no longer occurs as of GCC 9.
2112
2113 2019-04-08  Saam Barati  <sbarati@apple.com>
2114
2115         WebAssembly.RuntimeError missing exception check
2116         https://bugs.webkit.org/show_bug.cgi?id=196700
2117         <rdar://problem/49693932>
2118
2119         Reviewed by Yusuke Suzuki.
2120
2121         * wasm/js/JSWebAssemblyRuntimeError.h:
2122         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2123         (JSC::constructJSWebAssemblyRuntimeError):
2124
2125 2019-04-08  Yusuke Suzuki  <ysuzuki@apple.com>
2126
2127         Unreviewed, rolling in r243948 with test fix
2128         https://bugs.webkit.org/show_bug.cgi?id=196486
2129
2130         * parser/ASTBuilder.h:
2131         (JSC::ASTBuilder::createString):
2132         * parser/Lexer.cpp:
2133         (JSC::Lexer<T>::parseMultilineComment):
2134         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
2135         (JSC::Lexer<T>::lex): Deleted.
2136         * parser/Lexer.h:
2137         (JSC::Lexer::hasLineTerminatorBeforeToken const):
2138         (JSC::Lexer::setHasLineTerminatorBeforeToken):
2139         (JSC::Lexer<T>::lex):
2140         (JSC::Lexer::prevTerminator const): Deleted.
2141         (JSC::Lexer::setTerminator): Deleted.
2142         * parser/Parser.cpp:
2143         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
2144         (JSC::Parser<LexerType>::parseSingleFunction):
2145         (JSC::Parser<LexerType>::parseStatementListItem):
2146         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2147         (JSC::Parser<LexerType>::parseFunctionInfo):
2148         (JSC::Parser<LexerType>::parseClass):
2149         (JSC::Parser<LexerType>::parseExportDeclaration):
2150         (JSC::Parser<LexerType>::parseAssignmentExpression):
2151         (JSC::Parser<LexerType>::parseYieldExpression):
2152         (JSC::Parser<LexerType>::parseProperty):
2153         (JSC::Parser<LexerType>::parsePrimaryExpression):
2154         (JSC::Parser<LexerType>::parseMemberExpression):
2155         * parser/Parser.h:
2156         (JSC::Parser::nextWithoutClearingLineTerminator):
2157         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
2158         (JSC::Parser::internalSaveLexerState):
2159         (JSC::Parser::restoreLexerState):
2160
2161 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
2162
2163         Unreviewed, rolling out r243948.
2164
2165         Caused inspector/runtime/parse.html to fail
2166
2167         Reverted changeset:
2168
2169         "SIGSEGV in JSC::BytecodeGenerator::addStringConstant"
2170         https://bugs.webkit.org/show_bug.cgi?id=196486
2171         https://trac.webkit.org/changeset/243948
2172
2173 2019-04-08  Ryan Haddad  <ryanhaddad@apple.com>
2174
2175         Unreviewed, rolling out r243943.
2176
2177         Caused test262 failures.
2178
2179         Reverted changeset:
2180
2181         "[JSC] Filter DontEnum properties in
2182         ProxyObject::getOwnPropertyNames()"
2183         https://bugs.webkit.org/show_bug.cgi?id=176810
2184         https://trac.webkit.org/changeset/243943
2185
2186 2019-04-08  Claudio Saavedra  <csaavedra@igalia.com>
2187
2188         [JSC] Partially fix the build with unified builds disabled
2189         https://bugs.webkit.org/show_bug.cgi?id=196647
2190
2191         Reviewed by Konstantin Tokarev.
2192
2193         If you disable unified builds you find all kind of build
2194         errors. This partially tries to fix them but there's a lot
2195         more.
2196
2197         * API/JSBaseInternal.h:
2198         * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
2199         * b3/air/AirHandleCalleeSaves.h:
2200         * bytecode/ExecutableToCodeBlockEdge.cpp:
2201         * bytecode/ExitFlag.h:
2202         * bytecode/ICStatusUtils.h:
2203         * bytecode/UnlinkedMetadataTable.h:
2204         * dfg/DFGPureValue.h:
2205         * heap/IsoAlignedMemoryAllocator.cpp:
2206         * heap/IsoAlignedMemoryAllocator.h:
2207
2208 2019-04-08  Guillaume Emont  <guijemont@igalia.com>
2209
2210         Enable DFG on MIPS
2211         https://bugs.webkit.org/show_bug.cgi?id=196689
2212
2213         Reviewed by Žan Doberšek.
2214
2215         Since the bytecode change, we enabled the baseline JIT on mips in
2216         r240432, but DFG is still missing. With this change, all tests are
2217         passing on a ci20 board.
2218
2219         * jit/RegisterSet.cpp:
2220         (JSC::RegisterSet::calleeSaveRegisters):
2221         Added s0, which is used in llint.
2222
2223 2019-04-08  Xan Lopez  <xan@igalia.com>
2224
2225         [CMake] Detect SSE2 at compile time
2226         https://bugs.webkit.org/show_bug.cgi?id=196488
2227
2228         Reviewed by Carlos Garcia Campos.
2229
2230         * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
2231         incorrect) static_assert.
2232
2233 2019-04-07  Michael Saboff  <msaboff@apple.com>
2234
2235         REGRESSION (r243642): Crash in reddit.com page
2236         https://bugs.webkit.org/show_bug.cgi?id=196684
2237
2238         Reviewed by Geoffrey Garen.
2239
2240         In r243642, the code that saves and restores the count for non-greedy character classes
2241         was inadvertently put inside an if statement.  This code should be generated for all
2242         non-greedy character classes.
2243
2244         * yarr/YarrJIT.cpp:
2245         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
2246         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2247
2248 2019-04-07  Yusuke Suzuki  <ysuzuki@apple.com>
2249
2250         [JSC] CallLinkInfo should clear Callee or CodeBlock even if it is unlinked by jettison
2251         https://bugs.webkit.org/show_bug.cgi?id=196683
2252
2253         Reviewed by Saam Barati.
2254
2255         In r243626, we stop repatching CallLinkInfo when the CallLinkInfo is held by jettisoned CodeBlock.
2256         But we still need to clear the Callee or CodeBlock since they are now dead. Otherwise, CodeBlock's
2257         visitWeak eventually accesses this dead cells and crashes because the owner CodeBlock of CallLinkInfo
2258         can be still live.
2259
2260         We also move all repatching operations from CallLinkInfo.cpp to Repatch.cpp for consistency because the
2261         other repatching operations in CallLinkInfo are implemented in Repatch.cpp side.
2262
2263         * bytecode/CallLinkInfo.cpp:
2264         (JSC::CallLinkInfo::setCallee):
2265         (JSC::CallLinkInfo::clearCallee):
2266         * jit/Repatch.cpp:
2267         (JSC::linkFor):
2268         (JSC::revertCall):
2269
2270 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
2271
2272         [JSC] OSRExit recovery for SpeculativeAdd does not consier "A = A + A" pattern
2273         https://bugs.webkit.org/show_bug.cgi?id=196582
2274
2275         Reviewed by Saam Barati.
2276
2277         In DFG, our ArithAdd with overflow is executed speculatively, and we recover the value when overflow flag is set.
2278         The recovery is subtracting the operand from the destination to get the original two operands. Our recovery code
2279         handles A + B = A, A + B = B cases. But it misses A + A = A case (here, A and B are GPRReg). Our recovery code
2280         attempts to produce the original operand by performing A - A, and it always produces zero accidentally.
2281
2282         This patch adds the recovery code for A + A = A case. Because we know that this ArithAdd overflows, and operands were
2283         same values, we can calculate the original operand from the destination value by `((int32_t)value >> 1) ^ 0x80000000`.
2284
2285         We also found that FTL recovery code is dead. We remove them in this patch.
2286
2287         * dfg/DFGOSRExit.cpp:
2288         (JSC::DFG::OSRExit::executeOSRExit):
2289         (JSC::DFG::OSRExit::compileExit):
2290         * dfg/DFGOSRExit.h:
2291         (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
2292         * dfg/DFGSpeculativeJIT.cpp:
2293         (JSC::DFG::SpeculativeJIT::compileArithAdd):
2294         * ftl/FTLExitValue.cpp:
2295         (JSC::FTL::ExitValue::dataFormat const):
2296         (JSC::FTL::ExitValue::dumpInContext const):
2297         * ftl/FTLExitValue.h:
2298         (JSC::FTL::ExitValue::isArgument const):
2299         (JSC::FTL::ExitValue::hasIndexInStackmapLocations const):
2300         (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
2301         (JSC::FTL::ExitValue::recovery): Deleted.
2302         (JSC::FTL::ExitValue::isRecovery const): Deleted.
2303         (JSC::FTL::ExitValue::leftRecoveryArgument const): Deleted.
2304         (JSC::FTL::ExitValue::rightRecoveryArgument const): Deleted.
2305         (JSC::FTL::ExitValue::recoveryFormat const): Deleted.
2306         (JSC::FTL::ExitValue::recoveryOpcode const): Deleted.
2307         * ftl/FTLLowerDFGToB3.cpp:
2308         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2309         (JSC::FTL::DFG::LowerDFGToB3::preparePatchpointForExceptions):
2310         (JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
2311         (JSC::FTL::DFG::LowerDFGToB3::exitValueForNode):
2312         (JSC::FTL::DFG::LowerDFGToB3::addAvailableRecovery): Deleted.
2313         * ftl/FTLOSRExitCompiler.cpp:
2314         (JSC::FTL::compileRecovery):
2315
2316 2019-04-05  Ryan Haddad  <ryanhaddad@apple.com>
2317
2318         Unreviewed, rolling out r243665.
2319
2320         Caused iOS JSC tests to exit with an exception.
2321
2322         Reverted changeset:
2323
2324         "Assertion failed in JSC::createError"
2325         https://bugs.webkit.org/show_bug.cgi?id=196305
2326         https://trac.webkit.org/changeset/243665
2327
2328 2019-04-05  Yusuke Suzuki  <ysuzuki@apple.com>
2329
2330         SIGSEGV in JSC::BytecodeGenerator::addStringConstant
2331         https://bugs.webkit.org/show_bug.cgi?id=196486
2332
2333         Reviewed by Saam Barati.
2334
2335         When parsing a FunctionExpression / FunctionDeclaration etc., we use SyntaxChecker for the body of the function because we do not have any interest on the nodes of the body at that time.
2336         The nodes will be parsed with the ASTBuilder when the function itself is parsed for code generation. This works well previously because all the function ends with "}" previously.
2337         SyntaxChecker lexes this "}" token, and parser restores the context back to ASTBuilder and continues parsing.
2338
2339         But now, we have ArrowFunctionExpression without braces `arrow => expr`. Let's consider the following code.
2340
2341                 arrow => expr
2342                 "string!"
2343
2344         We parse arrow function's body with SyntaxChecker. At that time, we lex "string!" token under the SyntaxChecker context. But this means that we may not build string content for this token
2345         since SyntaxChecker may not have interest on string content itself in certain case. After the parser is back to ASTBuilder, we parse "string!" as ExpressionStatement with string constant,
2346         generate StringNode with non-built identifier (nullptr), and we accidentally create StringNode with nullptr.
2347
2348         This patch fixes this problem. The root cause of this problem is that the last token lexed in the previous context is used. We add lexCurrentTokenAgainUnderCurrentContext which will re-lex
2349         the current token under the current context (may be ASTBuilder). This should be done only when the caller's context is different from SyntaxChecker, which avoids unnecessary lexing.
2350         We leverage existing SavePoint mechanism to implement lexCurrentTokenAgainUnderCurrentContext cleanly.
2351
2352         And we also fix the bug in the existing SavePoint mechanism, which is shown in the attached test script. When we save LexerState, we do not save line terminator status. This patch also introduces
2353         lexWithoutClearingLineTerminator, which lex the token without clearing line terminator status.
2354
2355         * parser/ASTBuilder.h:
2356         (JSC::ASTBuilder::createString):
2357         * parser/Lexer.cpp:
2358         (JSC::Lexer<T>::parseMultilineComment):
2359         (JSC::Lexer<T>::lexWithoutClearingLineTerminator): EOF token also should record offset information. This offset information is correctly handled in Lexer::setOffset too.
2360         (JSC::Lexer<T>::lex): Deleted.
2361         * parser/Lexer.h:
2362         (JSC::Lexer::hasLineTerminatorBeforeToken const):
2363         (JSC::Lexer::setHasLineTerminatorBeforeToken):
2364         (JSC::Lexer<T>::lex):
2365         (JSC::Lexer::prevTerminator const): Deleted.
2366         (JSC::Lexer::setTerminator): Deleted.
2367         * parser/Parser.cpp:
2368         (JSC::Parser<LexerType>::allowAutomaticSemicolon):
2369         (JSC::Parser<LexerType>::parseSingleFunction):
2370         (JSC::Parser<LexerType>::parseStatementListItem):
2371         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2372         (JSC::Parser<LexerType>::parseFunctionInfo):
2373         (JSC::Parser<LexerType>::parseClass):
2374         (JSC::Parser<LexerType>::parseExportDeclaration):
2375         (JSC::Parser<LexerType>::parseAssignmentExpression):
2376         (JSC::Parser<LexerType>::parseYieldExpression):
2377         (JSC::Parser<LexerType>::parseProperty):
2378         (JSC::Parser<LexerType>::parsePrimaryExpression):
2379         (JSC::Parser<LexerType>::parseMemberExpression):
2380         * parser/Parser.h:
2381         (JSC::Parser::nextWithoutClearingLineTerminator):
2382         (JSC::Parser::lexCurrentTokenAgainUnderCurrentContext):
2383         (JSC::Parser::internalSaveLexerState):
2384         (JSC::Parser::restoreLexerState):
2385
2386 2019-04-05  Caitlin Potter  <caitp@igalia.com>
2387
2388         [JSC] Filter DontEnum properties in ProxyObject::getOwnPropertyNames()
2389         https://bugs.webkit.org/show_bug.cgi?id=176810
2390
2391         Reviewed by Saam Barati.
2392
2393         This adds conditional logic following the invariant checks, to perform
2394         filtering in common uses of getOwnPropertyNames.
2395
2396         While this would ideally only be done in JSPropertyNameEnumerator, adding
2397         the filtering to ProxyObject::performGetOwnPropertyNames maintains the
2398         invariant that the EnumerationMode is properly followed.
2399
2400         * runtime/PropertyNameArray.h:
2401         (JSC::PropertyNameArray::reset):
2402         * runtime/ProxyObject.cpp:
2403         (JSC::ProxyObject::performGetOwnPropertyNames):
2404
2405 2019-04-05  Commit Queue  <commit-queue@webkit.org>
2406
2407         Unreviewed, rolling out r243833.
2408         https://bugs.webkit.org/show_bug.cgi?id=196645
2409
2410         This change breaks build of WPE and GTK ports (Requested by
2411         annulen on #webkit).
2412
2413         Reverted changeset:
2414
2415         "[CMake][WTF] Mirror XCode header directories"
2416         https://bugs.webkit.org/show_bug.cgi?id=191662
2417         https://trac.webkit.org/changeset/243833
2418
2419 2019-04-05  Caitlin Potter  <caitp@igalia.com>
2420
2421         [JSC] throw if ownKeys Proxy trap result contains duplicate keys
2422         https://bugs.webkit.org/show_bug.cgi?id=185211
2423
2424         Reviewed by Saam Barati.
2425
2426         Implements the normative spec change in https://github.com/tc39/ecma262/pull/833
2427
2428         This involves tracking duplicate keys returned from the ownKeys trap in yet
2429         another HashTable, and may incur a minor performance penalty in some cases. This
2430         is not expected to significantly affect web performance.
2431
2432         * runtime/ProxyObject.cpp:
2433         (JSC::ProxyObject::performGetOwnPropertyNames):
2434
2435 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
2436
2437         [JSC] makeBoundFunction should not assume incoming "length" value is Int32 because it performs some calculation in bytecode
2438         https://bugs.webkit.org/show_bug.cgi?id=196631
2439
2440         Reviewed by Saam Barati.
2441
2442         makeBoundFunction assumes that "length" argument is always Int32. But this should not be done since this "length" value is calculated in builtin JS code.
2443         DFG may store this value in Double format so that we should not rely on that this value is Int32. This patch fixes makeBoundFunction function to perform
2444         toInt32 operation. We also insert a missing exception check for `JSString::value(ExecState*)` in makeBoundFunction.
2445
2446         * JavaScriptCore.xcodeproj/project.pbxproj:
2447         * Sources.txt:
2448         * interpreter/CallFrameInlines.h:
2449         * runtime/DoublePredictionFuzzerAgent.cpp: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
2450         (JSC::DoublePredictionFuzzerAgent::DoublePredictionFuzzerAgent):
2451         (JSC::DoublePredictionFuzzerAgent::getPrediction):
2452         * runtime/DoublePredictionFuzzerAgent.h: Copied from Source/JavaScriptCore/interpreter/CallFrameInlines.h.
2453         * runtime/JSGlobalObject.cpp:
2454         (JSC::makeBoundFunction):
2455         * runtime/Options.h:
2456         * runtime/VM.cpp:
2457         (JSC::VM::VM):
2458
2459 2019-04-04  Robin Morisset  <rmorisset@apple.com>
2460
2461         B3ReduceStrength should know that Mul distributes over Add and Sub
2462         https://bugs.webkit.org/show_bug.cgi?id=196325
2463         <rdar://problem/49441650>
2464
2465         Reviewed by Saam Barati.
2466
2467         Fix some obviously wrong code that was due to an accidental copy-paste.
2468         It made the entire optimization dead code that never ran.
2469
2470         * b3/B3ReduceStrength.cpp:
2471
2472 2019-04-04  Saam Barati  <sbarati@apple.com>
2473
2474         Unreviewed, build fix for CLoop after r243886
2475
2476         * interpreter/Interpreter.cpp:
2477         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
2478         * interpreter/StackVisitor.cpp:
2479         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
2480         * interpreter/StackVisitor.h:
2481
2482 2019-04-04  Commit Queue  <commit-queue@webkit.org>
2483
2484         Unreviewed, rolling out r243898.
2485         https://bugs.webkit.org/show_bug.cgi?id=196624
2486
2487         `#if !ENABLE(C_LOOP) && NUMBER_OF_CALLEE_SAVES_REGISTERS > 0`
2488         does not work well (Requested by yusukesuzuki on #webkit).
2489
2490         Reverted changeset:
2491
2492         "Unreviewed, build fix for CLoop and Windows after r243886"
2493         https://bugs.webkit.org/show_bug.cgi?id=196387
2494         https://trac.webkit.org/changeset/243898
2495
2496 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
2497
2498         Unreviewed, build fix for CLoop and Windows after r243886
2499         https://bugs.webkit.org/show_bug.cgi?id=196387
2500
2501         RegisterAtOffsetList does not exist if ENABLE(ASSEMBLER) is false.
2502
2503         * interpreter/StackVisitor.cpp:
2504         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
2505         * interpreter/StackVisitor.h:
2506
2507 2019-04-04  Saam barati  <sbarati@apple.com>
2508
2509         Teach Call ICs how to call Wasm
2510         https://bugs.webkit.org/show_bug.cgi?id=196387
2511
2512         Reviewed by Filip Pizlo.
2513
2514         This patch teaches JS to call Wasm without going through the native thunk.
2515         Currently, we emit a JIT "JS" callee stub which marshals arguments from
2516         JS to Wasm. Like the native version of this, this thunk is responsible
2517         for saving and restoring the VM's current Wasm context. Instead of emitting
2518         an exception handler, we also teach the unwinder how to read the previous
2519         wasm context to restore it as it unwindws past this frame.
2520         
2521         This patch is straight forward, and leaves some areas for perf improvement:
2522         - We can teach the DFG/FTL to directly use the Wasm calling convention when
2523           it knows it's calling a single Wasm function. This way we don't shuffle
2524           registers to the stack and then back into registers.
2525         - We bail out to the slow path for mismatched arity. I opened a bug to fix
2526           optimize arity check failures: https://bugs.webkit.org/show_bug.cgi?id=196564
2527         - We bail out to the slow path Double JSValues flowing into i32 arguments.
2528           We should teach this thunk how to do that conversion directly.
2529         
2530         This patch also refactors the code to explicitly have a single pinned size register.
2531         We used pretend in some places that we could have more than one pinned size register.
2532         However, there was other code that just asserted the size was one. This patch just rips
2533         out this code since we never moved to having more than one pinned size register. Doing
2534         this refactoring cleans up the various places where we set up the size register.
2535         
2536         This patch is a 50-60% progression on JetStream 2's richards-wasm.
2537
2538         * JavaScriptCore.xcodeproj/project.pbxproj:
2539         * Sources.txt:
2540         * assembler/MacroAssemblerCodeRef.h:
2541         (JSC::MacroAssemblerCodeRef::operator=):
2542         (JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
2543         * interpreter/Interpreter.cpp:
2544         (JSC::UnwindFunctor::operator() const):
2545         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
2546         * interpreter/StackVisitor.cpp:
2547         (JSC::StackVisitor::Frame::calleeSaveRegistersForUnwinding):
2548         (JSC::StackVisitor::Frame::calleeSaveRegisters): Deleted.
2549         * interpreter/StackVisitor.h:
2550         * jit/JITOperations.cpp:
2551         * jit/RegisterSet.cpp:
2552         (JSC::RegisterSet::runtimeTagRegisters):
2553         (JSC::RegisterSet::specialRegisters):
2554         (JSC::RegisterSet::runtimeRegisters): Deleted.
2555         * jit/RegisterSet.h:
2556         * jit/Repatch.cpp:
2557         (JSC::linkPolymorphicCall):
2558         * runtime/JSFunction.cpp:
2559         (JSC::getCalculatedDisplayName):
2560         * runtime/JSGlobalObject.cpp:
2561         (JSC::JSGlobalObject::init):
2562         (JSC::JSGlobalObject::visitChildren):
2563         * runtime/JSGlobalObject.h:
2564         (JSC::JSGlobalObject::jsToWasmICCalleeStructure const):
2565         * runtime/VM.cpp:
2566         (JSC::VM::VM):
2567         * runtime/VM.h:
2568         * wasm/WasmAirIRGenerator.cpp:
2569         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
2570         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2571         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2572         * wasm/WasmB3IRGenerator.cpp:
2573         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2574         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2575         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2576         * wasm/WasmBinding.cpp:
2577         (JSC::Wasm::wasmToWasm):
2578         * wasm/WasmContext.h:
2579         (JSC::Wasm::Context::pointerToInstance):
2580         * wasm/WasmContextInlines.h:
2581         (JSC::Wasm::Context::store):
2582         * wasm/WasmMemoryInformation.cpp:
2583         (JSC::Wasm::getPinnedRegisters):
2584         (JSC::Wasm::PinnedRegisterInfo::get):
2585         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
2586         * wasm/WasmMemoryInformation.h:
2587         (JSC::Wasm::PinnedRegisterInfo::toSave const):
2588         * wasm/WasmOMGPlan.cpp:
2589         (JSC::Wasm::OMGPlan::work):
2590         * wasm/js/JSToWasm.cpp:
2591         (JSC::Wasm::createJSToWasmWrapper):
2592         * wasm/js/JSToWasmICCallee.cpp: Added.
2593         (JSC::JSToWasmICCallee::create):
2594         (JSC::JSToWasmICCallee::createStructure):
2595         (JSC::JSToWasmICCallee::visitChildren):
2596         * wasm/js/JSToWasmICCallee.h: Added.
2597         (JSC::JSToWasmICCallee::function):
2598         (JSC::JSToWasmICCallee::JSToWasmICCallee):
2599         * wasm/js/WebAssemblyFunction.cpp:
2600         (JSC::WebAssemblyFunction::useTagRegisters const):
2601         (JSC::WebAssemblyFunction::calleeSaves const):
2602         (JSC::WebAssemblyFunction::usedCalleeSaveRegisters const):
2603         (JSC::WebAssemblyFunction::previousInstanceOffset const):
2604         (JSC::WebAssemblyFunction::previousInstance):
2605         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2606         (JSC::WebAssemblyFunction::visitChildren):
2607         (JSC::WebAssemblyFunction::destroy):
2608         * wasm/js/WebAssemblyFunction.h:
2609         * wasm/js/WebAssemblyFunctionHeapCellType.cpp: Added.
2610         (JSC::WebAssemblyFunctionDestroyFunc::operator() const):
2611         (JSC::WebAssemblyFunctionHeapCellType::WebAssemblyFunctionHeapCellType):
2612         (JSC::WebAssemblyFunctionHeapCellType::~WebAssemblyFunctionHeapCellType):
2613         (JSC::WebAssemblyFunctionHeapCellType::finishSweep):
2614         (JSC::WebAssemblyFunctionHeapCellType::destroy):
2615         * wasm/js/WebAssemblyFunctionHeapCellType.h: Added.
2616         * wasm/js/WebAssemblyPrototype.h:
2617
2618 2019-04-04  Yusuke Suzuki  <ysuzuki@apple.com>
2619
2620         [JSC] Pass CodeOrigin to FuzzerAgent
2621         https://bugs.webkit.org/show_bug.cgi?id=196590
2622
2623         Reviewed by Saam Barati.
2624
2625         Pass CodeOrigin instead of bytecodeIndex. CodeOrigin includes richer information (InlineCallFrame*).
2626         We also mask prediction with SpecBytecodeTop in DFGByteCodeParser. The fuzzer can produce any SpeculatedTypes,
2627         but DFGByteCodeParser should only see predictions that can be actually produced from the bytecode execution.
2628
2629         * dfg/DFGByteCodeParser.cpp:
2630         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2631         * runtime/FuzzerAgent.cpp:
2632         (JSC::FuzzerAgent::getPrediction):
2633         * runtime/FuzzerAgent.h:
2634         * runtime/RandomizingFuzzerAgent.cpp:
2635         (JSC::RandomizingFuzzerAgent::getPrediction):
2636         * runtime/RandomizingFuzzerAgent.h:
2637
2638 2019-04-04  Caio Lima  <ticaiolima@gmail.com>
2639
2640         [JSC] We should consider moving UnlinkedFunctionExecutable::m_parentScopeTDZVariables to RareData
2641         https://bugs.webkit.org/show_bug.cgi?id=194944
2642
2643         Reviewed by Keith Miller.
2644
2645         Based on profile data collected on JetStream2, Speedometer 2 and
2646         other benchmarks, it is very rare having non-empty
2647         UnlinkedFunctionExecutable::m_parentScopeTDZVariables.
2648
2649         - Data collected from Speedometer2
2650             Total number of UnlinkedFunctionExecutable: 39463
2651             Total number of non-empty parentScopeTDZVars: 428 (~1%)
2652
2653         - Data collected from JetStream2
2654             Total number of UnlinkedFunctionExecutable: 83715
2655             Total number of non-empty parentScopeTDZVars: 5285 (~6%)
2656
2657         We also collected numbers on 6 of top 10 Alexia sites.
2658
2659         - Data collected from youtube.com
2660             Total number of UnlinkedFunctionExecutable: 29599
2661             Total number of non-empty parentScopeTDZVars: 97 (~0.3%)
2662
2663         - Data collected from twitter.com
2664             Total number of UnlinkedFunctionExecutable: 23774
2665             Total number of non-empty parentScopeTDZVars: 172 (~0.7%)
2666
2667         - Data collected from google.com
2668             Total number of UnlinkedFunctionExecutable: 33209
2669             Total number of non-empty parentScopeTDZVars: 174 (~0.5%)
2670
2671         - Data collected from amazon.com:
2672             Total number of UnlinkedFunctionExecutable: 15182
2673             Total number of non-empty parentScopeTDZVars: 166 (~1%)
2674
2675         - Data collected from facebook.com:
2676             Total number of UnlinkedFunctionExecutable: 54443
2677             Total number of non-empty parentScopeTDZVars: 269 (~0.4%)
2678
2679         - Data collected from netflix.com:
2680             Total number of UnlinkedFunctionExecutable: 39266
2681             Total number of non-empty parentScopeTDZVars: 97 (~0.2%)
2682
2683         Considering such numbers, this patch is moving `m_parentScopeTDZVariables`
2684         to RareData. This decreases sizeof(UnlinkedFunctionExecutable) by
2685         16 bytes. With this change, now UnlinkedFunctionExecutable constructors
2686         receives an `Optional<VariableEnvironmentMap::Handle>` and only stores
2687         it when `value != WTF::nullopt`. We also changed
2688         UnlinkedFunctionExecutable::parentScopeTDZVariables() and it returns
2689         `VariableEnvironment()` whenever the Executable doesn't have RareData,
2690         or VariableEnvironmentMap::Handle is unitialized. This is required
2691         because RareData is instantiated when any of its field is stored and
2692         we can have an unitialized `Handle` even on cases when parentScopeTDZVariables
2693         is `WTF::nullopt`.
2694
2695         Results on memory usage on JetStrem2 is neutral.
2696
2697             Mean of memory peak on ToT: 4258633728 bytes (confidence interval: 249720072.95)
2698             Mean of memory peak on Changes: 4367325184 bytes (confidence interval: 321285583.61)
2699
2700         * builtins/BuiltinExecutables.cpp:
2701         (JSC::BuiltinExecutables::createExecutable):
2702         * bytecode/UnlinkedFunctionExecutable.cpp:
2703         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2704         * bytecode/UnlinkedFunctionExecutable.h:
2705         * bytecompiler/BytecodeGenerator.cpp:
2706         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
2707
2708         BytecodeGenerator::getVariablesUnderTDZ now also caches if m_cachedVariablesUnderTDZ
2709         is empty, so we can properly return `WTF::nullopt` without the
2710         reconstruction of a VariableEnvironment to check if it is empty.
2711
2712         * bytecompiler/BytecodeGenerator.h:
2713         (JSC::BytecodeGenerator::makeFunction):
2714         * parser/VariableEnvironment.h:
2715         (JSC::VariableEnvironment::isEmpty const):
2716         * runtime/CachedTypes.cpp:
2717         (JSC::CachedCompactVariableMapHandle::decode const):
2718
2719         It returns an unitialized Handle when there is no
2720         CompactVariableEnvironment. This can happen when RareData is ensured
2721         because of another field.
2722
2723         (JSC::CachedFunctionExecutableRareData::encode):
2724         (JSC::CachedFunctionExecutableRareData::decode const):
2725         (JSC::CachedFunctionExecutable::encode):
2726         (JSC::CachedFunctionExecutable::decode const):
2727         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2728         * runtime/CodeCache.cpp:
2729
2730         Instead of creating a dummyVariablesUnderTDZ, we simply pass
2731         WTF::nullopt.
2732
2733         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
2734
2735 2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>
2736
2737         Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
2738         https://bugs.webkit.org/show_bug.cgi?id=196409
2739
2740         Reviewed by Saam Barati.
2741
2742         Some of the helpers in jsc.cpp, such as `functionRunString`, were stll using
2743         using `makeSource` instead of `jscSource`, which does not use the ShellSourceProvider
2744         and therefore does not write the bytecode cache to disk.
2745
2746         Changing that revealed a bug in bytecode cache. The Encoder keeps a mapping
2747         of pointers to offsets of already cached objects, in order to avoid caching
2748         the same object twice. Similarly, the Decoder keeps a mapping from offsets
2749         to pointers, in order to avoid creating multiple objects in memory for the
2750         same cached object. The following was happening:
2751         1) A StringImpl* S was cached as CachedPtr<CachedStringImpl> at offset O. We add
2752         an entry in the Encoder mapping that S has already been encoded at O.
2753         2) We cache StringImpl* S again, but now as CachedPtr<CachedUniquedStringImpl>.
2754         We find an entry in the Encoder mapping for S, and return the offset O. However,
2755         the object cached at O is a CachedPtr<CachedStringImpl> (i.e. not Uniqued).
2756
2757         3) When decoding, there are 2 possibilities:
2758         3.1) We find S for the first time through a CachedPtr<CachedStringImpl>. In
2759         this case, everything works as expected since we add an entry in the decoder
2760         mapping from the offset O to the decoded StringImpl* S. The next time we find
2761         S through the uniqued version, we'll return the already decoded S.
2762         3.2) We find S through a CachedPtr<CachedUniquedStringImpl>. Now we have a
2763         problem, since the CachedPtr has the offset of a CachedStringImpl (not uniqued),
2764         which has a different shape and we crash.
2765
2766         We fix this by making CachedStringImpl and CachedUniquedStringImpl share the
2767         same implementation. Since it doesn't matter whether a string is uniqued for
2768         encoding, and we always decode strings as uniqued either way, they can be used
2769         interchangeably.
2770
2771         * jsc.cpp:
2772         (functionRunString):
2773         (functionLoadString):
2774         (functionDollarAgentStart):
2775         (functionCheckModuleSyntax):
2776         (runInteractive):
2777         * runtime/CachedTypes.cpp:
2778         (JSC::CachedUniquedStringImplBase::decode const):
2779         (JSC::CachedFunctionExecutable::rareData const):
2780         (JSC::CachedCodeBlock::rareData const):
2781         (JSC::CachedFunctionExecutable::encode):
2782         (JSC::CachedCodeBlock<CodeBlockType>::encode):
2783         (JSC::CachedUniquedStringImpl::encode): Deleted.
2784         (JSC::CachedUniquedStringImpl::decode const): Deleted.
2785         (JSC::CachedStringImpl::encode): Deleted.
2786         (JSC::CachedStringImpl::decode const): Deleted.
2787
2788 2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>
2789
2790         UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
2791         https://bugs.webkit.org/show_bug.cgi?id=196396
2792
2793         Reviewed by Saam Barati.
2794
2795         The UnlinkedCodeBlock constructor in CachedTypes was missing the initialization
2796         for m_didOptimize, which leads to crashes in CodeBlock::thresholdForJIT.
2797
2798         * runtime/CachedTypes.cpp:
2799         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2800
2801 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2802
2803         Unreviewed, rolling in r243843 with the build fix
2804         https://bugs.webkit.org/show_bug.cgi?id=196586
2805
2806         * runtime/Options.cpp:
2807         (JSC::recomputeDependentOptions):
2808         * runtime/Options.h:
2809         * runtime/RandomizingFuzzerAgent.cpp:
2810         (JSC::RandomizingFuzzerAgent::getPrediction):
2811
2812 2019-04-03  Ryan Haddad  <ryanhaddad@apple.com>
2813
2814         Unreviewed, rolling out r243843.
2815
2816         Broke CLoop and Windows builds.
2817
2818         Reverted changeset:
2819
2820         "[JSC] Add dump feature for RandomizingFuzzerAgent"
2821         https://bugs.webkit.org/show_bug.cgi?id=196586
2822         https://trac.webkit.org/changeset/243843
2823
2824 2019-04-03  Robin Morisset  <rmorisset@apple.com>
2825
2826         B3 should use associativity to optimize expression trees
2827         https://bugs.webkit.org/show_bug.cgi?id=194081
2828
2829         Reviewed by Filip Pizlo.
2830
2831         This patch adds a new B3 pass, that tries to find and optimize expression trees made purely of any one associative and commutative operator (Add/Mul/BitOr/BitAnd/BitXor).
2832         The pass only runs in O2, and runs once, after lowerMacros and just before a run of B3ReduceStrength (which helps clean up the dead code it tends to leave behind).
2833         I had to separate killDeadCode out of B3ReduceStrength (as a new B3EliminateDeadCode pass) to run it before B3OptimizeAssociativeExpressionTrees, as otherwise it is stopped by high use counts
2834         inherited from CSE.
2835         This extra run of DCE is by itself a win, most notably on microbenchmarks/instanceof-always-hit-two (1.5x faster), and on microbenchmarks/licm-dragons(-out-of-bounds) (both get 1.16x speedup).
2836         I suspect it is because it runs between CSE and tail-dedup, and as a result allows a lot more tail-dedup to occur.
2837
2838         The pass is currently extremely conservative, not trying anything if it would cause _any_ code duplication.
2839         For this purpose, it starts by computing use counts for the potentially interesting nodes (those with the right opcodes), and segregate them into expression trees.
2840         The root of an expression tree is a node that is either used in multiple places, or is used by a value with a different opcode.
2841         The leaves of an expression tree are nodes that are either used in multiple places, or have a different opcode.
2842         All constant leaves of a tree are combined, as well as all leaves that are identical. What remains is then laid out into a balanced binary tree, hopefully maximizing ILP.
2843
2844         This optimization was implemented as a stand-alone pass and not as part of B3ReduceStrength mostly because it needs use counts to avoid code duplication.
2845         It also benefits from finding all tree roots first, and not trying to repeatedly optimize subtrees.
2846
2847         I added several tests to testB3 with varying patterns of trees. It is also tested in a less focused way by lots of older tests.
2848
2849         In the future this pass could be expanded to allow some bounded amount of code duplication, and merging more leaves (e.g. Mul(a, 3) and a in an Add tree, into Mul(a, 4))
2850         The latter will need exposing the peephole optimizations out of B3ReduceStrength to avoid duplicating code.
2851
2852         * JavaScriptCore.xcodeproj/project.pbxproj:
2853         * Sources.txt:
2854         * b3/B3Common.cpp:
2855         (JSC::B3::shouldDumpIR):
2856         (JSC::B3::shouldDumpIRAtEachPhase):
2857         * b3/B3Common.h:
2858         * b3/B3EliminateDeadCode.cpp: Added.
2859         (JSC::B3::EliminateDeadCode::run):
2860         (JSC::B3::eliminateDeadCode):
2861         * b3/B3EliminateDeadCode.h: Added.
2862         (JSC::B3::EliminateDeadCode::EliminateDeadCode):
2863         * b3/B3Generate.cpp:
2864         (JSC::B3::generateToAir):
2865         * b3/B3OptimizeAssociativeExpressionTrees.cpp: Added.
2866         (JSC::B3::OptimizeAssociativeExpressionTrees::OptimizeAssociativeExpressionTrees):
2867         (JSC::B3::OptimizeAssociativeExpressionTrees::neutralElement):
2868         (JSC::B3::OptimizeAssociativeExpressionTrees::isAbsorbingElement):
2869         (JSC::B3::OptimizeAssociativeExpressionTrees::combineConstants):
2870         (JSC::B3::OptimizeAssociativeExpressionTrees::emitValue):
2871         (JSC::B3::OptimizeAssociativeExpressionTrees::optimizeRootedTree):
2872         (JSC::B3::OptimizeAssociativeExpressionTrees::run):
2873         (JSC::B3::optimizeAssociativeExpressionTrees):
2874         * b3/B3OptimizeAssociativeExpressionTrees.h: Added.
2875         * b3/B3ReduceStrength.cpp:
2876         * b3/B3Value.cpp:
2877         (JSC::B3::Value::replaceWithIdentity):
2878         * b3/testb3.cpp:
2879         (JSC::B3::testBitXorTreeArgs):
2880         (JSC::B3::testBitXorTreeArgsEven):
2881         (JSC::B3::testBitXorTreeArgImm):
2882         (JSC::B3::testAddTreeArg32):
2883         (JSC::B3::testMulTreeArg32):
2884         (JSC::B3::testBitAndTreeArg32):
2885         (JSC::B3::testBitOrTreeArg32):
2886         (JSC::B3::run):
2887
2888 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2889
2890         [JSC] Add dump feature for RandomizingFuzzerAgent
2891         https://bugs.webkit.org/show_bug.cgi?id=196586
2892
2893         Reviewed by Saam Barati.
2894
2895         Towards deterministic tests for the results from randomizing fuzzer agent, this patch adds Options::dumpRandomizingFuzzerAgentPredictions, which dumps the generated types.
2896         The results is like this.
2897
2898             getPrediction name:(#C2q9xD),bytecodeIndex:(22),original:(Array),generated:(OtherObj|Array|Float64Array|BigInt|NonIntAsDouble)
2899             getPrediction name:(makeUnwriteableUnconfigurableObject#AiEJv1),bytecodeIndex:(14),original:(OtherObj),generated:(Final|Uint8Array|Float64Array|SetObject|WeakSetObject|BigInt|NonIntAsDouble)
2900
2901         * runtime/Options.cpp:
2902         (JSC::recomputeDependentOptions):
2903         * runtime/Options.h:
2904         * runtime/RandomizingFuzzerAgent.cpp:
2905         (JSC::RandomizingFuzzerAgent::getPrediction):
2906
2907 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
2908
2909         -apple-trailing-word is needed for browser detection
2910         https://bugs.webkit.org/show_bug.cgi?id=196575
2911
2912         Unreviewed.
2913
2914         * Configurations/FeatureDefines.xcconfig:
2915
2916 2019-04-03  Michael Saboff  <msaboff@apple.com>
2917
2918         REGRESSION (r243642): com.apple.JavaScriptCore crash in JSC::RegExpObject::execInline
2919         https://bugs.webkit.org/show_bug.cgi?id=196477
2920
2921         Reviewed by Keith Miller.
2922
2923         The problem here is that when we advance the index by 2 for a character class that only
2924         has non-BMP characters, we might go past the end of the string.  This can happen for
2925         greedy counted character classes that are part of a alternative where there is one
2926         character to match after the greedy non-BMP character class.
2927
2928         The "do we have string left to match" check at the top of the JIT loop for the counted
2929         character class checks to see if index is not equal to the string length.  For non-BMP
2930         character classes, we need to check to see if there are at least 2 characters left.
2931         Therefore we now temporarily add 1 to the current index before comparing.  This checks
2932         to see if there are iat least 2 characters left to match, instead of 1.
2933
2934         * yarr/YarrJIT.cpp:
2935         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
2936         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
2937
2938 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2939
2940         [JSC] Exception verification crash on operationArrayIndexOfValueInt32OrContiguous
2941         https://bugs.webkit.org/show_bug.cgi?id=196574
2942
2943         Reviewed by Saam Barati.
2944
2945         This patch adds missing exception check in operationArrayIndexOfValueInt32OrContiguous.
2946
2947         * dfg/DFGOperations.cpp:
2948
2949 2019-04-03  Don Olmstead  <don.olmstead@sony.com>
2950
2951         [CMake][WTF] Mirror XCode header directories
2952         https://bugs.webkit.org/show_bug.cgi?id=191662
2953
2954         Reviewed by Konstantin Tokarev.
2955
2956         Use WTFFramework as a dependency and include frameworks/WTF.cmake for AppleWin internal
2957         builds.
2958
2959         * CMakeLists.txt:
2960         * shell/CMakeLists.txt:
2961
2962 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
2963
2964         [JSC] Add FuzzerAgent, which has a hooks to get feedback & inject fuzz data into JSC
2965         https://bugs.webkit.org/show_bug.cgi?id=196530
2966
2967         Reviewed by Saam Barati.
2968
2969         This patch adds FuzzerAgent interface and simple RandomizingFuzzerAgent to JSC.
2970         This RandomizingFuzzerAgent returns random SpeculatedType for value profiling to find
2971         the issues in JSC. The seed for randomization can be specified by seedOfRandomizingFuzzerAgent.
2972
2973         I ran this with seedOfRandomizingFuzzerAgent=1 last night and it finds 3 failures in the current JSC tests,
2974         they should be fixed in subsequent patches.
2975
2976         * CMakeLists.txt:
2977         * JavaScriptCore.xcodeproj/project.pbxproj:
2978         * Sources.txt:
2979         * dfg/DFGByteCodeParser.cpp:
2980         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2981         * runtime/FuzzerAgent.cpp: Added.
2982         (JSC::FuzzerAgent::~FuzzerAgent):
2983         (JSC::FuzzerAgent::getPrediction):
2984         * runtime/FuzzerAgent.h: Added.
2985         * runtime/JSGlobalObjectFunctions.cpp:
2986         * runtime/Options.h:
2987         * runtime/RandomizingFuzzerAgent.cpp: Added.
2988         (JSC::RandomizingFuzzerAgent::RandomizingFuzzerAgent):
2989         (JSC::RandomizingFuzzerAgent::getPrediction):
2990         * runtime/RandomizingFuzzerAgent.h: Added.
2991         * runtime/RegExpCachedResult.h:
2992         * runtime/RegExpGlobalData.cpp:
2993         * runtime/VM.cpp:
2994         (JSC::VM::VM):
2995         * runtime/VM.h:
2996         (JSC::VM::fuzzerAgent const):
2997         (JSC::VM::setFuzzerAgent):
2998
2999 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
3000
3001         Remove support for -apple-trailing-word
3002         https://bugs.webkit.org/show_bug.cgi?id=196525
3003
3004         Reviewed by Zalan Bujtas.
3005
3006         This CSS property is nonstandard and not used.
3007
3008         * Configurations/FeatureDefines.xcconfig:
3009
3010 2019-04-03  Joseph Pecoraro  <pecoraro@apple.com>
3011
3012         Web Inspector: Remote Inspector indicate callback should always happen on the main thread
3013         https://bugs.webkit.org/show_bug.cgi?id=196513
3014         <rdar://problem/49498284>
3015
3016         Reviewed by Devin Rousso.
3017
3018         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3019         (Inspector::RemoteInspector::receivedIndicateMessage):
3020         When we have a WebThread, don't just run on the WebThread,
3021         run on the MainThread with the WebThreadLock.
3022
3023 2019-04-02  Michael Saboff  <msaboff@apple.com>
3024
3025         Crash in Options::setOptions() using --configFile option and libgmalloc
3026         https://bugs.webkit.org/show_bug.cgi?id=196506
3027
3028         Reviewed by Keith Miller.
3029
3030         Changed to call CString::data() while making the call to Options::setOptions().  This keeps
3031         the implicit CString temporary alive until after setOptions() returns.
3032
3033         * runtime/ConfigFile.cpp:
3034         (JSC::ConfigFile::parse):
3035
3036 2019-04-02  Fujii Hironori  <Hironori.Fujii@sony.com>
3037
3038         [CMake] WEBKIT_MAKE_FORWARDING_HEADERS shouldn't use POST_BUILD to copy generated headers
3039         https://bugs.webkit.org/show_bug.cgi?id=182757
3040
3041         Reviewed by Don Olmstead.
3042
3043         * CMakeLists.txt: Do not use DERIVED_SOURCE_DIRECTORIES parameter
3044         of WEBKIT_MAKE_FORWARDING_HEADERS. Added generated headers to
3045         JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS.
3046
3047 2019-04-02  Saam barati  <sbarati@apple.com>
3048
3049         Add a ValueRepReduction phase
3050         https://bugs.webkit.org/show_bug.cgi?id=196234
3051
3052         Reviewed by Filip Pizlo.
3053
3054         This patch adds a ValueRepReduction phase. The main idea here is
3055         to try to reduce DoubleRep(RealNumberUse:ValueRep(DoubleRepUse:@x))
3056         to just be @x. This patch handles such above strengh reduction rules
3057         as long as we prove that all users of the ValueRep can be converted
3058         to using the incoming double value. That way we prevent introducing
3059         a parallel live range for the double value.
3060         
3061         This patch tracks the uses of the ValueRep through Phi variables,
3062         so we can convert entire Phi variables to being Double instead
3063         of JSValue if the Phi also has only double uses.
3064         
3065         This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
3066         and OSR exit hints are not counted as escapes. All other uses are counted
3067         as escapes. Connected Phi graphs are converted to being Double only if the
3068         entire graph is ok with the result being Double.
3069         
3070         Some ways we could extend this phase in the future:
3071         - There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
3072           that the result of the DoubleRep of @x is not impure NaN. We could
3073           handle this case if we introduced a PurifyNaN node and replace the DoubleRep
3074           with PurifyNaN(@x). Alternatively, we could see if certain users of this
3075           DoubleRep are okay with impure NaN flowing into them and we'd need to ensure
3076           their output type is always treated as if the input is impure NaN.
3077         - We could do sinking of ValueRep where we think it's profitable. So instead
3078           of an escape making it so we never represent the variable as a Double, we
3079           could make the escape reconstruct the JSValueRep where profitable.
3080         - We can extend this phase to handle Int52Rep if it's profitable.
3081         - We can opt other nodes into accepting incoming Doubles so we no longer
3082           treat them as escapes.
3083         
3084         This patch is somewhere between neutral and a 1% progression on JetStream 2.
3085
3086         * JavaScriptCore.xcodeproj/project.pbxproj:
3087         * Sources.txt:
3088         * dfg/DFGPlan.cpp:
3089         (JSC::DFG::Plan::compileInThreadImpl):
3090         * dfg/DFGValueRepReductionPhase.cpp: Added.
3091         (JSC::DFG::ValueRepReductionPhase::ValueRepReductionPhase):
3092         (JSC::DFG::ValueRepReductionPhase::run):
3093         (JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
3094         (JSC::DFG::performValueRepReduction):
3095         * dfg/DFGValueRepReductionPhase.h: Added.
3096         * runtime/Options.h:
3097
3098 2019-04-01  Yusuke Suzuki  <ysuzuki@apple.com>
3099
3100         [JSC] JSRunLoopTimer::Manager should be small
3101         https://bugs.webkit.org/show_bug.cgi?id=196425
3102
3103         Reviewed by Darin Adler.
3104
3105         Using very large Key or Value in HashMap potentially bloats memory since HashMap pre-allocates large size of
3106         memory ((sizeof(Key) + sizeof(Value)) * N) for its backing storage's array. Using std::unique_ptr<> for JSRunLoopTimer's
3107         PerVMData to keep HashMap's backing store size small.
3108
3109         * runtime/JSRunLoopTimer.cpp:
3110         (JSC::JSRunLoopTimer::Manager::timerDidFire):
3111         (JSC::JSRunLoopTimer::Manager::registerVM):
3112         (JSC::JSRunLoopTimer::Manager::scheduleTimer):
3113         (JSC::JSRunLoopTimer::Manager::cancelTimer):
3114         (JSC::JSRunLoopTimer::Manager::timeUntilFire):
3115         (JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
3116         * runtime/JSRunLoopTimer.h:
3117
3118 2019-04-01  Stephan Szabo  <stephan.szabo@sony.com>
3119
3120         [PlayStation] Add initialization for JSC shell for PlayStation port
3121         https://bugs.webkit.org/show_bug.cgi?id=195411
3122
3123         Reviewed by Ross Kirsling.
3124
3125         Add ps options
3126
3127         * shell/PlatformPlayStation.cmake: Added.
3128         * shell/playstation/Initializer.cpp: Added.
3129         (initializer):
3130
3131 2019-04-01  Michael Catanzaro  <mcatanzaro@igalia.com>
3132
3133         Stop trying to support building JSC with clang 3.8
3134         https://bugs.webkit.org/show_bug.cgi?id=195947
3135         <rdar://problem/49069219>
3136
3137         Reviewed by Darin Adler.
3138
3139         It seems WebKit hasn't built with clang 3.8 in a while, no devs are using this compiler, we
3140         don't know how much effort it would be to make JSC work again, and it's making the code
3141         worse. Remove my hacks to support clang 3.8 from JSC.
3142
3143         * bindings/ScriptValue.cpp:
3144         (Inspector::jsToInspectorValue):
3145         * bytecode/GetterSetterAccessCase.cpp:
3146         (JSC::GetterSetterAccessCase::create):
3147         (JSC::GetterSetterAccessCase::clone const):
3148         * bytecode/InstanceOfAccessCase.cpp:
3149         (JSC::InstanceOfAccessCase::clone const):
3150         * bytecode/IntrinsicGetterAccessCase.cpp:
3151         (JSC::IntrinsicGetterAccessCase::clone const):
3152         * bytecode/ModuleNamespaceAccessCase.cpp:
3153         (JSC::ModuleNamespaceAccessCase::clone const):
3154         * bytecode/ProxyableAccessCase.cpp:
3155         (JSC::ProxyableAccessCase::clone const):
3156
3157 2019-03-31  Yusuke Suzuki  <ysuzuki@apple.com>
3158
3159         [JSC] Butterfly allocation from LargeAllocation should try "realloc" behavior if collector thread is not active
3160         https://bugs.webkit.org/show_bug.cgi?id=196160
3161
3162         Reviewed by Saam Barati.
3163
3164         "realloc" can be effective in terms of peak/current memory footprint when realloc succeeds because,
3165
3166         1. It does not allocate additional memory while expanding a vector
3167         2. It does not deallocate an old memory, just reusing the current memory by expanding, so that memory footprint is tight even before scavenging
3168
3169         We found that we can "realloc" large butterflies in certain conditions are met because,
3170
3171         1. If it goes to LargeAllocation, this memory region is never reused until GC sweeps it.
3172         2. Butterflies are owned by owner JSObjects, so we know the lifetime of Butterflies.
3173
3174         This patch attempts to use "realloc" onto butterflies if,
3175
3176         1. Butterflies are allocated in LargeAllocation kind
3177         2. Concurrent collector is not active
3178         3. Butterflies do not have property storage
3179
3180         The condition (2) is required to avoid deallocating butterflies while the concurrent collector looks into it. The condition (3) is
3181         also required to avoid deallocating butterflies while the concurrent compiler looks into it.
3182
3183         We also change LargeAllocation mechanism to using "malloc" and "free" instead of "posix_memalign". This allows us to use "realloc"
3184         safely in all the platforms. Since LargeAllocation uses alignment to distinguish LargeAllocation and MarkedBlock, we manually adjust
3185         16B alignment by allocating 8B more memory in "malloc".
3186
3187         Speedometer2 and JetStream2 are neutral. RAMification shows about 1% progression (even in some of JIT tests).
3188
3189         * heap/AlignedMemoryAllocator.h:
3190         * heap/CompleteSubspace.cpp:
3191         (JSC::CompleteSubspace::tryAllocateSlow):
3192         (JSC::CompleteSubspace::reallocateLargeAllocationNonVirtual):
3193         * heap/CompleteSubspace.h:
3194         * heap/FastMallocAlignedMemoryAllocator.cpp:
3195         (JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory):
3196         (JSC::FastMallocAlignedMemoryAllocator::freeMemory):
3197         (JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory):
3198         * heap/FastMallocAlignedMemoryAllocator.h:
3199         * heap/GigacageAlignedMemoryAllocator.cpp:
3200         (JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory):
3201         (JSC::GigacageAlignedMemoryAllocator::freeMemory):
3202         (JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory):
3203         * heap/GigacageAlignedMemoryAllocator.h:
3204         * heap/IsoAlignedMemoryAllocator.cpp:
3205         (JSC::IsoAlignedMemoryAllocator::tryAllocateMemory):
3206         (JSC::IsoAlignedMemoryAllocator::freeMemory):
3207         (JSC::IsoAlignedMemoryAllocator::tryReallocateMemory):
3208         * heap/IsoAlignedMemoryAllocator.h:
3209         * heap/LargeAllocation.cpp:
3210         (JSC::isAlignedForLargeAllocation):
3211         (JSC::LargeAllocation::tryCreate):
3212         (JSC::LargeAllocation::tryReallocate):
3213         (JSC::LargeAllocation::LargeAllocation):
3214         (JSC::LargeAllocation::destroy):
3215         * heap/LargeAllocation.h:
3216         (JSC::LargeAllocation::indexInSpace):
3217         (JSC::LargeAllocation::setIndexInSpace):
3218         (JSC::LargeAllocation::basePointer const):
3219         * heap/MarkedSpace.cpp:
3220         (JSC::MarkedSpace::sweepLargeAllocations):
3221         (JSC::MarkedSpace::prepareForConservativeScan):
3222         * heap/WeakSet.h:
3223         (JSC::WeakSet::isTriviallyDestructible const):
3224         * runtime/Butterfly.h:
3225         * runtime/ButterflyInlines.h:
3226         (JSC::Butterfly::reallocArrayRightIfPossible):
3227         * runtime/JSObject.cpp:
3228         (JSC::JSObject::ensureLengthSlow):
3229
3230 2019-03-31  Sam Weinig  <weinig@apple.com>
3231
3232         Remove more i386 specific configurations
3233         https://bugs.webkit.org/show_bug.cgi?id=196430
3234
3235         Reviewed by Alexey Proskuryakov.
3236
3237         * Configurations/FeatureDefines.xcconfig:
3238         ENABLE_WEB_AUTHN_macosx can now be enabled unconditionally on macOS.
3239
3240         * Configurations/ToolExecutable.xcconfig:
3241         ARC can be enabled unconditionally now.
3242
3243 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
3244
3245         [JSC] JSWrapperMap should not use Objective-C Weak map (NSMapTable with NSPointerFunctionsWeakMemory) for m_cachedObjCWrappers
3246         https://bugs.webkit.org/show_bug.cgi?id=196392
3247
3248         Reviewed by Saam Barati.
3249
3250         Weak representation in Objective-C is surprisingly costly in terms of memory. We can see that very easy program shows 10KB memory consumption due to
3251         this weak wrapper map in JavaScriptCore.framework. But we do not need this weak map since Objective-C JSValue has a dealloc. We can unregister itself
3252         from the map when it is deallocated without using Objective-C weak mechanism. And since Objective-C JSValue is tightly coupled to a specific JSContext,
3253         and wrapper map is created per JSContext, JSValue wrapper and actual JavaScriptCore value is one-on-one, and [JSValue dealloc] knows which JSContext's
3254         wrapper map holds itself.
3255
3256         1. We do not use Objective-C weak mechanism. We use WTF::HashSet instead. When JSValue is allocated, we register it to JSWrapperMap's HashSet. And unregister
3257            JSValue from this map when JSValue is deallocated.
3258         2. We use HashSet<JSValue> (logically) instead of HashMap<JSValueRef, JSValue> to keep JSValueRef and JSValue relationship. We can achieve it because JSValue
3259            holds JSValueRef inside it.
3260
3261         * API/JSContext.mm:
3262         (-[JSContext removeWrapper:]):
3263         * API/JSContextInternal.h:
3264         * API/JSValue.mm:
3265         (-[JSValue dealloc]):
3266         (-[JSValue initWithValue:inContext:]):
3267         * API/JSWrapperMap.h:
3268         * API/JSWrapperMap.mm:
3269         (WrapperKey::hashTableDeletedValue):
3270         (WrapperKey::WrapperKey):
3271         (WrapperKey::isHashTableDeletedValue const):
3272         (WrapperKey::Hash::hash):
3273         (WrapperKey::Hash::equal):
3274         (WrapperKey::Traits::isEmptyValue):
3275         (WrapperKey::Translator::hash):
3276         (WrapperKey::Translator::equal):
3277         (WrapperKey::Translator::translate):
3278         (-[JSWrapperMap initWithGlobalContextRef:]):
3279         (-[JSWrapperMap dealloc]):
3280         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
3281         (-[JSWrapperMap removeWrapper:]):
3282         * API/tests/testapi.mm:
3283         (testObjectiveCAPIMain):
3284
3285 2019-03-29  Robin Morisset  <rmorisset@apple.com>
3286
3287         B3ReduceStrength should know that Mul distributes over Add and Sub
3288         https://bugs.webkit.org/show_bug.cgi?id=196325
3289
3290         Reviewed by Michael Saboff.
3291
3292         In this patch I add the following patterns to B3ReduceStrength:
3293         - Turn this: Integer Neg(Mul(value, c))
3294           Into this: Mul(value, -c), as long as -c does not overflow
3295         - Turn these: Integer Mul(value, Neg(otherValue)) and Integer Mul(Neg(value), otherValue)
3296           Into this: Neg(Mul(value, otherValue))
3297         - For Op==Add or Sub, turn any of these:
3298              Op(Mul(x1, x2), Mul(x1, x3))
3299              Op(Mul(x2, x1), Mul(x1, x3))
3300              Op(Mul(x1, x2), Mul(x3, x1))
3301              Op(Mul(x2, x1), Mul(x3, x1))
3302           Into this: Mul(x1, Op(x2, x3))
3303
3304         Also includes a trivial change: a similar reduction for the distributivity of BitAnd over BitOr/BitXor now
3305         emits the arguments to BitAnd in the other order, to minimize the probability that we'll spend a full fixpoint step just to flip them.
3306
3307         * b3/B3ReduceStrength.cpp:
3308         * b3/testb3.cpp:
3309         (JSC::B3::testAddMulMulArgs):
3310         (JSC::B3::testMulArgNegArg):
3311         (JSC::B3::testMulNegArgArg):
3312         (JSC::B3::testNegMulArgImm):
3313         (JSC::B3::testSubMulMulArgs):
3314         (JSC::B3::run):
3315
3316 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
3317
3318         [JSC] Remove distancing for LargeAllocation
3319         https://bugs.webkit.org/show_bug.cgi?id=196335
3320
3321         Reviewed by Saam Barati.
3322
3323         In r230226, we removed distancing feature from our GC. This patch removes remaining distancing thing in LargeAllocation.
3324
3325         * heap/HeapCell.h:
3326         * heap/LargeAllocation.cpp:
3327         (JSC::LargeAllocation::tryCreate):
3328         * heap/MarkedBlock.h:
3329
3330 2019-03-29  Myles C. Maxfield  <mmaxfield@apple.com>
3331
3332         Delete WebMetal implementation in favor of WebGPU
3333         https://bugs.webkit.org/show_bug.cgi?id=195418
3334
3335         Reviewed by Dean Jackson.
3336
3337         * Configurations/FeatureDefines.xcconfig:
3338         * inspector/protocol/Canvas.json:
3339         * inspector/scripts/codegen/generator.py:
3340
3341 2019-03-29  Tadeu Zagallo  <tzagallo@apple.com>
3342
3343         Assertion failed in JSC::createError
3344         https://bugs.webkit.org/show_bug.cgi?id=196305
3345         <rdar://problem/49387382>
3346
3347         Reviewed by Saam Barati.
3348
3349         JSC::createError assumes that `errorDescriptionForValue` will either
3350         throw an exception or return a valid description string. However, that
3351         is not true if the value is a rope string and we successfully resolve it,
3352         but later fail to wrap the string in quotes with `tryMakeString`.
3353
3354         * runtime/ExceptionHelpers.cpp:
3355         (JSC::createError):
3356
3357 2019-03-29  Devin Rousso  <drousso@apple.com>
3358
3359         Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
3360         https://bugs.webkit.org/show_bug.cgi?id=196382
3361         <rdar://problem/49403417>
3362
3363         Reviewed by Joseph Pecoraro.
3364
3365         Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
3366         `developerExtrasEnabled`. There should be no activity to/from any inspector objects until
3367         developer extras are enabled.
3368
3369         * inspector/agents/InspectorConsoleAgent.cpp:
3370         (Inspector::InspectorConsoleAgent::startTiming):
3371         (Inspector::InspectorConsoleAgent::stopTiming):
3372         (Inspector::InspectorConsoleAgent::count):
3373         (Inspector::InspectorConsoleAgent::addConsoleMessage):
3374
3375 2019-03-29  Cathie Chen  <cathiechen@igalia.com>
3376
3377         Implement ResizeObserver.
3378         https://bugs.webkit.org/show_bug.cgi?id=157743
3379
3380         Reviewed by Simon Fraser.
3381
3382         Add ENABLE_RESIZE_OBSERVER.
3383
3384         * Configurations/FeatureDefines.xcconfig:
3385
3386 2019-03-28  Michael Saboff  <msaboff@apple.com>
3387
3388         [YARR] Precompute BMP / non-BMP status when constructing character classes
3389         https://bugs.webkit.org/show_bug.cgi?id=196296
3390
3391         Reviewed by Keith Miller.
3392
3393         Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
3394         indicateis if the class includes characters from either BMP, non-BMP or both ranges.
3395         This allows the recognizing code to eliminate checks for the width of a matched
3396         characters when the class has only one width.  The character width is needed to
3397         determine if we advance 1 or 2 character.  Also, the pre-computed width of character
3398         classes that contains either all BMP or all non-BMP characters allows the parser to
3399         use fixed widths for terms using those character classes.  Changed both the code gen
3400         scripts and Yarr compiler to compute this bit field during the construction of
3401         character classes.
3402
3403         For JIT'ed code of character classes that contain either all BMP or all non-BMP
3404         characters, we can eliminate the generic check we were doing do compute how much
3405         to advance after sucessfully matching a character in the class.
3406
3407                 Generic isBMP check      BMP only            non-BMP only
3408                 --------------           --------------      --------------
3409                 inc %r9d                 inc %r9d            add $0x2, %r9d
3410                 cmp $0x10000, %eax
3411                 jl isBMP
3412                 cmp %edx, %esi
3413                 jz atEndOfString
3414                 inc %r9d
3415                 inc %esi
3416          isBMP:
3417
3418         For character classes that contained non-BMP characters, we were always generating
3419         the code in the left column.  The middle column is the code we generate for character
3420         classes that contain only BMP characters.  The right column is the code we now
3421         generate if the character class has only non-BMP characters.  In the fix width cases,
3422         we can eliminate both the isBMP check as well as the atEndOfString check.  The
3423         atEndOfstring check is eliminated since we know how many characters this character
3424         class requires and that check can be factored out to the beginning of the current
3425         alternative.  For character classes that contain both BMP and non-BMP characters,
3426         we still generate the generic left column.
3427
3428         This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
3429         as a whole.
3430
3431         * runtime/RegExp.cpp:
3432         (JSC::RegExp::matchCompareWithInterpreter):
3433         * runtime/RegExpInlines.h:
3434         (JSC::RegExp::matchInline):
3435         * yarr/YarrInterpreter.cpp:
3436         (JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
3437         (JSC::Yarr::Interpreter::matchCharacterClass):
3438         * yarr/YarrJIT.cpp:
3439         (JSC::Yarr::YarrGenerator::optimizeAlternative):
3440         (JSC::Yarr::YarrGenerator::matchCharacterClass):
3441         (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
3442         (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
3443         (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
3444         (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
3445         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
3446         (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
3447         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
3448         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
3449         (JSC::Yarr::YarrGenerator::generateEnter):
3450         (JSC::Yarr::YarrGenerator::YarrGenerator):
3451         (JSC::Yarr::YarrGenerator::compile):
3452         * yarr/YarrPattern.cpp:
3453         (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
3454         (JSC::Yarr::CharacterClassConstructor::reset):
3455         (JSC::Yarr::CharacterClassConstructor::charClass):
3456         (JSC::Yarr::CharacterClassConstructor::addSorted):
3457         (JSC::Yarr::CharacterClassConstructor::addSortedRange):
3458         (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
3459         (JSC::Yarr::CharacterClassConstructor::characterWidths):
3460         (JSC::Yarr::PatternTerm::dump):
3461         (JSC::Yarr::anycharCreate):
3462         * yarr/YarrPattern.h:
3463         (JSC::Yarr::operator|):
3464         (JSC::Yarr::operator&):
3465         (JSC::Yarr::operator|=):
3466         (JSC::Yarr::CharacterClass::CharacterClass):
3467         (JSC::Yarr::CharacterClass::hasNonBMPCharacters):
3468         (JSC::Yarr::CharacterClass::hasOneCharacterSize):
3469         (JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
3470         (JSC::Yarr::PatternTerm::invert const):
3471         (JSC::Yarr::PatternTerm::invert): Deleted.
3472         * yarr/create_regex_tables:
3473         * yarr/generateYarrUnicodePropertyTables.py:
3474
3475 2019-03-28  Saam Barati  <sbarati@apple.com>
3476
3477         BackwardsGraph needs to consider back edges as the backward's root successor
3478         https://bugs.webkit.org/show_bug.cgi?id=195991
3479
3480         Reviewed by Filip Pizlo.
3481
3482         * b3/testb3.cpp:
3483         (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
3484         (JSC::B3::run):
3485
3486 2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>
3487
3488         Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
3489         https://bugs.webkit.org/show_bug.cgi?id=196343
3490
3491         Reviewed by Saam Barati.
3492
3493         Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
3494         instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
3495
3496         * bytecode/Opcode.cpp:
3497         (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
3498         this function is used only in Opcode.cpp. Changed macros
3499         PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
3500         (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
3501         * bytecode/Opcode.h:
3502         (JSC::padOpcodeName): Moved.
3503
3504 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
3505
3506         CodeBlock::jettison() should disallow repatching its own calls
3507         https://bugs.webkit.org/show_bug.cgi?id=196359
3508         <rdar://problem/48973663>
3509
3510         Reviewed by Saam Barati.
3511
3512         CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
3513         instruction with the jump to OSR exit. However, if the `hlt` was immediately
3514         followed by a call to the CodeBlock being jettisoned, we would write over the
3515         OSR exit address while unlinking all the incoming CallLinkInfos later in
3516         CodeBlock::jettison().
3517
3518         Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
3519         owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
3520         repatching the call during unlinking. This is safe because this call will never
3521         be reachable again after the CodeBlock is jettisoned.
3522
3523         * bytecode/CallLinkInfo.cpp:
3524         (JSC::CallLinkInfo::CallLinkInfo):
3525         (JSC::CallLinkInfo::setCallee):
3526         (JSC::CallLinkInfo::clearCallee):
3527         (JSC::CallLinkInfo::setCodeBlock):
3528         (JSC::CallLinkInfo::clearCodeBlock):
3529         * bytecode/CallLinkInfo.h:
3530         (JSC::CallLinkInfo::clearedByJettison):
3531         (JSC::CallLinkInfo::setClearedByJettison):
3532         * bytecode/CodeBlock.cpp:
3533         (JSC::CodeBlock::jettison):
3534         * jit/Repatch.cpp:
3535         (JSC::revertCall):
3536
3537 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
3538
3539         [JSC] Drop VM and Context cache map in JavaScriptCore.framework
3540         https://bugs.webkit.org/show_bug.cgi?id=196341
3541
3542         Reviewed by Saam Barati.
3543
3544         Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
3545         But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
3546         JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
3547         a pointer to a wrapper in VM and JSGlobalObject.
3548
3549         This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
3550         clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
3551
3552         * API/JSContext.mm:
3553         (-[JSContext initWithVirtualMachine:]):
3554         (-[JSContext dealloc]):
3555         (-[JSContext initWithGlobalContextRef:]):
3556         (-[JSContext wrapperMap]):
3557         (+[JSContext contextWithJSGlobalContextRef:]):
3558         * API/JSVirtualMachine.mm:
3559         (-[JSVirtualMachine initWithContextGroupRef:]):
3560         (-[JSVirtualMachine dealloc]):
3561         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
3562         (scanExternalObjectGraph):
3563         (scanExternalRememberedSet):
3564         (initWrapperCache): Deleted.
3565         (wrapperCache): Deleted.
3566         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
3567         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
3568         (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
3569         (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
3570         * API/JSVirtualMachineInternal.h:
3571         * runtime/JSGlobalObject.h:
3572         (JSC::JSGlobalObject::setAPIWrapper):
3573         (JSC::JSGlobalObject::apiWrapper const):
3574         * runtime/VM.h:
3575
3576 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
3577
3578         In-memory code cache should not share bytecode across domains
3579         https://bugs.webkit.org/show_bug.cgi?id=196321
3580
3581         Reviewed by Geoffrey Garen.
3582
3583         Use the SourceProvider's URL to make sure that the hosts match for the
3584         two SourceCodeKeys in operator==.
3585
3586         * parser/SourceCodeKey.h:
3587         (JSC::SourceCodeKey::host const):
3588         (JSC::SourceCodeKey::operator== const):
3589
3590 2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>
3591
3592         Silence lot of warnings when compiling with clang
3593         https://bugs.webkit.org/show_bug.cgi?id=196310
3594
3595         Reviewed by Michael Catanzaro.
3596
3597         Initialize variable with default constructor.
3598
3599         * API/glib/JSCOptions.cpp:
3600         (jsc_options_foreach):
3601
3602 2019-03-27  Saam Barati  <sbarati@apple.com>
3603
3604         validateOSREntryValue with Int52 should box the value being checked into double format
3605         https://bugs.webkit.org/show_bug.cgi?id=196313
3606         <rdar://problem/49306703>
3607
3608         Reviewed by Yusuke Suzuki.
3609
3610         * dfg/DFGOSREntry.cpp:
3611         (JSC::DFG::prepareOSREntry):
3612         * ftl/FTLLowerDFGToB3.cpp:
3613         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
3614
3615 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
3616
3617         [JSC] Owner of watchpoints should validate at GC finalizing phase
3618         https://bugs.webkit.org/show_bug.cgi?id=195827
3619
3620         Reviewed by Filip Pizlo.
3621
3622         This patch fixes JSC's watchpoint liveness issue by the following two policies.
3623
3624         1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
3625
3626         Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
3627         When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
3628         be delayed due to incremental sweeper. So the following condition can happen.
3629
3630         When we have a watchpoint like the following.
3631
3632             class XXXWatchpoint {
3633                 ObjectPropertyCondition m_key;
3634                 JSCell* m_owner;
3635             };
3636
3637         Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
3638         is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
3639         watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
3640         we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
3641         `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
3642         once the destructor of m_owner is called, this watchpoint will be destroyed too.
3643
3644         2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
3645
3646         Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
3647         delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
3648         and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
3649         in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
3650         isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
3651         with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
3652         We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
3653
3654         * JavaScriptCore.xcodeproj/project.pbxproj:
3655         * Sources.txt:
3656         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
3657         (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
3658         (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
3659         * bytecode/CodeBlockJettisoningWatchpoint.h:
3660         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
3661         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
3662         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
3663         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
3664         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
3665         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
3666         * bytecode/StructureStubClearingWatchpoint.cpp:
3667         (JSC::StructureStubClearingWatchpoint::fireInternal):
3668         (JSC::WatchpointsOnStructureStubInfo::isValid const):
3669         * bytecode/StructureStubClearingWatchpoint.h:
3670         (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
3671         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
3672         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
3673         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
3674         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
3675         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
3676         * dfg/DFGAdaptiveStructureWatchpoint.h:
3677         (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
3678         * dfg/DFGDesiredWatchpoints.cpp:
3679         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
3680         * heap/Heap.cpp:
3681         (JSC::Heap::finalizeUnconditionalFinalizers):
3682         * llint/LLIntSlowPaths.cpp:
3683         (JSC::LLInt::setupGetByIdPrototypeCache):
3684         * runtime/ArrayBuffer.cpp:
3685         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
3686         * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
3687         (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
3688         (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
3689         (JSC::ArrayBufferNeuteringWatchpointSet::create):
3690         (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
3691         (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
3692         * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
3693         * runtime/FunctionRareData.h:
3694         * runtime/JSGlobalObject.cpp:
3695         (JSC::JSGlobalObject::init):
3696         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
3697         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
3698         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
3699         * runtime/StructureRareData.cpp:
3700         (JSC::StructureRareData::finalizeUnconditionally):
3701         * runtime/StructureRareData.h:
3702         * runtime/VM.cpp:
3703         (JSC::VM::VM):
3704
3705 2019-03-26  Saam Barati  <sbarati@apple.com>
3706
3707         FTL: Emit code to validate AI's state when running the compiled code
3708         https://bugs.webkit.org/show_bug.cgi?id=195924
3709         <rdar://problem/49003422>
3710
3711         Reviewed by Filip Pizlo.
3712
3713         This patch adds code that between the execution of each node that validates
3714         the types that AI proves. This option is too expensive to turn on for our
3715         regression testing, but we think it will be valuable in other types of running
3716         modes, such as when running with a fuzzer.
3717         
3718         This patch also adds options to only probabilistically run this validation
3719         after the execution of each node. As the probability is lowered, there is
3720         less of a perf hit.
3721         
3722         This patch just adds this validation in the FTL. A follow-up patch will land
3723         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
3724
3725         * ftl/FTLLowerDFGToB3.cpp:
3726         (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
3727         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
3728         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
3729         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3730         (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
3731         * runtime/Options.h:
3732
3733 2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
3734
3735         WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
3736         https://bugs.webkit.org/show_bug.cgi?id=196217
3737
3738         Reviewed by Saam Barati.
3739
3740         Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
3741         comparison in r243446 to all min and max float operations.
3742
3743         * wasm/WasmAirIRGenerator.cpp:
3744         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
3745         (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
3746         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
3747         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
3748         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
3749         * wasm/wasm.json:
3750
3751 2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
3752
3753         Intl.DateTimeFormat should obey 2-digit hour
3754         https://bugs.webkit.org/show_bug.cgi?id=195974
3755
3756         Reviewed by Keith Miller.
3757
3758         * runtime/IntlDateTimeFormat.cpp:
3759         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
3760
3761 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
3762
3763         Heap::isMarked and friends should be instance methods
3764         https://bugs.webkit.org/show_bug.cgi?id=179988
3765
3766         Reviewed by Saam Barati.
3767
3768         Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
3769         so that we do not need to look up Heap from the cell.
3770
3771         * API/JSAPIWrapperObject.mm:
3772         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
3773         * API/JSMarkingConstraintPrivate.cpp:
3774         (JSC::isMarked):
3775         * API/glib/JSAPIWrapperObjectGLib.cpp:
3776         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
3777         * builtins/BuiltinExecutables.cpp:
3778         (JSC::BuiltinExecutables::finalizeUnconditionally):
3779         * bytecode/AccessCase.cpp:
3780         (JSC::AccessCase::visitWeak const):
3781         (JSC::AccessCase::propagateTransitions const):
3782         * bytecode/CallLinkInfo.cpp:
3783         (JSC::CallLinkInfo::visitWeak):
3784         * bytecode/CallLinkStatus.cpp:
3785         (JSC::CallLinkStatus::finalize):
3786         * bytecode/CallLinkStatus.h:
3787         * bytecode/CallVariant.cpp:
3788         (JSC::CallVariant::finalize):
3789         * bytecode/CallVariant.h:
3790         * bytecode/CodeBlock.cpp:
3791         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
3792         (JSC::CodeBlock::shouldJettisonDueToOldAge):
3793         (JSC::shouldMarkTransition):
3794         (JSC::CodeBlock::propagateTransitions):
3795         (JSC::CodeBlock::determineLiveness):
3796         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3797         (JSC::CodeBlock::finalizeUnconditionally):
3798         (JSC::CodeBlock::jettison):
3799         * bytecode/CodeBlock.h:
3800         * bytecode/ExecutableToCodeBlockEdge.cpp:
3801         (JSC::ExecutableToCodeBlockEdge::visitChildren):
3802         (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
3803         (JSC::ExecutableToCodeBlockEdge::runConstraint):
3804         * bytecode/GetByIdStatus.cpp:
3805         (JSC::GetByIdStatus::finalize):
3806         * bytecode/GetByIdStatus.h:
3807         * bytecode/GetByIdVariant.cpp:
3808         (JSC::GetByIdVariant::finalize):
3809         * bytecode/GetByIdVariant.h:
3810         * bytecode/InByIdStatus.cpp:
3811         (JSC::InByIdStatus::finalize):
3812         * bytecode/InByIdStatus.h:
3813         * bytecode/InByIdVariant.cpp:
3814         (JSC::InByIdVariant::finalize):
3815         * bytecode/InByIdVariant.h:
3816         * bytecode/ObjectPropertyCondition.cpp:
3817         (JSC::ObjectPropertyCondition::isStillLive const):
3818         * bytecode/ObjectPropertyCondition.h:
3819         * bytecode/ObjectPropertyConditionSet.cpp:
3820         (JSC::ObjectPropertyConditionSet::areStillLive const):
3821         * bytecode/ObjectPropertyConditionSet.h:
3822         * bytecode/PolymorphicAccess.cpp:
3823         (JSC::PolymorphicAccess::visitWeak const):
3824         * bytecode/PropertyCondition.cpp:
3825         (JSC::PropertyCondition::isStillLive const):
3826         * bytecode/PropertyCondition.h:
3827         * bytecode/PutByIdStatus.cpp:
3828         (JSC::PutByIdStatus::finalize):
3829         * bytecode/PutByIdStatus.h:
3830         * bytecode/PutByIdVariant.cpp:
3831         (JSC::PutByIdVariant::finalize):
3832         * bytecode/PutByIdVariant.h:
3833         * bytecode/RecordedStatuses.cpp:
3834         (JSC::RecordedStatuses::finalizeWithoutDeleting):
3835         (JSC::RecordedStatuses::finalize):
3836         * bytecode/RecordedStatuses.h:
3837         * bytecode/StructureSet.cpp:
3838         (JSC::StructureSet::isStillAlive const):
3839         * bytecode/StructureSet.h:
3840         * bytecode/StructureStubInfo.cpp:
3841         (JSC::StructureStubInfo::visitWeakReferences):
3842         * dfg/DFGPlan.cpp:
3843         (JSC::DFG::Plan::finalizeInGC):
3844         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
3845         * heap/GCIncomingRefCounted.h:
3846         * heap/GCIncomingRefCountedInlines.h:
3847         (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
3848         * heap/GCIncomingRefCountedSet.h:
3849         * heap/GCIncomingRefCountedSetInlines.h:
3850         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):