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