diff options
| author | Simon Hausmann <simon.hausmann@digia.com> | 2012-10-17 16:21:14 +0200 |
|---|---|---|
| committer | Simon Hausmann <simon.hausmann@digia.com> | 2012-10-17 16:21:14 +0200 |
| commit | 8995b83bcbfbb68245f779b64e5517627c6cc6ea (patch) | |
| tree | 17985605dab9263cc2444bd4d45f189e142cca7c /Source/JavaScriptCore/ChangeLog | |
| parent | b9c9652036d5e9f1e29c574f40bc73a35c81ace6 (diff) | |
| download | qtwebkit-8995b83bcbfbb68245f779b64e5517627c6cc6ea.tar.gz | |
Imported WebKit commit cf4f8fc6f19b0629f51860cb2d4b25e139d07e00 (http://svn.webkit.org/repository/webkit/trunk@131592)
New snapshot that includes the build fixes for Mac OS X 10.6 and earlier as well
as the previously cherry-picked changes
Diffstat (limited to 'Source/JavaScriptCore/ChangeLog')
| -rw-r--r-- | Source/JavaScriptCore/ChangeLog | 21912 |
1 files changed, 2202 insertions, 19710 deletions
diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog index a5b548cab..69429a65d 100644 --- a/Source/JavaScriptCore/ChangeLog +++ b/Source/JavaScriptCore/ChangeLog @@ -1,2587 +1,1847 @@ -2012-09-25 Gavin Barraclough <barraclough@apple.com> +2012-10-16 Csaba Osztrogonác <ossy@webkit.org> - REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms - https://bugs.webkit.org/show_bug.cgi?id=97529 + Unreviewed, rolling out r131516 and r131550. + http://trac.webkit.org/changeset/131516 + http://trac.webkit.org/changeset/131550 + https://bugs.webkit.org/show_bug.cgi?id=99349 - Reviewed by Filip Pizlo. - - A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers. - - JSC currently throws an EvalError if you try to call eval with a this object that doesn't - match the given eval function. This does not match other browsers, which generally just - ignore the this value that was passed, and eval the string in the eval function's environment. - - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::globalFuncEval): - - Remove EvalError, ignore passed this value. - -2012-09-25 Filip Pizlo <fpizlo@apple.com> - - DFG ArrayPush, ArrayPop don't handle clobbering or having a bad time correctly - https://bugs.webkit.org/show_bug.cgi?id=97535 - - Reviewed by Oliver Hunt. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::handleIntrinsic): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-09-25 Geoffrey Garen <ggaren@apple.com> - - JSC should dump object size inference statistics - https://bugs.webkit.org/show_bug.cgi?id=97618 - - Reviewed by Filip Pizlo. - - Added an option to dump object size inference statistics. - - To see statistics on live objects: - - jsc --showHeapStatistics=1 - - To see cumulative statistics on all objects ever allocated: - - jsc --showHeapStatistics=1 --objectsAreImmortal=1 - - (This is useful for showing GC churn caused by over-allocation.) - - To support this second mode, I refactored Zombies to separate out their - immortality feature so I could reuse it. - - * heap/Heap.cpp: - (JSC::MarkObject): Helper for making things immortal. We have to checked - for being zapped because blocks start out in this state. - - (JSC::StorageStatistics): Gather statistics by walking the heap. Ignore - arrays and hash tables for now because they're not our focus. (We'll - remove these exceptions in future.) - - (JSC::Heap::collect): Moved zombify to the end so it wouldn't interfere - with statistics gathering. - - (JSC::Heap::showStatistics): - (JSC::Heap::markAllObjects): Factored out helper, so statistics could - take advantage of immortal objects. - - (Zombify): Don't mark immortal objects -- that's another class's job now. - - (JSC::Zombify::operator()): - (JSC::Heap::zombifyDeadObjects): Take advantage of forEachDeadCell instead - of rolling our own. - - * heap/Heap.h: - (Heap): - * heap/MarkedSpace.h: - (MarkedSpace): - (JSC::MarkedSpace::forEachDeadCell): Added, so clients don't have to do - the iteration logic themselves. - - * runtime/Options.cpp: - (JSC::Options::initialize): - * runtime/Options.h: New options, listed above. Make sure to initialize - based on environment variable first, so we can override with specific settings. - -2012-09-25 Filip Pizlo <fpizlo@apple.com> - - We shouldn't use the optimized versions of shift/unshift if the user is doing crazy things to the array - https://bugs.webkit.org/show_bug.cgi?id=97603 - <rdar://problem/12370864> - - Reviewed by Gavin Barraclough. - - You changed the length behind our backs? No optimizations for you then! - - * runtime/ArrayPrototype.cpp: - (JSC::shift): - (JSC::unshift): - * runtime/JSArray.cpp: - (JSC::JSArray::shiftCount): - -2012-09-25 Filip Pizlo <fpizlo@apple.com> - - JSC bindings appear to sometimes ignore the possibility of arrays being in sparse mode - https://bugs.webkit.org/show_bug.cgi?id=95610 - - Reviewed by Oliver Hunt. - - Add better support for quickly accessing the indexed storage from bindings. - - * runtime/JSObject.h: - (JSC::JSObject::tryGetIndexQuickly): - (JSObject): - (JSC::JSObject::getDirectIndex): - (JSC::JSObject::getIndex): - -2012-09-25 Filip Pizlo <fpizlo@apple.com> - - Structure check hoisting phase doesn't know about the side-effecting nature of Arrayify - https://bugs.webkit.org/show_bug.cgi?id=97537 - - Reviewed by Mark Hahnenberg. - - No tests because if we use Arrayify then we also use PutByVal(BlankToXYZ), and the latter is - already known to be side-effecting. So this bug shouldn't have had any symptoms, as far as I - can tell. - - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-09-25 Gavin Barraclough <barraclough@apple.com> - - Regression: put beyond vector length prefers prototype setters to sparse properties - https://bugs.webkit.org/show_bug.cgi?id=97593 - - Reviewed by Geoff Garen & Filip Pizlo. - - * runtime/JSObject.cpp: - (JSC::JSObject::putByIndexBeyondVectorLength): - - Check for self properties in the sparse map - if present, don't examine the protochain. - -2012-09-24 Gavin Barraclough <barraclough@apple.com> - - https://bugs.webkit.org/show_bug.cgi?id=97530 - Regression, freeze applied to numeric properties of non-array objects - - Reviewed by Filip Pizlo. - - Object.freeze has a fast implementation in JSObject, but this hasn't been updated to take into account numeric properties in butterflies. - For now, just fall back to the generic implementation if the object has numeric properties. - - * runtime/ObjectConstructor.cpp: - (JSC::objectConstructorFreeze): - - fallback if the object has a non-zero indexed property vector length. - -2012-09-24 Gavin Barraclough <barraclough@apple.com> - - Bug in numeric accessors on global environment - https://bugs.webkit.org/show_bug.cgi?id=97526 - - Reviewed by Geoff Garen. - - I've hit this assert in test262 in browser, but haven't yet worked out how to repro in a test case :-/ - The sparsemap is failing to map back from the global object to the window shell. - A test case would need to resolve a numeric property name against the global environment. - - (JSC::SparseArrayEntry::get): - (JSC::SparseArrayEntry::put): - - Add missing toThisObject calls. - -2012-09-24 Filip Pizlo <fpizlo@apple.com> - - SerializedScriptValue isn't aware of indexed storage, but should be - https://bugs.webkit.org/show_bug.cgi?id=97515 - <rdar://problem/12361874> - - Reviewed by Sam Weinig. - - Export a method that WebCore now uses. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * runtime/JSObject.h: - (JSObject): - -2012-09-24 Gavin Barraclough <barraclough@apple.com> - - Remove JSObject::unwrappedGlobalObject(), JSObject::unwrappedObject() - https://bugs.webkit.org/show_bug.cgi?id=97519 - - Reviewed by Geoff Garen. - - unwrappedGlobalObject() was only needed because globalObject() doesn't always return a helpful result - - specifically for WebCore's window shell the structure's globalObject is set to null. We can fix this by - simply keeping the structure up to date as the window navigates, obviating the need for this function. - - The only other use of unwrappedObject() came from globalFuncEval(), and this can be trivially removed - by flipping the way we perform this globalObject check (which we may also be able to remove!) - instead - of getting the globalObject from the provided this value & comparing to the expected globalObject, we - can get the this value from the expected globalObject, and compare to that provided. - - * runtime/JSGlobalObject.cpp: - - Call globalObject() instead of unwrappedGlobalObject(). - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::globalFuncEval): - - Changed to compare this object values, instead of globalObjects - - this means we only need to be able to map globalObject -> this, - and not vice versa. - * runtime/JSObject.cpp: - (JSC::JSObject::allowsAccessFrom): - (JSC::JSObject::createInheritorID): - - Call globalObject() instead of unwrappedGlobalObject(). - * runtime/JSObject.h: - (JSObject): - - Removed unwrappedGlobalObject(), unwrappedObject(). - -2012-09-24 Mark Lam <mark.lam@apple.com> - - Deleting the classic interpreter and cleaning up some build options. - https://bugs.webkit.org/show_bug.cgi?id=96969. - - Reviewed by Geoffrey Garen. + It caused zillion different problem on different platforms + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: + (JSC): + (JSC::isGlobalResolve): + (JSC::instructionOffsetForNth): + (JSC::printGlobalResolveInfo): + (JSC::CodeBlock::printStructures): (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::stronglyVisitStrongReferences): + (JSC::CodeBlock::hasGlobalResolveInfoAtBytecodeOffset): + (JSC::CodeBlock::globalResolveInfoForBytecodeOffset): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::addGlobalResolveInstruction): + (JSC::CodeBlock::addGlobalResolveInfo): + (JSC::CodeBlock::globalResolveInfo): + (JSC::CodeBlock::numberOfGlobalResolveInfos): + (JSC::CodeBlock::globalResolveInfoCount): + * bytecode/GlobalResolveInfo.h: Copied from Source/JavaScriptCore/bytecode/ResolveGlobalStatus.cpp. (JSC): - * bytecode/Instruction.h: - (JSC::Instruction::Instruction): - * interpreter/AbstractPC.cpp: - (JSC::AbstractPC::AbstractPC): - * interpreter/AbstractPC.h: - (AbstractPC): - * interpreter/CallFrame.h: - (ExecState): - * interpreter/Interpreter.cpp: + (JSC::GlobalResolveInfo::GlobalResolveInfo): + (GlobalResolveInfo): + (JSC::getGlobalResolveInfoBytecodeOffset): + * bytecode/Opcode.h: (JSC): - (JSC::Interpreter::Interpreter): - (JSC::Interpreter::~Interpreter): - (JSC::Interpreter::initialize): - (JSC::Interpreter::isOpcode): - (JSC::Interpreter::unwindCallFrame): - (JSC::getLineNumberForCallFrame): - (JSC::getCallerInfo): - (JSC::getSourceURLFromCallFrame): - (JSC::Interpreter::execute): - (JSC::Interpreter::executeCall): - (JSC::Interpreter::executeConstruct): - (JSC::Interpreter::retrieveArgumentsFromVMCode): - (JSC::Interpreter::retrieveCallerFromVMCode): - (JSC::Interpreter::retrieveLastCaller): - * interpreter/Interpreter.h: - (JSC::Interpreter::getOpcodeID): - (Interpreter): - * jit/ExecutableAllocatorFixedVMPool.cpp: - (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): - * offlineasm/asm.rb: - * offlineasm/offsets.rb: - * runtime/Executable.cpp: - (JSC::EvalExecutable::compileInternal): - (JSC::ProgramExecutable::compileInternal): - (JSC::FunctionExecutable::compileForCallInternal): - (JSC::FunctionExecutable::compileForConstructInternal): - * runtime/Executable.h: - (JSC::NativeExecutable::create): - (NativeExecutable): - (JSC::NativeExecutable::finishCreation): - * runtime/JSGlobalData.cpp: + (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: (JSC): - (JSC::JSGlobalData::JSGlobalData): - (JSC::JSGlobalData::getHostFunction): - * runtime/JSGlobalData.h: - (JSGlobalData): - (JSC::JSGlobalData::canUseJIT): - (JSC::JSGlobalData::canUseRegExpJIT): - * runtime/Options.cpp: - (JSC::Options::initialize): - -2012-09-24 Filip Pizlo <fpizlo@apple.com> - - Nested try/finally should not confuse the finally unpopper in BytecodeGenerator::emitComplexJumpScopes - https://bugs.webkit.org/show_bug.cgi?id=97508 - <rdar://problem/12361132> - - Reviewed by Sam Weinig. - - We're reusing some vector for multiple iterations of a loop, but we were forgetting to clear its - contents from one iteration to the next. Hence if you did multiple iterations of finally unpopping - (like in a nested try/finally and a jump out of both of them) then you'd get a corrupted try - context stack afterwards. - + (JSC::computeForStructure): + (JSC::computeForLLInt): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecode/ResolveOperation.h: Removed. * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitComplexJumpScopes): - -2012-09-24 Filip Pizlo <fpizlo@apple.com> - - ValueToInt32 bool case does bad things to registers - https://bugs.webkit.org/show_bug.cgi?id=97505 - <rdar://problem/12356331> - - Reviewed by Mark Hahnenberg. - - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileValueToInt32): - -2012-09-24 Mark Lam <mark.lam@apple.com> - - Add cloopDo instruction for debugging the llint C++ backend. - https://bugs.webkit.org/show_bug.cgi?id=97502. - - Reviewed by Geoffrey Garen. - - * offlineasm/cloop.rb: - * offlineasm/instructions.rb: - * offlineasm/parser.rb: - -2012-09-24 Filip Pizlo <fpizlo@apple.com> - - JSArray::putByIndex asserts with readonly property on prototype - https://bugs.webkit.org/show_bug.cgi?id=97435 - <rdar://problem/12357084> - - Reviewed by Geoffrey Garen. - - Boy, there were some problems: - - - putDirectIndex() should know that it can set the index quickly even if it's a hole and we're - in SlowPut mode, since that's the whole point of PutDirect. - - - We should have a fast path for putByIndex(). - - - The LiteralParser should not use push(), since that may throw if we're having a bad time. - - * interpreter/Interpreter.cpp: - (JSC::eval): - * runtime/JSObject.h: - (JSC::JSObject::putByIndexInline): - (JSObject): - (JSC::JSObject::putDirectIndex): - * runtime/LiteralParser.cpp: - (JSC::::parse): - -2012-09-24 Mark Lam <mark.lam@apple.com> - - Added a missing "if VALUE_PROFILER" around an access to ArrayProfile record. - https://bugs.webkit.org/show_bug.cgi?id=97496. - - Reviewed by Filip Pizlo. - - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-24 Geoffrey Garen <ggaren@apple.com> - - Inlined activation tear-off in the DFG - https://bugs.webkit.org/show_bug.cgi?id=97487 - - Reviewed by Filip Pizlo. - - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: Activation tear-off is always inlined now, so I - removed its out-of-line implementation. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Inlined the variable copy and update - of JSVariableObject::m_registers. This usually turns into < 10 instructions, - which is close to pure win as compared to the operation function call. - - * runtime/JSActivation.h: - (JSActivation): - (JSC::JSActivation::registersOffset): - (JSC::JSActivation::tearOff): - (JSC::JSActivation::isTornOff): + (JSC::ResolveResult::checkValidity): + (JSC::ResolveResult::registerPointer): (JSC): - (JSC::JSActivation::storageOffset): - (JSC::JSActivation::storage): Tiny bit of refactoring so the JIT can - share the pointer math helper functions we use internally. - -2012-09-24 Balazs Kilvady <kilvadyb@homejinni.com> - - MIPS: store8 functions added to MacroAssembler. - - MIPS store8 functions - https://bugs.webkit.org/show_bug.cgi?id=97243 - - Reviewed by Oliver Hunt. - - Add MIPS store8 functions. - - * assembler/MIPSAssembler.h: - (JSC::MIPSAssembler::lhu): New function. - (MIPSAssembler): - (JSC::MIPSAssembler::sb): New function. - (JSC::MIPSAssembler::sh): New function. - * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::store8): New function. - (MacroAssemblerMIPS): - (JSC::MacroAssemblerMIPS::store16): New function. - -2012-09-23 Geoffrey Garen <ggaren@apple.com> - - PutScopedVar should not be marked as clobbering the world - https://bugs.webkit.org/show_bug.cgi?id=97416 - - Reviewed by Filip Pizlo. - - No performance change. - - PutScopedVar doesn't have arbitrary side-effects, so it shouldn't be marked - as such. - - * dfg/DFGNodeType.h: - (DFG): - -2012-09-23 Geoffrey Garen <ggaren@apple.com> - - I accidentally the whole 32-bit :(. - - Unbreak the DFG in 32-bit with the 32-bit path I forgot in my last patch. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-09-23 Byungwoo Lee <bw80.lee@gmail.com> - - Fix build warnings : -Wunused-parameter, -Wparentheses, -Wuninitialized. - https://bugs.webkit.org/show_bug.cgi?id=97306 - - Reviewed by Benjamin Poulain. - - Fix build warning about -Wunused-parameter on MachineStackMarker.cpp, - LLIntSlowPaths.cpp, DatePrototype.cpp, Options.cpp by using - UNUSED_PARAM() macro or remove parameter name. - - * heap/MachineStackMarker.cpp: - (JSC::pthreadSignalHandlerSuspendResume): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::entryOSR): - * runtime/DatePrototype.cpp: - (JSC::formatLocaleDate): - * runtime/Options.cpp: - (JSC::computeNumberOfGCMarkers): - -2012-09-23 Gavin Barraclough <barraclough@apple.com> - - Sorting a non-array creates propreties (spec-violation) - https://bugs.webkit.org/show_bug.cgi?id=25477 - - Reviewed by Oliver Hunt. - - We're just calling get() to get properties, which is converting missing properties to - undefined. Hole values should be retained, and moved to the end of the array. - - * runtime/ArrayPrototype.cpp: - (JSC::getOrHole): - - Helper function, returns JSValue() instead of undefined for missing properties. - (JSC::arrayProtoFuncSort): - - Implemented per 15.4.4.11, see comments above. - -2012-09-23 Geoffrey Garen <ggaren@apple.com> - - CSE for access to closure variables (get_/put_scoped_var) - https://bugs.webkit.org/show_bug.cgi?id=97414 - - Reviewed by Oliver Hunt. - - I separated loading a scope from loading its storage pointer, so we can - CSE the storage pointer load. Then, I copied the global var CSE and adjusted - it for closure vars. - + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (JSC::ResolveResult::lexicalResolve): + (JSC::ResolveResult::indexedGlobalResolve): + (JSC::ResolveResult::dynamicIndexedGlobalResolve): + (JSC::ResolveResult::globalResolve): + (JSC::ResolveResult::dynamicGlobalResolve): + (JSC::ResolveResult::type): + (JSC::ResolveResult::index): + (JSC::ResolveResult::depth): + (JSC::ResolveResult::globalObject): + (ResolveResult): + (JSC::ResolveResult::isStatic): + (JSC::ResolveResult::isIndexed): + (JSC::ResolveResult::isScoped): + (JSC::ResolveResult::isGlobal): + (JSC::ResolveResult::ResolveResult): + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): Renamed GetScopeChain => GetScope to - reflect renames from a few weeks ago. - - Added a case for the storage pointer load, similar to object storage pointer load. - + (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): Added an independent node for - the storage pointer. - - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::scopedVarLoadElimination): - (CSEPhase): - (JSC::DFG::CSEPhase::scopedVarStoreElimination): - (JSC::DFG::CSEPhase::getScopeLoadElimination): - (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination): - (JSC::DFG::CSEPhase::setLocalStoreElimination): - (JSC::DFG::CSEPhase::performNodeCSE): Copied globalVarLoad/StoreElimination - and adapted the same logic to closure vars. - + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (DFG): + (Graph): * dfg/DFGNode.h: - (JSC::DFG::Node::hasScopeChainDepth): - (JSC::DFG::Node::scope): - (Node): + (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: - (DFG): GetScopedVar and GetGlobalVar are no longer MustGenerate. I'm not - sure why they ever were. But these are simple load operations so, if they're - unused, they're truly dead. - + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + (JSC): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Updated for renames and split-out - node for getting the storage pointer. - -2012-09-21 Geoffrey Garen <ggaren@apple.com> - - Unreviewed, rolled out a line I committed by accident. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::execute): - -2012-09-21 Geoffrey Garen <ggaren@apple.com> - - Optimized closures that capture arguments - https://bugs.webkit.org/show_bug.cgi?id=97358 - - Reviewed by Oliver Hunt. - - Previously, the activation object was responsible for capturing all - arguments in a way that was convenient for the arguments object. Now, - we move all captured variables into a contiguous region in the stack, - allocate an activation for exactly that size, and make the arguments - object responsible for knowing all the places to which arguments could - have moved. - - This seems like the right tradeoff because - - (a) Closures are common and long-lived, so we want them to be small. - - (b) Our primary strategy for optimizing the arguments object is to make - it go away. If you're allocating arguments objects, you're already having - a bad time. - - (c) It's common to use either the arguments object or named argument - closure, but not both. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::CodeBlock::CodeBlock): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::argumentsRegister): - (JSC::CodeBlock::activationRegister): - (JSC::CodeBlock::isCaptured): - (JSC::CodeBlock::argumentIndexAfterCapture): m_numCapturedVars is gone - now -- we have an explicit range instead. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): Move captured arguments - into the captured region of local variables for space efficiency. Record - precise data about where they moved for the sake of the arguments object. - - Some of this data was previously wrong, but it didn't cause any problems - because the arguments weren't actually moving. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): Don't - assume that captured vars are in any particular location -- always ask - the CodeBlock. This is better encapsulation. - - (JSC::DFG::ByteCodeParser::parseCodeBlock): - * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): I rename things sometimes. - - * runtime/Arguments.cpp: - (JSC::Arguments::tearOff): Account for a particularly nasty edge case. - - (JSC::Arguments::didTearOffActivation): Don't allocate our slow arguments - data on tear-off. We need to allocate it eagerly instead, since we need - to know about displaced, captured arguments during access before tear-off. - - * runtime/Arguments.h: - (JSC::Arguments::allocateSlowArguments): - (JSC::Arguments::argument): Tell our slow arguments array where all arguments - are, even if they are not captured. This simplifies some things, so we don't - have to account explicitly for the full matrix of (not torn off, torn off) - * (captured, not captured). - - (JSC::Arguments::finishCreation): Allocate our slow arguments array eagerly - because we need to know about displaced, captured arguments during access - before tear-off. - - * runtime/Executable.cpp: - (JSC::FunctionExecutable::FunctionExecutable): - (JSC::FunctionExecutable::compileForCallInternal): - (JSC::FunctionExecutable::compileForConstructInternal): - * runtime/Executable.h: - (JSC::FunctionExecutable::parameterCount): - (FunctionExecutable): - * runtime/JSActivation.cpp: - (JSC::JSActivation::visitChildren): - * runtime/JSActivation.h: - (JSActivation): - (JSC::JSActivation::create): - (JSC::JSActivation::JSActivation): - (JSC::JSActivation::registerOffset): - (JSC::JSActivation::tearOff): - (JSC::JSActivation::allocationSize): - (JSC::JSActivation::isValid): This is really the point of the patch. All - the pointer math in Activations basically boils away, since we always - copy a contiguous region of captured variables now. - - * runtime/SymbolTable.h: - (JSC::SlowArgument::SlowArgument): - (SlowArgument): - (SharedSymbolTable): - (JSC::SharedSymbolTable::captureCount): - (JSC::SharedSymbolTable::SharedSymbolTable): AllOfTheThings capture mode - is gone now -- that's the point of the patch. indexIfCaptured gets renamed - to index because we always have an index, even if not captured. (The only - time when the index is meaningless is when we're Deleted.) - -2012-09-21 Gavin Barraclough <barraclough@apple.com> + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + (JSC::JIT::emit_op_get_global_var_watchable): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_resolve): + (JSC): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emit_op_resolve_skip): + (JSC::JIT::emit_op_resolve_global): + (JSC::JIT::emitSlow_op_resolve_global): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emit_op_resolve_global_dynamic): + (JSC::JIT::emitSlow_op_resolve_global_dynamic): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_resolve): + (JSC): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emit_op_resolve_skip): + (JSC::JIT::emit_op_resolve_global): + (JSC::JIT::emitSlow_op_resolve_global): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + (JSC::JIT::emit_op_put_global_var_check): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + (JSC::JIT::emit_op_put_global_var_check): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSScope.cpp: + (JSC::JSScope::resolve): + (JSC::JSScope::resolveSkip): + (JSC::JSScope::resolveGlobal): + (JSC::JSScope::resolveGlobalDynamic): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: + * runtime/JSVariableObject.h: + * runtime/Structure.h: - Eeeep - broke early boyer in bug#97382 - https://bugs.webkit.org/show_bug.cgi?id=97383 +2012-10-16 Dongwoo Joshua Im <dw.im@samsung.com> - Rubber stamped by Sam Weinig. + [GTK] Fix build break - ResolveOperations.h is not in WebKit. + https://bugs.webkit.org/show_bug.cgi?id=99538 - missed a child3 -> child2! + Unreviewed build fix. - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileInstanceOf): + There are some files including ResolveOperations.h which is not exist at all. -2012-09-21 Gavin Barraclough <barraclough@apple.com> + * GNUmakefile.list.am: s/ResolveOperations.h/ResolveOperation.h/ + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: s/ResolveOperations.h/ResolveOperation.h/ - Unreviewed windows build fix. +2012-10-16 Jian Li <jianli@chromium.org> - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + Rename feature define ENABLE_WIDGET_REGION to ENABLE_DRAGGBALE_REGION + https://bugs.webkit.org/show_bug.cgi?id=98975 -2012-09-21 Gavin Barraclough <barraclough@apple.com> + Reviewed by Adam Barth. - Pedantic test in Mozilla's JavaScript test suite fails. function-001.js function-001-n.js - https://bugs.webkit.org/show_bug.cgi?id=27219 + Renaming is needed to better match with the draggable region code. - Reviewed by Sam Weinig. + * Configurations/FeatureDefines.xcconfig: - These tests are just wrong. - See ECMA 262 A.5, FunctionDelcaration does not require a semicolon. +2012-10-15 Oliver Hunt <oliver@apple.com> - * tests/mozilla/expected.html: - * tests/mozilla/js1_2/function/function-001-n.js: - * tests/mozilla/js1_3/Script/function-001-n.js: - * tests/mozilla/js1_3/regress/function-001-n.js: + Bytecode should not have responsibility for determining how to perform non-local resolves + https://bugs.webkit.org/show_bug.cgi?id=99349 -2012-09-21 Gavin Barraclough <barraclough@apple.com> + Reviewed by Gavin Barraclough. - Remove redundant argument to op_instanceof - https://bugs.webkit.org/show_bug.cgi?id=97382 + This patch removes lexical analysis from the bytecode generation. This allows + us to delay lookup of a non-local variables until the lookup is actually necessary, + and simplifies a lot of the resolve logic in BytecodeGenerator. - Reviewed by Geoff Garen. + Once a lookup is performed we cache the lookup information in a set of out-of-line + buffers in CodeBlock. This allows subsequent lookups to avoid unnecessary hashing, + etc, and allows the respective JITs to recreated optimal lookup code. - No longer needed after my last change. + This is currently still a performance regression in LLInt, but most of the remaining + regression is caused by a lot of indirection that I'll remove in future work, as well + as some work necessary to allow LLInt to perform in line instruction repatching. + We will also want to improve the behaviour of the baseline JIT for some of the lookup + operations, however this patch was getting quite large already so I'm landing it now + that we've reached the bar of "performance-neutral". + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printStructures): (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::addResolve): + (JSC::CodeBlock::addPutToBase): + (CodeBlock): + (JSC::CodeBlock::resolveOperations): + (JSC::CodeBlock::putToBaseOperation): + (JSC::CodeBlock::numberOfResolveOperations): + (JSC::CodeBlock::numberOfPutToBaseOperations): + (JSC::CodeBlock::addPropertyAccessInstruction): + (JSC::CodeBlock::globalObjectConstant): + (JSC::CodeBlock::setGlobalObjectConstant): + * bytecode/GlobalResolveInfo.h: Removed. * bytecode/Opcode.h: (JSC): (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecode/ResolveOperation.h: Added. + The new types and logic we use to perform the cached lookups. + (JSC): + (ResolveOperation): + (JSC::ResolveOperation::getAndReturnScopedVar): + (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope): + (JSC::ResolveOperation::getAndReturnGlobalVar): + (JSC::ResolveOperation::getAndReturnGlobalProperty): + (JSC::ResolveOperation::resolveFail): + (JSC::ResolveOperation::skipTopScopeNode): + (JSC::ResolveOperation::skipScopes): + (JSC::ResolveOperation::returnGlobalObjectAsBase): + (JSC::ResolveOperation::setBaseToGlobal): + (JSC::ResolveOperation::setBaseToUndefined): + (JSC::ResolveOperation::setBaseToScope): + (JSC::ResolveOperation::returnScopeAsBase): + (JSC::PutToBaseOperation::PutToBaseOperation): * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitInstanceOf): + (JSC::ResolveResult::checkValidity): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetLocalVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutToBase): * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (ResolveResult): + (JSC::ResolveResult::ResolveResult): + (JSC): + (NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::~NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::resolved): + (JSC::NonlocalResolveInfo::put): (BytecodeGenerator): + (JSC::BytecodeGenerator::getResolveOperations): + (JSC::BytecodeGenerator::getResolveWithThisOperations): + (JSC::BytecodeGenerator::getResolveBaseOperations): + (JSC::BytecodeGenerator::getResolveBaseForPutOperations): + (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations): + (JSC::BytecodeGenerator::getPutToBaseOperation): * bytecompiler/NodesCodegen.cpp: - (JSC::InstanceOfNode::emitBytecode): + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (DFG): + (JSC::DFG::ByteCodeParser::parseResolveOperations): (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileResolveOperations): + (DFG): + (JSC::DFG::canCompilePutToBaseOperation): + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (ResolveOperationData): + (DFG): + (PutToBaseOperationData): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifier): + (JSC::DFG::Node::resolveOperationsDataIndex): + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileInstanceOf): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::resolveOperations): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putToBaseOperation): + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_instanceof): - (JSC::JIT::emitSlow_op_instanceof): + (JSC::JIT::emit_op_put_to_base): + (JSC): + (JSC::JIT::emit_resolve_operations): + (JSC::JIT::emitSlow_link_resolve_operations): + (JSC::JIT::emit_op_resolve): + (JSC::JIT::emitSlow_op_resolve): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emitSlow_op_resolve_base): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emitSlow_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_instanceof): - (JSC::JIT::emitSlow_op_instanceof): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-21 Gavin Barraclough <barraclough@apple.com> - - Unreviewed windows build fix. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-09-21 Gavin Barraclough <barraclough@apple.com> - - instanceof should not get the prototype for non-default HasInstance - https://bugs.webkit.org/show_bug.cgi?id=68656 - - Reviewed by Oliver Hunt. - - Instanceof is currently implemented as a sequance of three opcodes: - check_has_instance - get_by_id(prototype) - op_instanceof - There are three interesting types of base value that instanceof can be applied to: - (A) Objects supporting default instanceof behaviour (functions, other than those created with bind) - (B) Objects overriding the default instancecof behaviour with a custom one (API objects, bound functions) - (C) Values that do not respond to the [[HasInstance]] trap. - Currently check_has_instance handles case (C), leaving the op_instanceof opcode to handle (A) & (B). There are - two problems with this apporach. Firstly, this is suboptimal for case (A), since we have to check for - hasInstance support twice (once in check_has_instance, then for default behaviour in op_instanceof). Secondly, - this means that in cases (B) we also perform the get_by_id, which is both suboptimal and an observable spec - violation. - - The fix here is to move handing of non-default instanceof (cases (B)) to the check_has_instance op, leaving - op_instanceof to handle only cases (A). - - * API/JSCallbackObject.h: - (JSCallbackObject): - * API/JSCallbackObjectFunctions.h: - (JSC::::customHasInstance): - * API/JSValueRef.cpp: - (JSValueIsInstanceOfConstructor): - - renamed hasInstance to customHasInstance - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - - added additional parameters to check_has_instance opcode - * bytecode/Opcode.h: + (JSC::JIT::emit_op_put_to_base): (JSC): - (JSC::padOpcodeName): - - added additional parameters to check_has_instance opcode - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitCheckHasInstance): - - added additional parameters to check_has_instance opcode - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - - added additional parameters to check_has_instance opcode - * bytecompiler/NodesCodegen.cpp: - (JSC::InstanceOfNode::emitBytecode): - - added additional parameters to check_has_instance opcode - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - - added additional parameters to check_has_instance opcode - * interpreter/Interpreter.cpp: - (JSC::isInvalidParamForIn): - (JSC::Interpreter::privateExecute): - - Add handling for non-default instanceof to op_check_has_instance - * jit/JITInlineMethods.h: - (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex): - - Fixed no-LLInt no_DFG build - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_check_has_instance): - (JSC::JIT::emitSlow_op_check_has_instance): - - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. - (JSC::JIT::emit_op_instanceof): - (JSC::JIT::emitSlow_op_instanceof): - - no need to check for ImplementsDefaultHasInstance. - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_check_has_instance): - (JSC::JIT::emitSlow_op_check_has_instance): - - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. - (JSC::JIT::emit_op_instanceof): - (JSC::JIT::emitSlow_op_instanceof): - - no need to check for ImplementsDefaultHasInstance. + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): * jit/JITStubs.cpp: (JSC::DEFINE_STUB_FUNCTION): + (JSC): * jit/JITStubs.h: - - Add handling for non-default instanceof to op_check_has_instance * llint/LLIntSlowPaths.cpp: + (LLInt): (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: - - move check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. - * runtime/ClassInfo.h: - (MethodTable): - (JSC): - - renamed hasInstance to customHasInstance - * runtime/CommonSlowPaths.h: - (CommonSlowPaths): - - removed opInstanceOfSlow (this was whittled down to one function call!) - * runtime/JSBoundFunction.cpp: - (JSC::JSBoundFunction::customHasInstance): - * runtime/JSBoundFunction.h: - (JSBoundFunction): - - renamed hasInstance to customHasInstance, reimplemented. - * runtime/JSCell.cpp: - (JSC::JSCell::customHasInstance): - * runtime/JSCell.h: - (JSCell): - * runtime/JSObject.cpp: - (JSC::JSObject::hasInstance): + * runtime/JSScope.cpp: + (JSC::LookupResult::base): + (JSC::LookupResult::value): + (JSC::LookupResult::setBase): + (JSC::LookupResult::setValue): + (LookupResult): + (JSC): + (JSC::setPutPropertyAccessOffset): + (JSC::executeResolveOperations): + (JSC::JSScope::resolveContainingScopeInternal): + (JSC::JSScope::resolveContainingScope): + (JSC::JSScope::resolve): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + (JSC::JSScope::resolvePut): + (JSC::JSScope::resolveGlobal): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: (JSC): - (JSC::JSObject::defaultHasInstance): - * runtime/JSObject.h: - (JSObject): - -2012-09-21 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, fix ARM build. - - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::store8): - (MacroAssemblerARMv7): - * offlineasm/armv7.rb: + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/Structure.h: + (JSC::Structure::propertyAccessesAreCacheable): + (Structure): -2012-09-21 Filip Pizlo <fpizlo@apple.com> +2012-10-16 Filip Pizlo <fpizlo@apple.com> - REGRESSION (r128400): Opening Google Web Fonts page hangs or crashes - https://bugs.webkit.org/show_bug.cgi?id=97328 + Accidental switch fall-through in DFG::FixupPhase + https://bugs.webkit.org/show_bug.cgi?id=96956 + <rdar://problem/12313242> Reviewed by Mark Hahnenberg. - It's a bad idea to emit stub code that reallocates property storage when we're in indexed - storage mode. DFGRepatch.cpp knew this and had the appropriate check in one of the places, - but it didn't have it in all of the places. - - This change also adds some more handy disassembly support, which I used to find the bug. - - * assembler/LinkBuffer.h: - (JSC): - * dfg/DFGRepatch.cpp: - (JSC::DFG::generateProtoChainAccessStub): - (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDList): - (JSC::DFG::emitPutReplaceStub): - (JSC::DFG::emitPutTransitionStub): - (JSC::DFG::tryCachePutByID): - * jit/JITStubRoutine.h: - (JSC): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): -2012-09-21 Filip Pizlo <fpizlo@apple.com> +2012-10-16 Filip Pizlo <fpizlo@apple.com> - DFG CSE assumes that a holy PutByVal does not interfere with GetArrayLength, when it clearly does - https://bugs.webkit.org/show_bug.cgi?id=97373 + GetScopedVar CSE matches dead GetScopedVar's leading to IR corruption + https://bugs.webkit.org/show_bug.cgi?id=99470 + <rdar://problem/12363698> Reviewed by Mark Hahnenberg. - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::pureCSE): - (JSC::DFG::CSEPhase::getArrayLengthElimination): - (JSC::DFG::CSEPhase::putStructureStoreElimination): - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGGraph.h: - (Graph): - -2012-09-21 Chris Rogers <crogers@google.com> + All it takes is to follow the "if (!shouldGenerate) continue" idiom and everything will be OK. - Add Web Audio support for deprecated/legacy APIs - https://bugs.webkit.org/show_bug.cgi?id=97050 - - Reviewed by Eric Carlson. - - * Configurations/FeatureDefines.xcconfig: + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkStructureElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): -2012-09-21 Gavin Barraclough <barraclough@apple.com> +2012-10-16 Dima Gorbik <dgorbik@apple.com> - Global Math object should be configurable but isn't - https://bugs.webkit.org/show_bug.cgi?id=55343 + Remove Platform.h include from the header files. + https://bugs.webkit.org/show_bug.cgi?id=98665 - Reviewed by Oliver Hunt. + Reviewed by Eric Seidel. - This has no performance impact. + We don't want other clients that include WebKit headers to know about Platform.h. - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - - Make 'Math' a regular property. + * API/tests/minidom.c: + * API/tests/testapi.c: -2012-09-21 Chao-ying Fu <fu@mips.com> +2012-10-16 Balazs Kilvady <kilvadyb@homejinni.com> - Add MIPS or32 function - https://bugs.webkit.org/show_bug.cgi?id=97157 + Add missing MIPS functions to assembler. + https://bugs.webkit.org/show_bug.cgi?id=98856 - Reviewed by Gavin Barraclough. + Reviewed by Oliver Hunt. - Add a missing or32 function. + Implement missing functions in MacroAssemblerMIPS and MIPSAssembler. + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::lb): + (MIPSAssembler): + (JSC::MIPSAssembler::lh): + (JSC::MIPSAssembler::cvtds): + (JSC::MIPSAssembler::cvtsd): + (JSC::MIPSAssembler::vmov): * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::or32): New function. (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::load8Signed): + (JSC::MacroAssemblerMIPS::load16Signed): + (JSC::MacroAssemblerMIPS::moveDoubleToInts): + (JSC::MacroAssemblerMIPS::moveIntsToDouble): + (JSC::MacroAssemblerMIPS::loadFloat): + (JSC::MacroAssemblerMIPS::loadDouble): + (JSC::MacroAssemblerMIPS::storeFloat): + (JSC::MacroAssemblerMIPS::storeDouble): + (JSC::MacroAssemblerMIPS::addDouble): + (JSC::MacroAssemblerMIPS::convertFloatToDouble): + (JSC::MacroAssemblerMIPS::convertDoubleToFloat): -2012-09-20 Filip Pizlo <fpizlo@apple.com> +2012-10-16 Balazs Kilvady <kilvadyb@homejinni.com> - CHECK_ARRAY_CONSISTENCY isn't being used or tested, so we should remove it - https://bugs.webkit.org/show_bug.cgi?id=97260 - - Rubber stamped by Geoffrey Garen. - - Supporting it will become difficult as we add more indexing types. It makes more - sense to kill, especially since we don't appear to use it or test it, ever. - - * runtime/ArrayConventions.h: - (JSC): - * runtime/ArrayPrototype.cpp: - (JSC::arrayProtoFuncSplice): - * runtime/ArrayStorage.h: - (JSC::ArrayStorage::copyHeaderFromDuringGC): - (ArrayStorage): - * runtime/FunctionPrototype.cpp: - (JSC::functionProtoFuncBind): - * runtime/JSArray.cpp: - (JSC::createArrayButterflyInDictionaryIndexingMode): - (JSC::JSArray::setLength): - (JSC::JSArray::pop): - (JSC::JSArray::push): - (JSC::JSArray::sortNumeric): - (JSC::JSArray::sort): - (JSC::JSArray::compactForSorting): - * runtime/JSArray.h: - (JSArray): - (JSC::createArrayButterfly): - (JSC::JSArray::tryCreateUninitialized): - (JSC::constructArray): - * runtime/JSObject.cpp: - (JSC::JSObject::putByIndex): - (JSC::JSObject::createArrayStorage): - (JSC::JSObject::deletePropertyByIndex): - (JSC): - * runtime/JSObject.h: - (JSC::JSObject::initializeIndex): - (JSObject): - -2012-09-20 Mark Lam <mark.lam@apple.com> - - Fixed a missing semicolon in the C++ llint backend. - https://bugs.webkit.org/show_bug.cgi?id=97252. - - Reviewed by Geoff Garen. - - * offlineasm/cloop.rb: - -2012-09-20 Geoffrey Garen <ggaren@apple.com> - - Refactored the interpreter and JIT so they don't dictate closure layout - https://bugs.webkit.org/show_bug.cgi?id=97221 + MIPS assembler coding-style fix. + https://bugs.webkit.org/show_bug.cgi?id=99359 Reviewed by Oliver Hunt. - Capture may change the location of an argument for space efficiency. This - patch removes static assumptions about argument location from the interpreter - and JIT. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::argumentIndexAfterCapture): - (JSC::ExecState::argumentAfterCapture): Factored out a helper function - so the compiler could share this logic. - - * bytecompiler/NodesCodegen.cpp: - (JSC::BracketAccessorNode::emitBytecode): Don't emit optimized bracket - access on arguments if a parameter has been captured by name. This case is - rare and, where I've seen it in the wild, the optimization mostly failed - anyway due to arguments escape, so I didn't feel like writing and testing - five copies of the code that would handle it in the baseline engines. + Coding style fix of existing MIPS assembler header files. - The DFG can still synthesize this optimization even if we don't emit the - optimized bytecode for it. + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::addiu): + (JSC::MIPSAssembler::addu): + (JSC::MIPSAssembler::subu): + (JSC::MIPSAssembler::mul): + (JSC::MIPSAssembler::andInsn): + (JSC::MIPSAssembler::andi): + (JSC::MIPSAssembler::nor): + (JSC::MIPSAssembler::orInsn): + (JSC::MIPSAssembler::ori): + (JSC::MIPSAssembler::xorInsn): + (JSC::MIPSAssembler::xori): + (JSC::MIPSAssembler::slt): + (JSC::MIPSAssembler::sltu): + (JSC::MIPSAssembler::sltiu): + (JSC::MIPSAssembler::sll): + (JSC::MIPSAssembler::sllv): + (JSC::MIPSAssembler::sra): + (JSC::MIPSAssembler::srav): + (JSC::MIPSAssembler::srl): + (JSC::MIPSAssembler::srlv): + (JSC::MIPSAssembler::lbu): + (JSC::MIPSAssembler::lw): + (JSC::MIPSAssembler::lwl): + (JSC::MIPSAssembler::lwr): + (JSC::MIPSAssembler::lhu): + (JSC::MIPSAssembler::sb): + (JSC::MIPSAssembler::sh): + (JSC::MIPSAssembler::sw): + (JSC::MIPSAssembler::addd): + (JSC::MIPSAssembler::subd): + (JSC::MIPSAssembler::muld): + (JSC::MIPSAssembler::divd): + (JSC::MIPSAssembler::lwc1): + (JSC::MIPSAssembler::ldc1): + (JSC::MIPSAssembler::swc1): + (JSC::MIPSAssembler::sdc1): + (MIPSAssembler): + (JSC::MIPSAssembler::relocateJumps): + (JSC::MIPSAssembler::linkWithOffset): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::add32): + (JSC::MacroAssemblerMIPS::and32): + (JSC::MacroAssemblerMIPS::sub32): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::load8): + (JSC::MacroAssemblerMIPS::load32): + (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords): + (JSC::MacroAssemblerMIPS::load16): + (JSC::MacroAssemblerMIPS::store8): + (JSC::MacroAssemblerMIPS::store16): + (JSC::MacroAssemblerMIPS::store32): + (JSC::MacroAssemblerMIPS::nearCall): + (JSC::MacroAssemblerMIPS::test8): + (JSC::MacroAssemblerMIPS::test32): + +2012-10-16 Yuqiang Xian <yuqiang.xian@intel.com> + + Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands + https://bugs.webkit.org/show_bug.cgi?id=99154 - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGAssemblyHelpers.h: - (JSC::DFG::AssemblyHelpers::symbolTableFor): - (AssemblyHelpers): Use the right helper function to account for the fact - that a parameter may have been captured by name and moved. + Reviewed by Gavin Barraclough. - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): ASSERT that we haven't inlined - a .apply on captured arguments. Once we do start inlining such things, - we'll need to do a little bit of math here to get them right. + In current JavaScriptCore implementation for JSVALUE64 platform (i.e., + the X64 platform), we assume that the JSValue size is same to the + pointer size, and thus EncodedJSValue is simply type defined as a + "void*". In the JIT compiler, we also take this assumption and invoke + the same macro assembler interfaces for both JSValue and pointer + operands. We need to differentiate the operations on pointers from the + operations on JSValues, and let them invoking different macro + assembler interfaces. For example, we now use the interface of + "loadPtr" to load either a pointer or a JSValue, and we need to switch + to using "loadPtr" to load a pointer and some new "load64" interface + to load a JSValue. This would help us supporting other JSVALUE64 + platforms where pointer size is not necessarily 64-bits, for example + x32 (bug #99153). + + The major modification I made is to introduce the "*64" interfaces in + the MacroAssembler for those operations on JSValues, keep the "*Ptr" + interfaces for those operations on real pointers, and go through all + the JIT compiler code to correct the usage. + + This is the first part of the work, i.e, to add the *64 interfaces to + the MacroAssembler. + + * assembler/AbstractMacroAssembler.h: Add the Imm64 interfaces. + (AbstractMacroAssembler): + (JSC::AbstractMacroAssembler::TrustedImm64::TrustedImm64): + (TrustedImm64): + (JSC::AbstractMacroAssembler::Imm64::Imm64): + (Imm64): + (JSC::AbstractMacroAssembler::Imm64::asTrustedImm64): + * assembler/MacroAssembler.h: map <foo>Ptr methods to <foo>64 for X86_64. + (MacroAssembler): + (JSC::MacroAssembler::peek64): + (JSC::MacroAssembler::poke): + (JSC::MacroAssembler::poke64): + (JSC::MacroAssembler::addPtr): + (JSC::MacroAssembler::andPtr): + (JSC::MacroAssembler::negPtr): + (JSC::MacroAssembler::orPtr): + (JSC::MacroAssembler::rotateRightPtr): + (JSC::MacroAssembler::subPtr): + (JSC::MacroAssembler::xorPtr): + (JSC::MacroAssembler::loadPtr): + (JSC::MacroAssembler::loadPtrWithAddressOffsetPatch): + (JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch): + (JSC::MacroAssembler::storePtr): + (JSC::MacroAssembler::storePtrWithAddressOffsetPatch): + (JSC::MacroAssembler::movePtrToDouble): + (JSC::MacroAssembler::moveDoubleToPtr): + (JSC::MacroAssembler::comparePtr): + (JSC::MacroAssembler::testPtr): + (JSC::MacroAssembler::branchPtr): + (JSC::MacroAssembler::branchTestPtr): + (JSC::MacroAssembler::branchAddPtr): + (JSC::MacroAssembler::branchSubPtr): + (JSC::MacroAssembler::shouldBlindDouble): + (JSC::MacroAssembler::shouldBlind): + (JSC::MacroAssembler::RotatedImm64::RotatedImm64): + (RotatedImm64): + (JSC::MacroAssembler::rotationBlindConstant): + (JSC::MacroAssembler::loadRotationBlindedConstant): + (JSC::MacroAssembler::move): + (JSC::MacroAssembler::and64): + (JSC::MacroAssembler::store64): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::shouldBlindForSpecificArch): + (MacroAssemblerX86Common): + (JSC::MacroAssemblerX86Common::move): + * assembler/MacroAssemblerX86_64.h: Add the <foo>64 methods for X86_64. + (JSC::MacroAssemblerX86_64::branchAdd32): + (JSC::MacroAssemblerX86_64::add64): + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::and64): + (JSC::MacroAssemblerX86_64::neg64): + (JSC::MacroAssemblerX86_64::or64): + (JSC::MacroAssemblerX86_64::rotateRight64): + (JSC::MacroAssemblerX86_64::sub64): + (JSC::MacroAssemblerX86_64::xor64): + (JSC::MacroAssemblerX86_64::load64): + (JSC::MacroAssemblerX86_64::load64WithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::load64WithCompactAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::store64): + (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::move64ToDouble): + (JSC::MacroAssemblerX86_64::moveDoubleTo64): + (JSC::MacroAssemblerX86_64::compare64): + (JSC::MacroAssemblerX86_64::branch64): + (JSC::MacroAssemblerX86_64::branchTest64): + (JSC::MacroAssemblerX86_64::test64): + (JSC::MacroAssemblerX86_64::branchAdd64): + (JSC::MacroAssemblerX86_64::branchSub64): + (JSC::MacroAssemblerX86_64::branchPtrWithPatch): + (JSC::MacroAssemblerX86_64::storePtrWithPatch): + +2012-10-15 Mark Hahnenberg <mhahnenberg@apple.com> + + Make CopiedSpace and MarkedSpace regions independent + https://bugs.webkit.org/show_bug.cgi?id=99222 - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Added support for bracket access on - an arguments object where arguments have also been captured by name. We - load the true index of the argument from a side vector. Arguments elision - is very powerful in the DFG, so I wanted to keep it working, even in this - rare case. + Reviewed by Filip Pizlo. - * interpreter/Interpreter.cpp: - (JSC::loadVarargs): Use the right helper function to account for the fact - that a parameter may have been captured by name and moved. + Right now CopiedSpace and MarkedSpace have the same block size and share the same regions, + but there's no reason that they can't have different block sizes while still sharing the + same underlying regions. We should factor the two "used" lists of regions apart so that + MarkedBlocks and CopiedBlocks can be different sizes. Regions will still be a uniform size + so that when they become empty they may be shared between the CopiedSpace and the MarkedSpace, + since benchmarks indicate that sharing is a boon for performance. - * jit/JITCall.cpp: - (JSC::JIT::compileLoadVarargs): - * jit/JITCall32_64.cpp: - (JSC::JIT::compileLoadVarargs): Don't use the inline copy loop if some - of our arguments have moved, since it would copy stale values. (We still - optimize the actual call, and elide the arguments object.) + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: + (JSC): + (Region): + (JSC::Region::create): We now have a fixed size for Regions so that empty regions can continue to + be shared between the MarkedSpace and CopiedSpace. Once they are used for a specific type of block, + however, they can only be used for that type of block until they become empty again. + (JSC::Region::createCustomSize): + (JSC::Region::Region): + (JSC::Region::~Region): + (JSC::Region::reset): + (BlockAllocator): + (JSC::BlockAllocator::RegionSet::RegionSet): + (RegionSet): + (JSC::BlockAllocator::tryAllocateFromRegion): We change this function so that it correctly + moves blocks between empty, partial, and full lists. + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::allocateCustomSize): + (JSC::BlockAllocator::deallocate): Ditto. + (JSC::CopiedBlock): + (JSC::MarkedBlock): + (JSC::BlockAllocator::regionSetFor): We use this so that we can use the same allocate/deallocate + functions with different RegionSets. We specialize the function for each type of block that we + want to allocate. + * heap/CopiedBlock.h: + (CopiedBlock): + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/HeapBlock.h: + (HeapBlock): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): For oversize MarkedBlocks, if the block size gets too big we can + underflow the endAtom, which will cause us to segfault when we try to sweep a block. If we're a + custom size MarkedBlock we need to calculate endAtom so it doesn't underflow. -2012-09-20 Gabor Rapcsanyi <rgabor@webkit.org> +2012-10-14 Filip Pizlo <fpizlo@apple.com> - [Qt] r129045 broke the ARM build - https://bugs.webkit.org/show_bug.cgi?id=97195 + JIT::JIT fails to initialize all of its fields + https://bugs.webkit.org/show_bug.cgi?id=99283 - Reviewed by Zoltan Herczeg. + Reviewed by Andreas Kling. - Implementing missing store8 function. + There were two groups of such fields, all of which are eventually initialized + prior to use inside of privateCompile(). But it's safer to make sure that they + are initialized in the constructor as well, since we may use the JIT to do a + stub compile without calling into privateCompile(). + + Unsigned index fields for dynamic repatching meta-data: this change + initializes them to UINT_MAX, so we should crash if we try to use those + indices without initializing them. + + Boolean flags for value profiling: this change initializes them to false, so + we at worst turn off value profiling. - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::store8): - (MacroAssemblerARM): + * jit/JIT.cpp: + (JSC::JIT::JIT): -2012-09-19 Geoffrey Garen <ggaren@apple.com> +2012-10-15 Mark Hahnenberg <mhahnenberg@apple.com> - OSR exit sometimes neglects to create the arguments object - https://bugs.webkit.org/show_bug.cgi?id=97162 + We should avoid weakCompareAndSwap when parallel GC is disabled + https://bugs.webkit.org/show_bug.cgi?id=99331 Reviewed by Filip Pizlo. - No performance change. - - I don't know of any case where this is a real problem in TOT, but it - will become a problem if we start compiling eval, with, or catch, and/or - sometimes stop doing arguments optimizations in the bytecode. - - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): Account for a - CreateArguments that has transformed into PhantomArguments. We used to - clear our reference to the CreateArguments node, but now we hold onto it, - so we need to account for it transforming. - - Don't replace a SetLocal(CreateArguments) with a SetLocal(JSValue()) - because that doesn't leave enough information behind for OSR exit to do - the right thing. Instead, maintain our reference to CreateArguments, and - rely on CreateArguments transforming into PhantomArguments after - optimization. SetLocal(PhantomArguments) is efficient, and it's a marker - for OSR exit to create the arguments object. - - Don't ASSERT that all PhantomArguments are unreferenced because we now - leave them in the graph as SetLocal(PhantomArguments), and that's harmless. - - * dfg/DFGArgumentsSimplificationPhase.h: - (NullableHashTraits): - (JSC::DFG::NullableHashTraits::emptyValue): Export our special hash table - for inline call frames so the OSR exit compiler can use it. - - * dfg/DFGOSRExitCompiler32_64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): Don't load the 'arguments' - register to decide if we need to create the arguments object. Optimization - may have eliminated the initializing store to this register, in which - case we'll load garbage. Instead, use the global knowledge that all call - frames that optimized out 'arguments' now need to create it, and use a hash - table to make sure we do so only once per call frame. - - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): SetLocal(PhantomArguments) is unique - because we haven't just changed a value's format or elided a load or store; - instead, we've replaced an object with JSValue(). We could try to account - for this in a general way, but for now it's a special-case optimization, - so we give it a specific OSR hint instead. - -2012-09-19 Filip Pizlo <fpizlo@apple.com> - - REGRESSION(r128802): It made some JS tests crash - https://bugs.webkit.org/show_bug.cgi?id=97001 + CopiedBlock::reportLiveBytes and didEvacuateBytes uses weakCompareAndSwap, which some platforms + don't support. For platforms that don't have parallel GC enabled, we should just use a normal store. - Reviewed by Mark Hahnenberg. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::visitChildren): - -2012-09-19 Filip Pizlo <fpizlo@apple.com> + * heap/CopiedBlock.h: + (JSC::CopiedBlock::reportLiveBytes): + (JSC::CopiedBlock::didEvacuateBytes): - DFG should not assume that a ByVal access is generic just because it was unprofiled - https://bugs.webkit.org/show_bug.cgi?id=97088 +2012-10-15 Carlos Garcia Campos <cgarcia@igalia.com> - Reviewed by Geoffrey Garen. - - We were not disambiguating between "Undecided" in the sense that the array profile - has no useful information versus "Undecided" in the sense that the array profile - knows that the access has not executed. That's an important distinction, since - the former form of "Undecided" means that we should consult value profiling, while - the latter means that we should force exit unless the value profiling indicates - that the access must be generic (base is not cell or property is not int). + Unreviewed. Fix make distcheck. - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::fromObserved): - (JSC::DFG::refineArrayMode): - (JSC::DFG::modeAlreadyChecked): - (JSC::DFG::modeToString): - * dfg/DFGArrayMode.h: - (JSC::DFG::canCSEStorage): - (JSC::DFG::modeIsSpecific): - (JSC::DFG::modeSupportsLength): - (JSC::DFG::benefitsFromStructureCheck): + * GNUmakefile.list.am: Add missing header file. -2012-09-19 Filip Pizlo <fpizlo@apple.com> +2012-10-14 Filip Pizlo <fpizlo@apple.com> - DFG should not emit PutByVal hole case unless it has to - https://bugs.webkit.org/show_bug.cgi?id=97080 + DFG should handle polymorphic array modes by eagerly transforming arrays into the most general applicable form + https://bugs.webkit.org/show_bug.cgi?id=99269 Reviewed by Geoffrey Garen. - This causes us to generate less code for typical PutByVal's. But if profiling tells us - that the hole case is being hit, we generate the same code as we would have generated - before. This seems like a slight speed-up across the board. + This kills off a bunch of code for "polymorphic" array modes in the DFG. It should + also be a performance win for code that uses a lot of array storage arrays. - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::store8): - (MacroAssemblerARMv7): - * assembler/MacroAssemblerX86.h: - (MacroAssemblerX86): - (JSC::MacroAssemblerX86::store8): - * assembler/MacroAssemblerX86_64.h: - (MacroAssemblerX86_64): - (JSC::MacroAssemblerX86_64::store8): - * assembler/X86Assembler.h: - (X86Assembler): - (JSC::X86Assembler::movb_i8m): - * bytecode/ArrayProfile.h: - (JSC::ArrayProfile::ArrayProfile): - (JSC::ArrayProfile::addressOfMayStoreToHole): - (JSC::ArrayProfile::mayStoreToHole): - (ArrayProfile): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::fromObserved): - (JSC::DFG::modeAlreadyChecked): - (JSC::DFG::modeToString): - * dfg/DFGArrayMode.h: - (DFG): - (JSC::DFG::mayStoreToHole): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JIT.h: - (JIT): - * jit/JITInlineMethods.h: - (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): - (JSC): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_put_by_val): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_put_by_val): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-18 Filip Pizlo <fpizlo@apple.com> - - DFG should not call out to C++ every time that it tries to put to an object that doesn't yet have array storage - https://bugs.webkit.org/show_bug.cgi?id=96983 - - Reviewed by Oliver Hunt. - - Introduce more polymorphism into the DFG's array mode support. Use that to - introduce the notion of effectul array modes, where the check for the mode - will perform actions necessary to ensure that we have the mode we want, if - the object is not already in that mode. Also added profiling support for - checking if an object is of a type that would not allow us to create array - storage (like a typed array or a string for example). - - This is a ~2x speed-up on loops that transform an object that did not have - indexed storage into one that does. - - * JSCTypedArrayStubs.h: - (JSC): - * bytecode/ArrayProfile.cpp: - (JSC::ArrayProfile::computeUpdatedPrediction): - * bytecode/ArrayProfile.h: - (JSC::ArrayProfile::ArrayProfile): - (JSC::ArrayProfile::mayInterceptIndexedAccesses): - (ArrayProfile): * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): * dfg/DFGArrayMode.cpp: (JSC::DFG::fromObserved): - (DFG): (JSC::DFG::modeAlreadyChecked): (JSC::DFG::modeToString): * dfg/DFGArrayMode.h: (DFG): (JSC::DFG::modeUsesButterfly): - (JSC::DFG::isSlowPutAccess): + (JSC::DFG::modeIsJSArray): + (JSC::DFG::mayStoreToTail): + (JSC::DFG::mayStoreToHole): + (JSC::DFG::canCSEStorage): + (JSC::DFG::modeSupportsLength): (JSC::DFG::benefitsFromStructureCheck): - (JSC::DFG::isEffectful): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getArrayMode): - (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): * dfg/DFGGraph.h: (JSC::DFG::Graph::byValIsPure): - * dfg/DFGNode.h: - (JSC::DFG::Node::hasArrayMode): - * dfg/DFGNodeType.h: - (DFG): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::arrayify): (DFG): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): - * runtime/Arguments.h: - (Arguments): - * runtime/JSNotAnObject.h: - (JSNotAnObject): - * runtime/JSObject.h: - (JSObject): - (JSC::JSObject::ensureArrayStorage): - * runtime/JSString.h: - (JSC::JSString::createStructure): -2012-09-18 Filip Pizlo <fpizlo@apple.com> +2012-10-14 Filip Pizlo <fpizlo@apple.com> - Include PhantomArguments in DFGDisassembly - https://bugs.webkit.org/show_bug.cgi?id=97043 + REGRESSION(126886): Fat binary builds don't know how to handle architecture variants to which the LLInt is agnostic + https://bugs.webkit.org/show_bug.cgi?id=99270 Reviewed by Geoffrey Garen. - * dfg/DFGNode.h: - (JSC::DFG::Node::willHaveCodeGenOrOSR): + The fix is to hash cons the offsets based on configuration index, not the offsets + themselves. -2012-09-18 Filip Pizlo <fpizlo@apple.com> + * offlineasm/offsets.rb: - REGRESSION(r128802): It made some JS tests crash - https://bugs.webkit.org/show_bug.cgi?id=97001 +2012-10-13 Filip Pizlo <fpizlo@apple.com> - Reviewed by Mark Hahnenberg. + IndexingType should not have a bit for each type + https://bugs.webkit.org/show_bug.cgi?id=98997 - IndexingHeaderInlineMethods was incorrectly assuming that if the HasArrayStorage bit is clear, then that means that indexing payload capacity is zero. + Reviewed by Oliver Hunt. - * runtime/IndexingHeaderInlineMethods.h: - (JSC::IndexingHeader::preCapacity): - (JSC::IndexingHeader::indexingPayloadSizeInBytes): + Somewhat incidentally, the introduction of butterflies led to each indexing + type being represented by a unique bit. This is superficially nice since it + allows you to test if a structure corresponds to a particular indexing type + by saying !!(structure->indexingType() & TheType). But the downside is that + given the 8 bits we have for the m_indexingType field, that leaves only a + small number of possible indexing types if we have one per bit. + + This changeset changes the indexing type to be: + + Bit #1: Tells you if you're an array. + + Bits #2 - #5: 16 possible indexing types, including the blank type for + objects that don't have indexed properties. + + Bits #6-8: Auxiliary bits that we could use for other things. Currently we + just use one of those bits, for MayHaveIndexedAccessors. + + This is performance-neutral, and is primarily intended to give us more + breathing room for introducing new inferred array modes. -2012-09-18 Mark Hahnenberg <mhahnenberg@apple.com> + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::JumpList::jumps): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranch32): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::patchableBranch32): + (MacroAssemblerARMv7): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::modeAlreadyChecked): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (DFG): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateJSArray): + (JSC::JIT::chooseArrayMode): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/IndexingType.h: + (JSC): + (JSC::hasIndexedProperties): + (JSC::hasContiguous): + (JSC::hasFastArrayStorage): + (JSC::hasArrayStorage): + (JSC::shouldUseSlowPut): + * runtime/JSGlobalObject.cpp: + (JSC): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): - Use WTF::HasTrivialDestructor instead of compiler-specific versions in JSC::NeedsDestructor - https://bugs.webkit.org/show_bug.cgi?id=96980 +2012-10-14 Filip Pizlo <fpizlo@apple.com> - Reviewed by Benjamin Poulain. + DFG structure check hoisting should attempt to ignore side effects and make transformations that are sound even in their presence + https://bugs.webkit.org/show_bug.cgi?id=99262 - * runtime/JSCell.h: - (JSC): - (NeedsDestructor): + Reviewed by Oliver Hunt. -2012-09-18 Filip Pizlo <fpizlo@apple.com> + This hugely simplifies the structure check hoisting phase. It will no longer be necessary + to modify it when the effectfulness of operations changes. This also enables the hoister + to hoist effectful things in the future. + + The downside is that the hoister may end up adding strictly more checks than were present + in the original code, if the code truly has a lot of side-effects. I don't see evidence + of this happening. This patch does have some speed-ups and some slow-downs, but is + neutral in the average, and the slow-downs do not appear to have more structure checks + than ToT. - DFGOperations doesn't use NativeCallFrameTracer in enough places - https://bugs.webkit.org/show_bug.cgi?id=96987 + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (StructureCheckHoistingPhase): + (CheckData): + (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData): - Reviewed by Mark Hahnenberg. +2012-10-14 Filip Pizlo <fpizlo@apple.com> - Anything that can GC should use it. + Fix the build of universal binary with ARMv7s of JavaScriptCore - * dfg/DFGOperations.cpp: + * llint/LLIntOfflineAsmConfig.h: + * llint/LowLevelInterpreter.asm: -2012-09-18 Mark Lam <mark.lam@apple.com> +2012-10-13 Filip Pizlo <fpizlo@apple.com> - Not reviewed. Attempt at greening the WinCairo bot. Touching - LowLevelInterpreter.asm to trigger a rebuild of LLIntDesiredOffsets. - https://bugs.webkit.org/show_bug.cgi?id=96992. + Array length array profiling is broken in the baseline JIT + https://bugs.webkit.org/show_bug.cgi?id=99258 - * llint/LowLevelInterpreter.asm: + Reviewed by Oliver Hunt. -2012-09-18 Peter Gal <galpeter@inf.u-szeged.hu> + The code generator for array length stubs calls into + emitArrayProfilingSiteForBytecodeIndex(), which emits profiling only if + canBeOptimized() returns true. But m_canBeOptimized is only initialized during + full method compiles, so in a stub compile it may (or may not) be false, meaning + that we may, or may not, get meaningful profiling info. + + This appeared to not affect too many programs since the LLInt has good array + length array profiling. - [Qt] REGRESSION(r128790): It broke the ARM build - https://bugs.webkit.org/show_bug.cgi?id=96968 + * jit/JIT.h: + (JSC::JIT::compilePatchGetArrayLength): - Reviewed by Filip Pizlo. +2012-10-14 Patrick Gansterer <paroga@webkit.org> - Implement the missing or32 method in the MacroAssemblerARM.h. + Build fix for WinCE after r131089. - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::or32): - (MacroAssemblerARM): + WinCE does not support getenv(). -2012-09-18 Mark Lam <mark.lam@apple.com> + * runtime/Options.cpp: + (JSC::overrideOptionWithHeuristic): - Fix for WinCairo builds. - https://bugs.webkit.org/show_bug.cgi?id=96992. +2012-10-12 Kangil Han <kangil.han@samsung.com> - Reviewed by Filip Pizlo. + Fix build error on DFGSpeculativeJIT32_64.cpp + https://bugs.webkit.org/show_bug.cgi?id=99234 - Adding additional vcproj build targets in LLIntDesiredOffsets.vcproj, - LLIntOffsetsExtractor.vcproj, and LLIntAssembly.vcproj to match those - in jsc.vcproj. + Reviewed by Anders Carlsson. - * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: - * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added property svn:eol-style. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added property svn:eol-style. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added property svn:eol-style. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Added. + Seems BUG 98608 causes build error on 32bit machine so fix it. -2012-09-18 Filip Pizlo <fpizlo@apple.com> + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): - Unreviewed, fix sloppy English in comment. +2012-10-12 Filip Pizlo <fpizlo@apple.com> - * runtime/JSGlobalObject.cpp: - (JSC): + Contiguous array allocation should always be inlined + https://bugs.webkit.org/show_bug.cgi?id=98608 -2012-09-17 Csaba Osztrogonác <ossy@webkit.org> + Reviewed by Oliver Hunt and Mark Hahnenberg. - Unreviewed, rolling out r128826 and r128813. + This inlines contiguous array allocation in the most obvious way possible. - * API/JSCallbackConstructor.cpp: - (JSC): - (JSC::JSCallbackConstructor::JSCallbackConstructor): - * API/JSCallbackConstructor.h: - (JSCallbackConstructor): - * API/JSCallbackObject.cpp: - (JSC): - (JSC::::createStructure): - * API/JSCallbackObject.h: - (JSC::JSCallbackObject::create): - (JSCallbackObject): - * API/JSClassRef.cpp: - (OpaqueJSClass::prototype): - * API/JSObjectRef.cpp: - (JSObjectMake): - (JSObjectGetPrivate): - (JSObjectSetPrivate): - (JSObjectGetPrivateProperty): - (JSObjectSetPrivateProperty): - (JSObjectDeletePrivateProperty): - * API/JSValueRef.cpp: - (JSValueIsObjectOfClass): - * API/JSWeakObjectMapRefPrivate.cpp: - * GNUmakefile.list.am: - * JSCTypedArrayStubs.h: - (JSC): - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::branchSubPtr): + (MacroAssembler): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::branchSubPtr): + (MacroAssemblerX86_64): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: Added. + (DFG): + (CallArrayAllocatorSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal): + (CallArrayAllocatorWithVariableSizeSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): + (DFG): + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): - * heap/Heap.cpp: - (JSC::Heap::isSafeToSweepStructures): - (JSC): - * heap/Heap.h: - (JSC::Heap::allocatorForObjectWithDestructor): - (Heap): - (JSC::Heap::allocateWithDestructor): - (JSC::Heap::allocateStructure): - (JSC): - * heap/IncrementalSweeper.cpp: - (JSC::IncrementalSweeper::IncrementalSweeper): - (JSC::IncrementalSweeper::sweepNextBlock): - (JSC::IncrementalSweeper::startSweeping): - (JSC::IncrementalSweeper::willFinishSweeping): - (JSC::IncrementalSweeper::structuresCanBeSwept): - (JSC): - * heap/IncrementalSweeper.h: - (IncrementalSweeper): - * heap/MarkedAllocator.cpp: - (JSC::MarkedAllocator::tryAllocateHelper): - (JSC::MarkedAllocator::allocateBlock): - * heap/MarkedAllocator.h: - (JSC::MarkedAllocator::cellsNeedDestruction): - (JSC::MarkedAllocator::onlyContainsStructures): - (MarkedAllocator): - (JSC::MarkedAllocator::MarkedAllocator): - (JSC::MarkedAllocator::init): - * heap/MarkedBlock.cpp: - (JSC::MarkedBlock::create): - (JSC::MarkedBlock::MarkedBlock): - (JSC): - (JSC::MarkedBlock::specializedSweep): - (JSC::MarkedBlock::sweep): - (JSC::MarkedBlock::sweepHelper): - * heap/MarkedBlock.h: - (JSC): - (MarkedBlock): - (JSC::MarkedBlock::cellsNeedDestruction): - (JSC::MarkedBlock::onlyContainsStructures): - * heap/MarkedSpace.cpp: - (JSC::MarkedSpace::MarkedSpace): - (JSC::MarkedSpace::resetAllocators): - (JSC::MarkedSpace::canonicalizeCellLivenessData): - (JSC::MarkedSpace::isPagedOut): - (JSC::MarkedSpace::freeBlock): - * heap/MarkedSpace.h: - (MarkedSpace): - (Subspace): - (JSC::MarkedSpace::allocatorFor): - (JSC::MarkedSpace::destructorAllocatorFor): - (JSC::MarkedSpace::allocateWithDestructor): - (JSC::MarkedSpace::allocateStructure): - (JSC::MarkedSpace::forEachBlock): - * heap/SlotVisitor.cpp: - * jit/JIT.h: - * jit/JITInlineMethods.h: - (JSC::JIT::emitAllocateBasicJSObject): - (JSC::JIT::emitAllocateJSFinalObject): - (JSC::JIT::emitAllocateJSArray): - * jsc.cpp: - (GlobalObject::create): - * runtime/Arguments.cpp: - (JSC): - * runtime/Arguments.h: - (Arguments): - (JSC::Arguments::Arguments): - * runtime/ErrorPrototype.cpp: - (JSC): - * runtime/Executable.h: - * runtime/InternalFunction.cpp: - (JSC): - (JSC::InternalFunction::InternalFunction): - * runtime/InternalFunction.h: - (InternalFunction): - * runtime/JSCell.h: - (JSC): - (JSC::allocateCell): - * runtime/JSDestructibleObject.h: Removed. - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (JSC): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::createRareDataIfNeeded): - (JSC::JSGlobalObject::create): - * runtime/JSGlobalThis.h: - (JSGlobalThis): - (JSC::JSGlobalThis::JSGlobalThis): - * runtime/JSPropertyNameIterator.h: - * runtime/JSScope.cpp: - (JSC): - * runtime/JSString.h: - (JSC): - * runtime/JSWrapperObject.h: - (JSWrapperObject): - (JSC::JSWrapperObject::JSWrapperObject): - * runtime/MathObject.cpp: - (JSC): - * runtime/NameInstance.h: - (NameInstance): - * runtime/RegExp.h: - * runtime/RegExpObject.cpp: - (JSC): - * runtime/SparseArrayValueMap.h: - * runtime/Structure.h: - (JSC::Structure): - (JSC::JSCell::classInfo): - (JSC): - * runtime/StructureChain.h: - * runtime/SymbolTable.h: - * testRegExp.cpp: - (GlobalObject::create): - -2012-09-17 Geoffrey Garen <ggaren@apple.com> - - Refactored the arguments object so it doesn't dictate closure layout - https://bugs.webkit.org/show_bug.cgi?id=96955 + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): - Reviewed by Oliver Hunt. +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> - * bytecode/CodeBlock.h: - (JSC::ExecState::argumentAfterCapture): Helper function for accessing an - argument that has been moved for capture. + Race condition during CopyingPhase can lead to deadlock + https://bugs.webkit.org/show_bug.cgi?id=99226 - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): Generate metadata for arguments - that are captured. We don't move any arguments yet, but we do use this - metadata to tell the arguments object if an argument is stored in the - activation. + Reviewed by Filip Pizlo. - * dfg/DFGOperations.cpp: - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): - (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Updated for the arguments object not - malloc'ing a separate backing store, and for a rename from deletedArguments - to slowArguments. + The main thread calls startCopying() for each of the GCThreads at the beginning of the copy phase. + It then proceeds to start copying. If copying completes before one of the GCThreads wakes up, the + main thread will set m_currentPhase back to NoPhase, the GCThread will wake up, see that there's + nothing to do, and then it will go back to sleep without ever calling CopyVisitor::doneCopying() + to return its borrowed block to the CopiedSpace. CopiedSpace::doneCopying() will then sleep forever + waiting on the block. - * interpreter/CallFrame.h: - (ExecState): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): - (JSC::Interpreter::privateExecute): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): Updated for small interface changes. + The fix for this is to make sure we call CopiedSpace::doneCopying() on the main thread before we + call GCThreadSharedData::didFinishCopying(), which sets the m_currentPhase flag to NoPhase. This + way we will wait until all threads have woken up and given back their borrowed blocks before + clearing the flag. - * runtime/Arguments.cpp: - (JSC::Arguments::visitChildren): - (JSC::Arguments::copyToArguments): - (JSC::Arguments::fillArgList): - (JSC::Arguments::getOwnPropertySlotByIndex): - (JSC::Arguments::createStrictModeCallerIfNecessary): - (JSC::Arguments::createStrictModeCalleeIfNecessary): - (JSC::Arguments::getOwnPropertySlot): - (JSC::Arguments::getOwnPropertyDescriptor): - (JSC::Arguments::getOwnPropertyNames): - (JSC::Arguments::putByIndex): - (JSC::Arguments::put): - (JSC::Arguments::deletePropertyByIndex): - (JSC::Arguments::deleteProperty): - (JSC::Arguments::defineOwnProperty): - (JSC::Arguments::tearOff): Moved all data inline into the object, for speed, - and refactored all internal argument accesses to use helper functions, so - we can change the implementation without changing lots of code. - - (JSC::Arguments::didTearOffActivation): This function needs to account - for arguments that were moved by the activation object. We do this accounting - through a side vector that tells us where our arguments will be in the - activation. + * heap/Heap.cpp: + (JSC::Heap::copyBackingStores): - (JSC::Arguments::tearOffForInlineCallFrame): - * runtime/Arguments.h: - (Arguments): - (JSC::Arguments::length): - (JSC::Arguments::isTornOff): - (JSC::Arguments::Arguments): - (JSC::Arguments::allocateSlowArguments): - (JSC::Arguments::tryDeleteArgument): - (JSC::Arguments::trySetArgument): - (JSC::Arguments::tryGetArgument): - (JSC::Arguments::isDeletedArgument): - (JSC::Arguments::isArgument): - (JSC::Arguments::argument): - (JSC::Arguments::finishCreation): - - * runtime/JSActivation.h: - (JSC::JSActivation::create): - (JSActivation): - (JSC::JSActivation::captureStart): - (JSC::JSActivation::storageSize): - (JSC::JSActivation::registerOffset): - (JSC::JSActivation::isValid): The activation object is no longer responsible - for copying extra arguments provided by the caller. The argumnents object - does this instead. This means we can allocate and initialize an activation - without worrying about the call frame's argument count. - - * runtime/SymbolTable.h: - (JSC::SlowArgument::SlowArgument): - (SlowArgument): - (JSC): - (JSC::SharedSymbolTable::parameterCount): - (SharedSymbolTable): - (JSC::SharedSymbolTable::slowArguments): - (JSC::SharedSymbolTable::setSlowArguments): Added data structures to back - the algorithms above. +2012-10-12 Anders Carlsson <andersca@apple.com> -2012-09-17 Filip Pizlo <fpizlo@apple.com> + Move macros from Parser.h to Parser.cpp + https://bugs.webkit.org/show_bug.cgi?id=99217 - 32-bit LLInt get_by_val does vector length checks incorrectly - https://bugs.webkit.org/show_bug.cgi?id=96893 - <rdar://problem/12311678> + Reviewed by Andreas Kling. - Reviewed by Mark Hahnenberg. + There are a bunch of macros in Parser.h that are only used in Parser.cpp. Move them to Parser.cpp + so they won't pollute the global namespace. + * parser/Parser.cpp: + * parser/Parser.h: + (JSC): - * llint/LowLevelInterpreter32_64.asm: +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> -2012-09-17 Filip Pizlo <fpizlo@apple.com> + Another build fix after r131213 - We don't have a bad enough time if an object's prototype chain crosses global objects - https://bugs.webkit.org/show_bug.cgi?id=96962 + Added some symbol magic to placate the linker on some platforms. - Reviewed by Geoffrey Garen. + * JavaScriptCore.order: - * runtime/JSGlobalObject.cpp: - (JSC): +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> -2012-09-17 Filip Pizlo <fpizlo@apple.com> + Build fix after r131213 - Unreviewed, fix a broken assertion in offlineasm. + Removed an unused variable that was making compilers unhappy. - * offlineasm/armv7.rb: - * offlineasm/backends.rb: + * heap/GCThread.cpp: + (JSC::GCThread::GCThread): + * heap/GCThread.h: + (GCThread): + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): -2012-09-16 Mark Hahnenberg <mhahnenberg@apple.com> +2012-10-09 Mark Hahnenberg <mhahnenberg@apple.com> - Delayed structure sweep can leak structures without bound - https://bugs.webkit.org/show_bug.cgi?id=96546 + Copying collection shouldn't require O(live bytes) memory overhead + https://bugs.webkit.org/show_bug.cgi?id=98792 - Reviewed by Gavin Barraclough. + Reviewed by Filip Pizlo. - This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only - allocators. We now have separate allocators for our three types of objects: those objects with no destructors, - those objects with destructors and with immortal structures, and those objects with destructors that don't have - immortal structures. All of the objects of the third type (destructors without immortal structures) now - inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores - the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction. + Currently our copying collection occurs simultaneously with the marking phase. We'd like + to be able to reuse CopiedBlocks as soon as they become fully evacuated, but this is not + currently possible because we don't know the liveness statistics of each old CopiedBlock + until marking/copying has already finished. Instead, we have to allocate additional memory + from the OS to use as our working set of CopiedBlocks while copying. We then return the + fully evacuated old CopiedBlocks back to the block allocator, thus giving our copying phase + an O(live bytes) overhead. + + To fix this, we should instead split the copying phase apart from the marking phase. This + way we have full liveness data for each CopiedBlock during the copying phase so that we + can reuse them the instant they become fully evacuated. With the additional liveness data + that each CopiedBlock accumulates, we can add some additional heuristics to the collector. + For example, we can calculate our global Heap fragmentation and only choose to do a copying + phase if that fragmentation exceeds some limit. As another example, we can skip copying + blocks that are already above a particular fragmentation limit, which allows older objects + to coalesce into blocks that are rarely copied. - * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor. - (JSC): - (JSC::JSCallbackConstructor::JSCallbackConstructor): - * API/JSCallbackConstructor.h: - (JSCallbackConstructor): - * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for - JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer. - (JSC): - (JSC::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add - the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides - to subclass this. We use this same technique for many other subclasses of JSGlobalObject. - (JSC::::createStructure): - * API/JSCallbackObject.h: - (JSCallbackObject): - (JSC): - * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead. - (OpaqueJSClass::prototype): - * API/JSObjectRef.cpp: Ditto. - (JSObjectMake): - (JSObjectGetPrivate): - (JSObjectSetPrivate): - (JSObjectGetPrivateProperty): - (JSObjectSetPrivateProperty): - (JSObjectDeletePrivateProperty): - * API/JSValueRef.cpp: Ditto. - (JSValueIsObjectOfClass): - * API/JSWeakObjectMapRefPrivate.cpp: Ditto. - * JSCTypedArrayStubs.h: - (JSC): * JavaScriptCore.xcodeproj/project.pbxproj: - * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG. - (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): - (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): + * heap/CopiedBlock.h: + (CopiedBlock): + (JSC::CopiedBlock::CopiedBlock): Added support for tracking live bytes in a CopiedBlock in a + thread-safe fashion. + (JSC::CopiedBlock::reportLiveBytes): Adds a number of live bytes to the block in a thread-safe + fashion using compare and swap. + (JSC): + (JSC::CopiedBlock::didSurviveGC): Called when a block survives a single GC without being + evacuated. This could be called for a couple reasons: (a) the block was pinned or (b) we + decided not to do any copying. A block can become pinned for a few reasons: (1) a pointer into + the block was found during the conservative scan. (2) the block was deemed full enough to + not warrant any copying. (3) The block is oversize and was found to be live. + (JSC::CopiedBlock::didEvacuateBytes): Called when some number of bytes are copied from this + block. If the number of live bytes ever hits zero, the block will return itself to the + BlockAllocator to be recycled. + (JSC::CopiedBlock::canBeRecycled): Indicates that a block has no live bytes and can be + immediately recycled. This is used for blocks that are found to have zero live bytes at the + beginning of the copying phase. + (JSC::CopiedBlock::shouldEvacuate): This function returns true if the current fragmentation + of the block is above our fragmentation threshold, and false otherwise. + (JSC::CopiedBlock::isPinned): Added an accessor for the pinned flag + (JSC::CopiedBlock::liveBytes): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::CopiedSpace): + (JSC::CopiedSpace::doneFillingBlock): Changed so that we can exchange our filled block for a + fresh block. This avoids the situation where a thread returns its borrowed block, it's the last + borrowed block, so CopiedSpace thinks that copying has completed, and it starts doing all of the + copying phase cleanup. In actuality, the thread wanted another block after returning the current + block. So we allow the thread to atomically exchange its block for another block. + (JSC::CopiedSpace::startedCopying): Added the calculation of global Heap fragmentation to + determine if the copying phase should commence. We include the MarkedSpace in our fragmentation + calculation by assuming that the MarkedSpace is 0% fragmented since we can reuse any currently + free memory in it (i.e. we ignore any internal fragmentation in the MarkedSpace). While we're + calculating the fragmentation of CopiedSpace, we also return any free blocks we find along the + way (meaning liveBytes() == 0). + (JSC): + (JSC::CopiedSpace::doneCopying): We still have to iterate over all the blocks, regardless of + whether the copying phase took place or not so that we can reset all of the live bytes counters + and un-pin any pinned blocks. + * heap/CopiedSpace.h: + (CopiedSpace): + (JSC::CopiedSpace::shouldDoCopyPhase): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::recycleEvacuatedBlock): This function is distinct from recycling a borrowed block + because a borrowed block hasn't been added to the CopiedSpace yet, but an evacuated block is still + currently in CopiedSpace, so we have to make sure we properly remove all traces of the block from + CopiedSpace before returning it to BlockAllocator. + (JSC::CopiedSpace::recycleBorrowedBlock): Renamed to indicate the distinction mentioned above. + * heap/CopyVisitor.cpp: Added. + (JSC): + (JSC::CopyVisitor::CopyVisitor): + (JSC::CopyVisitor::copyFromShared): Main function for any thread participating in the copying phase. + Grabs chunks of MarkedBlocks from the shared list and copies the backing store of anybody who needs + it until there are no more chunks to copy. + * heap/CopyVisitor.h: Added. + (JSC): + (CopyVisitor): + * heap/CopyVisitorInlineMethods.h: Added. + (JSC): + (GCCopyPhaseFunctor): + (JSC::GCCopyPhaseFunctor::GCCopyPhaseFunctor): + (JSC::GCCopyPhaseFunctor::operator()): + (JSC::CopyVisitor::checkIfShouldCopy): We don't have to check shouldEvacuate() because all of those + checks are done during the marking phase. + (JSC::CopyVisitor::allocateNewSpace): + (JSC::CopyVisitor::allocateNewSpaceSlow): + (JSC::CopyVisitor::startCopying): Initialization function for a thread that is about to start copying. + (JSC::CopyVisitor::doneCopying): + (JSC::CopyVisitor::didCopy): This callback is called by an object that has just successfully copied its + backing store. It indicates to the CopiedBlock that somebody has just finished evacuating some number of + bytes from it, and, if the CopiedBlock now has no more live bytes, can be recycled immediately. + * heap/GCThread.cpp: Added. + (JSC): + (JSC::GCThread::GCThread): This is a new class that encapsulates a single thread responsible for participating + in a specific set of GC phases. Currently, that set of phases includes Mark, Copy, and Exit. Each thread + monitors a shared variable in its associated GCThreadSharedData. The main thread updates this m_currentPhase + variable as collection progresses through the various phases. Parallel marking still works exactly like it + has. In other words, the "run loop" for each of the GC threads sits above any individual phase, thus keeping + the separate phases of the collector orthogonal. + (JSC::GCThread::threadID): + (JSC::GCThread::initializeThreadID): + (JSC::GCThread::slotVisitor): + (JSC::GCThread::copyVisitor): + (JSC::GCThread::waitForNextPhase): + (JSC::GCThread::gcThreadMain): + (JSC::GCThread::gcThreadStartFunc): + * heap/GCThread.h: Added. + (JSC): + (GCThread): + * heap/GCThreadSharedData.cpp: The GCThreadSharedData now has a list of GCThread objects rather than raw + ThreadIdentifiers. + (JSC::GCThreadSharedData::resetChildren): + (JSC::GCThreadSharedData::childVisitCount): + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::~GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + (JSC::GCThreadSharedData::didStartMarking): Callback to let the GCThreadSharedData know that marking has + started and updates the m_currentPhase variable and notifies the GCThreads accordingly. + (JSC::GCThreadSharedData::didFinishMarking): Ditto for finishing marking. + (JSC::GCThreadSharedData::didStartCopying): Ditto for starting the copying phase. + (JSC::GCThreadSharedData::didFinishCopying): Ditto for finishing copying. + * heap/GCThreadSharedData.h: + (JSC): + (GCThreadSharedData): + (JSC::GCThreadSharedData::getNextBlocksToCopy): Atomically gets the next chunk of work for a copying thread. * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC::Heap::markRoots): (JSC): - * heap/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function - since it's always safe to sweep Structures now. - (JSC::Heap::allocatorForObjectWithNormalDestructor): - (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): + (JSC::Heap::copyBackingStores): Responsible for setting up the copying phase, notifying the copying threads, + and doing any copying work if necessary. + (JSC::Heap::collect): + * heap/Heap.h: (Heap): - (JSC::Heap::allocateWithNormalDestructor): (JSC): - (JSC::Heap::allocateWithImmortalStructureDestructor): - * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the - IncrementalSweeper since it's always safe to sweep Structures now. + (JSC::CopyFunctor::CopyFunctor): + (CopyFunctor): + (JSC::CopyFunctor::operator()): + * heap/IncrementalSweeper.cpp: Changed the incremental sweeper to have a reference to the list of MarkedBlocks + that need sweeping, since this now resides in the Heap so that it can be easily shared by the GCThreads. (JSC::IncrementalSweeper::IncrementalSweeper): - (JSC::IncrementalSweeper::sweepNextBlock): (JSC::IncrementalSweeper::startSweeping): - (JSC::IncrementalSweeper::willFinishSweeping): - (JSC): * heap/IncrementalSweeper.h: - (IncrementalSweeper): - * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add - tracking of the specific destructor type of allocator. - (JSC::MarkedAllocator::tryAllocateHelper): - (JSC::MarkedAllocator::allocateBlock): - * heap/MarkedAllocator.h: - (JSC::MarkedAllocator::destructorType): - (MarkedAllocator): - (JSC::MarkedAllocator::MarkedAllocator): - (JSC::MarkedAllocator::init): - * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. - We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls. - (JSC::MarkedBlock::create): - (JSC::MarkedBlock::MarkedBlock): - (JSC): - (JSC::MarkedBlock::specializedSweep): - (JSC::MarkedBlock::sweep): - (JSC::MarkedBlock::sweepHelper): - * heap/MarkedBlock.h: - (JSC): - (JSC::MarkedBlock::allocator): - (JSC::MarkedBlock::destructorType): - * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace. - (JSC::MarkedSpace::MarkedSpace): - (JSC::MarkedSpace::resetAllocators): - (JSC::MarkedSpace::canonicalizeCellLivenessData): - (JSC::MarkedSpace::isPagedOut): - (JSC::MarkedSpace::freeBlock): - * heap/MarkedSpace.h: - (MarkedSpace): - (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): - (JSC::MarkedSpace::normalDestructorAllocatorFor): - (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): - (JSC::MarkedSpace::allocateWithNormalDestructor): - (JSC::MarkedSpace::forEachBlock): - * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function. - * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT. - * jit/JITInlineMethods.h: - (JSC::JIT::emitAllocateBasicJSObject): - (JSC::JIT::emitAllocateJSFinalObject): - (JSC::JIT::emitAllocateJSArray): - * jsc.cpp: - (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from - JSDestructibleObject. - * runtime/Arguments.cpp: Inherit from JSDestructibleObject. - (JSC): - * runtime/Arguments.h: - (Arguments): - (JSC::Arguments::Arguments): - * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor. - (JSC): - * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures. - (JSC): - * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject. - (JSC): - (JSC::InternalFunction::InternalFunction): - * runtime/InternalFunction.h: - (InternalFunction): - * runtime/JSCell.h: Added the NEEDS_DESTRUCTOR macro to make it easier for classes to indicate that instead of being - allocated in a destructor MarkedAllocator that they will handle their destruction themselves through the - use of a finalizer. - (JSC): - (HasImmortalStructure): New template to help us determine at compile-time if a particular class - should be allocated in the immortal structure MarkedAllocator. The default value is false. In order - to be allocated in the immortal structure allocator, classes must specialize this template. Also added - a macro to make it easier for classes to specialize the template. - (JSC::allocateCell): Use the appropriate allocator depending on the destructor type. - * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be - accessed safely when the object is being destroyed. - (JSC): - (JSDestructibleObject): - (JSC::JSDestructibleObject::classInfo): - (JSC::JSDestructibleObject::JSDestructibleObject): - (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe. - * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all - of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well. - (JSC::JSGlobalObject::reset): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one - for the m_rareData field when it's created. - (JSC::JSGlobalObject::create): (JSC): - * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject. - (JSGlobalThis): - (JSC::JSGlobalThis::JSGlobalThis): - * runtime/JSPropertyNameIterator.h: Has an immortal Structure. - (JSC): - * runtime/JSScope.cpp: - (JSC): - * runtime/JSString.h: Has an immortal Structure. - (JSC): - * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject. - (JSWrapperObject): - (JSC::JSWrapperObject::JSWrapperObject): - * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff. - (JSC): - * runtime/NameInstance.h: Inherit from JSDestructibleObject. - (NameInstance): - * runtime/RegExp.h: Has immortal Structure. - (JSC): - * runtime/RegExpObject.cpp: Inheritance cleanup. - (JSC): - * runtime/SparseArrayValueMap.h: Has immortal Structure. - (JSC): - * runtime/Structure.h: Has immortal Structure. + (IncrementalSweeper): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::setup): + (JSC::SlotVisitor::drainFromShared): We no longer do any copying-related work here. (JSC): - * runtime/StructureChain.h: Ditto. + * heap/SlotVisitor.h: + (SlotVisitor): + * heap/SlotVisitorInlineMethods.h: (JSC): - * runtime/SymbolTable.h: Ditto. - (SharedSymbolTable): + (JSC::SlotVisitor::copyLater): Notifies the CopiedBlock that there are some live bytes that may need + to be copied. + * runtime/Butterfly.h: (JSC): - -2012-09-17 Filip Pizlo <fpizlo@apple.com> - - If a prototype has indexed setters and its instances have indexed storage, then all put_by_val's should have a bad time - https://bugs.webkit.org/show_bug.cgi?id=96596 - - Reviewed by Gavin Barraclough. - - Added comprehensive support for accessors and read-only indexed properties on the - prototype chain. This is done without any performance regression on benchmarks that - we're aware of, by having the entire VM's strategy with respect to arrays tilted - heavily in favor of: - - - The prototype chain of JSArrays never having any accessors or read-only indexed - properties. If that changes, you're going to have a bad time. - - - Prototypes of non-JSArray objects either having no indexed accessors or read-only - indexed properties, or, having those indexed accessor thingies inserted before - any instance object (i.e. object with that prototype as its prototype) is created. - If you add indexed accessors or read-only indexed properties to an object that is - already used as a prototype, you're going to have a bad time. - - See below for the exact definition of having a bad time. - - Put another way, "fair" uses of indexed accessors and read-only indexed properties - are: - - - Put indexed accessors and read-only indexed properties on an object that is never - used as a prototype. This will slow down accesses to that object, but will not - have any effect on any other object. - - - Put those indexed accessor thingies on an object before it is used as a prototype - and then start instantiating objects that claim that object as their prototype. - This will slightly slow down indexed stores to the instance objects, and greatly - slow down all indexed accesses to the prototype, but will have no other effect. - - In short, "fair" uses only affect the object itself and any instance objects. But - if you start using indexed accessors in more eclectic ways, you're going to have - a bad time. - - Specifically, if an object that may be used as a prototype has an indexed accessor - added, the VM performs a whole-heap scan to find all objects that belong to the - same global object as the prototype you modified. If any of those objects has - indexed storage, their indexed storage is put into slow-put mode, just as if their - prototype chain had indexed accessors. This will happen even for objects that do - not currently have indexed accessors in their prototype chain. As well, all JSArray - allocations are caused to create arrays with slow-put storage, and all future - allocations of indexed storage for non-JSArray objects are also flipped to slow-put - mode. Note there are two aspects to having a bad time: (i) the whole-heap scan and - (ii) the poisoning of all indexed storage in the entire global object. (i) is - necessary for correctness. If we detect that an object that may be used as a - prototype has had an indexed accessor or indexed read-only property inserted into - it, then we need to ensure that henceforth all instances of that object inspect - the prototype chain whenever an indexed hole is stored to. But by default, indexed - stores do no such checking because doing so would be unnecessarily slow. So, we must - find all instances of the affected object and flip them into a different array - storage mode that omits all hole optimizations. Since prototypes never keep a list - of instance objects, the only way to find those objects is a whole-heap scan. But - (i) alone would be a potential disaster, if a program frequently allocated an - object without indexed accessors, then allocated a bunch of objects that used that - one as their prototype, and then added indexed accessors to the prototype. So, to - prevent massive heap scan storms in such awkward programs, having a bad time also - implies (ii): henceforth *all* objects belonging to that global object will use - slow put indexed storage, so that we don't ever have to scan the heap again. Note - that here we are using the global object as just an approximation of a program - module; it may be worth investigating in the future if other approximations can be - used instead. - - * bytecode/ArrayProfile.h: + (Butterfly): + * runtime/ButterflyInlineMethods.h: + (JSC::Butterfly::createUninitializedDuringCollection): Uses the new CopyVisitor. + * runtime/ClassInfo.h: + (MethodTable): Added new "virtual" function copyBackingStore to method table. (JSC): - (JSC::arrayModeFromStructure): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::fromObserved): - (JSC::DFG::modeAlreadyChecked): - (JSC::DFG::modeToString): - * dfg/DFGArrayMode.h: - (DFG): - (JSC::DFG::isSlowPutAccess): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArray): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JIT.h: - * jit/JITInlineMethods.h: - (JSC::JIT::emitAllocateJSArray): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_new_array): - * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::finishCreation): - (JSC::arrayProtoFuncSort): - * runtime/IndexingType.h: + * runtime/JSCell.cpp: + (JSC::JSCell::copyBackingStore): Default implementation that does nothing. (JSC): - (JSC::hasIndexedProperties): - (JSC::hasIndexingHeader): - (JSC::hasArrayStorage): - (JSC::shouldUseSlowPut): - * runtime/JSArray.cpp: - (JSC::JSArray::pop): - (JSC::JSArray::push): - (JSC::JSArray::fillArgList): - (JSC::JSArray::copyToArguments): - * runtime/JSArray.h: - (JSC::JSArray::createStructure): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - (JSC::JSGlobalObject::reset): + * runtime/JSCell.h: (JSC): - (JSC::JSGlobalObject::haveABadTime): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::addressOfArrayStructure): - (JSC::JSGlobalObject::havingABadTimeWatchpoint): - (JSC::JSGlobalObject::isHavingABadTime): + (JSCell): * runtime/JSObject.cpp: - (JSC::JSObject::visitButterfly): - (JSC::JSObject::getOwnPropertySlotByIndex): - (JSC::JSObject::put): - (JSC::JSObject::putByIndex): - (JSC::JSObject::enterDictionaryIndexingMode): - (JSC::JSObject::notifyPresenceOfIndexedAccessors): + (JSC::JSObject::copyButterfly): Does the actual copying of the butterfly. (JSC): - (JSC::JSObject::createArrayStorage): - (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): - (JSC::JSObject::switchToSlowPutArrayStorage): - (JSC::JSObject::setPrototype): - (JSC::JSObject::resetInheritorID): - (JSC::JSObject::inheritorID): - (JSC::JSObject::allowsAccessFrom): - (JSC::JSObject::deletePropertyByIndex): - (JSC::JSObject::getOwnPropertyNames): - (JSC::JSObject::unwrappedGlobalObject): - (JSC::JSObject::notifyUsedAsPrototype): - (JSC::JSObject::createInheritorID): - (JSC::JSObject::defineOwnIndexedProperty): - (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): - (JSC::JSObject::attemptToInterceptPutByIndexOnHole): - (JSC::JSObject::putByIndexBeyondVectorLength): - (JSC::JSObject::putDirectIndexBeyondVectorLength): - (JSC::JSObject::getNewVectorLength): - (JSC::JSObject::getOwnPropertyDescriptor): + (JSC::JSObject::visitButterfly): Calls copyLater for the butterfly. + (JSC::JSObject::copyBackingStore): * runtime/JSObject.h: - (JSC::JSObject::mayBeUsedAsPrototype): (JSObject): - (JSC::JSObject::mayInterceptIndexedAccesses): - (JSC::JSObject::getArrayLength): - (JSC::JSObject::getVectorLength): - (JSC::JSObject::canGetIndexQuickly): - (JSC::JSObject::getIndexQuickly): - (JSC::JSObject::canSetIndexQuickly): - (JSC::JSObject::setIndexQuickly): - (JSC::JSObject::initializeIndex): - (JSC::JSObject::completeInitialization): - (JSC::JSObject::inSparseIndexingMode): - (JSC::JSObject::arrayStorage): - (JSC::JSObject::arrayStorageOrNull): - (JSC::JSObject::ensureArrayStorage): - (JSC): - (JSC::JSValue::putByIndex): - * runtime/JSValue.cpp: - (JSC::JSValue::putToPrimitive): - (JSC::JSValue::putToPrimitiveByIndex): - (JSC): - * runtime/JSValue.h: - (JSValue): - * runtime/ObjectPrototype.cpp: - (JSC::ObjectPrototype::finishCreation): - * runtime/SparseArrayValueMap.cpp: - (JSC::SparseArrayValueMap::putEntry): - (JSC::SparseArrayEntry::put): - (JSC): - * runtime/SparseArrayValueMap.h: - (JSC): - (SparseArrayEntry): - * runtime/Structure.cpp: - (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses): + (JSC::JSCell::methodTable): + (JSC::JSCell::inherits): + * runtime/Options.h: Added two new constants, minHeapUtilization and minCopiedBlockUtilization, + to govern the amount of fragmentation we allow before doing copying. (JSC): - (JSC::Structure::suggestedIndexingTransition): - * runtime/Structure.h: - (Structure): - (JSC::Structure::mayInterceptIndexedAccesses): - * runtime/StructureTransitionTable.h: - (JSC::newIndexingType): -2012-09-17 Filip Pizlo <fpizlo@apple.com> +2012-10-12 Filip Pizlo <fpizlo@apple.com> - Array profiling has convergence issues - https://bugs.webkit.org/show_bug.cgi?id=96891 + DFG array allocation calls should not return an encoded JSValue + https://bugs.webkit.org/show_bug.cgi?id=99196 - Reviewed by Gavin Barraclough. + Reviewed by Mark Hahnenberg. - Now each array profiling site merges in the indexing type it observed into - the m_observedArrayModes bitset. The ArrayProfile also uses this to detect - cases where the structure must have gone polymorphic (if the bitset is - polymorphic then the structure must be). This achieves something like the - best of both worlds: on the one hand, we get a probabilistic structure that - we can use to optimize the monomorphic structure case, but on the other hand, - we get an accurate view of the set of types that were encountered. + The array allocation operations now return a pointer instead. This makes it + easier to share code between 32-bit and 64-bit. - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::or32): - (MacroAssemblerARMv7): - * assembler/MacroAssemblerX86.h: - (JSC::MacroAssemblerX86::or32): - (MacroAssemblerX86): - * assembler/MacroAssemblerX86_64.h: - (JSC::MacroAssemblerX86_64::or32): - (MacroAssemblerX86_64): - * assembler/X86Assembler.h: - (X86Assembler): - (JSC::X86Assembler::orl_rm): - * bytecode/ArrayProfile.cpp: - (JSC::ArrayProfile::computeUpdatedPrediction): - * bytecode/ArrayProfile.h: - (JSC::ArrayProfile::addressOfArrayModes): - (JSC::ArrayProfile::structureIsPolymorphic): - * jit/JIT.h: - (JIT): - * jit/JITInlineMethods.h: - (JSC): - (JSC::JIT::emitArrayProfilingSite): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-17 Mark Lam <mark.lam@apple.com> + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): - Not reviewed. Added svn:eol-style native to unbreak some build bots. - https://bugs.webkit.org/show_bug.cgi?id=96175. +2012-10-01 Jer Noble <jer.noble@apple.com> - * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added property svn:eol-style. - * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added property svn:eol-style. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added property svn:eol-style. + Enable ENCRYPTED_MEDIA support on Mac. + https://bugs.webkit.org/show_bug.cgi?id=98044 -2012-09-16 Mark Lam <mark.lam@apple.com> + Reviewed by Anders Carlsson. - Added MSVC project changes to enable building the llint. - https://bugs.webkit.org/show_bug.cgi?id=96175. + Enable the ENCRYPTED_MEDIA flag. - Reviewed by Geoff Garen. + * Configurations/FeatureDefines.xcconfig: - This only adds the ability to build the llint, but currently, only the - C++ backend is supported. By default, the Windows port will remain - running with the baseline JIT. The llint will not be enabled. +2012-10-12 Filip Pizlo <fpizlo@apple.com> - * JavaScriptCore.vcproj/JavaScriptCore.sln: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.vcproj/LLIntAssembly: Added. - * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Added. - * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added. - * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added. - * JavaScriptCore.vcproj/LLIntDesiredOffsets: Added. - * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added. - * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added. - * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added. - * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added. - -2012-09-16 Filip Pizlo <fpizlo@apple.com> - - JSObject.cpp and JSArray.cpp have inconsistent tests for the invalid array index case - https://bugs.webkit.org/show_bug.cgi?id=96878 + Unreviewed. It should be possible to build JSC on ARMv7. - Reviewed by Sam Weinig. + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::patchableBranchPtr): - Removed the uses of UNLIKELY() because I don't believe they are buying us anything, - since we're already on the slow path. Also found other places where we're testing for - the invalid array index case using unusual predicates rather than just using - MAX_ARRAY_INDEX. With this change, I believe that all of our tests for invalid - array indices (i.e. indices that should be treated as non-indexed properties) - uniformly use MAX_ARRAY_INDEX and PropertyName::NotAnIndex. +2012-10-11 Mark Hahnenberg <mhahnenberg@apple.com> - * runtime/JSArray.cpp: - (JSC::JSArray::push): - * runtime/JSObject.cpp: - (JSC::JSObject::putByIndex): - (JSC::JSObject::defineOwnIndexedProperty): + BlockAllocator should use regions as its VM allocation abstraction + https://bugs.webkit.org/show_bug.cgi?id=99107 -2012-09-15 Filip Pizlo <fpizlo@apple.com> + Reviewed by Geoffrey Garen. - Following the Butterfly refactoring, the comment for lastArraySize was not updated - https://bugs.webkit.org/show_bug.cgi?id=96877 + Currently the BlockAllocator allocates a single block at a time directly from the OS. Our block + allocations are on the large-ish side (64 KB) to amortize across many allocations the expense of + mapping new virtual memory from the OS. These large blocks are then shared between the MarkedSpace + and the CopiedSpace. This design makes it difficult to vary the size of the blocks in different + parts of the Heap while still allowing us to amortize the VM allocation costs. - Reviewed by Sam Weinig. + We should redesign the BlockAllocator so that it has a layer of indirection between blocks that are + used by the allocator/collector and our primary unit of VM allocation from the OS. In particular, + the BlockAllocator should allocate Regions of virtual memory from the OS, which are then subdivided + into one or more Blocks to be used in our custom allocators. This design has the following nice properties: - * runtime/JSObject.cpp: - (JSC): + 1) We can remove the knowledge of PageAllocationAligned from HeapBlocks. Each HeapBlock will now + only know what Region it belongs to. The Region maintains all the metadata for how to allocate + and deallocate virtual memory from the OS. -2012-09-15 Mark Lam <mark.lam@apple.com> + 2) We can easily allocate in larger chunks than we need to satisfy a particular request for a Block. + We can then continue to amortize our VM allocation costs while allowing for smaller block sizes, + which should increase locality in the mutator when allocating, lazy sweeping, etc. - Fixed JSLock to use the platform abstraction for Mutex instead of - depending on pthreads. - https://bugs.webkit.org/show_bug.cgi?id=96858. + 3) By encapsulating the logic of where our memory comes from inside of the Region class, we can more + easily transition over to allocating VM from a specific range of pre-reserved address space. This + will be a necessary step along the way to 32-bit pointers. - Reviewed by Filip Pizlo. + This particular patch will not change the size of MarkedBlocks or CopiedBlocks, nor will it change how + much VM we allocate per failed Block request. It only sets up the data structures that we need to make + these changes in future patches. - This fixes a synchronization problem on the Windows port and makes - it more reliable when running the layout tests. + Most of the changes in this patch relate to the addition of the Region class to be used by the + BlockAllocator and the threading of changes made to BlockAllocator's interface through to the call sites. - * runtime/InitializeThreading.cpp: - (JSC::initializeThreadingOnce): - * runtime/JSLock.cpp: + * heap/BlockAllocator.cpp: The BlockAllocator now has three lists that track the three disjoint sets of + Regions that it cares about: empty regions, partially full regions, and completely full regions. + Empty regions have no blocks currently in use and can be freed immediately if the freeing thread + determines they should be. Partial regions have some blocks used, but aren't completely in use yet. + These regions are preferred for recycling before empty regions to mitigate fragmentation within regions. + Completely full regions are no longer able to be used for allocations. Regions move between these + three lists as they are created and their constituent blocks are allocated and deallocated. + (JSC::BlockAllocator::BlockAllocator): + (JSC::BlockAllocator::~BlockAllocator): + (JSC::BlockAllocator::releaseFreeRegions): + (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): + (JSC::BlockAllocator::waitForRelativeTime): + (JSC::BlockAllocator::blockFreeingThreadMain): + * heap/BlockAllocator.h: (JSC): - (JSC::GlobalJSLock::GlobalJSLock): - (JSC::GlobalJSLock::~GlobalJSLock): - (JSC::GlobalJSLock::initialize): - * runtime/JSLock.h: - (GlobalJSLock): - (JSLock): + (DeadBlock): + (JSC::DeadBlock::DeadBlock): + (Region): + (JSC::Region::blockSize): + (JSC::Region::isFull): + (JSC::Region::isEmpty): + (JSC::Region::create): This function is responsible for doing the actual VM allocation. This should be the + only function in the entire JSC object runtime that calls out the OS for virtual memory allocation. + (JSC::Region::Region): + (JSC::Region::~Region): + (JSC::Region::allocate): + (JSC::Region::deallocate): + (BlockAllocator): + (JSC::BlockAllocator::tryAllocateFromRegion): Helper function that encapsulates checking a particular list + of regions for a free block. + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::allocateCustomSize): This function is responsible for allocating one-off custom size + regions for use in oversize allocations in both the MarkedSpace and the CopiedSpace. These regions are not + tracked by the BlockAllocator. The only pointer to them is in the HeapBlock that is returned. These regions + contain exactly one block. + (JSC::BlockAllocator::deallocate): + (JSC::BlockAllocator::deallocateCustomSize): This function is responsible for deallocating one-off custom size + regions. The regions are deallocated back to the OS eagerly. + * heap/CopiedBlock.h: Re-worked CopiedBlocks to use Regions instead of PageAllocationAligned. + (CopiedBlock): + (JSC::CopiedBlock::createNoZeroFill): + (JSC::CopiedBlock::create): + (JSC::CopiedBlock::CopiedBlock): + (JSC::CopiedBlock::payloadEnd): + (JSC::CopiedBlock::capacity): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::~CopiedSpace): + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocateOversize): + (JSC::CopiedSpace::doneCopying): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::allocateBlockForCopyingPhase): + (JSC::CopiedSpace::allocateBlock): + * heap/HeapBlock.h: + (JSC::HeapBlock::destroy): + (JSC::HeapBlock::HeapBlock): + (JSC::HeapBlock::region): + (HeapBlock): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::capacity): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::freeBlock): -2012-09-15 Filip Pizlo <fpizlo@apple.com> +2012-10-11 Filip Pizlo <fpizlo@apple.com> - Structure check hoisting fails to consider the possibility of conflicting checks on the source of the first assignment to the hoisted variable - https://bugs.webkit.org/show_bug.cgi?id=96872 + UInt32ToNumber and OSR exit should be aware of copy propagation and correctly recover both versions of a variable that was subject to a UInt32ToNumber cast + https://bugs.webkit.org/show_bug.cgi?id=99100 + <rdar://problem/12480955> - Reviewed by Oliver Hunt. + Reviewed by Michael Saboff and Mark Hahnenberg. - This does a few related things: - - - It turns off the use of ForceOSRExit for sure-to-fail CheckStructures, because - I noticed that this would sometimes happen for a ForwardCheckStructure. The - problem is that ForceOSRExit exits backwards, not forwards. Since the code that - led to those ForceOSRExit's being inserted was written out of paranoia rather - than need, I removed it. Specifically, I removed the m_isValid = false code - for CheckStructure/StructureTransitionWatchpoint in AbstractState. - - - If a structure check causes a structure set to go empty, we don't want a - PutStructure to revive the set. It should instead be smart enough to realize - that an empty set implies that the code can't execute. This was the only "bug" - that the use of m_isValid = false was preventing. - - - Finally, the main change: structure check hoisting looks at the source of the - SetLocals on structure-check-hoistable variables and ensures that the source - is not checked with a conflicting structure. This is O(n^2) but it does not - show up at all in performance tests. - - The first two parts of this change were auxiliary bugs that were revealed by - the structure check hoister doing bad things. + Fixed by forcing UInt32ToNumber to use a different register. This "undoes" the copy propagation that we + would have been doing, since it has no performance effect in this case and has the benefit of making the + OSR exit compiler a lot simpler. - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::initialize): - (JSC::DFG::AbstractState::execute): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): -2012-09-14 Filip Pizlo <fpizlo@apple.com> +2012-10-11 Geoffrey Garen <ggaren@apple.com> - All of the things in SparseArrayValueMap should be out-of-line - https://bugs.webkit.org/show_bug.cgi?id=96854 + Removed some more static assumptions about inline object capacity + https://bugs.webkit.org/show_bug.cgi?id=98603 - Reviewed by Andy Estes. + Reviewed by Filip Pizlo. - Those inline methods were buying us nothing. + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Use JSObject::allocationSize() + for a little more flexibility. We still pass it a constant inline capacity + because the JIT doesn't have a strategy for selecting a size class based + on non-constant capacity yet. "INLINE_STORAGE_CAPACITY" is a marker for + code that makes static assumptions about object size. - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * runtime/JSArray.cpp: - * runtime/JSGlobalData.cpp: - * runtime/JSObject.cpp: - * runtime/RegExpMatchesArray.cpp: - * runtime/SparseArrayValueMap.cpp: - (JSC::SparseArrayValueMap::SparseArrayValueMap): - (JSC): - (JSC::SparseArrayValueMap::~SparseArrayValueMap): - (JSC::SparseArrayValueMap::finishCreation): - (JSC::SparseArrayValueMap::create): - (JSC::SparseArrayValueMap::destroy): - (JSC::SparseArrayValueMap::createStructure): - (JSC::SparseArrayValueMap::add): - (JSC::SparseArrayValueMap::putEntry): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayEntry::get): - (JSC::SparseArrayEntry::getNonSparseMode): - (JSC::SparseArrayValueMap::visitChildren): - * runtime/SparseArrayValueMapInlineMethods.h: Removed. + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Ditto for the rest of our many execution engines. -2012-09-14 Mike West <mkwst@chromium.org> + * runtime/JSObject.h: + (JSC::JSObject::allocationSize): + (JSC::JSFinalObject::finishCreation): + (JSC::JSFinalObject::create): New helper function for computing object + size dynamically, since we plan to have objects of different sizes. - JSC should throw a more descriptive exception when blocking 'eval' via CSP. - https://bugs.webkit.org/show_bug.cgi?id=94331 + (JSC::JSFinalObject::JSFinalObject): Note that our m_inlineStorage used + to auto-generate an implicit C++ constructor with default null initialization. + This memory is not observed in its uninitialized state, and our LLInt and + JIT allocators do not initialize it, so I did not add any explicit code + to do so, now that the implicit code is gone. - Reviewed by Geoffrey Garen. + (JSC::JSObject::offsetOfInlineStorage): Changed the math here to match + inlineStorageUnsafe(), since we can rely on an explicit data member anymore. - Unless explicitly whitelisted, the 'script-src' Content Security Policy - directive blocks 'eval' and 'eval'-like constructs such as - 'new Function()'. When 'eval' is encountered in code, an 'EvalError' is - thrown, but the associated message is poor: "Eval is disabled" doesn't - give developers enough information about why their code isn't behaving - as expected. - - This patch adds an 'errorMessage' parameter to the JavaScriptCore method - used to disable 'eval'; ContentSecurityPolicy has the opportunity to - pass in a more detailed and descriptive error that contains more context - for the developer. - - * runtime/Executable.cpp: - (JSC::EvalExecutable::compileInternal): - Drop the hard-coded "Eval is disabled" error message in favor of - reading the error message off the global object. - * runtime/FunctionConstructor.cpp: - (JSC::FunctionConstructor::getCallData): - Drop the hard-coded "Function constructor is disabled" error message - in favor of reading the error message off the global object. - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::evalEnabled): - Making this accessor method const. - (JSC::JSGlobalObject::evalDisabledErrorMessage): - Accessor for the error message set via 'setEvalDisabled'. - (JSC::JSGlobalObject::setEvalEnabled): - Adding an 'errorMessage' parameter which is stored on the global - object, and used when exceptions are thrown. +2012-10-11 Geoffrey Garen <ggaren@apple.com> -2012-09-14 Filip Pizlo <fpizlo@apple.com> + Enable RUNTIME_HEURISTICS all the time, for easier testing + https://bugs.webkit.org/show_bug.cgi?id=99090 - bbc homepage crashes immediately - https://bugs.webkit.org/show_bug.cgi?id=96812 - <rdar://problem/12081386> + Reviewed by Filip Pizlo. - Reviewed by Oliver Hunt. + I find myself using this a lot, and there doesn't seem to be an obvious + reason to compile it out, since it only runs once at startup. - If you use the old storage pointer to write to space you thought was newly allocated, - you're going to have a bad time. + * runtime/Options.cpp: + (JSC::overrideOptionWithHeuristic): + (JSC::Options::initialize): + * runtime/Options.h: Removed the #ifdef. - * runtime/JSArray.cpp: - (JSC::JSArray::unshiftCount): +2012-10-11 Geoffrey Garen <ggaren@apple.com> -2012-09-14 Adam Barth <abarth@webkit.org> + Removed ASSERT_CLASS_FITS_IN_CELL + https://bugs.webkit.org/show_bug.cgi?id=97634 - Remove webkitPostMessage - https://bugs.webkit.org/show_bug.cgi?id=96577 + Reviewed by Mark Hahnenberg. - Reviewed by Ojan Vafai. + Our collector now supports arbitrarily sized objects, so the ASSERT is not needed. - Add ENABLE_LEGACY_VENDOR_PREFIXES flag. + * API/JSCallbackFunction.cpp: + * API/JSCallbackObject.cpp: + * heap/MarkedSpace.h: + * jsc.cpp: + * runtime/Arguments.cpp: + * runtime/ArrayConstructor.cpp: + * runtime/ArrayPrototype.cpp: + * runtime/BooleanConstructor.cpp: + * runtime/BooleanObject.cpp: + * runtime/BooleanPrototype.cpp: + * runtime/DateConstructor.cpp: + * runtime/DatePrototype.cpp: + * runtime/Error.cpp: + * runtime/ErrorConstructor.cpp: + * runtime/ErrorPrototype.cpp: + * runtime/FunctionConstructor.cpp: + * runtime/FunctionPrototype.cpp: + * runtime/InternalFunction.cpp: + * runtime/JSActivation.cpp: + * runtime/JSArray.cpp: + * runtime/JSBoundFunction.cpp: + * runtime/JSFunction.cpp: + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalThis.cpp: + * runtime/JSNameScope.cpp: + * runtime/JSNotAnObject.cpp: + * runtime/JSONObject.cpp: + * runtime/JSObject.cpp: + * runtime/JSPropertyNameIterator.cpp: + * runtime/JSScope.cpp: + * runtime/JSWithScope.cpp: + * runtime/JSWrapperObject.cpp: + * runtime/MathObject.cpp: + * runtime/NameConstructor.cpp: + * runtime/NamePrototype.cpp: + * runtime/NativeErrorConstructor.cpp: + * runtime/NativeErrorPrototype.cpp: + * runtime/NumberConstructor.cpp: + * runtime/NumberObject.cpp: + * runtime/NumberPrototype.cpp: + * runtime/ObjectConstructor.cpp: + * runtime/ObjectPrototype.cpp: + * runtime/RegExpConstructor.cpp: + * runtime/RegExpMatchesArray.cpp: + * runtime/RegExpObject.cpp: + * runtime/RegExpPrototype.cpp: + * runtime/StringConstructor.cpp: + * runtime/StringObject.cpp: + * runtime/StringPrototype.cpp: + * testRegExp.cpp: Removed the ASSERT. - * Configurations/FeatureDefines.xcconfig: +2012-10-11 Filip Pizlo <fpizlo@apple.com> -2012-09-14 Tor Arne Vestbø <tor.arne.vestbo@nokia.com> + DFG should inline code blocks that use new_array_buffer + https://bugs.webkit.org/show_bug.cgi?id=98996 - [Qt] Make force_static_libs_as_shared work on Mac OS + Reviewed by Geoffrey Garen. - We had to move a few LIBS += around that were in the wrong place, - and not caught when everything was just linked into the final - QtWebKit library. + This adds plumbing to drop in constant buffers from the inlinees to the inliner. + It's smart about not duplicating buffers needlessly but doesn't try to completely + hash-cons them, either. - Reviewed by Simon Hausmann. + * bytecode/CodeBlock.h: + (JSC::CodeBlock::numberOfConstantBuffers): + (JSC::CodeBlock::addConstantBuffer): + (JSC::CodeBlock::constantBufferAsVector): + (JSC::CodeBlock::constantBuffer): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ConstantBufferKey): + (JSC::DFG::ConstantBufferKey::ConstantBufferKey): + (JSC::DFG::ConstantBufferKey::operator==): + (JSC::DFG::ConstantBufferKey::hash): + (JSC::DFG::ConstantBufferKey::isHashTableDeletedValue): + (JSC::DFG::ConstantBufferKey::codeBlock): + (JSC::DFG::ConstantBufferKey::index): + (DFG): + (JSC::DFG::ConstantBufferKeyHash::hash): + (JSC::DFG::ConstantBufferKeyHash::equal): + (ConstantBufferKeyHash): + (WTF): + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::parseBlock): + (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): - * jsc.pro: No need for AppKit, we get it from WTF.pri +2012-10-10 Zoltan Horvath <zoltan@webkit.org> -2012-09-14 Kevin Funk <kevin.funk@kdab.com> + Pageload tests should measure memory usage + https://bugs.webkit.org/show_bug.cgi?id=93958 - Fix interpreter build - https://bugs.webkit.org/show_bug.cgi?id=96617 + Reviewed by Ryosuke Niwa. - Reviewed by Simon Hausmann. + Add JS Heap and Heap memory measurement to PageLoad tests. - Make compile. + * heap/HeapStatistics.cpp: + (JSC::HeapStatistics::usedJSHeap): Add new private function to expose the used JS Heap size. + (JSC): + * heap/HeapStatistics.h: + (HeapStatistics): Add new private function to expose the used JS Heap size. - * interpreter/Interpreter.cpp: +2012-10-10 Balazs Kilvady <kilvadyb@homejinni.com> -2012-09-14 Parth Patel <parpatel@rim.com> + RegisterFile to JSStack rename fix for a struct member. - [BlackBerry] Switching from Slogger to Slogger2 requires changes in CMakeList of - webkit in order to include libraries of slog2 - https://bugs.webkit.org/show_bug.cgi?id=96391 + Compilation problem in debug build on MIPS + https://bugs.webkit.org/show_bug.cgi?id=98808 - Reviewed by Yong Li. + Reviewed by Alexey Proskuryakov. - Changes in Cmake files of JavaScriptCore of webkit to include slog2 libs in build - files of webkit in response to switching from Slogger to Slogger2. + In ASSERT conditions structure field name "registerFile" was replaced + with type name "JSStack" and it should be "stack". - * shell/PlatformBlackBerry.cmake: + * jit/JITStubs.cpp: + (JSC::JITThunks::JITThunks): structure member name fix. -2012-09-14 Mark Hahnenberg <mhahnenberg@apple.com> +2012-10-10 Michael Saboff <msaboff@apple.com> - Remove the Zapped BlockState - https://bugs.webkit.org/show_bug.cgi?id=96708 + After r130344, OpaqueJSString::string() shouldn't directly return the wrapped String + https://bugs.webkit.org/show_bug.cgi?id=98801 Reviewed by Geoffrey Garen. - The Zapped block state is rather confusing. It indicates that a block is in one of two different states that we - can't tell the difference between: - - 1) I have run all destructors of things that are zapped, and I have not allocated any more objects. This block - is ready for reclaiming if you so choose. - 2) I have run all the destructors of things that are zapped, but I have allocated more stuff since then, so it - is not safe to reclaim this block. - - This state adds a lot of complexity to our state transition model for MarkedBlocks. We should get rid of it. - We can replace this state by making sure mark bits represent all of the liveness information we need when running - our conservative stack scan. Instead of zapping the free list when canonicalizing cell liveness data prior to - a conservative scan, we can instead mark all objects in the block except for those in the free list. This should - incur no performance penalty since we're doing it on a very small O(1) number of blocks at the beginning of the collection. - - For the time being we still need to use zapping to determine whether we have run an object's destructor or not. - - * heap/MarkedAllocator.cpp: - (JSC::MarkedAllocator::tryAllocateHelper): Renaming stuff. - * heap/MarkedAllocator.h: Renamed zapFreeList to canonicalizeCellLivenessData to match. - (MarkedAllocator): - (JSC::MarkedAllocator::canonicalizeCellLivenessData): Same as old zapFreeList, but just call canonicalize instead. - * heap/MarkedBlock.cpp: - (JSC::MarkedBlock::specializedSweep): Remove the check for Zapped block stuff. Also change the block state to Marked - instead of Zapped if we're not producing a FreeList since that's the only other state that really makes any sense. - (JSC::MarkedBlock::sweepHelper): Remove Zapped related code. - (SetAllMarksFunctor): Functor to set all the mark bits in the block since there's not a simple function to call on - the Bitmap itself. - (JSC::SetAllMarksFunctor::operator()): - (JSC): - (JSC::MarkedBlock::canonicalizeCellLivenessData): Remove all the stuff for Zapped. For FreeListed, set all the mark bits - and then clear the ones for the objects in the FreeList. This ensures that only the things that were in the FreeList - are considered to be dead by the conservative scan, just like if we were to have zapped the FreeList like before. - * heap/MarkedBlock.h: - (MarkedBlock): - (JSC::MarkedBlock::clearMarked): Add function to clear individual mark bits, since we need that functionality now. - (JSC): - (JSC::MarkedBlock::isLive): Remove code for Zapped stuff. Marked handles all interesting cases now. - (JSC::MarkedBlock::forEachCell): Add new iterator function that iterates over all cells in the block, regardless of - whether they're live or a dead. - * heap/MarkedSpace.cpp: - (JSC::MarkedSpace::canonicalizeCellLivenessData): Change to call the renamed canonicalize function. - -2012-09-13 Kevin Funk <kevin.funk@kdab.com> - - Make compile with both OS(WINCE) and PLATFORM(QT) support - https://bugs.webkit.org/show_bug.cgi?id=95536 + Return a copy of the wrapped String so that the wrapped string cannot be turned into + an Identifier. - Reviewed by Simon Hausmann. + * API/OpaqueJSString.cpp: + (OpaqueJSString::string): + * API/OpaqueJSString.h: + (OpaqueJSString): - Do not link against advapi32 on wince +2012-10-10 Peter Gal <galpeter@inf.u-szeged.hu> - * jsc.pro: + Add moveDoubleToInts and moveIntsToDouble to MacroAssemblerARM + https://bugs.webkit.org/show_bug.cgi?id=98855 -2012-09-13 Geoffrey Garen <ggaren@apple.com> + Reviewed by Filip Pizlo. - Refactored the DFG to make fewer assumptions about variable capture - https://bugs.webkit.org/show_bug.cgi?id=96680 + Implement the missing moveDoubleToInts and moveIntsToDouble + methods in the MacroAssemblerARM after r130839. - Reviewed by Gavin Barraclough. + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::moveDoubleToInts): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::moveIntsToDouble): - A variable capture optimization patch I'm working on broke DFG - correctness and the arguments simplification optimization phase, so I've - refactored both to make fewer assumptions about variable capture. +2012-10-09 Filip Pizlo <fpizlo@apple.com> - * bytecode/CodeBlock.h: - (JSC::CodeBlock::isCaptured): This is the new One True Way to find out - if a variable was captured. This gives us a single point of maintenance - as we chagne capture behavior. + Typed arrays should not be 20x slower in the baseline JIT than in the DFG JIT + https://bugs.webkit.org/show_bug.cgi?id=98605 - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::clobberCapturedVars): Don't assume that captured - variables have any particular location. Instead, ask the One True Function. + Reviewed by Oliver Hunt and Gavin Barraclough. - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): Mechanical - changes to separate being captured from being 'arguments'. What used - to be - if (captured) - if (arguments) - x - y - is now - if (arguments) - x - y - else if (captured) - y + This adds typed array get_by_val/put_by_val patching to the baseline JIT. It's + a big (~40%) win on benchmarks that have trouble staying in the DFG JIT. Even + if we fix those benchmarks, this functionality gives us the insurance that we + typically desire with all speculative optimizations: even if we bail to + baseline, we're still reasonably performant. - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getLocal): - (JSC::DFG::ByteCodeParser::setLocal): - (JSC::DFG::ByteCodeParser::getArgument): - (JSC::DFG::ByteCodeParser::setArgument): - (JSC::DFG::ByteCodeParser::flushDirect): - (JSC::DFG::ByteCodeParser::parseBlock): - (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/MacroAssembler.cpp: Added. + (JSC): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranchPtr): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::moveDoubleToInts): + (JSC::MacroAssemblerARMv7::moveIntsToDouble): + (JSC::MacroAssemblerARMv7::patchableBranchPtr): + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::moveDoubleToInts): + (JSC::MacroAssemblerX86::moveIntsToDouble): + * bytecode/ByValInfo.h: + (JSC::hasOptimizableIndexingForClassInfo): + (JSC): + (JSC::hasOptimizableIndexing): + (JSC::jitArrayModeForClassInfo): + (JSC::jitArrayModeForStructure): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + * dfg/DFGAssemblyHelpers.cpp: + (DFG): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + (JSC::DFG::AssemblyHelpers::boxDouble): + (JSC::DFG::AssemblyHelpers::unboxDouble): * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compile): Use the One True Function. + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * jit/JIT.h: + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + (JSC::JIT::emitIntTypedArrayGetByVal): + (JSC): + (JSC::JIT::emitFloatTypedArrayGetByVal): + (JSC::JIT::emitIntTypedArrayPutByVal): + (JSC::JIT::emitFloatTypedArrayPutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/JSCell.h: + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::typedArrayDescriptor): + * runtime/TypedArrayDescriptor.h: Added. + (JSC): + (JSC::TypedArrayDescriptor::TypedArrayDescriptor): + (TypedArrayDescriptor): -2012-09-13 Benjamin Poulain <bpoulain@apple.com> +2012-10-09 Michael Saboff <msaboff@apple.com> - Improve the SourceProvider hierarchy - https://bugs.webkit.org/show_bug.cgi?id=95635 + Add tests to testapi for null OpaqueJSStrings + https://bugs.webkit.org/show_bug.cgi?id=98805 Reviewed by Geoffrey Garen. - SourceProvider was designed to have subclasses magically handling the data without - decoding all of it. The virtual methods length() and getRange() were based - on these assumptions. - - In practice, the magic was in our head, there is no implementation that takes - advantage of that. - - SourceProvider is modified to adopt WebCore's ScriptSourceProvider::source() and base - everything on it. - The code using SourceProvider is also simplified. - - * interpreter/Interpreter.cpp: - (JSC::appendSourceToError): Keep a reference to the string instead of querying it for - each time it is used. - * parser/Lexer.cpp: - (JSC::::setCode): - (JSC::::sourceCode): - * parser/Parser.h: - (JSC::parse): - * parser/SourceCode.h: - (JSC::SourceCode::SourceCode): - (JSC::SourceCode::subExpression): - * parser/SourceProvider.h: - (SourceProvider): - (JSC::SourceProvider::getRange): + Added tests that check that OpaqueJSString, which is wrapped via JSStringRef, properly returns + null strings and that a null string in a JSStringRef will return a NULL JSChar* and 0 length + via the JSStringGetCharactersPtr() and JSStringGetLength() APIs respectively. Added a check that + JSValueMakeFromJSONString() properly handles a null string as well. -2012-09-13 Filip Pizlo <fpizlo@apple.com> + * API/tests/testapi.c: + (main): - DFG: Dead GetButterfly's shouldn't be subject to CSE - https://bugs.webkit.org/show_bug.cgi?id=96707 - <rdar://problem/12296311> +2012-10-09 Jian Li <jianli@chromium.org> - Reviewed by Oliver Hunt. - - There were a number of cases of this that creeped into the CSE: it would - match something even though it was dead. + Update the CSS property used to support draggable regions. + https://bugs.webkit.org/show_bug.cgi?id=97156 - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): - (JSC::DFG::CSEPhase::checkArrayElimination): - (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): - (JSC::DFG::CSEPhase::getScopeChainLoadElimination): - (JSC::DFG::CSEPhase::getLocalLoadElimination): + Reviewed by Adam Barth. -2012-09-13 Oliver Hunt <oliver@apple.com> + The CSS property to support draggable regions, guarded under + WIDGET_REGION is now disabled from Mac WebKit, in order not to cause + confusion with DASHBOARD_SUPPORT feature. - Make global const initialisation explicit in the bytecode - https://bugs.webkit.org/show_bug.cgi?id=96711 + * Configurations/FeatureDefines.xcconfig: Disable WIDGET_REGION feature. - Reviewed by Gavin Barraclough. +2012-10-09 Filip Pizlo <fpizlo@apple.com> - Added op_init_global_const to make initialisation of global const - fields explicit. This will help us keep correct semantics in the - upcoming variable resolution refactoring. + Unreviewed, adding forgotten files. - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/Opcode.h: + * bytecode/ByValInfo.h: Added. (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::isOptimizableIndexingType): + (JSC::jitArrayModeForIndexingType): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + (JSC::getByValInfoBytecodeIndex): + * runtime/IndexingType.cpp: Added. (JSC): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::ConstDeclNode::emitCodeSingle): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCapabilities.h: - (JSC::DFG::canCompileOpcode): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - (JSC::JIT::privateCompileSlowCases): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-13 Mark Hahnenberg <mhahnenberg@apple.com> - - Rename forEachCell to forEachLiveCell - https://bugs.webkit.org/show_bug.cgi?id=96685 - - Reviewed by Oliver Hunt. - - forEachCell actually only iterates over live cells. We should rename it to - reflect what it actually does. This is also helpful because we want to add a new - forEachCell that actually does iterate each and every cell in a MarkedBlock - regardless of whether or not it is live. - - * debugger/Debugger.cpp: - (JSC::Debugger::recompileAllJSFunctions): - * heap/Heap.cpp: - (JSC::Heap::globalObjectCount): - (JSC::Heap::objectTypeCounts): - * heap/MarkedBlock.h: - (MarkedBlock): - (JSC::MarkedBlock::forEachLiveCell): - * heap/MarkedSpace.h: - (MarkedSpace): - (JSC::MarkedSpace::forEachLiveCell): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::releaseExecutableMemory): - -2012-09-13 Filip Pizlo <fpizlo@apple.com> - - [Qt][Win] REGRESSION(r128400): It broke the build - https://bugs.webkit.org/show_bug.cgi?id=96617 - - Reviewed by Simon Hausmann. - - Changed "JSC::Array" to "JSC::ArrayClass" because it's not used often enough - for the brevity to be beneficial, and because "Array" causes too much namespace - pollution. - - * runtime/IndexingType.h: - (JSC): - * runtime/JSArray.cpp: - (JSC::JSArray::pop): - (JSC::JSArray::push): - (JSC::JSArray::sortNumeric): - (JSC::JSArray::sort): - (JSC::JSArray::fillArgList): - (JSC::JSArray::copyToArguments): - (JSC::JSArray::compactForSorting): - * runtime/JSObject.cpp: - (JSC::JSObject::getOwnPropertySlotByIndex): - (JSC::JSObject::putByIndex): - (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): - (JSC::JSObject::deletePropertyByIndex): - (JSC::JSObject::getOwnPropertyNames): - (JSC::JSObject::putByIndexBeyondVectorLength): - (JSC::JSObject::putDirectIndexBeyondVectorLength): - (JSC::JSObject::getNewVectorLength): - (JSC::JSObject::getOwnPropertyDescriptor): - * runtime/JSObject.h: - (JSC::JSObject::getArrayLength): - (JSC::JSObject::getVectorLength): - (JSC::JSObject::canGetIndexQuickly): - (JSC::JSObject::canSetIndexQuickly): - (JSC::JSObject::inSparseIndexingMode): - (JSC::JSObject::ensureArrayStorage): - -2012-09-13 Filip Pizlo <fpizlo@apple.com> + (JSC::indexingTypeToString): - Testing whether indexing type is ArrayWithArrayStorage should not compare against ArrayWithArrayStorage - https://bugs.webkit.org/show_bug.cgi?id=96611 +2012-10-08 Filip Pizlo <fpizlo@apple.com> - Reviewed by Gavin Barraclough. + JSC should infer when indexed storage is contiguous, and optimize for it + https://bugs.webkit.org/show_bug.cgi?id=97288 - * dfg/DFGRepatch.cpp: - (JSC::DFG::tryCacheGetByID): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArray): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompilePatchGetArrayLength): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::privateCompilePatchGetArrayLength): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-09 Filip Pizlo <fpizlo@apple.com> - - JSC should have property butterflies - https://bugs.webkit.org/show_bug.cgi?id=91933 - - Reviewed by Geoffrey Garen. + Reviewed by Mark Hahnenberg. - This changes the JSC object model. Previously, all objects had fast lookup for - named properties. Integer indexed properties were only fast if you used a - JSArray. With this change, all objects have fast indexed properties. This is - accomplished without any space overhead by using a bidirectional object layout, - aka butterflies. Each JSObject has a m_butterfly pointer where previously it - had a m_outOfLineStorage pointer. To the left of the location pointed to by - m_butterfly, we place all named out-of-line properties. To the right, we place - all indexed properties along with indexing meta-data. Though, some indexing - meta-data is placed in the 8-byte word immediately left of the pointed-to - location; this is in anticipation of the indexing meta-data being small enough - in the common case that m_butterfly always points to the first indexed - property. + This introduces a new kind of indexed property storage called Contiguous, + which has the following properties: - This is performance neutral, except on tests that use indexed properties on - plain objects, where the speed-up is in excess of an order of magnitude. + - No header bits beyond IndexedHeader. This results in a 16 byte reduction + in memory usage per array versus an ArrayStorage array. It also means + that the total memory usage for an empty array is now just 3 * 8 on both + 32-bit and 64-bit. Of that, only 8 bytes are array-specific; the rest is + our standard object header overhead. - One notable aspect of what this change brings is that it allows indexing - storage to morph over time. Currently this is only used to allow all non-array - objects to start out without any indexed storage. But it could be used for - some kinds of array type inference in the future. + - No need for hole checks on store. This results in a ~4% speed-up on + Kraken and a ~1% speed-up on V8v7. + + - publicLength <= vectorLength. This means that doing new Array(blah) + immediately allocates room for blah elements. + + - No sparse map or index bias. + + If you ever do things to an array that would require publicLength > + vectorLength, a sparse map, or index bias, then we switch to ArrayStorage + mode. This seems to never happen in any benchmark we track, and is unlikely + to happen very frequently on any website. - * API/JSCallbackObject.h: - (JSCallbackObject): - * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnPropertySlotByIndex): - (JSC): - (JSC::::getOwnNonIndexPropertyNames): - * API/JSObjectRef.cpp: * CMakeLists.txt: * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: - * bytecode/ArrayProfile.h: - (JSC): - (JSC::arrayModeFromStructure): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitDirectPutById): + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::JumpList::append): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranchTest32): + * bytecode/ByValInfo.h: Added. + (JSC): + (JSC::isOptimizableIndexingType): + (JSC::jitArrayModeForIndexingType): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + (JSC::getByValInfoBytecodeIndex): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::getByValInfo): + (JSC::CodeBlock::setNumberOfByValInfos): + (JSC::CodeBlock::numberOfByValInfos): + (JSC::CodeBlock::byValInfo): + * bytecode/SamplingTool.h: * dfg/DFGAbstractState.cpp: (JSC::DFG::AbstractState::execute): - * dfg/DFGAdjacencyList.h: - (JSC::DFG::AdjacencyList::AdjacencyList): - (AdjacencyList): * dfg/DFGArrayMode.cpp: (JSC::DFG::fromObserved): (JSC::DFG::modeAlreadyChecked): @@ -2591,3391 +1851,547 @@ (JSC::DFG::modeUsesButterfly): (JSC::DFG::modeIsJSArray): (JSC::DFG::isInBoundsAccess): + (JSC::DFG::mayStoreToTail): + (JSC::DFG::mayStoreToHole): + (JSC::DFG::modeIsPolymorphic): + (JSC::DFG::polymorphicIncludesContiguous): + (JSC::DFG::polymorphicIncludesArrayStorage): + (JSC::DFG::canCSEStorage): (JSC::DFG::modeSupportsLength): + (JSC::DFG::benefitsFromStructureCheck): + (JSC::DFG::isEffectful): * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::handleGetByOffset): - (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::handleIntrinsic): * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::addNode): - (FixupPhase): (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): * dfg/DFGGraph.h: (JSC::DFG::Graph::byValIsPure): - * dfg/DFGNode.h: - (JSC::DFG::Node::Node): - (Node): - * dfg/DFGNodeType.h: - (DFG): * dfg/DFGOperations.cpp: - (JSC::DFG::putByVal): * dfg/DFGOperations.h: - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGRepatch.cpp: - (JSC::DFG::generateProtoChainAccessStub): (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDList): - (JSC::DFG::emitPutReplaceStub): - (JSC::DFG::emitPutTransitionStub): - (JSC::DFG::tryBuildPutByIdList): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::arrayify): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): - (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + (DFG): * dfg/DFGSpeculativeJIT.h: + (DFG): (JSC::DFG::SpeculativeJIT::callOperation): - (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::cachedGetById): - (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): + (DFG): + (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::cachedGetById): - (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): + (DFG): + (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - * heap/CopiedSpace.h: - (CopiedSpace): + * interpreter/Interpreter.cpp: + (SamplingScope): + (JSC::SamplingScope::SamplingScope): + (JSC::SamplingScope::~SamplingScope): + (JSC): + (JSC::Interpreter::execute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): * jit/JIT.h: + (JSC::ByValCompilationInfo::ByValCompilationInfo): + (ByValCompilationInfo): + (JSC): + (JIT): + (JSC::JIT::compileGetByVal): + (JSC::JIT::compilePutByVal): * jit/JITInlineMethods.h: - (JSC::JIT::emitAllocateBasicJSObject): - (JSC::JIT::emitAllocateBasicStorage): (JSC::JIT::emitAllocateJSArray): + (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): + (JSC): + (JSC::arrayProfileSaw): + (JSC::JIT::chooseArrayMode): * jit/JITOpcodes.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): (JSC::JIT::emit_op_new_array): (JSC::JIT::emitSlow_op_new_array): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::compileGetDirectOffset): + (JSC): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::compileGetByIdHotPath): - (JSC::JIT::emit_op_put_by_id): - (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): + (JSC): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::compileGetByIdHotPath): - (JSC::JIT::emit_op_put_by_id): - (JSC::JIT::compilePutDirectOffset): - (JSC::JIT::compileGetDirectOffset): - (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::emitSlow_op_put_by_val): * jit/JITStubs.cpp: + (JSC::getByVal): + (JSC): (JSC::DEFINE_STUB_FUNCTION): - * jsc.cpp: - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::putByVal): + * jit/JITStubs.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: - * runtime/Arguments.cpp: - (JSC::Arguments::deletePropertyByIndex): - (JSC::Arguments::defineOwnProperty): - * runtime/ArrayConstructor.cpp: - * runtime/ArrayConventions.h: Added. - (JSC): + * runtime/ArrayConventions.h: (JSC::isDenseEnoughForVector): - (JSC::indexingHeaderForArray): - (JSC::baseIndexingHeaderForArray): * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::create): - (JSC): - (JSC::ArrayPrototype::ArrayPrototype): - (JSC::arrayProtoFuncToString): - (JSC::arrayProtoFuncJoin): - (JSC::arrayProtoFuncSort): - (JSC::arrayProtoFuncFilter): - (JSC::arrayProtoFuncMap): - (JSC::arrayProtoFuncEvery): - (JSC::arrayProtoFuncForEach): - (JSC::arrayProtoFuncSome): - (JSC::arrayProtoFuncReduce): - (JSC::arrayProtoFuncReduceRight): - * runtime/ArrayPrototype.h: - (ArrayPrototype): - (JSC::ArrayPrototype::createStructure): - * runtime/ArrayStorage.h: Added. - (JSC): - (ArrayStorage): - (JSC::ArrayStorage::ArrayStorage): - (JSC::ArrayStorage::from): - (JSC::ArrayStorage::butterfly): - (JSC::ArrayStorage::indexingHeader): - (JSC::ArrayStorage::length): - (JSC::ArrayStorage::setLength): - (JSC::ArrayStorage::vectorLength): - (JSC::ArrayStorage::setVectorLength): - (JSC::ArrayStorage::copyHeaderFromDuringGC): - (JSC::ArrayStorage::inSparseMode): - (JSC::ArrayStorage::lengthOffset): - (JSC::ArrayStorage::vectorLengthOffset): - (JSC::ArrayStorage::numValuesInVectorOffset): - (JSC::ArrayStorage::vectorOffset): - (JSC::ArrayStorage::indexBiasOffset): - (JSC::ArrayStorage::sparseMapOffset): - (JSC::ArrayStorage::sizeFor): - * runtime/Butterfly.h: Added. (JSC): + (JSC::shift): + (JSC::unshift): + (JSC::arrayProtoFuncPush): + (JSC::arrayProtoFuncShift): + (JSC::arrayProtoFuncSplice): + (JSC::arrayProtoFuncUnShift): + * runtime/Butterfly.h: (Butterfly): - (JSC::Butterfly::Butterfly): - (JSC::Butterfly::totalSize): - (JSC::Butterfly::fromBase): - (JSC::Butterfly::offsetOfIndexingHeader): - (JSC::Butterfly::offsetOfPublicLength): - (JSC::Butterfly::offsetOfVectorLength): - (JSC::Butterfly::indexingHeader): - (JSC::Butterfly::propertyStorage): - (JSC::Butterfly::indexingPayload): - (JSC::Butterfly::arrayStorage): - (JSC::Butterfly::offsetOfPropertyStorage): - (JSC::Butterfly::indexOfPropertyStorage): - (JSC::Butterfly::base): - * runtime/ButterflyInlineMethods.h: Added. - (JSC): - (JSC::Butterfly::createUninitialized): - (JSC::Butterfly::create): - (JSC::Butterfly::createUninitializedDuringCollection): - (JSC::Butterfly::base): - (JSC::Butterfly::growPropertyStorage): - (JSC::Butterfly::growArrayRight): - (JSC::Butterfly::resizeArray): + (JSC::Butterfly::fromPointer): + (JSC::Butterfly::pointer): + (JSC::Butterfly::publicLength): + (JSC::Butterfly::vectorLength): + (JSC::Butterfly::setPublicLength): + (JSC::Butterfly::setVectorLength): + (JSC::Butterfly::contiguous): + (JSC::Butterfly::fromContiguous): + * runtime/ButterflyInlineMethods.h: (JSC::Butterfly::unshift): (JSC::Butterfly::shift): - * runtime/ClassInfo.h: - (MethodTable): - (JSC): - * runtime/IndexingHeader.h: Added. - (JSC): - (IndexingHeader): - (JSC::IndexingHeader::offsetOfIndexingHeader): - (JSC::IndexingHeader::offsetOfPublicLength): - (JSC::IndexingHeader::offsetOfVectorLength): - (JSC::IndexingHeader::IndexingHeader): - (JSC::IndexingHeader::vectorLength): - (JSC::IndexingHeader::setVectorLength): - (JSC::IndexingHeader::publicLength): - (JSC::IndexingHeader::setPublicLength): - (JSC::IndexingHeader::from): - (JSC::IndexingHeader::fromEndOf): - (JSC::IndexingHeader::propertyStorage): - (JSC::IndexingHeader::arrayStorage): - (JSC::IndexingHeader::butterfly): - * runtime/IndexingHeaderInlineMethods.h: Added. - (JSC): - (JSC::IndexingHeader::preCapacity): + * runtime/IndexingHeaderInlineMethods.h: (JSC::IndexingHeader::indexingPayloadSizeInBytes): - * runtime/IndexingType.h: Added. + * runtime/IndexingType.cpp: Added. (JSC): - (JSC::hasIndexingHeader): - * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): - (JSC::JSActivation::visitChildren): - (JSC::JSActivation::getOwnNonIndexPropertyNames): - * runtime/JSActivation.h: - (JSActivation): - (JSC::JSActivation::tearOff): - * runtime/JSArray.cpp: + (JSC::indexingTypeToString): + * runtime/IndexingType.h: (JSC): - (JSC::createArrayButterflyInDictionaryIndexingMode): - (JSC::JSArray::setLengthWritable): - (JSC::JSArray::defineOwnProperty): - (JSC::JSArray::getOwnPropertySlot): - (JSC::JSArray::getOwnPropertyDescriptor): - (JSC::JSArray::put): - (JSC::JSArray::deleteProperty): - (JSC::JSArray::getOwnNonIndexPropertyNames): - (JSC::JSArray::unshiftCountSlowCase): + (JSC::hasContiguous): + * runtime/JSArray.cpp: + (JSC::JSArray::setLengthWithArrayStorage): (JSC::JSArray::setLength): + (JSC): (JSC::JSArray::pop): (JSC::JSArray::push): - (JSC::JSArray::shiftCount): - (JSC::JSArray::unshiftCount): + (JSC::JSArray::shiftCountWithArrayStorage): + (JSC::JSArray::shiftCountWithAnyIndexingType): + (JSC::JSArray::unshiftCountWithArrayStorage): + (JSC::JSArray::unshiftCountWithAnyIndexingType): + (JSC::JSArray::sortNumericVector): (JSC::JSArray::sortNumeric): + (JSC::JSArray::sortCompactedVector): (JSC::JSArray::sort): + (JSC::JSArray::sortVector): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): (JSC::JSArray::compactForSorting): * runtime/JSArray.h: - (JSC): + (JSC::JSArray::shiftCountForShift): + (JSC::JSArray::shiftCountForSplice): (JSArray): - (JSC::JSArray::JSArray): - (JSC::JSArray::length): - (JSC::JSArray::createStructure): + (JSC::JSArray::shiftCount): + (JSC::JSArray::unshiftCountForShift): + (JSC::JSArray::unshiftCountForSplice): + (JSC::JSArray::unshiftCount): (JSC::JSArray::isLengthWritable): - (JSC::createArrayButterfly): + (JSC::createContiguousArrayButterfly): + (JSC): (JSC::JSArray::create): (JSC::JSArray::tryCreateUninitialized): - * runtime/JSBoundFunction.cpp: - (JSC::boundFunctionCall): - (JSC::boundFunctionConstruct): - (JSC::JSBoundFunction::finishCreation): - * runtime/JSCell.cpp: - (JSC::JSCell::getOwnNonIndexPropertyNames): - (JSC): - * runtime/JSCell.h: - (JSCell): - * runtime/JSFunction.cpp: - (JSC::JSFunction::getOwnPropertySlot): - (JSC::JSFunction::getOwnPropertyDescriptor): - (JSC::JSFunction::getOwnNonIndexPropertyNames): - (JSC::JSFunction::defineOwnProperty): - * runtime/JSFunction.h: - (JSFunction): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): - * runtime/JSONObject.cpp: - (JSC::Stringifier::Holder::appendNextProperty): - (JSC::Walker::walk): - * runtime/JSObject.cpp: (JSC): + (JSC::JSGlobalObject::haveABadTime): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::arrayStructureWithArrayStorage): + (JSC::JSGlobalObject::addressOfArrayStructureWithArrayStorage): + (JSC::constructEmptyArray): + * runtime/JSObject.cpp: (JSC::JSObject::visitButterfly): - (JSC::JSObject::visitChildren): - (JSC::JSFinalObject::visitChildren): (JSC::JSObject::getOwnPropertySlotByIndex): - (JSC::JSObject::put): (JSC::JSObject::putByIndex): - (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::createInitialContiguous): + (JSC): (JSC::JSObject::createArrayStorage): - (JSC::JSObject::createInitialArrayStorage): + (JSC::JSObject::convertContiguousToArrayStorage): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC::JSObject::ensureIndexedStorageSlow): (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): - (JSC::JSObject::putDirectAccessor): - (JSC::JSObject::deleteProperty): + (JSC::JSObject::switchToSlowPutArrayStorage): + (JSC::JSObject::setPrototype): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): - (JSC::JSObject::getOwnNonIndexPropertyNames): - (JSC::JSObject::preventExtensions): - (JSC::JSObject::fillGetterPropertySlot): - (JSC::JSObject::putIndexedDescriptor): (JSC::JSObject::defineOwnIndexedProperty): - (JSC::JSObject::allocateSparseIndexMap): - (JSC::JSObject::deallocateSparseIndexMap): - (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putByIndexBeyondVectorLengthContiguousWithoutAttributes): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::putDirectIndexBeyondVectorLength): (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::countElementsInContiguous): (JSC::JSObject::increaseVectorLength): - (JSC::JSObject::checkIndexingConsistency): - (JSC::JSObject::growOutOfLineStorage): + (JSC::JSObject::ensureContiguousLengthSlow): (JSC::JSObject::getOwnPropertyDescriptor): - (JSC::putDescriptor): - (JSC::JSObject::putDirectMayBeIndex): - (JSC::JSObject::defineOwnNonIndexProperty): - (JSC::JSObject::defineOwnProperty): - (JSC::JSObject::getOwnPropertySlotSlow): * runtime/JSObject.h: (JSC::JSObject::getArrayLength): - (JSObject): (JSC::JSObject::getVectorLength): - (JSC::JSObject::putDirectIndex): (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): + (JSC::JSObject::tryGetIndexQuickly): (JSC::JSObject::canSetIndexQuickly): + (JSC::JSObject::canSetIndexQuicklyForPutDirect): (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): - (JSC::JSObject::completeInitialization): + (JSC::JSObject::hasSparseMap): (JSC::JSObject::inSparseIndexingMode): - (JSC::JSObject::butterfly): - (JSC::JSObject::outOfLineStorage): - (JSC::JSObject::offsetForLocation): - (JSC::JSObject::indexingShouldBeSparse): - (JSC::JSObject::butterflyOffset): - (JSC::JSObject::butterflyAddress): - (JSC::JSObject::arrayStorage): - (JSC::JSObject::arrayStorageOrZero): - (JSC::JSObject::ensureArrayStorage): - (JSC::JSObject::checkIndexingConsistency): - (JSC::JSNonFinalObject::JSNonFinalObject): - (JSC): - (JSC::JSObject::setButterfly): - (JSC::JSObject::setButterflyWithoutChangingStructure): - (JSC::JSObject::JSObject): - (JSC::JSObject::inlineGetOwnPropertySlot): - (JSC::JSObject::putDirectInternal): - (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): - (JSC::JSObject::putDirectWithoutTransition): - (JSC::offsetInButterfly): - (JSC::offsetRelativeToPatchedStorage): - (JSC::indexRelativeToBase): - (JSC::offsetRelativeToBase): - * runtime/JSPropertyNameIterator.cpp: - (JSC::JSPropertyNameIterator::create): - * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSSymbolTableObject): - * runtime/JSTypeInfo.h: - (JSC): - (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero): - (JSC::TypeInfo::overridesGetPropertyNames): - * runtime/LiteralParser.cpp: - (JSC::::parse): - * runtime/ObjectConstructor.cpp: - * runtime/ObjectPrototype.cpp: - (JSC::ObjectPrototype::ObjectPrototype): - (JSC): - * runtime/ObjectPrototype.h: - (ObjectPrototype): - * runtime/PropertyOffset.h: - (JSC::offsetInOutOfLineStorage): - * runtime/PropertyStorage.h: Added. - (JSC): - * runtime/PutDirectIndexMode.h: Added. - (JSC): - * runtime/RegExpMatchesArray.cpp: - (JSC::RegExpMatchesArray::RegExpMatchesArray): - (JSC): - (JSC::RegExpMatchesArray::create): - (JSC::RegExpMatchesArray::finishCreation): - * runtime/RegExpMatchesArray.h: - (RegExpMatchesArray): - (JSC::RegExpMatchesArray::createStructure): - * runtime/RegExpObject.cpp: - (JSC::RegExpObject::getOwnNonIndexPropertyNames): - * runtime/RegExpObject.h: - (RegExpObject): - * runtime/Reject.h: Added. - (JSC): - (JSC::reject): - * runtime/SparseArrayValueMap.cpp: Added. - (JSC): - * runtime/SparseArrayValueMap.h: Added. - (JSC): - (SparseArrayEntry): - (JSC::SparseArrayEntry::SparseArrayEntry): - (SparseArrayValueMap): - (JSC::SparseArrayValueMap::sparseMode): - (JSC::SparseArrayValueMap::setSparseMode): - (JSC::SparseArrayValueMap::lengthIsReadOnly): - (JSC::SparseArrayValueMap::setLengthIsReadOnly): - (JSC::SparseArrayValueMap::find): - (JSC::SparseArrayValueMap::remove): - (JSC::SparseArrayValueMap::notFound): - (JSC::SparseArrayValueMap::isEmpty): - (JSC::SparseArrayValueMap::contains): - (JSC::SparseArrayValueMap::size): - (JSC::SparseArrayValueMap::begin): - (JSC::SparseArrayValueMap::end): - * runtime/SparseArrayValueMapInlineMethods.h: Added. - (JSC): - (JSC::SparseArrayValueMap::SparseArrayValueMap): - (JSC::SparseArrayValueMap::~SparseArrayValueMap): - (JSC::SparseArrayValueMap::finishCreation): - (JSC::SparseArrayValueMap::create): - (JSC::SparseArrayValueMap::destroy): - (JSC::SparseArrayValueMap::createStructure): - (JSC::SparseArrayValueMap::add): - (JSC::SparseArrayValueMap::putEntry): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayEntry::get): - (JSC::SparseArrayEntry::getNonSparseMode): - (JSC::SparseArrayValueMap::visitChildren): - * runtime/StorageBarrier.h: Removed. - * runtime/StringObject.cpp: - (JSC::StringObject::putByIndex): - (JSC): - (JSC::StringObject::deletePropertyByIndex): - * runtime/StringObject.h: - (StringObject): - * runtime/StringPrototype.cpp: + (JSObject): + (JSC::JSObject::ensureContiguous): + (JSC::JSObject::ensureIndexedStorage): + (JSC::JSObject::ensureContiguousLength): + (JSC::JSObject::indexingData): + (JSC::JSObject::relevantLength): + * runtime/JSValue.cpp: + (JSC::JSValue::description): + * runtime/Options.cpp: + (JSC::Options::initialize): * runtime/Structure.cpp: - (JSC::Structure::Structure): - (JSC::Structure::materializePropertyMap): - (JSC::Structure::nonPropertyTransition): + (JSC::Structure::needsSlowPutIndexing): (JSC): + (JSC::Structure::suggestedArrayStorageTransition): * runtime/Structure.h: (Structure): - (JSC::Structure::indexingType): - (JSC::Structure::indexingTypeIncludingHistory): - (JSC::Structure::indexingTypeOffset): - (JSC::Structure::create): * runtime/StructureTransitionTable.h: - (JSC): - (JSC::toAttributes): (JSC::newIndexingType): - (JSC::StructureTransitionTable::Hash::hash): - * tests/mozilla/js1_6/Array/regress-304828.js: - -2012-09-12 Mark Lam <mark.lam@apple.com> - Refactor Opcodes to distinguish between core and extension opcodes. - https://bugs.webkit.org/show_bug.cgi?id=96466. +2012-10-09 Michael Saboff <msaboff@apple.com> - Reviewed by Filip Pizlo. - - * bytecode/Opcode.h: - (JSC): Added FOR_EACH_CORE_OPCODE_ID() macro. - * llint/LowLevelInterpreter.h: - (JSC): Auto-generate llint opcode aliases using the - FOR_EACH_CORE_OPCODE_ID() macro. - -2012-09-11 Geoffrey Garen <ggaren@apple.com> - - Second step to fixing the Windows build: Add new symbols. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-09-11 Geoffrey Garen <ggaren@apple.com> - - First step to fixing the Windows build: Remove old symbols. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-09-11 Geoffrey Garen <ggaren@apple.com> - - Don't allocate a backing store just for a function's name - https://bugs.webkit.org/show_bug.cgi?id=96468 - - Reviewed by Oliver Hunt. + After r130344, OpaqueJSString::identifier() adds wrapped String to identifier table + https://bugs.webkit.org/show_bug.cgi?id=98693 + REGRESSION (r130344): Install failed in Install Environment + <rdar://problem/12450118> - Treat function.name like function.length etc., and use a custom getter. - This saves space in closures. - - * debugger/DebuggerCallFrame.cpp: - (JSC::DebuggerCallFrame::functionName): - * debugger/DebuggerCallFrame.h: - (DebuggerCallFrame): Updated for interface change. - - * runtime/Executable.h: - (JSC::JSFunction::JSFunction): Do a little inlining. - - * runtime/JSFunction.cpp: - (JSC::JSFunction::finishCreation): Gone now. That's the point of the patch. - - (JSC::JSFunction::name): - (JSC::JSFunction::displayName): - (JSC::JSFunction::nameGetter): - (JSC::JSFunction::getOwnPropertySlot): - (JSC::JSFunction::getOwnPropertyDescriptor): - (JSC::JSFunction::getOwnPropertyNames): - (JSC::JSFunction::put): - (JSC::JSFunction::deleteProperty): - (JSC::JSFunction::defineOwnProperty): Added custom accessors for .name - just like .length and others. - - * runtime/JSFunction.h: - (JSC::JSFunction::create): - (JSFunction): Updated for interface changes. - -2012-09-11 Mark Hahnenberg <mhahnenberg@apple.com> - - IncrementalSweeper should not sweep/free Zapped blocks - https://bugs.webkit.org/show_bug.cgi?id=96464 - - Reviewed by Filip Pizlo. + Reviewed by Mark Rowe. - 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. + Use Identifier(LChar*, length) or Identifier(UChar*, length) constructors so that we don't + add the String instance in the OpaqueJSString to any identifier tables. - * heap/MarkedBlock.h: - (JSC::MarkedBlock::needsSweeping): It is only valid to sweep a block if it is in the Marked state. + * API/OpaqueJSString.cpp: + (OpaqueJSString::identifier): -2012-09-11 Geoffrey Garen <ggaren@apple.com> +2012-10-08 Mark Lam <mark.lam@apple.com> - JSActivation should inline allocate its registers, and eliminate - 'arguments' registers in the common case - https://bugs.webkit.org/show_bug.cgi?id=96427 + Renamed RegisterFile to JSStack, and removed prototype of the + previously deleted Interpreter::privateExecute(). + https://bugs.webkit.org/show_bug.cgi?id=98717. Reviewed by Filip Pizlo. - This cuts the size class for simple closures down to 64 bytes. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): Set the usesNonStrictEval - flag, which is new. Use a more specific test for whether a function - uses 'arguments', so we can avoid allocating, initializing, and tearing - off those registers in the common case. Distinguish between capturing - arguments and not, so we can avoid allocating space for arguments in - the torn-off object. - - We can make this even more general in the future, with some bytecode - generator refactoring. - - (JSC::BytecodeGenerator::resolve): Updated for new interface. - - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - (JSC::BytecodeGenerator::symbolTable): Updated some types. - - * heap/Heap.cpp: - (JSC::Heap::isValidAllocation): Allow large allocations, now that they - are both supported and used. - - * heap/Heap.h: - (Heap): Added a new form of allocateCell that specifies the full size - of the allocation, to allow for extra space on the end. - - * interpreter/CallFrame.h: - (JSC::ExecState::argumentOffset): - (JSC::ExecState::argumentOffsetIncludingThis): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): Refactored this code to be more - specific about tearing off 'arguments' vs activations. This is something - I forgot in my last patch, and it is required now that we can have - acitvations without 'arguments' registers. - - * runtime/Arguments.h: - (JSC::Arguments::setRegisters): No need for setRegisters anymore because - the activation object's storage doesn't change. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): Initialize our storage manually because - it's not declared to the C++ compiler. - - (JSC::JSActivation::visitChildren): No copyAndAppend because our storage - is not out-of-line anymore. - - (JSC::JSActivation::symbolTableGet): - (JSC::JSActivation::symbolTablePut): - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - (JSC::JSActivation::getOwnPropertySlot): - (JSC::JSActivation::getOwnPropertyDescriptor): - (JSC::JSActivation::argumentsGetter): Refactored isTornOff() testing to - avoid using a data member and to avoid hard-coding any offset assumptions. - - * runtime/JSActivation.h: - (JSC): - (JSActivation): - (JSC::JSActivation::create): - (JSC::JSActivation::isDynamicScope): - (JSC::JSActivation::captureStart): - (JSC::JSActivation::storageSize): - (JSC::JSActivation::storageSizeInBytes): - (JSC::JSActivation::registerOffset): - (JSC::JSActivation::tearOff): - (JSC::JSActivation::isTornOff): - (JSC::JSActivation::storage): - (JSC::JSActivation::allocationSize): - (JSC::JSActivation::isValid): New helper functions for doing the math - on our inline storage. Note that in the "AllOfTheThings" tear-off case, - the number of things is not known at compile time, so we store the - number in the argument count register. We can't just copy the raw contents - of the register beacuse we need a value that is safe for precise marking, - and the value in the register file has an invalid tag. - - * runtime/JSCell.h: - (JSC::allocateCell): New function for allocating with extra storage - on the end. - - * runtime/JSSymbolTableObject.h: - (JSC::JSSymbolTableObject::JSSymbolTableObject): - (JSC::JSSymbolTableObject::finishCreation): - * runtime/JSVariableObject.h: - (JSC::JSVariableObject::JSVariableObject): - (JSVariableObject): Make it easier for subclasses to use their symbol - tables during construction, by passing the table as a constructor argument. - - * runtime/SymbolTable.h: - (JSC::SharedSymbolTable::usesNonStrictEval): - (JSC::SharedSymbolTable::setUsesNonStrictEval): - (SharedSymbolTable): - (JSC::SharedSymbolTable::captureMode): - (JSC::SharedSymbolTable::setCaptureMode): - (JSC::SharedSymbolTable::captureStart): - (JSC::SharedSymbolTable::setCaptureStart): - (JSC::SharedSymbolTable::captureEnd): - (JSC::SharedSymbolTable::setCaptureEnd): - (JSC::SharedSymbolTable::parameterCountIncludingThis): - (JSC::SharedSymbolTable::setParameterCountIncludingThis): - (JSC::SharedSymbolTable::SharedSymbolTable): Added data members to more - precisely describe what kind of capture is in play, and to avoid having - data members in the activation. We expect N activations per symbol table, - so this can be a big savings in heavy closure usage. - -2012-09-11 Ryuan Choi <ryuan.choi@samsung.com> - - Fix build break with LLINT on 32bit machine after r128219 - https://bugs.webkit.org/show_bug.cgi?id=96461 - - Unreviewed build fix. - - * llint/LowLevelInterpreter32_64.asm: Fixed typo. - -2012-09-11 Michael Saboff <msaboff@apple.com> - - Build fixed for http://trac.webkit.org/changeset/128243 - - Rubber stamped by Stephanie Lewis. - - Added missing include file needed by 96422. - - * icu/unicode/unorm2.h: Added. - -2012-09-11 Michael Saboff <msaboff@apple.com> - - Build fixed for http://trac.webkit.org/changeset/128243 - - Rubber stamped by Stephanie Lewis. - - Added missing include file needed by 96422. - - * icu/unicode/ptypes.h: Added. - -2012-09-11 Michael Saboff <msaboff@apple.com> - - Update ICU header files to more recent version - https://bugs.webkit.org/show_bug.cgi?id=96422 - - Reviewed by Geoff Garen. - - Updated ICU header files to 4.6.1. Modifications made as part of the merge are: - platform.h - Changed ifndef / define / endif for U_HAVE_UINT8_T, U_HAVE_UINT16_T, U_HAVE_UINT32_T, - U_HAVE_UINT64_T, U_IS_BIG_ENDIAN and U_ENABLE_TRACING to match the existing platform.h - putil.h (line 132) - Changes defined(U_WINDOWS) to defined(WIN32) || defined(OS2) to match existing putil.h - ustring.h (line 945) - Wrapped macro argument cs with { (const UChar *)cs } to match existing ustring.h - utypes.h (line 545) - Changed defined(U_WINDOWS) to defined(WIN32) to match existing utypes.h - - * icu/unicode/localpointer.h: Added. - * icu/unicode/parseerr.h: - * icu/unicode/platform.h: - * icu/unicode/putil.h: - * icu/unicode/uchar.h: - * icu/unicode/ucnv.h: - * icu/unicode/ucnv_err.h: - * icu/unicode/ucol.h: - * icu/unicode/uconfig.h: - * icu/unicode/uenum.h: - * icu/unicode/uiter.h: - * icu/unicode/uloc.h: - * icu/unicode/umachine.h: - * icu/unicode/unorm.h: - * icu/unicode/urename.h: - * icu/unicode/uscript.h: - * icu/unicode/uset.h: - * icu/unicode/ustring.h: - * icu/unicode/utf.h: - * icu/unicode/utf16.h: - * icu/unicode/utf8.h: - * icu/unicode/utypes.h: - * icu/unicode/uvernum.h: Added. - * icu/unicode/uversion.h: - -2012-09-11 Matt Lilek <mrl@apple.com> - - OS X port should compile with newer versions of clang - https://bugs.webkit.org/show_bug.cgi?id=96434 - - m_identIsVarDecl is unused - remove it. - - Reviewed by Anders Carlsson. - - * parser/NodeConstructors.h: - (JSC::ForInNode::ForInNode): - * parser/Nodes.h: - (ForInNode): - -2012-09-11 Filip Pizlo <fpizlo@apple.com> - - LLInt should optimize and profile array length accesses - https://bugs.webkit.org/show_bug.cgi?id=96417 - - Reviewed by Oliver Hunt. - - This fixes the following hole in our array profiling strategy, where the array - is large (more than 1000 elements): - - for (var i = 0; i < array.length; ++i) ... - - The peeled use of array.length (in the array prologue) will execute only once - before DFG optimization kicks in from the loop's OSR point. Since it executed - only once, it executed in the LLInt. And prior to this patch, the LLInt did - not profile array.length accesses - so the DFG will assume, based on the lack - of profiling, that the access is in fact not an access to the JSArray length - property. That could then impede our ability to hoist the array structure - check, and may make us pessimistic in other ways as well, since the generic - GetById used for the array length access will be viewed as a side-effecting - operation. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::printGetByIdCacheStatus): - (JSC::CodeBlock::finalizeUnconditionally): - * bytecode/GetByIdStatus.cpp: - (JSC::GetByIdStatus::computeFromLLInt): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCapabilities.h: - (JSC::DFG::canCompileOpcode): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - (JSC::JIT::privateCompileSlowCases): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-09-11 Raphael Kubo da Costa <rakuco@webkit.org> - - [EFL] Rewrite the EFL-related Find modules - https://bugs.webkit.org/show_bug.cgi?id=95237 - - Reviewed by Kenneth Rohde Christiansen. - - * CMakeLists.txt: Stop setting the LINK_FLAGS property. - * PlatformEfl.cmake: Ditto. - * shell/PlatformEfl.cmake: Ditto. - -2012-09-11 Raphael Kubo da Costa <rakuco@webkit.org> - - [EFL] Unreviewed build fix after r128065. - - * CMakeLists.txt: Link against WTF for FastMalloc symbols, which - are needed when building with SYSTEM_MALLOC off. - -2012-09-10 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove m_classInfo from JSCell - https://bugs.webkit.org/show_bug.cgi?id=96311 - - Reviewed by Oliver Hunt. - - Now that no one is using the ClassInfo in JSCell, we can remove it for the greater good. This is a 1.5% win on v8v7 and - a 1.7% win on kraken, and is an overall performance progression. - - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Had to rearrange the order of when we take things off the free list - and when we store the Structure in the object because we would clobber the free list otherwise. This made it not okay for - the structure argument and the scratch register to alias one another. Also removed the store of the ClassInfo pointer in the - object. Yay! - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: Since it's no longer okay for for the scratch register and structure register to alias - one another as stated above, had to add an extra temporary for passing the Structure. - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: Ditto. - (JSC::DFG::SpeculativeJIT::compile): - * jit/JITInlineMethods.h: - (JSC::JIT::emitAllocateBasicJSObject): Similar changes to DFG's inline allocation except that it removed the object from - the free list first, so no changes were necessary there. - * llint/LowLevelInterpreter.asm: Change the constants for amount of inline storage to match PropertyOffset.h and remove - the store of the ClassInfo pointer during inline allocation. - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/JSCell.h: Remove the m_classInfo field and associated methods. - (JSCell): - * runtime/JSObject.h: - (JSObject): - * runtime/PropertyOffset.h: Expand the number of inline storage properties to take up the extra space that we're freeing - with the removal of the ClassInfo pointer. - (JSC): - * runtime/Structure.h: - (JSC): - (JSC::JSCell::JSCell): - (JSC::JSCell::finishCreation): - -2012-09-10 Geoffrey Garen <ggaren@apple.com> - - Added large allocation support to MarkedSpace - https://bugs.webkit.org/show_bug.cgi?id=96214 - - Originally reviewed by Oliver Hunt, then I added a design revision by - suggested by Phil Pizlo. - - I expanded the imprecise size classes to cover up to 32KB, then added - an mmap-based allocator for everything bigger. There's a lot of tuning - we could do in these size classes, but currently they're almost - completely unused, so I haven't done any tuning. - - Subtle point: the large allocator is a degenerate case of our free list - logic. Its list only ever contains zero or one items. - - * heap/Heap.h: - (JSC::Heap::allocateStructure): Pipe in size information. - - * heap/MarkedAllocator.cpp: - (JSC::MarkedAllocator::tryAllocateHelper): Handle the case where we - find a free item in the sweep list but the item isn't big enough. This - can happen in the large allocator because it mixes sizes. - - (JSC::MarkedAllocator::tryAllocate): - (JSC::MarkedAllocator::allocateSlowCase): More piping. - - (JSC::MarkedAllocator::allocateBlock): Handle the oversize case. - - (JSC::MarkedAllocator::addBlock): I moved the call to didAddBlock here - because it made more sense. - - * heap/MarkedAllocator.h: - (MarkedAllocator): - (JSC::MarkedAllocator::allocate): - * heap/MarkedSpace.cpp: - (JSC::MarkedSpace::MarkedSpace): - (JSC::MarkedSpace::resetAllocators): - (JSC::MarkedSpace::canonicalizeCellLivenessData): - (JSC::MarkedSpace::isPagedOut): - (JSC::MarkedSpace::freeBlock): - * heap/MarkedSpace.h: - (MarkedSpace): - (JSC::MarkedSpace::allocatorFor): - (JSC::MarkedSpace::destructorAllocatorFor): - (JSC::MarkedSpace::allocateWithoutDestructor): - (JSC::MarkedSpace::allocateWithDestructor): - (JSC::MarkedSpace::allocateStructure): - (JSC::MarkedSpace::forEachBlock): - * runtime/Structure.h: - (JSC::Structure): More piping. - -2012-09-10 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Windows (32-bit) build. - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_tear_off_arguments): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_tear_off_arguments): Get operands 1 and 2, not 1 and 1. :( - - Also took this opportunity to rename to indicate that these values are - not destinations anymore. - -2012-09-10 Geoffrey Garen <ggaren@apple.com> - - DFG misses arguments tear-off for function.arguments if 'arguments' is used - https://bugs.webkit.org/show_bug.cgi?id=96227 - - Reviewed by Gavin Barraclough. - - We've decided not to allow function.arguments to alias the local - 'arguments' object, or a local var or function named 'arguments'. - Aliasing complicates the implementation (cf, this bug) and can produce - surprising behavior for web programmers. - - Eliminating the aliasing has the side-effect of fixing this bug. - - The compatibilty story: function.arguments is deprecated, was never - specified, and throws an exception in strict mode, so we expect it to - disappear over time. Firefox does not alias to 'arguments'; Chrome - does, but not if you use eval or with; IE does; Safari did. - - * dfg/DFGByteCodeParser.cpp: Noticed a little cleanup while verifying - this code. Use the CodeBlock method for better encapsulation. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::retrieveArgumentsFromVMCode): Behavior change: don't - alias. - - * tests/mozilla/js1_4/Functions/function-001.js: - (TestFunction_4): Updated test expectations for changed behavior. - -2012-09-10 Filip Pizlo <fpizlo@apple.com> - - offlineasm has some impossible to implement, and unused, instructions - https://bugs.webkit.org/show_bug.cgi?id=96310 - - Reviewed by Mark Hahnenberg. - - * offlineasm/armv7.rb: - * offlineasm/instructions.rb: - * offlineasm/x86.rb: - -2012-09-09 Geoffrey Garen <ggaren@apple.com> - - Refactored op_tear_off* to support activations that don't allocate space for 'arguments' - https://bugs.webkit.org/show_bug.cgi?id=96231 - - Reviewed by Gavin Barraclough. - - This is a step toward smaller activations. - - As a side-effect, this patch eliminates a load and branch from the hot path - of activation tear-off by moving it to the cold path of arguments tear-off. Our - optimizing assumptions are that activations are common and that reifying the - arguments object is less common. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/Opcode.h: - (JSC::padOpcodeName): Updated for new opcode lengths. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): - (JSC::BytecodeGenerator::addConstantValue): Added support for JSValue() - in the bytecode, which we use when we have 'arguments' but no activation. - - (JSC::BytecodeGenerator::emitReturn): Always emit tear_off_arguments - if we've allocated the arguments registers. This allows tear_off_activation - not to worry about the arguments object anymore. - - Also, pass the activation and arguments values directly to these opcodes - instead of requiring the opcodes to infer the values through special - registers. This gives us more flexibility to move or eliminate registers. - - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGNode.h: - (Node): Updated for new opcode lengths. - - * dfg/DFGOperations.cpp: Activation tear-off doesn't worry about the - arguments object anymore. If 'arguments' is in use and reified, it's - responsible for aliasing back to the activation object in tear_off_arguments. - - * dfg/DFGOperations.h: - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Don't pass the arguments object to - activation tear-off; do pass the activation object to arguments tear-off. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): Ditto. - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_tear_off_activation): - (JSC::JIT::emit_op_tear_off_arguments): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_tear_off_activation): - (JSC::JIT::emit_op_tear_off_arguments): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: Same change in a few more execution engines. - -2012-09-10 Patrick Gansterer <paroga@webkit.org> - - [JSC] Use StringBuilder::appendNumber() instead of String::number() - https://bugs.webkit.org/show_bug.cgi?id=96236 - - Reviewed by Benjamin Poulain. - - * API/JSContextRef.cpp: - (JSContextCreateBacktrace): - -2012-09-06 Mark Hahnenberg <mhahnenberg@apple.com> - - Combine MarkStack and SlotVisitor into single class - https://bugs.webkit.org/show_bug.cgi?id=96043 - - Reviewed by Geoff Garen. - - Move all of MarkStack into SlotVisitor. The remaining stuff in MarkStack.cpp actually has to do - with MarkStack management/allocation. Cleaned up a few of the header files while I was at it. - * CMakeLists.txt: * GNUmakefile.list.am: + * JavaScriptCore.order: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: + * bytecode/BytecodeConventions.h: * bytecode/CodeBlock.cpp: - * dfg/DFGCommon.h: - * heap/GCThreadSharedData.cpp: - * heap/GCThreadSharedData.h: - (GCThreadSharedData): - * heap/HeapRootVisitor.h: - * heap/MarkStack.cpp: - (JSC): - * heap/MarkStack.h: - (JSC): - (MarkStackSegment): - (JSC::MarkStackSegment::data): - (JSC::MarkStackSegment::capacityFromSize): - (JSC::MarkStackSegment::sizeFromCapacity): - (MarkStackSegmentAllocator): - (MarkStackArray): - * heap/MarkStackInlineMethods.h: - (JSC::MarkStackArray::postIncTop): - (JSC): - (JSC::MarkStackArray::preDecTop): - (JSC::MarkStackArray::setTopForFullSegment): - (JSC::MarkStackArray::setTopForEmptySegment): - (JSC::MarkStackArray::top): - (JSC::MarkStackArray::validatePrevious): - (JSC::MarkStackArray::append): - (JSC::MarkStackArray::canRemoveLast): - (JSC::MarkStackArray::removeLast): - (JSC::MarkStackArray::isEmpty): - (JSC::MarkStackArray::size): - * heap/SlotVisitor.cpp: Added. - (JSC): - (JSC::SlotVisitor::SlotVisitor): - (JSC::SlotVisitor::~SlotVisitor): - (JSC::SlotVisitor::setup): - (JSC::SlotVisitor::reset): - (JSC::SlotVisitor::append): - (JSC::visitChildren): - (JSC::SlotVisitor::donateKnownParallel): - (JSC::SlotVisitor::drain): - (JSC::SlotVisitor::drainFromShared): - (JSC::SlotVisitor::mergeOpaqueRoots): - (JSC::SlotVisitor::startCopying): - (JSC::SlotVisitor::allocateNewSpaceSlow): - (JSC::SlotVisitor::allocateNewSpaceOrPin): - (JSC::JSString::tryHashConstLock): - (JSC::JSString::releaseHashConstLock): - (JSC::JSString::shouldTryHashConst): - (JSC::SlotVisitor::internalAppend): - (JSC::SlotVisitor::copyAndAppend): - (JSC::SlotVisitor::doneCopying): - (JSC::SlotVisitor::harvestWeakReferences): - (JSC::SlotVisitor::finalizeUnconditionalFinalizers): - (JSC::SlotVisitor::validate): - * heap/SlotVisitor.h: - (JSC): - (SlotVisitor): - (JSC::SlotVisitor::sharedData): - (JSC::SlotVisitor::isEmpty): - (JSC::SlotVisitor::visitCount): - (JSC::SlotVisitor::resetChildCount): - (JSC::SlotVisitor::childCount): - (JSC::SlotVisitor::incrementChildCount): - (ParallelModeEnabler): - (JSC::ParallelModeEnabler::ParallelModeEnabler): - (JSC::ParallelModeEnabler::~ParallelModeEnabler): - * heap/SlotVisitorInlineMethods.h: - (JSC::SlotVisitor::append): - (JSC): - (JSC::SlotVisitor::appendUnbarrieredPointer): - (JSC::SlotVisitor::appendUnbarrieredValue): - (JSC::SlotVisitor::internalAppend): - (JSC::SlotVisitor::addWeakReferenceHarvester): - (JSC::SlotVisitor::addUnconditionalFinalizer): - (JSC::SlotVisitor::addOpaqueRoot): - (JSC::SlotVisitor::containsOpaqueRoot): - (JSC::SlotVisitor::opaqueRootCount): - (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): - (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): - (JSC::SlotVisitor::donate): - (JSC::SlotVisitor::donateAndDrain): - * jit/JITWriteBarrier.h: - (JSC::SlotVisitor::append): - * jit/JumpReplacementWatchpoint.cpp: - * runtime/JSCell.h: - * runtime/Structure.h: - (JSC::SlotVisitor::internalAppend): - * runtime/WriteBarrier.h: - (JSC): - (JSC::SlotVisitor::append): - (JSC::SlotVisitor::appendValues): - * yarr/YarrJIT.cpp: - -2012-09-10 Hojong Han <hojong.han@samsung.com> - - [EFL] JIT memory usage is not retrieved - https://bugs.webkit.org/show_bug.cgi?id=96095 - - Reviewed by Geoffrey Garen. - - Fill JITBytes for EFL port. - - * runtime/MemoryStatistics.cpp: - (JSC::globalMemoryStatistics): - -2012-09-10 Thiago Marcos P. Santos <thiago.santos@intel.com> - - [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-10 Carlos Garcia Campos <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing files. - -2012-09-09 Mark Lam <mark.lam@apple.com> - - 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 <wtf/Assertions.h> 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-09 Patrick Gansterer <paroga@webkit.org> - - Add StringBuilder::appendNumber() and use it - https://bugs.webkit.org/show_bug.cgi?id=96030 - - Reviewed by Eric Seidel. - - Also fix a bunch of append() vs. appendLiteral() issues in the surrounding code. - - * API/JSContextRef.cpp: - (JSContextCreateBacktrace): - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * interpreter/Interpreter.h: - (JSC::StackFrame::toString): - -2012-09-09 Patrick Gansterer <paroga@webkit.org> - - Make the String initialization on the function side of String::number() - https://bugs.webkit.org/show_bug.cgi?id=95940 - - Reviewed by Benjamin Poulain. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-09-09 Geoffrey Garen <ggaren@apple.com> - - Rolled out <http://trac.webkit.org/changeset/127939> because it broke - fast/js/named-function-expression.html. - - Refactored bytecode generator initialization to support moving captured vars around - https://bugs.webkit.org/show_bug.cgi?id=96159 - - Reviewed by Gavin Barraclough. - -2012-09-08 Csaba Osztrogonác <ossy@webkit.org> - - LLInt buildfix for case sensitive filesystems - https://bugs.webkit.org/show_bug.cgi?id=96099 - - Reviewed by Michael Saboff. - - * llint/LowLevelInterpreter.cpp: Fix filenames. - -2012-09-07 Benjamin Poulain <bpoulain@apple.com> - - Rename the ustring() accessor to string() - https://bugs.webkit.org/show_bug.cgi?id=95919 - - Reviewed by Geoffrey Garen. - - Rename ustring() to string() to make the accessor name more logical after - r127191. - - * API/JSBase.cpp: - (JSEvaluateScript): - (JSCheckScriptSyntax): - * API/JSObjectRef.cpp: - (JSObjectMakeFunctionWithCallback): - (JSObjectMakeFunction): - (JSObjectCopyPropertyNames): - * API/JSProfilerPrivate.cpp: - (JSStartProfiling): - (JSEndProfiling): - * API/JSValueRef.cpp: - (JSValueMakeString): - (JSValueMakeFromJSONString): - * API/OpaqueJSString.cpp: - (OpaqueJSString::string): - * API/OpaqueJSString.h: - (OpaqueJSString): - * bytecode/CodeBlock.cpp: - (JSC::idName): - (JSC::CodeBlock::dump): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitLoad): - (JSC::BytecodeGenerator::addStringConstant): - * bytecompiler/NodesCodegen.cpp: - (JSC::RegExpNode::emitBytecode): - (JSC::processClauseList): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * jsc.cpp: - (GlobalObject::addFunction): - (GlobalObject::addConstructableFunction): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * parser/ASTBuilder.h: - (JSC::ASTBuilder::createRegExp): - * parser/Parser.cpp: - (JSC::::parsePrimaryExpression): - * parser/Parser.h: - (JSC::Scope::declareVariable): - (JSC::Scope::declareParameter): - (JSC::Scope::useVariable): - * parser/SyntaxChecker.h: - (JSC::SyntaxChecker::createRegExp): - * runtime/ExceptionHelpers.cpp: - (JSC::createUndefinedVariableError): - * runtime/Executable.cpp: - (JSC::FunctionExecutable::paramString): - * runtime/Executable.h: - (JSC::FunctionExecutable::finishCreation): - * runtime/FunctionPrototype.cpp: - (JSC::FunctionPrototype::addFunctionProperties): - * runtime/Identifier.h: - (JSC::Identifier::string): - * runtime/JSFunction.cpp: - (JSC::JSFunction::calculatedDisplayName): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - * runtime/JSONObject.cpp: - (JSC::PropertyNameForFunctionCall::value): - (JSC::Stringifier::Holder::appendNextProperty): - (JSC::Walker::walk): - * runtime/JSPropertyNameIterator.h: - (JSC::JSPropertyNameIterator::finishCreation): - * runtime/JSScope.cpp: - (JSC::JSScope::resolveBase): - * runtime/JSString.h: - (JSC::inlineJSValueNotStringtoString): - * runtime/LiteralParser.cpp: - (JSC::::parse): - * runtime/ObjectConstructor.cpp: - (JSC::ObjectConstructor::finishCreation): - (JSC::objectConstructorGetOwnPropertyNames): - (JSC::objectConstructorKeys): - * runtime/RegExpConstructor.cpp: - (JSC::RegExpConstructor::finishCreation): - -2012-09-07 Gavin Barraclough <barraclough@apple.com> - - CALLFRAME_OFFSET and EXCEPTION_OFFSET are same in ctiTrampoline on ARM Thumb2 - https://bugs.webkit.org/show_bug.cgi?id=82013 - - Reviewed by Geoff Garen. - - Neither of these values need to be stored. At all. - - * jit/JITStubs.cpp: - (JSC): - (JSC::ctiTrampoline): - (JSC::JITThunks::JITThunks): - - Nothing to see here. Move along. - -2012-09-07 Sheriff Bot <webkit.review.bot@gmail.com> - - 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 Geoffrey Garen <ggaren@apple.com> - - Refactored bytecode generator initialization to support moving captured vars around - https://bugs.webkit.org/show_bug.cgi?id=96159 - - Reviewed by Gavin Barraclough. - - This patch separates the stages of allocating registers, declaring identifiers - in the symbol table, and initializing registers, so you can change - allocation decisions without breaking the world. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): Call a set of helper functions - instead of inlining all the code, to help clarity. - - (JSC::BytecodeGenerator::allocateCapturedVars): - (JSC::BytecodeGenerator::allocateUncapturedVars): - (JSC::BytecodeGenerator::allocateActivationVar): - (JSC::BytecodeGenerator::allocateArgumentsVars): - (JSC::BytecodeGenerator::allocateCalleeVarUndeclared): - (JSC::BytecodeGenerator::declareParameters): - (JSC::BytecodeGenerator::declareCallee): - (JSC::BytecodeGenerator::initCalleeVar): - (JSC::BytecodeGenerator::initArgumentsVars): - (JSC::BytecodeGenerator::initActivationVar): - (JSC::BytecodeGenerator::initThisParameter): - (JSC::BytecodeGenerator::initFunctionDeclarations): - (JSC::BytecodeGenerator::declareParameter): - (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): - (JSC::BytecodeGenerator::createActivationIfNecessary): Factored these - helper functions out from pre-existing code. - - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * parser/ASTBuilder.h: - (JSC::ASTBuilder::createFuncDeclStatement): - (JSC::ASTBuilder::addVar): - * parser/Nodes.h: - (JSC::DeclarationStacks::VarDeclaration::VarDeclaration): - (VarDeclaration): - (JSC::DeclarationStacks::FunctionDeclaration::FunctionDeclaration): - (FunctionDeclaration): Declaration stacks get a little more data now, - to support allocating registers before putting things in the symbol - table. I'm convinced that we should eventually just expand the symbol - table to understand these things. - -2012-09-07 Mark Lam <mark.lam@apple.com> - - 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-07 Gavin Barraclough <barraclough@apple.com> - - Object.prototype.__define{G,S}etter__ with non-callable second parameter should throw TypeError instead of SyntaxError - https://bugs.webkit.org/show_bug.cgi?id=93873 - - Reviewed by Sam Weinig. - - * runtime/ObjectPrototype.cpp: - (JSC::objectProtoFuncDefineGetter): - - throw TypeError instead of SyntaxError - (JSC::objectProtoFuncDefineSetter): - - throw TypeError instead of SyntaxError - -2012-09-06 Mark Hahnenberg <mhahnenberg@apple.com> - - JSC should have a zombie mode - https://bugs.webkit.org/show_bug.cgi?id=96047 - - Reviewed by Geoffrey Garen. - - To aid clients of JSC while they are debugging memory issues, we should add a zombie - mode that scribbles into objects in the MarkedSpace after they are found to be dead - to prevent a sort of "use after free" situation. As a first cut we should support a - mode that just scribbles on objects prior to their being reused (i.e. while they are - "zombies") and a mode in which, in addition to scribbling on zombies, once an object - has been marked its mark bit will never be cleared, thus giving us "immortal" zombies. - - These two modes will be enabled through the use of environment variables. For now these - will be "JSZombieEnabled" and "JSImmortalZombieEnabled". Setting them to any value will - result in the use of the appropriate mode. - - * heap/Heap.cpp: - (JSC::Heap::collect): Zombifies dead objects at the end of collection if zombie mode is enabled. - (ZombifyCellFunctor): - (JSC::ZombifyCellFunctor::ZombifyCellFunctor): Sets marked bits for dead objects if in immortal mode and writes 0xbbadbeef into them. - (JSC::ZombifyCellFunctor::operator()): - (JSC): - (ZombifyBlockFunctor): - (JSC::ZombifyBlockFunctor::operator()): - (JSC::Heap::zombifyDeadObjects): Eagerly sweeps so that we don't write garbage into an object before it - is finalized/destroyed. - * heap/Heap.h: - (Heap): - * heap/MarkedBlock.h: - (MarkedBlock): - (JSC::MarkedBlock::forEachDeadCell): Used to iterate over dead cells at the end of collection if zombie mode is enabled. - (JSC): - * runtime/Options.cpp: - (JSC::Options::initialize): - * runtime/Options.h: - (JSC): - -2012-09-05 Geoffrey Garen <ggaren@apple.com> - - Rolled back in <http://trac.webkit.org/changeset/127698> with a fix for - fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html, which - is to make sure that function declarations don't put their names in scope. - - Reviewed by Gavin Barraclough. - - Named functions should not allocate scope objects for their names - https://bugs.webkit.org/show_bug.cgi?id=95659 - - Reviewed by Oliver Hunt. - -2012-09-06 Michael Saboff <msaboff@apple.com> - - 16 bit JSRopeString up converts an 8 bit fibers to 16 bits during resolution - https://bugs.webkit.org/show_bug.cgi?id=95810 - - Reviewed by Benjamin Poulain. - - Added 8 bit path that copies the contents of an 8 bit fiber to the 16 bit buffer - when resolving a 16 bit rope. - - * runtime/JSString.cpp: - (JSC::JSRopeString::resolveRopeSlowCase): - -2012-09-06 Gavin Barraclough <barraclough@apple.com> - - JS test suite puts incorrect limitations on Function.toString() - https://bugs.webkit.org/show_bug.cgi?id=3975 - - Reviewed by Geoff Garen. - - The result of function toString is implementation defined; - these test cases were looking for specific whitespace formatting - that matches mozilla's, and for redundant braces to be inserted - around if/else blocks. Stop that. - - * tests/mozilla/expected.html: - * tests/mozilla/js1_2/function/tostring-1.js: - (simplify): - - reduce whitespace differences - * tests/mozilla/js1_2/function/tostring-2.js: - (simplify): - - reduce whitespace differences - (TestOr): - (TestAnd): - - added braces to match expected output - -2012-09-06 Yuqiang Xian <yuqiang.xian@intel.com> - - Performance regressions on 32-bit platforms with revisions 125637 and 126387 - https://bugs.webkit.org/show_bug.cgi?id=95953 - - Reviewed by Filip Pizlo. - - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_get_by_val): Fix the typo. - -2012-09-05 Geoffrey Garen <ggaren@apple.com> - - Rolled out <http://trac.webkit.org/changeset/127698> because it broke - fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html - - Named functions should not allocate scope objects for their names - https://bugs.webkit.org/show_bug.cgi?id=95659 - - Reviewed by Oliver Hunt. - -2012-09-06 Mark Lam <mark.lam@apple.com> - - Renamed useYarrJIT() option to useRegExpJIT(). Also fixed regression in - which inadvertantly allows the ASM llint to use the baseline JIT when - useRegExpJIT() is true. - https://bugs.webkit.org/show_bug.cgi?id=95918. - - Reviewed by Geoffrey Garen. - - * runtime/JSGlobalData.cpp: - (JSC::enableAssembler): - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSC::JSGlobalData::canUseJIT): - (JSC::JSGlobalData::canUseRegExpJIT): - (JSGlobalData): - * runtime/Options.cpp: - (JSC::Options::initialize): - * runtime/Options.h: - (JSC): - -2012-09-06 Patrick Gansterer <paroga@webkit.org> - - Build fix for Interpreter after r127698. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - -2012-09-05 Geoffrey Garen <ggaren@apple.com> - - Named functions should not allocate scope objects for their names - https://bugs.webkit.org/show_bug.cgi?id=95659 - - Reviewed by Oliver Hunt. - - In most cases, we can merge a function expression's name into its symbol - table. This reduces memory footprint per closure from three objects - (function + activation + name scope) to two (function + activation), - speeds up closure allocation, and speeds up recursive calls. - - In the case of a named function expression that contains a non-strict - eval, the rules are so bat-poop crazy that I don't know how to model - them without an extra object. Since functions now default to not having - such an object, this case needs to allocate the object on function - entry. - - Therefore, this patch makes the slow case a bit slower so the fast case - can be faster and more memory-efficient. (Note that the slow case already - allocates an activation on entry, and until recently also allocated a - scope chain node on entry, so adding one allocation on entry shouldn't - break the bank.) - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): Caught a missed initializer. No behavior change. - + (JSC::CodeBlock::nameForRegister): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::alreadyInJSStack): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt32): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedCell): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedBoolean): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedDouble): + (JSC::ValueRecovery::displacedInJSStack): + (JSC::ValueRecovery::isAlreadyInJSStack): + (JSC::ValueRecovery::virtualRegister): + (JSC::ValueRecovery::dump): * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): Put the callee in static scope - during compilation so it doesn't need to be in dynamic scope at runtime. - (JSC::BytecodeGenerator::resolveCallee): - (JSC::BytecodeGenerator::addCallee): Helper functions for either statically - resolving the callee or adding a dynamic scope that will resolve to it, - depending on whether you're in the fast path. - - We move the callee into a var location if it's captured because activations - prefer to have contiguous ranges of captured variables. - + (JSC::BytecodeGenerator::emitCall): + (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::registerFor): - (BytecodeGenerator): - - * dfg/DFGOperations.cpp: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): This is the point of the patch: remove - one allocation in the case of a named function expression. - - * parser/Parser.cpp: - (JSC::::Parser): - * parser/Parser.h: - (JSC::Scope::declareCallee): - (Scope): - (Parser): - (JSC::parse): - * runtime/Executable.cpp: - (JSC::EvalExecutable::compileInternal): - (JSC::ProgramExecutable::checkSyntax): - (JSC::ProgramExecutable::compileInternal): - (JSC::FunctionExecutable::produceCodeBlockFor): - (JSC::FunctionExecutable::fromGlobalCode): Pipe the callee's name through - the parser so we get accurate information on whether the callee was captured. - - (JSC::FunctionExecutable::FunctionExecutable): - (JSC::EvalExecutable::compileInternal): - (JSC::ProgramExecutable::checkSyntax): - (JSC::ProgramExecutable::compileInternal): - (JSC::FunctionExecutable::produceCodeBlockFor): - (JSC::FunctionExecutable::fromGlobalCode): - * runtime/Executable.h: - (JSC::FunctionExecutable::create): - (FunctionExecutable): - (JSC::FunctionExecutable::finishCreation): I had to refactor function - creation to support the following function constructor quirk: the function - gets a name, but its name is not in lexical scope. - - To simplify this, FunctionExecutable now automatically extracts all the - data it needs from the parsed node. The special "fromGlobalCode" path - used by the function constructor creates an anonymous function, and then - quirkily sets the value used by the .name property to be non-null, even - though the parsed name is null. - - * runtime/JSNameScope.h: - (JSC::JSNameScope::create): - (JSC::JSNameScope::JSNameScope): Added support for explicitly specifying - your container scope. The compiler uses this for named function expressions. - -2012-09-05 Gavin Barraclough <barraclough@apple.com> - - a = data[a]++; sets the wrong key in data - https://bugs.webkit.org/show_bug.cgi?id=91270 - - Reviewed by Oliver Hunt. - - Postfix inc/dec is unsafely using finalDestination, can trample base/subscript prior to the result being put. - - * bytecompiler/NodesCodegen.cpp: - (JSC::PostfixNode::emitResolve): - - Remove redundant parens. - (JSC::PostfixNode::emitBracket): - (JSC::PostfixNode::emitDot): - - Refactored to use tempDestination instead of finalDestination. - (JSC::PrefixNode::emitBracket): - (JSC::PrefixNode::emitDot): - - Should be using emitPreIncOrDec. - -2012-09-05 Gavin Barraclough <barraclough@apple.com> - - Bug, assignment within subscript of prefix/postfix increment of bracket access - https://bugs.webkit.org/show_bug.cgi?id=95913 - - Reviewed by Oliver Hunt. - - javascript:alert((function(){ var a = { x:1 }; var b = { x:1 }; a[a=b,"x"]++; return a.x; })()) - - * bytecompiler/NodesCodegen.cpp: - (JSC::PostfixNode::emitBracket): - (JSC::PrefixNode::emitBracket): - - Should check for assigments in the subscript when loading the base. - * parser/Nodes.h: - (JSC::BracketAccessorNode::subscriptHasAssignments): - (BracketAccessorNode): - - Used by emitBracket methods. - -2012-09-05 Gavin Barraclough <barraclough@apple.com> - - Merge prefix/postfix nodes - https://bugs.webkit.org/show_bug.cgi?id=95898 - - Reviewed by Geoff Garen. - - Simplify the AST. - This will also mean we have access to m_subscriptHasAssignments when generating a prefix/postfix op applied to a bracket access. - - * bytecompiler/NodesCodegen.cpp: - (JSC::PostfixNode::emitResolve): - - was PostfixResolveNode::emitBytecode - (JSC::PostfixNode::emitBracket): - - was PostfixBracketNode::emitBytecode - (JSC::PostfixNode::emitDot): - - was PostfixDotNode::emitBytecode - (JSC::PostfixNode::emitBytecode): - - was PostfixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate. - (JSC::PrefixNode::emitResolve): - - was PrefixResolveNode::emitBytecode - (JSC::PrefixNode::emitBracket): - - was PrefixBracketNode::emitBytecode - (JSC::PrefixNode::emitDot): - - was PrefixDotNode::emitBytecode - (JSC::PrefixNode::emitBytecode): - - was PrefixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate. - * parser/ASTBuilder.h: - (JSC::ASTBuilder::makePrefixNode): - - Just makes a PrefixNode! - (JSC::ASTBuilder::makePostfixNode): - - Just makes a PostfixNode! - * parser/NodeConstructors.h: - (JSC::PostfixNode::PostfixNode): - - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode. - (JSC::PrefixNode::PrefixNode): - - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode. - * parser/Nodes.h: - (PostfixNode): - - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode. - (PrefixNode): - - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode. - -2012-09-05 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove use of JSCell::classInfoOffset() from tryCacheGetByID - https://bugs.webkit.org/show_bug.cgi?id=95860 - - Reviewed by Oliver Hunt. - - We should just do the indirection through the Structure instead. - - * dfg/DFGRepatch.cpp: - (JSC::DFG::tryCacheGetByID): - -2012-09-05 Geoffrey Garen <ggaren@apple.com> - - Throw exceptions when assigning to const in strict mode - https://bugs.webkit.org/show_bug.cgi?id=95894 - - Reviewed by Oliver Hunt. - - Currently, this never happens; but it will start happening once the - callee is a local const register. In this patch, there's no change in - behavior. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): Helper function - for doing the throwing. - * bytecompiler/BytecodeGenerator.h: - - * bytecompiler/NodesCodegen.cpp: - (JSC::PostfixResolveNode::emitBytecode): - (JSC::PrefixResolveNode::emitBytecode): - (JSC::ReadModifyResolveNode::emitBytecode): - (JSC::AssignResolveNode::emitBytecode): Call the helper function. - -2012-09-05 Geoffrey Garen <ggaren@apple.com> - - Refactored callee access in the DFG to support it in the general case - https://bugs.webkit.org/show_bug.cgi?id=95887 - - Reviewed by Phil Pizlo and Gavin Barraclough. - - To support named function expressions, the DFG needs to understand the - callee register being used in arbitrary expressions, and not just - create_this. - + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): + (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader): + (JSC::DFG::AssemblyHelpers::emitPutImmediateToCallFrameHeader): * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getDirect): - (JSC::DFG::ByteCodeParser::getCallee): Remap access to the callee register - into a GetCallee node. Otherwise, we get confused and think we have a - negatively indexed argument. - - (ByteCodeParser): - (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): Inlining also - needs to remap, but to the callee in the inline frame, and not the caller's - callee. - - (JSC::DFG::ByteCodeParser::parseBlock): Since we support the callee in - the general case now, there's no need to handle it in a special way for - create_this. - -2012-09-05 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove use of JSCell::classInfoOffset() from virtualForThunkGenerator - https://bugs.webkit.org/show_bug.cgi?id=95821 - - Reviewed by Oliver Hunt. - - We can replace the load of the ClassInfo from the object with a load from the Structure. - - * dfg/DFGThunks.cpp: - (JSC::DFG::virtualForThunkGenerator): - -2012-09-05 Benjamin Poulain <bpoulain@apple.com> - - Fix the uses of String::operator+=() for Mac - https://bugs.webkit.org/show_bug.cgi?id=95818 - - Reviewed by Dan Bernstein. - - * jsc.cpp: - (functionJSCStack): Use StringBuilder to create the stack dump, it is faster - and avoid String::operator+=(). - - * parser/Parser.h: - (JSC::Parser::updateErrorMessageSpecialCase): - (JSC::Parser::updateErrorMessage): - (JSC::Parser::updateErrorWithNameAndMessage): - Use the String operators (and makeString) to concatenate the strings. - -2012-09-05 Gabor Rapcsanyi <rgabor@webkit.org> - - DFG JIT doesn't work properly on ARM hardfp - https://bugs.webkit.org/show_bug.cgi?id=95684 - - Reviewed by Filip Pizlo. - - Add hardfp support to DFG JIT. The patch is created with the - help of Zoltan Herczeg. - - * dfg/DFGCCallHelpers.h: - (CCallHelpers): - (JSC::DFG::CCallHelpers::setupArguments): - * dfg/DFGFPRInfo.h: - (FPRInfo): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): - (JSC::DFG::SpeculativeJIT::appendCallSetResult): - -2012-09-04 Mark Lam <mark.lam@apple.com> - - Allow the YarrJIT to use the assembler even when useJIT() is false. - Introduce the useYarrJIT() option. - https://bugs.webkit.org/show_bug.cgi?id=95809. - - Reviewed by Geoffrey Garen. - - * runtime/JSGlobalData.cpp: - (JSC::enableAssembler): - * runtime/Options.cpp: - (JSC::Options::initialize): - * runtime/Options.h: - (JSC): - -2012-09-04 Gavin Barraclough <barraclough@apple.com> - - inc/dec behave incorrectly operating on a resolved const - https://bugs.webkit.org/show_bug.cgi?id=95815 - - Reviewed by Geoff Garen. - - There are two bugs here. - - (1) When the value being incremented is const, and the result is ignored, we assume this cannot be observed, and emit no code. - However if the value being incremented is not a primitive & has a valueOf conversion, then this should be being called. - - (2) In the case of a pre-increment of a const value where the result is not ignored, we'll move +/-1 to the destination, then - add the resolved const value being incremented to this. This is problematic if the destination is a local, and the const - value being incremented has a valueOf conversion that throws - the destination will be modified erroneously. Instead, we - need to use a temporary location. - - * bytecompiler/NodesCodegen.cpp: - (JSC::PostfixResolveNode::emitBytecode): - (JSC::PrefixResolveNode::emitBytecode): - - always at least perform a toNumber conversion, use tempDestination when reducing inc/dec to an add +/-1. - -2012-09-04 Filip Pizlo <fpizlo@apple.com> - - DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound - https://bugs.webkit.org/show_bug.cgi?id=95717 - - Reviewed by Oliver Hunt. - - Rolling back in after fixing the negative index case. - - Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already - there so we should just use it! - - * bytecode/DFGExitProfile.h: - (JSC::DFG::exitKindToString): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * 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-09-04 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r127503. - http://trac.webkit.org/changeset/127503 - https://bugs.webkit.org/show_bug.cgi?id=95788 - - broke some tests (fast/js/dfg-negative-array-index, fast/js - /dfg-put-by-val-setter-then-get-by-val) (Requested by thorton - on #webkit). - - * bytecode/DFGExitProfile.h: - (JSC::DFG::exitKindToString): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * 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::ByteCodeParser::getDirect): + (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): + (JSC::DFG::ByteCodeParser::addCall): + (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGGenerationInfo.h: + (GenerationInfo): + (JSC::DFG::GenerationInfo::needsSpill): + * dfg/DFGGraph.h: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compileEntry): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::beginCall): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryBuildGetByIDList): + * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compile): - -2012-09-04 Benjamin Poulain <bpoulain@apple.com> - - Improve JSC use of Strings after the UString->String change - https://bugs.webkit.org/show_bug.cgi?id=95633 - - Reviewed by Geoffrey Garen. - - This patch improve the use of strings in the JSC runtime. - - The initialization of Identifier is left for future patches. - - The improvements are the following: - -5% faster to raise one of the modified exception. - -3 times faster to execute Boolean::toString() - - Most of the changes are just about using the new methods - for string literals. - - With the changes, the binary on x86_64 gets 176 bytes smaller. - - * API/JSCallbackObjectFunctions.h: - (JSC::::staticFunctionGetter): - (JSC::::callbackGetter): - * API/JSContextRef.cpp: - (JSContextCreateBacktrace): - * API/JSObjectRef.cpp: - (JSObjectMakeFunctionWithCallback): - * bytecode/CodeBlock.cpp: - (JSC::valueToSourceString): - (JSC::CodeBlock::nameForRegister): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::addStackTraceIfNecessary): - * runtime/ArrayConstructor.cpp: - (JSC::constructArrayWithSizeQuirk): - * runtime/ArrayPrototype.cpp: - (JSC::shift): - (JSC::unshift): - (JSC::arrayProtoFuncPop): - (JSC::arrayProtoFuncReverse): - * runtime/BooleanPrototype.cpp: - (JSC::booleanProtoFuncToString): Instead of instanciating new strings, reuse the - keywords available in SmallStrings. Avoiding the creation of the JSString and StringImpl - makes the method significantly faster. - - * runtime/DateConversion.cpp: - (JSC::formatDateTime): - * runtime/DatePrototype.cpp: - (JSC::formatLocaleDate): - (JSC::formateDateInstance): - (JSC::dateProtoFuncToISOString): - Change the way we use snprintf() for clarity and performance. - - Instead of allocating one extra byte to put a zero "just in case", we use the size returned - by snprintf(). - To prevent any overflow from a programming mistake, we explicitely test for overflow and - return an empty string. - - (JSC::dateProtoFuncToJSON): - * runtime/Error.cpp: - (JSC::createNotEnoughArgumentsError): - (JSC::throwTypeError): - (JSC::throwSyntaxError): - * runtime/Error.h: - (JSC::StrictModeTypeErrorFunction::create): - * runtime/ErrorPrototype.cpp: - (JSC::ErrorPrototype::finishCreation): - (JSC::errorProtoFuncToString): - Using a null String is correct because (8) uses jsString(), (9) tests for a length of 0. - - * runtime/ExceptionHelpers.cpp: - (JSC::InterruptedExecutionError::defaultValue): - (JSC::TerminatedExecutionError::defaultValue): - (JSC::createStackOverflowError): - (JSC::createOutOfMemoryError): - * runtime/Executable.cpp: - (JSC::EvalExecutable::compileInternal): - (JSC::FunctionExecutable::paramString): - * runtime/FunctionConstructor.cpp: - (JSC::constructFunction): - (JSC::constructFunctionSkippingEvalEnabledCheck): - * runtime/FunctionPrototype.h: - (JSC::FunctionPrototype::create): - Using a null String for the name is correct because InternalFunction uses jsString() - to create the name value. - - * runtime/InternalFunction.cpp: - (JSC::InternalFunction::finishCreation): - There is no need to create an empty string for a null string, jsString() handle both - cases as empty JSString. - - * runtime/JSArray.cpp: - (JSC::reject): - (JSC::SparseArrayValueMap::put): - (JSC::JSArray::put): - (JSC::JSArray::putByIndexBeyondVectorLength): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - (JSC::JSArray::setLength): - (JSC::JSArray::pop): - (JSC::JSArray::push): - * runtime/JSFunction.cpp: - (JSC::JSFunction::finishCreation): Same issue as InternalFunction::finishCreation. - - (JSC::JSFunction::callerGetter): - (JSC::JSFunction::defineOwnProperty): - * runtime/JSGlobalData.cpp: - (JSC::enableAssembler): Use CFSTR() instead of CFStringCreateWithCString(). - CFStringCreateWithCString() copy the content and may choose to decode the data. - CFSTR() is much more efficient. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - JSFunction uses jsString() to create the name, we can use null strings instead - of creating empty strings. - - (JSC::JSGlobalObject::createThrowTypeError): ditto. - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::encode): - (JSC::decode): - (JSC::globalFuncEval): - * runtime/JSONObject.cpp: - (JSC::Stringifier::appendStringifiedValue): - (JSC::Stringifier::Holder::appendNextProperty): - (JSC::JSONProtoFuncParse): - (JSC::JSONProtoFuncStringify): - * runtime/JSObject.cpp: - (JSC::JSObject::put): - (JSC::JSObject::defaultValue): - (JSC::JSObject::hasInstance): - (JSC::JSObject::defineOwnProperty): - * runtime/JSString.cpp: - Return an empty JSString to avoid the creation of a temporary empty String. - - (JSC::JSRopeString::getIndexSlowCase): - * runtime/JSString.h: - (JSC): Remove the versions of jsNontrivialString() taking a char*. All the callers - have been replaced by calls using ASCIILiteral. - - * runtime/JSValue.cpp: - (JSC::JSValue::putToPrimitive): - * runtime/LiteralParser.cpp: - (JSC::::Lexer::lex): - (JSC::::Lexer::lexString): - (JSC::::Lexer::lexNumber): - (JSC::::parse): - * runtime/LiteralParser.h: - (JSC::LiteralParser::getErrorMessage): - * runtime/NumberPrototype.cpp: - (JSC::numberProtoFuncToExponential): - (JSC::numberProtoFuncToFixed): - (JSC::numberProtoFuncToPrecision): - (JSC::numberProtoFuncToString): - * runtime/ObjectConstructor.cpp: - (JSC::objectConstructorGetPrototypeOf): - (JSC::objectConstructorGetOwnPropertyDescriptor): - (JSC::objectConstructorGetOwnPropertyNames): - (JSC::objectConstructorKeys): - (JSC::toPropertyDescriptor): - (JSC::objectConstructorDefineProperty): - (JSC::objectConstructorDefineProperties): - (JSC::objectConstructorCreate): - (JSC::objectConstructorSeal): - (JSC::objectConstructorFreeze): - (JSC::objectConstructorPreventExtensions): - (JSC::objectConstructorIsSealed): - (JSC::objectConstructorIsFrozen): - (JSC::objectConstructorIsExtensible): - * runtime/ObjectPrototype.cpp: - (JSC::objectProtoFuncDefineGetter): - (JSC::objectProtoFuncDefineSetter): - (JSC::objectProtoFuncToString): - * runtime/RegExpConstructor.cpp: - (JSC::constructRegExp): - * runtime/RegExpObject.cpp: - (JSC::reject): - (JSC::regExpObjectSource): - * runtime/RegExpPrototype.cpp: - (JSC::regExpProtoFuncCompile): - * runtime/StringObject.cpp: - (JSC::StringObject::defineOwnProperty): - * runtime/StringPrototype.cpp: - (JSC::jsSpliceSubstrings): - (JSC::jsSpliceSubstringsWithSeparators): - -2012-09-04 Filip Pizlo <fpizlo@apple.com> - - DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound - https://bugs.webkit.org/show_bug.cgi?id=95717 - - Reviewed by Oliver Hunt. - - Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already - there so we should just use it! - - * bytecode/DFGExitProfile.h: - (JSC::DFG::exitKindToString): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::spill): * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): - -2012-09-04 Zoltan Horvath <zoltan@webkit.org> - - Extend the coverage of the Custom Allocation Framework in WTF and in JavaScriptCore - https://bugs.webkit.org/show_bug.cgi?id=95737 - - Reviewed by Eric Seidel. - - Add WTF_MAKE_FAST_ALLOCATED macro to the following class declarations because these are instantiated by operator new. - - * wtf/CryptographicallyRandomNumber.cpp: CryptographicallyRandomNumber is instantiated at wtf/CryptographicallyRandomNumber.cpp:162. - - * heap/MachineStackMarker.cpp: - (MachineThreads::Thread): Thread is instantiated at heap/MachineStackMarker.cpp:196. - * jit/ExecutableAllocatorFixedVMPool.cpp: - (FixedVMPoolExecutableAllocator): FixedVMPoolExecutableAllocator is instantiated at jit/ExecutableAllocatorFixedVMPool.cpp:111 - * parser/SourceProviderCache.h: - (SourceProviderCache): SourceProviderCache is instantiated at parser/SourceProvider.h:49. - * parser/SourceProviderCacheItem.h: - (SourceProviderCacheItem): SourceProviderCacheItem is instantiated at parser/Parser.cpp:843. - * runtime/GCActivityCallback.h: - (GCActivityCallback): GCActivityCallback is instantiated at runtime/GCActivityCallback.h:96. - * tools/CodeProfile.h: - (CodeProfile): CodeProfile is instantiated at JavaScriptCore/tools/CodeProfiling.cpp:140. - -2012-09-04 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove uses of ClassInfo from SpeculativeJIT::compileObjectOrOtherLogicalNot - https://bugs.webkit.org/show_bug.cgi?id=95510 - - Reviewed by Oliver Hunt. - - More refactoring to get rid of ClassInfo checks in the DFG. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): - (JSC::DFG::SpeculativeJIT::compileLogicalNot): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): - (JSC::DFG::SpeculativeJIT::compileLogicalNot): - -2012-09-03 Patrick Gansterer <paroga@webkit.org> - - Unreviewed. Build fix for ENABLE(CLASSIC_INTERPRETER) after r127393. - - * interpreter/Interpreter.h: - -2012-09-02 Geoffrey Garen <ggaren@apple.com> - - Fixed failures seen on Linux bots. - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_push_with_scope): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_push_with_scope): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * jit/JITStubs.h: push_*_scope doesn't have a destination operand anymore. - Accordingly, update these places in the baseline JIT, which I missed in my last patch. - -2012-09-02 Geoffrey Garen <ggaren@apple.com> - - Refactored scope chain opcodes to support optimization for named function expressions - https://bugs.webkit.org/show_bug.cgi?id=95658 - - Reviewed by Sam Weinig. - - Renamed - push_scope => push_with_scope - push_new_scope => push_name_scope - to clarify the difference between them. - - Changed push_with_scope and push_name_scope not to save the new scope in - a temporary register, since doing so made optimization harder. - - (The old behavior was a hold-over from when the scope chain wasn't - a GC object, and wouldn't be marked otherwise. Now, the scope chain is - marked because it is a GC object pointed to by the call frame.) - - Changed push_name_scope to accept an operand specifying the attributes - for the named property, instead of assuming DontDelete, because a named - function expression needs ReadOnly|DontDelete. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::highestUsedRegister): Removed this function, - which used to be related to preserving saved scope object temporaries, - because it had no callers. - -2012-09-01 Geoffrey Garen <ggaren@apple.com> - - Rolled back out a piece of <http://trac.webkit.org/changeset/127293> - because it broke inspector tests on Windows. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - -2012-09-01 Mark Lam <mark.lam@apple.com> - - 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): + * dfg/DFGThunks.cpp: + (JSC::DFG::throwExceptionFromCallSlowPathGenerator): + (JSC::DFG::slowPathFor): + (JSC::DFG::virtualForThunkGenerator): + * dfg/DFGValueSource.cpp: + (JSC::DFG::ValueSource::dump): + * dfg/DFGValueSource.h: + (JSC::DFG::dataFormatToValueSourceKind): + (JSC::DFG::valueSourceKindToDataFormat): + (JSC::DFG::isInJSStack): + (JSC::DFG::ValueSource::forSpeculation): + (JSC::DFG::ValueSource::isInJSStack): + (JSC::DFG::ValueSource::valueRecovery): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + * heap/Heap.cpp: + (JSC::Heap::stack): + (JSC::Heap::getConservativeRegisterRoots): + (JSC::Heap::markRoots): + * heap/Heap.h: + (JSC): + (Heap): + * interpreter/CallFrame.cpp: + (JSC::CallFrame::stack): + * interpreter/CallFrame.h: + (JSC::ExecState::calleeAsValue): + (JSC::ExecState::callee): + (JSC::ExecState::codeBlock): + (JSC::ExecState::scope): + (JSC::ExecState::callerFrame): + (JSC::ExecState::returnPC): + (JSC::ExecState::hasReturnPC): + (JSC::ExecState::clearReturnPC): + (JSC::ExecState::bytecodeOffsetForNonDFGCode): + (JSC::ExecState::setBytecodeOffsetForNonDFGCode): + (JSC::ExecState::inlineCallFrame): + (JSC::ExecState::codeOriginIndexForDFG): + (JSC::ExecState::currentVPC): + (JSC::ExecState::setCurrentVPC): + (JSC::ExecState::setCallerFrame): + (JSC::ExecState::setScope): + (JSC::ExecState::init): + (JSC::ExecState::argumentCountIncludingThis): + (JSC::ExecState::offsetFor): + (JSC::ExecState::setArgumentCountIncludingThis): + (JSC::ExecState::setCallee): + (JSC::ExecState::setCodeBlock): + (JSC::ExecState::setReturnPC): + (JSC::ExecState::setInlineCallFrame): + (ExecState): * interpreter/Interpreter.cpp: + (JSC::Interpreter::slideRegisterWindowForCall): + (JSC::eval): + (JSC::loadVarargs): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::throwException): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): - (JSC): + (JSC::Interpreter::prepareForRepeatCall): + (JSC::Interpreter::endRepeatCall): * 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::Interpreter::stack): + (Interpreter): + (JSC::Interpreter::execute): (JSC): - (JSC::JSValue::JSValue): - * runtime/Options.cpp: - (JSC::Options::initialize): - -2012-09-01 Geoffrey Garen <ggaren@apple.com> - - Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * runtime/JSActivation.h: - (JSActivation): - -2012-09-01 Geoffrey Garen <ggaren@apple.com> - - Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - (JSC::JSGlobalObject::setGlobalThis): + * interpreter/JSStack.cpp: Copied from Source/JavaScriptCore/interpreter/RegisterFile.cpp. + (JSC::stackStatisticsMutex): + (JSC::JSStack::~JSStack): + (JSC::JSStack::growSlowCase): + (JSC::JSStack::gatherConservativeRoots): + (JSC::JSStack::releaseExcessCapacity): + (JSC::JSStack::initializeThreading): + (JSC::JSStack::committedByteCount): + (JSC::JSStack::addToCommittedByteCount): + * interpreter/JSStack.h: Copied from Source/JavaScriptCore/interpreter/RegisterFile.h. + (JSStack): + (JSC::JSStack::JSStack): + (JSC::JSStack::shrink): + (JSC::JSStack::grow): + * interpreter/RegisterFile.cpp: Removed. + * interpreter/RegisterFile.h: Removed. + * interpreter/VMInspector.cpp: + (JSC::VMInspector::dumpFrame): + * jit/JIT.cpp: + (JSC::JIT::JIT): + (JSC::JIT::privateCompile): + * jit/JIT.h: (JSC): - (JSC::JSGlobalObject::visitChildren): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSScope::globalThis): + (JIT): + * jit/JITCall.cpp: + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEval): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEval): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCall): + * jit/JITCode.h: (JSC): - (JSC::JSGlobalObject::globalThis): - * runtime/JSNameScope.h: - (JSC::JSNameScope::JSNameScope): - * runtime/JSScope.cpp: - (JSC::JSScope::visitChildren): - * runtime/JSScope.h: - (JSScope): - (JSC::JSScope::JSScope): - (JSC::JSScope::globalObject): - (JSC::JSScope::globalData): - * runtime/JSSegmentedVariableObject.h: - (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): - * runtime/JSSymbolTableObject.h: - (JSC::JSSymbolTableObject::JSSymbolTableObject): - * runtime/JSVariableObject.h: - (JSC::JSVariableObject::JSVariableObject): - * runtime/JSWithScope.h: - (JSC::JSWithScope::JSWithScope): - * runtime/StrictEvalActivation.cpp: - (JSC::StrictEvalActivation::StrictEvalActivation): - -2012-09-01 Geoffrey Garen <ggaren@apple.com> - - Rolled back out a piece of <http://trac.webkit.org/changeset/127293> - because it broke Window inspector tests. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * runtime/JSActivation.h: - (JSActivation): - -2012-08-31 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, attempt to fix Windows, take two. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-31 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, attempt to fix Windows. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-31 Filip Pizlo <fpizlo@apple.com> - - JSArray::putDirectIndex should by default behave like JSObject::putDirect - https://bugs.webkit.org/show_bug.cgi?id=95630 - - Reviewed by Gavin Barraclough. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * jsc.cpp: - (GlobalObject::finishCreation): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * runtime/JSArray.cpp: - (JSC::SparseArrayValueMap::putDirect): - (JSC::JSArray::defineOwnNumericProperty): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - * runtime/JSArray.h: - (SparseArrayValueMap): - (JSArray): - (JSC::JSArray::putDirectIndex): - * runtime/JSONObject.cpp: - (JSC::Walker::walk): - * runtime/RegExpMatchesArray.cpp: - (JSC::RegExpMatchesArray::reifyAllProperties): - (JSC::RegExpMatchesArray::reifyMatchProperty): - * runtime/StringPrototype.cpp: - (JSC::splitStringByOneCharacterImpl): - (JSC::stringProtoFuncSplit): - -2012-08-31 Geoffrey Garen <ggaren@apple.com> - - Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): - * runtime/JSNameScope.h: - (JSC::JSNameScope::JSNameScope): - * runtime/JSWithScope.h: - (JSC::JSWithScope::JSWithScope): - * runtime/StrictEvalActivation.cpp: - (JSC::StrictEvalActivation::StrictEvalActivation): - -2012-08-31 Geoffrey Garen <ggaren@apple.com> - - Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): + (JSC::JITCode::execute): + * jit/JITInlineMethods.h: + (JSC::JIT::emitPutToCallFrameHeader): + (JSC::JIT::emitPutCellToCallFrameHeader): + (JSC::JIT::emitPutIntToCallFrameHeader): + (JSC::JIT::emitPutImmediateToCallFrameHeader): + (JSC::JIT::emitGetFromCallFrameHeaderPtr): + (JSC::JIT::emitGetFromCallFrameHeader32): + (JSC::JIT::updateTopCallFrame): + (JSC::JIT::unmap): * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_end): + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emit_op_get_arguments_length): + (JSC::JIT::emit_op_get_argument_by_val): (JSC::JIT::emit_op_resolve_global_dynamic): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (JSC::JSGlobalObject::visitChildren): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::withScopeStructure): - (JSC::JSGlobalObject::strictEvalActivationStructure): - (JSC::JSGlobalObject::activationStructure): - (JSC::JSGlobalObject::nameScopeStructure): - -2012-08-31 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove use of ClassInfo in SpeculativeJIT::emitBranch - https://bugs.webkit.org/show_bug.cgi?id=95623 - - Reviewed by Filip Pizlo. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): - (JSC::DFG::SpeculativeJIT::emitBranch): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): - (JSC::DFG::SpeculativeJIT::emitBranch): - -2012-08-31 Geoffrey Garen <ggaren@apple.com> - - Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - * heap/MarkedBlock.cpp: - (JSC::MarkedBlock::MarkedBlock): - * heap/MarkedBlock.h: - (MarkedBlock): - (JSC::MarkedBlock::globalData): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_end): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emit_op_get_arguments_length): + (JSC::JIT::emit_op_get_argument_by_val): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC::JIT::emit_op_put_scoped_var): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC::JIT::emit_op_put_scoped_var): + * jit/JITStubs.cpp: + (JSC::ctiTrampoline): + (JSC::JITThunks::JITThunks): (JSC): - * heap/WeakSet.cpp: - (JSC::WeakSet::addAllocator): - * heap/WeakSet.h: - (WeakSet): - (JSC::WeakSet::WeakSet): - (JSC::WeakSet::globalData): - * runtime/JSGlobalData.h: - (JSC::WeakSet::heap): + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: (JSC): - -2012-08-31 Mark Lam <mark.lam@apple.com> - - 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. + (JITStackFrame): + * jit/JSInterfaceJIT.h: + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::SpecializedThunkJIT): + (JSC::SpecializedThunkJIT::returnJSValue): + (JSC::SpecializedThunkJIT::returnDouble): + (JSC::SpecializedThunkJIT::returnInt32): + (JSC::SpecializedThunkJIT::returnJSCell): + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::setUpCall): Use ExecutableBase's hostCodeEntry() - jsCodeEntryFor(), and jsCodeWithArityCheckEntryFor() for computing - the entry points to functions being called. + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::genericCall): * 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-31 Tony Chang <tony@chromium.org> - - Remove ENABLE_CSS3_FLEXBOX compile time flag - https://bugs.webkit.org/show_bug.cgi?id=95382 - - Reviewed by Ojan Vafai. - - Everyone is already enabling this by default and the spec has stablized. - - * Configurations/FeatureDefines.xcconfig: - -2012-08-31 Geoffrey Garen <ggaren@apple.com> - - Not reviewed. - - Rolled out http://trac.webkit.org/changeset/127293 because it broke - inspector tests on Windows. - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - -2012-08-31 Geoffrey Garen <ggaren@apple.com> - - Shrink activation objects by half - https://bugs.webkit.org/show_bug.cgi?id=95591 - - Reviewed by Sam Weinig. - - Removed the global object, global data, and global this pointers from - JSScope, and changed an int to a bitfield. This gets the JSActivation - class down to 64 bytes, which in practice cuts it in half by getting it - out of the 128 byte size class. - - Now, it's one extra indirection to get these pointers. These pointers - aren't accessed by JIT code, so I thought there would be no cost to the - extra indirection. However, some C++-heavy SunSpider tests regressed a - bit in an early version of the patch, which added even more indirection. - This suggests that calls to exec->globalData() and/or exec->lexicalGlobalObject() - are common and probably duplicated in lots of places, and could stand - further optimization in C++. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): Test against the specific activation - for our global object, since there's no VM-shared activation structure - anymore. This is guaranteed to have the same success rate as the old test - because activation scope is fixed at compile time. - - * heap/MarkedBlock.cpp: - (JSC::MarkedBlock::MarkedBlock): - * heap/MarkedBlock.h: - (JSC::MarkedBlock::globalData): - * heap/WeakSet.cpp: - (JSC::WeakSet::addAllocator): - * heap/WeakSet.h: - (WeakSet): - (JSC::WeakSet::WeakSet): - (JSC::WeakSet::globalData): Store a JSGlobalData* instead of a Heap* - because JSGlobalData->Heap is just a constant fold in the addressing - mode, while Heap->JSGlobalData is an extra pointer dereference. (These - objects should eventually just merge.) - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_resolve_global_dynamic): See DFGAbstractState.cpp. - - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: Load the activation structure from - the code block instead of the global data because the structure is not - VM-shared anymore. (See DFGAbstractState.cpp.) - + * runtime/Arguments.cpp: + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/CommonSlowPaths.h: + (JSC::CommonSlowPaths::arityCheckFor): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): - * runtime/JSActivation.h: - (JSActivation): This is the point of the patch: Remove the data. - - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): No longer VM-shared. (See DFGAbstractState.cpp.) - - (JSC::WeakSet::heap): (See WeakSet.h.) - + (JSC::JSActivation::visitChildren): * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - (JSC::JSGlobalObject::setGlobalThis): - (JSC::JSGlobalObject::reset): - (JSC::JSGlobalObject::visitChildren): + (JSC::JSGlobalObject::globalExec): * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::withScopeStructure): - (JSC::JSGlobalObject::strictEvalActivationStructure): - (JSC::JSGlobalObject::activationStructure): - (JSC::JSGlobalObject::nameScopeStructure): - (JSC::JSScope::globalThis): - (JSC::JSGlobalObject::globalThis): Data that used to be in the JSScope - class goes here now, so it's not duplicated across all activations. - - * runtime/JSNameScope.h: - (JSC::JSNameScope::JSNameScope): - * runtime/JSScope.cpp: - (JSC::JSScope::visitChildren): This is the point of the patch: Remove the data. - - * runtime/JSScope.h: - (JSScope): - (JSC::JSScope::JSScope): - (JSC::JSScope::globalObject): - (JSC::JSScope::globalData): - * runtime/JSSegmentedVariableObject.h: - (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): - * runtime/JSSymbolTableObject.h: - (JSC::JSSymbolTableObject::JSSymbolTableObject): - * runtime/JSVariableObject.h: - (JSC::JSVariableObject::JSVariableObject): - * runtime/JSWithScope.h: - (JSC::JSWithScope::JSWithScope): - * runtime/StrictEvalActivation.cpp: - (JSC::StrictEvalActivation::StrictEvalActivation): Simplified now that - we don't need to pass so much data to JSScope. - -2012-08-31 Patrick Gansterer <paroga@webkit.org> - - Build fix for WinCE after r127191. - - * bytecode/JumpTable.h: - -2012-08-30 Filip Pizlo <fpizlo@apple.com> - - ASSERTION FAILURE in JSC::JSGlobalData::float32ArrayDescriptor when running fast/js/dfg-float64array.html - https://bugs.webkit.org/show_bug.cgi?id=95398 - - Reviewed by Mark Hahnenberg. - - Trying to get the build failure to be a bit more informative. - - * runtime/JSGlobalData.h: - (JSGlobalData): - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Qt build: add some #includes that, for some reason, only the Qt linker requires. - - * runtime/BooleanObject.cpp: - * runtime/ErrorInstance.cpp: - * runtime/NameInstance.cpp: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Fix the Qt build: Removed a now-dead variable. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::execute): - -2012-08-30 Benjamin Poulain <bpoulain@apple.com> - - Ambiguous operator[] after r127191 on some compiler - https://bugs.webkit.org/show_bug.cgi?id=95509 - - Reviewed by Simon Fraser. - - On some compilers, the operator[] conflicts with the Obj-C++ operators. This attempts to solve - the issue. - - * runtime/JSString.h: - (JSC::jsSingleCharacterSubstring): - (JSC::jsString): - (JSC::jsSubstring8): - (JSC::jsSubstring): - (JSC::jsOwnedString): - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Qt build: Remove the inline keyword at the declaration - site. - - The Qt compiler seems to be confused, complaining about these functions - not being defined in a translation unit, even though no generated code - in the unit calls these functions. Maybe removing the keyword at the - declaration site will change its mind. - - This shouldn't change the inlining decision at all: the definition is - still inline. - - * interpreter/CallFrame.h: - (ExecState): - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Undo Qt build fix guess, since it breaks other builds. - - * runtime/JSArray.h: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Qt build: add an #include to JSArray.h, since - it's included by some of the files Qt complains about, and - some of is functions call the functions Qt complains about. - - * runtime/JSArray.h: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Second step toward fixing the Windows build: Add new symbols. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Qt build: add an #include. - - * bytecode/GetByIdStatus.cpp: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - First step toward fixing the Windows build: Remove old symbols. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-30 Geoffrey Garen <ggaren@apple.com> - - Use one object instead of two for closures, eliminating ScopeChainNode - https://bugs.webkit.org/show_bug.cgi?id=95501 - - Reviewed by Filip Pizlo. - - This patch removes ScopeChainNode, and moves all the data and related - functions that used to be in ScopeChainNode into JSScope. - - Most of this patch is mechanical changes to use a JSScope* where we used - to use a ScopeChainNode*. I've only specifically commented about items - that were non-mechanical. - - * runtime/Completion.cpp: - (JSC::evaluate): - * runtime/Completion.h: Don't require an explicit scope chain argument - when evaluating code. Clients never wanted anything other than the - global scope, and other arbitrary scopes probably wouldn't work - correctly, anyway. - - * runtime/JSScope.cpp: - * runtime/JSScope.h: - (JSC::JSScope::JSScope): JSScope now requires the data we used to pass to - ScopeChainNode, so it can link itself into the scope chain correctly. - - * runtime/JSWithScope.h: - (JSC::JSWithScope::create): - (JSC::JSWithScope::JSWithScope): JSWithScope gets an extra constructor - for specifically supplying your own scope chain. The DOM needs this - interface for setting up the scope chain for certain event handlers. - Other clients always just push the JSWithScope to the head of the current - scope chain. - -2012-08-30 Mark Lam <mark.lam@apple.com> - - 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: + (JSGlobalObject): + * runtime/JSLock.cpp: (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/MemoryStatistics.cpp: + (JSC::globalMemoryStatistics): -2012-08-30 JungJik Lee <jungjik.lee@samsung.com> - - [EFL][WK2] Add WebMemorySampler feature. - https://bugs.webkit.org/show_bug.cgi?id=91214 - - Reviewed by Kenneth Rohde Christiansen. +2012-10-08 Kiran Muppala <cmuppala@apple.com> - WebMemorySampler collects Javascript stack and JIT memory usage in globalMemoryStatistics. + Throttle DOM timers on hidden pages. + https://bugs.webkit.org/show_bug.cgi?id=98474 - * PlatformEfl.cmake: + Reviewed by Maciej Stachowiak. -2012-08-30 Benjamin Poulain <bpoulain@apple.com> + Add HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define. - Replace JSC::UString by WTF::String - https://bugs.webkit.org/show_bug.cgi?id=95271 + * Configurations/FeatureDefines.xcconfig: - Reviewed by Geoffrey Garen. +2012-10-08 Michael Saboff <msaboff@apple.com> - Having JSC::UString and WTF::String increase the complexity of working on WebKit, and - add useless conversions in the bindings. It also cause some code bloat. + After r130344, OpaqueJSString() creates an empty string which should be a null string + https://bugs.webkit.org/show_bug.cgi?id=98417 - The performance advantages of UString have been ported over in previous patches. This patch - is the last step: getting rid of UString. + Reviewed by Sam Weinig. - In addition to the simplified code, this also reduce the binary size by 15kb on x86_64. + Changed create() of a null string to return 0. This is the same behavior as before r130344. * API/OpaqueJSString.cpp: - (OpaqueJSString::ustring): - * runtime/Identifier.h: - (JSC::Identifier::ustring): - To avoid changing everything at once, the function named ustring() were kept as is. They - will be renamed in a follow up patch. - - * runtime/JSString.h: - (JSC::JSString::string): - (JSC::JSValue::toWTFString): - (JSC::inlineJSValueNotStringtoString): - (JSC::JSValue::toWTFStringInline): - Since JSValue::toString() already exist (and return the JSString), the direct accessor is renamed - to ::toWTFString(). We may change ::string() to ::jsString() and ::toWTFString() to ::toString() - in the future. - - * runtime/StringPrototype.cpp: - (JSC::substituteBackreferencesSlow): Replace the use of UString::getCharacters<>() by String::getCharactersWithUpconvert<>(). - -2012-08-24 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove uses of ClassInfo in StrictEq and CompareEq in the DFG - https://bugs.webkit.org/show_bug.cgi?id=93401 - - Reviewed by Filip Pizlo. - - Another incremental step in removing the dependence on ClassInfo pointers in object headers. - - * bytecode/SpeculatedType.h: - (JSC::isCellOrOtherSpeculation): - (JSC): - * dfg/DFGAbstractState.cpp: Updated the CFA to reflect the changes to the backend. - (JSC::DFG::AbstractState::execute): - * dfg/DFGNode.h: - (Node): - (JSC::DFG::Node::shouldSpeculateString): Added this new function since it was conspicuously absent. - (JSC::DFG::Node::shouldSpeculateNonStringCellOrOther): Also add this function for use in the CFA. - * dfg/DFGSpeculativeJIT.cpp: Refactored how we handle CompareEq and CompareStrictEq in the DFG. We now just - check for Strings by comparing the object's Structure to the global Structure for strings. We only - check for MasqueradesAsUndefined if the watchpoint has fired. These changes allow us to remove our - uses of the ClassInfo pointer for compiling these nodes. - (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): - (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): - (JSC::DFG::SpeculativeJIT::compare): - (JSC::DFG::SpeculativeJIT::compileStrictEq): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: Same changes for 32 bit as for 64 bit. - (JSC::DFG::SpeculativeJIT::compileObjectEquality): - (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): - (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compileObjectEquality): - (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): - (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): - -2012-08-30 Yong Li <yoli@rim.com> - - [BlackBerry] Implement IncrementalSweeper for PLATFORM(BLACKBERRY) - https://bugs.webkit.org/show_bug.cgi?id=95469 - - Reviewed by Rob Buis. - - RIM PR# 200595. - Share most code with USE(CF) and implement timer-related methods - for PLATFORM(BLACKBERRY). - - * heap/IncrementalSweeper.cpp: - (JSC): - (JSC::IncrementalSweeper::IncrementalSweeper): - (JSC::IncrementalSweeper::create): - (JSC::IncrementalSweeper::scheduleTimer): - (JSC::IncrementalSweeper::cancelTimer): - (JSC::IncrementalSweeper::doSweep): - * heap/IncrementalSweeper.h: - (IncrementalSweeper): - -2012-08-30 Mark Lam <mark.lam@apple.com> - - 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-30 Byungwoo Lee <bw80.lee@samsung.com> - - 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-08-30 Yong Li <yoli@rim.com> - - [BlackBerry] Set timer client on platform timer used in HeapTimer - https://bugs.webkit.org/show_bug.cgi?id=95464 - - Reviewed by Rob Buis. - - Otherwise the timer won't work. - - * heap/HeapTimer.cpp: - (JSC::HeapTimer::HeapTimer): - -2012-08-30 Julien BRIANCEAU <jbrianceau@nds.com> - - [sh4] Add missing implementation for JavaScriptCore JIT - https://bugs.webkit.org/show_bug.cgi?id=95452 - - Reviewed by Oliver Hunt. - - * assembler/MacroAssemblerSH4.h: - (JSC::MacroAssemblerSH4::isCompactPtrAlignedAddressOffset): - (MacroAssemblerSH4): - (JSC::MacroAssemblerSH4::add32): - (JSC::MacroAssemblerSH4::convertibleLoadPtr): - * assembler/SH4Assembler.h: - (JSC::SH4Assembler::labelIgnoringWatchpoints): - (SH4Assembler): - (JSC::SH4Assembler::replaceWithLoad): - (JSC::SH4Assembler::replaceWithAddressComputation): - -2012-08-30 Charles Wei <charles.wei@torchmobile.com.cn> - - [BlackBerry] Eliminate build warnings - https://bugs.webkit.org/show_bug.cgi?id=95338 - - Reviewed by Filip Pizlo. - - static_cast to the same type to eliminate the build time warnings. - - * assembler/AssemblerBufferWithConstantPool.h: - (JSC::AssemblerBufferWithConstantPool::flushWithoutBarrier): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::branch32): - -2012-08-29 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove use of ClassInfo from compileGetByValOnArguments and compileGetArgumentsLength - https://bugs.webkit.org/show_bug.cgi?id=95131 - - Reviewed by Filip Pizlo. - - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it - with an assert to guarantee this. - -2012-08-29 Mark Lam <mark.lam@apple.com> - - 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-29 Gavin Barraclough <barraclough@apple.com> - - PutById uses DataLabel32, not DataLabelCompact - https://bugs.webkit.org/show_bug.cgi?id=95245 - - Reviewed by Geoff Garen. - - JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now, - since they currently both do the same thing, but if we were to ever make compact mean - 8-bit this could be a real problem. Also, relying on the object still being in eax - on entry to the transition stub isn't very robust - added nonArgGPR1 to at least make - this explicit. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emitSlow_op_put_by_id): - - copy regT0 to nonArgGPR1 - (JSC::JIT::privateCompilePutByIdTransition): - - DataLabelCompact -> DataLabel32 - (JSC::JIT::resetPatchPutById): - - reload regT0 from nonArgGPR1 - * jit/JSInterfaceJIT.h: - (JSInterfaceJIT): - - added nonArgGPR1 - -2012-08-28 Yong Li <yoli@rim.com> - - ExecutableAllocator should be destructed after Heap - https://bugs.webkit.org/show_bug.cgi?id=95244 - - Reviewed by Rob Buis. - - RIM PR# 199364. - Make ExecutableAllocator the first member in JSGlobalData. - Existing Web Worker tests can show the issue. - - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): - -2012-08-29 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Windows build. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Export! - -2012-08-28 Geoffrey Garen <ggaren@apple.com> - - Introduced JSWithScope, making all scope objects subclasses of JSScope - https://bugs.webkit.org/show_bug.cgi?id=95295 - - Reviewed by Filip Pizlo. - - This is a step toward removing ScopeChainNode. With a uniform representation - for objects in the scope chain, we can move data from ScopeChainNode - into JSScope. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: Build! - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): Use an explicit JSWithScope object - for 'with' statements. Since 'with' can put any object in the scope - chain, we'll need an adapter object to hold the data ScopeChainNode - currently holds. - - (JSGlobalData): Support for JSWithScope. - - * runtime/JSScope.cpp: - (JSC::JSScope::objectAtScope): - * runtime/JSScope.h: Check for and unwrap JSWithScope. - - * runtime/JSType.h: Support for JSWithScope. - - * runtime/StrictEvalActivation.cpp: - (JSC::StrictEvalActivation::StrictEvalActivation): - * runtime/StrictEvalActivation.h: - (StrictEvalActivation): Inherit from JSScope, to make the scope chain uniform. - - * runtime/JSWithScope.cpp: Added. - (JSC::JSWithScope::visitChildren): - * runtime/JSWithScope.h: Added. - (JSWithScope): - (JSC::JSWithScope::create): - (JSC::JSWithScope::object): - (JSC::JSWithScope::createStructure): - (JSC::JSWithScope::JSWithScope): New adapter object. Since this object - is never exposed to scripts, it doesn't need any meaningful implementation - of property access or other callbacks. - -2012-08-29 Patrick Gansterer <paroga@webkit.org> - - Unreviewed. Build fix for !ENABLE(JIT) after r126962. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): + (OpaqueJSString::create): -2012-08-28 Geoffrey Garen <ggaren@apple.com> - - Added JSScope::objectInScope(), and refactored callers to use it - https://bugs.webkit.org/show_bug.cgi?id=95281 - - Reviewed by Gavin Barraclough. - - This is a step toward removing ScopeChainNode. We need a layer of - indirection so that 'with' scopes can proxy for an object. - JSScope::objectInScope() will be that layer. - - * bytecode/EvalCodeCache.h: - (JSC::EvalCodeCache::tryGet): - (JSC::EvalCodeCache::getSlow): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::resolve): - (JSC::BytecodeGenerator::resolveConstDecl): . vs -> - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): - (JSC::Interpreter::execute): - * runtime/JSScope.cpp: - (JSC::JSScope::resolve): - (JSC::JSScope::resolveSkip): - (JSC::JSScope::resolveGlobalDynamic): - (JSC::JSScope::resolveBase): - (JSC::JSScope::resolveWithBase): - (JSC::JSScope::resolveWithThis): Added JSScope::objectAtScope() calls. - - * runtime/JSScope.h: - (JSScope): - (JSC::JSScope::objectAtScope): - (JSC): - (ScopeChainIterator): - (JSC::ScopeChainIterator::ScopeChainIterator): - (JSC::ScopeChainIterator::get): - (JSC::ScopeChainIterator::operator->): - (JSC::ScopeChainIterator::operator++): - (JSC::ScopeChainIterator::operator==): - (JSC::ScopeChainIterator::operator!=): - (JSC::ScopeChainNode::begin): - (JSC::ScopeChainNode::end): I moved ScopeChainIterator to this file - to resolve a circular #include problem. Eventually, I'll probably rename - it to JSScope::iterator, so I think it belongs here. - - * runtime/ScopeChain.cpp: - (JSC::ScopeChainNode::print): - (JSC::ScopeChainNode::localDepth): . vs -> - - * runtime/ScopeChain.h: - (ScopeChainNode): I made the 'object' data member private because it's - no longer safe to access -- you need to call JSScope::objectAtScope() - instead. - - The JITs need to be friends because of the private declaration. - - Subtly, JIT/LLInt code is correct without any changes because JIT/LLInt - code never compiles direct access to a with scope. - -2012-08-28 Mark Lam <mark.lam@apple.com> - - 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 Gavin Barraclough <barraclough@apple.com> - - Rolled out r126928, this broke stuff :'-( - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompilePutByIdTransition): - (JSC::JIT::resetPatchPutById): - -2012-08-28 Gavin Barraclough <barraclough@apple.com> - - PutById uses DataLabel32, not DataLabelCompact - https://bugs.webkit.org/show_bug.cgi?id=95245 - - Reviewed by Geoff Garen. - - JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now, - since they currently both do the same thing, but if we were to ever make compact mean - 8-bit this could be a real problem. Also, don't rely on the object still being in eax - on entry to the transition stub – this isn't very robust. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompilePutByIdTransition): - - DataLabelCompact -> DataLabel32 - (JSC::JIT::resetPatchPutById): - - reload regT0 from the stack - -2012-08-28 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r126914. - http://trac.webkit.org/changeset/126914 - https://bugs.webkit.org/show_bug.cgi?id=95239 - - it breaks everything and fixes nothing (Requested by pizlo on - #webkit). - - * API/JSCallbackObject.h: - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): - * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnPropertyNames): - * API/JSClassRef.cpp: - (OpaqueJSClass::~OpaqueJSClass): - (OpaqueJSClassContextData::OpaqueJSClassContextData): - (OpaqueJSClass::contextData): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::EvalCodeCache::visitAggregate): - (JSC::CodeBlock::nameForRegister): - * bytecode/JumpTable.h: - (JSC::StringJumpTable::offsetForValue): - (JSC::StringJumpTable::ctiForValue): - * bytecode/LazyOperandValueProfile.cpp: - (JSC::LazyOperandValueProfileParser::getIfPresent): - * bytecode/SamplingTool.cpp: - (JSC::SamplingTool::dump): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::addVar): - (JSC::BytecodeGenerator::addGlobalVar): - (JSC::BytecodeGenerator::addConstant): - (JSC::BytecodeGenerator::addConstantValue): - (JSC::BytecodeGenerator::emitLoad): - (JSC::BytecodeGenerator::addStringConstant): - (JSC::BytecodeGenerator::emitLazyNewFunction): - * bytecompiler/NodesCodegen.cpp: - (JSC::PropertyListNode::emitBytecode): - * debugger/Debugger.cpp: - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): - (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): - * dfg/DFGAssemblyHelpers.cpp: - (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): - * dfg/DFGByteCodeCache.h: - (JSC::DFG::ByteCodeCache::~ByteCodeCache): - (JSC::DFG::ByteCodeCache::get): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::cellConstant): - (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): - (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): - * heap/Heap.cpp: - (JSC::Heap::markProtectedObjects): - * heap/Heap.h: - (JSC::Heap::forEachProtectedCell): - * heap/JITStubRoutineSet.cpp: - (JSC::JITStubRoutineSet::markSlow): - (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): - * heap/MarkStack.cpp: - (JSC::MarkStack::internalAppend): - * heap/Weak.h: - (JSC::weakRemove): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - * jit/JITStubs.cpp: - (JSC::JITThunks::ctiStub): - * parser/Parser.cpp: - (JSC::::parseStrictObjectLiteral): - * profiler/Profile.cpp: - (JSC::functionNameCountPairComparator): - (JSC::Profile::debugPrintDataSampleStyle): - * runtime/Identifier.cpp: - (JSC::Identifier::add): - * runtime/JSActivation.cpp: - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - * runtime/JSArray.cpp: - (JSC::SparseArrayValueMap::put): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayValueMap::visitChildren): - (JSC::JSArray::enterDictionaryMode): - (JSC::JSArray::defineOwnNumericProperty): - (JSC::JSArray::getOwnPropertySlotByIndex): - (JSC::JSArray::getOwnPropertyDescriptor): - (JSC::JSArray::putByIndexBeyondVectorLength): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - (JSC::JSArray::deletePropertyByIndex): - (JSC::JSArray::getOwnPropertyNames): - (JSC::JSArray::setLength): - (JSC::JSArray::sort): - (JSC::JSArray::compactForSorting): - (JSC::JSArray::checkConsistency): - * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::getOwnPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSC::symbolTableGet): - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): - * runtime/RegExpCache.cpp: - (JSC::RegExpCache::invalidateCode): - * runtime/WeakGCMap.h: - (JSC::WeakGCMap::clear): - (JSC::WeakGCMap::set): - * tools/ProfileTreeNode.h: - (JSC::ProfileTreeNode::sampleChild): - (JSC::ProfileTreeNode::childCount): - (JSC::ProfileTreeNode::dumpInternal): - (JSC::ProfileTreeNode::compareEntries): - -2012-08-28 Filip Pizlo <fpizlo@apple.com> - - 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-28 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> +2012-10-07 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> Rename first/second to key/value in HashMap iterators https://bugs.webkit.org/show_bug.cgi?id=82784 @@ -5987,266 +2403,7 @@ (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnPropertyNames): - * API/JSClassRef.cpp: - (OpaqueJSClass::~OpaqueJSClass): - (OpaqueJSClassContextData::OpaqueJSClassContextData): - (OpaqueJSClass::contextData): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::EvalCodeCache::visitAggregate): - (JSC::CodeBlock::nameForRegister): - * bytecode/JumpTable.h: - (JSC::StringJumpTable::offsetForValue): - (JSC::StringJumpTable::ctiForValue): - * bytecode/LazyOperandValueProfile.cpp: - (JSC::LazyOperandValueProfileParser::getIfPresent): - * bytecode/SamplingTool.cpp: - (JSC::SamplingTool::dump): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::addVar): - (JSC::BytecodeGenerator::addGlobalVar): - (JSC::BytecodeGenerator::addConstant): - (JSC::BytecodeGenerator::addConstantValue): - (JSC::BytecodeGenerator::emitLoad): - (JSC::BytecodeGenerator::addStringConstant): - (JSC::BytecodeGenerator::emitLazyNewFunction): - * bytecompiler/NodesCodegen.cpp: - (JSC::PropertyListNode::emitBytecode): - * debugger/Debugger.cpp: - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): - (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): - * dfg/DFGAssemblyHelpers.cpp: - (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): - * dfg/DFGByteCodeCache.h: - (JSC::DFG::ByteCodeCache::~ByteCodeCache): - (JSC::DFG::ByteCodeCache::get): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::cellConstant): - (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): - (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): - * heap/Heap.cpp: - (JSC::Heap::markProtectedObjects): - * heap/Heap.h: - (JSC::Heap::forEachProtectedCell): - * heap/JITStubRoutineSet.cpp: - (JSC::JITStubRoutineSet::markSlow): - (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): - * heap/MarkStack.cpp: - (JSC::MarkStack::internalAppend): - * heap/Weak.h: - (JSC::weakRemove): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - * jit/JITStubs.cpp: - (JSC::JITThunks::ctiStub): - * parser/Parser.cpp: - (JSC::::parseStrictObjectLiteral): - * profiler/Profile.cpp: - (JSC::functionNameCountPairComparator): - (JSC::Profile::debugPrintDataSampleStyle): - * runtime/Identifier.cpp: - (JSC::Identifier::add): - * runtime/JSActivation.cpp: - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - * runtime/JSArray.cpp: - (JSC::SparseArrayValueMap::put): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayValueMap::visitChildren): - (JSC::JSArray::enterDictionaryMode): - (JSC::JSArray::defineOwnNumericProperty): - (JSC::JSArray::getOwnPropertySlotByIndex): - (JSC::JSArray::getOwnPropertyDescriptor): - (JSC::JSArray::putByIndexBeyondVectorLength): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - (JSC::JSArray::deletePropertyByIndex): - (JSC::JSArray::getOwnPropertyNames): - (JSC::JSArray::setLength): - (JSC::JSArray::sort): - (JSC::JSArray::compactForSorting): - (JSC::JSArray::checkConsistency): - * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::getOwnPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSC::symbolTableGet): - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): - * runtime/RegExpCache.cpp: - (JSC::RegExpCache::invalidateCode): - * runtime/WeakGCMap.h: - (JSC::WeakGCMap::clear): - (JSC::WeakGCMap::set): - * tools/ProfileTreeNode.h: - (JSC::ProfileTreeNode::sampleChild): - (JSC::ProfileTreeNode::childCount): - (JSC::ProfileTreeNode::dumpInternal): - (JSC::ProfileTreeNode::compareEntries): - -2012-08-28 Geoffrey Garen <ggaren@apple.com> - - GCC warning in JSActivation is causing Mac EWS errors - https://bugs.webkit.org/show_bug.cgi?id=95103 - - Reviewed by Sam Weinig. - - Try to fix a strict aliasing violation by using bitwise_cast. The - union in the cast should signal to the compiler that aliasing between - types is happening. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::visitChildren): - -2012-08-28 Geoffrey Garen <ggaren@apple.com> - - Build fix: svn add two files I forgot in my last patch. - -2012-08-27 Geoffrey Garen <ggaren@apple.com> - - Refactored and consolidated variable resolution functions - https://bugs.webkit.org/show_bug.cgi?id=95166 - - Reviewed by Filip Pizlo. - - This patch does a few things: - - (1) Introduces a new class, JSScope, which is the base class for all - objects that represent a scope in the scope chain. - - (2) Refactors and consolidates duplicate implementations of variable - resolution into the JSScope class. - - (3) Renames JSStaticScopeObject to JSNameScope because, as distinct from - something like a 'let' scope, JSStaticScopeObject only has storage for a - single name. - - These changes makes logical sense to me as-is. I will also use them in an - upcoming optimization. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: Build! - - * bytecode/CodeBlock.cpp: - (JSC): Build fix for LLInt-only builds. - - * bytecode/GlobalResolveInfo.h: - (GlobalResolveInfo): Use PropertyOffset to be consistent with other parts - of the engine. - - * bytecompiler/NodesCodegen.cpp: - * dfg/DFGOperations.cpp: Use the shared code in JSScope instead of rolling - our own. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::execute): - (JSC::Interpreter::createExceptionScope): - (JSC::Interpreter::privateExecute): - * interpreter/Interpreter.h: Use the shared code in JSScope instead of rolling - our own. - - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): Use the shared code in JSScope instead of rolling - our own. - - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - (LLInt): Use the shared code in JSScope instead of rolling our own. Note - that one of these slow paths calls the wrong helper function. I left it - that way to avoid a behavior change in a refactoring patch. - - * parser/Nodes.cpp: Updated for rename. - - * runtime/CommonSlowPaths.h: - (CommonSlowPaths): Removed resolve slow paths because were duplicative. - - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): Updated for renames. - - * runtime/JSNameScope.cpp: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.cpp. - (JSC): - (JSC::JSNameScope::visitChildren): - (JSC::JSNameScope::toThisObject): - (JSC::JSNameScope::put): - (JSC::JSNameScope::getOwnPropertySlot): - * runtime/JSNameScope.h: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.h. - (JSC): - (JSC::JSNameScope::create): - (JSC::JSNameScope::createStructure): - (JSNameScope): - (JSC::JSNameScope::JSNameScope): - (JSC::JSNameScope::isDynamicScope): Used do-webcore-rename script here. - It is fabulous! - - * runtime/JSObject.h: - (JSObject): - (JSC::JSObject::isNameScopeObject): More rename. - - * runtime/JSScope.cpp: Added. - (JSC): - (JSC::JSScope::isDynamicScope): - (JSC::JSScope::resolve): - (JSC::JSScope::resolveSkip): - (JSC::JSScope::resolveGlobal): - (JSC::JSScope::resolveGlobalDynamic): - (JSC::JSScope::resolveBase): - (JSC::JSScope::resolveWithBase): - (JSC::JSScope::resolveWithThis): - * runtime/JSScope.h: Added. - (JSC): - (JSScope): - (JSC::JSScope::JSScope): All the code here is a port from the - Interpreter.cpp implementations of this functionality. - - * runtime/JSStaticScopeObject.cpp: Removed. - * runtime/JSStaticScopeObject.h: Removed. - - * runtime/JSSymbolTableObject.cpp: - (JSC): - * runtime/JSSymbolTableObject.h: - (JSSymbolTableObject): - * runtime/JSType.h: Updated for rename. - - * runtime/Operations.h: - (JSC::resolveBase): Removed because it was duplicative. - -2012-08-28 Alban Browaeys <prahal@yahoo.com> - - [GTK] LLint build fails with -g -02 - https://bugs.webkit.org/show_bug.cgi?id=90098 - - Reviewed by Filip Pizlo. - - Avoid duplicate offsets for llint, discarding them. - - * offlineasm/offsets.rb: - -2012-08-27 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r126836. - http://trac.webkit.org/changeset/126836 - https://bugs.webkit.org/show_bug.cgi?id=95163 - - Broke all Apple ports, EFL, and Qt. (Requested by tkent on - #webkit). - - * API/JSCallbackObject.h: - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): - * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnPropertyNames): + (JSC::::getOwnNonIndexPropertyNames): * API/JSClassRef.cpp: (OpaqueJSClass::~OpaqueJSClass): (OpaqueJSClassContextData::OpaqueJSClassContextData): @@ -6298,8 +2455,8 @@ * heap/JITStubRoutineSet.cpp: (JSC::JITStubRoutineSet::markSlow): (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): - * heap/MarkStack.cpp: - (JSC::MarkStack::internalAppend): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::internalAppend): * heap/Weak.h: (JSC::weakRemove): * jit/JIT.cpp: @@ -6314,147 +2471,32 @@ * runtime/Identifier.cpp: (JSC::Identifier::add): * runtime/JSActivation.cpp: - (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::getOwnNonIndexPropertyNames): (JSC::JSActivation::symbolTablePutWithAttributes): * runtime/JSArray.cpp: - (JSC::SparseArrayValueMap::put): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayValueMap::visitChildren): - (JSC::JSArray::enterDictionaryMode): - (JSC::JSArray::defineOwnNumericProperty): - (JSC::JSArray::getOwnPropertySlotByIndex): - (JSC::JSArray::getOwnPropertyDescriptor): - (JSC::JSArray::putByIndexBeyondVectorLength): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - (JSC::JSArray::deletePropertyByIndex): - (JSC::JSArray::getOwnPropertyNames): (JSC::JSArray::setLength): - (JSC::JSArray::sort): - (JSC::JSArray::compactForSorting): - (JSC::JSArray::checkConsistency): + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): + (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::getOwnPropertyNames): + (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): * runtime/JSSymbolTableObject.h: (JSC::symbolTableGet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/RegExpCache.cpp: (JSC::RegExpCache::invalidateCode): - * runtime/WeakGCMap.h: - (JSC::WeakGCMap::clear): - (JSC::WeakGCMap::set): - * tools/ProfileTreeNode.h: - (JSC::ProfileTreeNode::sampleChild): - (JSC::ProfileTreeNode::childCount): - (JSC::ProfileTreeNode::dumpInternal): - (JSC::ProfileTreeNode::compareEntries): - -2012-08-27 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> - - Rename first/second to key/value in HashMap iterators - https://bugs.webkit.org/show_bug.cgi?id=82784 - - Reviewed by Eric Seidel. - - * API/JSCallbackObject.h: - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): - * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnPropertyNames): - * API/JSClassRef.cpp: - (OpaqueJSClass::~OpaqueJSClass): - (OpaqueJSClassContextData::OpaqueJSClassContextData): - (OpaqueJSClass::contextData): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::EvalCodeCache::visitAggregate): - (JSC::CodeBlock::nameForRegister): - * bytecode/JumpTable.h: - (JSC::StringJumpTable::offsetForValue): - (JSC::StringJumpTable::ctiForValue): - * bytecode/LazyOperandValueProfile.cpp: - (JSC::LazyOperandValueProfileParser::getIfPresent): - * bytecode/SamplingTool.cpp: - (JSC::SamplingTool::dump): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::addVar): - (JSC::BytecodeGenerator::addGlobalVar): - (JSC::BytecodeGenerator::addConstant): - (JSC::BytecodeGenerator::addConstantValue): - (JSC::BytecodeGenerator::emitLoad): - (JSC::BytecodeGenerator::addStringConstant): - (JSC::BytecodeGenerator::emitLazyNewFunction): - * bytecompiler/NodesCodegen.cpp: - (JSC::PropertyListNode::emitBytecode): - * debugger/Debugger.cpp: - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): - (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): - (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): - * dfg/DFGAssemblyHelpers.cpp: - (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): - * dfg/DFGByteCodeCache.h: - (JSC::DFG::ByteCodeCache::~ByteCodeCache): - (JSC::DFG::ByteCodeCache::get): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::cellConstant): - (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): - (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): - * heap/Heap.cpp: - (JSC::Heap::markProtectedObjects): - * heap/Heap.h: - (JSC::Heap::forEachProtectedCell): - * heap/JITStubRoutineSet.cpp: - (JSC::JITStubRoutineSet::markSlow): - (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): - * heap/MarkStack.cpp: - (JSC::MarkStack::internalAppend): - * heap/Weak.h: - (JSC::weakRemove): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - * jit/JITStubs.cpp: - (JSC::JITThunks::ctiStub): - * parser/Parser.cpp: - (JSC::::parseStrictObjectLiteral): - * profiler/Profile.cpp: - (JSC::functionNameCountPairComparator): - (JSC::Profile::debugPrintDataSampleStyle): - * runtime/Identifier.cpp: - (JSC::Identifier::add): - * runtime/JSActivation.cpp: - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - * runtime/JSArray.cpp: - (JSC::SparseArrayValueMap::put): + * runtime/SparseArrayValueMap.cpp: + (JSC::SparseArrayValueMap::putEntry): (JSC::SparseArrayValueMap::putDirect): (JSC::SparseArrayValueMap::visitChildren): - (JSC::JSArray::enterDictionaryMode): - (JSC::JSArray::defineOwnNumericProperty): - (JSC::JSArray::getOwnPropertySlotByIndex): - (JSC::JSArray::getOwnPropertyDescriptor): - (JSC::JSArray::putByIndexBeyondVectorLength): - (JSC::JSArray::putDirectIndexBeyondVectorLength): - (JSC::JSArray::deletePropertyByIndex): - (JSC::JSArray::getOwnPropertyNames): - (JSC::JSArray::setLength): - (JSC::JSArray::sort): - (JSC::JSArray::compactForSorting): - (JSC::JSArray::checkConsistency): - * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::getOwnPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSC::symbolTableGet): - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): - * runtime/RegExpCache.cpp: - (JSC::RegExpCache::invalidateCode): * runtime/WeakGCMap.h: (JSC::WeakGCMap::clear): (JSC::WeakGCMap::set): @@ -6464,13995 +2506,445 @@ (JSC::ProfileTreeNode::dumpInternal): (JSC::ProfileTreeNode::compareEntries): -2012-08-27 Filip Pizlo <fpizlo@apple.com> - - Structure check hoisting should abstain if the OSR entry's must-handle value for the respective variable has a different structure - https://bugs.webkit.org/show_bug.cgi?id=95141 - <rdar://problem/12170401> - - Reviewed by Mark Hahnenberg. - - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-27 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove use of ClassInfo from SpeculativeJIT::compileGetByValOnArguments - https://bugs.webkit.org/show_bug.cgi?id=95131 - - Reviewed by Filip Pizlo. - - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it - with an assert to guarantee this. - -2012-08-27 Oliver Hunt <oliver@apple.com> - - Remove opcode definition autogen for now - https://bugs.webkit.org/show_bug.cgi?id=95148 - - Reviewed by Mark Hahnenberg. - - This isn't worth doing at the moment. - - * DerivedSources.make: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/OpcodeDefinitions.h: Removed. - * bytecode/opcodes: Removed. - * opcode_definition_generator.py: Removed. - * opcode_generator.py: Removed. - * opcode_parser.py: Removed. - -2012-08-27 Mark Hahnenberg <mhahnenberg@apple.com> - - Remove uses of TypedArray ClassInfo from SpeculativeJIT::checkArgumentTypes - https://bugs.webkit.org/show_bug.cgi?id=95112 - - Reviewed by Filip Pizlo. - - Removing these checks since we no longer need them. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::initialize): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArgumentTypes): - -2012-08-27 Benjamin Poulain <benjamin@webkit.org> - - Add ECMAScript Number to String conversion to WTF::String - https://bugs.webkit.org/show_bug.cgi?id=95016 - - Reviewed by Geoffrey Garen. - - Rename UString::number(double) to UString::numberToStringECMAScript(double) to - differenciate it from the fixed-width conversion performed by String::number(). - - * parser/ParserArena.h: - (JSC::IdentifierArena::makeNumericIdentifier): - * runtime/JSONObject.cpp: - (JSC::Stringifier::appendStringifiedValue): - * runtime/NumberPrototype.cpp: - (JSC::numberProtoFuncToExponential): - (JSC::numberProtoFuncToFixed): - (JSC::numberProtoFuncToPrecision): - (JSC::numberProtoFuncToString): - * runtime/NumericStrings.h: - (JSC::NumericStrings::add): - * runtime/UString.cpp: - (JSC::UString::numberToStringECMAScript): - * runtime/UString.h: - (UString): - -2012-08-27 Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com> - - Rename RegisterProtocolHandler API to NavigatorContentUtils - https://bugs.webkit.org/show_bug.cgi?id=94920 - - Reviewed by Adam Barth. - - ENABLE_REGISTER_PROTOCOL_HANDLER is renamed to ENABLE_NAVIGATOR_CONTENT_UTILS. - - * Configurations/FeatureDefines.xcconfig: - -2012-08-26 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, fix for builds without VALUE_PROFILING. I had forgotten that shouldEmitProfiling() - is designed to return true if DFG_JIT is disabled. I should be using canBeOptimized() instead. - - * jit/JITCall.cpp: - (JSC::JIT::compileOpCall): - * jit/JITCall32_64.cpp: - (JSC::JIT::compileOpCall): - -2012-08-26 Geoffrey Garen <ggaren@apple.com> - - Don't allocate space for arguments and call frame if arguments aren't captured - https://bugs.webkit.org/show_bug.cgi?id=95024 - - Reviewed by Phil Pizlo. - - 27% on v8-real-earley. - - * runtime/JSActivation.h: - (JSC::JSActivation::registerOffset): The offset is zero if we're skipping - the arguments and call frame because "offset" means space reserved for - those things. - - (JSC::JSActivation::tearOff): Don't copy the scope chain and callee. We - don't need them for anything, and we're no longer guaranteed to have - space for them. - -2012-08-26 Geoffrey Garen <ggaren@apple.com> - - Removed the NULL checks from visitChildren functions - https://bugs.webkit.org/show_bug.cgi?id=95021 - - Reviewed by Oliver Hunt. - - As of http://trac.webkit.org/changeset/126624, all values are NULL-checked - during GC, so explicit NULL checks aren't needed anymore. - -2011-08-26 Geoffrey Garen <ggaren@apple.com> - - Removed a JSC-specific hack from the web inspector - https://bugs.webkit.org/show_bug.cgi?id=95033 - - Reviewed by Filip Pizlo. - - Added support for what the web inspector really wanted instead. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::symbolTableGet): - (JSC::JSActivation::symbolTablePut): Added some explanation for these - checks, which were non-obvious to me. - - (JSC::JSActivation::getOwnPropertySlot): It's impossible to access the - arguments property of an activation after it's been torn off, since the - only way to tear off an activation is to instantiate a new function, - which has its own arguments property in scope. However, the inspector - get special access to activations, and may try to perform this access, - so we need a special guard to maintain coherence and avoid crashing in - case the activation optimized out the arguments property. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::symbolTableGet): - (JSC::JSActivation::symbolTablePut): - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::getOwnPropertyDescriptor): Provide getOwnPropertyNames - and getOwnPropertyDescriptor implementations, to meet the web inspector's - needs. (User code can never call these.) - -2012-08-24 Filip Pizlo <fpizlo@apple.com> - - Finally inlining should correctly track the catch context - https://bugs.webkit.org/show_bug.cgi?id=94986 - <rdar://problem/11753784> - - 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-26 Filip Pizlo <fpizlo@apple.com> - - Array type checks and storage accesses should be uniformly represented and available to CSE - https://bugs.webkit.org/show_bug.cgi?id=95013 - - Reviewed by Oliver Hunt. - - This uniformly breaks up all array accesses into up to three parts: - - 1) The type check, using a newly introduced CheckArray node, in addition to possibly - a CheckStructure node. We were already inserting the CheckStructure prior to this - patch. The CheckArray node will be automatically eliminated if the thing it was - checking for had already been checked for, either intentionally (a CheckStructure - inserted based on the array profile of this access) or accidentally (some checks, - typically a CheckStructure, inserted for some unrelated operations). The - CheckArray node may not be inserted if the array type is non-specific (Generic or - ForceExit). - - 2) The storage load using GetIndexedPropertyStorage. Previously, this only worked for - GetByVal. Now it works for all array accesses. The storage load may not be - inserted if the mode of array access does not permit CSE of storage loads (like - non-specific modes or Arguments). - - 3) The access itself: one of GetByVal, PutByVal, PutByValAlias, ArrayPush, ArrayPop, - GetArrayLength, StringCharAt, or StringCharCodeAt. - - This means that the type check can be subjected to CSE even if the CFA isn't smart - enough to reason about it (yet!). It also means that the storage load can always be - subjected to CSE; previously CSE on storage load only worked for array loads and not - other forms of access. Finally, it removes the bizarre behavior that - GetIndexedPropertyStorage previously had: previously, it was responsible for the type - check in some cases, but not others; this made reasoning about the CFA really - confusing. - - This change also disables late refinement of array mode, since I decided that - supporting that feature is both confusing and likely unprofitable. The array modes are - now locked in in the first fixup run after prediction propagation. Of course, - refinements from Generic to something else would not have been a problem; we could - reenable those if we thought we really needed to. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::fromStructure): - (DFG): - (JSC::DFG::refineArrayMode): - * dfg/DFGArrayMode.h: - (DFG): - (JSC::DFG::modeIsJSArray): - (JSC::DFG::lengthNeedsStorage): - (JSC::DFG::modeIsSpecific): - (JSC::DFG::modeSupportsLength): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::ByteCodeParser): - (JSC::DFG::ByteCodeParser::getArrayMode): - (ByteCodeParser): - (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): - (JSC::DFG::ByteCodeParser::handleIntrinsic): - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::mergeBlocks): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::CSEPhase): - (JSC::DFG::CSEPhase::checkStructureElimination): - (CSEPhase): - (JSC::DFG::CSEPhase::checkArrayElimination): - (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): - (JSC::DFG::CSEPhase::performNodeCSE): - (JSC::DFG::performCSE): - * dfg/DFGCSEPhase.h: - (DFG): - * dfg/DFGCommon.h: - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGDriver.cpp: - (JSC::DFG::compile): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::checkArray): - (FixupPhase): - (JSC::DFG::FixupPhase::blessArrayOperation): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::Graph): - (DFG): - (JSC::DFG::Graph::dump): - (JSC::DFG::Graph::collectGarbage): - * dfg/DFGGraph.h: - (Graph): - (JSC::DFG::Graph::vote): - (JSC::DFG::Graph::substitute): - * dfg/DFGNode.h: - (JSC::DFG::Node::hasArrayMode): - (JSC::DFG::Node::setArrayMode): - * dfg/DFGNodeType.h: - (DFG): - * dfg/DFGOperations.cpp: - * dfg/DFGPhase.h: - (DFG): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::useChildren): - (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): - (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): - (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-26 Filip Pizlo <fpizlo@apple.com> - - DFGGraph.h has a bogus comment about the nature of StorageAccessData - https://bugs.webkit.org/show_bug.cgi?id=95035 - - Reviewed by Oliver Hunt. - - The comment is both wrong (storage access instructions don't reference CheckStructure) - and highly redundant: of course it's the case that two structures may have the same - identifier. Our interference analyses currently don't care about this and make the - conservative assumptions when necessary (same identifier, same object -> must be same - property; same identifier, may be same object -> may be the same property). Better to - remove the bogus comment since the code that operates over this data structure is - fairly self-explanatory already. - - * dfg/DFGGraph.h: - (StorageAccessData): - -2012-08-25 Geoffrey Garen <ggaren@apple.com> - - Try a little harder to fix the Linux build. - - * runtime/JSActivation.cpp: - * runtime/JSActivation.h: - -2012-08-25 Geoffrey Garen <ggaren@apple.com> - - Try to fix the Linux build. - - * runtime/JSActivation.cpp: - -2012-08-25 Geoffrey Garen <ggaren@apple.com> - - Don't use malloc / destructors for activation objects - https://bugs.webkit.org/show_bug.cgi?id=94897 - - Reviewed by Oliver Hunt. - - 65% faster on v8-real-earley. - - Lots of boilerplate here, but the jist is this: - - (1) Use CopiedSpace instead of malloc to allocate the activation's - backing store. - - (2) Use MarkedSpace instead of ref-counting to allocate the symbol table. - - (3) ==> No more destructor. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::stronglyVisitStrongReferences): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::symbolTable): - (CodeBlock): - (JSC::GlobalCodeBlock::GlobalCodeBlock): - (JSC::FunctionCodeBlock::FunctionCodeBlock): - (FunctionCodeBlock): SymbolTable is a GC object now, so it gets a write - barrier and visit calls instead of ref-counting. I changed all CodeBlocks - to use shared symbol tables because the distinction between shared and - unshared hurt my head. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::resolve): - (JSC::BytecodeGenerator::resolveConstDecl): - (JSC::BytecodeGenerator::emitPutStaticVar): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): Sometimes, a period just wants - to be an arrow. And then C++ is there to accommodate. - - * jit/JITDriver.h: - (JSC::jitCompileFunctionIfAppropriate): - * runtime/Arguments.h: - (ArgumentsData): - (JSC::Arguments::setRegisters): - (Arguments): - (JSC::Arguments::argument): - (JSC::Arguments::finishCreation): - * runtime/Executable.cpp: - (JSC::FunctionExecutable::FunctionExecutable): - (JSC::ProgramExecutable::compileInternal): - (JSC::FunctionExecutable::compileForCallInternal): - (JSC::FunctionExecutable::compileForConstructInternal): - (JSC::FunctionExecutable::visitChildren): - * runtime/Executable.h: - (JSC::FunctionExecutable::symbolTable): - (FunctionExecutable): - * runtime/ExecutionHarness.h: - (JSC::prepareFunctionForExecution): I changed from WriteBarrier to - WriteBarrierBase so activations could reuse StorageBarrier and PropertyStorage. - - * runtime/JSActivation.cpp: - (JSC::JSActivation::JSActivation): - (JSC::JSActivation::finishCreation): Allocate the symbol table here, - after we're fully constructed, to avoid GC during initialization. - - (JSC::JSActivation::visitChildren): - (JSC::JSActivation::symbolTableGet): - (JSC::JSActivation::symbolTablePut): - (JSC::JSActivation::getOwnPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - * runtime/JSActivation.h: - (JSC::JSActivation::create): - (JSActivation): - (JSC::JSActivation::registerOffset): - (JSC): - (JSC::JSActivation::registerArraySize): - (JSC::JSActivation::registerArraySizeInBytes): - (JSC::JSActivation::tearOff): Tear-off zero-initializes all uncopied - registers. This makes it safe to copyAndAppend the full buffer in - visitChildren, without any extra checks. - - * runtime/JSCell.h: - (JSCell): Moved a shared default set of flags into this base class, so - I could use it in a few places. - - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: - (JSGlobalData): New structure for symbol tables. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - (JSC::JSGlobalObject::addStaticGlobals): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::symbolTableHasProperty): We don't need an inline - symbol table -- JSSymbolTableObject will GC allocate one for us. - - * runtime/JSObject.h: - (JSObject): - * runtime/JSSegmentedVariableObject.h: - (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): - * runtime/JSStaticScopeObject.cpp: - (JSC): - (JSC::JSStaticScopeObject::visitChildren): NULL check our register store - because finishCreation allocates an object now, so we may get marked - before we've assigned to our register store. - - * runtime/JSStaticScopeObject.h: - (JSC::JSStaticScopeObject::finishCreation): - (JSC::JSStaticScopeObject::JSStaticScopeObject): - (JSStaticScopeObject): No more destructor for this object, either, since - it no longer embeds a hash table. - - * runtime/JSSymbolTableObject.cpp: - (JSC::JSSymbolTableObject::visitChildren): - (JSC::JSSymbolTableObject::deleteProperty): - (JSC::JSSymbolTableObject::getOwnPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSC::JSSymbolTableObject::symbolTable): - (JSSymbolTableObject): - (JSC::JSSymbolTableObject::JSSymbolTableObject): - (JSC::JSSymbolTableObject::finishCreation): - (JSC::symbolTableGet): - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): SymbolTableObject allocates a symbol - table automatically if one isn't provided. (Activations provide their - own, which they get from compiled code.) - - * runtime/JSVariableObject.cpp: - (JSC): - * runtime/JSVariableObject.h: - (JSC::JSVariableObject::registerAt): - (JSC::JSVariableObject::addressOfRegisters): - (JSVariableObject): - (JSC::JSVariableObject::JSVariableObject): - (JSC::JSVariableObject::finishCreation): Removed a bunch of obsolete code. - Activations manage their registers directly now. - - * runtime/StorageBarrier.h: - (StorageBarrier): - (JSC::StorageBarrier::operator!): - - * runtime/SymbolTable.cpp: - (JSC): - (JSC::SharedSymbolTable::destroy): - * runtime/SymbolTable.h: - (JSC::SharedSymbolTable::create): - (SharedSymbolTable): - (JSC::SharedSymbolTable::createStructure): - (JSC::SharedSymbolTable::SharedSymbolTable): Boilerplat code to - make shared symbol table GC-allocated. - -2012-08-25 Filip Pizlo <fpizlo@apple.com> - - op_call should have ArrayProfiling for the benefit of array intrinsics - https://bugs.webkit.org/show_bug.cgi?id=95014 - - Reviewed by Sam Weinig. - - This is a performance-neutral change that just adds the profiling but does not - use it, yet. If in the future we wanted to make this kind of profiling cheaper - we could move it into specialized thunks for the relevant array intrinsics, but - I figure that if this much simpler change gives us what we need without any - discernable performance penalty then that's for the best. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitCall): - * jit/JITCall.cpp: - (JSC::JIT::compileOpCall): - * jit/JITCall32_64.cpp: - (JSC::JIT::compileOpCall): - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-08-25 Filip Pizlo <fpizlo@apple.com> - - The redundant phi elimination phase is not used and should be removed - https://bugs.webkit.org/show_bug.cgi?id=95006 - - Reviewed by Dan Bernstein. - - Just removing dead code. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * dfg/DFGDriver.cpp: - * dfg/DFGRedundantPhiEliminationPhase.cpp: Removed. - * dfg/DFGRedundantPhiEliminationPhase.h: Removed. - -2012-08-24 Benjamin Poulain <bpoulain@apple.com> +2012-10-05 Mark Hahnenberg <mhahnenberg@apple.com> - Unify Number to StringImpl conversion - https://bugs.webkit.org/show_bug.cgi?id=94879 + JSC should have a way to gather and log Heap memory use and pause times + https://bugs.webkit.org/show_bug.cgi?id=98431 Reviewed by Geoffrey Garen. - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * runtime/UString.cpp: - * runtime/UString.h: - (JSC::UString::number): - Update UString to directly use the common NumberToString implementation. - -2012-08-24 Oliver Hunt <oliver@apple.com> - - Always null check cells before marking - https://bugs.webkit.org/show_bug.cgi?id=94968 - - Reviewed by Geoffrey Garen. - - Originally we tried to minimise null checks by only null checking values - that we knew could be null, however given that we can't ever guarantee - when a GC will happen, we're better off just always assuming that a null - check will be necessary. This results in a much less fragile code base - as we can add GC allocations to object initialisers without having to - subsequently worry about whether the object we are initialising will need - to add a bunch of null checks in its visitChildren implementation. - - * heap/MarkStack.cpp: - (JSC::MarkStack::internalAppend): - * heap/MarkStackInlineMethods.h: - (JSC::MarkStack::append): - (JSC::MarkStack::appendUnbarrieredPointer): - * runtime/Structure.h: - (JSC::MarkStack::internalAppend): - -2012-08-23 Oliver Hunt <oliver@apple.com> - - Autogenerate Opcode definitions - https://bugs.webkit.org/show_bug.cgi?id=94840 - - Reviewed by Gavin Barraclough. - - Start the process of autogenerating the code emission for the bytecode. - We'll just start with automatic generation of the list of Opcodes as that - requires the actual definition of the opcodes, and the logic for parsing - them. - - Due to some rather annoying dependency cycles, this initial version has - the OpcodeDefinitions.h file checked into the tree, although with some - work I hope to be able to fix that. - - * DerivedSources.make: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/Opcode.h: - Include OpcodeDefinitions.h as our definitive source of info - about the opcodes. - * bytecode/OpcodeDefinitions.h: Added. - Autogenerated file - * bytecode/opcodes: Added. - The new opcode definition file - * opcode_definition_generator.py: Added. - (generateOpcodeDefinition): - (generate): - Module that generates the content for OpcodeDefinitions.h - * opcode_generator.py: Added. - (printUsage): - (main): - Driver script - * opcode_parser.py: Added. - Simple parser for the opcode definitions. - -2011-08-23 Geoffrey Garen <ggaren@apple.com> - - Unreviewed, rolling out r126505. - http://trac.webkit.org/changeset/126505 - https://bugs.webkit.org/show_bug.cgi?id=94840 - - Caused testapi to crash on launch - - * DerivedSources.make: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/OpcodeDefinitions.h: Removed. - * bytecode/opcodes: Removed. - * opcode_definition_generator.py: Removed. - * opcode_generator.py: Removed. - * opcode_parser.py: Removed. - -2012-08-23 Oliver Hunt <oliver@apple.com> - - Autogenerate Opcode definitions - https://bugs.webkit.org/show_bug.cgi?id=94840 - - Reviewed by Gavin Barraclough. - - Start the process of autogenerating the code emission for the bytecode. - We'll just start with automatic generation of the list of Opcodes as that - requires the actual definition of the opcodes, and the logic for parsing - them. - - Due to some rather annoying dependency cycles, this initial version has - the OpcodeDefinitions.h file checked into the tree, although with some - work I hope to be able to fix that. - - * DerivedSources.make: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/Opcode.h: - Include OpcodeDefinitions.h as our definitive source of info - about the opcodes. - * bytecode/OpcodeDefinitions.h: Added. - Autogenerated file - * bytecode/opcodes: Added. - The new opcode definition file - * opcode_definition_generator.py: Added. - (generateOpcodeDefinition): - (generate): - Module that generates the content for OpcodeDefinitions.h - * opcode_generator.py: Added. - (printUsage): - (main): - Driver script - * opcode_parser.py: Added. - Simple parser for the opcode definitions. - -2012-08-23 Mark Hahnenberg <mhahnenberg@apple.com> - - Change behavior of MasqueradesAsUndefined to better accommodate DFG changes - https://bugs.webkit.org/show_bug.cgi?id=93884 - - Reviewed by Filip Pizlo. - - With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of - MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines, - we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined - objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject). - For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not - masquerade as undefined within frame B, but it will continue to masquerade in frame A. - - There are two primary changes that are taking place here. One is to thread the ExecState* through - JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's - JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two - are distinct, then the object cannot MasqueradeAsUndefined. - - The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined - flag in the Structure is checked. For C++ code, this check has been factored into its own function in - Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has - had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed - through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers - that are MasqueradesAsUndefined. - - * API/JSValueRef.cpp: - (JSValueToBoolean): - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * bytecode/Watchpoint.h: - (WatchpointSet): - * debugger/DebuggerCallFrame.h: - (JSC::DebuggerCallFrame::callFrame): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/ArrayPrototype.cpp: - (JSC::arrayProtoFuncFilter): - (JSC::arrayProtoFuncEvery): - (JSC::arrayProtoFuncSome): - * runtime/BooleanConstructor.cpp: - (JSC::constructBoolean): - (JSC::callBooleanConstructor): - * runtime/JSCell.h: - (JSCell): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint): - * runtime/JSString.h: - (JSC::JSCell::toBoolean): - (JSC::JSValue::toBoolean): - * runtime/JSValue.h: - * runtime/ObjectConstructor.cpp: - (JSC::toPropertyDescriptor): - * runtime/Operations.cpp: - (JSC::jsTypeStringForValue): - (JSC::jsIsObjectType): - * runtime/Operations.h: - (JSC): - (JSC::JSValue::equalSlowCaseInline): - * runtime/RegExpConstructor.cpp: - (JSC::setRegExpConstructorMultiline): - * runtime/RegExpPrototype.cpp: - (JSC::regExpProtoFuncToString): - * runtime/Structure.h: - (Structure): - (JSC::Structure::globalObjectOffset): - (JSC::Structure::masqueradesAsUndefined): - (JSC): - -2012-08-23 Mark Rowe <mrowe@apple.com> - - Make JavaScriptCore build with the latest version of clang. - - Reviewed by Dan Bernstein. - - * heap/MachineStackMarker.cpp: - (JSC::MachineThreads::MachineThreads): The m_heap member is only used within - assertions, so guard its initialization with !ASSERT_DISABLED. - * heap/MachineStackMarker.h: - (MachineThreads): Ditto for its declaration. - * jit/JITStubCall.h: - (JSC::JITStubCall::JITStubCall): The m_returnType member is only used within - assertions or if we're using JSVALUE32_64, so guard its uses with the appropriate - #if. - (JITStubCall): Ditto. - -2012-08-23 Christophe Dumez <christophe.dumez@intel.com> - - 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-22 Filip Pizlo <fpizlo@apple.com> - - Array accesses should remember what kind of array they are predicted to access - https://bugs.webkit.org/show_bug.cgi?id=94448 - - Reviewed by Gavin Barraclough. - - Introduced the notion of DFG::Array::Mode, stored in node.arrayMode(), which allows nodes - to remember how they decided to access arrays. This permits the bytecode parser to "lock in" - the mode of access if it has profiling at its disposal, and it also allows the prediction - propagator to do a fixup of the array mode later in the optimization fixpoint. - - This patch adds a healthy amount of new capability (specifically the ability of the parser - to lock in an array mode regardless of type predictions) and it also blows away a lot of - messy code. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGArrayMode.cpp: Added. - (DFG): - (JSC::DFG::fromObserved): - (JSC::DFG::refineArrayMode): - (JSC::DFG::modeAlreadyChecked): - (JSC::DFG::modeToString): - * dfg/DFGArrayMode.h: Added. - (DFG): - (JSC::DFG::canCSEStorage): - (JSC::DFG::modeForPut): - (JSC::DFG::modesCompatibleForStorageLoad): - (JSC::DFG::modeSupportsLength): - * dfg/DFGByteCodeParser.cpp: - (ByteCodeParser): - (JSC::DFG::ByteCodeParser::getArrayModeWithoutOSRExit): - (JSC::DFG::ByteCodeParser::getArrayMode): - (JSC::DFG::ByteCodeParser::handleIntrinsic): - (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::performNodeCSE): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::byValIsPure): - (JSC::DFG::Graph::clobbersWorld): - * dfg/DFGNode.h: - (JSC::DFG::Node::hasArrayMode): - (Node): - (JSC::DFG::Node::arrayMode): - (JSC::DFG::Node::setArrayMode): - * dfg/DFGNodeType.h: - (DFG): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): - (DFG): - (JSC::DFG::SpeculativeJIT::speculateArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnString): - (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): - (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): - (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-22 Geoffrey Garen <ggaren@apple.com> - - ThreadRestrictionVerifier should be opt-in, not opt-out - https://bugs.webkit.org/show_bug.cgi?id=94761 - - Reviewed by Mark Hahnenberg. - - Removed explicit calls to disable the verifier, since it's off by default now. + In order to improve our infrastructure for benchmark-driven development, we should + have a centralized method of gathering and logging various statistics about the state + of the JS heap. This would allow us to create and to use other tools to analyze the + output of the VM after running various workloads. - * parser/SourceProvider.h: - (JSC::SourceProvider::SourceProvider): - (SourceProvider): - * runtime/SymbolTable.h: - (JSC::SharedSymbolTable::SharedSymbolTable): + The first two statistics that might be interesting is memory use by JSC and GC pause + times. We can control whether this recording happens through the use of the Options + class, allowing us to either use environment variables or command line flags. -2012-08-22 Mark Hahnenberg <mhahnenberg@apple.com> - - Separate MarkStackThreadSharedData from MarkStack - https://bugs.webkit.org/show_bug.cgi?id=94294 - - Reviewed by Filip Pizlo. - - MarkStackThreadSharedData is soon going to have data to allow for a parallel copying - mode too, so to separate our concerns we should split it out into its own set of files - and rename it to GCThreadSharedData. For now this is purely a cosmetic refactoring. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * heap/GCThreadSharedData.cpp: Added. - (JSC): - (JSC::GCThreadSharedData::resetChildren): - (JSC::GCThreadSharedData::childVisitCount): - (JSC::GCThreadSharedData::markingThreadMain): - (JSC::GCThreadSharedData::markingThreadStartFunc): - (JSC::GCThreadSharedData::GCThreadSharedData): - (JSC::GCThreadSharedData::~GCThreadSharedData): - (JSC::GCThreadSharedData::reset): - * heap/GCThreadSharedData.h: Added. - (JSC): - (GCThreadSharedData): + * heap/Heap.cpp: + (JSC::Heap::collect): If we finish a collection and are still over our set GC heap size, + we end the program immediately and report an error. Also added recording of pause times. * heap/Heap.h: (Heap): - * heap/ListableHandler.h: - (ListableHandler): - * heap/MarkStack.cpp: - (JSC::MarkStack::MarkStack): - (JSC::MarkStack::~MarkStack): - * heap/MarkStack.h: - (JSC): - (MarkStack): - (JSC::MarkStack::sharedData): - * heap/MarkStackInlineMethods.h: Added. - (JSC): - (JSC::MarkStack::append): - (JSC::MarkStack::appendUnbarrieredPointer): - (JSC::MarkStack::appendUnbarrieredValue): - (JSC::MarkStack::internalAppend): - (JSC::MarkStack::addWeakReferenceHarvester): - (JSC::MarkStack::addUnconditionalFinalizer): - (JSC::MarkStack::addOpaqueRoot): - (JSC::MarkStack::containsOpaqueRoot): - (JSC::MarkStack::opaqueRootCount): - * heap/SlotVisitor.h: - (JSC): - (SlotVisitor): - (JSC::SlotVisitor::SlotVisitor): - -2012-08-22 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - Fix JSC build when DFG-JIT is disabled - https://bugs.webkit.org/show_bug.cgi?id=94694 - - Reviewed by Csaba Osztrogonác. - - Adding an appropriate guard for fixing the build. - - * bytecode/ResolveGlobalStatus.cpp: - (JSC): - -2012-08-21 Mark Lam <mark.lam@apple.com> - - Introducing the VMInspector for VM debugging use. - https://bugs.webkit.org/show_bug.cgi?id=94613. - - Reviewed by Filip Pizlo. - - Adding some utility functions for debugging the VM. This code is - presently #ifdef'd out by default. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * interpreter/CallFrame.h: - (ExecState): - * interpreter/VMInspector.cpp: Added. - (JSC): - (JSC::VMInspector::getTypeName): - (JSC::VMInspector::dumpFrame0): - (JSC::VMInspector::dumpFrame): - (JSC::VMInspector::countFrames): - * interpreter/VMInspector.h: Added. + (JSC::Heap::shouldCollect): When we set a specific GC heap size through Options, we + ignore all other heuristics on when we should collect and instead only ask if we're + greater than the amount specified in the Option value. This allows us to view time/memory + tradeoffs more clearly. + * heap/HeapStatistics.cpp: Added. + (JSC): + (JSC::HeapStatistics::initialize): + (JSC::HeapStatistics::recordGCPauseTime): + (JSC::HeapStatistics::logStatistics): + (JSC::HeapStatistics::exitWithFailure): + (JSC::HeapStatistics::reportSuccess): + (JSC::HeapStatistics::parseMemoryAmount): + (StorageStatistics): + (JSC::StorageStatistics::StorageStatistics): + (JSC::StorageStatistics::operator()): + (JSC::StorageStatistics::objectWithOutOfLineStorageCount): + (JSC::StorageStatistics::objectCount): + (JSC::StorageStatistics::storageSize): + (JSC::StorageStatistics::storageCapacity): + (JSC::HeapStatistics::showObjectStatistics): Moved the old showHeapStatistics (renamed to showObjectStatistics) + to try to start collecting our various memory statistics gathering/reporting mechanisms scattered throughout the + codebase into one place. + * heap/HeapStatistics.h: Added. + (JSC): + (HeapStatistics): + * jsc.cpp: + (main): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): We need to initialize our data structures for recording + statistics if necessary. + * runtime/Options.cpp: Add new Options for the various types of statistics we'll be gathering. + (JSC::parse): (JSC): - (VMInspector): - -2012-08-21 Filip Pizlo <fpizlo@apple.com> - - A patchable GetById right after a watchpoint should have the appropriate nop padding - https://bugs.webkit.org/show_bug.cgi?id=94635 - - Reviewed by Mark Hahnenberg. - - * assembler/AbstractMacroAssembler.h: - (JSC::AbstractMacroAssembler::padBeforePatch): - (AbstractMacroAssembler): - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch): - (JSC::MacroAssemblerARMv7::moveWithPatch): - (JSC::MacroAssemblerARMv7::patchableJump): - * assembler/MacroAssemblerX86.h: - (JSC::MacroAssemblerX86::moveWithPatch): - (JSC::MacroAssemblerX86::branchPtrWithPatch): - (JSC::MacroAssemblerX86::storePtrWithPatch): - * assembler/MacroAssemblerX86Common.h: - (JSC::MacroAssemblerX86Common::load32WithAddressOffsetPatch): - (JSC::MacroAssemblerX86Common::load32WithCompactAddressOffsetPatch): - (JSC::MacroAssemblerX86Common::loadCompactWithAddressOffsetPatch): - (JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch): - * assembler/MacroAssemblerX86_64.h: - (JSC::MacroAssemblerX86_64::loadPtrWithAddressOffsetPatch): - (JSC::MacroAssemblerX86_64::loadPtrWithCompactAddressOffsetPatch): - (JSC::MacroAssemblerX86_64::storePtrWithAddressOffsetPatch): - (JSC::MacroAssemblerX86_64::moveWithPatch): - * jit/JumpReplacementWatchpoint.cpp: - (JSC::JumpReplacementWatchpoint::fireInternal): - -2012-08-20 Mark Lam <mark.lam@apple.com> - - 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 <mark.lam@apple.com> - - 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::Options::initialize): Initialize the various new options using environment variables. + (JSC::Options::dumpOption): + * runtime/Options.h: (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-20 Filip Pizlo <fpizlo@apple.com> - - fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html on 32-bit - https://bugs.webkit.org/show_bug.cgi?id=94538 - - Reviewed by Mark Hahnenberg. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): - -2012-08-20 Filip Pizlo <fpizlo@apple.com> - - fast/js/dfg-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html crashes on 32-bit - https://bugs.webkit.org/show_bug.cgi?id=94026 - - Reviewed by Mark Hahnenberg. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): - -2012-08-19 Filip Pizlo <fpizlo@apple.com> - - The relationship between abstract values and structure transition watchpoints should be rationalized - https://bugs.webkit.org/show_bug.cgi?id=94205 - - Reviewed by Geoffrey Garen. - - This patch does a number of things related to the handling of the abstract values - arrising from values with structures known to be watchpointable: - - - This rationalizes the relationship between the structure that we know an object - to have *right now* based on having executed a check against that structure, and - the structure that we know the object could have *in the future* based on a type - check executed in the past over a structure that was watchpointable. - - - We use the above to assert that structure transition watchpoints are being used - soundly. - - - We use the above to strength reduce CheckStructure into StructureTransitionWatchpoint - whenever possible. - - - This rationalizes the handling of CFA over constants that appeared in the bytecode. - If at compile-time the constant has a watchpointable structure, then we can prove - what structures it may have in the future. The analysis uses this to both assert - that structure transition watchpoints are being used correctly, and to find - opportunities for using them more aggressively. - - The net effect of all of these changes is that OSR entry should work more smoothly. - It may also be a slight win due to strength reductions, though most of those strength - reductions would have already been done by the parser and the structure check hoister. - - * GNUmakefile.list.am: - * JavaScriptCore.xcodeproj/project.pbxproj: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::beginBasicBlock): - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (DFG): - (JSC::DFG::AbstractValue::clear): - (JSC::DFG::AbstractValue::isClear): - (JSC::DFG::AbstractValue::makeTop): - (JSC::DFG::AbstractValue::clobberStructures): - (JSC::DFG::AbstractValue::isTop): - (JSC::DFG::AbstractValue::setFuturePossibleStructure): - (AbstractValue): - (JSC::DFG::AbstractValue::filterFuturePossibleStructure): - (JSC::DFG::AbstractValue::setMostSpecific): - (JSC::DFG::AbstractValue::set): - (JSC::DFG::AbstractValue::operator==): - (JSC::DFG::AbstractValue::merge): - (JSC::DFG::AbstractValue::filter): - (JSC::DFG::AbstractValue::filterValueByType): - (JSC::DFG::AbstractValue::validateType): - (JSC::DFG::AbstractValue::validate): - (JSC::DFG::AbstractValue::checkConsistency): - (JSC::DFG::AbstractValue::dump): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::checkStructureLoadElimination): - (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGNode.h: - (JSC::DFG::Node::convertToStructureTransitionWatchpoint): - (Node): - (JSC::DFG::Node::hasStructure): - * dfg/DFGNodeType.h: - (DFG): - * dfg/DFGOSREntry.cpp: - (JSC::DFG::prepareOSREntry): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): - (JSC::DFG::SpeculativeJIT::forwardSpeculationWatchpoint): - (DFG): - (JSC::DFG::SpeculativeJIT::speculationWatchpointWithConditionalDirection): - (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): - (JSC::DFG::SpeculativeJIT::speculateArray): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStructureAbstractValue.h: Added. - (DFG): - (StructureAbstractValue): - (JSC::DFG::StructureAbstractValue::StructureAbstractValue): - (JSC::DFG::StructureAbstractValue::clear): - (JSC::DFG::StructureAbstractValue::makeTop): - (JSC::DFG::StructureAbstractValue::top): - (JSC::DFG::StructureAbstractValue::add): - (JSC::DFG::StructureAbstractValue::addAll): - (JSC::DFG::StructureAbstractValue::contains): - (JSC::DFG::StructureAbstractValue::isSubsetOf): - (JSC::DFG::StructureAbstractValue::doesNotContainAnyOtherThan): - (JSC::DFG::StructureAbstractValue::isSupersetOf): - (JSC::DFG::StructureAbstractValue::filter): - (JSC::DFG::StructureAbstractValue::isClear): - (JSC::DFG::StructureAbstractValue::isTop): - (JSC::DFG::StructureAbstractValue::isClearOrTop): - (JSC::DFG::StructureAbstractValue::isNeitherClearNorTop): - (JSC::DFG::StructureAbstractValue::size): - (JSC::DFG::StructureAbstractValue::at): - (JSC::DFG::StructureAbstractValue::operator[]): - (JSC::DFG::StructureAbstractValue::last): - (JSC::DFG::StructureAbstractValue::speculationFromStructures): - (JSC::DFG::StructureAbstractValue::hasSingleton): - (JSC::DFG::StructureAbstractValue::singleton): - (JSC::DFG::StructureAbstractValue::operator==): - (JSC::DFG::StructureAbstractValue::dump): - (JSC::DFG::StructureAbstractValue::topValue): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-17 Filip Pizlo <fpizlo@apple.com> - - The current state of the call frame should be taken into account in the DFG for both predictions and proofs - https://bugs.webkit.org/show_bug.cgi?id=94412 - Reviewed by Geoffrey Garen. +2012-10-04 Rik Cabanier <cabanier@adobe.com> - This ensures that no matter how smart the DFG gets, it'll always know through - which entrypoint OSR will try to enter, and with which values it will attempt - to do so. For prologue OSR, this has no effect other than adding the current - arguments to the argument predictions. For loop OSR, this makes our treatment - of the loop slightly more conservative - just conservative enough to ensure - that OSR succeeds. + Turn Compositing on by default in WebKit build + https://bugs.webkit.org/show_bug.cgi?id=98315 - * bytecode/CodeBlock.cpp: - (JSC::ProgramCodeBlock::compileOptimized): - (JSC::EvalCodeBlock::compileOptimized): - (JSC::FunctionCodeBlock::compileOptimized): - * bytecode/CodeBlock.h: - (CodeBlock): - (ProgramCodeBlock): - (EvalCodeBlock): - (FunctionCodeBlock): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::initialize): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::setMostSpecific): - (AbstractValue): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions): - (JSC::DFG::ByteCodeParser::parse): - * dfg/DFGDriver.cpp: - (JSC::DFG::compile): - (JSC::DFG::tryCompile): - (JSC::DFG::tryCompileFunction): - * dfg/DFGDriver.h: - (DFG): - (JSC::DFG::tryCompile): - (JSC::DFG::tryCompileFunction): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::Graph): - (Graph): - * jit/JITDriver.h: - (JSC::jitCompileIfAppropriate): - (JSC::jitCompileFunctionIfAppropriate): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * runtime/Executable.cpp: - (JSC::EvalExecutable::compileOptimized): - (JSC::EvalExecutable::compileInternal): - (JSC::ProgramExecutable::compileOptimized): - (JSC::ProgramExecutable::compileInternal): - (JSC::FunctionExecutable::compileOptimizedForCall): - (JSC::FunctionExecutable::compileOptimizedForConstruct): - (JSC::FunctionExecutable::compileForCallInternal): - (JSC::FunctionExecutable::compileForConstructInternal): - * runtime/Executable.h: - (EvalExecutable): - (ProgramExecutable): - (FunctionExecutable): - (JSC::FunctionExecutable::compileOptimizedFor): - * runtime/ExecutionHarness.h: - (JSC::prepareForExecution): - (JSC::prepareFunctionForExecution): - -2012-08-17 Filip Pizlo <fpizlo@apple.com> - - DFG CSE should be more honest about when it changed the IR - https://bugs.webkit.org/show_bug.cgi?id=94408 - - Reviewed by Geoffrey Garen. - - The CSE phase now always returns true if it changed the IR. - - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::setReplacement): - (JSC::DFG::CSEPhase::eliminate): - (JSC::DFG::CSEPhase::performNodeCSE): - -2012-08-17 Filip Pizlo <fpizlo@apple.com> - - DFG is still too pessimistic about what constitutes a side-effect on array accesses - https://bugs.webkit.org/show_bug.cgi?id=94309 - - Reviewed by Geoffrey Garen. - - This change means that even if structure transition watchpoints are not used for - hoisting of clobbered structure checks, we still retain good performance on the - benchmarks we care about. That's important, since butterflies will likely make - most array structures not watchpointable. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-17 Milian Wolff <milian.wolff@kdab.com> - - [Qt] QNX build fails due to ctype usage in system headers - https://bugs.webkit.org/show_bug.cgi?id=93849 - - Reviewed by Simon Hausmann. - - Move the check for whether DisallowCType should be active or not - to the DisallowCType.h header. This way, we can update the list - of platforms or OSes which do not work with this header in a - central place. All users can now safely include the header - and do not need to place custom guards around it. - - * config.h: - -2012-08-16 Simon Hausmann <simon.hausmann@nokia.com> - - [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap - https://bugs.webkit.org/show_bug.cgi?id=93872 - - Reviewed by Kenneth Rohde Christiansen. - - * Target.pri: Add missing JSWeakObjectMap file to build. - -2012-08-16 Filip Pizlo <fpizlo@apple.com> - - Structure check hoisting should be less expensive - https://bugs.webkit.org/show_bug.cgi?id=94201 - - Reviewed by Mark Hahnenberg. - - This appears like a broad win on short-running programs. - - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGDriver.cpp: - (JSC::DFG::compile): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::compareAndSwap): - (Graph): - (JSC::DFG::Graph::substitute): - (JSC::DFG::Graph::substituteGetLocal): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-16 Filip Pizlo <fpizlo@apple.com> - - All op_resolve_global instructions should end up in the list of global resolve instructions - https://bugs.webkit.org/show_bug.cgi?id=94247 - <rdar://problem/12103500> - - Reviewed by Mark Hahnenberg. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitResolveWithBase): - -2012-08-15 Bruno de Oliveira Abinader <bruno.abinader@basyskom.com> - - [css3-text] Add CSS3 Text decoration compile flag - https://bugs.webkit.org/show_bug.cgi?id=93863 - - Reviewed by Julien Chaffraix. + Reviewed by Simon Fraser. - This patch handles the compile flag implementation, which will come disabled by - default, thus not exposing the CSS3 text decoration features to the web, unless - when explicitly enabling it with "--css3-text-decoration" build parameter. + enable -webkit-blend-mode on trunk. * Configurations/FeatureDefines.xcconfig: -2012-08-15 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r125687. - http://trac.webkit.org/changeset/125687 - https://bugs.webkit.org/show_bug.cgi?id=94147 - - It broke the whole world (Requested by Ossy_night on #webkit). - - * API/JSValueRef.cpp: - (JSValueToBoolean): - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * bytecode/Watchpoint.h: - (WatchpointSet): - * debugger/DebuggerCallFrame.h: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/ArrayPrototype.cpp: - (JSC::arrayProtoFuncFilter): - (JSC::arrayProtoFuncEvery): - (JSC::arrayProtoFuncSome): - * runtime/BooleanConstructor.cpp: - (JSC::constructBoolean): - (JSC::callBooleanConstructor): - * runtime/JSCell.h: - (JSCell): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - * runtime/JSString.h: - (JSC::JSCell::toBoolean): - (JSC::JSValue::toBoolean): - * runtime/JSValue.h: - * runtime/ObjectConstructor.cpp: - (JSC::toPropertyDescriptor): - * runtime/Operations.cpp: - (JSC::jsTypeStringForValue): - (JSC::jsIsObjectType): - * runtime/Operations.h: - (JSC): - (JSC::JSValue::equalSlowCaseInline): - * runtime/RegExpConstructor.cpp: - (JSC::setRegExpConstructorMultiline): - * runtime/RegExpPrototype.cpp: - (JSC::regExpProtoFuncToString): - * runtime/Structure.h: - -2012-08-15 Gabor Ballabas <gaborb@inf.u-szeged.hu> +2012-10-04 Michael Saboff <msaboff@apple.com> - Buildfix after r125541 - https://bugs.webkit.org/show_bug.cgi?id=94097 + Crash in Safari at com.apple.JavaScriptCore: WTF::StringImpl::is8Bit const + 12 + https://bugs.webkit.org/show_bug.cgi?id=98433 - Reviewed by Filip Pizlo. - - r125541 has broken the traditional ARM port build of JSC. - - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::neg32): - (JSC::MacroAssemblerARM::xor32): - -2012-08-14 Mark Hahnenberg <mhahnenberg@apple.com> - - Change behavior of MasqueradesAsUndefined to better accommodate DFG changes - https://bugs.webkit.org/show_bug.cgi?id=93884 - - Reviewed by Geoffrey Garen. + Reviewed by Jessie Berlin. - With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of - MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines, - we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined - objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject). - For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not - masquerade as undefined within frame B, but it will continue to masquerade in frame A. - - There are two primary changes that are taking place here. One is to thread the ExecState* through - JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's - JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two - are distinct, then the object cannot MasqueradeAsUndefined. - - The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined - flag in the Structure is checked. For C++ code, this check has been factored into its own function in - Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has - had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed - through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers - that are MasqueradesAsUndefined. + The problem is due to a String with a null StringImpl (i.e. a null string). + Added a length check before the is8Bit() check since length() checks for a null StringImpl. Changed the + characters16() call to characters() since it can handle a null StringImpl as well. * API/JSValueRef.cpp: - (JSValueToBoolean): - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * bytecode/Watchpoint.h: - (WatchpointSet): - * debugger/DebuggerCallFrame.h: - (JSC::DebuggerCallFrame::callFrame): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::compile): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/ArrayPrototype.cpp: - (JSC::arrayProtoFuncFilter): - (JSC::arrayProtoFuncEvery): - (JSC::arrayProtoFuncSome): - * runtime/BooleanConstructor.cpp: - (JSC::constructBoolean): - (JSC::callBooleanConstructor): - * runtime/JSCell.h: - (JSCell): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::JSGlobalObject): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint): - * runtime/JSString.h: - (JSC::JSCell::toBoolean): - (JSC::JSValue::toBoolean): - * runtime/JSValue.h: - * runtime/ObjectConstructor.cpp: - (JSC::toPropertyDescriptor): - * runtime/Operations.cpp: - (JSC::jsTypeStringForValue): - (JSC::jsIsObjectType): - * runtime/Operations.h: - (JSC): - (JSC::JSValue::equalSlowCaseInline): - * runtime/RegExpConstructor.cpp: - (JSC::setRegExpConstructorMultiline): - * runtime/RegExpPrototype.cpp: - (JSC::regExpProtoFuncToString): - * runtime/Structure.h: - (Structure): - (JSC::Structure::globalObjectOffset): - (JSC::Structure::masqueradesAsUndefined): - (JSC): - -2012-08-14 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, build fix for !ENABLE(DFG_JIT) - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-08-13 Filip Pizlo <fpizlo@apple.com> - - Array checks should use the structure, not the class info - https://bugs.webkit.org/show_bug.cgi?id=93150 - - Reviewed by Mark Hahnenberg. - - This changes all array checks used in array accesses (get, put, get length, - push, pop) to use the structure, not the class info. Additionally, these - checks in the LLInt and baseline JIT record the structure in an ArrayProfile, - so that the DFG can know exactly what structure to check for. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/ArrayProfile.cpp: Added. - (JSC): - (JSC::ArrayProfile::computeUpdatedPrediction): - * bytecode/ArrayProfile.h: Added. - (JSC): - (JSC::arrayModeFromStructure): - (ArrayProfile): - (JSC::ArrayProfile::ArrayProfile): - (JSC::ArrayProfile::bytecodeOffset): - (JSC::ArrayProfile::addressOfLastSeenStructure): - (JSC::ArrayProfile::observeStructure): - (JSC::ArrayProfile::expectedStructure): - (JSC::ArrayProfile::structureIsPolymorphic): - (JSC::ArrayProfile::hasDefiniteStructure): - (JSC::ArrayProfile::observedArrayModes): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::CodeBlock::getArrayProfile): - (JSC): - (JSC::CodeBlock::getOrAddArrayProfile): - (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::executionEntryCount): - (JSC::CodeBlock::numberOfArrayProfiles): - (JSC::CodeBlock::arrayProfiles): - (JSC::CodeBlock::addArrayProfile): - (CodeBlock): - * bytecode/Instruction.h: - (JSC): - (JSC::Instruction::Instruction): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitGetArgumentByVal): - (JSC::BytecodeGenerator::emitGetByVal): - (JSC::BytecodeGenerator::emitPutByVal): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::initialize): - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (JSC::DFG::StructureAbstractValue::hasSingleton): - (StructureAbstractValue): - (JSC::DFG::StructureAbstractValue::singleton): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::speculateArray): - (DFG): - (JSC::DFG::SpeculativeJIT::compile): - (JSC::DFG::SpeculativeJIT::checkArgumentTypes): - (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::privateCompilePatchGetArrayLength): - * llint/LLIntOffsetsExtractor.cpp: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/Structure.h: - (Structure): - (JSC::Structure::classInfoOffset): - -2012-08-14 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - Rename functions in the ARM port of DFG-JIT for better code readability. - https://bugs.webkit.org/show_bug.cgi?id=93609 - - Reviewed by Zoltan Herczeg. - - Rename functions in the ARM port of DFG-JIT for better code - readability, and for following the WebKit coding style - wherever it is possible. - - * assembler/ARMAssembler.cpp: - (JSC::ARMAssembler::genInt): - (JSC::ARMAssembler::getImm): - (JSC::ARMAssembler::moveImm): - (JSC::ARMAssembler::encodeComplexImm): - (JSC::ARMAssembler::dataTransfer32): - (JSC::ARMAssembler::baseIndexTransfer32): - (JSC::ARMAssembler::dataTransfer16): - (JSC::ARMAssembler::baseIndexTransfer16): - (JSC::ARMAssembler::dataTransferFloat): - (JSC::ARMAssembler::baseIndexTransferFloat): - * assembler/ARMAssembler.h: - (JSC::ARMAssembler::bitAnd): - (JSC::ARMAssembler::bitAnds): - (JSC::ARMAssembler::eor): - (JSC::ARMAssembler::eors): - (JSC::ARMAssembler::sub): - (JSC::ARMAssembler::subs): - (JSC::ARMAssembler::rsb): - (JSC::ARMAssembler::rsbs): - (JSC::ARMAssembler::add): - (JSC::ARMAssembler::adds): - (JSC::ARMAssembler::adc): - (JSC::ARMAssembler::adcs): - (JSC::ARMAssembler::sbc): - (JSC::ARMAssembler::sbcs): - (JSC::ARMAssembler::rsc): - (JSC::ARMAssembler::rscs): - (JSC::ARMAssembler::tst): - (JSC::ARMAssembler::teq): - (JSC::ARMAssembler::cmp): - (JSC::ARMAssembler::cmn): - (JSC::ARMAssembler::orr): - (JSC::ARMAssembler::orrs): - (JSC::ARMAssembler::mov): - (JSC::ARMAssembler::movw): - (JSC::ARMAssembler::movt): - (JSC::ARMAssembler::movs): - (JSC::ARMAssembler::bic): - (JSC::ARMAssembler::bics): - (JSC::ARMAssembler::mvn): - (JSC::ARMAssembler::mvns): - (JSC::ARMAssembler::mul): - (JSC::ARMAssembler::muls): - (JSC::ARMAssembler::mull): - (JSC::ARMAssembler::vmov_f64): - (JSC::ARMAssembler::vadd_f64): - (JSC::ARMAssembler::vdiv_f64): - (JSC::ARMAssembler::vsub_f64): - (JSC::ARMAssembler::vmul_f64): - (JSC::ARMAssembler::vcmp_f64): - (JSC::ARMAssembler::vsqrt_f64): - (JSC::ARMAssembler::vabs_f64): - (JSC::ARMAssembler::vneg_f64): - (JSC::ARMAssembler::ldrImmediate): - (JSC::ARMAssembler::ldrUniqueImmediate): - (JSC::ARMAssembler::dtrUp): - (JSC::ARMAssembler::dtrUpRegister): - (JSC::ARMAssembler::dtrDown): - (JSC::ARMAssembler::dtrDownRegister): - (JSC::ARMAssembler::halfDtrUp): - (JSC::ARMAssembler::halfDtrUpRegister): - (JSC::ARMAssembler::halfDtrDown): - (JSC::ARMAssembler::halfDtrDownRegister): - (JSC::ARMAssembler::doubleDtrUp): - (JSC::ARMAssembler::doubleDtrDown): - (JSC::ARMAssembler::push): - (JSC::ARMAssembler::pop): - (JSC::ARMAssembler::poke): - (JSC::ARMAssembler::peek): - (JSC::ARMAssembler::vmov_vfp64): - (JSC::ARMAssembler::vmov_arm64): - (JSC::ARMAssembler::vmov_vfp32): - (JSC::ARMAssembler::vmov_arm32): - (JSC::ARMAssembler::vcvt_f64_s32): - (JSC::ARMAssembler::vcvt_s32_f64): - (JSC::ARMAssembler::vcvt_u32_f64): - (JSC::ARMAssembler::vcvt_f64_f32): - (JSC::ARMAssembler::vcvt_f32_f64): - (JSC::ARMAssembler::clz): - (JSC::ARMAssembler::lslRegister): - (JSC::ARMAssembler::lsrRegister): - (JSC::ARMAssembler::asrRegister): - (JSC::ARMAssembler::align): - (JSC::ARMAssembler::loadBranchTarget): - (JSC::ARMAssembler::vmov): - * assembler/MacroAssemblerARM.cpp: - (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::add32): - (JSC::MacroAssemblerARM::and32): - (JSC::MacroAssemblerARM::lshift32): - (JSC::MacroAssemblerARM::mul32): - (JSC::MacroAssemblerARM::or32): - (JSC::MacroAssemblerARM::rshift32): - (JSC::MacroAssemblerARM::urshift32): - (JSC::MacroAssemblerARM::sub32): - (JSC::MacroAssemblerARM::xor32): - (JSC::MacroAssemblerARM::countLeadingZeros32): - (JSC::MacroAssemblerARM::convertibleLoadPtr): - (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch): - (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch): - (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch): - (JSC::MacroAssemblerARM::store32): - (JSC::MacroAssemblerARM::pop): - (JSC::MacroAssemblerARM::push): - (JSC::MacroAssemblerARM::move): - (JSC::MacroAssemblerARM::swap): - (JSC::MacroAssemblerARM::branch32): - (JSC::MacroAssemblerARM::branchTest32): - (JSC::MacroAssemblerARM::mull32): - (JSC::MacroAssemblerARM::branchSub32): - (JSC::MacroAssemblerARM::compare32): - (JSC::MacroAssemblerARM::test32): - (JSC::MacroAssemblerARM::load32): - (JSC::MacroAssemblerARM::relativeTableJump): - (JSC::MacroAssemblerARM::moveWithPatch): - (JSC::MacroAssemblerARM::loadDouble): - (JSC::MacroAssemblerARM::moveDouble): - (JSC::MacroAssemblerARM::addDouble): - (JSC::MacroAssemblerARM::divDouble): - (JSC::MacroAssemblerARM::subDouble): - (JSC::MacroAssemblerARM::mulDouble): - (JSC::MacroAssemblerARM::sqrtDouble): - (JSC::MacroAssemblerARM::absDouble): - (JSC::MacroAssemblerARM::negateDouble): - (JSC::MacroAssemblerARM::convertInt32ToDouble): - (JSC::MacroAssemblerARM::convertFloatToDouble): - (JSC::MacroAssemblerARM::convertDoubleToFloat): - (JSC::MacroAssemblerARM::branchDouble): - (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): - (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): - (JSC::MacroAssemblerARM::truncateDoubleToInt32): - (JSC::MacroAssemblerARM::truncateDoubleToUint32): - (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): - (JSC::MacroAssemblerARM::branchDoubleNonZero): - (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN): - -2012-08-13 Simon Hausmann <simon.hausmann@nokia.com> - - Unreviewed, rolling out r125444. - http://trac.webkit.org/changeset/125444 - https://bugs.webkit.org/show_bug.cgi?id=93872 - - Broke some tests - - * Target.pri: - -2012-08-13 Simon Hausmann <simon.hausmann@nokia.com> - - [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap - https://bugs.webkit.org/show_bug.cgi?id=93872 - - Reviewed by Kenneth Rohde Christiansen. - - * Target.pri: Add missing JSWeakObjectMap file to build. - -2012-08-13 Raphael Kubo da Costa <rakuco@webkit.org> - - [CMake] Remove glib-related Find modules and write single new one instead. - https://bugs.webkit.org/show_bug.cgi?id=93786 - - Reviewed by Rob Buis. - - * shell/PlatformEfl.cmake: Use GLIB_* instead of Glib_*. - -2012-08-12 Allan Sandfeld Jensen <allan.jensen@nokia.com> - - Doesn't build with ENABLE_JIT=0 - https://bugs.webkit.org/show_bug.cgi?id=85042 - - Reviewed by Eric Seidel. - - Include headers without which CallFrame.h does not build, and - fix gcc warning about comparing unsigned int with 0. - - * dfg/DFGDriver.cpp: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::isOpcode): - -2012-08-10 Yong Li <yoli@rim.com> - - [BlackBerry] GCActivityCallback should always schedule GC even allocated bytes is a small number - https://bugs.webkit.org/show_bug.cgi?id=93650 - - Reviewed by Rob Buis. - - Even a small number of allocated JS objects could hold expensive resources. - - * runtime/GCActivityCallbackBlackBerry.cpp: - (JSC::DefaultGCActivityCallback::didAllocate): - -2012-08-09 Yong Li <yoli@rim.com> - - [QNX] Implement getCPUTime() for OS(QNX) - https://bugs.webkit.org/show_bug.cgi?id=93516 - - Reviewed by George Staikos. - - Implement getCPUTime() with CLOCK_THREAD_CPUTIME_ID so it will tell - exactly how long the current thread has spent without being impacted - by other things. - - * runtime/TimeoutChecker.cpp: - (JSC::getCPUTime): - -2012-08-08 Shane Stephens <shanestephens@google.com> - - Compile flag for CSS Hierarchies - https://bugs.webkit.org/show_bug.cgi?id=92433 - - Reviewed by Tony Chang. - - * Configurations/FeatureDefines.xcconfig: + (JSValueMakeFromJSONString): -2012-08-08 Benjamin Poulain <bpoulain@apple.com> +2012-10-04 Benjamin Poulain <bpoulain@apple.com> - Use char* instead of LChar* for the public interface of String construction from literals - https://bugs.webkit.org/show_bug.cgi?id=93402 + Use copyLCharsFromUCharSource() for IdentifierLCharFromUCharTranslator translation + https://bugs.webkit.org/show_bug.cgi?id=98335 Reviewed by Michael Saboff. - Update JSC' Identifier to use StringImpl::createFromLiteral with a char*. - - * runtime/Identifier.cpp: - (JSC::IdentifierASCIIStringTranslator::translate): - -2012-08-08 Patrick Gansterer <paroga@webkit.org> - - Remove ce_time.(cpp|h) from list of source files - https://bugs.webkit.org/show_bug.cgi?id=93446 - - Reviewed by Simon Hausmann. - - r125004 removed the last dependency on functions defined in ce_time.cpp. - - * Target.pri: - -2012-08-08 Patrick Gansterer <paroga@webkit.org> - - [WIN] Use GetTimeZoneInformation() for getting the timezone name - https://bugs.webkit.org/show_bug.cgi?id=91936 - - Reviewed by Ryosuke Niwa. - - The MS CRT implementation of strftime calls the same functions in the background. - 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/DateConversion.cpp: - (JSC::formatTime): - -2012-08-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - Refactor magic numbers in the ARM port of DFG-JIT - https://bugs.webkit.org/show_bug.cgi?id=93348 - - Reviewed by Eric Seidel. - - Introduce new names for hard-coded magic numbers. - Refactor constant with confusing names to more descriptive ones. - - * assembler/ARMAssembler.cpp: - (JSC::ARMAssembler::patchConstantPoolLoad): - (JSC::ARMAssembler::getOp2): - (JSC::ARMAssembler::genInt): - (JSC::ARMAssembler::getImm): - (JSC::ARMAssembler::moveImm): - (JSC::ARMAssembler::encodeComplexImm): - (JSC::ARMAssembler::dataTransfer32): - (JSC::ARMAssembler::dataTransfer16): - (JSC::ARMAssembler::dataTransferFloat): - (JSC::ARMAssembler::executableCopy): - * assembler/ARMAssembler.h: - (JSC::ARMAssembler::emitInstruction): - (JSC::ARMAssembler::ands_r): - (JSC::ARMAssembler::eors_r): - (JSC::ARMAssembler::subs_r): - (JSC::ARMAssembler::rsbs_r): - (JSC::ARMAssembler::adds_r): - (JSC::ARMAssembler::adcs_r): - (JSC::ARMAssembler::sbcs_r): - (JSC::ARMAssembler::rscs_r): - (JSC::ARMAssembler::tst_r): - (JSC::ARMAssembler::teq_r): - (JSC::ARMAssembler::cmp_r): - (JSC::ARMAssembler::cmn_r): - (JSC::ARMAssembler::orrs_r): - (JSC::ARMAssembler::movs_r): - (JSC::ARMAssembler::bics_r): - (JSC::ARMAssembler::mvns_r): - (JSC::ARMAssembler::muls_r): - (JSC::ARMAssembler::ldr_imm): - (JSC::ARMAssembler::ldr_un_imm): - (JSC::ARMAssembler::dtr_u): - (JSC::ARMAssembler::dtr_ur): - (JSC::ARMAssembler::dtr_dr): - (JSC::ARMAssembler::dtrh_u): - (JSC::ARMAssembler::dtrh_ur): - (JSC::ARMAssembler::fdtr_u): - (JSC::ARMAssembler::push_r): - (JSC::ARMAssembler::pop_r): - (JSC::ARMAssembler::getLdrImmAddress): - (JSC::ARMAssembler::getLdrImmAddressOnPool): - (JSC::ARMAssembler::patchConstantPoolLoad): - (JSC::ARMAssembler::repatchCompact): - (JSC::ARMAssembler::replaceWithJump): - (JSC::ARMAssembler::replaceWithLoad): - (JSC::ARMAssembler::replaceWithAddressComputation): - (JSC::ARMAssembler::getOp2Byte): - (JSC::ARMAssembler::getOp2Half): - (JSC::ARMAssembler::getImm16Op2): - (JSC::ARMAssembler::placeConstantPoolBarrier): - (JSC::ARMAssembler::getConditionalField): - * assembler/MacroAssemblerARM.cpp: - (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::and32): - (JSC::MacroAssemblerARM::branch32): - (JSC::MacroAssemblerARM::branchTest32): - (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): - -2012-08-07 Benjamin Poulain <benjamin@webkit.org> - - Use the initialization from literal for JSC's Identifiers - https://bugs.webkit.org/show_bug.cgi?id=93193 - - Reviewed by Geoffrey Garen. - - This patches modify Identifier ot take advantage of the new initialization from literal. - - In addition to the memory savings (~600bytes per instance), this gives us a 2% speed - improvement on CommonIdentifiers on average. - - * runtime/CommonIdentifiers.cpp: - (JSC::CommonIdentifiers::CommonIdentifiers): - Null and empty strings are forbidden for literal initialization. Use the most efficient constructors - instead of a literal. - - * runtime/Identifier.cpp: - (IdentifierASCIIStringTranslator): - Rename IdentifierCStringTranslator to IdentifierASCIIStringTranslator to make the text encoding - explicit. - (JSC::IdentifierASCIIStringTranslator::hash): - (JSC::IdentifierASCIIStringTranslator::equal): - (JSC::IdentifierASCIIStringTranslator::translate): Use the fast initialization from literal. - (JSC::Identifier::add): - * runtime/Identifier.h: - (JSC::Identifier::Identifier): - -2012-08-07 Simon Hausmann <simon.hausmann@nokia.com> - - [Qt][Win] Remove pthreads linkage - - Reviewed by Csaba Osztrogonác. - - After r124823 linkage to pthreads is not needed anymore for the Windows - build. - - * JavaScriptCore.pri: - -2012-08-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - Refactor emit*Inst functions and introduce toARMWord functions in DFG-JIT's traditional ARM port - https://bugs.webkit.org/show_bug.cgi?id=93266 - - Reviewed by Csaba Osztrogonác. - - First part of a bigger refactoring issue trying to make traditional - ARM DFG-JIT port easier to read and understand. - - - * assembler/ARMAssembler.h: - (JSC::ARMAssembler::emitInstruction): - (JSC::ARMAssembler::emitDoublePrecisionInstruction): - (JSC::ARMAssembler::emitSinglePrecisionInstruction): - (JSC::ARMAssembler::and_r): - (JSC::ARMAssembler::ands_r): - (JSC::ARMAssembler::eor_r): - (JSC::ARMAssembler::eors_r): - (JSC::ARMAssembler::sub_r): - (JSC::ARMAssembler::subs_r): - (JSC::ARMAssembler::rsb_r): - (JSC::ARMAssembler::rsbs_r): - (JSC::ARMAssembler::add_r): - (JSC::ARMAssembler::adds_r): - (JSC::ARMAssembler::adc_r): - (JSC::ARMAssembler::adcs_r): - (JSC::ARMAssembler::sbc_r): - (JSC::ARMAssembler::sbcs_r): - (JSC::ARMAssembler::rsc_r): - (JSC::ARMAssembler::rscs_r): - (JSC::ARMAssembler::tst_r): - (JSC::ARMAssembler::teq_r): - (JSC::ARMAssembler::cmp_r): - (JSC::ARMAssembler::cmn_r): - (JSC::ARMAssembler::orr_r): - (JSC::ARMAssembler::orrs_r): - (JSC::ARMAssembler::mov_r): - (JSC::ARMAssembler::movw_r): - (JSC::ARMAssembler::movt_r): - (JSC::ARMAssembler::movs_r): - (JSC::ARMAssembler::bic_r): - (JSC::ARMAssembler::bics_r): - (JSC::ARMAssembler::mvn_r): - (JSC::ARMAssembler::mvns_r): - (JSC::ARMAssembler::mul_r): - (JSC::ARMAssembler::muls_r): - (JSC::ARMAssembler::mull_r): - (JSC::ARMAssembler::vmov_f64_r): - (JSC::ARMAssembler::vadd_f64_r): - (JSC::ARMAssembler::vdiv_f64_r): - (JSC::ARMAssembler::vsub_f64_r): - (JSC::ARMAssembler::vmul_f64_r): - (JSC::ARMAssembler::vcmp_f64_r): - (JSC::ARMAssembler::vsqrt_f64_r): - (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::vmov_vfp64_r): - (JSC::ARMAssembler::vmov_arm64_r): - (JSC::ARMAssembler::vmov_vfp32_r): - (JSC::ARMAssembler::vmov_arm32_r): - (JSC::ARMAssembler::vcvt_f64_s32_r): - (JSC::ARMAssembler::vcvt_s32_f64_r): - (JSC::ARMAssembler::vcvt_u32_f64_r): - (JSC::ARMAssembler::vcvt_f64_f32_r): - (JSC::ARMAssembler::vcvt_f32_f64_r): - (JSC::ARMAssembler::vmrs_apsr): - (JSC::ARMAssembler::clz_r): - (JSC::ARMAssembler::bx): - (JSC::ARMAssembler::blx): - (JSC::ARMAssembler::linkJump): - (JSC::ARMAssembler::toARMWord): - (ARMAssembler): - -2012-08-06 Patrick Gansterer <paroga@webkit.org> - - [WIN] Remove dependency on pthread from MachineStackMarker - https://bugs.webkit.org/show_bug.cgi?id=68429 - - Reviewed by Geoffrey Garen. - - Windows has no support for calling a destructor for thread specific data. - Since we need more control over creating and deleting thread specific keys - we can not simply extend WTF::ThreadSpecific with this functionality. - - All thread specific keys created via the new API get stored in a list. - After a thread function finished we iterate over this list and call - the registered destructor for every item if needed. - - * heap/MachineStackMarker.cpp: Use the new functions instead of pthread directly. - (JSC::MachineThreads::~MachineThreads): - (JSC::MachineThreads::makeUsableFromMultipleThreads): - (JSC::MachineThreads::addCurrentThread): - * heap/MachineStackMarker.h: - (MachineThreads): - -2012-08-06 Patrick Gansterer <paroga@webkit.org> - - Unify JSC date and time formating functions - https://bugs.webkit.org/show_bug.cgi?id=92282 - - Reviewed by Geoffrey Garen. - - Replace the existing functions for formating GregorianDateTime - with one single function. This removes some code duplications - in DatePrototype and is a preperation to fix encoding issues, - since we can add UChar* values to the resulting string now. - - * runtime/DateConstructor.cpp: - (JSC::callDate): - * runtime/DateConversion.cpp: - (JSC::formatDateTime): - * runtime/DateConversion.h: - (JSC): - * runtime/DatePrototype.cpp: - (JSC::formateDateInstance): - (JSC::dateProtoFuncToString): - (JSC::dateProtoFuncToUTCString): - (JSC::dateProtoFuncToDateString): - (JSC::dateProtoFuncToTimeString): - (JSC::dateProtoFuncToGMTString): - -2012-08-06 Carlos Garcia Campos <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing header file. - -2012-08-05 Peter Wang <peter.wang@torchmobile.com.cn> - - Web Inspector: [JSC] implement setting breakpoints by line:column - https://bugs.webkit.org/show_bug.cgi?id=53003 - - Reviewed by Geoffrey Garen. - - Add a counter to Lexer to record the column info of each Token. Add a column parameter to - op_debug, cti_op_debug, and _llint_op_debug byte-code command. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::resolve): - (JSC::BytecodeGenerator::emitDebugHook): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::ArrayNode::toArgumentList): - (JSC::ApplyFunctionCallDotNode::emitBytecode): - (JSC::ConstStatementNode::emitBytecode): - (JSC::EmptyStatementNode::emitBytecode): - (JSC::DebuggerStatementNode::emitBytecode): - (JSC::ExprStatementNode::emitBytecode): - (JSC::VarStatementNode::emitBytecode): - (JSC::IfNode::emitBytecode): - (JSC::IfElseNode::emitBytecode): - (JSC::DoWhileNode::emitBytecode): - (JSC::WhileNode::emitBytecode): - (JSC::ForNode::emitBytecode): - (JSC::ForInNode::emitBytecode): - (JSC::ContinueNode::emitBytecode): - (JSC::BreakNode::emitBytecode): - (JSC::ReturnNode::emitBytecode): - (JSC::WithNode::emitBytecode): - (JSC::SwitchNode::emitBytecode): - (JSC::LabelNode::emitBytecode): - (JSC::ThrowNode::emitBytecode): - (JSC::TryNode::emitBytecode): - (JSC::ProgramNode::emitBytecode): - (JSC::EvalNode::emitBytecode): - (JSC::FunctionBodyNode::emitBytecode): - * debugger/Debugger.h: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): - (JSC::Interpreter::throwException): - (JSC::Interpreter::debug): - (JSC::Interpreter::privateExecute): - * interpreter/Interpreter.h: - (Interpreter): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter.asm: - * parser/ASTBuilder.h: - (ASTBuilder): - (JSC::ASTBuilder::createCommaExpr): - (JSC::ASTBuilder::createLogicalNot): - (JSC::ASTBuilder::createUnaryPlus): - (JSC::ASTBuilder::createVoid): - (JSC::ASTBuilder::thisExpr): - (JSC::ASTBuilder::createResolve): - (JSC::ASTBuilder::createObjectLiteral): - (JSC::ASTBuilder::createArray): - (JSC::ASTBuilder::createNumberExpr): - (JSC::ASTBuilder::createString): - (JSC::ASTBuilder::createBoolean): - (JSC::ASTBuilder::createNull): - (JSC::ASTBuilder::createBracketAccess): - (JSC::ASTBuilder::createDotAccess): - (JSC::ASTBuilder::createRegExp): - (JSC::ASTBuilder::createNewExpr): - (JSC::ASTBuilder::createConditionalExpr): - (JSC::ASTBuilder::createAssignResolve): - (JSC::ASTBuilder::createFunctionExpr): - (JSC::ASTBuilder::createFunctionBody): - (JSC::ASTBuilder::createGetterOrSetterProperty): - (JSC::ASTBuilder::createArgumentsList): - (JSC::ASTBuilder::createPropertyList): - (JSC::ASTBuilder::createFuncDeclStatement): - (JSC::ASTBuilder::createBlockStatement): - (JSC::ASTBuilder::createExprStatement): - (JSC::ASTBuilder::createIfStatement): - (JSC::ASTBuilder::createForLoop): - (JSC::ASTBuilder::createForInLoop): - (JSC::ASTBuilder::createEmptyStatement): - (JSC::ASTBuilder::createVarStatement): - (JSC::ASTBuilder::createReturnStatement): - (JSC::ASTBuilder::createBreakStatement): - (JSC::ASTBuilder::createContinueStatement): - (JSC::ASTBuilder::createTryStatement): - (JSC::ASTBuilder::createSwitchStatement): - (JSC::ASTBuilder::createWhileStatement): - (JSC::ASTBuilder::createDoWhileStatement): - (JSC::ASTBuilder::createLabelStatement): - (JSC::ASTBuilder::createWithStatement): - (JSC::ASTBuilder::createThrowStatement): - (JSC::ASTBuilder::createDebugger): - (JSC::ASTBuilder::createConstStatement): - (JSC::ASTBuilder::appendConstDecl): - (JSC::ASTBuilder::combineCommaNodes): - (JSC::ASTBuilder::appendBinaryOperation): - (JSC::ASTBuilder::createAssignment): - (JSC::ASTBuilder::createNumber): - (JSC::ASTBuilder::makeTypeOfNode): - (JSC::ASTBuilder::makeDeleteNode): - (JSC::ASTBuilder::makeNegateNode): - (JSC::ASTBuilder::makeBitwiseNotNode): - (JSC::ASTBuilder::makeMultNode): - (JSC::ASTBuilder::makeDivNode): - (JSC::ASTBuilder::makeModNode): - (JSC::ASTBuilder::makeAddNode): - (JSC::ASTBuilder::makeSubNode): - (JSC::ASTBuilder::makeLeftShiftNode): - (JSC::ASTBuilder::makeRightShiftNode): - (JSC::ASTBuilder::makeURightShiftNode): - (JSC::ASTBuilder::makeBitOrNode): - (JSC::ASTBuilder::makeBitAndNode): - (JSC::ASTBuilder::makeBitXOrNode): - (JSC::ASTBuilder::makeFunctionCallNode): - (JSC::ASTBuilder::makeBinaryNode): - (JSC::ASTBuilder::makeAssignNode): - (JSC::ASTBuilder::makePrefixNode): - (JSC::ASTBuilder::makePostfixNode): - * parser/Lexer.cpp: - (JSC::::setCode): - (JSC::::internalShift): - (JSC::::shift): - (JSC::::lex): - * parser/Lexer.h: - (Lexer): - (JSC::Lexer::currentColumnNumber): - (JSC::::lexExpectIdentifier): - * parser/NodeConstructors.h: - (JSC::Node::Node): - (JSC::ExpressionNode::ExpressionNode): - (JSC::StatementNode::StatementNode): - (JSC::NullNode::NullNode): - (JSC::BooleanNode::BooleanNode): - (JSC::NumberNode::NumberNode): - (JSC::StringNode::StringNode): - (JSC::RegExpNode::RegExpNode): - (JSC::ThisNode::ThisNode): - (JSC::ResolveNode::ResolveNode): - (JSC::ArrayNode::ArrayNode): - (JSC::PropertyListNode::PropertyListNode): - (JSC::ObjectLiteralNode::ObjectLiteralNode): - (JSC::BracketAccessorNode::BracketAccessorNode): - (JSC::DotAccessorNode::DotAccessorNode): - (JSC::ArgumentListNode::ArgumentListNode): - (JSC::NewExprNode::NewExprNode): - (JSC::EvalFunctionCallNode::EvalFunctionCallNode): - (JSC::FunctionCallValueNode::FunctionCallValueNode): - (JSC::FunctionCallResolveNode::FunctionCallResolveNode): - (JSC::FunctionCallBracketNode::FunctionCallBracketNode): - (JSC::FunctionCallDotNode::FunctionCallDotNode): - (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): - (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): - (JSC::PrePostResolveNode::PrePostResolveNode): - (JSC::PostfixResolveNode::PostfixResolveNode): - (JSC::PostfixBracketNode::PostfixBracketNode): - (JSC::PostfixDotNode::PostfixDotNode): - (JSC::PostfixErrorNode::PostfixErrorNode): - (JSC::DeleteResolveNode::DeleteResolveNode): - (JSC::DeleteBracketNode::DeleteBracketNode): - (JSC::DeleteDotNode::DeleteDotNode): - (JSC::DeleteValueNode::DeleteValueNode): - (JSC::VoidNode::VoidNode): - (JSC::TypeOfResolveNode::TypeOfResolveNode): - (JSC::TypeOfValueNode::TypeOfValueNode): - (JSC::PrefixResolveNode::PrefixResolveNode): - (JSC::PrefixBracketNode::PrefixBracketNode): - (JSC::PrefixDotNode::PrefixDotNode): - (JSC::PrefixErrorNode::PrefixErrorNode): - (JSC::UnaryOpNode::UnaryOpNode): - (JSC::UnaryPlusNode::UnaryPlusNode): - (JSC::NegateNode::NegateNode): - (JSC::BitwiseNotNode::BitwiseNotNode): - (JSC::LogicalNotNode::LogicalNotNode): - (JSC::BinaryOpNode::BinaryOpNode): - (JSC::MultNode::MultNode): - (JSC::DivNode::DivNode): - (JSC::ModNode::ModNode): - (JSC::AddNode::AddNode): - (JSC::SubNode::SubNode): - (JSC::LeftShiftNode::LeftShiftNode): - (JSC::RightShiftNode::RightShiftNode): - (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): - (JSC::LessNode::LessNode): - (JSC::GreaterNode::GreaterNode): - (JSC::LessEqNode::LessEqNode): - (JSC::GreaterEqNode::GreaterEqNode): - (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): - (JSC::InstanceOfNode::InstanceOfNode): - (JSC::InNode::InNode): - (JSC::EqualNode::EqualNode): - (JSC::NotEqualNode::NotEqualNode): - (JSC::StrictEqualNode::StrictEqualNode): - (JSC::NotStrictEqualNode::NotStrictEqualNode): - (JSC::BitAndNode::BitAndNode): - (JSC::BitOrNode::BitOrNode): - (JSC::BitXOrNode::BitXOrNode): - (JSC::LogicalOpNode::LogicalOpNode): - (JSC::ConditionalNode::ConditionalNode): - (JSC::ReadModifyResolveNode::ReadModifyResolveNode): - (JSC::AssignResolveNode::AssignResolveNode): - (JSC::ReadModifyBracketNode::ReadModifyBracketNode): - (JSC::AssignBracketNode::AssignBracketNode): - (JSC::AssignDotNode::AssignDotNode): - (JSC::ReadModifyDotNode::ReadModifyDotNode): - (JSC::AssignErrorNode::AssignErrorNode): - (JSC::CommaNode::CommaNode): - (JSC::ConstStatementNode::ConstStatementNode): - (JSC::EmptyStatementNode::EmptyStatementNode): - (JSC::DebuggerStatementNode::DebuggerStatementNode): - (JSC::ExprStatementNode::ExprStatementNode): - (JSC::VarStatementNode::VarStatementNode): - (JSC::IfNode::IfNode): - (JSC::IfElseNode::IfElseNode): - (JSC::DoWhileNode::DoWhileNode): - (JSC::WhileNode::WhileNode): - (JSC::ForNode::ForNode): - (JSC::ContinueNode::ContinueNode): - (JSC::BreakNode::BreakNode): - (JSC::ReturnNode::ReturnNode): - (JSC::WithNode::WithNode): - (JSC::LabelNode::LabelNode): - (JSC::ThrowNode::ThrowNode): - (JSC::TryNode::TryNode): - (JSC::FuncExprNode::FuncExprNode): - (JSC::FuncDeclNode::FuncDeclNode): - (JSC::SwitchNode::SwitchNode): - (JSC::ConstDeclNode::ConstDeclNode): - (JSC::BlockNode::BlockNode): - (JSC::ForInNode::ForInNode): - * parser/Nodes.cpp: - (JSC::StatementNode::setLoc): - (JSC): - (JSC::ScopeNode::ScopeNode): - (JSC::ProgramNode::ProgramNode): - (JSC::ProgramNode::create): - (JSC::EvalNode::EvalNode): - (JSC::EvalNode::create): - (JSC::FunctionBodyNode::FunctionBodyNode): - (JSC::FunctionBodyNode::create): - * parser/Nodes.h: - (Node): - (JSC::Node::columnNo): - (ExpressionNode): - (StatementNode): - (JSC::StatementNode::column): - (NullNode): - (BooleanNode): - (NumberNode): - (StringNode): - (RegExpNode): - (ThisNode): - (ResolveNode): - (ArrayNode): - (PropertyListNode): - (ObjectLiteralNode): - (BracketAccessorNode): - (DotAccessorNode): - (ArgumentListNode): - (NewExprNode): - (EvalFunctionCallNode): - (FunctionCallValueNode): - (FunctionCallResolveNode): - (FunctionCallBracketNode): - (FunctionCallDotNode): - (CallFunctionCallDotNode): - (ApplyFunctionCallDotNode): - (PrePostResolveNode): - (PostfixResolveNode): - (PostfixBracketNode): - (PostfixDotNode): - (PostfixErrorNode): - (DeleteResolveNode): - (DeleteBracketNode): - (DeleteDotNode): - (DeleteValueNode): - (VoidNode): - (TypeOfResolveNode): - (TypeOfValueNode): - (PrefixResolveNode): - (PrefixBracketNode): - (PrefixDotNode): - (PrefixErrorNode): - (UnaryOpNode): - (UnaryPlusNode): - (NegateNode): - (BitwiseNotNode): - (LogicalNotNode): - (BinaryOpNode): - (MultNode): - (DivNode): - (ModNode): - (AddNode): - (SubNode): - (LeftShiftNode): - (RightShiftNode): - (UnsignedRightShiftNode): - (LessNode): - (GreaterNode): - (LessEqNode): - (GreaterEqNode): - (ThrowableBinaryOpNode): - (InstanceOfNode): - (InNode): - (EqualNode): - (NotEqualNode): - (StrictEqualNode): - (NotStrictEqualNode): - (BitAndNode): - (BitOrNode): - (BitXOrNode): - (LogicalOpNode): - (ConditionalNode): - (ReadModifyResolveNode): - (AssignResolveNode): - (ReadModifyBracketNode): - (AssignBracketNode): - (AssignDotNode): - (ReadModifyDotNode): - (AssignErrorNode): - (CommaNode): - (ConstDeclNode): - (ConstStatementNode): - (BlockNode): - (EmptyStatementNode): - (DebuggerStatementNode): - (ExprStatementNode): - (VarStatementNode): - (IfNode): - (IfElseNode): - (DoWhileNode): - (WhileNode): - (ForNode): - (ForInNode): - (ContinueNode): - (BreakNode): - (ReturnNode): - (WithNode): - (LabelNode): - (ThrowNode): - (TryNode): - (ScopeNode): - (ProgramNode): - (EvalNode): - (FunctionBodyNode): - (FuncExprNode): - (FuncDeclNode): - (SwitchNode): - * parser/Parser.cpp: - (JSC::::parseSourceElements): - (JSC::::parseVarDeclaration): - (JSC::::parseConstDeclaration): - (JSC::::parseDoWhileStatement): - (JSC::::parseWhileStatement): - (JSC::::parseVarDeclarationList): - (JSC::::parseConstDeclarationList): - (JSC::::parseForStatement): - (JSC::::parseBreakStatement): - (JSC::::parseContinueStatement): - (JSC::::parseReturnStatement): - (JSC::::parseThrowStatement): - (JSC::::parseWithStatement): - (JSC::::parseSwitchStatement): - (JSC::::parseTryStatement): - (JSC::::parseDebuggerStatement): - (JSC::::parseBlockStatement): - (JSC::::parseStatement): - (JSC::::parseFunctionBody): - (JSC::::parseFunctionInfo): - (JSC::::parseFunctionDeclaration): - (JSC::::parseExpressionOrLabelStatement): - (JSC::::parseExpressionStatement): - (JSC::::parseIfStatement): - (JSC::::parseExpression): - (JSC::::parseAssignmentExpression): - (JSC::::parseConditionalExpression): - (JSC::::parseBinaryExpression): - (JSC::::parseProperty): - (JSC::::parseObjectLiteral): - (JSC::::parseStrictObjectLiteral): - (JSC::::parseArrayLiteral): - (JSC::::parsePrimaryExpression): - (JSC::::parseArguments): - (JSC::::parseMemberExpression): - (JSC::::parseUnaryExpression): - * parser/Parser.h: - (JSC::Parser::next): - (JSC::Parser::nextExpectIdentifier): - (JSC::Parser::tokenStart): - (JSC::Parser::tokenLine): - (JSC::Parser::tokenEnd): - (JSC::Parser::tokenLocation): - (Parser): - (JSC::Parser::getTokenName): - (JSC::::parse): - * parser/ParserTokens.h: - (JSC::JSTokenLocation::JSTokenLocation): - (JSTokenLocation): - (JSToken): - * parser/SourceProviderCacheItem.h: - (JSC::SourceProviderCacheItem::closeBraceToken): - * parser/SyntaxChecker.h: - (JSC::SyntaxChecker::makeFunctionCallNode): - (JSC::SyntaxChecker::createCommaExpr): - (JSC::SyntaxChecker::makeAssignNode): - (JSC::SyntaxChecker::makePrefixNode): - (JSC::SyntaxChecker::makePostfixNode): - (JSC::SyntaxChecker::makeTypeOfNode): - (JSC::SyntaxChecker::makeDeleteNode): - (JSC::SyntaxChecker::makeNegateNode): - (JSC::SyntaxChecker::makeBitwiseNotNode): - (JSC::SyntaxChecker::createLogicalNot): - (JSC::SyntaxChecker::createUnaryPlus): - (JSC::SyntaxChecker::createVoid): - (JSC::SyntaxChecker::thisExpr): - (JSC::SyntaxChecker::createResolve): - (JSC::SyntaxChecker::createObjectLiteral): - (JSC::SyntaxChecker::createArray): - (JSC::SyntaxChecker::createNumberExpr): - (JSC::SyntaxChecker::createString): - (JSC::SyntaxChecker::createBoolean): - (JSC::SyntaxChecker::createNull): - (JSC::SyntaxChecker::createBracketAccess): - (JSC::SyntaxChecker::createDotAccess): - (JSC::SyntaxChecker::createRegExp): - (JSC::SyntaxChecker::createNewExpr): - (JSC::SyntaxChecker::createConditionalExpr): - (JSC::SyntaxChecker::createAssignResolve): - (JSC::SyntaxChecker::createFunctionExpr): - (JSC::SyntaxChecker::createFunctionBody): - (JSC::SyntaxChecker::createArgumentsList): - (JSC::SyntaxChecker::createPropertyList): - (JSC::SyntaxChecker::createFuncDeclStatement): - (JSC::SyntaxChecker::createBlockStatement): - (JSC::SyntaxChecker::createExprStatement): - (JSC::SyntaxChecker::createIfStatement): - (JSC::SyntaxChecker::createForLoop): - (JSC::SyntaxChecker::createForInLoop): - (JSC::SyntaxChecker::createEmptyStatement): - (JSC::SyntaxChecker::createVarStatement): - (JSC::SyntaxChecker::createReturnStatement): - (JSC::SyntaxChecker::createBreakStatement): - (JSC::SyntaxChecker::createContinueStatement): - (JSC::SyntaxChecker::createTryStatement): - (JSC::SyntaxChecker::createSwitchStatement): - (JSC::SyntaxChecker::createWhileStatement): - (JSC::SyntaxChecker::createWithStatement): - (JSC::SyntaxChecker::createDoWhileStatement): - (JSC::SyntaxChecker::createLabelStatement): - (JSC::SyntaxChecker::createThrowStatement): - (JSC::SyntaxChecker::createDebugger): - (JSC::SyntaxChecker::createConstStatement): - (JSC::SyntaxChecker::appendConstDecl): - (JSC::SyntaxChecker::createGetterOrSetterProperty): - (JSC::SyntaxChecker::combineCommaNodes): - (JSC::SyntaxChecker::operatorStackPop): - -2012-08-03 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 Patrick Gansterer <paroga@webkit.org> - - Move getLocalTime() as static inline function to DateMath - https://bugs.webkit.org/show_bug.cgi?id=92955 - - Reviewed by Ryosuke Niwa. - - getCurrentLocalTime() and getLocalTime() has been superseded with the - GregorianDateTime class. So we can move it into DateMath.cpp as an static inline - function. This allows us to remove the dependecy on time() and localtime() - for Windows CE, where this functions require the ce_time library to work. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-02 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - Unreviewed, build fix for DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE). - - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - -2012-08-01 Mark Hahnenberg <mhahnenberg@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r124406. - http://trac.webkit.org/changeset/124406 - https://bugs.webkit.org/show_bug.cgi?id=92951 - - it set the Mac bots on fire (Requested by pizlo on #webkit). - - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitDebugHook): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::ArrayNode::toArgumentList): - (JSC::ApplyFunctionCallDotNode::emitBytecode): - (JSC::ConditionalNode::emitBytecode): - (JSC::ConstStatementNode::emitBytecode): - (JSC::EmptyStatementNode::emitBytecode): - (JSC::DebuggerStatementNode::emitBytecode): - (JSC::ExprStatementNode::emitBytecode): - (JSC::VarStatementNode::emitBytecode): - (JSC::IfNode::emitBytecode): - (JSC::IfElseNode::emitBytecode): - (JSC::DoWhileNode::emitBytecode): - (JSC::WhileNode::emitBytecode): - (JSC::ForNode::emitBytecode): - (JSC::ForInNode::emitBytecode): - (JSC::ContinueNode::emitBytecode): - (JSC::BreakNode::emitBytecode): - (JSC::ReturnNode::emitBytecode): - (JSC::WithNode::emitBytecode): - (JSC::SwitchNode::emitBytecode): - (JSC::LabelNode::emitBytecode): - (JSC::ThrowNode::emitBytecode): - (JSC::TryNode::emitBytecode): - (JSC::ProgramNode::emitBytecode): - (JSC::EvalNode::emitBytecode): - (JSC::FunctionBodyNode::emitBytecode): - * debugger/Debugger.h: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): - (JSC::Interpreter::throwException): - (JSC::Interpreter::debug): - * interpreter/Interpreter.h: - (Interpreter): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * parser/ASTBuilder.h: - (ASTBuilder): - (JSC::ASTBuilder::createCommaExpr): - (JSC::ASTBuilder::createLogicalNot): - (JSC::ASTBuilder::createUnaryPlus): - (JSC::ASTBuilder::createVoid): - (JSC::ASTBuilder::thisExpr): - (JSC::ASTBuilder::createResolve): - (JSC::ASTBuilder::createObjectLiteral): - (JSC::ASTBuilder::createArray): - (JSC::ASTBuilder::createNumberExpr): - (JSC::ASTBuilder::createString): - (JSC::ASTBuilder::createBoolean): - (JSC::ASTBuilder::createNull): - (JSC::ASTBuilder::createBracketAccess): - (JSC::ASTBuilder::createDotAccess): - (JSC::ASTBuilder::createRegExp): - (JSC::ASTBuilder::createNewExpr): - (JSC::ASTBuilder::createConditionalExpr): - (JSC::ASTBuilder::createAssignResolve): - (JSC::ASTBuilder::createFunctionExpr): - (JSC::ASTBuilder::createFunctionBody): - (JSC::ASTBuilder::createGetterOrSetterProperty): - (JSC::ASTBuilder::createArgumentsList): - (JSC::ASTBuilder::createPropertyList): - (JSC::ASTBuilder::createFuncDeclStatement): - (JSC::ASTBuilder::createBlockStatement): - (JSC::ASTBuilder::createExprStatement): - (JSC::ASTBuilder::createIfStatement): - (JSC::ASTBuilder::createForLoop): - (JSC::ASTBuilder::createForInLoop): - (JSC::ASTBuilder::createEmptyStatement): - (JSC::ASTBuilder::createVarStatement): - (JSC::ASTBuilder::createReturnStatement): - (JSC::ASTBuilder::createBreakStatement): - (JSC::ASTBuilder::createContinueStatement): - (JSC::ASTBuilder::createTryStatement): - (JSC::ASTBuilder::createSwitchStatement): - (JSC::ASTBuilder::createWhileStatement): - (JSC::ASTBuilder::createDoWhileStatement): - (JSC::ASTBuilder::createLabelStatement): - (JSC::ASTBuilder::createWithStatement): - (JSC::ASTBuilder::createThrowStatement): - (JSC::ASTBuilder::createDebugger): - (JSC::ASTBuilder::createConstStatement): - (JSC::ASTBuilder::appendConstDecl): - (JSC::ASTBuilder::combineCommaNodes): - (JSC::ASTBuilder::appendBinaryOperation): - (JSC::ASTBuilder::createAssignment): - (JSC::ASTBuilder::createNumber): - (JSC::ASTBuilder::makeTypeOfNode): - (JSC::ASTBuilder::makeDeleteNode): - (JSC::ASTBuilder::makeNegateNode): - (JSC::ASTBuilder::makeBitwiseNotNode): - (JSC::ASTBuilder::makeMultNode): - (JSC::ASTBuilder::makeDivNode): - (JSC::ASTBuilder::makeModNode): - (JSC::ASTBuilder::makeAddNode): - (JSC::ASTBuilder::makeSubNode): - (JSC::ASTBuilder::makeLeftShiftNode): - (JSC::ASTBuilder::makeRightShiftNode): - (JSC::ASTBuilder::makeURightShiftNode): - (JSC::ASTBuilder::makeBitOrNode): - (JSC::ASTBuilder::makeBitAndNode): - (JSC::ASTBuilder::makeBitXOrNode): - (JSC::ASTBuilder::makeFunctionCallNode): - (JSC::ASTBuilder::makeBinaryNode): - (JSC::ASTBuilder::makeAssignNode): - (JSC::ASTBuilder::makePrefixNode): - (JSC::ASTBuilder::makePostfixNode): - * parser/Lexer.cpp: - (JSC::::setCode): - (JSC::::internalShift): - (JSC::::shift): - (JSC::::lex): - * parser/Lexer.h: - (Lexer): - (JSC::::lexExpectIdentifier): - * parser/NodeConstructors.h: - (JSC::Node::Node): - (JSC::ExpressionNode::ExpressionNode): - (JSC::StatementNode::StatementNode): - (JSC::NullNode::NullNode): - (JSC::BooleanNode::BooleanNode): - (JSC::NumberNode::NumberNode): - (JSC::StringNode::StringNode): - (JSC::RegExpNode::RegExpNode): - (JSC::ThisNode::ThisNode): - (JSC::ResolveNode::ResolveNode): - (JSC::ArrayNode::ArrayNode): - (JSC::PropertyListNode::PropertyListNode): - (JSC::ObjectLiteralNode::ObjectLiteralNode): - (JSC::BracketAccessorNode::BracketAccessorNode): - (JSC::DotAccessorNode::DotAccessorNode): - (JSC::ArgumentListNode::ArgumentListNode): - (JSC::NewExprNode::NewExprNode): - (JSC::EvalFunctionCallNode::EvalFunctionCallNode): - (JSC::FunctionCallValueNode::FunctionCallValueNode): - (JSC::FunctionCallResolveNode::FunctionCallResolveNode): - (JSC::FunctionCallBracketNode::FunctionCallBracketNode): - (JSC::FunctionCallDotNode::FunctionCallDotNode): - (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): - (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): - (JSC::PrePostResolveNode::PrePostResolveNode): - (JSC::PostfixResolveNode::PostfixResolveNode): - (JSC::PostfixBracketNode::PostfixBracketNode): - (JSC::PostfixDotNode::PostfixDotNode): - (JSC::PostfixErrorNode::PostfixErrorNode): - (JSC::DeleteResolveNode::DeleteResolveNode): - (JSC::DeleteBracketNode::DeleteBracketNode): - (JSC::DeleteDotNode::DeleteDotNode): - (JSC::DeleteValueNode::DeleteValueNode): - (JSC::VoidNode::VoidNode): - (JSC::TypeOfResolveNode::TypeOfResolveNode): - (JSC::TypeOfValueNode::TypeOfValueNode): - (JSC::PrefixResolveNode::PrefixResolveNode): - (JSC::PrefixBracketNode::PrefixBracketNode): - (JSC::PrefixDotNode::PrefixDotNode): - (JSC::PrefixErrorNode::PrefixErrorNode): - (JSC::UnaryOpNode::UnaryOpNode): - (JSC::UnaryPlusNode::UnaryPlusNode): - (JSC::NegateNode::NegateNode): - (JSC::BitwiseNotNode::BitwiseNotNode): - (JSC::LogicalNotNode::LogicalNotNode): - (JSC::BinaryOpNode::BinaryOpNode): - (JSC::MultNode::MultNode): - (JSC::DivNode::DivNode): - (JSC::ModNode::ModNode): - (JSC::AddNode::AddNode): - (JSC::SubNode::SubNode): - (JSC::LeftShiftNode::LeftShiftNode): - (JSC::RightShiftNode::RightShiftNode): - (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): - (JSC::LessNode::LessNode): - (JSC::GreaterNode::GreaterNode): - (JSC::LessEqNode::LessEqNode): - (JSC::GreaterEqNode::GreaterEqNode): - (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): - (JSC::InstanceOfNode::InstanceOfNode): - (JSC::InNode::InNode): - (JSC::EqualNode::EqualNode): - (JSC::NotEqualNode::NotEqualNode): - (JSC::StrictEqualNode::StrictEqualNode): - (JSC::NotStrictEqualNode::NotStrictEqualNode): - (JSC::BitAndNode::BitAndNode): - (JSC::BitOrNode::BitOrNode): - (JSC::BitXOrNode::BitXOrNode): - (JSC::LogicalOpNode::LogicalOpNode): - (JSC::ConditionalNode::ConditionalNode): - (JSC::ReadModifyResolveNode::ReadModifyResolveNode): - (JSC::AssignResolveNode::AssignResolveNode): - (JSC::ReadModifyBracketNode::ReadModifyBracketNode): - (JSC::AssignBracketNode::AssignBracketNode): - (JSC::AssignDotNode::AssignDotNode): - (JSC::ReadModifyDotNode::ReadModifyDotNode): - (JSC::AssignErrorNode::AssignErrorNode): - (JSC::CommaNode::CommaNode): - (JSC::ConstStatementNode::ConstStatementNode): - (JSC::EmptyStatementNode::EmptyStatementNode): - (JSC::DebuggerStatementNode::DebuggerStatementNode): - (JSC::ExprStatementNode::ExprStatementNode): - (JSC::VarStatementNode::VarStatementNode): - (JSC::IfNode::IfNode): - (JSC::IfElseNode::IfElseNode): - (JSC::DoWhileNode::DoWhileNode): - (JSC::WhileNode::WhileNode): - (JSC::ForNode::ForNode): - (JSC::ContinueNode::ContinueNode): - (JSC::BreakNode::BreakNode): - (JSC::ReturnNode::ReturnNode): - (JSC::WithNode::WithNode): - (JSC::LabelNode::LabelNode): - (JSC::ThrowNode::ThrowNode): - (JSC::TryNode::TryNode): - (JSC::FuncExprNode::FuncExprNode): - (JSC::FuncDeclNode::FuncDeclNode): - (JSC::SwitchNode::SwitchNode): - (JSC::ConstDeclNode::ConstDeclNode): - (JSC::BlockNode::BlockNode): - (JSC::ForInNode::ForInNode): - * parser/Nodes.cpp: - (JSC): - (JSC::StatementNode::setLoc): - (JSC::ScopeNode::ScopeNode): - (JSC::ProgramNode::ProgramNode): - (JSC::ProgramNode::create): - (JSC::EvalNode::EvalNode): - (JSC::EvalNode::create): - (JSC::FunctionBodyNode::FunctionBodyNode): - (JSC::FunctionBodyNode::create): - * parser/Nodes.h: - (Node): - (ExpressionNode): - (StatementNode): - (NullNode): - (BooleanNode): - (NumberNode): - (StringNode): - (RegExpNode): - (ThisNode): - (ResolveNode): - (ArrayNode): - (PropertyListNode): - (ObjectLiteralNode): - (BracketAccessorNode): - (DotAccessorNode): - (ArgumentListNode): - (NewExprNode): - (EvalFunctionCallNode): - (FunctionCallValueNode): - (FunctionCallResolveNode): - (FunctionCallBracketNode): - (FunctionCallDotNode): - (CallFunctionCallDotNode): - (ApplyFunctionCallDotNode): - (PrePostResolveNode): - (PostfixResolveNode): - (PostfixBracketNode): - (PostfixDotNode): - (PostfixErrorNode): - (DeleteResolveNode): - (DeleteBracketNode): - (DeleteDotNode): - (DeleteValueNode): - (VoidNode): - (TypeOfResolveNode): - (TypeOfValueNode): - (PrefixResolveNode): - (PrefixBracketNode): - (PrefixDotNode): - (PrefixErrorNode): - (UnaryOpNode): - (UnaryPlusNode): - (NegateNode): - (BitwiseNotNode): - (LogicalNotNode): - (BinaryOpNode): - (MultNode): - (DivNode): - (ModNode): - (AddNode): - (SubNode): - (LeftShiftNode): - (RightShiftNode): - (UnsignedRightShiftNode): - (LessNode): - (GreaterNode): - (LessEqNode): - (GreaterEqNode): - (ThrowableBinaryOpNode): - (InstanceOfNode): - (InNode): - (EqualNode): - (NotEqualNode): - (StrictEqualNode): - (NotStrictEqualNode): - (BitAndNode): - (BitOrNode): - (BitXOrNode): - (LogicalOpNode): - (ConditionalNode): - (ReadModifyResolveNode): - (AssignResolveNode): - (ReadModifyBracketNode): - (AssignBracketNode): - (AssignDotNode): - (ReadModifyDotNode): - (AssignErrorNode): - (CommaNode): - (ConstDeclNode): - (ConstStatementNode): - (BlockNode): - (EmptyStatementNode): - (DebuggerStatementNode): - (ExprStatementNode): - (VarStatementNode): - (IfNode): - (IfElseNode): - (DoWhileNode): - (WhileNode): - (ForNode): - (ForInNode): - (ContinueNode): - (BreakNode): - (ReturnNode): - (WithNode): - (LabelNode): - (ThrowNode): - (TryNode): - (ScopeNode): - (ProgramNode): - (EvalNode): - (FunctionBodyNode): - (FuncExprNode): - (FuncDeclNode): - (SwitchNode): - * parser/Parser.cpp: - (JSC::::parseSourceElements): - (JSC::::parseVarDeclaration): - (JSC::::parseConstDeclaration): - (JSC::::parseDoWhileStatement): - (JSC::::parseWhileStatement): - (JSC::::parseVarDeclarationList): - (JSC::::parseConstDeclarationList): - (JSC::::parseForStatement): - (JSC::::parseBreakStatement): - (JSC::::parseContinueStatement): - (JSC::::parseReturnStatement): - (JSC::::parseThrowStatement): - (JSC::::parseWithStatement): - (JSC::::parseSwitchStatement): - (JSC::::parseTryStatement): - (JSC::::parseDebuggerStatement): - (JSC::::parseBlockStatement): - (JSC::::parseStatement): - (JSC::::parseFunctionBody): - (JSC::::parseFunctionInfo): - (JSC::::parseFunctionDeclaration): - (JSC::::parseExpressionOrLabelStatement): - (JSC::::parseExpressionStatement): - (JSC::::parseIfStatement): - (JSC::::parseExpression): - (JSC::::parseAssignmentExpression): - (JSC::::parseConditionalExpression): - (JSC::::parseBinaryExpression): - (JSC::::parseProperty): - (JSC::::parseObjectLiteral): - (JSC::::parseStrictObjectLiteral): - (JSC::::parseArrayLiteral): - (JSC::::parsePrimaryExpression): - (JSC::::parseArguments): - (JSC::::parseMemberExpression): - (JSC::::parseUnaryExpression): - * parser/Parser.h: - (JSC::Parser::next): - (JSC::Parser::nextExpectIdentifier): - (JSC::Parser::tokenStart): - (JSC::Parser::tokenLine): - (JSC::Parser::tokenEnd): - (JSC::Parser::getTokenName): - (JSC::::parse): - * parser/ParserTokens.h: - (JSC::JSTokenInfo::JSTokenInfo): - (JSTokenInfo): - (JSToken): - * parser/SourceProviderCacheItem.h: - (JSC::SourceProviderCacheItem::closeBraceToken): - * parser/SyntaxChecker.h: - (JSC::SyntaxChecker::makeFunctionCallNode): - (JSC::SyntaxChecker::createCommaExpr): - (JSC::SyntaxChecker::makeAssignNode): - (JSC::SyntaxChecker::makePrefixNode): - (JSC::SyntaxChecker::makePostfixNode): - (JSC::SyntaxChecker::makeTypeOfNode): - (JSC::SyntaxChecker::makeDeleteNode): - (JSC::SyntaxChecker::makeNegateNode): - (JSC::SyntaxChecker::makeBitwiseNotNode): - (JSC::SyntaxChecker::createLogicalNot): - (JSC::SyntaxChecker::createUnaryPlus): - (JSC::SyntaxChecker::createVoid): - (JSC::SyntaxChecker::thisExpr): - (JSC::SyntaxChecker::createResolve): - (JSC::SyntaxChecker::createObjectLiteral): - (JSC::SyntaxChecker::createArray): - (JSC::SyntaxChecker::createNumberExpr): - (JSC::SyntaxChecker::createString): - (JSC::SyntaxChecker::createBoolean): - (JSC::SyntaxChecker::createNull): - (JSC::SyntaxChecker::createBracketAccess): - (JSC::SyntaxChecker::createDotAccess): - (JSC::SyntaxChecker::createRegExp): - (JSC::SyntaxChecker::createNewExpr): - (JSC::SyntaxChecker::createConditionalExpr): - (JSC::SyntaxChecker::createAssignResolve): - (JSC::SyntaxChecker::createFunctionExpr): - (JSC::SyntaxChecker::createFunctionBody): - (JSC::SyntaxChecker::createArgumentsList): - (JSC::SyntaxChecker::createPropertyList): - (JSC::SyntaxChecker::createFuncDeclStatement): - (JSC::SyntaxChecker::createBlockStatement): - (JSC::SyntaxChecker::createExprStatement): - (JSC::SyntaxChecker::createIfStatement): - (JSC::SyntaxChecker::createForLoop): - (JSC::SyntaxChecker::createForInLoop): - (JSC::SyntaxChecker::createEmptyStatement): - (JSC::SyntaxChecker::createVarStatement): - (JSC::SyntaxChecker::createReturnStatement): - (JSC::SyntaxChecker::createBreakStatement): - (JSC::SyntaxChecker::createContinueStatement): - (JSC::SyntaxChecker::createTryStatement): - (JSC::SyntaxChecker::createSwitchStatement): - (JSC::SyntaxChecker::createWhileStatement): - (JSC::SyntaxChecker::createWithStatement): - (JSC::SyntaxChecker::createDoWhileStatement): - (JSC::SyntaxChecker::createLabelStatement): - (JSC::SyntaxChecker::createThrowStatement): - (JSC::SyntaxChecker::createDebugger): - (JSC::SyntaxChecker::createConstStatement): - (JSC::SyntaxChecker::appendConstDecl): - (JSC::SyntaxChecker::createGetterOrSetterProperty): - (JSC::SyntaxChecker::combineCommaNodes): - (JSC::SyntaxChecker::operatorStackPop): - -2012-08-01 Peter Wang <peter.wang@torchmobile.com.cn> - - Web Inspector: [JSC] implement setting breakpoints by line:column - https://bugs.webkit.org/show_bug.cgi?id=53003 - - Reviewed by Geoffrey Garen. - - Add a counter in lexer to record the column of each token. Debugger will use column info - in "Pretty Print" debug mode of Inspector. - - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitDebugHook): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::ArrayNode::toArgumentList): - (JSC::ApplyFunctionCallDotNode::emitBytecode): - (JSC::ConditionalNode::emitBytecode): - (JSC::ConstStatementNode::emitBytecode): - (JSC::EmptyStatementNode::emitBytecode): - (JSC::DebuggerStatementNode::emitBytecode): - (JSC::ExprStatementNode::emitBytecode): - (JSC::VarStatementNode::emitBytecode): - (JSC::IfNode::emitBytecode): - (JSC::IfElseNode::emitBytecode): - (JSC::DoWhileNode::emitBytecode): - (JSC::WhileNode::emitBytecode): - (JSC::ForNode::emitBytecode): - (JSC::ForInNode::emitBytecode): - (JSC::ContinueNode::emitBytecode): - (JSC::BreakNode::emitBytecode): - (JSC::ReturnNode::emitBytecode): - (JSC::WithNode::emitBytecode): - (JSC::SwitchNode::emitBytecode): - (JSC::LabelNode::emitBytecode): - (JSC::ThrowNode::emitBytecode): - (JSC::TryNode::emitBytecode): - (JSC::ProgramNode::emitBytecode): - (JSC::EvalNode::emitBytecode): - (JSC::FunctionBodyNode::emitBytecode): - * debugger/Debugger.h: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwindCallFrame): - (JSC::Interpreter::throwException): - (JSC::Interpreter::debug): - * interpreter/Interpreter.h: - (Interpreter): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * parser/ASTBuilder.h: - (ASTBuilder): - (JSC::ASTBuilder::createCommaExpr): - (JSC::ASTBuilder::createLogicalNot): - (JSC::ASTBuilder::createUnaryPlus): - (JSC::ASTBuilder::createVoid): - (JSC::ASTBuilder::thisExpr): - (JSC::ASTBuilder::createResolve): - (JSC::ASTBuilder::createObjectLiteral): - (JSC::ASTBuilder::createArray): - (JSC::ASTBuilder::createNumberExpr): - (JSC::ASTBuilder::createString): - (JSC::ASTBuilder::createBoolean): - (JSC::ASTBuilder::createNull): - (JSC::ASTBuilder::createBracketAccess): - (JSC::ASTBuilder::createDotAccess): - (JSC::ASTBuilder::createRegExp): - (JSC::ASTBuilder::createNewExpr): - (JSC::ASTBuilder::createConditionalExpr): - (JSC::ASTBuilder::createAssignResolve): - (JSC::ASTBuilder::createFunctionExpr): - (JSC::ASTBuilder::createFunctionBody): - (JSC::ASTBuilder::createGetterOrSetterProperty): - (JSC::ASTBuilder::createArgumentsList): - (JSC::ASTBuilder::createPropertyList): - (JSC::ASTBuilder::createFuncDeclStatement): - (JSC::ASTBuilder::createBlockStatement): - (JSC::ASTBuilder::createExprStatement): - (JSC::ASTBuilder::createIfStatement): - (JSC::ASTBuilder::createForLoop): - (JSC::ASTBuilder::createForInLoop): - (JSC::ASTBuilder::createEmptyStatement): - (JSC::ASTBuilder::createVarStatement): - (JSC::ASTBuilder::createReturnStatement): - (JSC::ASTBuilder::createBreakStatement): - (JSC::ASTBuilder::createContinueStatement): - (JSC::ASTBuilder::createTryStatement): - (JSC::ASTBuilder::createSwitchStatement): - (JSC::ASTBuilder::createWhileStatement): - (JSC::ASTBuilder::createDoWhileStatement): - (JSC::ASTBuilder::createLabelStatement): - (JSC::ASTBuilder::createWithStatement): - (JSC::ASTBuilder::createThrowStatement): - (JSC::ASTBuilder::createDebugger): - (JSC::ASTBuilder::createConstStatement): - (JSC::ASTBuilder::appendConstDecl): - (JSC::ASTBuilder::combineCommaNodes): - (JSC::ASTBuilder::appendBinaryOperation): - (JSC::ASTBuilder::createAssignment): - (JSC::ASTBuilder::createNumber): - (JSC::ASTBuilder::makeTypeOfNode): - (JSC::ASTBuilder::makeDeleteNode): - (JSC::ASTBuilder::makeNegateNode): - (JSC::ASTBuilder::makeBitwiseNotNode): - (JSC::ASTBuilder::makeMultNode): - (JSC::ASTBuilder::makeDivNode): - (JSC::ASTBuilder::makeModNode): - (JSC::ASTBuilder::makeAddNode): - (JSC::ASTBuilder::makeSubNode): - (JSC::ASTBuilder::makeLeftShiftNode): - (JSC::ASTBuilder::makeRightShiftNode): - (JSC::ASTBuilder::makeURightShiftNode): - (JSC::ASTBuilder::makeBitOrNode): - (JSC::ASTBuilder::makeBitAndNode): - (JSC::ASTBuilder::makeBitXOrNode): - (JSC::ASTBuilder::makeFunctionCallNode): - (JSC::ASTBuilder::makeBinaryNode): - (JSC::ASTBuilder::makeAssignNode): - (JSC::ASTBuilder::makePrefixNode): - (JSC::ASTBuilder::makePostfixNode): - * parser/Lexer.cpp: - (JSC::::setCode): - (JSC::::internalShift): - (JSC::::shift): - (JSC::::lex): - * parser/Lexer.h: - (Lexer): - (JSC::Lexer::currentColumnNumber): - (JSC::::lexExpectIdentifier): - * parser/NodeConstructors.h: - (JSC::Node::Node): - (JSC::ExpressionNode::ExpressionNode): - (JSC::StatementNode::StatementNode): - (JSC::NullNode::NullNode): - (JSC::BooleanNode::BooleanNode): - (JSC::NumberNode::NumberNode): - (JSC::StringNode::StringNode): - (JSC::RegExpNode::RegExpNode): - (JSC::ThisNode::ThisNode): - (JSC::ResolveNode::ResolveNode): - (JSC::ArrayNode::ArrayNode): - (JSC::PropertyListNode::PropertyListNode): - (JSC::ObjectLiteralNode::ObjectLiteralNode): - (JSC::BracketAccessorNode::BracketAccessorNode): - (JSC::DotAccessorNode::DotAccessorNode): - (JSC::ArgumentListNode::ArgumentListNode): - (JSC::NewExprNode::NewExprNode): - (JSC::EvalFunctionCallNode::EvalFunctionCallNode): - (JSC::FunctionCallValueNode::FunctionCallValueNode): - (JSC::FunctionCallResolveNode::FunctionCallResolveNode): - (JSC::FunctionCallBracketNode::FunctionCallBracketNode): - (JSC::FunctionCallDotNode::FunctionCallDotNode): - (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): - (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): - (JSC::PrePostResolveNode::PrePostResolveNode): - (JSC::PostfixResolveNode::PostfixResolveNode): - (JSC::PostfixBracketNode::PostfixBracketNode): - (JSC::PostfixDotNode::PostfixDotNode): - (JSC::PostfixErrorNode::PostfixErrorNode): - (JSC::DeleteResolveNode::DeleteResolveNode): - (JSC::DeleteBracketNode::DeleteBracketNode): - (JSC::DeleteDotNode::DeleteDotNode): - (JSC::DeleteValueNode::DeleteValueNode): - (JSC::VoidNode::VoidNode): - (JSC::TypeOfResolveNode::TypeOfResolveNode): - (JSC::TypeOfValueNode::TypeOfValueNode): - (JSC::PrefixResolveNode::PrefixResolveNode): - (JSC::PrefixBracketNode::PrefixBracketNode): - (JSC::PrefixDotNode::PrefixDotNode): - (JSC::PrefixErrorNode::PrefixErrorNode): - (JSC::UnaryOpNode::UnaryOpNode): - (JSC::UnaryPlusNode::UnaryPlusNode): - (JSC::NegateNode::NegateNode): - (JSC::BitwiseNotNode::BitwiseNotNode): - (JSC::LogicalNotNode::LogicalNotNode): - (JSC::BinaryOpNode::BinaryOpNode): - (JSC::MultNode::MultNode): - (JSC::DivNode::DivNode): - (JSC::ModNode::ModNode): - (JSC::AddNode::AddNode): - (JSC::SubNode::SubNode): - (JSC::LeftShiftNode::LeftShiftNode): - (JSC::RightShiftNode::RightShiftNode): - (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): - (JSC::LessNode::LessNode): - (JSC::GreaterNode::GreaterNode): - (JSC::LessEqNode::LessEqNode): - (JSC::GreaterEqNode::GreaterEqNode): - (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): - (JSC::InstanceOfNode::InstanceOfNode): - (JSC::InNode::InNode): - (JSC::EqualNode::EqualNode): - (JSC::NotEqualNode::NotEqualNode): - (JSC::StrictEqualNode::StrictEqualNode): - (JSC::NotStrictEqualNode::NotStrictEqualNode): - (JSC::BitAndNode::BitAndNode): - (JSC::BitOrNode::BitOrNode): - (JSC::BitXOrNode::BitXOrNode): - (JSC::LogicalOpNode::LogicalOpNode): - (JSC::ConditionalNode::ConditionalNode): - (JSC::ReadModifyResolveNode::ReadModifyResolveNode): - (JSC::AssignResolveNode::AssignResolveNode): - (JSC::ReadModifyBracketNode::ReadModifyBracketNode): - (JSC::AssignBracketNode::AssignBracketNode): - (JSC::AssignDotNode::AssignDotNode): - (JSC::ReadModifyDotNode::ReadModifyDotNode): - (JSC::AssignErrorNode::AssignErrorNode): - (JSC::CommaNode::CommaNode): - (JSC::ConstStatementNode::ConstStatementNode): - (JSC::EmptyStatementNode::EmptyStatementNode): - (JSC::DebuggerStatementNode::DebuggerStatementNode): - (JSC::ExprStatementNode::ExprStatementNode): - (JSC::VarStatementNode::VarStatementNode): - (JSC::IfNode::IfNode): - (JSC::IfElseNode::IfElseNode): - (JSC::DoWhileNode::DoWhileNode): - (JSC::WhileNode::WhileNode): - (JSC::ForNode::ForNode): - (JSC::ContinueNode::ContinueNode): - (JSC::BreakNode::BreakNode): - (JSC::ReturnNode::ReturnNode): - (JSC::WithNode::WithNode): - (JSC::LabelNode::LabelNode): - (JSC::ThrowNode::ThrowNode): - (JSC::TryNode::TryNode): - (JSC::FuncExprNode::FuncExprNode): - (JSC::FuncDeclNode::FuncDeclNode): - (JSC::SwitchNode::SwitchNode): - (JSC::ConstDeclNode::ConstDeclNode): - (JSC::BlockNode::BlockNode): - (JSC::ForInNode::ForInNode): - * parser/Nodes.cpp: - (JSC::StatementNode::setLoc): - (JSC): - (JSC::ScopeNode::ScopeNode): - (JSC::ProgramNode::ProgramNode): - (JSC::ProgramNode::create): - (JSC::EvalNode::EvalNode): - (JSC::EvalNode::create): - (JSC::FunctionBodyNode::FunctionBodyNode): - (JSC::FunctionBodyNode::create): - * parser/Nodes.h: - (Node): - (JSC::Node::columnNo): - (ExpressionNode): - (StatementNode): - (JSC::StatementNode::column): - (NullNode): - (BooleanNode): - (NumberNode): - (StringNode): - (RegExpNode): - (ThisNode): - (ResolveNode): - (ArrayNode): - (PropertyListNode): - (ObjectLiteralNode): - (BracketAccessorNode): - (DotAccessorNode): - (ArgumentListNode): - (NewExprNode): - (EvalFunctionCallNode): - (FunctionCallValueNode): - (FunctionCallResolveNode): - (FunctionCallBracketNode): - (FunctionCallDotNode): - (CallFunctionCallDotNode): - (ApplyFunctionCallDotNode): - (PrePostResolveNode): - (PostfixResolveNode): - (PostfixBracketNode): - (PostfixDotNode): - (PostfixErrorNode): - (DeleteResolveNode): - (DeleteBracketNode): - (DeleteDotNode): - (DeleteValueNode): - (VoidNode): - (TypeOfResolveNode): - (TypeOfValueNode): - (PrefixResolveNode): - (PrefixBracketNode): - (PrefixDotNode): - (PrefixErrorNode): - (UnaryOpNode): - (UnaryPlusNode): - (NegateNode): - (BitwiseNotNode): - (LogicalNotNode): - (BinaryOpNode): - (MultNode): - (DivNode): - (ModNode): - (AddNode): - (SubNode): - (LeftShiftNode): - (RightShiftNode): - (UnsignedRightShiftNode): - (LessNode): - (GreaterNode): - (LessEqNode): - (GreaterEqNode): - (ThrowableBinaryOpNode): - (InstanceOfNode): - (InNode): - (EqualNode): - (NotEqualNode): - (StrictEqualNode): - (NotStrictEqualNode): - (BitAndNode): - (BitOrNode): - (BitXOrNode): - (LogicalOpNode): - (ConditionalNode): - (ReadModifyResolveNode): - (AssignResolveNode): - (ReadModifyBracketNode): - (AssignBracketNode): - (AssignDotNode): - (ReadModifyDotNode): - (AssignErrorNode): - (CommaNode): - (ConstDeclNode): - (ConstStatementNode): - (BlockNode): - (EmptyStatementNode): - (DebuggerStatementNode): - (ExprStatementNode): - (VarStatementNode): - (IfNode): - (IfElseNode): - (DoWhileNode): - (WhileNode): - (ForNode): - (ForInNode): - (ContinueNode): - (BreakNode): - (ReturnNode): - (WithNode): - (LabelNode): - (ThrowNode): - (TryNode): - (ScopeNode): - (ProgramNode): - (EvalNode): - (FunctionBodyNode): - (FuncExprNode): - (FuncDeclNode): - (SwitchNode): - * parser/Parser.cpp: - (JSC::::parseSourceElements): - (JSC::::parseVarDeclaration): - (JSC::::parseConstDeclaration): - (JSC::::parseDoWhileStatement): - (JSC::::parseWhileStatement): - (JSC::::parseVarDeclarationList): - (JSC::::parseConstDeclarationList): - (JSC::::parseForStatement): - (JSC::::parseBreakStatement): - (JSC::::parseContinueStatement): - (JSC::::parseReturnStatement): - (JSC::::parseThrowStatement): - (JSC::::parseWithStatement): - (JSC::::parseSwitchStatement): - (JSC::::parseTryStatement): - (JSC::::parseDebuggerStatement): - (JSC::::parseBlockStatement): - (JSC::::parseStatement): - (JSC::::parseFunctionBody): - (JSC::::parseFunctionInfo): - (JSC::::parseFunctionDeclaration): - (JSC::::parseExpressionOrLabelStatement): - (JSC::::parseExpressionStatement): - (JSC::::parseIfStatement): - (JSC::::parseExpression): - (JSC::::parseAssignmentExpression): - (JSC::::parseConditionalExpression): - (JSC::::parseBinaryExpression): - (JSC::::parseProperty): - (JSC::::parseObjectLiteral): - (JSC::::parseStrictObjectLiteral): - (JSC::::parseArrayLiteral): - (JSC::::parsePrimaryExpression): - (JSC::::parseArguments): - (JSC::::parseMemberExpression): - (JSC::::parseUnaryExpression): - * parser/Parser.h: - (JSC::Parser::next): - (JSC::Parser::nextExpectIdentifier): - (JSC::Parser::tokenStart): - (JSC::Parser::tokenLine): - (JSC::Parser::tokenEnd): - (JSC::Parser::tokenLocation): - (Parser): - (JSC::Parser::getTokenName): - (JSC::::parse): - * parser/ParserTokens.h: - (JSC::JSTokenLocation::JSTokenLocation): - (JSTokenLocation): - (JSToken): - * parser/SourceProviderCacheItem.h: - (JSC::SourceProviderCacheItem::closeBraceToken): - * parser/SyntaxChecker.h: - (JSC::SyntaxChecker::makeFunctionCallNode): - (JSC::SyntaxChecker::createCommaExpr): - (JSC::SyntaxChecker::makeAssignNode): - (JSC::SyntaxChecker::makePrefixNode): - (JSC::SyntaxChecker::makePostfixNode): - (JSC::SyntaxChecker::makeTypeOfNode): - (JSC::SyntaxChecker::makeDeleteNode): - (JSC::SyntaxChecker::makeNegateNode): - (JSC::SyntaxChecker::makeBitwiseNotNode): - (JSC::SyntaxChecker::createLogicalNot): - (JSC::SyntaxChecker::createUnaryPlus): - (JSC::SyntaxChecker::createVoid): - (JSC::SyntaxChecker::thisExpr): - (JSC::SyntaxChecker::createResolve): - (JSC::SyntaxChecker::createObjectLiteral): - (JSC::SyntaxChecker::createArray): - (JSC::SyntaxChecker::createNumberExpr): - (JSC::SyntaxChecker::createString): - (JSC::SyntaxChecker::createBoolean): - (JSC::SyntaxChecker::createNull): - (JSC::SyntaxChecker::createBracketAccess): - (JSC::SyntaxChecker::createDotAccess): - (JSC::SyntaxChecker::createRegExp): - (JSC::SyntaxChecker::createNewExpr): - (JSC::SyntaxChecker::createConditionalExpr): - (JSC::SyntaxChecker::createAssignResolve): - (JSC::SyntaxChecker::createFunctionExpr): - (JSC::SyntaxChecker::createFunctionBody): - (JSC::SyntaxChecker::createArgumentsList): - (JSC::SyntaxChecker::createPropertyList): - (JSC::SyntaxChecker::createFuncDeclStatement): - (JSC::SyntaxChecker::createBlockStatement): - (JSC::SyntaxChecker::createExprStatement): - (JSC::SyntaxChecker::createIfStatement): - (JSC::SyntaxChecker::createForLoop): - (JSC::SyntaxChecker::createForInLoop): - (JSC::SyntaxChecker::createEmptyStatement): - (JSC::SyntaxChecker::createVarStatement): - (JSC::SyntaxChecker::createReturnStatement): - (JSC::SyntaxChecker::createBreakStatement): - (JSC::SyntaxChecker::createContinueStatement): - (JSC::SyntaxChecker::createTryStatement): - (JSC::SyntaxChecker::createSwitchStatement): - (JSC::SyntaxChecker::createWhileStatement): - (JSC::SyntaxChecker::createWithStatement): - (JSC::SyntaxChecker::createDoWhileStatement): - (JSC::SyntaxChecker::createLabelStatement): - (JSC::SyntaxChecker::createThrowStatement): - (JSC::SyntaxChecker::createDebugger): - (JSC::SyntaxChecker::createConstStatement): - (JSC::SyntaxChecker::appendConstDecl): - (JSC::SyntaxChecker::createGetterOrSetterProperty): - (JSC::SyntaxChecker::combineCommaNodes): - (JSC::SyntaxChecker::operatorStackPop): - -2012-08-01 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 Jian Li <jianli@chromium.org> - - Add new CSS property "-webkit-widget-region" to expose dashboard region support for other port - https://bugs.webkit.org/show_bug.cgi?id=90298 - - Reviewed by Adam Barth. - - * Configurations/FeatureDefines.xcconfig: Add ENABLE_WIDGET_REGION define. - -2012-08-01 Patrick Gansterer <paroga@webkit.org> - - Replace WTF::getCurrentLocalTime() with GregorianDateTime::setToCurrentLocalTime() - https://bugs.webkit.org/show_bug.cgi?id=92286 - - Reviewed by Geoffrey Garen. - - Add a method to GregorianDateTime to set its values to the current locale time. - Replacing all occurrences of getCurrentLocalTime with the new function allows - us to remove getCurrentLocalTime in a next step. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-08-01 Mark Hahnenberg <mhahnenberg@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <sam@webkit.org> - - Fix the Windows build. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-07-31 Geoffrey Garen <ggaren@apple.com> - - Maybe fix the GCC build. - - * heap/HeapBlock.h: - (HeapBlock): Accommodate incorrect parsing in GCC. - -2012-07-31 Sam Weinig <sam@webkit.org> - - Stop masking 8 bits off of the visited link hash. We need all the bits! - https://bugs.webkit.org/show_bug.cgi?id=92799 - - Reviewed by Anders Carlsson. + Michael Saboff added an optimized version of UChar->LChar conversion in r125846. + Use this function in JSC::Identifier. * runtime/Identifier.cpp: - (JSC::IdentifierCStringTranslator::hash): - (JSC::IdentifierLCharFromUCharTranslator::hash): - * runtime/Identifier.h: - (JSC::IdentifierCharBufferTranslator::hash): - Update for new function names. - -2012-07-31 Geoffrey Garen <ggaren@apple.com> - - 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 <mhahnenberg@apple.com> + (JSC::IdentifierLCharFromUCharTranslator::translate): - 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 <ggaren@apple.com> - - Fix all the other builds I just broke. Maybe fix the Windows build. - - * heap/HeapBlock.h: - (HeapBlock): WTF? - -2012-07-31 Geoffrey Garen <ggaren@apple.com> - - Maybe fix the Windows build. - - * heap/HeapBlock.h: - (HeapBlock): WTF? - -2012-07-31 Geoffrey Garen <ggaren@apple.com> - - Maybe fix the Windows build. - - * heap/HeapBlock.h: - (HeapBlock): WTF? - -2012-07-31 Geoffrey Garen <ggaren@apple.com> - - 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-10-04 Michael Saboff <msaboff@apple.com> -2012-07-31 Filip Pizlo <fpizlo@apple.com> + After r130344, OpaqueJSString() creates a empty string which should be a null string + https://bugs.webkit.org/show_bug.cgi?id=98417 - 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 <fu@mips.com> - - 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 <webkit.review.bot@gmail.com> - - 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 <mhahnenberg@apple.com> - - 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 <fpizlo@apple.com> - - 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 <cabanier@adobe.com> - - 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 <mhahnenberg@apple.com> - - Split functionality of MarkedAllocator::m_currentBlock - https://bugs.webkit.org/show_bug.cgi?id=92550 - - Reviewed by Filip Pizlo. + Reviewed by Alexey Proskuryakov. - 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. + Removed the setting of enclosed string to an empty string from default constructor. + Before changeset r130344, the semantic was the default constructor produced a null + string. - * 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. + * API/OpaqueJSString.h: + (OpaqueJSString::OpaqueJSString): -2012-07-27 Mark Hahnenberg <mhahnenberg@apple.com> +2012-10-04 Csaba Osztrogonác <ossy@webkit.org> - Increase inline storage for JSFinalObjects by one - https://bugs.webkit.org/show_bug.cgi?id=92526 + [Qt] Add missing LLInt dependencies to the build system + https://bugs.webkit.org/show_bug.cgi?id=98394 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): + * DerivedSources.pri: + * LLIntOffsetsExtractor.pro: -2012-07-27 Jer Noble <jer.noble@apple.com> +2012-10-03 Geoffrey Garen <ggaren@apple.com> - Support a rational time class for use by media elements. - https://bugs.webkit.org/show_bug.cgi?id=88787 + Next step toward fixing Windows: add new symbol. - Re-export WTF::MediaTime from JavaScriptCore. - - Reviewed by Eric Carlson. - - * JavaScriptCore.order: * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: -2012-07-26 Filip Pizlo <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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<Structure> down below the explicit template specialization - for allocateCell<Structure>. 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 <fpizlo@apple.com> - - 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 <zherczeg@webkit.org> - - [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 <mhahnenberg@apple.com> - - 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 <fpizlo@apple.com> - - 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. +2012-10-03 Geoffrey Garen <ggaren@apple.com> - * 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 <mhahnenberg@apple.com> - - 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 <caio.oliveira@openbossa.org> - - 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 <paroga@webkit.org> - - 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 <fpizlo@apple.com> - - 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 <paroga@webkit.org> - - 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 <paroga@webkit.org> - - [WIN] Build fix after r123417. + First step toward fixing Windows: remove old symbol. * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: -2012-07-23 Patrick Gansterer <paroga@webkit.org> - - 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 <fpizlo@apple.com> +2012-10-03 Geoffrey Garen <ggaren@apple.com> - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <simon.fraser@apple.com> - - 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 <paroga@webkit.org> - - 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 <simon.fraser@apple.com> - - 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 <yoli@rim.com> - - [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 <tkent@chromium.org> - - 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 <tkent@chromium.org> - - 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 <paroga@webkit.org> - - [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 <tkent@chromium.org> - - 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 <shenhan@google.com> - - [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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mark.lam@apple.com> - - 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 <paroga@webkit.org> - - [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 <mark.lam@apple.com> - - 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ó <kkristof@inf.u-szeged.hu> - - [Qt] Unreviewed buildfix after r123042. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::dumpRegisters): - -2012-07-18 Filip Pizlo <fpizlo@apple.com> - - 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 <oliver@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - [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 <rgabor@webkit.org> - - Unreviewed buildfix from Zoltan Herczeg after 122768. - - * dfg/DFGCCallHelpers.h: - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - (CCallHelpers): - -2012-07-17 David Barr <davidbarr@chromium.org> - - 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 <fpizlo@apple.com> - - 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 <oliver@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <paroga@webkit.org> - - 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 <rgabor@webkit.org> - - Unreviewed buildfix after r122729. Typo fix. - - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::add32): - -2012-07-16 Gabor Rapcsanyi <rgabor@webkit.org> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mark.lam@apple.com> - - OfflineASM Pretty printing and commenting enhancements. - https://bugs.webkit.org/show_bug.cgi?id=91281 + Removed the assumption that "final" objects have a fixed number of inline slots + https://bugs.webkit.org/show_bug.cgi?id=98332 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 <fpizlo@apple.com> - - ASSERTION FAILED: use.useKind() != DoubleUse - https://bugs.webkit.org/show_bug.cgi?id=91082 - - Reviewed by Geoffrey Garen. + This is a step toward object size inference. - The implementation of Branch() was unwisely relying on register allocation state - to decide what speculations to perform. That's never correct. + I replaced the inline storage capacity constant with a data member per + structure, set the the maximum supported value for the constant to 100, + then fixed what broke. (Note that even though this patch increases the + theoretical maximum inline capacity, it doesn't change any actual inline + capacity.) * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): - -2012-07-13 Sheriff Bot <webkit.review.bot@gmail.com> - - 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 <oliver@apple.com> - - 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 <yoli@rim.com> - - [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 <paroga@webkit.org> - - [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 <paroga@webkit.org> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <allan.jensen@nokia.com> - - [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 <ossy@webkit.org> - - 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 <cavalcantii@gmail.com> - - 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 <mrowe@apple.com> - - <http://webkit.org/b/91024> 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <kevino@theolliviers.com> - - [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 <fu@mips.com> - - 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 <andersca@apple.com> - - 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 <bpoulain@apple.com> - - 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 <wingo@igalia.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <falken@chromium.org> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 - <rdar://problem/11823843> - - 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 <fpizlo@apple.com> - - 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 <webkit.review.bot@gmail.com> - - 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 <falken@chromium.org> - - 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 <rniwa@webkit.org> - - gcc build fix after r121925. - - * runtime/JSObject.h: - (JSC::JSFinalObject::finishCreation): - -2012-07-08 Zoltan Herczeg <zherczeg@webkit.org> + (JSC::JIT::compileGetDirectOffset): These functions just get a rename: + the constant they need is the first out of line offset along the offset + number line, which is not necessarily the same thing (and is, in this + patch, never the same thing) as the inline capacity of any given object. - [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 <fpizlo@apple.com> - - 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): + * jit/JITPropertyAccess32_64.cpp: This function changes functionality, + since it needs to convert from the abstract offset number line to an + actual offset in memory, and it can't assume that inline and out-of-line + offsets are contiguous on the number line. -2012-07-06 Pravin D <pravind.2k4@gmail.com> - - Build Error on Qt Linux build - https://bugs.webkit.org/show_bug.cgi?id=90699 + (JSC::JIT::compileGetDirectOffset): Updated for rename. - Reviewed by Laszlo Gombos. + (JSC::JIT::emit_op_get_by_pname): Same as emit_op_get_by_pname above. - * parser/Parser.cpp: - (JSC::::parseForStatement): - Removed unused boolean variable as this was causing build error on Qt Linux. - -2012-07-06 Nuno Lopes <nlopes@apple.com> + * llint/LowLevelInterpreter.asm: Updated to mirror changes in PropertyOffset.h, + since we duplicate values from there. - 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 <zherczeg@webkit.org> - - [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 <fpizlo@apple.com> - - 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 <ossy@webkit.org> - - [Qt] Unreviewed 64 bit buildfix after r121925. - - * bytecode/PutByIdStatus.cpp: - (JSC::PutByIdStatus::computeFromLLInt): - -2012-07-05 Michael Saboff <msaboff@apple.com> - - 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 <fpizlo@apple.com> - - Inline property storage should not be wasted when it is exhausted - https://bugs.webkit.org/show_bug.cgi?id=90347 + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Just like the JIT, most things are just + renames, and get_by_pname changes to do more math. I also standardized + offset calculations to use a hard-coded "-2", to match the JIT. This + isn't really better, but it makes global search and replace easier, + should we choose to refactor this code not to hard-code constants. - 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. + I also renamed loadPropertyAtVariableOffsetKnownNotFinal to + loadPropertyAtVariableOffsetKnownNotInline in order to sever the assumption + that inline capacity is tied to object type, and I changed the 64bit LLInt + to use this -- not using this previously seems to have been an oversight. - * 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): + (JSNonFinalObject): + (JSC::JSFinalObject::createStructure): (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): + (JSC::JSFinalObject::finishCreation): Updated for above changes. + * 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): + (JSC::JSPropertyNameIterator::finishCreation): Store the inline capacity + of our object, since it's not a constant. + + (JSC::JSPropertyNameIterator::getOffset): Removed. This function was + wrong. Luckily, it was also unused, since the C++ interpreter is gone. + * runtime/PropertyMapHashTable.h: - (PropertyMapEntry): - (JSC::PropertyMapEntry::PropertyMapEntry): - (PropertyTable): - (JSC::PropertyTable::PropertyTable): - (JSC::PropertyTable::getDeletedOffset): - (JSC::PropertyTable::addDeletedOffset): + (PropertyTable): Use a helper function instead of hard-coding assumptions + about object types. + (JSC::PropertyTable::nextOffset): - (JSC): - (JSC::PropertyTable::sizeInMemory): - * runtime/PropertyOffset.h: Added. + * runtime/PropertyOffset.h: (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): + (JSC::propertyOffsetFor): Refactored these functions to take inline capacity + as an argument, since it's not fixed at compile time anymore. + * 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): + (JSC::Structure::create): Removed some hard-coded assumptions about inline + capacity and object type, and replaced with more liberal use of helper functions. -2012-07-05 Oliver Hunt <oliver@apple.com> +2012-10-03 Michael Saboff <msaboff@apple.com> - 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 <zherczeg@webkit.org> - - [Qt] Unreviewed buildfix after r121886. Typo fix. - - * assembler/MacroAssemblerARM.cpp: - (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): - -2012-07-05 Zoltan Herczeg <zherczeg@webkit.org> - - 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 <ascian@rim.com> - - 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 <wingo@igalia.com> - - [GTK] Enable parallel GC - https://bugs.webkit.org/show_bug.cgi?id=90568 - - Reviewed by Martin Robinson. - - * runtime/Options.cpp: Include <algorithm.h> for std::min. - -2012-07-04 John Mellor <johnme@chromium.org> - - 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 <msaboff@apple.com> - - 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 <tony@chromium.org> - - [chromium] Unreviewed, update .gitignore to handle VS2010 files. - - * JavaScriptCore.gyp/.gitignore: - -2012-07-03 Mark Lam <mark.lam@apple.com> - - 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 <jocelyn.turcotte@nokia.com> Joel Dillon <joel.dillon@codethink.co.uk> - - [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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <barraclough@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <zandobersek@gmail.com> - - 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 <mhahnenberg@apple.com> - - Remove warning about protected values when the Heap is being destroyed - https://bugs.webkit.org/show_bug.cgi?id=90302 + OpaqueJSString doesn't optimally handle 8 bit strings + https://bugs.webkit.org/show_bug.cgi?id=98300 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mark.lam@apple.com> - - 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. + Change OpaqueJSString to store and manage a String instead of a UChar buffer. + The member string is a copy of any string used during creation. - 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 <oliver@apple.com> - - 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 <tkent@chromium.org> - - 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 <msaboff@apple.com> - - [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 <webkit.review.bot@gmail.com> - - 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 <fpizlo@apple.com> - - 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 - <rdar://problem/11764613> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ascian@rim.com> - - 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 <oswald.buddenhagen@nokia.com> - - [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ø <tor.arne.vestbo@nokia.com> - - [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 <dominicc@chromium.org> - - [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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - DFG PutByValAlias is too aggressive - https://bugs.webkit.org/show_bug.cgi?id=90026 - <rdar://problem/11751830> - - 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 <yoli@rim.com> - - [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. + * API/OpaqueJSString.cpp: + (OpaqueJSString::create): + (OpaqueJSString::identifier): + * API/OpaqueJSString.h: + (OpaqueJSString::characters): + (OpaqueJSString::length): + (OpaqueJSString::string): + (OpaqueJSString::OpaqueJSString): + (OpaqueJSString): - * runtime/MemoryStatistics.cpp: - (JSC::globalMemoryStatistics): +2012-10-03 Filip Pizlo <fpizlo@apple.com> -2012-06-25 Filip Pizlo <fpizlo@apple.com> + Array.splice should be fast when it is used to remove elements other than the very first + https://bugs.webkit.org/show_bug.cgi?id=98236 - 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 Michael Saboff. - 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. + Applied the same technique that was used to optimize the unshift case of splice in + http://trac.webkit.org/changeset/129676. This is a >20x speed-up on programs that + use splice for element removal. - * 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/ArrayPrototype.cpp: + (JSC::shift): + * runtime/JSArray.cpp: + (JSC::JSArray::shiftCount): * runtime/JSArray.h: - (JSC): - (JSC::constructArray): - * runtime/JSGlobalObject.h: - (JSC): - (JSC::constructArray): - -2012-06-26 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <yoli@rim.com> - - [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 <webkit.review.bot@gmail.com> - - 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 <achicu@adobe.com> - - [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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <peter@chromium.org> - - [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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - Adding copyrights to new files. - - * heap/HeapTimer.cpp: - * heap/HeapTimer.h: - * heap/IncrementalSweeper.cpp: - * heap/IncrementalSweeper.h: - -2012-06-21 Arnaud Renevier <arno@renevier.net> - - 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 <ryuan.choi@gmail.com> - - [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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - [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 <fpizlo@apple.com> - - 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 - <rdar://problem/11700089> - - Reviewed by Geoffrey Garen. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - -2012-06-19 Mark Lam <mark.lam@apple.com> - - 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 <fpizlo@apple.com> - - Unreviewed, try to fix Windows build. - - * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: - -2012-06-17 Filip Pizlo <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <mkwst@chromium.org> - - 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: + (JSArray): -2012-06-18 Mark Lam <mark.lam@apple.com> +2012-09-16 Mark Hahnenberg <mhahnenberg@apple.com> - 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 + Delayed structure sweep can leak structures without bound + https://bugs.webkit.org/show_bug.cgi?id=96546 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 <aestes@apple.com> - - Fix r120663, which didn't land the change that was reviewed. - -2012-06-18 Andy Estes <aestes@apple.com> - - [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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <yoli@rim.com> - - [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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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. + This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only + allocators. We now have separate allocators for our three types of objects: those objects with no destructors, + those objects with destructors and with immortal structures, and those objects with destructors that don't have + immortal structures. All of the objects of the third type (destructors without immortal structures) now + inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores + the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction. - * 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: + * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor. (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 <webkit.review.bot@gmail.com> - - 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::JSCallbackConstructor::JSCallbackConstructor): + * API/JSCallbackConstructor.h: + (JSCallbackConstructor): + * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for + JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer. (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::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add + the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides + to subclass this. We use this same technique for many other subclasses of JSGlobalObject. + (JSC::::createStructure): + * API/JSCallbackObject.h: + (JSCallbackObject): (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: + * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead. + (OpaqueJSClass::prototype): + * API/JSObjectRef.cpp: Ditto. + (JSObjectMake): + (JSObjectGetPrivate): + (JSObjectSetPrivate): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + * API/JSValueRef.cpp: Ditto. + (JSValueIsObjectOfClass): + * API/JSWeakObjectMapRefPrivate.cpp: Ditto. + * JSCTypedArrayStubs.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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - Unreviewed build fix for ARMv7 debug builds. - - * jit/JITStubs.cpp: - (JSC::JITThunks::JITThunks): - -2012-06-12 Geoffrey Garen <ggaren@apple.com> - - Build fix for case-sensitive file systems: use the right case. - - * heap/ListableHandler.h: - -2012-06-11 Geoffrey Garen <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <leo.yang@torchmobile.com.cn> - - 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 <fpizlo@apple.com> - - 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 - <rdar://problem/11513971> - - 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 <fpizlo@apple.com> - - REGRESSION (r119779): Javascript TypeError: 'undefined' is not an object - https://bugs.webkit.org/show_bug.cgi?id=88783 - <rdar://problem/11640299> - - 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 <hojong.han@samsung.com> - - 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 <gyuyoung.kim@samsung.com> - - [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 <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck issues. - - * GNUmakefile.list.am: Remove non existent header file. - -2012-06-10 Patrick Gansterer <paroga@webkit.org> - - Unreviewed. Build fix for !ENABLE(JIT) after r119844 and r119925. - - * runtime/Executable.h: - (ExecutableBase): - (JSC::ExecutableBase::clearCodeVirtual): - -2012-06-10 Patrick Gansterer <paroga@webkit.org> - - Unreviewed. Build fix for !ENABLE(JIT) after r119844. - - * runtime/Executable.h: - (ExecutableBase): - (JSC): - -2012-06-09 Dominic Cooney <dominicc@chromium.org> - - [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 <ggaren@apple.com> - - 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 <sukolsak@google.com> - - 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 <ggaren@apple.com> - - 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 <barraclough@apple.com> - - Unreviewed roll out r119795. - - This broke jquery/core.html - - * dfg/DFGSpeculativeJIT.h: + * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG. (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 <fpizlo@apple.com> - - 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 <wingo@igalia.com> - - 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 <ggaren@apple.com> - - 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. - + (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): * 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 <fpizlo@apple.com> - - 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 <barraclough@apple.com> - - 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 <barraclough@apple.com> - - 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 <paroga@webkit.org> - - Unreviewed. Build fix for !ENABLE(JIT) after r119441. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::privateExecute): - -2012-06-07 Andy Wingo <wingo@igalia.com> - - 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 <rniwa@webkit.org> - - Chromium build fix attempt. Why do we need to list these files in gyp!? - - * JavaScriptCore.gypi: - -2012-06-06 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function + since it's always safe to sweep Structures now. + (JSC::Heap::allocatorForObjectWithNormalDestructor): + (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): (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::Heap::allocateWithNormalDestructor): (JSC): - * runtime/WriteBarrier.h: - -2012-06-06 Filip Pizlo <fpizlo@apple.com> - - 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 <msaboff@apple.com> - - 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 <barraclough@apple.com> - - 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 <wingo@igalia.com> - - 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 <wingo@igalia.com> - - [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 <wingo@igalia.com> - - 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 <mitz@apple.com> - - Reverted r119567, the fix for <http://webkit.org/b/88378>, 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::Heap::allocateWithImmortalStructureDestructor): + * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the + IncrementalSweeper since it's always safe to sweep Structures now. + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::sweepNextBlock): + (JSC::IncrementalSweeper::startSweeping): + (JSC::IncrementalSweeper::willFinishSweeping): (JSC): - (JSC::JSObject::offsetOfInheritorID): - (JSC::JSObject::inheritorID): - -2012-06-05 Yuqiang Xian <yuqiang.xian@intel.com> - - 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): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add + tracking of the specific destructor type of allocator. + (JSC::MarkedAllocator::tryAllocateHelper): + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::destructorType): + (MarkedAllocator): + (JSC::MarkedAllocator::MarkedAllocator): + (JSC::MarkedAllocator::init): + * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. + We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls. + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): (JSC): - (JSC::roundThunkGenerator): - -2012-06-05 Gavin Barraclough <barraclough@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <dw.im@samsung.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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::specializedSweep): (JSC::MarkedBlock::sweep): + (JSC::MarkedBlock::sweepHelper): * heap/MarkedBlock.h: - (JSC::MarkedBlock::resetAllocator): - (JSC): - * heap/MarkedSpace.cpp: - (JSC::ResetAllocator::operator()): (JSC): + (JSC::MarkedBlock::allocator): + (JSC::MarkedBlock::destructorType): + * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace. + (JSC::MarkedSpace::MarkedSpace): (JSC::MarkedSpace::resetAllocators): - (JSC::MarkedSpace::sweepWeakSets): + (JSC::MarkedSpace::canonicalizeCellLivenessData): + (JSC::MarkedSpace::isPagedOut): + (JSC::MarkedSpace::freeBlock): * 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 <fpizlo@apple.com> - - 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 <barraclough@apple.com> - - 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::MarkedSpace::immortalStructureDestructorAllocatorFor): + (JSC::MarkedSpace::normalDestructorAllocatorFor): + (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): + (JSC::MarkedSpace::allocateWithNormalDestructor): + (JSC::MarkedSpace::forEachBlock): + * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function. + * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT. + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC::JIT::emitAllocateJSFinalObject): + (JSC::JIT::emitAllocateJSArray): + * jsc.cpp: + (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from + JSDestructibleObject. + * runtime/Arguments.cpp: Inherit from JSDestructibleObject. (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): + * runtime/Arguments.h: + (Arguments): + (JSC::Arguments::Arguments): + * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor. (JSC): - - Renamed enabledProfilerReference to unusedX. - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter.asm: - * profiler/Profiler.cpp: + * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures. (JSC): - (JSC::Profiler::startProfiling): - (JSC::Profiler::stopProfiling): - * profiler/Profiler.h: - (Profiler): - - Removed s_sharedEnabledProfilerReference, enabledProfilerReference(). - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - * runtime/JSGlobalData.h: + * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject. (JSC): - (JSC::JSGlobalData::enabledProfiler): - (JSGlobalData): - - Added m_enabledProfiler, enabledProfiler(). - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::~JSGlobalObject): - -2012-06-04 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <andersca@apple.com> - - Fix a struct/class mismatch. - - * heap/Handle.h: - (Handle): - -2012-06-04 David Kilzer <ddkilzer@apple.com> - - BUILD FIX: FeatureDefines.xcconfig should match across projects - - * Configurations/FeatureDefines.xcconfig: - - Add missing ENABLE_LEGACY_CSS_VENDOR_PREFIXES. - -2012-06-02 Geoffrey Garen <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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 <arv@chromium.org> - - 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::InternalFunction::InternalFunction): + * runtime/InternalFunction.h: + (InternalFunction): + * runtime/JSCell.h: Added two static bools, needsDestruction and hasImmortalStructure, that classes can override + to indicate at compile time which part of the heap they should be allocated in. + (JSC::allocateCell): Use the appropriate allocator depending on the destructor type. + * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be + accessed safely when the object is being destroyed. + (JSC): + (JSDestructibleObject): + (JSC::JSDestructibleObject::classInfo): + (JSC::JSDestructibleObject::JSDestructibleObject): + (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe. + * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all + of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well. (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: - (JSC): (JSGlobalObject): - (JSC::JSGlobalObject::errorPrototype): - -2012-05-31 Andy Wingo <wingo@igalia.com> - - 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 <mhahnenberg@apple.com> - - 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 <paroga@webkit.org> - - [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 <oliver@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <oliver@apple.com> - - 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 <fpizlo@apple.com> - - 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 <paroga@webkit.org> - - Unreviewed. Build fix for !ENABLE(JIT) after r117823. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - -2012-05-30 Sheriff Bot <webkit.review.bot@gmail.com> - - 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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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<T>, we need to verify manually that the WeakImpl is live before - we return its payload. - -2012-05-29 Mark Hahnenberg <mhahnenberg@apple.com> - - 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 <davidbarr@chromium.org> - - 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 <webkit.review.bot@gmail.com> - - 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 <fpizlo@apple.com> - - 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 <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing header file. - -2012-05-27 Geoffrey Garen <ggaren@apple.com> - - 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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <timothy_horton@apple.com> - - Add feature defines for web-facing parts of CSS Regions and Exclusions - https://bugs.webkit.org/show_bug.cgi?id=87442 - <rdar://problem/10887709> - - Reviewed by Dan Bernstein. - - * Configurations/FeatureDefines.xcconfig: - -2012-05-24 Geoffrey Garen <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one + for the m_rareData field when it's created. + (JSC::JSGlobalObject::create): (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: + * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject. + (JSGlobalThis): + (JSC::JSGlobalThis::JSGlobalThis): + * runtime/JSPropertyNameIterator.h: Has an immortal Structure. (JSC): - * heap/WeakSet.h: - (WeakSet): - (JSC::WeakSet::heap): + * runtime/JSScope.cpp: (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 <barraclough@apple.com> - - Fix arm build - - Rubber stamped by Geoff Garen - - * dfg/DFGGPRInfo.h: - (GPRInfo): - -2012-05-24 Gavin Barraclough <barraclough@apple.com> - - 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: + * runtime/JSString.h: Has an immortal Structure. (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: + * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject. + (JSWrapperObject): + (JSC::JSWrapperObject::JSWrapperObject): + * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff. (JSC): - * jit/ExecutableAllocator.h: - (ExecutableAllocator): - -2012-05-24 John Mellor <johnme@chromium.org> - - 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 <allan.jensen@nokia.com> - - 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 <fpizlo@apple.com> - - 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 <ossy@webkit.org> - - Unreviewed 32 bit buildfix after r118325. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): Use ASSERT_UNUSED instead ASSERT. - -2012-05-23 Filip Pizlo <fpizlo@apple.com> - - DFG operationTearOffActivation should return after handling the null activation case - https://bugs.webkit.org/show_bug.cgi?id=87348 - <rdar://problem/11522295> - - Reviewed by Oliver Hunt. - - * dfg/DFGOperations.cpp: - -2012-05-23 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, merge the arguments fix in r118138 to get bots green. - - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): - -2012-05-20 Filip Pizlo <fpizlo@apple.com> - - 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: + * runtime/NameInstance.h: Inherit from JSDestructibleObject. + (NameInstance): + * runtime/RegExp.h: Has immortal Structure. (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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ojan@chromium.org> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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 <fpizlo@apple.com> - - Use after free in JSC::DFG::ByteCodeParser::processPhiStack - https://bugs.webkit.org/show_bug.cgi?id=87312 - <rdar://problem/11518848> - - Reviewed by Oliver Hunt. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::processPhiStack): - (JSC::DFG::ByteCodeParser::parse): - -2012-05-23 Filip Pizlo <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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: + * runtime/RegExpObject.cpp: Inheritance cleanup. (JSC): - (JSC::CallFrame::someCodeBlockForPossiblyInlinedCode): - * interpreter/CallFrame.h: - (ExecState): - (JSC::ExecState::someCodeBlockForPossiblyInlinedCode): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::retrieveArgumentsFromVMCode): - * runtime/Arguments.cpp: - (JSC::Arguments::tearOff): + * runtime/SparseArrayValueMap.h: Has immortal Structure. (JSC): - (JSC::Arguments::tearOffForInlineCallFrame): - * runtime/Arguments.h: - (Arguments): - (JSC::Arguments::create): - (JSC::Arguments::finishCreation): + * runtime/Structure.h: Has immortal Structure. (JSC): - -2012-05-23 Filip Pizlo <fpizlo@apple.com> - - 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 <ggaren@apple.com> - - 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): + * runtime/StructureChain.h: Ditto. (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 <ggaren@apple.com> - - 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 <oswald.buddenhagen@nokia.com> - - [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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <fpizlo@apple.com> - - 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 <mhahnenberg@apple.com> - - 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. + * runtime/SymbolTable.h: Ditto. + (SharedSymbolTable): (JSC): - (JSC::CopiedSpace::startedCopying): - (JSC::CopiedSpace::addNewBlock): - -2012-05-22 Geoffrey Garen <ggaren@apple.com> - - 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 == +== Rolled over to ChangeLog-2012-10-02 == |