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