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