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