2017-03-23 Yusuke Suzuki [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 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 [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 [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 78.878+-0.528 ^ 75.988+-0.621 ^ definitely 1.0380x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateAnyInt): * dfg/DFGPredictionPropagationPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate): 2017-03-22 Mark Lam 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 [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 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 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 [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 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 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 [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 [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 [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 [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::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 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 `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 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 [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 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 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 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. (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 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::defineOwnProperty): 2017-03-16 Simon Fraser 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 Array concat operation should check for length overflows. https://bugs.webkit.org/show_bug.cgi?id=169796 Reviewed by Keith Miller. * runtime/ArrayPrototype.cpp: (JSC::concatAppendOne): (JSC::arrayProtoPrivateFuncConcatMemcpy): 2017-03-16 Mark Lam The new array with spread operation needs to check for length overflows. https://bugs.webkit.org/show_bug.cgi?id=169780 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 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 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 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 Unreviewed, copy m_numberOfArgumentsToSkip https://bugs.webkit.org/show_bug.cgi?id=164582 * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): 2017-03-16 Yusuke Suzuki 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 [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::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 [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::isArrowFunctionParameters): (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseAsyncFunctionSourceElements): (JSC::Parser::parseFormalParameters): (JSC::Parser::parseFunctionBody): (JSC::Parser::parseFunctionParameters): (JSC::Parser::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 [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::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 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 [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 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 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 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 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 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 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 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 Reviewed by Michael Saboff. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::usesDerivedConstructorInArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): * bytecompiler/BytecodeGenerator.h: 2017-03-14 Brian Burg [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 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 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 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 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 [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 [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 [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 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 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 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 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 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 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 [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 [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 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 [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::parseStatement): 2017-03-11 Filip Pizlo 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 Unreviewed, suprress warnings in JSC B3 * b3/B3Opcode.cpp: 2017-03-11 Michael Saboff 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 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 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 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 WebAssembly: Make more demos run https://bugs.webkit.org/show_bug.cgi?id=165510 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 JSC: BindingNode::bindValue doesn't increase the scope's reference count. https://bugs.webkit.org/show_bug.cgi?id=168546 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 Fix CMake build. * CMakeLists.txt: Make more forwarding headers so we can find WasmFaultSignalHandler.h from WebProcess.cpp. 2017-03-10 Mark Lam [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 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 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 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 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 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 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 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 [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::parseDestructuringPattern): (JSC::Parser::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 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 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 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 Web Inspector: Add XHR breakpoints UI https://bugs.webkit.org/show_bug.cgi?id=168763 Reviewed by Joseph Pecoraro. * inspector/protocol/DOMDebugger.json: Added clarifying comments to command descriptions. 2017-03-09 Michael Saboff 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 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 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 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 Guard Credential Management implementation behind a runtime enabled feature flag https://bugs.webkit.org/show_bug.cgi?id=169364 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 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 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 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 Unreviewed, fix weak external symbol error. * heap/SlotVisitor.h: 2017-03-09 Filip Pizlo 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 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 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 Make the VM Traps mechanism non-polling for the DFG and FTL. https://bugs.webkit.org/show_bug.cgi?id=168920 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 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 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 [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 Web Inspector: Should be able to see where Resources came from (Memory Cache, Disk Cache) https://bugs.webkit.org/show_bug.cgi?id=164892 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 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 Some platforms won't be able to create a GPUDevice https://bugs.webkit.org/show_bug.cgi?id=169314 Reviewed by Jon Lee. Disable WEB_GPU on the iOS Simulator. * Configurations/FeatureDefines.xcconfig: 2017-03-06 Saam Barati WebAssembly: Implement the WebAssembly.instantiate API https://bugs.webkit.org/show_bug.cgi?id=165982 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 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 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 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 WebAssembly: implement init_expr for Element https://bugs.webkit.org/show_bug.cgi?id=165888 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 [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 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 [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 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 [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 [ARM] Unreviewed buildfix after r213376. * assembler/ARMAssembler.h: (JSC::ARMAssembler::isBkpt): Typo fixed. 2017-03-03 Carlos Alberto Lopez Perez [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 Add WebGPU compile flag and experimental feature flag https://bugs.webkit.org/show_bug.cgi?id=169161 Reviewed by Tim Horton. Add ENABLE_WEBGPU, an experimental feature flag, a RuntimeEnabledFeature, and an InternalSetting. * Configurations/FeatureDefines.xcconfig: 2017-03-03 Michael Saboff 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 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 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 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 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 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 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 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 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 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 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 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 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 Continue enabling WebRTC https://bugs.webkit.org/show_bug.cgi?id=169056 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: 2017-03-02 Tomas Popela 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 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 Continue enabling WebRTC https://bugs.webkit.org/show_bug.cgi?id=169056 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: 2017-03-01 Michael Saboff 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 [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 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: 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: 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: 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: 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: 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: 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: 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 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 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 REGRESSION(r211344): Remote Inspector: listingForAutomationTarget() is called off-main-thread, causing assertions https://bugs.webkit.org/show_bug.cgi?id=168695 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 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 [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. 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::actualPointerFor): (JSC::BytecodeDumper::actualPointerFor): (JSC::beginDumpProfiling): (JSC::BytecodeDumper::dumpValueProfiling): (JSC::BytecodeDumper::dumpValueProfiling): (JSC::BytecodeDumper::dumpArrayProfiling): (JSC::BytecodeDumper::dumpArrayProfiling): (JSC::BytecodeDumper::dumpProfilesForBytecodeOffset): (JSC::dumpRareCaseProfile): (JSC::dumpArithProfile): (JSC::BytecodeDumper::dumpProfilesForBytecodeOffset): (JSC::BytecodeDumper::vm): (JSC::BytecodeDumper::identifier): (JSC::regexpToSourceString): (JSC::regexpName): (JSC::printLocationAndOp): (JSC::isConstantRegisterIndex): (JSC::debugHookName): (JSC::BytecodeDumper::registerName): (JSC::idName): (JSC::BytecodeDumper::constantName): (JSC::BytecodeDumper::printUnaryOp): (JSC::BytecodeDumper::printBinaryOp): (JSC::BytecodeDumper::printConditionalJump): (JSC::BytecodeDumper::printGetByIdOp): (JSC::dumpStructure): (JSC::dumpChain): (JSC::BytecodeDumper::printGetByIdCacheStatus): (JSC::BytecodeDumper::printPutByIdCacheStatus): (JSC::BytecodeDumper::dumpCallLinkStatus): (JSC::BytecodeDumper::dumpCallLinkStatus): (JSC::BytecodeDumper::printCallOp): (JSC::BytecodeDumper::printPutByIdOp): (JSC::BytecodeDumper::printLocationOpAndRegisterOperand): (JSC::BytecodeDumper::dumpBytecode): (JSC::BytecodeDumper::dumpIdentifiers): (JSC::BytecodeDumper::dumpConstants): (JSC::BytecodeDumper::dumpRegExps): (JSC::BytecodeDumper::dumpExceptionHandlers): (JSC::BytecodeDumper::dumpSwitchJumpTables): (JSC::BytecodeDumper::dumpStringSwitchJumpTables): (JSC::BytecodeDumper::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 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 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 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 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 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 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 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 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::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 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 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 [libwebrtc] Enable WebRTC in some Production Builds https://bugs.webkit.org/show_bug.cgi?id=168858 * Configurations/FeatureDefines.xcconfig: 2017-02-26 Caio Lima 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 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 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::forEach): (JSC::B3::Air::ArgThingHelper::forEach): (JSC::B3::Air::ArgThingHelper::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::absoluteIndex): Deleted. (JSC::B3::Air::AbsoluteTmpMapper::lastMachineRegisterIndex): Deleted. (JSC::B3::Air::AbsoluteTmpMapper::tmpFromAbsoluteIndex): Deleted. (JSC::B3::Air::AbsoluteTmpMapper::absoluteIndex): Deleted. (JSC::B3::Air::AbsoluteTmpMapper::lastMachineRegisterIndex): Deleted. (JSC::B3::Air::AbsoluteTmpMapper::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 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 Unreviewed. Remove inaccurate copy-paste comment from r212939. * dfg/DFGOperations.cpp: 2017-02-23 Saam Barati 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::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 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 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 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 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 Unreviewed, fix the cloop build. Needed a #if. * jit/ExecutableAllocator.cpp: 2017-02-22 Carlos Garcia Campos 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 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 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 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 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 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 [WebRTC][Mac] Activate libwebrtc https://bugs.webkit.org/show_bug.cgi?id=167293 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-02-21 Saam Barati 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 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 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 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 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 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 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 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 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 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 [Re-landing] CachedCall should let GC know to keep its arguments alive. https://bugs.webkit.org/show_bug.cgi?id=168567 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 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 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 [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 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 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 CachedCall should let GC know to keep its arguments alive. https://bugs.webkit.org/show_bug.cgi?id=168567 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 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 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 [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 [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 to RefPtr&&. 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::GenericTypedArrayView): (JSC::GenericTypedArrayView::create): (JSC::GenericTypedArrayView::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::create): (JSC::JSGenericTypedArrayView::possiblySharedTypedImpl): (JSC::JSGenericTypedArrayView::unsharedTypedImpl): (JSC::JSGenericTypedArrayView::getTypedArrayImpl): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * runtime/JSTypedArrays.cpp: (JSC::createUint8TypedArray): * runtime/TypedArrayBase.h: Removed. 2017-02-16 Keith Miller 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 Unreviewed, fix cloop build. * heap/Heap.cpp: (JSC::Heap::stopThePeriphery): * runtime/JSLock.cpp: 2017-02-10 Filip Pizlo 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 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 [Cocoa] Web Inspector: Inspector::fromProtocolString should return std::optional https://bugs.webkit.org/show_bug.cgi?id=168018 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(). * 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 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 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 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 [JSC] Drop PassRefPtr in inspector/ https://bugs.webkit.org/show_bug.cgi?id=168420 Reviewed by Alex Christensen. Drop PassRefPtr uses. And use Ref and Ref 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&& instead of RefPtr&&. * 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 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::operator): (JSC::Weak::get): 2017-02-16 Yusuke Suzuki 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 [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 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 [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