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