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