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