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