typeOfDoubleSum is wrong for when NaN can be produced
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2019-03-20  Saam Barati  <sbarati@apple.com>
2
3         typeOfDoubleSum is wrong for when NaN can be produced
4         https://bugs.webkit.org/show_bug.cgi?id=196030
5
6         Reviewed by Filip Pizlo.
7
8         We were using typeOfDoubleSum(SpeculatedType, SpeculatedType) for add/sub/mul.
9         It assumed that the only way the resulting type could be NaN is if one of
10         the inputs were NaN. However, this is wrong. NaN can be produced in at least
11         these cases:
12           Infinity - Infinity
13           Infinity + (-Infinity)
14           Infinity * 0
15
16         * bytecode/SpeculatedType.cpp:
17         (JSC::typeOfDoubleSumOrDifferenceOrProduct):
18         (JSC::typeOfDoubleSum):
19         (JSC::typeOfDoubleDifference):
20         (JSC::typeOfDoubleProduct):
21
22 2019-03-20  Simon Fraser  <simon.fraser@apple.com>
23
24         Rename ENABLE_ACCELERATED_OVERFLOW_SCROLLING macro to ENABLE_OVERFLOW_SCROLLING_TOUCH
25         https://bugs.webkit.org/show_bug.cgi?id=196049
26
27         Reviewed by Tim Horton.
28
29         This macro is about the -webkit-overflow-scrolling CSS property, not accelerated
30         overflow scrolling in general, so rename it.
31
32         * Configurations/FeatureDefines.xcconfig:
33
34 2019-03-20  Saam Barati  <sbarati@apple.com>
35
36         GetCallee does not report the correct type in AI
37         https://bugs.webkit.org/show_bug.cgi?id=195981
38
39         Reviewed by Yusuke Suzuki.
40
41         I found this as part of my work in:
42         https://bugs.webkit.org/show_bug.cgi?id=195924
43         
44         I'm not sure how to write a test for it.
45         
46         GetCallee was always reporting that the result is SpecFunction. However,
47         for eval, it may result in just a JSCallee object, which is not a JSFunction.
48
49         * dfg/DFGAbstractInterpreterInlines.h:
50         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
51
52 2019-03-20  Mark Lam  <mark.lam@apple.com>
53
54         Open source arm64e code.
55         https://bugs.webkit.org/show_bug.cgi?id=196012
56         <rdar://problem/49066237>
57
58         Reviewed by Keith Miller.
59
60         * JavaScriptCore.xcodeproj/project.pbxproj:
61         * Sources.txt:
62         * assembler/ARM64EAssembler.h: Added.
63         (JSC::ARM64EAssembler::encodeGroup1):
64         (JSC::ARM64EAssembler::encodeGroup2):
65         (JSC::ARM64EAssembler::encodeGroup4):
66         (JSC::ARM64EAssembler::pacia1716):
67         (JSC::ARM64EAssembler::pacib1716):
68         (JSC::ARM64EAssembler::autia1716):
69         (JSC::ARM64EAssembler::autib1716):
70         (JSC::ARM64EAssembler::paciaz):
71         (JSC::ARM64EAssembler::paciasp):
72         (JSC::ARM64EAssembler::pacibz):
73         (JSC::ARM64EAssembler::pacibsp):
74         (JSC::ARM64EAssembler::autiaz):
75         (JSC::ARM64EAssembler::autiasp):
76         (JSC::ARM64EAssembler::autibz):
77         (JSC::ARM64EAssembler::autibsp):
78         (JSC::ARM64EAssembler::xpaclri):
79         (JSC::ARM64EAssembler::pacia):
80         (JSC::ARM64EAssembler::pacib):
81         (JSC::ARM64EAssembler::pacda):
82         (JSC::ARM64EAssembler::pacdb):
83         (JSC::ARM64EAssembler::autia):
84         (JSC::ARM64EAssembler::autib):
85         (JSC::ARM64EAssembler::autda):
86         (JSC::ARM64EAssembler::autdb):
87         (JSC::ARM64EAssembler::paciza):
88         (JSC::ARM64EAssembler::pacizb):
89         (JSC::ARM64EAssembler::pacdza):
90         (JSC::ARM64EAssembler::pacdzb):
91         (JSC::ARM64EAssembler::autiza):
92         (JSC::ARM64EAssembler::autizb):
93         (JSC::ARM64EAssembler::autdza):
94         (JSC::ARM64EAssembler::autdzb):
95         (JSC::ARM64EAssembler::xpaci):
96         (JSC::ARM64EAssembler::xpacd):
97         (JSC::ARM64EAssembler::pacga):
98         (JSC::ARM64EAssembler::braa):
99         (JSC::ARM64EAssembler::brab):
100         (JSC::ARM64EAssembler::blraa):
101         (JSC::ARM64EAssembler::blrab):
102         (JSC::ARM64EAssembler::braaz):
103         (JSC::ARM64EAssembler::brabz):
104         (JSC::ARM64EAssembler::blraaz):
105         (JSC::ARM64EAssembler::blrabz):
106         (JSC::ARM64EAssembler::retaa):
107         (JSC::ARM64EAssembler::retab):
108         (JSC::ARM64EAssembler::eretaa):
109         (JSC::ARM64EAssembler::eretab):
110         (JSC::ARM64EAssembler::linkPointer):
111         (JSC::ARM64EAssembler::repatchPointer):
112         (JSC::ARM64EAssembler::setPointer):
113         (JSC::ARM64EAssembler::readPointer):
114         (JSC::ARM64EAssembler::readCallTarget):
115         (JSC::ARM64EAssembler::ret):
116         * assembler/MacroAssembler.cpp:
117         * assembler/MacroAssembler.h:
118         * assembler/MacroAssemblerARM64.cpp:
119         * assembler/MacroAssemblerARM64E.h: Added.
120         (JSC::MacroAssemblerARM64E::tagReturnAddress):
121         (JSC::MacroAssemblerARM64E::untagReturnAddress):
122         (JSC::MacroAssemblerARM64E::tagPtr):
123         (JSC::MacroAssemblerARM64E::untagPtr):
124         (JSC::MacroAssemblerARM64E::removePtrTag):
125         (JSC::MacroAssemblerARM64E::callTrustedPtr):
126         (JSC::MacroAssemblerARM64E::call):
127         (JSC::MacroAssemblerARM64E::callRegister):
128         (JSC::MacroAssemblerARM64E::jump):
129         * dfg/DFGOSRExit.cpp:
130         (JSC::DFG::reifyInlinedCallFrames):
131         * dfg/DFGOSRExitCompilerCommon.cpp:
132         (JSC::DFG::reifyInlinedCallFrames):
133         * ftl/FTLThunks.cpp:
134         (JSC::FTL::genericGenerationThunkGenerator):
135         * jit/CCallHelpers.h:
136         (JSC::CCallHelpers::prepareForTailCallSlow):
137         * jit/CallFrameShuffler.cpp:
138         (JSC::CallFrameShuffler::prepareForTailCall):
139         * jit/ExecutableAllocator.cpp:
140         (JSC::ExecutableAllocator::allocate):
141         * jit/ThunkGenerators.cpp:
142         (JSC::arityFixupGenerator):
143         * llint/LLIntOfflineAsmConfig.h:
144         * llint/LowLevelInterpreter.asm:
145         * llint/LowLevelInterpreter64.asm:
146         * runtime/ClassInfo.h:
147         * runtime/InitializeThreading.cpp:
148         (JSC::initializeThreading):
149         * runtime/JSCPtrTag.cpp: Added.
150         (JSC::tagForPtr):
151         (JSC::ptrTagName):
152         (JSC::initializePtrTagLookup):
153         * runtime/JSCPtrTag.h:
154         (JSC::initializePtrTagLookup):
155         * runtime/Options.cpp:
156         (JSC::recomputeDependentOptions):
157
158 2019-03-20  Tadeu Zagallo  <tzagallo@apple.com>
159
160         JSC::createError needs to check for OOM in errorDescriptionForValue
161         https://bugs.webkit.org/show_bug.cgi?id=196032
162         <rdar://problem/46842740>
163
164         Reviewed by Mark Lam.
165
166         We were missing exceptions checks at two levels:
167         - In errorDescriptionForValue, when the value is a string, we should
168           check that JSString::value returns a valid string, since we might run
169           out of memory if it is a rope and we need to resolve it.
170         - In createError, we should check for the result of errorDescriptionForValue
171           before concatenating it with the message provided by the caller.
172
173         * runtime/ExceptionHelpers.cpp:
174         (JSC::errorDescriptionForValue):
175         (JSC::createError):
176         * runtime/ExceptionHelpers.h:
177
178 2019-03-20  Devin Rousso  <drousso@apple.com>
179
180         Web Inspector: DOM: include window as part of any event listener chain
181         https://bugs.webkit.org/show_bug.cgi?id=195730
182         <rdar://problem/48916872>
183
184         Reviewed by Timothy Hatcher.
185
186         * inspector/protocol/DOM.json:
187         Modify `DOM.getEventListenersForNode` to not save the handler object, as that was never
188         used by the frontend. Add an `onWindow` optional property to `DOM.EventListener` that is set
189         when the event listener was retrieved from the `window` object.
190
191 2019-03-20  Devin Rousso  <drousso@apple.com>
192
193         Web Inspector: Runtime: lazily create the agent
194         https://bugs.webkit.org/show_bug.cgi?id=195972
195         <rdar://problem/49039655>
196
197         Reviewed by Timothy Hatcher.
198
199         * inspector/JSGlobalObjectInspectorController.cpp:
200         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
201         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
202
203         * inspector/agents/InspectorRuntimeAgent.h:
204         (Inspector::InspectorRuntimeAgent::enabled): Deleted.
205         * inspector/agents/InspectorRuntimeAgent.cpp:
206         (Inspector::InspectorRuntimeAgent::didCreateFrontendAndBackend): Added.
207         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
208
209         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
210         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
211         (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): Deleted.
212
213 2019-03-20  Michael Saboff  <msaboff@apple.com>
214
215         JSC test crash: stress/dont-strength-reduce-regexp-with-compile-error.js.default
216         https://bugs.webkit.org/show_bug.cgi?id=195906
217
218         Reviewed by Mark Lam.
219
220         The problem here as that we may successfully parsed a RegExp without running out of stack,
221         but later run out of stack when trying to JIT compile the same expression.
222
223         Added a check for available stack space when we call into one of the parenthesis compilation
224         functions that recurse.  When we don't have enough stack space to recurse, we fail the JIT
225         compilation and let the interpreter handle the expression.
226
227         From code inspection of the YARR interpreter it has the same issue, but I couldn't cause a failure.
228         Filed a new bug and added a FIXME comment for the Interpreter to have similar checks.
229         Given that we can reproduce a failure, this is sufficient for now.
230
231         This change is covered by the previously added failing test,
232         JSTests/stress/dont-strength-reduce-regexp-with-compile-error.js.
233
234         * yarr/YarrInterpreter.cpp:
235         (JSC::Yarr::Interpreter::interpret):
236         * yarr/YarrJIT.cpp:
237         (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
238         (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
239         (JSC::Yarr::YarrGenerator::opCompileBody):
240         (JSC::Yarr::dumpCompileFailure):
241         * yarr/YarrJIT.h:
242
243 2019-03-20  Robin Morisset  <rmorisset@apple.com>
244
245         DFGNodeAllocator.h is dead code
246         https://bugs.webkit.org/show_bug.cgi?id=196019
247
248         Reviewed by Yusuke Suzuki.
249
250         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.
251         This patch removes both the comment and DFGNodeAllocator.h that that patch forgot to remove.
252
253         * dfg/DFGNode.h:
254         (JSC::DFG::Node::dumpChildren):
255         * dfg/DFGNodeAllocator.h: Removed.
256
257 2019-03-20  Robin Morisset  <rmorisset@apple.com>
258
259         Compress CodeOrigin into a single word in the common case
260         https://bugs.webkit.org/show_bug.cgi?id=195928
261
262         Reviewed by Saam Barati.
263
264         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.
265         So we can shove the bytecode index in the top bits almost all the time.
266         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.
267         Finally we represent an invalid bytecodeIndex (which used to be represented by UINT_MAX) by setting the second least signifcant bit.
268
269         The patch looks very long, but most of it is just replacing direct accesses to inlineCallFrame and bytecodeIndex by the relevant getters.
270
271         End result: CodeOrigin in the common case moves from 16 bytes (8 for InlineCallFrame*, 4 for unsigned bytecodeIndex, 4 of padding) to 8.
272         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
273         improvement to RAMification from this work.
274
275         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.
276
277         * bytecode/ByValInfo.h:
278         * bytecode/CallLinkStatus.cpp:
279         (JSC::CallLinkStatus::computeFor):
280         * bytecode/CodeBlock.cpp:
281         (JSC::CodeBlock::globalObjectFor):
282         (JSC::CodeBlock::updateOSRExitCounterAndCheckIfNeedToReoptimize):
283         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
284         * bytecode/CodeOrigin.cpp:
285         (JSC::CodeOrigin::inlineDepth const):
286         (JSC::CodeOrigin::isApproximatelyEqualTo const):
287         (JSC::CodeOrigin::approximateHash const):
288         (JSC::CodeOrigin::inlineStack const):
289         (JSC::CodeOrigin::codeOriginOwner const):
290         (JSC::CodeOrigin::stackOffset const):
291         (JSC::CodeOrigin::dump const):
292         (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
293         * bytecode/CodeOrigin.h:
294         (JSC::OutOfLineCodeOrigin::OutOfLineCodeOrigin):
295         (JSC::CodeOrigin::CodeOrigin):
296         (JSC::CodeOrigin::~CodeOrigin):
297         (JSC::CodeOrigin::isSet const):
298         (JSC::CodeOrigin::isHashTableDeletedValue const):
299         (JSC::CodeOrigin::bytecodeIndex const):
300         (JSC::CodeOrigin::inlineCallFrame const):
301         (JSC::CodeOrigin::buildCompositeValue):
302         (JSC::CodeOrigin::hash const):
303         (JSC::CodeOrigin::operator== const):
304         (JSC::CodeOrigin::exitingInlineKind const): Deleted.
305         * bytecode/DeferredSourceDump.h:
306         * bytecode/GetByIdStatus.cpp:
307         (JSC::GetByIdStatus::computeForStubInfo):
308         (JSC::GetByIdStatus::computeFor):
309         * bytecode/ICStatusMap.cpp:
310         (JSC::ICStatusContext::isInlined const):
311         * bytecode/InByIdStatus.cpp:
312         (JSC::InByIdStatus::computeFor):
313         (JSC::InByIdStatus::computeForStubInfo):
314         * bytecode/InlineCallFrame.cpp:
315         (JSC::InlineCallFrame::dumpInContext const):
316         * bytecode/InlineCallFrame.h:
317         (JSC::InlineCallFrame::computeCallerSkippingTailCalls):
318         (JSC::InlineCallFrame::getCallerInlineFrameSkippingTailCalls):
319         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
320         (JSC::CodeOrigin::walkUpInlineStack):
321         * bytecode/InstanceOfStatus.h:
322         * bytecode/PutByIdStatus.cpp:
323         (JSC::PutByIdStatus::computeForStubInfo):
324         (JSC::PutByIdStatus::computeFor):
325         * dfg/DFGAbstractInterpreterInlines.h:
326         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
327         * dfg/DFGArgumentsEliminationPhase.cpp:
328         * dfg/DFGArgumentsUtilities.cpp:
329         (JSC::DFG::argumentsInvolveStackSlot):
330         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
331         * dfg/DFGArrayMode.h:
332         * dfg/DFGByteCodeParser.cpp:
333         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
334         (JSC::DFG::ByteCodeParser::setLocal):
335         (JSC::DFG::ByteCodeParser::setArgument):
336         (JSC::DFG::ByteCodeParser::flushForTerminalImpl):
337         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
338         (JSC::DFG::ByteCodeParser::parseBlock):
339         (JSC::DFG::ByteCodeParser::parseCodeBlock):
340         (JSC::DFG::ByteCodeParser::handlePutByVal):
341         * dfg/DFGClobberize.h:
342         (JSC::DFG::clobberize):
343         * dfg/DFGConstantFoldingPhase.cpp:
344         (JSC::DFG::ConstantFoldingPhase::foldConstants):
345         * dfg/DFGFixupPhase.cpp:
346         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
347         * dfg/DFGForAllKills.h:
348         (JSC::DFG::forAllKilledOperands):
349         * dfg/DFGGraph.cpp:
350         (JSC::DFG::Graph::dumpCodeOrigin):
351         (JSC::DFG::Graph::dump):
352         (JSC::DFG::Graph::isLiveInBytecode):
353         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
354         (JSC::DFG::Graph::willCatchExceptionInMachineFrame):
355         * dfg/DFGGraph.h:
356         (JSC::DFG::Graph::executableFor):
357         (JSC::DFG::Graph::isStrictModeFor):
358         (JSC::DFG::Graph::hasExitSite):
359         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
360         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
361         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
362         * dfg/DFGMinifiedNode.cpp:
363         (JSC::DFG::MinifiedNode::fromNode):
364         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
365         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
366         * dfg/DFGOSRExit.cpp:
367         (JSC::DFG::OSRExit::executeOSRExit):
368         (JSC::DFG::reifyInlinedCallFrames):
369         (JSC::DFG::adjustAndJumpToTarget):
370         (JSC::DFG::printOSRExit):
371         (JSC::DFG::OSRExit::compileExit):
372         * dfg/DFGOSRExitBase.cpp:
373         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
374         * dfg/DFGOSRExitCompilerCommon.cpp:
375         (JSC::DFG::handleExitCounts):
376         (JSC::DFG::reifyInlinedCallFrames):
377         (JSC::DFG::adjustAndJumpToTarget):
378         * dfg/DFGOSRExitPreparation.cpp:
379         (JSC::DFG::prepareCodeOriginForOSRExit):
380         * dfg/DFGObjectAllocationSinkingPhase.cpp:
381         * dfg/DFGOperations.cpp:
382         * dfg/DFGPreciseLocalClobberize.h:
383         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
384         * dfg/DFGSpeculativeJIT.cpp:
385         (JSC::DFG::SpeculativeJIT::emitGetLength):
386         (JSC::DFG::SpeculativeJIT::emitGetCallee):
387         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
388         (JSC::DFG::SpeculativeJIT::compileValueAdd):
389         (JSC::DFG::SpeculativeJIT::compileValueSub):
390         (JSC::DFG::SpeculativeJIT::compileValueNegate):
391         (JSC::DFG::SpeculativeJIT::compileValueMul):
392         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
393         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
394         * dfg/DFGSpeculativeJIT32_64.cpp:
395         (JSC::DFG::SpeculativeJIT::emitCall):
396         * dfg/DFGSpeculativeJIT64.cpp:
397         (JSC::DFG::SpeculativeJIT::emitCall):
398         (JSC::DFG::SpeculativeJIT::compile):
399         * dfg/DFGTierUpCheckInjectionPhase.cpp:
400         (JSC::DFG::TierUpCheckInjectionPhase::run):
401         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
402         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
403         * dfg/DFGTypeCheckHoistingPhase.cpp:
404         (JSC::DFG::TypeCheckHoistingPhase::run):
405         * dfg/DFGVariableEventStream.cpp:
406         (JSC::DFG::VariableEventStream::reconstruct const):
407         * ftl/FTLLowerDFGToB3.cpp:
408         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
409         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
410         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
411         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
412         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
413         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
414         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
415         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
416         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
417         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
418         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
419         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
420         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
421         (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
422         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
423         (JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
424         * ftl/FTLOSRExitCompiler.cpp:
425         (JSC::FTL::compileStub):
426         * ftl/FTLOperations.cpp:
427         (JSC::FTL::operationMaterializeObjectInOSR):
428         * interpreter/CallFrame.cpp:
429         (JSC::CallFrame::bytecodeOffset):
430         * interpreter/StackVisitor.cpp:
431         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
432         (JSC::StackVisitor::readFrame):
433         (JSC::StackVisitor::readNonInlinedFrame):
434         (JSC::inlinedFrameOffset):
435         (JSC::StackVisitor::readInlinedFrame):
436         * interpreter/StackVisitor.h:
437         * jit/AssemblyHelpers.cpp:
438         (JSC::AssemblyHelpers::executableFor):
439         * jit/AssemblyHelpers.h:
440         (JSC::AssemblyHelpers::isStrictModeFor):
441         (JSC::AssemblyHelpers::argumentsStart):
442         (JSC::AssemblyHelpers::argumentCount):
443         * jit/PCToCodeOriginMap.cpp:
444         (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
445         (JSC::PCToCodeOriginMap::findPC const):
446         * profiler/ProfilerOriginStack.cpp:
447         (JSC::Profiler::OriginStack::OriginStack):
448         * profiler/ProfilerOriginStack.h:
449         * runtime/ErrorInstance.cpp:
450         (JSC::appendSourceToError):
451         * runtime/SamplingProfiler.cpp:
452         (JSC::SamplingProfiler::processUnverifiedStackTraces):
453
454 2019-03-20  Devin Rousso  <drousso@apple.com>
455
456         Web Inspector: Search: allow DOM searches to be case sensitive
457         https://bugs.webkit.org/show_bug.cgi?id=194673
458         <rdar://problem/48087577>
459
460         Reviewed by Timothy Hatcher.
461
462         Since `DOM.performSearch` also searches by selector and XPath, some results may appear
463         as unexpected. As an example, searching for "BoDy" will still return the <body> as a result,
464         as although the literal node name ("BODY") didn't match, it did match via selector/XPath.
465
466         * inspector/protocol/DOM.json:
467         Allow `DOM.performSearch` to be case sensitive.
468
469 2019-03-20  Saam Barati  <sbarati@apple.com>
470
471         AI rule for ValueBitNot/ValueBitXor/ValueBitAnd/ValueBitOr is wrong
472         https://bugs.webkit.org/show_bug.cgi?id=195980
473
474         Reviewed by Yusuke Suzuki.
475
476         They were all saying they could be type: (SpecBoolInt32, SpecBigInt)
477         However, they should have been type: (SpecInt32Only, SpecBigInt)
478
479         * dfg/DFGAbstractInterpreterInlines.h:
480         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
481
482 2019-03-20  Michael Catanzaro  <mcatanzaro@igalia.com>
483
484         Remove copyRef() calls added in r243163
485         https://bugs.webkit.org/show_bug.cgi?id=195962
486
487         Reviewed by Chris Dumez.
488
489         As best I can tell, may be a GCC 9 bug. It shouldn't warn about this case because the return
490         value is noncopyable and the WTFMove() is absolutely required. We can avoid the warning
491         without refcount churn by introducing an intermediate variable.
492
493         * inspector/scripts/codegen/cpp_generator_templates.py:
494
495 2019-03-20  Carlos Garcia Campos  <cgarcia@igalia.com>
496
497         [GLIB] Optimize jsc_value_object_define_property_data|accessor
498         https://bugs.webkit.org/show_bug.cgi?id=195679
499
500         Reviewed by Saam Barati.
501
502         Use direct C++ call instead of using the JSC GLib API to create the descriptor object and invoke Object.defineProperty().
503
504         * API/glib/JSCValue.cpp:
505         (jsc_value_object_define_property_data):
506         (jsc_value_object_define_property_accessor):
507
508 2019-03-19  Devin Rousso  <drousso@apple.com>
509
510         Web Inspector: Debugger: lazily create the agent
511         https://bugs.webkit.org/show_bug.cgi?id=195973
512         <rdar://problem/49039674>
513
514         Reviewed by Joseph Pecoraro.
515
516         * inspector/JSGlobalObjectInspectorController.cpp:
517         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
518         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
519         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
520
521         * inspector/JSGlobalObjectConsoleClient.h:
522         (Inspector::JSGlobalObjectConsoleClient::setInspectorDebuggerAgent): Added.
523         * inspector/JSGlobalObjectConsoleClient.cpp:
524         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
525         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
526         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
527
528         * inspector/agents/InspectorDebuggerAgent.h:
529         (Inspector::InspectorDebuggerAgent::addListener): Added.
530         (Inspector::InspectorDebuggerAgent::removeListener): Added.
531         (Inspector::InspectorDebuggerAgent::setListener): Deleted.
532         * inspector/agents/InspectorDebuggerAgent.cpp:
533         (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
534         (Inspector::InspectorDebuggerAgent::enable):
535         (Inspector::InspectorDebuggerAgent::disable):
536         (Inspector::InspectorDebuggerAgent::getScriptSource):
537         (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
538         (Inspector::InspectorDebuggerAgent::didPause):
539         (Inspector::InspectorDebuggerAgent::breakProgram):
540         (Inspector::InspectorDebuggerAgent::clearBreakDetails):
541         Drive-by: reorder some member variables for better sizing.
542         Drive-by: rename some member variables for clarity.
543
544 2019-03-19  Saam barati  <sbarati@apple.com>
545
546         Prune code after ForceOSRExit
547         https://bugs.webkit.org/show_bug.cgi?id=195913
548
549         Reviewed by Keith Miller.
550
551         I removed our original implementation of this in r242989 because
552         it was not sound. It broke backwards propagation because it removed
553         uses of a node that backwards propagation relied on to be sound.
554         Essentially, backwards propagation relies on being able to see uses
555         that would exist in bytecode to be sound.
556         
557         The rollout in r242989 was a 1% Speedometer2 regression. This patch
558         rolls back in the optimization in a sound way.
559         
560         This patch augments the code we had prior to r242989 to be sound. In
561         addition to preserving liveness, we now also convert all uses after
562         the ForceOSRExit to be Phantom. This may pessimize the optimizations
563         we do in backwards propagation, but it will prevent that phase from
564         making unsound optimizations.
565
566         * dfg/DFGByteCodeParser.cpp:
567         (JSC::DFG::ByteCodeParser::addToGraph):
568         (JSC::DFG::ByteCodeParser::parse):
569
570 2019-03-19  Michael Catanzaro  <mcatanzaro@igalia.com>
571
572         Build cleanly with GCC 9
573         https://bugs.webkit.org/show_bug.cgi?id=195920
574
575         Reviewed by Chris Dumez.
576
577         WebKit triggers three new GCC 9 warnings:
578
579         """
580         -Wdeprecated-copy, implied by -Wextra, warns about the C++11 deprecation of implicitly
581         declared copy constructor and assignment operator if one of them is user-provided.
582         """
583
584         Solution is to either add a copy constructor or copy assignment operator, if required, or
585         else remove one if it is redundant.
586
587         """
588         -Wredundant-move, implied by -Wextra, warns about redundant calls to std::move.
589         -Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision.
590         """
591
592         These account for most of this patch. Solution is to just remove the bad WTFMove().
593
594         Additionally, -Wclass-memaccess has been enhanced to catch a few cases that GCC 8 didn't.
595         These are solved by casting nontrivial types to void* before using memcpy. (Of course, it
596         would be safer to not use memcpy on nontrivial types, but that's too complex for this
597         patch. Searching for memcpy used with static_cast<void*> will reveal other cases to fix.)
598
599         * b3/B3ValueRep.h:
600         * bindings/ScriptValue.cpp:
601         (Inspector::jsToInspectorValue):
602         * bytecode/GetterSetterAccessCase.cpp:
603         (JSC::GetterSetterAccessCase::create):
604         (JSC::GetterSetterAccessCase::clone const):
605         * bytecode/InstanceOfAccessCase.cpp:
606         (JSC::InstanceOfAccessCase::clone const):
607         * bytecode/IntrinsicGetterAccessCase.cpp:
608         (JSC::IntrinsicGetterAccessCase::clone const):
609         * bytecode/ModuleNamespaceAccessCase.cpp:
610         (JSC::ModuleNamespaceAccessCase::clone const):
611         * bytecode/ProxyableAccessCase.cpp:
612         (JSC::ProxyableAccessCase::clone const):
613         * bytecode/StructureSet.h:
614         * debugger/Breakpoint.h:
615         * dfg/DFGRegisteredStructureSet.h:
616         * inspector/agents/InspectorDebuggerAgent.cpp:
617         (Inspector::buildDebuggerLocation):
618         * inspector/scripts/codegen/cpp_generator_templates.py:
619         * parser/UnlinkedSourceCode.h:
620         * wasm/WasmAirIRGenerator.cpp:
621         (JSC::Wasm::parseAndCompileAir):
622         * wasm/WasmB3IRGenerator.cpp:
623         (JSC::Wasm::parseAndCompile):
624         * wasm/WasmNameSectionParser.cpp:
625         (JSC::Wasm::NameSectionParser::parse):
626         * wasm/WasmStreamingParser.cpp:
627         (JSC::Wasm::StreamingParser::consume):
628
629 2019-03-19  Saam Barati  <sbarati@apple.com>
630
631         Style fix: remove C style cast in Instruction.h
632         https://bugs.webkit.org/show_bug.cgi?id=195917
633
634         Reviewed by Filip Pizlo.
635
636         * bytecode/Instruction.h:
637         (JSC::Instruction::wide const):
638
639 2019-03-19  Devin Rousso  <drousso@apple.com>
640
641         Web Inspector: Provide $event in the console when paused on an event listener
642         https://bugs.webkit.org/show_bug.cgi?id=188672
643
644         Reviewed by Timothy Hatcher.
645
646         * inspector/InjectedScript.h:
647         * inspector/InjectedScript.cpp:
648         (Inspector::InjectedScript::setEventValue): Added.
649         (Inspector::InjectedScript::clearEventValue): Added.
650
651         * inspector/InjectedScriptManager.h:
652         * inspector/InjectedScriptManager.cpp:
653         (Inspector::InjectedScriptManager::clearEventValue): Added.
654
655         * inspector/InjectedScriptSource.js:
656         (WI.InjectedScript.prototype.setEventValue): Added.
657         (WI.InjectedScript.prototype.clearEventValue): Added.
658         (BasicCommandLineAPI):
659
660 2019-03-19  Devin Rousso  <drousso@apple.com>
661
662         Web Inspector: ScriptProfiler: lazily create the agent
663         https://bugs.webkit.org/show_bug.cgi?id=195591
664         <rdar://problem/48791756>
665
666         Reviewed by Joseph Pecoraro.
667
668         * inspector/JSGlobalObjectConsoleClient.h:
669         (Inspector::JSGlobalObjectConsoleClient::setInspectorScriptProfilerAgent): Added.
670         * inspector/JSGlobalObjectConsoleClient.cpp:
671         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
672         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
673         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
674
675         * inspector/JSGlobalObjectInspectorController.cpp:
676         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
677         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
678
679 2019-03-19  Devin Rousso  <drousso@apple.com>
680
681         Web Inspector: Heap: lazily create the agent
682         https://bugs.webkit.org/show_bug.cgi?id=195590
683         <rdar://problem/48791750>
684
685         Reviewed by Joseph Pecoraro.
686
687         * inspector/agents/InspectorHeapAgent.h:
688         * inspector/agents/InspectorHeapAgent.cpp:
689         (Inspector::InspectorHeapAgent::~InspectorHeapAgent): Deleted.
690
691         * inspector/agents/InspectorConsoleAgent.h:
692         (Inspector::InspectorConsoleAgent::setInspectorHeapAgent): Added.
693         * inspector/agents/InspectorConsoleAgent.cpp:
694         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
695         (Inspector::InspectorConsoleAgent::takeHeapSnapshot):
696         (Inspector::InspectorConsoleAgent::~InspectorConsoleAgent): Deleted.
697
698         * inspector/JSGlobalObjectInspectorController.cpp:
699         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
700         (Inspector::JSGlobalObjectInspectorController::createLazyAgents):
701
702 2019-03-19  Caio Lima  <ticaiolima@gmail.com>
703
704         [JSC] LLIntEntryPoint creates same DirectJITCode for all functions
705         https://bugs.webkit.org/show_bug.cgi?id=194648
706
707         Reviewed by Keith Miller.
708
709         1. Making LLIntThunks singleton. 
710
711         Motivation: Former implementation has one LLIntThunk per type per VM.
712         However, the generated code for every kind of thunk is essentially the
713         same and we end up wasting memory (right now jitAllocationGranule = 32 bytes)
714         when we have 2 or more VM instantiated. Turn these thunks into
715         singleton will avoid such wasting.
716
717         Tradeoff: This change comes with a price, because we will keep thunks
718         allocated even when there is no VM instantiated. Considering WebCore use case,
719         the situation of having no VM instantiated is uncommon, since once a
720         VM is created through `commomVM()`, it will never be destroyed. Given
721         that, this change does not impact the overall memory comsumption of
722         WebCore/JSC. It also doesn't impact memory footprint, since thunks are
723         generated lazily (see results below).
724
725         Since we are keeping a static `MacroAssemblerCodeRef<JITThunkPtrTag>`,
726         we have the assurance that JITed code will never be deallocated,
727         given it is being pointed by `RefPtr<ExecutableMemoryHandle> m_executableMemory`.
728         To understand why we decided to make LLIntThunks singleton instead of
729         removing them, please see the comment on `llint/LLIntThunks.cpp`.
730
731         2. Making all LLIntEntrypoints singleton
732
733         Motivation: With singleton LLIntThunks, we also can have singleton
734         DirectJITCodes and NativeJITCodes for each LLIntEntrypoint type and
735         avoid multiple allocations of objects with the same content.
736
737         Tradeoff: As explained before, once we allocate an entrypoint, it
738         will be alive until the program exits. However, the gains we can
739         achieve in some use cases justifies such allocations.
740
741         As DirectJITCode and NativeJITCode are ThreadSafeRefCounted and we are using
742         `codeBlock->setJITCode(makeRef(*jitCode))`, their reference counter
743         will never be less than 1.
744
745         3. Memory usage analysis
746
747         This change reduces memory usage on stress/generate-multiple-llint-entrypoints.js
748         by 2% and is neutral on JetStream 2. Following results were generated
749         running each benchmark 6 times and using 95% Student's t distribution
750         confidence interval.
751
752         microbenchmarks/generate-multiple-llint-entrypoints.js (Changes uses less memory): 
753             Mean of memory peak on ToT: 122576896 bytes (confidence interval: 67747.2316)
754             Mean of memory peak on Changes: 119248213.33 bytes (confidence interval: 50251.2718)
755
756         JetStream2 (Neutral):
757             Mean of memory peak on ToT: 5442742272 bytes (confidence interval: 134381565.9117)
758             Mean of memory peak on Changes: 5384949760 bytes (confidence interval: 158413904.8352)
759
760         4. Performance Analysis
761
762         This change is performance neutral on JetStream 2 and Speedometer 2.
763         See results below.:
764
765         JetStream 2 (Neutral):
766             Mean of score on ToT: 139.58 (confidence interval: 2.44)
767             Mean of score on Changes: 141.46 (confidence interval: 4.24)
768
769         Speedometer run #1
770            ToT: 110 +- 2.9
771            Changes: 110 +- 1.8
772
773         Speedometer run #2
774            ToT: 110 +- 1.6
775            Changes: 108 +- 2.3
776
777         Speedometer run #3
778            ToT: 110 +- 3.0
779            Changes: 110 +- 1.4
780
781         * jit/JSInterfaceJIT.h:
782         (JSC::JSInterfaceJIT::JSInterfaceJIT):
783         * llint/LLIntEntrypoint.cpp:
784
785         Here we are changing the usage or DirectJITCode by NativeJITCode on cases
786         where there is no difference from address of calls with and without
787         ArithCheck.
788
789         (JSC::LLInt::setFunctionEntrypoint):
790         (JSC::LLInt::setEvalEntrypoint):
791         (JSC::LLInt::setProgramEntrypoint):
792         (JSC::LLInt::setModuleProgramEntrypoint):
793         (JSC::LLInt::setEntrypoint):
794         * llint/LLIntEntrypoint.h:
795         * llint/LLIntThunks.cpp:
796         (JSC::LLInt::generateThunkWithJumpTo):
797         (JSC::LLInt::functionForCallEntryThunk):
798         (JSC::LLInt::functionForConstructEntryThunk):
799         (JSC::LLInt::functionForCallArityCheckThunk):
800         (JSC::LLInt::functionForConstructArityCheckThunk):
801         (JSC::LLInt::evalEntryThunk):
802         (JSC::LLInt::programEntryThunk):
803         (JSC::LLInt::moduleProgramEntryThunk):
804         (JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
805         (JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
806         (JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
807         (JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
808         (JSC::LLInt::evalEntryThunkGenerator): Deleted.
809         (JSC::LLInt::programEntryThunkGenerator): Deleted.
810         (JSC::LLInt::moduleProgramEntryThunkGenerator): Deleted.
811         * llint/LLIntThunks.h:
812         * runtime/ScriptExecutable.cpp:
813         (JSC::setupLLInt):
814         (JSC::ScriptExecutable::prepareForExecutionImpl):
815
816 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
817
818         [JSC] Add missing exception checks revealed by newly added exception checks, follow-up after r243081
819         https://bugs.webkit.org/show_bug.cgi?id=195927
820
821         Reviewed by Mark Lam.
822
823         r243081 adds more exception checks which are previously missing, and it reveals missing exception checks in the caller.
824         This patch is a follow-up patch after r243081, adding missing exception checks more to fix debug test failures.
825
826         * runtime/RegExpConstructor.cpp:
827         (JSC::setRegExpConstructorInput):
828         (JSC::setRegExpConstructorMultiline):
829         * runtime/RegExpGlobalData.cpp:
830         (JSC::RegExpGlobalData::getBackref):
831         (JSC::RegExpGlobalData::getLastParen):
832
833 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
834
835         [JSC] Generator should not create JSLexicalEnvironment if it is not necessary
836         https://bugs.webkit.org/show_bug.cgi?id=195901
837
838         Reviewed by Saam Barati.
839
840         It is not rare that generators do not need to have any registers to be suspended and resumed.
841         Since currently we always emit op_create_lexical_environment for generator code, we sometimes
842         create empty JSLexicalEnvironment while it is not required. We can see that a lot of empty JSLexicalEnvironment
843         are allocated in RAMification's Basic test.
844
845         This patch removes this unnecessary allocation. We introduce op_create_generator_frame_environment, which is
846         a marker, similar to op_yield. And generatorification phase decides whether we should actually emit op_create_lexical_environment,
847         based on the result of the analysis in generatorification. This can remove unnecessary JSLexicalEnvironment allocations.
848
849         We run RAMification in 6 times, use average of them.
850         RAMification's Basic in JIT mode shows 1.4% improvement.
851         ToT
852             Current: 55076864.00, Peak: 55080960.00
853         Patched
854             Current: 54325930.67, Peak: 54329344.00
855
856         RAMification's Basic in non-JIT mode shows 5.0% improvement.
857         ToT
858             Current: 12485290.67, Peak: 12485290.67
859         Patched
860             Current: 11894101.33, Peak: 11894101.33
861
862         * bytecode/BytecodeGeneratorification.cpp:
863         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
864         (JSC::BytecodeGeneratorification::generatorFrameData const):
865         (JSC::BytecodeGeneratorification::run):
866         * bytecode/BytecodeList.rb:
867         * bytecode/BytecodeUseDef.h:
868         (JSC::computeUsesForBytecodeOffset):
869         (JSC::computeDefsForBytecodeOffset):
870         * bytecompiler/BytecodeGenerator.cpp:
871         (JSC::BytecodeGenerator::BytecodeGenerator):
872         * dfg/DFGCapabilities.cpp:
873         (JSC::DFG::capabilityLevel):
874         * llint/LowLevelInterpreter.asm:
875
876 2019-03-18  Robin Morisset  <rmorisset@apple.com>
877
878         Remove the inline capacity of Operands
879         https://bugs.webkit.org/show_bug.cgi?id=195898
880
881         Reviewed by Yusuke Suzuki.
882
883         Operands currently has a vector with an inline capacity of 24.
884         I tested on JetStream2, and only 4776 functions out of 12035 (that reach the DFG tier) have 24 or fewer elements in it.
885         This is a major problem, because we have 5 Operands in every DFG::BasicBlock, resulting in 2688 bytes of inline capacity per basic block.
886         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.
887         
888         So I removed the inline capacity of the vector in Operands, and here are the results:
889         Baseline Jetstream2:
890         159.741
891         159.746
892         159.989
893         Baseline RAMification on grouped and jit tests: (end/peak/score)
894         89.288/89.763/89.526
895         90.166/90.761/90.418
896         89.560/90.014/89.787
897         After optimization Jetstream2:
898         159.342
899         161.812
900         162.037
901         After optimization RAMification:
902         89.147/89.644/89.395
903         89.102.89.585/89.343
904         88.953/89.536/89.2444
905         
906         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).
907         I hope to land this, and get more accurate results from the bots.
908
909         * bytecode/Operands.h:
910
911 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
912
913         [JSC] Add --destroy-vm shell option and dumpHeapStatisticsAtVMDestruction option
914         https://bugs.webkit.org/show_bug.cgi?id=195897
915
916         Reviewed by Keith Miller.
917
918         It is useful if we have an option logging the status of all the existing MarkedBlocks and their objects at VM destruction.
919         I used this feature to find wasting memory, and successfully removed many wasted MarkedBlocks and JS cells like r243081.
920         This patch adds,
921
922         1. --destroy-vm option to JSC shell to destroy main thread JSC::VM
923         2. dumpHeapStatisticsAtVMDestruction to dump MarkedBlocks at VM destruction
924
925         While the current option name is "dumpHeapStatisticsAtVMDestruction", we just dump the status of MarkedBlocks and cells. But eventually,
926         we would like to collect heap statistics and dump them to investigate Heap status more.
927
928         This patch also removes logHeapStatisticsAtExit option since it is no longer used in JSC.
929
930         * heap/Heap.cpp:
931         (JSC::Heap::dumpHeapStatisticsAtVMDestruction):
932         (JSC::Heap::lastChanceToFinalize):
933         * heap/Heap.h:
934         * jsc.cpp:
935         (printUsageStatement):
936         (CommandLine::parseArguments):
937         (runJSC):
938         * runtime/Options.h:
939
940 2019-03-18  Yusuke Suzuki  <ysuzuki@apple.com>
941
942         [JSC] jsSubstring should resolve rope before calling JSRopeString::create
943         https://bugs.webkit.org/show_bug.cgi?id=195840
944
945         Reviewed by Geoffrey Garen.
946
947         jsSubstring always ends up resolving rope of the base string because substring JSRopeString only accepts non-rope JSString
948         as its base. Instead of resolving ropes in finishCreationSubstring, we should resolve before passing it to JSRopeString.
949         So that, we can access string data before creating JSRopeString, and we can introduce optimizations like avoiding creation
950         of single character substrings.
951
952         We can find that a lot of substrings for length = 1 are allocated in RAMification regexp tests. This patch avoids creation of these
953         strings to save memory.
954
955         This patch also strengthen error checks caused by rope resolution for base of substrings. Previously we sometimes miss this checks.
956
957         * dfg/DFGOperations.cpp:
958         * runtime/JSString.cpp:
959         (JSC::JSString::dumpToStream):
960         * runtime/JSString.h:
961         (JSC::jsSubstring):
962         (JSC::jsSubstringOfResolved):
963         (JSC::jsSingleCharacterString):
964         * runtime/RegExpCachedResult.cpp:
965         (JSC::RegExpCachedResult::lastResult): We no longer need to have length = 0 path since jsSubstring returns an empty string if length == 0.
966         (JSC::RegExpCachedResult::leftContext):
967         (JSC::RegExpCachedResult::rightContext):
968         (JSC::RegExpCachedResult::setInput):
969         * runtime/RegExpGlobalData.cpp:
970         (JSC::RegExpGlobalData::getBackref):
971         (JSC::RegExpGlobalData::getLastParen):
972         * runtime/StringObject.h:
973         (JSC::jsStringWithReuse):
974         (JSC::jsSubstring):
975         * runtime/StringPrototype.cpp:
976         (JSC::replaceUsingRegExpSearch):
977         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
978         (JSC::replaceUsingStringSearch):
979         (JSC::stringProtoFuncSlice):
980         (JSC::splitStringByOneCharacterImpl):
981         (JSC::stringProtoFuncSplitFast):
982         (JSC::stringProtoFuncSubstr):
983         (JSC::stringProtoFuncSubstring):
984         (JSC::stringProtoFuncToLowerCase):
985         (JSC::stringProtoFuncToUpperCase):
986         Some `const String& value = string->value(exec)` is dangerous if GC happens later. Changed to getting `String` instead of `const String&` here.
987
988         * runtime/StringPrototypeInlines.h:
989         (JSC::stringSlice):
990
991 2019-03-18  Mark Lam  <mark.lam@apple.com>
992
993         Missing a ThrowScope release in JSObject::toString().
994         https://bugs.webkit.org/show_bug.cgi?id=195893
995         <rdar://problem/48970986>
996
997         Reviewed by Michael Saboff.
998
999         Placate the validator with a RELEASE_AND_RETURN().
1000
1001         * runtime/JSObject.cpp:
1002         (JSC::JSObject::toString const):
1003
1004 2019-03-18  Mark Lam  <mark.lam@apple.com>
1005
1006         Structure::flattenDictionary() should clear unused property slots.
1007         https://bugs.webkit.org/show_bug.cgi?id=195871
1008         <rdar://problem/48959497>
1009
1010         Reviewed by Michael Saboff.
1011
1012         It currently attempts to do this but fails because it's actually clearing up the
1013         preCapacity region instead.  The fix is simply to account for the preCapacity
1014         when computing the start address of the property slots.
1015
1016         * runtime/Structure.cpp:
1017         (JSC::Structure::flattenDictionaryStructure):
1018
1019 2019-03-18  Robin Morisset  <rmorisset@apple.com>
1020
1021         B3 should reduce Shl(<S|Z>Shr(@x, @const), @const) to BitAnd(@x, -(1<<@const))
1022         https://bugs.webkit.org/show_bug.cgi?id=152164
1023
1024         Reviewed by Filip Pizlo.
1025
1026         Turn this: Shl(<S|Z>Shr(@x, @const), @const)
1027         Into this: BitAnd(@x, -(1<<@const))
1028
1029         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).
1030         I also modified a few adjacent tests to remove undefined behaviours.
1031
1032         * b3/B3ReduceStrength.cpp:
1033         * b3/testb3.cpp:
1034         (JSC::B3::testShlImms):
1035         (JSC::B3::testShlArgImm):
1036         (JSC::B3::testShlSShrArgImm):
1037         (JSC::B3::testShlImms32):
1038         (JSC::B3::testShlArgImm32):
1039         (JSC::B3::testShlZShrArgImm32):
1040         (JSC::B3::run):
1041
1042 2019-03-17  Robin Morisset  <rmorisset@apple.com>
1043
1044         ParserError can be shrunk by 8 bytes
1045         https://bugs.webkit.org/show_bug.cgi?id=195496
1046
1047         Reviewed by Mark Lam.
1048
1049         * parser/ParserError.h:
1050
1051 2019-03-17  Diego Pino Garcia  <dpino@igalia.com>
1052
1053         Fix WPE and GTK Debug builds after r243049
1054         https://bugs.webkit.org/show_bug.cgi?id=195860
1055
1056         Unreviewed, build fix after r243049.
1057
1058         * runtime/StringPrototype.cpp:
1059         (JSC::normalizationAffects8Bit):
1060
1061 2019-03-17  Yusuke Suzuki  <ysuzuki@apple.com>
1062
1063         REGRESSION: !vm.isInitializingObject() void* JSC::tryAllocateCellHelper<JSC::Structure> JSC::Structure::create
1064         https://bugs.webkit.org/show_bug.cgi?id=195858
1065
1066         Reviewed by Mark Lam.
1067
1068         r243011 changed WebAssembly related structures lazily-allocated. It means that this lazy allocation must not be done in the middle of
1069         the other object allocations. This patch changes the signature of wasm related objects' ::create functions to taking Structure*.
1070         This prevents us from materializing lazily-allocated structures while allocating wasm related objects, and this style is used in the
1071         other places to fix the same problem. This bug is caught by existing debug tests for wasm.
1072
1073         * runtime/JSGlobalObject.h:
1074         * wasm/js/JSWebAssemblyCompileError.cpp:
1075         (JSC::createJSWebAssemblyCompileError):
1076         * wasm/js/JSWebAssemblyInstance.cpp:
1077         (JSC::JSWebAssemblyInstance::finalizeCreation):
1078         (JSC::JSWebAssemblyInstance::create):
1079         * wasm/js/JSWebAssemblyLinkError.cpp:
1080         (JSC::createJSWebAssemblyLinkError):
1081         * wasm/js/JSWebAssemblyModule.cpp:
1082         (JSC::JSWebAssemblyModule::createStub):
1083         (JSC::JSWebAssemblyModule::finishCreation):
1084         * wasm/js/WasmToJS.cpp:
1085         (JSC::Wasm::wasmToJSException):
1086         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1087         (JSC::constructJSWebAssemblyCompileError):
1088         (JSC::callJSWebAssemblyCompileError):
1089         * wasm/js/WebAssemblyFunction.cpp:
1090         (JSC::WebAssemblyFunction::create):
1091         * wasm/js/WebAssemblyFunction.h:
1092         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1093         (JSC::constructJSWebAssemblyInstance):
1094         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
1095         (JSC::constructJSWebAssemblyLinkError):
1096         (JSC::callJSWebAssemblyLinkError):
1097         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1098         (JSC::constructJSWebAssemblyMemory):
1099         * wasm/js/WebAssemblyModuleConstructor.cpp:
1100         (JSC::WebAssemblyModuleConstructor::createModule):
1101         * wasm/js/WebAssemblyModuleRecord.cpp:
1102         (JSC::WebAssemblyModuleRecord::link):
1103         (JSC::WebAssemblyModuleRecord::evaluate):
1104         * wasm/js/WebAssemblyPrototype.cpp:
1105         (JSC::webAssemblyModuleValidateAsyncInternal):
1106         (JSC::instantiate):
1107         (JSC::compileAndInstantiate):
1108         (JSC::webAssemblyModuleInstantinateAsyncInternal):
1109         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1110         (JSC::constructJSWebAssemblyRuntimeError):
1111         (JSC::callJSWebAssemblyRuntimeError):
1112         * wasm/js/WebAssemblyTableConstructor.cpp:
1113         (JSC::constructJSWebAssemblyTable):
1114         * wasm/js/WebAssemblyToJSCallee.cpp:
1115         (JSC::WebAssemblyToJSCallee::create):
1116         * wasm/js/WebAssemblyToJSCallee.h:
1117         * wasm/js/WebAssemblyWrapperFunction.cpp:
1118         (JSC::WebAssemblyWrapperFunction::create):
1119         * wasm/js/WebAssemblyWrapperFunction.h:
1120
1121 2019-03-16  Darin Adler  <darin@apple.com>
1122
1123         Improve normalization code, including moving from unorm.h to unorm2.h
1124         https://bugs.webkit.org/show_bug.cgi?id=195330
1125
1126         Reviewed by Michael Catanzaro.
1127
1128         * runtime/JSString.h: Move StringViewWithUnderlyingString to StringView.h.
1129
1130         * runtime/StringPrototype.cpp: Include unorm2.h instead of unorm.h.
1131         (JSC::normalizer): Added. Function to create normalizer object given
1132         enumeration value indicating which is selected. Simplified because we
1133         know the function will not fail and so we don't need error handling code.
1134         (JSC::normalize): Changed this function to take a JSString* so we can
1135         optimize the case where no normalization is needed. Added an early exit
1136         if the string is stored as 8-bit and another if the string is already
1137         normalized, using unorm2_isNormalized. Changed error handling to only
1138         check cases that can actually fail in practice. Also did other small
1139         optimizations like passing VM rather than ExecState.
1140         (JSC::stringProtoFuncNormalize): Used smaller enumeration names that are
1141         identical to the names used in the API and normalization parlance rather
1142         than longer ones that expand the acronyms. Updated to pass JSString* to
1143         the normalize function, so we can optimize 8-bit and already-normalized
1144         cases, rather than callling the expensive String::upconvertedCharacters
1145         function. Use throwVMRangeError.
1146
1147 2019-03-15  Mark Lam  <mark.lam@apple.com>
1148
1149         Need to check ObjectPropertyCondition liveness before accessing it when firing watchpoints.
1150         https://bugs.webkit.org/show_bug.cgi?id=195827
1151         <rdar://problem/48845513>
1152
1153         Reviewed by Filip Pizlo.
1154
1155         m_object in ObjectPropertyCondition may no longer be live by the time the watchpoint fires.
1156
1157         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
1158         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
1159         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
1160         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
1161         * bytecode/ObjectPropertyCondition.cpp:
1162         (JSC::ObjectPropertyCondition::dumpInContext const):
1163         * bytecode/StructureStubClearingWatchpoint.cpp:
1164         (JSC::StructureStubClearingWatchpoint::fireInternal):
1165         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
1166         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
1167         * runtime/StructureRareData.cpp:
1168         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
1169
1170 2019-03-15  Yusuke Suzuki  <ysuzuki@apple.com>
1171
1172         [JSC] Make more properties lazily-allocated in JSGlobalObject, including properties only used in JIT mode
1173         https://bugs.webkit.org/show_bug.cgi?id=195816
1174
1175         Reviewed by Michael Saboff.
1176
1177         This patch makes more properties lazily-allocated in JSGlobalObject. This patch makes the following lazily-allocated.
1178
1179         1. iteratorResultObjectStructure
1180         2. WebAssembly related objects except for JSWebAssembly top-level object.
1181
1182         * CMakeLists.txt:
1183         * DerivedSources-input.xcfilelist:
1184         * DerivedSources-output.xcfilelist:
1185         * DerivedSources.make:
1186         * runtime/JSGlobalObject.cpp:
1187         (JSC::JSGlobalObject::init):
1188         (JSC::JSGlobalObject::visitChildren):
1189         * runtime/JSGlobalObject.h:
1190         (JSC::JSGlobalObject::iteratorResultObjectStructure const):
1191         (JSC::JSGlobalObject::webAssemblyModuleRecordStructure const):
1192         (JSC::JSGlobalObject::webAssemblyFunctionStructure const):
1193         (JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure const):
1194         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure const):
1195         * wasm/js/JSWebAssembly.cpp:
1196         * wasm/js/JSWebAssembly.h:
1197
1198 2019-03-15  Dominik Infuehr  <dinfuehr@igalia.com>
1199
1200         [CMake] Move test .js files into testapiScripts
1201         https://bugs.webkit.org/show_bug.cgi?id=195565
1202
1203         Reviewed by Yusuke Suzuki.
1204
1205         testapi expect .js file in the testapiScripts-directory.
1206
1207         * shell/CMakeLists.txt:
1208
1209 2019-03-15  Mark Lam  <mark.lam@apple.com>
1210
1211         Gardening: add a missing exception check after r242991.
1212         https://bugs.webkit.org/show_bug.cgi?id=195791
1213
1214         Unreviewed.
1215
1216         * tools/JSDollarVM.cpp:
1217         (JSC::functionGetGetterSetter):
1218
1219 2019-03-15  Devin Rousso  <drousso@apple.com>
1220
1221         Web Inspector: provide a way to capture a screenshot of a node from within the page
1222         https://bugs.webkit.org/show_bug.cgi?id=194279
1223         <rdar://problem/10731573>
1224
1225         Reviewed by Joseph Pecoraro.
1226
1227         Add `console.screenshot` functionality, which displays a screenshot of a given object (if
1228         able) within Web Inspector's Console tab. From there, it can be viewed and saved.
1229
1230         Currently, `console.screenshot` will
1231          - capture an image of a `Node` (if provided)
1232          - capture an image of the viewport if nothing is provided
1233
1234         * inspector/protocol/Console.json:
1235         Add `Image` enum value to `ConsoleMessage` type.
1236         * runtime/ConsoleTypes.h:
1237         * inspector/ConsoleMessage.h:
1238         * inspector/ConsoleMessage.cpp:
1239         (Inspector::messageTypeValue):
1240
1241         * runtime/ConsoleClient.h:
1242         * runtime/ConsoleObject.cpp:
1243         (JSC::ConsoleObject::finishCreation):
1244         (JSC::consoleProtoFuncScreenshot): Added.
1245
1246         * inspector/JSGlobalObjectConsoleClient.h:
1247         * inspector/JSGlobalObjectConsoleClient.cpp:
1248         (Inspector::JSGlobalObjectConsoleClient::screenshot): Added.
1249
1250 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
1251
1252         [JSC] Retain PrivateName of Symbol before passing it to operations potentially incurring GC
1253         https://bugs.webkit.org/show_bug.cgi?id=195791
1254         <rdar://problem/48806130>
1255
1256         Reviewed by Mark Lam.
1257
1258         Consider the following example:
1259
1260             void putByVal(JSObject*, PropertyName propertyName, ...);
1261
1262             putByVal(object, symbol->privateName(), ...);
1263
1264         PropertyName does not retain the passed UniquedStringImpl*. It just holds the pointer to UniquedStringImpl*.
1265         It means that since `Symbol::privateName()` returns `const PrivateName&` instead of `PrivateName`, putByVal
1266         and its caller does not retain UniquedStringImpl* held in PropertyName. The problem happens when the putByVal
1267         incurs GC, and when the `symbol` is missing in the conservative GC scan. The underlying UniquedStringImpl* of
1268         PropertyName can be accidentally destroyed in the middle of the putByVal operation. We should retain PrivateName
1269         before passing it to operations which takes it as PropertyName.
1270
1271         1. We use the code pattern like this.
1272
1273             auto propertyName = symbol->privateName();
1274             someOperation(..., propertyName);
1275
1276         This pattern is well aligned to existing `JSValue::toPropertyKey(exec)` and `JSString::toIdentifier(exec)` code patterns.
1277
1278             auto propertyName = value.toPropertyKey(exec);
1279             RETURN_IF_EXCEPTION(scope, { });
1280             someOperation(..., propertyName);
1281
1282         2. We change `Symbol::privateName()` to returning `PrivateName` instead of `const PrivateName&` to avoid
1283            potential dangerous use cases. This is OK because the code using `Symbol::privateName()` is not a critical path,
1284            and they typically need to retain PrivateName.
1285
1286         3. We audit similar functions `toPropertyKey(exec)` and `toIdentifier(exec)` for needed but missing exception checks.
1287            BTW, these functions are safe to the problem fixed in this patch since they return `Identifier` instead
1288            of `const Identifier&`.
1289
1290         Mark and Robin investigated and offered important data to understand what went wrong. And figured out the reason behind
1291         the mysterious behavior shown in the data, and now, we confirm that this is the right fix for this bug.
1292
1293         * dfg/DFGOperations.cpp:
1294         * jit/JITOperations.cpp:
1295         (JSC::tryGetByValOptimize):
1296         * runtime/JSFunction.cpp:
1297         (JSC::JSFunction::setFunctionName):
1298         * runtime/JSModuleLoader.cpp:
1299         (JSC::printableModuleKey):
1300         * runtime/JSONObject.cpp:
1301         (JSC::Stringifier::Stringifier):
1302         * runtime/Symbol.cpp:
1303         (JSC::Symbol::descriptiveString const):
1304         (JSC::Symbol::description const):
1305         * runtime/Symbol.h:
1306         * runtime/SymbolConstructor.cpp:
1307         (JSC::symbolConstructorKeyFor):
1308         * tools/JSDollarVM.cpp:
1309         (JSC::functionGetGetterSetter):
1310
1311 2019-03-14  Yusuke Suzuki  <ysuzuki@apple.com>
1312
1313         REGRESSION(r242841): Fix conservative DFG OSR entry validation to accept values which will be stored in AnyInt / Double flush formats
1314         https://bugs.webkit.org/show_bug.cgi?id=195752
1315
1316         Reviewed by Saam Barati.
1317
1318         We fixed the bug skipping AbstractValue validations when the flush format is Double or AnyInt. But it
1319         was too conservative. While validating inputs with AbstractValue is mandatory (without it, whole CFA
1320         falls into wrong condition), our validation does not care AnyInt and Double representations in lower
1321         tiers. For example, if a value is stored in Double flush format in DFG, its AbstractValue becomes
1322         SpecFullDouble. However, it does not include Int32 and OSR entry is rejected if Int32 comes for DoubleRep
1323         OSR entry value. This is wrong since we later convert these numbers into DoubleRep representation
1324         before entering DFG code.
1325
1326         This patch performs AbstractValue validation onto the correctly converted value with flush format hint.
1327
1328         And it still does not fix OSR entry failures in navier-stokes. This is because AbstractValue representation
1329         in navier-stokes's lin_solve was too strict. Then, this patch reverts r242627. Instead of removing must handle
1330         value handling in CFA, DFG OSR entry now correctly validates inputs with AbstractValues even if the flush format
1331         is Double or AnyInt. As long as DFG OSR entry validates inputs, merging must handle values as proven constants is OK.
1332
1333         We can see that # of OSR entry failures in navier-stokes.js becomes the same to the previous count. And we can see
1334         AnyInt OSR entry actually works in microbenchmarks/large-int.js. However, AnyInt effect is hard to observe because this
1335         is super rare. Since we inject type prediction based on must handle value, the flush format tends to be SpecAnyIntAsDouble
1336         and it accepts JSValues simply.
1337
1338         * bytecode/SpeculatedType.cpp:
1339         (JSC::dumpSpeculation):
1340         * dfg/DFGAbstractValue.cpp:
1341         (JSC::DFG::AbstractValue::filterValueByType):
1342         * dfg/DFGAbstractValue.h:
1343         (JSC::DFG::AbstractValue::validateOSREntryValue const):
1344         (JSC::DFG::AbstractValue::validateTypeAcceptingBoxedInt52 const):
1345         (JSC::DFG::AbstractValue::validate const): Deleted.
1346         (JSC::DFG::AbstractValue::validateType const): Deleted.
1347         * dfg/DFGCFAPhase.cpp:
1348         (JSC::DFG::CFAPhase::run):
1349         (JSC::DFG::CFAPhase::injectOSR):
1350         (JSC::DFG::CFAPhase::performBlockCFA):
1351         * dfg/DFGOSREntry.cpp:
1352         (JSC::DFG::prepareOSREntry):
1353
1354 2019-03-14  Saam barati  <sbarati@apple.com>
1355
1356         We can't remove code after ForceOSRExit until after FixupPhase
1357         https://bugs.webkit.org/show_bug.cgi?id=186916
1358         <rdar://problem/41396612>
1359
1360         Reviewed by Yusuke Suzuki.
1361
1362         There was an optimization in the bytecode parser I added in r232742 that converted blocks
1363         with ForceOSRExit in them to remove all IR after the ForceOSRExit. However,
1364         this is incorrect because it breaks backwards propagation. For example, it
1365         could incorrectly lead us to think it's safe to not check for overflow in
1366         an Add because such Add has no non-int uses. Backwards propagation relies on
1367         having a view over bytecode uses, and this optimization broke that. This patch
1368         rolls out that optimization, as initial perf data shows it may no longer be
1369         needed.
1370
1371         * dfg/DFGByteCodeParser.cpp:
1372         (JSC::DFG::ByteCodeParser::addToGraph):
1373         (JSC::DFG::ByteCodeParser::parse):
1374
1375 2019-03-14  Saam barati  <sbarati@apple.com>
1376
1377         JSScript should have an accessor saying if it's cached or not
1378         https://bugs.webkit.org/show_bug.cgi?id=195783
1379
1380         Reviewed by Michael Saboff.
1381
1382         * API/JSScript.h:
1383         * API/JSScript.mm:
1384         (-[JSScript isUsingBytecodeCache]):
1385         * API/tests/testapi.mm:
1386         (testIsUsingBytecodeCacheAccessor):
1387         (testObjectiveCAPI):
1388
1389 2019-03-14  Saam barati  <sbarati@apple.com>
1390
1391         Remove retain cycle from JSScript and also don't keep the cache file descriptor open so many JSScripts can be cached in a loop
1392         https://bugs.webkit.org/show_bug.cgi?id=195782
1393         <rdar://problem/48880625>
1394
1395         Reviewed by Michael Saboff.
1396
1397         This patch fixes two issues with JSScript API:
1398         
1399         1. There was a retain cycle causing us to never destroy a JSScript once it
1400         created a JSSourceCode. The reason for this is that JSScript had a 
1401         Strong<JSSourceCode> field. And JSSourceCode transitively had RetainPtr<JSScript>.
1402         
1403         This patch fixes this issue by making the "jsSourceCode" accessor return a transient object.
1404         
1405         2. r242585 made it so that JSScript would keep the cache file descriptor open
1406         (and locked) for the duration of the lifetime of the JSScript itself. Our
1407         anticipation here is that it would make implementing iterative cache updates
1408         easier. However, this made using the API super limiting in other ways. For
1409         example, if a program had a loop that cached 3000 different JSScripts, it's
1410         likely that such a program would exhaust the open file count limit. This patch
1411         reverts to the behavior prior to r242585 where we just keep open the file descriptor
1412         while we read or write it.
1413
1414         * API/JSAPIGlobalObject.mm:
1415         (JSC::JSAPIGlobalObject::moduleLoaderFetch):
1416         * API/JSContext.mm:
1417         (-[JSContext evaluateJSScript:]):
1418         * API/JSScript.mm:
1419         (-[JSScript dealloc]):
1420         (-[JSScript readCache]):
1421         (-[JSScript init]):
1422         (-[JSScript sourceCode]):
1423         (-[JSScript jsSourceCode]):
1424         (-[JSScript writeCache:]):
1425         (-[JSScript forceRecreateJSSourceCode]): Deleted.
1426         * API/JSScriptInternal.h:
1427         * API/tests/testapi.mm:
1428         (testCanCacheManyFilesWithTheSameVM):
1429         (testObjectiveCAPI):
1430         (testCacheFileIsExclusive): Deleted.
1431
1432 2019-03-14  Michael Saboff  <msaboff@apple.com>
1433
1434         ASSERTION FAILED: regexp->isValid() or ASSERTION FAILED: !isCompilationThread()
1435         https://bugs.webkit.org/show_bug.cgi?id=195735
1436
1437         Reviewed by Mark Lam.
1438
1439         There are two bug fixes here.
1440
1441         The first bug happens due to a race condition when we are compiling on a separate thread while the
1442         main thread is compiling the RegExp at a place where it can run out of stack.  When that happens,
1443         the RegExp becomes invalid due to the out of stack error.  If we check the ASSERT condition in the DFG
1444         compilation thread, we crash.  After the main thread throws an exception, it resets the RegExp as
1445         it might compile successfully the next time we try to execute it on a shallower stack.
1446         The main thread will see the regular expression as valid when it executes the JIT'ed code we are compiling
1447         or any slow path we call out to.  Therefore ASSERTs like this in compilation code can be eliminated.
1448
1449         The second bug is due to incorrect logic when we go to run the regexp in the Strength Reduction phase.
1450         The current check for "do we have code to run the RegExp?" only checks that the RegExp's state
1451         is != NotCompiled.  We also can't run the RegExp if there the state is ParseError.
1452         Changing hasCode() to take this into account fixes the second issue.
1453
1454         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
1455         * runtime/RegExp.h:
1456         * dfg/DFGSpeculativeJIT.cpp:
1457         (JSC::DFG::SpeculativeJIT::compileNewRegexp):
1458         * runtime/RegExp.h:
1459
1460 2019-03-14  Saam barati  <sbarati@apple.com>
1461
1462         Fixup uses KnownInt32 incorrectly in some nodes
1463         https://bugs.webkit.org/show_bug.cgi?id=195279
1464         <rdar://problem/47915654>
1465
1466         Reviewed by Yusuke Suzuki.
1467
1468         Fixup was sometimes using KnownInt32 edges when it knew some
1469         incoming value is an Int32 based on what the bytecode would return.
1470         However, because bytecode may result in Int32 for some node does
1471         not mean we'll pick Int32 as the value format for that local. For example,
1472         we may choose for a value to be represented as a double. This patch
1473         corrects such uses of KnownInt32.
1474
1475         * dfg/DFGArgumentsEliminationPhase.cpp:
1476         * dfg/DFGFixupPhase.cpp:
1477         (JSC::DFG::FixupPhase::fixupNode):
1478         * dfg/DFGSpeculativeJIT.cpp:
1479         (JSC::DFG::SpeculativeJIT::compileArrayPush):
1480         (JSC::DFG::SpeculativeJIT::compileGetDirectPname):
1481         * ftl/FTLLowerDFGToB3.cpp:
1482         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
1483
1484 2019-03-14  Keith Miller  <keith_miller@apple.com>
1485
1486         DFG liveness can't skip tail caller inline frames
1487         https://bugs.webkit.org/show_bug.cgi?id=195715
1488         <rdar://problem/46221598>
1489
1490         Reviewed by Saam Barati.
1491
1492         In order to simplify OSR exit/DFG bytecode parsing our bytecode
1493         generator always emits an op_ret after any tail call. However, the
1494         DFG when computing the liveness of locals, would skip any tail
1495         caller inline frames. This mean that if we ended up inserting a
1496         Check that would OSR to the op_ret we wouldn't have kept
1497         availability data around for it.
1498
1499         * dfg/DFGGraph.cpp:
1500         (JSC::DFG::Graph::isLiveInBytecode):
1501         * dfg/DFGGraph.h:
1502         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
1503
1504 2019-03-14  Robin Morisset  <rmorisset@apple.com>
1505
1506         DFG::Worklist can be shrunk by 16 bytes
1507         https://bugs.webkit.org/show_bug.cgi?id=195490
1508
1509         Reviewed by Darin Adler.
1510
1511         * dfg/DFGWorklist.cpp:
1512         (JSC::DFG::Worklist::Worklist):
1513         * dfg/DFGWorklist.h:
1514
1515 2019-03-14  Devin Rousso  <drousso@apple.com>
1516
1517         Web Inspector: Audit: provide a way to get the contents of resources
1518         https://bugs.webkit.org/show_bug.cgi?id=195266
1519         <rdar://problem/48550911>
1520
1521         Reviewed by Joseph Pecoraro.
1522
1523         * inspector/InjectedScriptBase.cpp:
1524         (Inspector::InjectedScriptBase::makeAsyncCall):
1525         Drive-by: fix missing `else`.
1526
1527 2019-03-14  Devin Rousso  <drousso@apple.com>
1528
1529         Web Inspector: Styles: `::-webkit-scrollbar*` rules aren't shown
1530         https://bugs.webkit.org/show_bug.cgi?id=195123
1531         <rdar://problem/48450148>
1532
1533         Reviewed by Joseph Pecoraro.
1534
1535         * inspector/protocol/CSS.json:
1536         Add `CSS.PseudoId` enum, rather than send a number, so that we have more knowledge about
1537         which pseudo type the rule corresponds to (e.g. a string is more descriptive than a number).
1538
1539 2019-03-13  Caio Lima  <ticaiolima@gmail.com>
1540
1541         [JSC] CodeBlock::visitChildren is reporting extra memory even when its JITCode is singleton
1542         https://bugs.webkit.org/show_bug.cgi?id=195638
1543
1544         Reviewed by Mark Lam.
1545
1546         This patch introduces a m_isShared flag to track whether the
1547         JITCode is shared between many CodeBlocks. This flag is used in
1548         `CodeBlock::setJITCode` and `CodeBlock::visitChildren` to avoid
1549         reporting duplicated extra memory for singleton JITCodes.
1550         With those changes, we now stop counting singleton LLIntEntrypoints
1551         as extra memory, since they are declared as static variables. This
1552         change can potentially avoid unecessary GC pressure, because
1553         extra memory is used by Heap::updateAllocationLimits() to update Heap
1554         limits.
1555         Even though it is hard to show performance difference for this change
1556         (see results below), it is important to keep extra memory usage
1557         correct. Otherwise, it can be a source of a complicated bug on
1558         GC in the future.
1559
1560         Results from last run of Speedometer 2 comparing ToT and changes. We
1561         collected those numbers running Minibrowser on a MacBook Pro 15-inch
1562         with 2,6 GHz Intel Core i7. Both versions are with JIT disabled,
1563         since these singleton JITCode are only used by this configuration:
1564
1565         Speedometer2 Run #1
1566             ToT: 58.2 +- 1.1
1567             changes: 57.9 +- 0.99
1568
1569         Speedometer2 Run #2
1570             ToT: 58.5 +- 1.7
1571             changes: 58.0 +- 1.5
1572
1573         Speedometer2 Run #2
1574             ToT: 58.5 +- 0.99
1575             changes: 57.1 +- 1.5
1576
1577         * bytecode/CodeBlock.cpp:
1578         (JSC::CodeBlock::estimatedSize):
1579         (JSC::CodeBlock::visitChildren):
1580         * bytecode/CodeBlock.h:
1581         (JSC::CodeBlock::setJITCode):
1582         * jit/JITCode.cpp:
1583         (JSC::JITCode::JITCode):
1584         (JSC::JITCodeWithCodeRef::JITCodeWithCodeRef):
1585         (JSC::DirectJITCode::DirectJITCode):
1586         (JSC::NativeJITCode::NativeJITCode):
1587         * jit/JITCode.h:
1588         (JSC::JITCode::isShared const):
1589         * llint/LLIntEntrypoint.cpp:
1590         (JSC::LLInt::setFunctionEntrypoint):
1591         (JSC::LLInt::setEvalEntrypoint):
1592         (JSC::LLInt::setProgramEntrypoint):
1593         (JSC::LLInt::setModuleProgramEntrypoint):
1594
1595 2019-03-13  Keith Rollin  <krollin@apple.com>
1596
1597         Add support for new StagedFrameworks layout
1598         https://bugs.webkit.org/show_bug.cgi?id=195543
1599
1600         Reviewed by Alexey Proskuryakov.
1601
1602         When creating the WebKit layout for out-of-band Safari/WebKit updates,
1603         use an optional path prefix when called for.
1604
1605         * Configurations/Base.xcconfig:
1606
1607 2019-03-13  Mark Lam  <mark.lam@apple.com>
1608
1609         Remove unneeded --tradeDestructorBlocks option.
1610         https://bugs.webkit.org/show_bug.cgi?id=195698
1611         <rdar://problem/39681388>
1612
1613         Reviewed by Yusuke Suzuki.
1614
1615         There's no reason why we would ever want --tradeDestructorBlocks to be false.
1616
1617         Also, there was an assertion in BlockDirectory::endMarking() for when
1618         (!Options::tradeDestructorBlocks() && needsDestruction()).  This assertion is
1619         outdated because the BlockDirectory's m_empty set used to mean the set of all
1620         blocks that have no live (as in not reachable by GC) objects and dead objects
1621         also do not require destructors to be called on them.  The current meaning of
1622         m_empty is that it is the set of all blocks that have no live objects,
1623         independent of whether they needs destructors to be called on them or not.
1624         The assertion is no longer valid for the new meaning of m_empty as m_empty may
1625         now contain destructible blocks.  This assertion is now removed as part of this
1626         patch.
1627
1628         * heap/BlockDirectory.cpp:
1629         (JSC::BlockDirectory::endMarking):
1630         * heap/LocalAllocator.cpp:
1631         (JSC::LocalAllocator::tryAllocateWithoutCollecting):
1632         * runtime/Options.h:
1633
1634 2019-03-13  Dominik Infuehr  <dinfuehr@igalia.com>
1635
1636         String overflow when using StringBuilder in JSC::createError
1637         https://bugs.webkit.org/show_bug.cgi?id=194957
1638
1639         Reviewed by Mark Lam.
1640
1641         StringBuilder in notAFunctionSourceAppender didn't check
1642         for overflows but just failed.
1643
1644         * runtime/ExceptionHelpers.cpp:
1645         (JSC::notAFunctionSourceAppender):
1646
1647 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
1648
1649         [JSC] Move species watchpoint installation from ArrayPrototype to JSGlobalObject
1650         https://bugs.webkit.org/show_bug.cgi?id=195593
1651
1652         Reviewed by Keith Miller.
1653
1654         This patch moves watchpoints installation and watchpoints themselves from ArrayPrototype to JSGlobalObject because of the following two reasons.
1655
1656         1. ArrayPrototype configures finalizer because of std::unique_ptr<> for watchpoints. If we move them from ArrayPrototype to JSGlobalObject, we do
1657            not need to set finalizer. And we can avoid unnecessary WeakBlock allocation.
1658
1659         2. This code lazily configures watchpoints instead of setting watchpoints eagerly in JSGlobalObject::init. We would like to expand this mechanism
1660            to other watchpoints which are eagerly configured in JSGlobalObject::init. Putting these code in JSGlobalObject instead of scattering them in
1661            each XXXPrototype / XXXConstructor can encourage the reuse of the code.
1662
1663         * runtime/ArrayPrototype.cpp:
1664         (JSC::ArrayPrototype::create):
1665         (JSC::speciesWatchpointIsValid):
1666         (JSC::ArrayPrototype::destroy): Deleted.
1667         (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): Deleted.
1668         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): Deleted.
1669         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): Deleted.
1670         * runtime/ArrayPrototype.h:
1671         * runtime/JSGlobalObject.cpp:
1672         (JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint): Instead of using ArrayPrototypeAdaptiveInferredPropertyWatchpoint,
1673         we use ObjectPropertyChangeAdaptiveWatchpoint. We create watchpoints after touching WatchpointSet since ObjectPropertyChangeAdaptiveWatchpoint
1674         requires WatchpointSet is IsWatched state.
1675         * runtime/JSGlobalObject.h:
1676
1677 2019-03-12  Yusuke Suzuki  <ysuzuki@apple.com>
1678
1679         [JSC] OSR entry should respect abstract values in addition to flush formats
1680         https://bugs.webkit.org/show_bug.cgi?id=195653
1681
1682         Reviewed by Mark Lam.
1683
1684         Let's consider the following graph.
1685
1686         Block #0
1687             ...
1688             27:< 2:loc13> JSConstant(JS|UseAsOther, StringIdent, Strong:String (atomic) (identifier): , StructureID: 42679, bc#10, ExitValid)
1689             ...
1690             28:< 2:loc13> ArithPow(DoubleRep:@437<Double>, Int32:@27, Double|UseAsOther, BytecodeDouble, Exits, bc#10, ExitValid)
1691             29:<!0:->     MovHint(DoubleRep:@28<Double>, MustGen, loc7, W:SideState, ClobbersExit, bc#10, ExitValid)
1692             30:< 1:->     SetLocal(DoubleRep:@28<Double>, loc7(M<Double>/FlushedDouble), machine:loc6, W:Stack(-8), bc#10, exit: bc#14, ExitValid)  predicting BytecodeDouble
1693             ...
1694             73:<!0:->     Jump(MustGen, T:#1, W:SideState, bc#71, ExitValid)
1695
1696         Block #1 (bc#71): (OSR target) pred, #0
1697             ...
1698            102:<!2:loc15> GetLocal(Check:Untyped:@400, Double|MustGen|PureInt, BytecodeDouble, loc7(M<Double>/FlushedDouble), machine:loc6, R:Stack(-8), bc#120, ExitValid)  predicting BytecodeDouble
1699             ...
1700
1701         CFA at @28 says it is invalid since there are type contradiction (Int32:@27 v.s. StringIdent). So, of course, we do not propagate #0's type information to #1 since we become invalid state.
1702         However, #1 is still reachable since it is an OSR target. Since #0 was only the predecessor of #1, loc7's type information becomes None at the head of #1.
1703         Since loc7's AbstractValue is None, @102 GetLocal emits breakpoint. It is OK as long as OSR entry fails because AbstractValue validation requires the given value is None type.
1704
1705         The issue here is that we skipped AbstractValue validation when we have FlushFormat information. Since loc7 has FlushedDouble format, DFG OSR entry code does not validate it against AbstractValue,
1706         which is None. Then, we hit the breakpoint emitted by @102.
1707
1708         This patch performs AbstractValue validation against values even if we have FlushFormat. We should correctly configure AbstractValue for OSR entry's locals too to avoid unnecessary OSR entry
1709         failures in the future but anyway validating locals with AbstractValue is correct behavior here since DFGSpeculativeJIT relies on that.
1710
1711         * dfg/DFGOSREntry.cpp:
1712         (JSC::DFG::prepareOSREntry):
1713
1714 2019-03-12  Michael Saboff  <msaboff@apple.com>
1715
1716         REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes
1717         https://bugs.webkit.org/show_bug.cgi?id=195613
1718
1719         Reviewed by Mark Lam.
1720
1721         The bug here is in Yarr JIT backreference matching code.  We are incorrectly
1722         using a checkedOffset / inputPosition correction when checking for the available
1723         length left in a string.  It is improper to do these corrections as a backreference's
1724         match length is based on what was matched in the referenced capture group and not
1725         part of the checkedOffset and inputPosition computed when we compiled the RegExp.
1726         In some cases, the resulting incorrect calculation would allow us to go past
1727         the subject string's length.  Removed these adjustments.
1728
1729         After writing tests for the first bug, found another bug where the non-greedy
1730         backreference backtracking code didn't do an "are we at the end of the input?" check.
1731         This caused an infinite loop as we'd jump from the backtracking code back to
1732         try matching one more backreference, fail and then backtrack.
1733
1734         * yarr/YarrJIT.cpp:
1735         (JSC::Yarr::YarrGenerator::generateBackReference):
1736         (JSC::Yarr::YarrGenerator::backtrackBackReference):
1737
1738 2019-03-12  Robin Morisset  <rmorisset@apple.com>
1739
1740         A lot more classes have padding that can be reduced by reordering their fields
1741         https://bugs.webkit.org/show_bug.cgi?id=195579
1742
1743         Reviewed by Mark Lam.
1744
1745         * assembler/LinkBuffer.h:
1746         * dfg/DFGArrayifySlowPathGenerator.h:
1747         (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
1748         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1749         (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
1750         (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
1751         * dfg/DFGGraph.h:
1752         * dfg/DFGNode.h:
1753         (JSC::DFG::SwitchData::SwitchData):
1754         * dfg/DFGPlan.cpp:
1755         (JSC::DFG::Plan::Plan):
1756         * dfg/DFGPlan.h:
1757         * dfg/DFGSlowPathGenerator.h:
1758         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
1759         * dfg/DFGSpeculativeJIT.cpp:
1760         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
1761         * dfg/DFGSpeculativeJIT.h:
1762         * domjit/DOMJITSignature.h:
1763         (JSC::DOMJIT::Signature::Signature):
1764         (JSC::DOMJIT::Signature::effect):
1765         (JSC::DOMJIT::Signature::argumentCount): Deleted.
1766         * heap/MarkingConstraintSolver.h:
1767         * heap/SlotVisitor.h:
1768         * jit/CallFrameShuffleData.h:
1769         * jit/JITDivGenerator.h:
1770         * jit/SpillRegistersMode.h:
1771         * parser/Nodes.h:
1772         * profiler/ProfilerOSRExit.cpp:
1773         (JSC::Profiler::OSRExit::OSRExit):
1774         * profiler/ProfilerOSRExit.h:
1775         * runtime/ArrayBufferView.h:
1776         * runtime/SamplingProfiler.cpp:
1777         (JSC::SamplingProfiler::SamplingProfiler):
1778         * runtime/SamplingProfiler.h:
1779         * runtime/TypeSet.cpp:
1780         (JSC::StructureShape::StructureShape):
1781         * runtime/TypeSet.h:
1782         * runtime/Watchdog.h:
1783
1784 2019-03-12  Mark Lam  <mark.lam@apple.com>
1785
1786         The HasIndexedProperty node does GC.
1787         https://bugs.webkit.org/show_bug.cgi?id=195559
1788         <rdar://problem/48767923>
1789
1790         Reviewed by Yusuke Suzuki.
1791
1792         HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(),
1793         which can eventually call JSString::getIndex(), which can resolve a rope.
1794
1795         * dfg/DFGDoesGC.cpp:
1796         (JSC::DFG::doesGC):
1797
1798 2019-03-12  Devin Rousso  <drousso@apple.com>
1799
1800         Web Inspector: Audit: there should be a centralized place for reusable code
1801         https://bugs.webkit.org/show_bug.cgi?id=195265
1802         <rdar://problem/47040673>
1803
1804         Reviewed by Joseph Pecoraro.
1805
1806         * inspector/protocol/Audit.json:
1807         Increment version.
1808
1809 2019-03-12  Robin Morisset  <rmorisset@apple.com>
1810
1811         blocksInPreOrder and blocksInPostOrder should reserve the right capacity for their result vector
1812         https://bugs.webkit.org/show_bug.cgi?id=195595
1813
1814         Reviewed by Saam Barati.
1815
1816         Also change BlockList from being Vector<BasicBlock*, 5> to Vector<BasicBlock*>
1817
1818         * dfg/DFGBasicBlock.h:
1819         * dfg/DFGGraph.cpp:
1820         (JSC::DFG::Graph::blocksInPreOrder):
1821         (JSC::DFG::Graph::blocksInPostOrder):
1822
1823 2019-03-11  Ross Kirsling  <ross.kirsling@sony.com>
1824
1825         Add Optional to Forward.h.
1826         https://bugs.webkit.org/show_bug.cgi?id=195586
1827
1828         Reviewed by Darin Adler.
1829
1830         * b3/B3Common.cpp:
1831         * b3/B3Common.h:
1832         * debugger/DebuggerParseData.cpp:
1833         * debugger/DebuggerParseData.h:
1834         * heap/HeapSnapshot.cpp:
1835         * heap/HeapSnapshot.h:
1836         * jit/PCToCodeOriginMap.cpp:
1837         * jit/PCToCodeOriginMap.h:
1838         * runtime/AbstractModuleRecord.cpp:
1839         * runtime/AbstractModuleRecord.h:
1840         * wasm/WasmInstance.h:
1841         * wasm/WasmModuleParser.h:
1842         * wasm/WasmSectionParser.cpp:
1843         * wasm/WasmSectionParser.h:
1844         * wasm/WasmStreamingParser.cpp:
1845         * wasm/WasmStreamingParser.h:
1846         * yarr/YarrFlags.cpp:
1847         * yarr/YarrFlags.h:
1848         * yarr/YarrUnicodeProperties.cpp:
1849         * yarr/YarrUnicodeProperties.h:
1850         Remove unnecessary includes from headers.
1851
1852 2019-03-11  Justin Fan  <justin_fan@apple.com>
1853
1854         [Web GPU] Update GPUSwapChainDescriptor, GPUSwapChain and implement GPUCanvasContext
1855         https://bugs.webkit.org/show_bug.cgi?id=194406
1856         <rdar://problem/47892466>
1857
1858         Reviewed by Myles C. Maxfield.
1859
1860         Added WebGPU to inspector context types.
1861
1862         * inspector/protocol/Canvas.json:
1863         * inspector/scripts/codegen/generator.py:
1864
1865 2019-03-11  Yusuke Suzuki  <ysuzuki@apple.com>
1866
1867         [JSC] Reduce # of structures in JSGlobalObject initialization
1868         https://bugs.webkit.org/show_bug.cgi?id=195498
1869
1870         Reviewed by Darin Adler.
1871
1872         This patch reduces # of structure allocations in JSGlobalObject initialization. Now it becomes 141, it fits in one
1873         MarkedBlock and this patch drops one MarkedBlock used for Structure previously.
1874
1875         * CMakeLists.txt:
1876         * DerivedSources-output.xcfilelist:
1877         * DerivedSources.make:
1878         * JavaScriptCore.xcodeproj/project.pbxproj:
1879         * runtime/ArrayIteratorPrototype.cpp:
1880         (JSC::ArrayIteratorPrototype::finishCreation): ArrayIteratorPrototype, MapIteratorPrototype, and StringIteratorPrototype's
1881         "next" properties are referenced by JSGlobalObject::init, and it causes reification of the lazy "next" property and structure
1882         transition anyway. So we should put it eagerly "without-transition" configuration to avoid one structure transition.
1883
1884         * runtime/ArrayPrototype.cpp:
1885         (JSC::ArrayPrototype::finishCreation): @@unscopable object's structure should be dictionary because (1) it is used as a dictionary
1886         in with-scope-resolution and (2) since with-scope-resolution is C++ runtime function anyway, non-dictionary structure does not add
1887         any performance benefit. This change saves several structures that are not useful.
1888
1889         * runtime/ClonedArguments.cpp:
1890         (JSC::ClonedArguments::createStructure): Bake CloneArguments's structure with 'without-transition' manner.
1891
1892         * runtime/JSGlobalObject.cpp:
1893         (JSC::JSGlobalObject::init): Previously we are always call resetProtoype at the end of JSGlobalObject::init. But it is not necessary
1894         since we do not change [[Prototype]] of JSGlobalObject. All we want is (1) fixupPrototypeChainWithObjectPrototype's operation and (2) setGlobalThis
1895         operation. Since setGlobalThis part is done in JSGlobalObject::finishCreation, fixupPrototypeChainWithObjectPrototype is only the thing
1896         we should do here.
1897
1898         (JSC::JSGlobalObject::fixupPrototypeChainWithObjectPrototype):
1899         (JSC::JSGlobalObject::resetPrototype): If the [[Prototype]] is the same to the current [[Prototype]], we can skip the operation.
1900
1901         * runtime/JSGlobalObject.h:
1902         * runtime/MapIteratorPrototype.cpp:
1903         (JSC::MapIteratorPrototype::finishCreation):
1904         * runtime/NullGetterFunction.h:
1905         * runtime/NullSetterFunction.h: Since structures of them are allocated per JSGlobalObject and they are per-JSGlobalObject,
1906         we can use without-transition property addition.
1907
1908         * runtime/StringIteratorPrototype.cpp:
1909         (JSC::StringIteratorPrototype::finishCreation):
1910         * runtime/VM.cpp:
1911         (JSC::VM::VM):
1912         (JSC::VM::setIteratorStructureSlow):
1913         (JSC::VM::mapIteratorStructureSlow): These structures are only used in WebCore's main thread.
1914         * runtime/VM.h:
1915         (JSC::VM::setIteratorStructure):
1916         (JSC::VM::mapIteratorStructure):
1917
1918 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
1919
1920         [JSC] BuiltinExecutables should behave like a WeakSet instead of generic WeakHandleOwner for memory footprint
1921         https://bugs.webkit.org/show_bug.cgi?id=195508
1922
1923         Reviewed by Darin Adler.
1924
1925         Weak<> is not cheap in terms of memory footprint. We allocate WeakBlock (256 bytes) for book-keeping Weak<>.
1926         Currently BuiltinExecutables has 203 Weak<> members and many WeakBlocks are actually allocated because
1927         many UnlinkedFunctionExecutables in BuiltinExecutables are allocated during JSGlobalObject initialization process.
1928
1929         This patch changes two things in BuiltinExecutables.
1930
1931         1. Previously we have m_xxxSourceCode fields too. But we do not need to keep it since we know how to produce it when it is required.
1932            We generate SourceCode in xxxSourceCode() method instead of just returning m_xxxSourceCode. This reduces sizeof(BuiltinExecutables) 24 x 203 = 4KB.
1933
1934         2. Instead of using Weak<>, BuiltinExecutables holds raw array of UnlinkedFunctionExecutable*. And Heap::finalizeUnconditionalFinalizers() correctly clears dead executables.
1935            This is similar to JSWeakSet implementation. And it saves WeakBlock allocations.
1936
1937         * builtins/BuiltinExecutables.cpp:
1938         (JSC::BuiltinExecutables::BuiltinExecutables):
1939         (JSC::BuiltinExecutables::finalizeUnconditionally):
1940         (JSC::JSC_FOREACH_BUILTIN_CODE): Deleted.
1941         (JSC::BuiltinExecutables::finalize): Deleted.
1942         * builtins/BuiltinExecutables.h:
1943         (JSC::BuiltinExecutables::static_cast<unsigned>):
1944         (): Deleted.
1945         * heap/Heap.cpp:
1946         (JSC::Heap::finalizeUnconditionalFinalizers):
1947
1948 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1949
1950         IntlDateTimeFormat can be shrunk by 32 bytes
1951         https://bugs.webkit.org/show_bug.cgi?id=195504
1952
1953         Reviewed by Darin Adler.
1954
1955         * runtime/IntlDateTimeFormat.h:
1956
1957 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1958
1959         IntlCollator can be shrunk by 16 bytes
1960         https://bugs.webkit.org/show_bug.cgi?id=195503
1961
1962         Reviewed by Darin Adler.
1963
1964         * runtime/IntlCollator.h:
1965
1966 2019-03-11  Robin Morisset  <rmorisset@apple.com>
1967
1968         IntlNumberFormat can be shrunk by 16 bytes
1969         https://bugs.webkit.org/show_bug.cgi?id=195505
1970
1971         Reviewed by Darin Adler.
1972
1973         * runtime/IntlNumberFormat.h:
1974
1975 2019-03-11  Caio Lima  <ticaiolima@gmail.com>
1976
1977         [ESNext][BigInt] Implement "~" unary operation
1978         https://bugs.webkit.org/show_bug.cgi?id=182216
1979
1980         Reviewed by Keith Miller.
1981
1982         This patch is adding support of BigInt into op_bitnot operations. In
1983         addition, we are changing ArithBitNot to handle only Number operands,
1984         while introducing a new node named ValueBitNot to handle Untyped and
1985         BigInt. This node follows the same approach we are doing into other
1986         arithimetic operations into DFG.
1987
1988         * dfg/DFGAbstractInterpreterInlines.h:
1989         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1990
1991         It is possible that fixup and prediction propagation don't convert a
1992         ValueBitNot(ConstInt32) into ArithBitNot(ConstInt32) because these
1993         analysis are conservative. In such case, we are adding constant
1994         folding rules to ValueBitNot AI.
1995
1996         * dfg/DFGBackwardsPropagationPhase.cpp:
1997         (JSC::DFG::BackwardsPropagationPhase::propagate):
1998
1999         ValueBitNot has same rules as ArithBitNot on backwards propagation.
2000
2001         * dfg/DFGByteCodeParser.cpp:
2002         (JSC::DFG::ByteCodeParser::parseBlock):
2003
2004         We can emit ArithBitNot if we know that operand of op_bitnot is a
2005         Number or any int. Otherwise we fallback to ValueBitNot and rely on
2006         fixup to convert the node to ArithBitNot when it is possible.
2007         ValueBitNot uses heap prediction on prediction propagation and we
2008         collect its type from op_bitnot's value profiler.
2009
2010         * dfg/DFGClobberize.h:
2011         (JSC::DFG::clobberize):
2012
2013         When we have the case with ValueBitNot(BigInt), we don't clobberize
2014         world.
2015
2016         * dfg/DFGDoesGC.cpp:
2017         (JSC::DFG::doesGC):
2018
2019         ValueBitNot can GC on BigIntUse because, right now, all bitNot
2020         operation allocates temporary BigInts to perform calculations and it
2021         can potentially trigger GC.
2022
2023         * dfg/DFGFixupPhase.cpp:
2024         (JSC::DFG::FixupPhase::fixupNode):
2025
2026         ValueBitNot is responsible do handle BigIntUse and UntypedUse. To all
2027         other uses, we fallback to ArithBitNot.
2028
2029         * dfg/DFGNode.h:
2030         (JSC::DFG::Node::hasHeapPrediction):
2031         * dfg/DFGNodeType.h:
2032         * dfg/DFGOperations.cpp:
2033         (JSC::DFG::bitwiseBinaryOp):
2034
2035         This template function is abstracting the new semantics of numeric
2036         values operations on bitwise operations. These operations usually
2037         folow these steps:
2038
2039             1. rhsNumeric = GetInt32OrBigInt(rhs)
2040             2. lhsNumeric = GetInt32OrBigInt(lhs)
2041             3. trhow error if TypeOf(rhsNumeric) != TypeOf(lhsNumeric)
2042             4. return BigInt::bitwiseOp(bitOp, rhs, lhs) if TypeOf(lhsNumeric) == BigInt
2043             5. return rhs <int32BitOp> lhs
2044
2045         Since we have almost the same code for every bitwise op,
2046         we use such template to avoid code duplication. The template receives
2047         Int32 and BigInt operations as parameter. Error message is received as
2048         `const char*` instead of `String&` to avoid String allocation even when
2049         there is no error to throw.
2050
2051         * dfg/DFGOperations.h:
2052         * dfg/DFGPredictionPropagationPhase.cpp:
2053         * dfg/DFGSafeToExecute.h:
2054         (JSC::DFG::safeToExecute):
2055         * dfg/DFGSpeculativeJIT.cpp:
2056         (JSC::DFG::SpeculativeJIT::compileValueBitNot):
2057
2058         ValueBitNot generates speculative code for BigIntUse and this code is a
2059         call to `operationBitNotBigInt`. This operation is faster than
2060         `operationValueBitNot` because there is no need to check types of
2061         operands and execute properly operation. We still need to check
2062         exceptions after `operationBitNotBigInt` because it can throw OOM.
2063
2064         (JSC::DFG::SpeculativeJIT::compileBitwiseNot):
2065         * dfg/DFGSpeculativeJIT.h:
2066         * dfg/DFGSpeculativeJIT32_64.cpp:
2067         (JSC::DFG::SpeculativeJIT::compile):
2068         * dfg/DFGSpeculativeJIT64.cpp:
2069         (JSC::DFG::SpeculativeJIT::compile):
2070         * ftl/FTLCapabilities.cpp:
2071         (JSC::FTL::canCompile):
2072         * ftl/FTLLowerDFGToB3.cpp:
2073         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2074         (JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
2075         (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot):
2076         * runtime/CommonSlowPaths.cpp:
2077         (JSC::SLOW_PATH_DECL):
2078         * runtime/JSBigInt.cpp:
2079         (JSC::JSBigInt::bitwiseNot):
2080         * runtime/JSBigInt.h:
2081
2082 2019-03-11  Darin Adler  <darin@apple.com>
2083
2084         Specify fixed precision explicitly to prepare to change String::number and StringBuilder::appendNumber floating point behavior
2085         https://bugs.webkit.org/show_bug.cgi?id=195533
2086
2087         Reviewed by Brent Fulgham.
2088
2089         * API/tests/ExecutionTimeLimitTest.cpp:
2090         (testExecutionTimeLimit): Use appendFixedPrecisionNumber.
2091         * runtime/NumberPrototype.cpp:
2092         (JSC::numberProtoFuncToPrecision): Use numberToStringFixedPrecision.
2093         * runtime/Options.cpp:
2094         (JSC::Option::dump const): Use appendFixedPrecisionNumber.
2095
2096 2019-03-10  Ross Kirsling  <ross.kirsling@sony.com>
2097
2098         Invalid flags in a RegExp literal should be an early SyntaxError
2099         https://bugs.webkit.org/show_bug.cgi?id=195514
2100
2101         Reviewed by Darin Adler.
2102
2103         Currently we're throwing a *runtime* SyntaxError; this should occur at parse time. 
2104
2105           12.2.8.1 Static Semantics: Early Errors
2106             PrimaryExpression : RegularExpressionLiteral
2107               - It is a Syntax Error if BodyText of RegularExpressionLiteral cannot be recognized
2108                 using the goal symbol Pattern of the ECMAScript RegExp grammar specified in 21.2.1.
2109               - It is a Syntax Error if FlagText of RegularExpressionLiteral contains any code points
2110                 other than "g", "i", "m",  "s", "u", or "y", or if it contains the same code point more than once.
2111
2112         In fixing this, let's also move flag handling from runtime/ to yarr/.
2113
2114         * yarr/YarrSyntaxChecker.cpp:
2115         (JSC::Yarr::checkSyntax):
2116         Check flags before checking pattern.
2117
2118         * CMakeLists.txt:
2119         * JavaScriptCore.xcodeproj/project.pbxproj:
2120         * Sources.txt:
2121         * bytecompiler/NodesCodegen.cpp:
2122         (JSC::RegExpNode::emitBytecode):
2123         * inspector/ContentSearchUtilities.cpp:
2124         (Inspector::ContentSearchUtilities::findMagicComment):
2125         * runtime/CachedTypes.cpp:
2126         * runtime/RegExp.cpp:
2127         (JSC::RegExp::RegExp):
2128         (JSC::RegExp::createWithoutCaching):
2129         (JSC::RegExp::create):
2130         (JSC::regExpFlags): Deleted.
2131         * runtime/RegExp.h:
2132         * runtime/RegExpCache.cpp:
2133         (JSC::RegExpCache::lookupOrCreate):
2134         (JSC::RegExpCache::ensureEmptyRegExpSlow):
2135         * runtime/RegExpCache.h:
2136         * runtime/RegExpConstructor.cpp:
2137         (JSC::toFlags):
2138         (JSC::regExpCreate):
2139         (JSC::constructRegExp):
2140         * runtime/RegExpKey.h:
2141         (JSC::RegExpKey::RegExpKey):
2142         (WTF::HashTraits<JSC::RegExpKey>::constructDeletedValue):
2143         (WTF::HashTraits<JSC::RegExpKey>::isDeletedValue):
2144         (): Deleted.
2145         * runtime/RegExpPrototype.cpp:
2146         (JSC::regExpProtoFuncCompile):
2147         * testRegExp.cpp:
2148         (parseRegExpLine):
2149         * yarr/RegularExpression.cpp:
2150         (JSC::Yarr::RegularExpression::Private::compile):
2151         * yarr/YarrFlags.cpp: Added.
2152         (JSC::Yarr::parseFlags):
2153         * yarr/YarrFlags.h: Added.
2154         * yarr/YarrInterpreter.h:
2155         (JSC::Yarr::BytecodePattern::ignoreCase const):
2156         (JSC::Yarr::BytecodePattern::multiline const):
2157         (JSC::Yarr::BytecodePattern::sticky const):
2158         (JSC::Yarr::BytecodePattern::unicode const):
2159         (JSC::Yarr::BytecodePattern::dotAll const):
2160         * yarr/YarrPattern.cpp:
2161         (JSC::Yarr::YarrPattern::compile):
2162         (JSC::Yarr::YarrPattern::YarrPattern):
2163         (JSC::Yarr::YarrPattern::dumpPattern):
2164         * yarr/YarrPattern.h:
2165         (JSC::Yarr::YarrPattern::global const):
2166         (JSC::Yarr::YarrPattern::ignoreCase const):
2167         (JSC::Yarr::YarrPattern::multiline const):
2168         (JSC::Yarr::YarrPattern::sticky const):
2169         (JSC::Yarr::YarrPattern::unicode const):
2170         (JSC::Yarr::YarrPattern::dotAll const):
2171         Move flag handling to Yarr and modernize API.
2172
2173 2019-03-09  Robin Morisset  <rmorisset@apple.com>
2174
2175         Compilation can be shrunk by 8 bytes
2176         https://bugs.webkit.org/show_bug.cgi?id=195500
2177
2178         Reviewed by Mark Lam.
2179
2180         * profiler/ProfilerCompilation.cpp:
2181         (JSC::Profiler::Compilation::Compilation):
2182         * profiler/ProfilerCompilation.h:
2183
2184 2019-03-09  Robin Morisset  <rmorisset@apple.com>
2185
2186         BinarySwitch can be shrunk by 8 bytes
2187         https://bugs.webkit.org/show_bug.cgi?id=195493
2188
2189         Reviewed by Mark Lam.
2190
2191         * jit/BinarySwitch.cpp:
2192         (JSC::BinarySwitch::BinarySwitch):
2193         * jit/BinarySwitch.h:
2194
2195 2019-03-09  Robin Morisset  <rmorisset@apple.com>
2196
2197         AsyncStackTrace can be shrunk by 8 bytes
2198         https://bugs.webkit.org/show_bug.cgi?id=195491
2199
2200         Reviewed by Mark Lam.
2201
2202         * inspector/AsyncStackTrace.h:
2203
2204 2019-03-08  Mark Lam  <mark.lam@apple.com>
2205
2206         Stack overflow crash in JSC::JSObject::hasInstance.
2207         https://bugs.webkit.org/show_bug.cgi?id=195458
2208         <rdar://problem/48710195>
2209
2210         Reviewed by Yusuke Suzuki.
2211
2212         * runtime/JSObject.cpp:
2213         (JSC::JSObject::hasInstance):
2214
2215 2019-03-08  Robin Morisset  <rmorisset@apple.com>
2216
2217         IntegerCheckCombiningPhase::Range can be shrunk by 8 bytes
2218         https://bugs.webkit.org/show_bug.cgi?id=195487
2219
2220         Reviewed by Saam Barati.
2221
2222         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2223
2224 2019-03-08  Robin Morisset  <rmorisset@apple.com>
2225
2226         TypeLocation can be shrunk by 8 bytes
2227         https://bugs.webkit.org/show_bug.cgi?id=195483
2228
2229         Reviewed by Mark Lam.
2230
2231         * bytecode/TypeLocation.h:
2232         (JSC::TypeLocation::TypeLocation):
2233
2234 2019-03-08  Robin Morisset  <rmorisset@apple.com>
2235
2236         GetByIdStatus can be shrunk by 16 bytes
2237         https://bugs.webkit.org/show_bug.cgi?id=195480
2238
2239         Reviewed by Saam Barati.
2240
2241         8 bytes from reordering fields
2242         8 more bytes by making the enum State only use 1 byte.
2243
2244         * bytecode/GetByIdStatus.cpp:
2245         (JSC::GetByIdStatus::GetByIdStatus):
2246         * bytecode/GetByIdStatus.h:
2247
2248 2019-03-08  Robin Morisset  <rmorisset@apple.com>
2249
2250         PutByIdVariant can be shrunk by 8 bytes
2251         https://bugs.webkit.org/show_bug.cgi?id=195482
2252
2253         Reviewed by Mark Lam.
2254
2255         * bytecode/PutByIdVariant.h:
2256         (JSC::PutByIdVariant::PutByIdVariant):
2257
2258 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
2259
2260         Unreviewed, follow-up after r242568
2261
2262         Robin pointed that calculation of `numberOfChildren` and `nonEmptyIndex` is unnecessary.
2263
2264         * dfg/DFGAbstractInterpreterInlines.h:
2265         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2266
2267 2019-03-08  Yusuke Suzuki  <ysuzuki@apple.com>
2268
2269         [JSC] We should have more WithoutTransition functions which are usable for JSGlobalObject initialization
2270         https://bugs.webkit.org/show_bug.cgi?id=195447
2271
2272         Reviewed by Filip Pizlo.
2273
2274         This patch reduces # of unnecessary structure transitions in JSGlobalObject initialization to avoid unnecessary allocations
2275         caused by Structure transition. One example is WeakBlock allocation for StructureTransitionTable.
2276         To achieve this, we (1) add putDirectNonIndexAccessorWithoutTransition and putDirectNativeIntrinsicGetterWithoutTransition
2277         to add accessor properties without transition, and (2) add NameAdditionMode::WithoutStructureTransition mode to InternalFunction::finishCreation
2278         to use `putDirectWithoutTransition` instead of `putDirect`.
2279
2280         * inspector/JSInjectedScriptHostPrototype.cpp:
2281         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2282         * inspector/JSJavaScriptCallFramePrototype.cpp:
2283         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2284         * runtime/ArrayConstructor.cpp:
2285         (JSC::ArrayConstructor::finishCreation):
2286         * runtime/AsyncFunctionConstructor.cpp:
2287         (JSC::AsyncFunctionConstructor::finishCreation):
2288         * runtime/AsyncGeneratorFunctionConstructor.cpp:
2289         (JSC::AsyncGeneratorFunctionConstructor::finishCreation):
2290         * runtime/BigIntConstructor.cpp:
2291         (JSC::BigIntConstructor::finishCreation):
2292         * runtime/BooleanConstructor.cpp:
2293         (JSC::BooleanConstructor::finishCreation):
2294         * runtime/DateConstructor.cpp:
2295         (JSC::DateConstructor::finishCreation):
2296         * runtime/ErrorConstructor.cpp:
2297         (JSC::ErrorConstructor::finishCreation):
2298         * runtime/FunctionConstructor.cpp:
2299         (JSC::FunctionConstructor::finishCreation):
2300         * runtime/FunctionPrototype.cpp:
2301         (JSC::FunctionPrototype::finishCreation):
2302         (JSC::FunctionPrototype::addFunctionProperties):
2303         (JSC::FunctionPrototype::initRestrictedProperties):
2304         * runtime/FunctionPrototype.h:
2305         * runtime/GeneratorFunctionConstructor.cpp:
2306         (JSC::GeneratorFunctionConstructor::finishCreation):
2307         * runtime/InternalFunction.cpp:
2308         (JSC::InternalFunction::finishCreation):
2309         * runtime/InternalFunction.h:
2310         * runtime/IntlCollatorConstructor.cpp:
2311         (JSC::IntlCollatorConstructor::finishCreation):
2312         * runtime/IntlDateTimeFormatConstructor.cpp:
2313         (JSC::IntlDateTimeFormatConstructor::finishCreation):
2314         * runtime/IntlNumberFormatConstructor.cpp:
2315         (JSC::IntlNumberFormatConstructor::finishCreation):
2316         * runtime/IntlPluralRulesConstructor.cpp:
2317         (JSC::IntlPluralRulesConstructor::finishCreation):
2318         * runtime/JSArrayBufferConstructor.cpp:
2319         (JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
2320         * runtime/JSArrayBufferPrototype.cpp:
2321         (JSC::JSArrayBufferPrototype::finishCreation):
2322         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2323         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2324         * runtime/JSGlobalObject.cpp:
2325         (JSC::JSGlobalObject::init):
2326         * runtime/JSObject.cpp:
2327         (JSC::JSObject::putDirectNonIndexAccessorWithoutTransition):
2328         (JSC::JSObject::putDirectNativeIntrinsicGetterWithoutTransition):
2329         * runtime/JSObject.h:
2330         * runtime/JSPromiseConstructor.cpp:
2331         (JSC::JSPromiseConstructor::finishCreation):
2332         * runtime/JSTypedArrayViewConstructor.cpp:
2333         (JSC::JSTypedArrayViewConstructor::finishCreation):
2334         * runtime/JSTypedArrayViewPrototype.cpp:
2335         (JSC::JSTypedArrayViewPrototype::finishCreation):
2336         * runtime/MapConstructor.cpp:
2337         (JSC::MapConstructor::finishCreation):
2338         * runtime/MapPrototype.cpp:
2339         (JSC::MapPrototype::finishCreation):
2340         * runtime/NativeErrorConstructor.cpp:
2341         (JSC::NativeErrorConstructorBase::finishCreation):
2342         * runtime/NullGetterFunction.h:
2343         * runtime/NullSetterFunction.h:
2344         * runtime/NumberConstructor.cpp:
2345         (JSC::NumberConstructor::finishCreation):
2346         * runtime/ObjectConstructor.cpp:
2347         (JSC::ObjectConstructor::finishCreation):
2348         * runtime/ProxyConstructor.cpp:
2349         (JSC::ProxyConstructor::finishCreation):
2350         * runtime/RegExpConstructor.cpp:
2351         (JSC::RegExpConstructor::finishCreation):
2352         * runtime/RegExpPrototype.cpp:
2353         (JSC::RegExpPrototype::finishCreation):
2354         * runtime/SetConstructor.cpp:
2355         (JSC::SetConstructor::finishCreation):
2356         * runtime/SetPrototype.cpp:
2357         (JSC::SetPrototype::finishCreation):
2358         * runtime/StringConstructor.cpp:
2359         (JSC::StringConstructor::finishCreation):
2360         * runtime/SymbolConstructor.cpp:
2361         (JSC::SymbolConstructor::finishCreation):
2362         * runtime/WeakMapConstructor.cpp:
2363         (JSC::WeakMapConstructor::finishCreation):
2364         * runtime/WeakSetConstructor.cpp:
2365         (JSC::WeakSetConstructor::finishCreation):
2366         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2367         (JSC::WebAssemblyCompileErrorConstructor::finishCreation):
2368         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2369         (JSC::WebAssemblyInstanceConstructor::finishCreation):
2370         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2371         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
2372         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2373         (JSC::WebAssemblyMemoryConstructor::finishCreation):
2374         * wasm/js/WebAssemblyModuleConstructor.cpp:
2375         (JSC::WebAssemblyModuleConstructor::finishCreation):
2376         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2377         (JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
2378         * wasm/js/WebAssemblyTableConstructor.cpp:
2379         (JSC::WebAssemblyTableConstructor::finishCreation):
2380
2381 2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
2382
2383         op_check_tdz does not def its argument
2384         https://bugs.webkit.org/show_bug.cgi?id=192880
2385         <rdar://problem/46221598>
2386
2387         Reviewed by Saam Barati.
2388
2389         This prevented the for-in loop optimization in the bytecode generator, since
2390         the analysis sees a redefinition of the loop variable.
2391
2392         * bytecode/BytecodeUseDef.h:
2393         (JSC::computeDefsForBytecodeOffset):
2394
2395 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
2396
2397         [JSC] Make more fields lazy in JSGlobalObject
2398         https://bugs.webkit.org/show_bug.cgi?id=195449
2399
2400         Reviewed by Mark Lam.
2401
2402         This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
2403
2404         1. Some minor structures like moduleRecordStructure.
2405         2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
2406         3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
2407
2408         * interpreter/Interpreter.cpp:
2409         (JSC::Interpreter::execute):
2410         * runtime/JSArrayBufferPrototype.h:
2411         * runtime/JSGlobalObject.cpp:
2412         (JSC::JSGlobalObject::init):
2413         (JSC::JSGlobalObject::visitChildren):
2414         * runtime/JSGlobalObject.h:
2415         (JSC::JSGlobalObject::parseIntFunction const):
2416         (JSC::JSGlobalObject::parseFloatFunction const):
2417         (JSC::JSGlobalObject::evalFunction const):
2418         (JSC::JSGlobalObject::strictEvalActivationStructure const):
2419         (JSC::JSGlobalObject::moduleRecordStructure const):
2420         (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
2421         (JSC::JSGlobalObject::proxyObjectStructure const):
2422         (JSC::JSGlobalObject::callableProxyObjectStructure const):
2423         (JSC::JSGlobalObject::proxyRevokeStructure const):
2424         (JSC::JSGlobalObject::arrayBufferConstructor const):
2425         (JSC::JSGlobalObject::arrayBufferPrototype const):
2426         (JSC::JSGlobalObject::arrayBufferStructure const):
2427         * runtime/ProxyObject.h:
2428         * runtime/StrictEvalActivation.cpp:
2429         (JSC::StrictEvalActivation::StrictEvalActivation):
2430         * runtime/StrictEvalActivation.h:
2431         * wasm/js/JSWebAssemblyMemory.cpp:
2432         (JSC::JSWebAssemblyMemory::buffer):
2433         * wasm/js/WebAssemblyModuleConstructor.cpp:
2434         (JSC::webAssemblyModuleCustomSections):
2435
2436 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
2437
2438         [JSC] Remove merging must handle values into proven types in CFA
2439         https://bugs.webkit.org/show_bug.cgi?id=195444
2440
2441         Reviewed by Saam Barati.
2442
2443         Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
2444         from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
2445
2446             Block #2 (loop header) succ #3, #4
2447             ...
2448             1: ForceOSRExit
2449             ...
2450             2: JSConstant(0)
2451             3: SetLocal(@2, loc6)
2452             ...
2453             4: Branch(#3, #4)
2454
2455             Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
2456             ...
2457             5: GetLocal(loc6)
2458             6: StringFromCharCode(@5)
2459             ...
2460
2461         Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
2462         If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
2463         as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
2464         we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
2465         we should not merge it in CFA.
2466
2467         Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
2468         progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
2469
2470         * dfg/DFGCFAPhase.cpp:
2471         (JSC::DFG::CFAPhase::run):
2472         (JSC::DFG::CFAPhase::performBlockCFA):
2473         (JSC::DFG::CFAPhase::injectOSR): Deleted.
2474
2475 2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
2476
2477         [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
2478         https://bugs.webkit.org/show_bug.cgi?id=195429
2479
2480         Reviewed by Saam Barati.
2481
2482         We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
2483         for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
2484         this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
2485         Note that ThunkGenerators's StringFromCharCode thunk was correct.
2486
2487         * dfg/DFGSpeculativeJIT.cpp:
2488         (JSC::DFG::SpeculativeJIT::compileFromCharCode):
2489         * ftl/FTLLowerDFGToB3.cpp:
2490         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
2491
2492 2019-03-07  Mark Lam  <mark.lam@apple.com>
2493
2494         Follow up refactoring in try-finally code after r242591.
2495         https://bugs.webkit.org/show_bug.cgi?id=195428
2496
2497         Reviewed by Saam Barati.
2498
2499         1. Added some comments in emitFinallyCompletion() to describe each completion case.
2500         2. Converted CatchEntry into a struct.
2501         3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
2502            to be more clear about its purpose.
2503
2504         * bytecompiler/BytecodeGenerator.cpp:
2505         (JSC::BytecodeGenerator::generate):
2506         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
2507         (JSC::BytecodeGenerator::emitFinallyCompletion):
2508         * bytecompiler/BytecodeGenerator.h:
2509
2510 2019-03-07  Saam Barati  <sbarati@apple.com>
2511
2512         CompactVariableMap::Handle's copy operator= leaks the previous data
2513         https://bugs.webkit.org/show_bug.cgi?id=195398
2514
2515         Reviewed by Yusuke Suzuki.
2516
2517         The copy constructor was just assigning |this| to the new value,
2518         forgetting to decrement the ref count of the thing pointed to by
2519         the |this| handle. Based on Yusuke's suggestion, this patch refactors
2520         the move constructor, move operator=, and copy operator= to use the
2521         swap() primitive and the copy constructor primitive.
2522
2523         * parser/VariableEnvironment.cpp:
2524         (JSC::CompactVariableMap::Handle::Handle):
2525         (JSC::CompactVariableMap::Handle::swap):
2526         (JSC::CompactVariableMap::Handle::operator=): Deleted.
2527         * parser/VariableEnvironment.h:
2528         (JSC::CompactVariableMap::Handle::Handle):
2529         (JSC::CompactVariableMap::Handle::operator=):
2530
2531 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
2532
2533         Lazily decode cached bytecode
2534         https://bugs.webkit.org/show_bug.cgi?id=194810
2535
2536         Reviewed by Saam Barati.
2537
2538         Like lazy parsing, we should pause at code block boundaries. Instead
2539         of always eagerly decoding UnlinkedFunctionExecutable's UnlinkedCodeBlocks,
2540         we store their offsets in the executable and lazily decode them on the next
2541         call to `unlinkedCodeBlockFor`.
2542
2543         * bytecode/UnlinkedFunctionExecutable.cpp:
2544         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2545         (JSC::UnlinkedFunctionExecutable::~UnlinkedFunctionExecutable):
2546         (JSC::UnlinkedFunctionExecutable::visitChildren):
2547         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
2548         (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks):
2549         * bytecode/UnlinkedFunctionExecutable.h:
2550         * runtime/CachedTypes.cpp:
2551         (JSC::Decoder::Decoder):
2552         (JSC::Decoder::~Decoder):
2553         (JSC::Decoder::create):
2554         (JSC::Decoder::offsetOf):
2555         (JSC::Decoder::cacheOffset):
2556         (JSC::Decoder::ptrForOffsetFromBase):
2557         (JSC::Decoder::handleForEnvironment const):
2558         (JSC::Decoder::setHandleForEnvironment):
2559         (JSC::Decoder::addFinalizer):
2560         (JSC::VariableLengthObject::isEmpty const):
2561         (JSC::CachedWriteBarrier::isEmpty const):
2562         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForCall const):
2563         (JSC::CachedFunctionExecutable::unlinkedCodeBlockForConstruct const):
2564         (JSC::CachedFunctionExecutable::decode const):
2565         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2566         (JSC::decodeCodeBlockImpl):
2567         (JSC::isCachedBytecodeStillValid):
2568         (JSC::decodeFunctionCodeBlock):
2569         * runtime/CachedTypes.h:
2570         (JSC::Decoder::vm):
2571
2572 2019-03-06  Mark Lam  <mark.lam@apple.com>
2573
2574         Exception is a JSCell, not a JSObject.
2575         https://bugs.webkit.org/show_bug.cgi?id=195392
2576
2577         Reviewed by Saam Barati.
2578
2579         Exception is a VM implementation construct to carry a stack trace for the point
2580         where it is thrown from.  As a reminder, an Exception is needed because:
2581         1. JS code can throw primitives as well that are non-cells.
2582         2. Error objects capture the stack trace at the point where they are constructed,
2583            which is not always the same as the point where they are thrown (if they are
2584            thrown).
2585
2586         Hence, Exception should not be visible to JS code, and therefore should not be a
2587         JSObject.  Hence, it should not inherit from JSDestructibleObject.
2588
2589         This patch changes the following:
2590
2591         1. Exception now inherits directly from JSCell instead.
2592
2593         2. Places where we return an Exception masquerading as a JSObject* are now
2594            updated to return a nullptr when we encounter an exception.
2595
2596         3. We still return Exception* as JSValue or EncodedJSValue when we encounter an
2597            exception in functions that return JSValue or EncodedJSValue.  This is because
2598            the number that implements the following pattern is too numerous:
2599
2600                 return throw<Some Error>(...)
2601
2602            We'll leave these as is for now.
2603
2604         * bytecode/CodeBlock.h:
2605         (JSC::ScriptExecutable::prepareForExecution):
2606         * interpreter/Interpreter.cpp:
2607         (JSC::Interpreter::executeProgram):
2608         (JSC::Interpreter::executeCall):
2609         (JSC::Interpreter::executeConstruct):
2610         (JSC::Interpreter::prepareForRepeatCall):
2611         (JSC::Interpreter::execute):
2612         (JSC::Interpreter::executeModuleProgram):
2613         * jit/JITOperations.cpp:
2614         * llint/LLIntSlowPaths.cpp:
2615         (JSC::LLInt::setUpCall):
2616         * runtime/ConstructData.cpp:
2617         (JSC::construct):
2618         * runtime/Error.cpp:
2619         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
2620         (JSC::throwTypeError):
2621         (JSC::throwSyntaxError):
2622         * runtime/Error.h:
2623         (JSC::throwRangeError):
2624         * runtime/Exception.cpp:
2625         (JSC::Exception::createStructure):
2626         * runtime/Exception.h:
2627         * runtime/ExceptionHelpers.cpp:
2628         (JSC::throwOutOfMemoryError):
2629         (JSC::throwStackOverflowError):
2630         (JSC::throwTerminatedExecutionException):
2631         * runtime/ExceptionHelpers.h:
2632         * runtime/FunctionConstructor.cpp:
2633         (JSC::constructFunction):
2634         (JSC::constructFunctionSkippingEvalEnabledCheck):
2635         * runtime/IntlPluralRules.cpp:
2636         (JSC::IntlPluralRules::resolvedOptions):
2637         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2638         (JSC::constructGenericTypedArrayViewWithArguments):
2639         * runtime/JSObject.h:
2640         * runtime/ObjectConstructor.cpp:
2641         (JSC::objectConstructorSeal):
2642         (JSC::objectConstructorFreeze):
2643         * runtime/ProgramExecutable.cpp:
2644         (JSC::ProgramExecutable::initializeGlobalProperties):
2645         * runtime/RegExpConstructor.cpp:
2646         (JSC::regExpCreate):
2647         (JSC::constructRegExp):
2648         * runtime/ScriptExecutable.cpp:
2649         (JSC::ScriptExecutable::newCodeBlockFor):
2650         (JSC::ScriptExecutable::prepareForExecutionImpl):
2651         * runtime/ScriptExecutable.h:
2652         * runtime/ThrowScope.cpp:
2653         (JSC::ThrowScope::throwException):
2654         * runtime/ThrowScope.h:
2655         (JSC::ThrowScope::throwException):
2656         (JSC::throwException):
2657         * runtime/VM.cpp:
2658         (JSC::VM::throwException):
2659         * runtime/VM.h:
2660
2661 2019-03-06  Ross Kirsling  <ross.kirsling@sony.com>
2662
2663         [Win] Remove -DUCHAR_TYPE=wchar_t stopgap and learn to live with char16_t.
2664         https://bugs.webkit.org/show_bug.cgi?id=195346
2665
2666         Reviewed by Fujii Hironori.
2667
2668         * jsc.cpp:
2669         (currentWorkingDirectory):
2670         (fetchModuleFromLocalFileSystem):
2671         * runtime/DateConversion.cpp:
2672         (JSC::formatDateTime):
2673         Use wchar helpers as needed.
2674
2675 2019-03-06  Mark Lam  <mark.lam@apple.com>
2676
2677         Fix incorrect handling of try-finally completion values.
2678         https://bugs.webkit.org/show_bug.cgi?id=195131
2679         <rdar://problem/46222079>
2680
2681         Reviewed by Saam Barati and Yusuke Suzuki.
2682
2683         Consider the following:
2684
2685             function foo() {                        // line 1
2686                 try {
2687                     return 42;                      // line 3
2688                 } finally {
2689                     for (var j = 0; j < 1; j++) {   // line 5
2690                         try {
2691                             throw '';               // line 7
2692                         } finally {
2693                             continue;               // line 9
2694                         }
2695                     }
2696                 }                                   // line 11
2697             }
2698             var result = foo();
2699
2700         With the current (before fix) code base, result will be the exception object thrown
2701         at line 7.  The expected result should be 42, returned at line 3.
2702
2703         The bug is that we were previously only using one set of completion type and
2704         value registers for the entire function.  This is inadequate because the outer
2705         try-finally needs to preserve its own completion type and value ({ Return, 42 }
2706         in this case) in order to be able to complete correctly.
2707
2708         One might be deceived into thinking that the above example should complete with
2709         the exception thrown at line 7.  However, according to Section 13.15.8 of the
2710         ECMAScript spec, the 'continue' in the finally at line 9 counts as an abrupt
2711         completion.  As a result, it overrides the throw from line 7.  After the continue,
2712         execution resumes at the top of the loop at line 5, followed by a normal completion
2713         at line 11.
2714
2715         Also according to Section 13.15.8, given that the completion type of the outer
2716         finally is normal, the resultant completion of the outer try-finally should be
2717         the completion of the outer try block i.e. { Return, 42 }.
2718
2719         This patch makes the following changes:
2720         
2721         1. Fix handling of finally completion to use a unique set of completion
2722            type and value registers for each FinallyContext.
2723
2724         2. Move the setting of Throw completion type to the out of line exception handler.
2725            This makes the mainline code slightly less branchy.
2726
2727         3. Introduce emitOutOfLineCatchHandler(), emitOutOfLineFinallyHandler(), and
2728            emitOutOfLineExceptionHandler() to make it clearer that these are not emitting
2729            bytecode inline.  Also, these make it clearer when we're emitting a handler
2730            for a catch vs a finally.
2731
2732         4. Allocate the FinallyContext on the stack instead of as a member of the
2733            heap allocated ControlFlowScope.  This simplifies its life-cycle management
2734            and reduces the amount of needed copying.
2735
2736         5. Update emitFinallyCompletion() to propagate the completion type and value to
2737            the outer FinallyContext when needed.
2738
2739         6. Fix emitJumpIf() to use the right order of operands.  Previously, we were
2740            only using it to do op_stricteq and op_nstricteq comparisons.  So, the order
2741            wasn't important.  We now use it to also do op_beloweq comparisons.  Hence,
2742            the order needs to be corrected.
2743
2744         7. Remove the unused CompletionType::Break and Continue.  These are encoded with
2745            the jumpIDs of the jump targets instead.
2746
2747         Relevant specifications:
2748         Section 13.15.8: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-try-statement-runtime-semantics-evaluation
2749         Section 6.3.2.4: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-updateempty
2750
2751         * bytecompiler/BytecodeGenerator.cpp:
2752         (JSC::FinallyContext::FinallyContext):
2753         (JSC::BytecodeGenerator::generate):
2754         (JSC::BytecodeGenerator::BytecodeGenerator):
2755         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2756         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2757         (JSC::BytecodeGenerator::emitOutOfLineCatchHandler):
2758         (JSC::BytecodeGenerator::emitOutOfLineFinallyHandler):
2759         (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
2760         (JSC::BytecodeGenerator::emitEnumeration):
2761         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2762         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2763         (JSC::BytecodeGenerator::emitFinallyCompletion):
2764         (JSC::BytecodeGenerator::emitJumpIf):
2765         (JSC::BytecodeGenerator::emitCatch): Deleted.
2766         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
2767         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
2768         * bytecompiler/BytecodeGenerator.h:
2769         (JSC::FinallyContext::completionTypeRegister const):
2770         (JSC::FinallyContext::completionValueRegister const):
2771         (JSC::ControlFlowScope::ControlFlowScope):
2772         (JSC::BytecodeGenerator::emitLoad):
2773         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
2774         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
2775         (JSC::BytecodeGenerator::completionTypeRegister const): Deleted.
2776         (JSC::BytecodeGenerator::completionValueRegister const): Deleted.
2777         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
2778         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
2779         * bytecompiler/NodesCodegen.cpp:
2780         (JSC::TryNode::emitBytecode):
2781
2782 2019-03-06  Saam Barati  <sbarati@apple.com>
2783
2784         JSScript should keep the cache file locked for the duration of its existence and should truncate the cache when it is out of date
2785         https://bugs.webkit.org/show_bug.cgi?id=195186
2786
2787         Reviewed by Keith Miller.
2788
2789         This patch makes it so that JSScript will keep its bytecode cache file
2790         locked as long as the JSScript is alive. This makes it obvious that it's
2791         safe to update that file, as it will only be used in a single VM, across
2792         all processes, at a single time. We may be able to extend this in the future
2793         if we can atomically update it across VMs/processes. However, we're choosing
2794         more restricted semantics now as it's always easier to extend these semantics
2795         in the future opposed to having to support the more flexible behavior
2796         up front.
2797         
2798         This patch also:
2799         - Adds error messages if writing the cache fails. We don't expect this to
2800           fail, but previously we would say we cached it even if write() fails.
2801         - Removes the unused m_moduleKey field.
2802         - Makes calling cacheBytecodeWithError with an already non-empty cache file fail.
2803           In the future, we should extend this to just fill in the parts of the cache
2804           that are not present. But we don't have the ability to do that yet, so we
2805           just result in an error for now.
2806
2807         * API/JSScript.mm:
2808         (-[JSScript dealloc]):
2809         (-[JSScript readCache]):
2810         (-[JSScript init]):
2811         (-[JSScript writeCache:]):
2812         * API/JSScriptInternal.h:
2813         * API/tests/testapi.mm:
2814         (testCacheFileIsExclusive):
2815         (testCacheFileFailsWhenItsAlreadyCached):
2816         (testObjectiveCAPI):
2817
2818 2019-03-06  Christopher Reid  <chris.reid@sony.com>
2819
2820         Followups to (r242306): Use LockHolder instead of std::lock_guard on Remote Inspector Locks
2821         https://bugs.webkit.org/show_bug.cgi?id=195381
2822
2823         Reviewed by Mark Lam.
2824
2825         Replacing std::lock_guard uses in Remote Inspector with WTF::LockHolder.
2826         Also using `= { }` for struct initialization instead of memeset.
2827
2828         * inspector/remote/RemoteConnectionToTarget.cpp:
2829         * inspector/remote/RemoteInspector.cpp:
2830         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
2831         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2832         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
2833         * inspector/remote/glib/RemoteInspectorGlib.cpp:
2834         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp:
2835         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp:
2836         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp:
2837         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp:
2838
2839 2019-03-06  Saam Barati  <sbarati@apple.com>
2840
2841         Air::reportUsedRegisters must padInterference
2842         https://bugs.webkit.org/show_bug.cgi?id=195303
2843         <rdar://problem/48270343>
2844
2845         Reviewed by Keith Miller.
2846
2847         reportUsedRegisters uses reg liveness to eliminate loads/moves into dead
2848         registers. However, liveness can report incorrect results in certain 
2849         scenarios when considering liveness at instruction boundaries. For example,
2850         it can go wrong when an Inst has a LateUse of a register and the following
2851         Inst has an EarlyDef of that same register. Such a scenario could lead us
2852         to incorrectly say the register is not live-in to the first Inst. Pad
2853         interference inserts Nops between such instruction boundaries that cause
2854         this issue.
2855         
2856         The test with this patch fixes the issue in reportUsedRegisters. This patch
2857         also conservatively makes it so that lowerAfterRegAlloc calls padInterference
2858         since it also reasons about liveness.
2859
2860         * b3/air/AirLowerAfterRegAlloc.cpp:
2861         (JSC::B3::Air::lowerAfterRegAlloc):
2862         * b3/air/AirPadInterference.h:
2863         * b3/air/AirReportUsedRegisters.cpp:
2864         (JSC::B3::Air::reportUsedRegisters):
2865         * b3/testb3.cpp:
2866         (JSC::B3::testReportUsedRegistersLateUseNotDead):
2867         (JSC::B3::run):
2868
2869 2019-03-06  Yusuke Suzuki  <ysuzuki@apple.com>
2870
2871         [JSC] AI should not propagate AbstractValue relying on constant folding phase
2872         https://bugs.webkit.org/show_bug.cgi?id=195375
2873
2874         Reviewed by Saam Barati.
2875
2876         MakeRope rule in AI attempts to propagate the node, which will be produced after constant folding phase runs.
2877         This is wrong since we do not guarantee that constant folding phase runs after AI runs (e.g. DFGSpeculativeJIT
2878         and FTLLowerDFGToB3 run AI). This results in the bug that the value produced at runtime is different from the
2879         proven constant value in AI. In the attached test, AI says the value is SpecStringIdent while the resulted value
2880         at runtime is SpecStringVar, resulting in wrong MakeRope code. This patch removes the path propagating the node
2881         relying on constant folding phase.
2882
2883         * dfg/DFGAbstractInterpreterInlines.h:
2884         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2885
2886 2019-03-05  Saam barati  <sbarati@apple.com>
2887
2888         op_switch_char broken for rope strings after JSRopeString layout rewrite
2889         https://bugs.webkit.org/show_bug.cgi?id=195339
2890         <rdar://problem/48592545>
2891
2892         Reviewed by Yusuke Suzuki.
2893
2894         When we did the JSString rewrite, we accidentally broke LLInt's switch_char
2895         for rope strings. That change made it so that we always go to the slow path
2896         for ropes. That's wrong. The slow path should only be taken when the rope
2897         is of length 1. For lengths other than 1, we need to fall through to the
2898         default case. This patch fixes this.
2899
2900         * llint/LowLevelInterpreter32_64.asm:
2901         * llint/LowLevelInterpreter64.asm:
2902         * runtime/JSString.h:
2903
2904 2019-03-05  Yusuke Suzuki  <ysuzuki@apple.com>
2905
2906         [JSC] Should check exception for JSString::toExistingAtomicString
2907         https://bugs.webkit.org/show_bug.cgi?id=195337
2908
2909         Reviewed by Keith Miller, Saam Barati, and Mark Lam.
2910
2911         We missed the exception check for JSString::toExistingAtomicString while it can resolve
2912         a rope and throw an OOM exception. This patch adds necessary exception checks. This patch
2913         fixes test failures in debug build, reported in https://bugs.webkit.org/show_bug.cgi?id=194375#c93.
2914
2915         * dfg/DFGOperations.cpp:
2916         * jit/JITOperations.cpp:
2917         (JSC::getByVal):
2918         * llint/LLIntSlowPaths.cpp:
2919         (JSC::LLInt::getByVal):
2920         * runtime/CommonSlowPaths.cpp:
2921         (JSC::SLOW_PATH_DECL):
2922
2923 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2924
2925         Unreviewed, build fix for debug builds after r242397
2926
2927         * runtime/JSString.h:
2928
2929 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2930
2931         [JSC] Store bits for JSRopeString in 3 stores
2932         https://bugs.webkit.org/show_bug.cgi?id=195234
2933
2934         Reviewed by Saam Barati.
2935
2936         This patch cleans up the initialization of JSRopeString fields in DFG and FTL.
2937         Previously, we store some part of data separately. Instead, this patch calculates
2938         the data first by bit operations and store calculated data with fewer stores.
2939
2940         This patch also cleans up is8Bit and isSubstring flags. We put them in lower bits
2941         of the first fiber instead of the upper 16 bits. Since we only have 3 bit flags, (isRope, is8Bit, isSubstring),
2942         we can put them into the lower 3 bits, they are always empty due to alignment.
2943
2944         * bytecode/AccessCase.cpp:
2945         (JSC::AccessCase::generateImpl): A bit clean up of StringLength IC to give a chance of unnecessary mov removal.
2946         * dfg/DFGSpeculativeJIT.cpp:
2947         (JSC::DFG::SpeculativeJIT::canBeRope):
2948         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2949         (JSC::DFG::SpeculativeJIT::compileMakeRope):
2950         * dfg/DFGSpeculativeJIT.h:
2951         * ftl/FTLAbstractHeapRepository.cpp:
2952         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
2953         * ftl/FTLAbstractHeapRepository.h:
2954         * ftl/FTLLowerDFGToB3.cpp:
2955         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
2956         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):
2957         (JSC::FTL::DFG::LowerDFGToB3::isNotRopeString):
2958         * runtime/JSString.cpp:
2959         (JSC::JSString::visitChildren):
2960         * runtime/JSString.h:
2961         (JSC::JSString::is8Bit const):
2962         (JSC::JSString::isSubstring const):
2963         * tools/JSDollarVM.cpp:
2964         (JSC::functionCreateNullRopeString):
2965         (JSC::JSDollarVM::finishCreation):
2966
2967 2019-03-04  Joseph Pecoraro  <pecoraro@apple.com>
2968
2969         ITMLKit Inspector: Data Bindings / Associated Data for nodes
2970         https://bugs.webkit.org/show_bug.cgi?id=195290
2971         <rdar://problem/48304019>
2972
2973         Reviewed by Devin Rousso.
2974
2975         * inspector/protocol/DOM.json:
2976
2977 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
2978
2979         [JSC] Make Reflect lazily-allocated by dropping @Reflect references from builtin JS
2980         https://bugs.webkit.org/show_bug.cgi?id=195250
2981
2982         Reviewed by Saam Barati.
2983
2984         By removing @Reflect from builtin JS, we can make Reflect object allocation lazy.
2985         We move @ownKeys function from @Reflect to @Object to remove @Reflect reference.
2986
2987         We also remove m_intlObject field from JSGlobalObject since we no longer use it.
2988
2989         * builtins/BuiltinNames.h:
2990         * builtins/GlobalOperations.js:
2991         (globalPrivate.copyDataProperties):
2992         (globalPrivate.copyDataPropertiesNoExclusions):
2993         * runtime/JSGlobalObject.cpp:
2994         (JSC::createReflectProperty):
2995         (JSC::JSGlobalObject::init):
2996         (JSC::JSGlobalObject::visitChildren):
2997         * runtime/JSGlobalObject.h:
2998         * runtime/ObjectConstructor.cpp:
2999         (JSC::ObjectConstructor::finishCreation):
3000         (JSC::objectConstructorOwnKeys):
3001         * runtime/ReflectObject.cpp:
3002         (JSC::ReflectObject::finishCreation):
3003
3004 2019-03-04  Yusuke Suzuki  <ysuzuki@apple.com>
3005
3006         [JSC] Offer @makeTypeError instead of exposing @TypeError
3007         https://bugs.webkit.org/show_bug.cgi?id=193858
3008
3009         Reviewed by Mark Lam.
3010
3011         Instead of exposing @TypeError, we expose @makeTypeError function.
3012         And we make TypeError and Error lazily-allocated objects in non JIT environment.
3013         In JIT environment, only TypeError becomes lazily-allocated since WebAssembly errors
3014         touch Error prototype anyway. But we can make them lazy in a subsequent patch.
3015
3016         * builtins/AsyncFromSyncIteratorPrototype.js:
3017         * builtins/AsyncGeneratorPrototype.js:
3018         (globalPrivate.asyncGeneratorEnqueue):
3019         * builtins/BuiltinNames.h:
3020         * builtins/PromiseOperations.js:
3021         (globalPrivate.createResolvingFunctions.resolve):
3022         * runtime/JSGlobalObject.cpp:
3023         (JSC::JSGlobalObject::initializeErrorConstructor):
3024         (JSC::JSGlobalObject::init):
3025         (JSC::JSGlobalObject::visitChildren):
3026         * runtime/JSGlobalObject.h:
3027         (JSC::JSGlobalObject::errorPrototype const):
3028         (JSC::JSGlobalObject::errorStructure const):
3029         * runtime/JSGlobalObjectFunctions.cpp:
3030         (JSC::globalFuncMakeTypeError):
3031         * runtime/JSGlobalObjectFunctions.h:
3032
3033 2019-03-04  Carlos Garcia Campos  <cgarcia@igalia.com>
3034
3035         [GLib] Returning G_TYPE_OBJECT from a constructor does not work
3036         https://bugs.webkit.org/show_bug.cgi?id=195206
3037
3038         Reviewed by Žan Doberšek.
3039
3040         We are freeing the newly created object before returning from the constructor.
3041
3042         * API/glib/JSCCallbackFunction.cpp:
3043         (JSC::JSCCallbackFunction::construct):
3044
3045 2019-03-02  Darin Adler  <darin@apple.com>
3046
3047         Retire legacy dtoa function and DecimalNumber class
3048         https://bugs.webkit.org/show_bug.cgi?id=195253
3049
3050         Reviewed by Daniel Bates.
3051
3052         * runtime/NumberPrototype.cpp:
3053         (JSC::numberProtoFuncToExponential): Removed dependency on NumberToStringBufferLength,
3054         using NumberToStringBuffer instead. Also tweaked style of implementation a bit.
3055
3056 2019-03-01  Darin Adler  <darin@apple.com>
3057
3058         Finish removing String::format
3059         https://bugs.webkit.org/show_bug.cgi?id=194893
3060
3061         Reviewed by Daniel Bates.
3062
3063         * bytecode/CodeBlock.cpp:
3064         (JSC::CodeBlock::nameForRegister): Use makeString instead of String::format,
3065         using the new "pad" function.
3066
3067 2019-03-01  Christopher Reid  <chris.reid@sony.com>
3068
3069         [PlayStation] Upstream playstation's remote inspector server
3070         https://bugs.webkit.org/show_bug.cgi?id=193806
3071
3072         Reviewed by Joseph Pecoraro.
3073
3074         Upstreaming PlayStation's Remote Inspector implementation.
3075         It is using a JSON RPC protocol over TCP sockets.
3076         This inspector implementation is planned to also support running on a WinCairo Client and Server.
3077
3078         * PlatformPlayStation.cmake:
3079         * SourcesGTK.txt:
3080         * SourcesWPE.txt:
3081         * inspector/remote/RemoteConnectionToTarget.cpp: Renamed from Source/JavaScriptCore/inspector/remote/glib/RemoteConnectionToTargetGlib.cpp.
3082         * inspector/remote/RemoteInspector.h:
3083         * inspector/remote/playstation/RemoteInspectorConnectionClient.h: Added.
3084         * inspector/remote/playstation/RemoteInspectorConnectionClientPlayStation.cpp: Added.
3085         * inspector/remote/playstation/RemoteInspectorMessageParser.h: Added.
3086         * inspector/remote/playstation/RemoteInspectorMessageParserPlayStation.cpp: Added.
3087         * inspector/remote/playstation/RemoteInspectorPlayStation.cpp: Added.
3088         * inspector/remote/playstation/RemoteInspectorServer.h: Added.
3089         * inspector/remote/playstation/RemoteInspectorServerPlayStation.cpp: Added.
3090         * inspector/remote/playstation/RemoteInspectorSocket.h: Added.
3091         * inspector/remote/playstation/RemoteInspectorSocketClient.h: Added.
3092         * inspector/remote/playstation/RemoteInspectorSocketClientPlayStation.cpp: Added.
3093         * inspector/remote/playstation/RemoteInspectorSocketPlayStation.cpp: Added.
3094         * inspector/remote/playstation/RemoteInspectorSocketServer.h: Added.
3095         * inspector/remote/playstation/RemoteInspectorSocketServerPlayStation.cpp: Added.
3096
3097 2019-03-01  Saam Barati  <sbarati@apple.com>
3098
3099         Create SPI to crash if a JSC VM is created
3100         https://bugs.webkit.org/show_bug.cgi?id=195231
3101         <rdar://problem/47717990>
3102
3103         Reviewed by Mark Lam.
3104
3105         * API/JSVirtualMachine.mm:
3106         (+[JSVirtualMachine setCrashOnVMCreation:]):
3107         * API/JSVirtualMachinePrivate.h:
3108         * runtime/VM.cpp:
3109         (JSC::VM::VM):
3110         (JSC::VM::setCrashOnVMCreation):
3111         * runtime/VM.h:
3112
3113 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
3114
3115         [JSC] Fix FTL build on ARM32_64 by adding stubs for JSRopeString::offsetOfXXX
3116         https://bugs.webkit.org/show_bug.cgi?id=195235
3117
3118         Reviewed by Saam Barati.
3119
3120         This is a workaround until https://bugs.webkit.org/show_bug.cgi?id=195234 is done.
3121
3122         * runtime/JSString.h:
3123
3124 2019-03-01  Yusuke Suzuki  <ysuzuki@apple.com>
3125
3126         [JSC] Use runtime calls for DFG MakeRope if !CPU(ADDRESS64)
3127         https://bugs.webkit.org/show_bug.cgi?id=195221
3128
3129         Reviewed by Mark Lam.
3130
3131         ARM32_64 builds DFG 64bit, but the size of address is 32bit. Make DFG MakeRope a runtime call not only for DFG 32_64,
3132         but also DFG 64 with !CPU(ADDRESS64). This patch unifies compileMakeRope again, and use a runtime call for !CPU(ADDRESS64).
3133
3134         * dfg/DFGSpeculativeJIT.cpp:
3135         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3136         * dfg/DFGSpeculativeJIT32_64.cpp:
3137         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
3138         * dfg/DFGSpeculativeJIT64.cpp:
3139         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
3140
3141 2019-03-01  Justin Fan  <justin_fan@apple.com>
3142
3143         [Web GPU] 32-bit builds broken by attempt to disable WebGPU on 32-bit
3144         https://bugs.webkit.org/show_bug.cgi?id=195191
3145
3146         Rubber-stamped by Dean Jackson.
3147
3148         Dropping support for 32-bit entirely, so I'm intentionally leaving 32-bit broken.
3149
3150         * Configurations/FeatureDefines.xcconfig:
3151
3152 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
3153
3154         Fix debug builds with GCC
3155         https://bugs.webkit.org/show_bug.cgi?id=195205
3156
3157         Unreviewed. Fix debug builds in GCC by removing
3158         the constexpr-keyword for this function.
3159
3160         * runtime/CachedTypes.cpp:
3161         (JSC::tagFromSourceCodeType):
3162
3163 2019-03-01  Dominik Infuehr  <dinfuehr@igalia.com>
3164
3165         [ARM] Fix assembler warnings in ctiMasmProbeTrampoline
3166         https://bugs.webkit.org/show_bug.cgi?id=195164
3167
3168         Reviewed by Mark Lam.
3169
3170         Short branches in IT blocks are deprecated in AArch32. In addition the
3171         the conditional branch was the only instruction in the IT block. Short
3172         branches are able to encode the condition code themselves, the additional
3173         IT instruction is not needed.
3174
3175         The assembler was also warning that writing into APSR without a bitmask
3176         was deprecated. Therefore use APSR_nzcvq instead, this generates the same
3177         instruction encoding.
3178
3179         * assembler/MacroAssemblerARMv7.cpp:
3180
3181 2019-02-28  Tadeu Zagallo  <tzagallo@apple.com>
3182
3183         Remove CachedPtr::m_isEmpty and CachedOptional::m_isEmpty fields
3184         https://bugs.webkit.org/show_bug.cgi?id=194999
3185
3186         Reviewed by Saam Barati.
3187
3188         These fields are unnecessary, since we can just check that m_offset
3189         has not been initialized (I added VariableLengthObject::isEmpty for
3190         that). They also add 7-byte padding to these classes, which is pretty
3191         bad given how frequently CachedPtr is used.
3192
3193         * runtime/CachedTypes.cpp:
3194         (JSC::CachedObject::operator new[]):
3195         (JSC::VariableLengthObject::allocate):
3196         (JSC::VariableLengthObject::isEmpty const):
3197         (JSC::CachedPtr::encode):
3198         (JSC::CachedPtr::decode const):
3199         (JSC::CachedPtr::get const):
3200         (JSC::CachedOptional::encode):
3201         (JSC::CachedOptional::decode const):
3202         (JSC::CachedOptional::decodeAsPtr const):
3203
3204 2019-02-28  Yusuke Suzuki  <ysuzuki@apple.com>
3205
3206         [JSC] sizeof(JSString) should be 16
3207         https://bugs.webkit.org/show_bug.cgi?id=194375
3208
3209         Reviewed by Saam Barati.
3210
3211         This patch reduces sizeof(JSString) from 24 to 16 to fit it into GC heap cell atom. And it also reduces sizeof(JSRopeString) from 48 to 32.
3212         Both classes cut 16 bytes per instance in GC allocation. This new layout is used in 64bit architectures which has little endianess.
3213
3214         JSString no longer has length and flags directly. JSString has String, and we query information to this String instead of holding duplicate
3215         information in JSString. We embed isRope bit into this String's pointer so that we can convert JSRopeString to JSString in an atomic manner.
3216         We emit store-store fence before we put String pointer. This should exist even before this patch, so this patch also fixes one concurrency issue.
3217
3218         The old JSRopeString separately had JSString* fibers along with String. In this patch, we merge the first JSString* fiber and String pointer
3219         storage into one to reduce the size of JSRopeString. JSRopeString has three pointer width storage. We pick 48bit effective address of JSString*
3220         fibers to compress three fibers + length + flags into three pointer width storage.
3221
3222         In 64bit architecture, JSString and JSRopeString have the following memory layout to make sizeof(JSString) == 16 and sizeof(JSRopeString) == 32.
3223         JSString has only one pointer. We use it for String. length() and is8Bit() queries go to StringImpl. In JSRopeString, we reuse the above pointer
3224         place for the 1st fiber. JSRopeString has three fibers so its size is 48. To keep length and is8Bit flag information in JSRopeString, JSRopeString
3225         encodes these information into the fiber pointers. is8Bit flag is encoded in the 1st fiber pointer. length is embedded directly, and two fibers
3226         are compressed into 12bytes. isRope information is encoded in the first fiber's LSB.
3227
3228         Since length of JSRopeString should be frequently accessed compared to each fiber, we put length in contiguous 32byte field, and compress 2nd
3229         and 3rd fibers into the following 80byte fields. One problem is that now 2nd and 3rd fibers are split. Storing and loading 2nd and 3rd fibers
3230         are not one pointer load operation. To make concurrent collector work correctly, we must initialize 2nd and 3rd fibers at JSRopeString creation
3231         and we must not modify these part later.
3232
3233                      0                        8        10               16                       32                                     48
3234         JSString     [   ID      ][  header  ][   String pointer      0]
3235         JSRopeString [   ID      ][  header  ][ flags ][ 1st fiber    1][  length  ][2nd lower32][2nd upper16][3rd lower16][3rd upper32]
3236                                                                       ^
3237                                                                    isRope bit
3238
3239         Since fibers in JSRopeString are not initialized in atomic pointer store manner, we must initialize all the fiber fields at JSRopeString creation.
3240         To achieve this, we modify our JSRopeString::RopeBuilder implementation not to create half-baked JSRopeString.
3241
3242         This patch also makes an empty JSString singleton per VM. This makes evaluation of JSString in boolean context one pointer comparison. This is
3243         critical in this change since this patch enlarges the code necessary to get length from JSString in JIT. Without this guarantee, our code of boolean
3244         context evaluation is bloated. This patch hides all the JSString::create and JSRopeString::create in the private permission. JSString and JSRopeString
3245         creation is only allowed from jsString and related helper functions and they return a singleton empty JSString if the length is zero. We also change
3246         JSRopeString::RopeBuilder not to construct an empty JSRopeString.
3247
3248         This patch is performance neutral in Speedometer2 and JetStream2. And it improves RAMification by 2.7%.
3249
3250         * JavaScriptCore.xcodeproj/project.pbxproj:
3251         * assembler/MacroAssemblerARM64.h:
3252         (JSC::MacroAssemblerARM64::storeZero16):
3253         * assembler/MacroAssemblerX86Common.h:
3254         (JSC::MacroAssemblerX86Common::storeZero16):
3255         (JSC::MacroAssemblerX86Common::store16):
3256         * bytecode/AccessCase.cpp:
3257         (JSC::AccessCase::generateImpl):
3258         * bytecode/InlineAccess.cpp:
3259         (JSC::InlineAccess::dumpCacheSizesAndCrash):
3260         (JSC::linkCodeInline):
3261         (JSC::InlineAccess::isCacheableStringLength):
3262         (JSC::InlineAccess::generateStringLength):
3263         * bytecode/InlineAccess.h:
3264         (JSC::InlineAccess::sizeForPropertyAccess):
3265         (JSC::InlineAccess::sizeForPropertyReplace):
3266         (JSC::InlineAccess::sizeForLengthAccess):
3267         * dfg/DFGOperations.cpp:
3268         * dfg/DFGOperations.h:
3269         * dfg/DFGSpeculativeJIT.cpp:
3270         (JSC::DFG::SpeculativeJIT::compileStringSlice):
3271         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
3272         (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):
3273         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
3274         (JSC::DFG::SpeculativeJIT::compileStringEquality):
3275         (JSC::DFG::SpeculativeJIT::compileStringZeroLength):
3276         (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther):
3277         (JSC::DFG::SpeculativeJIT::emitStringBranch):
3278         (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch):
3279         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
3280         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
3281         (JSC::DFG::SpeculativeJIT::emitPopulateSliceIndex):
3282         (JSC::DFG::SpeculativeJIT::compileArraySlice):
3283         (JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
3284         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
3285         (JSC::DFG::SpeculativeJIT::emitSwitchCharStringJump):
3286         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
3287         (JSC::DFG::SpeculativeJIT::compileMakeRope): Deleted.
3288         * dfg/DFGSpeculativeJIT.h:
3289         * dfg/DFGSpeculativeJIT32_64.cpp:
3290         (JSC::DFG::SpeculativeJIT::compile):
3291         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3292         * dfg/DFGSpeculativeJIT64.cpp:
3293         (JSC::DFG::SpeculativeJIT::compile):
3294         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3295         * ftl/FTLAbstractHeapRepository.cpp:
3296         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
3297         * ftl/FTLAbstractHeapRepository.h:
3298         * ftl/FTLLowerDFGToB3.cpp:
3299         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
3300         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
3301         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
3302         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
3303         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
3304         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
3305         (JSC::FTL::DFG::LowerDFGToB3::compileStringToUntypedStrictEquality):
3306         (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
3307         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
3308         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
3309         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
3310         (JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
3311         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
3312         (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
3313         (JSC::FTL::DFG::LowerDFGToB3::boolify):
3314         (JSC::FTL::DFG::LowerDFGToB3::switchString):
3315         (JSC::FTL::DFG::LowerDFGToB3::isRopeString):