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