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