ChangeLog-2017-03-23 [plain text]
2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] MachineThreads does not consider situation that one thread has multiple VMs
https://bugs.webkit.org/show_bug.cgi?id=169819
Reviewed by Mark Lam.
The Linux port of PlatformThread suspend/resume mechanism relies on having a thread
specific singleton thread data, and was relying on MachineThreads::Thread to be this
thread specific singleton. But because MachineThreads::Thread is not a thread specific
singleton, we can get a deadlock in the GTK port's DatabaseProcess.
This patch fixes this issue by moving per thread data from MachineThreads::Thread to
MachineThreads::ThreadData, where there will only be one instance of
MachineThreads::ThreadData per thread. Each MachineThreads::Thread will now point to
the same MachineThreads::ThreadData for any given thread.
* heap/MachineStackMarker.cpp:
(pthreadSignalHandlerSuspendResume):
(JSC::threadData):
(JSC::MachineThreads::Thread::Thread):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::Thread::operator==):
(JSC::MachineThreads::ThreadData::ThreadData):
(JSC::MachineThreads::ThreadData::~ThreadData):
(JSC::MachineThreads::ThreadData::suspend):
(JSC::MachineThreads::ThreadData::resume):
(JSC::MachineThreads::ThreadData::getRegisters):
(JSC::MachineThreads::ThreadData::Registers::stackPointer):
(JSC::MachineThreads::ThreadData::Registers::framePointer):
(JSC::MachineThreads::ThreadData::Registers::instructionPointer):
(JSC::MachineThreads::ThreadData::Registers::llintPC):
(JSC::MachineThreads::ThreadData::freeRegisters):
(JSC::MachineThreads::ThreadData::captureStack):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::MachineThreads::Thread::~Thread): Deleted.
(JSC::MachineThreads::Thread::suspend): Deleted.
(JSC::MachineThreads::Thread::resume): Deleted.
(JSC::MachineThreads::Thread::getRegisters): Deleted.
(JSC::MachineThreads::Thread::Registers::stackPointer): Deleted.
(JSC::MachineThreads::Thread::Registers::framePointer): Deleted.
(JSC::MachineThreads::Thread::Registers::instructionPointer): Deleted.
(JSC::MachineThreads::Thread::Registers::llintPC): Deleted.
(JSC::MachineThreads::Thread::freeRegisters): Deleted.
(JSC::MachineThreads::Thread::captureStack): Deleted.
* heap/MachineStackMarker.h:
(JSC::MachineThreads::Thread::operator!=):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::Thread::resume):
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::freeRegisters):
(JSC::MachineThreads::Thread::captureStack):
(JSC::MachineThreads::Thread::platformThread):
(JSC::MachineThreads::Thread::stackBase):
(JSC::MachineThreads::Thread::stackEnd):
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::isValidFramePointer):
* runtime/VMTraps.cpp:
(JSC::findActiveVMAndStackBounds):
2017-03-23 Mark Lam <mark.lam@apple.com>
Clients of JSArray::tryCreateForInitializationPrivate() should do their own null checks.
https://bugs.webkit.org/show_bug.cgi?id=169783
Reviewed by Saam Barati.
Fixed clients of tryCreateForInitializationPrivate() to do a null check and throw
an OutOfMemoryError if allocation fails, or RELEASE_ASSERT that the allocation
succeeds.
* dfg/DFGOperations.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateForInitializationPrivate):
(JSC::JSArray::fastSlice):
* runtime/JSArray.h:
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/RegExpMatchesArray.cpp:
(JSC::createEmptyRegExpMatchesArray):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
2017-03-23 Guillaume Emont <guijemont@igalia.com>
[jsc] Add MacroAssemblerMIPS::storeFence()
https://bugs.webkit.org/show_bug.cgi?id=169705
Reviewed by Yusuke Suzuki.
There doesn't seem to be anything more fine grained than "sync" that
guarantees that all memory operations following it are going to happen
after all stores before it, so we just use sync.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::sync): Added a FIXME about SYNC_MB.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::storeFence): Added.
2017-03-22 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][DFG] Propagate AnyIntAsDouble information carefully to utilize it in fixup
https://bugs.webkit.org/show_bug.cgi?id=169914
Reviewed by Saam Barati.
In DFG prediction propagation phase, we pollute the prediction of GetByVal for Array::Double
as SpecDoubleReal even if the heap prediction says the proper prediction is SpecAnyIntAsDouble.
Thus, the following nodes just see the result of GetByVal(Array::Double) as double value,
and select suboptimal edge filters in fixup phase. For example, if the result of GetByVal is
SpecAnyIntAsDouble, we can see the node like ArithAdd(SpecAnyIntAsDouble, Int52) and we should
have a chance to make it ArithAdd(Check:Int52, Int52) instead of ArithAdd(Double, Double).
This patch propagates SpecAnyIntAsDouble in GetByVal(Array::Double) properly. And ValueAdd,
ArithAdd and ArithSub select AnyInt edge filters for SpecAnyIntAsDouble values. It finally
produces a Int52 specialized DFG node. And subsequent nodes using the produced one also
become Int52 specialized.
One considerable problem is that the heap prediction misses the non any int doubles. In that case,
if Int52 edge filter is used, BadType exit will occur. It updates the prediction of the value profile
of GetByVal. So, in the next time, GetByVal(Array::Double) produces more conservative predictions
and avoids exit-and-recompile loop correctly.
This change is very sensitive to the correct AI and appropriate predictions. Thus, this patch finds
and fixes some related issues. One is incorrect prediction of ToThis and another is incorrect
AI logic for Int52Rep.
This change dramatically improves kraken benchmarks' crypto-pbkdf2 and crypto-sha256-iterative
by 42.0% and 30.7%, respectively.
baseline patched
Kraken:
ai-astar 158.851+-4.132 ? 159.433+-5.176 ?
audio-beat-detection 53.193+-1.621 ? 53.391+-2.072 ?
audio-dft 103.589+-2.277 ? 104.902+-1.924 ? might be 1.0127x slower
audio-fft 40.491+-1.102 39.854+-0.755 might be 1.0160x faster
audio-oscillator 68.504+-1.721 ? 68.957+-1.725 ?
imaging-darkroom 118.367+-2.171 ? 119.581+-2.310 ? might be 1.0103x slower
imaging-desaturate 71.443+-1.461 ? 72.398+-1.918 ? might be 1.0134x slower
imaging-gaussian-blur 110.648+-4.035 109.184+-3.373 might be 1.0134x faster
json-parse-financial 60.363+-1.628 ? 61.936+-1.585 ? might be 1.0261x slower
json-stringify-tinderbox 37.903+-0.869 ? 39.559+-1.607 ? might be 1.0437x slower
stanford-crypto-aes 56.313+-1.512 ? 56.675+-1.715 ?
stanford-crypto-ccm 51.564+-1.900 ? 53.456+-2.548 ? might be 1.0367x slower
stanford-crypto-pbkdf2 129.546+-2.738 ^ 91.214+-2.027 ^ definitely 1.4202x faster
stanford-crypto-sha256-iterative 43.515+-0.730 ^ 33.292+-0.653 ^ definitely 1.3071x faster
<arithmetic> 78.878+-0.528 ^ 75.988+-0.621 ^ definitely 1.0380x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::addShouldSpeculateAnyInt):
* dfg/DFGPredictionPropagationPhase.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
2017-03-22 Mark Lam <mark.lam@apple.com>
Add support for Error.stackTraceLimit.
https://bugs.webkit.org/show_bug.cgi?id=169904
Reviewed by Saam Barati.
Since there's no standard for this yet, we'll implement Error.stackTraceLimit
based on how Chrome does it. This includes some idiosyncrasies like:
1. If we set Error.stackTraceLimit = 0, then new Error().stack yields an empty
stack trace (Chrome has a title with no stack frame entries).
2. If we set Error.stackTraceLimit = {] (i.e. to a non-number value), then
new Error().stack is undefined.
Chrome and IE defaults their Error.stackTraceLimit to 10. We'll default ours to
100 because 10 may be a bit too skimpy and it is not that costly to allow up to
100 frames instead of 10.
The default value for Error.stackTraceLimit is specified by
Options::defaultErrorStackTraceLimit().
Also, the Exception object now limits the number of stack trace frames it captures
to the limit specified by Options::exceptionStackTraceLimit().
Note: the Exception object captures a stack trace that is not necessarily the
same as the one in an Error object being thrown:
- The Error object captures the stack trace at the point of object creation.
- The Exception object captures the stack trace at the point that the exception
is thrown. This stack trace is captured even when throwing a value that is not
an Error object e.g. a primitive value. The Exception object stack trace is
only used by WebInspector to identify where a value is thrown from. Hence,
it does not necessary make sense the Exception object stack trace limited by
Error.stackTraceLimit. Instead, we have it use own Options::exceptionStackTraceLimit().
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
* jsc.cpp:
(dumpException):
* runtime/CommonIdentifiers.h:
* runtime/Error.cpp:
(JSC::addErrorInfoAndGetBytecodeOffset):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
(JSC::ErrorConstructor::put):
(JSC::ErrorConstructor::deleteProperty):
* runtime/ErrorConstructor.h:
(JSC::ErrorConstructor::stackTraceLimit):
* runtime/Exception.cpp:
(JSC::Exception::finishCreation):
* runtime/Options.h:
2017-03-22 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Use jsNontrivialString for Number toString operations
https://bugs.webkit.org/show_bug.cgi?id=169965
Reviewed by Mark Lam.
After single character check, produced string is always longer than 1.
Thus, we can use jsNontrivialString.
* runtime/NumberPrototype.cpp:
(JSC::int32ToStringInternal):
2017-03-22 JF Bastien <jfbastien@apple.com>
WebAssembly: name ExecState consistently
https://bugs.webkit.org/show_bug.cgi?id=169954
Reviewed by Saam Barati.
No functional change.
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::JSWebAssemblyCompileError::create):
(JSC::createJSWebAssemblyCompileError):
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::JSWebAssemblyLinkError::create):
(JSC::createJSWebAssemblyLinkError):
* wasm/js/JSWebAssemblyLinkError.h:
(JSC::JSWebAssemblyLinkError::create):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::JSWebAssemblyRuntimeError::create):
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::callJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::callJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::callJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::dataSegmentFail):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyPrototype.cpp:
(JSC::webAssemblyFunctionValidate):
(JSC::webAssemblyFunctionCompile):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::callJSWebAssemblyTable):
2017-03-22 JF Bastien <jfbastien@apple.com>
WebAssembly: constructors without new don't throw
https://bugs.webkit.org/show_bug.cgi?id=165995
Reviewed by Saam Barati.
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
(JSC::callJSWebAssemblyCompileError):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::constructJSWebAssemblyLinkError):
(JSC::callJSWebAssemblyLinkError):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
(JSC::callJSWebAssemblyRuntimeError):
2017-03-22 Guillaume Emont <guijemont@igalia.com>
[DFG] Don't use ArraySlice intrinsic on MIPS
https://bugs.webkit.org/show_bug.cgi?id=169721
Reviewed by Yusuke Suzuki.
Like on x86, we don't have enough registers available for this.
* assembler/CPU.h:
(JSC::isMIPS): Added.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
Don't use the ArraySlice intrinsic on MIPS.
2017-03-21 Mark Lam <mark.lam@apple.com>
The DFG Integer Check Combining phase should force an OSR exit for CheckInBounds on a negative constant min bound.
https://bugs.webkit.org/show_bug.cgi?id=169933
<rdar://problem/31105125>
Reviewed by Filip Pizlo and Geoffrey Garen.
Also fixed the bit-rotted RangeKey::dump() function.
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
2017-03-21 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Add missing MacroAssembler functions after r214187
https://bugs.webkit.org/show_bug.cgi?id=169912
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::loadFloat):
(JSC::MacroAssemblerARM::storeFloat):
2017-03-21 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Optimize Number.prototype.toString on Int32 / Int52 / Double
https://bugs.webkit.org/show_bug.cgi?id=167454
Reviewed by Saam Barati.
This patch improves Number.toString(radix) performance
by introducing NumberToStringWithRadix DFG node. It directly
calls the operation and it always returns String.
baseline patched
stanford-crypto-sha256-iterative 45.130+-0.928 44.032+-1.184 might be 1.0250x faster
2017-03-21 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add JSPromiseDeferred::reject(ExecState*, Exception*) interface
https://bugs.webkit.org/show_bug.cgi?id=169908
Reviewed by Sam Weinig.
To avoid calling reject(ExecState*, JSValue) with Exception* accidentally,
we add a new interface reject(ExecState*, Exception*).
Such an interface is already added in DOMPromise in WebCore.
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::reject):
* runtime/JSInternalPromiseDeferred.h:
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::reject):
* runtime/JSPromiseDeferred.h:
2017-03-21 Zan Dobersek <zdobersek@igalia.com>
[jsc] MacroAssemblerMIPS: implement the branchPtr(RelationalCondition, BaseIndex, RegisterID) overload.
https://bugs.webkit.org/show_bug.cgi?id=169717
Reviewed by Yusuke Suzuki.
* assembler/MacroAssembler.h: Expose branchPtr() on MIPS as well.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchPtr): Added.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructor):
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnNumber):
(JSC::DFG::SpeculativeJIT::compileNumberToStringWithRadix):
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell): Deleted.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileNumberToStringWithRadix):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/JITOperations.h:
* runtime/Intrinsic.h:
* runtime/NumberPrototype.cpp:
(JSC::int52ToStringWithRadix):
(JSC::int32ToStringInternal):
(JSC::numberToStringInternal):
(JSC::int32ToString):
(JSC::int52ToString):
(JSC::numberToString):
(JSC::numberProtoFuncToString):
(JSC::integerValueToString): Deleted.
* runtime/NumberPrototype.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2017-03-20 Filip Pizlo <fpizlo@apple.com>
Graph coloring should use coalescable moves when spilling
https://bugs.webkit.org/show_bug.cgi?id=169820
Reviewed by Michael Saboff.
This makes our graph coloring register allocator use a new family of move instructions when
spilling both operands of the move. It's a three-operand move:
Move (src), (dst), %scratch
Previously, if both operands got spilled, we would emit a new instruction to load or store that
spill slot. But this made it hard for allocateStack to see that the two spill locations are
coalescable. This new kind of instruction makes it obvious that it's a coalescable move.
This change implements the coalescing of spill slots inside allocateStack.
This is an outrageous speed-up on the tsf_ir_speed benchmark from http://filpizlo.com/tsf/. This
is an interesting benchmark because it has a super ugly interpreter loop with ~20 live variables
carried around the loop back edge. This change makes that interpreter run 5x faster.
This isn't a speed-up on any other benchmarks. It also doesn't regress anything. Compile time is
neither progressed or regressed, since the coalescing is super cheap, and this does not add any
significant new machinery to the register allocator (it's just a small change to spill codegen).
Overall on our wasm benchmarks, this is a 16% throughput progression.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::move):
(JSC::MacroAssembler::move32):
(JSC::MacroAssembler::moveFloat):
(JSC::MacroAssembler::moveDouble):
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::allocateRegistersByGraphColoring):
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::hasEarlyDef):
(JSC::B3::Air::Inst::hasLateUseOrDef):
(JSC::B3::Air::Inst::needsPadding):
* b3/air/AirInst.h:
* b3/air/AirOpcode.opcodes:
* b3/air/AirPadInterference.cpp:
(JSC::B3::Air::padInterference):
* runtime/Options.h:
2017-03-19 Chris Dumez <cdumez@apple.com>
`const location = "foo"` throws in a worker
https://bugs.webkit.org/show_bug.cgi?id=169839
Reviewed by Mark Lam.
Our HasRestrictedGlobalProperty check in JSC was slightly wrong, causing us
to sometimes throw a Syntax exception when we shouldn't when declaring a
const/let variable and sometimes not throw an exception when we should have.
This aligns our behavior with ES6, Firefox and Chrome.
* runtime/ProgramExecutable.cpp:
(JSC::hasRestrictedGlobalProperty):
(JSC::ProgramExecutable::initializeGlobalProperties):
Rewrite hasRestrictedGlobalProperty logic as per the EcmaScript spec:
- http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasproperty
In particular, they were 2 issues:
- We should throw a SyntaxError if hasProperty() returned true but getOwnProperty()
would fail to return a descriptor. This would happen for properties that are
not OWN properties, but defined somewhere in the prototype chain. The spec does
not say to use hasProperty(), only getOwnProperty() and says we should return
false if getOwnProperty() does not return a descriptor. This is what we do now.
- We would fail to throw when declaring a let/const variable that shadows an own
property whose value is undefined. This is because the previous code was
explicitly checking for this case. I believe this was a misinterpretation of
ES6 which says:
"""
Let desc be O.[[GetOwnProperty]](P).
If desc is undefined, return false.
"""
We should check that desc is undefined, not desc.value. This is now fixed.
2017-03-19 Yusuke Suzuki <utatane.tea@gmail.com>
import(arg) crashes when ToString(arg) throws
https://bugs.webkit.org/show_bug.cgi?id=169778
Reviewed by Saam Barati.
JSPromiseDeferred should not be rejected with Exception*.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
2017-03-18 Oleksandr Skachkov <gskachkov@gmail.com>
[JSC] Remove unnecessary condition from needsDerivedConstructorInArrowFunctionLexicalEnvironment in BytecodeGenerator.cpp
https://bugs.webkit.org/show_bug.cgi?id=169832
Reviewed by Mark Lam.
Remove already covered condition in needsDerivedConstructorInArrowFunctionLexicalEnvironment
function. Condition isConstructor() && constructorKind() == ConstructorKind::Extends is already
isClassContext.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::needsDerivedConstructorInArrowFunctionLexicalEnvironment):
2017-03-18 Chris Dumez <cdumez@apple.com>
Allow setting the prototype of cross-origin objects, as long as they don't change
https://bugs.webkit.org/show_bug.cgi?id=169787
Reviewed by Mark Lam.
* runtime/JSGlobalObject.h:
Mark JS global object as an immutable prototype exotic object to match Window.
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeWithCycleCheck):
Update setPrototypeWithCycleCheck() for immutable prototype exotic objects in order
to align with:
- https://tc39.github.io/ecma262/#sec-set-immutable-prototype
In particular, we need to call [[GetPrototypeOf]] and return true if it returns the same
value as the new prototype. We really need to call [[GetPrototypeOf]] and not merely
getting the prototype slot via getPrototypeDirect() since Location and Window override
[[GetPrototypeOf]] to return null in the cross-origin case.
* runtime/JSProxy.cpp:
(JSC::JSProxy::setPrototype):
Update JSProxy::setPrototype() to forward such calls to its target. This is needed so
we end up calling JSObject::setPrototypeWithCycleCheck() for the Window object.
Handling immutable prototype exotic objects in that method does the right thing for
Window.
2017-03-17 Michael Saboff <msaboff@apple.com>
Use USE_INTERNAL_SDK to compute ENABLE_FAST_JIT_PERMISSIONS instead of HAVE_INTERNAL_SDK
https://bugs.webkit.org/show_bug.cgi?id=169817
Reviewed by Filip Pizlo.
* Configurations/FeatureDefines.xcconfig:
2017-03-11 Filip Pizlo <fpizlo@apple.com>
Air should be powerful enough to support Tmp-splitting
https://bugs.webkit.org/show_bug.cgi?id=169515
Reviewed by Saam Barati.
In the process of implementing the Tmp-splitting optimization, I made some small
clean-ups. They don't affect anything - it's basically moving code around and adding
utility functions.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::allocate): testb3 was sometimes failing its checkDoesNotUseInstruction check because of uninitialized memory. This initializes the internal fragmentation slop of every JIT allocation.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirAllocateRegistersByGraphColoring.h:
(JSC::B3::Air::useIRC): It's useful to be able to query which register allocator we're using.
* b3/air/AirArg.cpp:
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::temperature): The temperature of a role is a useful concept to have factored out.
* b3/air/AirBreakCriticalEdges.cpp: Added.
(JSC::B3::Air::breakCriticalEdges): I was surprised that we didn't have this already. It's a pretty fundamental CFG utility.
* b3/air/AirBreakCriticalEdges.h: Added.
* b3/air/AirGenerate.cpp:
* b3/air/AirInsertionSet.h: You can't use & if you want copy-constructibility, which seems to be a prerequisite to IndexMap<BasicBlock, InsertionSet>.
(JSC::B3::Air::InsertionSet::InsertionSet):
(JSC::B3::Air::InsertionSet::code):
* b3/air/AirLiveness.h: Teach Liveness to track only warm liveness.
(JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
(JSC::B3::Air::RegLivenessAdapter::acceptsRole):
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
2017-03-16 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in GenericArgumentsInlines.h.
https://bugs.webkit.org/show_bug.cgi?id=165012
Reviewed by Saam Barati.
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::defineOwnProperty):
2017-03-16 Simon Fraser <simon.fraser@apple.com>
Improve the system tracing points
https://bugs.webkit.org/show_bug.cgi?id=169790
Reviewed by Zalan Bujtas.
Use a more cohesive set of system trace points that give a good overview of what
WebKit is doing. Added points for resource loading, render tree building, sync messages
to the web process, async image decode, WASM and fetching cookies.
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
2017-03-16 Mark Lam <mark.lam@apple.com>
Array concat operation should check for length overflows.
https://bugs.webkit.org/show_bug.cgi?id=169796
<rdar://problem/31095276>
Reviewed by Keith Miller.
* runtime/ArrayPrototype.cpp:
(JSC::concatAppendOne):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
2017-03-16 Mark Lam <mark.lam@apple.com>
The new array with spread operation needs to check for length overflows.
https://bugs.webkit.org/show_bug.cgi?id=169780
<rdar://problem/31072182>
Reviewed by Filip Pizlo.
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* llint/LLIntSlowPaths.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSGlobalObject.cpp:
2017-03-16 Filip Pizlo <fpizlo@apple.com>
FTL should support global and eval code
https://bugs.webkit.org/show_bug.cgi?id=169656
Reviewed by Geoffrey Garen and Saam Barati.
Turned off the restriction against global and eval code running in the FTL, and then fixed all of
the things that didn't work.
This is a big speed-up on microbenchmarks that I wrote for this patch. One of the reasons why we
hadn't done this earlier is that we've never seen a benchmark that needed it. Global and eval
code rarely gets FTL-hot. Still, this seems like possibly a small JetStream speed-up.
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::setOSREntryBlock): I outlined this for better debugging.
* dfg/DFGJITCode.h:
(JSC::DFG::JITCode::setOSREntryBlock): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::isSemanticallySkippable): It turns out that global code often has InvalidationPoints before LoopHints. They are also skippable from the standpoint of OSR entrypoint analysis.
* dfg/DFGOperations.cpp: Don't do any normal compiles of global code - just do OSR compiles.
* ftl/FTLCapabilities.cpp: Enable FTL for global and eval code.
(JSC::FTL::canCompile):
* ftl/FTLCompile.cpp: Just debugging clean-ups.
(JSC::FTL::compile):
* ftl/FTLJITFinalizer.cpp: Implement finalize() and ensure that we only do things with the entrypoint buffer if we have one. We won't have one for eval code that we aren't OSR entering into.
(JSC::FTL::JITFinalizer::finalize):
(JSC::FTL::JITFinalizer::finalizeFunction):
(JSC::FTL::JITFinalizer::finalizeCommon):
* ftl/FTLJITFinalizer.h:
* ftl/FTLLink.cpp: When entering a function normally, we need the "entrypoint" to put the arity check code. Global and eval code don't need this.
(JSC::FTL::link):
* ftl/FTLOSREntry.cpp: Fix a dataLog statement.
(JSC::FTL::prepareOSREntry):
* ftl/FTLOSRExitCompiler.cpp: Remove dead code that happened to assert that we're exiting from a function.
(JSC::FTL::compileStub):
2017-03-16 Michael Saboff <msaboff@apple.com>
WebAssembly: function-tests/load-offset.js fails on ARM64
https://bugs.webkit.org/show_bug.cgi?id=169724
Reviewed by Keith Miller.
We need to use the two source version of Add64 to create a Wasm address with the
other source the first child.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
2017-03-16 Jon Lee <jonlee@apple.com>
Add FIXMEs to update WebRTC
https://bugs.webkit.org/show_bug.cgi?id=169735
Reviewed by Youenn Fablet.
* runtime/CommonIdentifiers.h: Add RTCIceTransport.
2017-03-16 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, copy m_numberOfArgumentsToSkip
https://bugs.webkit.org/show_bug.cgi?id=164582
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
2017-03-16 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, fix numParameter() - 1 OSRExit materialization
https://bugs.webkit.org/show_bug.cgi?id=164582
When materializing rest parameters, we rely on that numParameter() - 1 equals to
the numberOfArgumentsToSkip. But this assumption is broken in r214029.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArgumentsToSkip):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2017-03-16 Caio Lima <ticaiolima@gmail.com>
[ESnext] Implement Object Spread
https://bugs.webkit.org/show_bug.cgi?id=167963
Reviewed by Yusuke Suzuki.
This patch implements ECMA262 stage 3 Object Spread proposal [1].
It's implemented using CopyDataProperties to copy all enumerable keys
from object being spreaded.
It's also fixing CopyDataProperties that was using
Object.getOwnPropertyNames to list all keys to be copied, and now is
using Relect.ownKeys.
[1] - https://github.com/sebmarkbage/ecmascript-rest-spread
* builtins/GlobalOperations.js:
(globalPrivate.copyDataProperties):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
(JSC::ObjectPatternNode::bindValue):
(JSC::ObjectSpreadExpressionNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createObjectSpreadExpression):
(JSC::ASTBuilder::createProperty):
* parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
(JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode):
* parser/Nodes.h:
(JSC::ObjectSpreadExpressionNode::expression):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createObjectSpreadExpression):
(JSC::SyntaxChecker::createProperty):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::privateToObject): Deleted.
* runtime/JSGlobalObjectFunctions.h:
2017-03-15 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Default parameter part should be retrieved by op_get_argument opcode instead of changing arity
https://bugs.webkit.org/show_bug.cgi?id=164582
Reviewed by Saam Barati.
Previously we implement the default parameters as follows.
1. We count the default parameters as the usual parameters.
2. We just get the argument register.
3. Check it with op_is_undefined.
4. And fill the binding with either the argument register or default value.
The above is simple. However, it has the side effect that it always increase the arity of the function.
While `function.length` does not increase, internally, the number of parameters of CodeBlock increases.
This effectively prevent our DFG / FTL to perform inlining: currently we only allows DFG to inline
the function with the arity less than or equal the number of passing arguments. It is OK. But when using
default parameters, we frequently do not pass the argument for the parameter with the default value.
Thus, in our current implementation, we frequently need to fixup the arity. And we frequently fail
to inline the function.
This patch fixes the above problem by not increasing the arity of the function. When we encounter the
parameter with the default value, we use `op_argument` to get the argument instead of using the argument
registers.
This improves six-speed defaults.es6 performance by 4.45x.
defaults.es6 968.4126+-101.2350 ^ 217.6602+-14.8831 ^ definitely 4.4492x faster
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::initializeNextParameter):
(JSC::BytecodeGenerator::initializeParameters):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inliningCost):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createFunctionMetadata):
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
(JSC::FunctionParameters::size):
(JSC::FunctionParameters::at):
(JSC::FunctionParameters::append):
(JSC::FunctionParameters::isSimpleParameterList):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createFunctionMetadata):
* runtime/FunctionExecutable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::createBuiltinFunction):
(JSC::JSFunction::reifyLength):
2017-03-15 Yusuke Suzuki <utatane.tea@gmail.com>
[DFG] ToString operation should have fixup for primitives to say this node does not have side effects
https://bugs.webkit.org/show_bug.cgi?id=169544
Reviewed by Saam Barati.
Our DFG ToString only considers well about String operands. While ToString(non cell operand) does not have
any side effect, it is not modeled well in DFG.
This patch introduces a fixup for ToString with NonCellUse edge. If this edge is set, ToString does not
clobber things (like ToLowerCase, producing String). And ToString(NonCellUse) allows us to perform CSE!
Our microbenchmark shows 32.9% improvement due to dropped GetButterfly and CSE for ToString().
baseline patched
template-string-array 12.6284+-0.2766 ^ 9.4998+-0.2295 ^ definitely 1.3293x faster
And SixSpeed template_string.es6 shows 16.68x performance improvement due to LICM onto this non-side-effectful ToString().
baseline patched
template_string.es6 3229.7343+-40.5705 ^ 193.6077+-36.3349 ^ definitely 16.6818x faster
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::speculateNotCell):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
(JSC::FTL::DFG::LowerDFGToB3::lowNotCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateNotCell):
2017-03-15 Ryan Haddad <ryanhaddad@apple.com>
Revert part of r213978 to see if it resolves LayoutTest crashes.
https://bugs.webkit.org/show_bug.cgi?id=169729
Reviewed by Alexey Proskuryakov.
* JavaScriptCore.xcodeproj/project.pbxproj:
2017-03-15 Guillaume Emont <guijemont@igalia.com>
[jsc][mips] Fix compilation error introduced in r213652
https://bugs.webkit.org/show_bug.cgi?id=169723
Reviewed by Mark Lam.
The new replaceWithBkpt() contains a lapsus in it
(s/code/instructionStart) and won't compile.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::replaceWithBkpt):
2017-03-15 Daniel Ehrenberg <littledan@chromium.org>
Switch back to ISO 4217 for Intl CurrencyDigits data
https://bugs.webkit.org/show_bug.cgi?id=169182
Previously, a patch switched Intl.NumberFormat to use CLDR data through
ICU to get the default number of decimal digits for a currency.
However, that change actually violated the ECMA 402 specification,
which references ISO 4217 as the data source. This patch reverts to
an in-line implementation of that data.
Reviewed by Saam Barati.
* runtime/IntlNumberFormat.cpp:
(JSC::computeCurrencySortKey):
(JSC::extractCurrencySortKey):
(JSC::computeCurrencyDigits):
2017-03-15 Saam Barati <sbarati@apple.com>
WebAssembly: When we GC to try to get a fast memory, we should call collectAllGarbage(), not collectSync()
https://bugs.webkit.org/show_bug.cgi?id=169704
Reviewed by Mark Lam.
We weren't always sweeping the memory needed to free
the WasmMemory we wanted to use. collectAllGarbage()
will do this if the JS objects wrapping WasmMemory
are dead.
This patch also moves the increment of the allocatedFastMemories
integer to be thread safe.
* wasm/WasmMemory.cpp:
(JSC::Wasm::tryGetFastMemory):
2017-03-15 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in jsc.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164968
Reviewed by Saam Barati.
* jsc.cpp:
(WTF::CustomGetter::customGetter):
(GlobalObject::moduleLoaderResolve):
(GlobalObject::moduleLoaderFetch):
- The only way modules would throw an exception is if we encounter an OutOfMemory
error. This should be extremely rare. At this point, I don't think it's worth
doing the dance to propagate the exception when this happens. Instead, we'll
simply do a RELEASE_ASSERT that we don't see any exceptions here.
(functionRun):
(functionRunString):
(functionLoadModule):
(functionCheckModuleSyntax):
(box):
(dumpException):
(runWithScripts):
2017-03-15 Mark Lam <mark.lam@apple.com>
Fix missing exception checks in Interpreter.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164964
Reviewed by Saam Barati.
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::sizeOfVarargs):
(JSC::sizeFrameForVarargs):
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
(JSC::Interpreter::execute):
2017-03-15 Dean Jackson <dino@apple.com>
Sort Xcode project files
https://bugs.webkit.org/show_bug.cgi?id=169669
Reviewed by Antoine Quint.
* JavaScriptCore.xcodeproj/project.pbxproj:
2017-03-14 Tomas Popela <tpopela@redhat.com>
Wrong condition in offlineasm/risc.rb
https://bugs.webkit.org/show_bug.cgi?id=169597
Reviewed by Mark Lam.
It's missing the 'and' operator between the conditions.
* offlineasm/risc.rb:
2017-03-14 Mark Lam <mark.lam@apple.com>
BytecodeGenerator should use the same function to determine if it needs to store the DerivedConstructor in an ArrowFunction lexical environment.
https://bugs.webkit.org/show_bug.cgi?id=169647
<rdar://problem/31051832>
Reviewed by Michael Saboff.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::usesDerivedConstructorInArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
* bytecompiler/BytecodeGenerator.h:
2017-03-14 Brian Burg <bburg@apple.com>
[Cocoa] Web Inspector: generated code for parsing an array of primitive-type enums from payload does not work
https://bugs.webkit.org/show_bug.cgi?id=169629
Reviewed by Joseph Pecoraro.
This was encountered while trying to compile new protocol definitions that support the Actions API.
* inspector/scripts/codegen/models.py:
(EnumType.__repr__): Improve debug logging so fields match the class member names.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.payload_to_objc_expression_for_member):
If the array elements are actually a primitive type, then there's no need to do any
conversion from a payload. This happens for free since the payload is a tree of
NSDictionary, NSString, NSNumber, etc.
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
Rebaseline.
* inspector/scripts/tests/generic/type-declaration-object-type.json:
Add new cases for properties that contain an array with enum type references and an array of anonymous enums.
2017-03-14 Filip Pizlo <fpizlo@apple.com>
Record the HashSet/HashMap operations in DFG/FTL/B3 and replay them in a benchmark
https://bugs.webkit.org/show_bug.cgi?id=169590
Reviewed by Saam Barati.
Adds code to support logging some hashtable stuff in the DFG.
* dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::pruneHeap):
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::liveNodesAtHead):
(JSC::DFG::CombinedLiveness::CombinedLiveness):
* dfg/DFGCombinedLiveness.h:
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::run):
(JSC::DFG::LivenessAnalysisPhase::processBlock):
* dfg/DFGNode.cpp:
* dfg/DFGNode.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2017-03-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused Network protocol event
https://bugs.webkit.org/show_bug.cgi?id=169619
Reviewed by Mark Lam.
* inspector/protocol/Network.json:
This became unused in r213621 and should have been removed
from the protocol file then.
2017-03-14 Mark Lam <mark.lam@apple.com>
Add a null check in VMTraps::willDestroyVM() to handle a race condition.
https://bugs.webkit.org/show_bug.cgi?id=169620
Reviewed by Filip Pizlo.
There exists a race between VMTraps::willDestroyVM() (which removed SignalSenders
from its m_signalSenders list) and SignalSender::send() (which removes itself
from the list). In the event that SignalSender::send() removes itself between
the time that VMTraps::willDestroyVM() checks if m_signalSenders is empty and the
time it takes a sender from m_signalSenders, VMTraps::willDestroyVM() may end up
with a NULL sender pointer. The fix is to add the missing null check before using
the sender pointer.
* runtime/VMTraps.cpp:
(JSC::VMTraps::willDestroyVM):
(JSC::VMTraps::fireTrap):
* runtime/VMTraps.h:
2017-03-14 Mark Lam <mark.lam@apple.com>
Gardening: Speculative build fix for CLoop after r213886.
https://bugs.webkit.org/show_bug.cgi?id=169436
Not reviewed.
* runtime/MachineContext.h:
2017-03-14 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop unnecessary pthread_attr_t for JIT enabled Linux / FreeBSD environment
https://bugs.webkit.org/show_bug.cgi?id=169592
Reviewed by Carlos Garcia Campos.
Since suspended mcontext_t has all the necessary information, we can drop
pthread_attr_t allocation and destroy for JIT enabled Linux / FreeBSD environment.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::getRegisters):
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::Registers::llintPC):
(JSC::MachineThreads::Thread::freeRegisters):
* heap/MachineStackMarker.h:
2017-03-14 Zan Dobersek <zdobersek@igalia.com>
[GLib] Use USE(GLIB) guards in JavaScriptCore/inspector/EventLoop.cpp
https://bugs.webkit.org/show_bug.cgi?id=169594
Reviewed by Carlos Garcia Campos.
Instead of PLATFORM(GTK) guards, utilize the USE(GLIB) build guards
to guard the GLib-specific includes and invocations in the JSC
inspector's EventLoop class implementation.
* inspector/EventLoop.cpp:
(Inspector::EventLoop::cycle):
2017-03-13 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][Linux] Implement VMTrap in Linux ports
https://bugs.webkit.org/show_bug.cgi?id=169436
Reviewed by Mark Lam.
This patch port VMTrap to Linux ports.
We extract MachineContext accessors from various places (wasm/, heap/ and tools/)
and use them in all the JSC code.
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::Registers::stackPointer):
(JSC::MachineThreads::Thread::Registers::framePointer):
(JSC::MachineThreads::Thread::Registers::instructionPointer):
(JSC::MachineThreads::Thread::Registers::llintPC):
* heap/MachineStackMarker.h:
* runtime/MachineContext.h: Added.
(JSC::MachineContext::stackPointer):
(JSC::MachineContext::framePointer):
(JSC::MachineContext::instructionPointer):
(JSC::MachineContext::argumentPointer<1>):
(JSC::MachineContext::argumentPointer):
(JSC::MachineContext::llintInstructionPointer):
* runtime/PlatformThread.h:
(JSC::platformThreadSignal):
* runtime/VMTraps.cpp:
(JSC::SignalContext::SignalContext):
(JSC::SignalContext::adjustPCToPointToTrappingInstruction):
* tools/CodeProfiling.cpp:
(JSC::profilingTimer):
* tools/SigillCrashAnalyzer.cpp:
(JSC::SignalContext::SignalContext):
(JSC::SignalContext::dump):
* tools/VMInspector.cpp:
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
2017-03-13 Mark Lam <mark.lam@apple.com>
Make the HeapVerifier useful again.
https://bugs.webkit.org/show_bug.cgi?id=161752
Reviewed by Filip Pizlo.
Resurrect the HeapVerifier. Here's what the verifier now offers:
1. It captures the list of cells before and after GCs up to N GC cycles.
N is set by JSC_numberOfGCCyclesToRecordForVerification.
Currently, N defaults to 3.
This is useful if we're debugging in lldb and want to check if a candidate
cell pointer was observed by the GC during the last N GC cycles. We can do
this check buy calling HeapVerifier::checkIfRecorded() with the cell address.
HeapVerifier::checkIfRecorded() is robust and can be used on bogus addresses.
If the candidate cell was previously recorded by the HeapVerifier during a
GC cycle, checkIfRecorded() will dump any useful info it has on that cell.
2. The HeapVerifier will verify that cells in its captured list after a GC are
sane. Some examples of cell insanity are:
- the cell claims to belong to a different VM.
- the cell has a NULL structureID.
- the cell has a NULL structure.
- the cell's structure has a NULL structureID.
- the cell's structure has a NULL structure.
- the cell's structure's structure has a NULL structureID.
- the cell's structure's structure has a NULL structure.
These are all signs of corruption or a GC bug. The verifier will report any
insanity it finds, and then crash with a RELEASE_ASSERT.
3. Since the HeapVerifier captures list of cells in the heap before and after GCs
for the last N GCs, it will also automatically "trim" dead cells those list
after the most recent GC.
"trim" here means that the CellProfile in the HeapVerifier's lists will be
updated to reflect that the cell is now dead. It still keeps a record of the
dead cell pointer and the meta data collected about it back when it was alive.
As a result, checkIfRecorded() will also report if the candidate cell passed
to it is a dead object from a previous GC cycle.
4. Each CellProfile captured by the HeapVerifier now track the following info:
- the cell's HeapCell::Kind.
- the cell's liveness.
- if is JSCell, the cell's classInfo()->className.
- an associated timestamp.
- an associated stack trace.
Currently, the timestamp is only used for the time when the cell was recorded
by the HeapVerifier during GC. The stack trace is currently unused.
However, these fields are kept there so that we can instrument the VM (during
a debugging session, which requires rebuilding the VM) and record interesting
stack traces like that of the time of allocation of the cell. Since
capturing the stack traces for each cell is a very heavy weight operation,
the HeapVerifier code does not do this by default. Instead, we just leave
the building blocks for doing so in place to ease future debugging efforts.
* heap/Heap.cpp:
(JSC::Heap::runBeginPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::didFinishCollection):
* heap/Heap.h:
(JSC::Heap::verifier):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::takeLastActiveBlock): Deleted.
* heap/MarkedSpace.h:
* heap/MarkedSpaceInlines.h:
(JSC::MarkedSpace::forEachLiveCell):
* tools/CellList.cpp:
(JSC::CellList::find):
(JSC::CellList::reset):
(JSC::CellList::findCell): Deleted.
* tools/CellList.h:
(JSC::CellList::CellList):
(JSC::CellList::name):
(JSC::CellList::size):
(JSC::CellList::cells):
(JSC::CellList::add):
(JSC::CellList::reset): Deleted.
* tools/CellProfile.h:
(JSC::CellProfile::CellProfile):
(JSC::CellProfile::cell):
(JSC::CellProfile::jsCell):
(JSC::CellProfile::isJSCell):
(JSC::CellProfile::kind):
(JSC::CellProfile::isLive):
(JSC::CellProfile::isDead):
(JSC::CellProfile::setIsLive):
(JSC::CellProfile::setIsDead):
(JSC::CellProfile::timestamp):
(JSC::CellProfile::className):
(JSC::CellProfile::stackTrace):
(JSC::CellProfile::setStackTrace):
* tools/HeapVerifier.cpp:
(JSC::HeapVerifier::startGC):
(JSC::HeapVerifier::endGC):
(JSC::HeapVerifier::gatherLiveCells):
(JSC::trimDeadCellsFromList):
(JSC::HeapVerifier::trimDeadCells):
(JSC::HeapVerifier::printVerificationHeader):
(JSC::HeapVerifier::verifyCellList):
(JSC::HeapVerifier::validateCell):
(JSC::HeapVerifier::validateJSCell):
(JSC::HeapVerifier::verify):
(JSC::HeapVerifier::reportCell):
(JSC::HeapVerifier::checkIfRecorded):
(JSC::HeapVerifier::initializeGCCycle): Deleted.
(JSC::GatherCellFunctor::GatherCellFunctor): Deleted.
(JSC::GatherCellFunctor::visit): Deleted.
(JSC::GatherCellFunctor::operator()): Deleted.
(JSC::HeapVerifier::verifyButterflyIsInStorageSpace): Deleted.
* tools/HeapVerifier.h:
(JSC::HeapVerifier::GCCycle::reset):
2017-03-13 SKumarMetro <s.kumar@metrological.com>
JSC: fix compilation errors for MIPS
https://bugs.webkit.org/show_bug.cgi?id=168402
Reviewed by Mark Lam.
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::fillNops):
Added.
* assembler/MacroAssemblerMIPS.h:
Added MacroAssemblerMIPS::numGPRs and MacroAssemblerMIPS::numFPRs .
* bytecode/InlineAccess.h:
(JSC::InlineAccess::sizeForPropertyAccess):
(JSC::InlineAccess::sizeForPropertyReplace):
(JSC::InlineAccess::sizeForLengthAccess):
Added MIPS cases.
2017-03-13 Filip Pizlo <fpizlo@apple.com>
FTL should not flush strict arguments unless it really needs to
https://bugs.webkit.org/show_bug.cgi?id=169519
Reviewed by Mark Lam.
This is a refinement that we should have done ages ago. This kills some pointless PutStacks
in DFG SSA IR. It can sometimes unlock other optimizations.
Relanding after I fixed the special cases for CreateArguments-style nodes.
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2017-03-13 Devin Rousso <webkit@devinrousso.com>
Web Inspector: Event Listeners section is missing 'once', 'passive' event listener flags
https://bugs.webkit.org/show_bug.cgi?id=167080
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOM.json:
Add "passive" and "once" items to the EventListener type.
2017-03-13 Mark Lam <mark.lam@apple.com>
Remove obsolete experimental ObjC SPI.
https://bugs.webkit.org/show_bug.cgi?id=169569
Reviewed by Saam Barati.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine enableSigillCrashAnalyzer]): Deleted.
* API/JSVirtualMachinePrivate.h: Removed.
* JavaScriptCore.xcodeproj/project.pbxproj:
2017-03-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r213856.
https://bugs.webkit.org/show_bug.cgi?id=169562
Breaks JSC stress test stress/super-property-access.js.ftl-
eager failing (Requested by mlam|g on #webkit).
Reverted changeset:
"FTL should not flush strict arguments unless it really needs
to"
https://bugs.webkit.org/show_bug.cgi?id=169519
http://trac.webkit.org/changeset/213856
2017-03-13 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC][Linux] Allow profilers to demangle C++ names
https://bugs.webkit.org/show_bug.cgi?id=169559
Reviewed by Michael Catanzaro.
Linux also offers dladdr & demangling feature.
Thus, we can use it to show the names in profilers.
For example, SamplingProfiler tells us the C function names.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
* tools/CodeProfile.cpp:
(JSC::symbolName):
2017-03-13 Yusuke Suzuki <utatane.tea@gmail.com>
[WTF] Clean up RunLoop and WorkQueue with Seconds and Function
https://bugs.webkit.org/show_bug.cgi?id=169537
Reviewed by Sam Weinig.
* runtime/Watchdog.cpp:
(JSC::Watchdog::startTimer):
2017-03-11 Filip Pizlo <fpizlo@apple.com>
FTL should not flush strict arguments unless it really needs to
https://bugs.webkit.org/show_bug.cgi?id=169519
Reviewed by Mark Lam.
This is a refinement that we should have done ages ago. This kills some pointless PutStacks
in DFG SSA IR. It can sometimes unlock other optimizations.
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2017-03-13 Caio Lima <ticaiolima@gmail.com>
[JSC] It should be possible create a label named let when parsing Statement in non strict mode
https://bugs.webkit.org/show_bug.cgi?id=168684
Reviewed by Saam Barati.
This patch is fixing a Parser bug to allow define a label named
```let``` in sloppy mode when parsing a Statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatement):
2017-03-11 Filip Pizlo <fpizlo@apple.com>
Structure::willStoreValueSlow needs to keep the property table alive until the end
https://bugs.webkit.org/show_bug.cgi?id=169520
Reviewed by Michael Saboff.
We use pointers logically interior to `propertyTable` after doing a GC. We need to prevent the
compiler from optimizing away pointers to `propertyTable`.
* heap/HeapCell.cpp:
(JSC::HeapCell::use):
* heap/HeapCell.h:
(JSC::HeapCell::use): Introduce API for keeping a pointer alive until some point in execution.
* runtime/Structure.cpp:
(JSC::Structure::willStoreValueSlow): Use HeapCell::use() to keep the pointer alive.
2017-03-11 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, suprress warnings in JSC B3
* b3/B3Opcode.cpp:
2017-03-11 Michael Saboff <msaboff@apple.com>
Allow regular expressions to be used when selecting a process name in JSC config file
https://bugs.webkit.org/show_bug.cgi?id=169495
Reviewed by Saam Barati.
Only added regular expression selectors for unix like platforms.
* runtime/ConfigFile.cpp:
(JSC::ConfigFileScanner::tryConsumeRegExPattern):
(JSC::ConfigFile::parse):
2017-03-11 Jon Lee <jonlee@apple.com>
WebGPU prototype - Front-End
https://bugs.webkit.org/show_bug.cgi?id=167952
Reviewed by Dean Jackson.
* runtime/CommonIdentifiers.h: Add WebGPU objects.
2017-03-10 Filip Pizlo <fpizlo@apple.com>
The JITs should be able to emit fast TLS loads
https://bugs.webkit.org/show_bug.cgi?id=169483
Reviewed by Keith Miller.
Added loadFromTLS32/64/Ptr to the MacroAssembler and added a B3 test for this.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::mrs_TPIDRRO_EL0):
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::loadFromTLSPtr):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::loadFromTLS32):
(JSC::MacroAssemblerARM64::loadFromTLS64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::loadFromTLS32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::loadFromTLS64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::adcl_im):
(JSC::X86Assembler::addl_mr):
(JSC::X86Assembler::addl_im):
(JSC::X86Assembler::andl_im):
(JSC::X86Assembler::orl_im):
(JSC::X86Assembler::orl_rm):
(JSC::X86Assembler::subl_im):
(JSC::X86Assembler::cmpb_im):
(JSC::X86Assembler::cmpl_rm):
(JSC::X86Assembler::cmpl_im):
(JSC::X86Assembler::testb_im):
(JSC::X86Assembler::movb_i8m):
(JSC::X86Assembler::movb_rm):
(JSC::X86Assembler::movl_mr):
(JSC::X86Assembler::movq_mr):
(JSC::X86Assembler::movsxd_rr):
(JSC::X86Assembler::gs):
(JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
* b3/testb3.cpp:
(JSC::B3::testFastTLS):
(JSC::B3::run):
2017-03-10 Alex Christensen <achristensen@webkit.org>
Fix watch and tv builds after r213294
https://bugs.webkit.org/show_bug.cgi?id=169508
Reviewed by Dan Bernstein.
* Configurations/FeatureDefines.xcconfig:
2017-03-10 Saam Barati <sbarati@apple.com>
WebAssembly: Make more demos run
https://bugs.webkit.org/show_bug.cgi?id=165510
<rdar://problem/29760310>
Reviewed by Keith Miller.
This patch makes another Wasm demo run:
https://kripken.github.io/BananaBread/cube2/bb.html
This patch fixes two bugs:
1. When WebAssemblyFunctionType was added, we did not properly
update the last JS type value.
2. Our code for our JS -> Wasm entrypoint was wrong. It lead to bad
code generation where we would emit B3 that would write over r12
and rbx (on x86) which is invalid since those are our pinned registers.
This patch just rewrites the entrypoint to use hand written assembler
code. I was planning on doing this anyways because it's a compile
time speed boost.
Also, this patch adds support for some new API features:
We can now export an import, either via a direct export, or via a Table and the
Element section. I've added a new class called WebAssemblyWrapperFunction that
just wraps over a JSObject that is a function. Wrapper functions have types
associated with them, so if they're re-imported, or called via call_indirect,
they can be type checked.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::webAssemblyWrapperFunctionStructure):
* runtime/JSType.h:
* wasm/JSWebAssemblyCodeBlock.h:
(JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::headerSizeInBytes):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::isWebAssemblyHostFunction):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::importFunction):
(JSC::JSWebAssemblyInstance::importFunctions):
(JSC::JSWebAssemblyInstance::setImportFunction):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::grow):
(JSC::JSWebAssemblyTable::clearFunction):
(JSC::JSWebAssemblyTable::setFunction):
* wasm/js/JSWebAssemblyTable.h:
(JSC::JSWebAssemblyTable::getFunction):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::createInstance):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::webAssemblyTableProtoFuncGet):
(JSC::webAssemblyTableProtoFuncSet):
* wasm/js/WebAssemblyWrapperFunction.cpp: Added.
(JSC::callWebAssemblyWrapperFunction):
(JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
(JSC::WebAssemblyWrapperFunction::create):
(JSC::WebAssemblyWrapperFunction::finishCreation):
(JSC::WebAssemblyWrapperFunction::createStructure):
(JSC::WebAssemblyWrapperFunction::visitChildren):
* wasm/js/WebAssemblyWrapperFunction.h: Added.
(JSC::WebAssemblyWrapperFunction::signatureIndex):
(JSC::WebAssemblyWrapperFunction::wasmEntrypoint):
(JSC::WebAssemblyWrapperFunction::function):
2017-03-10 Mark Lam <mark.lam@apple.com>
JSC: BindingNode::bindValue doesn't increase the scope's reference count.
https://bugs.webkit.org/show_bug.cgi?id=168546
<rdar://problem/30589551>
Reviewed by Saam Barati.
We should protect the scope RegisterID with a RefPtr while it is still needed.
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitLoopHeader):
(JSC::ForOfNode::emitBytecode):
(JSC::BindingNode::bindValue):
2017-03-10 Alex Christensen <achristensen@webkit.org>
Fix CMake build.
* CMakeLists.txt:
Make more forwarding headers so we can find WasmFaultSignalHandler.h from WebProcess.cpp.
2017-03-10 Mark Lam <mark.lam@apple.com>
[Re-landing] Implement a StackTrace utility object that can capture stack traces for debugging.
https://bugs.webkit.org/show_bug.cgi?id=169454
Reviewed by Michael Saboff.
The underlying implementation is hoisted right out of Assertions.cpp from the
implementations of WTFPrintBacktrace().
The reason we need this StackTrace object is because during heap debugging, we
sometimes want to capture the stack trace that allocated the objects of interest.
Dumping the stack trace directly to stdout (using WTFReportBacktrace()) may
perturb the execution profile sufficiently that an issue may not reproduce,
while alternatively, just capturing the stack trace and deferring printing it
till we actually need it later perturbs the execution profile less.
In addition, just capturing the stack traces (instead of printing them
immediately at each capture site) allows us to avoid polluting stdout with tons
of stack traces that may be irrelevant.
For now, we only capture the native stack trace. We'll leave capturing and
integrating the JS stack trace as an exercise for the future if we need it then.
Here's an example of how to use this StackTrace utility:
// Capture a stack trace of the top 10 frames.
std::unique_ptr<StackTrace> trace(StackTrace::captureStackTrace(10));
// Print the trace.
dataLog(*trace);
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* tools/StackTrace.cpp: Added.
(JSC::StackTrace::instanceSize):
(JSC::StackTrace::captureStackTrace):
(JSC::StackTrace::dump):
* tools/StackTrace.h: Added.
(JSC::StackTrace::size):
(JSC::StackTrace::StackTrace):
2017-03-04 Filip Pizlo <fpizlo@apple.com>
B3 should have comprehensive support for atomic operations
https://bugs.webkit.org/show_bug.cgi?id=162349
Reviewed by Keith Miller.
This adds the following capabilities to B3:
- Atomic weak/strong unfenced/fenced compare-and-swap
- Atomic add/sub/or/and/xor/xchg
- Acquire/release fencing on loads/stores
- Fenceless load-load dependencies
This adds lowering to the following instructions on x86:
- lock cmpxchg
- lock xadd
- lock add/sub/or/and/xor/xchg
This adds lowering to the following instructions on ARM64:
- ldar and friends
- stlr and friends
- ldxr and friends (unfenced LL)
- stxr and friends (unfended SC)
- ldaxr and friends (fenced LL)
- stlxr and friends (fenced SC)
- eor as a fenceless load-load dependency
This does instruction selection pattern matching to ensure that weak/strong CAS and all of the
variants of fences and atomic math ops get lowered to the best possible instruction sequence.
For example, we support the Equal(AtomicStrongCAS(expected, ...), expected) pattern and a bunch
of its friends. You can say Branch(Equal(AtomicStrongCAS(expected, ...), expected)) and it will
generate the best possible branch sequence on x86 and ARM64.
B3 now knows how to model all of the kinds of fencing. It knows that acq loads are ordered with
respect to each other and with respect to rel stores, creating sequential consistency that
transcends just the acq/rel fences themselves (see Effects::fence). It knows that the phantom
fence effects may only target some abstract heaps but not others, so that load elimination and
store sinking can still operate across fences if you just tell B3 that the fence does not alias
those accesses. This makes it super easy to teach B3 that some of your heap is thread-local.
Even better, it lets you express fine-grained dependencies where the atomics that affect one
property in shared memory do not clobber non-atomics that ffect some other property in shared
memory.
One of my favorite features is Depend, which allows you to express load-load dependencies. On
x86 it lowers to nothing, while on ARM64 it lowers to eor.
This also exposes a common atomicWeakCAS API to the x86_64/ARM64 MacroAssemblers. Same for
acq/rel. JSC's 64-bit JITs are now a happy concurrency playground.
This doesn't yet expose the functionality to JS or wasm. SAB still uses the non-intrinsic
implementations of the Atomics object, for now.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::ldar):
(JSC::ARM64Assembler::ldxr):
(JSC::ARM64Assembler::ldaxr):
(JSC::ARM64Assembler::stxr):
(JSC::ARM64Assembler::stlr):
(JSC::ARM64Assembler::stlxr):
(JSC::ARM64Assembler::excepnGenerationImmMask):
(JSC::ARM64Assembler::exoticLoad):
(JSC::ARM64Assembler::storeRelease):
(JSC::ARM64Assembler::exoticStore):
* assembler/AbstractMacroAssembler.cpp: Added.
(WTF::printInternal):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssemblerBase::invert):
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::loadAcq8SignedExtendTo32):
(JSC::MacroAssemblerARM64::loadAcq8):
(JSC::MacroAssemblerARM64::storeRel8):
(JSC::MacroAssemblerARM64::loadAcq16SignedExtendTo32):
(JSC::MacroAssemblerARM64::loadAcq16):
(JSC::MacroAssemblerARM64::storeRel16):
(JSC::MacroAssemblerARM64::loadAcq32):
(JSC::MacroAssemblerARM64::loadAcq64):
(JSC::MacroAssemblerARM64::storeRel32):
(JSC::MacroAssemblerARM64::storeRel64):
(JSC::MacroAssemblerARM64::loadLink8):
(JSC::MacroAssemblerARM64::loadLinkAcq8):
(JSC::MacroAssemblerARM64::storeCond8):
(JSC::MacroAssemblerARM64::storeCondRel8):
(JSC::MacroAssemblerARM64::loadLink16):
(JSC::MacroAssemblerARM64::loadLinkAcq16):
(JSC::MacroAssemblerARM64::storeCond16):
(JSC::MacroAssemblerARM64::storeCondRel16):
(JSC::MacroAssemblerARM64::loadLink32):
(JSC::MacroAssemblerARM64::loadLinkAcq32):
(JSC::MacroAssemblerARM64::storeCond32):
(JSC::MacroAssemblerARM64::storeCondRel32):
(JSC::MacroAssemblerARM64::loadLink64):
(JSC::MacroAssemblerARM64::loadLinkAcq64):
(JSC::MacroAssemblerARM64::storeCond64):
(JSC::MacroAssemblerARM64::storeCondRel64):
(JSC::MacroAssemblerARM64::atomicStrongCAS8):
(JSC::MacroAssemblerARM64::atomicStrongCAS16):
(JSC::MacroAssemblerARM64::atomicStrongCAS32):
(JSC::MacroAssemblerARM64::atomicStrongCAS64):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS8):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS16):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS32):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS64):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS8):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS16):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS32):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS64):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS8):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS16):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS32):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS64):
(JSC::MacroAssemblerARM64::depend32):
(JSC::MacroAssemblerARM64::depend64):
(JSC::MacroAssemblerARM64::loadLink):
(JSC::MacroAssemblerARM64::loadLinkAcq):
(JSC::MacroAssemblerARM64::storeCond):
(JSC::MacroAssemblerARM64::storeCondRel):
(JSC::MacroAssemblerARM64::signExtend):
(JSC::MacroAssemblerARM64::branch):
(JSC::MacroAssemblerARM64::atomicStrongCAS):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS):
(JSC::MacroAssemblerARM64::extractSimpleAddress):
(JSC::MacroAssemblerARM64::signExtend<8>):
(JSC::MacroAssemblerARM64::signExtend<16>):
(JSC::MacroAssemblerARM64::branch<64>):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::and32):
(JSC::MacroAssemblerX86Common::and16):
(JSC::MacroAssemblerX86Common::and8):
(JSC::MacroAssemblerX86Common::neg32):
(JSC::MacroAssemblerX86Common::neg16):
(JSC::MacroAssemblerX86Common::neg8):
(JSC::MacroAssemblerX86Common::or32):
(JSC::MacroAssemblerX86Common::or16):
(JSC::MacroAssemblerX86Common::or8):
(JSC::MacroAssemblerX86Common::sub16):
(JSC::MacroAssemblerX86Common::sub8):
(JSC::MacroAssemblerX86Common::sub32):
(JSC::MacroAssemblerX86Common::xor32):
(JSC::MacroAssemblerX86Common::xor16):
(JSC::MacroAssemblerX86Common::xor8):
(JSC::MacroAssemblerX86Common::not32):
(JSC::MacroAssemblerX86Common::not16):
(JSC::MacroAssemblerX86Common::not8):
(JSC::MacroAssemblerX86Common::store16):
(JSC::MacroAssemblerX86Common::atomicStrongCAS8):
(JSC::MacroAssemblerX86Common::atomicStrongCAS16):
(JSC::MacroAssemblerX86Common::atomicStrongCAS32):
(JSC::MacroAssemblerX86Common::branchAtomicStrongCAS8):
(JSC::MacroAssemblerX86Common::branchAtomicStrongCAS16):
(JSC::MacroAssemblerX86Common::branchAtomicStrongCAS32):
(JSC::MacroAssemblerX86Common::atomicWeakCAS8):
(JSC::MacroAssemblerX86Common::atomicWeakCAS16):
(JSC::MacroAssemblerX86Common::atomicWeakCAS32):
(JSC::MacroAssemblerX86Common::branchAtomicWeakCAS8):
(JSC::MacroAssemblerX86Common::branchAtomicWeakCAS16):
(JSC::MacroAssemblerX86Common::branchAtomicWeakCAS32):
(JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS8):
(JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS16):
(JSC::MacroAssemblerX86Common::atomicRelaxedWeakCAS32):
(JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS8):
(JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS16):
(JSC::MacroAssemblerX86Common::branchAtomicRelaxedWeakCAS32):
(JSC::MacroAssemblerX86Common::atomicAdd8):
(JSC::MacroAssemblerX86Common::atomicAdd16):
(JSC::MacroAssemblerX86Common::atomicAdd32):
(JSC::MacroAssemblerX86Common::atomicSub8):
(JSC::MacroAssemblerX86Common::atomicSub16):
(JSC::MacroAssemblerX86Common::atomicSub32):
(JSC::MacroAssemblerX86Common::atomicAnd8):
(JSC::MacroAssemblerX86Common::atomicAnd16):
(JSC::MacroAssemblerX86Common::atomicAnd32):
(JSC::MacroAssemblerX86Common::atomicOr8):
(JSC::MacroAssemblerX86Common::atomicOr16):
(JSC::MacroAssemblerX86Common::atomicOr32):
(JSC::MacroAssemblerX86Common::atomicXor8):
(JSC::MacroAssemblerX86Common::atomicXor16):
(JSC::MacroAssemblerX86Common::atomicXor32):
(JSC::MacroAssemblerX86Common::atomicNeg8):
(JSC::MacroAssemblerX86Common::atomicNeg16):
(JSC::MacroAssemblerX86Common::atomicNeg32):
(JSC::MacroAssemblerX86Common::atomicNot8):
(JSC::MacroAssemblerX86Common::atomicNot16):
(JSC::MacroAssemblerX86Common::atomicNot32):
(JSC::MacroAssemblerX86Common::atomicXchgAdd8):
(JSC::MacroAssemblerX86Common::atomicXchgAdd16):
(JSC::MacroAssemblerX86Common::atomicXchgAdd32):
(JSC::MacroAssemblerX86Common::atomicXchg8):
(JSC::MacroAssemblerX86Common::atomicXchg16):
(JSC::MacroAssemblerX86Common::atomicXchg32):
(JSC::MacroAssemblerX86Common::loadAcq8):
(JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32):
(JSC::MacroAssemblerX86Common::loadAcq16):
(JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32):
(JSC::MacroAssemblerX86Common::loadAcq32):
(JSC::MacroAssemblerX86Common::storeRel8):
(JSC::MacroAssemblerX86Common::storeRel16):
(JSC::MacroAssemblerX86Common::storeRel32):
(JSC::MacroAssemblerX86Common::storeFence):
(JSC::MacroAssemblerX86Common::loadFence):
(JSC::MacroAssemblerX86Common::replaceWithJump):
(JSC::MacroAssemblerX86Common::maxJumpReplacementSize):
(JSC::MacroAssemblerX86Common::patchableJumpSize):
(JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
(JSC::MacroAssemblerX86Common::supportsAVX):
(JSC::MacroAssemblerX86Common::updateEax1EcxFlags):
(JSC::MacroAssemblerX86Common::x86Condition):
(JSC::MacroAssemblerX86Common::atomicStrongCAS):
(JSC::MacroAssemblerX86Common::branchAtomicStrongCAS):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::add64):
(JSC::MacroAssemblerX86_64::and64):
(JSC::MacroAssemblerX86_64::neg64):
(JSC::MacroAssemblerX86_64::or64):
(JSC::MacroAssemblerX86_64::sub64):
(JSC::MacroAssemblerX86_64::xor64):
(JSC::MacroAssemblerX86_64::not64):
(JSC::MacroAssemblerX86_64::store64):
(JSC::MacroAssemblerX86_64::atomicStrongCAS64):
(JSC::MacroAssemblerX86_64::branchAtomicStrongCAS64):
(JSC::MacroAssemblerX86_64::atomicWeakCAS64):
(JSC::MacroAssemblerX86_64::branchAtomicWeakCAS64):
(JSC::MacroAssemblerX86_64::atomicRelaxedWeakCAS64):
(JSC::MacroAssemblerX86_64::branchAtomicRelaxedWeakCAS64):
(JSC::MacroAssemblerX86_64::atomicAdd64):
(JSC::MacroAssemblerX86_64::atomicSub64):
(JSC::MacroAssemblerX86_64::atomicAnd64):
(JSC::MacroAssemblerX86_64::atomicOr64):
(JSC::MacroAssemblerX86_64::atomicXor64):
(JSC::MacroAssemblerX86_64::atomicNeg64):
(JSC::MacroAssemblerX86_64::atomicNot64):
(JSC::MacroAssemblerX86_64::atomicXchgAdd64):
(JSC::MacroAssemblerX86_64::atomicXchg64):
(JSC::MacroAssemblerX86_64::loadAcq64):
(JSC::MacroAssemblerX86_64::storeRel64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::addl_mr):
(JSC::X86Assembler::addq_mr):
(JSC::X86Assembler::addq_rm):
(JSC::X86Assembler::addq_im):
(JSC::X86Assembler::andl_mr):
(JSC::X86Assembler::andl_rm):
(JSC::X86Assembler::andw_rm):
(JSC::X86Assembler::andb_rm):
(JSC::X86Assembler::andl_im):
(JSC::X86Assembler::andw_im):
(JSC::X86Assembler::andb_im):
(JSC::X86Assembler::andq_mr):
(JSC::X86Assembler::andq_rm):
(JSC::X86Assembler::andq_im):
(JSC::X86Assembler::incq_m):
(JSC::X86Assembler::negq_m):
(JSC::X86Assembler::negl_m):
(JSC::X86Assembler::negw_m):
(JSC::X86Assembler::negb_m):
(JSC::X86Assembler::notl_m):
(JSC::X86Assembler::notw_m):
(JSC::X86Assembler::notb_m):
(JSC::X86Assembler::notq_m):
(JSC::X86Assembler::orl_mr):
(JSC::X86Assembler::orl_rm):
(JSC::X86Assembler::orw_rm):
(JSC::X86Assembler::orb_rm):
(JSC::X86Assembler::orl_im):
(JSC::X86Assembler::orw_im):
(JSC::X86Assembler::orb_im):
(JSC::X86Assembler::orq_mr):
(JSC::X86Assembler::orq_rm):
(JSC::X86Assembler::orq_im):
(JSC::X86Assembler::subl_mr):
(JSC::X86Assembler::subl_rm):
(JSC::X86Assembler::subw_rm):
(JSC::X86Assembler::subb_rm):
(JSC::X86Assembler::subl_im):
(JSC::X86Assembler::subw_im):
(JSC::X86Assembler::subb_im):
(JSC::X86Assembler::subq_mr):
(JSC::X86Assembler::subq_rm):
(JSC::X86Assembler::subq_im):
(JSC::X86Assembler::xorl_mr):
(JSC::X86Assembler::xorl_rm):
(JSC::X86Assembler::xorl_im):
(JSC::X86Assembler::xorw_rm):
(JSC::X86Assembler::xorw_im):
(JSC::X86Assembler::xorb_rm):
(JSC::X86Assembler::xorb_im):
(JSC::X86Assembler::xorq_im):
(JSC::X86Assembler::xorq_rm):
(JSC::X86Assembler::xorq_mr):
(JSC::X86Assembler::xchgb_rm):
(JSC::X86Assembler::xchgw_rm):
(JSC::X86Assembler::xchgl_rm):
(JSC::X86Assembler::xchgq_rm):
(JSC::X86Assembler::movw_im):
(JSC::X86Assembler::movq_i32m):
(JSC::X86Assembler::cmpxchgb_rm):
(JSC::X86Assembler::cmpxchgw_rm):
(JSC::X86Assembler::cmpxchgl_rm):
(JSC::X86Assembler::cmpxchgq_rm):
(JSC::X86Assembler::xaddb_rm):
(JSC::X86Assembler::xaddw_rm):
(JSC::X86Assembler::xaddl_rm):
(JSC::X86Assembler::xaddq_rm):
(JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
* b3/B3AtomicValue.cpp: Added.
(JSC::B3::AtomicValue::~AtomicValue):
(JSC::B3::AtomicValue::dumpMeta):
(JSC::B3::AtomicValue::cloneImpl):
(JSC::B3::AtomicValue::AtomicValue):
* b3/B3AtomicValue.h: Added.
* b3/B3BasicBlock.h:
* b3/B3BlockInsertionSet.cpp:
(JSC::B3::BlockInsertionSet::BlockInsertionSet):
(JSC::B3::BlockInsertionSet::insert): Deleted.
(JSC::B3::BlockInsertionSet::insertBefore): Deleted.
(JSC::B3::BlockInsertionSet::insertAfter): Deleted.
(JSC::B3::BlockInsertionSet::execute): Deleted.
* b3/B3BlockInsertionSet.h:
* b3/B3Effects.cpp:
(JSC::B3::Effects::interferes):
(JSC::B3::Effects::operator==):
(JSC::B3::Effects::dump):
* b3/B3Effects.h:
(JSC::B3::Effects::forCall):
(JSC::B3::Effects::mustExecute):
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3GenericBlockInsertionSet.h: Added.
(JSC::B3::GenericBlockInsertionSet::GenericBlockInsertionSet):
(JSC::B3::GenericBlockInsertionSet::insert):
(JSC::B3::GenericBlockInsertionSet::insertBefore):
(JSC::B3::GenericBlockInsertionSet::insertAfter):
(JSC::B3::GenericBlockInsertionSet::execute):
* b3/B3HeapRange.h:
(JSC::B3::HeapRange::operator|):
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::insertClone):
* b3/B3InsertionSet.h:
* b3/B3LegalizeMemoryOffsets.cpp:
* b3/B3LowerMacros.cpp:
(JSC::B3::lowerMacros):
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::LowerToAir):
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
(JSC::B3::Air::LowerToAir::appendShift):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::storeOpcode):
(JSC::B3::Air::LowerToAir::createStore):
(JSC::B3::Air::LowerToAir::finishAppendingInstructions):
(JSC::B3::Air::LowerToAir::newBlock):
(JSC::B3::Air::LowerToAir::splitBlock):
(JSC::B3::Air::LowerToAir::fillStackmap):
(JSC::B3::Air::LowerToAir::appendX86Div):
(JSC::B3::Air::LowerToAir::appendX86UDiv):
(JSC::B3::Air::LowerToAir::loadLinkOpcode):
(JSC::B3::Air::LowerToAir::storeCondOpcode):
(JSC::B3::Air::LowerToAir::appendCAS):
(JSC::B3::Air::LowerToAir::appendVoidAtomic):
(JSC::B3::Air::LowerToAir::appendGeneralAtomic):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::lowerX86Div): Deleted.
(JSC::B3::Air::LowerToAir::lowerX86UDiv): Deleted.
* b3/B3LowerToAir.h:
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::isLegalOffset):
(JSC::B3::MemoryValue::accessType):
(JSC::B3::MemoryValue::accessBank):
(JSC::B3::MemoryValue::accessByteSize):
(JSC::B3::MemoryValue::dumpMeta):
(JSC::B3::MemoryValue::MemoryValue):
(JSC::B3::MemoryValue::accessWidth): Deleted.
* b3/B3MemoryValue.h:
* b3/B3MemoryValueInlines.h: Added.
(JSC::B3::MemoryValue::isLegalOffset):
(JSC::B3::MemoryValue::requiresSimpleAddr):
(JSC::B3::MemoryValue::accessWidth):
* b3/B3MoveConstants.cpp:
* b3/B3NativeTraits.h: Added.
* b3/B3Opcode.cpp:
(JSC::B3::storeOpcode):
(WTF::printInternal):
* b3/B3Opcode.h:
(JSC::B3::isLoad):
(JSC::B3::isStore):
(JSC::B3::isLoadStore):
(JSC::B3::isAtomic):
(JSC::B3::isAtomicCAS):
(JSC::B3::isAtomicXchg):
(JSC::B3::isMemoryAccess):
(JSC::B3::signExtendOpcode):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::dump):
* b3/B3Procedure.h:
(JSC::B3::Procedure::hasQuirks):
(JSC::B3::Procedure::setHasQuirks):
* b3/B3PureCSE.cpp:
(JSC::B3::pureCSE):
* b3/B3PureCSE.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::returnsBool):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::performSubstitution):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3Width.cpp:
(JSC::B3::bestType):
* b3/B3Width.h:
(JSC::B3::canonicalWidth):
(JSC::B3::isCanonicalWidth):
(JSC::B3::mask):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::jsHash):
(JSC::B3::Air::Arg::dump):
(WTF::printInternal):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isAnyUse):
(JSC::B3::Air::Arg::isColdUse):
(JSC::B3::Air::Arg::cooled):
(JSC::B3::Air::Arg::isEarlyUse):
(JSC::B3::Air::Arg::isLateUse):
(JSC::B3::Air::Arg::isAnyDef):
(JSC::B3::Air::Arg::isEarlyDef):
(JSC::B3::Air::Arg::isLateDef):
(JSC::B3::Air::Arg::isZDef):
(JSC::B3::Air::Arg::simpleAddr):
(JSC::B3::Air::Arg::statusCond):
(JSC::B3::Air::Arg::isSimpleAddr):
(JSC::B3::Air::Arg::isMemory):
(JSC::B3::Air::Arg::isStatusCond):
(JSC::B3::Air::Arg::isCondition):
(JSC::B3::Air::Arg::ptr):
(JSC::B3::Air::Arg::base):
(JSC::B3::Air::Arg::isGP):
(JSC::B3::Air::Arg::isFP):
(JSC::B3::Air::Arg::isValidForm):
(JSC::B3::Air::Arg::forEachTmpFast):
(JSC::B3::Air::Arg::forEachTmp):
(JSC::B3::Air::Arg::asAddress):
(JSC::B3::Air::Arg::asStatusCondition):
(JSC::B3::Air::Arg::isInvertible):
(JSC::B3::Air::Arg::inverted):
* b3/air/AirBasicBlock.cpp:
(JSC::B3::Air::BasicBlock::setSuccessors):
* b3/air/AirBasicBlock.h:
* b3/air/AirBlockInsertionSet.cpp: Added.
(JSC::B3::Air::BlockInsertionSet::BlockInsertionSet):
(JSC::B3::Air::BlockInsertionSet::~BlockInsertionSet):
* b3/air/AirBlockInsertionSet.h: Added.
* b3/air/AirDumpAsJS.cpp: Removed.
* b3/air/AirDumpAsJS.h: Removed.
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isAtomicStrongCASValid):
(JSC::B3::Air::isBranchAtomicStrongCASValid):
(JSC::B3::Air::isAtomicStrongCAS8Valid):
(JSC::B3::Air::isAtomicStrongCAS16Valid):
(JSC::B3::Air::isAtomicStrongCAS32Valid):
(JSC::B3::Air::isAtomicStrongCAS64Valid):
(JSC::B3::Air::isBranchAtomicStrongCAS8Valid):
(JSC::B3::Air::isBranchAtomicStrongCAS16Valid):
(JSC::B3::Air::isBranchAtomicStrongCAS32Valid):
(JSC::B3::Air::isBranchAtomicStrongCAS64Valid):
* b3/air/AirOpcode.opcodes:
* b3/air/AirOptimizeBlockOrder.cpp:
(JSC::B3::Air::optimizeBlockOrder):
* b3/air/AirPadInterference.cpp:
(JSC::B3::Air::padInterference):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testLoadAcq42):
(JSC::B3::testStoreRelAddLoadAcq32):
(JSC::B3::testStoreRelAddLoadAcq8):
(JSC::B3::testStoreRelAddFenceLoadAcq8):
(JSC::B3::testStoreRelAddLoadAcq16):
(JSC::B3::testStoreRelAddLoadAcq64):
(JSC::B3::testTrappingStoreElimination):
(JSC::B3::testX86LeaAddAdd):
(JSC::B3::testX86LeaAddShlLeftScale1):
(JSC::B3::testAtomicWeakCAS):
(JSC::B3::testAtomicStrongCAS):
(JSC::B3::testAtomicXchg):
(JSC::B3::testDepend32):
(JSC::B3::testDepend64):
(JSC::B3::run):
* runtime/Options.h:
2017-03-10 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed typo fixes after r213652.
https://bugs.webkit.org/show_bug.cgi?id=168920
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::replaceWithBreakpoint):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::replaceWithBreakpoint):
2017-03-10 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed ARM buildfix after r213652.
https://bugs.webkit.org/show_bug.cgi?id=168920
r213652 used replaceWithBrk and replaceWithBkpt names for the same
function, which was inconsistent and caused build error in ARMAssembler.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::replaceWithBkpt): Renamed replaceWithBrk to replaceWithBkpt.
(JSC::ARM64Assembler::replaceWithBrk): Deleted.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::replaceWithBkpt): Renamed replaceWithBrk to replaceWithBkpt.
(JSC::ARMAssembler::replaceWithBrk): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::replaceWithBreakpoint):
2017-03-10 Alex Christensen <achristensen@webkit.org>
Win64 build fix.
* b3/B3FenceValue.h:
* b3/B3Value.h:
Putting JS_EXPORT_PRIVATE on member functions in classes that are declared with JS_EXPORT_PRIVATE
doesn't accomplish anything except making Visual Studio mad.
* b3/air/opcode_generator.rb:
winnt.h has naming collisions with enum values from AirOpcode.h.
For example, MemoryFence is #defined to be _mm_mfence, which is declared to be a function in emmintrin.h.
RotateLeft32 is #defined to be _rotl, which is declared to be a function in <stdlib.h>
A clean solution is just to put Opcode:: before the references to the opcode names to tell Visual Studio
that it is referring to the enum value in AirOpcode.h and not the function declaration elsewhere.
2017-03-09 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r213695.
This change broke the Windows build.
Reverted changeset:
"Implement a StackTrace utility object that can capture stack
traces for debugging."
https://bugs.webkit.org/show_bug.cgi?id=169454
http://trac.webkit.org/changeset/213695
2017-03-09 Caio Lima <ticaiolima@gmail.com>
[ESnext] Implement Object Rest - Implementing Object Rest Destructuring
https://bugs.webkit.org/show_bug.cgi?id=167962
Reviewed by Keith Miller.
Object Rest/Spread Destructing proposal is in stage 3[1] and this
Patch is a prototype implementation of it. A simple change over the
parser was necessary to support the new '...' token on Object Pattern
destruction rule. In the bytecode generator side, We changed the
bytecode generated on ObjectPatternNode::bindValue to store in an
array identifiers of already destructed properties, following spec draft
section[2], and then pass it as excludedNames to CopyDataProperties.
The rest destruction the calls copyDataProperties to perform the
copy of rest properties in rhs.
We also implemented CopyDataProperties as private JS global operation
on builtins/GlobalOperations.js following it's specification on [3].
It is implemented using Set object to verify if a property is on
excludedNames to keep this algorithm with O(n + m) complexity, where n
= number of source's own properties and m = excludedNames.length.
As a requirement to use JSSets as constants, a change in
CodeBlock::create API was necessary, because JSSet creation can throws OOM
exception. Now, CodeBlock::finishCreation returns ```false``` if an
execption is throwed by
CodeBlock::setConstantIdentifierSetRegisters and then we return
nullptr to ScriptExecutable::newCodeBlockFor. It is responsible to
check if CodeBlock was constructed properly and then, throw OOM
exception to the correct scope.
[1] - https://github.com/sebmarkbage/ecmascript-rest-spread
[2] - http://sebmarkbage.github.io/ecmascript-rest-spread/#Rest-RuntimeSemantics-PropertyDestructuringAssignmentEvaluation
[3] - http://sebmarkbage.github.io/ecmascript-rest-spread/#AbstractOperations-CopyDataProperties
* builtins/BuiltinNames.h:
* builtins/GlobalOperations.js:
(globalPrivate.copyDataProperties):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantIdentifierSetRegisters):
* bytecode/CodeBlock.h:
* bytecode/EvalCodeBlock.h:
(JSC::EvalCodeBlock::create):
* bytecode/FunctionCodeBlock.h:
(JSC::FunctionCodeBlock::create):
* bytecode/ModuleProgramCodeBlock.h:
(JSC::ModuleProgramCodeBlock::create):
* bytecode/ProgramCodeBlock.h:
(JSC::ProgramCodeBlock::create):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::addSetConstant):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::appendObjectPatternRestEntry):
(JSC::ASTBuilder::setContainsObjectRestElement):
* parser/Nodes.h:
(JSC::ObjectPatternNode::appendEntry):
(JSC::ObjectPatternNode::setContainsRestElement):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseProperty):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::privateToObject):
* runtime/JSGlobalObjectFunctions.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
2017-03-09 Mark Lam <mark.lam@apple.com>
Implement a StackTrace utility object that can capture stack traces for debugging.
https://bugs.webkit.org/show_bug.cgi?id=169454
Reviewed by Michael Saboff.
The underlying implementation is hoisted right out of Assertions.cpp from the
implementations of WTFPrintBacktrace().
The reason we need this StackTrace object is because during heap debugging, we
sometimes want to capture the stack trace that allocated the objects of interest.
Dumping the stack trace directly to stdout (using WTFReportBacktrace()) may
perturb the execution profile sufficiently that an issue may not reproduce,
while alternatively, just capturing the stack trace and deferring printing it
till we actually need it later perturbs the execution profile less.
In addition, just capturing the stack traces (instead of printing them
immediately at each capture site) allows us to avoid polluting stdout with tons
of stack traces that may be irrelevant.
For now, we only capture the native stack trace. We'll leave capturing and
integrating the JS stack trace as an exercise for the future if we need it then.
Here's an example of how to use this StackTrace utility:
// Capture a stack trace of the top 10 frames.
std::unique_ptr<StackTrace> trace(StackTrace::captureStackTrace(10));
// Print the trace.
dataLog(*trace);
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* tools/StackTrace.cpp: Added.
(JSC::StackTrace::instanceSize):
(JSC::StackTrace::captureStackTrace):
(JSC::StackTrace::dump):
* tools/StackTrace.h: Added.
(JSC::StackTrace::StackTrace):
(JSC::StackTrace::size):
2017-03-09 Keith Miller <keith_miller@apple.com>
WebAssembly: Enable fast memory for WK2
https://bugs.webkit.org/show_bug.cgi?id=169437
Reviewed by Tim Horton.
* JavaScriptCore.xcodeproj/project.pbxproj:
2017-03-09 Matt Baker <mattbaker@apple.com>
Web Inspector: Add XHR breakpoints UI
https://bugs.webkit.org/show_bug.cgi?id=168763
<rdar://problem/30952439>
Reviewed by Joseph Pecoraro.
* inspector/protocol/DOMDebugger.json:
Added clarifying comments to command descriptions.
2017-03-09 Michael Saboff <msaboff@apple.com>
Add plumbing to WebProcess to enable JavaScriptCore configuration and logging
https://bugs.webkit.org/show_bug.cgi?id=169387
Reviewed by Filip Pizlo.
Added a helper function, processConfigFile(), to process configuration file.
Changed jsc.cpp to use that function in lieu of processing the config file
manually.
* JavaScriptCore.xcodeproj/project.pbxproj: Made ConfigFile.h a private header file.
* jsc.cpp:
(jscmain):
* runtime/ConfigFile.cpp:
(JSC::processConfigFile):
* runtime/ConfigFile.h:
2017-03-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Show HTTP protocol version and other Network Load Metrics (IP Address, Priority, Connection ID)
https://bugs.webkit.org/show_bug.cgi?id=29687
<rdar://problem/19281586>
Reviewed by Matt Baker and Brian Burg.
* inspector/protocol/Network.json:
Add metrics object with optional properties to loadingFinished event.
2017-03-09 Youenn Fablet <youenn@apple.com>
Minimal build is broken
https://bugs.webkit.org/show_bug.cgi?id=169416
Reviewed by Chris Dumez.
Since we now have some JS built-ins that are not tied to a compilation flag, we can remove compilation guards around m_vm.
We could probably remove m_vm by ensuring m_jsDOMBindingInternals appear first but this might break very easily.
* Scripts/builtins/builtins_generate_internals_wrapper_header.py:
(generate_members):
* Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
2017-03-09 Daniel Bates <dabates@apple.com>
Guard Credential Management implementation behind a runtime enabled feature flag
https://bugs.webkit.org/show_bug.cgi?id=169364
<rdar://problem/30957425>
Reviewed by Brent Fulgham.
Add common identifiers for Credential, PasswordCredential, and SiteBoundCredential that are
needed to guard these interfaces behind a runtime enabled feature flag.
* runtime/CommonIdentifiers.h:
2017-03-09 Mark Lam <mark.lam@apple.com>
Refactoring some HeapVerifier code.
https://bugs.webkit.org/show_bug.cgi?id=169443
Reviewed by Filip Pizlo.
Renamed LiveObjectData to CellProfile.
Renamed LiveObjectList to CellList.
Moved CellProfile.*, CellList.*, and HeapVerifier.* from the heap folder to the tools folder.
Updated the HeapVerifier to handle JSCells instead of just JSObjects.
This is in preparation for subsequent patches to fix up the HeapVerifier for service again.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::runBeginPhase):
(JSC::Heap::runEndPhase):
* heap/HeapVerifier.cpp: Removed.
* heap/HeapVerifier.h: Removed.
* heap/LiveObjectData.h: Removed.
* heap/LiveObjectList.cpp: Removed.
* heap/LiveObjectList.h: Removed.
* tools/CellList.cpp: Copied from Source/JavaScriptCore/heap/LiveObjectList.cpp.
(JSC::CellList::findCell):
(JSC::LiveObjectList::findObject): Deleted.
* tools/CellList.h: Copied from Source/JavaScriptCore/heap/LiveObjectList.h.
(JSC::CellList::CellList):
(JSC::CellList::reset):
(JSC::LiveObjectList::LiveObjectList): Deleted.
(JSC::LiveObjectList::reset): Deleted.
* tools/CellProfile.h: Copied from Source/JavaScriptCore/heap/LiveObjectData.h.
(JSC::CellProfile::CellProfile):
(JSC::LiveObjectData::LiveObjectData): Deleted.
* tools/HeapVerifier.cpp: Copied from Source/JavaScriptCore/heap/HeapVerifier.cpp.
(JSC::GatherCellFunctor::GatherCellFunctor):
(JSC::GatherCellFunctor::visit):
(JSC::GatherCellFunctor::operator()):
(JSC::HeapVerifier::gatherLiveCells):
(JSC::HeapVerifier::cellListForGathering):
(JSC::trimDeadCellsFromList):
(JSC::HeapVerifier::trimDeadCells):
(JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
(JSC::HeapVerifier::reportCell):
(JSC::HeapVerifier::checkIfRecorded):
(JSC::GatherLiveObjFunctor::GatherLiveObjFunctor): Deleted.
(JSC::GatherLiveObjFunctor::visit): Deleted.
(JSC::GatherLiveObjFunctor::operator()): Deleted.
(JSC::HeapVerifier::gatherLiveObjects): Deleted.
(JSC::HeapVerifier::liveObjectListForGathering): Deleted.
(JSC::trimDeadObjectsFromList): Deleted.
(JSC::HeapVerifier::trimDeadObjects): Deleted.
(JSC::HeapVerifier::reportObject): Deleted.
* tools/HeapVerifier.h: Copied from Source/JavaScriptCore/heap/HeapVerifier.h.
2017-03-09 Anders Carlsson <andersca@apple.com>
Add delegate support to WebCore
https://bugs.webkit.org/show_bug.cgi?id=169427
Part of rdar://problem/28880714.
Reviewed by Geoffrey Garen.
* Configurations/FeatureDefines.xcconfig:
Add feature define.
2017-03-09 Nikita Vasilyev <nvasilyev@apple.com>
Web Inspector: Show individual messages in the content pane for a WebSocket
https://bugs.webkit.org/show_bug.cgi?id=169011
Reviewed by Joseph Pecoraro.
Add walltime parameter and correct the description of Timestamp type.
* inspector/protocol/Network.json:
2017-03-09 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix weak external symbol error.
* heap/SlotVisitor.h:
2017-03-09 Filip Pizlo <fpizlo@apple.com>
std::isnan/isinf should work with WTF time classes
https://bugs.webkit.org/show_bug.cgi?id=164991
Reviewed by Darin Adler.
Changes AtomicsObject to use std::isnan() instead of operator== to detect NaN.
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncWait):
2017-03-09 Mark Lam <mark.lam@apple.com>
Use const AbstractLocker& (instead of const LockHolder&) in more places.
https://bugs.webkit.org/show_bug.cgi?id=169424
Reviewed by Filip Pizlo.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::promoteYoungCodeBlocks):
* heap/CodeBlockSet.h:
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::mark):
* heap/ConservativeRoots.cpp:
(JSC::CompositeMarkHook::CompositeMarkHook):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::tryCopyOtherThreadStacks):
* heap/MachineStackMarker.h:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
* profiler/ProfilerDatabase.h:
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::createThreadIfNecessary):
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::start):
(JSC::SamplingProfiler::pause):
(JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
(JSC::SamplingProfiler::clearData):
(JSC::SamplingProfiler::releaseStackTraces):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::setStopWatch):
* wasm/WasmMemory.cpp:
(JSC::Wasm::availableFastMemories):
(JSC::Wasm::activeFastMemories):
(JSC::Wasm::viewActiveFastMemories):
* wasm/WasmMemory.h:
2017-03-09 Saam Barati <sbarati@apple.com>
WebAssembly: Make the Unity AngryBots demo run
https://bugs.webkit.org/show_bug.cgi?id=169268
Reviewed by Keith Miller.
This patch fixes three bugs:
1. The WasmBinding code for making a JS call was off
by 1 in its stack layout code.
2. The WasmBinding code had a "<" comparison instead
of a ">=" comparison. This would cause us to calculate
the wrong frame pointer offset.
3. The code to reload wasm state inside B3IRGenerator didn't
properly represent its effects.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::restoreWebAssemblyGlobalState):
(JSC::Wasm::parseAndCompile):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::createInstance):
2017-03-09 Mark Lam <mark.lam@apple.com>
Make the VM Traps mechanism non-polling for the DFG and FTL.
https://bugs.webkit.org/show_bug.cgi?id=168920
<rdar://problem/30738588>
Reviewed by Filip Pizlo.
1. Added a ENABLE(SIGNAL_BASED_VM_TRAPS) configuration in Platform.h.
This is currently only enabled for OS(DARWIN) and ENABLE(JIT).
2. Added assembler functions for overwriting an instruction with a breakpoint.
3. Added a new JettisonDueToVMTraps jettison reason.
4. Added CodeBlock and DFG::CommonData utility functions for over-writing
invalidation points with breakpoint instructions.
5. The BytecodeGenerator now emits the op_check_traps bytecode unconditionally.
6. Remove the JSC_alwaysCheckTraps option because of (4) above.
For ports that don't ENABLE(SIGNAL_BASED_VM_TRAPS), we'll force
Options::usePollingTraps() to always be true. This makes the VMTraps
implementation fall back to using polling based traps only.
7. Make VMTraps support signal based traps.
Some design and implementation details of signal based VM traps:
- The implementation makes use of 2 signal handlers for SIGUSR1 and SIGTRAP.
- VMTraps::fireTrap() will set the flag for the requested trap and instantiate
a SignalSender. The SignalSender will send SIGUSR1 to the mutator thread that
we want to trap, and check for the occurence of one of the following events:
a. VMTraps::handleTraps() has been called for the requested trap, or
b. the VM is inactive and is no longer executing any JS code. We determine
this to be the case if the thread no longer owns the JSLock and the VM's
entryScope is null.
Note: the thread can relinquish the JSLock while the VM's entryScope is not
null. This happens when the thread calls JSLock::dropAllLocks() before
calling a host function that may block on IO (or whatever). For our purpose,
this counts as the VM still running JS code, and VM::fireTrap() will still
be waiting.
If the SignalSender does not see either of these events, it will sleep for a
while and then re-send SIGUSR1 and check for the events again. When it sees
one of these events, it will consider the mutator to have received the trap
request.
- The SIGUSR1 handler will try to insert breakpoints at the invalidation points
in the DFG/FTL codeBlock at the top of the stack. This allows the mutator
thread to break (with a SIGTRAP) exactly at an invalidation point, where it's
safe to jettison the codeBlock.
Note: we cannot have the requester thread (that called VMTraps::fireTrap())
insert the breakpoint instructions itself. This is because we need the
register state of the the mutator thread (that we want to trap in) in order to
find the codeBlocks that we wish to insert the breakpoints in. Currently,
we don't have a generic way for the requester thread to get the register state
of another thread.
- The SIGTRAP handler will check to see if it is trapping on a breakpoint at an
invalidation point. If so, it will jettison the codeBlock and adjust the PC
to re-execute the invalidation OSR exit off-ramp. After the OSR exit, the
baseline JIT code will eventually reach an op_check_traps and call
VMTraps::handleTraps().
If the handler is not trapping at an invalidation point, then it must be
observing an assertion failure (which also uses the breakpoint instruction).
In this case, the handler will defer to the default SIGTRAP handler and crash.
- The reason we need the SignalSender is because SignalSender::send() is called
from another thread in a loop, so that VMTraps::fireTrap() can return sooner.
send() needs to make use of the VM pointer, and it is not guaranteed that the
VM will outlive the thread. SignalSender provides the mechanism by which we
can nullify the VM pointer when the VM dies so that the thread does not
continue to use it.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::replaceWithBrk):
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::replaceWithBrk):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::replaceWithBkpt):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::replaceWithBkpt):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::replaceWithJump):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::replaceWithBreakpoint):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::replaceWithBreakpoint):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::replaceWithJump):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::replaceWithBreakpoint):
* assembler/X86Assembler.h:
(JSC::X86Assembler::replaceWithInt3):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::hasInstalledVMTrapBreakpoints):
(JSC::CodeBlock::installVMTrapBreakpoints):
* bytecode/CodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCheckTraps):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::CommonData::isVMTrapBreakpoint):
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::hasInstalledVMTrapsBreakpoints):
* dfg/DFGJumpReplacement.cpp:
(JSC::DFG::JumpReplacement::installVMTrapBreakpoint):
* dfg/DFGJumpReplacement.h:
(JSC::DFG::JumpReplacement::dataLocation):
* dfg/DFGNodeType.h:
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::contains):
* heap/CodeBlockSet.h:
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::iterate):
* heap/Heap.cpp:
(JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::forEachCodeBlockIgnoringJITPlans):
* heap/MachineStackMarker.h:
(JSC::MachineThreads::threadsListHead):
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::isValidExecutableMemory):
* jit/ExecutableAllocator.h:
* profiler/ProfilerJettisonReason.cpp:
(WTF::printInternal):
* profiler/ProfilerJettisonReason.h:
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/PlatformThread.h:
(JSC::platformThreadSignal):
* runtime/VM.cpp:
(JSC::VM::~VM):
(JSC::VM::ensureWatchdog):
(JSC::VM::handleTraps): Deleted.
(JSC::VM::setNeedAsynchronousTerminationSupport): Deleted.
* runtime/VM.h:
(JSC::VM::ownerThread):
(JSC::VM::traps):
(JSC::VM::handleTraps):
(JSC::VM::needTrapHandling):
(JSC::VM::needAsynchronousTerminationSupport): Deleted.
* runtime/VMTraps.cpp:
(JSC::VMTraps::vm):
(JSC::SignalContext::SignalContext):
(JSC::SignalContext::adjustPCToPointToTrappingInstruction):
(JSC::vmIsInactive):
(JSC::findActiveVMAndStackBounds):
(JSC::handleSigusr1):
(JSC::handleSigtrap):
(JSC::installSignalHandlers):
(JSC::sanitizedTopCallFrame):
(JSC::isSaneFrame):
(JSC::VMTraps::tryInstallTrapBreakpoints):
(JSC::VMTraps::invalidateCodeBlocksOnStack):
(JSC::VMTraps::VMTraps):
(JSC::VMTraps::willDestroyVM):
(JSC::VMTraps::addSignalSender):
(JSC::VMTraps::removeSignalSender):
(JSC::VMTraps::SignalSender::willDestroyVM):
(JSC::VMTraps::SignalSender::send):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::handleTraps):
* runtime/VMTraps.h:
(JSC::VMTraps::~VMTraps):
(JSC::VMTraps::needTrapHandling):
(JSC::VMTraps::notifyGrabAllLocks):
(JSC::VMTraps::SignalSender::SignalSender):
(JSC::VMTraps::invalidateCodeBlocksOnStack):
* tools/VMInspector.cpp:
* tools/VMInspector.h:
(JSC::VMInspector::getLock):
(JSC::VMInspector::iterate):
2017-03-09 Filip Pizlo <fpizlo@apple.com>
WebKit: JSC: JSObject::ensureLength doesn't check if ensureLengthSlow failed
https://bugs.webkit.org/show_bug.cgi?id=169215
Reviewed by Mark Lam.
This doesn't have a test because it would be a very complicated test.
* runtime/JSObject.h:
(JSC::JSObject::ensureLength): If ensureLengthSlow returns false, we need to return false.
2017-03-07 Filip Pizlo <fpizlo@apple.com>
WTF should make it super easy to do ARM concurrency tricks
https://bugs.webkit.org/show_bug.cgi?id=169300
Reviewed by Mark Lam.
This changes a bunch of GC hot paths to use new concurrency APIs that lead to optimal
code on both x86 (fully leverage TSO, transactions become CAS loops) and ARM (use
dependency chains for fencing, transactions become LL/SC loops). While inspecting the
machine code, I found other opportunities for improvement, like inlining the "am I
marked" part of the marking functions.
* heap/Heap.cpp:
(JSC::Heap::setGCDidJIT):
* heap/HeapInlines.h:
(JSC::Heap::testAndSetMarked):
* heap/LargeAllocation.h:
(JSC::LargeAllocation::isMarked):
(JSC::LargeAllocation::isMarkedConcurrently):
(JSC::LargeAllocation::aboutToMark):
(JSC::LargeAllocation::testAndSetMarked):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::areMarksStaleWithDependency):
(JSC::MarkedBlock::aboutToMark):
(JSC::MarkedBlock::isMarkedConcurrently):
(JSC::MarkedBlock::isMarked):
(JSC::MarkedBlock::testAndSetMarked):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendSlow):
(JSC::SlotVisitor::appendHiddenSlow):
(JSC::SlotVisitor::appendHiddenSlowImpl):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendUnbarriered): Deleted.
(JSC::SlotVisitor::appendHidden): Deleted.
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::appendUnbarriered):
(JSC::SlotVisitor::appendHidden):
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendValues):
(JSC::SlotVisitor::appendValuesHidden):
* runtime/CustomGetterSetter.cpp:
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterflyImpl):
* runtime/JSObject.h:
2017-03-08 Yusuke Suzuki <utatane.tea@gmail.com>
[GTK] JSC test stress/arity-check-ftl-throw.js.ftl-no-cjit-validate-sampling-profiler crashing on GTK bot
https://bugs.webkit.org/show_bug.cgi?id=160124
Reviewed by Mark Lam.
When performing CallVarargs, we will copy values to the stack.
Before actually copying values, we need to adjust the stackPointerRegister
to ensure copied values are in the allocated stack area.
If we do not that, OS can break the values that is stored beyond the stack
pointer. For example, signal stack can be constructed on these area, and
breaks values.
This patch fixes the crash in stress/spread-forward-call-varargs-stack-overflow.js
in Linux port. Since Linux ports use signal to suspend and resume threads,
signal handler is frequently called when enabling sampling profiler. Thus this
crash occurs.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* jit/SetupVarargsFrame.h:
2017-03-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Should be able to see where Resources came from (Memory Cache, Disk Cache)
https://bugs.webkit.org/show_bug.cgi?id=164892
<rdar://problem/29320562>
Reviewed by Brian Burg.
* inspector/protocol/Network.json:
Replace "fromDiskCache" property with "source" property which includes
more complete information about the source of this response (network,
memory cache, disk cache, or unknown).
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(_generate_class_for_object_declaration):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
* inspector/scripts/codegen/generator.py:
(Generator):
(Generator.open_fields):
To avoid conflicts between the Inspector::Protocol::Network::Response::Source
enum and open accessor string symbol that would have the same name, only generate
a specific list of open accessor strings. This reduces the list of exported
symbols from all properties to just the ones that are needed. This can be
cleaned up later if needed.
* inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result: Added.
* inspector/scripts/tests/generic/type-with-open-parameters.json: Added.
Test for open accessors generation.
2017-03-08 Keith Miller <keith_miller@apple.com>
WebAssembly: Make OOB for fast memory do an extra safety check by ensuring the faulting address is in the range we allocated for fast memory
https://bugs.webkit.org/show_bug.cgi?id=169290
Reviewed by Saam Barati.
This patch adds an extra sanity check by ensuring that the the memory address we faulting trying to load is in range
of some wasm fast memory.
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
* wasm/WasmMemory.cpp:
(JSC::Wasm::activeFastMemories):
(JSC::Wasm::viewActiveFastMemories):
(JSC::Wasm::tryGetFastMemory):
(JSC::Wasm::releaseFastMemory):
* wasm/WasmMemory.h:
2017-03-07 Dean Jackson <dino@apple.com>
Some platforms won't be able to create a GPUDevice
https://bugs.webkit.org/show_bug.cgi?id=169314
<rdar://problems/30907521>
Reviewed by Jon Lee.
Disable WEB_GPU on the iOS Simulator.
* Configurations/FeatureDefines.xcconfig:
2017-03-06 Saam Barati <sbarati@apple.com>
WebAssembly: Implement the WebAssembly.instantiate API
https://bugs.webkit.org/show_bug.cgi?id=165982
<rdar://problem/29760110>
Reviewed by Keith Miller.
This patch is a straight forward implementation of the WebAssembly.instantiate
API: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstantiate
I implemented the API in a synchronous manner. We should make it
asynchronous: https://bugs.webkit.org/show_bug.cgi?id=169187
* wasm/JSWebAssembly.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::webAssemblyInstantiateFunc):
(JSC::JSWebAssembly::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
(JSC::WebAssemblyInstanceConstructor::createInstance):
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleConstructor.h:
2017-03-06 Michael Saboff <msaboff@apple.com>
Take advantage of fast permissions switching of JIT memory for devices that support it
https://bugs.webkit.org/show_bug.cgi?id=169155
Reviewed by Saam Barati.
Start using the os_thread_self_restrict_rwx_to_XX() SPIs when available to
control access to JIT memory.
Had to update the Xcode config files to handle various build variations of
public and internal SDKs.
* Configurations/Base.xcconfig:
* Configurations/FeatureDefines.xcconfig:
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
2017-03-06 Csaba Osztrogonác <ossy@webkit.org>
REGRESSION(r212778): It made 400 tests crash on AArch64 Linux
https://bugs.webkit.org/show_bug.cgi?id=168502
Reviewed by Filip Pizlo.
* heap/RegisterState.h: Use setjmp code path on AArch64 Linux too to fix crashes.
2017-03-06 Caio Lima <ticaiolima@gmail.com>
op_get_by_id_with_this should use inline caching
https://bugs.webkit.org/show_bug.cgi?id=162124
Reviewed by Saam Barati.
This patch is enabling inline cache for op_get_by_id_with_this in all
tiers. It means that operations using ```super.member``` are going to
be able to be optimized by PIC. To enable it, we introduced a new
member of StructureStubInfo.patch named thisGPR, created a new class
to manage the IC named JITGetByIdWithThisGenerator and changed
PolymorphicAccess.regenerate that uses StructureStubInfo.patch.thisGPR
to decide the correct this value on inline caches.
With inline cached enabled, ```super.member``` are ~4.5x faster,
according microbenchmarks.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addGetByIdWithThis):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compileIn):
(JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
(JSC::JITGetByIdWithThisGenerator::generateFastPath):
* jit/JITInlineCacheGenerator.h:
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByIdFunction):
(JSC::appropriateGenericGetByIdFunction):
(JSC::tryCacheGetByID):
* jit/Repatch.h:
* jsc.cpp:
(WTF::CustomGetter::getOwnPropertySlot):
(WTF::CustomGetter::customGetterAcessor):
2017-03-06 Saam Barati <sbarati@apple.com>
WebAssembly: implement init_expr for Element
https://bugs.webkit.org/show_bug.cgi?id=165888
<rdar://problem/29760199>
Reviewed by Keith Miller.
This patch fixes a few bugs. The main change is allowing init_expr
for the Element's offset. To do this, I had to fix a couple of
other bugs:
- I removed our invalid early module-parse-time invalidation
of out of bound Element sections. This is not in the spec because
it can't be validated in the general case when the offset is a
get_global.
- Our get_global validation inside our init_expr parsing code was simply wrong.
It thought that the index operand to get_global went into the pool of imports,
but it does not. It indexes into the pool of globals. I changed the code to
refer to the global pool instead.
* wasm/WasmFormat.h:
(JSC::Wasm::Element::Element):
* wasm/WasmModuleParser.cpp:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2017-03-06 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Allow indexed module namespace object fields
https://bugs.webkit.org/show_bug.cgi?id=168870
Reviewed by Saam Barati.
While JS modules cannot expose any indexed bindings,
Wasm modules can expose them. However, module namespace
object currently does not support indexed properties.
This patch allows module namespace objects to offer
indexed binding accesses.
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
(JSC::JSModuleNamespaceObject::getOwnPropertySlot):
(JSC::JSModuleNamespaceObject::getOwnPropertySlotByIndex):
* runtime/JSModuleNamespaceObject.h:
2017-03-06 Yusuke Suzuki <utatane.tea@gmail.com>
Null pointer crash when loading module with unresolved import also as a script file
https://bugs.webkit.org/show_bug.cgi?id=168971
Reviewed by Saam Barati.
If linking throws an error, this error should be re-thrown
when requesting the same module.
* builtins/ModuleLoaderPrototype.js:
(globalPrivate.newRegistryEntry):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::link):
2017-03-06 Yusuke Suzuki <utatane.tea@gmail.com>
[GTK][JSCOnly] Enable WebAssembly on Linux environment
https://bugs.webkit.org/show_bug.cgi?id=164032
Reviewed by Michael Catanzaro.
This patch enables WebAssembly on JSCOnly and GTK ports.
Basically, almost all the WASM code is portable to Linux.
One platform-dependent part is faster memory load using SIGBUS
signal handler. This patch ports this part to Linux.
* CMakeLists.txt:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
2017-03-06 Daniel Ehrenberg <littledan@igalia.com>
Currency digits calculation in Intl.NumberFormat should call out to ICU
https://bugs.webkit.org/show_bug.cgi?id=169182
Reviewed by Yusuke Suzuki.
* runtime/IntlNumberFormat.cpp:
(JSC::computeCurrencyDigits):
(JSC::computeCurrencySortKey): Deleted.
(JSC::extractCurrencySortKey): Deleted.
2017-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSCOnly][GTK] Suppress warnings on return type in B3 and WASM
https://bugs.webkit.org/show_bug.cgi?id=168869
Reviewed by Keith Miller.
* b3/B3Width.h:
* wasm/WasmSections.h:
2017-03-04 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Unreviewed buildfix after r213376.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::isBkpt): Typo fixed.
2017-03-03 Carlos Alberto Lopez Perez <clopez@igalia.com>
[JSC] build fix after r213399
https://bugs.webkit.org/show_bug.cgi?id=169154
Unreviewed.
* runtime/ConfigFile.cpp: Include unistd.h since its where getcwd() is defined.
2017-03-03 Dean Jackson <dino@apple.com>
Add WebGPU compile flag and experimental feature flag
https://bugs.webkit.org/show_bug.cgi?id=169161
<rdar://problem/30846689>
Reviewed by Tim Horton.
Add ENABLE_WEBGPU, an experimental feature flag, a RuntimeEnabledFeature,
and an InternalSetting.
* Configurations/FeatureDefines.xcconfig:
2017-03-03 Michael Saboff <msaboff@apple.com>
Add support for relative pathnames to JSC config files
https://bugs.webkit.org/show_bug.cgi?id=169154
Reviewed by Saam Barati.
If the config file is a relative path, prepend the current working directory.
After canonicalizing the config file path, we extract its directory path and
use that for the directory for a relative log pathname.
* runtime/ConfigFile.cpp:
(JSC::ConfigFile::ConfigFile):
(JSC::ConfigFile::parse):
(JSC::ConfigFile::canonicalizePaths):
* runtime/ConfigFile.h:
2017-03-03 Michael Saboff <msaboff@apple.com>
Add load / store exclusive instruction group to ARM64 disassembler
https://bugs.webkit.org/show_bug.cgi?id=169152
Reviewed by Filip Pizlo.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::opName):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::rs):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::rt2):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o0):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o1):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::o2):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::loadBit):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::opNumber):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreExclusive::isPairOp):
2017-03-03 Keith Miller <keith_miller@apple.com>
WASM should support faster loads.
https://bugs.webkit.org/show_bug.cgi?id=162693
Reviewed by Saam Barati.
This patch adds support for WebAssembly using a 32-bit address
space for memory (along with some extra space for offset
overflow). With a 32-bit address space (we call them
Signaling/fast memories), we reserve the virtual address space for
2^32 + offset bytes of memory and only mark the usable section as
read/write. If wasm code would read/write out of bounds we use a
custom signal handler to catch the SIGBUS. The signal handler then
checks if the faulting instruction is wasm code and tells the
thread to resume executing from the wasm exception
handler. Otherwise, the signal handler crashes the process, as
usual.
All of the allocations of these memories are managed by the
Wasm::Memory class. In order to avoid TLB churn in the OS we cache
old Signaling memories that are no longer in use. Since getting
the wrong memory can cause recompiles, we try to reserve a memory
for modules that do not import a memory. If a module does import a
memory, we try to guess the type of memory we are going to get
based on the last one allocated.
This patch also changes how the wasm JS-api manages objects. Since
we can compile different versions of code, this patch adds a new
JSWebAssemblyCodeBlock class that holds all the information
specific to running a module in a particular bounds checking
mode. Additionally, the Wasm::Memory object is now a reference
counted class that is shared between the JSWebAssemblyMemory
object and the ArrayBuffer that also views it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITThunks.cpp:
(JSC::JITThunks::existingCTIStub):
* jit/JITThunks.h:
* jsc.cpp:
(jscmain):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/JSWebAssemblyCodeBlock.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.
(JSC::JSWebAssemblyCodeBlock::create):
(JSC::JSWebAssemblyCodeBlock::createStructure):
(JSC::JSWebAssemblyCodeBlock::functionImportCount):
(JSC::JSWebAssemblyCodeBlock::mode):
(JSC::JSWebAssemblyCodeBlock::module):
(JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
(JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
(JSC::JSWebAssemblyCodeBlock::callees):
(JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
(JSC::JSWebAssemblyCodeBlock::allocationSize):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::getMemoryBaseAndSize):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::emitLoadOp):
(JSC::Wasm::B3IRGenerator::emitStoreOp):
* wasm/WasmCallingConvention.h:
* wasm/WasmFaultSignalHandler.cpp: Added.
(JSC::Wasm::trapHandler):
(JSC::Wasm::registerCode):
(JSC::Wasm::unregisterCode):
(JSC::Wasm::fastMemoryEnabled):
(JSC::Wasm::enableFastMemory):
* wasm/WasmFaultSignalHandler.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
* wasm/WasmFormat.h:
(JSC::Wasm::ModuleInformation::importFunctionCount):
(JSC::Wasm::ModuleInformation::hasMemory): Deleted.
* wasm/WasmMemory.cpp:
(JSC::Wasm::mmapBytes):
(JSC::Wasm::Memory::lastAllocatedMode):
(JSC::Wasm::availableFastMemories):
(JSC::Wasm::tryGetFastMemory):
(JSC::Wasm::releaseFastMemory):
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::createImpl):
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::dump):
(JSC::Wasm::Memory::makeString):
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::operator bool):
(JSC::Wasm::Memory::size):
(JSC::Wasm::Memory::check):
(JSC::Wasm::Memory::Memory): Deleted.
(JSC::Wasm::Memory::offsetOfMemory): Deleted.
(JSC::Wasm::Memory::offsetOfSize): Deleted.
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::MemoryInformation::hasReservedMemory):
(JSC::Wasm::MemoryInformation::takeReservedMemory):
(JSC::Wasm::MemoryInformation::mode):
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::mode):
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::finishCreation):
(JSC::JSWebAssemblyCallee::destroy):
* wasm/js/JSWebAssemblyCodeBlock.cpp: Added.
(JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
(JSC::JSWebAssemblyCodeBlock::destroy):
(JSC::JSWebAssemblyCodeBlock::isSafeToRun):
(JSC::JSWebAssemblyCodeBlock::visitChildren):
(JSC::JSWebAssemblyCodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::setMemory):
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::module):
(JSC::JSWebAssemblyInstance::codeBlock):
(JSC::JSWebAssemblyInstance::memoryMode):
(JSC::JSWebAssemblyInstance::setMemory): Deleted.
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::create):
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::buffer):
(JSC::JSWebAssemblyMemory::grow):
(JSC::JSWebAssemblyMemory::destroy):
* wasm/js/JSWebAssemblyMemory.h:
(JSC::JSWebAssemblyMemory::memory):
(JSC::JSWebAssemblyMemory::offsetOfMemory):
(JSC::JSWebAssemblyMemory::offsetOfSize):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::buildCodeBlock):
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::codeBlock):
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::visitChildren):
(JSC::JSWebAssemblyModule::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::takeReservedMemory):
(JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::codeBlock):
(JSC::JSWebAssemblyModule::functionImportCount): Deleted.
(JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
(JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
(JSC::JSWebAssemblyModule::setJSEntrypointCallee): Deleted.
(JSC::JSWebAssemblyModule::setWasmEntrypointCallee): Deleted.
(JSC::JSWebAssemblyModule::callees): Deleted.
(JSC::JSWebAssemblyModule::offsetOfCallees): Deleted.
(JSC::JSWebAssemblyModule::allocationSize): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
2017-03-03 Mark Lam <mark.lam@apple.com>
Gardening: fix broken ARM64 build.
https://bugs.webkit.org/show_bug.cgi?id=169139
Not reviewed.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::excepnGenerationImmMask):
2017-03-03 Mark Lam <mark.lam@apple.com>
Add MacroAssembler::isBreakpoint() query function.
https://bugs.webkit.org/show_bug.cgi?id=169139
Reviewed by Michael Saboff.
This will be needed soon when we use breakpoint instructions to implement
non-polling VM traps, and need to discern between a VM trap signal and a genuine
assertion breakpoint.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::isBrk):
(JSC::ARM64Assembler::excepnGenerationImmMask):
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::isBkpt):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::isBkpt):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::isBkpt):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::isBreakpoint):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::isBreakpoint):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::isBreakpoint):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::isBreakpoint):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::isBreakpoint):
* assembler/X86Assembler.h:
(JSC::X86Assembler::isInt3):
2017-03-03 Mark Lam <mark.lam@apple.com>
We should only check for traps that we're able to handle.
https://bugs.webkit.org/show_bug.cgi?id=169136
Reviewed by Michael Saboff.
The execute methods in interpreter were checking for the existence of any traps
(without masking) and only handling a subset of those via a mask. This can
result in a failed assertion on debug builds.
This patch fixes this by applying the same mask for both the needTrapHandling()
check and the handleTraps() call. Also added a few assertions.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2017-03-02 Carlos Garcia Campos <cgarcia@igalia.com>
Remote Inspector: Move updateTargetListing() methods to RemoteInspector.cpp
https://bugs.webkit.org/show_bug.cgi?id=169074
Reviewed by Joseph Pecoraro.
They are not actually cocoa specific.
* inspector/remote/RemoteInspector.cpp:
(Inspector::RemoteInspector::updateTargetListing):
* inspector/remote/RemoteInspector.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2017-03-02 Mark Lam <mark.lam@apple.com>
Add WebKit2 hooks to notify the VM that the user has requested a debugger break.
https://bugs.webkit.org/show_bug.cgi?id=169089
Reviewed by Tim Horton and Joseph Pecoraro.
* runtime/VM.cpp:
(JSC::VM::handleTraps):
* runtime/VM.h:
(JSC::VM::notifyNeedDebuggerBreak):
2017-03-02 Michael Saboff <msaboff@apple.com>
Add JSC identity when code signing to allow debugging on iOS
https://bugs.webkit.org/show_bug.cgi?id=169099
Reviewed by Filip Pizlo.
* Configurations/JSC.xcconfig:
* Configurations/ToolExecutable.xcconfig:
2017-03-02 Keith Miller <keith_miller@apple.com>
WebAssemblyFunction should have Function.prototype as its prototype
https://bugs.webkit.org/show_bug.cgi?id=169101
Reviewed by Filip Pizlo.
Per https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects our JSWebAssemblyFunction
objects should have Function.prototype as their prototype.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2017-03-02 Mark Lam <mark.lam@apple.com>
Add Options::alwaysCheckTraps() and Options::usePollingTraps() options.
https://bugs.webkit.org/show_bug.cgi?id=169088
Reviewed by Keith Miller.
Options::alwaysCheckTraps() forces the op_check_traps bytecode to always be
generated. This is useful for testing purposes until we have signal based
traps, at which point, we will always emit the op_check_traps bytecode and remove
this option.
Options::usePollingTraps() enables the use of polling VM traps all the time.
This will be useful for benchmark comparisons, (between polling and non-polling
traps), as well as for forcing polling traps later for ports that don't support
signal based traps.
Note: signal based traps are not fully implemented yet. As a result, if the VM
watchdog is in use, we will force Options::usePollingTraps() to be true.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCheckTraps):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTraps):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2017-03-02 Keith Miller <keith_miller@apple.com>
Fix addressing mode for B3WasmAddress
https://bugs.webkit.org/show_bug.cgi?id=169092
Reviewed by Filip Pizlo.
Fix the potential addressing modes for B3WasmAddress. ARM does not
support a base + index*1 + offset addressing mode. I think when I
read it the first time I assumed it would always work on both ARM
and X86. While true for X86 it's not true for ARM.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
2017-03-02 Mark Lam <mark.lam@apple.com>
Add support for selective handling of VM traps.
https://bugs.webkit.org/show_bug.cgi?id=169087
Reviewed by Keith Miller.
This is needed because there are some places in the VM where it's appropriate to
handle some types of VM traps but not others.
We implement this selection by using a VMTraps::Mask that allows the user to
specify which traps should be serviced.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
* runtime/VM.cpp:
(JSC::VM::handleTraps):
* runtime/VM.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::takeTrap): Deleted.
* runtime/VMTraps.h:
(JSC::VMTraps::Mask::Mask):
(JSC::VMTraps::Mask::allEventTypes):
(JSC::VMTraps::Mask::bits):
(JSC::VMTraps::Mask::init):
(JSC::VMTraps::needTrapHandling):
(JSC::VMTraps::hasTrapForEvent):
2017-03-02 Alex Christensen <achristensen@webkit.org>
Continue enabling WebRTC
https://bugs.webkit.org/show_bug.cgi?id=169056
Reviewed by Jon Lee.
* Configurations/FeatureDefines.xcconfig:
2017-03-02 Tomas Popela <tpopela@redhat.com>
Incorrect RELEASE_ASSERT in JSGlobalObject::addStaticGlobals()
https://bugs.webkit.org/show_bug.cgi?id=169034
Reviewed by Mark Lam.
It should not assign to offset, but compare to offset.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addStaticGlobals):
2017-03-01 Alex Christensen <achristensen@webkit.org>
Unreviewed, rolling out r213259.
Broke an internal build
Reverted changeset:
"Continue enabling WebRTC"
https://bugs.webkit.org/show_bug.cgi?id=169056
http://trac.webkit.org/changeset/213259
2017-03-01 Alex Christensen <achristensen@webkit.org>
Continue enabling WebRTC
https://bugs.webkit.org/show_bug.cgi?id=169056
Reviewed by Jon Lee.
* Configurations/FeatureDefines.xcconfig:
2017-03-01 Michael Saboff <msaboff@apple.com>
Source/JavaScriptCore/ChangeLog
https://bugs.webkit.org/show_bug.cgi?id=169055
Reviewed by Mark Lam.
Made local copies of options strings for OptionRange and string typed options.
* runtime/Options.cpp:
(JSC::parse):
(JSC::OptionRange::init):
2017-03-01 Mark Lam <mark.lam@apple.com>
[Re-landing] Change JSLock to stash PlatformThread instead of std::thread::id.
https://bugs.webkit.org/show_bug.cgi?id=168996
Reviewed by Filip Pizlo and Saam Barati.
PlatformThread is more useful because it allows us to:
1. find the MachineThreads::Thread which is associated with it.
2. suspend / resume threads.
3. send a signal to a thread.
We can't do those with std::thread::id. We will need one or more of these
capabilities to implement non-polling VM traps later.
Update: Since we don't have a canonical "uninitialized" value for PlatformThread,
we now have a JSLock::m_hasOwnerThread flag that is set to true if and only the
m_ownerThread value is valid. JSLock::currentThreadIsHoldingLock() now checks
JSLock::m_hasOwnerThread before doing the thread identity comparison.
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::machineThreadForCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::getCurrentPlatformThread): Deleted.
* heap/MachineStackMarker.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/JSLock.cpp:
(JSC::JSLock::JSLock):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock): Deleted.
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/PlatformThread.h: Added.
(JSC::currentPlatformThread):
* runtime/VM.cpp:
(JSC::VM::~VM):
* runtime/VM.h:
(JSC::VM::ownerThread):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::shouldTerminate):
(JSC::Watchdog::startTimer):
(JSC::Watchdog::stopTimer):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
* tools/VMInspector.cpp:
2017-03-01 Saam Barati <sbarati@apple.com>
Implement a mega-disassembler that'll be used in the FTL
https://bugs.webkit.org/show_bug.cgi?id=168685
Reviewed by Mark Lam.
This patch extends the previous Air disassembler to print the
DFG and B3 nodes belonging to particular Air instructions.
The algorithm I'm using to do this is not perfect. For example,
it won't try to print the entire DFG/B3 graph. It'll just print
the related nodes for particular Air instructions. We can make the
algorithm more sophisticated as we get more experience looking at
these IR dumps and get a better feel for what we want out of them.
This is an example of the output:
...
...
200:<!0:-> InvalidationPoint(MustGen, W:SideState, Exits, bc#28, exit: bc#25 --> _getEntry#DlGw2r:<0x10276f980> bc#37)
Void @54 = Patchpoint(@29:ColdAny, @29:ColdAny, @53:ColdAny, DFG:@200, generator = 0x1015d6c18, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r19, %r20, %r21, %r22, %fp], resultConstraint = WarmAny, ExitsSideways|WritesPinned|ReadsPinned|Reads:Top)
Patch &Patchpoint2, %r20, %r20, %r0, @54
76:< 6:-> GetByOffset(KnownCell:@44, KnownCell:@44, JS|UseAsOther, Array, id3{_elementData}, 2, inferredType = Object, R:NamedProperties(3), Exits, bc#37) predicting Array
Int64 @57 = Load(@29, DFG:@76, offset = 32, ControlDependent|Reads:100...101)
Move 32(%r20), %r5, @57
0x389cc9ac0: ldur x5, [x20, #32]
115:<!0:-> CheckStructure(Cell:@76, MustGen, [0x1027eae20:[Array, {}, ArrayWithContiguous, Proto:0x1027e0140]], R:JSCell_structureID, Exits, bc#46)
Int32 @58 = Load(@57, DFG:@115, ControlDependent|Reads:16...17)
Move32 (%r5), %r1, @58
0x389cc9ac4: ldur w1, [x5]
Int32 @59 = Const32(DFG:@115, 92)
Int32 @60 = NotEqual(@58, $92(@59), DFG:@115)
Void @61 = Check(@60:WarmAny, @57:ColdAny, @29:ColdAny, @29:ColdAny, @53:ColdAny, @57:ColdAny, DFG:@115, generator = 0x1057991e0, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r5, %r19, %r20, %r21, %r22, %fp], ExitsSideways|Reads:Top)
Patch &Branch32(3,SameAsRep)1, NotEqual, %r1, $92, %r5, %r20, %r20, %r0, %r5, @61
0x389cc9ac8: cmp w1, #92
0x389cc9acc: b.ne 0x389cc9dac
117:< 2:-> GetButterfly(Cell:@76, Storage|PureInt, R:JSObject_butterfly, Exits, bc#46)
Int64 @64 = Load(@57, DFG:@117, offset = 8, ControlDependent|Reads:24...25)
Move 8(%r5), %r4, @64
0x389cc9ad0: ldur x4, [x5, #8]
79:< 2:-> GetArrayLength(KnownCell:@76, Untyped:@117, JS|PureInt|UseAsInt, Nonboolint32, Contiguous+OriginalArray+InBounds+AsIs, R:Butterfly_publicLength, Exits, bc#46)
Int32 @67 = Load(@64, DFG:@79, offset = -8, ControlDependent|Reads:3...4)
Move32 -8(%r4), %r2, @67
0x389cc9ad4: ldur w2, [x4, #-8]
192:< 1:-> JSConstant(JS|PureInt, Nonboolint32, Int32: -1, bc#0)
Int32 @68 = Const32(DFG:@192, -1)
Move $0xffffffffffffffff, %r1, $-1(@68)
0x389cc9ad8: mov x1, #-1
83:<!2:-> ArithAdd(Int32:Kill:@79, Int32:Kill:@192, Number|MustGen|PureInt|UseAsInt, Int32, Unchecked, Exits, bc#55)
Int32 @69 = Add(@67, $-1(@68), DFG:@83)
Add32 %r2, %r1, %r1, @69
0x389cc9adc: add w1, w2, w1
86:< 3:-> BitAnd(Check:Int32:@71, Int32:Kill:@83, Int32|UseAsOther|UseAsInt|ReallyWantsInt, Int32, Exits, bc#60)
Int32 @70 = Below(@53, $-281474976710656(@15), DFG:@86)
Void @71 = Check(@70:WarmAny, @53:ColdAny, @29:ColdAny, @29:ColdAny, @53:ColdAny, @69:ColdAny, DFG:@86, generator = 0x105799370, earlyClobbered = [], lateClobbered = [], usedRegisters = [%r0, %r1, %r2, %r4, %r5, %r19, %r20, %r21, %r22, %fp], ExitsSideways|Reads:Top)
Patch &Branch64(3,SameAsRep)0, Below, %r0, %r22, %r0, %r20, %r20, %r0, %r1, @71
0x389cc9ae0: cmp x0, x22
0x389cc9ae4: b.lo 0x389cc9dc0
Int32 @72 = Trunc(@53, DFG:@86)
Int32 @73 = BitAnd(@69, @72, DFG:@86)
And32 %r1, %r0, %r1, @73
0x389cc9ae8: and w1, w1, w0
16:<!0:-> PutStack(KnownInt32:@71, MustGen, loc27, machine:loc3, FlushedInt32, W:Stack(-28), bc#19)
Int32 @72 = Trunc(@53, DFG:@86)
Int64 @11 = SlotBase(stack0)
Void @76 = Store(@72, @11, DFG:@16, offset = 32, ControlDependent|Writes:94...95)
Move32 %r0, -64(%fp), @76
0x389cc9aec: stur w0, [fp, #-64]
12:<!0:-> PutStack(Untyped:@86, MustGen, loc28, machine:loc4, FlushedJSValue, W:Stack(-29), bc#19)
Int64 @77 = ZExt32(@73, DFG:@12)
Int64 @78 = Add(@77, $-281474976710656(@15), DFG:@12)
Add64 %r1, %r22, %r3, @78
0x389cc9af0: add x3, x1, x22
Int64 @11 = SlotBase(stack0)
Void @81 = Store(@78, @11, DFG:@12, offset = 24, ControlDependent|Writes:95...96)
Move %r3, -72(%fp), @81
0x389cc9af4: stur x3, [fp, #-72]
10:<!0:-> PutStack(KnownInt32:@46, MustGen, loc29, machine:loc5, FlushedInt32, W:Stack(-30), bc#19)
Int32 @82 = Trunc(@24, DFG:@10)
Int64 @11 = SlotBase(stack0)
Void @85 = Store(@82, @11, DFG:@10, offset = 16, ControlDependent|Writes:96...97)
Move32 %r21, -80(%fp), @85
0x389cc9af8: stur w21, [fp, #-80]
129:<!10:-> GetByVal(KnownCell:Kill:@76, Int32:Kill:@86, Untyped:Kill:@117, JS|MustGen|UseAsOther, FinalOther, Contiguous+OriginalArray+OutOfBounds+AsIs, R:World, W:Heap, Exits, ClobbersExit, bc#19) predicting FinalOther
Int32 @89 = AboveEqual(@73, @67, DFG:@129)
Void @90 = Branch(@89, DFG:@129, Terminal)
Branch32 AboveOrEqual, %r1, %r2, @90
0x389cc9afc: cmp w1, w2
0x389cc9b00: b.hs 0x389cc9bec
...
...
* b3/air/AirDisassembler.cpp:
(JSC::B3::Air::Disassembler::dump):
* b3/air/AirDisassembler.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
(JSC::FTL::DFG::LowerDFGToB3::lowJSValue):
2017-03-01 Mark Lam <mark.lam@apple.com>
REGRESSION (r213202?): Assertion failed: (!"initialized()"), function operator().
https://bugs.webkit.org/show_bug.cgi?id=169042
Not reviewed.
Rolling out r213229 and r213202.
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/MachineStackMarker.cpp:
(JSC::getCurrentPlatformThread):
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::machineThreadForCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
* heap/MachineStackMarker.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/JSLock.cpp:
(JSC::JSLock::JSLock):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::currentThreadIsHoldingLock): Deleted.
* runtime/PlatformThread.h: Removed.
* runtime/VM.cpp:
(JSC::VM::~VM):
* runtime/VM.h:
(JSC::VM::ownerThread):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::shouldTerminate):
(JSC::Watchdog::startTimer):
(JSC::Watchdog::stopTimer):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
* tools/VMInspector.cpp:
2017-03-01 Mark Lam <mark.lam@apple.com>
REGRESSION (r213202?): Assertion failed: (!"initialized()"), function operator()
https://bugs.webkit.org/show_bug.cgi?id=169042
Reviewed by Filip Pizlo.
* runtime/JSLock.h:
(JSC::JSLock::currentThreadIsHoldingLock):
2017-02-28 Brian Burg <bburg@apple.com>
REGRESSION(r211344): Remote Inspector: listingForAutomationTarget() is called off-main-thread, causing assertions
https://bugs.webkit.org/show_bug.cgi?id=168695
<rdar://problem/30643899>
Reviewed by Joseph Pecoraro.
The aforementioned commit added some new calls to update target listings. This causes RemoteInspector
to update some listings underneath an incoming setup message on the XPC queue, which is not a safe place
to gather listing information for RemoteAutomationTargets.
Update the listing asynchronously since we don't need it immediately. Since this really only happens when
the connection to the target is set up and shut down, we can trigger listings to be refreshed from
the async block that's called on the target's queue inside RemoteConnectionToTarget::{setup,close}.
* inspector/remote/RemoteInspector.h:
Make updateListingForTarget(unsigned) usable from RemoteConnectionToTarget.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
Grab the target identifier while the RemoteControllableTarget pointer is still valid,
and use it inside the block later after it may have been destructed already. If that happens,
then updateTargetListing will bail out because the targetIdentifier cannot be found in the mapping.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::updateTargetListing):
We need to make sure to request a listing push after the target is updated, so implicitly call
pushListingsSoon() from here. That method doesn't require any particular queue or holding a lock.
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDidCloseMessage):
(Inspector::RemoteInspector::receivedConnectionDiedMessage):
Remove calls to updateTargetListing() and pushListingsSoon(), as these happen implicitly
and asynchronously on the target's queue when the connection to target is opened or closed.
2017-03-01 Tomas Popela <tpopela@redhat.com>
Leak under Options::setOptions
https://bugs.webkit.org/show_bug.cgi?id=169029
Reviewed by Michael Saboff.
Don't leak the optionsStrCopy variable.
* runtime/Options.cpp:
(JSC::Options::setOptions):
2017-03-01 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Allow UnlinkedCodeBlock to dump its bytecode sequence
https://bugs.webkit.org/show_bug.cgi?id=168968
Reviewed by Saam Barati.
This patch decouples dumping bytecode sequence from CodeBlock.
This change allows UnlinkedCodeBlock to dump its bytecode sequence.
It is useful because we now have complex phase between UnlinkedCodeBlock and CodeBlock,
called Generatorification.
We introduce BytecodeDumper<Block>. Both CodeBlock and UnlinkedCodeBlock can use
this class to dump bytecode sequence.
And this patch also adds Option::dumpBytecodesBeforeGeneratorification,
which dumps unlinked bytecode sequence before generatorification if it is enabled.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeDumper.cpp: Added.
(JSC::getStructureID):
(JSC::getSpecialPointer):
(JSC::getPutByIdFlags):
(JSC::getToThisStatus):
(JSC::getPointer):
(JSC::getStructureChain):
(JSC::getStructure):
(JSC::getCallLinkInfo):
(JSC::getBasicBlockLocation):
(JSC::BytecodeDumper<Block>::actualPointerFor):
(JSC::BytecodeDumper<CodeBlock>::actualPointerFor):
(JSC::beginDumpProfiling):
(JSC::BytecodeDumper<Block>::dumpValueProfiling):
(JSC::BytecodeDumper<CodeBlock>::dumpValueProfiling):
(JSC::BytecodeDumper<Block>::dumpArrayProfiling):
(JSC::BytecodeDumper<CodeBlock>::dumpArrayProfiling):
(JSC::BytecodeDumper<Block>::dumpProfilesForBytecodeOffset):
(JSC::dumpRareCaseProfile):
(JSC::dumpArithProfile):
(JSC::BytecodeDumper<CodeBlock>::dumpProfilesForBytecodeOffset):
(JSC::BytecodeDumper<Block>::vm):
(JSC::BytecodeDumper<Block>::identifier):
(JSC::regexpToSourceString):
(JSC::regexpName):
(JSC::printLocationAndOp):
(JSC::isConstantRegisterIndex):
(JSC::debugHookName):
(JSC::BytecodeDumper<Block>::registerName):
(JSC::idName):
(JSC::BytecodeDumper<Block>::constantName):
(JSC::BytecodeDumper<Block>::printUnaryOp):
(JSC::BytecodeDumper<Block>::printBinaryOp):
(JSC::BytecodeDumper<Block>::printConditionalJump):
(JSC::BytecodeDumper<Block>::printGetByIdOp):
(JSC::dumpStructure):
(JSC::dumpChain):
(JSC::BytecodeDumper<Block>::printGetByIdCacheStatus):
(JSC::BytecodeDumper<Block>::printPutByIdCacheStatus):
(JSC::BytecodeDumper<Block>::dumpCallLinkStatus):
(JSC::BytecodeDumper<CodeBlock>::dumpCallLinkStatus):
(JSC::BytecodeDumper<Block>::printCallOp):
(JSC::BytecodeDumper<Block>::printPutByIdOp):
(JSC::BytecodeDumper<Block>::printLocationOpAndRegisterOperand):
(JSC::BytecodeDumper<Block>::dumpBytecode):
(JSC::BytecodeDumper<Block>::dumpIdentifiers):
(JSC::BytecodeDumper<Block>::dumpConstants):
(JSC::BytecodeDumper<Block>::dumpRegExps):
(JSC::BytecodeDumper<Block>::dumpExceptionHandlers):
(JSC::BytecodeDumper<Block>::dumpSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables):
(JSC::BytecodeDumper<Block>::dumpBlock):
* bytecode/BytecodeDumper.h: Added.
(JSC::BytecodeDumper::BytecodeDumper):
(JSC::BytecodeDumper::block):
(JSC::BytecodeDumper::instructionsBegin):
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::BytecodeGeneratorification):
(JSC::performGeneratorification):
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::hasOpDebugForLineAndColumn):
(JSC::CodeBlock::usesOpcode):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::arithProfileForPC):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::constantRegisters):
(JSC::CodeBlock::numberOfRegExps):
(JSC::CodeBlock::bitVectors):
(JSC::CodeBlock::bitVector):
* bytecode/HandlerInfo.h:
(JSC::HandlerInfoBase::typeName):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::dump):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::getConstant):
* bytecode/UnlinkedInstructionStream.cpp:
(JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
* bytecode/UnlinkedInstructionStream.h:
(JSC::UnlinkedInstructionStream::Reader::next):
* runtime/Options.h:
2017-02-28 Mark Lam <mark.lam@apple.com>
Change JSLock to stash PlatformThread instead of std::thread::id.
https://bugs.webkit.org/show_bug.cgi?id=168996
Reviewed by Filip Pizlo.
PlatformThread is more useful because it allows us to:
1. find the MachineThreads::Thread which is associated with it.
2. suspend / resume threads.
3. send a signal to a thread.
We can't do those with std::thread::id. We will need one or more of these
capabilities to implement non-polling VM traps later.
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::Thread::createForCurrentThread):
(JSC::MachineThreads::machineThreadForCurrentThread):
(JSC::MachineThreads::removeThread):
(JSC::MachineThreads::Thread::suspend):
(JSC::MachineThreads::tryCopyOtherThreadStacks):
(JSC::getCurrentPlatformThread): Deleted.
* heap/MachineStackMarker.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/JSLock.cpp:
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock): Deleted.
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::currentThreadIsHoldingLock):
* runtime/PlatformThread.h: Added.
(JSC::currentPlatformThread):
* runtime/VM.cpp:
(JSC::VM::~VM):
* runtime/VM.h:
(JSC::VM::ownerThread):
* runtime/Watchdog.cpp:
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::shouldTerminate):
(JSC::Watchdog::startTimer):
(JSC::Watchdog::stopTimer):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
* tools/VMInspector.cpp:
2017-02-28 Mark Lam <mark.lam@apple.com>
Enable the SigillCrashAnalyzer by default for iOS.
https://bugs.webkit.org/show_bug.cgi?id=168989
Reviewed by Keith Miller.
* runtime/Options.cpp:
(JSC::overrideDefaults):
2017-02-28 Mark Lam <mark.lam@apple.com>
Remove setExclusiveThread() and peers from the JSLock.
https://bugs.webkit.org/show_bug.cgi?id=168977
Reviewed by Filip Pizlo.
JSLock::setExclusiveThread() was only used by WebCore. Benchmarking with
Speedometer, we see that removal of exclusive thread status has no measurable
impact on performance. So, let's remove the code for handling exclusive thread
status, and simplify the JSLock code.
For the records, exclusive thread status does improve JSLock locking/unlocking
time by up to 20%. However, this difference is not measurable in the way WebCore
uses the JSLock as confirmed by Speedometer.
Also applied a minor optimization in JSLock::lock() to assume the initial lock
entry case (as opposed to the re-entry case). This appears to shows a small
fractional improvement (about 5%) in JSLock cumulative locking and unlocking
time in a micro-benchmark.
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::MachineThreads):
(JSC::MachineThreads::addCurrentThread):
* heap/MachineStackMarker.h:
* runtime/JSLock.cpp:
(JSC::JSLock::JSLock):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock):
(JSC::JSLock::dropAllLocks):
(JSC::JSLock::grabAllLocks):
(JSC::JSLock::setExclusiveThread): Deleted.
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
(JSC::JSLock::hasExclusiveThread): Deleted.
(JSC::JSLock::exclusiveThread): Deleted.
* runtime/VM.h:
(JSC::VM::hasExclusiveThread): Deleted.
(JSC::VM::exclusiveThread): Deleted.
(JSC::VM::setExclusiveThread): Deleted.
2017-02-28 Saam Barati <sbarati@apple.com>
Arm64 disassembler prints "ars" instead of "asr"
https://bugs.webkit.org/show_bug.cgi?id=168923
Rubber stamped by Michael Saboff.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeBitfield::format):
2017-02-28 Oleksandr Skachkov <gskachkov@gmail.com>
Use of arguments in arrow function is slow
https://bugs.webkit.org/show_bug.cgi?id=168829
Reviewed by Saam Barati.
Current patch improves performance access to arguments within arrow functuion
by preventing create arguments variable within arrow function, also allow to cache
arguments variable. Before arguments variable always have Dynamic resolve type, after
patch it can be ClosureVar, that increase performance of access to arguments variable
in 9 times inside of the arrow function.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
2017-02-28 Michael Saboff <msaboff@apple.com>
Add ability to configure JSC options from a file
https://bugs.webkit.org/show_bug.cgi?id=168914
Reviewed by Filip Pizlo.
Added the ability to set options and DataLog file location via a configuration file.
The configuration file is specified with the --configFile option to JSC or the
JSC_configFile environment variable.
The file format allows for options conditionally dependent on various attributes.
Currently those attributes are the process name, parent process name and build
type (Release or Debug). In this patch, the parent process type is not set.
That will be set up in WebKit code with a follow up patch.
Here is an example config file:
logFile = "/tmp/jscLog.%pid.txt"
jscOptions {
dumpOptions = 2
}
build == "Debug" {
jscOptions {
useConcurrentJIT = false
dumpDisassembly = true
}
}
build == "Release" && processName == "jsc" {
jscOptions {
asyncDisassembly = true
}
}
Eliminated the prior options file code.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(jscmain):
* runtime/ConfigFile.cpp: Added.
(JSC::ConfigFileScanner::ConfigFileScanner):
(JSC::ConfigFileScanner::start):
(JSC::ConfigFileScanner::lineNumber):
(JSC::ConfigFileScanner::currentBuffer):
(JSC::ConfigFileScanner::atFileEnd):
(JSC::ConfigFileScanner::tryConsume):
(JSC::ConfigFileScanner::tryConsumeString):
(JSC::ConfigFileScanner::tryConsumeUpto):
(JSC::ConfigFileScanner::fillBufferIfNeeded):
(JSC::ConfigFileScanner::fillBuffer):
(JSC::ConfigFile::ConfigFile):
(JSC::ConfigFile::setProcessName):
(JSC::ConfigFile::setParentProcessName):
(JSC::ConfigFile::parse):
* runtime/ConfigFile.h: Added.
* runtime/Options.cpp:
(JSC::Options::initialize):
(JSC::Options::setOptions):
* runtime/Options.h:
2017-02-27 Alex Christensen <achristensen@webkit.org>
Begin enabling WebRTC on 64-bit
https://bugs.webkit.org/show_bug.cgi?id=168915
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2017-02-27 Mark Lam <mark.lam@apple.com>
Introduce a VM Traps mechanism and refactor Watchdog to use it.
https://bugs.webkit.org/show_bug.cgi?id=168842
Reviewed by Filip Pizlo.
Currently, the traps mechanism is only used for the JSC watchdog, and for
asynchronous termination requests (which is currently only used for worker
threads termination).
This first cut of the traps mechanism still relies on polling from DFG and FTL
code. This is done to keep the patch as small as possible. The work to do
a non-polling version of the traps mechanism for DFG and FTL code is deferred to
another patch.
In this patch, worker threads still need to set the VM::m_needAsynchronousTerminationSupport
flag to enable the traps polling in the DFG and FTL code. When we have the
non-polling version of the DFG and FTL traps mechanism, we can remove the use of
the VM::m_needAsynchronousTerminationSupport flag.
Note: this patch also separates asynchronous termination support from the JSC
watchdog. This separation allows us to significantly simplify the locking
requirements in the watchdog code, and make it easier to reason about its
correctness.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitLoopHint):
(JSC::BytecodeGenerator::emitCheckTraps):
(JSC::BytecodeGenerator::emitWatchdog): Deleted.
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTraps):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer): Deleted.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_check_traps):
(JSC::JIT::emitSlow_op_check_traps):
(JSC::JIT::emit_op_watchdog): Deleted.
(JSC::JIT::emitSlow_op_watchdog): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/VM.cpp:
(JSC::VM::~VM):
(JSC::VM::ensureWatchdog):
(JSC::VM::handleTraps):
* runtime/VM.h:
(JSC::VM::ownerThread):
(JSC::VM::needTrapHandling):
(JSC::VM::needTrapHandlingAddress):
(JSC::VM::notifyNeedTermination):
(JSC::VM::notifyNeedWatchdogCheck):
(JSC::VM::needAsynchronousTerminationSupport):
(JSC::VM::setNeedAsynchronousTerminationSupport):
* runtime/VMInlines.h:
(JSC::VM::shouldTriggerTermination): Deleted.
* runtime/VMTraps.cpp: Added.
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::takeTrap):
* runtime/VMTraps.h: Added.
(JSC::VMTraps::needTrapHandling):
(JSC::VMTraps::needTrapHandlingAddress):
(JSC::VMTraps::hasTrapForEvent):
(JSC::VMTraps::setTrapForEvent):
(JSC::VMTraps::clearTrapForEvent):
* runtime/Watchdog.cpp:
(JSC::Watchdog::Watchdog):
(JSC::Watchdog::setTimeLimit):
(JSC::Watchdog::shouldTerminate):
(JSC::Watchdog::enteredVM):
(JSC::Watchdog::exitedVM):
(JSC::Watchdog::startTimer):
(JSC::Watchdog::stopTimer):
(JSC::Watchdog::willDestroyVM):
(JSC::Watchdog::terminateSoon): Deleted.
(JSC::Watchdog::shouldTerminateSlow): Deleted.
* runtime/Watchdog.h:
(JSC::Watchdog::shouldTerminate): Deleted.
(JSC::Watchdog::timerDidFireAddress): Deleted.
2017-02-27 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r213019.
https://bugs.webkit.org/show_bug.cgi?id=168925
"It broke 32-bit jsc tests in debug builds" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"op_get_by_id_with_this should use inline caching"
https://bugs.webkit.org/show_bug.cgi?id=162124
http://trac.webkit.org/changeset/213019
2017-02-27 JF Bastien <jfbastien@apple.com>
WebAssembly: miscellaneous spec fixes part deux
https://bugs.webkit.org/show_bug.cgi?id=168861
Reviewed by Keith Miller.
* wasm/WasmFunctionParser.h: add some FIXME
2017-02-27 Alex Christensen <achristensen@webkit.org>
[libwebrtc] Enable WebRTC in some Production Builds
https://bugs.webkit.org/show_bug.cgi?id=168858
* Configurations/FeatureDefines.xcconfig:
2017-02-26 Caio Lima <ticaiolima@gmail.com>
op_get_by_id_with_this should use inline caching
https://bugs.webkit.org/show_bug.cgi?id=162124
Reviewed by Saam Barati.
This patch is enabling inline cache for op_get_by_id_with_this in all
tiers. It means that operations using ```super.member``` are going to
be able to be optimized by PIC. To enable it, we introduced a new
member of StructureStubInfo.patch named thisGPR, created a new class
to manage the IC named JITGetByIdWithThisGenerator and changed
PolymorphicAccess.regenerate that uses StructureStubInfo.patch.thisGPR
to decide the correct this value on inline caches.
With inline cached enabled, ```super.member``` are ~4.5x faster,
according microbenchmarks.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addGetByIdWithThis):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compileIn):
(JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITByIdGenerator::JITByIdGenerator):
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
(JSC::JITGetByIdWithThisGenerator::generateFastPath):
* jit/JITInlineCacheGenerator.h:
(JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emitSlow_op_get_by_id_with_this):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByIdFunction):
(JSC::appropriateGenericGetByIdFunction):
(JSC::tryCacheGetByID):
* jit/Repatch.h:
* jsc.cpp:
(WTF::CustomGetter::getOwnPropertySlot):
(WTF::CustomGetter::customGetterAcessor):
2017-02-24 JF Bastien <jfbastien@apple.com>
WebAssembly: miscellaneous spec fixes
https://bugs.webkit.org/show_bug.cgi?id=168822
Reviewed by Saam Barati.
* wasm/WasmModuleParser.cpp: "unknown" sections are now called "custom" sections
* wasm/WasmSections.h:
(JSC::Wasm::validateOrder):
(JSC::Wasm::makeString): fix ASSERT_UNREACHABLE bug in printing
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): disallow i64 import
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link): disallow i64 export
(JSC::WebAssemblyModuleRecord::evaluate):
2017-02-24 Filip Pizlo <fpizlo@apple.com>
Move Arg::Type and Arg::Width out into the B3 namespace, since they are general concepts
https://bugs.webkit.org/show_bug.cgi?id=168833
Reviewed by Saam Barati.
I want to use the Air::Arg::Type and Air::Arg::Width concepts in B3. We are already
doing this a bit, and it's akward because of the namespacing. Throughout B3 we take the
approach that if something is not specific to Air, then it should be in the B3
namespace.
This moves Air::Arg::Type to B3::Bank. This moves Air::Arg::Width to B3::Width.
I renamed Arg::Type to Bank because there is already a B3::Type and because Arg::Type
was never really a type. Its purpose was always to identify register banks, and we use
this enum when the thing we care about is whether the value is most appropriate for
GPRs or FPRs.
I kept both as non-enum classes because I think that we've learned that terse compiler
code is a good thing. I don't want to say Bank::GP when I can say GP. With Width, the
argument is even stronger, since you cannot say Width::8 but you can say Width8.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Bank.cpp: Added.
(WTF::printInternal):
* b3/B3Bank.h: Added.
(JSC::B3::forEachBank):
(JSC::B3::bankForType):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::forEachArg):
* b3/B3LegalizeMemoryOffsets.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::run):
(JSC::B3::Air::LowerToAir::tmp):
(JSC::B3::Air::LowerToAir::scaleForShl):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::addr):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::accessWidth):
* b3/B3MemoryValue.h:
* b3/B3MoveConstants.cpp:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3Value.h:
* b3/B3Variable.h:
(JSC::B3::Variable::width):
(JSC::B3::Variable::bank):
* b3/B3WasmAddressValue.h:
* b3/B3Width.cpp: Added.
(WTF::printInternal):
* b3/B3Width.h: Added.
(JSC::B3::pointerWidth):
(JSC::B3::widthForType):
(JSC::B3::conservativeWidth):
(JSC::B3::minimumWidth):
(JSC::B3::bytes):
(JSC::B3::widthForBytes):
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirAllocateStack.cpp:
(JSC::B3::Air::allocateStack):
* b3/air/AirArg.cpp:
(JSC::B3::Air::Arg::canRepresent):
(JSC::B3::Air::Arg::isCompatibleBank):
(JSC::B3::Air::Arg::isCompatibleType): Deleted.
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::hasBank):
(JSC::B3::Air::Arg::bank):
(JSC::B3::Air::Arg::isBank):
(JSC::B3::Air::Arg::forEachTmp):
(JSC::B3::Air::Arg::forEachType): Deleted.
(JSC::B3::Air::Arg::pointerWidth): Deleted.
(JSC::B3::Air::Arg::typeForB3Type): Deleted.
(JSC::B3::Air::Arg::widthForB3Type): Deleted.
(JSC::B3::Air::Arg::conservativeWidth): Deleted.
(JSC::B3::Air::Arg::minimumWidth): Deleted.
(JSC::B3::Air::Arg::bytes): Deleted.
(JSC::B3::Air::Arg::widthForBytes): Deleted.
(JSC::B3::Air::Arg::hasType): Deleted.
(JSC::B3::Air::Arg::type): Deleted.
(JSC::B3::Air::Arg::isType): Deleted.
* b3/air/AirArgInlines.h:
(JSC::B3::Air::ArgThingHelper<Tmp>::forEach):
(JSC::B3::Air::ArgThingHelper<Arg>::forEach):
(JSC::B3::Air::ArgThingHelper<Reg>::forEach):
(JSC::B3::Air::Arg::forEach):
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::forEachArg):
* b3/air/AirCCallingConvention.cpp:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
(JSC::B3::Air::Code::setRegsInPriorityOrder):
(JSC::B3::Air::Code::pinRegister):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::regsInPriorityOrder):
(JSC::B3::Air::Code::newTmp):
(JSC::B3::Air::Code::numTmps):
(JSC::B3::Air::Code::regsInPriorityOrderImpl):
* b3/air/AirCustom.cpp:
(JSC::B3::Air::PatchCustom::isValidForm):
(JSC::B3::Air::ShuffleCustom::isValidForm):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::forEachArg):
(JSC::B3::Air::CCallCustom::forEachArg):
(JSC::B3::Air::ColdCCallCustom::forEachArg):
(JSC::B3::Air::ShuffleCustom::forEachArg):
(JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
* b3/air/AirDumpAsJS.cpp:
(JSC::B3::Air::dumpAsJS):
* b3/air/AirEliminateDeadCode.cpp:
(JSC::B3::Air::eliminateDeadCode):
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h:
(JSC::B3::Air::ShufflePair::ShufflePair):
(JSC::B3::Air::ShufflePair::width):
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirFixPartialRegisterStalls.cpp:
(JSC::B3::Air::fixPartialRegisterStalls):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::hasArgEffects):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::forEachTmp):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::forEach):
(JSC::B3::Air::Inst::forEachDef):
(JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
* b3/air/AirLiveness.h:
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
(JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
(JSC::B3::Air::TmpLivenessAdapter::indexToValue):
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
(JSC::B3::Air::RegLivenessAdapter::acceptsBank):
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::AbstractLiveness::LocalCalc::execute):
(JSC::B3::Air::TmpLivenessAdapter::acceptsType): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::acceptsType): Deleted.
(JSC::B3::Air::RegLivenessAdapter::acceptsType): Deleted.
* b3/air/AirLogRegisterPressure.cpp:
(JSC::B3::Air::logRegisterPressure):
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerMacros.cpp:
(JSC::B3::Air::lowerMacros):
* b3/air/AirPadInterference.cpp:
(JSC::B3::Air::padInterference):
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::absoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::lastMachineRegisterIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpMapper<Arg::GP>::tmpFromAbsoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::absoluteIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::lastMachineRegisterIndex): Deleted.
(JSC::B3::Air::AbsoluteTmpMapper<Arg::FP>::tmpFromAbsoluteIndex): Deleted.
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* b3/air/AirTmpWidth.h:
(JSC::B3::Air::TmpWidth::width):
(JSC::B3::Air::TmpWidth::requiredWidth):
(JSC::B3::Air::TmpWidth::defWidth):
(JSC::B3::Air::TmpWidth::useWidth):
(JSC::B3::Air::TmpWidth::Widths::Widths):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* b3/air/AirValidate.cpp:
* b3/air/opcode_generator.rb:
* b3/air/testair.cpp:
(JSC::B3::Air::compile): Deleted.
(JSC::B3::Air::invoke): Deleted.
(JSC::B3::Air::compileAndRun): Deleted.
(JSC::B3::Air::testSimple): Deleted.
(JSC::B3::Air::loadConstantImpl): Deleted.
(JSC::B3::Air::loadConstant): Deleted.
(JSC::B3::Air::loadDoubleConstant): Deleted.
(JSC::B3::Air::testShuffleSimpleSwap): Deleted.
(JSC::B3::Air::testShuffleSimpleShift): Deleted.
(JSC::B3::Air::testShuffleLongShift): Deleted.
(JSC::B3::Air::testShuffleLongShiftBackwards): Deleted.
(JSC::B3::Air::testShuffleSimpleRotate): Deleted.
(JSC::B3::Air::testShuffleSimpleBroadcast): Deleted.
(JSC::B3::Air::testShuffleBroadcastAllRegs): Deleted.
(JSC::B3::Air::testShuffleTreeShift): Deleted.
(JSC::B3::Air::testShuffleTreeShiftBackward): Deleted.
(JSC::B3::Air::testShuffleTreeShiftOtherBackward): Deleted.
(JSC::B3::Air::testShuffleMultipleShifts): Deleted.
(JSC::B3::Air::testShuffleRotateWithFringe): Deleted.
(JSC::B3::Air::testShuffleRotateWithFringeInWeirdOrder): Deleted.
(JSC::B3::Air::testShuffleRotateWithLongFringe): Deleted.
(JSC::B3::Air::testShuffleMultipleRotates): Deleted.
(JSC::B3::Air::testShuffleShiftAndRotate): Deleted.
(JSC::B3::Air::testShuffleShiftAllRegs): Deleted.
(JSC::B3::Air::testShuffleRotateAllRegs): Deleted.
(JSC::B3::Air::testShuffleSimpleSwap64): Deleted.
(JSC::B3::Air::testShuffleSimpleShift64): Deleted.
(JSC::B3::Air::testShuffleSwapMixedWidth): Deleted.
(JSC::B3::Air::testShuffleShiftMixedWidth): Deleted.
(JSC::B3::Air::testShuffleShiftMemory): Deleted.
(JSC::B3::Air::testShuffleShiftMemoryLong): Deleted.
(JSC::B3::Air::testShuffleShiftMemoryAllRegs): Deleted.
(JSC::B3::Air::testShuffleShiftMemoryAllRegs64): Deleted.
(JSC::B3::Air::combineHiLo): Deleted.
(JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth): Deleted.
(JSC::B3::Air::testShuffleRotateMemory): Deleted.
(JSC::B3::Air::testShuffleRotateMemory64): Deleted.
(JSC::B3::Air::testShuffleRotateMemoryMixedWidth): Deleted.
(JSC::B3::Air::testShuffleRotateMemoryAllRegs64): Deleted.
(JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth): Deleted.
(JSC::B3::Air::testShuffleSwapDouble): Deleted.
(JSC::B3::Air::testShuffleShiftDouble): Deleted.
(JSC::B3::Air::testX86VMULSD): Deleted.
(JSC::B3::Air::testX86VMULSDDestRex): Deleted.
(JSC::B3::Air::testX86VMULSDOp1DestRex): Deleted.
(JSC::B3::Air::testX86VMULSDOp2DestRex): Deleted.
(JSC::B3::Air::testX86VMULSDOpsDestRex): Deleted.
(JSC::B3::Air::testX86VMULSDAddr): Deleted.
(JSC::B3::Air::testX86VMULSDAddrOpRexAddr): Deleted.
(JSC::B3::Air::testX86VMULSDDestRexAddr): Deleted.
(JSC::B3::Air::testX86VMULSDRegOpDestRexAddr): Deleted.
(JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr): Deleted.
(JSC::B3::Air::testX86VMULSDBaseNeedsRex): Deleted.
(JSC::B3::Air::testX86VMULSDIndexNeedsRex): Deleted.
(JSC::B3::Air::testX86VMULSDBaseIndexNeedRex): Deleted.
(JSC::B3::Air::run): Deleted.
2017-02-24 Keith Miller <keith_miller@apple.com>
We should be able to use std::tuples as keys in HashMap
https://bugs.webkit.org/show_bug.cgi?id=168805
Reviewed by Filip Pizlo.
Convert the mess of std::pairs we used as the keys in PrototypeMap
to a std::tuple. I also plan on using this for a HashMap in wasm.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::createEmptyStructure):
(JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
* runtime/PrototypeMap.h:
2017-02-24 Saam Barati <sbarati@apple.com>
Unreviewed. Remove inaccurate copy-paste comment from r212939.
* dfg/DFGOperations.cpp:
2017-02-23 Saam Barati <sbarati@apple.com>
Intrinsicify parseInt
https://bugs.webkit.org/show_bug.cgi?id=168627
Reviewed by Filip Pizlo.
This patch makes parseInt an intrinsic in the DFG and FTL.
We do our best to eliminate this node. If we speculate that
the first operand to the operation is an int32, and that there
isn't a second operand, we convert to the identity of the first
operand. That's because parseInt(someInt) === someInt.
If the first operand is proven to be an integer, and the second
operand is the integer 0 or the integer 10, we can eliminate the
node by making it an identity over its first operand. That's
because parseInt(someInt, 0) === someInt and parseInt(someInt, 10) === someInt.
If we are not able to constant fold the node away, we try to remove
checks. The most common use case of parseInt is that its first operand
is a proven string. The DFG might be able to remove type checks in this
case. We also set up CSE rules for parseInt(someString, someIntRadix)
because it's a "pure" operation (modulo resolving a rope).
This looks to be a 4% Octane/Box2D progression.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::parseIntResult):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileParseInt):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::appendCallSetResult):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileParseInt):
* jit/JITOperations.h:
* parser/Lexer.cpp:
* runtime/ErrorInstance.cpp:
* runtime/Intrinsic.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::toStringView): Deleted.
(JSC::isStrWhiteSpace): Deleted.
(JSC::parseDigit): Deleted.
(JSC::parseIntOverflow): Deleted.
(JSC::parseInt): Deleted.
* runtime/JSGlobalObjectFunctions.h:
* runtime/ParseInt.h: Added.
(JSC::parseDigit):
(JSC::parseIntOverflow):
(JSC::isStrWhiteSpace):
(JSC::parseInt):
(JSC::toStringView):
* runtime/StringPrototype.cpp:
2017-02-23 JF Bastien <jfbastien@apple.com>
WebAssembly: support 0x1 version
https://bugs.webkit.org/show_bug.cgi?id=168672
Reviewed by Keith Miller.
* wasm/wasm.json: update the version number, everything is based
on its value
2017-02-23 Saam Barati <sbarati@apple.com>
Make Briggs fixpoint validation run only with validateGraphAtEachPhase
https://bugs.webkit.org/show_bug.cgi?id=168795
Rubber stamped by Keith Miller.
The Briggs allocator was running intensive validation
on each step of the fixpoint. Instead, it now will just
do it when shouldValidateIRAtEachPhase() is true because
doing this for all !ASSERT_DISABLED builds takes too long.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
2017-02-23 Filip Pizlo <fpizlo@apple.com>
SpeculativeJIT::compilePutByValForIntTypedArray should only do the constant-folding optimization when the constant passes the type check
https://bugs.webkit.org/show_bug.cgi?id=168787
Reviewed by Michael Saboff and Mark Lam.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
2017-02-23 Mark Lam <mark.lam@apple.com>
Ensure that the end of the last invalidation point does not extend beyond the end of the buffer.
https://bugs.webkit.org/show_bug.cgi?id=168786
Reviewed by Filip Pizlo.
In practice, we will always have multiple instructions after invalidation points,
and have enough room in the JIT buffer for the invalidation point to work with.
However, as a precaution, we can guarantee that there's enough room by always
emitting a label just before we link the buffer. The label will emit nop padding
if needed.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::linkCode):
2017-02-23 Keith Miller <keith_miller@apple.com>
Unreviewed, fix the cloop build. Needed a #if.
* jit/ExecutableAllocator.cpp:
2017-02-22 Carlos Garcia Campos <cgarcia@igalia.com>
Better handle Thread and RunLoop initialization
https://bugs.webkit.org/show_bug.cgi?id=167828
Reviewed by Yusuke Suzuki.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading): Do not initialize double_conversion, that is already initialized by WTF, and GC
threads that will be initialized by WTF main thread when needed.
2017-02-22 JF Bastien <jfbastien@apple.com>
WebAssembly: clear out insignificant i32 bits when calling JavaScript
https://bugs.webkit.org/show_bug.cgi?id=166677
Reviewed by Keith Miller.
When WebAssembly calls JavaScript it needs to clear out the
insignificant bits of int32 values:
+------------------- tag
| +---------------- insignificant
| | +------------ 32-bit integer value
| | |
|--|---|-------|
0xffff0000ffffffff
At least some JavaScript code assumes that these bits are all
zero. In the wasm-to-wasm.js example we store a 64-bit value in an
object with lo / hi fields, each containing 32-bit integers. We
then load these back, and the baseline compiler fails its
comparison because it first checks the value are the same type
(yes, because the int32 tag is set in both), and then whether they
have the same value (no, because comparing the two registers
fails). We could argue that the baseline compiler is wrong for
performing a 64-bit comparison, but it doesn't really matter
because there's not much of a point in breaking that invariant for
WebAssembly's sake.
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
2017-02-22 Keith Miller <keith_miller@apple.com>
Remove the demand executable allocator
https://bugs.webkit.org/show_bug.cgi?id=168754
Reviewed by Saam Barati.
We currently only use the demand executable allocator for non-iOS 32-bit platforms.
Benchmark results on a MBP indicate there is no appreciable performance difference
between a the fixed and demand allocators. In a future patch I will go back through
this code and remove more of the abstractions.
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/ExecutableAllocator.cpp:
(JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
(JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
(JSC::ExecutableAllocator::initializeAllocator):
(JSC::ExecutableAllocator::ExecutableAllocator):
(JSC::FixedVMPoolExecutableAllocator::~FixedVMPoolExecutableAllocator):
(JSC::ExecutableAllocator::isValid):
(JSC::ExecutableAllocator::underMemoryPressure):
(JSC::ExecutableAllocator::memoryPressureMultiplier):
(JSC::ExecutableAllocator::allocate):
(JSC::ExecutableAllocator::isValidExecutableMemory):
(JSC::ExecutableAllocator::getLock):
(JSC::ExecutableAllocator::committedByteCount):
(JSC::ExecutableAllocator::dumpProfile):
(JSC::DemandExecutableAllocator::DemandExecutableAllocator): Deleted.
(JSC::DemandExecutableAllocator::~DemandExecutableAllocator): Deleted.
(JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators): Deleted.
(JSC::DemandExecutableAllocator::bytesCommittedByAllocactors): Deleted.
(JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators): Deleted.
(JSC::DemandExecutableAllocator::allocateNewSpace): Deleted.
(JSC::DemandExecutableAllocator::notifyNeedPage): Deleted.
(JSC::DemandExecutableAllocator::notifyPageIsFree): Deleted.
(JSC::DemandExecutableAllocator::allocators): Deleted.
(JSC::DemandExecutableAllocator::allocatorsMutex): Deleted.
* jit/ExecutableAllocator.h:
* jit/ExecutableAllocatorFixedVMPool.cpp: Removed.
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::canPerformRangeFilter):
(JSC::JITStubRoutine::filteringStartAddress):
(JSC::JITStubRoutine::filteringExtentSize):
2017-02-22 Saam Barati <sbarati@apple.com>
Add biased coloring to Briggs and IRC
https://bugs.webkit.org/show_bug.cgi?id=168611
Reviewed by Filip Pizlo.
This patch implements biased coloring as proposed by Briggs. See section
5.3.3 of his thesis for more information: http://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-thesis-1992.pdf
The main idea of biased coloring is this:
We try to coalesce a move between u and v, but the conservative heuristic
fails. We don't want coalesce the move because we don't want to risk
creating an uncolorable graph. However, if the conservative heuristic fails,
it's not proof that the graph is uncolorable if the move were indeed coalesced.
So, when we go to color the tmps, we'll remember that we really want the
same register for u and v, and if legal during coloring, we will
assign them to the same register.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
2017-02-22 Yusuke Suzuki <utatane.tea@gmail.com>
JSModuleNamespace object should have IC
https://bugs.webkit.org/show_bug.cgi?id=160590
Reviewed by Saam Barati.
This patch optimizes accesses to module namespace objects.
1. Cache the resolutions for module namespace objects.
When constructing the module namespace object, we already resolves all the exports.
The module namespace object caches this result and leverage it in the later access in
getOwnPropertySlot. This avoids resolving bindings through resolveExport.
2. Introduce ModuleNamespaceLoad IC.
This patch adds new IC for module namespace objects. The mechanism is simple, getOwnPropertySlot
tells us about module namespace object resolution. The IC first checks whether the given object
is an expected module namespace object. If this check succeeds, we load the value from the module
environment.
3. Introduce DFG/FTL optimization.
After exploiting module namespace object accesses in (2), DFG can recognize this in ByteCodeParser.
DFG will convert it to CheckCell with the namespace object and GetClosureVar from the cached environment.
At that time, we have a chance to fold it to the constant.
This optimization improves the performance of accessing to module namespace objects.
Before
$ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-namespace.js
../../WebKitBuild/module-ic-tot/Release/bin/jsc -m 0.43s user 0.03s system 101% cpu 0.451 total
$ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-binding.js
../../WebKitBuild/module-ic-tot/Release/bin/jsc -m 0.08s user 0.02s system 103% cpu 0.104 total
After
$ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-namespace.js
../../WebKitBuild/module-ic/Release/bin/jsc -m 0.11s user 0.01s system 106% cpu 0.109 total
$ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.js
../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.j 0.08s user 0.02s system 102% cpu 0.105 total
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::create):
(JSC::AccessCase::guardedByStructureCheck):
(JSC::AccessCase::canReplace):
(JSC::AccessCase::visitWeak):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* bytecode/AccessCase.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::makesCalls):
(JSC::GetByIdStatus::dump):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::isModuleNamespace):
(JSC::GetByIdStatus::takesSlowPath):
(JSC::GetByIdStatus::moduleNamespaceObject):
(JSC::GetByIdStatus::moduleEnvironment):
(JSC::GetByIdStatus::scopeOffset):
* bytecode/ModuleNamespaceAccessCase.cpp: Added.
(JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
(JSC::ModuleNamespaceAccessCase::create):
(JSC::ModuleNamespaceAccessCase::~ModuleNamespaceAccessCase):
(JSC::ModuleNamespaceAccessCase::clone):
(JSC::ModuleNamespaceAccessCase::emit):
* bytecode/ModuleNamespaceAccessCase.h: Added.
(JSC::ModuleNamespaceAccessCase::moduleNamespaceObject):
(JSC::ModuleNamespaceAccessCase::moduleEnvironment):
(JSC::ModuleNamespaceAccessCase::scopeOffset):
* bytecode/PolymorphicAccess.cpp:
(WTF::printInternal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleGetById):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::loadValue):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::getModuleNamespace):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::visitChildren):
(JSC::getValue):
(JSC::JSModuleNamespaceObject::getOwnPropertySlot):
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
* runtime/JSModuleNamespaceObject.h:
(JSC::isJSModuleNamespaceObject):
(JSC::JSModuleNamespaceObject::create): Deleted.
(JSC::JSModuleNamespaceObject::createStructure): Deleted.
(JSC::JSModuleNamespaceObject::moduleRecord): Deleted.
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::moduleEnvironment): Deleted.
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::domJIT):
(JSC::PropertySlot::moduleNamespaceSlot):
(JSC::PropertySlot::setValueModuleNamespace):
(JSC::PropertySlot::setCacheableCustom):
2017-02-22 Saam Barati <sbarati@apple.com>
Unreviewed. Rename AirGraphColoring.* files to AirAllocateRegistersByGraphColoring.* to be more consistent with the rest of the Air file names.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirAllocateRegistersByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirGraphColoring.cpp.
* b3/air/AirAllocateRegistersByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirGraphColoring.h.
* b3/air/AirGenerate.cpp:
* b3/air/AirGraphColoring.cpp: Removed.
* b3/air/AirGraphColoring.h: Removed.
2017-02-21 Youenn Fablet <youenn@apple.com>
[WebRTC][Mac] Activate libwebrtc
https://bugs.webkit.org/show_bug.cgi?id=167293
<rdar://problem/30401864>
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2017-02-21 Saam Barati <sbarati@apple.com>
Add the Briggs optimistic allocator to run on ARM64
https://bugs.webkit.org/show_bug.cgi?id=168454
Reviewed by Filip Pizlo.
This patch adds the Briggs allocator to Air:
http://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-thesis-1992.pdf
It uses it by default on ARM64. I was measuring an 8-10% speedup
in the phase because of this. I also wasn't able to detect a slowdown
for generated code on ARM64. There are still a few things we can do
to speed things up even further. Moving the interference graph into
a BitVector was another 10-20% speedup. We should consider doing this
in a follow up patch. This is especially important now, since making
register allocation faster has a direct impact on startup time for
Wasm modules.
I abstracted away the common bits between Briggs and IRC, and moved
them into a common super class. In a follow up to this patch, I plan
on implementing biased coloring for both Briggs and IRC (this is
described in Briggs's thesis). I was able to detect a 1% slowdown
with Briggs on Octane for x86-64. This is because the register file
for x86-64 is smaller than ARM64. When I implemented biased coloring,
I was no longer able to detect this slowdown. I still think it's a
sensible plan to run Briggs on ARM64 and IRC on x86-64.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* b3/air/AirGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp.
(JSC::B3::Air::allocateRegistersByGraphColoring):
(JSC::B3::Air::iteratedRegisterCoalescing): Deleted.
* b3/air/AirGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.h.
* b3/air/AirIteratedRegisterCoalescing.cpp: Removed.
* b3/air/AirIteratedRegisterCoalescing.h: Removed.
* runtime/Options.h:
2017-02-21 Mark Lam <mark.lam@apple.com>
Add more missing exception checks detected by running marathon.js.
https://bugs.webkit.org/show_bug.cgi?id=168697
Reviewed by Saam Barati.
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
2017-02-21 JF Bastien <jfbastien@apple.com>
FullCodeOrigin for CodeBlock+CodeOrigin printing
https://bugs.webkit.org/show_bug.cgi?id=168673
Reviewed by Filip Pizlo.
WebAssembly doesn't have a CodeBlock, so printing it isn't
valid. This patch adds FullCodeOrigin to handle the
CodeBlock+CodeOrigin printing pattern, and uses it through all the
places I could find, including Repatch.cpp where it's relevant for
WebAssembly.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::noticeIncomingCall):
* bytecode/FullCodeOrigin.cpp: Added.
(JSC::FullCodeOrigin::dump):
(JSC::FullCodeOrigin::dumpInContext):
* bytecode/FullCodeOrigin.h: Added.
(JSC::FullCodeOrigin::FullCodeOrigin):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
* jit/Repatch.cpp:
(JSC::linkFor):
(JSC::linkDirectFor):
(JSC::linkVirtualFor):
2017-02-21 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop. I managed to have my local patch for relanding be the one without the cloop
fix. I keep forgetting about cloop!
* heap/Heap.cpp:
(JSC::Heap::stopThePeriphery):
* runtime/JSLock.cpp:
2017-02-21 Mark Lam <mark.lam@apple.com>
Add missing exception checks detected by running marathon.js.
https://bugs.webkit.org/show_bug.cgi?id=168687
Reviewed by Saam Barati.
When running the marathon.js test from https://bugs.webkit.org/show_bug.cgi?id=168580,
we get some crashes due to missing exception checks. This patch adds those
missing exception checks.
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toPropertyKey):
* runtime/JSObject.cpp:
(JSC::JSObject::getPrimitiveNumber):
2017-02-20 Filip Pizlo <fpizlo@apple.com>
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/GCFinalizationCallback.cpp: Added.
(JSC::GCFinalizationCallback::GCFinalizationCallback):
(JSC::GCFinalizationCallback::~GCFinalizationCallback):
* heap/GCFinalizationCallback.h: Added.
(JSC::GCFinalizationCallbackFuncAdaptor::GCFinalizationCallbackFuncAdaptor):
(JSC::createGCFinalizationCallback):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::addFinalizationCallback):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::stopSweeping):
(JSC::IncrementalSweeper::willFinishSweeping): Deleted.
* heap/IncrementalSweeper.h:
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::callWithCurrentThreadState):
* heap/MachineStackMarker.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/RunningScope.h: Added.
(JSC::RunningScope::RunningScope):
(JSC::RunningScope::~RunningScope):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::donate):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::codeName):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
2017-02-21 Saam Barati <sbarati@apple.com>
Air should have a disassembly mode that dumps IR and assembly intermixed
https://bugs.webkit.org/show_bug.cgi?id=168629
Reviewed by Filip Pizlo.
This will make dumping FTL disassembly dump Air intermixed
with the assembly generated by each Air Inst. This is similar
to how dumpDFGDisassembly dumps the generated assembly for each
Node.
Here is what the output will look like:
Generated FTL JIT code for foo#CUaFiQ:[0x10b76c960->0x10b76c2d0->0x10b7b6da0, FTLFunctionCall, 40 (NeverInline)], instruction count = 40:
BB#0: ; frequency = 1.000000
0x469004e02e00: push %rbp
0x469004e02e01: mov %rsp, %rbp
0x469004e02e04: add $0xffffffffffffffd0, %rsp
Move $0x10b76c960, %rax, $4487301472(@16)
0x469004e02e08: mov $0x10b76c960, %rax
Move %rax, 16(%rbp), @19
0x469004e02e12: mov %rax, 0x10(%rbp)
Patch &Patchpoint2, %rbp, %rax, @20
0x469004e02e16: lea -0x50(%rbp), %rax
0x469004e02e1a: mov $0x1084081e0, %r11
0x469004e02e24: cmp %rax, (%r11)
0x469004e02e27: ja 0x469004e02e9a
Move 56(%rbp), %rdx, @23
0x469004e02e2d: mov 0x38(%rbp), %rdx
Move $0xffff000000000002, %rax, $-281474976710654(@15)
0x469004e02e31: mov $0xffff000000000002, %rax
Patch &BranchTest64(3,SameAsRep)1, NonZero, %rdx, %rax, %rdx, @26
0x469004e02e3b: test %rdx, %rax
0x469004e02e3e: jnz 0x469004e02f08
Move 48(%rbp), %rax, @29
0x469004e02e44: mov 0x30(%rbp), %rax
Move %rax, %rcx, @31
0x469004e02e48: mov %rax, %rcx
Xor64 $6, %rcx, @31
0x469004e02e4b: xor $0x6, %rcx
Patch &BranchTest64(3,SameAsRep)1, NonZero, %rcx, $-2, %rax, @35
0x469004e02e4f: test $0xfffffffffffffffe, %rcx
0x469004e02e56: jnz 0x469004e02f12
Patch &Branch32(3,SameAsRep)0, NotEqual, (%rdx), $266, %rdx, @45
0x469004e02e5c: cmp $0x10a, (%rdx)
0x469004e02e62: jnz 0x469004e02f1c
BranchTest32 NonZero, %rax, $1, @49
0x469004e02e68: test $0x1, %al
0x469004e02e6a: jnz 0x469004e02e91
Successors: #3, #1
BB#1: ; frequency = 1.000000
Predecessors: #0
Move $0, %rcx, @65
0x469004e02e70: xor %rcx, %rcx
Jump @66
Successors: #2
BB#2: ; frequency = 1.000000
Predecessors: #1, #3
Move 24(%rdx), %rax, @58
0x469004e02e73: mov 0x18(%rdx), %rax
Patch &BranchAdd32(4,ForceLateUseUnlessRecoverable)3, Overflow, %rcx, %rax, %rcx, %rcx, %rax, @60
0x469004e02e77: add %eax, %ecx
0x469004e02e79: jo 0x469004e02f26
Move $0xffff000000000000, %rax, $-281474976710656(@14)
0x469004e02e7f: mov $0xffff000000000000, %rax
Add64 %rcx, %rax, %rax, @62
0x469004e02e89: add %rcx, %rax
Ret64 %rax, @63
0x469004e02e8c: mov %rbp, %rsp
0x469004e02e8f: pop %rbp
0x469004e02e90: ret
BB#3: ; frequency = 1.000000
Predecessors: #0
Move 16(%rdx), %rcx, @52
0x469004e02e91: mov 0x10(%rdx), %rcx
Jump @55
0x469004e02e95: jmp 0x469004e02e73
Successors: #2
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setDisassembler):
(JSC::B3::Air::Code::disassembler):
* b3/air/AirDisassembler.cpp: Added.
(JSC::B3::Air::Disassembler::startEntrypoint):
(JSC::B3::Air::Disassembler::endEntrypoint):
(JSC::B3::Air::Disassembler::startLatePath):
(JSC::B3::Air::Disassembler::endLatePath):
(JSC::B3::Air::Disassembler::startBlock):
(JSC::B3::Air::Disassembler::addInst):
(JSC::B3::Air::Disassembler::dump):
* b3/air/AirDisassembler.h: Added.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
2017-02-21 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r212712.
This change broke the CLoop build.
Reverted changeset:
"JSModuleNamespace object should have IC"
https://bugs.webkit.org/show_bug.cgi?id=160590
http://trac.webkit.org/changeset/212712
2017-02-21 Yusuke Suzuki <utatane.tea@gmail.com>
JSModuleNamespace object should have IC
https://bugs.webkit.org/show_bug.cgi?id=160590
Reviewed by Saam Barati.
This patch optimizes accesses to module namespace objects.
1. Cache the resolutions for module namespace objects.
When constructing the module namespace object, we already resolves all the exports.
The module namespace object caches this result and leverage it in the later access in
getOwnPropertySlot. This avoids resolving bindings through resolveExport.
2. Introduce ModuleNamespaceLoad IC.
This patch adds new IC for module namespace objects. The mechanism is simple, getOwnPropertySlot
tells us about module namespace object resolution. The IC first checks whether the given object
is an expected module namespace object. If this check succeeds, we load the value from the module
environment.
3. Introduce DFG/FTL optimization.
After exploiting module namespace object accesses in (2), DFG can recognize this in ByteCodeParser.
DFG will convert it to CheckCell with the namespace object and GetClosureVar from the cached environment.
At that time, we have a chance to fold it to the constant.
This optimization improves the performance of accessing to module namespace objects.
Before
$ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-namespace.js
../../WebKitBuild/module-ic-tot/Release/bin/jsc -m 0.43s user 0.03s system 101% cpu 0.451 total
$ time ../../WebKitBuild/module-ic-tot/Release/bin/jsc -m module-assert-access-binding.js
../../WebKitBuild/module-ic-tot/Release/bin/jsc -m 0.08s user 0.02s system 103% cpu 0.104 total
After
$ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-namespace.js
../../WebKitBuild/module-ic/Release/bin/jsc -m 0.11s user 0.01s system 106% cpu 0.109 total
$ time ../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.js
../../WebKitBuild/module-ic/Release/bin/jsc -m module-assert-access-binding.j 0.08s user 0.02s system 102% cpu 0.105 total
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::create):
(JSC::AccessCase::guardedByStructureCheck):
(JSC::AccessCase::canReplace):
(JSC::AccessCase::visitWeak):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* bytecode/AccessCase.h:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::makesCalls):
(JSC::GetByIdStatus::dump):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::isModuleNamespace):
(JSC::GetByIdStatus::takesSlowPath):
(JSC::GetByIdStatus::moduleNamespaceObject):
(JSC::GetByIdStatus::moduleEnvironment):
(JSC::GetByIdStatus::scopeOffset):
* bytecode/ModuleNamespaceAccessCase.cpp: Added.
(JSC::ModuleNamespaceAccessCase::ModuleNamespaceAccessCase):
(JSC::ModuleNamespaceAccessCase::create):
(JSC::ModuleNamespaceAccessCase::~ModuleNamespaceAccessCase):
(JSC::ModuleNamespaceAccessCase::clone):
(JSC::ModuleNamespaceAccessCase::emit):
* bytecode/ModuleNamespaceAccessCase.h: Added.
(JSC::ModuleNamespaceAccessCase::moduleNamespaceObject):
(JSC::ModuleNamespaceAccessCase::moduleEnvironment):
(JSC::ModuleNamespaceAccessCase::scopeOffset):
* bytecode/PolymorphicAccess.cpp:
(WTF::printInternal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleGetById):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::loadValue):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::getModuleNamespace):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::visitChildren):
(JSC::getValue):
(JSC::JSModuleNamespaceObject::getOwnPropertySlot):
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
* runtime/JSModuleNamespaceObject.h:
(JSC::isJSModuleNamespaceObject):
(JSC::JSModuleNamespaceObject::create): Deleted.
(JSC::JSModuleNamespaceObject::createStructure): Deleted.
(JSC::JSModuleNamespaceObject::moduleRecord): Deleted.
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::moduleEnvironment): Deleted.
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
(JSC::PropertySlot::domJIT):
(JSC::PropertySlot::moduleNamespaceSlot):
(JSC::PropertySlot::setValueModuleNamespace):
(JSC::PropertySlot::setCacheableCustom):
2017-02-21 Yusuke Suzuki <utatane.tea@gmail.com>
ASSERTION FAILED: "!scope.exception()" with Object.isSealed/isFrozen and uninitialized module bindings
https://bugs.webkit.org/show_bug.cgi?id=168605
Reviewed by Saam Barati.
We should check exception state after calling getOwnPropertyDescriptor() since it can throw errors.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
2017-02-20 Mark Lam <mark.lam@apple.com>
[Re-landing] CachedCall should let GC know to keep its arguments alive.
https://bugs.webkit.org/show_bug.cgi?id=168567
<rdar://problem/30475767>
Reviewed by Saam Barati.
We fix this by having CachedCall use a MarkedArgumentBuffer to store its
arguments instead of a Vector.
Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
correctness.
Update: the original patch has a bug in MarkedArgumentBuffer::expandCapacity()
where it was copying and calling addMarkSet() on values in m_buffer beyond m_size
(up to m_capacity). As a result, depending on the pre-existing values in
m_inlineBuffer, this may result in a computed Heap pointer that is wrong, and
subsequently, manifest as a crash. This is likely to be the cause of the PLT
regression.
I don't have a new test for this fix because the issue relies on sufficiently bad
values randomly showing up in m_inlineBuffer when we do an ensureCapacity() which
calls expandCapacity().
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
(JSC::CachedCall::call):
(JSC::CachedCall::clearArguments):
(JSC::CachedCall::appendArgument):
(JSC::CachedCall::setArgument): Deleted.
* interpreter/CallFrame.h:
(JSC::ExecState::emptyList):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::prepareForRepeatCall):
* interpreter/Interpreter.h:
* interpreter/ProtoCallFrame.h:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::slowEnsureCapacity):
(JSC::MarkedArgumentBuffer::expandCapacity):
(JSC::MarkedArgumentBuffer::slowAppend):
* runtime/ArgList.h:
(JSC::MarkedArgumentBuffer::append):
(JSC::MarkedArgumentBuffer::ensureCapacity):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-02-20 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r212618.
https://bugs.webkit.org/show_bug.cgi?id=168609
"Appears to cause PLT regression" (Requested by mlam on
#webkit).
Reverted changeset:
"CachedCall should let GC know to keep its arguments alive."
https://bugs.webkit.org/show_bug.cgi?id=168567
http://trac.webkit.org/changeset/212618
2017-02-19 Mark Lam <mark.lam@apple.com>
BytecodeGenerator should not iterate its m_controlFlowScopeStack using a pointer bump.
https://bugs.webkit.org/show_bug.cgi?id=168585
Reviewed by Yusuke Suzuki.
This is because m_controlFlowScopeStack is a SegmentedVector, and entries for
consecutive indices in the vector are not guaranteed to be consecutive in memory
layout. Instead, we should be using indexing instead.
This issue was detected by the marathon.js test from
https://bugs.webkit.org/show_bug.cgi?id=168580.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2017-02-20 Manuel Rego Casasnovas <rego@igalia.com>
[css-grid] Remove compilation flag ENABLE_CSS_GRID_LAYOUT
https://bugs.webkit.org/show_bug.cgi?id=167693
Reviewed by Sergio Villar Senin.
* Configurations/FeatureDefines.xcconfig:
2017-02-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r212472.
https://bugs.webkit.org/show_bug.cgi?id=168584
Broke CLoop builds when r212466 was rolled out in r212616
(Requested by rniwa on #webkit).
Reverted changeset:
"Unreviewed, fix cloop build."
http://trac.webkit.org/changeset/212472
2017-02-19 Mark Lam <mark.lam@apple.com>
functionTestWasmModuleFunctions() should use a MarkedArgumentBuffer for storing args instead of a Vector.
https://bugs.webkit.org/show_bug.cgi?id=168574
Reviewed by Filip Pizlo.
* jsc.cpp:
(callWasmFunction):
(functionTestWasmModuleFunctions):
* runtime/ArgList.h:
2017-02-19 Mark Lam <mark.lam@apple.com>
CachedCall should let GC know to keep its arguments alive.
https://bugs.webkit.org/show_bug.cgi?id=168567
<rdar://problem/30475767>
Reviewed by Saam Barati.
We fix this by having CachedCall use a MarkedArgumentBuffer to store its
arguments instead of a Vector.
Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
correctness.
* interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
(JSC::CachedCall::call):
(JSC::CachedCall::clearArguments):
(JSC::CachedCall::appendArgument):
(JSC::CachedCall::setArgument): Deleted.
* interpreter/CallFrame.h:
(JSC::ExecState::emptyList):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::prepareForRepeatCall):
* interpreter/Interpreter.h:
* interpreter/ProtoCallFrame.h:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::expandCapacity):
* runtime/ArgList.h:
(JSC::MarkedArgumentBuffer::ensureCapacity):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-02-19 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r212466.
https://bugs.webkit.org/show_bug.cgi?id=168577
causes crashes on AArch64 on linux, maybe it's causing crashes
on iOS too (Requested by pizlo on #webkit).
Reverted changeset:
"The collector thread should only start when the mutator
doesn't have heap access"
https://bugs.webkit.org/show_bug.cgi?id=167737
http://trac.webkit.org/changeset/212466
2017-02-17 Michael Saboff <msaboff@apple.com>
Improve ARM64 disassembler handling of pseudo ops, unsupported opcodes and zero reg
https://bugs.webkit.org/show_bug.cgi?id=168527
Reviewed by Filip Pizlo.
Added support for data processing 1 source instructions like rbit, rev, clz and cls.
Added support for the FP conditional select instruction, fcsel. Consolidated the
two classes for handling dmb instructions into one class. Fixed the instruction
selection mask in the integer conditional select class, A64DOpcodeConditionalSelect.
Fixed the processing of extract instruction (extr) including the rotate right (ror)
pseudo instruction. Changed the printing of x31 and w31 to xzr and wzr as operands
according to the spec. Added support for common pseudo instructions. This includes:
- mvn x1, X2 in place of orn x1, xzr, x2
- lsl x3, x4, #count in place of ubfiz x3, x4, #count, #count
- smull x5, w6, w7 in place of smaddl x5, w6, w7, XZR
- More understandable mov x8, #-304 in place of movn x8, #0x12f
- Eliminated xzr from register index loads and stores, outputing
ldr x10, [x11] instead of ldr x10, [x11, xzr]
Changed the move wide instructions to use hex literals for movz and movk.
This makes it much easier to decifer sequences of wide moves for large literals.
Before After
movz x17, #26136 movz x17, #0x6618
movk x17, #672, lsl #16 movk x17, #0x2a0, lsl #16
movk x17, #1, lsl #32 movk x17, #0x1, lsl #32
Verified that all instructions currently generated by the JSC stress tests are
disassembled.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeBitfield::format):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::format):
(JSC::ARM64Disassembler::A64DOpcodeExtract::format):
(JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::format):
(JSC::ARM64Disassembler::A64DOpcodeFloatingPointIntegerConversions::format):
(JSC::ARM64Disassembler::A64DOpcodeDmb::format):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreImmediate::format):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterOffset::format):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format):
(JSC::ARM64Disassembler::A64DOpcodeLoadStoreUnsignedImmediate::format):
(JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::format):
(JSC::ARM64Disassembler::A64DOpcodeMoveWide::format):
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format): Deleted.
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format): Deleted.
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::appendSignedImmediate64):
(JSC::ARM64Disassembler::A64DOpcode::appendUnsignedHexImmediate):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opName):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::sBit):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opCode2):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::opNameIndex):
(JSC::ARM64Disassembler::A64DOpcodeDataProcessing3Source::opName):
(JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::opName):
(JSC::ARM64Disassembler::A64DOpcodeFloatingPointConditionalSelect::condition):
(JSC::ARM64Disassembler::A64DOpcodeDmb::option):
(JSC::ARM64Disassembler::A64DOpcodeDmb::crM):
(JSC::ARM64Disassembler::A64DOpcodeLogicalShiftedRegister::isMov):
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName): Deleted.
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName): Deleted.
2017-02-17 Zan Dobersek <zdobersek@igalia.com>
[GLib] GCActivityCallback::scheduleTimer() keeps pushing dispatch into the future
https://bugs.webkit.org/show_bug.cgi?id=168363
Reviewed by Carlos Garcia Campos.
Mimic the USE(CF) implementation of GCActivityCallback and HeapTimer by
scheduling the timer a decade into the future instead of completely
cancelling it. That way new dispatch times for GCActivityCallback can be
computed by simply deducting the difference in the new and previous
delay from the GSource's current dispatch time. Previously we handled an
extra 'paused' state (where m_delay was -1) and allowed for a delay of
an infinite value to be valid, complicating the next dispatch time
computation.
HeapTimer gains the static s_decade variable. The dispatch function in
heapTimerSourceFunctions only dispatches the callback, which now delays
the GSource by a decade. HeapTimer::scheduleTimer() simply schedules the
source to dispatch in the specified amount of time, and cancelTimer()
'cancels' the source by setting the dispatch time to a decade.
GCActivityCallback constructor initializes the delay to the s_decade
value and immediately sets the ready time for GSource a decade into the
future, avoiding the default -1 value as the ready time that would cause
problems in scheduleTimer(). scheduleTimer() doesn't special-case the
zero-delay value anymore, instead it just computes the difference
between the old and the new delay and rolls back the GSource's ready
time for that amount. cancelTimer() sets m_delay to the decade value and
delays the GSource for that same amount.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
(JSC::GCActivityCallback::scheduleTimer):
(JSC::GCActivityCallback::cancelTimer):
* heap/GCActivityCallback.h:
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
(JSC::HeapTimer::scheduleTimer):
(JSC::HeapTimer::cancelTimer):
* heap/HeapTimer.h:
2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop PassRefPtr from ArrayBuffer
https://bugs.webkit.org/show_bug.cgi?id=168455
Reviewed by Geoffrey Garen.
This patch finally drops all the PassRefPtr in JSC.
We changed PassRefPtr<ArrayBuffer> to RefPtr<ArrayBuffer>&&.
Since ArrayBuffer may be nullptr if the array is neutered,
we hold it as RefPtr<> instead of Ref<>.
And we also drops 2 files, TypedArrayBase.h and IntegralTypedArrayBase.h.
They are not used (and they are not referenced from the project file).
* inspector/JavaScriptCallFrame.h:
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* runtime/ArrayBufferView.cpp:
(JSC::ArrayBufferView::ArrayBufferView):
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::possiblySharedBuffer):
(JSC::ArrayBufferView::unsharedBuffer):
(JSC::ArrayBufferView::verifySubRangeLength):
(JSC::ArrayBufferView::clampOffsetAndNumElements):
* runtime/ClassInfo.h:
* runtime/DataView.cpp:
(JSC::DataView::DataView):
(JSC::DataView::create):
* runtime/DataView.h:
* runtime/GenericTypedArrayView.h:
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
(JSC::GenericTypedArrayView<Adaptor>::create):
(JSC::GenericTypedArrayView<Adaptor>::subarray):
* runtime/IntegralTypedArrayBase.h: Removed.
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::JSArrayBuffer):
(JSC::JSArrayBuffer::create):
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
* runtime/JSArrayBufferView.h:
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::possiblySharedImpl):
(JSC::JSArrayBufferView::unsharedImpl):
* runtime/JSCell.cpp:
(JSC::JSCell::slowDownAndWasteMemory):
(JSC::JSCell::getTypedArrayImpl):
* runtime/JSCell.h:
* runtime/JSDataView.cpp:
(JSC::JSDataView::create):
(JSC::JSDataView::possiblySharedTypedImpl):
(JSC::JSDataView::unsharedTypedImpl):
(JSC::JSDataView::getTypedArrayImpl):
* runtime/JSDataView.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::create):
(JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::getTypedArrayImpl):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSTypedArrays.cpp:
(JSC::createUint8TypedArray):
* runtime/TypedArrayBase.h: Removed.
2017-02-16 Keith Miller <keith_miller@apple.com>
ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
https://bugs.webkit.org/show_bug.cgi?id=168354
Reviewed by Geoffrey Garen.
Instead of adding a custom vmEntryGlobalObject for the debugger
we can just have it use vmEntryScope instead.
* debugger/Debugger.cpp:
(JSC::Debugger::detach):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach): Deleted.
* interpreter/CallFrame.h:
2017-02-16 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop build.
* heap/Heap.cpp:
(JSC::Heap::stopThePeriphery):
* runtime/JSLock.cpp:
2017-02-10 Filip Pizlo <fpizlo@apple.com>
The collector thread should only start when the mutator doesn't have heap access
https://bugs.webkit.org/show_bug.cgi?id=167737
Reviewed by Keith Miller.
This turns the collector thread's workflow into a state machine, so that the mutator thread can
run it directly. This reduces the amount of synchronization we do with the collector thread, and
means that most apps will never start the collector thread. The collector thread will still start
when we need to finish collecting and we don't have heap access.
In this new world, "stopping the world" means relinquishing control of collection to the mutator.
This means tracking who is conducting collection. I use the GCConductor enum to say who is
conducting. It's either GCConductor::Mutator or GCConductor::Collector. I use the term "conn" to
refer to the concept of conducting (having the conn, relinquishing the conn, taking the conn).
So, stopping the world means giving the mutator the conn. Releasing heap access means giving the
collector the conn.
This meant bringing back the conservative scan of the calling thread. It turns out that this
scan was too slow to be called on each GC increment because apparently setjmp() now does system
calls. So, I wrote our own callee save register saving for the GC. Then I had doubts about
whether or not it was correct, so I also made it so that the GC only rarely asks for the register
state. I think we still want to use my register saving code instead of setjmp because setjmp
seems to save things we don't need, and that could make us overly conservative.
It turns out that this new scheduling discipline makes the old space-time scheduler perform
better than the new stochastic space-time scheduler on systems with fewer than 4 cores. This is
because the mutator having the conn enables us to time the mutator<->collector context switches
by polling. The OS is never involved. So, we can use super precise timing. This allows the old
space-time schduler to shine like it hadn't before.
The splay results imply that this is all a good thing. On 2-core systems, this reduces pause
times by 40% and it increases throughput about 5%. On 1-core systems, this reduces pause times by
half and reduces throughput by 8%. On 4-or-more-core systems, this doesn't seem to have much
effect.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::dump):
(JSC::DFG::numberOfWorklists):
(JSC::DFG::ensureWorklistForIndex):
(JSC::DFG::existingWorklistForIndexOrNull):
(JSC::DFG::existingWorklistForIndex):
* dfg/DFGWorklist.h:
(JSC::DFG::numberOfWorklists): Deleted.
(JSC::DFG::ensureWorklistForIndex): Deleted.
(JSC::DFG::existingWorklistForIndexOrNull): Deleted.
(JSC::DFG::existingWorklistForIndex): Deleted.
* heap/CollectingScope.h: Added.
(JSC::CollectingScope::CollectingScope):
(JSC::CollectingScope::~CollectingScope):
* heap/CollectorPhase.cpp: Added.
(JSC::worldShouldBeSuspended):
(WTF::printInternal):
* heap/CollectorPhase.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::lastGCLength):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
(JSC::FullGCActivityCallback::lastGCLength):
* heap/GCConductor.cpp: Added.
(JSC::gcConductorShortName):
(WTF::printInternal):
* heap/GCConductor.h: Added.
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::shouldCollectInCollectorThread):
(JSC::Heap::collectInCollectorThread):
(JSC::Heap::checkConn):
(JSC::Heap::runCurrentPhase):
(JSC::Heap::runNotRunningPhase):
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::runReloopPhase):
(JSC::Heap::runEndPhase):
(JSC::Heap::changePhase):
(JSC::Heap::finishChangingPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::stopTheMutator):
(JSC::Heap::resumeTheMutator):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectInMutatorThread):
(JSC::Heap::collectInMutatorThreadImpl):
(JSC::Heap::waitForCollector):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::relinquishConn):
(JSC::Heap::finishRelinquishingConn):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::notifyThreadStopping):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::preventCollection):
(JSC::Heap::performIncrement):
(JSC::Heap::markToFixpoint): Deleted.
(JSC::Heap::shouldCollectInThread): Deleted.
(JSC::Heap::collectInThread): Deleted.
(JSC::Heap::stopTheWorld): Deleted.
(JSC::Heap::resumeTheWorld): Deleted.
* heap/Heap.h:
(JSC::Heap::machineThreads):
(JSC::Heap::lastFullGCLength):
(JSC::Heap::lastEdenGCLength):
(JSC::Heap::increaseLastFullGCLength):
* heap/HeapInlines.h:
(JSC::Heap::mutatorIsStopped): Deleted.
* heap/HeapStatistics.cpp: Removed.
* heap/HeapStatistics.h: Removed.
* heap/HelpingGCScope.h: Removed.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherFromCurrentThread):
(JSC::MachineThreads::gatherConservativeRoots):
* heap/MachineStackMarker.h:
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* heap/MutatorState.cpp:
(WTF::printInternal):
* heap/MutatorState.h:
* heap/RegisterState.h: Added.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
* heap/SweepingScope.h: Added.
(JSC::SweepingScope::SweepingScope):
(JSC::SweepingScope::~SweepingScope):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionFlashHeapAccess):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
* runtime/TestRunnerUtils.cpp:
(JSC::finalizeStatsAtEndOfTesting):
2017-02-16 Anders Carlsson <andersca@apple.com>
Remove EFL from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=168459
Reviewed by Geoffrey Garen.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
(JSC::GCActivityCallback::cancelTimer):
(JSC::GCActivityCallback::didAllocate):
* heap/GCActivityCallback.h:
* heap/HeapTimer.cpp:
(JSC::HeapTimer::add): Deleted.
(JSC::HeapTimer::stop): Deleted.
(JSC::HeapTimer::timerEvent): Deleted.
* heap/HeapTimer.h:
* inspector/EventLoop.cpp:
(Inspector::EventLoop::cycle):
* jsc.cpp:
(main):
* tools/CodeProfiling.cpp:
(JSC::CodeProfiling::begin):
(JSC::CodeProfiling::end):
2017-02-15 Brian Burg <bburg@apple.com>
[Cocoa] Web Inspector: Inspector::fromProtocolString<T> should return std::optional<T>
https://bugs.webkit.org/show_bug.cgi?id=168018
<rdar://problem/30468779>
Reviewed by Joseph Pecoraro.
These methods parse untrusted string inputs, so they should return an optional instead
of asserting or crashing when the input is not usable.
Update various pieces of generated code to handle the error case gracefully.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator._generate_conversions_for_command):
(ObjCBackendDispatcherImplementationGenerator._generate_invocation_for_command):
The local variable holding the ObjC-friendly converted value should take a std::optional
when converting an enum from a string into an NS_ENUM value. If the enum command parameter
is not optional, then send a response with a command failure message and return.
The optional enum parameter case is not handled correctly, but no existing code requires it.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_from_protocol_string):
Fix signature and remove default case ASSERT_NOT_REACHED.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_implementation):
Since this code assumes all inputs to be valid and throws an exception otherwise, we
try to convert the enum and throw an exception if it's nullopt. If it's valid, write to outValue.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
The local variable holding the ObjC-friendly converted value should take a std::optional
when converting an enum from a string into an NS_ENUM value. If the enum command parameter
is not optional, then throw an exception if the value is nullopt. Otherwise, allow it to be empty.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.protocol_to_objc_expression_for_member):
Unconditionally unwrap the optional. This expression is only used inside the typechecked
ObjC protocol objects. In this case we are guaranteed to have already initialized the enum with a valid
value, but must store it as a string inside a wrapped InspectorObject. The getter needs to
re-convert the stored string into an NS_ENUM value.
* inspector/scripts/codegen/objc_generator_templates.py:
Update type template for fromProtocolString<T>().
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Rebaseline tests.
2017-02-16 Keith Miller <keith_miller@apple.com>
ASSERTION FAILED: vm.heap.mutatorState() == MutatorState::Running || vm.apiLock().ownerThread() != std::this_thread::get_id()
https://bugs.webkit.org/show_bug.cgi?id=168354
Reviewed by Filip Pizlo.
Add a new vmEntryGlobalObject method for the debugger so that
the debugger does not crash in debug builds when trying to
detach itself from a global object.
* debugger/Debugger.cpp:
(JSC::Debugger::detach):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::vmEntryGlobalObjectForDebuggerDetach):
* interpreter/CallFrame.h:
2017-02-16 Keith Miller <keith_miller@apple.com>
Refactor AccessCase to be more like B3Value
https://bugs.webkit.org/show_bug.cgi?id=168408
Reviewed by Filip Pizlo.
This patch makes AccessCase (and new subclasses) more like B3Value. In the new system each
type has an associated AccessCase subclass. For instance any getter should use the
GetterSetterAccessCase subclass. The new system is easier to follow since you no longer need
to know exactly which members are used by which types. The subclass to AccessType mapping is:
GetterSetterAccessCase:
Getter
CustomAccessorGetter
CustomValueGetter
Setter
ProxyableAccessCase:
Load
Miss
GetGetter
IntrinsicGetterAccessCase:
IntrinsicGetter
AccessCase:
Everything else
It also has the additional advantage that it uses less memory for the cases where we would have needed
rare data in the past but that case would only use a small bit of it.
This patch also removes megamorphic loads and renames some TryGetById related enum values from Pure to Try.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/AccessCase.cpp: Added.
(JSC::AccessCase::AccessCase):
(JSC::AccessCase::create):
(JSC::AccessCase::~AccessCase):
(JSC::AccessCase::fromStructureStubInfo):
(JSC::AccessCase::clone):
(JSC::AccessCase::commit):
(JSC::AccessCase::guardedByStructureCheck):
(JSC::AccessCase::doesCalls):
(JSC::AccessCase::couldStillSucceed):
(JSC::AccessCase::canReplace):
(JSC::AccessCase::dump):
(JSC::AccessCase::visitWeak):
(JSC::AccessCase::propagateTransitions):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generate):
(JSC::AccessCase::generateImpl):
* bytecode/AccessCase.h: Added.
(JSC::AccessCase::as):
(JSC::AccessCase::create):
(JSC::AccessCase::type):
(JSC::AccessCase::state):
(JSC::AccessCase::offset):
(JSC::AccessCase::structure):
(JSC::AccessCase::newStructure):
(JSC::AccessCase::conditionSet):
(JSC::AccessCase::alternateBase):
(JSC::AccessCase::additionalSet):
(JSC::AccessCase::viaProxy):
(JSC::AccessCase::isGetter):
(JSC::AccessCase::isAccessor):
(JSC::AccessCase::dumpImpl):
(JSC::AccessCase::resetState):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetterSetterAccessCase.cpp: Added.
(JSC::GetterSetterAccessCase::GetterSetterAccessCase):
(JSC::GetterSetterAccessCase::create):
(JSC::GetterSetterAccessCase::~GetterSetterAccessCase):
(JSC::GetterSetterAccessCase::clone):
(JSC::GetterSetterAccessCase::alternateBase):
(JSC::GetterSetterAccessCase::dumpImpl):
(JSC::GetterSetterAccessCase::emitDOMJITGetter):
* bytecode/GetterSetterAccessCase.h: Added.
(JSC::GetterSetterAccessCase::callLinkInfo):
(JSC::GetterSetterAccessCase::customSlotBase):
(JSC::GetterSetterAccessCase::domJIT):
* bytecode/IntrinsicGetterAccessCase.cpp: Added.
(JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
(JSC::IntrinsicGetterAccessCase::create):
(JSC::IntrinsicGetterAccessCase::~IntrinsicGetterAccessCase):
(JSC::IntrinsicGetterAccessCase::clone):
* bytecode/IntrinsicGetterAccessCase.h: Added.
(JSC::IntrinsicGetterAccessCase::intrinsicFunction):
(JSC::IntrinsicGetterAccessCase::intrinsic):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
(WTF::printInternal):
(JSC::AccessCase::AccessCase): Deleted.
(JSC::AccessCase::tryGet): Deleted.
(JSC::AccessCase::get): Deleted.
(JSC::AccessCase::megamorphicLoad): Deleted.
(JSC::AccessCase::replace): Deleted.
(JSC::AccessCase::transition): Deleted.
(JSC::AccessCase::setter): Deleted.
(JSC::AccessCase::in): Deleted.
(JSC::AccessCase::getLength): Deleted.
(JSC::AccessCase::getIntrinsic): Deleted.
(JSC::AccessCase::~AccessCase): Deleted.
(JSC::AccessCase::fromStructureStubInfo): Deleted.
(JSC::AccessCase::clone): Deleted.
(JSC::AccessCase::commit): Deleted.
(JSC::AccessCase::guardedByStructureCheck): Deleted.
(JSC::AccessCase::alternateBase): Deleted.
(JSC::AccessCase::doesCalls): Deleted.
(JSC::AccessCase::couldStillSucceed): Deleted.
(JSC::AccessCase::canBeReplacedByMegamorphicLoad): Deleted.
(JSC::AccessCase::canReplace): Deleted.
(JSC::AccessCase::dump): Deleted.
(JSC::AccessCase::visitWeak): Deleted.
(JSC::AccessCase::propagateTransitions): Deleted.
(JSC::AccessCase::generateWithGuard): Deleted.
(JSC::AccessCase::generate): Deleted.
(JSC::AccessCase::generateImpl): Deleted.
(JSC::AccessCase::emitDOMJITGetter): Deleted.
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::type): Deleted.
(JSC::AccessCase::state): Deleted.
(JSC::AccessCase::offset): Deleted.
(JSC::AccessCase::viaProxy): Deleted.
(JSC::AccessCase::structure): Deleted.
(JSC::AccessCase::newStructure): Deleted.
(JSC::AccessCase::conditionSet): Deleted.
(JSC::AccessCase::intrinsicFunction): Deleted.
(JSC::AccessCase::intrinsic): Deleted.
(JSC::AccessCase::domJIT): Deleted.
(JSC::AccessCase::additionalSet): Deleted.
(JSC::AccessCase::customSlotBase): Deleted.
(JSC::AccessCase::isGetter): Deleted.
(JSC::AccessCase::callLinkInfo): Deleted.
(JSC::AccessCase::RareData::RareData): Deleted.
* bytecode/ProxyableAccessCase.cpp: Added.
(JSC::ProxyableAccessCase::ProxyableAccessCase):
(JSC::ProxyableAccessCase::create):
(JSC::ProxyableAccessCase::~ProxyableAccessCase):
(JSC::ProxyableAccessCase::clone):
(JSC::ProxyableAccessCase::dumpImpl):
* bytecode/ProxyableAccessCase.h: Added.
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTryGetById):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetById):
* jit/IntrinsicEmitter.cpp:
(JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
(JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
(JSC::AccessCase::canEmitIntrinsicGetter): Deleted.
(JSC::AccessCase::emitIntrinsicGetter): Deleted.
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_try_get_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_try_get_by_id):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
(JSC::tryCachePutByID):
(JSC::tryRepatchIn):
* jit/Repatch.h:
* runtime/Options.h:
2017-02-16 Filip Pizlo <fpizlo@apple.com>
JSONParseTest needs to hold the lock when the VM is destroyed
https://bugs.webkit.org/show_bug.cgi?id=168450
Rubber stamped by Alex Christensen.
* API/tests/JSONParseTest.cpp:
(testJSONParse):
2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop PassRefPtr in inspector/
https://bugs.webkit.org/show_bug.cgi?id=168420
Reviewed by Alex Christensen.
Drop PassRefPtr uses.
And use Ref<Inspector::ScriptArguments> and Ref<ScriptCallStack> as much as possible.
It drops some unnecessary null checks.
* debugger/Debugger.cpp:
(JSC::Debugger::hasBreakpoint):
(JSC::Debugger::currentDebuggerCallFrame):
* debugger/Debugger.h:
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::create):
(Inspector::AsyncStackTrace::AsyncStackTrace):
(Inspector::AsyncStackTrace::buildInspectorObject):
(Inspector::AsyncStackTrace::truncate):
* inspector/AsyncStackTrace.h:
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::ConsoleMessage):
* inspector/ConsoleMessage.h:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::InjectedScriptManager):
(Inspector::InjectedScriptManager::injectedScriptHost):
* inspector/InjectedScriptManager.h:
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
(Inspector::JSGlobalObjectConsoleClient::count):
(Inspector::JSGlobalObjectConsoleClient::timeEnd):
(Inspector::JSGlobalObjectConsoleClient::timeStamp):
(Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
* inspector/JSGlobalObjectConsoleClient.h:
ConsoleClient now takes Ref<ScriptArgument>&& instead of RefPtr<ScriptArgument>&&.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame):
(Inspector::toJS):
* inspector/JSJavaScriptCallFrame.h:
(Inspector::JSJavaScriptCallFrame::create):
* inspector/JavaScriptCallFrame.cpp:
(Inspector::JavaScriptCallFrame::JavaScriptCallFrame):
(Inspector::JavaScriptCallFrame::caller):
* inspector/JavaScriptCallFrame.h:
(Inspector::JavaScriptCallFrame::create):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::evaluateBreakpointAction):
(Inspector::ScriptDebugServer::dispatchDidPause):
(Inspector::ScriptDebugServer::exceptionOrCaughtValue):
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
* runtime/ConsoleClient.cpp:
(JSC::ConsoleClient::printConsoleMessageWithArguments):
(JSC::ConsoleClient::internalMessageWithTypeAndLevel):
(JSC::ConsoleClient::logWithLevel):
(JSC::ConsoleClient::dir):
(JSC::ConsoleClient::dirXML):
(JSC::ConsoleClient::table):
(JSC::ConsoleClient::trace):
(JSC::ConsoleClient::assertion):
(JSC::ConsoleClient::group):
(JSC::ConsoleClient::groupCollapsed):
(JSC::ConsoleClient::groupEnd):
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::consoleLogWithLevel):
(JSC::consoleProtoFuncDir):
(JSC::consoleProtoFuncDirXML):
(JSC::consoleProtoFuncTable):
(JSC::consoleProtoFuncTrace):
(JSC::consoleProtoFuncAssert):
(JSC::consoleProtoFuncCount):
(JSC::consoleProtoFuncTimeStamp):
(JSC::consoleProtoFuncGroup):
(JSC::consoleProtoFuncGroupCollapsed):
(JSC::consoleProtoFuncGroupEnd):
2017-02-15 Keith Miller <keith_miller@apple.com>
Weak should not use jsCast in its accessors
https://bugs.webkit.org/show_bug.cgi?id=168406
Reviewed by Filip Pizlo.
This can cause assertion failures in WebCore where classes might remove themselves
from a data structure in a weak reference, if that reference is still alive.
* heap/WeakInlines.h:
(JSC::>):
(JSC::Weak<T>::operator):
(JSC::Weak<T>::get):
2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
Web Inspector: allow import() inside the inspector
https://bugs.webkit.org/show_bug.cgi?id=167457
Reviewed by Ryosuke Niwa.
We relax import module hook to accept null SourceOrigin.
Such a script can be evaluated from the inspector console.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
2017-02-16 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Update module namespace object according to the latest ECMA262
https://bugs.webkit.org/show_bug.cgi?id=168280
Reviewed by Saam Barati.
Reflect updates to the module namespace object.
1. @@iterator property is dropped[1].
2. @@toStringTag property becomes non-configurable[1].
3. delete with Symbol should be delegated to the JSObject's one[2].
[1]: https://tc39.github.io/ecma262/#sec-module-namespace-objects
[2]: https://github.com/tc39/ecma262/pull/767
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::deleteProperty):
(JSC::moduleNamespaceObjectSymbolIterator): Deleted.
2017-02-16 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. Fix the build after r212424.
Add missing file.
* inspector/remote/RemoteInspector.cpp: Added.
(Inspector::RemoteInspector::startDisabled):
(Inspector::RemoteInspector::nextAvailableTargetIdentifier):
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateClientCapabilities):
(Inspector::RemoteInspector::setRemoteInspectorClient):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::waitingForAutomaticInspection):
(Inspector::RemoteInspector::clientCapabilitiesDidChange):
(Inspector::RemoteInspector::stop):
(Inspector::RemoteInspector::listingForTarget):
(Inspector::RemoteInspector::updateHasActiveDebugSession):
2017-02-15 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop PassRefPtr in bytecompiler/
https://bugs.webkit.org/show_bug.cgi?id=168374
Reviewed by Sam Weinig.
This patch drops PassRefPtr in bytecompiler directory.
We carefully change this to Ref<>. And we use Ref<Label>
as much as possible instead of using RefPtr<Label>.
And use Label& instead of Label* as much as possible.
Currently we do not apply this change for RefPtr<RegisterID>,
to reduce the size of this patch.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
(JSC::BytecodeGenerator::newLabelScope):
(JSC::BytecodeGenerator::newLabel):
(JSC::BytecodeGenerator::newEmittedLabel):
Introduce a new helper function, which returns new label that is emitted right here.
(JSC::BytecodeGenerator::emitLabel):
(JSC::BytecodeGenerator::emitJump):
(JSC::BytecodeGenerator::emitJumpIfTrue):
(JSC::BytecodeGenerator::emitJumpIfFalse):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
(JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
Drop returning Ref<Label> since nobody uses it.
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::breakTarget):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTry):
(JSC::prepareJumpTableForSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIteratorNext):
(JSC::BytecodeGenerator::emitIteratorNextWithValue):
(JSC::BytecodeGenerator::emitIteratorClose):
(JSC::BytecodeGenerator::pushIndexedForInScope):
(JSC::BytecodeGenerator::pushStructureForInScope):
(JSC::BytecodeGenerator::invalidateForInContextForLocal):
(JSC::BytecodeGenerator::emitRequireObjectCoercible):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf):
* bytecompiler/BytecodeGenerator.h:
FinallyJump, FinallyContext, TryData, TryContext and TryRange hold Ref<Label>
instead of RefPtr<Label>. They are never nullptr.
(JSC::FinallyJump::FinallyJump):
(JSC::FinallyContext::FinallyContext):
(JSC::FinallyContext::registerJump):
(JSC::BytecodeGenerator::emitNodeInConditionContext):
(JSC::BytecodeGenerator::emitNodeForLeftHandSide):
* bytecompiler/Label.h:
Make Label noncopyable.
* bytecompiler/LabelScope.h:
(JSC::LabelScope::LabelScope):
(JSC::LabelScope::breakTarget):
breakTarget always returns Label&. On the other hand, continueTarget may be nullptr.
So it returns Label*.
* bytecompiler/NodesCodegen.cpp:
(JSC::ExpressionNode::emitBytecodeInConditionContext):
(JSC::ConstantNode::emitBytecodeInConditionContext):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::LogicalNotNode::emitBytecodeInConditionContext):
(JSC::BinaryOpNode::emitBytecodeInConditionContext):
(JSC::InstanceOfNode::emitBytecode):
(JSC::LogicalOpNode::emitBytecode):
(JSC::LogicalOpNode::emitBytecodeInConditionContext):
(JSC::ConditionalNode::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ContinueNode::trivialTarget):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::trivialTarget):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::TryNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
(JSC::assignDefaultValueIfUndefined):
(JSC::ArrayPatternNode::bindValue):
Use Ref<Label> and Label&.
* parser/Nodes.h:
2017-02-15 Alex Christensen <achristensen@webkit.org>
Unreviewed, rolling out r212394.
Fixed iOS WebInspector
Reverted changeset:
"Unreviewed, rolling out r212169."
https://bugs.webkit.org/show_bug.cgi?id=166681
http://trac.webkit.org/changeset/212394
2017-02-15 Guillaume Emont <guijemont@igalia.com>
MIPS: add missing implementations of load8SignedExtendTo32()
JSC: missing implementations of MacroAssemblerMIPS::load8SignedExtendTo32()
https://bugs.webkit.org/show_bug.cgi?id=168350
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
Add missing implementations
2017-02-15 Alex Christensen <achristensen@webkit.org>
Unreviewed, rolling out r212169.
Broke iOS WebInspector
Reverted changeset:
"WebInspector: refactor RemoteInspector to move cocoa specific
code to their own files"
https://bugs.webkit.org/show_bug.cgi?id=166681
http://trac.webkit.org/changeset/212169
2017-02-15 Chris Dumez <cdumez@apple.com>
Expose Symbol.toPrimitive / valueOf on Location instances
https://bugs.webkit.org/show_bug.cgi?id=168295
Reviewed by Geoffrey Garen, Keith Miller and Mark Lam.
Cache origin objectProtoValueOf function on JSGlobalObject.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::objectProtoValueOfFunction):
2017-02-15 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop PassRefPtr
https://bugs.webkit.org/show_bug.cgi?id=168320
Reviewed by Saam Barati.
* API/JSContextRef.cpp:
(JSGlobalContextCreateInGroup):
Use Ref<VM> from the factory function.
* API/JSScriptRef.cpp:
(OpaqueJSScript::create):
Return Ref<> instead.
* API/tests/JSONParseTest.cpp:
(testJSONParse):
Use Ref<VM>.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
Use reference since we already perform null check.
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodeRef::MacroAssemblerCodeRef):
Take Ref<>&& instead of PassRefPtr<>.
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setStub):
(JSC::CallLinkInfo::setSlowStub):
Take Ref<>&& instead of PassRefPtr<>.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
Take RefPtr<SourceProvider>. Currently, the SourceProvider would be nullptr.
We will change it to Ref<SourceProvider> in https://bugs.webkit.org/show_bug.cgi?id=168325.
(JSC::CodeBlock::finishCreation):
Take Ref<TypeSet>&&.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
Take Ref<>&& instead.
(JSC::CodeBlock::jitCode):
Return RefPtr<> instead.
* bytecode/EvalCodeBlock.h:
(JSC::EvalCodeBlock::create):
Take RefPtr<>&& instead since SourceProvider woule be nullptr.
(JSC::EvalCodeBlock::EvalCodeBlock):
* bytecode/FunctionCodeBlock.h:
(JSC::FunctionCodeBlock::create):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
Take RefPtr<>&& instead since SourceProvider woule be nullptr.
* bytecode/GlobalCodeBlock.h:
(JSC::GlobalCodeBlock::GlobalCodeBlock):
Take RefPtr<>&& instead since SourceProvider woule be nullptr.
* bytecode/ModuleProgramCodeBlock.h:
(JSC::ModuleProgramCodeBlock::create):
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
Take RefPtr<>&& instead since SourceProvider woule be nullptr.
* bytecode/ProgramCodeBlock.h:
(JSC::ProgramCodeBlock::create):
(JSC::ProgramCodeBlock::ProgramCodeBlock):
Take RefPtr<>&& instead since SourceProvider woule be nullptr.
* debugger/DebuggerParseData.cpp:
(JSC::gatherDebuggerParseDataForSource):
Ensure the provider is not nullptr. It is OK because we already
touch `provider->xxx` values.
* dfg/DFGBlockInsertionSet.cpp:
(JSC::DFG::BlockInsertionSet::insert):
Take Ref<>&& instead.
* dfg/DFGBlockInsertionSet.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
Pass Ref<>&& to appendBlock.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
(JSC::DFG::compile):
Pass Ref<Plan>&&. And take Ref<>&& callback.
* dfg/DFGDriver.h:
* dfg/DFGGraph.h:
appendBlock takes Ref<>&&.
(JSC::DFG::Graph::appendBlock):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::jitCode):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::JITFinalizer):
Take Ref<JITCode>&&.
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
Pass compilation reference since we already perform null check.
* dfg/DFGJITFinalizer.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::enqueue):
Take Ref<Plan>&&.
* dfg/DFGWorklist.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
Dereference and pass jitCode & compilation references.
* jit/GCAwareJITStubRoutine.cpp:
(JSC::createJITStubRoutine):
Return Ref<> instead.
* jit/GCAwareJITStubRoutine.h:
(JSC::createJITStubRoutine):
* jit/JIT.cpp:
(JSC::JIT::link):
Pass compilation reference since we already perform null check.
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::asCodePtr):
Take Ref<>&& instead. And this drops unnecessary null check.
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
Pass Ref<> to NativeExecutable::create.
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
Use Ref<>&& instead.
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode):
(JSC::SourceCode::subExpression):
Add constructors taking Ref<>&&.
We still have constructors that take RefPtr<>&&.
We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.
* parser/UnlinkedSourceCode.h:
(JSC::UnlinkedSourceCode::UnlinkedSourceCode):
Add constructors taking Ref<>&&.
We still have constructors that take RefPtr<>&&.
We will change it to Ref<SourceProvider>&& in https://bugs.webkit.org/show_bug.cgi?id=168325.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addCompilation):
Take Ref<Compilation>&&.
* profiler/ProfilerDatabase.h:
Change data structures to hold Ref<> instead of RefPtr<>.
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::generatedJITCode):
Return Ref<> instead.
* runtime/ExecutableBase.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ExecutableBase::generatedJITCodeForConstruct):
(JSC::ExecutableBase::generatedJITCodeFor):
Return Ref<> instead.
* runtime/Identifier.cpp:
(JSC::Identifier::add):
(JSC::Identifier::add8):
* runtime/Identifier.h:
(JSC::Identifier::add):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::setInputCursor):
And take Ref<> in this method.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::inputCursor):
Change m_inputCursor from RefPtr<> to Ref<>.
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::create):
(JSC::JSPropertyNameEnumerator::finishCreation):
Take Ref<PropertyNameArray>&&.
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSString.h:
(JSC::JSString::JSString):
Take Ref<StringImpl>&& since we do not allow nullptr in this constructor.
(JSC::JSString::create):
(JSC::JSString::createHasOtherOwner):
Take Ref<StringImpl>&& in these factory functions. And drop unnecessary assertions.
(JSC::jsSingleCharacterString):
Use StringImpl::create() which returns Ref<>.
(JSC::jsNontrivialString):
Dereference impl() since we ensure that `s.length() > 1`.
(JSC::jsString):
Use releaseNonNull() since we ensure that `s.length() > 1`.
(JSC::jsOwnedString):
Use releaseNonNull() since we ensure that `s.length() > 1`.
* runtime/ModuleProgramExecutable.h:
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::finishCreation):
Take Ref<JITCode>&&.
* runtime/NativeExecutable.h:
* runtime/ProgramExecutable.h:
Return Ref<JITCode>.
* runtime/PropertyNameArray.h:
(JSC::PropertyNameArray::releaseData):
(JSC::PropertyNameArray::setData): Deleted.
This is not used.
* runtime/RegExpKey.h:
(JSC::RegExpKey::RegExpKey):
Take RefPtr<>&&.
* runtime/SmallStrings.cpp:
(JSC::SmallStringsStorage::rep):
Return StringImpl& since m_reps is already initialized in the constructor.
(JSC::SmallStrings::createEmptyString):
Dereference StringImpl::empty().
(JSC::SmallStrings::createSingleCharacterString):
Use StringImpl&.
(JSC::SmallStrings::singleCharacterStringRep):
Return StringImpl&.
(JSC::SmallStrings::initialize):
Use AtomicStringImpl::add instead.
* runtime/SmallStrings.h:
* runtime/Structure.cpp:
(JSC::Structure::toStructureShape):
Return Ref<>.
* runtime/Structure.h:
* runtime/TypeLocationCache.cpp:
(JSC::TypeLocationCache::getTypeLocation):
Take RefPtr<TypeSet>&&.
* runtime/TypeLocationCache.h:
* runtime/TypeProfilerLog.cpp:
Pass Ref<>&&.
(JSC::TypeProfilerLog::processLogEntries):
* runtime/TypeSet.cpp:
(JSC::TypeSet::addTypeInformation):
Take RefPtr<>&& since it can be nullptr.
And clean up "not found" code.
(JSC::TypeSet::allStructureRepresentations):
Use range based iteration.
(JSC::StructureShape::leastCommonAncestor):
We found that this method accidentally takes `const Vector<>` instead of `const Vector<>&`.
And internally, we just use raw pointers since these StructureShapes are owned by the m_proto trees which starts from the given Vector<>.
(JSC::StructureShape::hasSamePrototypeChain):
Take const reference instead. And use raw pointers internally.
(JSC::StructureShape::merge):
Take Ref<>&&.
* runtime/TypeSet.h:
(JSC::StructureShape::setProto):
Take Ref<>&&.
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
Pass Ref<>&&.
(JSC::VM::queueMicrotask):
Take and pass Ref<>&&.
* runtime/VM.h:
(JSC::QueuedTask::QueuedTask):
Take Ref<>&&.
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
We need this change due to Ref<>&& and RefPtr<>&& ambiguity of SourceCode constructors.
Once SourceCode is fixed to only take Ref<>&&, this change is unnecessary.
2017-02-15 Csaba Osztrogonác <ossy@webkit.org>
[Mac][cmake] Unreviewed trivial buildfix after r212169.
https://bugs.webkit.org/show_bug.cgi?id=166681
* PlatformMac.cmake: Removed inspector/remote/RemoteInspectorXPCConnection.mm.
2017-02-14 Mark Lam <mark.lam@apple.com>
Add JSC_sweepSynchronously and fix JSC_useZombieMode options.
https://bugs.webkit.org/show_bug.cgi?id=168257
<rdar://problem/30451496>
Reviewed by Filip Pizlo.
JSC_useZombieMode now basically enables JSC_sweepSynchronously and
JSC_scribbleFreeCells, which together does the job of zombifying dead objects
immediately after a GC.
* heap/Heap.cpp:
(JSC::Heap::sweepSynchronously):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::finalize):
(JSC::Heap::didFinishCollection):
(JSC::Zombify::visit): Deleted.
(JSC::Zombify::operator()): Deleted.
(JSC::Heap::zombifyDeadObjects): Deleted.
* heap/Heap.h:
(JSC::Heap::isZombified): Deleted.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2017-02-13 Michael Saboff <msaboff@apple.com>
asyncDisassembly crashes on iOS
https://bugs.webkit.org/show_bug.cgi?id=168259
Reviewed by Filip Pizlo.
Eliminated the dumping of the disassembly for the JIT write thunk.
Not only does it fix the crash, but given the nature of the JIT
write thunk, we probably don't want to disassemble it anyway.
* jit/ExecutableAllocatorFixedVMPool.cpp:
(JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
2017-02-12 Ryosuke Niwa <rniwa@webkit.org>
C loop build fix attempt after r212207.
* runtime/Lookup.h:
2017-02-11 Sam Weinig <sam@webkit.org>
Remove the remaining functions out of JSDOMBinding
https://bugs.webkit.org/show_bug.cgi?id=168179
Reviewed by Darin Adler.
Move utility functions into more appropriate locations.
- Move hasIteratorMethod to IteratorOperations.
- Move nonCachingStaticFunctionGetter to Lookup
* runtime/IteratorOperations.cpp:
(JSC::hasIteratorMethod):
* runtime/IteratorOperations.h:
* runtime/Lookup.h:
(JSC::nonCachingStaticFunctionGetter):
2017-02-11 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Implement (Shared)ArrayBuffer.prototype.byteLength
https://bugs.webkit.org/show_bug.cgi?id=166476
Reviewed by Saam Barati.
`byteLength` becomes getter and is set in ArrayBuffer.prototype
and SharedArrayBuffer.prototype. This patch implements the
above getter in native function. We do not have any optimization
path for that for now since ArrayBuffer.prototype.byteLength is
not considered a hot function: while TypedArrays have [] accesses,
ArrayBuffer does not have that. Thus byteLength getter is not so
meaningful for a hot paths like iterations.
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::getOwnPropertySlot): Deleted.
(JSC::JSArrayBuffer::put): Deleted.
(JSC::JSArrayBuffer::defineOwnProperty): Deleted.
(JSC::JSArrayBuffer::deleteProperty): Deleted.
(JSC::JSArrayBuffer::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSArrayBuffer.h:
(JSC::JSArrayBuffer::impl): Deleted.
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoGetterFuncByteLength):
(JSC::sharedArrayBufferProtoGetterFuncByteLength):
(JSC::JSArrayBufferPrototype::finishCreation):
2017-02-10 Saam Barati <sbarati@apple.com>
Object allocation sinking phase doesn't properly handle control flow when emitting a PutHint of a materialized object into a PromotedHeapLocation of a still sunken object
https://bugs.webkit.org/show_bug.cgi?id=168140
<rdar://problem/30205880>
Reviewed by Filip Pizlo.
This patch fixes a bug in allocation sinking phase where
we don't properly handle control flow when materializing
an object and also PutHinting that materialization into
a still sunken object. We were performing the PutHint
for the materialization at the point of materialization,
however, we may have materialized along both edges
of a control flow diamond, in which case, we need to
also PutHint at the join point. Consider this program:
```
bb#0:
b: PhantomActivation()
a: PhantomNewFunction()
c: PutHint(@a, @b, ActivationLoc)
Branch(#1, #2)
bb#1:
d: MaterializeActivation()
e: PutHint(@a, @d, ActivationLoc)
f: Upsilon(@d, ^p)
Jump(#3)
bb#2:
g: MaterializeActivation()
h: PutHint(@a, @g, ActivationLoc)
i: Upsilon(@d, ^p)
Jump(#3)
bb#3:
p: Phi()
// What is PromotedHeapLocation(@a, ActivationLoc) here?
// What would we do if we exited?
```
Before this patch, we didn't perform a PutHint of the Phi.
However, we need to, otherwise when exit, we won't know
the value of PromotedHeapLocation(@a, ActivationLoc)
The program we need then, for correctness, is this:
```
bb#0:
b: PhantomActivation()
a: PhantomNewFunction()
c: PutHint(@a, @b, ActivationLoc)
Branch(#1, #2)
bb#1:
d: MaterializeActivation()
e: PutHint(@a, @d, ActivationLoc)
f: Upsilon(@d, ^p)
Jump(#3)
bb#2:
g: MaterializeActivation()
h: PutHint(@a, @g, ActivationLoc)
i: Upsilon(@d, ^p)
Jump(#3)
bb#3:
p: Phi()
j: PutHint(@a, @p, ActivationLoc)
```
This patch makes it so that we emit the necessary PutHint at node `j`.
I've also added more validation to the OSRAvailabilityAnalysisPhase
to catch this problem during validation.
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2017-02-10 Carlos Garcia Campos <cgarcia@igalia.com>
WebInspector: refactor RemoteInspector to move cocoa specific code to their own files
https://bugs.webkit.org/show_bug.cgi?id=166681
Reviewed by Michael Catanzaro.
Move RemoteConnectionToTarget.mm and RemoteInspector.mm to a cocoa directory renamed with a Cocoa prefix,
because those are now the cocoa implementation of RemoteConnectionToTarget and RemoteInspector. The
cross-platform parts of RemoteInspector have been moced to a new RemoteInspector.cpp file. Also moved to cocoa
directory RemoteInspectorXPCConnection.h and RemoteInspectorXPCConnection.mm keeping the same name. Other than
that there aren't important code changes, only some cocoa specific types like NSString used in common headers,
and some other platform ifdefs needed. This is in preparation for adding a remote inspector implementation for
the GTK+ port.
* API/JSRemoteInspector.cpp:
(JSRemoteInspectorSetParentProcessInformation): Add PLATFORM(COCOA) to the ifdef.
* JavaScriptCore.xcodeproj/project.pbxproj:
* PlatformMac.cmake:
* inspector/remote/RemoteConnectionToTarget.h: Add platform ifdefs for cocoa specific parts and change
sendMessageToTarget to receive a WTF String instead of an NSString.
* inspector/remote/RemoteControllableTarget.h: Add platform ifdefs for CF specific parts.
* inspector/remote/RemoteInspectionTarget.h:
* inspector/remote/RemoteInspector.cpp: Added.
(Inspector::RemoteInspector::startDisabled):
(Inspector::RemoteInspector::nextAvailableTargetIdentifier):
(Inspector::RemoteInspector::registerTarget):
(Inspector::RemoteInspector::unregisterTarget):
(Inspector::RemoteInspector::updateTarget):
(Inspector::RemoteInspector::updateClientCapabilities):
(Inspector::RemoteInspector::setRemoteInspectorClient):
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::setupCompleted):
(Inspector::RemoteInspector::waitingForAutomaticInspection):
(Inspector::RemoteInspector::clientCapabilitiesDidChange):
(Inspector::RemoteInspector::stop):
(Inspector::RemoteInspector::listingForTarget):
(Inspector::RemoteInspector::updateHasActiveDebugSession):
* inspector/remote/RemoteInspector.h: Add platform ifdefs for cocoa specific parts. Also add TargetListing
typedef to define platform specific types for the listings without more ifdefs.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteConnectionToTarget.mm.
(Inspector::RemoteTargetInitializeGlobalQueue):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::setupRunLoop):
* inspector/remote/cocoa/RemoteInspectorCocoa.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspector.mm.
(Inspector::canAccessWebInspectorMachPort):
(Inspector::RemoteInspector::singleton):
(Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
(Inspector::RemoteInspector::start):
(Inspector::RemoteInspector::pushListingsSoon):
(Inspector::RemoteInspector::receivedIndicateMessage):
(Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
* inspector/remote/cocoa/RemoteInspectorXPCConnection.h: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.h.
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: Renamed from Source/JavaScriptCore/inspector/remote/RemoteInspectorXPCConnection.mm.
(Inspector::RemoteInspectorXPCConnection::closeFromMessage):
2017-02-10 Brian Burg <bburg@apple.com>
[Cocoa] Web Inspector: payload initializers for ObjC protocol types handles special-cased property names incorrectly
https://bugs.webkit.org/show_bug.cgi?id=168141
Reviewed by Joseph Pecoraro.
The generated code erroneously uses the ObjC variable name as the payload key,
rather than the raw type member name. For example, 'identifier' would be used instead of 'id'.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload):
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
Rebaseline an affected test.
2017-02-10 Mark Lam <mark.lam@apple.com>
StructureStubInfo::considerCaching() should write barrier its owner CodeBlock when buffering a new Structure.
https://bugs.webkit.org/show_bug.cgi?id=168137
<rdar://problem/28656664>
Reviewed by Filip Pizlo.
If we're adding a new structure to StructureStubInfo's bufferedStructures, we
should write barrier the StubInfo's owner CodeBlock because that structure may be
collected during the next GC. Write barrier-ing the owner CodeBlock ensures that
CodeBlock::finalizeBaselineJITInlineCaches() is called on it during the GC,
which, in turn, gives the StructureStubInfo the opportunity to filter out the
dead structure.
* bytecode/StructureStubInfo.h:
(JSC::StructureStubInfo::considerCaching):
* jit/JITOperations.cpp:
2017-02-10 Brian Burg <bburg@apple.com>
[Cocoa] Web Inspector: generate an NS_ENUM containing platforms supported by the protocol code generator
https://bugs.webkit.org/show_bug.cgi?id=168019
<rdar://problem/28718990>
Reviewed by Joseph Pecoraro.
It's useful to have an symbolic value (not a string) for each of the supported platform values.
Generate this once per protocol for the Objective-C bindings. Covered by existing tests.
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_enum_for_platforms):
Create an NS_ENUM for Platform values in Platforms.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_for_platforms):
Add type conversion/parsing methods for the newly added enum.
* inspector/scripts/codegen/generator.py:
(Generator.stylized_name_for_enum_value):
(Generator.stylized_name_for_enum_value.replaceCallback):
Support arbitrary special-cased substrings in enums, not just all-caps. Add 'IOS' and 'MacOS'.
* inspector/scripts/codegen/models.py:
(Platforms):
Use lower-case string values for platform names, to avoid guesswork.
(Platforms.__metaclass__):
(Platforms.__metaclass__.__iter__):
Make it possible to iterate over Platform instances of Platforms.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domain-availability.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Rebaseline results.
2017-02-09 Filip Pizlo <fpizlo@apple.com>
SharedArrayBuffer does not need to be in the transfer list
https://bugs.webkit.org/show_bug.cgi?id=168079
Reviewed by Geoffrey Garen and Keith Miller.
Exposes a simple shareWith() API for when you know you want to share the contents of
a shared buffer. Also a useful explicit operator bool.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::shareWith):
* runtime/ArrayBuffer.h:
(JSC::ArrayBufferContents::operator bool):
2017-02-09 Mark Lam <mark.lam@apple.com>
B3::Procedure::deleteOrphans() should neutralize upsilons with dead phis.
https://bugs.webkit.org/show_bug.cgi?id=167437
<rdar://problem/30198083>
Reviewed by Filip Pizlo.
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::deleteOrphans):
2017-02-09 Saam Barati <sbarati@apple.com>
Sloppy mode: We don't properly hoist functions names "arguments" when we have a non-simple parameter list
https://bugs.webkit.org/show_bug.cgi?id=167319
<rdar://problem/30149432>
Reviewed by Mark Lam.
When hoisting a function inside sloppy mode, we were assuming all "var"s are inside
what we call the "var" SymbolTableEntry. This was almost true, execpt for "arguments",
which has sufficiently weird behavior. "arguments" can be visible to the default
parameter expressions inside a function, therefore can't go inside the "var"
SymbolTableEntry since the parameter SymbolTableEntry comes before the "var"
SymbolTableEntry in the scope chain. Therefore, if we hoist a function named
"arguments", then we must also look for that variable inside the parameter scope
stack entry.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2017-02-09 Mark Lam <mark.lam@apple.com>
Fix max length check in ArrayPrototype.js' concatSlowPath().
https://bugs.webkit.org/show_bug.cgi?id=167270
<rdar://problem/30128133>
Reviewed by Filip Pizlo.
1. Fixed concatSlowPath() to ensure that the result array length does not exceed
@MAX_ARRAY_INDEX. The old code was checking against @MAX_SAFE_INTEGER in some
cases, but this is overly permissive.
2. Changed concatSlowPath() to throw a RangeError instead of a TypeError to be
consistent with the C++ runtime functions in JSArray.cpp.
3. Changed the RangeError message in concatSlowPath() and JSArray.cpp to "Length
exceeded the maximum array length" when the error is that the result length
exceeds MAX_ARRAY_INDEX. We do this for 2 reasons:
a. "Length exceeded the maximum array length" is more informative than
"Invalid array length".
b. We want to use the same string consistently for the same error.
There are still 2 places in JSArray.cpp that still throws a RangeError with
message "Invalid array length". In those cases, the error is not necessarily
due to the result length exceeding MAX_ARRAY_INDEX, but is due to attempting to
set a length value that is not an integer that fits in MAX_ARRAY_INDEX e.g.
an attempt to set a fractional length value. Hence, "Invalid array length" is
appropriate for those cases.
4. Fixed JSArray::appendMemcpy() to handle overflows when computing the result
array length.
* builtins/ArrayPrototype.js:
(concatSlowPath):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/ArrayPrototype.cpp:
(JSC::concatAppendOne):
(JSC::arrayProtoPrivateFuncAppendMemcpy):
* runtime/JSArray.cpp:
(JSC::JSArray::appendMemcpy):
(JSC::JSArray::push):
2017-02-09 Mark Lam <mark.lam@apple.com>
Constructed object's global object should be the global object of the constructor.
https://bugs.webkit.org/show_bug.cgi?id=167121
<rdar://problem/30054759>
Reviewed by Filip Pizlo and Geoffrey Garen.
The realm (i.e. globalObject) of any object should be the same as the constructor
that instantiated the object. Changed PrototypeMap::createEmptyStructure() to
be passed the correct globalObject to use instead of assuming it's the same one
as the prototype object.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::initialize):
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::initializeObjectAllocationProfile):
* runtime/FunctionRareData.h:
(JSC::FunctionRareData::createInternalFunctionAllocationStructureFromBase):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/IteratorOperations.cpp:
(JSC::createIteratorResultObjectStructure):
* runtime/JSBoundFunction.cpp:
(JSC::getBoundFunctionStructure):
* runtime/JSFunction.cpp:
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setTarget):
* runtime/ObjectConstructor.h:
(JSC::constructEmptyObject):
* runtime/PrototypeMap.cpp:
(JSC::PrototypeMap::createEmptyStructure):
(JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure):
(JSC::PrototypeMap::emptyObjectStructureForPrototype):
(JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
* runtime/PrototypeMap.h:
2017-02-09 Keith Miller <keith_miller@apple.com>
We should not allow Function.caller to be used on native functions
https://bugs.webkit.org/show_bug.cgi?id=165628
Reviewed by Mark Lam.
Also remove unneeded dynamic cast.
* runtime/JSFunction.cpp:
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
(JSC::JSFunction::callerGetter):
2017-02-08 Keith Miller <keith_miller@apple.com>
[JSC] op_in should have ArrayProfile
https://bugs.webkit.org/show_bug.cgi?id=164581
Reviewed by Filip Pizlo.
This patch adds an ArrayProfile to the op_in bytecode. In the
DFG, if we see that we the key is an int32 we will convert the In
DFG node to a HasIndexedProperty node instead.
This patch also flips the two arguments of op_in and the In node
to reflect the other property lookup bytecodes.
* bytecode/BytecodeList.json:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::finishCreation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIn):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitIn): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::InNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertToHasIndexedProperty):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasInternalMethodType):
(JSC::DFG::Node::internalMethodType):
(JSC::DFG::Node::setInternalMethodType):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileIn):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LowLevelInterpreter.asm:
* parser/Nodes.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
2017-02-08 Saam Barati <sbarati@apple.com>
Air IRC might spill a terminal that produces a value after the terminal
https://bugs.webkit.org/show_bug.cgi?id=167919
<rdar://problem/29754721>
Reviewed by Filip Pizlo.
IRC may spill a value-producing terminal (a patchpoint can be a value-producing terminal).
It used to do this by placing the spill *after* the terminal. This produces an invalid
graph because no instructions are allowed after the terminal.
I fixed this bug by having a cleanup pass over the IR after IRC is done.
The pass detects this problem, and fixes it by moving the spill into the
successors. However, it is careful to detect when the edge to the
successor is a critical edge. If the value-producing patchpoint is
the only predecessor of the successor, it just moves the spill
code to the beginning of the successor. Otherwise, it's a critical
edge and it breaks it by adding a block that does the spilling then
jumps to the successor.
* b3/air/AirInsertionSet.cpp:
* b3/air/AirInsertionSet.h:
(JSC::B3::Air::InsertionSet::insertInsts):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/testb3.cpp:
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
(JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
(JSC::B3::run):
2017-02-07 Mark Lam <mark.lam@apple.com>
SigillCrashAnalyzer::analyze() should use a do-while loop instead of a lambda.
https://bugs.webkit.org/show_bug.cgi?id=167950
Reviewed by Michael Saboff.
Lambdas aren't free (apparently, the compiler isn't able to detect that the
lambda does not escape and can be inlined completely). So, use a do-while loop
instead since we don't really need a lambda here.
* tools/SigillCrashAnalyzer.cpp:
2017-02-05 Mark Lam <mark.lam@apple.com>
The SigillCrashAnalyzer should play nicer with client code that may install its own SIGILL handler.
https://bugs.webkit.org/show_bug.cgi?id=167858
Reviewed by Michael Saboff.
Here are the scenarios that may come up:
1. Client code did not install a SIGILL handler.
- In this case, once we're done analyzing the SIGILL, we can just restore the
default handler and return to let the OS do the default action i.e. capture
a core dump.
2. Client code installed a SIGILL handler before JSC does.
- In this case, we will see a non-null handler returned as the old signal
handler when we install ours.
- In our signal handler, after doing our crash analysis, we should invoke the
client handler to let it do its work.
- Our analyzer can also tell us if the SIGILL source is from JSC code in
general (right now, this would just mean JIT code).
- If the SIGILL source is not from JSC, we'll just let the client handler
decided how to proceed. We assume that the client handler will do the right
thing (which is how the old behavior is before the SigillCrashAnalyzer was
introduced).
- If the SIGILL source is from JSC, then we know the SIGILL is an unrecoverable
condition. Hence, after we have given the client handler a chance to run,
we should restore the default handler and let the OS capture a core dump.
This intentionally overrides whatever signal settings the client handler may
have set.
3. Client code installed a SIGILL handler after JSC does.
- In this case, we are dependent on the client handler to call our handler
after it does its work. This is compatible with the old behavior before
SigillCrashAnalyzer was introduced.
- In our signal handler, if we determine that the SIGILL source is from JSC
code, then the SIGILL is not recoverable. We should then restore the
default handler and get a core dump.
- If the SIGILL source is not from JSC, we check to see if there's a client
handler installed after us.
- If we detect a client handler installed after us, we defer judgement on what
to do to the client handler. Since the client handler did not uninstall
itself, it must have considered itself to have recovered from the SIGILL.
We'll trust the client handler and take no restore action of our own (which
is compatible with old code behavior).
- If we detect no client handler and we have no previous handler, then we
should restore the default handler and get a core dump.
* tools/SigillCrashAnalyzer.cpp:
(JSC::handleCrash):
(JSC::installCrashHandler):
(JSC::SigillCrashAnalyzer::analyze): Deleted.
2017-02-07 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, manual roll out of r211777
https://bugs.webkit.org/show_bug.cgi?id=167457
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
2017-02-07 Yusuke Suzuki <utatane.tea@gmail.com>
Web Inspector: allow import() inside the inspector
https://bugs.webkit.org/show_bug.cgi?id=167457
Reviewed by Ryosuke Niwa.
We relax import module hook to accept null SourceOrigin.
Such a script can be evaluated from the inspector console.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
2017-02-06 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Do not use RunLoop when dispatching inspector GC event
https://bugs.webkit.org/show_bug.cgi?id=167683
<rdar://problem/30167791>
Reviewed by Brian Burg.
Move the RunLoop deferred implementation to WebCore. It is not needed
for JSContext inspection, and in JSContext inspection we are not
guarenteed a RunLoop to defer to.
* inspector/agents/InspectorHeapAgent.h:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::InspectorHeapAgent):
(Inspector::InspectorHeapAgent::~InspectorHeapAgent):
(Inspector::InspectorHeapAgent::disable):
(Inspector::InspectorHeapAgent::didGarbageCollect):
(Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): Deleted.
(Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): Deleted.
(Inspector::SendGarbageCollectionEventsTask::reset): Deleted.
(Inspector::SendGarbageCollectionEventsTask::timerFired): Deleted.
(Inspector::InspectorHeapAgent::dispatchGarbageCollectedEvent):
Make a virtual method so that WebCore implementations of this agent can choose
to dispatch this event asynchronously.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
Remove unnecessary RunLoop include.
2017-02-06 Joseph Pecoraro <pecoraro@apple.com>
Static Analyzer: JSContext.mm: Incorrect decrement of the reference count of an object
https://bugs.webkit.org/show_bug.cgi?id=167848
Reviewed by Saam Barati.
Source/JavaScriptCore/API/JSContext.mm:87:5: warning: Incorrect decrement of the reference count of an object that is not owned at this point by the caller
[self.exceptionHandler release];
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
* API/JSContext.mm:
(-[JSContext dealloc]):
Use the ivar in dealloc instead of going through the getter.
2017-02-05 Mark Lam <mark.lam@apple.com>
The VMInspector should use an RAII Locker.
https://bugs.webkit.org/show_bug.cgi?id=167854
Reviewed by Saam Barati.
Previously, VMInspector::lock() was returning an expected LockToken, and there's
no way to unlock it when we're done with it. This was not a problem before
because the VMInspector had only one client, the SigillCrashAnalyzer, that
expected the process to crash due to a SIGILL shortly thereafter.
However, the VMInspector is useful as a debugging tool that we can apply in other
debugging tasks. Fixing VMInspector::lock() to return an RAII locker will enable
other use cases. Plus it's just bad form to be able to lock something and never
be able to unlock it.
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::analyze):
* tools/VMInspector.cpp:
* tools/VMInspector.h:
2017-02-04 Joseph Pecoraro <pecoraro@apple.com>
Static Analyzer: Value stored to 'recordedMachineThreads' during its initialization is never read
https://bugs.webkit.org/show_bug.cgi?id=167845
Reviewed by Saam Barati.
Source/JavaScriptCore/heap/MachineStackMarker.cpp:151:14: warning: Value stored to 'recordedMachineThreads' during its initialization is never read
auto recordedMachineThreads = m_set.take(machineThreads);
^~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
* heap/MachineStackMarker.cpp:
(JSC::ActiveMachineThreadsManager::remove):
2017-02-04 Joseph Pecoraro <pecoraro@apple.com>
Static Analyzer: Value stored to 'prev' is never read
https://bugs.webkit.org/show_bug.cgi?id=167844
Reviewed by Saam Barati.
Source/JavaScriptCore/runtime/JSMapIterator.h:60:13: warning: Value stored to 'prev' is never read
prev = bucket;
^ ~~~~~~
Source/JavaScriptCore/runtime/JSSetIterator.h:60:13: warning: Value stored to 'prev' is never read
prev = bucket;
^ ~~~~~~
* runtime/JSMapIterator.h:
(JSC::JSMapIterator::advanceIter):
* runtime/JSSetIterator.h:
(JSC::JSSetIterator::advanceIter):
2017-02-04 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add operationToInt32SensibleSlow to optimize kraken pbkdf2 and sha256
https://bugs.webkit.org/show_bug.cgi?id=167736
Reviewed by Saam Barati.
Add a new function operationToInt32SensibleSlow. This function is only
called after x86 cvttss2si_rr is failed. This means that the
given double number never in range of int32 truncatable numbers.
As a result, exp in operationToInt32 always becomes >= 31. So
we can change the condition from `exp < 32` to `exp == 31`.
This makes missingOne constant. And it leads significantly good
code generation.
The original operationToInt32 code.
170: 66 48 0f 7e c1 movq %xmm0,%rcx
175: 31 c0 xor %eax,%eax
177: 66 48 0f 7e c6 movq %xmm0,%rsi
17c: 48 c1 f9 34 sar $0x34,%rcx
180: 81 e1 ff 07 00 00 and $0x7ff,%ecx
186: 8d 91 01 fc ff ff lea -0x3ff(%rcx),%edx
18c: 83 fa 53 cmp $0x53,%edx
18f: 77 37 ja 1c8 <_ZN3JSC16operationToInt32Ed+0x58>
191: 83 fa 34 cmp $0x34,%edx
194: 7f 3a jg 1d0 <_ZN3JSC16operationToInt32Ed+0x60>
196: b9 34 00 00 00 mov $0x34,%ecx
19b: 66 48 0f 7e c7 movq %xmm0,%rdi
1a0: 29 d1 sub %edx,%ecx
1a2: 48 d3 ff sar %cl,%rdi
1a5: 83 fa 1f cmp $0x1f,%edx
1a8: 89 f8 mov %edi,%eax
1aa: 7f 12 jg 1be <_ZN3JSC16operationToInt32Ed+0x4e>
1ac: 89 d1 mov %edx,%ecx
1ae: b8 01 00 00 00 mov $0x1,%eax
1b3: d3 e0 shl %cl,%eax
1b5: 89 c2 mov %eax,%edx
1b7: 8d 40 ff lea -0x1(%rax),%eax
1ba: 21 f8 and %edi,%eax
1bc: 01 d0 add %edx,%eax
1be: 89 c2 mov %eax,%edx
1c0: f7 da neg %edx
1c2: 48 85 f6 test %rsi,%rsi
1c5: 0f 48 c2 cmovs %edx,%eax
1c8: f3 c3 repz retq
1ca: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
1d0: 66 48 0f 7e c0 movq %xmm0,%rax
1d5: 81 e9 33 04 00 00 sub $0x433,%ecx
1db: 48 d3 e0 shl %cl,%rax
1de: eb de jmp 1be <_ZN3JSC16operationToInt32Ed+0x4e>
The operationToInt32SensibleSlow code.
1e0: 66 48 0f 7e c1 movq %xmm0,%rcx
1e5: 66 48 0f 7e c2 movq %xmm0,%rdx
1ea: 48 c1 f9 34 sar $0x34,%rcx
1ee: 81 e1 ff 07 00 00 and $0x7ff,%ecx
1f4: 8d b1 01 fc ff ff lea -0x3ff(%rcx),%esi
1fa: 83 fe 34 cmp $0x34,%esi
1fd: 7e 21 jle 220 <_ZN3JSC28operationToInt32SensibleSlowEd+0x40>
1ff: 66 48 0f 7e c0 movq %xmm0,%rax
204: 81 e9 33 04 00 00 sub $0x433,%ecx
20a: 48 d3 e0 shl %cl,%rax
20d: 89 c1 mov %eax,%ecx
20f: f7 d9 neg %ecx
211: 48 85 d2 test %rdx,%rdx
214: 0f 48 c1 cmovs %ecx,%eax
217: c3 retq
218: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
21f: 00
220: 66 48 0f 7e c0 movq %xmm0,%rax
225: b9 34 00 00 00 mov $0x34,%ecx
22a: 29 f1 sub %esi,%ecx
22c: 48 d3 f8 sar %cl,%rax
22f: 89 c1 mov %eax,%ecx
231: 81 c9 00 00 00 80 or $0x80000000,%ecx
237: 83 fe 1f cmp $0x1f,%esi
23a: 0f 44 c1 cmove %ecx,%eax
23d: 89 c1 mov %eax,%ecx
23f: f7 d9 neg %ecx
241: 48 85 d2 test %rdx,%rdx
244: 0f 48 c1 cmovs %ecx,%eax
247: c3 retq
248: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
24f: 00
This improves kraken pbkdf2 by 10.8% and sha256 by 7.5%.
baseline patched
stanford-crypto-pbkdf2 153.195+-2.745 ^ 138.204+-2.513 ^ definitely 1.1085x faster
stanford-crypto-sha256-iterative 49.047+-1.038 ^ 45.610+-1.235 ^ definitely 1.0754x faster
<arithmetic> 101.121+-1.379 ^ 91.907+-1.500 ^ definitely 1.1003x faster
* assembler/CPU.h:
(JSC::hasSensibleDoubleToInt):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
(JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::hasSensibleDoubleToInt): Deleted.
* ftl/FTLOutput.h:
* runtime/MathCommon.cpp:
(JSC::operationToInt32SensibleSlow):
* runtime/MathCommon.h:
2017-02-03 Joseph Pecoraro <pecoraro@apple.com>
Unreviewed rollout of r211486, r211629.
Original change is not ideal and is causing issues.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
2017-02-03 JF Bastien <jfbastien@apple.com>
OSR entry: delay outer-loop compilation when at inner-loop
https://bugs.webkit.org/show_bug.cgi?id=167149
Reviewed by Filip Pizlo.
r211224 and r211461 were reverted because they caused massive
kraken/ai-astar regressions. This patch instead does the
minimally-disruptive change to fix the original bug as described
below, but omits extra tuning and refactoring which I had
before. I'll commit tuning and refactoring separately, if this
sticks. This patch is therefore very minimal, and layers carefully
on top of the complex spaghetti-logic. The only change it makes is
that it uses triggers to indicate to outer loops that they should
compile, which fixes the immediate bug and seems roughly perf
neutral (maybe a small gain on kraken sometimes, other times a
small regression as would be expected from slightly compiling
later). As opposed to r211461 this patch doesn't unconditionally
unset the trigger because it prevents further DFG executions from
entering. It therefore makes the trigger a tri-state enum class:
don't trigger, compilation done, start compilation. Only "start
compilation" gets reset to "don't trigger". "Compilation done"
does not (unless there's a problem compiling, then it gets set
back to "don't trigger").
As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
compilation can be kicked off for an entry into an outer-loop,
while executing an inner-loop. This is desirable because often the
codegen from an inner-entry isn't as good as the codegen from an
outer-entry, but execution from an inner-loop is often pretty hot
and likely to kick off compilation. This approach provided nice
speedups on Kraken because we'd select to enter to the outer-loop
very reliably, which reduces variability (the inner-loop was
selected roughly 1/5 times from my unscientific measurements).
When compilation starts we take a snapshot of the JSValues at the
current execution state using OSR's recovery mechanism. These
values are passed to the compiler and are used as way to perform
type profiling, and could be used to observe cell types as well as
to perform predictions such as through constant propagation.
It's therefore desired to enter from the outer-loop when we can,
but we need to be executing from that location to capture the
right JSValues, otherwise we're confusing the compiler and giving
it inaccurate JSValues which can lead it to predict the wrong
things, leading to suboptimal code or recompilation due to
misprediction, or in super-corner-cases a crash.
DFG tier-up was added here:
https://bugs.webkit.org/show_bug.cgi?id=112838
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
2017-02-03 Saam Barati <sbarati@apple.com>
When OSR entering to the baseline JIT from the LLInt for a ProgramCodeBlock we can skip compiling a lot of the program
https://bugs.webkit.org/show_bug.cgi?id=167725
<rdar://problem/30339082>
Reviewed by Michael Saboff.
We often want to baseline compile ProgramCode once we hit a loop in the LLInt.
However, some programs execute a non-trivial amount of code before the loop.
This code can never be executed again because ProgramCodeBlocks never run more
than once. We're wasting time and memory by compiling code that is unreachable
from the OSR entry destination. This patch fixes this by only compiling code
that is reachable from the OSR entry destination.
This is a speedup on Kraken/ai-astar for devices with limited CPUs (I've been
testing on devices with 2 CPUs). On ai-astar, we were spending 50-100ms compiling
a huge ProgramCodeBlock in the baseline JIT where the majority of the code
would never execute. If this compilation was kicked off on the main thread,
then we'd be stalled for a long time. If it were started on the baseline JITs
background compilation thread, we'd still waste 50-100ms in that thread, causing
all other baseline compilations to happen on the main thread.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
* interpreter/Interpreter.h:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
(JSC::JIT::compile):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Plan::Plan):
(JSC::JITWorklist::Plan::compileNow):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
* jit/JITWorklist.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Completion.cpp:
(JSC::evaluate):
2017-02-03 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed typo fix after r211630.
* CMakeLists.txt:
2017-02-03 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Add initial implementation of resource usage overlay
https://bugs.webkit.org/show_bug.cgi?id=167731
Reviewed by Michael Catanzaro.
Also expose nextFireTime() for GTK+ port.
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::scheduleTimer):
(JSC::GCActivityCallback::cancelTimer):
* heap/GCActivityCallback.h:
2017-02-03 Csaba Osztrogonác <ossy@webkit.org>
[cmake] Unreviewed AArch64 buildfix after r211603.
https://bugs.webkit.org/show_bug.cgi?id=167714
* CMakeLists.txt:
2017-02-02 Andreas Kling <akling@apple.com>
[Mac] In-process memory pressure monitor for WebContent processes AKA websam
<https://webkit.org/b/167491>
<rdar://problem/30116072>
Reviewed by Antti Koivisto.
Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
WebCore-side memory footprint monitor.
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didExceedMaxLiveSize): Deleted.
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize): Deleted.
2017-02-02 Mark Lam <mark.lam@apple.com>
Add a SIGILL crash analyzer to make debugging SIGILLs easier.
https://bugs.webkit.org/show_bug.cgi?id=167714
<rdar://problem/30318237>
Not reviewed.
Build fix for CLOOP build.
* tools/VMInspector.cpp:
2017-02-02 Mark Lam <mark.lam@apple.com>
Add a SIGILL crash analyzer to make debugging SIGILLs easier.
https://bugs.webkit.org/show_bug.cgi?id=167714
<rdar://problem/30318237>
Reviewed by Filip Pizlo.
The current implementation is only for X86_64 and ARM64 on OS(DARWIN). The
analyzer is not enabled for all other ports.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* API/JSVirtualMachine.mm:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::illegalInstruction):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::illegalInstruction):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::illegalInstruction):
* assembler/X86Assembler.h:
(JSC::X86Assembler::illegalInstruction):
* heap/Heap.cpp:
(JSC::Heap::forEachCodeBlockIgnoringJITPlansImpl):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::forEachCodeBlockIgnoringJITPlans):
* runtime/Options.cpp:
(JSC::Options::isAvailable):
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
* tools/SigillCrashAnalyzer.cpp: Added.
(JSC::SignalContext::SignalContext):
(JSC::SignalContext::dump):
(JSC::handleCrash):
(JSC::initializeCrashHandler):
(JSC::ensureSigillCrashAnalyzer):
(JSC::SigillCrashAnalyzer::analyze):
(JSC::SigillCrashAnalyzer::dumpCodeBlock):
* tools/SigillCrashAnalyzer.h: Added.
* tools/VMInspector.cpp: Added.
(JSC::VMInspector::instance):
(JSC::VMInspector::add):
(JSC::VMInspector::remove):
(JSC::ensureIsSafeToLock):
* tools/VMInspector.h: Added.
(JSC::VMInspector::iterate):
2017-02-02 Chris Dumez <cdumez@apple.com>
{}.toString.call(crossOriginWindow) should return "[object Object]"
https://bugs.webkit.org/show_bug.cgi?id=167701
<rdar://problem/30330797>
Reviewed by Keith Miller.
Have JSProxy forward toStringName calls to its target so Window
can override it.
* runtime/JSProxy.cpp:
(JSC::JSProxy::toStringName):
* runtime/JSProxy.h:
2017-02-02 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r211571 and r211582.
https://bugs.webkit.org/show_bug.cgi?id=167751
This change caused API test WebKit1.MemoryPressureHandler to
fail with an assertion. (Requested by ryanhaddad on #webkit).
Reverted changesets:
"[Mac] In-process memory pressure monitor for WebContent
processes."
https://bugs.webkit.org/show_bug.cgi?id=167491
http://trac.webkit.org/changeset/211571
"Unreviewed attempt to fix the Windows build after r211571."
http://trac.webkit.org/changeset/211582
2017-02-02 Andreas Kling <akling@apple.com>
[Mac] In-process memory pressure monitor for WebContent processes.
<https://webkit.org/b/167491>
<rdar://problem/30116072>
Reviewed by Antti Koivisto.
Remove the sloppy "max live heap size" mechanism from JSC in favor of the new
WebCore-side memory footprint monitor.
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didExceedMaxLiveSize): Deleted.
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize): Deleted.
2017-02-02 Joseph Pecoraro <pecoraro@apple.com>
Removed unused m_errorHandlingModeReentry from Interpreter
https://bugs.webkit.org/show_bug.cgi?id=167726
Reviewed by Yusuke Suzuki.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::Interpreter):
* interpreter/Interpreter.h:
2017-02-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r211461.
https://bugs.webkit.org/show_bug.cgi?id=167721
Big regression on kraken (Requested by jfbastien on #webkit).
Reverted changeset:
"OSR entry: delay outer-loop compilation when at inner-loop"
https://bugs.webkit.org/show_bug.cgi?id=167149
http://trac.webkit.org/changeset/211461
2017-02-01 Keith Miller <keith_miller@apple.com>
Unreviewed, fix unintended change.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::displayName):
2017-02-01 Keith Miller <keith_miller@apple.com>
The sampling profile should have an option to sample from C frames.
https://bugs.webkit.org/show_bug.cgi?id=167614
Reviewed by Saam Barati.
We should be able to use the sampling profiler, at least
internally, to trace C calls. This patch only modifies the JSC
shell although it would be nice to add it to the Web Inspector in
a future patch.
* runtime/Options.h:
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::walk):
(JSC::FrameWalker::recordJSFrame):
(JSC::CFrameWalker::CFrameWalker):
(JSC::CFrameWalker::walk):
(JSC::CFrameWalker::isCFrame):
(JSC::CFrameWalker::advanceToParentFrame):
(JSC::CFrameWalker::frame):
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::StackFrame::displayName):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
2017-02-01 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Use guaranteed RunLoop instead of RunLoop::current for dispatching inspector GC event
https://bugs.webkit.org/show_bug.cgi?id=167683
<rdar://problem/30167791>
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
Use RunLoop::main instead of RunLoop::current which may go away.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
Ensure RunLoop::main is initialized when using JSC APIs.
2017-02-01 Yusuke Suzuki <utatane.tea@gmail.com>
ArityFixup should adjust SP first
https://bugs.webkit.org/show_bug.cgi?id=167239
Reviewed by Michael Saboff.
Arity fixup extends the stack and copy/fill the stack with
the values. At that time, we accidentally read/write stack
space below the stack pointer. As a result, we touch the area
of the stack space below the x64 red zone. These areas are unsafe.
OS may corrupt this space when constructing a signal stack.
The Linux kernel could not populate the pages for this space
and causes segmentation fault. This patch changes the stack
pointer before performing the arity fixup.
* jit/ThunkGenerators.cpp:
(JSC::arityFixupGenerator):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2017-01-31 Filip Pizlo <fpizlo@apple.com>
Make verifyEdge a RELEASE_ASSERT
<rdar://problem/30296879>
Rubber stamped by Saam Barati.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2017-01-31 JF Bastien <jfbastien@apple.com>
OSR entry: delay outer-loop compilation when at inner-loop
https://bugs.webkit.org/show_bug.cgi?id=167149
Reviewed by Filip Pizlo.
r211224 was reverted because it caused a massive kraken/ai-astar
regression. This patch instead does the minimally-disruptive
change to fix the original bug as described below, but omits extra
tuning and refactoring which I had before. I'll commit tuning and
refactoring separately, if this sticks. This patch is therefore
very minimal, and layers carefully on top of the complex
spaghetti-logic. The only change it makes is that it uses triggers
to indicate to outer loops that they should compile, which fixes
the immediate bug and seems roughly perf neutral (maybe a small
gain on kraken sometimes, other times a small regression as would
be expected from compiling later).
As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
compilation can be kicked off for an entry into an outer-loop,
while executing an inner-loop. This is desirable because often the
codegen from an inner-entry isn't as good as the codegen from an
outer-entry, but execution from an inner-loop is often pretty hot
and likely to kick off compilation. This approach provided nice
speedups on Kraken because we'd select to enter to the outer-loop
very reliably, which reduces variability (the inner-loop was
selected roughly 1/5 times from my unscientific measurements).
When compilation starts we take a snapshot of the JSValues at the
current execution state using OSR's recovery mechanism. These
values are passed to the compiler and are used as way to perform
type profiling, and could be used to observe cell types as well as
to perform predictions such as through constant propagation.
It's therefore desired to enter from the outer-loop when we can,
but we need to be executing from that location to capture the
right JSValues, otherwise we're confusing the compiler and giving
it inaccurate JSValues which can lead it to predict the wrong
things, leading to suboptimal code or recompilation due to
misprediction, or in super-corner-cases a crash.
These effects are pretty hard to measure: Fil points out that
marsalis-osr-entry really needs mustHandleValues (the JSValues
from the point of execution) because right now it just happens to
correctly guess int32. I tried removing mustHandleValues entirely
and saw no slowdowns, but our benchmarks probably aren't
sufficient to reliably find issues, sometimes because we happen to
have sufficient mitigations.
DFG tier-up was added here:
https://bugs.webkit.org/show_bug.cgi?id=112838
* dfg/DFGOperations.cpp:
2017-01-31 Filip Pizlo <fpizlo@apple.com>
The mutator should be able to perform increments of GC work
https://bugs.webkit.org/show_bug.cgi?id=167528
Reviewed by Keith Miller and Geoffrey Garen.
The cool thing about having a concurrent and parallel collector is that it's easy to also make
it incremental, because the load balancer can also hand over work to anyone (including the
mutator) and since the collector is running concurrently anyway, the mutator can usually rely
on the balancer having some spare work.
This change adds a classic work-based incremental mode to the GC. When you allocate K bytes,
you have to do Options::gcIncrementScale() * K "bytes" of draining. This is ammortized so that
it only happens in allocation slow paths.
On computers that have a lot of CPUs, this mode is not profitable and we set gcIncrementScale
to zero. On such computers, Riptide was already performing great because there was no way that
one mutator thread could outpace many GC threads. But on computers with fewer CPUs, there were
problems having to do with making the collector progress quickly enough so that the heap
doesn't grow too much. The stochastic scheduler actually made things worse, because it relies
a lot on the fact that the GC will simply be faster than the mutator anyway. The old scheduler
claimed to address the problem of GC pace, but it used a time-based scheduler, which is not as
precise at keeping pase as the new work-based incremental mode.
In theory, the work-based mode guarantees a bound on how much the heap can grow during a
collection just because each byte allocated means some number of bytes visited. We don't try
to create such a theoretical bound. We're just trying to give the collector an unfair advantage
in any race with the mutator.
Turning on incremental mode, the stochastic scheduler, and passive draining in combination with
each other is a huge splay-latency speed-up on my iPad. It's also a CDjs progression. It does
regress splay-throughput, but I think that's fine (the regression is 11%, the progression is
3x).
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::markToFixpoint):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::endMarking):
(JSC::Heap::finalize):
(JSC::Heap::didAllocate):
(JSC::Heap::visitCount):
(JSC::Heap::bytesVisited):
(JSC::Heap::forEachSlotVisitor):
(JSC::Heap::performIncrement):
(JSC::Heap::threadVisitCount): Deleted.
(JSC::Heap::threadBytesVisited): Deleted.
* heap/Heap.h:
* heap/MarkStack.cpp:
(JSC::MarkStackArray::transferTo):
* heap/MarkStack.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
(JSC::SlotVisitor::clearMarkStacks):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::noteLiveAuxiliaryCell):
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::performIncrementOfDraining):
(JSC::SlotVisitor::didReachTermination):
(JSC::SlotVisitor::hasWork):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::donateAll):
(JSC::SlotVisitor::correspondingGlobalStack):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::forEachMarkStack):
* heap/SpaceTimeMutatorScheduler.cpp:
(JSC::SpaceTimeMutatorScheduler::log):
* heap/StochasticSpaceTimeMutatorScheduler.cpp:
(JSC::StochasticSpaceTimeMutatorScheduler::log):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionHeapCapacity):
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
2017-01-31 Tomas Popela <tpopela@redhat.com>
Compilation error in JSArrayBufferView.h
https://bugs.webkit.org/show_bug.cgi?id=167642
Reviewed by Alex Christensen.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::vector):
2017-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Do not reject WebAssembly.compile() with Exception
https://bugs.webkit.org/show_bug.cgi?id=167585
Reviewed by Mark Lam.
We accidentally reject the promise with Exception instead of Exception::value()
for the result of WebAssembly::compile().
* wasm/JSWebAssembly.cpp:
(JSC::webAssemblyCompileFunc):
2017-01-30 Joseph Pecoraro <pecoraro@apple.com>
Implement PerformanceObserver
https://bugs.webkit.org/show_bug.cgi?id=167546
<rdar://problem/30247959>
Reviewed by Ryosuke Niwa.
* runtime/CommonIdentifiers.h:
2017-01-30 Matt Baker <mattbaker@apple.com>
Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
https://bugs.webkit.org/show_bug.cgi?id=165633
<rdar://problem/29738502>
Reviewed by Joseph Pecoraro.
This patch limits the memory used by the Inspector backend to store async
stack trace data.
Asynchronous stack traces are stored as a disjoint set of parent pointer
trees. Tree nodes represent asynchronous operations, and hold a copy of
the stack trace at the time the operation was scheduled. Each tree can
be regarded as a set of stack traces, stored as singly linked lists that
share part of their structure (specifically their tails). Traces belonging
to the same tree will at least share a common root. A stack trace begins
at a leaf node and follows the chain of parent pointers to the root of
of the tree. Leaf nodes always contain pending asynchronous calls.
When an asynchronous operation is scheduled with requestAnimationFrame,
setInterval, etc, a node is created containing the current call stack and
some bookkeeping data for the operation. An unique identifier comprised
of an operation type and callback identifier is mapped to the node. If
scheduling the callback was itself the result of an asynchronous call,
the node becomes a child of the node associated with that call, otherwise
it becomes the root of a new tree.
A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
start out as pending. After a callback for a pending node is dispatched
the node is marked as such, unless it is a repeating callback such as
setInterval, in which case it remains pending. Once a node is no longer
pending it is removed, as long as it has no children. Since nodes are
reference counted, it is a property of the stack trace tree that nodes
that are no longer pending and have no children pointing to them will be
automatically pruned from the tree.
If an async operation is canceled (e.g. cancelTimeout), the associated
node is marked as such. If the callback is not being dispatched at the
time, and has no children, it is removed.
Because async operations can be chained indefinitely, stack traces are
limited to a maximum depth. The depth of a stack trace is equal to the
sum of the depths of its nodes, with a node's depth equal to the number
of frames in its associated call stack. For any stack trace,
S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
A stack trace is truncated when it exceeds the maximum depth. Truncation
occurs on node boundaries, not call frames, consequently the maximum depth
is more of a target than a guarantee:
d = maximum stack trace depth
for all S, depth(S) ≤ d + depth(s𝑘)
Because nodes can belong to multiple stack traces, it may be necessary
to clone the tail of a stack trace being truncated to prevent other traces
from being effected.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/AsyncStackTrace.cpp: Added.
(Inspector::AsyncStackTrace::create):
(Inspector::AsyncStackTrace::AsyncStackTrace):
(Inspector::AsyncStackTrace::~AsyncStackTrace):
(Inspector::AsyncStackTrace::isPending):
(Inspector::AsyncStackTrace::isLocked):
(Inspector::AsyncStackTrace::willDispatchAsyncCall):
(Inspector::AsyncStackTrace::didDispatchAsyncCall):
(Inspector::AsyncStackTrace::didCancelAsyncCall):
(Inspector::AsyncStackTrace::buildInspectorObject):
(Inspector::AsyncStackTrace::truncate):
(Inspector::AsyncStackTrace::remove):
* inspector/AsyncStackTrace.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
(Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
(Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
(Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
(Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
(Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
(Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/protocol/Console.json:
2017-01-30 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r211345.
The LayoutTest for this change is failing an assertion.
Reverted changeset:
"Web Inspector: Need some limit on Async Call Stacks for async
loops (rAF loops)"
https://bugs.webkit.org/show_bug.cgi?id=165633
http://trac.webkit.org/changeset/211345
2017-01-28 Matt Baker <mattbaker@apple.com>
Web Inspector: Need some limit on Async Call Stacks for async loops (rAF loops)
https://bugs.webkit.org/show_bug.cgi?id=165633
<rdar://problem/29738502>
Reviewed by Joseph Pecoraro.
This patch limits the memory used by the Inspector backend to store async
stack trace data.
Asynchronous stack traces are stored as a disjoint set of parent pointer
trees. Tree nodes represent asynchronous operations, and hold a copy of
the stack trace at the time the operation was scheduled. Each tree can
be regarded as a set of stack traces, stored as singly linked lists that
share part of their structure (specifically their tails). Traces belonging
to the same tree will at least share a common root. A stack trace begins
at a leaf node and follows the chain of parent pointers to the root of
of the tree. Leaf nodes always contain pending asynchronous calls.
When an asynchronous operation is scheduled with requestAnimationFrame,
setInterval, etc, a node is created containing the current call stack and
some bookkeeping data for the operation. An unique identifier comprised
of an operation type and callback identifier is mapped to the node. If
scheduling the callback was itself the result of an asynchronous call,
the node becomes a child of the node associated with that call, otherwise
it becomes the root of a new tree.
A node is either `pending`, `active`, `dispatched`, or `canceled`. Nodes
start out as pending. After a callback for a pending node is dispatched
the node is marked as such, unless it is a repeating callback such as
setInterval, in which case it remains pending. Once a node is no longer
pending it is removed, as long as it has no children. Since nodes are
reference counted, it is a property of the stack trace tree that nodes
that are no longer pending and have no children pointing to them will be
automatically pruned from the tree.
If an async operation is canceled (e.g. cancelTimeout), the associated
node is marked as such. If the callback is not being dispatched at the
time, and has no children, it is removed.
Because async operations can be chained indefinitely, stack traces are
limited to a maximum depth. The depth of a stack trace is equal to the
sum of the depths of its nodes, with a node's depth equal to the number
of frames in its associated call stack. For any stack trace,
S = { s𝟶, s𝟷, …, s𝑘 }, with endpoints s𝟶, s𝑘
depth(S) = depth(s𝟶) + depth(s𝟷) + … + depth(s𝑘)
A stack trace is truncated when it exceeds the maximum depth. Truncation
occurs on node boundaries, not call frames, consequently the maximum depth
is more of a target than a guarantee:
d = maximum stack trace depth
for all S, depth(S) ≤ d + depth(s𝑘)
Because nodes can belong to multiple stack traces, it may be necessary
to clone the tail of a stack trace being truncated to prevent other traces
from being effected.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/AsyncStackTrace.cpp: Added.
(Inspector::AsyncStackTrace::create):
(Inspector::AsyncStackTrace::AsyncStackTrace):
(Inspector::AsyncStackTrace::~AsyncStackTrace):
(Inspector::AsyncStackTrace::isPending):
(Inspector::AsyncStackTrace::isLocked):
(Inspector::AsyncStackTrace::willDispatchAsyncCall):
(Inspector::AsyncStackTrace::didDispatchAsyncCall):
(Inspector::AsyncStackTrace::didCancelAsyncCall):
(Inspector::AsyncStackTrace::buildInspectorObject):
(Inspector::AsyncStackTrace::truncate):
(Inspector::AsyncStackTrace::remove):
* inspector/AsyncStackTrace.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
(Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
(Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
(Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
(Inspector::InspectorDebuggerAgent::buildAsyncStackTrace): Deleted.
(Inspector::InspectorDebuggerAgent::refAsyncCallData): Deleted.
(Inspector::InspectorDebuggerAgent::derefAsyncCallData): Deleted.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/protocol/Console.json:
2017-01-28 Joseph Pecoraro <pecoraro@apple.com>
Remote Inspector: Listing should be updated when a target gains or loses a debugger session
https://bugs.webkit.org/show_bug.cgi?id=167449
Reviewed by Brian Burg.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::setupFailed):
(Inspector::RemoteInspector::updateTargetListing):
(Inspector::RemoteInspector::receivedSetupMessage):
(Inspector::RemoteInspector::receivedDidCloseMessage):
(Inspector::RemoteInspector::receivedConnectionDiedMessage):
Whenever we add/remove a connection we should update the listing properties
for that target that corresponded to that connection. In this way group
updating active sessions, the target, and pushing listing together.
2017-01-27 Yusuke Suzuki <utatane.tea@gmail.com>
Lift template escape sequence restrictions in tagged templates
https://bugs.webkit.org/show_bug.cgi?id=166871
Reviewed by Saam Barati.
This patch implements stage 3 Lifting Template Literal Restriction[1].
Prior to this patch, template literal becomes syntax error if it contains
invalid escape sequences. But it is too restricted; Template literal
can have cooked and raw representations and only cooked representation
can escape sequences. So even if invalid escape sequences are included,
the raw representation can be valid.
Lifting Template Literal Restriction relaxes the above restriction.
When invalid escape sequence is included, if target template literals
are used as tagged templates, we make the result of the template including
the invalid escape sequence `undefined` instead of making it SyntaxError
immediately. It allows us to accept the templates including invalid
escape sequences in the raw representations in tagged templates.
On the other hand, the raw representation is only used in tagged templates.
So if invalid escape sequences are included in the usual template literals,
we just make it SyntaxError as before.
[1]: https://github.com/tc39/proposal-template-literal-revision
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/NodesCodegen.cpp:
(JSC::TemplateStringNode::emitBytecode):
(JSC::TemplateLiteralNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createTemplateString):
* parser/Lexer.cpp:
(JSC::Lexer<CharacterType>::parseUnicodeEscape):
(JSC::Lexer<T>::parseTemplateLiteral):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::scanTemplateString):
(JSC::Lexer<T>::scanTrailingTemplateString): Deleted.
* parser/Lexer.h:
* parser/NodeConstructors.h:
(JSC::TemplateStringNode::TemplateStringNode):
* parser/Nodes.h:
(JSC::TemplateStringNode::cooked):
(JSC::TemplateStringNode::raw):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentElement):
(JSC::Parser<LexerType>::parseTemplateString):
(JSC::Parser<LexerType>::parseTemplateLiteral):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createTemplateString):
* runtime/TemplateRegistry.cpp:
(JSC::TemplateRegistry::getTemplateObject):
* runtime/TemplateRegistryKey.h:
(JSC::TemplateRegistryKey::cookedStrings):
(JSC::TemplateRegistryKey::create):
(JSC::TemplateRegistryKey::TemplateRegistryKey):
* runtime/TemplateRegistryKeyTable.cpp:
(JSC::TemplateRegistryKeyTable::createKey):
* runtime/TemplateRegistryKeyTable.h:
2017-01-27 Saam Barati <sbarati@apple.com>
Make the CLI for the sampling profiler better for inlined call site indices
https://bugs.webkit.org/show_bug.cgi?id=167482
Reviewed by Mark Lam.
This patches changes the command line interface for the sampling
profiler to also dump the machine frame that the semantic code
origin is in if the semantic code origin is inlined. This helps
when doing performance work because it's helpful to know the
context that an inlined frame is in. Before, we used to just
say it was in the baseline JIT if it didn't have its own optimized
compile. Now, we can tell that its inlined into a DFG or FTL frame.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::buildSamples):
* runtime/Options.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::StackFrame::CodeLocation::hasCodeBlockHash):
(JSC::SamplingProfiler::StackFrame::CodeLocation::hasBytecodeIndex):
(JSC::SamplingProfiler::StackFrame::CodeLocation::hasExpressionInfo):
(JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
(JSC::SamplingProfiler::StackFrame::lineNumber):
(JSC::SamplingProfiler::StackFrame::columnNumber):
(JSC::SamplingProfiler::StackFrame::hasBytecodeIndex): Deleted.
(JSC::SamplingProfiler::StackFrame::hasCodeBlockHash): Deleted.
2017-01-27 Yusuke Suzuki <utatane.tea@gmail.com>
Extend create_hash_table to specify Intrinsic
https://bugs.webkit.org/show_bug.cgi?id=167505
Reviewed by Sam Weinig.
This patch extends create_hash_table to specify Intrinsic.
We can set Intrinsic in the static property table definition
in runtime/XXX.h.
And drop the adhoc code for String.fromCharCode in create_hash_table.
* create_hash_table:
* runtime/StringConstructor.cpp:
2017-01-27 Filip Pizlo <fpizlo@apple.com>
scanExternalRememberedSet needs to mergeIfNecessary
https://bugs.webkit.org/show_bug.cgi?id=167523
Reviewed by Keith Miller.
The protocol for opaque roots is that if you add to them outside of draining, then you need to call
mergeIfNecessary.
This means that every MarkingConstraint that adds opaque roots needs to mergeIfNecessary after.
scanExternalRememberedSet transitively calls addOpaqueRoot, is called from a MarkingConstraint, and
was missing a call to mergeIfNecessary. This fixes it.
* API/JSVirtualMachine.mm:
(scanExternalRememberedSet):
2017-01-27 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. Fix GTK+ debug build after r211247.
* heap/GCAssertions.h:
2017-01-26 Keith Miller <keith_miller@apple.com>
classInfo should take a VM so it is not materialized from the object on each call
https://bugs.webkit.org/show_bug.cgi?id=167424
Rubber Stamped by Michael Saboff.
Previously, classInfo() would get the VM from the target's
MarkedBlock. Most callers already have a VM on hand, so it is
wasteful to compute the VM from the marked block every time. This
patch refactors some of the most common callers of classInfo(),
jsDynamicCast and inherits to take a VM as well.
* API/JSCallbackConstructor.cpp:
(JSC::JSCallbackConstructor::finishCreation):
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::finishCreation):
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::asCallbackObject):
(JSC::JSCallbackObject<Parent>::finishCreation):
* API/JSObjectRef.cpp:
(JSObjectSetPrototype):
(classInfoPrivate):
(JSObjectGetPrivate):
(JSObjectSetPrivate):
(JSObjectGetPrivateProperty):
(JSObjectSetPrivateProperty):
(JSObjectDeletePrivateProperty):
* API/JSTypedArray.cpp:
(JSValueGetTypedArrayType):
(JSObjectMakeTypedArrayWithArrayBuffer):
(JSObjectMakeTypedArrayWithArrayBufferAndOffset):
(JSObjectGetTypedArrayBytesPtr):
(JSObjectGetTypedArrayLength):
(JSObjectGetTypedArrayByteLength):
(JSObjectGetTypedArrayByteOffset):
(JSObjectGetTypedArrayBuffer):
(JSObjectGetArrayBufferBytesPtr):
(JSObjectGetArrayBufferByteLength):
* API/JSValue.mm:
(isDate):
(isArray):
(valueToObjectWithoutCopy):
* API/JSValueRef.cpp:
(JSValueIsArray):
(JSValueIsDate):
(JSValueIsObjectOfClass):
* API/JSWeakObjectMapRefPrivate.cpp:
* API/JSWrapperMap.mm:
(tryUnwrapObjcObject):
* API/ObjCCallbackFunction.h:
* API/ObjCCallbackFunction.mm:
(tryUnwrapConstructor):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* bytecode/CallVariant.h:
(JSC::CallVariant::internalFunction):
(JSC::CallVariant::function):
(JSC::CallVariant::isClosureCall):
(JSC::CallVariant::executable):
(JSC::CallVariant::functionExecutable):
(JSC::CallVariant::nativeExecutable):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::replacement):
(JSC::CodeBlock::computeCapabilityLevel):
(JSC::CodeBlock::nameForRegister):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
* bytecode/ObjectPropertyCondition.cpp:
(JSC::ObjectPropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
* bytecode/ObjectPropertyCondition.h:
(JSC::ObjectPropertyCondition::isValidValueForPresence):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::isValidValueForAttributes):
(JSC::PropertyCondition::isValidValueForPresence):
(JSC::PropertyCondition::attemptToMakeEquivalenceWithoutBarrier):
* bytecode/PropertyCondition.h:
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromCell):
* debugger/Debugger.cpp:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::functionName):
(JSC::DebuggerCallFrame::scope):
(JSC::DebuggerCallFrame::type):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::name):
(JSC::DebuggerScope::location):
* dfg/DFGAbstractInterpreter.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::AbstractInterpreter):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::planLoad):
(JSC::DFG::ByteCodeParser::checkPresenceLike):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupMakeRope):
* dfg/DFGFrozenValue.h:
(JSC::DFG::FrozenValue::FrozenValue):
(JSC::DFG::FrozenValue::dynamicCast):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::tryGetConstantClosureVar):
(JSC::DFG::Graph::tryGetFoldableView):
(JSC::DFG::Graph::getRegExpPrototypeProperty):
(JSC::DFG::Graph::isStringPrototypeMethodSane):
(JSC::DFG::Graph::canOptimizeStringObjectAccess):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::tryGetStringImpl):
(JSC::DFG::LazyJSValue::tryGetString):
* dfg/DFGLazyJSValue.h:
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToPutStructureHint):
* dfg/DFGNode.h:
(JSC::DFG::Node::dynamicCastConstant):
(JSC::DFG::Node::castConstant):
* dfg/DFGOperations.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIn):
(JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileIn):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/CodeBlockSet.h:
* heap/GCAssertions.h:
* heap/Heap.cpp:
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::protectedObjectTypeCounts):
(JSC::Heap::objectTypeCounts):
(JSC::Heap::deleteUnmarkedCompiledCode):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json):
* heap/SlotVisitor.cpp:
(JSC::validate):
* inspector/InjectedScriptHost.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::finishCreation):
(Inspector::JSInjectedScriptHost::isHTMLAllCollection):
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::functionDetails):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::proxyTargetValue):
(Inspector::JSInjectedScriptHost::weakMapSize):
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::weakSetSize):
(Inspector::JSInjectedScriptHost::weakSetEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
(Inspector::jsInjectedScriptHostPrototypeFunctionInternalConstructorName):
(Inspector::jsInjectedScriptHostPrototypeFunctionIsHTMLAllCollection):
(Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
(Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
(Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
(Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
(Inspector::jsInjectedScriptHostPrototypeFunctionFunctionDetails):
(Inspector::jsInjectedScriptHostPrototypeFunctionGetInternalProperties):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::finishCreation):
(Inspector::toJSJavaScriptCallFrame): Deleted.
* inspector/JSJavaScriptCallFrame.h:
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSJavaScriptCallFramePrototype::finishCreation):
(Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
(Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
(Inspector::jsJavaScriptCallFrameAttributeCaller):
(Inspector::jsJavaScriptCallFrameAttributeSourceID):
(Inspector::jsJavaScriptCallFrameAttributeLine):
(Inspector::jsJavaScriptCallFrameAttributeColumn):
(Inspector::jsJavaScriptCallFrameAttributeFunctionName):
(Inspector::jsJavaScriptCallFrameAttributeScopeChain):
(Inspector::jsJavaScriptCallFrameAttributeThisObject):
(Inspector::jsJavaScriptCallFrameAttributeType):
(Inspector::jsJavaScriptCallFrameIsTailDeleted):
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::getFirstArgumentAsString):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::getPreview):
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
(JSC::Interpreter::unwind):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
(JSC::Interpreter::execute):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::update):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readFrame):
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::Frame::calleeSaveRegisters):
* jit/JITCode.cpp:
(JSC::JITCode::execute):
* jit/JITOperations.cpp:
(JSC::operationNewFunctionCommon):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* jsc.cpp:
(WTF::CustomGetter::customGetter):
(WTF::RuntimeArray::finishCreation):
(WTF::RuntimeArray::lengthGetter):
(WTF::DOMJITGetter::customGetter):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
(WTF::DOMJITGetterComplex::functionEnableException):
(WTF::DOMJITGetterComplex::customGetter):
(WTF::DOMJITFunctionObject::safeFunction):
(functionDescribeArray):
(functionCreateElement):
(functionGetElement):
(functionSetElementRoot):
(functionGetHiddenValue):
(functionSetHiddenValue):
(functionSetImpureGetterDelegate):
(functionNoFTL):
(functionDollarEvalScript):
(functionDollarAgentBroadcast):
(functionTransferArrayBuffer):
(functionFindTypeForExpression):
(functionReturnTypeFor):
(functionHasBasicBlockExecuted):
(functionBasicBlockExecutionCount):
(functionEnsureArrayStorage):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::finishCreation):
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::transferTo):
* runtime/ArrayBuffer.h:
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
(JSC::arrayConstructorPrivateFuncIsArraySlow):
(JSC::arrayConstructorPrivateFuncIsArrayConstructor):
* runtime/ArrayConstructor.h:
(JSC::isArrayConstructor): Deleted.
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/AsyncFunctionPrototype.cpp:
(JSC::AsyncFunctionPrototype::finishCreation):
* runtime/AtomicsObject.cpp:
(JSC::AtomicsObject::finishCreation):
(JSC::atomicsFuncWait):
(JSC::atomicsFuncWake):
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::finishCreation):
* runtime/BooleanObject.h:
(JSC::asBooleanObject):
* runtime/BooleanPrototype.cpp:
(JSC::BooleanPrototype::finishCreation):
(JSC::booleanProtoFuncToString):
(JSC::booleanProtoFuncValueOf):
* runtime/ConsoleObject.cpp:
(JSC::ConsoleObject::finishCreation):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
* runtime/DateInstance.cpp:
(JSC::DateInstance::finishCreation):
* runtime/DateInstance.h:
(JSC::asDateInstance):
* runtime/DatePrototype.cpp:
(JSC::formateDateInstance):
(JSC::DatePrototype::finishCreation):
(JSC::dateProtoFuncToISOString):
(JSC::dateProtoFuncToLocaleString):
(JSC::dateProtoFuncToLocaleDateString):
(JSC::dateProtoFuncToLocaleTimeString):
(JSC::dateProtoFuncGetTime):
(JSC::dateProtoFuncGetFullYear):
(JSC::dateProtoFuncGetUTCFullYear):
(JSC::dateProtoFuncGetMonth):
(JSC::dateProtoFuncGetUTCMonth):
(JSC::dateProtoFuncGetDate):
(JSC::dateProtoFuncGetUTCDate):
(JSC::dateProtoFuncGetDay):
(JSC::dateProtoFuncGetUTCDay):
(JSC::dateProtoFuncGetHours):
(JSC::dateProtoFuncGetUTCHours):
(JSC::dateProtoFuncGetMinutes):
(JSC::dateProtoFuncGetUTCMinutes):
(JSC::dateProtoFuncGetSeconds):
(JSC::dateProtoFuncGetUTCSeconds):
(JSC::dateProtoFuncGetMilliSeconds):
(JSC::dateProtoFuncGetUTCMilliseconds):
(JSC::dateProtoFuncGetTimezoneOffset):
(JSC::dateProtoFuncSetTime):
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetYear):
(JSC::dateProtoFuncGetYear):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorPrototype.cpp:
(JSC::ErrorPrototype::finishCreation):
* runtime/ExceptionHelpers.cpp:
(JSC::isTerminatedExecutionException):
* runtime/ExceptionHelpers.h:
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
(JSC::ExecutableBase::dump):
(JSC::ExecutableBase::hashFor):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorPrototype.cpp:
(JSC::GeneratorPrototype::finishCreation):
* runtime/GetterSetter.h:
* runtime/InspectorInstrumentationObject.cpp:
(JSC::InspectorInstrumentationObject::finishCreation):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
(JSC::InternalFunction::createSubclassStructure):
* runtime/InternalFunction.h:
(JSC::asInternalFunction):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototypeGetterCompare):
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
* runtime/IteratorPrototype.cpp:
(JSC::IteratorPrototype::finishCreation):
* runtime/JSArray.h:
(JSC::asArray):
(JSC::isJSArray):
* runtime/JSArrayBuffer.h:
(JSC::toPossiblySharedArrayBuffer):
(JSC::toUnsharedArrayBuffer):
(JSC::JSArrayBuffer::toWrapped):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::arrayBufferFuncIsView):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSArrayBufferView.h:
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::toWrapped):
* runtime/JSBoundFunction.cpp:
(JSC::isBoundFunction):
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::finishCreation):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpForBacktrace):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::inherits):
(JSC::JSValue::classInfoOrNull):
* runtime/JSCallee.cpp:
(JSC::JSCallee::finishCreation):
* runtime/JSCell.cpp:
(JSC::JSCell::dumpToStream):
(JSC::JSCell::className):
(JSC::JSCell::isAnyWasmCallee):
* runtime/JSCell.h:
(JSC::jsCast):
(JSC::jsDynamicCast):
* runtime/JSCellInlines.h:
(JSC::JSCell::methodTable):
(JSC::JSCell::inherits):
(JSC::JSCell::classInfo):
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSCustomGetterSetterFunction::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
(JSC::dataViewProtoGetterBuffer):
(JSC::dataViewProtoGetterByteLength):
(JSC::dataViewProtoGetterByteOffset):
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
(JSC::JSFunction::allocateAndInitializeRareData):
(JSC::JSFunction::initializeRareData):
(JSC::RetrieveArgumentsFunctor::RetrieveArgumentsFunctor):
(JSC::RetrieveCallerFunctionFunctor::RetrieveCallerFunctionFunctor):
(JSC::RetrieveCallerFunctionFunctor::operator()):
(JSC::JSFunction::callerGetter):
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::getCalculatedDisplayName):
(JSC::JSFunction::reifyBoundNameIfNeeded):
* runtime/JSGenericTypedArrayView.h:
(JSC::toPossiblySharedNativeTypedView):
(JSC::toUnsharedNativeTypedView):
(JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGenericTypedArrayViewPrototypeInlines.h:
(JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
* runtime/JSGlobalObject.cpp:
(JSC::getTemplateObject):
(JSC::enqueueJob):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
* runtime/JSInternalPromiseDeferred.cpp:
(JSC::JSInternalPromiseDeferred::create):
* runtime/JSLexicalEnvironment.h:
(JSC::asActivation):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
(JSC::JSModuleLoader::evaluate):
(JSC::JSModuleLoader::getModuleNamespaceObject):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::moduleNamespaceObjectSymbolIterator):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::finishCreation):
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::finishCreation):
* runtime/JSONObject.cpp:
(JSC::JSONObject::finishCreation):
(JSC::unwrapBoxedPrimitive):
(JSC::Stringifier::Stringifier):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::className):
(JSC::JSObject::toStringName):
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::ensureInt32Slow):
(JSC::JSObject::ensureDoubleSlow):
(JSC::JSObject::ensureContiguousSlow):
(JSC::JSObject::ensureArrayStorageSlow):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::getOwnStaticPropertySlot):
(JSC::JSObject::findPropertyHashEntry):
(JSC::JSObject::getOwnNonIndexPropertyNames):
(JSC::JSObject::reifyAllStaticProperties):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/JSObject.h:
(JSC::JSObject::finishCreation):
(JSC::JSNonFinalObject::finishCreation):
(JSC::JSFinalObject::finishCreation):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::create):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::finishCreation):
(JSC::propertyNameIteratorFuncNext):
* runtime/JSScope.cpp:
(JSC::JSScope::symbolTable):
* runtime/JSScope.h:
* runtime/JSString.cpp:
(JSC::JSString::dumpToStream):
* runtime/JSStringIterator.cpp:
(JSC::JSStringIterator::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewPrivateFuncIsTypedArrayView):
(JSC::typedArrayViewPrivateFuncLength):
(JSC::typedArrayViewPrivateFuncGetOriginalConstructor):
(JSC::typedArrayViewProtoGetterFuncToStringTag):
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/LazyClassStructure.cpp:
(JSC::LazyClassStructure::Initializer::setConstructor):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
(JSC::MapIteratorPrototypeFuncNext):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
(JSC::mapProtoFuncValues):
(JSC::mapProtoFuncEntries):
(JSC::mapProtoFuncKeys):
(JSC::privateFuncMapIterator):
(JSC::privateFuncMapIteratorNext):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
(JSC::moduleLoaderPrototypeRequestedModules):
(JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
(JSC::moduleLoaderPrototypeResolve):
(JSC::moduleLoaderPrototypeFetch):
(JSC::moduleLoaderPrototypeInstantiate):
(JSC::moduleLoaderPrototypeGetModuleNamespaceObject):
(JSC::moduleLoaderPrototypeEvaluate):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor::finishCreation):
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/NumberObject.cpp:
(JSC::NumberObject::finishCreation):
* runtime/NumberPrototype.cpp:
(JSC::NumberPrototype::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::toStringName):
(JSC::ProxyObject::finishCreation):
* runtime/ReflectObject.cpp:
(JSC::ReflectObject::finishCreation):
(JSC::reflectObjectConstruct):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
(JSC::constructRegExp):
* runtime/RegExpConstructor.h:
(JSC::asRegExpConstructor):
(JSC::isRegExp):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::finishCreation):
* runtime/RegExpObject.h:
(JSC::asRegExpObject):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
(JSC::regExpProtoFuncTestFast):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncMatchFast):
(JSC::regExpProtoFuncCompile):
(JSC::regExpProtoGetterGlobal):
(JSC::regExpProtoGetterIgnoreCase):
(JSC::regExpProtoGetterMultiline):
(JSC::regExpProtoGetterSticky):
(JSC::regExpProtoGetterUnicode):
(JSC::regExpProtoGetterSource):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
(JSC::ScriptExecutable::newReplacementCodeBlockFor):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
(JSC::SetIteratorPrototypeFuncNext):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
(JSC::setProtoFuncValues):
(JSC::setProtoFuncEntries):
(JSC::privateFuncSetIterator):
(JSC::privateFuncSetIteratorNext):
* runtime/StackFrame.cpp:
(JSC::StackFrame::sourceURL):
(JSC::StackFrame::functionName):
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/StringObject.cpp:
(JSC::StringObject::finishCreation):
* runtime/StringObject.h:
(JSC::asStringObject):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncToString):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::setObjectToStringValue):
* runtime/Symbol.cpp:
(JSC::Symbol::finishCreation):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::finishCreation):
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::finishCreation):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
(JSC::symbolProtoFuncToString):
(JSC::symbolProtoFuncValueOf):
* runtime/TestRunnerUtils.cpp:
(JSC::getExecutableForFunction):
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::throwException):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/WeakMapConstructor.cpp:
(JSC::WeakMapConstructor::finishCreation):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
(JSC::getWeakMapData):
* runtime/WeakSetConstructor.cpp:
(JSC::WeakSetConstructor::finishCreation):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
(JSC::getWeakMapData):
* tools/JSDollarVMPrototype.cpp:
(JSC::codeBlockFromArg):
* wasm/JSWebAssembly.cpp:
(JSC::JSWebAssembly::finishCreation):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::getWasmBufferFromValue):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::grow):
(JSC::JSWebAssemblyMemory::finishCreation):
(JSC::JSWebAssemblyMemory::destroy):
(JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory): Deleted.
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::finishCreation):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::getMemory):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::webAssemblyModuleProtoCustomSections):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::getTable):
(JSC::webAssemblyTableProtoFuncSet):
2017-01-26 Mark Lam <mark.lam@apple.com>
Fix missing exception check in genericTypedArrayViewProtoFuncSet().
https://bugs.webkit.org/show_bug.cgi?id=166812
<rdar://problem/29916672>
Reviewed by Saam Barati.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
2017-01-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r211224.
https://bugs.webkit.org/show_bug.cgi?id=167479
"It was a Kraken performance regression" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"OSR entry: delay outer-loop compilation when at inner-loop"
https://bugs.webkit.org/show_bug.cgi?id=167149
http://trac.webkit.org/changeset/211224
2017-01-26 Saam Barati <sbarati@apple.com>
Harden how the compiler references GC objects
https://bugs.webkit.org/show_bug.cgi?id=167277
<rdar://problem/30179506>
Reviewed by Filip Pizlo.
Since r210971, the DFG/FTL will flash safepoints before
each phase. This means that there are more opportunities for
a GC to happen while the compiler is running. Because of this,
the compiler must keep track of all the heap pointers that are part
of the Graph data structure. To accomplish this, I've designed
a new type called RegisteredStructure that can only be constructed
after the Graph becomes aware of its underlying Structure*. I
designed this new type to have the type system in C++ help us catch
errors where we're not informing the graph/plan of a heap pointer.
I've made it a compile error to create an OpInfo with a pointer
T* where T inherits from HeapCell. This encourages an OpInfo
to be created with either a FrozenValue* or a RegisteredStructure.
I've added similar compile time assertions for TrustedImmPtr in DFG::SpeculativeJIT
and FTL::Output::constIntPtr. These static asserts don't save us from all bad
programs because there are ways to write code that's incorrect that compiles,
but the new types do help us ensure that the most obvious way of writing the
code is correct.
The reason this patch is so big is that I've strung RegisteredStructure and
RegisteredStructureSet through the entire DFG/FTL.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::determineLiveness):
* bytecode/StructureSet.cpp:
(JSC::StructureSet::filter): Deleted.
(JSC::StructureSet::filterArrayModes): Deleted.
(JSC::StructureSet::speculationFromStructures): Deleted.
(JSC::StructureSet::arrayModesFromStructures): Deleted.
(JSC::StructureSet::validateReferences): Deleted.
* bytecode/StructureSet.h:
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::filter):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::booleanResult):
(JSC::DFG::isToThisAnIdentity):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::setType):
(JSC::DFG::AbstractValue::mergeOSREntryValue):
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::changeStructure):
(JSC::DFG::AbstractValue::contains):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::observeTransition):
(JSC::DFG::AbstractValue::TransitionObserver::TransitionObserver):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::alreadyChecked):
* dfg/DFGArrayifySlowPathGenerator.h:
(JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
(JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator):
(JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator):
* dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
(JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
(JSC::DFG::ConstantFoldingPhase::addBaseCheck):
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::checkArray):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::tryGetConstantProperty):
(JSC::DFG::Graph::inferredValueForProperty):
(JSC::DFG::Graph::visitChildren):
(JSC::DFG::Graph::freeze):
(JSC::DFG::Graph::registerStructure):
(JSC::DFG::Graph::assertIsRegistered):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::registerStructure):
(JSC::DFG::Graph::addStructureSet):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::branchWeakStructure):
* dfg/DFGMultiGetByOffsetData.cpp:
(JSC::DFG::MultiGetByOffsetCase::dumpInContext):
* dfg/DFGMultiGetByOffsetData.h:
(JSC::DFG::MultiGetByOffsetCase::MultiGetByOffsetCase):
(JSC::DFG::MultiGetByOffsetCase::set):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToPutStructureHint):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToCheckStructure):
(JSC::DFG::Node::structureSet):
(JSC::DFG::Node::structure):
(JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
(JSC::DFG::Node::OpInfoWrapper::operator=):
(JSC::DFG::Node::OpInfoWrapper::asRegisteredStructure):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
* dfg/DFGRegisteredStructure.h: Added.
(JSC::DFG::RegisteredStructure::get):
(JSC::DFG::RegisteredStructure::operator->):
(JSC::DFG::RegisteredStructure::operator==):
(JSC::DFG::RegisteredStructure::operator!=):
(JSC::DFG::RegisteredStructure::operator bool):
(JSC::DFG::RegisteredStructure::RegisteredStructure):
(JSC::DFG::RegisteredStructure::createPrivate):
* dfg/DFGRegisteredStructureSet.cpp: Added.
(JSC::DFG::RegisteredStructureSet::filter):
(JSC::DFG::RegisteredStructureSet::filterArrayModes):
(JSC::DFG::RegisteredStructureSet::speculationFromStructures):
(JSC::DFG::RegisteredStructureSet::arrayModesFromStructures):
(JSC::DFG::RegisteredStructureSet::validateReferences):
* dfg/DFGRegisteredStructureSet.h: Added.
(JSC::DFG::RegisteredStructureSet::RegisteredStructureSet):
(JSC::DFG::RegisteredStructureSet::onlyStructure):
(JSC::DFG::RegisteredStructureSet::toStructureSet):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::emitGetCallee):
(JSC::DFG::SpeculativeJIT::silentFill):
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compileFromCharCode):
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::compileClampDoubleToByte):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileArithRounding):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileNewFunction):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
(JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
(JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileTypeOf):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
(JSC::DFG::SpeculativeJIT::compileNewTypedArray):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
(JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::TrustedImmPtr):
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::weakPointer):
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::operator MacroAssembler::TrustedImmPtr):
(JSC::DFG::SpeculativeJIT::TrustedImmPtr::asIntptr):
(JSC::DFG::SpeculativeJIT::callOperation):
(JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::assertIsRegistered):
(JSC::DFG::StructureAbstractValue::clobber):
(JSC::DFG::StructureAbstractValue::observeTransition):
(JSC::DFG::StructureAbstractValue::observeTransitions):
(JSC::DFG::StructureAbstractValue::add):
(JSC::DFG::StructureAbstractValue::merge):
(JSC::DFG::StructureAbstractValue::mergeNotTop):
(JSC::DFG::StructureAbstractValue::filter):
(JSC::DFG::StructureAbstractValue::filterSlow):
(JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
(JSC::DFG::StructureAbstractValue::contains):
(JSC::DFG::StructureAbstractValue::isSubsetOf):
(JSC::DFG::StructureAbstractValue::isSupersetOf):
(JSC::DFG::StructureAbstractValue::overlaps):
(JSC::DFG::StructureAbstractValue::isSubClassOf):
(JSC::DFG::StructureAbstractValue::dumpInContext):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::StructureAbstractValue):
(JSC::DFG::StructureAbstractValue::operator=):
(JSC::DFG::StructureAbstractValue::set):
(JSC::DFG::StructureAbstractValue::toStructureSet):
(JSC::DFG::StructureAbstractValue::at):
(JSC::DFG::StructureAbstractValue::operator[]):
(JSC::DFG::StructureAbstractValue::onlyStructure):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::StructureRegistrationPhase): Deleted.
(JSC::DFG::StructureRegistrationPhase::run): Deleted.
(JSC::DFG::StructureRegistrationPhase::registerStructures): Deleted.
(JSC::DFG::StructureRegistrationPhase::registerStructure): Deleted.
(JSC::DFG::StructureRegistrationPhase::assertAreRegistered): Deleted.
(JSC::DFG::StructureRegistrationPhase::assertIsRegistered): Deleted.
(JSC::DFG::performStructureRegistration): Deleted.
* dfg/DFGStructureRegistrationPhase.h:
* dfg/DFGTransition.cpp:
(JSC::DFG::Transition::dumpInContext):
* dfg/DFGTransition.h:
(JSC::DFG::Transition::Transition):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheckAccountingForArrayMode):
* dfg/DFGValidate.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure):
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileAllocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileReallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
(JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
(JSC::FTL::DFG::LowerDFGToB3::checkStructure):
(JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID):
(JSC::FTL::DFG::LowerDFGToB3::weakPointer):
(JSC::FTL::DFG::LowerDFGToB3::frozenPointer):
(JSC::FTL::DFG::LowerDFGToB3::weakStructureID):
(JSC::FTL::DFG::LowerDFGToB3::weakStructure):
(JSC::FTL::DFG::LowerDFGToB3::crash):
* ftl/FTLOutput.h:
(JSC::FTL::Output::weakPointer):
(JSC::FTL::Output::constIntPtr):
2017-01-26 JF Bastien <jfbastien@apple.com>
OSR entry: delay outer-loop compilation when at inner-loop
https://bugs.webkit.org/show_bug.cgi?id=167149
Reviewed by Filip Pizlo.
As of https://bugs.webkit.org/show_bug.cgi?id=155217 OSR
compilation can be kicked off for an entry into an outer-loop,
while executing an inner-loop. This is desirable because often the
codegen from an inner-entry isn't as good as the codegen from an
outer-entry, but execution from an inner-loop is often pretty hot
and likely to kick off compilation. This approach provided nice
speedups on Kraken because we'd select to enter to the outer-loop
very reliably, which reduces variability (the inner-loop was
selected roughly 1/5 times from my unscientific measurements).
When compilation starts we take a snapshot of the JSValues at the
current execution state using OSR's recovery mechanism. These
values are passed to the compiler and are used as way to perform
type profiling, and could be used to observe cell types as well as
to perform predictions such as through constant propagation.
It's therefore desired to enter from the outer-loop when we can,
but we need to be executing from that location to capture the
right JSValues, otherwise we're confusing the compiler and giving
it inaccurate JSValues which can lead it to predict the wrong
things, leading to suboptimal code or recompilation due to
misprediction, or in super-corner-cases a crash.
These effects are pretty hard to measure: Fil points out that
marsalis-osr-entry really needs mustHandleValues (the JSValues
from the point of execution) because right now it just happens to
correctly guess int32. I tried removing mustHandleValues entirely
and saw no slowdowns, but our benchmarks probably aren't
sufficient to reliably find issues, sometimes because we happen to
have sufficient mitigations.
DFG tier-up was added here:
https://bugs.webkit.org/show_bug.cgi?id=112838
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSREntry.h:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTierUpEntryTrigger.h: Copied from Source/JavaScriptCore/ftl/FTLOSREntry.h.
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
(JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* ftl/FTLOSREntry.h:
* jit/JITOperations.cpp:
2017-01-25 Saam Barati <sbarati@apple.com>
WebAssembly JS API: coerce return values from imports
https://bugs.webkit.org/show_bug.cgi?id=165480
<rdar://problem/29760318>
Reviewed by Yusuke Suzuki.
This patch does proper coercion for all possible
JSValue return types from an imported function.
It also adds the spec-compliant code to throw an exception
when calling an import that has an i64 parameter or return
value.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitJumpIfException):
* jit/AssemblyHelpers.h:
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
2017-01-25 Filip Pizlo <fpizlo@apple.com>
jsc.cpp should have the $.agent stuff for testing SAB
https://bugs.webkit.org/show_bug.cgi?id=167431
Reviewed by Saam Barati.
This adds some stuff that the SAB branch of test262 needs. None of this is exposed except for our
own tests and the SAB branch of test262. We now pass all of the Atomics tests in the SAB branch
of test262.
* jsc.cpp:
(Message::releaseContents):
(Message::index):
(GlobalObject::finishCreation):
(GlobalObject::addFunction):
(Message::Message):
(Message::~Message):
(Worker::Worker):
(Worker::~Worker):
(Worker::send):
(Worker::receive):
(Worker::current):
(Worker::currentWorker):
(Workers::Workers):
(Workers::~Workers):
(Workers::broadcast):
(Workers::report):
(Workers::tryGetReport):
(Workers::getReport):
(Workers::singleton):
(functionDollarCreateRealm):
(functionDollarDetachArrayBuffer):
(functionDollarEvalScript):
(functionDollarAgentStart):
(functionDollarAgentReceiveBroadcast):
(functionDollarAgentReport):
(functionDollarAgentSleep):
(functionDollarAgentBroadcast):
(functionDollarAgentGetReport):
(functionWaitForReport):
(checkException):
(runWithScripts):
(runJSC):
(jscmain):
* runtime/JSArrayBuffer.h:
2017-01-25 Filip Pizlo <fpizlo@apple.com>
ARM/ARM64 stress/atomics-store-return.js fails
<rdar://problem/30192652>
Reviewed by Michael Saboff.
The problem was relying on double->int casts for anything. We need to use toInt32().
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncCompareExchange):
(JSC::atomicsFuncExchange):
(JSC::atomicsFuncStore):
2017-01-25 Ryosuke Niwa <rniwa@webkit.org>
collectMatchingElementsInFlatTree should not find elements inside an user agent shadow tree
https://bugs.webkit.org/show_bug.cgi?id=167409
Reviewed by Antti Koivisto.
Added matchingElementInFlatTree as a common identifier since it's required in the bindings code.
* runtime/CommonIdentifiers.h:
2017-01-24 Joseph Pecoraro <pecoraro@apple.com>
Fold USER_TIMING into WEB_TIMING and make it a RuntimeEnabledFeature
https://bugs.webkit.org/show_bug.cgi?id=167394
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
* runtime/CommonIdentifiers.h:
2017-01-24 Filip Pizlo <fpizlo@apple.com>
Atomics.store should return the int-converted value according to toInteger
https://bugs.webkit.org/show_bug.cgi?id=167399
Reviewed by Saam Barati.
I keep getting this wrong, but I think I've finally done it right. What we want is for
Atomics.store to return the value it was passed after toInteger, which doesn't clip the value to
any kind of range. It does get truncated to double.
This changes the code to pass those "integers" as doubles. It doesn't matter that this is slow,
since all of these code paths are slow due to their need to check everything. We'll take care of
that by making them intrinsic later.
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncAdd):
(JSC::atomicsFuncAnd):
(JSC::atomicsFuncCompareExchange):
(JSC::atomicsFuncExchange):
(JSC::atomicsFuncLoad):
(JSC::atomicsFuncOr):
(JSC::atomicsFuncStore):
(JSC::atomicsFuncSub):
(JSC::atomicsFuncXor):
2017-01-24 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Optimize Number#toString with Int52
https://bugs.webkit.org/show_bug.cgi?id=167303
Reviewed by Sam Weinig.
In kraken crypto-sha256-iterative, we frequently call Number.prototype.toString with
Int52. In that case, toString handles it in the generic double path. But we should
have a fast path for this since it can be represented in int64_t.
The stanford-crypto-sha256-iterative shows 1.6% performance improvement (on Linux machine hanayamata).
Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
milliseconds.
baseline patched
stanford-crypto-sha256-iterative 32.853+-0.075 ^ 32.325+-0.055 ^ definitely 1.0163x faster
* runtime/JSCJSValue.h:
* runtime/NumberPrototype.cpp:
(JSC::int52ToStringWithRadix):
(JSC::toStringWithRadix):
2017-01-24 Michael Saboff <msaboff@apple.com>
InferredTypeTable entry manipulation is not TOCTOU race safe
https://bugs.webkit.org/show_bug.cgi?id=167344
Reviewed by Filip Pizlo.
Made the accesses to table values safe from Time of Check,
Time of Use races with local temporary values.
Fixed point that we set an entry in the table to access the
current table entry instead of using the local entry. In that case,
we reload the now changed entry.
* runtime/InferredTypeTable.cpp:
(JSC::InferredTypeTable::visitChildren):
(JSC::InferredTypeTable::get):
(JSC::InferredTypeTable::willStoreValue):
(JSC::InferredTypeTable::makeTop):
2017-01-24 Filip Pizlo <fpizlo@apple.com>
Atomics.store should return the int-converted value, not the value that it stored
https://bugs.webkit.org/show_bug.cgi?id=167395
Reviewed by Saam Barati.
Previously the code was based around passing a lambda that operated over the native type of the
operation (so for example int8_t if we were doing things to Int8Arrays). But to support this
behavior of store, we need it to be able to control how it converts its result to JSValue and it
needs to see its argument as an int32_t. It turns out that it's easy for all of the functions in
AtomicsObject.cpp to also adopt this protocol since the conversion to JSValue is just jsNumber()
from the native type in those cases, and the conversion from int32_t is done for free in
std::atomic.
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncAdd):
(JSC::atomicsFuncAnd):
(JSC::atomicsFuncCompareExchange):
(JSC::atomicsFuncExchange):
(JSC::atomicsFuncLoad):
(JSC::atomicsFuncOr):
(JSC::atomicsFuncStore):
(JSC::atomicsFuncSub):
(JSC::atomicsFuncXor):
2017-01-24 Filip Pizlo <fpizlo@apple.com>
-0 is a valid array index and AtomicsObject should know this
https://bugs.webkit.org/show_bug.cgi?id=167386
Reviewed by Mark Lam.
* runtime/AtomicsObject.cpp: The bug title really says it all.
2017-01-24 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r211091.
https://bugs.webkit.org/show_bug.cgi?id=167384
introduces a subtle bug in InferredTypeTable, huge
Octane/deltablue regression (Requested by pizlo on #webkit).
Reverted changeset:
"InferredTypeTable entry manipulation is not TOCTOU race safe"
https://bugs.webkit.org/show_bug.cgi?id=167344
http://trac.webkit.org/changeset/211091
2017-01-24 Filip Pizlo <fpizlo@apple.com>
Enable the stochastic space-time scheduler on the larger multicores
https://bugs.webkit.org/show_bug.cgi?id=167382
<rdar://problem/30173375>
Rubber stamped by Saam Barati
This looks like a 1.3% JetStream speed-up thanks to a 28% splay-latency improvement. This new
scheduler seems to prevent all of the same pathologies as the old one prevented. But instead of
periodically suspending the mutator, this new one will only suspend after an iteration of the
constraint fixpoint. The length of that suspension length is random with the distribution being
governed by mutatorUtilization. Once resumed, the mutator gets to run unimpeded until draining
stalls.
I'm enabling it on platforms as I benchmark those platforms. It's possible that we will want to
use a different scheduler on different platforms.
* runtime/Options.cpp:
(JSC::overrideDefaults):
2017-01-24 Michael Saboff <msaboff@apple.com>
JSArray::tryCreateUninitialized should be called JSArray::tryCreateForInitializationPrivate
https://bugs.webkit.org/show_bug.cgi?id=167334
Rubber-stamped by Filip Pizlo.
* dfg/DFGOperations.cpp:
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateForInitializationPrivate):
(JSC::JSArray::fastSlice):
(JSC::JSArray::tryCreateUninitialized): Deleted.
* runtime/JSArray.h:
(JSC::JSArray::tryCreateForInitializationPrivate):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
(JSC::JSArray::tryCreateUninitialized): Deleted.
* runtime/RegExpMatchesArray.cpp:
(JSC::createEmptyRegExpMatchesArray):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
2017-01-23 Michael Saboff <msaboff@apple.com>
InferredTypeTable entry manipulation is not TOCTOU race safe
https://bugs.webkit.org/show_bug.cgi?id=167344
Reviewed by Filip Pizlo.
Made the accesses to table values safe from Time of Check,
Time of Use races with local temporary values.
* runtime/InferredTypeTable.cpp:
(JSC::InferredTypeTable::visitChildren):
(JSC::InferredTypeTable::get):
(JSC::InferredTypeTable::willStoreValue):
(JSC::InferredTypeTable::makeTop):
2017-01-23 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Provide a way to trigger a Garbage Collection
https://bugs.webkit.org/show_bug.cgi?id=167345
<rdar://problem/30102853>
Reviewed by Timothy Hatcher.
* inspector/protocol/Console.json:
* inspector/protocol/Debugger.json:
* inspector/protocol/Heap.json:
* inspector/protocol/Runtime.json:
These domains are supported by Worker backends. Label them.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.generate_domain):
* inspector/scripts/codegen/models.py:
(Protocol.parse_domain):
(Domain.__init__):
(Domains):
Parse "workerSupported" and include a line in BackendCommands.js
that calls to InspectorBackend.workerSupportedDomain().
* inspector/scripts/tests/generic/domain-availability.json: Added.
* inspector/scripts/tests/generic/expected/domain-availability.json-result: Added.
* inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Added.
* inspector/scripts/tests/generic/worker-supported-domains.json: Added.
Tests for domain "workerSupported" and "availability" properties.
2017-01-23 Saam Barati <sbarati@apple.com>
https://bugs.webkit.org/show_bug.cgi?id=167247
JSC: operationSpreadGeneric uses the wrong global object for the builtin function and slow_path_spread consults the wrong global object to prove if the iterator protocol is unobservable
<rdar://problem/30121809>
Reviewed by Filip Pizlo.
There were two bugs in the different tiers with respect to how
spread handled global objects.
The first was in the LLInt/baseline inside slow_path_spread:
We consulted the lexical global object instead of the thing we're
spreading's global object to determine if the array iterator protocol
is unobservable. This is wrong if the incoming array is from a different
global object. We must consult the incoming array's global object
to determine if it can be spread using the fast path.
The second was in operationSpreadGeneric in the DFG/FTL:
We were always using the incoming array's global object, even
when going down the slow path. This is wrong because we were
fetching the builtin iteration function helper from the incoming
array's global object, which meant that if the iterator function
were to throw an exception, it could leak objects from a different
global object. We should be executing the iterator function with
the lexical global object.
* dfg/DFGOperations.cpp:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionGlobalObjectForObject):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSArray.h:
* runtime/JSArrayInlines.h:
(JSC::JSArray::isIteratorProtocolFastAndNonObservable):
2017-01-22 Filip Pizlo <fpizlo@apple.com>
Land the stochastic space-time scheduler disabled
https://bugs.webkit.org/show_bug.cgi?id=167249
Reviewed by Saam Barati.
The space-time scheduler is pretty weird. It uses a periodic scheduler where the next period is
simply determined by an integer multiple of time since when the scheduler last snapped phase. It
snaps phase after constraint solving. Both the snapping of the phase after constraint solving and
the periodicity appear to be necessary for good performance. For example, if the space-time
scheduler decided that it was in the resume part of the phase just by virtue of having just
resumed, then it would be empirically worse than our scheduler which asks "what time is it?" to
decide whether it should be suspended or resumed even if it just suspended or resumed. I've spent
a lot of time wondering why these two features are essential, and I think I found a reason.
What's happening is that sometimes the GC has an overrun and its increment takes longer than it
should have. The current scheduler forgives overruns when constraint solving, which seems to
make sense because it cannot control whether constraint solving runs with the mutator resumed or
suspended. It has to be suspended currently. Snapping phase after constraint solving accomplishes
this. What's more surprising is how important it is to manage deadline misses during draining.
The relevant kind of deadline miss is when doing mutator-suspended draining to catch up to the
retreating wavefront. Deadline misses while doing this can happen systematically in some
workloads, like JetStream/hash-map and some test in Speedometer. It's because they have some
ginormous object and it takes like ~3ms+-1.5ms just to scan it. The space-time scheduler's use
of time to decide what to do saves the day here: after the deadline miss, the scheduler will
initially realize that it missed its deadline to resume the mutator. But as soon as it does this
it asks: "based on current time since phase snap, what should I do?". In the case of a deadline
miss, this question is essentially a weighted coin flip because of the high noise in the amount
of time that it takes to do things in the GC. If you overrun, you will probably overrun by
multiple milliseconds, which is enough that where you land in the space-time scheduler's timeline
is random. The likelihood that you land in the "resume mutator" part of the timeline has a
probability that is roughly the same as what the space-time scheduler calls mutator utilization.
This is a super weird property. I did not intend for it to have this property, but it appears to
be the most important property of this scheduler.
Based on this, it seems that the fact that the space-time scheduler could suspend the mutator
before draining runs out of work doesn't accomplish anything. As soon as you resume the
mutator, you have a retreating wavefront to worry about. But if the collector is happily scanning
things then it's almost certain that the collector will outpace the mutator. Also, anything that
the mutator asks us to revisit is deferred anyway.
In the past I've tried to replace the scheduler in one patch and this turned out to be annoying
because even a poorly conceived scheduler should be iterated on. This patch lands a new scheduler
called the StochasticSpaceTime scheduler. It replaces two of the known-good features of the old
scheduler: (1) it forgives constraint pauses and (2) after deadline overrun its choice is random,
weighted by the mutator utilization target. Unlike the old scheduler, this one will only suspend
the mutator when the draining terminates, but it may pause for any amount of time after an
iteration of constraint solving. It computes the targetPause by measuring constraint solving time
and multiplying by the pauseScale (0.3 by default). If smaller then minimumPause (0.3ms by
default), then it uses minimumPause instead. The stochastic scheduler will then definitely do at
least targetPause worth of suspended draining after the constraint solving iteration, and then
it will decide whether or not to do another one at random. The probability that it will choose to
resume is exactly mutatorUtilization, which is computed exactly as before. Therefore, the
probability of resumption starts at 0.7 and goes down as memory usage rises. Conversely, the
probability that we will stay suspended starts at 0.3 and goes up from there.
This new scheduler looks like it might be a 25% improvement on splay-latency. It also looks like
a small progression on hash-map. Hash-map is a great test of one of the worst cases of retreating
wavefront, since it is repeatedly storing to a ginormous array. This array is sure to take a
while to scan, and to complete, the GC must be smart enough to visit any new objects it finds
while scanning the array immediately after scanning that array. This new scheduler means that
after scanning the array, the probability that you will scan whatever you found in it starts at
0.3 and rises as the program allocates. It's sure to be 0.3, and not 0.3^k, because after the
wavefront stops advancing, the only object on the mark stack after a constraint iteration will be
that array. Since there is sure to be a 0.3ms or longer pause, the GC will be sure to start
visiting this object. The GC can then complete if it just allows enough time after this to scan
whatever new objects it finds. If scanning the array overruns the deadline (and it almost
certainly will) then the probability that the GC keeps the mutator suspended is simply
1 - mutatorUtilization.
This scheduler is disabled by default. You can enable it with
--useStochasticMutatorScheduler=true.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::markToFixpoint):
* heap/Heap.h:
* heap/MarkingConstraintSet.cpp:
(JSC::MarkingConstraintSet::didStartMarking):
(JSC::MarkingConstraintSet::executeConvergenceImpl):
(JSC::MarkingConstraintSet::resetStats): Deleted.
(JSC::MarkingConstraintSet::executeBootstrap): Deleted.
* heap/MarkingConstraintSet.h:
* heap/MutatorScheduler.cpp:
(JSC::MutatorScheduler::didReachTermination):
(JSC::MutatorScheduler::synchronousDrainingDidStall):
* heap/MutatorScheduler.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didReachTermination):
(JSC::SlotVisitor::drainFromShared):
* heap/StochasticSpaceTimeMutatorScheduler.cpp: Added.
(JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::Snapshot):
(JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::now):
(JSC::StochasticSpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
(JSC::StochasticSpaceTimeMutatorScheduler::StochasticSpaceTimeMutatorScheduler):
(JSC::StochasticSpaceTimeMutatorScheduler::~StochasticSpaceTimeMutatorScheduler):
(JSC::StochasticSpaceTimeMutatorScheduler::state):
(JSC::StochasticSpaceTimeMutatorScheduler::beginCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::didStop):
(JSC::StochasticSpaceTimeMutatorScheduler::willResume):
(JSC::StochasticSpaceTimeMutatorScheduler::didReachTermination):
(JSC::StochasticSpaceTimeMutatorScheduler::didExecuteConstraints):
(JSC::StochasticSpaceTimeMutatorScheduler::synchronousDrainingDidStall):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToStop):
(JSC::StochasticSpaceTimeMutatorScheduler::timeToResume):
(JSC::StochasticSpaceTimeMutatorScheduler::log):
(JSC::StochasticSpaceTimeMutatorScheduler::endCollection):
(JSC::StochasticSpaceTimeMutatorScheduler::setResumeTime):
(JSC::StochasticSpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
(JSC::StochasticSpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
(JSC::StochasticSpaceTimeMutatorScheduler::maxHeadroom):
(JSC::StochasticSpaceTimeMutatorScheduler::headroomFullness):
(JSC::StochasticSpaceTimeMutatorScheduler::mutatorUtilization):
* heap/StochasticSpaceTimeMutatorScheduler.h: Added.
* runtime/Options.cpp:
(JSC::overrideDefaults):
* runtime/Options.h:
2017-01-23 Mark Lam <mark.lam@apple.com>
Added a comment to clarify an assertion.
Rubber-stamped by Filip Pizlo.
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
2017-01-23 Filip Pizlo <fpizlo@apple.com>
SharedArrayBuffer plus WebGL should not equal CRASH
https://bugs.webkit.org/show_bug.cgi?id=167329
Reviewed by Saam Barati.
DOM unwrapping methods should return null rather than crashing. The code expects an
unshared buffer, so we should return null when it's shared. The caller can then decide
if they like null or not.
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::toWrapped):
2017-01-23 Mark Lam <mark.lam@apple.com>
ObjCCallbackFunction::destroy() should not use jsCast().
https://bugs.webkit.org/show_bug.cgi?id=167322
Reviewed by Filip Pizlo.
Since r210829, it is no longer correct for object destructors to use jsCast().
Fixed ObjCCallbackFunction::destroy() to use a static_cast instead.
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunction::destroy):
2017-01-23 Michael Saboff <msaboff@apple.com>
IntlObject uses JSArray::tryCreateUninitialized in an unsafe way
https://bugs.webkit.org/show_bug.cgi?id=167288
Reviewed by Filip Pizlo.
Refactored the following "create" methods into a "tryCreate" method and a
"create" wrapper: JSArray::create(), Butterfly::create() and
createArrayButterfly().
Changed IntlObject.cpp to use JSArray::tryCreate() as it is simpler to use
by not requiring the caller to be GC savey. The performance benefits of
tryCreateUninitialized() are not needed by the IntlObject c++ code.
Did not add a new test as the bug caused LayoutTests/js/intl.html to fail
reliably with the JSC option values scribbleFreeCells=true,
collectContinuously=true and JSC_useGenerationalGC=false.
* runtime/Butterfly.h:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::tryCreate): Added.
(JSC::Butterfly::create):
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
(JSC::lookupSupportedLocales):
(JSC::intlObjectFuncGetCanonicalLocales):
* runtime/JSArray.h:
(JSC::createContiguousArrayButterfly): Deleted.
(JSC::tryCreateArrayButterfly): Added.
(JSC::createArrayButterfly):
(JSC::JSArray::tryCreate): Added.
(JSC::JSArray::create):
2017-01-23 Joseph Pecoraro <pecoraro@apple.com>
JavaScriptCore has a weak external symbol in it
https://bugs.webkit.org/show_bug.cgi?id=167282
Reviewed by Yusuke Suzuki.
* debugger/Debugger.cpp:
(JSC::Debugger::ProfilingClient::~ProfilingClient):
* debugger/Debugger.h:
Avoid possible weak external symbol.
2017-01-21 Chris Dumez <cdumez@apple.com>
JavaScript for-of does not work on a lot of collection types (e.g. HTMLCollection)
https://bugs.webkit.org/show_bug.cgi?id=167091
Reviewed by Darin Adler.
Update Array methods to throw a TypeError when (this === null || this === undefined)
instead of when (this == null). This is because (this == null) returns true for types
that masquerades as undefined (such as document.all) and this prevented use of the
Array API on such types. The specification only stays to use ToObject(), which throws
when the input is undefined or null.
The corresponding specification is at:
- https://www.ecma-international.org/ecma-262/7.0/index.html#sec-array.prototype.values
- https://www.ecma-international.org/ecma-262/7.0/index.html#sec-toobject
* builtins/ArrayPrototype.js:
(values):
(keys):
(entries):
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(sort):
(concatSlowPath):
(copyWithin):
2017-01-21 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] export JSC::importModule API for WebCore dynamic import
https://bugs.webkit.org/show_bug.cgi?id=167099
Reviewed by Darin Adler.
We newly expose JSC::importModule API. This can be used later
from WebCore to implement WebCore side dynamic import.
And JSC shell also uses this API.
And this patch also cleans up module loader a bit:
Dropping requestInstantiateAll.
* builtins/BuiltinNames.h:
* builtins/ModuleLoaderPrototype.js:
(requestLink):
(requestImportModule):
(requestInstantiateAll): Deleted.
(importModule): Deleted.
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
* runtime/Completion.cpp:
(JSC::importModule):
* runtime/Completion.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::requestImportModule):
* runtime/JSModuleLoader.h:
* runtime/ModuleLoaderPrototype.cpp:
2017-01-21 Yusuke Suzuki <utatane.tea@gmail.com>
dynamic import is ambiguous with import declaration at module code
https://bugs.webkit.org/show_bug.cgi?id=167098
Reviewed by Darin Adler.
This patch fixes two syntax issues related to dynamic import.
1. Fix member expression parsing with dynamic import results
We should not return import expression immediately after parsing
it in parseMemberExpression. This prohibits us to parse the following
code,
import("...").then(function () {
});
2. dynamic import with import declaration under the module context
Before this patch, we always attempt to parse IMPORT as import declaration
under the module context. It means that import call in the top level
expression statement fails to be parsed since the parser attempts to parse
it as import declaration.
import("...") // module top level statement.
In this patch, we check the condition `[lookahead != (]` before starting
parsing import declaration. This allows us to put import call in the module
top level statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseModuleSourceElements):
(JSC::Parser<LexerType>::parseMemberExpression):
2017-01-20 Joseph Pecoraro <pecoraro@apple.com>
Remove outdated ENABLE(CSP_NEXT) build flag
https://bugs.webkit.org/show_bug.cgi?id=167252
Reviewed by Brent Fulgham.
* Configurations/FeatureDefines.xcconfig:
2017-01-20 Saam Barati <sbarati@apple.com>
We should flash a safepoint before each DFG/FTL phase
https://bugs.webkit.org/show_bug.cgi?id=167234
Reviewed by Filip Pizlo.
The recent GC changes caused us to regress Kraken because of a
longstanding issue that happened to be hit with higher frequency because
of a change in timing between when a particular GC was happening and
when a particular FTL compilation was happening. The regression is caused
by the GC was waiting for a large function to make it through the DFG portion
of an FTL compilation. This was taking 20ms-30ms and started happened during a
particular test with much higher frequency.
This means that anytime the GC waits for this compilation, the test ran at least
~20ms slower because the GC waits for the compiler threads the mutator is stopped.
It's good that we have such an easily reproducible case of this performance
issue because it will effect many real JS programs, especially ones with
large functions that get hot.
The most straight forward solution to fix this is to flash a safepoint before
each phase, allowing the GC to suspend the compiler if needed. In my testing,
this progresses Kraken in the browser, and doesn't regress anything else. This
solution also makes the most sense. I did some analysis on the compilation time
of this function that took ~20-30ms to pass through the DFG phases, and
the phase times were mostly evenly distributed. Some took longer than others,
but no phase was longer than 3ms. Most were in the 0.25ms to 1.5ms range.
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGSafepoint.cpp:
(JSC::DFG::Safepoint::begin):
* runtime/Options.h:
2017-01-20 Skachkov Oleksandr <gskachkov@gmail.com>
Super property access in base class constructor doesn't work
https://bugs.webkit.org/show_bug.cgi?id=166665
Reviewed by Ryosuke Niwa.
Allow to use super inside of the constructor for classes
without parent class.
Parser checks if super used within the constructor and
add this information to function metedata, and later it is used
during byte code generation.
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::usesEval):
(JSC::Scope::fillParametersForSourceProviderCache):
(JSC::Scope::restoreFromSourceProviderCache):
(JSC::Parser::adjustSuperBindingForBaseConstructor):
* parser/SourceProviderCacheItem.h:
(JSC::SourceProviderCacheItem::SourceProviderCacheItem):
2017-01-19 Chris Dumez <cdumez@apple.com>
iterable<> should be enabled on WK1
https://bugs.webkit.org/show_bug.cgi?id=167221
<rdar://problem/30108531>
Reviewed by Youenn Fablet.
* runtime/CommonIdentifiers.h:
2017-01-19 Filip Pizlo <fpizlo@apple.com>
Structure::pin() needs to be called while holding a lock
https://bugs.webkit.org/show_bug.cgi?id=167220
Reviewed by Saam Barati.
Imagine this race: the mutator calls pin() and the collector calls visitChildren(),
on the same Structure at the same time. In trunk pin() does not require a lock to be
held and it doesn't grab any locks. Meanwhile visitChildren() grabs the lock, checks
if the structure is pinned, and if not, it removes it by overwriting with zero. Now
imagine how this plays out when pin() runs. Since pin() grabs no locks, it is
irrelevant that visitChildren() grabs any locks. So, visitChildren() might check if
the table is pinned before pin() pins it, and then clear the table after it was
already pinned.
The problem here is that pin() should be holding a lock. We could either make pin()
grab that lock by itself, or what this patch does is makes the caller grab the lock.
This is great because it means that sometimes we don't have to introduce any new
locking.
This fixes a materializePropertyTable() checkOffsetConsistency() crash that happens
very rarely, but I was able to get it to reproduce with run-webkit-tests and
aggressive GC settings.
* runtime/ConcurrentJSLock.h:
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::changePrototypeTransition):
(JSC::Structure::attributeChangeTransition):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::nonPropertyTransition):
(JSC::Structure::pin):
(JSC::Structure::pinForCaching):
(JSC::Structure::add):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::checkOffsetConsistency):
(JSC::Structure::add):
(JSC::Structure::addPropertyWithoutTransition):
2017-01-19 Filip Pizlo <fpizlo@apple.com>
The mutator needs to fire a barrier after memmoving stuff around in an object that the GC scans
https://bugs.webkit.org/show_bug.cgi?id=167208
Reviewed by Saam Barati.
It used to be that if you moved a value from one place to another in the same object
then there is no need for a barrier because the generational GC would have no need to
know that some old object still continues to refer to the same other old object.
But the concurrent GC might scan that object as the mutator moves pointers around in
it. If the ordering is right, this could mean that the collector never sees some of
those pointers. This can be fixed by adding a barrier.
This fixes the most obvious cases I found. There may be more and I'll continue to
audit. Most of the other memmove users seem to already use some kind of synchronization
to prevent this. For example, this can also be fixed by just holding the cell lock
around the memmove since we're dealing with indexing storage and the GC reads that
under the cell lock.
* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
2017-01-19 Myles C. Maxfield <mmaxfield@apple.com>
[Cocoa] Variation fonts are erroneously disabled on iOS
https://bugs.webkit.org/show_bug.cgi?id=167172
Reviewed by Simon Fraser.
OpenSource builders don't seem to understand sdk=embedded*.
* Configurations/FeatureDefines.xcconfig:
2017-01-19 Skachkov Oleksandr <gskachkov@gmail.com>
"this" missing after await in async arrow function
https://bugs.webkit.org/show_bug.cgi?id=166919
Reviewed by NOBODY Saam Barati.
This patch fixed issue in async arrow function. Issue appears because in arrow
function _this_ is loaded from arrow function virtual scope.
Async arrow function can be suspended and when resuming should be used _this_ from
virtual scope, to allow this we load _this_ from virtual scope before store it to
generator.generatorThis property
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
2017-01-18 Yusuke Suzuki <utatane.tea@gmail.com>
[B3] B3 strength reduction could encounter Value without owner in PureCSE
https://bugs.webkit.org/show_bug.cgi?id=167161
Reviewed by Filip Pizlo.
PureCSE relies on the fact that all the stored Values have owner member.
This assumption is broken when you execute specializeSelect in B3ReduceStrength phase.
It clears owner of Values which are in between Select and Check to clone them to then/else
blocks. If these cleared Values are already stored in PureCSE map, this map poses a Value
with nullptr owner in PureCSE.
This patch changes PureCSE to ignore stored Values tha have nullptr owner. This even means
that a client of PureCSE could deliberately null the owner if they wanted to signal the
Value should be ignored.
While PureCSE ignores chance for optimization if Value's owner is nullptr, in the current
strength reduction algorithm, this does not hurt optimization because CSE will be eventually
applied since the strength reduction phase want to reach fixed point. But even without
this iterations, our result itself is valid since PureCSE is allowed to be conservative.
* b3/B3PureCSE.cpp:
(JSC::B3::PureCSE::findMatch):
(JSC::B3::PureCSE::process):
* b3/testb3.cpp:
(JSC::B3::testCheckSelectAndCSE):
(JSC::B3::run):
2017-01-18 Filip Pizlo <fpizlo@apple.com>
JSSegmentedVariableObject and its subclasses should have a sane destruction story
https://bugs.webkit.org/show_bug.cgi?id=167193
Reviewed by Saam Barati.
Prior to this change, JSSegmentedVariableObjects' subclasses install finalizers that call
destroy. They did this in random ways, which sometimes resulted in
JSSegmentedVariableObject::~JSSegmentedVariableObject executing more than once (which worked
because of the way that ~SegmentedVector is written). Maybe this works now, but it's a disaster
waiting to happen.
Fortunately we can now just give those things their own Subspace and teach it its own protocol of
destruction. This change introduces JSSegmentedVariableObjectSubspace and stashes a m_classInfo
in JSSegmentedVariableObject. Now, subclasses of JSSegmentedVariableObject are destructible in
much the same way as JSDestructibleObject without having to be subclasses of
JSDestructibleObject.
* API/JSCallbackObject.cpp:
(JSC::JSCallbackObject<JSGlobalObject>::create):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(GlobalObject::create):
* runtime/JSGlobalLexicalEnvironment.h:
(JSC::JSGlobalLexicalEnvironment::create):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::create):
(JSC::JSGlobalObject::finishCreation):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::create): Deleted.
(JSC::JSGlobalObject::finishCreation): Deleted.
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::destroy):
(JSC::JSSegmentedVariableObject::JSSegmentedVariableObject):
(JSC::JSSegmentedVariableObject::~JSSegmentedVariableObject):
(JSC::JSSegmentedVariableObject::finishCreation):
* runtime/JSSegmentedVariableObject.h:
(JSC::JSSegmentedVariableObject::subspaceFor):
(JSC::JSSegmentedVariableObject::classInfo):
(JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): Deleted.
(JSC::JSSegmentedVariableObject::finishCreation): Deleted.
* runtime/JSSegmentedVariableObjectSubspace.cpp: Added.
(JSC::JSSegmentedVariableObjectSubspace::JSSegmentedVariableObjectSubspace):
(JSC::JSSegmentedVariableObjectSubspace::~JSSegmentedVariableObjectSubspace):
(JSC::JSSegmentedVariableObjectSubspace::finishSweep):
(JSC::JSSegmentedVariableObjectSubspace::destroy):
* runtime/JSSegmentedVariableObjectSubspace.h: Added.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* testRegExp.cpp:
(GlobalObject::create):
2017-01-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: console.table only works for the first 5 properties
https://bugs.webkit.org/show_bug.cgi?id=167175
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.wrapTable):
(InjectedScript.RemoteObject.createObjectPreviewForValue):
(InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
Pass through secondLevelKeys. Though the keys are themselves ignored, the
existence is a signal that we should send more than the first 5 properties.
2017-01-18 Antti Koivisto <antti@apple.com>
Only delete source provider caches on full collection
https://bugs.webkit.org/show_bug.cgi?id=167173
Reviewed by Andreas Kling.
They are currently often wiped and recreated during page loading due to eden collections.
It is not clear that tying the lifetime of these caches to gc makes sense at all but this
should at least help some.
* heap/Heap.cpp:
(JSC::Heap::deleteSourceProviderCaches):
2017-01-18 Filip Pizlo <fpizlo@apple.com>
JSObjectSetPrivate should not use jsCast<>
rdar://problem/30069096
Reviewed by Keith Miller.
* API/JSObjectRef.cpp:
(JSObjectSetPrivate):
2017-01-18 Brian Burg <bburg@apple.com>
Web Inspector: remove an unnecessary include in generated Objective-C Inspector protocol code
https://bugs.webkit.org/show_bug.cgi?id=167156
Rubber-stamped by Geoffrey Garen.
* inspector/scripts/codegen/objc_generator_templates.py:
This include of config.h doesn't make sense when using the code generator
outside of JavaScriptCore/WebKit. It is not necessary either, so remove it.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
Rebaseline test results.
2017-01-18 Csaba Osztrogonác <ossy@webkit.org>
Fix the JSCOnly build after r210844
https://bugs.webkit.org/show_bug.cgi?id=167155
Unreviewed buildfix.
* heap/EdenGCActivityCallback.cpp:
2017-01-16 Filip Pizlo <fpizlo@apple.com>
Make opaque root scanning truly constraint-based
https://bugs.webkit.org/show_bug.cgi?id=165760
Reviewed by Geoffrey Garen.
We have bugs when visitChildren() changes its mind about what opaque root to add, since
we don't have barriers on opaque roots. This supposedly once worked for generational GC,
and I started adding more barriers to support concurrent GC. But I think that the real
bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
participates in the fixpoint. I like to think of this as an *output* constraint, because it
is concerned with outgoing edges in the heap from the object that registered the constraint.
An *input* constraint is like what Weak<> does when deciding whether the thing it points to
should be live.
Whether or not an object has output constraints depends on its type. So, we want the GC to
have a feature where we rapidly call some function on all marked objects of some type.
It's easy to rapidly scan all marked objects in a MarkedBlock. So, we want to allocate all
objects that have output constraints in their own MarkedBlocks and we want to track the set
of MarkedBlocks with output constraints.
This patch makes it easy to have clients of JSC's internal C++ APIs create a Subspace - like
what we used to call MarkedSpace::Subspace but now it's in the JSC namespace - which is
a collection of objects that you can easily scan during GC from a MarkingConstraint. It's
now possible for internal C++ API clients to register their own MarkingConstraints. The DOM
now uses this to create two Subspaces (more on why two below) and it calls
JSCell::visitOutputConstraints() on all of the marked objects in those subspaces using a new
MarkingConstraint. That MarkingConstraint uses a new style of volatility, called
SeldomGreyed, which is like GreyedByExecution except it is opportunistically not executed
as roots in the hopes that their sole execution will be the snapshot-at-the-end. I also
converted the CodeBlock rescan constraint to SeldomGreyed, since that's also an output
constraint.
This patch also uses Subspace for something pretty obvious: knowing how to call the
destructor. Subspaces can specialize the sweep for their way of invoking destructors. We
have the following subspaces:
- auxiliary
- cell
- destructibleCell - for JSCell subclasses that have destructors and StructureIsImmortal
- stringSpace - inlines ~JSString into the sweep, making string allocation 7% faster
- destructibleObjectSpace - for JSDestructibleObject subclasses
And WebCore adds:
- outputConstraint - for JSDOMObjects that have a visitAdditionalChildren
- globalObjectOutputConstraint - for JSDOMGlobalObjects that have a visitAdditionalChildren,
since JSDOMGlobalObjects are not JSDestructibleObjects
The Subspace for a type is selected by saying JSC::subspaceFor<Type>(vm). This calls
Type::subspaceFor<Type>(vm). This allows cell classes to override subspaceFor<> and it
allows any subspaceFor<> implementation to query static flags in the type. This is how
JSCell::subspaceFor<> can select either cellSpace or destructibleCellSpace.
This patch is mostly about:
- Moving MarkedSpace::Subspace out of MarkedSpace and making it a nice class with a nice
API. Almost all of its functionality is just taken out of MarkedSpace.
- Converting users of the old API for allocating objects and getting MarkedAllocators, like
heap.allocatorForObjectWithoutDestructor() and its friends. That would now say
vm.cellSpace.allocatorFor().
Altogether, this means that we only have a small regression on Dromaeo. The regression is
due to the fact that we scan output constraints. Before the Subspace optimizations (see
r209766, which was rolled out in r209812), this regression on Dromaeo/jslib was 2x but after
the optimizations in this patch it's only 1.12x. Note that Dromaeo/jslib creats gigabytes of
DOM nodes. Compared to web pages, this is a very extreme synthetic microbenchmark. Still, we
like optimizing these because we don't want to presume what web pages will look like.
The use of Subspaces to specialize destructors happened not because it's super necessary but
because I wanted to introduce a single unified way of communicating to the GC how to treat
different types. Any Subspace feature that allowed us to collect some types together would
have to be mindful of the destructorness of objects. I could have turned this into a
liability where each Subspace has two subsubspaces - one for destructor objects and one for
non-destructor objects, which would have allowed me to keep the old sweep specialization
code. Just days prior, mlam wanted to do something that was hard because of that old sweep
specializer, so I decided to take the opportunity to fix the sweep specializer while also
making Subspace be the one true way of teaching the GC about types. To validate that this
actually does things, I added a JSStringSubspace and a test that shows that this is a 7%
string allocation progression.
In bug 167066, I'm getting rid of the rest of the code in JSC that would special-case for
JSDestructibleObject vs StructureIsImmortal by using the GC's DestructionMode. After that,
Subspace will be only mechanism by which JSC uses the GC to encode types.
Prior to this change, having multiple MarkedSpace::Subspaces would have been expensive
because they create a bunch of MarkedAllocators upfront. We now have the ability to create
MarkedAllocators lazily. We create them on the first allocation from that size class or when
a JIT asks for the MarkedAllocator. The concurrent JITs can ask for MarkedAllocators because
their creation is under a lock.
On my machine, this might be a 1.1% JetStream speed-up with 87% confidence and it might be
a 0.4% PLT3 slow-down with 92% confidence. Note that 0.4% on PLT3 is the level of systematic
error on PLT3 on my computer: I've seen definite 0.4% speed-ups and slow-downs that were not
confirmed by any bot. Let's see what the bots say.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::initialize):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileNewTypedArray):
(JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatorForSize):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
* heap/AllocatorAttributes.h:
(JSC::AllocatorAttributes::AllocatorAttributes):
* heap/ConstraintVolatility.h: Added.
(WTF::printInternal):
* heap/GCActivityCallback.cpp:
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markToFixpoint):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::bytesVisited):
(JSC::Heap::addCoreConstraints):
(JSC::Heap::addMarkingConstraint):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::preventCollection):
(JSC::Heap::allowCollection):
(JSC::Heap::setMutatorShouldBeFenced):
(JSC::Heap::buildConstraintSet): Deleted.
(JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
(JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
* heap/Heap.h:
(JSC::Heap::mutatorExecutionVersion):
(JSC::Heap::numOpaqueRoots):
(JSC::Heap::vm): Deleted.
(JSC::Heap::subspaceForObjectWithoutDestructor): Deleted.
(JSC::Heap::subspaceForObjectDestructor): Deleted.
(JSC::Heap::subspaceForAuxiliaryData): Deleted.
(JSC::Heap::allocatorForObjectWithoutDestructor): Deleted.
(JSC::Heap::allocatorForObjectWithDestructor): Deleted.
(JSC::Heap::allocatorForAuxiliaryData): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::vm):
(JSC::Heap::allocateWithDestructor): Deleted.
(JSC::Heap::allocateWithoutDestructor): Deleted.
(JSC::Heap::allocateObjectOfType): Deleted.
(JSC::Heap::subspaceForObjectOfType): Deleted.
(JSC::Heap::allocatorForObjectOfType): Deleted.
(JSC::Heap::allocateAuxiliary): Deleted.
(JSC::Heap::tryAllocateAuxiliary): Deleted.
(JSC::Heap::tryReallocateAuxiliary): Deleted.
(JSC::Heap::ascribeOwner): Deleted.
(JSC::Heap::writeBarrierOpaqueRoot): Deleted.
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::tryCreate):
(JSC::LargeAllocation::LargeAllocation):
(JSC::LargeAllocation::~LargeAllocation):
(JSC::LargeAllocation::sweep):
* heap/LargeAllocation.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::MarkedAllocator):
(JSC::MarkedAllocator::tryAllocateWithoutCollecting):
(JSC::MarkedAllocator::tryAllocateIn):
(JSC::MarkedAllocator::allocateSlowCaseImpl):
(JSC::MarkedAllocator::tryAllocateBlock):
(JSC::MarkedAllocator::shrink):
(JSC::MarkedAllocator::markedSpace):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::nextAllocatorInSubspace):
(JSC::MarkedAllocator::setNextAllocatorInSubspace):
(JSC::MarkedAllocator::subspace):
(JSC::MarkedAllocator::tryAllocate): Deleted.
(JSC::MarkedAllocator::allocate): Deleted.
(JSC::MarkedAllocator::forEachBlock): Deleted.
* heap/MarkedAllocatorInlines.h: Added.
(JSC::MarkedAllocator::tryAllocate):
(JSC::MarkedAllocator::allocate):
(JSC::MarkedAllocator::forEachBlock):
(JSC::MarkedAllocator::forEachNotEmptyBlock):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::subspace):
(JSC::MarkedBlock::Handle::sweep):
(JSC::MarkedBlock::Handle::specializedSweep): Deleted.
(JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode): Deleted.
(JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode): Deleted.
(JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated): Deleted.
(JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode): Deleted.
(JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::visitWeakSet):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
(JSC::MarkedBlock::heap):
(JSC::MarkedBlock::space):
(JSC::MarkedBlock::Handle::space):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
(JSC::MarkedBlock::Handle::sweepDestructionMode):
(JSC::MarkedBlock::Handle::emptyMode):
(JSC::MarkedBlock::Handle::scribbleMode):
(JSC::MarkedBlock::Handle::newlyAllocatedMode):
(JSC::MarkedBlock::Handle::marksMode):
(JSC::MarkedBlock::Handle::forEachMarkedCell):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::initializeSizeClassForStepSize):
(JSC::MarkedSpace::MarkedSpace):
(JSC::MarkedSpace::lastChanceToFinalize):
(JSC::MarkedSpace::addMarkedAllocator):
(JSC::MarkedSpace::allocate): Deleted.
(JSC::MarkedSpace::tryAllocate): Deleted.
(JSC::MarkedSpace::allocateLarge): Deleted.
(JSC::MarkedSpace::tryAllocateLarge): Deleted.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::heap):
(JSC::MarkedSpace::allocatorLock):
(JSC::MarkedSpace::subspaceForObjectsWithDestructor): Deleted.
(JSC::MarkedSpace::subspaceForObjectsWithoutDestructor): Deleted.
(JSC::MarkedSpace::subspaceForAuxiliaryData): Deleted.
(JSC::MarkedSpace::allocatorFor): Deleted.
(JSC::MarkedSpace::destructorAllocatorFor): Deleted.
(JSC::MarkedSpace::auxiliaryAllocatorFor): Deleted.
(JSC::MarkedSpace::allocateWithoutDestructor): Deleted.
(JSC::MarkedSpace::allocateWithDestructor): Deleted.
(JSC::MarkedSpace::allocateAuxiliary): Deleted.
(JSC::MarkedSpace::tryAllocateAuxiliary): Deleted.
(JSC::MarkedSpace::forEachSubspace): Deleted.
* heap/MarkingConstraint.cpp:
(JSC::MarkingConstraint::MarkingConstraint):
* heap/MarkingConstraint.h:
(JSC::MarkingConstraint::volatility):
* heap/MarkingConstraintSet.cpp:
(JSC::MarkingConstraintSet::resetStats):
(JSC::MarkingConstraintSet::add):
(JSC::MarkingConstraintSet::executeConvergenceImpl):
* heap/MarkingConstraintSet.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::visitAsConstraint):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::mergeIfNecessary):
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
* heap/SlotVisitor.h:
(JSC::SlotVisitor::setIgnoreNewOpaqueRoots):
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExternalMemoryVisited):
* heap/Subspace.cpp: Added.
(JSC::Subspace::Subspace):
(JSC::Subspace::~Subspace):
(JSC::Subspace::finishSweep):
(JSC::Subspace::destroy):
(JSC::Subspace::allocate):
(JSC::Subspace::tryAllocate):
(JSC::Subspace::allocatorForSlow):
(JSC::Subspace::allocateSlow):
(JSC::Subspace::tryAllocateSlow):
* heap/Subspace.h: Added.
(JSC::Subspace::tryAllocatorFor):
(JSC::Subspace::allocatorFor):
* heap/SubspaceInlines.h: Added.
(JSC::Subspace::forEachMarkedBlock):
(JSC::Subspace::forEachNotEmptyMarkedBlock):
(JSC::Subspace::forEachLargeAllocation):
(JSC::Subspace::forEachMarkedCell):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::specializedVisit):
* heap/WeakBlock.h:
* heap/WeakSet.h:
(JSC::WeakSet::visit):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
* jsc.cpp:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::createUninitialized):
(JSC::Butterfly::growArrayRight):
* runtime/ClassInfo.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createEmpty):
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::overrideThings):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
* runtime/HashMapImpl.h:
(JSC::HashMapBuffer::create):
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateUninitialized):
(JSC::JSArray::unshiftCountSlowCase):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
* runtime/JSCell.h:
(JSC::subspaceFor):
* runtime/JSCellInlines.h:
(JSC::JSCell::visitOutputConstraints):
(JSC::JSCell::subspaceFor):
(JSC::allocateCell):
* runtime/JSDestructibleObject.h:
(JSC::JSDestructibleObject::subspaceFor):
* runtime/JSDestructibleObjectSubspace.cpp: Added.
(JSC::JSDestructibleObjectSubspace::JSDestructibleObjectSubspace):
(JSC::JSDestructibleObjectSubspace::~JSDestructibleObjectSubspace):
(JSC::JSDestructibleObjectSubspace::finishSweep):
(JSC::JSDestructibleObjectSubspace::destroy):
* runtime/JSDestructibleObjectSubspace.h: Added.
* runtime/JSObject.h:
(JSC::JSObject::JSObject):
* runtime/JSObjectInlines.h:
* runtime/JSSegmentedVariableObject.h:
* runtime/JSString.h:
(JSC::JSString::subspaceFor):
* runtime/JSStringSubspace.cpp: Added.
(JSC::JSStringSubspace::JSStringSubspace):
(JSC::JSStringSubspace::~JSStringSubspace):
(JSC::JSStringSubspace::finishSweep):
(JSC::JSStringSubspace::destroy):
* runtime/JSStringSubspace.h: Added.
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-01-17 Michael Saboff <msaboff@apple.com>
Nested parenthesized regular expressions with non-zero minimum counts appear to hang and use lots of memory
https://bugs.webkit.org/show_bug.cgi?id=167125
Reviewed by Filip Pizlo.
Changed Yarr to handle nested parenthesized subexpressions where the minimum count is
not 0 directly in the Yarr interpreter. Previously we'd factor an expression like
(a|b)+ into (a|b)(a|b)* with special handling for captures. This factoring was done
using a deep copy that doubled the size of the resulting expresion for each nested
parenthesized subexpression. Now the Yarr interpreter can directly process a regexp
like (a|b){2,42}.
The parser will allow one level of nested, non-zero minimum, counted parenthesis using
the old copy method. After one level, it will generate parenthesis terms with a non-zero
minimum. Such an expression wasn't handled by the Yarr JIT before the change, so this
change isn't a performance regression.
Added a minimum count to the YarrPattern and ByteTerm classes, and then factored that
minimum into the interpreter. A non-zero minimum is only handled by the Yarr interpreter.
If the Yarr JIT see such a term, it punts back to the interpreter.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::backtrackPatternCharacter):
(JSC::Yarr::Interpreter::backtrackPatternCasedCharacter):
(JSC::Yarr::Interpreter::matchCharacterClass):
(JSC::Yarr::Interpreter::backtrackCharacterClass):
(JSC::Yarr::Interpreter::matchBackReference):
(JSC::Yarr::Interpreter::backtrackBackReference):
(JSC::Yarr::Interpreter::matchParenthesesOnceBegin):
(JSC::Yarr::Interpreter::matchParenthesesOnceEnd):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd):
(JSC::Yarr::Interpreter::matchParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::backtrackParenthesesTerminalBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::matchParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionBegin):
(JSC::Yarr::Interpreter::backtrackParentheticalAssertionEnd):
(JSC::Yarr::Interpreter::matchParentheses):
(JSC::Yarr::Interpreter::backtrackParentheses):
(JSC::Yarr::Interpreter::matchDisjunction):
(JSC::Yarr::ByteCompiler::atomPatternCharacter):
(JSC::Yarr::ByteCompiler::atomCharacterClass):
(JSC::Yarr::ByteCompiler::atomBackReference):
(JSC::Yarr::ByteCompiler::atomParentheticalAssertionEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd):
(JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd):
(JSC::Yarr::ByteCompiler::emitDisjunction):
* yarr/YarrInterpreter.h:
(JSC::Yarr::ByteTerm::ByteTerm):
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
(JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
(JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy):
(JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy):
(JSC::Yarr::YarrGenerator::generateCharacterClassFixed):
(JSC::Yarr::YarrGenerator::generateCharacterClassGreedy):
(JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy):
(JSC::Yarr::YarrGenerator::generateTerm):
(JSC::Yarr::YarrGenerator::backtrackTerm):
(JSC::Yarr::YarrGenerator::generate):
(JSC::Yarr::YarrGenerator::backtrack):
(JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::copyTerm):
(JSC::Yarr::YarrPatternConstructor::quantifyAtom):
(JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
(JSC::Yarr::YarrPattern::YarrPattern):
* yarr/YarrPattern.h:
(JSC::Yarr::PatternTerm::PatternTerm):
(JSC::Yarr::PatternTerm::quantify):
(JSC::Yarr::YarrPattern::reset):
2017-01-17 Joseph Pecoraro <pecoraro@apple.com>
ENABLE(USER_TIMING) Not Defined for Apple Windows or OS X Ports
https://bugs.webkit.org/show_bug.cgi?id=116551
<rdar://problem/13949830>
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2017-01-16 Filip Pizlo <fpizlo@apple.com>
JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
https://bugs.webkit.org/show_bug.cgi?id=167066
Reviewed by Keith Miller and Michael Saboff.
This reduces the size of JSCell::classInfo() by half and removes some checks that
this function previously had to do in case it was called from destructors.
I changed all of the destructors so that they don't call JSCell::classInfo() and I
added an assertion to JSCell::classInfo() to catch cases where someone called it
from a destructor accidentally.
This means that we only have one place in destruction that needs to know the class:
the sweeper's call to the destructor.
One of the trickiest outcomes of this is the need to support inherits() tests in
JSObjectGetPrivate(), when it is called from the destructor callback on the object
being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
on any dead-but-not-destructed object other than the one being destructed right
now. The purpose of the inherits() tests is to distinguish between different kinds
of CallbackObjects, which may have different kinds of base classes. I think that
this was always subtly wrong - for example, if the object being destructed is a
JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
but does not have an immortal Structure - so classInfo() is not valid. This fixes
the issue by having ~JSCallbackObject know its classInfo. It now stashes its
classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
that it's being used on a currently-destructing object.
That was the only really weird part of this patch. The rest is mostly removing
illegal uses of jsCast<> in destructors. There were a few other genuine uses of
classInfo() but they were in code that already knew how to get its classInfo()
using other means:
- You can still say structure()->classInfo(), and I use this form in code that
knows that its StructureIsImmortal.
- You can use this->classInfo() if it's overridden, like in subclasses of
JSDestructibleObject.
Rolling this back in because I think I fixed the crashes.
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::finalize):
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::~JSCallbackObject):
(JSC::JSCallbackObject<Parent>::init):
* API/JSObjectRef.cpp:
(classInfoPrivate):
(JSObjectGetPrivate):
(JSObjectSetPrivate):
* bytecode/EvalCodeBlock.cpp:
(JSC::EvalCodeBlock::destroy):
* bytecode/FunctionCodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy):
* bytecode/ModuleProgramCodeBlock.cpp:
(JSC::ModuleProgramCodeBlock::destroy):
* bytecode/ProgramCodeBlock.cpp:
(JSC::ProgramCodeBlock::destroy):
* bytecode/UnlinkedEvalCodeBlock.cpp:
(JSC::UnlinkedEvalCodeBlock::destroy):
* bytecode/UnlinkedFunctionCodeBlock.cpp:
(JSC::UnlinkedFunctionCodeBlock::destroy):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::destroy):
* bytecode/UnlinkedModuleProgramCodeBlock.cpp:
(JSC::UnlinkedModuleProgramCodeBlock::destroy):
* bytecode/UnlinkedProgramCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::destroy):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::destroy):
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
(JSC::JSCell::callDestructor):
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::destroy):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::destroy):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::destroy):
* runtime/JSSegmentedVariableObject.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::destroy):
* runtime/VM.h:
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::destroy):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::destroy):
* wasm/js/WebAssemblyToJSCallee.cpp:
(JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
(JSC::WebAssemblyToJSCallee::destroy):
2017-01-17 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out http://trac.webkit.org/changeset/210821
It was causing crashes.
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::finalize):
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::~JSCallbackObject):
(JSC::JSCallbackObject<Parent>::init):
* API/JSObjectRef.cpp:
(JSObjectGetPrivate):
(JSObjectSetPrivate):
(classInfoPrivate): Deleted.
* bytecode/EvalCodeBlock.cpp:
(JSC::EvalCodeBlock::destroy):
* bytecode/FunctionCodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy):
* bytecode/ModuleProgramCodeBlock.cpp:
(JSC::ModuleProgramCodeBlock::destroy):
* bytecode/ProgramCodeBlock.cpp:
(JSC::ProgramCodeBlock::destroy):
* bytecode/UnlinkedEvalCodeBlock.cpp:
(JSC::UnlinkedEvalCodeBlock::destroy):
* bytecode/UnlinkedFunctionCodeBlock.cpp:
(JSC::UnlinkedFunctionCodeBlock::destroy):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::destroy):
* bytecode/UnlinkedModuleProgramCodeBlock.cpp:
(JSC::UnlinkedModuleProgramCodeBlock::destroy):
* bytecode/UnlinkedProgramCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::destroy):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::destroy):
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
(JSC::JSCell::callDestructor):
* runtime/JSLock.h:
(JSC::JSLock::exclusiveThread):
(JSC::JSLock::ownerThread): Deleted.
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::destroy):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::destroy):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::destroy):
* runtime/JSSegmentedVariableObject.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::destroy):
* runtime/VM.h:
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::destroy):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::destroy):
* wasm/js/WebAssemblyToJSCallee.cpp:
(JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
(JSC::WebAssemblyToJSCallee::destroy):
2017-01-16 Filip Pizlo <fpizlo@apple.com>
JSCell::classInfo() shouldn't have a bunch of mitigations for being called during destruction
https://bugs.webkit.org/show_bug.cgi?id=167066
Reviewed by Keith Miller and Michael Saboff.
This reduces the size of JSCell::classInfo() by half and removes some checks that
this function previously had to do in case it was called from destructors.
I changed all of the destructors so that they don't call JSCell::classInfo() and I
added an assertion to JSCell::classInfo() to catch cases where someone called it
from a destructor accidentally.
This means that we only have one place in destruction that needs to know the class:
the sweeper's call to the destructor.
One of the trickiest outcomes of this is the need to support inherits() tests in
JSObjectGetPrivate(), when it is called from the destructor callback on the object
being destructed. JSObjectGetPrivate() is undefined behavior anyway if you use it
on any dead-but-not-destructed object other than the one being destructed right
now. The purpose of the inherits() tests is to distinguish between different kinds
of CallbackObjects, which may have different kinds of base classes. I think that
this was always subtly wrong - for example, if the object being destructed is a
JSGlobalObject then it's not a DestructibleObject, is not in a destructor block,
but does not have an immortal Structure - so classInfo() is not valid. This fixes
the issue by having ~JSCallbackObject know its classInfo. It now stashes its
classInfo in VM so that JSObjectGetPrivate can use that classInfo if it detects
that it's being used on a currently-destructing object.
That was the only really weird part of this patch. The rest is mostly removing
illegal uses of jsCast<> in destructors. There were a few other genuine uses of
classInfo() but they were in code that already knew how to get its classInfo()
using other means:
- You can still say structure()->classInfo(), and I use this form in code that
knows that its StructureIsImmortal.
- You can use this->classInfo() if it's overridden, like in subclasses of
JSDestructibleObject.
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::finalize):
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::~JSCallbackObject):
(JSC::JSCallbackObject<Parent>::init):
* API/JSObjectRef.cpp:
(classInfoPrivate):
(JSObjectGetPrivate):
(JSObjectSetPrivate):
* bytecode/EvalCodeBlock.cpp:
(JSC::EvalCodeBlock::destroy):
* bytecode/FunctionCodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy):
* bytecode/ModuleProgramCodeBlock.cpp:
(JSC::ModuleProgramCodeBlock::destroy):
* bytecode/ProgramCodeBlock.cpp:
(JSC::ProgramCodeBlock::destroy):
* bytecode/UnlinkedEvalCodeBlock.cpp:
(JSC::UnlinkedEvalCodeBlock::destroy):
* bytecode/UnlinkedFunctionCodeBlock.cpp:
(JSC::UnlinkedFunctionCodeBlock::destroy):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::destroy):
* bytecode/UnlinkedModuleProgramCodeBlock.cpp:
(JSC::UnlinkedModuleProgramCodeBlock::destroy):
* bytecode/UnlinkedProgramCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::destroy):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::lastChanceToFinalize):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::sweep):
* jit/JITThunks.cpp:
(JSC::JITThunks::finalize):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::destroy):
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
* runtime/JSCellInlines.h:
(JSC::JSCell::classInfo):
(JSC::JSCell::callDestructor):
* runtime/JSLock.h:
(JSC::JSLock::ownerThread):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::destroy):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::destroy):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::destroy):
* runtime/JSSegmentedVariableObject.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::destroy):
* runtime/VM.h:
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::destroy):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::destroy):
* wasm/js/WebAssemblyToJSCallee.cpp:
(JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
(JSC::WebAssemblyToJSCallee::destroy):
2017-01-16 Joseph Pecoraro <pecoraro@apple.com>
Remove the REQUEST_ANIMATION_FRAME flag
https://bugs.webkit.org/show_bug.cgi?id=156980
<rdar://problem/25906849>
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2017-01-14 Yusuke Suzuki <utatane.tea@gmail.com>
WebAssembly: Suppress warnings & errors in GCC
https://bugs.webkit.org/show_bug.cgi?id=167049
Reviewed by Sam Weinig.
* wasm/WasmFunctionParser.h:
Add missing { } after the switch. Ideally, it is not necessary.
But in GCC, it is required. Since this function is fairly large,
I think the code generated by this does not cause performance
regression.
* wasm/WasmPageCount.h:
UINT_MAX is defined in limits.h.
* wasm/generateWasmValidateInlinesHeader.py:
On the other hand, we use this suppress pragma here to solve the
same problem in wasm/WasmFunctionParser.h. Since the load function
is fairly small, the additional `return { };` may generate some
suboptimal code. See bug 150794 for more detail.
2017-01-14 Yusuke Suzuki <utatane.tea@gmail.com>
Reserve capacity for StringBuilder in unescape
https://bugs.webkit.org/show_bug.cgi?id=167008
Reviewed by Sam Weinig.
`unescape` function is frequently called in Kraken sha256-iterative.
This patch just reserves the capacity for the StringBuilder.
Currently, we select the length of the string for the reserved capacity.
It improves the performance 2.73%.
Benchmark report for Kraken on sakura-trick.
VMs tested:
"baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
"patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc
Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
milliseconds.
baseline patched
stanford-crypto-sha256-iterative 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
<arithmetic> 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncUnescape):
2017-01-13 Joseph Pecoraro <pecoraro@apple.com>
Remove ENABLE(DETAILS_ELEMENT) guards
https://bugs.webkit.org/show_bug.cgi?id=167042
Reviewed by Alex Christensen.
* Configurations/FeatureDefines.xcconfig:
2017-01-11 Darin Adler <darin@apple.com>
Remove PassRefPtr from more of "platform"
https://bugs.webkit.org/show_bug.cgi?id=166809
Reviewed by Sam Weinig.
* inspector/JSInjectedScriptHost.h:
(Inspector::JSInjectedScriptHost::impl): Simplified code since we don't need a
const_cast here any more.
* runtime/PrivateName.h:
(JSC::PrivateName::uid): Ditto.
2017-01-13 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r210735.
This change introduced LayoutTest and JSC test flakiness.
Reverted changeset:
"Reserve capacity for StringBuilder in unescape"
https://bugs.webkit.org/show_bug.cgi?id=167008
http://trac.webkit.org/changeset/210735
2017-01-13 Saam Barati <sbarati@apple.com>
Initialize the ArraySpecies watchpoint as Clear and transition to IsWatched once slice is called for the first time
https://bugs.webkit.org/show_bug.cgi?id=167017
<rdar://problem/30019309>
Reviewed by Keith Miller and Filip Pizlo.
This patch is to reverse the JSBench regression from r210695.
The new state diagram for the array species watchpoint is as
follows:
1. On GlobalObject construction, it starts life out as ClearWatchpoint.
2. When slice is called for the first time, we observe the state
of the world, and either transition it to IsWatched if we were able
to set up the object property conditions, or to IsInvalidated if we
were not.
3. The DFG compiler will now only lower slice as an intrinsic if
it observed the speciesWatchpoint.state() as IsWatched.
4. The IsWatched => IsInvalidated transition happens only when
one of the object property condition watchpoints fire.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* runtime/ArrayPrototype.cpp:
(JSC::speciesWatchpointIsValid):
(JSC::speciesConstructArray):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
(JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint):
(JSC::ArrayPrototype::initializeSpeciesWatchpoint): Deleted.
* runtime/ArrayPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
2017-01-13 Yusuke Suzuki <utatane.tea@gmail.com>
Reserve capacity for StringBuilder in unescape
https://bugs.webkit.org/show_bug.cgi?id=167008
Reviewed by Sam Weinig.
`unescape` function is frequently called in Kraken sha256-iterative.
This patch just reserves the capacity for the StringBuilder.
Currently, we select the length of the string for the reserved capacity.
It improves the performance 2.73%.
Benchmark report for Kraken on sakura-trick.
VMs tested:
"baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/untot/Release/bin/jsc
"patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/un/Release/bin/jsc
Collected 100 samples per benchmark/VM, with 100 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime()
function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in
milliseconds.
baseline patched
stanford-crypto-sha256-iterative 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
<arithmetic> 51.609+-0.672 50.237+-0.860 might be 1.0273x faster
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncUnescape):
2017-01-12 Saam Barati <sbarati@apple.com>
Add a slice intrinsic to the DFG/FTL
https://bugs.webkit.org/show_bug.cgi?id=166707
<rdar://problem/29913445>
Reviewed by Filip Pizlo.
The gist of this patch is to inline Array.prototype.slice
into the DFG/FTL. The implementation in the DFG-backend
and FTLLowerDFGToB3 is just a straight forward implementation
of what the C function is doing. The more interesting bits
of this patch are setting up the proper watchpoints and conditions
in the executing code to prove that its safe to skip all of the
observable JS actions that Array.prototype.slice normally does.
We perform the following proofs:
1. Array.prototype.constructor has not changed (via a watchpoint).
2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
3. The global object is not having a bad time.
4. The array that is being sliced has an original array structure.
5. Array.prototype/Object.prototype have not transitioned.
Conditions 1, 2, and 3 are strictly required.
4 is ensuring a couple things:
1. That a "constructor" property hasn't been added to the array
we're slicing since we're supposed to perform a Get(array, "constructor").
2. That we're not slicing an instance of a subclass of Array.
We could relax 4.1 in the future if we find other ways to test if
the incoming array hasn't changed the "constructor" property. We
would probably use TryGetById to do this.
I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
the total benchmark (the results are sometimes noisy).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
(JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
(JSC::FTL::DFG::LowerDFGToB3::storeStructure):
(JSC::FTL::DFG::LowerDFGToB3::allocateCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::allocateUninitializedContiguousJSArray):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::speciesWatchpointIsValid):
(JSC::speciesConstructArray):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
(JSC::ArrayPrototype::initializeSpeciesWatchpoint):
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
(JSC::speciesWatchpointsValid): Deleted.
(JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
* runtime/ArrayPrototype.h:
(JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
(): Deleted.
* runtime/Intrinsic.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arraySpeciesWatchpoint):
* runtime/Structure.h:
2017-01-12 Saam Barati <sbarati@apple.com>
Concurrent GC has a bug where we would detect a race but fail to rescan the object
https://bugs.webkit.org/show_bug.cgi?id=166960
<rdar://problem/29983526>
Reviewed by Filip Pizlo and Mark Lam.
We have code like this in JSC:
```
Butterfly* butterfly = allocateMoreOutOfLineStorage(vm, oldOutOfLineCapacity, newOutOfLineCapacity);
nukeStructureAndSetButterfly(vm, structureID, butterfly);
structure->setLastOffset(newLastOffset);
WTF::storeStoreFence();
setStructureIDDirectly(structureID);
```
Note that the collector could detect a race here, which sometimes
incorrectly caused us to not visit the object again.
Mutator Thread: M, Collector Thread: C, assuming sequential consistency via
proper barriers:
M: allocate new butterfly
M: Set nuked structure ID
M: Set butterfly (this does a barrier)
C: Start scanning O
C: load structure ID
C: See it's nuked and bail, (we used to rely on a write barrier to rescan).
We sometimes never rescanned here because we were calling
setStructureIDDirectly which doesn't do a write barrier.
(Note, the places that do this but call setStructure were
OK because setStructure will perform a write barrier.)
(This same issue also existed in places where the collector thread
detected races for Structure::m_offset, but places that changed
Structure::m_offset didn't perform a write barrier on the object
after changing its Structure's m_offset.)
To prevent such code from requiring every call site to perform
a write barrier on the object, I've changed the collector code
to keep a stack of cells to be revisited due to races. This stack
is then consulted when we do marking. Because such races are rare,
we have a single stack on Heap that is guarded by a lock.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::markToFixpoint):
(JSC::Heap::endMarking):
(JSC::Heap::buildConstraintSet):
(JSC::Heap::addToRaceMarkStack):
* heap/Heap.h:
(JSC::Heap::collectorSlotVisitor):
(JSC::Heap::mutatorMarkStack): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didRace):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::didRace):
(JSC::SlotVisitor::didNotRace): Deleted.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::didNotRace): Deleted.
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::visitButterflyImpl):
* runtime/JSObjectInlines.h:
(JSC::JSObject::prepareToPutDirectWithoutTransition):
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure):
2017-01-12 Chris Dumez <cdumez@apple.com>
Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
https://bugs.webkit.org/show_bug.cgi?id=166995
Reviewed by Jer Noble.
Add KEYBOARD_KEY_ATTRIBUTE / KEYBOARD_CODE_ATTRIBUTE to FeatureDefines.xcconfig
as some people are having trouble building without it.
* Configurations/FeatureDefines.xcconfig:
2017-01-12 Yusuke Suzuki <utatane.tea@gmail.com>
Implement InlineClassicScript
https://bugs.webkit.org/show_bug.cgi?id=166925
Reviewed by Ryosuke Niwa.
Add ScriptFetcher field for SourceOrigin.
* runtime/SourceOrigin.h:
(JSC::SourceOrigin::SourceOrigin):
(JSC::SourceOrigin::fetcher):
2017-01-11 Andreas Kling <akling@apple.com>
Crash when WebCore's GC heap grows way too large.
<https://webkit.org/b/166875>
<rdar://problem/27896585>
Reviewed by Mark Lam.
Add a simple API to JSC::Heap that allows setting a hard limit on the amount
of live bytes. If this is exceeded, we crash with a recognizable signature.
By default there is no limit.
* heap/Heap.cpp:
(JSC::Heap::didExceedMaxLiveSize):
(JSC::Heap::updateAllocationLimits):
* heap/Heap.h:
(JSC::Heap::setMaxLiveSize):
2017-01-11 Yusuke Suzuki <utatane.tea@gmail.com>
Decouple module loading initiator from ScriptElement
https://bugs.webkit.org/show_bug.cgi?id=166888
Reviewed by Saam Barati and Ryosuke Niwa.
Add ScriptFetcher and JSScriptFetcher.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ModuleLoaderPrototype.js:
(requestFetch):
(requestInstantiate):
(requestSatisfy):
(requestInstantiateAll):
(requestLink):
(moduleEvaluation):
(loadAndEvaluateModule):
(importModule):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
(JSC::linkAndEvaluateModule):
* runtime/Completion.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::JSModuleLoader::instantiate):
(JSC::JSModuleLoader::evaluate):
* runtime/JSModuleLoader.h:
* runtime/JSScriptFetcher.cpp: Copied from Source/WebCore/dom/LoadableScript.cpp.
(JSC::JSScriptFetcher::destroy):
* runtime/JSScriptFetcher.h: Added.
(JSC::JSScriptFetcher::createStructure):
(JSC::JSScriptFetcher::create):
(JSC::JSScriptFetcher::fetcher):
(JSC::JSScriptFetcher::JSScriptFetcher):
* runtime/JSType.h:
* runtime/ScriptFetcher.h: Copied from Source/WebCore/dom/LoadableScript.cpp.
(JSC::ScriptFetcher::~ScriptFetcher):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-01-10 Yusuke Suzuki <utatane.tea@gmail.com>
Implement JSSourceCode to propagate SourceCode in module pipeline
https://bugs.webkit.org/show_bug.cgi?id=166861
Reviewed by Saam Barati.
Instead of propagating source code string, we propagate JSSourceCode
cell in the module pipeline. This allows us to attach a metadata
to the propagated source code string. In particular, it propagates
SourceOrigin through the module pipeline.
And it also fixes JSC shell to use Module source type for module source code.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ModuleLoaderPrototype.js:
(fulfillFetch):
(requestFetch):
* jsc.cpp:
(GlobalObject::moduleLoaderFetch):
(runWithScripts):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::provide):
* runtime/JSModuleLoader.h:
* runtime/JSSourceCode.cpp: Added.
(JSC::JSSourceCode::destroy):
* runtime/JSSourceCode.h: Added.
(JSC::JSSourceCode::createStructure):
(JSC::JSSourceCode::create):
(JSC::JSSourceCode::sourceCode):
(JSC::JSSourceCode::JSSourceCode):
* runtime/JSType.h:
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-01-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r210052.
https://bugs.webkit.org/show_bug.cgi?id=166915
"breaks web compatability" (Requested by keith_miller on
#webkit).
Reverted changeset:
"Add support for global"
https://bugs.webkit.org/show_bug.cgi?id=165171
http://trac.webkit.org/changeset/210052
2017-01-10 Sam Weinig <sam@webkit.org>
[WebIDL] Remove most of the custom bindings for the WebGL code
https://bugs.webkit.org/show_bug.cgi?id=166834
Reviewed by Alex Christensen.
* runtime/ArrayPrototype.h:
* runtime/ObjectPrototype.h:
Export the ClassInfo so it can be used from WebCore.
2017-01-09 Filip Pizlo <fpizlo@apple.com>
Streamline the GC barrier slowpath
https://bugs.webkit.org/show_bug.cgi?id=166878
Reviewed by Geoffrey Garen and Saam Barati.
This implements two optimizations to the barrier:
- Removes the write barrier buffer. This was just overhead.
- Teaches the slow path how to white an object that was black but unmarked, ensuring that
we don't take slow path for this object again.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
* heap/CellState.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::markToFixpoint):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::stopTheWorld):
(JSC::Heap::writeBarrierSlowPath):
(JSC::Heap::buildConstraintSet):
(JSC::Heap::flushWriteBarrierBuffer): Deleted.
* heap/Heap.h:
(JSC::Heap::writeBarrierBuffer): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
* heap/WriteBarrierBuffer.cpp: Removed.
* heap/WriteBarrierBuffer.h: Removed.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
* runtime/StructureIDBlob.h:
(JSC::StructureIDBlob::StructureIDBlob):
2017-01-10 Mark Lam <mark.lam@apple.com>
Property setters should not be called for bound arguments list entries.
https://bugs.webkit.org/show_bug.cgi?id=165631
Reviewed by Filip Pizlo.
* builtins/FunctionPrototype.js:
(bind):
- use @putByValDirect to set the bound arguments so that we don't consult the
prototype chain for setters.
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
- no need to create a bound arguments array because these bound functions binds
no arguments according to the spec.
2017-01-10 Skachkov Oleksandr <gskachkov@gmail.com>
Calling async arrow function which is in a class's member function will cause error
https://bugs.webkit.org/show_bug.cgi?id=166879
Reviewed by Saam Barati.
Current patch fixed loading 'super' in async arrow function. Errored appear becuase
super was loaded always nevertherless if it used in async arrow function or not, but bytecompiler
put to arrow function context only if it used within arrow function. So to fix this issue we need to
check if super was used in arrow function.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
2017-01-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r210537.
https://bugs.webkit.org/show_bug.cgi?id=166903
This change introduced JSC test failures (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"Implement JSSourceCode to propagate SourceCode in module
pipeline"
https://bugs.webkit.org/show_bug.cgi?id=166861
http://trac.webkit.org/changeset/210537
2017-01-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r210540.
https://bugs.webkit.org/show_bug.cgi?id=166896
too crude for non-WebCore clients (Requested by kling on
#webkit).
Reverted changeset:
"Crash when GC heap grows way too large."
https://bugs.webkit.org/show_bug.cgi?id=166875
http://trac.webkit.org/changeset/210540
2017-01-09 Filip Pizlo <fpizlo@apple.com>
JSArray has some object scanning races
https://bugs.webkit.org/show_bug.cgi?id=166874
Reviewed by Mark Lam.
This fixes two separate bugs, both of which I detected by running
array-splice-contiguous.js in extreme anger:
1) Some of the paths of shifting and unshifting were not grabbing the internal cell
lock. This was causing the array storage scan to crash, even though it was well
synchronized (the scan does hold the lock). The fix is just to hold the lock anywhere
that memmoves the innards of the butterfly.
2) Out of line property scanning was synchronized using double collect snapshot. Array
storage scanning was synchronized using locks. But what if array storage
transformations messed up the out of line properties? It turns out that we actually
need to hoist the array storage scanner's locking up into the double collect
snapshot.
I don't know how to write a test that does any better of a job of catching this than
array-splice-contiguous.js.
* heap/DeferGC.h: Make DisallowGC usable even if NDEBUG.
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::unshiftCountWithArrayStorage):
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterflyImpl):
2017-01-10 Andreas Kling <akling@apple.com>
Crash when GC heap grows way too large.
<https://webkit.org/b/166875>
<rdar://problem/27896585>
Reviewed by Mark Lam.
Hard cap the JavaScript heap at 4GB of live objects (determined post-GC.)
If we go past this limit, crash with a recognizable signature.
* heap/Heap.cpp:
(JSC::Heap::didExceedHeapSizeLimit):
(JSC::Heap::updateAllocationLimits):
2017-01-09 Yusuke Suzuki <utatane.tea@gmail.com>
Implement JSSourceCode to propagate SourceCode in module pipeline
https://bugs.webkit.org/show_bug.cgi?id=166861
Reviewed by Saam Barati.
Instead of propagating source code string, we propagate JSSourceCode
cell in the module pipeline. This allows us to attach a metadata
to the propagated source code string. In particular, it propagates
SourceOrigin through the module pipeline.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ModuleLoaderPrototype.js:
(fulfillFetch):
(requestFetch):
* jsc.cpp:
(GlobalObject::moduleLoaderFetch):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::provide):
* runtime/JSModuleLoader.h:
* runtime/JSSourceCode.cpp: Added.
(JSC::JSSourceCode::destroy):
* runtime/JSSourceCode.h: Added.
(JSC::JSSourceCode::createStructure):
(JSC::JSSourceCode::create):
(JSC::JSSourceCode::sourceCode):
(JSC::JSSourceCode::JSSourceCode):
* runtime/JSType.h:
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2017-01-09 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r210522): ASSERTION FAILED: divot.offset >= divotStart.offset seen with stress/import-basic.js and stress/import-from-eval.js
https://bugs.webkit.org/show_bug.cgi?id=166873
Reviewed by Saam Barati.
The divot should be the end of `import` token.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2017-01-09 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop.
* dfg/DFGPlanInlines.h:
2017-01-09 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Prototype dynamic-import
https://bugs.webkit.org/show_bug.cgi?id=165724
Reviewed by Saam Barati.
In this patch, we implement stage3 dynamic-import proposal[1].
This patch adds a new special operator `import`. And by using it, we can import
the module dynamically from modules and scripts. Before this feature, the module
is always imported statically and before executing the modules, importing the modules
needs to be done. And especially, the module can only be imported from the module.
So the classic script cannot import and use the modules. This dynamic-import relaxes
the above restrictions.
The typical dynamic-import form is the following.
import("...").then(function (namespace) { ... });
You can pass any AssignmentExpression for the import operator. So you can determine
the importing modules dynamically.
import(value).then(function (namespace) { ... });
And previously the module import declaration is only allowed in the top level statements.
But this import operator is just an expression. So you can use it in the function.
And you can use it conditionally.
async function go(cond)
{
if (cond)
return import("...");
return undefined;
}
await go(true);
Currently, this patch just implements this feature only for the JSC shell.
JSC module loader requires a new hook, `importModule`. And the JSC shell implements
this hook. So, for now, this dynamic-import is not available in the browser side.
If you write this `import` call, it always returns the rejected promise.
import is implemented like a special operator similar to `super`.
This is because import is context-sensitive. If you call the `import`, the module
key resolution is done based on the caller's running context.
For example, if you are running the script which filename is "./ok/hello.js", the module
key for the call`import("./resource/syntax.js")` becomes `"./ok/resource/syntax.js"`.
But if you write the completely same import form in the script "./error/hello.js", the
key becomes "./error/resource/syntax.js". So exposing this feature as the `import`
function is misleading: this function becomes caller's context-sensitive. That's why
dynamic-import is specified as a special operator.
To resolve the module key, we need the caller's context information like the filename of
the caller. This is provided by the SourceOrigin implemented in r210149.
In the JSC shell implementation, this SourceOrigin holds the filename of the caller. So
based on this implementation, the module loader resolve the module key.
In the near future, we will extend this SourceOrigin to hold more information needed for
the browser-side import implementation.
[1]: https://tc39.github.io/proposal-dynamic-import/
* builtins/ModuleLoaderPrototype.js:
(importModule):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetTemplateObject):
(JSC::BytecodeGenerator::emitGetGlobalPrivate):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ImportNode::emitBytecode):
* jsc.cpp:
(absolutePath):
(GlobalObject::moduleLoaderImportModule):
(functionRun):
(functionLoad):
(functionCheckSyntax):
(runWithScripts):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createImportExpr):
* parser/NodeConstructors.h:
(JSC::ImportNode::ImportNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isImportNode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createImportExpr):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncImportModule):
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::getModuleNamespaceObject):
* runtime/JSModuleLoader.h:
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeGetModuleNamespaceObject):
2017-01-08 Filip Pizlo <fpizlo@apple.com>
Make the collector's fixpoint smart about scheduling work
https://bugs.webkit.org/show_bug.cgi?id=165910
Reviewed by Keith Miller.
Prior to this change, every time the GC would run any constraints in markToFixpoint, it
would run all of the constraints. It would always run them in the same order. That means
that so long as any one constraint was generating new work, we'd pay the price of all
constraints. This is usually OK because most constraints are cheap but it artificially
inflates the cost of slow constraints - especially ones that are expensive but usually
generate no new work.
This patch redoes how the GC runs constraints by applying ideas from data flow analysis.
The GC now builds a MarkingConstraintSet when it boots up, and this contains all of the
constraints as well as some meta-data about them. Now, markToFixpoint just calls into
MarkingConstraintSet to execute constraints. Because constraint execution and scheduling
need to be aware of each other, I rewrote markToFixpoint in such a way that it's more
obvious how the GC goes between constraint solving, marking with stopped mutator, and
marking with resumed mutator. This also changes the scheduler API in such a way that a
synchronous stop-the-world collection no longer needs to do fake stop/resume - instead we
just swap the space-time scheduler for the stop-the-world scheduler.
This is a big streamlining of the GC. This is a speed-up in GC-heavy tests because we
now execute most constraints exactly twice regardless of how many total fixpoint
iterations we do. Now, when we run out of marking work, the constraint solver will just
run the constraint that is most likely to generate new visiting work, and if it does
generate work, then the GC now goes back to marking. Before, it would run *all*
constraints and then go back to marking. The constraint solver is armed with three
information signals that it uses to sort the constraints in order of descending likelihood
to generate new marking work. Then it runs them in that order until it there is new
marking work. The signals are:
1) Whether the constraint is greyed by marking or execution. We call this the volatility
of the constraint. For example, weak reference constraints have GreyedByMarking as
their volatility because they are most likely to have something to say after we've done
some marking. On the other hand, conservative roots have GreyedByExecution as their
volatility because they will give new information anytime we let the mutator run. The
constraint solver will only run GreyedByExecution constraints as roots and after the
GreyedByMarking constraints go silent. This ensures that we don't try to scan
conservative roots every time we need to re-run weak references and vice-versa.
Another way to look at it is that the constraint solver tries to predict if the
wavefront is advancing or retreating. The wavefront is almost certainly advancing so
long as the mark stacks are non-empty or so long as at least one of the GreyedByMarking
constraints is still producing work. Otherwise the wavefront is almost certainly
retreating. It's most profitable to run GreyedByMarking constraints when the wavefront
is advancing, and most profitable to run GreyedByExecution constraints when the
wavefront is retreating.
We use the predicted wavefront direction and the volatility of constraints as a
first-order signal of constraint profitability.
2) How much visiting work was created the last time the constraint ran. The solver
remembers the lastVisitCount, and uses it to predict how much work the constraint will
generate next time. In practice this means we will keep re-running the one interesting
constraint until it shuts up.
3) Optional work predictors for some constraints. The constraint that shuffles the mutator
mark stack into the main SlotVisitor's mutator mark stack always knows exactly how much
work it will create.
The sum of (2) and (3) are used as a second-order signal of constraint profitability.
The constraint solver will always run all of the GreyedByExecution constraints at GC
start, since these double as the GC's roots. The constraint solver will always run all of
the GreyedByMarking constraints the first time that marking stalls. Other than that, the
solver will keep running constraints, sorted according to their likelihood to create work,
until either work is created or we run out of constraints to run. GC termination happens
when we run out of constraints to run.
This new infrastructure means that we have a much better chance of dealing with worst-case
DOM pathologies. If we can intelligently factor different evil DOM things into different
constraints with the right work predictions then this could reduce the cost of those DOM
things by a factor of N where N is the number of fixpoint iterations the GC typically
does. N is usually around 5-6 even for simple heaps.
My perf measurements say:
PLT3: 0.02% faster with 5.3% confidence.
JetStream: 0.15% faster with 17% confidence.
Speedometer: 0.58% faster with 82% confidence.
Here are the details from JetStream:
splay: 1.02173x faster with 0.996841 confidence
splay-latency: 1.0617x faster with 0.987462 confidence
towers.c: 1.01852x faster with 0.92128 confidence
crypto-md5: 1.06058x faster with 0.482363 confidence
score: 1.00152x faster with 0.16892 confidence
I think that Speedometer is legitimately benefiting from this change based on looking at
--logGC=true output. We are now spending less time reexecuting expensive constraints. I
think that JetStream/splay is also benefiting, because although the constraints it sees
are cheap, it spends 30% of its time in GC so even small improvements matter.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::markCodeBlocks): Deleted.
(JSC::DFG::Plan::rememberCodeBlocks): Deleted.
* dfg/DFGPlan.h:
* dfg/DFGPlanInlines.h: Added.
(JSC::DFG::Plan::iterateCodeBlocksForGC):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::markCodeBlocks): Deleted.
(JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
(JSC::DFG::rememberCodeBlocks): Deleted.
* dfg/DFGWorklist.h:
* dfg/DFGWorklistInlines.h: Added.
(JSC::DFG::iterateCodeBlocksForGC):
(JSC::DFG::Worklist::iterateCodeBlocksForGC):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::writeBarrierCurrentlyExecuting): Deleted.
* heap/CodeBlockSet.h:
(JSC::CodeBlockSet::iterate): Deleted.
* heap/CodeBlockSetInlines.h:
(JSC::CodeBlockSet::iterate):
(JSC::CodeBlockSet::iterateCurrentlyExecuting):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocksWithoutHoldingLocks):
(JSC::Heap::assertSharedMarkStacksEmpty):
(JSC::Heap::markToFixpoint):
(JSC::Heap::endMarking):
(JSC::Heap::collectInThread):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::buildConstraintSet):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope): Deleted.
(JSC::Heap::ResumeTheWorldScope::~ResumeTheWorldScope): Deleted.
(JSC::Heap::harvestWeakReferences): Deleted.
(JSC::Heap::visitConservativeRoots): Deleted.
(JSC::Heap::visitCompilerWorklistWeakReferences): Deleted.
* heap/Heap.h:
* heap/MarkingConstraint.cpp: Added.
(JSC::MarkingConstraint::MarkingConstraint):
(JSC::MarkingConstraint::~MarkingConstraint):
(JSC::MarkingConstraint::resetStats):
(JSC::MarkingConstraint::execute):
* heap/MarkingConstraint.h: Added.
(JSC::MarkingConstraint::index):
(JSC::MarkingConstraint::abbreviatedName):
(JSC::MarkingConstraint::name):
(JSC::MarkingConstraint::lastVisitCount):
(JSC::MarkingConstraint::quickWorkEstimate):
(JSC::MarkingConstraint::workEstimate):
(JSC::MarkingConstraint::volatility):
* heap/MarkingConstraintSet.cpp: Added.
(JSC::MarkingConstraintSet::ExecutionContext::ExecutionContext):
(JSC::MarkingConstraintSet::ExecutionContext::didVisitSomething):
(JSC::MarkingConstraintSet::ExecutionContext::shouldTimeOut):
(JSC::MarkingConstraintSet::ExecutionContext::drain):
(JSC::MarkingConstraintSet::ExecutionContext::didExecute):
(JSC::MarkingConstraintSet::ExecutionContext::execute):
(JSC::MarkingConstraintSet::MarkingConstraintSet):
(JSC::MarkingConstraintSet::~MarkingConstraintSet):
(JSC::MarkingConstraintSet::resetStats):
(JSC::MarkingConstraintSet::add):
(JSC::MarkingConstraintSet::executeBootstrap):
(JSC::MarkingConstraintSet::executeConvergence):
(JSC::MarkingConstraintSet::isWavefrontAdvancing):
(JSC::MarkingConstraintSet::executeConvergenceImpl):
(JSC::MarkingConstraintSet::executeAll):
* heap/MarkingConstraintSet.h: Added.
(JSC::MarkingConstraintSet::isWavefrontRetreating):
* heap/MutatorScheduler.cpp: Added.
(JSC::MutatorScheduler::MutatorScheduler):
(JSC::MutatorScheduler::~MutatorScheduler):
(JSC::MutatorScheduler::didStop):
(JSC::MutatorScheduler::willResume):
(JSC::MutatorScheduler::didExecuteConstraints):
(JSC::MutatorScheduler::log):
(JSC::MutatorScheduler::shouldStop):
(JSC::MutatorScheduler::shouldResume):
* heap/MutatorScheduler.h: Added.
* heap/OpaqueRootSet.h:
(JSC::OpaqueRootSet::add):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::visitAsConstraint):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::didReachTermination):
(JSC::SlotVisitor::hasWork):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively):
(JSC::SlotVisitor::addOpaqueRoot):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::addToVisitCount):
* heap/SpaceTimeMutatorScheduler.cpp: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.cpp.
(JSC::SpaceTimeMutatorScheduler::Snapshot::Snapshot):
(JSC::SpaceTimeMutatorScheduler::Snapshot::now):
(JSC::SpaceTimeMutatorScheduler::Snapshot::bytesAllocatedThisCycle):
(JSC::SpaceTimeMutatorScheduler::SpaceTimeMutatorScheduler):
(JSC::SpaceTimeMutatorScheduler::~SpaceTimeMutatorScheduler):
(JSC::SpaceTimeMutatorScheduler::state):
(JSC::SpaceTimeMutatorScheduler::beginCollection):
(JSC::SpaceTimeMutatorScheduler::didStop):
(JSC::SpaceTimeMutatorScheduler::willResume):
(JSC::SpaceTimeMutatorScheduler::didExecuteConstraints):
(JSC::SpaceTimeMutatorScheduler::timeToStop):
(JSC::SpaceTimeMutatorScheduler::timeToResume):
(JSC::SpaceTimeMutatorScheduler::log):
(JSC::SpaceTimeMutatorScheduler::endCollection):
(JSC::SpaceTimeMutatorScheduler::bytesAllocatedThisCycleImpl):
(JSC::SpaceTimeMutatorScheduler::bytesSinceBeginningOfCycle):
(JSC::SpaceTimeMutatorScheduler::maxHeadroom):
(JSC::SpaceTimeMutatorScheduler::headroomFullness):
(JSC::SpaceTimeMutatorScheduler::mutatorUtilization):
(JSC::SpaceTimeMutatorScheduler::collectorUtilization):
(JSC::SpaceTimeMutatorScheduler::elapsedInPeriod):
(JSC::SpaceTimeMutatorScheduler::phase):
(JSC::SpaceTimeMutatorScheduler::shouldBeResumed):
(JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization): Deleted.
(JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization): Deleted.
(JSC::SpaceTimeScheduler::Decision::elapsedInPeriod): Deleted.
(JSC::SpaceTimeScheduler::Decision::phase): Deleted.
(JSC::SpaceTimeScheduler::Decision::shouldBeResumed): Deleted.
(JSC::SpaceTimeScheduler::Decision::timeToResume): Deleted.
(JSC::SpaceTimeScheduler::Decision::timeToStop): Deleted.
(JSC::SpaceTimeScheduler::SpaceTimeScheduler): Deleted.
(JSC::SpaceTimeScheduler::snapPhase): Deleted.
(JSC::SpaceTimeScheduler::currentDecision): Deleted.
* heap/SpaceTimeMutatorScheduler.h: Copied from Source/JavaScriptCore/heap/SpaceTimeScheduler.h.
(JSC::SpaceTimeScheduler::Decision::operator bool): Deleted.
* heap/SpaceTimeScheduler.cpp: Removed.
* heap/SpaceTimeScheduler.h: Removed.
* heap/SynchronousStopTheWorldMutatorScheduler.cpp: Added.
(JSC::SynchronousStopTheWorldMutatorScheduler::SynchronousStopTheWorldMutatorScheduler):
(JSC::SynchronousStopTheWorldMutatorScheduler::~SynchronousStopTheWorldMutatorScheduler):
(JSC::SynchronousStopTheWorldMutatorScheduler::state):
(JSC::SynchronousStopTheWorldMutatorScheduler::beginCollection):
(JSC::SynchronousStopTheWorldMutatorScheduler::timeToStop):
(JSC::SynchronousStopTheWorldMutatorScheduler::timeToResume):
(JSC::SynchronousStopTheWorldMutatorScheduler::endCollection):
* heap/SynchronousStopTheWorldMutatorScheduler.h: Added.
* heap/VisitingTimeout.h: Added.
(JSC::VisitingTimeout::VisitingTimeout):
(JSC::VisitingTimeout::visitCount):
(JSC::VisitingTimeout::didVisitSomething):
(JSC::VisitingTimeout::shouldTimeOut):
* runtime/Options.h:
2017-01-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r210476.
https://bugs.webkit.org/show_bug.cgi?id=166859
"4% JSBench regression" (Requested by keith_mi_ on #webkit).
Reverted changeset:
"Add a slice intrinsic to the DFG/FTL"
https://bugs.webkit.org/show_bug.cgi?id=166707
http://trac.webkit.org/changeset/210476
2017-01-08 Andreas Kling <akling@apple.com>
Inject MarkedSpace size classes for a few more high-volume objects.
<https://webkit.org/b/166815>
Reviewed by Darin Adler.
Add the following classes to the list of manually injected size classes:
- JSString
- JSFunction
- PropertyTable
- Structure
Only Structure actually ends up with a new size class, the others already
can't get any tighter due to the current MarkedBlock::atomSize being 16.
I've put them in anyway to ensure that we have optimally carved-out cells
for them in the future, should they grow.
With this change, Structures get allocated in 128-byte cells instead of
160-byte cells, giving us 25% more Structures per MarkedBlock.
* heap/MarkedSpace.cpp:
2017-01-06 Saam Barati <sbarati@apple.com>
Add a slice intrinsic to the DFG/FTL
https://bugs.webkit.org/show_bug.cgi?id=166707
Reviewed by Filip Pizlo.
The gist of this patch is to inline Array.prototype.slice
into the DFG/FTL. The implementation in the DFG-backend
and FTLLowerDFGToB3 is just a straight forward implementation
of what the C function is doing. The more interesting bits
of this patch are setting up the proper watchpoints and conditions
in the executing code to prove that its safe to skip all of the
observable JS actions that Array.prototype.slice normally does.
We perform the following proofs:
1. Array.prototype.constructor has not changed (via a watchpoint).
2. That Array.prototype.constructor[Symbol.species] has not changed (via a watchpoint).
3. The global object is not having a bad time.
3. The array that is being sliced has an original array structure.
5. Array.prototype/Object.prototype have not transitioned.
Conditions 1, 2, and 3 are strictly required.
4 is ensuring a couple things:
1. That a "constructor" property hasn't been added to the array
we're slicing since we're supposed to perform a Get(array, "constructor").
2. That we're not slicing an instance of a subclass of Array.
We could relax 4.1 in the future if we find other ways to test if
the incoming array hasn't changed the "constructor" property.
I'm seeing a 5% speedup on crypto-pbkdf2 and often a 1% speedup on
the total benchmark (the results are sometimes noisy).
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasArrayMode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArraySlice):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
(JSC::speciesWatchpointIsValid):
(JSC::speciesConstructArray):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
(JSC::ArrayPrototype::initializeSpeciesWatchpoint):
(JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
(JSC::speciesWatchpointsValid): Deleted.
(JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): Deleted.
* runtime/ArrayPrototype.h:
(JSC::ArrayPrototype::speciesWatchpointStatus): Deleted.
(): Deleted.
* runtime/Intrinsic.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arraySpeciesWatchpoint):
2017-01-06 Mark Lam <mark.lam@apple.com>
The ObjC API's JSVirtualMachine's map tables need to be guarded by a lock.
https://bugs.webkit.org/show_bug.cgi?id=166778
<rdar://problem/29761198>
Reviewed by Filip Pizlo.
Now that we have a concurrent GC, access to JSVirtualMachine's
m_externalObjectGraph and m_externalRememberedSet need to be guarded by a lock
since both the GC marker thread and the mutator thread may access them at the
same time.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine addExternalRememberedObject:]):
(-[JSVirtualMachine addManagedReference:withOwner:]):
(-[JSVirtualMachine removeManagedReference:withOwner:]):
(-[JSVirtualMachine externalDataMutex]):
(scanExternalObjectGraph):
(scanExternalRememberedSet):
* API/JSVirtualMachineInternal.h:
- Deleted externalObjectGraph method. There's no need to expose this.
2017-01-06 Michael Saboff <msaboff@apple.com>
@putByValDirect in Array.of and Array.from overwrites non-writable/configurable properties
https://bugs.webkit.org/show_bug.cgi?id=153486
Reviewed by Saam Barati.
Moved read only check in putDirect() to all paths.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putDirect):
2016-12-30 Filip Pizlo <fpizlo@apple.com>
DeferGC::~DeferGC should be super cheap
https://bugs.webkit.org/show_bug.cgi?id=166626
Reviewed by Saam Barati.
Right now, ~DeferGC requires running the collector's full collectIfNecessaryOrDefer()
hook, which is super big. Normally, that hook would only be called from GC slow paths,
so it ought to be possible to add complex logic to it. It benefits the GC algorithm to
make that code smart, not necessarily fast.
The right thing for it to do is to have ~DeferGC check a boolean to see if
collectIfNecessaryOrDefer() had previously deferred anything, and only call it if that
is true. That's what this patch does.
Unfortunately, this means that we lose the collectAccordingToDeferGCProbability mode,
which we used for two tests. Since I could only see two tests that used this mode, I
felt that it was better to enhance the GC than to keep the tests. I filed bug 166627 to
bring back something like that mode.
Although this patch does make some paths faster, its real goal is to ensure that bug
165963 can add more logic to collectIfNecessaryOrDefer() without introducing a big
regression. Until then, I wouldn't be surprised if this patch was a progression, but I'm
not betting on it.
* heap/Heap.cpp:
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::decrementDeferralDepthAndGCIfNeededSlow):
(JSC::Heap::canCollect): Deleted.
(JSC::Heap::shouldCollectHeuristic): Deleted.
(JSC::Heap::shouldCollect): Deleted.
(JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::incrementDeferralDepth):
(JSC::Heap::decrementDeferralDepth):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
(JSC::Heap::mayNeedToStop):
(JSC::Heap::stopIfNecessary):
* runtime/Options.h:
2017-01-05 Filip Pizlo <fpizlo@apple.com>
AutomaticThread timeout shutdown leaves a small window where notify() would think that the thread is still running
https://bugs.webkit.org/show_bug.cgi?id=166742
Reviewed by Geoffrey Garen.
Update to new AutomaticThread API.
* dfg/DFGWorklist.cpp:
2017-01-05 Per Arne Vollan <pvollan@apple.com>
[Win] Compile error.
https://bugs.webkit.org/show_bug.cgi?id=166726
Reviewed by Alex Christensen.
Add include folder.
* CMakeLists.txt:
2016-12-21 Brian Burg <bburg@apple.com>
Web Inspector: teach the protocol generator about platform-specific types, events, and commands
https://bugs.webkit.org/show_bug.cgi?id=166003
<rdar://problem/28718990>
Reviewed by Joseph Pecoraro.
This patch implements parser, model, and generator-side changes to account for
platform-specific types, events, and commands. The 'platform' property is parsed
for top-level definitions and assumed to be the 'generic' platform if none is specified.
Since the generator's platform setting acts to filter definitions with an incompatible platform,
all generators must be modified to consult a list of filtered types/commands/events for
a domain instead of directly accessing Domain.{type_declarations, commands, events}. To prevent
accidental misuse, hide those fields behind accessors (e.g., `all_type_declarations()`) so that they
are still accessible if truly necessary, but not used by default and caused an error if not migrated.
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.domains_to_generate):
(CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.domains_to_generate):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.domains_to_generate):
(CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.domains_to_generate):
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator._generate_forward_declarations):
(_generate_typedefs_for_domain):
(_generate_builders_for_domain):
(_generate_forward_declarations_for_binding_traits):
(_generate_declarations_for_enum_conversion_methods):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.domains_to_generate):
(JSBackendCommandsGenerator.generate_domain):
(JSBackendCommandsGenerator.domains_to_generate.should_generate_domain): Deleted.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator):
(ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
(ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
(ObjCConfigurationImplementationGenerator): Deleted.
(ObjCConfigurationImplementationGenerator.__init__): Deleted.
(ObjCConfigurationImplementationGenerator.output_filename): Deleted.
(ObjCConfigurationImplementationGenerator.domains_to_generate): Deleted.
(ObjCConfigurationImplementationGenerator.generate_output): Deleted.
(ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_domain): Deleted.
(ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): Deleted.
(ObjCConfigurationImplementationGenerator._generate_conversions_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_conversions_for_command.in_param_expression): Deleted.
(ObjCConfigurationImplementationGenerator._generate_invocation_for_command): Deleted.
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator.generate_output):
(ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCConfigurationImplementationGenerator):
(ObjCConfigurationImplementationGenerator.generate_output):
(ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjCConfigurationImplementationGenerator._generate_ivars):
(ObjCConfigurationImplementationGenerator._generate_dealloc):
(ObjCBackendDispatcherImplementationGenerator): Deleted.
(ObjCBackendDispatcherImplementationGenerator.__init__): Deleted.
(ObjCBackendDispatcherImplementationGenerator.output_filename): Deleted.
(ObjCBackendDispatcherImplementationGenerator.generate_output): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_ivars): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_dealloc): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): Deleted.
(ObjCBackendDispatcherImplementationGenerator._variable_name_prefix_for_domain): Deleted.
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_forward_declarations):
(ObjCHeaderGenerator._generate_enums):
(ObjCHeaderGenerator._generate_types):
(ObjCHeaderGenerator._generate_command_protocols):
(ObjCHeaderGenerator._generate_event_interfaces):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.generate_output):
(ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.domains_to_generate):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementations):
* inspector/scripts/codegen/generator.py:
(Generator.can_generate_platform):
(Generator):
(Generator.type_declarations_for_domain):
(Generator.commands_for_domain):
(Generator.events_for_domain):
These are the core methods for computing whether a definition can be used given a target platform.
(Generator.calculate_types_requiring_shape_assertions):
(Generator._traverse_and_assign_enum_values):
* inspector/scripts/codegen/models.py:
(Protocol.parse_type_declaration):
(Protocol.parse_command):
(Protocol.parse_event):
(Protocol.resolve_types):
(Domain.__init__):
(Domain):
(Domain.all_type_declarations):
(Domain.all_commands):
(Domain.all_events):
Hide fields behind these accessors so it's really obvious when we are ignoring platform filtering.
(Domain.resolve_type_references):
(TypeDeclaration.__init__):
(Command.__init__):
(Event.__init__):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.should_generate_types_for_domain):
(ObjCGenerator):
(ObjCGenerator.should_generate_commands_for_domain):
(ObjCGenerator.should_generate_events_for_domain):
(ObjCGenerator.should_generate_domain_types_filter): Deleted.
(ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types): Deleted.
(ObjCGenerator.should_generate_domain_command_handler_filter): Deleted.
(ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler): Deleted.
(ObjCGenerator.should_generate_domain_event_dispatcher_filter): Deleted.
(ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher): Deleted.
Clean up some messy code that essentially did the same definition filtering as we must do for platforms.
This will be enhanced in a future patch so that platform filtering will take priority over the target framework.
The results above need rebaselining because the class names for two generators were swapped by accident.
Fixing the names causes the order of generated files to change, and this generates ugly diffs because every
generated file includes the same copyright block at the top.
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/generic/expected/fail-on-command-with-invalid-platform.json-error: Added.
* inspector/scripts/tests/generic/expected/fail-on-type-with-invalid-platform.json-error: Added.
* inspector/scripts/tests/generic/fail-on-command-with-invalid-platform.json: Added.
* inspector/scripts/tests/generic/fail-on-type-with-invalid-platform.json: Added.
Add error test cases for invalid platforms in commands, types, and events.
* inspector/scripts/tests/generic/definitions-with-mac-platform.json: Added.
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: Added.
* inspector/scripts/tests/all/definitions-with-mac-platform.json: Added.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: Added.
* inspector/scripts/tests/ios/definitions-with-mac-platform.json: Added.
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: Added.
* inspector/scripts/tests/mac/definitions-with-mac-platform.json: Added.
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: Added.
Add a basic 4-way test that generates code for each platform from the same specification.
With 'macos' platform for each definition, only 'all' and 'mac' generate anything interesting.
2017-01-03 Brian Burg <bburg@apple.com>
Web Inspector: teach the protocol generator about platform-specific types, events, and commands
https://bugs.webkit.org/show_bug.cgi?id=166003
<rdar://problem/28718990>
Reviewed by Joseph Pecoraro.
This patch implements parser, model, and generator-side changes to account for
platform-specific types, events, and commands. The 'platform' property is parsed
for top-level definitions and assumed to be the 'generic' platform if none is specified.
Since the generator's platform setting acts to filter definitions with an incompatible platform,
all generators must be modified to consult a list of filtered types/commands/events for
a domain instead of directly accessing Domain.{type_declarations, commands, events}. To prevent
accidental misuse, hide those fields behind accessors (e.g., `all_type_declarations()`) so that they
are still accessible if truly necessary, but not used by default and caused an error if not migrated.
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.domains_to_generate):
(CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.domains_to_generate):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.domains_to_generate):
(CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.domains_to_generate):
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator._generate_forward_declarations):
(_generate_typedefs_for_domain):
(_generate_builders_for_domain):
(_generate_forward_declarations_for_binding_traits):
(_generate_declarations_for_enum_conversion_methods):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.should_generate_domain):
(JSBackendCommandsGenerator.domains_to_generate):
(JSBackendCommandsGenerator.generate_domain):
(JSBackendCommandsGenerator.domains_to_generate.should_generate_domain): Deleted.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.domains_to_generate):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator):
(ObjCBackendDispatcherImplementationGenerator.domains_to_generate):
(ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
(ObjCConfigurationImplementationGenerator): Deleted.
(ObjCConfigurationImplementationGenerator.__init__): Deleted.
(ObjCConfigurationImplementationGenerator.output_filename): Deleted.
(ObjCConfigurationImplementationGenerator.domains_to_generate): Deleted.
(ObjCConfigurationImplementationGenerator.generate_output): Deleted.
(ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_domain): Deleted.
(ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): Deleted.
(ObjCConfigurationImplementationGenerator._generate_conversions_for_command): Deleted.
(ObjCConfigurationImplementationGenerator._generate_conversions_for_command.in_param_expression): Deleted.
(ObjCConfigurationImplementationGenerator._generate_invocation_for_command): Deleted.
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator.generate_output):
(ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCConfigurationImplementationGenerator):
(ObjCConfigurationImplementationGenerator.generate_output):
(ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjCConfigurationImplementationGenerator._generate_ivars):
(ObjCConfigurationImplementationGenerator._generate_dealloc):
(ObjCBackendDispatcherImplementationGenerator): Deleted.
(ObjCBackendDispatcherImplementationGenerator.__init__): Deleted.
(ObjCBackendDispatcherImplementationGenerator.output_filename): Deleted.
(ObjCBackendDispatcherImplementationGenerator.generate_output): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_ivars): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_dealloc): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): Deleted.
(ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): Deleted.
(ObjCBackendDispatcherImplementationGenerator._variable_name_prefix_for_domain): Deleted.
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.domains_to_generate):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_forward_declarations):
(ObjCHeaderGenerator._generate_enums):
(ObjCHeaderGenerator._generate_types):
(ObjCHeaderGenerator._generate_command_protocols):
(ObjCHeaderGenerator._generate_event_interfaces):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.generate_output):
(ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.domains_to_generate):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementations):
* inspector/scripts/codegen/generator.py:
(Generator.can_generate_platform):
(Generator):
(Generator.type_declarations_for_domain):
(Generator.commands_for_domain):
(Generator.events_for_domain):
These are the core methods for computing whether a definition can be used given a target platform.
(Generator.calculate_types_requiring_shape_assertions):
(Generator._traverse_and_assign_enum_values):
* inspector/scripts/codegen/models.py:
(Protocol.parse_type_declaration):
(Protocol.parse_command):
(Protocol.parse_event):
(Protocol.resolve_types):
(Domain.__init__):
(Domain):
(Domain.all_type_declarations):
(Domain.all_commands):
(Domain.all_events):
Hide fields behind these accessors so it's really obvious when we are ignoring platform filtering.
(Domain.resolve_type_references):
(TypeDeclaration.__init__):
(Command.__init__):
(Event.__init__):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.should_generate_types_for_domain):
(ObjCGenerator):
(ObjCGenerator.should_generate_commands_for_domain):
(ObjCGenerator.should_generate_events_for_domain):
(ObjCGenerator.should_generate_domain_types_filter): Deleted.
(ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types): Deleted.
(ObjCGenerator.should_generate_domain_command_handler_filter): Deleted.
(ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler): Deleted.
(ObjCGenerator.should_generate_domain_event_dispatcher_filter): Deleted.
(ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher): Deleted.
Clean up some messy code that essentially did the same definition filtering as we must do for platforms.
This will be enhanced in a future patch so that platform filtering will take priority over the target framework.
The following results need rebaselining because the class names for two generators were swapped by accident.
Fixing the names causes the order of generated files to change, and this generates ugly diffs because every
generated file includes the same copyright block at the top.
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
2017-01-03 Brian Burg <bburg@apple.com>
Web Inspector: teach the protocol generator about platform-specific types, events, and commands
https://bugs.webkit.org/show_bug.cgi?id=166003
<rdar://problem/28718990>
Reviewed by Joseph Pecoraro.
Make it possible to test inspector protocol generator output for different platforms.
Move existing tests to the generic/ subdirectory, as they are to be generated
without any specific platform. Later, platform-specific generator behavior will be
tested by cloning the same test to multiple platform directories.
* inspector/scripts/tests{/ => /generic/}commands-with-async-attribute.json
* inspector/scripts/tests{/ => /generic/}commands-with-optional-call-return-parameters.json
* inspector/scripts/tests{/ => /generic/}domains-with-varying-command-sizes.json
* inspector/scripts/tests{/ => /generic/}enum-values.json
* inspector/scripts/tests{/ => /generic/}events-with-optional-parameters.json
* inspector/scripts/tests{/ => /generic/}expected/commands-with-async-attribute.json-result
* inspector/scripts/tests{/ => /generic/}expected/commands-with-optional-call-return-parameters.json-result
* inspector/scripts/tests{/ => /generic/}expected/domains-with-varying-command-sizes.json-result
* inspector/scripts/tests{/ => /generic/}expected/enum-values.json-result
* inspector/scripts/tests{/ => /generic/}expected/events-with-optional-parameters.json-result
* inspector/scripts/tests{/ => /generic/}expected/fail-on-domain-availability.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-command-call-parameter-names.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-command-return-parameter-names.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-event-parameter-names.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-type-declarations.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-duplicate-type-member-names.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-enum-with-no-values.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-number-typed-optional-parameter-flag.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-number-typed-optional-type-member.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-string-typed-optional-parameter-flag.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-string-typed-optional-type-member.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-type-declaration-using-type-reference.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-type-reference-as-primitive-type.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-type-with-lowercase-name.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-unknown-type-reference-in-type-declaration.json-error
* inspector/scripts/tests{/ => /generic/}expected/fail-on-unknown-type-reference-in-type-member.json-error
* inspector/scripts/tests{/ => /generic/}expected/generate-domains-with-feature-guards.json-result
* inspector/scripts/tests{/ => /generic/}expected/same-type-id-different-domain.json-result
* inspector/scripts/tests{/ => /generic/}expected/shadowed-optional-type-setters.json-result
* inspector/scripts/tests{/ => /generic/}expected/type-declaration-aliased-primitive-type.json-result
* inspector/scripts/tests{/ => /generic/}expected/type-declaration-array-type.json-result
* inspector/scripts/tests{/ => /generic/}expected/type-declaration-enum-type.json-result
* inspector/scripts/tests{/ => /generic/}expected/type-declaration-object-type.json-result
* inspector/scripts/tests{/ => /generic/}expected/type-requiring-runtime-casts.json-result
* inspector/scripts/tests{/ => /generic/}fail-on-domain-availability.json
* inspector/scripts/tests{/ => /generic/}fail-on-duplicate-command-call-parameter-names.json
* inspector/scripts/tests{/ => /generic/}fail-on-duplicate-command-return-parameter-names.json
* inspector/scripts/tests{/ => /generic/}fail-on-duplicate-event-parameter-names.json
* inspector/scripts/tests{/ => /generic/}fail-on-duplicate-type-declarations.json
* inspector/scripts/tests{/ => /generic/}fail-on-duplicate-type-member-names.json
* inspector/scripts/tests{/ => /generic/}fail-on-enum-with-no-values.json
* inspector/scripts/tests{/ => /generic/}fail-on-number-typed-optional-parameter-flag.json
* inspector/scripts/tests{/ => /generic/}fail-on-number-typed-optional-type-member.json
* inspector/scripts/tests{/ => /generic/}fail-on-string-typed-optional-parameter-flag.json
* inspector/scripts/tests{/ => /generic/}fail-on-string-typed-optional-type-member.json
* inspector/scripts/tests{/ => /generic/}fail-on-type-declaration-using-type-reference.json
* inspector/scripts/tests{/ => /generic/}fail-on-type-reference-as-primitive-type.json
* inspector/scripts/tests{/ => /generic/}fail-on-type-with-lowercase-name.json
* inspector/scripts/tests{/ => /generic/}fail-on-unknown-type-reference-in-type-declaration.json
* inspector/scripts/tests{/ => /generic/}fail-on-unknown-type-reference-in-type-member.json
* inspector/scripts/tests{/ => /generic/}generate-domains-with-feature-guards.json
* inspector/scripts/tests{/ => /generic/}same-type-id-different-domain.json
* inspector/scripts/tests{/ => /generic/}shadowed-optional-type-setters.json
* inspector/scripts/tests{/ => /generic/}type-declaration-aliased-primitive-type.json
* inspector/scripts/tests{/ => /generic/}type-declaration-array-type.json
* inspector/scripts/tests{/ => /generic/}type-declaration-enum-type.json
* inspector/scripts/tests{/ => /generic/}type-declaration-object-type.json
* inspector/scripts/tests{/ => /generic/}type-requiring-runtime-casts.json
2017-01-03 Brian Burg <bburg@apple.com>
Web Inspector: teach the protocol generator about platform-specific types, events, and commands
https://bugs.webkit.org/show_bug.cgi?id=166003
<rdar://problem/28718990>
Reviewed by Joseph Pecoraro.
Add a --platform argument to generate-inspector-protocol-bindings.py and propagate
the specified platform to each generator. This will be used in the next few patches
to exclude types, events, and commands that are unsupported by the backend platform.
Covert all subclasses of Generator to pass along their positional arguments so that we
can easily change base class arguments without editing all generator constructors.
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.__init__):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCConfigurationImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCBackendDispatcherImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.__init__):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator.__init__):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator.__init__):
Pass along *args instead of single positional arguments.
* inspector/scripts/codegen/generator.py:
(Generator.__init__):
Save the target platform and add a getter.
* inspector/scripts/codegen/models.py:
(Platform):
(Platform.__init__):
(Platform.fromString):
(Platforms):
Define the allowed Platform instances (iOS, macOS, and Any).
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.and.__init__):
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
Pass along *args instead of single positional arguments.
2017-01-04 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: add Module.sections
https://bugs.webkit.org/show_bug.cgi?id=165159
<rdar://problem/29760326>
Reviewed by Mark Lam.
As described in: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodulecustomsections
This was added for Emscripten, and is likely to be used soon.
* wasm/WasmFormat.h: custom sections are just name + bytes
* wasm/WasmModuleParser.cpp: parse them, instead of skipping over
* wasm/WasmModuleParser.h:
* wasm/js/WebAssemblyModulePrototype.cpp: construct the Array of
ArrayBuffer as described in the spec
(JSC::webAssemblyModuleProtoCustomSections):
2017-01-04 Saam Barati <sbarati@apple.com>
We don't properly handle exceptions inside the nativeCallTrampoline macro in the LLInt
https://bugs.webkit.org/show_bug.cgi?id=163720
Reviewed by Mark Lam.
In the LLInt, we were incorrectly doing the exception check after the call.
Before the exception check, we were unwinding to our caller's
frame under the assumption that our caller was always a JS frame.
This is incorrect, however, because our caller might be a C frame.
One way that it can be a C frame is when C calls to JS, and JS tail
calls to native. This patch fixes this bug by doing unwinding from
the native callee's frame instead of its callers.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2017-01-03 JF Bastien <jfbastien@apple.com>
REGRESSION (r210244): Release JSC Stress test failure: wasm.yaml/wasm/js-api/wasm-to-wasm.js.default-wasm
https://bugs.webkit.org/show_bug.cgi?id=166669
<rdar://problem/29856455>
Reviewed by Saam Barati.
Bug #165282 added wasm -> wasm calls, but caused crashes in
release builds because the pinned registers are also callee-saved
and were being clobbered. B3 didn't see itself clobbering them
when no memory was used, and therefore omitted a restore.
This was causing the C++ code in callWebAssemblyFunction to crash
because $r12 was 0, and it expected it to have its value prior to
the call.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::createJSToWasmWrapper):
2017-01-03 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Address failures under LayoutTests/inspector/debugger/stepping
https://bugs.webkit.org/show_bug.cgi?id=166300
Reviewed by Brian Burg.
* debugger/Debugger.cpp:
(JSC::Debugger::continueProgram):
When continuing, clear states that would have had us pause again.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didBecomeIdle):
When resuming after becoming idle, be sure to clear Debugger state.
2017-01-03 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: check and test in-call / out-call values
https://bugs.webkit.org/show_bug.cgi?id=164876
<rdar://problem/29844107>
Reviewed by Saam Barati.
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs): fix the wasm -> JS call coercions for f32 /
f64 which the assotiated tests inadvertently tripped on: the
previous code wasn't correctly performing JSValue boxing for
"double" values. This change is slightly involved because it
requires two scratch registers to materialize the
`DoubleEncodeOffset` value. This change therefore reorganizes the
code to first generate traps, then handle all integers (freeing
all GPRs), and then all the floating-point values.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction): Implement the defined semantics
for mismatched arities when JS calls wasm:
https://github.com/WebAssembly/design/blob/master/JS.md#exported-function-exotic-objects
- i32 is 0, f32 / f64 are NaN.
- wasm functions which return "void" are "undefined" in JS.
2017-01-03 Per Arne Vollan <pvollan@apple.com>
[Win] jsc.exe sometimes never exits.
https://bugs.webkit.org/show_bug.cgi?id=158073
Reviewed by Darin Adler.
On Windows the thread specific destructor is also called when the main thread is exiting.
This may lead to the main thread waiting forever for the machine thread lock when exiting,
if the sampling profiler thread was terminated by the system while holding the machine
thread lock.
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::removeThread):
2017-01-02 Julien Brianceau <jbriance@cisco.com>
Remove sh4 specific code from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=166640
Reviewed by Filip Pizlo.
sh4-specific code does not compile for a while (r189884 at least).
As nobody seems to have interest in this architecture anymore, let's
remove this dead code and thus ease the burden for JSC maintainers.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Jump::Jump):
(JSC::AbstractMacroAssembler::Jump::link):
* assembler/MacroAssembler.h:
* assembler/MacroAssemblerSH4.h: Removed.
* assembler/MaxFrameExtentForSlowPathCall.h:
* assembler/SH4Assembler.h: Removed.
* bytecode/DOMJITAccessCasePatchpointParams.cpp:
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::debugCall):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/ExecutableAllocator.h:
* jit/FPRInfo.h:
* jit/GPRInfo.h:
* jit/JITInlines.h:
(JSC::JIT::callOperation):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileCTINativeCall):
* jit/JITOperations.cpp:
* jit/RegisterSet.cpp:
(JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
(JSC::RegisterSet::dfgCalleeSaveRegisters):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* offlineasm/backends.rb:
* offlineasm/instructions.rb:
* offlineasm/sh4.rb: Removed.
* yarr/YarrJIT.cpp:
(JSC::Yarr::YarrGenerator::generateEnter):
(JSC::Yarr::YarrGenerator::generateReturn):
2017-01-02 JF Bastien <jfbastien@apple.com>
WebAssembly: handle and optimize wasm export → wasm import calls
https://bugs.webkit.org/show_bug.cgi?id=165282
Reviewed by Saam Barati.
- Add a new JSType for WebAssemblyFunction, and use it when creating its
structure. This will is used to quickly detect from wasm whether the import
call is to another wasm module, or whether it's to JS.
- Generate two stubs from the import stub generator: one for wasm->JS and one
for wasm -> wasm. This is done at Module time. Which is called will only be
known at Instance time, once we've received the import object. We want to
avoid codegen at Instance time, so having both around is great.
- Restore the WebAssembly global state (VM top Instance, and pinned registers)
after call / call_indirect, and in the JS->wasm entry stub.
- Pinned registers are now a global thing, not per-Memory, because the wasm ->
wasm stubs are generated at Module time where we don't really have enough
information to do the right thing (doing so would generate too much code).
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSType.h: add WebAssemblyFunctionType as a JSType
* wasm/WasmB3IRGenerator.cpp: significantly rework how calls which
could be external work, and how we save / restore global state:
VM's top Instance, and pinned registers
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::getMemoryBaseAndSize):
(JSC::Wasm::restoreWebAssemblyGlobalState):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBinding.cpp:
(JSC::Wasm::materializeImportJSCell):
(JSC::Wasm::wasmToJS):
(JSC::Wasm::wasmToWasm): the main goal of this patch was adding this function
(JSC::Wasm::exitStubGenerator):
* wasm/WasmBinding.h:
* wasm/WasmFormat.h: Get rid of much of the function index space:
we already have all of its information elsewhere, and as-is it
provides no extra efficiency.
(JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
(JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
(JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmMemory.cpp: Add some logging.
(JSC::Wasm::Memory::dump): this was nice when debugging
(JSC::Wasm::Memory::makeString):
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::grow):
* wasm/WasmMemory.h: don't use extra indirection, it wasn't
needed. Reorder some of the fields which are looked up at runtime
so they're more cache-friendly.
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::mode):
(JSC::Wasm::Memory::offsetOfSize):
* wasm/WasmMemoryInformation.cpp: Pinned registers are now a
global thing for all of JSC, not a per-Memory thing
anymore. wasm->wasm calls are more complex otherwise: they have to
figure out how to bridge between the caller and callee's
special-snowflake pinning.
(JSC::Wasm::PinnedRegisterInfo::get):
(JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/WasmMemoryInformation.h:
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
* wasm/WasmPageCount.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
(JSC::Wasm::PageCount::dump): nice for debugging
* wasm/WasmPageCount.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::takeWasmExitStubs):
* wasm/WasmSignature.cpp:
(JSC::Wasm::Signature::toString):
(JSC::Wasm::Signature::dump):
* wasm/WasmSignature.h:
* wasm/WasmValidate.cpp:
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::offsetOfTable):
(JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
(JSC::JSWebAssemblyInstance::offsetOfImportFunction):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::create):
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::buffer):
(JSC::JSWebAssemblyMemory::grow):
* wasm/js/JSWebAssemblyMemory.h:
(JSC::JSWebAssemblyMemory::memory):
(JSC::JSWebAssemblyMemory::offsetOfMemory):
(JSC::JSWebAssemblyMemory::offsetOfSize):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::functionImportCount):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::createStructure):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::wasmEntrypoint):
(JSC::WebAssemblyFunction::offsetOfInstance):
(JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): always start with a dummy
memory, so wasm->wasm calls don't need to null-check
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
2017-01-02 Saam Barati <sbarati@apple.com>
WebAssembly: Some loads don't take into account the offset
https://bugs.webkit.org/show_bug.cgi?id=166616
<rdar://problem/29841541>
Reviewed by Keith Miller.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoadOp):
2017-01-01 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2017
https://bugs.webkit.org/show_bug.cgi?id=166278
Reviewed by Dan Bernstein.
* Info.plist:
2016-12-28 Saam Barati <sbarati@apple.com>
WebAssembly: Don't allow duplicate export names
https://bugs.webkit.org/show_bug.cgi?id=166490
<rdar://problem/29815000>
Reviewed by Keith Miller.
* wasm/WasmModuleParser.cpp:
2016-12-28 Saam Barati <sbarati@apple.com>
Unreviewed. Fix jsc.cpp build error.
* jsc.cpp:
(functionTestWasmModuleFunctions):
2016-12-28 Saam Barati <sbarati@apple.com>
WebAssembly: Implement grow_memory and current_memory
https://bugs.webkit.org/show_bug.cgi?id=166448
<rdar://problem/29803676>
Reviewed by Keith Miller.
This patch implements grow_memory, current_memory, and WebAssembly.prototype.grow.
See relevant spec texts here:
https://github.com/WebAssembly/design/blob/master/Semantics.md#linear-memory-accesses
https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymemoryprototypegrow
I also fix a couple miscellaneous bugs:
1. Data section now understands full init_exprs.
2. parseVarUint1 no longer has a bug where we allow values larger than 1 if
their bottom 8 bits are zero.
Since the JS API can now grow memory, we need to make calling an import
and call_indirect refresh the base memory register and the size registers.
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/Options.h:
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::reloadPinnedRegisters):
(JSC::Wasm::B3IRGenerator::emitReloadPinnedRegisters):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmFormat.cpp:
(JSC::Wasm::Segment::create):
* wasm/WasmFormat.h:
(JSC::Wasm::I32InitExpr::I32InitExpr):
(JSC::Wasm::I32InitExpr::globalImport):
(JSC::Wasm::I32InitExpr::constValue):
(JSC::Wasm::I32InitExpr::isConst):
(JSC::Wasm::I32InitExpr::isGlobalImport):
(JSC::Wasm::I32InitExpr::globalImportIndex):
(JSC::Wasm::Segment::byte):
(JSC::Wasm::ModuleInformation::importFunctionCount):
(JSC::Wasm::ModuleInformation::hasMemory):
* wasm/WasmFunctionParser.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::grow):
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::size):
(JSC::Wasm::Memory::sizeInPages):
(JSC::Wasm::Memory::offsetOfMemory):
(JSC::Wasm::Memory::isValid): Deleted.
(JSC::Wasm::Memory::grow): Deleted.
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::makeI32InitExpr):
* wasm/WasmModuleParser.h:
* wasm/WasmPageCount.h:
(JSC::Wasm::PageCount::bytes):
(JSC::Wasm::PageCount::pageCount):
(JSC::Wasm::PageCount::fromBytes):
(JSC::Wasm::PageCount::operator+):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
* wasm/WasmValidate.cpp:
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::offsetOfMemory):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::grow):
* wasm/js/JSWebAssemblyMemory.h:
(JSC::JSWebAssemblyMemory::offsetOfMemory):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::functionImportCount):
(JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::importCount): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::getMemory):
(JSC::webAssemblyMemoryProtoFuncBuffer):
(JSC::webAssemblyMemoryProtoFuncGrow):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::dataSegmentFail):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/wasm.json:
2016-12-26 Yusuke Suzuki <utatane.tea@gmail.com>
Use variadic templates in JSC Parser to clean up
https://bugs.webkit.org/show_bug.cgi?id=166482
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::logError):
* parser/Parser.h:
2016-12-25 Yusuke Suzuki <utatane.tea@gmail.com>
Propagate the source origin as much as possible
https://bugs.webkit.org/show_bug.cgi?id=166348
Reviewed by Darin Adler.
This patch introduces CallFrame::callerSourceOrigin, SourceOrigin class
and SourceProvider::m_sourceOrigin. CallFrame::callerSourceOrigin returns
an appropriate SourceOrigin if possible. If we cannot find the appropriate
one, we just return null SourceOrigin.
This paves the way for implementing the module dynamic-import[1].
When the import operator is evaluated, it will resolve the module
specifier with this propagated source origin of the caller function.
To support import operator inside the dynamic code generation
functions (like `eval`, `new Function`, indirect call to `eval`),
we need to propagate the caller's source origin to the generated
source code.
We do not use sourceURL for that purpose. This is because we
would like to keep sourceURL for `eval` / `new Function` null.
This sourceURL will be used for the stack dump for errors with line/column
numbers. Dumping the caller's sourceURL with line/column numbers are
meaningless. So we would like to keep it null while we would like
to propagate SourceOrigin for dynamic imports.
[1]: https://github.com/tc39/proposal-dynamic-import
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSObjectRef.cpp:
(JSObjectMakeFunction):
* API/JSScriptRef.cpp:
(OpaqueJSScript::create):
(OpaqueJSScript::vm):
(OpaqueJSScript::OpaqueJSScript):
(parseScript):
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/builtins/builtins_templates.py:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
(JSC::BuiltinExecutables::createDefaultConstructor):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::parse):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::callerSourceOrigin):
* interpreter/CallFrame.h:
* interpreter/Interpreter.cpp:
(JSC::eval):
* jsc.cpp:
(jscSource):
(GlobalObject::finishCreation):
(extractDirectoryName):
(currentWorkingDirectory):
(GlobalObject::moduleLoaderResolve):
(functionRunString):
(functionLoadString):
(functionCallerSourceOrigin):
(functionCreateBuiltin):
(functionCheckModuleSyntax):
(runInteractive):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceOrigin):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::WebAssemblySourceProvider::create):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::sourceOrigin):
* runtime/SourceOrigin.h: Added.
(JSC::SourceOrigin::SourceOrigin):
(JSC::SourceOrigin::string):
(JSC::SourceOrigin::isNull):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
2016-12-24 Caio Lima <ticaiolima@gmail.com>
[test262] Fixing mapped arguments object property test case
https://bugs.webkit.org/show_bug.cgi?id=159398
Reviewed by Saam Barati.
This patch changes GenericArguments' override mechanism to
implement corret behavior on ECMAScript test262 suite test cases of
mapped arguments object with non-configurable and non-writable
property. Also it is ensuring that arguments[i]
cannot be deleted when argument "i" is {configurable: false}.
The previous implementation is against to the specification for 2 reasons:
1. Every argument in arguments object are {writable: true} by default
(http://www.ecma-international.org/ecma-262/7.0/index.html#sec-createunmappedargumentsobject).
It means that we have to stop mapping a defined property index
if the new property descriptor contains writable (i.e writable is
present) and its value is false (also check
https://tc39.github.io/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc).
Previous implementation considers {writable: false} if writable is
not present.
2. When a property is overriden, "delete" operation is always returning true. However
delete operations should follow the specification.
We created an auxilary boolean array named m_modifiedArgumentsDescriptor
to store which arguments[i] descriptor was changed from its default
property descriptor. This modification was necessary because m_overrides
was responsible to keep this information at the same time
of keeping information about arguments mapping. The problem of this apporach was
that we needed to call overridesArgument(i) as soon as the ith argument's property
descriptor was changed and it stops the argument's mapping as sideffect, producing
wrong behavior.
To keep tracking arguments mapping status, we renamed DirectArguments::m_overrides to
DirectArguments::m_mappedArguments and now we it is responsible to manage if an
argument[i] is mapped or not.
With these 2 structures, now it is possible to an argument[i] have its property
descriptor modified and don't stop the mapping as soon as it happens. One example
of that wrong behavior can be found on arguments-bizarre-behaviour-disable-enumerability
test case, that now is fixed by this new mechanism.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
* jit/JITOperations.cpp:
(JSC::canAccessArgumentIndexQuickly):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitDirectArgumentsGetByVal):
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::estimatedSize):
(JSC::DirectArguments::visitChildren):
(JSC::DirectArguments::overrideThings):
(JSC::DirectArguments::overrideThingsIfNecessary):
(JSC::DirectArguments::unmapArgument):
(JSC::DirectArguments::copyToArguments):
(JSC::DirectArguments::overridesSize):
(JSC::DirectArguments::overrideArgument): Deleted.
* runtime/DirectArguments.h:
(JSC::DirectArguments::length):
(JSC::DirectArguments::isMappedArgument):
(JSC::DirectArguments::isMappedArgumentInDFG):
(JSC::DirectArguments::getIndexQuickly):
(JSC::DirectArguments::setIndexQuickly):
(JSC::DirectArguments::overrodeThings):
(JSC::DirectArguments::initModifiedArgumentsDescriptorIfNecessary):
(JSC::DirectArguments::setModifiedArgumentDescriptor):
(JSC::DirectArguments::isModifiedArgumentDescriptor):
(JSC::DirectArguments::offsetOfMappedArguments):
(JSC::DirectArguments::offsetOfModifiedArgumentsDescriptor):
(JSC::DirectArguments::canAccessIndexQuickly): Deleted.
(JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
(JSC::DirectArguments::offsetOfOverrides): Deleted.
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::visitChildren):
(JSC::GenericArguments<Type>::getOwnPropertySlot):
(JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
(JSC::GenericArguments<Type>::getOwnPropertyNames):
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::putByIndex):
(JSC::GenericArguments<Type>::deleteProperty):
(JSC::GenericArguments<Type>::deletePropertyByIndex):
(JSC::GenericArguments<Type>::defineOwnProperty):
(JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
(JSC::GenericArguments<Type>::initModifiedArgumentsDescriptorIfNecessary):
(JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
(JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
(JSC::GenericArguments<Type>::copyToArguments):
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::visitChildren):
(JSC::ScopedArguments::unmapArgument):
(JSC::ScopedArguments::overrideArgument): Deleted.
* runtime/ScopedArguments.h:
(JSC::ScopedArguments::isMappedArgument):
(JSC::ScopedArguments::isMappedArgumentInDFG):
(JSC::ScopedArguments::getIndexQuickly):
(JSC::ScopedArguments::setIndexQuickly):
(JSC::ScopedArguments::initModifiedArgumentsDescriptorIfNecessary):
(JSC::ScopedArguments::setModifiedArgumentDescriptor):
(JSC::ScopedArguments::isModifiedArgumentDescriptor):
(JSC::ScopedArguments::canAccessIndexQuickly): Deleted.
(JSC::ScopedArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
2016-12-23 Mark Lam <mark.lam@apple.com>
Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
https://bugs.webkit.org/show_bug.cgi?id=166466
Reviewed by Keith Miller.
* runtime/VM.cpp:
(JSC::VM::throwException):
2016-12-23 Mark Lam <mark.lam@apple.com>
Enhance LLInt tracing to dump the codeBlock signature instead of just a pointer where appropriate.
https://bugs.webkit.org/show_bug.cgi?id=166465
Reviewed by Keith Miller.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::traceFunctionPrologue):
2016-12-23 Keith Miller <keith_miller@apple.com>
WebAssembly: trap on bad division.
https://bugs.webkit.org/show_bug.cgi?id=164786
Reviewed by Mark Lam.
This patch adds traps for division / modulo by zero and for
division by int_min / -1.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
* wasm/WasmExceptionType.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/wasm.json:
2016-12-23 Mark Lam <mark.lam@apple.com>
Fix broken LLINT_SLOW_PATH_TRACING build.
https://bugs.webkit.org/show_bug.cgi?id=166463
Reviewed by Keith Miller.
* llint/LLIntExceptions.cpp:
(JSC::LLInt::returnToThrow):
(JSC::LLInt::callToThrow):
* runtime/CommonSlowPathsExceptions.cpp:
(JSC::CommonSlowPaths::interpreterThrowInCaller):
2016-12-22 Keith Miller <keith_miller@apple.com>
WebAssembly: Make spec-tests/f32.wast.js and spec-tests/f64.wast.js pass
https://bugs.webkit.org/show_bug.cgi?id=166447
Reviewed by Saam Barati.
We needed to treat -0.0 < 0.0 for floating point min/max. For min,
the algorithm works because if a == b then a and b are not NaNs so
either they are the same or they are some zero. When we or a and b
either we get the same number back or we get -0.0. Similarly for
max we use an and and the sign bit gets dropped if one is 0.0 and
the other is -0.0, otherwise, we get the same number back.
* wasm/wasm.json:
2016-12-22 Saam Barati <sbarati@apple.com>
WebAssembly: Make calling Wasm functions that returns or takes an i64 as a parameter an early exception
https://bugs.webkit.org/show_bug.cgi?id=166437
<rdar://problem/29793949>
Reviewed by Keith Miller.
This patch makes it so that we throw an exception before we do
anything else if we call a wasm function that either takes an
i64 as an argument or returns an i64.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
(JSC::WebAssemblyFunction::call): Deleted.
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::signatureIndex):
(JSC::WebAssemblyFunction::jsEntrypoint):
2016-12-22 Keith Miller <keith_miller@apple.com>
Add BitOr for floating points to B3
https://bugs.webkit.org/show_bug.cgi?id=166446
Reviewed by Saam Barati.
This patch does some slight refactoring to the ARM assembler,
which groups all the vector floating point instructions together.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::vand):
(JSC::ARM64Assembler::vorr):
(JSC::ARM64Assembler::vectorDataProcessingLogical):
(JSC::ARM64Assembler::vectorDataProcessing2Source): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::orDouble):
(JSC::MacroAssemblerARM64::orFloat):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::orDouble):
(JSC::MacroAssemblerX86Common::orFloat):
* assembler/X86Assembler.h:
(JSC::X86Assembler::orps_rr):
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::bitOrConstant):
(JSC::B3::ConstDoubleValue::bitXorConstant):
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::bitOrConstant):
(JSC::B3::ConstFloatValue::bitXorConstant):
* b3/B3ConstFloatValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Validate.cpp:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::bitOrDouble):
(JSC::B3::testBitOrArgDouble):
(JSC::B3::testBitOrArgsDouble):
(JSC::B3::testBitOrArgImmDouble):
(JSC::B3::testBitOrImmsDouble):
(JSC::B3::bitOrFloat):
(JSC::B3::testBitOrArgFloat):
(JSC::B3::testBitOrArgsFloat):
(JSC::B3::testBitOrArgImmFloat):
(JSC::B3::testBitOrImmsFloat):
(JSC::B3::testBitOrArgsFloatWithUselessDoubleConversion):
(JSC::B3::run):
2016-12-22 Mark Lam <mark.lam@apple.com>
BytecodeGenerator::m_finallyDepth should be unsigned.
https://bugs.webkit.org/show_bug.cgi?id=166438
Reviewed by Saam Barati.
Also removed FinallyContext::m_finallyDepth because it is not used.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::labelScopeDepth):
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyContext::FinallyContext):
(JSC::FinallyContext::finallyLabel):
(JSC::FinallyContext::depth): Deleted.
2016-12-22 Mark Lam <mark.lam@apple.com>
De-duplicate finally blocks.
https://bugs.webkit.org/show_bug.cgi?id=160168
Reviewed by Saam Barati.
JS execution can arrive at a finally block when there are abrupt completions from
its try or catch block. The abrupt completion types include Break,
Continue, Return, and Throw. The non-abrupt completion type is called Normal
(i.e. the case of a try block falling through to the finally block).
Previously, we enable each of these paths for abrupt completion (except for Throw)
to run the finally block code by duplicating the finally block code at each of
the sites that trigger those completions. This patch fixes the implementation so
that each of these abrupt completions will set a completionTypeRegister (plus a
completionValueRegister for CompletionType::Return) and then jump to the
relevant finally blocks, and continue to thread through subsequent outer finally
blocks until execution reaches the outermost finally block that the completion
type dictates. We no longer duplicate the finally block code.
The implementation details:
1. We allocate a pair of registers (completionTypeRegister and completionValueRegister)
just before entering the outermost try-catch-finally scope.
On allocating the registers, we initialize the completionTypeRegister to
CompletionType::Normal, and set the completionValueRegister to the empty
JSValue.
2. The completionTypeRegister will hold a CompletionType value. This is how we
encode the CompletionType value to be set:
a. For Normal, Return, and Throw completion types:
- The completionTypeRegister is set to CompletionType::Normal,
CompletionType::Return, and CompletionType::Throw respectively.
b. For Break and Continue completion types:
- The completionTypeRegister is set to a unique jumpID where the jumpID is
computed as:
jumpID = CompletionType::NumberOfTypes + bytecodeOffset
The bytecodeOffset used here is the bytecodeOffset of the break or continue
statement that triggered this completion.
3. Each finally block will have 2 entries:
a. the catch entry.
b. the normal entry.
The catch entry is recorded in the codeBlock's exception handler table,
and can only be jumped to by the VM's exception handling mechanism.
The normal entry is recorded in a FinallyContext (at bytecode generation time
only) and is jumped to when we want enter the finally block due any of the
other CompletionTypes.
4. How each completion type works?
CompletionType::Normal
======================
We normally encounter this when falling through from a try or catch block to
the finally block.
For the try block case, since completionTypeRegister is set to Normal by default,
there's nothing more that needs to be done.
For the catch block case, since we entered the catch block with an exception,
completionTypeRegister may be set to Throw. We'll need to set it to Normal
before jumping to the finally block's normal entry.
CompletionType::Break
=====================
When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
that we need to service before jumping to the breakTarget. If we don't, then
emit op_jump to the breakTarget as usual. Otherwise:
a. we'll register a jumpID and the breakTarget with the FinallyContext for the
outermost finally block that we're supposed to run through.
b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
from the innermost to the one for that outermost finally block.
c. emit bytecode to set the completionTypeRegister to the jumpID.
d. emit bytecode to jump to the normal entry of the innermost finally block.
Each finally block will take care of cascading to the next outer finally block
as needed (see (5) below).
CompletionType::Continue
========================
Since continues and breaks work the same way (i.e. with a jump), we handle this
exactly the same way as CompletionType::Break, except that we use the
continueTarget instead of the breakTarget.
CompletionType::Return
======================
When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
at all on the m_controlFlowScopeStack. If we don't, then emit op_ret as usual.
Otherwise:
a. emit bytecode to set the completionTypeRegister to CompletionType::Return.
b. emit bytecode to move the return value into the completionValueRegister.
c. emit bytecode to jump to the normal entry of the innermost finally block.
Each finally block will take care of cascading to the next outer finally block
as needed (see (5) below).
CompletionType::Throw
======================
At the catch entry a finally block, we:
1. emit an op_catch that stores the caught Exception object in the
completionValueRegister.
2. emit bytecode to set the completionTypeRegister to CompletionType::Throw.
3. Fall through or jump to the finally block's normal entry.
5. What happens in each finally block?
==================================
For details on the finally block's catch entry, see "CompletionType::Throw" in
(4) above.
The finally block's normal entry will:
1. restore the scope of the finally block.
2. save the completionTypeRegister in a savedCompletionTypeRegister.
3. proceed to execute the body of the finally block.
At the end of the finally block, we will emit bytecode check the
savedCompletionTypeRegister for each completion type see emitFinallyCompletion())
in the following order:
a. Check for CompletionType::Normal
================================
If savedCompletionTypeRegister is CompletionType::Normal, jump to the
designated normalCompletion label. We only need this check this finally
block also needs to check for Break, Continue, or Return. If not, the
completion type check for CompletionType::Throw below will make this check
redundant.
b. Check for CompletionType::Break and Continue
============================================
If the FinallyContext for this block has registered FinallyJumps, we'll
check the jumpIDs against the savedCompletionTypeRegister. If the jumpID
matches, jump to the corresponding jumpTarget.
If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
greater than the number of registered FinallyJumps, then this means that
we have a Break or Continue that needs to be handled by an outer finally
block. In that case, jump to the next outer finally block's normal entry.
c. Check for CompletionType::Return
================================
If this finally block is not the outermost and the savedCompletionTypeRegister
is set to CompletionType::Return, then jump to the next outer finally
block's normal entry.
Otherwise, if this finally block is the outermost and the savedCompletionTypeRegister
is set to CompletionType::Return, then execute op_ret and return the value
in the completionValueRegister.
d. CompletionType::Throw
=====================
If savedCompletionTypeRegister is CompletionType::Throw, then just re-throw the
Exception object in the completionValueRegister.
Detail 1: that we check the savedCompletionTypeRegister (and not the
completionTypeRegister). This is because the finally block may itself contain
a try-finally, and this inner try-finally may have trashed the completionTypeRegister.
Here's an example:
try {
return "r1"; // Sets completionTypeRegister to CompletionType::Return;
} finally {
// completionTypeRegister is CompletionType::Return here.
try {
... // do stuff.
} finally {
... // do more stuff.
}
// completionTypeRegister may be anything here depending on what
// was executed in the inner try-finally block above.
// Hence, finally completion here must be based on a saved copy of the
// completionTypeRegister when we entered this finally block.
}
Detail 2: the finally completion for CompletionType::Throw must always explicitly
check if the savedCompletionTypeRegister is CompletionType::Throw before throwing.
We cannot imply that it is so from the Throw case being last. Here's why:
// completionTypeRegister is CompletionType::Normal here.
try {
return "r1"; // Sets completionTypeRegister to CompletionType::Return;
} finally {
// completionTypeRegister is CompletionType::Return here.
try {
... // do stuff. No abrupt completions.
} finally {
// completionTypeRegister is CompletionType::Return here (from the outer try-finally).
// savedCompletionTypeRegister is set to completionTypeRegister (i.e. CompletionType::Return) here.
... // do more stuff. No abrupt completions.
// Unless there's an abrupt completion since entering the outer
// finally block, the savedCompletionTypeRegister will remain set
// to CompletionType::Return. If we don't explicitly check if the
// savedCompletionTypeRegister is CompletionType::Throw before
// throwing here, we'll end up erroneously throwing "r1".
}
...
}
6. restoreScopeRegister()
Since the needed scope objects are always stored in a local, we can restore
the scope register by simply moving from that local instead of going through
op_get_parent_scope.
7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
This makes it easier to keep a pointer to the FinallyContext on that stack,
and not have to worry about the vector being realloc'ed due to resizing.
Performance appears to be neutral both on ES6SampleBench (run via cli) and the
JSC benchmarks.
Relevant spec references:
https://tc39.github.io/ecma262/#sec-completion-record-specification-type
https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
* bytecode/HandlerInfo.h:
(JSC::HandlerInfoBase::typeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::allocateAndEmitScope):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTry):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::restoreScopeRegister):
(JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
(JSC::BytecodeGenerator::labelScopeDepth):
(JSC::BytecodeGenerator::pushLocalControlFlowScope):
(JSC::BytecodeGenerator::popLocalControlFlowScope):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
(JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
(JSC::BytecodeGenerator::emitJumpIf):
(JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
(JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
(JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
(JSC::BytecodeGenerator::emitPopScopes): Deleted.
(JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::bytecodeOffsetToJumpID):
(JSC::FinallyJump::FinallyJump):
(JSC::FinallyContext::FinallyContext):
(JSC::FinallyContext::outerContext):
(JSC::FinallyContext::finallyLabel):
(JSC::FinallyContext::depth):
(JSC::FinallyContext::numberOfBreaksOrContinues):
(JSC::FinallyContext::incNumberOfBreaksOrContinues):
(JSC::FinallyContext::handlesReturns):
(JSC::FinallyContext::setHandlesReturns):
(JSC::FinallyContext::registerJump):
(JSC::FinallyContext::numberOfJumps):
(JSC::FinallyContext::jumps):
(JSC::ControlFlowScope::ControlFlowScope):
(JSC::ControlFlowScope::isLabelScope):
(JSC::ControlFlowScope::isFinallyScope):
(JSC::BytecodeGenerator::currentLexicalScopeIndex):
(JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
(JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
(JSC::BytecodeGenerator::completionTypeRegister):
(JSC::BytecodeGenerator::completionValueRegister):
(JSC::BytecodeGenerator::emitSetCompletionType):
(JSC::BytecodeGenerator::emitSetCompletionValue):
(JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::TryNode::emitBytecode):
2016-12-22 Saam Barati <sbarati@apple.com>
WebAssembly: Make the spec-tests/address.wast.js test pass
https://bugs.webkit.org/show_bug.cgi?id=166429
<rdar://problem/29793220>
Reviewed by Keith Miller.
Right now, provably out of bound loads/stores (given a load/store's constant
offset) are not a validation error. However, we were failing to catch uint32_t
overflows in release builds (we did have a debug assertion). To fix this,
I now detect when uint32_t addition will overflow, and instead of emitting
a normal load/store, I emit code that throws an out of bounds memory exception.
* wasm/WasmB3IRGenerator.cpp:
2016-12-22 Keith Miller <keith_miller@apple.com>
WebAssembly: The validator should not allow unused stack entries at the end of a block
https://bugs.webkit.org/show_bug.cgi?id=166411
Reviewed by Saam Barati.
This patch also cleans up some of the verbose mode logging.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::dumpExpressionStack):
(JSC::Wasm::B3IRGenerator::dump):
* wasm/WasmFunctionParser.h:
* wasm/WasmValidate.cpp:
(JSC::Wasm::dumpExpressionStack):
(JSC::Wasm::Validate::dump):
2016-12-22 Saam Barati <sbarati@apple.com>
WebAssembly: Make the spec-tests/start.wast.js test pass
https://bugs.webkit.org/show_bug.cgi?id=166416
<rdar://problem/29784532>
Reviewed by Yusuke Suzuki.
To make the test run, I had to fix two bugs:
1. We weren't properly finding the start function. There was code
that would try to find the start function from the list of *exported*
functions. This is wrong; the start function is an index into the
function index space, which is the space for *imports* and *local*
functions. So the code was just wrong in this respect, and I've
fixed it do the right thing. We weren't sure if this was originally
allowed or not in the spec, but it has been decided that it is allowed
and the spec-tests test for it: https://github.com/WebAssembly/design/issues/896
2. We were emitting a breakpoint for Unreachable. Instead of crashing,
this opcode needs to throw an exception when executing.
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmExceptionType.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h:
2016-12-21 Keith Miller <keith_miller@apple.com>
WebAssembly: Fix decode floating point constants in unreachable code
https://bugs.webkit.org/show_bug.cgi?id=166400
Reviewed by Saam Barati.
We decoded these as variable length but they should be fixed length.
* wasm/WasmFunctionParser.h:
2016-12-21 Keith Miller <keith_miller@apple.com>
WebAssembly: Allow br, br_if, and br_table to act as a return
https://bugs.webkit.org/show_bug.cgi?id=166393
Reviewed by Saam Barati.
This patch allows br, br_if, and br_table to treat branching to
the size of the control stack to act as a return. This change was
made by adding a new block type to the wasm function parser,
TopLevel. Adding this new block eliminates a lot of the special
case code we had in the parser previously. The only special case
we need is when the end opcode is parsed from the top level. The
B3 IR generator needs to automatically emit a return at that
point.
Also, this patch adds the function number to validation errors
in the function parser. The current error message is not helpful
otherwise.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::ControlData::dump):
(JSC::Wasm::B3IRGenerator::addTopLevel):
* wasm/WasmFunctionParser.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::ControlData::dump):
(JSC::Wasm::Validate::Validate):
(JSC::Wasm::Validate::addTopLevel):
(JSC::Wasm::validateFunction):
2016-12-21 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: cleanup & pass VM around to {Compile/Runtime}Error
https://bugs.webkit.org/show_bug.cgi?id=166295
<rdar://problem/29762017>
Reviewed by Mark Lam.
Rename the create* functions, and pass VM around, as suggested for
LinkError in #165805.
At the same time, use the default source appender when
constructing these error types, which gives a nice map back to the
original source as part of the error message. This is clearer when
using the current frame, so add that as well.
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromWasmThunkGenerator):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::JSWebAssemblyCompileError::create):
(JSC::createJSWebAssemblyCompileError):
(JSC::createWebAssemblyCompileError): Deleted.
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::JSWebAssemblyRuntimeError::create):
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2016-12-21 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Fix modules document in features.json
https://bugs.webkit.org/show_bug.cgi?id=166313
Reviewed by Saam Barati.
* features.json:
2016-12-20 Taras Tsugrii <ttsugrii@fb.com>
Fix undefined behavior caused by macro expansion producing 'defined'
https://bugs.webkit.org/show_bug.cgi?id=166047
Reviewed by Darin Adler.
* API/JSBase.h:
2016-12-20 Keith Miller <keith_miller@apple.com>
Add support for global
https://bugs.webkit.org/show_bug.cgi?id=165171
Reviewed by Filip Pizlo.
This patch adds spport for the global property on the global object.
The global property spec is in stage three and is quite simple.
For reference: http://tc39.github.io/proposal-global/
* runtime/JSGlobalObject.cpp:
2016-12-20 Saam Barati <sbarati@apple.com>
WebAssembly: We should compile wasm functions in parallel
https://bugs.webkit.org/show_bug.cgi?id=165993
Reviewed by Keith Miller.
This patch adds a very simple parallel compiler for Wasm code.
This patch speeds up compiling the Unity headless benchmark by
slightly more than 4x on my MBP. To make this safe, I perform
all linking on the main thread. I also had to change some code
inside Wasmb3IRGenerator to be thread safe.
* b3/air/AirCustom.h:
(JSC::B3::Air::WasmBoundsCheckCustom::generate):
* b3/air/AirGenerationContext.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::emitExceptionCheck):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::setupFrameInPrologue):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
2016-12-20 Brent Fulgham <bfulgham@apple.com>
Address some style problems found by static analysis
https://bugs.webkit.org/show_bug.cgi?id=165975
Reviewed by Alex Christensen.
Correct the const-correctness of functions that are implemented using stricter
const declarations.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorHeapAgent.cpp:
* inspector/agents/InspectorHeapAgent.h:
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/scripts/codegen/cpp_generator.py:
(cpp_type_for_unchecked_formal_in_parameter): Update to match const declarations of
implementation files.
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
Rebaselined results for "const Ptr* const" syntax.
2016-12-20 JF Bastien <jfbastien@apple.com>
WebAssembly: construct 32-bit encodedJSValue properly
https://bugs.webkit.org/show_bug.cgi?id=166199
Reviewed by Mark Lam.
Constructing an encodedJSValue using `{ }` yields the wrong value
on 32-bit platforms. WebAssembly doesn't currently target 32-bit
platforms, but we may as well get it right.
* wasm/JSWebAssembly.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::webAssemblyValidateFunc):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::toNonWrappingUint32):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::webAssemblyTableProtoFuncLength):
(JSC::webAssemblyTableProtoFuncGrow):
(JSC::webAssemblyTableProtoFuncGet):
(JSC::webAssemblyTableProtoFuncSet):
2016-12-20 Dean Jackson <dino@apple.com>
Remove INDIE_UI
https://bugs.webkit.org/show_bug.cgi?id=165881
<rdar://problem/29672532>
Reviewed by Simon Fraser.
The Indie UI work has been discontinued.
* Configurations/FeatureDefines.xcconfig:
2016-12-20 JF Bastien <jfbastien@apple.com>
WebAssembly API: implement WebAssembly.LinkError
https://bugs.webkit.org/show_bug.cgi?id=165805
<rdar://problem/29747874>
Reviewed by Mark Lam.
As described here: https://github.com/WebAssembly/design/pull/901
Some TypeError and RangeError are now converted to WebAssembly.LinkError.
* CMakeLists.txt: add files
* DerivedSources.make: add autoget .lut.h files
* JavaScriptCore.xcodeproj/project.pbxproj: add files
* builtins/BuiltinNames.h: new name LinkError
* runtime/JSGlobalObject.h: auto-register LinkError using existing macro magic
* wasm/JSWebAssembly.h: make the new includes available
* wasm/js/JSWebAssemblyLinkError.cpp: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.cpp.
(JSC::JSWebAssemblyLinkError::create):
(JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
(JSC::createWebAssemblyLinkError):
* wasm/js/JSWebAssemblyLinkError.h: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.h.
(JSC::JSWebAssemblyLinkError::create):
* wasm/js/WebAssemblyInstanceConstructor.cpp: update as per spec change
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.cpp.
(JSC::constructJSWebAssemblyLinkError):
(JSC::callJSWebAssemblyLinkError):
(JSC::WebAssemblyLinkErrorConstructor::create):
(JSC::WebAssemblyLinkErrorConstructor::createStructure):
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
(JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
(JSC::WebAssemblyLinkErrorConstructor::getConstructData):
(JSC::WebAssemblyLinkErrorConstructor::getCallData):
* wasm/js/WebAssemblyLinkErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.h.
* wasm/js/WebAssemblyLinkErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.cpp.
(JSC::WebAssemblyLinkErrorPrototype::create):
(JSC::WebAssemblyLinkErrorPrototype::createStructure):
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
(JSC::WebAssemblyLinkErrorPrototype::WebAssemblyLinkErrorPrototype):
* wasm/js/WebAssemblyLinkErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.h.
* wasm/js/WebAssemblyModuleRecord.cpp: update as per spec change
(JSC::dataSegmentFail):
(JSC::WebAssemblyModuleRecord::evaluate):
2016-12-20 JF Bastien <jfbastien@apple.com>
WebAssembly: unique function signatures
https://bugs.webkit.org/show_bug.cgi?id=165957
<rdar://problem/29735737>
Reviewed by Saam Barati.
Signatures in a Module's Type section can be duplicated, we
therefore need to unique them so that call_indirect only needs to
do a single integer compare to check that a callee's Signature is
the same as the Signature declared at the call site. Without
uniquing we'd either trap when duplicate Signatures are used, or
we'd need to do multiple comparisons. This patch makes that narrow
usecase function correctly.
There's further complication when calling from wasm to
wasm, in which case the Signatures must also match. Such
cross-instance calls will be improved in bug #165282, but this
patch sets the groundwork for it:
- Signatures are now owned by SignatureInformation which lives on
VM, and is shared by all Modules.
- When parsing a Module, a Signature is created for every Type
entry, and then uniqued by SignatureInformation's adopt
method. Duplicate Signatures are dropped and the previous
SignatureIndex is returned, new Signatures are adopted and a new
SignatureIndex is created.
- The SignatureIndex values are monotonic. 0 is used to represent
invalid indices, which trap. This can only occur through Table.
- SignatureInformation is used while generating code to map a
SignatureIndex back to the Signature* when return / argument
information is needed. This is a simple lookup into a Vector. It
isn't used at runtime.
- These Signatures live forever on VM because the bookkeeping
likely isn't worth it. We may want to empty things out if all
Modules die, this is tracked in bug #166037.
- We can further improve things by bit-packing SignatureIndex with
Code*, which is tracked by bug #165511.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/VM.h: wasm signatures are uniqued here, but aren't accessed frequently (only during parsing) so indirection is fine
* wasm/WasmB3IRGenerator.cpp: use SignatureIndex instead of Signature* when appropriate, and when still using Signature* do so with its new API
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmBinding.cpp:
(JSC::Wasm::importStubGenerator): use SignatureIndex
* wasm/WasmBinding.h:
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::loadArguments):
* wasm/WasmFormat.cpp: drive-by move of alloc/free functions to the implementation file, allows the .h file to drop an FastMalloc.h
(JSC::Wasm::Segment::create):
(JSC::Wasm::Segment::destroy):
(JSC::Wasm::Segment::createPtr):
* wasm/WasmFormat.h: move Signature to its own file
(JSC::Wasm::CallableFunction::CallableFunction):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::Parser):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmSignature.cpp: Added.
(JSC::Wasm::Signature::dump):
(JSC::Wasm::Signature::hash):
(JSC::Wasm::Signature::create):
(JSC::Wasm::Signature::createInvalid):
(JSC::Wasm::Signature::destroy):
(JSC::Wasm::SignatureInformation::~SignatureInformation):
(JSC::Wasm::SignatureInformation::adopt):
(JSC::Wasm::SignatureInformation::get):
* wasm/WasmSignature.h: Added.
(JSC::Wasm::Signature::Signature):
(JSC::Wasm::Signature::storage):
(JSC::Wasm::Signature::allocatedSize):
(JSC::Wasm::Signature::returnType):
(JSC::Wasm::Signature::returnCount):
(JSC::Wasm::Signature::argumentCount):
(JSC::Wasm::Signature::argument):
(JSC::Wasm::Signature::operator==):
(JSC::Wasm::SignatureHash::empty):
(JSC::Wasm::SignatureHash::deleted):
(JSC::Wasm::SignatureHash::SignatureHash):
(JSC::Wasm::SignatureHash::operator==):
(JSC::Wasm::SignatureHash::equal):
(JSC::Wasm::SignatureHash::hash):
(JSC::Wasm::SignatureHash::isHashTableDeletedValue):
* wasm/WasmValidate.cpp:
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::clearFunction):
(JSC::JSWebAssemblyTable::setFunction):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::call):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::signatureIndex):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
2016-12-20 Konstantin Tokarev <annulen@yandex.ru>
Modernize for loops in JSC
https://bugs.webkit.org/show_bug.cgi?id=166060
Reviewed by Yusuke Suzuki.
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::tallyFrequentExitSites):
(JSC::CodeBlock::nameForRegister):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue):
* debugger/Debugger.cpp:
(JSC::Debugger::applyBreakpoints):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
* dfg/DFGClobberSet.cpp:
(JSC::DFG::ClobberSet::setOf):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::visitChildren):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::linkBranches):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* dfg/DFGValidate.cpp:
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::VirtualRegisterAllocationPhase::run):
* heap/HeapVerifier.cpp:
(JSC::trimDeadObjectsFromList):
(JSC::HeapVerifier::trimDeadObjects):
* heap/LiveObjectList.cpp:
(JSC::LiveObjectList::findObject):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::isPagedOut):
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::firstNonNativeCallFrame):
* jit/JIT.cpp:
(JSC::JIT::link):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::markAllVariablesAsCaptured):
(JSC::VariableEnvironment::hasCapturedVariables):
* runtime/FunctionHasExecutedCache.cpp:
(JSC::FunctionHasExecutedCache::hasExecutedAtOffset):
(JSC::FunctionHasExecutedCache::getFunctionRanges):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::visitChildren):
* runtime/TypeProfiler.cpp:
(JSC::TypeProfiler::findLocation):
* runtime/TypeSet.cpp:
(JSC::TypeSet::addTypeInformation):
(JSC::TypeSet::dumpTypes):
* runtime/VM.cpp:
(JSC::VM::gatherConservativeRoots):
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
(JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
* tools/ProfileTreeNode.h:
(JSC::ProfileTreeNode::dumpInternal):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::emitDisjunction):
2016-12-20 Konstantin Tokarev <annulen@yandex.ru>
__cpuid() requires <intrin.h> to be included
https://bugs.webkit.org/show_bug.cgi?id=166051
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerX86Common.h:
2016-12-19 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Enable ES6 Modules
https://bugs.webkit.org/show_bug.cgi?id=165849
Reviewed by Geoffrey Garen.
* features.json:
2016-12-19 Mark Lam <mark.lam@apple.com>
Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
https://bugs.webkit.org/show_bug.cgi?id=166049
Not reviewed.
* bytecode/HandlerInfo.h:
(JSC::HandlerInfoBase::typeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::labelScopeDepth):
(JSC::BytecodeGenerator::pushLocalControlFlowScope):
(JSC::BytecodeGenerator::popLocalControlFlowScope):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::popTry): Deleted.
(JSC::BytecodeGenerator::emitCatch): Deleted.
(JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
(JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
(JSC::BytecodeGenerator::emitIsNumber): Deleted.
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
(JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
(JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
(JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
(JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::isInFinallyBlock):
(JSC::FinallyJump::FinallyJump): Deleted.
(JSC::FinallyContext::FinallyContext): Deleted.
(JSC::FinallyContext::outerContext): Deleted.
(JSC::FinallyContext::finallyLabel): Deleted.
(JSC::FinallyContext::depth): Deleted.
(JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
(JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
(JSC::FinallyContext::handlesReturns): Deleted.
(JSC::FinallyContext::setHandlesReturns): Deleted.
(JSC::FinallyContext::registerJump): Deleted.
(JSC::FinallyContext::numberOfJumps): Deleted.
(JSC::FinallyContext::jumps): Deleted.
(JSC::ControlFlowScope::ControlFlowScope): Deleted.
(JSC::ControlFlowScope::isLabelScope): Deleted.
(JSC::ControlFlowScope::isFinallyScope): Deleted.
(JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
(JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
(JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
(JSC::BytecodeGenerator::finallyActionRegister): Deleted.
(JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
(JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::TryNode::emitBytecode):
2016-12-19 Mark Lam <mark.lam@apple.com>
Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
https://bugs.webkit.org/show_bug.cgi?id=166049
Not reviewed.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::allocateFinallyRegisters):
(JSC::BytecodeGenerator::releaseFinallyRegisters):
(JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
(JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
(JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
(JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyJump::FinallyJump):
(JSC::FinallyContext::registerJump):
(JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
(JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
(JSC::BytecodeGenerator::finallyActionRegister):
(JSC::BytecodeGenerator::finallyReturnValueRegister):
(JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
(JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
(JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
(JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
(JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
(JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
(JSC::bytecodeOffsetToJumpID): Deleted.
(JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
(JSC::BytecodeGenerator::completionTypeRegister): Deleted.
(JSC::BytecodeGenerator::completionValueRegister): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
(JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2016-12-19 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
https://bugs.webkit.org/show_bug.cgi?id=166034
<rdar://problem/29554366>
Reviewed by Brian Burg.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::refAsyncCallData):
Remove assertion. This assert can happen if the currently executing callback
was just explicitly cancelled by script. Existing code already handles if
no async data was found for the given identifier.
2016-12-18 Saam Barati <sbarati@apple.com>
WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
https://bugs.webkit.org/show_bug.cgi?id=165936
Reviewed by Mark Lam.
The APIs are documented here:
- https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
- https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate
* wasm/JSWebAssembly.cpp:
(JSC::webAssemblyCompileFunc):
(JSC::webAssemblyValidateFunc):
(JSC::JSWebAssembly::finishCreation):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::parseAndValidateModule):
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::getWasmBufferFromValue):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::callJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyModuleConstructor.h:
2016-12-18 Mark Lam <mark.lam@apple.com>
Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
https://bugs.webkit.org/show_bug.cgi?id=165979
Reviewed by Saam Barati.
This patch makes it so that we only store int JSValues in the finallyActionRegister
thereby making type prediction on this register more successful for JITs. In so
doing, we are able to get some additional benefits:
1. Renamed the following:
FinallyRegistersScope => CompletionRecordScope
finallyActionRegister => completionTypeRegister
finallyReturnValueRegister => completionValueRegister
These new names are more in line with the ES spec, which describes these
values as the completion record and its type and value properties.
https://tc39.github.io/ecma262/#sec-completion-record-specification-type
2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
(in our implementation of completion type). As a result, we only need one of
each of the emitter methods for getting, setting, and compare-and-jump on the
completion type. The code using these methods also reads much clearer now.
3. Finally blocks' op_catch should now always pop the caught Exception object into
the completionValueRegister instead of the completionTypeRegister (formerly
finallyActionRegister).
Also removed the restoreScopeRegister() call in the IteratorClose catch block
because that is an implementation specific synthesized catch block, and we
can guarantee that it never needs to resolve any symbols from the scope. Hence,
there is no need to restore the scope register.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
(JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
(JSC::BytecodeGenerator::emitJumpIfCompletionType):
(JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
(JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
(JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::bytecodeOffsetToJumpID):
(JSC::FinallyJump::FinallyJump):
(JSC::FinallyContext::registerJump):
(JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
(JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
(JSC::BytecodeGenerator::completionTypeRegister):
(JSC::BytecodeGenerator::completionValueRegister):
(JSC::BytecodeGenerator::emitSetCompletionType):
(JSC::BytecodeGenerator::emitSetCompletionValue):
(JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
(JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
(JSC::BytecodeGenerator::finallyActionRegister): Deleted.
(JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
(JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
(JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
(JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2016-12-17 Saam Barati <sbarati@apple.com>
WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
https://bugs.webkit.org/show_bug.cgi?id=165989
Reviewed by Mark Lam.
The input should be constrained to a register to match what
the patchpoint code expects.
* wasm/WasmB3IRGenerator.cpp:
2016-12-17 Saam Barati <sbarati@apple.com>
WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
https://bugs.webkit.org/show_bug.cgi?id=165990
Reviewed by Mark Lam.
* wasm/WasmBinding.cpp:
(JSC::Wasm::importStubGenerator):
2016-12-16 Joseph Pecoraro <pecoraro@apple.com>
JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
https://bugs.webkit.org/show_bug.cgi?id=165986
<rdar://problem/29551379>
Reviewed by Matt Baker.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype.processProperties):
Prefer String.prototype.endsWith now that it is available.
(InjectedScript.prototype._describe):
Prefer Function.prototype.toString for converting functions to String.
Previously we were doing String(f) which would to Symbol.toPrimitive
conversion which seems unnecessary here.
2016-12-16 Michael Catanzaro <mcatanzaro@igalia.com>
Unreviewed, fix GCC 6 build failure after r209952
Return false, not nullptr, in function returning bool.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2016-12-16 Saam Barati <sbarati@apple.com>
WebAssembly: We still have some incorrect parsing productions inside unreachable code
https://bugs.webkit.org/show_bug.cgi?id=165981
Reviewed by Keith Miller.
This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
It also fixes a more nefarious bug in which we were decoding an extra varuint32
for Br/BrIf inside unreachable code.
* wasm/WasmFunctionParser.h:
2016-12-16 Filip Pizlo <fpizlo@apple.com>
CellState should have members with accurate names
https://bugs.webkit.org/show_bug.cgi?id=165969
Reviewed by Mark Lam.
This once again renames the members in CellState. I wanted to convey the following
pieces of information in the names:
- What does the state mean for Generational GC?
- What does the state mean for Concurrent GC?
- Does the state guarantee what it means, or is there some contingency?
The names I came up with are:
PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
other things. If the mark bit is set then the object is either black or being
blackened as we speak. It's going to survive the GC, so it will be old, but may be
new now. In between GCs, objects in this state are definitely old. If the mark bit
is not set, then the object is actually old and white.
DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
new.
DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
may be new or old depending on other things.
* heap/CellState.h:
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::writeBarrierSlowPath):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
* runtime/StructureIDBlob.h:
(JSC::StructureIDBlob::StructureIDBlob):
2016-12-16 Saam Barati <sbarati@apple.com>
B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
https://bugs.webkit.org/show_bug.cgi?id=165946
Reviewed by Keith Miller.
This was happening because the phase will convert some Phi nodes
from Double to Float. However, one place that did this conversion
forgot to first check if the Phi was already a Float. If it's already
a Float, a later part of the phase will be buggy if the phase claims that it has
converted it from Double->Float. The reason is that at the end of the
phase, we'll look for all uses of former Double Phi nodes and make them
be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
This is clearly wrong if the Phi were Float to begin with (and
therefore, the uses were Float uses to begin with).
* b3/B3ReduceDoubleToFloat.cpp:
* b3/testb3.cpp:
(JSC::B3::testReduceFloatToDoubleValidates):
(JSC::B3::run):
2016-12-16 Mark Lam <mark.lam@apple.com>
De-duplicate finally blocks.
https://bugs.webkit.org/show_bug.cgi?id=160168
Reviewed by Keith Miller.
JS execution can arrive at a finally block when there are abrupt completions from
its try or catch block. The abrupt completion types include Break,
Continue, Return, and Throw. The non-abrupt completion type is called Normal
(i.e. the case of a try block falling through to the finally block).
Previously, we enable each of these paths for abrupt completion (except for Throw)
to run the finally block code by duplicating the finally block code at each of
the sites that trigger those completions. This patch fixes the implementation so
that each of these abrupt completions will set a finallyActionRegister (plus a
finallyReturnValueRegister for CompletionType::Return) and then jump to the
relevant finally blocks, and continue to thread through subsequent outer finally
blocks until execution reaches the outermost finally block that the completion
type dictates. We no longer duplicate the finally block code.
The implementation details:
1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
just before entering the outermost try-catch-finally scope.
On allocating the registers, we set them to the empty JSValue. This serves
to set the completion type to CompletionType::Normal (see (2) below).
2. The finallyActionRegister serves 2 purpose:
a. indicates the CompletionType that triggered entry into the finally block.
This is how we encode the completion type in the finallyActionRegister:
1. CompletionType::Normal
- finallyActionRegister is set to the empty JSValue.
2. CompletionType::Break
- finallyActionRegister is set to the int jumpID for the site of the break statement.
3. CompletionType::Continue
- finallyActionRegister is set to the int jumpID for the site of the continue statement.
4. CompletionType::Return
- finallyActionRegister is set to CompletionType::Return as an int JSValue.
- finallyReturnValueRegister is set to the value to be returned.
5. CompletionType::Throw
- finallyActionRegister is set to the exception object that was caught by the finally block.
Hence, if the finallyActionRegister can either be:
1. empty i.e. we're handling CompletionType::Normal.
2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
3. an object i.e. we're handling CompletionType::Throw.
b. stores the exception caught in the finally block if we're handing
CompletionType::Throw.
3. Each finally block will have 2 entries:
a. the entry via throw.
b. the normal entry.
The entry via throw is recorded in the codeBlock's exception table, and can
only be jumped to by the VM's exception handling mechanism.
The normal entry is recorded in a FinallyContext (at bytecode generation time
only) and is jumped to when we want enter the finally block due any of the
other CompletionTypes.
4. CompletionType::Normal
======================
We encounter this when falling through from a try or catch block to the finally block.
For the try block case, since finallyActionRegister is set to Normal by default,
there's nothing more that needs to be done.
For the catch block case, since we entered the catch block with an exception,
finallyActionRegister may be set to Throw. We'll need to set it to Normal
before jumping to the finally block's normal entry.
CompletionType::Break
=====================
When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
that we need to service before jumping to the breakTarget. If we do, then:
a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
from the innermost to the outermost.
c. instead of emitting bytecode to jump to the breakTarget, we:
1. emit bytecode to set finallyActionRegister to the jumpID.
b. emit bytecode to jump to the normal entry of the innermost finally block.
Each finally block will take care of cascading to the next outer finally block
as needed (see (5) below).
CompletionType::Continue
========================
Since continues and breaks work the same way (i.e. with a jump), we handle this
exactly the same way as CompletionType::Break, except that we use the
continueTarget instead of the breakTarget.
CompletionType::Return
======================
When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
at all on the m_controlFlowScopeStack.
If so, then instead of emitting op_ret, we:
1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
1. emit bytecode to move the return value into finallyReturnValueRegister.
2. emit bytecode to jump to the normal entry of the innermost finally block.
Each finally block will take care of cascading to the next outer finally block
as needed (see (5) below).
CompletionType::Throw
======================
The op_catch of a finally block will always store the caught exception object
in the finallyActionRegister. This means we're handling CompletionType::Throw
(see (2) above).
5. What happens in each finally block?
==================================
Only the finally block's entry via throw will have an op_catch that catches the
pending exception (and stores it in the finallyActionRegister). This throw
entry then falls through to the normal entry.
The finally block's normal entry will restore the scope of the finally block
and proceed to execute its code.
At the end of the finally block (see emitFinallyCompletion()), the finally
block will check the finallyActionRegister for each completion type in the
following order:
a. CompletionType::Normal: jump to the code after the finally block as
designated by a normalCompletion label.
b. CompletionType::Break and Continue:
If the FinallyContext for this block has registered FinallyJumps, we'll
check for the jumpIDs against the finallyActionRegister. If the jumpID
matches, jump to the corresponding jumpTarget.
If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
greater than the number of registered FinallyJumps, then this means that
we have a Break or Continue that needs to be handled by an outer finally
block. In that case, jump to the outer finally block's normal entry.
c. CompletionType::Return:
If this finally block is not the outermost and finallyActionRegister contains
CompletionType::Return, then jump to the outer finally block's normal entry.
Otherwise, if this finally block is the outermost and finallyActionRegister
contains CompletionType::Return, then execute op_ret and return the value
in finallyReturnValueRegister.
d. CompletionType::Throw:
If we're not handling any of the above cases, then just throw the
finallyActionRegister which contains the exception to re-throw.
6. restoreScopeRegister()
Since the needed scope objects are always stored in a local, we can restore
the scope register by simply moving from that local instead of going through
op_get_parent_scope.
7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
This makes it easier to keep a pointer to the FinallyContext on that stack,
and not have to worry about the vector being realloc'ed due to resizing.
Performance appears to be neutral both on ES6SampleBench (run via cli) and the
JSC benchmarks.
Relevant spec references:
https://tc39.github.io/ecma262/#sec-completion-record-specification-type
https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
* bytecode/HandlerInfo.h:
(JSC::HandlerInfoBase::typeName):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitReturn):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::allocateAndEmitScope):
(JSC::BytecodeGenerator::pushTry):
(JSC::BytecodeGenerator::popTry):
(JSC::BytecodeGenerator::emitCatch):
(JSC::BytecodeGenerator::restoreScopeRegister):
(JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
(JSC::BytecodeGenerator::labelScopeDepth):
(JSC::BytecodeGenerator::pushLocalControlFlowScope):
(JSC::BytecodeGenerator::popLocalControlFlowScope):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIsNumber):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::allocateFinallyRegisters):
(JSC::BytecodeGenerator::releaseFinallyRegisters):
(JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
(JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
(JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
(JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
(JSC::BytecodeGenerator::emitPopScopes): Deleted.
(JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::FinallyJump::FinallyJump):
(JSC::FinallyContext::FinallyContext):
(JSC::FinallyContext::outerContext):
(JSC::FinallyContext::finallyLabel):
(JSC::FinallyContext::depth):
(JSC::FinallyContext::numberOfBreaksOrContinues):
(JSC::FinallyContext::incNumberOfBreaksOrContinues):
(JSC::FinallyContext::handlesReturns):
(JSC::FinallyContext::setHandlesReturns):
(JSC::FinallyContext::registerJump):
(JSC::FinallyContext::numberOfJumps):
(JSC::FinallyContext::jumps):
(JSC::ControlFlowScope::ControlFlowScope):
(JSC::ControlFlowScope::isLabelScope):
(JSC::ControlFlowScope::isFinallyScope):
(JSC::BytecodeGenerator::currentLexicalScopeIndex):
(JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
(JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
(JSC::BytecodeGenerator::finallyActionRegister):
(JSC::BytecodeGenerator::finallyReturnValueRegister):
(JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
(JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
(JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
(JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
(JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
(JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
(JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
(JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::TryNode::emitBytecode):
2016-12-16 Keith Miller <keith_miller@apple.com>
Add missing cases to parseUnreachableExpression and cleanup FunctionParser
https://bugs.webkit.org/show_bug.cgi?id=165966
Reviewed by Saam Barati.
This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
code decoder. It also, removes unneeded OpType namespaces where they were not
needed and has the unary / binary macros cover all the cases rather than
just the simple cases.
* wasm/WasmFunctionParser.h:
2016-12-16 Mark Lam <mark.lam@apple.com>
Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
https://bugs.webkit.org/show_bug.cgi?id=165958
Reviewed by Saam Barati.
Also:
1. refactored the code to use a common lambda function to dump FastBitVectors.
2. list successors by their block index instead of pointers.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::dumpResults):
2016-12-16 Saam Barati <sbarati@apple.com>
WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
https://bugs.webkit.org/show_bug.cgi?id=165834
Reviewed by Keith Miller.
This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
There are still places where we need to throw exceptions and we don't, but
this patch removes most of those places inside the IR generator. There are
still a few places we need to throw exceptions inside the IR generator, like
div/mod by 0. Those will be done in a separate patch. Also, there are
still some stubs we need to throw exceptions from; those will also be
done in a separate patch.
All exceptions thrown from Wasm share a common stub. The ABI for the stub
is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
The stub will then throw an exception with an error message tailored
to the particular Wasm::ExceptionType failure.
This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
constructor would compile a B3 function. This patch makes B3::Compilation a simple
tuple that keeps the necessary bits of B3 function alive in order to be runnable.
There is a new function that actually does the compilation for you. It is:
Compilation B3::compile(VM&, Procedure&)
The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
constructor in Wasm code. It is weird to have a class both have a
constructor that instantiates the tuple, and another that performs the
compilation and then instantiates the tuple. It's more straight
forward if Compilation's job wasn't to actually do the compilation
but just to hold the necessary bits to keep a compiled B3 alive.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Compilation.cpp:
(JSC::B3::Compilation::Compilation):
* b3/B3Compilation.h:
* b3/B3Compile.cpp: Added.
(JSC::B3::compile):
* b3/B3Compile.h: Added.
* b3/testb3.cpp:
(JSC::B3::compile):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromWasmThunkGenerator):
* jit/ThunkGenerators.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::emitExceptionCheck):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmExceptionType.h: Added.
(JSC::Wasm::errorMessageForExceptionType):
2016-12-16 Keith Miller <keith_miller@apple.com>
i64.eqz should use an Int64 zero
https://bugs.webkit.org/show_bug.cgi?id=165942
Reviewed by Mark Lam.
This patch fixes i64.eqz, which was using an Int32 zero
for the comparison previously. This patch also, adds
printing opcodes names in verbose mode.
* wasm/WasmFunctionParser.h:
* wasm/generateWasmOpsHeader.py:
* wasm/wasm.json:
2016-12-15 Darin Adler <darin@apple.com>
Use asString instead of toWTFString, toString, or getString when we already checked isString
https://bugs.webkit.org/show_bug.cgi?id=165895
Reviewed by Yusuke Suzuki.
Once we have called isString, we should always use asString and value rather than using
functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
slightly less reference count churn, since the string is stored right inside the JSString,
and obviates the need for exception handling.
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue): Use asString/value instead of getString.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
of toWTFString.
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
peculiar getString(nullptr) that was here before.
* jsc.cpp:
(functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
toWTFString/Identifier::fromString.
(functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
prefer the asString function, since it exists.
(functionFindTypeForExpression): Use asString/value instead of getString.
(functionHasBasicBlockExecuted): Ditto.
(functionBasicBlockExecutionCount): Ditto.
(functionCreateBuiltin): Use asString/value instead of toWTFString and removed
unneeded RETURN_IF_EXCEPTION.
(valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
(box): Ditto.
* runtime/DateConstructor.cpp:
(JSC::constructDate): Use asString/values instead of getString.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue): Tweaked formatting.
* runtime/HashMapImpl.h:
(JSC::jsMapHash): Changed this function to use asString/value.
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
jsCast<JSString*>.
(JSC::JSValue::dumpForBacktrace): Ditto.
* runtime/JSCJSValueInlines.h:
(JSC::toPreferredPrimitiveType): Ditto.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval): Use asString/value instead of toWTFString.
* runtime/JSString.cpp:
(JSC::JSString::destroy): Streamlined by removing local variable.
(JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
(JSC::JSString::visitChildren): Ditto.
(JSC::JSString::toThis): Ditto.
* runtime/JSString.h:
(JSC::JSValue::toString): Ditto.
(JSC::JSValue::toStringOrNull): Ditto.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncValueOf): Ditto.
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString): Ditto.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter): Ditto.
(JSC::stringProtoFuncSubstr): Ditto.
(JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.
2016-12-15 Keith Miller <keith_miller@apple.com>
Fix validation of non-void if blocks with no else
https://bugs.webkit.org/show_bug.cgi?id=165938
Reviewed by Saam Barati.
We should not have been allowing non-void if-blocks that don't
have an else. Since this causes a value to be placed on the
stack that only appears under some control flow and not another.
* wasm/WasmValidate.cpp:
2016-12-15 Filip Pizlo <fpizlo@apple.com>
Get rid of HeapRootVisitor and make SlotVisitor less painful to use
https://bugs.webkit.org/show_bug.cgi?id=165911
Reviewed by Geoffrey Garen.
Previously we had two ways of adding a raw pointer to the GC's mark stack:
- SlotVisitor::appendUnbarrieredXYZ() methods
- HeapRootVisitor::visit() methods
HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
unless you had permission. But SlotVisitor would let you do it anyway, because that was
a lot more practical.
I think that we should just have one way to do it. This removes HeapRootVisitor. It
also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/builtins/builtins_templates.py:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitWeakly):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::stronglyVisitWeakReferences):
* bytecode/DirectEvalCodeCache.cpp:
(JSC::DirectEvalCodeCache::visitAggregate):
* bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::visitAggregate):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::visitAggregate):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::propagateTransitions):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildren):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildren):
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::visitChildren):
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::visitChildren):
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::visitChildren):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::visitChildren):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::markCodeBlocks):
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
* heap/HandleSet.cpp:
(JSC::HandleSet::visitStrongHandles):
* heap/HandleSet.h:
* heap/HandleStack.cpp:
(JSC::HandleStack::visit):
* heap/HandleStack.h:
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint):
* heap/Heap.h:
* heap/HeapRootVisitor.h: Removed.
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::visitWeakSet):
* heap/LargeAllocation.h:
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::visitWeakSet):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::visitWeakSets):
* heap/MarkedSpace.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendUnbarriered):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::appendUnbarriered):
(JSC::SlotVisitor::append):
(JSC::SlotVisitor::appendHidden):
(JSC::SlotVisitor::appendValues):
(JSC::SlotVisitor::appendValuesHidden):
(JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
(JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
(JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
(JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
(JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
* heap/WeakBlock.cpp:
(JSC::WeakBlock::specializedVisit):
(JSC::WeakBlock::visit):
* heap/WeakBlock.h:
* heap/WeakSet.h:
(JSC::WeakSet::visit):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::visitChildren):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
* jsc.cpp:
(WTF::Element::visitChildren):
(WTF::ImpureGetter::visitChildren):
(WTF::SimpleObject::visitChildren):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::visitChildren):
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::markLists):
* runtime/ArgList.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::visitChildren):
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::visitChildren):
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::visitChildren):
* runtime/Exception.cpp:
(JSC::Exception::visitChildren):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::visitChildren):
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::visitChildren):
* runtime/GetterSetter.cpp:
(JSC::GetterSetter::visitChildren):
* runtime/HashMapImpl.cpp:
(JSC::HashMapBucket<Data>::visitChildren):
(JSC::HashMapImpl<HashMapBucket>::visitChildren):
* runtime/InferredTypeTable.cpp:
(JSC::InferredTypeTable::visitChildren):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::visitChildren):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::visitChildren):
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::visitChildren):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::visitChildren):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::visitChildren):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::visitChildren):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::visitChildren):
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::visitChildren):
* runtime/JSCallee.cpp:
(JSC::JSCallee::visitChildren):
* runtime/JSCellInlines.h:
(JSC::JSCell::visitChildren):
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSCustomGetterSetterFunction::visitChildren):
* runtime/JSFunction.cpp:
(JSC::JSFunction::visitChildren):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::visitChildren):
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::visitChildren):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::visitChildren):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::visitChildren):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildren):
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::visitChildren):
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterflyImpl):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::visitChildren):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::visitChildren):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::visitChildren):
* runtime/JSProxy.cpp:
(JSC::JSProxy::visitChildren):
* runtime/JSScope.cpp:
(JSC::JSScope::visitChildren):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildren):
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::visitChildren):
* runtime/JSString.cpp:
(JSC::JSRopeString::visitFibers):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::visitChildren):
* runtime/JSWeakMap.cpp:
(JSC::JSWeakMap::visitChildren):
* runtime/JSWeakSet.cpp:
(JSC::JSWeakSet::visitChildren):
* runtime/JSWithScope.cpp:
(JSC::JSWithScope::visitChildren):
* runtime/JSWrapperObject.cpp:
(JSC::JSWrapperObject::visitChildren):
* runtime/LazyClassStructure.cpp:
(JSC::LazyClassStructure::visit):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::visit):
* runtime/MapBase.cpp:
(JSC::MapBase<HashMapBucketType>::visitChildren):
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::visitChildren):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor::visitChildren):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::visitChildren):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::visitChildren):
* runtime/ProxyRevoke.cpp:
(JSC::ProxyRevoke::visitChildren):
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitChildren):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::visitChildren):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::visitChildren):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::visit):
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::visitChildren):
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::visitStrongReferences):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::visitChildren):
* runtime/Structure.cpp:
(JSC::Structure::visitChildren):
(JSC::Structure::markIfCheap):
* runtime/StructureChain.cpp:
(JSC::StructureChain::visitChildren):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::visitChildren):
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::visit):
* runtime/WeakMapData.cpp:
(JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::visitChildren):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::visitChildren):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::visitChildren):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::visitChildren):
2016-12-15 Myles C. Maxfield <mmaxfield@apple.com>
Sort Xcode project files
https://bugs.webkit.org/show_bug.cgi?id=165937
Reviewed by Simon Fraser.
* JavaScriptCore.xcodeproj/project.pbxproj:
2016-12-15 Keith Miller <keith_miller@apple.com>
Wasm should not create empty unlinked callsites
https://bugs.webkit.org/show_bug.cgi?id=165933
Reviewed by Mark Lam.
Wasm would create holes in the unlinked callsite vector if B3 was able to
eliminate the callsite.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCall):
2016-12-15 JF Bastien <jfbastien@apple.com>
WebAssembly: improve compilation error messages
https://bugs.webkit.org/show_bug.cgi?id=163919
Reviewed by Saam Barati.
The error handling messages were underwhelming because most
locations merely returned `false` on failure. This patch uses
std::expected to denote that failure isn't expected. Doing this
makes it almost impossible to mess up the code: either a function
returns a result (or a partial result for internal helpers) or an
error. We're not synchronizing the error string with the m_failed
bool anymore, and the caller will abort if they try to get a
result but the outcome was an error.
This also shortens the code significantly using macros, while also
judiciously preventing inlining of error handling code and biasing
towards success using UNLIKELY. This means that the generated code
should be more efficient (no string formatting on success, and
regalloc can avoid these unlikely paths).
The patch adds a few missing checks as well, especially related to
count limits and memory allocation failure.
As a follow-up I'd like to improve WTF::makeString further, so it
does coercions to string and understands ADL as I did in this
patch.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::fail):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFormat.h:
(JSC::Wasm::isValidExternalKind):
(JSC::Wasm::makeString):
* wasm/WasmFunctionParser.h:
* wasm/WasmModuleParser.cpp:
* wasm/WasmModuleParser.h:
* wasm/WasmParser.h:
(JSC::Wasm::FailureHelper::makeString):
(JSC::Wasm::Parser::fail):
(JSC::Wasm::Parser<SuccessType>::Parser):
(JSC::Wasm::Parser<SuccessType>::consumeCharacter):
(JSC::Wasm::Parser<SuccessType>::consumeString):
(JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
(JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
(JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
(JSC::Wasm::Parser<SuccessType>::parseVarInt32):
(JSC::Wasm::Parser<SuccessType>::parseVarInt64):
(JSC::Wasm::Parser<SuccessType>::parseUInt32):
(JSC::Wasm::Parser<SuccessType>::parseUInt64):
(JSC::Wasm::Parser<SuccessType>::parseUInt8):
(JSC::Wasm::Parser<SuccessType>::parseInt7):
(JSC::Wasm::Parser<SuccessType>::parseUInt7):
(JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
(JSC::Wasm::Parser<SuccessType>::parseResultType):
(JSC::Wasm::Parser<SuccessType>::parseValueType):
(JSC::Wasm::Parser<SuccessType>::parseExternalKind):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/WasmSections.h:
(JSC::Wasm::isValidSection):
(JSC::Wasm::validateOrder):
(JSC::Wasm::makeString):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::fail):
(JSC::Wasm::Validate::addUnreachable):
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
* wasm/generateWasmOpsHeader.py:
* wasm/generateWasmValidateInlinesHeader.py:
(loadMacro):
(storeMacro):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2016-12-15 JF Bastien <jfbastien@apple.com>
WebAssembly API: improve data section errors, initialize after Element
https://bugs.webkit.org/show_bug.cgi?id=165733
Reviewed by Keith Miller.
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::dataSegmentFail):
(JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization
2016-12-15 Keith Miller <keith_miller@apple.com>
Turn on WebAssembly by default
https://bugs.webkit.org/show_bug.cgi?id=165918
Reviewed by Saam Barati.
* runtime/Options.h:
2016-12-15 Konstantin Tokarev <annulen@yandex.ru>
Added missing override and final specifiers
https://bugs.webkit.org/show_bug.cgi?id=165903
Reviewed by Darin Adler.
* bytecompiler/BytecodeGenerator.h:
* jsc.cpp:
* parser/Nodes.h:
2016-12-15 Chris Dumez <cdumez@apple.com>
Harden JSObject::getOwnPropertyDescriptor()
https://bugs.webkit.org/show_bug.cgi?id=165908
Reviewed by Geoffrey Garen.
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertyDescriptor):
2016-12-15 Keith Miller <keith_miller@apple.com>
Fix 64-bit shift family Wasm opcodes
https://bugs.webkit.org/show_bug.cgi?id=165902
Reviewed by Geoffrey Garen.
The Int64 versions of the shift family B3 opcodes take an Int32
for the shift value. Wasm, however, takes an i64, so we need to
Trunc the shift value. Also, this fixes a bug where shr_u mapped
to signed shift and shr_s mapped to the unsigned shift.
* wasm/wasm.json:
2016-12-14 Keith Miller <keith_miller@apple.com>
Wasm should decode constants correctly
https://bugs.webkit.org/show_bug.cgi?id=165886
Reviewed by Saam Barati.
This patch fixes how we decode the constant part of i32, i64, f32,
and f64.const opcodes.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/wasm.json:
2016-12-14 Saam Barati <sbarati@apple.com>
WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
https://bugs.webkit.org/show_bug.cgi?id=165883
Reviewed by Keith Miller.
This patch implements some low hanging fruit:
- Exporting Table
- Exporting Memory
- Load16 with zero extension to both 32 and 64 bit values.
- Fixes Unreachable to emit code that will prevent B3 from having a validation error.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addUnreachable):
(JSC::Wasm::sizeOfLoadOp):
(JSC::Wasm::B3IRGenerator::emitLoadOp):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseExport):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addUnreachable):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::link):
2016-12-14 Yusuke Suzuki <utatane.tea@gmail.com>
Update ModuleLoader code by using the latest builtin primitives
https://bugs.webkit.org/show_bug.cgi?id=165851
Reviewed by Sam Weinig.
Update the module loader code,
1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
and it can be observed by defining indexed setters in Array.prototype.
* builtins/ModuleLoaderPrototype.js:
(ensureRegistered):
(fulfillFetch):
(commitInstantiated):
(requestFetch):
(requestSatisfy):
(setStateToMax): Deleted.
(newRegistryEntry): Deleted.
* runtime/ModuleLoaderPrototype.cpp:
2016-12-14 Michael Saboff <msaboff@apple.com>
The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
https://bugs.webkit.org/show_bug.cgi?id=165871
Reviewed by Mark Lam.
This fixes two issues with the VM watch dog timer firing in a worker.
The first issue has to do with bytecode ordering. Prior to this change, the first few opcodes
generated when the watch dog is enabled are:
op_enter
op_watchdog
op_get_scope
When the watchdog fires, the function will get an exception at op_watchdog. In processing that exception,
we'll try to update the ShadowChicken shadow stack. That update assumes that if there is a scope
VirtualRegister allocated, then the slot contains a valid JSScope. With the current bytecode ordering,
this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot. It isn't until the
op_get_scope gets processed that we'll have a valid scope in the slot. The fix for this issue is to
ensure that op_get_scope happens before the op_watchdog.
The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
execution exception happened. Instead call() returns an empty JSValue. InjectedScript::wrapCallFrames()
wasn't checking for an empty JSValue, but was passing it to another function. Added a short circuit
return when call returns an empty JSValue.
Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
to check for an empty JSValue return value.
Also tracked with <rdar://problem/29671015>.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitEnter):
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::wrapCallFrames):
2016-12-14 Filip Pizlo <fpizlo@apple.com>
DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
https://bugs.webkit.org/show_bug.cgi?id=165882
Reviewed by Mark Lam.
The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
callee frame is simply the size of the args vector.
That's not true for DirectTailCall, which will pad the args vector with undefined if we
are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
case.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
* jit/CallFrameShuffleData.h:
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
(JSC::CallFrameShuffler::prepareAny):
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::snapshot):
* jit/JITCall.cpp:
(JSC::JIT::compileOpCall):
2016-12-14 Keith Miller <keith_miller@apple.com>
WebAssembly JS API: implement Global
https://bugs.webkit.org/show_bug.cgi?id=164133
Reviewed by Saam Barati.
This patch adds support for globals. It handles imports, exports
and internal globals. In the MVP only internal globals are allowed
to be mutable. This means we can store a C-array of 64-bit slots
off the instance holding them. When globals are exported to JS
they are done so as numbers. This means that i64 globals cannot be
imported or exported.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::getGlobal):
(JSC::Wasm::B3IRGenerator::setGlobal):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::parseAndCompile):
* wasm/WasmFormat.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseGlobal):
(JSC::Wasm::ModuleParser::parseExport):
(JSC::Wasm::ModuleParser::parseElement):
(JSC::Wasm::ModuleParser::parseInitExpr):
(JSC::Wasm::ModuleParser::parseGlobalType):
(JSC::Wasm::ModuleParser::parseData):
* wasm/WasmModuleParser.h:
* wasm/WasmParser.h:
(JSC::Wasm::Parser::parseVarInt32):
(JSC::Wasm::Parser::parseVarInt64):
(JSC::Wasm::Parser::parseUInt64):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::hasMemory):
(JSC::Wasm::Validate::Validate):
(JSC::Wasm::Validate::getGlobal):
(JSC::Wasm::Validate::setGlobal):
(JSC::Wasm::validateFunction):
* wasm/generateWasmOpsHeader.py:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::loadI32Global):
(JSC::JSWebAssemblyInstance::loadI64Global):
(JSC::JSWebAssemblyInstance::loadF32Global):
(JSC::JSWebAssemblyInstance::loadF64Global):
(JSC::JSWebAssemblyInstance::setGlobal):
(JSC::JSWebAssemblyInstance::offsetOfGlobals):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::link):
2016-12-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
regressions is fixed. Lets see what the bots think!
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-14 Filip Pizlo <fpizlo@apple.com>
Devices with fewer cores should use a more aggressive GC schedule by default
https://bugs.webkit.org/show_bug.cgi?id=165859
Reviewed by Mark Lam.
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
* runtime/Options.cpp:
(JSC::overrideDefaults): Change the heuristics if we have fewer cores.
(JSC::Options::initialize):
* runtime/Options.h:
2016-12-14 Mark Lam <mark.lam@apple.com>
BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
https://bugs.webkit.org/show_bug.cgi?id=165820
Reviewed by Saam Barati.
Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
will iterate over all basic blocks looking for the block containing the jump
target, and it will continue to do this even when all the jump targets have been
found. This is wasted work, and all the more so given that most branch type
opcodes only have a single jump target.
* bytecode/BytecodeBasicBlock.cpp:
(JSC::BytecodeBasicBlock::computeImpl):
2016-12-14 Gavin Barraclough <barraclough@apple.com>
MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
https://bugs.webkit.org/show_bug.cgi?id=165741
Unreviewed, re-landing this with fix (revert erroneous change to Options).
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CellContainer.cpp: Added.
(JSC::CellContainer::isNewlyAllocated):
* heap/CellContainer.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::addBlock):
(JSC::MarkedAllocator::removeBlock):
(JSC::MarkedAllocator::dumpBits):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::forEachBitVector):
(JSC::MarkedAllocator::forEachBitVectorWithName):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::tryCreate):
(JSC::MarkedBlock::Handle::~Handle):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::Handle::dumpState):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::markingVersion):
(JSC::MarkedBlock::isMarkedRaw):
(JSC::MarkedBlock::isMarked):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::marksConveyLivenessDuringMarking):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::size):
(JSC::StructureIDTable::get):
2016-12-14 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r209766.
Regressed Dromaeo JSLib by ~50%
Reverted changeset:
"Make opaque root scanning truly constraint-based"
https://bugs.webkit.org/show_bug.cgi?id=165760
http://trac.webkit.org/changeset/209766
2016-12-14 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209795.
https://bugs.webkit.org/show_bug.cgi?id=165853
rolled out the wrong revision (Requested by pizlo on #webkit).
Reverted changeset:
"MarkedBlock::marksConveyLivenessDuringMarking should take
into account collection scope"
https://bugs.webkit.org/show_bug.cgi?id=165741
http://trac.webkit.org/changeset/209795
2016-12-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-13 Yusuke Suzuki <utatane.tea@gmail.com>
Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
https://bugs.webkit.org/show_bug.cgi?id=165795
Reviewed by Saam Barati.
In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
`toWTFString` does not create intermediate JSString objects, then reduce unnecessary
allocations.
This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
* API/JSValueRef.cpp:
(JSValueToStringCopy):
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::toString):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::extractSourceInformationFromException):
* runtime/ConsoleObject.cpp:
(JSC::valueToStringWithUndefinedOrNullCheck):
(JSC::valueOrDefaultLabelString):
* runtime/DateConstructor.cpp:
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::formatLocaleDate):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/InspectorInstrumentationObject.cpp:
(JSC::inspectorInstrumentationObjectLog):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::fetch):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
* runtime/RegExpConstructor.cpp:
(JSC::regExpCreate):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::regExpProtoFuncToString):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstr):
(JSC::stringProtoFuncLocaleCompare):
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
(JSC::stringProtoFuncLink):
(JSC::trimString):
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::stringProtoFuncNormalize):
* tools/JSDollarVMPrototype.cpp:
(JSC::functionPrint):
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create):
2016-12-14 Gavin Barraclough <barraclough@apple.com>
MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
https://bugs.webkit.org/show_bug.cgi?id=165741
Unreviewed rollout due to performance regression.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CellContainer.cpp: Removed.
* heap/CellContainer.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::addBlock):
(JSC::MarkedAllocator::removeBlock):
(JSC::MarkedAllocator::dumpBits):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::forEachBitVector):
(JSC::MarkedAllocator::forEachBitVectorWithName):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::tryCreate):
(JSC::MarkedBlock::Handle::~Handle):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::Handle::dumpState): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::isMarked):
(JSC::MarkedBlock::markingVersion): Deleted.
(JSC::MarkedBlock::isMarkedRaw): Deleted.
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::marksConveyLivenessDuringMarking):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* runtime/Options.h:
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::get):
(JSC::StructureIDTable::size): Deleted.
2016-12-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209792.
https://bugs.webkit.org/show_bug.cgi?id=165841
Cause build failures (Requested by yusukesuzuki on #webkit).
Reverted changeset:
"Use JSValue::toWTFString instead of calling toString(exec)
and value(exec)"
https://bugs.webkit.org/show_bug.cgi?id=165795
http://trac.webkit.org/changeset/209792
2016-12-13 Yusuke Suzuki <utatane.tea@gmail.com>
Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
https://bugs.webkit.org/show_bug.cgi?id=165795
Reviewed by Saam Barati.
In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
`toWTFString` does not create intermediate JSString objects, then reduce unnecessary
allocations.
This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
* API/JSValueRef.cpp:
(JSValueToStringCopy):
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::toString):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::extractSourceInformationFromException):
* runtime/ConsoleObject.cpp:
(JSC::valueToStringWithUndefinedOrNullCheck):
(JSC::valueOrDefaultLabelString):
* runtime/DateConstructor.cpp:
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::formatLocaleDate):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/InspectorInstrumentationObject.cpp:
(JSC::inspectorInstrumentationObjectLog):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toWTFStringSlowCase):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::fetch):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
* runtime/RegExpConstructor.cpp:
(JSC::regExpCreate):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::regExpProtoFuncToString):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstr):
(JSC::stringProtoFuncLocaleCompare):
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
(JSC::stringProtoFuncLink):
(JSC::trimString):
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::stringProtoFuncNormalize):
* tools/JSDollarVMPrototype.cpp:
(JSC::functionPrint):
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create):
2016-12-13 Saam Barati <sbarati@apple.com>
WebAssembly: implement the elements section
https://bugs.webkit.org/show_bug.cgi?id=165715
Reviewed by Keith Miller.
This is a straight forward implementation of the Element
section in the Wasm spec:
https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section
There are a few ambiguities I encountered when implementing this, so I've
filed bugs against the Wasm design repo, and corresponding bugzilla bugs
for us to address after they've been discussed by the various Wasm folks:
- https://bugs.webkit.org/show_bug.cgi?id=165827
- https://bugs.webkit.org/show_bug.cgi?id=165826
- https://bugs.webkit.org/show_bug.cgi?id=165825
* wasm/WasmFormat.h:
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseElement):
(JSC::Wasm::ModuleParser::parseInitExpr):
(JSC::Wasm::ModuleParser::parseData):
* wasm/WasmModuleParser.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2016-12-13 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r209544.
Looks like r209489 did not cause the performance regression
after all
Reverted changeset:
"Unreviewed, rolling out r209489."
https://bugs.webkit.org/show_bug.cgi?id=165550
http://trac.webkit.org/changeset/209544
2016-12-13 Saam Barati <sbarati@apple.com>
WebAssembly: implement the table section and table import
https://bugs.webkit.org/show_bug.cgi?id=165716
Reviewed by Keith Miller.
This patch implements the Table space for wasm:
https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#table-section
It only implements defining and importing a table. The bulk
of this patch is implementing the various wasm Table prototype
methods and the underlying Table object:
https://github.com/WebAssembly/design/blob/master/JS.md#webassemblytable-constructor
This patch also fixes a bug in our implementation with call_indirect.
We initially implemented call_indirect as a way to call functions that
are imported or defined in the module. This was the wrong
interpretation of the spec. Instead, call_indirect can only index into
the table index space.
* JavaScriptCore.xcodeproj/project.pbxproj:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::parseAndCompile):
* wasm/WasmFormat.h:
(JSC::Wasm::TableInformation::TableInformation):
(JSC::Wasm::TableInformation::operator bool):
(JSC::Wasm::TableInformation::isImport):
(JSC::Wasm::TableInformation::initial):
(JSC::Wasm::TableInformation::maximum):
(JSC::Wasm::CallableFunction::CallableFunction):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseResizableLimits):
(JSC::Wasm::ModuleParser::parseTableHelper):
(JSC::Wasm::ModuleParser::parseTable):
(JSC::Wasm::ModuleParser::parseMemoryHelper):
(JSC::Wasm::ModuleParser::parseExport):
* wasm/WasmModuleParser.h:
* wasm/js/JSWebAssemblyHelpers.h: Added.
(JSC::toNonWrappingUint32):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::table):
(JSC::JSWebAssemblyInstance::setTable):
(JSC::JSWebAssemblyInstance::offsetOfTable):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::create):
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::visitChildren):
(JSC::JSWebAssemblyTable::grow):
(JSC::JSWebAssemblyTable::clearFunction):
(JSC::JSWebAssemblyTable::setFunction):
* wasm/js/JSWebAssemblyTable.h:
(JSC::JSWebAssemblyTable::maximum):
(JSC::JSWebAssemblyTable::size):
(JSC::JSWebAssemblyTable::getFunction):
(JSC::JSWebAssemblyTable::offsetOfSize):
(JSC::JSWebAssemblyTable::offsetOfFunctions):
(JSC::JSWebAssemblyTable::isValidSize):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::call):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::visitChildren):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::signature):
(JSC::WebAssemblyFunction::wasmEntrypoint):
(JSC::WebAssemblyFunction::webAssemblyCallee): Deleted.
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::getTable):
(JSC::webAssemblyTableProtoFuncLength):
(JSC::webAssemblyTableProtoFuncGrow):
(JSC::webAssemblyTableProtoFuncGet):
(JSC::webAssemblyTableProtoFuncSet):
(JSC::WebAssemblyTablePrototype::create):
(JSC::WebAssemblyTablePrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.h:
2016-12-13 Filip Pizlo <fpizlo@apple.com>
Add null checks to opaque root APIs.
Rubber stamped by Saam Barati.
If we got a crash report about null in the opaque root HashSet, we would probably not
celebrate how great it is that we found out about a new race - instead we would probably
be annoyed that null wasn't just silently ignored.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRoot):
(JSC::SlotVisitor::containsOpaqueRootTriState):
2016-12-13 Filip Pizlo <fpizlo@apple.com>
Make opaque root scanning truly constraint-based
https://bugs.webkit.org/show_bug.cgi?id=165760
Reviewed by Saam Barati.
We have bugs when visitChildren() changes its mind about what opaque root to add, since
we don't have barriers on opaque roots. This supposedly once worked for generational GC,
and I started adding more barriers to support concurrent GC. But I think that the real
bug here is that we want the JSObject->OpaqueRoot to be evaluated as a constraint that
participates in the fixpoint. A constraint is different from the normal visiting in that
the GC will not wait for a barrier to rescan the object.
So, it's now possible for any visitChildren() method to become a constraint by calling
slotVisitor.rescanAsConstraint(). Because opaque roots are constraints, addOpaqueRoot()
does rescanAsConstraint() for you.
The constraint set is simply a HashSet<JSCell*> that accumulates with every
rescanAsConstraint() call and is only cleared at the start of full GC. This trivially
resolves most classes of GC bugs that would have arisen from opaque roots being changed
in a way that the GC did not anticipate.
Looks like this is perf-neutral.
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint):
(JSC::Heap::setMutatorShouldBeFenced):
(JSC::Heap::writeBarrierOpaqueRootSlow): Deleted.
(JSC::Heap::addMutatorShouldBeFencedCache): Deleted.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::writeBarrierOpaqueRoot): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::visitWeakSets):
* heap/MarkedSpace.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::visitSubsequently):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::addOpaqueRoot):
(JSC::SlotVisitor::rescanAsConstraint):
(JSC::SlotVisitor::mergeIfNecessary):
(JSC::SlotVisitor::mergeOpaqueRootsAndConstraints):
(JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExternalMemoryVisited):
(JSC::SlotVisitor::didNotRace):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::specializedVisit):
(JSC::WeakBlock::visit):
* heap/WeakBlock.h:
* heap/WeakSet.h:
(JSC::WeakSet::visit):
2016-12-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209725.
https://bugs.webkit.org/show_bug.cgi?id=165811
"Broke ARMv7 builds" (Requested by msaboff on #webkit).
Reverted changeset:
"REGRESSION(r209653): speedometer crashes making virtual slow
path tailcalls"
https://bugs.webkit.org/show_bug.cgi?id=165748
http://trac.webkit.org/changeset/209725
2016-12-13 Filip Pizlo <fpizlo@apple.com>
Unreviewed, revert the collectorPermittedIdleRatio back to 0 because of 100MB
regression on membuster. Also, it didn't seem to help perf.
* runtime/Options.h:
2016-12-13 JF Bastien <jfbastien@apple.com>
[WTF] Turn tryMakeString(), makeString() into variadic templates
https://bugs.webkit.org/show_bug.cgi?id=147142
Reviewed by Mark Lam.
* runtime/JSStringBuilder.h:
(JSC::jsMakeNontrivialString): remove WTF:: prefix, it isn't needed anymore
* runtime/Lookup.cpp:
(JSC::reifyStaticAccessor): remove WTF:: prefix, it isn't needed anymore
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString): remove WTF:: prefix, it isn't needed anymore
2016-12-12 Mark Lam <mark.lam@apple.com>
Rename BytecodeGenerator's ControlFlowContext to ControlFlowScope.
https://bugs.webkit.org/show_bug.cgi?id=165777
Reviewed by Keith Miller.
The existing code sometimes refer to ControlFlowContext (and associated references)
as context, and sometimes as scope. Let's be consistent and always call it a scope.
Also renamed push/popScopedControlFlowContext() to push/popLocalControlFlowScope()
because these are only used when we inc/dec the m_localScopeDepth.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitPopWithScope):
(JSC::BytecodeGenerator::pushFinallyControlFlowScope):
(JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
(JSC::BytecodeGenerator::popFinallyControlFlowScope):
(JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::emitPopScopes):
(JSC::BytecodeGenerator::pushLocalControlFlowScope):
(JSC::BytecodeGenerator::popLocalControlFlowScope):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::pushFinallyContext): Deleted.
(JSC::BytecodeGenerator::pushIteratorCloseContext): Deleted.
(JSC::BytecodeGenerator::popFinallyContext): Deleted.
(JSC::BytecodeGenerator::popIteratorCloseContext): Deleted.
(JSC::BytecodeGenerator::pushScopedControlFlowContext): Deleted.
(JSC::BytecodeGenerator::popScopedControlFlowContext): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
2016-12-12 Filip Pizlo <fpizlo@apple.com>
GC scheduler should avoid consecutive pauses
https://bugs.webkit.org/show_bug.cgi?id=165758
Reviewed by Michael Saboff.
This factors out the scheduler from lambdas in Heap::markToFixpoint to an actual class.
It's called the SpaceTimeScheduler because it is a linear controller that ties the
amount of time you spend on things to the amount of space you are using.
This patch uses this refactoring to fix a bug where the GC would pause even though we
still had time during a mutator timeslice. This is a 15% improvement on
JetStream/splay-latency. Seems neutral on everything else. However, it's not at all
clear if this is the right policy or not since retreating wavefront can sometimes be so
sensitive to scheduling decisions. For this reason, there is a tunable option that lets
you decide how long the GC will sit idle before the start of its timeslice.
So, we can revert this policy change in this patch without reverting the patch.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint):
* heap/Heap.h:
* heap/SpaceTimeScheduler.cpp: Added.
(JSC::SpaceTimeScheduler::Decision::targetMutatorUtilization):
(JSC::SpaceTimeScheduler::Decision::targetCollectorUtilization):
(JSC::SpaceTimeScheduler::Decision::elapsedInPeriod):
(JSC::SpaceTimeScheduler::Decision::phase):
(JSC::SpaceTimeScheduler::Decision::shouldBeResumed):
(JSC::SpaceTimeScheduler::Decision::timeToResume):
(JSC::SpaceTimeScheduler::Decision::timeToStop):
(JSC::SpaceTimeScheduler::SpaceTimeScheduler):
(JSC::SpaceTimeScheduler::snapPhase):
(JSC::SpaceTimeScheduler::currentDecision):
* heap/SpaceTimeScheduler.h: Added.
(JSC::SpaceTimeScheduler::Decision::Decision):
(JSC::SpaceTimeScheduler::Decision::operator bool):
* runtime/Options.h:
2016-12-12 Michael Saboff <msaboff@apple.com>
REGRESSION(r209653): speedometer crashes making virtual slow path tailcalls
https://bugs.webkit.org/show_bug.cgi?id=165748
Reviewed by Filip Pizlo.
The virtual slow path for tailcalls always passes arguments on the stack.
The fix here is to link to the stack argument entrypoint instead of a register
argument entrypoint.
While fixing this bug, I found that we weren't clearing the code origin when
shuffling the call frame for a register argument tailcall.
Also rolling back in r209653, r209654, r209663, and r209673.
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareAny):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
2016-12-12 Mark Lam <mark.lam@apple.com>
Rename BytecodeGenerator's m_symbolTableStack to m_lexicalScopeStack.
https://bugs.webkit.org/show_bug.cgi?id=165768
Reviewed by Saam Barati.
The lexical scope in "m_lexicalScopeStack" here refers to a pair of { } in the
source code that bounds the scope of variables.
There are 4 places in the code where we call m_symbolTableStack.append() to
append a new stack entry. In only 3 of the 4 cases, a symbol table is provided
in the new stack entry. In all 4 cases, a scope register is provided in the new
stack entry.
Also, 3 of the 4 functions that appends an entry to this stack are named:
1. initializeVarLexicalEnvironment()
2. pushLexicalScopeInternal()
3. emitPushWithScope()
The 4th function is the BytecodeGenerator constructor where it pushes the scope
for a module environment.
Based on these details, m_lexicalScopeStack is a better name for this stack than
m_symbolTableStack.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
(JSC::BytecodeGenerator::pushLexicalScopeInternal):
(JSC::BytecodeGenerator::initializeBlockScopedFunctions):
(JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::resolveType):
(JSC::BytecodeGenerator::emitResolveScope):
(JSC::BytecodeGenerator::emitPushWithScope):
(JSC::BytecodeGenerator::emitPopWithScope):
(JSC::BytecodeGenerator::pushFinallyContext):
(JSC::BytecodeGenerator::pushIteratorCloseContext):
(JSC::BytecodeGenerator::emitComplexPopScopes):
(JSC::BytecodeGenerator::popTryAndEmitCatch):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
* bytecompiler/BytecodeGenerator.h:
2016-12-12 Saam Barati <sbarati@apple.com>
Unreviewed. Try to fix the cloop build.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::calleeSaveRegisters):
* interpreter/StackVisitor.h:
2016-12-12 Michael Saboff <msaboff@apple.com>
FTL: Dumping disassembly requires that code origin is set when making polymorphic tail calls.
https://bugs.webkit.org/show_bug.cgi?id=165747
Reviewed by Filip Pizlo.
Setting the code origin needs to be done for both the fast and slow path as we might need
it when linking a polymorphic or virtual call stub.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2016-12-11 Saam Barati <sbarati@apple.com>
Unreviewed. Try to fix the linux build.
* runtime/StackFrame.h:
2016-12-11 Saam Barati <sbarati@apple.com>
We should be able to throw exceptions from Wasm code and when Wasm frames are on the stack
https://bugs.webkit.org/show_bug.cgi?id=165429
Reviewed by Keith Miller.
This patch teaches the stack walking runtime about wasm.
To do this, I taught StackVisitor that a callee is not
always an object.
To be able to unwind callee save registers properly, I've given
JSWebAssemblyCallee a list of RegisterAtOffsetList for the callee
saves that B3 saved in the prologue. Also, because we have two
B3Compilations per wasm function, one for wasm entrypoint, and
one for the JS entrypoint, I needed to create a callee for each
because they each might spill callee save registers.
I also fixed a bug inside the Wasm::Memory constructor where we
were trying to mmap the same number of bytes even after the first
mmap failed. We should start by trying to mmap the maximum bytes,
and if that fails, fall back to the specified initial bytes. However,
the code was just mmapping the maximum twice. I've fixed that and
also added a RELEASE_ASSERT_NOT_REACHED() for when the second mmap
fails along with a FIXME to throw an OOM error.
There was a second bug I fixed where JSModuleRecord was calling
visitWeak on its CallLinkInfos inside ::visitChldren(). It needs
to do this after marking. I changed JSModuleRecord to do what
CodeBlock does and call visitWeak on its CallLinkInfos inside
an UnconditionalFinalizer.
* API/JSContextRef.cpp:
(BacktraceFunctor::operator()):
* inspector/ScriptCallStackFactory.cpp:
(Inspector::createScriptCallStackFromException):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::vmEntryGlobalObject):
* interpreter/CallFrame.h:
(JSC::ExecState::callee):
* interpreter/Interpreter.cpp:
(JSC::GetStackTraceFunctor::operator()):
(JSC::UnwindFunctor::operator()):
(JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
* interpreter/Interpreter.h:
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::update):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::StackVisitor):
(JSC::StackVisitor::readFrame):
(JSC::StackVisitor::readNonInlinedFrame):
(JSC::StackVisitor::readInlinedFrame):
(JSC::StackVisitor::Frame::isWasmFrame):
(JSC::StackVisitor::Frame::codeType):
(JSC::StackVisitor::Frame::calleeSaveRegisters):
(JSC::StackVisitor::Frame::functionName):
(JSC::StackVisitor::Frame::sourceURL):
(JSC::StackVisitor::Frame::toString):
(JSC::StackVisitor::Frame::hasLineAndColumnInfo):
(JSC::StackVisitor::Frame::setToEnd):
* interpreter/StackVisitor.h:
(JSC::StackVisitor::Frame::callee):
(JSC::StackVisitor::Frame::isNativeFrame):
(JSC::StackVisitor::Frame::isJSFrame): Deleted.
* jsc.cpp:
(callWasmFunction):
(functionTestWasmModuleFunctions):
* runtime/Error.cpp:
(JSC::addErrorInfoAndGetBytecodeOffset):
* runtime/JSCell.cpp:
(JSC::JSCell::isAnyWasmCallee):
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::RetrieveArgumentsFunctor::operator()):
(JSC::RetrieveCallerFunctionFunctor::operator()):
* runtime/StackFrame.cpp:
(JSC::StackFrame::sourceID):
(JSC::StackFrame::sourceURL):
(JSC::StackFrame::functionName):
(JSC::StackFrame::computeLineAndColumn):
(JSC::StackFrame::toString):
* runtime/StackFrame.h:
(JSC::StackFrame::StackFrame):
(JSC::StackFrame::hasLineAndColumnInfo):
(JSC::StackFrame::hasBytecodeOffset):
(JSC::StackFrame::bytecodeOffset):
(JSC::StackFrame::isNative): Deleted.
* runtime/VM.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::setupFrameInPrologue):
* wasm/WasmFormat.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::Memory):
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::isValid):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
(JSC::Wasm::Plan::initializeCallees):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::jsToWasmEntryPointForFunction): Deleted.
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::finishCreation):
* wasm/js/JSWebAssemblyCallee.h:
(JSC::JSWebAssemblyCallee::create):
(JSC::JSWebAssemblyCallee::entrypoint):
(JSC::JSWebAssemblyCallee::calleeSaveRegisters):
(JSC::JSWebAssemblyCallee::jsToWasmEntryPoint): Deleted.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::visitChildren):
(JSC::JSWebAssemblyModule::UnconditionalFinalizer::finalizeUnconditionally):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
(JSC::JSWebAssemblyModule::setJSEntrypointCallee):
(JSC::JSWebAssemblyModule::setWasmEntrypointCallee):
(JSC::JSWebAssemblyModule::allocationSize):
(JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace): Deleted.
* wasm/js/JSWebAssemblyRuntimeError.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::call):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2016-12-11 Filip Pizlo <fpizlo@apple.com>
Re-enable concurrent GC.
Rubber stampted by Saam Barati.
This change actually landed in r209692 by accident.
* runtime/Options.h:
2016-12-10 Filip Pizlo <fpizlo@apple.com>
MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
https://bugs.webkit.org/show_bug.cgi?id=165741
Reviewed by Saam Barati.
MarkedBlock::marksConveyLivenessDuringMarking thought that the off-by-one marking
version indicated liveness during any collection when it's just during full collection.
One of its users - MarkedBlock::sweep - knew this and had a special case, but the other
one - MarkedBlock::isLive - didn't. So, I moved the special case into
marksConveyLivenessDuringMarking.
Also, this cleans up some remaining bitvector races.
To find this bug, I significantly strengthened our assertions.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/CellContainer.cpp: Added.
(JSC::CellContainer::isNewlyAllocated):
* heap/CellContainer.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::addBlock):
(JSC::MarkedAllocator::removeBlock):
(JSC::MarkedAllocator::dumpBits):
* heap/MarkedAllocator.h:
(JSC::MarkedAllocator::forEachBitVector):
(JSC::MarkedAllocator::forEachBitVectorWithName):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::tryCreate):
(JSC::MarkedBlock::Handle::~Handle):
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::MarkedBlock::Handle::dumpState):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::markingVersion):
(JSC::MarkedBlock::isMarkedRaw):
(JSC::MarkedBlock::isMarked):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::marksConveyLivenessDuringMarking):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::size):
(JSC::StructureIDTable::get):
2016-12-10 Filip Pizlo <fpizlo@apple.com>
The DOM should have an advancing wavefront opaque root barrier
https://bugs.webkit.org/show_bug.cgi?id=165712
Reviewed by Yusuke Suzuki.
This exposes the ability to fire an advancing wavefront barrier on opaque roots. It also
gives clients the ability to maintain their own cache of whether that barrier needs to
be enabled.
The DOM uses this to enable a very cheap barrier on the DOM. This is neutral on
Speedometer and fixes another concurrent GC crash.
* heap/Heap.cpp:
(JSC::Heap::beginMarking):
(JSC::Heap::endMarking):
(JSC::Heap::writeBarrierOpaqueRootSlow):
(JSC::Heap::addMutatorShouldBeFencedCache):
(JSC::Heap::setMutatorShouldBeFenced):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::writeBarrierOpaqueRoot):
2016-12-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209653, r209654, r209663, and
r209673.
https://bugs.webkit.org/show_bug.cgi?id=165739
speedometer crashes (Requested by pizlo on #webkit).
Reverted changesets:
"JSVALUE64: Pass arguments in platform argument registers when
making JavaScript calls"
https://bugs.webkit.org/show_bug.cgi?id=160355
http://trac.webkit.org/changeset/209653
"Unreviewed build fix for 32 bit builds."
http://trac.webkit.org/changeset/209654
"Unreviewed build fix for the CLOOP after r209653"
http://trac.webkit.org/changeset/209663
"REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()"
https://bugs.webkit.org/show_bug.cgi?id=165728
http://trac.webkit.org/changeset/209673
2016-12-10 Michael Saboff <msaboff@apple.com>
REGRESSION(r209653) Crash in CallFrameShuffler::snapshot()
https://bugs.webkit.org/show_bug.cgi?id=165728
Reviewed by Filip Pizlo.
It can be the case that a JSValueReg's CachedRecovery is the source for mutliple
GPRs. We only store the CachedRecovery in one slot of m_newRegisters to simplify
the recovery process. This is also done for the case where the recovery source
and destination are the same GPR.
In light of this change, snapshot needs to be taught that one CacheRecovery is
the source for multiple registers. This is done by using a two step process.
First find all the argument CachedRecovery's and create a vector mapping all of
the target GPRs and the source recovery. Then use that vector to get the
recovery for each register.
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::snapshot):
2016-12-10 Keith Miller <keith_miller@apple.com>
Fix indirect_call if the result type is used.
https://bugs.webkit.org/show_bug.cgi?id=165727
Reviewed by Michael Saboff.
The patchpoint for indirect_call assumed that the callee would be
in params[0]. This is not the case, however, if the callee returns
a value.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCallIndirect):
2016-12-10 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Include WTF, JSC, and WebCore headers automatically to targers using them
https://bugs.webkit.org/show_bug.cgi?id=165686
Reviewed by Michael Catanzaro.
This change reduces duplication of include path lists between modules,
and reduces future need for fixes like r209605 (broken build because of
WebCore header suddenly becoming used in WebKit2).
* CMakeLists.txt:
* PlatformEfl.cmake:
* PlatformGTK.cmake:
* PlatformJSCOnly.cmake:
* PlatformMac.cmake:
2016-12-10 Michael Saboff <msaboff@apple.com>
Unreviewed build fix for the CLOOP after r209653
* jit/GPRInfo.h:
Provided a definition for NUMBER_OF_JS_FUNCTION_ARGUMENT_REGISTERS when the JIT is disabled.
* jit/JITEntryPoints.h:
Removed #if ENABLE(JIT) protection around contents.
2016-12-10 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Module namespace object behaves like immutable prototype exotic object
https://bugs.webkit.org/show_bug.cgi?id=165598
Reviewed by Mark Lam.
In the latest ECMA262 draft, the module namespace object behaves like immutable prototype exotic object.
https://tc39.github.io/ecma262/#sec-module-namespace-exotic-objects-setprototypeof-v
* runtime/JSModuleNamespaceObject.h:
2016-12-10 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION(r208791): Assertion in testb3
https://bugs.webkit.org/show_bug.cgi?id=165651
Reviewed by Saam Barati.
Accidentally we always use edx/rdx for the result of UDiv/UMod.
But it is incorrect. We should use eax/rax for the result of UDiv.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lowerX86UDiv):
2016-12-09 Michael Saboff <msaboff@apple.com>
Unreviewed build fix for 32 bit builds.
* dfg/DFGMinifiedNode.h:
(JSC::DFG::MinifiedNode::argumentIndex): Added a static_cast<unsigned>().
2016-12-09 Michael Saboff <msaboff@apple.com>
JSVALUE64: Pass arguments in platform argument registers when making JavaScript calls
https://bugs.webkit.org/show_bug.cgi?id=160355
Reviewed by Filip Pizlo.
This patch implements passing JavaScript function arguments in registers for 64 bit platforms.
The implemented convention follows the ABI conventions for the associated platform.
The first two arguments are the callee and argument count, the rest of the argument registers
contain "this" and following argument until all platform argument registers are exhausted.
Arguments beyond what fit in registers are placed on the stack in the same location as
before this patch.
For X86-64 non-Windows platforms, there are 6 argument registers specified in the related ABI.
ARM64 has had argument registers. This allows for 4 or 6 parameter values to be placed in
registers on these respective platforms. This patch doesn't implement passing arguments in
registers for 32 bit platform, since most platforms have at most 4 argument registers
specified and 32 bit platforms use two 32 bit registers/memory locations to store one JSValue.
The call frame on the stack in unchanged in format and the arguments that are passed in
registers use the corresponding call frame location as a spill location. Arguments can
also be passed on the stack. The LLInt, baseline JIT'ed code as well as the initial entry
from C++ code base arguments on the stack. DFG s and FTL generated code pass arguments
via registers. All callees can accept arguments either in registers or on the stack.
The callee is responsible for moving argument to its preferred location.
The multiple entry points to JavaSCript code is now handled via the JITEntryPoints class and
related code. That class now has entries for StackArgsArityCheckNotRequired,
StackArgsMustCheckArity and for platforms that support registers arguments,
RegisterArgsArityCheckNotRequired, RegisterArgsMustCheckArity as well as and additional
RegisterArgsPossibleExtraArgs entry point when extra registers argument are passed.
This last case is needed to spill those extra arguments to the corresponding call frame
slots.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.h:
* b3/B3Validate.cpp:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::argumentsLocation):
(JSC::CallLinkInfo::argumentsInRegisters):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
(JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
(JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGCommon.h:
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::run):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGenerationInfo.h:
(JSC::DFG::GenerationInfo::initArgumentRegisterValue):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::needsFlushedThis):
(JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::initialize):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::compileEntry): Deleted.
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addJSDirectCall):
(JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
(JSC::DFG::JITCompiler::JSDirectCallRecord::hasSlowCall):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::JITFinalizer):
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
* dfg/DFGJITFinalizer.h:
* dfg/DFGLiveCatchVariablePreservationPhase.cpp:
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
* dfg/DFGMaximalFlushInsertionPhase.cpp:
(JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
(JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
* dfg/DFGMayExit.cpp:
* dfg/DFGMinifiedNode.cpp:
(JSC::DFG::MinifiedNode::fromNode):
* dfg/DFGMinifiedNode.h:
(JSC::DFG::belongsInMinifiedGraph):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::hasVariableAccessData):
* dfg/DFGNode.h:
(JSC::DFG::Node::accessesStack):
(JSC::DFG::Node::setVariableAccessData):
(JSC::DFG::Node::hasArgumentRegisterIndex):
(JSC::DFG::Node::argumentRegisterIndex):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGPutStackSinkingPhase.cpp:
* dfg/DFGRegisterBank.h:
(JSC::DFG::RegisterBank::iterator::unlock):
(JSC::DFG::RegisterBank::unlockAtIndex):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::clearGenerationInfo):
(JSC::DFG::dumpRegisterInfo):
(JSC::DFG::SpeculativeJIT::dump):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
(JSC::DFG::SpeculativeJIT::setupArgumentRegistersForEntry):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::allocate):
(JSC::DFG::SpeculativeJIT::spill):
(JSC::DFG::SpeculativeJIT::generationInfoFromVirtualRegister):
(JSC::DFG::JSValueOperand::JSValueOperand):
(JSC::DFG::JSValueOperand::gprUseSpecific):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillJSValue):
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrEntryThunkGenerator):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* dfg/DFGVirtualRegisterAllocationPhase.cpp:
(JSC::DFG::VirtualRegisterAllocationPhase::allocateRegister):
(JSC::DFG::VirtualRegisterAllocationPhase::run):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode):
(JSC::FTL::JITCode::initializeEntrypointThunk):
(JSC::FTL::JITCode::setEntryFor):
(JSC::FTL::JITCode::addressForCall):
(JSC::FTL::JITCode::executableAddressAtOffset):
(JSC::FTL::JITCode::initializeAddressForCall): Deleted.
(JSC::FTL::JITCode::initializeArityCheckEntrypoint): Deleted.
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentRegister):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::argumentRegister):
(JSC::FTL::Output::argumentRegisterInt32):
* ftl/FTLOutput.h:
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::update):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitDumbVirtualCall):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::spillArgumentRegistersToFrameBeforePrologue):
(JSC::AssemblyHelpers::spillArgumentRegistersToFrame):
(JSC::AssemblyHelpers::fillArgumentRegistersFromFrameBeforePrologue):
(JSC::AssemblyHelpers::emitPutArgumentToCallFrameBeforePrologue):
(JSC::AssemblyHelpers::emitPutArgumentToCallFrame):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeaderBeforePrologue):
(JSC::AssemblyHelpers::emitGetFromCallFrameArgumentBeforePrologue):
(JSC::AssemblyHelpers::emitGetPayloadFromCallFrameHeaderBeforePrologue):
(JSC::AssemblyHelpers::incrementCounter):
* jit/CachedRecovery.cpp:
(JSC::CachedRecovery::addTargetJSValueRegs):
* jit/CachedRecovery.h:
(JSC::CachedRecovery::gprTargets):
(JSC::CachedRecovery::setWantedFPR):
(JSC::CachedRecovery::wantedJSValueRegs):
(JSC::CachedRecovery::setWantedJSValueRegs): Deleted.
* jit/CallFrameShuffleData.h:
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::CallFrameShuffler):
(JSC::CallFrameShuffler::dump):
(JSC::CallFrameShuffler::tryWrites):
(JSC::CallFrameShuffler::prepareAny):
* jit/CallFrameShuffler.h:
(JSC::CallFrameShuffler::snapshot):
(JSC::CallFrameShuffler::addNew):
(JSC::CallFrameShuffler::initDangerFrontier):
(JSC::CallFrameShuffler::updateDangerFrontier):
(JSC::CallFrameShuffler::findDangerFrontierFrom):
* jit/CallFrameShuffler64.cpp:
(JSC::CallFrameShuffler::emitDisplace):
* jit/GPRInfo.h:
(JSC::JSValueRegs::operator==):
(JSC::JSValueRegs::operator!=):
(JSC::GPRInfo::toArgumentIndex):
(JSC::argumentRegisterFor):
(JSC::argumentRegisterForCallee):
(JSC::argumentRegisterForArgumentCount):
(JSC::argumentRegisterIndexForJSFunctionArgument):
(JSC::jsFunctionArgumentForArgumentRegister):
(JSC::argumentRegisterForFunctionArgument):
(JSC::numberOfRegisterArgumentsFor):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
(JSC::JIT::compileCTINativeCall): Deleted.
* jit/JIT.h:
(JSC::JIT::compileNativeCallEntryPoints):
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCode.cpp:
(JSC::JITCode::execute):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::initializeEntryPoints):
(JSC::DirectJITCode::addressForCall):
(JSC::NativeJITCode::addressForCall):
(JSC::DirectJITCode::initializeCodeRef): Deleted.
* jit/JITCode.h:
(JSC::JITCode::executableAddress): Deleted.
* jit/JITEntryPoints.h: Added.
(JSC::JITEntryPoints::JITEntryPoints):
(JSC::JITEntryPoints::entryFor):
(JSC::JITEntryPoints::setEntryFor):
(JSC::JITEntryPoints::offsetOfEntryFor):
(JSC::JITEntryPoints::registerEntryTypeForArgumentCount):
(JSC::JITEntryPoints::registerEntryTypeForArgumentType):
(JSC::JITEntryPoints::clearEntries):
(JSC::JITEntryPoints::operator=):
(JSC::JITEntryPointsWithRef::JITEntryPointsWithRef):
(JSC::JITEntryPointsWithRef::codeRef):
(JSC::argumentsLocationFor):
(JSC::registerEntryPointTypeFor):
(JSC::entryPointTypeFor):
(JSC::thunkEntryPointTypeFor):
(JSC::JITJSCallThunkEntryPointsWithRef::JITJSCallThunkEntryPointsWithRef):
(JSC::JITJSCallThunkEntryPointsWithRef::entryFor):
(JSC::JITJSCallThunkEntryPointsWithRef::setEntryFor):
(JSC::JITJSCallThunkEntryPointsWithRef::offsetOfEntryFor):
(JSC::JITJSCallThunkEntryPointsWithRef::clearEntries):
(JSC::JITJSCallThunkEntryPointsWithRef::codeRef):
(JSC::JITJSCallThunkEntryPointsWithRef::operator=):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileJITEntryNativeCall):
(JSC::JIT::privateCompileCTINativeCall): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileJITEntryNativeCall):
(JSC::JIT::privateCompileCTINativeCall): Deleted.
* jit/JITOperations.cpp:
* jit/JITThunks.cpp:
(JSC::JITThunks::jitEntryNativeCall):
(JSC::JITThunks::jitEntryNativeConstruct):
(JSC::JITThunks::jitEntryStub):
(JSC::JITThunks::jitCallThunkEntryStub):
(JSC::JITThunks::hostFunctionStub):
(JSC::JITThunks::ctiNativeCall): Deleted.
(JSC::JITThunks::ctiNativeConstruct): Deleted.
* jit/JITThunks.h:
* jit/JSInterfaceJIT.h:
(JSC::JSInterfaceJIT::emitJumpIfNotInt32):
(JSC::JSInterfaceJIT::emitLoadInt32):
* jit/RegisterSet.cpp:
(JSC::RegisterSet::argumentRegisters):
* jit/RegisterSet.h:
* jit/Repatch.cpp:
(JSC::linkSlowFor):
(JSC::revertCall):
(JSC::unlinkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::SpecializedThunkJIT):
(JSC::SpecializedThunkJIT::checkJSStringArgument):
(JSC::SpecializedThunkJIT::linkFailureHere):
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerator.h:
* jit/ThunkGenerators.cpp:
(JSC::createRegisterArgumentsSpillEntry):
(JSC::slowPathFor):
(JSC::linkCallThunkGenerator):
(JSC::linkDirectCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::nativeCallGenerator):
(JSC::nativeTailCallGenerator):
(JSC::nativeTailCallWithoutSavedTagsGenerator):
(JSC::nativeConstructGenerator):
(JSC::stringCharLoadRegCall):
(JSC::charCodeAtThunkGenerator):
(JSC::charAtThunkGenerator):
(JSC::fromCharCodeThunkGenerator):
(JSC::clz32ThunkGenerator):
(JSC::sqrtThunkGenerator):
(JSC::floorThunkGenerator):
(JSC::ceilThunkGenerator):
(JSC::truncThunkGenerator):
(JSC::roundThunkGenerator):
(JSC::expThunkGenerator):
(JSC::logThunkGenerator):
(JSC::absThunkGenerator):
(JSC::imulThunkGenerator):
(JSC::randomThunkGenerator):
(JSC::boundThisNoArgsFunctionCallGenerator):
* jit/ThunkGenerators.h:
* jsc.cpp:
(jscmain):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::entryOSR):
(JSC::LLInt::setUpCall):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::functionForRegisterCallEntryThunkGenerator):
(JSC::LLInt::functionForStackCallEntryThunkGenerator):
(JSC::LLInt::functionForRegisterConstructEntryThunkGenerator):
(JSC::LLInt::functionForStackConstructEntryThunkGenerator):
(JSC::LLInt::functionForRegisterCallArityCheckThunkGenerator):
(JSC::LLInt::functionForStackCallArityCheckThunkGenerator):
(JSC::LLInt::functionForRegisterConstructArityCheckThunkGenerator):
(JSC::LLInt::functionForStackConstructArityCheckThunkGenerator):
(JSC::LLInt::functionForCallEntryThunkGenerator): Deleted.
(JSC::LLInt::functionForConstructEntryThunkGenerator): Deleted.
(JSC::LLInt::functionForCallArityCheckThunkGenerator): Deleted.
(JSC::LLInt::functionForConstructArityCheckThunkGenerator): Deleted.
* llint/LLIntThunks.h:
* runtime/ArityCheckMode.h:
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
* runtime/ExecutableBase.h:
(JSC::ExecutableBase::entrypointFor):
(JSC::ExecutableBase::offsetOfEntryFor):
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
* runtime/JSBoundFunction.cpp:
(JSC::boundThisNoArgsFunctionCall):
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::finishCreation):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::installCode):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::thunkGeneratorForIntrinsic):
(JSC::VM::clearCounters):
(JSC::VM::dumpCounters):
* runtime/VM.h:
(JSC::VM::getJITEntryStub):
(JSC::VM::getJITCallThunkEntryStub):
(JSC::VM::addressOfCounter):
(JSC::VM::counterFor):
* wasm/WasmBinding.cpp:
(JSC::Wasm::importStubGenerator):
2016-12-09 Keith Miller <keith_miller@apple.com>
Wasm should support call_indirect
https://bugs.webkit.org/show_bug.cgi?id=165718
Reviewed by Filip Pizlo.
This patch adds support for call_indirect. The basic framework for
an indirect call is that the module holds a buffer containing a
stub for each function in the index space. Whenever a function
needs to do an indirect call it gets a index into that table. In
order to ensure call_indirect is calling a valid function the
functionIndexSpace also needs a pointer to a canonicalized
signature. When making an indirect call, we first check the index
is in range, then check the signature matches the value we were given.
This patch also differentiates between FunctionIndexSpaces and
ImmutableFunctionIndexSpaces. Since we don't know the size of the
FunctionIndexSpace when we start parsing we need to be able to
resize the IndexSpace. However, once we have finished parsing all
the sections we want to prevent an relocation of the function
index space pointer.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::setupCall):
* wasm/WasmFormat.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser::setErrorMessage):
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::takeFunctionIndexSpace):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addCallIndirect):
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
(JSC::JSWebAssemblyModule::offsetOfFunctionIndexSpace):
2016-12-09 JF Bastien <jfbastien@apple.com>
WebAssembly: implement data section
https://bugs.webkit.org/show_bug.cgi?id=165696
Reviewed by Keith Miller.
As specified in https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#data-section
Note that some of the interesting corner cases are ill-defined by the spec: https://github.com/WebAssembly/design/issues/897
* wasm/WasmFormat.h: segments are what represent sections of memory to initialize (similar to ELF's non-zero intializer data / rodata)
(JSC::Wasm::Segment::make):
(JSC::Wasm::Segment::destroy):
(JSC::Wasm::Segment::byte):
(JSC::Wasm::Segment::makePtr):
* wasm/WasmModuleParser.cpp: parse the data section, and prevent a few overflows if a user passes in UINT_MAX (the loops would overflow)
(JSC::Wasm::ModuleParser::parseType):
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseFunction):
(JSC::Wasm::ModuleParser::parseExport):
(JSC::Wasm::ModuleParser::parseCode):
(JSC::Wasm::ModuleParser::parseData):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate): the only sensible time to initialize the data section is after linking, but before calling start, I test for this but the spec isn't clear it's correct yet
2016-12-09 Karim H <karim@karhm.com>
It is okay to turn undefined into null because we are producing values for a
JSON representation (InspectorValue) and JSON has a `null` value and no
`undefined` value.
https://bugs.webkit.org/show_bug.cgi?id=165506
Reviewed by Darin Adler.
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
2016-12-09 Filip Pizlo <fpizlo@apple.com>
REGRESSION (r209554-209571): stress/poly-setter-combo crashing
https://bugs.webkit.org/show_bug.cgi?id=165669
Reviewed by Geoffrey Garen.
We now rely on objects being zero-filled in a bunch of places, not just concurrent GC.
So, we need 32-bit to do it too.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_new_object):
2016-12-09 Eric Carlson <eric.carlson@apple.com>
Annotate MediaStream and WebRTC idl with EnabledAtRuntime flag
https://bugs.webkit.org/show_bug.cgi?id=165251
Reviewed by Dean Jackson.
Based on a patch by Dr Alex Gouaillard <agouaillard@gmail.com>
* runtime/CommonIdentifiers.h: Add WebRTC and MediaStream identifiers.
2016-12-09 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement start function
https://bugs.webkit.org/show_bug.cgi?id=165150
Reviewed by Saam Barati.
* wasm/WasmFormat.h: pass the start function around
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseTable): mark unreachable code
(JSC::Wasm::ModuleParser::parseGlobal): mark unreachable code
(JSC::Wasm::ModuleParser::parseStart): mark unreachable code
(JSC::Wasm::ModuleParser::parseElement): mark unreachable code
(JSC::Wasm::ModuleParser::parseData): mark unreachable code
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction): NFC: call the new function below
(JSC::WebAssemblyFunction::call): separate this out so that the start function can use it
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::visitChildren): visit the start function
(JSC::WebAssemblyModuleRecord::link): handle start function
(JSC::WebAssemblyModuleRecord::evaluate): call the start function, if present
* wasm/js/WebAssemblyModuleRecord.h:
2016-12-09 Filip Pizlo <fpizlo@apple.com>
GC might be forced to look at a nuked object due to ordering of AllocatePropertyStorage, MaterializeNewObject, and PutStructure
https://bugs.webkit.org/show_bug.cgi?id=165672
Reviewed by Geoffrey Garen.
We need to make sure that the shady stuff in a property put happens after the
PutByOffset, since the PutByOffset is the place where we materialize. More generally, we
should strive to not have any fenceposts between Nodes where a GC would be illegal.
This gets us most of the way there by separating NukeStructureAndSetButterfly from
[Re]AllocatePropertyStorage. A transitioning put will now look something like:
GetButterfly
ReallocatePropertyStorage
PutByOffset
NukeStructureAndSetButterfly
PutStructure
Previously the structure would get nuked by ReallocatePropertyStorage, so if we placed
an object materialization just after it (before the PutByOffset) then any GC that
completed at that safepoint would encounter an unresolved visit race due to seeing a
nuked structure. We cannot have nuked structures at safepoints, and this change makes
sure that we don't - at least until someone tries to sink to the PutStructure. We will
eventually have to create a combined SetStructureAndButterfly node, but we don't need it
yet.
This also fixes a goof where the DFG's AllocatePropertyStorage was nulling the structure
instead of nuking it. This could easily have caused many crashes in GC.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNukeStructureAndSetButterfly):
(JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h: Fix a bug - make it possible to turn on concurrent GC optionally again.
2016-12-09 Chris Dumez <cdumez@apple.com>
Inline JSCell::toObject()
https://bugs.webkit.org/show_bug.cgi?id=165679
Reviewed by Geoffrey Garen.
Inline JSCell::toObject() as it shows on Speedometer profiles.
* runtime/JSCell.cpp:
(JSC::JSCell::toObjectSlow):
(JSC::JSCell::toObject): Deleted.
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::toObject):
2016-12-09 Geoffrey Garen <ggaren@apple.com>
Deploy OrdinalNumber in JSC::SourceCode
https://bugs.webkit.org/show_bug.cgi?id=165687
Reviewed by Michael Saboff.
We have a lot of confusion between 1-based and 0-based counting in line
and column numbers. Let's use OrdinalNumber to clear up the confusion.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::link):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitExpressionInfo):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::functionDetails):
* parser/Lexer.cpp:
(JSC::Lexer<T>::setCode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode):
(JSC::SourceCode::firstLine):
(JSC::SourceCode::startColumn):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::firstLine):
(JSC::ScriptExecutable::startColumn):
* tools/CodeProfile.h:
(JSC::CodeProfile::CodeProfile):
2016-12-09 Saam Barati <sbarati@apple.com>
WebAssembly JS API: implement importing and defining Memory
https://bugs.webkit.org/show_bug.cgi?id=164134
Reviewed by Keith Miller.
This patch implements the WebAssembly.Memory object. It refactors
the code to now associate a Memory with the instance instead of
the Module.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(functionTestWasmModuleFunctions):
* runtime/VM.h:
* shell/CMakeLists.txt:
* testWasm.cpp: Removed.
This has bitrotted. I'm removing it.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::sizeOfLoadOp):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFormat.cpp:
(JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
* wasm/WasmFormat.h:
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::Memory):
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::size):
(JSC::Wasm::Memory::initial):
(JSC::Wasm::Memory::maximum):
(JSC::Wasm::Memory::pinnedRegisters): Deleted.
* wasm/WasmMemoryInformation.cpp: Added.
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/WasmMemoryInformation.h: Added.
(JSC::Wasm::MemoryInformation::MemoryInformation):
(JSC::Wasm::MemoryInformation::pinnedRegisters):
(JSC::Wasm::MemoryInformation::initial):
(JSC::Wasm::MemoryInformation::maximum):
(JSC::Wasm::MemoryInformation::isImport):
(JSC::Wasm::MemoryInformation::operator bool):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseMemoryHelper):
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseExport):
* wasm/WasmModuleParser.h:
* wasm/WasmPageCount.h: Added. Implement a new way of describing Wasm
pages and then asking for how many bytes a quantity of pages is. This
class also makes it clear when we're talking about bytes or pages.
(JSC::Wasm::PageCount::PageCount):
(JSC::Wasm::PageCount::bytes):
(JSC::Wasm::PageCount::isValid):
(JSC::Wasm::PageCount::max):
(JSC::Wasm::PageCount::operator bool):
(JSC::Wasm::PageCount::operator<):
(JSC::Wasm::PageCount::operator>):
(JSC::Wasm::PageCount::operator>=):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::memory): Deleted.
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::hasMemory):
(JSC::Wasm::Validate::Validate):
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/generateWasmValidateInlinesHeader.py:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::memory):
(JSC::JSWebAssemblyInstance::setMemory):
(JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
(JSC::JSWebAssemblyInstance::allocationSize):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::create):
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::buffer):
(JSC::JSWebAssemblyMemory::visitChildren):
* wasm/js/JSWebAssemblyMemory.h:
(JSC::JSWebAssemblyMemory::memory):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
Handle importing and creating of memory according
to the spec. This also does the needed validation
of making sure the memory defined in the module
is compatible with the imported memory.
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
(JSC::callJSWebAssemblyMemory):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::webAssemblyMemoryProtoFuncBuffer):
(JSC::WebAssemblyMemoryPrototype::create):
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::link):
2016-12-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Some resources fetched via Fetch API do not have data
https://bugs.webkit.org/show_bug.cgi?id=165230
<rdar://problem/29449220>
Reviewed by Alex Christensen.
* inspector/protocol/Page.json:
Add new Fetch Page.ResourceType.
2016-12-09 Geoffrey Garen <ggaren@apple.com>
TextPosition and OrdinalNumber should be more like idiomatic numbers
https://bugs.webkit.org/show_bug.cgi?id=165678
Reviewed by Filip Pizlo.
Adopt default constructor.
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSObjectRef.cpp:
(JSObjectMakeFunction):
* API/JSScriptRef.cpp:
(OpaqueJSScript::OpaqueJSScript):
* jsc.cpp:
(functionCheckModuleSyntax):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.h:
(JSC::StringSourceProvider::create):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
2016-12-09 Filip Pizlo <fpizlo@apple.com>
Unreviewed, disable concurrent GC for real.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-09 Filip Pizlo <fpizlo@apple.com>
Unreviewed, disable concurrent GC while crashes get investigated.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-09 Filip Pizlo <fpizlo@apple.com>
JSSegmentedVariableObject should keep its state private
Rubber stamped by Michael Saboff.
Its state fields were protected for no reason. They really should be private because
you have to know to obey a particular concurrency protocol when accessing them.
* runtime/JSSegmentedVariableObject.h:
2016-12-09 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed ARM buildfix after 209570.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::or32): Added.
2016-12-08 JF Bastien <jfbastien@apple.com>
WebAssembly: JSC::link* shouldn't need a CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=165591
Reviewed by Keith Miller.
Allow linking without a CodeBlock, which WebAssembly's wasm -> JS stubs does. This needs to work for polymorphic and virtual calls. This patch adds corresponding tests for this.
* assembler/LinkBuffer.cpp:
(JSC::shouldDumpDisassemblyFor): don't look at the tier option if there isn't a CodeBlock, only look at the global one. This is a WebAssembly function, so the tier information is irrelevant.
* jit/Repatch.cpp:
(JSC::isWebAssemblyToJSCallee): this is used in the link* functions below
(JSC::linkFor):
(JSC::linkVirtualFor):
(JSC::linkPolymorphicCall):
* runtime/Options.h: add an option to change the maximum number of polymorphic calls in stubs from wasm to JS, which will come in handy when we try to tune performance or try merging some of the WebAssembly stubs
* wasm/WasmBinding.cpp:
(JSC::Wasm::importStubGenerator): remove the breakpoint since the code now works
* wasm/js/WebAssemblyToJSCallee.h:
2016-12-08 Filip Pizlo <fpizlo@apple.com>
MultiPutByOffset should get a barrier if it transitions
https://bugs.webkit.org/show_bug.cgi?id=165646
Reviewed by Keith Miller.
Previously, if we knew that we were storing a non-cell but we needed to transition, we
would fail to add the barrier but the FTL's lowering expected the barrier to be there.
Strictly, we need to "consider" the barrier on MultiPutByOffset if the value is
possibly a cell or if the MultiPutByOffset may transition. Then "considering" the
barrier implies checking if the base is possibly old.
But because the barrier is so cheap anyway, this patch implements something safer: we
just consider the barrier on MultiPutByOffset unconditionally, which opts it out of any
barrier optimizations other than those based on the predicted state of the base. Those
optimizations are already sound - for example they use doesGC() to detect safepoints
and that function correctly predicts when MultiPutByOffset could GC.
Because the barrier optimizations are only a very small speed-up, I think it's great to
fix bugs by weakening the optimizer without cleverness.
* dfg/DFGFixupPhase.cpp:
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::assertValidCell):
2016-12-08 Filip Pizlo <fpizlo@apple.com>
Enable concurrent GC on ARM64
https://bugs.webkit.org/show_bug.cgi?id=165643
Reviewed by Saam Barati.
It looks stable enough to enable.
* assembler/CPU.h:
(JSC::useGCFences): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::mutatorFence):
(JSC::AssemblyHelpers::storeButterfly):
(JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
(JSC::AssemblyHelpers::emitInitializeInlineStorage):
(JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-08 Filip Pizlo <fpizlo@apple.com>
Disable collectContinuously if not useConcurrentGC
Rubber stamped by Geoffrey Garen.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-12-08 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop build.
* runtime/JSObject.h:
2016-12-06 Filip Pizlo <fpizlo@apple.com>
Concurrent GC should be stable enough to land enabled on X86_64
https://bugs.webkit.org/show_bug.cgi?id=164990
Reviewed by Geoffrey Garen.
This fixes a ton of performance and correctness bugs revealed by getting the concurrent GC to
be stable enough to land enabled.
I had to redo the JSObject::visitChildren concurrency protocol again. This time I think it's
even more correct than ever!
This is an enormous win on JetStream/splay-latency and Octane/SplayLatency. It looks to be
mostly neutral on everything else, though Speedometer is showing statistically weak signs of a
slight regression.
* API/JSAPIWrapperObject.mm: Added locking.
(JSC::JSAPIWrapperObject::visitChildren):
* API/JSCallbackObject.h: Added locking.
(JSC::JSCallbackObjectData::visitChildren):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::deletePrivateProperty):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): This had a TOCTOU race on shouldJettisonDueToOldAge.
(JSC::EvalCodeCache::visitAggregate): Moved to EvalCodeCache.cpp.
* bytecode/DirectEvalCodeCache.cpp: Added. Outlined some functions and made them use locks.
(JSC::DirectEvalCodeCache::setSlow):
(JSC::DirectEvalCodeCache::clear):
(JSC::DirectEvalCodeCache::visitAggregate):
* bytecode/DirectEvalCodeCache.h:
(JSC::DirectEvalCodeCache::set):
(JSC::DirectEvalCodeCache::clear): Deleted.
* bytecode/UnlinkedCodeBlock.cpp: Added locking.
(JSC::UnlinkedCodeBlock::visitChildren):
(JSC::UnlinkedCodeBlock::setInstructions):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecode/UnlinkedCodeBlock.h: Added locking.
(JSC::UnlinkedCodeBlock::addRegExp):
(JSC::UnlinkedCodeBlock::addConstant):
(JSC::UnlinkedCodeBlock::addFunctionDecl):
(JSC::UnlinkedCodeBlock::addFunctionExpr):
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
* debugger/Debugger.cpp: Use the right delete API.
(JSC::Debugger::recompileAllJSFunctions):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix a pre-existing bug in ToFunction constant folding.
* dfg/DFGClobberize.h: Add support for nuking.
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp: Add support for nuking.
(JSC::DFG::clobbersExitState):
* dfg/DFGFixupPhase.cpp: Add support for nuking.
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::indexForChecks):
(JSC::DFG::FixupPhase::originForCheck):
(JSC::DFG::FixupPhase::speculateForBarrier):
(JSC::DFG::FixupPhase::insertCheck):
(JSC::DFG::FixupPhase::fixupChecksInBlock):
* dfg/DFGSpeculativeJIT.cpp: Add support for nuking.
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* ftl/FTLLowerDFGToB3.cpp: Add support for nuking.
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
(JSC::FTL::DFG::LowerDFGToB3::nukeStructureAndSetButterfly):
(JSC::FTL::DFG::LowerDFGToB3::setButterfly): Deleted.
* heap/CodeBlockSet.cpp: We need to be more careful about the CodeBlockSet workflow during GC, since we will allocate CodeBlocks in eden while collecting.
(JSC::CodeBlockSet::clearMarksForFullCollection):
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/Heap.cpp: Added code to measure max pauses. Added a better collectContinuously mode.
(JSC::Heap::lastChanceToFinalize): Stop the collectContinuously thread.
(JSC::Heap::harvestWeakReferences): Inline SlotVisitor::harvestWeakReferences.
(JSC::Heap::finalizeUnconditionalFinalizers): Inline SlotVisitor::finalizeUnconditionalReferences.
(JSC::Heap::markToFixpoint): We need to do some MarkedSpace stuff before every conservative scan, rather than just at the start of marking, so we now call prepareForConservativeScan() before each conservative scan. Also call a less-parallel version of drainInParallel when the mutator is running.
(JSC::Heap::collectInThread): Inline Heap::prepareForAllocation().
(JSC::Heap::stopIfNecessarySlow): We need to be more careful about ensuring that we run finalization before and after stopping. Also, we should sanitize stack when stopping the world.
(JSC::Heap::acquireAccessSlow): Add some optional debug prints.
(JSC::Heap::handleNeedFinalize): Assert that we are running this when the world is not stopped.
(JSC::Heap::finalize): Remove the old collectContinuously code.
(JSC::Heap::requestCollection): We don't need to sanitize stack here anymore.
(JSC::Heap::notifyIsSafeToCollect): Start the collectContinuously thread. It will request collection 1 KHz.
(JSC::Heap::prepareForAllocation): Deleted.
(JSC::Heap::preventCollection): Prevent any new concurrent GCs from being initiated.
(JSC::Heap::allowCollection):
(JSC::Heap::forEachSlotVisitor): Allows us to safely iterate slot visitors.
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::writeBarrier): If the 'to' cell is not NewWhite then it could be AnthraciteOrBlack. During a full collection, objects may be AnthraciteOrBlack from a previous GC. Turns out, we don't benefit from this optimization so we can just kill it.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::buildSnapshot): This needs to use PreventCollectionScope to ensure snapshot soundness.
* heap/ListableHandler.h:
(JSC::ListableHandler::isOnList): Useful helper.
* heap/LockDuringMarking.h:
(JSC::lockDuringMarking): It's a locker that only locks while we're marking.
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::addBlock): Hold the bitvector lock while resizing.
* heap/MarkedBlock.cpp: Hold the bitvector lock while accessing the bitvectors while the mutator is running.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::prepareForConservativeScan): We used to do this in prepareForMarking, but we need to do it before each conservative scan not just before marking.
(JSC::MarkedSpace::prepareForMarking): Remove the logic moved to prepareForConservativeScan.
* heap/MarkedSpace.h:
* heap/PreventCollectionScope.h: Added.
* heap/SlotVisitor.cpp: Refactored drainFromShared so that we can write a similar function called drainInParallelPassively.
(JSC::SlotVisitor::updateMutatorIsStopped): Update whether we can use "fast" scanning.
(JSC::SlotVisitor::mutatorIsStoppedIsUpToDate):
(JSC::SlotVisitor::didReachTermination):
(JSC::SlotVisitor::hasWork):
(JSC::SlotVisitor::drain): This now uses the rightToRun lock to allow the main GC thread to safepoint the workers.
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::drainInParallelPassively): This runs marking with one fewer threads than normal. It's useful for when we have resumed the mutator, since then the mutator has a better chance of getting on a core.
(JSC::SlotVisitor::addWeakReferenceHarvester):
(JSC::SlotVisitor::addUnconditionalFinalizer):
(JSC::SlotVisitor::harvestWeakReferences): Deleted.
(JSC::SlotVisitor::finalizeUnconditionalFinalizers): Deleted.
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h: Outline stuff.
(JSC::SlotVisitor::addWeakReferenceHarvester): Deleted.
(JSC::SlotVisitor::addUnconditionalFinalizer): Deleted.
* runtime/InferredType.cpp: This needed thread safety.
(JSC::InferredType::visitChildren): This needs to keep its structure finalizer alive until it runs.
(JSC::InferredType::set):
(JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
* runtime/InferredType.h:
* runtime/InferredValue.cpp: This needed thread safety.
(JSC::InferredValue::visitChildren):
(JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase): Update to use new butterfly API.
(JSC::JSArray::unshiftCountWithArrayStorage): Update to use new butterfly API.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::visitChildren): Thread safety.
* runtime/JSCell.h:
(JSC::JSCell::setStructureIDDirectly): This is used for nuking the structure.
(JSC::JSCell::InternalLocker::InternalLocker): Deleted. The cell is now the lock.
(JSC::JSCell::InternalLocker::~InternalLocker): Deleted. The cell is now the lock.
* runtime/JSCellInlines.h:
(JSC::JSCell::structure): Clean this up.
(JSC::JSCell::lock): The cell is now the lock.
(JSC::JSCell::tryLock):
(JSC::JSCell::unlock):
(JSC::JSCell::isLocked):
(JSC::JSCell::lockInternalLock): Deleted.
(JSC::JSCell::unlockInternalLock): Deleted.
* runtime/JSFunction.cpp:
(JSC::JSFunction::visitChildren): Thread safety.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Thread safety.
(JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory): Thread safety.
* runtime/JSObject.cpp:
(JSC::JSObject::markAuxiliaryAndVisitOutOfLineProperties): Factor out this "easy" step of butterfly visiting.
(JSC::JSObject::visitButterfly): Make this achieve 100% precision about structure-butterfly relationships. This relies on the mutator "nuking" the structure prior to "locked" structure-butterfly transitions.
(JSC::JSObject::visitChildren): Use the new, nicer API.
(JSC::JSFinalObject::visitChildren): Use the new, nicer API.
(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): Use the new butterfly API.
(JSC::JSObject::createInitialUndecided): Use the new butterfly API.
(JSC::JSObject::createInitialInt32): Use the new butterfly API.
(JSC::JSObject::createInitialDouble): Use the new butterfly API.
(JSC::JSObject::createInitialContiguous): Use the new butterfly API.
(JSC::JSObject::createArrayStorage): Use the new butterfly API.
(JSC::JSObject::convertUndecidedToContiguous): Use the new butterfly API.
(JSC::JSObject::convertUndecidedToArrayStorage): Use the new butterfly API.
(JSC::JSObject::convertInt32ToArrayStorage): Use the new butterfly API.
(JSC::JSObject::convertDoubleToContiguous): Use the new butterfly API.
(JSC::JSObject::convertDoubleToArrayStorage): Use the new butterfly API.
(JSC::JSObject::convertContiguousToArrayStorage): Use the new butterfly API.
(JSC::JSObject::increaseVectorLength): Use the new butterfly API.
(JSC::JSObject::shiftButterflyAfterFlattening): Use the new butterfly API.
* runtime/JSObject.h:
(JSC::JSObject::setButterfly): This now does all of the fences. Only use this when you are not also transitioning the structure or the structure's lastOffset.
(JSC::JSObject::nukeStructureAndSetButterfly): Use this when doing locked structure-butterfly transitions.
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectWithoutTransition): Use the newly factored out API.
(JSC::JSObject::prepareToPutDirectWithoutTransition): Factor this out!
(JSC::JSObject::putDirectInternal): Use the newly factored out API.
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::finishCreation): Locks!
(JSC::JSPropertyNameEnumerator::visitChildren): Locks!
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildren): Locks!
* runtime/JSString.cpp:
(JSC::JSString::visitChildren): Thread safety.
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::visitChildren): Thread safety.
* runtime/Options.cpp: For now we disable concurrent GC on not-X86_64.
(JSC::recomputeDependentOptions):
* runtime/Options.h: Change the default max GC parallelism to 8. I don't know why it was still 7.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::stackTracesAsJSON): This needs to defer GC before grabbing its lock.
* runtime/SparseArrayValueMap.cpp: This needed thread safety.
(JSC::SparseArrayValueMap::add):
(JSC::SparseArrayValueMap::remove):
(JSC::SparseArrayValueMap::visitChildren):
* runtime/SparseArrayValueMap.h:
* runtime/Structure.cpp: This had a race between addNewPropertyTransition and visitChildren.
(JSC::Structure::Structure):
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::flattenDictionaryStructure):
(JSC::Structure::add): Help out with nuking support - the m_offset needs to play along.
(JSC::Structure::visitChildren):
* runtime/Structure.h: Make some useful things public - like the notion of a lastOffset.
* runtime/StructureChain.cpp:
(JSC::StructureChain::visitChildren): Thread safety!
* runtime/StructureChain.h: Thread safety!
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::allocateID): Ensure that we don't get nuked IDs.
* runtime/StructureIDTable.h: Add the notion of a nuked ID! It's a bit that the runtime never sees except during specific shady actions like locked structure-butterfly transitions. "Nuking" tells the GC to steer clear and rescan once we fire the barrier.
(JSC::nukedStructureIDBit):
(JSC::nuke):
(JSC::isNuked):
(JSC::decontaminate):
* runtime/StructureInlines.h:
(JSC::Structure::hasIndexingHeader): Better API.
(JSC::Structure::add):
* runtime/VM.cpp: Better GC interaction.
(JSC::VM::ensureWatchdog):
(JSC::VM::deleteAllLinkedCode):
(JSC::VM::deleteAllCode):
* runtime/VM.h:
(JSC::VM::getStructure): Why wasn't this always an API!
* runtime/WebAssemblyExecutable.cpp:
(JSC::WebAssemblyExecutable::visitChildren): Thread safety.
2016-12-08 Filip Pizlo <fpizlo@apple.com>
Enable SharedArrayBuffer, remove the flag
https://bugs.webkit.org/show_bug.cgi?id=165614
Rubber stamped by Geoffrey Garen.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/RuntimeFlags.h:
2016-12-08 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: wire up Instance imports
https://bugs.webkit.org/show_bug.cgi?id=165118
Reviewed by Saam Barati.
Change a bunch of the WebAssembly object model, and pipe the
necessary changes to be able to call JS imports from
WebAssembly. This will make it easier to call_indirect, and
unblock many other missing features.
As a follow-up I need to teach JSC::linkFor to live without a
CodeBlock: wasm doesn't have one and the IC patching is sad. We'll
switch on the callee (or its type?) and then use that as the owner
(because the callee is alive if the instance is alive, ditto
module, and module owns the CallLinkInfo).
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* interpreter/CallFrame.h:
(JSC::ExecState::callee): give access to the callee as a JSCell
* jit/RegisterSet.cpp: dead code from previous WebAssembly implementation
* jsc.cpp:
(callWasmFunction):
(functionTestWasmModuleFunctions):
* runtime/JSCellInlines.h:
(JSC::ExecState::vm): check callee instead of jsCallee: wasm only has a JSCell and not a JSObject
* runtime/VM.cpp:
(JSC::VM::VM): store the "top" WebAssembly.Instance on entry to WebAssembly (and restore the previous one on exit)
* runtime/VM.h:
* testWasm.cpp:
(runWasmTests):
* wasm/JSWebAssembly.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator): pass unlinked calls around to shorten their lifetime: they're ony needed until the Plan is done
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::parseAndCompile): also pass in the function index space, so that imports can be signature-checked along with internal functions
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBinding.cpp: Added.
(JSC::Wasm::importStubGenerator): stubs from wasm to JS
* wasm/WasmBinding.h: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::setupFrameInPrologue):
* wasm/WasmFormat.h: fix the object model
(JSC::Wasm::CallableFunction::CallableFunction):
* wasm/WasmFunctionParser.h: simplify some of the failure condition checks
(JSC::Wasm::FunctionParser<Context>::FunctionParser): need function index space, not just internal functions
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp: early-create some of the structures which will be needed later
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseFunction):
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseExport):
(JSC::Wasm::ModuleParser::parseCode):
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::functionIndexSpace):
(JSC::Wasm::ModuleParser::functionLocations):
* wasm/WasmParser.h:
(JSC::Wasm::Parser::consumeUTF8String):
* wasm/WasmPlan.cpp: pass around the wasm objects at the right time, reducing their lifetime and making it easier to pass them around when needed
(JSC::Wasm::Plan::run):
(JSC::Wasm::Plan::initializeCallees):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::exports):
(JSC::Wasm::Plan::internalFunctionCount):
(JSC::Wasm::Plan::jsToWasmEntryPointForFunction):
(JSC::Wasm::Plan::takeModuleInformation):
(JSC::Wasm::Plan::takeCallLinkInfos):
(JSC::Wasm::Plan::takeWasmToJSStubs):
(JSC::Wasm::Plan::takeFunctionIndexSpace):
* wasm/WasmValidate.cpp: check function index space instead of only internal functions
(JSC::Wasm::Validate::addCall):
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h:
* wasm/js/JSWebAssemblyCallee.cpp:
(JSC::JSWebAssemblyCallee::finishCreation):
* wasm/js/JSWebAssemblyCallee.h:
(JSC::JSWebAssemblyCallee::create):
(JSC::JSWebAssemblyCallee::jsToWasmEntryPoint):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h: hold the import functions off the end of the Instance
(JSC::JSWebAssemblyInstance::importFunction):
(JSC::JSWebAssemblyInstance::importFunctions):
(JSC::JSWebAssemblyInstance::setImportFunction):
(JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
(JSC::JSWebAssemblyInstance::offsetOfImportFunction):
(JSC::JSWebAssemblyInstance::allocationSize):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h: hold the link call info, the import function stubs, and the function index space
(JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
(JSC::JSWebAssemblyModule::importCount):
(JSC::JSWebAssemblyModule::calleeFromFunctionIndexSpace):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction): set top Instance on VM
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::instance):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): handle function imports
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule): generate the stubs for import functions
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyToJSCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
(JSC::WebAssemblyToJSCallee::create): dummy JSCell singleton which lives on the VM, and is put as the callee in the import stub's frame to identified it when unwinding
(JSC::WebAssemblyToJSCallee::createStructure):
(JSC::WebAssemblyToJSCallee::WebAssemblyToJSCallee):
(JSC::WebAssemblyToJSCallee::finishCreation):
(JSC::WebAssemblyToJSCallee::destroy):
* wasm/js/WebAssemblyToJSCallee.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h.
2016-12-08 Mark Lam <mark.lam@apple.com>
Enable JSC restricted options by default in the jsc shell.
https://bugs.webkit.org/show_bug.cgi?id=165615
Reviewed by Keith Miller.
The jsc shell is only used for debugging and development testing. We should
allow it to use restricted options like JSC_useDollarVM even for release builds.
* jsc.cpp:
(jscmain):
* runtime/Options.cpp:
(JSC::Options::enableRestrictedOptions):
(JSC::Options::isAvailable):
(JSC::allowRestrictedOptions): Deleted.
* runtime/Options.h:
2016-12-08 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r209489.
Likely caused large regressions on JetStream, Sunspider and
Speedometer
Reverted changeset:
"Add system trace points for JavaScript VM entry/exit"
https://bugs.webkit.org/show_bug.cgi?id=165550
http://trac.webkit.org/changeset/209489
2016-12-08 Keith Miller <keith_miller@apple.com>
Move LEB tests to API tests
https://bugs.webkit.org/show_bug.cgi?id=165586
Reviewed by Saam Barati.
Delete old stuff.
* testWasm.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
(main):
(runLEBTests): Deleted.
2016-12-07 JF Bastien <jfbastien@apple.com>
Cleanup WebAssembly's RETURN_IF_EXCEPTION
https://bugs.webkit.org/show_bug.cgi?id=165595
Reviewed by Filip Pizlo.
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2016-12-07 Geoffrey Garen <ggaren@apple.com>
Renamed SourceCode members to match their accessor names
https://bugs.webkit.org/show_bug.cgi?id=165573
Reviewed by Keith Miller.
startChar => startOffset
endChar => endOffset
* parser/UnlinkedSourceCode.h:
(JSC::UnlinkedSourceCode::UnlinkedSourceCode):
(JSC::UnlinkedSourceCode::view):
(JSC::UnlinkedSourceCode::startOffset):
(JSC::UnlinkedSourceCode::endOffset):
(JSC::UnlinkedSourceCode::length):
2016-12-07 Keith Miller <keith_miller@apple.com>
Add more missing trivial wasm ops.
https://bugs.webkit.org/show_bug.cgi?id=165564
Reviewed by Geoffrey Garen.
This patch adds the nop, drop, and tee_local opcodes.
It also fixes an issue where we were not generating
the proper enums for the grow_memory and current_memory
opcodes.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/generateWasmOpsHeader.py:
2016-12-07 Geoffrey Garen <ggaren@apple.com>
Renamed source => parentSource
https://bugs.webkit.org/show_bug.cgi?id=165570
Reviewed by Keith Miller.
For less confuse.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2016-12-07 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop translate phase in module loader
https://bugs.webkit.org/show_bug.cgi?id=164861
Reviewed by Saam Barati.
Originally, this "translate" phase was introduced to the module loader.
However, recent rework discussion[1] starts dropping this phase.
And this "translate" phase is meaningless in the browser side module loader
since this phase originally mimics the node.js's translation hook (like,
transpiling CoffeeScript source to JavaScript).
This "translate" phase is not necessary for the exposed HTML5
<script type="module"> tag right now. Once the module loader pipeline is
redefined and specified, we need to update the current loader anyway.
So dropping "translate" phase right now is OK.
This a bit simplifies the current module loader pipeline.
[1]: https://github.com/whatwg/loader/issues/147
* builtins/ModuleLoaderPrototype.js:
(newRegistryEntry):
(fulfillFetch):
(requestFetch):
(requestInstantiate):
(provide):
(fulfillTranslate): Deleted.
(requestTranslate): Deleted.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* jsc.cpp:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::translate): Deleted.
* runtime/JSModuleLoader.h:
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeInstantiate):
(JSC::moduleLoaderPrototypeTranslate): Deleted.
2016-12-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add ability to distinguish if a Script was parsed as a module
https://bugs.webkit.org/show_bug.cgi?id=164900
<rdar://problem/29323817>
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didParseSource):
* inspector/protocol/Debugger.json:
Add an optional event parameter to distinguish if a script was a module or not.
2016-12-07 Simon Fraser <simon.fraser@apple.com>
Add system trace points for JavaScript VM entry/exit
https://bugs.webkit.org/show_bug.cgi?id=165550
Reviewed by Tim Horton.
Add trace points for entry/exit into/out of the JS VM.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::~VMEntryScope):
2016-12-06 Keith Miller <keith_miller@apple.com>
Add support for truncation operators
https://bugs.webkit.org/show_bug.cgi?id=165519
Reviewed by Geoffrey Garen.
This patch adds initial support for truncation operators. The current patch
does range based out of bounds checking, in the future we should use system
register flags on ARM and other tricks on X86 improve the performance of
these opcodes.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTruncateDoubleToInt32):
(JSC::MacroAssemblerARM64::truncateDoubleToInt64):
(JSC::MacroAssemblerARM64::truncateDoubleToUint64):
(JSC::MacroAssemblerARM64::truncateFloatToInt32):
(JSC::MacroAssemblerARM64::truncateFloatToUint32):
(JSC::MacroAssemblerARM64::truncateFloatToInt64):
(JSC::MacroAssemblerARM64::truncateFloatToUint64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::truncateFloatToInt32):
(JSC::MacroAssemblerX86Common::truncateDoubleToUint32): Deleted.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::truncateDoubleToUint32):
(JSC::MacroAssemblerX86_64::truncateDoubleToInt64):
(JSC::MacroAssemblerX86_64::truncateDoubleToUint64):
(JSC::MacroAssemblerX86_64::truncateFloatToUint32):
(JSC::MacroAssemblerX86_64::truncateFloatToInt64):
(JSC::MacroAssemblerX86_64::truncateFloatToUint64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::cvttss2si_rr):
(JSC::X86Assembler::cvttss2siq_rr):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncSF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncSF32>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncUF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncUF32>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncSF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncSF32>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64TruncUF32>):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
2016-12-07 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused and mostly untested Page domain commands and events
https://bugs.webkit.org/show_bug.cgi?id=165507
Reviewed by Brian Burg.
Remove unused and unsupported commands and events.
- Page.setDocumentContent
- Page.getScriptExecutionStatus
- Page.setScriptExecutionDisabled
- Page.handleJavaScriptDialog
- Page.javascriptDialogOpening
- Page.javascriptDialogClosed
- Page.scriptsEnabled
* inspector/protocol/Page.json:
2016-12-07 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Merge PromiseReactions
https://bugs.webkit.org/show_bug.cgi?id=165526
Reviewed by Sam Weinig.
Our promise implementation has two arrays per Promise; promiseFulfillReactions and promiseRejectReactions.
And everytime we call `promise.then`, we create two promise reactions for fullfill and reject.
However, these two reactions and the arrays for reactions can be merged into one array and one reaction.
It reduces the unnecessary object allocations.
No behavior change.
* builtins/BuiltinNames.h:
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseReaction):
(globalPrivate.triggerPromiseReactions):
(globalPrivate.rejectPromise):
(globalPrivate.fulfillPromise):
(globalPrivate.promiseReactionJob):
(globalPrivate.initializePromise):
* builtins/PromisePrototype.js:
(then):
* runtime/JSPromise.cpp:
(JSC::JSPromise::finishCreation):
2016-12-06 Mark Lam <mark.lam@apple.com>
GetByID IC is wrongly unwrapping the global proxy this value for getter/setters.
https://bugs.webkit.org/show_bug.cgi?id=165401
Reviewed by Saam Barati.
When the this value for a property access is the JS global and that property
access is via a GetterSetter, the underlying getter / setter functions would
expect the this value they receive to be the JSProxy instance instead of the
JSGlobalObject. This is consistent with how the LLINT and runtime code behaves.
The IC code should behave the same way.
Also added some ASSERTs to document invariants in the code, and help detect
bugs sooner if the code gets changed in a way that breaks those invariants in
the future.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
2016-12-06 Joseph Pecoraro <pecoraro@apple.com>
DumpRenderTree ASSERT in JSC::ExecutableBase::isHostFunction seen on bots
https://bugs.webkit.org/show_bug.cgi?id=165497
<rdar://problem/29538973>
Reviewed by Saam Barati.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
Defer collection when extracting and processing the samples to avoid
any objects held by the samples from getting collected while processing.
This is because while processing we call into functions that can
allocate and we must prevent those functions from syncing with the
GC thread which may collect other sample data yet to be processed.
2016-12-06 Alexey Proskuryakov <ap@apple.com>
Correct SDKROOT values in xcconfig files
https://bugs.webkit.org/show_bug.cgi?id=165487
rdar://problem/29539209
Reviewed by Dan Bernstein.
Fix suggested by Dan Bernstein.
* Configurations/DebugRelease.xcconfig:
2016-12-06 Saam Barati <sbarati@apple.com>
Remove old Wasm object model
https://bugs.webkit.org/show_bug.cgi?id=165481
Reviewed by Keith Miller and Mark Lam.
It's confusing to see code that consults both the old
Wasm object model alongside the new one. The old object
model is not a thing, and it's not being used. Let's
remove it now to prevent further confusion.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::replacement):
(JSC::CodeBlock::computeCapabilityLevel):
(JSC::CodeBlock::updateAllPredictions):
* bytecode/CodeBlock.h:
* bytecode/WebAssemblyCodeBlock.cpp: Removed.
* bytecode/WebAssemblyCodeBlock.h: Removed.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupportedForInlining):
* interpreter/Interpreter.cpp:
(JSC::GetStackTraceFunctor::operator()):
(JSC::UnwindFunctor::operator()):
(JSC::isWebAssemblyExecutable): Deleted.
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/ExecutableBase.cpp:
(JSC::ExecutableBase::clearCode):
* runtime/ExecutableBase.h:
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
* runtime/JSFunction.cpp:
* runtime/JSFunction.h:
* runtime/JSFunctionInlines.h:
(JSC::JSFunction::isBuiltinFunction):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* runtime/WebAssemblyExecutable.cpp: Removed.
* runtime/WebAssemblyExecutable.h: Removed.
2016-12-06 JF Bastien <jfbastien@apple.com>
PureNaN: fix typo
https://bugs.webkit.org/show_bug.cgi?id=165493
Reviewed by Mark Lam.
* runtime/PureNaN.h:
2016-12-06 Mark Lam <mark.lam@apple.com>
Introduce the concept of Immutable Prototype Exotic Objects to comply with the spec.
https://bugs.webkit.org/show_bug.cgi?id=165227
<rdar://problem/29442665>
Reviewed by Saam Barati.
* runtime/JSObject.cpp:
(JSC::JSObject::setPrototypeWithCycleCheck):
- This is where we check for immutable prototype exotic objects and refuse to set
the prototype if needed.
See https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::isImmutablePrototypeExoticObject):
* runtime/Structure.h:
- Add flag for declaring immutable prototype exotic objects.
* runtime/ObjectPrototype.h:
- Declare that Object.prototype is an immutable prototype exotic object.
See https://tc39.github.io/ecma262/#sec-properties-of-the-object-prototype-object.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorSetPrototypeOf):
- Use better error messages.
2016-12-04 Darin Adler <darin@apple.com>
Use ASCIICType more, and improve it a little bit
https://bugs.webkit.org/show_bug.cgi?id=165360
Reviewed by Sam Weinig.
* inspector/InspectorValues.cpp:
(Inspector::readHexDigits): Use isASCIIHexDigit.
(Inspector::hextoInt): Deleted.
(decodeString): Use toASCIIHexValue.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::parseDigit): Use isASCIIDigit, isASCIIUpper, and isASCIILower.
* runtime/StringPrototype.cpp:
(JSC::substituteBackreferencesSlow): Use isASCIIDigit.
2016-12-06 Csaba Osztrogonác <ossy@webkit.org>
Add storeFence support for ARMv7
https://bugs.webkit.org/show_bug.cgi?id=164733
Reviewed by Saam Barati.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::dmbISHST): Added.
* assembler/ARMv7Assembler.h: Typo fixed, DMB has only T1 encoding.
(JSC::ARMv7Assembler::dmbSY):
(JSC::ARMv7Assembler::dmbISHST): Added.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::storeFence):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::storeFence):
2016-12-05 Matt Baker <mattbaker@apple.com>
Web Inspector: remove ASSERT from InspectorDebuggerAgent::derefAsyncCallData
https://bugs.webkit.org/show_bug.cgi?id=165413
<rdar://problem/29517587>
Reviewed by Brian Burg.
DOMTimer::removeById can call into InspectorInstrumentation with an
invalid identifier, so don't assert that async call data exists.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::derefAsyncCallData):
2016-12-05 Geoffrey Garen <ggaren@apple.com>
Fixed a bug in my last patch.
Unreviewed.
* bytecode/UnlinkedFunctionExecutable.h: Restore the conversion to
one-based counting.
2016-12-05 Geoffrey Garen <ggaren@apple.com>
Moved start and end column linking into helper functions
https://bugs.webkit.org/show_bug.cgi?id=165422
Reviewed by Sam Weinig.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
2016-12-05 Mark Lam <mark.lam@apple.com>
Fix JSC files so that we can build a release build with NDEBUG #undef'ed.
https://bugs.webkit.org/show_bug.cgi?id=165409
Reviewed by Keith Miller.
This allows us to run a release build with DEBUG ASSERTs enabled.
* bytecode/BytecodeLivenessAnalysis.cpp:
* bytecode/UnlinkedEvalCodeBlock.cpp:
* bytecode/UnlinkedFunctionCodeBlock.cpp:
* bytecode/UnlinkedModuleProgramCodeBlock.cpp:
* bytecode/UnlinkedProgramCodeBlock.cpp:
* runtime/EvalExecutable.cpp:
2016-12-05 Geoffrey Garen <ggaren@apple.com>
Renamed source => parentSource
https://bugs.webkit.org/show_bug.cgi?id=165419
Reviewed by Saam Barati.
This should help clarify that a FunctionExecutable holds the source
code to its *parent* scope, and not its own SourceCode.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
2016-12-05 Geoffrey Garen <ggaren@apple.com>
ScriptExecutable should not contain a copy of firstLine and startColumn
https://bugs.webkit.org/show_bug.cgi?id=165415
Reviewed by Keith Miller.
We already have this data in SourceCode.
It's super confusing to have two copies of this data, where one is
allowed to mutate. In reality, your line and column number never change.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlock):
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::FunctionExecutable):
* runtime/FunctionExecutable.h:
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::ScriptExecutable):
(JSC::ScriptExecutable::newCodeBlockFor):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::firstLine):
(JSC::ScriptExecutable::startColumn):
(JSC::ScriptExecutable::recordParse):
2016-12-05 Caitlin Potter <caitp@igalia.com>
[JSC] report unexpected token when "async" is followed by identifier
https://bugs.webkit.org/show_bug.cgi?id=165091
Reviewed by Mark Lam.
Report a SyntaxError, in order to report correct error in contexts
an async ArrowFunction cannot occur. Also corrects errors in comment
describing JSTokenType bitfield, which was added in r209293.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/ParserTokens.h:
2016-12-05 Keith Miller <keith_miller@apple.com>
Add Wasm i64 to i32 conversion.
https://bugs.webkit.org/show_bug.cgi?id=165378
Reviewed by Filip Pizlo.
It turns out the wrap operation is just B3's Trunc.
* wasm/wasm.json:
2016-12-05 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION(r208985): SafariForWebKitDevelopment Symbol Not Found looking for method with WTF::Optional
https://bugs.webkit.org/show_bug.cgi?id=165351
Reviewed by Yusuke Suzuki.
Some versions of Safari expect:
Inspector::BackendDispatcher::reportProtocolError(WTF::Optional<long>, Inspector::BackendDispatcher::CommonErrorCode, WTF::String const&)
Which we had updated to use std::optional. Expose a version with the original
Symbol for these Safaris. This stub will just call through to the new version.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::reportProtocolError):
* inspector/InspectorBackendDispatcher.h:
2016-12-05 Konstantin Tokarev <annulen@yandex.ru>
Add __STDC_FORMAT_MACROS before inttypes.h is included
https://bugs.webkit.org/show_bug.cgi?id=165374
We need formatting macros like PRIu64 to be available in all places where
inttypes.h header is used. All these usages get inttypes.h definitions
via wtf/Assertions.h header, except SQLiteFileSystem.cpp where formatting
macros are not used anymore since r185129.
This patch fixes multiple build errors with MinGW and reduces number of
independent __STDC_FORMAT_MACROS uses in the code base.
Reviewed by Darin Adler.
* disassembler/ARM64/A64DOpcode.cpp: Removed __STDC_FORMAT_MACROS
because it is obtained via Assertions.h now
* disassembler/ARM64Disassembler.cpp: Ditto.
2016-12-04 Keith Miller <keith_miller@apple.com>
Add support for Wasm ctz and popcnt
https://bugs.webkit.org/show_bug.cgi?id=165369
Reviewed by Saam Barati.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::countTrailingZeros32):
(JSC::MacroAssemblerARM64::countTrailingZeros64):
* assembler/MacroAssemblerX86Common.cpp:
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::countTrailingZeros32):
(JSC::MacroAssemblerX86Common::supportsBMI1):
(JSC::MacroAssemblerX86Common::ctzAfterBsf):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::countTrailingZeros64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::tzcnt_rr):
(JSC::X86Assembler::tzcntq_rr):
(JSC::X86Assembler::bsf_rr):
(JSC::X86Assembler::bsfq_rr):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32Ctz>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64Ctz>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32Popcnt>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64Popcnt>):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
2016-12-04 Saam Barati <sbarati@apple.com>
We should have a Wasm callee
https://bugs.webkit.org/show_bug.cgi?id=165163
Reviewed by Keith Miller.
This patch adds JSWebAssemblyCallee and stores it into the
callee slot in the call frame as part of the prologue of a
wasm function. This is the first step in implementing
unwinding from/through wasm frames. We will use the callee
to identify that a machine frame belongs to wasm code.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jsc.cpp:
(callWasmFunction):
(functionTestWasmModuleFunctions):
* llint/LowLevelInterpreter64.asm:
* runtime/JSGlobalObject.cpp:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/JSWebAssembly.h:
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::parseAndCompile):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::setupFrameInPrologue):
* wasm/WasmFormat.h:
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::initializeCallees):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::compiledFunction):
(JSC::Wasm::Plan::getCompiledFunctions): Deleted.
* wasm/js/JSWebAssemblyCallee.cpp: Added.
(JSC::JSWebAssemblyCallee::JSWebAssemblyCallee):
(JSC::JSWebAssemblyCallee::finishCreation):
(JSC::JSWebAssemblyCallee::destroy):
* wasm/js/JSWebAssemblyCallee.h: Added.
(JSC::JSWebAssemblyCallee::create):
(JSC::JSWebAssemblyCallee::createStructure):
(JSC::JSWebAssemblyCallee::jsEntryPoint):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
(JSC::JSWebAssemblyModule::callee):
(JSC::JSWebAssemblyModule::callees):
(JSC::JSWebAssemblyModule::offsetOfCallees):
(JSC::JSWebAssemblyModule::allocationSize):
(JSC::JSWebAssemblyModule::compiledFunctions): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::visitChildren):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h:
(JSC::WebAssemblyFunction::webAssemblyCallee):
(JSC::WebAssemblyFunction::instance):
(JSC::WebAssemblyFunction::signature):
(JSC::CallableWebAssemblyFunction::CallableWebAssemblyFunction): Deleted.
(JSC::WebAssemblyFunction::webAssemblyFunctionCell): Deleted.
* wasm/js/WebAssemblyFunctionCell.cpp:
(JSC::WebAssemblyFunctionCell::create): Deleted.
(JSC::WebAssemblyFunctionCell::WebAssemblyFunctionCell): Deleted.
(JSC::WebAssemblyFunctionCell::destroy): Deleted.
(JSC::WebAssemblyFunctionCell::createStructure): Deleted.
* wasm/js/WebAssemblyFunctionCell.h:
(JSC::WebAssemblyFunctionCell::function): Deleted.
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2016-12-04 Matt Baker <mattbaker@apple.com>
Web Inspector: Assertion Failures breakpoint should respect global Breakpoints enabled setting
https://bugs.webkit.org/show_bug.cgi?id=165277
<rdar://problem/29467098>
Reviewed by Mark Lam.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
Check that breakpoints are active before pausing.
2016-12-03 Yusuke Suzuki <utatane.tea@gmail.com>
Refactor SymbolImpl layout
https://bugs.webkit.org/show_bug.cgi?id=165247
Reviewed by Darin Adler.
Use SymbolImpl::{create, createNullSymbol} instead.
* runtime/PrivateName.h:
(JSC::PrivateName::PrivateName):
2016-12-03 JF Bastien <jfbastien@apple.com>
WebAssembly: update binary format to 0xD version
https://bugs.webkit.org/show_bug.cgi?id=165345
Reviewed by Keith Miller.
As described in the following PR: https://github.com/WebAssembly/design/pull/836
Originally committed in r209175, reverted in r209242, and fixed in r209284.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::zeroForType):
(JSC::Wasm::B3IRGenerator::addConstant):
(JSC::Wasm::createJSWrapper):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::marshallArgument):
* wasm/WasmFormat.cpp:
(JSC::Wasm::toString): Deleted.
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::toB3Type): Deleted.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseType):
* wasm/WasmModuleParser.h:
* wasm/WasmParser.h:
(JSC::Wasm::Parser::parseResultType):
* wasm/generateWasm.py:
(Wasm.__init__):
* wasm/generateWasmOpsHeader.py:
(cppMacro):
(typeMacroizer):
(opcodeMacroizer):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/wasm.json:
2016-12-02 Keith Miller <keith_miller@apple.com>
Add Wasm copysign
https://bugs.webkit.org/show_bug.cgi?id=165355
Reviewed by Filip Pizlo.
This patch also makes two other important changes:
1) allows for i64 constants in the B3 generator language.
2) Fixes a bug with F64ConvertUI64 where the operation returned a Float instead
of a Double in B3.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
(CodeGenerator.generateOpcode):
(generateConstCode):
(generateI32ConstCode): Deleted.
* wasm/wasm.json:
2016-12-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209298.
https://bugs.webkit.org/show_bug.cgi?id=165359
broke the build (Requested by smfr on #webkit).
Reverted changeset:
"Add Wasm copysign"
https://bugs.webkit.org/show_bug.cgi?id=165355
http://trac.webkit.org/changeset/209298
2016-12-02 Keith Miller <keith_miller@apple.com>
Add Wasm copysign
https://bugs.webkit.org/show_bug.cgi?id=165355
Reviewed by Filip Pizlo.
This patch also makes two other important changes:
1) allows for i64 constants in the B3 generator language.
2) Fixes a bug with F64ConvertUI64 where the operation returned a Float instead
of a Double in B3.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
(CodeGenerator.generateOpcode):
(generateConstCode):
(generateI32ConstCode): Deleted.
* wasm/wasm.json:
2016-12-02 Keith Miller <keith_miller@apple.com>
Unreviewed, fix git having a breakdown over trying to reland a rollout.
2016-12-02 Keith Miller <keith_miller@apple.com>
Add Wasm floating point nearest and trunc
https://bugs.webkit.org/show_bug.cgi?id=165339
Reviewed by Saam Barati.
This patch also allows any wasm primitive type to be passed as a
string.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearestIntDouble):
(JSC::MacroAssemblerARM64::nearestIntFloat):
(JSC::MacroAssemblerARM64::truncDouble):
(JSC::MacroAssemblerARM64::truncFloat):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::nearestIntDouble):
(JSC::MacroAssemblerX86Common::nearestIntFloat):
* jsc.cpp:
(box):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F64Nearest>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32Nearest>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F64Trunc>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32Trunc>):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
2016-12-02 Caitlin Potter <caitp@igalia.com>
[JSC] add additional bit to JSTokenType bitfield
https://bugs.webkit.org/show_bug.cgi?id=165091
Reviewed by Geoffrey Garen.
Avoid overflow which causes keyword tokens to be treated as unary
tokens now that "async" is tokenized as a keyword, by granting an
additional 64 bits to be occupied by token IDs.
* parser/ParserTokens.h:
2016-12-02 Andy Estes <aestes@apple.com>
[Cocoa] Adopt the PRODUCT_BUNDLE_IDENTIFIER build setting
https://bugs.webkit.org/show_bug.cgi?id=164492
Reviewed by Dan Bernstein.
* Configurations/JavaScriptCore.xcconfig: Set PRODUCT_BUNDLE_IDENTIFIER to
com.apple.$(PRODUCT_NAME:rfc1034identifier).
* Info.plist: Changed CFBundleIdentifier's value from com.apple.${PRODUCT_NAME} to
${PRODUCT_BUNDLE_IDENTIFIER}.
2016-12-02 JF Bastien <jfbastien@apple.com>
WebAssembly: mark WasmOps.h as private
https://bugs.webkit.org/show_bug.cgi?id=165335
Reviewed by Mark Lam.
* JavaScriptCore.xcodeproj/project.pbxproj: WasmOps.h will be used by non-JSC and should therefore be private
2016-12-02 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209275 and r209276.
https://bugs.webkit.org/show_bug.cgi?id=165348
"broke the arm build" (Requested by keith_miller on #webkit).
Reverted changesets:
"Add Wasm floating point nearest and trunc"
https://bugs.webkit.org/show_bug.cgi?id=165339
http://trac.webkit.org/changeset/209275
"Unreviewed, forgot to change instruction after renaming."
http://trac.webkit.org/changeset/209276
2016-12-02 Keith Miller <keith_miller@apple.com>
Unreviewed, forgot to change instruction after renaming.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearestIntDouble):
(JSC::MacroAssemblerARM64::nearestIntFloat):
2016-12-02 Keith Miller <keith_miller@apple.com>
Add Wasm floating point nearest and trunc
https://bugs.webkit.org/show_bug.cgi?id=165339
Reviewed by Filip Pizlo.
This patch also allows any wasm primitive type to be passed as a
string.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::nearestIntDouble):
(JSC::MacroAssemblerARM64::nearestIntFloat):
(JSC::MacroAssemblerARM64::truncDouble):
(JSC::MacroAssemblerARM64::truncFloat):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::nearestIntDouble):
(JSC::MacroAssemblerX86Common::nearestIntFloat):
* jsc.cpp:
(box):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F64Nearest>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32Nearest>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F64Trunc>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32Trunc>):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
2016-12-02 JF Bastien <jfbastien@apple.com>
WebAssembly: revert patch causing odd breakage
https://bugs.webkit.org/show_bug.cgi?id=165308
Unreviewed.
Bug #164724 seems to cause build issues which I haven't tracked down yet. WasmOps.h can't be found:
./Source/JavaScriptCore/wasm/WasmFormat.h:34:10: fatal error: 'WasmOps.h' file not found
It's weird since the file is auto-generated and has been for a while. #164724 merely includes it in WasmFormat.h.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::zeroForType):
(JSC::Wasm::B3IRGenerator::addConstant):
(JSC::Wasm::createJSWrapper):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::marshallArgument):
* wasm/WasmFormat.cpp:
(JSC::Wasm::toString):
* wasm/WasmFormat.h:
(JSC::Wasm::toB3Type):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseType):
* wasm/WasmModuleParser.h:
* wasm/WasmParser.h:
(JSC::Wasm::Parser::parseResultType):
* wasm/generateWasm.py:
(Wasm.__init__):
* wasm/generateWasmOpsHeader.py:
(cppMacro):
(opcodeMacroizer):
(typeMacroizer): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/wasm.json:
2016-12-01 Brian Burg <bburg@apple.com>
Remote Inspector: fix weird typo in generated ObjC protocol type initializer implementations
https://bugs.webkit.org/show_bug.cgi?id=165295
<rdar://problem/29427778>
Reviewed by Joseph Pecoraro.
Remove a stray semicolon appended after custom initializer signatures.
This is a syntax error when building with less lenient compiler warnings.
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-12-01 Saam Barati <sbarati@apple.com>
Rename CallFrame::callee() to CallFrame::jsCallee()
https://bugs.webkit.org/show_bug.cgi?id=165293
Reviewed by Keith Miller.
Wasm will soon have its own Callee that doesn't derive
from JSObject, but derives from JSCell. I want to introduce
a new function like:
```
CalleeBase* CallFrame::callee()
```
once we have a Wasm callee. It only makes sense to name that
function callee() and rename the current one turn to:
```
JSObject* CallFrame::jsCallee()
```
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::call):
(JSC::APICallbackFunction::construct):
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::construct):
(JSC::JSCallbackObject<Parent>::call):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::scope):
(JSC::DebuggerCallFrame::type):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::friendlyFunctionName):
* interpreter/CallFrame.h:
(JSC::ExecState::jsCallee):
(JSC::ExecState::callee): Deleted.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::dumpRegisters):
(JSC::notifyDebuggerOfUnwinding):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::update):
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readNonInlinedFrame):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::traceFunctionPrologue):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
* runtime/AsyncFunctionConstructor.cpp:
(JSC::callAsyncFunctionConstructor):
(JSC::constructAsyncFunctionConstructor):
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::arityCheckFor):
* runtime/DateConstructor.cpp:
(JSC::constructWithDateConstructor):
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::createByCopying):
* runtime/Error.h:
(JSC::StrictModeTypeErrorFunction::constructThrowTypeError):
(JSC::StrictModeTypeErrorFunction::callThrowTypeError):
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
(JSC::Interpreter::callErrorConstructor):
* runtime/FunctionConstructor.cpp:
(JSC::constructWithFunctionConstructor):
(JSC::callFunctionConstructor):
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::callGeneratorFunctionConstructor):
(JSC::constructGeneratorFunctionConstructor):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
(JSC::defaultLocale):
(JSC::lookupSupportedLocales):
(JSC::intlObjectFuncGetCanonicalLocales):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSBoundFunction.cpp:
(JSC::boundThisNoArgsFunctionCall):
(JSC::boundFunctionCall):
(JSC::boundThisNoArgsFunctionConstruct):
(JSC::boundFunctionConstruct):
* runtime/JSCellInlines.h:
(JSC::ExecState::vm):
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
* runtime/JSFunction.cpp:
(JSC::callHostFunctionAsConstructor):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSInternalPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::createPair):
(JSC::JSMapIterator::clone):
* runtime/JSNativeStdFunction.cpp:
(JSC::runStdFunction):
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::clone):
* runtime/JSScope.h:
(JSC::ExecState::lexicalGlobalObject):
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::createPair):
(JSC::JSSetIterator::clone):
* runtime/JSStringIterator.cpp:
(JSC::JSStringIterator::clone):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MapPrototype.cpp:
(JSC::mapProtoFuncValues):
(JSC::mapProtoFuncEntries):
(JSC::mapProtoFuncKeys):
(JSC::privateFuncMapIterator):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
(JSC::Interpreter::callNativeErrorConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
* runtime/ProxyObject.cpp:
(JSC::performProxyCall):
(JSC::performProxyConstruct):
* runtime/ProxyRevoke.cpp:
(JSC::performProxyRevoke):
* runtime/RegExpConstructor.cpp:
(JSC::constructWithRegExpConstructor):
(JSC::callRegExpConstructor):
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::createByCopying):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/SetPrototype.cpp:
(JSC::setProtoFuncValues):
(JSC::setProtoFuncEntries):
(JSC::privateFuncSetIterator):
* runtime/StringConstructor.cpp:
(JSC::constructWithStringConstructor):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncIterator):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2016-12-01 Brian Burg <bburg@apple.com>
Web Inspector: generated code should use a framework-style import for *ProtocolArrayConversions.h
https://bugs.webkit.org/show_bug.cgi?id=165281
<rdar://problem/29427778>
Reviewed by Joseph Pecoraro.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2016-12-01 Geoffrey Garen <ggaren@apple.com>
SourceCodeKey should use unlinked source code
https://bugs.webkit.org/show_bug.cgi?id=165286
Reviewed by Saam Barati.
This patch splits out UnlinkedSourceCode from SourceCode, and deploys
UnlinkedSourceCode in SourceCodeKey.
It's misleading to store SourceCode in SourceCodeKey because SourceCode
has an absolute location whereas unlinked cached code has no location.
I plan to deploy UnlinkedSourceCode in more places, to indicate code
that has no absolute location.
* JavaScriptCore.xcodeproj/project.pbxproj:
* parser/SourceCode.cpp:
(JSC::UnlinkedSourceCode::toUTF8):
(JSC::SourceCode::toUTF8): Deleted.
* parser/SourceCode.h:
(JSC::SourceCode::SourceCode):
(JSC::SourceCode::startColumn):
(JSC::SourceCode::isHashTableDeletedValue): Deleted.
(JSC::SourceCode::hash): Deleted.
(JSC::SourceCode::view): Deleted.
(JSC::SourceCode::providerID): Deleted.
(JSC::SourceCode::isNull): Deleted.
(JSC::SourceCode::provider): Deleted.
(JSC::SourceCode::startOffset): Deleted.
(JSC::SourceCode::endOffset): Deleted.
(JSC::SourceCode::length): Deleted. Move a bunch of stuff in to a new
base class, UnlinkedSourceCode.
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::SourceCodeKey): Use UnlinkedSourceCode since code
in the cache has no location.
* parser/UnlinkedSourceCode.h: Copied from Source/JavaScriptCore/parser/SourceCode.h.
(JSC::UnlinkedSourceCode::UnlinkedSourceCode):
(JSC::UnlinkedSourceCode::provider):
(JSC::SourceCode::SourceCode): Deleted.
(JSC::SourceCode::isHashTableDeletedValue): Deleted.
(JSC::SourceCode::hash): Deleted.
(JSC::SourceCode::view): Deleted.
(JSC::SourceCode::providerID): Deleted.
(JSC::SourceCode::isNull): Deleted.
(JSC::SourceCode::provider): Deleted.
(JSC::SourceCode::firstLine): Deleted.
(JSC::SourceCode::startColumn): Deleted.
(JSC::SourceCode::startOffset): Deleted.
(JSC::SourceCode::endOffset): Deleted.
(JSC::SourceCode::length): Deleted.
(JSC::makeSource): Deleted.
(JSC::SourceCode::subExpression): Deleted.
* runtime/CodeCache.h: Use UnlinkedSourceCode in the cache.
2016-12-01 Keith Miller <keith_miller@apple.com>
Add wasm int to floating point opcodes
https://bugs.webkit.org/show_bug.cgi?id=165252
Reviewed by Geoffrey Garen.
This patch adds support for the Wasm integral type => floating point
type conversion opcodes. Most of these were already supported by B3
however there was no support for uint64 to float/double. Unfortunately,
AFAIK x86_64 does not have a single instruction that performs this
conversion. Since there is a signed conversion instruction on x86 we
use that for all uint64s that don't have the top bit set. If they do have
the top bit set we need to divide by 2 (rounding up) then convert the number
with the signed conversion then double the result.
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::convertUInt64ToDouble):
(JSC::MacroAssemblerX86_64::convertUInt64ToFloat):
* jsc.cpp:
(valueWithTypeOfWasmValue):
(box):
(functionTestWasmModuleFunctions):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<F64ConvertUI64>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::F32ConvertUI64>):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/wasm.json:
2016-12-01 Geoffrey Garen <ggaren@apple.com>
Renamed EvalCodeCache => DirectEvalCodeCache
https://bugs.webkit.org/show_bug.cgi?id=165271
Reviewed by Saam Barati.
We only use this cache for DirectEval, not IndirectEval.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::DirectEvalCodeCache::visitAggregate):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::EvalCodeCache::visitAggregate): Deleted.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::directEvalCodeCache):
(JSC::CodeBlock::evalCodeCache): Deleted.
* bytecode/DirectEvalCodeCache.h: Copied from Source/JavaScriptCore/bytecode/EvalCodeCache.h.
(JSC::EvalCodeCache::CacheKey::CacheKey): Deleted.
(JSC::EvalCodeCache::CacheKey::hash): Deleted.
(JSC::EvalCodeCache::CacheKey::isEmptyValue): Deleted.
(JSC::EvalCodeCache::CacheKey::operator==): Deleted.
(JSC::EvalCodeCache::CacheKey::isHashTableDeletedValue): Deleted.
(JSC::EvalCodeCache::CacheKey::Hash::hash): Deleted.
(JSC::EvalCodeCache::CacheKey::Hash::equal): Deleted.
(JSC::EvalCodeCache::tryGet): Deleted.
(JSC::EvalCodeCache::set): Deleted.
(JSC::EvalCodeCache::isEmpty): Deleted.
(JSC::EvalCodeCache::clear): Deleted.
* bytecode/EvalCodeCache.h: Removed.
* interpreter/Interpreter.cpp:
(JSC::eval):
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
2016-12-01 Geoffrey Garen <ggaren@apple.com>
Removed some unnecessary indirection in code generation
https://bugs.webkit.org/show_bug.cgi?id=165264
Reviewed by Keith Miller.
There's no need to route through JSGlobalObject when producing code --
it just made the code harder to read.
This patch moves functions from JSGlobalObject to their singleton
call sites.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedEvalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock): Deleted.
* runtime/CodeCache.h:
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
* runtime/IndirectEvalExecutable.cpp:
(JSC::IndirectEvalExecutable::create):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock): Deleted.
(JSC::JSGlobalObject::createLocalEvalCodeBlock): Deleted.
(JSC::JSGlobalObject::createGlobalEvalCodeBlock): Deleted.
(JSC::JSGlobalObject::createModuleProgramCodeBlock): Deleted.
* runtime/JSGlobalObject.h:
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::create):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/ProgramExecutable.h:
2016-11-30 Darin Adler <darin@apple.com>
Roll out StringBuilder changes from the previous patch.
They were a slowdown on a Kraken JSON test.
* runtime/JSONObject.cpp:
Roll out changes from below.
2016-11-30 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Specifying same module entry point multiple times cause TypeError
https://bugs.webkit.org/show_bug.cgi?id=164858
Reviewed by Saam Barati.
Allow importing the same module multiple times. Previously, when specifying the same
module in the <script type="module" src="here">, it throws TypeError.
* builtins/ModuleLoaderPrototype.js:
(requestFetch):
(requestTranslate):
(requestInstantiate):
(requestSatisfy):
2016-11-30 Yusuke Suzuki <utatane.tea@gmail.com>
WebAssembly JS API: export a module namespace object instead of a module environment
https://bugs.webkit.org/show_bug.cgi?id=165121
Reviewed by Saam Barati.
This patch setup AbstractModuleRecord further for WebAssemblyModuleRecord.
For exported entries in a wasm instance, we set up exported entries for
AbstractModuleRecord. This allows us to export WASM exported functions in
the module handling code.
Since the exported entries in the abstract module record are correctly
instantiated, the module namespace object for WASM module also starts
working correctly. So we start exposing the module namespace object
as `instance.exports` instead of the module environment object.
And we move SourceCode, lexicalVariables, and declaredVariables fields to
JSModuleRecord since they are related to JS source code (in the spec words,
they are related to the source text module record).
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::AbstractModuleRecord):
* runtime/AbstractModuleRecord.h:
(JSC::AbstractModuleRecord::sourceCode): Deleted.
(JSC::AbstractModuleRecord::declaredVariables): Deleted.
(JSC::AbstractModuleRecord::lexicalVariables): Deleted.
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::JSModuleRecord):
* runtime/JSModuleRecord.h:
(JSC::JSModuleRecord::sourceCode):
(JSC::JSModuleRecord::declaredVariables):
(JSC::JSModuleRecord::lexicalVariables):
* wasm/WasmFormat.cpp:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
* wasm/js/WebAssemblyFunction.cpp:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::create):
(JSC::WebAssemblyModuleRecord::WebAssemblyModuleRecord):
(JSC::WebAssemblyModuleRecord::finishCreation):
WebAssemblyModuleRecord::link should perform linking things.
So allocating exported entries should be done here.
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyModuleRecord.h:
2016-11-30 Mark Lam <mark.lam@apple.com>
TypeInfo::OutOfLineTypeFlags should be 16 bits in size.
https://bugs.webkit.org/show_bug.cgi?id=165224
Reviewed by Saam Barati.
There's no reason for OutOfLineTypeFlags to be constraint to 8 bits since the
space is available to us. Making OutOfLineTypeFlags 16 bits brings TypeInfo up
to 32 bits in size from the current 24 bits.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
2016-11-30 Joseph Pecoraro <pecoraro@apple.com>
REGRESSION: inspector/sampling-profiler/* LayoutTests are flaky timeouts
https://bugs.webkit.org/show_bug.cgi?id=164388
<rdar://problem/29101555>
Reviewed by Saam Barati.
There was a possibility of a deadlock between the main thread and the GC thread
with the SamplingProfiler lock when Inspector is processing samples to send to
the frontend. The Inspector (main thread) was holding the SamplingProfiler lock
while processing samples, which runs JavaScript that could trigger a GC, and
GC then tries to acquire the SamplingProfiler lock to process unprocessed samples.
A simple solution here is to tighten the bounds of when Inspector holds the
SamplingProfiler lock. It only needs the lock when extracting samples from
the SamplingProfiler. It doesn't need to hold the lock for processing those
samples, which is what can run script and cause a GC.
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
Tighten bounds of this lock to only where it is needed.
2016-11-30 Mark Lam <mark.lam@apple.com>
Proxy is not allowed in the global prototype chain.
https://bugs.webkit.org/show_bug.cgi?id=165205
Reviewed by Geoffrey Garen.
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
- We'll now throw a TypeError if we detect a Proxy in the global prototype chain.
2016-11-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209112.
https://bugs.webkit.org/show_bug.cgi?id=165208
"It regressed Octane/Raytrace and JetStream" (Requested by
saamyjoon on #webkit).
Reverted changeset:
"We should support CreateThis in the FTL"
https://bugs.webkit.org/show_bug.cgi?id=164904
http://trac.webkit.org/changeset/209112
2016-11-30 Darin Adler <darin@apple.com>
Streamline and speed up tokenizer and segmented string classes
https://bugs.webkit.org/show_bug.cgi?id=165003
Reviewed by Sam Weinig.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue): Use viewWithUnderlyingString when calling
StringBuilder::appendQuotedJSONString, since it now takes a StringView and there is
no benefit in creating a String for that function if one doesn't already exist.
2016-11-29 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: improve Instance
https://bugs.webkit.org/show_bug.cgi?id=164757
Reviewed by Keith Miller.
An Instance's `exports` property wasn't populated with exports.
According to the spec [0], `exports` should present itself as a WebAssembly
Module Record. In order to do this we need to split JSModuleRecord into
AbstractModuleRecord (without the `link` and `evaluate` functions), and
JSModuleRecord (which implements link and evaluate). We can then have a separate
WebAssemblyModuleRecord which shares most of the implementation.
`exports` then maps function names to WebAssemblyFunction and
WebAssemblyFunctionCell, which call into the B3-generated WebAssembly code.
A follow-up patch will do imports.
A few things of note:
- Use Identifier instead of String. They get uniqued, we need them for the JSModuleNamespaceObject. This is safe because JSWebAssemblyModule creation is on the main thread.
- JSWebAssemblyInstance needs to refer to the JSWebAssemblyModule used to create it, because the module owns the code, identifiers, etc. The world would be very sad if it got GC'd.
- Instance.exports shouldn't use putWithoutTransition because it affects all Structures, whereas here each instance needs its own exports.
- Expose the compiled functions, and pipe them to the InstanceConstructor. Start moving things around to split JSModuleRecord out into JS and WebAssembly parts.
[0]: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstance-constructor
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/AbstractModuleRecord.cpp: Copied from Source/JavaScriptCore/runtime/JSModuleRecord.cpp, which I split in two
(JSC::AbstractModuleRecord::AbstractModuleRecord):
(JSC::AbstractModuleRecord::destroy):
(JSC::AbstractModuleRecord::finishCreation):
(JSC::AbstractModuleRecord::visitChildren):
(JSC::AbstractModuleRecord::appendRequestedModule):
(JSC::AbstractModuleRecord::addStarExportEntry):
(JSC::AbstractModuleRecord::addImportEntry):
(JSC::AbstractModuleRecord::addExportEntry):
(JSC::identifierToJSValue):
(JSC::AbstractModuleRecord::hostResolveImportedModule):
(JSC::AbstractModuleRecord::ResolveQuery::ResolveQuery):
(JSC::AbstractModuleRecord::ResolveQuery::isEmptyValue):
(JSC::AbstractModuleRecord::ResolveQuery::isDeletedValue):
(JSC::AbstractModuleRecord::ResolveQuery::Hash::hash):
(JSC::AbstractModuleRecord::ResolveQuery::Hash::equal):
(JSC::AbstractModuleRecord::cacheResolution):
(JSC::getExportedNames):
(JSC::AbstractModuleRecord::getModuleNamespace):
(JSC::printableName):
(JSC::AbstractModuleRecord::dump):
* runtime/AbstractModuleRecord.h: Copied from Source/JavaScriptCore/runtime/JSModuleRecord.h.
(JSC::AbstractModuleRecord::ImportEntry::isNamespace):
(JSC::AbstractModuleRecord::sourceCode):
(JSC::AbstractModuleRecord::moduleKey):
(JSC::AbstractModuleRecord::requestedModules):
(JSC::AbstractModuleRecord::exportEntries):
(JSC::AbstractModuleRecord::importEntries):
(JSC::AbstractModuleRecord::starExportEntries):
(JSC::AbstractModuleRecord::declaredVariables):
(JSC::AbstractModuleRecord::lexicalVariables):
(JSC::AbstractModuleRecord::moduleEnvironment):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::webAssemblyModuleRecordStructure):
(JSC::JSGlobalObject::webAssemblyFunctionStructure):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::create):
(JSC::JSModuleEnvironment::finishCreation):
(JSC::JSModuleEnvironment::getOwnPropertySlot):
(JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames):
(JSC::JSModuleEnvironment::put):
(JSC::JSModuleEnvironment::deleteProperty):
* runtime/JSModuleEnvironment.h:
(JSC::JSModuleEnvironment::create):
(JSC::JSModuleEnvironment::offsetOfModuleRecord):
(JSC::JSModuleEnvironment::allocationSize):
(JSC::JSModuleEnvironment::moduleRecord):
(JSC::JSModuleEnvironment::moduleRecordSlot):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
(JSC::JSModuleNamespaceObject::getOwnPropertySlot):
* runtime/JSModuleNamespaceObject.h:
(JSC::JSModuleNamespaceObject::create):
(JSC::JSModuleNamespaceObject::moduleRecord):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::createStructure):
(JSC::JSModuleRecord::create):
(JSC::JSModuleRecord::JSModuleRecord):
(JSC::JSModuleRecord::destroy):
(JSC::JSModuleRecord::finishCreation):
(JSC::JSModuleRecord::visitChildren):
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSModuleRecord.h:
* runtime/JSScope.cpp:
(JSC::abstractAccess):
(JSC::JSScope::collectClosureVariablesUnderTDZ):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
* wasm/JSWebAssembly.h:
* wasm/WasmFormat.h: use Identifier instead of String
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseType):
(JSC::Wasm::ModuleParser::parseImport): fix off-by-one
(JSC::Wasm::ModuleParser::parseFunction):
(JSC::Wasm::ModuleParser::parseExport):
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::run):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h:
(JSC::JSWebAssemblyInstance::module):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
(JSC::JSWebAssemblyModule::compiledFunctions):
(JSC::JSWebAssemblyModule::exportSymbolTable):
* wasm/js/WebAssemblyFunction.cpp: Added.
(JSC::callWebAssemblyFunction):
(JSC::WebAssemblyFunction::create):
(JSC::WebAssemblyFunction::createStructure):
(JSC::WebAssemblyFunction::WebAssemblyFunction):
(JSC::WebAssemblyFunction::visitChildren):
(JSC::WebAssemblyFunction::finishCreation):
* wasm/js/WebAssemblyFunction.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.
(JSC::CallableWebAssemblyFunction::CallableWebAssemblyFunction):
(JSC::WebAssemblyFunction::webAssemblyFunctionCell):
* wasm/js/WebAssemblyFunctionCell.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h.
(JSC::WebAssemblyFunctionCell::create):
(JSC::WebAssemblyFunctionCell::WebAssemblyFunctionCell):
(JSC::WebAssemblyFunctionCell::destroy):
(JSC::WebAssemblyFunctionCell::createStructure):
* wasm/js/WebAssemblyFunctionCell.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h.
(JSC::WebAssemblyFunctionCell::function):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyModuleRecord.cpp: Added.
(JSC::WebAssemblyModuleRecord::createStructure):
(JSC::WebAssemblyModuleRecord::create):
(JSC::WebAssemblyModuleRecord::WebAssemblyModuleRecord):
(JSC::WebAssemblyModuleRecord::destroy):
(JSC::WebAssemblyModuleRecord::finishCreation):
(JSC::WebAssemblyModuleRecord::visitChildren):
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyModuleRecord.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyModule.h.
2016-11-29 Saam Barati <sbarati@apple.com>
We should be able optimize the pattern where we spread a function's rest parameter to another call
https://bugs.webkit.org/show_bug.cgi?id=163865
Reviewed by Filip Pizlo.
This patch optimizes the following patterns to prevent both the allocation
of the rest parameter, and the execution of the iterator protocol:
```
function foo(...args) {
let arr = [...args];
}
and
function foo(...args) {
bar(...args);
}
```
To do this, I've extended the arguments elimination phase to reason
about Spread and NewArrayWithSpread. I've added two new nodes, PhantomSpread
and PhantomNewArrayWithSpread. PhantomSpread is only allowed over rest
parameters that don't escape. If the rest parameter *does* escape, we can't
convert the spread into a phantom because it would not be sound w.r.t JS
semantics because we would be reading from the call frame even though
the rest array may have changed.
Note that NewArrayWithSpread also understands what to do when one of its
arguments is PhantomSpread(@PhantomCreateRest) even if it itself is escaped.
PhantomNewArrayWithSpread is only allowed over a series of
PhantomSpread(@PhantomCreateRest) nodes. Like with PhantomSpread, PhantomNewArrayWithSpread
is only allowed if none of its arguments that are being spread are escaped
and if it itself is not escaped.
Because there is a dependency between a node being a candidate and
the escaped state of the node's children, I've extended the notion
of escaping a node inside the arguments elimination phase. Now, when
any node is escaped, we must consider all other candidates that are may
now no longer be valid.
For example:
```
function foo(...args) {
escape(args);
bar(...args);
}
```
In the above program, we don't know if the function call to escape()
modifies args, therefore, the spread can not become phantom because
the execution of the spread may not be as simple as reading the
arguments from the call frame.
Unfortunately, the arguments elimination phase does not consider control
flow when doing its escape analysis. It would be good to integrate this
phase with the object allocation sinking phase. To see why, consider
an example where we don't eliminate the spread and allocation of the rest
parameter even though we could:
```
function foo(rareCondition, ...args) {
bar(...args);
if (rareCondition)
baz(args);
}
```
There are only a few users of the PhantomSpread and PhantomNewArrayWithSpread
nodes. PhantomSpread is only used by PhantomNewArrayWithSpread and NewArrayWithSpread.
PhantomNewArrayWithSpread is only used by ForwardVarargs and the various
*Call*ForwardVarargs nodes. The users of these phantoms know how to produce
what the phantom node would have produced. For example, NewArrayWithSpread
knows how to produce the values that would have been produced by PhantomSpread(@PhantomCreateRest)
by directly reading from the call frame.
This patch is a 6% speedup on my MBP on ES6SampleBench.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::tryAppendLea):
* b3/B3ValueRep.h:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createDefaultConstructor):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKillsInBlock):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasConstant):
(JSC::DFG::Node::constant):
(JSC::DFG::Node::bitVector):
(JSC::DFG::Node::isPhantomAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::LocalOSRAvailabilityCalculator::LocalOSRAvailabilityCalculator):
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSRAvailabilityAnalysisPhase.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGPromotedHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::getSpreadLengthFromInlineCallFrame):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* jsc.cpp:
(GlobalObject::finishCreation):
(functionMaxArguments):
* runtime/JSFixedArray.h:
(JSC::JSFixedArray::createFromArray):
2016-11-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r209058 and r209074.
https://bugs.webkit.org/show_bug.cgi?id=165188
These changes caused API test StringBuilderTest.Equal to crash
and/or fail. (Requested by ryanhaddad on #webkit).
Reverted changesets:
"Streamline and speed up tokenizer and segmented string
classes"
https://bugs.webkit.org/show_bug.cgi?id=165003
http://trac.webkit.org/changeset/209058
"REGRESSION (r209058): API test StringBuilderTest.Equal
crashing"
https://bugs.webkit.org/show_bug.cgi?id=165142
http://trac.webkit.org/changeset/209074
2016-11-29 Caitlin Potter <caitp@igalia.com>
[JSC] always wrap AwaitExpression operand in a new Promise
https://bugs.webkit.org/show_bug.cgi?id=165181
Reviewed by Yusuke Suzuki.
Ensure operand of AwaitExpression is wrapped in a new Promise by
explicitly creating a new Promise Capability and invoking its
resolve callback. This avoids the specified short-circuit for
Promise.resolve().
* builtins/AsyncFunctionPrototype.js:
(globalPrivate.asyncFunctionResume):
2016-11-29 Saam Barati <sbarati@apple.com>
We should support CreateThis in the FTL
https://bugs.webkit.org/show_bug.cgi?id=164904
Reviewed by Geoffrey Garen.
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
(JSC::FTL::DFG::LowerDFGToB3::storeStructure):
(JSC::FTL::DFG::LowerDFGToB3::allocateCell):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
* runtime/Structure.h:
2016-11-29 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/RegExp* files.
https://bugs.webkit.org/show_bug.cgi?id=165054
Reviewed by Saam Barati.
Also replaced returning JSValue() with returning { }.
* runtime/RegExpConstructor.cpp:
(JSC::toFlags):
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
(JSC::collectMatches):
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpObjectInlines.h:
(JSC::getRegExpObjectLastIndexAsUnsigned):
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::flagsString):
(JSC::regExpProtoFuncToString):
(JSC::regExpProtoFuncSplitFast):
2016-11-29 Andy Estes <aestes@apple.com>
[Cocoa] Enable two clang warnings recommended by Xcode
https://bugs.webkit.org/show_bug.cgi?id=164498
Reviewed by Mark Lam.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_INFINITE_RECURSION and CLANG_WARN_SUSPICIOUS_MOVE.
2016-11-29 Keith Miller <keith_miller@apple.com>
Add simple way to implement Wasm ops that require more than one B3 opcode
https://bugs.webkit.org/show_bug.cgi?id=165129
Reviewed by Geoffrey Garen.
This patch adds a simple way to show the B3IRGenerator opcode script how
to generate code for Wasm opcodes that do not have a one to one mapping.
The syntax is pretty simple right now. There are only three things one
can use as of this patch (although more things might be added in the future)
1) Wasm opcode arguments: These are referred to as @<argument_number>. For example,
I32.sub would map to Sub(@0, @1).
2) 32-bit int constants: These are reffered to as i32(<value>). For example, i32.inc
would map to Add(@0, i32(1))
3) B3 opcodes: These are referred to as the B3 opcode name followed by the B3Value's constructor
arguments. A value may take the result of another value as an argument. For example, you can do
Div(Mul(@0, Add(@0, i32(1))), i32(2)) if there was a b3 opcode that computed the sum from 1 to n.
These scripts are used to implement Wasm's eqz and floating point max/min opcodes. This patch
also adds missing support for the Wasm Neg opcodes.
* jsc.cpp:
(box):
(functionTestWasmModuleFunctions):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::toB3Op): Deleted.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseBody):
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseType):
* wasm/WasmParser.h:
(JSC::Wasm::Parser::parseUInt8):
(JSC::Wasm::Parser::parseValueType):
* wasm/generateWasmB3IRGeneratorInlinesHeader.py:
(Source):
(Source.__init__):
(read):
(lex):
(CodeGenerator):
(CodeGenerator.__init__):
(CodeGenerator.advance):
(CodeGenerator.token):
(CodeGenerator.parseError):
(CodeGenerator.consume):
(CodeGenerator.generateParameters):
(CodeGenerator.generateOpcode):
(CodeGenerator.generate):
(temp):
(generateB3OpCode):
(generateI32ConstCode):
(generateB3Code):
(generateSimpleCode):
* wasm/wasm.json:
2016-11-29 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ProxyConstructor.cpp and ProxyObject.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165053
Reviewed by Saam Barati.
Also replaced returning JSValue() with returning { }.
* runtime/ProxyConstructor.cpp:
(JSC::constructProxyObject):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::structureForTarget):
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::getOwnPropertySlotCommon):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::putByIndexCommon):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
2016-11-28 Matt Baker <mattbaker@apple.com>
Web Inspector: Debugger should have an option for showing asynchronous call stacks
https://bugs.webkit.org/show_bug.cgi?id=163230
<rdar://problem/28698683>
Reviewed by Joseph Pecoraro.
* inspector/ScriptCallFrame.cpp:
(Inspector::ScriptCallFrame::isNative):
Encapsulate check for native code source URL.
* inspector/ScriptCallFrame.h:
* inspector/ScriptCallStack.cpp:
(Inspector::ScriptCallStack::firstNonNativeCallFrame):
(Inspector::ScriptCallStack::buildInspectorArray):
* inspector/ScriptCallStack.h:
Replace use of Console::StackTrace with Array<Console::CallFrame>.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::setAsyncStackTraceDepth):
Set number of async frames to store (including boundary frames).
A value of zero disables recording of async call stacks.
(Inspector::InspectorDebuggerAgent::buildAsyncStackTrace):
Helper function for building a linked list StackTraces.
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
Store a call stack for the script that scheduled the async call.
If the call repeats (e.g. setInterval), the starting reference count is
set to 1. This ensures that dereffing after dispatch won't clear the stack.
If another async call is currently being dispatched, increment the
AsyncCallData reference count for that call.
(Inspector::InspectorDebuggerAgent::didCancelAsyncCall):
Decrement the reference count for the canceled call.
(Inspector::InspectorDebuggerAgent::willDispatchAsyncCall):
Set the identifier for the async callback currently being dispatched,
so that if the debugger pauses during dispatch a stack trace can be
associated with the pause location. If an async call is already being
dispatched, which could be the case when a script schedules an async
call in a nested runloop, do nothing.
(Inspector::InspectorDebuggerAgent::didDispatchAsyncCall):
Decrement the reference count for the canceled call.
(Inspector::InspectorDebuggerAgent::didPause):
If a stored stack trace exists for this location, convert to a protocol
object and send to the frontend.
(Inspector::InspectorDebuggerAgent::didClearGlobalObject):
(Inspector::InspectorDebuggerAgent::clearAsyncStackTraceData):
(Inspector::InspectorDebuggerAgent::refAsyncCallData):
Increment AsyncCallData reference count.
(Inspector::InspectorDebuggerAgent::derefAsyncCallData):
Decrement AsyncCallData reference count. If zero, deref its parent
(if it exists) and remove the AsyncCallData entry.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/protocol/Console.json:
* inspector/protocol/Network.json:
Replace use of Console.StackTrace with array of Console.CallFrame.
* inspector/protocol/Debugger.json:
New protocol command and event data.
2016-11-28 Darin Adler <darin@apple.com>
Streamline and speed up tokenizer and segmented string classes
https://bugs.webkit.org/show_bug.cgi?id=165003
Reviewed by Sam Weinig.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue): Use viewWithUnderlyingString when calling
StringBuilder::appendQuotedJSONString, since it now takes a StringView and there is
no benefit in creating a String for that function if one doesn't already exist.
2016-11-21 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/Intl* files.
https://bugs.webkit.org/show_bug.cgi?id=165014
Reviewed by Saam Barati.
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototypeFuncResolvedOptions):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::lookupSupportedLocales):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in IteratorOperations.h.
https://bugs.webkit.org/show_bug.cgi?id=165015
Reviewed by Saam Barati.
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSArray* files.
https://bugs.webkit.org/show_bug.cgi?id=165016
Reviewed by Saam Barati.
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::put):
(JSC::JSArray::setLength):
(JSC::JSArray::pop):
(JSC::JSArray::push):
(JSC::JSArray::unshiftCountWithAnyIndexingType):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSArrayInlines.h:
(JSC::getLength):
(JSC::toLength):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSDataView.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165020
Reviewed by Saam Barati.
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSFunction.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165021
Reviewed by Saam Barati.
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/JSGenericTypedArrayView* files.
https://bugs.webkit.org/show_bug.cgi?id=165022
Reviewed by Saam Barati.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/Operations.cpp/h.
https://bugs.webkit.org/show_bug.cgi?id=165046
Reviewed by Saam Barati.
Also switched to using returning { } instead of JSValue().
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
(JSC::jsIsObjectTypeOrNull):
* runtime/Operations.h:
(JSC::jsStringFromRegisterArray):
(JSC::jsStringFromArguments):
(JSC::jsLess):
(JSC::jsLessEq):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSScope.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165047
Reviewed by Saam Barati.
* runtime/JSScope.cpp:
(JSC::JSScope::resolve):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSTypedArrayViewPrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165049
Reviewed by Saam Barati.
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewPrivateFuncSort):
(JSC::typedArrayViewProtoFuncSet):
(JSC::typedArrayViewProtoFuncCopyWithin):
(JSC::typedArrayViewProtoFuncIncludes):
(JSC::typedArrayViewProtoFuncLastIndexOf):
(JSC::typedArrayViewProtoFuncIndexOf):
(JSC::typedArrayViewProtoFuncJoin):
(JSC::typedArrayViewProtoGetterFuncBuffer):
(JSC::typedArrayViewProtoGetterFuncLength):
(JSC::typedArrayViewProtoGetterFuncByteLength):
(JSC::typedArrayViewProtoGetterFuncByteOffset):
(JSC::typedArrayViewProtoFuncReverse):
(JSC::typedArrayViewPrivateFuncSubarrayCreate):
(JSC::typedArrayViewProtoFuncSlice):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/Map* files.
https://bugs.webkit.org/show_bug.cgi?id=165050
Reviewed by Saam Barati.
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototypeFuncNext):
* runtime/MapPrototype.cpp:
(JSC::privateFuncMapIteratorNext):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in more miscellaneous files.
https://bugs.webkit.org/show_bug.cgi?id=165102
Reviewed by Saam Barati.
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/Weak* files.
https://bugs.webkit.org/show_bug.cgi?id=165096
Reviewed by Geoffrey Garen.
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakMapPrototype.cpp:
(JSC::protoFuncWeakMapSet):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* runtime/WeakSetPrototype.cpp:
(JSC::protoFuncWeakSetAdd):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/String* files.
https://bugs.webkit.org/show_bug.cgi?id=165067
Reviewed by Saam Barati.
* runtime/StringConstructor.cpp:
(JSC::stringFromCodePoint):
(JSC::constructWithStringConstructor):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
(JSC::StringObject::defineOwnProperty):
* runtime/StringPrototype.cpp:
(JSC::jsSpliceSubstrings):
(JSC::jsSpliceSubstringsWithSeparators):
(JSC::replaceUsingRegExpSearch):
(JSC::replaceUsingStringSearch):
(JSC::repeatCharacter):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingStringSearch):
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncCodePointAt):
(JSC::stringProtoFuncConcat):
(JSC::stringProtoFuncIndexOf):
(JSC::stringProtoFuncLastIndexOf):
(JSC::splitStringByOneCharacterImpl):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstring):
(JSC::stringProtoFuncToLowerCase):
(JSC::stringProtoFuncToUpperCase):
(JSC::toLocaleCase):
(JSC::trimString):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::stringProtoFuncIterator):
(JSC::normalize):
(JSC::stringProtoFuncNormalize):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ObjectConstructor.cpp and ObjectPrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165051
Reviewed by Saam Barati.
Also,
1. Replaced returning JSValue() with returning { }.
2. Replaced uses of exec->propertyNames() with vm.propertyNames.
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::ownEnumerablePropertyKeys):
(JSC::toPropertyDescriptor):
(JSC::defineProperties):
(JSC::objectConstructorDefineProperties):
(JSC::objectConstructorCreate):
(JSC::setIntegrityLevel):
(JSC::objectConstructorSeal):
(JSC::objectConstructorPreventExtensions):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::ownPropertyKeys):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncValueOf):
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncIsPrototypeOf):
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncToLocaleString):
(JSC::objectProtoFuncToString):
2016-11-26 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in miscellaneous files.
https://bugs.webkit.org/show_bug.cgi?id=165055
Reviewed by Saam Barati.
* runtime/MathObject.cpp:
(JSC::mathProtoFuncIMul):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
(JSC::moduleLoaderPrototypeRequestedModules):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototypeFuncNext):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/TemplateRegistry.cpp:
(JSC::TemplateRegistry::getTemplateObject):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ReflectObject.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165066
Reviewed by Saam Barati.
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
(JSC::reflectObjectDefineProperty):
(JSC::reflectObjectEnumerate):
(JSC::reflectObjectGet):
(JSC::reflectObjectGetOwnPropertyDescriptor):
(JSC::reflectObjectGetPrototypeOf):
(JSC::reflectObjectOwnKeys):
(JSC::reflectObjectSet):
2016-11-24 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ArrayConstructor.cpp and ArrayPrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164972
Reviewed by Geoffrey Garen.
* runtime/ArrayConstructor.cpp:
(JSC::constructArrayWithSizeQuirk):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
(JSC::putLength):
(JSC::speciesWatchpointsValid):
(JSC::speciesConstructArray):
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::slowJoin):
(JSC::fastJoin):
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
(JSC::concatAppendOne):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
(JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
2016-11-28 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in LLIntSlowPaths.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164969
Reviewed by Geoffrey Garen.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::setUpCall):
(JSC::LLInt::varargsSetup):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2016-11-26 Yusuke Suzuki <utatane.tea@gmail.com>
[WTF] Import std::optional reference implementation as WTF::Optional
https://bugs.webkit.org/show_bug.cgi?id=164199
Reviewed by Saam Barati and Sam Weinig.
Previous WTF::Optional::operator= is not compatible to std::optional::operator=.
std::optional::emplace has the same semantics to the previous one.
So we change the code to use it.
* Scripts/builtins/builtins_templates.py:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest):
* b3/B3CheckSpecial.cpp:
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::shouldTryAliasingDef):
* b3/B3CheckSpecial.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::scaleForShl):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::tryAppendLea):
* b3/B3Opcode.cpp:
(JSC::B3::invertedCompare):
* b3/B3Opcode.h:
* b3/B3PatchpointSpecial.cpp:
(JSC::B3::PatchpointSpecial::forEachArg):
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::forEachArgImpl):
* b3/B3StackmapSpecial.h:
* b3/B3Value.cpp:
(JSC::B3::Value::invertedCompare):
* b3/air/AirArg.h:
(JSC::B3::Air::Arg::isValidScale):
(JSC::B3::Air::Arg::isValidAddrForm):
(JSC::B3::Air::Arg::isValidIndexForm):
(JSC::B3::Air::Arg::isValidForm):
* b3/air/AirCustom.h:
(JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirSpecial.cpp:
(JSC::B3::Air::Special::shouldTryAliasingDef):
* b3/air/AirSpecial.h:
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::storageForGeneratorLocal):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::findPC):
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
* bytecode/CodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::link):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ObjectPatternNode::bindValue):
* debugger/Debugger.cpp:
(JSC::Debugger::resolveBreakpoint):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::currentPosition):
* debugger/DebuggerParseData.cpp:
(JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
* debugger/DebuggerParseData.h:
* debugger/ScriptProfilingScope.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeDoubleUnaryOpEffects):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::findPC):
* dfg/DFGJITCode.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::SlowPathGenerator::generate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
(JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
(JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
(JSC::DFG::SpeculativeJIT::compileMathIC):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileLogicalNot):
(JSC::DFG::SpeculativeJIT::emitBranch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::findPC):
* ftl/FTLJITCode.h:
* heap/Heap.cpp:
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::collectInThread):
(JSC::Heap::requestCollection):
(JSC::Heap::willStartCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::shouldDoFullCollection):
* heap/Heap.h:
(JSC::Heap::collectionScope):
* heap/HeapSnapshot.cpp:
(JSC::HeapSnapshot::nodeForCell):
(JSC::HeapSnapshot::nodeForObjectIdentifier):
* heap/HeapSnapshot.h:
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::dispatch):
(Inspector::BackendDispatcher::sendPendingErrors):
(Inspector::BackendDispatcher::reportProtocolError):
* inspector/InspectorBackendDispatcher.h:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
(Inspector::InspectorHeapAgent::getPreview):
(Inspector::InspectorHeapAgent::getRemoteObject):
* inspector/agents/InspectorHeapAgent.h:
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteConnectionToTarget.mm:
(Inspector::RemoteConnectionToTarget::targetIdentifier):
(Inspector::RemoteConnectionToTarget::setup):
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::updateClientCapabilities):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(_generate_declarations_for_enum_conversion_methods):
(_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* jit/JITCode.h:
(JSC::JITCode::findPC):
* jit/JITDivGenerator.cpp:
(JSC::JITDivGenerator::generateFastPath):
* jit/JITOperations.cpp:
* jit/PCToCodeOriginMap.cpp:
(JSC::PCToCodeOriginMap::findPC):
* jit/PCToCodeOriginMap.h:
* jsc.cpp:
(WTF::RuntimeArray::getOwnPropertySlot):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* parser/ModuleAnalyzer.cpp:
(JSC::ModuleAnalyzer::exportVariable):
* runtime/ConcurrentJSLock.h:
(JSC::ConcurrentJSLocker::ConcurrentJSLocker):
* runtime/DefinePropertyAttributes.h:
(JSC::DefinePropertyAttributes::writable):
(JSC::DefinePropertyAttributes::configurable):
(JSC::DefinePropertyAttributes::enumerable):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertySlot):
(JSC::GenericArguments<Type>::put):
(JSC::GenericArguments<Type>::deleteProperty):
(JSC::GenericArguments<Type>::defineOwnProperty):
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::get):
* runtime/HashMapImpl.h:
(JSC::concurrentJSMapHash):
* runtime/Identifier.h:
(JSC::parseIndex):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toNumberFromPrimitive):
(JSC::JSValue::putToPrimitive):
* runtime/JSCJSValue.h:
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
* runtime/JSModuleRecord.cpp:
* runtime/JSModuleRecord.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::putDirectMayBeIndex):
(JSC::JSObject::defineOwnProperty):
* runtime/JSObject.h:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::putOwnDataPropertyMayBeIndex):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSString.cpp:
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::getStringPropertySlot):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/MathCommon.h:
(JSC::safeReciprocalForDivByConst):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncHasOwnProperty):
* runtime/PropertyDescriptor.h:
(JSC::toPropertyDescriptor):
* runtime/PropertyName.h:
(JSC::parseIndex):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::isStringOwnProperty):
(JSC::StringObject::deleteProperty):
* runtime/ToNativeFromValue.h:
(JSC::toNativeFromValueWithoutCoercion):
* runtime/TypedArrayAdaptors.h:
(JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
(JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion):
(JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
(JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion):
(JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion):
(JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion):
(JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion):
2016-11-26 Sam Weinig <sam@webkit.org>
Convert IntersectionObserver over to using RuntimeEnabledFeatures so it can be properly excluded from script
https://bugs.webkit.org/show_bug.cgi?id=164965
Reviewed by Simon Fraser.
* runtime/CommonIdentifiers.h:
Add identifiers needed for RuntimeEnabledFeatures.
2016-11-23 Zan Dobersek <zdobersek@igalia.com>
Remove ENABLE_ASSEMBLER_WX_EXCLUSIVE code
https://bugs.webkit.org/show_bug.cgi?id=165027
Reviewed by Darin Adler.
Remove the code guarded with ENABLE(ASSEMBLER_WX_EXCLUSIVE).
No port enables this and the guarded code doesn't build at all,
so it's safe to say it's abandoned.
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::initializeAllocator):
(JSC::ExecutableAllocator::ExecutableAllocator):
(JSC::ExecutableAllocator::reprotectRegion): Deleted.
2016-11-18 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSC profiler files.
https://bugs.webkit.org/show_bug.cgi?id=164971
Reviewed by Saam Barati.
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::addSequenceProperties):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::toJS):
(JSC::Profiler::Database::toJSON):
* profiler/ProfilerOSRExitSite.cpp:
(JSC::Profiler::OSRExitSite::toJS):
* profiler/ProfilerOriginStack.cpp:
(JSC::Profiler::OriginStack::toJS):
2016-11-22 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in JSONObject.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165025
Reviewed by Saam Barati.
* runtime/JSONObject.cpp:
(JSC::gap):
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::stringify):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
(JSC::JSONProtoFuncParse):
(JSC::JSONProtoFuncStringify):
(JSC::JSONStringify):
2016-11-21 Mark Lam <mark.lam@apple.com>
Removed an extra space character at the end of line.
Not reviewed.
* runtime/JSCell.cpp:
(JSC::JSCell::toNumber):
2016-11-21 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in FunctionConstructor.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165011
Reviewed by Saam Barati.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunction):
(JSC::constructFunctionSkippingEvalEnabledCheck):
2016-11-21 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in GetterSetter.cpp.
https://bugs.webkit.org/show_bug.cgi?id=165013
Reviewed by Saam Barati.
* runtime/GetterSetter.cpp:
(JSC::callGetter):
(JSC::callSetter):
2016-11-21 Yusuke Suzuki <utatane.tea@gmail.com>
Crash in com.apple.JavaScriptCore: WTF::ThreadSpecific<WTF::WTFThreadData, + 142
https://bugs.webkit.org/show_bug.cgi?id=164898
Reviewed by Darin Adler.
The callsite object (JSArray) of tagged template literal is managed by WeakGCMap since
same tagged template literal need to return an identical object.
The problem is that we used TemplateRegistryKey as the key of the WeakGCMap. WeakGCMap
can prune its entries in the collector thread. At that time, this TemplateRegistryKey
is deallocated. Since it includes String (and then, StringImpl), we accidentally call
ref(), deref() and StringImpl::destroy() in the different thread from the main thread
while this TemplateRegistryKey is allocated in the main thread.
Instead, we use TemplateRegistryKey* as the key of WeakGCMap. Then, to keep its liveness
while the entry of the WeakGCMap is alive, the callsite object has the reference to
the JSTemplateRegistryKey. And it holds Ref<TemplateRegistryKey>.
And now we need to lookup WeakGCMap with TemplateRegistryKey*. To do so, we create
interning system for TemplateRegistryKey. It is similar to AtomicStringTable and
SymbolRegistry. TemplateRegistryKey is allocated from this table. This table atomize the
TemplateRegistryKey. So we can use the pointer comparison between TemplateRegistryKey.
It allows us to lookup the entry from WeakGCMap by TemplateRegistryKey*.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
(JSC::BytecodeGenerator::emitGetTemplateObject):
* bytecompiler/BytecodeGenerator.h:
* runtime/JSGlobalObject.cpp:
(JSC::getTemplateObject):
* runtime/JSTemplateRegistryKey.cpp:
(JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
(JSC::JSTemplateRegistryKey::create):
* runtime/JSTemplateRegistryKey.h:
* runtime/TemplateRegistry.cpp:
(JSC::TemplateRegistry::getTemplateObject):
* runtime/TemplateRegistry.h:
* runtime/TemplateRegistryKey.cpp: Copied from Source/JavaScriptCore/runtime/TemplateRegistry.h.
(JSC::TemplateRegistryKey::~TemplateRegistryKey):
* runtime/TemplateRegistryKey.h:
(JSC::TemplateRegistryKey::calculateHash):
(JSC::TemplateRegistryKey::create):
(JSC::TemplateRegistryKey::TemplateRegistryKey):
* runtime/TemplateRegistryKeyTable.cpp: Added.
(JSC::TemplateRegistryKeyTranslator::hash):
(JSC::TemplateRegistryKeyTranslator::equal):
(JSC::TemplateRegistryKeyTranslator::translate):
(JSC::TemplateRegistryKeyTable::~TemplateRegistryKeyTable):
(JSC::TemplateRegistryKeyTable::createKey):
(JSC::TemplateRegistryKeyTable::unregister):
* runtime/TemplateRegistryKeyTable.h: Copied from Source/JavaScriptCore/runtime/JSTemplateRegistryKey.h.
(JSC::TemplateRegistryKeyTable::KeyHash::hash):
(JSC::TemplateRegistryKeyTable::KeyHash::equal):
* runtime/VM.h:
(JSC::VM::templateRegistryKeyTable):
2016-11-21 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in runtime/Error* files.
https://bugs.webkit.org/show_bug.cgi?id=164998
Reviewed by Darin Adler.
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
* runtime/ErrorInstance.h:
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
2016-11-21 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in *Executable.cpp files.
https://bugs.webkit.org/show_bug.cgi?id=164996
Reviewed by Darin Adler.
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
* runtime/IndirectEvalExecutable.cpp:
(JSC::IndirectEvalExecutable::create):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::prepareForExecutionImpl):
2016-11-20 Zan Dobersek <zdobersek@igalia.com>
[EncryptedMedia] Make EME API runtime-enabled
https://bugs.webkit.org/show_bug.cgi?id=164927
Reviewed by Jer Noble.
* runtime/CommonIdentifiers.h: Add the necessary identifiers.
2016-11-20 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ConstructData.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164976
Reviewed by Darin Adler.
* runtime/ConstructData.cpp:
(JSC::construct):
2016-11-20 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in CommonSlowPaths.cpp/h.
https://bugs.webkit.org/show_bug.cgi?id=164975
Reviewed by Darin Adler.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
2016-11-20 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in DateConstructor.cpp and DatePrototype.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164995
Reviewed by Darin Adler.
* runtime/DateConstructor.cpp:
(JSC::millisecondsFromComponents):
(JSC::constructDate):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
2016-11-20 Caitlin Potter <caitp@igalia.com>
[JSC] speed up parsing of async functions
https://bugs.webkit.org/show_bug.cgi?id=164808
Reviewed by Yusuke Suzuki.
Minor adjustments to Parser in order to mitigate slowdown with async
function parsing enabled:
- Tokenize "async" as a keyword
- Perform less branching in various areas of the Parser
* parser/Keywords.table:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::createResolveAndUseVariable):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::printUnexpectedTokenText):
* parser/Parser.h:
(JSC::isAnyContextualKeyword):
(JSC::isIdentifierOrAnyContextualKeyword):
(JSC::isSafeContextualKeyword):
(JSC::Parser::matchSpecIdentifier):
* parser/ParserTokens.h:
* runtime/CommonIdentifiers.h:
2016-11-19 Mark Lam <mark.lam@apple.com>
Add --timeoutMultiplier option to allow some tests more time to run.
https://bugs.webkit.org/show_bug.cgi?id=164951
Reviewed by Yusuke Suzuki.
* jsc.cpp:
(timeoutThreadMain):
- Modified to factor in a timeout multiplier that can adjust the timeout duration.
(startTimeoutThreadIfNeeded):
- Moved the code that starts the timeout thread here from main() so that we can
call it after command line args have been parsed instead.
(main):
- Deleted old timeout thread starting code.
(CommandLine::parseArguments):
- Added parsing of the --timeoutMultiplier option.
(jscmain):
- Start the timeout thread if needed after we've parsed the command line args.
2016-11-19 Mark Lam <mark.lam@apple.com>
Fix missing exception checks in JSC inspector files.
https://bugs.webkit.org/show_bug.cgi?id=164959
Reviewed by Saam Barati.
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::weakSetEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::scopeDescriptions):
2016-11-18 Mark Lam <mark.lam@apple.com>
Fix missing exception checks in DFGOperations.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164958
Reviewed by Geoffrey Garen.
* dfg/DFGOperations.cpp:
2016-11-18 Mark Lam <mark.lam@apple.com>
Fix exception scope verification failures in ShadowChicken.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164966
Reviewed by Saam Barati.
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::functionsOnStack):
2016-11-18 Jeremy Jones <jeremyj@apple.com>
Add runtime flag to enable pointer lock. Enable pointer lock feature for mac.
https://bugs.webkit.org/show_bug.cgi?id=163801
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-11-18 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::stronglyVisitStrongReferences):
2016-11-18 Filip Pizlo <fpizlo@apple.com>
Concurrent GC should be able to run splay in debug mode and earley/raytrace in release mode with no perf regression
https://bugs.webkit.org/show_bug.cgi?id=164282
Reviewed by Geoffrey Garen and Oliver Hunt.
The two three remaining bugs were:
- Improper ordering inside putDirectWithoutTransition() and friends. We need to make sure
that the GC doesn't see the store to Structure::m_offset until we've resized the butterfly.
That proved a bit tricky. On the other hand, this means that we could probably remove the
requirement that the GC holds the Structure lock in some cases. I haven't removed that lock
yet because I still think it might protect some weird cases, and it doesn't seem to cost us
anything.
- CodeBlock's GC strategy needed to be made thread-safe (visitWeakly, visitChildren, and
their friends now hold locks) and incremental-safe (we need to update predictions in the
finalizer to make sure we clear anything that was put into a value profile towards the end
of GC).
- The GC timeslicing scheduler needed to be made a bit more aggressive to deal with
generational workloads like earley, raytrace, and CDjs. Once I got those benchmarks to run,
I found that they would do many useless iterations of GC because they wouldn't pause long
enough after rescanning weak references and roots. I added a bunch of knobs for forcing a
pause. In the end, I realized that I could get the desired effect by putting a ceiling on
mutator utilization. We want the GC to finish quickly if it is possible to do so, even if
the amount of allocation that the mutator had done is low. Having a utilization ceiling
seems to accomplish this for benchmarks with trivial heaps (earley and raytrace) as well as
huge heaps (like CDjs in its "large" configuration).
This preserves splay performance, makes the concurrent GC more stable, and makes the
concurrent GC not a perf regression on earley or raytrace. It seems to give us great CDjs
performance as well, but this is still hard to tell because we crash a lot in that benchmark.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitWeakly):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::shouldVisitStrongly):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally):
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::stronglyVisitWeakReferences):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/Heap.cpp:
(JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
(JSC::Heap::markToFixpoint):
(JSC::Heap::beginMarking):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::collectInThread):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::mutatorFence):
* heap/MarkedBlock.cpp:
* runtime/JSCellInlines.h:
(JSC::JSCell::finishCreation):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectWithoutTransition):
(JSC::JSObject::putDirectInternal):
* runtime/Options.h:
* runtime/Structure.cpp:
(JSC::Structure::add):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::add):
2016-11-18 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Generator functions should have a displayable name when shown in stack traces
https://bugs.webkit.org/show_bug.cgi?id=164844
<rdar://problem/29300697>
Reviewed by Yusuke Suzuki.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createGeneratorFunctionBody):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGeneratorFunctionBody):
New way to create a generator function with an inferred name.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
* parser/Parser.h:
Pass on the name of the generator wrapper function so we can
use it on the inner generator function.
2016-11-17 Ryosuke Niwa <rniwa@webkit.org>
Add an experimental API to find elements across shadow boundaries
https://bugs.webkit.org/show_bug.cgi?id=164851
<rdar://problem/28220092>
Reviewed by Sam Weinig.
* runtime/CommonIdentifiers.h:
2016-11-17 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop arguments.caller
https://bugs.webkit.org/show_bug.cgi?id=164859
Reviewed by Saam Barati.
Originally, some JavaScript engine has `arguments.caller` property.
But it easily causes some information leaks and it becomes obstacles
for secure ECMAScript (SES). In ES5, we make it deprecated in strict
mode. To do so, we explicitly set "caller" getter throwing TypeError
to arguments in strict mode.
But now, there is no modern engine which supports `arguments.caller`
in sloppy mode. So the original compatibility problem is gone and
"caller" getter in the strict mode arguments becomes meaningless.
ES2017 drops this from the spec. In this patch, we also drop this
`arguments.caller` in strict mode support.
Note that Function#caller is still alive.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::put):
(JSC::ClonedArguments::deleteProperty):
(JSC::ClonedArguments::defineOwnProperty):
(JSC::ClonedArguments::materializeSpecials):
2016-11-17 Mark Lam <mark.lam@apple.com>
Inlining should be disallowed when JSC_alwaysUseShadowChicken=true.
https://bugs.webkit.org/show_bug.cgi?id=164893
<rdar://problem/29146436>
Reviewed by Saam Barati.
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
2016-11-17 Filip Pizlo <fpizlo@apple.com>
Speculatively disable eager object zero-fill on not-x86 to let the bots decide if that's a problem
https://bugs.webkit.org/show_bug.cgi?id=164885
Reviewed by Mark Lam.
This adds a useGCFences() function that we use to guard all eager object zero-fill and the
related fences. It currently returns true only on x86().
The goal here is to get the bots to tell us if this code is responsible for perf issues on
any non-x86 platforms. We have a few different paths that we can pursue if this turns out
to be the case. Eager zero-fill is merely the easiest way to optimize out some fences, but
we could get rid of it and instead teach B3 how to think about fences.
* assembler/CPU.h:
(JSC::useGCFences):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
(JSC::FTL::DFG::LowerDFGToB3::setButterfly):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::mutatorFence):
(JSC::AssemblyHelpers::storeButterfly):
(JSC::AssemblyHelpers::emitInitializeInlineStorage):
(JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
2016-11-17 Keith Miller <keith_miller@apple.com>
Add rotate to Wasm
https://bugs.webkit.org/show_bug.cgi?id=164871
Reviewed by Filip Pizlo.
Add rotate left and rotate right to Wasm. These directly map to B3 opcodes.
This also moves arm specific transformations of rotate left to lower macros
after optimization. It's a bad idea to have platform specific canonicalizations
in reduce strength since other optimizations may not be aware of it.
Add a bug to do pure CSE after lower macros after optimization since we want to
clean up RotL(value, Neg(Neg(shift))).
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3ReduceStrength.cpp:
* wasm/wasm.json:
2016-11-17 Keith Miller <keith_miller@apple.com>
Add sqrt to Wasm
https://bugs.webkit.org/show_bug.cgi?id=164877
Reviewed by Mark Lam.
B3 already has a Sqrt opcode we just need to map Wasm to it.
* wasm/wasm.json:
2016-11-17 Keith Miller <keith_miller@apple.com>
Add support for rotate in B3 and the relevant assemblers
https://bugs.webkit.org/show_bug.cgi?id=164869
Reviewed by Geoffrey Garen.
This patch runs RotR and RotL (rotate right and left respectively)
through B3 and B3's assemblers. One thing of note is that ARM64 does
not support rotate left instead it allows negative right rotations.
This patch also fixes a theoretical bug in the assembler where
on X86 doing someShiftOp(reg, edx) would instead shift the shift
amount by the value. Additionally, this patch refactors some
of the X86 assembler to use templates when deciding how to format
the appropriate shift instruction.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::rotateRight32):
(JSC::MacroAssemblerARM64::rotateRight64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::rotateRight32):
(JSC::MacroAssemblerX86Common::rotateLeft32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::lshift64):
(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::urshift64):
(JSC::MacroAssemblerX86_64::rotateRight64):
(JSC::MacroAssemblerX86_64::rotateLeft64):
(JSC::MacroAssemblerX86_64::or64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::xorq_rm):
(JSC::X86Assembler::shiftInstruction32):
(JSC::X86Assembler::sarl_i8r):
(JSC::X86Assembler::shrl_i8r):
(JSC::X86Assembler::shll_i8r):
(JSC::X86Assembler::rorl_i8r):
(JSC::X86Assembler::rorl_CLr):
(JSC::X86Assembler::roll_i8r):
(JSC::X86Assembler::roll_CLr):
(JSC::X86Assembler::shiftInstruction64):
(JSC::X86Assembler::sarq_CLr):
(JSC::X86Assembler::sarq_i8r):
(JSC::X86Assembler::shrq_i8r):
(JSC::X86Assembler::shlq_i8r):
(JSC::X86Assembler::rorq_i8r):
(JSC::X86Assembler::rorq_CLr):
(JSC::X86Assembler::rolq_i8r):
(JSC::X86Assembler::rolq_CLr):
* b3/B3Common.h:
(JSC::B3::rotateRight):
(JSC::B3::rotateLeft):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::rotRConstant):
(JSC::B3::Const32Value::rotLConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::rotRConstant):
(JSC::B3::Const64Value::rotLConstant):
* b3/B3Const64Value.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::rotRConstant):
(JSC::B3::Value::rotLConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isRotateRight32Valid):
(JSC::B3::Air::isRotateLeft32Valid):
(JSC::B3::Air::isRotateRight64Valid):
(JSC::B3::Air::isRotateLeft64Valid):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testRotR):
(JSC::B3::testRotL):
(JSC::B3::testRotRWithImmShift):
(JSC::B3::testRotLWithImmShift):
(JSC::B3::run):
2016-11-17 Saam Barati <sbarati@apple.com>
Remove async/await compile time flag and enable tests
https://bugs.webkit.org/show_bug.cgi?id=164828
<rdar://problem/28639334>
Reviewed by Yusuke Suzuki.
* Configurations/FeatureDefines.xcconfig:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseExportDeclaration):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
2016-11-17 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] WTF::TemporaryChange with WTF::SetForScope
https://bugs.webkit.org/show_bug.cgi?id=164761
Reviewed by Saam Barati.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/SetForScope.h: Removed.
* debugger/Debugger.cpp:
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::dispatch):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
(Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
(Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
(Inspector::ScriptDebugServer::sourceParsed):
(Inspector::ScriptDebugServer::dispatchFunctionToListeners):
* parser/Parser.cpp:
2016-11-16 Mark Lam <mark.lam@apple.com>
ExceptionFuzz needs to placate exception check verification before overwriting a thrown exception.
https://bugs.webkit.org/show_bug.cgi?id=164843
Reviewed by Keith Miller.
The ThrowScope will check for unchecked simulated exceptions before throwing a
new exception. This ensures that we don't quietly overwrite a pending exception
(which should never happen, with the only exception being to rethrow the same
exception). However, ExceptionFuzz works by intentionally throwing its own
exception even when one may already exist thereby potentially overwriting an
existing exception. This is ok for ExceptionFuzz testing, but we need to placate
the exception check verifier before ExceptionFuzz throws its own exception.
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
2016-11-16 Geoffrey Garen <ggaren@apple.com>
UnlinkedCodeBlock should not have a starting line number
https://bugs.webkit.org/show_bug.cgi?id=164838
Reviewed by Mark Lam.
Here's how the starting line number in UnlinkedCodeBlock used to work:
(1) Assign the source code starting line number to the parser starting
line number.
(2) Assign (1) to the AST.
(3) Subtract (1) from (2) and assign to UnlinkedCodeBlock.
Then, when linking:
(4) Add (3) to (1).
This was an awesome no-op.
Generally, unlinked code is code that is not tied to any particular
web page or resource. So, it's inappropriate to think of it having a
starting line number.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::recordParse):
(JSC::UnlinkedCodeBlock::hasCapturedVariables):
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlock):
2016-11-16 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6][WebCore] Change ES6_MODULES compile time flag to runtime flag
https://bugs.webkit.org/show_bug.cgi?id=164827
Reviewed by Ryosuke Niwa.
* Configurations/FeatureDefines.xcconfig:
2016-11-16 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out r208811. It's not sound.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
(JSC::FTL::DFG::LowerDFGToB3::setButterfly):
(JSC::FTL::DFG::LowerDFGToB3::splatWordsIfMutatorIsFenced): Deleted.
2016-11-16 Keith Miller <keith_miller@apple.com>
Wasm function parser should use template functions for each binary and unary opcode
https://bugs.webkit.org/show_bug.cgi?id=164835
Reviewed by Mark Lam.
This patch changes the wasm function parser to call into a template specialization
for each binary/unary opcode. This change makes it easier to have custom implementations
of various opcodes. It is also, in theory a speedup since it does not require switching
on the opcode twice.
* CMakeLists.txt:
* DerivedSources.make:
* wasm/WasmB3IRGenerator.cpp:
(): Deleted.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::binaryCase):
(JSC::Wasm::FunctionParser<Context>::unaryCase):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
* wasm/generateWasm.py:
(isBinary):
(isSimple):
* wasm/generateWasmB3IRGeneratorInlinesHeader.py: Added.
(generateSimpleCode):
* wasm/generateWasmOpsHeader.py:
(opcodeMacroizer):
* wasm/generateWasmValidateInlinesHeader.py:
2016-11-16 Mark Lam <mark.lam@apple.com>
ExceptionFuzz functions should use its client's ThrowScope.
https://bugs.webkit.org/show_bug.cgi?id=164834
Reviewed by Geoffrey Garen.
This is because ExceptionFuzz's purpose is to throw exceptions from its client at
exception check sites. Using the client's ThrowScope solves 2 problems:
1. If ExceptionFuzz instantiates its own ThrowScope, the simulated throw will be
mis-attributed to ExceptionFuzz when it should be attributed to its client.
2. One way exception scope verification works is by having ThrowScopes assert
that there are no unchecked simulated exceptions when the ThrowScope is
instantiated. However, ExceptionFuzz necessarily works by inserting
doExceptionFuzzingIfEnabled() in between a ThrowScope that simulated a throw
and an exception check. If we declare a ThrowScope in ExceptionFuzz's code,
we will be instantiating the ThrowScope between the point where a simulated
throw occurs and where the needed exception check can occur. Hence, having
ExceptionFuzz instantiate its own ThrowScope will fail exception scope
verification every time.
Changing ExceptionFuzz to use its client's ThrowScope resolves both problems.
Also fixed the THROW() macro in CommonSlowPaths.cpp to use the ThrowScope that
already exists in every slow path function instead of creating a new one.
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/CommonSlowPaths.cpp:
* runtime/ExceptionFuzz.cpp:
(JSC::doExceptionFuzzing):
* runtime/ExceptionFuzz.h:
(JSC::doExceptionFuzzingIfEnabled):
2016-11-16 Filip Pizlo <fpizlo@apple.com>
Slight Octane regression from concurrent GC's eager object zero-fill
https://bugs.webkit.org/show_bug.cgi?id=164823
Reviewed by Geoffrey Garen.
During concurrent GC, we need to eagerly zero-fill objects we allocate prior to
executing the end-of-allocation fence. This causes some regressions. This is an attempt
to fix those regressions by making them conditional on whether the mutator is fenced.
This is a slight speed-up on raytrace and boyer, and hopefully it will fix the
regression.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::splatWordsIfMutatorIsFenced):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
(JSC::FTL::DFG::LowerDFGToB3::setButterfly):
2016-11-16 Mark Lam <mark.lam@apple.com>
Fix exception scope checking in JSGlobalObject.cpp.
https://bugs.webkit.org/show_bug.cgi?id=164831
Reviewed by Saam Barati.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
- Use a CatchScope here because we don't ever expect JSGlobalObject initialization
to fail with errors.
(JSC::JSGlobalObject::put):
- Fix exception check requirements.
2016-11-16 Keith Miller <keith_miller@apple.com>
Unreviewed, ARM build fix.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::lowerX86Div):
(JSC::B3::Air::LowerToAir::lowerX86UDiv):
2016-11-15 Mark Lam <mark.lam@apple.com>
Make JSC test functions more robust.
https://bugs.webkit.org/show_bug.cgi?id=164807
Reviewed by Keith Miller.
* jsc.cpp:
(functionGetHiddenValue):
(functionSetHiddenValue):
2016-11-15 Keith Miller <keith_miller@apple.com>
B3 should support UDiv/UMod
https://bugs.webkit.org/show_bug.cgi?id=164811
Reviewed by Filip Pizlo.
This patch adds support for UDiv and UMod in B3. Many of the magic number
cases have been ommited for now since they are unlikely to happen in wasm
code. Most wasm code we will see is generated via llvm, which has more
robust versions of what we would do anyway. Additionally, this patch
links the new opcodes up to the wasm parser.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::uDiv32):
(JSC::MacroAssemblerARM64::uDiv64):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::x86UDiv32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::x86UDiv64):
* assembler/X86Assembler.h:
(JSC::X86Assembler::divq_r):
* b3/B3Common.h:
(JSC::B3::chillUDiv):
(JSC::B3::chillUMod):
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::uDivConstant):
(JSC::B3::Const32Value::uModConstant):
* b3/B3Const32Value.h:
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::uDivConstant):
(JSC::B3::Const64Value::uModConstant):
* b3/B3Const64Value.h:
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::lowerX86UDiv):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::uDivConstant):
(JSC::B3::Value::uModConstant):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
* b3/B3Value.h:
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize):
* b3/air/AirInstInlines.h:
(JSC::B3::Air::isX86UDiv32Valid):
(JSC::B3::Air::isX86UDiv64Valid):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testUDivArgsInt32):
(JSC::B3::testUDivArgsInt64):
(JSC::B3::testUModArgsInt32):
(JSC::B3::testUModArgsInt64):
(JSC::B3::run):
* wasm/wasm.json:
2016-11-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Preview other CSS @media in browser window (print)
https://bugs.webkit.org/show_bug.cgi?id=13530
<rdar://problem/5712928>
Reviewed by Timothy Hatcher.
* inspector/protocol/Page.json:
Update to preferred JSON style.
2016-11-15 Filip Pizlo <fpizlo@apple.com>
Unreviewed, revert renaming useConcurrentJIT to useConcurrentJS.
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/WriteBarrierInlines.h:
(JSC::WriteBarrierBase<T>::set):
(JSC::WriteBarrierBase<Unknown>::set):
2016-11-15 Geoffrey Garen <ggaren@apple.com>
Debugging and other tools should not disable the code cache
https://bugs.webkit.org/show_bug.cgi?id=164802
Reviewed by Mark Lam.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode): Updated for interface
change.
* parser/SourceCodeKey.h:
(JSC::SourceCodeFlags::SourceCodeFlags):
(JSC::SourceCodeFlags::bits):
(JSC::SourceCodeKey::SourceCodeKey): Treat debugging and other tools
as part of our key so that we can cache code while using tools. Be sure
to include these bits in our hash function so you don't get storms of
collisions as you open and close the Web Inspector.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): Treat tools as
a part of our key instead of as a reason to disable caching.
* runtime/CodeCache.h:
2016-11-15 Mark Lam <mark.lam@apple.com>
Remove JSString::SafeView and replace its uses with StringViewWithUnderlyingString.
https://bugs.webkit.org/show_bug.cgi?id=164777
Reviewed by Geoffrey Garen.
JSString::SafeView no longer achieves its intended goal to make it easier to
handle strings safely. Its clients still need to do explicit exception checks in
order to be correct. We'll remove it and replace its uses with
StringViewWithUnderlyingString instead which serves to gets the a StringView
(which is what we really wanted from SafeView) and keeps the backing String alive
while the view is in use.
Also added some missing exception checks.
* jsc.cpp:
(printInternal):
(functionDebug):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncJoin):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncJoin):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::toStringView):
(JSC::globalFuncParseFloat):
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse):
* runtime/JSString.h:
(JSC::JSString::SafeView::is8Bit): Deleted.
(JSC::JSString::SafeView::length): Deleted.
(JSC::JSString::SafeView::SafeView): Deleted.
(JSC::JSString::SafeView::get): Deleted.
(JSC::JSString::view): Deleted.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter):
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncCharCodeAt):
(JSC::stringProtoFuncIndexOf):
(JSC::stringProtoFuncNormalize):
2016-11-15 Filip Pizlo <fpizlo@apple.com>
Unreviewed, remove bogus assertion.
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint):
2016-11-15 Filip Pizlo <fpizlo@apple.com>
[mac-wk1 debug] ASSERTION FAILED: thisObject->m_propertyTableUnsafe
https://bugs.webkit.org/show_bug.cgi?id=162986
Reviewed by Saam Barati.
This assertion is wrong for concurrent GC anyway, so this removes it.
* runtime/Structure.cpp:
(JSC::Structure::visitChildren):
2016-11-15 Filip Pizlo <fpizlo@apple.com>
Rename CONCURRENT_JIT/ConcurrentJIT to CONCURRENT_JS/ConcurrentJS
https://bugs.webkit.org/show_bug.cgi?id=164791
Reviewed by Geoffrey Garen.
Just renaming.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
(JSC::ArrayProfile::briefDescriptionWithoutUpdating):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::observedArrayModes):
(JSC::ArrayProfile::mayInterceptIndexedAccesses):
(JSC::ArrayProfile::mayStoreToHole):
(JSC::ArrayProfile::outOfBounds):
(JSC::ArrayProfile::usesOriginalArrayStructures):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
(JSC::CallLinkStatus::computeFor):
(JSC::CallLinkStatus::computeExitSiteData):
(JSC::CallLinkStatus::computeFromCallLinkInfo):
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/CallLinkStatus.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::getStubInfoMap):
(JSC::CodeBlock::getCallLinkInfoMap):
(JSC::CodeBlock::getByValInfoMap):
(JSC::CodeBlock::addStubInfo):
(JSC::CodeBlock::addByValInfo):
(JSC::CodeBlock::addCallLinkInfo):
(JSC::CodeBlock::resetJITData):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::getArrayProfile):
(JSC::CodeBlock::addArrayProfile):
(JSC::CodeBlock::getOrAddArrayProfile):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::nameForRegister):
(JSC::CodeBlock::livenessAnalysisSlow):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::addFrequentExitSite):
(JSC::CodeBlock::hasExitSite):
(JSC::CodeBlock::livenessAnalysis):
* bytecode/DFGExitProfile.cpp:
(JSC::DFG::ExitProfile::add):
(JSC::DFG::ExitProfile::hasExitSite):
(JSC::DFG::QueryableExitProfile::initialize):
* bytecode/DFGExitProfile.h:
(JSC::DFG::ExitProfile::hasExitSite):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::hasExitSite):
(JSC::GetByIdStatus::computeFor):
(JSC::GetByIdStatus::computeForStubInfo):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdStatus.h:
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
(JSC::CompressedLazyOperandValueProfileHolder::add):
(JSC::LazyOperandValueProfileParser::initialize):
(JSC::LazyOperandValueProfileParser::prediction):
* bytecode/LazyOperandValueProfile.h:
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::emitReportValue):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::hasExitSite):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::computeForStubInfo):
* bytecode/PutByIdStatus.h:
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureStubClearingWatchpoint::fireInternal):
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::briefDescription):
(JSC::ValueProfileBase::computeUpdatedPrediction):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::withSpeculationFromProfile):
(JSC::DFG::ArrayMode::withProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGDriver.cpp:
(JSC::DFG::compileImpl):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryGetConstantClosureVar):
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
* jit/JITOperations.cpp:
(JSC::tryGetByValOptimize):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompileGetByValWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/JITWorklist.cpp:
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
* jit/Repatch.cpp:
(JSC::repatchGetByID):
(JSC::repatchPutByID):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
(JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
* runtime/ConcurrentJITLock.h: Removed.
* runtime/ConcurrentJSLock.h: Copied from Source/JavaScriptCore/runtime/ConcurrentJITLock.h.
(JSC::ConcurrentJSLockerBase::ConcurrentJSLockerBase):
(JSC::ConcurrentJSLockerBase::~ConcurrentJSLockerBase):
(JSC::GCSafeConcurrentJSLocker::GCSafeConcurrentJSLocker):
(JSC::GCSafeConcurrentJSLocker::~GCSafeConcurrentJSLocker):
(JSC::ConcurrentJSLocker::ConcurrentJSLocker):
(JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase): Deleted.
(JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase): Deleted.
(JSC::ConcurrentJITLockerBase::unlockEarly): Deleted.
(JSC::GCSafeConcurrentJITLocker::GCSafeConcurrentJITLocker): Deleted.
(JSC::GCSafeConcurrentJITLocker::~GCSafeConcurrentJITLocker): Deleted.
(JSC::ConcurrentJITLocker::ConcurrentJITLocker): Deleted.
* runtime/InferredType.cpp:
(JSC::InferredType::canWatch):
(JSC::InferredType::addWatchpoint):
(JSC::InferredType::willStoreValueSlow):
(JSC::InferredType::makeTopSlow):
(JSC::InferredType::set):
(JSC::InferredType::removeStructure):
* runtime/InferredType.h:
* runtime/InferredTypeTable.cpp:
(JSC::InferredTypeTable::visitChildren):
(JSC::InferredTypeTable::get):
(JSC::InferredTypeTable::willStoreValue):
(JSC::InferredTypeTable::makeTop):
* runtime/InferredTypeTable.h:
* runtime/JSEnvironmentRecord.cpp:
(JSC::JSEnvironmentRecord::heapSnapshot):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::addGlobalVar):
(JSC::JSGlobalObject::addStaticGlobals):
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
* runtime/JSObject.cpp:
(JSC::JSObject::deleteProperty):
(JSC::JSObject::shiftButterflyAfterFlattening):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectWithoutTransition):
(JSC::JSObject::putDirectInternal):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
(JSC::JSScope::collectClosureVariablesUnderTDZ):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::findVariableIndex):
(JSC::JSSegmentedVariableObject::addVariables):
(JSC::JSSegmentedVariableObject::heapSnapshot):
* runtime/JSSegmentedVariableObject.h:
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
(JSC::symbolTablePut):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::matchConcurrently):
(JSC::RegExp::compileMatchOnly):
(JSC::RegExp::deleteCode):
* runtime/RegExp.h:
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::takePropertyTableOrCloneIfPinned):
(JSC::Structure::nonPropertyTransition):
(JSC::Structure::flattenDictionaryStructure):
(JSC::Structure::ensurePropertyReplacementWatchpointSet):
(JSC::Structure::add):
(JSC::Structure::remove):
(JSC::Structure::visitChildren):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::propertyReplacementWatchpointSet):
(JSC::Structure::add):
(JSC::Structure::remove):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::visitChildren):
(JSC::SymbolTable::localToEntry):
(JSC::SymbolTable::entryFor):
(JSC::SymbolTable::prepareForTypeProfiling):
(JSC::SymbolTable::uniqueIDForVariable):
(JSC::SymbolTable::uniqueIDForOffset):
(JSC::SymbolTable::globalTypeSetForOffset):
(JSC::SymbolTable::globalTypeSetForVariable):
* runtime/SymbolTable.h:
* runtime/TypeSet.cpp:
(JSC::TypeSet::addTypeInformation):
(JSC::TypeSet::invalidateCache):
* runtime/TypeSet.h:
(JSC::TypeSet::structureSet):
* runtime/VM.h:
* runtime/WriteBarrierInlines.h:
(JSC::WriteBarrierBase<T>::set):
(JSC::WriteBarrierBase<Unknown>::set):
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::ByteCompiler::compile):
(JSC::Yarr::byteCompile):
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::BytecodePattern):
2016-11-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Remove unused and untested Page.setTouchEmulationEnabled command
https://bugs.webkit.org/show_bug.cgi?id=164793
Reviewed by Matt Baker.
* inspector/protocol/Page.json:
2016-11-15 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for Windows debug build after r208738
https://bugs.webkit.org/show_bug.cgi?id=164727
This static member variable can be touched outside of the JSC project
since inlined MacroAssembler member functions read / write it.
So it should be exported.
* assembler/MacroAssemblerX86Common.h:
2016-11-15 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: inspector/worker/debugger-pause.html fails on WebKit1
https://bugs.webkit.org/show_bug.cgi?id=164787
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
Clear this DebuggerAgent state when we resume.
2016-11-15 Filip Pizlo <fpizlo@apple.com>
It should be possible to disable concurrent GC timeslicing
https://bugs.webkit.org/show_bug.cgi?id=164788
Reviewed by Saam Barati.
Collector timeslicing means that the collector will try to pause once every 2ms. This is
great because it throttles the mutator and prevents it from outpacing the collector. But
it reduces some of the efficacy of the collectContinuously=true configuration: while
it's great that collecting continuously means that the collector will also pause more
frequently and so it will test the pausing code, it also means that the collector will
spend less time running concurrently. The primary purpose of collectContinuously is to
maximize the amount of time that the collector is running concurrently to the mutator to
maximize the likelihood that a race will cause a detectable error.
This adds an option to disable collector timeslicing (useCollectorTimeslicing=false).
The idea is that we will usually use this in conjunction with collectContinuously=true
to find race conditions during marking, but we can also use the two options
independently to focus our testing on other things.
* heap/Heap.cpp:
(JSC::Heap::markToFixpoint):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::drainInParallel): We should have added this helper ages ago.
* heap/SlotVisitor.h:
* runtime/Options.h:
2016-11-15 Filip Pizlo <fpizlo@apple.com>
The concurrent GC should have a timeslicing controller
https://bugs.webkit.org/show_bug.cgi?id=164783
Reviewed by Geoffrey Garen.
This adds a simple control system for deciding when the collector should let the mutator run
and when it should stop the mutator. We definitely have to stop the mutator during certain
collector phases, but during marking - which takes the most time - we can go either way.
Normally we want to let the mutator run, but if the heap size starts to grow then we have to
stop the mutator just to make sure it doesn't get too far ahead of the collector. That could
lead to memory exhaustion, so it's better to just stop in that case.
The controller tries to never stop the mutator for longer than short timeslices. It slices on
a 2ms period (configurable via Options). The amount of that period that the collector spends
with the mutator stopped is determined by the fraction of the collector's concurrent headroom
that has been allocated over. The headroom is currently configured at 50% of what was
allocated before the collector started.
This moves a bunch of parameters into Options so that it's easier to play with different
configurations.
I tried these different values for the period:
1ms: 30% worse than 2ms on splay-latency.
2ms: best score on splay-latency: the tick time above the 99.5% percentile is <2ms.
3ms: 40% worse than 2ms on splay-latency.
4ms: 40% worse than 2ms on splay-latency.
I also tried 100% headroom as an alternate to 50% and found it to be a worse.
This patch is a 2x improvement on splay-latency with the default parameters and concurrent GC
enabled. Prior to this change, the GC didn't have a good bound on its pause times, which
would cause these problems. Concurrent GC is now 5.6x better on splay-latency than no
concurrent GC.
* heap/Heap.cpp:
(JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
(JSC::Heap::markToFixpoint):
(JSC::Heap::collectInThread):
* runtime/Options.h:
2016-11-15 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for CLoop after r208738
https://bugs.webkit.org/show_bug.cgi?id=164727
* jsc.cpp:
(WTF::DOMJITFunctionObject::unsafeFunction):
(WTF::DOMJITFunctionObject::finishCreation):
2016-11-15 Mark Lam <mark.lam@apple.com>
The jsc shell's setImpureGetterDelegate() should ensure that the set value is an ImpureGetter.
https://bugs.webkit.org/show_bug.cgi?id=164781
<rdar://problem/28418590>
Reviewed by Geoffrey Garen and Michael Saboff.
* jsc.cpp:
(functionSetImpureGetterDelegate):
2016-11-15 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Allow using macro assembler scratches in FTL CheckDOM
https://bugs.webkit.org/show_bug.cgi?id=164727
Reviewed by Filip Pizlo.
While CallDOMGetter can use macro assembler scratch registers, we previiously
assumed that CheckDOM code generator does not use macro assembler scratch registers.
It is currently true in x86 environment. But it is not true in the other environments.
We should not limit DOMJIT::Patchpoint's functionality in such a way. We should allow
arbitrary macro assembler operations inside the DOMJIT::Patchpoint. This patch allows
CheckDOM to use macro assembler scratch registers.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
* jsc.cpp:
(WTF::DOMJITFunctionObject::DOMJITFunctionObject):
(WTF::DOMJITFunctionObject::createStructure):
(WTF::DOMJITFunctionObject::create):
(WTF::DOMJITFunctionObject::unsafeFunction):
(WTF::DOMJITFunctionObject::safeFunction):
(WTF::DOMJITFunctionObject::checkDOMJITNode):
(WTF::DOMJITFunctionObject::finishCreation):
(GlobalObject::finishCreation):
(functionCreateDOMJITFunctionObject):
2016-11-14 Geoffrey Garen <ggaren@apple.com>
CodeCache should stop pretending to cache builtins
https://bugs.webkit.org/show_bug.cgi?id=164750
Reviewed by Saam Barati.
We were passing JSParserBuiltinMode to all CodeCache functions, but the
passed-in value was always NotBuiltin.
Let's stop passing it.
* parser/SourceCodeKey.h:
(JSC::SourceCodeFlags::SourceCodeFlags):
(JSC::SourceCodeKey::SourceCodeKey):
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
(JSC::CodeCache::getUnlinkedProgramCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock):
(JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
(JSC::generateUnlinkedCodeBlock):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createLocalEvalCodeBlock):
(JSC::JSGlobalObject::createGlobalEvalCodeBlock):
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
2016-11-15 Filip Pizlo <fpizlo@apple.com>
REGRESSION (r208711-r208722): ASSERTION FAILED: hasInlineStorage()
https://bugs.webkit.org/show_bug.cgi?id=164775
Reviewed by Mark Lam and Keith Miller.
We were calling inlineStorage() which asserts that inline storage is not empty. But we
were calling it in a context where it could be empty and that's fine. So, we now call
inlineStorageUnsafe().
* runtime/JSObject.h:
(JSC::JSFinalObject::JSFinalObject):
2016-11-14 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Unreviewed buildfix after r208720.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::storeFence): Stub function copied from MacroAssemblerARMv7.h.
2016-11-14 Caitlin Potter <caitp@igalia.com>
[JSC] do not reference AwaitExpression Promises in async function Promise chain
https://bugs.webkit.org/show_bug.cgi?id=164753
Reviewed by Yusuke Suzuki.
Previously, long-running async functions which contained many AwaitExpressions
would allocate and retain references to intermediate Promise objects for each `await`,
resulting in a memory leak.
To mitigate this leak, a reference to the original Promise (and its resolve and reject
functions) associated with the async function are kept, and passed to each call to
@asyncFunctionResume, while intermediate Promises are discarded. This is done by adding
a new Register to the BytecodeGenerator to hold the PromiseCapability object associated
with an async function wrapper. The capability is used to reject the Promise if an
exception is thrown during parameter initialization, and is used to store the resulting
value once the async function has terminated.
* builtins/AsyncFunctionPrototype.js:
(globalPrivate.asyncFunctionResume):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::promiseCapabilityRegister):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
2016-11-14 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Worker debugging should pause all targets and view call frames in all targets
https://bugs.webkit.org/show_bug.cgi?id=164305
<rdar://problem/29056192>
Reviewed by Timothy Hatcher.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._propertyDescriptors):
Accessing __proto__ does a ToThis(...) conversion on the receiver.
In the case of GlobalObjects (such as WorkerGlobalScope when paused)
this would return undefined and throw an exception. We can use
Object.getPrototypeOf to avoid that conversion and possible error.
* inspector/protocol/Debugger.json:
Provide a new way to effectively `resume` + `pause` immediately.
This must be implemented on the backend to correctly synchronize
the resuming and pausing.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::continueUntilNextRunLoop):
Treat this as `resume` and `pause`. Resume now, and trigger
a pause if the VM becomes idle and we didn't pause before then
(such as hitting a breakpoint after we resumed).
(Inspector::InspectorDebuggerAgent::pause):
(Inspector::InspectorDebuggerAgent::resume):
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
(Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement):
Clean up and correct pause on next statement logic.
(Inspector::InspectorDebuggerAgent::registerIdleHandler):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping): Deleted.
The idle handler may now also trigger a pause in the case
where continueUntilNextRunLoop resumed and wants to pause.
(Inspector::InspectorDebuggerAgent::didPause):
Eliminate the useless didPause. The DOMDebugger was keeping track
of its own state that was worse then the state in DebuggerAgent.
2016-11-14 Filip Pizlo <fpizlo@apple.com>
Unreviewed, fix cloop.
* runtime/JSCellInlines.h:
2016-11-14 Filip Pizlo <fpizlo@apple.com>
The GC should be optionally concurrent and disabled by default
https://bugs.webkit.org/show_bug.cgi?id=164454
Reviewed by Geoffrey Garen.
This started out as a patch to have the GC scan the stack at the end, and then the
outage happened and I decided to pick a more aggresive target: give the GC a concurrent
mode that can be enabled at runtime, and whose only effect is that it turns on the
ResumeTheWorldScope. This gives our GC a really intuitive workflow: by default, the GC
thread is running solo with the world stopped and the parallel markers converged and
waiting. We have a parallel work scope to enable the parallel markers and now we have a
ResumeTheWorldScope that will optionally resume the world and then stop it again.
It's easy to make a concurrent GC that always instantly crashes. I can't promise that
this one won't do that when you run it. I set a specific goal: I wanted to do >10
concurrent GCs in debug mode with generations, optimizing JITs, and parallel marking
disabled.
To reach this milestone, I needed to do a bunch of stuff:
- The mutator needs a separate mark stack for the barrier, since it will mutate this
stack concurrently to the collector's slot visitors.
- The use of CellState to indicate whether an object is being scanned the first time or
a subsequent time was racy. It fails spectacularly when a barrier is fired at the same
time as visitChildren is running or if the barrier runs at the same time as the GC
marks the same object. So, I split SlotVisitor's mark stacks. It's now the case that
you know why you're being scanned by looking at which stack you came off of.
- All of root marking must be in the collector fixpoint. I renamed markRoots to
markToFixpoint. They say concurrency is hard, but the collector looks more intuitive
this way. We never gained anything from forcing people to make a choice between
scanning something in the fixpoint versus outside of it. Because root scanning is
cheap, we can afford to do it repeatedly, which means all root scanning can now do
constraint-based marking (like: I'll mark you if that thing is marked).
- JSObject::visitChildren's scanning of the butterfly raced with property additions,
indexed storage transitions and resizing, and a bunch of miscellaneous dirty butterfly
reshaping functions - like the one that flattens a dictionary and some sneaky
ArrayStorage transformations. Many of these can be fixed by using store-store fences
in the mutator and load-load fences in the collector. I've adopted the rule that the
collector must always see either a butterfly and structure that match or a newer
butterfly with an older structure, where their age is just one transition apart. This
can be achieved with fences. For the cases where it breaks down, I added a lock to
every JSCell. This is a full-fledged WTF lock that we sneak into two available bits in
the indexingType. See the WTF ChangeLog for details.
The mutator fencing rules are as follows:
- Store-store fence before and after setting the butterfly.
- Store-store fence before setting structure if you had changed the shape of the
butterfly.
- Store-store fence after initializing all fields in an allocation.
- A dictionary Structure can change in strange ways while the GC is trying to scan it.
So, JSObject::visitChildren will now grab the object's structure's lock if the
object's structure is a dictionary. Dictionary structures are 1:1 with their object,
so this does not reduce GC parallelism (super unlikely that the GC will simultaneously
scan an object from two threads).
- The GC can blow away a Structure's property table at any time. As a small consolation,
it's now holding the Structure's lock when it does so. But there was tons of code in
Structure that uses DeferGC to prevent the GC from blowing away the property table.
This doesn't work with concurrent GC, since DeferGC only means that the GC won't run
its safepoint (i.e. stop-the-world code) in the DeferGC region. It will still do
marking and it was the Structure::visitChildren that would delete the table. It turns
out that Structure's reliance on the property table not being deleted was the product
of code rot. We already had functions that would materialize the table on demand. We
were simply making the mistake of saying:
structure->materializePropertyMap();
...
structure->propertyTable()->things
Instead of saying:
PropertyTable* table = structure->ensurePropertyTable();
...
table->things
Switching the code to use the latter idiom allowed me to simplify the code a lot while
fixing the race.
- The LLInt's get_by_val handling was broken because the indexing shape constants were
wrong. Once I started putting more things into the IndexingType, that started causing
crashes for me. So I fixed LLInt. That turned out to be a lot of work, since that code
had rotted in subtle ways.
This is a speed-up in SunSpider, probably because of the LLInt fix. This is neutral on
Octane and Kraken. It's a smaller slow-down on LongSpider, but I think we can ignore
that (we don't view LongSpider as an official benchmark). By default, the concurrent GC
is disabled: in all of the places where it would have resumed the world to run marking
concurrently to the mutator, it will just skip the resume step. When you enable
concurrent GC (--useConcurrentGC=true), it can sometimes run Octane/splay to completion.
It seems to perform quite well: on my machine, it improves both splay-throughput and
splay-latency. It's probably unstable for other programs.
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine isOldExternalObject:]):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::storeFence):
* bytecode/InlineAccess.cpp:
(JSC::InlineAccess::dumpCacheSizesAndCrash):
(JSC::InlineAccess::generateSelfPropertyAccess):
(JSC::InlineAccess::generateArrayLength):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfile::offsetOfInlineCapacity):
(JSC::ObjectAllocationProfile::ObjectAllocationProfile):
(JSC::ObjectAllocationProfile::initialize):
(JSC::ObjectAllocationProfile::inlineCapacity):
(JSC::ObjectAllocationProfile::clear):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* dfg/DFGArrayifySlowPathGenerator.h:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOperations.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::markCodeBlocks):
(JSC::DFG::Plan::rememberCodeBlocks):
* dfg/DFGPlan.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::arrayify):
(JSC::DFG::SpeculativeJIT::compileMakeRope):
(JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
(JSC::DFG::SpeculativeJIT::compileCreateActivation):
(JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileNewStringObject):
(JSC::DFG::SpeculativeJIT::compileNewTypedArray):
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::markCodeBlocks):
(JSC::DFG::Worklist::rememberCodeBlocks):
(JSC::DFG::markCodeBlocks):
(JSC::DFG::completeAllPlansForVM):
(JSC::DFG::rememberCodeBlocks):
* dfg/DFGWorklist.h:
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
(JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::splatWords):
(JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::allocateObject):
(JSC::FTL::DFG::LowerDFGToB3::isArrayType):
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
(JSC::FTL::DFG::LowerDFGToB3::mutatorFence):
(JSC::FTL::DFG::LowerDFGToB3::setButterfly):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::signExt32ToPtr):
(JSC::FTL::Output::fence):
* ftl/FTLOutput.h:
* heap/CellState.h:
* heap/GCSegmentedArray.h:
* heap/Heap.cpp:
(JSC::Heap::ResumeTheWorldScope::ResumeTheWorldScope):
(JSC::Heap::ResumeTheWorldScope::~ResumeTheWorldScope):
(JSC::Heap::Heap):
(JSC::Heap::~Heap):
(JSC::Heap::harvestWeakReferences):
(JSC::Heap::finalizeUnconditionalFinalizers):
(JSC::Heap::completeAllJITPlans):
(JSC::Heap::markToFixpoint):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::beginMarking):
(JSC::Heap::visitConservativeRoots):
(JSC::Heap::visitCompilerWorklistWeakReferences):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::endMarking):
(JSC::Heap::addToRememberedSet):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::setGCDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::setMutatorWaiting):
(JSC::Heap::clearMutatorWaiting):
(JSC::Heap::finalize):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::writeBarrierSlowPath):
(JSC::Heap::canCollect):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
(JSC::Heap::notifyIsSafeToCollect):
(JSC::Heap::markRoots): Deleted.
(JSC::Heap::visitExternalRememberedSet): Deleted.
(JSC::Heap::visitSmallStrings): Deleted.
(JSC::Heap::visitProtectedObjects): Deleted.
(JSC::Heap::visitArgumentBuffers): Deleted.
(JSC::Heap::visitException): Deleted.
(JSC::Heap::visitStrongHandles): Deleted.
(JSC::Heap::visitHandleStack): Deleted.
(JSC::Heap::visitSamplingProfiler): Deleted.
(JSC::Heap::visitTypeProfiler): Deleted.
(JSC::Heap::visitShadowChicken): Deleted.
(JSC::Heap::traceCodeBlocksAndJITStubRoutines): Deleted.
(JSC::Heap::visitWeakHandles): Deleted.
(JSC::Heap::flushOldStructureIDTables): Deleted.
(JSC::Heap::stopAllocation): Deleted.
* heap/Heap.h:
(JSC::Heap::collectorSlotVisitor):
(JSC::Heap::mutatorMarkStack):
(JSC::Heap::mutatorShouldBeFenced):
(JSC::Heap::addressOfMutatorShouldBeFenced):
(JSC::Heap::slotVisitor): Deleted.
(JSC::Heap::notifyIsSafeToCollect): Deleted.
(JSC::Heap::barrierShouldBeFenced): Deleted.
(JSC::Heap::addressOfBarrierShouldBeFenced): Deleted.
* heap/MarkStack.cpp:
(JSC::MarkStackArray::transferTo):
* heap/MarkStack.h:
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::tryAllocateIn):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::MarkedBlock):
(JSC::MarkedBlock::Handle::specializedSweep):
(JSC::MarkedBlock::Handle::sweep):
(JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::didConsumeFreeList):
(JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): Deleted.
(JSC::SetNewlyAllocatedFunctor::operator()): Deleted.
* heap/MarkedBlock.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::resumeAllocating):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::~SlotVisitor):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::clearMarkStacks):
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
(JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::appendToMutatorMarkStack):
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::donateKnownParallel):
(JSC::SlotVisitor::drain):
(JSC::SlotVisitor::drainFromShared):
(JSC::SlotVisitor::containsOpaqueRoot):
(JSC::SlotVisitor::donateAndDrain):
(JSC::SlotVisitor::mergeOpaqueRoots):
(JSC::SlotVisitor::dump):
(JSC::SlotVisitor::clearMarkStack): Deleted.
(JSC::SlotVisitor::opaqueRootCount): Deleted.
* heap/SlotVisitor.h:
(JSC::SlotVisitor::collectorMarkStack):
(JSC::SlotVisitor::mutatorMarkStack):
(JSC::SlotVisitor::isEmpty):
(JSC::SlotVisitor::bytesVisited):
(JSC::SlotVisitor::markStack): Deleted.
(JSC::SlotVisitor::bytesCopied): Deleted.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExternalMemoryVisited):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
(JSC::AssemblyHelpers::barrierStoreLoadFence):
(JSC::AssemblyHelpers::mutatorFence):
(JSC::AssemblyHelpers::storeButterfly):
(JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded):
(JSC::AssemblyHelpers::emitInitializeInlineStorage):
(JSC::AssemblyHelpers::emitInitializeOutOfLineStorage):
(JSC::AssemblyHelpers::jumpIfBarrierStoreLoadFenceNotNeeded): Deleted.
* jit/JITInlines.h:
(JSC::JIT::emitArrayProfilingSiteWithCell):
* jit/JITOperations.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_to_scope):
(JSC::JIT::emit_op_put_to_arguments):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ButterflyInlines.h:
(JSC::Butterfly::create):
(JSC::Butterfly::createOrGrowPropertyStorage):
* runtime/ConcurrentJITLock.h:
(JSC::GCSafeConcurrentJITLocker::NoDefer::NoDefer): Deleted.
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
(JSC::GenericArguments<Type>::putByIndex):
* runtime/IndexingType.h:
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
(JSC::JSArray::unshiftCountWithArrayStorage):
* runtime/JSCell.h:
(JSC::JSCell::InternalLocker::InternalLocker):
(JSC::JSCell::InternalLocker::~InternalLocker):
(JSC::JSCell::atomicCompareExchangeCellStateWeakRelaxed):
(JSC::JSCell::atomicCompareExchangeCellStateStrong):
(JSC::JSCell::indexingTypeAndMiscOffset):
(JSC::JSCell::indexingTypeOffset): Deleted.
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
(JSC::JSCell::finishCreation):
(JSC::JSCell::indexingTypeAndMisc):
(JSC::JSCell::indexingType):
(JSC::JSCell::setStructure):
(JSC::JSCell::callDestructor):
(JSC::JSCell::lockInternalLock):
(JSC::JSCell::unlockInternalLock):
* runtime/JSObject.cpp:
(JSC::JSObject::visitButterfly):
(JSC::JSObject::visitChildren):
(JSC::JSFinalObject::visitChildren):
(JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::createArrayStorage):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::increaseVectorLength):
(JSC::JSObject::ensureLengthSlow):
(JSC::JSObject::reallocateAndShrinkButterfly):
(JSC::JSObject::allocateMoreOutOfLineStorage):
(JSC::JSObject::shiftButterflyAfterFlattening):
(JSC::JSObject::growOutOfLineStorage): Deleted.
* runtime/JSObject.h:
(JSC::JSFinalObject::JSFinalObject):
(JSC::JSObject::setButterfly):
(JSC::JSObject::getOwnNonIndexPropertySlot):
(JSC::JSObject::fillCustomGetterPropertySlot):
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::setStructureAndButterfly): Deleted.
(JSC::JSObject::setButterflyWithoutChangingStructure): Deleted.
(JSC::JSObject::putDirectInternal): Deleted.
(JSC::JSObject::putDirectWithoutTransition): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
(JSC::JSObject::putDirectWithoutTransition):
(JSC::JSObject::putDirectInternal):
* runtime/Options.h:
* runtime/SparseArrayValueMap.h:
* runtime/Structure.cpp:
(JSC::Structure::dumpStatistics):
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::changePrototypeTransition):
(JSC::Structure::attributeChangeTransition):
(JSC::Structure::toDictionaryTransition):
(JSC::Structure::takePropertyTableOrCloneIfPinned):
(JSC::Structure::nonPropertyTransition):
(JSC::Structure::isSealed):
(JSC::Structure::isFrozen):
(JSC::Structure::flattenDictionaryStructure):
(JSC::Structure::pin):
(JSC::Structure::pinForCaching):
(JSC::Structure::willStoreValueSlow):
(JSC::Structure::copyPropertyTableForPinning):
(JSC::Structure::add):
(JSC::Structure::remove):
(JSC::Structure::getPropertyNamesFromStructure):
(JSC::Structure::visitChildren):
(JSC::Structure::materializePropertyMap): Deleted.
(JSC::Structure::addPropertyWithoutTransition): Deleted.
(JSC::Structure::removePropertyWithoutTransition): Deleted.
(JSC::Structure::copyPropertyTable): Deleted.
(JSC::Structure::createPropertyMap): Deleted.
(JSC::PropertyTable::checkConsistency): Deleted.
(JSC::Structure::checkConsistency): Deleted.
* runtime/Structure.h:
* runtime/StructureIDBlob.h:
(JSC::StructureIDBlob::StructureIDBlob):
(JSC::StructureIDBlob::indexingTypeIncludingHistory):
(JSC::StructureIDBlob::setIndexingTypeIncludingHistory):
(JSC::StructureIDBlob::indexingTypeIncludingHistoryOffset):
(JSC::StructureIDBlob::indexingType): Deleted.
(JSC::StructureIDBlob::setIndexingType): Deleted.
(JSC::StructureIDBlob::indexingTypeOffset): Deleted.
* runtime/StructureInlines.h:
(JSC::Structure::get):
(JSC::Structure::checkOffsetConsistency):
(JSC::Structure::checkConsistency):
(JSC::Structure::add):
(JSC::Structure::remove):
(JSC::Structure::addPropertyWithoutTransition):
(JSC::Structure::removePropertyWithoutTransition):
(JSC::Structure::setPropertyTable):
(JSC::Structure::putWillGrowOutOfLineStorage): Deleted.
(JSC::Structure::propertyTable): Deleted.
(JSC::Structure::suggestedNewOutOfLineStorageCapacity): Deleted.
2016-11-14 Keith Miller <keith_miller@apple.com>
Add Wasm select
https://bugs.webkit.org/show_bug.cgi?id=164743
Reviewed by Saam Barati.
Also, this patch fixes an issue with the jsc.cpp test harness where negative numbers would be sign extended
when they shouldn't be.
* jsc.cpp:
(box):
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::addSelect):
2016-11-11 Geoffrey Garen <ggaren@apple.com>
JSC should distinguish between local and global eval
https://bugs.webkit.org/show_bug.cgi?id=164628
Reviewed by Saam Barati.
Local use of the 'eval' keyword and invocation of the global window.eval
function are distinct operations in JavaScript.
This patch splits out LocalEvalExecutable vs GlobalEvalExecutable in
order to help distinguish these operations in code.
Our code used to do some silly things for lack of distinguishing these
cases. For example, it would double cache local eval in CodeCache and
EvalCodeCache. This made CodeCache seem more complicated than it really
was.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj: Added some files.
* bytecode/CodeBlock.h:
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::tryGet):
(JSC::EvalCodeCache::set):
(JSC::EvalCodeCache::getSlow): Deleted. Moved code generation out of
the cache to avoid tight coupling. Now the cache just caches.
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::fromGlobalCode):
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecode/UnlinkedProgramCodeBlock.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension): Updated for interface
changes.
* interpreter/Interpreter.cpp:
(JSC::eval): Moved code generation here so the cache didn't need to build
it in.
* llint/LLIntOffsetsExtractor.cpp:
* runtime/CodeCache.cpp:
(JSC::CodeCache::getUnlinkedGlobalCodeBlock): No need to check for TDZ
variables any more. We only cache global programs, and global variable
access always does TDZ checks.
(JSC::CodeCache::getUnlinkedProgramCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalEvalCodeBlock):
(JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
(JSC::CodeCache::CodeCache): Deleted.
(JSC::CodeCache::~CodeCache): Deleted.
(JSC::CodeCache::getGlobalCodeBlock): Deleted.
(JSC::CodeCache::getProgramCodeBlock): Deleted.
(JSC::CodeCache::getEvalCodeBlock): Deleted.
(JSC::CodeCache::getModuleProgramCodeBlock): Deleted.
(JSC::CodeCache::getFunctionExecutableFromGlobalCode): Deleted.
* runtime/CodeCache.h:
(JSC::CodeCache::clear):
(JSC::generateUnlinkedCodeBlock): Moved unlinked code block creation
out of the CodeCache class and into a stand-alone function because
we need it for local eval, which does not live in CodeCache.
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::create): Deleted.
* runtime/EvalExecutable.h:
(): Deleted.
* runtime/GlobalEvalExecutable.cpp: Added.
(JSC::GlobalEvalExecutable::create):
(JSC::GlobalEvalExecutable::GlobalEvalExecutable):
* runtime/GlobalEvalExecutable.h: Added.
* runtime/LocalEvalExecutable.cpp: Added.
(JSC::LocalEvalExecutable::create):
(JSC::LocalEvalExecutable::LocalEvalExecutable):
* runtime/LocalEvalExecutable.h: Added. Split out Local vs Global
EvalExecutable classes to distinguish these operations in code. The key
difference is that LocalEvalExecutable does not live in the CodeCache
and only lives in the EvalCodeCache.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::createProgramCodeBlock):
(JSC::JSGlobalObject::createLocalEvalCodeBlock):
(JSC::JSGlobalObject::createGlobalEvalCodeBlock):
(JSC::JSGlobalObject::createModuleProgramCodeBlock):
(JSC::JSGlobalObject::createEvalCodeBlock): Deleted.
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSScope.cpp:
(JSC::JSScope::collectClosureVariablesUnderTDZ):
(JSC::JSScope::collectVariablesUnderTDZ): Deleted. We don't include
global lexical variables in our concept of TDZ scopes anymore. Global
variable access always does TDZ checks unconditionally. So, only closure
scope accesses give specific consideration to TDZ checks.
* runtime/JSScope.h:
2016-11-14 Caitlin Potter <caitp@igalia.com>
[JSC] Handle new_async_func / new_async_func_exp in DFG / FTL
https://bugs.webkit.org/show_bug.cgi?id=164037
Reviewed by Yusuke Suzuki.
This patch introduces new_async_func / new_async_func_exp into DFG and FTL,
in much the same capacity that https://trac.webkit.org/changeset/194216 added
DFG / FTL support for generators: by adding new DFG nodes (NewAsyncFunction and
PhantomNewAsyncFunction), rather than extending the existing NewFunction node type.
Like NewFunction and PhantomNewFunction, and the Generator variants, allocation of
async wrapper functions may be deferred or eliminated during the allocation sinking
phase.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewFunction):
(JSC::DFG::Node::convertToPhantomNewAsyncFunction):
(JSC::DFG::Node::hasCellOperand):
(JSC::DFG::Node::isFunctionAllocation):
(JSC::DFG::Node::isPhantomFunctionAllocation):
(JSC::DFG::Node::isPhantomAllocation):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewFunction):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::asyncFunctionPrototype):
(JSC::JSGlobalObject::asyncFunctionStructure):
(JSC::JSGlobalObject::lazyAsyncFunctionStructure): Deleted.
(JSC::JSGlobalObject::asyncFunctionPrototypeConcurrently): Deleted.
(JSC::JSGlobalObject::asyncFunctionStructureConcurrently): Deleted.
2016-11-14 Mark Lam <mark.lam@apple.com>
Some of JSStringView::SafeView methods are not idiomatically safe for JSString to StringView conversions.
https://bugs.webkit.org/show_bug.cgi?id=164701
<rdar://problem/27462104>
Reviewed by Darin Adler.
The characters8(), characters16(), and operator[] in JSString::SafeView converts
the underlying JSString to a StringView via get(), and then uses the StringView
without first checking if an exception was thrown during the conversion. This is
unsafe because the conversion may have failed.
Instead, we should remove these 3 convenience methods, and make the caller
explicitly call get() and do the appropriate exception checks before using the
StringView.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::toStringView):
(JSC::encode):
(JSC::decode):
(JSC::globalFuncParseInt):
(JSC::globalFuncEscape):
(JSC::globalFuncUnescape):
(JSC::toSafeView): Deleted.
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse):
* runtime/JSString.h:
(JSC::JSString::SafeView::length):
(JSC::JSString::SafeView::characters8): Deleted.
(JSC::JSString::SafeView::characters16): Deleted.
(JSC::JSString::SafeView::operator[]): Deleted.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter):
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncCharCodeAt):
(JSC::stringProtoFuncNormalize):
2016-11-14 Mark Lam <mark.lam@apple.com>
RegExpObject::exec/match should handle errors gracefully.
https://bugs.webkit.org/show_bug.cgi?id=155145
<rdar://problem/27435934>
Reviewed by Keith Miller.
1. Added some missing exception checks to RegExpObject::execInline() and
RegExpObject::matchInline().
2. Updated related code to work with ExceptionScope verification requirements.
* dfg/DFGOperations.cpp:
* runtime/RegExpObjectInlines.h:
(JSC::RegExpObject::execInline):
(JSC::RegExpObject::matchInline):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncTestFast):
(JSC::regExpProtoFuncExec):
(JSC::regExpProtoFuncMatchFast):
2016-11-13 Mark Lam <mark.lam@apple.com>
Add debugging facility to limit the max single allocation size.
https://bugs.webkit.org/show_bug.cgi?id=164681
Reviewed by Keith Miller.
Added JSC option to set FastMalloc's maxSingleAllocationSize for testing purposes.
This option is only available on Debug builds.
* runtime/Options.cpp:
(JSC::Options::isAvailable):
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-11-12 Joseph Pecoraro <pecoraro@apple.com>
Follow-up fix to r208639.
Unreviewed fix. This is a straightfoward change where I forgot to
switch from uncheckedArgument() to argument() in once case after
dropping an argumentCount check. All other cases do this properly.
This addresses an ASSERT seen on the bots running tests.
* runtime/JSDataViewPrototype.cpp:
(JSC::setData):
2016-11-11 Joseph Pecoraro <pecoraro@apple.com>
test262: DataView with explicit undefined byteLength should be the same as it not being present
https://bugs.webkit.org/show_bug.cgi?id=164453
Reviewed by Darin Adler.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
Handle the special case of DataView construction with an undefined byteLength value.
2016-11-11 Joseph Pecoraro <pecoraro@apple.com>
test262: DataView get methods should allow for missing offset, set methods should allow for missing value
https://bugs.webkit.org/show_bug.cgi?id=164451
Reviewed by Darin Adler.
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
Missing offset is still valid and will be coerced to 0.
(JSC::setData):
Missing value is still valid and will be coerced to 0.
2016-11-11 Saam Barati <sbarati@apple.com>
We should have a more concise way of determining when we're varargs calling a function using rest parameters
https://bugs.webkit.org/show_bug.cgi?id=164258
Reviewed by Yusuke Suzuki.
This patch adds two new bytecodes and DFG nodes for the following code patterns:
```
foo(a, b, ...c)
let x = [a, b, ...c];
```
To do this, I've introduced two new bytecode operations (and their
corresponding DFG nodes):
op_spread and op_new_array_with_spread.
op_spread takes a single input and performs the ES6 iteration protocol on it.
It returns the result of doing the spread inside a new class I've
made called JSFixedArray. JSFixedArray is a cell with a single 'size'
field and a buffer of values allocated inline in the cell. Abstracting
the protocol into a single node is good because it will make IR analysis
in the future much simpler. For now, it's also good because it allows
us to create fast paths for array iteration (which is quite common).
This fast path allows us to emit really good code for array iteration
inside the DFG/FTL.
op_new_array_with_spread is a variable argument bytecode that also
has a bit vector associated with it. The bit vector indicates if
any particular argument is to be spread or not. Arguments that
are spread are known to be JSFixedArray because we must emit an
op_spread before op_new_array_with_spread consumes the value.
For example, for this array:
[a, b, ...c, d, ...e]
we will have this bit vector:
[0, 0, 1, 0, 1]
The reason I've chosen this IR is that it will make eliminating
a rest allocation for this type of code much easier:
```
function foo(...args) {
return bar(a, b, ...args);
}
```
It will be easier to analyze the IR now that the operations
will be described at a high level.
This patch is an ~8% speedup on ES6SampleBench on my MBP.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/IteratorHelpers.js: Added.
(performIteration):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionForSelfEquivalence):
* bytecode/ObjectPropertyConditionSet.h:
* bytecode/TrackedReferences.cpp:
(JSC::TrackedReferences::check):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::bitVectors):
(JSC::UnlinkedCodeBlock::bitVector):
(JSC::UnlinkedCodeBlock::addBitVector):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::watchHavingABadTime):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint):
* dfg/DFGNode.h:
(JSC::DFG::Node::bitVector):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
(JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_array_with_spread):
(JSC::JIT::emit_op_spread):
* jit/JITOperations.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
* llint/LowLevelInterpreter.asm:
* runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Added.
(JSC::ArrayIteratorAdaptiveWatchpoint::ArrayIteratorAdaptiveWatchpoint):
(JSC::ArrayIteratorAdaptiveWatchpoint::handleFire):
* runtime/ArrayIteratorAdaptiveWatchpoint.h: Added.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
* runtime/JSCInlines.h:
* runtime/JSFixedArray.cpp: Added.
(JSC::JSFixedArray::visitChildren):
* runtime/JSFixedArray.h: Added.
(JSC::JSFixedArray::createStructure):
(JSC::JSFixedArray::createFromArray):
(JSC::JSFixedArray::get):
(JSC::JSFixedArray::buffer):
(JSC::JSFixedArray::size):
(JSC::JSFixedArray::offsetOfSize):
(JSC::JSFixedArray::offsetOfData):
(JSC::JSFixedArray::create):
(JSC::JSFixedArray::JSFixedArray):
(JSC::JSFixedArray::allocationSize):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::objectPrototypeIsSane): Deleted.
(JSC::JSGlobalObject::arrayPrototypeChainIsSane): Deleted.
(JSC::JSGlobalObject::stringPrototypeChainIsSane): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayIteratorProtocolWatchpoint):
(JSC::JSGlobalObject::iteratorProtocolFunction):
* runtime/JSGlobalObjectInlines.h: Added.
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
(JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable):
* runtime/JSType.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2016-11-11 Keith Miller <keith_miller@apple.com>
Move Wasm tests to JS
https://bugs.webkit.org/show_bug.cgi?id=164611
Reviewed by Geoffrey Garen.
This patch translates most of the tests from testWasm.cpp to the JS testing api. Most of the
ommited tests were earliest tests, which tested trivial things, like adding two
constants. Some tests are ommited for other reasons, however. These are:
1) Tests using I64 since the testing api does not yet know how to handle 64-bit numbers. 2)
Tests that would validate the memory of the module once wasm was done with it since that's
not really possible in JS.
In order to make such a translation easier this patch also adds some features to the JS
testing api:
1) Blocks can now be done lexically by adding a lambda as the last argument of the block
opcode. For example one can do:
...
.Block("i32", b => b.I32Const(1) )
and the nested lambda will automatically have an end attached.
2) The JS testing api can now handle inline signature types.
3) Relocate some code to make it easier to follow and prevent 44 space indentation.
4) Rename varuint/varint to varuint32/varint32, this lets them be directly called from the
wasm.json without being remapped.
5) Add support for Memory and Function sections to the Builder.
6) Add support for local variables.
On the JSC side, we needed to expose a new function to validate the compiled wasm code
behaves the way we expect. At least until the JS Wasm API is finished. The new validation
function, testWasmModuleFunctions, takes an array buffer containing the wasm binary, the
number of functions in the blob and tests for each of those functions.
* jsc.cpp:
(GlobalObject::finishCreation):
(box):
(callWasmFunction):
(functionTestWasmModuleFunctions):
* testWasm.cpp:
(checkPlan):
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseBody):
(JSC::Wasm::FunctionParser<Context>::parseBlock): Deleted.
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseExport):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::run):
* wasm/WasmPlan.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
2016-11-11 Saam Barati <sbarati@apple.com>
Unreviewed try to fix windows build after https://bugs.webkit.org/show_bug.cgi?id=164650
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2016-11-11 Saam Barati <sbarati@apple.com>
We recursively grab a lock in the DFGBytecodeParser causing us to deadlock
https://bugs.webkit.org/show_bug.cgi?id=164650
Reviewed by Geoffrey Garen.
Some code was incorrectly holding a lock when recursively calling
back into the bytecode parser's via inlining a put_by_val as a put_by_id.
This can cause a deadlock if the inlinee CodeBlock is something we're
already holding a lock for. I've changed the range of the lock holder
to be as narrow as possible.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2016-11-11 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r208584.
Seems to have regressed Speedometer by 1% on Mac
Reverted changeset:
"We should have a more concise way of determining when we're
varargs calling a function using rest parameters"
https://bugs.webkit.org/show_bug.cgi?id=164258
http://trac.webkit.org/changeset/208584
2016-11-11 Chris Dumez <cdumez@apple.com>
Unreviewed, rolling out r208117 and r208160.
Regressed Speedometer by >1.5%
Reverted changesets:
"We should have a way of profiling when a get_by_id is pure
and to emit a PureGetById in the DFG/FTL"
https://bugs.webkit.org/show_bug.cgi?id=163305
http://trac.webkit.org/changeset/208117
"Debug JSC test microbenchmarks/pure-get-by-id-cse-2.js timing
out"
https://bugs.webkit.org/show_bug.cgi?id=164227
http://trac.webkit.org/changeset/208160
2016-11-11 Saam Barati <sbarati@apple.com>
We should have a more concise way of determining when we're varargs calling a function using rest parameters
https://bugs.webkit.org/show_bug.cgi?id=164258
Reviewed by Yusuke Suzuki.
This patch adds two new bytecodes and DFG nodes for the following code patterns:
```
foo(a, b, ...c)
let x = [a, b, ...c];
```
To do this, I've introduced two new bytecode operations (and their
corresponding DFG nodes):
op_spread and op_new_array_with_spread.
op_spread takes a single input and performs the ES6 iteration protocol on it.
It returns the result of doing the spread inside a new class I've
made called JSFixedArray. JSFixedArray is a cell with a single 'size'
field and a buffer of values allocated inline in the cell. Abstracting
the protocol into a single node is good because it will make IR analysis
in the future much simpler. For now, it's also good because it allows
us to create fast paths for array iteration (which is quite common).
This fast path allows us to emit really good code for array iteration
inside the DFG/FTL.
op_new_array_with_spread is a variable argument bytecode that also
has a bit vector associated with it. The bit vector indicates if
any particular argument is to be spread or not. Arguments that
are spread are known to be JSFixedArray because we must emit an
op_spread before op_new_array_with_spread consumes the value.
For example, for this array:
[a, b, ...c, d, ...e]
we will have this bit vector:
[0, 0, 1, 0, 1]
The reason I've chosen this IR is that it will make eliminating
a rest allocation for this type of code much easier:
```
function foo(...args) {
return bar(a, b, ...args);
}
```
It will be easier to analyze the IR now that the operations
will be described at a high level.
This patch is an ~8% speedup on ES6SampleBench on my MBP.
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/IteratorHelpers.js: Added.
(performIteration):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionForSelfEquivalence):
* bytecode/ObjectPropertyConditionSet.h:
* bytecode/TrackedReferences.cpp:
(JSC::TrackedReferences::check):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::bitVectors):
(JSC::UnlinkedCodeBlock::bitVector):
(JSC::UnlinkedCodeBlock::addBitVector):
(JSC::UnlinkedCodeBlock::shrinkToFit):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewArrayWithSpread):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::watchHavingABadTime):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::isWatchingArrayIteratorProtocolWatchpoint):
* dfg/DFGNode.h:
(JSC::DFG::Node::bitVector):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileSpread):
(JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedCell):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
(JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_array_with_spread):
(JSC::JIT::emit_op_spread):
* jit/JITOperations.h:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LLIntSlowPaths.cpp:
* llint/LowLevelInterpreter.asm:
* runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Added.
(JSC::ArrayIteratorAdaptiveWatchpoint::ArrayIteratorAdaptiveWatchpoint):
(JSC::ArrayIteratorAdaptiveWatchpoint::handleFire):
* runtime/ArrayIteratorAdaptiveWatchpoint.h: Added.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
* runtime/JSCInlines.h:
* runtime/JSFixedArray.cpp: Added.
(JSC::JSFixedArray::visitChildren):
* runtime/JSFixedArray.h: Added.
(JSC::JSFixedArray::createStructure):
(JSC::JSFixedArray::createFromArray):
(JSC::JSFixedArray::get):
(JSC::JSFixedArray::buffer):
(JSC::JSFixedArray::size):
(JSC::JSFixedArray::offsetOfSize):
(JSC::JSFixedArray::offsetOfData):
(JSC::JSFixedArray::create):
(JSC::JSFixedArray::JSFixedArray):
(JSC::JSFixedArray::allocationSize):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::objectPrototypeIsSane): Deleted.
(JSC::JSGlobalObject::arrayPrototypeChainIsSane): Deleted.
(JSC::JSGlobalObject::stringPrototypeChainIsSane): Deleted.
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayIteratorProtocolWatchpoint):
(JSC::JSGlobalObject::iteratorProtocolFunction):
* runtime/JSGlobalObjectInlines.h: Added.
(JSC::JSGlobalObject::objectPrototypeIsSane):
(JSC::JSGlobalObject::arrayPrototypeChainIsSane):
(JSC::JSGlobalObject::stringPrototypeChainIsSane):
(JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable):
* runtime/JSType.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2016-11-10 JF Bastien <jfbastien@apple.com>
ASSERTION FAILED: length > offset encountered with wasm.yaml/wasm/js-api/test_Module.js.default-wasm
https://bugs.webkit.org/show_bug.cgi?id=164597
Reviewed by Keith Miller.
* wasm/WasmParser.h:
(JSC::Wasm::Parser::parseVarUInt32): move closer to other parsers
(JSC::Wasm::Parser::parseVarUInt64): move closer to other parsers
2016-11-10 Joseph Pecoraro <pecoraro@apple.com>
test262: DataView / TypedArray methods should throw RangeErrors for negative numbers (ToIndex)
https://bugs.webkit.org/show_bug.cgi?id=164450
Reviewed by Darin Adler.
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toIndex):
Introduce a method for toIndex, which is used by DataView and TypedArrays
to convert an argument to a number with the possibility of throwing
RangeErrors for negative values. We also throw RangeErrors for large
values, because wherever this is used we expect an unsigned.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
Use toIndex instead of toUint32 where required.
2016-11-10 Mark Lam <mark.lam@apple.com>
A few bits of minor code clean up.
https://bugs.webkit.org/show_bug.cgi?id=164523
Reviewed by Yusuke Suzuki.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::dump):
- Insert a space to make the dump more legible.
* runtime/Options.h:
- Fixed some typos.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncReplaceUsingStringSearch):
- Use the VM& that is already available.
2016-11-10 Mark Lam <mark.lam@apple.com>
Graph::methodOfGettingAValueProfileFor() should be returning the profile for the operand node.
https://bugs.webkit.org/show_bug.cgi?id=164600
<rdar://problem/28828676>
Reviewed by Filip Pizlo.
Currently, Graph::methodOfGettingAValueProfileFor() assumes that the operand DFG
node that it is provided with always has a different origin than the node that is
using that operand. For example, in a DFG graph that looks like this:
a: ...
b: ArithAdd(@a, ...)
... when emitting speculation checks on @a for the ArithAdd node at @b,
Graph::methodOfGettingAValueProfileFor() is passed @a, and expects @a's to
originate from a different bytecode than @b. The intent here is to get the
profile for @a so that the OSR exit ramp for @b can update @a's profile with the
observed result type from @a so that future type prediction on incoming args for
the ArithAdd node can take this into consideration.
However, op_negate can be compiled into the following series of nodes:
a: ...
b: BooleanToNumber(@a)
c: DoubleRep(@b)
d: ArithNegate(@c)
All 3 nodes @b, @c, and @d maps to the same op_negate bytecode i.e. they have the
same origin. When the speculativeJIT emits a speculationCheck for DoubleRep, it
calls Graph::methodOfGettingAValueProfileFor() to get the ArithProfile for the
BooleanToNumber node. But because all 3 nodes have the same origin,
Graph::methodOfGettingAValueProfileFor() erroneously returns the ArithProfile for
the op_negate. Subsequently, the OSR exit ramp will modify the ArithProfile of
the op_negate and corrupt its profile. Instead, what the OSR exit ramp should be
doing is update the ArithProfile of op_negate's operand i.e. BooleanToNumber's
operand @a in this case.
The fix is to always pass the current node we're generating code for (in addition
to the operand node) to Graph::methodOfGettingAValueProfileFor(). This way, we
know the profile is valid if and only if the current node and its operand node
does not have the same origin.
In this patch, we also fixed the following:
1. Teach Graph::methodOfGettingAValueProfileFor() to get the profile for
BooleanToNumber's operand if the operand node it is given is BooleanToNumber.
2. Change JITCompiler::appendExceptionHandlingOSRExit() to explicitly pass an
empty MethodOfGettingAValueProfile(). It was implicitly doing this before.
3. Change SpeculativeJIT::emitInvalidationPoint() to pass an empty
MethodOfGettingAValueProfile(). It has no child node. Hence, it doesn't
make sense to call Graph::methodOfGettingAValueProfileFor() for a child node
that does not exist.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::methodOfGettingAValueProfileFor):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::appendOSRExitDescriptor):
2016-11-10 Aaron Chu <aaron_chu@apple.com>
Web Inspector: AXI: clarify button roles (e.g. toggle or popup button)
https://bugs.webkit.org/show_bug.cgi?id=130726
<rdar://problem/16420420>
Reviewed by Brian Burg.
Add the isPopupButton flag to the AccessibilityProperties type.
* inspector/protocol/DOM.json:
2016-11-10 Csaba Osztrogonác <ossy@webkit.org>
[ARM] Unreviewed buildfix after r208450.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::load8SignedExtendTo32): Added.
2016-11-08 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Avoid cloned arguments allocation in ArrayPrototype methods
https://bugs.webkit.org/show_bug.cgi?id=164502
Reviewed by Saam Barati.
In many builtin functions, we use `arguments` to just get optional parameters.
While FTL argument elimination can drop `arguments` allocations, it leaves
the allocations in LLInt, Baseline, and DFG. And we found that DFG compiled
Array#map is heavily used in ES6SampleBench/Basic. And it always creates
a meaningless ClonedArguments.
Using ES6 default parameter here is not a solution. It increases the number
of parameters of the CodeBlock (not `function.length`). And the optional
parameters in Array.prototype.xxx methods are not typically passed. For
example, we typically do not pass `thisArg` to `Array.prototype.map` function.
In this case, the arity check frequently fails. It requires the additional C
call to fixup arguments and it becomes pure overhead.
To solve this problem, this patch introduces a new bytecode intrinsic @argument().
This offers the way to retrieve the argument value without increasing the
arity of the function. And if the argument is not passed (out of bounds), it
just returns `undefined`. The semantics of this intrinsic is the same to the C++
ExecState::argument(). This operation does not require `arguments` object. And we
can drop the `argument` references even in lower 3 tiers.
We implement op_get_argument for this intrinsic. And later this will be converted
to DFG GetArgument node. All the tiers handles this feature.
This patch improves ES6SampleBench/Basic 13.8% in steady state. And in summary,
it improves 4.5%.
In the future, we can improve the implementation of the default parameters.
Currently, the default parameter always increases the arity of the function. So
if you do not pass the argument, the arity check fails. But since it is the default
parameter, it is likely that we don't pass the argument. Using op_get_argument to
implement the default parameter can decrease the case in which the arity check
frequently fails. And it can change the builtin implementation to use the ES6
default parameters instead of using the special @argument() intrinsic in the future.
And at that case, the user code also receives the benefit.
ES6SampleBench/Basic.
Baseline:
Running... Basic ( 1 to go)
firstIteration: 39.38 ms +- 4.48 ms
averageWorstCase: 20.79 ms +- 0.96 ms
steadyState: 1959.22 ms +- 65.55 ms
Patched:
Running... Basic ( 1 to go)
firstIteration: 37.85 ms +- 4.09 ms
averageWorstCase: 18.60 ms +- 0.76 ms
steadyState: 1721.89 ms +- 57.58 ms
All summary.
Baseline:
summary: 164.34 ms +- 5.01 ms
Patched:
summary: 157.26 ms +- 5.96 ms
* builtins/ArrayConstructor.js:
* builtins/ArrayPrototype.js:
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(copyWithin):
* builtins/DatePrototype.js:
(toLocaleString):
(toLocaleDateString):
(toLocaleTimeString):
* builtins/MapPrototype.js:
(forEach):
* builtins/NumberPrototype.js:
(toLocaleString):
* builtins/SetPrototype.js:
(forEach):
* builtins/StringPrototype.js:
(padStart):
(padEnd):
(localeCompare):
* builtins/TypedArrayConstructor.js:
* builtins/TypedArrayPrototype.js:
(every):
(fill):
(find):
(findIndex):
(forEach):
(some):
(reduce):
(reduceRight):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::finishCreation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetArgument):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_argument):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasArgumentIndex):
(JSC::DFG::Node::argumentIndex):
* dfg/DFGNodeType.h:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetArgument):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArgument):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_get_argument):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2016-11-08 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: DebuggerManager.Event.Resumed introduces test flakiness
https://bugs.webkit.org/show_bug.cgi?id=161951
<rdar://problem/28295767>
Reviewed by Brian Burg.
This removes an ambiguity in the protocol when stepping through
JavaScript. Previously, when paused and issuing a Debugger.step*
command the frontend would always receive a Debugger.resumed event and
then, maybe, a Debugger.paused event indicating we paused again (after
stepping). However, this ambiguity means that the frontend needs to
wait for a short period of time to determine if we really resumed
or not. And even still that decision may be incorrect if the step
takes a sufficiently long period of time.
The new approach removes this ambiguity. Now, in response to a
Debugger.step* command the backend MUST send a single Debugger.paused
event or Debugger.resumed event. Now the frontend knows that the
next Debugger event it receives after issuing the step command is
the result (stepped and paused, or stepped and resumed).
To make resuming consistent in all cases, a Debugger.resume command
will always respond with a Debugger.resumed event.
Finally, Debugger.continueToLocation is treated like a "big step"
in cases where we can resolve the location. If we can't resolve the
location it is treated as a resume, maintaining the old behavior.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepOver):
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::stepOut):
(Inspector::InspectorDebuggerAgent::willStepAndMayBecomeIdle):
(Inspector::InspectorDebuggerAgent::didBecomeIdleAfterStepping):
When stepping register a VM exit observer so that we can issue
a Debugger.resumed event if the step caused us to exit the VM.
(Inspector::InspectorDebuggerAgent::resume):
Set a flag to issue a Debugger.resumed event once we break out
of the nested run loop.
(Inspector::InspectorDebuggerAgent::didPause):
We are issuing Debugger.paused so clear the state to indicate that
we no longer need to issue Debugger.resumed event, we have paused.
(Inspector::InspectorDebuggerAgent::didContinue):
Only issue the Debugger.resumed event if needed (explicitly asked
to resume).
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
All places that do continueProgram should be audited. In error cases,
if we are paused and continue we should remember to send Debugger.resumed.
* inspector/protocol/Debugger.json:
Clarify in the protocol description the contract of these methods.
2016-11-09 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Associate Worker Resources with the Worker and not the Page
https://bugs.webkit.org/show_bug.cgi?id=164342
<rdar://problem/29075775>
Reviewed by Timothy Hatcher.
* inspector/protocol/Network.json:
* inspector/protocol/Page.json:
Associate Resource data with a target.
2016-11-09 Keith Miller <keith_miller@apple.com>
jsc CLI should work with the remote inspector
https://bugs.webkit.org/show_bug.cgi?id=164569
Reviewed by Joseph Pecoraro.
This patch enables using the remote inspector on the jsc CLI.
In order to use the remote inspector, jsc users need to pass an option.
* jsc.cpp:
(CommandLine::parseArguments):
(runJSC):
2016-11-09 Saam Barati <sbarati@apple.com>
Math.min()/Math.max() with no arguments is lowered incorrectly in the BytecodeParser
https://bugs.webkit.org/show_bug.cgi?id=164464
<rdar://problem/29131452>
Reviewed by Darin Adler.
We were incorrectly matching this pattern inside the bytecode parser
to return NaN. Instead, we must return:
Infinity for Math.min()
-Infinity for Math.max()
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleMinMax):
2016-11-09 Saam Barati <sbarati@apple.com>
TypeProfiler and running GC collection on another thread don't play nicely with each other
https://bugs.webkit.org/show_bug.cgi?id=164441
<rdar://problem/29132174>
Reviewed by Geoffrey Garen.
This fix here is simple: we now treat the type profiler log as a GC root.
GC will make sure that we mark any values/structures that are in the log.
It's easy to reason about the correctness of this, and it also solves
the problem that we were clearing the log on the GC thread. Clearing the
log on the GC thread was a problem because when we clear the log, we may
allocate, which we're not allowed to do from the GC thread.
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::visitTypeProfiler):
(JSC::Heap::collectInThread):
* heap/Heap.h:
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::processLogEntries):
(JSC::TypeProfilerLog::visit):
* runtime/TypeProfilerLog.h:
2016-11-09 JF Bastien <jfbastien@apple.com>
WebAssembly: Silence noisy warning
https://bugs.webkit.org/show_bug.cgi?id=164459
Reviewed by Yusuke Suzuki.
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
2016-11-07 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] The implementation of 8 bit operation in MacroAssembler should care about uint8_t / int8_t
https://bugs.webkit.org/show_bug.cgi?id=164432
Reviewed by Michael Saboff.
Except for X86, our supported MacroAssemblers do not have native 8bit instructions.
It means that all the 8bit instructions are converted to 32bit operations by using
scratch registers. For example, ARM64 branch8 implementation is the following.
Jump branch8(RelationCondition cord, Address left, TrustedImm32 right)
{
TrustedImm32 right8(static_cast<int8_t>(right.m_value));
load8(left, getCachedMemoryTempRegisterIDAndInvalidate());
return branch32(cone, memoryTempRegister, right8);
}
The problem is that we exclusively use zero-extended load instruction (load8). Even
for signed RelationConditions, we do not perform sign extension. It makes signed
operations with negative numbers incorrect! Consider the |left| address holds `-1`
in int8_t form. However load8 will load it as 255 into 32bit register. On the other hand,
|right| will be sign extended. If you pass 0 as |right| and LessThan condition, this
branch8 should jump based on the answer of `-1 < 0`. But the current MacroAssembler
performs `255 < 0` in int32_t context and returns the incorrect result.
We should follow the x86 model. So we should select the appropriate load operation and masking
operation based on the RelationCondition. This patch introduces mask8OnCondition and load8OnCondition.
And we use them in 8bit operations including branch8, branchTest8, compare8, and test8.
We intentionally do not change anything on x86 assembler since it has the native signed 8bit operations.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::isSigned):
(JSC::MacroAssembler::isUnsigned):
(JSC::MacroAssembler::branchTest8):
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::branch8):
(JSC::MacroAssemblerARM::branchTest8):
(JSC::MacroAssemblerARM::compare8):
(JSC::MacroAssemblerARM::test8):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load8SignedExtendTo32):
(JSC::MacroAssemblerARM64::branch8):
(JSC::MacroAssemblerARM64::branchTest8):
(JSC::MacroAssemblerARM64::compare8):
(JSC::MacroAssemblerARM64::test8):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branch8):
(JSC::MacroAssemblerARMv7::branchTest8):
(JSC::MacroAssemblerARMv7::compare8):
(JSC::MacroAssemblerARMv7::test8):
* assembler/MacroAssemblerHelpers.h: Added.
(JSC::MacroAssemblerHelpers::isSigned):
(JSC::MacroAssemblerHelpers::isUnsigned):
(JSC::MacroAssemblerHelpers::mask8OnCondition):
(JSC::MacroAssemblerHelpers::load8OnCondition):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branch8):
(JSC::MacroAssemblerMIPS::compare8):
(JSC::MacroAssemblerMIPS::branchTest8):
(JSC::MacroAssemblerMIPS::test8):
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::branchTest8):
(JSC::MacroAssemblerSH4::branch8):
(JSC::MacroAssemblerSH4::compare8):
(JSC::MacroAssemblerSH4::test8):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branch8):
2016-11-08 Geoffrey Garen <ggaren@apple.com>
REGRESSION: date-format-tofte.js is super slow
https://bugs.webkit.org/show_bug.cgi?id=164499
Reviewed by Sam Weinig.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::CacheKey::operator==): Use character comparison,
not pointer comparison. (This function was always wrong, but I started
calling it in more places.)
2016-11-08 Saam Barati <sbarati@apple.com>
REGRESSION: Crashes in StringImpl destructor during GC when clearing the HasOwnPropertyCache
https://bugs.webkit.org/show_bug.cgi?id=164433
Reviewed by Mark Lam.
Clearing the HasOwnPropertyCache will call deref() on the StringImpls
in the cache. We were doing this from the collector thread, which is
not allowed. It must be done from the mutator thread. We now clear the
cache in Heap::finalize() which happens before the mutator begins
executing JS after a collection happens.
* heap/Heap.cpp:
(JSC::Heap::collectInThread):
(JSC::Heap::finalize):
2016-11-05 Konstantin Tokarev <annulen@yandex.ru>
Fixed compilation of LLInt with MinGW
https://bugs.webkit.org/show_bug.cgi?id=164449
Reviewed by Michael Catanzaro.
MinGW uses LLIntAssembly.h with GNU assembler syntax, just like GCC on
other platforms.
* llint/LowLevelInterpreter.cpp: Include LLIntAssembly.h with
appropriate preamble.
2016-11-04 Filip Pizlo <fpizlo@apple.com>
WTF::ParkingLot should stop using std::chrono because std::chrono::duration casts are prone to overflows
https://bugs.webkit.org/show_bug.cgi?id=152045
Reviewed by Andy Estes.
Probably the nicest example of why this patch is a good idea is the change in
AtomicsObject.cpp.
* jit/ICStats.cpp:
(JSC::ICStats::ICStats):
* runtime/AtomicsObject.cpp:
(JSC::atomicsFuncWait):
2016-11-04 JF Bastien <jfbastien@apple.com>
testWASM should be very sad if no options are provided
https://bugs.webkit.org/show_bug.cgi?id=164444
Reviewed by Saam Barati.
Detect missing or invalid options on the command line.
* testWasm.cpp:
(CommandLine::parseArguments):
2016-11-04 Mark Lam <mark.lam@apple.com>
Error description code should be able to handle Symbol values.
https://bugs.webkit.org/show_bug.cgi?id=164436
<rdar://problem/29115583>
Reviewed by Filip Pizlo and Saam Barati.
Previously, we try to toString() the Symbol value, resulting in it throwing an
exception in errorDescriptionForValue() which breaks the invariant that
errorDescriptionForValue() should not throw.
We fixed this by making errorDescriptionForValue() aware of the Symbol type, and
not so a toString() on Symbol values. Also fixed notAFunctionSourceAppender()
to build a nicer message for Symbol values.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
(JSC::notAFunctionSourceAppender):
2016-11-02 Geoffrey Garen <ggaren@apple.com>
EvalCodeCache should not give up in strict mode and other cases
https://bugs.webkit.org/show_bug.cgi?id=164357
Reviewed by Michael Saboff.
EvalCodeCache gives up in non-trivial cases because generated eval code
can't soundly migrate from, for example, a let scope to a non-let scope.
The number of cases has grown over time.
Instead, let's cache eval code based on the location of the call to
eval(). That way, we never relocate the code, and it's sound to make
normal assumptions about our surrounding scope.
* bytecode/EvalCodeCache.h:
(JSC::EvalCodeCache::CacheKey::CacheKey): Use CallSiteIndex to uniquely
identify the location of our call to eval().
(JSC::EvalCodeCache::CacheKey::hash):
(JSC::EvalCodeCache::CacheKey::operator==):
(JSC::EvalCodeCache::CacheKey::Hash::equal): Use CallSiteIndex instead
of lots of other flags.
(JSC::EvalCodeCache::tryGet): No need to include details that are implied
by our CallSiteIndex.
(JSC::EvalCodeCache::getSlow): No need to skip caching in complex
situations. We promise we'll never relocate the cached code.
(JSC::EvalCodeCache::isCacheableScope): Deleted.
(JSC::EvalCodeCache::isCacheable): Deleted.
* interpreter/Interpreter.cpp:
(JSC::eval): Pass through a CallSiteIndex to uniquely identify this call
to eval().
2016-11-04 Keith Miller <keith_miller@apple.com>
Add support for Wasm br_table
https://bugs.webkit.org/show_bug.cgi?id=164429
Reviewed by Michael Saboff.
This patch adds support for Wasm br_table. The Wasm br_table
opcode essentially directly maps to B3's switch opcode.
There are also three other minor changes:
1) all non-argument locals should be initialized to zero at function entry.
2) add new setErrorMessage member to WasmFunctionParser.h
3) return does not decode an extra immediate anymore.
* testWasm.cpp:
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser::setErrorMessage):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
(JSC::Wasm::FunctionParser<Context>::popExpressionStack):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::checkBranchTarget):
(JSC::Wasm::Validate::addBranch):
(JSC::Wasm::Validate::addSwitch):
2016-11-04 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement more sections
https://bugs.webkit.org/show_bug.cgi?id=164023
Reviewed by Keith Miller.
On the JSC side:
- Put in parser stubs for all WebAssembly sections.
- Parse Import, Export sections.
- Use tryReserveCapacity instead of reserve, and bail out of the parser if it fails. This prevents the parser from bringing everything down when faced with a malicious input.
- Encapsulate all parsed module information into its own structure, making it easier to pass around (from parser to Plan to Module to Instance).
- Create WasmFormat.cpp to hold parsed module information's dtor to avoid including WasmMemory.h needlessly.
- Remove all remainders of polyfill-prototype-1, and update license.
- Add missing WasmOps.h and WasmValidateInlines.h auto-generation for cmake build.
On the Builder.js testing side:
- Implement Type, Import (function only), Export (function only) sections.
- Check section order and uniqueness.
- Optionally auto-generate the Type section from subsequent Export / Import / Code entries.
- Allow re-exporting an import.
* CMakeLists.txt: missing auto-genration
* JavaScriptCore.xcodeproj/project.pbxproj: merge conflict
* testWasm.cpp: update for API changes, no functional change
(checkPlan):
(runWasmTests):
* wasm/WasmFormat.cpp: add a dtor which requires extra headers which I'd rather not include in WasmFormat.h
(JSC::Wasm::ModuleInformation::~ModuleInformation):
* wasm/WasmFormat.h: Add External, Import, Functioninformation, Export, ModuleInformation, CompiledFunction, and remove obsolete stuff which was a holdover from the first implementation (all that code is now gone, so remove its license)
(JSC::Wasm::External::isValid):
* wasm/WasmModuleParser.cpp: simplify some, make names consistent with the WebAssembly section names, check memory allocations so they can fail early
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseType):
(JSC::Wasm::ModuleParser::parseImport):
(JSC::Wasm::ModuleParser::parseFunction):
(JSC::Wasm::ModuleParser::parseTable):
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseGlobal):
(JSC::Wasm::ModuleParser::parseExport):
(JSC::Wasm::ModuleParser::parseStart):
(JSC::Wasm::ModuleParser::parseElement):
(JSC::Wasm::ModuleParser::parseCode): avoid overflow through function size.
(JSC::Wasm::ModuleParser::parseData):
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::moduleInformation):
* wasm/WasmParser.h:
(JSC::Wasm::Parser::consumeUTF8String): add as required by spec
(JSC::Wasm::Parser::parseExternalKind): add as per spec
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan): fix some ownership, improve some error messages
* wasm/WasmPlan.h: fix some ownership
(JSC::Wasm::Plan::getModuleInformation):
(JSC::Wasm::Plan::getMemory):
(JSC::Wasm::Plan::compiledFunctionCount):
(JSC::Wasm::Plan::compiledFunction):
(JSC::Wasm::Plan::getCompiledFunctions):
* wasm/WasmSections.h: macroize with description, so that error messages are super pretty. This could be auto-generated.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create): take module information
(JSC::JSWebAssemblyModule::JSWebAssemblyModule): ditto
* wasm/js/JSWebAssemblyModule.h:
(JSC::JSWebAssemblyModule::moduleInformation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): check that modules with imports are instantiated with an import object, as per spec. This needs to be tested.
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::constructJSWebAssemblyMemory):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::constructJSWebAssemblyTable):
2016-11-03 Mark Lam <mark.lam@apple.com>
ClonedArguments need to also support haveABadTime mode.
https://bugs.webkit.org/show_bug.cgi?id=164200
<rdar://problem/27211336>
Reviewed by Geoffrey Garen.
For those who are not familiar with the parlance, "have a bad time" in the VM
means that Object.prototype has been modified in such a way that we can no longer
trivially do indexed property accesses without consulting the Object.prototype.
This defeats JIT indexed put optimizations, and hence, makes the VM "have a
bad time".
Once the VM enters haveABadTime mode, all existing objects are converted to use
slow put storage. Thereafter, JSArrays are always created with slow put storage.
JSObjects are always created with a blank indexing type. When a new indexed
property is put into the new object, its indexing type will be converted to the
slow put array indexing type just before we perform the put operation. This is
how we ensure that the objects will also use slow put storage.
However, ClonedArguments is an object which was previously created unconditionally
to use contiguous storage. Subsequently, if we try to call Object.preventExtensions()
on that ClonedArguments object, Object.preventExtensions() will:
1. make the ClonedArguments enter dictionary indexing mode, which means it will
2. first ensure that the ClonedArguments is using slow put array storage via
JSObject::ensureArrayStorageSlow().
However, JSObject::ensureArrayStorageSlow() expects that we never see an object
with contiguous storage once we're in haveABadTime mode. Our ClonedArguments
object did not obey this invariant.
The fix is to make the ClonedArguments factories create objects that use slow put
array storage when in haveABadTime mode. This means:
1. JSGlobalObject::haveABadTime() now changes m_clonedArgumentsStructure to use
its slow put version.
Also the caching of the slow put version of m_regExpMatchesArrayStructure,
because we only need to create it when we are having a bad time.
2. The ClonedArguments factories now allocates a butterfly with slow put array
storage if we're in haveABadTime mode.
Also added some assertions in ClonedArguments' factory methods to ensure that
the created object has the slow put indexing type when it needsSlowPutIndexing().
3. DFGFixupPhase now watches the havingABadTimeWatchpoint because ClonedArguments'
structure will change when having a bad time.
4. DFGArgumentEliminationPhase and DFGVarargsForwardingPhase need not be changed
because it is still valid to eliminate the creation of the arguments object
even having a bad time, as long as the arguments object does not escape.
5. The DFGAbstractInterpreterInlines now checks for haveABadTime, and sets the
predicted type to be SpecObject.
Note: this issue does not apply to DirectArguments and ScopedArguments because
they use a blank indexing type (just like JSObject).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::dump):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createEmpty):
(JSC::ClonedArguments::createWithInlineFrame):
(JSC::ClonedArguments::createWithMachineFrame):
(JSC::ClonedArguments::createByCopyingFrom):
(JSC::ClonedArguments::createStructure):
(JSC::ClonedArguments::createSlowPutStructure):
* runtime/ClonedArguments.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::haveABadTime):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
2016-11-03 Filip Pizlo <fpizlo@apple.com>
DFG plays fast and loose with the shadow values of a Phi
https://bugs.webkit.org/show_bug.cgi?id=164309
Reviewed by Saam Barati.
Oh boy, what an embarrassing mistake! The style of SSA I like to use avoids block/value
tuples as parameters of a Phi, thereby simplifying CFG transformations and making Phi largely
not a special case for most compiler transforms. It does this by introducing another value
called Upsilon, which stores a value into some Phi.
B3 uses this also. The easiest way to understand what Upsilon/Phi behave like is to look at
the B3->Air lowering. Air is not SSA - it has Tmps that you can assign to and use as many
times as you like. B3 allocates one Tmp per Value, and an extra "phiTmp" for Phis, so that
Phis get two Tmps total. Upsilon stores the value into the phiTmp of the Phi, while Phi moves
the value from its phiTmp to its tmp.
This is necessary to support scenarios like this:
a: Phi()
b: Upsilon(@x, ^a)
c: Use(@a)
Here, we want @c to see @a's value before @b. That's a very basic requirement of SSA: that
the a value (like @a) doesn't change during its lifetime.
Unfortunately, DFG's liveness analysis, abstract interpreter, and integer range optimization
all failed to correctly model Upsilon/Phi this way. They would assume that it's accurate to
model the Upsilon as storing into the Phi directly.
Because DFG does flow analysis over SSA, making it correct means enabling it to speak of the
shadow value. This change addresses this problem by introducing the concept of a
NodeFlowProjection. This is a key that lets us speak of both a Node's primary value and its
optional "shadow" value. Liveness, AI, and integer range are now keyed by NodeFlowProjection
rather than Node*. Conceptually this turns out to be a very simple change, but it does touch
a good amount of code.
This looks to be perf-neutral.
Rolled back in after fixing the debug build.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirLiveness.h:
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
(JSC::B3::Air::RegLivenessAdapter::numIndices):
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::TmpLivenessAdapter::maxIndex): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::maxIndex): Deleted.
(JSC::B3::Air::RegLivenessAdapter::maxIndex): Deleted.
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::forNode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
* dfg/DFGAtTailAbstractState.cpp:
(JSC::DFG::AtTailAbstractState::createValueForNode):
(JSC::DFG::AtTailAbstractState::forNode):
* dfg/DFGAtTailAbstractState.h:
* dfg/DFGBasicBlock.h:
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::liveNodesAtHead):
* dfg/DFGCombinedLiveness.h:
* dfg/DFGFlowIndexing.cpp: Added.
(JSC::DFG::FlowIndexing::FlowIndexing):
(JSC::DFG::FlowIndexing::~FlowIndexing):
(JSC::DFG::FlowIndexing::recompute):
* dfg/DFGFlowIndexing.h: Added.
(JSC::DFG::FlowIndexing::graph):
(JSC::DFG::FlowIndexing::numIndices):
(JSC::DFG::FlowIndexing::index):
(JSC::DFG::FlowIndexing::shadowIndex):
(JSC::DFG::FlowIndexing::nodeProjection):
* dfg/DFGFlowMap.h: Added.
(JSC::DFG::FlowMap::FlowMap):
(JSC::DFG::FlowMap::resize):
(JSC::DFG::FlowMap::graph):
(JSC::DFG::FlowMap::at):
(JSC::DFG::FlowMap::atShadow):
(WTF::printInternal):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::abstractValuesCache): Deleted.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::setLiveValues):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
(JSC::DFG::InPlaceAbstractState::merge):
* dfg/DFGInPlaceAbstractState.h:
(JSC::DFG::InPlaceAbstractState::createValueForNode):
(JSC::DFG::InPlaceAbstractState::forNode):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
(JSC::DFG::LivenessAnalysisPhase::run):
(JSC::DFG::LivenessAnalysisPhase::processBlock):
(JSC::DFG::LivenessAnalysisPhase::addChildUse): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::NodeComparator::operator()):
(JSC::DFG::nodeListDump):
(JSC::DFG::nodeMapDump):
(JSC::DFG::nodeValuePairListDump):
(JSC::DFG::nodeComparator): Deleted.
* dfg/DFGNodeAbstractValuePair.cpp: Added.
(JSC::DFG::NodeAbstractValuePair::dump):
* dfg/DFGNodeAbstractValuePair.h: Added.
(JSC::DFG::NodeAbstractValuePair::NodeAbstractValuePair):
* dfg/DFGNodeFlowProjection.cpp: Added.
(JSC::DFG::NodeFlowProjection::dump):
* dfg/DFGNodeFlowProjection.h: Added.
(JSC::DFG::NodeFlowProjection::NodeFlowProjection):
(JSC::DFG::NodeFlowProjection::operator bool):
(JSC::DFG::NodeFlowProjection::kind):
(JSC::DFG::NodeFlowProjection::node):
(JSC::DFG::NodeFlowProjection::operator*):
(JSC::DFG::NodeFlowProjection::operator->):
(JSC::DFG::NodeFlowProjection::hash):
(JSC::DFG::NodeFlowProjection::operator==):
(JSC::DFG::NodeFlowProjection::operator!=):
(JSC::DFG::NodeFlowProjection::operator<):
(JSC::DFG::NodeFlowProjection::operator>):
(JSC::DFG::NodeFlowProjection::operator<=):
(JSC::DFG::NodeFlowProjection::operator>=):
(JSC::DFG::NodeFlowProjection::isHashTableDeletedValue):
(JSC::DFG::NodeFlowProjection::isStillValid):
(JSC::DFG::NodeFlowProjection::forEach):
(JSC::DFG::NodeFlowProjectionHash::hash):
(JSC::DFG::NodeFlowProjectionHash::equal):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
2016-11-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r208364.
https://bugs.webkit.org/show_bug.cgi?id=164402
broke the build (Requested by smfr on #webkit).
Reverted changeset:
"DFG plays fast and loose with the shadow values of a Phi"
https://bugs.webkit.org/show_bug.cgi?id=164309
http://trac.webkit.org/changeset/208364
2016-11-03 Filip Pizlo <fpizlo@apple.com>
DFG plays fast and loose with the shadow values of a Phi
https://bugs.webkit.org/show_bug.cgi?id=164309
Reviewed by Saam Barati.
Oh boy, what an embarrassing mistake! The style of SSA I like to use avoids block/value
tuples as parameters of a Phi, thereby simplifying CFG transformations and making Phi largely
not a special case for most compiler transforms. It does this by introducing another value
called Upsilon, which stores a value into some Phi.
B3 uses this also. The easiest way to understand what Upsilon/Phi behave like is to look at
the B3->Air lowering. Air is not SSA - it has Tmps that you can assign to and use as many
times as you like. B3 allocates one Tmp per Value, and an extra "phiTmp" for Phis, so that
Phis get two Tmps total. Upsilon stores the value into the phiTmp of the Phi, while Phi moves
the value from its phiTmp to its tmp.
This is necessary to support scenarios like this:
a: Phi()
b: Upsilon(@x, ^a)
c: Use(@a)
Here, we want @c to see @a's value before @b. That's a very basic requirement of SSA: that
the a value (like @a) doesn't change during its lifetime.
Unfortunately, DFG's liveness analysis, abstract interpreter, and integer range optimization
all failed to correctly model Upsilon/Phi this way. They would assume that it's accurate to
model the Upsilon as storing into the Phi directly.
Because DFG does flow analysis over SSA, making it correct means enabling it to speak of the
shadow value. This change addresses this problem by introducing the concept of a
NodeFlowProjection. This is a key that lets us speak of both a Node's primary value and its
optional "shadow" value. Liveness, AI, and integer range are now keyed by NodeFlowProjection
rather than Node*. Conceptually this turns out to be a very simple change, but it does touch
a good amount of code.
This looks to be perf-neutral.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/air/AirLiveness.h:
(JSC::B3::Air::TmpLivenessAdapter::numIndices):
(JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
(JSC::B3::Air::RegLivenessAdapter::numIndices):
(JSC::B3::Air::AbstractLiveness::AbstractLiveness):
(JSC::B3::Air::TmpLivenessAdapter::maxIndex): Deleted.
(JSC::B3::Air::StackSlotLivenessAdapter::maxIndex): Deleted.
(JSC::B3::Air::RegLivenessAdapter::maxIndex): Deleted.
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::forNode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
* dfg/DFGAtTailAbstractState.cpp:
(JSC::DFG::AtTailAbstractState::createValueForNode):
(JSC::DFG::AtTailAbstractState::forNode):
* dfg/DFGAtTailAbstractState.h:
* dfg/DFGBasicBlock.h:
* dfg/DFGCombinedLiveness.cpp:
(JSC::DFG::liveNodesAtHead):
* dfg/DFGCombinedLiveness.h:
* dfg/DFGFlowIndexing.cpp: Added.
(JSC::DFG::FlowIndexing::FlowIndexing):
(JSC::DFG::FlowIndexing::~FlowIndexing):
(JSC::DFG::FlowIndexing::recompute):
* dfg/DFGFlowIndexing.h: Added.
(JSC::DFG::FlowIndexing::graph):
(JSC::DFG::FlowIndexing::numIndices):
(JSC::DFG::FlowIndexing::index):
(JSC::DFG::FlowIndexing::shadowIndex):
(JSC::DFG::FlowIndexing::nodeProjection):
* dfg/DFGFlowMap.h: Added.
(JSC::DFG::FlowMap::FlowMap):
(JSC::DFG::FlowMap::resize):
(JSC::DFG::FlowMap::graph):
(JSC::DFG::FlowMap::at):
(JSC::DFG::FlowMap::atShadow):
(WTF::printInternal):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::abstractValuesCache): Deleted.
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::setLiveValues):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
(JSC::DFG::InPlaceAbstractState::merge):
* dfg/DFGInPlaceAbstractState.h:
(JSC::DFG::InPlaceAbstractState::createValueForNode):
(JSC::DFG::InPlaceAbstractState::forNode):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGLivenessAnalysisPhase.cpp:
(JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
(JSC::DFG::LivenessAnalysisPhase::run):
(JSC::DFG::LivenessAnalysisPhase::processBlock):
(JSC::DFG::LivenessAnalysisPhase::addChildUse): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::NodeComparator::operator()):
(JSC::DFG::nodeListDump):
(JSC::DFG::nodeMapDump):
(JSC::DFG::nodeValuePairListDump):
(JSC::DFG::nodeComparator): Deleted.
* dfg/DFGNodeAbstractValuePair.cpp: Added.
(JSC::DFG::NodeAbstractValuePair::dump):
* dfg/DFGNodeAbstractValuePair.h: Added.
(JSC::DFG::NodeAbstractValuePair::NodeAbstractValuePair):
* dfg/DFGNodeFlowProjection.cpp: Added.
(JSC::DFG::NodeFlowProjection::dump):
* dfg/DFGNodeFlowProjection.h: Added.
(JSC::DFG::NodeFlowProjection::NodeFlowProjection):
(JSC::DFG::NodeFlowProjection::operator bool):
(JSC::DFG::NodeFlowProjection::kind):
(JSC::DFG::NodeFlowProjection::node):
(JSC::DFG::NodeFlowProjection::operator*):
(JSC::DFG::NodeFlowProjection::operator->):
(JSC::DFG::NodeFlowProjection::hash):
(JSC::DFG::NodeFlowProjection::operator==):
(JSC::DFG::NodeFlowProjection::operator!=):
(JSC::DFG::NodeFlowProjection::operator<):
(JSC::DFG::NodeFlowProjection::operator>):
(JSC::DFG::NodeFlowProjection::operator<=):
(JSC::DFG::NodeFlowProjection::operator>=):
(JSC::DFG::NodeFlowProjection::isHashTableDeletedValue):
(JSC::DFG::NodeFlowProjection::isStillValid):
(JSC::DFG::NodeFlowProjection::forEach):
(JSC::DFG::NodeFlowProjectionHash::hash):
(JSC::DFG::NodeFlowProjectionHash::equal):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
2016-11-03 Keith Miller <keith_miller@apple.com>
Unreviewed, changelog fix due to failed git rebase..
2016-11-03 Keith Miller <keith_miller@apple.com>
Wasm starts a new stack whenever it adds a new block and has return types for blocks.
https://bugs.webkit.org/show_bug.cgi?id=164100
Reviewed by Saam Barati.
This patch overhauls much of the Wasm function parser, validator, and B3 IR generator
to work with block return types. In Wasm, blocks can act as expressions and have a
return value. Most of the control flow operators needed to be rewritten in order to
support this feature. To enable return types the function parser needed to be able
to save and restore the expression stack from previous blocks, which is done via the
control stack.
This patch also removes the lazy continuation block system added previously. It's
not clear if there would be any performance win from such a system. There are likely
many other things with orders of magnitude more impact on B3 IR generation. The
complexity cost of such a system is not worth the effort without sufficient evidence
otherwise.
* testWasm.cpp:
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseBlock):
(JSC::Wasm::FunctionParser<Context>::addReturn):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
(JSC::Wasm::FunctionParser<Context>::popExpressionStack):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::ControlData::hasNonVoidSignature):
(JSC::Wasm::Validate::addElse):
(JSC::Wasm::Validate::addElseToUnreachable):
(JSC::Wasm::Validate::addBranch):
(JSC::Wasm::Validate::endBlock):
(JSC::Wasm::Validate::addEndToUnreachable):
(JSC::Wasm::Validate::dump):
(JSC::Wasm::validateFunction):
(JSC::Wasm::Validate::isContinuationReachable): Deleted.
2016-11-03 Saam Barati <sbarati@apple.com>
Asking for a value profile prediction should be defensive against not finding a value profile
https://bugs.webkit.org/show_bug.cgi?id=164306
Reviewed by Mark Lam.
Currently, the code that calls CodeBlock::valueProfilePredictionForBytecodeOffset
in the DFG assumes it will always be at a value producing node. However, this isn't
true if we tail call from an inlined setter. When we're at a tail call, we try
to find the first caller that isn't a tail call to see what value the
tail_call produces. If we inline a setter, however, we will end up finding
the put_by_id as our first non-tail-called "caller", and that won't have a
value profile associated with it since it's not a value producing node.
CodeBlock::valueProfilePredictionForBytecodeOffset should be defensive
against finding a null value profile.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2016-11-02 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, fix CLoop build after r208320.
https://bugs.webkit.org/show_bug.cgi?id=162980
Add required forward declarations.
* domjit/DOMJITHeapRange.cpp:
* domjit/DOMJITSignature.h:
* runtime/VM.h:
2016-11-02 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Add DOMJIT::Signature
https://bugs.webkit.org/show_bug.cgi?id=162980
Reviewed by Saam Barati and Sam Weinig.
This patch introduces a new mechanism called DOMJIT::Signature. We can annotate the function with DOMJIT::Signature.
DOMJIT::Signature has type information of that function. And it also maintains the effect of the function and the
pointer to the unsafe function. The unsafe function means the function without type and argument count checks.
By using these information, we can separate type and argument count checks from the function. And we can emit
these things as DFG checks and convert the function call itself to CallDOM node. CallDOM node can call the unsafe
function directly without any checks. Furthermore, this CallDOM node can represent its own clobberizing rules based
on DOMJIT::Effect maintained by DOMJIT::Signature. It allows us to make opaque Call node to a CallDOM node that
merely reads some part of heap. These changes (1) can drop duplicate type checks in DFG, (2) offer ability to move
CallDOM node to somewhere, and (3) track more detailed heap reads and writes of CallDOM nodes.
We first emit Call node with DOMJIT::Signature in DFGByteCodeParser. And in the fixup phase, we attempt to lower
Call node to CallDOM node with checks & edge filters. This is because we do not know the type predictions in
DFGByteCodeParser phase. If we always emit CallDOM node in DFGByteCodeParser, if we evaluate `div.getAttribute(true)`
thingy, the Uncountable OSR exits repeatedly happen because AI figures out the abstract value is cleared.
Currently, DOMJIT signature only allows the types that can reside in GPR. This is because the types of the unsafe
function arguments are represented as the sequence of void*. In the future, we will extend to accept other types like
float, double etc.
We annotate several functions in Element. In particular, we annotate Element::getAttribute. This allows us to perform
LICM in Dromaeo dom-attr test. In the Dromaeo dom-attr getAttribute test, we can see 32x improvement. (134974.8 v.s. 4203.4)
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallVariant.h:
(JSC::CallVariant::functionExecutable):
(JSC::CallVariant::nativeExecutable):
(JSC::CallVariant::signatureFor):
* bytecode/SpeculatedType.h:
(JSC::isNotStringSpeculation):
(JSC::isNotInt32Speculation):
(JSC::isNotBooleanSpeculation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeCallDOM):
(JSC::DFG::FixupPhase::fixupCheckDOM):
(JSC::DFG::FixupPhase::fixupCallDOM):
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToCallDOM):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::shouldSpeculateNotInt32):
(JSC::DFG::Node::shouldSpeculateNotBoolean):
(JSC::DFG::Node::shouldSpeculateNotString):
(JSC::DFG::Node::hasSignature):
(JSC::DFG::Node::signature):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* domjit/DOMJITEffect.h:
(JSC::DOMJIT::Effect::Effect):
(JSC::DOMJIT::Effect::forWrite):
(JSC::DOMJIT::Effect::forRead):
(JSC::DOMJIT::Effect::forReadWrite):
(JSC::DOMJIT::Effect::forPure):
(JSC::DOMJIT::Effect::forDef):
(JSC::DOMJIT::Effect::mustGenerate):
In clang, we cannot make this Effect constructor constexpr if we use Optional<HeapRange>.
So we use HeapRange::top() for Nullopt def now.
* domjit/DOMJITHeapRange.h:
(JSC::DOMJIT::HeapRange::fromRaw):
(JSC::DOMJIT::HeapRange::operator bool):
(JSC::DOMJIT::HeapRange::operator==):
(JSC::DOMJIT::HeapRange::operator!=):
(JSC::DOMJIT::HeapRange::fromConstant):
* domjit/DOMJITSignature.h: Copied from Source/JavaScriptCore/domjit/DOMJITEffect.h.
(JSC::DOMJIT::Signature::Signature):
(JSC::DOMJIT::Signature::argumentCount):
(JSC::DOMJIT::Signature::checkDOM):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jit/JITOperations.h:
* jit/JITThunks.cpp:
(JSC::JITThunks::hostFunctionStub):
* jit/JITThunks.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
* runtime/JSFunction.h:
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::create):
* runtime/JSObject.cpp:
(JSC::JSObject::putDirectNativeFunction):
* runtime/JSObject.h:
* runtime/Lookup.h:
(JSC::HashTableValue::functionLength):
(JSC::HashTableValue::signature):
(JSC::reifyStaticProperty):
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::NativeExecutable):
* runtime/NativeExecutable.h:
* runtime/PropertySlot.h:
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
* runtime/VM.h:
2016-11-02 Andreas Kling <akling@apple.com>
MarkedSpace should have specialized size classes for popular engine objects.
<https://webkit.org/b/164345>
Reviewed by Filip Pizlo.
The MarkedSpace size classes were recently reworked to minimize wasted space
at the end of MarkedBlocks.
However, we know that some specific objects will be allocated in very high volume.
Adding specialized size classes for those object sizes achieves greater utilization
since we're basically guaranteed to allocate them all the time.
Inject specialized size classes for these four objects:
- FunctionCodeBlock
560 bytes instead of 624
28 per block instead of 26 (+2)
- FunctionExecutable
176 bytes instead of 224
92 per block instead of 72 (+20)
- UnlinkedFunctionCodeBlock
256 bytes instead of 320
63 per block instead of 50 (+13)
- UnlinkedFunctionExecutable
192 bytes instead of 224
84 per block instead of 72 (+12)
* heap/MarkedSpace.cpp:
2016-11-02 Geoffrey Garen <ggaren@apple.com>
One file per class for UnlinkedCodeBlock.h/.cpp
https://bugs.webkit.org/show_bug.cgi?id=164348
Reviewed by Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/FunctionCodeBlock.h:
* bytecode/ModuleProgramCodeBlock.h:
* bytecode/ProgramCodeBlock.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedEvalCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecode/UnlinkedEvalCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::estimatedSize): Deleted.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::getLineAndColumn): Deleted.
(JSC::dumpLineColumnEntry): Deleted.
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted.
(JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::~UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
(JSC::UnlinkedCodeBlock::setInstructions): Deleted.
(JSC::UnlinkedCodeBlock::instructions): Deleted.
(JSC::UnlinkedCodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::handlerForIndex): Deleted.
(JSC::UnlinkedCodeBlock::applyModification): Deleted.
* bytecode/UnlinkedEvalCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::parseMode): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
(JSC::UnlinkedCodeBlock::derivedContextType): Deleted.
(JSC::UnlinkedCodeBlock::evalContextType): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunctionContext): Deleted.
(JSC::UnlinkedCodeBlock::isClassContext): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::superBinding): Deleted.
(JSC::UnlinkedCodeBlock::scriptMode): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numCalleeLocals): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::sourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::sourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::UnlinkedCodeBlock::didOptimize): Deleted.
(JSC::UnlinkedCodeBlock::setDidOptimize): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecode/UnlinkedFunctionCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::estimatedSize): Deleted.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::getLineAndColumn): Deleted.
(JSC::dumpLineColumnEntry): Deleted.
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted.
(JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::~UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedEvalCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
(JSC::UnlinkedCodeBlock::setInstructions): Deleted.
(JSC::UnlinkedCodeBlock::instructions): Deleted.
(JSC::UnlinkedCodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::handlerForIndex): Deleted.
(JSC::UnlinkedCodeBlock::applyModification): Deleted.
* bytecode/UnlinkedFunctionCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::parseMode): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
(JSC::UnlinkedCodeBlock::derivedContextType): Deleted.
(JSC::UnlinkedCodeBlock::evalContextType): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunctionContext): Deleted.
(JSC::UnlinkedCodeBlock::isClassContext): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::superBinding): Deleted.
(JSC::UnlinkedCodeBlock::scriptMode): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numCalleeLocals): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::sourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::sourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::UnlinkedCodeBlock::didOptimize): Deleted.
(JSC::UnlinkedCodeBlock::setDidOptimize): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::destroy):
* bytecode/UnlinkedGlobalCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::parseMode): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
(JSC::UnlinkedCodeBlock::derivedContextType): Deleted.
(JSC::UnlinkedCodeBlock::evalContextType): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunctionContext): Deleted.
(JSC::UnlinkedCodeBlock::isClassContext): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::superBinding): Deleted.
(JSC::UnlinkedCodeBlock::scriptMode): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numCalleeLocals): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::sourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::sourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::UnlinkedCodeBlock::didOptimize): Deleted.
(JSC::UnlinkedCodeBlock::setDidOptimize): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
* bytecode/UnlinkedModuleProgramCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::estimatedSize): Deleted.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::getLineAndColumn): Deleted.
(JSC::dumpLineColumnEntry): Deleted.
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted.
(JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::~UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedEvalCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
(JSC::UnlinkedCodeBlock::setInstructions): Deleted.
(JSC::UnlinkedCodeBlock::instructions): Deleted.
(JSC::UnlinkedCodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::handlerForIndex): Deleted.
(JSC::UnlinkedCodeBlock::applyModification): Deleted.
* bytecode/UnlinkedModuleProgramCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::parseMode): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
(JSC::UnlinkedCodeBlock::derivedContextType): Deleted.
(JSC::UnlinkedCodeBlock::evalContextType): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunctionContext): Deleted.
(JSC::UnlinkedCodeBlock::isClassContext): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::superBinding): Deleted.
(JSC::UnlinkedCodeBlock::scriptMode): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numCalleeLocals): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::sourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::sourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::UnlinkedCodeBlock::didOptimize): Deleted.
(JSC::UnlinkedCodeBlock::setDidOptimize): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecode/UnlinkedProgramCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.cpp.
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::estimatedSize): Deleted.
(JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::getLineAndColumn): Deleted.
(JSC::dumpLineColumnEntry): Deleted.
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
(JSC::UnlinkedCodeBlock::~UnlinkedCodeBlock): Deleted.
(JSC::UnlinkedModuleProgramCodeBlock::destroy): Deleted.
(JSC::UnlinkedEvalCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionCodeBlock::destroy): Deleted.
(JSC::UnlinkedFunctionExecutable::destroy): Deleted.
(JSC::UnlinkedCodeBlock::setInstructions): Deleted.
(JSC::UnlinkedCodeBlock::instructions): Deleted.
(JSC::UnlinkedCodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::handlerForIndex): Deleted.
(JSC::UnlinkedCodeBlock::applyModification): Deleted.
* bytecode/UnlinkedProgramCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h.
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedSimpleJumpTable::add): Deleted.
(JSC::UnlinkedInstruction::UnlinkedInstruction): Deleted.
(JSC::UnlinkedCodeBlock::isConstructor): Deleted.
(JSC::UnlinkedCodeBlock::isStrictMode): Deleted.
(JSC::UnlinkedCodeBlock::usesEval): Deleted.
(JSC::UnlinkedCodeBlock::parseMode): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunction): Deleted.
(JSC::UnlinkedCodeBlock::derivedContextType): Deleted.
(JSC::UnlinkedCodeBlock::evalContextType): Deleted.
(JSC::UnlinkedCodeBlock::isArrowFunctionContext): Deleted.
(JSC::UnlinkedCodeBlock::isClassContext): Deleted.
(JSC::UnlinkedCodeBlock::hasExpressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::expressionInfo): Deleted.
(JSC::UnlinkedCodeBlock::setThisRegister): Deleted.
(JSC::UnlinkedCodeBlock::setScopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::usesGlobalObject): Deleted.
(JSC::UnlinkedCodeBlock::setGlobalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::globalObjectRegister): Deleted.
(JSC::UnlinkedCodeBlock::setNumParameters): Deleted.
(JSC::UnlinkedCodeBlock::addParameter): Deleted.
(JSC::UnlinkedCodeBlock::numParameters): Deleted.
(JSC::UnlinkedCodeBlock::addRegExp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfRegExps): Deleted.
(JSC::UnlinkedCodeBlock::regexp): Deleted.
(JSC::UnlinkedCodeBlock::numberOfIdentifiers): Deleted.
(JSC::UnlinkedCodeBlock::addIdentifier): Deleted.
(JSC::UnlinkedCodeBlock::identifier): Deleted.
(JSC::UnlinkedCodeBlock::identifiers): Deleted.
(JSC::UnlinkedCodeBlock::addConstant): Deleted.
(JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Deleted.
(JSC::UnlinkedCodeBlock::constantRegisters): Deleted.
(JSC::UnlinkedCodeBlock::constantRegister): Deleted.
(JSC::UnlinkedCodeBlock::isConstantRegisterIndex): Deleted.
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::UnlinkedCodeBlock::numberOfJumpTargets): Deleted.
(JSC::UnlinkedCodeBlock::addJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::jumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::lastJumpTarget): Deleted.
(JSC::UnlinkedCodeBlock::isBuiltinFunction): Deleted.
(JSC::UnlinkedCodeBlock::constructorKind): Deleted.
(JSC::UnlinkedCodeBlock::superBinding): Deleted.
(JSC::UnlinkedCodeBlock::scriptMode): Deleted.
(JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
(JSC::UnlinkedCodeBlock::numCalleeLocals): Deleted.
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::UnlinkedCodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionDecl): Deleted.
(JSC::UnlinkedCodeBlock::functionDecl): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionDecls): Deleted.
(JSC::UnlinkedCodeBlock::addFunctionExpr): Deleted.
(JSC::UnlinkedCodeBlock::functionExpr): Deleted.
(JSC::UnlinkedCodeBlock::numberOfFunctionExprs): Deleted.
(JSC::UnlinkedCodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::UnlinkedCodeBlock::addExceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::exceptionHandler): Deleted.
(JSC::UnlinkedCodeBlock::addArrayProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addArrayAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addObjectAllocationProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addValueProfile): Deleted.
(JSC::UnlinkedCodeBlock::numberOfValueProfiles): Deleted.
(JSC::UnlinkedCodeBlock::addLLIntCallLinkInfo): Deleted.
(JSC::UnlinkedCodeBlock::numberOfLLintCallLinkInfos): Deleted.
(JSC::UnlinkedCodeBlock::codeType): Deleted.
(JSC::UnlinkedCodeBlock::thisRegister): Deleted.
(JSC::UnlinkedCodeBlock::scopeRegister): Deleted.
(JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): Deleted.
(JSC::UnlinkedCodeBlock::numberOfPropertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::propertyAccessInstructions): Deleted.
(JSC::UnlinkedCodeBlock::constantBufferCount): Deleted.
(JSC::UnlinkedCodeBlock::addConstantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::constantBuffer): Deleted.
(JSC::UnlinkedCodeBlock::hasRareData): Deleted.
(JSC::UnlinkedCodeBlock::recordParse): Deleted.
(JSC::UnlinkedCodeBlock::sourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::sourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): Deleted.
(JSC::UnlinkedCodeBlock::codeFeatures): Deleted.
(JSC::UnlinkedCodeBlock::hasCapturedVariables): Deleted.
(JSC::UnlinkedCodeBlock::firstLine): Deleted.
(JSC::UnlinkedCodeBlock::lineCount): Deleted.
(JSC::UnlinkedCodeBlock::startColumn): Deleted.
(JSC::UnlinkedCodeBlock::endColumn): Deleted.
(JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): Deleted.
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): Deleted.
(JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::UnlinkedCodeBlock::didOptimize): Deleted.
(JSC::UnlinkedCodeBlock::setDidOptimize): Deleted.
(JSC::UnlinkedCodeBlock::finishCreation): Deleted.
(JSC::UnlinkedCodeBlock::createRareDataIfNecessary): Deleted.
(JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
* runtime/CodeCache.cpp:
* runtime/EvalExecutable.h:
* runtime/JSModuleRecord.cpp:
2016-11-02 Saam Barati <sbarati@apple.com>
Allocation elimination of rest parameter doesn't take into account indexed properties on Array.prototype/Object.prototype
https://bugs.webkit.org/show_bug.cgi?id=164301
Reviewed by Geoffrey Garen.
We weren't taking into account indexed properties on the __proto__
of the rest parameter. This made the code for doing out of bound
accesses incorrect since it just assumed it's safe for the result of
an out of bound access to be undefined. This broke the semantics
of JS code when there was an indexed property on the Array.prototype
or Object.prototype.
This patch makes sure we set up the proper watchpoints for making
sure out of bound accesses are safe to return undefined.
* dfg/DFGArgumentsEliminationPhase.cpp:
2016-11-02 Geoffrey Garen <ggaren@apple.com>
One file per class for CodeBlock.h/.cpp
https://bugs.webkit.org/show_bug.cgi?id=164343
Reviewed by Andreas Kling.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CallLinkInfo.cpp:
* bytecode/CodeBlock.cpp:
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
* bytecode/CodeBlock.h:
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
* bytecode/EvalCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/CodeBlock.cpp.
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::CodeBlock::inferredName): Deleted.
(JSC::CodeBlock::hasHash): Deleted.
(JSC::CodeBlock::isSafeToComputeHash): Deleted.
(JSC::CodeBlock::hash): Deleted.
(JSC::CodeBlock::sourceCodeForTools): Deleted.
(JSC::CodeBlock::sourceCodeOnOneLine): Deleted.
(JSC::CodeBlock::hashAsStringIfPossible): Deleted.
(JSC::CodeBlock::dumpAssumingJITType): Deleted.
(JSC::CodeBlock::dump): Deleted.
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpSource): Deleted.
(JSC::CodeBlock::dumpBytecode): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
(JSC::sizeInBytes): Deleted.
(JSC::CodeBlock::CodeBlock): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::~CodeBlock): Deleted.
(JSC::CodeBlock::setConstantRegisters): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::setNumParameters): Deleted.
(JSC::EvalCodeCache::visitAggregate): Deleted.
(JSC::CodeBlock::specialOSREntryBlockOrNull): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::estimatedSize): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::CodeBlock::shouldVisitStrongly): Deleted.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Deleted.
(JSC::shouldMarkTransition): Deleted.
(JSC::CodeBlock::propagateTransitions): Deleted.
(JSC::CodeBlock::determineLiveness): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Deleted.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addStubInfo): Deleted.
(JSC::CodeBlock::addJITAddIC): Deleted.
(JSC::CodeBlock::addJITMulIC): Deleted.
(JSC::CodeBlock::addJITSubIC): Deleted.
(JSC::CodeBlock::addJITNegIC): Deleted.
(JSC::CodeBlock::findStubInfo): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
(JSC::CodeBlock::addCallLinkInfo): Deleted.
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted.
(JSC::CodeBlock::resetJITData): Deleted.
(JSC::CodeBlock::visitOSRExitTargets): Deleted.
(JSC::CodeBlock::stronglyVisitStrongReferences): Deleted.
(JSC::CodeBlock::stronglyVisitWeakReferences): Deleted.
(JSC::CodeBlock::baselineAlternative): Deleted.
(JSC::CodeBlock::baselineVersion): Deleted.
(JSC::CodeBlock::hasOptimizedReplacement): Deleted.
(JSC::CodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::CodeBlock::handlerForIndex): Deleted.
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex): Deleted.
(JSC::CodeBlock::removeExceptionHandlerForCallSite): Deleted.
(JSC::CodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::CodeBlock::hasOpDebugForLineAndColumn): Deleted.
(JSC::CodeBlock::shrinkToFit): Deleted.
(JSC::CodeBlock::linkIncomingCall): Deleted.
(JSC::CodeBlock::linkIncomingPolymorphicCall): Deleted.
(JSC::CodeBlock::unlinkIncomingCalls): Deleted.
(JSC::CodeBlock::newReplacement): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
(JSC::CodeBlock::jettison): Deleted.
(JSC::CodeBlock::globalObjectFor): Deleted.
(JSC::RecursionCheckFunctor::RecursionCheckFunctor): Deleted.
(JSC::RecursionCheckFunctor::operator()): Deleted.
(JSC::RecursionCheckFunctor::didRecurse): Deleted.
(JSC::CodeBlock::noticeIncomingCall): Deleted.
(JSC::CodeBlock::reoptimizationRetryCounter): Deleted.
(JSC::CodeBlock::setCalleeSaveRegisters): Deleted.
(JSC::roundCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::countReoptimization): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::codeTypeThresholdMultiplier): Deleted.
(JSC::CodeBlock::optimizationThresholdScalingFactor): Deleted.
(JSC::clipThreshold): Deleted.
(JSC::CodeBlock::adjustedCounterValue): Deleted.
(JSC::CodeBlock::checkIfOptimizationThresholdReached): Deleted.
(JSC::CodeBlock::optimizeNextInvocation): Deleted.
(JSC::CodeBlock::dontOptimizeAnytimeSoon): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::optimizeAfterLongWarmUp): Deleted.
(JSC::CodeBlock::optimizeSoon): Deleted.
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently): Deleted.
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Deleted.
(JSC::CodeBlock::adjustedExitCountThreshold): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimization): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): Deleted.
(JSC::CodeBlock::shouldReoptimizeNow): Deleted.
(JSC::CodeBlock::shouldReoptimizeFromLoopNow): Deleted.
(JSC::CodeBlock::getArrayProfile): Deleted.
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
(JSC::CodeBlock::updateAllValueProfilePredictions): Deleted.
(JSC::CodeBlock::updateAllArrayPredictions): Deleted.
(JSC::CodeBlock::updateAllPredictions): Deleted.
(JSC::CodeBlock::shouldOptimizeNow): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::dumpValueProfiles): Deleted.
(JSC::CodeBlock::frameRegisterCount): Deleted.
(JSC::CodeBlock::stackPointerOffset): Deleted.
(JSC::CodeBlock::predictedMachineCodeSize): Deleted.
(JSC::CodeBlock::usesOpcode): Deleted.
(JSC::CodeBlock::nameForRegister): Deleted.
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::validate): Deleted.
(JSC::CodeBlock::beginValidationDidFail): Deleted.
(JSC::CodeBlock::endValidationDidFail): Deleted.
(JSC::CodeBlock::addBreakpoint): Deleted.
(JSC::CodeBlock::setSteppingMode): Deleted.
(JSC::CodeBlock::addRareCaseProfile): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForPC): Deleted.
(JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
(JSC::CodeBlock::capabilityLevel): Deleted.
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): Deleted.
(JSC::CodeBlock::setPCToCodeOriginMap): Deleted.
(JSC::CodeBlock::findPC): Deleted.
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): Deleted.
(JSC::CodeBlock::thresholdForJIT): Deleted.
(JSC::CodeBlock::jitAfterWarmUp): Deleted.
(JSC::CodeBlock::jitSoon): Deleted.
(JSC::CodeBlock::dumpMathICStats): Deleted.
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/EvalCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* bytecode/FunctionCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/CodeBlock.cpp.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
(JSC::CodeBlock::inferredName): Deleted.
(JSC::CodeBlock::hasHash): Deleted.
(JSC::CodeBlock::isSafeToComputeHash): Deleted.
(JSC::CodeBlock::hash): Deleted.
(JSC::CodeBlock::sourceCodeForTools): Deleted.
(JSC::CodeBlock::sourceCodeOnOneLine): Deleted.
(JSC::CodeBlock::hashAsStringIfPossible): Deleted.
(JSC::CodeBlock::dumpAssumingJITType): Deleted.
(JSC::CodeBlock::dump): Deleted.
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpSource): Deleted.
(JSC::CodeBlock::dumpBytecode): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
(JSC::sizeInBytes): Deleted.
(JSC::CodeBlock::CodeBlock): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::~CodeBlock): Deleted.
(JSC::CodeBlock::setConstantRegisters): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::setNumParameters): Deleted.
(JSC::EvalCodeCache::visitAggregate): Deleted.
(JSC::CodeBlock::specialOSREntryBlockOrNull): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::estimatedSize): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::CodeBlock::shouldVisitStrongly): Deleted.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Deleted.
(JSC::shouldMarkTransition): Deleted.
(JSC::CodeBlock::propagateTransitions): Deleted.
(JSC::CodeBlock::determineLiveness): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Deleted.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addStubInfo): Deleted.
(JSC::CodeBlock::addJITAddIC): Deleted.
(JSC::CodeBlock::addJITMulIC): Deleted.
(JSC::CodeBlock::addJITSubIC): Deleted.
(JSC::CodeBlock::addJITNegIC): Deleted.
(JSC::CodeBlock::findStubInfo): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
(JSC::CodeBlock::addCallLinkInfo): Deleted.
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted.
(JSC::CodeBlock::resetJITData): Deleted.
(JSC::CodeBlock::visitOSRExitTargets): Deleted.
(JSC::CodeBlock::stronglyVisitStrongReferences): Deleted.
(JSC::CodeBlock::stronglyVisitWeakReferences): Deleted.
(JSC::CodeBlock::baselineAlternative): Deleted.
(JSC::CodeBlock::baselineVersion): Deleted.
(JSC::CodeBlock::hasOptimizedReplacement): Deleted.
(JSC::CodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::CodeBlock::handlerForIndex): Deleted.
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex): Deleted.
(JSC::CodeBlock::removeExceptionHandlerForCallSite): Deleted.
(JSC::CodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::CodeBlock::hasOpDebugForLineAndColumn): Deleted.
(JSC::CodeBlock::shrinkToFit): Deleted.
(JSC::CodeBlock::linkIncomingCall): Deleted.
(JSC::CodeBlock::linkIncomingPolymorphicCall): Deleted.
(JSC::CodeBlock::unlinkIncomingCalls): Deleted.
(JSC::CodeBlock::newReplacement): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
(JSC::CodeBlock::jettison): Deleted.
(JSC::CodeBlock::globalObjectFor): Deleted.
(JSC::RecursionCheckFunctor::RecursionCheckFunctor): Deleted.
(JSC::RecursionCheckFunctor::operator()): Deleted.
(JSC::RecursionCheckFunctor::didRecurse): Deleted.
(JSC::CodeBlock::noticeIncomingCall): Deleted.
(JSC::CodeBlock::reoptimizationRetryCounter): Deleted.
(JSC::CodeBlock::setCalleeSaveRegisters): Deleted.
(JSC::roundCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::countReoptimization): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::codeTypeThresholdMultiplier): Deleted.
(JSC::CodeBlock::optimizationThresholdScalingFactor): Deleted.
(JSC::clipThreshold): Deleted.
(JSC::CodeBlock::adjustedCounterValue): Deleted.
(JSC::CodeBlock::checkIfOptimizationThresholdReached): Deleted.
(JSC::CodeBlock::optimizeNextInvocation): Deleted.
(JSC::CodeBlock::dontOptimizeAnytimeSoon): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::optimizeAfterLongWarmUp): Deleted.
(JSC::CodeBlock::optimizeSoon): Deleted.
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently): Deleted.
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Deleted.
(JSC::CodeBlock::adjustedExitCountThreshold): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimization): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): Deleted.
(JSC::CodeBlock::shouldReoptimizeNow): Deleted.
(JSC::CodeBlock::shouldReoptimizeFromLoopNow): Deleted.
(JSC::CodeBlock::getArrayProfile): Deleted.
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
(JSC::CodeBlock::updateAllValueProfilePredictions): Deleted.
(JSC::CodeBlock::updateAllArrayPredictions): Deleted.
(JSC::CodeBlock::updateAllPredictions): Deleted.
(JSC::CodeBlock::shouldOptimizeNow): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::dumpValueProfiles): Deleted.
(JSC::CodeBlock::frameRegisterCount): Deleted.
(JSC::CodeBlock::stackPointerOffset): Deleted.
(JSC::CodeBlock::predictedMachineCodeSize): Deleted.
(JSC::CodeBlock::usesOpcode): Deleted.
(JSC::CodeBlock::nameForRegister): Deleted.
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::validate): Deleted.
(JSC::CodeBlock::beginValidationDidFail): Deleted.
(JSC::CodeBlock::endValidationDidFail): Deleted.
(JSC::CodeBlock::addBreakpoint): Deleted.
(JSC::CodeBlock::setSteppingMode): Deleted.
(JSC::CodeBlock::addRareCaseProfile): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForPC): Deleted.
(JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
(JSC::CodeBlock::capabilityLevel): Deleted.
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): Deleted.
(JSC::CodeBlock::setPCToCodeOriginMap): Deleted.
(JSC::CodeBlock::findPC): Deleted.
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): Deleted.
(JSC::CodeBlock::thresholdForJIT): Deleted.
(JSC::CodeBlock::jitAfterWarmUp): Deleted.
(JSC::CodeBlock::jitSoon): Deleted.
(JSC::CodeBlock::dumpMathICStats): Deleted.
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/FunctionCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* bytecode/GlobalCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* bytecode/ModuleProgramCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/CodeBlock.cpp.
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
(JSC::CodeBlock::inferredName): Deleted.
(JSC::CodeBlock::hasHash): Deleted.
(JSC::CodeBlock::isSafeToComputeHash): Deleted.
(JSC::CodeBlock::hash): Deleted.
(JSC::CodeBlock::sourceCodeForTools): Deleted.
(JSC::CodeBlock::sourceCodeOnOneLine): Deleted.
(JSC::CodeBlock::hashAsStringIfPossible): Deleted.
(JSC::CodeBlock::dumpAssumingJITType): Deleted.
(JSC::CodeBlock::dump): Deleted.
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpSource): Deleted.
(JSC::CodeBlock::dumpBytecode): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
(JSC::sizeInBytes): Deleted.
(JSC::CodeBlock::CodeBlock): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::~CodeBlock): Deleted.
(JSC::CodeBlock::setConstantRegisters): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::setNumParameters): Deleted.
(JSC::EvalCodeCache::visitAggregate): Deleted.
(JSC::CodeBlock::specialOSREntryBlockOrNull): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::estimatedSize): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::CodeBlock::shouldVisitStrongly): Deleted.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Deleted.
(JSC::shouldMarkTransition): Deleted.
(JSC::CodeBlock::propagateTransitions): Deleted.
(JSC::CodeBlock::determineLiveness): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Deleted.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addStubInfo): Deleted.
(JSC::CodeBlock::addJITAddIC): Deleted.
(JSC::CodeBlock::addJITMulIC): Deleted.
(JSC::CodeBlock::addJITSubIC): Deleted.
(JSC::CodeBlock::addJITNegIC): Deleted.
(JSC::CodeBlock::findStubInfo): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
(JSC::CodeBlock::addCallLinkInfo): Deleted.
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted.
(JSC::CodeBlock::resetJITData): Deleted.
(JSC::CodeBlock::visitOSRExitTargets): Deleted.
(JSC::CodeBlock::stronglyVisitStrongReferences): Deleted.
(JSC::CodeBlock::stronglyVisitWeakReferences): Deleted.
(JSC::CodeBlock::baselineAlternative): Deleted.
(JSC::CodeBlock::baselineVersion): Deleted.
(JSC::CodeBlock::hasOptimizedReplacement): Deleted.
(JSC::CodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::CodeBlock::handlerForIndex): Deleted.
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex): Deleted.
(JSC::CodeBlock::removeExceptionHandlerForCallSite): Deleted.
(JSC::CodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::CodeBlock::hasOpDebugForLineAndColumn): Deleted.
(JSC::CodeBlock::shrinkToFit): Deleted.
(JSC::CodeBlock::linkIncomingCall): Deleted.
(JSC::CodeBlock::linkIncomingPolymorphicCall): Deleted.
(JSC::CodeBlock::unlinkIncomingCalls): Deleted.
(JSC::CodeBlock::newReplacement): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
(JSC::CodeBlock::jettison): Deleted.
(JSC::CodeBlock::globalObjectFor): Deleted.
(JSC::RecursionCheckFunctor::RecursionCheckFunctor): Deleted.
(JSC::RecursionCheckFunctor::operator()): Deleted.
(JSC::RecursionCheckFunctor::didRecurse): Deleted.
(JSC::CodeBlock::noticeIncomingCall): Deleted.
(JSC::CodeBlock::reoptimizationRetryCounter): Deleted.
(JSC::CodeBlock::setCalleeSaveRegisters): Deleted.
(JSC::roundCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::countReoptimization): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::codeTypeThresholdMultiplier): Deleted.
(JSC::CodeBlock::optimizationThresholdScalingFactor): Deleted.
(JSC::clipThreshold): Deleted.
(JSC::CodeBlock::adjustedCounterValue): Deleted.
(JSC::CodeBlock::checkIfOptimizationThresholdReached): Deleted.
(JSC::CodeBlock::optimizeNextInvocation): Deleted.
(JSC::CodeBlock::dontOptimizeAnytimeSoon): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::optimizeAfterLongWarmUp): Deleted.
(JSC::CodeBlock::optimizeSoon): Deleted.
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently): Deleted.
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Deleted.
(JSC::CodeBlock::adjustedExitCountThreshold): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimization): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): Deleted.
(JSC::CodeBlock::shouldReoptimizeNow): Deleted.
(JSC::CodeBlock::shouldReoptimizeFromLoopNow): Deleted.
(JSC::CodeBlock::getArrayProfile): Deleted.
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
(JSC::CodeBlock::updateAllValueProfilePredictions): Deleted.
(JSC::CodeBlock::updateAllArrayPredictions): Deleted.
(JSC::CodeBlock::updateAllPredictions): Deleted.
(JSC::CodeBlock::shouldOptimizeNow): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::dumpValueProfiles): Deleted.
(JSC::CodeBlock::frameRegisterCount): Deleted.
(JSC::CodeBlock::stackPointerOffset): Deleted.
(JSC::CodeBlock::predictedMachineCodeSize): Deleted.
(JSC::CodeBlock::usesOpcode): Deleted.
(JSC::CodeBlock::nameForRegister): Deleted.
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::validate): Deleted.
(JSC::CodeBlock::beginValidationDidFail): Deleted.
(JSC::CodeBlock::endValidationDidFail): Deleted.
(JSC::CodeBlock::addBreakpoint): Deleted.
(JSC::CodeBlock::setSteppingMode): Deleted.
(JSC::CodeBlock::addRareCaseProfile): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForPC): Deleted.
(JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
(JSC::CodeBlock::capabilityLevel): Deleted.
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): Deleted.
(JSC::CodeBlock::setPCToCodeOriginMap): Deleted.
(JSC::CodeBlock::findPC): Deleted.
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): Deleted.
(JSC::CodeBlock::thresholdForJIT): Deleted.
(JSC::CodeBlock::jitAfterWarmUp): Deleted.
(JSC::CodeBlock::jitSoon): Deleted.
(JSC::CodeBlock::dumpMathICStats): Deleted.
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/ModuleProgramCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* bytecode/ProgramCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/CodeBlock.cpp.
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::WebAssemblyCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
(JSC::CodeBlock::inferredName): Deleted.
(JSC::CodeBlock::hasHash): Deleted.
(JSC::CodeBlock::isSafeToComputeHash): Deleted.
(JSC::CodeBlock::hash): Deleted.
(JSC::CodeBlock::sourceCodeForTools): Deleted.
(JSC::CodeBlock::sourceCodeOnOneLine): Deleted.
(JSC::CodeBlock::hashAsStringIfPossible): Deleted.
(JSC::CodeBlock::dumpAssumingJITType): Deleted.
(JSC::CodeBlock::dump): Deleted.
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpSource): Deleted.
(JSC::CodeBlock::dumpBytecode): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
(JSC::sizeInBytes): Deleted.
(JSC::CodeBlock::CodeBlock): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::~CodeBlock): Deleted.
(JSC::CodeBlock::setConstantRegisters): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::setNumParameters): Deleted.
(JSC::EvalCodeCache::visitAggregate): Deleted.
(JSC::CodeBlock::specialOSREntryBlockOrNull): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::estimatedSize): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::CodeBlock::shouldVisitStrongly): Deleted.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Deleted.
(JSC::shouldMarkTransition): Deleted.
(JSC::CodeBlock::propagateTransitions): Deleted.
(JSC::CodeBlock::determineLiveness): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Deleted.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addStubInfo): Deleted.
(JSC::CodeBlock::addJITAddIC): Deleted.
(JSC::CodeBlock::addJITMulIC): Deleted.
(JSC::CodeBlock::addJITSubIC): Deleted.
(JSC::CodeBlock::addJITNegIC): Deleted.
(JSC::CodeBlock::findStubInfo): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
(JSC::CodeBlock::addCallLinkInfo): Deleted.
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted.
(JSC::CodeBlock::resetJITData): Deleted.
(JSC::CodeBlock::visitOSRExitTargets): Deleted.
(JSC::CodeBlock::stronglyVisitStrongReferences): Deleted.
(JSC::CodeBlock::stronglyVisitWeakReferences): Deleted.
(JSC::CodeBlock::baselineAlternative): Deleted.
(JSC::CodeBlock::baselineVersion): Deleted.
(JSC::CodeBlock::hasOptimizedReplacement): Deleted.
(JSC::CodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::CodeBlock::handlerForIndex): Deleted.
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex): Deleted.
(JSC::CodeBlock::removeExceptionHandlerForCallSite): Deleted.
(JSC::CodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::CodeBlock::hasOpDebugForLineAndColumn): Deleted.
(JSC::CodeBlock::shrinkToFit): Deleted.
(JSC::CodeBlock::linkIncomingCall): Deleted.
(JSC::CodeBlock::linkIncomingPolymorphicCall): Deleted.
(JSC::CodeBlock::unlinkIncomingCalls): Deleted.
(JSC::CodeBlock::newReplacement): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
(JSC::CodeBlock::jettison): Deleted.
(JSC::CodeBlock::globalObjectFor): Deleted.
(JSC::RecursionCheckFunctor::RecursionCheckFunctor): Deleted.
(JSC::RecursionCheckFunctor::operator()): Deleted.
(JSC::RecursionCheckFunctor::didRecurse): Deleted.
(JSC::CodeBlock::noticeIncomingCall): Deleted.
(JSC::CodeBlock::reoptimizationRetryCounter): Deleted.
(JSC::CodeBlock::setCalleeSaveRegisters): Deleted.
(JSC::roundCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::countReoptimization): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::codeTypeThresholdMultiplier): Deleted.
(JSC::CodeBlock::optimizationThresholdScalingFactor): Deleted.
(JSC::clipThreshold): Deleted.
(JSC::CodeBlock::adjustedCounterValue): Deleted.
(JSC::CodeBlock::checkIfOptimizationThresholdReached): Deleted.
(JSC::CodeBlock::optimizeNextInvocation): Deleted.
(JSC::CodeBlock::dontOptimizeAnytimeSoon): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::optimizeAfterLongWarmUp): Deleted.
(JSC::CodeBlock::optimizeSoon): Deleted.
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently): Deleted.
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Deleted.
(JSC::CodeBlock::adjustedExitCountThreshold): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimization): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): Deleted.
(JSC::CodeBlock::shouldReoptimizeNow): Deleted.
(JSC::CodeBlock::shouldReoptimizeFromLoopNow): Deleted.
(JSC::CodeBlock::getArrayProfile): Deleted.
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
(JSC::CodeBlock::updateAllValueProfilePredictions): Deleted.
(JSC::CodeBlock::updateAllArrayPredictions): Deleted.
(JSC::CodeBlock::updateAllPredictions): Deleted.
(JSC::CodeBlock::shouldOptimizeNow): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::dumpValueProfiles): Deleted.
(JSC::CodeBlock::frameRegisterCount): Deleted.
(JSC::CodeBlock::stackPointerOffset): Deleted.
(JSC::CodeBlock::predictedMachineCodeSize): Deleted.
(JSC::CodeBlock::usesOpcode): Deleted.
(JSC::CodeBlock::nameForRegister): Deleted.
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::validate): Deleted.
(JSC::CodeBlock::beginValidationDidFail): Deleted.
(JSC::CodeBlock::endValidationDidFail): Deleted.
(JSC::CodeBlock::addBreakpoint): Deleted.
(JSC::CodeBlock::setSteppingMode): Deleted.
(JSC::CodeBlock::addRareCaseProfile): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForPC): Deleted.
(JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
(JSC::CodeBlock::capabilityLevel): Deleted.
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): Deleted.
(JSC::CodeBlock::setPCToCodeOriginMap): Deleted.
(JSC::CodeBlock::findPC): Deleted.
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): Deleted.
(JSC::CodeBlock::thresholdForJIT): Deleted.
(JSC::CodeBlock::jitAfterWarmUp): Deleted.
(JSC::CodeBlock::jitSoon): Deleted.
(JSC::CodeBlock::dumpMathICStats): Deleted.
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/ProgramCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::WebAssemblyCodeBlock::create): Deleted.
(JSC::WebAssemblyCodeBlock::createStructure): Deleted.
(JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* bytecode/WebAssemblyCodeBlock.cpp: Copied from Source/JavaScriptCore/bytecode/CodeBlock.cpp.
(JSC::FunctionCodeBlock::destroy): Deleted.
(JSC::ProgramCodeBlock::destroy): Deleted.
(JSC::ModuleProgramCodeBlock::destroy): Deleted.
(JSC::EvalCodeBlock::destroy): Deleted.
(JSC::CodeBlock::inferredName): Deleted.
(JSC::CodeBlock::hasHash): Deleted.
(JSC::CodeBlock::isSafeToComputeHash): Deleted.
(JSC::CodeBlock::hash): Deleted.
(JSC::CodeBlock::sourceCodeForTools): Deleted.
(JSC::CodeBlock::sourceCodeOnOneLine): Deleted.
(JSC::CodeBlock::hashAsStringIfPossible): Deleted.
(JSC::CodeBlock::dumpAssumingJITType): Deleted.
(JSC::CodeBlock::dump): Deleted.
(JSC::idName): Deleted.
(JSC::CodeBlock::registerName): Deleted.
(JSC::CodeBlock::constantName): Deleted.
(JSC::regexpToSourceString): Deleted.
(JSC::regexpName): Deleted.
(JSC::debugHookName): Deleted.
(JSC::CodeBlock::printUnaryOp): Deleted.
(JSC::CodeBlock::printBinaryOp): Deleted.
(JSC::CodeBlock::printConditionalJump): Deleted.
(JSC::CodeBlock::printGetByIdOp): Deleted.
(JSC::dumpStructure): Deleted.
(JSC::dumpChain): Deleted.
(JSC::CodeBlock::printGetByIdCacheStatus): Deleted.
(JSC::CodeBlock::printPutByIdCacheStatus): Deleted.
(JSC::CodeBlock::printCallOp): Deleted.
(JSC::CodeBlock::printPutByIdOp): Deleted.
(JSC::CodeBlock::dumpSource): Deleted.
(JSC::CodeBlock::dumpBytecode): Deleted.
(JSC::CodeBlock::dumpExceptionHandlers): Deleted.
(JSC::CodeBlock::beginDumpProfiling): Deleted.
(JSC::CodeBlock::dumpValueProfiling): Deleted.
(JSC::CodeBlock::dumpArrayProfiling): Deleted.
(JSC::CodeBlock::dumpRareCaseProfile): Deleted.
(JSC::CodeBlock::dumpArithProfile): Deleted.
(JSC::CodeBlock::printLocationAndOp): Deleted.
(JSC::CodeBlock::printLocationOpAndRegisterOperand): Deleted.
(JSC::sizeInBytes): Deleted.
(JSC::CodeBlock::CodeBlock): Deleted.
(JSC::CodeBlock::finishCreation): Deleted.
(JSC::CodeBlock::~CodeBlock): Deleted.
(JSC::CodeBlock::setConstantRegisters): Deleted.
(JSC::CodeBlock::setAlternative): Deleted.
(JSC::CodeBlock::setNumParameters): Deleted.
(JSC::EvalCodeCache::visitAggregate): Deleted.
(JSC::CodeBlock::specialOSREntryBlockOrNull): Deleted.
(JSC::CodeBlock::visitWeakly): Deleted.
(JSC::CodeBlock::estimatedSize): Deleted.
(JSC::CodeBlock::visitChildren): Deleted.
(JSC::CodeBlock::shouldVisitStrongly): Deleted.
(JSC::CodeBlock::shouldJettisonDueToWeakReference): Deleted.
(JSC::timeToLive): Deleted.
(JSC::CodeBlock::shouldJettisonDueToOldAge): Deleted.
(JSC::shouldMarkTransition): Deleted.
(JSC::CodeBlock::propagateTransitions): Deleted.
(JSC::CodeBlock::determineLiveness): Deleted.
(JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
(JSC::CodeBlock::clearLLIntGetByIdCache): Deleted.
(JSC::CodeBlock::finalizeLLIntInlineCaches): Deleted.
(JSC::CodeBlock::finalizeBaselineJITInlineCaches): Deleted.
(JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
(JSC::CodeBlock::getStubInfoMap): Deleted.
(JSC::CodeBlock::getCallLinkInfoMap): Deleted.
(JSC::CodeBlock::getByValInfoMap): Deleted.
(JSC::CodeBlock::addStubInfo): Deleted.
(JSC::CodeBlock::addJITAddIC): Deleted.
(JSC::CodeBlock::addJITMulIC): Deleted.
(JSC::CodeBlock::addJITSubIC): Deleted.
(JSC::CodeBlock::addJITNegIC): Deleted.
(JSC::CodeBlock::findStubInfo): Deleted.
(JSC::CodeBlock::addByValInfo): Deleted.
(JSC::CodeBlock::addCallLinkInfo): Deleted.
(JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): Deleted.
(JSC::CodeBlock::resetJITData): Deleted.
(JSC::CodeBlock::visitOSRExitTargets): Deleted.
(JSC::CodeBlock::stronglyVisitStrongReferences): Deleted.
(JSC::CodeBlock::stronglyVisitWeakReferences): Deleted.
(JSC::CodeBlock::baselineAlternative): Deleted.
(JSC::CodeBlock::baselineVersion): Deleted.
(JSC::CodeBlock::hasOptimizedReplacement): Deleted.
(JSC::CodeBlock::handlerForBytecodeOffset): Deleted.
(JSC::CodeBlock::handlerForIndex): Deleted.
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex): Deleted.
(JSC::CodeBlock::removeExceptionHandlerForCallSite): Deleted.
(JSC::CodeBlock::lineNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::columnNumberForBytecodeOffset): Deleted.
(JSC::CodeBlock::expressionRangeForBytecodeOffset): Deleted.
(JSC::CodeBlock::hasOpDebugForLineAndColumn): Deleted.
(JSC::CodeBlock::shrinkToFit): Deleted.
(JSC::CodeBlock::linkIncomingCall): Deleted.
(JSC::CodeBlock::linkIncomingPolymorphicCall): Deleted.
(JSC::CodeBlock::unlinkIncomingCalls): Deleted.
(JSC::CodeBlock::newReplacement): Deleted.
(JSC::CodeBlock::replacement): Deleted.
(JSC::CodeBlock::computeCapabilityLevel): Deleted.
(JSC::CodeBlock::jettison): Deleted.
(JSC::CodeBlock::globalObjectFor): Deleted.
(JSC::RecursionCheckFunctor::RecursionCheckFunctor): Deleted.
(JSC::RecursionCheckFunctor::operator()): Deleted.
(JSC::RecursionCheckFunctor::didRecurse): Deleted.
(JSC::CodeBlock::noticeIncomingCall): Deleted.
(JSC::CodeBlock::reoptimizationRetryCounter): Deleted.
(JSC::CodeBlock::setCalleeSaveRegisters): Deleted.
(JSC::roundCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::countReoptimization): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::codeTypeThresholdMultiplier): Deleted.
(JSC::CodeBlock::optimizationThresholdScalingFactor): Deleted.
(JSC::clipThreshold): Deleted.
(JSC::CodeBlock::adjustedCounterValue): Deleted.
(JSC::CodeBlock::checkIfOptimizationThresholdReached): Deleted.
(JSC::CodeBlock::optimizeNextInvocation): Deleted.
(JSC::CodeBlock::dontOptimizeAnytimeSoon): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::optimizeAfterLongWarmUp): Deleted.
(JSC::CodeBlock::optimizeSoon): Deleted.
(JSC::CodeBlock::forceOptimizationSlowPathConcurrently): Deleted.
(JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult): Deleted.
(JSC::CodeBlock::adjustedExitCountThreshold): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimization): Deleted.
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): Deleted.
(JSC::CodeBlock::shouldReoptimizeNow): Deleted.
(JSC::CodeBlock::shouldReoptimizeFromLoopNow): Deleted.
(JSC::CodeBlock::getArrayProfile): Deleted.
(JSC::CodeBlock::addArrayProfile): Deleted.
(JSC::CodeBlock::getOrAddArrayProfile): Deleted.
(JSC::CodeBlock::codeOrigins): Deleted.
(JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
(JSC::CodeBlock::updateAllValueProfilePredictions): Deleted.
(JSC::CodeBlock::updateAllArrayPredictions): Deleted.
(JSC::CodeBlock::updateAllPredictions): Deleted.
(JSC::CodeBlock::shouldOptimizeNow): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::dumpValueProfiles): Deleted.
(JSC::CodeBlock::frameRegisterCount): Deleted.
(JSC::CodeBlock::stackPointerOffset): Deleted.
(JSC::CodeBlock::predictedMachineCodeSize): Deleted.
(JSC::CodeBlock::usesOpcode): Deleted.
(JSC::CodeBlock::nameForRegister): Deleted.
(JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::validate): Deleted.
(JSC::CodeBlock::beginValidationDidFail): Deleted.
(JSC::CodeBlock::endValidationDidFail): Deleted.
(JSC::CodeBlock::addBreakpoint): Deleted.
(JSC::CodeBlock::setSteppingMode): Deleted.
(JSC::CodeBlock::addRareCaseProfile): Deleted.
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForBytecodeOffset): Deleted.
(JSC::CodeBlock::arithProfileForPC): Deleted.
(JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
(JSC::CodeBlock::capabilityLevel): Deleted.
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): Deleted.
(JSC::CodeBlock::setPCToCodeOriginMap): Deleted.
(JSC::CodeBlock::findPC): Deleted.
(JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): Deleted.
(JSC::CodeBlock::thresholdForJIT): Deleted.
(JSC::CodeBlock::jitAfterWarmUp): Deleted.
(JSC::CodeBlock::jitSoon): Deleted.
(JSC::CodeBlock::dumpMathICStats): Deleted.
(JSC::CodeBlock::livenessAnalysisSlow): Deleted.
* bytecode/WebAssemblyCodeBlock.h: Copied from Source/JavaScriptCore/bytecode/CodeBlock.h.
(): Deleted.
(JSC::CodeBlock::unlinkedCodeBlock): Deleted.
(JSC::CodeBlock::numParameters): Deleted.
(JSC::CodeBlock::numCalleeLocals): Deleted.
(JSC::CodeBlock::addressOfNumParameters): Deleted.
(JSC::CodeBlock::offsetOfNumParameters): Deleted.
(JSC::CodeBlock::alternative): Deleted.
(JSC::CodeBlock::forEachRelatedCodeBlock): Deleted.
(JSC::CodeBlock::specializationKind): Deleted.
(JSC::CodeBlock::isStrictMode): Deleted.
(JSC::CodeBlock::ecmaMode): Deleted.
(JSC::CodeBlock::isKnownNotImmediate): Deleted.
(JSC::CodeBlock::isTemporaryRegisterIndex): Deleted.
(JSC::CodeBlock::stubInfoBegin): Deleted.
(JSC::CodeBlock::stubInfoEnd): Deleted.
(JSC::CodeBlock::callLinkInfosBegin): Deleted.
(JSC::CodeBlock::callLinkInfosEnd): Deleted.
(JSC::CodeBlock::setJITCodeMap): Deleted.
(JSC::CodeBlock::jitCodeMap): Deleted.
(JSC::CodeBlock::bytecodeOffset): Deleted.
(JSC::CodeBlock::numberOfInstructions): Deleted.
(JSC::CodeBlock::instructions): Deleted.
(JSC::CodeBlock::instructionCount): Deleted.
(JSC::CodeBlock::setJITCode): Deleted.
(JSC::CodeBlock::jitCode): Deleted.
(JSC::CodeBlock::jitCodeOffset): Deleted.
(JSC::CodeBlock::jitType): Deleted.
(JSC::CodeBlock::hasBaselineJITProfiling): Deleted.
(JSC::CodeBlock::capabilityLevelState): Deleted.
(JSC::CodeBlock::ownerExecutable): Deleted.
(JSC::CodeBlock::ownerScriptExecutable): Deleted.
(JSC::CodeBlock::vm): Deleted.
(JSC::CodeBlock::setThisRegister): Deleted.
(JSC::CodeBlock::thisRegister): Deleted.
(JSC::CodeBlock::usesEval): Deleted.
(JSC::CodeBlock::setScopeRegister): Deleted.
(JSC::CodeBlock::scopeRegister): Deleted.
(JSC::CodeBlock::codeType): Deleted.
(JSC::CodeBlock::putByIdContext): Deleted.
(JSC::CodeBlock::source): Deleted.
(JSC::CodeBlock::sourceOffset): Deleted.
(JSC::CodeBlock::firstLineColumnOffset): Deleted.
(JSC::CodeBlock::numberOfJumpTargets): Deleted.
(JSC::CodeBlock::jumpTarget): Deleted.
(JSC::CodeBlock::numberOfArgumentValueProfiles): Deleted.
(JSC::CodeBlock::valueProfileForArgument): Deleted.
(JSC::CodeBlock::numberOfValueProfiles): Deleted.
(JSC::CodeBlock::valueProfile): Deleted.
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): Deleted.
(JSC::CodeBlock::totalNumberOfValueProfiles): Deleted.
(JSC::CodeBlock::getFromAllValueProfiles): Deleted.
(JSC::CodeBlock::numberOfRareCaseProfiles): Deleted.
(JSC::CodeBlock::likelyToTakeSlowCase): Deleted.
(JSC::CodeBlock::couldTakeSlowCase): Deleted.
(JSC::CodeBlock::numberOfArrayProfiles): Deleted.
(JSC::CodeBlock::arrayProfiles): Deleted.
(JSC::CodeBlock::numberOfExceptionHandlers): Deleted.
(JSC::CodeBlock::exceptionHandler): Deleted.
(JSC::CodeBlock::hasExpressionInfo): Deleted.
(JSC::CodeBlock::hasCodeOrigins): Deleted.
(JSC::CodeBlock::canGetCodeOrigin): Deleted.
(JSC::CodeBlock::codeOrigin): Deleted.
(JSC::CodeBlock::addFrequentExitSite): Deleted.
(JSC::CodeBlock::hasExitSite): Deleted.
(JSC::CodeBlock::exitProfile): Deleted.
(JSC::CodeBlock::lazyOperandValueProfiles): Deleted.
(JSC::CodeBlock::numberOfIdentifiers): Deleted.
(JSC::CodeBlock::identifier): Deleted.
(JSC::CodeBlock::constants): Deleted.
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::addConstant): Deleted.
(JSC::CodeBlock::addConstantLazily): Deleted.
(JSC::CodeBlock::constantRegister): Deleted.
(JSC::CodeBlock::isConstantRegisterIndex): Deleted.
(JSC::CodeBlock::getConstant): Deleted.
(JSC::CodeBlock::constantSourceCodeRepresentation): Deleted.
(JSC::CodeBlock::functionDecl): Deleted.
(JSC::CodeBlock::numberOfFunctionDecls): Deleted.
(JSC::CodeBlock::functionExpr): Deleted.
(JSC::CodeBlock::regexp): Deleted.
(JSC::CodeBlock::numberOfConstantBuffers): Deleted.
(JSC::CodeBlock::addConstantBuffer): Deleted.
(JSC::CodeBlock::constantBufferAsVector): Deleted.
(JSC::CodeBlock::constantBuffer): Deleted.
(JSC::CodeBlock::heap): Deleted.
(JSC::CodeBlock::globalObject): Deleted.
(JSC::CodeBlock::livenessAnalysis): Deleted.
(JSC::CodeBlock::numberOfSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTable): Deleted.
(JSC::CodeBlock::switchJumpTable): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::numberOfStringSwitchJumpTables): Deleted.
(JSC::CodeBlock::addStringSwitchJumpTable): Deleted.
(JSC::CodeBlock::stringSwitchJumpTable): Deleted.
(JSC::CodeBlock::evalCodeCache): Deleted.
(JSC::CodeBlock::checkIfJITThresholdReached): Deleted.
(JSC::CodeBlock::dontJITAnytimeSoon): Deleted.
(JSC::CodeBlock::llintExecuteCounter): Deleted.
(JSC::CodeBlock::llintGetByIdWatchpointMap): Deleted.
(JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): Deleted.
(JSC::CodeBlock::addressOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecuteCounter): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionActiveThreshold): Deleted.
(JSC::CodeBlock::offsetOfJITExecutionTotalCount): Deleted.
(JSC::CodeBlock::jitExecuteCounter): Deleted.
(JSC::CodeBlock::optimizationDelayCounter): Deleted.
(JSC::CodeBlock::osrExitCounter): Deleted.
(JSC::CodeBlock::countOSRExit): Deleted.
(JSC::CodeBlock::addressOfOSRExitCounter): Deleted.
(JSC::CodeBlock::offsetOfOSRExitCounter): Deleted.
(JSC::CodeBlock::calleeSaveRegisters): Deleted.
(JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): Deleted.
(JSC::CodeBlock::optimizeAfterWarmUp): Deleted.
(JSC::CodeBlock::numberOfDFGCompiles): Deleted.
(JSC::CodeBlock::hasDebuggerRequests): Deleted.
(JSC::CodeBlock::debuggerRequestsAddress): Deleted.
(JSC::CodeBlock::removeBreakpoint): Deleted.
(JSC::CodeBlock::clearDebuggerRequests): Deleted.
(JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): Deleted.
(JSC::CodeBlock::clearExceptionHandlers): Deleted.
(JSC::CodeBlock::appendExceptionHandler): Deleted.
(JSC::CodeBlock::tallyFrequentExitSites): Deleted.
(JSC::CodeBlock::replaceConstant): Deleted.
(JSC::CodeBlock::timeSinceCreation): Deleted.
(JSC::CodeBlock::createRareDataIfNecessary): Deleted.
(JSC::GlobalCodeBlock::GlobalCodeBlock): Deleted.
(JSC::ProgramCodeBlock::create): Deleted.
(JSC::ProgramCodeBlock::createStructure): Deleted.
(JSC::ProgramCodeBlock::ProgramCodeBlock): Deleted.
(JSC::ModuleProgramCodeBlock::create): Deleted.
(JSC::ModuleProgramCodeBlock::createStructure): Deleted.
(JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock): Deleted.
(JSC::EvalCodeBlock::create): Deleted.
(JSC::EvalCodeBlock::createStructure): Deleted.
(JSC::EvalCodeBlock::variable): Deleted.
(JSC::EvalCodeBlock::numVariables): Deleted.
(JSC::EvalCodeBlock::EvalCodeBlock): Deleted.
(JSC::EvalCodeBlock::unlinkedEvalCodeBlock): Deleted.
(JSC::FunctionCodeBlock::create): Deleted.
(JSC::FunctionCodeBlock::createStructure): Deleted.
(JSC::FunctionCodeBlock::FunctionCodeBlock): Deleted.
(JSC::ExecState::r): Deleted.
(JSC::ExecState::uncheckedR): Deleted.
(JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
(JSC::ScriptExecutable::forEachCodeBlock): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* dfg/DFGByteCodeParser.cpp:
* interpreter/Interpreter.cpp:
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/CommonSlowPaths.h:
* runtime/EvalExecutable.cpp:
* runtime/ExecutableBase.cpp:
* runtime/FunctionExecutable.cpp:
* runtime/FunctionExecutableDump.cpp:
* runtime/ModuleProgramExecutable.cpp:
* runtime/ProgramExecutable.cpp:
* runtime/ScriptExecutable.cpp:
* runtime/ScriptExecutable.h:
* runtime/TestRunnerUtils.cpp:
* runtime/VM.cpp:
* runtime/WebAssemblyExecutable.cpp:
* tools/JSDollarVMPrototype.cpp:
2016-11-01 Sam Weinig <sam@webkit.org>
[WebIDL] Move interfaces and typed arrays over to JSDOMConvert
https://bugs.webkit.org/show_bug.cgi?id=164256
Reviewed by Alex Christensen.
* runtime/JSArrayBuffer.h:
(JSC::JSArrayBuffer::toWrapped):
Change return type to ArrayBuffer* to match WebCore's expectation.
2016-11-02 Filip Pizlo <fpizlo@apple.com>
The GC should be in a thread
https://bugs.webkit.org/show_bug.cgi?id=163562
Reviewed by Geoffrey Garen and Andreas Kling.
In a concurrent GC, the work of collecting happens on a separate thread. This patch
implements this, and schedules the thread the way that a concurrent GC thread would be
scheduled. But, the GC isn't actually concurrent yet because it calls stopTheWorld() before
doing anything and calls resumeTheWorld() after it's done with everything. The next step will
be to make it really concurrent by basically calling stopTheWorld()/resumeTheWorld() around
bounded snippets of work while making most of the work happen with the world running. Our GC
will probably always have stop-the-world phases because the semantics of JSC weak references
call for it.
This implements concurrent GC scheduling. This means that there is no longer a
Heap::collect() API. Instead, you can call collectAsync() which makes sure that a GC is
scheduled (it will do nothing if one is scheduled or ongoing) or you can call collectSync()
to schedule a GC and wait for it to happen. I made our debugging stuff call collectSync().
It should be a goal to never call collectSync() except for debugging or benchmark harness
hacks.
The collector thread is an AutomaticThread, so it won't linger when not in use. It works on
a ticket-based system, like you would see at the DMV. A ticket is a 64-bit integer. There are
two ticket counters: last granted and last served. When you request a collection, last
granted is incremented and its new value given to you. When a collection completes, last
served is incremented. collectSync() waits until last served catches up to what last granted
had been at the time you requested a GC. This means that if you request a sync GC in the
middle of an async GC, you will wait for that async GC to finish and then you will request
and wait for your sync GC.
The synchronization between the collector thread and the main threads is complex. The
collector thread needs to be able to ask the main thread to stop. It needs to be able to do
some post-GC clean-up, like the synchronous CodeBlock and LargeAllocation sweeps, on the main
thread. The collector needs to be able to ask the main thread to execute a cross-modifying
code fence before running any JIT code, since the GC might aid the JIT worklist and run JIT
finalization. It's possible for the GC to want the main thread to run something at the same
time that the main thread wants to wait for the GC. The main thread needs to be able to run
non-JSC stuff without causing the GC to completely stall. The main thread needs to be able
to query its own state (is there a request to stop?) and change it (running JSC versus not)
quickly, since this may happen on hot paths. This kind of intertwined system of requests,
notifications, and state changes requires a combination of lock-free algorithms and waiting.
So, this is all implemented using a Atomic<unsigned> Heap::m_worldState, which has bits to
represent things being requested by the collector and the heap access state of the mutator. I
am borrowing a lot of terms that I've seen in other VMs that I've worked on. Here's what they
mean:
- Stop the world: make sure that either the mutator is not running, or that it's not running
code that could mess with the heap.
- Heap access: the mutator is said to have heap access if it could mess with the heap.
If you stop the world and the mutator doesn't have heap access, all you're doing is making
sure that it will block when it tries to acquire heap access. This means that our GC is
already fully concurrent in cases where the GC is requested while the mutator has no heap
access. This probably won't happen, but if it did then it should just work. Usually, stopping
the world means that we state our shouldStop request with m_worldState, and a future call
to Heap::stopIfNecessary() will go to slow path and stop. The act of stopping or waiting to
acquire heap access is managed by using ParkingLot API directly on m_worldState. This works
out great because it would be very awkward to get the same functionality using locks and
condition variables, since we want stopIfNecessary/acquireAccess/requestAccess fast paths
that are single atomic instructions (load/CAS/CAS, respectively). The mutator will call these
things frequently. Currently we have Heap::stopIfNecessary() polling on every allocator slow
path, but we may want to make it even more frequent than that.
Currently only JSC API clients benefit from the heap access optimization. The DOM forces us
to assume that heap access is permanently on, since DOM manipulation doesn't always hold the
JSLock. We could still allow the GC to proceed when the runloop is idle by having the GC put
a task on the runloop that just calls stopIfNecessary().
This is perf neutral. The only behavior change that clients ought to observe is that marking
and the weak fixpoint happen on a separate thread. Marking was already parallel so it already
handled multiple threads, but now it _never_ runs on the main thread. The weak fixpoint
needed some help to be able to run on another thread - mostly because there was some code in
IndexedDB that was using thread specifics in the weak fixpoint.
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::Thread::Thread):
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::gatherStackRoots):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::shouldCollectInThread):
(JSC::Heap::collectInThread):
(JSC::Heap::stopTheWorld):
(JSC::Heap::resumeTheWorld):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::acquireAccessSlow):
(JSC::Heap::releaseAccessSlow):
(JSC::Heap::handleDidJIT):
(JSC::Heap::handleNeedFinalize):
(JSC::Heap::setDidJIT):
(JSC::Heap::setNeedFinalize):
(JSC::Heap::waitWhileNeedFinalize):
(JSC::Heap::finalize):
(JSC::Heap::requestCollection):
(JSC::Heap::waitForCollection):
(JSC::Heap::didFinishCollection):
(JSC::Heap::canCollect):
(JSC::Heap::shouldCollectHeuristic):
(JSC::Heap::shouldCollect):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::collect): Deleted.
(JSC::Heap::collectWithoutAnySweep): Deleted.
(JSC::Heap::collectImpl): Deleted.
* heap/Heap.h:
(JSC::Heap::ReleaseAccessScope::ReleaseAccessScope):
(JSC::Heap::ReleaseAccessScope::~ReleaseAccessScope):
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::releaseAccess):
(JSC::Heap::stopIfNecessary):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::gatherConservativeRoots):
(JSC::MachineThreads::gatherFromCurrentThread): Deleted.
* heap/MachineStackMarker.h:
* jit/JITWorklist.cpp:
(JSC::JITWorklist::completeAllForVM):
* jit/JITWorklist.h:
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::unlock):
(JSC::JSLock::willReleaseLock):
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
2016-11-02 Michael Saboff <msaboff@apple.com>
Crash beneath SlotVisitor::drain @ cooksillustrated.com
https://bugs.webkit.org/show_bug.cgi?id=164304
Reviewed by Mark Lam.
Added back write barrier for the base cell of put-by_id in the LLInt when the structure is
changed. Also removed the unused macro "storeStructureWithTypeInfo".
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2016-11-02 Keith Miller <keith_miller@apple.com>
We should not pop from an empty stack in the Wasm function parser.
https://bugs.webkit.org/show_bug.cgi?id=164275
Reviewed by Filip Pizlo.
This patch prevents an issue in the wasm parser where we might
accidentially pop from the expression stack without if there
are no entries. It also fixes a similar issue with else
blocks where a user might try to put an else on the top level
of a function.
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::popExpressionStack):
* wasm/WasmValidate.cpp:
(JSC::Wasm::Validate::setErrorMessage):
2016-11-02 Romain Bellessort <romain.bellessort@crf.canon.fr>
[Readable Streams API] Enable creation of ReadableByteStreamController
https://bugs.webkit.org/show_bug.cgi?id=164014
Reviewed by Youenn Fablet.
Added flag for the byte stream part of Readable Streams API.
* Configurations/FeatureDefines.xcconfig:
2016-11-02 Per Arne Vollan <pvollan@apple.com>
[Win] Copy build results to AAS 'Program Files' folder.
https://bugs.webkit.org/show_bug.cgi?id=164273
Reviewed by Brent Fulgham.
The preferred location for the binaries is the AAS 'Program Files' folder.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2016-11-01 Ryosuke Niwa <rniwa@webkit.org>
Remove CUSTOM_ELEMENTS build flag
https://bugs.webkit.org/show_bug.cgi?id=164267
Reviewed by Antti Koivisto.
Removed the build flag.
* Configurations/FeatureDefines.xcconfig:
2016-11-01 Keith Miller <keith_miller@apple.com>
Add a WASM function validator.
https://bugs.webkit.org/show_bug.cgi?id=161707
Reviewed by Saam Barati.
This is a new template specialization of the Wasm FunctionParser class. Instead of having
the FunctionParser track what B3 values each stack entry refers to the validator has each
entry refer to the type of the stack entry. Additionally, the control stack tracks what type
of block the object is and what the result type of the block is. The validation functions
for unary, binary, and memory operations are autogenerated by the
generateWasmValidateInlinesHeader.py script.
There are still a couple issue with validating that will be addressed in follow-up patches.
1) We need to handle result types from basic blocks. https://bugs.webkit.org/show_bug.cgi?id=164100
2) We need to handle popping things from stacks when they don't exist. https://bugs.webkit.org/show_bug.cgi?id=164275
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* testWasm.cpp:
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmFormat.cpp: Added.
(JSC::Wasm::toString):
* wasm/WasmFormat.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
* wasm/WasmValidate.cpp: Added.
(JSC::Wasm::Validate::ControlData::ControlData):
(JSC::Wasm::Validate::ControlData::dump):
(JSC::Wasm::Validate::ControlData::type):
(JSC::Wasm::Validate::ControlData::signature):
(JSC::Wasm::Validate::addConstant):
(JSC::Wasm::Validate::isContinuationReachable):
(JSC::Wasm::Validate::errorMessage):
(JSC::Wasm::Validate::Validate):
(JSC::Wasm::Validate::addArguments):
(JSC::Wasm::Validate::addLocal):
(JSC::Wasm::Validate::getLocal):
(JSC::Wasm::Validate::setLocal):
(JSC::Wasm::Validate::addBlock):
(JSC::Wasm::Validate::addLoop):
(JSC::Wasm::Validate::addIf):
(JSC::Wasm::Validate::addElse):
(JSC::Wasm::Validate::addReturn):
(JSC::Wasm::Validate::addBranch):
(JSC::Wasm::Validate::endBlock):
(JSC::Wasm::Validate::addCall):
(JSC::Wasm::Validate::unify):
(JSC::Wasm::Validate::dump):
(JSC::Wasm::validateFunction):
* wasm/WasmValidate.h: Added.
* wasm/generateWasmValidateInlinesHeader.py: Added.
(cppType):
(toCpp):
(unaryMacro):
(binaryMacro):
(loadMacro):
(storeMacro):
2016-11-01 Saam Barati <sbarati@apple.com>
We should be able to eliminate rest parameter allocations
https://bugs.webkit.org/show_bug.cgi?id=163925
Reviewed by Filip Pizlo.
This is the first step towards eliminating rest parameter
allocations when they're spread to other function calls:
`function foo(...args) { bar(...args); }`
This patch simply removes the allocation for rest parameter
allocations using the same escape analysis that is performed
in the argument elimination phase. I've added a new rule to
the phase to make sure that CheckStructure doesn't count as
an escape for an allocation since this often shows up in code
like this:
```
function foo(...args) {
let r = [];
for (let i = 0; i < args.length; i++)
r.push(args[i]);
return r;
}
```
The above program now entirely eliminates the allocation for args
compiled in the FTL. Programs like this also eliminate the allocation
for args:
```
function foo(...args) { return [args.length, args[0]]; }
function bar(...args) { return someOtherFunction.apply(null, args); }
```
This patch extends the arguments elimination phase to understand
the concept that we may want to forward arguments, or get from
the arguments region, starting at some offset. The offset is the
number of names parameter before the rest parameter. For example:
```
function foo(a, b, ...args) { return bar.apply(null, args); }
```
Will forward arguments starting at the *third* argument.
Our arguments forwarding code already had the notion of starting
from some offset, however, I found bugs in that code. I extended
it to work properly for rest parameters with arbitrary skip offsets.
And this program:
```
function foo(...args) {
let r = [];
for (let i = 0; i < args.length; i++)
r.push(args[i]);
return r;
}
```
Knows to perform the GetMyArgumentByVal* with an offset of 3
inside the loop. To make this work, I taught GetMyArgumentByVal
and GetMyArgumentByValOutOfBounds to take an offset representing
the number of arguments to skip.
This patch is a ~20% speedup on microbenchmarks.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGArgumentsUtilities.cpp:
(JSC::DFG::emitCodeToGetArgumentsArrayLength):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasConstant):
(JSC::DFG::Node::constant):
(JSC::DFG::Node::isPhantomAllocation):
(JSC::DFG::Node::numberOfArgumentsToSkip):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOperations.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateRest):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetVarargsFrame):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::restParameterStructure):
2016-11-01 Geoffrey Garen <ggaren@apple.com>
Lots of stderr logging in JSManagedValue
https://bugs.webkit.org/show_bug.cgi?id=164279
<rdar://problem/28949886>
Reviewed by Filip Pizlo.
Revert an accidental change in <https://trac.webkit.org/changeset/205462>.
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
2016-11-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r208208 and r208210.
https://bugs.webkit.org/show_bug.cgi?id=164276
This change caused 28 JSC test failures. (Requested by
ryanhaddad on #webkit).
Reverted changesets:
"We should be able to eliminate rest parameter allocations"
https://bugs.webkit.org/show_bug.cgi?id=163925
http://trac.webkit.org/changeset/208208
"Fix the EFL build."
http://trac.webkit.org/changeset/208210
2016-11-01 Ryosuke Niwa <rniwa@webkit.org>
Web Inspector: Add the support for custom elements
https://bugs.webkit.org/show_bug.cgi?id=164266
<rdar://problem/29038883>
Reviewed by Joseph Pecoraro.
Added customElementState of type CustomElementState to reflect the custom element state on each DOM node
along with customElementStateChanged which fires when the custom element state changes.
* inspector/protocol/DOM.json:
2016-10-31 Simon Fraser <simon.fraser@apple.com>
Fix the EFL build.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):
2016-10-29 Filip Pizlo <fpizlo@apple.com>
JSC should support SharedArrayBuffer
https://bugs.webkit.org/show_bug.cgi?id=163986
Reviewed by Keith Miller.
This implements https://tc39.github.io/ecmascript_sharedmem/shmem.html.
There is now a new SharedArrayBuffer type. In the JS runtime, which includes typed array
types, the SharedArrayBuffer is a drop-in replacement for ArrayBuffer, even though they are
distinct types (new SharedArrayBuffer() instanceof ArrayBuffer == false and vice versa). The
DOM will not recognize SharedArrayBuffer, or any typed array that wraps it, to ensure safety.
This matches what other browsers intend to do, see
https://github.com/tc39/ecmascript_sharedmem/issues/38. API is provided for the DOM to opt
into SharedArrayBuffer. One notable place is postMessage, which will share the
SharedArrayBuffer's underlying data storage with other workers. This creates a pool of shared
memory that the workers can use to talk to each other.
There is also an Atomics object in global scope, which exposes sequentially consistent atomic
operations: add, and, compareExchange, exchange, load, or, store, sub, and xor. Additionally
it exposes a Atomics.isLockFree utility, which takes a byte amount and returns true or false.
Also there is Atomics.wake/wait, which neatly map to ParkingLot.
Accesses to typed arrays that wrap SharedArrayBuffer are optimized by JSC the same way as
always. I believe that DFG and B3 already obey the following memory model, which I believe is
a bit weaker than Cambridge and a bit stronger than what is being proposed for
SharedArrayBuffer. To predict a program's behavior under the B3 memory model, imagine the
space of all possible programs that would result from running an optimizer that adversarially
follows B3's transformation rules. B3 transformations are correct if the newly created
program is equivalent to the old one, assuming that any opaque effect in IR (like the reads
and writes of a patchpoint/call/fence) could perform any load/store that satisfies the
B3::Effects summary. Opaque effects are a way of describing an infinite set of programs: any
program that only does the effects summarized in B3::Effects belongs to the set. For example,
this prevents motion of operations across fences since fences are summarized as opaque
effects that could read or write memory. This rule alone is not enough, because it leaves the
door open for turning an atomic operation (like a load) into a non-atomic one (like a load
followed by a store of the same value back to the same location or multiple loads). This is
not an optimization that either our compiler or the CPU would want to do. One way to think of
what exactly is forbidden is that B3 transformations that mess with memory accesses can only
reorder them or remove them. This means that for any execution of the untransformed program,
the corresponding execution of the transformed program (i.e. with the same input arguments
and the same programs filled in for the opaque effects) must have the same loads and stores,
with some removed and some reordered. This is a fairly simple mental model that B3 and DFG
already follow and it's based on existing abstractions for the infinite set of programs
inside an opaque effect (DFG's AbstractHeaps and B3's Effects).
This patch makes all atomics operations intrinsic, but the DFG doesn't know about any of them
yet. That's covered by bug 164108.
This ought to be perf-neutral, but I am still running tests to confirm this. I'm also still
writing new tests to cover all of the Atomics functionality and the behavior of SAB objects.
* API/JSTypedArray.cpp:
(JSObjectGetTypedArrayBytesPtr):
(JSObjectGetTypedArrayBuffer):
(JSObjectMakeArrayBufferWithBytesNoCopy):
* API/tests/CompareAndSwapTest.cpp:
(Bitmap::concurrentTestAndSet):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
* heap/Heap.cpp:
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
* jsc.cpp:
(functionTransferArrayBuffer):
* runtime/ArrayBuffer.cpp:
(JSC::SharedArrayBufferContents::SharedArrayBufferContents):
(JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
(JSC::ArrayBufferContents::ArrayBufferContents):
(JSC::ArrayBufferContents::operator=):
(JSC::ArrayBufferContents::~ArrayBufferContents):
(JSC::ArrayBufferContents::clear):
(JSC::ArrayBufferContents::destroy):
(JSC::ArrayBufferContents::reset):
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBufferContents::makeShared):
(JSC::ArrayBufferContents::transferTo):
(JSC::ArrayBufferContents::copyTo):
(JSC::ArrayBufferContents::shareWith):
(JSC::ArrayBuffer::create):
(JSC::ArrayBuffer::createAdopted):
(JSC::ArrayBuffer::createFromBytes):
(JSC::ArrayBuffer::tryCreate):
(JSC::ArrayBuffer::createUninitialized):
(JSC::ArrayBuffer::tryCreateUninitialized):
(JSC::ArrayBuffer::createInternal):
(JSC::ArrayBuffer::ArrayBuffer):
(JSC::ArrayBuffer::slice):
(JSC::ArrayBuffer::sliceImpl):
(JSC::ArrayBuffer::makeShared):
(JSC::ArrayBuffer::setSharingMode):
(JSC::ArrayBuffer::transferTo):
(JSC::ArrayBuffer::transfer): Deleted.
* runtime/ArrayBuffer.h:
(JSC::arrayBufferSharingModeName):
(JSC::SharedArrayBufferContents::data):
(JSC::ArrayBufferContents::data):
(JSC::ArrayBufferContents::sizeInBytes):
(JSC::ArrayBufferContents::isShared):
(JSC::ArrayBuffer::sharingMode):
(JSC::ArrayBuffer::isShared):
(JSC::ArrayBuffer::gcSizeEstimateInBytes):
(JSC::arrayBufferDestructorNull): Deleted.
(JSC::arrayBufferDestructorDefault): Deleted.
(JSC::ArrayBufferContents::ArrayBufferContents): Deleted.
(JSC::ArrayBufferContents::transfer): Deleted.
(JSC::ArrayBufferContents::copyTo): Deleted.
(JSC::ArrayBuffer::create): Deleted.
(JSC::ArrayBuffer::createAdopted): Deleted.
(JSC::ArrayBuffer::createFromBytes): Deleted.
(JSC::ArrayBuffer::tryCreate): Deleted.
(JSC::ArrayBuffer::createUninitialized): Deleted.
(JSC::ArrayBuffer::tryCreateUninitialized): Deleted.
(JSC::ArrayBuffer::createInternal): Deleted.
(JSC::ArrayBuffer::ArrayBuffer): Deleted.
(JSC::ArrayBuffer::slice): Deleted.
(JSC::ArrayBuffer::sliceImpl): Deleted.
(JSC::ArrayBufferContents::tryAllocate): Deleted.
(JSC::ArrayBufferContents::~ArrayBufferContents): Deleted.
* runtime/ArrayBufferSharingMode.h: Added.
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::possiblySharedBuffer):
(JSC::ArrayBufferView::unsharedBuffer):
(JSC::ArrayBufferView::isShared):
(JSC::ArrayBufferView::buffer): Deleted.
* runtime/AtomicsObject.cpp: Added.
(JSC::AtomicsObject::AtomicsObject):
(JSC::AtomicsObject::create):
(JSC::AtomicsObject::createStructure):
(JSC::AtomicsObject::finishCreation):
(JSC::atomicsFuncAdd):
(JSC::atomicsFuncAnd):
(JSC::atomicsFuncCompareExchange):
(JSC::atomicsFuncExchange):
(JSC::atomicsFuncIsLockFree):
(JSC::atomicsFuncLoad):
(JSC::atomicsFuncOr):
(JSC::atomicsFuncStore):
(JSC::atomicsFuncSub):
(JSC::atomicsFuncWait):
(JSC::atomicsFuncWake):
(JSC::atomicsFuncXor):
* runtime/AtomicsObject.h: Added.
* runtime/CommonIdentifiers.h:
* runtime/DataView.cpp:
(JSC::DataView::wrap):
* runtime/GenericTypedArrayViewInlines.h:
(JSC::GenericTypedArrayView<Adaptor>::subarray):
* runtime/Intrinsic.h:
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::finishCreation):
(JSC::JSArrayBuffer::isShared):
(JSC::JSArrayBuffer::sharingMode):
* runtime/JSArrayBuffer.h:
(JSC::toPossiblySharedArrayBuffer):
(JSC::toUnsharedArrayBuffer):
(JSC::JSArrayBuffer::toWrapped):
(JSC::toArrayBuffer): Deleted.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSArrayBufferConstructor::JSArrayBufferConstructor):
(JSC::JSArrayBufferConstructor::finishCreation):
(JSC::JSArrayBufferConstructor::create):
(JSC::constructArrayBuffer):
* runtime/JSArrayBufferConstructor.h:
(JSC::JSArrayBufferConstructor::sharingMode):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
(JSC::JSArrayBufferPrototype::JSArrayBufferPrototype):
(JSC::JSArrayBufferPrototype::finishCreation):
(JSC::JSArrayBufferPrototype::create):
* runtime/JSArrayBufferPrototype.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::finishCreation):
(JSC::JSArrayBufferView::visitChildren):
(JSC::JSArrayBufferView::unsharedBuffer):
(JSC::JSArrayBufferView::unsharedJSBuffer):
(JSC::JSArrayBufferView::possiblySharedJSBuffer):
(JSC::JSArrayBufferView::neuter):
(JSC::JSArrayBufferView::toWrapped): Deleted.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::jsBuffer): Deleted.
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::isShared):
(JSC::JSArrayBufferView::possiblySharedBuffer):
(JSC::JSArrayBufferView::possiblySharedImpl):
(JSC::JSArrayBufferView::unsharedImpl):
(JSC::JSArrayBufferView::byteOffset):
(JSC::JSArrayBufferView::toWrapped):
(JSC::JSArrayBufferView::buffer): Deleted.
(JSC::JSArrayBufferView::impl): Deleted.
(JSC::JSArrayBufferView::neuter): Deleted.
* runtime/JSDataView.cpp:
(JSC::JSDataView::possiblySharedTypedImpl):
(JSC::JSDataView::unsharedTypedImpl):
(JSC::JSDataView::getTypedArrayImpl):
(JSC::JSDataView::typedImpl): Deleted.
* runtime/JSDataView.h:
(JSC::JSDataView::possiblySharedBuffer):
(JSC::JSDataView::unsharedBuffer):
(JSC::JSDataView::buffer): Deleted.
* runtime/JSDataViewPrototype.cpp:
(JSC::dataViewProtoGetterBuffer):
* runtime/JSGenericTypedArrayView.h:
(JSC::toPossiblySharedNativeTypedView):
(JSC::toUnsharedNativeTypedView):
(JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
(JSC::JSGenericTypedArrayView::typedImpl): Deleted.
(JSC::toNativeTypedView): Deleted.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::create):
(JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::getTypedArrayImpl):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoGetterFuncBuffer):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::createAtomicsProperty):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayBufferPrototype):
(JSC::JSGlobalObject::arrayBufferStructure):
* runtime/MathObject.cpp:
* runtime/RuntimeFlags.h:
* runtime/SimpleTypedArrayController.cpp:
(JSC::SimpleTypedArrayController::toJS):
* runtime/TypedArrayType.h:
(JSC::typedArrayTypeForType):
2016-10-31 Saam Barati <sbarati@apple.com>
We should be able to eliminate rest parameter allocations
https://bugs.webkit.org/show_bug.cgi?id=163925
Reviewed by Filip Pizlo.
This is the first step towards eliminating rest parameter
allocations when they're spread to other function calls:
`function foo(...args) { bar(...args); }`
This patch simply removes the allocation for rest parameter
allocations using the same escape analysis that is performed
in the argument elimination phase. I've added a new rule to
the phase to make sure that CheckStructure doesn't count as
an escape for an allocation since this often shows up in code
like this:
```
function foo(...args) {
let r = [];
for (let i = 0; i < args.length; i++)
r.push(args[i]);
return r;
}
```
The above program now entirely eliminates the allocation for args
compiled in the FTL. Programs like this also eliminate the allocation
for args:
```
function foo(...args) { return [args.length, args[0]]; }
function bar(...args) { return someOtherFunction.apply(null, args); }
```
This patch extends the arguments elimination phase to understand
the concept that we may want to forward arguments, or get from
the arguments region, starting at some offset. The offset is the
number of names parameter before the rest parameter. For example:
```
function foo(a, b, ...args) { return bar.apply(null, args); }
```
Will forward arguments starting at the *third* argument.
Our arguments forwarding code already had the notion of starting
from some offset, however, I found bugs in that code. I extended
it to work properly for rest parameters with arbitrary skip offsets.
And this program:
```
function foo(...args) {
let r = [];
for (let i = 0; i < args.length; i++)
r.push(args[i]);
return r;
}
```
Knows to perform the GetMyArgumentByVal* with an offset of 3
inside the loop. To make this work, I taught GetMyArgumentByVal
and GetMyArgumentByValOutOfBounds to take an offset representing
the number of arguments to skip.
This patch is a ~20% speedup on microbenchmarks.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGArgumentsUtilities.cpp:
(JSC::DFG::emitCodeToGetArgumentsArrayLength):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasConstant):
(JSC::DFG::Node::constant):
(JSC::DFG::Node::isPhantomAllocation):
(JSC::DFG::Node::numberOfArgumentsToSkip):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOperations.cpp:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCreateRest):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureRegistrationPhase.cpp:
(JSC::DFG::StructureRegistrationPhase::run):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetVarargsFrame):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::restParameterStructure):
2016-10-31 Mark Lam <mark.lam@apple.com>
Add $vm.codeBlockFor() debugging utility.
https://bugs.webkit.org/show_bug.cgi?id=164192
Reviewed by Saam Barati.
Sometimes, while debugging, it would be nice if we can get the codeBlock info for
a function. Amongst other uses, this is useful for checking what optimization
level the function is currently at. With $vm.codeBlockFor(), we can now do this.
For example, when JS_useDollarVM=true:
print("test's codeBlock = " + $vm.codeBlockFor(test)); // prints function test's codeBlock.
Also added some comments to clarify some pre-existing code.
* tools/JSDollarVMPrototype.cpp:
(JSC::functionCodeBlockForFrame):
(JSC::codeBlockFromArg):
(JSC::functionCodeBlockFor):
(JSC::JSDollarVMPrototype::finishCreation):
2016-10-31 Saam Barati <sbarati@apple.com>
GetByOffset rule is has incorrect assumptions inside arguments elimination phase
https://bugs.webkit.org/show_bug.cgi?id=164239
<rdar://problem/29032041>
Reviewed by Keith Miller.
The rule for GetByOffset assumes that a child will always be transformed before
the user of a child is by assuming its child will already be a phantom allocation.
This will almost certainly be true because of how we generate bytecode for
arguments allocation and how traversal of the graph works using blocksInNaturalOrder.
However, there is no guarantee that blocksInNaturalOrder must first traverse a
block's dominator before the block being dominated. Since it's unlikely that this
bug will ever be seen by real code, this fix is mostly for maintaining good hygiene.
* dfg/DFGArgumentsEliminationPhase.cpp:
2016-10-31 Simon Fraser <simon.fraser@apple.com>
Implement IntersectionObserver
https://bugs.webkit.org/show_bug.cgi?id=159475
Reviewed by Ryosuke Niwa.
Add ENABLE_INTERSECTION_OBSERVER, enabled by default.
* Configurations/FeatureDefines.xcconfig:
2016-10-31 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Provide an opportunity to clear ScriptValues associated with debugged target
https://bugs.webkit.org/show_bug.cgi?id=164167
<rdar://problem/29010148>
Reviewed by Mark Lam.
* inspector/InspectorAgentBase.h:
(Inspector::InspectorAgentBase::discardValues):
* inspector/InspectorAgentRegistry.cpp:
(Inspector::AgentRegistry::~AgentRegistry):
(Inspector::AgentRegistry::discardValues):
* inspector/InspectorAgentRegistry.h:
New standard agent method to allow the agent to discard values.
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::discardValues):
Discard ScriptValues in ConsoleMessages.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
Global object is going away, discard values.
2016-10-31 Keith Miller <keith_miller@apple.com>
autogenerated files from wasm.json should be in derived sources.
https://bugs.webkit.org/show_bug.cgi?id=164152
Reviewed by Filip Pizlo.
Add two new python scripts to the build. These scripts do what the
old js script in JSTests did. Previously, changes to wasm.json needed
to be manually reflected in WasmOps.h. This patch will auto-build from
the json file. That system was unsustainable, especially as future patches
will likely add more autogenerated files. The generated header files are
identical other than the comment at the top and the order of the opcodes.
I believe ordering difference just has to do with the iteration order for
sets.
* DerivedSources.make:
* wasm/WasmOps.h: Removed.
* wasm/generateWasm.py: Added.
(Wasm):
(Wasm.__init__):
(opcodeIterator):
(toCpp):
(isNormal):
(isUnary):
(isBinary):
* wasm/generateWasmOpsHeader.py: Added.
(cppMacro):
(opcodeMacroizer):
(ceilDiv):
(bitSet):
(BinaryOpType):
(UnaryOpType):
(LoadOpType):
(StoreOpType):
* wasm/wasm.json: Added.
2016-10-29 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] JSON.stringify should handle Proxy which is non JSArray but isArray is true
https://bugs.webkit.org/show_bug.cgi?id=164123
Reviewed by Mark Lam.
When JSON.stringify encounter the undefined value, the result depends
on the context. If it is produced under the object property context, we ignore
that property. On the other hand, if it is produced under the array element
context, we produce "null".
For example,
// https://tc39.github.io/ecma262/#sec-serializejsonobject section 8.b.
// Skip the property that value is undefined.
JSON.stringify({ value: undefined }); // => "{}"
// https://tc39.github.io/ecma262/#sec-serializejsonarray section 8.b.
// Write "null" when the element is undefined.
JSON.stringify([undefined]); // => "[null]"
At that time, we decide the context based on the `holder->inherits(JSArray::info())`.
But it is not correct since we have a holder that creates the array element context
but it is not JSArray subtype. ES6 Proxy to an array is one example. In that case,
`isArray(exec, proxy)` returns `true`, but `inherits(JSArray::info())` returns false.
Since we already have this `isArray()` value in Stringifier::Holder, we should reuse
this here. And this is the correct behavior in the ES6 spec.
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::isArray):
(JSC::Stringifier::stringify):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::Holder):
(JSC::Stringifier::Holder::appendNextProperty):
2016-10-29 Saam Barati <sbarati@apple.com>
We should have a way of profiling when a get_by_id is pure and to emit a PureGetById in the DFG/FTL
https://bugs.webkit.org/show_bug.cgi?id=163305
Reviewed by Keith Miller.
This creates a new GetById node in the DFG called PureGetById. We emit a
PureGetById when we profile that a get_by_id in the baseline never does
side effects. PureGetById speculates on the fact that it won't do side
effects. If it realizes that it must perform side effects, it will perform
the side effect, but also invalidate the CodeBlock that compiled it,
which will cause us to exit once we return back to the compiled code.
This allows us to have stricter clobberize rules for PureGetById which
model how getOwnPropertySlot(VMInquiry) behaves. This means that PureGetByIds
can be CSEd with each other, and that other things are more likely to
be CSEd around a PureGetById. To profile if a get_by_id does side
effects, I've added an extra bit into StructureStubInfo that we write
to when performing a get_by_id slow path call. If we notice that we
never do effects, inside the ByteCodeParser, we will emit a PureGetById
instead of a GetById.
To justify the performance benefit of this patch, I ran the suite of
benchmarks with useAccessInlining=false. This meant that we don't compile
any (Multi)GetByOffset/(Multi)PutByOffset. This was just to try to see if
this patch is worth anything at all in a world where we emit many
PureGetByIds. Running the benchmarks under this mode showed a 3.5% octane
improvement and a 15% kraken improvement. However, when running benchmarks
with useAccessInlining=true (the default JSC state), this patch is neutral.
I think the main reason for this is that the DFG is good at knowing when to
emit (Multi)GetByOffset, and most benchmarks that would benefit from
PureGetById are already emitting (Multi)GetByOffset. However, PureGetById can be
profitable when we encounter code that is too polymorphic for (Multi)GetByOffset.
It's reasonable to expect that JS code in the wild will fall into this use
case even though it might not be represented in some of the major JS benchmarks.
I wrote some microbenchmarks to demonstrate the benefits of PureGetById CSE,
and they were 30% (eliminating a few PureGetById from an add expression)
to 10x faster (eliminating a PureGetById in a loop).
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::StructureStubInfo):
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::canBecomeGetArrayLength):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToGetByOffset):
(JSC::DFG::Node::convertToMultiGetByOffset):
(JSC::DFG::Node::hasIdentifier):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTryGetById):
(JSC::DFG::SpeculativeJIT::compilePureGetById):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetById):
(JSC::FTL::DFG::LowerDFGToB3::getById):
* jit/JITOperations.cpp:
(JSC::pureGetByIdCommon):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_try_get_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_try_get_by_id):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByIdFunction):
(JSC::appropriateGenericGetByIdFunction):
(JSC::tryCacheGetByID):
* jit/Repatch.h:
* profiler/ProfilerJettisonReason.cpp:
(WTF::printInternal):
* profiler/ProfilerJettisonReason.h:
2016-10-28 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Breakpoints not working in scripts with unicode characters
https://bugs.webkit.org/show_bug.cgi?id=164172
<rdar://problem/28895862>
Reviewed by Ryosuke Niwa.
* parser/Parser.h:
(JSC::parse):
Ensure we pass the debuggerParseData struct to get populated in the
non 8bit string case!
2016-10-28 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Include identifier name in CallDOMGetter to dump it
https://bugs.webkit.org/show_bug.cgi?id=164161
Reviewed by Mark Lam.
This patch adds an identifier number to CallDOMGetterData and use it when dumping the data.
CallDOMGetter did not include identifier. It made CallDOMGetter super hard to debug when dumping DFG graph.
The dump becomes like this.
CallDOMGetter(Cell:@21, JS|MustGen|UseAsOther, Nonboolint32, id0{customGetter}, domJIT = 0x42f8a0, R:World, W:Heap, Exits, ClobbersExit, bc#15) predicting Nonboolint32
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleGetById):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNode.h:
2016-10-28 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Rename CallDOM to CallDOMGetter
https://bugs.webkit.org/show_bug.cgi?id=164157
Reviewed by Keith Miller.
Rename CallDOM to CallDOMGetter to represent that
this is used for DOMJIT getter explicitly.
CallDOM will be used for DOM functions (like element.getAttribute()) later.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::blessCallDOMGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::blessCallDOM): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasCallDOMGetterData):
(JSC::DFG::Node::callDOMGetterData):
(JSC::DFG::Node::hasCallDOMData): Deleted.
(JSC::DFG::Node::callDOMData): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
(JSC::DFG::SpeculativeJIT::compileCallDOM): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* domjit/DOMJITCallDOMGetterPatchpoint.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::CallDOMGetterPatchpoint::create):
* domjit/DOMJITGetterSetter.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM): Deleted.
* jsc.cpp:
2016-10-28 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix in CLoop builds after r208063.
Include required headers.
* parser/Parser.h:
* runtime/Completion.cpp:
* runtime/JSGlobalObjectFunctions.cpp:
2016-10-28 Ryan Haddad <ryanhaddad@apple.com>
Update reference files for builtins generator tests after r208063.
Unreviewed test gardening.
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2016-10-28 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add wasm/js directory to JSC include directories in CMakeLists.txt
https://bugs.webkit.org/show_bug.cgi?id=164145
Reviewed by Michael Catanzaro.
Attempt to fix CMake ports. We include a file under wasm/js.
But we didn't add it to JSC include directories.
* CMakeLists.txt:
2016-10-27 Geoffrey Garen <ggaren@apple.com>
One file per class for Executable.h/.cpp
https://bugs.webkit.org/show_bug.cgi?id=164099
Reviewed by Saam Barati.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/builtins/builtins_generate_combined_implementation.py:
(BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes):
* Scripts/builtins/builtins_generate_separate_implementation.py:
(BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes):
* builtins/BuiltinExecutables.cpp:
* bytecode/CallVariant.h:
* bytecode/CodeBlock.cpp:
* bytecode/CodeBlock.h:
(JSC::ScriptExecutable::prepareForExecution):
* bytecode/CodeOrigin.cpp:
* bytecode/EvalCodeCache.h:
* bytecode/InlineCallFrame.cpp:
* bytecode/UnlinkedCodeBlock.cpp:
* bytecode/UnlinkedFunctionExecutable.cpp:
* bytecompiler/StaticPropertyAnalysis.h:
* debugger/DebuggerLocation.cpp:
* dfg/DFGCapabilities.h:
* dfg/DFGOSRExitPreparation.cpp:
* dfg/DFGToFTLDeferredCompilationCallback.cpp:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
* interpreter/StackVisitor.cpp:
* jit/JITThunks.cpp:
* jit/JITToDFGDeferredCompilationCallback.cpp:
* jit/SpecializedThunkJIT.h:
* llint/LLIntOffsetsExtractor.cpp:
* parser/Parser.h:
* runtime/CallData.cpp:
* runtime/ConstructData.cpp:
* runtime/EvalExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/EvalExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/Executable.cpp: Removed.
* runtime/Executable.h: Removed.
* runtime/ExecutableBase.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/ExecutableBase.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/FunctionExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/FunctionExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/FunctionExecutableDump.h:
* runtime/JSArray.cpp:
* runtime/JSFunctionInlines.h:
* runtime/JSModuleRecord.cpp:
* runtime/JSObject.cpp:
* runtime/Lookup.cpp:
* runtime/ModuleProgramExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/ModuleProgramExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/NativeExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/NativeExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/ProgramExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/ProgramExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/SamplingProfiler.cpp:
* runtime/ScriptExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::WebAssemblyExecutable::WebAssemblyExecutable): Deleted.
(JSC::WebAssemblyExecutable::destroy): Deleted.
(JSC::WebAssemblyExecutable::visitChildren): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
* runtime/ScriptExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(): Deleted.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
* runtime/StringConstructor.cpp:
* runtime/StringPrototype.cpp:
* runtime/WebAssemblyExecutable.cpp: Copied from Source/JavaScriptCore/runtime/Executable.cpp.
(JSC::ExecutableBase::destroy): Deleted.
(JSC::ExecutableBase::clearCode): Deleted.
(JSC::NativeExecutable::create): Deleted.
(JSC::NativeExecutable::destroy): Deleted.
(JSC::NativeExecutable::createStructure): Deleted.
(JSC::NativeExecutable::finishCreation): Deleted.
(JSC::NativeExecutable::NativeExecutable): Deleted.
(JSC::ScriptExecutable::ScriptExecutable): Deleted.
(JSC::ScriptExecutable::destroy): Deleted.
(JSC::ScriptExecutable::installCode): Deleted.
(JSC::ScriptExecutable::newCodeBlockFor): Deleted.
(JSC::ScriptExecutable::newReplacementCodeBlockFor): Deleted.
(JSC::setupLLInt): Deleted.
(JSC::setupJIT): Deleted.
(JSC::ScriptExecutable::prepareForExecutionImpl): Deleted.
(JSC::EvalExecutable::create): Deleted.
(JSC::EvalExecutable::EvalExecutable): Deleted.
(JSC::EvalExecutable::destroy): Deleted.
(JSC::ProgramExecutable::ProgramExecutable): Deleted.
(JSC::ProgramExecutable::destroy): Deleted.
(JSC::ModuleProgramExecutable::ModuleProgramExecutable): Deleted.
(JSC::ModuleProgramExecutable::create): Deleted.
(JSC::ModuleProgramExecutable::destroy): Deleted.
(JSC::FunctionExecutable::FunctionExecutable): Deleted.
(JSC::FunctionExecutable::finishCreation): Deleted.
(JSC::FunctionExecutable::destroy): Deleted.
(JSC::samplingDescription): Deleted.
(JSC::EvalExecutable::visitChildren): Deleted.
(JSC::ProgramExecutable::checkSyntax): Deleted.
(JSC::ProgramExecutable::initializeGlobalProperties): Deleted.
(JSC::ProgramExecutable::visitChildren): Deleted.
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::baselineCodeBlockFor): Deleted.
(JSC::FunctionExecutable::visitChildren): Deleted.
(JSC::FunctionExecutable::fromGlobalCode): Deleted.
(JSC::ExecutableBase::dump): Deleted.
(JSC::ExecutableBase::hashFor): Deleted.
(JSC::NativeExecutable::hashFor): Deleted.
(JSC::ScriptExecutable::hashFor): Deleted.
* runtime/WebAssemblyExecutable.h: Copied from Source/JavaScriptCore/runtime/Executable.h.
(JSC::isCall): Deleted.
(JSC::ExecutableBase::ExecutableBase): Deleted.
(JSC::ExecutableBase::finishCreation): Deleted.
(JSC::ExecutableBase::isEvalExecutable): Deleted.
(JSC::ExecutableBase::isFunctionExecutable): Deleted.
(JSC::ExecutableBase::isProgramExecutable): Deleted.
(JSC::ExecutableBase::isModuleProgramExecutable): Deleted.
(JSC::ExecutableBase::isHostFunction): Deleted.
(JSC::ExecutableBase::isWebAssemblyExecutable): Deleted.
(JSC::ExecutableBase::createStructure): Deleted.
(JSC::ExecutableBase::generatedJITCodeForCall): Deleted.
(JSC::ExecutableBase::generatedJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::generatedJITCodeFor): Deleted.
(JSC::ExecutableBase::entrypointFor): Deleted.
(JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor): Deleted.
(JSC::ExecutableBase::offsetOfNumParametersFor): Deleted.
(JSC::ExecutableBase::hasJITCodeForCall): Deleted.
(JSC::ExecutableBase::hasJITCodeForConstruct): Deleted.
(JSC::ExecutableBase::hasJITCodeFor): Deleted.
(JSC::ExecutableBase::intrinsic): Deleted.
(JSC::ExecutableBase::intrinsicFor): Deleted.
(JSC::ScriptExecutable::source): Deleted.
(JSC::ScriptExecutable::sourceID): Deleted.
(JSC::ScriptExecutable::sourceURL): Deleted.
(JSC::ScriptExecutable::firstLine): Deleted.
(JSC::ScriptExecutable::setOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::hasOverrideLineNumber): Deleted.
(JSC::ScriptExecutable::overrideLineNumber): Deleted.
(JSC::ScriptExecutable::lastLine): Deleted.
(JSC::ScriptExecutable::startColumn): Deleted.
(JSC::ScriptExecutable::endColumn): Deleted.
(JSC::ScriptExecutable::typeProfilingStartOffset): Deleted.
(JSC::ScriptExecutable::typeProfilingEndOffset): Deleted.
(JSC::ScriptExecutable::usesEval): Deleted.
(JSC::ScriptExecutable::usesArguments): Deleted.
(JSC::ScriptExecutable::isArrowFunctionContext): Deleted.
(JSC::ScriptExecutable::isStrictMode): Deleted.
(JSC::ScriptExecutable::derivedContextType): Deleted.
(JSC::ScriptExecutable::evalContextType): Deleted.
(JSC::ScriptExecutable::ecmaMode): Deleted.
(JSC::ScriptExecutable::setNeverInline): Deleted.
(JSC::ScriptExecutable::setNeverOptimize): Deleted.
(JSC::ScriptExecutable::setNeverFTLOptimize): Deleted.
(JSC::ScriptExecutable::setDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::setCanUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::neverInline): Deleted.
(JSC::ScriptExecutable::neverOptimize): Deleted.
(JSC::ScriptExecutable::neverFTLOptimize): Deleted.
(JSC::ScriptExecutable::didTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::isInliningCandidate): Deleted.
(JSC::ScriptExecutable::isOkToOptimize): Deleted.
(JSC::ScriptExecutable::canUseOSRExitFuzzing): Deleted.
(JSC::ScriptExecutable::addressOfDidTryToEnterInLoop): Deleted.
(JSC::ScriptExecutable::features): Deleted.
(JSC::ScriptExecutable::recordParse): Deleted.
(JSC::ScriptExecutable::finishCreation): Deleted.
(JSC::ScriptExecutable::prepareForExecution): Deleted.
2016-10-20 Caitlin Potter <caitp@igalia.com>
[JSC] implement runtime for async functions
https://bugs.webkit.org/show_bug.cgi?id=163760
Reviewed by Yusuke Suzuki.
Async functions generate bytecode equivalent to the following, which is
highly dependent on the Generator implementation:
```
// Before translation:
async function asyncfn() {}
// After translation:
function asyncfn() {
let generator = {
@generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode, @generatorFrameState) {
// Body of async function
},
@generatorState: 0,
@generatorThis: this,
@generatorFrameState: <frame state>,
};
return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode);
}
```
Await Expressions are equivalent to non-delegating Yield expressions, and emit identical bytecode.
There are some caveats to be addressed later:
1) the `op_to_this` is always performed, whether it's used or not, like normal generators. (https://bugs.webkit.org/show_bug.cgi?id=151586)
2) for async arrow functions, the home object is always stored on the "body" function, regardless of whether it's needed or
not, for the same reason as #1 (and should also be fixed as part of https://bugs.webkit.org/show_bug.cgi?id=151586)
* CMakeLists.txt:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/AsyncFunctionPrototype.js: Added.
(asyncFunctionResume):
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::isArrowFunction):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
(JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
(JSC::BytecodeGenerator::emitNewFunction):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionNode::emitBytecode):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emitNewFuncCommon):
(JSC::JIT::emit_op_new_async_func):
(JSC::JIT::emitNewFuncExprCommon):
(JSC::JIT::emit_op_new_async_func_exp):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionInfo):
* parser/Parser.h:
(JSC::Scope::setSourceParseMode):
* parser/ParserModes.h:
(JSC::isGeneratorOrAsyncFunctionBodyParseMode):
(JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
* runtime/AsyncFunctionConstructor.cpp: Added.
(JSC::AsyncFunctionConstructor::AsyncFunctionConstructor):
(JSC::AsyncFunctionConstructor::finishCreation):
(JSC::callAsyncFunctionConstructor):
(JSC::constructAsyncFunctionConstructor):
(JSC::AsyncFunctionConstructor::getCallData):
(JSC::AsyncFunctionConstructor::getConstructData):
* runtime/AsyncFunctionConstructor.h: Added.
(JSC::AsyncFunctionConstructor::create):
(JSC::AsyncFunctionConstructor::createStructure):
* runtime/AsyncFunctionPrototype.cpp: Added.
(JSC::AsyncFunctionPrototype::AsyncFunctionPrototype):
(JSC::AsyncFunctionPrototype::finishCreation):
* runtime/AsyncFunctionPrototype.h: Added.
(JSC::AsyncFunctionPrototype::create):
(JSC::AsyncFunctionPrototype::createStructure):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/FunctionConstructor.h:
* runtime/JSAsyncFunction.cpp: Added.
(JSC::JSAsyncFunction::JSAsyncFunction):
(JSC::JSAsyncFunction::createImpl):
(JSC::JSAsyncFunction::create):
(JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSAsyncFunction.h: Added.
(JSC::JSAsyncFunction::allocationSize):
(JSC::JSAsyncFunction::createStructure):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::lazyAsyncFunctionStructure):
(JSC::JSGlobalObject::asyncFunctionPrototype):
(JSC::JSGlobalObject::asyncFunctionPrototypeConcurrently):
(JSC::JSGlobalObject::asyncFunctionStructure):
(JSC::JSGlobalObject::asyncFunctionStructureConcurrently):
2016-10-27 Mark Lam <mark.lam@apple.com>
JSFunction::put() should not allow caching of lazily reified properties.
https://bugs.webkit.org/show_bug.cgi?id=164081
Reviewed by Geoffrey Garen.
It is incorrect for JSFunction::put() to return PutPropertySlots that indicates
that its lazily reified properties (e.g. .caller, and .arguments) are cacheable.
The reason for this is:
1. Currently, a cacheable put may only consist of the following types of put
operations:
a. putting a new property at an offset in the object storage.
b. changing the value of an existing property at an offset in the object storage.
c. invoking the setter for a property at an offset in the object storage.
Returning a PutPropertySlot that indicates the property is cacheable means that
the property put must be one of the above operations.
For lazily reified properties, JSFunction::put() implements complex conditional
behavior that is different than the set of cacheable put operations above.
Hence, it should not claim that the property put is cacheable.
2. Cacheable puts are cached on the original structure of the object before the
put operation.
Reifying a lazy property will trigger a structure transition. Even though
subsequent puts to such a property may be cacheable after the structure
transition, it is incorrect to indicate that the property put is cacheable
because the caching is on the original structure, not the new transitioned
structure.
Also fixed some missing exception checks.
* jit/JITOperations.cpp:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::reifyLazyPropertyIfNeeded):
(JSC::JSFunction::reifyBoundNameIfNeeded):
* runtime/JSFunction.h:
2016-10-27 Caitlin Potter <caitp@igalia.com>
[JSC] forbid lexical redeclaration of generator formal parameters
https://bugs.webkit.org/show_bug.cgi?id=163930
Reviewed by Yusuke Suzuki.
Also forbids "arguments" and "eval" as generator argument names in strict mode.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::declareRestOrNormalParameter):
* parser/Parser.h:
(JSC::Parser::declareVariable):
(JSC::Parser::hasDeclaredParameter):
(JSC::Parser::isValidStrictMode):
2016-10-27 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Include ConsoleAgent in Workers - real console.log support
https://bugs.webkit.org/show_bug.cgi?id=163844
<rdar://problem/28903328>
Reviewed by Brian Burg.
* inspector/protocol/Worker.json:
2016-10-27 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Introduce Page WorkerAgent and Worker InspectorController
https://bugs.webkit.org/show_bug.cgi?id=163817
<rdar://problem/28899063>
Reviewed by Brian Burg.
* CMakeLists.txt:
* DerivedSources.make:
* inspector/protocol/Worker.json: Added.
New Worker domain.
2016-10-26 JF Bastien <jfbastien@apple.com>
WebAssembly API: implement Instance
As described in: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyinstance-objects
- Take ownership of Wasm::Plan's compilation result when successfully creating a JSWebAssemblyModule object.
- Construct a basic Instance with a Module.
- Handle second argument (importObject) of WebAssembly.Instance.
- Add reference text from the spec to WebAssembly.Module's code.
- Expose and test an empty 'exports' ModuleNamespaceObject on WebAssembly.Instance.
The implementation isn't complete yet: it relies on further work for which I've filed bugs.
WebAssembly API: implement Instance
https://bugs.webkit.org/show_bug.cgi?id=163998
Reviewed by Keith Miller.
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::getFunctions): allow transfering state out
(JSC::Wasm::Plan::getMemory): allow transfering state out
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::finishCreation): set the ModuleNamespaceObject, and expose it as "exports"
(JSC::JSWebAssemblyInstance::visitChildren): visit the ModuleNamespaceObject child
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule): move in the compiled functions and the memory
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance): take the Module, extract the Plan's results, and create the (empty for now) ModuleNamespaceObject
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule): add a few comments from the spec, and pass out the Plan's results
2016-10-26 Brian Burg <bburg@apple.com>
Web Inspector: remove unused bool return value from FrontendChannel::sendMessageToFrontend
https://bugs.webkit.org/show_bug.cgi?id=164046
Reviewed by Joseph Pecoraro.
* inspector/InspectorFrontendChannel.h:
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteConnectionToTarget.mm:
(Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
2016-10-26 JF Bastien <jfbastien@apple.com>
WebAssembly: remove now-dead JSWasmModule
https://bugs.webkit.org/show_bug.cgi?id=164044
Reviewed by Keith Miller.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
(JSC::WebAssemblyExecutable::visitChildren):
* runtime/Executable.h:
* wasm/JSWasmModule.cpp: Removed.
* wasm/JSWasmModule.h: Removed.
* wasm/WasmModuleParser.cpp:
2016-10-26 Mark Lam <mark.lam@apple.com>
JSGenericTypedArrayView::set() should check for exceptions.
https://bugs.webkit.org/show_bug.cgi?id=164007
<rdar://problem/28853775>
Reviewed by Filip Pizlo.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
2016-10-25 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Tell IDL result type to DFG to drop type checks in AI
https://bugs.webkit.org/show_bug.cgi?id=163900
Reviewed by Sam Weinig.
The IDL tells the conservative result type. While we use the heap prediction
for prediction propagation phase in DOMJIT getter (it is offered by get_by_id!),
we leverage the type told by IDL to produce the abstract value with the proven type
in AI. It effectively drops unnecessary type checks followed by CallDOM operations.
For example, when you write the code like,
if (node.nodeType === 9) {
// document.
}
Previously, we inserted a Int32 check for the result of node.nodeType.
It is dropped now.
We annotate the DOMJIT getter in jsc.cpp to ensure that the unnecessary type checks
are correctly dropped when executing JSTests/stress/domjit-getter.js.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* domjit/DOMJITGetterSetter.h:
(JSC::DOMJIT::GetterSetter::GetterSetter):
(JSC::DOMJIT::GetterSetter::resultType):
* jsc.cpp:
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
2016-10-25 Mark Lam <mark.lam@apple.com>
String.prototype.replace() should throw an OutOfMemoryError when using too much memory.
https://bugs.webkit.org/show_bug.cgi?id=163996
<rdar://problem/28263117>
Reviewed by Geoffrey Garen.
String.prototype.replace() uses a Vector internally for bookkeeping work.
Currently, if this vector gets too big, we just crash on allocation failure.
While this is correct behavior, it is not too friendly.
We now detect the imminent failure, and throw a OutOfMemoryError instead.
* runtime/StringPrototype.cpp:
(JSC::removeUsingRegExpSearch):
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::stringProtoFuncReplaceUsingRegExp):
2016-10-25 Mark Lam <mark.lam@apple.com>
Rename the reject() helper function to something more meaningful.
https://bugs.webkit.org/show_bug.cgi?id=163549
Reviewed by Saam Barati.
We'll rename reject() to typeError(). The intuition behind this is that all the
clients that uses this function will return typeError(..., shouldThrow, ...).
In a sense, they are returning a "type" of TypeError (which happened to be the
value false). In addition, it may also throw a JS TypeError if the shouldThrow
parameter is true.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::setLengthWithArrayStorage):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSArrayBufferView.cpp:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::validateAndApplyPropertyDescriptor):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setPrototype):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/Reject.h: Removed.
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayValueMap::putDirect):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
* runtime/TypeError.h: Copied from Source/JavaScriptCore/runtime/Reject.h.
(JSC::typeError):
(JSC::reject): Deleted.
2016-10-25 Filip Pizlo <fpizlo@apple.com>
HeapTimer should not hardcode all of its subclasses and USE(CF) shouldn't be a bizarre special case
https://bugs.webkit.org/show_bug.cgi?id=163947
Reviewed by Geoffrey Garen.
I want to introduce another HeapTimer. Prior to this change, that would have meant writing
exact copies of that timer's logic for each platform that has a HeapTimer (CF, GLIB, and
EFL). That logic would in turn be a duplicate of the logic already present in
IncrementalSweeper and GCActivityCallback: all of the subclasses of HeapTimer have their
own code for scheduling timers, so a new subclass would have to duplicate that code. Then,
to add insult to injury, the USE(CF) version of HeapTimer would have to have an extra case
for that new subclass since it doesn't use virtual methods effectively.
This changes HeapTimer on USE(CF) to know to get its runloop from Heap and to use virtual
methods effectively so that it doesn't have to know about all of its subclasses.
This also moves IncrementalSweeper's code for scheduling timers into HeapTimer. This means
that future subclasses of HeapTimer could simply use that logic.
This keeps changes to GCActivityCallback to a minimum. It still has a lot of
platform-specific code and I'm not sure that this code can be trivially deduplicated since
that code has more quirks. That's fine for now, since I mainly just need a sane way of
creating new timers that use IncrementalSweeper-like scheduling logic.
* heap/EdenGCActivityCallback.cpp:
* heap/EdenGCActivityCallback.h:
* heap/FullGCActivityCallback.cpp:
* heap/FullGCActivityCallback.h:
* heap/GCActivityCallback.cpp:
(JSC::GCActivityCallback::GCActivityCallback):
* heap/GCActivityCallback.h:
* heap/Heap.cpp:
(JSC::Heap::Heap):
* heap/Heap.h:
(JSC::Heap::runLoop):
* heap/HeapTimer.cpp:
(JSC::HeapTimer::HeapTimer):
(JSC::HeapTimer::setRunLoop):
(JSC::HeapTimer::~HeapTimer):
(JSC::HeapTimer::timerDidFire):
(JSC::HeapTimer::scheduleTimer):
(JSC::HeapTimer::cancelTimer):
(JSC::retainAPILock): Deleted.
(JSC::releaseAPILock): Deleted.
* heap/HeapTimer.h:
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::scheduleTimer):
(JSC::IncrementalSweeper::cancelTimer): Deleted.
* heap/IncrementalSweeper.h:
2016-10-25 JF Bastien <jfbastien@apple.com>
Remove redundant argument count check
Indexing argument out of bounds already returns jsUndefined().
Remove redundant argument count check
https://bugs.webkit.org/show_bug.cgi?id=163957
Reviewed by Keith Miller.
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
(JSC::Interpreter::callErrorConstructor):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2016-10-25 Mark Lam <mark.lam@apple.com>
Add ThrowScope::release() calls at all call sites of jsMakeNontrivialString().
https://bugs.webkit.org/show_bug.cgi?id=163990
Reviewed by Geoffrey Garen.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncToString):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
2016-10-25 Mark Lam <mark.lam@apple.com>
JSStringJoiner::joinedLength() should limit joined string lengths to INT_MAX.
https://bugs.webkit.org/show_bug.cgi?id=163937
<rdar://problem/28642990>
Reviewed by Geoffrey Garen.
JSStringJoiner::joinedLength() was previously limiting it to UINT_MAX. This is
inconsistent with other parts of string code which expects a max length of INT_MAX.
This is now fixed.
Also fixed jsMakeNontrivialString() to ensure that the resultant string length
is valid. It was previously allowing lengths greater than INT_MAX. This was
caught by the new assertion in JSString::setLength().
There are already pre-existing assertions in various JSString::finishCreation()
which do RELEASE_ASSERTs on the string length. To be consistent, I'm making the
assertion in JSString::setLength() a RELEASE_ASSERT. If this proves to be a
performance issue, I'll change this to a debug ASSERT later.
* runtime/JSString.cpp:
(JSC::JSRopeString::resolveRopeInternal8):
(JSC::JSRopeString::resolveRopeInternal8NoSubstring):
(JSC::JSRopeString::resolveRopeInternal16):
(JSC::JSRopeString::resolveRopeInternal16NoSubstring):
(JSC::JSRopeString::resolveRopeToAtomicString):
(JSC::JSRopeString::resolveRopeToExistingAtomicString):
(JSC::JSRopeString::resolveRope):
(JSC::JSRopeString::resolveRopeSlowCase8):
(JSC::JSRopeString::resolveRopeSlowCase):
(JSC::JSString::getStringPropertyDescriptor):
* runtime/JSString.h:
(JSC::JSString::finishCreation):
(JSC::JSString::length):
(JSC::JSString::isValidLength):
(JSC::JSString::toBoolean):
(JSC::JSString::canGetIndex):
(JSC::JSString::setLength):
(JSC::JSString::getStringPropertySlot):
(JSC::JSRopeString::unsafeView):
(JSC::JSRopeString::viewWithUnderlyingString):
* runtime/JSStringBuilder.h:
(JSC::jsMakeNontrivialString):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::joinedLength):
2016-10-25 JF Bastien <jfbastien@apple.com>
WebAssembly: fix unknown section name handling, and check for section size overflow
https://bugs.webkit.org/show_bug.cgi?id=163959
See: https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#high-level-structure
Name length and name are already included in the payload length.
Reviewed by Filip Pizlo.
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse):
2016-10-25 Christopher Reid <Christopher.Reid@am.sony.com>
jsc.cpp is leaking memory allocated by readline in runInteractive
https://bugs.webkit.org/show_bug.cgi?id=163958
According to http://web.mit.edu/gnu/doc/html/rlman_2.html,
"The line readline returns is allocated with malloc ();
you should free () the line when you are done with it."
The memory allocated by readline is not being freed when it should.
Reviewed by Mark Lam.
* jsc.cpp:
2016-10-25 Konstantin Tokarev <annulen@yandex.ru>
[cmake] Check if jscLib and WebKitGUID targets exist before using them
https://bugs.webkit.org/show_bug.cgi?id=163945
Reviewed by Alex Christensen.
Currently these targets are used under WIN32 condition, however they
are defined in PlatformWin.cmake, causing CMake warnings if port
supports WIN32 but does not use PlatformWin.cmake
* shell/CMakeLists.txt:
2016-10-25 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement Module
This implementation allows us to:
- Syncrhonously create a WebAssembly.Module with a typed array.
- Creates a compilation plan.
- Parse the Module and creates corresponding code.
- Throw WebAssembly.CompileError with mildly helpful [*] error messages on
failure.
Consult the API documentation for expected behavior: https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymodule-constructor
For now the implementation discards the generated code.
The next steps will be:
- Expose a Module's exports.
- Implement WebAssembly.Instance, which allows instantiating and running a
compiled Module.
- Beef up the testing infrastructure under JSTests/wasm so that more complex
modules can be created and tested (instead of writing the bits by hand).
This patch also:
- Adds assert.instanceof in assert.js.
- Refactors Wasm::Parser and friends to accept const uint8_t* as well as a
Vector, to avoid copying when invoked synchronously.
- Remove useless Structure from some of the wasm constructors: they're already
on the JSGlobalObject, visited properly and all.
- Fix off-by-one error in parsing: Parser::parseUInt32 failed if the integer
was exactly at end of file.
[*] On error messages while parsing: I filed https://bugs.webkit.org/show_bug.cgi?id=163919
WebAssembly JS API: implement Module
https://bugs.webkit.org/show_bug.cgi?id=163903
Reviewed by Keith Miller.
* runtime/ExceptionHelpers.cpp:
(JSC::defaultSourceAppender): make this public so that WebAssembly can use it: it generates those fancy (evaluating '...') messages at the end
* runtime/ExceptionHelpers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): remove the useless Structure from the WebAssembly objects (it's already in this file, no need to hold two references and visit them twice)
* testWasm.cpp:
(runWasmTests): update API
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::parseAndCompile): use updated API
* wasm/WasmB3IRGenerator.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::FunctionParser): use updated API
(JSC::Wasm::FunctionParser<Context>::parseExpression): use updated API
* wasm/WasmModuleParser.cpp:
(JSC::Wasm::ModuleParser::parse): generate error messages
* wasm/WasmModuleParser.h:
(JSC::Wasm::ModuleParser::ModuleParser):
(JSC::Wasm::ModuleParser::failed):
(JSC::Wasm::ModuleParser::errorMessage):
(JSC::Wasm::ModuleParser::functionInformation):
(JSC::Wasm::ModuleParser::memory):
* wasm/WasmParser.h: use update non-public API
(JSC::Wasm::Parser::parseVarUInt32):
(JSC::Wasm::Parser::parseVarUInt64):
(JSC::Wasm::Parser::source):
(JSC::Wasm::Parser::length):
(JSC::Wasm::Parser::Parser):
(JSC::Wasm::Parser::consumeCharacter):
(JSC::Wasm::Parser::consumeString):
(JSC::Wasm::Parser::parseUInt32):
(JSC::Wasm::Parser::parseUInt7):
* wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::Plan):
(JSC::Wasm::Plan::~Plan):
* wasm/WasmPlan.h:
(JSC::Wasm::Plan::failed):
(JSC::Wasm::Plan::errorMessage):
(JSC::Wasm::Plan::resultSize):
(JSC::Wasm::Plan::result):
(JSC::Wasm::Plan::memory):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createWebAssemblyCompileError): makes it easier to throw a WebAssembly.CompileError from Module
* wasm/js/JSWebAssemblyCompileError.h:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::create):
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyCompileErrorConstructor.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::create):
(JSC::WebAssemblyInstanceConstructor::finishCreation):
(JSC::WebAssemblyInstanceConstructor::visitChildren):
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::WebAssemblyMemoryConstructor::create):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
(JSC::WebAssemblyMemoryConstructor::visitChildren):
* wasm/js/WebAssemblyMemoryConstructor.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::constructJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::create):
(JSC::WebAssemblyModuleConstructor::finishCreation):
(JSC::WebAssemblyModuleConstructor::visitChildren):
* wasm/js/WebAssemblyModuleConstructor.h:
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::create):
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorConstructor.h:
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::WebAssemblyTableConstructor::create):
(JSC::WebAssemblyTableConstructor::finishCreation):
(JSC::WebAssemblyTableConstructor::visitChildren):
* wasm/js/WebAssemblyTableConstructor.h:
2016-10-25 Keith Miller <keith_miller@apple.com>
Add trivial Wasm conversion opcodes
https://bugs.webkit.org/show_bug.cgi?id=163950
Reviewed by Filip Pizlo.
This patch differentiates between Wasm opcodes that are trivially mapped to a B3 opcode and
those that are not. Some of the Wasm opcodes that are currently a non-simple opcode will
become simple as we add B3 opcodes for Wasm operations. The remaining opcodes will need to
be added via patchpoints in a later patch.
* wasm/WasmB3IRGenerator.cpp:
* wasm/WasmOps.h:
(JSC::Wasm::isSimple):
2016-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
Arrow functions with concise bodies cannot return regular expressions
https://bugs.webkit.org/show_bug.cgi?id=163162
Reviewed by Filip Pizlo.
When we encounter the RegExp in the parser, we first scan it as / or /=.
And if / or /= is parsed under the primary expression context, we rescan it
as RegExp. However, we did not update the token record information. So the
token record still says "I'm / or /=".
When we parse the string "() => /hello/", the last token becomes "/", which is
the first character of the RegExp, instead of "/hello/". Since the arrow
function parsing utilizes the end offset of the last token, we accidentally
recognize the range of the above arrow function as "() => /".
In this patch, we update the token when rescanning under the RegExp context.
This logic is similar to parsing Tail Template Literal token.
We also refine the error message for regular expression literals. And since
the REGEXP token is now introduced, the other error messages using that token
are improved too.
Currently, unterminated error messages can be seen in Parser.cpp. However,
these messages cannot be shown to users if the lexer has m_error. So these
code is meaningless. I'll move these tokenizing errors to the lexer in the
subsequent patch[1].
[1]: https://bugs.webkit.org/show_bug.cgi?id=163928
* parser/Lexer.cpp:
(JSC::Lexer<T>::fillTokenInfo):
(JSC::Lexer<T>::lex):
(JSC::Lexer<T>::scanRegExp):
(JSC::Lexer<T>::scanTrailingTemplateString):
(JSC::Lexer<T>::skipRegExp): Deleted.
* parser/Lexer.h:
(JSC::Lexer::getToken):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
(JSC::Parser::getToken):
* parser/ParserTokens.h:
2016-10-24 Per Arne Vollan <pvollan@apple.com>
[Win] CMake build type is not set.
https://bugs.webkit.org/show_bug.cgi?id=163917
Reviewed by Alex Christensen.
The CMAKE_BUILD_TYPE variable should be set to Debug or Release.
* JavaScriptCore.vcxproj/JavaScriptCore.proj:
2016-10-24 Chris Dumez <cdumez@apple.com>
Reduce special handling for typed arrays in JSDOMConvert.h
https://bugs.webkit.org/show_bug.cgi?id=163907
Reviewed by Sam Weinig.
Reduce special handling for typed arrays in JSDOMConvert.h by adding a toWrapped() static
function on JSGenericTypedArrayView, similarly to other wrapper types.
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::typedImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::toWrapped):
2016-10-24 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][DFG] CallDOM never writes Stack
https://bugs.webkit.org/show_bug.cgi?id=163926
Reviewed by Filip Pizlo and Saam Barati.
There is no way to write(Stack) in CallDOM.
This worst case (the most clobbering case) scenario
should be aligned to the one of Call, read(World) and write(Heap).
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2016-10-23 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Add a way for DOMJIT::Patchpoint to express effects
https://bugs.webkit.org/show_bug.cgi?id=163657
Reviewed by Saam Barati.
This patch introduces DOMJIT::Effect. It describes the side effects of
the DOMJIT::CallDOMPatchpoint. DOMJIT::CallDOMPatchpoint can use this
feature to teach the compilers about the effects. And the compilers
will perform CSE based on the reported effects.
As the same to B3's HeapRange, the effects are represented as a pair of
integers. [begin, end) pair will represents the range of the abstract
heap. We encode the abstract heap hierarchy into these pairs. Like,
Root: [0, 32)
Child1: [0, 20) Child2: [20, 32)
Child11: [0, 4) Child12: [4, 20)
This simplifies the representation of the abstract heap. And WebCore
just tells pairs of integers and it does not tell any detailed hierarchy.
So, DFG and FTL can optimize DOM operations without deep knowledge of
the DOM abstract heap hierarchy. For example, WebCore will tell that
firstChild will read Node_firstChild abstract heap. But this information
is encoded to the pair and DFG does not know the details. But still
DFG can understand the abstract heap hierarchy and can query whether the
given abstract heap overlaps with some abstract heap.
The heap range told by the WebCore is represented as DOMJIT::HeapRange.
DFG will handle this under the DOMState abstract heap. DOMJIT::HeapRange
is stored in DFG::AbstractHeap's Payload. We maintain the hierarchy by
DOMJIT::HeapRange in the DOMState abstract heap. We add a necessary
handling in DFG's AbstractHeap and ClobberSet.
And we also introduce DOMStateLoc for HeapLocation. It is combined with
DOMState AbstractHeap with DOMJIT::HeapRange. For example, we can
represent Node.firstChild as `read(DOMState:Node_firstChild)` and
`def(HeapLocation(node, DOMState:Node_firstChild))` thingy. This allows us
to perform CSE onto DOM getters that will read some of DOM heap!
For simplicity, we convert CallDOM from NodeVarArgs to the normal one.
CallDOM is now just used for DOMJIT getter. So its children is at most 2.
It may have either 1 or 2 children. If the global object is required
by CallDOMPatchpoint, it has 2 children. And we changed the order of
the children to further simplify the code. Before this change, the order
is 1: globalObject 2: base. After this patch, the order becomes 1: base,
and 2: globalObject. And the child2 may not exists if the global object
is not required. We changed all the existing DOMJIT patchpoint to this
form.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
* dfg/DFGAbstractHeap.cpp:
(JSC::DFG::AbstractHeap::dump):
* dfg/DFGAbstractHeap.h:
(JSC::DFG::AbstractHeap::isStrictSubtypeOf):
(JSC::DFG::AbstractHeap::overlaps):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::blessCallDOM):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
* dfg/DFGClobberSet.cpp:
(JSC::DFG::ClobberSet::overlaps):
* dfg/DFGClobberSet.h:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCallDOMData):
(JSC::DFG::Node::callDOMData):
(JSC::DFG::Node::hasCallDOMPatchpoint): Deleted.
(JSC::DFG::Node::callDOMPatchpoint): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
* domjit/DOMJITAbstractHeap.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::AbstractHeap::compute):
(JSC::DOMJIT::AbstractHeap::dump):
(JSC::DOMJIT::AbstractHeap::shallowDump):
(JSC::DOMJIT::AbstractHeap::deepDump):
* domjit/DOMJITAbstractHeap.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::AbstractHeap::AbstractHeap):
(JSC::DOMJIT::AbstractHeap::setParent):
(JSC::DOMJIT::AbstractHeap::isRoot):
(JSC::DOMJIT::AbstractHeap::isComputed):
(JSC::DOMJIT::AbstractHeap::range):
* domjit/DOMJITCallDOMPatchpoint.h:
* domjit/DOMJITEffect.h: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::Effect::forReadWrite):
(JSC::DOMJIT::Effect::forPure):
(JSC::DOMJIT::Effect::forDef):
(JSC::DOMJIT::Effect::mustGenerate):
* domjit/DOMJITHeapRange.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITCallDOMPatchpoint.h.
(JSC::DOMJIT::HeapRange::dump):
* domjit/DOMJITHeapRange.h: Added.
(JSC::DOMJIT::HeapRange::HeapRange):
(JSC::DOMJIT::HeapRange::fromRaw):
(JSC::DOMJIT::HeapRange::begin):
(JSC::DOMJIT::HeapRange::end):
(JSC::DOMJIT::HeapRange::rawRepresentation):
(JSC::DOMJIT::HeapRange::operator bool):
(JSC::DOMJIT::HeapRange::operator==):
(JSC::DOMJIT::HeapRange::top):
(JSC::DOMJIT::HeapRange::none):
(JSC::DOMJIT::HeapRange::isStrictSubtypeOf):
(JSC::DOMJIT::HeapRange::isSubtypeOf):
(JSC::DOMJIT::HeapRange::overlaps):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jsc.cpp:
2016-10-24 Alex Christensen <achristensen@webkit.org>
JSONParse should not crash with null Strings
https://bugs.webkit.org/show_bug.cgi?id=163918
<rdar://problem/28834095>
Reviewed by Michael Saboff.
When JSONParse is called with a null String, it calls String::is8bit, which dereferences a null pointer.
This is happening with new work in the Fetch API, but callers of JSONParse should not have to check
if the String is null.
* API/tests/JSONParseTest.cpp: Added.
(testJSONParse):
* API/tests/JSONParseTest.h: Added.
* API/tests/testapi.c:
(main):
Test parsing null Strings. They should have the same result as parsing empty Strings.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSONObject.cpp:
(JSC::JSONParse):
Check for null Strings.
* shell/PlatformWin.cmake:
2016-10-24 Devin Rousso <dcrousso+webkit@gmail.com>
Web Inspector: Scope chain shouldn't show empty Closure sections
https://bugs.webkit.org/show_bug.cgi?id=152348
Reviewed by Joseph Pecoraro.
* inspector/InjectedScriptSource.js:
(isEmptyObject):
(InjectedScript.CallFrameProxy._createScopeJson):
If the scope object has no properties, set empty to true.
* inspector/protocol/Debugger.json:
Added empty property to Scope type.
2016-10-24 Keith Miller <keith_miller@apple.com>
Wasm should support floating point operations.
https://bugs.webkit.org/show_bug.cgi?id=163770
Reviewed by Michael Saboff.
Since we now have a Double => Float Trunc in B3, we can now support calls in Wasm
that take floating point arguments. This patch also enables most of the Wasm
floating point operations, as the associated B3 opcode has been linked via wasm.json.
If there is no direct mapping to a B3 opcode the Wasm is not yet implemented. This
patch also fixes a bug in calls where the arguments would be reversed.
* testWasm.cpp:
(cast):
(invoke):
(boxf):
(boxd):
(runWasmTests):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::createJSWrapper):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallingConvention::loadArguments):
(JSC::Wasm::CallingConvention::setupCall):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmOps.h:
2016-10-24 Mark Lam <mark.lam@apple.com>
Dumping of op_negate bytecode is broken.
https://bugs.webkit.org/show_bug.cgi?id=163896
Reviewed by Darin Adler.
It thinks the bytecode consists of only 3 machine words, when it consists of 4.
This is now fixed.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
2016-10-24 Youenn Fablet <youenn@apple.com>
Activate WEB_RTC compilation flags for Mac bots
https://bugs.webkit.org/show_bug.cgi?id=163886
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2016-10-23 Zan Dobersek <zdobersek@igalia.com>
Unreviewed. Build fix for Clang and libstdc++ configurations.
* b3/testb3.cpp:
(JSC::B3::testAbsArgWithEffectfulDoubleConversion): Explicitly cast the
float-typed return value of fabs(float) to double in order to avoid
ambiguous calls to isIdentical().
(JSC::B3::testSqrtArgWithEffectfulDoubleConversion): Ditto for sqrt(float).
2016-10-22 Chris Dumez <cdumez@apple.com>
WebGLRenderingContextBase.bufferData() should use a union instead of overloading
https://bugs.webkit.org/show_bug.cgi?id=163795
Reviewed by Darin Adler.
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::data):
Add a data() method which aliases baseAddress() to align the API with
ArrayBuffer and reduce special handling at call sites.
* runtime/JSArrayBuffer.h:
(JSC::toArrayBuffer):
(JSC::JSArrayBuffer::toWrapped):
Add toWrapped() method similarly with WebCore wrapper types to
reduce special handling of JSArrayBuffer type.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::toWrapped):
* runtime/JSArrayBufferView.h:
Add toWrapped() method similarly with WebCore wrapper types to
reduce special handling of JSArrayBufferView type.
2016-10-21 Filip Pizlo <fpizlo@apple.com>
Slow and big Heap methods should not be inline
https://bugs.webkit.org/show_bug.cgi?id=163802
Reviewed by Keith Miller.
JSC often suffers from the inline cargo cult, and Heap is a prime example. This outlines a
bunch of Heap methods that are either already very big, or call out-of-line methods, or call
very big methods, or are not called often enough for inlining to matter.
This simplifies concurrent GC work because I'm so tired of recompiling the world when I touch
one of these methods.
This looks to be perf-neutral.
* heap/Heap.cpp:
(JSC::Heap::shouldCollect):
(JSC::Heap::isCurrentThreadBusy):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
(JSC::Heap::collectIfNecessaryOrDefer):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
(JSC::Heap::registerWeakGCMap):
(JSC::Heap::unregisterWeakGCMap):
(JSC::Heap::didAllocateBlock):
(JSC::Heap::didFreeBlock):
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect): Deleted.
(JSC::Heap::isCurrentThreadBusy): Deleted.
(JSC::Heap::reportExtraMemoryVisited): Deleted.
(JSC::Heap::reportExternalMemoryVisited): Deleted.
(JSC::Heap::collectIfNecessaryOrDefer): Deleted.
(JSC::Heap::collectAccordingToDeferGCProbability): Deleted.
(JSC::Heap::decrementDeferralDepthAndGCIfNeeded): Deleted.
(JSC::Heap::registerWeakGCMap): Deleted.
(JSC::Heap::unregisterWeakGCMap): Deleted.
(JSC::Heap::didAllocateBlock): Deleted.
(JSC::Heap::didFreeBlock): Deleted.
2016-10-21 Saam Barati <sbarati@apple.com>
SpeculativeJIT::compileTryGetById needs to pass in NeedsToSpill along both the cell speculation and untyped speculation path
https://bugs.webkit.org/show_bug.cgi?id=163622
Reviewed by Yusuke Suzuki.
We were passing in DontSpill in the Untyped:child1() case, which caused us
not to spill the base register. This is obviously wrong because the
DFG's register allocator expected the base to still be in the register
that it allocated for it after the TryGetById node executed.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTryGetById):
2016-10-21 Keith Miller <keith_miller@apple.com>
Expand Trunc in B3 to support Double to Float
https://bugs.webkit.org/show_bug.cgi?id=163809
Reviewed by Geoffrey Garen.
This feature is useful for passing floating point arguments via registers.
Currently, ArgumentRegValue returns a the full 64-bit register. Thus, we
need a way to indicate to B3 that we only want the low 32-bits.
* b3/B3Common.h:
(JSC::B3::isIdentical):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::typeFor):
* b3/testb3.cpp:
(JSC::B3::testAddFPRArgsFloat):
(JSC::B3::testCeilArgWithEffectfulDoubleConversion):
(JSC::B3::testFloorArgWithEffectfulDoubleConversion):
(JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
(JSC::B3::run):
2016-10-21 Keith Miller <keith_miller@apple.com>
Rename WASM to Wasm
https://bugs.webkit.org/show_bug.cgi?id=163796
Rubber stamped by Filip Pizlo.
* CMakeLists.txt:
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntThunks.cpp:
(JSC::vmEntryToWasm):
(JSC::vmEntryToWASM): Deleted.
* llint/LLIntThunks.h:
* runtime/Executable.cpp:
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
* runtime/Executable.h:
* shell/CMakeLists.txt:
* testWASM.cpp:
(runWASMTests): Deleted.
* testWasm.cpp: Renamed from Source/JavaScriptCore/testWASM.cpp.
(CommandLine::CommandLine):
(printUsageStatement):
(CommandLine::parseArguments):
(runLEBTests):
(invoke):
(box):
(runWasmTests):
(main):
* wasm/JSWASMModule.cpp:
(JSC::JSWASMModule::JSWASMModule): Deleted.
(JSC::JSWASMModule::destroy): Deleted.
(JSC::JSWASMModule::visitChildren): Deleted.
* wasm/JSWASMModule.h:
(JSC::JSWASMModule::create): Deleted.
(JSC::JSWASMModule::createStructure): Deleted.
(JSC::JSWASMModule::i32Constants): Deleted.
(JSC::JSWASMModule::f32Constants): Deleted.
(JSC::JSWASMModule::f64Constants): Deleted.
(JSC::JSWASMModule::signatures): Deleted.
(JSC::JSWASMModule::functionImports): Deleted.
(JSC::JSWASMModule::functionImportSignatures): Deleted.
(JSC::JSWASMModule::globalVariableTypes): Deleted.
(JSC::JSWASMModule::functionDeclarations): Deleted.
(JSC::JSWASMModule::functionPointerTables): Deleted.
(JSC::JSWASMModule::arrayBuffer): Deleted.
(JSC::JSWASMModule::functions): Deleted.
(JSC::JSWASMModule::functionStartOffsetsInSource): Deleted.
(JSC::JSWASMModule::functionStackHeights): Deleted.
(JSC::JSWASMModule::globalVariables): Deleted.
(JSC::JSWASMModule::importedFunctions): Deleted.
* wasm/JSWasmModule.cpp: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.cpp.
(JSC::JSWasmModule::JSWasmModule):
(JSC::JSWasmModule::destroy):
(JSC::JSWasmModule::visitChildren):
* wasm/JSWasmModule.h: Renamed from Source/JavaScriptCore/wasm/JSWASMModule.h.
(JSC::JSWasmModule::create):
(JSC::JSWasmModule::createStructure):
(JSC::JSWasmModule::i32Constants):
(JSC::JSWasmModule::f32Constants):
(JSC::JSWasmModule::f64Constants):
(JSC::JSWasmModule::signatures):
(JSC::JSWasmModule::functionImports):
(JSC::JSWasmModule::functionImportSignatures):
(JSC::JSWasmModule::globalVariableTypes):
(JSC::JSWasmModule::functionDeclarations):
(JSC::JSWasmModule::functionPointerTables):
(JSC::JSWasmModule::arrayBuffer):
(JSC::JSWasmModule::functions):
(JSC::JSWasmModule::functionStartOffsetsInSource):
(JSC::JSWasmModule::functionStackHeights):
(JSC::JSWasmModule::globalVariables):
(JSC::JSWasmModule::importedFunctions):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper): Deleted.
(JSC::WASM::parseAndCompile): Deleted.
* wasm/WASMCallingConvention.cpp:
(JSC::WASM::jscCallingConvention): Deleted.
(JSC::WASM::wasmCallingConvention): Deleted.
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::CallingConvention): Deleted.
(JSC::WASM::CallingConvention::marshallArgumentImpl): Deleted.
(JSC::WASM::CallingConvention::marshallArgument): Deleted.
(JSC::WASM::CallingConvention::loadArguments): Deleted.
(JSC::WASM::CallingConvention::setupCall): Deleted.
(JSC::WASM::nextJSCOffset): Deleted.
* wasm/WASMFormat.h:
(JSC::WASM::toB3Type): Deleted.
(JSC::WASM::isValueType): Deleted.
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::FunctionParser): Deleted.
(JSC::WASM::FunctionParser<Context>::parse): Deleted.
(JSC::WASM::FunctionParser<Context>::parseBlock): Deleted.
(JSC::WASM::FunctionParser<Context>::parseExpression): Deleted.
(JSC::WASM::FunctionParser<Context>::parseUnreachableExpression): Deleted.
* wasm/WASMMemory.cpp:
(JSC::WASM::Memory::Memory): Deleted.
* wasm/WASMMemory.h:
(JSC::WASM::Memory::~Memory): Deleted.
(JSC::WASM::Memory::memory): Deleted.
(JSC::WASM::Memory::size): Deleted.
(JSC::WASM::Memory::pinnedRegisters): Deleted.
(JSC::WASM::Memory::mode): Deleted.
(JSC::WASM::Memory::grow): Deleted.
(JSC::WASM::Memory::offsetOfSize): Deleted.
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse): Deleted.
(JSC::WASM::ModuleParser::parseMemory): Deleted.
(JSC::WASM::ModuleParser::parseFunctionTypes): Deleted.
(JSC::WASM::ModuleParser::parseFunctionSignatures): Deleted.
(JSC::WASM::ModuleParser::parseFunctionDefinitions): Deleted.
* wasm/WASMModuleParser.h:
(JSC::WASM::ModuleParser::ModuleParser): Deleted.
(JSC::WASM::ModuleParser::functionInformation): Deleted.
(JSC::WASM::ModuleParser::memory): Deleted.
* wasm/WASMOps.h:
(JSC::WASM::isValidOpType): Deleted.
(JSC::WASM::isControlOp): Deleted.
* wasm/WASMParser.h:
(JSC::WASM::Parser::parseVarUInt32): Deleted.
(JSC::WASM::Parser::parseVarUInt64): Deleted.
(JSC::WASM::Parser::Parser): Deleted.
(JSC::WASM::Parser::consumeCharacter): Deleted.
(JSC::WASM::Parser::consumeString): Deleted.
(JSC::WASM::Parser::parseUInt32): Deleted.
(JSC::WASM::Parser::parseUInt7): Deleted.
(JSC::WASM::Parser::parseVarUInt1): Deleted.
(JSC::WASM::Parser::parseValueType): Deleted.
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan): Deleted.
* wasm/WASMSections.h:
(JSC::WASM::Sections::validateOrder): Deleted.
* wasm/WasmB3IRGenerator.cpp: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.cpp.
(dumpProcedure):
(JSC::Wasm::createJSWrapper):
(JSC::Wasm::parseAndCompile):
* wasm/WasmB3IRGenerator.h: Renamed from Source/JavaScriptCore/wasm/WASMB3IRGenerator.h.
* wasm/WasmCallingConvention.cpp: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.cpp.
(JSC::Wasm::jscCallingConvention):
(JSC::Wasm::wasmCallingConvention):
* wasm/WasmCallingConvention.h: Renamed from Source/JavaScriptCore/wasm/WASMCallingConvention.h.
(JSC::Wasm::CallingConvention::CallingConvention):
(JSC::Wasm::CallingConvention::marshallArgumentImpl):
(JSC::Wasm::CallingConvention::marshallArgument):
(JSC::Wasm::CallingConvention::loadArguments):
(JSC::Wasm::CallingConvention::setupCall):
(JSC::Wasm::nextJSCOffset):
* wasm/WasmFormat.h: Renamed from Source/JavaScriptCore/wasm/WASMFormat.h.
(JSC::Wasm::toB3Type):
(JSC::Wasm::isValueType):
* wasm/WasmFunctionParser.h: Renamed from Source/JavaScriptCore/wasm/WASMFunctionParser.h.
(JSC::Wasm::FunctionParser<Context>::FunctionParser):
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseBlock):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmMemory.cpp: Renamed from Source/JavaScriptCore/wasm/WASMMemory.cpp.
(JSC::Wasm::Memory::Memory):
* wasm/WasmMemory.h: Renamed from Source/JavaScriptCore/wasm/WASMMemory.h.
(JSC::Wasm::Memory::~Memory):
(JSC::Wasm::Memory::memory):
(JSC::Wasm::Memory::size):
(JSC::Wasm::Memory::pinnedRegisters):
(JSC::Wasm::Memory::mode):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::offsetOfSize):
* wasm/WasmModuleParser.cpp: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.cpp.
(JSC::Wasm::ModuleParser::parse):
(JSC::Wasm::ModuleParser::parseMemory):
(JSC::Wasm::ModuleParser::parseFunctionTypes):
(JSC::Wasm::ModuleParser::parseFunctionSignatures):
(JSC::Wasm::ModuleParser::parseFunctionDefinitions):
* wasm/WasmModuleParser.h: Renamed from Source/JavaScriptCore/wasm/WASMModuleParser.h.
(JSC::Wasm::ModuleParser::ModuleParser):
(JSC::Wasm::ModuleParser::functionInformation):
(JSC::Wasm::ModuleParser::memory):
* wasm/WasmOps.h: Renamed from Source/JavaScriptCore/wasm/WASMOps.h.
(JSC::Wasm::isValidOpType):
(JSC::Wasm::isControlOp):
* wasm/WasmParser.h: Renamed from Source/JavaScriptCore/wasm/WASMParser.h.
(JSC::Wasm::Parser::parseVarUInt32):
(JSC::Wasm::Parser::parseVarUInt64):
(JSC::Wasm::Parser::Parser):
(JSC::Wasm::Parser::consumeCharacter):
(JSC::Wasm::Parser::consumeString):
(JSC::Wasm::Parser::parseUInt32):
(JSC::Wasm::Parser::parseUInt7):
(JSC::Wasm::Parser::parseVarUInt1):
(JSC::Wasm::Parser::parseValueType):
* wasm/WasmPlan.cpp: Renamed from Source/JavaScriptCore/wasm/WASMPlan.cpp.
(JSC::Wasm::Plan::Plan):
* wasm/WasmPlan.h: Renamed from Source/JavaScriptCore/wasm/WASMPlan.h.
* wasm/WasmSections.h: Renamed from Source/JavaScriptCore/wasm/WASMSections.h.
(JSC::Wasm::Sections::validateOrder):
2016-10-21 Caitlin Potter <caitp@igalia.com>
[JSC] don't crash when arguments to `new Function()` produce unexpected AST
https://bugs.webkit.org/show_bug.cgi?id=163748
Reviewed by Mark Lam.
The ASSERT(statement); and ASSERT(funcDecl); lines are removed, replaced with blocks
to report a generic Parser error message. These lines are only possible to be reached
if the input string produced an unexpected AST, which previously could be used to crash
the process via ASSERT failure.
The node type assertions are left in the tree, as it should be impossible for a top-level
`{` to produce anything other than a Block node. If the node turns out not to be a Block,
it indicates that the (C++) caller of this function (E.g in FunctionConstructor.cpp), is
doing something incorrect. Similarly, it should be impossible for the `funcDecl` node to
be anything other than a function declaration given the conventions of the caller of this
function.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2016-10-20 Keith Miller <keith_miller@apple.com>
Add support for WASM calls
https://bugs.webkit.org/show_bug.cgi?id=161727
Reviewed by Filip Pizlo and Michael Saboff.
Add support for WASM calls. Since most of the work for this was already done when we added
WASM Memory, this is mostly just cleanup work. The main interesting part of this patch is
how we link calls to other WASM functions in the same module. Since a WASM callee may not
have been compiled by the time the current function has started compilation we don't know
what address we need to call to. For each callsite in the compiling function, WASM
remembers the CodeLocationCall and the target function index. Once all WASM functions are
compiled, each callsite is linked to the appropriate entrypoint.
* testWASM.cpp:
(runWASMTests):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper):
(JSC::WASM::parseAndCompile):
* wasm/WASMB3IRGenerator.h:
* wasm/WASMCallingConvention.cpp:
(JSC::WASM::jscCallingConvention):
(JSC::WASM::wasmCallingConvention):
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::CallingConvention):
(JSC::WASM::CallingConvention::marshallArgumentImpl):
(JSC::WASM::CallingConvention::marshallArgument):
(JSC::WASM::CallingConvention::loadArguments):
(JSC::WASM::CallingConvention::setupCall):
(JSC::WASM::CallingConvention::iterate): Deleted.
* wasm/WASMFormat.h:
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::FunctionParser):
(JSC::WASM::FunctionParser<Context>::parseBlock):
(JSC::WASM::FunctionParser<Context>::parseExpression):
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse):
* wasm/WASMOps.h:
* wasm/WASMParser.h:
(JSC::WASM::Parser::parseVarUInt32):
(JSC::WASM::Parser::parseVarUInt64):
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan):
2016-10-21 Wenson Hsieh <wenson_hsieh@apple.com>
Implement InputEvent.getTargetRanges() for the input events spec
https://bugs.webkit.org/show_bug.cgi?id=162947
<rdar://problem/28853079>
Reviewed by Darin Adler.
Boilerplate change to add a runtime guard for InputEvents-related IDL interfaces. See WebCore ChangeLog entry
for more details.
* runtime/CommonIdentifiers.h:
2016-10-20 Zan Dobersek <zdobersek@igalia.com>
Fix JSC cast-align compiler warnings on ARMv7
https://bugs.webkit.org/show_bug.cgi?id=163744
Reviewed by Mark Lam.
Use the reinterpret_cast_ptr workaround in a few places where
the cast alignment warning is being thrown by the GCC compiler
when compiling for the ARMv7 architecture.
* heap/Heap.cpp:
(JSC::Zombify::visit):
* heap/HeapCell.h:
(JSC::HeapCell::zap):
(JSC::HeapCell::isZapped):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::specializedSweep):
2016-10-20 Filip Pizlo <fpizlo@apple.com>
The tracking of the coarse-grain Heap state (allocating or not, collector or not, eden vs full) should respect the orthogonality between allocating and collecting
https://bugs.webkit.org/show_bug.cgi?id=163738
Reviewed by Geoffrey Garen.
We need to know if we're currently in an allocation slow path, so that code can assert that
it's not being used from inside a destructor that runs during a sweep. We need to know if
we're currently collecting, because some code behaves differently during collection, and
other code wants to assert that it's not being used from inside a visitChildren method that
runs during marking. If we are collecting, we need to know if it's an eden collection or a
full collection. If we are requesting a collection, we need to know if we're requesting an
eden collection, a full collection, or any kind of collection.
Prior to this change, you would reason about all of these things using the HeapOperation. It
had the following states: NoOperation, Allocation, FullCollection, EdenCollection, and
AnyCollection. NoOperation versus Allocation was primarily for asserting that sweep didn't
call arbitrary JS. FullCollection versus EdenCollection was about describing generations. We
would even use HeapOperation in places where we knew that it could only be either Full or
Eden, because we just needed a variable to tell us which generation we were talking about.
It was all very confusing.
Where it completely breaks down is the fact that a concurrent GC has two logical threads, the
mutator and the collector, which can change state independently. The mutator can be
allocating. It can also be doing some work to help the GC. That's three states: running,
allocating, or helping GC. At the same time, the GC thread could either be running or not,
and if it's running, it could be a full collection or an eden collection. Because the mutator
and collector can run at the same time, it means that if we used one enum, we would need nine
states: every combination of mutator running, allocating, or helping GC, crossed with
collector not running, running eden, or running full. So, this change decouples mutator state
from collector state and uses two separate fields with two different types.
Mutator state is described using MutatorState, which can be either MutatorState::Running,
MutatorState::Allocating, or MutatorState::HelpingGC.
Collector state is described using Optional<CollectionScope>. CollectionScope describes how
big the scope of the collection is, and it can be either CollectionScope::Eden or
CollectionScope::Full. If the Optional is Nullopt, it means that we are not collecting. This
way, you can treat collectionScope as a boolean (an Optional is true iff it's engaged). You
can pass around just a CollectionScope if you know that you must be collecting and you just
want to know about the generation. Also, we can use Nullopt in methods that request
collection, which those methods take to mean that they can run any kind of collection (the
old AnyCollection).
Another use of HeapOperation was to answer questions about whether the caller is running as
part of the GC or as part of the mutator. Optional<CollectionScope> does not answer this,
since code that runs in the mutator while the mutator is not HelpingGC at the same time as
the collector is running should run as if it was part of the mutator not as if it was part of
the GC. MutatorState is needed to answer this question, but it doesn't tell the whole story
since code that runs in the collector thread at the same time as the mutator is running
should run as if it was part of the GC not as if it was part of the mutator. So, we need to
know if we're on the collector thread or the mutator thread. We already have a WTF facility
for this, which answers if a thread is a GC thread. But we already use this to answer a
stronger question: are we part of the parallel GC helpers? Some functions in the GC, like
mark bit queries, will work fine in a concurrent collector thread so long as there is no
parallel marking. So, this change also changes WTF's mayBeGCThread to tell what kind of GC
thread we may be: either GCThreadType::Main or GCThreadType::Helper. The parallel GC safety
checks look for GCThreadType::Helper. The "should I run as mutator" query can now be answered
by checking with mayBeGCThread, which returns Optional<GCThreadType>; if engaged, then run as
GC, else run as GC if MutatorState is HelpingGC, else run as mutator.
This doesn't change the way that the GC behaves, but it does change how the GC represents a
fundamental piece of state. So, it's a big change. It should be perf-neutral (still testing).
* API/JSBase.cpp:
(JSSynchronousEdenCollectForDebugging):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
* dfg/DFGWorklist.cpp:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* heap/AllocatingScope.h: Added.
(JSC::AllocatingScope::AllocatingScope):
(JSC::AllocatingScope::~AllocatingScope):
* heap/AllocationScope.h: Removed.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
* heap/CodeBlockSet.h:
* heap/CollectionScope.cpp: Added.
(JSC::collectionScopeName):
(WTF::printInternal):
* heap/CollectionScope.h: Added.
* heap/EdenGCActivityCallback.cpp:
(JSC::EdenGCActivityCallback::doCollection):
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/GCTypeMap.h:
(JSC::GCTypeMap::operator[]):
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::lastChanceToFinalize):
(JSC::Heap::markRoots):
(JSC::Heap::beginMarking):
(JSC::Heap::visitSmallStrings):
(JSC::Heap::updateObjectCounts):
(JSC::Heap::deleteAllCodeBlocks):
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::collectAllGarbage):
(JSC::Heap::collect):
(JSC::Heap::collectWithoutAnySweep):
(JSC::Heap::collectImpl):
(JSC::Heap::willStartCollection):
(JSC::Heap::flushWriteBarrierBuffer):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
(JSC::Heap::notifyIncrementalSweeper):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::didFinishCollection):
(JSC::Heap::isValidAllocation):
(JSC::Heap::shouldDoFullCollection):
* heap/Heap.h:
(JSC::Heap::mutatorState):
(JSC::Heap::collectionScope):
(JSC::Heap::operationInProgress): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::shouldCollect):
(JSC::Heap::isCurrentThreadBusy):
(JSC::Heap::isMarked):
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
(JSC::Heap::collectAccordingToDeferGCProbability):
(JSC::Heap::isBusy): Deleted.
(JSC::Heap::isCollecting): Deleted.
* heap/HeapObserver.h:
* heap/HeapOperation.cpp: Removed.
* heap/HeapOperation.h: Removed.
* heap/HeapVerifier.cpp:
(JSC::HeapVerifier::initializeGCCycle):
(JSC::HeapVerifier::reportObject):
(JSC::HeapVerifier::collectionTypeName): Deleted.
* heap/HeapVerifier.h:
(JSC::HeapVerifier::GCCycle::collectionTypeName): Deleted.
* heap/HelpingGCScope.h: Added.
(JSC::HelpingGCScope::HelpingGCScope):
(JSC::HelpingGCScope::~HelpingGCScope):
* heap/LargeAllocation.cpp:
(JSC::LargeAllocation::flip):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::doTestCollectionsIfNeeded):
(JSC::MarkedAllocator::allocateSlowCaseImpl):
* heap/MarkedBlock.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::prepareForAllocation):
(JSC::MarkedSpace::visitWeakSets):
(JSC::MarkedSpace::reapWeakSets):
(JSC::MarkedSpace::prepareForMarking):
(JSC::MarkedSpace::beginMarking):
(JSC::MarkedSpace::snapshotUnswept):
* heap/MutatorState.cpp: Added.
(WTF::printInternal):
* heap/MutatorState.h: Added.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::didStartMarking):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::protocolTypeForHeapOperation):
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorHeapAgent.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jsc.cpp:
(functionFullGC):
(functionEdenGC):
* runtime/Completion.cpp:
(JSC::evaluate):
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
(JSC::linkAndEvaluateModule):
* runtime/JSLock.cpp:
(JSC::JSLock::DropAllLocks::DropAllLocks):
* runtime/SmallStrings.h:
(JSC::SmallStrings::needsToBeVisited):
* runtime/VM.h:
(JSC::VM::isCollectorBusyOnCurrentThread):
(JSC::VM::isCollectorBusy): Deleted.
* tools/JSDollarVMPrototype.cpp:
(JSC::JSDollarVMPrototype::edenGC):
2016-10-20 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Drop isEnvironmentRecord type info flag and use JSType information instead
https://bugs.webkit.org/show_bug.cgi?id=163761
Reviewed by Keith Miller.
When we call a function in the following form,
var charAt = String.prototype.charAt;
charAt(); // |this| becomes the global object.
we should see |this| as undefined/null. In StringPrototype.cpp,
we use IsEnvironmentRecord type info flag to check whther the
given |this| is an environment record.
However, type info flag is precious thing and only StringPrototype.cpp
uses IsEnvironmentRecord. In addition to that, JSType should
already knows whether the given object is an environment record.
So IsEnvironmentRecord type info flag should be dropped.
This patch adds a new JSType, StrictEvalActivation. And we add a new
method JSObject::isEnvironmentRecord(). This method uses JSType to
return the result. And we drop IsEnvironmentRecord type info flag.
This patch makes a room for putting one bit flag to the out of line
type info flag. Previously, it is already exhausted.
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/JSObject.h:
(JSC::JSObject::isStrictEvalActivation):
(JSC::JSObject::isEnvironmentRecord):
* runtime/JSSymbolTableObject.h:
* runtime/JSType.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::newImpurePropertyFiresWatchpoints):
(JSC::TypeInfo::isEnvironmentRecord): Deleted.
* runtime/StrictEvalActivation.h:
(JSC::StrictEvalActivation::createStructure):
* runtime/StringPrototype.cpp:
(JSC::checkObjectCoercible):
2016-10-20 JF Bastien <jfbastien@apple.com>
WebAssembly API: implement exception constructors properly
- Rename WebAssemblyObject to JSWebAssembly for consistency.
- WebAssembly object now has its own prototype: add WebAssemblyPrototype, and
use it to register JSWebAssembly's function properties through auto-generated
.lut.h, instead of manually.
- The error constructors used to throw (e.g. `new WebAssembly.CompileError()`).
- Register WebAssembly's constructors from the global object, and hold a
reference to their structure and prototype so that invoking the constructor
can use the structure directly from the global object.
- Add a prototype base field to global object creation. Previous ones all had
Object's prototype as their base, but WebAssembly's error constructors have
Error as their base.
- Test for the error object's correctness.
- Add missing #if ENABLE(WEBASSEMBLY)
WebAssembly API: implement exception constructors properly
https://bugs.webkit.org/show_bug.cgi?id=163699
Reviewed by Keith Miller.
* CMakeLists.txt: rename WebAssemblyObject -> JSWebAssembly; add a .lut.h file
* DerivedSources.make: new .lut.h file
* JavaScriptCore.xcodeproj/project.pbxproj: ditto
* runtime/JSGlobalObject.cpp: new prototypeBase macro
(JSC::JSGlobalObject::init): register WebAssembly constructors here
(JSC::JSGlobalObject::visitChildren): use the macro to visit
* runtime/JSGlobalObject.h: declare the WebAssembly constructor macro
* wasm/JSWebAssembly.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssembly::create):
(JSC::JSWebAssembly::createStructure):
(JSC::JSWebAssembly::finishCreation):
(JSC::JSWebAssembly::JSWebAssembly):
* wasm/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/WebAssemblyObject.cpp: Removed.
* wasm/js/JSWebAssemblyCompileError.cpp:
* wasm/js/JSWebAssemblyCompileError.h:
(JSC::JSWebAssemblyCompileError::create): string convenience
* wasm/js/JSWebAssemblyInstance.cpp:
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.cpp:
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.cpp:
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/JSWebAssemblyRuntimeError.cpp:
* wasm/js/JSWebAssemblyRuntimeError.h:
(JSC::JSWebAssemblyRuntimeError::create): string convenience
* wasm/js/JSWebAssemblyTable.cpp:
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):don't throw, create the object
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):no need for the structure, it's on the global object
* wasm/js/WebAssemblyCompileErrorConstructor.h:
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
* wasm/js/WebAssemblyCompileErrorPrototype.h:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyInstancePrototype.h:
* wasm/js/WebAssemblyMemoryConstructor.cpp:
* wasm/js/WebAssemblyMemoryConstructor.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
* wasm/js/WebAssemblyMemoryPrototype.h:
* wasm/js/WebAssemblyModuleConstructor.cpp:
* wasm/js/WebAssemblyModuleConstructor.h:
* wasm/js/WebAssemblyModulePrototype.cpp:
* wasm/js/WebAssemblyModulePrototype.h:
* wasm/js/WebAssemblyPrototype.cpp: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyCompileErrorPrototype.cpp.
(JSC::webAssemblyFunctionValidate):
(JSC::webAssemblyFunctionCompile):
(JSC::WebAssemblyPrototype::create):
(JSC::WebAssemblyPrototype::createStructure):
(JSC::WebAssemblyPrototype::finishCreation):
(JSC::WebAssemblyPrototype::WebAssemblyPrototype):
* wasm/js/WebAssemblyPrototype.h: Copied from Source/JavaScriptCore/wasm/js/WebAssemblyMemoryPrototype.h.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):don't throw, create the object
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):no need for the structure, it's on the global object
* wasm/js/WebAssemblyRuntimeErrorConstructor.h:
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
* wasm/js/WebAssemblyRuntimeErrorPrototype.h:
* wasm/js/WebAssemblyTableConstructor.cpp:
* wasm/js/WebAssemblyTableConstructor.h:
* wasm/js/WebAssemblyTablePrototype.cpp:
* wasm/js/WebAssemblyTablePrototype.h:
2016-10-19 Myles C. Maxfield <mmaxfield@apple.com>
[macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
https://bugs.webkit.org/show_bug.cgi?id=163374
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2016-10-20 Caitlin Potter <caitp@igalia.com>
[JSC] disallow references to `await` in AsyncFunction formal parameters
https://bugs.webkit.org/show_bug.cgi?id=163694
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
2016-10-19 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Move InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero to out of line type info flags
https://bugs.webkit.org/show_bug.cgi?id=163716
Reviewed by Saam Barati.
We found that all the accesses to the InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero flag is
done through the Structure. There is no user that accesses this flag in the cell inlined member. And JIT
code does not access it directly. That means that we can move this flag from inlined flags to out of line
flags. This patch moves it to the out of line flags. And make one bit empty in inlined flags. Later this
new empty flag will be used by megamorphic DOMJIT implementation.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasStaticPropertyTable):
(JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero):
2016-10-20 Keith Miller <keith_miller@apple.com>
Invalid assertion in arguments elimination
https://bugs.webkit.org/show_bug.cgi?id=163740
<rdar://problem/27911462>
Reviewed by Michael Saboff.
The DFGFTL's arguments elimination phase incorrectly asserted that a GetFromArguments' first
child would always be a CreateDirectArguments. While we only create the
op_get_from_arguments bytecode pointing to a create_direct_arguments, its possible for a
number of reasons that a DFG GetFromArguments may not point to a CreateDirectArguments. For
example, if we are OSR entering in some function with direct arguments the
CreateDirectArguments node might become ExtractOSREntryLocals.
* dfg/DFGArgumentsEliminationPhase.cpp:
2016-10-20 Caitlin Potter <caitp@igalia.com>
[JSC] throw TypeError when constructing dynamically created JSGeneratorFunction
https://bugs.webkit.org/show_bug.cgi?id=163714
Reviewed by Mark Lam.
According to CreateDynamicFunction() (https://tc39.github.io/ecma262/#sec-createdynamicfunction),
non-normal functions are not constructors. Previously, dynamically created functions would always
be constructible, and so it was possible to evaluate `new (function*() {}.constructor())`,
and have it return an Iterator object.
This change selects a dynamically created function's ConstructAbility based on its parse mode instead.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
2016-10-19 JF Bastien <jfbastien@apple.com>
create_hash_table: allow empty tables
The Windows build was broken by because I added empty tables and Windows insists that empty tables are horrible. Put in dummy entries in that case.
create_hash_table: allow empty tables
https://bugs.webkit.org/show_bug.cgi?id=163701
Reviewed by Keith Miller.
* create_hash_table:
2016-10-19 JF Bastien <jfbastien@apple.com>
JavaScript WebAssembly API: baby steps
- Expand WebAssembly constructors into their own files. This requires a lot of
boilerplate, as well as adding the .lut.h files. All of the
JSWebAssembly*.{h,cpp}, as well as Constructor and Prototype files, are
currently the same between the 4 specified WebAssembly constructors. It'll be
easy to implement individual functions on constructed objects as per the
spec, and have each of these files diverge. The error constructors are also
similar, except that their instance derives from ErrorInstance.
- Use constructor macro when initializing the global object.
- Dramatically improve testing of the WebAssembly API by checking for
properties specified in the spec [*].
- Clean up assert.js' exception testing.
- Fix a copy-paste bug in wasm.json: floating-point const return values were
swapped.
[*] https://github.com/WebAssembly/design/blob/master/JS.md
Implement more of the JavaScript WebAssembly API
https://bugs.webkit.org/show_bug.cgi?id=163571
Reviewed by Keith Miller.
* CMakeLists.txt: add .lut.h generation
* DerivedSources.make: ditto
* JavaScriptCore.xcodeproj/project.pbxproj: add .lut.h generation and all the new files
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): use macro to list all constructors
* wasm/WebAssemblyObject.cpp: unboilerplate, all constructors into their own files
* wasm/WebAssemblyObject.h: ditto
* wasm/js/JSWebAssemblyCompileError.cpp: Added.
(JSC::JSWebAssemblyCompileError::create):
(JSC::JSWebAssemblyCompileError::createStructure):
(JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
(JSC::JSWebAssemblyCompileError::finishCreation):
(JSC::JSWebAssemblyCompileError::destroy):
(JSC::JSWebAssemblyCompileError::visitChildren):
* wasm/js/JSWebAssemblyCompileError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyInstance.cpp: Added.
(JSC::JSWebAssemblyInstance::create):
(JSC::JSWebAssemblyInstance::createStructure):
(JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::destroy):
(JSC::JSWebAssemblyInstance::visitChildren):
* wasm/js/JSWebAssemblyInstance.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyMemory.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyMemory::create):
(JSC::JSWebAssemblyMemory::createStructure):
(JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
(JSC::JSWebAssemblyMemory::finishCreation):
(JSC::JSWebAssemblyMemory::destroy):
(JSC::JSWebAssemblyMemory::visitChildren):
* wasm/js/JSWebAssemblyMemory.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyModule.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyModule::create):
(JSC::JSWebAssemblyModule::createStructure):
(JSC::JSWebAssemblyModule::JSWebAssemblyModule):
(JSC::JSWebAssemblyModule::finishCreation):
(JSC::JSWebAssemblyModule::destroy):
(JSC::JSWebAssemblyModule::visitChildren):
* wasm/js/JSWebAssemblyModule.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyRuntimeError.cpp: Added.
(JSC::JSWebAssemblyRuntimeError::create):
(JSC::JSWebAssemblyRuntimeError::createStructure):
(JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
(JSC::JSWebAssemblyRuntimeError::finishCreation):
(JSC::JSWebAssemblyRuntimeError::destroy):
(JSC::JSWebAssemblyRuntimeError::visitChildren):
* wasm/js/JSWebAssemblyRuntimeError.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/JSWebAssemblyTable.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::JSWebAssemblyTable::create):
(JSC::JSWebAssemblyTable::createStructure):
(JSC::JSWebAssemblyTable::JSWebAssemblyTable):
(JSC::JSWebAssemblyTable::finishCreation):
(JSC::JSWebAssemblyTable::destroy):
(JSC::JSWebAssemblyTable::visitChildren):
* wasm/js/JSWebAssemblyTable.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyCompileErrorConstructor.cpp: Added.
(JSC::constructJSWebAssemblyCompileError):
(JSC::callJSWebAssemblyCompileError):
(JSC::WebAssemblyCompileErrorConstructor::create):
(JSC::WebAssemblyCompileErrorConstructor::createStructure):
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
(JSC::WebAssemblyCompileErrorConstructor::WebAssemblyCompileErrorConstructor):
(JSC::WebAssemblyCompileErrorConstructor::getConstructData):
(JSC::WebAssemblyCompileErrorConstructor::getCallData):
(JSC::WebAssemblyCompileErrorConstructor::visitChildren):
* wasm/js/WebAssemblyCompileErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyCompileErrorConstructor::CompileErrorStructure):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyCompileErrorPrototype::create):
(JSC::WebAssemblyCompileErrorPrototype::createStructure):
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
(JSC::WebAssemblyCompileErrorPrototype::WebAssemblyCompileErrorPrototype):
* wasm/js/WebAssemblyCompileErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyInstanceConstructor.cpp: Added.
(JSC::constructJSWebAssemblyInstance):
(JSC::callJSWebAssemblyInstance):
(JSC::WebAssemblyInstanceConstructor::create):
(JSC::WebAssemblyInstanceConstructor::createStructure):
(JSC::WebAssemblyInstanceConstructor::finishCreation):
(JSC::WebAssemblyInstanceConstructor::WebAssemblyInstanceConstructor):
(JSC::WebAssemblyInstanceConstructor::getConstructData):
(JSC::WebAssemblyInstanceConstructor::getCallData):
(JSC::WebAssemblyInstanceConstructor::visitChildren):
* wasm/js/WebAssemblyInstanceConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyInstanceConstructor::InstanceStructure):
* wasm/js/WebAssemblyInstancePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyInstancePrototype::create):
(JSC::WebAssemblyInstancePrototype::createStructure):
(JSC::WebAssemblyInstancePrototype::finishCreation):
(JSC::WebAssemblyInstancePrototype::WebAssemblyInstancePrototype):
* wasm/js/WebAssemblyInstancePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyMemoryConstructor.cpp: Added.
(JSC::constructJSWebAssemblyMemory):
(JSC::callJSWebAssemblyMemory):
(JSC::WebAssemblyMemoryConstructor::create):
(JSC::WebAssemblyMemoryConstructor::createStructure):
(JSC::WebAssemblyMemoryConstructor::finishCreation):
(JSC::WebAssemblyMemoryConstructor::WebAssemblyMemoryConstructor):
(JSC::WebAssemblyMemoryConstructor::getConstructData):
(JSC::WebAssemblyMemoryConstructor::getCallData):
(JSC::WebAssemblyMemoryConstructor::visitChildren):
* wasm/js/WebAssemblyMemoryConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyMemoryConstructor::MemoryStructure):
* wasm/js/WebAssemblyMemoryPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyMemoryPrototype::create):
(JSC::WebAssemblyMemoryPrototype::createStructure):
(JSC::WebAssemblyMemoryPrototype::finishCreation):
(JSC::WebAssemblyMemoryPrototype::WebAssemblyMemoryPrototype):
* wasm/js/WebAssemblyMemoryPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyModuleConstructor.cpp: Added.
(JSC::constructJSWebAssemblyModule):
(JSC::callJSWebAssemblyModule):
(JSC::WebAssemblyModuleConstructor::create):
(JSC::WebAssemblyModuleConstructor::createStructure):
(JSC::WebAssemblyModuleConstructor::finishCreation):
(JSC::WebAssemblyModuleConstructor::WebAssemblyModuleConstructor):
(JSC::WebAssemblyModuleConstructor::getConstructData):
(JSC::WebAssemblyModuleConstructor::getCallData):
(JSC::WebAssemblyModuleConstructor::visitChildren):
* wasm/js/WebAssemblyModuleConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyModuleConstructor::ModuleStructure):
* wasm/js/WebAssemblyModulePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyModulePrototype::create):
(JSC::WebAssemblyModulePrototype::createStructure):
(JSC::WebAssemblyModulePrototype::finishCreation):
(JSC::WebAssemblyModulePrototype::WebAssemblyModulePrototype):
* wasm/js/WebAssemblyModulePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: Added.
(JSC::constructJSWebAssemblyRuntimeError):
(JSC::callJSWebAssemblyRuntimeError):
(JSC::WebAssemblyRuntimeErrorConstructor::create):
(JSC::WebAssemblyRuntimeErrorConstructor::createStructure):
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
(JSC::WebAssemblyRuntimeErrorConstructor::WebAssemblyRuntimeErrorConstructor):
(JSC::WebAssemblyRuntimeErrorConstructor::getConstructData):
(JSC::WebAssemblyRuntimeErrorConstructor::getCallData):
(JSC::WebAssemblyRuntimeErrorConstructor::visitChildren):
* wasm/js/WebAssemblyRuntimeErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyRuntimeErrorConstructor::RuntimeErrorStructure):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyRuntimeErrorPrototype::create):
(JSC::WebAssemblyRuntimeErrorPrototype::createStructure):
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
(JSC::WebAssemblyRuntimeErrorPrototype::WebAssemblyRuntimeErrorPrototype):
* wasm/js/WebAssemblyRuntimeErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
* wasm/js/WebAssemblyTableConstructor.cpp: Added.
(JSC::constructJSWebAssemblyTable):
(JSC::callJSWebAssemblyTable):
(JSC::WebAssemblyTableConstructor::create):
(JSC::WebAssemblyTableConstructor::createStructure):
(JSC::WebAssemblyTableConstructor::finishCreation):
(JSC::WebAssemblyTableConstructor::WebAssemblyTableConstructor):
(JSC::WebAssemblyTableConstructor::getConstructData):
(JSC::WebAssemblyTableConstructor::getCallData):
(JSC::WebAssemblyTableConstructor::visitChildren):
* wasm/js/WebAssemblyTableConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyTableConstructor::TableStructure):
* wasm/js/WebAssemblyTablePrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
(JSC::WebAssemblyTablePrototype::create):
(JSC::WebAssemblyTablePrototype::createStructure):
(JSC::WebAssemblyTablePrototype::finishCreation):
(JSC::WebAssemblyTablePrototype::WebAssemblyTablePrototype):
* wasm/js/WebAssemblyTablePrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyObject.h.
2016-10-19 Caitlin Potter <caitp@igalia.com>
[JSC] forbid "use strict" directive in generator functions with non-simple parameters
https://bugs.webkit.org/show_bug.cgi?id=163683
Reviewed by Geoffrey Garen.
Because generator functions and async functions both have an implicit
inner function whose arguments are inherited from its parent, "use strict"
directives within these functions did not yield a SyntaxError.
Now, the correct syntax error is reported, fixing several test262 failures
for generators and async functions.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionInfo):
2016-10-19 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r207557.
This change caused animations/font-variations tests to time
out on pre-Sierra Macs.
Reverted changeset:
"[macOS] [iOS] Disable variation fonts on macOS El Capitan and
iOS 9"
https://bugs.webkit.org/show_bug.cgi?id=163374
http://trac.webkit.org/changeset/207557
2016-10-19 Filip Pizlo <fpizlo@apple.com>
Baseline JIT should use AutomaticThread
https://bugs.webkit.org/show_bug.cgi?id=163686
Reviewed by Geoffrey Garen.
Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
compiler thread shuts down automatically after inactivity.
With this change, all of JSC's threads shut down automatically. If you run splay for a few
seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
you'll see that the only threads left are the main thread and the bmalloc thread.
* jit/JITWorklist.cpp:
(JSC::JITWorklist::Thread::Thread):
(JSC::JITWorklist::JITWorklist):
(JSC::JITWorklist::completeAllForVM):
(JSC::JITWorklist::poll):
(JSC::JITWorklist::compileLater):
(JSC::JITWorklist::compileNow):
(JSC::JITWorklist::finalizePlans):
(JSC::JITWorklist::runThread): Deleted.
* jit/JITWorklist.h:
2016-10-19 Myles C. Maxfield <mmaxfield@apple.com>
[macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
https://bugs.webkit.org/show_bug.cgi?id=163374
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
2016-10-19 Aaron Chu <aaron_chu@apple.com>
Web Inspector: AXI: expose computed tree node and heading level
https://bugs.webkit.org/show_bug.cgi?id=130825
<rdar://problem/16442349>
Reviewed by Joseph Pecoraro.
Exposing two new accessibility properties: Heading Level and Hierarchical Level.
* inspector/protocol/DOM.json:
2016-10-18 Filip Pizlo <fpizlo@apple.com>
DFG worklist should use AutomaticThread
https://bugs.webkit.org/show_bug.cgi?id=163615
Reviewed by Mark Lam.
AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
threads shut down automatically, too. This has the potential to save a lot of memory.
This required some improvements to AutomaticThread: Worklist likes to be able to keep state
around for the whole lifetime of a thread, and so it likes knowing when threads are born and
when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
that, too.
This looks to be perf-neutral.
* dfg/DFGThreadData.cpp:
(JSC::DFG::ThreadData::ThreadData):
* dfg/DFGThreadData.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
(JSC::DFG::Worklist::Worklist):
(JSC::DFG::Worklist::~Worklist):
(JSC::DFG::Worklist::finishCreation):
(JSC::DFG::Worklist::isActiveForVM):
(JSC::DFG::Worklist::enqueue):
(JSC::DFG::Worklist::compilationState):
(JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
(JSC::DFG::Worklist::removeAllReadyPlansForVM):
(JSC::DFG::Worklist::completeAllReadyPlansForVM):
(JSC::DFG::Worklist::rememberCodeBlocks):
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
(JSC::DFG::Worklist::removeNonCompilingPlansForVM):
(JSC::DFG::Worklist::queueLength):
(JSC::DFG::Worklist::dump):
(JSC::DFG::Worklist::runThread): Deleted.
(JSC::DFG::Worklist::threadFunction): Deleted.
* dfg/DFGWorklist.h:
2016-10-19 Dan Bernstein <mitz@apple.com>
[Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
https://bugs.webkit.org/show_bug.cgi?id=163642
Reviewed by Darin Adler.
* API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
* API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
former to be followed by a method (and we have a property), but not the latter. Changed
a couple of instances of “method” to “@method”. Removed empty @param entries.
* API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
* API/JSContextRefPrivate.h: Ditto.
* API/JSManagedValue.h: Removed empty @param entries.
* API/JSObjectRef.h: Corrected parameter name in @param entry.
* API/JSTypedArray.h: Ditto.
* API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
changed @method to @property where appropriate. Removed empty @param entries.
* API/JSValueRef.h: Named a parameter referenced in a @param entry.
* API/JSWeakObjectMapRefPrivate.h: Ditto.
* Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
treat the icu headers as system headers, to stop it from emitting warnings about headers
we don’t want to change.
* Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
headers.
2016-10-19 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed ARM buildfix after r207475.
* assembler/ARMAssembler.h:
(JSC::ARMAssembler::relinkJumpToNop):
2016-10-18 Mark Lam <mark.lam@apple.com>
Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
https://bugs.webkit.org/show_bug.cgi?id=154377
<rdar://problem/27330808>
Reviewed by Filip Pizlo and Saam Barati.
In a scenario where we cache the __proto__ accessors in global variables, and
later explicitly invoke those accessors as functions, the spec for Function Calls
(see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
ref value is of type Reference, and base of ref is an Environment Record. Then,
it follows that the thisValue should be set to refEnv.WithBaseObject()
(see section 4.b.ii of 12.3.4.1 at
https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
refEnv in this case is the environment record that the cached accessors were
found in i.e. the global object. The WithBaseObject() of the global object is
undefined (see details about WithBaseObject at
https://tc39.github.io/ecma262/#sec-environment-records).
Hence, the __proto__ accessors should see a thisValue of undefined, and throw
TypeErrors. See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
https://tc39.github.io/ecma262/#sec-toobject, and
https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
In JSC's implementation, the callee needs to do a ToThis operation on the
incoming "this" argument in order to get the specified thisValue. The
implementations of the __proto__ accessors were not doing this correctly. This
has now been fixed.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
(JSC::globalFuncProtoSetter):
2016-10-18 Sam Weinig <sam@webkit.org>
Replace std::experimental::variant with WTF::Variant (or similar)
https://bugs.webkit.org/show_bug.cgi?id=163626
Reviewed by Chris Dumez.
Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
into the WTF namespace.
* domjit/DOMJITReg.h:
(JSC::DOMJIT::Reg::gpr):
(JSC::DOMJIT::Reg::fpr):
(JSC::DOMJIT::Reg::jsValueRegs):
2016-10-18 Keith Miller <keith_miller@apple.com>
GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
https://bugs.webkit.org/show_bug.cgi?id=163629
Reviewed by Yusuke Suzuki.
This patch fixes a bug in the DFG when attempt to convert a
GetByVal into a GetById. While converting the GetByVal, during
handleGetById in the Bytecode parser, we would mistakenly use the
opcode length of op_get_by_id rather than op_get_by_val. This causes
the new basic block we create to point to the wrong offset. In the
added test this will cause us to infinite loop.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
2016-10-18 Dean Jackson <dino@apple.com>
Remove CSS_SHAPES feature definition. This should always be on.
https://bugs.webkit.org/show_bug.cgi?id=163628
<rdar://problem/28834613>
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2016-10-18 Michael Saboff <msaboff@apple.com>
Add JSC option to show time spent in each optimization phase
https://bugs.webkit.org/show_bug.cgi?id=163617
Reviewed by Saam Barati.
Added reportDFGPhaseTimes option. This outputs one line per phase similar to
Phase CPS rethreading took 0.2661 ms
One line is output for each phase run.
* dfg/DFGPhase.h:
(JSC::DFG::runAndLog):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-10-18 Filip Pizlo <fpizlo@apple.com>
WTF should make it easier to create threads that die automatically after inactivity
https://bugs.webkit.org/show_bug.cgi?id=163576
Reviewed by Andreas Kling.
Added a sleepSeconds() function, which made it easier for me to test this change.
The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
shut down automatically after 1 second of inactivity. Maybe this will save some memory.
* jsc.cpp:
(GlobalObject::finishCreation):
(functionSleepSeconds):
2016-10-18 Keith Miller <keith_miller@apple.com>
Cleanup Wasm memory.
https://bugs.webkit.org/show_bug.cgi?id=163601
Reviewed by Saam Barati.
There were a couple of issues with the original Wasm memory patch.
This is a follow-up patch to fix those issues.
* wasm/WASMMemory.cpp:
(JSC::WASM::Memory::Memory):
* wasm/WASMMemory.h:
2016-10-15 Filip Pizlo <fpizlo@apple.com>
DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
https://bugs.webkit.org/show_bug.cgi?id=163371
Reviewed by Geoffrey Garen and Saam Barati.
This adds a new kind of call inline cache for when the DFG can prove what the callee
executable is. In those cases, we can skip some of the things that the traditional call IC
would do:
- No need to check who the callee is.
- No need to do arity checks.
This case isn't as simple as just emitting a call instruction since the callee may not be
compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
callee may be jettisoned independently of the caller, so we need to be able to revert the
call to an unlinked state. This means that we need almost all of the things that
CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
teaches it about new "Direct" call types.
The direct non-tail call IC looks like this:
set up arguments
FastPath:
call _SlowPath
lea -FrameSize(%rbp), %rsp
SlowPath:
pop
call operationLinkDirectCall
check exception
jmp FastPath
The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
This means that in steady state, a call is just that: a call. There are no extra branches or
checks.
The direct tail call IC is a bit more complicated because the act of setting up arguments
destroys our frame, which would prevent us from being able to throw an exception if we
failed to compile the callee. So, direct tail call ICs look like this:
jmp _SlowPath
FastPath:
set up arguments
jmp 0 // patch to jump to callee
SlowPath:
silent spill
call operationLinkDirectCall
silent fill
check exception
jmp FastPath
The jmp to the slow path is patched to be a fall-through jmp when we link the call.
Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
AsmBench.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::relinkJumpToNop):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::relinkJumpToNop):
(JSC::ARMv7Assembler::relinkJump): Deleted.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::repatchJumpToNop):
(JSC::AbstractMacroAssembler::repatchJump): Deleted.
* assembler/X86Assembler.h:
(JSC::X86Assembler::relinkJumpToNop):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
(JSC::CallLinkInfo::callReturnLocation):
(JSC::CallLinkInfo::patchableJump):
(JSC::CallLinkInfo::hotPathBegin):
(JSC::CallLinkInfo::slowPathStart):
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
(JSC::CallLinkInfo::callee):
(JSC::CallLinkInfo::setCodeBlock):
(JSC::CallLinkInfo::clearCodeBlock):
(JSC::CallLinkInfo::codeBlock):
(JSC::CallLinkInfo::setLastSeenCallee):
(JSC::CallLinkInfo::clearLastSeenCallee):
(JSC::CallLinkInfo::lastSeenCallee):
(JSC::CallLinkInfo::haveLastSeenCallee):
(JSC::CallLinkInfo::setExecutableDuringCompilation):
(JSC::CallLinkInfo::executable):
(JSC::CallLinkInfo::setMaxNumArguments):
(JSC::CallLinkInfo::visitWeak):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::specializationKindFor):
(JSC::CallLinkInfo::callModeFor):
(JSC::CallLinkInfo::isDirect):
(JSC::CallLinkInfo::nearCallMode):
(JSC::CallLinkInfo::isLinked):
(JSC::CallLinkInfo::setCallLocations):
(JSC::CallLinkInfo::addressOfMaxNumArguments):
(JSC::CallLinkInfo::maxNumArguments):
(JSC::CallLinkInfo::isTailCall): Deleted.
(JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
(JSC::CallLinkInfo::callReturnLocation): Deleted.
(JSC::CallLinkInfo::hotPathBegin): Deleted.
(JSC::CallLinkInfo::callee): Deleted.
(JSC::CallLinkInfo::setLastSeenCallee): Deleted.
(JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
(JSC::CallLinkInfo::lastSeenCallee): Deleted.
(JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeDFGStatuses):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::forEachReg):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::findTerminal):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
(JSC::DFG::ByteCodeParser::handleCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::parameterSlotsForArgCount):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addJSDirectCall):
(JSC::DFG::JITCompiler::addJSDirectTailCall):
(JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
(JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
(JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
(JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
* dfg/DFGNode.cpp:
(JSC::DFG::Node::convertToDirectCall):
* dfg/DFGNode.h:
(JSC::DFG::Node::isTerminal):
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasCellOperand):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForRepeatCall):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITCall.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileSetupVarargsFrame):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::linkDirectFor):
(JSC::revertCall):
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/Executable.cpp:
(JSC::ScriptExecutable::prepareForExecutionImpl):
* runtime/Executable.h:
(JSC::ScriptExecutable::prepareForExecution):
* runtime/Options.h:
2016-10-18 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Not emit exception case if it is not necessary
https://bugs.webkit.org/show_bug.cgi?id=163589
Reviewed by Sam Weinig.
We should not emit exception case if we do not use the slow path calls.
For example, nodeType accessor does not use the slow path calls.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
2016-10-18 Caitlin Potter <caitp@igalia.com>
[JSC] ES6 Method functions should not have prototype
https://bugs.webkit.org/show_bug.cgi?id=162530
Reviewed by Saam Barati.
ECMA-262 only adds "prototype" properties to specific syntactic function forms.
Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
and ArrowFunctions.
For details, see the following spec text, and the difference between GeneratorMethod evaluation and
the evaluation of other MethodDefinition forms.
- https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
- https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
- https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
- https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::callerGetter):
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::deleteProperty):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::makeFunction):
* runtime/Executable.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::deleteProperty):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
https://bugs.webkit.org/show_bug.cgi?id=163586
Reviewed by Saam Barati.
C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
This fixes the debug assertion caused in r207427.
* bytecode/DOMJITAccessCasePatchpointParams.cpp:
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
(JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
* bytecode/DOMJITAccessCasePatchpointParams.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::emitDOMJITGetter):
* jsc.cpp:
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
2016-10-17 Keith Miller <keith_miller@apple.com>
Add support for WASM Memory.
https://bugs.webkit.org/show_bug.cgi?id=161710
Reviewed by Geoffrey Garen.
This patch add initial support for WASM memory operations. First,
it adds the concept of a WASM Module memory management object.
This object currently mmaps a 32-bit address space for WASM use,
although it marks all the memory outside the current breakpoint as
PROT_NONE. For now, we do a range check on each store and load. In
the future, we should change this to be an signal handler that
checks what module the program trapped in.
Additionally, this patch changes the way that our temporary tests
call into WASM code. There is now a true "thunk" that relocates
arguments and calls into WASM. This thunk does not tail call
because we use pinned values to memory base-pointer and
size. We use the new B3 pinned register api to pin the values.
* CMakeLists.txt:
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* testWASM.cpp:
(runWASMTests):
(main):
* wasm/WASMB3IRGenerator.cpp:
(JSC::WASM::createJSWrapper):
(JSC::WASM::parseAndCompile):
* wasm/WASMB3IRGenerator.h:
* wasm/WASMCallingConvention.h:
(JSC::WASM::CallingConvention::iterate):
(JSC::WASM::CallingConvention::setupCall):
(JSC::WASM::nextJSCOffset):
* wasm/WASMFormat.h:
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::parseExpression):
* wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
(JSC::WASM::Memory::Memory):
* wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
(JSC::WASM::Memory::~Memory):
(JSC::WASM::Memory::memory):
(JSC::WASM::Memory::size):
(JSC::WASM::Memory::pinnedRegisters):
(JSC::WASM::Memory::mode):
(JSC::WASM::Memory::growMemory):
(JSC::WASM::Memory::offsetOfSize):
* wasm/WASMModuleParser.cpp:
(JSC::WASM::ModuleParser::parse):
(JSC::WASM::ModuleParser::parseMemory):
* wasm/WASMModuleParser.h:
(JSC::WASM::ModuleParser::functionInformation):
(JSC::WASM::ModuleParser::memory):
* wasm/WASMOps.h:
* wasm/WASMPlan.cpp:
(JSC::WASM::Plan::Plan):
* wasm/WASMPlan.h:
* wasm/WASMSections.h:
2016-10-17 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Add toggles for debugger pauses at console.assert failures
https://bugs.webkit.org/show_bug.cgi?id=139542
<rdar://problem/19281600>
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
Toggle pause on assertions state. Default is disabled,
and disable it when frontends disconnect.
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
Instead of using the PauseOnAllExceptions state, use this
new state specific to assertions.
* inspector/protocol/Debugger.json:
New protocol method to toggle pausing on assertions.
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][JSC] Add Option::useDOMJIT
https://bugs.webkit.org/show_bug.cgi?id=163457
Reviewed by Saam Barati.
Add an option to switch the DOMJIT optimization.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/Options.h:
2016-10-17 Filip Pizlo <fpizlo@apple.com>
Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
https://bugs.webkit.org/show_bug.cgi?id=163548
<rdar://problem/28804381>
Reviewed by Geoffrey Garen.
Before r207408, IRC had a mode where it would silently assign the first assignable register (so
%rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
We reason about interference at instruction boundaries. This means that if you have, for example,
an instruction that clobbers all registers late followed by an instruction that has an early def
in the same register file, then the early def will not be colorable because it interferes with
all registers. This already happens in our tests, but IRC silently returns the first assignable
register to such tmps. For some reason the resulting code works OK - probably because this tends
to only be hit by fuzzing, which may not then stress that code enough to shake out the register
corruption. Also, this can only happen for floating point registers, so it's hard to get an
exciting crash. The worst case is that your numbers get all messed up.
This change fixes the issue:
- IRC will now crash if it can't color a tmp.
- IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
around the interference problem by inserting Nops to pad between those instructions where
conflating their early and late actions into one interference fencepost could create an
uncolorable graph.
See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
problem can arise.
This problem almost made me want to abandon our use of interference at instruction boundaries,
and introduce something more comprehensive, like interference at various stages of an
instruction's execution. The reason why I didn't do this is that this problem only arises in well
confined corner cases: you need an instruction that does a late use or def followed by an
instruction that does an early def. Register clobbers count as defs for this equation.
Fortunately, early defs are rare, and even when they do happen, you still need the previous
instruction to have a late something. Late uses are rare and many instructions don't have defs at
all, which means that it's actually pretty common for an instruction to not have anything late.
This means that the padInterference() strategy is ideal: our algorithms stay simple because they
only have to worry about interference at boundaries, and we rarely insert any Nops in
padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
allocateStack() kills them.
This also finally refactors our passing of RegisterSet to pass it by value, since it's small
enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
smaller than a pointer.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3StackmapSpecial.cpp:
(JSC::B3::StackmapSpecial::extraClobberedRegs):
(JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
* b3/B3StackmapSpecial.h:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
(JSC::B3::Air::CCallSpecial::extraClobberedRegs):
* b3/air/AirCCallSpecial.h:
* b3/air/AirInst.h:
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
* b3/air/AirIteratedRegisterCoalescing.cpp:
(JSC::B3::Air::iteratedRegisterCoalescing):
* b3/air/AirPadInterference.cpp: Added.
(JSC::B3::Air::padInterference):
* b3/air/AirPadInterference.h: Added.
* b3/air/AirSpecial.h:
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* jit/RegisterSet.h:
(JSC::RegisterSet::isEmpty):
2016-10-17 JF Bastien <jfbastien@apple.com>
WebAssembly JS API: implement basic stub
Implement the global WebAssembly JavaScript object, and its constructor +
function properties as described in:
https://github.com/WebAssembly/design/blob/master/JS.md
These don't do anything at the moment, the parent bug will take care of adding
more functionality and associated tests.
WebAssembly JS API: implement basic stub
https://bugs.webkit.org/show_bug.cgi?id=163404
Reviewed by Keith Miller.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
* jsc.cpp: remove useless include
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
* runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
* wasm/WebAssemblyObject.cpp: Added.
(JSC::WebAssemblyObject::create): boilerplate
(JSC::WebAssemblyObject::createStructure): boilerplate
(JSC::WebAssemblyObject::finishCreation): boilerplate
(JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
(JSC::wasmObjectFuncvalidate): auto-throws for now
(JSC::wasmObjectFunccompile): auto-throws for now
* wasm/WebAssemblyObject.h: Added.
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix after r207428
https://bugs.webkit.org/show_bug.cgi?id=163223
Previous build fix r207428 broke all the builds.
* bytecode/PolymorphicAccess.h:
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix for GTK and Windows
https://bugs.webkit.org/show_bug.cgi?id=163223
Attempt to fix build failures in GTK port and Windows port.
* bytecode/PolymorphicAccess.cpp:
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::SpillState::SpillState):
2016-10-17 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Use DOMJIT::Patchpoint in IC
https://bugs.webkit.org/show_bug.cgi?id=163223
Reviewed by Saam Barati.
This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
to emit code and make DOMJIT accessors inlined in IC.
To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
required in DOMJIT::Patchpoint. This system is useful when we create the super-
polymorphic support[1] later. And inlining mechanism is useful even after
introducing super-polymorphic support since it can work even after we fire the
watchpoint for super-polymorphic handling.
This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
[1]: https://bugs.webkit.org/show_bug.cgi?id=163226
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
(JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
(JSC::SlowPathCallGeneratorWithArguments::generateImpl):
(JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
* bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
(JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
(JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::liveRegistersForCall):
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::calleeSaveRegisters):
(JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
(JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
(JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
(JSC::AccessGenerationState::originalExceptionHandler):
(JSC::AccessCase::generateImpl):
(JSC::AccessCase::emitDOMJITGetter):
(JSC::PolymorphicAccess::regenerate):
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::SpillState::isEmpty):
(JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
(JSC::AccessGenerationState::spillStateForJSGetterSetter):
(JSC::AccessGenerationState::liveRegistersForCall): Deleted.
(JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
(JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
* dfg/DFGDOMJITPatchpointParams.cpp:
* dfg/DFGDOMJITPatchpointParams.h:
* domjit/DOMJITPatchpoint.h:
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::addSlowPathCall):
* ftl/FTLDOMJITPatchpointParams.cpp:
* ftl/FTLDOMJITPatchpointParams.h:
* jsc.cpp:
(WTF::DOMJITNode::checkDOMJITNode):
(WTF::DOMJITGetterComplex::DOMJITGetterComplex):
(WTF::DOMJITGetterComplex::createStructure):
(WTF::DOMJITGetterComplex::create):
(WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
(WTF::DOMJITGetterComplex::finishCreation):
(WTF::DOMJITGetterComplex::functionEnableException):
(WTF::DOMJITGetterComplex::customGetter):
(GlobalObject::finishCreation):
(functionCreateDOMJITGetterComplexObject):
2016-10-17 Saam Barati <sbarati@apple.com>
Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
https://bugs.webkit.org/show_bug.cgi?id=163490
Reviewed by Darin Adler.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::Entry):
(JSC::HasOwnPropertyCache::tryAdd):
2016-10-17 Mark Lam <mark.lam@apple.com>
Use the reject() helper function for conditionally throwing TypeErrors.
https://bugs.webkit.org/show_bug.cgi?id=163491
Reviewed by Filip Pizlo.
In some places where we may conditionally throw a TypeError (e.g. when in strict
mode), we already use the reject() helper function to conditionally throw the
TypeError. Doing so makes the code mode compact. This patch applies this idiom
consistently in all places that throws TypeError where appropriate.
This patch also does the following:
1. Make the reject() helper function take an ASCIILiteral instead of a const char*
because we always pass it a literal string anyway.
2. Change the reject helper() to take a ThrowScope&. This allows the thrown
error to be attributed to its caller.
3. When an error message string is instantiated repeatedly in more than 1 place,
create a common copy of that literal string in JSObject.cpp (if one doesn't
already exist) and use that common string in all those places.
4. Since I was auditing call sites of throwTypeError() to check if they should be
using the reject() helper instead, I also fixed those up to pass the error
message as an ASCIILiteral where appropriate.
5. In functions that I touched, change the code to not recompute the VM& when it
is already available.
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ArrayPrototype.cpp:
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncReverse):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::pop):
* runtime/JSArrayBuffer.cpp:
(JSC::JSArrayBuffer::put):
(JSC::JSArrayBuffer::defineOwnProperty):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSDataView.cpp:
(JSC::JSDataView::put):
(JSC::JSDataView::defineOwnProperty):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::setIndex):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::defineOwnProperty):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::defineOwnIndexedProperty):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
(JSC::validateAndApplyPropertyDescriptor):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSProxy.cpp:
(JSC::JSProxy::setPrototype):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::defineOwnProperty):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/Reject.h:
(JSC::reject):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayValueMap::putDirect):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorKeyFor):
2016-10-16 Filip Pizlo <fpizlo@apple.com>
Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
https://bugs.webkit.org/show_bug.cgi?id=163509
Reviewed by Mark Lam.
The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
while working on bug 163371, I hit a crazy corner case where a temporary would have no
interference edges (i.e. no degree). Here's how it happens:
A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
everywhere and interferes with everyone, but has one use like:
Move %ourTmp, %someOtherTmp
Where there are no other tmps live. After spill conversion, this may look like:
Move (ourSpill), %newTmp
Move %newTmp, %someOtherTmp
Of course, we'd rather not get this kind of spill code but it's totally possible because we now
have a bunch of random conditions under which we won't slap the spill address directly into the
Move.
After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
for %newTmp because the Move is coalescable and does not contribute to interference.
Then, we might coalesce %someOtherTmp with %newTmp. Once this happens, if we make the %newTmp be
the master, we're in deep trouble because %newTmp is not on any worklist.
I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
* b3/air/AirIteratedRegisterCoalescing.cpp:
2016-10-15 Mark Lam <mark.lam@apple.com>
Add a $vm.getpid() method.
https://bugs.webkit.org/show_bug.cgi?id=163493
Reviewed by Saam Barati.
This is especially useful when we need to know the pid of an instance of jsc in
the foreground that we're trying to attach a debugger to while the JSC tests are
running in the background with a gazillion other jsc processes live at the same
time.
Currently, $vm.getpid() is only supported on non-Windows platforms.
According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
deprecated. According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
_getpid() cannot be used in applications that execute in the Windows Runtime.
Since this is only a debugging tool and is not a required feature, I'll defer
the Windows implementation of this function till the time when someone actually
needs it.
* tools/JSDollarVMPrototype.cpp:
(JSC::functionGetPID):
(JSC::JSDollarVMPrototype::finishCreation):
2016-10-15 Saam Barati <sbarati@apple.com>
Assertion failed under operationToLowerCase with a rope with zero length
https://bugs.webkit.org/show_bug.cgi?id=163314
Reviewed by Mark Lam.
There are some ways to get JSC to create empty rope strings. ToLowerCase
inside the DFG/FTL goes to the slow path when the argument is a rope.
operationToLowerCase was calling into a WTF string function that
assumed we are passing it a this value that has non-zero length.
However, we were calling it with a string that did have zero length.
To fix this, we make operationToLowerCase return the empty JSString
if it is going to make a string with zero length.
* dfg/DFGOperations.cpp:
* jsc.cpp:
(GlobalObject::finishCreation):
(functionIsRope):
2016-10-14 Benjamin Poulain <bpoulain@apple.com>
[JSC] op_negate should with any type
https://bugs.webkit.org/show_bug.cgi?id=162587
Reviewed by Saam Barati.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
ArithNegate is quite simple. If the input is double, the output
is double. The other cases are set from the LLInt slow case.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
Tweak a bit the IntegerRangeOptimizationPhase when simplifying
ArithAbs to ArithNegate.
We should not do the conversion if the target nodes OSR Exits
on different input than the source node.
In particular, Checked ArithNegate exits on zero while
ArithAbs has not problem with it.
Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
should not either.
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithNegate):
(JSC::DFG::SpeculativeJIT::compileMathIC):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
* jit/JITNegGenerator.cpp:
(JSC::JITNegGenerator::generateFastPath):
* jit/JITOperations.cpp:
Add result profiling in baseline to have types we can use
in DFG and FTL.
2016-10-14 Keith Miller <keith_miller@apple.com>
B3 needs a special WasmAddress Opcode
https://bugs.webkit.org/show_bug.cgi?id=163394
Reviewed by Filip Pizlo.
This patch adds support for WasmAddress. WasmAddress will be used by
Wasm to compute the address of a memory operation from the pinned
base pointer. WasmAddress takes an IntPtr so we can avoid emitting
unnecessary Move32s in Air. This could happen in the following case:
@ptr = Trunc(...)
WasmAddress(@ptr, pinnedGPR)
...
PatchPoint(...) // Do Wasm call
WasmAddress(@ptr, pinnedGPR)
...
In this case we will not be able to CSE the WasmAddresses since the
call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
32-bit value. If Wasm ensures that there there is a leading ZExt32 then
the duplicated moves become unnecessary.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3WasmAddressValue.cpp: Added.
(JSC::B3::WasmAddressValue::~WasmAddressValue):
(JSC::B3::WasmAddressValue::dumpMeta):
(JSC::B3::WasmAddressValue::cloneImpl):
(JSC::B3::WasmAddressValue::WasmAddressValue):
* b3/B3WasmAddressValue.h: Added.
* b3/testb3.cpp:
(JSC::B3::testWasmAddress):
(JSC::B3::run):
2016-10-14 Joseph Pecoraro <pecoraro@apple.com>
test262: @isConstructor incorrectly thinks Math.cos is a constructor
https://bugs.webkit.org/show_bug.cgi?id=163437
Reviewed by Saam Barati.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getConstructData):
By default, Host JSFunctions are not constructable. They get
the default callHostFunctionAsConstructor native constructor.
When getting construct data we can return ConstructType::None
in these cases instead of indicating it might be constructable
and later throwing an exception when construction is attempted.
2016-10-14 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r207322.
This change caused JSC test failures
Reverted changeset:
"Fix Array.prototype.splice ES6 compliance."
https://bugs.webkit.org/show_bug.cgi?id=163372
http://trac.webkit.org/changeset/207322
2016-10-14 Mark Lam <mark.lam@apple.com>
JSON.parse should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163430
Reviewed by Saam Barati.
The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
set values returned by a reviver. The spec for CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the same
defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and is
not configurable or if O is not extensible, [[DefineOwnProperty]] will return
false."
Note: CreateDataProperty() will not throw a TypeError.
Since the properties of frozen objects are not extensible, not configurable, and
not writeable, JSON.parse should fail to write to any frozen objects. Similarly,
JSON.parse should fail to delete properties in frozen objects.
In JSON.parse(), we previously write to array elements using the form of
putDirectIndex() that uses mode PutDirectIndexLikePutDirect. This makes it so
that the write (i.e. put) is always successful. We've now fixed this to use
PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
the array is not writeable.
Also changed Walker::walk() to use the version of methodTable() that takes a VM&
since the VM& is already available.
* runtime/JSONObject.cpp:
(JSC::Walker::walk):
2016-10-14 Joseph Pecoraro <pecoraro@apple.com>
test262: Failure with RegExp.prototype.compile when pattern is undefined
https://bugs.webkit.org/show_bug.cgi?id=163431
Reviewed by Yusuke Suzuki.
If pattern is undefined let P be the empty String.
https://tc39.github.io/ecma262/#sec-regexpinitialize
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
2016-10-13 Joseph Pecoraro <pecoraro@apple.com>
Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
https://bugs.webkit.org/show_bug.cgi?id=163426
Reviewed by Geoffrey Garen.
* bytecompiler/NodesCodegen.cpp:
(JSC::BracketAccessorNode::emitBytecode):
It matters where emitExpressionInfo is called since it gathers
info about where we are in the instruction stream. We need to
emit it before the bytecode that we want to associate the data
with. In this case, before the getById / getByVal.
2016-10-13 Mark Lam <mark.lam@apple.com>
Fix Array.prototype.splice ES6 compliance.
https://bugs.webkit.org/show_bug.cgi?id=163372
Reviewed by Geoffrey Garen and Yusuke Suzuki.
Our Array.prototype.splice implementation neglected to set length on the result
array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
a certain code path. This is now fixed.
I'm deferring the implementation of step 8 till later because it requires more
careful consideration and the fix is of a lesser value (and therefore, of less
urgency). See https://bugs.webkit.org/show_bug.cgi?id=163417
Also added some needed exception checks and assertions.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2016-10-13 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
https://bugs.webkit.org/show_bug.cgi?id=163378
<rdar://problem/28749376>
Reviewed by Saam Barati.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
Since each expression builds on the previous, always keep the starting
location the first location.
2016-10-13 Per Arne Vollan <pvollan@apple.com>
[Win64] Compile fix.
https://bugs.webkit.org/show_bug.cgi?id=163384
Reviewed by Brent Fulgham.
Fix use of potentially uninitialized variable.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2016-10-12 Chris Dumez <cdumez@apple.com>
[Web IDL] Drop support for legacy [ConstructorConditional=*]
https://bugs.webkit.org/show_bug.cgi?id=163368
Reviewed by Ryosuke Niwa.
Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
* Configurations/FeatureDefines.xcconfig:
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: step-into `console.log(o)` should not step through inspector javascript
https://bugs.webkit.org/show_bug.cgi?id=161656
<rdar://problem/28181123>
Reviewed by Timothy Hatcher.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
If the Script is blacklisted skip checking if we need to pause.
(JSC::Debugger::isBlacklisted):
(JSC::Debugger::addToBlacklist):
(JSC::Debugger::clearBlacklist):
Add the ability to add a Script to a blacklist. Currently the blacklist
only prevents pausing in the Script.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::isWebKitInjectedScript):
(Inspector::InspectorDebuggerAgent::didParseSource):
Always add Internal InjectedScripts to the Debugger's blacklist.
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
Clear blacklists when clearing debugger state.
2016-10-12 Keith Miller <keith_miller@apple.com>
B3 needs a special WasmBoundsCheck Opcode
https://bugs.webkit.org/show_bug.cgi?id=163246
Reviewed by Filip Pizlo.
This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
the Int32 pointer value used to be used by the Load. Next is the pinned register. The
pinned register must be pinned by calling proc.setPinned() prior to compiling the
Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
than or equal to the value in the pinnedRegister. Instead of taking a generator for each
value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
Air this patch adds a new Custom opcode, WasmBoundsCheck.
In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::imm):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::setWasmBoundsCheckGenerator):
* b3/B3Procedure.h:
(JSC::B3::Procedure::setWasmBoundsCheckGenerator):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
(JSC::B3::Value::typeFor):
* b3/B3WasmBoundsCheckValue.cpp: Added.
(JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
(JSC::B3::WasmBoundsCheckValue::dumpMeta):
* b3/B3WasmBoundsCheckValue.h: Added.
(JSC::B3::WasmBoundsCheckValue::accepts):
(JSC::B3::WasmBoundsCheckValue::pinnedGPR):
(JSC::B3::WasmBoundsCheckValue::offset):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
(JSC::B3::Air::Code::wasmBoundsCheckGenerator):
* b3/air/AirCustom.cpp:
(JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
* b3/air/AirCustom.h:
(JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
(JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
(JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
(JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
(JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
(JSC::B3::Air::WasmBoundsCheckCustom::generate):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testWasmBoundsCheck):
(JSC::B3::run):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
The blackening of CellState is a bad way of tracking if the object is being marked for the first time
https://bugs.webkit.org/show_bug.cgi?id=163343
Reviewed by Mark Lam.
When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
multiple objects in tandem. But I never ended up using this capability. Still, I liked the
new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
make the object's state reflect whether it was black for the first time or not. That seemed
convenient.
Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
grey it. Then we would forget that we are visiting this object for the first time.
Subsequent visits will think that they are not the first. So, we will fail to do the right
thing in reportExtraMemoryVisited().
So, this reverts that change. This is a little more than just a revert, though. I've changed
the terminology a bit. For example, I got tired of reading Black and having to remind myself
that it really means that the object has begun being visited, instead of the more strict
meaning that implies that it has already been visited. We want to say that it's Black or
currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
black CellState is now called AnthraciteOrBlack.
[1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
* heap/CellState.h:
(JSC::isBlack): Deleted.
(JSC::blacken): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addToRememberedSet):
(JSC::Heap::writeBarrierSlowPath):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::reportExtraMemoryVisited):
(JSC::Heap::reportExternalMemoryVisited):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
* heap/SlotVisitor.h:
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::reportExtraMemoryVisited):
(JSC::SlotVisitor::reportExternalMemoryVisited):
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
2016-10-12 Mark Lam <mark.lam@apple.com>
Rename variables in arrayProtoFuncSplice() to match names in the spec.
https://bugs.webkit.org/show_bug.cgi?id=163354
Reviewed by Saam Barati.
This will make it easier to see whether the code matches the spec or not.
Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2016-10-12 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
https://bugs.webkit.org/show_bug.cgi?id=163245
Reviewed by Filip Pizlo.
We reserve the highest bit of JSC::JSType for extensions outside JSC.
JSC does not use JSType bits so many: only 52 types are defined.
And we extend CallDOM patchpoint to claim that it does not require a global object.
This global object is used to generate a DOM wrapper. However, nodeType does not require
it since it just returns integer. In the future, we will extend CallDOM to claim
its result type. And we can decide this `requireGlobalObject` condition automatically
according to the result type.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCheckDOMPatchpoint):
(JSC::DFG::Node::checkDOMPatchpoint):
(JSC::DFG::Node::hasCallDOMPatchpoint):
(JSC::DFG::Node::callDOMPatchpoint):
(JSC::DFG::Node::hasDOMJIT): Deleted.
(JSC::DFG::Node::domJIT): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
(JSC::DOMJIT::CallDOMPatchpoint::create):
* domjit/DOMJITGetterSetter.h:
* domjit/DOMJITPatchpoint.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jsc.cpp:
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions):
* llint/LowLevelInterpreter.asm:
* runtime/JSType.h:
2016-10-12 Keith Miller <keith_miller@apple.com>
Handle non-function, non-undefined comparator in Array.prototype.sort
https://bugs.webkit.org/show_bug.cgi?id=163085
Reviewed by Yusuke Suzuki.
* builtins/ArrayPrototype.js:
(sort.comparatorSort):
(sort.stringSort):
(sort):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
https://bugs.webkit.org/show_bug.cgi?id=163337
Reviewed by Mark Lam.
It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
built around the idea that we can revisit objects many times. This means that any action that
should only take place once per object must check the object's state. This fixes the snapshot
code to do this.
While writing this code, I realized that we're actually doing this check incorrectly, so I
filed bug 163343. That bug requires a race, so we aren't going to see it yet.
* heap/HeapSnapshot.cpp:
(JSC::HeapSnapshot::finalize):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Improve support for logging Proxy objects in console
https://bugs.webkit.org/show_bug.cgi?id=163323
<rdar://problem/28432553>
Reviewed by Timothy Hatcher.
This is based off of similiar patches in Blink for Proxy handling.
* bindings/ScriptValue.cpp:
(Deprecated::ScriptValue::isEqual):
Use strict equality. This is the intent, and it prevents the possibility of triggering
primitive conversion on objects in previous ConsoleMessage argument lists.
* inspector/InjectedScriptSource.js:
(InjectedScript.prototype._propertyDescriptors):
Bail if the object is a Proxy.
(InjectedScript.prototype._describe):
Provide a friendlier name, "Proxy" instead of "ProxyObject".
(InjectedScript.RemoteObject):
When generating a preview for a Proxy object, generate it from the final target
and mark it as lossy so that the object can always be expanded to get the internal
target/handler properties.
* inspector/JSInjectedScriptHost.h:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
New subtype for Proxy objects.
(Inspector::JSInjectedScriptHost::proxyTargetValue):
Resolve the final target value for a Proxy.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSInjectedScriptHostPrototype::finishCreation):
(Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
Add the new method.
* inspector/ScriptArguments.cpp:
(Inspector::ScriptArguments::getFirstArgumentAsString):
Avoid triggering Proxy traps on a Proxy object when getting a quick
string description for ConsoleMessages.
* inspector/protocol/Runtime.json:
Add new "proxy" subtype.
2016-10-12 Joseph Pecoraro <pecoraro@apple.com>
Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
https://bugs.webkit.org/show_bug.cgi?id=162809
Reviewed by Geoffrey Garen.
Change how BytecodeGeneration emits debug hooks to be more consistent.
Previously most nodes individually generated their own debug hook
and we asserted that it matched a breakpoint location identified
by the parser. This could get out of sync, or nodes could forget to
emit debug hooks expected by the parser.
With this change, we always check and emit a debug hook for any
node. The default behavior is for BytecodeGenerator::emitNode
to emit the debug hook when emitting the node itself. This covers
the majority of cases (statements).
There are a few exceptions where we continue to need to customize
emitting debug hooks:
1. Nodes with emitBytecodeInConditionContext
- non-Expression nodes customize how they emit their children
- constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
- always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
2. Specialized Debug Hooks
- such as hooks for Program start/end, debugger statements, etc.
3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
- such as pausing on the assignment expression inside these loops
The majority of nodes no longer have custom emits.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitNodeInTailPosition):
(JSC::BytecodeGenerator::emitNodeInConditionContext):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitEnumeration):
By default, when emitting a node check if we should also emit an op_debug for it.
This default DebugHook is WillExecuteStatement, which is a normal pause point.
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstantNode::emitBytecodeInConditionContext):
(JSC::LogicalNotNode::emitBytecodeInConditionContext):
(JSC::BinaryOpNode::emitBytecodeInConditionContext):
(JSC::LogicalOpNode::emitBytecodeInConditionContext):
The parser would have generated a pause location for these conditions
no matter what constant folding and re-writing these nodes may perform.
So, when emitting these nodes in condition context check if they need
emit their own debug hook.
(JSC::EmptyStatementNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::DeclarationStatement::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
No longer need to custom emit debug hooks. The default emitNode will handle these.
(JSC::ForInNode::emitBytecode):
Include extra debug hooks the user expects to return back to the assignment
expression in the loop header before starting the body again. The same is done
for for..of with emitEnumeration.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createExportDefaultDeclaration):
(JSC::ASTBuilder::createExportLocalDeclaration):
These are no longer needed to fake-satisfy assertions. We never wanted to
emit debug hooks for these inner statements because the export statement
will already have the debug hooks.
(JSC::ASTBuilder::createForInLoop):
(JSC::ASTBuilder::createForOfLoop):
Include the correct location where the declaration starts.
(JSC::ASTBuilder::breakpointLocation):
Simplify to a general implementation for Node.
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createForInLoop):
(JSC::SyntaxChecker::createForOfLoop):
Ignore the new extra parameter.
* parser/Nodes.h:
(JSC::Node::needsDebugHook):
(JSC::Node::setNeedsDebugHook):
(JSC::ExpressionNode::needsDebugHook): Deleted.
(JSC::ExpressionNode::setNeedsDebugHook): Deleted.
(JSC::StatementNode::isEmptyStatement): Deleted.
(JSC::StatementNode::needsDebugHook): Deleted.
(JSC::StatementNode::setNeedsDebugHook): Deleted.
Move debug hook logic into the base Node class.
(JSC::StatementNode::isDebuggerStatement):
Provide a way to distinguish a debugger statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
Provide the location before the declaration starts.
2016-10-12 Mark Lam <mark.lam@apple.com>
Array.prototype.slice should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163338
Reviewed by Filip Pizlo.
1. The ES6 spec for Array.prototype.slice
(https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
the CreateDataPropertyOrThrow()
(https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
the result array. The spec for CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the
same defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and
is not configurable or if O is not extensible, [[DefineOwnProperty]] will
return false causing this operation to throw a TypeError exception."
2. Array.prototype.slice also uses a Set function
(https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
property and passes true for the Throw argument. Ultimately, it ends up
calling the OrdinarySet function
(https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
property is not writable. This failure should result in a TypeError being
thrown in Set.
Since the properties of frozen objects are not extensible, not configurable,
and not writeable, Array.prototype.slice should fail to write to the result
array if it is frozen.
If the source array being sliced has 1 or more elements, (1) will take effect
when we try to set the element in the non-writeable result obj.
If the source array being sliced has 0 elements, we will not set any elements and
(1) will not trigger. Subsequently, (2) will take effect when we will try to
set the length of the result obj.
* runtime/ArrayPrototype.cpp:
(JSC::putLength):
(JSC::setLength):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
2016-10-12 Filip Pizlo <fpizlo@apple.com>
Remove JITWriteBarrier.h
https://bugs.webkit.org/show_bug.cgi?id=163334
Reviewed by Mark Lam.
I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
bits into machine code, then you better execute a barrier on the code block. But it's a
complicated piece of code, and I can never remember how it quite works. These days it looks
vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
not really necessary to have something like this, since our convention is that any pointer
stored in machine code must always be shadowed in the GC heap. I think that convention has
won by overwhelming majority, so we should finally remove JITWriteBarrier.
A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
which will have to store the callee in the CallLinkInfo but not in the machine code.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AbstractMacroAssembler.h:
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setCallee):
(JSC::CallLinkInfo::clearCallee):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setCallee): Deleted.
(JSC::CallLinkInfo::clearCallee): Deleted.
* heap/SlotVisitor.h:
* jit/JITWriteBarrier.h: Removed.
2016-10-12 Csaba Osztrogonác <ossy@webkit.org>
Unreviewed buildfix for GCC 4.9 after r207186.
https://bugs.webkit.org/show_bug.cgi?id=163255
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::Entry):
2016-10-11 Saam Barati <sbarati@apple.com>
HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
https://bugs.webkit.org/show_bug.cgi?id=163255
Reviewed by Geoffrey Garen.
The cache needs to be responsible for ensuring that things
in the cache stay alive. Before, it wasn't doing this, and
that was wrong.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::Entry::operator=):
(JSC::HasOwnPropertyCache::operator delete):
(JSC::HasOwnPropertyCache::create):
(JSC::HasOwnPropertyCache::get):
(JSC::HasOwnPropertyCache::tryAdd):
(JSC::HasOwnPropertyCache::clear):
(JSC::HasOwnPropertyCache::zeroBuffer):
2016-10-06 Filip Pizlo <fpizlo@apple.com>
MarkedBlock should know what objects are live during marking
https://bugs.webkit.org/show_bug.cgi?id=162309
Reviewed by Geoffrey Garen.
It used to be that we would forget which objects are live the moment we started collection.
That's because the flip at the beginning clears all mark bits.
But we already have a facility for tracking objects that are live-but-not-marked. It's called
newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
newlyAllocated. Then we want to clear all newlyAllocated after GC.
This implements such an approach, along with a versioning optimization for newlyAllocated.
Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
clear.
We could have even avoided allocating newlyAllocated in most cases, since empirically most
blocks are either completely empty or completely full. An earlier version of this patch did
this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
and membuster.
To validate this change, we now run the conservative scan after the beginMarking flip. And it
totally works!
This is a huge step towards concurrent GC. It means that we ought to be able to run the
allocator while marking. Since we already separately made it possible to run the barrier
while marking, this means that we're pretty much ready for some serious concurrency action.
This appears to be perf-neutral and space-neutral.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
* bytecode/CodeBlock.h:
(JSC::CodeBlockSet::mark): Deleted.
* heap/CodeBlockSet.cpp:
(JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
(JSC::CodeBlockSet::clearCurrentlyExecuting):
(JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
* heap/CodeBlockSet.h:
* heap/CodeBlockSetInlines.h: Added.
(JSC::CodeBlockSet::mark):
* heap/ConservativeRoots.cpp:
* heap/Heap.cpp:
(JSC::Heap::markRoots):
(JSC::Heap::beginMarking):
(JSC::Heap::collectImpl):
(JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
(JSC::Heap::clearCurrentlyExecutingCodeBlocks):
* heap/Heap.h:
* heap/HeapUtil.h:
(JSC::HeapUtil::findGCObjectPointersForMarking):
* heap/MarkedAllocator.cpp:
(JSC::MarkedAllocator::isPagedOut):
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::Handle):
(JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
(JSC::MarkedBlock::Handle::stopAllocating):
(JSC::MarkedBlock::Handle::lastChanceToFinalize):
(JSC::MarkedBlock::Handle::resumeAllocating):
(JSC::MarkedBlock::aboutToMarkSlow):
(JSC::MarkedBlock::Handle::resetAllocated):
(JSC::MarkedBlock::resetMarks):
(JSC::MarkedBlock::setNeedsDestruction):
(JSC::MarkedBlock::Handle::didAddToAllocator):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::clearMarks): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::newlyAllocatedVersion):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
(JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::cellsPerBlock):
(JSC::MarkedBlock::Handle::isLive):
(JSC::MarkedBlock::Handle::isLiveCell):
(JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
(JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
(JSC::MarkedBlock::heap):
(JSC::MarkedBlock::space):
(JSC::MarkedBlock::Handle::space):
(JSC::MarkedBlock::resetMarkingVersion): Deleted.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::beginMarking):
(JSC::MarkedSpace::endMarking):
(JSC::MarkedSpace::clearNewlyAllocated): Deleted.
* heap/MarkedSpace.h:
(JSC::MarkedSpace::nextVersion):
(JSC::MarkedSpace::newlyAllocatedVersion):
(JSC::MarkedSpace::markingVersion): Deleted.
* runtime/SamplingProfiler.cpp:
2016-10-11 Mark Lam <mark.lam@apple.com>
Array.prototype.concat should not modify frozen objects.
https://bugs.webkit.org/show_bug.cgi?id=163302
Reviewed by Filip Pizlo.
The ES6 spec for Array.prototype.concat states that it uses the
CreateDataPropertyOrThrow() to add items to the result array. The spec for
CreateDataPropertyOrThrow states:
"This abstract operation creates a property whose attributes are set to the same
defaults used for properties created by the ECMAScript language assignment
operator. Normally, the property will not already exist. If it does exist and is
not configurable or if O is not extensible, [[DefineOwnProperty]] will return
false causing this operation to throw a TypeError exception."
Since the properties of frozen objects are not extensible, not configurable, and
not writable, Array.prototype.concat should fail to write to the result array if
it is frozen.
Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
https://tc39.github.io/ecma262/#sec-createdataproperty.
The fix consists of 2 parts:
1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
putDirectIndex(), and
2. SparseArrayValueMap::putDirect() should check for the case where the property
is read only.
(2) ensures that we don't write into a non-writable property.
(1) ensures that we throw a TypeError for attempts to write to a non-writeable
property.
* runtime/ArrayPrototype.cpp:
(JSC::moveElements):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putDirect):
2016-10-11 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
https://bugs.webkit.org/show_bug.cgi?id=163224
Reviewed by Filip Pizlo.
We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
This global object is necessary to check whether the world is normal before entering
the fast path of looking up the DOM wrapper cache.
We can sometimes constant-fold this GetGlobalObject. For example, if we performed
CheckStructure, the structure can offer the information about the possible result
of GetGlobalObject. By using this constant-folded global object, we can drop some
checks.
This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
constant value, this JSValue is filled with it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGDOMJITPatchpointParams.h:
(JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::at):
(JSC::DOMJIT::PatchpointParams::operator[]):
(JSC::DOMJIT::PatchpointParams::PatchpointParams):
* domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
(JSC::DOMJIT::Value::Value):
(JSC::DOMJIT::Value::isGPR):
(JSC::DOMJIT::Value::isFPR):
(JSC::DOMJIT::Value::isJSValueRegs):
(JSC::DOMJIT::Value::gpr):
(JSC::DOMJIT::Value::fpr):
(JSC::DOMJIT::Value::jsValueRegs):
(JSC::DOMJIT::Value::reg):
(JSC::DOMJIT::Value::value):
* ftl/FTLDOMJITPatchpointParams.h:
(JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2016-10-10 Filip Pizlo <fpizlo@apple.com>
Air should be able to replace constant materializations with adds
https://bugs.webkit.org/show_bug.cgi?id=162749
Reviewed by Yusuke Suzuki.
We have a lot of defenses against emitting code that materializes huge contants. But if we do
end up with such code in the backend, it's better to convert those materializations into add
instructions by checking if other registers are known to contain nearby constants. That's
what this patch does.
* b3/air/AirFixObviousSpills.cpp:
* b3/testb3.cpp:
2016-10-11 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
https://bugs.webkit.org/show_bug.cgi?id=163264
Reviewed by Mark Lam.
When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
case.
It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
to how matching an address and matching a lea have to do very different things. Matching a
lea means creating an instruction that is distinct from other instructions to do multiple
math operations at once. Matching an address means making some instruction do extra work
for free. Also, address matching can take advantage of the fact that the offset is already
associated with the memory operation by strength reduction - lea matching can't do this; it
has to figure out Add(@value, $const) on its own. This change makes the situation slightly
more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
content, since <<32 is such a bizarre outlier. I don't think we even have a path along
which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::scaleForShl):
(JSC::B3::Air::LowerToAir::effectiveAddr):
(JSC::B3::Air::LowerToAir::tryAppendLea):
(JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
* b3/testb3.cpp:
(JSC::B3::testLoadBaseIndexShift2):
(JSC::B3::testLoadBaseIndexShift32):
(JSC::B3::run):
2016-10-11 Saam Barati <sbarati@apple.com>
ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
https://bugs.webkit.org/show_bug.cgi?id=163182
Reviewed by Filip Pizlo.
This code pattern shows up in Dromaeo, so it's worth optimizing for.
This might also show up in real world JS code due to inlining and other
types of constant folding.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::getValue):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
2016-10-10 Zan Dobersek <zdobersek@igalia.com>
Add ENABLE_ENCRYPTED_MEDIA configuration option
https://bugs.webkit.org/show_bug.cgi?id=163219
Reviewed by Darin Adler.
* Configurations/FeatureDefines.xcconfig:
Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
to enable or disable the new EME implementation at build-time.
2016-10-10 Filip Pizlo <fpizlo@apple.com>
B3->Air lowering should be able to emit complex leas on x86
https://bugs.webkit.org/show_bug.cgi?id=163234
Reviewed by Saam Barati.
This adds comprehensive support for emitting lea on x86.
When adding this, I found that it was useful to also finally add more reassociation. That
reduces the amount of patterns that the instruction selector has to deal with.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::lea32):
(JSC::MacroAssembler::lea64):
(JSC::MacroAssembler::lea): Deleted.
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::commitInternal):
(JSC::B3::Air::LowerToAir::tryAppendLea):
(JSC::B3::Air::LowerToAir::lower):
(JSC::B3::Air::LowerToAir::createSelect): Deleted.
* b3/B3ReduceStrength.cpp:
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::isRepresentableAs):
(JSC::B3::Value::representableAs): Deleted.
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp: Lots of tests for lea and reassociation.
2016-10-10 Mark Lam <mark.lam@apple.com>
Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
https://bugs.webkit.org/show_bug.cgi?id=163260
Reviewed by Saam Barati.
In all cases where we call these, we already have the VM& anyway.
* runtime/ArrayPrototype.cpp:
(JSC::putLength):
(JSC::setLength):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
2016-10-10 Mark Lam <mark.lam@apple.com>
Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
https://bugs.webkit.org/show_bug.cgi?id=163239
Reviewed by Filip Pizlo.
This string is also used for reporting the same error in cases which have nothing
to do with strict mode.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/GetterSetter.cpp:
(JSC::callSetter):
* runtime/JSArray.cpp:
(JSC::JSArray::setLengthWithArrayStorage):
(JSC::JSArray::pop):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::putToPrimitiveByIndex):
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::put):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::put):
(JSC::JSModuleNamespaceObject::putByIndex):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::putInlineSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::putInline):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/RegExpObject.h:
(JSC::RegExpObject::setLastIndex):
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::putEntry):
(JSC::SparseArrayEntry::put):
* runtime/StringObject.cpp:
(JSC::StringObject::put):
(JSC::StringObject::putByIndex):
2016-10-10 Saam Barati <sbarati@apple.com>
compileCheckStringIdent in the FTL is wrong
https://bugs.webkit.org/show_bug.cgi?id=163215
Reviewed by Mark Lam and Filip Pizlo.
lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
was treating its return value as the actual JSString. This is wrong.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
2016-10-10 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Implement Node accessors in DOMJIT
https://bugs.webkit.org/show_bug.cgi?id=163005
Reviewed by Filip Pizlo.
Add some helper methods and offsetOfXXX for JSC::Weak since it is used
for DOM wrapper caching.
And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
to avoid the situation that the same register is allocated to child and result.
We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* domjit/DOMJITSlowPathCalls.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* heap/WeakImpl.h:
(JSC::WeakImpl::offsetOfJSValue):
(JSC::WeakImpl::offsetOfWeakHandleOwner):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::boxCell):
(JSC::AssemblyHelpers::boxInt32): Deleted.
* jit/JITOperations.h:
2016-10-09 Filip Pizlo <fpizlo@apple.com>
Air should expose API for pinning registers
https://bugs.webkit.org/show_bug.cgi?id=163175
Reviewed by Keith Miller.
You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
register behave as follows:
- B3 and Air will emit no code that modifies the value in this register, except if that
happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
- B3 and Air will allow others to modify the register. For example, if the register is not
callee-save, then the compiler knows that the register's value will be trashed by any
C-style call.
- Air will be happy to emit code that reads from this register, including coalescing tmps
with it, so longer as there is no interference (i.e. no chance of the register's value
changing). For example, if we went back to having pinned tag registers, we would tell B3
to use them by (1) excluding them from any clobber set (easy, since they're callee save)
and (2) emitting ArgumentReg to grab their value. There's a test that does this.
This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air
already used this API when choosing registers in register allocation. Code now also vends a
mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
a register can be mutated. Doing it this way means that most of this is a purely mechanical
change. The calls to mutableRegs() are the places where we had to change logic:
- The register allocators needs to know that coalescing with a precolored pinned tmp is free.
- The callee-save handler needs to know that we're not supposed to save/restore pinned
registers.
Note that in this scheme, pinned registers are simply registers that do not appear in
regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
vector that excludes some registers. More generally, this means that clients can now tweak
the register allocator's register preferences, since the ordering in that list reflects the
order in which the allocator will try registers.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::pinRegister):
* b3/B3Procedure.h:
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::Code):
(JSC::B3::Air::Code::setRegsInPriorityOrder):
(JSC::B3::Air::Code::pinRegister):
* b3/air/AirCode.h:
(JSC::B3::Air::Code::regsInPriorityOrder):
(JSC::B3::Air::Code::mutableRegs):
(JSC::B3::Air::Code::isPinned):
(JSC::B3::Air::Code::regsInPriorityOrderImpl):
(JSC::B3::Air::Code::proc): Deleted.
* b3/air/AirEmitShuffle.cpp:
(JSC::B3::Air::emitShuffle):
* b3/air/AirEmitShuffle.h:
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirRegisterPriority.cpp: Removed.
* b3/air/AirRegisterPriority.h: Removed.
* b3/air/AirSpillEverything.cpp:
(JSC::B3::Air::spillEverything):
* b3/air/testair.cpp:
(JSC::B3::Air::testShuffleBroadcastAllRegs):
(JSC::B3::Air::testShuffleShiftAllRegs):
(JSC::B3::Air::testShuffleRotateAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs):
(JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
(JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
(JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
(JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
* b3/testb3.cpp:
(JSC::B3::testPinRegisters):
(JSC::B3::run):
* jit/RegisterSet.h:
2016-10-08 Filip Pizlo <fpizlo@apple.com>
B3 should know about mutable pinned registers
https://bugs.webkit.org/show_bug.cgi?id=163172
Reviewed by Keith Miller.
If we have mutable pinned registers then we need to know which operations mutate them. At
first I considered making this into a heap range thing, but I think that this would be very
confusing. Also, in the future, we might want to make Effects track register sets of
clobbered registers (see bug 163173).
* b3/B3Effects.cpp:
(JSC::B3::Effects::interferes):
(JSC::B3::Effects::operator==):
(JSC::B3::Effects::dump):
* b3/B3Effects.h:
(JSC::B3::Effects::forCall):
(JSC::B3::Effects::mustExecute):
2016-10-08 Saam Barati <sbarati@apple.com>
HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
https://bugs.webkit.org/show_bug.cgi?id=159942
<rdar://problem/27328836>
Reviewed by Filip Pizlo.
When HasIndexedProperty has a ForceOSRExit array mode, it should
report to write to side state, like the ForceOSRExit node, and the
other nodes with ForceOSRExit array mode.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2016-10-07 Mark Lam <mark.lam@apple.com>
Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
https://bugs.webkit.org/show_bug.cgi?id=163160
Reviewed by Saam Barati.
See https://tc39.github.io/ecma262/#sec-object.freeze,
https://tc39.github.io/ecma262/#sec-object.seal, and
https://tc39.github.io/ecma262/#sec-setintegritylevel. We need to call
preventExtensions first before proceeding to freeze / seal the object. If
preventExtensions fails, we should throw a TypeError.
* runtime/ObjectConstructor.cpp:
(JSC::setIntegrityLevel):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
2016-10-06 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Support slow path call
https://bugs.webkit.org/show_bug.cgi?id=162978
Reviewed by Saam Barati.
One of the most important features required in DOMJIT::Patchpoint is slow path calls.
DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
At that time, slow path call functionality is necessary.
This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
just use addSlowPathCall.
Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
slow path calls inside DFG and FTL instead of exposing everything.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCommon.h:
* dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::DFG::dispatch):
* dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::extractResult): Deleted.
* domjit/DOMJITPatchpointParams.h:
(JSC::DOMJIT::PatchpointParams::addSlowPathCall):
* domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
* ftl/FTLDOMJITPatchpointParams.cpp: Added.
(JSC::FTL::dispatch):
* ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
(JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
* jit/GPRInfo.h:
(JSC::extractResult):
* jsc.cpp:
2016-10-06 Saam Barati <sbarati@apple.com>
HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
https://bugs.webkit.org/show_bug.cgi?id=163091
Reviewed by Mark Lam.
I'm investigating a real fix for this in:
https://bugs.webkit.org/show_bug.cgi?id=163092
However, it's best to get this out of trunk for now.
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::tryAdd):
2016-10-06 Keith Miller <keith_miller@apple.com>
getInternalObjcObject should validate the JSManagedObject's value.
https://bugs.webkit.org/show_bug.cgi?id=162985
Reviewed by Geoffrey Garen.
Previously, if, for instance, the JSManagedObject's weak value had been
cleared we would call tryUnwrapObjcObject with a nil context and value.
This triggered assertions failures as those functions expect their inputs
to be valid.
* API/JSVirtualMachine.mm:
(getInternalObjcObject):
2016-10-06 Brian Burg <bburg@apple.com>
Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
https://bugs.webkit.org/show_bug.cgi?id=163039
<rdar://problem/28571460>
Reviewed by Timothy Hatcher.
The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
client while on the main thread, then use the cached struct data on the XPC connection queue rather
than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
(Inspector::RemoteInspector::setRemoteInspectorClient):
Re-cache the capabilities. Scope the lock to avoid reentrant locking.
(Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
(Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
(Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
(Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2016-10-06 Yusuke Suzuki <utatane.tea@gmail.com>
[WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
https://bugs.webkit.org/show_bug.cgi?id=163001
Reviewed by Keith Miller.
Previously, the argument of @throwXXXError intrinsics must be string literal.
But it is error-prone restriction. This patch relaxes the restriction to accept
arbitrary values. To keep emitted bytecode small, if the argument is string literal,
we generate the same bytecode as before. If the argument is not string literal,
we evaluate it and perform to_string before passing to throw_static_error.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitThrowStaticError):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add @throwXXXError bytecode intrinsic
https://bugs.webkit.org/show_bug.cgi?id=162995
Reviewed by Saam Barati.
Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
and prevent us from inlining. We should have a way to reduce this size.
Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
* builtins/ArrayConstructor.js:
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/ArrayPrototype.js:
(values):
(keys):
(entries):
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(fill):
(find):
(findIndex):
(includes):
(sort):
(concatSlowPath):
(copyWithin):
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleDateString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* builtins/FunctionPrototype.js:
(bind):
* builtins/GeneratorPrototype.js:
(globalPrivate.generatorResume):
* builtins/GlobalOperations.js:
(globalPrivate.speciesConstructor):
* builtins/MapPrototype.js:
(forEach):
* builtins/ModuleLoaderPrototype.js:
(provide):
* builtins/ObjectConstructor.js:
(values):
(entries):
(assign):
* builtins/PromiseConstructor.js:
(race):
(reject):
(resolve):
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseCapability.executor):
(globalPrivate.newPromiseCapability):
(globalPrivate.initializePromise):
* builtins/PromisePrototype.js:
* builtins/ReflectObject.js:
(apply):
(deleteProperty):
(has):
* builtins/RegExpPrototype.js:
(globalPrivate.regExpExec):
(match):
(replace):
(search):
(split):
(intrinsic.RegExpTestIntrinsic.test):
* builtins/SetPrototype.js:
(forEach):
* builtins/StringConstructor.js:
(raw):
* builtins/StringIteratorPrototype.js:
(next):
* builtins/StringPrototype.js:
(match):
(globalPrivate.repeatSlowPath):
(repeat):
(padStart):
(padEnd):
(intrinsic.StringPrototypeReplaceIntrinsic.replace):
(localeCompare):
(search):
(split):
* builtins/TypedArrayConstructor.js:
(of):
(from):
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArraySpeciesConstructor):
(every):
(find):
(findIndex):
(forEach):
(some):
(subarray):
(reduce):
(reduceRight):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitThrowRangeError):
(JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
(JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_throw_static_error):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_throw_static_error): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Error.cpp:
(JSC::createError):
(WTF::printInternal):
* runtime/Error.h:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, attempt to fix CLoop build after r206846
https://bugs.webkit.org/show_bug.cgi?id=162941
Attempt to fix CLoop build part 2. r206847 was not valid.
* jsc.cpp:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
Unreviewed, build fix after r206846
https://bugs.webkit.org/show_bug.cgi?id=162941
DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
* jsc.cpp:
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Add initial CheckDOM and CallDOM implementations
https://bugs.webkit.org/show_bug.cgi?id=162941
Reviewed by Filip Pizlo.
This patch implements a prototype of DOMJIT accelerated getter.
We add two new DFG nodes, CheckDOM and CallDOM.
CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
JSNode::info().
CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
object. And it returns JSValue as its result.
Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
faster code for such a case.
By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
Notes about the future extensions.
1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
we need to create an abstraction over DFG slow path call and FTL slow path call!
2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
For example, given CheckDOM A and CheckDOM B to the same target. If A is subclass of B, we can merge them to CheckDOM A.
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3Effects.h:
(JSC::B3::Effects::forCheck):
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::makesCalls):
(JSC::GetByIdStatus::dump):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::isCustom):
(JSC::GetByIdStatus::takesSlowPath):
(JSC::GetByIdStatus::isSimple): Deleted.
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromClassInfo):
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::filterClassInfo):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterClassInfo):
* dfg/DFGAbstractValue.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleGetById):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasDOMJIT):
(JSC::DFG::Node::domJIT):
(JSC::DFG::Node::hasClassInfo):
(JSC::DFG::Node::classInfo):
(JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
(JSC::DFG::Node::OpInfoWrapper::operator=):
* dfg/DFGNodeType.h:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::allocateTemporaryRegistersForPatchpoint):
(JSC::DFG::SpeculativeJIT::compileCallDOM):
(JSC::DFG::SpeculativeJIT::compileCheckDOM):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
(JSC::DFG::StructureAbstractValue::isSubClassOf):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::filterClassInfo):
(JSC::DFG::StructureAbstractValue::filter): Deleted.
* domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
(JSC::DOMJIT::PatchpointParams::~PatchpointParams):
(JSC::DOMJIT::PatchpointParams::size):
(JSC::DOMJIT::PatchpointParams::at):
(JSC::DOMJIT::PatchpointParams::operator[]):
(JSC::DOMJIT::PatchpointParams::gpScratch):
(JSC::DOMJIT::PatchpointParams::fpScratch):
(JSC::DOMJIT::PatchpointParams::PatchpointParams):
* domjit/DOMJITReg.h: Added.
(JSC::DOMJIT::Reg::Reg):
(JSC::DOMJIT::Reg::isGPR):
(JSC::DOMJIT::Reg::isFPR):
(JSC::DOMJIT::Reg::isJSValueRegs):
(JSC::DOMJIT::Reg::gpr):
(JSC::DOMJIT::Reg::fpr):
(JSC::DOMJIT::Reg::jsValueRegs):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
* jit/AssemblyHelpers.h:
* jsc.cpp:
(WTF::DOMJITNode::DOMJITNode):
(WTF::DOMJITNode::createStructure):
(WTF::DOMJITNode::create):
(WTF::DOMJITNode::value):
(WTF::DOMJITNode::offsetOfValue):
(WTF::DOMJITGetter::DOMJITGetter):
(WTF::DOMJITGetter::createStructure):
(WTF::DOMJITGetter::create):
(WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
(WTF::DOMJITGetter::domJITNodeGetterSetter):
(WTF::DOMJITGetter::finishCreation):
(WTF::DOMJITGetter::customGetter):
(GlobalObject::finishCreation):
(functionCreateDOMJITNodeObject):
(functionCreateDOMJITGetterObject):
2016-10-05 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
https://bugs.webkit.org/show_bug.cgi?id=162993
Reviewed by Filip Pizlo.
We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
We do not hit this bug before since maybe there is no object that has own custom-accessor and this custom-accessor does not raise an error.
For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
access always raises an error. I guess all the custom accessors follow this pattern. This bug is uncovered when testing DOMJIT (This bug causes crash and
it can occur even if we disabled DOMJIT).
But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByIdStatus::computeFor):
2016-10-05 Saam Barati <sbarati@apple.com>
PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
https://bugs.webkit.org/show_bug.cgi?id=162936
Reviewed by Michael Saboff.
label() may insert nops because of an InvalidationPoint. It does that
because we don't want code that comes after an InvalidationPoint that isn't
effected by the invalidation point to be overwritten if we fire the
InvalidationPoint. PCToCodeOriginMap just grabs labels to build
a mapping, it never emits code that actually jumps to those labels.
Therefore, it should never cause us to emit nops.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2016-10-05 Myles C. Maxfield <mmaxfield@apple.com>
Put variation fonts work behind a compile-time flag
https://bugs.webkit.org/show_bug.cgi?id=162949
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-10-05 Andy VanWagoner <thetalecrafter@gmail.com>
[INTL] Implement Intl.getCanonicalLocales
https://bugs.webkit.org/show_bug.cgi?id=162768
Reviewed by Benjamin Poulain.
Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
Reuse canonicalizeLocaleList and copy the results into a new JSArray.
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
(JSC::intlObjectFuncGetCanonicalLocales):
2016-10-05 Michael Saboff <msaboff@apple.com>
Bad ASSERT in ClonedArguments::createByCopyingFrom()
https://bugs.webkit.org/show_bug.cgi?id=162988
Reviewed by Keith Miller.
Removed bogus assert.
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createByCopyingFrom):
2016-10-05 Zan Dobersek <zdobersek@igalia.com>
Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
https://bugs.webkit.org/show_bug.cgi?id=162903
Reviewed by Alex Christensen.
Rename build guards for the remaining implementation of the legacy EME API
to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
* Configurations/FeatureDefines.xcconfig:
2016-10-05 Csaba Osztrogonác <ossy@webkit.org>
ARM EABI buildfix after r206778
https://bugs.webkit.org/show_bug.cgi?id=162964
Unreviewed trivial fix.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupArgumentsWithExecState):
2016-10-04 Saam Barati <sbarati@apple.com>
String.prototype.toLowerCase should be a DFG/FTL intrinsic
https://bugs.webkit.org/show_bug.cgi?id=162887
Reviewed by Filip Pizlo and Yusuke Suzuki.
This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
path, the intrinsic will loop over an 8-bit string ensuring it's already
lower case, and simply return the string. In the slow path, it'll call
into C code to make a new string.
This is a 7-8% speedup on ES6SampleBench/Basic.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToLowerCase):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
* jit/JITOperations.h:
* runtime/Intrinsic.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2016-10-04 Brian Burg <bburg@apple.com>
Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
https://bugs.webkit.org/show_bug.cgi?id=162810
<rdar://problem/28571460>
Reviewed by Timothy Hatcher.
We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
off of the main thread, because it could cause problems. This happens when we pushListingsNow()
in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
to pushListingsNow(), so this only needs to be changed in the XPC message handler.
* inspector/remote/RemoteInspector.mm:
(Inspector::RemoteInspector::receivedGetListingMessage):
2016-10-04 JF Bastien <jfbastien@apple.com>
WebAssembly: handle a few corner cases
https://bugs.webkit.org/show_bug.cgi?id=162884
Reviewed by Keith Miller.
* wasm/JSWASMModule.cpp: missing include broke cmake build
* wasm/WASMFunctionParser.h:
(JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
(JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
* wasm/WASMOps.h:
(JSC::WASM::isValidOpType): op is valid
* wasm/WASMParser.h:
(JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
(JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
2016-10-04 Yusuke Suzuki <utatane.tea@gmail.com>
REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
https://bugs.webkit.org/show_bug.cgi?id=162937
Reviewed by Saam Barati.
We dropped expression info accidentally at r206777.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallDefineProperty):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ClassExprNode::emitBytecode):
2016-10-04 Yusuke Suzuki <utatane.tea@gmail.com>
[DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
https://bugs.webkit.org/show_bug.cgi?id=162916
Reviewed by Filip Pizlo.
In this patch, we introduce DOMJIT::GetterSetter.
This class maintains information required to emit JIT code in DFG and FTL.
DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
These functions can return a DOMJIT::Patchpoint that allows us to inject
appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
these functions to get a patchpoint. And this patchpoint will be used to
emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
in subsqeunt patch.
We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
and GetByIdStatus along with CustomGetter to teach DFG that this custom access
code has a chance to be inlined with this DOMJIT::GetterSetter information.
Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
and structure transitions.
Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
(JSC::GetByIdVariant::operator=):
(JSC::GetByIdVariant::attemptToMerge):
(JSC::GetByIdVariant::dumpInContext):
* bytecode/GetByIdVariant.h:
(JSC::GetByIdVariant::domJIT):
(JSC::GetByIdVariant::intrinsic): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::get):
(JSC::AccessCase::clone):
* bytecode/PolymorphicAccess.h:
(JSC::AccessCase::domJIT):
(JSC::AccessCase::RareData::RareData):
* dfg/DFGNode.h:
* domjit/DOMJITGetterSetter.h: Added.
(JSC::DOMJIT::GetterSetter::GetterSetter):
(JSC::DOMJIT::GetterSetter::~GetterSetter):
(JSC::DOMJIT::GetterSetter::getter):
(JSC::DOMJIT::GetterSetter::setter):
(JSC::DOMJIT::GetterSetter::thisClassInfo):
* domjit/DOMJITPatchpoint.h: Added.
(JSC::DOMJIT::Patchpoint::create):
(JSC::DOMJIT::Patchpoint::setGenerator):
(JSC::DOMJIT::Patchpoint::generator):
* jit/Repatch.cpp:
(JSC::tryCacheGetByID):
* runtime/CustomGetterSetter.h:
* runtime/JSObject.h:
(JSC::JSObject::fillCustomGetterPropertySlot):
* runtime/Lookup.h:
(JSC::HashTableValue::domJIT):
(JSC::getStaticPropertySlotFromTable):
(JSC::putEntry):
(JSC::reifyStaticProperty):
* runtime/PropertySlot.h:
(JSC::PropertySlot::domJIT):
(JSC::PropertySlot::setCacheableCustom):
2016-09-27 Yusuke Suzuki <utatane.tea@gmail.com>
[JSC] Add a new byte code op_define_property instead of calling defineProperty
https://bugs.webkit.org/show_bug.cgi?id=162108
Reviewed by Saam Barati.
To construct ES6 class, we emitted bytecode that performs the following operations.
1. construct a new object
2. put "configurable", "enumerable" etc. fields
3. call "defineProperty" function
However, this approach has problems. Every time we define a class method, we need to create
a new object to represent property descriptor. This can be removed if we can introduce
a special bytecode or special function.
This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
Instead of taking an object, they takes several registers to avoid object allocations.
We're planning to use this bytecode to implement Object.defineProperty in builtin JS next.
This allows us to leverage object allocation sinking. And it also gives us a chance to use
faster ::get and ::hasProperty in JS.
Originally, I attempted to create one bytecode, op_define_property. However, it takes too many
children in DFG and uses so many registers in DFG. This leads tricky program in 32bit platforms.
Furthermore, it does not fit to the number of x64 argument registers. So instead, we introduce
two bytecodes.
And for op_define_accessor_property, we perform CellUse edge filter to getter and setter children.
This edge filter makes us possible to use SpeculateCellOperand and reduce the number of used registers
in comparison with JSValueOperand. To make children Cells even if we do not specify some accessors (for
example, { get: func, set: null } case), we fill registers with special throwTypeErrorFunction.
The attributes bitset keep information like "This property descriptor only has getter slot".
In these two bytecodes, we take attributes (configurable, enumerable, writable, hasGetter etc.) as
register instead of embedding constant int value because we will use these bytecodes to implement
Object.defineProperty next. In Object.defineProperty case, an attributes are not statically defined
at bytecode compiling time.
Run ES6SampleBench/Air 20 times. The result shows ~2% performance improvement.
Baseline:
firstIteration: 84.05 ms +- 4.37 ms
averageWorstCase: 40.54 ms +- 2.81 ms
steadyState: 3317.49 ms +- 48.25 ms
summary: 223.51 ms +- 5.07 ms
Patched:
firstIteration: 84.46 ms +- 4.22 ms
averageWorstCase: 41.48 ms +- 2.33 ms
steadyState: 3253.48 ms +- 29.31 ms
summary: 224.40 ms +- 4.72 ms
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeList.json:
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeOffset):
(JSC::computeDefsForBytecodeOffset):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
* bytecode/SpecialPointer.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitMoveLinkTimeConstant):
(JSC::BytecodeGenerator::emitCallDefineProperty):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::BitwiseNotNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
(JSC::ObjectPatternNode::bindValue):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
(JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): Deleted.
* jit/CCallHelpers.cpp:
(JSC::CCallHelpers::setupFourStubArgsGPR): Deleted.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupFourStubArgsGPR):
(JSC::CCallHelpers::setupFiveStubArgsGPR):
(JSC::CCallHelpers::setupArgumentsWithExecState):
(JSC::CCallHelpers::setupStubArgsGPR):
(JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_define_data_property):
(JSC::JIT::emit_op_define_accessor_property):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/DefinePropertyAttributes.h: Added.
(JSC::DefinePropertyAttributes::DefinePropertyAttributes):
(JSC::DefinePropertyAttributes::rawRepresentation):
(JSC::DefinePropertyAttributes::hasValue):
(JSC::DefinePropertyAttributes::setValue):
(JSC::DefinePropertyAttributes::hasGet):
(JSC::DefinePropertyAttributes::setGet):
(JSC::DefinePropertyAttributes::hasSet):
(JSC::DefinePropertyAttributes::setSet):
(JSC::DefinePropertyAttributes::writable):
(JSC::DefinePropertyAttributes::configurable):
(JSC::DefinePropertyAttributes::enumerable):
(JSC::DefinePropertyAttributes::setWritable):
(JSC::DefinePropertyAttributes::setConfigurable):
(JSC::DefinePropertyAttributes::setEnumerable):
(JSC::DefinePropertyAttributes::fillWithTriState):
(JSC::DefinePropertyAttributes::extractTriState):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::throwTypeErrorFunction):
(JSC::JSGlobalObject::definePropertyFunction): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::addDefineProperty): Deleted.
* runtime/ObjectConstructor.h:
* runtime/PropertyDescriptor.h:
(JSC::toPropertyDescriptor):
2016-10-04 Saam Barati <sbarati@apple.com>
Follow up fix to GetMapBucket and MapHash speculating on child node types.
To fix this, on 32-bit platforms, we do not speculate on the child
type since we just call into C code for these nodes.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2016-10-03 Saam Barati <sbarati@apple.com>
GetMapBucket node should speculate on the type of its 'key' child
https://bugs.webkit.org/show_bug.cgi?id=161638
Reviewed by Filip Pizlo.
This eliminates type-check branches when we've already
proven the type of the incoming key. Also, it reduces
the branches we emit when type checking the bucket's key.
This is a 2-3% speedup on ES6SampleBench/Basic.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
2016-10-03 Christopher Reid <Christopher.Reid@am.sony.com>
Offline asm should not output masm assembly when using a x86_64 asm backend
https://bugs.webkit.org/show_bug.cgi?id=162705
When cross compiling on windows to Clang, masm was being generated simply because
the os was windows. This change adds a command line parameter --assembler=MASM
to set the output assembly to masm.
The functions isGCC and isCompilingToWindows were removed as they are no longer called.
Reviewed by Mark Lam.
* CMakeLists.txt:
* offlineasm/asm.rb:
* offlineasm/x86.rb:
2016-10-03 JF Bastien <jfbastien@apple.com>
Auto-generate WASMOps.h, share with testing JSON file
https://bugs.webkit.org/show_bug.cgi?id=162870
Reviewed by Keith Miller.
Add a few new opcodes, but keep this mostly as-is for now. I want
to generate smarter code but will do so in a later update to
reduce disruption.
* wasm/WASMOps.h: auto-generated from ./JSTests/stress/wasm/to-c++.js
2016-10-03 Michael Saboff <msaboff@apple.com>
Creating pcToOriginMap in FTL shouldn't insert unnecessary NOPs
https://bugs.webkit.org/show_bug.cgi?id=162879
Reviewed by Filip Pizlo.
If there is a recent watchpoint label, using MacroAssembler::label() will pad
the instruction stream with NOPs to provide space for a jump. This changes
Air::generate() to use labelIgnoringWatchpoints() to create pcToOriginMap
entries to eliminate unneccesary NOPs.
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/testb3.cpp:
(JSC::B3::testPCOriginMapDoesntInsertNops): New test.
(JSC::B3::run):
2016-10-03 Saam Barati <sbarati@apple.com>
MapHash should speculate on the type of its child node
https://bugs.webkit.org/show_bug.cgi?id=161922
Reviewed by Filip Pizlo.
This allows us to remove runtime type checks when we've already
proven the type of the incoming value.
This is a 2-3% speedup on ES6SampleBench/Basic.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::wangsInt64Hash):
(JSC::FTL::DFG::LowerDFGToB3::mapHashString):
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
2016-10-03 Filip Pizlo <fpizlo@apple.com>
B3 trapping memory accesses should be documented
https://bugs.webkit.org/show_bug.cgi?id=162845
Reviewed by Geoffrey Garen.
While writing some documentation, I found some small holes in the code.
* b3/B3Effects.cpp:
(JSC::B3::Effects::operator==): Need this to write tests.
(JSC::B3::Effects::operator!=): Need this to write tests.
* b3/B3Effects.h:
* b3/B3HeapRange.h:
* b3/B3MemoryValue.cpp:
(JSC::B3::MemoryValue::dumpMeta): Sometimes the heap range dump won't show you the memory value's actual range. This makes the dump show you the actual range in that case.
* b3/B3Value.cpp:
(JSC::B3::Value::effects): While documenting this, I remembered that trapping also has to imply reading top. I fixed this.
* b3/testb3.cpp:
(JSC::B3::testTrappingLoad): Added checks for the effects of trapping loads.
(JSC::B3::testTrappingStore): Added checks for the effects of trapping stores.
(JSC::B3::testMoveConstants): Made this not crash with validation.
2016-10-03 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
https://bugs.webkit.org/show_bug.cgi?id=162849
Reviewed by Geoffrey Garen.
Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
function* generatorFunction() { }
generatorFunction.prototype.constructor // undefined
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot):
2016-10-03 Nicolas Breidinger <Nicolas.Breidinger@sony.com>
JSStringRef should define JSChar without platform checks
https://bugs.webkit.org/show_bug.cgi?id=162808
Reviewed by Mark Lam.
* API/JSStringRef.h:
2016-10-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] Align attributes of Generator related properties to spec
https://bugs.webkit.org/show_bug.cgi?id=162839
Reviewed by Saam Barati.
This patch fixes attributes of Generator related properties.
These fixes are covered by test262.
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::finishCreation):
* runtime/GeneratorFunctionConstructor.h:
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.h:
* runtime/GeneratorPrototype.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2016-10-01 Yusuke Suzuki <utatane.tea@gmail.com>
[ES6] GeneratorFunction constructor should instantiate generator function
https://bugs.webkit.org/show_bug.cgi?id=162838
Reviewed by Saam Barati.
GeneratorFunction's constructor should return an instance of JSGeneratorFunction
instead of JSFunction. In this patch, we fix the following 2 things.
1. GeneratorFunction constructor should use JSGeneratorFunction
Previously, we used JSFunction to construct a result. It's wrong. We use JSGeneratorFunction.
2. Pass newTarget into GeneratorFunction constructor to make it subclassible
We did not leverage newTarget when using GeneratorFunction constructor.
Using it correctly to create the subclass Structure and making GeneratorFunction subclassible.
Test262 test covers (1), but (2) is not covered. We add tests that covers both to stress tests.
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::constructGeneratorFunctionConstructor):
* runtime/JSGeneratorFunction.cpp:
(JSC::JSGeneratorFunction::JSGeneratorFunction):
(JSC::JSGeneratorFunction::createImpl):
(JSC::JSGeneratorFunction::create):
(JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
* runtime/JSGeneratorFunction.h:
2016-10-01 Filip Pizlo <fpizlo@apple.com>
Get rid of isMarkedOrNewlyAllocated
https://bugs.webkit.org/show_bug.cgi?id=162842
Reviewed by Dan Bernstein.
This function has become dead code. This change removes it.
* heap/CellContainer.h:
* heap/CellContainerInlines.h:
(JSC::CellContainer::isMarkedOrNewlyAllocated): Deleted.
* heap/LargeAllocation.h:
(JSC::LargeAllocation::isLive):
(JSC::LargeAllocation::isMarkedOrNewlyAllocated): Deleted.
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
(JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
2016-10-01 Joseph Pecoraro <pecoraro@apple.com>
Rename DebugHookID to DebugHookType
https://bugs.webkit.org/show_bug.cgi?id=162820
Reviewed by Alex Christensen.
* bytecode/CodeBlock.cpp:
(JSC::debugHookName):
(JSC::CodeBlock::dumpBytecode):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDebugHook):
* bytecompiler/BytecodeGenerator.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::debug):
* interpreter/Interpreter.h:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping to a line with an autoContinue breakpoint should still pause
https://bugs.webkit.org/show_bug.cgi?id=161712
<rdar://problem/28193970>
Reviewed by Brian Burg.
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
If we stepped to an auto-continue breakpoint we should continue
stepping, not just continue.
2016-09-30 Filip Pizlo <fpizlo@apple.com>
B3 should support trapping memory accesses
https://bugs.webkit.org/show_bug.cgi?id=162689
Reviewed by Geoffrey Garen.
This adds a traps flag to B3::Kind. It also makes B3::Kind work more like Air::Kind, in the
sense that it's a bag of distinct bits - it doesn't need to be a union unless we get enough
things that it would make a difference.
The only analysis that needs to know about traps is effects. It now knows that traps implies
sideExits, which means that this turns off DCE. The only optimization that needs to know
about traps is eliminateCommonSubexpressions(), which needs to pessimize its store
elimination if the store traps.
The hard part of this change is teaching the instruction selector to faithfully carry the
traps flag down to Air. I got this to work by making ArgPromise a non-copyable object that
knows whether you've used it in an instruction. It knows when you call consume(). If you do
this then ArgPromise cannot be destructed without first passing your inst through it. This,
along with a few other hacks, means that all of the load-op and load-op-store fusions
correctly carry the trap bit: if any of the B3 loads or stores involved traps then you get
traps in Air.
This framework also sets us up to do bug 162688, since the ArgPromise::inst() hook is
powerful enough to allow wrapping the instruction with a Patch.
I added some tests to testb3 that verify that optimizations are appropriately inhibited and
that the traps flag survives until the bitter end of Air.
* b3/B3EliminateCommonSubexpressions.cpp:
* b3/B3Kind.cpp:
(JSC::B3::Kind::dump):
* b3/B3Kind.h:
(JSC::B3::Kind::Kind):
(JSC::B3::Kind::hasExtraBits):
(JSC::B3::Kind::isChill):
(JSC::B3::Kind::setIsChill):
(JSC::B3::Kind::hasTraps):
(JSC::B3::Kind::traps):
(JSC::B3::Kind::setTraps):
(JSC::B3::Kind::operator==):
(JSC::B3::Kind::hash):
(JSC::B3::trapping):
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::ArgPromise::swap):
(JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
(JSC::B3::Air::LowerToAir::ArgPromise::operator=):
(JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise):
(JSC::B3::Air::LowerToAir::ArgPromise::setTraps):
(JSC::B3::Air::LowerToAir::ArgPromise::consume):
(JSC::B3::Air::LowerToAir::ArgPromise::inst):
(JSC::B3::Air::LowerToAir::trappingInst):
(JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
(JSC::B3::Air::LowerToAir::appendUnOp):
(JSC::B3::Air::LowerToAir::appendBinOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
(JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
(JSC::B3::Air::LowerToAir::appendStore):
(JSC::B3::Air::LowerToAir::append):
(JSC::B3::Air::LowerToAir::createGenericCompare):
(JSC::B3::Air::LowerToAir::createBranch):
(JSC::B3::Air::LowerToAir::createCompare):
(JSC::B3::Air::LowerToAir::createSelect):
(JSC::B3::Air::LowerToAir::lower):
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects):
* b3/B3Value.h:
* b3/air/AirCode.h:
* b3/testb3.cpp:
(JSC::B3::testTrappingLoad):
(JSC::B3::testTrappingStore):
(JSC::B3::testTrappingLoadAddStore):
(JSC::B3::testTrappingLoadDCE):
(JSC::B3::testTrappingStoreElimination):
(JSC::B3::run):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping over/out of a function sometimes resumes instead of taking you to caller
https://bugs.webkit.org/show_bug.cgi?id=162802
<rdar://problem/28569982>
Reviewed by Mark Lam.
* debugger/Debugger.cpp:
(JSC::Debugger::stepOverStatement):
(JSC::Debugger::stepOutOfFunction):
Enable stepping mode when we start stepping.
2016-09-30 Filip Pizlo <fpizlo@apple.com>
B3::moveConstants should be able to edit code to minimize the number of constants
https://bugs.webkit.org/show_bug.cgi?id=162764
Reviewed by Saam Barati.
There are some interesting cases where we can reduce the number of constant materializations if
we teach moveConstants() how to edit code. The two examples that this patch supports are:
- Loads and stores from a constant pointer. Since loads and stores get an offset for free
and the instruction selector is really good at handling it, and since we can query Air to
see what kinds of offsets are legal, we can sometimes avoid using a constant pointer that
is specific to the absolute address of that load and instead pick some other constant
that is within offset distance of ours.
- Add and Sub by a constant (x + c, x - c). Since x + c = x - -c and x - c = x + -c, we can
flip Add to Sub or vice versa if the negated constant is available.
This change makes moveConstants() pick the most dominant constant that works for an value. In
the case of memory accesses, it uses Air::Arg::isValidAddrForm() to work out what other
constants would work. In the case of Add/Sub, it simply looks for the negated constant. This
should result in something like a minimal number of constants since these rules always pick the
most dominant constant that works - so if an Add's constant is already most dominant then
nothing changes, but if the negated one is more dominant then it becomes a Sub.
This is a 0.5% speed-up on LongSpider and neutral elsewhere. It's a speed-up because the
absolute address thing reduces the number of address materializations that we have to do, while
the add/sub thing prevents us from having to materialize 0x1000000000000 to box doubles.
However, this may introduce a pathology, which I've filed a bug for: bug 162796.
* b3/B3MoveConstants.cpp:
* b3/B3MoveConstants.h:
* b3/B3UseCounts.h:
* b3/air/AirFixObviousSpills.cpp:
* b3/testb3.cpp:
(JSC::B3::testMoveConstants):
(JSC::B3::run):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Fix modules tests after r206653 handle breakpoint locations in import/export statements
https://bugs.webkit.org/show_bug.cgi?id=162807
Reviewed by Mark Lam.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createExportDefaultDeclaration):
(JSC::ASTBuilder::createExportLocalDeclaration):
Don't record an extra breakpoint location for the statement
within an export statement.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseModuleSourceElements):
Record a pause location for import/export statements.
2016-09-30 Mark Lam <mark.lam@apple.com>
Remove the dumping of the stack back trace in VM::verifyExceptionCheckNeedIsSatisfied().
https://bugs.webkit.org/show_bug.cgi?id=162797
Reviewed by Geoffrey Garen.
This is because the RELEASE_ASSERT() that follows immediately after will also
dump the stack back trace. Hence, the first dump will be redundant.
Also removed an extra space in the dataLog output.
* runtime/VM.cpp:
(JSC::VM::verifyExceptionCheckNeedIsSatisfied):
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping through `a(); b(); c();` it is unclear where we are and what is about to execute
https://bugs.webkit.org/show_bug.cgi?id=161658
<rdar://problem/28181254>
Reviewed by Geoffrey Garen.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
Updated pause location for unary expressions.
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Breakpoints on blank lines or comments don't break
https://bugs.webkit.org/show_bug.cgi?id=9885
<rdar://problem/6134406>
Reviewed by Mark Lam.
This change introduces a way to perform a Debugger Parse of a script.
This debugger parse gathers a list of breakpoint locations, which
the backend uses to resolve breakpoint locations that came from the
Inspector frontend to the exact location we would actually pause.
We gather this information from the parser so that we can eagerly
get this information without requiring the code to have executed (the
real op_debugs are generated during bytecode generation when code
is actually evaluated).
If an input location was on a line with whitespace or a comment, the
resolved breakpoint location would be before the next statement that
will be executed. That may be the next line, or even later. We also
update our policy when setting breakpoints on and around function
statements to better match user expectations.
For example, when resolving breakpoints in:
1. // Comment
2. before;
3.
4. function foo() {
5. inside;
6. }
7.
8. after;
A breakpoint on line 1, a comment, resolves to line 2 the next
statement that will execute.
A breakpoint on line 3 or 7, empty lines, resolves to line 8 the next
statement that will execute. This skips past the definition of foo,
just like stepping would have done. The creation of foo would have
been hoisted, which would have happened before execution of the
other statements.
A breakpoint on line 4, a function signature, resolves to line 5,
inside the function. Users would expect to pause inside of a function
when setting a breakpoint on that function's name or opening brace.
A breakpoint on line 6, a function's closing brace, resolves to
line 6. The debugger will pause whenever execution leaves foo due to
a return and not an exception. This matches stepping behavior. An
explicit or implicit return (the implicit return undefined) will
pause on the closing brace as we leave the function, giving users
an opportunity to inspect the final state before leaving.
--
At this point, op_debug's are still emitted at custom locations during
bytecode generation of other statements / expressions. In order to
ensure the generated op_debugs correspond to locations the Parser
determined were breakpoint locations, the Parser sets a "needs debug
hook" flag on the nodes it will use for breakpoint locations, and
we assert during bytecode generation that op_debugs are only emitted
for nodes that were marked as needing debug hooks.
This still leaves open the possibility that the Parser will mark
some nodes that get missed during bytecode generation, so we might
fail to emit some op_debugs. The next step will be eliminating the
custom emitDebugHooks spread across StatementNode and ExpressionNode
subclasses, and instead always generating op_debugs whenever we
emit a flagged node.
--
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
New DebuggerParseData files.
* API/JSScriptRef.cpp:
(OpaqueJSScript::OpaqueJSScript):
* jsc.cpp:
(functionCheckModuleSyntax):
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceType):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
(JSC::SourceProvider::startPosition): Deleted.
Add a new type on SourceProvider to distinguish if its script was
intended to be a Script, Module, or WebAssembly. This information
will be needed to know how to best parse this file when the
debugger decides to lazily parse.
* runtime/Executable.cpp:
(JSC::EvalExecutable::EvalExecutable):
(JSC::ProgramExecutable::ProgramExecutable):
(JSC::ModuleProgramExecutable::ModuleProgramExecutable):
(JSC::WebAssemblyExecutable::WebAssemblyExecutable):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
ASSERT the SourceProvider type matches the executable type we are
creating for it.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::breakpointLocation):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::operatorStackPop):
When gathering breakpoint positions, get the position from the
current node. In the SyntaxChecker, return an invalid position.
* parser/Nodes.h:
(JSC::ExpressionNode::needsDebugHook):
(JSC::ExpressionNode::setNeedsDebugHook):
(JSC::StatementNode::needsDebugHook):
(JSC::StatementNode::setNeedsDebugHook):
When gathering breakpoint positions, mark the node as needing
a debug hook. For now we assert op_debugs generated must come
from these nodes. Later we should just generate op_debugs for
these nodes.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseDoWhileStatement):
(JSC::Parser<LexerType>::parseWhileStatement):
(JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseWithStatement):
(JSC::Parser<LexerType>::parseSwitchStatement):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseIfStatement):
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
(JSC::parse):
Add an optional DebuggerParseData struct to the Parser. When available
the Parser will gather debugger data, and parse all functions with the
ASTBuilder instead of SyntaxChecking inner functions.
* debugger/DebuggerParseData.cpp: Added.
(JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
(JSC::DebuggerPausePositions::sort):
(JSC::gatherDebuggerParseData):
(JSC::gatherDebuggerParseDataForSource):
* debugger/DebuggerParseData.h: Copied from Source/JavaScriptCore/debugger/DebuggerPrimitives.h.
(JSC::DebuggerPausePositions::DebuggerPausePositions):
(JSC::DebuggerPausePositions::appendPause):
(JSC::DebuggerPausePositions::appendEntry):
(JSC::DebuggerPausePositions::appendLeave):
The DebuggerParseData struct currently only contains a list of pause positions.
Once populated it can resolve an input location to a pause position.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
(JSC::BytecodeGenerator::emitDebugHook):
(JSC::BytecodeGenerator::emitEnumeration):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::EmptyStatementNode::emitBytecode):
(JSC::DebuggerStatementNode::emitBytecode):
(JSC::ExprStatementNode::emitBytecode):
(JSC::DeclarationStatement::emitBytecode):
(JSC::IfElseNode::emitBytecode):
(JSC::DoWhileNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::ContinueNode::emitBytecode):
(JSC::BreakNode::emitBytecode):
(JSC::ReturnNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
(JSC::ThrowNode::emitBytecode):
Emit op_debugs for the nodes themselves. Assert when we do that the
Parser had marked them as needing a debug hook.
* debugger/Breakpoint.h:
(JSC::Breakpoint::Breakpoint):
A breakpoint may be resolved or unresolved. Debugger::resolveBreakpoint
must be used to resolve the breakpoint. Most methods now require a
resolved breakpoint.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::detach):
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::debuggerParseData):
(JSC::Debugger::resolveBreakpoint):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::clearParsedData):
Provide a public method to resolve a breakpoint location in a script.
This will gather debugger parse data for the script if none is available.
Ensure clients have resolved a breakpoint before attempting to set it.
Currently we allow only a single breakpoint at a location. This may
need to change if multiple breakpoints resolve to the same location
but have different actions.
* inspector/ScriptDebugListener.h:
ScriptDebugServer::Script is effectively duplicating most of the data from
a SourceProvider. We should eliminate this and just use SourceProvider.
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::setBreakpointActions):
(Inspector::ScriptDebugServer::removeBreakpointActions):
(Inspector::ScriptDebugServer::getActionsForBreakpoint):
(Inspector::ScriptDebugServer::clearBreakpointActions):
(Inspector::ScriptDebugServer::evaluateBreakpointAction):
(Inspector::ScriptDebugServer::dispatchDidParseSource):
(Inspector::ScriptDebugServer::handleBreakpointHit):
(Inspector::ScriptDebugServer::setBreakpoint): Deleted.
(Inspector::ScriptDebugServer::removeBreakpoint): Deleted.
(Inspector::ScriptDebugServer::clearBreakpoints): Deleted.
* inspector/ScriptDebugServer.h:
Reduce ScriptDebugServer's involvement in breakpoints to just handling
breakpoint actions. Eventually we should eliminate it alltogether and
fold breakpoint logic into Debugger or DebugAgent.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::buildDebuggerLocation):
(Inspector::parseLocation):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::didSetBreakpoint):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::didParseSource):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
The Inspector can set breakpoints in multiple ways.
Ensure that once we have the Script that we always
resolve the breakpoint location before setting the
breakpoint. The different paths are:
- setBreakpoint(scriptId, location)
- Here we know the SourceProvider by its SourceID
- resolve and set
- setBreakpointByURL(url, location)
- Search for existing Scripts that match the URL
- resolve in each and set
- When new Scripts are parsed that match the URL
- resolve and set
2016-09-30 Joseph Pecoraro <pecoraro@apple.com>
Web Inspector: Stepping out of a function finishes the line that called it.
https://bugs.webkit.org/show_bug.cgi?id=155325
<rdar://problem/25094578>
Reviewed by Mark Lam.
Also addresses:
<https://webkit.org/b/161721> Web Inspector: Stepping all the way through program should not cause a pause on the next program that executes
<https://webkit.org/b/161716> Web Inspector: Stepping into a function / program should not require stepping to the first statement
This change introduces a new op_debug hook: WillExecuteExpression.
Currently this new hook is only used for pausing at function calls.
We may decide to add it to other places later where pausing with
finer granularity then statements (or lines) if useful.
This updates the location and behavior of some of the existing debug
hooks, to be more consistent and useful if the exact location of the
pause is displayed. For example, in control flow statements like
`if` and `while`, the pause location is the expression itself that
will be evaluated, not the location of the `if` or `while` keyword.
For example:
if (|condition)
while (|condition)
Finally, this change gets rid of some unnecessary / useless pause
locations such as on entering a function and on entering a program.
These pauses are not needed because if there is a statement, we
would pause before the statement and it is equivalent. We continue
to pause when leaving a function via stepping by uniformly jumping
to the closing brace of the function. This gives users a chance
to observe state before leaving the function.
* bytecode/CodeBlock.cpp:
(JSC::debugHookName):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::dumpLineColumnEntry):
Logging strings for the new debug hook.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCallInTailPosition):
(JSC::BytecodeGenerator::emitCallEval):
(JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
(JSC::BytecodeGenerator::emitConstructVarargs):
(JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
(JSC::BytecodeGenerator::emitCallDefineProperty):
(JSC::BytecodeGenerator::emitConstruct):
(JSC::BytecodeGenerator::emitGetTemplateObject):
(JSC::BytecodeGenerator::emitIteratorNext):
(JSC::BytecodeGenerator::emitIteratorNextWithValue):
(JSC::BytecodeGenerator::emitIteratorClose):
(JSC::BytecodeGenerator::emitDelegateYield):
All emitCall variants now take an enum to decide whether or not to
emit the WillExecuteExpression debug hook.
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitCallVarargs):
In the two real implementations, actually decide to emit the debug
hook or not based on the parameter.
(JSC::BytecodeGenerator::emitEnumeration):
This is shared looping code used by for..of iteration of iterables.
When used by ForOfNode, we want to emit a pause location during
iteration.
(JSC::BytecodeGenerator::emitWillLeaveCallFrameDebugHook):
This is shared call frame leave code to emit a consistent pause
location when leaving a function.
* bytecompiler/NodesCodegen.cpp:
(JSC::EvalFunctionCallNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::FunctionCallResolveNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
(JSC::FunctionCallBracketNode::emitBytecode):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::CallFunctionCallDotNode::emitBytecode):
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::TaggedTemplateNode::emitBytecode):
(JSC::ArrayPatternNode::bindValue):
All tail position calls are the function calls that we want to emit
debug hooks for. All non-tail call calls appear to be internal
implementation details, and these should not have the debug hook.
(JSC::IfElseNode::emitBytecode):
(JSC::WhileNode::emitBytecode):
(JSC::WithNode::emitBytecode):
(JSC::SwitchNode::emitBytecode):
Make the pause location consistent at the expression.
(JSC::DoWhileNode::emitBytecode):
Make the pause location consistent at the expression.
Remove the errant pause at the do's '}' when entering the do block.
(JSC::ForNode::emitBytecode):
(JSC::ForInNode::emitMultiLoopBytecode):
(JSC::ForOfNode::emitBytecode):
Make the pause location consistent at expressions.
Also allow stepping to the traditional for loop's
update expression, which was previously not possible.
(JSC::ReturnNode::emitBytecode):
(JSC::FunctionNode::emitBytecode):
Make the pause location when leaving a function consistently be the
function's closing brace. The two cases are stepping through a return
statement, or the implicit return undefined at the end of a function.
(JSC::LabelNode::emitBytecode):
(JSC::TryNode::emitBytecode):
Remove unnecessary pauses that add no value, as they contain a
statement and we will then pause at that statement.
* parser/Nodes.h:
(JSC::StatementNode::isFunctionNode):
(JSC::StatementNode::isForOfNode):
(JSC::EnumerationNode::lexpr):
(JSC::ForOfNode::isForOfNode):
New virtual methods to distinguish different nodes.
* debugger/Debugger.h:
Rename m_pauseAtNextStatement to m_pauseAtNextOpportunity.
This is the finest granularity of stepping, and it can be
pausing at a location that is not a statement.
Introduce state to properly handle step out and stepping
when there are multiple expressions in a statement.
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::setPauseOnNextStatement):
(JSC::Debugger::breakProgram):
(JSC::Debugger::continueProgram):
(JSC::Debugger::stepIntoStatement):
(JSC::Debugger::exception):
(JSC::Debugger::didReachBreakpoint):
Use new variable names, and clarify if we should attempt
to pause or not.
(JSC::Debugger::stepOutOfFunction):
Set a new state to indicate a step out action.
(JSC::Debugger::updateCallFrame):
(JSC::Debugger::updateCallFrameAndPauseIfNeeded): Deleted.
(JSC::Debugger::updateCallFrameInternal):
(JSC::Debugger::pauseIfNeeded):
Allow updateCallFrame to either attempt a pause or not.
(JSC::Debugger::atStatement):
Attempt pause and reset the at first expression flag.
(JSC::Debugger::atExpression):
Attempt a pause when not stepping over. Also skip
the first expression pause, since that would be
equivalent to when we paused for the expression.
(JSC::Debugger::callEvent):
Do not pause when entering a function.
(JSC::Debugger::returnEvent):
Attempt pause when leaving a function.
If the user did a step-over and is leaving the
function, then behave like step-out.
(JSC::Debugger::unwindEvent):
Behave like return except don't change any
pausing states. If we needed to pause the
Debugger::exception will have handled it.
(JSC::Debugger::willExecuteProgram):
Do not pause when entering a program.
(JSC::Debugger::didExecuteProgram):
Attempt pause when leaving a program that has a caller.
This can be useful for exiting an eval(...) program.
Otherwise treat this like return, and step-over out
of the program should behave like step-out. We use
pause at next opportunity because there may be extra
callframes we do not know about.
When the program doesn't have a parent, clear all
our state so we don't errantly pause on the next
JavaScript microtask that gets executed.
(JSC::Debugger::clearNextPauseState):
Helper to clear all of the pause states now that
it happens in a couple places.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
Treat unwinding slightly differently from returning.
We will not want to pause when unwinding callframes.
(JSC::Interpreter::debug):
* interpreter/Interpreter.h:
New debug hook.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepInto):
(Inspector::InspectorDebuggerAgent::didPause):
* inspector/agents/InspectorDebuggerAgent.h:
Remove unnecessary stepInto code notification for listeners.
The listeners are never notified if the debugger resumes,
so whatever state they were setting by this is going to
get out of date.
2016-09-30 Saam Barati <sbarati@apple.com>
Arrow functions should not allow duplicate parameter names
https://bugs.webkit.org/show_bug.cgi?id=162741
Reviewed by Filip Pizlo.
This patch makes parsing arrow function parameters throw
a syntax error when there are duplicate parameter names.
It also starts to make some syntax errors for arrow functions
better, however, this is trickier than it seems since we need
to choose between two parsing productions when we decide to
throw a syntax error. I'm going to work on this problem
in another patch specifically devoted to making the error
messages better for parsing arrow functions:
https://bugs.webkit.org/show_bug.cgi?id=162794
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/Parser.h:
2016-09-30 Mark Lam <mark.lam@apple.com>
Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
https://bugs.webkit.org/show_bug.cgi?id=162793
Reviewed by Saam Barati.
Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
in the determination of whether to skip the re-throw of a simulated throw. This
is needed because the topCallFrame is not updated in operationConstructArityCheck()
(and does not need to be), whereas topVMEntryFrame is always updated properly.
Hence, we should just switch to using the more reliable topVMEntryFrame instead.
This issue was discovered by existing JSC tests when exception check validation
is enabled.
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::~ThrowScope):
2016-09-30 Filip Pizlo <fpizlo@apple.com>
64-bit LLInt needs to have a concurrency-aware barrier
https://bugs.webkit.org/show_bug.cgi?id=162790
Reviewed by Mark Lam.
In a concurrent GC the barrier definitely has to be after the store, not before it.
* llint/LowLevelInterpreter64.asm:
2016-09-29 Filip Pizlo <fpizlo@apple.com>
Air should have a way of expressing additional instruction flags
https://bugs.webkit.org/show_bug.cgi?id=162699
Reviewed by Mark Lam.
This follows a similar change in B3 (r206595) and replaces Air::Opcode with Air::Kind,
which holds onto the opcode and some additional flags. Because Air is an orthogonal ISA
(the opcode tells you what the operation does but each operand is allowed to also contain
effectively instructions for what to do to read or write that operand), the flags are
meant to be orthogonal to opcode. This allows us to say things like Add32<Trap>, which
makes sense if any of the operands to the Add32 are addresses.
To demonstrate the flags facility this partly adds a trap flag to Air. B3 doesn't use it
yet, but I made sure that Air respects it. Basically that means blocking DCE when the flag
is set, by making it imply hasNonArgNonControlEffects.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3CheckSpecial.cpp:
(JSC::B3::Air::numB3Args):
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::dump):
(JSC::B3::CheckSpecial::CheckSpecial):
(JSC::B3::CheckSpecial::hiddenBranch):
(JSC::B3::CheckSpecial::forEachArg):
(JSC::B3::CheckSpecial::generate):
(JSC::B3::CheckSpecial::dumpImpl):
(JSC::B3::CheckSpecial::deepDumpImpl):
* b3/B3CheckSpecial.h:
(JSC::B3::CheckSpecial::Key::Key):
(JSC::B3::CheckSpecial::Key::operator==):
(JSC::B3::CheckSpecial::Key::kind):
(JSC::B3::CheckSpecial::Key::hash):
(JSC::B3::CheckSpecial::Key::opcode): Deleted.
* b3/B3Kind.cpp:
(JSC::B3::Kind::dump):
* b3/air/AirDumpAsJS.cpp:
(JSC::B3::Air::dumpAsJS):
* b3/air/AirFixObviousSpills.cpp:
* b3/air/AirFixPartialRegisterStalls.cpp:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generate):
* b3/air/AirHandleCalleeSaves.cpp:
(JSC::B3::Air::handleCalleeSaves):
* b3/air/AirInst.cpp:
(JSC::B3::Air::Inst::jsHash):
(JSC::B3::Air::Inst::dump):
* b3/air/AirInst.h:
(JSC::B3::Air::Inst::Inst):
(JSC::B3::Air::Inst::kind):
(JSC::B3::Air::Inst::operator bool):
(JSC::B3::Air::Inst::opcode): Deleted.
* b3/air/AirInstInlines.h:
(JSC::B3::Air::Inst::extraClobberedRegs):
(JSC::B3::Air::Inst::extraEarlyClobberedRegs):
(JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
(JSC::B3::Air::Inst::reportUsedRegisters):
(JSC::B3::Air::Inst::shouldTryAliasingDef):
* b3/air/AirIteratedRegisterCoalescing.cpp:
* b3/air/AirKind.cpp: Added.
(JSC::B3::Air::Kind::dump):
* b3/air/AirKind.h: Added.
(JSC::B3::Air::Kind::Kind):
(JSC::B3::Air::Kind::operator==):
(JSC::B3::Air::Kind::operator!=):
(JSC::B3::Air::Kind::hash):
(JSC::B3::Air::Kind::operator bool):
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* b3/air/AirLowerEntrySwitch.cpp:
(JSC::B3::Air::lowerEntrySwitch):
* b3/air/AirLowerMacros.cpp:
(JSC::B3::Air::lowerMacros):
* b3/air/AirOptimizeBlockOrder.cpp:
(JSC::B3::Air::optimizeBlockOrder):
* b3/air/AirReportUsedRegisters.cpp:
(JSC::B3::Air::reportUsedRegisters):
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
* b3/air/AirValidate.cpp:
* b3/air/opcode_generator.rb:
* b3/testb3.cpp:
(JSC::B3::testTernarySubInstructionSelection):
(JSC::B3::testBranchBitAndImmFusion):
2016-09-29 Filip Pizlo <fpizlo@apple.com>
REGRESSION(r206555): It made Dromaeo/jslib-style-jquery.html crash
https://bugs.webkit.org/show_bug.cgi?id=162721
Reviewed by Keith Miller.
The put_by_id-in-put_by_val optimization had the write barrier in the wrong place and
incorrectly filtered on value instead of base.
No reduced test case. You really need to run Dromaeo/jslib to catch it. I love Dromaeo's
ability to catch GC bugs.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutByValWithCachedId):
2016-09-29 Joseph Pecoraro <pecoraro@apple.com>
Arrow functions do not infer name from computed property but normal functions do
https://bugs.webkit.org/show_bug.cgi?id=162720
Reviewed by Saam Barati.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
Set function name on arrow functions as well.
2016-09-29 Joseph Pecoraro <pecoraro@apple.com>
test262: class and function names should be inferred in assignment
https://bugs.webkit.org/show_bug.cgi?id=146262
Reviewed by Saam Barati.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::appendParameter):
(JSC::ASTBuilder::appendArrayPatternEntry):
(JSC::ASTBuilder::appendObjectPatternEntry):
(JSC::ASTBuilder::tryInferFunctionNameInPattern):
Assign names to default value functions and classes in destructuring.
(JSC::ASTBuilder::createAssignResolve):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::makeAssignNode):
Assign names to both normal and arrow functions.
* parser/Nodes.h:
(JSC::ExpressionNode::isBaseFuncExprNode):
Both functions and arrow functions infer name, they both extend
this base so give the base an is check.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
B3 opcodes should leave room for flags
https://bugs.webkit.org/show_bug.cgi?id=162692
Reviewed by Keith Miller.
It used to be that the main thing that determined what a Value did was the opcode. The
Opcode was how you knew what subclass of Value you had. The opcode told you what the Value
actually did. This change replaces Opcode with Kind, which is a tuple of opcode and other
stuff.
Opcodes are great, and that's how most compilers work. But opcodes are one-dimensional. Here
is how this manifests. Say you have an opcode, like Load. You will be happy if your IR has
one Load opcode. But then, you might add Load8S/Load8Z/Load16S/Load16Z opcodes, as we have
done in B3. B3 has one dimension of Load opcodes, which determines something like the C type
of the load. But in the very near future, we will want to add two more dimensions to Loads:
- A flag to say if the load traps.
- A flag to say if the load has acquire semantics.
Mapping these three dimensions (type, trap, acquire) onto the one-dimensional Opcode space
would create mayham: Load8S, Load8STrap, Load8SAcquire, Load8STrapAcquire, Load8Z,
Load8ZTrap, etc.
This happens in other parts of the IR. For example, we have a dimension of arithmetic
operations: add, sub, mul, div, mod, etc. Then we have the chill flag. But since opcodes
are one-dimensional, that means having ChillDiv and ChillMod, and tons of places in the
compiler that case on both Div and ChillDiv, or case on both Mod and ChillMod, since they
are only interested in the kind of arithmetic being done and not the chillness.
Though the examples all involve bits (chill or not, trapping or not, etc), I can imagine
other properties that behave more like small enums, like if we fill out more memory ordering
modes other than just "acquire? yes/no". There will eventually have to be something like a
std::memory_order associated with memory accesses.
One approach to this problem is to have a Value subclass that contains fields with the meta
data. I don't like this for two reasons:
- In bug 162688, I want to make trapping memory accesses have stackmaps. This means that a
trapping memory access would have a different Value subclass than a non-trapping memory
access. So, this meta-data needs to channel into ValueType::accepts(). Currently that
takes Opcode and nothing else.
- Compiler IRs are all about making common tasks easy. If it becomes commonplace for opcodes
to require a custom Value subclass just for a bit then that's not very easy.
This change addresses this problem by making the compiler pass around Kinds rather than
Opcodes. A Kind contains an Opcode as well as any number of opcode-specific bits. This
change demonstrates how Kind should be used by converting chillness to it. Kind has
hasIsChill(), isChill(), and setIsChill() methods. hasIsChill() is true only for Div and
Mod. setIsChill() asserts if !hasIsChill(). If you want to create a Chill Div, you say
chill(Div). IR dumps will print it like this:
Int32 @38 = Div<Chill>(@36, @37, DFG:@24, ControlDependent)
Where "Div<Chill>" is how a Kind that hasExtraBits() dumps itself. If a Kind does not
hasExtraBits() (the normal case) then it dumps like a normal Opcode (without the "<>").
I replaced many uses of Opcode with Kind. New code has to be mindful that Opcode may not be
the right way to summarize what a value does, and so in many cases it's better to carry
around a Kind instead - especially if you will use it to stamp out new Values. Opcode is no
longer sufficient to perform a dynamic Value cast, since that code now uses Kind. ValueKey
now wants a Kind instead of an Opcode. All Value constructors now take Kind instead of
Opcode. But most opcodes don't get any extra Kind bits, and so the code that operates on
those opcodes is largely unchanged.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* b3/B3ArgumentRegValue.h:
* b3/B3CCallValue.h:
* b3/B3CheckValue.cpp:
(JSC::B3::CheckValue::convertToAdd):
(JSC::B3::CheckValue::CheckValue):
* b3/B3CheckValue.h:
(JSC::B3::CheckValue::accepts):
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.h:
* b3/B3FenceValue.h:
* b3/B3Kind.cpp: Added.
(JSC::B3::Kind::dump):
* b3/B3Kind.h: Added.
(JSC::B3::Kind::Kind):
(JSC::B3::Kind::opcode):
(JSC::B3::Kind::setOpcode):
(JSC::B3::Kind::hasExtraBits):
(JSC::B3::Kind::hasIsChill):
(JSC::B3::Kind::isChill):
(JSC::B3::Kind::setIsChill):
(JSC::B3::Kind::operator==):
(JSC::B3::Kind::operator!=):
(JSC::B3::Kind::hash):
(JSC::B3::Kind::isHashTableDeletedValue):
(JSC::B3::chill):
(JSC::B3::KindHash::hash):
(JSC::B3::KindHash::equal):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/B3MemoryValue.h:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3PatchpointValue.h:
(JSC::B3::PatchpointValue::accepts):
* b3/B3ReduceStrength.cpp:
* b3/B3SlotBaseValue.h:
* b3/B3StackmapValue.cpp:
(JSC::B3::StackmapValue::StackmapValue):
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.h:
(JSC::B3::SwitchValue::accepts):
* b3/B3UpsilonValue.h:
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::dump):
(JSC::B3::Value::deepDump):
(JSC::B3::Value::invertedCompare):
(JSC::B3::Value::effects):
(JSC::B3::Value::key):
(JSC::B3::Value::typeFor):
(JSC::B3::Value::badKind):
(JSC::B3::Value::badOpcode): Deleted.
* b3/B3Value.h:
* b3/B3ValueInlines.h:
(JSC::B3::Value::as):
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::dump):
(JSC::B3::ValueKey::materialize):
* b3/B3ValueKey.h:
(JSC::B3::ValueKey::ValueKey):
(JSC::B3::ValueKey::kind):
(JSC::B3::ValueKey::opcode):
(JSC::B3::ValueKey::operator==):
(JSC::B3::ValueKey::hash):
* b3/B3ValueKeyInlines.h:
(JSC::B3::ValueKey::ValueKey):
* b3/B3VariableValue.cpp:
(JSC::B3::VariableValue::VariableValue):
* b3/B3VariableValue.h:
* b3/testb3.cpp:
(JSC::B3::testChillDiv):
(JSC::B3::testChillDivTwice):
(JSC::B3::testChillDiv64):
(JSC::B3::testChillModArg):
(JSC::B3::testChillModArgs):
(JSC::B3::testChillModImms):
(JSC::B3::testChillModArg32):
(JSC::B3::testChillModArgs32):
(JSC::B3::testChillModImms32):
(JSC::B3::testSwitchChillDiv):
(JSC::B3::testEntrySwitchWithCommonPaths):
(JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::chillDiv):
(JSC::FTL::Output::chillMod):
2016-09-29 Saam Barati <sbarati@apple.com>
We don't properly propagate non-simple-parameter-list when parsing a setter
https://bugs.webkit.org/show_bug.cgi?id=160483
Reviewed by Joseph Pecoraro.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseFunctionParameters):
2016-09-28 Saam Barati <sbarati@apple.com>
stringProtoFuncRepeatCharacter will return `null` when it should not
https://bugs.webkit.org/show_bug.cgi?id=161944
Reviewed by Yusuke Suzuki.
stringProtoFuncRepeatCharacter was expecting its second argument
to always be a boxed integer. This is not correct. The DFG may decide
to represent a particular value as a double instead of integer. This
function needs to have correct behavior when its second argument is
a boxed double. I also added an assertion stating that the second argument
is always a number. We can guarantee this since it's only called from
builtins.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncRepeatCharacter):
2016-09-28 Filip Pizlo <fpizlo@apple.com>
The write barrier should be down with TSO
https://bugs.webkit.org/show_bug.cgi?id=162316
Reviewed by Geoffrey Garen.
This makes our write barrier behave correctly when it races with the collector. The
collector wants to do this when visiting:
object->cellState = black
visit(object)
The mutator wants to do this when storing:
object->property = newValue
if (object->cellState == black)
remember(object)
Prior to this change, this didn't work right because the compiler would sometimes place
barriers before the store to the property and because the mutator did not have adequate
fences.
Prior to this change, the DFG and FTL would emit this:
if (object->cellState == black)
remember(object)
object->property = newValue
Which is wrong, because the object could start being scanned just after the cellState
check, at which point the store would be lost. We need to confirm that the state was not
black *after* the store! This change was harder than you'd expect: placing the barrier
after the store broke B3's ability to do its super crazy ninja CSE on some store-load
redundancies. Because the B3 CSE has some moves that the DFG CSE lacks, the DFG CSE's
ability to ignore barriers didn't help. I fixed this by having the FTL convey precise
heap ranges for the patchpoint corresponding to the barrier slow path. It reads the world
(because of the store-load fence) and it writes only cellState (because the B3 heap ranges
don't have any way to represent any of the GC's other state, which means that B3 does not
have to worry about aliasing with any of that).
The collector already uses a store-load fence on x86 just after setting the cellState and
before visiting the object. The mutator needs to do the same. But we cannot put a
store-load fence of any kind before store barriers, because that causes enormous slow
downs. In the worst case, Octane/richards slowed down by 90%! That's crazy! However, the
overall slow downs were small enough (0-15% on benchmark suite aggregates) that it would be
reasonable if the slow down only happened while the GC was running. Then, the concurrent GC
would lift throughput-while-collecting from 0% of peak to 85% of peak. This changes the
barrier so that it looks like this:
if (object->cellState <= heap.sneakyBlackThreshold)
slowPath(object)
Where sneakyBlackThreshold is the normal blackThreshold when we're not collecting, or a
tautoligical threshold (that makes everything look black) when we are collecting. This
turns out to not be any more expensive than the barrier in tip of tree when the GC is not
running, or a 0-15% slow-down when it is "running". (Of course we don't run the GC
concurrently yet. I still have more work to do.) The slowPath() does some extra work to
check if we are concurrently collecting; if so, it does a fence and rechecks if the object
really did need that barrier.
This also reintroduces elimination of redundant store barriers, which was lost in the last
store barrier change. We can only do it when there is no possibility of GC, exit, or
exceptions between the two store barriers. We could remove the exit/exception limitation if
we taught OSR exit how to buffer store barriers, which is an insane thing to do considering
that I've never been able to detect a win from redundant store barrier elimination. I just
want us to have it for stupidly obvious situations, like a tight sequence of stores to the
same object. This same optimization also sometimes strength-reduces the store barrier so
that it uses a constant black threshold rather than the sneaky one, thereby saving one
load.
Even with all of those optimizations, I still had problems with barrier cost. I found that one
of the benchmarks that was being hit particularly hard was JetStream/regexp-2010. Fortunately
that benchmark does most of its barriers in a tight C++ loop in RegExpMatchesArray.h. When we
know what we're doing, we can defer GC around a bunch of object initializations and then remove
all of the barriers between any of the objects allocated within the deferral. Unfortunately,
our GC deferral mechanism isn't really performant enough to make this be a worthwhile
optimization. The most efficient version of such an optimization that I could come up with was
to have a DeferralContext object that houses a boolean that is false by default, but the GC
writes true into it if it would have wanted to GC. You thread a pointer to the deferralContext
through all of your allocations. This kind of mechanism has the overhead of a zero
initialization on the stack on entry and a zero check on exit. This is probably even efficient
enough that we could start thinking about having the DFG use it, for example if we found a
bounded-time section of code with a lot of barriers and entry/exit sites that aren't totally
wacky. This optimization took this patch from 0.68% JetStream regressed to neutral, according
to my latest data.
Finally, an earlier version of this change put the store-load fence in B3 IR, so I ended up
adding FTLOutput support for it and AbstractHeapRepository magic for decorating the heaps.
I think we might as well keep that, it'll be useful.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::branch32):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::branch32):
(JSC::MacroAssemblerX86_64::branch64): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::isStoreBarrier):
* dfg/DFGNodeType.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
(JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
(JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
* dfg/DFGStoreBarrierClusteringPhase.cpp: Added.
(JSC::DFG::performStoreBarrierClustering):
* dfg/DFGStoreBarrierClusteringPhase.h: Added.
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGStoreBarrierInsertionPhase.h:
* ftl/FTLAbstractHeap.h:
(JSC::FTL::AbsoluteAbstractHeap::at):
(JSC::FTL::AbsoluteAbstractHeap::operator[]):
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::decorateFenceRead):
(JSC::FTL::AbstractHeapRepository::decorateFenceWrite):
(JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileStoreBarrier):
(JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
(JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::fence):
(JSC::FTL::Output::absolute):
* ftl/FTLOutput.h:
* heap/CellState.h:
(JSC::isWithinThreshold):
(JSC::isBlack):
* heap/Heap.cpp:
(JSC::Heap::writeBarrierSlowPath):
* heap/Heap.h:
(JSC::Heap::barrierShouldBeFenced):
(JSC::Heap::addressOfBarrierShouldBeFenced):
(JSC::Heap::sneakyBlackThreshold):
(JSC::Heap::addressOfSneakyBlackThreshold):
* heap/HeapInlines.h:
(JSC::Heap::writeBarrier):
(JSC::Heap::writeBarrierWithoutFence):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEdenWithoutFence):
(JSC::AssemblyHelpers::sneakyJumpIfIsRememberedOrInEden):
(JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
(JSC::AssemblyHelpers::storeBarrierStoreLoadFence):
(JSC::AssemblyHelpers::jumpIfStoreBarrierStoreLoadFenceNotNeeded):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitWriteBarrier):
(JSC::JIT::privateCompilePutByVal):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_by_id):
* llint/LowLevelInterpreter.asm:
* offlineasm/x86.rb:
* runtime/Options.h:
2016-09-27 Joseph Pecoraro <pecoraro@apple.com>
Improve useCodeCache Option description string.
* runtime/Options.h:
Address late review comments and clarify description.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
Optimize B3->Air lowering of Fence on ARM
https://bugs.webkit.org/show_bug.cgi?id=162342
Reviewed by Geoffrey Garen.
This gives us comprehensive support for standalone fences on x86 and ARM. The changes are as
follows:
- Sets in stone the rule that the heaps of a B3::Fence tell you what the fence protects. If the
fence reads, it protects motion of stores. If the fence writes, it protects motion of loads.
This allows us to express for example load-load fences in a portable way: on x86 they will just
block B3 optimizations and emit no code, while on ARM you will get some fence.
- Adds comprehensive support for WTF-style fences in the ARM assembler. I simplified it just a bit
to match what B3, the main client, knows. There are three fences: MemoryFence, StoreFence, and
LoadFence. On x86, MemoryFence is ortop while StoreFence and LoadFence emit no code. On ARM64,
MemoryFence and LoadFence are dmb ish while StoreFence is dmb ishst.
- Tests! To test this, I needed to teach the disassembler how to disassemble dmb ish and dmb
ishst. I think that the canonical way to do it would be to create a group for dmb and then teach
that group how to decode the operands. But I don't actually know what are all of the ways of
encoding dmb, so I'd rather that unrecognized encodings fall through to the ".long blah"
bailout. So, this creates explicit matching rules for "dmb ish" and "dmb ishst", which is the
most conservative thing we can do.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::dmbISH):
(JSC::ARM64Assembler::dmbISHST):
(JSC::ARM64Assembler::dmbSY): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::memoryFence):
(JSC::MacroAssemblerARM64::storeFence):
(JSC::MacroAssemblerARM64::loadFence):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::storeFence):
(JSC::MacroAssemblerX86Common::loadFence):
* b3/B3FenceValue.h:
* b3/B3LowerToAir.cpp:
(JSC::B3::Air::LowerToAir::lower):
* b3/air/AirOpcode.opcodes:
* b3/testb3.cpp:
(JSC::B3::testMemoryFence):
(JSC::B3::testStoreFence):
(JSC::B3::testLoadFence):
(JSC::B3::run):
(JSC::B3::testX86MFence): Deleted.
(JSC::B3::testX86CompilerFence): Deleted.
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format):
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName):
(JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName):
2016-09-28 Joseph Pecoraro <pecoraro@apple.com>
Adopt #pragma once in some generated resources
https://bugs.webkit.org/show_bug.cgi?id=162666
Reviewed by Alex Christensen.
* Scripts/builtins/builtins_generate_combined_header.py:
* Scripts/builtins/builtins_generate_internals_wrapper_header.py:
* Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
* Scripts/builtins/builtins_generate_separate_header.py:
* Scripts/builtins/builtins_generate_wrapper_header.py:
* Scripts/builtins/builtins_generate_wrapper_implementation.py:
Remove headerGuard attribute unused by templates.
* Scripts/tests/builtins/expected/JavaScriptCore-Operations.Promise-Combined.js-result: Removed.
No such test exists. It was likely renamed.
* generate-bytecode-files:
Simplify header guard output.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator.generate_output):
* replay/scripts/CodeGeneratorReplayInputs.py:
(Generator.generate_header):
* replay/scripts/CodeGeneratorReplayInputsTemplates.py:
Simplify header guard output.
* replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
* replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
Rebaseline.
2016-09-28 Filip Pizlo <fpizlo@apple.com>
Store-load fences should be a lot cheaper on ARM
https://bugs.webkit.org/show_bug.cgi?id=162461
Rubber stamped by Keith Miller.
It turns out that they are already cheap enough, so this change just make us use them.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::visitChildren):
2016-09-28 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, rolling out r206522.
Roll r206506 back in since the build fix landed in r206521
Reverted changeset:
"Unreviewed, rolling out r206506."
https://bugs.webkit.org/show_bug.cgi?id=162682
http://trac.webkit.org/changeset/206522
2016-09-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r206506.
https://bugs.webkit.org/show_bug.cgi?id=162682
Broke the Windows and WinCairo builds. (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"Adopt #pragma once in JavaScriptCore"
https://bugs.webkit.org/show_bug.cgi?id=162664
http://trac.webkit.org/changeset/206506
2016-09-28 Joseph Pecoraro <pecoraro@apple.com>
Adopt #pragma once in JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=162664
Reviewed by Saam Barati.
* **/**.h:
Adopt pragma once in all but API headers and generated headers.
Include some namespace closing comments for consistency.
2016-09-27 JF Bastien <jfbastien@apple.com>
Missing Atomics.h include in MarkedBlock.h
https://bugs.webkit.org/show_bug.cgi?id=162648
Missing include from my previous patch.
Reviewed by Yusuke Suzuki.
* heap/MarkedBlock.h:
2016-09-27 Mark Lam <mark.lam@apple.com>
createError() and JSObject::calculatedClassName() should not throw any exceptions.
https://bugs.webkit.org/show_bug.cgi?id=162637
Reviewed by Geoffrey Garen.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
- assert that errorDescriptionForValue() did not throw an exception.
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
- the code already ensures that we always return a non-null String. Just need to
make sure that it catches its own exceptions.
2016-09-27 Filip Pizlo <fpizlo@apple.com>
B3::lowerMacros forgets to before->updatePredecessorsAfter() when lowering ChillMod on ARM64
https://bugs.webkit.org/show_bug.cgi?id=162644
Reviewed by Keith Miller.
If you forget to update the predecessors of your successors, then bad things will happen if you
do something that requires accurate predecessors for correctness. lowerMacros() uses
BlockInsertionSet, which relies on accurate predecessors.
* b3/B3LowerMacros.cpp:
2016-09-27 JF Bastien <jfbastien@apple.com>
Speed up Heap::isMarkedConcurrently
https://bugs.webkit.org/show_bug.cgi?id=162095
Reviewed by Filip Pizlo.
Speed up isMarkedConcurrently by using WTF::consumeLoad.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::areMarksStale):
(JSC::MarkedBlock::areMarksStaleWithDependency):
(JSC::MarkedBlock::isMarkedConcurrently): do away with the load-load fence
2016-09-27 Mark Lam <mark.lam@apple.com>
Add some needed CatchScopes in code that should not throw.
https://bugs.webkit.org/show_bug.cgi?id=162584
Reviewed by Keith Miller.
Re-landing minus the jsc.cpp and ExceptionHelpers.cpp changes. I'll address
those in a subsequent patch if the need manifests again in my testing.
* API/JSObjectRef.cpp:
(JSObjectSetProperty):
- This function already handles exceptions in its own way. We're honoring this
contract and catching exceptions and passing it to the handler.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
- The debugger should not be throwing any exceptions.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::save):
- If an exception was thrown while saving the database, there's nothing we can
really do about it anyway. Just fail nicely and return false. This is in line
with existing error checking code in Database::save() that returns false if
it's not able to open the file to save to.
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
- The existing code already RELEASE_ASSERT that no exception was thrown.
Hence, it's appropriate to use a CatchScope here.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
- The sampling profiler is doing a VMInquiry get here. It should never throw an
exception. Hence, we'll just use a CatchScope and assert accordingly.
2016-09-27 Jer Noble <jer.noble@apple.com>
Remove deprecated ENCRYPTED_MEDIA implementation.
https://bugs.webkit.org/show_bug.cgi?id=161010
Reviewed by Eric Carlson.
Remove ENABLE_ENCRYPTED_MEDIA.
* Configurations/FeatureDefines.xcconfig:
2016-09-27 Michael Catanzaro <mcatanzaro@igalia.com>
[GTK] Install binaries to pkglibexecdir rather than bindir
https://bugs.webkit.org/show_bug.cgi?id=162602
Reviewed by Carlos Garcia Campos.
Install jsc shell to LIBEXEC_INSTALL_DIR rather than EXEC_INSTALL_DIR.
Note these locations are the same on non-GTK ports.
* shell/CMakeLists.txt:
2016-09-26 Sam Weinig <sam@webkit.org>
Make DFGSlowPathGenerator a bit more variadic
https://bugs.webkit.org/show_bug.cgi?id=162378
Reviewed by Filip Pizlo.
Make the subclass of CallSlowPathGenerator that takes arguments variadic
so it can take any number of arguments. Also updates the slowPathCall helper
function to be variadic. I had to move the spill mode and exception check
requirement parameters to before the arguments since the variadic arguments
must be at the end. As a convenience, I added an overload of slowPathCall that
doesn't take spill mode and exception check requirement parameters.
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
(JSC::DFG::slowPathCall):
(JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal): Deleted.
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator): Deleted.
(JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal): Deleted.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileNotifyWrite):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
2016-09-26 Commit Queue <commit-queue@webkit.org>
Unreviewed, rolling out r206405.
https://bugs.webkit.org/show_bug.cgi?id=162588
This change caused LayoutTest crashes. (Requested by
ryanhaddad on #webkit).
Reverted changeset:
"Add some needed CatchScopes in code that should not throw."
https://bugs.webkit.org/show_bug.cgi?id=162584
http://trac.webkit.org/changeset/206405
2016-09-26 Mark Lam <mark.lam@apple.com>
Add some needed CatchScopes in code that should not throw.
https://bugs.webkit.org/show_bug.cgi?id=162584
Reviewed by Keith Miller.
* API/JSObjectRef.cpp:
(JSObjectSetProperty):
- This function already handles exceptions in its own way. We're honoring this
contract and catching exceptions and passing it to the handler.
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
- The debugger should not be throwing any exceptions.
* jsc.cpp:
(runJSC):
- the buck stops here. There's no reason an exception should propagate past here.
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::save):
- If an exception was thrown while saving the database, there's nothing we can
really do about it anyway. Just fail nicely and return false. This is in line
with existing error checking code in Database::save() that returns false if
it's not able to open the file to save to.
* runtime/ExceptionHelpers.cpp:
(JSC::createError):
- If we're not able to stringify the error value, then we'll just use the
provided message as the error string. It doesn't make sense to have the
Error factory throw an exception that shadows the intended exception that the
client probably wants to throw (assuming that that's why the client is creating
this Error object).
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::finishCreation):
- The existing code already RELEASE_ASSERT that no exception was thrown.
Hence, it's appropriate to use a CatchScope here.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
- The sampling profiler is doing a VMInquiry get here. It should never throw an
exception. Hence, we'll just use a CatchScope and assert accordingly.
2016-09-26 Mark Lam <mark.lam@apple.com>
Exception unwinding code should use a CatchScope instead of a ThrowScope.
https://bugs.webkit.org/show_bug.cgi?id=162583
Reviewed by Geoffrey Garen.
This is because the exception unwinding code does not throw an exception.
It only inspects the thrown exception and passes it to the appropriate handler.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
2016-09-26 Joseph Pecoraro <pecoraro@apple.com>
Add an Option to disable the CodeCache
https://bugs.webkit.org/show_bug.cgi?id=162579
Reviewed by Geoffrey Garen.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getGlobalCodeBlock):
(JSC::CodeCache::getFunctionExecutableFromGlobalCode):
Do not use the cache if the Option is disabled.
* runtime/Options.h:
New option to not use the code cache.
2016-09-26 Daniel Bates <dabates@apple.com>
Rename IOS_TEXT_AUTOSIZING to TEXT_AUTOSIZING
https://bugs.webkit.org/show_bug.cgi?id=162365
Reviewed by Simon Fraser.
* Configurations/FeatureDefines.xcconfig:
2016-09-26 Benjamin Poulain <benjamin@webkit.org>
[JSC] Shrink the Math inline caches some more
https://bugs.webkit.org/show_bug.cgi?id=162485
Reviewed by Saam Barati.
This patch applies some lessons learnt from op_negate
to shrink the generated asm of the previous 3 inline
caches.
In order of importance:
-We do not need to pass the pointer to ArithProfile
on the slow path. We can just get the profile out
of the Math IC.
This saves us from materializing a 64bits value
in a register before the call on the slow path.
-We can remove a bunch of mov by setting up the registers
in the way the slow path needs them.
The slow path makes a function calls with the input
as second and third arguments, and return the result in
the "return register". By using those as target when
loading/storing from the stack, we remove 3 mov per slow path.
-When performing integer add, we can set the result directly in
the output register if that does not trashes one of the input
register. This removes one mov per integer add.
The inline cache average sizes on Sunspider change as follow:
-Adds: 147.573099->131.555556 (~10%)
-Muls: 186.882353->170.991597 (~8%)
-Subs: 139.127907->121.523256 (~12%)
* jit/JIT.h:
* jit/JITAddGenerator.cpp:
(JSC::JITAddGenerator::generateInline):
(JSC::JITAddGenerator::generateFastPath):
* jit/JITArithmetic.cpp:
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
* jit/JITInlines.h:
(JSC::JIT::callOperation): Deleted.
* jit/JITOperations.cpp:
* jit/JITOperations.h:
2016-09-26 Mark Lam <mark.lam@apple.com>
Added RETURN_IF_EXCEPTION() macro and use it for exception checks.
https://bugs.webkit.org/show_bug.cgi?id=162521
Reviewed by Saam Barati.
Also, where possible, if the return type is JSValue, changed the returned value
(on exception) to the empty JSValue (instead of sometimes jsUndefined, jsNull,
or the thrown exception value).
There are a few places where I had to continue to return the previously returned
value (instead of the empty JSValue) in order for tests to pass. This is needed
because there are missing exception checks that will need to be added before I
can change those to return the empty JSValue too. Identifying all the places
where those checks need to be added is beyond the scope of this patch. I will
work on adding missing exception checks in a subsequent patch.
In this patch, there is one missing exception check in replaceUsingRegExpSearch()
that was easily identified, and is necessary so that Interpreter::execute()
functions can return JSValue. I've added this missing check.
This patch has passed the JSC and layout tests.
* dfg/DFGOperations.cpp:
(JSC::DFG::operationPutByValInternal):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::weakSetEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* inspector/JSJavaScriptCallFrame.cpp:
(Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::sizeOfVarargs):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::functionsOnStack):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jsc.cpp:
(WTF::ImpureGetter::getOwnPropertySlot):
(functionRun):
(functionRunString):
(functionLoad):
(functionLoadString):
(functionReadFile):
(functionCheckSyntax):
(functionSetRandomSeed):
(functionLoadModule):
(functionCreateBuiltin):
(functionCheckModuleSyntax):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::addSequenceProperties):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::toJS):
* profiler/ProfilerOSRExitSite.cpp:
(JSC::Profiler::OSRExitSite::toJS):
* profiler/ProfilerOriginStack.cpp:
(JSC::Profiler::OriginStack::toJS):
* runtime/ArrayPrototype.cpp:
(JSC::speciesConstructArray):
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
(JSC::slowJoin):
(JSC::fastJoin):
(JSC::arrayProtoFuncJoin):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
(JSC::moveElements):
(JSC::arrayProtoPrivateFuncConcatMemcpy):
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::opIn):
* runtime/Completion.cpp:
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/ConsoleObject.cpp:
(JSC::consoleProtoFuncAssert):
(JSC::consoleProtoFuncProfile):
(JSC::consoleProtoFuncProfileEnd):
(JSC::consoleProtoFuncTakeHeapSnapshot):
(JSC::consoleProtoFuncTime):
(JSC::consoleProtoFuncTimeEnd):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
(JSC::dateParse):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
(JSC::dateProtoFuncToJSON):
* runtime/ErrorConstructor.cpp:
(JSC::Interpreter::constructWithErrorConstructor):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/ExceptionScope.h:
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::copyToArguments):
* runtime/GetterSetter.cpp:
(JSC::callGetter):
* runtime/HashMapImpl.h:
(JSC::jsMapHash):
(JSC::HashMapImpl::finishCreation):
(JSC::HashMapImpl::findBucket):
(JSC::HashMapImpl::add):
(JSC::HashMapImpl::rehash):
* runtime/InspectorInstrumentationObject.cpp:
(JSC::inspectorInstrumentationObjectLog):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorFuncCompare):
(JSC::IntlCollatorPrototypeGetterCompare):
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatFuncFormatDateTime):
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormatNumber):
(JSC::IntlNumberFormatPrototypeGetterFormat):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
(JSC::intlStringOption):
(JSC::intlNumberOption):
(JSC::canonicalizeLocaleList):
(JSC::supportedLocales):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
* runtime/IteratorOperations.cpp:
(JSC::iteratorNext):
(JSC::iteratorStep):
(JSC::iteratorClose):
(JSC::iteratorForIterable):
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
* runtime/JSArray.cpp:
(JSC::JSArray::pop):
(JSC::JSArray::copyToArguments):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::constructArrayBuffer):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
* runtime/JSArrayInlines.h:
(JSC::getLength):
(JSC::toLength):
* runtime/JSBoundFunction.cpp:
(JSC::getBoundFunctionStructure):
(JSC::JSBoundFunction::create):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
(JSC::JSValue::toStringSlowCase):
* runtime/JSCJSValueInlines.h:
(JSC::toPreferredPrimitiveType):
(JSC::JSValue::getPropertySlot):
(JSC::JSValue::equalSlowCaseInline):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
* runtime/JSFunction.cpp:
(JSC::JSFunction::setFunctionName):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView::setIndex):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewFromIterator):
(JSC::constructGenericTypedArrayViewWithArguments):
(JSC::constructGenericTypedArrayView):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.h:
(JSC::constructEmptyArray):
(JSC::constructArray):
(JSC::constructArrayNegativeIndexed):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncEval):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
* runtime/JSONObject.cpp:
(JSC::Stringifier::stringify):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
(JSC::JSONProtoFuncParse):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::JSObject::setPrototypeWithCycleCheck):
(JSC::callToPrimitiveFunction):
(JSC::JSObject::defaultHasInstance):
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::toNumber):
(JSC::JSObject::toString):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::JSObject::getGenericPropertyNames):
(JSC::JSObject::getMethod):
* runtime/JSObjectInlines.h:
(JSC::createListFromArrayLike):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/JSPromiseConstructor.cpp:
(JSC::constructPromise):
* runtime/JSPromiseDeferred.cpp:
(JSC::JSPromiseDeferred::create):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSPropertyNameIterator.cpp:
(JSC::JSPropertyNameIterator::create):
* runtime/JSScope.cpp:
(JSC::isUnscopable):
* runtime/JSString.cpp:
(JSC::JSString::equalSlowCase):
* runtime/JSStringJoiner.cpp:
(JSC::JSStringJoiner::join):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
* runtime/MapBase.h:
(JSC::MapBase::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/MathObject.cpp:
(JSC::mathProtoFuncClz32):
(JSC::mathProtoFuncHypot):
(JSC::mathProtoFuncIMul):
* runtime/ModuleLoaderPrototype.cpp:
(JSC::moduleLoaderPrototypeParseModule):
(JSC::moduleLoaderPrototypeRequestedModules):
(JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
* runtime/NativeErrorConstructor.cpp:
(JSC::Interpreter::constructWithNativeErrorConstructor):
* runtime/NumberConstructor.cpp:
(JSC::constructWithNumberConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObject):
(JSC::objectConstructorGetPrototypeOf):
(JSC::objectConstructorSetPrototypeOf):
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::ownEnumerablePropertyKeys):
(JSC::toPropertyDescriptor):
(JSC::objectConstructorDefineProperty):
(JSC::defineProperties):
(JSC::objectConstructorSeal):
(JSC::objectConstructorFreeze):
(JSC::objectConstructorIsSealed):
(JSC::objectConstructorIsFrozen):
(JSC::objectConstructorIsExtensible):
(JSC::ownPropertyKeys):
* runtime/ObjectConstructor.h:
(JSC::constructObjectFromPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncHasOwnProperty):
(JSC::objectProtoFuncIsPrototypeOf):
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
(JSC::objectProtoFuncLookupGetter):
(JSC::objectProtoFuncLookupSetter):
(JSC::objectProtoFuncPropertyIsEnumerable):
(JSC::objectProtoFuncToLocaleString):
(JSC::objectProtoFuncToString):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::slowGetterSetter):
* runtime/ProxyConstructor.cpp:
(JSC::makeRevocableProxy):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::ProxyObject::putByIndexCommon):
(JSC::performProxyCall):
(JSC::performProxyConstruct):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
(JSC::reflectObjectDefineProperty):
(JSC::reflectObjectGet):
(JSC::reflectObjectGetOwnPropertyDescriptor):
(JSC::reflectObjectIsExtensible):
(JSC::reflectObjectPreventExtensions):
(JSC::reflectObjectSet):
(JSC::reflectObjectSetPrototypeOf):
* runtime/RegExpConstructor.cpp:
(JSC::toFlags):
(JSC::regExpCreate):
(JSC::constructRegExp):
* runtime/RegExpConstructor.h:
(JSC::isRegExp):
* runtime/RegExpObject.cpp:
(JSC::collectMatches):
(JSC::RegExpObject::matchGlobal):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncCompile):
(JSC::flagsString):
(JSC::regExpProtoFuncToString):
(JSC::regExpProtoGetterFlags):
(JSC::regExpProtoFuncSearchFast):
(JSC::regExpProtoFuncSplitFast):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/StringConstructor.cpp:
(JSC::stringFromCodePoint):
(JSC::constructWithStringConstructor):
* runtime/StringObject.cpp:
(JSC::StringObject::defineOwnProperty):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::replaceUsingStringSearch):
(JSC::replace):
(JSC::stringProtoFuncReplaceUsingRegExp):
(JSC::stringProtoFuncReplaceUsingStringSearch):
(JSC::stringProtoFuncCodePointAt):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSplitFast):
(JSC::stringProtoFuncSubstr):
(JSC::stringProtoFuncSubstring):
(JSC::stringProtoFuncLocaleCompare):
(JSC::toLocaleCase):
(JSC::stringProtoFuncBig):
(JSC::stringProtoFuncSmall):
(JSC::stringProtoFuncBlink):
(JSC::stringProtoFuncBold):
(JSC::stringProtoFuncFixed):
(JSC::stringProtoFuncItalics):
(JSC::stringProtoFuncStrike):
(JSC::stringProtoFuncSub):
(JSC::stringProtoFuncSup):
(JSC::stringProtoFuncFontcolor):
(JSC::stringProtoFuncFontsize):
(JSC::stringProtoFuncAnchor):
(JSC::stringProtoFuncLink):
(JSC::trimString):
(JSC::stringProtoFuncStartsWith):
(JSC::stringProtoFuncEndsWith):
(JSC::stringIncludesImpl):
(JSC::stringProtoFuncIncludes):
(JSC::builtinStringIncludesInternal):
(JSC::stringProtoFuncNormalize):
* runtime/SymbolConstructor.cpp:
(JSC::symbolConstructorFor):
* runtime/TemplateRegistry.cpp:
(JSC::TemplateRegistry::getTemplateObject):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* tools/JSDollarVMPrototype.cpp:
(JSC::functionPrint):
2016-09-26 Don Olmstead <don.olmstead@am.sony.com>
[JSC] Allow fixedExecutableMemoryPoolSize to be set during build
https://bugs.webkit.org/show_bug.cgi?id=162514
Reviewed by Mark Lam.
* jit/ExecutableAllocator.h:
== Rolled over to ChangeLog-2016-09-26 ==