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