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