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