2014-01-30 Zan Dobersek [GTK] Only disable -ftree-dce optimization when compiling with GCC https://bugs.webkit.org/show_bug.cgi?id=127911 Reviewed by Carlos Garcia Campos. * GNUmakefile.am: Only disable the -ftree-dce optimization when using the GCC compiler. Some Clang versions/configurations don't support the flag. 2014-01-30 Zan Dobersek [GTK] Disable optimizations for JSC that turned out malignant after jsCStack branch merge https://bugs.webkit.org/show_bug.cgi?id=127909 Reviewed by Carlos Garcia Campos. * GNUmakefile.am: Disable the -fomit-frame-pointer optimization to achieve proper register usage in operationCallEval. Disable the -ftree-dce optimization since it is causing additional failures when using GCC 4.8, possibly due to a bug in the compiler itself. 2014-01-29 Csaba Osztrogonác Remove ENABLE(JAVASCRIPT_DEBUGGER) leftovers https://bugs.webkit.org/show_bug.cgi?id=127845 Reviewed by Joseph Pecoraro. * Configurations/FeatureDefines.xcconfig: 2014-01-29 Csaba Osztrogonác Remove ENABLE(JAVASCRIPT_DEBUGGER) guards https://bugs.webkit.org/show_bug.cgi?id=127840 Reviewed by Mark Lam. * inspector/scripts/CodeGeneratorInspector.py: 2014-01-28 Commit Queue Unreviewed, rolling out r162987. http://trac.webkit.org/changeset/162987 https://bugs.webkit.org/show_bug.cgi?id=127825 Broke Mountain Lion build (Requested by andersca on #webkit). * inspector/InjectedScriptSource.js: (.): * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): * runtime/PropertyDescriptor.cpp: * runtime/PropertyDescriptor.h: * runtime/PropertySlot.h: 2014-01-28 Oliver Hunt Make DOM attributes appear to be faux accessor properties https://bugs.webkit.org/show_bug.cgi?id=127797 Reviewed by Michael Saboff. Add flag so we can identify which properties should have the old custom property semantics vs. the new faux accessors. Update the inspector protocol accordingly. These faux accessors produce descriptors with "get" and "set" properties, but both values are undefined so can't be used directly. A few custom properties actually require their existing magical behaviour, so we now have a flag to distinguish the expected output. * inspector/InjectedScriptSource.js: (.): * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setCustomDescriptor): * runtime/PropertyDescriptor.h: * runtime/PropertySlot.h: 2014-01-28 Mark Lam Remove some unneeded debugger code. https://bugs.webkit.org/show_bug.cgi?id=127805. Reviewed by Oliver Hunt. JSC will now always support the debugger. Hence, the #if ENABLE(JAVASCRIPT_DEBUGGER) checks can be removed. DebuggerCallFrame::callFrame() is also unused and will be removed. * debugger/Breakpoint.h: * debugger/Debugger.cpp: * debugger/DebuggerCallFrame.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::wrapCallFrames): * inspector/InjectedScript.h: * inspector/JSGlobalObjectScriptDebugServer.cpp: * inspector/JSGlobalObjectScriptDebugServer.h: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.cpp: * inspector/JSJavaScriptCallFramePrototype.h: * inspector/JavaScriptCallFrame.cpp: * inspector/JavaScriptCallFrame.h: * inspector/ScriptDebugListener.h: * inspector/ScriptDebugServer.cpp: * inspector/ScriptDebugServer.h: * inspector/agents/InspectorDebuggerAgent.cpp: * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent): (Inspector::setPauseOnExceptionsState): (Inspector::InspectorRuntimeAgent::evaluate): (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::getProperties): * inspector/agents/InspectorRuntimeAgent.h: 2014-01-28 Geoffrey Garen REGRESSION: JavascriptCore crash during OS Installation (due to Heap::m_operationInProgress ASSERT vs DelayedReleaseScope) https://bugs.webkit.org/show_bug.cgi?id=127793 Reviewed by Mark Hahnenberg. This was a mistaken ASSERT. * API/tests/testapi.mm: (-[EvilAllocationObject doEvilThingsWithContext:]): Added a test to verify that GC from a DelayedReleaseScope doesn't crash. * heap/DelayedReleaseScope.h: (JSC::DelayedReleaseScope::~DelayedReleaseScope): Our contract is that it is valid to do anything while running a DelayedReleaseScope -dealloc method, so the Heap must be ready for new allocations and collections. Change the Heap's operationInProgress value to NoOperation while running -dealloc methods, so that it doesn't ASSERT in the face of new allocations and collections. * heap/Heap.h: Made DelayedReleaseScope a friend because exposing a setter for m_operationInProgress seemed like the worse of the two options for encapsulation: we don't really want arbitrary clients to set the Heap's m_operationInProgress. 2014-01-28 Mark Lam Jettison DFG code when neither breakpoints or the profiler are active. Reviewed by Geoffrey Garen. We need to jettison the DFG CodeBlocks under the following circumstances: 1. When adding breakpoints to a CodeBlock, jettison it if it is a DFG CodeBlock. 2. When enabling stepping mode in a CodeBlock, jettison it if it a DFG CodeBlock. 3. When settign the enabled profiler in the VM, we need to jettison all DFG CodeBlocks. Instead of emitting speculation checks, the DFG code will now treat Breakpoint, ProfileWillCall, and ProfileDidCall as no-ops similar to a Phantom node. We still need to track these nodes so that they match the corresponding opcodes in the baseline JIT when we jettison and OSR exit. Without them, we would OSR exit to the wrong location in the baseline JIT code. In DFGDriver's compileImpl() and DFGPlan's finalizeWithoutNotifyingCallback() we fail the compilation effort with a CompilationInvalidated result. This allows the DFG compiler to re-attampt the compilation of the function after some time if it is hot. The CompilationInvalidated result is supposed to cause the DFG to exercise an exponential back off before re-attempting compilation again (see runtime/CompilationResult.h). This patch improves the Octane score from ~2950 to ~3067. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::addBreakpoint): (JSC::CodeBlock::setSteppingMode): * bytecode/CodeBlock.h: * debugger/Debugger.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * profiler/LegacyProfiler.cpp: (JSC::LegacyProfiler::startProfiling): (JSC::LegacyProfiler::stopProfiling): * runtime/VM.cpp: (JSC::VM::VM): (JSC::SetEnabledProfilerFunctor::operator()): (JSC::VM::setEnabledProfiler): * runtime/VM.h: (JSC::VM::enabledProfiler): 2014-01-27 Joseph Pecoraro -[JSContext evaluteScript:] calls JSEvaluteScript with startingLineNumber 0, later interpreted as a oneBasedInt https://bugs.webkit.org/show_bug.cgi?id=127648 Reviewed by Geoffrey Garen. The actual bug being fixed here is that the line number for scripts evaluated via the JSC APIs is now sane. However, there is no good infrastructure in place right now to test that. * API/tests/testapi.c: (main): * API/tests/testapi.mm: (testObjectiveCAPI): Add tests for exception line numbers and handling of bad startingLineNumbers in public APIs. These tests were already passing, I just add them to make sure they are not regressed in the future. * API/JSBase.cpp: (JSEvaluateScript): (JSCheckScriptSyntax): * API/JSBase.h: * API/JSObjectRef.cpp: (JSObjectMakeFunction): * API/JSObjectRef.h: * API/JSScriptRef.cpp: * API/JSScriptRefPrivate.h: * API/JSStringRef.h: - Clarify documentation that startingLineNumber is 1 based and clamped. - Add clamping in the implementation to put sane values into JSC::SourceProvider. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::didParseSource): Remove the FIXME now that the SourceProvider is giving us expected values. 2014-01-27 Joseph Pecoraro Web Inspector: CRASH when debugger closes remote inspecting JSContext https://bugs.webkit.org/show_bug.cgi?id=127738 Reviewed by Timothy Hatcher. RemoteInspectorXPCConnection could be accessed in a background dispatch queue, while being deallocated on the main thread when a connection was suddenly terminated. Make RemoteInspectorXPCConnection a ThreadSafeRefCounted object. Always keep the connection object ref'd until the main thread calls close() and removes its reference. At that point we can close the connection, queue, and deref safely on the background queue. * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): (Inspector::RemoteInspector::xpcConnectionFailed): For simplicity RemoteInspectorXPCConnections's don't have any threading primatives to prevent client callbacks after they are closed. RemoteInspector does, so it just ignores possible callbacks from connections it no longer cares about. * inspector/remote/RemoteInspectorXPCConnection.h: * inspector/remote/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::close): Keep the connection alive as long as the queue it can be used on is alive. Clean up everything on the queue when close() is called. (Inspector::RemoteInspectorXPCConnection::handleEvent): Checking if closed here is not thread safe so it is meaningless. Remove the check. (Inspector::RemoteInspectorXPCConnection::sendMessage): Bail based on the m_closed state. 2014-01-27 Joseph Pecoraro JavaScriptCore: Enable -Wimplicit-fallthrough and add FALLTHROUGH annotation where needed https://bugs.webkit.org/show_bug.cgi?id=127647 Reviewed by Anders Carlsson. Explicitly annotate switch case fallthroughs in JavaScriptCore and enable warnings for unannotated fallthroughs. * dfg/DFGArithMode.h: (doesOverflow): Only insert FALLTHROUGH in release builds. In debug builds, the FALLTHROUGH would be unreachable (due to the ASSERT_NOT_REACHED) and would through a warning. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): Due to the templatized nature of this function, a fallthrough in one of the template expansions would be unreachable. Disable the warning for this function. * Configurations/Base.xcconfig: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validateCPS): * parser/Lexer.cpp: (JSC::Lexer::lex): * parser/Parser.cpp: (JSC::Parser::parseStatement): (JSC::Parser::parseProperty): * runtime/JSArray.cpp: (JSC::JSArray::push): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putByIndexBeyondVectorLength): * runtime/JSObject.h: (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): * runtime/LiteralParser.cpp: (JSC::LiteralParser::parse): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin): (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd): * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parseTokens): 2014-01-27 Andy Estes Scrub WebKit API headers of WTF macros https://bugs.webkit.org/show_bug.cgi?id=127706 Reviewed by David Kilzer. * Configurations/FeatureDefines.xcconfig: Added ENABLE_INSPECTOR. 2014-01-27 Mark Lam Remove unused CodeBlock::createActivation(). Reviewed by Filip Pizlo. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: 2014-01-26 Andreas Kling JSC: Pack unlinked instructions harder. Store UnlinkedCodeBlock's instructions in a variable-length stream to reduce memory usage. Compression rate ends up around 60-61%. The format is very simple. Every instruction starts with a 1 byte opcode. It's followed by an opcode-dependent number of argument values, each encoded separately for maximum packing. There are 7 packed value formats: 5-bit positive integer 5-bit negative integer 13-bit positive integer 13-bit positive integer 5-bit constant register index 13-bit constant register index 32-bit value (fallback) 27.5 MB progression on Membuster3. (~2% of total memory.) Reviewed by Filip Pizlo. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/UnlinkedInstructionStream.h: Added. (JSC::UnlinkedInstructionStream::count): (JSC::UnlinkedInstructionStream::Reader::atEnd): * bytecode/UnlinkedInstructionStream.cpp: Added. (JSC::UnlinkedInstructionStream::Reader::Reader): (JSC::UnlinkedInstructionStream::Reader::read8): (JSC::UnlinkedInstructionStream::Reader::read32): (JSC::UnlinkedInstructionStream::Reader::next): (JSC::append8): (JSC::append32): (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream): (JSC::UnlinkedInstructionStream::unpackForDebugging): * bytecompiler/BytecodeGenerator.cpp: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): (JSC::dumpLineColumnEntry): (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): (JSC::UnlinkedCodeBlock::setInstructions): (JSC::UnlinkedCodeBlock::instructions): * bytecode/UnlinkedCodeBlock.h: (JSC::BytecodeGenerator::generate): 2014-01-26 Joseph Pecoraro Web Inspector: Move InspectorDebuggerAgent into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=127629 Rubber-stamped by Sam Weinig. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: - Add new files to the build. - Also, since non REMOTE_INSPECTOR ports cannot yet connect to a JSGlobalObject for inspection remove those files as they don't need to be built. * inspector/EventLoop.cpp: Added. (Inspector::EventLoop::cycle): * inspector/EventLoop.h: Added. (Inspector::EventLoop::EventLoop): (Inspector::EventLoop::ended): Add a JavaScriptCore version of EventLoop. This is currently only used by the Mac port for JSGlobalObject remote inspection. Keep the WebCore/platform version alive because for the Mac port it does slightly different things involving AppKit. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): Create DebuggerAgent and hook up ScriptDebugServer where needed. * inspector/JSGlobalObjectScriptDebugServer.cpp: Added. (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer): (Inspector::JSGlobalObjectScriptDebugServer::addListener): (Inspector::JSGlobalObjectScriptDebugServer::removeListener): (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused): * inspector/JSGlobalObjectScriptDebugServer.h: Added. Simple implementation of ScriptDebugServer with a JSGlobalObject. * inspector/agents/InspectorDebuggerAgent.cpp: Renamed from Source/WebCore/inspector/InspectorDebuggerAgent.cpp. * inspector/agents/InspectorDebuggerAgent.h: Renamed from Source/WebCore/inspector/InspectorDebuggerAgent.h. Copied from WebCore. A few methods need to be made virtual so that Web implementations can override and extend the funcitonality. E.g. sourceMapURLForScript and enable/disable. * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: Added. * inspector/agents/JSGlobalObjectDebuggerAgent.h: Added. (Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent): (Inspector::JSGlobalObjectDebuggerAgent::startListeningScriptDebugServer): (Inspector::JSGlobalObjectDebuggerAgent::stopListeningScriptDebugServer): (Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval): Simple implementation of DebuggerAGent with a JSGlobalObject. 2014-01-25 Mark Lam Gardening: fix build breakage from previous commit. Not reviewed. * profiler/ProfileNode.cpp: (JSC::ProfileNode::debugPrintData): - Removed obsolete references to "visible" timers. 2014-01-25 Timothy Hatcher Remove dead code from the JSC profiler. https://bugs.webkit.org/show_bug.cgi?id=127643 Reviewed by Mark Lam. * profiler/Profile.cpp: * profiler/Profile.h: * profiler/ProfileGenerator.cpp: (JSC::ProfileGenerator::stopProfiling): * profiler/ProfileNode.cpp: (JSC::ProfileNode::ProfileNode): (JSC::ProfileNode::stopProfiling): (JSC::ProfileNode::endAndRecordCall): (JSC::ProfileNode::debugPrintData): (JSC::ProfileNode::debugPrintDataSampleStyle): * profiler/ProfileNode.h: (JSC::ProfileNode::totalTime): (JSC::ProfileNode::setTotalTime): (JSC::ProfileNode::selfTime): (JSC::ProfileNode::setSelfTime): (JSC::ProfileNode::totalPercent): (JSC::ProfileNode::selfPercent): Remove support for things like focus and exclude. The Inspector does those in JS now. 2014-01-25 Sam Weinig Remove unused support for DRAGGABLE_REGION https://bugs.webkit.org/show_bug.cgi?id=127642 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2014-01-25 Darin Adler Try to fix Mac build. * runtime/DatePrototype.cpp: Put the include of inside a conditional since we don't have that header in our Mac build configuration. 2014-01-25 Darin Adler Call deprecatedCharacters instead of characters at more call sites https://bugs.webkit.org/show_bug.cgi?id=127631 Reviewed by Sam Weinig. * API/JSValueRef.cpp: (JSValueMakeFromJSONString): * API/OpaqueJSString.cpp: (OpaqueJSString::~OpaqueJSString): * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::createSearchRegexSource): * inspector/InspectorValues.cpp: * runtime/Identifier.h: (JSC::Identifier::deprecatedCharacters): * runtime/JSStringBuilder.h: (JSC::JSStringBuilder::append): Use the new name. 2014-01-25 Darin Adler Get rid of ICU_UNICODE and WCHAR_UNICODE remnants https://bugs.webkit.org/show_bug.cgi?id=127623 Reviewed by Anders Carlsson. * runtime/DatePrototype.cpp: Removed USE(ICU_UNICODE) checks, since that's always true now. 2014-01-25 Darin Adler [Mac] Rewrite locale-specific date formatting code to remove strange string creation https://bugs.webkit.org/show_bug.cgi?id=127624 Reviewed by Anders Carlsson. * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): Use some smart pointers and conversion operators we already have to do the formatting in a more straightforward way. 2014-01-25 Anders Carlsson Remove atomicIncrement/atomicDecrement https://bugs.webkit.org/show_bug.cgi?id=127625 Reviewed by Andreas Kling. Replace atomicIncrement/atomicDecrement with std::atomic. * bytecode/Watchpoint.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::lower): * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::Database): (JSC::Profiler::Database::addDatabaseToAtExit): 2014-01-24 Joseph Pecoraro Web Inspector: Move InspectorRuntimeAgent into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=127605 Reviewed by Timothy Hatcher. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: Add new files to the build. * inspector/agents/InspectorRuntimeAgent.h: Renamed from Source/WebCore/inspector/InspectorRuntimeAgent.h. * inspector/agents/InspectorRuntimeAgent.cpp: Renamed from Source/WebCore/inspector/InspectorRuntimeAgent.cpp. (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent): (Inspector::InspectorRuntimeAgent::parse): (Inspector::InspectorRuntimeAgent::evaluate): (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::getProperties): - Move the agent into JavaScriptCore. - Modernize and cleanup. - Make globalVM a pure virtual function for subclasses to implement. * inspector/agents/JSGlobalObjectRuntimeAgent.h: Added. * inspector/agents/JSGlobalObjectRuntimeAgent.cpp: Added. (Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent): (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): (Inspector::JSGlobalObjectRuntimeAgent::globalVM): (Inspector::JSGlobalObjectRuntimeAgent::injectedScriptForEval): Straightforward JSGlobalObject implementation. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): Add a runtime agent when inspecting a JSContext! 2014-01-23 Joseph Pecoraro Move JavaScriptCallFrame and ScriptDebugServer into JavaScriptCore for inspector https://bugs.webkit.org/show_bug.cgi?id=127543 Reviewed by Geoffrey Garen. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: Add new files. * inspector/ScriptDebugListener.h: Extract WebCore knowledge from ScriptDebugServer. This will eventually be made to work outside of WebCore. * inspector/ScriptDebugServer.h: Renamed from Source/WebCore/bindings/js/ScriptDebugServer.h. * inspector/ScriptDebugServer.cpp: Renamed from Source/WebCore/bindings/js/ScriptDebugServer.cpp. (Inspector::ScriptDebugServer::evaluateBreakpointAction): (Inspector::ScriptDebugServer::dispatchDidPause): (Inspector::ScriptDebugServer::dispatchBreakpointActionLog): (Inspector::ScriptDebugServer::dispatchBreakpointActionSound): (Inspector::ScriptDebugServer::sourceParsed): (Inspector::ScriptDebugServer::dispatchFunctionToListeners): (Inspector::ScriptDebugServer::handlePause): Modernize code, and call the new ScriptDebugListener callbacks where appropriate. * inspector/JSJavaScriptCallFrame.cpp: Renamed from Source/WebCore/bindings/js/JSJavaScriptCallFrameCustom.cpp. (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame): (Inspector::JSJavaScriptCallFrame::finishCreation): (Inspector::JSJavaScriptCallFrame::createPrototype): (Inspector::JSJavaScriptCallFrame::destroy): (Inspector::JSJavaScriptCallFrame::releaseImpl): (Inspector::JSJavaScriptCallFrame::~JSJavaScriptCallFrame): (Inspector::JSJavaScriptCallFrame::evaluate): (Inspector::JSJavaScriptCallFrame::scopeType): (Inspector::JSJavaScriptCallFrame::caller): (Inspector::JSJavaScriptCallFrame::sourceID): (Inspector::JSJavaScriptCallFrame::line): (Inspector::JSJavaScriptCallFrame::column): (Inspector::JSJavaScriptCallFrame::functionName): (Inspector::JSJavaScriptCallFrame::scopeChain): (Inspector::JSJavaScriptCallFrame::thisObject): (Inspector::JSJavaScriptCallFrame::type): (Inspector::toJS): (Inspector::toJSJavaScriptCallFrame): * inspector/JSJavaScriptCallFrame.h: Added. (Inspector::JSJavaScriptCallFrame::createStructure): (Inspector::JSJavaScriptCallFrame::create): (Inspector::JSJavaScriptCallFrame::impl): * inspector/JSJavaScriptCallFramePrototype.cpp: Added. (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate): (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): (Inspector::jsJavaScriptCallFrameAttributeCaller): (Inspector::jsJavaScriptCallFrameAttributeSourceID): (Inspector::jsJavaScriptCallFrameAttributeLine): (Inspector::jsJavaScriptCallFrameAttributeColumn): (Inspector::jsJavaScriptCallFrameAttributeFunctionName): (Inspector::jsJavaScriptCallFrameAttributeScopeChain): (Inspector::jsJavaScriptCallFrameAttributeThisObject): (Inspector::jsJavaScriptCallFrameAttributeType): (Inspector::jsJavaScriptCallFrameConstantGLOBAL_SCOPE): (Inspector::jsJavaScriptCallFrameConstantLOCAL_SCOPE): (Inspector::jsJavaScriptCallFrameConstantWITH_SCOPE): (Inspector::jsJavaScriptCallFrameConstantCLOSURE_SCOPE): (Inspector::jsJavaScriptCallFrameConstantCATCH_SCOPE): * inspector/JSJavaScriptCallFramePrototype.h: Added. (Inspector::JSJavaScriptCallFramePrototype::create): (Inspector::JSJavaScriptCallFramePrototype::createStructure): (Inspector::JSJavaScriptCallFramePrototype::JSJavaScriptCallFramePrototype): * inspector/JavaScriptCallFrame.cpp: Renamed from Source/WebCore/bindings/js/JavaScriptCallFrame.cpp. (Inspector::JavaScriptCallFrame::caller): * inspector/JavaScriptCallFrame.h: Renamed from Source/WebCore/bindings/js/JavaScriptCallFrame.h. Port of JavaScriptCallFrame.idl to a set of native JS classes. 2014-01-24 Mark Lam DebuggerCallFrame::evaluateWithCallFrame() should not execute a null executable. Reviewed by Oliver Hunt. In DebuggerCallFrame::evaluateWithCallFrame(), if the script string that is passed in is bad, it will fail to create an Executable i.e. EvalExecutable::create() returns a null pointer. However, DebuggerCallFrame::evaluateWithCallFrame() was just clearing the exception and proceeded to execute the null pointer as an Executable. A crash ensues. Now, if an exception is detected while creating the Executable, we abort instead. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluateWithCallFrame): 2014-01-24 Oliver Hunt Put functions need to take a base object and a this value, and perform type checks on |this| https://bugs.webkit.org/show_bug.cgi?id=127594 Reviewed by Geoffrey Garen. Change the signature for static setter functions, and update uses * create_hash_table: * runtime/Lookup.h: (JSC::putEntry): * runtime/PutPropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::setRegExpConstructorInput): (JSC::setRegExpConstructorMultiline): 2014-01-24 Oliver Hunt Generic JSObject::put should handle static properties in the classinfo hierarchy https://bugs.webkit.org/show_bug.cgi?id=127523 Reviewed by Geoffrey Garen. This patch makes JSObject::put correctly call static setters defined by the ClassInfo. To make this not clobber performance, the ClassInfo HashTable now includes a flag to indicate that it contains setters. This required updating the lut generator so that it tracked (and emitted) this. The rest of the change was making a number of the methods take a VM rather than an ExecState*, so that Structure could set the getter/setter flags during construction (if necessary). This also means most objects do not need to perform a lookupPut manually anymore, so most custom ::put's are no longer needed. DOMWindow is the only exception as it has interesting security related semantics. * create_hash_table: * interpreter/CallFrame.h: (JSC::ExecState::arrayConstructorTable): (JSC::ExecState::arrayPrototypeTable): (JSC::ExecState::booleanPrototypeTable): (JSC::ExecState::dataViewTable): (JSC::ExecState::dateTable): (JSC::ExecState::dateConstructorTable): (JSC::ExecState::errorPrototypeTable): (JSC::ExecState::globalObjectTable): (JSC::ExecState::jsonTable): (JSC::ExecState::numberConstructorTable): (JSC::ExecState::numberPrototypeTable): (JSC::ExecState::objectConstructorTable): (JSC::ExecState::privateNamePrototypeTable): (JSC::ExecState::regExpTable): (JSC::ExecState::regExpConstructorTable): (JSC::ExecState::regExpPrototypeTable): (JSC::ExecState::stringConstructorTable): (JSC::ExecState::promisePrototypeTable): (JSC::ExecState::promiseConstructorTable): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::getOwnPropertySlot): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::getOwnPropertySlot): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::getOwnPropertySlot): * runtime/ClassInfo.h: (JSC::ClassInfo::propHashTable): * runtime/DateConstructor.cpp: (JSC::DateConstructor::getOwnPropertySlot): * runtime/DatePrototype.cpp: (JSC::DatePrototype::getOwnPropertySlot): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::getOwnPropertySlot): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::getOwnPropertySlot): * runtime/JSONObject.cpp: (JSC::JSONObject::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::put): (JSC::JSObject::deleteProperty): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getOwnPropertySlot): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::getOwnPropertySlot): * runtime/Lookup.h: (JSC::HashTable::copy): (JSC::putEntry): (JSC::lookupPut): * runtime/NamePrototype.cpp: (JSC::NamePrototype::getOwnPropertySlot): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::getOwnPropertySlot): * runtime/NumberConstructor.h: * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::getOwnPropertySlot): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::getOwnPropertySlot): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getOwnPropertySlot): * runtime/RegExpConstructor.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::getOwnPropertySlot): (JSC::RegExpObject::put): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::getOwnPropertySlot): * runtime/StringConstructor.cpp: (JSC::StringConstructor::getOwnPropertySlot): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::freezeTransition): (JSC::ClassInfo::hasStaticSetterOrReadonlyProperties): 2014-01-24 Commit Queue Unreviewed, rolling out r162713. http://trac.webkit.org/changeset/162713 https://bugs.webkit.org/show_bug.cgi?id=127593 broke media/network-no-source-const-shadow (Requested by thorton on #webkit). * create_hash_table: * interpreter/CallFrame.h: (JSC::ExecState::arrayConstructorTable): (JSC::ExecState::arrayPrototypeTable): (JSC::ExecState::booleanPrototypeTable): (JSC::ExecState::dataViewTable): (JSC::ExecState::dateTable): (JSC::ExecState::dateConstructorTable): (JSC::ExecState::errorPrototypeTable): (JSC::ExecState::globalObjectTable): (JSC::ExecState::jsonTable): (JSC::ExecState::numberConstructorTable): (JSC::ExecState::numberPrototypeTable): (JSC::ExecState::objectConstructorTable): (JSC::ExecState::privateNamePrototypeTable): (JSC::ExecState::regExpTable): (JSC::ExecState::regExpConstructorTable): (JSC::ExecState::regExpPrototypeTable): (JSC::ExecState::stringConstructorTable): (JSC::ExecState::promisePrototypeTable): (JSC::ExecState::promiseConstructorTable): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::getOwnPropertySlot): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::getOwnPropertySlot): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::getOwnPropertySlot): * runtime/ClassInfo.h: (JSC::ClassInfo::propHashTable): * runtime/DateConstructor.cpp: (JSC::DateConstructor::getOwnPropertySlot): * runtime/DatePrototype.cpp: (JSC::DatePrototype::getOwnPropertySlot): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::getOwnPropertySlot): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::getOwnPropertySlot): * runtime/JSONObject.cpp: (JSC::JSONObject::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::put): (JSC::JSObject::deleteProperty): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getOwnPropertySlot): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::getOwnPropertySlot): * runtime/Lookup.h: (JSC::HashTable::copy): (JSC::putEntry): (JSC::lookupPut): * runtime/NamePrototype.cpp: (JSC::NamePrototype::getOwnPropertySlot): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::getOwnPropertySlot): (JSC::NumberConstructor::put): * runtime/NumberConstructor.h: * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::getOwnPropertySlot): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::getOwnPropertySlot): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getOwnPropertySlot): (JSC::RegExpConstructor::put): * runtime/RegExpConstructor.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::getOwnPropertySlot): (JSC::RegExpObject::put): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::getOwnPropertySlot): * runtime/StringConstructor.cpp: (JSC::StringConstructor::getOwnPropertySlot): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::freezeTransition): 2014-01-24 Mark Lam ASSERT(!m_markedSpace.m_currentDelayedReleaseScope) reloading page in inspector. Reviewed by Mark Hahnenberg. 1. We should not enter a HeapIterationScope when we iterate the CodeBlocks. Apparently, iterating the CodeBlocks does not count as heap iteration. 2. If we're detaching the debugger due to the JSGlobalObject destructing, then we don't need to clear the debugger requests in the associated CodeBlocks. The JSGlobalObject destructing would mean that those CodeBlocks would be destructing too, and it may not be safe to access them anyway at this point. The assertion failure is because we had entered a HeapIterationScope while the JSGlobalObject is destructing, which in turn means that GC sweeping is in progress. It's not legal to iterate the heap while the GC is sweeping. Once we fixed the above 2 issues, we will no longer have the conditions that manifests this assertion failure. * debugger/Debugger.cpp: (JSC::Debugger::detach): (JSC::Debugger::setSteppingMode): (JSC::Debugger::toggleBreakpoint): (JSC::Debugger::clearBreakpoints): (JSC::Debugger::clearDebuggerRequests): * debugger/Debugger.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): 2014-01-24 Brent Fulgham [Win] Convert some NMake files to MSBuild project files https://bugs.webkit.org/show_bug.cgi?id=127579 Reviewed by Tim Horton. * JavaScriptCore.vcxproj/JavaScriptCore.make: Removed. * JavaScriptCore.vcxproj/JavaScriptCore.proj: Added. 2014-01-24 Mark Lam Fixed a bad assertion in CodeBlock::removeBreakpoint(). Reviewed by Joseph Pecoraro. * bytecode/CodeBlock.h: (JSC::CodeBlock::removeBreakpoint): 2014-01-24 Joseph Pecoraro fast/profiler tests ASSERTing after moving recompileAllJSFunctions off a timer https://bugs.webkit.org/show_bug.cgi?id=127566 Reviewed by Oliver Hunt. Make the VM handle recompilation as soon as possible after it is requested. * debugger/Debugger.cpp: (JSC::Debugger::recompileAllJSFunctions): When in a JavaScript stack, mark for recompilation when possible. * runtime/VMEntryScope.h: (JSC::VMEntryScope::setRecompilationNeeded): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): Handle recompilation when the top VMEntryScope is popped. Pass the needs recompilation flag up the stack if needed. 2014-01-24 Oliver Hunt Generic JSObject::put should handle static properties in the classinfo hierarchy https://bugs.webkit.org/show_bug.cgi?id=127523 Reviewed by Geoffrey Garen. This patch makes JSObject::put correctly call static setters defined by the ClassInfo. To make this not clobber performance, the ClassInfo HashTable now includes a flag to indicate that it contains setters. This required updating the lut generator so that it tracked (and emitted) this. The rest of the change was making a number of the methods take a VM rather than an ExecState*, so that Structure could set the getter/setter flags during construction (if necessary). This also means most objects do not need to perform a lookupPut manually anymore, so most custom ::put's are no longer needed. DOMWindow is the only exception as it has interesting security related semantics. * create_hash_table: * interpreter/CallFrame.h: (JSC::ExecState::arrayConstructorTable): (JSC::ExecState::arrayPrototypeTable): (JSC::ExecState::booleanPrototypeTable): (JSC::ExecState::dataViewTable): (JSC::ExecState::dateTable): (JSC::ExecState::dateConstructorTable): (JSC::ExecState::errorPrototypeTable): (JSC::ExecState::globalObjectTable): (JSC::ExecState::jsonTable): (JSC::ExecState::numberConstructorTable): (JSC::ExecState::numberPrototypeTable): (JSC::ExecState::objectConstructorTable): (JSC::ExecState::privateNamePrototypeTable): (JSC::ExecState::regExpTable): (JSC::ExecState::regExpConstructorTable): (JSC::ExecState::regExpPrototypeTable): (JSC::ExecState::stringConstructorTable): (JSC::ExecState::promisePrototypeTable): (JSC::ExecState::promiseConstructorTable): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::getOwnPropertySlot): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::getOwnPropertySlot): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::getOwnPropertySlot): * runtime/ClassInfo.h: (JSC::ClassInfo::propHashTable): * runtime/DateConstructor.cpp: (JSC::DateConstructor::getOwnPropertySlot): * runtime/DatePrototype.cpp: (JSC::DatePrototype::getOwnPropertySlot): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::getOwnPropertySlot): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::getOwnPropertySlot): * runtime/JSONObject.cpp: (JSC::JSONObject::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::put): (JSC::JSObject::deleteProperty): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getOwnPropertySlot): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::getOwnPropertySlot): * runtime/Lookup.h: (JSC::HashTable::copy): (JSC::putEntry): (JSC::lookupPut): * runtime/NamePrototype.cpp: (JSC::NamePrototype::getOwnPropertySlot): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::getOwnPropertySlot): * runtime/NumberConstructor.h: * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::getOwnPropertySlot): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::getOwnPropertySlot): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getOwnPropertySlot): * runtime/RegExpConstructor.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::getOwnPropertySlot): (JSC::RegExpObject::put): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::getOwnPropertySlot): * runtime/StringConstructor.cpp: (JSC::StringConstructor::getOwnPropertySlot): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::freezeTransition): (JSC::ClassInfo::hasStaticSetterOrReadonlyProperties): 2014-01-24 Mark Lam Skip op_profiler callbacks if !VM::m_enabledProfiler. https://bugs.webkit.org/show_bug.cgi?id=127567. Reviewed by Geoffrey Garen. The profiler may not be always active (recording). When it's not active (as in VM::m_enabledProfiler is null), then we might as well skip the op_profiler callbacks. The callbacks themselves were already previously gated by a VM::enabledProfiler() check. So, this change does not change any profiler behavior. For the DFG, we'll turn the op_profiler handling into speculation checks and OSR exit to the baseline JIT if the profiler becomes active. This brings the Octane score up to ~3000 from ~2840. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_will_call): (JSC::JIT::emit_op_profile_did_call): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_will_call): (JSC::JIT::emit_op_profile_did_call): * llint/LowLevelInterpreter.asm: * runtime/VM.h: (JSC::VM::enabledProfilerAddress): 2014-01-24 Mark Lam Removing the need for Debugger* and m_shouldPause op_debug check. Reviewed by Geoffrey Garen. This patch replaces the checking of the Debugger::m_shouldPause flag with a procedure to set a SteppingMode flag on all CodeBlocks under the management of the debugger. This simplifies the op_debug checking logic in all the execution engines. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: (JSC::CodeBlock::hasDebuggerRequests): (JSC::CodeBlock::debuggerRequestsAddress): (JSC::CodeBlock::setSteppingMode): (JSC::CodeBlock::clearDebuggerRequests): - CodeBlock::m_debuggerRequests is a union of m_numBreakpoints and the new m_steppingMode. The debugger can add/remove breakpoints to the CodeBlock as well as set the stepping mode. By having m_debuggerRequests as a union of the 2 bit fields, the op_debug code can now check if any of the 2 requests made on the CodeBlock is still in effect just by testing a single int. * debugger/Debugger.cpp: (JSC::Debugger::Debugger): (JSC::Debugger::detach): - This was bug from before where I forgot to clear the CodeBlock breakpoints before detaching. We now take care of it by clearing all debugger requests made to the CodeBlock. (JSC::Debugger::SetSteppingModeFunctor::SetSteppingModeFunctor): (JSC::Debugger::SetSteppingModeFunctor::operator()): (JSC::Debugger::setSteppingMode): (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::ClearCodeBlockDebuggerRequestsFunctor): (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator()): (JSC::Debugger::clearBreakpoints): (JSC::Debugger::ClearDebuggerRequestsFunctor::ClearDebuggerRequestsFunctor): (JSC::Debugger::ClearDebuggerRequestsFunctor::operator()): (JSC::Debugger::clearDebuggerRequests): - We need a distinct clearDebuggerRequests() from clearBreakpoints() because: 1. When we detach a globalObject, we only want to clear the debugger requests in CodeBlocks from that global. 2. Clearing the debugger requests in the CodeBlocks is not the same as clearing the breakpoints. The breakpoints are still in effect for the next time a globalObject is attached, or for other globalObjects that are still attached. (JSC::Debugger::setPauseOnNextStatement): (JSC::Debugger::breakProgram): (JSC::Debugger::stepIntoStatement): (JSC::Debugger::updateCallFrameAndPauseIfNeeded): (JSC::Debugger::pauseIfNeeded): (JSC::Debugger::exception): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didReachBreakpoint): * debugger/Debugger.h: - We're always going to support the debugger. So, there's no longer a need to check ENABLE(JAVASCRIPT_DEBUGGER). Removed the unneeded code. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * interpreter/Interpreter.cpp: (JSC::Interpreter::debug): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * llint/LowLevelInterpreter.asm: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::setDebugger): 2014-01-24 Michael Saboff ARM Offline assembler temporary register allocator has duplicate register when building fat binaries https://bugs.webkit.org/show_bug.cgi?id=127545 Reviewed by Mark Lam. Eliminate the conditional addition of r11/r7 from getModifiedListARMCommon as the .concat will add the new register to ARM_EXTRA_GPRS. If getModifiedListARMCommon is invoked a second time, there will be a second r11 or r7, which messes things up. Instead, r6 was added to ARM_EXTRA_GPRS. r6 is currently an unused register. * offlineasm/arm.rb: 2014-01-23 Joseph Pecoraro Move ContentSearchUtils, ScriptBreakpoint, and ScriptDebugListener into JavaScriptCore for inspector https://bugs.webkit.org/show_bug.cgi?id=127537 Reviewed by Timothy Hatcher. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/ContentSearchUtilities.cpp: Renamed from Source/WebCore/inspector/ContentSearchUtils.cpp. (Inspector::ContentSearchUtilities::createSearchRegexSource): (Inspector::ContentSearchUtilities::sizetExtractor): (Inspector::ContentSearchUtilities::textPositionFromOffset): (Inspector::ContentSearchUtilities::getRegularExpressionMatchesByLines): (Inspector::ContentSearchUtilities::lineEndings): (Inspector::ContentSearchUtilities::buildObjectForSearchMatch): (Inspector::ContentSearchUtilities::createSearchRegex): (Inspector::ContentSearchUtilities::countRegularExpressionMatches): (Inspector::ContentSearchUtilities::searchInTextByLines): (Inspector::ContentSearchUtilities::scriptCommentPattern): (Inspector::ContentSearchUtilities::stylesheetCommentPattern): (Inspector::ContentSearchUtilities::findMagicComment): (Inspector::ContentSearchUtilities::findScriptSourceURL): (Inspector::ContentSearchUtilities::findScriptSourceMapURL): (Inspector::ContentSearchUtilities::findStylesheetSourceMapURL): * inspector/ContentSearchUtilities.h: Renamed from Source/WebCore/inspector/ContentSearchUtils.h. * inspector/ScriptBreakpoint.h: Renamed from Source/WebCore/inspector/ScriptBreakpoint.h. (Inspector::ScriptBreakpointAction::ScriptBreakpointAction): (Inspector::ScriptBreakpoint::ScriptBreakpoint): * inspector/ScriptDebugListener.h: Renamed from Source/WebCore/inspector/ScriptDebugListener.h. (Inspector::ScriptDebugListener::Script::Script): (Inspector::ScriptDebugListener::~ScriptDebugListener): * runtime/RegExp.cpp: (JSC::RegExp::match): 2014-01-23 Joseph Pecoraro Move RegularExpression into JavaScriptCore for inspector https://bugs.webkit.org/show_bug.cgi?id=127526 Reviewed by Geoffrey Garen. Move RegularExpression into JavaScriptCore/yarr so it can be used later on by JavaScriptCore/inspector. Convert to the JSC::Yarr namespace. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * yarr/RegularExpression.cpp: Renamed from Source/WebCore/platform/text/RegularExpression.cpp. (JSC::Yarr::RegularExpression::Private::create): (JSC::Yarr::RegularExpression::Private::Private): (JSC::Yarr::RegularExpression::Private::compile): (JSC::Yarr::RegularExpression::RegularExpression): (JSC::Yarr::RegularExpression::~RegularExpression): (JSC::Yarr::RegularExpression::operator=): (JSC::Yarr::RegularExpression::match): (JSC::Yarr::RegularExpression::searchRev): (JSC::Yarr::RegularExpression::matchedLength): (JSC::Yarr::replace): (JSC::Yarr::RegularExpression::isValid): * yarr/RegularExpression.h: Renamed from Source/WebCore/platform/text/RegularExpression.h. 2014-01-23 Joseph Pecoraro Web Inspector: Remove recompileAllJSFunctions timer in ScriptDebugServer https://bugs.webkit.org/show_bug.cgi?id=127409 Reviewed by Geoffrey Garen. * inspector/InspectorAgentBase.h: When disconnecting agents, provide a InspectorDisconnectReason for the disconnection. It could be that an inspector frontend is just disconnecting or that the inspected object is going away entirely and we can avoid doing some work. * runtime/JSGlobalObjectDebuggable.h: * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::~JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::disconnectInternal): Pass different reasons for the different disconnects. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): * inspector/InspectorAgentRegistry.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): * inspector/JSGlobalObjectInspectorController.h: * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::willDestroyFrontendAndBackend): * inspector/agents/InspectorAgent.h: Pass InspectorDisconnectReason around where needed. 2014-01-23 Mark Lam Enable DFG for the Debugger and Profiler. Reviewed by Geoffrey Garen. In this patch, we implement DFG op_debug as a series of 3 checks: 1. Check if the debugger pointer is non-null. This is needed in case the debugger has been detached but the DFG code is still running on the stack. 2. Check if Debugger::m_shouldPause is true. 3. Check if CodeBlock::m_numBreakpoints is non-zero. These are the same 3 checks done in the LLINT and baselineJIT. But unlike the LLINT and baselineJIT, these DFG checks are implemented as speculationChecks. If the check fails, we OSR exit to the baselineJIT and let it do the work of servicing the op_debug callback. Stepping through code in the debugger would work the same way. The top function being debugged has to be a LLINT or baselineJIT function because we would have OSR exited if there is a breakpoint in that function. When we step out of that function to its caller, we expect that the caller will call back to the debugger at the next op_debug. If the caller function is a DFG function, the op_debug site will fail its speculation check on Debugger::m_shouldPause and deopt into a baselineJIT function. Execution continues from there as usual, and the debugger gets its callback. For the profile, op_profile_will_call and op_profile_did_call are implemented as simple runtime calls to service the profiler. With this patch, Octane performance with the WebInspector open jump from ~2000 to ~2500 (25% progression). * bytecode/CodeBlock.h: (JSC::CodeBlock::numBreakpointsAddress): * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * debugger/Debugger.cpp: (JSC::Debugger::toggleBreakpoint): - removed an obsolete assertion. The debugger can now handle DFG CodeBlocks too. * debugger/Debugger.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/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::debuggerAddress): 2014-01-23 Max Vujovic Remove CSS Custom Filters code and tests https://bugs.webkit.org/show_bug.cgi?id=127382 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2014-01-22 Brent Fulgham [Win] Update project and solution files for 64-bit builds. https://bugs.webkit.org/show_bug.cgi?id=127457 Reviewed by Eric Carlson. * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Add 64-bit target. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Update for VS2013 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Add missing file from project view. * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Update for VS2013 * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto 2014-01-22 Mark Lam Poor man's fast breakpoints for a 2.3x debugger speedup. Reviewed by Geoffrey Garen. Previously we gained back some performance (run at baseline JIT speeds) when the WebInspector is opened provided no breakpoints are set. This was achieved by simply skipping all op_debug callbacks to the debugger if no breakpoints are set. If any breakpoints are set, the debugger will set a m_needsOpDebugCallbacks flag which causes the callbacks to be called, and we don't get the baseline JIT speeds anymore. With this patch, we will now track the number of breakpoints set in the CodeBlock that they are set in. The LLINT and baseline JIT code will check CodeBlock::m_numBreakpoints to determine if the op_debug callbacks need to be called. With this, we will only enable op_debug callbacks for CodeBlocks that need it i.e. those with breakpoints set in them. Debugger::m_needsOpDebugCallbacks is now obsoleted. The LLINT and baseline JIT code still needs to check Debugger::m_shouldPause to determine if the debugger is in stepping mode and hence, needs op_debug callbacks enabled for everything until the debugger "continues" the run and exit stepping mode. Also in this patch, I fixed a regression in DOM breakpoints which relies Debugger::breakProgram() to pause the debugger. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): - Missed accounting for op_debug's new hasBreakpointFlag operand here when it was added. (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::hasOpDebugForLineAndColumn): - This is needed in Debugger::toggleBreakpoint() to determine if a breakpoint falls within a CodeBlock or not. Simply checking the bounds of the CodeBlock is insufficient. For example, let's say we have the following JS code: // begin global scope function f1() { function f2() { ... // set breakpoint here. } } // end global scope Using the CodeBlock bounds alone, the breakpoint above will to appear to be in the global program CodeBlock, and the CodeBlocks for function f1() and f2(). With CodeBlock::hasOpDebugForLineAndColumn() we can rule out the global program CodeBlock and f1(), and only apply the breakpoint to f2(0 where it belongs. CodeBlock::hasOpDebugForLineAndColumn() works by iterating over all the opcodes in the CodeBlock to look for op_debug's. For each op_debug, it calls CodeBlock::expressionRangeForBytecodeOffset() to do a binary seach to get the line and column info for that op_debug. This is a N * log(N) algorithm. However, a quick hands on test using the WebInspector (with this patch applied) to exercise setting, breaking on, and clearing breakpoints, as well as stepping through some code shows no noticeable degradation of the user experience compared to the baseline without this patch. * bytecode/CodeBlock.h: (JSC::CodeBlock::numBreakpoints): (JSC::CodeBlock::numBreakpointsOffset): (JSC::CodeBlock::addBreakpoint): (JSC::CodeBlock::removeBreakpoint): (JSC::CodeBlock::clearAllBreakpoints): * debugger/Breakpoint.h: - defined Breakpoint::unspecifiedColumn so that we can explicitly indicate when the WebInspector was setting a line breakpoint and did not provide a column value. CodeBlock::hasOpDebugForLineAndColumn() needs this information in order to loosen its matching criteria for op_debug bytecodes for the specified breakpoint line and column values provided by the debugger. Previously, we just hijack a 0 value column as an unspecified column. However, the WebInspector operates on 0-based ints for column values. Hence, 0 should be a valid column value and should not be hijacked to mean an unspecified column. * debugger/Debugger.cpp: (JSC::Debugger::Debugger): - added tracking of the VM that the debugger is used with. This is needed by Debugger::breakProgram(). The VM pointer is attained from the first JSGlobalObject that the debugger attaches to. When the debugger detaches from the last JSGlobalObject, it will nullify its VM pointer to allow a new one to be set on the next attach. We were always only using each debugger instance with one VM. This change makes it explicit with an assert to ensure that all globalObjects that the debugger attaches to beongs to the same VM. (JSC::Debugger::attach): (JSC::Debugger::detach): (JSC::Debugger::setShouldPause): (JSC::Debugger::registerCodeBlock): (JSC::Debugger::unregisterCodeBlock): - registerCodeBlock() is responsible for applying pre-existing breakpoints to new CodeBlocks being installed. Similarly, unregisterCodeBlock() clears the breakpoints. (JSC::Debugger::toggleBreakpoint): - This is the workhorse function that checks if a breakpoint falls within a CodeBlock or not. If it does, then it can either enable or disable said breakpoint in the CodeBlock. In the current implementation, enabling/disabling the breakpoint simply means incrementing/decrementing the CodeBlock's m_numBreakpoints. (JSC::Debugger::applyBreakpoints): (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor): (JSC::Debugger::ToggleBreakpointFunctor::operator()): (JSC::Debugger::toggleBreakpoint): - Iterates all relevant CodeBlocks and apply the specified breakpoint if appropriate. This is called when a new breakpoint is being defined by the WebInspector and needs to be applied to an already installed CodeBlock. (JSC::Debugger::setBreakpoint): (JSC::Debugger::removeBreakpoint): (JSC::Debugger::hasBreakpoint): (JSC::Debugger::ClearBreakpointsFunctor::ClearBreakpointsFunctor): (JSC::Debugger::ClearBreakpointsFunctor::operator()): (JSC::Debugger::clearBreakpoints): (JSC::Debugger::breakProgram): - Fixed a regression that broke DOM breakpoints. The issue is that with the skipping of op_debug callbacks, we don't always have an updated m_currentCallFrame. Normally, m_currentCallFrame is provided as arg in the op_debug callback. In this case, we can get the CallFrame* from m_vm->topCallFrame. (JSC::Debugger::updateCallFrameAndPauseIfNeeded): (JSC::Debugger::pauseIfNeeded): (JSC::Debugger::willExecuteProgram): * debugger/Debugger.h: (JSC::Debugger::Debugger): (JSC::Debugger::shouldPause): * heap/CodeBlockSet.h: (JSC::CodeBlockSet::iterate): * heap/Heap.h: (JSC::Heap::forEachCodeBlock): - Added utility to iterate all CodeBlocks in the heap / VM. * interpreter/Interpreter.cpp: (JSC::Interpreter::debug): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * llint/LowLevelInterpreter.asm: - These now checks CodeBlock::m_numBreakpoints and Debugger::m_shouldPause instead of Debugger::m_needsOpDebugCallbacks. * runtime/Executable.cpp: (JSC::ScriptExecutable::installCode): 2014-01-22 Myles C. Maxfield Remove CSS3_TEXT_DECORATION define https://bugs.webkit.org/show_bug.cgi?id=127333 This is required for unprefixing the text-decoration-* CSS properties. Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2014-01-22 Alexey Proskuryakov Update JS whitespace definition for changes in Unicode 6.3 https://bugs.webkit.org/show_bug.cgi?id=127450 Reviewed by Oliver Hunt. Covered by existing tests when running against a Unicode back-end that supports Unicode 6.3 or higher. * runtime/JSGlobalObjectFunctions.cpp: (JSC::isStrWhiteSpace): Explicitly allow U+180E MONGOLIAN VOWEL SEPARATOR, because we need to keep recognizing all characters that used to be whitespace. 2014-01-21 Mark Hahnenberg Registers used in writeBarrierOnOperand can cause clobbering on some platforms https://bugs.webkit.org/show_bug.cgi?id=127357 Reviewed by Filip Pizlo. Some platforms use t0 and t1 for their first two arguments, so using those to load the cell for the write barrier is a bad idea because it will get clobbered. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2014-01-21 Mark Rowe Mac production build fix. Move the shell script build phase to copy jsc into JavaScriptCore.framework out of the jsc target and in to the All target so that it's not run during production builds. Xcode appears to the parent directories of paths referenced in the Output Files of the build phase, which leads to problems when the SYMROOT for the JavaScriptCore framework and the jsc executables are later merged. I've also fixed the path to the Resources folder in the script while I'm here. On iOS the framework bundle is shallow so the correct destination is Resources/ rather than Versions/A/Resources. This is handled by tweaking the JAVASCRIPTCORE_RESOURCES_DIR configuration setting to be relative rather than a complete path so we can reuse it in the script. The references in JSC.xcconfig and ToolExecutable.xcconfig are updated to prepend JAVASCRIPTCORE_FRAMEWORKS_DIR to preserve their former values. * Configurations/Base.xcconfig: * Configurations/JSC.xcconfig: * Configurations/ToolExecutable.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: 2014-01-19 Andreas Kling JSC Parser: Shrink BindingNode. The "divot" and "end" source locations are always identical for BindingNodes, so store only "start" and "end" instead. 1.19 MB progression on Membuster3. Reviewed by Geoff Garen. * bytecompiler/NodesCodegen.cpp: (JSC::BindingNode::bindValue): * parser/ASTBuilder.h: (JSC::ASTBuilder::createBindingLocation): * parser/NodeConstructors.h: (JSC::BindingNode::create): (JSC::BindingNode::BindingNode): * parser/Nodes.h: (JSC::BindingNode::divotStart): (JSC::BindingNode::divotEnd): * parser/Parser.cpp: (JSC::Parser::createBindingPattern): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): 2014-01-20 Filip Pizlo op_captured_mov and op_new_captured_func in UnlinkedCodeBlocks should use the IdentifierMap instead of the strings directly https://bugs.webkit.org/show_bug.cgi?id=127311 Reviewed by Andreas Kling. This makes UnlinkedCodeBlocks use 32-bit instruction streams again. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedInstruction::UnlinkedInstruction): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::emitInitLazyRegister): (JSC::BytecodeGenerator::createArgumentsIfNecessary): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::watchableVariable): (JSC::BytecodeGenerator::hasWatchableVariable): 2014-01-20 Mark Lam Removing CodeBlock::opDebugBytecodeOffsetForLineAndColumn() and friends. Reviewed by Geoffrey Garen. We're changing plans and will be going with CodeBlock level breakpoints instead of bytecode level breakpoints. As a result, we no longer need the services of CodeBlock::opDebugBytecodeOffsetForLineAndColumn() (and friends). This patch will remove that unused code. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: * bytecode/LineColumnInfo.h: Removed. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): * bytecode/UnlinkedCodeBlock.h: 2014-01-20 Mark Hahnenberg CodeBlockSet::traceMarked doesn't need to visit the ownerExecutable https://bugs.webkit.org/show_bug.cgi?id=127301 Reviewed by Oliver Hunt. We used to just call CodeBlock::visitAggregate, but now we call visitChildren on the ownerExecutable, which is unnecessary. * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::traceMarked): 2014-01-20 Anders Carlsson Fix build. * heap/BlockAllocator.h: 2014-01-20 Anders Carlsson Stop using ThreadCondition in BlockAllocator https://bugs.webkit.org/show_bug.cgi?id=126313 Reviewed by Sam Weinig. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForDuration): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2014-01-19 Anders Carlsson Convert GCThreadSharedData over to STL threading primitives https://bugs.webkit.org/show_bug.cgi?id=127256 Reviewed by Andreas Kling. * heap/GCThread.cpp: (JSC::GCThread::waitForNextPhase): (JSC::GCThread::gcThreadMain): * heap/GCThreadSharedData.cpp: (JSC::GCThreadSharedData::GCThreadSharedData): (JSC::GCThreadSharedData::~GCThreadSharedData): (JSC::GCThreadSharedData::startNextPhase): (JSC::GCThreadSharedData::endCurrentPhase): (JSC::GCThreadSharedData::didStartMarking): (JSC::GCThreadSharedData::didFinishMarking): * heap/GCThreadSharedData.h: * heap/SlotVisitor.cpp: (JSC::SlotVisitor::donateKnownParallel): (JSC::SlotVisitor::drainFromShared): 2014-01-18 Andreas Kling CodeBlock: Size m_callLinkInfos and m_byValInfos to fit earlier. Reviewed by Anders Carlsson. * bytecode/CodeBlock.h: (JSC::CodeBlock::setNumberOfByValInfos): (JSC::CodeBlock::setNumberOfCallLinkInfos): Use resizeToFit() instead of grow() for these vectors, since we know the final size here. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): No need to shrink here anymore. We were not even shrinking m_byValInfo before! 2014-01-18 Andreas Kling CodeBlock: Size m_function{Exprs,Decls} to fit from creation. Reviewed by Anders Carlsson. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): Use resizeToFit() instead of grow() for m_functionExprs and m_functionDecls since we know they will never change size. (JSC::CodeBlock::shrinkToFit): No need to shrink them here anymore. 2014-01-18 Andreas Kling Remove unused CodeBlock::m_additionalIdentifiers member. Reviewed by Anders Carlsson. * bytecode/CodeBlock.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::shrinkToFit): Remove m_additionalIdentifiers, nothing uses it. 2014-01-18 Andreas Kling Remove two unused CodeBlock functions. Kill copyPostParseDataFrom() and copyPostParseDataFromAlternative() since they are not used. Reviewed by Anders Carlsson. * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: 2014-01-18 Andreas Kling CodeBlock: Size m_exceptionHandlers to fit from creation. Avoid allocation churn for CodeBlock::m_exceptionHandlers. Reviewed by Anders Carlsson. * bytecode/CodeBlock.h: Removed unused CodeBlock::allocateHandlers() function. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): Use resizeToFit() instead of grow() for m_exceptionHandlers since we know it's never going to change size. (JSC::CodeBlock::shrinkToFit): No need to shrink m_exceptionHandlers here since it's already the perfect size. 2014-01-18 Mark Lam Add a hasBreakpointFlag arg to the op_debug bytecode. https://bugs.webkit.org/show_bug.cgi?id=127230. Reviewed by Geoffrey Garen. This is in anticipation of upcoming changes to support bytecode level breakpoints. This patch adds the flag to the op_debug bytecode and initializes it, but does not use it yet. * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitDebugHook): * llint/LowLevelInterpreter.asm: 2014-01-18 Alberto Garcia JavaScriptCore uses PLATFORM(MAC) when it means OS(DARWIN) https://bugs.webkit.org/show_bug.cgi?id=99683 Reviewed by Anders Carlsson. * jit/ThunkGenerators.cpp: * tools/CodeProfile.cpp: (JSC::symbolName): (JSC::CodeProfile::sample): 2014-01-18 Anders Carlsson Remove ENABLE_THREADED_HTML_PARSER defines everywhere https://bugs.webkit.org/show_bug.cgi?id=127225 Reviewed by Andreas Kling. This concludes the removal of over 8.8 million lines of threaded parser code. * Configurations/FeatureDefines.xcconfig: 2014-01-18 Mark Lam Adding UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn().. https://bugs.webkit.org/show_bug.cgi?id=127127. Reviewed by Geoffrey Garen. In order to implement bytecode level breakpoints, we need a mechanism for computing the best fit op_debug bytecode offset for any valid given line and column value in the source. The "best fit" op_debug bytecode in this case is defined below in the comment for UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn(). * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::opDebugBytecodeOffsetForLineAndColumn): - Convert the line and column to unlinked line and column values and pass them to UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn() to do the real work. * bytecode/CodeBlock.h: * bytecode/LineColumnInfo.h: Added. (JSC::LineColumnInfo::operator <): (JSC::LineColumnInfo::LineColumnPair::LineColumnPair): (JSC::LineColumnInfo::operator ==): (JSC::LineColumnInfo::operator !=): (JSC::LineColumnInfo::operator <=): (JSC::LineColumnInfo::operator >): (JSC::LineColumnInfo::operator >=): * bytecode/LineInfo.h: Removed. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::decodeExpressionRangeLineAndColumn): - Factored this out of expressionRangeForBytecodeOffset() so that it can be called from multiple places. (JSC::dumpLineColumnEntry): (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): (JSC::UnlinkedCodeBlock::dumpOpDebugLineColumnInfoList): - Some dumpers for debugging use only. (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): (JSC::UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn): - Finds the earliest op_debug bytecode whose line and column matches the specified line and column values. If an exact match is not found, then finds the nearest op_debug bytecode that precedes the specified line and column values. If there are more than one op_debug at that preceding line and column value, then the earliest of those op_debug bytecodes will be be selected. The offset of the selected bytecode will be returned. We want the earliest one because when we have multiple op_debug bytecodes that map to a given line and column, a debugger user would expect to break on the first one and step through the rest thereafter if needed. (JSC::compareLineColumnInfo): (JSC::UnlinkedCodeBlock::opDebugLineColumnInfoList): - Creates the sorted opDebugLineColumnInfoList on demand. This list is stored in the UnlinkedCodeBlock's rareData. * bytecode/UnlinkedCodeBlock.h: 2014-01-18 Zan Dobersek Inspector scripts are not compatible with Python v3 https://bugs.webkit.org/show_bug.cgi?id=127128 Reviewed by Benjamin Poulain. * inspector/scripts/generate-combined-inspector-json.py: Turn print statements into print function calls. * inspector/scripts/jsmin.py: Try importing the StringIO class from the StringIO module (which will work for Python v2) or, on import error, import the class from the io module (which will work for Python v3). 2014-01-17 Anders Carlsson String::is8Bit() crashes if m_impl is null, handle this. * API/OpaqueJSString.h: (OpaqueJSString::OpaqueJSString): 2014-01-17 Anders Carlsson Try to fix the Windows build. * API/OpaqueJSString.cpp: (OpaqueJSString::~OpaqueJSString): (OpaqueJSString::characters): * API/OpaqueJSString.h: (OpaqueJSString::OpaqueJSString): 2014-01-17 Anders Carlsson Get rid of OpaqueJSString::deprecatedCharacters() https://bugs.webkit.org/show_bug.cgi?id=127161 Reviewed by Sam Weinig. Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra code paths for the 8-bit cases. Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer. Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr is called and the backing string is 8-bit. This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before. (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it causing an unsafe upconversion to a 16-bit string). * API/JSStringRef.cpp: (JSStringGetCharactersPtr): Call OpaqueJSString::characters. (JSStringGetUTF8CString): Add a code path that handles 8-bit strings. (JSStringIsEqual): Call OpaqueJSString::equal. * API/JSStringRefCF.cpp: (JSStringCreateWithCFString): Reformat the code to use an early return instead of putting most of the code inside the body of an if statement. (JSStringCopyCFString): Create an 8-bit CFStringRef if possible. * API/OpaqueJSString.cpp: (OpaqueJSString::create): Use nullptr. (OpaqueJSString::~OpaqueJSString): Free m_characters. (OpaqueJSString::characters): Do the up-conversion and store the result in m_characters. (OpaqueJSString::equal): New helper function. * API/OpaqueJSString.h: (OpaqueJSString::is8Bit): New function that returns whether a string is 8-bit or not. (OpaqueJSString::characters8): (OpaqueJSString::characters16): Add getters. 2014-01-17 Peter Molnar Remove workaround for compilers not supporting deleted functions https://bugs.webkit.org/show_bug.cgi?id=127166 Reviewed by Andreas Kling. * inspector/InspectorAgentRegistry.h: 2014-01-17 Commit Queue Unreviewed, rolling out r162185, r162186, and r162187. http://trac.webkit.org/changeset/162185 http://trac.webkit.org/changeset/162186 http://trac.webkit.org/changeset/162187 https://bugs.webkit.org/show_bug.cgi?id=127164 Broke JSStringCreateWithCharactersNoCopy, as evidenced by a JSC API test (Requested by ap on #webkit). * API/JSStringRef.cpp: (JSStringGetCharactersPtr): (JSStringGetUTF8CString): (JSStringIsEqual): * API/JSStringRefCF.cpp: (JSStringCreateWithCFString): (JSStringCopyCFString): * API/OpaqueJSString.cpp: (OpaqueJSString::create): (OpaqueJSString::identifier): * API/OpaqueJSString.h: (OpaqueJSString::create): (OpaqueJSString::characters): (OpaqueJSString::deprecatedCharacters): (OpaqueJSString::OpaqueJSString): 2014-01-16 Anders Carlsson Export OpaqueJSString destructor. * API/OpaqueJSString.h: 2014-01-16 Anders Carlsson Build fix. * API/OpaqueJSString.h: 2014-01-16 Anders Carlsson Get rid of OpaqueJSString::deprecatedCharacters() https://bugs.webkit.org/show_bug.cgi?id=127161 Reviewed by Sam Weinig. Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra code paths for the 8-bit cases. Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer. Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr is called. This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before. (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it causing an unsafe upconversion to a 16-bit string). * API/JSStringRef.cpp: (JSStringGetCharactersPtr): Call OpaqueJSString::characters. (JSStringGetUTF8CString): Add a code path that handles 8-bit strings. (JSStringIsEqual): Call OpaqueJSString::equal. * API/JSStringRefCF.cpp: (JSStringCreateWithCFString): Reformat the code to use an early return instead of putting most of the code inside the body of an if statement. (JSStringCopyCFString): Create an 8-bit CFStringRef if possible. * API/OpaqueJSString.cpp: (OpaqueJSString::create): Use nullptr. (OpaqueJSString::~OpaqueJSString): Free m_characters. (OpaqueJSString::characters): Do the up-conversion and store the result in m_characters. (OpaqueJSString::equal): New helper function. * API/OpaqueJSString.h: (OpaqueJSString::is8Bit): New function that returns whether a string is 8-bit or not. (OpaqueJSString::characters8): (OpaqueJSString::characters16): Add getters. 2014-01-16 Anders Carlsson Change all uses of FINAL to final now that all our compilers support it https://bugs.webkit.org/show_bug.cgi?id=127142 Reviewed by Benjamin Poulain. * inspector/JSGlobalObjectInspectorController.h: * inspector/agents/InspectorAgent.h: * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspectorDebuggableConnection.h: * inspector/scripts/CodeGeneratorInspector.py: (Generator.go): * runtime/JSGlobalObjectDebuggable.h: * runtime/JSPromiseReaction.cpp: 2014-01-16 Oliver Hunt throwing an objc object (or general binding object) triggers an assertion https://bugs.webkit.org/show_bug.cgi?id=127146 Reviewed by Alexey Proskuryakov. This is simply a bogus assertion as we can't guarantee a bindings object won't intercept assignment to .stack * interpreter/Interpreter.cpp: (JSC::Interpreter::unwind): 2014-01-16 Peter Molnar Remove workaround for compilers not supporting explicit override control https://bugs.webkit.org/show_bug.cgi?id=127111 Reviewed by Anders Carlsson. Now all compilers support explicit override control, this workaround can be removed. * API/JSAPIWrapperObject.mm: * API/JSCallbackObject.h: * API/JSManagedValue.mm: * API/JSScriptRef.cpp: * bytecode/CodeBlock.h: * bytecode/CodeBlockJettisoningWatchpoint.h: * bytecode/ProfiledCodeBlockJettisoningWatchpoint.h: * bytecode/StructureStubClearingWatchpoint.h: * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: * dfg/DFGFailedFinalizer.h: * dfg/DFGJITCode.h: * dfg/DFGJITFinalizer.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: * dfg/DFGSpeculativeJIT64.cpp: * heap/Heap.h: * heap/IncrementalSweeper.h: * heap/SuperRegion.h: * inspector/InspectorValues.h: * inspector/JSGlobalObjectInspectorController.h: * inspector/agents/InspectorAgent.h: * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspectorDebuggableConnection.h: * inspector/scripts/CodeGeneratorInspector.py: (Generator.go): * jit/ClosureCallStubRoutine.h: * jit/ExecutableAllocatorFixedVMPool.cpp: * jit/GCAwareJITStubRoutine.h: * jit/JITCode.h: * jit/JITToDFGDeferredCompilationCallback.h: * parser/Nodes.h: * parser/SourceProvider.h: * runtime/DataView.h: * runtime/GCActivityCallback.h: * runtime/GenericTypedArrayView.h: * runtime/JSGlobalObjectDebuggable.h: * runtime/JSPromiseReaction.cpp: * runtime/RegExpCache.h: * runtime/SimpleTypedArrayController.h: * runtime/SymbolTable.h: * runtime/WeakMapData.h: 2014-01-15 Joseph Pecoraro [iOS] Clean up REMOTE_INSPECTOR code in OpenSource after the iOS merge https://bugs.webkit.org/show_bug.cgi?id=127069 Reviewed by Timothy Hatcher. * JavaScriptCore.xcodeproj/project.pbxproj: Export XPCConnection because it is needed by RemoteInspector.h. * inspector/remote/RemoteInspectorXPCConnection.h: * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::startDisabled): (Inspector::RemoteInspector::shared): Allow RemoteInspector singleton to start disabled. 2014-01-15 Brian Burg Web Inspector: capture probe samples on the backend https://bugs.webkit.org/show_bug.cgi?id=126668 Reviewed by Joseph Pecoraro. Add the 'probe' breakpoint action to the protocol. Change the setBreakpoint commands to return a list of assigned breakpoint action identifiers Add a type for breakpoint action identifiers. Add an event for sending captured probe samples to the inspector frontend. * inspector/protocol/Debugger.json: 2014-01-10 Mark Hahnenberg Copying should be generational https://bugs.webkit.org/show_bug.cgi?id=126555 Reviewed by Geoffrey Garen. This patch adds support for copying to our generational collector. Eden collections always trigger copying. Full collections use our normal fragmentation-based heuristics. The way this works is that the CopiedSpace now has the notion of an old generation set of CopiedBlocks and a new generation of CopiedBlocks. During each mutator cycle new CopiedSpace allocations reside in the new generation. When a collection occurs, those blocks are moved to the old generation. One key thing to remember is that both new and old generation objects in the MarkedSpace can refer to old or new generation allocations in CopiedSpace. This is why we must fire write barriers when assigning to an old (MarkedSpace) object's Butterfly. * heap/CopiedAllocator.h: (JSC::CopiedAllocator::tryAllocateDuringCopying): * heap/CopiedBlock.h: (JSC::CopiedBlock::CopiedBlock): (JSC::CopiedBlock::didEvacuateBytes): (JSC::CopiedBlock::isOld): (JSC::CopiedBlock::didPromote): * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): (JSC::CopiedBlock::reportLiveBytesDuringCopying): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::CopiedSpace): (JSC::CopiedSpace::~CopiedSpace): (JSC::CopiedSpace::init): (JSC::CopiedSpace::tryAllocateOversize): (JSC::CopiedSpace::tryReallocateOversize): (JSC::CopiedSpace::doneFillingBlock): (JSC::CopiedSpace::didStartFullCollection): (JSC::CopiedSpace::doneCopying): (JSC::CopiedSpace::size): (JSC::CopiedSpace::capacity): (JSC::CopiedSpace::isPagedOut): * heap/CopiedSpace.h: (JSC::CopiedSpace::CopiedGeneration::CopiedGeneration): * heap/CopiedSpaceInlines.h: (JSC::CopiedSpace::contains): (JSC::CopiedSpace::recycleEvacuatedBlock): (JSC::CopiedSpace::allocateBlock): (JSC::CopiedSpace::startedCopying): * heap/CopyVisitor.cpp: (JSC::CopyVisitor::copyFromShared): * heap/CopyVisitorInlines.h: (JSC::CopyVisitor::allocateNewSpace): (JSC::CopyVisitor::allocateNewSpaceSlow): * heap/GCThreadSharedData.cpp: (JSC::GCThreadSharedData::didStartCopying): * heap/Heap.cpp: (JSC::Heap::copyBackingStores): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::copyLater): * heap/TinyBloomFilter.h: (JSC::TinyBloomFilter::add): 2014-01-14 Mark Lam ASSERTION FAILED: !hasError() in JSC::Parser::createSavePoint(). https://bugs.webkit.org/show_bug.cgi?id=126990. Reviewed by Geoffrey Garen. * parser/Parser.cpp: (JSC::Parser::parseConstDeclarationList): - We were missing an error check after attempting to parse an initializer expression. This is now fixed. 2014-01-14 Joseph Pecoraro Web Inspector: For Remote Inspection link WebProcess's to their parent UIProcess https://bugs.webkit.org/show_bug.cgi?id=126995 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForDebuggable): For each WebView, list the parent process. Listing the parent per WebView is already supported back when we supported processes that could host WebViews for multiple applications. * inspector/remote/RemoteInspectorConstants.h: Add a separate key for the bundle identifier, separate from application identifier. * inspector/remote/RemoteInspectorDebuggable.cpp: (Inspector::RemoteInspectorDebuggable::info): * inspector/remote/RemoteInspectorDebuggable.h: (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo): (Inspector::RemoteInspectorDebuggableInfo::hasParentProcess): If a RemoteInspectorDebuggable has a non-zero parent process identifier it is a proxy for the parent process. 2014-01-14 Brian J. Burg Add ENABLE(WEB_REPLAY) feature flag to the build system https://bugs.webkit.org/show_bug.cgi?id=126949 Reviewed by Joseph Pecoraro. * Configurations/FeatureDefines.xcconfig: 2014-01-14 Peter Molnar [EFL] FTL buildfix, add missing includes https://bugs.webkit.org/show_bug.cgi?id=126641 Reviewed by Csaba Osztrogonác. * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExitCompiler.cpp: 2014-01-14 Joseph Pecoraro Web Inspector: RemoteInspector::updateDebuggable may miss a push https://bugs.webkit.org/show_bug.cgi?id=126965 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::updateDebuggable): Always push an update. If a debuggable went from allowed to not allowed, we would have missed pushing an update. 2014-01-13 Mark Hahnenberg Performance regression on dromaeo due to generational marking https://bugs.webkit.org/show_bug.cgi?id=126901 Reviewed by Oliver Hunt. We were seeing some performance regression with ENABLE_GGC == 0, so this patch ifdefs out more things to get rid of the additional overhead. * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::writeBarrier): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearMarksWithCollectionType): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::resetAllocators): * heap/MarkedSpace.h: (JSC::MarkedSpace::didAllocateInBlock): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::reportExtraMemoryUsage): 2014-01-13 Brian Burg Web Inspector: protocol generator should support integer-typed declarations https://bugs.webkit.org/show_bug.cgi?id=126828 Reviewed by Joseph Pecoraro. Add new binding classes for parameter/ad-hoc and normal integer type declarations. * inspector/scripts/CodeGeneratorInspector.py: (TypeBindings.create_type_declaration_): (TypeBindings.create_type_declaration_.PlainInteger): (TypeBindings.create_type_declaration_.PlainInteger.resolve_inner): (TypeBindings.create_type_declaration_.PlainInteger.request_user_runtime_cast): (TypeBindings.create_type_declaration_.PlainInteger.request_internal_runtime_cast): (TypeBindings.create_type_declaration_.PlainInteger.get_code_generator): (TypeBindings.create_type_declaration_.PlainInteger.get_validator_call_text): (TypeBindings.create_type_declaration_.PlainInteger.reduce_to_raw_type): (TypeBindings.create_type_declaration_.PlainInteger.get_type_model): (TypeBindings.create_type_declaration_.PlainInteger.get_setter_value_expression_pattern): (TypeBindings.create_type_declaration_.PlainInteger.get_array_item_c_type_text): (TypeBindings.create_type_declaration_.TypedefInteger): (TypeBindings.create_type_declaration_.TypedefInteger.resolve_inner): (TypeBindings.create_type_declaration_.TypedefInteger.request_user_runtime_cast): (TypeBindings.create_type_declaration_.TypedefInteger.request_internal_runtime_cast): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.generate_type_builder): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.generate_type_builder.int): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.register_use): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.get_generate_pass_id): (TypeBindings.create_type_declaration_.TypedefInteger.get_validator_call_text): (TypeBindings.create_type_declaration_.TypedefInteger.reduce_to_raw_type): (TypeBindings.create_type_declaration_.TypedefInteger.get_type_model): (TypeBindings.create_type_declaration_.TypedefInteger.get_setter_value_expression_pattern): (TypeBindings.create_type_declaration_.TypedefInteger.get_array_item_c_type_text): 2014-01-13 Zalan Bujtas Enable SUBPIXEL_LAYOUT on Mac Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2014-01-13 Zan Dobersek Unreviewed. Changes in r161686 are exposing a bug in GCC where the global .cfi_startproc directive is not inserted early enough into the generated assembler code when building in debug mode, causing compilation failures on ports using the GCC compilers. To work around the problem, only utilize the OFFLINE_ASM_* macros that use .cfi_ directives when compiling with Clang. * llint/LowLevelInterpreter.cpp: 2014-01-12 Commit Queue Unreviewed, rolling out r161840. http://trac.webkit.org/changeset/161840 https://bugs.webkit.org/show_bug.cgi?id=126870 Caused jsscore and layout test failures (Requested by smfr on #webkit). * API/JSValueRef.cpp: (JSValueMakeFromJSONString): * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): * inspector/InspectorValues.cpp: * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): * runtime/Identifier.h: (JSC::Identifier::characters): * runtime/JSStringBuilder.h: (JSC::JSStringBuilder::append): 2014-01-12 Darin Adler Add deprecatedCharacters as a synonym for characters and convert most call sites https://bugs.webkit.org/show_bug.cgi?id=126858 Reviewed by Anders Carlsson. * API/JSStringRef.cpp: (JSStringGetCharactersPtr): (JSStringGetUTF8CString): (JSStringIsEqual): * API/JSStringRefCF.cpp: (JSStringCopyCFString): * API/OpaqueJSString.h: (OpaqueJSString::characters): (OpaqueJSString::deprecatedCharacters): (OpaqueJSString::length): (OpaqueJSString::OpaqueJSString): * inspector/InspectorValues.cpp: (Inspector::InspectorValue::parseJSON): * runtime/JSGlobalObjectFunctions.cpp: (JSC::parseInt): * runtime/StringPrototype.cpp: (JSC::localeCompare): (JSC::stringProtoFuncFontsize): (JSC::stringProtoFuncLink): Use deprecatedCharacters instead of characters. 2014-01-12 Darin Adler Reduce use of String::characters https://bugs.webkit.org/show_bug.cgi?id=126854 Reviewed by Sam Weinig. * API/JSValueRef.cpp: (JSValueMakeFromJSONString): Use characters16 instead of characters for 16-bit case. Had to remove length check because an empty string could be either 8 bit or 16 bit. Don't need a null string check before calling is8Bit because JSStringRef can't hold a null string. * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): Use the existing string here instead of creating a new one by calling characters and length on the old string. I think this may be left over from when string types were not the same in JavaScriptCore and WebCore. Also rewrite the property names loop to use modern for syntax and fewer locals. * inspector/InspectorValues.cpp: (Inspector::escapeChar): Changed to use appendLiteral instead of hard-coding string lengths. Moved handling of "<" and ">" in here instead of at the call site. (Inspector::doubleQuoteString): Simplify the code so there is no use of characters and length. This is still an inefficient way of doing this job and could use a rethink. * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): Use RetainPtr, createCFString, and the conversion from CFStringRef to WTF::String to remove a lot of unneeded code. * runtime/Identifier.h: Removed unneeded Identifier::characters function. * runtime/JSStringBuilder.h: (JSC::JSStringBuilder::append): Use characters16 instead of characters function here, since we have already checked is8Bit above. 2014-01-12 Andy Estes [iOS] Enable the JSC Objective-C API Rubber-stamped by Simon Fraser. * API/JSBase.h: 2014-01-12 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.am: Add inline-and-minify-stylesheets-and-scripts.py to EXTRA_DIST and fix InjectedScriptSource.h generation rule. * GNUmakefile.list.am: Move InjectedScriptSource.h to built_nosources to make sure it's not disted. 2014-01-11 Anders Carlsson Try again to fix the build. * inspector/InspectorAgentRegistry.cpp: * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson Try to prevent the Vector copy constructor from being instantiated. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson Try something else. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::~InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Dean Jackson [JSC] Revise typed array implementations to match ECMAScript and WebGL Specification https://bugs.webkit.org/show_bug.cgi?id=126754 Reviewed by Filip Pizlo. The ECMAScript specification forbids calling the typed array constructors without using "new". Change the call data to return none so we throw and exception in these cases. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-11 Anders Carlsson Try to fix the build by introducing a constructor. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson * inspector/InspectorAgentRegistry.h: Remove an unused function. 2014-01-11 Anders Carlsson InspectorAgentRegistry should use std::unique_ptr https://bugs.webkit.org/show_bug.cgi?id=126826 Reviewed by Sam Weinig. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::append): * inspector/InspectorAgentRegistry.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): * inspector/agents/InspectorAgent.h: 2014-01-10 Joseph Pecoraro Web Inspector: Push InspectorAgent down into JSC, give JSC an InspectorController https://bugs.webkit.org/show_bug.cgi?id=126763 Reviewed by Timothy Hatcher. Introduce JSGlobalObjectInspectorController. This is the InspectorController for a JSContext. It is created by the JSGlobalObject Remote Inspector Debuggable when a remote frontend connects, and is destroyed when the remote frontend disconnects of the JSGlobalObject is destroyed. * inspector/JSGlobalObjectInspectorController.h: Added. * inspector/JSGlobalObjectInspectorController.cpp: Added. (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController): (Inspector::JSGlobalObjectInspectorController::connectFrontend): (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend): (Inspector::JSGlobalObjectInspectorController::functionCallHandler): (Inspector::JSGlobalObjectInspectorController::evaluateHandler): Create/destory agents, create/destroy dispatches, implement InspectorEnvironment. * runtime/JSGlobalObjectDebuggable.h: * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::~JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Forward actions to the InspectorController object. * inspector/agents/InspectorAgent.h: Renamed from Source/WebCore/inspector/InspectorAgent.h. * inspector/agents/InspectorAgent.cpp: Renamed from Source/WebCore/inspector/InspectorAgent.cpp. (Inspector::InspectorAgent::InspectorAgent): (Inspector::InspectorAgent::~InspectorAgent): (Inspector::InspectorAgent::didCreateFrontendAndBackend): (Inspector::InspectorAgent::inspect): (Inspector::InspectorAgent::evaluateForTestInFrontend): Implement InspectorAgent in JavaScriptCore in namespace Inspector. * JavaScriptCore.xcodeproj/project.pbxproj: * CMakeLists.txt: * ChangeLog: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/copy-files.cmd: Add files and new inspector/agents subdirectory. 2014-01-10 Commit Queue Unreviewed, rolling out r161702. http://trac.webkit.org/changeset/161702 https://bugs.webkit.org/show_bug.cgi?id=126803 Broke multiple tests (Requested by ap on #webkit). * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-10 David Kilzer Clean up architectures in xcconfig files Reviewed by Andy Estes. * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: Remove armv6, ppc. * Configurations/ToolExecutable.xcconfig: Sort. - Add new arch. 2014-01-10 Dean Jackson [JSC] Revise typed array implementations to match ECMAScript and WebGL Specification https://bugs.webkit.org/show_bug.cgi?id=126754 Reviewed by Filip Pizlo. The ECMAScript specification forbids calling the typed array constructors without using "new". Change the call data to return none so we throw and exception in these cases. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-10 Benjamin Poulain Remove the BlackBerry port from trunk https://bugs.webkit.org/show_bug.cgi?id=126715 Reviewed by Anders Carlsson. * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::replaceWithJump): (JSC::ARMv7Assembler::maxJumpReplacementSize): (JSC::ARMv7Assembler::cacheFlush): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): * heap/MachineStackMarker.cpp: (JSC::getPlatformThreadRegisters): (JSC::otherThreadStackPointer): (JSC::freePlatformThreadRegisters): * jit/ExecutableAllocator.h: 2014-01-10 Joseph Pecoraro Web Inspector: Remove unimplemented or static ScriptDebugServer features https://bugs.webkit.org/show_bug.cgi?id=126784 Reviewed by Timothy Hatcher. * inspector/protocol/Debugger.json: 2014-01-10 Michael Saboff REGRESSION(C stack work): stack traces no longer work in CrashTracer, lldb, and other tools https://bugs.webkit.org/show_bug.cgi?id=126764 Reviewed by Geoffrey Garen. Updated callToJavaScript and cllToNativeFunction to properly replicate the caller's return PC and frame pointer in the sentinel frame. For X86-64, added .cfi_ directives to create eh_frame info for all LLInt symbols so that the various unwinding code understands that we are using a separate JS stack referenced by BP and at what offsets in that frame the prior PC (register 16) and prior BP (register 6) can be found. These two changes are sufficient for stack tracing to work for Mac OSX. * llint/LowLevelInterpreter.cpp: * llint/LowLevelInterpreter64.asm: 2014-01-10 Tamas Gergely [EFL][JSC] Enable udis86 disassembler on efl. https://bugs.webkit.org/show_bug.cgi?id=125502 Reviewed by Michael Saboff. Enable udis86 disassembler on efl and fix build warnings. * CMakeLists.txt: Add udis86 disassembler source files. * disassembler/udis86/udis86_decode.c: (decode_modrm_rm): Build warning fixes. * disassembler/udis86/udis86_syn-att.c: (gen_operand): Build warning fixes. * disassembler/udis86/udis86_syn-intel.c: (gen_operand): Build warning fixes. * disassembler/udis86/udis86_types.h: Correct FMT64 for uint64_t. 2014-01-09 Benjamin Poulain Remove the BlackBerry files outside WebCore https://bugs.webkit.org/show_bug.cgi?id=126715 Reviewed by Anders Carlsson. * PlatformBlackBerry.cmake: Removed. * runtime/GCActivityCallbackBlackBerry.cpp: Removed. * shell/PlatformBlackBerry.cmake: Removed. 2014-01-10 Geoffrey Garen Removed Blackberry #ifdefs and platform code from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=126757 Reviewed by Sam Weinig. * PlatformBlackBerry.cmake: Removed. * heap/HeapTimer.cpp: * heap/HeapTimer.h: * heap/IncrementalSweeper.cpp: * heap/IncrementalSweeper.h: * jsc.cpp: (main): * runtime/GCActivityCallbackBlackBerry.cpp: Removed. * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): 2014-01-07 Mark Hahnenberg Marking should be generational https://bugs.webkit.org/show_bug.cgi?id=126552 Reviewed by Geoffrey Garen. Re-marking the same objects over and over is a waste of effort. This patch implements the sticky mark bit algorithm (along with our already-present write barriers) to reduce overhead during garbage collection caused by rescanning objects. There are now two collection modes, EdenCollection and FullCollection. EdenCollections only visit new objects or objects that were added to the remembered set by a write barrier. FullCollections are normal collections that visit all objects regardless of their generation. In this patch EdenCollections do not do anything in CopiedSpace. This will be fixed in https://bugs.webkit.org/show_bug.cgi?id=126555. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::didStartFullCollection): * heap/CopiedSpace.h: (JSC::CopiedSpace::heap): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::addToRememberedSet): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): (JSC::Heap::writeBarrier): * heap/Heap.h: (JSC::Heap::isInRememberedSet): (JSC::Heap::operationInProgress): (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): (JSC::MarkStackArray::clear): (JSC::MarkStackArray::fillVector): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::isListPagedOut): (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): (JSC::MarkedAllocator::reset): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearRememberedSet): (JSC::MarkedBlock::clearMarksWithCollectionType): (JSC::MarkedBlock::lastChanceToFinalize): * heap/MarkedBlock.h: Changed atomSize to 16 bytes because we have no objects smaller than 16 bytes. This is also to pay for the additional Bitmap for the remembered set. (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::setRemembered): (JSC::MarkedBlock::clearRemembered): (JSC::MarkedBlock::atomicClearRemembered): (JSC::MarkedBlock::isRemembered): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): (JSC::VerifyMarked::operator()): (JSC::MarkedSpace::clearMarks): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::ClearRememberedSet::operator()): (JSC::MarkedSpace::didAllocateInBlock): (JSC::MarkedSpace::clearRememberedSet): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): (JSC::SlotVisitor::clearMarkStack): * heap/SlotVisitor.h: (JSC::SlotVisitor::markStack): (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::unconditionallyAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): (JSC::SlotVisitor::heap): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-09 Joseph Pecoraro Unreviewed Windows build fix for r161563. Copy all scripts, some may not be .py. * JavaScriptCore.vcxproj/copy-files.cmd: 2014-01-09 Filip Pizlo AI for CreateArguments should pass through non-SpecEmpty input values https://bugs.webkit.org/show_bug.cgi?id=126709 Reviewed by Mark Hahnenberg. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * tests/stress/use-arguments-as-object-pointer.js: Added. (foo): 2014-01-09 Mark Hahnenberg Constructors for Objective-C classes do not work properly with instanceof https://bugs.webkit.org/show_bug.cgi?id=126670 Reviewed by Oliver Hunt. This bug is due to the fact that the JS constructors created for Objective-C classes via the JSC API inherit from JSCallbackObject, which overrides hasInstance with its own customHasInstance. JSCallbackObject::customHasInstance only checks the JSClassRefs for hasInstance callbacks. If it doesn't find any callbacks, it returns false. This patch adds a hasInstance callback to constructors created for Objective-C wrapper classes. * API/JSWrapperMap.mm: (constructorHasInstance): (constructorWithCustomBrand): (allocateConstructorForCustomClass): * API/tests/testapi.mm: 2014-01-09 Joseph Pecoraro Web Inspector: Move InjectedScript classes into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=126598 Reviewed by Timothy Hatcher. Part 5: Move InjectedScript classes into JavaScriptCore There are pieces of logic that WebCore wants to hook into in the InjectedScript execution (e.g. for CommandLineAPIModule and InspectorInstrumentation). Create hooks for those in a base class called InspectorEnvironment. For now, the InspectorControllers (Page, JSGlobalObject, Worker) will be the InspectorEnvironments and provide answers to its hooks. * inspector/InspectorEnvironment.h: Added. New hooks needed by WebCore in various places. Mostly stubbed in JavaScriptCore. * inspector/InjectedScript.cpp: Renamed from Source/WebCore/inspector/InjectedScript.cpp. * inspector/InjectedScript.h: Added. * inspector/InjectedScriptBase.cpp: Renamed from Source/WebCore/inspector/InjectedScriptBase.cpp. * inspector/InjectedScriptBase.h: Renamed from Source/WebCore/inspector/InjectedScriptBase.h. * inspector/InjectedScriptModule.cpp: Renamed from Source/WebCore/inspector/InjectedScriptModule.cpp. * inspector/InjectedScriptModule.h: Renamed from Source/WebCore/inspector/InjectedScriptModule.h. Cleanup the style of these files (nullptr, formatting, whitespace, etc). Use the InspectorEnvironments call/evaluate function for ScriptFunctionCalls and checking access * inspector/InjectedScriptManager.cpp: Renamed from Source/WebCore/inspector/InjectedScriptManager.cpp. * inspector/InjectedScriptManager.h: Renamed from Source/WebCore/inspector/InjectedScriptManager.h. Take an InspectorEnvironment with multiple hooks, instead of a single hook function. * inspector/InjectedScriptHost.cpp: Added. * inspector/InjectedScriptHost.h: Added. * inspector/JSInjectedScriptHost.cpp: Renamed from Source/WebCore/bindings/js/JSInjectedScriptHostCustom.cpp. * inspector/JSInjectedScriptHost.h: Added. * inspector/JSInjectedScriptHostPrototype.cpp: Added. * inspector/JSInjectedScriptHostPrototype.h: Added. Implementation of InjectedScriptHost which is passed into the script (InjectedScriptSource.js) that we inject into the page. This is mostly copied from the original autogenerated code, then simplified and cleaned up. InjectedScriptHost can be subclasses to provide specialized implementations of isHTMLAllCollection and type for Web/DOM types unknown to a pure JS context. Part 4: Move all inspector scripts into JavaScriptCore and update generators. For OS X be sure to export the scripts as if they are private headers. * GNUmakefile.am: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/scripts/cssmin.py: Renamed from Source/WebCore/inspector/Scripts/cssmin.py. * inspector/scripts/inline-and-minify-stylesheets-and-scripts.py: Renamed from Source/WebCore/inspector/Scripts/inline-and-minify-stylesheets-and-scripts.py. * inspector/scripts/jsmin.py: Renamed from Source/WebCore/inspector/Scripts/jsmin.py. * inspector/scripts/xxd.pl: Renamed from Source/WebCore/inspector/xxd.pl. Part 3: Update CodeGeneratorInspector to avoid inlining virtual destructors. This avoids build errors about duplicate exported virtual inlined methods are included from multiple places. Just put empty destructors in the implementation file instead of inlined. * inspector/scripts/CodeGeneratorInspector.py: (Generator): (Generator.go): * inspector/scripts/CodeGeneratorInspectorStrings.py: Part 2: Move InjectedScriptSource and generation into JavaScriptCore. Move InjectedScriptSource.js and derived sources generation. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/InjectedScriptSource.js: Renamed from Source/WebCore/inspector/InjectedScriptSource.js. 2014-01-09 Balazs Kilvady Regression: failing RegExp tests on 32 bit architectures. https://bugs.webkit.org/show_bug.cgi?id=126699 Reviewed by Michael Saboff. Fix setRegExpConstructor functions for 32 bit architectures. * runtime/RegExpConstructor.cpp: (JSC::setRegExpConstructorInput): (JSC::setRegExpConstructorMultiline): 2014-01-09 Commit Queue Unreviewed, rolling out r161540. http://trac.webkit.org/changeset/161540 https://bugs.webkit.org/show_bug.cgi?id=126704 Caused assertion failures on multiple tests (Requested by ap on #webkit). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: * heap/CopiedSpace.h: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): * heap/Heap.h: (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::reset): * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: (JSC::MarkedBlock::lastChanceToFinalize): (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::clearMarks): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::MarkedSpace::clearMarks): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): * heap/SlotVisitor.h: (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-09 Andreas Kling Shrink WatchpointSet. Reorder the members of WatchpointSet, shrinking it by 8 bytes. 767 kB progression on Membuster3. Reviewed by Antti Koivisto. * bytecode/Watchpoint.h: 2014-01-08 Mark Hahnenberg Reverting accidental GC logging * heap/Heap.cpp: 2014-01-07 Mark Hahnenberg Marking should be generational https://bugs.webkit.org/show_bug.cgi?id=126552 Reviewed by Geoffrey Garen. Re-marking the same objects over and over is a waste of effort. This patch implements the sticky mark bit algorithm (along with our already-present write barriers) to reduce overhead during garbage collection caused by rescanning objects. There are now two collection modes, EdenCollection and FullCollection. EdenCollections only visit new objects or objects that were added to the remembered set by a write barrier. FullCollections are normal collections that visit all objects regardless of their generation. In this patch EdenCollections do not do anything in CopiedSpace. This will be fixed in https://bugs.webkit.org/show_bug.cgi?id=126555. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::didStartFullCollection): * heap/CopiedSpace.h: (JSC::CopiedSpace::heap): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::addToRememberedSet): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): (JSC::Heap::writeBarrier): * heap/Heap.h: (JSC::Heap::isInRememberedSet): (JSC::Heap::operationInProgress): (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): (JSC::MarkStackArray::clear): (JSC::MarkStackArray::fillVector): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::isListPagedOut): (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): (JSC::MarkedAllocator::reset): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearRememberedSet): (JSC::MarkedBlock::clearMarksWithCollectionType): (JSC::MarkedBlock::lastChanceToFinalize): * heap/MarkedBlock.h: Changed atomSize to 16 bytes because we have no objects smaller than 16 bytes. This is also to pay for the additional Bitmap for the remembered set. (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::setRemembered): (JSC::MarkedBlock::clearRemembered): (JSC::MarkedBlock::atomicClearRemembered): (JSC::MarkedBlock::isRemembered): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): (JSC::VerifyMarked::operator()): (JSC::MarkedSpace::clearMarks): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::ClearRememberedSet::operator()): (JSC::MarkedSpace::didAllocateInBlock): (JSC::MarkedSpace::clearRememberedSet): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): (JSC::SlotVisitor::clearMarkStack): * heap/SlotVisitor.h: (JSC::SlotVisitor::markStack): (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::unconditionallyAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): (JSC::SlotVisitor::heap): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-08 Sam Weinig [JS] Should be able to create a promise by calling the Promise constructor as a function https://bugs.webkit.org/show_bug.cgi?id=126561 Reviewed by Geoffrey Garen. * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getCallData): Add support for calling the Promise constructor as a function (e.g. var p = Promise(...), note the missing "new"). 2014-01-08 Dániel Bátyai [EFL] Make FTL buildable https://bugs.webkit.org/show_bug.cgi?id=125777 Reviewed by Csaba Osztrogonác. * CMakeLists.txt: * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExitCompiler.cpp: * llvm/library/config_llvm.h: 2014-01-08 Zan Dobersek [Automake] Scripts for generated build targets do not necessarily produce their output https://bugs.webkit.org/show_bug.cgi?id=126378 Reviewed by Carlos Garcia Campos. * GNUmakefile.am: Touch the build targets that are generated through helper scripts that don't assure the output is generated every time the script is invoked, most commonly due to unchanged input. This assures the build targets are up-to-date and can't be older that their dependencies, which would result in constant regeneration at every build. 2014-01-07 Filip Pizlo DFG fixup phase should be responsible for inserting ValueToInt32's as needed and it should use Phantom to keep the original values alive in case of OSR exit https://bugs.webkit.org/show_bug.cgi?id=126600 Reviewed by Michael Saboff. This fixes an embarrassing OSR exit liveness bug. It also simplifies the code. We were already using FixupPhase as the place where conversion nodes get inserted. ValueToInt32 was the only exception to that rule, and that was one of the reasons why we had this bug. Henceforth ValueToInt32 is only inserted by FixupPhase, and only when it is necessary: we have a BitOp that will want a ToInt32 conversion and the operand is not predicted to already be an int32. If FixupPhase inserts any ValueToInt32's then the BitOp will no longer appear to use the original operand, which will make OSR exit think that the original operand is dead. We work around this they way we always do: insert a Phantom on the original operands right after the BitOp. This ensures that any OSR exit in any of the ValueToInt32's or in the BitOp itself will have values for the original inputs. * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsic): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixIntEdge): (JSC::DFG::FixupPhase::fixBinaryIntEdges): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * tests/stress/bit-op-value-to-int32-input-liveness.js: Added. (foo): 2014-01-07 Mark Hahnenberg Repatch write barrier slow path call doesn't align the stack in the presence of saved registers https://bugs.webkit.org/show_bug.cgi?id=126093 Reviewed by Geoffrey Garen. * jit/Repatch.cpp: Reworked the stack alignment code for calling out to C code on the write barrier slow path. We need to properly account for the number of reused registers that were saved to the stack, so we have to pass the ScratchRegisterAllocator around. (JSC::storeToWriteBarrierBuffer): (JSC::writeBarrier): (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): * jit/ScratchRegisterAllocator.h: Previously the ScratchRegisterAllocator only knew whether or not it had reused registers, but not how many. In order to correctly align the stack for calls to C slow paths for the write barriers in inline caches we need to know how the stack is aligned. So now ScratchRegisterAllocator tracks how many registers it has reused. (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::ScratchRegisterAllocator::allocateScratch): (JSC::ScratchRegisterAllocator::didReuseRegisters): (JSC::ScratchRegisterAllocator::numberOfReusedRegisters): (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping): * llint/LowLevelInterpreter64.asm: Random typo fix. 2014-01-07 Mark Lam r161364 caused JSC tests regression on non-DFG builds (e.g. C Loop and Windows). https://bugs.webkit.org/show_bug.cgi?id=126589. Reviewed by Filip Pizlo. After the removal of ENABLE(VALUE_PROFILER), the LLINT is now expecting the relevant opcode operands to point to ValueProfiler data structures and will write profiling data into them. Hence, we need to allocate these data structures even though the profiling data won't be used in non-DFG builds. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): 2014-01-07 Filip Pizlo ASSERT in compileArithNegate on pdfjs https://bugs.webkit.org/show_bug.cgi?id=126584 Reviewed by Mark Hahnenberg. Check negative zero when we should check it, not when we shouldn't check it. :-/ * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithNegate): 2014-01-07 Gabor Rapcsanyi pushFinallyContext saves wrong m_labelScopes size https://bugs.webkit.org/show_bug.cgi?id=124529 Remove free label scopes before saving finally context. Reviewed by Geoffrey Garen. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::pushFinallyContext): 2014-01-06 Mark Hahnenberg Heap::collect shouldn't be responsible for sweeping https://bugs.webkit.org/show_bug.cgi?id=126556 Reviewed by Geoffrey Garen. Sweeping happens at an awkward time during collection due to the fact that destructors can cause arbitrary reentry into the VM. This patch separates collecting and sweeping, and delays sweeping until after collection has completely finished. * heap/Heap.cpp: (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): * runtime/GCActivityCallback.cpp: (JSC::DefaultGCActivityCallback::doWork): 2014-01-07 Mark Rowe Remove the legacy WebKit availability macros They're no longer used. Reviewed by Ryosuke Niwa. * API/WebKitAvailability.h: 2014-01-07 Filip Pizlo SetLocal for a FlushedArguments should not claim that the dataFormat is DataFormatJS https://bugs.webkit.org/show_bug.cgi?id=126563 Reviewed by Gavin Barraclough. This was a rookie arguments simplification mistake: the SetLocal needs to record the fact that although it set JSValue(), OSR should think it set Arguments. DataFormatArguments conveys this, and dataFormatFor(FlushFormat) will do the right thing. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/stress/phantom-arguments-set-local-then-exit-in-same-block.js: Added. (foo): 2014-01-06 Filip Pizlo Make the different flavors of integer arithmetic more explicit, and don't rely on (possibly stale) results of the backwards propagator to decide integer arithmetic semantics https://bugs.webkit.org/show_bug.cgi?id=125519 Reviewed by Geoffrey Garen. Adds the Arith::Mode enum to arithmetic nodes, which makes it explicit what sorts of checks and overflows the node should do. Previously this would be deduced from backwards analysis results. This also makes "unchecked" variants really mean that you want the int32 wrapped result, so ArithIMul is now done in terms of ArithMul(Unchecked). That means that the constant folder needs to compute exactly the result implied by ArithMode, instead of just folding the double result. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArithMode.cpp: Added. (WTF::printInternal): * dfg/DFGArithMode.h: Added. (JSC::DFG::doesOverflow): (JSC::DFG::shouldCheckOverflow): (JSC::DFG::shouldCheckNegativeZero): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::pureCSE): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::Node): (JSC::DFG::Node::hasArithMode): (JSC::DFG::Node::arithMode): (JSC::DFG::Node::setArithMode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArithMod): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileAddSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithDivMod): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): 2014-01-06 Mark Hahnenberg Add write barriers to the LLInt https://bugs.webkit.org/show_bug.cgi?id=126527 Reviewed by Filip Pizlo. This patch takes a similar approach to how write barriers work in the baseline JIT. We execute the write barrier at the beginning of the opcode so we don't have to worry about saving and restoring live registers across write barrier slow path calls to C code. * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_write_barrier_slow): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: * offlineasm/x86.rb: 2014-01-05 Sam Weinig [JS] Implement Promise.all() https://bugs.webkit.org/show_bug.cgi?id=126510 Reviewed by Gavin Barraclough. Add Promise.all() implementation and factor out performing resolves and rejects on deferreds to share a bit of code. Also moves the abruptRejection helper to JSPromiseDeferred so it can be used in JSPromiseFunctions. * runtime/CommonIdentifiers.h: * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructorFuncCast): (JSC::JSPromiseConstructorFuncResolve): (JSC::JSPromiseConstructorFuncReject): (JSC::JSPromiseConstructorFuncAll): * runtime/JSPromiseDeferred.cpp: (JSC::updateDeferredFromPotentialThenable): (JSC::performDeferredResolve): (JSC::performDeferredReject): (JSC::abruptRejection): * runtime/JSPromiseDeferred.h: * runtime/JSPromiseFunctions.cpp: (JSC::promiseAllCountdownFunction): (JSC::createPromiseAllCountdownFunction): * runtime/JSPromiseFunctions.h: * runtime/JSPromiseReaction.cpp: (JSC::ExecutePromiseReactionMicrotask::run): 2014-01-06 Filip Pizlo Get rid of ENABLE(VALUE_PROFILER). It's on all the time now. Rubber stamped by Mark Hahnenberg. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpValueProfiling): (JSC::CodeBlock::dumpArrayProfiling): (JSC::CodeBlock::dumpRareCaseProfile): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::setNumParameters): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::shouldOptimizeNow): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfileForBytecodeOffset): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/LazyOperandValueProfile.cpp: * bytecode/LazyOperandValueProfile.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ValueProfile.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::newArrayProfile): (JSC::BytecodeGenerator::newArrayAllocationProfile): (JSC::BytecodeGenerator::emitProfiledOpcode): * jit/GPRInfo.h: * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::privateCompile): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::emit_op_mul): (JSC::JIT::emit_op_div): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_div): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): * jit/JITInlines.h: (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex): (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase): (JSC::arrayProfileSaw): (JSC::JIT::chooseArrayMode): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_from_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_from_scope): * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CommonSlowPaths.cpp: 2014-01-06 Filip Pizlo LLInt shouldn't check for ENABLE(JIT). Rubber stamped by Mark Hahnenberg. * llint/LLIntCommon.h: * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: 2014-01-06 Filip Pizlo LLInt shouldnt check for ENABLE(JAVASCRIPT_DEBUGGER). Rubber stamped by Mark Hahnenberg. * debugger/Debugger.h: (JSC::Debugger::Debugger): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: 2014-01-05 Sam Weinig [JS] Implement Promise.race() https://bugs.webkit.org/show_bug.cgi?id=126506 Reviewed by Oliver Hunt. * runtime/CommonIdentifiers.h: Add identifier for "cast". * runtime/JSPromiseConstructor.cpp: (JSC::abruptRejection): Helper for the RejectIfAbrupt abstract operation. (JSC::JSPromiseConstructorFuncRace): Add implementation of Promise.race() 2014-01-05 Martin Robinson [GTK] [CMake] Ensure that the autotools build and the CMake install the same files https://bugs.webkit.org/show_bug.cgi?id=116379 Reviewed by Gustavo Noronha Silva. * PlatformGTK.cmake: Install API headers, gir files, and the pkg-config file. 2014-01-04 Yusuke Suzuki Use Compiler macros instead of raw "final" and "override" https://bugs.webkit.org/show_bug.cgi?id=126490 Reviewed by Sam Weinig. * runtime/JSPromiseReaction.cpp: 2014-01-04 Martin Robinson [GTK] [CMake] Improve the way we locate gobject-introspection https://bugs.webkit.org/show_bug.cgi?id=126452 Reviewed by Philippe Normand. * PlatformGTK.cmake: Use the new introspection variables. 2014-01-04 Zan Dobersek Explicitly use the std:: nested name specifier when using std::pair, std::make_pair https://bugs.webkit.org/show_bug.cgi?id=126439 Reviewed by Andreas Kling. Instead of relying on std::pair and std::make_pair symbols being present in the current scope through the pair and make_pair symbols, the std:: specifier should be used explicitly. * bytecode/Opcode.cpp: (JSC::compareOpcodePairIndices): (JSC::OpcodeStats::~OpcodeStats): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeBinaryNode): * parser/Parser.cpp: (JSC::Parser::parseIfStatement): * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains): (JSC::StructureTransitionTable::get): (JSC::StructureTransitionTable::add): 2014-01-03 David Farler [super dealloc] missing in Source/JavaScriptCore/API/tests/testapi.mm, fails to build with -Werror,-Wobjc-missing-super-calls https://bugs.webkit.org/show_bug.cgi?id=126454 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: (-[TextXYZ dealloc]): add [super dealloc] (-[EvilAllocationObject dealloc]): add [super dealloc] 2014-01-02 Carlos Garcia Campos REGRESSION(r160304): [GTK] Disable libtool fast install https://bugs.webkit.org/show_bug.cgi?id=126381 Reviewed by Martin Robinson. Remove -no-fast-install ld flag since fast install is now disabled globally. * GNUmakefile.am: 2014-01-02 Sam Weinig Update Promises to the https://github.com/domenic/promises-unwrapping spec https://bugs.webkit.org/show_bug.cgi?id=120954 Reviewed by Filip Pizlo. Update Promises to the revised spec. Notable changes: - JSPromiseResolver is gone. - TaskContext has been renamed Microtask and now has a virtual run() function. - Instead of using custom InternalFunction subclasses, JSFunctions are used with PrivateName properties for internal slots. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CallFrame.h: (JSC::ExecState::promiseConstructorTable): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseConstructor): (JSC::JSGlobalObject::promisePrototype): (JSC::JSGlobalObject::promiseStructure): * runtime/JSPromise.cpp: (JSC::JSPromise::create): (JSC::JSPromise::JSPromise): (JSC::JSPromise::finishCreation): (JSC::JSPromise::visitChildren): (JSC::JSPromise::reject): (JSC::JSPromise::resolve): (JSC::JSPromise::appendResolveReaction): (JSC::JSPromise::appendRejectReaction): (JSC::triggerPromiseReactions): * runtime/JSPromise.h: (JSC::JSPromise::status): (JSC::JSPromise::result): (JSC::JSPromise::constructor): * runtime/JSPromiseCallback.cpp: Removed. * runtime/JSPromiseCallback.h: Removed. * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): (JSC::JSPromiseConstructor::getCallData): (JSC::JSPromiseConstructorFuncCast): (JSC::JSPromiseConstructorFuncResolve): (JSC::JSPromiseConstructorFuncReject): * runtime/JSPromiseConstructor.h: * runtime/JSPromiseDeferred.cpp: Added. (JSC::JSPromiseDeferred::create): (JSC::JSPromiseDeferred::JSPromiseDeferred): (JSC::JSPromiseDeferred::finishCreation): (JSC::JSPromiseDeferred::visitChildren): (JSC::createJSPromiseDeferredFromConstructor): (JSC::updateDeferredFromPotentialThenable): * runtime/JSPromiseDeferred.h: Added. (JSC::JSPromiseDeferred::createStructure): (JSC::JSPromiseDeferred::promise): (JSC::JSPromiseDeferred::resolve): (JSC::JSPromiseDeferred::reject): * runtime/JSPromiseFunctions.cpp: Added. (JSC::deferredConstructionFunction): (JSC::createDeferredConstructionFunction): (JSC::identifyFunction): (JSC::createIdentifyFunction): (JSC::promiseAllCountdownFunction): (JSC::createPromiseAllCountdownFunction): (JSC::promiseResolutionHandlerFunction): (JSC::createPromiseResolutionHandlerFunction): (JSC::rejectPromiseFunction): (JSC::createRejectPromiseFunction): (JSC::resolvePromiseFunction): (JSC::createResolvePromiseFunction): (JSC::throwerFunction): (JSC::createThrowerFunction): * runtime/JSPromiseFunctions.h: Added. * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototypeFuncThen): (JSC::JSPromisePrototypeFuncCatch): * runtime/JSPromiseReaction.cpp: Added. (JSC::createExecutePromiseReactionMicroTask): (JSC::ExecutePromiseReactionMicroTask::run): (JSC::JSPromiseReaction::create): (JSC::JSPromiseReaction::JSPromiseReaction): (JSC::JSPromiseReaction::finishCreation): (JSC::JSPromiseReaction::visitChildren): * runtime/JSPromiseReaction.h: Added. (JSC::JSPromiseReaction::createStructure): (JSC::JSPromiseReaction::deferred): (JSC::JSPromiseReaction::handler): * runtime/JSPromiseResolver.cpp: Removed. * runtime/JSPromiseResolver.h: Removed. * runtime/JSPromiseResolverConstructor.cpp: Removed. * runtime/JSPromiseResolverConstructor.h: Removed. * runtime/JSPromiseResolverPrototype.cpp: Removed. * runtime/JSPromiseResolverPrototype.h: Removed. * runtime/Microtask.h: Added. * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: 2014-01-02 Mark Hahnenberg Add support for StoreBarrier and friends to the FTL https://bugs.webkit.org/show_bug.cgi?id=126040 Reviewed by Filip Pizlo. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileConditionalStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): (JSC::FTL::LowerDFGToLLVM::loadMarkByte): (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier): * heap/Heap.cpp: (JSC::Heap::Heap): * heap/Heap.h: (JSC::Heap::writeBarrierBuffer): 2014-01-02 Mark Hahnenberg Storing new CopiedSpace memory into a JSObject should fire a write barrier https://bugs.webkit.org/show_bug.cgi?id=126025 Reviewed by Filip Pizlo. Technically this is creating a pointer between a (potentially) old generation object and a young generation chunk of memory, thus there needs to be a barrier. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * heap/CopyWriteBarrier.h: Added. This class functions similarly to the WriteBarrier class. It acts as a proxy for pointers to CopiedSpace. Assignments to the field cause a write barrier to fire for the object that is the owner of the CopiedSpace memory. This is to ensure during nursery collections that objects with new backing stores are visited, even if they are old generation objects. (JSC::CopyWriteBarrier::CopyWriteBarrier): (JSC::CopyWriteBarrier::operator!): (JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): (JSC::CopyWriteBarrier::get): (JSC::CopyWriteBarrier::operator*): (JSC::CopyWriteBarrier::operator->): (JSC::CopyWriteBarrier::set): (JSC::CopyWriteBarrier::setWithoutWriteBarrier): (JSC::CopyWriteBarrier::clear): * heap/Heap.h: * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::unshiftCountWithArrayStorage): * runtime/JSCell.h: (JSC::JSCell::unvalidatedStructure): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.cpp: (JSC::JSObject::copyButterfly): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::countElements): (JSC::JSObject::increaseVectorLength): (JSC::JSObject::ensureLengthSlow): * runtime/JSObject.h: (JSC::JSObject::butterfly): (JSC::JSObject::setStructureAndButterfly): (JSC::JSObject::setButterflyWithoutChangingStructure): (JSC::JSObject::JSObject): (JSC::JSObject::putDirectInternal): (JSC::JSObject::putDirectWithoutTransition): * runtime/MapData.cpp: (JSC::MapData::ensureSpaceForAppend): * runtime/Structure.cpp: (JSC::Structure::materializePropertyMap): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by Antti Koivisto. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2014-01-01 Filip Pizlo Rationalize DFG DCE https://bugs.webkit.org/show_bug.cgi?id=125523 Reviewed by Mark Hahnenberg. Adds the ability to DCE more things. It's now the case that if a node is completely pure, we clear NodeMustGenerate and the node becomes a DCE candidate. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAdd): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileValueAdd): 2014-01-02 Benjamin Poulain Attempt to fix the build of WebCore's code generator on CMake based system https://bugs.webkit.org/show_bug.cgi?id=126271 Reviewed by Sam Weinig. * CMakeLists.txt: 2013-12-30 Commit Queue Unreviewed, rolling out r161157, r161158, r161160, r161161, r161163, and r161165. http://trac.webkit.org/changeset/161157 http://trac.webkit.org/changeset/161158 http://trac.webkit.org/changeset/161160 http://trac.webkit.org/changeset/161161 http://trac.webkit.org/changeset/161163 http://trac.webkit.org/changeset/161165 https://bugs.webkit.org/show_bug.cgi?id=126332 Broke WebKit2 on Mountain Lion (Requested by ap on #webkit). * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): (JSC::BlockAllocator::waitForRelativeTime): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Fix build. * heap/BlockAllocator.h: 2013-12-30 Anders Carlsson Stop using ThreadCondition in BlockAllocator https://bugs.webkit.org/show_bug.cgi?id=126313 Reviewed by Sam Weinig. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForDuration): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Stop using ThreadCondition in jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=126311 Reviewed by Sam Weinig. * jsc.cpp: (timeoutThreadMain): (main): 2013-12-30 Anders Carlsson Replace WTF::ThreadingOnce with std::call_once https://bugs.webkit.org/show_bug.cgi?id=126215 Reviewed by Sam Weinig. * dfg/DFGWorklist.cpp: (JSC::DFG::globalWorklist): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-30 Martin Robinson [CMake] [GTK] Add support for GObject introspection https://bugs.webkit.org/show_bug.cgi?id=126162 Reviewed by Daniel Bates. * PlatformGTK.cmake: Add the GIR targets. 2013-12-28 Filip Pizlo Get rid of DFG forward exiting https://bugs.webkit.org/show_bug.cgi?id=125531 Reviewed by Oliver Hunt. This finally gets rid of forward exiting. Forward exiting was always a fragile concept since it involved the compiler trying to figure out how to "roll forward" the execution from some DFG node to the next bytecode index. It was always easy to find counterexamples where it broke, and it has always served as an obstacle to adding compiler improvements - the latest being http://webkit.org/b/125523, which tried to make DCE work for more things. This change finishes the work of removing forward exiting. A lot of forward exiting was already removed in some other bugs, but SetLocal still did forward exits. SetLocal is in many ways the hardest to remove, since the forward exiting of SetLocal also implied that any conversion nodes inserted before the SetLocal would then also be marked as forward-exiting. Hence SetLocal's forward-exiting made a bunch of other things also forward-exiting, and this was always a source of weirdo bugs. SetLocal must be able to exit in case it performs a hoisted type speculation. Nodes inserted just before SetLocal must also be able to exit - for example type check hoisting may insert a CheckStructure, or fixup phase may insert something like Int32ToDouble. But if any of those nodes tried to backward exit, then this could lead to the reexecution of a side-effecting operation, for example: a: Call(...) b: SetLocal(@a, r1) For a long time it seemed like SetLocal *had* to exit forward because of this. But this change side-steps the problem by changing the ByteCodeParser to always emit a kind of "two-phase commit" for stores to local variables. Now when the ByteCodeParser wishes to store to a local, it first emits a MovHint and then enqueues a SetLocal. The SetLocal isn't actually emitted until the beginning of the next bytecode instruction (which the exception of op_enter and op_ret, which emit theirs immediately since it's always safe to reexecute those bytecode instructions and since deferring SetLocals would be weird there - op_enter has many SetLocals and op_ret is a set followed by a jump in case of inlining, so we'd have to emit the SetLocal "after" the jump and that would be awkward). This means that the above IR snippet would look something like: a: Call(..., bc#42) b: MovHint(@a, r1, bc#42) c: SetLocal(@a, r1, bc#47) Where the SetLocal exits "backwards" but appears at the beginning of the next bytecode instruction. This means that by the time we get to that SetLocal, the OSR exit analysis already knows that r1 is associated with @a, and it means that the SetLocal or anything hoisted above it can exit backwards as normal. This change also means that the "forward rewiring" can be killed. Previously, we might have inserted a conversion node on SetLocal and then the SetLocal died (i.e. turned into a MovHint) and the conversion node either died completely or had its lifetime truncated to be less than the actual value's bytecode lifetime. This no longer happens since conversion nodes are only inserted at SetLocals. More precisely, this change introduces two laws that we were basically already following anyway: 1) A MovHint's child should never be changed except if all other uses of that child are also replaced. Specifically, this prohibits insertion of conversion nodes at MovHints. 2) Anytime any child is replaced with something else, and all other uses aren't also replaced, we must insert a Phantom use of the original child. This is a slight compile-time regression but has no effect on code-gen. It unlocks a bunch of optimization opportunities so I think it's worth it. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): * bytecode/CodeBlock.h: (JSC::CodeBlock::instructionCount): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGArrayifySlowPathGenerator.h: (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::eliminate): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): (JSC::DFG::DCEPhase::fixupBlock): (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGMinifiedNode.cpp: (JSC::DFG::MinifiedNode::fromNode): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::constantNumber): (JSC::DFG::MinifiedNode::weakConstant): * dfg/DFGNode.cpp: (JSC::DFG::Node::hasVariableAccessData): * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantom): (JSC::DFG::Node::convertToPhantomUnchecked): (JSC::DFG::Node::convertToIdentity): (JSC::DFG::Node::containsMovHint): (JSC::DFG::Node::hasUnlinkedLocal): (JSC::DFG::Node::willHaveCodeGenOrOSR): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitBase.cpp: * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::emitInvalidationPoint): (JSC::DFG::SpeculativeJIT::typeCheck): (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch): (JSC::DFG::SpeculativeJIT::needsTypeCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validateCPS): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileMovHint): (JSC::FTL::LowerDFGToLLVM::compileZombieHint): (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::typeCheck): (JSC::FTL::LowerDFGToLLVM::appendTypeCheck): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): * ftl/FTLOSRExit.cpp: * ftl/FTLOSRExit.h: * tests/stress/dead-int32-to-double.js: Added. (foo): * tests/stress/dead-uint32-to-number.js: Added. (foo): 2013-12-25 Commit Queue Unreviewed, rolling out r161033 and r161074. http://trac.webkit.org/changeset/161033 http://trac.webkit.org/changeset/161074 https://bugs.webkit.org/show_bug.cgi?id=126240 Oliver says that a rollout would be better (Requested by ap on #webkit). * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setNewProperty): (JSC::PutPropertySlot::isCacheable): 2013-12-25 Filip Pizlo DFG PhantomArguments shouldn't rely on a dead Phi graph https://bugs.webkit.org/show_bug.cgi?id=126218 Reviewed by Oliver Hunt. This change dramatically rationalizes our handling of PhantomArguments (i.e. speculative elision of arguments object allocation). It's now the case that if we decide that we can elide arguments allocation, we just turn the arguments-creating node into a PhantomArguments and mark all locals that it's stored to as being arguments aliases. Being an arguments alias and being a PhantomArguments means basically the same thing: in DFG execution you have the empty value, on OSR exit an arguments object is allocated in your place, and all operations that use the value now just refer directly to the actual arguments in the call frame header (or the arguments we know that we passed to the call, in case of inlining). This means that we no longer have arguments simplification creating a dead Phi graph that then has to be interpreted by the OSR exit logic. That sort of never made any sense. This means that PhantomArguments now has a clear story in SSA: basically SSA just gets rid of the "locals" but everything else is the same. Finally, this means that we can more easily get rid of forward exiting. As I was working on the code to get rid of forward exiting, I realized that I'd have to carefully preserve the special meanings of MovHint and SetLocal in the case of PhantomArguments. It was really bizarre: even the semantics of MovHint were tied to our specific treatment of PhantomArguments. After this change this is no longer the case. One of the really cool things about this change is that arguments reification now just becomes a special kind of FlushFormat. This further unifies things: it means that a MovHint(PhantomArguments) and a SetLocal(PhantomArguments) both have the same meaning, since both of them dictate that the way we recover the local on exit is by reifying arguments. Previously, the SetLocal(PhantomArguments) case needed some special handling to accomplish this. A downside of this approach is that we will now emit code to store the empty value into aliased arguments variables, and we will even emit code to load that empty value as well. As far as I can tell this doesn't cost anything, since PhantomArguments are most profitable in cases where it allows us to simplify control flow and kill the arguments locals entirely. Of course, this isn't an issue in SSA form since SSA form also eliminates the locals. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::detypeArgumentsReferencingPhantomChild): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): (JSC::DFG::dataFormatFor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::ValueSource): (JSC::DFG::ValueSource::forFlushFormat): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::buildExitArguments): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by msaboff. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2013-12-23 Benjamin Poulain Add class matching to the Selector Code Generator https://bugs.webkit.org/show_bug.cgi?id=126176 Reviewed by Antti Koivisto and Oliver Hunt. Add test and branch based on BaseIndex addressing for x86_64. Fast loops are needed to compete with clang on tight loops. * assembler/MacroAssembler.h: * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branch64): (JSC::MacroAssemblerX86_64::branchPtr): * assembler/X86Assembler.h: (JSC::X86Assembler::cmpq_rm): 2013-12-23 Oliver Hunt Update custom setter implementations to perform type checks https://bugs.webkit.org/show_bug.cgi?id=126171 Reviewed by Daniel Bates. Modify the setter function signature to take encoded values as we're changing the setter usage everywhere anyway. * runtime/Lookup.h: (JSC::putEntry): 2013-12-23 Lucas Forschler Update copyright strings Reviewed by Dan Bernstein. * Info.plist: * JavaScriptCore.vcxproj/JavaScriptCore.resources/Info.plist: 2013-12-23 Zan Dobersek [GTK] Clean up compiler optimizations flags for libWTF, libJSC https://bugs.webkit.org/show_bug.cgi?id=126157 Reviewed by Gustavo Noronha Silva. * GNUmakefile.am: Remove the -fstrict-aliasing and -O3 compiler flags for libWTF.la. -O3 gets overridden by -O2 that's listed in CXXFLAGS (or -O0 in case of debug builds) and -fstrict-aliasing is enabled when -O2 is used (and shouldn't be enabled in debug builds anyway). 2013-12-22 Martin Robinson [CMake] Fix typo from r160812 https://bugs.webkit.org/show_bug.cgi?id=126145 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Fix typo when detecting the type of library. 2013-12-22 Martin Robinson [GTK][CMake] libtool-compatible soversion calculation https://bugs.webkit.org/show_bug.cgi?id=125511 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Use the POPULATE_LIBRARY_VERSION macro and the library-specific version information. 2013-12-23 Gustavo Noronha Silva [GTK] [CMake] Generate pkg-config files https://bugs.webkit.org/show_bug.cgi?id=125685 Reviewed by Martin Robinson. * PlatformGTK.cmake: Added. Generate javascriptcoregtk-3.0.pc. 2013-12-22 Benjamin Poulain Create a skeleton for CSS Selector code generation https://bugs.webkit.org/show_bug.cgi?id=126044 Reviewed by Antti Koivisto and Gavin Barraclough. * assembler/LinkBuffer.h: Add a new owner UID for code compiled for CSS. Export the symbols needed to link code from WebCore. 2013-12-19 Mark Hahnenberg Clean up DFG write barriers https://bugs.webkit.org/show_bug.cgi?id=126047 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Use the register allocator to determine which registers need saving instead of saving every single one of them. (JSC::DFG::SpeculativeJIT::osrWriteBarrier): We don't need to save live register state because the write barriers during OSR execute when there are no live registers. Also we don't need to use pushes to pad the stack pointer for pokes on x86; we can just use an add. (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT.h: * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): * runtime/VM.h: Get rid of writeBarrierRegisterBuffer since it's no longer used. 2013-12-20 Balazs Kilvady [MIPS] Missing MacroAssemblerMIPS::branchTest8(ResultCondition, BaseIndex, TrustedImm32) https://bugs.webkit.org/show_bug.cgi?id=126062 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchTest8): 2013-12-20 Julien Brianceau [sh4] Add missing implementation in MacroAssembler to fix build. https://bugs.webkit.org/show_bug.cgi?id=126063 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTest8): 2013-12-20 Julien Brianceau [arm] Add missing implementation in MacroAssembler to fix CPU(ARM_TRADITIONAL) build. https://bugs.webkit.org/show_bug.cgi?id=126064 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTest8): 2013-12-19 Joseph Pecoraro Web Inspector: Add InspectorFrontendHost.debuggableType to let the frontend know it's backend is JavaScript or Web https://bugs.webkit.org/show_bug.cgi?id=126016 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForDebuggable): * inspector/remote/RemoteInspectorConstants.h: Include a debuggable type identifier in the debuggable listing, so the remote frontend can know if it is debugging a Web Page or JS Context. 2013-12-19 Benjamin Poulain Add an utility class to simplify generating function calls https://bugs.webkit.org/show_bug.cgi?id=125972 Reviewed by Geoffrey Garen. Split branchTest32 in two functions: test32AndSetFlags and branchOnFlags. This is done to allow code where the flags are set, multiple operation that do not modify the flags occur, then the flags are used. This is used for function calls to test the return value while discarding the return register. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::test32AndSetFlags): (JSC::MacroAssemblerX86Common::branchOnFlags): (JSC::MacroAssemblerX86Common::branchTest32): 2013-12-19 Mark Hahnenberg Put write barriers in the right places in the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=125975 Reviewed by Filip Pizlo. * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): (JSC::JIT::emitArrayProfilingSite): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): (JSC::JIT::checkMarkWord): (JSC::JIT::emitWriteBarrier): (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): (JSC::repatchPutByID): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-19 Brent Fulgham Implement ArrayBuffer.isView https://bugs.webkit.org/show_bug.cgi?id=126004 Reviewed by Filip Pizlo. Test coverage in webgl/1.0.2/resources/webgl_test_files/conformance/typedarrays/array-unit-tests.html * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): Add 'isView' to object constructor. (JSC::arrayBufferFuncIsView): New method. 2013-12-19 Mark Lam Fix broken C loop LLINT build. https://bugs.webkit.org/show_bug.cgi?id=126024. Reviewed by Oliver Hunt. * runtime/VM.h: 2013-12-18 Mark Hahnenberg DelayedReleaseScope is in the wrong place https://bugs.webkit.org/show_bug.cgi?id=125876 Reviewed by Geoffrey Garen. The DelayedReleaseScope needs to be around the free list sweeping in MarkedAllocator::tryAllocateHelper. This location gives us a good safe point between getting ready to allocate (i.e. identifying a non-empty free list) and doing the actual allocation (popping the free list). * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::allocateSlowCase): (JSC::MarkedAllocator::addBlock): * runtime/JSCellInlines.h: (JSC::allocateCell): 2013-12-18 Gustavo Noronha Silva [GTK][CMake] make libjavascriptcoregtk a public shared library again https://bugs.webkit.org/show_bug.cgi?id=125512 Reviewed by Martin Robinson. * CMakeLists.txt: use target type instead of SHARED_CORE to decide whether JavaScriptCore is a shared library, since it's always shared for GTK+ regardless of SHARED_CORE. 2013-12-18 Benjamin Poulain Add a simple stack abstraction for x86_64 https://bugs.webkit.org/show_bug.cgi?id=125908 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::addPtrNoFlags): Add an explicit abstraction for the "lea" instruction. This is needed by the experimental JIT to have add and substract without changing the flags. This is useful for function calls to test the return value, restore the registers, then branch on the flags from the return value. 2013-12-18 Mark Hahnenberg DFG should have a separate StoreBarrier node https://bugs.webkit.org/show_bug.cgi?id=125530 Reviewed by Filip Pizlo. This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. They are inserted during the fixup phase. Initially they do not generate any code. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::isKnownNotCell): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberizeForAllocation): (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers, we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first, which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier. If we ever require that write barriers occur before stores, we'll have to split these nodes into AllocatePropertyStorage + StoreBarrier + PutPropertyStorage. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::insertStoreBarrier): * dfg/DFGNode.h: (JSC::DFG::Node::isStoreBarrier): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): (JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the byte that contains the mark bit of the object. (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call. (JSC::DFG::SpeculativeJIT::writeBarrier): (JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles are properly cleared during GC. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that that object doesn't need any more StoreBarriers. (JSC::DFG::StoreBarrierElisionPhase::StoreBarrierElisionPhase): (JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the objects known in the current block. (JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically sets the bit for that object since if a GC occurred as the result of that object's allocation then that object would not need a barrier since it would be guaranteed to be a young generation object until the next GC point. (JSC::DFG::StoreBarrierElisionPhase::noticeFreshObject): (JSC::DFG::StoreBarrierElisionPhase::getBaseOfStore): (JSC::DFG::StoreBarrierElisionPhase::shouldBeElided): (JSC::DFG::StoreBarrierElisionPhase::elideBarrier): (JSC::DFG::StoreBarrierElisionPhase::handleNode): (JSC::DFG::StoreBarrierElisionPhase::handleBlock): (JSC::DFG::StoreBarrierElisionPhase::run): (JSC::DFG::performStoreBarrierElision): * dfg/DFGStoreBarrierElisionPhase.h: Added. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::flushWriteBarrierBuffer): * heap/Heap.h: (JSC::Heap::writeBarrier): * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfMarks): * heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to each EdenCollection. (JSC::WriteBarrierBuffer::WriteBarrierBuffer): (JSC::WriteBarrierBuffer::~WriteBarrierBuffer): (JSC::WriteBarrierBuffer::flush): (JSC::WriteBarrierBuffer::reset): (JSC::WriteBarrierBuffer::add): * heap/WriteBarrierBuffer.h: Added. (JSC::WriteBarrierBuffer::currentIndexOffset): (JSC::WriteBarrierBuffer::capacityOffset): (JSC::WriteBarrierBuffer::bufferOffset): * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/VM.h: 2013-12-18 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.am: 2013-12-17 Julien Brianceau Fix armv7 and sh4 builds. https://bugs.webkit.org/show_bug.cgi?id=125848 Reviewed by Csaba Osztrogonác. * assembler/ARMv7Assembler.h: Include limits.h for INT_MIN. * assembler/SH4Assembler.h: Include limits.h for INT_MIN. 2013-12-16 Oliver Hunt Avoid indirect function calls for custom getters https://bugs.webkit.org/show_bug.cgi?id=125821 Reviewed by Mark Hahnenberg. Rather than invoking a helper function to perform an indirect call through a function pointer, just have the JIT call the function directly. Unfortunately this only works in JSVALUE64 at the moment as there is not an obvious way to pass two EncodedJSValues uniformly over the various effected JITs. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArguments): * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryBuildGetByIDList): 2013-12-16 Joseph Pecoraro Fix some whitespace issues in inspector code https://bugs.webkit.org/show_bug.cgi?id=125814 Reviewed by Darin Adler. * inspector/protocol/Debugger.json: * inspector/protocol/Runtime.json: * inspector/scripts/CodeGeneratorInspector.py: (Generator.process_command): 2013-12-16 Mark Hahnenberg Add some missing functions to MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=125809 Reviewed by Oliver Hunt. * assembler/AbstractMacroAssembler.h: * assembler/AssemblerBuffer.h: * assembler/LinkBuffer.cpp: * assembler/MacroAssembler.h: (JSC::MacroAssembler::storePtr): (JSC::MacroAssembler::andPtr): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): (JSC::MacroAssemblerARM64::branchTest8): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchTest8): * assembler/X86Assembler.h: 2013-12-16 Brent Fulgham [Win] Remove dead code after conversion to VS2013 https://bugs.webkit.org/show_bug.cgi?id=125795 Reviewed by Darin Adler. * API/tests/testapi.c: Remove local nan implementation 2013-12-16 Oliver Hunt Cache getters and custom accessors on the prototype chain https://bugs.webkit.org/show_bug.cgi?id=125602 Reviewed by Michael Saboff. Support caching of custom getters and accessors on the prototype chain. This is relatively trivial and just requires a little work compared to the direct access mode as we're under more register pressure. * bytecode/StructureStubInfo.h: Removed the unsued initGetByIdProto as it was confusing to still have it present. * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): 2013-12-16 Mark Lam Change slow path result to take a void* instead of a ExecState*. https://bugs.webkit.org/show_bug.cgi?id=125802. Reviewed by Filip Pizlo. This is in preparation for C Stack OSR entry work that is coming soon. In the OSR entry case, we'll be returning a topOfFrame pointer value instead of the ExecState*. * offlineasm/cloop.rb: * runtime/CommonSlowPaths.h: (JSC::encodeResult): (JSC::decodeResult): 2013-12-16 Alex Christensen Fixed Win64 build on VS2013. https://bugs.webkit.org/show_bug.cgi?id=125753 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Added correct PlatformToolset for 64-bit builds. 2013-12-16 Peter Szanka Delete RVCT related code parts. https://bugs.webkit.org/show_bug.cgi?id=125626 Reviewed by Darin Adler. * assembler/ARMAssembler.cpp: * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/MacroAssemblerARM.cpp: (JSC::isVFPPresent): * jit/JITStubsARM.h: * jit/JITStubsARMv7.h: 2013-12-15 Ryosuke Niwa REGRESSION: 2x regression on Dromaeo DOM query tests https://bugs.webkit.org/show_bug.cgi?id=125377 Reviewed by Filip Pizlo. The bug was caused by JSC not JIT'ing property access on "document" due to its type info having HasImpureGetOwnPropertySlot flag. Fixed the bug by new type info flag NewImpurePropertyFiresWatchpoints, which allows the baseline JIT to generate byte code for access properties on an object with named properties (a.k.a. custom name getter) in DOM. When a new named property appears on the object, VM is notified via VM::addImpureProperty and fires StructureStubClearingWatchpoint added during the repatch. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): Take the slow path if we have any object with impure properties in the prototype chain. (JSC::GetByIdStatus::computeForChain): Ditto. * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): Throw away the byte code when a new impure property is added on any object in the prototype chain via StructureStubClearingWatchpoint. (JSC::generateProtoChainAccessStub): Ditto. (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): (JSC::tryRepatchIn): Ditto. * runtime/JSTypeInfo.h: Added NewImpurePropertyFiresWatchpoints. (JSC::TypeInfo::newImpurePropertyFiresWatchpoints): Added. * runtime/Operations.h: (JSC::normalizePrototypeChainForChainAccess): Don't exit early if VM will be notified of new impure property even if the object had impure properties. * runtime/Structure.h: (JSC::Structure::takesSlowPathInDFGForImpureProperty): Added. Wraps hasImpureGetOwnPropertySlot and asserts that newImpurePropertyFiresWatchpoints is true whenever hasImpureGetOwnPropertySlot is true. * runtime/VM.cpp: (JSC::VM::registerWatchpointForImpureProperty): Added. (JSC::VM::addImpureProperty): Added. HTMLDocument calls it to notify JSC of a new impure property. * runtime/VM.h: 2013-12-15 Andy Estes [iOS] Upstream changes to FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125742 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2013-12-14 Filip Pizlo FTL should *really* know when things are flushed https://bugs.webkit.org/show_bug.cgi?id=125747 Reviewed by Sam Weinig. Fix more codegen badness. This makes V8v7's crypto am3() function run faster in the FTL than in DFG. This means that even if we just compile those functions in V8v7 that don't make calls, the FTL gives us a 2% speed-up over the DFG. That's pretty good considering that we have still more optimizations to fix and we can make calls work. * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): 2013-12-14 Andy Estes Unify FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125741 Rubber-stamped by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: Enable ENABLE_MEDIA_SOURCE. 2013-12-14 Mark Rowe Build fix after r160557. r160557 added the first generated header to JavaScriptCore that needs to be installed in to the framework wrapper. Sadly JavaScriptCore's Derived Sources target was not set to generate headers when invoked as part of the installhdrs action. This resulted in the build failing due to Xcode being unable to find the header file to install. The fix for this is to configure the Derived Sources target to use JavaScriptCore.xcconfig, which sets INSTALLHDRS_SCRIPT_PHASE to YES and allows Xcode to generate derived sources during the installhdrs action. Enabling INSTALLHDRS_SCRIPT_PHASE required tweaking the Generate Derived Sources script build phase to skip running code related to offlineasm that depends on JSCLLIntOffsetExtractor having been compiled, which isn't the case at installhdrs time. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Some Set and Map prototype functions have incorrect function lengths https://bugs.webkit.org/show_bug.cgi?id=125732 Reviewed by Oliver Hunt. * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2013-12-13 Joseph Pecoraro Web Inspector: Move Inspector and Debugger protocol domains into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125707 Reviewed by Timothy Hatcher. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * inspector/protocol/Debugger.json: Renamed from Source/WebCore/inspector/protocol/Debugger.json. * inspector/protocol/GenericTypes.json: Added. * inspector/protocol/InspectorDomain.json: Renamed from Source/WebCore/inspector/protocol/InspectorDomain.json. Add new files to inspector generation. * inspector/scripts/CodeGeneratorInspector.py: (Generator.go): Only build TypeBuilder output if the domain only has types. Avoid backend/frontend dispatchers and backend commands. (TypeBindings.create_type_declaration_.EnumBinding.get_setter_value_expression_pattern): (format_setter_value_expression): (Generator.process_command): (Generator.generate_send_method): * inspector/scripts/CodeGeneratorInspectorStrings.py: Export and name the get{JS,Web}EnumConstant function. 2013-12-11 Filip Pizlo Get rid of forward exit on UInt32ToNumber by adding an op_unsigned bytecode instruction https://bugs.webkit.org/show_bug.cgi?id=125553 Reviewed by Oliver Hunt. UInt32ToNumber was a super complicated node because it had to do a speculation, but it would do it after we already had computed the urshift. It couldn't just back to the beginning of the urshift because the inputs to the urshift weren't necessarily live anymore. We couldn't jump forward to the beginning of the next instruction because the result of the urshift was not yet unsigned-converted. For a while we solved this by forward-exiting in UInt32ToNumber. But that's really gross and I want to get rid of all forward exits. They cause a lot of bugs. We could also have turned UInt32ToNumber to a backwards exit by forcing the inputs to the urshift to be live. I figure that this might be a bit too extreme. So, I just created a new place that we can exit to: I split op_urshift into op_urshift followed by op_unsigned. op_unsigned is an "unsigned cast" along the lines of what UInt32ToNumber does. This allows me to get rid of all of the nastyness in the DFG for forward exiting in UInt32ToNumber. This patch enables massive code carnage in the DFG and FTL, and brings us closer to eliminating one of the DFG's most confusing concepts. On the flipside, it does make the bytecode slightly more complex (one new instruction). This is a profitable trade. We want the DFG and FTL to trend towards simplicity, since they are both currently too complicated. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::dumpInContext): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::gpr): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): (JSC::emitReadModifyAssignment): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::toInt32): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild1): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild2): * ftl/FTLFormattedValue.h: (JSC::FTL::int32Value): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): * ftl/FTLValueFormat.cpp: (JSC::FTL::reboxAccordingToFormat): (WTF::printInternal): * ftl/FTLValueFormat.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_urshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitRightShift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-13 Mark Hahnenberg LLInt should not conditionally branch to to labels outside of its function https://bugs.webkit.org/show_bug.cgi?id=125713 Reviewed by Geoffrey Garen. Conditional branches are insufficient for jumping to out-of-function labels. The fix is to use an unconditional jmp to the label combined with a conditional branch around the jmp. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-12-13 Joseph Pecoraro [GTK] Remove Warnings in building about duplicate INSPECTOR variables https://bugs.webkit.org/show_bug.cgi?id=125710 Reviewed by Tim Horton. * GNUmakefile.am: 2013-12-13 Joseph Pecoraro Cleanup CodeGeneratorInspectorStrings a bit https://bugs.webkit.org/show_bug.cgi?id=125705 Reviewed by Timothy Hatcher. * inspector/scripts/CodeGeneratorInspectorStrings.py: Use ${foo} variable syntax and add an ASCIILiteral. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160563 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Missed the Debug target in my last patch. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160548 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Specify that we are using the vs12_xp target for Makefile-based projects. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Ditto * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Ditto. 2013-12-13 Joseph Pecoraro Make inspector folder groups smarter in JavaScriptCore.xcodeproj https://bugs.webkit.org/show_bug.cgi?id=125663 Reviewed by Darin Adler. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Web Inspector: Add Inspector Code Generation to JavaScriptCore for Runtime Domain https://bugs.webkit.org/show_bug.cgi?id=125595 Reviewed by Timothy Hatcher. - Move CodeGeneration scripts from WebCore into JavaScriptCore/inspector/scripts - For ports that build WebKit frameworks separately, export the scripts as PrivateHeaders - Update CodeGeneratorInspector.py in a few ways: - output dynamic filenames, so JavaScriptCore generates InspectorJSFoo.* and WebCore generates InspectorWebFoo.* - take in more then one protocol JSON file. The first contains domains to generate, the others are dependencies that are generated elsewhere that we can depend on for Types. - Add DerivedSources build step to generate the Inspector Interfaces * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: Add scripts and code generation. * inspector/protocol/Runtime.json: Renamed from Source/WebCore/inspector/protocol/Runtime.json. Move protocol file into JavaScriptCore so its types will be generated in JavaScriptCore. * inspector/scripts/CodeGeneratorInspector.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspector.py. Updates to the script as listed above. * inspector/scripts/CodeGeneratorInspectorStrings.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspectorStrings.py. * inspector/scripts/generate-combined-inspector-json.py: Renamed from Source/WebCore/inspector/Scripts/generate-combined-inspector-json.py. Moved from WebCore into JavaScriptCore for code generation. 2013-12-13 Peter Szanka Delete INTEL C compiler related code parts. https://bugs.webkit.org/show_bug.cgi?id=125625 Reviewed by Darin Adler. * jsc.cpp: * testRegExp.cpp: 2013-12-13 Brent Fulgham [Win] Switch WebKit solution to Visual Studio 2013 https://bugs.webkit.org/show_bug.cgi?id=125192 Reviewed by Anders Carlsson. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Update for VS2013 * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Ditto * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto 2013-12-12 Joseph Pecoraro Add a few more ASCIILiterals https://bugs.webkit.org/show_bug.cgi?id=125662 Reviewed by Darin Adler. * inspector/InspectorBackendDispatcher.cpp: (Inspector::InspectorBackendDispatcher::dispatch): 2013-12-12 Joseph Pecoraro Test new JSContext name APIs https://bugs.webkit.org/show_bug.cgi?id=125607 Reviewed by Darin Adler. * API/JSContext.h: * API/JSContextRef.h: Fix whitespace issues. * API/tests/testapi.c: (globalContextNameTest): (main): * API/tests/testapi.mm: Add tests for JSContext set/get name APIs. 2013-12-11 Filip Pizlo ARM64: Hang running pdfjs test, suspect DFG generated code for "in" https://bugs.webkit.org/show_bug.cgi?id=124727 Reviewed by Michael Saboff. Get rid of In's hackish use of StructureStubInfo. Previously it was using hotPathBegin, and it was the only IC that used that field, which was wasteful. Moreover, it used it to store two separate locations: the label for patching the jump and the label right after the jump. The code was relying on those two being the same label, which is true on X86 and some other platforms, but it isn't true on ARM64. This gets rid of hotPathBegin and makes In express those two locations as offsets from the callReturnLocation, which is analogous to what the other IC's do. This fixes a bug where any successful In patching would result in a trivially infinite loop - and hence a hang - on ARM64. * bytecode/StructureStubInfo.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::InRecord::InRecord): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIn): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::finalize): * jit/Repatch.cpp: (JSC::replaceWithJump): (JSC::patchJumpToGetByIdStub): (JSC::tryCachePutByID): (JSC::tryBuildPutByIdList): (JSC::tryRepatchIn): (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): 2013-12-11 Joseph Pecoraro Web Inspector: Push More Inspector Required Classes Down into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125324 Reviewed by Timothy Hatcher. * CMakeLists.txt: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: * bindings/ScriptFunctionCall.cpp: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.cpp. * bindings/ScriptFunctionCall.h: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.h. * bindings/ScriptObject.cpp: Copied from Source/WebCore/inspector/WorkerConsoleAgent.cpp. * bindings/ScriptObject.h: Renamed from Source/WebCore/inspector/InspectorBaseAgent.h. * bindings/ScriptValue.cpp: Renamed from Source/WebCore/bindings/js/ScriptValue.cpp. * bindings/ScriptValue.h: Renamed from Source/WebCore/bindings/js/ScriptValue.h. * inspector/InspectorAgentBase.h: Copied from Source/WebCore/inspector/InspectorAgentRegistry.h. * inspector/InspectorAgentRegistry.cpp: Renamed from Source/WebCore/inspector/InspectorAgentRegistry.cpp. * inspector/InspectorBackendDispatcher.h: Renamed from Source/WebCore/inspector/InspectorBackendDispatcher.h. (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): * inspector/InspectorValues.cpp: Renamed from Source/WebCore/inspector/InspectorValues.cpp. * inspector/InspectorValues.h: Renamed from Source/WebCore/inspector/InspectorValues.h. 2013-12-11 Laszlo Vidacs Store SHA1 hash in std::array https://bugs.webkit.org/show_bug.cgi?id=125446 Reviewed by Darin Adler. Change Vector to std::array and use typedef. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): 2013-12-11 Mark Rowe Modernize the JavaScriptCore API headers This consists of three main changes: 1) Converting the return type of initializer methods to instancetype. 2) Declaring properties rather than getters and setters. 3) Tagging C API methods with information about their memory management semantics. Changing the declarations from getters and setters to properties also required updating the headerdoc in a number of places. Reviewed by Anders Carlsson. * API/JSContext.h: * API/JSContext.mm: * API/JSManagedValue.h: * API/JSManagedValue.mm: * API/JSStringRefCF.h: * API/JSValue.h: * API/JSVirtualMachine.h: * API/JSVirtualMachine.mm: 2013-12-11 Mark Rowe Move JavaScriptCore off the legacy WebKit availability macros The legacy WebKit availability macros are verbose, confusing, and provide no benefit over using the system availability macros directly. The original vision was that they'd serve a cross-platform purpose but that never came to be. Map from WebKit version to OS X version based on the mapping in WebKitAvailability.h. All iOS versions are specified as 7.0 as that is when the JavaScriptCore C API was made public. Part of . Reviewed by Anders Carlsson. * API/JSBasePrivate.h: * API/JSContextRef.h: * API/JSContextRefPrivate.h: * API/JSObjectRef.h: * API/JSValueRef.h: 2013-12-10 Filip Pizlo Get rid of forward exit on DoubleAsInt32 https://bugs.webkit.org/show_bug.cgi?id=125552 Reviewed by Oliver Hunt. The forward exit was just there so that we wouldn't have to keep the inputs alive up to the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and we shouldn't have it just for a bit of liveness micro-optimization. Also add a bunch of machinery to test this case on X86. * assembler/AbstractMacroAssembler.h: (JSC::optimizeForARMv7s): (JSC::optimizeForARM64): (JSC::optimizeForX86): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): * runtime/Options.h: * tests/stress/double-as-int32.js: Added. (foo): (test): 2013-12-10 Filip Pizlo Simplify CSE's treatment of NodeRelevantToOSR https://bugs.webkit.org/show_bug.cgi?id=125538 Reviewed by Oliver Hunt. Make the NodeRelevantToOSR thing obvious: if there is any MovHint on a node then the node is relevant to OSR. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): (JSC::DFG::CSEPhase::performBlockCSE): 2013-12-10 Filip Pizlo Get rid of forward exit in GetByVal on Uint32Array https://bugs.webkit.org/show_bug.cgi?id=125543 Reviewed by Oliver Hunt. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): 2013-12-10 Balazs Kilvady [MIPS] Redundant instructions in code generated from offlineasm. https://bugs.webkit.org/show_bug.cgi?id=125528 Reviewed by Michael Saboff. Optimize lowering of offlineasm BaseIndex Addresses. * offlineasm/mips.rb: 2013-12-10 Oliver Hunt Reduce the mass templatizing of the JS parser https://bugs.webkit.org/show_bug.cgi?id=125535 Reviewed by Michael Saboff. The various caches we have now have removed the need for many of the template vs. regular parameters. This patch converts those template parameters to regular parameters and updates the call sites. This reduces the code size of the parser by around 15%. * parser/ASTBuilder.h: (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createProperty): * parser/Parser.cpp: (JSC::::parseInner): (JSC::::parseSourceElements): (JSC::::parseVarDeclarationList): (JSC::::createBindingPattern): (JSC::::tryParseDeconstructionPatternExpression): (JSC::::parseDeconstructionPattern): (JSC::::parseSwitchClauses): (JSC::::parseSwitchDefaultClause): (JSC::::parseBlockStatement): (JSC::::parseFormalParameters): (JSC::::parseFunctionInfo): (JSC::::parseFunctionDeclaration): (JSC::::parseProperty): (JSC::::parseObjectLiteral): (JSC::::parseStrictObjectLiteral): (JSC::::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::createGetterOrSetterProperty): 2013-12-10 Mark Hahnenberg ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at beginning of GC https://bugs.webkit.org/show_bug.cgi?id=125472 Reviewed by Geoff Garen. This patch makes it look like it's okay to allocate so that the DFG plan finalization stuff can do what it needs to do. We already expected that we might do allocation during plan finalization and we increased the deferral depth to handle this, but we need to fix this other ASSERT stuff too. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::collect): * heap/Heap.h: * heap/RecursiveAllocationScope.h: Added. (JSC::RecursiveAllocationScope::RecursiveAllocationScope): (JSC::RecursiveAllocationScope::~RecursiveAllocationScope): * runtime/VM.h: 2013-12-09 Filip Pizlo Impose and enforce some basic rules of sanity for where Phi functions are allowed to occur and where their (optional) corresponding MovHints can be https://bugs.webkit.org/show_bug.cgi?id=125480 Reviewed by Geoffrey Garen. Previously, if you wanted to insert some speculation right after where a value was produced, you'd get super confused if that value was produced by a Phi node. You can't necessarily insert speculations after a Phi node because Phi nodes appear in this special sequence of Phis and MovHints that establish the OSR exit state for a block. So, you'd probably want to search for the next place where it's safe to insert things. We already do this "search for beginning of next bytecode instruction" search by looking at the next node that has a different CodeOrigin. But this would be hard for a Phi because those Phis and MovHints have basically random CodeOrigins and they can all have different CodeOrigins. This change imposes some sanity for this situation: - Phis must have unset CodeOrigins. - In each basic block, all nodes that have unset CodeOrigins must come before all nodes that have set CodeOrigins. This all ends up working out just great because prior to this change we didn't have a use for unset CodeOrigins. I think it's appropriate to make "unset CodeOrigin" mean that we're in the prologue of a basic block. It's interesting what this means for block merging, which we don't yet do in SSA. Consider merging the edge A->B. One possibility is that the block merger is now required to clean up Phi/Upsilons, and reascribe the MovHints to have the CodeOrigin of the A's block terminal. But an answer that might be better is that the originless nodes at the top of the B are just given the origin of the terminal and we keep the Phis. That would require changing the above rules. We'll see how it goes, and what we end up picking... Overall, this special-things-at-the-top rule is analogous to what other SSA-based compilers do. For example, LLVM has rules mandating that Phis appear at the top of a block. * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::dump): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::OSRExitBase): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): (JSC::DFG::Validate::validateSSA): 2013-12-08 Filip Pizlo Reveal array bounds checks in DFG IR https://bugs.webkit.org/show_bug.cgi?id=125253 Reviewed by Oliver Hunt and Mark Hahnenberg. In SSA mode, this reveals array bounds checks and the load of array length in DFG IR, making this a candidate for LICM. This also fixes a long-standing performance bug where the JSObject slow paths would always create contiguous storage, rather than type-specialized storage, when doing a "storage creating" storage, like: var o = {}; o[0] = 42; * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): (JSC::exitKindIsCountable): * bytecode/ExitKind.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::permitsBoundsCheckLowering): (JSC::DFG::ArrayMode::permitsBoundsCheckLowering): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::lengthNeedsStorage): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSSALoweringPhase.cpp: Added. (JSC::DFG::SSALoweringPhase::SSALoweringPhase): (JSC::DFG::SSALoweringPhase::run): (JSC::DFG::SSALoweringPhase::handleNode): (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): (JSC::DFG::performSSALowering): * dfg/DFGSSALoweringPhase.h: Added. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckInBounds): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds): * runtime/JSObject.cpp: (JSC::JSObject::convertUndecidedForValue): (JSC::JSObject::createInitialForValueAndSet): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLength): * runtime/JSObject.h: * tests/stress/float32array-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-object-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-out-of-bounds.js: Added. (foo): (test): 2013-12-09 Sam Weinig Replace use of WTF::FixedArray with std::array https://bugs.webkit.org/show_bug.cgi?id=125475 Reviewed by Anders Carlsson. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::dump): * bytecode/Opcode.cpp: (JSC::OpcodeStats::~OpcodeStats): * dfg/DFGCSEPhase.cpp: * ftl/FTLAbstractHeap.h: * heap/MarkedSpace.h: * parser/ParserArena.h: * runtime/CodeCache.h: * runtime/DateInstanceCache.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: * runtime/JSString.h: * runtime/LiteralParser.h: * runtime/NumericStrings.h: * runtime/RegExpCache.h: * runtime/SmallStrings.h: 2013-12-09 Joseph Pecoraro Remove miscellaneous unnecessary build statements https://bugs.webkit.org/show_bug.cgi?id=125466 Reviewed by Darin Adler. * DerivedSources.make: * JavaScriptCore.vcxproj/build-generated-files.sh: * JavaScriptCore.xcodeproj/project.pbxproj: * make-generated-sources.sh: 2013-12-08 Filip Pizlo CSE should work in SSA https://bugs.webkit.org/show_bug.cgi?id=125430 Reviewed by Oliver Hunt and Mark Hahnenberg. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): 2013-12-09 Joseph Pecoraro Remove docs/make-bytecode-docs.pl https://bugs.webkit.org/show_bug.cgi?id=125462 This sript is very old and no longer outputs useful data since the op code definitions have moved from Interpreter.cpp. Reviewed by Darin Adler. * DerivedSources.make: * docs/make-bytecode-docs.pl: Removed. 2013-12-09 Julien Brianceau Fix sh4 LLINT build. https://bugs.webkit.org/show_bug.cgi?id=125454 Reviewed by Michael Saboff. In LLINT, sh4 backend implementation didn't handle properly conditional jumps using a LabelReference instance. This patch fixes it through sh4LowerMisplacedLabels phase. Also, to avoid the need of a 4th temporary gpr, this phase is triggered later in getModifiedListSH4. * offlineasm/sh4.rb: 2013-12-08 Filip Pizlo Add the notion of ConstantStoragePointer to DFG IR https://bugs.webkit.org/show_bug.cgi?id=125395 Reviewed by Oliver Hunt. This pushes more typed array folding into StrengthReductionPhase, and enables CSE on storage pointers. Previously, you might have separate nodes for the same storage pointer and this would cause some bad register pressure in the DFG. Note that this was really a theoretical problem and not, to my knowledge a practical one - so this patch is basically just a clean-up. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::constantStoragePointerCSE): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::convertToConstantStoragePointer): (JSC::DFG::Node::hasStoragePointer): (JSC::DFG::Node::storagePointer): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileConstantStoragePointer): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): 2013-12-08 Filip Pizlo FTL should support UntypedUse versions of Compare nodes https://bugs.webkit.org/show_bug.cgi?id=125426 Reviewed by Oliver Hunt. This adds UntypedUse versions of all comparisons except CompareStrictEq, which is sufficiently different that I thought I'd do it in another patch. This also extends our ability to abstract over comparison kind and removes a bunch of copy-paste code. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::compare): (JSC::FTL::LowerDFGToLLVM::nonSpeculativeCompare): * ftl/FTLOutput.h: (JSC::FTL::Output::icmp): (JSC::FTL::Output::equal): (JSC::FTL::Output::notEqual): (JSC::FTL::Output::above): (JSC::FTL::Output::aboveOrEqual): (JSC::FTL::Output::below): (JSC::FTL::Output::belowOrEqual): (JSC::FTL::Output::greaterThan): (JSC::FTL::Output::greaterThanOrEqual): (JSC::FTL::Output::lessThan): (JSC::FTL::Output::lessThanOrEqual): (JSC::FTL::Output::fcmp): (JSC::FTL::Output::doubleEqual): (JSC::FTL::Output::doubleNotEqualOrUnordered): (JSC::FTL::Output::doubleLessThan): (JSC::FTL::Output::doubleLessThanOrEqual): (JSC::FTL::Output::doubleGreaterThan): (JSC::FTL::Output::doubleGreaterThanOrEqual): (JSC::FTL::Output::doubleEqualOrUnordered): (JSC::FTL::Output::doubleNotEqual): (JSC::FTL::Output::doubleLessThanOrUnordered): (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): * tests/stress/untyped-equality.js: Added. (foo): * tests/stress/untyped-less-than.js: Added. (foo): 2013-12-07 Filip Pizlo Fold typedArray.length if typedArray is constant https://bugs.webkit.org/show_bug.cgi?id=125252 Reviewed by Sam Weinig. This was meant to be easy. The problem is that there was no good place for putting the folding of typedArray.length to a constant. You can't quite do it in the bytecode parser because at that point you don't yet know if typedArray is really a typed array. You can't do it as part of constant folding because the folder assumes that it can opportunistically forward-flow a constant value without changing the IR; this doesn't work since we need to first change the IR to register a desired watchpoint and only after that can we introduce that constant. We could have done it in Fixup but that would have been awkward since Fixup's code for turning a GetById of "length" into GetArrayLength is already somewhat complex. We could have done it in CSE but CSE is already fairly gnarly and will probably get rewritten. So I introduced a new phase, called StrengthReduction. This phase should have any transformations that don't requite CFA or CSE and that it would be weird to put into those other phases. I also took the opportunity to refactor some of the other folding code. This also adds a test, but the test couldn't quite be a LayoutTests/js/regress so I introduced the notion of JavaScriptCore/tests/stress. The goal of this patch isn't really to improve performance or anything like that. It adds an optimization for completeness, and in doing so it unlocks a bunch of new possibilities. The one that I'm most excited about is revealing array length checks in DFG IR, which will allow for array bounds check hoisting and elimination. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): (JSC::DFG::Graph::tryGetFoldableViewForChild1): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasTypedArray): (JSC::DFG::Node::typedArray): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: Added. (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase): (JSC::DFG::StrengthReductionPhase::run): (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::performStrengthReduction): * dfg/DFGStrengthReductionPhase.h: Added. * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * jsc.cpp: (GlobalObject::finishCreation): (functionTransferArrayBuffer): * runtime/ArrayBufferView.h: * tests/stress: Added. * tests/stress/fold-typed-array-properties.js: Added. (foo): 2013-12-07 peavo@outlook.com [Win][64-bit] Hitting breakpoint assembler instruction in callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125382 Reviewed by Michael Saboff. The WinCairo results from run-javascriptcore-tests are the same as the WinCairo 32-bits results, when removing these breakpoints. * jit/JITStubsMSVC64.asm: Remove breakpoint instructions. 2013-12-06 Filip Pizlo FTL should support all of Branch/LogicalNot https://bugs.webkit.org/show_bug.cgi?id=125370 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::boolify): 2013-12-06 Roger Fong and Brent Fulgham [Win] Support compiling with VS2013 https://bugs.webkit.org/show_bug.cgi?id=125353 Reviewed by Anders Carlsson. * API/tests/testapi.c: Use C99 defines if available. * jit/JITOperations.cpp: Don't attempt to define C linkage when returning a C++ object. 2013-12-06 Filip Pizlo FTL should support generic ByVal accesses https://bugs.webkit.org/show_bug.cgi?id=125368 Reviewed by Mark Hahnenberg. * dfg/DFGGraph.h: (JSC::DFG::Graph::isStrictModeFor): (JSC::DFG::Graph::ecmaModeFor): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Filip Pizlo FTL should support hole/OOB array accesses https://bugs.webkit.org/show_bug.cgi?id=118077 Reviewed by Oliver Hunt and Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::baseIndex): 2013-12-06 Michael Saboff Split sizing of VarArgs frames from loading arguments for the frame https://bugs.webkit.org/show_bug.cgi?id=125331 Reviewed by Filip Pizlo. Split loadVarargs into sizeAndAllocFrameForVarargs() and loadVarargs() in preparation for moving onto the C stack. sizeAndAllocFrameForVarargs() will compute the size of the callee frame and allocate it, while loadVarargs() actually loads the argument values. As part of moving onto the C stack, sizeAndAllocFrameForVarargs() will be changed to a function that just computes the size. The caller will use that size to allocate the new frame on the stack before calling loadVargs() and actually making the call. * interpreter/Interpreter.cpp: (JSC::sizeAndAllocFrameForVarargs): (JSC::loadVarargs): * interpreter/Interpreter.h: * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITInlines.h: (JSC::JIT::callOperation): * 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.h: 2013-12-06 Filip Pizlo FTL should support all of ValueToInt32 https://bugs.webkit.org/show_bug.cgi?id=125283 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileValueToInt32): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::isCell): 2013-12-06 Filip Pizlo FTL shouldn't have a doubleToUInt32 path https://bugs.webkit.org/show_bug.cgi?id=125360 Reviewed by Mark Hahnenberg. This code existed because I incorrectly thought it was necessary. It's now basically dead. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Laszlo Vidacs Define SHA1 hash size in SHA1.h and use it at various places. https://bugs.webkit.org/show_bug.cgi?id=125345 Reviewed by Darin Adler. Use SHA1::hashSize instead of local variables. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): use SHA1::hashSize 2013-12-05 Michael Saboff REGRESSION(r160213): Crash in js/dom/JSON-parse.html https://bugs.webkit.org/show_bug.cgi?id=125335 Reviewed by Mark Lam. Changed _llint_op_catch to materialize the VM via the scope chain instead of the CodeBlock. CallFrames always have a scope chain, but may have a null CodeBlock. * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): 2013-12-05 Michael Saboff JSC: Simplify interface between throw and catch handler https://bugs.webkit.org/show_bug.cgi?id=125328 Reviewed by Geoffrey Garen. Simplified the throw - catch interface. The throw side is only responsible for jumping to the appropriate op_catch handler or returnFromJavaScript for uncaught exceptions. The handler uses the exception values like VM.callFrameForThrow as appropriate and no longer relies on the throw side putting anything in registers. * jit/CCallHelpers.h: (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Filip Pizlo FTL should use cvttsd2si directly for double-to-int32 conversions https://bugs.webkit.org/show_bug.cgi?id=125275 Reviewed by Michael Saboff. Wow. This was an ordeal. Using cvttsd2si was actually easy, but I learned, and sometimes even fixed, some interesting things: - The llvm.x86.sse2.cvttsd2si intrinsic can actually result in LLVM emitting a vcvttsd2si. I guess the intrinsic doesn't actually imply the instruction. - That whole thing about branchTruncateDoubleToUint32? Yeah we don't need that. It's better to use branchTruncateDoubleToInt32 instead. It has the right semantics for all of its callers (err, its one-and-only caller), and it's more likely to take fast path. This patch kills branchTruncateDoubleToUint32. - "a[i] = v; v = a[i]". Does this change v? OK, assume that 'a[i]' is a pure-ish operation - like an array access with 'i' being an integer index and we're not having a bad time. Now does this change v? CSE assumes that it doesn't. That's wrong. If 'a' is a typed array - the most sensible and pure kind of array - then this can be a truncating cast. For example 'v' could be a double and 'a' could be an integer array. - "v1 = a[i]; v2 = a[i]". Is v1 === v2 assuming that 'a[i]' is pure-ish? The answer is no. You could have a different arrayMode in each access. I know this sounds weird, but with concurrent JIT that might happen. This patch adds tests for all of this stuff, except for the first issue (it's weird but probably doesn't matter) and the last issue (it's too much of a freakshow). * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerX86Common.h: * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * ftl/FTLAbbreviations.h: (JSC::FTL::vectorType): (JSC::FTL::getUndef): (JSC::FTL::buildInsertElement): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::doubleToInt32): (JSC::FTL::LowerDFGToLLVM::doubleToUInt32): (JSC::FTL::LowerDFGToLLVM::sensibleDoubleToInt32): * ftl/FTLOutput.h: (JSC::FTL::Output::insertElement): (JSC::FTL::Output::hasSensibleDoubleToInt): (JSC::FTL::Output::sensibleDoubleToInt): 2013-12-05 Commit Queue Unreviewed, rolling out r160133. http://trac.webkit.org/changeset/160133 https://bugs.webkit.org/show_bug.cgi?id=125325 broke bindings tests on all the bots (Requested by thorton on #webkit). * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-05 Mark Lam Make the C Loop LLINT work with callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125294. Reviewed by Michael Saboff. 1. Changed the C Loop LLINT to dispatch to an Executable via its JITCode instance which is consistent with how the ASM LLINT works. 2. Changed CLoop::execute() to take an Opcode instead of an OpcodeID. This makes it play nice with the use of JITCode for dispatching. 3. Introduce a callToJavaScript and callToNativeFunction for the C Loop LLINT. These will call JSStack::pushFrame() and popFrame() to setup and teardown the CallFrame. 4. Also introduced a C Loop returnFromJavaScript which is just a replacement for ctiOpThrowNotCaught which had the same function. 5. Remove a lot of #if ENABLE(LLINT_C_LOOP) code now that the dispatch mechanism is consistent. This patch has been tested with both configurations of COMPUTED_GOTOs on and off. * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::call): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::setThis): (JSC::CallFrameClosure::setArgument): (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::pushFrame): * interpreter/ProtoCallFrame.h: (JSC::ProtoCallFrame::scope): (JSC::ProtoCallFrame::callee): (JSC::ProtoCallFrame::thisValue): (JSC::ProtoCallFrame::argument): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITExceptions.cpp: (JSC::genericUnwind): * llint/LLIntCLoop.cpp: (JSC::LLInt::CLoop::initialize): * llint/LLIntCLoop.h: * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): - Inverted the check for vm.canUseJIT(). This allows the JIT case to be #if'd out nicely when building the C Loop LLINT. * llint/LLIntOpcode.h: * llint/LLIntThunks.cpp: (JSC::doCallToJavaScript): (JSC::executeJS): (JSC::callToJavaScript): (JSC::executeNative): (JSC::callToNativeFunction): * llint/LLIntThunks.h: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * runtime/Executable.h: (JSC::ExecutableBase::offsetOfNumParametersFor): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::ProgramExecutable::generatedJITCode): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): * runtime/VM.cpp: (JSC::VM::getHostFunction): 2013-12-05 Laszlo Vidacs Fix JavaScriptCore build if cloop is enabled after r160094 https://bugs.webkit.org/show_bug.cgi?id=125292 Reviewed by Michael Saboff. Move ProtoCallFrame outside the JIT guard. * jit/JITCode.h: 2013-12-04 Filip Pizlo Fold constant typed arrays https://bugs.webkit.org/show_bug.cgi?id=125205 Reviewed by Oliver Hunt and Mark Hahnenberg. If by some other mechanism we have a typed array access on a compile-time constant typed array pointer, then fold: - Array bounds checks. Specifically, fold the load of length. - Loading the vector. This needs to install a watchpoint on the array itself because of the possibility of neutering. Neutering is ridiculous. We do this without bloating the size of ArrayBuffer or JSArrayBufferView in the common case (i.e. the case where you allocated an array that didn't end up becoming a compile-time constant). To install the watchpoint, we slowDownAndWasteMemory and then create an incoming reference to the ArrayBuffer, where that incoming reference is from a watchpoint object. The ArrayBuffer already knows about such incoming references and can fire the watchpoints that way. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): (JSC::DFG::DesiredWatchpoints::addLazily): * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::GenericSetAdaptor::add): (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated): (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated): (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): (JSC::DFG::GenericDesiredWatchpoints::areStillValid): (JSC::DFG::GenericDesiredWatchpoints::isStillValid): (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isStillValid): (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isValidOrMixed): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::emitTypedArrayBoundsCheck): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): (JSC::DFG::WatchpointCollectionPhase::addLazily): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::transfer): * runtime/ArrayBufferNeuteringWatchpoint.cpp: Added. (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::~ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::finishCreation): (JSC::ArrayBufferNeuteringWatchpoint::destroy): (JSC::ArrayBufferNeuteringWatchpoint::create): (JSC::ArrayBufferNeuteringWatchpoint::createStructure): * runtime/ArrayBufferNeuteringWatchpoint.h: Added. (JSC::ArrayBufferNeuteringWatchpoint::set): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-12-04 Commit Queue Unreviewed, rolling out r160116. http://trac.webkit.org/changeset/160116 https://bugs.webkit.org/show_bug.cgi?id=125264 Change doesn't work as intended. See bug comments for details. (Requested by bfulgham on #webkit). * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Daniel Bates [iOS] Enable Objective-C ARC when building JSC tools for iOS simulator https://bugs.webkit.org/show_bug.cgi?id=125170 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: * Configurations/ToolExecutable.xcconfig: 2013-12-04 peavo@outlook.com Use ThreadingOnce class to encapsulate pthread_once functionality. https://bugs.webkit.org/show_bug.cgi?id=125228 Reviewed by Brent Fulgham. * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Mark Lam Remove unneeded semicolons. https://bugs.webkit.org/show_bug.cgi?id=125083. Rubber-stamped by Filip Pizlo. * debugger/Debugger.h: (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): 2013-12-04 Andy Estes [iOS] Build projects with $(ARCHS_STANDARD_32_64_BIT) https://bugs.webkit.org/show_bug.cgi?id=125236 Reviewed by Sam Weinig. $(ARCHS_STANDARD_32_64_BIT) is what we want for both device and simulator builds. * Configurations/DebugRelease.xcconfig: 2013-12-03 Filip Pizlo Infer constant closure variables https://bugs.webkit.org/show_bug.cgi?id=124630 Reviewed by Geoffrey Garen. Captured variables that are assigned once (not counting op_enter's Undefined initialization) and that are contained within a function that has thus far only been entered once are now constant folded. It's pretty awesome. This involves a watchpoint on the assignment to variables and a watchpoint on entry into the function. The former is reused from global variable constant inference and the latter is reused from one-time closure inference. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): * bytecode/Instruction.h: (JSC::Instruction::Instruction): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedInstruction::UnlinkedInstruction): * bytecode/VariableWatchpointSet.h: (JSC::VariableWatchpointSet::invalidate): * bytecode/Watchpoint.h: (JSC::WatchpointSet::invalidate): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitInitLazyRegister): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::emitNewFunctionInternal): (JSC::BytecodeGenerator::createArgumentsIfNecessary): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::watchableVariable): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::inferredConstant): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetActivation): (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): (JSC::JIT::emit_op_new_captured_func): (JSC::JIT::emitSlow_op_captured_mov): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/ConstantMode.h: Added. * runtime/JSGlobalObject.h: * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::prepareToWatch): 2013-12-04 Brent Fulgham [Win] Unreviewed project file gardening. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Remove deleted files from project. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Put files in proper directory folders to match the directory structure of the source code. 2013-12-04 Joseph Pecoraro Unreviewed Windows Build Fix attempt after r160099. * JavaScriptCore.vcxproj/copy-files.cmd: 2013-12-04 Julien Brianceau REGRESSION (r160094): Fix lots of crashes for sh4 architecture. https://bugs.webkit.org/show_bug.cgi?id=125227 Reviewed by Michael Saboff. * llint/LowLevelInterpreter32_64.asm: Do not use t4 and t5 as they match a0 and a1. * offlineasm/registers.rb: Add t7, t8 and t9 in register list for sh4 port. * offlineasm/sh4.rb: Rearrange RegisterID list and add the missing ones. 2013-12-03 Joseph Pecoraro Web Inspector: Push Remote Inspector debugging connection management into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=124613 Reviewed by Timothy Hatcher. Move the ENABLE(REMOTE_INSPECTOR) remote debugger connection management into JavaScriptCore (originally from WebKit/mac). Include enhancements: * allow for different types of remote debuggable targets, eventually at least a JSContext, WebView, WKView. * allow debuggables to be registered and debugged on any thread. Unlike WebViews, JSContexts may be run entirely off of the main thread. * move the remote connection (XPC connection) itself off of the main thread, it doesn't need to be on the main thread. Make JSContext @class and JavaScriptCore::JSContextRef "JavaScript" Remote Debuggables. * inspector/remote/RemoteInspectorDebuggable.h: Added. * inspector/remote/RemoteInspectorDebuggable.cpp: Added. (Inspector::RemoteInspectorDebuggable::RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::init): (Inspector::RemoteInspectorDebuggable::update): (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed): (Inspector::RemoteInspectorDebuggable::info): RemoteInspectorDebuggable defines a debuggable target. As long as something creates a debuggable and is set to allow remote inspection it will be listed in remote debuggers. For the different types of debuggables (JavaScript and Web) there is different basic information that may be listed. * inspector/InspectorFrontendChannel.h: Added. (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): The only thing a debuggable needs for remote debugging is an InspectorFrontendChannel a way to send messages to a remote frontend. This class provides that method, and is vended to the RemoteInspectorDebuggable when a remote connection is setup. * inspector/remote/RemoteInspector.h: Added. * inspector/remote/RemoteInspector.mm: Added. Singleton, created at least when the first Debuggable is created. This class manages the list of debuggables, any connection to a remote debugger proxy (XPC service "com.apple.webinspector"). (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): (Inspector::RemoteInspector::shared): (Inspector::RemoteInspector::RemoteInspector): (Inspector::RemoteInspector::nextAvailableIdentifier): (Inspector::RemoteInspector::registerDebuggable): (Inspector::RemoteInspector::unregisterDebuggable): (Inspector::RemoteInspector::updateDebuggable): Debuggable management. When debuggables are added, removed, or updated we stash a copy of the debuggable information and push an update to debuggers. Stashing a copy of the information in the RemoteInspector is a thread safe way to avoid walking over all debuggables to gather the information when it is needed. (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stop): Runtime API to enable / disable the feature. (Inspector::RemoteInspector::listingForDebuggable): (Inspector::RemoteInspector::pushListingNow): (Inspector::RemoteInspector::pushListingSoon): Pushing a listing to remote debuggers. (Inspector::RemoteInspector::sendMessageToRemoteFrontend): (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): (Inspector::RemoteInspector::xpcConnectionReceivedMessage): (Inspector::RemoteInspector::xpcConnectionFailed): (Inspector::RemoteInspector::xpcConnectionUnhandledMessage): XPC setup, send, and receive handling. (Inspector::RemoteInspector::updateHasActiveDebugSession): Applications being debugged may want to know when a debug session is active. This provides that notification. (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedGetListingMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): Dispatching incoming remote debugging protocol messages. These are wrapping above the inspector protocol messages. * inspector/remote/RemoteInspectorConstants.h: Added. Protocol messages and dictionary keys inside the messages. (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo): * inspector/remote/RemoteInspectorDebuggableConnection.h: Added. * inspector/remote/RemoteInspectorDebuggableConnection.mm: Added. This is a connection between the RemoteInspector singleton and a RemoteInspectorDebuggable. (Inspector::RemoteInspectorDebuggableConnection::RemoteInspectorDebuggableConnection): (Inspector::RemoteInspectorDebuggableConnection::~RemoteInspectorDebuggableConnection): Allow for dispatching messages on JavaScript debuggables on a dispatch_queue instead of the main queue. (Inspector::RemoteInspectorDebuggableConnection::destination): (Inspector::RemoteInspectorDebuggableConnection::connectionIdentifier): Needed in the remote debugging protocol to identify the remote debugger. (Inspector::RemoteInspectorDebuggableConnection::dispatchSyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::dispatchAsyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::setup): (Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable): (Inspector::RemoteInspectorDebuggableConnection::close): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend): The connection is a thin channel between the two sides that can be closed from either side, so there is some logic around multi-threaded access. * inspector/remote/RemoteInspectorXPCConnection.h: Added. (Inspector::RemoteInspectorXPCConnection::Client::~Client): * inspector/remote/RemoteInspectorXPCConnection.mm: Added. (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::close): (Inspector::RemoteInspectorXPCConnection::deserializeMessage): (Inspector::RemoteInspectorXPCConnection::handleEvent): (Inspector::RemoteInspectorXPCConnection::sendMessage): This is a connection between the RemoteInspector singleton and an XPC service named "com.apple.webinspector". This handles serialization of the dictionary messages to and from the service. The receiving is done on a non-main queue. * API/JSContext.h: * API/JSContext.mm: (-[JSContext name]): (-[JSContext setName:]): ObjC API to enable/disable JSContext remote inspection and give a name. * API/JSContextRef.h: * API/JSContextRef.cpp: (JSGlobalContextGetName): (JSGlobalContextSetName): C API to give a JSContext a name. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setName): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::name): Shared handling of the APIs above. * runtime/JSGlobalObjectDebuggable.cpp: Added. (JSC::JSGlobalObjectDebuggable::JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::name): (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): * runtime/JSGlobalObjectDebuggable.h: Added. Stub for the actual remote debugging implementation. We will push down the appropriate WebCore/inspector peices suitable for debugging just a JavaScript context. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Update build files. 2013-12-04 Michael Saboff Move the setting up of callee's callFrame from pushFrame to callToJavaScript thunk https://bugs.webkit.org/show_bug.cgi?id=123999 Reviewed by Filip Pizlo. Changed LLInt and/or JIT enabled ports to allocate the stack frame in the callToJavaScript stub. Added an additional stub, callToNativeFunction that allocates a stack frame in a similar way for calling native entry points that take a single ExecState* argument. These stubs are implemented using common macros in LowLevelInterpreter{32_64,64}.asm. There are also Windows X86 and X86-64 versions in the corresponding JitStubsXX.h. The stubs allocate and create a sentinel frame, then create the callee's frame, populating the header and arguments from the passed in ProtoCallFrame*. It is assumed that the caller of either stub does a check for enough stack space via JSStack::entryCheck(). For ports using the C-Loop interpreter, the prior method for allocating stack frame and invoking functions is used, namely with JSStack::pushFrame() and ::popFrame(). Made spelling changes "sentinal" -> "sentinel". * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::setThis): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::entryCheck): (JSC::JSStack::pushFrame): (JSC::JSStack::popFrame): * interpreter/ProtoCallFrame.cpp: Added. (JSC::ProtoCallFrame::init): * interpreter/ProtoCallFrame.h: Added. (JSC::ProtoCallFrame::codeBlock): (JSC::ProtoCallFrame::setCodeBlock): (JSC::ProtoCallFrame::setScope): (JSC::ProtoCallFrame::setCallee): (JSC::ProtoCallFrame::argumentCountIncludingThis): (JSC::ProtoCallFrame::argumentCount): (JSC::ProtoCallFrame::setArgumentCountIncludingThis): (JSC::ProtoCallFrame::setPaddedArgsCount): (JSC::ProtoCallFrame::clearCurrentVPC): (JSC::ProtoCallFrame::setThisValue): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITOperations.cpp: * jit/JITStubs.h: * jit/JITStubsMSVC64.asm: * jit/JITStubsX86.h: * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntThunks.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.h: (JSC::ArgList::data): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): 2013-12-04 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125220 Reviewed by Michael Saboff. * interpreter/VMInspector.cpp: * jit/JITArithmetic.cpp: * jit/JITArithmetic32_64.cpp: * jit/JITCall.cpp: * jit/JITCall32_64.cpp: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: * runtime/Completion.cpp: * runtime/IndexingType.cpp: * runtime/Lookup.h: * runtime/Operations.cpp: * runtime/Options.cpp: * runtime/RegExp.cpp: 2013-12-04 László Langó Avoid to add zero offset in BaseIndex. https://bugs.webkit.org/show_bug.cgi?id=125215 Reviewed by Michael Saboff. When using cloop do not generate offsets additions for BaseIndex if the offset is zero. * offlineasm/cloop.rb: 2013-12-04 Peter Molnar Fix !ENABLE(JAVASCRIPT_DEBUGGER) build. https://bugs.webkit.org/show_bug.cgi?id=125083 Reviewed by Mark Lam. * debugger/Debugger.cpp: * debugger/Debugger.h: (JSC::Debugger::Debugger): (JSC::Debugger::needsOpDebugCallbacks): (JSC::Debugger::needsExceptionCallbacks): (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): * debugger/DebuggerPrimitives.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: 2013-12-03 Mark Lam testapi test crashes on Windows in WTF::Vector::size(). https://bugs.webkit.org/show_bug.cgi?id=121972. Reviewed by Brent Fulgham. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): - Reverting the change from r160004 since it's better to fix OSAllocatorWin to be consistent with OSAllocatorPosix. 2013-12-03 Mark Lam Fix LLINT_C_LOOP build for Win64. https://bugs.webkit.org/show_bug.cgi?id=125186. Reviewed by Michael Saboff. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * jit/JITOperationsMSVC64.cpp: Added. (JSC::getHostCallReturnValueWithExecState): - Win64 will build JITStubMSVC64.asm even when !ENABLE(JIT). This results in a linkage error due to a missing getHostCallReturnValueWithExecState(). So, we add a stub getHostCallReturnValueWithExecState() here to satisfy that linkage. This function will never be called. The alternative to providing such a stub is to make the MSVC project recognize if the JIT is enabled or not, and exclude JITStubMSVC64.asm if it's not enabled. We don't currently set ENABLE(JIT) via the MSVC project and the work to do that is too much trouble for what we're trying to achieve here. So, we're opting for this simpler workaround instead. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): - Don't build callToJavaScript if we're building the C loop. Otherwise, the C loop won't build if !ENABLE(COMPUTE_GOTO_OPCODES). 2013-12-03 Michael Saboff ARM64: Crash in JIT code due to improper reuse of cached memory temp register https://bugs.webkit.org/show_bug.cgi?id=125181 Reviewed by Geoffrey Garen. Changed load8() and load() to invalidate the memory temp CachedTempRegister when the destination of an absolute load is the memory temp register since the source address is also the memory temp register. Change branch{8,32,64} of an AbsoluteAddress with a register to use the dataTempRegister as the destinate of the absolute load to reduce the chance that we need to invalidate the memory temp register cache. In the process, found and fixed an outright bug in branch8() where we'd load into the data temp register and then compare and branch on the memory temp register. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::branch32): (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branch8): (JSC::MacroAssemblerARM64::load): 2013-12-03 Michael Saboff jit/JITArithmetic.cpp doesn't build for non-X86 ports https://bugs.webkit.org/show_bug.cgi?id=125185 Rubber stamped by Mark Hahnenberg. Removed unused declarations and related UNUSED_PARAM(). * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_mod): 2013-12-03 Filip Pizlo ObjectAllocationProfile is racy and the DFG should be cool with that https://bugs.webkit.org/show_bug.cgi?id=125172 Reviewed by Mark Hahnenberg. We would previously sometimes get a null Structure because checking if the profile is non-null and loading the structure from it were two separate operations. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::setFuturePossibleStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * runtime/JSFunction.h: (JSC::JSFunction::allocationProfile): (JSC::JSFunction::allocationStructure): 2013-12-03 peavo@outlook.com testapi test crashes on Windows in WTF::Vector::size() https://bugs.webkit.org/show_bug.cgi?id=121972 Reviewed by Michael Saboff. The reason for the crash is that the wrong memory block is decommitted. This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): Don't decommit memory if nothing has been committed. 2013-12-03 László Langó Guard JIT include. https://bugs.webkit.org/show_bug.cgi?id=125063 Reviewed by Filip Pizlo. * llint/LLIntThunks.cpp: 2013-12-03 Julien Brianceau Merge mips and arm/sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=125067 Reviewed by Michael Saboff. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): 2013-12-02 Mark Lam Build failure when disabling JIT, YARR_JIT, and ASSEMBLER. https://bugs.webkit.org/show_bug.cgi?id=123809. Reviewed by Geoffrey Garen. Also fixed build when disabling the DISASSEMBLER. Added some needed #if's and some comments. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * dfg/DFGDisassembler.cpp: * dfg/DFGDisassembler.h: (JSC::DFG::Disassembler::Disassembler): (JSC::DFG::Disassembler::setStartOfCode): (JSC::DFG::Disassembler::setForBlockIndex): (JSC::DFG::Disassembler::setForNode): (JSC::DFG::Disassembler::setEndOfMainPath): (JSC::DFG::Disassembler::setEndOfCode): (JSC::DFG::Disassembler::dump): (JSC::DFG::Disassembler::reportToProfiler): * disassembler/Disassembler.cpp: * disassembler/X86Disassembler.cpp: * jit/FPRInfo.h: * jit/GPRInfo.h: * jit/JITDisassembler.cpp: * jit/JITDisassembler.h: (JSC::JITDisassembler::JITDisassembler): (JSC::JITDisassembler::setStartOfCode): (JSC::JITDisassembler::setForBytecodeMainPath): (JSC::JITDisassembler::setForBytecodeSlowPath): (JSC::JITDisassembler::setEndOfSlowPath): (JSC::JITDisassembler::setEndOfCode): (JSC::JITDisassembler::dump): (JSC::JITDisassembler::reportToProfiler): 2013-12-02 Filip Pizlo Baseline JIT calls to CommonSlowPaths shouldn't restore the last result https://bugs.webkit.org/show_bug.cgi?id=125107 Reviewed by Mark Hahnenberg. Just killing dead code. * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitSlow_op_rshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emit_op_mod): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emitSlow_op_div): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_strcat): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): 2013-12-01 Filip Pizlo Stores to local captured variables should be intercepted https://bugs.webkit.org/show_bug.cgi?id=124883 Reviewed by Mark Hahnenberg. Previously, in bytecode, you could assign to a captured variable just as you would assign to any other kind of variable. This complicates closure variable constant inference because we don't have any place where we can intercept stores to captured variables in the LLInt. This patch institutes a policy that only certain instructions can store to captured variables. If you interpret those instructions and you are required to notifyWrite() then you need to check if the relevant variable is captured. Those instructions are tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov. In the future, we'll probably modify those instructions to have a pointer directly to the VariableWatchpointSet; but for now we just introduce the captured instructions as placeholders. In order to validate that the placeholders are inserted correctly, this patch improves the CodeBlock validation to be able to inspect every def in the bytecode. To do that, this patch refactors the liveness analysis' use/def calculator to be reusable; it now takes a functor for each use or def. In the process of refactoring the liveness analysis, I noticed that op_enter was claiming to def all callee registers. That's wrong; it only defs the non-temporary variables. Making that change revealed preexisting bugs in the liveness analysis, since now the validator would pick up cases where the bytecode claimed to use a temporary and the def calculator never noticed the definition (or the converse - where the bytecode was actually not using a temporary but the liveness analysis thought that it was a use). This patch fixes a few of those bugs. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::stepOverInstruction): * bytecode/BytecodeUseDef.h: Added. (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::isCaptured): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolveCallee): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::isCaptured): (JSC::BytecodeGenerator::local): (JSC::BytecodeGenerator::constLocal): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitLazyNewFunction): (JSC::BytecodeGenerator::emitNewFunctionInternal): * bytecompiler/BytecodeGenerator.h: (JSC::Local::Local): (JSC::Local::isCaptured): (JSC::Local::captureMode): (JSC::BytecodeGenerator::captureMode): (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::pushOptimisedForIn): * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): (JSC::ForInNode::emitBytecode): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/SymbolTable.h: (JSC::SymbolTable::isCaptured): 2013-12-02 Filip Pizlo Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables https://bugs.webkit.org/show_bug.cgi?id=125052 Reviewed by Mark Hahnenberg. This makes us watch function entry rather than activation creation. We only incur the costs of doing so for functions that have captured variables, and only on the first two entries into the function. This means that closure variable constant inference will naturally work even for local uses of the captured variable, like: (function(){ var blah = 42; ... // stuff function () { ... blah /* we can fold this to 42 */ } ... blah // we can also fold this to 42. })(); Previously, only the nested use would have been foldable. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::touch): (JSC::InlineWatchpointSet::touch): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasSymbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_touch_entry): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-12-02 Nick Diego Yamane [JSC] Get rid of some unused parameters in LLIntSlowPaths.cpp macros https://bugs.webkit.org/show_bug.cgi?id=125075 Reviewed by Michael Saboff. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): added UNUSED_PARAM(pc). (JSC::LLInt::setUpCall): Doesn't pass 'pc' to LLINT_CALL macros. (JSC::LLInt::LLINT_SLOW_PATH_DECL): Ditto. 2013-12-02 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125066 Reviewed by Michael Saboff. Remove stdio.h, when it is not necessary to be included. * bytecode/CodeBlock.cpp: * bytecode/StructureSet.h: * profiler/LegacyProfiler.cpp: * profiler/Profile.cpp: * profiler/ProfileNode.cpp: * yarr/YarrInterpreter.cpp: 2013-12-02 László Langó Unused include files when building without JIT. https://bugs.webkit.org/show_bug.cgi?id=125062 Reviewed by Michael Saboff. We should organize the includes, and guard JIT methods in ValueRecovery. * bytecode/ValueRecovery.cpp: Guard include files. * bytecode/ValueRecovery.h: Guard JIT methods. 2013-12-02 Balazs Kilvady [MIPS] Small stack frame causes regressions. https://bugs.webkit.org/show_bug.cgi?id=124945 Reviewed by Michael Saboff. Fix stack space for LLInt on MIPS. * llint/LowLevelInterpreter32_64.asm: 2013-12-02 Brian J. Burg jsc: implement a native readFile function https://bugs.webkit.org/show_bug.cgi?id=125059 Reviewed by Filip Pizlo. This adds a native readFile() function to jsc, used to slurp an entire file into a JavaScript string. * jsc.cpp: (GlobalObject::finishCreation): Add readFile() to globals. (functionReadFile): Added. 2013-12-02 László Langó JSC does not build if OPCODE_STATS is enabled. https://bugs.webkit.org/show_bug.cgi?id=125011 Reviewed by Filip Pizlo. * bytecode/Opcode.cpp: 2013-11-29 Filip Pizlo Finally remove those DFG_ENABLE things https://bugs.webkit.org/show_bug.cgi?id=125025 Rubber stamped by Sam Weinig. This removes a bunch of unused and untested insanity. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::tallyFrequentExitSites): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::makeDivSafe): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::linkBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::parse): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::convertToJump): (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::endIndexForPureCSE): (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): (JSC::DFG::CSEPhase::setReplacement): (JSC::DFG::CSEPhase::eliminate): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCommon.h: (JSC::DFG::verboseCompilationEnabled): (JSC::DFG::logCompilationChanges): (JSC::DFG::shouldDumpGraphAtEachPhase): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::endBasicBlock): (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::run): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::propagateForward): (JSC::DFG::PredictionPropagationPhase::propagateBackward): (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::use): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::generate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): (JSC::DFG::SpeculativeJIT::dump): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * dfg/DFGVariableEventStream.h: (JSC::DFG::VariableEventStream::appendAndLog): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * jit/JIT.cpp: (JSC::JIT::privateCompile): 2013-11-29 Filip Pizlo FTL IC should nop-fill to make up the difference between the actual IC size and the requested patchpoint size https://bugs.webkit.org/show_bug.cgi?id=124960 Reviewed by Sam Weinig. * assembler/LinkBuffer.h: (JSC::LinkBuffer::size): * assembler/X86Assembler.h: (JSC::X86Assembler::fillNops): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpHeader): * ftl/FTLCompile.cpp: (JSC::FTL::generateICFastPath): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::dumpHeader): 2013-11-29 Julien Brianceau Use moveDoubleToInts in SpecializedThunkJIT::returnDouble for non-X86 JSVALUE32_64 ports. https://bugs.webkit.org/show_bug.cgi?id=124936 Reviewed by Zoltan Herczeg. The moveDoubleToInts implementations in ARM, MIPS and SH4 macro assemblers do not clobber src FPRegister and are likely to be more efficient than the current generic implementation using the stack. * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::returnDouble): 2013-11-29 Julien Brianceau Merge arm and sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=124892 Reviewed by Zoltan Herczeg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::call): Pick a scratch register instead of getting it as a parameter. The sh4 port was the only one to have this call(Address, RegisterID) prototype. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): Use argumentGPRx and merge arm and sh4 paths. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): Use argumentGPRx and merge arm and sh4 paths. 2013-11-28 Nadav Rotem Revert the X86 assembler peephole changes https://bugs.webkit.org/show_bug.cgi?id=124988 Reviewed by Csaba Osztrogonác. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::branchAdd32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-28 Antti Koivisto Remove feature: CSS variables https://bugs.webkit.org/show_bug.cgi?id=114119 Reviewed by Andreas Kling. * Configurations/FeatureDefines.xcconfig: 2013-11-28 Peter Gal Typo fix after r159834 to fix 32 bit builds. Reviewed by Csaba Osztrogonác. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-11-27 Nadav Rotem Add a bunch of early exits and local optimizations to the x86 assembler. https://bugs.webkit.org/show_bug.cgi?id=124904 Reviewed by Filip Pizlo. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-27 Filip Pizlo Infer one-time scopes https://bugs.webkit.org/show_bug.cgi?id=124812 Reviewed by Oliver Hunt. This detects JSActivations that are created only once. The JSActivation pointer is then baked into the machine code. This takes advantage of the one-time scope inference to reduce the number of indirections needed to get to a closure variable in case where the scope is only allocated once. This isn't really a speed-up since in the common case the total number of instruction bytes needed to load the scope from the stack is about equal to the number of instruction bytes needed to materialize the absolute address of a scoped variable. But, this is a necessary prerequisite to https://bugs.webkit.org/show_bug.cgi?id=124630, so it's probably a good idea anyway. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finalizeUnconditionally): * bytecode/Instruction.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::notifyWrite): (JSC::InlineWatchpointSet::notifyWrite): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitResolveScope): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::scopedVarLoadElimination): (JSC::DFG::CSEPhase::scopedVarStoreElimination): (JSC::DFG::CSEPhase::getLocalLoadElimination): (JSC::DFG::CSEPhase::setLocalStoreElimination): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::varNumber): (JSC::DFG::Node::hasSymbolTable): (JSC::DFG::Node::symbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::abstractResolve): * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSVariableObject.h: (JSC::JSVariableObject::registers): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-11-27 Filip Pizlo Finally fix some obvious Bartlett bugs https://bugs.webkit.org/show_bug.cgi?id=124951 Reviewed by Mark Hahnenberg. Sanitize the stack (i.e. zero parts of it known to be dead) at three key points: - GC. - At beginning of OSR entry. - Just as we finish preparing OSR entry. This clears those slots on the stack that could have been live in baseline but that are known to be dead in DFG. This is as much as a 2x speed-up on splay if you run it in certain modes, and run it for a long enough interval. It appears to fix all instances of the dreaded exponential heap growth that splay gets into when some stale pointer stays around. This doesn't have much of an effect on real-world programs. This bug has only ever manifested in splay and for that reason we thus far opted against fixing it. But splay is, for what it's worth, the premiere GC stress test in JavaScript - so making sure we can run it without pathologies - even when you tweak its configuration - is probably fairly important. * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: 2013-11-26 Filip Pizlo Do bytecode validation as part of testing https://bugs.webkit.org/show_bug.cgi?id=124913 Reviewed by Oliver Hunt. Also fix some small bugs in the bytecode liveness analysis that I found by doing this validation thingy. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::isValidRegisterForLiveness): (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::validate): (JSC::CodeBlock::beginValidationDidFail): (JSC::CodeBlock::endValidationDidFail): * bytecode/CodeBlock.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/Options.h: 2013-11-27 Andreas Kling Structure::m_staticFunctionReified should be a single bit. Shave 8 bytes off of JSC::Structure by jamming m_staticFunctionReified into the bitfield just above. Reviewed by Antti Koivisto. 2013-11-27 Andreas Kling JSActivation constructor should use NotNull placement new. Knock a null check outta the storage initialization loop. Reviewed by Antti Koivisto. 2013-11-26 Filip Pizlo Restructure global variable constant inference so that it could work for any kind of symbol table variable https://bugs.webkit.org/show_bug.cgi?id=124760 Reviewed by Oliver Hunt. This changes the way global variable constant inference works so that it can be reused for closure variable constant inference. Some of the premises that originally motivated this patch are somewhat wrong, but it led to some simplifications anyway and I suspect that we'll be able to fix those premises in the future. The main point of this patch is to make it easy to reuse global variable constant inference for closure variable constant inference, and this will be possible provided we can also either (a) infer one-shot closures (easy) or (b) infer closure variables that are always assigned prior to first use. One of the things that this patch is meant to enable is constant inference for closure variables that may be part of a multi-shot closure. Closure variables may be instantiated multiple times, like: function foo() { var WIDTH = 45; function bar() { ... use WIDTH ... } ... } Even if foo() is called many times and WIDTH is assigned to multiple times, that doesn't change the fact that it's a constant. The goal of closure variable constant inference is to catch any case where a closure variable has been assigned at least once and its value has never changed. This patch doesn't implement that, but it does change global variable constant inference to have most of the powers needed to do that. Note that most likely we will use this functionality only to implement constant inference for one-shot closures, but the resulting machinery is still simpler than what we had before. This involves three changes: - The watchpoint object now contains the inferred value. This involves creating a new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object for closure variables. - Writing to a variable that is watchpointed still involves these three states that we proceed through monotonically (Uninitialized->Initialized->Invalidated) but now, the Initialized->Invalidated state transition only happens if we change the variable's value, rather than store to the variable. Repeatedly storing the same value won't change the variable's state. - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer need fancy fencing to get a consistent view of the watchpoint in the JIT. The state of the VariableWatchpointSet for the purposes of constant folding is entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is JSValue() then you cannot fold (either because the set is uninitialized or because it's invalidated - doesn't matter which); on the other hand if the value is anything other than JSValue() then you can fold, and that's the value you fold to. Simple! This also changes the way that DFG IR deals with variable watchpoints. It's now oblivious to global variables. You install a watchpoint using VariableWatchpoint and you notify write using NotifyWrite. Easy! Note that this will requires some more tweaks because of the fact that op_enter will store Undefined into every captured variable. Hence it won't even work for one-shot closures. One-shot closures are easily fixed by introducing another state (so we'll have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will require static analysis. One-shot closures are clearly a higher priority. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Instruction.h: * bytecode/VariableWatchpointSet.h: Added. (JSC::VariableWatchpointSet::VariableWatchpointSet): (JSC::VariableWatchpointSet::~VariableWatchpointSet): (JSC::VariableWatchpointSet::inferredValue): (JSC::VariableWatchpointSet::notifyWrite): (JSC::VariableWatchpointSet::invalidate): (JSC::VariableWatchpointSet::finalizeUnconditionally): (JSC::VariableWatchpointSet::addressOfInferredValue): * bytecode/Watchpoint.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasRegisterPointer): (JSC::DFG::Node::hasVariableWatchpointSet): (JSC::DFG::Node::variableWatchpointSet): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addFunction): * runtime/JSGlobalObject.h: * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::inferredValue): (JSC::SymbolTableEntry::prepareToWatch): (JSC::SymbolTableEntry::addWatchpoint): (JSC::SymbolTableEntry::notifyWriteSlow): (JSC::SymbolTable::visitChildren): (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::watchpointSet): (JSC::SymbolTableEntry::notifyWrite): 2013-11-24 Filip Pizlo Create a new SymbolTable every time code is loaded so that the watchpoints don't get reused https://bugs.webkit.org/show_bug.cgi?id=124824 Reviewed by Oliver Hunt. This helps with one shot closure inference as well as closure variable constant inference, since without this, if code was reloaded from the cache then we would think that the first run was actually an Nth run. This would cause us to think that the watchpoint(s) should all be invalidated. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/CodeBlock.h: (JSC::CodeBlock::symbolTable): * runtime/Executable.cpp: (JSC::FunctionExecutable::symbolTable): * runtime/Executable.h: * runtime/SymbolTable.cpp: (JSC::SymbolTable::clone): * runtime/SymbolTable.h: 2013-11-26 Oliver Hunt Crash in JSC::ASTBuilder::Expression JSC::Parser >::parseUnaryExpression(JSC::ASTBuilder&) https://bugs.webkit.org/show_bug.cgi?id=124886 Reviewed by Sam Weinig. Make sure the error macros propagate an existing error before trying to create a new error message. We need to do this as the parser state may not be safe for any specific error message if we are already unwinding due to an error. * parser/Parser.cpp: 2013-11-26 Nadav Rotem Optimize away OR with zero - a common ASM.js pattern. https://bugs.webkit.org/show_bug.cgi?id=124869 Reviewed by Filip Pizlo. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2013-11-25 Julien Brianceau [arm][mips] Fix crash in dfg-arrayify-elimination layout jsc test. https://bugs.webkit.org/show_bug.cgi?id=124839 Reviewed by Michael Saboff. In ARM EABI and MIPS, 64-bit values have to be aligned on stack too. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/JITInlines.h: (JSC::JIT::callOperation): Add missing EABI_32BIT_DUMMY_ARG. 2013-11-23 Filip Pizlo Fix more fallout from failed attempts at div/mod DFG strength reductions https://bugs.webkit.org/show_bug.cgi?id=124813 Reviewed by Geoffrey Garen. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): 2013-11-22 Mark Hahnenberg JSC Obj-C API should have real documentation https://bugs.webkit.org/show_bug.cgi?id=124805 Reviewed by Geoffrey Garen. Massaging the header comments into proper headerdocs. * API/JSContext.h: * API/JSExport.h: * API/JSManagedValue.h: * API/JSValue.h: * API/JSVirtualMachine.h: 2013-11-22 Filip Pizlo CodeBlock::m_numCalleeRegisters shouldn't also mean frame size, frame size needed for exit, or any other unrelated things https://bugs.webkit.org/show_bug.cgi?id=124793 Reviewed by Mark Hahnenberg. Now m_numCalleeRegisters always refers to the number of locals that the attached bytecode uses. It never means anything else. For frame size, we now have it lazily computed from m_numCalleeRegisters for the baseline engines and we have it stored in DFG::CommonData for the optimizing JITs. For frame-size-needed-at-exit, we store that in DFG::CommonData, too. The code no longer implies that there is any arithmetic relationship between m_numCalleeRegisters and frameSize. Previously it implied that the latter is greater than the former. The code no longer implies that there is any arithmetic relationship between the frame Size and the frame-size-needed-at-exit. Previously it implied that the latter is greater that the former. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::frameRegisterCount): * bytecode/CodeBlock.h: * dfg/DFGCommonData.h: (JSC::DFG::CommonData::CommonData): (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::frameRegisterCount): (JSC::DFG::Graph::requiredRegisterCountForExit): (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGGraph.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * interpreter/CallFrame.cpp: (JSC::CallFrame::frameExtentInternal): * interpreter/JSStackInlines.h: (JSC::JSStack::pushFrame): * jit/JIT.h: (JSC::JIT::frameRegisterCountFor): * jit/JITOperations.cpp: * llint/LLIntEntrypoint.cpp: (JSC::LLInt::frameRegisterCountFor): * llint/LLIntEntrypoint.h: 2013-11-21 Filip Pizlo Combine SymbolTable and SharedSymbolTable https://bugs.webkit.org/show_bug.cgi?id=124761 Reviewed by Geoffrey Garen. SymbolTable was never used directly; we now always used SharedSymbolTable. So, this gets rid of SymbolTable and renames SharedSymbolTable to SymbolTable. * bytecode/CodeBlock.h: (JSC::CodeBlock::symbolTable): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedFunctionExecutable::symbolTable): (JSC::UnlinkedCodeBlock::symbolTable): (JSC::UnlinkedCodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::symbolTable): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::symbolTableFor): * runtime/Arguments.h: (JSC::Arguments::finishCreation): * runtime/Executable.h: (JSC::FunctionExecutable::symbolTable): * runtime/JSActivation.h: (JSC::JSActivation::create): (JSC::JSActivation::JSActivation): (JSC::JSActivation::registersOffset): (JSC::JSActivation::allocationSize): * runtime/JSSymbolTableObject.h: (JSC::JSSymbolTableObject::symbolTable): (JSC::JSSymbolTableObject::JSSymbolTableObject): (JSC::JSSymbolTableObject::finishCreation): * runtime/JSVariableObject.h: (JSC::JSVariableObject::JSVariableObject): * runtime/SymbolTable.cpp: (JSC::SymbolTable::destroy): (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: (JSC::SymbolTable::create): (JSC::SymbolTable::createStructure): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-11-22 Mark Lam Remove residual references to "dynamicGlobalObject". https://bugs.webkit.org/show_bug.cgi?id=124787. Reviewed by Filip Pizlo. * JavaScriptCore.order: * interpreter/CallFrame.h: 2013-11-22 Mark Lam Ensure that arity fixups honor stack alignment requirements. https://bugs.webkit.org/show_bug.cgi?id=124756. Reviewed by Geoffrey Garen. The LLINT and all the JITs rely on CommonSlowPaths::arityCheckFor() to compute the arg count adjustment for the arity fixup. We take advantage of this choke point and introduce the stack alignment padding there in the guise of additional args. The only cost of this approach is that the padding will also be initialized to undefined values as if they were args. Since arity fixups are considered a slow path that is rarely taken, this cost is not a concern. * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/VM.h: (JSC::VM::isSafeToRecurse): 2013-11-21 Filip Pizlo BytecodeGenerator should align the stack according to native conventions https://bugs.webkit.org/show_bug.cgi?id=124735 Reviewed by Mark Lam. Rolling this back in because it actually fixed fast/dom/gc-attribute-node.html, but our infrastructure misleads peole into thinking that fixing a test constitutes breaking it. * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): 2013-11-21 Filip Pizlo Get rid of CodeBlock::dumpStatistics() https://bugs.webkit.org/show_bug.cgi?id=124762 Reviewed by Mark Hahnenberg. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::~CodeBlock): * bytecode/CodeBlock.h: 2013-11-22 Commit Queue Unreviewed, rolling out r159652. http://trac.webkit.org/changeset/159652 https://bugs.webkit.org/show_bug.cgi?id=124778 broke fast/dom/gc-attribute-node.html (Requested by ap on #webkit). * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): (JSC::CallArguments::newArgument): 2013-11-21 Filip Pizlo Fix a typo (requriements->requirements). * runtime/StackAlignment.h: 2013-11-21 Mark Lam CodeBlock::m_numCalleeRegisters need to honor native stack alignment. https://bugs.webkit.org/show_bug.cgi?id=124754. Reviewed by Filip Pizlo. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::newRegister): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): 2013-11-21 Mark Rowe Stop overriding VALID_ARCHS. All modern versions of Xcode set it appropriately for our needs. Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: 2013-11-21 Mark Rowe Fix an error in a few Xcode configuration setting files. Reviewed by Alexey Proskuryakov. * Configurations/Base.xcconfig: 2013-11-21 Michael Saboff ARM64: Implement push/pop equivalents in LLInt https://bugs.webkit.org/show_bug.cgi?id=124721 Reviewed by Filip Pizlo. Added pushLRAndFP and popLRAndFP that push and pop the link register and frame pointer register. These ops emit code just like what the compiler emits in the prologue and epilogue. Also changed pushCalleeSaves and popCalleeSaves to use the same store pair and load pair instructions to do the actually pushing and popping. Finally changed the implementation of push and pop to raise an exception since we don't have (or need) a single register push or pop. * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: 2013-11-21 Michael Saboff JSC: Removed unused opcodes from offline assembler https://bugs.webkit.org/show_bug.cgi?id=124749 Reviewed by Mark Hahnenberg. Removed the unused, X86 only peekq and pokeq. * offlineasm/instructions.rb: * offlineasm/x86.rb: 2013-11-21 Michael Saboff REGRESSION(159395) Fix branch8(…, AbsoluteAddress, …) in ARM64 MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=124688 Reviewed by Geoffrey Garen. Changed handling of the address for the load8() in the branch8(AbsoluteAddress) to be like the rest of the branchXX(AbsoluteAddress) fucntions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::branch8): 2013-11-21 Filip Pizlo BytecodeGenerator should align the stack according to native conventions https://bugs.webkit.org/show_bug.cgi?id=124735 Reviewed by Mark Lam. * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::registerOffset): (JSC::CallArguments::argumentCountIncludingThis): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): 2013-11-21 Filip Pizlo Unreviewed, preemptive build fix. * runtime/StackAlignment.h: (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2013-11-21 Filip Pizlo JSC should know what the stack alignment conventions are https://bugs.webkit.org/show_bug.cgi?id=124736 Reviewed by Mark Lam. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/StackAlignment.h: Added. (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2013-11-21 Balazs Kilvady [MIPS] Build fails since r159545. https://bugs.webkit.org/show_bug.cgi?id=124716 Reviewed by Michael Saboff. Add missing implementations in MacroAssembler and LLInt for MIPS. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::sync): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::store8): (JSC::MacroAssemblerMIPS::memoryFence): * offlineasm/mips.rb: 2013-11-21 Julien Brianceau Fix sh4 build after r159545. https://bugs.webkit.org/show_bug.cgi?id=124713 Reviewed by Michael Saboff. Add missing implementations in macro assembler and LLINT for sh4. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::load8): (JSC::MacroAssemblerSH4::store8): (JSC::MacroAssemblerSH4::memoryFence): * assembler/SH4Assembler.h: (JSC::SH4Assembler::synco): * offlineasm/sh4.rb: Handle "memfence" opcode. 2013-11-20 Mark Lam Introducing VMEntryScope to update the VM stack limit. https://bugs.webkit.org/show_bug.cgi?id=124634. Reviewed by Geoffrey Garen. 1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h). Currently, it is hardcoded to use separate C and JS stacks. Once we switch to using the C stack for JS frames, we'll need to fix this to only be enabled when ENABLE(LLINT_C_LOOP). 2. Stack limits are now tracked in the VM. Logically, there are 2 stack limits: a. m_stackLimit for the native C stack, and b. m_jsStackLimit for the JS stack. If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same value, and are implemented as 2 fields in a union. 3. The VM native stackLimit is set as follows: a. Initially, the VM sets it to the limit of the stack of the thread that instantiated the VM. This allows the parser and bytecode generator to run before we enter the VM to execute JS code. b. Upon entry into the VM to execute JS code (via one of the Interpreter::execute...() functions), we instantiate a VMEntryScope that sets the VM's stackLimit to the limit of the current thread's stack. The VMEntryScope will automatically restore the previous entryScope and stack limit upon destruction. If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's jsStackLimit whenever it grows or shrinks. 4. The VM now provides a isSafeToRecurse() function that compares the current stack pointer against its native stackLimit. This subsumes and obsoletes the VMStackBounds class. 5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for tracking the JSGlobalObject that we last entered the VM with. 6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is the value that the function retrieves. 7. Changed JIT and LLINT code to do stack checks against the jsStackLimit in the VM class instead of the JSStack. * API/JSBase.cpp: (JSEvaluateScript): (JSCheckScriptSyntax): * API/JSContextRef.cpp: (JSGlobalContextRetain): (JSGlobalContextRelease): * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::emitNodeInConditionContext): * debugger/Debugger.cpp: (JSC::Debugger::detach): (JSC::Debugger::recompileAllJSFunctions): (JSC::Debugger::pauseIfNeeded): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::vmEntryGlobalObject): * debugger/DebuggerCallFrame.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSREntry.cpp: * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLOSREntry.cpp: * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::deleteAllCompiledCode): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): (JSC::Interpreter::unwind): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::debug): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::shrink): (JSC::JSStack::grow): - Moved these inlined functions here from JSStack.h. It reduces some #include dependencies of JSSTack.h which had previously resulted in some EWS bots' unhappiness with this patch. (JSC::JSStack::updateStackLimit): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::::Parser): * parser/Parser.h: (JSC::Parser::canRecurse): * runtime/CommonSlowPaths.h: * runtime/Completion.cpp: (JSC::evaluate): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::releaseExecutableMemory): (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::addressOfJSStackLimit): (JSC::VM::jsStackLimit): (JSC::VM::setJSStackLimit): (JSC::VM::stackLimit): (JSC::VM::setStackLimit): (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: Added. (JSC::VMEntryScope::VMEntryScope): (JSC::VMEntryScope::~VMEntryScope): (JSC::VMEntryScope::requiredCapacity): * runtime/VMEntryScope.h: Added. (JSC::VMEntryScope::globalObject): * runtime/VMStackBounds.h: Removed. 2013-11-20 Michael Saboff [Win] JavaScript JIT crash (with DFG enabled). https://bugs.webkit.org/show_bug.cgi?id=124675 Reviewed by Geoffrey Garen. Similar to the change in r159427, changed linkClosureCall to use regT0/regT1 (payload/tag) for the callee. linkForThunkGenerator already expected the callee in regT0/regT1, but changed the comment to reflect that. * jit/Repatch.cpp: (JSC::linkClosureCall): * jit/ThunkGenerators.cpp: (JSC::linkForThunkGenerator): 2013-11-20 Michael Saboff ARMv7: Crash due to use after free of AssemblerBuffer https://bugs.webkit.org/show_bug.cgi?id=124611 Reviewed by Geoffrey Garen. Changed JITFinalizer constructor to take a MacroAssemblerCodePtr instead of a Label. In finalizeFunction(), we use that value instead of calculating it from the label. * assembler/MacroAssembler.cpp: * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::JITFinalizer): (JSC::DFG::JITFinalizer::finalizeFunction): * dfg/DFGJITFinalizer.h: 2013-11-20 Julien Brianceau Fix CPU(ARM_TRADITIONAL) build after r159545. https://bugs.webkit.org/show_bug.cgi?id=124649 Reviewed by Michael Saboff. Add missing memoryFence, load8 and store8 implementations in macro assembler. * assembler/ARMAssembler.h: (JSC::ARMAssembler::dmbSY): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::load8): (JSC::MacroAssemblerARM::store8): (JSC::MacroAssemblerARM::memoryFence): 2013-11-20 Julien Brianceau [armv7][arm64] Speculative build fix after r159545. https://bugs.webkit.org/show_bug.cgi?id=124646 Reviewed by Filip Pizlo. * assembler/ARMv7Assembler.h: * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::memoryFence): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::memoryFence): 2013-11-19 Ryosuke Niwa Enable HTMLTemplateElement on Mac port https://bugs.webkit.org/show_bug.cgi?id=124637 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2013-11-19 Filip Pizlo Unreviewed, remove completely bogus assertion. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): 2013-11-19 Filip Pizlo Unreviewed, debug build fix. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): 2013-11-19 Filip Pizlo Infer constant global variables https://bugs.webkit.org/show_bug.cgi?id=124464 Reviewed by Sam Weinig. All global variables that are candidates for watchpoint-based constant inference (i.e. not 'const' variables) will now have WatchpointSet's associated with them and those are used to drive the inference by tracking three states of each variable: Uninitialized: the variable's value is Undefined and the WatchpointSet state is ClearWatchpoint. Initialized: the variable's value was set to something (could even be explicitly set to Undefined) and the WatchpointSet state is IsWatching. Invalidated: the variable's value was set to something else (could even be the same thing as before but the point is that a put operation did execute again) and the WatchpointSet is IsInvalidated. If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is IsWatching, then the current value of the variable can be folded in place of the get, and a watchpoint on the variable can be registered. We handle race conditions between the mutator and compiler by mandating that: - The mutator changes the WatchpointSet state after executing the put. - There is no opportunity to install code or call functions between when the mutator executes a put and changes the WatchpointSet state. - The compiler checks the WatchpointSet state prior to reading the value. The concrete algorithm used by the mutator is: 1. Store the new value into the variable. --- Execute a store-store fence. 2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes IsInvalidated); the IsWatching->IsInvalidated transition may end up firing watchpoints. The concrete algorithm that the compiler uses is: 1. Load the state. If it's *not* IsWatching, then give up on constant inference. --- Execute a load-load fence. 2. Load the value of the variable and use that for folding, while also registering a DesiredWatchpoint. The various parts of this step can be done in any order. The desired watchpoint registration will fail if the watchpoint set is already invalidated. Now consider the following interesting interleavings: Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store operation, and the variable is folded. The fencing ensures that C2 sees the value stored in M1 - i.e. we fold on the value that will actually be watchpointed. If before the compilation is installed the mutator executes another store then we will be sure that it will be a complete sequence of M1+M2 since compilations get installed at safepoints and never "in the middle" of a put_to_scope. Hence that compilation installation will be invalidated. If the M1+M2 sequence happens after the code is installed, then the code will be invalidated by triggering a jettison. Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is a sensible outcome since if the compiler read the variable's value, it would have seen Undefined. Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold. Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold. Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold. Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold. IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold. IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired watchpoint, and that watchpoint will get invalidated before the code is installed. IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated. IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated. IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated. IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated. Note that this kind of reasoning shows why having the mutator first bump the state and then store the new value would be wrong. If we had done that (M1 = bump state, M2 = execute put) then we could have the following deadly interleavings: Uninitialized->M1->C1->C2->M2: Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a value other than Undefined, and you're toast. You could fix this sort of thing by making the Desired Watchpoints machinery more sophisticated, for example having it track the value that was folded; if the global variable's value was later found to be different then we could invalidate the compilation. You could also fix it by having the compiler also check that the value of the variable is not Undefined before folding. While those all sound great, I decided to instead just use the right interleaving since that results in less code and feels more intuitive. This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic. It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is because 3d-cube takes global variable assignment slow paths very often. Note that this 3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS programming often leads to global-var-based idioms and those variables tend to be assigned once, leading to excellent constant folding opportunities in an optimizing JIT. This is very evident in the speed-ups on JSRegress. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::dmbSY): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::dmbSY): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::memfence): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::load8): (JSC::MacroAssemblerARMv7::memfence): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::load8): (JSC::MacroAssemblerX86::store8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::getUnusedRegister): (JSC::MacroAssemblerX86Common::store8): (JSC::MacroAssemblerX86Common::memoryFence): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::load8): (JSC::MacroAssemblerX86_64::store8): * assembler/X86Assembler.h: (JSC::X86Assembler::movb_rm): (JSC::X86Assembler::movzbl_mr): (JSC::X86Assembler::mfence): (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::WatchpointSet): (JSC::WatchpointSet::add): (JSC::WatchpointSet::notifyWriteSlow): * bytecode/Watchpoint.h: (JSC::WatchpointSet::state): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::addressOfSetIsNotEmpty): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getJSConstantForValue): (JSC::DFG::ByteCodeParser::getJSConstant): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::isStronglyProvedConstantIn): (JSC::DFG::Node::hasIdentifierNumberForCheck): (JSC::DFG::Node::hasRegisterPointer): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNotifyPutGlobalVar): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbbreviatedTypes.h: * ftl/FTLAbbreviations.h: (JSC::FTL::buildFence): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar): * ftl/FTLOutput.h: (JSC::FTL::Output::fence): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * llvm/LLVMAPIFunctions.h: * offlineasm/arm.rb: * offlineasm/arm64.rb: * offlineasm/cloop.rb: * offlineasm/instructions.rb: * offlineasm/x86.rb: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addFunction): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::addVar): (JSC::JSGlobalObject::addConst): * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::couldBeWatched): (JSC::SymbolTableEntry::prepareToWatch): (JSC::SymbolTableEntry::notifyWriteSlow): * runtime/SymbolTable.h: 2013-11-19 Michael Saboff REGRESSION(158384) ARMv7 point checks too restrictive for native calls to traditional ARM code https://bugs.webkit.org/show_bug.cgi?id=124612 Reviewed by Geoffrey Garen. Removed ASSERT checks (i.e. lower bit set) for ARM Thumb2 destination addresses related to calls since we are calling native ARM traditional functions like sin() and cos(). * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::linkCall): (JSC::ARMv7Assembler::relinkCall): * assembler/MacroAssemblerCodeRef.h: 2013-11-19 Commit Queue Unreviewed, rolling out r159459. http://trac.webkit.org/changeset/159459 https://bugs.webkit.org/show_bug.cgi?id=124616 tons of assertions on launch (Requested by thorton on #webkit). * API/JSContext.mm: (-[JSContext setException:]): (-[JSContext wrapperForObjCObject:]): (-[JSContext wrapperForJSObject:]): * API/JSContextRef.cpp: (JSContextGroupRelease): (JSGlobalContextRelease): * API/JSManagedValue.mm: (-[JSManagedValue initWithValue:]): (-[JSManagedValue value]): * API/JSObjectRef.cpp: (JSObjectIsFunction): (JSObjectCopyPropertyNames): * API/JSValue.mm: (containerValueToObject): * API/JSWrapperMap.mm: (tryUnwrapObjcObject): 2013-11-19 Filip Pizlo Rename WatchpointSet::notifyWrite() should be renamed to WatchpointSet::fireAll() https://bugs.webkit.org/show_bug.cgi?id=124609 Rubber stamped by Mark Lam. notifyWrite() is a thing that SymbolTable does. WatchpointSet uses that terminology because it was original designed to match exactly SymbolTable's semantics. But now it's a confusing term. * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::fireAllSlow): * bytecode/Watchpoint.h: (JSC::WatchpointSet::fireAll): (JSC::InlineWatchpointSet::fireAll): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): * runtime/Structure.h: (JSC::Structure::notifyTransitionFromThisStructure): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::notifyWriteSlow): 2013-11-18 Michael Saboff REGRESSION (r159395): Error compiling for ARMv7 https://bugs.webkit.org/show_bug.cgi?id=124552 Reviewed by Geoffrey Garen. Fixed the implementation of branch8(RelationalCondition cond, AbsoluteAddress address, TrustedImm32 right) to materialize and use address similar to other ARMv7 branchXX() functions. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branch8): 2013-11-19 Mark Lam Add tracking of endColumn for Executables. https://bugs.webkit.org/show_bug.cgi?id=124245. Reviewed by Geoffrey Garen. 1. Fixed computation of columns to take into account the startColumn from