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