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