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