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