diff options
Diffstat (limited to 'Source/JavaScriptCore/ChangeLog')
| -rw-r--r-- | Source/JavaScriptCore/ChangeLog | 9281 |
1 files changed, 0 insertions, 9281 deletions
diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog deleted file mode 100644 index df3f15070..000000000 --- a/Source/JavaScriptCore/ChangeLog +++ /dev/null @@ -1,9281 +0,0 @@ -2013-04-09 Balazs Kilvady <kilvadyb@homejinni.com> - - LLInt conditional branch compilation fault on MIPS. - https://bugs.webkit.org/show_bug.cgi?id=114264 - - Reviewed by Filip Pizlo. - - Fix conditional branch compilation in LLInt offlineasm. - - * offlineasm/mips.rb: - -2013-02-18 Balazs Kilvady <kilvadyb@homejinni.com> - - MIPS DFG implementation. - https://bugs.webkit.org/show_bug.cgi?id=101328 - - Reviewed by Oliver Hunt. - - DFG implementation for MIPS. - - * assembler/MIPSAssembler.h: - (JSC::MIPSAssembler::MIPSAssembler): - (JSC::MIPSAssembler::sllv): - (JSC::MIPSAssembler::movd): - (MIPSAssembler): - (JSC::MIPSAssembler::negd): - (JSC::MIPSAssembler::labelForWatchpoint): - (JSC::MIPSAssembler::label): - (JSC::MIPSAssembler::vmov): - (JSC::MIPSAssembler::linkDirectJump): - (JSC::MIPSAssembler::maxJumpReplacementSize): - (JSC::MIPSAssembler::revertJumpToMove): - (JSC::MIPSAssembler::replaceWithJump): - * assembler/MacroAssembler.h: - (MacroAssembler): - (JSC::MacroAssembler::poke): - * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::add32): - (MacroAssemblerMIPS): - (JSC::MacroAssemblerMIPS::and32): - (JSC::MacroAssemblerMIPS::lshift32): - (JSC::MacroAssemblerMIPS::mul32): - (JSC::MacroAssemblerMIPS::or32): - (JSC::MacroAssemblerMIPS::rshift32): - (JSC::MacroAssemblerMIPS::urshift32): - (JSC::MacroAssemblerMIPS::sub32): - (JSC::MacroAssemblerMIPS::xor32): - (JSC::MacroAssemblerMIPS::store32): - (JSC::MacroAssemblerMIPS::jump): - (JSC::MacroAssemblerMIPS::branchAdd32): - (JSC::MacroAssemblerMIPS::branchMul32): - (JSC::MacroAssemblerMIPS::branchSub32): - (JSC::MacroAssemblerMIPS::branchNeg32): - (JSC::MacroAssemblerMIPS::call): - (JSC::MacroAssemblerMIPS::loadDouble): - (JSC::MacroAssemblerMIPS::moveDouble): - (JSC::MacroAssemblerMIPS::swapDouble): - (JSC::MacroAssemblerMIPS::subDouble): - (JSC::MacroAssemblerMIPS::mulDouble): - (JSC::MacroAssemblerMIPS::divDouble): - (JSC::MacroAssemblerMIPS::negateDouble): - (JSC::MacroAssemblerMIPS::branchEqual): - (JSC::MacroAssemblerMIPS::branchNotEqual): - (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32): - (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32): - (JSC::MacroAssemblerMIPS::truncateDoubleToInt32): - (JSC::MacroAssemblerMIPS::truncateDoubleToUint32): - (JSC::MacroAssemblerMIPS::branchDoubleNonZero): - (JSC::MacroAssemblerMIPS::branchDoubleZeroOrNaN): - (JSC::MacroAssemblerMIPS::invert): - (JSC::MacroAssemblerMIPS::replaceWithJump): - (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): - * dfg/DFGAssemblyHelpers.h: - (AssemblyHelpers): - (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall): - (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn): - (JSC::DFG::AssemblyHelpers::debugCall): - * dfg/DFGCCallHelpers.h: - (CCallHelpers): - (JSC::DFG::CCallHelpers::setupArguments): - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - * dfg/DFGFPRInfo.h: - (DFG): - (FPRInfo): - (JSC::DFG::FPRInfo::toRegister): - (JSC::DFG::FPRInfo::toIndex): - (JSC::DFG::FPRInfo::debugName): - * dfg/DFGGPRInfo.h: - (DFG): - (GPRInfo): - (JSC::DFG::GPRInfo::toRegister): - (JSC::DFG::GPRInfo::toIndex): - (JSC::DFG::GPRInfo::debugName): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * jit/JSInterfaceJIT.h: - (JSInterfaceJIT): - * runtime/JSGlobalData.h: - (JSC::ScratchBuffer::allocationSize): - (ScratchBuffer): - -2013-02-01 Balazs Kilvady <kilvadyb@homejinni.com> - - offlineasm BaseIndex handling is broken on ARM due to MIPS changes - https://bugs.webkit.org/show_bug.cgi?id=108261 - - Reviewed by Filip Pizlo. - - offlineasm BaseIndex handling fix on MIPS. - - * offlineasm/mips.rb: - * offlineasm/risc.rb: - -2013-01-07 Balazs Kilvady <kilvadyb@homejinni.com> - - MIPS LLInt implementation. - https://bugs.webkit.org/show_bug.cgi?id=99706 - - Reviewed by Filip Pizlo. - - LLInt implementation for MIPS. - - * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::jump): - * dfg/DFGOperations.cpp: - (JSC): - * jit/JITStubs.cpp: - (JSC): - * jit/JITStubs.h: - (JITStackFrame): - * llint/LLIntOfflineAsmConfig.h: - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * offlineasm/backends.rb: - * offlineasm/instructions.rb: - * offlineasm/mips.rb: Added. - -2013-02-27 Simon Hausmann <simon.hausmann@digia.com> - - [Qt][Mac] Fix massive parallel builds - - Reviewed by Tor Arne Vestbø. - - There exists a race condition that LLIntDesiredOffsets.h is written to - by two parllel instances of the ruby script. This patch ensures that similar to the output file, - the generated file is also prefixed according to the build configuration. - - * LLIntOffsetsExtractor.pro: - -2012-12-18 Mark Hahnenberg <mhahnenberg@apple.com> - - Restrictions on oversize CopiedBlock allocations should be relaxed - https://bugs.webkit.org/show_bug.cgi?id=105339 - - Reviewed by Filip Pizlo. - - Currently the DFG has a single branch in the inline allocation path for property/array storage where - it checks to see if the number of bytes requested will fit in the current block. This does not match - what the C++ allocation path does; it checks if the requested number of bytes is oversize, and then - if it's not, it tries to fit it in the current block. The garbage collector assumes that ALL allocations - that are greater than 16KB are in oversize blocks. Therefore, this mismatch can lead to crashes when - the collector tries to perform some operation on a CopiedBlock. - - To avoid adding an extra branch to the inline allocation path in the JIT, we should make it so that - oversize blocks are allocated on the same alignment boundaries so that there is a single mask to find - the block header of any CopiedBlock (rather than two, one for normal and one for oversize blocks), and - we should figure out if a block is oversize by some other method than just whatever the JSObject says - it is. One way we could record this info Region of the block, since we allocate a one-off Region for - oversize blocks. - - * heap/BlockAllocator.h: - (JSC::Region::isCustomSize): - (Region): - (JSC::Region::createCustomSize): - (JSC::Region::Region): - (JSC::BlockAllocator::deallocateCustomSize): - * heap/CopiedBlock.h: - (CopiedBlock): - (JSC::CopiedBlock::isOversize): - (JSC): - * heap/CopiedSpace.cpp: - (JSC::CopiedSpace::tryAllocateOversize): - (JSC::CopiedSpace::tryReallocate): - (JSC::CopiedSpace::tryReallocateOversize): - * heap/CopiedSpace.h: - (CopiedSpace): - * heap/CopiedSpaceInlines.h: - (JSC::CopiedSpace::contains): - (JSC::CopiedSpace::tryAllocate): - (JSC): - * heap/CopyVisitor.h: - (CopyVisitor): - * heap/CopyVisitorInlines.h: - (JSC::CopyVisitor::checkIfShouldCopy): - (JSC::CopyVisitor::didCopy): - * heap/SlotVisitorInlines.h: - (JSC::SlotVisitor::copyLater): - * runtime/JSObject.cpp: - (JSC::JSObject::copyButterfly): - -2012-12-17 Mark Hahnenberg <mhahnenberg@apple.com> - - Butterfly::growArrayRight shouldn't be called on null Butterfly objects - https://bugs.webkit.org/show_bug.cgi?id=105221 - - Reviewed by Filip Pizlo. - - Currently we depend upon the fact that Butterfly::growArrayRight works with null Butterfly - objects purely by coincidence. We should add a new static function that null checks the old - Butterfly object and creates a new one if it's null, or calls growArrayRight if it isn't for - use in the couple of places in JSObject that expect such behavior to work. - - * runtime/Butterfly.h: - (Butterfly): - * runtime/ButterflyInlines.h: - (JSC::Butterfly::createOrGrowArrayRight): - (JSC): - * runtime/JSObject.cpp: - (JSC::JSObject::createInitialIndexedStorage): - (JSC::JSObject::createArrayStorage): - -2013-01-02 Simon Hausmann <simon.hausmann@digia.com> - - [MinGW-w64] Centralize workaround for pow() implementation - https://bugs.webkit.org/show_bug.cgi?id=105925 - - Reviewed by Sam Weinig. - - As suggested by Sam, move the MinGW-w64 workaround into MathExtras.h - away from the JSC usage. - - * runtime/MathObject.cpp: - (JSC::mathPow): - -2012-12-17 Jonathan Liu <net147@gmail.com> - - Fix Math.pow implementation with MinGW-w64 - https://bugs.webkit.org/show_bug.cgi?id=105087 - - Reviewed by Simon Hausmann. - - The MinGW-w64 runtime has different behaviour for pow() - compared to other C runtimes. This results in the following - test262 tests failing with the latest MinGW-w64 runtime: - - S15.8.2.13_A14 - - S15.8.2.13_A16 - - S15.8.2.13_A20 - - S15.8.2.13_A22 - - Handle the special cases that are different with MinGW-w64. - - * runtime/MathObject.cpp: - (JSC::mathPow): - -2012-12-07 Jonathan Liu <net147@gmail.com> - - Add missing forward declaration for JSC::ArrayAllocationProfile - https://bugs.webkit.org/show_bug.cgi?id=104425 - - Reviewed by Kentaro Hara. - - The header for the JSC::ArrayConstructor class is missing a forward - declaration for the JSC::ArrayAllocationProfile class which causes - compilation to fail when compiling with MinGW-w64. - - * runtime/ArrayConstructor.h: - (JSC): - -2012-12-07 Jonathan Liu <net147@gmail.com> - - Add missing const qualifier to JSC::CodeBlock::getJITType() - https://bugs.webkit.org/show_bug.cgi?id=104424 - - Reviewed by Laszlo Gombos. - - JSC::CodeBlock::getJITType() has the const qualifier when JIT is - enabled but is missing the const qualifier when JIT is disabled. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::getJITType): - -2012-11-30 Pierre Rossi <pierre.rossi@gmail.com> - - [Qt] Unreviewed speculative Mac build fix after r136232 - - Update the include path so that LLIntAssembly.h is picked up. - The bot didn't break until later when a clean build was triggered. - - * JavaScriptCore.pri: - -2012-11-30 Allan Sandfeld Jensen <allan.jensen@digia.com> - - Crash in conversion of empty OpaqueJSString to Identifier - https://bugs.webkit.org/show_bug.cgi?id=101867 - - Reviewed by NOBODY (OOPS!). - - The constructor call used for both null and empty OpaqueJSStrings results - in an assertion voilation and crash. This patch instead uses the Identifier - constructors which are specifically for null and empty Identifier. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::identifier): - -2012-11-30 Tor Arne Vestbø <tor.arne.vestbo@digia.com> - - [Qt] Place the LLIntOffsetsExtractor binaries in debug/release subdirs on Mac - - Otherwise we'll end up using the same LLIntAssembly.h for both build - configs of JavaScriptCore -- one of them which will be for the wrong - config. - - Reviewed by Simon Hausmann. - - * LLIntOffsetsExtractor.pro: - -2012-11-30 Julien BRIANCEAU <jbrianceau@nds.com> - - [sh4] Fix compilation warnings in JavaScriptCore JIT for sh4 arch - https://bugs.webkit.org/show_bug.cgi?id=103378 - - Reviewed by Filip Pizlo. - - * assembler/MacroAssemblerSH4.h: - (JSC::MacroAssemblerSH4::branchTest32): - (JSC::MacroAssemblerSH4::branchAdd32): - (JSC::MacroAssemblerSH4::branchMul32): - (JSC::MacroAssemblerSH4::branchSub32): - (JSC::MacroAssemblerSH4::branchOr32): - -2012-11-29 Rafael Weinstein <rafaelw@chromium.org> - - [HTMLTemplateElement] Add feature flag - https://bugs.webkit.org/show_bug.cgi?id=103694 - - Reviewed by Adam Barth. - - This flag will guard the implementation of the HTMLTemplateElement. - http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html - - * Configurations/FeatureDefines.xcconfig: - -2012-11-29 Filip Pizlo <fpizlo@apple.com> - - It should be easy to find code blocks in debug dumps - https://bugs.webkit.org/show_bug.cgi?id=103623 - - Reviewed by Goeffrey Garen. - - This gives CodeBlock a relatively strong, but also relatively compact, hash. We compute - it lazily so that it only impacts run-time when debug support is enabled. We stringify - it smartly so that it's short and easy to type. We base it on the source code so that - the optimization level is irrelevant. And, we use SHA1 since it's already in our code - base. Now, when a piece of code wants to print some debugging to say that it's operating - on some code block, it can use this CodeBlockHash instead of memory addresses. - - This also takes CodeBlock debugging into the new world of print() and dataLog(). In - particular, CodeBlock::dump() corresponds to the thing you want printed if you do: - - dataLog("I heart ", *myCodeBlock); - - Probably, you want to just print some identifying information at this point rather than - the full bytecode dump. So, the existing CodeBlock::dump() has been renamed to - CodeBlock::dumpBytecode(), and CodeBlock::dump() now prints the CodeBlockHash plus just - a few little tidbits. - - Here's an example of CodeBlock::dump() output: - - EkILzr:[0x103883a00, BaselineFunctionCall] - - EkILzr is the CodeBlockHash. 0x103883a00 is the CodeBlock's address in memory. The other - part is self-explanatory. - - Finally, this new notion of CodeBlockHash is available for other purposes like bisecting - breakage. As such CodeBlockHash has all of the comparison operator overloads. When - bisecting in DFGDriver.cpp, you can now say things like: - - if (codeBlock->hash() < CodeBlockHash("CAAAAA")) - return false; - - And yes, CAAAAA is near the median hash, and the largest one is smaller than E99999. Such - is life when you use base 62 to encode a 32-bit number. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/CallLinkInfo.h: - (CallLinkInfo): - (JSC::CallLinkInfo::specializationKind): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::hash): - (JSC): - (JSC::CodeBlock::dumpAssumingJITType): - (JSC::CodeBlock::dump): - (JSC::CodeBlock::dumpBytecode): - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::resetStubInternal): - (JSC::CodeBlock::reoptimize): - (JSC::ProgramCodeBlock::jettison): - (JSC::EvalCodeBlock::jettison): - (JSC::FunctionCodeBlock::jettison): - (JSC::CodeBlock::shouldOptimizeNow): - (JSC::CodeBlock::tallyFrequentExitSites): - (JSC::CodeBlock::dumpValueProfiles): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::specializationKind): - (CodeBlock): - (JSC::CodeBlock::getJITType): - * bytecode/CodeBlockHash.cpp: Added. - (JSC): - (JSC::CodeBlockHash::CodeBlockHash): - (JSC::CodeBlockHash::dump): - * bytecode/CodeBlockHash.h: Added. - (JSC): - (CodeBlockHash): - (JSC::CodeBlockHash::CodeBlockHash): - (JSC::CodeBlockHash::hash): - (JSC::CodeBlockHash::operator==): - (JSC::CodeBlockHash::operator!=): - (JSC::CodeBlockHash::operator<): - (JSC::CodeBlockHash::operator>): - (JSC::CodeBlockHash::operator<=): - (JSC::CodeBlockHash::operator>=): - * bytecode/CodeBlockWithJITType.h: Added. - (JSC): - (CodeBlockWithJITType): - (JSC::CodeBlockWithJITType::CodeBlockWithJITType): - (JSC::CodeBlockWithJITType::dump): - * bytecode/CodeOrigin.cpp: Added. - (JSC): - (JSC::CodeOrigin::inlineDepthForCallFrame): - (JSC::CodeOrigin::inlineDepth): - (JSC::CodeOrigin::inlineStack): - (JSC::InlineCallFrame::hash): - * bytecode/CodeOrigin.h: - (InlineCallFrame): - (JSC::InlineCallFrame::specializationKind): - (JSC): - * bytecode/CodeType.cpp: Added. - (WTF): - (WTF::printInternal): - * bytecode/CodeType.h: - (WTF): - * bytecode/ExecutionCounter.cpp: - (JSC::ExecutionCounter::dump): - * bytecode/ExecutionCounter.h: - (ExecutionCounter): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseCodeBlock): - * dfg/DFGDisassembler.cpp: - (JSC::DFG::Disassembler::dump): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dumpCodeOrigin): - * dfg/DFGOSRExitCompiler.cpp: - * dfg/DFGOperations.cpp: - * dfg/DFGRepatch.cpp: - (JSC::DFG::generateProtoChainAccessStub): - (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDList): - (JSC::DFG::emitPutReplaceStub): - (JSC::DFG::emitPutTransitionStub): - (JSC::DFG::dfgLinkClosureCall): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::dumpCallFrame): - * jit/JITCode.cpp: Added. - (WTF): - (WTF::printInternal): - * jit/JITCode.h: - (JSC::JITCode::jitType): - (WTF): - * jit/JITDisassembler.cpp: - (JSC::JITDisassembler::dump): - (JSC::JITDisassembler::dumpForInstructions): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompilePutByIdTransition): - (JSC::JIT::privateCompilePatchGetArrayLength): - (JSC::JIT::privateCompileGetByIdProto): - (JSC::JIT::privateCompileGetByIdSelfList): - (JSC::JIT::privateCompileGetByIdProtoList): - (JSC::JIT::privateCompileGetByIdChainList): - (JSC::JIT::privateCompileGetByIdChain): - (JSC::JIT::privateCompileGetByVal): - (JSC::JIT::privateCompilePutByVal): - * 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/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * runtime/CodeSpecializationKind.cpp: Added. - (WTF): - (WTF::printInternal): - * runtime/CodeSpecializationKind.h: - (JSC::specializationFromIsCall): - (JSC): - (JSC::specializationFromIsConstruct): - (WTF): - * runtime/Executable.cpp: - (JSC::ExecutableBase::hashFor): - (JSC): - (JSC::NativeExecutable::hashFor): - (JSC::ScriptExecutable::hashFor): - * runtime/Executable.h: - (ExecutableBase): - (NativeExecutable): - (ScriptExecutable): - (JSC::ScriptExecutable::source): - -2012-11-29 Michael Saboff <msaboff@apple.com> - - Speculative Windows build fix after r136086. - - Unreviewed build fix. - - Suspect that ?setDumpsGeneratedCode@BytecodeGenerator@JSC@@SAX_N@Z needs to be removed from Windows - export list since the symbol was removed in r136086. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-11-28 Filip Pizlo <fpizlo@apple.com> - - SpeculatedType dumping should not use the static char buffer[thingy] idiom - https://bugs.webkit.org/show_bug.cgi?id=103584 - - Reviewed by Michael Saboff. - - Changed SpeculatedType to be "dumpable" by saying things like: - - dataLog("thingy = ", SpeculationDump(thingy)) - - Removed the old stringification functions, and changed all code that referred to them - to use the new dataLog()/print() style. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/SpeculatedType.cpp: - (JSC::dumpSpeculation): - (JSC::speculationToAbbreviatedString): - (JSC::dumpSpeculationAbbreviated): - * bytecode/SpeculatedType.h: - * bytecode/ValueProfile.h: - (JSC::ValueProfileBase::dump): - * bytecode/VirtualRegister.h: - (WTF::printInternal): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::dump): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): - (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - (JSC::DFG::Graph::predictArgumentTypes): - * dfg/DFGGraph.h: - (Graph): - * dfg/DFGStructureAbstractValue.h: - * dfg/DFGVariableAccessDataDump.cpp: Added. - (JSC::DFG::VariableAccessDataDump::VariableAccessDataDump): - (JSC::DFG::VariableAccessDataDump::dump): - * dfg/DFGVariableAccessDataDump.h: Added. - (VariableAccessDataDump): - -2012-11-28 Michael Saboff <msaboff@apple.com> - - Change Bytecompiler s_dumpsGeneratedCode to an Options value - https://bugs.webkit.org/show_bug.cgi?id=103588 - - Reviewed by Filip Pizlo. - - Moved the control of dumping bytecodes to Options::dumpGeneratedBytecodes. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecompiler/BytecodeGenerator.cpp: - * bytecompiler/BytecodeGenerator.h: - * jsc.cpp: - (runWithScripts): - * runtime/Options.h: - -2012-11-28 Mark Hahnenberg <mhahnenberg@apple.com> - - Copying phase should use work lists - https://bugs.webkit.org/show_bug.cgi?id=101390 - - Reviewed by Filip Pizlo. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * heap/BlockAllocator.cpp: - (JSC::BlockAllocator::BlockAllocator): - * heap/BlockAllocator.h: New RegionSet for CopyWorkListSegments. - (BlockAllocator): - (JSC::CopyWorkListSegment): - * heap/CopiedBlock.h: Added a per-block CopyWorkList to keep track of the JSCells that need to be revisited during the copying - phase to copy their backing stores. - (CopiedBlock): - (JSC::CopiedBlock::CopiedBlock): - (JSC::CopiedBlock::didSurviveGC): - (JSC::CopiedBlock::didEvacuateBytes): There is now a one-to-one relationship between GCThreads and the CopiedBlocks they're - responsible for evacuating, we no longer need any of that fancy compare and swap stuff. - (JSC::CopiedBlock::pin): - (JSC::CopiedBlock::hasWorkList): - (JSC::CopiedBlock::workList): - * heap/CopiedBlockInlines.h: Added. - (JSC::CopiedBlock::reportLiveBytes): Since we now have to grab a SpinLock to perform operations on the CopyWorkList during marking, - we don't need to do any of that fancy compare and swap stuff we were doing for tracking live bytes. - * heap/CopiedSpace.h: - (CopiedSpace): - * heap/CopiedSpaceInlines.h: - (JSC::CopiedSpace::pin): - * heap/CopyVisitor.cpp: - (JSC::CopyVisitor::copyFromShared): We now iterate over a range of CopiedBlocks rather than MarkedBlocks and revisit the cells in those - blocks' CopyWorkLists. - * heap/CopyVisitor.h: - (CopyVisitor): - * heap/CopyVisitorInlines.h: - (JSC::CopyVisitor::visitCell): The function responsible for calling the correct copyBackingStore() function for each JSCell from - a CopiedBlock's CopyWorkList. - (JSC::CopyVisitor::didCopy): We no longer need to check if the block is empty here because we know exactly when we're done - evacuating a CopiedBlock, which is when we've gone through all of the CopiedBlock's CopyWorkList. - * heap/CopyWorkList.h: Added. - (CopyWorkListSegment): Individual chunk of a CopyWorkList that is allocated from the BlockAllocator. - (JSC::CopyWorkListSegment::create): - (JSC::CopyWorkListSegment::size): - (JSC::CopyWorkListSegment::isFull): - (JSC::CopyWorkListSegment::get): - (JSC::CopyWorkListSegment::append): - (JSC::CopyWorkListSegment::CopyWorkListSegment): - (JSC::CopyWorkListSegment::data): - (JSC::CopyWorkListSegment::endOfBlock): - (CopyWorkListIterator): Responsible for giving CopyVisitors a contiguous notion of access across the separate CopyWorkListSegments - that make up each CopyWorkList. - (JSC::CopyWorkListIterator::get): - (JSC::CopyWorkListIterator::operator*): - (JSC::CopyWorkListIterator::operator->): - (JSC::CopyWorkListIterator::operator++): - (JSC::CopyWorkListIterator::operator==): - (JSC::CopyWorkListIterator::operator!=): - (JSC::CopyWorkListIterator::CopyWorkListIterator): - (CopyWorkList): Data structure that keeps track of the JSCells that need copying in a particular CopiedBlock. - (JSC::CopyWorkList::CopyWorkList): - (JSC::CopyWorkList::~CopyWorkList): - (JSC::CopyWorkList::append): - (JSC::CopyWorkList::begin): - (JSC::CopyWorkList::end): - * heap/GCThreadSharedData.cpp: - (JSC::GCThreadSharedData::GCThreadSharedData): We no longer use the m_blockSnapshot from the Heap during the copying phase. - (JSC::GCThreadSharedData::didStartCopying): We now copy the set of all blocks in the CopiedSpace to a separate vector for - iterating over during the copying phase since the set stored in the CopiedSpace will change as blocks are evacuated and - recycled throughout the copying phase. - * heap/GCThreadSharedData.h: - (GCThreadSharedData): - * heap/Heap.h: - (Heap): - * heap/SlotVisitor.h: We now need to know the object who is being marked that has a backing store so that we can store it - in a CopyWorkList to revisit later during the copying phase. - * heap/SlotVisitorInlines.h: - (JSC::SlotVisitor::copyLater): - * runtime/JSObject.cpp: - (JSC::JSObject::visitButterfly): - -2012-11-28 Filip Pizlo <fpizlo@apple.com> - - Disassembly methods should be able to disassemble to any PrintStream& rather than always using WTF::dataFile() - https://bugs.webkit.org/show_bug.cgi?id=103492 - - Reviewed by Mark Hahnenberg. - - Switched disassembly code to use PrintStream&, and to use print() rather than printf(). - - * dfg/DFGDisassembler.cpp: - (JSC::DFG::Disassembler::dump): - (DFG): - (JSC::DFG::Disassembler::dumpDisassembly): - * dfg/DFGDisassembler.h: - (Disassembler): - * dfg/DFGGraph.cpp: - (JSC::DFG::printWhiteSpace): - (JSC::DFG::Graph::dumpCodeOrigin): - (JSC::DFG::Graph::printNodeWhiteSpace): - (JSC::DFG::Graph::dump): - (DFG): - (JSC::DFG::Graph::dumpBlockHeader): - * dfg/DFGGraph.h: - (Graph): - * jit/JITDisassembler.cpp: - (JSC::JITDisassembler::dump): - (JSC::JITDisassembler::dumpForInstructions): - (JSC::JITDisassembler::dumpDisassembly): - * jit/JITDisassembler.h: - (JITDisassembler): - -2012-11-28 Filip Pizlo <fpizlo@apple.com> - - It should be possible to say dataLog("count = ", count, "\n") instead of dataLogF("count = %d\n", count) - https://bugs.webkit.org/show_bug.cgi?id=103009 - - Reviewed by Michael Saboff. - - Instead of converting all of JSC to use the new dataLog()/print() methods, I just changed - one place: dumping of abstract values. This is mainly just to ensure that the code I - added to WTF is actually doing things. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::dump): - (WTF): - (WTF::printInternal): - * dfg/DFGStructureAbstractValue.h: - (JSC::DFG::StructureAbstractValue::dump): - (WTF): - (WTF::printInternal): - -2012-11-28 Oliver Hunt <oliver@apple.com> - - Make source cache include more information about the function extent. - https://bugs.webkit.org/show_bug.cgi?id=103552 - - Reviewed by Gavin Barraclough. - - Add a bit more information to the source cache. - - * parser/Parser.cpp: - (JSC::::parseFunctionInfo): - Store the function start offset - * parser/SourceProviderCacheItem.h: - (JSC::SourceProviderCacheItem::SourceProviderCacheItem): - (SourceProviderCacheItem): - Add additional field for the start of the real function string, and re-arrange - fields to avoid growing the struct. - -2012-11-27 Filip Pizlo <fpizlo@apple.com> - - Convert some remaining uses of FILE* to PrintStream&. - - Rubber stamped by Mark Hahnenberg. - - * bytecode/ValueProfile.h: - (JSC::ValueProfileBase::dump): - * bytecode/ValueRecovery.h: - (JSC::ValueRecovery::dump): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseCodeBlock): - * dfg/DFGNode.h: - (JSC::DFG::Node::dumpChildren): - -2012-11-27 Filip Pizlo <fpizlo@apple.com> - - Fix indentation in JSValue.h - - Rubber stamped by Mark Hahnenberg. - - * runtime/JSValue.h: - -2012-11-26 Filip Pizlo <fpizlo@apple.com> - - DFG SetLocal should use forwardSpeculationCheck instead of its own half-baked version of same - https://bugs.webkit.org/show_bug.cgi?id=103353 - - Reviewed by Oliver Hunt and Gavin Barraclough. - - Made it possible to use forward speculations for most of the operand classes. Changed the conditional - direction parameter from being 'bool isForward' to an enum (SpeculationDirection). Changed SetLocal - to use forward speculations and got rid of its half-baked version of same. - - Also added the ability to force the DFG's disassembler to dump all nodes, even ones that are dead. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGDisassembler.cpp: - (JSC::DFG::Disassembler::dump): - * dfg/DFGDriver.cpp: - (JSC::DFG::compile): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::speculationCheck): - (DFG): - (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): - (JSC::DFG::SpeculativeJIT::speculationWatchpoint): - (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): - (JSC::DFG::SpeculativeJIT::fillStorage): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand): - (JSC::DFG::SpeculateIntegerOperand::gpr): - (SpeculateIntegerOperand): - (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): - (JSC::DFG::SpeculateDoubleOperand::fpr): - (SpeculateDoubleOperand): - (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): - (JSC::DFG::SpeculateCellOperand::gpr): - (SpeculateCellOperand): - (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand): - (JSC::DFG::SpeculateBooleanOperand::gpr): - (SpeculateBooleanOperand): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): - (JSC::DFG::SpeculativeJIT::fillSpeculateInt): - (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): - (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::fillSpeculateInt): - (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): - (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): - (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): - (JSC::DFG::SpeculativeJIT::compile): - * runtime/Options.h: - (JSC): - -2012-11-26 Daniel Bates <dbates@webkit.org> - - Substitute "allSeparators8Bit" for "allSeperators8Bit" in JSC::jsSpliceSubstringsWithSeparators() - <https://bugs.webkit.org/show_bug.cgi?id=103303> - - Reviewed by Simon Fraser. - - Fix misspelled word, "Seperators" [sic], in a local variable name in JSC::jsSpliceSubstringsWithSeparators(). - - * runtime/StringPrototype.cpp: - (JSC::jsSpliceSubstringsWithSeparators): - -2012-11-26 Daniel Bates <dbates@webkit.org> - - JavaScript fails to handle String.replace() with large replacement string - https://bugs.webkit.org/show_bug.cgi?id=102956 - <rdar://problem/12738012> - - Reviewed by Oliver Hunt. - - Fix an issue where we didn't check for overflow when computing the length - of the result of String.replace() with a large replacement string. - - * runtime/StringPrototype.cpp: - (JSC::jsSpliceSubstringsWithSeparators): - -2012-11-26 Zeno Albisser <zeno@webkit.org> - - [Qt] Fix the LLInt build on Mac - https://bugs.webkit.org/show_bug.cgi?id=97587 - - Reviewed by Simon Hausmann. - - * DerivedSources.pri: - * JavaScriptCore.pro: - -2012-11-26 Oliver Hunt <oliver@apple.com> - - 32-bit build fix. Move the method decalration outside of the X86_64 only section. - - * assembler/MacroAssembler.h: - (MacroAssembler): - (JSC::MacroAssembler::shouldConsiderBlinding): - -2012-11-26 Oliver Hunt <oliver@apple.com> - - Don't blind all the things. - https://bugs.webkit.org/show_bug.cgi?id=102572 - - Reviewed by Gavin Barraclough. - - No longer blind all the constants in the instruction stream. We use a - simple non-deterministic filter to avoid blinding everything. Also modified - the basic integer blinding logic to avoid blinding small negative values. - - * assembler/MacroAssembler.h: - (MacroAssembler): - (JSC::MacroAssembler::shouldConsiderBlinding): - (JSC::MacroAssembler::shouldBlind): - -2012-11-26 Mark Hahnenberg <mhahnenberg@apple.com> - - JSObject::copyButterfly doesn't handle undecided indexing types correctly - https://bugs.webkit.org/show_bug.cgi?id=102573 - - Reviewed by Filip Pizlo. - - We don't do any copying into the newly allocated vector and we don't zero-initialize CopiedBlocks - during the copying phase, so we end up with uninitialized memory in arrays which have undecided indexing - types. We should just do the actual memcpy from the old block to the new one. - - * runtime/JSObject.cpp: - (JSC::JSObject::copyButterfly): Just do the same thing that we do for other contiguous indexing types. - -2012-11-26 Julien BRIANCEAU <jbrianceau@nds.com> - - [sh4] JavaScriptCore JIT build is broken since r135330 - Add missing implementation for sh4 arch. - https://bugs.webkit.org/show_bug.cgi?id=103145 - - Reviewed by Oliver Hunt. - - * assembler/MacroAssemblerSH4.h: - (JSC::MacroAssemblerSH4::canJumpReplacePatchableBranchPtrWithPatch): - (MacroAssemblerSH4): - (JSC::MacroAssemblerSH4::startOfBranchPtrWithPatchOnRegister): - (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch): - (JSC::MacroAssemblerSH4::startOfPatchableBranchPtrWithPatchOnAddress): - (JSC::MacroAssemblerSH4::revertJumpReplacementToPatchableBranchPtrWithPatch): - * assembler/SH4Assembler.h: - (JSC::SH4Assembler::revertJump): - (SH4Assembler): - (JSC::SH4Assembler::printInstr): - -2012-11-26 Yuqiang Xian <yuqiang.xian@intel.com> - - Use load64 instead of loadPtr to load a JSValue on JSVALUE64 platforms - https://bugs.webkit.org/show_bug.cgi?id=100909 - - Reviewed by Brent Fulgham. - - This is a (trivial) fix after r132701. - - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - -2012-11-26 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - [Qt][ARM] REGRESSION(r130826): It made 33 JSC test and 466 layout tests crash - https://bugs.webkit.org/show_bug.cgi?id=98857 - - Reviewed by Zoltan Herczeg. - - Implement a new version of patchableBranch32 to fix crashing JSC - tests. - - * assembler/MacroAssembler.h: - (MacroAssembler): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::patchableBranch32): - (MacroAssemblerARM): - -2012-11-21 Filip Pizlo <fpizlo@apple.com> - - Any function that can log things should be able to easily log them to a memory buffer as well - https://bugs.webkit.org/show_bug.cgi?id=103000 - - Reviewed by Sam Weinig. - - Change all users of WTF::dataFile() to expect a PrintStream& rather than a FILE*. - - * bytecode/Operands.h: - (JSC::OperandValueTraits::dump): - (JSC::dumpOperands): - (JSC): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::dump): - * dfg/DFGAbstractState.h: - (AbstractState): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::dump): - * dfg/DFGCommon.h: - (JSC::DFG::NodeIndexTraits::dump): - * dfg/DFGStructureAbstractValue.h: - (JSC::DFG::StructureAbstractValue::dump): - * dfg/DFGVariableEvent.cpp: - (JSC::DFG::VariableEvent::dump): - (JSC::DFG::VariableEvent::dumpFillInfo): - (JSC::DFG::VariableEvent::dumpSpillInfo): - * dfg/DFGVariableEvent.h: - (VariableEvent): - * disassembler/Disassembler.h: - (JSC): - (JSC::tryToDisassemble): - * disassembler/UDis86Disassembler.cpp: - (JSC::tryToDisassemble): - -2012-11-23 Alexis Menard <alexis@webkit.org> - - [CSS3 Backgrounds and Borders] Implement new CSS3 background-position parsing. - https://bugs.webkit.org/show_bug.cgi?id=102104 - - Reviewed by Julien Chaffraix. - - Protect the new feature behind a feature flag. - - * Configurations/FeatureDefines.xcconfig: - -2012-11-23 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - Fix the ARM traditional build after r135330 - https://bugs.webkit.org/show_bug.cgi?id=102871 - - Reviewed by Zoltan Herczeg. - - Added missing functionality to traditional ARM architecture. - - * assembler/ARMAssembler.h: - (JSC::ARMAssembler::revertJump): - (ARMAssembler): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatchOnAddress): - (JSC::MacroAssemblerARM::startOfBranchPtrWithPatchOnRegister): - (MacroAssemblerARM): - (JSC::MacroAssemblerARM::revertJumpReplacementToBranchPtrWithPatch): - -2012-11-16 Yury Semikhatsky <yurys@chromium.org> - - Memory instrumentation: extract MemoryObjectInfo declaration into a separate file - https://bugs.webkit.org/show_bug.cgi?id=102510 - - Reviewed by Pavel Feldman. - - Added new symbols for the methods that have moved into .../wtf/MemoryInstrumentation.cpp - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-11-23 Julien BRIANCEAU <jbrianceau@nds.com> - - [sh4] JavaScriptCore JIT build is broken since r130839 - Add missing implementation for sh4 arch. - https://bugs.webkit.org/show_bug.cgi?id=101479 - - Reviewed by Filip Pizlo. - - * assembler/MacroAssemblerSH4.h: - (JSC::MacroAssemblerSH4::load8Signed): - (MacroAssemblerSH4): - (JSC::MacroAssemblerSH4::load16Signed): - (JSC::MacroAssemblerSH4::store8): - (JSC::MacroAssemblerSH4::store16): - (JSC::MacroAssemblerSH4::moveDoubleToInts): - (JSC::MacroAssemblerSH4::moveIntsToDouble): - (JSC::MacroAssemblerSH4::loadFloat): - (JSC::MacroAssemblerSH4::loadDouble): - (JSC::MacroAssemblerSH4::storeFloat): - (JSC::MacroAssemblerSH4::storeDouble): - (JSC::MacroAssemblerSH4::addDouble): - (JSC::MacroAssemblerSH4::convertFloatToDouble): - (JSC::MacroAssemblerSH4::convertDoubleToFloat): - (JSC::MacroAssemblerSH4::urshift32): - * assembler/SH4Assembler.h: - (JSC::SH4Assembler::sublRegReg): - (JSC::SH4Assembler::subvlRegReg): - (JSC::SH4Assembler::floatfpulfrn): - (JSC::SH4Assembler::fldsfpul): - (JSC::SH4Assembler::fstsfpul): - (JSC::SH4Assembler::dcnvsd): - (SH4Assembler): - (JSC::SH4Assembler::movbRegMem): - (JSC::SH4Assembler::sizeOfConstantPool): - (JSC::SH4Assembler::linkJump): - (JSC::SH4Assembler::printInstr): - (JSC::SH4Assembler::printBlockInstr): - -2012-11-22 Balazs Kilvady <kilvadyb@homejinni.com> - - Fix the MIPS build after r135330 - https://bugs.webkit.org/show_bug.cgi?id=102872 - - Reviewed by Gavin Barraclough. - - Revert/replace functions added to MIPS port. - - * assembler/MIPSAssembler.h: - (JSC::MIPSAssembler::revertJumpToMove): - (MIPSAssembler): - (JSC::MIPSAssembler::replaceWithJump): - * assembler/MacroAssemblerMIPS.h: - (MacroAssemblerMIPS): - (JSC::MacroAssemblerMIPS::startOfBranchPtrWithPatchOnRegister): - (JSC::MacroAssemblerMIPS::revertJumpReplacementToBranchPtrWithPatch): - (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatchOnAddress): - -2012-11-21 Filip Pizlo <fpizlo@apple.com> - - Rename dataLog() and dataLogV() to dataLogF() and dataLogFV() - https://bugs.webkit.org/show_bug.cgi?id=103001 - - Rubber stamped by Dan Bernstein. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * assembler/LinkBuffer.cpp: - (JSC::LinkBuffer::finalizeCodeWithDisassembly): - (JSC::LinkBuffer::dumpLinkStatistics): - (JSC::LinkBuffer::dumpCode): - * assembler/LinkBuffer.h: - (JSC): - * assembler/SH4Assembler.h: - (JSC::SH4Assembler::vprintfStdoutInstr): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): - (JSC::CodeBlock::printUnaryOp): - (JSC::CodeBlock::printBinaryOp): - (JSC::CodeBlock::printConditionalJump): - (JSC::CodeBlock::printGetByIdOp): - (JSC::dumpStructure): - (JSC::dumpChain): - (JSC::CodeBlock::printGetByIdCacheStatus): - (JSC::CodeBlock::printCallOp): - (JSC::CodeBlock::printPutByIdOp): - (JSC::CodeBlock::printStructure): - (JSC::CodeBlock::printStructures): - (JSC::CodeBlock::dump): - (JSC::CodeBlock::dumpStatistics): - (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::resetStubInternal): - (JSC::CodeBlock::reoptimize): - (JSC::ProgramCodeBlock::jettison): - (JSC::EvalCodeBlock::jettison): - (JSC::FunctionCodeBlock::jettison): - (JSC::CodeBlock::shouldOptimizeNow): - (JSC::CodeBlock::tallyFrequentExitSites): - (JSC::CodeBlock::dumpValueProfiles): - * bytecode/Opcode.cpp: - (JSC::OpcodeStats::~OpcodeStats): - * bytecode/SamplingTool.cpp: - (JSC::SamplingFlags::stop): - (JSC::SamplingRegion::dumpInternal): - (JSC::SamplingTool::dump): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::initialize): - (JSC::DFG::AbstractState::endBasicBlock): - (JSC::DFG::AbstractState::mergeStateAtTail): - (JSC::DFG::AbstractState::mergeToSuccessors): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::dump): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): - (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): - (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): - (JSC::DFG::ByteCodeParser::makeSafe): - (JSC::DFG::ByteCodeParser::makeDivSafe): - (JSC::DFG::ByteCodeParser::handleCall): - (JSC::DFG::ByteCodeParser::handleInlining): - (JSC::DFG::ByteCodeParser::parseBlock): - (JSC::DFG::ByteCodeParser::processPhiStack): - (JSC::DFG::ByteCodeParser::linkBlock): - (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): - (JSC::DFG::ByteCodeParser::parseCodeBlock): - (JSC::DFG::ByteCodeParser::parse): - * dfg/DFGCFAPhase.cpp: - (JSC::DFG::CFAPhase::performBlockCFA): - (JSC::DFG::CFAPhase::performForwardCFA): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): - (JSC::DFG::CFGSimplificationPhase::fixPhis): - (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): - (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): - (JSC::DFG::CFGSimplificationPhase::mergeBlocks): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::endIndexForPureCSE): - (JSC::DFG::CSEPhase::setReplacement): - (JSC::DFG::CSEPhase::eliminate): - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGCapabilities.cpp: - (JSC::DFG::debugFail): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): - * dfg/DFGDisassembler.cpp: - (JSC::DFG::Disassembler::dump): - * dfg/DFGDriver.cpp: - (JSC::DFG::compile): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::fixDoubleEdge): - * dfg/DFGGraph.cpp: - (JSC::DFG::printWhiteSpace): - (JSC::DFG::Graph::dumpCodeOrigin): - (JSC::DFG::Graph::dump): - (JSC::DFG::Graph::dumpBlockHeader): - (JSC::DFG::Graph::predictArgumentTypes): - * dfg/DFGJITCompiler.cpp: - (JSC::DFG::JITCompiler::link): - * dfg/DFGOSREntry.cpp: - (JSC::DFG::prepareOSREntry): - * dfg/DFGOSRExitCompiler.cpp: - * dfg/DFGOSRExitCompiler32_64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGOperations.cpp: - * dfg/DFGPhase.cpp: - (JSC::DFG::Phase::beginPhase): - * dfg/DFGPhase.h: - (JSC::DFG::runAndLog): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - (JSC::DFG::PredictionPropagationPhase::propagateForward): - (JSC::DFG::PredictionPropagationPhase::propagateBackward): - (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): - * dfg/DFGRegisterBank.h: - (JSC::DFG::RegisterBank::dump): - * dfg/DFGScoreBoard.h: - (JSC::DFG::ScoreBoard::use): - (JSC::DFG::ScoreBoard::dump): - * dfg/DFGSlowPathGenerator.h: - (JSC::DFG::SlowPathGenerator::generate): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): - (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): - (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): - (JSC::DFG::SpeculativeJIT::dump): - (JSC::DFG::SpeculativeJIT::checkConsistency): - (JSC::DFG::SpeculativeJIT::compile): - (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): - (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): - (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): - (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): - (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - * dfg/DFGValidate.cpp: - (Validate): - (JSC::DFG::Validate::reportValidationContext): - (JSC::DFG::Validate::dumpData): - (JSC::DFG::Validate::dumpGraphIfAppropriate): - * dfg/DFGVariableEventStream.cpp: - (JSC::DFG::VariableEventStream::logEvent): - (JSC::DFG::VariableEventStream::reconstruct): - * dfg/DFGVirtualRegisterAllocationPhase.cpp: - (JSC::DFG::VirtualRegisterAllocationPhase::run): - * heap/Heap.cpp: - * heap/HeapStatistics.cpp: - (JSC::HeapStatistics::logStatistics): - (JSC::HeapStatistics::showObjectStatistics): - * heap/MarkStack.h: - * heap/MarkedBlock.h: - * heap/SlotVisitor.cpp: - (JSC::SlotVisitor::validate): - * interpreter/CallFrame.cpp: - (JSC::CallFrame::dumpCaller): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::dumpRegisters): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - (JSC::JIT::privateCompileSlowCases): - (JSC::JIT::privateCompile): - * jit/JITDisassembler.cpp: - (JSC::JITDisassembler::dump): - (JSC::JITDisassembler::dumpForInstructions): - * jit/JITStubRoutine.h: - (JSC): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * jit/JumpReplacementWatchpoint.cpp: - (JSC::JumpReplacementWatchpoint::fireInternal): - * llint/LLIntExceptions.cpp: - (JSC::LLInt::interpreterThrowInCaller): - (JSC::LLInt::returnToThrow): - (JSC::LLInt::callToThrow): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::llint_trace_operand): - (JSC::LLInt::llint_trace_value): - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - (JSC::LLInt::traceFunctionPrologue): - (JSC::LLInt::jitCompileAndSetHeuristics): - (JSC::LLInt::entryOSR): - (JSC::LLInt::handleHostCall): - (JSC::LLInt::setUpCall): - * profiler/Profile.cpp: - (JSC::Profile::debugPrintData): - (JSC::Profile::debugPrintDataSampleStyle): - * profiler/ProfileNode.cpp: - (JSC::ProfileNode::debugPrintData): - (JSC::ProfileNode::debugPrintDataSampleStyle): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::dumpRegExpTrace): - * runtime/RegExp.cpp: - (JSC::RegExp::matchCompareWithInterpreter): - * runtime/SamplingCounter.cpp: - (JSC::AbstractSamplingCounter::dump): - * runtime/Structure.cpp: - (JSC::Structure::dumpStatistics): - (JSC::PropertyMapStatisticsExitLogger::~PropertyMapStatisticsExitLogger): - * tools/CodeProfile.cpp: - (JSC::CodeProfile::report): - * tools/ProfileTreeNode.h: - (JSC::ProfileTreeNode::dumpInternal): - * yarr/YarrInterpreter.cpp: - (JSC::Yarr::ByteCompiler::dumpDisjunction): - -2012-11-21 Filip Pizlo <fpizlo@apple.com> - - It should be possible to say disassemble(stuff) instead of having to say if (!tryToDisassemble(stuff)) dataLog("I failed") - https://bugs.webkit.org/show_bug.cgi?id=103010 - - Reviewed by Anders Carlsson. - - You can still say tryToDisassemble(), which will tell you if it failed; you can then - decide what to do instead. But it's better to say disassemble(), which will just print - the instruction ranges if tryToDisassemble() failed. This is particularly appropriate - since that's what all previous users of tryToDisassemble() would have done in some - form or another. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * assembler/LinkBuffer.cpp: - (JSC::LinkBuffer::finalizeCodeWithDisassembly): - * dfg/DFGDisassembler.cpp: - (JSC::DFG::Disassembler::dumpDisassembly): - * disassembler/Disassembler.cpp: Added. - (JSC): - (JSC::disassemble): - * disassembler/Disassembler.h: - (JSC): - * jit/JITDisassembler.cpp: - (JSC::JITDisassembler::dumpDisassembly): - -2012-11-21 Filip Pizlo <fpizlo@apple.com> - - dumpOperands() claims that it needs a non-const Operands& when that is completely false - https://bugs.webkit.org/show_bug.cgi?id=103005 - - Reviewed by Eric Carlson. - - * bytecode/Operands.h: - (JSC::dumpOperands): - (JSC): - -2012-11-20 Filip Pizlo <fpizlo@apple.com> - - Baseline JIT's disassembly should be just as pretty as the DFG's - https://bugs.webkit.org/show_bug.cgi?id=102873 - - Reviewed by Sam Weinig. - - Integrated the CodeBlock's bytecode dumper with the JIT's disassembler. Also fixed - some type goof-ups (instructions are not in a Vector<Instruction> so using a Vector - iterator makes no sense) and stream-lined some things (you don't actually need a - full-fledged ExecState* to dump bytecode). - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::printUnaryOp): - (JSC::CodeBlock::printBinaryOp): - (JSC::CodeBlock::printConditionalJump): - (JSC::CodeBlock::printGetByIdOp): - (JSC::CodeBlock::printCallOp): - (JSC::CodeBlock::printPutByIdOp): - (JSC::CodeBlock::dump): - (JSC): - (JSC::CodeBlock::CodeBlock): - * bytecode/CodeBlock.h: - (CodeBlock): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::dumpCallFrame): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - (JSC::JIT::privateCompileSlowCases): - (JSC::JIT::privateCompile): - * jit/JIT.h: - (JIT): - * jit/JITDisassembler.cpp: Added. - (JSC): - (JSC::JITDisassembler::JITDisassembler): - (JSC::JITDisassembler::~JITDisassembler): - (JSC::JITDisassembler::dump): - (JSC::JITDisassembler::dumpForInstructions): - (JSC::JITDisassembler::dumpDisassembly): - * jit/JITDisassembler.h: Added. - (JSC): - (JITDisassembler): - (JSC::JITDisassembler::setStartOfCode): - (JSC::JITDisassembler::setForBytecodeMainPath): - (JSC::JITDisassembler::setForBytecodeSlowPath): - (JSC::JITDisassembler::setEndOfSlowPath): - (JSC::JITDisassembler::setEndOfCode): - -2012-11-21 Daniel Bates <dbates@webkit.org> - - JavaScript fails to concatenate large strings - <https://bugs.webkit.org/show_bug.cgi?id=102963> - - Reviewed by Michael Saboff. - - Fixes an issue where we inadvertently didn't check the length of - a JavaScript string for overflow. - - * runtime/Operations.h: - (JSC::jsString): - (JSC::jsStringFromArguments): - -2012-11-20 Filip Pizlo <fpizlo@apple.com> - - DFG should be able to cache closure calls (part 2/2) - https://bugs.webkit.org/show_bug.cgi?id=102662 - - Reviewed by Gavin Barraclough. - - Added caching of calls where the JSFunction* varies, but the Structure* and ExecutableBase* - stay the same. This is accomplished by replacing the branch that compares against a constant - JSFunction* with a jump to a closure call stub. The closure call stub contains a fast path, - and jumps slow directly to the virtual call thunk. - - Looks like a 1% win on V8v7. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/CallLinkInfo.cpp: - (JSC::CallLinkInfo::unlink): - * bytecode/CallLinkInfo.h: - (CallLinkInfo): - (JSC::CallLinkInfo::isLinked): - (JSC::getCallLinkInfoBytecodeIndex): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::finalizeUnconditionally): - (JSC): - (JSC::CodeBlock::findClosureCallForReturnPC): - (JSC::CodeBlock::bytecodeOffset): - (JSC::CodeBlock::codeOriginForReturn): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::getCallLinkInfo): - (CodeBlock): - (JSC::CodeBlock::isIncomingCallAlreadyLinked): - * dfg/DFGJITCompiler.cpp: - (JSC::DFG::JITCompiler::link): - * dfg/DFGJITCompiler.h: - (JSC::DFG::JITCompiler::addJSCall): - (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord): - (JSCallRecord): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGRepatch.cpp: - (JSC::DFG::linkSlowFor): - (DFG): - (JSC::DFG::dfgLinkFor): - (JSC::DFG::dfgLinkSlowFor): - (JSC::DFG::dfgLinkClosureCall): - * dfg/DFGRepatch.h: - (DFG): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::emitCall): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::emitCall): - * dfg/DFGThunks.cpp: - (DFG): - (JSC::DFG::linkClosureCallThunkGenerator): - * dfg/DFGThunks.h: - (DFG): - * heap/Heap.h: - (Heap): - (JSC::Heap::jitStubRoutines): - * heap/JITStubRoutineSet.h: - (JSC::JITStubRoutineSet::size): - (JSC::JITStubRoutineSet::at): - (JITStubRoutineSet): - * jit/ClosureCallStubRoutine.cpp: Added. - (JSC): - (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine): - (JSC::ClosureCallStubRoutine::~ClosureCallStubRoutine): - (JSC::ClosureCallStubRoutine::markRequiredObjectsInternal): - * jit/ClosureCallStubRoutine.h: Added. - (JSC): - (ClosureCallStubRoutine): - (JSC::ClosureCallStubRoutine::structure): - (JSC::ClosureCallStubRoutine::executable): - (JSC::ClosureCallStubRoutine::codeOrigin): - * jit/GCAwareJITStubRoutine.cpp: - (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): - * jit/GCAwareJITStubRoutine.h: - (GCAwareJITStubRoutine): - (JSC::GCAwareJITStubRoutine::isClosureCall): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - -2012-11-20 Filip Pizlo <fpizlo@apple.com> - - DFG should be able to cache closure calls (part 1/2) - https://bugs.webkit.org/show_bug.cgi?id=102662 - - Reviewed by Gavin Barraclough. - - Add ability to revert a jump replacement back to - branchPtrWithPatch(Condition, RegisterID, TrustedImmPtr). This is meant to be - a mandatory piece of functionality for all assemblers. I also renamed some of - the functions for reverting jump replacements back to - patchableBranchPtrWithPatch(Condition, Address, TrustedImmPtr), so as to avoid - confusion. - - * assembler/ARMv7Assembler.h: - (JSC::ARMv7Assembler::BadReg): - (ARMv7Assembler): - (JSC::ARMv7Assembler::revertJumpTo_movT3): - * assembler/LinkBuffer.h: - (JSC): - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::startOfBranchPtrWithPatchOnRegister): - (MacroAssemblerARMv7): - (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): - (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatchOnAddress): - * assembler/MacroAssemblerX86.h: - (JSC::MacroAssemblerX86::startOfBranchPtrWithPatchOnRegister): - (MacroAssemblerX86): - (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatchOnAddress): - (JSC::MacroAssemblerX86::revertJumpReplacementToBranchPtrWithPatch): - * assembler/MacroAssemblerX86_64.h: - (JSC::MacroAssemblerX86_64::startOfBranchPtrWithPatchOnRegister): - (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatchOnAddress): - (MacroAssemblerX86_64): - (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch): - * assembler/RepatchBuffer.h: - (JSC::RepatchBuffer::startOfBranchPtrWithPatchOnRegister): - (RepatchBuffer): - (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatchOnAddress): - (JSC::RepatchBuffer::revertJumpReplacementToBranchPtrWithPatch): - * assembler/X86Assembler.h: - (JSC::X86Assembler::revertJumpTo_cmpl_ir_force32): - (X86Assembler): - * dfg/DFGRepatch.cpp: - (JSC::DFG::replaceWithJump): - (JSC::DFG::dfgResetGetByID): - (JSC::DFG::dfgResetPutByID): - -2012-11-20 Yong Li <yoli@rim.com> - - [ARMv7] Neither linkCall() nor linkPointer() should flush code. - https://bugs.webkit.org/show_bug.cgi?id=99213 - - Reviewed by George Staikos. - - LinkBuffer doesn't need to flush code during linking. It will - eventually flush the whole executable. Fixing this gives >%5 - sunspider boost (on QNX). - - Also make replaceWithLoad() and replaceWithAddressComputation() flush - only when necessary. - - * assembler/ARMv7Assembler.h: - (JSC::ARMv7Assembler::linkCall): - (JSC::ARMv7Assembler::linkPointer): - (JSC::ARMv7Assembler::relinkCall): - (JSC::ARMv7Assembler::repatchInt32): - (JSC::ARMv7Assembler::repatchPointer): - (JSC::ARMv7Assembler::replaceWithLoad): Flush only after it did write. - (JSC::ARMv7Assembler::replaceWithAddressComputation): Flush only after it did write. - (JSC::ARMv7Assembler::setInt32): - (JSC::ARMv7Assembler::setPointer): - -2012-11-19 Filip Pizlo <fpizlo@apple.com> - - Remove support for ARMv7 errata from the jump code - https://bugs.webkit.org/show_bug.cgi?id=102759 - - Reviewed by Oliver Hunt. - - The jump replacement code was wrong to begin with since it wasn't doing - a cache flush on the inserted padding. And, to my knowledge, we don't need - this anymore, so this patch removes all errata code from the ARMv7 port. - - * assembler/ARMv7Assembler.h: - (JSC::ARMv7Assembler::computeJumpType): - (JSC::ARMv7Assembler::replaceWithJump): - (JSC::ARMv7Assembler::maxJumpReplacementSize): - (JSC::ARMv7Assembler::canBeJumpT3): - (JSC::ARMv7Assembler::canBeJumpT4): - -2012-11-19 Patrick Gansterer <paroga@webkit.org> - - [CMake] Create JavaScriptCore ForwardingHeaders - https://bugs.webkit.org/show_bug.cgi?id=92665 - - Reviewed by Brent Fulgham. - - When using CMake to build the Windows port, we need - to generate the forwarding headers with it too. - - * CMakeLists.txt: - -2012-11-19 Kihong Kwon <kihong.kwon@samsung.com> - - Add PROXIMITY_EVENTS feature - https://bugs.webkit.org/show_bug.cgi?id=102658 - - Reviewed by Kentaro Hara. - - Add PROXIMITY_EVENTS feature to xcode project for JavaScriptCore. - - * Configurations/FeatureDefines.xcconfig: - -2012-11-18 Dan Bernstein <mitz@apple.com> - - Try to fix the DFG build after r135099. - - * dfg/DFGCommon.h: - (JSC::DFG::shouldShowDisassembly): - -2012-11-18 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, build fix for !ENABLE(DFG_JIT). - - * dfg/DFGCommon.h: - (JSC::DFG::shouldShowDisassembly): - (DFG): - -2012-11-18 Filip Pizlo <fpizlo@apple.com> - - JSC should have more logging in structure-related code - https://bugs.webkit.org/show_bug.cgi?id=102630 - - Reviewed by Simon Fraser. - - - JSValue::description() now tells you if something is a structure, and if so, - what kind of structure it is. - - - Jettisoning logic now tells you why things are being jettisoned. - - - It's now possible to turn off GC-triggered jettisoning entirely. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::reoptimize): - (JSC::ProgramCodeBlock::jettison): - (JSC::EvalCodeBlock::jettison): - (JSC::FunctionCodeBlock::jettison): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): - * runtime/JSValue.cpp: - (JSC::JSValue::description): - * runtime/Options.h: - (JSC): - -2012-11-18 Filip Pizlo <fpizlo@apple.com> - - DFG constant folding phase should say 'changed = true' whenever it changes the graph - https://bugs.webkit.org/show_bug.cgi?id=102550 - - Rubber stamped by Mark Hahnenberg. - - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - -2012-11-17 Elliott Sprehn <esprehn@chromium.org> - - Expose JSObject removeDirect and PrivateName to WebCore - https://bugs.webkit.org/show_bug.cgi?id=102546 - - Reviewed by Geoffrey Garen. - - Export removeDirect for use in WebCore so JSDependentRetained works. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-11-16 Filip Pizlo <fpizlo@apple.com> - - Given a PutById or GetById with a proven structure, the DFG should be able to emit a PutByOffset or GetByOffset instead - https://bugs.webkit.org/show_bug.cgi?id=102327 - - Reviewed by Mark Hahnenberg. - - If the profiler tells us that a GetById or PutById may be polymorphic but our - control flow analysis proves that it isn't, we should trust the control flow - analysis over the profiler. This arises in cases where GetById or PutById were - inlined: the inlined function may have been called from other places that led - to polymorphism, but in the current inlined context, there is no polymorphism. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/GetByIdStatus.cpp: - (JSC::GetByIdStatus::computeFor): - (JSC): - * bytecode/GetByIdStatus.h: - (JSC::GetByIdStatus::GetByIdStatus): - (GetByIdStatus): - * bytecode/PutByIdStatus.cpp: - (JSC::PutByIdStatus::computeFor): - (JSC): - * bytecode/PutByIdStatus.h: - (JSC): - (JSC::PutByIdStatus::PutByIdStatus): - (PutByIdStatus): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::bestProvenStructure): - (AbstractValue): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): - (ConstantFoldingPhase): - * dfg/DFGNode.h: - (JSC::DFG::Node::convertToGetByOffset): - (Node): - (JSC::DFG::Node::convertToPutByOffset): - (JSC::DFG::Node::hasStorageResult): - * runtime/JSGlobalObject.h: - (JSC::Structure::prototypeChain): - (JSC): - (JSC::Structure::isValid): - * runtime/Operations.h: - (JSC::isPrototypeChainNormalized): - (JSC): - * runtime/Structure.h: - (Structure): - (JSC::Structure::transitionDidInvolveSpecificValue): - -2012-11-16 Tony Chang <tony@chromium.org> - - Remove ENABLE_CSS_HIERARCHIES since it's no longer in use - https://bugs.webkit.org/show_bug.cgi?id=102554 - - Reviewed by Andreas Kling. - - As mentioned in https://bugs.webkit.org/show_bug.cgi?id=79939#c41 , - we're going to revist this feature once additional vendor support is - achieved. - - * Configurations/FeatureDefines.xcconfig: - -2012-11-16 Patrick Gansterer <paroga@webkit.org> - - Build fix for WinCE after r133688. - - Use numeric_limits<uint32_t>::max() instead of UINT32_MAX. - - * runtime/CodeCache.h: - (JSC::CacheMap::CacheMap): - -2012-11-15 Filip Pizlo <fpizlo@apple.com> - - ClassInfo.h should have correct indentation. - - Rubber stamped by Mark Hahnenberg. - - ClassInfo.h had some true creativity in its use of whitespace. Some things within - the namespace were indented four spaces and others where not. One #define had its - contents indented four spaces, while another didn't. I applied the following rule: - - - Non-macro things in the namespace should not be indented (that's our current - accepted practice). - - - Macros should never be indented but if they are multi-line then their subsequent - bodies should be indented four spaces. I believe that is consistent with what we - do elsewhere. - - * runtime/ClassInfo.h: - (JSC): - (MethodTable): - (ClassInfo): - (JSC::ClassInfo::propHashTable): - (JSC::ClassInfo::isSubClassOf): - (JSC::ClassInfo::hasStaticProperties): - -2012-11-15 Filip Pizlo <fpizlo@apple.com> - - DFG should copy propagate trivially no-op ConvertThis - https://bugs.webkit.org/show_bug.cgi?id=102445 - - Reviewed by Oliver Hunt. - - Copy propagation is always a good thing, since it reveals must-alias relationships - to the CFA and CSE. This accomplishes copy propagation for ConvertThis by first - converting it to an Identity node (which is done by the constant folder since it - has access to CFA results) and then performing substitution of references to - Identity with references to Identity's child in the CSE. - - I'm not aiming for a big speed-up here; I just think that this will be useful for - the work on https://bugs.webkit.org/show_bug.cgi?id=102327. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * 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-11-15 Filip Pizlo <fpizlo@apple.com> - - CallData.h should have correct indentation. - - Rubber stamped by Mark Hahneberg. - - * runtime/CallData.h: - (JSC): - -2012-11-15 Filip Pizlo <fpizlo@apple.com> - - Remove methodCallDummy since it is not used anymore. - - Rubber stamped by Mark Hahnenberg. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (JSC): - (JSC::JSGlobalObject::visitChildren): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - -2012-11-14 Filip Pizlo <fpizlo@apple.com> - - Structure should be able to easily tell if the prototype chain might intercept a store - https://bugs.webkit.org/show_bug.cgi?id=102326 - - Reviewed by Geoffrey Garen. - - This improves our ability to reason about the correctness of the more optimized - prototype chain walk in JSObject::put(), while also making it straight forward to - check if the prototype chain will do strange things to a property store by just - looking at the structure. - - * runtime/JSObject.cpp: - (JSC::JSObject::put): - * runtime/Structure.cpp: - (JSC::Structure::prototypeChainMayInterceptStoreTo): - (JSC): - * runtime/Structure.h: - (Structure): - -2012-11-15 Thiago Marcos P. Santos <thiago.santos@intel.com> - - [CMake] Do not regenerate LLIntAssembly.h on every incremental build - https://bugs.webkit.org/show_bug.cgi?id=102248 - - Reviewed by Kenneth Rohde Christiansen. - - Update LLIntAssembly.h's mtime after running asm.rb to make the build - system dependency tracking consistent. - - * CMakeLists.txt: - -2012-11-15 Thiago Marcos P. Santos <thiago.santos@intel.com> - - Fix compiler warnings about signed/unsigned comparison on i386 - https://bugs.webkit.org/show_bug.cgi?id=102249 - - Reviewed by Kenneth Rohde Christiansen. - - Add casting to unsigned to shut up gcc warnings. Build was broken on - JSVALUE32_64 ports compiling with -Werror. - - * llint/LLIntData.cpp: - (JSC::LLInt::Data::performAssertions): - -2012-11-14 Brent Fulgham <bfulgham@webkit.org> - - [Windows, WinCairo] Unreviewed build fix. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - Missed one of the exports that was part of the WebKit2.def. - -2012-11-14 Brent Fulgham <bfulgham@webkit.org> - - [Windows, WinCairo] Correct build failure. - https://bugs.webkit.org/show_bug.cgi?id=102302 - - WebCore symbols were mistakenly added to the JavaScriptCore - library definition file. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Remove - WebCore symbols that were incorrectly added to the export file. - -2012-11-14 Mark Lam <mark.lam@apple.com> - - Change JSEventListener::m_jsFunction to be a weak ref. - https://bugs.webkit.org/show_bug.cgi?id=101989. - - Reviewed by Geoffrey Garen. - - Added infrastructure for scanning weak ref slots. - - * heap/SlotVisitor.cpp: Added #include "SlotVisitorInlines.h". - * heap/SlotVisitor.h: - (SlotVisitor): Added SlotVisitor::appendUnbarrieredWeak(). - * heap/SlotVisitorInlines.h: Added #include "Weak.h". - (JSC::SlotVisitor::appendUnbarrieredWeak): Added. - * heap/Weak.h: - (JSC::operator==): Added operator==() for Weak. - * runtime/JSCell.h: Removed #include "SlotVisitorInlines.h". - * runtime/JSObject.h: Added #include "SlotVisitorInlines.h". - -2012-11-14 Filip Pizlo <fpizlo@apple.com> - - Read-only properties created with putDirect() should tell the structure that there are read-only properties - https://bugs.webkit.org/show_bug.cgi?id=102292 - - Reviewed by Gavin Barraclough. - - This mostly affects things like function.length. - - * runtime/JSObject.h: - (JSC::JSObject::putDirectInternal): - -2012-11-13 Filip Pizlo <fpizlo@apple.com> - - Don't access Node& after adding nodes to the graph. - https://bugs.webkit.org/show_bug.cgi?id=102005 - - Reviewed by Oliver Hunt. - - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - -2012-11-14 Valery Ignatyev <valery.ignatyev@ispras.ru> - - Replace (typeof(x) != <"object", "undefined", ...>) with - !(typeof(x) == <"object",..>). Later is_object, is_<...> bytecode operation - will be used. - - https://bugs.webkit.org/show_bug.cgi?id=98893 - - Reviewed by Filip Pizlo. - - This eliminates expensive typeof implementation and - allows to use DFG optimizations, which doesn't support 'typeof'. - - * bytecompiler/NodesCodegen.cpp: - (JSC::BinaryOpNode::emitBytecode): - -2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> - - [Qt][ARM]REGRESSION(r133985): It broke the build - https://bugs.webkit.org/show_bug.cgi?id=101740 - - Reviewed by Csaba Osztrogonác. - - Changed the emitGenericContiguousPutByVal to accept the additional IndexingType argument. - This information was passed as a template parameter. - - * jit/JIT.h: - (JSC::JIT::emitInt32PutByVal): - (JSC::JIT::emitDoublePutByVal): - (JSC::JIT::emitContiguousPutByVal): - (JIT): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emitGenericContiguousPutByVal): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emitGenericContiguousPutByVal): - -2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> - - Fix the MIPS build after r134332 - https://bugs.webkit.org/show_bug.cgi?id=102227 - - Reviewed by Csaba Osztrogonác. - - Added missing methods for the MacroAssemblerMIPS, based on the MacroAssemblerARMv7. - - * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::canJumpReplacePatchableBranchPtrWithPatch): - (MacroAssemblerMIPS): - (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranchPtrWithPatch): - -2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> - - Fix the [-Wreturn-type] warning in JavaScriptCore/assembler/MacroAssemblerARM.h - https://bugs.webkit.org/show_bug.cgi?id=102206 - - Reviewed by Csaba Osztrogonác. - - Add a return value for the function to suppress the warning. - - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch): - -2012-11-14 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r134599. - http://trac.webkit.org/changeset/134599 - https://bugs.webkit.org/show_bug.cgi?id=102225 - - It broke the 32 bit EFL build (Requested by Ossy on #webkit). - - * jit/JITPropertyAccess.cpp: - * jit/JITPropertyAccess32_64.cpp: - (JSC): - (JSC::JIT::emitGenericContiguousPutByVal): - -2012-11-14 Balazs Kilvady <kilvadyb@homejinni.com> - - [Qt][ARM]REGRESSION(r133985): It broke the build - https://bugs.webkit.org/show_bug.cgi?id=101740 - - Reviewed by Csaba Osztrogonác. - - Template function body moved to fix VALUE_PROFILER disabled case. - - * jit/JITPropertyAccess.cpp: - (JSC): - (JSC::JIT::emitGenericContiguousPutByVal): - * jit/JITPropertyAccess32_64.cpp: - -2012-11-13 Filip Pizlo <fpizlo@apple.com> - - DFG CreateThis should be able to statically account for the structure of the object it creates, if profiling indicates that this structure is always the same - https://bugs.webkit.org/show_bug.cgi?id=102017 - - Reviewed by Geoffrey Garen. - - This adds a watchpoint in JSFunction on the cached inheritor ID. It also changes - NewObject to take a structure as an operand (previously it implicitly used the owning - global object's empty object structure). Any GetCallee where the callee is predictable - is turned into a CheckFunction + WeakJSConstant, and any CreateThis on a WeakJSConstant - where the inheritor ID watchpoint is still valid is turned into an InheritorIDWatchpoint - followed by a NewObject. NewObject already accounts for the structure it uses for object - creation in the CFA. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::checkFunctionElimination): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * dfg/DFGNode.h: - (JSC::DFG::Node::hasFunction): - (JSC::DFG::Node::function): - (JSC::DFG::Node::hasStructure): - * 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/Executable.h: - (JSC::JSFunction::JSFunction): - * runtime/JSBoundFunction.cpp: - (JSC): - * runtime/JSFunction.cpp: - (JSC::JSFunction::JSFunction): - (JSC::JSFunction::put): - (JSC::JSFunction::defineOwnProperty): - * runtime/JSFunction.h: - (JSC::JSFunction::tryGetKnownInheritorID): - (JSFunction): - (JSC::JSFunction::addInheritorIDWatchpoint): - -2012-11-13 Filip Pizlo <fpizlo@apple.com> - - JSFunction and its descendants should be destructible - https://bugs.webkit.org/show_bug.cgi?id=102062 - - Reviewed by Mark Hahnenberg. - - This will make it easy to place an InlineWatchpointSet inside JSFunction. In the - future, we could make JSFunction non-destructible again by making a version of - WatchpointSet that is entirely GC'd, but this seems like overkill for now. - - This is performance-neutral. - - * runtime/JSBoundFunction.cpp: - (JSC::JSBoundFunction::destroy): - (JSC): - * runtime/JSBoundFunction.h: - (JSBoundFunction): - * runtime/JSFunction.cpp: - (JSC): - (JSC::JSFunction::destroy): - * runtime/JSFunction.h: - (JSFunction): - -2012-11-13 Cosmin Truta <ctruta@rim.com> - - Uninitialized fields in class JSLock - https://bugs.webkit.org/show_bug.cgi?id=101695 - - Reviewed by Mark Hahnenberg. - - Initialize JSLock::m_ownerThread and JSLock::m_lockDropDepth. - - * runtime/JSLock.cpp: - (JSC::JSLock::JSLock): - -2012-11-13 Peter Gal <galpeter@inf.u-szeged.hu> - - Fix the ARM traditional build after r134332 - https://bugs.webkit.org/show_bug.cgi?id=102044 - - Reviewed by Zoltan Herczeg. - - Added missing methods for the MacroAssemblerARM, based on the MacroAssemblerARMv7. - - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::canJumpReplacePatchableBranchPtrWithPatch): - (MacroAssemblerARM): - (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch): - -2012-11-12 Filip Pizlo <fpizlo@apple.com> - - op_get_callee should have value profiling - https://bugs.webkit.org/show_bug.cgi?id=102047 - - Reviewed by Sam Weinig. - - This will allow us to detect if the callee is always the same, which is probably - the common case for a lot of constructors. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_get_callee): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_get_callee): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-11-12 Filip Pizlo <fpizlo@apple.com> - - The act of getting the callee during 'this' construction should be explicit in bytecode - https://bugs.webkit.org/show_bug.cgi?id=102016 - - Reviewed by Michael Saboff. - - This is mostly a rollout of http://trac.webkit.org/changeset/116673, but also includes - changes to have create_this use the result of get_callee. - - No performance or behavioral impact. This is just meant to allow us to profile - get_callee in the future. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCapabilities.h: - (JSC::DFG::canCompileOpcode): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - * jit/JIT.h: - (JIT): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_get_callee): - (JSC): - (JSC::JIT::emit_op_create_this): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_get_callee): - (JSC): - (JSC::JIT::emit_op_create_this): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2012-11-12 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, fix ARMv7 build. - - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch): - -2012-11-12 Filip Pizlo <fpizlo@apple.com> - - Patching of jumps to stubs should use jump replacement rather than branch destination overwrite - https://bugs.webkit.org/show_bug.cgi?id=101909 - - Reviewed by Geoffrey Garen. - - This saves a few instructions in inline cases, on those architectures where it is - easy to figure out where to put the jump replacement. Sub-1% speed-up across the - board. - - * assembler/MacroAssemblerARMv7.h: - (MacroAssemblerARMv7): - (JSC::MacroAssemblerARMv7::canJumpReplacePatchableBranchPtrWithPatch): - (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch): - * assembler/MacroAssemblerX86.h: - (JSC::MacroAssemblerX86::canJumpReplacePatchableBranchPtrWithPatch): - (MacroAssemblerX86): - (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerX86::revertJumpReplacementToPatchableBranchPtrWithPatch): - * assembler/MacroAssemblerX86_64.h: - (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch): - (MacroAssemblerX86_64): - (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatch): - (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch): - * assembler/RepatchBuffer.h: - (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatch): - (RepatchBuffer): - (JSC::RepatchBuffer::replaceWithJump): - (JSC::RepatchBuffer::revertJumpReplacementToPatchableBranchPtrWithPatch): - * assembler/X86Assembler.h: - (X86Assembler): - (JSC::X86Assembler::revertJumpTo_movq_i64r): - (JSC::X86Assembler::revertJumpTo_cmpl_im_force32): - (X86InstructionFormatter): - * bytecode/StructureStubInfo.h: - * dfg/DFGRepatch.cpp: - (JSC::DFG::replaceWithJump): - (DFG): - (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDList): - (JSC::DFG::tryBuildGetByIDProtoList): - (JSC::DFG::tryCachePutByID): - (JSC::DFG::dfgResetGetByID): - (JSC::DFG::dfgResetPutByID): - -2012-11-11 Filip Pizlo <fpizlo@apple.com> - - DFG ArithMul overflow check elimination is too aggressive - https://bugs.webkit.org/show_bug.cgi?id=101871 - - Reviewed by Oliver Hunt. - - The code was ignoring the fact that ((a * b) | 0) == (((a | 0) * (b | 0)) | 0) - only holds if a * b < 2^53. So, I changed it to only enable the optimization - when a < 2^22 and b is an int32 (and vice versa), using a super trivial peephole - analysis to prove the inequality. I considered writing an epic forward flow - formulation that tracks the ranges of integer values but then I thought better - of it. - - This also rewires the ArithMul integer speculation logic. Previously, we would - assume that an ArithMul was only UsedAsNumber if it escaped, and separately we - would decide whether to speculate integer based on a proof of the <2^22 - inequality. Now, we treat the double rounding behavior of ArithMul as if the - result was UsedAsNumber even if it did not escape. Then we try to prove that - double rounding cannot happen by attemping to prove that a < 2^22. This then - feeds back into the decision of whether or not to speculate integer (if we fail - to prove a < 2^22 then we're UsedAsNumber, and if we're also MayOverflow then - that forces double speculation). - - No performance impact. It just fixes a bug. - - * dfg/DFGGraph.h: - (JSC::DFG::Graph::mulShouldSpeculateInteger): - * dfg/DFGPredictionPropagationPhase.cpp: - (PredictionPropagationPhase): - (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant): - (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive): - (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo): - (JSC::DFG::PredictionPropagationPhase::propagate): - -2012-11-11 Filip Pizlo <fpizlo@apple.com> - - DFG should not emit function checks if we've already proved that the operand is that exact function - https://bugs.webkit.org/show_bug.cgi?id=101885 - - Reviewed by Oliver Hunt. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::filterByValue): - (AbstractValue): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - -2012-11-12 Kentaro Hara <haraken@chromium.org> - - [V8][JSC] ScriptProfileNode::callUID needs not to be [Custom] - https://bugs.webkit.org/show_bug.cgi?id=101892 - - Reviewed by Adam Barth. - - Added callUID(), which enables us to kill custom bindings for ScriptProfileNode::callUID. - - * profiler/ProfileNode.h: - (JSC::ProfileNode::callUID): - -2012-11-12 Carlos Garcia Campos <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing header. - -2012-11-11 Michael Pruett <michael@68k.org> - - Fix assertion failure in JSObject::tryGetIndexQuickly() - https://bugs.webkit.org/show_bug.cgi?id=101869 - - Reviewed by Filip Pizlo. - - Currently JSObject::tryGetIndexQuickly() triggers an assertion - failure when the object has an undecided indexing type. This - case should be treated the same as a blank indexing type. - - * runtime/JSObject.h: - (JSC::JSObject::tryGetIndexQuickly): - -2012-11-11 Filip Pizlo <fpizlo@apple.com> - - DFG register allocation should be greedy rather than round-robin - https://bugs.webkit.org/show_bug.cgi?id=101870 - - Reviewed by Geoffrey Garen. - - This simplifies the code, reduces some code duplication, and shows some slight - performance improvements in a few places, likely due to the fact that lower-numered - registers also typically have smaller encodings. - - * dfg/DFGRegisterBank.h: - (JSC::DFG::RegisterBank::RegisterBank): - (JSC::DFG::RegisterBank::tryAllocate): - (JSC::DFG::RegisterBank::allocate): - (JSC::DFG::RegisterBank::allocateInternal): - (RegisterBank): - -2012-11-11 Kenichi Ishibashi <bashi@chromium.org> - - WTFString::utf8() should have a mode of conversion to use replacement character - https://bugs.webkit.org/show_bug.cgi?id=101678 - - Reviewed by Alexey Proskuryakov. - - Follow the change on String::utf8() - - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::encode): Pass String::StrictConversion instead of true to String::utf8(). - -2012-11-10 Filip Pizlo <fpizlo@apple.com> - - DFG should optimize out the NaN check on loads from double arrays if the array prototype chain is having a great time - https://bugs.webkit.org/show_bug.cgi?id=101718 - - Reviewed by Geoffrey Garen. - - If we're reading from a JSArray in double mode, where the array's structure is - primordial (all aspects of the structure are unchanged except for indexing type), - and the result of the load is used in arithmetic that is known to not distinguish - between NaN and undefined, then we should not emit a NaN check. Looks like a 5% - win on navier-stokes. - - Also fixed an OpInfo initialization goof for String ops that was revealed by this - change. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::arraySpeculationToString): - * dfg/DFGArrayMode.h: - (JSC::DFG::ArrayMode::isSaneChain): - (ArrayMode): - (JSC::DFG::ArrayMode::isInBounds): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::handleIntrinsic): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGNodeFlags.cpp: - (JSC::DFG::nodeFlagsAsString): - * dfg/DFGNodeFlags.h: - (DFG): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::arrayPrototypeChainIsSane): - (JSC): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - -2012-11-10 Filip Pizlo <fpizlo@apple.com> - - DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true - https://bugs.webkit.org/show_bug.cgi?id=101511 - - Reviewed by Geoffrey Garen. - - This is the second attempt at this patch, which fixes the !"" case. - - To make life easier, this moves BranchDirection into BasicBlock so that after - running the CFA, we always know, for each block, what direction the CFA - proved. CFG simplification now both uses and preserves cfaBranchDirection in - its transformations. - - Also made both LogicalNot and Branch check whether the operand is a known cell - with a known structure, and if so, made them do the appropriate folding. - - 5% speed-up on V8/raytrace because it makes raytrace's own null checks - evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact - that we were already doing structure check hoisting. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::endBasicBlock): - (JSC::DFG::AbstractState::execute): - (JSC::DFG::AbstractState::mergeToSuccessors): - * dfg/DFGAbstractState.h: - (AbstractState): - * dfg/DFGBasicBlock.h: - (JSC::DFG::BasicBlock::BasicBlock): - (BasicBlock): - * dfg/DFGBranchDirection.h: Added. - (DFG): - (JSC::DFG::branchDirectionToString): - (JSC::DFG::isKnownDirection): - (JSC::DFG::branchCondition): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - (JSC::DFG::CFGSimplificationPhase::mergeBlocks): - -2012-11-10 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r133971. - http://trac.webkit.org/changeset/133971 - https://bugs.webkit.org/show_bug.cgi?id=101839 - - Causes WebProcess to hang at 100% on www.apple.com (Requested - by kling on #webkit). - - * JavaScriptCore.xcodeproj/project.pbxproj: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::endBasicBlock): - (JSC::DFG::AbstractState::execute): - (JSC::DFG::AbstractState::mergeToSuccessors): - * dfg/DFGAbstractState.h: - (JSC::DFG::AbstractState::branchDirectionToString): - (AbstractState): - * dfg/DFGBasicBlock.h: - (JSC::DFG::BasicBlock::BasicBlock): - (BasicBlock): - * dfg/DFGBranchDirection.h: Removed. - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - (JSC::DFG::CFGSimplificationPhase::mergeBlocks): - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - If the DFG ArrayMode says that an access is on an OriginalArray, then the checks should always enforce this - https://bugs.webkit.org/show_bug.cgi?id=101720 - - Reviewed by Mark Hahnenberg. - - Previously, "original" arrays was just a hint that we could find the structure - of the array if we needed to even if the array profile didn't have it due to - polymorphism. Now, "original" arrays are a property that is actually checked: - if an array access has ArrayMode::arrayClass() == Array::OriginalArray, then we - can be sure that the code performing the access is dealing with not just a - JSArray, but a JSArray that has no named properties, no indexed accessors, and - the ArrayPrototype as its prototype. This will be useful for optimizations that - are being done as part of https://bugs.webkit.org/show_bug.cgi?id=101720. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::ArrayMode::originalArrayStructure): - (DFG): - (JSC::DFG::ArrayMode::alreadyChecked): - * dfg/DFGArrayMode.h: - (JSC): - (DFG): - (JSC::DFG::ArrayMode::withProfile): - (ArrayMode): - (JSC::DFG::ArrayMode::benefitsFromOriginalArray): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::checkArray): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnString): - (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): - (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - Fix indentation of BooleanPrototype.h - - Rubber stamped by Mark Hahnenberg. - - * runtime/BooleanPrototype.h: - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - Fix indentation of BooleanObject.h - - Rubber stamped by Mark Hahnenberg. - - * runtime/BooleanObject.h: - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - Fix indentation of BooleanConstructor.h - - Rubber stamped by Mark Hahnenberg. - - * runtime/BooleanConstructor.h: - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - Fix indentation of BatchedTransitionOptimizer.h - - Rubber stamped by Mark Hahnenberg. - - * runtime/BatchedTransitionOptimizer.h: - -2012-11-09 Oliver Hunt <oliver@apple.com> - - So Thingy probably isn't the best name for a class, so - renamed to CacheMap. - - RS=Geoff - - * runtime/CodeCache.h: - (JSC::CacheMap::CacheMap): - -2012-11-09 Filip Pizlo <fpizlo@apple.com> - - ArrayPrototype should start out with a blank indexing type - https://bugs.webkit.org/show_bug.cgi?id=101719 - - Reviewed by Mark Hahnenberg. - - This allows us to track if the array prototype ever ends up with indexed - properties. - - * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::create): - (JSC::ArrayPrototype::ArrayPrototype): - * runtime/ArrayPrototype.h: - (ArrayPrototype): - (JSC::ArrayPrototype::createStructure): - -2012-11-08 Mark Hahnenberg <mhahnenberg@apple.com> - - MarkStackArray should use the BlockAllocator instead of the MarkStackSegmentAllocator - https://bugs.webkit.org/show_bug.cgi?id=101642 - - Reviewed by Filip Pizlo. - - MarkStackSegmentAllocator is like a miniature version of the BlockAllocator. Now that the BlockAllocator has support - for a variety of block sizes, we should get rid of the MarkStackSegmentAllocator in favor of the BlockAllocator. - - * heap/BlockAllocator.h: Add new specializations of regionSetFor for the new MarkStackSegments. - (JSC): - (JSC::MarkStackSegment): - * heap/GCThreadSharedData.cpp: - (JSC::GCThreadSharedData::GCThreadSharedData): - (JSC::GCThreadSharedData::reset): - * heap/GCThreadSharedData.h: - (GCThreadSharedData): - * heap/MarkStack.cpp: - (JSC::MarkStackArray::MarkStackArray): We now have a doubly linked list of MarkStackSegments, so we need to refactor - all the places that used the old custom tail/previous logic. - (JSC::MarkStackArray::~MarkStackArray): - (JSC::MarkStackArray::expand): - (JSC::MarkStackArray::refill): - (JSC::MarkStackArray::donateSomeCellsTo): Refactor to use the new linked list. - (JSC::MarkStackArray::stealSomeCellsFrom): Ditto. - * heap/MarkStack.h: - (JSC): - (MarkStackSegment): - (JSC::MarkStackSegment::MarkStackSegment): - (JSC::MarkStackSegment::sizeFromCapacity): - (MarkStackArray): - * heap/MarkStackInlines.h: - (JSC::MarkStackSegment::create): - (JSC): - (JSC::MarkStackArray::postIncTop): - (JSC::MarkStackArray::preDecTop): - (JSC::MarkStackArray::setTopForFullSegment): - (JSC::MarkStackArray::setTopForEmptySegment): - (JSC::MarkStackArray::top): - (JSC::MarkStackArray::validatePrevious): - (JSC::MarkStackArray::append): - (JSC::MarkStackArray::removeLast): - (JSC::MarkStackArray::isEmpty): - (JSC::MarkStackArray::size): - * heap/SlotVisitor.cpp: - (JSC::SlotVisitor::SlotVisitor): - -2012-11-09 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - [Qt] r133953 broke the ARM_TRADITIONAL build - https://bugs.webkit.org/show_bug.cgi?id=101706 - - Reviewed by Csaba Osztrogonác. - - Fix for both hardfp and softfp. - - * dfg/DFGCCallHelpers.h: - (CCallHelpers): - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - -2012-11-09 Sheriff Bot <webkit.review.bot@gmail.com> - - Unreviewed, rolling out r134051. - http://trac.webkit.org/changeset/134051 - https://bugs.webkit.org/show_bug.cgi?id=101757 - - It didn't fix the build (Requested by Ossy on #webkit). - - * dfg/DFGCCallHelpers.h: - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - -2012-11-09 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - [Qt] r133953 broke the ARM_TRADITIONAL build - https://bugs.webkit.org/show_bug.cgi?id=101706 - - Reviewed by Csaba Osztrogonác. - - Fix the ARM_TRADITIONAL build after r133953 - - * dfg/DFGCCallHelpers.h: - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - (CCallHelpers): - -2012-11-09 Csaba Osztrogonác <ossy@webkit.org> - - [Qt] Fix the LLINT build from ARMv7 platform - https://bugs.webkit.org/show_bug.cgi?id=101712 - - Reviewed by Simon Hausmann. - - Enable generating of LLIntAssembly.h on ARM platforms. - - * DerivedSources.pri: - * JavaScriptCore.pro: - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - ArrayPrototype.h should have correct indentation - - Rubber stamped by Sam Weinig. - - * runtime/ArrayPrototype.h: - -2012-11-08 Mark Lam <mark.lam@apple.com> - - Renamed ...InlineMethods.h files to ...Inlines.h. - https://bugs.webkit.org/show_bug.cgi?id=101145. - - Reviewed by Geoffrey Garen. - - This is only a refactoring effort to rename the files. There are no - functionality changes. - - * API/JSObjectRef.cpp: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/CodeBlock.cpp: - * dfg/DFGOperations.cpp: - * heap/ConservativeRoots.cpp: - * heap/CopiedBlock.h: - * heap/CopiedSpace.cpp: - * heap/CopiedSpaceInlineMethods.h: Removed. - * heap/CopiedSpaceInlines.h: Copied from Source/JavaScriptCore/heap/CopiedSpaceInlineMethods.h. - * heap/CopyVisitor.cpp: - * heap/CopyVisitorInlineMethods.h: Removed. - * heap/CopyVisitorInlines.h: Copied from Source/JavaScriptCore/heap/CopyVisitorInlineMethods.h. - * heap/GCThread.cpp: - * heap/GCThreadSharedData.cpp: - * heap/HandleStack.cpp: - * heap/Heap.cpp: - * heap/HeapRootVisitor.h: - * heap/MarkStack.cpp: - * heap/MarkStackInlineMethods.h: Removed. - * heap/MarkStackInlines.h: Copied from Source/JavaScriptCore/heap/MarkStackInlineMethods.h. - * heap/SlotVisitor.cpp: - * heap/SlotVisitor.h: - * heap/SlotVisitorInlineMethods.h: Removed. - * heap/SlotVisitorInlines.h: Copied from Source/JavaScriptCore/heap/SlotVisitorInlineMethods.h. - * jit/HostCallReturnValue.cpp: - * jit/JIT.cpp: - * jit/JITArithmetic.cpp: - * jit/JITArithmetic32_64.cpp: - * jit/JITCall.cpp: - * jit/JITCall32_64.cpp: - * jit/JITInlineMethods.h: Removed. - * jit/JITInlines.h: Copied from Source/JavaScriptCore/jit/JITInlineMethods.h. - * jit/JITOpcodes.cpp: - * jit/JITOpcodes32_64.cpp: - * jit/JITPropertyAccess.cpp: - * jit/JITPropertyAccess32_64.cpp: - * jsc.cpp: - * runtime/ArrayConstructor.cpp: - * runtime/ArrayPrototype.cpp: - * runtime/ButterflyInlineMethods.h: Removed. - * runtime/ButterflyInlines.h: Copied from Source/JavaScriptCore/runtime/ButterflyInlineMethods.h. - * runtime/IndexingHeaderInlineMethods.h: Removed. - * runtime/IndexingHeaderInlines.h: Copied from Source/JavaScriptCore/runtime/IndexingHeaderInlineMethods.h. - * runtime/JSActivation.h: - * runtime/JSArray.cpp: - * runtime/JSArray.h: - * runtime/JSCell.h: - * runtime/JSObject.cpp: - * runtime/JSValueInlineMethods.h: Removed. - * runtime/JSValueInlines.h: Copied from Source/JavaScriptCore/runtime/JSValueInlineMethods.h. - * runtime/LiteralParser.cpp: - * runtime/ObjectConstructor.cpp: - * runtime/Operations.h: - * runtime/RegExpMatchesArray.cpp: - * runtime/RegExpObject.cpp: - * runtime/StringPrototype.cpp: - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - ArrayConstructor.h should have correct indentation - - Rubber stamped by Sam Weinig. - - * runtime/ArrayConstructor.h: - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - DFG should know that int == null is always false - https://bugs.webkit.org/show_bug.cgi?id=101665 - - Reviewed by Oliver Hunt. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - Arguments.h should have correct indentation - - Rubber stamped by Sam Weinig. - - * runtime/Arguments.h: - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - It should be possible to JIT compile get_by_vals and put_by_vals even if the DFG is disabled. - - Reviewed by Oliver Hunt. - - * jit/JITInlineMethods.h: - (JSC::JIT::chooseArrayMode): - -2012-11-08 Filip Pizlo <fpizlo@apple.com> - - op_call should have LLInt call link info even if the DFG is disabled - https://bugs.webkit.org/show_bug.cgi?id=101672 - - Reviewed by Oliver Hunt. - - Get rid of the evil uses of fall-through. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - -2012-11-08 Oliver Hunt <oliver@apple.com> - - Improve effectiveness of function-level caching - https://bugs.webkit.org/show_bug.cgi?id=101667 - - Reviewed by Filip Pizlo. - - Added a random-eviction based cache for unlinked functions, and switch - UnlinkedFunctionExecutable's code references to Weak<>, thereby letting - us remove the explicit UnlinkedFunctionExecutable::clearCode() calls that - were being triggered by GC. - - Refactored the random eviction part of the CodeCache into a separate data - structure so that I didn't have to duplicate the code again, and then used - that for the new function cache. - - * bytecode/UnlinkedCodeBlock.cpp: - (JSC::UnlinkedFunctionExecutable::visitChildren): - (JSC::UnlinkedFunctionExecutable::codeBlockFor): - * bytecode/UnlinkedCodeBlock.h: - (JSC::UnlinkedFunctionExecutable::clearCodeForRecompilation): - (UnlinkedFunctionExecutable): - * debugger/Debugger.cpp: - * runtime/CodeCache.cpp: - (JSC::CodeCache::getCodeBlock): - (JSC::CodeCache::generateFunctionCodeBlock): - (JSC::CodeCache::getFunctionExecutableFromGlobalCode): - (JSC::CodeCache::usedFunctionCode): - (JSC): - * runtime/Executable.cpp: - (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): - (JSC::FunctionExecutable::clearCode): - * runtime/Executable.h: - (FunctionExecutable): - -2012-11-07 Filip Pizlo <fpizlo@apple.com> - - DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true - https://bugs.webkit.org/show_bug.cgi?id=101511 - - Reviewed by Oliver Hunt. - - To make life easier, this moves BranchDirection into BasicBlock so that after - running the CFA, we always know, for each block, what direction the CFA - proved. CFG simplification now both uses and preserves cfaBranchDirection in - its transformations. - - Also made both LogicalNot and Branch check whether the operand is a known cell - with a known structure, and if so, made them do the appropriate folding. - - 5% speed-up on V8/raytrace because it makes raytrace's own null checks - evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact - that we were already doing structure check hoisting. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::endBasicBlock): - (JSC::DFG::AbstractState::execute): - (JSC::DFG::AbstractState::mergeToSuccessors): - * dfg/DFGAbstractState.h: - (AbstractState): - * dfg/DFGBasicBlock.h: - (JSC::DFG::BasicBlock::BasicBlock): - (BasicBlock): - * dfg/DFGBranchDirection.h: Added. - (DFG): - (JSC::DFG::branchDirectionToString): - (JSC::DFG::isKnownDirection): - (JSC::DFG::branchCondition): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - (JSC::DFG::CFGSimplificationPhase::mergeBlocks): - -2012-11-08 Christophe Dumez <christophe.dumez@intel.com> - - [JSC] HTML extensions to String.prototype should escape " as " in argument values - https://bugs.webkit.org/show_bug.cgi?id=90667 - - Reviewed by Benjamin Poulain. - - Escape quotation mark as " in argument values to: - - String.prototype.anchor(name) - - String.prototype.fontcolor(color) - - String.prototype.fontsize(size) - - String.prototype.link(href) - - This behavior matches Chromium/V8 and Firefox/Spidermonkey - implementations and is requited by: - http://mathias.html5.org/specs/javascript/#escapeattributevalue - - This also fixes a potential security risk (XSS vector). - - * runtime/StringPrototype.cpp: - (JSC::stringProtoFuncFontcolor): - (JSC::stringProtoFuncFontsize): - (JSC::stringProtoFuncAnchor): - (JSC::stringProtoFuncLink): - -2012-11-08 Anders Carlsson <andersca@apple.com> - - HeapStatistics::s_pauseTimeStarts and s_pauseTimeEnds should be Vectors - https://bugs.webkit.org/show_bug.cgi?id=101651 - - Reviewed by Andreas Kling. - - HeapStatistics uses Deques when Vectors would work just as good. - - * heap/HeapStatistics.cpp: - * heap/HeapStatistics.h: - (HeapStatistics): - -2012-11-07 Filip Pizlo <fpizlo@apple.com> - - DFG should not assume that something is a double just because it might be undefined - https://bugs.webkit.org/show_bug.cgi?id=101438 - - Reviewed by Oliver Hunt. - - This changes all non-bitop arithmetic to (a) statically expect that variables are - defined prior to use in arithmetic and (b) not fall off into double paths just - because a value may not be a number. This is accomplished with two new notions of - speculation: - - shouldSpeculateIntegerExpectingDefined: Should we speculate that the value is an - integer if we ignore undefined (i.e. SpecOther) predictions? - - shouldSpeculateIntegerForArithmetic: Should we speculate that the value is an - integer if we ignore non-numeric predictions? - - This is a ~2x speed-up on programs that seem to our prediction propagator to have - paths in which otherwise numeric variables are undefined. - - * bytecode/SpeculatedType.h: - (JSC::isInt32SpeculationForArithmetic): - (JSC): - (JSC::isInt32SpeculationExpectingDefined): - (JSC::isDoubleSpeculationForArithmetic): - (JSC::isNumberSpeculationExpectingDefined): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::addShouldSpeculateInteger): - (JSC::DFG::Graph::mulShouldSpeculateInteger): - (JSC::DFG::Graph::negateShouldSpeculateInteger): - (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): - (JSC::DFG::Graph::mulImmediateShouldSpeculateInteger): - * dfg/DFGNode.h: - (JSC::DFG::Node::shouldSpeculateIntegerForArithmetic): - (Node): - (JSC::DFG::Node::shouldSpeculateIntegerExpectingDefined): - (JSC::DFG::Node::shouldSpeculateDoubleForArithmetic): - (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileAdd): - (JSC::DFG::SpeculativeJIT::compileArithMod): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JITArithmetic.cpp: - (JSC::JIT::emit_op_div): - -2012-11-06 Filip Pizlo <fpizlo@apple.com> - - JSC should infer when indexed storage contains only integers or doubles - https://bugs.webkit.org/show_bug.cgi?id=98606 - - Reviewed by Oliver Hunt. - - This adds two new indexing types: int32 and double. It also adds array allocation profiling, - which allows array allocations to converge to allocating arrays using those types to which - those arrays would have been converted. - - 20% speed-up on navier-stokes. 40% speed-up on various Kraken DSP tests. Some slow-downs too, - but a performance win overall on all benchmarks we track. - - * API/JSObjectRef.cpp: - (JSObjectMakeArray): - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * assembler/AbstractMacroAssembler.h: - (JumpList): - (JSC::AbstractMacroAssembler::JumpList::JumpList): - * assembler/MacroAssemblerX86Common.h: - (JSC::MacroAssemblerX86Common::branchDouble): - * assembler/X86Assembler.h: - (JSC::X86Assembler::jnp): - (X86Assembler): - (JSC::X86Assembler::X86InstructionFormatter::emitRex): - * bytecode/ArrayAllocationProfile.cpp: Added. - (JSC): - (JSC::ArrayAllocationProfile::updateIndexingType): - * bytecode/ArrayAllocationProfile.h: Added. - (JSC): - (ArrayAllocationProfile): - (JSC::ArrayAllocationProfile::ArrayAllocationProfile): - (JSC::ArrayAllocationProfile::selectIndexingType): - (JSC::ArrayAllocationProfile::updateLastAllocation): - (JSC::ArrayAllocationProfile::selectIndexingTypeFor): - (JSC::ArrayAllocationProfile::updateLastAllocationFor): - * bytecode/ArrayProfile.cpp: - (JSC::ArrayProfile::updatedObservedArrayModes): - (JSC): - * bytecode/ArrayProfile.h: - (JSC): - (JSC::arrayModesInclude): - (JSC::shouldUseSlowPutArrayStorage): - (JSC::shouldUseFastArrayStorage): - (JSC::shouldUseContiguous): - (JSC::shouldUseDouble): - (JSC::shouldUseInt32): - (ArrayProfile): - * bytecode/ByValInfo.h: - (JSC::isOptimizableIndexingType): - (JSC::jitArrayModeForIndexingType): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): - (JSC): - (JSC::CodeBlock::updateAllValueProfilePredictions): - (JSC::CodeBlock::updateAllArrayPredictions): - (JSC::CodeBlock::updateAllPredictions): - (JSC::CodeBlock::shouldOptimizeNow): - * bytecode/CodeBlock.h: - (CodeBlock): - (JSC::CodeBlock::numberOfArrayAllocationProfiles): - (JSC::CodeBlock::addArrayAllocationProfile): - (JSC::CodeBlock::updateAllValueProfilePredictions): - (JSC::CodeBlock::updateAllArrayPredictions): - * bytecode/DFGExitProfile.h: - (JSC::DFG::exitKindToString): - * bytecode/Instruction.h: - (JSC): - (JSC::Instruction::Instruction): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/SpeculatedType.h: - (JSC): - (JSC::isRealNumberSpeculation): - * bytecode/UnlinkedCodeBlock.cpp: - (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): - * bytecode/UnlinkedCodeBlock.h: - (JSC): - (JSC::UnlinkedCodeBlock::addArrayAllocationProfile): - (JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): - (UnlinkedCodeBlock): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::newArrayAllocationProfile): - (JSC): - (JSC::BytecodeGenerator::emitNewArray): - (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::ArrayMode::fromObserved): - (JSC::DFG::ArrayMode::refine): - (DFG): - (JSC::DFG::ArrayMode::alreadyChecked): - (JSC::DFG::arrayTypeToString): - * dfg/DFGArrayMode.h: - (JSC::DFG::ArrayMode::withType): - (ArrayMode): - (JSC::DFG::ArrayMode::withTypeAndConversion): - (JSC::DFG::ArrayMode::usesButterfly): - (JSC::DFG::ArrayMode::isSpecific): - (JSC::DFG::ArrayMode::supportsLength): - (JSC::DFG::ArrayMode::arrayModesThatPassFiltering): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getArrayMode): - (ByteCodeParser): - (JSC::DFG::ByteCodeParser::handleIntrinsic): - (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCCallHelpers.h: - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - (CCallHelpers): - * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: - (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal): - (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::checkArray): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::byValIsPure): - * dfg/DFGNode.h: - (NewArrayBufferData): - (JSC::DFG::Node::hasIndexingType): - (Node): - (JSC::DFG::Node::indexingType): - (JSC::DFG::Node::setIndexingType): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): - (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): - (DFG): - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::arrayify): - (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): - (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): - (SpeculativeJIT): - (SpeculateIntegerOperand): - (JSC::DFG::SpeculateIntegerOperand::use): - (SpeculateDoubleOperand): - (JSC::DFG::SpeculateDoubleOperand::use): - * dfg/DFGSpeculativeJIT32_64.cpp: - (DFG): - (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JIT.h: - (JSC::JIT::emitInt32GetByVal): - (JIT): - (JSC::JIT::emitInt32PutByVal): - (JSC::JIT::emitDoublePutByVal): - (JSC::JIT::emitContiguousPutByVal): - * jit/JITExceptions.cpp: - (JSC::genericThrow): - * jit/JITInlineMethods.h: - (JSC::arrayProfileSaw): - (JSC::JIT::chooseArrayMode): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_new_array): - (JSC::JIT::emit_op_new_array_with_size): - (JSC::JIT::emit_op_new_array_buffer): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emitDoubleGetByVal): - (JSC): - (JSC::JIT::emitContiguousGetByVal): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::emitGenericContiguousPutByVal): - (JSC::JIT::emitSlow_op_put_by_val): - (JSC::JIT::privateCompileGetByVal): - (JSC::JIT::privateCompilePutByVal): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emitContiguousGetByVal): - (JSC::JIT::emitDoubleGetByVal): - (JSC): - (JSC::JIT::emit_op_put_by_val): - (JSC::JIT::emitGenericContiguousPutByVal): - (JSC::JIT::emitSlow_op_put_by_val): - * jit/JITStubs.cpp: - (JSC::DEFINE_STUB_FUNCTION): - * jit/JITStubs.h: - (JSC): - * jsc.cpp: - (GlobalObject::finishCreation): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::jitCompileAndSetHeuristics): - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * offlineasm/x86.rb: - * runtime/ArrayConstructor.cpp: - (JSC::constructArrayWithSizeQuirk): - * runtime/ArrayConstructor.h: - (JSC): - * runtime/ArrayPrototype.cpp: - (JSC::arrayProtoFuncConcat): - (JSC::arrayProtoFuncSlice): - (JSC::arrayProtoFuncSplice): - (JSC::arrayProtoFuncFilter): - (JSC::arrayProtoFuncMap): - * runtime/Butterfly.h: - (JSC::Butterfly::contiguousInt32): - (JSC::Butterfly::contiguousDouble): - (JSC::Butterfly::fromContiguous): - * runtime/ButterflyInlineMethods.h: - (JSC::Butterfly::createUninitializedDuringCollection): - * runtime/FunctionPrototype.cpp: - (JSC::functionProtoFuncBind): - * runtime/IndexingHeaderInlineMethods.h: - (JSC::IndexingHeader::indexingPayloadSizeInBytes): - * runtime/IndexingType.cpp: - (JSC::leastUpperBoundOfIndexingTypes): - (JSC): - (JSC::leastUpperBoundOfIndexingTypeAndType): - (JSC::leastUpperBoundOfIndexingTypeAndValue): - (JSC::indexingTypeToString): - * runtime/IndexingType.h: - (JSC): - (JSC::hasUndecided): - (JSC::hasInt32): - (JSC::hasDouble): - * runtime/JSArray.cpp: - (JSC::JSArray::setLength): - (JSC::JSArray::pop): - (JSC::JSArray::push): - (JSC::JSArray::shiftCountWithAnyIndexingType): - (JSC::JSArray::unshiftCountWithAnyIndexingType): - (JSC::compareNumbersForQSortWithInt32): - (JSC): - (JSC::compareNumbersForQSortWithDouble): - (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: - (JSArray): - (JSC::createContiguousArrayButterfly): - (JSC::JSArray::create): - (JSC::JSArray::tryCreateUninitialized): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (JSC): - (JSC::JSGlobalObject::haveABadTime): - (JSC::JSGlobalObject::visitChildren): - * runtime/JSGlobalObject.h: - (JSGlobalObject): - (JSC::JSGlobalObject::originalArrayStructureForIndexingType): - (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation): - (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation): - (JSC::JSGlobalObject::isOriginalArrayStructure): - (JSC::constructEmptyArray): - (JSC::constructArray): - * runtime/JSObject.cpp: - (JSC::JSObject::copyButterfly): - (JSC::JSObject::getOwnPropertySlotByIndex): - (JSC::JSObject::putByIndex): - (JSC::JSObject::enterDictionaryIndexingMode): - (JSC::JSObject::createInitialIndexedStorage): - (JSC): - (JSC::JSObject::createInitialUndecided): - (JSC::JSObject::createInitialInt32): - (JSC::JSObject::createInitialDouble): - (JSC::JSObject::createInitialContiguous): - (JSC::JSObject::convertUndecidedToInt32): - (JSC::JSObject::convertUndecidedToDouble): - (JSC::JSObject::convertUndecidedToContiguous): - (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements): - (JSC::JSObject::convertUndecidedToArrayStorage): - (JSC::JSObject::convertInt32ToDouble): - (JSC::JSObject::convertInt32ToContiguous): - (JSC::JSObject::convertInt32ToArrayStorage): - (JSC::JSObject::convertDoubleToContiguous): - (JSC::JSObject::convertDoubleToArrayStorage): - (JSC::JSObject::convertContiguousToArrayStorage): - (JSC::JSObject::convertUndecidedForValue): - (JSC::JSObject::convertInt32ForValue): - (JSC::JSObject::setIndexQuicklyToUndecided): - (JSC::JSObject::convertInt32ToDoubleOrContiguousWhilePerformingSetIndex): - (JSC::JSObject::convertDoubleToContiguousWhilePerformingSetIndex): - (JSC::JSObject::ensureInt32Slow): - (JSC::JSObject::ensureDoubleSlow): - (JSC::JSObject::ensureContiguousSlow): - (JSC::JSObject::ensureArrayStorageSlow): - (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): - (JSC::JSObject::switchToSlowPutArrayStorage): - (JSC::JSObject::deletePropertyByIndex): - (JSC::JSObject::getOwnPropertyNames): - (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): - (JSC::JSObject::putByIndexBeyondVectorLength): - (JSC::JSObject::putDirectIndexBeyondVectorLength): - (JSC::JSObject::getNewVectorLength): - (JSC::JSObject::countElements): - (JSC::JSObject::ensureLengthSlow): - (JSC::JSObject::getOwnPropertyDescriptor): - * runtime/JSObject.h: - (JSC::JSObject::getArrayLength): - (JSC::JSObject::getVectorLength): - (JSC::JSObject::canGetIndexQuickly): - (JSC::JSObject::getIndexQuickly): - (JSC::JSObject::tryGetIndexQuickly): - (JSC::JSObject::canSetIndexQuickly): - (JSC::JSObject::canSetIndexQuicklyForPutDirect): - (JSC::JSObject::setIndexQuickly): - (JSC::JSObject::initializeIndex): - (JSC::JSObject::hasSparseMap): - (JSC::JSObject::inSparseIndexingMode): - (JSObject): - (JSC::JSObject::ensureInt32): - (JSC::JSObject::ensureDouble): - (JSC::JSObject::ensureLength): - (JSC::JSObject::indexingData): - (JSC::JSObject::currentIndexingData): - (JSC::JSObject::getHolyIndexQuickly): - (JSC::JSObject::relevantLength): - (JSC::JSObject::currentRelevantLength): - * runtime/JSValue.cpp: - (JSC::JSValue::description): - * runtime/LiteralParser.cpp: - (JSC::::parse): - * runtime/ObjectConstructor.cpp: - (JSC::objectConstructorGetOwnPropertyNames): - (JSC::objectConstructorKeys): - * runtime/StringPrototype.cpp: - (JSC::stringProtoFuncMatch): - (JSC::stringProtoFuncSplit): - * runtime/Structure.cpp: - (JSC::Structure::nonPropertyTransition): - * runtime/StructureTransitionTable.h: - (JSC::newIndexingType): - -2012-11-08 Balazs Kilvady <kilvadyb@homejinni.com> - - ASSERT problem on MIPS - https://bugs.webkit.org/show_bug.cgi?id=100589 - - Reviewed by Oliver Hunt. - - ASSERT fix for MIPS arch. - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_resolve_operations): - -2012-11-08 Michael Saboff <msaboff@apple.com> - - OpaqueJSClassContextData() should use StringImpl::isolatedCopy() to make string copies - https://bugs.webkit.org/show_bug.cgi?id=101507 - - Reviewed by Andreas Kling. - - Changed to use isolatedCopy() for key Strings. - - * API/JSClassRef.cpp: - (OpaqueJSClassContextData::OpaqueJSClassContextData): - -2012-11-07 Mark Hahnenberg <mhahnenberg@apple.com> - - WeakBlocks should be HeapBlocks - https://bugs.webkit.org/show_bug.cgi?id=101411 - - Reviewed by Oliver Hunt. - - Currently WeakBlocks use fastMalloc memory. They are very similar to the other HeapBlocks, however, - so we should change them to being allocated with the BlockAllocator. - - * heap/BlockAllocator.cpp: - (JSC::BlockAllocator::BlockAllocator): - * heap/BlockAllocator.h: Added a new RegionSet for WeakBlocks. - (JSC): - (BlockAllocator): - (JSC::WeakBlock): - * heap/Heap.h: Friended WeakSet to allow access to the BlockAllocator. - (Heap): - * heap/WeakBlock.cpp: - (JSC::WeakBlock::create): Refactored to use HeapBlocks rather than fastMalloc. - (JSC::WeakBlock::WeakBlock): - * heap/WeakBlock.h: Changed the WeakBlock size to 4 KB so that it divides evenly into the Region size. - (JSC): - (WeakBlock): - * heap/WeakSet.cpp: - (JSC::WeakSet::~WeakSet): - (JSC::WeakSet::addAllocator): - -2012-11-07 Filip Pizlo <fpizlo@apple.com> - - Indentation of ArgList.h is wrong - https://bugs.webkit.org/show_bug.cgi?id=101441 - - Reviewed by Andreas Kling. - - Just unindented by 4 spaces. - - * runtime/ArgList.h: - -2012-11-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - [Qt][ARM] REGRESSION(r133688): It made all JSC and layout tests crash on ARM traditional platform - https://bugs.webkit.org/show_bug.cgi?id=101465 - - Reviewed by Oliver Hunt. - - Fix failing javascriptcore tests on ARM after r133688 - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - -2012-11-06 Oliver Hunt <oliver@apple.com> - - Reduce parser overhead in JSC - https://bugs.webkit.org/show_bug.cgi?id=101127 - - Reviewed by Filip Pizlo. - - An exciting journey into the world of architecture in which our hero - adds yet another layer to JSC codegeneration. - - This patch adds a marginally more compact form of bytecode that is - free from any data specific to a given execution context, and that - does store any data structures necessary for execution. To actually - execute this UnlinkedBytecode we still need to instantiate a real - CodeBlock, but this is a much faster linear time operation than any - of the earlier parsing or code generation passes. - - As the unlinked code is context free we can then simply use a cache - from source to unlinked code mapping to completely avoid all of the - old parser overhead. The cache is currently very simple and memory - heavy, using the complete source text as a key (rather than SourceCode - or equivalent), and a random eviction policy. - - This seems to produce a substantial win when loading identical content - in different contexts. - - * API/tests/testapi.c: - (main): - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/CodeBlock.cpp: - * bytecode/CodeBlock.h: - Moved a number of fields, and a bunch of logic to UnlinkedCodeBlock.h/cpp - * bytecode/Opcode.h: - Added a global const init no op instruction needed to get correct - behaviour without any associated semantics. - * bytecode/UnlinkedCodeBlock.cpp: Added. - * bytecode/UnlinkedCodeBlock.h: Added. - A fairly shallow, GC allocated version of the old CodeBlock - classes with a 32bit instruction size, and just metadata - size tracking. - * bytecompiler/BytecodeGenerator.cpp: - * bytecompiler/BytecodeGenerator.h: - Replace direct access to m_symbolTable with access through - symbolTable(). ProgramCode no longer has a symbol table at - all so some previously unconditional (and pointless) uses - of symbolTable get null checks. - A few other changes to deal with type changes due to us generating - unlinked code (eg. pointer free, so profile indices rather than - pointers). - * dfg/DFGByteCodeParser.cpp: - * dfg/DFGCapabilities.h: - Support global_init_nop - * interpreter/Interpreter.cpp: - Now get the ProgramExecutable to initialise new global properties - before starting execution. - * jit/JIT.cpp: - * jit/JITDriver.h: - * jit/JITStubs.cpp: - * llint/LLIntData.cpp: - * llint/LLIntSlowPaths.cpp: - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - Adding init_global_const_nop everywhere else - * parser/Parser.h: - * parser/ParserModes.h: Added. - * parser/ParserTokens.h: - Parser no longer needs a global object or callframe to function - * runtime/CodeCache.cpp: Added. - * runtime/CodeCache.h: Added. - A simple, random eviction, Source->UnlinkedCode cache - * runtime/Executable.cpp: - * runtime/Executable.h: - Executables now reference their unlinked counterparts, and - request code specifically for the target global object. - * runtime/JSGlobalData.cpp: - * runtime/JSGlobalData.h: - GlobalData now owns a CodeCache and a set of new structures - for the unlinked code types. - * runtime/JSGlobalObject.cpp: - * runtime/JSGlobalObject.h: - Utility functions used by executables to perform compilation - - * runtime/JSType.h: - Add new JSTypes for unlinked code - -2012-11-06 Michael Saboff <msaboff@apple.com> - - JSStringCreateWithCFString() Should create an 8 bit String if possible - https://bugs.webkit.org/show_bug.cgi?id=101104 - - Reviewed by Darin Adler. - - Try converting the CFString to an 8 bit string using CFStringGetBytes(..., - kCFStringEncodingISOLatin1, ...) and return the 8 bit string if successful. - If not proceed with 16 bit conversion. - - * API/JSStringRefCF.cpp: - (JSStringCreateWithCFString): - -2012-11-06 Oliver Hunt <oliver@apple.com> - - Reduce direct m_symbolTable usage in CodeBlock - https://bugs.webkit.org/show_bug.cgi?id=101391 - - Reviewed by Sam Weinig. - - Simple refactoring. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - (JSC::CodeBlock::dumpStatistics): - (JSC::CodeBlock::nameForRegister): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::isCaptured): - -2012-11-06 Michael Saboff <msaboff@apple.com> - - Lexer::scanRegExp, create 8 bit pattern and flag Identifiers from 16 bit source when possible - https://bugs.webkit.org/show_bug.cgi?id=101013 - - Reviewed by Darin Adler. - - Changed scanRegExp so that it will create 8 bit identifiers from 8 bit sources and from 16 bit sources - whan all the characters are 8 bit. Using two templated helpers, the "is all 8 bit" check is only performed - on 16 bit sources. The first helper is orCharacter() that will accumulate the or value of all characters - only for 16 bit sources. Replaced the helper Lexer::makeIdentifierSameType() with Lexer::makeRightSizedIdentifier(). - - * parser/Lexer.cpp: - (JSC::orCharacter<LChar>): Explicit template that serves as a placeholder. - (JSC::orCharacter<UChar>): Explicit template that actually or accumulates characters. - (JSC::Lexer::scanRegExp): - * parser/Lexer.h: - (Lexer): - (JSC::Lexer::makeRightSizedIdentifier<LChar>): New template that always creates an 8 bit Identifier. - (JSC::Lexer::makeRightSizedIdentifier<UChar>): New template that creates an 8 bit Identifier for 8 bit - data in a 16 bit source. - -2012-11-06 Filip Pizlo <fpizlo@apple.com> - - Indentation of JSCell.h is wrong - https://bugs.webkit.org/show_bug.cgi?id=101379 - - Rubber stamped by Alexey Proskuryakov. - - Just removed four spaces on a bunch of lines. - - * runtime/JSCell.h: - -2012-11-05 Filip Pizlo <fpizlo@apple.com> - - Indentation of JSObject.h is wrong - https://bugs.webkit.org/show_bug.cgi?id=101313 - - Rubber stamped by Alexey Proskuryakov. - - Just unindented code, since namespace bodies shouldn't be indented. - - * runtime/JSObject.h: - -2012-11-05 Filip Pizlo <fpizlo@apple.com> - - Indentation of JSArray.h is wrong - https://bugs.webkit.org/show_bug.cgi?id=101314 - - Rubber stamped by Alexey Proskuryakov. - - Just removing the indentation inside the namespace body. - - * runtime/JSArray.h: - -2012-11-05 Filip Pizlo <fpizlo@apple.com> - - DFG should not fall down to patchable GetById just because a prototype had things added to it - https://bugs.webkit.org/show_bug.cgi?id=101299 - - Reviewed by Geoffrey Garen. - - This looks like a slight win on V8v7 and SunSpider. - - * bytecode/DFGExitProfile.h: - (JSC::DFG::exitKindToString): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-11-05 Filip Pizlo <fpizlo@apple.com> - - Get rid of method_check - https://bugs.webkit.org/show_bug.cgi?id=101147 - - Reviewed by Geoffrey Garen. - - op_method_check no longer buys us anything, since get_by_id proto caching - gives just as much profiling information and the DFG inlines monomorphic - proto accesses anyway. - - This also has the potential for a speed-up since it makes parsing of - profiling data easier. No longer do we have to deal with the confusion of - the get_by_id portion of a method_check appearing monomorphic even though - we're really dealing with a bimorphic access (method_check specializes for - one case and get_by_id for another). - - This looks like a 1% speed-up on both SunSpider and V8v7. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::printGetByIdCacheStatus): - (JSC::CodeBlock::dump): - (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::shrinkToFit): - (JSC::CodeBlock::unlinkCalls): - * bytecode/CodeBlock.h: - (JSC::CodeBlock::getCallLinkInfo): - (JSC::CodeBlock::callLinkInfo): - (CodeBlock): - * bytecode/GetByIdStatus.cpp: - (JSC::GetByIdStatus::computeFromLLInt): - * bytecode/MethodCallLinkInfo.cpp: Removed. - * bytecode/MethodCallLinkInfo.h: Removed. - * bytecode/MethodCallLinkStatus.cpp: Removed. - * bytecode/MethodCallLinkStatus.h: Removed. - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::FunctionCallDotNode::emitBytecode): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCapabilities.h: - (JSC::DFG::canCompileOpcode): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - (JSC::JIT::privateCompileSlowCases): - (JSC::PropertyStubCompilationInfo::copyToStubInfo): - (JSC::JIT::privateCompile): - * jit/JIT.h: - (JSC::PropertyStubCompilationInfo::slowCaseInfo): - (PropertyStubCompilationInfo): - (JSC): - (JIT): - * jit/JITPropertyAccess.cpp: - (JSC): - (JSC::JIT::emitSlow_op_get_by_id): - (JSC::JIT::compileGetByIdSlowCase): - * jit/JITPropertyAccess32_64.cpp: - (JSC): - (JSC::JIT::compileGetByIdSlowCase): - * jit/JITStubs.cpp: - (JSC): - * jit/JITStubs.h: - * llint/LowLevelInterpreter.asm: - -2012-11-05 Yuqiang Xian <yuqiang.xian@intel.com> - - Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations - https://bugs.webkit.org/show_bug.cgi?id=100321 - - Reviewed by Filip Pizlo. - - We have refactored the MacroAssembler and JIT compilers to distinguish - the pointer operations from the 64-bit integer operations (see bug #99154). - Now we want to do the similar work for LLInt, and the goal is same as - the one mentioned in 99154. - - This is the second part of the modification: in the low level interpreter, - changing the operations on 64-bit integers to use the "<foo>q" instructions. - This also removes some unused/meaningless "<foo>p" instructions. - - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter.cpp: - (JSC::CLoop::execute): - * llint/LowLevelInterpreter64.asm: - * offlineasm/armv7.rb: - * offlineasm/cloop.rb: - * offlineasm/instructions.rb: - * offlineasm/x86.rb: - -2012-11-05 Filip Pizlo <fpizlo@apple.com> - - Prototype chain caching should check that the path from the base object to the slot base involves prototype hops only - https://bugs.webkit.org/show_bug.cgi?id=101276 - - Reviewed by Gavin Barraclough. - - Changed normalizePrototypeChain() to report an invalid prototype chain if any object is a proxy. - This catches cases where our prototype chain checks would have been insufficient to guard against - newly introduced properties, despecialized properties, or deleted properties in the chain of - objects involved in the access. - - * dfg/DFGRepatch.cpp: - (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDProtoList): - (JSC::DFG::tryCachePutByID): - (JSC::DFG::tryBuildPutByIdList): - * jit/JITStubs.cpp: - (JSC::JITThunks::tryCachePutByID): - (JSC::JITThunks::tryCacheGetByID): - (JSC::DEFINE_STUB_FUNCTION): - * llint/LLIntSlowPaths.cpp: - (JSC::LLInt::LLINT_SLOW_PATH_DECL): - * runtime/Operations.h: - (JSC): - (JSC::normalizePrototypeChain): - -2012-11-05 Dima Gorbik <dgorbik@apple.com> - - Back out controversial changes from Bug 98665. - https://bugs.webkit.org/show_bug.cgi?id=101244 - - Reviewed by David Kilzer. - - Backing out changes from Bug 98665 until further discussions take place on rules for including Platform.h in Assertions.h. - - * API/tests/minidom.c: - * API/tests/testapi.c: - -2012-11-04 Filip Pizlo <fpizlo@apple.com> - - Reduce the verbosity of referring to QNaN in JavaScriptCore - https://bugs.webkit.org/show_bug.cgi?id=101174 - - Reviewed by Geoffrey Garen. - - Introduces a #define QNaN in JSValue.h, and replaces all previous uses of - std::numeric_limits<double>::quiet_NaN() with QNaN. - - * API/JSValueRef.cpp: - (JSValueMakeNumber): - (JSValueToNumber): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emitFloatTypedArrayGetByVal): - * runtime/CachedTranscendentalFunction.h: - (JSC::CachedTranscendentalFunction::initialize): - * runtime/DateConstructor.cpp: - (JSC::constructDate): - * runtime/DateInstanceCache.h: - (JSC::DateInstanceData::DateInstanceData): - (JSC::DateInstanceCache::reset): - * runtime/ExceptionHelpers.cpp: - (JSC::InterruptedExecutionError::defaultValue): - (JSC::TerminatedExecutionError::defaultValue): - * runtime/JSCell.h: - (JSC::JSValue::getPrimitiveNumber): - * runtime/JSDateMath.cpp: - (JSC::parseDateFromNullTerminatedCharacters): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - (JSC::JSGlobalData::resetDateCache): - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::parseInt): - (JSC::jsStrDecimalLiteral): - (JSC::toDouble): - (JSC::jsToNumber): - (JSC::parseFloat): - * runtime/JSValue.cpp: - (JSC::JSValue::toNumberSlowCase): - * runtime/JSValue.h: - (JSC): - * runtime/JSValueInlineMethods.h: - (JSC::jsNaN): - * runtime/MathObject.cpp: - (JSC::mathProtoFuncMax): - (JSC::mathProtoFuncMin): - -2012-11-03 Filip Pizlo <fpizlo@apple.com> - - Baseline JIT should use structure watchpoints whenever possible - https://bugs.webkit.org/show_bug.cgi?id=101146 - - Reviewed by Sam Weinig. - - No speed-up yet except on toy programs. I think that it will start to show - speed-ups with https://bugs.webkit.org/show_bug.cgi?id=101147, which this is - a step towards. - - * jit/JIT.h: - (JIT): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompilePutByIdTransition): - (JSC::JIT::privateCompileGetByIdProto): - (JSC::JIT::privateCompileGetByIdProtoList): - (JSC::JIT::privateCompileGetByIdChainList): - (JSC::JIT::privateCompileGetByIdChain): - (JSC::JIT::addStructureTransitionCheck): - (JSC): - (JSC::JIT::testPrototype): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::privateCompilePutByIdTransition): - (JSC::JIT::privateCompileGetByIdProto): - (JSC::JIT::privateCompileGetByIdProtoList): - (JSC::JIT::privateCompileGetByIdChainList): - (JSC::JIT::privateCompileGetByIdChain): - -2012-11-04 Csaba Osztrogonác <ossy@webkit.org> - - [Qt] udis86_itab.c is always regenerated - https://bugs.webkit.org/show_bug.cgi?id=100756 - - Reviewed by Simon Hausmann. - - * DerivedSources.pri: Generate sources to the generated directory. - * disassembler/udis86/differences.txt: - * disassembler/udis86/itab.py: Add --outputDir option. - (UdItabGenerator.__init__): - (genItabH): - (genItabC): - (main): - -2012-11-02 Filip Pizlo <fpizlo@apple.com> - - LLInt 32-bit put_by_val ArrayStorage case should use the right register (t3, not t2) for the index in the publicLength updating path - https://bugs.webkit.org/show_bug.cgi?id=101118 - - Reviewed by Gavin Barraclough. - - * llint/LowLevelInterpreter32_64.asm: - -2012-11-02 Filip Pizlo <fpizlo@apple.com> - - DFG::Node::converToStructureTransitionWatchpoint should take kindly to ArrayifyToStructure - https://bugs.webkit.org/show_bug.cgi?id=101117 - - Reviewed by Gavin Barraclough. - - We have logic to convert ArrayifyToStructure to StructureTransitionWatchpoint, which is awesome, except - that previously convertToStructureTransitionWatchpoint was (a) asserting that it never saw an - ArrayifyToStructure and (b) would incorrectly create a ForwardStructureTransitionWatchpoint if it did. - - * dfg/DFGNode.h: - (JSC::DFG::Node::convertToStructureTransitionWatchpoint): - -2012-11-02 Filip Pizlo <fpizlo@apple.com> - - DFG::SpeculativeJIT::typedArrayDescriptor should use the Float64Array descriptor for Float64Arrays - https://bugs.webkit.org/show_bug.cgi?id=101114 - - Reviewed by Gavin Barraclough. - - As in https://bugs.webkit.org/show_bug.cgi?id=101112, this was only wrong when Float64Array descriptors - hadn't been initialized yet. That happens rarely, but when it does happen, we would crash. - - This would also become much more wrong if we ever put type size info (num bytes, etc) in the descriptor - and used that directly. So it's good to fix it. - - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): - -2012-11-02 Filip Pizlo <fpizlo@apple.com> - - JIT::privateCompileGetByVal should use the uint8ClampedArrayDescriptor for compiling accesses to Uint8ClampedArrays - https://bugs.webkit.org/show_bug.cgi?id=101112 - - Reviewed by Gavin Barraclough. - - The only reason why the code was wrong to use uint8ArrayDescriptor instead is that if we're just using - Uint8ClampedArrays then the descriptor for Uint8Array may not have been initialized. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompileGetByVal): - -2012-11-02 Mark Hahnenberg <mhahnenberg@apple.com> - - MarkedBlocks should use something other than the mark bits to indicate liveness for newly allocated objects - https://bugs.webkit.org/show_bug.cgi?id=100877 - - Reviewed by Filip Pizlo. - - Currently when we canonicalize cell liveness data in MarkedBlocks, we set the mark bit for every cell in the - block except for those in the free list. This allows us to consider objects that were allocated since the - previous collection to be considered live until they have a chance to be properly marked by the collector. - - If we want to use the mark bits to signify other types of information, e.g. using sticky mark bits for generational - collection, we will have to keep track of newly allocated objects in a different fashion when we canonicalize cell liveness. - - One method would be to allocate a separate set of bits while canonicalizing liveness data. These bits would - track the newly allocated objects in the block separately from those objects who had already been marked. We would - then check these bits, along with the mark bits, when determining liveness. - - * heap/Heap.h: - (Heap): - (JSC::Heap::isLive): We now check for the presence of the newlyAllocated Bitmap. - (JSC): - * heap/MarkedBlock.cpp: - (JSC::MarkedBlock::specializedSweep): We clear the newlyAllocated Bitmap if we're creating a free list. This - will happen if we canonicalize liveness data for some other reason than collection (e.g. forEachCell) and - then start allocating again. - (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): - (SetNewlyAllocatedFunctor): - (JSC::SetNewlyAllocatedFunctor::operator()): We set the newlyAllocated bits for all the objects - that aren't already marked. We undo the bits for the objects in the free list later in canonicalizeCellLivenessData. - (JSC::MarkedBlock::canonicalizeCellLivenessData): We should never have a FreeListed block with a newlyAllocated Bitmap. - We allocate the new Bitmap, set the bits for all the objects that aren't already marked, and then unset all of the - bits for the items currently in the FreeList. - * heap/MarkedBlock.h: - (JSC::MarkedBlock::clearMarks): We clear the newlyAllocated bitmap if it exists because at this point we don't need it - any more. - (JSC::MarkedBlock::isEmpty): If we have some objects that are newlyAllocated, we are not empty. - (JSC::MarkedBlock::isNewlyAllocated): - (JSC): - (JSC::MarkedBlock::setNewlyAllocated): - (JSC::MarkedBlock::clearNewlyAllocated): - (JSC::MarkedBlock::isLive): We now check the newlyAllocated Bitmap, if it exists, when determining liveness of a cell in - a block that is Marked. - * heap/WeakBlock.cpp: - (JSC::WeakBlock::visit): We need to make sure we don't finalize objects that are in the newlyAllocated Bitmap. - (JSC::WeakBlock::reap): Ditto. - -2012-11-02 Filip Pizlo <fpizlo@apple.com> - - JIT::privateCompileGetByVal should use MacroAssemblerCodePtr::createFromExecutableAddress like JIT::privateCompilePutByVal - https://bugs.webkit.org/show_bug.cgi?id=101109 - - Reviewed by Gavin Barraclough. - - This fixes crashes on ARMv7 resulting from the return address already being tagged with the THUMB2 bit. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::privateCompileGetByVal): - -2012-11-02 Simon Fraser <simon.fraser@apple.com> - - Enable SUBPIXEL_LAYOUT on Mac - https://bugs.webkit.org/show_bug.cgi?id=101076 - - Reviewed by Dave Hyatt. - - Define ENABLE_SUBPIXEL_LAYOUT and include it in FEATURE_DEFINES. - - * Configurations/FeatureDefines.xcconfig: - -2012-11-02 Michael Saboff <msaboff@apple.com> - - RegExp.prototype.toString Should Produce an 8 bit JSString if possible. - https://bugs.webkit.org/show_bug.cgi?id=101003 - - Reviewed by Geoffrey Garen. - - Took the logic of regExpObjectSource() and created two templated helpers that uses the - source character type when appending to the StringBuilder. - - * runtime/RegExpObject.cpp: - (JSC::appendLineTerminatorEscape): Checks line terminate type to come up with escaped version. - (JSC::regExpObjectSourceInternal): Templated version of original. - (JSC::regExpObjectSource): Wrapper function. - -2012-11-02 Adam Barth <abarth@webkit.org> - - ENABLE(UNDO_MANAGER) is disabled everywhere and is not under active development - https://bugs.webkit.org/show_bug.cgi?id=100711 - - Reviewed by Eric Seidel. - - * Configurations/FeatureDefines.xcconfig: - -2012-11-02 Simon Hausmann <simon.hausmann@digia.com> - - [Qt] Fix build on Windows when Qt is configured with -release - https://bugs.webkit.org/show_bug.cgi?id=101041 - - Reviewed by Jocelyn Turcotte. - - When Qt is configured with -debug or -release, the release/debug build of for example - QtCore is not available by default. For LLIntExtractor we always need to build debug - _and_ release versions, but we do not actually need any Qt libraries nor qtmain(d).lib. - Therefore we can disable all these features but need to keep $$QT.core.includes in the - INCLUDEPATH for some defines from qglobal.h. - - * LLIntOffsetsExtractor.pro: - -2012-11-01 Mark Lam <mark.lam@apple.com> - - A llint workaround for a toolchain issue. - https://bugs.webkit.org/show_bug.cgi?id=101012. - - Reviewed by Michael Saboff. - - * llint/LowLevelInterpreter.asm: - - use a local label to workaround the toolchain issue with undeclared - global labels. - -2012-11-01 Oliver Hunt <oliver@apple.com> - - Remove GlobalObject constant register that is typically unused - https://bugs.webkit.org/show_bug.cgi?id=101005 - - Reviewed by Geoffrey Garen. - - The GlobalObject constant register is frequently allocated even when it - is not used, it is also getting in the way of some other optimisations. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecode/CodeBlock.h: - (CodeBlock): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseResolveOperations): - -2012-10-31 Filip Pizlo <fpizlo@apple.com> - - DFG optimized string access code should be enabled - https://bugs.webkit.org/show_bug.cgi?id=100825 - - Reviewed by Oliver Hunt. - - - Removes prediction checks from the parser. - - - Fixes the handling of array mode refinement for strings. I.e. we don't do - any refinement - we already know it's going to be a string. We could - revisit this in the future, but for now the DFG lacks the ability to - handle any array modes other than Array::String for string intrinsics, so - this is as good as it gets. - - - Removes uses of isBlahSpeculation for checking if a mode is already - checked. isBlahSpeculation implicitly checks if the SpeculatedType is not - BOTTOM ("empty"), which breaks for checking if a mode is already checked - since a mode may already be "checked" in the sense that we've proven that - the code is unreachable. - - ~1% speed-up on V8v7, mostly from a speed-up on crypto, which uses string - intrinsics in one of the hot functions. - - * bytecode/SpeculatedType.h: - (JSC::speculationChecked): - (JSC): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::ArrayMode::alreadyChecked): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::handleIntrinsic): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): - -2012-10-31 Filip Pizlo <fpizlo@apple.com> - - Sparse array size threshold should be increased to 100000 - https://bugs.webkit.org/show_bug.cgi?id=100827 - - Reviewed by Oliver Hunt. - - This enables the use of contiguous arrays in programs that previously - couldn't use them. And I so far can't see any examples of this being - a downside. To the extent that there is a downside, it ought to be - addressed by GC: https://bugs.webkit.org/show_bug.cgi?id=100828 - - * runtime/ArrayConventions.h: - (JSC): - -2012-10-31 Mark Lam <mark.lam@apple.com> - - C++ llint 64-bit backend needs to zero extend results of int32 operations. - https://bugs.webkit.org/show_bug.cgi?id=100899. - - Reviewed by Filip Pizlo. - - llint asm instructions ending in "i" for a 64-bit machine expects the - high 32-bit of registers to be zero'ed out when a 32-bit instruction - writes into a register. Fixed the C++ llint to honor this. - - Fixed the index register used in BaseIndex addressing to be of size - intptr_t as expected. - - Updated CLoopRegister to handle different endiannesss configurations. - - * llint/LowLevelInterpreter.cpp: - (JSC::CLoopRegister::clearHighWord): - - new method to clear the high 32-bit of a 64-bit register. - It's a no-op for the 32-bit build. - (CLoopRegister): - - CLoopRegister now takes care of packing and byte endianness order. - (JSC::CLoop::execute): - Added an assert. - * offlineasm/cloop.rb: - - Add calls to clearHighWord() wherever needed. - -2012-10-31 Mark Lam <mark.lam@apple.com> - - A JSC printf (support for %J+s and %b). - https://bugs.webkit.org/show_bug.cgi?id=100566. - - Reviewed by Michael Saboff. - - Added VMInspector::printf(), fprintf(), sprintf(), and snprintf(). - - %b prints ints as boolean TRUE (non-zero) or FALSE (zero). - - %Js prints a WTF::String* like a %s prints a char*. - Also works for 16bit WTF::Strings (prints wchar_t* using %S). - - '+' is a modifier meaning 'use verbose mode', and %J+s is an example - of its use. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * interpreter/VMInspector.cpp: - (FormatPrinter): - (JSC::FormatPrinter::~FormatPrinter): - (JSC::FormatPrinter::print): - (JSC::FormatPrinter::printArg): - (JSC::FormatPrinter::printWTFString): - (JSC::FileFormatPrinter::FileFormatPrinter): - (JSC::FileFormatPrinter::printArg): - (JSC::StringFormatPrinter::StringFormatPrinter): - (JSC::StringFormatPrinter::printArg): - (JSC::StringNFormatPrinter::StringNFormatPrinter): - (JSC::StringNFormatPrinter::printArg): - (JSC::VMInspector::fprintf): - (JSC::VMInspector::printf): - (JSC::VMInspector::sprintf): - (JSC::VMInspector::snprintf): - * interpreter/VMInspector.h: - (VMInspector): - -2012-10-31 Mark Lam <mark.lam@apple.com> - - 64-bit llint PC offset can be negative: using an unsigned shift is a bug. - https://bugs.webkit.org/show_bug.cgi?id=100896. - - Reviewed by Filip Pizlo. - - Fixed the PC offset divisions in the 64-bit llint asm to use rshift instead of urshift. - - * llint/LowLevelInterpreter64.asm: - -2012-10-30 Yuqiang Xian <yuqiang.xian@intel.com> - - glsl-function-atan.html WebGL conformance test fails after https://bugs.webkit.org/show_bug.cgi?id=99154 - https://bugs.webkit.org/show_bug.cgi?id=100789 - - Reviewed by Filip Pizlo. - - We accidently missed a bitwise double to int64 conversion. - - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::silentFill): - -2012-10-30 Joseph Pecoraro <pecoraro@apple.com> - - [Mac] Sync up FeatureDefine Configuration Files - https://bugs.webkit.org/show_bug.cgi?id=100171 - - Reviewed by David Kilzer. - - Follow up to better coordinate with iOS feature defines. Make: - - - ENABLE_FILTERS always on - - ENABLE_INPUT_* iphonesimulator values point to the iphoneos values - - * Configurations/FeatureDefines.xcconfig: - -2012-10-30 Joseph Pecoraro <pecoraro@apple.com> - - [Mac] Sync up FeatureDefine Configuration Files - https://bugs.webkit.org/show_bug.cgi?id=100171 - - Reviewed by David Kilzer. - - Ensure an identical FeatureDefine files across all projects. Changes: - - - ENABLE_CSS_BOX_DECORATION_BREAK should be in all - - ENABLE_PDFKIT_PLUGIN should be in all - - ENABLE_RESOLUTION_MEDIA_QUERY should be in all - - ENABLE_ENCRYPTED_MEDIA should be in all - - ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING with corrected value - - Some alphabetical ordering cleanup - - * Configurations/FeatureDefines.xcconfig: - -2012-10-30 Mark Hahnenberg <mhahnenberg@apple.com> - - Arrays can change IndexingType in the middle of sorting - https://bugs.webkit.org/show_bug.cgi?id=100773 - - Reviewed by Filip Pizlo. - - Instead of giving up, we just fetch the appropriate vector based on the current - IndexingType of the array. - - * runtime/JSArray.cpp: - (JSC::JSArray::sortVector): - * runtime/JSObject.h: - (JSObject): - (JSC::JSObject::currentIndexingData): - (JSC::JSObject::currentRelevantLength): - -2012-10-29 Anders Carlsson <andersca@apple.com> - - Build WebKit as C++11 on Mac - https://bugs.webkit.org/show_bug.cgi?id=100720 - - Reviewed by Daniel Bates. - - * Configurations/Base.xcconfig: - Add CLANG_CXX_LANGUAGE_STANDARD=gnu++0x. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::generate): - (JSC::BytecodeGenerator::pushFinallyContext): - (JSC::BytecodeGenerator::beginSwitch): - * llint/LLIntOffsetsExtractor.cpp: - * runtime/Identifier.cpp: - (JSC::Identifier::add8): - * runtime/Identifier.h: - (JSC::Identifier::add): - * runtime/JSONObject.cpp: - (JSC::appendStringToStringBuilder): - * runtime/StringPrototype.cpp: - (JSC::replaceUsingStringSearch): - Add static_casts to prevent implicit type conversions in non-constant initializer lists. - -2012-10-28 Mark Rowe <mrowe@apple.com> - - Simplify Xcode configuration settings that used to vary between OS versions. - - Reviewed by Dan Bernstein. - - * Configurations/Base.xcconfig: - * Configurations/DebugRelease.xcconfig: - * Configurations/JavaScriptCore.xcconfig: - -2012-10-28 Mark Rowe <mrowe@apple.com> - - Remove references to unsupported OS and Xcode versions. - - Reviewed by Anders Carlsson. - - * Configurations/Base.xcconfig: - * Configurations/CompilerVersion.xcconfig: Removed. - * Configurations/DebugRelease.xcconfig: - * Configurations/Version.xcconfig: - * JavaScriptCore.xcodeproj/project.pbxproj: - -2012-10-29 Michael Saboff <msaboff@apple.com> - - Non-special escape character sequences cause JSC::Lexer::parseString to create 16 bit strings - https://bugs.webkit.org/show_bug.cgi?id=100576 - - Reviewed by Darin Adler. - - Changed singleEscape() processing to be based on a lookup of a static table. The table - covers ASCII characters SPACE through DEL. If a character can be a single character escape, - then the table provides the non-zero result of that escape. Updated the result of - singleEscape to be an LChar to make the table as small as possible. - Added a new test fast/js/normal-character-escapes-in-string-literals.html to validated - the behavior. - - * parser/Lexer.cpp: - (JSC::singleEscape): - (JSC::Lexer::parseString): - (JSC::Lexer::parseStringSlowCase): - -2012-10-29 Enrica Casucci <enrica@apple.com> - - Add ENABLE_USERSELECT_ALL feature flag. - https://bugs.webkit.org/show_bug.cgi?id=100559 - - Reviewed by Eric Seidel. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-28 Filip Pizlo <fpizlo@apple.com> - - DFG should be able to emit effectful structure checks - https://bugs.webkit.org/show_bug.cgi?id=99260 - - Reviewed by Oliver Hunt. - - This change allows us to find out if an array access that has gone polymorphic - is operating over known structures - i.e. the primordial array structures of the - global object that the code block containing the array access belongs to. We - term this state "OriginalArray" for short. The fact that the access has gone - polymorphic means that the array profile will not be able to report the set of - structures it had seen - but if it can tell us that all of the structures were - primordial then it just so happens that we can deduce what the structure set - would have been by just querying the code block's global object. This allows us - to emit an ArrayifyToStructure instead of an Arrayify if we find that we need to - do conversions. The fast path of an ArrayifyToStructure is exactly like the fast - path of a CheckStructure and is mostly subject to the same optimizations. It - also burns one fewer registers. - - Essentially the notion of OriginalArray is a super cheap way of getting the - array profile to tell us a structure set instead of a singleton structure. - Currently, the array profile can only tell us the structure seen at an array - access if there was exactly one structure. If there were multiple structures, it - won't tell us anything other than the array modes and other auxiliary profiling - data (whether there were stores to holes, for example). With OriginalArray, we - cheaply get a structure set if all of the structures were primordial for the - code block's global object, since in that case the array mode set (ArrayModes) - can directly tell us the structure set. In the future, we might consider adding - complete structure sets to the array profiles, but I suspect that we would hit - diminishing returns if we did so - it would only help if we have array accesses - that are both polymorphic and are cross-global-object accesses (rare) or if the - arrays had named properties or other structure transitions that are unrelated to - indexing type (also rare). - - This also does away with Arrayify (and the new ArrayifyToStructure) returning - the butterfly pointer. This turns out to be faster and easier to CSE. - - And, this also changes constant folding to be able to eliminate CheckStructure, - ForwardCheckStructure, and ArrayifyToStructure in addition to being able to - transform them into structure transition watchpoints. This is great for - ArrayifyToStructure because then CSE and CFA know that there is no side effect. - Converting CheckStructure and ForwardCheckStructure to also behave this way is - just a matter of elegance. - - This has no performance impact right now. It's intended to alleviate some of the - regressions seen in the early implementation of - https://bugs.webkit.org/show_bug.cgi?id=98606. - - * bytecode/ArrayProfile.cpp: - (JSC::ArrayProfile::computeUpdatedPrediction): - * bytecode/ArrayProfile.h: - (JSC): - (JSC::ArrayProfile::ArrayProfile): - (ArrayProfile): - (JSC::ArrayProfile::usesOriginalArrayStructures): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::ArrayMode::fromObserved): - (JSC::DFG::ArrayMode::alreadyChecked): - (JSC::DFG::arrayClassToString): - * dfg/DFGArrayMode.h: - (JSC::DFG::ArrayMode::withProfile): - (JSC::DFG::ArrayMode::isJSArray): - (ArrayMode): - (JSC::DFG::ArrayMode::isJSArrayWithOriginalStructure): - (JSC::DFG::ArrayMode::supportsLength): - (JSC::DFG::ArrayMode::arrayModesWithIndexingShape): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getArrayMode): - (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): - (JSC::DFG::ByteCodeParser::handleGetByOffset): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::checkStructureElimination): - (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): - (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): - (JSC::DFG::CSEPhase::checkArrayElimination): - (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::checkArray): - * dfg/DFGNode.h: - (JSC::DFG::Node::hasStructure): - (JSC::DFG::Node::hasArrayMode): - (JSC::DFG::Node::arrayMode): - * dfg/DFGNodeType.h: - (DFG): - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): - (JSC::DFG::SpeculativeJIT::arrayify): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * runtime/JSGlobalObject.h: - (JSC::JSGlobalObject::isOriginalArrayStructure): - * runtime/Structure.cpp: - (JSC::Structure::nonPropertyTransition): - -2012-10-28 Filip Pizlo <fpizlo@apple.com> - - There should not be blind spots in array length array profiling - https://bugs.webkit.org/show_bug.cgi?id=100620 - - Reviewed by Oliver Hunt. - - I don't think this has any performance impact. But it's good to not have random - programs occasionally emit a GetById for array length accesses. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::compileGetByIdHotPath): - (JSC::JIT::privateCompilePatchGetArrayLength): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::compileGetByIdHotPath): - (JSC::JIT::privateCompilePatchGetArrayLength): - -2012-10-28 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, make always-true enum-to-int comparisons use casts. - - * dfg/DFGFPRInfo.h: - (JSC::DFG::FPRInfo::debugName): - * dfg/DFGGPRInfo.h: - (JSC::DFG::JSValueSource::tagGPR): - (JSC::DFG::GPRInfo::toIndex): - (JSC::DFG::GPRInfo::debugName): - * runtime/JSTypeInfo.h: - (JSC::TypeInfo::TypeInfo): - -2012-10-27 Filip Pizlo <fpizlo@apple.com> - - OSR exit compilation should defend against argument recoveries from code blocks that are no longer on the inline stack - https://bugs.webkit.org/show_bug.cgi?id=100601 - - Reviewed by Oliver Hunt. - - This happened to me while I was fixing bugs for https://bugs.webkit.org/show_bug.cgi?id=100599. - I'm not sure how to reproduce this. - - * dfg/DFGAssemblyHelpers.h: - (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor): - (AssemblyHelpers): - * dfg/DFGOSRExitCompiler32_64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - -2012-10-27 Filip Pizlo <fpizlo@apple.com> - - DFG::Array::Mode needs to be cleaned up - https://bugs.webkit.org/show_bug.cgi?id=100599 - - Reviewed by Oliver Hunt. - - Turn the previous massive Array::Mode enum into a class that contains four - fields, the type, whether it's a JSArray, the level of speculation, and the - kind of conversion to perform. - - No performance or behavioral change. - - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGArgumentsSimplificationPhase.cpp: - (JSC::DFG::ArgumentsSimplificationPhase::run): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::ArrayMode::fromObserved): - (JSC::DFG::ArrayMode::refine): - (JSC::DFG::ArrayMode::alreadyChecked): - (JSC::DFG::arrayTypeToString): - (JSC::DFG::arrayClassToString): - (DFG): - (JSC::DFG::arraySpeculationToString): - (JSC::DFG::arrayConversionToString): - (JSC::DFG::ArrayMode::toString): - * dfg/DFGArrayMode.h: - (DFG): - (ArrayMode): - (JSC::DFG::ArrayMode::ArrayMode): - (JSC::DFG::ArrayMode::type): - (JSC::DFG::ArrayMode::arrayClass): - (JSC::DFG::ArrayMode::speculation): - (JSC::DFG::ArrayMode::conversion): - (JSC::DFG::ArrayMode::asWord): - (JSC::DFG::ArrayMode::fromWord): - (JSC::DFG::ArrayMode::withSpeculation): - (JSC::DFG::ArrayMode::usesButterfly): - (JSC::DFG::ArrayMode::isJSArray): - (JSC::DFG::ArrayMode::isInBounds): - (JSC::DFG::ArrayMode::mayStoreToHole): - (JSC::DFG::ArrayMode::isOutOfBounds): - (JSC::DFG::ArrayMode::isSlowPut): - (JSC::DFG::ArrayMode::canCSEStorage): - (JSC::DFG::ArrayMode::lengthNeedsStorage): - (JSC::DFG::ArrayMode::modeForPut): - (JSC::DFG::ArrayMode::isSpecific): - (JSC::DFG::ArrayMode::supportsLength): - (JSC::DFG::ArrayMode::benefitsFromStructureCheck): - (JSC::DFG::ArrayMode::doesConversion): - (JSC::DFG::ArrayMode::arrayModesThatPassFiltering): - (JSC::DFG::ArrayMode::operator==): - (JSC::DFG::ArrayMode::operator!=): - (JSC::DFG::ArrayMode::arrayModesWithIndexingShape): - (JSC::DFG::canCSEStorage): - (JSC::DFG::lengthNeedsStorage): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getArrayMode): - (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): - (JSC::DFG::ByteCodeParser::handleIntrinsic): - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::getArrayLengthElimination): - (JSC::DFG::CSEPhase::checkArrayElimination): - (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::checkArray): - (JSC::DFG::FixupPhase::blessArrayOperation): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::byValIsPure): - * dfg/DFGNode.h: - (JSC::DFG::Node::arrayMode): - (JSC::DFG::Node::setArrayMode): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): - (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::arrayify): - (JSC::DFG::SpeculativeJIT::compileGetByValOnString): - (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): - (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): - (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): - (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): - (SpeculativeJIT): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-27 Dan Bernstein <mitz@apple.com> - - REAL_PLATFORM_NAME build setting is no longer needed - https://bugs.webkit.org/show_bug.cgi?id=100587 - - Reviewed by Mark Rowe. - - Removed the definition of REAL_PLATFORM_NAME and replaced references to it with references - to PLATFORM_NAME. - - * Configurations/Base.xcconfig: - * Configurations/CompilerVersion.xcconfig: - * Configurations/DebugRelease.xcconfig: - * Configurations/FeatureDefines.xcconfig: - * Configurations/JSC.xcconfig: - * Configurations/JavaScriptCore.xcconfig: - * Configurations/ToolExecutable.xcconfig: - -2012-10-25 Filip Pizlo <fpizlo@apple.com> - - Forward OSR calculation is wrong in the presence of multiple SetLocals, or a mix of SetLocals and Phantoms - https://bugs.webkit.org/show_bug.cgi?id=100461 - - Reviewed by Oliver Hunt and Gavin Barraclough. - - This does a couple of things. First, it removes the part of the change in r131822 that made the forward - OSR exit calculator capable of handling multiple SetLocals. That change was wrong, because it would - blindly assume that all SetLocals had the same ValueRecovery, and would ignore the possibility that if - there is no value recovery then a ForwardCheckStructure on the first SetLocal would not know how to - recover the state associated with the second SetLocal. Then, it introduces the invariant that any bytecode - op that decomposes into multiple SetLocals must first emit dead SetLocals as hints and then emit a second - set of SetLocals to actually do the setting of the locals. This means that if a ForwardCheckStructure (or - any other hoisted forward speculation) is inserted, it will always be inserted on the second set of - SetLocals (since hoisting only touches the live ones), at which point OSR will already know about the - mov hints implied by the first set of (dead) SetLocals. This gives us the behavior we wanted, namely, that - a ForwardCheckStructure applied to a variant set by a resolve_with_base-like operation can correctly do a - forward exit while also ensuring that prior to exiting we set the appropriate locals. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * 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/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): - -2012-10-26 Simon Hausmann <simon.hausmann@digia.com> - - [Qt] Fix the LLInt build on Windows - https://bugs.webkit.org/show_bug.cgi?id=97648 - - Reviewed by Tor Arne Vestbø. - - The main change for the port on Windows is changing the way offsets are extracted - and the LLIntAssembly.h is generated to accomodate release and debug configurations. - - Firstly the LLIntOffsetsExtractor binary is now built as-is (no DESTDIR set) and - placed into debug\LLIntOffsetsExtractor.exe and release\LLIntOffsetsExtractor.exe - on Windows debug_and_release builds. On other patforms it remainds in the regular - out directory. - - Secondly the LLIntAssembly.h files must be different for different build types, - so the LLIntAssembly.h generator in DerivedSources.pri operates no on the extractor - binary files as input. Using a simple exists() check we verify the presence of either - a regular, a debug\LLIntOffsetsExtractor and a release\LLIntOffsetsExtractor binary - and process all of them. The resulting assembly files consequently end up in - generated\debug\LLIntAssembly.h and generated\release\LLIntAssembly.h. - - In Target.pri we have to also make sure that those directories are in the include - path according to the release or debug configuration. - - Lastly a small tweak - swapping WTF.pri and JSC.pri inclusions - in the - LLIntOffsetsExtractor build was needed to make sure that we include - JavaScriptCore/config.h instead of WTF/config.h, required to fix the - build issues originally pasted in bug #97648. - - * DerivedSources.pri: - * JavaScriptCore.pro: - * LLIntOffsetsExtractor.pro: - * Target.pri: - -2012-10-26 Gabor Ballabas <gaborb@inf.u-szeged.hu> - - [Qt] Enable JSC's disassembler on x86, x86_64 Linux - https://bugs.webkit.org/show_bug.cgi?id=100386 - - Reviewed by Simon Hausmann. - - It works fine on Linux x86, x86_64 just needs to be enabled in the - QtWebKit build system. - - * DerivedSources.pri: - * JavaScriptCore.pri: - * Target.pri: - -2012-10-26 Thiago Marcos P. Santos <thiago.santos@intel.com> - - Add feature flags for CSS Device Adaptation - https://bugs.webkit.org/show_bug.cgi?id=95960 - - Reviewed by Kenneth Rohde Christiansen. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-26 Simon Hausmann <simon.hausmann@digia.com> - - [WIN] Make LLInt offsets extractor work on Windows - https://bugs.webkit.org/show_bug.cgi?id=100369 - - Reviewed by Kenneth Rohde Christiansen. - - Open the input file explicitly in binary mode to prevent ruby/Windows from thinking that - it's a text mode file that needs even new line conversions. The binary mode parameter is - ignored on other platforms. - - * offlineasm/offsets.rb: - -2012-10-25 Michael Saboff <msaboff@apple.com> - - SymbolTableIndexHashTraits::needsDestruction should be set to true - https://bugs.webkit.org/show_bug.cgi?id=100437 - - Reviewed by Mark Hahnenberg. - - For correctness, set SymbolTableIndexHashTraits::needsDestruction to true since SymbolTableEntry's do - need to have their destructor called due to the possibility of rare data. - - * runtime/SymbolTable.h: - (SymbolTableIndexHashTraits): - -2012-10-25 Filip Pizlo <fpizlo@apple.com> - - DFG Arrayify elimination should replace it with GetButterfly rather than Phantom - https://bugs.webkit.org/show_bug.cgi?id=100441 - - Reviewed by Oliver Hunt and Gavin Barraclough. - - Made array profiler's to-string helper behave correctly. - - Made Arrayify elimination do the right thing (convert to GetButterfly). - - Made CFA's interference analysis track clobbered array modes correctly, mostly by - simplifying the machinery. - - * bytecode/ArrayProfile.cpp: - (JSC::arrayModesToString): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::clobberArrayModes): - (AbstractValue): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - -2012-10-25 Filip Pizlo <fpizlo@apple.com> - - REGRESSION (r131793-r131826): Crash going to wikifonia.org - https://bugs.webkit.org/show_bug.cgi?id=100281 - - Reviewed by Oliver Hunt. - - Restore something that got lost in the resolve refactoring: the ability to give up on life if - we see a resolve of 'arguments'. - - * runtime/JSScope.cpp: - (JSC::JSScope::resolveContainingScopeInternal): - -2012-10-25 Dominik Röttsches <dominik.rottsches@intel.com> - - Conditionalize XHR timeout support - https://bugs.webkit.org/show_bug.cgi?id=100356 - - Reviewed by Adam Barth. - - Adding XHR_TIMEOUT feature to conditionalize this on ports without network backend support. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-25 Michael Saboff <msaboff@apple.com> - - REGRESSION (r131836): failures in list styles tests on EFL, GTK - https://bugs.webkit.org/show_bug.cgi?id=99824 - - Reviewed by Oliver Hunt. - - Saved start of string since it is modified by call convertUTF8ToUTF16(). - - * API/JSStringRef.cpp: - (JSStringCreateWithUTF8CString): - -2012-10-24 Filip Pizlo <fpizlo@apple.com> - - DFG NewArrayBuffer node should keep its data in a structure on the side to free up one of the opInfos - https://bugs.webkit.org/show_bug.cgi?id=100328 - - Reviewed by Oliver Hunt. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGGraph.h: - (Graph): - * dfg/DFGNode.h: - (NewArrayBufferData): - (DFG): - (JSC::DFG::Node::newArrayBufferData): - (Node): - (JSC::DFG::Node::startConstant): - (JSC::DFG::Node::numConstants): - -2012-10-25 Mark Lam <mark.lam@apple.com> - - Update the C++ llint to work with the latest op_resolve... changes. - https://bugs.webkit.org/show_bug.cgi?id=100345. - - Reviewed by Oliver Hunt. - - * llint/LowLevelInterpreter.cpp: - (JSC::CLoop::execute): - - emit opcode name as label when not using COMPUTED_GOTOs. The new op_resolve - opcodes have jumps to these labels. - - declare all opcode labels as UNUSED_LABEL()s to keep the compiler happy - for opcodes that are not referenced by anyone. - * offlineasm/asm.rb: - - strip llint_ prefix from opcode names used as labels. - -2012-10-24 Yuqiang Xian <yuqiang.xian@intel.com> - - Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations - https://bugs.webkit.org/show_bug.cgi?id=100321 - - Reviewed by Filip Pizlo. - - We have refactored the MacroAssembler and JIT compilers to distinguish - the pointer operations from the 64-bit integer operations (see bug #99154). - Now we want to do the similar work for LLInt, and the goal is same as - the one mentioned in 99154. - - This is the first part of the modification: in the offline assembler, - adding the support of the "<foo>q" instructions which will be used for - 64-bit integer operations. - - * llint/LowLevelInterpreter.cpp: - (JSC::CLoop::execute): - * offlineasm/cloop.rb: - * offlineasm/instructions.rb: - * offlineasm/x86.rb: - -2012-10-24 Filip Pizlo <fpizlo@apple.com> - - DFG compileBlahBlahByVal methods for Contiguous and ArrayStorage have only one caller and should be removed - https://bugs.webkit.org/show_bug.cgi?id=100311 - - Reviewed by Mark Hahnenberg. - - Just trying to simplify things before I make them more complicated again. - - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): - * dfg/DFGSpeculativeJIT32_64.cpp: - (DFG): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (DFG): - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-23 Andreas Kling <kling@webkit.org> - - CodeBlock: Give m_putToBaseOperations an inline capacity. - <http://webkit.org/b/100190> - <rdar://problem/12562466> - - Reviewed by Oliver Hunt. - - Since the CodeBlock constructor always inserts a single PutToBaseOperation, but there's no - guarantee that more will follow, give the m_putToBaseOperations vector an inline capacity of 1. - There are 4009 of these Vectors on Membuster3, and only 126 of them have more than a single entry. - - This change yields a 1.90MB reduction in memory usage. - - * bytecode/CodeBlock.h: - (CodeBlock): - -2012-10-23 Christophe Dumez <christophe.dumez@intel.com> - - Regression(r132143): Assertion hit in JSC::Interpreter::StackPolicy::StackPolicy(JSC::Interpreter&, const WTF::StackBounds&) - https://bugs.webkit.org/show_bug.cgi?id=100109 - - Reviewed by Oliver Hunt. - - Fix possible integer overflow in StackPolicy constructor by - using size_t type instead of int for stack sizes. The value - returned by StackBounds::size() is of type size_t but was - assigned to an int, which may overflow. - - * interpreter/Interpreter.cpp: - (JSC): - (JSC::Interpreter::StackPolicy::StackPolicy): - -2012-10-23 Carlos Garcia Campos <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing header file. - -2012-10-23 Mark Lam <mark.lam@apple.com> - - Make topCallFrame reliable. - https://bugs.webkit.org/show_bug.cgi?id=98928. - - Reviewed by Geoffrey Garen. - - - VM entry points and the GC now uses topCallFrame. - - The callerFrame value in CallFrames are now always the previous - frame on the stack, except for the first frame which has a - callerFrame of 0 (not counting the HostCallFrameFlag). - Hence, we can now traverse every frame on the stack all the way - back to the first frame. - - GlobalExec's will no longer be used as the callerFrame values in - call frames. - - Added fences and traps for debugging the JSStack in debug builds. - - * bytecode/SamplingTool.h: - (SamplingTool): - (JSC::SamplingTool::CallRecord::CallRecord): - * dfg/DFGOperations.cpp: - - Fixed 2 DFG helper functions to flush topCallFrame as expected. - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::prepareForExternalCall): - * interpreter/CallFrame.h: - (JSC::ExecState::callerFrameNoFlags): - (ExecState): - (JSC::ExecState::argIndexForRegister): - (JSC::ExecState::getArgumentUnsafe): - * interpreter/CallFrameClosure.h: - (CallFrameClosure): - * interpreter/Interpreter.cpp: - (JSC): - (JSC::eval): - (JSC::Interpreter::Interpreter): - (JSC::Interpreter::throwException): - (JSC::Interpreter::execute): - (JSC::Interpreter::executeCall): - (JSC::Interpreter::executeConstruct): - (JSC::Interpreter::prepareForRepeatCall): - (JSC::Interpreter::endRepeatCall): - * interpreter/Interpreter.h: - (JSC): - (Interpreter): - * interpreter/JSStack.cpp: - (JSC::JSStack::JSStack): - (JSC::JSStack::gatherConservativeRoots): - (JSC::JSStack::disableErrorStackReserve): - * interpreter/JSStack.h: - (JSC): - (JSStack): - (JSC::JSStack::installFence): - (JSC::JSStack::validateFence): - (JSC::JSStack::installTrapsAfterFrame): - * interpreter/JSStackInlines.h: Added. - (JSC): - (JSC::JSStack::getTopOfFrame): - (JSC::JSStack::getTopOfStack): - (JSC::JSStack::getStartOfFrame): - (JSC::JSStack::pushFrame): - (JSC::JSStack::popFrame): - (JSC::JSStack::generateFenceValue): - (JSC::JSStack::installFence): - (JSC::JSStack::validateFence): - (JSC::JSStack::installTrapsAfterFrame): - * jit/JITStubs.cpp: - (JSC::jitCompileFor): - (JSC::lazyLinkFor): - - Set frame->codeBlock to 0 for both the above because they are called - with partially intitialized frames (cb uninitialized), but may - trigger a GC. - (JSC::DEFINE_STUB_FUNCTION): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - -2012-10-22 Filip Pizlo <fpizlo@apple.com> - - DFG::Array::Undecided should be called DFG::Array::SelectUsingPredictions - https://bugs.webkit.org/show_bug.cgi?id=100052 - - Reviewed by Oliver Hunt. - - No functional change, just renaming. It's a clearer name that more accurately - reflects the meaning, and it eliminates the namespace confusion that will happen - with the Undecided indexing type in https://bugs.webkit.org/show_bug.cgi?id=98606 - - * 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): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::blessArrayOperation): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::arrayify): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-22 Mark Lam <mark.lam@apple.com> - - Change stack recursion checks to be based on stack availability. - https://bugs.webkit.org/show_bug.cgi?id=99872. - - Reviewed by Filip Pizlo and Geoffrey Garen. - - - Remove m_reentryDepth, ThreadStackType which are now obsolete. - - Replaced the reentryDepth checks with a StackBounds check. - - Added the Interpreter::StackPolicy class to compute a reasonable - stack capacity requirement given the native stack that the - interpreter is executing on at that time. - - Reserved an amount of JSStack space for the use of error handling - and enable its use (using Interpreter::ErrorHandlingMode) when - we're about to throw or report an exception. - - Interpreter::StackPolicy also allows more native stack space - to be used when in ErrorHandlingMode. This is needed in the case - of native stack overflows. - - Fixed the parser so that it throws a StackOverflowError instead of - a SyntaxError when it encounters a stack overflow. - - * API/JSContextRef.cpp: - (JSContextGroupCreate): - (JSGlobalContextCreateInGroup): - * JavaScriptCore.order: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - * interpreter/Interpreter.cpp: - (JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode): - (JSC): - (JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode): - (JSC::Interpreter::StackPolicy::StackPolicy): - (JSC::Interpreter::Interpreter): - (JSC::Interpreter::execute): - (JSC::Interpreter::executeCall): - (JSC::Interpreter::executeConstruct): - (JSC::Interpreter::prepareForRepeatCall): - * interpreter/Interpreter.h: - (JSC): - (Interpreter): - (ErrorHandlingMode): - (StackPolicy): - (JSC::Interpreter::StackPolicy::requiredCapacity): - * interpreter/JSStack.cpp: - (JSC): - (JSC::JSStack::JSStack): - (JSC::JSStack::growSlowCase): - (JSC::JSStack::enableErrorStackReserve): - (JSC::JSStack::disableErrorStackReserve): - * interpreter/JSStack.h: - (JSStack): - (JSC::JSStack::reservationEnd): - (JSC): - * jsc.cpp: - (jscmain): - * parser/Parser.cpp: - (JSC::::Parser): - * parser/Parser.h: - (Parser): - (JSC::::parse): - * runtime/ExceptionHelpers.cpp: - (JSC::throwStackOverflowError): - * runtime/JSGlobalData.cpp: - (JSC::JSGlobalData::JSGlobalData): - (JSC::JSGlobalData::createContextGroup): - (JSC::JSGlobalData::create): - (JSC::JSGlobalData::createLeaked): - (JSC::JSGlobalData::sharedInstance): - * runtime/JSGlobalData.h: - (JSC): - (JSGlobalData): - * runtime/StringRecursionChecker.h: - (JSC::StringRecursionChecker::performCheck): - * testRegExp.cpp: - (realMain): - -2012-10-20 Martin Robinson <mrobinson@igalia.com> - - Fix 'make dist' for the GTK+ port - - * GNUmakefile.list.am: Add missing files to the source list. - -2012-10-21 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> - - [CMake][JSC] Depend on risc.rb to decide when to run the LLInt scripts. - https://bugs.webkit.org/show_bug.cgi?id=99917 - - Reviewed by Geoffrey Garen. - - Depend on the newly-added risc.rb to make sure we always run the - LLInt scripts when one of them changes. - - * CMakeLists.txt: - -2012-10-20 Filip Pizlo <fpizlo@apple.com> - - LLInt backends of non-ARM RISC platforms should be able to share code with the existing ARMv7 backend - https://bugs.webkit.org/show_bug.cgi?id=99745 - - Reviewed by Geoffrey Garen. - - This moves all of the things in armv7.rb that I thought are generally useful out - into risc.rb. It also separates some phases (branch ops is separated into one - phase that does sensible things, and another that does things that are painfully - ARM-specific), and removes ARM assumptions from others by using a callback to - drive exactly what lowering must happen. The goal here is to minimize the future - maintenance burden of LLInt by ensuring that the various platforms share as much - lowering code as possible. - - * offlineasm/armv7.rb: - * offlineasm/risc.rb: Added. - -2012-10-19 Filip Pizlo <fpizlo@apple.com> - - DFG should have some facility for recognizing redundant CheckArrays and Arrayifies - https://bugs.webkit.org/show_bug.cgi?id=99287 - - Reviewed by Mark Hahnenberg. - - Adds reasoning about indexing type sets (i.e. ArrayModes) to AbstractValue, which - then enables us to fold away CheckArray's and Arrayify's that are redundant. - - * bytecode/ArrayProfile.cpp: - (JSC::arrayModesToString): - (JSC): - * bytecode/ArrayProfile.h: - (JSC): - (JSC::mergeArrayModes): - (JSC::arrayModesAlreadyChecked): - * bytecode/StructureSet.h: - (JSC::StructureSet::arrayModesFromStructures): - (StructureSet): - * dfg/DFGAbstractState.cpp: - (JSC::DFG::AbstractState::execute): - * dfg/DFGAbstractValue.h: - (JSC::DFG::AbstractValue::AbstractValue): - (JSC::DFG::AbstractValue::clear): - (JSC::DFG::AbstractValue::isClear): - (JSC::DFG::AbstractValue::makeTop): - (JSC::DFG::AbstractValue::clobberStructures): - (AbstractValue): - (JSC::DFG::AbstractValue::setMostSpecific): - (JSC::DFG::AbstractValue::set): - (JSC::DFG::AbstractValue::operator==): - (JSC::DFG::AbstractValue::merge): - (JSC::DFG::AbstractValue::filter): - (JSC::DFG::AbstractValue::filterArrayModes): - (JSC::DFG::AbstractValue::validate): - (JSC::DFG::AbstractValue::checkConsistency): - (JSC::DFG::AbstractValue::dump): - (JSC::DFG::AbstractValue::clobberArrayModes): - (JSC::DFG::AbstractValue::clobberArrayModesSlow): - (JSC::DFG::AbstractValue::setFuturePossibleStructure): - (JSC::DFG::AbstractValue::filterFuturePossibleStructure): - * dfg/DFGArrayMode.cpp: - (JSC::DFG::modeAlreadyChecked): - * dfg/DFGArrayMode.h: - (JSC::DFG::arrayModesFor): - (DFG): - * dfg/DFGConstantFoldingPhase.cpp: - (JSC::DFG::ConstantFoldingPhase::foldConstants): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::arrayify): - -2012-10-19 Filip Pizlo <fpizlo@apple.com> - - Baseline JIT should not inline array allocations, to make them easier to instrument - https://bugs.webkit.org/show_bug.cgi?id=99905 - - Reviewed by Mark Hahnenberg. - - This will make it easier to instrument array allocations for the purposes of profiling. - It also allows us to kill off a bunch of code. And, this doesn't appear to hurt - performance at all. That's expected because these days any hot allocation will end up - in the DFG JIT, which does inline these allocations. - - * jit/JIT.cpp: - (JSC::JIT::privateCompileSlowCases): - * jit/JIT.h: - (JIT): - * jit/JITInlineMethods.h: - (JSC): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_new_array): - -2012-10-19 Oliver Hunt <oliver@apple.com> - - Fix some of the regression cause by the non-local variable reworking - https://bugs.webkit.org/show_bug.cgi?id=99896 - - Reviewed by Filip Pizlo. - - The non0local variable reworking led to some of the optimisations performed by - the bytecode generator being dropped. This in turn put more pressure on the DFG - optimisations. This exposed a short coming in our double speculation propogation. - Now we try to distinguish between places where we should SpecDoubleReal vs generic - SpecDouble. - - * dfg/DFGPredictionPropagationPhase.cpp: - (PredictionPropagationPhase): - (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction): - (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPredictions): - (JSC::DFG::PredictionPropagationPhase::propagate): - -2012-10-19 Michael Saboff <msaboff@apple.com> - - Lexer should create 8 bit Identifiers for RegularExpressions and ASCII identifiers - https://bugs.webkit.org/show_bug.cgi?id=99855 - - Reviewed by Filip Pizlo. - - Added makeIdentifier helpers that will always make an 8 bit Identifier or make an - Identifier that is the same size as the template parameter. Used the first in the fast - path when looking for a JS identifier and the second when scanning regular expressions. - - * parser/Lexer.cpp: - (JSC::::scanRegExp): - * parser/Lexer.h: - (Lexer): - (JSC::::makeIdentifierSameType): - (JSC::::makeLCharIdentifier): - (JSC::::lexExpectIdentifier): - -2012-10-19 Mark Lam <mark.lam@apple.com> - - Added WTF::StackStats mechanism. - https://bugs.webkit.org/show_bug.cgi?id=99805. - - Reviewed by Geoffrey Garen. - - Added StackStats checkpoints and probes. - - * bytecompiler/BytecodeGenerator.h: - (JSC::BytecodeGenerator::emitNode): - (JSC::BytecodeGenerator::emitNodeInConditionContext): - * heap/SlotVisitor.cpp: - (JSC::SlotVisitor::append): - (JSC::visitChildren): - (JSC::SlotVisitor::donateKnownParallel): - (JSC::SlotVisitor::drain): - (JSC::SlotVisitor::drainFromShared): - (JSC::SlotVisitor::mergeOpaqueRoots): - (JSC::SlotVisitor::internalAppend): - (JSC::SlotVisitor::harvestWeakReferences): - (JSC::SlotVisitor::finalizeUnconditionalFinalizers): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::execute): - (JSC::Interpreter::executeCall): - (JSC::Interpreter::executeConstruct): - (JSC::Interpreter::prepareForRepeatCall): - * parser/Parser.h: - (JSC::Parser::canRecurse): - * runtime/StringRecursionChecker.h: - (StringRecursionChecker): - -2012-10-19 Oliver Hunt <oliver@apple.com> - - REGRESSION(r131822): It made 500+ tests crash on 32 bit platforms - https://bugs.webkit.org/show_bug.cgi?id=99814 - - Reviewed by Filip Pizlo. - - Call the correct macro in 32bit. - - * llint/LowLevelInterpreter.asm: - -2012-10-19 Dongwoo Joshua Im <dw.im@samsung.com> - - Rename ENABLE_CSS3_TEXT_DECORATION to ENABLE_CSS3_TEXT - https://bugs.webkit.org/show_bug.cgi?id=99804 - - Reviewed by Julien Chaffraix. - - CSS3 text related properties will be implemented under this flag, - including text decoration, text-align-last, and text-justify. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-18 Anders Carlsson <andersca@apple.com> - - Clean up RegExpKey - https://bugs.webkit.org/show_bug.cgi?id=99798 - - Reviewed by Darin Adler. - - RegExpHash doesn't need to be a class template specialization when the class template is specialized - for JSC::RegExpKey only. Make it a nested class of RegExp instead. Also, make operator== a friend function - so Hash::equal can see it. - - * runtime/RegExpKey.h: - (JSC::RegExpKey::RegExpKey): - (JSC::RegExpKey::operator==): - (RegExpKey): - (JSC::RegExpKey::Hash::hash): - (JSC::RegExpKey::Hash::equal): - (Hash): - -2012-10-19 Mark Lam <mark.lam@apple.com> - - Bot greening: Follow up to r131877 to fix the Windows build. - https://bugs.webkit.org/show_bug.cgi?id=99739. - - Not reviewed. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-10-19 Mark Lam <mark.lam@apple.com> - - Bot greening: Attempt to fix broken Window build after r131836. - https://bugs.webkit.org/show_bug.cgi?id=99739. - - Not reviewed. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-10-19 Yuqiang Xian <yuqiang.xian@intel.com> - - Unreviewed fix after r131868. - - On JSVALUE64 platforms, JSValue constants can be Imm64 instead of ImmPtr for JIT compilers. - - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - -2012-10-18 Filip Pizlo <fpizlo@apple.com> - - Baseline array profiling should be less accurate, and DFG OSR exit should update array profiles on CheckArray and CheckStructure failure - https://bugs.webkit.org/show_bug.cgi?id=99261 - - Reviewed by Oliver Hunt. - - This makes array profiling stochastic, like value profiling. The point is to avoid - noticing one-off indexing types that we'll never see again, but instead to: - - Notice the big ones: We want the DFG to compile based on the things that happen with - high probability. So, this change makes array profiling do like value profiling and - only notice a random subsampling of indexing types that flowed through an array - access. Prior to this patch array profiles noticed all indexing types and weighted - them identically. - - Bias the recent: Often an array access will see awkward indexing types during the - first handful of executions because of artifacts of program startup. So, we want to - bias towards the indexing types that we saw most recently. With this change, array - profiling does like value profiling and usually tells use a random sampling that - is biased to what happened recently. - - Have a backup plan: The above two things don't work by themselves because our - randomness is not that random (nor do we care enough to make it more random), and - because some procedures will have a <1/10 probability event that we must handle - without bailing because it dominates a hot loop. So, like value profiling, this - patch makes array profiling use OSR exits to tell us why we are bailing out, so - that we don't make the same mistake again in the future. - - This change also makes the way that the 32-bit OSR exit compiler snatches scratch - registers more uniform. We don't need a scratch buffer when we can push and pop. - - * bytecode/DFGExitProfile.h: - * dfg/DFGOSRExitCompiler32_64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::arrayify): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JITInlineMethods.h: - (JSC::JIT::emitArrayProfilingSite): - * llint/LowLevelInterpreter.asm: - -2012-10-18 Yuqiang Xian <yuqiang.xian@intel.com> - - [Qt] REGRESSION(r131858): It broke the ARM build - https://bugs.webkit.org/show_bug.cgi?id=99809 - - Reviewed by Csaba Osztrogonác. - - * dfg/DFGCCallHelpers.h: - (CCallHelpers): - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - -2012-10-18 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 - - Reviewed by Gavin Barraclough. - - 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 second part of the work, i.e, to correct the usage of the - new MacroAssembler interfaces in the JIT compilers, which also means - that now EncodedJSValue is defined as a 64-bit integer, and the "*64" - interfaces are used for it. - - * assembler/MacroAssembler.h: JSValue immediates should be in Imm64 instead of ImmPtr. - (MacroAssembler): - (JSC::MacroAssembler::shouldBlind): - * dfg/DFGAssemblyHelpers.cpp: Correct the JIT compilers usage of the new interfaces. - (JSC::DFG::AssemblyHelpers::jitAssertIsInt32): - (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32): - (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber): - (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble): - (JSC::DFG::AssemblyHelpers::jitAssertIsCell): - * dfg/DFGAssemblyHelpers.h: - (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader): - (JSC::DFG::AssemblyHelpers::branchIfNotCell): - (JSC::DFG::AssemblyHelpers::debugCall): - (JSC::DFG::AssemblyHelpers::boxDouble): - (JSC::DFG::AssemblyHelpers::unboxDouble): - (JSC::DFG::AssemblyHelpers::emitExceptionCheck): - * dfg/DFGCCallHelpers.h: - (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): - (CCallHelpers): - * dfg/DFGOSRExitCompiler64.cpp: - (JSC::DFG::OSRExitCompiler::compileExit): - * dfg/DFGRepatch.cpp: - (JSC::DFG::generateProtoChainAccessStub): - (JSC::DFG::tryCacheGetByID): - (JSC::DFG::tryBuildGetByIDList): - (JSC::DFG::emitPutReplaceStub): - (JSC::DFG::emitPutTransitionStub): - * dfg/DFGScratchRegisterAllocator.h: - (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): - (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): - * dfg/DFGSilentRegisterSavePlan.h: - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArgumentTypes): - (JSC::DFG::SpeculativeJIT::compileValueToInt32): - (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): - (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): - (JSC::DFG::SpeculativeJIT::compileInstanceOf): - (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant): - (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): - * dfg/DFGSpeculativeJIT.h: - (SpeculativeJIT): - (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): - (JSC::DFG::SpeculativeJIT::silentSpill): - (JSC::DFG::SpeculativeJIT::silentFill): - (JSC::DFG::SpeculativeJIT::spill): - (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64): - (JSC::DFG::SpeculativeJIT::callOperation): - (JSC::DFG::SpeculativeJIT::branch64): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::fillInteger): - (JSC::DFG::SpeculativeJIT::fillDouble): - (JSC::DFG::SpeculativeJIT::fillJSValue): - (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber): - (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32): - (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): - (JSC::DFG::SpeculativeJIT::cachedGetById): - (JSC::DFG::SpeculativeJIT::cachedPutById): - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): - (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): - (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): - (JSC::DFG::SpeculativeJIT::emitCall): - (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): - (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): - (JSC::DFG::SpeculativeJIT::fillSpeculateCell): - (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): - (JSC::DFG::SpeculativeJIT::convertToDouble): - (JSC::DFG::SpeculativeJIT::compileObjectEquality): - (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): - (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): - (JSC::DFG::SpeculativeJIT::compileDoubleCompare): - (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): - (JSC::DFG::SpeculativeJIT::compileLogicalNot): - (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): - (JSC::DFG::SpeculativeJIT::emitBranch): - (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): - (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): - (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): - (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGThunks.cpp: - (JSC::DFG::osrExitGenerationThunkGenerator): - (JSC::DFG::throwExceptionFromCallSlowPathGenerator): - (JSC::DFG::slowPathFor): - (JSC::DFG::virtualForThunkGenerator): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::dumpRegisters): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - * jit/JIT.h: - (JIT): - * jit/JITArithmetic.cpp: - (JSC::JIT::emit_op_negate): - (JSC::JIT::emitSlow_op_negate): - (JSC::JIT::emit_op_rshift): - (JSC::JIT::emitSlow_op_urshift): - (JSC::JIT::emit_compareAndJumpSlow): - (JSC::JIT::emit_op_bitand): - (JSC::JIT::compileBinaryArithOpSlowCase): - (JSC::JIT::emit_op_div): - * jit/JITCall.cpp: - (JSC::JIT::compileLoadVarargs): - (JSC::JIT::compileCallEval): - (JSC::JIT::compileCallEvalSlowCase): - (JSC::JIT::compileOpCall): - * jit/JITInlineMethods.h: Have some clean-up work as well. - (JSC): - (JSC::JIT::emitPutCellToCallFrameHeader): - (JSC::JIT::emitPutIntToCallFrameHeader): - (JSC::JIT::emitPutToCallFrameHeader): - (JSC::JIT::emitGetFromCallFrameHeader32): - (JSC::JIT::emitGetFromCallFrameHeader64): - (JSC::JIT::emitAllocateJSArray): - (JSC::JIT::emitValueProfilingSite): - (JSC::JIT::emitGetJITStubArg): - (JSC::JIT::emitGetVirtualRegister): - (JSC::JIT::emitPutVirtualRegister): - (JSC::JIT::emitInitRegister): - (JSC::JIT::emitJumpIfJSCell): - (JSC::JIT::emitJumpIfBothJSCells): - (JSC::JIT::emitJumpIfNotJSCell): - (JSC::JIT::emitLoadInt32ToDouble): - (JSC::JIT::emitJumpIfImmediateInteger): - (JSC::JIT::emitJumpIfNotImmediateInteger): - (JSC::JIT::emitJumpIfNotImmediateIntegers): - (JSC::JIT::emitFastArithReTagImmediate): - (JSC::JIT::emitFastArithIntToImmNoCheck): - * jit/JITOpcodes.cpp: - (JSC::JIT::privateCompileCTINativeCall): - (JSC::JIT::emit_op_mov): - (JSC::JIT::emit_op_instanceof): - (JSC::JIT::emit_op_is_undefined): - (JSC::JIT::emit_op_is_boolean): - (JSC::JIT::emit_op_is_number): - (JSC::JIT::emit_op_tear_off_activation): - (JSC::JIT::emit_op_not): - (JSC::JIT::emit_op_jfalse): - (JSC::JIT::emit_op_jeq_null): - (JSC::JIT::emit_op_jneq_null): - (JSC::JIT::emit_op_jtrue): - (JSC::JIT::emit_op_bitxor): - (JSC::JIT::emit_op_bitor): - (JSC::JIT::emit_op_get_pnames): - (JSC::JIT::emit_op_next_pname): - (JSC::JIT::compileOpStrictEq): - (JSC::JIT::emit_op_catch): - (JSC::JIT::emit_op_throw_static_error): - (JSC::JIT::emit_op_eq_null): - (JSC::JIT::emit_op_neq_null): - (JSC::JIT::emit_op_create_activation): - (JSC::JIT::emit_op_create_arguments): - (JSC::JIT::emit_op_init_lazy_reg): - (JSC::JIT::emitSlow_op_convert_this): - (JSC::JIT::emitSlow_op_not): - (JSC::JIT::emit_op_get_argument_by_val): - (JSC::JIT::emit_op_put_to_base): - (JSC::JIT::emit_resolve_operations): - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emit_op_get_by_val): - (JSC::JIT::emitContiguousGetByVal): - (JSC::JIT::emitArrayStorageGetByVal): - (JSC::JIT::emitSlow_op_get_by_val): - (JSC::JIT::compileGetDirectOffset): - (JSC::JIT::emit_op_get_by_pname): - (JSC::JIT::emitContiguousPutByVal): - (JSC::JIT::emitArrayStoragePutByVal): - (JSC::JIT::compileGetByIdHotPath): - (JSC::JIT::emit_op_put_by_id): - (JSC::JIT::compilePutDirectOffset): - (JSC::JIT::emit_op_init_global_const): - (JSC::JIT::emit_op_init_global_const_check): - (JSC::JIT::emitIntTypedArrayGetByVal): - (JSC::JIT::emitFloatTypedArrayGetByVal): - (JSC::JIT::emitFloatTypedArrayPutByVal): - * jit/JITStubCall.h: - (JITStubCall): - (JSC::JITStubCall::JITStubCall): - (JSC::JITStubCall::addArgument): - (JSC::JITStubCall::call): - (JSC::JITStubCall::callWithValueProfiling): - * jit/JSInterfaceJIT.h: - (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): - (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): - (JSC::JSInterfaceJIT::emitLoadJSCell): - (JSC::JSInterfaceJIT::emitLoadInt32): - (JSC::JSInterfaceJIT::emitLoadDouble): - * jit/SpecializedThunkJIT.h: - (JSC::SpecializedThunkJIT::returnDouble): - (JSC::SpecializedThunkJIT::tagReturnAsInt32): - * runtime/JSValue.cpp: - (JSC::JSValue::description): - * runtime/JSValue.h: Define JSVALUE64 EncodedJSValue as int64_t, which is also unified with JSVALUE32_64. - (JSC): - * runtime/JSValueInlineMethods.h: New implementation of some JSValue methods to make them more conformant - with the new rule that "JSValue is a 64-bit integer rather than a pointer" for JSVALUE64 platforms. - (JSC): - (JSC::JSValue::JSValue): - (JSC::JSValue::operator bool): - (JSC::JSValue::operator==): - (JSC::JSValue::operator!=): - (JSC::reinterpretDoubleToInt64): - (JSC::reinterpretInt64ToDouble): - (JSC::JSValue::asDouble): - -2012-10-18 Michael Saboff <msaboff@apple.com> - - convertUTF8ToUTF16() Should Check for ASCII Input - ihttps://bugs.webkit.org/show_bug.cgi?id=99739 - - Reviewed by Geoffrey Garen. - - Using the updated convertUTF8ToUTF16() , we can determine if is makes more sense to - create a string using the 8 bit source. Added a new OpaqueJSString::create(LChar*, unsigned). - Had to add a cast n JSStringCreateWithCFString to differentiate which create() to call. - - * API/JSStringRef.cpp: - (JSStringCreateWithUTF8CString): - * API/JSStringRefCF.cpp: - (JSStringCreateWithCFString): - * API/OpaqueJSString.h: - (OpaqueJSString::create): - (OpaqueJSString): - (OpaqueJSString::OpaqueJSString): - -2012-10-18 Oliver Hunt <oliver@apple.com> - - Unbreak jsc tests. Last minute "clever"-ness is clearly just not - a good plan. - - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - -2012-10-18 Oliver Hunt <oliver@apple.com> - - Bytecode should not have responsibility for determining how to perform non-local resolves - https://bugs.webkit.org/show_bug.cgi?id=99349 - - Reviewed by Gavin Barraclough. - - 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. - - 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. - - 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". - - Basic browsing seems to work. - - * GNUmakefile.list.am: - * 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/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/ResolveGlobalStatus.cpp: - (JSC::computeForStructure): - (JSC::ResolveGlobalStatus::computeFor): - * bytecode/ResolveGlobalStatus.h: - (JSC): - (ResolveGlobalStatus): - * bytecompiler/BytecodeGenerator.cpp: - (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::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::canInlineResolveOperations): - (DFG): - (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::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_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_put_to_base): - (JSC): - * 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: - * 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::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): - * runtime/JSVariableObject.h: - (JSVariableObject): - * runtime/Structure.h: - (JSC::Structure::propertyAccessesAreCacheable): - (Structure): - -2012-10-18 Mark Hahnenberg <mhahnenberg@apple.com> - - Live oversize copied blocks should count toward overall heap fragmentation - https://bugs.webkit.org/show_bug.cgi?id=99548 - - Reviewed by Filip Pizlo. - - The CopiedSpace uses overall heap fragmentation to determine whether or not it should do any copying. - Currently it doesn't include live oversize CopiedBlocks in the calculation, but it should. We should - treat them as 100% utilized, since running a copying phase won't be able to free/compact any of their - memory. We can also free any dead oversize CopiedBlocks while we're iterating over them, rather than - iterating over them again at the end of the copying phase. - - * heap/CopiedSpace.cpp: - (JSC::CopiedSpace::doneFillingBlock): - (JSC::CopiedSpace::startedCopying): - (JSC::CopiedSpace::doneCopying): Also removed a branch when iterating over from-space at the end of - copying. Since we eagerly recycle blocks as soon as they're fully evacuated, we should see no - unpinned blocks in from-space at the end of copying. - * heap/CopiedSpaceInlineMethods.h: - (JSC::CopiedSpace::recycleBorrowedBlock): - * heap/CopyVisitorInlineMethods.h: - (JSC::CopyVisitor::checkIfShouldCopy): - -2012-10-18 Roger Fong <roger_fong@apple.com> - - Unreviewed. Build fix after r131701 and r131777. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-10-18 Mark Hahnenberg <mhahnenberg@apple.com> - - Race condition between GCThread and main thread during copying phase - https://bugs.webkit.org/show_bug.cgi?id=99641 - - Reviewed by Filip Pizlo. - - When a GCThread returns from copyFromShared(), it then calls doneCopying(), which returns - its borrowed CopiedBlock to the CopiedSpace. This final block allows the CopiedSpace to - continue and finish the cleanup of the copying phase. However, the GCThread can loop back - around, see that m_currentPhase is still "Copy", and try to go through the copying phase again. - This can cause all sorts of issues. To fix this, we should add a cyclic barrier to GCThread::waitForNextPhase(). - - * heap/GCThread.cpp: - (JSC::GCThread::waitForNextPhase): All GCThreads will wait when they finish one iteration until the main thread - notifies them to move down to the second while loop, where they wait for the next GCPhase to start. They also - decrement the m_numberOfActiveGCThreads counter as they begin to wait for the next phase and increment it as - they enter the next phase. This allows the main thread to wait in endCurrentPhase() until all the threads have - finished the current phase and are waiting on the next phase to begin. Without the counter, there would be - no way to ensure that every thread was available for each GCPhase. - (JSC::GCThread::gcThreadMain): We now use the m_phaseLock to synchronize with the main thread when we're being created. - * heap/GCThreadSharedData.cpp: - (JSC::GCThreadSharedData::GCThreadSharedData): As we create each GCThread, we increment the m_numberOfActiveGCThreads - counter. When we are done creating the threads, we wait until they're all waiting for the next GCPhase. This prevents - us from leaving some GCThreads behind during the first GCPhase, which could hurt us on our very short-running - benchmarks (e.g. SunSpider). - (JSC::GCThreadSharedData::~GCThreadSharedData): - (JSC::GCThreadSharedData::startNextPhase): We atomically swap the two flags, m_gcThreadsShouldWait and m_currentPhase, - so that if the threads finish very quickly, they will wait until the main thread is ready to end the current phase. - (JSC::GCThreadSharedData::endCurrentPhase): Here atomically we swap the two flags again to allow the threads to - advance to waiting on the next GCPhase. We wait until all of the GCThreads have settled into the second wait loop - before allowing the main thread to continue. This prevents us from leaving one of the GCThreads stuck in the first - wait loop if we were to call startNextPhase() before it had time to wake up and move on to the second wait loop. - (JSC): - (JSC::GCThreadSharedData::didStartMarking): We now use startNextPhase() to properly swap the flags. - (JSC::GCThreadSharedData::didFinishMarking): Ditto for endCurrentPhase(). - (JSC::GCThreadSharedData::didStartCopying): Ditto. - (JSC::GCThreadSharedData::didFinishCopying): Ditto. - * heap/GCThreadSharedData.h: - (GCThreadSharedData): - * heap/Heap.cpp: - (JSC::Heap::copyBackingStores): No reason to use the extra reference. - -2012-10-18 Pablo Flouret <pablof@motorola.com> - - Implement css3-conditional's @supports rule - https://bugs.webkit.org/show_bug.cgi?id=86146 - - Reviewed by Antti Koivisto. - - * Configurations/FeatureDefines.xcconfig: - Add an ENABLE_CSS3_CONDITIONAL_RULES flag. - -2012-10-18 Michael Saboff <msaboff@apple.com> - - Make conversion between JSStringRef and WKStringRef work without character size conversions - https://bugs.webkit.org/show_bug.cgi?id=99727 - - Reviewed by Anders Carlsson. - - Export the string() method for use in WebKit. - - * API/OpaqueJSString.h: - (OpaqueJSString::string): - -2012-10-18 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> - - [CMake] Avoid unnecessarily running the LLInt generation commands. - https://bugs.webkit.org/show_bug.cgi?id=99708 - - Reviewed by Rob Buis. - - As described in the comments in the change itself, in some cases - the Ruby generation scripts used when LLInt is on would each be - run twice in every build even if nothing had changed. - - Fix that by not setting the OBJECT_DEPENDS property of some source - files to depend on the generated headers; instead, they are now - just part of the final binaries/libraries which use them. - - * CMakeLists.txt: - -2012-10-17 Zoltan Horvath <zoltan@webkit.org> - - Remove the JSHeap memory measurement of the PageLoad performacetests since it creates bogus JSGlobalDatas - https://bugs.webkit.org/show_bug.cgi?id=99609 - - Reviewed by Ryosuke Niwa. - - Remove the implementation since it creates bogus JSGlobalDatas in the layout tests. - - * heap/HeapStatistics.cpp: - (JSC): - * heap/HeapStatistics.h: - (HeapStatistics): - -2012-10-17 Sam Weinig <sam@webkit.org> - - Attempt to fix the build. - - * bytecode/GlobalResolveInfo.h: Copied from bytecode/GlobalResolveInfo.h. - -2012-10-17 Filip Pizlo <fpizlo@apple.com> - - REGRESSION (r130826 or r130828): Twitter top bar is dysfunctional - https://bugs.webkit.org/show_bug.cgi?id=99577 - <rdar://problem/12518883> - - Reviewed by Mark Hahnenberg. - - It turns out that it's a good idea to maintain the invariants of your object model, such as that - elements past publicLength should have the hole value. - - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::dump): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-17 Anders Carlsson <andersca@apple.com> - - Clean up Vector.h - https://bugs.webkit.org/show_bug.cgi?id=99622 - - Reviewed by Benjamin Poulain. - - Fix fallout from removing std::max and std::min using declarations. - - * runtime/StringPrototype.cpp: - (JSC::jsSpliceSubstrings): - (JSC::jsSpliceSubstringsWithSeparators): - (JSC::stringProtoFuncIndexOf): - * yarr/YarrPattern.cpp: - (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): - -2012-10-17 Oliver Hunt <oliver@apple.com> - - Committing new files is so overrated. - - * bytecode/ResolveOperation.h: Added. - (JSC): - (JSC::ResolveOperation::getAndReturnScopedVar): - (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope): - (ResolveOperation): - (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): - -2012-10-17 Michael Saboff <msaboff@apple.com> - - StringPrototype::jsSpliceSubstringsWithSeparators() doesn't optimally handle 8 bit strings - https://bugs.webkit.org/show_bug.cgi?id=99230 - - Reviewed by Geoffrey Garen. - - Added code to select characters8() or characters16() on the not all 8 bit path for both the - processing of the source and the separators. - - * runtime/StringPrototype.cpp: - (JSC::jsSpliceSubstringsWithSeparators): - -2012-10-17 Filip Pizlo <fpizlo@apple.com> - - Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling - https://bugs.webkit.org/show_bug.cgi?id=99557 - - Reviewed by Geoffrey Garen. - - Removed an inaccurate and misleading comment as per Geoff's review. (I forgot - to make this change as part of http://trac.webkit.org/changeset/131644). - - * bytecompiler/NodesCodegen.cpp: - (JSC::FunctionCallResolveNode::emitBytecode): - -2012-10-17 Oliver Hunt <oliver@apple.com> - - Bytecode should not have responsibility for determining how to perform non-local resolves - https://bugs.webkit.org/show_bug.cgi?id=99349 - - Reviewed by Gavin Barraclough. - - 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. - - 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. - - 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::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::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::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_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_put_to_base): - (JSC): - * 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: - * 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::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): - * runtime/JSVariableObject.h: - (JSVariableObject): - * runtime/Structure.h: - (JSC::Structure::propertyAccessesAreCacheable): - (Structure): - -2012-10-17 Filip Pizlo <fpizlo@apple.com> - - Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling - https://bugs.webkit.org/show_bug.cgi?id=99557 - - Reviewed by Geoffrey Garen. - - This uses the old jneq_ptr trick to allow for the bytecode to "see" that the - operation in question is what we almost certainly know it to be. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dump): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/SpecialPointer.h: - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitCall): - (JSC::BytecodeGenerator::emitCallEval): - (JSC::BytecodeGenerator::expectedFunctionForIdentifier): - (JSC): - (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): - (JSC::BytecodeGenerator::emitConstruct): - * bytecompiler/BytecodeGenerator.h: - (BytecodeGenerator): - * bytecompiler/NodesCodegen.cpp: - (JSC::NewExprNode::emitBytecode): - (JSC::FunctionCallValueNode::emitBytecode): - (JSC::FunctionCallResolveNode::emitBytecode): - (JSC::FunctionCallBracketNode::emitBytecode): - (JSC::FunctionCallDotNode::emitBytecode): - (JSC::CallFunctionCallDotNode::emitBytecode): - (JSC::ApplyFunctionCallDotNode::emitBytecode): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGCapabilities.h: - (JSC::DFG::canCompileOpcode): - * jit/JIT.cpp: - (JSC::JIT::privateCompileMainPass): - * jit/JIT.h: - (JIT): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_new_array_with_size): - (JSC): - * 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/LowLevelInterpreter.asm: - * runtime/ArrayConstructor.cpp: - (JSC::constructArrayWithSizeQuirk): - (JSC): - * runtime/ArrayConstructor.h: - (JSC): - * runtime/CommonIdentifiers.h: - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (JSC): - -2012-10-17 Filip Pizlo <fpizlo@apple.com> - - JIT op_get_by_pname should call cti_get_by_val_generic and not cti_get_by_val - https://bugs.webkit.org/show_bug.cgi?id=99631 - <rdar://problem/12483221> - - Reviewed by Mark Hahnenberg. - - cti_get_by_val assumes that the return address has patching metadata associated with it, which won't - be true for op_get_by_pname. cti_get_by_val_generic makes no such assumptions. - - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emitSlow_op_get_by_pname): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emitSlow_op_get_by_pname): - -2012-10-17 Mark Hahnenberg <mhahnenberg@apple.com> - - Block freeing thread should sleep indefinitely when there's no work to do - https://bugs.webkit.org/show_bug.cgi?id=98084 - - Reviewed by Geoffrey Garen. - - r130212 didn't fully fix the problem. - - * heap/BlockAllocator.cpp: - (JSC::BlockAllocator::blockFreeingThreadMain): We would just continue to the next iteration if - we found that we had zero blocks to copy. We should move the indefinite wait up to where that - check is done so that we properly detect the "no more blocks to copy, wait for more" condition. - -2012-10-16 Csaba Osztrogonác <ossy@webkit.org> - - 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 - - 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::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): - (JSC::GlobalResolveInfo::GlobalResolveInfo): - (GlobalResolveInfo): - (JSC::getGlobalResolveInfoBytecodeOffset): - * bytecode/Opcode.h: - (JSC): - (JSC::padOpcodeName): - * bytecode/ResolveGlobalStatus.cpp: - (JSC): - (JSC::computeForStructure): - (JSC::computeForLLInt): - (JSC::ResolveGlobalStatus::computeFor): - * bytecode/ResolveGlobalStatus.h: - (JSC): - (ResolveGlobalStatus): - * bytecode/ResolveOperation.h: Removed. - * bytecompiler/BytecodeGenerator.cpp: - (JSC::ResolveResult::checkValidity): - (JSC::ResolveResult::registerPointer): - (JSC): - (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): - * dfg/DFGByteCodeParser.cpp: - (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::hasIdentifier): - * 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: - (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): - * 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: - -2012-10-16 Dongwoo Joshua Im <dw.im@samsung.com> - - [GTK] Fix build break - ResolveOperations.h is not in WebKit. - https://bugs.webkit.org/show_bug.cgi?id=99538 - - Unreviewed build fix. - - There are some files including ResolveOperations.h which is not exist at all. - - * GNUmakefile.list.am: s/ResolveOperations.h/ResolveOperation.h/ - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: s/ResolveOperations.h/ResolveOperation.h/ - -2012-10-16 Jian Li <jianli@chromium.org> - - Rename feature define ENABLE_WIDGET_REGION to ENABLE_DRAGGBALE_REGION - https://bugs.webkit.org/show_bug.cgi?id=98975 - - Reviewed by Adam Barth. - - Renaming is needed to better match with the draggable region code. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-15 Oliver Hunt <oliver@apple.com> - - Bytecode should not have responsibility for determining how to perform non-local resolves - https://bugs.webkit.org/show_bug.cgi?id=99349 - - Reviewed by Gavin Barraclough. - - 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. - - 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. - - 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::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::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::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_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_put_to_base): - (JSC): - * 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: - * 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::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): - * runtime/JSVariableObject.h: - (JSVariableObject): - * runtime/Structure.h: - (JSC::Structure::propertyAccessesAreCacheable): - (Structure): - -2012-10-16 Filip Pizlo <fpizlo@apple.com> - - Accidental switch fall-through in DFG::FixupPhase - https://bugs.webkit.org/show_bug.cgi?id=96956 - <rdar://problem/12313242> - - Reviewed by Mark Hahnenberg. - - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - -2012-10-16 Filip Pizlo <fpizlo@apple.com> - - 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. - - All it takes is to follow the "if (!shouldGenerate) continue" idiom and everything will be OK. - - * 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-10-16 Dima Gorbik <dgorbik@apple.com> - - Remove Platform.h include from the header files. - https://bugs.webkit.org/show_bug.cgi?id=98665 - - Reviewed by Eric Seidel. - - We don't want other clients that include WebKit headers to know about Platform.h. - - * API/tests/minidom.c: - * API/tests/testapi.c: - -2012-10-16 Balazs Kilvady <kilvadyb@homejinni.com> - - Add missing MIPS functions to assembler. - https://bugs.webkit.org/show_bug.cgi?id=98856 - - Reviewed by Oliver Hunt. - - 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: - (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-10-16 Balazs Kilvady <kilvadyb@homejinni.com> - - MIPS assembler coding-style fix. - https://bugs.webkit.org/show_bug.cgi?id=99359 - - Reviewed by Oliver Hunt. - - Coding style fix of existing MIPS assembler header files. - - * 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 - - Reviewed by Gavin Barraclough. - - 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 - - Reviewed by Filip Pizlo. - - 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. - - * 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-10-14 Filip Pizlo <fpizlo@apple.com> - - JIT::JIT fails to initialize all of its fields - https://bugs.webkit.org/show_bug.cgi?id=99283 - - Reviewed by Andreas Kling. - - 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. - - * jit/JIT.cpp: - (JSC::JIT::JIT): - -2012-10-15 Mark Hahnenberg <mhahnenberg@apple.com> - - We should avoid weakCompareAndSwap when parallel GC is disabled - https://bugs.webkit.org/show_bug.cgi?id=99331 - - Reviewed by Filip Pizlo. - - 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. - - * heap/CopiedBlock.h: - (JSC::CopiedBlock::reportLiveBytes): - (JSC::CopiedBlock::didEvacuateBytes): - -2012-10-15 Carlos Garcia Campos <cgarcia@igalia.com> - - Unreviewed. Fix make distcheck. - - * GNUmakefile.list.am: Add missing header file. - -2012-10-14 Filip Pizlo <fpizlo@apple.com> - - 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 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. - - * 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::modeUsesButterfly): - (JSC::DFG::modeIsJSArray): - (JSC::DFG::mayStoreToTail): - (JSC::DFG::mayStoreToHole): - (JSC::DFG::canCSEStorage): - (JSC::DFG::modeSupportsLength): - (JSC::DFG::benefitsFromStructureCheck): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::checkArray): - (JSC::DFG::FixupPhase::blessArrayOperation): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::byValIsPure): - * 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): - -2012-10-14 Filip Pizlo <fpizlo@apple.com> - - 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. - - The fix is to hash cons the offsets based on configuration index, not the offsets - themselves. - - * offlineasm/offsets.rb: - -2012-10-13 Filip Pizlo <fpizlo@apple.com> - - IndexingType should not have a bit for each type - https://bugs.webkit.org/show_bug.cgi?id=98997 - - Reviewed by Oliver Hunt. - - 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. - - * 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): - -2012-10-14 Filip Pizlo <fpizlo@apple.com> - - 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 - - Reviewed by Oliver Hunt. - - 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. - - * dfg/DFGStructureCheckHoistingPhase.cpp: - (JSC::DFG::StructureCheckHoistingPhase::run): - (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): - (StructureCheckHoistingPhase): - (CheckData): - (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData): - -2012-10-14 Filip Pizlo <fpizlo@apple.com> - - Fix the build of universal binary with ARMv7s of JavaScriptCore - - * llint/LLIntOfflineAsmConfig.h: - * llint/LowLevelInterpreter.asm: - -2012-10-13 Filip Pizlo <fpizlo@apple.com> - - Array length array profiling is broken in the baseline JIT - https://bugs.webkit.org/show_bug.cgi?id=99258 - - Reviewed by Oliver Hunt. - - 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. - - * jit/JIT.h: - (JSC::JIT::compilePatchGetArrayLength): - -2012-10-14 Patrick Gansterer <paroga@webkit.org> - - Build fix for WinCE after r131089. - - WinCE does not support getenv(). - - * runtime/Options.cpp: - (JSC::overrideOptionWithHeuristic): - -2012-10-12 Kangil Han <kangil.han@samsung.com> - - Fix build error on DFGSpeculativeJIT32_64.cpp - https://bugs.webkit.org/show_bug.cgi?id=99234 - - Reviewed by Anders Carlsson. - - Seems BUG 98608 causes build error on 32bit machine so fix it. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-12 Filip Pizlo <fpizlo@apple.com> - - Contiguous array allocation should always be inlined - https://bugs.webkit.org/show_bug.cgi?id=98608 - - Reviewed by Oliver Hunt and Mark Hahnenberg. - - This inlines contiguous array allocation in the most obvious way possible. - - * 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): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> - - Race condition during CopyingPhase can lead to deadlock - https://bugs.webkit.org/show_bug.cgi?id=99226 - - Reviewed by Filip Pizlo. - - 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. - - 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. - - * heap/Heap.cpp: - (JSC::Heap::copyBackingStores): - -2012-10-12 Anders Carlsson <andersca@apple.com> - - Move macros from Parser.h to Parser.cpp - https://bugs.webkit.org/show_bug.cgi?id=99217 - - Reviewed by Andreas Kling. - - 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): - -2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> - - Another build fix after r131213 - - Added some symbol magic to placate the linker on some platforms. - - * JavaScriptCore.order: - -2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> - - Build fix after r131213 - - Removed an unused variable that was making compilers unhappy. - - * heap/GCThread.cpp: - (JSC::GCThread::GCThread): - * heap/GCThread.h: - (GCThread): - * heap/GCThreadSharedData.cpp: - (JSC::GCThreadSharedData::GCThreadSharedData): - -2012-10-09 Mark Hahnenberg <mhahnenberg@apple.com> - - Copying collection shouldn't require O(live bytes) memory overhead - https://bugs.webkit.org/show_bug.cgi?id=98792 - - Reviewed by Filip Pizlo. - - 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. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * 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): - (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): - (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::startSweeping): - * heap/IncrementalSweeper.h: - (JSC): - (IncrementalSweeper): - * heap/SlotVisitor.cpp: - (JSC::SlotVisitor::setup): - (JSC::SlotVisitor::drainFromShared): We no longer do any copying-related work here. - (JSC): - * heap/SlotVisitor.h: - (SlotVisitor): - * heap/SlotVisitorInlineMethods.h: - (JSC): - (JSC::SlotVisitor::copyLater): Notifies the CopiedBlock that there are some live bytes that may need - to be copied. - * runtime/Butterfly.h: - (JSC): - (Butterfly): - * runtime/ButterflyInlineMethods.h: - (JSC::Butterfly::createUninitializedDuringCollection): Uses the new CopyVisitor. - * runtime/ClassInfo.h: - (MethodTable): Added new "virtual" function copyBackingStore to method table. - (JSC): - * runtime/JSCell.cpp: - (JSC::JSCell::copyBackingStore): Default implementation that does nothing. - (JSC): - * runtime/JSCell.h: - (JSC): - (JSCell): - * runtime/JSObject.cpp: - (JSC::JSObject::copyButterfly): Does the actual copying of the butterfly. - (JSC): - (JSC::JSObject::visitButterfly): Calls copyLater for the butterfly. - (JSC::JSObject::copyBackingStore): - * runtime/JSObject.h: - (JSObject): - (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): - -2012-10-12 Filip Pizlo <fpizlo@apple.com> - - DFG array allocation calls should not return an encoded JSValue - https://bugs.webkit.org/show_bug.cgi?id=99196 - - Reviewed by Mark Hahnenberg. - - The array allocation operations now return a pointer instead. This makes it - easier to share code between 32-bit and 64-bit. - - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - -2012-10-01 Jer Noble <jer.noble@apple.com> - - Enable ENCRYPTED_MEDIA support on Mac. - https://bugs.webkit.org/show_bug.cgi?id=98044 - - Reviewed by Anders Carlsson. - - Enable the ENCRYPTED_MEDIA flag. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-12 Filip Pizlo <fpizlo@apple.com> - - Unreviewed. It should be possible to build JSC on ARMv7. - - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::patchableBranchPtr): - -2012-10-11 Mark Hahnenberg <mhahnenberg@apple.com> - - BlockAllocator should use regions as its VM allocation abstraction - https://bugs.webkit.org/show_bug.cgi?id=99107 - - Reviewed by Geoffrey Garen. - - 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. - - 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: - - 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. - - 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. - - 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. - - 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. - - 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. - - * 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): - (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-10-11 Filip Pizlo <fpizlo@apple.com> - - 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 Michael Saboff and Mark Hahnenberg. - - 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/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): - -2012-10-11 Geoffrey Garen <ggaren@apple.com> - - Removed some more static assumptions about inline object capacity - https://bugs.webkit.org/show_bug.cgi?id=98603 - - Reviewed by Filip Pizlo. - - * 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. - - * 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. - - * 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::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. - - (JSC::JSObject::offsetOfInlineStorage): Changed the math here to match - inlineStorageUnsafe(), since we can rely on an explicit data member anymore. - -2012-10-11 Geoffrey Garen <ggaren@apple.com> - - Enable RUNTIME_HEURISTICS all the time, for easier testing - https://bugs.webkit.org/show_bug.cgi?id=99090 - - Reviewed by Filip Pizlo. - - 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. - - * runtime/Options.cpp: - (JSC::overrideOptionWithHeuristic): - (JSC::Options::initialize): - * runtime/Options.h: Removed the #ifdef. - -2012-10-11 Geoffrey Garen <ggaren@apple.com> - - Removed ASSERT_CLASS_FITS_IN_CELL - https://bugs.webkit.org/show_bug.cgi?id=97634 - - Reviewed by Mark Hahnenberg. - - Our collector now supports arbitrarily sized objects, so the ASSERT is not needed. - - * 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. - -2012-10-11 Filip Pizlo <fpizlo@apple.com> - - DFG should inline code blocks that use new_array_buffer - https://bugs.webkit.org/show_bug.cgi?id=98996 - - Reviewed by Geoffrey Garen. - - 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. - - * 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): - -2012-10-10 Zoltan Horvath <zoltan@webkit.org> - - Pageload tests should measure memory usage - https://bugs.webkit.org/show_bug.cgi?id=93958 - - Reviewed by Ryosuke Niwa. - - Add JS Heap and Heap memory measurement to PageLoad tests. - - * 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. - -2012-10-10 Balazs Kilvady <kilvadyb@homejinni.com> - - RegisterFile to JSStack rename fix for a struct member. - - Compilation problem in debug build on MIPS - https://bugs.webkit.org/show_bug.cgi?id=98808 - - Reviewed by Alexey Proskuryakov. - - In ASSERT conditions structure field name "registerFile" was replaced - with type name "JSStack" and it should be "stack". - - * jit/JITStubs.cpp: - (JSC::JITThunks::JITThunks): structure member name fix. - -2012-10-10 Michael Saboff <msaboff@apple.com> - - After r130344, OpaqueJSString::string() shouldn't directly return the wrapped String - https://bugs.webkit.org/show_bug.cgi?id=98801 - - Reviewed by Geoffrey Garen. - - Return a copy of the wrapped String so that the wrapped string cannot be turned into - an Identifier. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::string): - * API/OpaqueJSString.h: - (OpaqueJSString): - -2012-10-10 Peter Gal <galpeter@inf.u-szeged.hu> - - Add moveDoubleToInts and moveIntsToDouble to MacroAssemblerARM - https://bugs.webkit.org/show_bug.cgi?id=98855 - - Reviewed by Filip Pizlo. - - Implement the missing moveDoubleToInts and moveIntsToDouble - methods in the MacroAssemblerARM after r130839. - - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::moveDoubleToInts): - (MacroAssemblerARM): - (JSC::MacroAssemblerARM::moveIntsToDouble): - -2012-10-09 Filip Pizlo <fpizlo@apple.com> - - 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 - - Reviewed by Oliver Hunt and Gavin Barraclough. - - 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. - - * 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::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-10-09 Michael Saboff <msaboff@apple.com> - - Add tests to testapi for null OpaqueJSStrings - https://bugs.webkit.org/show_bug.cgi?id=98805 - - Reviewed by Geoffrey Garen. - - 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. - - * API/tests/testapi.c: - (main): - -2012-10-09 Jian Li <jianli@chromium.org> - - Update the CSS property used to support draggable regions. - https://bugs.webkit.org/show_bug.cgi?id=97156 - - Reviewed by Adam Barth. - - 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. - - * Configurations/FeatureDefines.xcconfig: Disable WIDGET_REGION feature. - -2012-10-09 Filip Pizlo <fpizlo@apple.com> - - Unreviewed, adding forgotten files. - - * bytecode/ByValInfo.h: Added. - (JSC): - (JSC::isOptimizableIndexingType): - (JSC::jitArrayModeForIndexingType): - (JSC::ByValInfo::ByValInfo): - (ByValInfo): - (JSC::getByValInfoBytecodeIndex): - * runtime/IndexingType.cpp: Added. - (JSC): - (JSC::indexingTypeToString): - -2012-10-08 Filip Pizlo <fpizlo@apple.com> - - JSC should infer when indexed storage is contiguous, and optimize for it - https://bugs.webkit.org/show_bug.cgi?id=97288 - - Reviewed by Mark Hahnenberg. - - This introduces a new kind of indexed property storage called Contiguous, - which has the following properties: - - - 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. - - - 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. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * 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/DFGArrayMode.cpp: - (JSC::DFG::fromObserved): - (JSC::DFG::modeAlreadyChecked): - (JSC::DFG::modeToString): - * dfg/DFGArrayMode.h: - (DFG): - (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::handleIntrinsic): - * dfg/DFGCSEPhase.cpp: - (JSC::DFG::CSEPhase::getArrayLengthElimination): - (JSC::DFG::CSEPhase::getByValLoadElimination): - (JSC::DFG::CSEPhase::performNodeCSE): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - (JSC::DFG::FixupPhase::checkArray): - (JSC::DFG::FixupPhase::blessArrayOperation): - * dfg/DFGGraph.h: - (JSC::DFG::Graph::byValIsPure): - * dfg/DFGOperations.cpp: - * dfg/DFGOperations.h: - * dfg/DFGRepatch.cpp: - (JSC::DFG::tryCacheGetByID): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::checkArray): - (JSC::DFG::SpeculativeJIT::arrayify): - (JSC::DFG::SpeculativeJIT::compileGetArrayLength): - (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): - (DFG): - * dfg/DFGSpeculativeJIT.h: - (DFG): - (JSC::DFG::SpeculativeJIT::callOperation): - (SpeculativeJIT): - (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): - (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): - * dfg/DFGSpeculativeJIT32_64.cpp: - (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::compileContiguousGetByVal): - (DFG): - (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): - (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): - (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): - (JSC::DFG::SpeculativeJIT::compile): - * 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::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): - (JSC::JIT::emitContiguousGetByVal): - (JSC::JIT::emitArrayStorageGetByVal): - (JSC::JIT::emitSlow_op_get_by_val): - (JSC::JIT::emit_op_put_by_val): - (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::emitContiguousPutByVal): - (JSC::JIT::emitArrayStoragePutByVal): - (JSC::JIT::emitSlow_op_put_by_val): - * jit/JITStubs.cpp: - (JSC::getByVal): - (JSC): - (JSC::DEFINE_STUB_FUNCTION): - (JSC::putByVal): - * jit/JITStubs.h: - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * runtime/ArrayConventions.h: - (JSC::isDenseEnoughForVector): - * runtime/ArrayPrototype.cpp: - (JSC): - (JSC::shift): - (JSC::unshift): - (JSC::arrayProtoFuncPush): - (JSC::arrayProtoFuncShift): - (JSC::arrayProtoFuncSplice): - (JSC::arrayProtoFuncUnShift): - * runtime/Butterfly.h: - (Butterfly): - (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/IndexingHeaderInlineMethods.h: - (JSC::IndexingHeader::indexingPayloadSizeInBytes): - * runtime/IndexingType.cpp: Added. - (JSC): - (JSC::indexingTypeToString): - * runtime/IndexingType.h: - (JSC): - (JSC::hasContiguous): - * runtime/JSArray.cpp: - (JSC::JSArray::setLengthWithArrayStorage): - (JSC::JSArray::setLength): - (JSC): - (JSC::JSArray::pop): - (JSC::JSArray::push): - (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::JSArray::shiftCountForShift): - (JSC::JSArray::shiftCountForSplice): - (JSArray): - (JSC::JSArray::shiftCount): - (JSC::JSArray::unshiftCountForShift): - (JSC::JSArray::unshiftCountForSplice): - (JSC::JSArray::unshiftCount): - (JSC::JSArray::isLengthWritable): - (JSC::createContiguousArrayButterfly): - (JSC): - (JSC::JSArray::create): - (JSC::JSArray::tryCreateUninitialized): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::reset): - (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::getOwnPropertySlotByIndex): - (JSC::JSObject::putByIndex): - (JSC::JSObject::enterDictionaryIndexingMode): - (JSC::JSObject::createInitialContiguous): - (JSC): - (JSC::JSObject::createArrayStorage): - (JSC::JSObject::convertContiguousToArrayStorage): - (JSC::JSObject::ensureContiguousSlow): - (JSC::JSObject::ensureArrayStorageSlow): - (JSC::JSObject::ensureIndexedStorageSlow): - (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): - (JSC::JSObject::switchToSlowPutArrayStorage): - (JSC::JSObject::setPrototype): - (JSC::JSObject::deletePropertyByIndex): - (JSC::JSObject::getOwnPropertyNames): - (JSC::JSObject::defineOwnIndexedProperty): - (JSC::JSObject::putByIndexBeyondVectorLengthContiguousWithoutAttributes): - (JSC::JSObject::putByIndexBeyondVectorLength): - (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): - (JSC::JSObject::putDirectIndexBeyondVectorLength): - (JSC::JSObject::getNewVectorLength): - (JSC::JSObject::countElementsInContiguous): - (JSC::JSObject::increaseVectorLength): - (JSC::JSObject::ensureContiguousLengthSlow): - (JSC::JSObject::getOwnPropertyDescriptor): - * runtime/JSObject.h: - (JSC::JSObject::getArrayLength): - (JSC::JSObject::getVectorLength): - (JSC::JSObject::canGetIndexQuickly): - (JSC::JSObject::getIndexQuickly): - (JSC::JSObject::tryGetIndexQuickly): - (JSC::JSObject::canSetIndexQuickly): - (JSC::JSObject::canSetIndexQuicklyForPutDirect): - (JSC::JSObject::setIndexQuickly): - (JSC::JSObject::initializeIndex): - (JSC::JSObject::hasSparseMap): - (JSC::JSObject::inSparseIndexingMode): - (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::needsSlowPutIndexing): - (JSC): - (JSC::Structure::suggestedArrayStorageTransition): - * runtime/Structure.h: - (Structure): - * runtime/StructureTransitionTable.h: - (JSC::newIndexingType): - -2012-10-09 Michael Saboff <msaboff@apple.com> - - 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> - - Reviewed by Mark Rowe. - - 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. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::identifier): - -2012-10-08 Mark Lam <mark.lam@apple.com> - - 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. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.order: - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * Target.pri: - * bytecode/BytecodeConventions.h: - * bytecode/CodeBlock.cpp: - (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::resolveCallee): - (JSC::BytecodeGenerator::emitCall): - (JSC::BytecodeGenerator::emitConstruct): - * bytecompiler/BytecodeGenerator.h: - (JSC::BytecodeGenerator::registerFor): - * 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::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): - (JSC::DFG::SpeculativeJIT::checkArgumentTypes): - (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): - * dfg/DFGSpeculativeJIT.h: - (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): - * 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::Interpreter::prepareForRepeatCall): - (JSC::Interpreter::endRepeatCall): - * interpreter/Interpreter.h: - (JSC::Interpreter::stack): - (Interpreter): - (JSC::Interpreter::execute): - (JSC): - * 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): - (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::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): - * 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): - (JSC::DEFINE_STUB_FUNCTION): - * jit/JITStubs.h: - (JSC): - (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::LLINT_SLOW_PATH_DECL): - (JSC::LLInt::genericCall): - * llint/LLIntSlowPaths.h: - (LLInt): - * llint/LowLevelInterpreter.asm: - * runtime/Arguments.cpp: - (JSC::Arguments::tearOffForInlineCallFrame): - * runtime/CommonSlowPaths.h: - (JSC::CommonSlowPaths::arityCheckFor): - * runtime/InitializeThreading.cpp: - (JSC::initializeThreadingOnce): - * runtime/JSActivation.cpp: - (JSC::JSActivation::visitChildren): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::globalExec): - * runtime/JSGlobalObject.h: - (JSC): - (JSGlobalObject): - * runtime/JSLock.cpp: - (JSC): - * runtime/JSVariableObject.h: - (JSVariableObject): - * runtime/MemoryStatistics.cpp: - (JSC::globalMemoryStatistics): - -2012-10-08 Kiran Muppala <cmuppala@apple.com> - - Throttle DOM timers on hidden pages. - https://bugs.webkit.org/show_bug.cgi?id=98474 - - Reviewed by Maciej Stachowiak. - - Add HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-08 Michael Saboff <msaboff@apple.com> - - After r130344, OpaqueJSString() creates an empty string which should be a null string - https://bugs.webkit.org/show_bug.cgi?id=98417 - - Reviewed by Sam Weinig. - - Changed create() of a null string to return 0. This is the same behavior as before r130344. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::create): - -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 - - Reviewed by Eric Seidel. - - * API/JSCallbackObject.h: - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): - (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): - * API/JSCallbackObjectFunctions.h: - (JSC::::getOwnNonIndexPropertyNames): - * 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/SlotVisitor.cpp: - (JSC::SlotVisitor::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::getOwnNonIndexPropertyNames): - (JSC::JSActivation::symbolTablePutWithAttributes): - * runtime/JSArray.cpp: - (JSC::JSArray::setLength): - * 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::getOwnNonIndexPropertyNames): - * runtime/JSSymbolTableObject.h: - (JSC::symbolTableGet): - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): - * runtime/RegExpCache.cpp: - (JSC::RegExpCache::invalidateCode): - * runtime/SparseArrayValueMap.cpp: - (JSC::SparseArrayValueMap::putEntry): - (JSC::SparseArrayValueMap::putDirect): - (JSC::SparseArrayValueMap::visitChildren): - * 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-10-05 Mark Hahnenberg <mhahnenberg@apple.com> - - 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. - - 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. - - 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. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * 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): - (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): - (JSC::Options::initialize): Initialize the various new options using environment variables. - (JSC::Options::dumpOption): - * runtime/Options.h: - (JSC): - -2012-10-04 Rik Cabanier <cabanier@adobe.com> - - Turn Compositing on by default in WebKit build - https://bugs.webkit.org/show_bug.cgi?id=98315 - - Reviewed by Simon Fraser. - - enable -webkit-blend-mode on trunk. - - * Configurations/FeatureDefines.xcconfig: - -2012-10-04 Michael Saboff <msaboff@apple.com> - - Crash in Safari at com.apple.JavaScriptCore: WTF::StringImpl::is8Bit const + 12 - https://bugs.webkit.org/show_bug.cgi?id=98433 - - Reviewed by Jessie Berlin. - - 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: - (JSValueMakeFromJSONString): - -2012-10-04 Benjamin Poulain <bpoulain@apple.com> - - Use copyLCharsFromUCharSource() for IdentifierLCharFromUCharTranslator translation - https://bugs.webkit.org/show_bug.cgi?id=98335 - - Reviewed by Michael Saboff. - - Michael Saboff added an optimized version of UChar->LChar conversion in r125846. - Use this function in JSC::Identifier. - - * runtime/Identifier.cpp: - (JSC::IdentifierLCharFromUCharTranslator::translate): - -2012-10-04 Michael Saboff <msaboff@apple.com> - - After r130344, OpaqueJSString() creates a empty string which should be a null string - https://bugs.webkit.org/show_bug.cgi?id=98417 - - Reviewed by Alexey Proskuryakov. - - 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. - - * API/OpaqueJSString.h: - (OpaqueJSString::OpaqueJSString): - -2012-10-04 Csaba Osztrogonác <ossy@webkit.org> - - [Qt] Add missing LLInt dependencies to the build system - https://bugs.webkit.org/show_bug.cgi?id=98394 - - Reviewed by Geoffrey Garen. - - * DerivedSources.pri: - * LLIntOffsetsExtractor.pro: - -2012-10-03 Geoffrey Garen <ggaren@apple.com> - - Next step toward fixing Windows: add new symbol. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-10-03 Geoffrey Garen <ggaren@apple.com> - - First step toward fixing Windows: remove old symbol. - - * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: - -2012-10-03 Geoffrey Garen <ggaren@apple.com> - - 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. - - This is a step toward object size inference. - - 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): - * jit/JITPropertyAccess.cpp: - (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. - - (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. - - (JSC::JIT::compileGetDirectOffset): Updated for rename. - - (JSC::JIT::emit_op_get_by_pname): Same as emit_op_get_by_pname above. - - * llint/LowLevelInterpreter.asm: Updated to mirror changes in PropertyOffset.h, - since we duplicate values from there. - - * 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. - - 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. - - * runtime/JSObject.cpp: - (JSC::JSObject::visitChildren): - (JSC::JSFinalObject::visitChildren): - * runtime/JSObject.h: - (JSC::JSObject::offsetForLocation): - (JSNonFinalObject): - (JSC::JSFinalObject::createStructure): - (JSFinalObject): - (JSC::JSFinalObject::finishCreation): Updated for above changes. - - * runtime/JSPropertyNameIterator.h: - (JSPropertyNameIterator): - (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: - (PropertyTable): Use a helper function instead of hard-coding assumptions - about object types. - - (JSC::PropertyTable::nextOffset): - * runtime/PropertyOffset.h: - (JSC): - (JSC::checkOffset): - (JSC::validateOffset): - (JSC::isInlineOffset): - (JSC::numberOfSlotsForLastOffset): - (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::flattenDictionaryStructure): - (JSC::Structure::putSpecificValue): - * runtime/Structure.h: - (Structure): - (JSC::Structure::outOfLineCapacity): - (JSC::Structure::hasInlineStorage): - (JSC::Structure::inlineCapacity): - (JSC::Structure::inlineSize): - (JSC::Structure::firstValidOffset): - (JSC::Structure::lastValidOffset): - (JSC::Structure::create): Removed some hard-coded assumptions about inline - capacity and object type, and replaced with more liberal use of helper functions. - -2012-10-03 Michael Saboff <msaboff@apple.com> - - OpaqueJSString doesn't optimally handle 8 bit strings - https://bugs.webkit.org/show_bug.cgi?id=98300 - - Reviewed by Geoffrey Garen. - - 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. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::create): - (OpaqueJSString::identifier): - * API/OpaqueJSString.h: - (OpaqueJSString::characters): - (OpaqueJSString::length): - (OpaqueJSString::string): - (OpaqueJSString::OpaqueJSString): - (OpaqueJSString): - -2012-10-03 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 - - Reviewed by Michael Saboff. - - 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. - - * runtime/ArrayPrototype.cpp: - (JSC::shift): - * runtime/JSArray.cpp: - (JSC::JSArray::shiftCount): - * runtime/JSArray.h: - (JSArray): - -2012-09-16 Mark Hahnenberg <mhahnenberg@apple.com> - - Delayed structure sweep can leak structures without bound - https://bugs.webkit.org/show_bug.cgi?id=96546 - - Reviewed by Geoffrey Garen. - - 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. - - * 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/Heap.cpp: - (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): - (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::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 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: - (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. - (JSC): - * runtime/StructureChain.h: Ditto. - (JSC): - * runtime/SymbolTable.h: Ditto. - (SharedSymbolTable): - (JSC): - -== Rolled over to ChangeLog-2012-10-02 == |