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