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