2012-09-11 Mark Hahnenberg IncrementalSweeper should not sweep/free Zapped blocks https://bugs.webkit.org/show_bug.cgi?id=96464 Reviewed by Filip Pizlo. This is not beneficial in terms of performance because there isn't any way a block can emerge in the Zapped state from a call to Heap::collect() unless we run an eager sweep on it, in which case we've already run all the destructors we possibly can. This also causes bugs since we don't take zapped-ness into account when determining whether or not a block is empty to free it. The incremental sweeper can then accidentally free blocks that it thinks are empty but are in fact zapped with still-live objects in them. * heap/MarkedBlock.h: (JSC::MarkedBlock::needsSweeping): It is only valid to sweep a block if it is in the Marked state. 2013-03-11 Oliver Hunt Make SegmentedVector Noncopyable https://bugs.webkit.org/show_bug.cgi?id=112059 Reviewed by Geoffrey Garen. Copying a SegmentedVector is very expensive, and really shouldn't be necessary. So I've taken the one place where we currently copy and replaced it with a regular Vector, and replaced the address dependent logic with a indexing ref instead. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::newLabelScope): (JSC::BytecodeGenerator::emitComplexJumpScopes): * bytecompiler/BytecodeGenerator.h: (BytecodeGenerator): * bytecompiler/LabelScope.h: (JSC): (JSC::LabelScopePtr::LabelScopePtr): (LabelScopePtr): (JSC::LabelScopePtr::operator=): (JSC::LabelScopePtr::~LabelScopePtr): (JSC::LabelScopePtr::operator*): (JSC::LabelScopePtr::operator->): * bytecompiler/NodesCodegen.cpp: (JSC::DoWhileNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::SwitchNode::emitBytecode): (JSC::LabelNode::emitBytecode): 2012-11-20 Yong Li [ARMv7] Neither linkCall() nor linkPointer() should flush code. https://bugs.webkit.org/show_bug.cgi?id=99213 Reviewed by George Staikos. LinkBuffer doesn't need to flush code during linking. It will eventually flush the whole executable. Fixing this gives >%5 sunspider boost (on QNX). Also make replaceWithLoad() and replaceWithAddressComputation() flush only when necessary. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::linkCall): (JSC::ARMv7Assembler::linkPointer): (JSC::ARMv7Assembler::relinkCall): (JSC::ARMv7Assembler::repatchInt32): (JSC::ARMv7Assembler::repatchPointer): (JSC::ARMv7Assembler::replaceWithLoad): Flush only after it did write. (JSC::ARMv7Assembler::replaceWithAddressComputation): Flush only after it did write. (JSC::ARMv7Assembler::setInt32): (JSC::ARMv7Assembler::setPointer): 2012-08-30 Byungwoo Lee Build warning : -Wsign-compare on DFGByteCodeParser.cpp. https://bugs.webkit.org/show_bug.cgi?id=95418 Reviewed by Filip Pizlo. There is a build warning '-Wsign-compare' on findArgumentPositionForLocal() in DFGByteCodeParser.cpp. For removing this warning, casting statement is added explicitly. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::findArgumentPosition): 2012-11-13 Cosmin Truta Uninitialized fields in class JSLock https://bugs.webkit.org/show_bug.cgi?id=101695 Reviewed by Mark Hahnenberg. Initialize JSLock::m_ownerThread and JSLock::m_lockDropDepth. * runtime/JSLock.cpp: (JSC::JSLock::JSLock): 2012-09-17 Filip Pizlo Unreviewed, fix a broken assertion in offlineasm. * offlineasm/armv7.rb: * offlineasm/backends.rb: 2012-09-10 Thiago Marcos P. Santos [CMake][EFL] Enable the LLInt https://bugs.webkit.org/show_bug.cgi?id=92682 Reviewed by Csaba Osztrogonác. Generate the headers needed by LLint when LLint is enabled. * CMakeLists.txt: 2012-09-09 Mark Lam Fixed a few llint C++ interpreter bugs. https://bugs.webkit.org/show_bug.cgi?id=96127. Reviewed by Geoffrey Garen. * llint/LLIntCLoop.h: CLoop::execute()'s bootstrapOpcodeId does not need a default value. There is no case when this function is called without that parameter being specified. * llint/LowLevelInterpreter.asm: Moved the dispatchAfterCall() call to where it is needed. For the C_LOOP back-end, it generates unreachable code. * llint/LowLevelInterpreter.cpp: #include because LLIntAssembly.h needs it. (JSC): Fixed bug in SIGN_BIT32() macro. Placate a MSVC warning for t0, and t1 being uninitialized. (JSC::CLoop::execute): The bootstrapOpcodeId arg should always be specified. MSVC doesn't like UNUSED_PARAM() for labels. Switch to using the new UNUSED_LABEL() macro. * offlineasm/cloop.rb: * offlineasm/generate_offset_extractor.rb: Resolved a compiler warning found via MSVC. 2012-09-07 Sheriff Bot Unreviewed, rolling out r127938. http://trac.webkit.org/changeset/127938 https://bugs.webkit.org/show_bug.cgi?id=96166 It broke the build (Requested by smfr on #webkit). * llint/LowLevelInterpreter.cpp: (JSC): (JSC::CLoop::execute): * offlineasm/cloop.rb: 2012-09-07 Mark Lam Fix a llint C++ interpreter bugs. https://bugs.webkit.org/show_bug.cgi?id=96127. Reviewed by Filip Pizlo. * llint/LowLevelInterpreter.cpp: (JSC): (JSC::CLoop::execute): * offlineasm/cloop.rb: 2012-09-01 Mark Lam LLInt C loop backend. https://bugs.webkit.org/show_bug.cgi?id=91052. Reviewed by Filip Pizlo. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): (JSC::CodeBlock::bytecodeOffset): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC): * interpreter/Interpreter.h: * jit/JITStubs.h: (JITStackFrame): (JSC): * llint/LLIntCLoop.cpp: Added. (JSC): (LLInt): (JSC::LLInt::CLoop::initialize): (JSC::LLInt::CLoop::catchRoutineFor): (JSC::LLInt::CLoop::hostCodeEntryFor): (JSC::LLInt::CLoop::jsCodeEntryWithArityCheckFor): (JSC::LLInt::CLoop::jsCodeEntryFor): * llint/LLIntCLoop.h: Added. (JSC): (LLInt): (CLoop): * llint/LLIntData.cpp: (JSC::LLInt::initialize): * llint/LLIntData.h: (JSC): * llint/LLIntOfflineAsmConfig.h: * llint/LLIntOpcode.h: * llint/LLIntThunks.cpp: (LLInt): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (LLInt): (JSC::LLInt::Ints2Double): (JSC): (JSC::CLoop::execute): * llint/LowLevelInterpreter.h: (JSC): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/asm.rb: * offlineasm/backends.rb: * offlineasm/cloop.rb: Added. * offlineasm/instructions.rb: * runtime/Executable.h: (ExecutableBase): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::ExecutableBase::catchRoutineFor): (NativeExecutable): * runtime/JSValue.h: (JSC): (LLInt): (JSValue): * runtime/JSValueInlineMethods.h: (JSC): (JSC::JSValue::JSValue): * runtime/Options.cpp: (JSC::Options::initialize): 2012-08-31 Mark Lam Refactor LLInt and supporting code in preparation for the C Loop backend. https://bugs.webkit.org/show_bug.cgi?id=95531. Reviewed by Filip Pizlo. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * jit/JITExceptions.cpp: (JSC::genericThrow): Use ExecutableBase::catchRoutineFor() to fetch fetch the catch routine for a thrown exception. This will allow us to redefine that for the C loop later, and still keep this code readable. * llint/LLIntOfflineAsmConfig.h: Moved ASM macros to LowLevelInterpreter.cpp which is the only place they are used. This will make it more convenient to redefine them for the C loop later. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setUpCall): Use ExecutableBase's hostCodeEntry() jsCodeEntryFor(), and jsCodeWithArityCheckEntryFor() for computing the entry points to functions being called. * llint/LLIntSlowPaths.h: (SlowPathReturnType): (JSC::LLInt::encodeResult): (LLInt): (JSC::LLInt::decodeResult): Added. Needed by LLInt C Loop later. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/asm.rb: Disambiguate between opcodes and other labels. * offlineasm/config.rb: * runtime/Executable.h: (JSC::ExecutableBase::hostCodeEntryFor): Added. (ExecutableBase): (JSC::ExecutableBase::jsCodeEntryFor): Added. (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): Added. (JSC::ExecutableBase::catchRoutineFor): Added. * runtime/JSValueInlineMethods.h: (JSC): 2012-08-30 Mark Lam Render unto #ifdef's that which belong to them. https://bugs.webkit.org/show_bug.cgi?id=95482. Reviewed by Filip Pizlo. Refining / disambiguating between #ifdefs and adding some. For example, ENABLE(JIT) is conflated with ENABLE(LLINT) in some places. Also, we need to add ENABLE(COMPUTED_GOTO_OPCODES) to indicate that we want interpreted opcodes to use COMPUTED GOTOs apart from ENABLE(LLINT) and ENABLE(COMPUTED_GOTO_CLASSIC_INTERPRETER). Also cleaned up #ifdefs in certain places which were previously incorrect. * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::bytecodeOffset): * bytecode/CodeBlock.h: (CodeBlock): * bytecode/Opcode.h: (JSC::padOpcodeName): * config.h: * dfg/DFGOperations.cpp: * interpreter/AbstractPC.cpp: (JSC::AbstractPC::AbstractPC): * interpreter/CallFrame.h: (ExecState): * interpreter/Interpreter.cpp: (JSC::Interpreter::~Interpreter): (JSC::Interpreter::initialize): (JSC::Interpreter::isOpcode): (JSC::Interpreter::unwindCallFrame): (JSC::getLineNumberForCallFrame): (JSC::getCallerInfo): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::privateExecute): * interpreter/Interpreter.h: (JSC::Interpreter::getOpcode): (JSC::Interpreter::getOpcodeID): (Interpreter): * jit/HostCallReturnValue.h: * jit/JITCode.h: (JITCode): * jit/JITExceptions.cpp: * jit/JITExceptions.h: * jit/JSInterfaceJIT.h: * llint/LLIntData.h: (JSC::LLInt::getOpcode): * llint/LLIntEntrypoints.cpp: (JSC::LLInt::getFunctionEntrypoint): (JSC::LLInt::getEvalEntrypoint): (JSC::LLInt::getProgramEntrypoint): * llint/LLIntOffsetsExtractor.cpp: (JSC::LLIntOffsetsExtractor::dummy): * llint/LLIntSlowPaths.cpp: (LLInt): * runtime/JSGlobalData.cpp: (JSC): 2012-08-23 Christophe Dumez Serialization of JavaScript values does not appear to respect new HTML5 Structured Clone semantics https://bugs.webkit.org/show_bug.cgi?id=65292 Reviewed by Oliver Hunt. Add function to construct a StringObject from a JSValue. Similar functions already exist for NumberObject and BooleanObject for example. Export several symbols so address linking errors in WebCore. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * runtime/BooleanObject.h: (BooleanObject): * runtime/NumberObject.h: (NumberObject): (JSC): * runtime/StringObject.cpp: (JSC::constructString): (JSC): * runtime/StringObject.h: (JSC): 2012-08-30 Mark Lam Fix broken classic intrpreter build. https://bugs.webkit.org/show_bug.cgi?id=95484. Reviewed by Filip Pizlo. * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): 2012-08-29 Mark Lam Refactoring LLInt::Data. https://bugs.webkit.org/show_bug.cgi?id=95316. Reviewed by Geoff Garen. This change allows its opcodeMap to be easily queried from any function without needing to go through a GlobalData object. It also introduces the LLInt::getCodePtr() methods that will be used by the LLInt C loop later to redefine how llint symbols (opcodes and trampoline glue labels) get resolved. * assembler/MacroAssemblerCodeRef.h: (MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createLLIntCodePtr): (MacroAssemblerCodeRef): (JSC::MacroAssemblerCodeRef::createLLIntCodeRef): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::adjustPCIfAtCallSite): (JSC::CodeBlock::bytecodeOffset): * bytecode/Opcode.h: Remove the 'const' to simplify things and avoid having to do additional casts and #ifdefs in many places. * bytecode/ResolveGlobalStatus.cpp: (JSC::computeForLLInt): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * interpreter/Interpreter.cpp: (JSC::Interpreter::initialize): * interpreter/Interpreter.h: (Interpreter): * jit/JITExceptions.cpp: (JSC::genericThrow): * llint/LLIntData.cpp: (LLInt): (JSC::LLInt::initialize): * llint/LLIntData.h: (JSC): (LLInt): (Data): (JSC::LLInt::exceptionInstructions): (JSC::LLInt::opcodeMap): (JSC::LLInt::getOpcode): (JSC::LLInt::getCodePtr): (JSC::LLInt::Data::performAssertions): * llint/LLIntExceptions.cpp: (JSC::LLInt::returnToThrowForThrownException): (JSC::LLInt::returnToThrow): (JSC::LLInt::callToThrow): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::handleHostCall): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): Initialize the singleton LLInt data. * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): * runtime/JSGlobalData.h: (JSGlobalData): Removed the now unneeded LLInt::Data instance in JSGlobalData. * runtime/JSValue.h: (JSValue): 2012-08-24 Filip Pizlo Finally inlining should correctly track the catch context https://bugs.webkit.org/show_bug.cgi?id=94986 Reviewed by Sam Weinig. This fixes two behaviors: 1) Throwing from a finally block. Previously, we would seem to reenter the finally block - though only once. 2) Executing a finally block from some nested context, for example due to a 'continue', 'break', or 'return' in the try. This would execute the finally block in the context of of the try block, which could lead to either scope depth mismatches or reexecutions of the finally block on throw, similarly to (1) but for different reasons. * bytecompiler/BytecodeGenerator.cpp: (JSC): (JSC::BytecodeGenerator::pushFinallyContext): (JSC::BytecodeGenerator::emitComplexJumpScopes): (JSC::BytecodeGenerator::pushTry): (JSC::BytecodeGenerator::popTryAndEmitCatch): * bytecompiler/BytecodeGenerator.h: (FinallyContext): (TryData): (JSC): (TryContext): (TryRange): (BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): 2012-08-28 Mark Lam Adding support for adding LLInt opcode extensions. This will be needed by the LLInt C loop interpreter later. https://bugs.webkit.org/show_bug.cgi?id=95277. Reviewed by Geoffrey Garen. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Opcode.h: * llint/LLIntOpcode.h: Added. * llint/LowLevelInterpreter.h: 2012-08-28 Filip Pizlo LLInt should not rely on ordering of global labels https://bugs.webkit.org/show_bug.cgi?id=95221 Reviewed by Oliver Hunt. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2012-08-20 Mark Lam Fix broken non-JIT build. https://bugs.webkit.org/show_bug.cgi?id=94564. Reviewed by Filip Pizlo. Added some UNUSED_PARAM() macros to make the compiler happy. * runtime/Executable.cpp: (JSC::EvalExecutable::compileInternal): (JSC::ProgramExecutable::compileInternal): (JSC::FunctionExecutable::compileForCallInternal): (JSC::FunctionExecutable::compileForConstructInternal): 2012-08-20 Mark Lam Fixed erroneous line number for LLint frame when throwing exceptions. https://bugs.webkit.org/show_bug.cgi?id=94051. Reviewed by Filip Pizlo. For LLInt frames, before throwing an exception, adjust the PC from the return PC back to the call PC if we are indeed at a call site. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::adjustPCIfAtCallSite): (JSC): (JSC::CodeBlock::bytecodeOffset): * bytecode/CodeBlock.h: (CodeBlock): * llint/LLIntExceptions.cpp: (JSC::LLInt::fixupPCforExceptionIfNeeded): (LLInt): (JSC::LLInt::interpreterThrowInCaller): (JSC::LLInt::returnToThrow): (JSC::LLInt::callToThrow): 2012-08-03 Filip Pizlo Crashes in dfgBuildPutByIdList when clicking on just about anything on Google Maps https://bugs.webkit.org/show_bug.cgi?id=92691 Reviewed by Mark Hahnenberg. The state of the stubs was changing after we determined the type (by virtue of the slow path function that was called), since the get or put (in this case put) could cause arbitrary side effects. Perhaps a full-blown fix would be to eliminate our reliance of the slow path function to determine what to do, but an easier fix for now is to have the slow path give up if its assumptions were invalidated by a side effect. * dfg/DFGOperations.cpp: * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): 2012-08-03 Filip Pizlo DFG handling of get_by_id should always inject a ForceOSRExit node if there is no prediction https://bugs.webkit.org/show_bug.cgi?id=93162 Reviewed by Mark Hahnenberg. This simplifies the DFG IR by ensuring that all nodes that use value profiles will be preceded by a ForceOSRExit if the value profile had no data. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2012-08-03 Filip Pizlo DFG::StructureCheckHoistingPhase keeps a Node& around for too long https://bugs.webkit.org/show_bug.cgi?id=93157 Reviewed by Mark Hahnenberg. * dfg/DFGStructureCheckHoistingPhase.cpp: (JSC::DFG::StructureCheckHoistingPhase::run): 2012-08-02 Filip Pizlo ASSERTION FAILED: at(m_compileIndex).canExit() || m_isCheckingArgumentTypes https://bugs.webkit.org/show_bug.cgi?id=91074 Reviewed by Mark Hahnenberg. Fixes a bug where the speculative JIT was performing an unnecessary speculation that the CFA had proven shouldn't be performed, leading to asserts that a node should not have exit sites. This is a debug-only assert with no release symptom - we were just emitting a check that was not reachable. Also found, and fixed, a bug where structure check hoisting was slightly confusing the CFA by inserting GetLocal's into the graph. CSE would clean the GetLocal's up, which would make the backend happy - but the CFA would produce subtly wrong results. * bytecode/SpeculatedType.h: (JSC::isOtherOrEmptySpeculation): (JSC): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): 2012-08-02 Filip Pizlo Unreviewed, build fix for DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE). * dfg/DFGStructureCheckHoistingPhase.cpp: (JSC::DFG::StructureCheckHoistingPhase::run): 2012-08-01 Mark Hahnenberg Remove all uses of ClassInfo for JSStrings in JIT code https://bugs.webkit.org/show_bug.cgi?id=92935 Reviewed by Geoffrey Garen. This is the first step in removing our dependence on in-object ClassInfo pointers in JIT code. Most of the changes are to check the Structure, which is unique for JSString primitives. * bytecode/SpeculatedType.cpp: (JSC::speculationFromClassInfo): (JSC::speculationFromStructure): Changed to check the TypeInfo in the Structure since there wasn't a JSGlobalData immediately available to grab the JSString Structure out of. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITInlineMethods.h: (JSC::JIT::emitLoadCharacterString): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileCTIMachineTrampolines): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_convert_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTIMachineTrampolines): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::emit_op_convert_this): * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::emitSlow_op_get_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::emitSlow_op_get_by_val): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadJSStringArgument): * jit/ThunkGenerators.cpp: (JSC::stringCharLoad): (JSC::charCodeAtThunkGenerator): (JSC::charAtThunkGenerator): 2012-08-02 Filip Pizlo Unreviewed, missed a style goof in the previous patch: "NodeIndex nodeIndex" in a method signature is painfully redundant. * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): 2012-08-02 Filip Pizlo DFGSpeculativeJIT.h has too many inline method bodies https://bugs.webkit.org/show_bug.cgi?id=92957 Reviewed by Antti Koivisto. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (DFG): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection): (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): 2012-08-01 Filip Pizlo DFG should hoist structure checks https://bugs.webkit.org/show_bug.cgi?id=92696 Reviewed by Gavin Barraclough. This hoists structure checks in the same way that we would hoist array checks, but with added complexity to cope with the fact that the structure of an object may change. This is handled by performing a side effects analysis over the region in which the respective variable is live. If a structure clobbering side effect may happen then we either hoist the structure checks and fall back on structure transition watchpoints (if the watchpoint set is still valid), or we avoid hoisting altogether. Doing this required teaching the CFA that we may have an expectation that an object has a particular structure even after structure clobbering happens, in the sense that structure proofs that were cobbered can be revived using watchpoints. CFA must know about this so that OSR entry may know about it, since we cannot allow entry to happen if the variable has a clobbered structure proof, will have a watchpoint to revive the proof, and the variable in the baseline JIT has a completely unrelated structure. This is mostly performance neutral. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/ValueRecovery.h: (JSC::ValueRecovery::isSet): (JSC::ValueRecovery::operator!): (ValueRecovery): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::clobberWorld): (DFG): (JSC::DFG::AbstractState::clobberCapturedVars): * dfg/DFGAbstractState.h: (AbstractState): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::clear): (JSC::DFG::AbstractValue::isClear): (JSC::DFG::AbstractValue::makeTop): (JSC::DFG::AbstractValue::isTop): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::operator==): (JSC::DFG::AbstractValue::merge): (JSC::DFG::AbstractValue::filter): (JSC::DFG::AbstractValue::validate): (JSC::DFG::AbstractValue::validateForEntry): (AbstractValue): (JSC::DFG::AbstractValue::checkConsistency): (JSC::DFG::AbstractValue::dump): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::getArgument): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::checkStructureLoadElimination): (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): (JSC::DFG::CSEPhase::putStructureStoreElimination): (JSC::DFG::CSEPhase::getLocalLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::vote): (Graph): * dfg/DFGNode.h: (JSC::DFG::Node::convertToStructureTransitionWatchpoint): (Node): (JSC::DFG::Node::hasStructureSet): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): (PredictionPropagationPhase): (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection): (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): (JSC::DFG::SpeculateCellOperand::gpr): (SpeculateCellOperand): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStructureCheckHoistingPhase.cpp: Added. (DFG): (StructureCheckHoistingPhase): (JSC::DFG::StructureCheckHoistingPhase::StructureCheckHoistingPhase): (JSC::DFG::StructureCheckHoistingPhase::run): (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): (JSC::DFG::StructureCheckHoistingPhase::clobber): (CheckData): (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData): (JSC::DFG::performStructureCheckHoisting): * dfg/DFGStructureCheckHoistingPhase.h: Added. (DFG): * dfg/DFGVariableAccessData.h: (VariableAccessData): (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::mergeStructureCheckHoistingFailed): (JSC::DFG::VariableAccessData::structureCheckHoistingFailed): (JSC::DFG::VariableAccessData::clearVotes): (JSC::DFG::VariableAccessData::vote): (JSC::DFG::VariableAccessData::voteRatio): (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): * runtime/Options.h: (JSC): 2012-08-01 Filip Pizlo DFG should distinguish between PutByVal's that clobber the world and ones that don't https://bugs.webkit.org/show_bug.cgi?id=92923 Reviewed by Mark Hahnenberg. This is performance-neutral. I also confirmed that it's neutral if we make the clobbering variant (PutByValSafe) clobber all knowledge of what is an array, which should feed nicely into work on removing uses of ClassInfo. * bytecode/DFGExitProfile.h: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::checkStructureLoadElimination): (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): (JSC::DFG::CSEPhase::getByOffsetLoadElimination): (JSC::DFG::CSEPhase::putByOffsetStoreElimination): (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::byValIsPure): (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-08-01 Mark Hahnenberg C++ code should get ClassInfo from the Structure https://bugs.webkit.org/show_bug.cgi?id=92892 Reviewed by Geoffrey Garen. In our march to remove ClassInfo from our JSCell object headers, we can switch C++ code over to grabbing the ClassInfo from the Structure since it is finally safe to do so now that Structure access is safe during finalization/destruction. The remaining JIT code changes can be done in a separate patch. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::callDestructor): We don't want to clear the Structure any more since the Structure should still be valid at this point. * heap/WeakSetInlines.h: (JSC::WeakBlock::finalize): Ditto. * runtime/JSCell.h: (JSC): * runtime/Structure.h: (JSC::JSCell::classInfo): Move JSCell's classInfo() to Structure.h so it can be inline. Use a different method of getting the JSCell's Structure based on whether we're in GC_VALIDATION mode or not, since always using get() will cause infinite recursion in GC_VALIDATION mode. (JSC): 2012-07-31 Mark Hahnenberg MarkedBlock::sweep() should sweep another block if it can't sweep a Structure block https://bugs.webkit.org/show_bug.cgi?id=92819 Reviewed by Geoffrey Garen. If we are forced to allocate a new block for Structures because we are unable to safely sweep our pre-existing Structure blocks, we should sweep another random block so that we can start sweeping Structure blocks sooner. * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): Change to use sweepNextBlock. (JSC): (JSC::IncrementalSweeper::sweepNextBlock): * heap/IncrementalSweeper.h: (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): When we can't safely sweep our Structure blocks, call sweepNextBlock instead. 2012-07-31 Sam Weinig Fix the Windows build. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: 2012-07-31 Geoffrey Garen Maybe fix the GCC build. * heap/HeapBlock.h: (HeapBlock): Accommodate incorrect parsing in GCC. 2012-07-31 Geoffrey Garen Maybe break the Windows build. Reviewed by Anders Carlsson. Formally objected to by Sam Weinig. * heap/HeapBlock.h: (HeapBlock): Try to slightly improve this because we don't want Windows to control our lives. 2012-07-30 Mark Hahnenberg Structures should be swept after all other objects https://bugs.webkit.org/show_bug.cgi?id=92679 Reviewed by Filip Pizlo. In order to get rid of ClassInfo from our objects, we need to be able to safely get the ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the Structure, but currently it is not safe to do so because the order of destruction of objects is not guaranteed to sweep objects before their corresponding Structure. We can fix this by sweeping Structures after everything else. * heap/Heap.cpp: (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures. If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is safe to sweep structures since we'll always do Structures last anyways due to the ordering of MarkedSpace::forEachBlock. (JSC): (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() calls during lastChanceToFinalize(). * heap/Heap.h: (Heap): * heap/HeapTimer.h: (HeapTimer): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures. This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping the first time. (JSC): (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we make our first pass. We now null out the slots as we sweep them so that we can quickly find the Structures during the second pass. (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index. (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds. (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index. * heap/IncrementalSweeper.h: Add declarations for new stuff. (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that will sweep some number of other blocks in place of the current block to mitigate the cost of the floating Structure garbage. (JSC::MarkedAllocator::addBlock): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no longer valid to allocate from, so we set the current block to null. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures at an unsafe time. * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping. (JSC): * heap/MarkedSpace.h: (JSC): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown. 2012-07-31 Geoffrey Garen Fix all the other builds I just broke. Maybe fix the Windows build. * heap/HeapBlock.h: (HeapBlock): WTF? 2012-07-31 Geoffrey Garen Maybe fix the Windows build. * heap/HeapBlock.h: (HeapBlock): WTF? 2012-07-31 Geoffrey Garen Maybe fix the Windows build. * heap/HeapBlock.h: (HeapBlock): WTF? 2012-07-31 Geoffrey Garen Removed some public data and casting from the Heap https://bugs.webkit.org/show_bug.cgi?id=92777 Reviewed by Oliver Hunt. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::releaseFreeBlocks): (JSC::BlockAllocator::blockFreeingThreadMain): Use the DeadBlock class since HeapBlock is a template, and not a class, now. Call destroy() instead of monkeying around with DeadBlock's internal data because encapsulation is good. * heap/BlockAllocator.h: (DeadBlock): Added a class to represent a dead block, since HeapBlock is a template now, and can't be instantiated directly. (JSC::DeadBlock::DeadBlock): (JSC::DeadBlock::create): (BlockAllocator): (JSC::BlockAllocator::allocate): (JSC::BlockAllocator::deallocate): Use the DeadBlock class because encapsulation is good. * heap/CopiedBlock.h: (CopiedBlock::destroy): No need for a destroy() function, since we inherit one now. (JSC::CopiedBlock::CopiedBlock): (JSC::CopiedBlock::payloadEnd): (JSC::CopiedBlock::capacity): Updated for some encapsulation inside HeapBlock. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::~CopiedSpace): (JSC::CopiedSpace::doneCopying): (JSC::CopiedSpace::size): (JSC::CopiedSpace::capacity): (JSC::isBlockListPagedOut): Removed a bunch of casting. This is no longer necessary, now that our list and its nodes have the right type. * heap/CopiedSpace.h: Use the right type in our data structures because it improves clarity. * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::startedCopying): Use swap to avoid duplicating it. * heap/HeapBlock.h: (HeapBlock): Made this a class template so we can return the right type in linked list operations. Made our data private because encapsulation is good. (JSC::HeapBlock::destroy): Since we know our type, we can also eliminate duplicate destroy() functions in our subclasses. (JSC::HeapBlock::allocation): Added an accessor so we can hide our data. By using const, this accessor prevents clients from accidentally deleting our allocation. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::removeBlock): Removed a bunch of casting. This is no longer necessary, now that our list and its nodes have the right type. * heap/MarkedAllocator.h: (MarkedAllocator): (JSC::MarkedAllocator::reset): (JSC::MarkedAllocator::forEachBlock): Use the right type, do less casting. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::destroy): Removed this function because our parent class provides it for us now. (JSC::MarkedBlock::MarkedBlock): * heap/MarkedBlock.h: (MarkedBlock): (JSC::MarkedBlock::capacity): Updated for encapsulation. 2012-07-31 Filip Pizlo DFG OSR exit profiling has unusual oversights https://bugs.webkit.org/show_bug.cgi?id=92728 Reviewed by Geoffrey Garen. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::speculationWatchpoint): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-07-31 Chao-ying Fu Add MIPS add32 function https://bugs.webkit.org/show_bug.cgi?id=91522 Reviewed by Oliver Hunt. Add isCompactPtrAlignedAddressOffset. Add a new version of add32 that accepts AbsoluteAddress as inputs. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::isCompactPtrAlignedAddressOffset): New. (MacroAssemblerMIPS): (JSC::MacroAssemblerMIPS::add32): Support AbsoluteAddress as inputs. 2012-07-30 Sheriff Bot Unreviewed, rolling out r124123. http://trac.webkit.org/changeset/124123 https://bugs.webkit.org/show_bug.cgi?id=92700 ASSERT crashes terminate webkit Layout tests (Requested by msaboff on #webkit). * heap/Heap.cpp: * heap/Heap.h: (Heap): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): (JSC::IncrementalSweeper::startSweeping): (JSC::IncrementalSweeper::IncrementalSweeper): (JSC): * heap/IncrementalSweeper.h: (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::zapFreeList): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweepHelper): * heap/MarkedSpace.cpp: * heap/MarkedSpace.h: (JSC::MarkedSpace::sweep): (JSC): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::~JSGlobalData): 2012-07-30 Mark Hahnenberg Structures should be swept after all other objects https://bugs.webkit.org/show_bug.cgi?id=92679 Reviewed by Filip Pizlo. In order to get rid of ClassInfo from our objects, we need to be able to safely get the ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the Structure, but currently it is not safe to do so because the order of destruction of objects is not guaranteed to sweep objects before their corresponding Structure. We can fix this by sweeping Structures after everything else. * heap/Heap.cpp: (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures. If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is safe to sweep structures since we'll always do Structures last anyways due to the ordering of MarkedSpace::forEachBlock. (JSC): (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() calls during lastChanceToFinalize(). * heap/Heap.h: (Heap): * heap/HeapTimer.h: (HeapTimer): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures. This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping the first time. (JSC): (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we make our first pass. We now null out the slots as we sweep them so that we can quickly find the Structures during the second pass. (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index. (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds. (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index. * heap/IncrementalSweeper.h: Add declarations for new stuff. (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that will sweep some number of other blocks in place of the current block to mitigate the cost of the floating Structure garbage. (JSC::MarkedAllocator::addBlock): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no longer valid to allocate from, so we set the current block to null. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures at an unsafe time. * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping. (JSC): * heap/MarkedSpace.h: (JSC): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown. 2012-07-29 Filip Pizlo PropertyNameArray::m_shouldCache is only assigned and never used https://bugs.webkit.org/show_bug.cgi?id=92598 Reviewed by Dan Bernstein. * runtime/PropertyNameArray.h: (JSC::PropertyNameArray::PropertyNameArray): (PropertyNameArray): 2012-07-29 Rik Cabanier Add ENABLE_CSS_COMPOSITING flag https://bugs.webkit.org/show_bug.cgi?id=92553 Reviewed by Dirk Schulze. Adds compiler flag CSS_COMPOSITING to build systems to enable CSS blending and compositing. See spec https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html * Configurations/FeatureDefines.xcconfig: 2012-07-27 Mark Hahnenberg Split functionality of MarkedAllocator::m_currentBlock https://bugs.webkit.org/show_bug.cgi?id=92550 Reviewed by Filip Pizlo. MarkedAllocator::m_currentBlock serves two purposes right now; it indicates the block that is currently being used for allocation and the beginning of the list of blocks that need to be swept. We should split these two functionalities into two separate fields. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): Use m_blocksToSweep instead of m_currentBlock as the initializer/reference of the loop. Only change m_currentBlock when we know what the result will be. (JSC::MarkedAllocator::addBlock): When we add a new block we know that both m_blocksToSweep and m_currentBlock are null. In order to preserve the invariant that m_currentBlock <= m_blocksToSweep, we assign both of them to point to the new block. (JSC::MarkedAllocator::removeBlock): We need a separate check to see if the block we're removing is m_blocksToSweep and if so, advance it to the next block in the list. * heap/MarkedAllocator.h: (MarkedAllocator): Initialize m_blocksToSweep. (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::reset): We set m_blocksToSweep to be the head of our list. This function is called at the end of a collection, so all of the blocks in our allocator need to be swept. We need to sweep a block before we can start allocating, so m_currentBlock is set to null. We also set the freeList to the empty FreeList to emphasize the fact that we can't start allocating until we do some sweeping. 2012-07-27 Mark Hahnenberg Increase inline storage for JSFinalObjects by one https://bugs.webkit.org/show_bug.cgi?id=92526 Reviewed by Geoffrey Garen. Now that we've removed the inheritorID from objects, we can increase our inline storage for JSFinalObjects on 64-bit platforms by 1. * llint/LowLevelInterpreter.asm: Change the constant. * runtime/PropertyOffset.h: Change the constant. (JSC): 2012-07-27 Jer Noble Support a rational time class for use by media elements. https://bugs.webkit.org/show_bug.cgi?id=88787 Re-export WTF::MediaTime from JavaScriptCore. Reviewed by Eric Carlson. * JavaScriptCore.order: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: 2012-07-26 Filip Pizlo JSObject::reallocateStorageIfNecessary is neither used nor defined https://bugs.webkit.org/show_bug.cgi?id=92417 Reviewed by Mark Rowe. * runtime/JSObject.h: (JSObject): 2012-07-26 Mark Hahnenberg Allocate Structures in a separate part of the Heap https://bugs.webkit.org/show_bug.cgi?id=92420 Reviewed by Filip Pizlo. To fix our issue with destruction/finalization of Structures before their objects, we can move Structures to a separate part of the Heap that will be swept after all other objects. This first patch will just be separating Structures out into their own separate MarkedAllocator. Everything else will behave identically. * heap/Heap.h: New function to allocate Structures in the Heap. (Heap): (JSC): (JSC::Heap::allocateStructure): * heap/MarkedAllocator.cpp: Pass whether or not we're allocated Structures to the MarkedBlock. (JSC::MarkedAllocator::allocateBlock): * heap/MarkedAllocator.h: Add tracking for whether or not we're allocating only Structures. (JSC::MarkedAllocator::onlyContainsStructures): (MarkedAllocator): (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::init): * heap/MarkedBlock.cpp: Add tracking for whether or not we're allocating only Structures. We need this to be able to distinguish the various MarkedBlock types in MarkedSpace::allocatorFor(MarkedBlock*). (JSC::MarkedBlock::create): (JSC::MarkedBlock::MarkedBlock): * heap/MarkedBlock.h: (MarkedBlock): (JSC::MarkedBlock::onlyContainsStructures): (JSC): * heap/MarkedSpace.cpp: Include the new Structure allocator in all the places that all the other allocators are used/modified. (JSC::MarkedSpace::MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::canonicalizeCellLivenessData): (JSC::MarkedSpace::isPagedOut): * heap/MarkedSpace.h: Add new MarkedAllocator just for Structures. (MarkedSpace): (JSC::MarkedSpace::allocatorFor): (JSC::MarkedSpace::allocateStructure): (JSC): (JSC::MarkedSpace::forEachBlock): * runtime/Structure.h: Move all of the functions that call allocateCell down below the explicit template specialization for allocateCell. The new inline specialization for allocateCell directly calls the allocateStructure() function in the Heap. (Structure): (JSC::Structure): (JSC): (JSC::Structure::create): (JSC::Structure::createStructure): 2012-07-26 Filip Pizlo JSArray has methods that are neither used nor defined https://bugs.webkit.org/show_bug.cgi?id=92416 Reviewed by Simon Fraser. * runtime/JSArray.h: (JSArray): 2012-07-26 Zoltan Herczeg [Qt][ARM]ARMAssembler needs buildfix afert r123417 https://bugs.webkit.org/show_bug.cgi?id=92086 Reviewed by Csaba Osztrogonác. The ARM implementation of this should be optimized code path is covered by a non-optimized code path. This patch fixes this, and adds a new function which returns with the offset range. * assembler/ARMAssembler.h: (JSC::ARMAssembler::readPointer): (ARMAssembler): (JSC::ARMAssembler::repatchInt32): (JSC::ARMAssembler::repatchCompact): * assembler/MacroAssemblerARM.h: (MacroAssemblerARM): (JSC::MacroAssemblerARM::isCompactPtrAlignedAddressOffset): (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch): 2012-07-25 Mark Hahnenberg Build fix for 32-bit after r123682 * runtime/JSObject.h: Need to pad out JSObjects on 32-bit so that they're the correct size since we only removed one 4-byte word and we need to be 8-byte aligned. (JSObject): 2012-07-25 Filip Pizlo JSC GC object copying APIs should allow for greater flexibility https://bugs.webkit.org/show_bug.cgi?id=92316 Reviewed by Mark Hahnenberg. It's now the case that visitChildren() methods can directly pin and allocate in new space during copying. They can also do the copying and marking themselves. This new API is only used for JSObjects for now. * JavaScriptCore.xcodeproj/project.pbxproj: * heap/MarkStack.cpp: (JSC::SlotVisitor::allocateNewSpaceSlow): (JSC::SlotVisitor::allocateNewSpaceOrPin): (JSC): (JSC::SlotVisitor::copyAndAppend): * heap/MarkStack.h: (MarkStack): (JSC::MarkStack::appendUnbarrieredValue): (JSC): * heap/SlotVisitor.h: * heap/SlotVisitorInlineMethods.h: Added. (JSC): (JSC::SlotVisitor::checkIfShouldCopyAndPinOtherwise): (JSC::SlotVisitor::allocateNewSpace): * runtime/JSObject.cpp: (JSC::JSObject::visitOutOfLineStorage): (JSC): (JSC::JSObject::visitChildren): (JSC::JSFinalObject::visitChildren): * runtime/JSObject.h: (JSObject): 2012-07-25 Mark Hahnenberg Remove JSObject::m_inheritorID https://bugs.webkit.org/show_bug.cgi?id=88378 Reviewed by Filip Pizlo. This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). Instead use a private named value in the object's property storage. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): No need m_inheritorID to initialize! * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): No need m_inheritorID to initialize! * llint/LowLevelInterpreter.asm: No need m_inheritorID to initialize! * runtime/JSGlobalData.h: (JSGlobalData): Added private name 'm_inheritorIDKey'. * runtime/JSGlobalThis.cpp: (JSC::JSGlobalThis::setUnwrappedObject): resetInheritorID is now passed a JSGlobalData&. * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): No m_inheritorID to be marked. (JSC::JSFinalObject::visitChildren): No m_inheritorID to be marked. (JSC::JSObject::createInheritorID): Store the newly created inheritorID in the property map. Make sure it's got the DontEnum attribute!! * runtime/JSObject.h: (JSObject): (JSC::JSObject::resetInheritorID): Remove the inheritorID from property storage. (JSC): (JSC::JSObject::inheritorID): Read the inheritorID from property storage. 2012-07-25 Caio Marcelo de Oliveira Filho Create a specialized pair for use in HashMap iterators https://bugs.webkit.org/show_bug.cgi?id=92137 Reviewed by Ryosuke Niwa. Update a couple of sites that relied on the fact that "contents" of iterators were std::pairs. * profiler/Profile.cpp: (JSC): This code kept a vector of the pairs that were the "contents" of the iterators. This is changed to use a KeyValuePair. We make use HashCount's ValueType (which represents only the key) to get the proper key parameter for KeyValuePair. * tools/ProfileTreeNode.h: (ProfileTreeNode): Use HashMap::ValueType to declare the type of the contents of the hash instead of declaring it manually. This will make use of the new KeyValuePair. 2012-07-25 Patrick Gansterer REGRESSION(r123505): Date.getYear() returns the same as Date.getFullYear() https://bugs.webkit.org/show_bug.cgi?id=92218 Reviewed by Csaba Osztrogonác. * runtime/DatePrototype.cpp: (JSC::dateProtoFuncGetYear): Added the missing offset of 1900 to the return value. 2012-07-24 Filip Pizlo REGRESSION(r123417): It made tests assert/crash on 32 bit https://bugs.webkit.org/show_bug.cgi?id=92088 Reviewed by Mark Hahnenberg. The pointer arithmetic was wrong, because negative numbers are hard to think about. * dfg/DFGRepatch.cpp: (JSC::DFG::emitPutTransitionStub): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): 2012-07-24 Patrick Gansterer Store the full year in GregorianDateTime https://bugs.webkit.org/show_bug.cgi?id=92067 Reviewed by Geoffrey Garen. Use the full year instead of the offset from year 1900 for the year member variable of GregorianDateTime. * runtime/DateConstructor.cpp: (JSC::constructDate): (JSC::dateUTC): * runtime/DateConversion.cpp: (JSC::formatDate): (JSC::formatDateUTCVariant): * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): (JSC::fillStructuresUsingDateArgs): (JSC::dateProtoFuncToISOString): (JSC::dateProtoFuncGetFullYear): (JSC::dateProtoFuncGetUTCFullYear): (JSC::dateProtoFuncSetYear): * runtime/JSDateMath.cpp: (JSC::gregorianDateTimeToMS): (JSC::msToGregorianDateTime): 2012-07-24 Patrick Gansterer [WIN] Build fix after r123417. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: 2012-07-23 Patrick Gansterer Move GregorianDateTime from JSC to WTF namespace https://bugs.webkit.org/show_bug.cgi?id=91948 Reviewed by Geoffrey Garen. Moving GregorianDateTime into the WTF namespace allows us to us to use it in WebCore too. The new class has the same behaviour as the old struct. Only the unused timeZone member has been removed. * runtime/DateConstructor.cpp: * runtime/DateConversion.cpp: * runtime/DateConversion.h: * runtime/DateInstance.h: * runtime/DatePrototype.cpp: * runtime/JSDateMath.cpp: * runtime/JSDateMath.h: 2012-07-23 Filip Pizlo Property storage should grow in reverse address direction, to support butterflies https://bugs.webkit.org/show_bug.cgi?id=91788 Reviewed by Geoffrey Garen. Changes property storage to grow to the left, and changes the property storage pointer to point one 8-byte word (i.e. JSValue) to the right of the first value in the storage. Also improved debug support somewhat, by adding a describe() function to the jsc command-line, and a slow mode of object access in LLInt. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::repatchCompact): * assembler/MacroAssemblerARMv7.h: (MacroAssemblerARMv7): (JSC::MacroAssemblerARMv7::isCompactPtrAlignedAddressOffset): (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::isCompactPtrAlignedAddressOffset): (JSC::MacroAssemblerX86Common::repatchCompact): * assembler/X86Assembler.h: (JSC::X86Assembler::repatchCompact): * bytecode/CodeBlock.cpp: (JSC::dumpStructure): * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::GetByIdStatus): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGRepatch.cpp: (JSC::DFG::tryCacheGetByID): (JSC::DFG::emitPutTransitionStub): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * heap/ConservativeRoots.cpp: (JSC::ConservativeRoots::genericAddPointer): * heap/CopiedSpace.h: (CopiedSpace): * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::pinIfNecessary): (JSC): * jit/JITPropertyAccess.cpp: (JSC::JIT::compileGetDirectOffset): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::compileGetDirectOffset): * jit/JITStubs.cpp: (JSC::JITThunks::tryCacheGetByID): * jsc.cpp: (GlobalObject::finishCreation): (functionDescribe): * llint/LLIntCommon.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSFinalObject::visitChildren): (JSC::JSObject::growOutOfLineStorage): * runtime/JSObject.h: (JSC::JSObject::getDirectLocation): (JSC::JSObject::offsetForLocation): * runtime/JSValue.h: (JSValue): * runtime/PropertyOffset.h: (JSC::offsetInOutOfLineStorage): 2012-07-23 Filip Pizlo DFG is too aggressive in performing the specific value optimization on loads https://bugs.webkit.org/show_bug.cgi?id=92034 Reviewed by Mark Hahnenberg. This ensures that we don't do optimizations based on a structure having a specific value, if there is no way to detect that the value is despecified. This is the case for dictionaries, since despecifying a value in a dictionary does not lead to a transition and so cannot be caught by either structure checks or structure transition watchpoints. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/ResolveGlobalStatus.cpp: (JSC::computeForStructure): 2012-07-23 Filip Pizlo REGRESSION(r123169): It made fast/js/dfg-inline-arguments-use-from-uninlined-code.html fail on 32 bit platforms https://bugs.webkit.org/show_bug.cgi?id=92002 Reviewed by Mark Hahnenberg. In the process of changing the nature of local variable typing, I forgot to modify one of the places where we glue the DFG's notion of variable prediction to the runtime's notion of variable tagging. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-07-23 Simon Fraser Part 2 of: Implement sticky positioning https://bugs.webkit.org/show_bug.cgi?id=90046 Reviewed by Ojan Vafai. Turn on ENABLE_CSS_STICKY_POSITION. * Configurations/FeatureDefines.xcconfig: 2012-07-23 Patrick Gansterer Move JSC::parseDate() from DateConversion to JSDateMath https://bugs.webkit.org/show_bug.cgi?id=91982 Reviewed by Geoffrey Garen. Moveing this function into the other files removes the dependency on JSC spcific classes in DateConversion.{cpp|h}. * runtime/DateConversion.cpp: * runtime/DateConversion.h: (JSC): * runtime/JSDateMath.cpp: (JSC::parseDate): (JSC): * runtime/JSDateMath.h: (JSC): 2012-07-23 Simon Fraser Part 1 of: Implement sticky positioning https://bugs.webkit.org/show_bug.cgi?id=90046 Reviewed by Ojan Vafai. Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially. Sort the ENABLE_CSS lines in the file. Make sure all the flags are in FEATURE_DEFINES. * Configurations/FeatureDefines.xcconfig: 2012-07-23 Yong Li [BlackBerry] Implement GCActivityCallback with platform timer https://bugs.webkit.org/show_bug.cgi?id=90175 Reviewed by Rob Buis. Use JSLock when performing GC to avoid assertions. * runtime/GCActivityCallbackBlackBerry.cpp: (JSC::DefaultGCActivityCallback::doWork): 2012-07-23 Kent Tamura Rename ENABLE_METER_TAG and ENABLE_PROGRESS_TAG to ENABLE_METER_ELEMENT and ENABLE_PROGRESS_ELEMENT respectively https://bugs.webkit.org/show_bug.cgi?id=91941 Reviewed by Kentaro Hara. A flag name for an elmement should be ENABLE_*_ELEMENT. * Configurations/FeatureDefines.xcconfig: 2012-07-22 Kent Tamura Rename ENABLE_DETAILS to ENABLE_DETAILS_ELEMENT https://bugs.webkit.org/show_bug.cgi?id=91928 Reviewed by Kentaro Hara. A flag name for an elmement should be ENABLE_*_ELEMENT. * Configurations/FeatureDefines.xcconfig: 2012-07-21 Patrick Gansterer [WIN] Use GetDateFormat and GetTimeFormat instead of strftime https://bugs.webkit.org/show_bug.cgi?id=83436 Reviewed by Brent Fulgham. The MS CRT implementation of strftime calls the same two functions. Using them directly avoids the overhead of parsing the format string and removes the dependency on strftime() for WinCE where this function does not exist. * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): 2012-07-20 Kent Tamura Rename ENABLE_DATALIST to ENABLE_DATALIST_ELEMENT https://bugs.webkit.org/show_bug.cgi?id=91846 Reviewed by Kentaro Hara. A flag name for an elmement should be ENABLE_*_ELEMENT. * Configurations/FeatureDefines.xcconfig: 2012-07-20 Han Shen [Chromium] Compilation fails under gcc 4.7 https://bugs.webkit.org/show_bug.cgi?id=90227 Reviewed by Tony Chang. Disable warnings about c++0x compatibility in gcc newer than 4.6. * JavaScriptCore.gyp/JavaScriptCore.gyp: 2012-07-18 Filip Pizlo DFG cell checks should be hoisted https://bugs.webkit.org/show_bug.cgi?id=91717 Reviewed by Geoffrey Garen. The DFG has always had the policy of hoisting array and integer checks to the point of variable assignment. Eventually, we added doubles and booleans to the mix. But cells should really be part of this as well, particularly for 32-bit where accessing a known-type variable is dramatically cheaper than accessing a variable whose types is only predicted but otherwise unproven. This appears to be a definite speed-up for V8 on 32-bit, a possible speed-up for Kraken, and a possible slow-down for V8 on 64-bit (around 0.2% if at all). Any slow-downs can, and should, be addressed by making the hoisting logic cognizant of variables that are never used in a manner that requires type checks, and by sinking argument checks to the point(s) of first use. To make this work I had to change some OSR machinery, and special-case the type predictions of the 'this' argument for constructors. OSR exit normally assumes that arguments are boxed, which happens to be true because the type prediction used for check hoisting is LUB'd with the type of the argument that was passed in - so either the arguments are always stored to with the full tag+payload, or if only the payload is stored then the tag matches whatever the caller would have set. But not so with the 'this' argument for constructors, which is not initialized by the caller. We could make this more precise by having argument types for OSR be inferred using similar machinery to other locals, but I figured that for this patch I should use the surgical fix. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branchTestPtr): (MacroAssemblerX86_64): * assembler/X86Assembler.h: (JSC::X86Assembler::testq_rm): (X86Assembler): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::execute): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.h: (JSC::DFG::Graph::isCreatedThisArgument): (Graph): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArgumentTypes): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::forSpeculation): 2012-07-19 Filip Pizlo Fast path of storage resize should be removed from property storage reallocation, since it is only useful for arrays https://bugs.webkit.org/show_bug.cgi?id=91796 Reviewed by Geoffrey Garen. * dfg/DFGRepatch.cpp: (JSC::DFG::emitPutTransitionStub): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): * runtime/JSObject.cpp: (JSC::JSObject::growOutOfLineStorage): 2012-07-19 Mark Lam Bug fixes and enhancements for OfflineASM annotation system. https://bugs.webkit.org/show_bug.cgi?id=91690 Reviewed by Filip Pizlo. * offlineasm/armv7.rb: added default handling of Instruction lower(). * offlineasm/asm.rb: added more support for annotations and more pretty printing. * offlineasm/ast.rb: added more support for annotations. * offlineasm/config.rb: added $preferredCommentStartColumn, simplified $enableInstrAnnotations. * offlineasm/parser.rb: added more support for annotations. * offlineasm/transform.rb: added more support for annotations. * offlineasm/x86.rb: added default handling of Instruction lower(). 2012-07-19 Patrick Gansterer [WIN] Fix compilation of JSGlobalData.h with ENABLE(DFG_JIT) https://bugs.webkit.org/show_bug.cgi?id=91243 Reviewed by Geoffrey Garen. Disable MSVC warning 4200 "zero-sized array in struct/union" for JSC::ScratchBuffer. * runtime/JSGlobalData.h: (JSC): 2012-07-19 Mark Lam Fixed broken ENABLE_JIT=0 build. https://bugs.webkit.org/show_bug.cgi?id=91725 Reviewed by Oliver Hunt. * bytecode/Watchpoint.cpp: * heap/JITStubRoutineSet.h: (JSC): (JITStubRoutineSet): (JSC::JITStubRoutineSet::JITStubRoutineSet): (JSC::JITStubRoutineSet::~JITStubRoutineSet): (JSC::JITStubRoutineSet::add): (JSC::JITStubRoutineSet::clearMarks): (JSC::JITStubRoutineSet::mark): (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): (JSC::JITStubRoutineSet::traceMarkedStubRoutines): 2012-07-19 Kristóf Kosztyó [Qt] Unreviewed buildfix after r123042. * interpreter/Interpreter.cpp: (JSC::Interpreter::dumpRegisters): 2012-07-18 Filip Pizlo DFG should emit inline code for property storage (re)allocation https://bugs.webkit.org/show_bug.cgi?id=91597 Reviewed by Oliver Hunt. This adds two new ops to the DFG IR: AllocatePropertyStorage and ReallocatePropertyStorage. It enables these to interact properly with CSE so that a GetPropertyStorage on something for which we have obviously done a (Re)AllocatePropertyStorage will result in the GetPropertyStorage being eliminated. Other than that, the code emitted for these ops is identical to the code we were emitting in the corresponding PutById stub. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::putStructureStoreElimination): (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): * dfg/DFGNode.h: (JSC::DFG::Node::hasStructureTransitionData): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (DFG): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * runtime/Structure.cpp: (JSC::nextOutOfLineStorageCapacity): * runtime/Structure.h: (JSC): 2012-07-16 Oliver Hunt dumpCallFrame is broken in ToT https://bugs.webkit.org/show_bug.cgi?id=91444 Reviewed by Gavin Barraclough. Various changes have been made to the SF calling convention, but dumpCallFrame has not been updated to reflect these changes. That resulted in both bogus information, as well as numerous assertions of sadness. This patch makes dumpCallFrame actually work again and adds the wonderful feature of telling you the name of the variable that a register reflects, or what value it contains. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::nameForRegister): A really innefficient mechanism for finding the name of a local register. This should only ever be used by debug code so this should be okay. * bytecode/CodeBlock.h: (CodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): Debug builds no longer throw away a functions symbol table, this allows us to actually perform a register# to name mapping * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): We weren't propogating the bytecode offset here leading to assertions in debug builds when dumping bytecode of DFG compiled code. * interpreter/Interpreter.cpp: (JSC): (JSC::Interpreter::dumpRegisters): Rework to actually be correct. (JSC::getCallerInfo): Return the byteocde offset as well now, given we have to determine it anyway. (JSC::Interpreter::getStackTrace): (JSC::Interpreter::retrieveCallerFromVMCode): * interpreter/Interpreter.h: (Interpreter): * jsc.cpp: (GlobalObject::finishCreation): (functionDumpCallFrame): Give debug builds of JSC a method for calling dumpCallFrame so we can inspect a callframe without requiring us to break in a debugger. 2012-07-18 Filip Pizlo DFG 32-bit PutById transition stub storage reallocation case copies the first pointer of each JSValue instead of the whole JSValue https://bugs.webkit.org/show_bug.cgi?id=91599 Reviewed by Geoffrey Garen. * dfg/DFGRepatch.cpp: (JSC::DFG::emitPutTransitionStub): 2012-07-17 Filip Pizlo DFG 32-bit PutById transition stub passes the payload/tag arguments to a DFG operation in the wrong order https://bugs.webkit.org/show_bug.cgi?id=91576 Reviewed by Gavin Barraclough. * dfg/DFGRepatch.cpp: (JSC::DFG::emitPutTransitionStub): 2012-07-17 Filip Pizlo [Qt] REGRESSION(r122768, r122771): They broke jquery/data.html and inspector/elements/edit-dom-actions.html https://bugs.webkit.org/show_bug.cgi?id=91476 Reviewed by Mark Hahnenberg. The 32-bit repatching code was not correctly adapted to the new world where there may not always be an available scratch register. Fixed it by ensuring that the scratch register we select does not overlap with the value tag. * dfg/DFGRepatch.cpp: (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::emitPutReplaceStub): 2012-07-17 Gabor Rapcsanyi Unreviewed buildfix from Zoltan Herczeg after 122768. * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (CCallHelpers): 2012-07-17 David Barr Introduce ENABLE_CSS_IMAGE_ORIENTATION compile flag https://bugs.webkit.org/show_bug.cgi?id=89055 Reviewed by Kent Tamura. The css3-images module is at candidate recommendation. http://www.w3.org/TR/2012/CR-css3-images-20120417/#the-image-orientation Add a configuration option for CSS image-orientation support, disabling it by default. * Configurations/FeatureDefines.xcconfig: 2012-07-16 Filip Pizlo Unreviewed, roll out 122790 because it broke the Windows build. I'm not sure what to do with exported symbols that are predicated on NDEBUG. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * bytecode/CodeBlock.cpp: (JSC): * bytecode/CodeBlock.h: (CodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * interpreter/Interpreter.cpp: (JSC): (JSC::Interpreter::dumpRegisters): (JSC::getCallerInfo): (JSC::Interpreter::getStackTrace): (JSC::Interpreter::retrieveCallerFromVMCode): * interpreter/Interpreter.h: (Interpreter): * jsc.cpp: (GlobalObject::finishCreation): 2012-07-16 Oliver Hunt dumpCallFrame is broken in ToT https://bugs.webkit.org/show_bug.cgi?id=91444 Reviewed by Gavin Barraclough. Various changes have been made to the SF calling convention, but dumpCallFrame has not been updated to reflect these changes. That resulted in both bogus information, as well as numerous assertions of sadness. This patch makes dumpCallFrame actually work again and adds the wonderful feature of telling you the name of the variable that a register reflects, or what value it contains. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::nameForRegister): A really innefficient mechanism for finding the name of a local register. This should only ever be used by debug code so this should be okay. * bytecode/CodeBlock.h: (CodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): Debug builds no longer throw away a functions symbol table, this allows us to actually perform a register# to name mapping * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): We weren't propogating the bytecode offset here leading to assertions in debug builds when dumping bytecode of DFG compiled code. * interpreter/Interpreter.cpp: (JSC): (JSC::Interpreter::dumpRegisters): Rework to actually be correct. (JSC::getCallerInfo): Return the byteocde offset as well now, given we have to determine it anyway. (JSC::Interpreter::getStackTrace): (JSC::Interpreter::retrieveCallerFromVMCode): * interpreter/Interpreter.h: (Interpreter): * jsc.cpp: (GlobalObject::finishCreation): (functionDumpCallFrame): Give debug builds of JSC a method for calling dumpCallFrame so we can inspect a callframe without requiring us to break in a debugger. 2012-07-16 Filip Pizlo Unreviewed, adding forgotten files. * dfg/DFGRegisterSet.h: Added. (DFG): (RegisterSet): (JSC::DFG::RegisterSet::RegisterSet): (JSC::DFG::RegisterSet::asPOD): (JSC::DFG::RegisterSet::copyInfo): (JSC::DFG::RegisterSet::set): (JSC::DFG::RegisterSet::setGPRByIndex): (JSC::DFG::RegisterSet::clear): (JSC::DFG::RegisterSet::get): (JSC::DFG::RegisterSet::getGPRByIndex): (JSC::DFG::RegisterSet::getFreeGPR): (JSC::DFG::RegisterSet::setFPRByIndex): (JSC::DFG::RegisterSet::getFPRByIndex): (JSC::DFG::RegisterSet::setByIndex): (JSC::DFG::RegisterSet::getByIndex): (JSC::DFG::RegisterSet::numberOfSetGPRs): (JSC::DFG::RegisterSet::numberOfSetFPRs): (JSC::DFG::RegisterSet::numberOfSetRegisters): (JSC::DFG::RegisterSet::setBit): (JSC::DFG::RegisterSet::clearBit): (JSC::DFG::RegisterSet::getBit): * dfg/DFGScratchRegisterAllocator.h: Added. (DFG): (ScratchRegisterAllocator): (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::DFG::ScratchRegisterAllocator::lock): (JSC::DFG::ScratchRegisterAllocator::allocateScratch): (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR): (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR): (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters): (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping): (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize): (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): 2012-07-15 Filip Pizlo DFG PutById transition should handle storage allocation, and inline it https://bugs.webkit.org/show_bug.cgi?id=91337 Reviewed by Oliver Hunt. This enables the patching of DFG PutById to handle the out-of-line storage allocation case. Furthermore, it inlines out-of-line storage allocation (and reallocation) into the generated stubs. To do this, this patch adds the ability to store the relevant register allocation state (i.e. the set of in-use registers) in the structure stub info so that the stub generation code can more flexibly select scratch registers: sometimes it needs none, sometimes one - or sometimes up to three. Moreover, to make the stub generation register allocation simple and maintainable, this patch introduces a reusable scratch register allocator class. This register allocator understands that some registers are in use by the main path code and so must be spilled as necessary, other registers are locked for use in the stub itself and so cannot even be spilled, while still others may be allocated for scratch purposes. A scratch register that is used must be spilled. If a register is locked, it cannot be used as a scratch register. If a register is used, it can be used as a scratch register so long as it is spilled. This is a sub-1% speed-up on V8 and neutral elsewhere. * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssemblerCodeRef.h: (FunctionPtr): (JSC::FunctionPtr::FunctionPtr): * bytecode/StructureStubInfo.h: * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (CCallHelpers): * dfg/DFGGPRInfo.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord): (PropertyAccessRecord): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGRegisterBank.h: (JSC::DFG::RegisterBank::isInUse): (RegisterBank): * dfg/DFGRegisterSet.h: Added. (DFG): (RegisterSet): (JSC::DFG::RegisterSet::RegisterSet): (JSC::DFG::RegisterSet::asPOD): (JSC::DFG::RegisterSet::copyInfo): (JSC::DFG::RegisterSet::set): (JSC::DFG::RegisterSet::setGPRByIndex): (JSC::DFG::RegisterSet::clear): (JSC::DFG::RegisterSet::get): (JSC::DFG::RegisterSet::getGPRByIndex): (JSC::DFG::RegisterSet::getFreeGPR): (JSC::DFG::RegisterSet::setFPRByIndex): (JSC::DFG::RegisterSet::getFPRByIndex): (JSC::DFG::RegisterSet::setByIndex): (JSC::DFG::RegisterSet::getByIndex): (JSC::DFG::RegisterSet::numberOfSetGPRs): (JSC::DFG::RegisterSet::numberOfSetFPRs): (JSC::DFG::RegisterSet::numberOfSetRegisters): (JSC::DFG::RegisterSet::setBit): (JSC::DFG::RegisterSet::clearBit): (JSC::DFG::RegisterSet::getBit): * dfg/DFGRepatch.cpp: (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::emitPutReplaceStub): (JSC::DFG::emitPutTransitionStub): (JSC::DFG::tryCachePutByID): (JSC::DFG::tryBuildPutByIdList): * dfg/DFGScratchRegisterAllocator.h: Added. (DFG): (ScratchRegisterAllocator): (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::DFG::ScratchRegisterAllocator::lock): (JSC::DFG::ScratchRegisterAllocator::allocateScratch): (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR): (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR): (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters): (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping): (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize): (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::usedRegisters): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * heap/CopiedAllocator.h: (CopiedAllocator): (JSC::CopiedAllocator::fastPathShouldSucceed): (JSC): 2012-07-16 Patrick Gansterer Add dfg switch to create_jit_stubs script https://bugs.webkit.org/show_bug.cgi?id=91256 Reviewed by Geoffrey Garen. * create_jit_stubs: Add a switch to enable or disable the generation of stub functions in #if ENABLE(DFG_JIT) conditions. 2012-07-16 Gabor Rapcsanyi Unreviewed buildfix after r122729. Typo fix. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::add32): 2012-07-16 Gabor Rapcsanyi Unreviewed buildfix from Zoltan Herczeg after r122677. Implement missing add32 function to MacroAssemblerARM. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::add32): (MacroAssemblerARM): 2012-07-14 Filip Pizlo DFG PutByVal opcodes should accept more than 3 operands https://bugs.webkit.org/show_bug.cgi?id=91332 Reviewed by Oliver Hunt. Turned PutByVal/PutByValAlias into var-arg nodes, so that we can give them 4 or more operands in the future. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixDoubleEdge): * dfg/DFGGraph.h: (JSC::DFG::Graph::byValIsPure): (JSC::DFG::Graph::varArgNumChildren): (Graph): (JSC::DFG::Graph::numChildren): (JSC::DFG::Graph::varArgChild): (JSC::DFG::Graph::child): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-07-14 Filip Pizlo Rationalize and optimize storage allocation https://bugs.webkit.org/show_bug.cgi?id=91303 Reviewed by Oliver Hunt. This implements a backwards bump allocator for copied space storage allocation, shown in pseudo-code below: pointer bump(size) { pointer tmp = allocator->remaining; tmp -= size; if (tmp < 0) fail; allocator->remaining = tmp; return allocator->payloadEnd - tmp - size; } The advantage of this allocator is that it: - Only requires one comparison in the common case where size is known to not be huge, and this comparison can be done by checking the sign bit of the subtraction. - Can be implemented even when only one register is available. This register is reused for both temporary storage during allocation and for the result. - Preserves the behavior that memory in a block is filled in from lowest address to highest address, which allows for a cheap reallocation fast path. - Is resilient against the block used for allocation being the last one in virtual memory, thereby otherwise leading to the risk of overflow in the bump pointer, despite only doing one branch. In order to implement this allocator using the smallest possible chunk of code, I refactored the copied space code so that all of the allocation logic is in CopiedAllocator, and all of the state is in either CopiedBlock or CopiedAllocator. This should make changing the allocation fast path easier in the future. In order to do this, I needed to add some new assembler support, particularly for various forms of add(address, register) and negPtr(). This is performance neutral. The purpose of this change is to facilitate further inlining of storage allocation without having to reserve additional registers or emit too much code. * assembler/MacroAssembler.h: (JSC::MacroAssembler::addPtr): (MacroAssembler): (JSC::MacroAssembler::negPtr): * assembler/MacroAssemblerARMv7.h: (MacroAssemblerARMv7): (JSC::MacroAssemblerARMv7::add32): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (MacroAssemblerX86): * assembler/MacroAssemblerX86_64.h: (MacroAssemblerX86_64): (JSC::MacroAssemblerX86_64::addPtr): (JSC::MacroAssemblerX86_64::negPtr): * assembler/X86Assembler.h: (X86Assembler): (JSC::X86Assembler::addl_mr): (JSC::X86Assembler::addq_mr): (JSC::X86Assembler::negq_r): * heap/CopiedAllocator.h: (CopiedAllocator): (JSC::CopiedAllocator::isValid): (JSC::CopiedAllocator::CopiedAllocator): (JSC::CopiedAllocator::tryAllocate): (JSC): (JSC::CopiedAllocator::tryReallocate): (JSC::CopiedAllocator::forceAllocate): (JSC::CopiedAllocator::resetCurrentBlock): (JSC::CopiedAllocator::setCurrentBlock): (JSC::CopiedAllocator::currentCapacity): * heap/CopiedBlock.h: (CopiedBlock): (JSC::CopiedBlock::create): (JSC::CopiedBlock::zeroFillWilderness): (JSC::CopiedBlock::CopiedBlock): (JSC::CopiedBlock::payloadEnd): (JSC): (JSC::CopiedBlock::payloadCapacity): (JSC::CopiedBlock::data): (JSC::CopiedBlock::dataEnd): (JSC::CopiedBlock::dataSize): (JSC::CopiedBlock::wilderness): (JSC::CopiedBlock::wildernessEnd): (JSC::CopiedBlock::wildernessSize): (JSC::CopiedBlock::size): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateSlowCase): (JSC::CopiedSpace::tryAllocateOversize): (JSC::CopiedSpace::tryReallocate): (JSC::CopiedSpace::doneFillingBlock): (JSC::CopiedSpace::doneCopying): * heap/CopiedSpace.h: (CopiedSpace): * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::startedCopying): (JSC::CopiedSpace::allocateBlockForCopyingPhase): (JSC::CopiedSpace::allocateBlock): (JSC::CopiedSpace::tryAllocate): (JSC): * heap/MarkStack.cpp: (JSC::SlotVisitor::startCopying): (JSC::SlotVisitor::allocateNewSpace): (JSC::SlotVisitor::doneCopying): * heap/SlotVisitor.h: (JSC::SlotVisitor::SlotVisitor): * jit/JIT.h: * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicStorage): (JSC::JIT::emitAllocateJSArray): 2012-07-13 Mark Lam OfflineASM Pretty printing and commenting enhancements. https://bugs.webkit.org/show_bug.cgi?id=91281 Reviewed by Filip Pizlo. Added some minor pretty printing in the OfflineASM. Also added infrastruture for adding multiple types of comments and annotations with the ability to enable/disable them in the generated output as desired. * GNUmakefile.list.am: add new file config.rb. * llint/LLIntOfflineAsmConfig.h: Added OFFLINE_ASM_BEGIN, OFFLINE_ASM_END, and OFFLINE_ASM_LOCAL_LABEL macros. This will allow us to redefine these for other backends later. * llint/LowLevelInterpreter32_64.asm: Add a small example of instruction annotations for now. * llint/LowLevelInterpreter64.asm: Add a small example of instruction annotations for now. * offlineasm/armv7.rb: Added handling of annotations. * offlineasm/asm.rb: Added machinery to dump the new comments and annotations. Also added some indentations to make the output a little prettier. * offlineasm/ast.rb: Added annotation field in class Instruction. * offlineasm/backends.rb: * offlineasm/config.rb: Added. Currently only contains commenting options. This file is meant to be a centralized place for build config values much like config.h for JavaScriptCore. * offlineasm/generate_offset_extractor.rb: * offlineasm/instructions.rb: * offlineasm/offsets.rb: * offlineasm/opt.rb: * offlineasm/parser.rb: Parse and record annotations. * offlineasm/registers.rb: * offlineasm/self_hash.rb: * offlineasm/settings.rb: * offlineasm/transform.rb: * offlineasm/x86.rb: Added handling of annotations. 2012-07-13 Filip Pizlo ASSERTION FAILED: use.useKind() != DoubleUse https://bugs.webkit.org/show_bug.cgi?id=91082 Reviewed by Geoffrey Garen. The implementation of Branch() was unwisely relying on register allocation state to decide what speculations to perform. That's never correct. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-07-13 Sheriff Bot Unreviewed, rolling out r122640. http://trac.webkit.org/changeset/122640 https://bugs.webkit.org/show_bug.cgi?id=91298 LLInt apparently does not expect to mark these (Requested by olliej on #webkit). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitStructures): (JSC::CodeBlock::stronglyVisitStrongReferences): 2012-07-13 Oliver Hunt LLInt fails to mark structures stored in the bytecode https://bugs.webkit.org/show_bug.cgi?id=91296 Reviewed by Geoffrey Garen. LLInt stores structures in the bytecode, so we need to visit the appropriate instructions as we would if we were running in the classic interpreter. This requires adding additional checks for the LLInt specific opcodes, and the lint specific variants of operand ordering. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitStructures): (JSC::CodeBlock::stronglyVisitStrongReferences): 2012-07-13 Yong Li [BlackBerry] Implement GCActivityCallback with platform timer https://bugs.webkit.org/show_bug.cgi?id=90175 Reviewed by Rob Buis. Implement GCActivityCallback and HeapTimer for BlackBerry port. * heap/HeapTimer.cpp: (JSC): (JSC::HeapTimer::HeapTimer): (JSC::HeapTimer::~HeapTimer): (JSC::HeapTimer::timerDidFire): (JSC::HeapTimer::synchronize): (JSC::HeapTimer::invalidate): (JSC::HeapTimer::didStartVMShutdown): * heap/HeapTimer.h: (HeapTimer): * runtime/GCActivityCallbackBlackBerry.cpp: (JSC): (JSC::DefaultGCActivityCallback::doWork): (JSC::DefaultGCActivityCallback::didAllocate): (JSC::DefaultGCActivityCallback::willCollect): (JSC::DefaultGCActivityCallback::cancel): 2012-07-13 Patrick Gansterer [WIN] Fix compilation of DFGRepatch.cpp https://bugs.webkit.org/show_bug.cgi?id=91241 Reviewed by Geoffrey Garen. Use intptr_t instead of uintptr_t when calling CodeLocationCommon::dataLabelPtrAtOffset(int) to fix MSVC "unary minus operator applied to unsigned type, result still unsigned" warning. * dfg/DFGRepatch.cpp: (JSC::DFG::dfgResetGetByID): (JSC::DFG::dfgResetPutByID): 2012-07-13 Patrick Gansterer Fix ARM_TRADITIONAL JIT for COMPILER(MSVC) and COMPILER(RVCT) after r121885 https://bugs.webkit.org/show_bug.cgi?id=91238 Reviewed by Zoltan Herczeg. r121885 changed the assembler instruction only for COMPILER(GCC). Use the same instructions for the other compilers too. * jit/JITStubs.cpp: (JSC::ctiTrampoline): (JSC::ctiTrampolineEnd): (JSC::ctiVMThrowTrampoline): 2012-07-12 Filip Pizlo DFG property access stubs should use structure transition watchpoints https://bugs.webkit.org/show_bug.cgi?id=91135 Reviewed by Geoffrey Garen. This adds a Watchpoint subclass that will clear a structure stub (i.e. a property access stub) when fired. The DFG stub generation code now uses this optimization. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::finalizeUnconditionally): (JSC::CodeBlock::resetStub): (JSC::CodeBlock::resetStubInternal): * bytecode/CodeBlock.h: (JSC): (CodeBlock): * bytecode/StructureStubClearingWatchpoint.cpp: Added. (JSC): (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint): (JSC::StructureStubClearingWatchpoint::push): (JSC::StructureStubClearingWatchpoint::fireInternal): (JSC::WatchpointsOnStructureStubInfo::~WatchpointsOnStructureStubInfo): (JSC::WatchpointsOnStructureStubInfo::addWatchpoint): (JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint): * bytecode/StructureStubClearingWatchpoint.h: Added. (JSC): (StructureStubClearingWatchpoint): (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): (WatchpointsOnStructureStubInfo): (JSC::WatchpointsOnStructureStubInfo::WatchpointsOnStructureStubInfo): (JSC::WatchpointsOnStructureStubInfo::codeBlock): (JSC::WatchpointsOnStructureStubInfo::stubInfo): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::addWatchpoint): (StructureStubInfo): * dfg/DFGRepatch.cpp: (JSC::DFG::addStructureTransitionCheck): (DFG): (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::emitPutTransitionStub): * jit/JumpReplacementWatchpoint.h: 2012-07-12 Filip Pizlo DFG CFA may get overzealous in loops that have code that must exit https://bugs.webkit.org/show_bug.cgi?id=91188 Reviewed by Gavin Barraclough. Ensure that if the CFA assumes that an operation must exit, then it will always exit no matter what happens after. That's necessary to preserve soundness. Remove a broken fixup done by the DFG simplifier, where it was trying to say that the variable-at-head was the first access in the second block in the merge, if the first block did not read the variable. That's totally wrong, if the first block was in fact doing a phantom read. I removed that fixup and instead hardened the rest of the compiler. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::endBasicBlock): * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::BasicBlock): (BasicBlock): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performBlockCFA): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::mergeBlocks): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase): (JSC::DFG::ConstantFoldingPhase::run): (ConstantFoldingPhase): (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): 2012-07-12 Allan Sandfeld Jensen [Qt] Implement MemoryUsageSupport https://bugs.webkit.org/show_bug.cgi?id=91094 Reviewed by Adam Barth. Compile in MemoryStatistics so we can make use of the interface. * Target.pri: 2012-07-12 Csaba Osztrogonác Remove dead code after r122392. https://bugs.webkit.org/show_bug.cgi?id=91049 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): 2012-07-11 Adenilson Cavalcanti Build fix + remove dead code https://bugs.webkit.org/show_bug.cgi?id=91039 Reviewed by Filip Pizlo. An unused variable was breaking compilation (thanks to warnings being treated as errors). * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): 2012-07-11 Mark Rowe Build against the latest SDK when targeting older OS X versions. Reviewed by Dan Bernstein. The deployment target is already set to the version that we're targeting, and it's that setting which determines which functionality from the SDK is available to us. * Configurations/Base.xcconfig: 2012-07-11 Filip Pizlo DFG should have fast virtual calls https://bugs.webkit.org/show_bug.cgi?id=90924 Reviewed by Gavin Barraclough. Implements virtual call support in the style of the old JIT, with the caveat that we still use the same slow path for both InternalFunction calls and JSFunction calls. Also rationalized the way that our CodeOrigin indices tie into exception checks (previously it was a strange one-to-one mapping with fairly limited assertions; now it's a one-to-many mapping for CodeOrigins to exception checks, respectively). I also took the opportunity to clean up CallLinkInfo::callReturnLocation, which previously was either a Call or a NearCall. Now it's just a NearCall. As well, exceptions during slow path call resolution are now handled by returning an exception throwing thunk rather than returning null. And finally, I made a few things public that were previously private-with-lots-of-friends, because I truly despise the thought of listing each thunk generating function as a friend of JSValue and friends. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::unlink): * bytecode/CallLinkInfo.h: (CallLinkInfo): * bytecode/CodeOrigin.h: (JSC::CodeOrigin::CodeOrigin): (JSC::CodeOrigin::isSet): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::AssemblyHelpers): * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::CCallHelpers): * dfg/DFGGPRInfo.h: (GPRInfo): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::CallBeginToken::CallBeginToken): (JSC::DFG::CallBeginToken::~CallBeginToken): (CallBeginToken): (JSC::DFG::CallBeginToken::set): (JSC::DFG::CallBeginToken::registerWithExceptionCheck): (JSC::DFG::CallBeginToken::codeOrigin): (JSC::DFG::CallExceptionRecord::CallExceptionRecord): (CallExceptionRecord): (JSC::DFG::JITCompiler::currentCodeOriginIndex): (JITCompiler): (JSC::DFG::JITCompiler::beginCall): (JSC::DFG::JITCompiler::notifyCall): (JSC::DFG::JITCompiler::prepareForExceptionCheck): (JSC::DFG::JITCompiler::addExceptionCheck): (JSC::DFG::JITCompiler::addFastExceptionCheck): * dfg/DFGOperations.cpp: * dfg/DFGRepatch.cpp: (JSC::DFG::dfgLinkFor): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGThunks.cpp: (JSC::DFG::emitPointerValidation): (DFG): (JSC::DFG::throwExceptionFromCallSlowPathGenerator): (JSC::DFG::slowPathFor): (JSC::DFG::linkForThunkGenerator): (JSC::DFG::linkCallThunkGenerator): (JSC::DFG::linkConstructThunkGenerator): (JSC::DFG::virtualForThunkGenerator): (JSC::DFG::virtualCallThunkGenerator): (JSC::DFG::virtualConstructThunkGenerator): * dfg/DFGThunks.h: (DFG): * jit/JIT.cpp: (JSC::JIT::privateCompile): (JSC::JIT::linkFor): * runtime/Executable.h: (ExecutableBase): (JSC::ExecutableBase::offsetOfJITCodeFor): (JSC::ExecutableBase::offsetOfNumParametersFor): * runtime/JSValue.h: (JSValue): 2012-07-11 Filip Pizlo Accidentally used the wrong license (3-clause instead of 2-clause) in some files I just committed. Rubber stamped by Oliver Hunt. * bytecode/Watchpoint.cpp: * bytecode/Watchpoint.h: * jit/JumpReplacementWatchpoint.cpp: * jit/JumpReplacementWatchpoint.h: 2012-07-11 Filip Pizlo Watchpoints and jump replacement should be decoupled https://bugs.webkit.org/show_bug.cgi?id=91016 Reviewed by Oliver Hunt. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/AbstractMacroAssembler.h: (JSC): (Label): * bytecode/CodeBlock.h: (JSC::CodeBlock::appendWatchpoint): (JSC::CodeBlock::watchpoint): (DFGData): * bytecode/Watchpoint.cpp: (JSC): * bytecode/Watchpoint.h: (JSC::Watchpoint::Watchpoint): (Watchpoint): (JSC::Watchpoint::fire): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::speculationWatchpoint): * jit/JumpReplacementWatchpoint.cpp: Added. (JSC): (JSC::JumpReplacementWatchpoint::correctLabels): (JSC::JumpReplacementWatchpoint::fireInternal): * jit/JumpReplacementWatchpoint.h: Added. (JSC): (JumpReplacementWatchpoint): (JSC::JumpReplacementWatchpoint::JumpReplacementWatchpoint): (JSC::JumpReplacementWatchpoint::setDestination): 2012-07-11 Kevin Ollivier [wx] Unreviewed build fix. Don't try to build udis86_itab.c since it's included by another file. * wscript: 2012-07-11 Chao-ying Fu Add MIPS convertibleLoadPtr and other functions https://bugs.webkit.org/show_bug.cgi?id=90714 Reviewed by Oliver Hunt. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::labelIgnoringWatchpoints): (MIPSAssembler): (JSC::MIPSAssembler::replaceWithLoad): (JSC::MIPSAssembler::replaceWithAddressComputation): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::convertibleLoadPtr): (MacroAssemblerMIPS): 2012-07-11 Anders Carlsson Add -Wtautological-compare and -Wsign-compare warning flags https://bugs.webkit.org/show_bug.cgi?id=90994 Reviewed by Mark Rowe. * Configurations/Base.xcconfig: 2012-07-11 Benjamin Poulain Simplify the copying of JSC ARMv7's LinkRecord https://bugs.webkit.org/show_bug.cgi?id=90930 Reviewed by Filip Pizlo. The class LinkRecord is used by value everywhere in ARMv7Assembler. The compiler uses memmove() to move the objects. The problem is memmove() is overkill for this object, moving the value can be done with 3 load-store. This patch adds an operator= to the class doing more efficient copying. This reduces the link time by 19%. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::LinkRecord::LinkRecord): (JSC::ARMv7Assembler::LinkRecord::operator=): (JSC::ARMv7Assembler::LinkRecord::from): (JSC::ARMv7Assembler::LinkRecord::setFrom): (JSC::ARMv7Assembler::LinkRecord::to): (JSC::ARMv7Assembler::LinkRecord::type): (JSC::ARMv7Assembler::LinkRecord::linkType): (JSC::ARMv7Assembler::LinkRecord::setLinkType): (JSC::ARMv7Assembler::LinkRecord::condition): 2012-07-11 Andy Wingo jsc: Parse options before creating global data https://bugs.webkit.org/show_bug.cgi?id=90975 Reviewed by Filip Pizlo. This patch moves the options parsing in "jsc" before the creation of the JSGlobalData, so that --useJIT=no has a chance to take effect. * jsc.cpp: (CommandLine::parseArguments): Refactor to be a class, and take argc and argv as constructor arguments. (jscmain): Move arg parsing before JSGlobalData creation. 2012-07-10 Filip Pizlo REGRESSION(r122166): It made 170 tests crash on 32 bit platforms https://bugs.webkit.org/show_bug.cgi?id=90852 Reviewed by Zoltan Herczeg. If we can't use the range filter, we should still make sure that the address is remotely sane, otherwise the hashtables will assert. * jit/JITStubRoutine.h: (JSC::JITStubRoutine::passesFilter): 2012-07-10 Filip Pizlo DFG recompilation heuristics should be based on count, not rate https://bugs.webkit.org/show_bug.cgi?id=90146 Reviewed by Oliver Hunt. Rolling r121511 back in after fixing the DFG's interpretation of op_div profiling, with Gavin's rubber stamp. This removes a bunch of code that was previously trying to prevent spurious reoptimizations if a large enough majority of executions of a code block did not result in OSR exit. It turns out that this code was purely harmful. This patch removes all of that logic and replaces it with a dead-simple heuristic: if you exit more than N times (where N is an exponential function of the number of times the code block has already been recompiled) then we will recompile. This appears to be a broad ~1% win on many benchmarks large and small. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/CodeBlock.h: (JSC::CodeBlock::couldTakeSpecialFastCase): (CodeBlock): (JSC::CodeBlock::osrExitCounter): (JSC::CodeBlock::countOSRExit): (JSC::CodeBlock::addressOfOSRExitCounter): (JSC::CodeBlock::offsetOfOSRExitCounter): (JSC::CodeBlock::adjustedExitCountThreshold): (JSC::CodeBlock::exitCountThresholdForReoptimization): (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): (JSC::CodeBlock::shouldReoptimizeNow): (JSC::CodeBlock::shouldReoptimizeFromLoopNow): * bytecode/ExecutionCounter.cpp: (JSC::ExecutionCounter::setThreshold): * bytecode/ExecutionCounter.h: (ExecutionCounter): (JSC::ExecutionCounter::clippedThreshold): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeDivSafe): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExitCompiler::handleExitCounts): * dfg/DFGOperations.cpp: * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Options.h: (JSC): 2012-07-09 Matt Falkenhagen Add ENABLE_DIALOG_ELEMENT and skeleton files https://bugs.webkit.org/show_bug.cgi?id=90521 Reviewed by Kent Tamura. * Configurations/FeatureDefines.xcconfig: 2012-07-09 Filip Pizlo Unreviewed, roll out http://trac.webkit.org/changeset/121511 It made in-browser V8v7 10% slower. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::countSpeculationSuccess): (JSC::CodeBlock::countSpeculationFailure): (JSC::CodeBlock::speculativeSuccessCounter): (JSC::CodeBlock::speculativeFailCounter): (JSC::CodeBlock::forcedOSRExitCounter): (JSC::CodeBlock::addressOfSpeculativeSuccessCounter): (JSC::CodeBlock::addressOfSpeculativeFailCounter): (JSC::CodeBlock::addressOfForcedOSRExitCounter): (JSC::CodeBlock::offsetOfSpeculativeSuccessCounter): (JSC::CodeBlock::offsetOfSpeculativeFailCounter): (JSC::CodeBlock::offsetOfForcedOSRExitCounter): (JSC::CodeBlock::largeFailCountThreshold): (JSC::CodeBlock::largeFailCountThresholdForLoop): (JSC::CodeBlock::shouldReoptimizeNow): (JSC::CodeBlock::shouldReoptimizeFromLoopNow): * bytecode/ExecutionCounter.cpp: (JSC::ExecutionCounter::setThreshold): * bytecode/ExecutionCounter.h: (ExecutionCounter): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExitCompiler::handleExitCounts): * dfg/DFGOperations.cpp: * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Options.h: (JSC): 2012-07-09 Filip Pizlo DFG may get stuck in an infinite fix point if it constant folds a mispredicted node https://bugs.webkit.org/show_bug.cgi?id=90829 Reviewed by Oliver Hunt. If a node is shown to have been mispredicted during CFA, then don't allow constant folding to make the graph even more degenerate. Instead, pull back on constant folding and allow the normal OSR machinery to fix our profiling so that a future recompilation doesn't see the same mistake. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::trySetConstant): (AbstractState): * dfg/DFGPhase.h: (JSC::DFG::Phase::name): (Phase): (JSC::DFG::runAndLog): (DFG): (JSC::DFG::runPhase): 2012-07-09 Filip Pizlo It should be possible to jettison JIT stub routines even if they are currently running https://bugs.webkit.org/show_bug.cgi?id=90731 Reviewed by Gavin Barraclough. This gives the GC awareness of all JIT-generated stubs for inline caches. That means that if you want to delete a JIT-generated stub, you don't have to worry about whether or not it is currently running: if there is a chance that it might be, the GC will kindly defer deletion until non-running-ness is proved. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/Instruction.h: (JSC): (PolymorphicStubInfo): (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set): (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList): * bytecode/PolymorphicPutByIdList.cpp: (JSC::PutByIdAccess::fromStructureStubInfo): * bytecode/PolymorphicPutByIdList.h: (JSC::PutByIdAccess::transition): (JSC::PutByIdAccess::replace): (JSC::PutByIdAccess::stubRoutine): (PutByIdAccess): (JSC::PolymorphicPutByIdList::currentSlowPathTarget): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::reset): * dfg/DFGRepatch.cpp: (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::tryBuildGetByIDProtoList): (JSC::DFG::emitPutReplaceStub): (JSC::DFG::emitPutTransitionStub): (JSC::DFG::tryCachePutByID): (JSC::DFG::tryBuildPutByIdList): * heap/ConservativeRoots.cpp: (JSC): (DummyMarkHook): (JSC::DummyMarkHook::mark): (JSC::ConservativeRoots::add): (CompositeMarkHook): (JSC::CompositeMarkHook::CompositeMarkHook): (JSC::CompositeMarkHook::mark): * heap/ConservativeRoots.h: (JSC): (ConservativeRoots): * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::deleteUnmarkedCompiledCode): * heap/Heap.h: (JSC): (Heap): * heap/JITStubRoutineSet.cpp: Added. (JSC): (JSC::JITStubRoutineSet::JITStubRoutineSet): (JSC::JITStubRoutineSet::~JITStubRoutineSet): (JSC::JITStubRoutineSet::add): (JSC::JITStubRoutineSet::clearMarks): (JSC::JITStubRoutineSet::markSlow): (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): (JSC::JITStubRoutineSet::traceMarkedStubRoutines): * heap/JITStubRoutineSet.h: Added. (JSC): (JITStubRoutineSet): (JSC::JITStubRoutineSet::mark): * heap/MachineStackMarker.h: (JSC): * interpreter/RegisterFile.cpp: (JSC::RegisterFile::gatherConservativeRoots): * interpreter/RegisterFile.h: (JSC): * jit/ExecutableAllocator.cpp: (JSC::DemandExecutableAllocator::DemandExecutableAllocator): * jit/ExecutableAllocator.h: (JSC): * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC): (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): * jit/GCAwareJITStubRoutine.cpp: Added. (JSC): (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutine::observeZeroRefCount): (JSC::GCAwareJITStubRoutine::deleteFromGC): (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal): (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): (JSC::createJITStubRoutine): * jit/GCAwareJITStubRoutine.h: Added. (JSC): (GCAwareJITStubRoutine): (JSC::GCAwareJITStubRoutine::markRequiredObjects): (MarkingGCAwareJITStubRoutineWithOneObject): * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::privateCompilePatchGetArrayLength): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::privateCompilePatchGetArrayLength): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): * jit/JITStubRoutine.cpp: Added. (JSC): (JSC::JITStubRoutine::~JITStubRoutine): (JSC::JITStubRoutine::observeZeroRefCount): * jit/JITStubRoutine.h: Added. (JSC): (JITStubRoutine): (JSC::JITStubRoutine::JITStubRoutine): (JSC::JITStubRoutine::createSelfManagedRoutine): (JSC::JITStubRoutine::code): (JSC::JITStubRoutine::asCodePtr): (JSC::JITStubRoutine::ref): (JSC::JITStubRoutine::deref): (JSC::JITStubRoutine::startAddress): (JSC::JITStubRoutine::endAddress): (JSC::JITStubRoutine::addressStep): (JSC::JITStubRoutine::canPerformRangeFilter): (JSC::JITStubRoutine::filteringStartAddress): (JSC::JITStubRoutine::filteringExtentSize): (JSC::JITStubRoutine::passesFilter): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): (JSC::getPolymorphicAccessStructureListSlot): 2012-07-09 Sheriff Bot Unreviewed, rolling out r122107. http://trac.webkit.org/changeset/122107 https://bugs.webkit.org/show_bug.cgi?id=90794 Build failure on Mac debug bots (Requested by falken_ on #webkit). * Configurations/FeatureDefines.xcconfig: 2012-07-09 Matt Falkenhagen Add ENABLE_DIALOG_ELEMENT and skeleton files https://bugs.webkit.org/show_bug.cgi?id=90521 Reviewed by Kent Tamura. * Configurations/FeatureDefines.xcconfig: 2012-07-08 Ryosuke Niwa gcc build fix after r121925. * runtime/JSObject.h: (JSC::JSFinalObject::finishCreation): 2012-07-08 Zoltan Herczeg [Qt][ARM] Implementing missing macro assembler instructions after r121925 https://bugs.webkit.org/show_bug.cgi?id=90657 Reviewed by Csaba Osztrogonác. Implementing convertibleLoadPtr, replaceWithLoad and replaceWithAddressComputation. * assembler/ARMAssembler.h: (JSC::ARMAssembler::replaceWithLoad): (ARMAssembler): (JSC::ARMAssembler::replaceWithAddressComputation): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::convertibleLoadPtr): (MacroAssemblerARM): 2012-07-06 Filip Pizlo WebKit Version 5.1.7 (6534.57.2, r121935): Double-click no longer works on OpenStreetMap https://bugs.webkit.org/show_bug.cgi?id=90703 Reviewed by Michael Saboff. It turns out that in my object model refactoring, I managed to fix get_by_pname in all execution engines except 64-bit baseline JIT. * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_pname): 2012-07-06 Pravin D Build Error on Qt Linux build https://bugs.webkit.org/show_bug.cgi?id=90699 Reviewed by Laszlo Gombos. * parser/Parser.cpp: (JSC::::parseForStatement): Removed unused boolean variable as this was causing build error on Qt Linux. 2012-07-06 Nuno Lopes Fix build with recent clang. https://bugs.webkit.org/show_bug.cgi?id=90634 Reviewed by Oliver Hunt. * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): (SpecializedThunkJIT): * jit/ThunkGenerators.cpp: (JSC::charCodeAtThunkGenerator): (JSC::charAtThunkGenerator): (JSC::fromCharCodeThunkGenerator): (JSC::sqrtThunkGenerator): (JSC::floorThunkGenerator): (JSC::ceilThunkGenerator): (JSC::roundThunkGenerator): (JSC::expThunkGenerator): (JSC::logThunkGenerator): (JSC::absThunkGenerator): (JSC::powThunkGenerator): * parser/ASTBuilder.h: (JSC::ASTBuilder::createAssignResolve): (JSC::ASTBuilder::createForLoop): (JSC::ASTBuilder::createForInLoop): (JSC::ASTBuilder::makeAssignNode): (JSC::ASTBuilder::makePrefixNode): (JSC::ASTBuilder::makePostfixNode): * parser/NodeConstructors.h: (JSC::PostfixErrorNode::PostfixErrorNode): (JSC::PrefixErrorNode::PrefixErrorNode): (JSC::AssignResolveNode::AssignResolveNode): (JSC::AssignErrorNode::AssignErrorNode): (JSC::ForNode::ForNode): (JSC::ForInNode::ForInNode): * parser/Nodes.h: (FunctionCallResolveNode): (PostfixErrorNode): (PrefixErrorNode): (ReadModifyResolveNode): (AssignResolveNode): (AssignErrorNode): (ForNode): (ForInNode): * parser/Parser.cpp: (JSC::::parseVarDeclarationList): (JSC::::parseForStatement): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createAssignResolve): (JSC::SyntaxChecker::createForLoop): 2012-07-06 Zoltan Herczeg [Qt][ARM] REGRESSION(r121885): It broke 30 jsc tests, 500+ layout tests https://bugs.webkit.org/show_bug.cgi?id=90656 Reviewed by Csaba Osztrogonác. Typo fixes. * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): Rename getOp2Byte() -> getOp2Half() * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::convertibleLoadPtr): Add a necessary space. * jit/JITStubs.cpp: (JSC): Revert INLINE_ARM_FUNCTION macro. 2012-07-05 Filip Pizlo REGRESSION(r121925): It broke 5 sputnik tests on x86 platforms https://bugs.webkit.org/show_bug.cgi?id=90658 Reviewed by Zoltan Herczeg. Under the new object model, out-of-line property accesses such as those in ResolveGlobal must account for the fact that the offset to the Kth property is represented by K + inlineStorageCapacity. Hence, the property loads in ResolveGlobal must have an additional -inlineStorageCapacity * sizeof(JSValue) offset. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-07-05 Csaba Osztrogonác [Qt] Unreviewed 64 bit buildfix after r121925. * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): 2012-07-05 Michael Saboff JSString::tryHashConstLock() fails to get exclusive lock https://bugs.webkit.org/show_bug.cgi?id=90639 Reviewed by Oliver Hunt. Added check that the string is already locked even before compare and swap. * heap/MarkStack.cpp: (JSC::JSString::tryHashConstLock): 2012-07-04 Filip Pizlo Inline property storage should not be wasted when it is exhausted https://bugs.webkit.org/show_bug.cgi?id=90347 Reviewed by Gavin Barraclough. Previously, if we switched an object from using inline storage to out-of-line storage, we would abandon the inline storage. This would have two main implications: (i) all accesses to the object, even for properties that were previously in inline storage, must now take an extra indirection; and (ii) we waste a non-trivial amount of space since we must allocate additional out-of-line storage to hold properties that would have fit in the inline storage. There's also the copying cost when switching to out-of-line storage - we must copy all inline properties into ouf-of-line storage. This patch changes the way that object property storage works so that we can use both inline and out-of-line storage concurrently. This is accomplished by introducing a new notion of property offset. This PropertyOffset is a 32-bit signed integer and it behaves as follows: offset == -1: invalid offset, indicating a property that does not exist. 0 <= offset <= inlineStorageCapacity: offset into inline storage. inlineStorageCapacity < offset: offset into out-of-line storage. Because non-final objects don't have inline storage, the only valid PropertyOffsets for those objects' properties are -1 or > inlineStorageCapacity. This now means that the decision to use inline or out-of-line storage for an access is made based on the offset, rather than the structure. It also means that any access where the offset is a variable must have an extra branch, unless the type of the object is also known (if it's known to be a non-final object then we can just assert that the offset is >= inlineStorageCapacity). This looks like a big Kraken speed-up and a slight V8 speed-up. * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARMv7Assembler.h: (ARMv7Assembler): (JSC::ARMv7Assembler::ldrWide8BitImmediate): (JSC::ARMv7Assembler::replaceWithLoad): (JSC::ARMv7Assembler::replaceWithAddressComputation): * assembler/AbstractMacroAssembler.h: (AbstractMacroAssembler): (ConvertibleLoadLabel): (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel): (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::isSet): (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints): (JSC::AbstractMacroAssembler::replaceWithLoad): (JSC::AbstractMacroAssembler::replaceWithAddressComputation): * assembler/CodeLocation.h: (JSC): (CodeLocationCommon): (CodeLocationConvertibleLoad): (JSC::CodeLocationConvertibleLoad::CodeLocationConvertibleLoad): (JSC::CodeLocationCommon::convertibleLoadAtOffset): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * assembler/LinkBuffer.h: (LinkBuffer): (JSC::LinkBuffer::locationOf): * assembler/MacroAssemblerARMv7.h: (MacroAssemblerARMv7): (JSC::MacroAssemblerARMv7::convertibleLoadPtr): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::convertibleLoadPtr): (MacroAssemblerX86): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::convertibleLoadPtr): (MacroAssemblerX86_64): * assembler/RepatchBuffer.h: (RepatchBuffer): (JSC::RepatchBuffer::replaceWithLoad): (JSC::RepatchBuffer::replaceWithAddressComputation): (JSC::RepatchBuffer::setLoadInstructionIsActive): * assembler/X86Assembler.h: (JSC::X86Assembler::replaceWithLoad): (X86Assembler): (JSC::X86Assembler::replaceWithAddressComputation): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printGetByIdOp): (JSC::CodeBlock::dump): (JSC::CodeBlock::finalizeUnconditionally): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::GetByIdStatus): (JSC::GetByIdStatus::offset): (GetByIdStatus): * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * bytecode/PutByIdStatus.h: (JSC::PutByIdStatus::PutByIdStatus): (JSC::PutByIdStatus::offset): (PutByIdStatus): * bytecode/ResolveGlobalStatus.cpp: (JSC): (JSC::computeForStructure): * bytecode/ResolveGlobalStatus.h: (JSC::ResolveGlobalStatus::ResolveGlobalStatus): (JSC::ResolveGlobalStatus::offset): (ResolveGlobalStatus): * bytecode/StructureSet.h: (StructureSet): * bytecode/StructureStubInfo.h: * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::handleGetByOffset): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord): (PropertyAccessRecord): * dfg/DFGRepatch.cpp: (JSC::DFG::dfgRepatchByIdSelfAccess): (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::tryBuildGetByIDProtoList): (JSC::DFG::emitPutReplaceStub): (JSC::DFG::emitPutTransitionStub): (JSC::DFG::tryCachePutByID): (JSC::DFG::tryBuildPutByIdList): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compile): * heap/MarkStack.cpp: (JSC::visitChildren): * interpreter/Interpreter.cpp: (JSC::Interpreter::tryCacheGetByID): (JSC::Interpreter::privateExecute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::PropertyStubCompilationInfo::copyToStubInfo): * jit/JIT.h: (JSC::PropertyStubCompilationInfo::PropertyStubCompilationInfo): (JSC::JIT::compileGetByIdProto): (JSC::JIT::compileGetByIdSelfList): (JSC::JIT::compileGetByIdProtoList): (JSC::JIT::compileGetByIdChainList): (JSC::JIT::compileGetByIdChain): (JSC::JIT::compilePutByIdTransition): (JIT): * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_resolve_global): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_resolve_global): * jit/JITPropertyAccess.cpp: (JSC::JIT::compileGetDirectOffset): (JSC::JIT::emit_op_method_check): (JSC::JIT::compileGetByIdHotPath): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::compilePutDirectOffset): (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::patchGetByIdSelf): (JSC::JIT::patchPutByIdReplace): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_method_check): (JSC::JIT::compileGetByIdHotPath): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::compilePutDirectOffset): (JSC::JIT::compileGetDirectOffset): (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::patchGetByIdSelf): (JSC::JIT::patchPutByIdReplace): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): (JSC::JIT::emit_op_get_by_pname): * jit/JITStubs.cpp: (JSC::JITThunks::tryCacheGetByID): (JSC::DEFINE_STUB_FUNCTION): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/x86.rb: * runtime/JSGlobalObject.h: (JSGlobalObject): (JSC::JSGlobalObject::functionNameOffset): * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC): (JSC::JSFinalObject::visitChildren): (JSC::JSObject::put): (JSC::JSObject::deleteProperty): (JSC::JSObject::getPropertySpecificValue): (JSC::JSObject::removeDirect): (JSC::JSObject::growOutOfLineStorage): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSObject): (JSC::JSObject::getDirect): (JSC::JSObject::getDirectLocation): (JSC::JSObject::hasInlineStorage): (JSC::JSObject::inlineStorageUnsafe): (JSC::JSObject::inlineStorage): (JSC::JSObject::outOfLineStorage): (JSC::JSObject::locationForOffset): (JSC::JSObject::offsetForLocation): (JSC::JSObject::getDirectOffset): (JSC::JSObject::putDirectOffset): (JSC::JSObject::putUndefinedAtDirectOffset): (JSC::JSObject::addressOfOutOfLineStorage): (JSC::JSObject::finishCreation): (JSC::JSNonFinalObject::JSNonFinalObject): (JSC::JSNonFinalObject::finishCreation): (JSFinalObject): (JSC::JSFinalObject::finishCreation): (JSC::JSFinalObject::JSFinalObject): (JSC::JSObject::offsetOfOutOfLineStorage): (JSC::JSObject::setOutOfLineStorage): (JSC::JSObject::JSObject): (JSC): (JSC::JSCell::fastGetOwnProperty): (JSC::JSObject::putDirectInternal): (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): (JSC::JSObject::putDirectWithoutTransition): (JSC::offsetRelativeToPatchedStorage): (JSC::indexRelativeToBase): (JSC::offsetRelativeToBase): * runtime/JSPropertyNameIterator.cpp: (JSC::JSPropertyNameIterator::create): * runtime/JSPropertyNameIterator.h: (JSPropertyNameIterator): (JSC::JSPropertyNameIterator::getOffset): (JSC::JSPropertyNameIterator::finishCreation): * runtime/JSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/Operations.h: (JSC::normalizePrototypeChain): * runtime/Options.cpp: (JSC): (JSC::Options::initialize): * runtime/PropertyMapHashTable.h: (PropertyMapEntry): (JSC::PropertyMapEntry::PropertyMapEntry): (PropertyTable): (JSC::PropertyTable::PropertyTable): (JSC::PropertyTable::getDeletedOffset): (JSC::PropertyTable::addDeletedOffset): (JSC::PropertyTable::nextOffset): (JSC): (JSC::PropertyTable::sizeInMemory): * runtime/PropertyOffset.h: Added. (JSC): (JSC::checkOffset): (JSC::validateOffset): (JSC::isValidOffset): (JSC::isInlineOffset): (JSC::isOutOfLineOffset): (JSC::offsetInInlineStorage): (JSC::offsetInOutOfLineStorage): (JSC::offsetInRespectiveStorage): (JSC::numberOfOutOfLineSlotsForLastOffset): (JSC::numberOfSlotsForLastOffset): (JSC::nextPropertyOffsetFor): (JSC::firstPropertyOffsetFor): * runtime/PropertySlot.h: (JSC::PropertySlot::cachedOffset): (JSC::PropertySlot::setValue): (JSC::PropertySlot::setCacheableGetterSlot): (JSC::PropertySlot::clearOffset): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::setExistingProperty): (JSC::PutPropertySlot::setNewProperty): (JSC::PutPropertySlot::cachedOffset): (PutPropertySlot): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::materializePropertyMap): (JSC::nextOutOfLineStorageCapacity): (JSC::Structure::growOutOfLineCapacity): (JSC::Structure::suggestedNewOutOfLineStorageCapacity): (JSC::Structure::addPropertyTransitionToExistingStructure): (JSC::Structure::addPropertyTransition): (JSC::Structure::removePropertyTransition): (JSC::Structure::flattenDictionaryStructure): (JSC::Structure::addPropertyWithoutTransition): (JSC::Structure::removePropertyWithoutTransition): (JSC::Structure::copyPropertyTableForPinning): (JSC::Structure::get): (JSC::Structure::putSpecificValue): (JSC::Structure::remove): * runtime/Structure.h: (Structure): (JSC::Structure::putWillGrowOutOfLineStorage): (JSC::Structure::previousID): (JSC::Structure::outOfLineCapacity): (JSC::Structure::outOfLineSizeForKnownFinalObject): (JSC::Structure::outOfLineSizeForKnownNonFinalObject): (JSC::Structure::outOfLineSize): (JSC::Structure::hasInlineStorage): (JSC::Structure::inlineCapacity): (JSC::Structure::inlineSizeForKnownFinalObject): (JSC::Structure::inlineSize): (JSC::Structure::totalStorageSize): (JSC::Structure::totalStorageCapacity): (JSC::Structure::firstValidOffset): (JSC::Structure::lastValidOffset): (JSC::Structure::isValidOffset): (JSC::Structure::isEmpty): (JSC::Structure::transitionCount): (JSC::Structure::get): 2012-07-05 Oliver Hunt JSObjectCallAsFunction should thisConvert the provided thisObject https://bugs.webkit.org/show_bug.cgi?id=90628 Reviewed by Gavin Barraclough. Perform this conversion on the provided this object. * API/JSObjectRef.cpp: (JSObjectCallAsFunction): 2012-07-05 Zoltan Herczeg [Qt] Unreviewed buildfix after r121886. Typo fix. * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): 2012-07-05 Zoltan Herczeg Port DFG JIT to traditional ARM https://bugs.webkit.org/show_bug.cgi?id=90198 Reviewed by Filip Pizlo. This patch contains the macro assembler part of the DFG JIT support on ARM systems with fixed 32 bit instruction width. A large amount of old code was refactored, and the ARMv4 or lower support is removed from the macro assembler. Sunspider is improved by 8%, and V8 is 92%. * assembler/ARMAssembler.cpp: (JSC::ARMAssembler::dataTransfer32): (JSC::ARMAssembler::baseIndexTransfer32): (JSC): (JSC::ARMAssembler::dataTransfer16): (JSC::ARMAssembler::baseIndexTransfer16): (JSC::ARMAssembler::dataTransferFloat): (JSC::ARMAssembler::baseIndexTransferFloat): (JSC::ARMAssembler::executableCopy): * assembler/ARMAssembler.h: (JSC::ARMAssembler::ARMAssembler): (JSC::ARMAssembler::emitInst): (JSC::ARMAssembler::vmov_f64_r): (ARMAssembler): (JSC::ARMAssembler::vabs_f64_r): (JSC::ARMAssembler::vneg_f64_r): (JSC::ARMAssembler::ldr_imm): (JSC::ARMAssembler::ldr_un_imm): (JSC::ARMAssembler::dtr_u): (JSC::ARMAssembler::dtr_ur): (JSC::ARMAssembler::dtr_d): (JSC::ARMAssembler::dtr_dr): (JSC::ARMAssembler::dtrh_u): (JSC::ARMAssembler::dtrh_ur): (JSC::ARMAssembler::dtrh_d): (JSC::ARMAssembler::dtrh_dr): (JSC::ARMAssembler::fdtr_u): (JSC::ARMAssembler::fdtr_d): (JSC::ARMAssembler::push_r): (JSC::ARMAssembler::pop_r): (JSC::ARMAssembler::poke_r): (JSC::ARMAssembler::peek_r): (JSC::ARMAssembler::vmov_vfp64_r): (JSC::ARMAssembler::vmov_arm64_r): (JSC::ARMAssembler::vmov_vfp32_r): (JSC::ARMAssembler::vmov_arm32_r): (JSC::ARMAssembler::vcvt_u32_f64_r): (JSC::ARMAssembler::vcvt_f64_f32_r): (JSC::ARMAssembler::vcvt_f32_f64_r): (JSC::ARMAssembler::clz_r): (JSC::ARMAssembler::bkpt): (JSC::ARMAssembler::bx): (JSC::ARMAssembler::blx): (JSC::ARMAssembler::labelIgnoringWatchpoints): (JSC::ARMAssembler::labelForWatchpoint): (JSC::ARMAssembler::label): (JSC::ARMAssembler::getLdrImmAddress): (JSC::ARMAssembler::replaceWithJump): (JSC::ARMAssembler::maxJumpReplacementSize): (JSC::ARMAssembler::getOp2Byte): (JSC::ARMAssembler::getOp2Half): (JSC::ARMAssembler::RM): (JSC::ARMAssembler::RS): (JSC::ARMAssembler::RD): (JSC::ARMAssembler::RN): * assembler/AssemblerBufferWithConstantPool.h: (JSC::AssemblerBufferWithConstantPool::ensureSpaceForAnyInstruction): * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::add32): (MacroAssemblerARM): (JSC::MacroAssemblerARM::and32): (JSC::MacroAssemblerARM::lshift32): (JSC::MacroAssemblerARM::mul32): (JSC::MacroAssemblerARM::neg32): (JSC::MacroAssemblerARM::rshift32): (JSC::MacroAssemblerARM::urshift32): (JSC::MacroAssemblerARM::xor32): (JSC::MacroAssemblerARM::load8): (JSC::MacroAssemblerARM::load8Signed): (JSC::MacroAssemblerARM::load16): (JSC::MacroAssemblerARM::load16Signed): (JSC::MacroAssemblerARM::load32): (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch): (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch): (JSC::MacroAssemblerARM::store8): (JSC::MacroAssemblerARM::store16): (JSC::MacroAssemblerARM::store32): (JSC::MacroAssemblerARM::move): (JSC::MacroAssemblerARM::jump): (JSC::MacroAssemblerARM::branchAdd32): (JSC::MacroAssemblerARM::mull32): (JSC::MacroAssemblerARM::branchMul32): (JSC::MacroAssemblerARM::nearCall): (JSC::MacroAssemblerARM::compare32): (JSC::MacroAssemblerARM::test32): (JSC::MacroAssemblerARM::sub32): (JSC::MacroAssemblerARM::call): (JSC::MacroAssemblerARM::loadFloat): (JSC::MacroAssemblerARM::loadDouble): (JSC::MacroAssemblerARM::storeFloat): (JSC::MacroAssemblerARM::storeDouble): (JSC::MacroAssemblerARM::moveDouble): (JSC::MacroAssemblerARM::addDouble): (JSC::MacroAssemblerARM::divDouble): (JSC::MacroAssemblerARM::subDouble): (JSC::MacroAssemblerARM::mulDouble): (JSC::MacroAssemblerARM::absDouble): (JSC::MacroAssemblerARM::negateDouble): (JSC::MacroAssemblerARM::convertInt32ToDouble): (JSC::MacroAssemblerARM::convertFloatToDouble): (JSC::MacroAssemblerARM::convertDoubleToFloat): (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): (JSC::MacroAssemblerARM::truncateDoubleToInt32): (JSC::MacroAssemblerARM::truncateDoubleToUint32): (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): (JSC::MacroAssemblerARM::branchDoubleNonZero): (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN): (JSC::MacroAssemblerARM::invert): (JSC::MacroAssemblerARM::replaceWithJump): (JSC::MacroAssemblerARM::maxJumpReplacementSize): (JSC::MacroAssemblerARM::call32): * assembler/SH4Assembler.h: (JSC::SH4Assembler::label): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::debugCall): (JSC::DFG::AssemblyHelpers::boxDouble): (JSC::DFG::AssemblyHelpers::unboxDouble): * dfg/DFGCCallHelpers.h: (CCallHelpers): (JSC::DFG::CCallHelpers::setupArguments): * dfg/DFGFPRInfo.h: (DFG): * dfg/DFGGPRInfo.h: (DFG): (GPRInfo): * dfg/DFGOperations.cpp: (JSC): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): (JSC::DFG::SpeculativeJIT::appendCallSetResult): * jit/JITStubs.cpp: (JSC): * jit/JITStubs.h: (JITStackFrame): * jit/JSInterfaceJIT.h: (JSInterfaceJIT): 2012-07-04 Anthony Scian Web Inspector [JSC]: Implement ScriptCallStack::stackTrace https://bugs.webkit.org/show_bug.cgi?id=40118 Reviewed by Yong Li. Added member functions to expose function name, urlString, and line #. Refactored toString to make use of these member functions to reduce duplicated code for future maintenance. Manually tested refactoring of toString by tracing thrown exceptions. * interpreter/Interpreter.h: (JSC::StackFrame::toString): (JSC::StackFrame::friendlySourceURL): (JSC::StackFrame::friendlyFunctionName): (JSC::StackFrame::friendlyLineNumber): 2012-07-04 Andy Wingo [GTK] Enable parallel GC https://bugs.webkit.org/show_bug.cgi?id=90568 Reviewed by Martin Robinson. * runtime/Options.cpp: Include for std::min. 2012-07-04 John Mellor Text Autosizing: Add compile flag and runtime setting https://bugs.webkit.org/show_bug.cgi?id=87394 This patch renames Font Boosting to Text Autosizing. Reviewed by Adam Barth. * Configurations/FeatureDefines.xcconfig: 2012-07-03 Michael Saboff Enh: Hash Const JSString in Backing Stores to Save Memory https://bugs.webkit.org/show_bug.cgi?id=86024 Reviewed by Oliver Hunt. During garbage collection, each marking thread keeps a HashMap of strings. While visiting via MarkStack::copyAndAppend(), we check to see if the string we are visiting is already in the HashMap. If not we add it. If so, we change the reference to the current string we're visiting to the prior string. To reduce the performance impact of this change, two throttles have ben added. 1) We only try hash consting if a significant number of new strings have been created since the last hash const. Currently this is set at 100 strings. 2) If a string is unique at the end of a marking it will not be checked during further GC phases. In some cases this won't catch all duplicates, but we are trying to catch the growth of duplicate strings. * heap/Heap.cpp: (JSC::Heap::markRoots): * heap/MarkStack.cpp: (JSC::MarkStackThreadSharedData::resetChildren): (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): (JSC::MarkStackThreadSharedData::reset): (JSC::MarkStack::setup): Check to see if enough strings have been created to hash const. (JSC::MarkStack::reset): Added call to clear m_uniqueStrings. (JSC::JSString::tryHashConstLock): New method to lock JSString for hash consting. (JSC::JSString::releaseHashConstLock): New unlock method. (JSC::JSString::shouldTryHashConst): Set of checks to see if we should try to hash const the string. (JSC::MarkStack::internalAppend): New method that performs the hash consting. (JSC::SlotVisitor::copyAndAppend): Changed to call the new hash consting internalAppend(). * heap/MarkStack.h: (MarkStackThreadSharedData): (MarkStack): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): * runtime/JSGlobalData.h: (JSGlobalData): (JSC::JSGlobalData::haveEnoughNewStringsToHashConst): (JSC::JSGlobalData::resetNewStringsSinceLastHashConst): * runtime/JSString.h: (JSString): Changed from using bool flags to using an unsigned m_flags field. This works better with the weakCompareAndSwap in JSString::tryHashConstLock(). Changed the 8bitness setting and checking to use new accessors. (JSC::JSString::JSString): (JSC::JSString::finishCreation): (JSC::JSString::is8Bit): Updated for new m_flags. (JSC::JSString::setIs8Bit): New setter. New hash const flags accessors: (JSC::JSString::isHashConstSingleton): (JSC::JSString::clearHashConstSingleton): (JSC::JSString::setHashConstSingleton): (JSC::JSRopeString::finishCreation): (JSC::JSRopeString::append): 2012-07-03 Tony Chang [chromium] Unreviewed, update .gitignore to handle VS2010 files. * JavaScriptCore.gyp/.gitignore: 2012-07-03 Mark Lam Add ability to symbolically set and dump JSC VM options. See comments in runtime/Options.h for details on how the options work. https://bugs.webkit.org/show_bug.cgi?id=90420 Reviewed by Filip Pizlo. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * assembler/LinkBuffer.h: (JSC): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shouldOptimizeNow): * bytecode/CodeBlock.h: (JSC::CodeBlock::likelyToTakeSlowCase): (JSC::CodeBlock::couldTakeSlowCase): (JSC::CodeBlock::likelyToTakeSpecialFastCase): (JSC::CodeBlock::likelyToTakeDeepestSlowCase): (JSC::CodeBlock::likelyToTakeAnySlowCase): (JSC::CodeBlock::jitAfterWarmUp): (JSC::CodeBlock::jitSoon): (JSC::CodeBlock::reoptimizationRetryCounter): (JSC::CodeBlock::countReoptimization): (JSC::CodeBlock::counterValueForOptimizeAfterWarmUp): (JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp): (JSC::CodeBlock::optimizeSoon): (JSC::CodeBlock::exitCountThresholdForReoptimization): (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::clippedThreshold): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): * dfg/DFGCapabilities.h: (JSC::DFG::mightCompileEval): (JSC::DFG::mightCompileProgram): (JSC::DFG::mightCompileFunctionForCall): (JSC::DFG::mightCompileFunctionForConstruct): (JSC::DFG::mightInlineFunctionForCall): (JSC::DFG::mightInlineFunctionForConstruct): * dfg/DFGCommon.h: (JSC::DFG::shouldShowDisassembly): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): * heap/MarkStack.cpp: (JSC::MarkStackSegmentAllocator::allocate): (JSC::MarkStackSegmentAllocator::shrinkReserve): (JSC::MarkStackArray::MarkStackArray): (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): (JSC::SlotVisitor::donateKnownParallel): (JSC::SlotVisitor::drain): (JSC::SlotVisitor::drainFromShared): * heap/MarkStack.h: (JSC::MarkStack::mergeOpaqueRootsIfProfitable): (JSC::MarkStack::addOpaqueRoot): * heap/SlotVisitor.h: (JSC::SlotVisitor::donate): * jit/JIT.cpp: (JSC::JIT::emitOptimizationCheck): * jsc.cpp: (printUsageStatement): (parseArguments): * runtime/InitializeThreading.cpp: (JSC::initializeThreadingOnce): * runtime/JSGlobalData.cpp: (JSC::enableAssembler): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): * runtime/Options.cpp: (JSC): (JSC::overrideOptionWithHeuristic): (JSC::Options::initialize): (JSC::Options::setOption): (JSC::Options::dumpAllOptions): (JSC::Options::dumpOption): * runtime/Options.h: (JSC): (Options): (EntryInfo): 2012-07-03 Jocelyn Turcotte Joel Dillon [Qt][Win] Fix broken QtWebKit5.lib linking https://bugs.webkit.org/show_bug.cgi?id=88321 Reviewed by Kenneth Rohde Christiansen. The goal is to have different ports build systems define STATICALLY_LINKED_WITH_WTF when building JavaScriptCore, if both are packaged in the same DLL, instead of relying on the code to handle this. The effects of BUILDING_* and STATICALLY_LINKED_WITH_* are currently the same except for a check in Source/JavaScriptCore/config.h. Keeping the old way for the WX port as requested by the port's contributors. For non-Windows ports there is no difference between IMPORT and EXPORT, no change is needed. * API/JSBase.h: JS symbols shouldn't be included by WTF objects anymore. Remove the export when BUILDING_WTF. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: Make sure that JavaScriptCore uses import symbols of WTF for the Win port. * runtime/JSExportMacros.h: 2012-07-02 Filip Pizlo DFG OSR exit value recoveries should be computed lazily https://bugs.webkit.org/show_bug.cgi?id=82155 Reviewed by Gavin Barraclough. This change aims to reduce one aspect of DFG compile times: the fact that we currently compute the value recoveries for each local and argument on every speculation check. We compile many speculation checks, so this can add up quick. The strategy that this change takes is to have the DFG save just enough information about how the compiler is choosing to represent state, that the DFG::OSRExitCompiler can reify the value recoveries lazily. This appears to be an 0.3% SunSpider speed-up and is neutral elsewhere. I also took the opportunity to fix the sampling regions profiler (it was missing an export macro) and to put in more sampling regions in the DFG (which are disabled so long as ENABLE(SAMPLING_REGIONS) is false). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::shrinkDFGDataToFit): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::minifiedDFG): (JSC::CodeBlock::variableEventStream): (DFGData): * bytecode/Operands.h: (JSC::Operands::hasOperand): (Operands): (JSC::Operands::size): (JSC::Operands::at): (JSC::Operands::operator[]): (JSC::Operands::isArgument): (JSC::Operands::isVariable): (JSC::Operands::argumentForIndex): (JSC::Operands::variableForIndex): (JSC::Operands::operandForIndex): (JSC): (JSC::dumpOperands): * bytecode/SamplingTool.h: (SamplingRegion): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::parse): * dfg/DFGCFAPhase.cpp: (JSC::DFG::performCFA): * dfg/DFGCSEPhase.cpp: (JSC::DFG::performCSE): * dfg/DFGFixupPhase.cpp: (JSC::DFG::performFixup): * dfg/DFGGenerationInfo.h: (JSC::DFG::GenerationInfo::GenerationInfo): (JSC::DFG::GenerationInfo::initConstant): (JSC::DFG::GenerationInfo::initInteger): (JSC::DFG::GenerationInfo::initJSValue): (JSC::DFG::GenerationInfo::initCell): (JSC::DFG::GenerationInfo::initBoolean): (JSC::DFG::GenerationInfo::initDouble): (JSC::DFG::GenerationInfo::initStorage): (GenerationInfo): (JSC::DFG::GenerationInfo::noticeOSRBirth): (JSC::DFG::GenerationInfo::use): (JSC::DFG::GenerationInfo::spill): (JSC::DFG::GenerationInfo::setSpilled): (JSC::DFG::GenerationInfo::fillJSValue): (JSC::DFG::GenerationInfo::fillCell): (JSC::DFG::GenerationInfo::fillInteger): (JSC::DFG::GenerationInfo::fillBoolean): (JSC::DFG::GenerationInfo::fillDouble): (JSC::DFG::GenerationInfo::fillStorage): (JSC::DFG::GenerationInfo::appendFill): (JSC::DFG::GenerationInfo::appendSpill): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGMinifiedGraph.h: Added. (DFG): (MinifiedGraph): (JSC::DFG::MinifiedGraph::MinifiedGraph): (JSC::DFG::MinifiedGraph::at): (JSC::DFG::MinifiedGraph::append): (JSC::DFG::MinifiedGraph::prepareAndShrink): (JSC::DFG::MinifiedGraph::setOriginalGraphSize): (JSC::DFG::MinifiedGraph::originalGraphSize): * dfg/DFGMinifiedNode.cpp: Added. (DFG): (JSC::DFG::MinifiedNode::fromNode): * dfg/DFGMinifiedNode.h: Added. (DFG): (JSC::DFG::belongsInMinifiedGraph): (MinifiedNode): (JSC::DFG::MinifiedNode::MinifiedNode): (JSC::DFG::MinifiedNode::index): (JSC::DFG::MinifiedNode::op): (JSC::DFG::MinifiedNode::hasChild1): (JSC::DFG::MinifiedNode::child1): (JSC::DFG::MinifiedNode::hasConstant): (JSC::DFG::MinifiedNode::hasConstantNumber): (JSC::DFG::MinifiedNode::constantNumber): (JSC::DFG::MinifiedNode::hasWeakConstant): (JSC::DFG::MinifiedNode::weakConstant): (JSC::DFG::MinifiedNode::getIndex): (JSC::DFG::MinifiedNode::compareByNodeIndex): (JSC::DFG::MinifiedNode::hasChild): * dfg/DFGNode.h: (Node): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: (OSRExitCompiler): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::performPredictionPropagation): * dfg/DFGRedundantPhiEliminationPhase.cpp: (JSC::DFG::performRedundantPhiElimination): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (DFG): (JSC::DFG::SpeculativeJIT::fillStorage): (JSC::DFG::SpeculativeJIT::noticeOSRBirth): (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT.h: (DFG): (JSC::DFG::SpeculativeJIT::use): (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::spill): (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillInteger): (JSC::DFG::SpeculativeJIT::fillDouble): (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillInteger): (JSC::DFG::SpeculativeJIT::fillDouble): (JSC::DFG::SpeculativeJIT::fillJSValue): (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueRecoveryOverride.h: Added. (DFG): (ValueRecoveryOverride): (JSC::DFG::ValueRecoveryOverride::ValueRecoveryOverride): * dfg/DFGValueSource.cpp: Added. (DFG): (JSC::DFG::ValueSource::dump): * dfg/DFGValueSource.h: Added. (DFG): (JSC::DFG::dataFormatToValueSourceKind): (JSC::DFG::valueSourceKindToDataFormat): (JSC::DFG::isInRegisterFile): (ValueSource): (JSC::DFG::ValueSource::ValueSource): (JSC::DFG::ValueSource::forPrediction): (JSC::DFG::ValueSource::forDataFormat): (JSC::DFG::ValueSource::isSet): (JSC::DFG::ValueSource::kind): (JSC::DFG::ValueSource::isInRegisterFile): (JSC::DFG::ValueSource::dataFormat): (JSC::DFG::ValueSource::valueRecovery): (JSC::DFG::ValueSource::nodeIndex): (JSC::DFG::ValueSource::nodeIndexFromKind): (JSC::DFG::ValueSource::kindFromNodeIndex): * dfg/DFGVariableEvent.cpp: Added. (DFG): (JSC::DFG::VariableEvent::dump): (JSC::DFG::VariableEvent::dumpFillInfo): (JSC::DFG::VariableEvent::dumpSpillInfo): * dfg/DFGVariableEvent.h: Added. (DFG): (VariableEvent): (JSC::DFG::VariableEvent::VariableEvent): (JSC::DFG::VariableEvent::reset): (JSC::DFG::VariableEvent::fillGPR): (JSC::DFG::VariableEvent::fillPair): (JSC::DFG::VariableEvent::fillFPR): (JSC::DFG::VariableEvent::spill): (JSC::DFG::VariableEvent::death): (JSC::DFG::VariableEvent::setLocal): (JSC::DFG::VariableEvent::movHint): (JSC::DFG::VariableEvent::kind): (JSC::DFG::VariableEvent::nodeIndex): (JSC::DFG::VariableEvent::dataFormat): (JSC::DFG::VariableEvent::gpr): (JSC::DFG::VariableEvent::tagGPR): (JSC::DFG::VariableEvent::payloadGPR): (JSC::DFG::VariableEvent::fpr): (JSC::DFG::VariableEvent::virtualRegister): (JSC::DFG::VariableEvent::operand): (JSC::DFG::VariableEvent::variableRepresentation): * dfg/DFGVariableEventStream.cpp: Added. (DFG): (JSC::DFG::VariableEventStream::logEvent): (MinifiedGenerationInfo): (JSC::DFG::MinifiedGenerationInfo::MinifiedGenerationInfo): (JSC::DFG::MinifiedGenerationInfo::update): (JSC::DFG::VariableEventStream::reconstruct): * dfg/DFGVariableEventStream.h: Added. (DFG): (VariableEventStream): (JSC::DFG::VariableEventStream::appendAndLog): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::performVirtualRegisterAllocation): 2012-07-02 Filip Pizlo DFG::ArgumentsSimplificationPhase should assert that the PhantomArguments nodes it creates are not shouldGenerate() https://bugs.webkit.org/show_bug.cgi?id=90407 Reviewed by Mark Hahnenberg. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): 2012-07-02 Gavin Barraclough Array.prototype.pop should throw if property is not configurable https://bugs.webkit.org/show_bug.cgi?id=75788 Rubber Stamped by Oliver Hunt. No real bug here any more, but the error we throw sometimes has a misleading message. * runtime/JSArray.cpp: (JSC::JSArray::pop): 2012-06-29 Filip Pizlo JSObject wastes too much memory on unused property slots https://bugs.webkit.org/show_bug.cgi?id=90255 Reviewed by Mark Hahnenberg. Rolling back in after applying a simple fix: it appears that JSObject::setStructureAndReallocateStorageIfNecessary() was allocating more property storage than necessary. Fixing this appears to resolve the crash. This does a few things: - JSNonFinalObject no longer has inline property storage. - Initial out-of-line property storage size is 4 slots for JSNonFinalObject, or 2x the inline storage for JSFinalObject. - Property storage is only reallocated if it needs to be. Previously, we would reallocate the property storage on any transition where the original structure said shouldGrowProperyStorage(), but this led to spurious reallocations when doing transitionless property adds and there are deleted property slots available. That in turn led to crashes, because we would switch to out-of-line storage even if the capacity matched the criteria for inline storage. - Inline JSFunction allocation is killed off because we don't have a good way of inlining property storage allocation. This didn't hurt performance. Killing off code is better than fixing it if that code wasn't doing any good. This looks like a 1% progression on V8. * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): (JSC): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_func): (JSC): (JSC::JIT::emit_op_new_func_exp): * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): * runtime/JSObject.h: (JSC::JSObject::isUsingInlineStorage): (JSObject): (JSC::JSObject::finishCreation): (JSC): (JSC::JSNonFinalObject::hasInlineStorage): (JSNonFinalObject): (JSC::JSNonFinalObject::JSNonFinalObject): (JSC::JSNonFinalObject::finishCreation): (JSC::JSFinalObject::hasInlineStorage): (JSC::JSFinalObject::finishCreation): (JSC::JSObject::offsetOfInlineStorage): (JSC::JSObject::setPropertyStorage): (JSC::Structure::inlineStorageCapacity): (JSC::Structure::isUsingInlineStorage): (JSC::JSObject::putDirectInternal): (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): (JSC::JSObject::putDirectWithoutTransition): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::nextPropertyStorageCapacity): (JSC): (JSC::Structure::growPropertyStorageCapacity): (JSC::Structure::suggestedNewPropertyStorageSize): * runtime/Structure.h: (JSC::Structure::putWillGrowPropertyStorage): (Structure): 2012-06-29 Filip Pizlo Webkit crashes in DFG on Google Docs when creating a new document https://bugs.webkit.org/show_bug.cgi?id=90209 Reviewed by Gavin Barraclough. Don't attempt to short-circuit Phantom(GetLocal) if the GetLocal is for a captured variable. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::mergeBlocks): 2012-06-30 Zan Dobersek Unreviewed, rolling out r121605. http://trac.webkit.org/changeset/121605 https://bugs.webkit.org/show_bug.cgi?id=90336 Changes caused flaky crashes in sputnik/Unicode tests on Apple WK1 and GTK Linux builders * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): (JSC::JIT::emitAllocateJSFinalObject): (JSC): (JSC::JIT::emitAllocateJSFunction): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_func): (JSC::JIT::emitSlow_op_new_func): (JSC): (JSC::JIT::emit_op_new_func_exp): (JSC::JIT::emitSlow_op_new_func_exp): * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): * runtime/JSObject.h: (JSC::JSObject::isUsingInlineStorage): (JSObject): (JSC::JSObject::finishCreation): (JSC): (JSNonFinalObject): (JSC::JSNonFinalObject::JSNonFinalObject): (JSC::JSNonFinalObject::finishCreation): (JSFinalObject): (JSC::JSFinalObject::finishCreation): (JSC::JSObject::offsetOfInlineStorage): (JSC::JSObject::setPropertyStorage): (JSC::Structure::isUsingInlineStorage): (JSC::JSObject::putDirectInternal): (JSC::JSObject::putDirectWithoutTransition): (JSC::JSObject::transitionTo): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC): (JSC::Structure::growPropertyStorageCapacity): (JSC::Structure::suggestedNewPropertyStorageSize): * runtime/Structure.h: (JSC::Structure::shouldGrowPropertyStorage): (JSC::Structure::propertyStorageSize): 2012-06-29 Mark Hahnenberg Remove warning about protected values when the Heap is being destroyed https://bugs.webkit.org/show_bug.cgi?id=90302 Reviewed by Geoffrey Garen. Having to do book-keeping about whether values allocated from a certain VM are or are not protected makes the JSC API much more difficult to use correctly. Clients should be able to throw an entire VM away and not have to worry about unprotecting all of the values that they protected earlier. * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): 2012-06-29 Filip Pizlo JSObject wastes too much memory on unused property slots https://bugs.webkit.org/show_bug.cgi?id=90255 Reviewed by Mark Hahnenberg. This does a few things: - JSNonFinalObject no longer has inline property storage. - Initial out-of-line property storage size is 4 slots for JSNonFinalObject, or 2x the inline storage for JSFinalObject. - Property storage is only reallocated if it needs to be. Previously, we would reallocate the property storage on any transition where the original structure said shouldGrowProperyStorage(), but this led to spurious reallocations when doing transitionless property adds and there are deleted property slots available. That in turn led to crashes, because we would switch to out-of-line storage even if the capacity matched the criteria for inline storage. - Inline JSFunction allocation is killed off because we don't have a good way of inlining property storage allocation. This didn't hurt performance. Killing off code is better than fixing it if that code wasn't doing any good. This looks like a 1% progression on V8. * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): (JSC): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_new_func): (JSC): (JSC::JIT::emit_op_new_func_exp): * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): * runtime/JSObject.h: (JSC::JSObject::isUsingInlineStorage): (JSObject): (JSC::JSObject::finishCreation): (JSC): (JSC::JSNonFinalObject::hasInlineStorage): (JSNonFinalObject): (JSC::JSNonFinalObject::JSNonFinalObject): (JSC::JSNonFinalObject::finishCreation): (JSC::JSFinalObject::hasInlineStorage): (JSC::JSFinalObject::finishCreation): (JSC::JSObject::offsetOfInlineStorage): (JSC::JSObject::setPropertyStorage): (JSC::Structure::inlineStorageCapacity): (JSC::Structure::isUsingInlineStorage): (JSC::JSObject::putDirectInternal): (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): (JSC::JSObject::putDirectWithoutTransition): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::nextPropertyStorageCapacity): (JSC): (JSC::Structure::growPropertyStorageCapacity): (JSC::Structure::suggestedNewPropertyStorageSize): * runtime/Structure.h: (JSC::Structure::putWillGrowPropertyStorage): (Structure): 2012-06-28 Filip Pizlo DFG recompilation heuristics should be based on count, not rate https://bugs.webkit.org/show_bug.cgi?id=90146 Reviewed by Oliver Hunt. This removes a bunch of code that was previously trying to prevent spurious reoptimizations if a large enough majority of executions of a code block did not result in OSR exit. It turns out that this code was purely harmful. This patch removes all of that logic and replaces it with a dead-simple heuristic: if you exit more than N times (where N is an exponential function of the number of times the code block has already been recompiled) then we will recompile. This appears to be a broad ~1% win on many benchmarks large and small. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/CodeBlock.h: (JSC::CodeBlock::osrExitCounter): (JSC::CodeBlock::countOSRExit): (CodeBlock): (JSC::CodeBlock::addressOfOSRExitCounter): (JSC::CodeBlock::offsetOfOSRExitCounter): (JSC::CodeBlock::adjustedExitCountThreshold): (JSC::CodeBlock::exitCountThresholdForReoptimization): (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): (JSC::CodeBlock::shouldReoptimizeNow): (JSC::CodeBlock::shouldReoptimizeFromLoopNow): * bytecode/ExecutionCounter.cpp: (JSC::ExecutionCounter::setThreshold): * bytecode/ExecutionCounter.h: (ExecutionCounter): (JSC::ExecutionCounter::clippedThreshold): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExitCompiler::handleExitCounts): * dfg/DFGOperations.cpp: * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * runtime/Options.cpp: (Options): (JSC::Options::initializeOptions): * runtime/Options.h: (Options): 2012-06-28 Mark Lam Adding a commenting utility to record BytecodeGenerator comments with opcodes that are emitted. Presently, the comments can only be constant strings. Adding comments for opcodes is optional. If a comment is added, the comment will be printed following the opcode when CodeBlock::dump() is called. This utility is disabled by default, and is only meant for VM development purposes. It should not be enabled for product builds. To enable this utility, set ENABLE_BYTECODE_COMMENTS in CodeBlock.h to 1. https://bugs.webkit.org/show_bug.cgi?id=90095 Reviewed by Geoffrey Garen. * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): Dumps the comment. (JSC): (JSC::CodeBlock::printUnaryOp): Add comment dumps. (JSC::CodeBlock::printBinaryOp): Add comment dumps. (JSC::CodeBlock::printConditionalJump): Add comment dumps. (JSC::CodeBlock::printCallOp): Add comment dumps. (JSC::CodeBlock::printPutByIdOp): Add comment dumps. (JSC::CodeBlock::dump): Add comment dumps. (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::commentForBytecodeOffset): Finds the comment for an opcode if available. (JSC::CodeBlock::dumpBytecodeComments): For debugging whether comments are collected. It is not being called anywhere. * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::bytecodeComments): * bytecode/Comment.h: Added. (JSC): (Comment): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitOpcode): Calls emitComment(). (JSC): (JSC::BytecodeGenerator::emitComment): Adds comment to CodeBlock. (JSC::BytecodeGenerator::prependComment): Registers a comment for emitComemnt() to use later. * bytecompiler/BytecodeGenerator.h: (BytecodeGenerator): (JSC::BytecodeGenerator::emitComment): (JSC::BytecodeGenerator::prependComment): These are inlined versions of these functions that nullify them when ENABLE_BYTECODE_COMMENTS is 0. (JSC::BytecodeGenerator::comments): 2012-06-28 Oliver Hunt 32bit DFG incorrectly claims an fpr is fillable even if it has not been proven double https://bugs.webkit.org/show_bug.cgi?id=90127 Reviewed by Filip Pizlo. The 32-bit version of fillSpeculateDouble doesn't handle Number->fpr loads correctly. This patch fixes this by killing the fill info in the GenerationInfo when the spillFormat doesn't guarantee the value is a double. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): 2012-06-28 Kent Tamura Classify form control states by their owner forms https://bugs.webkit.org/show_bug.cgi?id=89950 Reviewed by Hajime Morita. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Expose WTF::StringBuilder::canShrink() 2012-06-27 Michael Saboff [Win] jscore-tests flakey https://bugs.webkit.org/show_bug.cgi?id=88118 Reviewed by Jessie Berlin. jsDriver.pl on windows intermittently doesn't get the returned value from jsc, instead it gets 126. Added a new option to jsc (-x) which prints the exit code before exiting. jsDriver.pl uses this option on Windows and parses the exit code output for the exit code, removing it before comparing the actual and expected outputs. Filed a follow on "FIXME" defect: [WIN] Intermittent failure for jsc return value to propagate through jsDriver.pl https://bugs.webkit.org/show_bug.cgi?id=90119 * jsc.cpp: (CommandLine::CommandLine): (CommandLine): (printUsageStatement): (parseArguments): (jscmain): * tests/mozilla/jsDriver.pl: (execute_tests): 2012-06-27 Sheriff Bot Unreviewed, rolling out r121359. http://trac.webkit.org/changeset/121359 https://bugs.webkit.org/show_bug.cgi?id=90115 Broke many inspector tests (Requested by jpfau on #webkit). * interpreter/Interpreter.h: (JSC::StackFrame::toString): 2012-06-27 Filip Pizlo Javascript SHA-512 gives wrong hash on second and subsequent runs unless Web Inspector Javascript Debugging is on https://bugs.webkit.org/show_bug.cgi?id=90053 Reviewed by Mark Hahnenberg. The problem is that the code was assuming that the recovery should be Undefined if the source of the SetLocal was !shouldGenerate(). But that's wrong, since the DFG optimizer may skip around a UInt32ToNumber node (hence making it !shouldGenerate()) and keep the source of that node alive. In that case we should base the recovery on the source of the UInt32ToNumber. The logic for this was already in place but the fast check for !shouldGenerate() broke it. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): 2012-06-27 Filip Pizlo DFG disassembly should be easier to read https://bugs.webkit.org/show_bug.cgi?id=90106 Reviewed by Mark Hahnenberg. Did a few things: - Options::showDFGDisassembly now shows OSR exit disassembly as well. - Phi node dumping doesn't attempt to do line wrapping since it just made the dump harder to read. - DFG graph disassembly view shows a few additional node types that turn out to be essential for understanding OSR exits. Put together, these changes reinforce the philosophy that anything needed for computing OSR exit is just as important as the machine code itself. Of course, we still don't take that philosophy to its full extreme - for example Phantom nodes are not dumped. We may revisit that in the future. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * assembler/LinkBuffer.h: (JSC): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dump): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dumpBlockHeader): * dfg/DFGNode.h: (JSC::DFG::Node::willHaveCodeGenOrOSR): * dfg/DFGOSRExitCompiler.cpp: * jit/JIT.cpp: (JSC::JIT::privateCompile): 2012-06-25 Mark Hahnenberg JSLock should be per-JSGlobalData https://bugs.webkit.org/show_bug.cgi?id=89123 Reviewed by Geoffrey Garen. * API/APIShims.h: (APIEntryShimWithoutLock): (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): Added an extra parameter to the constructor to determine whether we should ref the JSGlobalData or not. We want to ref all the time except for in the HeapTimer class because timerDidFire could run after somebody has started to tear down that particular JSGlobalData, so we wouldn't want to resurrect the ref count of that JSGlobalData from 0 back to 1 after its destruction has begun. (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): (JSC::APIEntryShim::APIEntryShim): (APIEntryShim): (JSC::APIEntryShim::~APIEntryShim): (JSC::APIEntryShim::init): Factored out common initialization code for the various APIEntryShim constructors. Also moved the timeoutChecker stop and start here because we need to start after we've grabbed the API lock and before we've released it, which can only done in APIEntryShim. (JSC::APICallbackShim::~APICallbackShim): We no longer need to synchronize here. * API/JSContextRef.cpp: (JSGlobalContextCreate): (JSGlobalContextCreateInGroup): (JSGlobalContextRelease): (JSContextCreateBacktrace): * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateSlowCase): * heap/Heap.cpp: (JSC::Heap::protect): (JSC::Heap::unprotect): (JSC::Heap::collect): (JSC::Heap::setActivityCallback): (JSC::Heap::activityCallback): (JSC::Heap::sweeper): * heap/Heap.h: Changed m_activityCallback and m_sweeper to be raw pointers rather than OwnPtrs because they are now responsible for their own lifetime. Also changed the order of declaration of the GCActivityCallback and the IncrementalSweeper to make sure they're the last things that get initialized during construction to prevent any issues with uninitialized memory in the JSGlobalData/Heap they might care about. (Heap): * heap/HeapTimer.cpp: Refactored to allow for thread-safe operation and shutdown. (JSC::HeapTimer::~HeapTimer): (JSC::HeapTimer::invalidate): (JSC): (JSC::HeapTimer::didStartVMShutdown): Called at the beginning of ~JSGlobalData. If we're on the same thread that the HeapTimer is running on, we kill the HeapTimer ourselves. If not, then we set some state in the HeapTimer and schedule it to fire immediately so that it can notice and kill itself. (JSC::HeapTimer::timerDidFire): We grab our mutex and check our JSGlobalData pointer. If it has been zero-ed out, then we know the VM has started to shutdown and we should kill ourselves. Otherwise, grab the APIEntryShim, but without ref-ing the JSGlobalData (we don't want to bring the JSGlobalData's ref-count from 0 to 1) in case we were interrupted between releasing our mutex and trying to grab the APILock. * heap/HeapTimer.h: (HeapTimer): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doWork): We no longer need the API shim here since HeapTimer::timerDidFire handles all of that for us. (JSC::IncrementalSweeper::create): * heap/IncrementalSweeper.h: (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::allocateSlowCase): * heap/WeakBlock.cpp: (JSC::WeakBlock::reap): * jsc.cpp: (functionGC): (functionReleaseExecutableMemory): (jscmain): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::evaluate): * runtime/GCActivityCallback.h: (DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::create): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): (JSC::JSGlobalData::~JSGlobalData): Signals to the two HeapTimers (GCActivityCallback and IncrementalSweeper) that the VM has started shutting down. It then waits until the HeapTimer is done with whatever activity it needs to do before continuing with any further destruction. Also asserts that we do not currently hold the APILock because this could potentially cause deadlock when we try to signal to the HeapTimers using their mutexes. (JSC::JSGlobalData::sharedInstance): Protect the initialization for the shared instance with the GlobalJSLock. (JSC::JSGlobalData::sharedInstanceInternal): * runtime/JSGlobalData.h: Change to be ThreadSafeRefCounted so that we don't have to worry about refing and de-refing JSGlobalDatas on separate threads since we don't do it that often anyways. (JSGlobalData): (JSC::JSGlobalData::apiLock): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): (JSC::JSGlobalObject::init): * runtime/JSLock.cpp: (JSC): (JSC::GlobalJSLock::GlobalJSLock): For accessing the shared instance. (JSC::GlobalJSLock::~GlobalJSLock): (JSC::JSLockHolder::JSLockHolder): MutexLocker for JSLock. Also refs the JSGlobalData to keep it alive so that it can successfully unlock it later without it disappearing from underneath it. (JSC::JSLockHolder::~JSLockHolder): (JSC::JSLock::JSLock): (JSC::JSLock::~JSLock): (JSC::JSLock::lock): Uses the spin lock for guarding the lock count and owner thread fields. Uses the mutex for actually waiting for long periods. (JSC::JSLock::unlock): (JSC::JSLock::currentThreadIsHoldingLock): (JSC::JSLock::dropAllLocks): (JSC::JSLock::dropAllLocksUnconditionally): (JSC::JSLock::grabAllLocks): (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): * runtime/JSLock.h: (JSC): (GlobalJSLock): (JSLockHolder): (JSLock): (DropAllLocks): * runtime/WeakGCMap.h: (JSC::WeakGCMap::set): * testRegExp.cpp: (realMain): 2012-06-27 Filip Pizlo x86 disassembler confuses immediates with addresses https://bugs.webkit.org/show_bug.cgi?id=90099 Reviewed by Mark Hahnenberg. Prepend "$" to immediates to disambiguate between immediates and addresses. This is in accordance with the gas and AT&T syntax. * disassembler/udis86/udis86_syn-att.c: (gen_operand): 2012-06-27 Filip Pizlo Add a comment clarifying Options::showDisassembly versus Options::showDFGDisassembly. Rubber stamped by Mark Hahnenberg. * runtime/Options.cpp: (JSC::Options::initializeOptions): 2012-06-27 Anthony Scian Web Inspector [JSC]: Implement ScriptCallStack::stackTrace https://bugs.webkit.org/show_bug.cgi?id=40118 Reviewed by Yong Li. Added member functions to expose function name, urlString, and line #. Refactored toString to make use of these member functions to reduce duplicated code for future maintenance. Manually tested refactoring of toString by tracing thrown exceptions. * interpreter/Interpreter.h: (StackFrame): (JSC::StackFrame::toString): (JSC::StackFrame::friendlySourceURL): (JSC::StackFrame::friendlyFunctionName): (JSC::StackFrame::friendlyLineNumber): 2012-06-27 Oswald Buddenhagen [Qt] Remove redundant c++11 warning suppression code This is already handled in default_post. Reviewed by Tor Arne Vestbø. * Target.pri: 2012-06-26 Tor Arne Vestbø [Qt] Add missing heades to HEADERS For JavaScriptCore there aren't any Qt specific files, so we include all headers for easy editing in Qt Creator. Reviewed by Simon Hausmann. * Target.pri: 2012-06-26 Dominic Cooney [Chromium] Remove unused build scripts and empty folders for JavaScriptCore w/ gyp https://bugs.webkit.org/show_bug.cgi?id=90029 Reviewed by Adam Barth. * gyp: Removed. * gyp/generate-derived-sources.sh: Removed. * gyp/generate-dtrace-header.sh: Removed. * gyp/run-if-exists.sh: Removed. * gyp/update-info-plist.sh: Removed. 2012-06-26 Geoffrey Garen Reduced (but did not eliminate) use of "berzerker GC" https://bugs.webkit.org/show_bug.cgi?id=89237 Reviewed by Gavin Barraclough. (PART 2) This part turns off "berzerker GC" and turns on incremental shrinking. * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): Free or shrink after sweeping to maintain the behavior we used to get from the occasional berzerker GC, which would run all finalizers and then free or shrink all blocks synchronously. * heap/MarkedBlock.h: (JSC::MarkedBlock::needsSweeping): Sweep zapped blocks, too. It's always safe to sweep a zapped block (that's the point of zapping), and it's sometimes profitable. For example, consider this case: Block A does some allocation (transitioning Block A from Marked to FreeListed), then GC happens (transitioning Block A to Zapped), then all objects in Block A are free, then the incremental sweeper visits Block A. If we skipped Zapped blocks, we'd skip Block A, even though it would be profitable to run its destructors and free its memory. * runtime/GCActivityCallback.cpp: (JSC::DefaultGCActivityCallback::doWork): Don't sweep eagerly; we'll do this incrementally. 2012-06-26 Filip Pizlo DFG PutByValAlias is too aggressive https://bugs.webkit.org/show_bug.cgi?id=90026 Reviewed by Gavin Barraclough. For CSE on normal arrays, we now treat PutByVal as impure. This does not appear to affect performance by much. For CSE on typed arrays, we fix PutByValAlias by making GetByVal speculate that the access is within bounds. This also has the effect of making our out-of-bounds handling consistent with WebCore. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGGraph.h: (JSC::DFG::Graph::byValIsPure): (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNodeType.h: (DFG): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): 2012-06-26 Yong Li [BlackBerry] Add JSC statistics into about:memory https://bugs.webkit.org/show_bug.cgi?id=89779 Reviewed by Rob Buis. Fix non-JIT build on BlackBerry broken by r121196. * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): 2012-06-25 Filip Pizlo DFG::operationNewArray is unnecessarily slow, and may use the wrong array prototype when inlined https://bugs.webkit.org/show_bug.cgi?id=89821 Reviewed by Geoffrey Garen. Fixes all array allocations to use the right structure, and hence the right prototype. Adds inlining of new Array(...) with a non-zero number of arguments. Optimizes allocations of empty arrays. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (CCallHelpers): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * runtime/JSArray.h: (JSC): (JSC::constructArray): * runtime/JSGlobalObject.h: (JSC): (JSC::constructArray): 2012-06-26 Filip Pizlo New fast/js/dfg-store-unexpected-value-into-argument-and-osr-exit.html fails on 32 bit https://bugs.webkit.org/show_bug.cgi?id=89953 Reviewed by Zoltan Herczeg. DFG 32-bit JIT was confused about the difference between a predicted type and a proven type. This is easy to get confused about, since a local that is predicted int32 almost always means that the local must be an int32 since speculations are hoisted to stores to locals. But that is less likely to be the case for arguments, where there is an additional least-upper-bounding step: any store to an argument with a weird type may force the argument to be any type. This patch basically duplicates the functionality in DFGSpeculativeJIT64.cpp for GetLocal: the decision of whether to load a local as an int32 (or as an array, or as a boolean) is made based on the AbstractValue::m_type, which is a type proof, rather than the VariableAccessData::prediction(), which is a predicted type. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-06-25 Filip Pizlo JSC should try to make profiling deterministic because otherwise reproducing failures is nearly impossible https://bugs.webkit.org/show_bug.cgi?id=89940 Rubber stamped by Gavin Barraclough. This rolls out the part of http://trac.webkit.org/changeset/121215 that introduced randomness into the system. Now, instead of randomizing the tier-up threshold, we always set it to an artificially low (and statically predetermined!) value. This gives most of the benefit of threshold randomization without actually making the system behave completely differently on each invocation. * bytecode/ExecutionCounter.cpp: (JSC::ExecutionCounter::setThreshold): * runtime/Options.cpp: (Options): (JSC::Options::initializeOptions): * runtime/Options.h: (Options): 2012-06-22 Filip Pizlo Value profiling should use tier-up threshold randomization to get more coverage https://bugs.webkit.org/show_bug.cgi?id=89802 Reviewed by Gavin Barraclough. This patch causes both LLInt and Baseline JIT code to take the OSR slow path several times before actually doing OSR. If we take the OSR slow path before the execution count threshold is reached, then we just call CodeBlock::updateAllPredictions() to compute the current latest least-upper-bound SpecType of all values seen in each ValueProfile. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC): (JSC::CodeBlock::updateAllPredictions): (JSC::CodeBlock::shouldOptimizeNow): * bytecode/CodeBlock.h: (JSC::CodeBlock::llintExecuteCounter): (JSC::CodeBlock::jitExecuteCounter): (CodeBlock): (JSC::CodeBlock::updateAllPredictions): * bytecode/ExecutionCounter.cpp: (JSC::ExecutionCounter::setThreshold): (JSC::ExecutionCounter::status): (JSC): * bytecode/ExecutionCounter.h: (JSC::ExecutionCounter::count): (ExecutionCounter): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC): * runtime/JSGlobalObject.h: (JSGlobalObject): (JSC::JSGlobalObject::weakRandomInteger): * runtime/Options.cpp: (Options): (JSC::Options::initializeOptions): * runtime/Options.h: (Options): * runtime/WeakRandom.h: (WeakRandom): (JSC::WeakRandom::seedUnsafe): 2012-06-25 Yong Li [BlackBerry] Add JSC statistics into about:memory https://bugs.webkit.org/show_bug.cgi?id=89779 Reviewed by Rob Buis. Add MemoryStatistics.cpp into build, and fill JITBytes for BlackBerry port. * PlatformBlackBerry.cmake: * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): 2012-06-23 Sheriff Bot Unreviewed, rolling out r121058. http://trac.webkit.org/changeset/121058 https://bugs.webkit.org/show_bug.cgi?id=89809 Patch causes plugins tests to crash in GTK debug builds (Requested by zdobersek on #webkit). * API/APIShims.h: (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): (APIEntryShimWithoutLock): (JSC::APIEntryShim::APIEntryShim): (APIEntryShim): (JSC::APICallbackShim::~APICallbackShim): * API/JSContextRef.cpp: (JSGlobalContextCreate): (JSGlobalContextCreateInGroup): (JSGlobalContextRelease): (JSContextCreateBacktrace): * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateSlowCase): * heap/Heap.cpp: (JSC::Heap::protect): (JSC::Heap::unprotect): (JSC::Heap::collect): (JSC::Heap::setActivityCallback): (JSC::Heap::activityCallback): (JSC::Heap::sweeper): * heap/Heap.h: (Heap): * heap/HeapTimer.cpp: (JSC::HeapTimer::~HeapTimer): (JSC::HeapTimer::invalidate): (JSC::HeapTimer::timerDidFire): (JSC): * heap/HeapTimer.h: (HeapTimer): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doWork): (JSC::IncrementalSweeper::create): * heap/IncrementalSweeper.h: (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::allocateSlowCase): * heap/WeakBlock.cpp: (JSC::WeakBlock::reap): * jsc.cpp: (functionGC): (functionReleaseExecutableMemory): (jscmain): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::evaluate): * runtime/GCActivityCallback.h: (DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::create): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): (JSC::JSGlobalData::~JSGlobalData): (JSC::JSGlobalData::sharedInstance): (JSC::JSGlobalData::sharedInstanceInternal): * runtime/JSGlobalData.h: (JSGlobalData): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): (JSC::JSGlobalObject::init): * runtime/JSLock.cpp: (JSC): (JSC::createJSLockCount): (JSC::JSLock::lockCount): (JSC::setLockCount): (JSC::JSLock::JSLock): (JSC::JSLock::lock): (JSC::JSLock::unlock): (JSC::JSLock::currentThreadIsHoldingLock): (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): * runtime/JSLock.h: (JSC): (JSLock): (JSC::JSLock::JSLock): (JSC::JSLock::~JSLock): (DropAllLocks): * runtime/WeakGCMap.h: (JSC::WeakGCMap::set): * testRegExp.cpp: (realMain): 2012-06-22 Alexandru Chiculita [CSS Shaders] Re-enable the CSS Shaders compile time flag on Safari Mac https://bugs.webkit.org/show_bug.cgi?id=89781 Reviewed by Dean Jackson. Added ENABLE_CSS_SHADERS flag as enabled by default on Safari for Mac. * Configurations/FeatureDefines.xcconfig: 2012-06-22 Filip Pizlo DFG tier-up should happen in prologues, not epilogues https://bugs.webkit.org/show_bug.cgi?id=89752 Reviewed by Geoffrey Garen. This change has two outcomes: 1) Slightly reduces the likelihood that a function will be optimized both standalone and via inlining. Previously, if you had a call sequence like foo() calls bar() exactly once, and nobody else calls bar(), then bar() would get optimized first (because it returns first) and then foo() gets optimized. If foo() can inline bar() then that means that bar() gets optimized twice. But now, if we optimize in prologues, then foo() will be optimized first. If it inlines bar(), that means that there will no longer be any calls to bar(). 2) It lets us kill some code in JITStubs. Epilogue tier-up was very different from loop tier-up, since epilogue tier-up should not attempt OSR. But prologue tier-up requires OSR (albeit really easy OSR since it's the top of the compilation unit), so it becomes just like loop tier-up. As a result, we now have one optimization hook (cti_optimize) instead of two (cti_optimize_from_loop and cti_optimize_from_ret). As a consequence of not having an optimization check in epilogues, the OSR exit code must now trigger reoptimization itself instead of just signaling the epilogue check to fire. This also adds the ability to count the number of DFG compilations, which was useful for debugging this patch and might be useful for other things in the future. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::reoptimize): (JSC): * bytecode/CodeBlock.h: (CodeBlock): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseCodeBlock): * dfg/DFGDriver.cpp: (DFG): (JSC::DFG::getNumCompilations): (JSC::DFG::compile): * dfg/DFGDriver.h: (DFG): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExitCompiler::handleExitCounts): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * jit/JIT.cpp: (JSC::JIT::emitOptimizationCheck): * jit/JIT.h: * jit/JITCall32_64.cpp: (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_ret_object_or_this): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_ret_object_or_this): (JSC::JIT::emit_op_enter): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): * jit/JITStubs.h: 2012-06-20 Mark Hahnenberg JSLock should be per-JSGlobalData https://bugs.webkit.org/show_bug.cgi?id=89123 Reviewed by Gavin Barraclough. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * API/APIShims.h: (APIEntryShimWithoutLock): (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): Added an extra parameter to the constructor to determine whether we should ref the JSGlobalData or not. We want to ref all the time except for in the HeapTimer class because timerDidFire could run after somebody has started to tear down that particular JSGlobalData, so we wouldn't want to resurrect the ref count of that JSGlobalData from 0 back to 1 after its destruction has begun. (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): Now derefs if it also refed. (JSC::APIEntryShim::APIEntryShim): (APIEntryShim): (JSC::APIEntryShim::~APIEntryShim): (JSC::APIEntryShim::init): Factored out common initialization code for the various APIEntryShim constructors. Also moved the timeoutChecker stop and start here because we need to start after we've grabbed the API lock and before we've released it, which can only done in APIEntryShim. (JSC::APICallbackShim::~APICallbackShim): We no longer need to synchronize here. * API/JSContextRef.cpp: (JSGlobalContextCreate): (JSGlobalContextCreateInGroup): (JSGlobalContextRelease): (JSContextCreateBacktrace): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateSlowCase): * heap/Heap.cpp: (JSC::Heap::protect): (JSC::Heap::unprotect): (JSC::Heap::collect): (JSC::Heap::setActivityCallback): (JSC::Heap::activityCallback): (JSC::Heap::sweeper): * heap/Heap.h: Changed m_activityCallback and m_sweeper to be raw pointers rather than OwnPtrs because they are now responsible for their own lifetime. Also changed the order of declaration of the GCActivityCallback and the IncrementalSweeper to make sure they're the last things that get initialized during construction to prevent any issues with uninitialized memory in the JSGlobalData/Heap they might care about. (Heap): * heap/HeapTimer.cpp: Refactored to allow for thread-safe operation and shutdown. (JSC::HeapTimer::~HeapTimer): (JSC::HeapTimer::invalidate): (JSC): (JSC::HeapTimer::didStartVMShutdown): Called at the beginning of ~JSGlobalData. If we're on the same thread that the HeapTimer is running on, we kill the HeapTimer ourselves. If not, then we set some state in the HeapTimer and schedule it to fire immediately so that it can notice and kill itself. (JSC::HeapTimer::timerDidFire): We grab our mutex and check our JSGlobalData pointer. If it has been zero-ed out, then we know the VM has started to shutdown and we should kill ourselves. Otherwise, grab the APIEntryShim, but without ref-ing the JSGlobalData (we don't want to bring the JSGlobalData's ref-count from 0 to 1) in case we were interrupted between releasing our mutex and trying to grab the APILock. * heap/HeapTimer.h: (HeapTimer): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doWork): We no longer need the API shim here since HeapTimer::timerDidFire handles all of that for us. (JSC::IncrementalSweeper::create): * heap/IncrementalSweeper.h: (IncrementalSweeper): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::allocateSlowCase): * heap/WeakBlock.cpp: (JSC::WeakBlock::reap): * jsc.cpp: (functionGC): (functionReleaseExecutableMemory): (jscmain): * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::evaluate): * runtime/GCActivityCallback.h: (DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::create): * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): (JSC::JSGlobalData::~JSGlobalData): Signals to the two HeapTimers (GCActivityCallback and IncrementalSweeper) that the VM has started shutting down. It then waits until the HeapTimer is done with whatever activity it needs to do before continuing with any further destruction. Also asserts that we do not currently hold the APILock because this could potentially cause deadlock when we try to signal to the HeapTimers using their mutexes. (JSC::JSGlobalData::sharedInstance): Protect the initialization for the shared instance with the GlobalJSLock. (JSC::JSGlobalData::sharedInstanceInternal): * runtime/JSGlobalData.h: Change to be ThreadSafeRefCounted so that we don't have to worry about refing and de-refing JSGlobalDatas on separate threads since we don't do it that often anyways. (JSGlobalData): (JSC::JSGlobalData::apiLock): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): (JSC::JSGlobalObject::init): * runtime/JSLock.cpp: (JSC): (JSC::GlobalJSLock::GlobalJSLock): For accessing the shared instance. (JSC::GlobalJSLock::~GlobalJSLock): (JSC::JSLockHolder::JSLockHolder): MutexLocker for JSLock. Also refs the JSGlobalData to keep it alive so that it can successfully unlock it later without it disappearing from underneath it. (JSC::JSLockHolder::~JSLockHolder): (JSC::JSLock::JSLock): (JSC::JSLock::~JSLock): (JSC::JSLock::lock): Uses the spin lock for guarding the lock count and owner thread fields. Uses the mutex for actually waiting for long periods. (JSC::JSLock::unlock): (JSC::JSLock::currentThreadIsHoldingLock): (JSC::JSLock::dropAllLocks): (JSC::JSLock::dropAllLocksUnconditionally): (JSC::JSLock::grabAllLocks): (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): * runtime/JSLock.h: (JSC): (GlobalJSLock): (JSLockHolder): (JSLock): (DropAllLocks): * runtime/WeakGCMap.h: (JSC::WeakGCMap::set): * testRegExp.cpp: (realMain): 2012-06-22 Peter Beverloo [Chromium] Disable c++0x compatibility warnings in JavaScriptCore.gyp when building for Android https://bugs.webkit.org/show_bug.cgi?id=88853 Reviewed by Steve Block. The Android exclusions were necessary to fix a gyp generation error, as the gcc_version variable wasn't being defined for Android. Remove these exceptions when Chromium is able to define the gcc_version variable. * JavaScriptCore.gyp/JavaScriptCore.gyp: 2012-06-21 Filip Pizlo op_resolve_global should not prevent DFG inlining https://bugs.webkit.org/show_bug.cgi?id=89726 Reviewed by Gavin Barraclough. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::shrinkToFit): * bytecode/GlobalResolveInfo.h: (JSC::GlobalResolveInfo::GlobalResolveInfo): (GlobalResolveInfo): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCapabilities.h: (JSC::DFG::canInlineOpcode): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-06-20 Filip Pizlo DFG should inline 'new Array()' https://bugs.webkit.org/show_bug.cgi?id=89632 Reviewed by Geoffrey Garen. This adds support for treating InternalFunction like intrinsics. The code to do so is actually quite clean, so I don't feel bad about perpetuating the InternalFunction vs. JSFunction-with-NativeExecutable dichotomy. Currently this newfound power is only used to inline 'new Array()'. * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (DFG): * dfg/DFGGraph.h: (JSC::DFG::Graph::isInternalFunctionConstant): (JSC::DFG::Graph::valueOfInternalFunctionConstant): 2012-06-21 Mark Hahnenberg Adding copyrights to new files. * heap/HeapTimer.cpp: * heap/HeapTimer.h: * heap/IncrementalSweeper.cpp: * heap/IncrementalSweeper.h: 2012-06-21 Arnaud Renevier make sure headers are included only once per file https://bugs.webkit.org/show_bug.cgi?id=88922 Reviewed by Alexey Proskuryakov. * bytecode/CodeBlock.h: * heap/MachineStackMarker.cpp: * runtime/JSVariableObject.h: 2012-06-21 Ryuan Choi [EFL][WK2] Make WebKit2/Efl headers and resources installable. https://bugs.webkit.org/show_bug.cgi?id=88207 Reviewed by Chang Shu. * shell/CMakeLists.txt: Use ${EXEC_INSTALL_DIR} instead of hardcoding "bin" 2012-06-20 Geoffrey Garen Reduced (but did not eliminate) use of "berzerker GC" https://bugs.webkit.org/show_bug.cgi?id=89237 Reviewed by Gavin Barraclough. (PART 1) This patch turned out to be crashy, so I'm landing the non-crashy bits first. This part is pre-requisite refactoring. I didn't actually turn off "berzerker GC" or turn on incremental shrinking. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::removeBlock): Make sure to clear the free list when we throw away the block we're currently allocating out of. Otherwise, we'll allocate out of a stale free list. * heap/MarkedSpace.cpp: (JSC::Free::Free): (JSC::Free::operator()): (JSC::Free::returnValue): Refactored this functor to use a shared helper function, so we can share our implementation with the incremental sweeper. Also changed to freeing individual blocks immediately instead of linking them into a list for later freeing. This makes the programming interface simpler, and it's slightly more efficient to boot. (JSC::MarkedSpace::~MarkedSpace): Updated for rename. (JSC::MarkedSpace::freeBlock): (JSC::MarkedSpace::freeOrShrinkBlock): New helper functions to share behavior with the incremental sweeper. (JSC::MarkedSpace::shrink): Updated for new functor behavior. * heap/MarkedSpace.h: Statically typed languages are awesome. 2012-06-20 Filip Pizlo DFG should optimize ResolveGlobal https://bugs.webkit.org/show_bug.cgi?id=89617 Reviewed by Oliver Hunt. This adds inlining of ResolveGlobal accesses that are known monomorphic. It also adds the specific function optimization to ResolveGlobal, when it is inlined. And, it makes internal functions act like specific functions, since that will be the most common use-case of this optimization. This is only a slighy speed-up (sub 1%), since we don't yet do the obvious thing with this optimization, which is to completely inline common "globally resolved" function and constructor calls, like "new Array()". * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::globalResolveInfoForBytecodeOffset): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::numberOfGlobalResolveInfos): * bytecode/GlobalResolveInfo.h: (JSC::getGlobalResolveInfoBytecodeOffset): (JSC): * bytecode/ResolveGlobalStatus.cpp: Added. (JSC): (JSC::computeForStructure): (JSC::computeForLLInt): (JSC::ResolveGlobalStatus::computeFor): * bytecode/ResolveGlobalStatus.h: Added. (JSC): (ResolveGlobalStatus): (JSC::ResolveGlobalStatus::ResolveGlobalStatus): (JSC::ResolveGlobalStatus::state): (JSC::ResolveGlobalStatus::isSet): (JSC::ResolveGlobalStatus::operator!): (JSC::ResolveGlobalStatus::isSimple): (JSC::ResolveGlobalStatus::takesSlowPath): (JSC::ResolveGlobalStatus::structure): (JSC::ResolveGlobalStatus::offset): (JSC::ResolveGlobalStatus::specificValue): * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::handleGetByOffset): (DFG): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): * runtime/JSObject.cpp: (JSC::getCallableObjectSlow): (JSC): (JSC::JSObject::put): (JSC::JSObject::putDirectVirtual): (JSC::JSObject::putDirectAccessor): * runtime/JSObject.h: (JSC): (JSC::getCallableObject): (JSC::JSObject::putOwnDataProperty): (JSC::JSObject::putDirect): (JSC::JSObject::putDirectWithoutTransition): 2012-06-20 Filip Pizlo Functions on global objects should be specializable https://bugs.webkit.org/show_bug.cgi?id=89615 Reviewed by Oliver Hunt. I tested to see if this brought back the bug in https://bugs.webkit.org/show_bug.cgi?id=33343, and it didn't. Bug 33343 was the reason why we disabled global object function specialization to begin with. So I'm guessing this is safe. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2012-06-20 Filip Pizlo build-webkit failure due to illegal 32-bit integer constants in code generated by offlineasm https://bugs.webkit.org/show_bug.cgi?id=89347 Reviewed by Geoffrey Garen. The offending constants are the magic numbers used by offlineasm to find offsets in the generated machine code. Added code to turn them into what the C++ compiler will believe to be valid 32-bit values. * offlineasm/offsets.rb: 2012-06-19 Geoffrey Garen Made the incremental sweeper more aggressive https://bugs.webkit.org/show_bug.cgi?id=89527 Reviewed by Oliver Hunt. This is a pre-requisite to getting rid of "berzerker GC" because we need the sweeper to reclaim memory in a timely fashion, or we'll see a memory footprint regression. * heap/IncrementalSweeper.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::scheduleTimer): Since the time slice is predictable, no need to use a data member to record it. (JSC::IncrementalSweeper::doSweep): Sweep as many blocks as we can in a small time slice. This is better than sweeping only one block per timer fire because that strategy has a heavy timer overhead, and artificially delays memory reclamation. 2012-06-20 Filip Pizlo DFG should be able to print disassembly interleaved with the IR https://bugs.webkit.org/show_bug.cgi?id=89551 Reviewed by Geoffrey Garen. This change also removes running Dominators unconditionally on every DFG compile. Dominators are designed to be computed on-demand, and currently the only demand is graph dumps. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::labelIgnoringWatchpoints): (ARMv7Assembler): * assembler/AbstractMacroAssembler.h: (AbstractMacroAssembler): (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints): * assembler/X86Assembler.h: (X86Assembler): (JSC::X86Assembler::labelIgnoringWatchpoints): * dfg/DFGCommon.h: (JSC::DFG::shouldShowDisassembly): (DFG): * dfg/DFGDisassembler.cpp: Added. (DFG): (JSC::DFG::Disassembler::Disassembler): (JSC::DFG::Disassembler::dump): (JSC::DFG::Disassembler::dumpDisassembly): * dfg/DFGDisassembler.h: Added. (DFG): (Disassembler): (JSC::DFG::Disassembler::setStartOfCode): (JSC::DFG::Disassembler::setForBlock): (JSC::DFG::Disassembler::setForNode): (JSC::DFG::Disassembler::setEndOfMainPath): (JSC::DFG::Disassembler::setEndOfCode): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dumpCodeOrigin): (JSC::DFG::Graph::amountOfNodeWhiteSpace): (DFG): (JSC::DFG::Graph::printNodeWhiteSpace): (JSC::DFG::Graph::dump): (JSC::DFG::Graph::dumpBlockHeader): * dfg/DFGGraph.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (DFG): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JITCompiler): (JSC::DFG::JITCompiler::setStartOfCode): (JSC::DFG::JITCompiler::setForBlock): (JSC::DFG::JITCompiler::setForNode): (JSC::DFG::JITCompiler::setEndOfMainPath): (JSC::DFG::JITCompiler::setEndOfCode): * dfg/DFGNode.h: (Node): (JSC::DFG::Node::willHaveCodeGen): * dfg/DFGNodeFlags.cpp: (JSC::DFG::nodeFlagsAsString): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): * runtime/Options.cpp: (Options): (JSC::Options::initializeOptions): * runtime/Options.h: (Options): 2012-06-19 Filip Pizlo JSC should be able to show disassembly for all generated JIT code https://bugs.webkit.org/show_bug.cgi?id=89536 Reviewed by Gavin Barraclough. Now instead of doing linkBuffer.finalizeCode(), you do FINALIZE_CODE(linkBuffer, (... explanation ...)). FINALIZE_CODE() then prints your explanation and the disassembled code, if Options::showDisassembly is set to true. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/LinkBuffer.cpp: Added. (JSC): (JSC::LinkBuffer::finalizeCodeWithoutDisassembly): (JSC::LinkBuffer::finalizeCodeWithDisassembly): (JSC::LinkBuffer::linkCode): (JSC::LinkBuffer::performFinalization): (JSC::LinkBuffer::dumpLinkStatistics): (JSC::LinkBuffer::dumpCode): * assembler/LinkBuffer.h: (LinkBuffer): (JSC): * assembler/MacroAssemblerCodeRef.h: (JSC::MacroAssemblerCodeRef::tryToDisassemble): (MacroAssemblerCodeRef): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGRepatch.cpp: (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): (JSC::DFG::tryBuildGetByIDList): (JSC::DFG::emitPutReplaceStub): (JSC::DFG::emitPutTransitionStub): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): * disassembler/Disassembler.h: (JSC): (JSC::tryToDisassemble): * disassembler/UDis86Disassembler.cpp: (JSC::tryToDisassemble): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITCode.h: (JSC::JITCode::tryToDisassemble): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileCTIMachineTrampolines): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTIMachineTrampolines): (JSC::JIT::privateCompileCTINativeCall): * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::privateCompilePatchGetArrayLength): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::privateCompilePutByIdTransition): (JSC::JIT::privateCompilePatchGetArrayLength): (JSC::JIT::privateCompileGetByIdProto): (JSC::JIT::privateCompileGetByIdSelfList): (JSC::JIT::privateCompileGetByIdProtoList): (JSC::JIT::privateCompileGetByIdChainList): (JSC::JIT::privateCompileGetByIdChain): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::charCodeAtThunkGenerator): (JSC::charAtThunkGenerator): (JSC::fromCharCodeThunkGenerator): (JSC::sqrtThunkGenerator): (JSC::floorThunkGenerator): (JSC::ceilThunkGenerator): (JSC::roundThunkGenerator): (JSC::expThunkGenerator): (JSC::logThunkGenerator): (JSC::absThunkGenerator): (JSC::powThunkGenerator): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): (JSC::LLInt::functionForCallEntryThunkGenerator): (JSC::LLInt::functionForConstructEntryThunkGenerator): (JSC::LLInt::functionForCallArityCheckThunkGenerator): (JSC::LLInt::functionForConstructArityCheckThunkGenerator): (JSC::LLInt::evalEntryThunkGenerator): (JSC::LLInt::programEntryThunkGenerator): * runtime/Options.cpp: (Options): (JSC::Options::initializeOptions): * runtime/Options.h: (Options): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::compile): 2012-06-19 Mark Hahnenberg [Qt][Mac] REGRESSION(r120742): It broke the build https://bugs.webkit.org/show_bug.cgi?id=89516 Reviewed by Geoffrey Garen. Removing GCActivityCallbackCF.cpp because it doesn't mesh well with cross-platform code on Darwin (e.g. Qt). We now use plain ol' vanilla ifdefs to handle platforms without CF support. These if-defs will probably disappear in the future when we use cross-platform timers in HeapTimer. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/GCActivityCallback.cpp: (JSC): (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::doWork): (JSC::DefaultGCActivityCallback::scheduleTimer): (JSC::DefaultGCActivityCallback::cancelTimer): (JSC::DefaultGCActivityCallback::didAllocate): (JSC::DefaultGCActivityCallback::willCollect): (JSC::DefaultGCActivityCallback::cancel): * runtime/GCActivityCallbackCF.cpp: Removed. 2012-06-19 Filip Pizlo DFG CFA forgets to notify subsequent phases of found constants if it proves LogicalNot to be a constant https://bugs.webkit.org/show_bug.cgi?id=89511 Reviewed by Geoffrey Garen. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): 2012-06-19 Mark Lam CodeBlock::needsCallReturnIndices() is no longer needed. https://bugs.webkit.org/show_bug.cgi?id=89490 Reviewed by Geoffrey Garen. * bytecode/CodeBlock.h: (JSC::CodeBlock::needsCallReturnIndices): removed. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * jit/JIT.cpp: (JSC::JIT::privateCompile): 2012-06-19 Filip Pizlo Unreviewed, try to fix Windows build. * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: 2012-06-17 Filip Pizlo It should be possible to look at disassembly https://bugs.webkit.org/show_bug.cgi?id=89319 Reviewed by Sam Weinig. This imports the udis86 disassembler library. The library is placed behind an abstraction in disassembler/Disassembler.h, so that we can in the future use other disassemblers (for other platforms) whenever appropriate. As a first step, the disassembler is being invoked for DFG verbose dumps. If we ever want to merge a new version of udis86 in the future, I've made notes about changes I made to the library in disassembler/udis86/differences.txt. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.list.am: * JavaScriptCore.pri: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * disassembler: Added. * disassembler/Disassembler.h: Added. (JSC): (JSC::tryToDisassemble): * disassembler/UDis86Disassembler.cpp: Added. (JSC): (JSC::tryToDisassemble): * disassembler/udis86: Added. * disassembler/udis86/differences.txt: Added. * disassembler/udis86/itab.py: Added. (UdItabGenerator): (UdItabGenerator.__init__): (UdItabGenerator.toGroupId): (UdItabGenerator.genLookupTable): (UdItabGenerator.genLookupTableList): (UdItabGenerator.genInsnTable): (genItabH): (genItabH.UD_ITAB_H): (genItabC): (genItab): (main): * disassembler/udis86/optable.xml: Added. * disassembler/udis86/ud_opcode.py: Added. (UdOpcodeTables): (UdOpcodeTables.sizeOfTable): (UdOpcodeTables.nameOfTable): (UdOpcodeTables.updateTable): (UdOpcodeTables.Insn): (UdOpcodeTables.Insn.__init__): (UdOpcodeTables.Insn.__init__.opcode): (UdOpcodeTables.parse): (UdOpcodeTables.addInsnDef): (UdOpcodeTables.print_table): (UdOpcodeTables.print_tree): * disassembler/udis86/ud_optable.py: Added. (UdOptableXmlParser): (UdOptableXmlParser.parseDef): (UdOptableXmlParser.parse): (printFn): (parse): (main): * disassembler/udis86/udis86.c: Added. (ud_init): (ud_disassemble): (ud_set_mode): (ud_set_vendor): (ud_set_pc): (ud): (ud_insn_asm): (ud_insn_off): (ud_insn_hex): (ud_insn_ptr): (ud_insn_len): * disassembler/udis86/udis86.h: Added. * disassembler/udis86/udis86_decode.c: Added. (eff_adr_mode): (ud_lookup_mnemonic): (decode_prefixes): (modrm): (resolve_operand_size): (resolve_mnemonic): (decode_a): (decode_gpr): (resolve_gpr64): (resolve_gpr32): (resolve_reg): (decode_imm): (decode_modrm_reg): (decode_modrm_rm): (decode_o): (decode_operand): (decode_operands): (clear_insn): (resolve_mode): (gen_hex): (decode_insn): (decode_3dnow): (decode_ssepfx): (decode_ext): (decode_opcode): (ud_decode): * disassembler/udis86/udis86_decode.h: Added. (ud_itab_entry_operand): (ud_itab_entry): (ud_lookup_table_list_entry): (sse_pfx_idx): (mode_idx): (modrm_mod_idx): (vendor_idx): (is_group_ptr): (group_idx): * disassembler/udis86/udis86_extern.h: Added. * disassembler/udis86/udis86_input.c: Added. (inp_buff_hook): (inp_file_hook): (ud): (ud_set_user_opaque_data): (ud_get_user_opaque_data): (ud_set_input_buffer): (ud_set_input_file): (ud_input_skip): (ud_input_end): (ud_inp_next): (ud_inp_back): (ud_inp_peek): (ud_inp_move): (ud_inp_uint8): (ud_inp_uint16): (ud_inp_uint32): (ud_inp_uint64): * disassembler/udis86/udis86_input.h: Added. * disassembler/udis86/udis86_itab_holder.c: Added. * disassembler/udis86/udis86_syn-att.c: Added. (opr_cast): (gen_operand): (ud_translate_att): * disassembler/udis86/udis86_syn-intel.c: Added. (opr_cast): (gen_operand): (ud_translate_intel): * disassembler/udis86/udis86_syn.c: Added. * disassembler/udis86/udis86_syn.h: Added. (mkasm): * disassembler/udis86/udis86_types.h: Added. (ud_operand): (ud): * jit/JITCode.h: (JITCode): (JSC::JITCode::tryToDisassemble): 2012-06-19 Mark Hahnenberg GCActivityCallback and IncrementalSweeper should share code https://bugs.webkit.org/show_bug.cgi?id=89400 Reviewed by Geoffrey Garen. A lot of functionality is duplicated between GCActivityCallback and IncrementalSweeper. We should extract the common functionality out into a separate class that both of them can inherit from. This refactoring will be an even greater boon when we add the ability to shut these two agents down in a thread-safe fashion * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * heap/Heap.cpp: (JSC::Heap::Heap): Move initialization down so that the JSGlobalData has a valid Heap when we're initializing the GCActivityCallback and the IncrementalSweeper. * heap/Heap.h: (Heap): * heap/HeapTimer.cpp: Added. (JSC): (JSC::HeapTimer::HeapTimer): Initialize the various base class data that DefaultGCActivityCallback::commonConstructor() used to do. (JSC::HeapTimer::~HeapTimer): Call to invalidate(). (JSC::HeapTimer::synchronize): Same functionality as the old DefaultGCActivityCallback::synchronize(). Virtual so that non-CF subclasses can override. (JSC::HeapTimer::invalidate): Tears down the runloop timer to prevent any future firing. (JSC::HeapTimer::timerDidFire): Callback to pass to the timer function. Casts and calls the virtual doWork(). * heap/HeapTimer.h: Added. This is the class that serves as the common base class for both GCActivityCallback and IncrementalSweeper. It handles setting up and tearing down run loops and synchronizing across threads for its subclasses. (JSC): (HeapTimer): * heap/IncrementalSweeper.cpp: Changes to accomodate the extraction of common functionality between IncrementalSweeper and GCActivityCallback into a common ancestor. (JSC): (JSC::IncrementalSweeper::doWork): (JSC::IncrementalSweeper::IncrementalSweeper): (JSC::IncrementalSweeper::cancelTimer): (JSC::IncrementalSweeper::create): * heap/IncrementalSweeper.h: (IncrementalSweeper): * runtime/GCActivityCallback.cpp: (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::doWork): * runtime/GCActivityCallback.h: (GCActivityCallback): (JSC::GCActivityCallback::willCollect): (JSC::GCActivityCallback::GCActivityCallback): (JSC): (DefaultGCActivityCallback): Remove the platform data struct. The platform data should be kept in the class itself so as to be accessible by doWork(). Most of the platform data for CF is kept in HeapTimer anyways, so we only need the m_delay field now. * runtime/GCActivityCallbackBlackBerry.cpp: (JSC): (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::doWork): (JSC::DefaultGCActivityCallback::didAllocate): * runtime/GCActivityCallbackCF.cpp: (JSC): (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::doWork): (JSC::DefaultGCActivityCallback::scheduleTimer): (JSC::DefaultGCActivityCallback::cancelTimer): (JSC::DefaultGCActivityCallback::didAllocate): (JSC::DefaultGCActivityCallback::willCollect): (JSC::DefaultGCActivityCallback::cancel): 2012-06-19 Mike West Introduce ENABLE_CSP_NEXT configuration flag. https://bugs.webkit.org/show_bug.cgi?id=89300 Reviewed by Adam Barth. The 1.0 draft of the Content Security Policy spec is just about to move to Last Call. We'll hide work on the upcoming 1.1 spec behind this ENABLE flag, disabled by default. Spec: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html * Configurations/FeatureDefines.xcconfig: 2012-06-18 Mark Lam Changed JSC to always record line number information so that error.stack and window.onerror() can report proper line numbers. https://bugs.webkit.org/show_bug.cgi?id=89410 Reviewed by Geoffrey Garen. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::lineNumberForBytecodeOffset): (JSC::CodeBlock::shrinkToFit): m_lineInfo is now available unconditionally. * bytecode/CodeBlock.h: (JSC::CodeBlock::addLineInfo): (JSC::CodeBlock::hasLineInfo): Unused. Now removed. (JSC::CodeBlock::needsCallReturnIndices): (CodeBlock): (RareData): Hoisted m_lineInfo out of m_rareData. m_lineInfo is now filled in unconditionally. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::addLineInfo): 2012-06-18 Andy Estes Fix r120663, which didn't land the change that was reviewed. 2012-06-18 Andy Estes [JSC] In JSGlobalData.cpp, enableAssembler() sometimes leaks two CF objects https://bugs.webkit.org/show_bug.cgi?id=89415 Reviewed by Sam Weinig. In the case where canUseJIT was a non-NULL CFBooleanRef, enableAssembler() would leak both canUseJITKey and canUseJIT by returning before calling CFRelease. Fix this by using RetainPtr. * runtime/JSGlobalData.cpp: (JSC::enableAssembler): 2012-06-17 Geoffrey Garen GC copy phase spends needless cycles zero-filling blocks https://bugs.webkit.org/show_bug.cgi?id=89128 Reviewed by Gavin Barraclough. We only need to zero-fill when we're allocating memory that might not get fully initialized before GC. * heap/CopiedBlock.h: (JSC::CopiedBlock::createNoZeroFill): (JSC::CopiedBlock::create): Added a way to create without zero-filling. This is our optimization. (JSC::CopiedBlock::zeroFillToEnd): (JSC::CopiedBlock::CopiedBlock): Split zero-filling out from creation, so we can sometimes create without zero-filling. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::init): (JSC::CopiedSpace::tryAllocateSlowCase): (JSC::CopiedSpace::doneCopying): Renamed addNewBlock to allocateBlock() to clarify that the new block is always newly-allocated. (JSC::CopiedSpace::doneFillingBlock): Make sure to zero-fill to the end of a block that might be used in the future for allocation. (Most of the time, this is a no-op, since we've already filled the block completely.) (JSC::CopiedSpace::getFreshBlock): Removed this function because the abstraction of "allocation must succeed" is no longer useful. * heap/CopiedSpace.h: Updated declarations to match. * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::allocateBlockForCopyingPhase): New function, which knows that it can skip zero-filling. Added tighter scoping to our lock, to improve parallelism. (JSC::CopiedSpace::allocateBlock): Folded getFreshBlock functionality into this function, for simplicity. * heap/MarkStack.cpp: (JSC::SlotVisitor::startCopying): (JSC::SlotVisitor::allocateNewSpace): Use our new zero-fill-free helper function for great good. 2012-06-17 Filip Pizlo DFG should attempt to use structure watchpoints for all inlined get_by_id's and put_by_id's https://bugs.webkit.org/show_bug.cgi?id=89316 Reviewed by Oliver Hunt. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): (ByteCodeParser): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): 2012-06-15 Yong Li [BlackBerry] Put platform-specific GC policy in GCActivityCallback https://bugs.webkit.org/show_bug.cgi?id=89236 Reviewed by Rob Buis. Add GCActivityCallbackBlackBerry.cpp and implement platform-specific low memory GC policy there. * PlatformBlackBerry.cmake: * heap/Heap.h: (JSC::Heap::isSafeToCollect): Added. * runtime/GCActivityCallbackBlackBerry.cpp: Added. (JSC): (JSC::DefaultGCActivityCallbackPlatformData::DefaultGCActivityCallbackPlatformData): (DefaultGCActivityCallbackPlatformData): (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::~DefaultGCActivityCallback): (JSC::DefaultGCActivityCallback::didAllocate): (JSC::DefaultGCActivityCallback::willCollect): (JSC::DefaultGCActivityCallback::synchronize): (JSC::DefaultGCActivityCallback::cancel): 2012-06-15 Filip Pizlo DFG should be able to set watchpoints on structure transitions in the method check prototype chain https://bugs.webkit.org/show_bug.cgi?id=89058 Adding the same assertion to 32-bit that I added to 64-bit. This change does not affect correctness but it's a good thing for assertion coverage. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-06-13 Filip Pizlo DFG should be able to set watchpoints on structure transitions in the method check prototype chain https://bugs.webkit.org/show_bug.cgi?id=89058 Reviewed by Gavin Barraclough. This adds the ability to set watchpoints on Structures, and then does the most modest thing we can do with this ability: the DFG now sets watchpoints on structure transitions in the prototype chain of method checks. This appears to be a >1% speed-up on V8. * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeFor): * bytecode/StructureSet.h: (JSC::StructureSet::containsOnly): (StructureSet): * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::WatchpointSet): (JSC::InlineWatchpointSet::add): (JSC): (JSC::InlineWatchpointSet::inflateSlow): (JSC::InlineWatchpointSet::freeFat): * bytecode/Watchpoint.h: (WatchpointSet): (JSC): (InlineWatchpointSet): (JSC::InlineWatchpointSet::InlineWatchpointSet): (JSC::InlineWatchpointSet::~InlineWatchpointSet): (JSC::InlineWatchpointSet::hasBeenInvalidated): (JSC::InlineWatchpointSet::isStillValid): (JSC::InlineWatchpointSet::startWatching): (JSC::InlineWatchpointSet::notifyWrite): (JSC::InlineWatchpointSet::isFat): (JSC::InlineWatchpointSet::fat): (JSC::InlineWatchpointSet::inflate): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): (ByteCodeParser): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): (CSEPhase): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCommon.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::isCellConstant): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addWeakReferences): (JITCompiler): * dfg/DFGNode.h: (JSC::DFG::Node::hasStructure): (Node): (JSC::DFG::Node::structure): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGRepatch.cpp: (JSC::DFG::emitPutTransitionStub): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITStubs.cpp: (JSC::JITThunks::tryCachePutByID): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Structure.cpp: (JSC::Structure::Structure): * runtime/Structure.h: (JSC::Structure::transitionWatchpointSetHasBeenInvalidated): (Structure): (JSC::Structure::transitionWatchpointSetIsStillValid): (JSC::Structure::addTransitionWatchpoint): (JSC::Structure::notifyTransitionFromThisStructure): (JSC::JSCell::setStructure): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::attemptToWatch): 2012-06-13 Filip Pizlo DFG should be able to set watchpoints on global variables https://bugs.webkit.org/show_bug.cgi?id=88692 Reviewed by Geoffrey Garen. Rolling back in after fixing Windows build issues, and implementing branchTest8 for the Qt port's strange assemblers. This implements global variable constant folding by allowing the optimizing compiler to set a "watchpoint" on globals that it wishes to constant fold. If the watchpoint fires, then an OSR exit is forced by overwriting the machine code that the optimizing compiler generated with a jump. As such, this patch is adding quite a bit of stuff: - Jump replacement on those hardware targets supported by the optimizing JIT. It is now possible to patch in a jump instruction over any recorded watchpoint label. The jump must be "local" in the sense that it must be within the range of the largest jump distance supported by a one instruction jump. - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node that records the location where a jump must be inserted and the destination to which it should jump. Watchpoints can be added to a WatchpointSet. The WatchpointSet can be fired all at once, which plants all jumps. WatchpointSet also remembers if it had ever been invalidated, which allows for monotonicity: we typically don't want to optimize using watchpoints on something for which watchpoints had previously fired. The act of notifying a WatchpointSet has a trivial fast path in case no Watchpoints are registered (one-byte load+branch). - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(), except that you don't have to emit branches. But, you need to know what WatchpointSet to add the resulting Watchpoint to. Not everything that you could write a speculationCheck() for will have a WatchpointSet that would get notified if the condition you were speculating against became invalid. - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can do so without incurring any space overhead for those entries that don't have WatchpointSets. - The bytecode generator infers all global function variables to be watchable, and makes all stores perform the WatchpointSet's write check, and marks all loads as being potentially watchable (i.e. you can compile them to a watchpoint and a constant). Put together, this allows for fully sleazy inlining of calls to globally declared functions. The inline prologue will no longer contain the load of the function, or any checks of the function you're calling. I.e. it's pretty much like the kind of inlining you would see in Java or C++. Furthermore, the watchpointing functionality is built to be fairly general, and should allow setting watchpoints on all sorts of interesting things in the future. The sleazy inlining means that we will now sometimes inline in code paths that have never executed. Previously, to inline we would have either had to have executed the call (to read the call's inline cache) or have executed the method check (to read the method check's inline cache). Now, we might inline when the callee is a watched global variable. This revealed some humorous bugs. First, constant folding disagreed with CFA over what kinds of operations can clobber (example: code path A is dead but stores a String into variable X, all other code paths store 0 into X, and then you do CompareEq(X, 0) - CFA will say that this is a non- clobbering constant, but constant folding thought it was clobbering because it saw the String prediction). Second, inlining would crash if the inline callee had not been compiled. This patch fixes both bugs, since otherwise run-javascriptcore-tests would report regressions. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/ARMv7Assembler.h: (ARMv7Assembler): (JSC::ARMv7Assembler::ARMv7Assembler): (JSC::ARMv7Assembler::labelForWatchpoint): (JSC::ARMv7Assembler::label): (JSC::ARMv7Assembler::replaceWithJump): (JSC::ARMv7Assembler::maxJumpReplacementSize): * assembler/AbstractMacroAssembler.h: (JSC): (AbstractMacroAssembler): (Label): (JSC::AbstractMacroAssembler::watchpointLabel): (JSC::AbstractMacroAssembler::readPointer): * assembler/AssemblerBuffer.h: * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTest8): (MacroAssemblerARM): (JSC::MacroAssemblerARM::replaceWithJump): (JSC::MacroAssemblerARM::maxJumpReplacementSize): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::load8Signed): (JSC::MacroAssemblerARMv7::load16Signed): (MacroAssemblerARMv7): (JSC::MacroAssemblerARMv7::replaceWithJump): (JSC::MacroAssemblerARMv7::maxJumpReplacementSize): (JSC::MacroAssemblerARMv7::branchTest8): (JSC::MacroAssemblerARMv7::jump): (JSC::MacroAssemblerARMv7::makeBranch): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchTest8): (MacroAssemblerMIPS): (JSC::MacroAssemblerMIPS::replaceWithJump): (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTest8): (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::replaceWithJump): (JSC::MacroAssemblerSH4::maxJumpReplacementSize): * assembler/MacroAssemblerX86.h: (MacroAssemblerX86): (JSC::MacroAssemblerX86::branchTest8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::replaceWithJump): (MacroAssemblerX86Common): (JSC::MacroAssemblerX86Common::maxJumpReplacementSize): * assembler/MacroAssemblerX86_64.h: (MacroAssemblerX86_64): (JSC::MacroAssemblerX86_64::branchTest8): * assembler/X86Assembler.h: (JSC::X86Assembler::X86Assembler): (X86Assembler): (JSC::X86Assembler::cmpb_im): (JSC::X86Assembler::testb_im): (JSC::X86Assembler::labelForWatchpoint): (JSC::X86Assembler::label): (JSC::X86Assembler::replaceWithJump): (JSC::X86Assembler::maxJumpReplacementSize): (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): * bytecode/CodeBlock.cpp: (JSC): (JSC::CodeBlock::printGetByIdCacheStatus): (JSC::CodeBlock::dump): * bytecode/CodeBlock.h: (JSC::CodeBlock::appendOSRExit): (JSC::CodeBlock::appendSpeculationRecovery): (CodeBlock): (JSC::CodeBlock::appendWatchpoint): (JSC::CodeBlock::numberOfWatchpoints): (JSC::CodeBlock::watchpoint): (DFGData): * bytecode/DFGExitProfile.h: (JSC::DFG::exitKindToString): (JSC::DFG::exitKindIsCountable): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForChain): * bytecode/Instruction.h: (Instruction): (JSC::Instruction::Instruction): * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): * bytecode/Watchpoint.cpp: Added. (JSC): (JSC::Watchpoint::~Watchpoint): (JSC::Watchpoint::correctLabels): (JSC::Watchpoint::fire): (JSC::WatchpointSet::WatchpointSet): (JSC::WatchpointSet::~WatchpointSet): (JSC::WatchpointSet::add): (JSC::WatchpointSet::notifyWriteSlow): (JSC::WatchpointSet::fireAllWatchpoints): * bytecode/Watchpoint.h: Added. (JSC): (Watchpoint): (JSC::Watchpoint::Watchpoint): (JSC::Watchpoint::setDestination): (WatchpointSet): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::hasBeenInvalidated): (JSC::WatchpointSet::startWatching): (JSC::WatchpointSet::notifyWrite): (JSC::WatchpointSet::addressOfIsWatched): * bytecompiler/BytecodeGenerator.cpp: (JSC::ResolveResult::checkValidity): (JSC::BytecodeGenerator::addGlobalVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolve): (JSC::BytecodeGenerator::emitResolve): (JSC::BytecodeGenerator::emitResolveWithBase): (JSC::BytecodeGenerator::emitResolveWithThis): (JSC::BytecodeGenerator::emitGetStaticVar): (JSC::BytecodeGenerator::emitPutStaticVar): * bytecompiler/BytecodeGenerator.h: (BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): (JSC::PostfixResolveNode::emitBytecode): (JSC::PrefixResolveNode::emitBytecode): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::clobberStructures): * dfg/DFGAbstractState.h: (AbstractState): (JSC::DFG::AbstractState::didClobber): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCCallHelpers.h: (CCallHelpers): (JSC::DFG::CCallHelpers::setupArguments): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::globalVarWatchpointElimination): (CSEPhase): (JSC::DFG::CSEPhase::globalVarStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGCorrectableJumpPoint.h: (JSC::DFG::CorrectableJumpPoint::isSet): (CorrectableJumpPoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifierNumberForCheck): (Node): (JSC::DFG::Node::identifierNumberForCheck): (JSC::DFG::Node::hasRegisterPointer): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::appendCall): (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_global_var_check): (JSC): (JSC::JIT::emitSlow_op_put_global_var_check): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_global_var_check): (JSC): (JSC::JIT::emitSlow_op_put_global_var_check): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): (JSC): * jit/JITStubs.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (LLInt): * llint/LLIntSlowPaths.h: (LLInt): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSObject.cpp: (JSC::JSObject::removeDirect): * runtime/JSObject.h: (JSObject): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: Added. (JSC): (JSC::SymbolTableEntry::copySlow): (JSC::SymbolTableEntry::freeFatEntrySlow): (JSC::SymbolTableEntry::couldBeWatched): (JSC::SymbolTableEntry::attemptToWatch): (JSC::SymbolTableEntry::addressOfIsWatched): (JSC::SymbolTableEntry::addWatchpoint): (JSC::SymbolTableEntry::notifyWriteSlow): (JSC::SymbolTableEntry::inflateSlow): * runtime/SymbolTable.h: (JSC): (SymbolTableEntry): (Fast): (JSC::SymbolTableEntry::Fast::Fast): (JSC::SymbolTableEntry::Fast::isNull): (JSC::SymbolTableEntry::Fast::getIndex): (JSC::SymbolTableEntry::Fast::isReadOnly): (JSC::SymbolTableEntry::Fast::getAttributes): (JSC::SymbolTableEntry::Fast::isFat): (JSC::SymbolTableEntry::SymbolTableEntry): (JSC::SymbolTableEntry::~SymbolTableEntry): (JSC::SymbolTableEntry::operator=): (JSC::SymbolTableEntry::isNull): (JSC::SymbolTableEntry::getIndex): (JSC::SymbolTableEntry::getFast): (JSC::SymbolTableEntry::getAttributes): (JSC::SymbolTableEntry::isReadOnly): (JSC::SymbolTableEntry::watchpointSet): (JSC::SymbolTableEntry::notifyWrite): (FatEntry): (JSC::SymbolTableEntry::FatEntry::FatEntry): (JSC::SymbolTableEntry::isFat): (JSC::SymbolTableEntry::fatEntry): (JSC::SymbolTableEntry::inflate): (JSC::SymbolTableEntry::bits): (JSC::SymbolTableEntry::freeFatEntry): (JSC::SymbolTableEntry::pack): (JSC::SymbolTableEntry::isValidIndex): 2012-06-13 Sheriff Bot Unreviewed, rolling out r120172. http://trac.webkit.org/changeset/120172 https://bugs.webkit.org/show_bug.cgi?id=88976 The patch causes compilation failures on Gtk, Qt and Apple Win bots (Requested by zdobersek on #webkit). * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::nop): (JSC::ARMv7Assembler::label): (JSC::ARMv7Assembler::readPointer): (ARMv7Assembler): * assembler/AbstractMacroAssembler.h: (JSC): (AbstractMacroAssembler): (Label): * assembler/AssemblerBuffer.h: * assembler/MacroAssemblerARM.h: * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::nop): (JSC::MacroAssemblerARMv7::jump): (JSC::MacroAssemblerARMv7::makeBranch): * assembler/MacroAssemblerMIPS.h: * assembler/MacroAssemblerSH4.h: * assembler/MacroAssemblerX86.h: (MacroAssemblerX86): (JSC::MacroAssemblerX86::moveWithPatch): * assembler/MacroAssemblerX86Common.h: * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branchTest8): * assembler/X86Assembler.h: (JSC::X86Assembler::cmpb_im): (JSC::X86Assembler::codeSize): (JSC::X86Assembler::label): (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): * bytecode/CodeBlock.h: (JSC::CodeBlock::appendOSRExit): (JSC::CodeBlock::appendSpeculationRecovery): (DFGData): * bytecode/DFGExitProfile.h: (JSC::DFG::exitKindToString): (JSC::DFG::exitKindIsCountable): * bytecode/Instruction.h: * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): * bytecode/Watchpoint.cpp: Removed. * bytecode/Watchpoint.h: Removed. * bytecompiler/BytecodeGenerator.cpp: (JSC::ResolveResult::checkValidity): (JSC::BytecodeGenerator::addGlobalVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolve): (JSC::BytecodeGenerator::emitResolve): (JSC::BytecodeGenerator::emitResolveWithBase): (JSC::BytecodeGenerator::emitResolveWithThis): (JSC::BytecodeGenerator::emitGetStaticVar): (JSC::BytecodeGenerator::emitPutStaticVar): * bytecompiler/BytecodeGenerator.h: (BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): (JSC::PostfixResolveNode::emitBytecode): (JSC::PrefixResolveNode::emitBytecode): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::clobberStructures): * dfg/DFGAbstractState.h: (AbstractState): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArguments): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::globalVarStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGCorrectableJumpPoint.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGNode.h: (JSC::DFG::Node::hasRegisterPointer): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::appendCallSetResult): (JSC::DFG::SpeculativeJIT::speculationCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: * jit/JITStubs.cpp: * jit/JITStubs.h: * llint/LLIntSlowPaths.cpp: * llint/LLIntSlowPaths.h: (LLInt): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSObject.cpp: (JSC::JSObject::removeDirect): * runtime/JSObject.h: (JSObject): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: Removed. * runtime/SymbolTable.h: (JSC): (JSC::SymbolTableEntry::isNull): (JSC::SymbolTableEntry::getIndex): (SymbolTableEntry): (JSC::SymbolTableEntry::getAttributes): (JSC::SymbolTableEntry::isReadOnly): (JSC::SymbolTableEntry::pack): (JSC::SymbolTableEntry::isValidIndex): 2012-06-12 Filip Pizlo DFG should be able to set watchpoints on global variables https://bugs.webkit.org/show_bug.cgi?id=88692 Reviewed by Geoffrey Garen. This implements global variable constant folding by allowing the optimizing compiler to set a "watchpoint" on globals that it wishes to constant fold. If the watchpoint fires, then an OSR exit is forced by overwriting the machine code that the optimizing compiler generated with a jump. As such, this patch is adding quite a bit of stuff: - Jump replacement on those hardware targets supported by the optimizing JIT. It is now possible to patch in a jump instruction over any recorded watchpoint label. The jump must be "local" in the sense that it must be within the range of the largest jump distance supported by a one instruction jump. - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node that records the location where a jump must be inserted and the destination to which it should jump. Watchpoints can be added to a WatchpointSet. The WatchpointSet can be fired all at once, which plants all jumps. WatchpointSet also remembers if it had ever been invalidated, which allows for monotonicity: we typically don't want to optimize using watchpoints on something for which watchpoints had previously fired. The act of notifying a WatchpointSet has a trivial fast path in case no Watchpoints are registered (one-byte load+branch). - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(), except that you don't have to emit branches. But, you need to know what WatchpointSet to add the resulting Watchpoint to. Not everything that you could write a speculationCheck() for will have a WatchpointSet that would get notified if the condition you were speculating against became invalid. - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can do so without incurring any space overhead for those entries that don't have WatchpointSets. - The bytecode generator infers all global function variables to be watchable, and makes all stores perform the WatchpointSet's write check, and marks all loads as being potentially watchable (i.e. you can compile them to a watchpoint and a constant). Put together, this allows for fully sleazy inlining of calls to globally declared functions. The inline prologue will no longer contain the load of the function, or any checks of the function you're calling. I.e. it's pretty much like the kind of inlining you would see in Java or C++. Furthermore, the watchpointing functionality is built to be fairly general, and should allow setting watchpoints on all sorts of interesting things in the future. The sleazy inlining means that we will now sometimes inline in code paths that have never executed. Previously, to inline we would have either had to have executed the call (to read the call's inline cache) or have executed the method check (to read the method check's inline cache). Now, we might inline when the callee is a watched global variable. This revealed some humorous bugs. First, constant folding disagreed with CFA over what kinds of operations can clobber (example: code path A is dead but stores a String into variable X, all other code paths store 0 into X, and then you do CompareEq(X, 0) - CFA will say that this is a non- clobbering constant, but constant folding thought it was clobbering because it saw the String prediction). Second, inlining would crash if the inline callee had not been compiled. This patch fixes both bugs, since otherwise run-javascriptcore-tests would report regressions. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * assembler/ARMv7Assembler.h: (ARMv7Assembler): (JSC::ARMv7Assembler::ARMv7Assembler): (JSC::ARMv7Assembler::labelForWatchpoint): (JSC::ARMv7Assembler::label): (JSC::ARMv7Assembler::replaceWithJump): (JSC::ARMv7Assembler::maxJumpReplacementSize): * assembler/AbstractMacroAssembler.h: (JSC): (AbstractMacroAssembler): (Label): (JSC::AbstractMacroAssembler::watchpointLabel): * assembler/AssemblerBuffer.h: * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::replaceWithJump): (MacroAssemblerARM): (JSC::MacroAssemblerARM::maxJumpReplacementSize): * assembler/MacroAssemblerARMv7.h: (MacroAssemblerARMv7): (JSC::MacroAssemblerARMv7::replaceWithJump): (JSC::MacroAssemblerARMv7::maxJumpReplacementSize): (JSC::MacroAssemblerARMv7::branchTest8): (JSC::MacroAssemblerARMv7::jump): (JSC::MacroAssemblerARMv7::makeBranch): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::replaceWithJump): (MacroAssemblerMIPS): (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::replaceWithJump): (MacroAssemblerSH4): (JSC::MacroAssemblerSH4::maxJumpReplacementSize): * assembler/MacroAssemblerX86.h: (MacroAssemblerX86): (JSC::MacroAssemblerX86::branchTest8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::replaceWithJump): (MacroAssemblerX86Common): (JSC::MacroAssemblerX86Common::maxJumpReplacementSize): * assembler/MacroAssemblerX86_64.h: (MacroAssemblerX86_64): (JSC::MacroAssemblerX86_64::branchTest8): * assembler/X86Assembler.h: (JSC::X86Assembler::X86Assembler): (X86Assembler): (JSC::X86Assembler::cmpb_im): (JSC::X86Assembler::testb_im): (JSC::X86Assembler::labelForWatchpoint): (JSC::X86Assembler::label): (JSC::X86Assembler::replaceWithJump): (JSC::X86Assembler::maxJumpReplacementSize): (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): * bytecode/CodeBlock.h: (JSC::CodeBlock::appendOSRExit): (JSC::CodeBlock::appendSpeculationRecovery): (CodeBlock): (JSC::CodeBlock::appendWatchpoint): (JSC::CodeBlock::numberOfWatchpoints): (JSC::CodeBlock::watchpoint): (DFGData): * bytecode/DFGExitProfile.h: (JSC::DFG::exitKindToString): (JSC::DFG::exitKindIsCountable): * bytecode/Instruction.h: (Instruction): (JSC::Instruction::Instruction): * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): * bytecode/Watchpoint.cpp: Added. (JSC): (JSC::Watchpoint::~Watchpoint): (JSC::Watchpoint::correctLabels): (JSC::Watchpoint::fire): (JSC::WatchpointSet::WatchpointSet): (JSC::WatchpointSet::~WatchpointSet): (JSC::WatchpointSet::add): (JSC::WatchpointSet::notifyWriteSlow): (JSC::WatchpointSet::fireAllWatchpoints): * bytecode/Watchpoint.h: Added. (JSC): (Watchpoint): (JSC::Watchpoint::Watchpoint): (JSC::Watchpoint::setDestination): (WatchpointSet): (JSC::WatchpointSet::isStillValid): (JSC::WatchpointSet::hasBeenInvalidated): (JSC::WatchpointSet::startWatching): (JSC::WatchpointSet::notifyWrite): (JSC::WatchpointSet::addressOfIsWatched): * bytecompiler/BytecodeGenerator.cpp: (JSC::ResolveResult::checkValidity): (JSC::BytecodeGenerator::addGlobalVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolve): (JSC::BytecodeGenerator::emitResolve): (JSC::BytecodeGenerator::emitResolveWithBase): (JSC::BytecodeGenerator::emitResolveWithThis): (JSC::BytecodeGenerator::emitGetStaticVar): (JSC::BytecodeGenerator::emitPutStaticVar): * bytecompiler/BytecodeGenerator.h: (BytecodeGenerator): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallResolveNode::emitBytecode): (JSC::PostfixResolveNode::emitBytecode): (JSC::PrefixResolveNode::emitBytecode): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::clobberStructures): * dfg/DFGAbstractState.h: (AbstractState): (JSC::DFG::AbstractState::didClobber): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCCallHelpers.h: (CCallHelpers): (JSC::DFG::CCallHelpers::setupArguments): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::globalVarWatchpointElimination): (CSEPhase): (JSC::DFG::CSEPhase::globalVarStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGCorrectableJumpPoint.h: (JSC::DFG::CorrectableJumpPoint::isSet): (CorrectableJumpPoint): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifierNumberForCheck): (Node): (JSC::DFG::Node::identifierNumberForCheck): (JSC::DFG::Node::hasRegisterPointer): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExit.h: (OSRExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::appendCall): (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::speculationWatchpoint): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_global_var_check): (JSC): (JSC::JIT::emitSlow_op_put_global_var_check): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_global_var_check): (JSC): (JSC::JIT::emitSlow_op_put_global_var_check): * jit/JITStubs.cpp: (JSC::JITThunks::JITThunks): (JSC::DEFINE_STUB_FUNCTION): (JSC): * jit/JITStubs.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (LLInt): * llint/LLIntSlowPaths.h: (LLInt): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSObject.cpp: (JSC::JSObject::removeDirect): * runtime/JSObject.h: (JSObject): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: Added. (JSC): (JSC::SymbolTableEntry::copySlow): (JSC::SymbolTableEntry::freeFatEntrySlow): (JSC::SymbolTableEntry::couldBeWatched): (JSC::SymbolTableEntry::attemptToWatch): (JSC::SymbolTableEntry::addressOfIsWatched): (JSC::SymbolTableEntry::addWatchpoint): (JSC::SymbolTableEntry::notifyWriteSlow): (JSC::SymbolTableEntry::inflateSlow): * runtime/SymbolTable.h: (JSC): (SymbolTableEntry): (Fast): (JSC::SymbolTableEntry::Fast::Fast): (JSC::SymbolTableEntry::Fast::isNull): (JSC::SymbolTableEntry::Fast::getIndex): (JSC::SymbolTableEntry::Fast::isReadOnly): (JSC::SymbolTableEntry::Fast::getAttributes): (JSC::SymbolTableEntry::Fast::isFat): (JSC::SymbolTableEntry::SymbolTableEntry): (JSC::SymbolTableEntry::~SymbolTableEntry): (JSC::SymbolTableEntry::operator=): (JSC::SymbolTableEntry::isNull): (JSC::SymbolTableEntry::getIndex): (JSC::SymbolTableEntry::getFast): (JSC::SymbolTableEntry::getAttributes): (JSC::SymbolTableEntry::isReadOnly): (JSC::SymbolTableEntry::watchpointSet): (JSC::SymbolTableEntry::notifyWrite): (FatEntry): (JSC::SymbolTableEntry::FatEntry::FatEntry): (JSC::SymbolTableEntry::isFat): (JSC::SymbolTableEntry::fatEntry): (JSC::SymbolTableEntry::inflate): (JSC::SymbolTableEntry::bits): (JSC::SymbolTableEntry::freeFatEntry): (JSC::SymbolTableEntry::pack): (JSC::SymbolTableEntry::isValidIndex): 2012-06-12 Filip Pizlo Unreviewed build fix for ARMv7 debug builds. * jit/JITStubs.cpp: (JSC::JITThunks::JITThunks): 2012-06-12 Geoffrey Garen Build fix for case-sensitive file systems: use the right case. * heap/ListableHandler.h: 2012-06-11 Geoffrey Garen GC should be 1.7X faster https://bugs.webkit.org/show_bug.cgi?id=88840 Reviewed by Oliver Hunt. I profiled, and removed anything that showed up as a concurrency bottleneck. Then, I added 3 threads to our max thread count, since we can scale up to more threads now. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::BlockAllocator): (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::releaseFreeBlocks): (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): (JSC::BlockAllocator::waitForRelativeTime): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (BlockAllocator): (JSC::BlockAllocator::allocate): (JSC::BlockAllocator::deallocate): Use a spin lock for the common case where we're just popping a linked list. (A pthread mutex would sleep our thread even if the lock were only contended for a microsecond.) Scope the lock to avoid holding it while allocating VM, since that's a slow activity and it doesn't modify any of our data structures. We still use a pthread mutex to handle our condition variable since we have to, and it's not a hot path. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::CopiedSpace): (JSC::CopiedSpace::doneFillingBlock): * heap/CopiedSpace.h: (JSC::CopiedSpace::CopiedSpace): Use a spin lock for the to space lock, since it just guards linked list and hash table manipulation. * heap/MarkStack.cpp: (JSC::MarkStackSegmentAllocator::MarkStackSegmentAllocator): (JSC::MarkStackSegmentAllocator::allocate): (JSC::MarkStackSegmentAllocator::release): (JSC::MarkStackSegmentAllocator::shrinkReserve): Use a spin lock, since we're just managing a linked list. (JSC::MarkStackArray::donateSomeCellsTo): Changed donation to be proportional to our current stack size. This fixes cases where we used to donate too much. Interestingly, donating too much was starving the donor (when it ran out of work later) *and* the recipient (since it had to wait on a long donation operation to complete before it could acquire the lock). In the worst case, we're still guaranteed to donate N cells in roughly log N time. This change also fixes cases where we used to donate too little, since we would always keep a fixed minimum number of cells. In the worst case, with N marking threads, would could have N large object graph roots in our stack for the duration of GC, and scale to only 1 thread. It's an interesting observation that a single object in the mark stack might represent an arbitrarily large object graph -- and only the act of marking can find out. (JSC::MarkStackArray::stealSomeCellsFrom): Steal in proportion to idle threads. Once again, this fixes cases where constants could cause us to steal too much or too little. (JSC::SlotVisitor::donateKnownParallel): Always wake up other threads if they're idle. We can afford to do this because we're conservative about when we donate. (JSC::SlotVisitor::drainFromShared): * heap/MarkStack.h: (MarkStackSegmentAllocator): (MarkStackArray): (JSC): * heap/SlotVisitor.h: Merged the "should I donate?" decision into a single function, for simplicity. * runtime/Options.cpp: (minimumNumberOfScansBetweenRebalance): Reduced the delay before donation a lot. We can afford to do this because, in the common case, donation is a single branch that decides not to donate. (cpusToUse): Use more CPUs now, since we scale better now. * runtime/Options.h: (Options): Removed now-unused variables. 2012-06-12 Filip Pizlo REGRESSION(120121): inspector tests crash in DFG https://bugs.webkit.org/show_bug.cgi?id=88941 Reviewed by Geoffrey Garen. The CFG simplifier has two different ways of fixing up GetLocal, Phantom, and Flush. If we've already fixed up the node one way, we shouldn't try the other way. The reason why we shouldn't is that the second way depends on the node referring to other nodes in the to-be-jettisoned block. After fixup they potentially will refer to nodes in the block being merged to. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): (JSC::DFG::CFGSimplificationPhase::mergeBlocks): 2012-06-12 Leo Yang Dynamic hash table in DOMObjectHashTableMap is wrong in multiple threads https://bugs.webkit.org/show_bug.cgi?id=87334 Reviewed by Geoffrey Garen. Add a copy member function to JSC::HasTable. This function will copy all data members except for *table* which contains thread specific data that prevents up copying it. When you want to copy a JSC::HashTable that was constructed on another thread you should call JSC::HashTable::copy(). * runtime/Lookup.h: (JSC::HashTable::copy): (HashTable): 2012-06-12 Filip Pizlo DFG should not ASSERT if you have a double use of a variable that is not revealed to be a double until after CFG simplification https://bugs.webkit.org/show_bug.cgi?id=88927 Reviewed by Geoffrey Garen. Speculation fixup needs to run if simplification did things, because simplification can change predictions - particularly if you had a control flow path that stored weird things into a variable, but that path got axed by the simplifier. Running fixup in the fixpoint requires making it idempotent, which it previously wasn't. Only one place needed to be changed, namely the un-MustGenerate-ion of ValueToInt32. * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2012-06-12 Filip Pizlo REGRESSION (r119779): Javascript TypeError: 'undefined' is not an object https://bugs.webkit.org/show_bug.cgi?id=88783 Reviewed by Geoffrey Garen. If you don't keep alive the base of an object access over the various checks you do for the prototype chain, you're going to have a bad time. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): 2012-06-12 Hojong Han Property names of the built-in object cannot be retrieved after trying to delete one of its properties https://bugs.webkit.org/show_bug.cgi?id=86461 Reviewed by Gavin Barraclough. * runtime/JSObject.cpp: (JSC::getClassPropertyNames): (JSC::JSObject::getOwnPropertyNames): 2012-06-11 Gyuyoung Kim [CMAKE][EFL] Remove duplicated executable output path https://bugs.webkit.org/show_bug.cgi?id=88765 Reviewed by Daniel Bates. CMake files for EFL port have redefined executable output path. However, EFL port doesn't need to define again because it is already defined in top-level CMake file. * shell/CMakeLists.txt: 2012-06-11 Carlos Garcia Campos Unreviewed. Fix make distcheck issues. * GNUmakefile.list.am: Remove non existent header file. 2012-06-10 Patrick Gansterer Unreviewed. Build fix for !ENABLE(JIT) after r119844 and r119925. * runtime/Executable.h: (ExecutableBase): (JSC::ExecutableBase::clearCodeVirtual): 2012-06-10 Patrick Gansterer Unreviewed. Build fix for !ENABLE(JIT) after r119844. * runtime/Executable.h: (ExecutableBase): (JSC): 2012-06-09 Dominic Cooney [Chromium] Remove JavaScriptCore dependencies from gyp https://bugs.webkit.org/show_bug.cgi?id=88510 Reviewed by Adam Barth. Chromium doesn't support JSC any more and there doesn't seem to be a strong interest in using GYP as the common build system in other ports. * JavaScriptCore.gyp/JavaScriptCore.gyp: WebCore still depends on YARR interpreter. * JavaScriptCore.gypi: Only include YARR source. * gyp/JavaScriptCore.gyp: Removed. * gyp/gtk.gyp: Removed. 2012-06-09 Geoffrey Garen Unreviewed, rolling back in part2 of r118646. This patch removes eager finalization. Weak pointer finalization should be lazy https://bugs.webkit.org/show_bug.cgi?id=87599 Reviewed by Sam Weinig. * heap/Heap.cpp: (JSC::Heap::collect): Don't finalize eagerly -- we'll do it lazily. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): Do sweep weak sets when sweeping a block, since we won't get another chance. * heap/MarkedBlock.h: (JSC::MarkedBlock::sweepWeakSet): * heap/MarkedSpace.cpp: (MarkedSpace::WeakSetSweep): * heap/MarkedSpace.h: (JSC::MarkedSpace::sweepWeakSets): Removed now-unused code. 2012-06-09 Sukolsak Sakshuwong Add UNDO_MANAGER flag https://bugs.webkit.org/show_bug.cgi?id=87908 Reviewed by Tony Chang. * Configurations/FeatureDefines.xcconfig: 2012-06-08 Geoffrey Garen Unreviewed, rolling back in part1 of r118646. This patch includes everything necessary for lazy finalization, but keeps eager finalization enabled for the time being. Weak pointer finalization should be lazy https://bugs.webkit.org/show_bug.cgi?id=87599 Reviewed by Sam Weinig. * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: (JSC::MarkedBlock::resetAllocator): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::resetAllocators): * heap/MarkedSpace.h: (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore. It will happen automatically when a weak set is swept. It's simpler to have only one canonical way for this to happen, and it wasn't buying us anything to do it eagerly. * heap/WeakBlock.cpp: (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know the sweep would be a no-op. If even one finalizer is pending, we need to run it, since we won't get another chance. * heap/WeakSet.cpp: (JSC::WeakSet::sweep): This loop can be simpler now that WeakBlock::sweep() does what we mean. Reset our allocator after a sweep because this is the optimal time to start trying to recycle old weak pointers. (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an allocator because we've swept already, and forcing a new sweep would be wasteful. * heap/WeakSet.h: (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink because the shrink may have removed the block the allocator was going to allocate out of. 2012-06-08 Gavin Barraclough Unreviewed roll out r119795. This broke jquery/core.html * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): * llint/LowLevelInterpreter.asm: * runtime/JSGlobalData.h: (JSGlobalData): * runtime/JSGlobalThis.cpp: (JSC::JSGlobalThis::setUnwrappedObject): * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSObject::createInheritorID): * runtime/JSObject.h: (JSObject): (JSC::JSObject::resetInheritorID): (JSC): (JSC::JSObject::offsetOfInheritorID): (JSC::JSObject::inheritorID): 2012-06-08 Filip Pizlo PredictedType should be called SpeculatedType https://bugs.webkit.org/show_bug.cgi?id=88477 Unreviewed, fix a renaming goof from http://trac.webkit.org/changeset/119660. I accidentally renamed ByteCodeParser::getPrediction to ByteCodeParser::getSpeculation. That was not the intent. This changes it back. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getPrediction): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::parseBlock): 2012-06-08 Andy Wingo Explictly mark stubs called by JIT as being internal https://bugs.webkit.org/show_bug.cgi?id=88552 Reviewed by Filip Pizlo. * dfg/DFGOSRExitCompiler.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * jit/HostCallReturnValue.h: * jit/JITStubs.cpp: * jit/JITStubs.h: * jit/ThunkGenerators.cpp: * llint/LLIntSlowPaths.h: Mark a bunch of stubs as being WTF_INTERNAL. Change most calls to SYMBOL_STRING_RELOCATION to LOCAL_REFERENCE, or GLOBAL_REFERENCE in the case of the wrappers to truly global symbols. * offlineasm/asm.rb: Generate LOCAL_REFERENCE instead of SYMBOL_STRING_RELOCATION. 2012-06-08 Geoffrey Garen Don't rely on weak pointers for eager CodeBlock finalization https://bugs.webkit.org/show_bug.cgi?id=88465 Reviewed by Gavin Barraclough. This is incompatible with lazy weak pointer finalization. I considered just making CodeBlock finalization lazy-friendly, but it turns out that the heap is already way up in CodeBlock's business when it comes to finalization, so I decided to finish the job and move full responsibility for CodeBlock finalization into the heap. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Maybe this will build. * debugger/Debugger.cpp: Updated for rename. * heap/Heap.cpp: (JSC::Heap::deleteAllCompiledCode): Renamed for consistency. Fixed a bug where we would not delete code for a code block that had been previously jettisoned. I don't know if this happens in practice -- I mostly did this to improve consistency with deleteUnmarkedCompiledCode. (JSC::Heap::deleteUnmarkedCompiledCode): New function, responsible for eager finalization of unmarked code blocks. (JSC::Heap::collect): Updated for rename. Updated to call deleteUnmarkedCompiledCode(), which takes care of jettisoned DFG code blocks too. (JSC::Heap::addCompiledCode): Renamed, since this points to all code now, not just functions. * heap/Heap.h: (Heap): Keep track of all user code, not just functions. This is a negligible additional overhead, since most code is function code. * runtime/Executable.cpp: (JSC::*::finalize): Removed these functions, since we don't rely on weak pointer finalization anymore. (JSC::FunctionExecutable::FunctionExecutable): Moved linked-list stuff into base class so all executables can be in the list. (JSC::EvalExecutable::clearCode): (JSC::ProgramExecutable::clearCode): (JSC::FunctionExecutable::clearCode): All we need to do is delete our CodeBlock -- that will delete all of its internal data structures. (JSC::FunctionExecutable::clearCodeIfNotCompiling): Factored out a helper function to improve clarity. * runtime/Executable.h: (JSC::ExecutableBase): Moved linked-list stuff into base class so all executables can be in the list. (JSC::NativeExecutable::create): (NativeExecutable): (ScriptExecutable): (JSC::ScriptExecutable::finishCreation): (JSC::EvalExecutable::create): (EvalExecutable): (JSC::ProgramExecutable::create): (ProgramExecutable): (FunctionExecutable): (JSC::FunctionExecutable::create): Don't use a finalizer -- the heap will call us back to destroy our code block. (JSC::FunctionExecutable::discardCode): Renamed to clearCodeIfNotCompiling() for clarity. (JSC::FunctionExecutable::isCompiling): New helper function, for clarity. (JSC::ScriptExecutable::clearCodeVirtual): New helper function, since the heap needs to make polymorphic calls to clear code. * runtime/JSGlobalData.cpp: (JSC::StackPreservingRecompiler::operator()): * runtime/JSGlobalObject.cpp: (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): Updated for renames. 2012-06-07 Filip Pizlo DFG should inline prototype chain accesses, and do the right things if the specific function optimization is available https://bugs.webkit.org/show_bug.cgi?id=88594 Reviewed by Gavin Barraclough. Looks like a 3% win on V8. * bytecode/CodeBlock.h: (JSC::Structure::prototypeForLookup): (JSC): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC): (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::GetByIdStatus): (JSC::GetByIdStatus::isSimple): (JSC::GetByIdStatus::chain): (JSC::GetByIdStatus::specificValue): (GetByIdStatus): * bytecode/StructureSet.h: (StructureSet): (JSC::StructureSet::singletonStructure): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::initGetByIdProto): (JSC::StructureStubInfo::initGetByIdChain): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): * dfg/DFGRepatch.cpp: (JSC::DFG::tryCacheGetByID): * jit/JITStubs.cpp: (JSC::JITThunks::tryCacheGetByID): * runtime/JSGlobalObject.h: (JSC::Structure::prototypeForLookup): (JSC): * runtime/Structure.h: (Structure): 2012-06-07 Gavin Barraclough Remove JSObject::m_inheritorID https://bugs.webkit.org/show_bug.cgi?id=88378 Reviewed by Geoff Garen. This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). Instead use a private named value in the object's property storage. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): - No need m_inheritorID to initialize! * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): - No need m_inheritorID to initialize! * llint/LowLevelInterpreter.asm: - No need m_inheritorID to initialize! * runtime/JSGlobalData.h: (JSGlobalData): - Added private name 'm_inheritorIDKey'. * runtime/JSGlobalThis.cpp: (JSC::JSGlobalThis::setUnwrappedObject): - resetInheritorID is now passed a JSGlobalData&. * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): - No m_inheritorID to be marked. (JSC::JSObject::createInheritorID): - Store the newly created inheritorID in the property map. * runtime/JSObject.h: (JSC::JSObject::resetInheritorID): - Remove the inheritorID from property storage. (JSC::JSObject::inheritorID): - Read the inheritorID from property storage. 2012-06-07 Gavin Barraclough Math.pow on iOS does not support denormal numbers. https://bugs.webkit.org/show_bug.cgi?id=88592 Reviewed by Filip Pizlo. Import an implementation from fdlibm, detect cases where it is safe to use the system implementation & where we should fall back to fdlibm. * runtime/MathObject.cpp: (JSC::isDenormal): (JSC::isEdgeCase): (JSC::mathPow): - On iOS, detect cases where denormal support may be required & use fdlibm in these cases. (JSC::mathProtoFuncPow): - Changed to use mathPow. (JSC::fdlibmScalbn): (JSC::fdlibmPow): - These functions imported from fdlibm; original style retained to ease future merging. 2012-06-07 Patrick Gansterer Unreviewed. Build fix for !ENABLE(JIT) after r119441. * interpreter/Interpreter.cpp: (JSC::Interpreter::privateExecute): 2012-06-07 Andy Wingo Unreviewed build fix after r119593. * llint/LLIntOfflineAsmConfig.h (OFFLINE_ASM_GLOBAL_LABEL): Fix uses of "name" to be "label", the macro's parameter. Otherwise we serialize mentions of the literal symbol "name" into the objcode. Causes a build error using GNU ld (not gold). 2012-06-06 Ryosuke Niwa Chromium build fix attempt. Why do we need to list these files in gyp!? * JavaScriptCore.gypi: 2012-06-06 Filip Pizlo PredictedType should be called SpeculatedType https://bugs.webkit.org/show_bug.cgi?id=88477 Rubber stamped by Gavin Barraclough. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shouldOptimizeNow): (JSC::CodeBlock::dumpValueProfiles): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): * bytecode/LazyOperandValueProfile.cpp: (JSC::LazyOperandValueProfileParser::prediction): * bytecode/LazyOperandValueProfile.h: (LazyOperandValueProfileParser): * bytecode/PredictedType.cpp: Removed. * bytecode/PredictedType.h: Removed. * bytecode/SpeculatedType.cpp: Copied from Source/JavaScriptCore/bytecode/PredictedType.cpp. (JSC::speculationToString): (JSC::speculationToAbbreviatedString): (JSC::speculationFromClassInfo): (JSC::speculationFromStructure): (JSC::speculationFromCell): (JSC::speculationFromValue): * bytecode/SpeculatedType.h: Copied from Source/JavaScriptCore/bytecode/PredictedType.h. (JSC): (JSC::isAnySpeculation): (JSC::isCellSpeculation): (JSC::isObjectSpeculation): (JSC::isFinalObjectSpeculation): (JSC::isFinalObjectOrOtherSpeculation): (JSC::isFixedIndexedStorageObjectSpeculation): (JSC::isStringSpeculation): (JSC::isArraySpeculation): (JSC::isFunctionSpeculation): (JSC::isInt8ArraySpeculation): (JSC::isInt16ArraySpeculation): (JSC::isInt32ArraySpeculation): (JSC::isUint8ArraySpeculation): (JSC::isUint8ClampedArraySpeculation): (JSC::isUint16ArraySpeculation): (JSC::isUint32ArraySpeculation): (JSC::isFloat32ArraySpeculation): (JSC::isFloat64ArraySpeculation): (JSC::isArgumentsSpeculation): (JSC::isActionableIntMutableArraySpeculation): (JSC::isActionableFloatMutableArraySpeculation): (JSC::isActionableTypedMutableArraySpeculation): (JSC::isActionableMutableArraySpeculation): (JSC::isActionableArraySpeculation): (JSC::isArrayOrOtherSpeculation): (JSC::isMyArgumentsSpeculation): (JSC::isInt32Speculation): (JSC::isDoubleRealSpeculation): (JSC::isDoubleSpeculation): (JSC::isNumberSpeculation): (JSC::isBooleanSpeculation): (JSC::isOtherSpeculation): (JSC::isEmptySpeculation): (JSC::mergeSpeculations): (JSC::mergeSpeculation): * bytecode/StructureSet.h: (JSC::StructureSet::speculationFromStructures): * bytecode/ValueProfile.h: (JSC::ValueProfileBase::ValueProfileBase): (JSC::ValueProfileBase::dump): (JSC::ValueProfileBase::computeUpdatedPrediction): (ValueProfileBase): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::mergeStateAtTail): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::speculateInt32Unary): (JSC::DFG::AbstractState::speculateNumberUnary): (JSC::DFG::AbstractState::speculateBooleanUnary): (JSC::DFG::AbstractState::speculateInt32Binary): (JSC::DFG::AbstractState::speculateNumberBinary): * dfg/DFGAbstractValue.h: (JSC::DFG::StructureAbstractValue::filter): (JSC::DFG::StructureAbstractValue::speculationFromStructures): (JSC::DFG::AbstractValue::AbstractValue): (JSC::DFG::AbstractValue::clear): (JSC::DFG::AbstractValue::isClear): (JSC::DFG::AbstractValue::makeTop): (JSC::DFG::AbstractValue::clobberStructures): (JSC::DFG::AbstractValue::isTop): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::merge): (JSC::DFG::AbstractValue::filter): (JSC::DFG::AbstractValue::validateIgnoringValue): (JSC::DFG::AbstractValue::validate): (JSC::DFG::AbstractValue::checkConsistency): (JSC::DFG::AbstractValue::dump): (AbstractValue): * dfg/DFGArgumentPosition.h: (JSC::DFG::ArgumentPosition::ArgumentPosition): (JSC::DFG::ArgumentPosition::mergeArgumentAwareness): (JSC::DFG::ArgumentPosition::prediction): (ArgumentPosition): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::getArgument): (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::getSpeculationWithoutOSRExit): (JSC::DFG::ByteCodeParser::getSpeculation): (InlineStackEntry): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleIntrinsic): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixDoubleEdge): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::nameOfVariableAccessData): (JSC::DFG::Graph::dump): (JSC::DFG::Graph::predictArgumentTypes): * dfg/DFGGraph.h: (JSC::DFG::Graph::getJSConstantSpeculation): (JSC::DFG::Graph::isPredictedNumerical): (JSC::DFG::Graph::byValIsPure): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::getSpeculation): * dfg/DFGNode.h: (JSC::DFG::Node::Node): (JSC::DFG::Node::getHeapPrediction): (JSC::DFG::Node::predictHeap): (JSC::DFG::Node::prediction): (JSC::DFG::Node::predict): (JSC::DFG::Node::shouldSpeculateInteger): (JSC::DFG::Node::shouldSpeculateDouble): (JSC::DFG::Node::shouldSpeculateNumber): (JSC::DFG::Node::shouldSpeculateBoolean): (JSC::DFG::Node::shouldSpeculateFinalObject): (JSC::DFG::Node::shouldSpeculateFinalObjectOrOther): (JSC::DFG::Node::shouldSpeculateArray): (JSC::DFG::Node::shouldSpeculateArguments): (JSC::DFG::Node::shouldSpeculateInt8Array): (JSC::DFG::Node::shouldSpeculateInt16Array): (JSC::DFG::Node::shouldSpeculateInt32Array): (JSC::DFG::Node::shouldSpeculateUint8Array): (JSC::DFG::Node::shouldSpeculateUint8ClampedArray): (JSC::DFG::Node::shouldSpeculateUint16Array): (JSC::DFG::Node::shouldSpeculateUint32Array): (JSC::DFG::Node::shouldSpeculateFloat32Array): (JSC::DFG::Node::shouldSpeculateFloat64Array): (JSC::DFG::Node::shouldSpeculateArrayOrOther): (JSC::DFG::Node::shouldSpeculateObject): (JSC::DFG::Node::shouldSpeculateCell): (Node): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::setPrediction): (JSC::DFG::PredictionPropagationPhase::mergePrediction): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::fillStorage): (JSC::DFG::SpeculativeJIT::writeBarrier): (JSC::DFG::GPRTemporary::GPRTemporary): (JSC::DFG::FPRTemporary::FPRTemporary): (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): (JSC::DFG::SpeculativeJIT::compileGetByValOnString): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayLength): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): (JSC::DFG::SpeculativeJIT::compileInstanceOf): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithMod): (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): (JSC::DFG::SpeculativeJIT::compileRegExpExec): * dfg/DFGSpeculativeJIT.h: (DFG): (JSC::DFG::ValueSource::forSpeculation): (SpeculativeJIT): (GPRTemporary): (FPRTemporary): (JSC::DFG::SpecDoubleOperand::SpecDoubleOperand): (JSC::DFG::SpecDoubleOperand::~SpecDoubleOperand): (JSC::DFG::SpecDoubleOperand::fpr): (JSC::DFG::SpecCellOperand::SpecCellOperand): (JSC::DFG::SpecCellOperand::~SpecCellOperand): (JSC::DFG::SpecCellOperand::gpr): (JSC::DFG::SpecBooleanOperand::SpecBooleanOperand): (JSC::DFG::SpecBooleanOperand::~SpecBooleanOperand): (JSC::DFG::SpecBooleanOperand::gpr): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpecDouble): (JSC::DFG::SpeculativeJIT::fillSpecCell): (JSC::DFG::SpeculativeJIT::fillSpecBoolean): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileDoubleCompare): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpecDouble): (JSC::DFG::SpeculativeJIT::fillSpecCell): (JSC::DFG::SpeculativeJIT::fillSpecBoolean): (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileDoubleCompare): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::predict): (JSC::DFG::VariableAccessData::nonUnifiedPrediction): (JSC::DFG::VariableAccessData::prediction): (JSC::DFG::VariableAccessData::argumentAwarePrediction): (JSC::DFG::VariableAccessData::mergeArgumentAwarePrediction): (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat): (VariableAccessData): 2012-06-06 Filip Pizlo Global object variable accesses should not require an extra load https://bugs.webkit.org/show_bug.cgi?id=88385 Reviewed by Gavin Barraclough and Geoffrey Garen. Previously, if you wanted to access a global variable, you'd first have to load the register array from the appropriate global object and then either load or store at an offset to the register array. This is because JSGlobalObject inherited from JSVariableObject, and JSVariableObject is designed with the pessimistic assumption that its register array may point into the call stack. This is never the case for global objects. Hence, even though the global object may add more registers at any time, it does not need to store them in a contiguous array. It can use a SegmentedVector or similar. This patch refactors global objects and variable objects as follows: - The functionality to track variables in an indexable array using a SymbolTable to map names to indices is moved into JSSymbolTableObject, which is now a supertype of JSVariableObject. JSVariableObject is now just a holder for a registers array and implements the registerAt() method that is left abstract in JSSymbolTableObject. Because all users of JSVariableObject know whether they are a JSStaticScopeObject, JSActivation, or JSGlobalObject, this "abstract" method is not virtual; instead the utility methods that would call registerAt() are now template functions that require you to know statically what subtype of JSSymbolTableObject you're using (JSVariableObject or something else), so that registerAt() can be statically bound. - A new class is added called JSSegmentedVariableObject, which only differs from JSVariableObject in how it allocates registers. It uses a SegmentedVector instead of manually managing a pointer to a contiguous slab of registers. This changes the interface somewhat; for example with JSVariableObject if you wanted to add a register you had to do it yourself since the JSVariableObject didn't know how the registers array ought to be allocated. With JSSegmentedVariableObject you can just call addRegisters(). JSSegmentedVariableObject preserves the invariant that once you get a pointer into a register, that pointer will continue to be valid so long as the JSSegmentedVariableObject is alive. This allows the JITs and interpreters to skip the extra load. - JSGlobalObject now inherits from JSSegmentedVariableObject. For now (and possibly forever) it is the only subtype of this new class. - The bytecode format is changed so that get_global_var and put_global_var have a pointer to the register directly rather than having an index. A convenience method is provided in JSSegmentedVariableObject to get the index given a a pointer, which is used for assertions and debug dumps. This appears to be a 1% across the board win. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): * bytecode/Instruction.h: (Instruction): (JSC::Instruction::Instruction): * bytecompiler/BytecodeGenerator.cpp: (JSC::ResolveResult::registerPointer): (JSC): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::retrieveLastUnaryOp): (JSC::BytecodeGenerator::resolve): (JSC::BytecodeGenerator::resolveConstDecl): (JSC::BytecodeGenerator::emitGetStaticVar): (JSC::BytecodeGenerator::emitPutStaticVar): * bytecompiler/BytecodeGenerator.h: (ResolveResult): (BytecodeGenerator): * dfg/DFGAssemblyHelpers.h: (AssemblyHelpers): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::globalVarLoadElimination): (JSC::DFG::CSEPhase::globalVarStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::globalObjectFor): (Graph): * dfg/DFGNode.h: (JSC::DFG::Node::hasVarNumber): (Node): (JSC::DFG::Node::hasRegisterPointer): (JSC::DFG::Node::registerPointer): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * heap/Heap.h: (Heap): (JSC::Heap::isWriteBarrierEnabled): (JSC): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::privateExecute): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_global_var): (JSC::JIT::emit_op_put_global_var): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_global_var): (JSC::JIT::emit_op_put_global_var): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSGlobalObject.cpp: (JSC): (JSC::JSGlobalObject::put): (JSC::JSGlobalObject::putDirectVirtual): (JSC::JSGlobalObject::defineOwnProperty): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::addStaticGlobals): (JSC::JSGlobalObject::getOwnPropertySlot): (JSC::JSGlobalObject::getOwnPropertyDescriptor): * runtime/JSGlobalObject.h: (JSGlobalObject): (JSC::JSGlobalObject::JSGlobalObject): (JSC): (JSC::JSGlobalObject::hasOwnPropertyForWrite): * runtime/JSSegmentedVariableObject.cpp: Added. (JSC): (JSC::JSSegmentedVariableObject::findRegisterIndex): (JSC::JSSegmentedVariableObject::addRegisters): (JSC::JSSegmentedVariableObject::visitChildren): * runtime/JSSegmentedVariableObject.h: Added. (JSC): (JSSegmentedVariableObject): (JSC::JSSegmentedVariableObject::registerAt): (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): (JSC::JSSegmentedVariableObject::finishCreation): * runtime/JSStaticScopeObject.cpp: (JSC::JSStaticScopeObject::put): (JSC::JSStaticScopeObject::putDirectVirtual): (JSC::JSStaticScopeObject::getOwnPropertySlot): * runtime/JSSymbolTableObject.cpp: Added. (JSC): (JSC::JSSymbolTableObject::destroy): (JSC::JSSymbolTableObject::deleteProperty): (JSC::JSSymbolTableObject::getOwnPropertyNames): (JSC::JSSymbolTableObject::putDirectVirtual): (JSC::JSSymbolTableObject::isDynamicScope): * runtime/JSSymbolTableObject.h: Added. (JSC): (JSSymbolTableObject): (JSC::JSSymbolTableObject::symbolTable): (JSC::JSSymbolTableObject::JSSymbolTableObject): (JSC::JSSymbolTableObject::finishCreation): (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/JSVariableObject.cpp: (JSC): * runtime/JSVariableObject.h: (JSVariableObject): (JSC::JSVariableObject::JSVariableObject): (JSC::JSVariableObject::finishCreation): (JSC): * runtime/WriteBarrier.h: 2012-06-06 Filip Pizlo DFG arguments access slow path should not crash if the arguments haven't been created https://bugs.webkit.org/show_bug.cgi?id=88471 Reviewed by Gavin Barraclough. * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (CCallHelpers): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-06-06 Michael Saboff ENH: Add Logging to GC Marking Phase https://bugs.webkit.org/show_bug.cgi?id=88364 Reviewed by Filip Pizlo. Log GC marking to stderr or a file. The logging in controlled with the define ENABLE_OBJECT_MARK_LOGGING in wtf/Platform.h. If DATA_LOG_TO_FILE in wtf/DataLog.cpp is set to 1, output is logged to a file otherwise it is logged to stderr. When logging is enabled, the GC is built single threaded since the log output from the various threads isn't buffered and output in a thread safe manner. * heap/Heap.cpp: (JSC::Heap::markRoots): * heap/MarkStack.cpp: (JSC::MarkStackThreadSharedData::resetChildren): (JSC::MarkStackThreadSharedData::childVisitCount): (JSC::MarkStackThreadSharedData::markingThreadMain): (JSC::MarkStackThreadSharedData::markingThreadStartFunc): (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): (JSC::MarkStackThreadSharedData::reset): * heap/MarkStack.h: (MarkStackThreadSharedData): (MarkStack): (JSC::MarkStack::sharedData): (JSC::MarkStack::resetChildCount): (JSC::MarkStack::childCount): (JSC::MarkStack::incrementChildCount): * runtime/JSArray.cpp: (JSC::JSArray::visitChildren): * runtime/JSCell.cpp: (JSC::JSCell::className): * runtime/JSCell.h: (JSCell): (JSC::JSCell::visitChildren): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/JSString.h: (JSString): * runtime/Structure.h: (JSC::MarkStack::internalAppend): 2012-06-06 Gavin Barraclough Assigning to a static property should not change iteration order https://bugs.webkit.org/show_bug.cgi?id=88401 Reviewed by Geoff Garen. A specific iteration order is not defined by the spec, but test-262 somewhat tenuously requires that it is at least stable, e.g. ch10/10.4/10.4.2/S10.4.2_A1.1_T1.js Whilst it is not clear that this behavior really arises from the specification, it would seem like common sense to conform to this. The problem here is that we allow properties in the structure to shadow those in the static table, and we iterate the properties in the structure first - which means that as values of existing properties are modified, their iteration order changes too. The easy fix is to iterate the properties from the static table first. This has a further benefit, since it will mean that user added properties will come after those present in the static table (respected the expected insertion-order). * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyNames): - Iterate static properties first. 2012-06-06 Andy Wingo Ensure consistent order of evaluation in LLInt slow paths https://bugs.webkit.org/show_bug.cgi?id=88409 Reviewed by Geoffrey Garen. * llint/LLIntSlowPaths.cpp: (slow_path_mul) (slow_path_sub) (slow_path_div) (slow_path_mod) (slow_path_lshift) (slow_path_rshift) (slow_path_urshift) (slow_path_bitand) (slow_path_bitor) (slow_path_bitxor): Avoid calling toNumber, toInt32, or toUInt32 multiple times without intervening sequence points. Fixes fast/js/exception-sequencing-binops.html with GCC 4.7 on x86-64 Linux, which reordered evaluation of the arguments to fmod. 2012-06-06 Andy Wingo [GTK] Enable the LLInt https://bugs.webkit.org/show_bug.cgi?id=88315 Reviewed by Filip Pizlo. * GNUmakefile.am: Add rules to generate LLIntDesiredOffsets.h and LLIntAssembly.h. * GNUmakefile.list.am: Add offlineasm and llint files to the dist. Add LLInt source files to the build. * llint/LowLevelInterpreter.asm (crash): Generate a store of 0xbbadbeef to a register, not to a constant. Otherwise, gas was failing to assemble result. * offlineasm/asm.rb (labelReference): Generate a SYMBOL_STRING_RELOCATION instead of a SYMBOL_STRING, so that we go through the PLT on ELF systems. 2012-06-06 Andy Wingo REGRESSION (r106478): None of the Paper.js JavaScript examples work https://bugs.webkit.org/show_bug.cgi?id=87158 Reviewed by Michael Saboff. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::resolve): If we have to bail out to dynamicResolve(), only skip static scopes from the head of the scope chain. Before, we were also skipping activations with direct eval as well, which was incorrect. 2012-06-06 Dan Bernstein Reverted r119567, the fix for , because it broke the 32-bit build. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): * llint/LowLevelInterpreter.asm: * runtime/JSGlobalData.h: (JSGlobalData): * runtime/JSGlobalThis.cpp: (JSC::JSGlobalThis::setUnwrappedObject): * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSObject::createInheritorID): * runtime/JSObject.h: (JSObject): (JSC::JSObject::resetInheritorID): (JSC): (JSC::JSObject::offsetOfInheritorID): (JSC::JSObject::inheritorID): 2012-06-05 Yuqiang Xian Improve Math.round and Math.floor intrinsic https://bugs.webkit.org/show_bug.cgi?id=88314 Reviewed by Filip Pizlo. Currently we call a native function from the JIT code to complete the "round" and "floor" operations. We could inline some fast paths especially for those positive values on the platforms where floating point truncation is supported. This brings 3% gain on Kraken, especially 32% on audio-oscillator, and slight win on SunSpider, measured on IA32. * jit/ThunkGenerators.cpp: (JSC::floorThunkGenerator): (JSC): (JSC::roundThunkGenerator): 2012-06-05 Gavin Barraclough Remove JSObject::m_inheritorID https://bugs.webkit.org/show_bug.cgi?id=88378 Reviewed by Geoff Garen. This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). Instead use a private named value in the object's property storage. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): - No need m_inheritorID to initialize! * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): - No need m_inheritorID to initialize! * llint/LowLevelInterpreter.asm: - No need m_inheritorID to initialize! * runtime/JSGlobalData.h: (JSGlobalData): - Added private name 'm_inheritorIDKey'. * runtime/JSGlobalThis.cpp: (JSC::JSGlobalThis::setUnwrappedObject): - resetInheritorID is now passed a JSGlobalData&. * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): - No m_inheritorID to be marked. (JSC::JSObject::createInheritorID): - Store the newly created inheritorID in the property map. * runtime/JSObject.h: (JSC::JSObject::resetInheritorID): - Remove the inheritorID from property storage. (JSC::JSObject::inheritorID): - Read the inheritorID from property storage. 2012-06-05 Filip Pizlo DFG CFG simplification should not attempt to deref nodes inside of an unreachable subgraph https://bugs.webkit.org/show_bug.cgi?id=88362 Reviewed by Gavin Barraclough. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::fixPhis): (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): 2012-06-05 Mark Hahnenberg Entry into JSC should CRASH() if the Heap is busy https://bugs.webkit.org/show_bug.cgi?id=88355 Reviewed by Geoffrey Garen. Interpreter::execute() returns jsNull() right now if we try to enter it while the Heap is busy (e.g. with a collection), which is okay, but some code paths that call Interpreter::execute() allocate objects before checking if the Heap is busy. Attempting to execute JS code while the Heap is busy should not be allowed and should be enforced by a release-mode CRASH() to prevent vague, unhelpful backtraces later on if somebody makes a mistake. Normally, recursively executing JS code is okay, e.g. for evals, but it should not occur during a Heap allocation or collection because the Heap is not guaranteed to be in a consistent state (especially during collections). We are protected from executing JS on the same Heap concurrently on two separate threads because they must each take a JSLock first. However, we are not protected from reentrant execution of JS on the same thread because JSLock allows reentrancy. Therefore, we should fail early if we detect an entrance into JS code while the Heap is busy. * heap/Heap.cpp: Changed Heap::collect so that it sets the m_operationInProgress field at the beginning of collection and then unsets it at the end so that it is set at all times throughout the duration of a collection rather than sporadically during various phases. There is no reason to unset during a collection because our collector does not currently support running additional JS between the phases of a collection. (JSC::Heap::getConservativeRegisterRoots): (JSC::Heap::markRoots): (JSC::Heap::collect): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): Crash if the Heap is busy. * runtime/Completion.cpp: Crash if the Heap is busy. We do it here before we call Interpreter::execute() because we do some allocation prior to calling execute() which could cause Heap corruption if, for example, that allocation caused a collection. (JSC::evaluate): 2012-06-05 Dongwoo Im Add 'isProtocolHandlerRegistered' and 'unregisterProtocolHandler'. https://bugs.webkit.org/show_bug.cgi?id=73176 Reviewed by Adam Barth. Two more APIs are added in Custom Scheme Handler specification. http://dev.w3.org/html5/spec/Overview.html#custom-handlers One is 'isProtocolHandlerRegistered' to query whether the specific URL is registered or not. The other is 'unregisterProtocolHandler' to remove the registered URL. * Configurations/FeatureDefines.xcconfig: Add a macro 'ENABLE_CUSTOM_SCHEME_HANDLER'. 2012-06-04 Filip Pizlo DFG CFG simplification should correct the variables at the head of the predecessor block https://bugs.webkit.org/show_bug.cgi?id=88284 Reviewed by Geoffrey Garen. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::mergeBlocks): 2012-06-04 Geoffrey Garen Unreviewed. Rolled out r119364 because it's still causing crashes (when running v8-earley in release builds of DRT) This time for sure! * heap/Heap.cpp: (JSC::Heap::collect): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): * heap/MarkedBlock.h: (JSC::MarkedBlock::resetAllocator): (JSC): * heap/MarkedSpace.cpp: (JSC::ResetAllocator::operator()): (JSC): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::sweepWeakSets): * heap/MarkedSpace.h: (MarkedSpace): * heap/WeakBlock.cpp: (JSC::WeakBlock::sweep): * heap/WeakSet.cpp: (JSC::WeakSet::sweep): (JSC::WeakSet::tryFindAllocator): * heap/WeakSet.h: (JSC::WeakSet::shrink): 2012-06-04 Filip Pizlo DFG arguments simplification should have rationalized handling of TearOffArguments https://bugs.webkit.org/show_bug.cgi?id=88206 Reviewed by Geoffrey Garen. - Accesses to the unmodified arguments register ought to have the same effect on alias/escape analysis of arguments as accesses to the mutable arguments register. - The existence of TearOffArguments should not get in the way of arguments aliasing. - TearOffArguments should be eliminated if CreateArguments is eliminated. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): 2012-06-04 Gavin Barraclough Remove enabledProfilerReference https://bugs.webkit.org/show_bug.cgi?id=88258 Reviewed by Michael Saboff. Make the enabled profiler a member of JSGlobalData, and switch code that accesses it to do so directly via the JSGlobalData, rather than holding a Profiler** reference to it. Do not pass the Profiler** reference to JIT code. This patch does not change the stack layout on entry into JIT code (passing an unused void* instead), since this is an intrusive change better handled in a separate patch. * interpreter/Interpreter.cpp: (JSC::Interpreter::throwException): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::privateExecute): * jit/JITCode.h: (JSC::JITCode::execute): - Don't pass Profiler** to JIT code. * 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): * jit/JITStubs.cpp: (JSC): (JSC::ctiTrampoline): (JSC::ctiVMThrowTrampoline): (JSC::ctiOpThrowNotCaught): (JSC::JITThunks::JITThunks): (JSC::DEFINE_STUB_FUNCTION): - For ARM_THUMB2, rename ENABLE_PROFILER_REFERENCE_OFFSET to FIRST_STACK_ARGUMENT (which is how it is being used). - For MIPS, remove ENABLE_PROFILER_REFERENCE_OFFSET. * jit/JITStubs.h: (JITStackFrame): (JSC): - Renamed enabledProfilerReference to unusedX. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * profiler/Profiler.cpp: (JSC): (JSC::Profiler::startProfiling): (JSC::Profiler::stopProfiling): * profiler/Profiler.h: (Profiler): - Removed s_sharedEnabledProfilerReference, enabledProfilerReference(). * runtime/JSGlobalData.cpp: (JSC::JSGlobalData::JSGlobalData): * runtime/JSGlobalData.h: (JSC): (JSC::JSGlobalData::enabledProfiler): (JSGlobalData): - Added m_enabledProfiler, enabledProfiler(). * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): 2012-06-04 Filip Pizlo get_argument_by_val should be profiled everywhere https://bugs.webkit.org/show_bug.cgi?id=88205 Reviewed by Geoffrey Garen. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_get_argument_by_val): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2012-06-04 Filip Pizlo DFG arguments simplification takes unkindly to direct accesses to the arguments register https://bugs.webkit.org/show_bug.cgi?id=88261 Reviewed by Geoffrey Garen. Fixed arguments simplification for direct accesses to the arguments register, which may arise if CSE had not run. Fixed CSE so that it does run prior to arguments simplification, by making it a full-fledged member of the fixpoint. Fixed other issues in arguments simplification, like realizing that it needs to bail if there is a direct assignment to the arguments register, and failing to turn CreateArguments into PhantomArguments. Also fixed CSE's handling of store elimination of captured locals in the presence of a GetMyArgumentByVal (or one of its friends), and fixed CSE to correctly fixup variables at tail if the Flush it removes is the last operation on a local in a basic block. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::setLocalStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): (CSEPhase): * dfg/DFGDriver.cpp: (JSC::DFG::compile): 2012-06-04 Anders Carlsson Fix a struct/class mismatch. * heap/Handle.h: (Handle): 2012-06-04 David Kilzer BUILD FIX: FeatureDefines.xcconfig should match across projects * Configurations/FeatureDefines.xcconfig: - Add missing ENABLE_LEGACY_CSS_VENDOR_PREFIXES. 2012-06-02 Geoffrey Garen Weak pointer finalization should be lazy https://bugs.webkit.org/show_bug.cgi?id=87599 Reviewed by Sam Weinig. This time for sure! * heap/Heap.cpp: (JSC::Heap::collect): Don't sweep eagerly -- we'll sweep lazily instead. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): Sweep our weak set before we sweep our other destructors -- this is our last chance to run weak set finalizers before we recycle our memory. * heap/MarkedBlock.h: (JSC::MarkedBlock::resetAllocator): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::resetAllocators): * heap/MarkedSpace.h: (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore. It will happen automatically when a weak set is swept. It's simpler to have only one canonical way for this to happen, and it wasn't buying us anything to do it eagerly. * heap/WeakBlock.cpp: (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know the sweep would be a no-op. If even one finalizer is pending, we need to run it, since we won't get another chance. * heap/WeakSet.cpp: (JSC::WeakSet::sweep): This loop can be simpler now that WeakBlock::sweep() does what we mean. Reset our allocator after a sweep because this is the optimal time to start trying to recycle old weak pointers. (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an allocator because we've swept already, and forcing a new sweep would be wasteful. * heap/WeakSet.h: (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink because the shrink may have removed the block the allocator was going to allocate out of. 2012-06-02 Filip Pizlo If the DFG bytecode parser detects that op_method_check has gone polymorphic, it shouldn't revert all the way to GetById/GetByIdFlush https://bugs.webkit.org/show_bug.cgi?id=88176 Reviewed by Geoffrey Garen. Refactored the code so that the op_method_check case of the parser gracefully falls through to all of the goodness of the normal op_get_by_id case. * dfg/DFGByteCodeParser.cpp: (ByteCodeParser): (JSC::DFG::ByteCodeParser::handleGetById): (DFG): (JSC::DFG::ByteCodeParser::parseBlock): 2012-06-02 Filip Pizlo DFG CSE should be able to eliminate unnecessary flushes of arguments and captured variables https://bugs.webkit.org/show_bug.cgi?id=87929 Reviewed by Geoffrey Garen. Slight speed-up on V8. Big win (up to 50%) on programs that inline very small functions. This required a bunch of changes: - The obvious change is making CSE essentially ignore whether or not the set of operations between the Flush and the SetLocal can exit, and instead focus on whether or not that set of operations can clobber the world or access local variables. This code is now refactored to return a set of flags indicating any of these events, and the CSE decides what to do based on those flags. If the set of operations is non-clobbering and non-accessing, then the Flush is turned into a Phantom on the child of the SetLocal. This expands the liveness of the relevant variable but virtually guarantees that it will be register allocated and not flushed to the stack. So, yeah, this patch is a lot of work to save a few stores to the stack. - Previously, CheckArgumentsNotCreated was optimized "lazily" in that you only knew if it was a no-op if you were holding onto a CFA abstract state. But this would make the CSE act pessimistically, since it doesn't use the CFA. Hence, this patch changes the constant folding phase into something more broad; it now fixes up CheckArgumentsNotCreated nodes by turning them into phantoms if it knows that they are no-ops. - Arguments simplification was previously relying on this very strange PhantomArguments node, which had two different meanings: for normal execution it meant the empty value but for OSR exit it meant that the arguments should be reified. This produces problems when set SetLocals to the captured arguments registers are CSE'd away, since we'd be triggering reification of arguments without having initialized the arguments registers to empty. The cleanest solution was to fix PhantomArguments to have one meaning: namely, arguments reification on OSR exit. Hence, this patch changes arguments simplification to change SetLocal of CreateArguments on the arguments registers to be a SetLocal of Empty. - Argument value recoveries were previously derived from the value source of the arguments at the InlineStart. But that relies on all SetLocals to arguments having been flushed. It's possible that we could have elided the SetLocal to the arguments at the callsite because there were subsequent SetLocals to the arguments inside of the callee, in which case the InlineStart would get the wrong information. Hence, this patch changes argument value recovery computation to operate over the ArgumentPositions directly. - But that doesn't actually work, because previously, there was no way to link an InlineStart back to the corresponding ArgumentPositions, at least not without some ugliness. So this patch instates the rule that the m_argumentPositions vector consists of disjoint subsequences such that each subsequence corresponds to an inline callsite and can be identified by its first index, and within each subsequence are the ArgumentPositions of all of the arguments ordered by argument index. This required flipping the order in which ArgumentPositions are added to the vector, and giving InlineStart an operand that indicates the start of that inline callsite's ArgumentPosition subsequence. - This patch also revealed a nasty bug in the reification of arguments in inline call frames on OSR exit. Since the reification was happening after the values of virtual registers were recovered, the value recoveries of the inline arguments were wrong. Hence using operationCreateInlinedArguments is wrong. For example a value recovery might say that you have to box a double, but if we had already boxed it then boxing it a second time will result in garbage. The specific case of this bug was this patch uncovered was that now it is possible for an inline call frame to not have any valid value recoveries for any inline arguments, if the optimization elides all argument flushes, while at the same time optimizing away arguments creation. Then OSR exit would try to recover the arguments using the inline call frame, which had bogus information, and humorous crashes would ensue. This patch fixes this issue by moving arguments reification to after call frame reification, so that arguments reification can always use operationCreateArguments instead of operationCreateInlinedArguments. - This patch may turn a Flush into a Phantom. That's kind of the whole point. But that broke forward speculation checks, which knew to look for a Flush prior to a SetLocal but didn't know that there could alternatively be a Phantom in place of the Flush. This patch fixes that by augmenting the forward speculation check logic. - Finally, in the process of having fun with all of the above, I realized that my DFG validation was not actually running on every phase like I had originally designed it to. In fact it was only running just after bytecode parsing. I initially tried to make it run in every phase but found that this causes some tests to timeout (specifically the evil fuzzing ones), so I decided on a compromise where: (i) in release mode validation never runs, (ii) in debug mode validation will run just after parsing and just before the backend, and (iii) it's possible with a simple switch to enable validation to run on every phase. Luckily all of the above issues were already covered by the 77 or so DFG-specific layout tests. Hence, this patch does not introduce any new tests despite being so meaty. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGArgumentPosition.h: (JSC::DFG::ArgumentPosition::prediction): (JSC::DFG::ArgumentPosition::doubleFormatState): (JSC::DFG::ArgumentPosition::shouldUseDoubleFormat): (ArgumentPosition): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::SetLocalStoreEliminationResult::SetLocalStoreEliminationResult): (SetLocalStoreEliminationResult): (JSC::DFG::CSEPhase::setLocalStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCommon.h: * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGNode.h: (Node): (JSC::DFG::Node::hasArgumentPositionStart): (JSC::DFG::Node::argumentPositionStart): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPhase.cpp: (DFG): * dfg/DFGPhase.h: (Phase): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-06-02 Geoffrey Garen DOM string cache should hash pointers, not characters https://bugs.webkit.org/show_bug.cgi?id=88175 Reviewed by Phil Pizlo and Sam Weinig. * heap/Weak.h: (JSC::weakAdd): (JSC::weakRemove): Made these function templates slightly more generic to accommodate new client types. 2012-06-01 Filip Pizlo DFG CFA should know that PutByVal can clobber the world https://bugs.webkit.org/show_bug.cgi?id=88155 Reviewed by Gavin Barraclough. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): 2012-06-01 Filip Pizlo DFG CFA should mark basic blocks as having constants if local accesses yield constants https://bugs.webkit.org/show_bug.cgi?id=88153 Reviewed by Gavin Barraclough. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): 2012-06-01 Filip Pizlo DFG arguments simplification phase uses a node.codeOrigin after appending a node https://bugs.webkit.org/show_bug.cgi?id=88151 Reviewed by Geoffrey Garen. The right thing to do is to save the CodeOrigin before appending to the graph. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): 2012-06-01 Filip Pizlo DFG should not emit unnecessary speculation checks when performing an int32 to double conversion on a value that is proved to be a number, predicted to be an int32, but not proved to be an int32 https://bugs.webkit.org/show_bug.cgi?id=88146 Reviewed by Gavin Barraclough. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): 2012-06-01 Filip Pizlo DFG constant folding search for the last local access skips the immediately previous local access https://bugs.webkit.org/show_bug.cgi?id=88141 Reviewed by Michael Saboff. If you use a loop in the style of: for (i = start; i--;) then you need to remember that the first value of 'i' that the loop body will see is 'start - 1'. Hence the following is probably wrong: for (i = start - 1; i--;) * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): 2012-06-01 Filip Pizlo DFG constant folding should be OK with GetLocal of captured variables having a constant https://bugs.webkit.org/show_bug.cgi?id=88137 Reviewed by Gavin Barraclough. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): 2012-05-31 Mark Hahnenberg JSGlobalObject does not mark m_privateNameStructure https://bugs.webkit.org/show_bug.cgi?id=88023 Rubber stamped by Gavin Barraclough. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::visitChildren): We need to mark this so it doesn't get inadvertently garbage collected. 2012-05-31 Erik Arvidsson Make DOM Exceptions Errors https://bugs.webkit.org/show_bug.cgi?id=85078 Reviewed by Oliver Hunt. WebIDL mandates that exceptions should have Error.prototype on its prototype chain. For JSC we have access to the Error.prototype from the binding code. For V8 we set a field in the WrapperTypeInfo and when the constructor function is created we set the prototype as needed. Updated test: fast/dom/DOMException/prototype-object.html * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: (JSC): (JSGlobalObject): (JSC::JSGlobalObject::errorPrototype): 2012-05-31 Andy Wingo Fix reference to unset variable in debug mode https://bugs.webkit.org/show_bug.cgi?id=87981 Reviewed by Geoffrey Garen. * runtime/JSONObject.cpp (Stringifier::Holder::Holder): Initialize m_size in debug mode, as we check it later in an assert. 2012-05-30 Mark Hahnenberg Heap should sweep incrementally https://bugs.webkit.org/show_bug.cgi?id=85429 We shouldn't have to wait for the opportunistic GC timer to fire in order to call object destructors. Instead, we should incrementally sweep some subset of the blocks requiring sweeping periodically. We tie this sweeping to a timer rather than to collections because we want to reclaim this memory even if we stop allocating. This way, our memory usage scales smoothly with actual use, regardless of whether we've recently done an opportunistic GC or not. Reviewed by Geoffrey Garen. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.gypi: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::collect): We no longer sweep during a full sweep. We only shrink now, which we will switch over to being done during incremental sweeping too as soon as all finalizers can be run lazily (and, by extension, incrementally). (JSC::Heap::sweeper): (JSC): * heap/Heap.h: (JSC): (Heap): * heap/IncrementalSweeper.cpp: Added. (JSC): (JSC::IncrementalSweeper::timerDidFire): The IncrementalSweeper works very similarly to GCActivityCallback. It is tied to a run-loop based timer that fires periodically based on how long the previous sweep increment took to run. The IncrementalSweeper doesn't do anything if the platform doesn't support CoreFoundation. (JSC::IncrementalSweeper::IncrementalSweeper): (JSC::IncrementalSweeper::~IncrementalSweeper): (JSC::IncrementalSweeper::create): (JSC::IncrementalSweeper::scheduleTimer): (JSC::IncrementalSweeper::cancelTimer): (JSC::IncrementalSweeper::doSweep): Iterates over the snapshot of the MarkedSpace taken during the last collection, checking to see which blocks need sweeping. If it successfully gets to the end of the blocks that need sweeping then it cancels the timer. (JSC::IncrementalSweeper::startSweeping): We take a snapshot of the Heap and store it in a Vector that the incremental sweep will iterate over. We also reset our index into this Vector. * heap/IncrementalSweeper.h: Added. (JSC): (IncrementalSweeper): * heap/MarkedBlock.h: (JSC::MarkedBlock::needsSweeping): If a block is in the Marked state it needs sweeping to be usable and to run any destructors that need to be run. 2012-05-30 Patrick Gansterer [WINCE] Fix JSString after r115516. https://bugs.webkit.org/show_bug.cgi?id=87892 Reviewed by Geoffrey Garen. r115516 splitted JSString into two classes, with addition nested classes. Add a workaround for the WinCE compiler since it can't resolve the friend class declerations corretly and denies the access to protected members of JSString. * runtime/JSString.h: (JSC::JSRopeString::RopeBuilder::append): (JSC::JSRopeString::append): (JSRopeString): 2012-05-30 Oliver Hunt Really provide error information with the inspector disabled https://bugs.webkit.org/show_bug.cgi?id=87910 Reviewed by Filip Pizlo. Don't bother checking for anything other than pre-existing error info. In the absence of complete line number information you'll only get the line a function starts on, but at least it's something. * interpreter/Interpreter.cpp: (JSC::Interpreter::throwException): 2012-05-30 Filip Pizlo LLInt broken on x86-32 with JIT turned off https://bugs.webkit.org/show_bug.cgi?id=87906 Reviewed by Geoffrey Garen. Fixed the code to not clobber registers that contain important things, like the call frame. * llint/LowLevelInterpreter32_64.asm: 2012-05-30 Filip Pizlo ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it https://bugs.webkit.org/show_bug.cgi?id=87887 Reviewed by Darin Adler. Better fix - we now never call SourceProvider::asID() if SourceProvider* is 0. * parser/Nodes.h: (JSC::ScopeNode::sourceID): * parser/SourceCode.h: (JSC::SourceCode::providerID): (SourceCode): * parser/SourceProvider.h: (SourceProvider): (JSC::SourceProvider::asID): * runtime/Executable.h: (JSC::ScriptExecutable::sourceID): 2012-05-30 Filip Pizlo ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it https://bugs.webkit.org/show_bug.cgi?id=87887 Reviewed by Geoffrey Garen. * parser/SourceProvider.h: (JSC::SourceProvider::asID): 2012-05-30 Oliver Hunt DFG does not correctly handle exceptions caught in the LLInt https://bugs.webkit.org/show_bug.cgi?id=87885 Reviewed by Filip Pizlo. Make the DFG use genericThrow, rather than reimplementing a small portion of it. Also make the LLInt slow paths validate that their PC is correct. * dfg/DFGOperations.cpp: * llint/LLIntSlowPaths.cpp: (LLInt): 2012-05-29 Filip Pizlo DFG CFA should infer types and values of captured variables https://bugs.webkit.org/show_bug.cgi?id=87813 Reviewed by Gavin Barraclough. Slight speed-up in V8/earley-boyer (~1%). * bytecode/CodeBlock.h: (JSC::CodeBlock::argumentsAreCaptured): (JSC::CodeBlock::argumentIsCaptured): (CodeBlock): * dfg/DFGAbstractState.cpp: (DFG): (JSC::DFG::AbstractState::beginBasicBlock): (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::endBasicBlock): (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::clobberWorld): (JSC::DFG::AbstractState::clobberStructures): (JSC::DFG::AbstractState::mergeStateAtTail): (JSC::DFG::AbstractState::merge): (JSC::DFG::AbstractState::mergeToSuccessors): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::variables): (AbstractState): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-30 Patrick Gansterer Unreviewed. Build fix for !ENABLE(JIT) after r117823. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): 2012-05-30 Sheriff Bot Unreviewed, rolling out r118868. http://trac.webkit.org/changeset/118868 https://bugs.webkit.org/show_bug.cgi?id=87828 introduced ~20 crashes on Mac and Qt bots (Requested by pizlo_ on #webkit). * heap/Heap.cpp: (JSC::Heap::collect): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): * heap/MarkedBlock.h: (JSC::MarkedBlock::sweepWeakSet): (JSC): * heap/MarkedSpace.cpp: (JSC::SweepWeakSet::operator()): (JSC): (JSC::MarkedSpace::sweepWeakSets): * heap/MarkedSpace.h: (MarkedSpace): 2012-05-29 Geoffrey Garen Rolled back in r118646, now that https://bugs.webkit.org/show_bug.cgi?id=87784 is fixed. http://trac.webkit.org/changeset/118646 https://bugs.webkit.org/show_bug.cgi?id=87599 * heap/Heap.cpp: (JSC::Heap::collect): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): * heap/MarkedBlock.h: (JSC): * heap/MarkedSpace.cpp: (JSC): * heap/MarkedSpace.h: (MarkedSpace): 2012-05-29 Filip Pizlo DFG should keep captured variables alive until the (inline) return. https://bugs.webkit.org/show_bug.cgi?id=87205 Reviewed by Gavin Barraclough. Changes the way we do flushing for captured variables and arguments. Instead of flushing each SetLocal immediately, we flush at kill points. So a SetLocal will cause a Flush of whatever was live in the variable previously, and a return will cause a Flush of all captured variables and all arguments. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::set): (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::getArgument): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::findArgumentPositionForArgument): (ByteCodeParser): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::findArgumentPosition): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::setLocalStoreElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): 2012-05-29 Geoffrey Garen WeakGCMap should be lazy-finalization-safe https://bugs.webkit.org/show_bug.cgi?id=87784 Reviewed by Darin Adler. * runtime/WeakGCMap.h: (JSC::WeakGCMap::get): Since this is a map of raw WeakImpl pointers, and not Weak, we need to verify manually that the WeakImpl is live before we return its payload. 2012-05-29 Mark Hahnenberg CopiedSpace::doneCopying could start another collection https://bugs.webkit.org/show_bug.cgi?id=86538 Reviewed by Geoffrey Garen. It's possible that if we don't have anything at the head of to-space after a collection and the BlockAllocator doesn't have any fresh blocks to give us right now we could start another collection while still in the middle of the first collection when we call CopiedSpace::addNewBlock(). One way to resolve this would be to have Heap::shouldCollect() check that m_operationInProgress is NoOperation. This would prevent the path in getFreshBlock() that starts the collection if we're already in the middle of one. I could not come up with a test case to reproduce this crash on ToT. * heap/Heap.h: (JSC::Heap::shouldCollect): We shouldn't collect if we're already in the middle of a collection, i.e. the current operation should be NoOperation. 2012-05-29 David Barr Introduce ENABLE_CSS_IMAGE_RESOLUTION compile flag https://bugs.webkit.org/show_bug.cgi?id=87685 Reviewed by Eric Seidel. Add a configuration option for CSS image-resolution support, disabling it by default. * Configurations/FeatureDefines.xcconfig: 2012-05-28 Sheriff Bot Unreviewed, rolling out r118646. http://trac.webkit.org/changeset/118646 https://bugs.webkit.org/show_bug.cgi?id=87691 broke V8 raytrace benchmark (Requested by pizlo_ on #webkit). * heap/Heap.cpp: (JSC::Heap::collect): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): * heap/MarkedBlock.h: (JSC::MarkedBlock::sweepWeakSet): (JSC): * heap/MarkedSpace.cpp: (JSC::SweepWeakSet::operator()): (JSC): (JSC::MarkedSpace::sweepWeakSets): * heap/MarkedSpace.h: (MarkedSpace): 2012-05-28 Filip Pizlo DFG should not generate code for code that the CFA proves to be unreachable https://bugs.webkit.org/show_bug.cgi?id=87682 Reviewed by Sam Weinig. This also fixes a small performance bug where CFA was not marking blocks as having constants (and hence not triggering constant folding) if the only constants were on GetLocals. And fixing that bug revealed another bug: constant folding was assuming that a GetLocal must be the first access to a local in a basic block. This isn't true. The first access may be a Flush. This patch fixes that issue using the safest approach possible, since we don't need to be clever for something that only happens in one of our benchmarks. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-28 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.list.am: Add missing header file. 2012-05-27 Geoffrey Garen Weak pointer finalization should be lazy https://bugs.webkit.org/show_bug.cgi?id=87599 Reviewed by Darin Adler. * heap/Heap.cpp: (JSC::Heap::collect): Don't force immediate finalization -- it will happen lazily. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::sweep): Sweep a block's weak set when sweeping the block. The weak set may not have been swept yet, and this is our last chance to run weak finalizers before we recycle the memory they reference. * heap/MarkedBlock.h: * heap/MarkedSpace.cpp: (JSC::MarkedBlock::sweepWeakSets): * heap/MarkedSpace.h: (JSC::MarkedSpace::sweepWeakSets): Nixed sweepWeakSets because it's unused now. 2012-05-26 Geoffrey Garen WebKit should be lazy-finalization-safe (esp. the DOM) v2 https://bugs.webkit.org/show_bug.cgi?id=87581 Reviewed by Oliver Hunt. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::callDestructor): * heap/WeakBlock.h: * heap/WeakSetInlines.h: (JSC::WeakBlock::finalize): Since we don't guarantee destruction order, it's not valid to access GC pointers like the Structure pointer during finalization. We NULL out the structure pointer in debug builds to try to make this programming mistake more obvious. * API/JSCallbackConstructor.cpp: (JSC::JSCallbackConstructor::destroy): * API/JSCallbackObject.cpp: (JSC::::destroy): (JSC::JSCallbackObjectData::finalize): * runtime/Arguments.cpp: (JSC::Arguments::destroy): * runtime/DateInstance.cpp: (JSC::DateInstance::destroy): * runtime/Error.cpp: (JSC::StrictModeTypeErrorFunction::destroy): * runtime/Executable.cpp: (JSC::ExecutableBase::destroy): (JSC::NativeExecutable::destroy): (JSC::ScriptExecutable::destroy): (JSC::EvalExecutable::destroy): (JSC::ProgramExecutable::destroy): (JSC::FunctionExecutable::destroy): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::destroy): * runtime/JSPropertyNameIterator.cpp: (JSC::JSPropertyNameIterator::destroy): * runtime/JSStaticScopeObject.cpp: (JSC::JSStaticScopeObject::destroy): * runtime/JSString.cpp: (JSC::JSString::destroy): * runtime/JSVariableObject.cpp: (JSC::JSVariableObject::destroy): * runtime/NameInstance.cpp: (JSC::NameInstance::destroy): * runtime/RegExp.cpp: (JSC::RegExp::destroy): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::destroy): * runtime/Structure.cpp: (JSC::Structure::destroy): * runtime/StructureChain.cpp: (JSC::StructureChain::destroy): Use static_cast instead of jsCast because jsCast does Structure-based validation, and our Structure is not guaranteed to be alive when we get finalized. 2012-05-22 Filip Pizlo DFG CSE should eliminate redundant WeakJSConstants https://bugs.webkit.org/show_bug.cgi?id=87179 Reviewed by Gavin Barraclough. Merged r118141 from dfgopt. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::weakConstantCSE): (CSEPhase): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGNode.h: (JSC::DFG::Node::weakConstant): 2012-05-22 Filip Pizlo DFG CSE should do redundant store elimination https://bugs.webkit.org/show_bug.cgi?id=87161 Reviewed by Oliver Hunt. Merge r118138 from dfgopt. This patch adds redundant store elimination. For example, consider this code: o.x = 42; o.x = 84; If o.x is speculated to be a well-behaved field, the first assignment is unnecessary, since the second just overwrites it. We would like to eliminate the first assignment in these cases. The need for this optimization arises mostly from stores that our runtime requires. For example: o = {f:1, g:2, h:3}; This will have four assignments to the structure for the newly created object - one assignment for the empty structure, one for {f}, one for {f, g}, and one for {f, g, h}. We would like to only have the last of those assigments in this case. Intriguingly, doing so for captured variables breaks the way arguments simplification used to work. Consider that prior to either arguments simplification or store elimination we will have IR that looks like: a: SetLocal(r0, Empty) b: SetLocal(r1, Empty) c: GetLocal(r0) d: CreateArguments(@c) e: SetLocal(r0, @d) f: SetLocal(r1, @d) Then redundant store elimination will eliminate the stores that initialize the arguments registers to Empty, but then arguments simplification eliminates the stores that initialize the arguments to the newly created arguments - and at this point we no longer have any stores to the arguments register, leading to hilarious crashes. This patch therefore changes arguments simplification to replace CreateArguments with JSConstant(Empty) rather than eliminating the SetLocals. But this revealed bugs where arguments simplification was being overzealous, so I fixed those bugs. This is a minor speed-up on V8/early and a handful of other tests. * bytecode/CodeBlock.h: (JSC::CodeBlock::uncheckedActivationRegister): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses): (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::globalVarStoreElimination): (CSEPhase): (JSC::DFG::CSEPhase::putStructureStoreElimination): (JSC::DFG::CSEPhase::putByOffsetStoreElimination): (JSC::DFG::CSEPhase::setLocalStoreElimination): (JSC::DFG::CSEPhase::setReplacement): (JSC::DFG::CSEPhase::eliminate): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGGraph.h: (JSC::DFG::Graph::uncheckedActivationRegisterFor): (Graph): * dfg/DFGNode.h: (JSC::DFG::Node::isPhantomArguments): (Node): (JSC::DFG::Node::hasConstant): (JSC::DFG::Node::valueOfJSConstant): (JSC::DFG::Node::hasStructureTransitionData): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-21 Filip Pizlo DFG ConvertThis should just be a CheckStructure if the structure is known https://bugs.webkit.org/show_bug.cgi?id=87057 Reviewed by Gavin Barraclough. Merged r118021 from dfgopt. This gives ValueProfile the ability to track singleton values - i.e. profiling sites that always see the same value. That is then used to profile the structure in op_convert_this. This is then used to optimize op_convert_this into a CheckStructure if the structure is always the same. That then results in better CSE in inlined code that uses 'this', since previously we couldn't CSE accesses on 'this' from different inline call frames. Also fixed a bug where we were unnecessarily flushing 'this'. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dump): (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/LazyOperandValueProfile.cpp: (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): * bytecode/LazyOperandValueProfile.h: (CompressedLazyOperandValueProfileHolder): * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): * bytecode/ValueProfile.h: (JSC::ValueProfileBase::ValueProfileBase): (JSC::ValueProfileBase::dump): (JSC::ValueProfileBase::computeUpdatedPrediction): (ValueProfileBase): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_convert_this): (JSC::JIT::emitSlow_op_convert_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_convert_this): (JSC::JIT::emitSlow_op_convert_this): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSValue.h: (JSValue): * runtime/Structure.h: (JSC::JSValue::structureOrUndefined): (JSC): 2012-05-24 Tim Horton Add feature defines for web-facing parts of CSS Regions and Exclusions https://bugs.webkit.org/show_bug.cgi?id=87442 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2012-05-24 Geoffrey Garen WebKit should be lazy-finalization-safe (esp. the DOM) https://bugs.webkit.org/show_bug.cgi?id=87456 Reviewed by Filip Pizlo. Lazy finalization adds one twist to weak pointer use: A HashMap of weak pointers may contain logically null entries. (Weak pointers behave as-if null once their payloads die.) Insertion must not assume that a pre-existing entry is necessarily valid, and iteration must not assume that all entries can be dereferenced. (Previously, I thought that it also added a second twist: A demand-allocated weak pointer may replace a dead payload before the payload's finalizer runs. In that case, when the payload's finalizer runs, the payload has already been overwritten, and the finalizer should not clear the payload, which now points to something new. But that's not the case here, since we cancel the old payload's finalizer when we over-write it. I've added ASSERTs to verify this assumption, in case it ever changes.) * API/JSClassRef.cpp: (OpaqueJSClass::prototype): No need to specify null; that's the default. * API/JSWeakObjectMapRefPrivate.cpp: Use remove, since take() is gone. * heap/PassWeak.h: (WeakImplAccessor::was): This is no longer a debug-only function, since it's required to reason about lazily finalized pointers. * heap/Weak.h: (JSC::weakAdd): (JSC::weakRemove): (JSC::weakClear): Added these helper functions for the common idioms of what clients want to do in their weak pointer finalizers. * jit/JITStubs.cpp: (JSC::JITThunks::hostFunctionStub): Use the new idioms. Otherwise, we would return NULL for a "zombie" executable weak pointer that was waiting for finalization (item (2)), and finalizing a dead executable weak pointer would potentially destroy a new, live one (item (1)). * runtime/RegExpCache.cpp: (JSC::RegExpCache::lookupOrCreate): (JSC::RegExpCache::finalize): Ditto. (JSC::RegExpCache::invalidateCode): Check for null while iterating. (See item (2).) * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains): (JSC::StructureTransitionTable::add): Use get and set instead of add and contains, since add and contains are not compatible with lazy finalization. * runtime/WeakGCMap.h: (WeakGCMap): (JSC::WeakGCMap::clear): (JSC::WeakGCMap::remove): Removed a bunch of code that was incompatible with lazy finalization because I didn't feel like making it compatible, and I had no way to test it. 2012-05-24 Filip Pizlo REGRESSION (r118013-r118031): Loops/Reloads under www.yahoo.com, quits after three tries with error https://bugs.webkit.org/show_bug.cgi?id=87327 Reviewed by Geoffrey Garen. If you use AbstractValue::filter(StructureSet) to test subset relationships between TOP and a set containing >=2 elements, you're going to have a bad time. That's because AbstractValue considers a set with >=2 elements to be equivalent to TOP, in order to save space and speed up convergence. So filtering has no effect in this case, which made the code think that the abstract value was proving that the structure check was unnecessary. The correct thing to do is to use isSubsetOf() on the StructureAbstractValue, which does the right thingies for TOP and >=2 elements. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-24 Filip Pizlo new test fast/js/dfg-arguments-mixed-alias.html fails on JSVALUE32_64 https://bugs.webkit.org/show_bug.cgi?id=87378 Reviewed by Gavin Barraclough. - Captured variable tracking forgot did not consistently handle arguments, leading to OSR badness. - Nodes capable of exiting were tracked in a non-monotonic way, leading to compiler errors. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::CSEPhase): (CSEPhase): (JSC::DFG::performCSE): * dfg/DFGCSEPhase.h: (DFG): * dfg/DFGCommon.h: * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::resetExitStates): (DFG): * dfg/DFGGraph.h: (Graph): * dfg/DFGPhase.h: (DFG): (JSC::DFG::runPhase): 2012-05-24 Geoffrey Garen Made WeakSet per-block instead of per-heap https://bugs.webkit.org/show_bug.cgi?id=87401 Reviewed by Oliver Hunt. This allows us fast access to the set of all weak pointers for a block, which is a step toward lazy finalization. No performance change. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::lastChanceToFinalize): Removed the per-heap weak set, since it's per-block now. (JSC::Heap::markRoots): Delegate weak set visiting to the marked space, since it knows how to iterate all blocks. (JSC::Heap::collect): Moved the reaping outside of markRoots, since it doesn't mark anything. Make sure to reset allocators after shrinking, since shrinking may deallocate the current allocator. * heap/Heap.h: (Heap): No more per-heap weak set, since it's per-block now. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::MarkedBlock): * heap/MarkedBlock.h: (MarkedBlock): (JSC::MarkedBlock::lastChanceToFinalize): Migrated finalization logic here from the heap, so the heap doesn't need to know about our internal data structures like our weak set. (JSC::MarkedBlock::heap): (JSC::MarkedBlock::weakSet): (JSC::MarkedBlock::shrink): (JSC::MarkedBlock::resetAllocator): (JSC::MarkedBlock::visitWeakSet): (JSC::MarkedBlock::reapWeakSet): (JSC::MarkedBlock::sweepWeakSet): * heap/MarkedSpace.cpp: (JSC::VisitWeakSet::VisitWeakSet): (JSC::VisitWeakSet::operator()): (VisitWeakSet): (JSC): (JSC::ReapWeakSet::operator()): (JSC::SweepWeakSet::operator()): (JSC::LastChanceToFinalize::operator()): (JSC::MarkedSpace::lastChanceToFinalize): (JSC::ResetAllocator::operator()): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): (JSC::MarkedSpace::sweepWeakSets): (JSC::Shrink::operator()): (JSC::MarkedSpace::shrink): * heap/MarkedSpace.h: (MarkedSpace): Make sure to account for our weak sets when sweeping, shrinking, etc. * heap/WeakSet.cpp: (JSC): * heap/WeakSet.h: (WeakSet): (JSC::WeakSet::heap): (JSC): (JSC::WeakSet::lastChanceToFinalize): (JSC::WeakSet::visit): (JSC::WeakSet::reap): (JSC::WeakSet::shrink): (JSC::WeakSet::resetAllocator): Inlined some things since they're called once per block now instead of once per heap. * heap/WeakSetInlines.h: (JSC::WeakSet::allocate): Use the per-block weak set since there is no per-heap weak set anymore. 2012-05-24 Gavin Barraclough Fix arm build Rubber stamped by Geoff Garen * dfg/DFGGPRInfo.h: (GPRInfo): 2012-05-24 Gavin Barraclough Move cacheFlush from ExecutableAllocator to Assembler classes https://bugs.webkit.org/show_bug.cgi?id=87420 Reviewed by Oliver Hunt. Makes more sense there, & remove a pile of #ifdefs. * assembler/ARMAssembler.cpp: (JSC): (JSC::ARMAssembler::cacheFlush): * assembler/ARMAssembler.h: (ARMAssembler): (JSC::ARMAssembler::cacheFlush): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::relinkJump): (JSC::ARMv7Assembler::cacheFlush): (ARMv7Assembler): (JSC::ARMv7Assembler::setInt32): (JSC::ARMv7Assembler::setUInt7ForLoad): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::cacheFlush): * assembler/LinkBuffer.h: (JSC::LinkBuffer::performFinalization): * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::relinkJump): (JSC::MIPSAssembler::relinkCall): (JSC::MIPSAssembler::repatchInt32): (JSC::MIPSAssembler::cacheFlush): (MIPSAssembler): * assembler/SH4Assembler.h: (JSC::SH4Assembler::repatchCompact): (JSC::SH4Assembler::cacheFlush): (SH4Assembler): * assembler/X86Assembler.h: (X86Assembler): (JSC::X86Assembler::cacheFlush): * jit/ExecutableAllocator.cpp: (JSC): * jit/ExecutableAllocator.h: (ExecutableAllocator): 2012-05-24 John Mellor Font Boosting: Add compile flag and runtime setting https://bugs.webkit.org/show_bug.cgi?id=87394 Reviewed by Adam Barth. Add ENABLE_FONT_BOOSTING. * Configurations/FeatureDefines.xcconfig: 2012-05-24 Allan Sandfeld Jensen cti_vm_throw gets kicked out by gcc 4.6 -flto https://bugs.webkit.org/show_bug.cgi?id=56088 Reviewed by Darin Adler. Add REFERENCED_FROM_ASM to functions only referenced from assembler. * dfg/DFGOperations.cpp: * jit/HostCallReturnValue.h: * jit/JITStubs.h: * jit/ThunkGenerators.cpp: 2012-05-24 Filip Pizlo Incorrect merge of r117542 from dfg opt branch in r118323 is leading to fast/js/dfg-arguments-osr-exit.html failing https://bugs.webkit.org/show_bug.cgi?id=87350 Reviewed by Maciej Stachowiak. The dfgopt branch introduced the notion of a local variable being killed because it was aliased to the Arguments object as in cases like: var a = arguments; return a.length; This required changes to OSR exit handling - if the variable is dead but aliased to arguments, then OSR exit should reify the arguments. But meanwhile, in tip of tree we introduced special handling for dead variables on OSR exit. When the two were merged in r118323, the structure of the if/else branches ended up being such that we would treat dead arguments variables as totally dead as opposed to treating them as variables that need arguments reification. This fixes the structure of the relevant if/else block so that variables that are dead-but-arguments end up being treated as reified arguments objects, while variables that are dead but not aliased to arguments are treated as tip of tree would have treated them (initialize to Undefined). * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-24 Csaba Osztrogonác Unreviewed 32 bit buildfix after r118325. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): Use ASSERT_UNUSED instead ASSERT. 2012-05-23 Filip Pizlo DFG operationTearOffActivation should return after handling the null activation case https://bugs.webkit.org/show_bug.cgi?id=87348 Reviewed by Oliver Hunt. * dfg/DFGOperations.cpp: 2012-05-23 Filip Pizlo Unreviewed, merge the arguments fix in r118138 to get bots green. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): 2012-05-20 Filip Pizlo DFG CFA should record if a node can OSR exit https://bugs.webkit.org/show_bug.cgi?id=86905 Reviewed by Oliver Hunt. Merged r117931 from dfgopt. Adds a NodeFlag that denotes nodes that are known to not have OSR exits. This ought to aid any backwards analyses that need to know when a backward flow merge might happen due to a side exit. Also added assertions into speculationCheck() that ensure that we did not mark a node as non-exiting and then promptly compile in an exit. This helped catch some minor bugs where we were doing unnecessary speculation checks. This is a perf-neutral change. The speculation checks that this removes were not on hot paths of major benchmarks. * bytecode/PredictedType.h: (JSC): (JSC::isAnyPrediction): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::speculateInt32Unary): (AbstractState): (JSC::DFG::AbstractState::speculateNumberUnary): (JSC::DFG::AbstractState::speculateBooleanUnary): (JSC::DFG::AbstractState::speculateInt32Binary): (JSC::DFG::AbstractState::speculateNumberBinary): * dfg/DFGNode.h: (JSC::DFG::Node::mergeFlags): (JSC::DFG::Node::filterFlags): (Node): (JSC::DFG::Node::setCanExit): (JSC::DFG::Node::canExit): * dfg/DFGNodeFlags.cpp: (JSC::DFG::nodeFlagsAsString): * dfg/DFGNodeFlags.h: (DFG): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::SpeculativeJIT): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileValueToInt32): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): 2012-05-20 Filip Pizlo DFG should not do unnecessary indirections when storing to objects https://bugs.webkit.org/show_bug.cgi?id=86959 Reviewed by Oliver Hunt. Merged r117819 from dfgopt. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByOffsetLoadElimination): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-17 Filip Pizlo DFG should optimize aliased uses of the Arguments object of the current call frame https://bugs.webkit.org/show_bug.cgi?id=86552 Reviewed by Geoff Garen. Merged r117542 and r117543 from dfgopt. Performs must-alias and escape analysis on uses of CreateArguments, and if a variable is must-aliased to CreateArguments and does not escape, then we turn all uses of that variable into direct arguments accesses. 36% speed-up on V8/earley leading to a 2.3% speed-up overall in V8. * bytecode/CodeBlock.h: (JSC::CodeBlock::uncheckedArgumentsRegister): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::argumentsThatWereNotCreated): (ValueRecovery): (JSC::ValueRecovery::dump): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGAdjacencyList.h: (AdjacencyList): (JSC::DFG::AdjacencyList::removeEdgeFromBag): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (ArgumentsSimplificationPhase): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses): (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::argumentsRegisterFor): (AssemblyHelpers): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): * dfg/DFGGPRInfo.h: (GPRInfo): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::collectGarbage): (DFG): * dfg/DFGGraph.h: (Graph): (JSC::DFG::Graph::executableFor): (JSC::DFG::Graph::argumentsRegisterFor): (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: (JSC::DFG::OSRExitCompiler::OSRExitCompiler): (OSRExitCompiler): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::ValueSource::dump): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): (VariableAccessData): (JSC::DFG::VariableAccessData::isArgumentsAlias): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_get_argument_by_val): 2012-05-23 Filip Pizlo DFGCapabilities should not try to get an arguments register from code blocks that don't have one https://bugs.webkit.org/show_bug.cgi?id=87332 Reviewed by Andy Estes. * dfg/DFGCapabilities.h: (JSC::DFG::canInlineOpcode): 2012-05-23 Filip Pizlo DFG should have sparse conditional constant propagation https://bugs.webkit.org/show_bug.cgi?id=86580 Reviewed by Oliver Hunt. Merged r117370 from dfgopt. This enhances CFA so that if it suspects at any point during the fixpoint that a branch will only go one way, then it only propagates in that one way. This vastly increases the opportunities for CFG simplification. For example, it enables us to evaporate this loop: for (var i = 0; i < 1; ++i) doThings(i); As a result, it uncovered loads of bugs in the CFG simplifier. In particular: - Phi fixup was assuming that all Phis worth fixing up are shouldGenerate(). That's not true; we also fixup Phis that are dead. - GetLocal fixup was assuming that it's only necessary to rewire links to a GetLocal, and that the GetLocal's own links don't need to be rewired. Untrue, because the GetLocal may not be rewirable (first block has no GetLocal for r42 but second block does have a GetLocal), in which case it will refer to a Phi in the second block. We need it to refer to a Phi from the first block to ensure that subsequent transformations work. - Tail operand fixup was ignoring the fact that Phis in successors may contain references to the children of our tail variables. Hence, successor Phi child substitution needs to use the original second block variable table as its prior, rather than trying to reconstruct the prior later (since by that point the children of the second block's tail variables will have been fixed up, so we will not know what the prior would have been). * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::beginBasicBlock): (JSC::DFG::AbstractState::endBasicBlock): (JSC::DFG::AbstractState::reset): (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::mergeToSuccessors): * dfg/DFGAbstractState.h: (JSC::DFG::AbstractState::branchDirectionToString): (AbstractState): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::OperandSubstitution): (OperandSubstitution): (JSC::DFG::CFGSimplificationPhase::skipGetLocal): (JSC::DFG::CFGSimplificationPhase::recordPossibleIncomingReference): (CFGSimplificationPhase): (JSC::DFG::CFGSimplificationPhase::fixTailOperand): (JSC::DFG::CFGSimplificationPhase::mergeBlocks): * dfg/DFGGraph.h: (JSC::DFG::Graph::changeEdge): 2012-05-23 Ojan Vafai add back the ability to disable flexbox https://bugs.webkit.org/show_bug.cgi?id=87147 Reviewed by Tony Chang. * Configurations/FeatureDefines.xcconfig: 2012-05-23 Filip Pizlo Unreviewed, fix Windows build. * bytecode/CodeBlock.h: * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): (JSC::DFG::canCompileOpcodes): * dfg/DFGCommon.h: (DFG): 2012-05-23 Filip Pizlo DFG should optimize inlined uses of arguments.length and arguments[i] https://bugs.webkit.org/show_bug.cgi?id=86327 Reviewed by Gavin Barraclough. Merged r117017 from dfgopt. Turns inlined uses of arguments.length into a constant. Turns inlined uses of arguments[constant] into a direct reference to the argument. Big win on micro-benchmarks. Not yet a win on V8 because the hot uses of arguments.length and arguments[i] are aliased. I'll leave the aliasing optimizations to a later patch. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * bytecode/DFGExitProfile.h: (FrequentExitSite): (JSC::DFG::FrequentExitSite::FrequentExitSite): (JSC::DFG::QueryableExitProfile::hasExitSite): (QueryableExitProfile): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGArgumentsSimplificationPhase.cpp: Added. (DFG): (ArgumentsSimplificationPhase): (JSC::DFG::ArgumentsSimplificationPhase::ArgumentsSimplificationPhase): (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::performArgumentsSimplification): * dfg/DFGArgumentsSimplificationPhase.h: Added. (DFG): * dfg/DFGAssemblyHelpers.cpp: (JSC::DFG::AssemblyHelpers::executableFor): (DFG): * dfg/DFGAssemblyHelpers.h: (AssemblyHelpers): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getLocalLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.h: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::executableFor): (Graph): (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNode.h: (JSC::DFG::Node::convertToConstant): (JSC::DFG::Node::convertToGetLocalUnlinked): (Node): (JSC::DFG::Node::unlinkedLocal): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-13 Filip Pizlo DFG should be able to optimize foo.apply(bar, arguments) https://bugs.webkit.org/show_bug.cgi?id=86306 Reviewed by Gavin Barraclough. Merge r116912 from dfgopt. Enables compilation of op_jneq_ptr and some forms of op_call_varargs. Also includes a bunch of bug fixes that were made necessary by the increased pressure on the CFG simplifier. This is a 1-2% win on V8. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printCallOp): (JSC::CodeBlock::CodeBlock): (JSC::ProgramCodeBlock::canCompileWithDFGInternal): (JSC::EvalCodeBlock::canCompileWithDFGInternal): (JSC::FunctionCodeBlock::canCompileWithDFGInternal): * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::canCompileWithDFG): (JSC::CodeBlock::canCompileWithDFGState): (ProgramCodeBlock): (EvalCodeBlock): (FunctionCodeBlock): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::processPhiStack): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): (JSC::DFG::CFGSimplificationPhase::fixTailOperand): (JSC::DFG::CFGSimplificationPhase::mergeBlocks): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getLocalLoadElimination): (CSEPhase): (JSC::DFG::CSEPhase::setReplacement): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCapabilities.cpp: (JSC::DFG::debugFail): (DFG): (JSC::DFG::canHandleOpcodes): (JSC::DFG::canCompileOpcodes): (JSC::DFG::canInlineOpcodes): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): (JSC::DFG::canInlineOpcode): (DFG): (JSC::DFG::canCompileOpcodes): (JSC::DFG::canCompileEval): (JSC::DFG::canCompileProgram): (JSC::DFG::canCompileFunctionForCall): (JSC::DFG::canCompileFunctionForConstruct): * dfg/DFGCommon.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNodeType.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: (Validate): (JSC::DFG::Validate::validate): (JSC::DFG::Validate::checkOperand): (JSC::DFG::Validate::reportValidationContext): * jit/JIT.cpp: (JSC::JIT::emitOptimizationCheck): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::privateCompile): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompilePutByIdTransition): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::privateCompilePutByIdTransition): * tools/CodeProfile.cpp: (JSC::CodeProfile::sample): 2012-05-23 Geoffrey Garen Refactored WeakBlock to use malloc, clarify behavior https://bugs.webkit.org/show_bug.cgi?id=87318 Reviewed by Filip Pizlo. We want to use malloc so we can make these smaller than 4KB, since an individual MarkedBlock will usually have fewer than 4KB worth of weak pointers. * heap/Heap.cpp: (JSC::Heap::markRoots): Renamed visitLiveWeakImpls to visit, since we no longer need to distinguish from "visitDeadWeakImpls". Renamed "visitDeadWeakImpls" to "reap" because we're not actually doing any visiting -- we're just tagging things as dead. * heap/WeakBlock.cpp: (JSC::WeakBlock::create): (JSC::WeakBlock::destroy): (JSC::WeakBlock::WeakBlock): Malloc! (JSC::WeakBlock::visit): (JSC::WeakBlock::reap): Renamed as above. * heap/WeakBlock.h: (WeakBlock): Reduced to 3KB, as explained above. * heap/WeakSet.cpp: (JSC::WeakSet::visit): (JSC::WeakSet::reap): * heap/WeakSet.h: (WeakSet): Updated for renames, and to match WebKit style. 2012-05-23 Filip Pizlo Use after free in JSC::DFG::ByteCodeParser::processPhiStack https://bugs.webkit.org/show_bug.cgi?id=87312 Reviewed by Oliver Hunt. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::processPhiStack): (JSC::DFG::ByteCodeParser::parse): 2012-05-23 Filip Pizlo It should be possible to make C function calls from DFG code on ARM in debug mode https://bugs.webkit.org/show_bug.cgi?id=87313 Reviewed by Gavin Barraclough. * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): 2012-05-11 Filip Pizlo DFG should be able to inline functions that use arguments reflectively https://bugs.webkit.org/show_bug.cgi?id=86132 Reviewed by Oliver Hunt. Merged r116838 from dfgopt. This turns on inlining of functions that use arguments reflectively, but it does not do any of the obvious optimizations that this exposes. I'll save that for another patch - the important thing for now is that this contains all of the plumbing necessary to make this kind of inlining sound even in bizarro cases like an inline callee escaping the arguments object to parts of the inline caller where the arguments are otherwise dead. Or even more fun cases like where you've inlined to an inline stack that is three-deep, and the function on top of the inline stack reflectively accesses the arguments of a function that is in the middle of the inline stack. Any subsequent optimizations that we do for the obvious cases of arguments usage in inline functions will have to take care not to break the baseline functionality that this patch plumbs together. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printCallOp): (JSC::CodeBlock::dump): * bytecode/CodeBlock.h: * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::argumentsRegisterFor): (AssemblyHelpers): * dfg/DFGByteCodeParser.cpp: (InlineStackEntry): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCCallHelpers.h: (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): (CCallHelpers): * dfg/DFGCapabilities.h: (JSC::DFG::canInlineOpcode): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * interpreter/CallFrame.cpp: (JSC): (JSC::CallFrame::someCodeBlockForPossiblyInlinedCode): * interpreter/CallFrame.h: (ExecState): (JSC::ExecState::someCodeBlockForPossiblyInlinedCode): * interpreter/Interpreter.cpp: (JSC::Interpreter::retrieveArgumentsFromVMCode): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): (JSC): (JSC::Arguments::tearOffForInlineCallFrame): * runtime/Arguments.h: (Arguments): (JSC::Arguments::create): (JSC::Arguments::finishCreation): (JSC): 2012-05-23 Filip Pizlo Every OSR exit on ARM results in a crash https://bugs.webkit.org/show_bug.cgi?id=87307 Reviewed by Geoffrey Garen. * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): 2012-05-23 Geoffrey Garen Refactored heap tear-down to use normal value semantics (i.e., destructors) https://bugs.webkit.org/show_bug.cgi?id=87302 Reviewed by Oliver Hunt. This is a step toward incremental DOM finalization. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::~CopiedSpace): * heap/CopiedSpace.h: (CopiedSpace): Just use our destructor, instead of relying on the heap to send us a special message at a special time. * heap/Heap.cpp: (JSC::Heap::Heap): Use OwnPtr for m_markListSet because this is not Sparta. (JSC::Heap::~Heap): No need for delete or freeAllBlocks because normal destructors do this work automatically now. (JSC::Heap::lastChanceToFinalize): Just call lastChanceToFinalize on our sub-objects, and assume it does the right thing. This improves encapsulation, so we can add items requiring finalization to our sub-objects. * heap/Heap.h: Moved m_blockAllocator to get the right destruction order. * heap/MarkedSpace.cpp: (Take): (JSC): (JSC::Take::Take): (JSC::Take::operator()): (JSC::Take::returnValue): Moved to the top of the file so it can be used in another function. (JSC::MarkedSpace::~MarkedSpace): Delete all outstanding memory, like a good destructor should. (JSC::MarkedSpace::lastChanceToFinalize): Moved some code here from the heap, since it pertains to our internal implementation details. * heap/MarkedSpace.h: (MarkedSpace): * heap/WeakBlock.cpp: (JSC::WeakBlock::lastChanceToFinalize): * heap/WeakBlock.h: (WeakBlock): * heap/WeakSet.cpp: (JSC::WeakSet::lastChanceToFinalize): * heap/WeakSet.h: (WeakSet): Stop using a special freeAllBlocks() callback and just implement lastChanceToFinalize. 2011-05-22 Geoffrey Garen Encapsulated some calculations for whether portions of the heap are empty https://bugs.webkit.org/show_bug.cgi?id=87210 Reviewed by Gavin Barraclough. This is a step toward incremental DOM finalization. * heap/Heap.cpp: (JSC::Heap::~Heap): Explicitly call freeAllBlocks() instead of relying implicitly on all blocks thinking they're empty. In future, we may choose to tear down the heap without first setting all data structures to "empty". * heap/MarkedBlock.h: (JSC::MarkedBlock::isEmpty): (JSC::MarkedBlock::gatherDirtyCells): Renamed markCountIsZero to isEmpty, in preparation for making it check for outstanding finalizers in addition to marked cells. * heap/MarkedSpace.cpp: (Take): (JSC::Take::Take): (JSC::Take::operator()): (JSC::Take::returnValue): (JSC::MarkedSpace::shrink): (JSC::MarkedSpace::freeAllBlocks): Refactored the "Take" functor to support a conditional isEmpty check, so it dould be shared by shrink() and freeAllBlocks(). * heap/WeakBlock.cpp: (JSC::WeakBlock::WeakBlock): (JSC::WeakBlock::visitLiveWeakImpls): (JSC::WeakBlock::visitDeadWeakImpls): * heap/WeakBlock.h: (WeakBlock): (JSC::WeakBlock::isEmpty): * heap/WeakSet.cpp: (JSC::WeakSet::sweep): (JSC::WeakSet::shrink): Use isEmpty(), in preparation for changes in its implementation. 2012-05-23 Oswald Buddenhagen [Qt] Remove references to $$QT_SOURCE_TREE With a modularized Qt, it's ambigious. What we really want is qtbase, which qtcore is a proxy for (we assume it will always live in qtbase). Reviewed by Tor Arne Vestbø. * JavaScriptCore.pri: * Target.pri: 2012-05-09 Filip Pizlo DFG should allow inlining in case of certain arity mismatches https://bugs.webkit.org/show_bug.cgi?id=86059 Reviewed by Geoff Garen. Merge r116620 from dfgopt. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): 2012-05-08 Filip Pizlo DFG variable capture analysis should work even if the variables arose through inlining https://bugs.webkit.org/show_bug.cgi?id=85945 Reviewed by Oliver Hunt. Merged r116555 from dfgopt. This just changes how the DFG queries whether a variable is captured. It does not change any user-visible behavior. As part of this change, I further solidified the policy that the CFA behaves in an undefined way for captured locals and queries about their values will not yield reliable results. This will likely be changed in the future, but for now it makes sense. One fun part about this change is that it recognizes that the same variable may be both captured and not, at the same time, because their live interval spans inlining boundaries. This only happens in the case of arguments to functions that capture their arguments, and this change treats them with just the right touch of conservatism: they will be treated as if captured by the caller as well as the callee. Finally, this also adds captured variable reasoning to the InlineCallFrame, which I thought might be useful for later tooling. This is perf-neutral, since it does it does not make the DFG take advantage of this new functionality in any way. In particular, it is still the case that the DFG will not inline functions that use arguments reflectively or that create activations. * bytecode/CodeBlock.h: (CodeBlock): (JSC::CodeBlock::needsActivation): (JSC::CodeBlock::argumentIsCaptured): (JSC::CodeBlock::localIsCaptured): (JSC::CodeBlock::isCaptured): * bytecode/CodeOrigin.h: (InlineCallFrame): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::initialize): (JSC::DFG::AbstractState::endBasicBlock): (JSC::DFG::AbstractState::execute): (JSC::DFG::AbstractState::merge): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::newVariableAccessData): (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::getArgument): (JSC::DFG::ByteCodeParser::setArgument): (JSC::DFG::ByteCodeParser::flushArgument): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::processPhiStack): (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGCFGSimplificationPhase.cpp: (CFGSimplificationPhase): (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): (JSC::DFG::CFGSimplificationPhase::fixTailOperand): * dfg/DFGCommon.h: * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::nameOfVariableAccessData): * dfg/DFGGraph.h: (JSC::DFG::Graph::needsActivation): (JSC::DFG::Graph::usesArguments): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::mergeIsCaptured): (VariableAccessData): (JSC::DFG::VariableAccessData::isCaptured): 2012-05-08 Filip Pizlo DFG should support op_get_argument_by_val and op_get_arguments_length https://bugs.webkit.org/show_bug.cgi?id=85911 Reviewed by Oliver Hunt. Merged r116467 from dfgopt. This adds a simple and relatively conservative implementation of op_get_argument_by_val and op_get_arguments_length. We can optimize these later. For now it's great to have the additional coverage. This patch appears to be perf-neutral. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGAssemblyHelpers.h: (JSC::DFG::AssemblyHelpers::addressFor): (JSC::DFG::AssemblyHelpers::tagFor): (JSC::DFG::AssemblyHelpers::payloadFor): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): (JSC::DFG::canInlineOpcode): * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_argument_by_val): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2012-05-07 Filip Pizlo DFG should support op_tear_off_arguments https://bugs.webkit.org/show_bug.cgi?id=85847 Reviewed by Michael Saboff. Merged r116378 from dfgopt. * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.h: (JSC::DFG::canCompileOpcode): (JSC::DFG::canInlineOpcode): * dfg/DFGNodeType.h: (DFG): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2012-05-22 Mark Hahnenberg CopiedSpace::contains doesn't check for oversize blocks https://bugs.webkit.org/show_bug.cgi?id=87180 Reviewed by Geoffrey Garen. When doing a conservative scan we use CopiedSpace::contains to determine if a particular address points into the CopiedSpace. Currently contains() only checks if the address points to a block in to-space, which means that pointers to oversize blocks may not get scanned. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateOversize): (JSC::CopiedSpace::tryReallocateOversize): (JSC::CopiedSpace::doneFillingBlock): (JSC::CopiedSpace::doneCopying): * heap/CopiedSpace.h: Refactored CopiedSpace so that all blocks (oversize and to-space) are in a single hash set and bloom filter for membership testing. (CopiedSpace): * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::contains): We check for the normal block first. Since the oversize blocks are only page aligned, rather than block aligned, we have to re-mask the ptr to check if it's in CopiedSpace. Also added a helper function of the same name that takes a CopiedBlock* and checks if it's in CopiedSpace so that check isn't typed out twice. (JSC): (JSC::CopiedSpace::startedCopying): (JSC::CopiedSpace::addNewBlock): 2012-05-22 Geoffrey Garen CopiedBlock and MarkedBlock should have proper value semantics (i.e., destructors) https://bugs.webkit.org/show_bug.cgi?id=87172 Reviewed by Oliver Hunt and Phil Pizlo. This enables MarkedBlock to own non-trivial sub-objects that require destruction. It also fixes a FIXME about casting a CopiedBlock to a MarkedBlock at destroy time. CopiedBlock and MarkedBlock now accept an allocation chunk at create time and return it at destroy time. Their client is expected to allocate, recycle, and destroy these chunks. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::releaseFreeBlocks): (JSC::BlockAllocator::blockFreeingThreadMain): Don't call MarkedBlock::destroy because we expect that to be called before a block is put on our free list now. Do manually deallocate our allocation chunk because that's our job now. * heap/BlockAllocator.h: (BlockAllocator): (JSC::BlockAllocator::allocate): Allocate never fails now. This is a cleaner abstraction because only one object does all the VM allocation and deallocation. Caching is an implementation detail. (JSC::BlockAllocator::deallocate): We take an allocation chunk argument instead of a block because we now expect the block to have been destroyed before we recycle its memory. For convenience, we still use the HeapBlock class as our linked list node. This is OK because HeapBlock is a POD type. * heap/CopiedBlock.h: (CopiedBlock): (JSC::CopiedBlock::create): (JSC::CopiedBlock::destroy): (JSC::CopiedBlock::CopiedBlock): Added proper create and destroy functions, to match MarkedBlock. * heap/CopiedSpace.cpp: (JSC::CopiedSpace::tryAllocateOversize): (JSC::CopiedSpace::tryReallocateOversize): (JSC::CopiedSpace::doneCopying): (JSC::CopiedSpace::getFreshBlock): (JSC::CopiedSpace::freeAllBlocks): * heap/CopiedSpaceInlineMethods.h: (JSC::CopiedSpace::recycleBlock): Make sure to call destroy before returning a block to the BlockAllocator. Otherwise, our destructors won't run. (If we get this wrong now, we'll get a compile error.) * heap/HeapBlock.h: (JSC::HeapBlock::HeapBlock): const! * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::allocateBlock): No need to distinguish between create and recycle -- MarkedBlock always accepts memory allocated by its client now. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::create): Don't allocate memory -- we assume that we're passed already-allocated memory, to clarify the responsibility for VM recycling. (JSC::MarkedBlock::destroy): Do run our destructor before giving back our VM -- that is the whole point of this patch. (JSC::MarkedBlock::MarkedBlock): * heap/MarkedBlock.h: (MarkedBlock): * heap/MarkedSpace.cpp: const! (JSC::MarkedSpace::freeBlocks): Make sure to call destroy before returning a block to the BlockAllocator. Otherwise, our destructors won't run. (If we get this wrong now, we'll get a compile error.) == Rolled over to ChangeLog-2012-05-22 ==