UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-04-04  Tadeu Zagallo  <tzagallo@apple.com>
2
3         UnlinkedCodeBlock constructor from cache should initialize m_didOptimize
4         https://bugs.webkit.org/show_bug.cgi?id=196396
5
6         Reviewed by Saam Barati.
7
8         The UnlinkedCodeBlock constructor in CachedTypes was missing the initialization
9         for m_didOptimize, which leads to crashes in CodeBlock::thresholdForJIT.
10
11         * runtime/CachedTypes.cpp:
12         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
13
14 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
15
16         Unreviewed, rolling in r243843 with the build fix
17         https://bugs.webkit.org/show_bug.cgi?id=196586
18
19         * runtime/Options.cpp:
20         (JSC::recomputeDependentOptions):
21         * runtime/Options.h:
22         * runtime/RandomizingFuzzerAgent.cpp:
23         (JSC::RandomizingFuzzerAgent::getPrediction):
24
25 2019-04-03  Ryan Haddad  <ryanhaddad@apple.com>
26
27         Unreviewed, rolling out r243843.
28
29         Broke CLoop and Windows builds.
30
31         Reverted changeset:
32
33         "[JSC] Add dump feature for RandomizingFuzzerAgent"
34         https://bugs.webkit.org/show_bug.cgi?id=196586
35         https://trac.webkit.org/changeset/243843
36
37 2019-04-03  Robin Morisset  <rmorisset@apple.com>
38
39         B3 should use associativity to optimize expression trees
40         https://bugs.webkit.org/show_bug.cgi?id=194081
41
42         Reviewed by Filip Pizlo.
43
44         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).
45         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).
46         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
47         inherited from CSE.
48         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).
49         I suspect it is because it runs between CSE and tail-dedup, and as a result allows a lot more tail-dedup to occur.
50
51         The pass is currently extremely conservative, not trying anything if it would cause _any_ code duplication.
52         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.
53         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.
54         The leaves of an expression tree are nodes that are either used in multiple places, or have a different opcode.
55         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.
56
57         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.
58         It also benefits from finding all tree roots first, and not trying to repeatedly optimize subtrees.
59
60         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.
61
62         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))
63         The latter will need exposing the peephole optimizations out of B3ReduceStrength to avoid duplicating code.
64
65         * JavaScriptCore.xcodeproj/project.pbxproj:
66         * Sources.txt:
67         * b3/B3Common.cpp:
68         (JSC::B3::shouldDumpIR):
69         (JSC::B3::shouldDumpIRAtEachPhase):
70         * b3/B3Common.h:
71         * b3/B3EliminateDeadCode.cpp: Added.
72         (JSC::B3::EliminateDeadCode::run):
73         (JSC::B3::eliminateDeadCode):
74         * b3/B3EliminateDeadCode.h: Added.
75         (JSC::B3::EliminateDeadCode::EliminateDeadCode):
76         * b3/B3Generate.cpp:
77         (JSC::B3::generateToAir):
78         * b3/B3OptimizeAssociativeExpressionTrees.cpp: Added.
79         (JSC::B3::OptimizeAssociativeExpressionTrees::OptimizeAssociativeExpressionTrees):
80         (JSC::B3::OptimizeAssociativeExpressionTrees::neutralElement):
81         (JSC::B3::OptimizeAssociativeExpressionTrees::isAbsorbingElement):
82         (JSC::B3::OptimizeAssociativeExpressionTrees::combineConstants):
83         (JSC::B3::OptimizeAssociativeExpressionTrees::emitValue):
84         (JSC::B3::OptimizeAssociativeExpressionTrees::optimizeRootedTree):
85         (JSC::B3::OptimizeAssociativeExpressionTrees::run):
86         (JSC::B3::optimizeAssociativeExpressionTrees):
87         * b3/B3OptimizeAssociativeExpressionTrees.h: Added.
88         * b3/B3ReduceStrength.cpp:
89         * b3/B3Value.cpp:
90         (JSC::B3::Value::replaceWithIdentity):
91         * b3/testb3.cpp:
92         (JSC::B3::testBitXorTreeArgs):
93         (JSC::B3::testBitXorTreeArgsEven):
94         (JSC::B3::testBitXorTreeArgImm):
95         (JSC::B3::testAddTreeArg32):
96         (JSC::B3::testMulTreeArg32):
97         (JSC::B3::testBitAndTreeArg32):
98         (JSC::B3::testBitOrTreeArg32):
99         (JSC::B3::run):
100
101 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
102
103         [JSC] Add dump feature for RandomizingFuzzerAgent
104         https://bugs.webkit.org/show_bug.cgi?id=196586
105
106         Reviewed by Saam Barati.
107
108         Towards deterministic tests for the results from randomizing fuzzer agent, this patch adds Options::dumpRandomizingFuzzerAgentPredictions, which dumps the generated types.
109         The results is like this.
110
111             getPrediction name:(#C2q9xD),bytecodeIndex:(22),original:(Array),generated:(OtherObj|Array|Float64Array|BigInt|NonIntAsDouble)
112             getPrediction name:(makeUnwriteableUnconfigurableObject#AiEJv1),bytecodeIndex:(14),original:(OtherObj),generated:(Final|Uint8Array|Float64Array|SetObject|WeakSetObject|BigInt|NonIntAsDouble)
113
114         * runtime/Options.cpp:
115         (JSC::recomputeDependentOptions):
116         * runtime/Options.h:
117         * runtime/RandomizingFuzzerAgent.cpp:
118         (JSC::RandomizingFuzzerAgent::getPrediction):
119
120 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
121
122         -apple-trailing-word is needed for browser detection
123         https://bugs.webkit.org/show_bug.cgi?id=196575
124
125         Unreviewed.
126
127         * Configurations/FeatureDefines.xcconfig:
128
129 2019-04-03  Michael Saboff  <msaboff@apple.com>
130
131         REGRESSION (r243642): com.apple.JavaScriptCore crash in JSC::RegExpObject::execInline
132         https://bugs.webkit.org/show_bug.cgi?id=196477
133
134         Reviewed by Keith Miller.
135
136         The problem here is that when we advance the index by 2 for a character class that only
137         has non-BMP characters, we might go past the end of the string.  This can happen for
138         greedy counted character classes that are part of a alternative where there is one
139         character to match after the greedy non-BMP character class.
140
141         The "do we have string left to match" check at the top of the JIT loop for the counted
142         character class checks to see if index is not equal to the string length.  For non-BMP
143         character classes, we need to check to see if there are at least 2 characters left.
144         Therefore we now temporarily add 1 to the current index before comparing.  This checks
145         to see if there are iat least 2 characters left to match, instead of 1.
146
147         * yarr/YarrJIT.cpp:
148         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
149         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
150
151 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
152
153         [JSC] Exception verification crash on operationArrayIndexOfValueInt32OrContiguous
154         https://bugs.webkit.org/show_bug.cgi?id=196574
155
156         Reviewed by Saam Barati.
157
158         This patch adds missing exception check in operationArrayIndexOfValueInt32OrContiguous.
159
160         * dfg/DFGOperations.cpp:
161
162 2019-04-03  Don Olmstead  <don.olmstead@sony.com>
163
164         [CMake][WTF] Mirror XCode header directories
165         https://bugs.webkit.org/show_bug.cgi?id=191662
166
167         Reviewed by Konstantin Tokarev.
168
169         Use WTFFramework as a dependency and include frameworks/WTF.cmake for AppleWin internal
170         builds.
171
172         * CMakeLists.txt:
173         * shell/CMakeLists.txt:
174
175 2019-04-03  Yusuke Suzuki  <ysuzuki@apple.com>
176
177         [JSC] Add FuzzerAgent, which has a hooks to get feedback & inject fuzz data into JSC
178         https://bugs.webkit.org/show_bug.cgi?id=196530
179
180         Reviewed by Saam Barati.
181
182         This patch adds FuzzerAgent interface and simple RandomizingFuzzerAgent to JSC.
183         This RandomizingFuzzerAgent returns random SpeculatedType for value profiling to find
184         the issues in JSC. The seed for randomization can be specified by seedOfRandomizingFuzzerAgent.
185
186         I ran this with seedOfRandomizingFuzzerAgent=1 last night and it finds 3 failures in the current JSC tests,
187         they should be fixed in subsequent patches.
188
189         * CMakeLists.txt:
190         * JavaScriptCore.xcodeproj/project.pbxproj:
191         * Sources.txt:
192         * dfg/DFGByteCodeParser.cpp:
193         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
194         * runtime/FuzzerAgent.cpp: Added.
195         (JSC::FuzzerAgent::~FuzzerAgent):
196         (JSC::FuzzerAgent::getPrediction):
197         * runtime/FuzzerAgent.h: Added.
198         * runtime/JSGlobalObjectFunctions.cpp:
199         * runtime/Options.h:
200         * runtime/RandomizingFuzzerAgent.cpp: Added.
201         (JSC::RandomizingFuzzerAgent::RandomizingFuzzerAgent):
202         (JSC::RandomizingFuzzerAgent::getPrediction):
203         * runtime/RandomizingFuzzerAgent.h: Added.
204         * runtime/RegExpCachedResult.h:
205         * runtime/RegExpGlobalData.cpp:
206         * runtime/VM.cpp:
207         (JSC::VM::VM):
208         * runtime/VM.h:
209         (JSC::VM::fuzzerAgent const):
210         (JSC::VM::setFuzzerAgent):
211
212 2019-04-03  Myles C. Maxfield  <mmaxfield@apple.com>
213
214         Remove support for -apple-trailing-word
215         https://bugs.webkit.org/show_bug.cgi?id=196525
216
217         Reviewed by Zalan Bujtas.
218
219         This CSS property is nonstandard and not used.
220
221         * Configurations/FeatureDefines.xcconfig:
222
223 2019-04-03  Joseph Pecoraro  <pecoraro@apple.com>
224
225         Web Inspector: Remote Inspector indicate callback should always happen on the main thread
226         https://bugs.webkit.org/show_bug.cgi?id=196513
227         <rdar://problem/49498284>
228
229         Reviewed by Devin Rousso.
230
231         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
232         (Inspector::RemoteInspector::receivedIndicateMessage):
233         When we have a WebThread, don't just run on the WebThread,
234         run on the MainThread with the WebThreadLock.
235
236 2019-04-02  Michael Saboff  <msaboff@apple.com>
237
238         Crash in Options::setOptions() using --configFile option and libgmalloc
239         https://bugs.webkit.org/show_bug.cgi?id=196506
240
241         Reviewed by Keith Miller.
242
243         Changed to call CString::data() while making the call to Options::setOptions().  This keeps
244         the implicit CString temporary alive until after setOptions() returns.
245
246         * runtime/ConfigFile.cpp:
247         (JSC::ConfigFile::parse):
248
249 2019-04-02  Fujii Hironori  <Hironori.Fujii@sony.com>
250
251         [CMake] WEBKIT_MAKE_FORWARDING_HEADERS shouldn't use POST_BUILD to copy generated headers
252         https://bugs.webkit.org/show_bug.cgi?id=182757
253
254         Reviewed by Don Olmstead.
255
256         * CMakeLists.txt: Do not use DERIVED_SOURCE_DIRECTORIES parameter
257         of WEBKIT_MAKE_FORWARDING_HEADERS. Added generated headers to
258         JavaScriptCore_PRIVATE_FRAMEWORK_HEADERS.
259
260 2019-04-02  Saam barati  <sbarati@apple.com>
261
262         Add a ValueRepReduction phase
263         https://bugs.webkit.org/show_bug.cgi?id=196234
264
265         Reviewed by Filip Pizlo.
266
267         This patch adds a ValueRepReduction phase. The main idea here is
268         to try to reduce DoubleRep(RealNumberUse:ValueRep(DoubleRepUse:@x))
269         to just be @x. This patch handles such above strengh reduction rules
270         as long as we prove that all users of the ValueRep can be converted
271         to using the incoming double value. That way we prevent introducing
272         a parallel live range for the double value.
273         
274         This patch tracks the uses of the ValueRep through Phi variables,
275         so we can convert entire Phi variables to being Double instead
276         of JSValue if the Phi also has only double uses.
277         
278         This is implemented through a simple escape analysis. DoubleRep(RealNumberUse:)
279         and OSR exit hints are not counted as escapes. All other uses are counted
280         as escapes. Connected Phi graphs are converted to being Double only if the
281         entire graph is ok with the result being Double.
282         
283         Some ways we could extend this phase in the future:
284         - There are a lot of DoubleRep(NumberUse:@ValueRep(@x)) uses. This ensures
285           that the result of the DoubleRep of @x is not impure NaN. We could
286           handle this case if we introduced a PurifyNaN node and replace the DoubleRep
287           with PurifyNaN(@x). Alternatively, we could see if certain users of this
288           DoubleRep are okay with impure NaN flowing into them and we'd need to ensure
289           their output type is always treated as if the input is impure NaN.
290         - We could do sinking of ValueRep where we think it's profitable. So instead
291           of an escape making it so we never represent the variable as a Double, we
292           could make the escape reconstruct the JSValueRep where profitable.
293         - We can extend this phase to handle Int52Rep if it's profitable.
294         - We can opt other nodes into accepting incoming Doubles so we no longer
295           treat them as escapes.
296         
297         This patch is somewhere between neutral and a 1% progression on JetStream 2.
298
299         * JavaScriptCore.xcodeproj/project.pbxproj:
300         * Sources.txt:
301         * dfg/DFGPlan.cpp:
302         (JSC::DFG::Plan::compileInThreadImpl):
303         * dfg/DFGValueRepReductionPhase.cpp: Added.
304         (JSC::DFG::ValueRepReductionPhase::ValueRepReductionPhase):
305         (JSC::DFG::ValueRepReductionPhase::run):
306         (JSC::DFG::ValueRepReductionPhase::convertValueRepsToDouble):
307         (JSC::DFG::performValueRepReduction):
308         * dfg/DFGValueRepReductionPhase.h: Added.
309         * runtime/Options.h:
310
311 2019-04-01  Yusuke Suzuki  <ysuzuki@apple.com>
312
313         [JSC] JSRunLoopTimer::Manager should be small
314         https://bugs.webkit.org/show_bug.cgi?id=196425
315
316         Reviewed by Darin Adler.
317
318         Using very large Key or Value in HashMap potentially bloats memory since HashMap pre-allocates large size of
319         memory ((sizeof(Key) + sizeof(Value)) * N) for its backing storage's array. Using std::unique_ptr<> for JSRunLoopTimer's
320         PerVMData to keep HashMap's backing store size small.
321
322         * runtime/JSRunLoopTimer.cpp:
323         (JSC::JSRunLoopTimer::Manager::timerDidFire):
324         (JSC::JSRunLoopTimer::Manager::registerVM):
325         (JSC::JSRunLoopTimer::Manager::scheduleTimer):
326         (JSC::JSRunLoopTimer::Manager::cancelTimer):
327         (JSC::JSRunLoopTimer::Manager::timeUntilFire):
328         (JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
329         * runtime/JSRunLoopTimer.h:
330
331 2019-04-01  Stephan Szabo  <stephan.szabo@sony.com>
332
333         [PlayStation] Add initialization for JSC shell for PlayStation port
334         https://bugs.webkit.org/show_bug.cgi?id=195411
335
336         Reviewed by Ross Kirsling.
337
338         Add ps options
339
340         * shell/PlatformPlayStation.cmake: Added.
341         * shell/playstation/Initializer.cpp: Added.
342         (initializer):
343
344 2019-04-01  Michael Catanzaro  <mcatanzaro@igalia.com>
345
346         Stop trying to support building JSC with clang 3.8
347         https://bugs.webkit.org/show_bug.cgi?id=195947
348         <rdar://problem/49069219>
349
350         Reviewed by Darin Adler.
351
352         It seems WebKit hasn't built with clang 3.8 in a while, no devs are using this compiler, we
353         don't know how much effort it would be to make JSC work again, and it's making the code
354         worse. Remove my hacks to support clang 3.8 from JSC.
355
356         * bindings/ScriptValue.cpp:
357         (Inspector::jsToInspectorValue):
358         * bytecode/GetterSetterAccessCase.cpp:
359         (JSC::GetterSetterAccessCase::create):
360         (JSC::GetterSetterAccessCase::clone const):
361         * bytecode/InstanceOfAccessCase.cpp:
362         (JSC::InstanceOfAccessCase::clone const):
363         * bytecode/IntrinsicGetterAccessCase.cpp:
364         (JSC::IntrinsicGetterAccessCase::clone const):
365         * bytecode/ModuleNamespaceAccessCase.cpp:
366         (JSC::ModuleNamespaceAccessCase::clone const):
367         * bytecode/ProxyableAccessCase.cpp:
368         (JSC::ProxyableAccessCase::clone const):
369
370 2019-03-31  Yusuke Suzuki  <ysuzuki@apple.com>
371
372         [JSC] Butterfly allocation from LargeAllocation should try "realloc" behavior if collector thread is not active
373         https://bugs.webkit.org/show_bug.cgi?id=196160
374
375         Reviewed by Saam Barati.
376
377         "realloc" can be effective in terms of peak/current memory footprint when realloc succeeds because,
378
379         1. It does not allocate additional memory while expanding a vector
380         2. It does not deallocate an old memory, just reusing the current memory by expanding, so that memory footprint is tight even before scavenging
381
382         We found that we can "realloc" large butterflies in certain conditions are met because,
383
384         1. If it goes to LargeAllocation, this memory region is never reused until GC sweeps it.
385         2. Butterflies are owned by owner JSObjects, so we know the lifetime of Butterflies.
386
387         This patch attempts to use "realloc" onto butterflies if,
388
389         1. Butterflies are allocated in LargeAllocation kind
390         2. Concurrent collector is not active
391         3. Butterflies do not have property storage
392
393         The condition (2) is required to avoid deallocating butterflies while the concurrent collector looks into it. The condition (3) is
394         also required to avoid deallocating butterflies while the concurrent compiler looks into it.
395
396         We also change LargeAllocation mechanism to using "malloc" and "free" instead of "posix_memalign". This allows us to use "realloc"
397         safely in all the platforms. Since LargeAllocation uses alignment to distinguish LargeAllocation and MarkedBlock, we manually adjust
398         16B alignment by allocating 8B more memory in "malloc".
399
400         Speedometer2 and JetStream2 are neutral. RAMification shows about 1% progression (even in some of JIT tests).
401
402         * heap/AlignedMemoryAllocator.h:
403         * heap/CompleteSubspace.cpp:
404         (JSC::CompleteSubspace::tryAllocateSlow):
405         (JSC::CompleteSubspace::reallocateLargeAllocationNonVirtual):
406         * heap/CompleteSubspace.h:
407         * heap/FastMallocAlignedMemoryAllocator.cpp:
408         (JSC::FastMallocAlignedMemoryAllocator::tryAllocateMemory):
409         (JSC::FastMallocAlignedMemoryAllocator::freeMemory):
410         (JSC::FastMallocAlignedMemoryAllocator::tryReallocateMemory):
411         * heap/FastMallocAlignedMemoryAllocator.h:
412         * heap/GigacageAlignedMemoryAllocator.cpp:
413         (JSC::GigacageAlignedMemoryAllocator::tryAllocateMemory):
414         (JSC::GigacageAlignedMemoryAllocator::freeMemory):
415         (JSC::GigacageAlignedMemoryAllocator::tryReallocateMemory):
416         * heap/GigacageAlignedMemoryAllocator.h:
417         * heap/IsoAlignedMemoryAllocator.cpp:
418         (JSC::IsoAlignedMemoryAllocator::tryAllocateMemory):
419         (JSC::IsoAlignedMemoryAllocator::freeMemory):
420         (JSC::IsoAlignedMemoryAllocator::tryReallocateMemory):
421         * heap/IsoAlignedMemoryAllocator.h:
422         * heap/LargeAllocation.cpp:
423         (JSC::isAlignedForLargeAllocation):
424         (JSC::LargeAllocation::tryCreate):
425         (JSC::LargeAllocation::tryReallocate):
426         (JSC::LargeAllocation::LargeAllocation):
427         (JSC::LargeAllocation::destroy):
428         * heap/LargeAllocation.h:
429         (JSC::LargeAllocation::indexInSpace):
430         (JSC::LargeAllocation::setIndexInSpace):
431         (JSC::LargeAllocation::basePointer const):
432         * heap/MarkedSpace.cpp:
433         (JSC::MarkedSpace::sweepLargeAllocations):
434         (JSC::MarkedSpace::prepareForConservativeScan):
435         * heap/WeakSet.h:
436         (JSC::WeakSet::isTriviallyDestructible const):
437         * runtime/Butterfly.h:
438         * runtime/ButterflyInlines.h:
439         (JSC::Butterfly::reallocArrayRightIfPossible):
440         * runtime/JSObject.cpp:
441         (JSC::JSObject::ensureLengthSlow):
442
443 2019-03-31  Sam Weinig  <weinig@apple.com>
444
445         Remove more i386 specific configurations
446         https://bugs.webkit.org/show_bug.cgi?id=196430
447
448         Reviewed by Alexey Proskuryakov.
449
450         * Configurations/FeatureDefines.xcconfig:
451         ENABLE_WEB_AUTHN_macosx can now be enabled unconditionally on macOS.
452
453         * Configurations/ToolExecutable.xcconfig:
454         ARC can be enabled unconditionally now.
455
456 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
457
458         [JSC] JSWrapperMap should not use Objective-C Weak map (NSMapTable with NSPointerFunctionsWeakMemory) for m_cachedObjCWrappers
459         https://bugs.webkit.org/show_bug.cgi?id=196392
460
461         Reviewed by Saam Barati.
462
463         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
464         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
465         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,
466         and wrapper map is created per JSContext, JSValue wrapper and actual JavaScriptCore value is one-on-one, and [JSValue dealloc] knows which JSContext's
467         wrapper map holds itself.
468
469         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
470            JSValue from this map when JSValue is deallocated.
471         2. We use HashSet<JSValue> (logically) instead of HashMap<JSValueRef, JSValue> to keep JSValueRef and JSValue relationship. We can achieve it because JSValue
472            holds JSValueRef inside it.
473
474         * API/JSContext.mm:
475         (-[JSContext removeWrapper:]):
476         * API/JSContextInternal.h:
477         * API/JSValue.mm:
478         (-[JSValue dealloc]):
479         (-[JSValue initWithValue:inContext:]):
480         * API/JSWrapperMap.h:
481         * API/JSWrapperMap.mm:
482         (WrapperKey::hashTableDeletedValue):
483         (WrapperKey::WrapperKey):
484         (WrapperKey::isHashTableDeletedValue const):
485         (WrapperKey::Hash::hash):
486         (WrapperKey::Hash::equal):
487         (WrapperKey::Traits::isEmptyValue):
488         (WrapperKey::Translator::hash):
489         (WrapperKey::Translator::equal):
490         (WrapperKey::Translator::translate):
491         (-[JSWrapperMap initWithGlobalContextRef:]):
492         (-[JSWrapperMap dealloc]):
493         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
494         (-[JSWrapperMap removeWrapper:]):
495         * API/tests/testapi.mm:
496         (testObjectiveCAPIMain):
497
498 2019-03-29  Robin Morisset  <rmorisset@apple.com>
499
500         B3ReduceStrength should know that Mul distributes over Add and Sub
501         https://bugs.webkit.org/show_bug.cgi?id=196325
502
503         Reviewed by Michael Saboff.
504
505         In this patch I add the following patterns to B3ReduceStrength:
506         - Turn this: Integer Neg(Mul(value, c))
507           Into this: Mul(value, -c), as long as -c does not overflow
508         - Turn these: Integer Mul(value, Neg(otherValue)) and Integer Mul(Neg(value), otherValue)
509           Into this: Neg(Mul(value, otherValue))
510         - For Op==Add or Sub, turn any of these:
511              Op(Mul(x1, x2), Mul(x1, x3))
512              Op(Mul(x2, x1), Mul(x1, x3))
513              Op(Mul(x1, x2), Mul(x3, x1))
514              Op(Mul(x2, x1), Mul(x3, x1))
515           Into this: Mul(x1, Op(x2, x3))
516
517         Also includes a trivial change: a similar reduction for the distributivity of BitAnd over BitOr/BitXor now
518         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.
519
520         * b3/B3ReduceStrength.cpp:
521         * b3/testb3.cpp:
522         (JSC::B3::testAddMulMulArgs):
523         (JSC::B3::testMulArgNegArg):
524         (JSC::B3::testMulNegArgArg):
525         (JSC::B3::testNegMulArgImm):
526         (JSC::B3::testSubMulMulArgs):
527         (JSC::B3::run):
528
529 2019-03-29  Yusuke Suzuki  <ysuzuki@apple.com>
530
531         [JSC] Remove distancing for LargeAllocation
532         https://bugs.webkit.org/show_bug.cgi?id=196335
533
534         Reviewed by Saam Barati.
535
536         In r230226, we removed distancing feature from our GC. This patch removes remaining distancing thing in LargeAllocation.
537
538         * heap/HeapCell.h:
539         * heap/LargeAllocation.cpp:
540         (JSC::LargeAllocation::tryCreate):
541         * heap/MarkedBlock.h:
542
543 2019-03-29  Myles C. Maxfield  <mmaxfield@apple.com>
544
545         Delete WebMetal implementation in favor of WebGPU
546         https://bugs.webkit.org/show_bug.cgi?id=195418
547
548         Reviewed by Dean Jackson.
549
550         * Configurations/FeatureDefines.xcconfig:
551         * inspector/protocol/Canvas.json:
552         * inspector/scripts/codegen/generator.py:
553
554 2019-03-29  Tadeu Zagallo  <tzagallo@apple.com>
555
556         Assertion failed in JSC::createError
557         https://bugs.webkit.org/show_bug.cgi?id=196305
558         <rdar://problem/49387382>
559
560         Reviewed by Saam Barati.
561
562         JSC::createError assumes that `errorDescriptionForValue` will either
563         throw an exception or return a valid description string. However, that
564         is not true if the value is a rope string and we successfully resolve it,
565         but later fail to wrap the string in quotes with `tryMakeString`.
566
567         * runtime/ExceptionHelpers.cpp:
568         (JSC::createError):
569
570 2019-03-29  Devin Rousso  <drousso@apple.com>
571
572         Web Inspector: add fast returns for instrumentation hooks that have no affect before a frontend is connected
573         https://bugs.webkit.org/show_bug.cgi?id=196382
574         <rdar://problem/49403417>
575
576         Reviewed by Joseph Pecoraro.
577
578         Ensure that all instrumentation hooks use `FAST_RETURN_IF_NO_FRONTENDS` or check that
579         `developerExtrasEnabled`. There should be no activity to/from any inspector objects until
580         developer extras are enabled.
581
582         * inspector/agents/InspectorConsoleAgent.cpp:
583         (Inspector::InspectorConsoleAgent::startTiming):
584         (Inspector::InspectorConsoleAgent::stopTiming):
585         (Inspector::InspectorConsoleAgent::count):
586         (Inspector::InspectorConsoleAgent::addConsoleMessage):
587
588 2019-03-29  Cathie Chen  <cathiechen@igalia.com>
589
590         Implement ResizeObserver.
591         https://bugs.webkit.org/show_bug.cgi?id=157743
592
593         Reviewed by Simon Fraser.
594
595         Add ENABLE_RESIZE_OBSERVER.
596
597         * Configurations/FeatureDefines.xcconfig:
598
599 2019-03-28  Michael Saboff  <msaboff@apple.com>
600
601         [YARR] Precompute BMP / non-BMP status when constructing character classes
602         https://bugs.webkit.org/show_bug.cgi?id=196296
603
604         Reviewed by Keith Miller.
605
606         Changed CharacterClass::m_hasNonBMPCharacters into a character width bit field which
607         indicateis if the class includes characters from either BMP, non-BMP or both ranges.
608         This allows the recognizing code to eliminate checks for the width of a matched
609         characters when the class has only one width.  The character width is needed to
610         determine if we advance 1 or 2 character.  Also, the pre-computed width of character
611         classes that contains either all BMP or all non-BMP characters allows the parser to
612         use fixed widths for terms using those character classes.  Changed both the code gen
613         scripts and Yarr compiler to compute this bit field during the construction of
614         character classes.
615
616         For JIT'ed code of character classes that contain either all BMP or all non-BMP
617         characters, we can eliminate the generic check we were doing do compute how much
618         to advance after sucessfully matching a character in the class.
619
620                 Generic isBMP check      BMP only            non-BMP only
621                 --------------           --------------      --------------
622                 inc %r9d                 inc %r9d            add $0x2, %r9d
623                 cmp $0x10000, %eax
624                 jl isBMP
625                 cmp %edx, %esi
626                 jz atEndOfString
627                 inc %r9d
628                 inc %esi
629          isBMP:
630
631         For character classes that contained non-BMP characters, we were always generating
632         the code in the left column.  The middle column is the code we generate for character
633         classes that contain only BMP characters.  The right column is the code we now
634         generate if the character class has only non-BMP characters.  In the fix width cases,
635         we can eliminate both the isBMP check as well as the atEndOfString check.  The
636         atEndOfstring check is eliminated since we know how many characters this character
637         class requires and that check can be factored out to the beginning of the current
638         alternative.  For character classes that contain both BMP and non-BMP characters,
639         we still generate the generic left column.
640
641         This change is a ~8% perf progression on UniPoker and a ~2% improvement on RexBench
642         as a whole.
643
644         * runtime/RegExp.cpp:
645         (JSC::RegExp::matchCompareWithInterpreter):
646         * runtime/RegExpInlines.h:
647         (JSC::RegExp::matchInline):
648         * yarr/YarrInterpreter.cpp:
649         (JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
650         (JSC::Yarr::Interpreter::matchCharacterClass):
651         * yarr/YarrJIT.cpp:
652         (JSC::Yarr::YarrGenerator::optimizeAlternative):
653         (JSC::Yarr::YarrGenerator::matchCharacterClass):
654         (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch):
655         (JSC::Yarr::YarrGenerator::tryReadUnicodeCharImpl):
656         (JSC::Yarr::YarrGenerator::generateCharacterClassOnce):
657         (JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
658         (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
659         (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy):
660         (JSC::Yarr::YarrGenerator::generateCharacterClassNonGreedy):
661         (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
662         (JSC::Yarr::YarrGenerator::generateEnter):
663         (JSC::Yarr::YarrGenerator::YarrGenerator):
664         (JSC::Yarr::YarrGenerator::compile):
665         * yarr/YarrPattern.cpp:
666         (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor):
667         (JSC::Yarr::CharacterClassConstructor::reset):
668         (JSC::Yarr::CharacterClassConstructor::charClass):
669         (JSC::Yarr::CharacterClassConstructor::addSorted):
670         (JSC::Yarr::CharacterClassConstructor::addSortedRange):
671         (JSC::Yarr::CharacterClassConstructor::hasNonBMPCharacters):
672         (JSC::Yarr::CharacterClassConstructor::characterWidths):
673         (JSC::Yarr::PatternTerm::dump):
674         (JSC::Yarr::anycharCreate):
675         * yarr/YarrPattern.h:
676         (JSC::Yarr::operator|):
677         (JSC::Yarr::operator&):
678         (JSC::Yarr::operator|=):
679         (JSC::Yarr::CharacterClass::CharacterClass):
680         (JSC::Yarr::CharacterClass::hasNonBMPCharacters):
681         (JSC::Yarr::CharacterClass::hasOneCharacterSize):
682         (JSC::Yarr::CharacterClass::hasOnlyNonBMPCharacters):
683         (JSC::Yarr::PatternTerm::invert const):
684         (JSC::Yarr::PatternTerm::invert): Deleted.
685         * yarr/create_regex_tables:
686         * yarr/generateYarrUnicodePropertyTables.py:
687
688 2019-03-28  Saam Barati  <sbarati@apple.com>
689
690         BackwardsGraph needs to consider back edges as the backward's root successor
691         https://bugs.webkit.org/show_bug.cgi?id=195991
692
693         Reviewed by Filip Pizlo.
694
695         * b3/testb3.cpp:
696         (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting):
697         (JSC::B3::run):
698
699 2019-03-28  Fujii Hironori  <Hironori.Fujii@sony.com>
700
701         Opcode.h(159,27): warning: adding 'unsigned int' to a string does not append to the string [-Wstring-plus-int]
702         https://bugs.webkit.org/show_bug.cgi?id=196343
703
704         Reviewed by Saam Barati.
705
706         Clang reports a compilation warning and recommend '&PADDING_STRING[PADDING_STRING_LENGTH]'
707         instead of 'PADDING_STRING + PADDING_STRING_LENGTH'.
708
709         * bytecode/Opcode.cpp:
710         (JSC::padOpcodeName): Moved padOpcodeName from Opcode.h because
711         this function is used only in Opcode.cpp. Changed macros
712         PADDING_STRING and PADDING_STRING_LENGTH to simple variables.
713         (JSC::compareOpcodePairIndices): Replaced pair with std::pair.
714         * bytecode/Opcode.h:
715         (JSC::padOpcodeName): Moved.
716
717 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
718
719         CodeBlock::jettison() should disallow repatching its own calls
720         https://bugs.webkit.org/show_bug.cgi?id=196359
721         <rdar://problem/48973663>
722
723         Reviewed by Saam Barati.
724
725         CodeBlock::jettison() calls CommonData::invalidate, which replaces the `hlt`
726         instruction with the jump to OSR exit. However, if the `hlt` was immediately
727         followed by a call to the CodeBlock being jettisoned, we would write over the
728         OSR exit address while unlinking all the incoming CallLinkInfos later in
729         CodeBlock::jettison().
730
731         Change it so that we set a flag, `clearedByJettison`, in all the CallLinkInfos
732         owned by the CodeBlock being jettisoned. If the flag is set, we will avoid
733         repatching the call during unlinking. This is safe because this call will never
734         be reachable again after the CodeBlock is jettisoned.
735
736         * bytecode/CallLinkInfo.cpp:
737         (JSC::CallLinkInfo::CallLinkInfo):
738         (JSC::CallLinkInfo::setCallee):
739         (JSC::CallLinkInfo::clearCallee):
740         (JSC::CallLinkInfo::setCodeBlock):
741         (JSC::CallLinkInfo::clearCodeBlock):
742         * bytecode/CallLinkInfo.h:
743         (JSC::CallLinkInfo::clearedByJettison):
744         (JSC::CallLinkInfo::setClearedByJettison):
745         * bytecode/CodeBlock.cpp:
746         (JSC::CodeBlock::jettison):
747         * jit/Repatch.cpp:
748         (JSC::revertCall):
749
750 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
751
752         [JSC] Drop VM and Context cache map in JavaScriptCore.framework
753         https://bugs.webkit.org/show_bug.cgi?id=196341
754
755         Reviewed by Saam Barati.
756
757         Previously, we created Objective-C weak map to maintain JSVirtualMachine and JSContext wrappers corresponding to VM and JSGlobalObject.
758         But Objective-C weak map is really memory costly. Even if the entry is only one, it consumes 2.5KB per weak map. Since we can modify
759         JSC intrusively for JavaScriptCore.framework (and we already did it, like, holding JSWrapperMap in JSGlobalObject), we can just hold
760         a pointer to a wrapper in VM and JSGlobalObject.
761
762         This patch adds void* members to VM and JSGlobalObject, which holds a non-strong reference to a wrapper. When a wrapper is gone, we
763         clear this pointer too. This removes unnecessary two Objective-C weak maps, and save 5KB.
764
765         * API/JSContext.mm:
766         (-[JSContext initWithVirtualMachine:]):
767         (-[JSContext dealloc]):
768         (-[JSContext initWithGlobalContextRef:]):
769         (-[JSContext wrapperMap]):
770         (+[JSContext contextWithJSGlobalContextRef:]):
771         * API/JSVirtualMachine.mm:
772         (-[JSVirtualMachine initWithContextGroupRef:]):
773         (-[JSVirtualMachine dealloc]):
774         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
775         (scanExternalObjectGraph):
776         (scanExternalRememberedSet):
777         (initWrapperCache): Deleted.
778         (wrapperCache): Deleted.
779         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): Deleted.
780         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): Deleted.
781         (-[JSVirtualMachine contextForGlobalContextRef:]): Deleted.
782         (-[JSVirtualMachine addContext:forGlobalContextRef:]): Deleted.
783         * API/JSVirtualMachineInternal.h:
784         * runtime/JSGlobalObject.h:
785         (JSC::JSGlobalObject::setAPIWrapper):
786         (JSC::JSGlobalObject::apiWrapper const):
787         * runtime/VM.h:
788
789 2019-03-28  Tadeu Zagallo  <tzagallo@apple.com>
790
791         In-memory code cache should not share bytecode across domains
792         https://bugs.webkit.org/show_bug.cgi?id=196321
793
794         Reviewed by Geoffrey Garen.
795
796         Use the SourceProvider's URL to make sure that the hosts match for the
797         two SourceCodeKeys in operator==.
798
799         * parser/SourceCodeKey.h:
800         (JSC::SourceCodeKey::host const):
801         (JSC::SourceCodeKey::operator== const):
802
803 2019-03-28  Víctor Manuel Jáquez Leal  <vjaquez@igalia.com>
804
805         Silence lot of warnings when compiling with clang
806         https://bugs.webkit.org/show_bug.cgi?id=196310
807
808         Reviewed by Michael Catanzaro.
809
810         Initialize variable with default constructor.
811
812         * API/glib/JSCOptions.cpp:
813         (jsc_options_foreach):
814
815 2019-03-27  Saam Barati  <sbarati@apple.com>
816
817         validateOSREntryValue with Int52 should box the value being checked into double format
818         https://bugs.webkit.org/show_bug.cgi?id=196313
819         <rdar://problem/49306703>
820
821         Reviewed by Yusuke Suzuki.
822
823         * dfg/DFGOSREntry.cpp:
824         (JSC::DFG::prepareOSREntry):
825         * ftl/FTLLowerDFGToB3.cpp:
826         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
827
828 2019-03-27  Yusuke Suzuki  <ysuzuki@apple.com>
829
830         [JSC] Owner of watchpoints should validate at GC finalizing phase
831         https://bugs.webkit.org/show_bug.cgi?id=195827
832
833         Reviewed by Filip Pizlo.
834
835         This patch fixes JSC's watchpoint liveness issue by the following two policies.
836
837         1. Watchpoint should have owner cell, and "fire" operation should be gaurded with owner cell's isLive check.
838
839         Watchpoints should hold its owner cell, and fire procedure should be guarded by `owner->isLive()`.
840         When the owner cell is destroyed, these watchpoints are destroyed too. But this destruction can
841         be delayed due to incremental sweeper. So the following condition can happen.
842
843         When we have a watchpoint like the following.
844
845             class XXXWatchpoint {
846                 ObjectPropertyCondition m_key;
847                 JSCell* m_owner;
848             };
849
850         Both m_key's cell and m_owner is now unreachable from the root. So eventually, m_owner cell's destructor
851         is called and this watchpoint will be destroyed. But before that, m_key's cell can be destroyed. And this
852         watchpoint's fire procedure can be called since m_owner's destructor is not called yet. In this situation,
853         we encounter the destroyed cell held in m_key. This problem can be avoided if we guard fire procedure with
854         `m_owner->isLive()`. Until the owner cell is destroyed, this guard avoids "fire" procedure execution. And
855         once the destructor of m_owner is called, this watchpoint will be destroyed too.
856
857         2. Watchpoint liveness should be maintained by owner cell's unconditional finalizer
858
859         Watchpoints often hold weak references to the other cell (like, m_key in the above example). If we do not
860         delete watchpoints with dead cells when these weak cells become dead, these watchpoints continue holding dead cells,
861         and watchpoint's fire operation can use these dead cells accidentally. isLive / isStillLive check for these weak cells
862         in fire operation is not useful. Because these dead cells can be reused to the other live cells eventually, and this
863         isLive / isStillLive checks fail to see these cells are live if they are reused. Appropriate way is deleting watchpoints
864         with dead cells when finalizing GC. In this patch, we do this in unconditional finalizers in owner cells of watchpoints.
865         We already did this in CodeBlock etc. We add the same thing to StructureRareData which owns watchpoints for toString operations.
866
867         * JavaScriptCore.xcodeproj/project.pbxproj:
868         * Sources.txt:
869         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
870         (JSC::AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint::StructureWatchpoint): Deleted.
871         (JSC::AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint::PropertyWatchpoint): Deleted.
872         * bytecode/CodeBlockJettisoningWatchpoint.h:
873         (JSC::CodeBlockJettisoningWatchpoint::CodeBlockJettisoningWatchpoint): Deleted.
874         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
875         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
876         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
877         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
878         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::key const): Deleted.
879         * bytecode/StructureStubClearingWatchpoint.cpp:
880         (JSC::StructureStubClearingWatchpoint::fireInternal):
881         (JSC::WatchpointsOnStructureStubInfo::isValid const):
882         * bytecode/StructureStubClearingWatchpoint.h:
883         (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): Deleted.
884         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
885         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::isValid const):
886         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
887         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
888         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
889         * dfg/DFGAdaptiveStructureWatchpoint.h:
890         (JSC::DFG::AdaptiveStructureWatchpoint::key const): Deleted.
891         * dfg/DFGDesiredWatchpoints.cpp:
892         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
893         * heap/Heap.cpp:
894         (JSC::Heap::finalizeUnconditionalFinalizers):
895         * llint/LLIntSlowPaths.cpp:
896         (JSC::LLInt::setupGetByIdPrototypeCache):
897         * runtime/ArrayBuffer.cpp:
898         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
899         * runtime/ArrayBufferNeuteringWatchpointSet.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.cpp.
900         (JSC::ArrayBufferNeuteringWatchpointSet::ArrayBufferNeuteringWatchpointSet):
901         (JSC::ArrayBufferNeuteringWatchpointSet::destroy):
902         (JSC::ArrayBufferNeuteringWatchpointSet::create):
903         (JSC::ArrayBufferNeuteringWatchpointSet::createStructure):
904         (JSC::ArrayBufferNeuteringWatchpointSet::fireAll):
905         * runtime/ArrayBufferNeuteringWatchpointSet.h: Renamed from Source/JavaScriptCore/runtime/ArrayBufferNeuteringWatchpoint.h.
906         * runtime/FunctionRareData.h:
907         * runtime/JSGlobalObject.cpp:
908         (JSC::JSGlobalObject::init):
909         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
910         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
911         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): Deleted.
912         * runtime/StructureRareData.cpp:
913         (JSC::StructureRareData::finalizeUnconditionally):
914         * runtime/StructureRareData.h:
915         * runtime/VM.cpp:
916         (JSC::VM::VM):
917
918 2019-03-26  Saam Barati  <sbarati@apple.com>
919
920         FTL: Emit code to validate AI's state when running the compiled code
921         https://bugs.webkit.org/show_bug.cgi?id=195924
922         <rdar://problem/49003422>
923
924         Reviewed by Filip Pizlo.
925
926         This patch adds code that between the execution of each node that validates
927         the types that AI proves. This option is too expensive to turn on for our
928         regression testing, but we think it will be valuable in other types of running
929         modes, such as when running with a fuzzer.
930         
931         This patch also adds options to only probabilistically run this validation
932         after the execution of each node. As the probability is lowered, there is
933         less of a perf hit.
934         
935         This patch just adds this validation in the FTL. A follow-up patch will land
936         it in the DFG too: https://bugs.webkit.org/show_bug.cgi?id=196219
937
938         * ftl/FTLLowerDFGToB3.cpp:
939         (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
940         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
941         (JSC::FTL::DFG::LowerDFGToB3::validateAIState):
942         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
943         (JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
944         * runtime/Options.h:
945
946 2019-03-26  Tadeu Zagallo  <tzagallo@apple.com>
947
948         WebAssembly: Fix f32.min, f64.min and f64.max operations on NaN
949         https://bugs.webkit.org/show_bug.cgi?id=196217
950
951         Reviewed by Saam Barati.
952
953         Generalize the fix for f32.max to properly handle NaN by doing an extra GreatherThan
954         comparison in r243446 to all min and max float operations.
955
956         * wasm/WasmAirIRGenerator.cpp:
957         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
958         (JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
959         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
960         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
961         (JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
962         * wasm/wasm.json:
963
964 2019-03-26  Andy VanWagoner  <andy@vanwagoner.family>
965
966         Intl.DateTimeFormat should obey 2-digit hour
967         https://bugs.webkit.org/show_bug.cgi?id=195974
968
969         Reviewed by Keith Miller.
970
971         * runtime/IntlDateTimeFormat.cpp:
972         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
973
974 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
975
976         Heap::isMarked and friends should be instance methods
977         https://bugs.webkit.org/show_bug.cgi?id=179988
978
979         Reviewed by Saam Barati.
980
981         Almost all the callers of Heap::isMarked have VM& reference. We should make Heap::isMarked instance function instead of static function
982         so that we do not need to look up Heap from the cell.
983
984         * API/JSAPIWrapperObject.mm:
985         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
986         * API/JSMarkingConstraintPrivate.cpp:
987         (JSC::isMarked):
988         * API/glib/JSAPIWrapperObjectGLib.cpp:
989         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
990         * builtins/BuiltinExecutables.cpp:
991         (JSC::BuiltinExecutables::finalizeUnconditionally):
992         * bytecode/AccessCase.cpp:
993         (JSC::AccessCase::visitWeak const):
994         (JSC::AccessCase::propagateTransitions const):
995         * bytecode/CallLinkInfo.cpp:
996         (JSC::CallLinkInfo::visitWeak):
997         * bytecode/CallLinkStatus.cpp:
998         (JSC::CallLinkStatus::finalize):
999         * bytecode/CallLinkStatus.h:
1000         * bytecode/CallVariant.cpp:
1001         (JSC::CallVariant::finalize):
1002         * bytecode/CallVariant.h:
1003         * bytecode/CodeBlock.cpp:
1004         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
1005         (JSC::CodeBlock::shouldJettisonDueToOldAge):
1006         (JSC::shouldMarkTransition):
1007         (JSC::CodeBlock::propagateTransitions):
1008         (JSC::CodeBlock::determineLiveness):
1009         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1010         (JSC::CodeBlock::finalizeUnconditionally):
1011         (JSC::CodeBlock::jettison):
1012         * bytecode/CodeBlock.h:
1013         * bytecode/ExecutableToCodeBlockEdge.cpp:
1014         (JSC::ExecutableToCodeBlockEdge::visitChildren):
1015         (JSC::ExecutableToCodeBlockEdge::finalizeUnconditionally):
1016         (JSC::ExecutableToCodeBlockEdge::runConstraint):
1017         * bytecode/GetByIdStatus.cpp:
1018         (JSC::GetByIdStatus::finalize):
1019         * bytecode/GetByIdStatus.h:
1020         * bytecode/GetByIdVariant.cpp:
1021         (JSC::GetByIdVariant::finalize):
1022         * bytecode/GetByIdVariant.h:
1023         * bytecode/InByIdStatus.cpp:
1024         (JSC::InByIdStatus::finalize):
1025         * bytecode/InByIdStatus.h:
1026         * bytecode/InByIdVariant.cpp:
1027         (JSC::InByIdVariant::finalize):
1028         * bytecode/InByIdVariant.h:
1029         * bytecode/ObjectPropertyCondition.cpp:
1030         (JSC::ObjectPropertyCondition::isStillLive const):
1031         * bytecode/ObjectPropertyCondition.h:
1032         * bytecode/ObjectPropertyConditionSet.cpp:
1033         (JSC::ObjectPropertyConditionSet::areStillLive const):
1034         * bytecode/ObjectPropertyConditionSet.h:
1035         * bytecode/PolymorphicAccess.cpp:
1036         (JSC::PolymorphicAccess::visitWeak const):
1037         * bytecode/PropertyCondition.cpp:
1038         (JSC::PropertyCondition::isStillLive const):
1039         * bytecode/PropertyCondition.h:
1040         * bytecode/PutByIdStatus.cpp:
1041         (JSC::PutByIdStatus::finalize):
1042         * bytecode/PutByIdStatus.h:
1043         * bytecode/PutByIdVariant.cpp:
1044         (JSC::PutByIdVariant::finalize):
1045         * bytecode/PutByIdVariant.h:
1046         * bytecode/RecordedStatuses.cpp:
1047         (JSC::RecordedStatuses::finalizeWithoutDeleting):
1048         (JSC::RecordedStatuses::finalize):
1049         * bytecode/RecordedStatuses.h:
1050         * bytecode/StructureSet.cpp:
1051         (JSC::StructureSet::isStillAlive const):
1052         * bytecode/StructureSet.h:
1053         * bytecode/StructureStubInfo.cpp:
1054         (JSC::StructureStubInfo::visitWeakReferences):
1055         * dfg/DFGPlan.cpp:
1056         (JSC::DFG::Plan::finalizeInGC):
1057         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
1058         * heap/GCIncomingRefCounted.h:
1059         * heap/GCIncomingRefCountedInlines.h:
1060         (JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
1061         * heap/GCIncomingRefCountedSet.h:
1062         * heap/GCIncomingRefCountedSetInlines.h:
1063         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
1064         (JSC::GCIncomingRefCountedSet<T>::sweep):
1065         (JSC::GCIncomingRefCountedSet<T>::removeAll): Deleted.
1066         (JSC::GCIncomingRefCountedSet<T>::removeDead): Deleted.
1067         * heap/Heap.cpp:
1068         (JSC::Heap::addToRememberedSet):
1069         (JSC::Heap::runEndPhase):
1070         (JSC::Heap::sweepArrayBuffers):
1071         (JSC::Heap::addCoreConstraints):
1072         * heap/Heap.h:
1073         * heap/HeapInlines.h:
1074         (JSC::Heap::isMarked):
1075         * heap/HeapSnapshotBuilder.cpp:
1076         (JSC::HeapSnapshotBuilder::appendNode):
1077         * heap/SlotVisitor.cpp:
1078         (JSC::SlotVisitor::appendToMarkStack):
1079         (JSC::SlotVisitor::visitChildren):
1080         * jit/PolymorphicCallStubRoutine.cpp:
1081         (JSC::PolymorphicCallStubRoutine::visitWeak):
1082         * runtime/ErrorInstance.cpp:
1083         (JSC::ErrorInstance::finalizeUnconditionally):
1084         * runtime/InferredValueInlines.h:
1085         (JSC::InferredValue::finalizeUnconditionally):
1086         * runtime/StackFrame.h:
1087         (JSC::StackFrame::isMarked const):
1088         * runtime/Structure.cpp:
1089         (JSC::Structure::isCheapDuringGC):
1090         (JSC::Structure::markIfCheap):
1091         * runtime/Structure.h:
1092         * runtime/TypeProfiler.cpp:
1093         (JSC::TypeProfiler::invalidateTypeSetCache):
1094         * runtime/TypeProfiler.h:
1095         * runtime/TypeSet.cpp:
1096         (JSC::TypeSet::invalidateCache):
1097         * runtime/TypeSet.h:
1098         * runtime/WeakMapImpl.cpp:
1099         (JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints):
1100         * runtime/WeakMapImplInlines.h:
1101         (JSC::WeakMapImpl<WeakMapBucket>::finalizeUnconditionally):
1102
1103 2019-03-25  Keith Miller  <keith_miller@apple.com>
1104
1105         ASSERTION FAILED: m_op == CompareStrictEq in JSC::DFG::Node::convertToCompareEqPtr(JSC::DFG::FrozenValue *, JSC::DFG::Edge)
1106         https://bugs.webkit.org/show_bug.cgi?id=196176
1107
1108         Reviewed by Saam Barati.
1109
1110         convertToCompareEqPtr should allow for either CompareStrictEq or
1111         the SameValue DFG node. This fixes the old assertion that only
1112         allowed CompareStrictEq.
1113
1114         * dfg/DFGNode.h:
1115         (JSC::DFG::Node::convertToCompareEqPtr):
1116
1117 2019-03-25  Tadeu Zagallo  <tzagallo@apple.com>
1118
1119         WebAssembly: f32.max with NaN generates incorrect result
1120         https://bugs.webkit.org/show_bug.cgi?id=175691
1121         <rdar://problem/33952228>
1122
1123         Reviewed by Saam Barati.
1124
1125         Fix the B3 and Air compilation for f32.max. In order to handle the NaN
1126         case, we need an extra GreaterThan comparison on top of the existing
1127         Equal and LessThan ones.
1128
1129         * wasm/WasmAirIRGenerator.cpp:
1130         (JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
1131         * wasm/wasm.json:
1132
1133 2019-03-25  Yusuke Suzuki  <ysuzuki@apple.com>
1134
1135         Unreviewed, speculative fix for CLoop build on CPU(UNKNOWN)
1136         https://bugs.webkit.org/show_bug.cgi?id=195982
1137
1138         * jit/ExecutableAllocator.h:
1139         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
1140
1141 2019-03-25  Gyuyoung Kim  <gyuyoung.kim@webkit.org>
1142
1143         Remove NavigatorContentUtils in WebCore/Modules
1144         https://bugs.webkit.org/show_bug.cgi?id=196070
1145
1146         Reviewed by Alex Christensen.
1147
1148         NavigatorContentUtils was to support the custom scheme spec [1].
1149         However, in WebKit side, no port has supported the feature in
1150         WebKit layer after EFL port was removed. So there has been the
1151         only IDL implementation of the NavigatorContentUtils in WebCore.
1152         So we don't need to keep the implementation in WebCore anymore.
1153
1154         [1] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
1155
1156         * Configurations/FeatureDefines.xcconfig:
1157
1158 2019-03-23  Mark Lam  <mark.lam@apple.com>
1159
1160         Rolling out r243032 and r243071 because the fix is incorrect.
1161         https://bugs.webkit.org/show_bug.cgi?id=195892
1162         <rdar://problem/48981239>
1163
1164         Not reviewed.
1165
1166         The fix is incorrect: it relies on being able to determine liveness of an object
1167         in an ObjectPropertyCondition based on the state of the object's MarkedBit.
1168         However, there's no guarantee that GC has run and that the MarkedBit is already
1169         set even if the object is live.  As a result, we may not re-install adaptive
1170         watchpoints based on presumed dead objects which are actually live.
1171
1172         I'm rolling this out, and will implement a more comprehensive fix to handle
1173         watchpoint liveness later.
1174
1175         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
1176         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
1177         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
1178         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
1179         * bytecode/ObjectPropertyCondition.cpp:
1180         (JSC::ObjectPropertyCondition::dumpInContext const):
1181         * bytecode/StructureStubClearingWatchpoint.cpp:
1182         (JSC::StructureStubClearingWatchpoint::fireInternal):
1183         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
1184         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
1185         * runtime/StructureRareData.cpp:
1186         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
1187
1188 2019-03-23  Keith Miller  <keith_miller@apple.com>
1189
1190         Refactor clz/ctz and fix getLSBSet.
1191         https://bugs.webkit.org/show_bug.cgi?id=196162
1192
1193         Reviewed by Saam Barati.
1194
1195         Refactor references of clz32/64 and ctz32 to use clz and ctz,
1196         respectively.
1197
1198         * dfg/DFGAbstractInterpreterInlines.h:
1199         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1200         * dfg/DFGOperations.cpp:
1201         * runtime/JSBigInt.cpp:
1202         (JSC::JSBigInt::digitDiv):
1203         (JSC::JSBigInt::absoluteDivWithBigIntDivisor):
1204         (JSC::JSBigInt::calculateMaximumCharactersRequired):
1205         (JSC::JSBigInt::toStringBasePowerOfTwo):
1206         (JSC::JSBigInt::compareToDouble):
1207         * runtime/MathObject.cpp:
1208         (JSC::mathProtoFuncClz32):
1209
1210 2019-03-23  Yusuke Suzuki  <ysuzuki@apple.com>
1211
1212         [JSC] Shrink sizeof(RegExp)
1213         https://bugs.webkit.org/show_bug.cgi?id=196133
1214
1215         Reviewed by Mark Lam.
1216
1217         Some applications have many RegExp cells. But RegExp cells are very large (144B).
1218         This patch reduces the size from 144B to 48B by,
1219
1220         1. Allocate Yarr::YarrCodeBlock in non-GC heap. We can avoid this allocation if JIT is disabled.
1221         2. m_captureGroupNames and m_namedGroupToParenIndex are moved to RareData. They are only used when RegExp has named capture groups.
1222
1223         * runtime/RegExp.cpp:
1224         (JSC::RegExp::finishCreation):
1225         (JSC::RegExp::estimatedSize):
1226         (JSC::RegExp::compile):
1227         (JSC::RegExp::matchConcurrently):
1228         (JSC::RegExp::compileMatchOnly):
1229         (JSC::RegExp::deleteCode):
1230         (JSC::RegExp::printTraceData):
1231         * runtime/RegExp.h:
1232         * runtime/RegExpInlines.h:
1233         (JSC::RegExp::hasCodeFor):
1234         (JSC::RegExp::matchInline):
1235         (JSC::RegExp::hasMatchOnlyCodeFor):
1236
1237 2019-03-22  Keith Rollin  <krollin@apple.com>
1238
1239         Enable ThinLTO support in Production builds
1240         https://bugs.webkit.org/show_bug.cgi?id=190758
1241         <rdar://problem/45413233>
1242
1243         Reviewed by Daniel Bates.
1244
1245         Tweak JavaScriptCore's Base.xcconfig to be more in-line with other
1246         .xcconfig files with regards to LTO settings. However, don't actually
1247         enable LTO for JavaScriptCore. LTO is not enabled for JavaScriptCore
1248         due to <rdar://problem/24543547>.
1249
1250         * Configurations/Base.xcconfig:
1251
1252 2019-03-22  Mark Lam  <mark.lam@apple.com>
1253
1254         Placate exception check validation in genericTypedArrayViewProtoFuncLastIndexOf().
1255         https://bugs.webkit.org/show_bug.cgi?id=196154
1256         <rdar://problem/49145307>
1257
1258         Reviewed by Filip Pizlo.
1259
1260         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1261         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1262
1263 2019-03-22  Mark Lam  <mark.lam@apple.com>
1264
1265         Placate exception check validation in constructJSWebAssemblyLinkError().
1266         https://bugs.webkit.org/show_bug.cgi?id=196152
1267         <rdar://problem/49145257>
1268
1269         Reviewed by Michael Saboff.
1270
1271         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
1272         (JSC::constructJSWebAssemblyLinkError):
1273
1274 2019-03-22  Timothy Hatcher  <timothy@apple.com>
1275
1276         Change macosx() to macos() in WK_API... and JSC_API... macros.
1277         https://bugs.webkit.org/show_bug.cgi?id=196106
1278
1279         Reviewed by Brian Burg.
1280
1281         * API/JSBasePrivate.h:
1282         * API/JSContext.h:
1283         * API/JSContextPrivate.h:
1284         * API/JSContextRef.h:
1285         * API/JSContextRefInternal.h:
1286         * API/JSContextRefPrivate.h:
1287         * API/JSManagedValue.h:
1288         * API/JSObjectRef.h:
1289         * API/JSObjectRefPrivate.h:
1290         * API/JSRemoteInspector.h:
1291         * API/JSScript.h:
1292         * API/JSTypedArray.h:
1293         * API/JSValue.h:
1294         * API/JSValuePrivate.h:
1295         * API/JSValueRef.h:
1296         * API/JSVirtualMachinePrivate.h:
1297
1298 2019-03-22  Yusuke Suzuki  <ysuzuki@apple.com>
1299
1300         Unreviewed, build fix for Windows
1301         https://bugs.webkit.org/show_bug.cgi?id=196122
1302
1303         * runtime/FunctionExecutable.cpp:
1304
1305 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
1306
1307         [JSC] Shrink sizeof(FunctionExecutable) by 16bytes
1308         https://bugs.webkit.org/show_bug.cgi?id=196122
1309
1310         Reviewed by Saam Barati.
1311
1312         This patch reduces sizeof(FunctionExecutable) by 16 bytes.
1313
1314         1. ScriptExecutable::m_numParametersForCall and ScriptExecutable::m_numParametersForConstruct are not used in a meaningful way. Removed them.
1315         2. ScriptExecutable::m_lastLine and ScriptExecutable::m_endColumn can be calculated from UnlinkedFunctionExecutable. So FunctionExecutable does not need to hold it.
1316            This patch adds GlobalExecutable, which are non-function ScriptExecutables, and move m_lastLine and m_endColumn to this class.
1317         3. FunctionExecutable still needs to have the feature overriding m_lastLine and m_endColumn. We move overridden data in FunctionExecutable::RareData.
1318
1319         * CMakeLists.txt:
1320         * JavaScriptCore.xcodeproj/project.pbxproj:
1321         * Sources.txt:
1322         * bytecode/UnlinkedFunctionExecutable.cpp:
1323         (JSC::UnlinkedFunctionExecutable::link):
1324         * runtime/EvalExecutable.cpp:
1325         (JSC::EvalExecutable::EvalExecutable):
1326         * runtime/EvalExecutable.h:
1327         * runtime/FunctionExecutable.cpp:
1328         (JSC::FunctionExecutable::FunctionExecutable):
1329         (JSC::FunctionExecutable::ensureRareDataSlow):
1330         (JSC::FunctionExecutable::overrideInfo):
1331         * runtime/FunctionExecutable.h:
1332         * runtime/GlobalExecutable.cpp: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
1333         * runtime/GlobalExecutable.h: Copied from Source/JavaScriptCore/tools/FunctionOverrides.h.
1334         (JSC::GlobalExecutable::lastLine const):
1335         (JSC::GlobalExecutable::endColumn const):
1336         (JSC::GlobalExecutable::recordParse):
1337         (JSC::GlobalExecutable::GlobalExecutable):
1338         * runtime/ModuleProgramExecutable.cpp:
1339         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
1340         * runtime/ModuleProgramExecutable.h:
1341         * runtime/ProgramExecutable.cpp:
1342         (JSC::ProgramExecutable::ProgramExecutable):
1343         * runtime/ProgramExecutable.h:
1344         * runtime/ScriptExecutable.cpp:
1345         (JSC::ScriptExecutable::clearCode):
1346         (JSC::ScriptExecutable::installCode):
1347         (JSC::ScriptExecutable::hasClearableCode const):
1348         (JSC::ScriptExecutable::newCodeBlockFor):
1349         (JSC::ScriptExecutable::typeProfilingEndOffset const):
1350         (JSC::ScriptExecutable::recordParse):
1351         (JSC::ScriptExecutable::lastLine const):
1352         (JSC::ScriptExecutable::endColumn const):
1353         * runtime/ScriptExecutable.h:
1354         (JSC::ScriptExecutable::hasJITCodeForCall const):
1355         (JSC::ScriptExecutable::hasJITCodeForConstruct const):
1356         (JSC::ScriptExecutable::recordParse):
1357         (JSC::ScriptExecutable::lastLine const): Deleted.
1358         (JSC::ScriptExecutable::endColumn const): Deleted.
1359         * tools/FunctionOverrides.h:
1360
1361 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
1362
1363         [JSC] Shrink sizeof(RegExpObject)
1364         https://bugs.webkit.org/show_bug.cgi?id=196130
1365
1366         Reviewed by Saam Barati.
1367
1368         sizeof(RegExpObject) is 48B due to one bool flag. We should compress this flag into lower bit of RegExp* field so that we can make RegExpObject 32B.
1369         It saves memory footprint 1.3% in RAMification's regexp.
1370
1371         * dfg/DFGSpeculativeJIT.cpp:
1372         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
1373         (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
1374         * ftl/FTLAbstractHeapRepository.h:
1375         * ftl/FTLLowerDFGToB3.cpp:
1376         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
1377         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
1378         * runtime/RegExpObject.cpp:
1379         (JSC::RegExpObject::RegExpObject):
1380         (JSC::RegExpObject::visitChildren):
1381         (JSC::RegExpObject::getOwnPropertySlot):
1382         (JSC::RegExpObject::defineOwnProperty):
1383         * runtime/RegExpObject.h:
1384
1385 2019-03-21  Tomas Popela  <tpopela@redhat.com>
1386
1387         [JSC] Fix build after r243232 on unsupported 64bit architectures
1388         https://bugs.webkit.org/show_bug.cgi?id=196072
1389
1390         Reviewed by Keith Miller.
1391
1392         As Keith suggested we already expect 16 free bits at the top of any
1393         pointer for JSValue even for the unsupported 64 bit arches.
1394
1395         * bytecode/CodeOrigin.h:
1396
1397 2019-03-21  Mark Lam  <mark.lam@apple.com>
1398
1399         Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
1400         https://bugs.webkit.org/show_bug.cgi?id=196116
1401         <rdar://problem/48976951>
1402
1403         Reviewed by Filip Pizlo.
1404
1405         The DFG backend should not make assumptions about what optimizations the front end
1406         will or will not do.  The assertion asserts that the operand cannot be known to be
1407         a cell.  However, it is not guaranteed that the front end will fold away this case.
1408         Also, the DFG backend is perfectly capable of generating code to handle the case
1409         where the operand is a cell.
1410
1411         The attached test case demonstrates a case where the operand can be a known cell.
1412         The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
1413         trip up this assertion about once every 10 runs or so.
1414
1415         * dfg/DFGSpeculativeJIT64.cpp:
1416         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
1417
1418 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
1419
1420         JSC::createError should clear exception thrown by errorDescriptionForValue
1421         https://bugs.webkit.org/show_bug.cgi?id=196089
1422
1423         Reviewed by Mark Lam.
1424
1425         errorDescriptionForValue returns a nullString in case of failure, but it
1426         might also throw an OOM exception when resolving a rope string. We need
1427         to clear any potential exceptions thrown by errorDescriptionForValue
1428         before returning the OOM from JSC::createError.
1429
1430         * runtime/ExceptionHelpers.cpp:
1431         (JSC::createError):
1432
1433 2019-03-21  Robin Morisset  <rmorisset@apple.com>
1434
1435         B3::Opcode can fit in a single byte, shrinking B3Value by 8 bytes
1436         https://bugs.webkit.org/show_bug.cgi?id=196014
1437
1438         Reviewed by Keith Miller.
1439
1440         B3::Opcode has less than one hundred cases, so it can easily fit in one byte (from two currently)
1441         This shrinks B3::Kind from 4 bytes to 2 (by removing the byte of padding at the end).
1442         This in turns eliminate padding from B3::Value, shrinking it by 8 bytes (out of 80).
1443
1444         * b3/B3Opcode.h:
1445
1446 2019-03-21  Michael Catanzaro  <mcatanzaro@igalia.com>
1447
1448         Unreviewed, more clang 3.8 build fixes
1449         https://bugs.webkit.org/show_bug.cgi?id=195947
1450         <rdar://problem/49069219>
1451
1452         In the spirit of making our code worse to please old compilers....
1453
1454         * bindings/ScriptValue.cpp:
1455         (Inspector::jsToInspectorValue):
1456         * bytecode/GetterSetterAccessCase.cpp:
1457         (JSC::GetterSetterAccessCase::create):
1458         (JSC::GetterSetterAccessCase::clone const):
1459         * bytecode/InstanceOfAccessCase.cpp:
1460         (JSC::InstanceOfAccessCase::clone const):
1461         * bytecode/IntrinsicGetterAccessCase.cpp:
1462         (JSC::IntrinsicGetterAccessCase::clone const):
1463         * bytecode/ModuleNamespaceAccessCase.cpp:
1464         (JSC::ModuleNamespaceAccessCase::clone const):
1465         * bytecode/ProxyableAccessCase.cpp:
1466         (JSC::ProxyableAccessCase::clone const):
1467
1468 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
1469
1470         [JSC] Do not create JIT related data under non-JIT mode
1471         https://bugs.webkit.org/show_bug.cgi?id=195982
1472
1473         Reviewed by Mark Lam.
1474
1475         We avoid creations of JIT related data structures under non-JIT mode.
1476         This patch removes the following allocations.
1477
1478         1. JITThunks
1479         2. FTLThunks
1480         3. FixedVMPoolExecutableAllocator
1481         4. noJITValueProfileSingleton since it is no longer used
1482         5. ARM disassembler should be initialized when it is used
1483         6. Wasm related data structures are accidentally allocated if VM::canUseJIT() == false &&
1484            Options::useWebAssembly() == true. Add Wasm::isSupported() function to check the both conditions.
1485
1486         * CMakeLists.txt:
1487         * JavaScriptCore.xcodeproj/project.pbxproj:
1488         * heap/Heap.cpp:
1489         (JSC::Heap::runEndPhase):
1490         * jit/ExecutableAllocator.cpp:
1491         (JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
1492         (JSC::ExecutableAllocator::initializeUnderlyingAllocator):
1493         (JSC::ExecutableAllocator::isValid const):
1494         (JSC::ExecutableAllocator::underMemoryPressure):
1495         (JSC::ExecutableAllocator::memoryPressureMultiplier):
1496         (JSC::ExecutableAllocator::allocate):
1497         (JSC::ExecutableAllocator::isValidExecutableMemory):
1498         (JSC::ExecutableAllocator::getLock const):
1499         (JSC::ExecutableAllocator::committedByteCount):
1500         (JSC::ExecutableAllocator::dumpProfile):
1501         (JSC::startOfFixedExecutableMemoryPoolImpl):
1502         (JSC::endOfFixedExecutableMemoryPoolImpl):
1503         (JSC::ExecutableAllocator::initialize):
1504         (JSC::ExecutableAllocator::initializeAllocator): Deleted.
1505         (JSC::ExecutableAllocator::ExecutableAllocator): Deleted.
1506         (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted.
1507         * jit/ExecutableAllocator.h:
1508         (JSC::ExecutableAllocatorBase::isValid const):
1509         (JSC::ExecutableAllocatorBase::underMemoryPressure):
1510         (JSC::ExecutableAllocatorBase::memoryPressureMultiplier):
1511         (JSC::ExecutableAllocatorBase::dumpProfile):
1512         (JSC::ExecutableAllocatorBase::allocate):
1513         (JSC::ExecutableAllocatorBase::setJITEnabled):
1514         (JSC::ExecutableAllocatorBase::isValidExecutableMemory):
1515         (JSC::ExecutableAllocatorBase::committedByteCount):
1516         (JSC::ExecutableAllocatorBase::getLock const):
1517         (JSC::ExecutableAllocator::isValid const): Deleted.
1518         (JSC::ExecutableAllocator::underMemoryPressure): Deleted.
1519         (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted.
1520         (JSC::ExecutableAllocator::allocate): Deleted.
1521         (JSC::ExecutableAllocator::setJITEnabled): Deleted.
1522         (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted.
1523         (JSC::ExecutableAllocator::committedByteCount): Deleted.
1524         (JSC::ExecutableAllocator::getLock const): Deleted.
1525         * jsc.cpp:
1526         (functionWebAssemblyMemoryMode):
1527         * runtime/InitializeThreading.cpp:
1528         (JSC::initializeThreading):
1529         * runtime/JSGlobalObject.cpp:
1530         (JSC::JSGlobalObject::init):
1531         * runtime/JSLock.cpp:
1532         (JSC::JSLock::didAcquireLock):
1533         * runtime/Options.cpp:
1534         (JSC::recomputeDependentOptions):
1535         * runtime/VM.cpp:
1536         (JSC::enableAssembler):
1537         (JSC::VM::canUseAssembler):
1538         (JSC::VM::VM):
1539         * runtime/VM.h:
1540         * wasm/WasmCapabilities.h: Added.
1541         (JSC::Wasm::isSupported):
1542         * wasm/WasmFaultSignalHandler.cpp:
1543         (JSC::Wasm::enableFastMemory):
1544
1545 2019-03-21  Yusuke Suzuki  <ysuzuki@apple.com>
1546
1547         [JSC] Fix JSC build with newer ICU
1548         https://bugs.webkit.org/show_bug.cgi?id=196098
1549
1550         Reviewed by Keith Miller.
1551
1552         IntlDateTimeFormat and IntlNumberFormat have switch statement over ICU's enums. However it lacks "default" clause so that
1553         the compile error occurs when a new enum value is added in ICU side. We should have "default" clause which just fallbacks
1554         "unknown"_s case. The behavior is not changed since we already have `return "unknown"_s;` statement anyway after the
1555         switch statement. This patch just suppresses a compile error.
1556
1557         * runtime/IntlDateTimeFormat.cpp:
1558         (JSC::IntlDateTimeFormat::partTypeString):
1559         * runtime/IntlNumberFormat.cpp:
1560         (JSC::IntlNumberFormat::partTypeString):
1561
1562 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
1563
1564         JSObject::putDirectIndexSlowOrBeyondVectorLength should check if indexIsSufficientlyBeyondLengthForSparseMap
1565         https://bugs.webkit.org/show_bug.cgi?id=196078
1566         <rdar://problem/35925380>
1567
1568         Reviewed by Mark Lam.
1569
1570         Unlike the other variations of putByIndex, it only checked if the index
1571         was larger than MIN_SPARSE_ARRAY_INDEX when the indexingType was
1572         ALL_BLANK_INDEXING_TYPES. This resulted in a huge butterfly being
1573         allocated for object literals (e.g. `{[9e4]: ...}`) and objects parsed
1574         from JSON.
1575
1576         * runtime/JSObject.cpp:
1577         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
1578
1579 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
1580
1581         CachedUnlinkedSourceCodeShape::m_provider should be a CachedRefPtr
1582         https://bugs.webkit.org/show_bug.cgi?id=196079
1583
1584         Reviewed by Saam Barati.
1585
1586         It was mistakenly cached as CachedPtr, which was leaking the decoded SourceProvider.
1587
1588         * runtime/CachedTypes.cpp:
1589         (JSC::CachedUnlinkedSourceCodeShape::encode):
1590
1591 2019-03-21  Mark Lam  <mark.lam@apple.com>
1592
1593         Placate exception check validation in operationArrayIndexOfString().
1594         https://bugs.webkit.org/show_bug.cgi?id=196067
1595         <rdar://problem/49056572>
1596
1597         Reviewed by Michael Saboff.
1598
1599         * dfg/DFGOperations.cpp:
1600
1601 2019-03-21  Xan Lopez  <xan@igalia.com>
1602
1603         [JSC][x86] Drop support for x87 floating point
1604         https://bugs.webkit.org/show_bug.cgi?id=194853
1605
1606         Reviewed by Don Olmstead.
1607
1608         Require SSE2 throughout the codebase, and remove x87 support where
1609         it was optionally available. SSE2 detection happens at compile
1610         time through a static_assert.
1611
1612         * assembler/MacroAssemblerX86.h:
1613         (JSC::MacroAssemblerX86::storeDouble):
1614         (JSC::MacroAssemblerX86::moveDoubleToInts):
1615         (JSC::MacroAssemblerX86::supportsFloatingPoint):
1616         (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):
1617         (JSC::MacroAssemblerX86::supportsFloatingPointSqrt):
1618         (JSC::MacroAssemblerX86::supportsFloatingPointAbs):
1619         * assembler/MacroAssemblerX86Common.cpp:
1620         * assembler/MacroAssemblerX86Common.h:
1621         (JSC::MacroAssemblerX86Common::moveDouble):
1622         (JSC::MacroAssemblerX86Common::loadDouble):
1623         (JSC::MacroAssemblerX86Common::loadFloat):
1624         (JSC::MacroAssemblerX86Common::storeDouble):
1625         (JSC::MacroAssemblerX86Common::storeFloat):
1626         (JSC::MacroAssemblerX86Common::convertDoubleToFloat):
1627         (JSC::MacroAssemblerX86Common::convertFloatToDouble):
1628         (JSC::MacroAssemblerX86Common::addDouble):
1629         (JSC::MacroAssemblerX86Common::addFloat):
1630         (JSC::MacroAssemblerX86Common::divDouble):
1631         (JSC::MacroAssemblerX86Common::divFloat):
1632         (JSC::MacroAssemblerX86Common::subDouble):
1633         (JSC::MacroAssemblerX86Common::subFloat):
1634         (JSC::MacroAssemblerX86Common::mulDouble):
1635         (JSC::MacroAssemblerX86Common::mulFloat):
1636         (JSC::MacroAssemblerX86Common::convertInt32ToDouble):
1637         (JSC::MacroAssemblerX86Common::convertInt32ToFloat):
1638         (JSC::MacroAssemblerX86Common::branchDouble):
1639         (JSC::MacroAssemblerX86Common::branchFloat):
1640         (JSC::MacroAssemblerX86Common::compareDouble):
1641         (JSC::MacroAssemblerX86Common::compareFloat):
1642         (JSC::MacroAssemblerX86Common::branchTruncateDoubleToInt32):
1643         (JSC::MacroAssemblerX86Common::truncateDoubleToInt32):
1644         (JSC::MacroAssemblerX86Common::truncateFloatToInt32):
1645         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
1646         (JSC::MacroAssemblerX86Common::branchDoubleNonZero):
1647         (JSC::MacroAssemblerX86Common::branchDoubleZeroOrNaN):
1648         (JSC::MacroAssemblerX86Common::lshiftPacked):
1649         (JSC::MacroAssemblerX86Common::rshiftPacked):
1650         (JSC::MacroAssemblerX86Common::orPacked):
1651         (JSC::MacroAssemblerX86Common::move32ToFloat):
1652         (JSC::MacroAssemblerX86Common::moveFloatTo32):
1653         (JSC::MacroAssemblerX86Common::moveConditionallyDouble):
1654         (JSC::MacroAssemblerX86Common::moveConditionallyFloat):
1655         * offlineasm/x86.rb:
1656         * runtime/MathCommon.cpp:
1657         (JSC::operationMathPow):
1658
1659 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
1660
1661         [GLIB] User data not correctly passed to callback of functions and constructors with no parameters
1662         https://bugs.webkit.org/show_bug.cgi?id=196073
1663
1664         Reviewed by Michael Catanzaro.
1665
1666         This is because GClosure always expects a first parameter as instance. In case of functions or constructors with
1667         no parameters we insert a fake instance which is just a null pointer that is ignored by the callback. But
1668         if the function/constructor has user data the callback will expect one parameter for the user data. In that case
1669         we can simply swap instance/user data so that the fake instance will be the second argument and user data the
1670         first one.
1671
1672         * API/glib/JSCClass.cpp:
1673         (jscClassCreateConstructor): Use g_cclosure_new_swap() if parameters is empty and user data was provided.
1674         * API/glib/JSCValue.cpp:
1675         (jscValueFunctionCreate): Ditto.
1676
1677 2019-03-21  Pablo Saavedra  <psaavedra@igalia.com>
1678
1679         [JSC][32-bit] Build failure after r243232
1680         https://bugs.webkit.org/show_bug.cgi?id=196068
1681
1682         Reviewed by Mark Lam.
1683
1684         * dfg/DFGOSRExit.cpp:
1685         (JSC::DFG::reifyInlinedCallFrames):
1686         * dfg/DFGOSRExitCompilerCommon.cpp:
1687         (JSC::DFG::reifyInlinedCallFrames):
1688
1689 2019-03-21  Carlos Garcia Campos  <cgarcia@igalia.com>
1690
1691         [GLib] Returning G_TYPE_OBJECT from a method does not work
1692         https://bugs.webkit.org/show_bug.cgi?id=195574
1693
1694         Reviewed by Michael Catanzaro.
1695
1696         Add more documentation to clarify the ownership of wrapped objects when created and when returned by functions.
1697
1698         * API/glib/JSCCallbackFunction.cpp:
1699         (JSC::JSCCallbackFunction::construct): Also allow to return boxed types from a constructor.
1700         * API/glib/JSCClass.cpp:
1701         * API/glib/JSCValue.cpp:
1702
1703 2019-03-21  Mark Lam  <mark.lam@apple.com>
1704
1705         Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.
1706         https://bugs.webkit.org/show_bug.cgi?id=196055
1707         <rdar://problem/49067448>
1708
1709         Reviewed by Yusuke Suzuki.
1710
1711         We are doing this because:
1712         1. We expect the array to be densely packed.
1713         2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent)
1714            expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH
1715            if we don't want to use an ArrayStorage shape.
1716         3. There's no reason why an array with spread needs to be that large anyway.
1717            MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty.
1718
1719         In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and
1720         emitAllocateButterfly() to check for overflows.
1721
1722         * assembler/AbortReason.h:
1723         * dfg/DFGOperations.cpp:
1724         * dfg/DFGSpeculativeJIT.cpp:
1725         (JSC::DFG::SpeculativeJIT::compileCreateRest):
1726         (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
1727         (JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
1728         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
1729         * ftl/FTLLowerDFGToB3.cpp:
1730         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
1731         * runtime/ArrayConventions.h:
1732         * runtime/CommonSlowPaths.cpp:
1733         (JSC::SLOW_PATH_DECL):
1734
1735 2019-03-20  Yusuke Suzuki  <ysuzuki@apple.com>
1736
1737         [JSC] Use finalizer in JSGlobalLexicalEnvironment and JSGlobalObject
1738         https://bugs.webkit.org/show_bug.cgi?id=195992
1739
1740         Reviewed by Keith Miller and Mark Lam.
1741
1742         JSGlobalLexicalEnvironment and JSGlobalObject have their own CompleteSubspace to call destructors while they are not inheriting JSDestructibleObject.
1743         But it is too costly since (1) it requires CompleteSubspace in VM, (2) both objects allocate MarkedBlocks while # of them are really small.
1744
1745         Instead of using CompleteSubspace, we just set finalizers for them. Since these objects are rarely allocated, setting finalizers does not show
1746         memory / performance problems (actually, previously we used finalizer for ArrayPrototype due to the same reason, and it does not show any problems).
1747
1748         And we also add following two changes to JSSegmentedVariableObject.
1749
1750         1. Remove one boolean used for debugging in Release build. It enlarges sizeof(JSSegmentedVariableObject) and allocates one more MarkedBlock.
1751         2. Use cellLock() instead.
1752
1753         * CMakeLists.txt:
1754         * JavaScriptCore.xcodeproj/project.pbxproj:
1755         * Sources.txt:
1756         * runtime/JSSegmentedVariableObject.cpp:
1757         (JSC::JSSegmentedVariableObject::findVariableIndex):
1758         (JSC::JSSegmentedVariableObject::addVariables):
1759         (JSC::JSSegmentedVariableObject::visitChildren):
1760         (JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
1761         (JSC::JSSegmentedVariableObject::finishCreation):
1762         * runtime/JSSegmentedVariableObject.h:
1763         (JSC::JSSegmentedVariableObject::subspaceFor): Deleted.
1764         * runtime/JSSegmentedVariableObjectHeapCellType.cpp: Removed.
1765         * runtime/JSSegmentedVariableObjectHeapCellType.h: Removed.
1766         * runtime/StringIteratorPrototype.cpp:
1767         * runtime/VM.cpp:
1768         (JSC::VM::VM):
1769         * runtime/VM.h:
1770
1771 2019-03-20  Saam Barati  <sbarati@apple.com>
1772
1773         DFG::AbstractValue::validateOSREntry is wrong when isHeapTop and the incoming value is Empty
1774         https://bugs.webkit.org/show_bug.cgi?id=195721
1775
1776         Reviewed by Filip Pizlo.
1777
1778         There was a check in AbstractValue::validateOSREntry where it checked
1779         if isHeapTop(), and if so, just returned true. However, this is wrong
1780         if the value we're checking against is the empty value, since HeapTop
1781         does not include the Empty value. Instead, this check should be
1782         isBytecodeTop(), which does account for the empty value.
1783         
1784         This patch also does a couple of other things:
1785         - For our OSR entry AbstractValues, we were using HeapTop to mark
1786          a dead value. That is now changed to BytecodeTop. (The idea here
1787          is just to have validateOSREntry return early.)
1788         - It wasn't obvious to me how I could make this fail in JS code.
1789          The symptom we'd end up seeing is something like a nullptr derefernece
1790          from forgetting to do a TDZ check. Instead, I've added a unit test.
1791          This unit test lives in a new test file: testdfg. testdfg is similar
1792          to testb3/testair/testapi.
1793
1794         * JavaScriptCore.xcodeproj/project.pbxproj:
1795         * bytecode/SpeculatedType.h:
1796         * dfg/DFGAbstractValue.h:
1797         (JSC::DFG::AbstractValue::isBytecodeTop const):
1798         (JSC::DFG::AbstractValue::validateOSREntryValue const):
1799         * dfg/testdfg.cpp: Added.
1800         (hiddenTruthBecauseNoReturnIsStupid):
1801         (usage):
1802         (JSC::DFG::testEmptyValueDoesNotValidateWithHeapTop):
1803         (JSC::DFG::run):
1804         (run):
1805         (main):
1806         * shell/CMakeLists.txt:
1807
1808 2019-03-20  Saam Barati  <sbarati@apple.com>
1809
1810         typeOfDoubleSum is wrong for when NaN can be produced
1811         https://bugs.webkit.org/show_bug.cgi?id=196030
1812
1813         Reviewed by Filip Pizlo.
1814
1815         We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
1816         It assumed that the only way the resulting type could be NaN is if one of
1817         the inputs were NaN. However, this is wrong. NaN can be produced in at least
1818         these cases:
1819           Infinity - Infinity
1820           Infinity + (-Infinity)
1821           Infinity * 0
1822
1823         * bytecode/SpeculatedType.cpp:
1824         (JSC::typeOfDoubleSumOrDifferenceOrProduct):
1825         (JSC::typeOfDoubleSum):
1826         (JSC::typeOfDoubleDifference):
1827         (JSC::typeOfDoubleProduct):
1828
1829 2019-03-20  Simon Fraser  <simon.fraser@apple.com>
1830
1831         Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
1832         https://bugs.webkit.org/show_bug.cgi?id=196049
1833
1834         Reviewed by Tim Horton.
1835
1836         This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
1837         overflow scrolling in general, so rename it.
1838
1839         * Configurations/FeatureDefines.xcconfig:
1840
1841 2019-03-20  Saam Barati  <sbarati@apple.com>
1842
1843         GetCallee does not report the correct type in AI
1844         https://bugs.webkit.org/show_bug.cgi?id=195981
1845
1846         Reviewed by Yusuke Suzuki.
1847
1848         I found this as part of my work in:
1849         https://bugs.webkit.org/show_bug.cgi?id=195924
1850         
1851         I'm not sure how to write a test for it.
1852         
1853         GetCallee was always reporting that the result is SpecFunction. However,
1854         for eval, it may result in just a JSCallee object, which is not a JSFunction.
1855
1856         * dfg/DFGAbstractInterpreterInlines.h:
1857         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1858
1859 2019-03-20  Mark Lam  <mark.lam@apple.com>
1860
1861         Open source arm64e code.
1862         https://bugs.webkit.org/show_bug.cgi?id=196012
1863         <rdar://problem/49066237>
1864
1865         Reviewed by Keith Miller.
1866
1867         * JavaScriptCore.xcodeproj/project.pbxproj:
1868         * Sources.txt:
1869         * assembler/ARM64EAssembler.h: Added.
1870         (JSC::ARM64EAssembler::encodeGroup1):
1871         (JSC::ARM64EAssembler::encodeGroup2):
1872         (JSC::ARM64EAssembler::encodeGroup4):
1873         (JSC::ARM64EAssembler::pacia1716):
1874         (JSC::ARM64EAssembler::pacib1716):
1875         (JSC::ARM64EAssembler::autia1716):
1876         (JSC::ARM64EAssembler::autib1716):
1877         (JSC::ARM64EAssembler::paciaz):
1878         (JSC::ARM64EAssembler::paciasp):
1879         (JSC::ARM64EAssembler::pacibz):
1880         (JSC::ARM64EAssembler::pacibsp):
1881         (JSC::ARM64EAssembler::autiaz):
1882         (JSC::ARM64EAssembler::autiasp):
1883         (JSC::ARM64EAssembler::autibz):
1884         (JSC::ARM64EAssembler::autibsp):
1885         (JSC::ARM64EAssembler::xpaclri):
1886         (JSC::ARM64EAssembler::pacia):
1887         (JSC::ARM64EAssembler::pacib):
1888         (JSC::ARM64EAssembler::pacda):
1889         (JSC::ARM64EAssembler::pacdb):
1890         (JSC::ARM64EAssembler::autia):
1891         (JSC::ARM64EAssembler::autib):
1892         (JSC::ARM64EAssembler::autda):
1893         (JSC::ARM64EAssembler::autdb):
1894         (JSC::ARM64EAssembler::paciza):
1895         (JSC::ARM64EAssembler::pacizb):
1896         (JSC::ARM64EAssembler::pacdza):
1897         (JSC::ARM64EAssembler::pacdzb):
1898         (JSC::ARM64EAssembler::autiza):
1899         (JSC::ARM64EAssembler::autizb):
1900         (JSC::ARM64EAssembler::autdza):
1901         (JSC::ARM64EAssembler::autdzb):
1902         (JSC::ARM64EAssembler::xpaci):
1903         (JSC::ARM64EAssembler::xpacd):
1904         (JSC::ARM64EAssembler::pacga):
1905         (JSC::ARM64EAssembler::braa):
1906         (JSC::ARM64EAssembler::brab):
1907         (JSC::ARM64EAssembler::blraa):
1908         (JSC::ARM64EAssembler::blrab):
1909         (JSC::ARM64EAssembler::braaz):
1910         (JSC::ARM64EAssembler::brabz):
1911         (JSC::ARM64EAssembler::blraaz):
1912         (JSC::ARM64EAssembler::blrabz):
1913         (JSC::ARM64EAssembler::retaa):
1914         (JSC::ARM64EAssembler::retab):
1915         (JSC::ARM64EAssembler::eretaa):
1916         (JSC::ARM64EAssembler::eretab):
1917         (JSC::ARM64EAssembler::linkPointer):
1918         (JSC::ARM64EAssembler::repatchPointer):
1919         (JSC::ARM64EAssembler::setPointer):
1920         (JSC::ARM64EAssembler::readPointer):
1921         (JSC::ARM64EAssembler::readCallTarget):
1922         (JSC::ARM64EAssembler::ret):
1923         * assembler/MacroAssembler.cpp:
1924         * assembler/MacroAssembler.h:
1925         * assembler/MacroAssemblerARM64.cpp:
1926         * assembler/MacroAssemblerARM64E.h: Added.
1927         (JSC::MacroAssemblerARM64E::tagReturnAddress):
1928         (JSC::MacroAssemblerARM64E::untagReturnAddress):
1929         (JSC::MacroAssemblerARM64E::tagPtr):
1930         (JSC::MacroAssemblerARM64E::untagPtr):
1931         (JSC::MacroAssemblerARM64E::removePtrTag):
1932         (JSC::MacroAssemblerARM64E::callTrustedPtr):
1933         (JSC::MacroAssemblerARM64E::call):
1934         (JSC::MacroAssemblerARM64E::callRegister):
1935         (JSC::MacroAssemblerARM64E::jump):
1936         * dfg/DFGOSRExit.cpp:
1937         (JSC::DFG::reifyInlinedCallFrames):
1938         * dfg/DFGOSRExitCompilerCommon.cpp:
1939         (JSC::DFG::reifyInlinedCallFrames):
1940         * ftl/FTLThunks.cpp:
1941         (JSC::FTL::genericGenerationThunkGenerator):
1942         * jit/CCallHelpers.h:
1943         (JSC::CCallHelpers::prepareForTailCallSlow):
1944         * jit/CallFrameShuffler.cpp:
1945         (JSC::CallFrameShuffler::prepareForTailCall):
1946         * jit/ExecutableAllocator.cpp:
1947         (JSC::ExecutableAllocator::allocate):
1948         * jit/ThunkGenerators.cpp:
1949         (JSC::arityFixupGenerator):
1950         * llint/LLIntOfflineAsmConfig.h:
1951         * llint/LowLevelInterpreter.asm:
1952         * llint/LowLevelInterpreter64.asm:
1953         * runtime/ClassInfo.h:
1954         * runtime/InitializeThreading.cpp:
1955         (JSC::initializeThreading):
1956         * runtime/JSCPtrTag.cpp: Added.
1957         (JSC::tagForPtr):
1958         (JSC::ptrTagName):
1959         (JSC::initializePtrTagLookup):
1960         * runtime/JSCPtrTag.h:
1961         (JSC::initializePtrTagLookup):
1962         * runtime/Options.cpp:
1963         (JSC::recomputeDependentOptions):
1964
1965 2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>
1966
1967         JSC::createError needs to check for OOM in errorDescriptionForValue
1968         https://bugs.webkit.org/show_bug.cgi?id=196032
1969         <rdar://problem/46842740>
1970
1971         Reviewed by Mark Lam.
1972
1973         We were missing exceptions checks at two levels:
1974         - In errorDescriptionForValue, when the value is a string, we should
1975           check that JSString::value returns a valid string, since we might run
1976           out of memory if it is a rope and we need to resolve it.
1977         - In createError, we should check for the result of errorDescriptionForValue
1978           before concatenating it with the message provided by the caller.
1979
1980         * runtime/ExceptionHelpers.cpp:
1981         (JSC::errorDescriptionForValue):
1982         (JSC::createError):
1983         * runtime/ExceptionHelpers.h:
1984
1985 2019-03-20  Devin Rousso  <drousso@apple.com>
1986
1987         Web Inspector: DOM: include window as part of any event listener chain
1988         https://bugs.webkit.org/show_bug.cgi?id=195730
1989         <rdar://problem/48916872>
1990
1991         Reviewed by Timothy Hatcher.
1992
1993         * inspector/protocol/DOM.json:
1994         Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
1995         used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
1996         when the event listener was retrieved from the `window` object.
1997
1998 2019-03-20  Devin Rousso  <drousso@apple.com>
1999
2000         Web Inspector: Runtime: lazily create the agent
2001         https://bugs.webkit.org/show_bug.cgi?id=195972
2002         <rdar://problem/49039655>
2003
2004         Reviewed by Timothy Hatcher.
2005
2006         * inspector/JSGlobalObjectInspectorController.cpp:
2007         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2008         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2009
2010         * inspector/agents/InspectorRuntimeAgent.h:
2011         (Inspector::InspectorRuntimeAgent::enabled): Deleted.
2012         * inspector/agents/InspectorRuntimeAgent.cpp:
2013         (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
2014         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
2015
2016         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
2017         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
2018         (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
2019
2020 2019-03-20  Michael Saboff  <msaboff@apple.com>
2021
2022         JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
2023         https://bugs.webkit.org/show_bug.cgi?id=195906
2024
2025         Reviewed by Mark Lam.
2026
2027         The problem here as that we may successfully parsed a RegExp without running out of stack,
2028         but later run out of stack when trying to JIT compile the same expression.
2029
2030         Added a check for available stack space when we call into one of the parenthesis compilation
2031         functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
2032         compilation and let the interpreter handle the expression.
2033
2034         From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
2035         Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
2036         Given that we can reproduce a failure, this is sufficient for now.
2037
2038         This change is covered by the previously added failing test,
2039         JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
2040
2041         * yarr/YarrInterpreter.cpp:
2042         (JSC::Yarr::Interpreter::interpret):
2043         * yarr/YarrJIT.cpp:
2044         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
2045         (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
2046         (JSC::Yarr::YarrGenerator::opCompileBody):
2047         (JSC::Yarr::dumpCompileFailure):
2048         * yarr/YarrJIT.h:
2049
2050 2019-03-20  Robin Morisset  <rmorisset@apple.com>
2051
2052         DFGNodeAllocator.h is dead code
2053         https://bugs.webkit.org/show_bug.cgi?id=196019
2054
2055         Reviewed by Yusuke Suzuki.
2056
2057         As explained by Yusuke on IRC, the comment on DFG::Node saying that it cannot have a destructor is obsolete since https://trac.webkit.org/changeset/216815/webkit.
2058         This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
2059
2060         * dfg/DFGNode.h:
2061         (JSC::DFG::Node::dumpChildren):
2062         * dfg/DFGNodeAllocator.h: Removed.
2063
2064 2019-03-20  Robin Morisset  <rmorisset@apple.com>
2065
2066         Compress CodeOrigin into a single word in the common case
2067         https://bugs.webkit.org/show_bug.cgi?id=195928
2068
2069         Reviewed by Saam Barati.
2070
2071         The trick is that pointers only take 48 bits on x86_64 in practice (and we can even use the bottom three bits of that thanks to alignment), and even less on ARM64.
2072         So we can shove the bytecode index in the top bits almost all the time.
2073         If the bytecodeIndex is too ginormous (1<<16 in practice on x86_64), we just set one bit at the bottom and store a pointer to some out-of-line storage instead.
2074         Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
2075
2076         The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
2077
2078         End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
2079         As a reference, during running JetStream2 we allocate more than 35M CodeOrigins. While they won't all be alive at the same time, it is still quite a lot of objects, so I am hoping for some small
2080         improvement to RAMification from this work.
2081
2082         The one slightly tricky part is that we must implement copy and move assignment operators and constructors to make sure that any out-of-line storage belongs to a single CodeOrigin and is destroyed exactly once.
2083
2084         * bytecode/ByValInfo.h:
2085         * bytecode/CallLinkStatus.cpp:
2086         (JSC::CallLinkStatus::computeFor):
2087         * bytecode/CodeBlock.cpp:
2088         (JSC::CodeBlock::globalObjectFor):
2089         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
2090         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
2091         * bytecode/CodeOrigin.cpp:
2092         (JSC::CodeOrigin::inlineDepth const):
2093         (JSC::CodeOrigin::isApproximatelyEqualTo const):
2094         (JSC::CodeOrigin::approximateHash const):
2095         (JSC::CodeOrigin::inlineStack const):
2096         (JSC::CodeOrigin::codeOriginOwner const):
2097         (JSC::CodeOrigin::stackOffset const):
2098         (JSC::CodeOrigin::dump const):
2099         (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
2100         * bytecode/CodeOrigin.h:
2101         (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
2102         (JSC::CodeOrigin::CodeOrigin):
2103         (JSC::CodeOrigin::~CodeOrigin):
2104         (JSC::CodeOrigin::isSet const):
2105         (JSC::CodeOrigin::isHashTableDeletedValue const):
2106         (JSC::CodeOrigin::bytecodeIndex const):
2107         (JSC::CodeOrigin::inlineCallFrame const):
2108         (JSC::CodeOrigin::buildCompositeValue):
2109         (JSC::CodeOrigin::hash const):
2110         (JSC::CodeOrigin::operator== const):
2111         (JSC::CodeOrigin::exitingInlineKind const): Deleted.
2112         * bytecode/DeferredSourceDump.h:
2113         * bytecode/GetByIdStatus.cpp:
2114         (JSC::GetByIdStatus::computeForStubInfo):
2115         (JSC::GetByIdStatus::computeFor):
2116         * bytecode/ICStatusMap.cpp:
2117         (JSC::ICStatusContext::isInlined const):
2118         * bytecode/InByIdStatus.cpp:
2119         (JSC::InByIdStatus::computeFor):
2120         (JSC::InByIdStatus::computeForStubInfo):
2121         * bytecode/InlineCallFrame.cpp:
2122         (JSC::InlineCallFrame::dumpInContext const):
2123         * bytecode/InlineCallFrame.h:
2124         (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
2125         (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
2126         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
2127         (JSC::CodeOrigin::walkUpInlineStack):
2128         * bytecode/InstanceOfStatus.h:
2129         * bytecode/PutByIdStatus.cpp:
2130         (JSC::PutByIdStatus::computeForStubInfo):
2131         (JSC::PutByIdStatus::computeFor):
2132         * dfg/DFGAbstractInterpreterInlines.h:
2133         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2134         * dfg/DFGArgumentsEliminationPhase.cpp:
2135         * dfg/DFGArgumentsUtilities.cpp:
2136         (JSC::DFG::argumentsInvolveStackSlot):
2137         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
2138         * dfg/DFGArrayMode.h:
2139         * dfg/DFGByteCodeParser.cpp:
2140         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
2141         (JSC::DFG::ByteCodeParser::setLocal):
2142         (JSC::DFG::ByteCodeParser::setArgument):
2143         (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
2144         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2145         (JSC::DFG::ByteCodeParser::parseBlock):
2146         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2147         (JSC::DFG::ByteCodeParser::handlePutByVal):
2148         * dfg/DFGClobberize.h:
2149         (JSC::DFG::clobberize):
2150         * dfg/DFGConstantFoldingPhase.cpp:
2151         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2152         * dfg/DFGFixupPhase.cpp:
2153         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
2154         * dfg/DFGForAllKills.h:
2155         (JSC::DFG::forAllKilledOperands):
2156         * dfg/DFGGraph.cpp:
2157         (JSC::DFG::Graph::dumpCodeOrigin):
2158         (JSC::DFG::Graph::dump):
2159         (JSC::DFG::Graph::isLiveInBytecode):
2160         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2161         (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
2162         * dfg/DFGGraph.h:
2163         (JSC::DFG::Graph::executableFor):
2164         (JSC::DFG::Graph::isStrictModeFor):
2165         (JSC::DFG::Graph::hasExitSite):
2166         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2167         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2168         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
2169         * dfg/DFGMinifiedNode.cpp:
2170         (JSC::DFG::MinifiedNode::fromNode):
2171         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2172         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
2173         * dfg/DFGOSRExit.cpp:
2174         (JSC::DFG::OSRExit::executeOSRExit):
2175         (JSC::DFG::reifyInlinedCallFrames):
2176         (JSC::DFG::adjustAndJumpToTarget):
2177         (JSC::DFG::printOSRExit):
2178         (JSC::DFG::OSRExit::compileExit):
2179         * dfg/DFGOSRExitBase.cpp:
2180         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
2181         * dfg/DFGOSRExitCompilerCommon.cpp:
2182         (JSC::DFG::handleExitCounts):
2183         (JSC::DFG::reifyInlinedCallFrames):
2184         (JSC::DFG::adjustAndJumpToTarget):
2185         * dfg/DFGOSRExitPreparation.cpp:
2186         (JSC::DFG::prepareCodeOriginForOSRExit):
2187         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2188         * dfg/DFGOperations.cpp:
2189         * dfg/DFGPreciseLocalClobberize.h:
2190         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2191         * dfg/DFGSpeculativeJIT.cpp:
2192         (JSC::DFG::SpeculativeJIT::emitGetLength):
2193         (JSC::DFG::SpeculativeJIT::emitGetCallee):
2194         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2195         (JSC::DFG::SpeculativeJIT::compileValueAdd):
2196         (JSC::DFG::SpeculativeJIT::compileValueSub):
2197         (JSC::DFG::SpeculativeJIT::compileValueNegate):
2198         (JSC::DFG::SpeculativeJIT::compileValueMul):
2199         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
2200         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
2201         * dfg/DFGSpeculativeJIT32_64.cpp:
2202         (JSC::DFG::SpeculativeJIT::emitCall):
2203         * dfg/DFGSpeculativeJIT64.cpp:
2204         (JSC::DFG::SpeculativeJIT::emitCall):
2205         (JSC::DFG::SpeculativeJIT::compile):
2206         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2207         (JSC::DFG::TierUpCheckInjectionPhase::run):
2208         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
2209         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
2210         * dfg/DFGTypeCheckHoistingPhase.cpp:
2211         (JSC::DFG::TypeCheckHoistingPhase::run):
2212         * dfg/DFGVariableEventStream.cpp:
2213         (JSC::DFG::VariableEventStream::reconstruct const):
2214         * ftl/FTLLowerDFGToB3.cpp:
2215         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
2216         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
2217         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
2218         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
2219         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
2220         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
2221         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
2222         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
2223         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
2224         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
2225         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
2226         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
2227         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
2228         (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
2229         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
2230         (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
2231         * ftl/FTLOSRExitCompiler.cpp:
2232         (JSC::FTL::compileStub):
2233         * ftl/FTLOperations.cpp:
2234         (JSC::FTL::operationMaterializeObjectInOSR):
2235         * interpreter/CallFrame.cpp:
2236         (JSC::CallFrame::bytecodeOffset):
2237         * interpreter/StackVisitor.cpp:
2238         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
2239         (JSC::StackVisitor::readFrame):
2240         (JSC::StackVisitor::readNonInlinedFrame):
2241         (JSC::inlinedFrameOffset):
2242         (JSC::StackVisitor::readInlinedFrame):
2243         * interpreter/StackVisitor.h:
2244         * jit/AssemblyHelpers.cpp:
2245         (JSC::AssemblyHelpers::executableFor):
2246         * jit/AssemblyHelpers.h:
2247         (JSC::AssemblyHelpers::isStrictModeFor):
2248         (JSC::AssemblyHelpers::argumentsStart):
2249         (JSC::AssemblyHelpers::argumentCount):
2250         * jit/PCToCodeOriginMap.cpp:
2251         (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
2252         (JSC::PCToCodeOriginMap::findPC const):
2253         * profiler/ProfilerOriginStack.cpp:
2254         (JSC::Profiler::OriginStack::OriginStack):
2255         * profiler/ProfilerOriginStack.h:
2256         * runtime/ErrorInstance.cpp:
2257         (JSC::appendSourceToError):
2258         * runtime/SamplingProfiler.cpp:
2259         (JSC::SamplingProfiler::processUnverifiedStackTraces):
2260
2261 2019-03-20  Devin Rousso  <drousso@apple.com>
2262
2263         Web Inspector: Search: allow DOM searches to be case sensitive
2264         https://bugs.webkit.org/show_bug.cgi?id=194673
2265         <rdar://problem/48087577>
2266
2267         Reviewed by Timothy Hatcher.
2268
2269         Since `DOM.performSearch` also searches by selector and XPath, some results may appear
2270         as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
2271         as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
2272
2273         * inspector/protocol/DOM.json:
2274         Allow `DOM.performSearch` to be case sensitive.
2275
2276 2019-03-20  Saam Barati  <sbarati@apple.com>
2277
2278         AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
2279         https://bugs.webkit.org/show_bug.cgi?id=195980
2280
2281         Reviewed by Yusuke Suzuki.
2282
2283         They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
2284         However, they should have been type: (SpecInt32Only, SpecBigInt)
2285
2286         * dfg/DFGAbstractInterpreterInlines.h:
2287         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2288
2289 2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>
2290
2291         Remove copyRef() calls added in r243163
2292         https://bugs.webkit.org/show_bug.cgi?id=195962
2293
2294         Reviewed by Chris Dumez.
2295
2296         As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
2297         value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
2298         without refcount churn by introducing an intermediate variable.
2299
2300         * inspector/scripts/codegen/cpp_generator_templates.py:
2301
2302 2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>
2303
2304         [GLIB] Optimize jsc_value_object_define_property_data|accessor
2305         https://bugs.webkit.org/show_bug.cgi?id=195679
2306
2307         Reviewed by Saam Barati.
2308
2309         Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
2310
2311         * API/glib/JSCValue.cpp:
2312         (jsc_value_object_define_property_data):
2313         (jsc_value_object_define_property_accessor):
2314
2315 2019-03-19  Devin Rousso  <drousso@apple.com>
2316
2317         Web Inspector: Debugger: lazily create the agent
2318         https://bugs.webkit.org/show_bug.cgi?id=195973
2319         <rdar://problem/49039674>
2320
2321         Reviewed by Joseph Pecoraro.
2322
2323         * inspector/JSGlobalObjectInspectorController.cpp:
2324         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2325         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
2326         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2327
2328         * inspector/JSGlobalObjectConsoleClient.h:
2329         (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
2330         * inspector/JSGlobalObjectConsoleClient.cpp:
2331         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
2332         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2333         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2334
2335         * inspector/agents/InspectorDebuggerAgent.h:
2336         (Inspector::InspectorDebuggerAgent::addListener): Added.
2337         (Inspector::InspectorDebuggerAgent::removeListener): Added.
2338         (Inspector::InspectorDebuggerAgent::setListener): Deleted.
2339         * inspector/agents/InspectorDebuggerAgent.cpp:
2340         (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
2341         (Inspector::InspectorDebuggerAgent::enable):
2342         (Inspector::InspectorDebuggerAgent::disable):
2343         (Inspector::InspectorDebuggerAgent::getScriptSource):
2344         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
2345         (Inspector::InspectorDebuggerAgent::didPause):
2346         (Inspector::InspectorDebuggerAgent::breakProgram):
2347         (Inspector::InspectorDebuggerAgent::clearBreakDetails):
2348         Drive-by: reorder some member variables for better sizing.
2349         Drive-by: rename some member variables for clarity.
2350
2351 2019-03-19  Saam barati  <sbarati@apple.com>
2352
2353         Prune code after ForceOSRExit
2354         https://bugs.webkit.org/show_bug.cgi?id=195913
2355
2356         Reviewed by Keith Miller.
2357
2358         I removed our original implementation of this in r242989 because
2359         it was not sound. It broke backwards propagation because it removed
2360         uses of a node that backwards propagation relied on to be sound.
2361         Essentially, backwards propagation relies on being able to see uses
2362         that would exist in bytecode to be sound.
2363         
2364         The rollout in r242989 was a 1% Speedometer2 regression. This patch
2365         rolls back in the optimization in a sound way.
2366         
2367         This patch augments the code we had prior to r242989 to be sound. In
2368         addition to preserving liveness, we now also convert all uses after
2369         the ForceOSRExit to be Phantom. This may pessimize the optimizations
2370         we do in backwards propagation, but it will prevent that phase from
2371         making unsound optimizations.
2372
2373         * dfg/DFGByteCodeParser.cpp:
2374         (JSC::DFG::ByteCodeParser::addToGraph):
2375         (JSC::DFG::ByteCodeParser::parse):
2376
2377 2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
2378
2379         Build cleanly with GCC 9
2380         https://bugs.webkit.org/show_bug.cgi?id=195920
2381
2382         Reviewed by Chris Dumez.
2383
2384         WebKit triggers three new GCC 9 warnings:
2385
2386         """
2387         -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
2388         declared copy constructor and assignment operator if one of them is user-provided.
2389         """
2390
2391         Solution is to either add a copy constructor or copy assignment operator, if required, or
2392         else remove one if it is redundant.
2393
2394         """
2395         -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
2396         -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
2397         """
2398
2399         These account for most of this patch. Solution is to just remove the bad WTFMove().
2400
2401         Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
2402         These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
2403         would be safer to not use memcpy on nontrivial types, but that's too complex for this
2404         patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
2405
2406         * b3/B3ValueRep.h:
2407         * bindings/ScriptValue.cpp:
2408         (Inspector::jsToInspectorValue):
2409         * bytecode/GetterSetterAccessCase.cpp:
2410         (JSC::GetterSetterAccessCase::create):
2411         (JSC::GetterSetterAccessCase::clone const):
2412         * bytecode/InstanceOfAccessCase.cpp:
2413         (JSC::InstanceOfAccessCase::clone const):
2414         * bytecode/IntrinsicGetterAccessCase.cpp:
2415         (JSC::IntrinsicGetterAccessCase::clone const):
2416         * bytecode/ModuleNamespaceAccessCase.cpp:
2417         (JSC::ModuleNamespaceAccessCase::clone const):
2418         * bytecode/ProxyableAccessCase.cpp:
2419         (JSC::ProxyableAccessCase::clone const):
2420         * bytecode/StructureSet.h:
2421         * debugger/Breakpoint.h:
2422         * dfg/DFGRegisteredStructureSet.h:
2423         * inspector/agents/InspectorDebuggerAgent.cpp:
2424         (Inspector::buildDebuggerLocation):
2425         * inspector/scripts/codegen/cpp_generator_templates.py:
2426         * parser/UnlinkedSourceCode.h:
2427         * wasm/WasmAirIRGenerator.cpp:
2428         (JSC::Wasm::parseAndCompileAir):
2429         * wasm/WasmB3IRGenerator.cpp:
2430         (JSC::Wasm::parseAndCompile):
2431         * wasm/WasmNameSectionParser.cpp:
2432         (JSC::Wasm::NameSectionParser::parse):
2433         * wasm/WasmStreamingParser.cpp:
2434         (JSC::Wasm::StreamingParser::consume):
2435
2436 2019-03-19  Saam Barati  <sbarati@apple.com>
2437
2438         Style fix: remove C style cast in Instruction.h
2439         https://bugs.webkit.org/show_bug.cgi?id=195917
2440
2441         Reviewed by Filip Pizlo.
2442
2443         * bytecode/Instruction.h:
2444         (JSC::Instruction::wide const):
2445
2446 2019-03-19  Devin Rousso  <drousso@apple.com>
2447
2448         Web Inspector: Provide $event in the console when paused on an event listener
2449         https://bugs.webkit.org/show_bug.cgi?id=188672
2450
2451         Reviewed by Timothy Hatcher.
2452
2453         * inspector/InjectedScript.h:
2454         * inspector/InjectedScript.cpp:
2455         (Inspector::InjectedScript::setEventValue): Added.
2456         (Inspector::InjectedScript::clearEventValue): Added.
2457
2458         * inspector/InjectedScriptManager.h:
2459         * inspector/InjectedScriptManager.cpp:
2460         (Inspector::InjectedScriptManager::clearEventValue): Added.
2461
2462         * inspector/InjectedScriptSource.js:
2463         (WI.InjectedScript.prototype.setEventValue): Added.
2464         (WI.InjectedScript.prototype.clearEventValue): Added.
2465         (BasicCommandLineAPI):
2466
2467 2019-03-19  Devin Rousso  <drousso@apple.com>
2468
2469         Web Inspector: ScriptProfiler: lazily create the agent
2470         https://bugs.webkit.org/show_bug.cgi?id=195591
2471         <rdar://problem/48791756>
2472
2473         Reviewed by Joseph Pecoraro.
2474
2475         * inspector/JSGlobalObjectConsoleClient.h:
2476         (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
2477         * inspector/JSGlobalObjectConsoleClient.cpp:
2478         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
2479         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2480         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2481
2482         * inspector/JSGlobalObjectInspectorController.cpp:
2483         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2484         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2485
2486 2019-03-19  Devin Rousso  <drousso@apple.com>
2487
2488         Web Inspector: Heap: lazily create the agent
2489         https://bugs.webkit.org/show_bug.cgi?id=195590
2490         <rdar://problem/48791750>
2491
2492         Reviewed by Joseph Pecoraro.
2493
2494         * inspector/agents/InspectorHeapAgent.h:
2495         * inspector/agents/InspectorHeapAgent.cpp:
2496         (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
2497
2498         * inspector/agents/InspectorConsoleAgent.h:
2499         (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
2500         * inspector/agents/InspectorConsoleAgent.cpp:
2501         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
2502         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
2503         (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
2504
2505         * inspector/JSGlobalObjectInspectorController.cpp:
2506         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2507         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
2508
2509 2019-03-19  Caio Lima  <ticaiolima@gmail.com>
2510
2511         [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
2512         https://bugs.webkit.org/show_bug.cgi?id=194648
2513
2514         Reviewed by Keith Miller.
2515
2516         1. Making LLIntThunks singleton. 
2517
2518         Motivation: Former implementation has one LLIntThunk per type per VM.
2519         However, the generated code for every kind of thunk is essentially the
2520         same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
2521         when we have 2 or more VM instantiated. Turn these thunks into
2522         singleton will avoid such wasting.
2523
2524         Tradeoff: This change comes with a price, because we will keep thunks
2525         allocated even when there is no VM instantiated. Considering WebCore use case,
2526         the situation of having no VM instantiated is uncommon, since once a
2527         VM is created through `commomVM()`, it will never be destroyed. Given
2528         that, this change does not impact the overall memory comsumption of
2529         WebCore/JSC. It also doesn't impact memory footprint, since thunks are
2530         generated lazily (see results below).
2531
2532         Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
2533         we have the assurance that JITed code will never be deallocated,
2534         given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
2535         To understand why we decided to make LLIntThunks singleton instead of
2536         removing them, please see the comment on `llint/LLIntThunks.cpp`.
2537
2538         2. Making all LLIntEntrypoints singleton
2539
2540         Motivation: With singleton LLIntThunks, we also can have singleton
2541         DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
2542         avoid multiple allocations of objects with the same content.
2543
2544         Tradeoff: As explained before, once we allocate an entrypoint, it
2545         will be alive until the program exits. However, the gains we can
2546         achieve in some use cases justifies such allocations.
2547
2548         As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
2549         `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
2550         will never be less than 1.
2551
2552         3. Memory usage analysis
2553
2554         This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
2555         by 2% and is neutral on JetStream 2. Following results were generated
2556         running each benchmark 6 times and using 95% Student's t distribution
2557         confidence interval.
2558
2559         microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
2560             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
2561             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
2562
2563         JetStream2 (Neutral):
2564             Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
2565             Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
2566
2567         4. Performance Analysis
2568
2569         This change is performance neutral on JetStream 2 and Speedometer 2.
2570         See results below.:
2571
2572         JetStream 2 (Neutral):
2573             Mean of score on ToT: 139.58 (confidence interval: 2.44)
2574             Mean of score on Changes: 141.46 (confidence interval: 4.24)
2575
2576         Speedometer run #1
2577            ToT: 110 +- 2.9
2578            Changes: 110 +- 1.8
2579
2580         Speedometer run #2
2581            ToT: 110 +- 1.6
2582            Changes: 108 +- 2.3
2583
2584         Speedometer run #3
2585            ToT: 110 +- 3.0
2586            Changes: 110 +- 1.4
2587
2588         * jit/JSInterfaceJIT.h:
2589         (JSC::JSInterfaceJIT::JSInterfaceJIT):
2590         * llint/LLIntEntrypoint.cpp:
2591
2592         Here we are changing the usage or DirectJITCode by NativeJITCode on cases
2593         where there is no difference from address of calls with and without
2594         ArithCheck.
2595
2596         (JSC::LLInt::setFunctionEntrypoint):
2597         (JSC::LLInt::setEvalEntrypoint):
2598         (JSC::LLInt::setProgramEntrypoint):
2599         (JSC::LLInt::setModuleProgramEntrypoint):
2600         (JSC::LLInt::setEntrypoint):
2601         * llint/LLIntEntrypoint.h:
2602         * llint/LLIntThunks.cpp:
2603         (JSC::LLInt::generateThunkWithJumpTo):
2604         (JSC::LLInt::functionForCallEntryThunk):
2605         (JSC::LLInt::functionForConstructEntryThunk):
2606         (JSC::LLInt::functionForCallArityCheckThunk):
2607         (JSC::LLInt::functionForConstructArityCheckThunk):
2608         (JSC::LLInt::evalEntryThunk):
2609         (JSC::LLInt::programEntryThunk):
2610         (JSC::LLInt::moduleProgramEntryThunk):
2611         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
2612         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
2613         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
2614         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
2615         (JSC::LLInt::evalEntryThunkGenerator): Deleted.
2616         (JSC::LLInt::programEntryThunkGenerator): Deleted.
2617         (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
2618         * llint/LLIntThunks.h:
2619         * runtime/ScriptExecutable.cpp:
2620         (JSC::setupLLInt):
2621         (JSC::ScriptExecutable::prepareForExecutionImpl):
2622
2623 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2624
2625         [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
2626         https://bugs.webkit.org/show_bug.cgi?id=195927
2627
2628         Reviewed by Mark Lam.
2629
2630         r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
2631         This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
2632
2633         * runtime/RegExpConstructor.cpp:
2634         (JSC::setRegExpConstructorInput):
2635         (JSC::setRegExpConstructorMultiline):
2636         * runtime/RegExpGlobalData.cpp:
2637         (JSC::RegExpGlobalData::getBackref):
2638         (JSC::RegExpGlobalData::getLastParen):
2639
2640 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2641
2642         [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
2643         https://bugs.webkit.org/show_bug.cgi?id=195901
2644
2645         Reviewed by Saam Barati.
2646
2647         It is not rare that generators do not need to have any registers to be suspended and resumed.
2648         Since currently we always emit op_create_lexical_environment for generator code, we sometimes
2649         create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
2650         are allocated in RAMification's Basic test.
2651
2652         This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
2653         a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
2654         based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
2655
2656         We run RAMification in 6 times, use average of them.
2657         RAMification's Basic in JIT mode shows 1.4% improvement.
2658         ToT
2659             Current: 55076864.00, Peak: 55080960.00
2660         Patched
2661             Current: 54325930.67, Peak: 54329344.00
2662
2663         RAMification's Basic in non-JIT mode shows 5.0% improvement.
2664         ToT
2665             Current: 12485290.67, Peak: 12485290.67
2666         Patched
2667             Current: 11894101.33, Peak: 11894101.33
2668
2669         * bytecode/BytecodeGeneratorification.cpp:
2670         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
2671         (JSC::BytecodeGeneratorification::generatorFrameData const):
2672         (JSC::BytecodeGeneratorification::run):
2673         * bytecode/BytecodeList.rb:
2674         * bytecode/BytecodeUseDef.h:
2675         (JSC::computeUsesForBytecodeOffset):
2676         (JSC::computeDefsForBytecodeOffset):
2677         * bytecompiler/BytecodeGenerator.cpp:
2678         (JSC::BytecodeGenerator::BytecodeGenerator):
2679         * dfg/DFGCapabilities.cpp:
2680         (JSC::DFG::capabilityLevel):
2681         * llint/LowLevelInterpreter.asm:
2682
2683 2019-03-18  Robin Morisset  <rmorisset@apple.com>
2684
2685         Remove the inline capacity of Operands
2686         https://bugs.webkit.org/show_bug.cgi?id=195898
2687
2688         Reviewed by Yusuke Suzuki.
2689
2690         Operands currently has a vector with an inline capacity of 24.
2691         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
2692         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
2693         Still on JetStream 2, functions have an average of 18 BB, but those functions whose operands overflow have an average of 27 BB (so we are wasting 72kB on average when compiling them), and the largest function has 1241 BB (!), for a total of 3.3MB being wasted while it is compiled.
2694         
2695         So I removed the inline capacity of the vector in Operands, and here are the results:
2696         Baseline Jetstream2:
2697         159.741
2698         159.746
2699         159.989
2700         Baseline RAMification on grouped and jit tests: (end/peak/score)
2701         89.288/89.763/89.526
2702         90.166/90.761/90.418
2703         89.560/90.014/89.787
2704         After optimization Jetstream2:
2705         159.342
2706         161.812
2707         162.037
2708         After optimization RAMification:
2709         89.147/89.644/89.395
2710         89.102.89.585/89.343
2711         88.953/89.536/89.2444
2712         
2713         So it looks like a roughly 1% improvement on RAMification (at least the tests where the JIT is enabled), and more surprisingly also a 1% progression on Jetstream2 (although I have more doubts about this one considering the variability in my numbers).
2714         I hope to land this, and get more accurate results from the bots.
2715
2716         * bytecode/Operands.h:
2717
2718 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2719
2720         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
2721         https://bugs.webkit.org/show_bug.cgi?id=195897
2722
2723         Reviewed by Keith Miller.
2724
2725         It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
2726         I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
2727         This patch adds,
2728
2729         1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
2730         2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
2731
2732         While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
2733         we would like to collect heap statistics and dump them to investigate Heap status more.
2734
2735         This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
2736
2737         * heap/Heap.cpp:
2738         (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
2739         (JSC::Heap::lastChanceToFinalize):
2740         * heap/Heap.h:
2741         * jsc.cpp:
2742         (printUsageStatement):
2743         (CommandLine::parseArguments):
2744         (runJSC):
2745         * runtime/Options.h:
2746
2747 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
2748
2749         [JSC] jsSubstring should resolve rope before calling JSRopeString::create
2750         https://bugs.webkit.org/show_bug.cgi?id=195840
2751
2752         Reviewed by Geoffrey Garen.
2753
2754         jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
2755         as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
2756         So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
2757         of single character substrings.
2758
2759         We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
2760         strings to save memory.
2761
2762         This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
2763
2764         * dfg/DFGOperations.cpp:
2765         * runtime/JSString.cpp:
2766         (JSC::JSString::dumpToStream):
2767         * runtime/JSString.h:
2768         (JSC::jsSubstring):
2769         (JSC::jsSubstringOfResolved):
2770         (JSC::jsSingleCharacterString):
2771         * runtime/RegExpCachedResult.cpp:
2772         (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
2773         (JSC::RegExpCachedResult::leftContext):
2774         (JSC::RegExpCachedResult::rightContext):
2775         (JSC::RegExpCachedResult::setInput):
2776         * runtime/RegExpGlobalData.cpp:
2777         (JSC::RegExpGlobalData::getBackref):
2778         (JSC::RegExpGlobalData::getLastParen):
2779         * runtime/StringObject.h:
2780         (JSC::jsStringWithReuse):
2781         (JSC::jsSubstring):
2782         * runtime/StringPrototype.cpp:
2783         (JSC::replaceUsingRegExpSearch):
2784         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
2785         (JSC::replaceUsingStringSearch):
2786         (JSC::stringProtoFuncSlice):
2787         (JSC::splitStringByOneCharacterImpl):
2788         (JSC::stringProtoFuncSplitFast):
2789         (JSC::stringProtoFuncSubstr):
2790         (JSC::stringProtoFuncSubstring):
2791         (JSC::stringProtoFuncToLowerCase):
2792         (JSC::stringProtoFuncToUpperCase):
2793         Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
2794
2795         * runtime/StringPrototypeInlines.h:
2796         (JSC::stringSlice):
2797
2798 2019-03-18  Mark Lam  <mark.lam@apple.com>
2799
2800         Missing a ThrowScope release in JSObject::toString().
2801         https://bugs.webkit.org/show_bug.cgi?id=195893
2802         <rdar://problem/48970986>
2803
2804         Reviewed by Michael Saboff.
2805
2806         Placate the validator with a RELEASE_AND_RETURN().
2807
2808         * runtime/JSObject.cpp:
2809         (JSC::JSObject::toString const):
2810
2811 2019-03-18  Mark Lam  <mark.lam@apple.com>
2812
2813         Structure::flattenDictionary() should clear unused property slots.
2814         https://bugs.webkit.org/show_bug.cgi?id=195871
2815         <rdar://problem/48959497>
2816
2817         Reviewed by Michael Saboff.
2818
2819         It currently attempts to do this but fails because it's actually clearing up the
2820         preCapacity region instead.  The fix is simply to account for the preCapacity
2821         when computing the start address of the property slots.
2822
2823         * runtime/Structure.cpp:
2824         (JSC::Structure::flattenDictionaryStructure):
2825
2826 2019-03-18  Robin Morisset  <rmorisset@apple.com>
2827
2828         B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
2829         https://bugs.webkit.org/show_bug.cgi?id=152164
2830
2831         Reviewed by Filip Pizlo.
2832
2833         Turn this: Shl(<S|Z>Shr(@x, @const), @const)
2834         Into this: BitAnd(@x, -(1<<@const))
2835
2836         I added two tests: one for ZShr/32 bits, and one for SShr/64 bits, I think it is enough coverage (no reason for any interaction between the signedness of the shift and the bitwidth).
2837         I also modified a few adjacent tests to remove undefined behaviours.
2838
2839         * b3/B3ReduceStrength.cpp:
2840         * b3/testb3.cpp:
2841         (JSC::B3::testShlImms):
2842         (JSC::B3::testShlArgImm):
2843         (JSC::B3::testShlSShrArgImm):
2844         (JSC::B3::testShlImms32):
2845         (JSC::B3::testShlArgImm32):
2846         (JSC::B3::testShlZShrArgImm32):
2847         (JSC::B3::run):
2848
2849 2019-03-17  Robin Morisset  <rmorisset@apple.com>
2850
2851         ParserError can be shrunk by 8 bytes
2852         https://bugs.webkit.org/show_bug.cgi?id=195496
2853
2854         Reviewed by Mark Lam.
2855
2856         * parser/ParserError.h:
2857
2858 2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
2859
2860         Fix WPE and GTK Debug builds after r243049
2861         https://bugs.webkit.org/show_bug.cgi?id=195860
2862
2863         Unreviewed, build fix after r243049.
2864
2865         * runtime/StringPrototype.cpp:
2866         (JSC::normalizationAffects8Bit):
2867
2868 2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
2869
2870         REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
2871         https://bugs.webkit.org/show_bug.cgi?id=195858
2872
2873         Reviewed by Mark Lam.
2874
2875         r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
2876         the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
2877         This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
2878         other places to fix the same problem. This bug is caught by existing debug tests for wasm.
2879
2880         * runtime/JSGlobalObject.h:
2881         * wasm/js/JSWebAssemblyCompileError.cpp:
2882         (JSC::createJSWebAssemblyCompileError):
2883         * wasm/js/JSWebAssemblyInstance.cpp:
2884         (JSC::JSWebAssemblyInstance::finalizeCreation):
2885         (JSC::JSWebAssemblyInstance::create):
2886         * wasm/js/JSWebAssemblyLinkError.cpp:
2887         (JSC::createJSWebAssemblyLinkError):
2888         * wasm/js/JSWebAssemblyModule.cpp:
2889         (JSC::JSWebAssemblyModule::createStub):
2890         (JSC::JSWebAssemblyModule::finishCreation):
2891         * wasm/js/WasmToJS.cpp:
2892         (JSC::Wasm::wasmToJSException):
2893         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2894         (JSC::constructJSWebAssemblyCompileError):
2895         (JSC::callJSWebAssemblyCompileError):
2896         * wasm/js/WebAssemblyFunction.cpp:
2897         (JSC::WebAssemblyFunction::create):
2898         * wasm/js/WebAssemblyFunction.h:
2899         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2900         (JSC::constructJSWebAssemblyInstance):
2901         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2902         (JSC::constructJSWebAssemblyLinkError):
2903         (JSC::callJSWebAssemblyLinkError):
2904         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2905         (JSC::constructJSWebAssemblyMemory):
2906         * wasm/js/WebAssemblyModuleConstructor.cpp:
2907         (JSC::WebAssemblyModuleConstructor::createModule):
2908         * wasm/js/WebAssemblyModuleRecord.cpp:
2909         (JSC::WebAssemblyModuleRecord::link):
2910         (JSC::WebAssemblyModuleRecord::evaluate):
2911         * wasm/js/WebAssemblyPrototype.cpp:
2912         (JSC::webAssemblyModuleValidateAsyncInternal):
2913         (JSC::instantiate):
2914         (JSC::compileAndInstantiate):
2915         (JSC::webAssemblyModuleInstantinateAsyncInternal):
2916         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2917         (JSC::constructJSWebAssemblyRuntimeError):
2918         (JSC::callJSWebAssemblyRuntimeError):
2919         * wasm/js/WebAssemblyTableConstructor.cpp:
2920         (JSC::constructJSWebAssemblyTable):
2921         * wasm/js/WebAssemblyToJSCallee.cpp:
2922         (JSC::WebAssemblyToJSCallee::create):
2923         * wasm/js/WebAssemblyToJSCallee.h:
2924         * wasm/js/WebAssemblyWrapperFunction.cpp:
2925         (JSC::WebAssemblyWrapperFunction::create):
2926         * wasm/js/WebAssemblyWrapperFunction.h:
2927
2928 2019-03-16  Darin Adler  <darin@apple.com>
2929
2930         Improve normalization code, including moving from unorm.h to unorm2.h
2931         https://bugs.webkit.org/show_bug.cgi?id=195330
2932
2933         Reviewed by Michael Catanzaro.
2934
2935         * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
2936
2937         * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
2938         (JSC::normalizer): Added. Function to create normalizer object given
2939         enumeration value indicating which is selected. Simplified because we
2940         know the function will not fail and so we don't need error handling code.
2941         (JSC::normalize): Changed this function to take a JSString* so we can
2942         optimize the case where no normalization is needed. Added an early exit
2943         if the string is stored as 8-bit and another if the string is already
2944         normalized, using unorm2_isNormalized. Changed error handling to only
2945         check cases that can actually fail in practice. Also did other small
2946         optimizations like passing VM rather than ExecState.
2947         (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
2948         identical to the names used in the API and normalization parlance rather
2949         than longer ones that expand the acronyms. Updated to pass JSString* to
2950         the normalize function, so we can optimize 8-bit and already-normalized
2951         cases, rather than callling the expensive String::upconvertedCharacters
2952         function. Use throwVMRangeError.
2953
2954 2019-03-15  Mark Lam  <mark.lam@apple.com>
2955
2956         Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
2957         https://bugs.webkit.org/show_bug.cgi?id=195827
2958         <rdar://problem/48845513>
2959
2960         Reviewed by Filip Pizlo.
2961
2962         m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
2963
2964         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
2965         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
2966         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2967         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2968         * bytecode/ObjectPropertyCondition.cpp:
2969         (JSC::ObjectPropertyCondition::dumpInContext const):
2970         * bytecode/StructureStubClearingWatchpoint.cpp:
2971         (JSC::StructureStubClearingWatchpoint::fireInternal):
2972         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2973         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
2974         * runtime/StructureRareData.cpp:
2975         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2976
2977 2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
2978
2979         [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
2980         https://bugs.webkit.org/show_bug.cgi?id=195816
2981
2982         Reviewed by Michael Saboff.
2983
2984         This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
2985
2986         1. iteratorResultObjectStructure
2987         2. WebAssembly related objects except for JSWebAssembly top-level object.
2988
2989         * CMakeLists.txt:
2990         * DerivedSources-input.xcfilelist:
2991         * DerivedSources-output.xcfilelist:
2992         * DerivedSources.make:
2993         * runtime/JSGlobalObject.cpp:
2994         (JSC::JSGlobalObject::init):
2995         (JSC::JSGlobalObject::visitChildren):
2996         * runtime/JSGlobalObject.h:
2997         (JSC::JSGlobalObject::iteratorResultObjectStructure const):
2998         (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
2999         (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
3000         (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
3001         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
3002         * wasm/js/JSWebAssembly.cpp:
3003         * wasm/js/JSWebAssembly.h:
3004
3005 2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
3006
3007         [CMake] Move test .js files into testapiScripts
3008         https://bugs.webkit.org/show_bug.cgi?id=195565
3009
3010         Reviewed by Yusuke Suzuki.
3011
3012         testapi expect .js file in the testapiScripts-directory.
3013
3014         * shell/CMakeLists.txt:
3015
3016 2019-03-15  Mark Lam  <mark.lam@apple.com>
3017
3018         Gardening: add a missing exception check after r242991.
3019         https://bugs.webkit.org/show_bug.cgi?id=195791
3020
3021         Unreviewed.
3022
3023         * tools/JSDollarVM.cpp:
3024         (JSC::functionGetGetterSetter):
3025
3026 2019-03-15  Devin Rousso  <drousso@apple.com>
3027
3028         Web Inspector: provide a way to capture a screenshot of a node from within the page
3029         https://bugs.webkit.org/show_bug.cgi?id=194279
3030         <rdar://problem/10731573>
3031
3032         Reviewed by Joseph Pecoraro.
3033
3034         Add `console.screenshot` functionality, which displays a screenshot of a given object (if
3035         able) within Web Inspector's Console tab. From there, it can be viewed and saved.
3036
3037         Currently, `console.screenshot` will
3038          - capture an image of a `Node` (if provided)
3039          - capture an image of the viewport if nothing is provided
3040
3041         * inspector/protocol/Console.json:
3042         Add `Image` enum value to `ConsoleMessage` type.
3043         * runtime/ConsoleTypes.h:
3044         * inspector/ConsoleMessage.h:
3045         * inspector/ConsoleMessage.cpp:
3046         (Inspector::messageTypeValue):
3047
3048         * runtime/ConsoleClient.h:
3049         * runtime/ConsoleObject.cpp:
3050         (JSC::ConsoleObject::finishCreation):
3051         (JSC::consoleProtoFuncScreenshot): Added.
3052
3053         * inspector/JSGlobalObjectConsoleClient.h:
3054         * inspector/JSGlobalObjectConsoleClient.cpp:
3055         (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
3056
3057 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
3058
3059         [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
3060         https://bugs.webkit.org/show_bug.cgi?id=195791
3061         <rdar://problem/48806130>
3062
3063         Reviewed by Mark Lam.
3064
3065         Consider the following example:
3066
3067             void putByVal(JSObject*, PropertyName propertyName, ...);
3068
3069             putByVal(object, symbol->privateName(), ...);
3070
3071         PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
3072         It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
3073         and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
3074         incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
3075         PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
3076         before passing it to operations which takes it as PropertyName.
3077
3078         1. We use the code pattern like this.
3079
3080             auto propertyName = symbol->privateName();
3081             someOperation(..., propertyName);
3082
3083         This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
3084
3085             auto propertyName = value.toPropertyKey(exec);
3086             RETURN_IF_EXCEPTION(scope, { });
3087             someOperation(..., propertyName);
3088
3089         2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
3090            potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
3091            and they typically need to retain PrivateName.
3092
3093         3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
3094            BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
3095            of `const Identifier&`.
3096
3097         Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
3098         the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
3099
3100         * dfg/DFGOperations.cpp:
3101         * jit/JITOperations.cpp:
3102         (JSC::tryGetByValOptimize):
3103         * runtime/JSFunction.cpp:
3104         (JSC::JSFunction::setFunctionName):
3105         * runtime/JSModuleLoader.cpp:
3106         (JSC::printableModuleKey):
3107         * runtime/JSONObject.cpp:
3108         (JSC::Stringifier::Stringifier):
3109         * runtime/Symbol.cpp:
3110         (JSC::Symbol::descriptiveString const):
3111         (JSC::Symbol::description const):
3112         * runtime/Symbol.h:
3113         * runtime/SymbolConstructor.cpp:
3114         (JSC::symbolConstructorKeyFor):
3115         * tools/JSDollarVM.cpp:
3116         (JSC::functionGetGetterSetter):
3117
3118 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
3119
3120         REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
3121         https://bugs.webkit.org/show_bug.cgi?id=195752
3122
3123         Reviewed by Saam Barati.
3124
3125         We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
3126         was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
3127         falls into wrong condition), our validation does not care AnyInt and Double representations in lower
3128         tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
3129         SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
3130         OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
3131         before entering DFG code.
3132
3133         This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
3134
3135         And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
3136         in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
3137         value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
3138         is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
3139
3140         We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
3141         AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
3142         is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
3143         and it accepts JSValues simply.
3144
3145         * bytecode/SpeculatedType.cpp:
3146         (JSC::dumpSpeculation):
3147         * dfg/DFGAbstractValue.cpp:
3148         (JSC::DFG::AbstractValue::filterValueByType):
3149         * dfg/DFGAbstractValue.h:
3150         (JSC::DFG::AbstractValue::validateOSREntryValue const):
3151         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
3152         (JSC::DFG::AbstractValue::validate const): Deleted.
3153         (JSC::DFG::AbstractValue::validateType const): Deleted.
3154         * dfg/DFGCFAPhase.cpp:
3155         (JSC::DFG::CFAPhase::run):
3156         (JSC::DFG::CFAPhase::injectOSR):
3157         (JSC::DFG::CFAPhase::performBlockCFA):
3158         * dfg/DFGOSREntry.cpp:
3159         (JSC::DFG::prepareOSREntry):
3160
3161 2019-03-14  Saam barati  <sbarati@apple.com>
3162
3163         We can't remove code after ForceOSRExit until after FixupPhase
3164         https://bugs.webkit.org/show_bug.cgi?id=186916
3165         <rdar://problem/41396612>
3166
3167         Reviewed by Yusuke Suzuki.
3168
3169         There was an optimization in the bytecode parser I added in r232742 that converted blocks
3170         with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
3171         this is incorrect because it breaks backwards propagation. For example, it
3172         could incorrectly lead us to think it's safe to not check for overflow in
3173         an Add because such Add has no non-int uses. Backwards propagation relies on
3174         having a view over bytecode uses, and this optimization broke that. This patch
3175         rolls out that optimization, as initial perf data shows it may no longer be
3176         needed.
3177
3178         * dfg/DFGByteCodeParser.cpp:
3179         (JSC::DFG::ByteCodeParser::addToGraph):
3180         (JSC::DFG::ByteCodeParser::parse):
3181
3182 2019-03-14  Saam barati  <sbarati@apple.com>
3183
3184         JSScript should have an accessor saying if it's cached or not
3185         https://bugs.webkit.org/show_bug.cgi?id=195783
3186
3187         Reviewed by Michael Saboff.
3188
3189         * API/JSScript.h:
3190         * API/JSScript.mm:
3191         (-[JSScript isUsingBytecodeCache]):
3192         * API/tests/testapi.mm:
3193         (testIsUsingBytecodeCacheAccessor):
3194         (testObjectiveCAPI):
3195
3196 2019-03-14  Saam barati  <sbarati@apple.com>
3197
3198         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
3199         https://bugs.webkit.org/show_bug.cgi?id=195782
3200         <rdar://problem/48880625>
3201
3202         Reviewed by Michael Saboff.
3203
3204         This patch fixes two issues with JSScript API:
3205         
3206         1. There was a retain cycle causing us to never destroy a JSScript once it
3207         created a JSSourceCode. The reason for this is that JSScript had a 
3208         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
3209         
3210         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
3211         
3212         2. r242585 made it so that JSScript would keep the cache file descriptor open
3213         (and locked) for the duration of the lifetime of the JSScript itself. Our
3214         anticipation here is that it would make implementing iterative cache updates
3215         easier. However, this made using the API super limiting in other ways. For
3216         example, if a program had a loop that cached 3000 different JSScripts, it's
3217         likely that such a program would exhaust the open file count limit. This patch
3218         reverts to the behavior prior to r242585 where we just keep open the file descriptor
3219         while we read or write it.
3220
3221         * API/JSAPIGlobalObject.mm:
3222         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
3223         * API/JSContext.mm:
3224         (-[JSContext evaluateJSScript:]):
3225         * API/JSScript.mm:
3226         (-[JSScript dealloc]):
3227         (-[JSScript readCache]):
3228         (-[JSScript init]):
3229         (-[JSScript sourceCode]):
3230         (-[JSScript jsSourceCode]):
3231         (-[JSScript writeCache:]):
3232         (-[JSScript forceRecreateJSSourceCode]): Deleted.
3233         * API/JSScriptInternal.h:
3234         * API/tests/testapi.mm:
3235         (testCanCacheManyFilesWithTheSameVM):
3236         (testObjectiveCAPI):
3237         (testCacheFileIsExclusive): Deleted.
3238
3239 2019-03-14  Michael Saboff  <msaboff@apple.com>
3240
3241         ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
3242         https://bugs.webkit.org/show_bug.cgi?id=195735
3243
3244         Reviewed by Mark Lam.
3245
3246         There are two bug fixes here.
3247
3248         The first bug happens due to a race condition when we are compiling on a separate thread while the
3249         main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
3250         the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
3251         compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
3252         it might compile successfully the next time we try to execute it on a shallower stack.
3253         The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
3254         or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.
3255
3256         The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
3257         The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
3258         is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
3259         Changing hasCode() to take this into account fixes the second issue.
3260
3261         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
3262         * runtime/RegExp.h:
3263         * dfg/DFGSpeculativeJIT.cpp:
3264         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
3265         * runtime/RegExp.h:
3266
3267 2019-03-14  Saam barati  <sbarati@apple.com>
3268
3269         Fixup uses KnownInt32 incorrectly in some nodes
3270         https://bugs.webkit.org/show_bug.cgi?id=195279
3271         <rdar://problem/47915654>
3272
3273         Reviewed by Yusuke Suzuki.
3274
3275         Fixup was sometimes using KnownInt32 edges when it knew some
3276         incoming value is an Int32 based on what the bytecode would return.
3277         However, because bytecode may result in Int32 for some node does
3278         not mean we'll pick Int32 as the value format for that local. For example,
3279         we may choose for a value to be represented as a double. This patch
3280         corrects such uses of KnownInt32.
3281
3282         * dfg/DFGArgumentsEliminationPhase.cpp:
3283         * dfg/DFGFixupPhase.cpp:
3284         (JSC::DFG::FixupPhase::fixupNode):
3285         * dfg/DFGSpeculativeJIT.cpp:
3286         (JSC::DFG::SpeculativeJIT::compileArrayPush):
3287         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
3288         * ftl/FTLLowerDFGToB3.cpp:
3289         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
3290
3291 2019-03-14  Keith Miller  <keith_miller@apple.com>
3292
3293         DFG liveness can't skip tail caller inline frames
3294         https://bugs.webkit.org/show_bug.cgi?id=195715
3295         <rdar://problem/46221598>
3296
3297         Reviewed by Saam Barati.
3298
3299         In order to simplify OSR exit/DFG bytecode parsing our bytecode
3300         generator always emits an op_ret after any tail call. However, the
3301         DFG when computing the liveness of locals, would skip any tail
3302         caller inline frames. This mean that if we ended up inserting a
3303         Check that would OSR to the op_ret we wouldn't have kept
3304         availability data around for it.
3305
3306         * dfg/DFGGraph.cpp:
3307         (JSC::DFG::Graph::isLiveInBytecode):
3308         * dfg/DFGGraph.h:
3309         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
3310
3311 2019-03-14  Robin Morisset  <rmorisset@apple.com>
3312
3313         DFG::Worklist can be shrunk by 16 bytes
3314         https://bugs.webkit.org/show_bug.cgi?id=195490
3315
3316         Reviewed by Darin Adler.
3317
3318         * dfg/DFGWorklist.cpp:
3319         (JSC::DFG::Worklist::Worklist):
3320         * dfg/DFGWorklist.h:
3321
3322 2019-03-14  Devin Rousso  <drousso@apple.com>
3323
3324         Web Inspector: Audit: provide a way to get the contents of resources
3325         https://bugs.webkit.org/show_bug.cgi?id=195266
3326         <rdar://problem/48550911>
3327
3328         Reviewed by Joseph Pecoraro.
3329
3330         * inspector/InjectedScriptBase.cpp:
3331         (Inspector::InjectedScriptBase::makeAsyncCall):
3332         Drive-by: fix missing `else`.