Google Git Google Git
Sign in
cobalt/cobalt/496b2f8cd442da39084f65fe2c451ae84d79695f/./src/third_party/WebKit/Source/JavaScriptCore/ChangeLog
blob: ab6c07613eb256c28f8350737f96ff8accdcc0d5 [file]
2013-01-18 Balazs Kilvady <kilvadyb@homejinni.com>
r134080 causes heap problem on linux systems where PAGESIZE != 4096
https://bugs.webkit.org/show_bug.cgi?id=102828
Reviewed by Mark Hahnenberg.
Make MarkStackSegment::blockSize as the capacity of segments of a MarkStackArray.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
* heap/MarkStack.cpp:
(JSC):
(JSC::MarkStackArray::MarkStackArray):
(JSC::MarkStackArray::expand):
(JSC::MarkStackArray::donateSomeCellsTo):
(JSC::MarkStackArray::stealSomeCellsFrom):
* heap/MarkStack.h:
(JSC::MarkStackSegment::data):
(CapacityFromSize):
(MarkStackArray):
* heap/MarkStackInlines.h:
(JSC::MarkStackArray::setTopForFullSegment):
(JSC::MarkStackArray::append):
(JSC::MarkStackArray::isEmpty):
(JSC::MarkStackArray::size):
* runtime/Options.h:
(JSC):
2013-01-11 Geoffrey Garen <ggaren@apple.com>
Removed getDirectLocation and offsetForLocation and all their uses
https://bugs.webkit.org/show_bug.cgi?id=106692
Reviewed by Filip Pizlo.
getDirectLocation() and its associated offsetForLocation() relied on
detailed knowledge of the rules of PropertyOffset, JSObject, and
Structure, which is a hard thing to reverse-engineer reliably. Luckily,
it wasn't needed, and all clients either wanted a true value or a
PropertyOffset. So, I refactored accordingly.
* dfg/DFGOperations.cpp: Renamed putDirectOffset to putDirect, to clarify
that we are not putting an offset.
* runtime/JSActivation.cpp:
(JSC::JSActivation::getOwnPropertySlot): Get a value instead of a value
pointer, since we never wanted a pointer to begin with.
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnPropertySlot): Use a PropertyOffset instead of a pointer,
so we don't have to reverse-engineer the offset from the pointer.
* runtime/JSObject.cpp:
(JSC::JSObject::put):
(JSC::JSObject::resetInheritorID):
(JSC::JSObject::inheritorID):
(JSC::JSObject::removeDirect):
(JSC::JSObject::fillGetterPropertySlot):
(JSC::JSObject::getOwnPropertyDescriptor): Renamed getDirectOffset and
putDirectOffset, as explaind above. We want to use the name "getDirectOffset"
for when the thing you're getting is the offset.
* runtime/JSObject.h:
(JSC::JSObject::getDirect):
(JSC::JSObject::getDirectOffset): Changed getDirectLocation to getDirectOffset,
since clients really wants PropertyOffsets and not locations.
(JSObject::offsetForLocation): Removed this function because it was hard
to get right.
(JSC::JSObject::putDirect):
(JSC::JSObject::putDirectUndefined):
(JSC::JSObject::inlineGetOwnPropertySlot):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::putDirectWithoutTransition):
* runtime/JSScope.cpp:
(JSC::executeResolveOperations):
(JSC::JSScope::resolvePut):
* runtime/JSValue.cpp:
(JSC::JSValue::putToPrimitive): Updated for renames.
* runtime/Lookup.cpp:
(JSC::setUpStaticFunctionSlot): Use a PropertyOffset instead of a pointer,
so we don't have to reverse-engineer the offset from the pointer.
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure): Updated for renames.
2013-01-11 Geoffrey Garen <ggaren@apple.com>
Fixed some bogus PropertyOffset ASSERTs
https://bugs.webkit.org/show_bug.cgi?id=106686
Reviewed by Gavin Barraclough.
The ASSERTs were passing a JSType instead of an inlineCapacity, due to
an incomplete refactoring.
The compiler didn't catch this because both types are int underneath.
* runtime/JSObject.h:
(JSC::JSObject::getDirect):
(JSC::JSObject::getDirectLocation):
(JSC::JSObject::offsetForLocation):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransitionToExistingStructure): Validate against
our inline capacity, as we intended.
2012-12-16 Filip Pizlo <fpizlo@apple.com>
Rationalize array profiling for out-of-bounds and hole cases
https://bugs.webkit.org/show_bug.cgi?id=105139
Reviewed by Geoffrey Garen.
This makes ArrayProfile track whether or not we had out-of-bounds, which allows
for more precise decision-making in the DFG.
Also cleaned up ExitKinds for out-of-bounds and hole cases to make it easier to
look at them in the profiler.
Slight speed-up (5-8%) on SunSpider/crypto-md5.
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::ArrayProfile):
(JSC::ArrayProfile::addressOfOutOfBounds):
(JSC::ArrayProfile::expectedStructure):
(JSC::ArrayProfile::structureIsPolymorphic):
(JSC::ArrayProfile::outOfBounds):
(JSC::ArrayProfile::polymorphicStructure):
* bytecode/CodeBlock.cpp:
(JSC::dumpChain):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
(JSC::exitKindIsCountable):
* bytecode/ExitKind.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JIT.h:
* jit/JITInlines.h:
(JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emitSlow_op_put_by_val):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2012-12-17 Balazs Kilvady <kilvadyb@homejinni.com>
Implement add64 for MIPS assembler after r136601
https://bugs.webkit.org/show_bug.cgi?id=104106
Reviewed by Zoltan Herczeg.
Added add64 function to MacroAssebler of MIPS.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::add32):
(JSC::MacroAssemblerMIPS::add64):
(MacroAssemblerMIPS):
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-16 Filip Pizlo <fpizlo@apple.com>
Bytecode dumping should show rare case profiles
https://bugs.webkit.org/show_bug.cgi?id=105133
Reviewed by Geoffrey Garen.
Refactored the dumper to call dumpBytecodeCommandAndNewLine in just one place,
rather than in all of the places. Changed the rare case profile getters to use
tryBinarySearch rather than binarySearch, so that they can be used speculatively
even if you don't know that the bytecode has rare case profiles. This actually
increases our assertion level, since it means that in release builds we will get
null and crash rather than getting some random adjacent profile. And then this
adds some printing of the rare case profiles.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printUnaryOp):
(JSC::CodeBlock::printBinaryOp):
(JSC::CodeBlock::printConditionalJump):
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::printPutByIdOp):
(JSC::CodeBlock::beginDumpProfiling):
(JSC):
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::dumpRareCaseProfile):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
(JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):
2012-12-13 Filip Pizlo <fpizlo@apple.com>
Attempt to rationalize and simplify WTF::binarySearch
https://bugs.webkit.org/show_bug.cgi?id=104890
Reviewed by Maciej Stachowiak.
Switch to using the new binarySearch() API. No change in behavior.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::codeOriginForReturn):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::getStubInfo):
(JSC::CodeBlock::getByValInfo):
(JSC::CodeBlock::getCallLinkInfo):
(JSC::CodeBlock::dfgOSREntryDataForBytecodeIndex):
(JSC::CodeBlock::valueProfileForBytecodeOffset):
(JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
(JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::blockIndexForBytecodeOffset):
* dfg/DFGMinifiedGraph.h:
(JSC::DFG::MinifiedGraph::at):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::indexForBytecodeIndex):
2012-12-13 Filip Pizlo <fpizlo@apple.com>
Don't assert that flags <= 0x3ff in JSTypeInfo
https://bugs.webkit.org/show_bug.cgi?id=104988
Reviewed by Sam Weinig.
This assertion doesn't accomplish anything other than crashes.
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
2012-12-13 Filip Pizlo <fpizlo@apple.com>
Named lookups on HTML documents produce inconsistent results in JavaScriptCore bindings
https://bugs.webkit.org/show_bug.cgi?id=104623
Reviewed by Geoffrey Garen.
Add the notion of objects that HasImpureGetOwnPropertySlot, and use that to inhibit prototype chain caching
in some cases. This appears to be perf-neutral on benchmarks that we track.
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCacheGetByID):
(JSC::DFG::tryBuildGetByIDProtoList):
* jit/JITStubs.cpp:
(JSC::JITThunks::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
* runtime/JSTypeInfo.h:
(JSC):
(JSC::TypeInfo::hasImpureGetOwnPropertySlot):
* runtime/Operations.h:
(JSC::normalizePrototypeChainForChainAccess):
2012-12-13 Filip Pizlo <fpizlo@apple.com>
Unreviewed, roll out http://trac.webkit.org/changeset/137683.
It broke gmail.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode):
* dfg/DFGNodeType.h:
(DFG):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
(JSC):
* runtime/Operations.h:
(JSC):
2012-13-11 Oliver Hunt <oliver@apple.com>
Support op_typeof in the DFG
https://bugs.webkit.org/show_bug.cgi?id=98898
Reviewed by Filip Pizlo.
Adds a TypeOf node to the DFG to support op_typeof.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
We try to determine the result early here, and substitute in a constant.
Otherwise we leave the node intact, and set the result type to SpecString.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
Parse op_typeof
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::performNodeCSE):
TypeOf nodes can be subjected to pure CSE
* dfg/DFGCapabilities.h:
(JSC::DFG::canCompileOpcode):
We can handle typeof.
* dfg/DFGNodeType.h:
(DFG):
Define the node.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
Add operationTypeOf to support the non-trivial cases.
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
Actual codegen
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
(JSC):
* runtime/Operations.h:
(JSC):
Some refactoring to allow us to get the type string for an
object without needing a callframe.
2012-12-12 Filip Pizlo <fpizlo@apple.com>
OSR exit compiler should emit code for resetting the execution counter that matches the logic of ExecutionCounter.cpp
https://bugs.webkit.org/show_bug.cgi?id=104791
Reviewed by Oliver Hunt.
The OSR exit compiler wants to make it so that every OSR exit does the equivalent
of:
codeBlock->m_jitExecuteCounter.setNewThreshold(
codeBlock->counterValueForOptimizeAfterLongWarmUp());
This logically involves:
- Resetting the counter to zero.
- Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
- Figuring out the scaled threshold, subtracting the count so far (which is zero,
so this part is a no-op), and clipping (ExecuteCounter::clippedThreshold()).
- Setting m_counter to the negated clipped threshold.
- Setting m_totalCount to the previous count so far (which is zero) plus the
clipped threshold.
Because of the reset, which sets the count-so-far to zero, this amounts to:
- Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp().
- Figuring out the clipped scaled threshold.
- Setting m_counter to the negated clipped scaled threshold.
- Setting m_totalCount to the (positive) clipped scaled threshold.
The code was previously not doing this, but now is. This is performance neutral.
The only change in behavior over what the code was previously doing (setting the
m_counter to the negated scaled threshold, without clipping, and then setting
the m_totalCount to the clipped scaled threshold) is that this will respond more
gracefully under memory pressure and will ensure that we get more value profile
LUBing before triggering recompilation. More LUBing is almost always a good
thing.
* dfg/DFGOSRExitCompiler.cpp:
(JSC::DFG::OSRExitCompiler::handleExitCounts):
2012-12-12 Ilya Tikhonovsky <loislo@chromium.org>
Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo.
https://bugs.webkit.org/show_bug.cgi?id=104796
Reviewed by Yury Semikhatsky.
It was not a good idea to introduce a fake root MemoryObjectInfo.
It makes a problem when we visit an object without its own MemoryObjectType.
Example: RenderBox has a global pointer to a hash map.
HashMap doesn't have its own object type because it is a generic container.
It will inherit object type from the fake root memory object info.
The same could happen for another container in another class with other MemoryObjectType.
This fact forces me to create custom process method for root objects
because they need to have their own MemoryObjectInfo with customisable memory object type.
Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using
for instrumented and not instrumented object classes.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
2012-12-11 Gabor Ballabas <gaborb@inf.u-szeged.hu>
Implement add64 for ARM traditional assembler after r136601
https://bugs.webkit.org/show_bug.cgi?id=104103
Reviewed by Zoltan Herczeg.
Implement add64 function for ARM traditional macroassembler.
* assembler/MacroAssemblerARM.h:
(JSC::MacroAssemblerARM::add64):
(MacroAssemblerARM):
2012-12-11 Filip Pizlo <fpizlo@apple.com>
Unreviewed. Fix build with DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE).
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
2012-12-11 Filip Pizlo <fpizlo@apple.com>
Profiler should show bytecode dumps as they would have been visible to the JITs, including the profiling data that the JITs would see
https://bugs.webkit.org/show_bug.cgi?id=104647
Reviewed by Oliver Hunt.
Adds more profiling data to bytecode dumps, and adds the ability to do a secondary
bytecode dump for each JIT compilation of a code block. This is relevant because both
the bytecodes, and the profiling data, may change after some number of executions.
Also fixes some random dumping code to use PrintStream& rather than
static const char[thingy].
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
(JSC::ArrayProfile::briefDescription):
* bytecode/ArrayProfile.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::printGetByIdOp):
(JSC::CodeBlock::printGetByIdCacheStatus):
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::briefDescription):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::dump):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* profiler/ProfilerBytecodeSequence.cpp: Added.
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
(JSC::Profiler::BytecodeSequence::~BytecodeSequence):
(JSC::Profiler::BytecodeSequence::indexForBytecodeIndex):
(JSC::Profiler::BytecodeSequence::forBytecodeIndex):
(JSC::Profiler::BytecodeSequence::addSequenceProperties):
* profiler/ProfilerBytecodeSequence.h: Added.
(JSC::Profiler::BytecodeSequence::size):
(JSC::Profiler::BytecodeSequence::at):
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::Bytecodes):
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h:
(JSC::Profiler::Bytecodes::instructionCount):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::addProfiledBytecodes):
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerCompilation.h:
(JSC::Profiler::Compilation::profiledBytecodesSize):
(JSC::Profiler::Compilation::profiledBytecodesAt):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
* profiler/ProfilerDatabase.h:
* profiler/ProfilerProfiledBytecodes.cpp: Added.
(JSC::Profiler::ProfiledBytecodes::ProfiledBytecodes):
(JSC::Profiler::ProfiledBytecodes::~ProfiledBytecodes):
(JSC::Profiler::ProfiledBytecodes::toJS):
* profiler/ProfilerProfiledBytecodes.h: Added.
(JSC::Profiler::ProfiledBytecodes::bytecodes):
* runtime/CommonIdentifiers.h:
2012-12-11 Oswald Buddenhagen <oswald.buddenhagen@digia.com>
[Qt] delete dead include paths
Reviewed by Simon Hausmann.
followup to https://bugs.webkit.org/show_bug.cgi?id=93446
* JavaScriptCore.pri:
2012-12-11 Julien BRIANCEAU <jbrianceau@nds.com>
Implement add64 for SH4 assembler to fix build after r136601
https://bugs.webkit.org/show_bug.cgi?id=104377
Reviewed by Zoltan Herczeg.
* assembler/MacroAssemblerSH4.h:
(JSC::MacroAssemblerSH4::add64):
(MacroAssemblerSH4):
2012-12-10 Yury Semikhatsky <yurys@chromium.org>
Memory instrumentation: make sure each edge is reported only once
https://bugs.webkit.org/show_bug.cgi?id=104630
Reviewed by Pavel Feldman.
Changed exported symbols for MemoryInstrumentation.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
2012-12-10 Filip Pizlo <fpizlo@apple.com>
Don't OSR exit just because a string is a rope
https://bugs.webkit.org/show_bug.cgi?id=104621
Reviewed by Michael Saboff.
Slight SunSpider speed-up at around the 0.7% level. This patch does the obvious
thing of calling a slow path to resolve ropes rather than OSR exiting if the
string is a rope.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::getIndexedPropertyStorageMayTriggerGC):
(ArrayMode):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
2012-12-10 Gustavo Noronha Silva <gns@gnome.org>
Unreviewed distcheck fix.
* GNUmakefile.list.am:
2012-12-10 Filip Pizlo <fpizlo@apple.com>
JSC profiling and debug dump code should use inferred names when possible
https://bugs.webkit.org/show_bug.cgi?id=104519
Reviewed by Oliver Hunt.
This does as advertised: the profiler now knows the inferred name of all code blocks,
and all uses of CodeBlock::dump() dump it along with the hash.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::CodeBlock::dumpAssumingJITType):
* bytecode/CodeBlock.h:
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::Bytecodes):
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h:
(JSC::Profiler::Bytecodes::inferredName):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addBytecodes):
(JSC::Profiler::Database::ensureBytecodesFor):
* profiler/ProfilerDatabase.h:
* runtime/CommonIdentifiers.h:
2012-12-09 Filip Pizlo <fpizlo@apple.com>
Profiler should say things about OSR exits
https://bugs.webkit.org/show_bug.cgi?id=104497
Reviewed by Oliver Hunt.
This adds support for profiling OSR exits. For each exit that is taken, the profiler
records the machine code address that the exit occurred on, the exit kind, the origin
stack, and the number of times that it happened.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* assembler/AbstractMacroAssembler.h:
(Jump):
(JSC::AbstractMacroAssembler::Jump::label):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::saveCompilation):
(CodeBlock):
(JSC::CodeBlock::compilation):
(DFGData):
* bytecode/DFGExitProfile.h:
(DFG):
* bytecode/ExitKind.cpp: Added.
(JSC):
(JSC::exitKindToString):
(JSC::exitKindIsCountable):
(WTF):
(WTF::printInternal):
* bytecode/ExitKind.h: Added.
(JSC):
(WTF):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGOSRExitCompiler.cpp:
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JIT):
* jit/JumpReplacementWatchpoint.h:
(JSC::JumpReplacementWatchpoint::sourceLabel):
(JumpReplacementWatchpoint):
* profiler/ProfilerCompilation.cpp:
(JSC::Profiler::Compilation::addOSRExitSite):
(Profiler):
(JSC::Profiler::Compilation::addOSRExit):
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerCompilation.h:
(Compilation):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::newCompilation):
* profiler/ProfilerDatabase.h:
(Database):
* profiler/ProfilerOSRExit.cpp: Added.
(Profiler):
(JSC::Profiler::OSRExit::OSRExit):
(JSC::Profiler::OSRExit::~OSRExit):
(JSC::Profiler::OSRExit::toJS):
* profiler/ProfilerOSRExit.h: Added.
(Profiler):
(OSRExit):
(JSC::Profiler::OSRExit::id):
(JSC::Profiler::OSRExit::origin):
(JSC::Profiler::OSRExit::exitKind):
(JSC::Profiler::OSRExit::isWatchpoint):
(JSC::Profiler::OSRExit::counterAddress):
(JSC::Profiler::OSRExit::count):
* profiler/ProfilerOSRExitSite.cpp: Added.
(Profiler):
(JSC::Profiler::OSRExitSite::toJS):
* profiler/ProfilerOSRExitSite.h: Added.
(Profiler):
(OSRExitSite):
(JSC::Profiler::OSRExitSite::OSRExitSite):
(JSC::Profiler::OSRExitSite::codeAddress):
* runtime/CommonIdentifiers.h:
2012-12-10 Alexis Menard <alexis@webkit.org>
[CSS3 Backgrounds and Borders] Remove CSS3_BACKGROUND feature flag.
https://bugs.webkit.org/show_bug.cgi?id=104539
Reviewed by Antonio Gomes.
As discussed on webkit-dev it is not needed to keep this feature flag
as support for <position> type is a small feature that is already
implemented by three other UAs. It was useful while landing this
feature as partial bits were landed one after one.
* Configurations/FeatureDefines.xcconfig:
2012-12-09 Filip Pizlo <fpizlo@apple.com>
DFG ArrayPush/Pop should not pass their second child as the index for blessArrayOperation()
https://bugs.webkit.org/show_bug.cgi?id=104500
Reviewed by Oliver Hunt.
Slight across-the-board speed-up.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2012-12-08 Filip Pizlo <fpizlo@apple.com>
JSC should scale the optimization threshold for a code block according to the cost of compiling it
https://bugs.webkit.org/show_bug.cgi?id=104406
Reviewed by Oliver Hunt.
We've long known that we want to scale the execution count threshold needed for the DFG
to kick in to scale according to some estimate of the cost of compiling that code block.
This institutes a relationship like this:
threshold = thresholdSetting * (a * sqrt(instructionCount + b) + abs(c * instructionCount) + d
Where a, b, c, d are coefficients derived from fitting the above expression to various
data points, which I chose based on looking at one benchmark (3d-cube) and from my
own intuitions.
Making this work well also required changing the thresholdForOptimizeAfterLongWarmUp
from 5000 to 1000.
This is a >1% speed-up on SunSpider, a >3% speed-up on V8Spider, ~1% speed-up on V8v7,
neutral on Octane, and neutral on Kraken.
I also out-of-lined a bunch of methods related to these heuristics, because I couldn't
stand having them defined in the header anymore. I also made improvements to debugging
code because I needed it for tuning this change.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::sourceCodeOnOneLine):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::reoptimizationRetryCounter):
(JSC::CodeBlock::countReoptimization):
(JSC::CodeBlock::optimizationThresholdScalingFactor):
(JSC::clipThreshold):
(JSC::CodeBlock::counterValueForOptimizeAfterWarmUp):
(JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp):
(JSC::CodeBlock::counterValueForOptimizeSoon):
(JSC::CodeBlock::checkIfOptimizationThresholdReached):
(JSC::CodeBlock::optimizeNextInvocation):
(JSC::CodeBlock::dontOptimizeAnytimeSoon):
(JSC::CodeBlock::optimizeAfterWarmUp):
(JSC::CodeBlock::optimizeAfterLongWarmUp):
(JSC::CodeBlock::optimizeSoon):
(JSC::CodeBlock::adjustedExitCountThreshold):
(JSC::CodeBlock::exitCountThresholdForReoptimization):
(JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop):
(JSC::CodeBlock::shouldReoptimizeNow):
(JSC::CodeBlock::shouldReoptimizeFromLoopNow):
* bytecode/CodeBlock.h:
* bytecode/ExecutionCounter.cpp:
(JSC::ExecutionCounter::hasCrossedThreshold):
* bytecode/ReduceWhitespace.cpp: Added.
(JSC::reduceWhitespace):
* bytecode/ReduceWhitespace.h: Added.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::mightCompileEval):
(JSC::DFG::mightCompileProgram):
(JSC::DFG::mightCompileFunctionForCall):
(JSC::DFG::mightCompileFunctionForConstruct):
(JSC::DFG::mightInlineFunctionForCall):
(JSC::DFG::mightInlineFunctionForConstruct):
* dfg/DFGCapabilities.h:
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpHeader):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dumpHeader):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
* runtime/Options.h:
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-12-07 Oliver Hunt <oliver@apple.com>
Make function code cache proportional to main codeblock cache
https://bugs.webkit.org/show_bug.cgi?id=104420
Reviewed by Geoffrey Garen.
Makes the constants determining the recently used function cache proportional
to the number of root codeblocks in the cache. Also renames the constants to
make them more clear.
* runtime/CodeCache.h:
2012-12-06 Filip Pizlo <fpizlo@apple.com>
Strange results calculating a square root in a loop
https://bugs.webkit.org/show_bug.cgi?id=104247
<rdar://problem/12826880>
Reviewed by Oliver Hunt.
Fixed the CFG simplification phase to ignore dead GetLocals in the first of the blocks
under the merge. This fixes the assertion, and is also cleaner: our general rule is
to not "revive" things that we've already proved to be dead.
Also fixed some rotted debug code.
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal):
* dfg/DFGStructureCheckHoistingPhase.cpp:
(JSC::DFG::StructureCheckHoistingPhase::run):
2012-12-07 Geoffrey Garen <ggaren@apple.com>
Crash in JSC::Bindings::RootObject::globalObject() sync'ing notes in Evernote
https://bugs.webkit.org/show_bug.cgi?id=104321
<rdar://problem/12770497>
Reviewed by Sam Weinig.
Work around a JSValueUnprotect(NULL) in Evernote.
* API/JSValueRef.cpp:
(evernoteHackNeeded):
(JSValueUnprotect):
2012-12-06 Filip Pizlo <fpizlo@apple.com>
Incorrect inequality for checking whether a statement is within bounds of a handler
https://bugs.webkit.org/show_bug.cgi?id=104313
<rdar://problem/12808934>
Reviewed by Geoffrey Garen.
The most relevant change is in handlerForBytecodeOffset(), which fixes the inequality
used for checking whether a handler is pertinent to the current instruction. '<' is
correct, but '<=' isn't, since the 'end' is not inclusive.
Also found, and addressed, a benign goof in how the finally inliner works: sometimes
we will have end > start. This falls out naturally from how the inliner works and how
we pop scopes in the bytecompiler, but it's sufficiently surprising that, to avoid any
future confusion, I added a comment and some code to prune those handlers out. Because
of how the handler resolution works, these handlers would have been skipped anyway.
Also made various fixes to debugging code, which was necessary for tracking this down.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::handlerForBytecodeOffset):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
* bytecompiler/Label.h:
(JSC::Label::bind):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::throwException):
* llint/LLIntExceptions.cpp:
(JSC::LLInt::interpreterThrowInCaller):
(JSC::LLInt::returnToThrow):
(JSC::LLInt::callToThrow):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::handleHostCall):
2012-12-06 Rick Byers <rbyers@chromium.org>
CSS cursor property should support webkit-image-set
https://bugs.webkit.org/show_bug.cgi?id=99493
Reviewed by Beth Dakin.
Add ENABLE_MOUSE_CURSOR_SCALE (disabled by default)
* Configurations/FeatureDefines.xcconfig:
2012-12-06 Laszlo Gombos <l.gombos@samsung.com>
[CMake] Consolidate list of files to build for JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=104287
Reviewed by Gyuyoung Kim.
Add MemoryStatistics.cpp and ExecutableAllocator.cpp to the common
list of files and remove them from the port specific lists.
* CMakeLists.txt:
* PlatformBlackBerry.cmake:
* PlatformEfl.cmake:
* PlatformWinCE.cmake:
2012-12-06 Oliver Hunt <oliver@apple.com>
Tell heap that we've released all the compiled code.
Reviewed by Geoff Garen.
When we discard compiled code, inform the heap that we've
released an entire object graph. This informs the heap that
it might want to perform a GC soon.
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::discardAllCode):
2012-12-06 Laszlo Gombos <l.gombos@samsung.com>
[EFL] Remove ENABLE_GLIB_SUPPORT CMake variable
https://bugs.webkit.org/show_bug.cgi?id=104278
Reviewed by Brent Fulgham.
The conditional is not required as it is always set for EFL.
* PlatformEfl.cmake:
2012-12-06 Oliver Hunt <oliver@apple.com>
Build fix, last patch rolled out logic that is now needed on ToT.
* parser/ASTBuilder.h:
(ASTBuilder):
(JSC::ASTBuilder::setFunctionStart):
* parser/Nodes.h:
(JSC::FunctionBodyNode::setFunctionStart):
(JSC::FunctionBodyNode::functionStart):
(FunctionBodyNode):
* parser/Parser.cpp:
(JSC::::parseFunctionInfo):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::setFunctionStart):
2012-12-05 Oliver Hunt <oliver@apple.com>
Remove harmful string->function cache
https://bugs.webkit.org/show_bug.cgi?id=104193
Reviewed by Alexey Proskuryakov.
Remove the string->function code cache that turned out to actually
be quite harmful.
* runtime/CodeCache.cpp:
(JSC::CodeCache::getFunctionCodeBlock):
* runtime/CodeCache.h:
(JSC::CodeCache::clear):
2012-12-05 Halton Huo <halton.huo@intel.com>
[CMake] Unify coding style for CMake files
https://bugs.webkit.org/show_bug.cgi?id=103605
Reviewed by Laszlo Gombos.
Update cmake files(.cmake, CMakeLists.txt) with following style rules:
1. Indentation
1.1 Use spaces, not tabs.
1.2 Four spaces as indent.
2. Spacing
2.1 Place one space between control statements and their parentheses.
For eg, if (), else (), elseif (), endif (), foreach (),
endforeach (), while (), endwhile (), break ().
2.2 Do not place spaces between function and macro statements and
their parentheses. For eg, macro(), endmacro(), function(),
endfunction().
2.3 Do not place spaces between a command or function or macro and its
parentheses, or between a parenthesis and its content. For eg,
message("testing") not message( "testing") or message ("testing" )
2.4 No space at line ending.
3. Lowercase when call commands macros and functions. For eg,
add_executable() not ADD_EXECUTABLE(), set() not SET().
* CMakeLists.txt:
* PlatformBlackBerry.cmake:
* PlatformEfl.cmake:
* PlatformWinCE.cmake:
* shell/CMakeLists.txt:
* shell/PlatformBlackBerry.cmake:
* shell/PlatformEfl.cmake:
* shell/PlatformWinCE.cmake:
2012-12-05 Oliver Hunt <oliver@apple.com>
Empty parse cache when receiving a low memory warning
https://bugs.webkit.org/show_bug.cgi?id=104161
Reviewed by Filip Pizlo.
This adds a function to the globaldata to empty all code related data
structures (code in the heap and the code cache).
It also adds a function to allow the CodeCache to actually be cleared
at all.
* runtime/CodeCache.h:
(CacheMap):
(JSC::CacheMap::clear):
(JSC::CodeCache::clear):
(CodeCache):
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::discardAllCode):
(JSC):
* runtime/JSGlobalData.h:
(JSGlobalData):
2012-12-05 Filip Pizlo <fpizlo@apple.com>
JSC profiler should not count executions of op_call_put_result because doing so changes DFG codegen
https://bugs.webkit.org/show_bug.cgi?id=104102
Reviewed by Oliver Hunt.
This removes op_call_put_result from profiling, since profiling it has an effect on
codegen. This fix enables all of SunSpider, V8, and Kraken to be profiled with the
new profiler.
To make this all fit together, the profiler now also reports in its output the exact
bytecode opcode name for each instruction (in addition to the stringified dump of that
bytecode), so that tools that grok the output can take note of op_call_put_result and
work around the fact that it has no counts.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* profiler/ProfilerBytecode.cpp:
(JSC::Profiler::Bytecode::toJS):
* profiler/ProfilerBytecode.h:
(JSC::Profiler::Bytecode::Bytecode):
(JSC::Profiler::Bytecode::opcodeID):
(Bytecode):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
* runtime/CommonIdentifiers.h:
2012-12-04 Filip Pizlo <fpizlo@apple.com>
display-profiler-output should be able to show source code
https://bugs.webkit.org/show_bug.cgi?id=104073
Reviewed by Oliver Hunt.
Modify the profiler database to store source code. For functions, we store the
function including the function signature.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::unlinkedCodeBlock):
(CodeBlock):
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::Bytecodes):
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h:
(Bytecodes):
(JSC::Profiler::Bytecodes::sourceCode):
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::addBytecodes):
(JSC::Profiler::Database::ensureBytecodesFor):
* profiler/ProfilerDatabase.h:
(Database):
* runtime/CommonIdentifiers.h:
* runtime/Executable.h:
(FunctionExecutable):
(JSC::FunctionExecutable::unlinkedExecutable):
2012-12-02 Filip Pizlo <fpizlo@apple.com>
JSC should be able to report profiling data associated with the IR dumps and disassembly
https://bugs.webkit.org/show_bug.cgi?id=102999
Reviewed by Gavin Barraclough.
Added a new profiler to JSC. It's simply called "Profiler" in anticipation of it
ultimately replacing the previous profiling infrastructure. This profiler counts the
number of times that a bytecode executes in various engines, and will record both the
counts and all disassembly and bytecode dumps, into a database that can be at any
time turned into either a JS object using any global object or global data of your
choice, or can be turned into a JSON string, or saved to a file.
Currently the only use of this is the new '-p <file>' flag to the jsc command-line.
The profiler is always compiled in and normally incurs no execution time cost, but is
only activated when you create a Profiler::Database and install it in
JSGlobalData::m_perBytecodeProfiler. From that point on, all code blocks will be
compiled along with disassembly and bytecode dumps stored into the Profiler::Database,
and all code blocks will have execution counts, which are also stored in the database.
The database will continue to keep information about code blocks alive even after they
are otherwise GC'd.
This currently still has some glitches, like the fact that it only counts executions
in the JITs. Doing execution counting in the LLInt might require a bit of a rethink
about how the counting is expressed - currently it is implicit in bytecode, so there
is no easy way to "turn it on" in the LLInt. Also, right now there is no information
recorded about OSR exits or out-of-line stubs. But, even so, it's quite cool, and
gives you a peek into what JSC is doing that would otherwise not be possible.
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::baselineVersion):
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::baselineCodeBlock):
(JSC):
* bytecode/CodeOrigin.h:
(InlineCallFrame):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dump):
(DFG):
(JSC::DFG::Disassembler::reportToProfiler):
(JSC::DFG::Disassembler::dumpHeader):
(JSC::DFG::Disassembler::append):
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDisassembler.h:
(Disassembler):
(JSC::DFG::Disassembler::DumpedOp::DumpedOp):
(DumpedOp):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGNode.h:
(Node):
(JSC::DFG::Node::hasExecutionCounter):
(JSC::DFG::Node::executionCounter):
* 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):
* jit/JIT.cpp:
(JSC::JIT::JIT):
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JIT):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dump):
(JSC::JITDisassembler::reportToProfiler):
(JSC):
(JSC::JITDisassembler::dumpHeader):
(JSC::JITDisassembler::firstSlowLabel):
(JSC::JITDisassembler::dumpVectorForInstructions):
(JSC::JITDisassembler::dumpForInstructions):
(JSC::JITDisassembler::reportInstructions):
* jit/JITDisassembler.h:
(JITDisassembler):
(DumpedOp):
* jsc.cpp:
(CommandLine::CommandLine):
(CommandLine):
(printUsageStatement):
(CommandLine::parseArguments):
(jscmain):
* profiler/ProfilerBytecode.cpp: Added.
(Profiler):
(JSC::Profiler::Bytecode::toJS):
* profiler/ProfilerBytecode.h: Added.
(Profiler):
(Bytecode):
(JSC::Profiler::Bytecode::Bytecode):
(JSC::Profiler::Bytecode::bytecodeIndex):
(JSC::Profiler::Bytecode::description):
(JSC::Profiler::getBytecodeIndexForBytecode):
* profiler/ProfilerBytecodes.cpp: Added.
(Profiler):
(JSC::Profiler::Bytecodes::Bytecodes):
(JSC::Profiler::Bytecodes::~Bytecodes):
(JSC::Profiler::Bytecodes::indexForBytecodeIndex):
(JSC::Profiler::Bytecodes::forBytecodeIndex):
(JSC::Profiler::Bytecodes::dump):
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h: Added.
(Profiler):
(Bytecodes):
(JSC::Profiler::Bytecodes::append):
(JSC::Profiler::Bytecodes::id):
(JSC::Profiler::Bytecodes::hash):
(JSC::Profiler::Bytecodes::size):
(JSC::Profiler::Bytecodes::at):
* profiler/ProfilerCompilation.cpp: Added.
(Profiler):
(JSC::Profiler::Compilation::Compilation):
(JSC::Profiler::Compilation::~Compilation):
(JSC::Profiler::Compilation::addDescription):
(JSC::Profiler::Compilation::executionCounterFor):
(JSC::Profiler::Compilation::toJS):
* profiler/ProfilerCompilation.h: Added.
(Profiler):
(Compilation):
(JSC::Profiler::Compilation::bytecodes):
(JSC::Profiler::Compilation::kind):
* profiler/ProfilerCompilationKind.cpp: Added.
(WTF):
(WTF::printInternal):
* profiler/ProfilerCompilationKind.h: Added.
(Profiler):
(WTF):
* profiler/ProfilerCompiledBytecode.cpp: Added.
(Profiler):
(JSC::Profiler::CompiledBytecode::CompiledBytecode):
(JSC::Profiler::CompiledBytecode::~CompiledBytecode):
(JSC::Profiler::CompiledBytecode::toJS):
* profiler/ProfilerCompiledBytecode.h: Added.
(Profiler):
(CompiledBytecode):
(JSC::Profiler::CompiledBytecode::originStack):
(JSC::Profiler::CompiledBytecode::description):
* profiler/ProfilerDatabase.cpp: Added.
(Profiler):
(JSC::Profiler::Database::Database):
(JSC::Profiler::Database::~Database):
(JSC::Profiler::Database::addBytecodes):
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::newCompilation):
(JSC::Profiler::Database::toJS):
(JSC::Profiler::Database::toJSON):
(JSC::Profiler::Database::save):
* profiler/ProfilerDatabase.h: Added.
(Profiler):
(Database):
* profiler/ProfilerExecutionCounter.h: Added.
(Profiler):
(ExecutionCounter):
(JSC::Profiler::ExecutionCounter::ExecutionCounter):
(JSC::Profiler::ExecutionCounter::address):
(JSC::Profiler::ExecutionCounter::count):
* profiler/ProfilerOrigin.cpp: Added.
(Profiler):
(JSC::Profiler::Origin::Origin):
(JSC::Profiler::Origin::dump):
(JSC::Profiler::Origin::toJS):
* profiler/ProfilerOrigin.h: Added.
(JSC):
(Profiler):
(Origin):
(JSC::Profiler::Origin::Origin):
(JSC::Profiler::Origin::operator!):
(JSC::Profiler::Origin::bytecodes):
(JSC::Profiler::Origin::bytecodeIndex):
(JSC::Profiler::Origin::operator!=):
(JSC::Profiler::Origin::operator==):
(JSC::Profiler::Origin::hash):
(JSC::Profiler::Origin::isHashTableDeletedValue):
(JSC::Profiler::OriginHash::hash):
(JSC::Profiler::OriginHash::equal):
(OriginHash):
(WTF):
* profiler/ProfilerOriginStack.cpp: Added.
(Profiler):
(JSC::Profiler::OriginStack::OriginStack):
(JSC::Profiler::OriginStack::~OriginStack):
(JSC::Profiler::OriginStack::append):
(JSC::Profiler::OriginStack::operator==):
(JSC::Profiler::OriginStack::hash):
(JSC::Profiler::OriginStack::dump):
(JSC::Profiler::OriginStack::toJS):
* profiler/ProfilerOriginStack.h: Added.
(JSC):
(Profiler):
(OriginStack):
(JSC::Profiler::OriginStack::OriginStack):
(JSC::Profiler::OriginStack::operator!):
(JSC::Profiler::OriginStack::size):
(JSC::Profiler::OriginStack::fromBottom):
(JSC::Profiler::OriginStack::fromTop):
(JSC::Profiler::OriginStack::isHashTableDeletedValue):
(JSC::Profiler::OriginStackHash::hash):
(JSC::Profiler::OriginStackHash::equal):
(OriginStackHash):
(WTF):
* runtime/CommonIdentifiers.h:
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
* runtime/JSGlobalData.cpp:
(JSC::JSGlobalData::JSGlobalData):
(JSC::JSGlobalData::~JSGlobalData):
* runtime/JSGlobalData.h:
(JSGlobalData):
* runtime/Options.h:
(JSC):
2012-12-04 Filip Pizlo <fpizlo@apple.com>
Rename Profiler to LegacyProfiler
https://bugs.webkit.org/show_bug.cgi?id=104031
Rubber stamped by Mark Hahnenberg
Make room in the namespace for https://bugs.webkit.org/show_bug.cgi?id=102999.
* API/JSProfilerPrivate.cpp:
(JSStartProfiling):
(JSEndProfiling):
* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::throwException):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JIT.h:
* jit/JITCode.h:
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* jit/JITStubs.h:
(JSC):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* profiler/LegacyProfiler.cpp: Added.
(JSC):
(JSC::LegacyProfiler::profiler):
(JSC::LegacyProfiler::startProfiling):
(JSC::LegacyProfiler::stopProfiling):
(JSC::dispatchFunctionToProfiles):
(JSC::LegacyProfiler::willExecute):
(JSC::LegacyProfiler::didExecute):
(JSC::LegacyProfiler::exceptionUnwind):
(JSC::LegacyProfiler::createCallIdentifier):
(JSC::createCallIdentifierFromFunctionImp):
* profiler/LegacyProfiler.h: Added.
(JSC):
(LegacyProfiler):
(JSC::LegacyProfiler::currentProfiles):
* profiler/ProfileGenerator.cpp:
(JSC::ProfileGenerator::addParentForConsoleStart):
* profiler/ProfileNode.cpp:
* profiler/Profiler.cpp: Removed.
* profiler/Profiler.h: Removed.
* runtime/JSGlobalData.h:
(JSC):
(JSC::JSGlobalData::enabledProfiler):
(JSGlobalData):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::~JSGlobalObject):
2012-12-03 Filip Pizlo <fpizlo@apple.com>
DFG should inline code blocks that use scoped variable access
https://bugs.webkit.org/show_bug.cgi?id=103974
Reviewed by Oliver Hunt.
This mostly just turns on something we could have done all along, but also adds a few key
necessities to make this right:
1) Constant folding of SkipScope, since if we inline with a known JSFunction* then the
scope is constant.
2) Interference analysis for GetLocal<->PutScopedVar and SetLocal<->GetScopedVar.
This is not meant to be a speed-up on major benchmarks since we don't yet inline most
closure calls for entirely unrelated reasons. But on toy programs it can be >2x faster.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getScope):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::scopedVarLoadElimination):
(JSC::DFG::CSEPhase::scopedVarStoreElimination):
(JSC::DFG::CSEPhase::getLocalLoadElimination):
(JSC::DFG::CSEPhase::setLocalStoreElimination):
* dfg/DFGCapabilities.h:
(JSC::DFG::canInlineResolveOperations):
2012-12-03 Filip Pizlo <fpizlo@apple.com>
Replace JSValue::description() with JSValue::dump(PrintStream&)
https://bugs.webkit.org/show_bug.cgi?id=103866
Reviewed by Darin Adler.
JSValue now has a dump() method. Anywhere that you would have wanted to use
description(), you can either do toCString(value).data(), or if the callee
is a print()/dataLog() method then you just pass the value directly.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
* bytecode/CodeBlock.cpp:
(JSC::valueToSourceString):
(JSC::CodeBlock::finalizeUnconditionally):
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::dump):
* bytecode/ValueRecovery.h:
(JSC::ValueRecovery::dump):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::dump):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::dumpRegisters):
* jsc.cpp:
(functionDescribe):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_trace_value):
* runtime/JSValue.cpp:
(JSC::JSValue::dump):
* runtime/JSValue.h:
2012-12-04 Filip Pizlo <fpizlo@apple.com>
jsc command line tool's support for typed arrays should be robust against array buffer allocation errors
https://bugs.webkit.org/show_bug.cgi?id=104020
<rdar://problem/12802478>
Reviewed by Mark Hahnenberg.
Check for null buffers, since that's what typed array allocators are supposed to do. WebCore does it,
and that is indeed the contract of ArrayBuffer and TypedArrayBase.
* JSCTypedArrayStubs.h:
(JSC):
2012-12-03 Peter Rybin <prybin@chromium.org>
Web Inspector: make ASSERTION FAILED: foundPropertiesCount == object->size() more useful
https://bugs.webkit.org/show_bug.cgi?id=103254
Reviewed by Pavel Feldman.
Missing symbol WTFReportFatalError is added to the linker list.
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
2012-12-03 Alexis Menard <alexis@webkit.org>
[Mac] Enable CSS3 background-position offset by default.
https://bugs.webkit.org/show_bug.cgi?id=103905
Reviewed by Simon Fraser.
Turn the flag on by default.
* Configurations/FeatureDefines.xcconfig:
2012-12-02 Filip Pizlo <fpizlo@apple.com>
DFG should trigger rage conversion from double to contiguous if it sees a GetByVal on Double being used in an integer context
https://bugs.webkit.org/show_bug.cgi?id=103858
Reviewed by Gavin Barraclough.
A rage conversion from double to contiguous is one where you try to convert each
double to an int32.
This is probably not the last we'll hear of rage conversion from double to contiguous.
It may be better to do this right during parsing, which will result in fewer cases of
Arrayification. But even so, this looks like a straight win already - 1% speed-up on
Kraken, no major regression anywhere else.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine):
(JSC::DFG::arrayConversionToString):
(JSC::DFG::ArrayMode::dump):
(WTF):
(WTF::printInternal):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::withConversion):
(ArrayMode):
(JSC::DFG::ArrayMode::doesConversion):
(WTF):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupBlock):
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::checkArray):
(FixupPhase):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):
* dfg/DFGNodeFlags.h:
(DFG):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::arrayify):
* dfg/DFGStructureCheckHoistingPhase.cpp:
(JSC::DFG::StructureCheckHoistingPhase::run):
* runtime/JSObject.cpp:
(JSC):
(JSC::JSObject::genericConvertDoubleToContiguous):
(JSC::JSObject::convertDoubleToContiguous):
(JSC::JSObject::rageConvertDoubleToContiguous):
(JSC::JSObject::ensureContiguousSlow):
(JSC::JSObject::rageEnsureContiguousSlow):
* runtime/JSObject.h:
(JSObject):
(JSC::JSObject::rageEnsureContiguous):
2012-12-02 Filip Pizlo <fpizlo@apple.com>
DFG CSE should not keep alive things that aren't relevant to OSR
https://bugs.webkit.org/show_bug.cgi?id=103849
Reviewed by Oliver Hunt.
Most Phantom nodes are inserted by CSE, and by default have the same children as the
node that CSE had eliminated. This change makes CSE inspect all Phantom nodes (both
those it creates and those that were created by other phases) to see if they have
children that are redundant - i.e. children that are not interesting to OSR, which
is the only reason why Phantoms exist in the first place. Being relevant to OSR is
defined as one of: (1) you're a Phi, (2) you're a SetLocal, (3) somewhere between
your definition and the Phantom there was a SetLocal that referred to you.
This is a slight speed-up in a few places.
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::CSEPhase):
(JSC::DFG::CSEPhase::run):
(JSC::DFG::CSEPhase::performSubstitution):
(CSEPhase):
(JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
(JSC::DFG::CSEPhase::setReplacement):
(JSC::DFG::CSEPhase::eliminate):
(JSC::DFG::CSEPhase::performNodeCSE):
(JSC::DFG::CSEPhase::performBlockCSE):
2012-12-02 Filip Pizlo <fpizlo@apple.com>
It should be possible to build and run with DFG_ENABLE(PROPAGATION_VERBOSE)
https://bugs.webkit.org/show_bug.cgi?id=103848
Reviewed by Sam Weinig.
Fix random dataLog() and print() statements.
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpBlockHeader):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGStructureCheckHoistingPhase.cpp:
(JSC::DFG::StructureCheckHoistingPhase::run):
2012-12-01 Filip Pizlo <fpizlo@apple.com>
CodeBlock should be able to dump bytecode to something other than WTF::dataFile()
https://bugs.webkit.org/show_bug.cgi?id=103832
Reviewed by Oliver Hunt.
Add a PrintStream& argument to all of the CodeBlock bytecode dumping methods.
* 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::dumpBytecode):
* bytecode/CodeBlock.h:
(CodeBlock):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dumpForInstructions):
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 Oliver Hunt <oliver@apple.com>
Optimise more cases of op_typeof
https://bugs.webkit.org/show_bug.cgi?id=103783
Reviewed by Mark Hahnenberg.
Increase our coverage of typeof based typechecks by
making sure that the codegenerators always uses
consistent operand ordering when feeding typeof operations
into equality operations.
* bytecompiler/NodesCodegen.cpp:
(JSC::BinaryOpNode::emitBytecode):
(JSC::EqualNode::emitBytecode):
(JSC::StrictEqualNode::emitBytecode):
2012-11-30 Filip Pizlo <fpizlo@apple.com>
Rationalize and clean up DFG handling of scoped accesses
https://bugs.webkit.org/show_bug.cgi?id=103715
Reviewed by Oliver Hunt.
Previously, we had a GetScope node that specified the depth to which you wanted
to travel to get a JSScope, and the backend implementation of the node would
perform all of the necessary footwork, including potentially skipping the top
scope if necessary, and doing however many loads were needed. But there were
strange things. First, if you had accesses at different scope depths, then the
loads to get to the common depth could not be CSE'd - CSE would match only
GetScope's that had identical depth. Second, GetScope would be emitted even if
we already had the scope, for example in put_to_base. And finally, even though
the ResolveOperations could tell us whether or not we had to skip the top scope,
the backend would recompute this information itself, often pessimistically.
This eliminates GetScope and replaces it with the following:
GetMyScope: just get the JSScope from the call frame header. This will forever
mean getting the JSScope associated with the machine call frame; it will not
mean getting the scope of an inlined function. Or at least that's the intent.
SkipTopScope: check if there is an activation, and if so, skip a scope. This
takes a scope as a child and returns a scope.
SkipScope: skip one scope level.
The bytecode parser now emits the right combination of the above, and
potentially emits multiple SkipScope's, based on the ResolveOperations.
This change also includes some fixups to debug logging. We now always print
the ExecutableBase* in addition to the CodeBlock* in the CodeBlock's dump,
and we are now more verbose when dumping CodeOrigins and InlineCallFrames.
This is performance-neutral. It's just meant to be a clean-up.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpAssumingJITType):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::inlineStack):
(JSC::CodeOrigin::dump):
(JSC):
(JSC::InlineCallFrame::dump):
* bytecode/CodeOrigin.h:
(CodeOrigin):
(InlineCallFrame):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::execute):
* dfg/DFGByteCodeParser.cpp:
(ByteCodeParser):
(JSC::DFG::ByteCodeParser::getScope):
(DFG):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::scopedVarLoadElimination):
(JSC::DFG::CSEPhase::scopedVarStoreElimination):
(JSC::DFG::CSEPhase::getMyScopeLoadElimination):
(JSC::DFG::CSEPhase::setLocalStoreElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dump):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dumpBlockHeader):
* dfg/DFGNode.h:
(Node):
* 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):
* jit/JITDisassembler.cpp:
(JSC::JITDisassembler::dump):
2012-11-30 Oliver Hunt <oliver@apple.com>
Add direct string->function code cache
https://bugs.webkit.org/show_bug.cgi?id=103764
Reviewed by Michael Saboff.
A fairly logically simple patch. We now track the start of the
unique portion of a functions body, and use that as our key for
unlinked function code. This allows us to cache identical code
in different contexts, leading to a small but consistent improvement
on the benchmarks we track.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedFunctionExecutable::functionStartOffset):
(UnlinkedFunctionExecutable):
* parser/ASTBuilder.h:
(ASTBuilder):
(JSC::ASTBuilder::setFunctionStart):
* parser/Nodes.cpp:
* parser/Nodes.h:
(JSC::FunctionBodyNode::setFunctionStart):
(JSC::FunctionBodyNode::functionStart):
(FunctionBodyNode):
* parser/Parser.cpp:
(JSC::::parseFunctionInfo):
* parser/Parser.h:
(JSC::Parser::findCachedFunctionInfo):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::setFunctionStart):
* runtime/CodeCache.cpp:
(JSC::CodeCache::generateFunctionCodeBlock):
(JSC::CodeCache::getFunctionCodeBlock):
(JSC::CodeCache::usedFunctionCode):
* runtime/CodeCache.h:
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 Michael Saboff.
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 &quot; in argument values
https://bugs.webkit.org/show_bug.cgi?id=90667
Reviewed by Benjamin Poulain.
Escape quotation mark as &quot; 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 ==