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