diff options
Diffstat (limited to 'Source/JavaScriptCore/ChangeLog-2012-10-02')
| -rw-r--r-- | Source/JavaScriptCore/ChangeLog-2012-10-02 | 20888 |
1 files changed, 20888 insertions, 0 deletions
diff --git a/Source/JavaScriptCore/ChangeLog-2012-10-02 b/Source/JavaScriptCore/ChangeLog-2012-10-02 new file mode 100644 index 000000000..ded22e693 --- /dev/null +++ b/Source/JavaScriptCore/ChangeLog-2012-10-02 @@ -0,0 +1,20888 @@ +2012-10-02 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r128400): ASSERT (crash in release) @ app.asana.com + https://bugs.webkit.org/show_bug.cgi?id=98175 + + Reviewed by Oliver Hunt. + + It's bad karma to create a new structure while stealing another structure's property table + while leaving the m_offset unset. Eventually someone will then steal your property table, and + then you won't know how many properties you have anymore. + + * runtime/Structure.cpp: + (JSC::Structure::nonPropertyTransition): + +2012-10-02 Michael Saboff <msaboff@apple.com> + + Comment additions after r130109 + + Rubber stamped by Geoffrey Garen. + + Updated comments to how array storage works. + + * runtime/ArrayStorage.h: + * runtime/JSArray.cpp: + +2012-10-01 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. + + Currently the block freeing thread wakes up once a second to check if there are any blocks + for it to release back to the OS. This is wasteful. We should change it to sleep when it + realizes there are no more blocks to free. Any thread that returns a block to the BlockAllocator + should then notify the block freeing thread that there is more work to do now. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + (JSC::BlockAllocator::blockFreeingThreadMain): + * heap/BlockAllocator.h: + (BlockAllocator): + (JSC::BlockAllocator::deallocate): + +2012-10-01 Michael Saboff <msaboff@apple.com> + + JSArray::unshiftCountSlowCase needs to clear array slots when adding space to end of array + https://bugs.webkit.org/show_bug.cgi?id=98101 + + Reviewed by Filip Pizlo. + + Cleared new array entries when adding to end due to shifting contents to lower memory. Also + checnaged the order of moving array contents and metadata in the shift left case to avoid + clobbering the metadata with array contents. Optimized the to only make a memmove if the + count is non-zero. + + * runtime/JSArray.cpp: + (JSC::JSArray::unshiftCountSlowCase): + (JSC::JSArray::unshiftCount): + +2012-10-01 Filip Pizlo <fpizlo@apple.com> + + Address a FIXME in JSArray::sort + https://bugs.webkit.org/show_bug.cgi?id=98080 + <rdar://problem/12407844> + + Reviewed by Oliver Hunt. + + Get rid of fast sorting of sparse maps. I don't know that it's broken but I do know that we don't + have coverage for it. Then also address the FIXME in JSArray::sort regarding side-effecting + compare functions. + + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncSort): + * runtime/JSArray.cpp: + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + * runtime/JSArray.h: + (JSArray): + * runtime/JSObject.h: + (JSC::JSObject::hasSparseMap): + (JSObject): + +2012-10-01 Jonathan Liu <net147@gmail.com> + + Remove unused sys/mman.h include + https://bugs.webkit.org/show_bug.cgi?id=97995 + + Reviewed by Kentaro Hara. + + The sys/mman.h is not used and removing it improves portability as not + all systems have sys/mman.h. + + * jit/ExecutableAllocatorFixedVMPool.cpp: + +2012-09-28 Filip Pizlo <fpizlo@apple.com> + + ASSERTION in m_graph[tailNodeIndex].op() == Flush || m_graph[tailNodeIndex].op() == SetLocal on plus.google.com + https://bugs.webkit.org/show_bug.cgi?id=97656 + + Reviewed by Mark Hahnenberg. + + There were two bugs here: + + 1) In case of multiple GetLocals to the same captured variable, the bytecode parser would linke the first, + rather than the last, of the GetLocals into the vars-at-tail table. + + 2) The constant folding phase was asserting that any GetLocal it eliminates must be linked into the + vars-at-tail table, when for captured variables only the last of those should be. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getLocal): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2012-09-28 Filip Pizlo <fpizlo@apple.com> + + DFGStructureHoistingPhase SetLocal assumes StructureTransitionWatchpoint has a structure set + https://bugs.webkit.org/show_bug.cgi?id=97810 + + Reviewed by Mark Hahnenberg. + + No tests because this can't happen in ToT: the structure check hoisting phase runs before any + CFA or folding, so the only StructureTransitionWatchpoints it will see are the ones inserted + by the parser. But the parser will only insert StructureTransitinWatchpoints on constants, which + will not be subject to SetLocals. + + Still, it would be good to fix this in case things changed. + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-09-27 Mark Lam <mark.lam@apple.com> + + Put initializeHostCallReturnValue() behind #if ENABLE(JIT). + Fixes non JIT builds. + https://bugs.webkit.org/show_bug.cgi?id=97838. + + Reviewed by John Sullivan. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + +2012-09-27 Mark Lam <mark.lam@apple.com> + + Fixed CallFrameClosure::resetCallFrame() to use the valid + range of argument index values. + https://bugs.webkit.org/show_bug.cgi?id=97836. + + Reviewed by Gavin Barraclough. + + * interpreter/CallFrame.h: + (ExecState): + * interpreter/CallFrameClosure.h: + (JSC::CallFrameClosure::resetCallFrame): + +2012-09-27 Patrick Gansterer <paroga@webkit.org> + + Fix usage of COMPILER() macros + https://bugs.webkit.org/show_bug.cgi?id=97642 + + Reviewed by Geoffrey Garen. + + Add COMPILER(GCC) around compiler specific code and remove it from generic code. + This allows us to implement the DFG code for other compilers to in a next step. + + * dfg/DFGOperations.cpp: + * jit/HostCallReturnValue.h: + +2012-09-27 Andreas Kling <kling@webkit.org> + + 3.20MB below FunctionParameters::create() on Membuster3. + <http://webkit.org/b/97730> + + Reviewed by Anders Carlsson. + + Figure out the exact space needed for parameter identifiers and use reserveInitialCapacity(). + Reduces memory consumption on Membuster3 by ~1.60 MB. + + * parser/Nodes.cpp: + (JSC::FunctionParameters::FunctionParameters): + +2012-09-27 Csaba Osztrogonác <ossy@webkit.org>, Tor Arne Vestbø <vestbo@webkit.org> + + [Qt] Enable the LLInt on Linux + https://bugs.webkit.org/show_bug.cgi?id=95749 + + Reviewed by Simon Hausmann. + + * DerivedSources.pri: + * JavaScriptCore.pro: + * LLIntOffsetsExtractor.pro: Added. + * Target.pri: + +2012-09-27 Patrick Gansterer <paroga@webkit.org> + + [CMake] Fix build with static JavaScriptCore library + + * shell/CMakeLists.txt: Define STATICALLY_LINKED_WITH_JavaScriptCore if + JavaScriptCore_LIBRARY_TYPE is set to STATIC. + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + Proxy the global this in JSC + https://bugs.webkit.org/show_bug.cgi?id=97734 + + Reviewed by Filip Pizlo. + + Eeep – fix a bug - was leaving the global this proxy's structure's globalObject as 0, + and setting the proxy's prototype as the global object, rather than its prototype. + + * jsc.cpp: + (GlobalObject::create): + * runtime/JSProxy.h: + (JSC::JSProxy::createStructure): + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + Speculative Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-26 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, 32-bit build fix. + + * llint/LowLevelInterpreter32_64.asm: + +2012-09-26 Filip Pizlo <fpizlo@apple.com> + + jneq_ptr shouldn't have a pointer + https://bugs.webkit.org/show_bug.cgi?id=97739 + + Reviewed by Oliver Hunt. + + Slamming pointers directly into bytecode is sometimes cool, but in this case it's + unwieldy and confusing. Switched the instruction to use an enum instead. This has + zero effect on code gen behavior in the JITs. In the LLInt, there is now more + indirection, but that doesn't affect benchmarks. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/Instruction.h: + (JSC::Instruction::Instruction): + (Instruction): + * bytecode/SpecialPointer.cpp: Added. + (JSC): + (JSC::actualPointerFor): + * bytecode/SpecialPointer.h: Added. + (JSC): + (JSC::pointerIsFunction): + (JSC::pointerIsCell): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall): + (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_jneq_ptr): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_jneq_ptr): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::actualPointerFor): + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms + https://bugs.webkit.org/show_bug.cgi?id=97529 + + Reviewed by Filip Pizlo. + + A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers. + + JSC currently throws an EvalError if you try to call eval with a this object that doesn't + match the given eval function. This does not match other browsers, which generally just + ignore the this value that was passed, and eval the string in the eval function's environment. + + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncEval): + - Remove EvalError, ignore passed this value. + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + Proxy the global this in JSC + https://bugs.webkit.org/show_bug.cgi?id=97734 + + Reviewed by Oliver Hunt. + + Having jsc diverge from WebCore here is not beneficial; it potentially masks bugs and/or performance + problems from command line testing. + + * jsc.cpp: + (GlobalObject::create): + - Create a this value proxy for the global object. + * runtime/JSGlobalObject.h: + (JSGlobalObject): + - Make setGlobalThis protected. + * runtime/JSProxy.h: + (JSC::JSProxy::create): + (JSC::JSProxy::target): + (JSC::JSProxy::finishCreation): + (JSProxy): + - Allow proxy target to be a JSObject, add target to create method. + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + Speculative Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-26 Filip Pizlo <fpizlo@apple.com> + + JSObject::ensureArrayStorage() ignores the possibility that extensions have been prevented + https://bugs.webkit.org/show_bug.cgi?id=97719 + + Reviewed by Gavin Barraclough. + + * runtime/JSObject.cpp: + (JSC::JSObject::ensureArrayStorageSlow): + (JSC): + * runtime/JSObject.h: + (JSC::JSObject::ensureArrayStorage): + (JSObject): + +2012-09-26 Gavin Barraclough <barraclough@apple.com> + + Generalize JSGlobalThis as JSProxy + https://bugs.webkit.org/show_bug.cgi?id=97716 + + Reviewed by Oliver Hunt. + + Generalize JSGlobalThis as JSProxy and move proxying functionality up from the window shell into JSProxy. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::toThisObject): + - Hoist toThisObject from WebCore. + (JSC): + * runtime/JSGlobalObject.h: + - removed include. + (JSC::JSGlobalObject::finishCreation): + - JSGlobalThis -> JSObject + (JSGlobalObject): + - Hoist toThisObject from WebCore. + * runtime/JSGlobalThis.cpp: Removed. + * runtime/JSGlobalThis.h: Removed. + * runtime/JSObject.cpp: + - removed include. + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::isProxy): + - isGlobalThis -> isProxy + - GlobalThisType -> ProxyType + * runtime/JSProxy.cpp: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.cpp. + (JSC): + (JSC::JSProxy::visitChildren): + (JSC::JSProxy::setTarget): + (JSC::JSProxy::className): + (JSC::JSProxy::getOwnPropertySlot): + (JSC::JSProxy::getOwnPropertySlotByIndex): + (JSC::JSProxy::getOwnPropertyDescriptor): + (JSC::JSProxy::put): + (JSC::JSProxy::putByIndex): + (JSC::JSProxy::putDirectVirtual): + (JSC::JSProxy::defineOwnProperty): + (JSC::JSProxy::deleteProperty): + (JSC::JSProxy::deletePropertyByIndex): + (JSC::JSProxy::getPropertyNames): + (JSC::JSProxy::getOwnPropertyNames): + - Class cretaed from JSGlobalThis, JSDOMWindowShell. + * runtime/JSProxy.h: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.h. + (JSC::JSProxy::create): + (JSC::JSProxy::createStructure): + (JSProxy): + (JSC::JSProxy::target): + (JSC::JSProxy::JSProxy): + - Class cretaed from JSGlobalThis, JSDOMWindowShell. + * runtime/JSType.h: + - GlobalThisType -> ProxyType + +2012-09-26 Michael Saboff <msaboff@apple.com> + + Add ability for JSArray::unshiftCount to unshift in middle of an array + https://bugs.webkit.org/show_bug.cgi?id=97691 + + Reviewed by Filip Pizlo. + + Changed JSArray::unshiftCount and unshiftCountSlowCase to handle unshifting from the middle of an + array. Depending on where the unshift point is, either the front part of the array will be moved + "left" or the back part will be moved right. Given that unshiftCount only works on contiguous + arrays it is safe to use memmove for the moves. + + This change is worth 25% performance improvement on pdfjs. It doesn't seem to have any impact on + any other benchmarks. + + * runtime/ArrayPrototype.cpp: + (JSC::unshift): + * runtime/JSArray.cpp: + (JSC::JSArray::unshiftCountSlowCase): + (JSC::JSArray::unshiftCount): + * runtime/JSArray.h: + (JSArray): + +2012-09-26 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r129592. + http://trac.webkit.org/changeset/129592 + https://bugs.webkit.org/show_bug.cgi?id=97670 + + Failures in Chromium security tests (Requested by schenney on + #webkit). + + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncEval): + +2012-09-25 Gavin Barraclough <barraclough@apple.com> + + REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms + https://bugs.webkit.org/show_bug.cgi?id=97529 + + Reviewed by Filip Pizlo. + + A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers. + + JSC currently throws an EvalError if you try to call eval with a this object that doesn't + match the given eval function. This does not match other browsers, which generally just + ignore the this value that was passed, and eval the string in the eval function's environment. + + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncEval): + - Remove EvalError, ignore passed this value. + +2012-09-25 Filip Pizlo <fpizlo@apple.com> + + DFG ArrayPush, ArrayPop don't handle clobbering or having a bad time correctly + https://bugs.webkit.org/show_bug.cgi?id=97535 + + Reviewed by Oliver Hunt. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleIntrinsic): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-09-25 Geoffrey Garen <ggaren@apple.com> + + JSC should dump object size inference statistics + https://bugs.webkit.org/show_bug.cgi?id=97618 + + Reviewed by Filip Pizlo. + + Added an option to dump object size inference statistics. + + To see statistics on live objects: + + jsc --showHeapStatistics=1 + + To see cumulative statistics on all objects ever allocated: + + jsc --showHeapStatistics=1 --objectsAreImmortal=1 + + (This is useful for showing GC churn caused by over-allocation.) + + To support this second mode, I refactored Zombies to separate out their + immortality feature so I could reuse it. + + * heap/Heap.cpp: + (JSC::MarkObject): Helper for making things immortal. We have to checked + for being zapped because blocks start out in this state. + + (JSC::StorageStatistics): Gather statistics by walking the heap. Ignore + arrays and hash tables for now because they're not our focus. (We'll + remove these exceptions in future.) + + (JSC::Heap::collect): Moved zombify to the end so it wouldn't interfere + with statistics gathering. + + (JSC::Heap::showStatistics): + (JSC::Heap::markAllObjects): Factored out helper, so statistics could + take advantage of immortal objects. + + (Zombify): Don't mark immortal objects -- that's another class's job now. + + (JSC::Zombify::operator()): + (JSC::Heap::zombifyDeadObjects): Take advantage of forEachDeadCell instead + of rolling our own. + + * heap/Heap.h: + (Heap): + * heap/MarkedSpace.h: + (MarkedSpace): + (JSC::MarkedSpace::forEachDeadCell): Added, so clients don't have to do + the iteration logic themselves. + + * runtime/Options.cpp: + (JSC::Options::initialize): + * runtime/Options.h: New options, listed above. Make sure to initialize + based on environment variable first, so we can override with specific settings. + +2012-09-25 Filip Pizlo <fpizlo@apple.com> + + We shouldn't use the optimized versions of shift/unshift if the user is doing crazy things to the array + https://bugs.webkit.org/show_bug.cgi?id=97603 + <rdar://problem/12370864> + + Reviewed by Gavin Barraclough. + + You changed the length behind our backs? No optimizations for you then! + + * runtime/ArrayPrototype.cpp: + (JSC::shift): + (JSC::unshift): + * runtime/JSArray.cpp: + (JSC::JSArray::shiftCount): + +2012-09-25 Filip Pizlo <fpizlo@apple.com> + + JSC bindings appear to sometimes ignore the possibility of arrays being in sparse mode + https://bugs.webkit.org/show_bug.cgi?id=95610 + + Reviewed by Oliver Hunt. + + Add better support for quickly accessing the indexed storage from bindings. + + * runtime/JSObject.h: + (JSC::JSObject::tryGetIndexQuickly): + (JSObject): + (JSC::JSObject::getDirectIndex): + (JSC::JSObject::getIndex): + +2012-09-25 Filip Pizlo <fpizlo@apple.com> + + Structure check hoisting phase doesn't know about the side-effecting nature of Arrayify + https://bugs.webkit.org/show_bug.cgi?id=97537 + + Reviewed by Mark Hahnenberg. + + No tests because if we use Arrayify then we also use PutByVal(BlankToXYZ), and the latter is + already known to be side-effecting. So this bug shouldn't have had any symptoms, as far as I + can tell. + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-09-25 Gavin Barraclough <barraclough@apple.com> + + Regression: put beyond vector length prefers prototype setters to sparse properties + https://bugs.webkit.org/show_bug.cgi?id=97593 + + Reviewed by Geoff Garen & Filip Pizlo. + + * runtime/JSObject.cpp: + (JSC::JSObject::putByIndexBeyondVectorLength): + - Check for self properties in the sparse map - if present, don't examine the protochain. + +2012-09-24 Gavin Barraclough <barraclough@apple.com> + + https://bugs.webkit.org/show_bug.cgi?id=97530 + Regression, freeze applied to numeric properties of non-array objects + + Reviewed by Filip Pizlo. + + Object.freeze has a fast implementation in JSObject, but this hasn't been updated to take into account numeric properties in butterflies. + For now, just fall back to the generic implementation if the object has numeric properties. + + * runtime/ObjectConstructor.cpp: + (JSC::objectConstructorFreeze): + - fallback if the object has a non-zero indexed property vector length. + +2012-09-24 Gavin Barraclough <barraclough@apple.com> + + Bug in numeric accessors on global environment + https://bugs.webkit.org/show_bug.cgi?id=97526 + + Reviewed by Geoff Garen. + + I've hit this assert in test262 in browser, but haven't yet worked out how to repro in a test case :-/ + The sparsemap is failing to map back from the global object to the window shell. + A test case would need to resolve a numeric property name against the global environment. + + (JSC::SparseArrayEntry::get): + (JSC::SparseArrayEntry::put): + - Add missing toThisObject calls. + +2012-09-24 Filip Pizlo <fpizlo@apple.com> + + SerializedScriptValue isn't aware of indexed storage, but should be + https://bugs.webkit.org/show_bug.cgi?id=97515 + <rdar://problem/12361874> + + Reviewed by Sam Weinig. + + Export a method that WebCore now uses. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * runtime/JSObject.h: + (JSObject): + +2012-09-24 Gavin Barraclough <barraclough@apple.com> + + Remove JSObject::unwrappedGlobalObject(), JSObject::unwrappedObject() + https://bugs.webkit.org/show_bug.cgi?id=97519 + + Reviewed by Geoff Garen. + + unwrappedGlobalObject() was only needed because globalObject() doesn't always return a helpful result - + specifically for WebCore's window shell the structure's globalObject is set to null. We can fix this by + simply keeping the structure up to date as the window navigates, obviating the need for this function. + + The only other use of unwrappedObject() came from globalFuncEval(), and this can be trivially removed + by flipping the way we perform this globalObject check (which we may also be able to remove!) - instead + of getting the globalObject from the provided this value & comparing to the expected globalObject, we + can get the this value from the expected globalObject, and compare to that provided. + + * runtime/JSGlobalObject.cpp: + - Call globalObject() instead of unwrappedGlobalObject(). + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncEval): + - Changed to compare this object values, instead of globalObjects - + this means we only need to be able to map globalObject -> this, + and not vice versa. + * runtime/JSObject.cpp: + (JSC::JSObject::allowsAccessFrom): + (JSC::JSObject::createInheritorID): + - Call globalObject() instead of unwrappedGlobalObject(). + * runtime/JSObject.h: + (JSObject): + - Removed unwrappedGlobalObject(), unwrappedObject(). + +2012-09-24 Mark Lam <mark.lam@apple.com> + + Deleting the classic interpreter and cleaning up some build options. + https://bugs.webkit.org/show_bug.cgi?id=96969. + + Reviewed by Geoffrey Garen. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::stronglyVisitStrongReferences): + (JSC): + * bytecode/Instruction.h: + (JSC::Instruction::Instruction): + * interpreter/AbstractPC.cpp: + (JSC::AbstractPC::AbstractPC): + * interpreter/AbstractPC.h: + (AbstractPC): + * interpreter/CallFrame.h: + (ExecState): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::Interpreter): + (JSC::Interpreter::~Interpreter): + (JSC::Interpreter::initialize): + (JSC::Interpreter::isOpcode): + (JSC::Interpreter::unwindCallFrame): + (JSC::getLineNumberForCallFrame): + (JSC::getCallerInfo): + (JSC::getSourceURLFromCallFrame): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::retrieveArgumentsFromVMCode): + (JSC::Interpreter::retrieveCallerFromVMCode): + (JSC::Interpreter::retrieveLastCaller): + * interpreter/Interpreter.h: + (JSC::Interpreter::getOpcodeID): + (Interpreter): + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): + * offlineasm/asm.rb: + * offlineasm/offsets.rb: + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + * runtime/Executable.h: + (JSC::NativeExecutable::create): + (NativeExecutable): + (JSC::NativeExecutable::finishCreation): + * runtime/JSGlobalData.cpp: + (JSC): + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::getHostFunction): + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::canUseJIT): + (JSC::JSGlobalData::canUseRegExpJIT): + * runtime/Options.cpp: + (JSC::Options::initialize): + +2012-09-24 Filip Pizlo <fpizlo@apple.com> + + Nested try/finally should not confuse the finally unpopper in BytecodeGenerator::emitComplexJumpScopes + https://bugs.webkit.org/show_bug.cgi?id=97508 + <rdar://problem/12361132> + + Reviewed by Sam Weinig. + + We're reusing some vector for multiple iterations of a loop, but we were forgetting to clear its + contents from one iteration to the next. Hence if you did multiple iterations of finally unpopping + (like in a nested try/finally and a jump out of both of them) then you'd get a corrupted try + context stack afterwards. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitComplexJumpScopes): + +2012-09-24 Filip Pizlo <fpizlo@apple.com> + + ValueToInt32 bool case does bad things to registers + https://bugs.webkit.org/show_bug.cgi?id=97505 + <rdar://problem/12356331> + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + +2012-09-24 Mark Lam <mark.lam@apple.com> + + Add cloopDo instruction for debugging the llint C++ backend. + https://bugs.webkit.org/show_bug.cgi?id=97502. + + Reviewed by Geoffrey Garen. + + * offlineasm/cloop.rb: + * offlineasm/instructions.rb: + * offlineasm/parser.rb: + +2012-09-24 Filip Pizlo <fpizlo@apple.com> + + JSArray::putByIndex asserts with readonly property on prototype + https://bugs.webkit.org/show_bug.cgi?id=97435 + <rdar://problem/12357084> + + Reviewed by Geoffrey Garen. + + Boy, there were some problems: + + - putDirectIndex() should know that it can set the index quickly even if it's a hole and we're + in SlowPut mode, since that's the whole point of PutDirect. + + - We should have a fast path for putByIndex(). + + - The LiteralParser should not use push(), since that may throw if we're having a bad time. + + * interpreter/Interpreter.cpp: + (JSC::eval): + * runtime/JSObject.h: + (JSC::JSObject::putByIndexInline): + (JSObject): + (JSC::JSObject::putDirectIndex): + * runtime/LiteralParser.cpp: + (JSC::::parse): + +2012-09-24 Mark Lam <mark.lam@apple.com> + + Added a missing "if VALUE_PROFILER" around an access to ArrayProfile record. + https://bugs.webkit.org/show_bug.cgi?id=97496. + + Reviewed by Filip Pizlo. + + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-24 Geoffrey Garen <ggaren@apple.com> + + Inlined activation tear-off in the DFG + https://bugs.webkit.org/show_bug.cgi?id=97487 + + Reviewed by Filip Pizlo. + + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: Activation tear-off is always inlined now, so I + removed its out-of-line implementation. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Inlined the variable copy and update + of JSVariableObject::m_registers. This usually turns into < 10 instructions, + which is close to pure win as compared to the operation function call. + + * runtime/JSActivation.h: + (JSActivation): + (JSC::JSActivation::registersOffset): + (JSC::JSActivation::tearOff): + (JSC::JSActivation::isTornOff): + (JSC): + (JSC::JSActivation::storageOffset): + (JSC::JSActivation::storage): Tiny bit of refactoring so the JIT can + share the pointer math helper functions we use internally. + +2012-09-24 Balazs Kilvady <kilvadyb@homejinni.com> + + MIPS: store8 functions added to MacroAssembler. + + MIPS store8 functions + https://bugs.webkit.org/show_bug.cgi?id=97243 + + Reviewed by Oliver Hunt. + + Add MIPS store8 functions. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::lhu): New function. + (MIPSAssembler): + (JSC::MIPSAssembler::sb): New function. + (JSC::MIPSAssembler::sh): New function. + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::store8): New function. + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::store16): New function. + +2012-09-23 Geoffrey Garen <ggaren@apple.com> + + PutScopedVar should not be marked as clobbering the world + https://bugs.webkit.org/show_bug.cgi?id=97416 + + Reviewed by Filip Pizlo. + + No performance change. + + PutScopedVar doesn't have arbitrary side-effects, so it shouldn't be marked + as such. + + * dfg/DFGNodeType.h: + (DFG): + +2012-09-23 Geoffrey Garen <ggaren@apple.com> + + I accidentally the whole 32-bit :(. + + Unbreak the DFG in 32-bit with the 32-bit path I forgot in my last patch. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-09-23 Byungwoo Lee <bw80.lee@gmail.com> + + Fix build warnings : -Wunused-parameter, -Wparentheses, -Wuninitialized. + https://bugs.webkit.org/show_bug.cgi?id=97306 + + Reviewed by Benjamin Poulain. + + Fix build warning about -Wunused-parameter on MachineStackMarker.cpp, + LLIntSlowPaths.cpp, DatePrototype.cpp, Options.cpp by using + UNUSED_PARAM() macro or remove parameter name. + + * heap/MachineStackMarker.cpp: + (JSC::pthreadSignalHandlerSuspendResume): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::entryOSR): + * runtime/DatePrototype.cpp: + (JSC::formatLocaleDate): + * runtime/Options.cpp: + (JSC::computeNumberOfGCMarkers): + +2012-09-23 Gavin Barraclough <barraclough@apple.com> + + Sorting a non-array creates propreties (spec-violation) + https://bugs.webkit.org/show_bug.cgi?id=25477 + + Reviewed by Oliver Hunt. + + We're just calling get() to get properties, which is converting missing properties to + undefined. Hole values should be retained, and moved to the end of the array. + + * runtime/ArrayPrototype.cpp: + (JSC::getOrHole): + - Helper function, returns JSValue() instead of undefined for missing properties. + (JSC::arrayProtoFuncSort): + - Implemented per 15.4.4.11, see comments above. + +2012-09-23 Geoffrey Garen <ggaren@apple.com> + + CSE for access to closure variables (get_/put_scoped_var) + https://bugs.webkit.org/show_bug.cgi?id=97414 + + Reviewed by Oliver Hunt. + + I separated loading a scope from loading its storage pointer, so we can + CSE the storage pointer load. Then, I copied the global var CSE and adjusted + it for closure vars. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): Renamed GetScopeChain => GetScope to + reflect renames from a few weeks ago. + + Added a case for the storage pointer load, similar to object storage pointer load. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): Added an independent node for + the storage pointer. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::scopedVarStoreElimination): + (JSC::DFG::CSEPhase::getScopeLoadElimination): + (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): Copied globalVarLoad/StoreElimination + and adapted the same logic to closure vars. + + * dfg/DFGNode.h: + (JSC::DFG::Node::hasScopeChainDepth): + (JSC::DFG::Node::scope): + (Node): + * dfg/DFGNodeType.h: + (DFG): GetScopedVar and GetGlobalVar are no longer MustGenerate. I'm not + sure why they ever were. But these are simple load operations so, if they're + unused, they're truly dead. + + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Updated for renames and split-out + node for getting the storage pointer. + +2012-09-21 Geoffrey Garen <ggaren@apple.com> + + Unreviewed, rolled out a line I committed by accident. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + +2012-09-21 Geoffrey Garen <ggaren@apple.com> + + Optimized closures that capture arguments + https://bugs.webkit.org/show_bug.cgi?id=97358 + + Reviewed by Oliver Hunt. + + Previously, the activation object was responsible for capturing all + arguments in a way that was convenient for the arguments object. Now, + we move all captured variables into a contiguous region in the stack, + allocate an activation for exactly that size, and make the arguments + object responsible for knowing all the places to which arguments could + have moved. + + This seems like the right tradeoff because + + (a) Closures are common and long-lived, so we want them to be small. + + (b) Our primary strategy for optimizing the arguments object is to make + it go away. If you're allocating arguments objects, you're already having + a bad time. + + (c) It's common to use either the arguments object or named argument + closure, but not both. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::argumentsRegister): + (JSC::CodeBlock::activationRegister): + (JSC::CodeBlock::isCaptured): + (JSC::CodeBlock::argumentIndexAfterCapture): m_numCapturedVars is gone + now -- we have an explicit range instead. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): Move captured arguments + into the captured region of local variables for space efficiency. Record + precise data about where they moved for the sake of the arguments object. + + Some of this data was previously wrong, but it didn't cause any problems + because the arguments weren't actually moving. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): Don't + assume that captured vars are in any particular location -- always ask + the CodeBlock. This is better encapsulation. + + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): I rename things sometimes. + + * runtime/Arguments.cpp: + (JSC::Arguments::tearOff): Account for a particularly nasty edge case. + + (JSC::Arguments::didTearOffActivation): Don't allocate our slow arguments + data on tear-off. We need to allocate it eagerly instead, since we need + to know about displaced, captured arguments during access before tear-off. + + * runtime/Arguments.h: + (JSC::Arguments::allocateSlowArguments): + (JSC::Arguments::argument): Tell our slow arguments array where all arguments + are, even if they are not captured. This simplifies some things, so we don't + have to account explicitly for the full matrix of (not torn off, torn off) + * (captured, not captured). + + (JSC::Arguments::finishCreation): Allocate our slow arguments array eagerly + because we need to know about displaced, captured arguments during access + before tear-off. + + * runtime/Executable.cpp: + (JSC::FunctionExecutable::FunctionExecutable): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + * runtime/Executable.h: + (JSC::FunctionExecutable::parameterCount): + (FunctionExecutable): + * runtime/JSActivation.cpp: + (JSC::JSActivation::visitChildren): + * runtime/JSActivation.h: + (JSActivation): + (JSC::JSActivation::create): + (JSC::JSActivation::JSActivation): + (JSC::JSActivation::registerOffset): + (JSC::JSActivation::tearOff): + (JSC::JSActivation::allocationSize): + (JSC::JSActivation::isValid): This is really the point of the patch. All + the pointer math in Activations basically boils away, since we always + copy a contiguous region of captured variables now. + + * runtime/SymbolTable.h: + (JSC::SlowArgument::SlowArgument): + (SlowArgument): + (SharedSymbolTable): + (JSC::SharedSymbolTable::captureCount): + (JSC::SharedSymbolTable::SharedSymbolTable): AllOfTheThings capture mode + is gone now -- that's the point of the patch. indexIfCaptured gets renamed + to index because we always have an index, even if not captured. (The only + time when the index is meaningless is when we're Deleted.) + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Eeeep - broke early boyer in bug#97382 + https://bugs.webkit.org/show_bug.cgi?id=97383 + + Rubber stamped by Sam Weinig. + + missed a child3 -> child2! + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Unreviewed windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Pedantic test in Mozilla's JavaScript test suite fails. function-001.js function-001-n.js + https://bugs.webkit.org/show_bug.cgi?id=27219 + + Reviewed by Sam Weinig. + + These tests are just wrong. + See ECMA 262 A.5, FunctionDelcaration does not require a semicolon. + + * tests/mozilla/expected.html: + * tests/mozilla/js1_2/function/function-001-n.js: + * tests/mozilla/js1_3/Script/function-001-n.js: + * tests/mozilla/js1_3/regress/function-001-n.js: + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Remove redundant argument to op_instanceof + https://bugs.webkit.org/show_bug.cgi?id=97382 + + Reviewed by Geoff Garen. + + No longer needed after my last change. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitInstanceOf): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::InstanceOfNode::emitBytecode): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_instanceof): + (JSC::JIT::emitSlow_op_instanceof): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_instanceof): + (JSC::JIT::emitSlow_op_instanceof): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Unreviewed windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + instanceof should not get the prototype for non-default HasInstance + https://bugs.webkit.org/show_bug.cgi?id=68656 + + Reviewed by Oliver Hunt. + + Instanceof is currently implemented as a sequance of three opcodes: + check_has_instance + get_by_id(prototype) + op_instanceof + There are three interesting types of base value that instanceof can be applied to: + (A) Objects supporting default instanceof behaviour (functions, other than those created with bind) + (B) Objects overriding the default instancecof behaviour with a custom one (API objects, bound functions) + (C) Values that do not respond to the [[HasInstance]] trap. + Currently check_has_instance handles case (C), leaving the op_instanceof opcode to handle (A) & (B). There are + two problems with this apporach. Firstly, this is suboptimal for case (A), since we have to check for + hasInstance support twice (once in check_has_instance, then for default behaviour in op_instanceof). Secondly, + this means that in cases (B) we also perform the get_by_id, which is both suboptimal and an observable spec + violation. + + The fix here is to move handing of non-default instanceof (cases (B)) to the check_has_instance op, leaving + op_instanceof to handle only cases (A). + + * API/JSCallbackObject.h: + (JSCallbackObject): + * API/JSCallbackObjectFunctions.h: + (JSC::::customHasInstance): + * API/JSValueRef.cpp: + (JSValueIsInstanceOfConstructor): + - renamed hasInstance to customHasInstance + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + - added additional parameters to check_has_instance opcode + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + - added additional parameters to check_has_instance opcode + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitCheckHasInstance): + - added additional parameters to check_has_instance opcode + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + - added additional parameters to check_has_instance opcode + * bytecompiler/NodesCodegen.cpp: + (JSC::InstanceOfNode::emitBytecode): + - added additional parameters to check_has_instance opcode + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + - added additional parameters to check_has_instance opcode + * interpreter/Interpreter.cpp: + (JSC::isInvalidParamForIn): + (JSC::Interpreter::privateExecute): + - Add handling for non-default instanceof to op_check_has_instance + * jit/JITInlineMethods.h: + (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex): + - Fixed no-LLInt no_DFG build + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_check_has_instance): + (JSC::JIT::emitSlow_op_check_has_instance): + - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. + (JSC::JIT::emit_op_instanceof): + (JSC::JIT::emitSlow_op_instanceof): + - no need to check for ImplementsDefaultHasInstance. + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_check_has_instance): + (JSC::JIT::emitSlow_op_check_has_instance): + - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. + (JSC::JIT::emit_op_instanceof): + (JSC::JIT::emitSlow_op_instanceof): + - no need to check for ImplementsDefaultHasInstance. + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + - Add handling for non-default instanceof to op_check_has_instance + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + - move check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance. + * runtime/ClassInfo.h: + (MethodTable): + (JSC): + - renamed hasInstance to customHasInstance + * runtime/CommonSlowPaths.h: + (CommonSlowPaths): + - removed opInstanceOfSlow (this was whittled down to one function call!) + * runtime/JSBoundFunction.cpp: + (JSC::JSBoundFunction::customHasInstance): + * runtime/JSBoundFunction.h: + (JSBoundFunction): + - renamed hasInstance to customHasInstance, reimplemented. + * runtime/JSCell.cpp: + (JSC::JSCell::customHasInstance): + * runtime/JSCell.h: + (JSCell): + * runtime/JSObject.cpp: + (JSC::JSObject::hasInstance): + (JSC): + (JSC::JSObject::defaultHasInstance): + * runtime/JSObject.h: + (JSObject): + +2012-09-21 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix ARM build. + + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::store8): + (MacroAssemblerARMv7): + * offlineasm/armv7.rb: + +2012-09-21 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r128400): Opening Google Web Fonts page hangs or crashes + https://bugs.webkit.org/show_bug.cgi?id=97328 + + Reviewed by Mark Hahnenberg. + + It's a bad idea to emit stub code that reallocates property storage when we're in indexed + storage mode. DFGRepatch.cpp knew this and had the appropriate check in one of the places, + but it didn't have it in all of the places. + + This change also adds some more handy disassembly support, which I used to find the bug. + + * assembler/LinkBuffer.h: + (JSC): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryCachePutByID): + * jit/JITStubRoutine.h: + (JSC): + +2012-09-21 Filip Pizlo <fpizlo@apple.com> + + DFG CSE assumes that a holy PutByVal does not interfere with GetArrayLength, when it clearly does + https://bugs.webkit.org/show_bug.cgi?id=97373 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::pureCSE): + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGGraph.h: + (Graph): + +2012-09-21 Chris Rogers <crogers@google.com> + + Add Web Audio support for deprecated/legacy APIs + https://bugs.webkit.org/show_bug.cgi?id=97050 + + Reviewed by Eric Carlson. + + * Configurations/FeatureDefines.xcconfig: + +2012-09-21 Gavin Barraclough <barraclough@apple.com> + + Global Math object should be configurable but isn't + https://bugs.webkit.org/show_bug.cgi?id=55343 + + Reviewed by Oliver Hunt. + + This has no performance impact. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + - Make 'Math' a regular property. + +2012-09-21 Chao-ying Fu <fu@mips.com> + + Add MIPS or32 function + https://bugs.webkit.org/show_bug.cgi?id=97157 + + Reviewed by Gavin Barraclough. + + Add a missing or32 function. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::or32): New function. + (MacroAssemblerMIPS): + +2012-09-20 Filip Pizlo <fpizlo@apple.com> + + CHECK_ARRAY_CONSISTENCY isn't being used or tested, so we should remove it + https://bugs.webkit.org/show_bug.cgi?id=97260 + + Rubber stamped by Geoffrey Garen. + + Supporting it will become difficult as we add more indexing types. It makes more + sense to kill, especially since we don't appear to use it or test it, ever. + + * runtime/ArrayConventions.h: + (JSC): + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncSplice): + * runtime/ArrayStorage.h: + (JSC::ArrayStorage::copyHeaderFromDuringGC): + (ArrayStorage): + * runtime/FunctionPrototype.cpp: + (JSC::functionProtoFuncBind): + * runtime/JSArray.cpp: + (JSC::createArrayButterflyInDictionaryIndexingMode): + (JSC::JSArray::setLength): + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + * runtime/JSArray.h: + (JSArray): + (JSC::createArrayButterfly): + (JSC::JSArray::tryCreateUninitialized): + (JSC::constructArray): + * runtime/JSObject.cpp: + (JSC::JSObject::putByIndex): + (JSC::JSObject::createArrayStorage): + (JSC::JSObject::deletePropertyByIndex): + (JSC): + * runtime/JSObject.h: + (JSC::JSObject::initializeIndex): + (JSObject): + +2012-09-20 Mark Lam <mark.lam@apple.com> + + Fixed a missing semicolon in the C++ llint backend. + https://bugs.webkit.org/show_bug.cgi?id=97252. + + Reviewed by Geoff Garen. + + * offlineasm/cloop.rb: + +2012-09-20 Geoffrey Garen <ggaren@apple.com> + + Refactored the interpreter and JIT so they don't dictate closure layout + https://bugs.webkit.org/show_bug.cgi?id=97221 + + Reviewed by Oliver Hunt. + + Capture may change the location of an argument for space efficiency. This + patch removes static assumptions about argument location from the interpreter + and JIT. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::argumentIndexAfterCapture): + (JSC::ExecState::argumentAfterCapture): Factored out a helper function + so the compiler could share this logic. + + * bytecompiler/NodesCodegen.cpp: + (JSC::BracketAccessorNode::emitBytecode): Don't emit optimized bracket + access on arguments if a parameter has been captured by name. This case is + rare and, where I've seen it in the wild, the optimization mostly failed + anyway due to arguments escape, so I didn't feel like writing and testing + five copies of the code that would handle it in the baseline engines. + + The DFG can still synthesize this optimization even if we don't emit the + optimized bytecode for it. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::symbolTableFor): + (AssemblyHelpers): Use the right helper function to account for the fact + that a parameter may have been captured by name and moved. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): ASSERT that we haven't inlined + a .apply on captured arguments. Once we do start inlining such things, + we'll need to do a little bit of math here to get them right. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Added support for bracket access on + an arguments object where arguments have also been captured by name. We + load the true index of the argument from a side vector. Arguments elision + is very powerful in the DFG, so I wanted to keep it working, even in this + rare case. + + * interpreter/Interpreter.cpp: + (JSC::loadVarargs): Use the right helper function to account for the fact + that a parameter may have been captured by name and moved. + + * jit/JITCall.cpp: + (JSC::JIT::compileLoadVarargs): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileLoadVarargs): Don't use the inline copy loop if some + of our arguments have moved, since it would copy stale values. (We still + optimize the actual call, and elide the arguments object.) + +2012-09-20 Gabor Rapcsanyi <rgabor@webkit.org> + + [Qt] r129045 broke the ARM build + https://bugs.webkit.org/show_bug.cgi?id=97195 + + Reviewed by Zoltan Herczeg. + + Implementing missing store8 function. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::store8): + (MacroAssemblerARM): + +2012-09-19 Geoffrey Garen <ggaren@apple.com> + + OSR exit sometimes neglects to create the arguments object + https://bugs.webkit.org/show_bug.cgi?id=97162 + + Reviewed by Filip Pizlo. + + No performance change. + + I don't know of any case where this is a real problem in TOT, but it + will become a problem if we start compiling eval, with, or catch, and/or + sometimes stop doing arguments optimizations in the bytecode. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): Account for a + CreateArguments that has transformed into PhantomArguments. We used to + clear our reference to the CreateArguments node, but now we hold onto it, + so we need to account for it transforming. + + Don't replace a SetLocal(CreateArguments) with a SetLocal(JSValue()) + because that doesn't leave enough information behind for OSR exit to do + the right thing. Instead, maintain our reference to CreateArguments, and + rely on CreateArguments transforming into PhantomArguments after + optimization. SetLocal(PhantomArguments) is efficient, and it's a marker + for OSR exit to create the arguments object. + + Don't ASSERT that all PhantomArguments are unreferenced because we now + leave them in the graph as SetLocal(PhantomArguments), and that's harmless. + + * dfg/DFGArgumentsSimplificationPhase.h: + (NullableHashTraits): + (JSC::DFG::NullableHashTraits::emptyValue): Export our special hash table + for inline call frames so the OSR exit compiler can use it. + + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): Don't load the 'arguments' + register to decide if we need to create the arguments object. Optimization + may have eliminated the initializing store to this register, in which + case we'll load garbage. Instead, use the global knowledge that all call + frames that optimized out 'arguments' now need to create it, and use a hash + table to make sure we do so only once per call frame. + + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): SetLocal(PhantomArguments) is unique + because we haven't just changed a value's format or elided a load or store; + instead, we've replaced an object with JSValue(). We could try to account + for this in a general way, but for now it's a special-case optimization, + so we give it a specific OSR hint instead. + +2012-09-19 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r128802): It made some JS tests crash + https://bugs.webkit.org/show_bug.cgi?id=97001 + + Reviewed by Mark Hahnenberg. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::visitChildren): + +2012-09-19 Filip Pizlo <fpizlo@apple.com> + + DFG should not assume that a ByVal access is generic just because it was unprofiled + https://bugs.webkit.org/show_bug.cgi?id=97088 + + Reviewed by Geoffrey Garen. + + We were not disambiguating between "Undecided" in the sense that the array profile + has no useful information versus "Undecided" in the sense that the array profile + knows that the access has not executed. That's an important distinction, since + the former form of "Undecided" means that we should consult value profiling, while + the latter means that we should force exit unless the value profiling indicates + that the access must be generic (base is not cell or property is not int). + + * 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): + +2012-09-19 Filip Pizlo <fpizlo@apple.com> + + DFG should not emit PutByVal hole case unless it has to + https://bugs.webkit.org/show_bug.cgi?id=97080 + + Reviewed by Geoffrey Garen. + + This causes us to generate less code for typical PutByVal's. But if profiling tells us + that the hole case is being hit, we generate the same code as we would have generated + before. This seems like a slight speed-up across the board. + + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::store8): + (MacroAssemblerARMv7): + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::store8): + * assembler/MacroAssemblerX86_64.h: + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::store8): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::movb_i8m): + * bytecode/ArrayProfile.h: + (JSC::ArrayProfile::ArrayProfile): + (JSC::ArrayProfile::addressOfMayStoreToHole): + (JSC::ArrayProfile::mayStoreToHole): + (ArrayProfile): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::mayStoreToHole): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.h: + (JIT): + * jit/JITInlineMethods.h: + (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_put_by_val): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_put_by_val): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-18 Filip Pizlo <fpizlo@apple.com> + + DFG should not call out to C++ every time that it tries to put to an object that doesn't yet have array storage + https://bugs.webkit.org/show_bug.cgi?id=96983 + + Reviewed by Oliver Hunt. + + Introduce more polymorphism into the DFG's array mode support. Use that to + introduce the notion of effectul array modes, where the check for the mode + will perform actions necessary to ensure that we have the mode we want, if + the object is not already in that mode. Also added profiling support for + checking if an object is of a type that would not allow us to create array + storage (like a typed array or a string for example). + + This is a ~2x speed-up on loops that transform an object that did not have + indexed storage into one that does. + + * JSCTypedArrayStubs.h: + (JSC): + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::computeUpdatedPrediction): + * bytecode/ArrayProfile.h: + (JSC::ArrayProfile::ArrayProfile): + (JSC::ArrayProfile::mayInterceptIndexedAccesses): + (ArrayProfile): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (DFG): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::modeUsesButterfly): + (JSC::DFG::isSlowPutAccess): + (JSC::DFG::benefitsFromStructureCheck): + (JSC::DFG::isEffectful): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayMode): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasArrayMode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (DFG): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/Arguments.h: + (Arguments): + * runtime/JSNotAnObject.h: + (JSNotAnObject): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::ensureArrayStorage): + * runtime/JSString.h: + (JSC::JSString::createStructure): + +2012-09-18 Filip Pizlo <fpizlo@apple.com> + + Include PhantomArguments in DFGDisassembly + https://bugs.webkit.org/show_bug.cgi?id=97043 + + Reviewed by Geoffrey Garen. + + * dfg/DFGNode.h: + (JSC::DFG::Node::willHaveCodeGenOrOSR): + +2012-09-18 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r128802): It made some JS tests crash + https://bugs.webkit.org/show_bug.cgi?id=97001 + + Reviewed by Mark Hahnenberg. + + IndexingHeaderInlineMethods was incorrectly assuming that if the HasArrayStorage bit is clear, then that means that indexing payload capacity is zero. + + * runtime/IndexingHeaderInlineMethods.h: + (JSC::IndexingHeader::preCapacity): + (JSC::IndexingHeader::indexingPayloadSizeInBytes): + +2012-09-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Use WTF::HasTrivialDestructor instead of compiler-specific versions in JSC::NeedsDestructor + https://bugs.webkit.org/show_bug.cgi?id=96980 + + Reviewed by Benjamin Poulain. + + * runtime/JSCell.h: + (JSC): + (NeedsDestructor): + +2012-09-18 Filip Pizlo <fpizlo@apple.com> + + DFGOperations doesn't use NativeCallFrameTracer in enough places + https://bugs.webkit.org/show_bug.cgi?id=96987 + + Reviewed by Mark Hahnenberg. + + Anything that can GC should use it. + + * dfg/DFGOperations.cpp: + +2012-09-18 Mark Lam <mark.lam@apple.com> + + Not reviewed. Attempt at greening the WinCairo bot. Touching + LowLevelInterpreter.asm to trigger a rebuild of LLIntDesiredOffsets. + https://bugs.webkit.org/show_bug.cgi?id=96992. + + * llint/LowLevelInterpreter.asm: + +2012-09-18 Peter Gal <galpeter@inf.u-szeged.hu> + + [Qt] REGRESSION(r128790): It broke the ARM build + https://bugs.webkit.org/show_bug.cgi?id=96968 + + Reviewed by Filip Pizlo. + + Implement the missing or32 method in the MacroAssemblerARM.h. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::or32): + (MacroAssemblerARM): + +2012-09-18 Mark Lam <mark.lam@apple.com> + + Fix for WinCairo builds. + https://bugs.webkit.org/show_bug.cgi?id=96992. + + Reviewed by Filip Pizlo. + + Adding additional vcproj build targets in LLIntDesiredOffsets.vcproj, + LLIntOffsetsExtractor.vcproj, and LLIntAssembly.vcproj to match those + in jsc.vcproj. + + * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: + * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Added. + +2012-09-18 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix sloppy English in comment. + + * runtime/JSGlobalObject.cpp: + (JSC): + +2012-09-17 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed, rolling out r128826 and r128813. + + * API/JSCallbackConstructor.cpp: + (JSC): + (JSC::JSCallbackConstructor::JSCallbackConstructor): + * API/JSCallbackConstructor.h: + (JSCallbackConstructor): + * API/JSCallbackObject.cpp: + (JSC): + (JSC::::createStructure): + * API/JSCallbackObject.h: + (JSC::JSCallbackObject::create): + (JSCallbackObject): + * API/JSClassRef.cpp: + (OpaqueJSClass::prototype): + * API/JSObjectRef.cpp: + (JSObjectMake): + (JSObjectGetPrivate): + (JSObjectSetPrivate): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + * API/JSValueRef.cpp: + (JSValueIsObjectOfClass): + * API/JSWeakObjectMapRefPrivate.cpp: + * GNUmakefile.list.am: + * JSCTypedArrayStubs.h: + (JSC): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): + * heap/Heap.cpp: + (JSC::Heap::isSafeToSweepStructures): + (JSC): + * heap/Heap.h: + (JSC::Heap::allocatorForObjectWithDestructor): + (Heap): + (JSC::Heap::allocateWithDestructor): + (JSC::Heap::allocateStructure): + (JSC): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::sweepNextBlock): + (JSC::IncrementalSweeper::startSweeping): + (JSC::IncrementalSweeper::willFinishSweeping): + (JSC::IncrementalSweeper::structuresCanBeSwept): + (JSC): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::cellsNeedDestruction): + (JSC::MarkedAllocator::onlyContainsStructures): + (MarkedAllocator): + (JSC::MarkedAllocator::MarkedAllocator): + (JSC::MarkedAllocator::init): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): + (JSC): + (JSC::MarkedBlock::specializedSweep): + (JSC::MarkedBlock::sweep): + (JSC::MarkedBlock::sweepHelper): + * heap/MarkedBlock.h: + (JSC): + (MarkedBlock): + (JSC::MarkedBlock::cellsNeedDestruction): + (JSC::MarkedBlock::onlyContainsStructures): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::MarkedSpace): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::canonicalizeCellLivenessData): + (JSC::MarkedSpace::isPagedOut): + (JSC::MarkedSpace::freeBlock): + * heap/MarkedSpace.h: + (MarkedSpace): + (Subspace): + (JSC::MarkedSpace::allocatorFor): + (JSC::MarkedSpace::destructorAllocatorFor): + (JSC::MarkedSpace::allocateWithDestructor): + (JSC::MarkedSpace::allocateStructure): + (JSC::MarkedSpace::forEachBlock): + * heap/SlotVisitor.cpp: + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC::JIT::emitAllocateJSFinalObject): + (JSC::JIT::emitAllocateJSArray): + * jsc.cpp: + (GlobalObject::create): + * runtime/Arguments.cpp: + (JSC): + * runtime/Arguments.h: + (Arguments): + (JSC::Arguments::Arguments): + * runtime/ErrorPrototype.cpp: + (JSC): + * runtime/Executable.h: + * runtime/InternalFunction.cpp: + (JSC): + (JSC::InternalFunction::InternalFunction): + * runtime/InternalFunction.h: + (InternalFunction): + * runtime/JSCell.h: + (JSC): + (JSC::allocateCell): + * runtime/JSDestructibleObject.h: Removed. + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::createRareDataIfNeeded): + (JSC::JSGlobalObject::create): + * runtime/JSGlobalThis.h: + (JSGlobalThis): + (JSC::JSGlobalThis::JSGlobalThis): + * runtime/JSPropertyNameIterator.h: + * runtime/JSScope.cpp: + (JSC): + * runtime/JSString.h: + (JSC): + * runtime/JSWrapperObject.h: + (JSWrapperObject): + (JSC::JSWrapperObject::JSWrapperObject): + * runtime/MathObject.cpp: + (JSC): + * runtime/NameInstance.h: + (NameInstance): + * runtime/RegExp.h: + * runtime/RegExpObject.cpp: + (JSC): + * runtime/SparseArrayValueMap.h: + * runtime/Structure.h: + (JSC::Structure): + (JSC::JSCell::classInfo): + (JSC): + * runtime/StructureChain.h: + * runtime/SymbolTable.h: + * testRegExp.cpp: + (GlobalObject::create): + +2012-09-17 Geoffrey Garen <ggaren@apple.com> + + Refactored the arguments object so it doesn't dictate closure layout + https://bugs.webkit.org/show_bug.cgi?id=96955 + + Reviewed by Oliver Hunt. + + * bytecode/CodeBlock.h: + (JSC::ExecState::argumentAfterCapture): Helper function for accessing an + argument that has been moved for capture. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): Generate metadata for arguments + that are captured. We don't move any arguments yet, but we do use this + metadata to tell the arguments object if an argument is stored in the + activation. + + * dfg/DFGOperations.cpp: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Updated for the arguments object not + malloc'ing a separate backing store, and for a rename from deletedArguments + to slowArguments. + + * interpreter/CallFrame.h: + (ExecState): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): + (JSC::Interpreter::privateExecute): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): Updated for small interface changes. + + * runtime/Arguments.cpp: + (JSC::Arguments::visitChildren): + (JSC::Arguments::copyToArguments): + (JSC::Arguments::fillArgList): + (JSC::Arguments::getOwnPropertySlotByIndex): + (JSC::Arguments::createStrictModeCallerIfNecessary): + (JSC::Arguments::createStrictModeCalleeIfNecessary): + (JSC::Arguments::getOwnPropertySlot): + (JSC::Arguments::getOwnPropertyDescriptor): + (JSC::Arguments::getOwnPropertyNames): + (JSC::Arguments::putByIndex): + (JSC::Arguments::put): + (JSC::Arguments::deletePropertyByIndex): + (JSC::Arguments::deleteProperty): + (JSC::Arguments::defineOwnProperty): + (JSC::Arguments::tearOff): Moved all data inline into the object, for speed, + and refactored all internal argument accesses to use helper functions, so + we can change the implementation without changing lots of code. + + (JSC::Arguments::didTearOffActivation): This function needs to account + for arguments that were moved by the activation object. We do this accounting + through a side vector that tells us where our arguments will be in the + activation. + + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/Arguments.h: + (Arguments): + (JSC::Arguments::length): + (JSC::Arguments::isTornOff): + (JSC::Arguments::Arguments): + (JSC::Arguments::allocateSlowArguments): + (JSC::Arguments::tryDeleteArgument): + (JSC::Arguments::trySetArgument): + (JSC::Arguments::tryGetArgument): + (JSC::Arguments::isDeletedArgument): + (JSC::Arguments::isArgument): + (JSC::Arguments::argument): + (JSC::Arguments::finishCreation): + + * runtime/JSActivation.h: + (JSC::JSActivation::create): + (JSActivation): + (JSC::JSActivation::captureStart): + (JSC::JSActivation::storageSize): + (JSC::JSActivation::registerOffset): + (JSC::JSActivation::isValid): The activation object is no longer responsible + for copying extra arguments provided by the caller. The argumnents object + does this instead. This means we can allocate and initialize an activation + without worrying about the call frame's argument count. + + * runtime/SymbolTable.h: + (JSC::SlowArgument::SlowArgument): + (SlowArgument): + (JSC): + (JSC::SharedSymbolTable::parameterCount): + (SharedSymbolTable): + (JSC::SharedSymbolTable::slowArguments): + (JSC::SharedSymbolTable::setSlowArguments): Added data structures to back + the algorithms above. + +2012-09-17 Filip Pizlo <fpizlo@apple.com> + + 32-bit LLInt get_by_val does vector length checks incorrectly + https://bugs.webkit.org/show_bug.cgi?id=96893 + <rdar://problem/12311678> + + Reviewed by Mark Hahnenberg. + + * llint/LowLevelInterpreter32_64.asm: + +2012-09-17 Filip Pizlo <fpizlo@apple.com> + + We don't have a bad enough time if an object's prototype chain crosses global objects + https://bugs.webkit.org/show_bug.cgi?id=96962 + + Reviewed by Geoffrey Garen. + + * runtime/JSGlobalObject.cpp: + (JSC): + +2012-09-17 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix a broken assertion in offlineasm. + + * offlineasm/armv7.rb: + * offlineasm/backends.rb: + +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 Gavin Barraclough. + + 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 the NEEDS_DESTRUCTOR macro to make it easier for classes to indicate that instead of being + allocated in a destructor MarkedAllocator that they will handle their destruction themselves through the + use of a finalizer. + (JSC): + (HasImmortalStructure): New template to help us determine at compile-time if a particular class + should be allocated in the immortal structure MarkedAllocator. The default value is false. In order + to be allocated in the immortal structure allocator, classes must specialize this template. Also added + a macro to make it easier for classes to specialize the template. + (JSC::allocateCell): Use the appropriate allocator depending on the destructor type. + * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be + accessed safely when the object is being destroyed. + (JSC): + (JSDestructibleObject): + (JSC::JSDestructibleObject::classInfo): + (JSC::JSDestructibleObject::JSDestructibleObject): + (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe. + * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all + of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well. + (JSC::JSGlobalObject::reset): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one + for the m_rareData field when it's created. + (JSC::JSGlobalObject::create): + (JSC): + * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject. + (JSGlobalThis): + (JSC::JSGlobalThis::JSGlobalThis): + * runtime/JSPropertyNameIterator.h: Has an immortal Structure. + (JSC): + * runtime/JSScope.cpp: + (JSC): + * runtime/JSString.h: Has an immortal Structure. + (JSC): + * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject. + (JSWrapperObject): + (JSC::JSWrapperObject::JSWrapperObject): + * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff. + (JSC): + * runtime/NameInstance.h: Inherit from JSDestructibleObject. + (NameInstance): + * runtime/RegExp.h: Has immortal Structure. + (JSC): + * runtime/RegExpObject.cpp: Inheritance cleanup. + (JSC): + * runtime/SparseArrayValueMap.h: Has immortal Structure. + (JSC): + * runtime/Structure.h: Has immortal Structure. + (JSC): + * runtime/StructureChain.h: Ditto. + (JSC): + * runtime/SymbolTable.h: Ditto. + (SharedSymbolTable): + (JSC): + +2012-09-17 Filip Pizlo <fpizlo@apple.com> + + If a prototype has indexed setters and its instances have indexed storage, then all put_by_val's should have a bad time + https://bugs.webkit.org/show_bug.cgi?id=96596 + + Reviewed by Gavin Barraclough. + + Added comprehensive support for accessors and read-only indexed properties on the + prototype chain. This is done without any performance regression on benchmarks that + we're aware of, by having the entire VM's strategy with respect to arrays tilted + heavily in favor of: + + - The prototype chain of JSArrays never having any accessors or read-only indexed + properties. If that changes, you're going to have a bad time. + + - Prototypes of non-JSArray objects either having no indexed accessors or read-only + indexed properties, or, having those indexed accessor thingies inserted before + any instance object (i.e. object with that prototype as its prototype) is created. + If you add indexed accessors or read-only indexed properties to an object that is + already used as a prototype, you're going to have a bad time. + + See below for the exact definition of having a bad time. + + Put another way, "fair" uses of indexed accessors and read-only indexed properties + are: + + - Put indexed accessors and read-only indexed properties on an object that is never + used as a prototype. This will slow down accesses to that object, but will not + have any effect on any other object. + + - Put those indexed accessor thingies on an object before it is used as a prototype + and then start instantiating objects that claim that object as their prototype. + This will slightly slow down indexed stores to the instance objects, and greatly + slow down all indexed accesses to the prototype, but will have no other effect. + + In short, "fair" uses only affect the object itself and any instance objects. But + if you start using indexed accessors in more eclectic ways, you're going to have + a bad time. + + Specifically, if an object that may be used as a prototype has an indexed accessor + added, the VM performs a whole-heap scan to find all objects that belong to the + same global object as the prototype you modified. If any of those objects has + indexed storage, their indexed storage is put into slow-put mode, just as if their + prototype chain had indexed accessors. This will happen even for objects that do + not currently have indexed accessors in their prototype chain. As well, all JSArray + allocations are caused to create arrays with slow-put storage, and all future + allocations of indexed storage for non-JSArray objects are also flipped to slow-put + mode. Note there are two aspects to having a bad time: (i) the whole-heap scan and + (ii) the poisoning of all indexed storage in the entire global object. (i) is + necessary for correctness. If we detect that an object that may be used as a + prototype has had an indexed accessor or indexed read-only property inserted into + it, then we need to ensure that henceforth all instances of that object inspect + the prototype chain whenever an indexed hole is stored to. But by default, indexed + stores do no such checking because doing so would be unnecessarily slow. So, we must + find all instances of the affected object and flip them into a different array + storage mode that omits all hole optimizations. Since prototypes never keep a list + of instance objects, the only way to find those objects is a whole-heap scan. But + (i) alone would be a potential disaster, if a program frequently allocated an + object without indexed accessors, then allocated a bunch of objects that used that + one as their prototype, and then added indexed accessors to the prototype. So, to + prevent massive heap scan storms in such awkward programs, having a bad time also + implies (ii): henceforth *all* objects belonging to that global object will use + slow put indexed storage, so that we don't ever have to scan the heap again. Note + that here we are using the global object as just an approximation of a program + module; it may be worth investigating in the future if other approximations can be + used instead. + + * bytecode/ArrayProfile.h: + (JSC): + (JSC::arrayModeFromStructure): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::isSlowPutAccess): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateJSArray): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_array): + * runtime/ArrayPrototype.cpp: + (JSC::ArrayPrototype::finishCreation): + (JSC::arrayProtoFuncSort): + * runtime/IndexingType.h: + (JSC): + (JSC::hasIndexedProperties): + (JSC::hasIndexingHeader): + (JSC::hasArrayStorage): + (JSC::shouldUseSlowPut): + * runtime/JSArray.cpp: + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + * runtime/JSArray.h: + (JSC::JSArray::createStructure): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::haveABadTime): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::addressOfArrayStructure): + (JSC::JSGlobalObject::havingABadTimeWatchpoint): + (JSC::JSGlobalObject::isHavingABadTime): + * runtime/JSObject.cpp: + (JSC::JSObject::visitButterfly): + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::put): + (JSC::JSObject::putByIndex): + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::notifyPresenceOfIndexedAccessors): + (JSC): + (JSC::JSObject::createArrayStorage): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::switchToSlowPutArrayStorage): + (JSC::JSObject::setPrototype): + (JSC::JSObject::resetInheritorID): + (JSC::JSObject::inheritorID): + (JSC::JSObject::allowsAccessFrom): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::unwrappedGlobalObject): + (JSC::JSObject::notifyUsedAsPrototype): + (JSC::JSObject::createInheritorID): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): + (JSC::JSObject::attemptToInterceptPutByIndexOnHole): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::getOwnPropertyDescriptor): + * runtime/JSObject.h: + (JSC::JSObject::mayBeUsedAsPrototype): + (JSObject): + (JSC::JSObject::mayInterceptIndexedAccesses): + (JSC::JSObject::getArrayLength): + (JSC::JSObject::getVectorLength): + (JSC::JSObject::canGetIndexQuickly): + (JSC::JSObject::getIndexQuickly): + (JSC::JSObject::canSetIndexQuickly): + (JSC::JSObject::setIndexQuickly): + (JSC::JSObject::initializeIndex): + (JSC::JSObject::completeInitialization): + (JSC::JSObject::inSparseIndexingMode): + (JSC::JSObject::arrayStorage): + (JSC::JSObject::arrayStorageOrNull): + (JSC::JSObject::ensureArrayStorage): + (JSC): + (JSC::JSValue::putByIndex): + * runtime/JSValue.cpp: + (JSC::JSValue::putToPrimitive): + (JSC::JSValue::putToPrimitiveByIndex): + (JSC): + * runtime/JSValue.h: + (JSValue): + * runtime/ObjectPrototype.cpp: + (JSC::ObjectPrototype::finishCreation): + * runtime/SparseArrayValueMap.cpp: + (JSC::SparseArrayValueMap::putEntry): + (JSC::SparseArrayEntry::put): + (JSC): + * runtime/SparseArrayValueMap.h: + (JSC): + (SparseArrayEntry): + * runtime/Structure.cpp: + (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses): + (JSC): + (JSC::Structure::suggestedIndexingTransition): + * runtime/Structure.h: + (Structure): + (JSC::Structure::mayInterceptIndexedAccesses): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): + +2012-09-17 Filip Pizlo <fpizlo@apple.com> + + Array profiling has convergence issues + https://bugs.webkit.org/show_bug.cgi?id=96891 + + Reviewed by Gavin Barraclough. + + Now each array profiling site merges in the indexing type it observed into + the m_observedArrayModes bitset. The ArrayProfile also uses this to detect + cases where the structure must have gone polymorphic (if the bitset is + polymorphic then the structure must be). This achieves something like the + best of both worlds: on the one hand, we get a probabilistic structure that + we can use to optimize the monomorphic structure case, but on the other hand, + we get an accurate view of the set of types that were encountered. + + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::or32): + (MacroAssemblerARMv7): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::or32): + (MacroAssemblerX86): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::or32): + (MacroAssemblerX86_64): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::orl_rm): + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::computeUpdatedPrediction): + * bytecode/ArrayProfile.h: + (JSC::ArrayProfile::addressOfArrayModes): + (JSC::ArrayProfile::structureIsPolymorphic): + * jit/JIT.h: + (JIT): + * jit/JITInlineMethods.h: + (JSC): + (JSC::JIT::emitArrayProfilingSite): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-17 Mark Lam <mark.lam@apple.com> + + Not reviewed. Added svn:eol-style native to unbreak some build bots. + https://bugs.webkit.org/show_bug.cgi?id=96175. + + * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added property svn:eol-style. + * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added property svn:eol-style. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added property svn:eol-style. + +2012-09-16 Mark Lam <mark.lam@apple.com> + + Added MSVC project changes to enable building the llint. + https://bugs.webkit.org/show_bug.cgi?id=96175. + + Reviewed by Geoff Garen. + + This only adds the ability to build the llint, but currently, only the + C++ backend is supported. By default, the Windows port will remain + running with the baseline JIT. The llint will not be enabled. + + * JavaScriptCore.vcproj/JavaScriptCore.sln: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcproj/LLIntAssembly: Added. + * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Added. + * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added. + * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added. + * JavaScriptCore.vcproj/LLIntDesiredOffsets: Added. + * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added. + * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added. + * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added. + * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added. + +2012-09-16 Filip Pizlo <fpizlo@apple.com> + + JSObject.cpp and JSArray.cpp have inconsistent tests for the invalid array index case + https://bugs.webkit.org/show_bug.cgi?id=96878 + + Reviewed by Sam Weinig. + + Removed the uses of UNLIKELY() because I don't believe they are buying us anything, + since we're already on the slow path. Also found other places where we're testing for + the invalid array index case using unusual predicates rather than just using + MAX_ARRAY_INDEX. With this change, I believe that all of our tests for invalid + array indices (i.e. indices that should be treated as non-indexed properties) + uniformly use MAX_ARRAY_INDEX and PropertyName::NotAnIndex. + + * runtime/JSArray.cpp: + (JSC::JSArray::push): + * runtime/JSObject.cpp: + (JSC::JSObject::putByIndex): + (JSC::JSObject::defineOwnIndexedProperty): + +2012-09-15 Filip Pizlo <fpizlo@apple.com> + + Following the Butterfly refactoring, the comment for lastArraySize was not updated + https://bugs.webkit.org/show_bug.cgi?id=96877 + + Reviewed by Sam Weinig. + + * runtime/JSObject.cpp: + (JSC): + +2012-09-15 Mark Lam <mark.lam@apple.com> + + Fixed JSLock to use the platform abstraction for Mutex instead of + depending on pthreads. + https://bugs.webkit.org/show_bug.cgi?id=96858. + + Reviewed by Filip Pizlo. + + This fixes a synchronization problem on the Windows port and makes + it more reliable when running the layout tests. + + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): + * runtime/JSLock.cpp: + (JSC): + (JSC::GlobalJSLock::GlobalJSLock): + (JSC::GlobalJSLock::~GlobalJSLock): + (JSC::GlobalJSLock::initialize): + * runtime/JSLock.h: + (GlobalJSLock): + (JSLock): + +2012-09-15 Filip Pizlo <fpizlo@apple.com> + + Structure check hoisting fails to consider the possibility of conflicting checks on the source of the first assignment to the hoisted variable + https://bugs.webkit.org/show_bug.cgi?id=96872 + + Reviewed by Oliver Hunt. + + This does a few related things: + + - It turns off the use of ForceOSRExit for sure-to-fail CheckStructures, because + I noticed that this would sometimes happen for a ForwardCheckStructure. The + problem is that ForceOSRExit exits backwards, not forwards. Since the code that + led to those ForceOSRExit's being inserted was written out of paranoia rather + than need, I removed it. Specifically, I removed the m_isValid = false code + for CheckStructure/StructureTransitionWatchpoint in AbstractState. + + - If a structure check causes a structure set to go empty, we don't want a + PutStructure to revive the set. It should instead be smart enough to realize + that an empty set implies that the code can't execute. This was the only "bug" + that the use of m_isValid = false was preventing. + + - Finally, the main change: structure check hoisting looks at the source of the + SetLocals on structure-check-hoistable variables and ensures that the source + is not checked with a conflicting structure. This is O(n^2) but it does not + show up at all in performance tests. + + The first two parts of this change were auxiliary bugs that were revealed by + the structure check hoister doing bad things. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::execute): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-09-14 Filip Pizlo <fpizlo@apple.com> + + All of the things in SparseArrayValueMap should be out-of-line + https://bugs.webkit.org/show_bug.cgi?id=96854 + + Reviewed by Andy Estes. + + Those inline methods were buying us nothing. + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * runtime/JSArray.cpp: + * runtime/JSGlobalData.cpp: + * runtime/JSObject.cpp: + * runtime/RegExpMatchesArray.cpp: + * runtime/SparseArrayValueMap.cpp: + (JSC::SparseArrayValueMap::SparseArrayValueMap): + (JSC): + (JSC::SparseArrayValueMap::~SparseArrayValueMap): + (JSC::SparseArrayValueMap::finishCreation): + (JSC::SparseArrayValueMap::create): + (JSC::SparseArrayValueMap::destroy): + (JSC::SparseArrayValueMap::createStructure): + (JSC::SparseArrayValueMap::add): + (JSC::SparseArrayValueMap::putEntry): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayEntry::get): + (JSC::SparseArrayEntry::getNonSparseMode): + (JSC::SparseArrayValueMap::visitChildren): + * runtime/SparseArrayValueMapInlineMethods.h: Removed. + +2012-09-14 Mike West <mkwst@chromium.org> + + JSC should throw a more descriptive exception when blocking 'eval' via CSP. + https://bugs.webkit.org/show_bug.cgi?id=94331 + + Reviewed by Geoffrey Garen. + + Unless explicitly whitelisted, the 'script-src' Content Security Policy + directive blocks 'eval' and 'eval'-like constructs such as + 'new Function()'. When 'eval' is encountered in code, an 'EvalError' is + thrown, but the associated message is poor: "Eval is disabled" doesn't + give developers enough information about why their code isn't behaving + as expected. + + This patch adds an 'errorMessage' parameter to the JavaScriptCore method + used to disable 'eval'; ContentSecurityPolicy has the opportunity to + pass in a more detailed and descriptive error that contains more context + for the developer. + + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + Drop the hard-coded "Eval is disabled" error message in favor of + reading the error message off the global object. + * runtime/FunctionConstructor.cpp: + (JSC::FunctionConstructor::getCallData): + Drop the hard-coded "Function constructor is disabled" error message + in favor of reading the error message off the global object. + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::evalEnabled): + Making this accessor method const. + (JSC::JSGlobalObject::evalDisabledErrorMessage): + Accessor for the error message set via 'setEvalDisabled'. + (JSC::JSGlobalObject::setEvalEnabled): + Adding an 'errorMessage' parameter which is stored on the global + object, and used when exceptions are thrown. + +2012-09-14 Filip Pizlo <fpizlo@apple.com> + + bbc homepage crashes immediately + https://bugs.webkit.org/show_bug.cgi?id=96812 + <rdar://problem/12081386> + + Reviewed by Oliver Hunt. + + If you use the old storage pointer to write to space you thought was newly allocated, + you're going to have a bad time. + + * runtime/JSArray.cpp: + (JSC::JSArray::unshiftCount): + +2012-09-14 Adam Barth <abarth@webkit.org> + + Remove webkitPostMessage + https://bugs.webkit.org/show_bug.cgi?id=96577 + + Reviewed by Ojan Vafai. + + Add ENABLE_LEGACY_VENDOR_PREFIXES flag. + + * Configurations/FeatureDefines.xcconfig: + +2012-09-14 Tor Arne Vestbø <tor.arne.vestbo@nokia.com> + + [Qt] Make force_static_libs_as_shared work on Mac OS + + We had to move a few LIBS += around that were in the wrong place, + and not caught when everything was just linked into the final + QtWebKit library. + + Reviewed by Simon Hausmann. + + * jsc.pro: No need for AppKit, we get it from WTF.pri + +2012-09-14 Kevin Funk <kevin.funk@kdab.com> + + Fix interpreter build + https://bugs.webkit.org/show_bug.cgi?id=96617 + + Reviewed by Simon Hausmann. + + Make compile. + + * interpreter/Interpreter.cpp: + +2012-09-14 Parth Patel <parpatel@rim.com> + + [BlackBerry] Switching from Slogger to Slogger2 requires changes in CMakeList of + webkit in order to include libraries of slog2 + https://bugs.webkit.org/show_bug.cgi?id=96391 + + Reviewed by Yong Li. + + Changes in Cmake files of JavaScriptCore of webkit to include slog2 libs in build + files of webkit in response to switching from Slogger to Slogger2. + + * shell/PlatformBlackBerry.cmake: + +2012-09-14 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove the Zapped BlockState + https://bugs.webkit.org/show_bug.cgi?id=96708 + + Reviewed by Geoffrey Garen. + + The Zapped block state is rather confusing. It indicates that a block is in one of two different states that we + can't tell the difference between: + + 1) I have run all destructors of things that are zapped, and I have not allocated any more objects. This block + is ready for reclaiming if you so choose. + 2) I have run all the destructors of things that are zapped, but I have allocated more stuff since then, so it + is not safe to reclaim this block. + + This state adds a lot of complexity to our state transition model for MarkedBlocks. We should get rid of it. + We can replace this state by making sure mark bits represent all of the liveness information we need when running + our conservative stack scan. Instead of zapping the free list when canonicalizing cell liveness data prior to + a conservative scan, we can instead mark all objects in the block except for those in the free list. This should + incur no performance penalty since we're doing it on a very small O(1) number of blocks at the beginning of the collection. + + For the time being we still need to use zapping to determine whether we have run an object's destructor or not. + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): Renaming stuff. + * heap/MarkedAllocator.h: Renamed zapFreeList to canonicalizeCellLivenessData to match. + (MarkedAllocator): + (JSC::MarkedAllocator::canonicalizeCellLivenessData): Same as old zapFreeList, but just call canonicalize instead. + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::specializedSweep): Remove the check for Zapped block stuff. Also change the block state to Marked + instead of Zapped if we're not producing a FreeList since that's the only other state that really makes any sense. + (JSC::MarkedBlock::sweepHelper): Remove Zapped related code. + (SetAllMarksFunctor): Functor to set all the mark bits in the block since there's not a simple function to call on + the Bitmap itself. + (JSC::SetAllMarksFunctor::operator()): + (JSC): + (JSC::MarkedBlock::canonicalizeCellLivenessData): Remove all the stuff for Zapped. For FreeListed, set all the mark bits + and then clear the ones for the objects in the FreeList. This ensures that only the things that were in the FreeList + are considered to be dead by the conservative scan, just like if we were to have zapped the FreeList like before. + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::clearMarked): Add function to clear individual mark bits, since we need that functionality now. + (JSC): + (JSC::MarkedBlock::isLive): Remove code for Zapped stuff. Marked handles all interesting cases now. + (JSC::MarkedBlock::forEachCell): Add new iterator function that iterates over all cells in the block, regardless of + whether they're live or a dead. + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::canonicalizeCellLivenessData): Change to call the renamed canonicalize function. + +2012-09-13 Kevin Funk <kevin.funk@kdab.com> + + Make compile with both OS(WINCE) and PLATFORM(QT) support + https://bugs.webkit.org/show_bug.cgi?id=95536 + + Reviewed by Simon Hausmann. + + Do not link against advapi32 on wince + + * jsc.pro: + +2012-09-13 Geoffrey Garen <ggaren@apple.com> + + Refactored the DFG to make fewer assumptions about variable capture + https://bugs.webkit.org/show_bug.cgi?id=96680 + + Reviewed by Gavin Barraclough. + + A variable capture optimization patch I'm working on broke DFG + correctness and the arguments simplification optimization phase, so I've + refactored both to make fewer assumptions about variable capture. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::isCaptured): This is the new One True Way to find out + if a variable was captured. This gives us a single point of maintenance + as we chagne capture behavior. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::clobberCapturedVars): Don't assume that captured + variables have any particular location. Instead, ask the One True Function. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): Mechanical + changes to separate being captured from being 'arguments'. What used + to be + if (captured) + if (arguments) + x + y + is now + if (arguments) + x + y + else if (captured) + y + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::flushDirect): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): Use the One True Function. + +2012-09-13 Benjamin Poulain <bpoulain@apple.com> + + Improve the SourceProvider hierarchy + https://bugs.webkit.org/show_bug.cgi?id=95635 + + Reviewed by Geoffrey Garen. + + SourceProvider was designed to have subclasses magically handling the data without + decoding all of it. The virtual methods length() and getRange() were based + on these assumptions. + + In practice, the magic was in our head, there is no implementation that takes + advantage of that. + + SourceProvider is modified to adopt WebCore's ScriptSourceProvider::source() and base + everything on it. + The code using SourceProvider is also simplified. + + * interpreter/Interpreter.cpp: + (JSC::appendSourceToError): Keep a reference to the string instead of querying it for + each time it is used. + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::sourceCode): + * parser/Parser.h: + (JSC::parse): + * parser/SourceCode.h: + (JSC::SourceCode::SourceCode): + (JSC::SourceCode::subExpression): + * parser/SourceProvider.h: + (SourceProvider): + (JSC::SourceProvider::getRange): + +2012-09-13 Filip Pizlo <fpizlo@apple.com> + + DFG: Dead GetButterfly's shouldn't be subject to CSE + https://bugs.webkit.org/show_bug.cgi?id=96707 + <rdar://problem/12296311> + + Reviewed by Oliver Hunt. + + There were a number of cases of this that creeped into the CSE: it would + match something even though it was dead. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::getScopeChainLoadElimination): + (JSC::DFG::CSEPhase::getLocalLoadElimination): + +2012-09-13 Oliver Hunt <oliver@apple.com> + + Make global const initialisation explicit in the bytecode + https://bugs.webkit.org/show_bug.cgi?id=96711 + + Reviewed by Gavin Barraclough. + + Added op_init_global_const to make initialisation of global const + fields explicit. This will help us keep correct semantics in the + upcoming variable resolution refactoring. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ConstDeclNode::emitCodeSingle): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-13 Mark Hahnenberg <mhahnenberg@apple.com> + + Rename forEachCell to forEachLiveCell + https://bugs.webkit.org/show_bug.cgi?id=96685 + + Reviewed by Oliver Hunt. + + forEachCell actually only iterates over live cells. We should rename it to + reflect what it actually does. This is also helpful because we want to add a new + forEachCell that actually does iterate each and every cell in a MarkedBlock + regardless of whether or not it is live. + + * debugger/Debugger.cpp: + (JSC::Debugger::recompileAllJSFunctions): + * heap/Heap.cpp: + (JSC::Heap::globalObjectCount): + (JSC::Heap::objectTypeCounts): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::forEachLiveCell): + * heap/MarkedSpace.h: + (MarkedSpace): + (JSC::MarkedSpace::forEachLiveCell): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::releaseExecutableMemory): + +2012-09-13 Filip Pizlo <fpizlo@apple.com> + + [Qt][Win] REGRESSION(r128400): It broke the build + https://bugs.webkit.org/show_bug.cgi?id=96617 + + Reviewed by Simon Hausmann. + + Changed "JSC::Array" to "JSC::ArrayClass" because it's not used often enough + for the brevity to be beneficial, and because "Array" causes too much namespace + pollution. + + * runtime/IndexingType.h: + (JSC): + * runtime/JSArray.cpp: + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sort): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + (JSC::JSArray::compactForSorting): + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::putByIndex): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::getOwnPropertyDescriptor): + * runtime/JSObject.h: + (JSC::JSObject::getArrayLength): + (JSC::JSObject::getVectorLength): + (JSC::JSObject::canGetIndexQuickly): + (JSC::JSObject::canSetIndexQuickly): + (JSC::JSObject::inSparseIndexingMode): + (JSC::JSObject::ensureArrayStorage): + +2012-09-13 Filip Pizlo <fpizlo@apple.com> + + Testing whether indexing type is ArrayWithArrayStorage should not compare against ArrayWithArrayStorage + https://bugs.webkit.org/show_bug.cgi?id=96611 + + Reviewed by Gavin Barraclough. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-09 Filip Pizlo <fpizlo@apple.com> + + JSC should have property butterflies + https://bugs.webkit.org/show_bug.cgi?id=91933 + + Reviewed by Geoffrey Garen. + + This changes the JSC object model. Previously, all objects had fast lookup for + named properties. Integer indexed properties were only fast if you used a + JSArray. With this change, all objects have fast indexed properties. This is + accomplished without any space overhead by using a bidirectional object layout, + aka butterflies. Each JSObject has a m_butterfly pointer where previously it + had a m_outOfLineStorage pointer. To the left of the location pointed to by + m_butterfly, we place all named out-of-line properties. To the right, we place + all indexed properties along with indexing meta-data. Though, some indexing + meta-data is placed in the 8-byte word immediately left of the pointed-to + location; this is in anticipation of the indexing meta-data being small enough + in the common case that m_butterfly always points to the first indexed + property. + + This is performance neutral, except on tests that use indexed properties on + plain objects, where the speed-up is in excess of an order of magnitude. + + One notable aspect of what this change brings is that it allows indexing + storage to morph over time. Currently this is only used to allow all non-array + objects to start out without any indexed storage. But it could be used for + some kinds of array type inference in the future. + + * API/JSCallbackObject.h: + (JSCallbackObject): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnPropertySlotByIndex): + (JSC): + (JSC::::getOwnNonIndexPropertyNames): + * API/JSObjectRef.cpp: + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/ArrayProfile.h: + (JSC): + (JSC::arrayModeFromStructure): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDirectPutById): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAdjacencyList.h: + (JSC::DFG::AdjacencyList::AdjacencyList): + (AdjacencyList): + * 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::modeSupportsLength): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::addNode): + (FixupPhase): + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGNode.h: + (JSC::DFG::Node::Node): + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + (JSC::DFG::putByVal): + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryBuildPutByIdList): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * heap/CopiedSpace.h: + (CopiedSpace): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC::JIT::emitAllocateBasicStorage): + (JSC::JIT::emitAllocateJSArray): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_array): + (JSC::JIT::emitSlow_op_new_array): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::compileGetDirectOffset): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::emit_op_put_by_id): + (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::emit_op_put_by_id): + (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::compileGetDirectOffset): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jsc.cpp: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/Arguments.cpp: + (JSC::Arguments::deletePropertyByIndex): + (JSC::Arguments::defineOwnProperty): + * runtime/ArrayConstructor.cpp: + * runtime/ArrayConventions.h: Added. + (JSC): + (JSC::isDenseEnoughForVector): + (JSC::indexingHeaderForArray): + (JSC::baseIndexingHeaderForArray): + * runtime/ArrayPrototype.cpp: + (JSC::ArrayPrototype::create): + (JSC): + (JSC::ArrayPrototype::ArrayPrototype): + (JSC::arrayProtoFuncToString): + (JSC::arrayProtoFuncJoin): + (JSC::arrayProtoFuncSort): + (JSC::arrayProtoFuncFilter): + (JSC::arrayProtoFuncMap): + (JSC::arrayProtoFuncEvery): + (JSC::arrayProtoFuncForEach): + (JSC::arrayProtoFuncSome): + (JSC::arrayProtoFuncReduce): + (JSC::arrayProtoFuncReduceRight): + * runtime/ArrayPrototype.h: + (ArrayPrototype): + (JSC::ArrayPrototype::createStructure): + * runtime/ArrayStorage.h: Added. + (JSC): + (ArrayStorage): + (JSC::ArrayStorage::ArrayStorage): + (JSC::ArrayStorage::from): + (JSC::ArrayStorage::butterfly): + (JSC::ArrayStorage::indexingHeader): + (JSC::ArrayStorage::length): + (JSC::ArrayStorage::setLength): + (JSC::ArrayStorage::vectorLength): + (JSC::ArrayStorage::setVectorLength): + (JSC::ArrayStorage::copyHeaderFromDuringGC): + (JSC::ArrayStorage::inSparseMode): + (JSC::ArrayStorage::lengthOffset): + (JSC::ArrayStorage::vectorLengthOffset): + (JSC::ArrayStorage::numValuesInVectorOffset): + (JSC::ArrayStorage::vectorOffset): + (JSC::ArrayStorage::indexBiasOffset): + (JSC::ArrayStorage::sparseMapOffset): + (JSC::ArrayStorage::sizeFor): + * runtime/Butterfly.h: Added. + (JSC): + (Butterfly): + (JSC::Butterfly::Butterfly): + (JSC::Butterfly::totalSize): + (JSC::Butterfly::fromBase): + (JSC::Butterfly::offsetOfIndexingHeader): + (JSC::Butterfly::offsetOfPublicLength): + (JSC::Butterfly::offsetOfVectorLength): + (JSC::Butterfly::indexingHeader): + (JSC::Butterfly::propertyStorage): + (JSC::Butterfly::indexingPayload): + (JSC::Butterfly::arrayStorage): + (JSC::Butterfly::offsetOfPropertyStorage): + (JSC::Butterfly::indexOfPropertyStorage): + (JSC::Butterfly::base): + * runtime/ButterflyInlineMethods.h: Added. + (JSC): + (JSC::Butterfly::createUninitialized): + (JSC::Butterfly::create): + (JSC::Butterfly::createUninitializedDuringCollection): + (JSC::Butterfly::base): + (JSC::Butterfly::growPropertyStorage): + (JSC::Butterfly::growArrayRight): + (JSC::Butterfly::resizeArray): + (JSC::Butterfly::unshift): + (JSC::Butterfly::shift): + * runtime/ClassInfo.h: + (MethodTable): + (JSC): + * runtime/IndexingHeader.h: Added. + (JSC): + (IndexingHeader): + (JSC::IndexingHeader::offsetOfIndexingHeader): + (JSC::IndexingHeader::offsetOfPublicLength): + (JSC::IndexingHeader::offsetOfVectorLength): + (JSC::IndexingHeader::IndexingHeader): + (JSC::IndexingHeader::vectorLength): + (JSC::IndexingHeader::setVectorLength): + (JSC::IndexingHeader::publicLength): + (JSC::IndexingHeader::setPublicLength): + (JSC::IndexingHeader::from): + (JSC::IndexingHeader::fromEndOf): + (JSC::IndexingHeader::propertyStorage): + (JSC::IndexingHeader::arrayStorage): + (JSC::IndexingHeader::butterfly): + * runtime/IndexingHeaderInlineMethods.h: Added. + (JSC): + (JSC::IndexingHeader::preCapacity): + (JSC::IndexingHeader::indexingPayloadSizeInBytes): + * runtime/IndexingType.h: Added. + (JSC): + (JSC::hasIndexingHeader): + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): + (JSC::JSActivation::visitChildren): + (JSC::JSActivation::getOwnNonIndexPropertyNames): + * runtime/JSActivation.h: + (JSActivation): + (JSC::JSActivation::tearOff): + * runtime/JSArray.cpp: + (JSC): + (JSC::createArrayButterflyInDictionaryIndexingMode): + (JSC::JSArray::setLengthWritable): + (JSC::JSArray::defineOwnProperty): + (JSC::JSArray::getOwnPropertySlot): + (JSC::JSArray::getOwnPropertyDescriptor): + (JSC::JSArray::put): + (JSC::JSArray::deleteProperty): + (JSC::JSArray::getOwnNonIndexPropertyNames): + (JSC::JSArray::unshiftCountSlowCase): + (JSC::JSArray::setLength): + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::shiftCount): + (JSC::JSArray::unshiftCount): + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sort): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + (JSC::JSArray::compactForSorting): + * runtime/JSArray.h: + (JSC): + (JSArray): + (JSC::JSArray::JSArray): + (JSC::JSArray::length): + (JSC::JSArray::createStructure): + (JSC::JSArray::isLengthWritable): + (JSC::createArrayButterfly): + (JSC::JSArray::create): + (JSC::JSArray::tryCreateUninitialized): + * runtime/JSBoundFunction.cpp: + (JSC::boundFunctionCall): + (JSC::boundFunctionConstruct): + (JSC::JSBoundFunction::finishCreation): + * runtime/JSCell.cpp: + (JSC::JSCell::getOwnNonIndexPropertyNames): + (JSC): + * runtime/JSCell.h: + (JSCell): + * runtime/JSFunction.cpp: + (JSC::JSFunction::getOwnPropertySlot): + (JSC::JSFunction::getOwnPropertyDescriptor): + (JSC::JSFunction::getOwnNonIndexPropertyNames): + (JSC::JSFunction::defineOwnProperty): + * runtime/JSFunction.h: + (JSFunction): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + * runtime/JSONObject.cpp: + (JSC::Stringifier::Holder::appendNextProperty): + (JSC::Walker::walk): + * runtime/JSObject.cpp: + (JSC): + (JSC::JSObject::visitButterfly): + (JSC::JSObject::visitChildren): + (JSC::JSFinalObject::visitChildren): + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::put): + (JSC::JSObject::putByIndex): + (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::createArrayStorage): + (JSC::JSObject::createInitialArrayStorage): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::putDirectAccessor): + (JSC::JSObject::deleteProperty): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::getOwnNonIndexPropertyNames): + (JSC::JSObject::preventExtensions): + (JSC::JSObject::fillGetterPropertySlot): + (JSC::JSObject::putIndexedDescriptor): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::allocateSparseIndexMap): + (JSC::JSObject::deallocateSparseIndexMap): + (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::increaseVectorLength): + (JSC::JSObject::checkIndexingConsistency): + (JSC::JSObject::growOutOfLineStorage): + (JSC::JSObject::getOwnPropertyDescriptor): + (JSC::putDescriptor): + (JSC::JSObject::putDirectMayBeIndex): + (JSC::JSObject::defineOwnNonIndexProperty): + (JSC::JSObject::defineOwnProperty): + (JSC::JSObject::getOwnPropertySlotSlow): + * runtime/JSObject.h: + (JSC::JSObject::getArrayLength): + (JSObject): + (JSC::JSObject::getVectorLength): + (JSC::JSObject::putDirectIndex): + (JSC::JSObject::canGetIndexQuickly): + (JSC::JSObject::getIndexQuickly): + (JSC::JSObject::canSetIndexQuickly): + (JSC::JSObject::setIndexQuickly): + (JSC::JSObject::initializeIndex): + (JSC::JSObject::completeInitialization): + (JSC::JSObject::inSparseIndexingMode): + (JSC::JSObject::butterfly): + (JSC::JSObject::outOfLineStorage): + (JSC::JSObject::offsetForLocation): + (JSC::JSObject::indexingShouldBeSparse): + (JSC::JSObject::butterflyOffset): + (JSC::JSObject::butterflyAddress): + (JSC::JSObject::arrayStorage): + (JSC::JSObject::arrayStorageOrZero): + (JSC::JSObject::ensureArrayStorage): + (JSC::JSObject::checkIndexingConsistency): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC): + (JSC::JSObject::setButterfly): + (JSC::JSObject::setButterflyWithoutChangingStructure): + (JSC::JSObject::JSObject): + (JSC::JSObject::inlineGetOwnPropertySlot): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): + (JSC::JSObject::putDirectWithoutTransition): + (JSC::offsetInButterfly): + (JSC::offsetRelativeToPatchedStorage): + (JSC::indexRelativeToBase): + (JSC::offsetRelativeToBase): + * runtime/JSPropertyNameIterator.cpp: + (JSC::JSPropertyNameIterator::create): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSSymbolTableObject): + * runtime/JSTypeInfo.h: + (JSC): + (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero): + (JSC::TypeInfo::overridesGetPropertyNames): + * runtime/LiteralParser.cpp: + (JSC::::parse): + * runtime/ObjectConstructor.cpp: + * runtime/ObjectPrototype.cpp: + (JSC::ObjectPrototype::ObjectPrototype): + (JSC): + * runtime/ObjectPrototype.h: + (ObjectPrototype): + * runtime/PropertyOffset.h: + (JSC::offsetInOutOfLineStorage): + * runtime/PropertyStorage.h: Added. + (JSC): + * runtime/PutDirectIndexMode.h: Added. + (JSC): + * runtime/RegExpMatchesArray.cpp: + (JSC::RegExpMatchesArray::RegExpMatchesArray): + (JSC): + (JSC::RegExpMatchesArray::create): + (JSC::RegExpMatchesArray::finishCreation): + * runtime/RegExpMatchesArray.h: + (RegExpMatchesArray): + (JSC::RegExpMatchesArray::createStructure): + * runtime/RegExpObject.cpp: + (JSC::RegExpObject::getOwnNonIndexPropertyNames): + * runtime/RegExpObject.h: + (RegExpObject): + * runtime/Reject.h: Added. + (JSC): + (JSC::reject): + * runtime/SparseArrayValueMap.cpp: Added. + (JSC): + * runtime/SparseArrayValueMap.h: Added. + (JSC): + (SparseArrayEntry): + (JSC::SparseArrayEntry::SparseArrayEntry): + (SparseArrayValueMap): + (JSC::SparseArrayValueMap::sparseMode): + (JSC::SparseArrayValueMap::setSparseMode): + (JSC::SparseArrayValueMap::lengthIsReadOnly): + (JSC::SparseArrayValueMap::setLengthIsReadOnly): + (JSC::SparseArrayValueMap::find): + (JSC::SparseArrayValueMap::remove): + (JSC::SparseArrayValueMap::notFound): + (JSC::SparseArrayValueMap::isEmpty): + (JSC::SparseArrayValueMap::contains): + (JSC::SparseArrayValueMap::size): + (JSC::SparseArrayValueMap::begin): + (JSC::SparseArrayValueMap::end): + * runtime/SparseArrayValueMapInlineMethods.h: Added. + (JSC): + (JSC::SparseArrayValueMap::SparseArrayValueMap): + (JSC::SparseArrayValueMap::~SparseArrayValueMap): + (JSC::SparseArrayValueMap::finishCreation): + (JSC::SparseArrayValueMap::create): + (JSC::SparseArrayValueMap::destroy): + (JSC::SparseArrayValueMap::createStructure): + (JSC::SparseArrayValueMap::add): + (JSC::SparseArrayValueMap::putEntry): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayEntry::get): + (JSC::SparseArrayEntry::getNonSparseMode): + (JSC::SparseArrayValueMap::visitChildren): + * runtime/StorageBarrier.h: Removed. + * runtime/StringObject.cpp: + (JSC::StringObject::putByIndex): + (JSC): + (JSC::StringObject::deletePropertyByIndex): + * runtime/StringObject.h: + (StringObject): + * runtime/StringPrototype.cpp: + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::nonPropertyTransition): + (JSC): + * runtime/Structure.h: + (Structure): + (JSC::Structure::indexingType): + (JSC::Structure::indexingTypeIncludingHistory): + (JSC::Structure::indexingTypeOffset): + (JSC::Structure::create): + * runtime/StructureTransitionTable.h: + (JSC): + (JSC::toAttributes): + (JSC::newIndexingType): + (JSC::StructureTransitionTable::Hash::hash): + * tests/mozilla/js1_6/Array/regress-304828.js: + +2012-09-12 Mark Lam <mark.lam@apple.com> + + Refactor Opcodes to distinguish between core and extension opcodes. + https://bugs.webkit.org/show_bug.cgi?id=96466. + + Reviewed by Filip Pizlo. + + * bytecode/Opcode.h: + (JSC): Added FOR_EACH_CORE_OPCODE_ID() macro. + * llint/LowLevelInterpreter.h: + (JSC): Auto-generate llint opcode aliases using the + FOR_EACH_CORE_OPCODE_ID() macro. + +2012-09-11 Geoffrey Garen <ggaren@apple.com> + + Second step to fixing the Windows build: Add new symbols. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-11 Geoffrey Garen <ggaren@apple.com> + + First step to fixing the Windows build: Remove old symbols. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-11 Geoffrey Garen <ggaren@apple.com> + + Don't allocate a backing store just for a function's name + https://bugs.webkit.org/show_bug.cgi?id=96468 + + Reviewed by Oliver Hunt. + + Treat function.name like function.length etc., and use a custom getter. + This saves space in closures. + + * debugger/DebuggerCallFrame.cpp: + (JSC::DebuggerCallFrame::functionName): + * debugger/DebuggerCallFrame.h: + (DebuggerCallFrame): Updated for interface change. + + * runtime/Executable.h: + (JSC::JSFunction::JSFunction): Do a little inlining. + + * runtime/JSFunction.cpp: + (JSC::JSFunction::finishCreation): Gone now. That's the point of the patch. + + (JSC::JSFunction::name): + (JSC::JSFunction::displayName): + (JSC::JSFunction::nameGetter): + (JSC::JSFunction::getOwnPropertySlot): + (JSC::JSFunction::getOwnPropertyDescriptor): + (JSC::JSFunction::getOwnPropertyNames): + (JSC::JSFunction::put): + (JSC::JSFunction::deleteProperty): + (JSC::JSFunction::defineOwnProperty): Added custom accessors for .name + just like .length and others. + + * runtime/JSFunction.h: + (JSC::JSFunction::create): + (JSFunction): Updated for interface changes. + +2012-09-11 Mark Hahnenberg <mhahnenberg@apple.com> + + IncrementalSweeper should not sweep/free Zapped blocks + https://bugs.webkit.org/show_bug.cgi?id=96464 + + Reviewed by Filip Pizlo. + + This is not beneficial in terms of performance because there isn't any way a block can emerge + in the Zapped state from a call to Heap::collect() unless we run an eager sweep on it, in which + case we've already run all the destructors we possibly can. This also causes bugs since we don't + take zapped-ness into account when determining whether or not a block is empty to free it. The + incremental sweeper can then accidentally free blocks that it thinks are empty but are in fact + zapped with still-live objects in them. + + * heap/MarkedBlock.h: + (JSC::MarkedBlock::needsSweeping): It is only valid to sweep a block if it is in the Marked state. + +2012-09-11 Geoffrey Garen <ggaren@apple.com> + + JSActivation should inline allocate its registers, and eliminate + 'arguments' registers in the common case + https://bugs.webkit.org/show_bug.cgi?id=96427 + + Reviewed by Filip Pizlo. + + This cuts the size class for simple closures down to 64 bytes. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): Set the usesNonStrictEval + flag, which is new. Use a more specific test for whether a function + uses 'arguments', so we can avoid allocating, initializing, and tearing + off those registers in the common case. Distinguish between capturing + arguments and not, so we can avoid allocating space for arguments in + the torn-off object. + + We can make this even more general in the future, with some bytecode + generator refactoring. + + (JSC::BytecodeGenerator::resolve): Updated for new interface. + + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + (JSC::BytecodeGenerator::symbolTable): Updated some types. + + * heap/Heap.cpp: + (JSC::Heap::isValidAllocation): Allow large allocations, now that they + are both supported and used. + + * heap/Heap.h: + (Heap): Added a new form of allocateCell that specifies the full size + of the allocation, to allow for extra space on the end. + + * interpreter/CallFrame.h: + (JSC::ExecState::argumentOffset): + (JSC::ExecState::argumentOffsetIncludingThis): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): Refactored this code to be more + specific about tearing off 'arguments' vs activations. This is something + I forgot in my last patch, and it is required now that we can have + acitvations without 'arguments' registers. + + * runtime/Arguments.h: + (JSC::Arguments::setRegisters): No need for setRegisters anymore because + the activation object's storage doesn't change. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): Initialize our storage manually because + it's not declared to the C++ compiler. + + (JSC::JSActivation::visitChildren): No copyAndAppend because our storage + is not out-of-line anymore. + + (JSC::JSActivation::symbolTableGet): + (JSC::JSActivation::symbolTablePut): + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + (JSC::JSActivation::getOwnPropertySlot): + (JSC::JSActivation::getOwnPropertyDescriptor): + (JSC::JSActivation::argumentsGetter): Refactored isTornOff() testing to + avoid using a data member and to avoid hard-coding any offset assumptions. + + * runtime/JSActivation.h: + (JSC): + (JSActivation): + (JSC::JSActivation::create): + (JSC::JSActivation::isDynamicScope): + (JSC::JSActivation::captureStart): + (JSC::JSActivation::storageSize): + (JSC::JSActivation::storageSizeInBytes): + (JSC::JSActivation::registerOffset): + (JSC::JSActivation::tearOff): + (JSC::JSActivation::isTornOff): + (JSC::JSActivation::storage): + (JSC::JSActivation::allocationSize): + (JSC::JSActivation::isValid): New helper functions for doing the math + on our inline storage. Note that in the "AllOfTheThings" tear-off case, + the number of things is not known at compile time, so we store the + number in the argument count register. We can't just copy the raw contents + of the register beacuse we need a value that is safe for precise marking, + and the value in the register file has an invalid tag. + + * runtime/JSCell.h: + (JSC::allocateCell): New function for allocating with extra storage + on the end. + + * runtime/JSSymbolTableObject.h: + (JSC::JSSymbolTableObject::JSSymbolTableObject): + (JSC::JSSymbolTableObject::finishCreation): + * runtime/JSVariableObject.h: + (JSC::JSVariableObject::JSVariableObject): + (JSVariableObject): Make it easier for subclasses to use their symbol + tables during construction, by passing the table as a constructor argument. + + * runtime/SymbolTable.h: + (JSC::SharedSymbolTable::usesNonStrictEval): + (JSC::SharedSymbolTable::setUsesNonStrictEval): + (SharedSymbolTable): + (JSC::SharedSymbolTable::captureMode): + (JSC::SharedSymbolTable::setCaptureMode): + (JSC::SharedSymbolTable::captureStart): + (JSC::SharedSymbolTable::setCaptureStart): + (JSC::SharedSymbolTable::captureEnd): + (JSC::SharedSymbolTable::setCaptureEnd): + (JSC::SharedSymbolTable::parameterCountIncludingThis): + (JSC::SharedSymbolTable::setParameterCountIncludingThis): + (JSC::SharedSymbolTable::SharedSymbolTable): Added data members to more + precisely describe what kind of capture is in play, and to avoid having + data members in the activation. We expect N activations per symbol table, + so this can be a big savings in heavy closure usage. + +2012-09-11 Ryuan Choi <ryuan.choi@samsung.com> + + Fix build break with LLINT on 32bit machine after r128219 + https://bugs.webkit.org/show_bug.cgi?id=96461 + + Unreviewed build fix. + + * llint/LowLevelInterpreter32_64.asm: Fixed typo. + +2012-09-11 Michael Saboff <msaboff@apple.com> + + Build fixed for http://trac.webkit.org/changeset/128243 + + Rubber stamped by Stephanie Lewis. + + Added missing include file needed by 96422. + + * icu/unicode/unorm2.h: Added. + +2012-09-11 Michael Saboff <msaboff@apple.com> + + Build fixed for http://trac.webkit.org/changeset/128243 + + Rubber stamped by Stephanie Lewis. + + Added missing include file needed by 96422. + + * icu/unicode/ptypes.h: Added. + +2012-09-11 Michael Saboff <msaboff@apple.com> + + Update ICU header files to more recent version + https://bugs.webkit.org/show_bug.cgi?id=96422 + + Reviewed by Geoff Garen. + + Updated ICU header files to 4.6.1. Modifications made as part of the merge are: + platform.h - Changed ifndef / define / endif for U_HAVE_UINT8_T, U_HAVE_UINT16_T, U_HAVE_UINT32_T, + U_HAVE_UINT64_T, U_IS_BIG_ENDIAN and U_ENABLE_TRACING to match the existing platform.h + putil.h (line 132) - Changes defined(U_WINDOWS) to defined(WIN32) || defined(OS2) to match existing putil.h + ustring.h (line 945) - Wrapped macro argument cs with { (const UChar *)cs } to match existing ustring.h + utypes.h (line 545) - Changed defined(U_WINDOWS) to defined(WIN32) to match existing utypes.h + + * icu/unicode/localpointer.h: Added. + * icu/unicode/parseerr.h: + * icu/unicode/platform.h: + * icu/unicode/putil.h: + * icu/unicode/uchar.h: + * icu/unicode/ucnv.h: + * icu/unicode/ucnv_err.h: + * icu/unicode/ucol.h: + * icu/unicode/uconfig.h: + * icu/unicode/uenum.h: + * icu/unicode/uiter.h: + * icu/unicode/uloc.h: + * icu/unicode/umachine.h: + * icu/unicode/unorm.h: + * icu/unicode/urename.h: + * icu/unicode/uscript.h: + * icu/unicode/uset.h: + * icu/unicode/ustring.h: + * icu/unicode/utf.h: + * icu/unicode/utf16.h: + * icu/unicode/utf8.h: + * icu/unicode/utypes.h: + * icu/unicode/uvernum.h: Added. + * icu/unicode/uversion.h: + +2012-09-11 Matt Lilek <mrl@apple.com> + + OS X port should compile with newer versions of clang + https://bugs.webkit.org/show_bug.cgi?id=96434 + + m_identIsVarDecl is unused - remove it. + + Reviewed by Anders Carlsson. + + * parser/NodeConstructors.h: + (JSC::ForInNode::ForInNode): + * parser/Nodes.h: + (ForInNode): + +2012-09-11 Filip Pizlo <fpizlo@apple.com> + + LLInt should optimize and profile array length accesses + https://bugs.webkit.org/show_bug.cgi?id=96417 + + Reviewed by Oliver Hunt. + + This fixes the following hole in our array profiling strategy, where the array + is large (more than 1000 elements): + + for (var i = 0; i < array.length; ++i) ... + + The peeled use of array.length (in the array prologue) will execute only once + before DFG optimization kicks in from the loop's OSR point. Since it executed + only once, it executed in the LLInt. And prior to this patch, the LLInt did + not profile array.length accesses - so the DFG will assume, based on the lack + of profiling, that the access is in fact not an access to the JSArray length + property. That could then impede our ability to hoist the array structure + check, and may make us pessimistic in other ways as well, since the generic + GetById used for the array length access will be viewed as a side-effecting + operation. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::finalizeUnconditionally): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-09-11 Raphael Kubo da Costa <rakuco@webkit.org> + + [EFL] Rewrite the EFL-related Find modules + https://bugs.webkit.org/show_bug.cgi?id=95237 + + Reviewed by Kenneth Rohde Christiansen. + + * CMakeLists.txt: Stop setting the LINK_FLAGS property. + * PlatformEfl.cmake: Ditto. + * shell/PlatformEfl.cmake: Ditto. + +2012-09-11 Raphael Kubo da Costa <rakuco@webkit.org> + + [EFL] Unreviewed build fix after r128065. + + * CMakeLists.txt: Link against WTF for FastMalloc symbols, which + are needed when building with SYSTEM_MALLOC off. + +2012-09-10 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove m_classInfo from JSCell + https://bugs.webkit.org/show_bug.cgi?id=96311 + + Reviewed by Oliver Hunt. + + Now that no one is using the ClassInfo in JSCell, we can remove it for the greater good. This is a 1.5% win on v8v7 and + a 1.7% win on kraken, and is an overall performance progression. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Had to rearrange the order of when we take things off the free list + and when we store the Structure in the object because we would clobber the free list otherwise. This made it not okay for + the structure argument and the scratch register to alias one another. Also removed the store of the ClassInfo pointer in the + object. Yay! + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: Since it's no longer okay for for the scratch register and structure register to alias + one another as stated above, had to add an extra temporary for passing the Structure. + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: Ditto. + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): Similar changes to DFG's inline allocation except that it removed the object from + the free list first, so no changes were necessary there. + * llint/LowLevelInterpreter.asm: Change the constants for amount of inline storage to match PropertyOffset.h and remove + the store of the ClassInfo pointer during inline allocation. + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSCell.h: Remove the m_classInfo field and associated methods. + (JSCell): + * runtime/JSObject.h: + (JSObject): + * runtime/PropertyOffset.h: Expand the number of inline storage properties to take up the extra space that we're freeing + with the removal of the ClassInfo pointer. + (JSC): + * runtime/Structure.h: + (JSC): + (JSC::JSCell::JSCell): + (JSC::JSCell::finishCreation): + +2012-09-10 Geoffrey Garen <ggaren@apple.com> + + Added large allocation support to MarkedSpace + https://bugs.webkit.org/show_bug.cgi?id=96214 + + Originally reviewed by Oliver Hunt, then I added a design revision by + suggested by Phil Pizlo. + + I expanded the imprecise size classes to cover up to 32KB, then added + an mmap-based allocator for everything bigger. There's a lot of tuning + we could do in these size classes, but currently they're almost + completely unused, so I haven't done any tuning. + + Subtle point: the large allocator is a degenerate case of our free list + logic. Its list only ever contains zero or one items. + + * heap/Heap.h: + (JSC::Heap::allocateStructure): Pipe in size information. + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): Handle the case where we + find a free item in the sweep list but the item isn't big enough. This + can happen in the large allocator because it mixes sizes. + + (JSC::MarkedAllocator::tryAllocate): + (JSC::MarkedAllocator::allocateSlowCase): More piping. + + (JSC::MarkedAllocator::allocateBlock): Handle the oversize case. + + (JSC::MarkedAllocator::addBlock): I moved the call to didAddBlock here + because it made more sense. + + * heap/MarkedAllocator.h: + (MarkedAllocator): + (JSC::MarkedAllocator::allocate): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::MarkedSpace): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::canonicalizeCellLivenessData): + (JSC::MarkedSpace::isPagedOut): + (JSC::MarkedSpace::freeBlock): + * heap/MarkedSpace.h: + (MarkedSpace): + (JSC::MarkedSpace::allocatorFor): + (JSC::MarkedSpace::destructorAllocatorFor): + (JSC::MarkedSpace::allocateWithoutDestructor): + (JSC::MarkedSpace::allocateWithDestructor): + (JSC::MarkedSpace::allocateStructure): + (JSC::MarkedSpace::forEachBlock): + * runtime/Structure.h: + (JSC::Structure): More piping. + +2012-09-10 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Windows (32-bit) build. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_tear_off_arguments): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_tear_off_arguments): Get operands 1 and 2, not 1 and 1. :( + + Also took this opportunity to rename to indicate that these values are + not destinations anymore. + +2012-09-10 Geoffrey Garen <ggaren@apple.com> + + DFG misses arguments tear-off for function.arguments if 'arguments' is used + https://bugs.webkit.org/show_bug.cgi?id=96227 + + Reviewed by Gavin Barraclough. + + We've decided not to allow function.arguments to alias the local + 'arguments' object, or a local var or function named 'arguments'. + Aliasing complicates the implementation (cf, this bug) and can produce + surprising behavior for web programmers. + + Eliminating the aliasing has the side-effect of fixing this bug. + + The compatibilty story: function.arguments is deprecated, was never + specified, and throws an exception in strict mode, so we expect it to + disappear over time. Firefox does not alias to 'arguments'; Chrome + does, but not if you use eval or with; IE does; Safari did. + + * dfg/DFGByteCodeParser.cpp: Noticed a little cleanup while verifying + this code. Use the CodeBlock method for better encapsulation. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::retrieveArgumentsFromVMCode): Behavior change: don't + alias. + + * tests/mozilla/js1_4/Functions/function-001.js: + (TestFunction_4): Updated test expectations for changed behavior. + +2012-09-10 Filip Pizlo <fpizlo@apple.com> + + offlineasm has some impossible to implement, and unused, instructions + https://bugs.webkit.org/show_bug.cgi?id=96310 + + Reviewed by Mark Hahnenberg. + + * offlineasm/armv7.rb: + * offlineasm/instructions.rb: + * offlineasm/x86.rb: + +2012-09-09 Geoffrey Garen <ggaren@apple.com> + + Refactored op_tear_off* to support activations that don't allocate space for 'arguments' + https://bugs.webkit.org/show_bug.cgi?id=96231 + + Reviewed by Gavin Barraclough. + + This is a step toward smaller activations. + + As a side-effect, this patch eliminates a load and branch from the hot path + of activation tear-off by moving it to the cold path of arguments tear-off. Our + optimizing assumptions are that activations are common and that reifying the + arguments object is less common. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC::padOpcodeName): Updated for new opcode lengths. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::addConstantValue): Added support for JSValue() + in the bytecode, which we use when we have 'arguments' but no activation. + + (JSC::BytecodeGenerator::emitReturn): Always emit tear_off_arguments + if we've allocated the arguments registers. This allows tear_off_activation + not to worry about the arguments object anymore. + + Also, pass the activation and arguments values directly to these opcodes + instead of requiring the opcodes to infer the values through special + registers. This gives us more flexibility to move or eliminate registers. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGNode.h: + (Node): Updated for new opcode lengths. + + * dfg/DFGOperations.cpp: Activation tear-off doesn't worry about the + arguments object anymore. If 'arguments' is in use and reified, it's + responsible for aliasing back to the activation object in tear_off_arguments. + + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Don't pass the arguments object to + activation tear-off; do pass the activation object to arguments tear-off. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): Ditto. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_tear_off_activation): + (JSC::JIT::emit_op_tear_off_arguments): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_tear_off_activation): + (JSC::JIT::emit_op_tear_off_arguments): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Same change in a few more execution engines. + +2012-09-10 Patrick Gansterer <paroga@webkit.org> + + [JSC] Use StringBuilder::appendNumber() instead of String::number() + https://bugs.webkit.org/show_bug.cgi?id=96236 + + Reviewed by Benjamin Poulain. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + +2012-09-06 Mark Hahnenberg <mhahnenberg@apple.com> + + Combine MarkStack and SlotVisitor into single class + https://bugs.webkit.org/show_bug.cgi?id=96043 + + Reviewed by Geoff Garen. + + Move all of MarkStack into SlotVisitor. The remaining stuff in MarkStack.cpp actually has to do + with MarkStack management/allocation. Cleaned up a few of the header files while I was at it. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + * dfg/DFGCommon.h: + * heap/GCThreadSharedData.cpp: + * heap/GCThreadSharedData.h: + (GCThreadSharedData): + * heap/HeapRootVisitor.h: + * heap/MarkStack.cpp: + (JSC): + * heap/MarkStack.h: + (JSC): + (MarkStackSegment): + (JSC::MarkStackSegment::data): + (JSC::MarkStackSegment::capacityFromSize): + (JSC::MarkStackSegment::sizeFromCapacity): + (MarkStackSegmentAllocator): + (MarkStackArray): + * heap/MarkStackInlineMethods.h: + (JSC::MarkStackArray::postIncTop): + (JSC): + (JSC::MarkStackArray::preDecTop): + (JSC::MarkStackArray::setTopForFullSegment): + (JSC::MarkStackArray::setTopForEmptySegment): + (JSC::MarkStackArray::top): + (JSC::MarkStackArray::validatePrevious): + (JSC::MarkStackArray::append): + (JSC::MarkStackArray::canRemoveLast): + (JSC::MarkStackArray::removeLast): + (JSC::MarkStackArray::isEmpty): + (JSC::MarkStackArray::size): + * heap/SlotVisitor.cpp: Added. + (JSC): + (JSC::SlotVisitor::SlotVisitor): + (JSC::SlotVisitor::~SlotVisitor): + (JSC::SlotVisitor::setup): + (JSC::SlotVisitor::reset): + (JSC::SlotVisitor::append): + (JSC::visitChildren): + (JSC::SlotVisitor::donateKnownParallel): + (JSC::SlotVisitor::drain): + (JSC::SlotVisitor::drainFromShared): + (JSC::SlotVisitor::mergeOpaqueRoots): + (JSC::SlotVisitor::startCopying): + (JSC::SlotVisitor::allocateNewSpaceSlow): + (JSC::SlotVisitor::allocateNewSpaceOrPin): + (JSC::JSString::tryHashConstLock): + (JSC::JSString::releaseHashConstLock): + (JSC::JSString::shouldTryHashConst): + (JSC::SlotVisitor::internalAppend): + (JSC::SlotVisitor::copyAndAppend): + (JSC::SlotVisitor::doneCopying): + (JSC::SlotVisitor::harvestWeakReferences): + (JSC::SlotVisitor::finalizeUnconditionalFinalizers): + (JSC::SlotVisitor::validate): + * heap/SlotVisitor.h: + (JSC): + (SlotVisitor): + (JSC::SlotVisitor::sharedData): + (JSC::SlotVisitor::isEmpty): + (JSC::SlotVisitor::visitCount): + (JSC::SlotVisitor::resetChildCount): + (JSC::SlotVisitor::childCount): + (JSC::SlotVisitor::incrementChildCount): + (ParallelModeEnabler): + (JSC::ParallelModeEnabler::ParallelModeEnabler): + (JSC::ParallelModeEnabler::~ParallelModeEnabler): + * heap/SlotVisitorInlineMethods.h: + (JSC::SlotVisitor::append): + (JSC): + (JSC::SlotVisitor::appendUnbarrieredPointer): + (JSC::SlotVisitor::appendUnbarrieredValue): + (JSC::SlotVisitor::internalAppend): + (JSC::SlotVisitor::addWeakReferenceHarvester): + (JSC::SlotVisitor::addUnconditionalFinalizer): + (JSC::SlotVisitor::addOpaqueRoot): + (JSC::SlotVisitor::containsOpaqueRoot): + (JSC::SlotVisitor::opaqueRootCount): + (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): + (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): + (JSC::SlotVisitor::donate): + (JSC::SlotVisitor::donateAndDrain): + * jit/JITWriteBarrier.h: + (JSC::SlotVisitor::append): + * jit/JumpReplacementWatchpoint.cpp: + * runtime/JSCell.h: + * runtime/Structure.h: + (JSC::SlotVisitor::internalAppend): + * runtime/WriteBarrier.h: + (JSC): + (JSC::SlotVisitor::append): + (JSC::SlotVisitor::appendValues): + * yarr/YarrJIT.cpp: + +2012-09-10 Hojong Han <hojong.han@samsung.com> + + [EFL] JIT memory usage is not retrieved + https://bugs.webkit.org/show_bug.cgi?id=96095 + + Reviewed by Geoffrey Garen. + + Fill JITBytes for EFL port. + + * runtime/MemoryStatistics.cpp: + (JSC::globalMemoryStatistics): + +2012-09-10 Thiago Marcos P. Santos <thiago.santos@intel.com> + + [CMake][EFL] Enable the LLInt + https://bugs.webkit.org/show_bug.cgi?id=92682 + + Reviewed by Csaba Osztrogonác. + + Generate the headers needed by LLint when LLint is enabled. + + * CMakeLists.txt: + +2012-09-10 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing files. + +2012-09-09 Mark Lam <mark.lam@apple.com> + + Fixed a few llint C++ interpreter bugs. + https://bugs.webkit.org/show_bug.cgi?id=96127. + + Reviewed by Geoffrey Garen. + + * llint/LLIntCLoop.h: + CLoop::execute()'s bootstrapOpcodeId does not need a default + value. There is no case when this function is called without + that parameter being specified. + * llint/LowLevelInterpreter.asm: + Moved the dispatchAfterCall() call to where it is needed. + For the C_LOOP back-end, it generates unreachable code. + * llint/LowLevelInterpreter.cpp: + #include <wtf/Assertions.h> because LLIntAssembly.h needs it. + (JSC): + Fixed bug in SIGN_BIT32() macro. + Placate a MSVC warning for t0, and t1 being uninitialized. + (JSC::CLoop::execute): + The bootstrapOpcodeId arg should always be specified. + MSVC doesn't like UNUSED_PARAM() for labels. Switch to using + the new UNUSED_LABEL() macro. + * offlineasm/cloop.rb: + * offlineasm/generate_offset_extractor.rb: + Resolved a compiler warning found via MSVC. + +2012-09-09 Patrick Gansterer <paroga@webkit.org> + + Add StringBuilder::appendNumber() and use it + https://bugs.webkit.org/show_bug.cgi?id=96030 + + Reviewed by Eric Seidel. + + Also fix a bunch of append() vs. appendLiteral() issues in the surrounding code. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * interpreter/Interpreter.h: + (JSC::StackFrame::toString): + +2012-09-09 Patrick Gansterer <paroga@webkit.org> + + Make the String initialization on the function side of String::number() + https://bugs.webkit.org/show_bug.cgi?id=95940 + + Reviewed by Benjamin Poulain. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-09-09 Geoffrey Garen <ggaren@apple.com> + + Rolled out <http://trac.webkit.org/changeset/127939> because it broke + fast/js/named-function-expression.html. + + Refactored bytecode generator initialization to support moving captured vars around + https://bugs.webkit.org/show_bug.cgi?id=96159 + + Reviewed by Gavin Barraclough. + +2012-09-08 Csaba Osztrogonác <ossy@webkit.org> + + LLInt buildfix for case sensitive filesystems + https://bugs.webkit.org/show_bug.cgi?id=96099 + + Reviewed by Michael Saboff. + + * llint/LowLevelInterpreter.cpp: Fix filenames. + +2012-09-07 Benjamin Poulain <bpoulain@apple.com> + + Rename the ustring() accessor to string() + https://bugs.webkit.org/show_bug.cgi?id=95919 + + Reviewed by Geoffrey Garen. + + Rename ustring() to string() to make the accessor name more logical after + r127191. + + * API/JSBase.cpp: + (JSEvaluateScript): + (JSCheckScriptSyntax): + * API/JSObjectRef.cpp: + (JSObjectMakeFunctionWithCallback): + (JSObjectMakeFunction): + (JSObjectCopyPropertyNames): + * API/JSProfilerPrivate.cpp: + (JSStartProfiling): + (JSEndProfiling): + * API/JSValueRef.cpp: + (JSValueMakeString): + (JSValueMakeFromJSONString): + * API/OpaqueJSString.cpp: + (OpaqueJSString::string): + * API/OpaqueJSString.h: + (OpaqueJSString): + * bytecode/CodeBlock.cpp: + (JSC::idName): + (JSC::CodeBlock::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + * bytecompiler/NodesCodegen.cpp: + (JSC::RegExpNode::emitBytecode): + (JSC::processClauseList): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jsc.cpp: + (GlobalObject::addFunction): + (GlobalObject::addConstructableFunction): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * parser/ASTBuilder.h: + (JSC::ASTBuilder::createRegExp): + * parser/Parser.cpp: + (JSC::::parsePrimaryExpression): + * parser/Parser.h: + (JSC::Scope::declareVariable): + (JSC::Scope::declareParameter): + (JSC::Scope::useVariable): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::createRegExp): + * runtime/ExceptionHelpers.cpp: + (JSC::createUndefinedVariableError): + * runtime/Executable.cpp: + (JSC::FunctionExecutable::paramString): + * runtime/Executable.h: + (JSC::FunctionExecutable::finishCreation): + * runtime/FunctionPrototype.cpp: + (JSC::FunctionPrototype::addFunctionProperties): + * runtime/Identifier.h: + (JSC::Identifier::string): + * runtime/JSFunction.cpp: + (JSC::JSFunction::calculatedDisplayName): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + * runtime/JSONObject.cpp: + (JSC::PropertyNameForFunctionCall::value): + (JSC::Stringifier::Holder::appendNextProperty): + (JSC::Walker::walk): + * runtime/JSPropertyNameIterator.h: + (JSC::JSPropertyNameIterator::finishCreation): + * runtime/JSScope.cpp: + (JSC::JSScope::resolveBase): + * runtime/JSString.h: + (JSC::inlineJSValueNotStringtoString): + * runtime/LiteralParser.cpp: + (JSC::::parse): + * runtime/ObjectConstructor.cpp: + (JSC::ObjectConstructor::finishCreation): + (JSC::objectConstructorGetOwnPropertyNames): + (JSC::objectConstructorKeys): + * runtime/RegExpConstructor.cpp: + (JSC::RegExpConstructor::finishCreation): + +2012-09-07 Gavin Barraclough <barraclough@apple.com> + + CALLFRAME_OFFSET and EXCEPTION_OFFSET are same in ctiTrampoline on ARM Thumb2 + https://bugs.webkit.org/show_bug.cgi?id=82013 + + Reviewed by Geoff Garen. + + Neither of these values need to be stored. At all. + + * jit/JITStubs.cpp: + (JSC): + (JSC::ctiTrampoline): + (JSC::JITThunks::JITThunks): + - Nothing to see here. Move along. + +2012-09-07 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r127938. + http://trac.webkit.org/changeset/127938 + https://bugs.webkit.org/show_bug.cgi?id=96166 + + It broke the build (Requested by smfr on #webkit). + + * llint/LowLevelInterpreter.cpp: + (JSC): + (JSC::CLoop::execute): + * offlineasm/cloop.rb: + +2012-09-07 Geoffrey Garen <ggaren@apple.com> + + Refactored bytecode generator initialization to support moving captured vars around + https://bugs.webkit.org/show_bug.cgi?id=96159 + + Reviewed by Gavin Barraclough. + + This patch separates the stages of allocating registers, declaring identifiers + in the symbol table, and initializing registers, so you can change + allocation decisions without breaking the world. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): Call a set of helper functions + instead of inlining all the code, to help clarity. + + (JSC::BytecodeGenerator::allocateCapturedVars): + (JSC::BytecodeGenerator::allocateUncapturedVars): + (JSC::BytecodeGenerator::allocateActivationVar): + (JSC::BytecodeGenerator::allocateArgumentsVars): + (JSC::BytecodeGenerator::allocateCalleeVarUndeclared): + (JSC::BytecodeGenerator::declareParameters): + (JSC::BytecodeGenerator::declareCallee): + (JSC::BytecodeGenerator::initCalleeVar): + (JSC::BytecodeGenerator::initArgumentsVars): + (JSC::BytecodeGenerator::initActivationVar): + (JSC::BytecodeGenerator::initThisParameter): + (JSC::BytecodeGenerator::initFunctionDeclarations): + (JSC::BytecodeGenerator::declareParameter): + (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): + (JSC::BytecodeGenerator::createActivationIfNecessary): Factored these + helper functions out from pre-existing code. + + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * parser/ASTBuilder.h: + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::addVar): + * parser/Nodes.h: + (JSC::DeclarationStacks::VarDeclaration::VarDeclaration): + (VarDeclaration): + (JSC::DeclarationStacks::FunctionDeclaration::FunctionDeclaration): + (FunctionDeclaration): Declaration stacks get a little more data now, + to support allocating registers before putting things in the symbol + table. I'm convinced that we should eventually just expand the symbol + table to understand these things. + +2012-09-07 Mark Lam <mark.lam@apple.com> + + Fix a llint C++ interpreter bugs. + https://bugs.webkit.org/show_bug.cgi?id=96127. + + Reviewed by Filip Pizlo. + + * llint/LowLevelInterpreter.cpp: + (JSC): + (JSC::CLoop::execute): + * offlineasm/cloop.rb: + +2012-09-07 Gavin Barraclough <barraclough@apple.com> + + Object.prototype.__define{G,S}etter__ with non-callable second parameter should throw TypeError instead of SyntaxError + https://bugs.webkit.org/show_bug.cgi?id=93873 + + Reviewed by Sam Weinig. + + * runtime/ObjectPrototype.cpp: + (JSC::objectProtoFuncDefineGetter): + - throw TypeError instead of SyntaxError + (JSC::objectProtoFuncDefineSetter): + - throw TypeError instead of SyntaxError + +2012-09-06 Mark Hahnenberg <mhahnenberg@apple.com> + + JSC should have a zombie mode + https://bugs.webkit.org/show_bug.cgi?id=96047 + + Reviewed by Geoffrey Garen. + + To aid clients of JSC while they are debugging memory issues, we should add a zombie + mode that scribbles into objects in the MarkedSpace after they are found to be dead + to prevent a sort of "use after free" situation. As a first cut we should support a + mode that just scribbles on objects prior to their being reused (i.e. while they are + "zombies") and a mode in which, in addition to scribbling on zombies, once an object + has been marked its mark bit will never be cleared, thus giving us "immortal" zombies. + + These two modes will be enabled through the use of environment variables. For now these + will be "JSZombieEnabled" and "JSImmortalZombieEnabled". Setting them to any value will + result in the use of the appropriate mode. + + * heap/Heap.cpp: + (JSC::Heap::collect): Zombifies dead objects at the end of collection if zombie mode is enabled. + (ZombifyCellFunctor): + (JSC::ZombifyCellFunctor::ZombifyCellFunctor): Sets marked bits for dead objects if in immortal mode and writes 0xbbadbeef into them. + (JSC::ZombifyCellFunctor::operator()): + (JSC): + (ZombifyBlockFunctor): + (JSC::ZombifyBlockFunctor::operator()): + (JSC::Heap::zombifyDeadObjects): Eagerly sweeps so that we don't write garbage into an object before it + is finalized/destroyed. + * heap/Heap.h: + (Heap): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::forEachDeadCell): Used to iterate over dead cells at the end of collection if zombie mode is enabled. + (JSC): + * runtime/Options.cpp: + (JSC::Options::initialize): + * runtime/Options.h: + (JSC): + +2012-09-05 Geoffrey Garen <ggaren@apple.com> + + Rolled back in <http://trac.webkit.org/changeset/127698> with a fix for + fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html, which + is to make sure that function declarations don't put their names in scope. + + Reviewed by Gavin Barraclough. + + Named functions should not allocate scope objects for their names + https://bugs.webkit.org/show_bug.cgi?id=95659 + + Reviewed by Oliver Hunt. + +2012-09-06 Michael Saboff <msaboff@apple.com> + + 16 bit JSRopeString up converts an 8 bit fibers to 16 bits during resolution + https://bugs.webkit.org/show_bug.cgi?id=95810 + + Reviewed by Benjamin Poulain. + + Added 8 bit path that copies the contents of an 8 bit fiber to the 16 bit buffer + when resolving a 16 bit rope. + + * runtime/JSString.cpp: + (JSC::JSRopeString::resolveRopeSlowCase): + +2012-09-06 Gavin Barraclough <barraclough@apple.com> + + JS test suite puts incorrect limitations on Function.toString() + https://bugs.webkit.org/show_bug.cgi?id=3975 + + Reviewed by Geoff Garen. + + The result of function toString is implementation defined; + these test cases were looking for specific whitespace formatting + that matches mozilla's, and for redundant braces to be inserted + around if/else blocks. Stop that. + + * tests/mozilla/expected.html: + * tests/mozilla/js1_2/function/tostring-1.js: + (simplify): + - reduce whitespace differences + * tests/mozilla/js1_2/function/tostring-2.js: + (simplify): + - reduce whitespace differences + (TestOr): + (TestAnd): + - added braces to match expected output + +2012-09-06 Yuqiang Xian <yuqiang.xian@intel.com> + + Performance regressions on 32-bit platforms with revisions 125637 and 126387 + https://bugs.webkit.org/show_bug.cgi?id=95953 + + Reviewed by Filip Pizlo. + + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): Fix the typo. + +2012-09-05 Geoffrey Garen <ggaren@apple.com> + + Rolled out <http://trac.webkit.org/changeset/127698> because it broke + fast/dom/HTMLScriptElement/script-reexecution-pretty-diff.html + + Named functions should not allocate scope objects for their names + https://bugs.webkit.org/show_bug.cgi?id=95659 + + Reviewed by Oliver Hunt. + +2012-09-06 Mark Lam <mark.lam@apple.com> + + Renamed useYarrJIT() option to useRegExpJIT(). Also fixed regression in + which inadvertantly allows the ASM llint to use the baseline JIT when + useRegExpJIT() is true. + https://bugs.webkit.org/show_bug.cgi?id=95918. + + Reviewed by Geoffrey Garen. + + * runtime/JSGlobalData.cpp: + (JSC::enableAssembler): + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSC::JSGlobalData::canUseJIT): + (JSC::JSGlobalData::canUseRegExpJIT): + (JSGlobalData): + * runtime/Options.cpp: + (JSC::Options::initialize): + * runtime/Options.h: + (JSC): + +2012-09-06 Patrick Gansterer <paroga@webkit.org> + + Build fix for Interpreter after r127698. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + +2012-09-05 Geoffrey Garen <ggaren@apple.com> + + Named functions should not allocate scope objects for their names + https://bugs.webkit.org/show_bug.cgi?id=95659 + + Reviewed by Oliver Hunt. + + In most cases, we can merge a function expression's name into its symbol + table. This reduces memory footprint per closure from three objects + (function + activation + name scope) to two (function + activation), + speeds up closure allocation, and speeds up recursive calls. + + In the case of a named function expression that contains a non-strict + eval, the rules are so bat-poop crazy that I don't know how to model + them without an extra object. Since functions now default to not having + such an object, this case needs to allocate the object on function + entry. + + Therefore, this patch makes the slow case a bit slower so the fast case + can be faster and more memory-efficient. (Note that the slow case already + allocates an activation on entry, and until recently also allocated a + scope chain node on entry, so adding one allocation on entry shouldn't + break the bank.) + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): Caught a missed initializer. No behavior change. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): Put the callee in static scope + during compilation so it doesn't need to be in dynamic scope at runtime. + + (JSC::BytecodeGenerator::resolveCallee): + (JSC::BytecodeGenerator::addCallee): Helper functions for either statically + resolving the callee or adding a dynamic scope that will resolve to it, + depending on whether you're in the fast path. + + We move the callee into a var location if it's captured because activations + prefer to have contiguous ranges of captured variables. + + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::registerFor): + (BytecodeGenerator): + + * dfg/DFGOperations.cpp: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): This is the point of the patch: remove + one allocation in the case of a named function expression. + + * parser/Parser.cpp: + (JSC::::Parser): + * parser/Parser.h: + (JSC::Scope::declareCallee): + (Scope): + (Parser): + (JSC::parse): + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + (JSC::ProgramExecutable::checkSyntax): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::produceCodeBlockFor): + (JSC::FunctionExecutable::fromGlobalCode): Pipe the callee's name through + the parser so we get accurate information on whether the callee was captured. + + (JSC::FunctionExecutable::FunctionExecutable): + (JSC::EvalExecutable::compileInternal): + (JSC::ProgramExecutable::checkSyntax): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::produceCodeBlockFor): + (JSC::FunctionExecutable::fromGlobalCode): + * runtime/Executable.h: + (JSC::FunctionExecutable::create): + (FunctionExecutable): + (JSC::FunctionExecutable::finishCreation): I had to refactor function + creation to support the following function constructor quirk: the function + gets a name, but its name is not in lexical scope. + + To simplify this, FunctionExecutable now automatically extracts all the + data it needs from the parsed node. The special "fromGlobalCode" path + used by the function constructor creates an anonymous function, and then + quirkily sets the value used by the .name property to be non-null, even + though the parsed name is null. + + * runtime/JSNameScope.h: + (JSC::JSNameScope::create): + (JSC::JSNameScope::JSNameScope): Added support for explicitly specifying + your container scope. The compiler uses this for named function expressions. + +2012-09-05 Gavin Barraclough <barraclough@apple.com> + + a = data[a]++; sets the wrong key in data + https://bugs.webkit.org/show_bug.cgi?id=91270 + + Reviewed by Oliver Hunt. + + Postfix inc/dec is unsafely using finalDestination, can trample base/subscript prior to the result being put. + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixNode::emitResolve): + - Remove redundant parens. + (JSC::PostfixNode::emitBracket): + (JSC::PostfixNode::emitDot): + - Refactored to use tempDestination instead of finalDestination. + (JSC::PrefixNode::emitBracket): + (JSC::PrefixNode::emitDot): + - Should be using emitPreIncOrDec. + +2012-09-05 Gavin Barraclough <barraclough@apple.com> + + Bug, assignment within subscript of prefix/postfix increment of bracket access + https://bugs.webkit.org/show_bug.cgi?id=95913 + + Reviewed by Oliver Hunt. + + javascript:alert((function(){ var a = { x:1 }; var b = { x:1 }; a[a=b,"x"]++; return a.x; })()) + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixNode::emitBracket): + (JSC::PrefixNode::emitBracket): + - Should check for assigments in the subscript when loading the base. + * parser/Nodes.h: + (JSC::BracketAccessorNode::subscriptHasAssignments): + (BracketAccessorNode): + - Used by emitBracket methods. + +2012-09-05 Gavin Barraclough <barraclough@apple.com> + + Merge prefix/postfix nodes + https://bugs.webkit.org/show_bug.cgi?id=95898 + + Reviewed by Geoff Garen. + + Simplify the AST. + This will also mean we have access to m_subscriptHasAssignments when generating a prefix/postfix op applied to a bracket access. + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixNode::emitResolve): + - was PostfixResolveNode::emitBytecode + (JSC::PostfixNode::emitBracket): + - was PostfixBracketNode::emitBytecode + (JSC::PostfixNode::emitDot): + - was PostfixDotNode::emitBytecode + (JSC::PostfixNode::emitBytecode): + - was PostfixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate. + (JSC::PrefixNode::emitResolve): + - was PrefixResolveNode::emitBytecode + (JSC::PrefixNode::emitBracket): + - was PrefixBracketNode::emitBytecode + (JSC::PrefixNode::emitDot): + - was PrefixDotNode::emitBytecode + (JSC::PrefixNode::emitBytecode): + - was PrefixErrorNode::emitBytecode, call resolve/bracket/dot version as appropriate. + * parser/ASTBuilder.h: + (JSC::ASTBuilder::makePrefixNode): + - Just makes a PrefixNode! + (JSC::ASTBuilder::makePostfixNode): + - Just makes a PostfixNode! + * parser/NodeConstructors.h: + (JSC::PostfixNode::PostfixNode): + - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode. + (JSC::PrefixNode::PrefixNode): + - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode. + * parser/Nodes.h: + (PostfixNode): + - Added, merge of PostfixResolveNode/PostfixBracketNode/PostfixDotNode/PostfixErrorNode. + (PrefixNode): + - Added, merge of PrefixResolveNode/PrefixBracketNode/PrefixDotNode/PrefixErrorNode. + +2012-09-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove use of JSCell::classInfoOffset() from tryCacheGetByID + https://bugs.webkit.org/show_bug.cgi?id=95860 + + Reviewed by Oliver Hunt. + + We should just do the indirection through the Structure instead. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + +2012-09-05 Geoffrey Garen <ggaren@apple.com> + + Throw exceptions when assigning to const in strict mode + https://bugs.webkit.org/show_bug.cgi?id=95894 + + Reviewed by Oliver Hunt. + + Currently, this never happens; but it will start happening once the + callee is a local const register. In this patch, there's no change in + behavior. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): Helper function + for doing the throwing. + * bytecompiler/BytecodeGenerator.h: + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixResolveNode::emitBytecode): + (JSC::PrefixResolveNode::emitBytecode): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): Call the helper function. + +2012-09-05 Geoffrey Garen <ggaren@apple.com> + + Refactored callee access in the DFG to support it in the general case + https://bugs.webkit.org/show_bug.cgi?id=95887 + + Reviewed by Phil Pizlo and Gavin Barraclough. + + To support named function expressions, the DFG needs to understand the + callee register being used in arbitrary expressions, and not just + create_this. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getDirect): + (JSC::DFG::ByteCodeParser::getCallee): Remap access to the callee register + into a GetCallee node. Otherwise, we get confused and think we have a + negatively indexed argument. + + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): Inlining also + needs to remap, but to the callee in the inline frame, and not the caller's + callee. + + (JSC::DFG::ByteCodeParser::parseBlock): Since we support the callee in + the general case now, there's no need to handle it in a special way for + create_this. + +2012-09-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove use of JSCell::classInfoOffset() from virtualForThunkGenerator + https://bugs.webkit.org/show_bug.cgi?id=95821 + + Reviewed by Oliver Hunt. + + We can replace the load of the ClassInfo from the object with a load from the Structure. + + * dfg/DFGThunks.cpp: + (JSC::DFG::virtualForThunkGenerator): + +2012-09-05 Benjamin Poulain <bpoulain@apple.com> + + Fix the uses of String::operator+=() for Mac + https://bugs.webkit.org/show_bug.cgi?id=95818 + + Reviewed by Dan Bernstein. + + * jsc.cpp: + (functionJSCStack): Use StringBuilder to create the stack dump, it is faster + and avoid String::operator+=(). + + * parser/Parser.h: + (JSC::Parser::updateErrorMessageSpecialCase): + (JSC::Parser::updateErrorMessage): + (JSC::Parser::updateErrorWithNameAndMessage): + Use the String operators (and makeString) to concatenate the strings. + +2012-09-05 Gabor Rapcsanyi <rgabor@webkit.org> + + DFG JIT doesn't work properly on ARM hardfp + https://bugs.webkit.org/show_bug.cgi?id=95684 + + Reviewed by Filip Pizlo. + + Add hardfp support to DFG JIT. The patch is created with the + help of Zoltan Herczeg. + + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArguments): + * dfg/DFGFPRInfo.h: + (FPRInfo): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): + (JSC::DFG::SpeculativeJIT::appendCallSetResult): + +2012-09-04 Mark Lam <mark.lam@apple.com> + + Allow the YarrJIT to use the assembler even when useJIT() is false. + Introduce the useYarrJIT() option. + https://bugs.webkit.org/show_bug.cgi?id=95809. + + Reviewed by Geoffrey Garen. + + * runtime/JSGlobalData.cpp: + (JSC::enableAssembler): + * runtime/Options.cpp: + (JSC::Options::initialize): + * runtime/Options.h: + (JSC): + +2012-09-04 Gavin Barraclough <barraclough@apple.com> + + inc/dec behave incorrectly operating on a resolved const + https://bugs.webkit.org/show_bug.cgi?id=95815 + + Reviewed by Geoff Garen. + + There are two bugs here. + + (1) When the value being incremented is const, and the result is ignored, we assume this cannot be observed, and emit no code. + However if the value being incremented is not a primitive & has a valueOf conversion, then this should be being called. + + (2) In the case of a pre-increment of a const value where the result is not ignored, we'll move +/-1 to the destination, then + add the resolved const value being incremented to this. This is problematic if the destination is a local, and the const + value being incremented has a valueOf conversion that throws - the destination will be modified erroneously. Instead, we + need to use a temporary location. + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixResolveNode::emitBytecode): + (JSC::PrefixResolveNode::emitBytecode): + - always at least perform a toNumber conversion, use tempDestination when reducing inc/dec to an add +/-1. + +2012-09-04 Filip Pizlo <fpizlo@apple.com> + + DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound + https://bugs.webkit.org/show_bug.cgi?id=95717 + + Reviewed by Oliver Hunt. + + Rolling back in after fixing the negative index case. + + Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already + there so we should just use it! + + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-09-04 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r127503. + http://trac.webkit.org/changeset/127503 + https://bugs.webkit.org/show_bug.cgi?id=95788 + + broke some tests (fast/js/dfg-negative-array-index, fast/js + /dfg-put-by-val-setter-then-get-by-val) (Requested by thorton + on #webkit). + + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-09-04 Benjamin Poulain <bpoulain@apple.com> + + Improve JSC use of Strings after the UString->String change + https://bugs.webkit.org/show_bug.cgi?id=95633 + + Reviewed by Geoffrey Garen. + + This patch improve the use of strings in the JSC runtime. + + The initialization of Identifier is left for future patches. + + The improvements are the following: + -5% faster to raise one of the modified exception. + -3 times faster to execute Boolean::toString() + + Most of the changes are just about using the new methods + for string literals. + + With the changes, the binary on x86_64 gets 176 bytes smaller. + + * API/JSCallbackObjectFunctions.h: + (JSC::::staticFunctionGetter): + (JSC::::callbackGetter): + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * API/JSObjectRef.cpp: + (JSObjectMakeFunctionWithCallback): + * bytecode/CodeBlock.cpp: + (JSC::valueToSourceString): + (JSC::CodeBlock::nameForRegister): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::addStackTraceIfNecessary): + * runtime/ArrayConstructor.cpp: + (JSC::constructArrayWithSizeQuirk): + * runtime/ArrayPrototype.cpp: + (JSC::shift): + (JSC::unshift): + (JSC::arrayProtoFuncPop): + (JSC::arrayProtoFuncReverse): + * runtime/BooleanPrototype.cpp: + (JSC::booleanProtoFuncToString): Instead of instanciating new strings, reuse the + keywords available in SmallStrings. Avoiding the creation of the JSString and StringImpl + makes the method significantly faster. + + * runtime/DateConversion.cpp: + (JSC::formatDateTime): + * runtime/DatePrototype.cpp: + (JSC::formatLocaleDate): + (JSC::formateDateInstance): + (JSC::dateProtoFuncToISOString): + Change the way we use snprintf() for clarity and performance. + + Instead of allocating one extra byte to put a zero "just in case", we use the size returned + by snprintf(). + To prevent any overflow from a programming mistake, we explicitely test for overflow and + return an empty string. + + (JSC::dateProtoFuncToJSON): + * runtime/Error.cpp: + (JSC::createNotEnoughArgumentsError): + (JSC::throwTypeError): + (JSC::throwSyntaxError): + * runtime/Error.h: + (JSC::StrictModeTypeErrorFunction::create): + * runtime/ErrorPrototype.cpp: + (JSC::ErrorPrototype::finishCreation): + (JSC::errorProtoFuncToString): + Using a null String is correct because (8) uses jsString(), (9) tests for a length of 0. + + * runtime/ExceptionHelpers.cpp: + (JSC::InterruptedExecutionError::defaultValue): + (JSC::TerminatedExecutionError::defaultValue): + (JSC::createStackOverflowError): + (JSC::createOutOfMemoryError): + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + (JSC::FunctionExecutable::paramString): + * runtime/FunctionConstructor.cpp: + (JSC::constructFunction): + (JSC::constructFunctionSkippingEvalEnabledCheck): + * runtime/FunctionPrototype.h: + (JSC::FunctionPrototype::create): + Using a null String for the name is correct because InternalFunction uses jsString() + to create the name value. + + * runtime/InternalFunction.cpp: + (JSC::InternalFunction::finishCreation): + There is no need to create an empty string for a null string, jsString() handle both + cases as empty JSString. + + * runtime/JSArray.cpp: + (JSC::reject): + (JSC::SparseArrayValueMap::put): + (JSC::JSArray::put): + (JSC::JSArray::putByIndexBeyondVectorLength): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + (JSC::JSArray::setLength): + (JSC::JSArray::pop): + (JSC::JSArray::push): + * runtime/JSFunction.cpp: + (JSC::JSFunction::finishCreation): Same issue as InternalFunction::finishCreation. + + (JSC::JSFunction::callerGetter): + (JSC::JSFunction::defineOwnProperty): + * runtime/JSGlobalData.cpp: + (JSC::enableAssembler): Use CFSTR() instead of CFStringCreateWithCString(). + CFStringCreateWithCString() copy the content and may choose to decode the data. + CFSTR() is much more efficient. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + JSFunction uses jsString() to create the name, we can use null strings instead + of creating empty strings. + + (JSC::JSGlobalObject::createThrowTypeError): ditto. + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::encode): + (JSC::decode): + (JSC::globalFuncEval): + * runtime/JSONObject.cpp: + (JSC::Stringifier::appendStringifiedValue): + (JSC::Stringifier::Holder::appendNextProperty): + (JSC::JSONProtoFuncParse): + (JSC::JSONProtoFuncStringify): + * runtime/JSObject.cpp: + (JSC::JSObject::put): + (JSC::JSObject::defaultValue): + (JSC::JSObject::hasInstance): + (JSC::JSObject::defineOwnProperty): + * runtime/JSString.cpp: + Return an empty JSString to avoid the creation of a temporary empty String. + + (JSC::JSRopeString::getIndexSlowCase): + * runtime/JSString.h: + (JSC): Remove the versions of jsNontrivialString() taking a char*. All the callers + have been replaced by calls using ASCIILiteral. + + * runtime/JSValue.cpp: + (JSC::JSValue::putToPrimitive): + * runtime/LiteralParser.cpp: + (JSC::::Lexer::lex): + (JSC::::Lexer::lexString): + (JSC::::Lexer::lexNumber): + (JSC::::parse): + * runtime/LiteralParser.h: + (JSC::LiteralParser::getErrorMessage): + * runtime/NumberPrototype.cpp: + (JSC::numberProtoFuncToExponential): + (JSC::numberProtoFuncToFixed): + (JSC::numberProtoFuncToPrecision): + (JSC::numberProtoFuncToString): + * runtime/ObjectConstructor.cpp: + (JSC::objectConstructorGetPrototypeOf): + (JSC::objectConstructorGetOwnPropertyDescriptor): + (JSC::objectConstructorGetOwnPropertyNames): + (JSC::objectConstructorKeys): + (JSC::toPropertyDescriptor): + (JSC::objectConstructorDefineProperty): + (JSC::objectConstructorDefineProperties): + (JSC::objectConstructorCreate): + (JSC::objectConstructorSeal): + (JSC::objectConstructorFreeze): + (JSC::objectConstructorPreventExtensions): + (JSC::objectConstructorIsSealed): + (JSC::objectConstructorIsFrozen): + (JSC::objectConstructorIsExtensible): + * runtime/ObjectPrototype.cpp: + (JSC::objectProtoFuncDefineGetter): + (JSC::objectProtoFuncDefineSetter): + (JSC::objectProtoFuncToString): + * runtime/RegExpConstructor.cpp: + (JSC::constructRegExp): + * runtime/RegExpObject.cpp: + (JSC::reject): + (JSC::regExpObjectSource): + * runtime/RegExpPrototype.cpp: + (JSC::regExpProtoFuncCompile): + * runtime/StringObject.cpp: + (JSC::StringObject::defineOwnProperty): + * runtime/StringPrototype.cpp: + (JSC::jsSpliceSubstrings): + (JSC::jsSpliceSubstringsWithSeparators): + +2012-09-04 Filip Pizlo <fpizlo@apple.com> + + DFG GetByVal for JSArrays shouldn't OSR exit every time that the index is out of bound + https://bugs.webkit.org/show_bug.cgi?id=95717 + + Reviewed by Oliver Hunt. + + Make GetByVal for JSArrayOutOfBounds do meaningful things. The profiling was already + there so we should just use it! + + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-09-04 Zoltan Horvath <zoltan@webkit.org> + + Extend the coverage of the Custom Allocation Framework in WTF and in JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=95737 + + Reviewed by Eric Seidel. + + Add WTF_MAKE_FAST_ALLOCATED macro to the following class declarations because these are instantiated by operator new. + + * wtf/CryptographicallyRandomNumber.cpp: CryptographicallyRandomNumber is instantiated at wtf/CryptographicallyRandomNumber.cpp:162. + + * heap/MachineStackMarker.cpp: + (MachineThreads::Thread): Thread is instantiated at heap/MachineStackMarker.cpp:196. + * jit/ExecutableAllocatorFixedVMPool.cpp: + (FixedVMPoolExecutableAllocator): FixedVMPoolExecutableAllocator is instantiated at jit/ExecutableAllocatorFixedVMPool.cpp:111 + * parser/SourceProviderCache.h: + (SourceProviderCache): SourceProviderCache is instantiated at parser/SourceProvider.h:49. + * parser/SourceProviderCacheItem.h: + (SourceProviderCacheItem): SourceProviderCacheItem is instantiated at parser/Parser.cpp:843. + * runtime/GCActivityCallback.h: + (GCActivityCallback): GCActivityCallback is instantiated at runtime/GCActivityCallback.h:96. + * tools/CodeProfile.h: + (CodeProfile): CodeProfile is instantiated at JavaScriptCore/tools/CodeProfiling.cpp:140. + +2012-09-04 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove uses of ClassInfo from SpeculativeJIT::compileObjectOrOtherLogicalNot + https://bugs.webkit.org/show_bug.cgi?id=95510 + + Reviewed by Oliver Hunt. + + More refactoring to get rid of ClassInfo checks in the DFG. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + +2012-09-03 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for ENABLE(CLASSIC_INTERPRETER) after r127393. + + * interpreter/Interpreter.h: + +2012-09-02 Geoffrey Garen <ggaren@apple.com> + + Fixed failures seen on Linux bots. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_push_with_scope): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_push_with_scope): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: push_*_scope doesn't have a destination operand anymore. + Accordingly, update these places in the baseline JIT, which I missed in my last patch. + +2012-09-02 Geoffrey Garen <ggaren@apple.com> + + Refactored scope chain opcodes to support optimization for named function expressions + https://bugs.webkit.org/show_bug.cgi?id=95658 + + Reviewed by Sam Weinig. + + Renamed + push_scope => push_with_scope + push_new_scope => push_name_scope + to clarify the difference between them. + + Changed push_with_scope and push_name_scope not to save the new scope in + a temporary register, since doing so made optimization harder. + + (The old behavior was a hold-over from when the scope chain wasn't + a GC object, and wouldn't be marked otherwise. Now, the scope chain is + marked because it is a GC object pointed to by the call frame.) + + Changed push_name_scope to accept an operand specifying the attributes + for the named property, instead of assuming DontDelete, because a named + function expression needs ReadOnly|DontDelete. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::highestUsedRegister): Removed this function, + which used to be related to preserving saved scope object temporaries, + because it had no callers. + +2012-09-01 Geoffrey Garen <ggaren@apple.com> + + Rolled back out a piece of <http://trac.webkit.org/changeset/127293> + because it broke inspector tests on Windows. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + +2012-09-01 Mark Lam <mark.lam@apple.com> + + LLInt C loop backend. + https://bugs.webkit.org/show_bug.cgi?id=91052. + + Reviewed by Filip Pizlo. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::bytecodeOffset): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC): + * interpreter/Interpreter.h: + * jit/JITStubs.h: + (JITStackFrame): + (JSC): + * llint/LLIntCLoop.cpp: Added. + (JSC): + (LLInt): + (JSC::LLInt::CLoop::initialize): + (JSC::LLInt::CLoop::catchRoutineFor): + (JSC::LLInt::CLoop::hostCodeEntryFor): + (JSC::LLInt::CLoop::jsCodeEntryWithArityCheckFor): + (JSC::LLInt::CLoop::jsCodeEntryFor): + * llint/LLIntCLoop.h: Added. + (JSC): + (LLInt): + (CLoop): + * llint/LLIntData.cpp: + (JSC::LLInt::initialize): + * llint/LLIntData.h: + (JSC): + * llint/LLIntOfflineAsmConfig.h: + * llint/LLIntOpcode.h: + * llint/LLIntThunks.cpp: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter.cpp: + (LLInt): + (JSC::LLInt::Ints2Double): + (JSC): + (JSC::CLoop::execute): + * llint/LowLevelInterpreter.h: + (JSC): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/asm.rb: + * offlineasm/backends.rb: + * offlineasm/cloop.rb: Added. + * offlineasm/instructions.rb: + * runtime/Executable.h: + (ExecutableBase): + (JSC::ExecutableBase::hostCodeEntryFor): + (JSC::ExecutableBase::jsCodeEntryFor): + (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): + (JSC::ExecutableBase::catchRoutineFor): + (NativeExecutable): + * runtime/JSValue.h: + (JSC): + (LLInt): + (JSValue): + * runtime/JSValueInlineMethods.h: + (JSC): + (JSC::JSValue::JSValue): + * runtime/Options.cpp: + (JSC::Options::initialize): + +2012-09-01 Geoffrey Garen <ggaren@apple.com> + + Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * runtime/JSActivation.h: + (JSActivation): + +2012-09-01 Geoffrey Garen <ggaren@apple.com> + + Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC::JSGlobalObject::setGlobalThis): + (JSC): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSScope::globalThis): + (JSC): + (JSC::JSGlobalObject::globalThis): + * runtime/JSNameScope.h: + (JSC::JSNameScope::JSNameScope): + * runtime/JSScope.cpp: + (JSC::JSScope::visitChildren): + * runtime/JSScope.h: + (JSScope): + (JSC::JSScope::JSScope): + (JSC::JSScope::globalObject): + (JSC::JSScope::globalData): + * runtime/JSSegmentedVariableObject.h: + (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): + * runtime/JSSymbolTableObject.h: + (JSC::JSSymbolTableObject::JSSymbolTableObject): + * runtime/JSVariableObject.h: + (JSC::JSVariableObject::JSVariableObject): + * runtime/JSWithScope.h: + (JSC::JSWithScope::JSWithScope): + * runtime/StrictEvalActivation.cpp: + (JSC::StrictEvalActivation::StrictEvalActivation): + +2012-09-01 Geoffrey Garen <ggaren@apple.com> + + Rolled back out a piece of <http://trac.webkit.org/changeset/127293> + because it broke Window inspector tests. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * runtime/JSActivation.h: + (JSActivation): + +2012-08-31 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, attempt to fix Windows, take two. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-31 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, attempt to fix Windows. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-31 Filip Pizlo <fpizlo@apple.com> + + JSArray::putDirectIndex should by default behave like JSObject::putDirect + https://bugs.webkit.org/show_bug.cgi?id=95630 + + Reviewed by Gavin Barraclough. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jsc.cpp: + (GlobalObject::finishCreation): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * runtime/JSArray.cpp: + (JSC::SparseArrayValueMap::putDirect): + (JSC::JSArray::defineOwnNumericProperty): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + * runtime/JSArray.h: + (SparseArrayValueMap): + (JSArray): + (JSC::JSArray::putDirectIndex): + * runtime/JSONObject.cpp: + (JSC::Walker::walk): + * runtime/RegExpMatchesArray.cpp: + (JSC::RegExpMatchesArray::reifyAllProperties): + (JSC::RegExpMatchesArray::reifyMatchProperty): + * runtime/StringPrototype.cpp: + (JSC::splitStringByOneCharacterImpl): + (JSC::stringProtoFuncSplit): + +2012-08-31 Geoffrey Garen <ggaren@apple.com> + + Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSNameScope.h: + (JSC::JSNameScope::JSNameScope): + * runtime/JSWithScope.h: + (JSC::JSWithScope::JSWithScope): + * runtime/StrictEvalActivation.cpp: + (JSC::StrictEvalActivation::StrictEvalActivation): + +2012-08-31 Geoffrey Garen <ggaren@apple.com> + + Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_resolve_global_dynamic): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::withScopeStructure): + (JSC::JSGlobalObject::strictEvalActivationStructure): + (JSC::JSGlobalObject::activationStructure): + (JSC::JSGlobalObject::nameScopeStructure): + +2012-08-31 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove use of ClassInfo in SpeculativeJIT::emitBranch + https://bugs.webkit.org/show_bug.cgi?id=95623 + + Reviewed by Filip Pizlo. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + +2012-08-31 Geoffrey Garen <ggaren@apple.com> + + Rolled back in a piece of <http://trac.webkit.org/changeset/127293>. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::globalData): + (JSC): + * heap/WeakSet.cpp: + (JSC::WeakSet::addAllocator): + * heap/WeakSet.h: + (WeakSet): + (JSC::WeakSet::WeakSet): + (JSC::WeakSet::globalData): + * runtime/JSGlobalData.h: + (JSC::WeakSet::heap): + (JSC): + +2012-08-31 Mark Lam <mark.lam@apple.com> + + Refactor LLInt and supporting code in preparation for the C Loop backend. + https://bugs.webkit.org/show_bug.cgi?id=95531. + + Reviewed by Filip Pizlo. + + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFromLLInt): + * jit/JITExceptions.cpp: + (JSC::genericThrow): Use ExecutableBase::catchRoutineFor() to fetch + fetch the catch routine for a thrown exception. This will allow + us to redefine that for the C loop later, and still keep this + code readable. + * llint/LLIntOfflineAsmConfig.h: Moved ASM macros to + LowLevelInterpreter.cpp which is the only place they are used. This + will make it more convenient to redefine them for the C loop later. + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::setUpCall): Use ExecutableBase's hostCodeEntry() + jsCodeEntryFor(), and jsCodeWithArityCheckEntryFor() for computing + the entry points to functions being called. + * llint/LLIntSlowPaths.h: + (SlowPathReturnType): + (JSC::LLInt::encodeResult): + (LLInt): + (JSC::LLInt::decodeResult): Added. Needed by LLInt C Loop later. + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter.cpp: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/asm.rb: Disambiguate between opcodes and other labels. + * offlineasm/config.rb: + * runtime/Executable.h: + (JSC::ExecutableBase::hostCodeEntryFor): Added. + (ExecutableBase): + (JSC::ExecutableBase::jsCodeEntryFor): Added. + (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): Added. + (JSC::ExecutableBase::catchRoutineFor): Added. + * runtime/JSValueInlineMethods.h: + (JSC): + +2012-08-31 Tony Chang <tony@chromium.org> + + Remove ENABLE_CSS3_FLEXBOX compile time flag + https://bugs.webkit.org/show_bug.cgi?id=95382 + + Reviewed by Ojan Vafai. + + Everyone is already enabling this by default and the spec has stablized. + + * Configurations/FeatureDefines.xcconfig: + +2012-08-31 Geoffrey Garen <ggaren@apple.com> + + Not reviewed. + + Rolled out http://trac.webkit.org/changeset/127293 because it broke + inspector tests on Windows. + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + +2012-08-31 Geoffrey Garen <ggaren@apple.com> + + Shrink activation objects by half + https://bugs.webkit.org/show_bug.cgi?id=95591 + + Reviewed by Sam Weinig. + + Removed the global object, global data, and global this pointers from + JSScope, and changed an int to a bitfield. This gets the JSActivation + class down to 64 bytes, which in practice cuts it in half by getting it + out of the 128 byte size class. + + Now, it's one extra indirection to get these pointers. These pointers + aren't accessed by JIT code, so I thought there would be no cost to the + extra indirection. However, some C++-heavy SunSpider tests regressed a + bit in an early version of the patch, which added even more indirection. + This suggests that calls to exec->globalData() and/or exec->lexicalGlobalObject() + are common and probably duplicated in lots of places, and could stand + further optimization in C++. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): Test against the specific activation + for our global object, since there's no VM-shared activation structure + anymore. This is guaranteed to have the same success rate as the old test + because activation scope is fixed at compile time. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::globalData): + * heap/WeakSet.cpp: + (JSC::WeakSet::addAllocator): + * heap/WeakSet.h: + (WeakSet): + (JSC::WeakSet::WeakSet): + (JSC::WeakSet::globalData): Store a JSGlobalData* instead of a Heap* + because JSGlobalData->Heap is just a constant fold in the addressing + mode, while Heap->JSGlobalData is an extra pointer dereference. (These + objects should eventually just merge.) + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_resolve_global_dynamic): See DFGAbstractState.cpp. + + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Load the activation structure from + the code block instead of the global data because the structure is not + VM-shared anymore. (See DFGAbstractState.cpp.) + + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): + * runtime/JSActivation.h: + (JSActivation): This is the point of the patch: Remove the data. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): No longer VM-shared. (See DFGAbstractState.cpp.) + + (JSC::WeakSet::heap): (See WeakSet.h.) + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC::JSGlobalObject::setGlobalThis): + (JSC::JSGlobalObject::reset): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::withScopeStructure): + (JSC::JSGlobalObject::strictEvalActivationStructure): + (JSC::JSGlobalObject::activationStructure): + (JSC::JSGlobalObject::nameScopeStructure): + (JSC::JSScope::globalThis): + (JSC::JSGlobalObject::globalThis): Data that used to be in the JSScope + class goes here now, so it's not duplicated across all activations. + + * runtime/JSNameScope.h: + (JSC::JSNameScope::JSNameScope): + * runtime/JSScope.cpp: + (JSC::JSScope::visitChildren): This is the point of the patch: Remove the data. + + * runtime/JSScope.h: + (JSScope): + (JSC::JSScope::JSScope): + (JSC::JSScope::globalObject): + (JSC::JSScope::globalData): + * runtime/JSSegmentedVariableObject.h: + (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): + * runtime/JSSymbolTableObject.h: + (JSC::JSSymbolTableObject::JSSymbolTableObject): + * runtime/JSVariableObject.h: + (JSC::JSVariableObject::JSVariableObject): + * runtime/JSWithScope.h: + (JSC::JSWithScope::JSWithScope): + * runtime/StrictEvalActivation.cpp: + (JSC::StrictEvalActivation::StrictEvalActivation): Simplified now that + we don't need to pass so much data to JSScope. + +2012-08-31 Patrick Gansterer <paroga@webkit.org> + + Build fix for WinCE after r127191. + + * bytecode/JumpTable.h: + +2012-08-30 Filip Pizlo <fpizlo@apple.com> + + ASSERTION FAILURE in JSC::JSGlobalData::float32ArrayDescriptor when running fast/js/dfg-float64array.html + https://bugs.webkit.org/show_bug.cgi?id=95398 + + Reviewed by Mark Hahnenberg. + + Trying to get the build failure to be a bit more informative. + + * runtime/JSGlobalData.h: + (JSGlobalData): + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Qt build: add some #includes that, for some reason, only the Qt linker requires. + + * runtime/BooleanObject.cpp: + * runtime/ErrorInstance.cpp: + * runtime/NameInstance.cpp: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Fix the Qt build: Removed a now-dead variable. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + +2012-08-30 Benjamin Poulain <bpoulain@apple.com> + + Ambiguous operator[] after r127191 on some compiler + https://bugs.webkit.org/show_bug.cgi?id=95509 + + Reviewed by Simon Fraser. + + On some compilers, the operator[] conflicts with the Obj-C++ operators. This attempts to solve + the issue. + + * runtime/JSString.h: + (JSC::jsSingleCharacterSubstring): + (JSC::jsString): + (JSC::jsSubstring8): + (JSC::jsSubstring): + (JSC::jsOwnedString): + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Qt build: Remove the inline keyword at the declaration + site. + + The Qt compiler seems to be confused, complaining about these functions + not being defined in a translation unit, even though no generated code + in the unit calls these functions. Maybe removing the keyword at the + declaration site will change its mind. + + This shouldn't change the inlining decision at all: the definition is + still inline. + + * interpreter/CallFrame.h: + (ExecState): + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Undo Qt build fix guess, since it breaks other builds. + + * runtime/JSArray.h: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Qt build: add an #include to JSArray.h, since + it's included by some of the files Qt complains about, and + some of is functions call the functions Qt complains about. + + * runtime/JSArray.h: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Second step toward fixing the Windows build: Add new symbols. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Qt build: add an #include. + + * bytecode/GetByIdStatus.cpp: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + First step toward fixing the Windows build: Remove old symbols. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-30 Geoffrey Garen <ggaren@apple.com> + + Use one object instead of two for closures, eliminating ScopeChainNode + https://bugs.webkit.org/show_bug.cgi?id=95501 + + Reviewed by Filip Pizlo. + + This patch removes ScopeChainNode, and moves all the data and related + functions that used to be in ScopeChainNode into JSScope. + + Most of this patch is mechanical changes to use a JSScope* where we used + to use a ScopeChainNode*. I've only specifically commented about items + that were non-mechanical. + + * runtime/Completion.cpp: + (JSC::evaluate): + * runtime/Completion.h: Don't require an explicit scope chain argument + when evaluating code. Clients never wanted anything other than the + global scope, and other arbitrary scopes probably wouldn't work + correctly, anyway. + + * runtime/JSScope.cpp: + * runtime/JSScope.h: + (JSC::JSScope::JSScope): JSScope now requires the data we used to pass to + ScopeChainNode, so it can link itself into the scope chain correctly. + + * runtime/JSWithScope.h: + (JSC::JSWithScope::create): + (JSC::JSWithScope::JSWithScope): JSWithScope gets an extra constructor + for specifically supplying your own scope chain. The DOM needs this + interface for setting up the scope chain for certain event handlers. + Other clients always just push the JSWithScope to the head of the current + scope chain. + +2012-08-30 Mark Lam <mark.lam@apple.com> + + Render unto #ifdef's that which belong to them. + https://bugs.webkit.org/show_bug.cgi?id=95482. + + Reviewed by Filip Pizlo. + + Refining / disambiguating between #ifdefs and adding some. For + example, ENABLE(JIT) is conflated with ENABLE(LLINT) in some places. + Also, we need to add ENABLE(COMPUTED_GOTO_OPCODES) to indicate that we + want interpreted opcodes to use COMPUTED GOTOs apart from ENABLE(LLINT) + and ENABLE(COMPUTED_GOTO_CLASSIC_INTERPRETER). Also cleaned up #ifdefs + in certain places which were previously incorrect. + + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::CodeBlock::bytecodeOffset): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/Opcode.h: + (JSC::padOpcodeName): + * config.h: + * dfg/DFGOperations.cpp: + * interpreter/AbstractPC.cpp: + (JSC::AbstractPC::AbstractPC): + * interpreter/CallFrame.h: + (ExecState): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::~Interpreter): + (JSC::Interpreter::initialize): + (JSC::Interpreter::isOpcode): + (JSC::Interpreter::unwindCallFrame): + (JSC::getLineNumberForCallFrame): + (JSC::getCallerInfo): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::privateExecute): + * interpreter/Interpreter.h: + (JSC::Interpreter::getOpcode): + (JSC::Interpreter::getOpcodeID): + (Interpreter): + * jit/HostCallReturnValue.h: + * jit/JITCode.h: + (JITCode): + * jit/JITExceptions.cpp: + * jit/JITExceptions.h: + * jit/JSInterfaceJIT.h: + * llint/LLIntData.h: + (JSC::LLInt::getOpcode): + * llint/LLIntEntrypoints.cpp: + (JSC::LLInt::getFunctionEntrypoint): + (JSC::LLInt::getEvalEntrypoint): + (JSC::LLInt::getProgramEntrypoint): + * llint/LLIntOffsetsExtractor.cpp: + (JSC::LLIntOffsetsExtractor::dummy): + * llint/LLIntSlowPaths.cpp: + (LLInt): + * runtime/JSGlobalData.cpp: + (JSC): + +2012-08-30 JungJik Lee <jungjik.lee@samsung.com> + + [EFL][WK2] Add WebMemorySampler feature. + https://bugs.webkit.org/show_bug.cgi?id=91214 + + Reviewed by Kenneth Rohde Christiansen. + + WebMemorySampler collects Javascript stack and JIT memory usage in globalMemoryStatistics. + + * PlatformEfl.cmake: + +2012-08-30 Benjamin Poulain <bpoulain@apple.com> + + Replace JSC::UString by WTF::String + https://bugs.webkit.org/show_bug.cgi?id=95271 + + Reviewed by Geoffrey Garen. + + Having JSC::UString and WTF::String increase the complexity of working on WebKit, and + add useless conversions in the bindings. It also cause some code bloat. + + The performance advantages of UString have been ported over in previous patches. This patch + is the last step: getting rid of UString. + + In addition to the simplified code, this also reduce the binary size by 15kb on x86_64. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::ustring): + * runtime/Identifier.h: + (JSC::Identifier::ustring): + To avoid changing everything at once, the function named ustring() were kept as is. They + will be renamed in a follow up patch. + + * runtime/JSString.h: + (JSC::JSString::string): + (JSC::JSValue::toWTFString): + (JSC::inlineJSValueNotStringtoString): + (JSC::JSValue::toWTFStringInline): + Since JSValue::toString() already exist (and return the JSString), the direct accessor is renamed + to ::toWTFString(). We may change ::string() to ::jsString() and ::toWTFString() to ::toString() + in the future. + + * runtime/StringPrototype.cpp: + (JSC::substituteBackreferencesSlow): Replace the use of UString::getCharacters<>() by String::getCharactersWithUpconvert<>(). + +2012-08-24 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove uses of ClassInfo in StrictEq and CompareEq in the DFG + https://bugs.webkit.org/show_bug.cgi?id=93401 + + Reviewed by Filip Pizlo. + + Another incremental step in removing the dependence on ClassInfo pointers in object headers. + + * bytecode/SpeculatedType.h: + (JSC::isCellOrOtherSpeculation): + (JSC): + * dfg/DFGAbstractState.cpp: Updated the CFA to reflect the changes to the backend. + (JSC::DFG::AbstractState::execute): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::shouldSpeculateString): Added this new function since it was conspicuously absent. + (JSC::DFG::Node::shouldSpeculateNonStringCellOrOther): Also add this function for use in the CFA. + * dfg/DFGSpeculativeJIT.cpp: Refactored how we handle CompareEq and CompareStrictEq in the DFG. We now just + check for Strings by comparing the object's Structure to the global Structure for strings. We only + check for MasqueradesAsUndefined if the watchpoint has fired. These changes allow us to remove our + uses of the ClassInfo pointer for compiling these nodes. + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: Same changes for 32 bit as for 64 bit. + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + +2012-08-30 Yong Li <yoli@rim.com> + + [BlackBerry] Implement IncrementalSweeper for PLATFORM(BLACKBERRY) + https://bugs.webkit.org/show_bug.cgi?id=95469 + + Reviewed by Rob Buis. + + RIM PR# 200595. + Share most code with USE(CF) and implement timer-related methods + for PLATFORM(BLACKBERRY). + + * heap/IncrementalSweeper.cpp: + (JSC): + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::create): + (JSC::IncrementalSweeper::scheduleTimer): + (JSC::IncrementalSweeper::cancelTimer): + (JSC::IncrementalSweeper::doSweep): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + +2012-08-30 Mark Lam <mark.lam@apple.com> + + Fix broken classic intrpreter build. + https://bugs.webkit.org/show_bug.cgi?id=95484. + + Reviewed by Filip Pizlo. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + +2012-08-30 Byungwoo Lee <bw80.lee@samsung.com> + + Build warning : -Wsign-compare on DFGByteCodeParser.cpp. + https://bugs.webkit.org/show_bug.cgi?id=95418 + + Reviewed by Filip Pizlo. + + There is a build warning '-Wsign-compare' on + findArgumentPositionForLocal() in DFGByteCodeParser.cpp. + + For removing this warning, casting statement is added explicitly. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): + (JSC::DFG::ByteCodeParser::findArgumentPosition): + +2012-08-30 Yong Li <yoli@rim.com> + + [BlackBerry] Set timer client on platform timer used in HeapTimer + https://bugs.webkit.org/show_bug.cgi?id=95464 + + Reviewed by Rob Buis. + + Otherwise the timer won't work. + + * heap/HeapTimer.cpp: + (JSC::HeapTimer::HeapTimer): + +2012-08-30 Julien BRIANCEAU <jbrianceau@nds.com> + + [sh4] Add missing implementation for JavaScriptCore JIT + https://bugs.webkit.org/show_bug.cgi?id=95452 + + Reviewed by Oliver Hunt. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::isCompactPtrAlignedAddressOffset): + (MacroAssemblerSH4): + (JSC::MacroAssemblerSH4::add32): + (JSC::MacroAssemblerSH4::convertibleLoadPtr): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::labelIgnoringWatchpoints): + (SH4Assembler): + (JSC::SH4Assembler::replaceWithLoad): + (JSC::SH4Assembler::replaceWithAddressComputation): + +2012-08-30 Charles Wei <charles.wei@torchmobile.com.cn> + + [BlackBerry] Eliminate build warnings + https://bugs.webkit.org/show_bug.cgi?id=95338 + + Reviewed by Filip Pizlo. + + static_cast to the same type to eliminate the build time warnings. + + * assembler/AssemblerBufferWithConstantPool.h: + (JSC::AssemblerBufferWithConstantPool::flushWithoutBarrier): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::branch32): + +2012-08-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove use of ClassInfo from compileGetByValOnArguments and compileGetArgumentsLength + https://bugs.webkit.org/show_bug.cgi?id=95131 + + Reviewed by Filip Pizlo. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it + with an assert to guarantee this. + +2012-08-29 Mark Lam <mark.lam@apple.com> + + Refactoring LLInt::Data. + https://bugs.webkit.org/show_bug.cgi?id=95316. + + Reviewed by Geoff Garen. + + This change allows its opcodeMap to be easily queried from any function + without needing to go through a GlobalData object. It also introduces + the LLInt::getCodePtr() methods that will be used by the LLInt C loop + later to redefine how llint symbols (opcodes and trampoline glue + labels) get resolved. + + * assembler/MacroAssemblerCodeRef.h: + (MacroAssemblerCodePtr): + (JSC::MacroAssemblerCodePtr::createLLIntCodePtr): + (MacroAssemblerCodeRef): + (JSC::MacroAssemblerCodeRef::createLLIntCodeRef): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::adjustPCIfAtCallSite): + (JSC::CodeBlock::bytecodeOffset): + * bytecode/Opcode.h: + Remove the 'const' to simplify things and avoid having to do + additional casts and #ifdefs in many places. + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForLLInt): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::initialize): + * interpreter/Interpreter.h: + (Interpreter): + * jit/JITExceptions.cpp: + (JSC::genericThrow): + * llint/LLIntData.cpp: + (LLInt): + (JSC::LLInt::initialize): + * llint/LLIntData.h: + (JSC): + (LLInt): + (Data): + (JSC::LLInt::exceptionInstructions): + (JSC::LLInt::opcodeMap): + (JSC::LLInt::getOpcode): + (JSC::LLInt::getCodePtr): + (JSC::LLInt::Data::performAssertions): + * llint/LLIntExceptions.cpp: + (JSC::LLInt::returnToThrowForThrownException): + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::handleHostCall): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): Initialize the singleton LLInt data. + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): Removed the now unneeded LLInt::Data instance in + JSGlobalData. + * runtime/JSValue.h: + (JSValue): + +2012-08-29 Gavin Barraclough <barraclough@apple.com> + + PutById uses DataLabel32, not DataLabelCompact + https://bugs.webkit.org/show_bug.cgi?id=95245 + + Reviewed by Geoff Garen. + + JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now, + since they currently both do the same thing, but if we were to ever make compact mean + 8-bit this could be a real problem. Also, relying on the object still being in eax + on entry to the transition stub isn't very robust - added nonArgGPR1 to at least make + this explicit. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitSlow_op_put_by_id): + - copy regT0 to nonArgGPR1 + (JSC::JIT::privateCompilePutByIdTransition): + - DataLabelCompact -> DataLabel32 + (JSC::JIT::resetPatchPutById): + - reload regT0 from nonArgGPR1 + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + - added nonArgGPR1 + +2012-08-28 Yong Li <yoli@rim.com> + + ExecutableAllocator should be destructed after Heap + https://bugs.webkit.org/show_bug.cgi?id=95244 + + Reviewed by Rob Buis. + + RIM PR# 199364. + Make ExecutableAllocator the first member in JSGlobalData. + Existing Web Worker tests can show the issue. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + +2012-08-29 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Export! + +2012-08-28 Geoffrey Garen <ggaren@apple.com> + + Introduced JSWithScope, making all scope objects subclasses of JSScope + https://bugs.webkit.org/show_bug.cgi?id=95295 + + Reviewed by Filip Pizlo. + + This is a step toward removing ScopeChainNode. With a uniform representation + for objects in the scope chain, we can move data from ScopeChainNode + into JSScope. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: Build! + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): Use an explicit JSWithScope object + for 'with' statements. Since 'with' can put any object in the scope + chain, we'll need an adapter object to hold the data ScopeChainNode + currently holds. + + (JSGlobalData): Support for JSWithScope. + + * runtime/JSScope.cpp: + (JSC::JSScope::objectAtScope): + * runtime/JSScope.h: Check for and unwrap JSWithScope. + + * runtime/JSType.h: Support for JSWithScope. + + * runtime/StrictEvalActivation.cpp: + (JSC::StrictEvalActivation::StrictEvalActivation): + * runtime/StrictEvalActivation.h: + (StrictEvalActivation): Inherit from JSScope, to make the scope chain uniform. + + * runtime/JSWithScope.cpp: Added. + (JSC::JSWithScope::visitChildren): + * runtime/JSWithScope.h: Added. + (JSWithScope): + (JSC::JSWithScope::create): + (JSC::JSWithScope::object): + (JSC::JSWithScope::createStructure): + (JSC::JSWithScope::JSWithScope): New adapter object. Since this object + is never exposed to scripts, it doesn't need any meaningful implementation + of property access or other callbacks. + +2012-08-29 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for !ENABLE(JIT) after r126962. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + +2012-08-28 Geoffrey Garen <ggaren@apple.com> + + Added JSScope::objectInScope(), and refactored callers to use it + https://bugs.webkit.org/show_bug.cgi?id=95281 + + Reviewed by Gavin Barraclough. + + This is a step toward removing ScopeChainNode. We need a layer of + indirection so that 'with' scopes can proxy for an object. + JSScope::objectInScope() will be that layer. + + * bytecode/EvalCodeCache.h: + (JSC::EvalCodeCache::tryGet): + (JSC::EvalCodeCache::getSlow): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): . vs -> + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): + (JSC::Interpreter::execute): + * runtime/JSScope.cpp: + (JSC::JSScope::resolve): + (JSC::JSScope::resolveSkip): + (JSC::JSScope::resolveGlobalDynamic): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): Added JSScope::objectAtScope() calls. + + * runtime/JSScope.h: + (JSScope): + (JSC::JSScope::objectAtScope): + (JSC): + (ScopeChainIterator): + (JSC::ScopeChainIterator::ScopeChainIterator): + (JSC::ScopeChainIterator::get): + (JSC::ScopeChainIterator::operator->): + (JSC::ScopeChainIterator::operator++): + (JSC::ScopeChainIterator::operator==): + (JSC::ScopeChainIterator::operator!=): + (JSC::ScopeChainNode::begin): + (JSC::ScopeChainNode::end): I moved ScopeChainIterator to this file + to resolve a circular #include problem. Eventually, I'll probably rename + it to JSScope::iterator, so I think it belongs here. + + * runtime/ScopeChain.cpp: + (JSC::ScopeChainNode::print): + (JSC::ScopeChainNode::localDepth): . vs -> + + * runtime/ScopeChain.h: + (ScopeChainNode): I made the 'object' data member private because it's + no longer safe to access -- you need to call JSScope::objectAtScope() + instead. + + The JITs need to be friends because of the private declaration. + + Subtly, JIT/LLInt code is correct without any changes because JIT/LLInt + code never compiles direct access to a with scope. + +2012-08-28 Mark Lam <mark.lam@apple.com> + + Adding support for adding LLInt opcode extensions. This will be needed + by the LLInt C loop interpreter later. + https://bugs.webkit.org/show_bug.cgi?id=95277. + + Reviewed by Geoffrey Garen. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Opcode.h: + * llint/LLIntOpcode.h: Added. + * llint/LowLevelInterpreter.h: + +2012-08-28 Gavin Barraclough <barraclough@apple.com> + + Rolled out r126928, this broke stuff :'-( + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::resetPatchPutById): + +2012-08-28 Gavin Barraclough <barraclough@apple.com> + + PutById uses DataLabel32, not DataLabelCompact + https://bugs.webkit.org/show_bug.cgi?id=95245 + + Reviewed by Geoff Garen. + + JIT::resetPatchPutById calls the the wrong thing on x86-64 – this is moot right now, + since they currently both do the same thing, but if we were to ever make compact mean + 8-bit this could be a real problem. Also, don't rely on the object still being in eax + on entry to the transition stub – this isn't very robust. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + - DataLabelCompact -> DataLabel32 + (JSC::JIT::resetPatchPutById): + - reload regT0 from the stack + +2012-08-28 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r126914. + http://trac.webkit.org/changeset/126914 + https://bugs.webkit.org/show_bug.cgi?id=95239 + + it breaks everything and fixes nothing (Requested by pizlo on + #webkit). + + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnPropertyNames): + * API/JSClassRef.cpp: + (OpaqueJSClass::~OpaqueJSClass): + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::EvalCodeCache::visitAggregate): + (JSC::CodeBlock::nameForRegister): + * bytecode/JumpTable.h: + (JSC::StringJumpTable::offsetForValue): + (JSC::StringJumpTable::ctiForValue): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::getIfPresent): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::addVar): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::addConstantValue): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::emitLazyNewFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::PropertyListNode::emitBytecode): + * debugger/Debugger.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): + * dfg/DFGByteCodeCache.h: + (JSC::DFG::ByteCodeCache::~ByteCodeCache): + (JSC::DFG::ByteCodeCache::get): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + * heap/Heap.cpp: + (JSC::Heap::markProtectedObjects): + * heap/Heap.h: + (JSC::Heap::forEachProtectedCell): + * heap/JITStubRoutineSet.cpp: + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + * heap/MarkStack.cpp: + (JSC::MarkStack::internalAppend): + * heap/Weak.h: + (JSC::weakRemove): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITStubs.cpp: + (JSC::JITThunks::ctiStub): + * parser/Parser.cpp: + (JSC::::parseStrictObjectLiteral): + * profiler/Profile.cpp: + (JSC::functionNameCountPairComparator): + (JSC::Profile::debugPrintDataSampleStyle): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSArray.cpp: + (JSC::SparseArrayValueMap::put): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayValueMap::visitChildren): + (JSC::JSArray::enterDictionaryMode): + (JSC::JSArray::defineOwnNumericProperty): + (JSC::JSArray::getOwnPropertySlotByIndex): + (JSC::JSArray::getOwnPropertyDescriptor): + (JSC::JSArray::putByIndexBeyondVectorLength): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + (JSC::JSArray::deletePropertyByIndex): + (JSC::JSArray::getOwnPropertyNames): + (JSC::JSArray::setLength): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + (JSC::JSArray::checkConsistency): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::invalidateCode): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::set): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::sampleChild): + (JSC::ProfileTreeNode::childCount): + (JSC::ProfileTreeNode::dumpInternal): + (JSC::ProfileTreeNode::compareEntries): + +2012-08-28 Filip Pizlo <fpizlo@apple.com> + + LLInt should not rely on ordering of global labels + https://bugs.webkit.org/show_bug.cgi?id=95221 + + Reviewed by Oliver Hunt. + + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-08-28 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> + + Rename first/second to key/value in HashMap iterators + https://bugs.webkit.org/show_bug.cgi?id=82784 + + Reviewed by Eric Seidel. + + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnPropertyNames): + * API/JSClassRef.cpp: + (OpaqueJSClass::~OpaqueJSClass): + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::EvalCodeCache::visitAggregate): + (JSC::CodeBlock::nameForRegister): + * bytecode/JumpTable.h: + (JSC::StringJumpTable::offsetForValue): + (JSC::StringJumpTable::ctiForValue): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::getIfPresent): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::addVar): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::addConstantValue): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::emitLazyNewFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::PropertyListNode::emitBytecode): + * debugger/Debugger.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): + * dfg/DFGByteCodeCache.h: + (JSC::DFG::ByteCodeCache::~ByteCodeCache): + (JSC::DFG::ByteCodeCache::get): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + * heap/Heap.cpp: + (JSC::Heap::markProtectedObjects): + * heap/Heap.h: + (JSC::Heap::forEachProtectedCell): + * heap/JITStubRoutineSet.cpp: + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + * heap/MarkStack.cpp: + (JSC::MarkStack::internalAppend): + * heap/Weak.h: + (JSC::weakRemove): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITStubs.cpp: + (JSC::JITThunks::ctiStub): + * parser/Parser.cpp: + (JSC::::parseStrictObjectLiteral): + * profiler/Profile.cpp: + (JSC::functionNameCountPairComparator): + (JSC::Profile::debugPrintDataSampleStyle): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSArray.cpp: + (JSC::SparseArrayValueMap::put): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayValueMap::visitChildren): + (JSC::JSArray::enterDictionaryMode): + (JSC::JSArray::defineOwnNumericProperty): + (JSC::JSArray::getOwnPropertySlotByIndex): + (JSC::JSArray::getOwnPropertyDescriptor): + (JSC::JSArray::putByIndexBeyondVectorLength): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + (JSC::JSArray::deletePropertyByIndex): + (JSC::JSArray::getOwnPropertyNames): + (JSC::JSArray::setLength): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + (JSC::JSArray::checkConsistency): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::invalidateCode): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::set): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::sampleChild): + (JSC::ProfileTreeNode::childCount): + (JSC::ProfileTreeNode::dumpInternal): + (JSC::ProfileTreeNode::compareEntries): + +2012-08-28 Geoffrey Garen <ggaren@apple.com> + + GCC warning in JSActivation is causing Mac EWS errors + https://bugs.webkit.org/show_bug.cgi?id=95103 + + Reviewed by Sam Weinig. + + Try to fix a strict aliasing violation by using bitwise_cast. The + union in the cast should signal to the compiler that aliasing between + types is happening. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::visitChildren): + +2012-08-28 Geoffrey Garen <ggaren@apple.com> + + Build fix: svn add two files I forgot in my last patch. + +2012-08-27 Geoffrey Garen <ggaren@apple.com> + + Refactored and consolidated variable resolution functions + https://bugs.webkit.org/show_bug.cgi?id=95166 + + Reviewed by Filip Pizlo. + + This patch does a few things: + + (1) Introduces a new class, JSScope, which is the base class for all + objects that represent a scope in the scope chain. + + (2) Refactors and consolidates duplicate implementations of variable + resolution into the JSScope class. + + (3) Renames JSStaticScopeObject to JSNameScope because, as distinct from + something like a 'let' scope, JSStaticScopeObject only has storage for a + single name. + + These changes makes logical sense to me as-is. I will also use them in an + upcoming optimization. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: Build! + + * bytecode/CodeBlock.cpp: + (JSC): Build fix for LLInt-only builds. + + * bytecode/GlobalResolveInfo.h: + (GlobalResolveInfo): Use PropertyOffset to be consistent with other parts + of the engine. + + * bytecompiler/NodesCodegen.cpp: + * dfg/DFGOperations.cpp: Use the shared code in JSScope instead of rolling + our own. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + (JSC::Interpreter::createExceptionScope): + (JSC::Interpreter::privateExecute): + * interpreter/Interpreter.h: Use the shared code in JSScope instead of rolling + our own. + + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): Use the shared code in JSScope instead of rolling + our own. + + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (LLInt): Use the shared code in JSScope instead of rolling our own. Note + that one of these slow paths calls the wrong helper function. I left it + that way to avoid a behavior change in a refactoring patch. + + * parser/Nodes.cpp: Updated for rename. + + * runtime/CommonSlowPaths.h: + (CommonSlowPaths): Removed resolve slow paths because were duplicative. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): Updated for renames. + + * runtime/JSNameScope.cpp: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.cpp. + (JSC): + (JSC::JSNameScope::visitChildren): + (JSC::JSNameScope::toThisObject): + (JSC::JSNameScope::put): + (JSC::JSNameScope::getOwnPropertySlot): + * runtime/JSNameScope.h: Copied from Source/JavaScriptCore/runtime/JSStaticScopeObject.h. + (JSC): + (JSC::JSNameScope::create): + (JSC::JSNameScope::createStructure): + (JSNameScope): + (JSC::JSNameScope::JSNameScope): + (JSC::JSNameScope::isDynamicScope): Used do-webcore-rename script here. + It is fabulous! + + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::isNameScopeObject): More rename. + + * runtime/JSScope.cpp: Added. + (JSC): + (JSC::JSScope::isDynamicScope): + (JSC::JSScope::resolve): + (JSC::JSScope::resolveSkip): + (JSC::JSScope::resolveGlobal): + (JSC::JSScope::resolveGlobalDynamic): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + * runtime/JSScope.h: Added. + (JSC): + (JSScope): + (JSC::JSScope::JSScope): All the code here is a port from the + Interpreter.cpp implementations of this functionality. + + * runtime/JSStaticScopeObject.cpp: Removed. + * runtime/JSStaticScopeObject.h: Removed. + + * runtime/JSSymbolTableObject.cpp: + (JSC): + * runtime/JSSymbolTableObject.h: + (JSSymbolTableObject): + * runtime/JSType.h: Updated for rename. + + * runtime/Operations.h: + (JSC::resolveBase): Removed because it was duplicative. + +2012-08-28 Alban Browaeys <prahal@yahoo.com> + + [GTK] LLint build fails with -g -02 + https://bugs.webkit.org/show_bug.cgi?id=90098 + + Reviewed by Filip Pizlo. + + Avoid duplicate offsets for llint, discarding them. + + * offlineasm/offsets.rb: + +2012-08-27 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r126836. + http://trac.webkit.org/changeset/126836 + https://bugs.webkit.org/show_bug.cgi?id=95163 + + Broke all Apple ports, EFL, and Qt. (Requested by tkent on + #webkit). + + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnPropertyNames): + * API/JSClassRef.cpp: + (OpaqueJSClass::~OpaqueJSClass): + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::EvalCodeCache::visitAggregate): + (JSC::CodeBlock::nameForRegister): + * bytecode/JumpTable.h: + (JSC::StringJumpTable::offsetForValue): + (JSC::StringJumpTable::ctiForValue): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::getIfPresent): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::addVar): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::addConstantValue): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::emitLazyNewFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::PropertyListNode::emitBytecode): + * debugger/Debugger.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): + * dfg/DFGByteCodeCache.h: + (JSC::DFG::ByteCodeCache::~ByteCodeCache): + (JSC::DFG::ByteCodeCache::get): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + * heap/Heap.cpp: + (JSC::Heap::markProtectedObjects): + * heap/Heap.h: + (JSC::Heap::forEachProtectedCell): + * heap/JITStubRoutineSet.cpp: + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + * heap/MarkStack.cpp: + (JSC::MarkStack::internalAppend): + * heap/Weak.h: + (JSC::weakRemove): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITStubs.cpp: + (JSC::JITThunks::ctiStub): + * parser/Parser.cpp: + (JSC::::parseStrictObjectLiteral): + * profiler/Profile.cpp: + (JSC::functionNameCountPairComparator): + (JSC::Profile::debugPrintDataSampleStyle): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSArray.cpp: + (JSC::SparseArrayValueMap::put): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayValueMap::visitChildren): + (JSC::JSArray::enterDictionaryMode): + (JSC::JSArray::defineOwnNumericProperty): + (JSC::JSArray::getOwnPropertySlotByIndex): + (JSC::JSArray::getOwnPropertyDescriptor): + (JSC::JSArray::putByIndexBeyondVectorLength): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + (JSC::JSArray::deletePropertyByIndex): + (JSC::JSArray::getOwnPropertyNames): + (JSC::JSArray::setLength): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + (JSC::JSArray::checkConsistency): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::invalidateCode): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::set): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::sampleChild): + (JSC::ProfileTreeNode::childCount): + (JSC::ProfileTreeNode::dumpInternal): + (JSC::ProfileTreeNode::compareEntries): + +2012-08-27 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> + + Rename first/second to key/value in HashMap iterators + https://bugs.webkit.org/show_bug.cgi?id=82784 + + Reviewed by Eric Seidel. + + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnPropertyNames): + * API/JSClassRef.cpp: + (OpaqueJSClass::~OpaqueJSClass): + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::EvalCodeCache::visitAggregate): + (JSC::CodeBlock::nameForRegister): + * bytecode/JumpTable.h: + (JSC::StringJumpTable::offsetForValue): + (JSC::StringJumpTable::ctiForValue): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::getIfPresent): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::addVar): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::addConstantValue): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::emitLazyNewFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::PropertyListNode::emitBytecode): + * debugger/Debugger.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): + * dfg/DFGByteCodeCache.h: + (JSC::DFG::ByteCodeCache::~ByteCodeCache): + (JSC::DFG::ByteCodeCache::get): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + * heap/Heap.cpp: + (JSC::Heap::markProtectedObjects): + * heap/Heap.h: + (JSC::Heap::forEachProtectedCell): + * heap/JITStubRoutineSet.cpp: + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + * heap/MarkStack.cpp: + (JSC::MarkStack::internalAppend): + * heap/Weak.h: + (JSC::weakRemove): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITStubs.cpp: + (JSC::JITThunks::ctiStub): + * parser/Parser.cpp: + (JSC::::parseStrictObjectLiteral): + * profiler/Profile.cpp: + (JSC::functionNameCountPairComparator): + (JSC::Profile::debugPrintDataSampleStyle): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSArray.cpp: + (JSC::SparseArrayValueMap::put): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayValueMap::visitChildren): + (JSC::JSArray::enterDictionaryMode): + (JSC::JSArray::defineOwnNumericProperty): + (JSC::JSArray::getOwnPropertySlotByIndex): + (JSC::JSArray::getOwnPropertyDescriptor): + (JSC::JSArray::putByIndexBeyondVectorLength): + (JSC::JSArray::putDirectIndexBeyondVectorLength): + (JSC::JSArray::deletePropertyByIndex): + (JSC::JSArray::getOwnPropertyNames): + (JSC::JSArray::setLength): + (JSC::JSArray::sort): + (JSC::JSArray::compactForSorting): + (JSC::JSArray::checkConsistency): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::invalidateCode): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::set): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::sampleChild): + (JSC::ProfileTreeNode::childCount): + (JSC::ProfileTreeNode::dumpInternal): + (JSC::ProfileTreeNode::compareEntries): + +2012-08-27 Filip Pizlo <fpizlo@apple.com> + + Structure check hoisting should abstain if the OSR entry's must-handle value for the respective variable has a different structure + https://bugs.webkit.org/show_bug.cgi?id=95141 + <rdar://problem/12170401> + + Reviewed by Mark Hahnenberg. + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-27 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove use of ClassInfo from SpeculativeJIT::compileGetByValOnArguments + https://bugs.webkit.org/show_bug.cgi?id=95131 + + Reviewed by Filip Pizlo. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): We don't need this speculation check. We can replace it + with an assert to guarantee this. + +2012-08-27 Oliver Hunt <oliver@apple.com> + + Remove opcode definition autogen for now + https://bugs.webkit.org/show_bug.cgi?id=95148 + + Reviewed by Mark Hahnenberg. + + This isn't worth doing at the moment. + + * DerivedSources.make: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/OpcodeDefinitions.h: Removed. + * bytecode/opcodes: Removed. + * opcode_definition_generator.py: Removed. + * opcode_generator.py: Removed. + * opcode_parser.py: Removed. + +2012-08-27 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove uses of TypedArray ClassInfo from SpeculativeJIT::checkArgumentTypes + https://bugs.webkit.org/show_bug.cgi?id=95112 + + Reviewed by Filip Pizlo. + + Removing these checks since we no longer need them. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + +2012-08-27 Benjamin Poulain <benjamin@webkit.org> + + Add ECMAScript Number to String conversion to WTF::String + https://bugs.webkit.org/show_bug.cgi?id=95016 + + Reviewed by Geoffrey Garen. + + Rename UString::number(double) to UString::numberToStringECMAScript(double) to + differenciate it from the fixed-width conversion performed by String::number(). + + * parser/ParserArena.h: + (JSC::IdentifierArena::makeNumericIdentifier): + * runtime/JSONObject.cpp: + (JSC::Stringifier::appendStringifiedValue): + * runtime/NumberPrototype.cpp: + (JSC::numberProtoFuncToExponential): + (JSC::numberProtoFuncToFixed): + (JSC::numberProtoFuncToPrecision): + (JSC::numberProtoFuncToString): + * runtime/NumericStrings.h: + (JSC::NumericStrings::add): + * runtime/UString.cpp: + (JSC::UString::numberToStringECMAScript): + * runtime/UString.h: + (UString): + +2012-08-27 Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com> + + Rename RegisterProtocolHandler API to NavigatorContentUtils + https://bugs.webkit.org/show_bug.cgi?id=94920 + + Reviewed by Adam Barth. + + ENABLE_REGISTER_PROTOCOL_HANDLER is renamed to ENABLE_NAVIGATOR_CONTENT_UTILS. + + * Configurations/FeatureDefines.xcconfig: + +2012-08-26 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix for builds without VALUE_PROFILING. I had forgotten that shouldEmitProfiling() + is designed to return true if DFG_JIT is disabled. I should be using canBeOptimized() instead. + + * jit/JITCall.cpp: + (JSC::JIT::compileOpCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileOpCall): + +2012-08-26 Geoffrey Garen <ggaren@apple.com> + + Don't allocate space for arguments and call frame if arguments aren't captured + https://bugs.webkit.org/show_bug.cgi?id=95024 + + Reviewed by Phil Pizlo. + + 27% on v8-real-earley. + + * runtime/JSActivation.h: + (JSC::JSActivation::registerOffset): The offset is zero if we're skipping + the arguments and call frame because "offset" means space reserved for + those things. + + (JSC::JSActivation::tearOff): Don't copy the scope chain and callee. We + don't need them for anything, and we're no longer guaranteed to have + space for them. + +2012-08-26 Geoffrey Garen <ggaren@apple.com> + + Removed the NULL checks from visitChildren functions + https://bugs.webkit.org/show_bug.cgi?id=95021 + + Reviewed by Oliver Hunt. + + As of http://trac.webkit.org/changeset/126624, all values are NULL-checked + during GC, so explicit NULL checks aren't needed anymore. + +2011-08-26 Geoffrey Garen <ggaren@apple.com> + + Removed a JSC-specific hack from the web inspector + https://bugs.webkit.org/show_bug.cgi?id=95033 + + Reviewed by Filip Pizlo. + + Added support for what the web inspector really wanted instead. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::symbolTableGet): + (JSC::JSActivation::symbolTablePut): Added some explanation for these + checks, which were non-obvious to me. + + (JSC::JSActivation::getOwnPropertySlot): It's impossible to access the + arguments property of an activation after it's been torn off, since the + only way to tear off an activation is to instantiate a new function, + which has its own arguments property in scope. However, the inspector + get special access to activations, and may try to perform this access, + so we need a special guard to maintain coherence and avoid crashing in + case the activation optimized out the arguments property. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::symbolTableGet): + (JSC::JSActivation::symbolTablePut): + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::getOwnPropertyDescriptor): Provide getOwnPropertyNames + and getOwnPropertyDescriptor implementations, to meet the web inspector's + needs. (User code can never call these.) + +2012-08-24 Filip Pizlo <fpizlo@apple.com> + + Finally inlining should correctly track the catch context + https://bugs.webkit.org/show_bug.cgi?id=94986 + <rdar://problem/11753784> + + Reviewed by Sam Weinig. + + This fixes two behaviors: + + 1) Throwing from a finally block. Previously, we would seem to reenter the finally + block - though only once. + + 2) Executing a finally block from some nested context, for example due to a + 'continue', 'break', or 'return' in the try. This would execute the finally + block in the context of of the try block, which could lead to either scope depth + mismatches or reexecutions of the finally block on throw, similarly to (1) but + for different reasons. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC): + (JSC::BytecodeGenerator::pushFinallyContext): + (JSC::BytecodeGenerator::emitComplexJumpScopes): + (JSC::BytecodeGenerator::pushTry): + (JSC::BytecodeGenerator::popTryAndEmitCatch): + * bytecompiler/BytecodeGenerator.h: + (FinallyContext): + (TryData): + (JSC): + (TryContext): + (TryRange): + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::TryNode::emitBytecode): + +2012-08-26 Filip Pizlo <fpizlo@apple.com> + + Array type checks and storage accesses should be uniformly represented and available to CSE + https://bugs.webkit.org/show_bug.cgi?id=95013 + + Reviewed by Oliver Hunt. + + This uniformly breaks up all array accesses into up to three parts: + + 1) The type check, using a newly introduced CheckArray node, in addition to possibly + a CheckStructure node. We were already inserting the CheckStructure prior to this + patch. The CheckArray node will be automatically eliminated if the thing it was + checking for had already been checked for, either intentionally (a CheckStructure + inserted based on the array profile of this access) or accidentally (some checks, + typically a CheckStructure, inserted for some unrelated operations). The + CheckArray node may not be inserted if the array type is non-specific (Generic or + ForceExit). + + 2) The storage load using GetIndexedPropertyStorage. Previously, this only worked for + GetByVal. Now it works for all array accesses. The storage load may not be + inserted if the mode of array access does not permit CSE of storage loads (like + non-specific modes or Arguments). + + 3) The access itself: one of GetByVal, PutByVal, PutByValAlias, ArrayPush, ArrayPop, + GetArrayLength, StringCharAt, or StringCharCodeAt. + + This means that the type check can be subjected to CSE even if the CFA isn't smart + enough to reason about it (yet!). It also means that the storage load can always be + subjected to CSE; previously CSE on storage load only worked for array loads and not + other forms of access. Finally, it removes the bizarre behavior that + GetIndexedPropertyStorage previously had: previously, it was responsible for the type + check in some cases, but not others; this made reasoning about the CFA really + confusing. + + This change also disables late refinement of array mode, since I decided that + supporting that feature is both confusing and likely unprofitable. The array modes are + now locked in in the first fixup run after prediction propagation. Of course, + refinements from Generic to something else would not have been a problem; we could + reenable those if we thought we really needed to. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromStructure): + (DFG): + (JSC::DFG::refineArrayMode): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::modeIsJSArray): + (JSC::DFG::lengthNeedsStorage): + (JSC::DFG::modeIsSpecific): + (JSC::DFG::modeSupportsLength): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::ByteCodeParser): + (JSC::DFG::ByteCodeParser::getArrayMode): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (JSC::DFG::CSEPhase::checkStructureElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + (JSC::DFG::performCSE): + * dfg/DFGCSEPhase.h: + (DFG): + * dfg/DFGCommon.h: + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (FixupPhase): + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + (DFG): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::collectGarbage): + * dfg/DFGGraph.h: + (Graph): + (JSC::DFG::Graph::vote): + (JSC::DFG::Graph::substitute): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasArrayMode): + (JSC::DFG::Node::setArrayMode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGPhase.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::useChildren): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-26 Filip Pizlo <fpizlo@apple.com> + + DFGGraph.h has a bogus comment about the nature of StorageAccessData + https://bugs.webkit.org/show_bug.cgi?id=95035 + + Reviewed by Oliver Hunt. + + The comment is both wrong (storage access instructions don't reference CheckStructure) + and highly redundant: of course it's the case that two structures may have the same + identifier. Our interference analyses currently don't care about this and make the + conservative assumptions when necessary (same identifier, same object -> must be same + property; same identifier, may be same object -> may be the same property). Better to + remove the bogus comment since the code that operates over this data structure is + fairly self-explanatory already. + + * dfg/DFGGraph.h: + (StorageAccessData): + +2012-08-25 Geoffrey Garen <ggaren@apple.com> + + Try a little harder to fix the Linux build. + + * runtime/JSActivation.cpp: + * runtime/JSActivation.h: + +2012-08-25 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Linux build. + + * runtime/JSActivation.cpp: + +2012-08-25 Geoffrey Garen <ggaren@apple.com> + + Don't use malloc / destructors for activation objects + https://bugs.webkit.org/show_bug.cgi?id=94897 + + Reviewed by Oliver Hunt. + + 65% faster on v8-real-earley. + + Lots of boilerplate here, but the jist is this: + + (1) Use CopiedSpace instead of malloc to allocate the activation's + backing store. + + (2) Use MarkedSpace instead of ref-counting to allocate the symbol table. + + (3) ==> No more destructor. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::stronglyVisitStrongReferences): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::symbolTable): + (CodeBlock): + (JSC::GlobalCodeBlock::GlobalCodeBlock): + (JSC::FunctionCodeBlock::FunctionCodeBlock): + (FunctionCodeBlock): SymbolTable is a GC object now, so it gets a write + barrier and visit calls instead of ref-counting. I changed all CodeBlocks + to use shared symbol tables because the distinction between shared and + unshared hurt my head. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::emitPutStaticVar): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Sometimes, a period just wants + to be an arrow. And then C++ is there to accommodate. + + * jit/JITDriver.h: + (JSC::jitCompileFunctionIfAppropriate): + * runtime/Arguments.h: + (ArgumentsData): + (JSC::Arguments::setRegisters): + (Arguments): + (JSC::Arguments::argument): + (JSC::Arguments::finishCreation): + * runtime/Executable.cpp: + (JSC::FunctionExecutable::FunctionExecutable): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + (JSC::FunctionExecutable::visitChildren): + * runtime/Executable.h: + (JSC::FunctionExecutable::symbolTable): + (FunctionExecutable): + * runtime/ExecutionHarness.h: + (JSC::prepareFunctionForExecution): I changed from WriteBarrier to + WriteBarrierBase so activations could reuse StorageBarrier and PropertyStorage. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::JSActivation): + (JSC::JSActivation::finishCreation): Allocate the symbol table here, + after we're fully constructed, to avoid GC during initialization. + + (JSC::JSActivation::visitChildren): + (JSC::JSActivation::symbolTableGet): + (JSC::JSActivation::symbolTablePut): + (JSC::JSActivation::getOwnPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSActivation.h: + (JSC::JSActivation::create): + (JSActivation): + (JSC::JSActivation::registerOffset): + (JSC): + (JSC::JSActivation::registerArraySize): + (JSC::JSActivation::registerArraySizeInBytes): + (JSC::JSActivation::tearOff): Tear-off zero-initializes all uncopied + registers. This makes it safe to copyAndAppend the full buffer in + visitChildren, without any extra checks. + + * runtime/JSCell.h: + (JSCell): Moved a shared default set of flags into this base class, so + I could use it in a few places. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): New structure for symbol tables. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC::JSGlobalObject::addStaticGlobals): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::symbolTableHasProperty): We don't need an inline + symbol table -- JSSymbolTableObject will GC allocate one for us. + + * runtime/JSObject.h: + (JSObject): + * runtime/JSSegmentedVariableObject.h: + (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): + * runtime/JSStaticScopeObject.cpp: + (JSC): + (JSC::JSStaticScopeObject::visitChildren): NULL check our register store + because finishCreation allocates an object now, so we may get marked + before we've assigned to our register store. + + * runtime/JSStaticScopeObject.h: + (JSC::JSStaticScopeObject::finishCreation): + (JSC::JSStaticScopeObject::JSStaticScopeObject): + (JSStaticScopeObject): No more destructor for this object, either, since + it no longer embeds a hash table. + + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::visitChildren): + (JSC::JSSymbolTableObject::deleteProperty): + (JSC::JSSymbolTableObject::getOwnPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::JSSymbolTableObject::symbolTable): + (JSSymbolTableObject): + (JSC::JSSymbolTableObject::JSSymbolTableObject): + (JSC::JSSymbolTableObject::finishCreation): + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): SymbolTableObject allocates a symbol + table automatically if one isn't provided. (Activations provide their + own, which they get from compiled code.) + + * runtime/JSVariableObject.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSC::JSVariableObject::registerAt): + (JSC::JSVariableObject::addressOfRegisters): + (JSVariableObject): + (JSC::JSVariableObject::JSVariableObject): + (JSC::JSVariableObject::finishCreation): Removed a bunch of obsolete code. + Activations manage their registers directly now. + + * runtime/StorageBarrier.h: + (StorageBarrier): + (JSC::StorageBarrier::operator!): + + * runtime/SymbolTable.cpp: + (JSC): + (JSC::SharedSymbolTable::destroy): + * runtime/SymbolTable.h: + (JSC::SharedSymbolTable::create): + (SharedSymbolTable): + (JSC::SharedSymbolTable::createStructure): + (JSC::SharedSymbolTable::SharedSymbolTable): Boilerplat code to + make shared symbol table GC-allocated. + +2012-08-25 Filip Pizlo <fpizlo@apple.com> + + op_call should have ArrayProfiling for the benefit of array intrinsics + https://bugs.webkit.org/show_bug.cgi?id=95014 + + Reviewed by Sam Weinig. + + This is a performance-neutral change that just adds the profiling but does not + use it, yet. If in the future we wanted to make this kind of profiling cheaper + we could move it into specialized thunks for the relevant array intrinsics, but + I figure that if this much simpler change gives us what we need without any + discernable performance penalty then that's for the best. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitCall): + * jit/JITCall.cpp: + (JSC::JIT::compileOpCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileOpCall): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-08-25 Filip Pizlo <fpizlo@apple.com> + + The redundant phi elimination phase is not used and should be removed + https://bugs.webkit.org/show_bug.cgi?id=95006 + + Reviewed by Dan Bernstein. + + Just removing dead code. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGDriver.cpp: + * dfg/DFGRedundantPhiEliminationPhase.cpp: Removed. + * dfg/DFGRedundantPhiEliminationPhase.h: Removed. + +2012-08-24 Benjamin Poulain <bpoulain@apple.com> + + Unify Number to StringImpl conversion + https://bugs.webkit.org/show_bug.cgi?id=94879 + + Reviewed by Geoffrey Garen. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * runtime/UString.cpp: + * runtime/UString.h: + (JSC::UString::number): + Update UString to directly use the common NumberToString implementation. + +2012-08-24 Oliver Hunt <oliver@apple.com> + + Always null check cells before marking + https://bugs.webkit.org/show_bug.cgi?id=94968 + + Reviewed by Geoffrey Garen. + + Originally we tried to minimise null checks by only null checking values + that we knew could be null, however given that we can't ever guarantee + when a GC will happen, we're better off just always assuming that a null + check will be necessary. This results in a much less fragile code base + as we can add GC allocations to object initialisers without having to + subsequently worry about whether the object we are initialising will need + to add a bunch of null checks in its visitChildren implementation. + + * heap/MarkStack.cpp: + (JSC::MarkStack::internalAppend): + * heap/MarkStackInlineMethods.h: + (JSC::MarkStack::append): + (JSC::MarkStack::appendUnbarrieredPointer): + * runtime/Structure.h: + (JSC::MarkStack::internalAppend): + +2012-08-23 Oliver Hunt <oliver@apple.com> + + Autogenerate Opcode definitions + https://bugs.webkit.org/show_bug.cgi?id=94840 + + Reviewed by Gavin Barraclough. + + Start the process of autogenerating the code emission for the bytecode. + We'll just start with automatic generation of the list of Opcodes as that + requires the actual definition of the opcodes, and the logic for parsing + them. + + Due to some rather annoying dependency cycles, this initial version has + the OpcodeDefinitions.h file checked into the tree, although with some + work I hope to be able to fix that. + + * DerivedSources.make: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Opcode.h: + Include OpcodeDefinitions.h as our definitive source of info + about the opcodes. + * bytecode/OpcodeDefinitions.h: Added. + Autogenerated file + * bytecode/opcodes: Added. + The new opcode definition file + * opcode_definition_generator.py: Added. + (generateOpcodeDefinition): + (generate): + Module that generates the content for OpcodeDefinitions.h + * opcode_generator.py: Added. + (printUsage): + (main): + Driver script + * opcode_parser.py: Added. + Simple parser for the opcode definitions. + +2011-08-23 Geoffrey Garen <ggaren@apple.com> + + Unreviewed, rolling out r126505. + http://trac.webkit.org/changeset/126505 + https://bugs.webkit.org/show_bug.cgi?id=94840 + + Caused testapi to crash on launch + + * DerivedSources.make: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/OpcodeDefinitions.h: Removed. + * bytecode/opcodes: Removed. + * opcode_definition_generator.py: Removed. + * opcode_generator.py: Removed. + * opcode_parser.py: Removed. + +2012-08-23 Oliver Hunt <oliver@apple.com> + + Autogenerate Opcode definitions + https://bugs.webkit.org/show_bug.cgi?id=94840 + + Reviewed by Gavin Barraclough. + + Start the process of autogenerating the code emission for the bytecode. + We'll just start with automatic generation of the list of Opcodes as that + requires the actual definition of the opcodes, and the logic for parsing + them. + + Due to some rather annoying dependency cycles, this initial version has + the OpcodeDefinitions.h file checked into the tree, although with some + work I hope to be able to fix that. + + * DerivedSources.make: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Opcode.h: + Include OpcodeDefinitions.h as our definitive source of info + about the opcodes. + * bytecode/OpcodeDefinitions.h: Added. + Autogenerated file + * bytecode/opcodes: Added. + The new opcode definition file + * opcode_definition_generator.py: Added. + (generateOpcodeDefinition): + (generate): + Module that generates the content for OpcodeDefinitions.h + * opcode_generator.py: Added. + (printUsage): + (main): + Driver script + * opcode_parser.py: Added. + Simple parser for the opcode definitions. + +2012-08-23 Mark Hahnenberg <mhahnenberg@apple.com> + + Change behavior of MasqueradesAsUndefined to better accommodate DFG changes + https://bugs.webkit.org/show_bug.cgi?id=93884 + + Reviewed by Filip Pizlo. + + With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of + MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines, + we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined + objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject). + For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not + masquerade as undefined within frame B, but it will continue to masquerade in frame A. + + There are two primary changes that are taking place here. One is to thread the ExecState* through + JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's + JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two + are distinct, then the object cannot MasqueradeAsUndefined. + + The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined + flag in the Structure is checked. For C++ code, this check has been factored into its own function in + Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has + had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed + through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers + that are MasqueradesAsUndefined. + + * API/JSValueRef.cpp: + (JSValueToBoolean): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * bytecode/Watchpoint.h: + (WatchpointSet): + * debugger/DebuggerCallFrame.h: + (JSC::DebuggerCallFrame::callFrame): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncFilter): + (JSC::arrayProtoFuncEvery): + (JSC::arrayProtoFuncSome): + * runtime/BooleanConstructor.cpp: + (JSC::constructBoolean): + (JSC::callBooleanConstructor): + * runtime/JSCell.h: + (JSCell): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint): + * runtime/JSString.h: + (JSC::JSCell::toBoolean): + (JSC::JSValue::toBoolean): + * runtime/JSValue.h: + * runtime/ObjectConstructor.cpp: + (JSC::toPropertyDescriptor): + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC::jsIsObjectType): + * runtime/Operations.h: + (JSC): + (JSC::JSValue::equalSlowCaseInline): + * runtime/RegExpConstructor.cpp: + (JSC::setRegExpConstructorMultiline): + * runtime/RegExpPrototype.cpp: + (JSC::regExpProtoFuncToString): + * runtime/Structure.h: + (Structure): + (JSC::Structure::globalObjectOffset): + (JSC::Structure::masqueradesAsUndefined): + (JSC): + +2012-08-23 Mark Rowe <mrowe@apple.com> + + Make JavaScriptCore build with the latest version of clang. + + Reviewed by Dan Bernstein. + + * heap/MachineStackMarker.cpp: + (JSC::MachineThreads::MachineThreads): The m_heap member is only used within + assertions, so guard its initialization with !ASSERT_DISABLED. + * heap/MachineStackMarker.h: + (MachineThreads): Ditto for its declaration. + * jit/JITStubCall.h: + (JSC::JITStubCall::JITStubCall): The m_returnType member is only used within + assertions or if we're using JSVALUE32_64, so guard its uses with the appropriate + #if. + (JITStubCall): Ditto. + +2012-08-23 Christophe Dumez <christophe.dumez@intel.com> + + Serialization of JavaScript values does not appear to respect new HTML5 Structured Clone semantics + https://bugs.webkit.org/show_bug.cgi?id=65292 + + Reviewed by Oliver Hunt. + + Add function to construct a StringObject from a JSValue. + Similar functions already exist for NumberObject and + BooleanObject for example. + + Export several symbols so address linking errors in + WebCore. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * runtime/BooleanObject.h: + (BooleanObject): + * runtime/NumberObject.h: + (NumberObject): + (JSC): + * runtime/StringObject.cpp: + (JSC::constructString): + (JSC): + * runtime/StringObject.h: + (JSC): + +2012-08-22 Filip Pizlo <fpizlo@apple.com> + + Array accesses should remember what kind of array they are predicted to access + https://bugs.webkit.org/show_bug.cgi?id=94448 + + Reviewed by Gavin Barraclough. + + Introduced the notion of DFG::Array::Mode, stored in node.arrayMode(), which allows nodes + to remember how they decided to access arrays. This permits the bytecode parser to "lock in" + the mode of access if it has profiling at its disposal, and it also allows the prediction + propagator to do a fixup of the array mode later in the optimization fixpoint. + + This patch adds a healthy amount of new capability (specifically the ability of the parser + to lock in an array mode regardless of type predictions) and it also blows away a lot of + messy code. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGArrayMode.cpp: Added. + (DFG): + (JSC::DFG::fromObserved): + (JSC::DFG::refineArrayMode): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: Added. + (DFG): + (JSC::DFG::canCSEStorage): + (JSC::DFG::modeForPut): + (JSC::DFG::modesCompatibleForStorageLoad): + (JSC::DFG::modeSupportsLength): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::getArrayModeWithoutOSRExit): + (JSC::DFG::ByteCodeParser::getArrayMode): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkStructureLoadElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + (JSC::DFG::CSEPhase::putByOffsetStoreElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasArrayMode): + (Node): + (JSC::DFG::Node::arrayMode): + (JSC::DFG::Node::setArrayMode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): + (DFG): + (JSC::DFG::SpeculativeJIT::speculateArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-22 Geoffrey Garen <ggaren@apple.com> + + ThreadRestrictionVerifier should be opt-in, not opt-out + https://bugs.webkit.org/show_bug.cgi?id=94761 + + Reviewed by Mark Hahnenberg. + + Removed explicit calls to disable the verifier, since it's off by default now. + + * parser/SourceProvider.h: + (JSC::SourceProvider::SourceProvider): + (SourceProvider): + * runtime/SymbolTable.h: + (JSC::SharedSymbolTable::SharedSymbolTable): + +2012-08-22 Mark Hahnenberg <mhahnenberg@apple.com> + + Separate MarkStackThreadSharedData from MarkStack + https://bugs.webkit.org/show_bug.cgi?id=94294 + + Reviewed by Filip Pizlo. + + MarkStackThreadSharedData is soon going to have data to allow for a parallel copying + mode too, so to separate our concerns we should split it out into its own set of files + and rename it to GCThreadSharedData. For now this is purely a cosmetic refactoring. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * heap/GCThreadSharedData.cpp: Added. + (JSC): + (JSC::GCThreadSharedData::resetChildren): + (JSC::GCThreadSharedData::childVisitCount): + (JSC::GCThreadSharedData::markingThreadMain): + (JSC::GCThreadSharedData::markingThreadStartFunc): + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::~GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + * heap/GCThreadSharedData.h: Added. + (JSC): + (GCThreadSharedData): + * heap/Heap.h: + (Heap): + * heap/ListableHandler.h: + (ListableHandler): + * heap/MarkStack.cpp: + (JSC::MarkStack::MarkStack): + (JSC::MarkStack::~MarkStack): + * heap/MarkStack.h: + (JSC): + (MarkStack): + (JSC::MarkStack::sharedData): + * heap/MarkStackInlineMethods.h: Added. + (JSC): + (JSC::MarkStack::append): + (JSC::MarkStack::appendUnbarrieredPointer): + (JSC::MarkStack::appendUnbarrieredValue): + (JSC::MarkStack::internalAppend): + (JSC::MarkStack::addWeakReferenceHarvester): + (JSC::MarkStack::addUnconditionalFinalizer): + (JSC::MarkStack::addOpaqueRoot): + (JSC::MarkStack::containsOpaqueRoot): + (JSC::MarkStack::opaqueRootCount): + * heap/SlotVisitor.h: + (JSC): + (SlotVisitor): + (JSC::SlotVisitor::SlotVisitor): + +2012-08-22 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Fix JSC build when DFG-JIT is disabled + https://bugs.webkit.org/show_bug.cgi?id=94694 + + Reviewed by Csaba Osztrogonác. + + Adding an appropriate guard for fixing the build. + + * bytecode/ResolveGlobalStatus.cpp: + (JSC): + +2012-08-21 Mark Lam <mark.lam@apple.com> + + Introducing the VMInspector for VM debugging use. + https://bugs.webkit.org/show_bug.cgi?id=94613. + + Reviewed by Filip Pizlo. + + Adding some utility functions for debugging the VM. This code is + presently #ifdef'd out by default. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * interpreter/CallFrame.h: + (ExecState): + * interpreter/VMInspector.cpp: Added. + (JSC): + (JSC::VMInspector::getTypeName): + (JSC::VMInspector::dumpFrame0): + (JSC::VMInspector::dumpFrame): + (JSC::VMInspector::countFrames): + * interpreter/VMInspector.h: Added. + (JSC): + (VMInspector): + +2012-08-21 Filip Pizlo <fpizlo@apple.com> + + A patchable GetById right after a watchpoint should have the appropriate nop padding + https://bugs.webkit.org/show_bug.cgi?id=94635 + + Reviewed by Mark Hahnenberg. + + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::padBeforePatch): + (AbstractMacroAssembler): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch): + (JSC::MacroAssemblerARMv7::moveWithPatch): + (JSC::MacroAssemblerARMv7::patchableJump): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::moveWithPatch): + (JSC::MacroAssemblerX86::branchPtrWithPatch): + (JSC::MacroAssemblerX86::storePtrWithPatch): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::load32WithAddressOffsetPatch): + (JSC::MacroAssemblerX86Common::load32WithCompactAddressOffsetPatch): + (JSC::MacroAssemblerX86Common::loadCompactWithAddressOffsetPatch): + (JSC::MacroAssemblerX86Common::store32WithAddressOffsetPatch): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::loadPtrWithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::loadPtrWithCompactAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::storePtrWithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::moveWithPatch): + * jit/JumpReplacementWatchpoint.cpp: + (JSC::JumpReplacementWatchpoint::fireInternal): + +2012-08-20 Mark Lam <mark.lam@apple.com> + + Fix broken non-JIT build. + https://bugs.webkit.org/show_bug.cgi?id=94564. + + Reviewed by Filip Pizlo. + + Added some UNUSED_PARAM() macros to make the compiler happy. + + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + +2012-08-20 Mark Lam <mark.lam@apple.com> + + Fixed erroneous line number for LLint frame when throwing exceptions. + https://bugs.webkit.org/show_bug.cgi?id=94051. + + Reviewed by Filip Pizlo. + + For LLInt frames, before throwing an exception, adjust the PC from the + return PC back to the call PC if we are indeed at a call site. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::adjustPCIfAtCallSite): + (JSC): + (JSC::CodeBlock::bytecodeOffset): + * bytecode/CodeBlock.h: + (CodeBlock): + * llint/LLIntExceptions.cpp: + (JSC::LLInt::fixupPCforExceptionIfNeeded): + (LLInt): + (JSC::LLInt::interpreterThrowInCaller): + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + +2012-08-20 Filip Pizlo <fpizlo@apple.com> + + fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html on 32-bit + https://bugs.webkit.org/show_bug.cgi?id=94538 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + +2012-08-20 Filip Pizlo <fpizlo@apple.com> + + fast/js/dfg-compare-final-object-to-final-object-or-other-when-both-proven-final-object.html crashes on 32-bit + https://bugs.webkit.org/show_bug.cgi?id=94026 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + +2012-08-19 Filip Pizlo <fpizlo@apple.com> + + The relationship between abstract values and structure transition watchpoints should be rationalized + https://bugs.webkit.org/show_bug.cgi?id=94205 + + Reviewed by Geoffrey Garen. + + This patch does a number of things related to the handling of the abstract values + arrising from values with structures known to be watchpointable: + + - This rationalizes the relationship between the structure that we know an object + to have *right now* based on having executed a check against that structure, and + the structure that we know the object could have *in the future* based on a type + check executed in the past over a structure that was watchpointable. + + - We use the above to assert that structure transition watchpoints are being used + soundly. + + - We use the above to strength reduce CheckStructure into StructureTransitionWatchpoint + whenever possible. + + - This rationalizes the handling of CFA over constants that appeared in the bytecode. + If at compile-time the constant has a watchpointable structure, then we can prove + what structures it may have in the future. The analysis uses this to both assert + that structure transition watchpoints are being used correctly, and to find + opportunities for using them more aggressively. + + The net effect of all of these changes is that OSR entry should work more smoothly. + It may also be a slight win due to strength reductions, though most of those strength + reductions would have already been done by the parser and the structure check hoister. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::beginBasicBlock): + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (DFG): + (JSC::DFG::AbstractValue::clear): + (JSC::DFG::AbstractValue::isClear): + (JSC::DFG::AbstractValue::makeTop): + (JSC::DFG::AbstractValue::clobberStructures): + (JSC::DFG::AbstractValue::isTop): + (JSC::DFG::AbstractValue::setFuturePossibleStructure): + (AbstractValue): + (JSC::DFG::AbstractValue::filterFuturePossibleStructure): + (JSC::DFG::AbstractValue::setMostSpecific): + (JSC::DFG::AbstractValue::set): + (JSC::DFG::AbstractValue::operator==): + (JSC::DFG::AbstractValue::merge): + (JSC::DFG::AbstractValue::filter): + (JSC::DFG::AbstractValue::filterValueByType): + (JSC::DFG::AbstractValue::validateType): + (JSC::DFG::AbstractValue::validate): + (JSC::DFG::AbstractValue::checkConsistency): + (JSC::DFG::AbstractValue::dump): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::checkStructureLoadElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToStructureTransitionWatchpoint): + (Node): + (JSC::DFG::Node::hasStructure): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + (JSC::DFG::SpeculativeJIT::forwardSpeculationWatchpoint): + (DFG): + (JSC::DFG::SpeculativeJIT::speculationWatchpointWithConditionalDirection): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::speculateArray): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureAbstractValue.h: Added. + (DFG): + (StructureAbstractValue): + (JSC::DFG::StructureAbstractValue::StructureAbstractValue): + (JSC::DFG::StructureAbstractValue::clear): + (JSC::DFG::StructureAbstractValue::makeTop): + (JSC::DFG::StructureAbstractValue::top): + (JSC::DFG::StructureAbstractValue::add): + (JSC::DFG::StructureAbstractValue::addAll): + (JSC::DFG::StructureAbstractValue::contains): + (JSC::DFG::StructureAbstractValue::isSubsetOf): + (JSC::DFG::StructureAbstractValue::doesNotContainAnyOtherThan): + (JSC::DFG::StructureAbstractValue::isSupersetOf): + (JSC::DFG::StructureAbstractValue::filter): + (JSC::DFG::StructureAbstractValue::isClear): + (JSC::DFG::StructureAbstractValue::isTop): + (JSC::DFG::StructureAbstractValue::isClearOrTop): + (JSC::DFG::StructureAbstractValue::isNeitherClearNorTop): + (JSC::DFG::StructureAbstractValue::size): + (JSC::DFG::StructureAbstractValue::at): + (JSC::DFG::StructureAbstractValue::operator[]): + (JSC::DFG::StructureAbstractValue::last): + (JSC::DFG::StructureAbstractValue::speculationFromStructures): + (JSC::DFG::StructureAbstractValue::hasSingleton): + (JSC::DFG::StructureAbstractValue::singleton): + (JSC::DFG::StructureAbstractValue::operator==): + (JSC::DFG::StructureAbstractValue::dump): + (JSC::DFG::StructureAbstractValue::topValue): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-17 Filip Pizlo <fpizlo@apple.com> + + The current state of the call frame should be taken into account in the DFG for both predictions and proofs + https://bugs.webkit.org/show_bug.cgi?id=94412 + + Reviewed by Geoffrey Garen. + + This ensures that no matter how smart the DFG gets, it'll always know through + which entrypoint OSR will try to enter, and with which values it will attempt + to do so. For prologue OSR, this has no effect other than adding the current + arguments to the argument predictions. For loop OSR, this makes our treatment + of the loop slightly more conservative - just conservative enough to ensure + that OSR succeeds. + + * bytecode/CodeBlock.cpp: + (JSC::ProgramCodeBlock::compileOptimized): + (JSC::EvalCodeBlock::compileOptimized): + (JSC::FunctionCodeBlock::compileOptimized): + * bytecode/CodeBlock.h: + (CodeBlock): + (ProgramCodeBlock): + (EvalCodeBlock): + (FunctionCodeBlock): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::setMostSpecific): + (AbstractValue): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + (JSC::DFG::tryCompile): + (JSC::DFG::tryCompileFunction): + * dfg/DFGDriver.h: + (DFG): + (JSC::DFG::tryCompile): + (JSC::DFG::tryCompileFunction): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::Graph): + (Graph): + * jit/JITDriver.h: + (JSC::jitCompileIfAppropriate): + (JSC::jitCompileFunctionIfAppropriate): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileOptimized): + (JSC::EvalExecutable::compileInternal): + (JSC::ProgramExecutable::compileOptimized): + (JSC::ProgramExecutable::compileInternal): + (JSC::FunctionExecutable::compileOptimizedForCall): + (JSC::FunctionExecutable::compileOptimizedForConstruct): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + * runtime/Executable.h: + (EvalExecutable): + (ProgramExecutable): + (FunctionExecutable): + (JSC::FunctionExecutable::compileOptimizedFor): + * runtime/ExecutionHarness.h: + (JSC::prepareForExecution): + (JSC::prepareFunctionForExecution): + +2012-08-17 Filip Pizlo <fpizlo@apple.com> + + DFG CSE should be more honest about when it changed the IR + https://bugs.webkit.org/show_bug.cgi?id=94408 + + Reviewed by Geoffrey Garen. + + The CSE phase now always returns true if it changed the IR. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + +2012-08-17 Filip Pizlo <fpizlo@apple.com> + + DFG is still too pessimistic about what constitutes a side-effect on array accesses + https://bugs.webkit.org/show_bug.cgi?id=94309 + + Reviewed by Geoffrey Garen. + + This change means that even if structure transition watchpoints are not used for + hoisting of clobbered structure checks, we still retain good performance on the + benchmarks we care about. That's important, since butterflies will likely make + most array structures not watchpointable. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-17 Milian Wolff <milian.wolff@kdab.com> + + [Qt] QNX build fails due to ctype usage in system headers + https://bugs.webkit.org/show_bug.cgi?id=93849 + + Reviewed by Simon Hausmann. + + Move the check for whether DisallowCType should be active or not + to the DisallowCType.h header. This way, we can update the list + of platforms or OSes which do not work with this header in a + central place. All users can now safely include the header + and do not need to place custom guards around it. + + * config.h: + +2012-08-16 Simon Hausmann <simon.hausmann@nokia.com> + + [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap + https://bugs.webkit.org/show_bug.cgi?id=93872 + + Reviewed by Kenneth Rohde Christiansen. + + * Target.pri: Add missing JSWeakObjectMap file to build. + +2012-08-16 Filip Pizlo <fpizlo@apple.com> + + Structure check hoisting should be less expensive + https://bugs.webkit.org/show_bug.cgi?id=94201 + + Reviewed by Mark Hahnenberg. + + This appears like a broad win on short-running programs. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::compareAndSwap): + (Graph): + (JSC::DFG::Graph::substitute): + (JSC::DFG::Graph::substituteGetLocal): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-16 Filip Pizlo <fpizlo@apple.com> + + All op_resolve_global instructions should end up in the list of global resolve instructions + https://bugs.webkit.org/show_bug.cgi?id=94247 + <rdar://problem/12103500> + + Reviewed by Mark Hahnenberg. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitResolveWithBase): + +2012-08-15 Bruno de Oliveira Abinader <bruno.abinader@basyskom.com> + + [css3-text] Add CSS3 Text decoration compile flag + https://bugs.webkit.org/show_bug.cgi?id=93863 + + Reviewed by Julien Chaffraix. + + This patch handles the compile flag implementation, which will come disabled by + default, thus not exposing the CSS3 text decoration features to the web, unless + when explicitly enabling it with "--css3-text-decoration" build parameter. + + * Configurations/FeatureDefines.xcconfig: + +2012-08-15 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r125687. + http://trac.webkit.org/changeset/125687 + https://bugs.webkit.org/show_bug.cgi?id=94147 + + It broke the whole world (Requested by Ossy_night on #webkit). + + * API/JSValueRef.cpp: + (JSValueToBoolean): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * bytecode/Watchpoint.h: + (WatchpointSet): + * debugger/DebuggerCallFrame.h: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncFilter): + (JSC::arrayProtoFuncEvery): + (JSC::arrayProtoFuncSome): + * runtime/BooleanConstructor.cpp: + (JSC::constructBoolean): + (JSC::callBooleanConstructor): + * runtime/JSCell.h: + (JSCell): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + * runtime/JSString.h: + (JSC::JSCell::toBoolean): + (JSC::JSValue::toBoolean): + * runtime/JSValue.h: + * runtime/ObjectConstructor.cpp: + (JSC::toPropertyDescriptor): + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC::jsIsObjectType): + * runtime/Operations.h: + (JSC): + (JSC::JSValue::equalSlowCaseInline): + * runtime/RegExpConstructor.cpp: + (JSC::setRegExpConstructorMultiline): + * runtime/RegExpPrototype.cpp: + (JSC::regExpProtoFuncToString): + * runtime/Structure.h: + +2012-08-15 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Buildfix after r125541 + https://bugs.webkit.org/show_bug.cgi?id=94097 + + Reviewed by Filip Pizlo. + + r125541 has broken the traditional ARM port build of JSC. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::neg32): + (JSC::MacroAssemblerARM::xor32): + +2012-08-14 Mark Hahnenberg <mhahnenberg@apple.com> + + Change behavior of MasqueradesAsUndefined to better accommodate DFG changes + https://bugs.webkit.org/show_bug.cgi?id=93884 + + Reviewed by Geoffrey Garen. + + With some upcoming changes to the DFG to remove uses of ClassInfo, we will be changing the behavior of + MasqueradesAsUndefined. In order to make this change consistent across all of our execution engines, + we will make this change to MasqueradesAsUndefined as a separate patch. After this patch, MasqueradesAsUndefined + objects will only masquerade as undefined in their original context (i.e. their original JSGlobalObject). + For example, if an object that masquerades as undefined in frame A is passed to frame B, it will not + masquerade as undefined within frame B, but it will continue to masquerade in frame A. + + There are two primary changes that are taking place here. One is to thread the ExecState* through + JSValue::toBoolean and JSCell::toBoolean so that JSCell::toBoolean can check the object's + JSGlobalObject to compare it to the lexical JSGlobalObject of the currently running code. If the two + are distinct, then the object cannot MasqueradeAsUndefined. + + The other change is to perform this comparison of JSGlobalObjects everywhere where the MasqueradesAsUndefined + flag in the Structure is checked. For C++ code, this check has been factored into its own function in + Structure::masqueradesAsUndefined. We only perform this check in the DFG if the current JSGlobalObject has + had a MasqueradesAsUndefined object allocated within its context. This conditional compilation is managed + through the use of a WatchpointSet in each JSGlobalObject and alternate create() functions for JS DOM wrappers + that are MasqueradesAsUndefined. + + * API/JSValueRef.cpp: + (JSValueToBoolean): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * bytecode/Watchpoint.h: + (WatchpointSet): + * debugger/DebuggerCallFrame.h: + (JSC::DebuggerCallFrame::callFrame): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncFilter): + (JSC::arrayProtoFuncEvery): + (JSC::arrayProtoFuncSome): + * runtime/BooleanConstructor.cpp: + (JSC::constructBoolean): + (JSC::callBooleanConstructor): + * runtime/JSCell.h: + (JSCell): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::masqueradesAsUndefinedWatchpoint): + * runtime/JSString.h: + (JSC::JSCell::toBoolean): + (JSC::JSValue::toBoolean): + * runtime/JSValue.h: + * runtime/ObjectConstructor.cpp: + (JSC::toPropertyDescriptor): + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC::jsIsObjectType): + * runtime/Operations.h: + (JSC): + (JSC::JSValue::equalSlowCaseInline): + * runtime/RegExpConstructor.cpp: + (JSC::setRegExpConstructorMultiline): + * runtime/RegExpPrototype.cpp: + (JSC::regExpProtoFuncToString): + * runtime/Structure.h: + (Structure): + (JSC::Structure::globalObjectOffset): + (JSC::Structure::masqueradesAsUndefined): + (JSC): + +2012-08-14 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, build fix for !ENABLE(DFG_JIT) + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-08-13 Filip Pizlo <fpizlo@apple.com> + + Array checks should use the structure, not the class info + https://bugs.webkit.org/show_bug.cgi?id=93150 + + Reviewed by Mark Hahnenberg. + + This changes all array checks used in array accesses (get, put, get length, + push, pop) to use the structure, not the class info. Additionally, these + checks in the LLInt and baseline JIT record the structure in an ArrayProfile, + so that the DFG can know exactly what structure to check for. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/ArrayProfile.cpp: Added. + (JSC): + (JSC::ArrayProfile::computeUpdatedPrediction): + * bytecode/ArrayProfile.h: Added. + (JSC): + (JSC::arrayModeFromStructure): + (ArrayProfile): + (JSC::ArrayProfile::ArrayProfile): + (JSC::ArrayProfile::bytecodeOffset): + (JSC::ArrayProfile::addressOfLastSeenStructure): + (JSC::ArrayProfile::observeStructure): + (JSC::ArrayProfile::expectedStructure): + (JSC::ArrayProfile::structureIsPolymorphic): + (JSC::ArrayProfile::hasDefiniteStructure): + (JSC::ArrayProfile::observedArrayModes): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::getArrayProfile): + (JSC): + (JSC::CodeBlock::getOrAddArrayProfile): + (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::executionEntryCount): + (JSC::CodeBlock::numberOfArrayProfiles): + (JSC::CodeBlock::arrayProfiles): + (JSC::CodeBlock::addArrayProfile): + (CodeBlock): + * bytecode/Instruction.h: + (JSC): + (JSC::Instruction::Instruction): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitGetArgumentByVal): + (JSC::BytecodeGenerator::emitGetByVal): + (JSC::BytecodeGenerator::emitPutByVal): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (JSC::DFG::StructureAbstractValue::hasSingleton): + (StructureAbstractValue): + (JSC::DFG::StructureAbstractValue::singleton): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculateArray): + (DFG): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LLIntOffsetsExtractor.cpp: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/Structure.h: + (Structure): + (JSC::Structure::classInfoOffset): + +2012-08-14 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Rename functions in the ARM port of DFG-JIT for better code readability. + https://bugs.webkit.org/show_bug.cgi?id=93609 + + Reviewed by Zoltan Herczeg. + + Rename functions in the ARM port of DFG-JIT for better code + readability, and for following the WebKit coding style + wherever it is possible. + + * assembler/ARMAssembler.cpp: + (JSC::ARMAssembler::genInt): + (JSC::ARMAssembler::getImm): + (JSC::ARMAssembler::moveImm): + (JSC::ARMAssembler::encodeComplexImm): + (JSC::ARMAssembler::dataTransfer32): + (JSC::ARMAssembler::baseIndexTransfer32): + (JSC::ARMAssembler::dataTransfer16): + (JSC::ARMAssembler::baseIndexTransfer16): + (JSC::ARMAssembler::dataTransferFloat): + (JSC::ARMAssembler::baseIndexTransferFloat): + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::bitAnd): + (JSC::ARMAssembler::bitAnds): + (JSC::ARMAssembler::eor): + (JSC::ARMAssembler::eors): + (JSC::ARMAssembler::sub): + (JSC::ARMAssembler::subs): + (JSC::ARMAssembler::rsb): + (JSC::ARMAssembler::rsbs): + (JSC::ARMAssembler::add): + (JSC::ARMAssembler::adds): + (JSC::ARMAssembler::adc): + (JSC::ARMAssembler::adcs): + (JSC::ARMAssembler::sbc): + (JSC::ARMAssembler::sbcs): + (JSC::ARMAssembler::rsc): + (JSC::ARMAssembler::rscs): + (JSC::ARMAssembler::tst): + (JSC::ARMAssembler::teq): + (JSC::ARMAssembler::cmp): + (JSC::ARMAssembler::cmn): + (JSC::ARMAssembler::orr): + (JSC::ARMAssembler::orrs): + (JSC::ARMAssembler::mov): + (JSC::ARMAssembler::movw): + (JSC::ARMAssembler::movt): + (JSC::ARMAssembler::movs): + (JSC::ARMAssembler::bic): + (JSC::ARMAssembler::bics): + (JSC::ARMAssembler::mvn): + (JSC::ARMAssembler::mvns): + (JSC::ARMAssembler::mul): + (JSC::ARMAssembler::muls): + (JSC::ARMAssembler::mull): + (JSC::ARMAssembler::vmov_f64): + (JSC::ARMAssembler::vadd_f64): + (JSC::ARMAssembler::vdiv_f64): + (JSC::ARMAssembler::vsub_f64): + (JSC::ARMAssembler::vmul_f64): + (JSC::ARMAssembler::vcmp_f64): + (JSC::ARMAssembler::vsqrt_f64): + (JSC::ARMAssembler::vabs_f64): + (JSC::ARMAssembler::vneg_f64): + (JSC::ARMAssembler::ldrImmediate): + (JSC::ARMAssembler::ldrUniqueImmediate): + (JSC::ARMAssembler::dtrUp): + (JSC::ARMAssembler::dtrUpRegister): + (JSC::ARMAssembler::dtrDown): + (JSC::ARMAssembler::dtrDownRegister): + (JSC::ARMAssembler::halfDtrUp): + (JSC::ARMAssembler::halfDtrUpRegister): + (JSC::ARMAssembler::halfDtrDown): + (JSC::ARMAssembler::halfDtrDownRegister): + (JSC::ARMAssembler::doubleDtrUp): + (JSC::ARMAssembler::doubleDtrDown): + (JSC::ARMAssembler::push): + (JSC::ARMAssembler::pop): + (JSC::ARMAssembler::poke): + (JSC::ARMAssembler::peek): + (JSC::ARMAssembler::vmov_vfp64): + (JSC::ARMAssembler::vmov_arm64): + (JSC::ARMAssembler::vmov_vfp32): + (JSC::ARMAssembler::vmov_arm32): + (JSC::ARMAssembler::vcvt_f64_s32): + (JSC::ARMAssembler::vcvt_s32_f64): + (JSC::ARMAssembler::vcvt_u32_f64): + (JSC::ARMAssembler::vcvt_f64_f32): + (JSC::ARMAssembler::vcvt_f32_f64): + (JSC::ARMAssembler::clz): + (JSC::ARMAssembler::lslRegister): + (JSC::ARMAssembler::lsrRegister): + (JSC::ARMAssembler::asrRegister): + (JSC::ARMAssembler::align): + (JSC::ARMAssembler::loadBranchTarget): + (JSC::ARMAssembler::vmov): + * assembler/MacroAssemblerARM.cpp: + (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::add32): + (JSC::MacroAssemblerARM::and32): + (JSC::MacroAssemblerARM::lshift32): + (JSC::MacroAssemblerARM::mul32): + (JSC::MacroAssemblerARM::or32): + (JSC::MacroAssemblerARM::rshift32): + (JSC::MacroAssemblerARM::urshift32): + (JSC::MacroAssemblerARM::sub32): + (JSC::MacroAssemblerARM::xor32): + (JSC::MacroAssemblerARM::countLeadingZeros32): + (JSC::MacroAssemblerARM::convertibleLoadPtr): + (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch): + (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch): + (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch): + (JSC::MacroAssemblerARM::store32): + (JSC::MacroAssemblerARM::pop): + (JSC::MacroAssemblerARM::push): + (JSC::MacroAssemblerARM::move): + (JSC::MacroAssemblerARM::swap): + (JSC::MacroAssemblerARM::branch32): + (JSC::MacroAssemblerARM::branchTest32): + (JSC::MacroAssemblerARM::mull32): + (JSC::MacroAssemblerARM::branchSub32): + (JSC::MacroAssemblerARM::compare32): + (JSC::MacroAssemblerARM::test32): + (JSC::MacroAssemblerARM::load32): + (JSC::MacroAssemblerARM::relativeTableJump): + (JSC::MacroAssemblerARM::moveWithPatch): + (JSC::MacroAssemblerARM::loadDouble): + (JSC::MacroAssemblerARM::moveDouble): + (JSC::MacroAssemblerARM::addDouble): + (JSC::MacroAssemblerARM::divDouble): + (JSC::MacroAssemblerARM::subDouble): + (JSC::MacroAssemblerARM::mulDouble): + (JSC::MacroAssemblerARM::sqrtDouble): + (JSC::MacroAssemblerARM::absDouble): + (JSC::MacroAssemblerARM::negateDouble): + (JSC::MacroAssemblerARM::convertInt32ToDouble): + (JSC::MacroAssemblerARM::convertFloatToDouble): + (JSC::MacroAssemblerARM::convertDoubleToFloat): + (JSC::MacroAssemblerARM::branchDouble): + (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): + (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): + (JSC::MacroAssemblerARM::truncateDoubleToInt32): + (JSC::MacroAssemblerARM::truncateDoubleToUint32): + (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): + (JSC::MacroAssemblerARM::branchDoubleNonZero): + (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN): + +2012-08-13 Simon Hausmann <simon.hausmann@nokia.com> + + Unreviewed, rolling out r125444. + http://trac.webkit.org/changeset/125444 + https://bugs.webkit.org/show_bug.cgi?id=93872 + + Broke some tests + + * Target.pri: + +2012-08-13 Simon Hausmann <simon.hausmann@nokia.com> + + [Qt] Replace use of internal Weak smart pointer with JSWeakObjectMap + https://bugs.webkit.org/show_bug.cgi?id=93872 + + Reviewed by Kenneth Rohde Christiansen. + + * Target.pri: Add missing JSWeakObjectMap file to build. + +2012-08-13 Raphael Kubo da Costa <rakuco@webkit.org> + + [CMake] Remove glib-related Find modules and write single new one instead. + https://bugs.webkit.org/show_bug.cgi?id=93786 + + Reviewed by Rob Buis. + + * shell/PlatformEfl.cmake: Use GLIB_* instead of Glib_*. + +2012-08-12 Allan Sandfeld Jensen <allan.jensen@nokia.com> + + Doesn't build with ENABLE_JIT=0 + https://bugs.webkit.org/show_bug.cgi?id=85042 + + Reviewed by Eric Seidel. + + Include headers without which CallFrame.h does not build, and + fix gcc warning about comparing unsigned int with 0. + + * dfg/DFGDriver.cpp: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::isOpcode): + +2012-08-10 Yong Li <yoli@rim.com> + + [BlackBerry] GCActivityCallback should always schedule GC even allocated bytes is a small number + https://bugs.webkit.org/show_bug.cgi?id=93650 + + Reviewed by Rob Buis. + + Even a small number of allocated JS objects could hold expensive resources. + + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC::DefaultGCActivityCallback::didAllocate): + +2012-08-09 Yong Li <yoli@rim.com> + + [QNX] Implement getCPUTime() for OS(QNX) + https://bugs.webkit.org/show_bug.cgi?id=93516 + + Reviewed by George Staikos. + + Implement getCPUTime() with CLOCK_THREAD_CPUTIME_ID so it will tell + exactly how long the current thread has spent without being impacted + by other things. + + * runtime/TimeoutChecker.cpp: + (JSC::getCPUTime): + +2012-08-08 Shane Stephens <shanestephens@google.com> + + Compile flag for CSS Hierarchies + https://bugs.webkit.org/show_bug.cgi?id=92433 + + Reviewed by Tony Chang. + + * Configurations/FeatureDefines.xcconfig: + +2012-08-08 Benjamin Poulain <bpoulain@apple.com> + + Use char* instead of LChar* for the public interface of String construction from literals + https://bugs.webkit.org/show_bug.cgi?id=93402 + + Reviewed by Michael Saboff. + + Update JSC' Identifier to use StringImpl::createFromLiteral with a char*. + + * runtime/Identifier.cpp: + (JSC::IdentifierASCIIStringTranslator::translate): + +2012-08-08 Patrick Gansterer <paroga@webkit.org> + + Remove ce_time.(cpp|h) from list of source files + https://bugs.webkit.org/show_bug.cgi?id=93446 + + Reviewed by Simon Hausmann. + + r125004 removed the last dependency on functions defined in ce_time.cpp. + + * Target.pri: + +2012-08-08 Patrick Gansterer <paroga@webkit.org> + + [WIN] Use GetTimeZoneInformation() for getting the timezone name + https://bugs.webkit.org/show_bug.cgi?id=91936 + + Reviewed by Ryosuke Niwa. + + The MS CRT implementation of strftime calls the same functions in the background. + Using them directly avoids the overhead of parsing the format string and removes + the dependency on strftime() for WinCE where this function does not exist. + + * runtime/DateConversion.cpp: + (JSC::formatTime): + +2012-08-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Refactor magic numbers in the ARM port of DFG-JIT + https://bugs.webkit.org/show_bug.cgi?id=93348 + + Reviewed by Eric Seidel. + + Introduce new names for hard-coded magic numbers. + Refactor constant with confusing names to more descriptive ones. + + * assembler/ARMAssembler.cpp: + (JSC::ARMAssembler::patchConstantPoolLoad): + (JSC::ARMAssembler::getOp2): + (JSC::ARMAssembler::genInt): + (JSC::ARMAssembler::getImm): + (JSC::ARMAssembler::moveImm): + (JSC::ARMAssembler::encodeComplexImm): + (JSC::ARMAssembler::dataTransfer32): + (JSC::ARMAssembler::dataTransfer16): + (JSC::ARMAssembler::dataTransferFloat): + (JSC::ARMAssembler::executableCopy): + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::emitInstruction): + (JSC::ARMAssembler::ands_r): + (JSC::ARMAssembler::eors_r): + (JSC::ARMAssembler::subs_r): + (JSC::ARMAssembler::rsbs_r): + (JSC::ARMAssembler::adds_r): + (JSC::ARMAssembler::adcs_r): + (JSC::ARMAssembler::sbcs_r): + (JSC::ARMAssembler::rscs_r): + (JSC::ARMAssembler::tst_r): + (JSC::ARMAssembler::teq_r): + (JSC::ARMAssembler::cmp_r): + (JSC::ARMAssembler::cmn_r): + (JSC::ARMAssembler::orrs_r): + (JSC::ARMAssembler::movs_r): + (JSC::ARMAssembler::bics_r): + (JSC::ARMAssembler::mvns_r): + (JSC::ARMAssembler::muls_r): + (JSC::ARMAssembler::ldr_imm): + (JSC::ARMAssembler::ldr_un_imm): + (JSC::ARMAssembler::dtr_u): + (JSC::ARMAssembler::dtr_ur): + (JSC::ARMAssembler::dtr_dr): + (JSC::ARMAssembler::dtrh_u): + (JSC::ARMAssembler::dtrh_ur): + (JSC::ARMAssembler::fdtr_u): + (JSC::ARMAssembler::push_r): + (JSC::ARMAssembler::pop_r): + (JSC::ARMAssembler::getLdrImmAddress): + (JSC::ARMAssembler::getLdrImmAddressOnPool): + (JSC::ARMAssembler::patchConstantPoolLoad): + (JSC::ARMAssembler::repatchCompact): + (JSC::ARMAssembler::replaceWithJump): + (JSC::ARMAssembler::replaceWithLoad): + (JSC::ARMAssembler::replaceWithAddressComputation): + (JSC::ARMAssembler::getOp2Byte): + (JSC::ARMAssembler::getOp2Half): + (JSC::ARMAssembler::getImm16Op2): + (JSC::ARMAssembler::placeConstantPoolBarrier): + (JSC::ARMAssembler::getConditionalField): + * assembler/MacroAssemblerARM.cpp: + (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::and32): + (JSC::MacroAssemblerARM::branch32): + (JSC::MacroAssemblerARM::branchTest32): + (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): + +2012-08-07 Benjamin Poulain <benjamin@webkit.org> + + Use the initialization from literal for JSC's Identifiers + https://bugs.webkit.org/show_bug.cgi?id=93193 + + Reviewed by Geoffrey Garen. + + This patches modify Identifier ot take advantage of the new initialization from literal. + + In addition to the memory savings (~600bytes per instance), this gives us a 2% speed + improvement on CommonIdentifiers on average. + + * runtime/CommonIdentifiers.cpp: + (JSC::CommonIdentifiers::CommonIdentifiers): + Null and empty strings are forbidden for literal initialization. Use the most efficient constructors + instead of a literal. + + * runtime/Identifier.cpp: + (IdentifierASCIIStringTranslator): + Rename IdentifierCStringTranslator to IdentifierASCIIStringTranslator to make the text encoding + explicit. + (JSC::IdentifierASCIIStringTranslator::hash): + (JSC::IdentifierASCIIStringTranslator::equal): + (JSC::IdentifierASCIIStringTranslator::translate): Use the fast initialization from literal. + (JSC::Identifier::add): + * runtime/Identifier.h: + (JSC::Identifier::Identifier): + +2012-08-07 Simon Hausmann <simon.hausmann@nokia.com> + + [Qt][Win] Remove pthreads linkage + + Reviewed by Csaba Osztrogonác. + + After r124823 linkage to pthreads is not needed anymore for the Windows + build. + + * JavaScriptCore.pri: + +2012-08-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Refactor emit*Inst functions and introduce toARMWord functions in DFG-JIT's traditional ARM port + https://bugs.webkit.org/show_bug.cgi?id=93266 + + Reviewed by Csaba Osztrogonác. + + First part of a bigger refactoring issue trying to make traditional + ARM DFG-JIT port easier to read and understand. + + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::emitInstruction): + (JSC::ARMAssembler::emitDoublePrecisionInstruction): + (JSC::ARMAssembler::emitSinglePrecisionInstruction): + (JSC::ARMAssembler::and_r): + (JSC::ARMAssembler::ands_r): + (JSC::ARMAssembler::eor_r): + (JSC::ARMAssembler::eors_r): + (JSC::ARMAssembler::sub_r): + (JSC::ARMAssembler::subs_r): + (JSC::ARMAssembler::rsb_r): + (JSC::ARMAssembler::rsbs_r): + (JSC::ARMAssembler::add_r): + (JSC::ARMAssembler::adds_r): + (JSC::ARMAssembler::adc_r): + (JSC::ARMAssembler::adcs_r): + (JSC::ARMAssembler::sbc_r): + (JSC::ARMAssembler::sbcs_r): + (JSC::ARMAssembler::rsc_r): + (JSC::ARMAssembler::rscs_r): + (JSC::ARMAssembler::tst_r): + (JSC::ARMAssembler::teq_r): + (JSC::ARMAssembler::cmp_r): + (JSC::ARMAssembler::cmn_r): + (JSC::ARMAssembler::orr_r): + (JSC::ARMAssembler::orrs_r): + (JSC::ARMAssembler::mov_r): + (JSC::ARMAssembler::movw_r): + (JSC::ARMAssembler::movt_r): + (JSC::ARMAssembler::movs_r): + (JSC::ARMAssembler::bic_r): + (JSC::ARMAssembler::bics_r): + (JSC::ARMAssembler::mvn_r): + (JSC::ARMAssembler::mvns_r): + (JSC::ARMAssembler::mul_r): + (JSC::ARMAssembler::muls_r): + (JSC::ARMAssembler::mull_r): + (JSC::ARMAssembler::vmov_f64_r): + (JSC::ARMAssembler::vadd_f64_r): + (JSC::ARMAssembler::vdiv_f64_r): + (JSC::ARMAssembler::vsub_f64_r): + (JSC::ARMAssembler::vmul_f64_r): + (JSC::ARMAssembler::vcmp_f64_r): + (JSC::ARMAssembler::vsqrt_f64_r): + (JSC::ARMAssembler::vabs_f64_r): + (JSC::ARMAssembler::vneg_f64_r): + (JSC::ARMAssembler::ldr_imm): + (JSC::ARMAssembler::ldr_un_imm): + (JSC::ARMAssembler::dtr_u): + (JSC::ARMAssembler::dtr_ur): + (JSC::ARMAssembler::dtr_d): + (JSC::ARMAssembler::dtr_dr): + (JSC::ARMAssembler::dtrh_u): + (JSC::ARMAssembler::dtrh_ur): + (JSC::ARMAssembler::dtrh_d): + (JSC::ARMAssembler::dtrh_dr): + (JSC::ARMAssembler::fdtr_u): + (JSC::ARMAssembler::fdtr_d): + (JSC::ARMAssembler::push_r): + (JSC::ARMAssembler::pop_r): + (JSC::ARMAssembler::vmov_vfp64_r): + (JSC::ARMAssembler::vmov_arm64_r): + (JSC::ARMAssembler::vmov_vfp32_r): + (JSC::ARMAssembler::vmov_arm32_r): + (JSC::ARMAssembler::vcvt_f64_s32_r): + (JSC::ARMAssembler::vcvt_s32_f64_r): + (JSC::ARMAssembler::vcvt_u32_f64_r): + (JSC::ARMAssembler::vcvt_f64_f32_r): + (JSC::ARMAssembler::vcvt_f32_f64_r): + (JSC::ARMAssembler::vmrs_apsr): + (JSC::ARMAssembler::clz_r): + (JSC::ARMAssembler::bx): + (JSC::ARMAssembler::blx): + (JSC::ARMAssembler::linkJump): + (JSC::ARMAssembler::toARMWord): + (ARMAssembler): + +2012-08-06 Patrick Gansterer <paroga@webkit.org> + + [WIN] Remove dependency on pthread from MachineStackMarker + https://bugs.webkit.org/show_bug.cgi?id=68429 + + Reviewed by Geoffrey Garen. + + Windows has no support for calling a destructor for thread specific data. + Since we need more control over creating and deleting thread specific keys + we can not simply extend WTF::ThreadSpecific with this functionality. + + All thread specific keys created via the new API get stored in a list. + After a thread function finished we iterate over this list and call + the registered destructor for every item if needed. + + * heap/MachineStackMarker.cpp: Use the new functions instead of pthread directly. + (JSC::MachineThreads::~MachineThreads): + (JSC::MachineThreads::makeUsableFromMultipleThreads): + (JSC::MachineThreads::addCurrentThread): + * heap/MachineStackMarker.h: + (MachineThreads): + +2012-08-06 Patrick Gansterer <paroga@webkit.org> + + Unify JSC date and time formating functions + https://bugs.webkit.org/show_bug.cgi?id=92282 + + Reviewed by Geoffrey Garen. + + Replace the existing functions for formating GregorianDateTime + with one single function. This removes some code duplications + in DatePrototype and is a preperation to fix encoding issues, + since we can add UChar* values to the resulting string now. + + * runtime/DateConstructor.cpp: + (JSC::callDate): + * runtime/DateConversion.cpp: + (JSC::formatDateTime): + * runtime/DateConversion.h: + (JSC): + * runtime/DatePrototype.cpp: + (JSC::formateDateInstance): + (JSC::dateProtoFuncToString): + (JSC::dateProtoFuncToUTCString): + (JSC::dateProtoFuncToDateString): + (JSC::dateProtoFuncToTimeString): + (JSC::dateProtoFuncToGMTString): + +2012-08-06 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing header file. + +2012-08-05 Peter Wang <peter.wang@torchmobile.com.cn> + + Web Inspector: [JSC] implement setting breakpoints by line:column + https://bugs.webkit.org/show_bug.cgi?id=53003 + + Reviewed by Geoffrey Garen. + + Add a counter to Lexer to record the column info of each Token. Add a column parameter to + op_debug, cti_op_debug, and _llint_op_debug byte-code command. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::emitDebugHook): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ArrayNode::toArgumentList): + (JSC::ApplyFunctionCallDotNode::emitBytecode): + (JSC::ConstStatementNode::emitBytecode): + (JSC::EmptyStatementNode::emitBytecode): + (JSC::DebuggerStatementNode::emitBytecode): + (JSC::ExprStatementNode::emitBytecode): + (JSC::VarStatementNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + (JSC::WithNode::emitBytecode): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + (JSC::ThrowNode::emitBytecode): + (JSC::TryNode::emitBytecode): + (JSC::ProgramNode::emitBytecode): + (JSC::EvalNode::emitBytecode): + (JSC::FunctionBodyNode::emitBytecode): + * debugger/Debugger.h: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): + (JSC::Interpreter::throwException): + (JSC::Interpreter::debug): + (JSC::Interpreter::privateExecute): + * interpreter/Interpreter.h: + (Interpreter): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::createCommaExpr): + (JSC::ASTBuilder::createLogicalNot): + (JSC::ASTBuilder::createUnaryPlus): + (JSC::ASTBuilder::createVoid): + (JSC::ASTBuilder::thisExpr): + (JSC::ASTBuilder::createResolve): + (JSC::ASTBuilder::createObjectLiteral): + (JSC::ASTBuilder::createArray): + (JSC::ASTBuilder::createNumberExpr): + (JSC::ASTBuilder::createString): + (JSC::ASTBuilder::createBoolean): + (JSC::ASTBuilder::createNull): + (JSC::ASTBuilder::createBracketAccess): + (JSC::ASTBuilder::createDotAccess): + (JSC::ASTBuilder::createRegExp): + (JSC::ASTBuilder::createNewExpr): + (JSC::ASTBuilder::createConditionalExpr): + (JSC::ASTBuilder::createAssignResolve): + (JSC::ASTBuilder::createFunctionExpr): + (JSC::ASTBuilder::createFunctionBody): + (JSC::ASTBuilder::createGetterOrSetterProperty): + (JSC::ASTBuilder::createArgumentsList): + (JSC::ASTBuilder::createPropertyList): + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::createBlockStatement): + (JSC::ASTBuilder::createExprStatement): + (JSC::ASTBuilder::createIfStatement): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::createEmptyStatement): + (JSC::ASTBuilder::createVarStatement): + (JSC::ASTBuilder::createReturnStatement): + (JSC::ASTBuilder::createBreakStatement): + (JSC::ASTBuilder::createContinueStatement): + (JSC::ASTBuilder::createTryStatement): + (JSC::ASTBuilder::createSwitchStatement): + (JSC::ASTBuilder::createWhileStatement): + (JSC::ASTBuilder::createDoWhileStatement): + (JSC::ASTBuilder::createLabelStatement): + (JSC::ASTBuilder::createWithStatement): + (JSC::ASTBuilder::createThrowStatement): + (JSC::ASTBuilder::createDebugger): + (JSC::ASTBuilder::createConstStatement): + (JSC::ASTBuilder::appendConstDecl): + (JSC::ASTBuilder::combineCommaNodes): + (JSC::ASTBuilder::appendBinaryOperation): + (JSC::ASTBuilder::createAssignment): + (JSC::ASTBuilder::createNumber): + (JSC::ASTBuilder::makeTypeOfNode): + (JSC::ASTBuilder::makeDeleteNode): + (JSC::ASTBuilder::makeNegateNode): + (JSC::ASTBuilder::makeBitwiseNotNode): + (JSC::ASTBuilder::makeMultNode): + (JSC::ASTBuilder::makeDivNode): + (JSC::ASTBuilder::makeModNode): + (JSC::ASTBuilder::makeAddNode): + (JSC::ASTBuilder::makeSubNode): + (JSC::ASTBuilder::makeLeftShiftNode): + (JSC::ASTBuilder::makeRightShiftNode): + (JSC::ASTBuilder::makeURightShiftNode): + (JSC::ASTBuilder::makeBitOrNode): + (JSC::ASTBuilder::makeBitAndNode): + (JSC::ASTBuilder::makeBitXOrNode): + (JSC::ASTBuilder::makeFunctionCallNode): + (JSC::ASTBuilder::makeBinaryNode): + (JSC::ASTBuilder::makeAssignNode): + (JSC::ASTBuilder::makePrefixNode): + (JSC::ASTBuilder::makePostfixNode): + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::internalShift): + (JSC::::shift): + (JSC::::lex): + * parser/Lexer.h: + (Lexer): + (JSC::Lexer::currentColumnNumber): + (JSC::::lexExpectIdentifier): + * parser/NodeConstructors.h: + (JSC::Node::Node): + (JSC::ExpressionNode::ExpressionNode): + (JSC::StatementNode::StatementNode): + (JSC::NullNode::NullNode): + (JSC::BooleanNode::BooleanNode): + (JSC::NumberNode::NumberNode): + (JSC::StringNode::StringNode): + (JSC::RegExpNode::RegExpNode): + (JSC::ThisNode::ThisNode): + (JSC::ResolveNode::ResolveNode): + (JSC::ArrayNode::ArrayNode): + (JSC::PropertyListNode::PropertyListNode): + (JSC::ObjectLiteralNode::ObjectLiteralNode): + (JSC::BracketAccessorNode::BracketAccessorNode): + (JSC::DotAccessorNode::DotAccessorNode): + (JSC::ArgumentListNode::ArgumentListNode): + (JSC::NewExprNode::NewExprNode): + (JSC::EvalFunctionCallNode::EvalFunctionCallNode): + (JSC::FunctionCallValueNode::FunctionCallValueNode): + (JSC::FunctionCallResolveNode::FunctionCallResolveNode): + (JSC::FunctionCallBracketNode::FunctionCallBracketNode): + (JSC::FunctionCallDotNode::FunctionCallDotNode): + (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): + (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): + (JSC::PrePostResolveNode::PrePostResolveNode): + (JSC::PostfixResolveNode::PostfixResolveNode): + (JSC::PostfixBracketNode::PostfixBracketNode): + (JSC::PostfixDotNode::PostfixDotNode): + (JSC::PostfixErrorNode::PostfixErrorNode): + (JSC::DeleteResolveNode::DeleteResolveNode): + (JSC::DeleteBracketNode::DeleteBracketNode): + (JSC::DeleteDotNode::DeleteDotNode): + (JSC::DeleteValueNode::DeleteValueNode): + (JSC::VoidNode::VoidNode): + (JSC::TypeOfResolveNode::TypeOfResolveNode): + (JSC::TypeOfValueNode::TypeOfValueNode): + (JSC::PrefixResolveNode::PrefixResolveNode): + (JSC::PrefixBracketNode::PrefixBracketNode): + (JSC::PrefixDotNode::PrefixDotNode): + (JSC::PrefixErrorNode::PrefixErrorNode): + (JSC::UnaryOpNode::UnaryOpNode): + (JSC::UnaryPlusNode::UnaryPlusNode): + (JSC::NegateNode::NegateNode): + (JSC::BitwiseNotNode::BitwiseNotNode): + (JSC::LogicalNotNode::LogicalNotNode): + (JSC::BinaryOpNode::BinaryOpNode): + (JSC::MultNode::MultNode): + (JSC::DivNode::DivNode): + (JSC::ModNode::ModNode): + (JSC::AddNode::AddNode): + (JSC::SubNode::SubNode): + (JSC::LeftShiftNode::LeftShiftNode): + (JSC::RightShiftNode::RightShiftNode): + (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): + (JSC::LessNode::LessNode): + (JSC::GreaterNode::GreaterNode): + (JSC::LessEqNode::LessEqNode): + (JSC::GreaterEqNode::GreaterEqNode): + (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): + (JSC::InstanceOfNode::InstanceOfNode): + (JSC::InNode::InNode): + (JSC::EqualNode::EqualNode): + (JSC::NotEqualNode::NotEqualNode): + (JSC::StrictEqualNode::StrictEqualNode): + (JSC::NotStrictEqualNode::NotStrictEqualNode): + (JSC::BitAndNode::BitAndNode): + (JSC::BitOrNode::BitOrNode): + (JSC::BitXOrNode::BitXOrNode): + (JSC::LogicalOpNode::LogicalOpNode): + (JSC::ConditionalNode::ConditionalNode): + (JSC::ReadModifyResolveNode::ReadModifyResolveNode): + (JSC::AssignResolveNode::AssignResolveNode): + (JSC::ReadModifyBracketNode::ReadModifyBracketNode): + (JSC::AssignBracketNode::AssignBracketNode): + (JSC::AssignDotNode::AssignDotNode): + (JSC::ReadModifyDotNode::ReadModifyDotNode): + (JSC::AssignErrorNode::AssignErrorNode): + (JSC::CommaNode::CommaNode): + (JSC::ConstStatementNode::ConstStatementNode): + (JSC::EmptyStatementNode::EmptyStatementNode): + (JSC::DebuggerStatementNode::DebuggerStatementNode): + (JSC::ExprStatementNode::ExprStatementNode): + (JSC::VarStatementNode::VarStatementNode): + (JSC::IfNode::IfNode): + (JSC::IfElseNode::IfElseNode): + (JSC::DoWhileNode::DoWhileNode): + (JSC::WhileNode::WhileNode): + (JSC::ForNode::ForNode): + (JSC::ContinueNode::ContinueNode): + (JSC::BreakNode::BreakNode): + (JSC::ReturnNode::ReturnNode): + (JSC::WithNode::WithNode): + (JSC::LabelNode::LabelNode): + (JSC::ThrowNode::ThrowNode): + (JSC::TryNode::TryNode): + (JSC::FuncExprNode::FuncExprNode): + (JSC::FuncDeclNode::FuncDeclNode): + (JSC::SwitchNode::SwitchNode): + (JSC::ConstDeclNode::ConstDeclNode): + (JSC::BlockNode::BlockNode): + (JSC::ForInNode::ForInNode): + * parser/Nodes.cpp: + (JSC::StatementNode::setLoc): + (JSC): + (JSC::ScopeNode::ScopeNode): + (JSC::ProgramNode::ProgramNode): + (JSC::ProgramNode::create): + (JSC::EvalNode::EvalNode): + (JSC::EvalNode::create): + (JSC::FunctionBodyNode::FunctionBodyNode): + (JSC::FunctionBodyNode::create): + * parser/Nodes.h: + (Node): + (JSC::Node::columnNo): + (ExpressionNode): + (StatementNode): + (JSC::StatementNode::column): + (NullNode): + (BooleanNode): + (NumberNode): + (StringNode): + (RegExpNode): + (ThisNode): + (ResolveNode): + (ArrayNode): + (PropertyListNode): + (ObjectLiteralNode): + (BracketAccessorNode): + (DotAccessorNode): + (ArgumentListNode): + (NewExprNode): + (EvalFunctionCallNode): + (FunctionCallValueNode): + (FunctionCallResolveNode): + (FunctionCallBracketNode): + (FunctionCallDotNode): + (CallFunctionCallDotNode): + (ApplyFunctionCallDotNode): + (PrePostResolveNode): + (PostfixResolveNode): + (PostfixBracketNode): + (PostfixDotNode): + (PostfixErrorNode): + (DeleteResolveNode): + (DeleteBracketNode): + (DeleteDotNode): + (DeleteValueNode): + (VoidNode): + (TypeOfResolveNode): + (TypeOfValueNode): + (PrefixResolveNode): + (PrefixBracketNode): + (PrefixDotNode): + (PrefixErrorNode): + (UnaryOpNode): + (UnaryPlusNode): + (NegateNode): + (BitwiseNotNode): + (LogicalNotNode): + (BinaryOpNode): + (MultNode): + (DivNode): + (ModNode): + (AddNode): + (SubNode): + (LeftShiftNode): + (RightShiftNode): + (UnsignedRightShiftNode): + (LessNode): + (GreaterNode): + (LessEqNode): + (GreaterEqNode): + (ThrowableBinaryOpNode): + (InstanceOfNode): + (InNode): + (EqualNode): + (NotEqualNode): + (StrictEqualNode): + (NotStrictEqualNode): + (BitAndNode): + (BitOrNode): + (BitXOrNode): + (LogicalOpNode): + (ConditionalNode): + (ReadModifyResolveNode): + (AssignResolveNode): + (ReadModifyBracketNode): + (AssignBracketNode): + (AssignDotNode): + (ReadModifyDotNode): + (AssignErrorNode): + (CommaNode): + (ConstDeclNode): + (ConstStatementNode): + (BlockNode): + (EmptyStatementNode): + (DebuggerStatementNode): + (ExprStatementNode): + (VarStatementNode): + (IfNode): + (IfElseNode): + (DoWhileNode): + (WhileNode): + (ForNode): + (ForInNode): + (ContinueNode): + (BreakNode): + (ReturnNode): + (WithNode): + (LabelNode): + (ThrowNode): + (TryNode): + (ScopeNode): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + (FuncExprNode): + (FuncDeclNode): + (SwitchNode): + * parser/Parser.cpp: + (JSC::::parseSourceElements): + (JSC::::parseVarDeclaration): + (JSC::::parseConstDeclaration): + (JSC::::parseDoWhileStatement): + (JSC::::parseWhileStatement): + (JSC::::parseVarDeclarationList): + (JSC::::parseConstDeclarationList): + (JSC::::parseForStatement): + (JSC::::parseBreakStatement): + (JSC::::parseContinueStatement): + (JSC::::parseReturnStatement): + (JSC::::parseThrowStatement): + (JSC::::parseWithStatement): + (JSC::::parseSwitchStatement): + (JSC::::parseTryStatement): + (JSC::::parseDebuggerStatement): + (JSC::::parseBlockStatement): + (JSC::::parseStatement): + (JSC::::parseFunctionBody): + (JSC::::parseFunctionInfo): + (JSC::::parseFunctionDeclaration): + (JSC::::parseExpressionOrLabelStatement): + (JSC::::parseExpressionStatement): + (JSC::::parseIfStatement): + (JSC::::parseExpression): + (JSC::::parseAssignmentExpression): + (JSC::::parseConditionalExpression): + (JSC::::parseBinaryExpression): + (JSC::::parseProperty): + (JSC::::parseObjectLiteral): + (JSC::::parseStrictObjectLiteral): + (JSC::::parseArrayLiteral): + (JSC::::parsePrimaryExpression): + (JSC::::parseArguments): + (JSC::::parseMemberExpression): + (JSC::::parseUnaryExpression): + * parser/Parser.h: + (JSC::Parser::next): + (JSC::Parser::nextExpectIdentifier): + (JSC::Parser::tokenStart): + (JSC::Parser::tokenLine): + (JSC::Parser::tokenEnd): + (JSC::Parser::tokenLocation): + (Parser): + (JSC::Parser::getTokenName): + (JSC::::parse): + * parser/ParserTokens.h: + (JSC::JSTokenLocation::JSTokenLocation): + (JSTokenLocation): + (JSToken): + * parser/SourceProviderCacheItem.h: + (JSC::SourceProviderCacheItem::closeBraceToken): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::makeFunctionCallNode): + (JSC::SyntaxChecker::createCommaExpr): + (JSC::SyntaxChecker::makeAssignNode): + (JSC::SyntaxChecker::makePrefixNode): + (JSC::SyntaxChecker::makePostfixNode): + (JSC::SyntaxChecker::makeTypeOfNode): + (JSC::SyntaxChecker::makeDeleteNode): + (JSC::SyntaxChecker::makeNegateNode): + (JSC::SyntaxChecker::makeBitwiseNotNode): + (JSC::SyntaxChecker::createLogicalNot): + (JSC::SyntaxChecker::createUnaryPlus): + (JSC::SyntaxChecker::createVoid): + (JSC::SyntaxChecker::thisExpr): + (JSC::SyntaxChecker::createResolve): + (JSC::SyntaxChecker::createObjectLiteral): + (JSC::SyntaxChecker::createArray): + (JSC::SyntaxChecker::createNumberExpr): + (JSC::SyntaxChecker::createString): + (JSC::SyntaxChecker::createBoolean): + (JSC::SyntaxChecker::createNull): + (JSC::SyntaxChecker::createBracketAccess): + (JSC::SyntaxChecker::createDotAccess): + (JSC::SyntaxChecker::createRegExp): + (JSC::SyntaxChecker::createNewExpr): + (JSC::SyntaxChecker::createConditionalExpr): + (JSC::SyntaxChecker::createAssignResolve): + (JSC::SyntaxChecker::createFunctionExpr): + (JSC::SyntaxChecker::createFunctionBody): + (JSC::SyntaxChecker::createArgumentsList): + (JSC::SyntaxChecker::createPropertyList): + (JSC::SyntaxChecker::createFuncDeclStatement): + (JSC::SyntaxChecker::createBlockStatement): + (JSC::SyntaxChecker::createExprStatement): + (JSC::SyntaxChecker::createIfStatement): + (JSC::SyntaxChecker::createForLoop): + (JSC::SyntaxChecker::createForInLoop): + (JSC::SyntaxChecker::createEmptyStatement): + (JSC::SyntaxChecker::createVarStatement): + (JSC::SyntaxChecker::createReturnStatement): + (JSC::SyntaxChecker::createBreakStatement): + (JSC::SyntaxChecker::createContinueStatement): + (JSC::SyntaxChecker::createTryStatement): + (JSC::SyntaxChecker::createSwitchStatement): + (JSC::SyntaxChecker::createWhileStatement): + (JSC::SyntaxChecker::createWithStatement): + (JSC::SyntaxChecker::createDoWhileStatement): + (JSC::SyntaxChecker::createLabelStatement): + (JSC::SyntaxChecker::createThrowStatement): + (JSC::SyntaxChecker::createDebugger): + (JSC::SyntaxChecker::createConstStatement): + (JSC::SyntaxChecker::appendConstDecl): + (JSC::SyntaxChecker::createGetterOrSetterProperty): + (JSC::SyntaxChecker::combineCommaNodes): + (JSC::SyntaxChecker::operatorStackPop): + +2012-08-03 Filip Pizlo <fpizlo@apple.com> + + Crashes in dfgBuildPutByIdList when clicking on just about anything on Google Maps + https://bugs.webkit.org/show_bug.cgi?id=92691 + + Reviewed by Mark Hahnenberg. + + The state of the stubs was changing after we determined the type (by virtue of the slow path + function that was called), since the get or put (in this case put) could cause arbitrary + side effects. Perhaps a full-blown fix would be to eliminate our reliance of the slow path + function to determine what to do, but an easier fix for now is to have the slow path give up + if its assumptions were invalidated by a side effect. + + * dfg/DFGOperations.cpp: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + +2012-08-03 Filip Pizlo <fpizlo@apple.com> + + DFG handling of get_by_id should always inject a ForceOSRExit node if there is no prediction + https://bugs.webkit.org/show_bug.cgi?id=93162 + + Reviewed by Mark Hahnenberg. + + This simplifies the DFG IR by ensuring that all nodes that use value profiles will be preceded + by a ForceOSRExit if the value profile had no data. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + +2012-08-03 Filip Pizlo <fpizlo@apple.com> + + DFG::StructureCheckHoistingPhase keeps a Node& around for too long + https://bugs.webkit.org/show_bug.cgi?id=93157 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-02 Patrick Gansterer <paroga@webkit.org> + + Move getLocalTime() as static inline function to DateMath + https://bugs.webkit.org/show_bug.cgi?id=92955 + + Reviewed by Ryosuke Niwa. + + getCurrentLocalTime() and getLocalTime() has been superseded with the + GregorianDateTime class. So we can move it into DateMath.cpp as an static inline + function. This allows us to remove the dependecy on time() and localtime() + for Windows CE, where this functions require the ce_time library to work. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-02 Filip Pizlo <fpizlo@apple.com> + + ASSERTION FAILED: at(m_compileIndex).canExit() || m_isCheckingArgumentTypes + https://bugs.webkit.org/show_bug.cgi?id=91074 + + Reviewed by Mark Hahnenberg. + + Fixes a bug where the speculative JIT was performing an unnecessary speculation that the + CFA had proven shouldn't be performed, leading to asserts that a node should not have + exit sites. This is a debug-only assert with no release symptom - we were just emitting + a check that was not reachable. + + Also found, and fixed, a bug where structure check hoisting was slightly confusing the + CFA by inserting GetLocal's into the graph. CSE would clean the GetLocal's up, which + would make the backend happy - but the CFA would produce subtly wrong results. + + * bytecode/SpeculatedType.h: + (JSC::isOtherOrEmptySpeculation): + (JSC): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + +2012-08-02 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, build fix for DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE). + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-08-01 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove all uses of ClassInfo for JSStrings in JIT code + https://bugs.webkit.org/show_bug.cgi?id=92935 + + Reviewed by Geoffrey Garen. + + This is the first step in removing our dependence on in-object ClassInfo pointers + in JIT code. Most of the changes are to check the Structure, which is unique for + JSString primitives. + + * bytecode/SpeculatedType.cpp: + (JSC::speculationFromClassInfo): + (JSC::speculationFromStructure): Changed to check the TypeInfo in the Structure + since there wasn't a JSGlobalData immediately available to grab the JSString + Structure out of. + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITInlineMethods.h: + (JSC::JIT::emitLoadCharacterString): + * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::emit_op_to_primitive): + (JSC::JIT::emit_op_convert_this): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::emit_op_to_primitive): + (JSC::JIT::emitSlow_op_eq): + (JSC::JIT::emitSlow_op_neq): + (JSC::JIT::compileOpStrictEq): + (JSC::JIT::emit_op_convert_this): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::emitSlow_op_get_by_val): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::emitSlow_op_get_by_val): + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::loadJSStringArgument): + * jit/ThunkGenerators.cpp: + (JSC::stringCharLoad): + (JSC::charCodeAtThunkGenerator): + (JSC::charAtThunkGenerator): + +2012-08-02 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, missed a style goof in the previous patch: "NodeIndex nodeIndex" + in a method signature is painfully redundant. + + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2012-08-02 Filip Pizlo <fpizlo@apple.com> + + DFGSpeculativeJIT.h has too many inline method bodies + https://bugs.webkit.org/show_bug.cgi?id=92957 + + Reviewed by Antti Koivisto. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2012-08-01 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r124406. + http://trac.webkit.org/changeset/124406 + https://bugs.webkit.org/show_bug.cgi?id=92951 + + it set the Mac bots on fire (Requested by pizlo on #webkit). + + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ArrayNode::toArgumentList): + (JSC::ApplyFunctionCallDotNode::emitBytecode): + (JSC::ConditionalNode::emitBytecode): + (JSC::ConstStatementNode::emitBytecode): + (JSC::EmptyStatementNode::emitBytecode): + (JSC::DebuggerStatementNode::emitBytecode): + (JSC::ExprStatementNode::emitBytecode): + (JSC::VarStatementNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + (JSC::WithNode::emitBytecode): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + (JSC::ThrowNode::emitBytecode): + (JSC::TryNode::emitBytecode): + (JSC::ProgramNode::emitBytecode): + (JSC::EvalNode::emitBytecode): + (JSC::FunctionBodyNode::emitBytecode): + * debugger/Debugger.h: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): + (JSC::Interpreter::throwException): + (JSC::Interpreter::debug): + * interpreter/Interpreter.h: + (Interpreter): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::createCommaExpr): + (JSC::ASTBuilder::createLogicalNot): + (JSC::ASTBuilder::createUnaryPlus): + (JSC::ASTBuilder::createVoid): + (JSC::ASTBuilder::thisExpr): + (JSC::ASTBuilder::createResolve): + (JSC::ASTBuilder::createObjectLiteral): + (JSC::ASTBuilder::createArray): + (JSC::ASTBuilder::createNumberExpr): + (JSC::ASTBuilder::createString): + (JSC::ASTBuilder::createBoolean): + (JSC::ASTBuilder::createNull): + (JSC::ASTBuilder::createBracketAccess): + (JSC::ASTBuilder::createDotAccess): + (JSC::ASTBuilder::createRegExp): + (JSC::ASTBuilder::createNewExpr): + (JSC::ASTBuilder::createConditionalExpr): + (JSC::ASTBuilder::createAssignResolve): + (JSC::ASTBuilder::createFunctionExpr): + (JSC::ASTBuilder::createFunctionBody): + (JSC::ASTBuilder::createGetterOrSetterProperty): + (JSC::ASTBuilder::createArgumentsList): + (JSC::ASTBuilder::createPropertyList): + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::createBlockStatement): + (JSC::ASTBuilder::createExprStatement): + (JSC::ASTBuilder::createIfStatement): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::createEmptyStatement): + (JSC::ASTBuilder::createVarStatement): + (JSC::ASTBuilder::createReturnStatement): + (JSC::ASTBuilder::createBreakStatement): + (JSC::ASTBuilder::createContinueStatement): + (JSC::ASTBuilder::createTryStatement): + (JSC::ASTBuilder::createSwitchStatement): + (JSC::ASTBuilder::createWhileStatement): + (JSC::ASTBuilder::createDoWhileStatement): + (JSC::ASTBuilder::createLabelStatement): + (JSC::ASTBuilder::createWithStatement): + (JSC::ASTBuilder::createThrowStatement): + (JSC::ASTBuilder::createDebugger): + (JSC::ASTBuilder::createConstStatement): + (JSC::ASTBuilder::appendConstDecl): + (JSC::ASTBuilder::combineCommaNodes): + (JSC::ASTBuilder::appendBinaryOperation): + (JSC::ASTBuilder::createAssignment): + (JSC::ASTBuilder::createNumber): + (JSC::ASTBuilder::makeTypeOfNode): + (JSC::ASTBuilder::makeDeleteNode): + (JSC::ASTBuilder::makeNegateNode): + (JSC::ASTBuilder::makeBitwiseNotNode): + (JSC::ASTBuilder::makeMultNode): + (JSC::ASTBuilder::makeDivNode): + (JSC::ASTBuilder::makeModNode): + (JSC::ASTBuilder::makeAddNode): + (JSC::ASTBuilder::makeSubNode): + (JSC::ASTBuilder::makeLeftShiftNode): + (JSC::ASTBuilder::makeRightShiftNode): + (JSC::ASTBuilder::makeURightShiftNode): + (JSC::ASTBuilder::makeBitOrNode): + (JSC::ASTBuilder::makeBitAndNode): + (JSC::ASTBuilder::makeBitXOrNode): + (JSC::ASTBuilder::makeFunctionCallNode): + (JSC::ASTBuilder::makeBinaryNode): + (JSC::ASTBuilder::makeAssignNode): + (JSC::ASTBuilder::makePrefixNode): + (JSC::ASTBuilder::makePostfixNode): + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::internalShift): + (JSC::::shift): + (JSC::::lex): + * parser/Lexer.h: + (Lexer): + (JSC::::lexExpectIdentifier): + * parser/NodeConstructors.h: + (JSC::Node::Node): + (JSC::ExpressionNode::ExpressionNode): + (JSC::StatementNode::StatementNode): + (JSC::NullNode::NullNode): + (JSC::BooleanNode::BooleanNode): + (JSC::NumberNode::NumberNode): + (JSC::StringNode::StringNode): + (JSC::RegExpNode::RegExpNode): + (JSC::ThisNode::ThisNode): + (JSC::ResolveNode::ResolveNode): + (JSC::ArrayNode::ArrayNode): + (JSC::PropertyListNode::PropertyListNode): + (JSC::ObjectLiteralNode::ObjectLiteralNode): + (JSC::BracketAccessorNode::BracketAccessorNode): + (JSC::DotAccessorNode::DotAccessorNode): + (JSC::ArgumentListNode::ArgumentListNode): + (JSC::NewExprNode::NewExprNode): + (JSC::EvalFunctionCallNode::EvalFunctionCallNode): + (JSC::FunctionCallValueNode::FunctionCallValueNode): + (JSC::FunctionCallResolveNode::FunctionCallResolveNode): + (JSC::FunctionCallBracketNode::FunctionCallBracketNode): + (JSC::FunctionCallDotNode::FunctionCallDotNode): + (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): + (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): + (JSC::PrePostResolveNode::PrePostResolveNode): + (JSC::PostfixResolveNode::PostfixResolveNode): + (JSC::PostfixBracketNode::PostfixBracketNode): + (JSC::PostfixDotNode::PostfixDotNode): + (JSC::PostfixErrorNode::PostfixErrorNode): + (JSC::DeleteResolveNode::DeleteResolveNode): + (JSC::DeleteBracketNode::DeleteBracketNode): + (JSC::DeleteDotNode::DeleteDotNode): + (JSC::DeleteValueNode::DeleteValueNode): + (JSC::VoidNode::VoidNode): + (JSC::TypeOfResolveNode::TypeOfResolveNode): + (JSC::TypeOfValueNode::TypeOfValueNode): + (JSC::PrefixResolveNode::PrefixResolveNode): + (JSC::PrefixBracketNode::PrefixBracketNode): + (JSC::PrefixDotNode::PrefixDotNode): + (JSC::PrefixErrorNode::PrefixErrorNode): + (JSC::UnaryOpNode::UnaryOpNode): + (JSC::UnaryPlusNode::UnaryPlusNode): + (JSC::NegateNode::NegateNode): + (JSC::BitwiseNotNode::BitwiseNotNode): + (JSC::LogicalNotNode::LogicalNotNode): + (JSC::BinaryOpNode::BinaryOpNode): + (JSC::MultNode::MultNode): + (JSC::DivNode::DivNode): + (JSC::ModNode::ModNode): + (JSC::AddNode::AddNode): + (JSC::SubNode::SubNode): + (JSC::LeftShiftNode::LeftShiftNode): + (JSC::RightShiftNode::RightShiftNode): + (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): + (JSC::LessNode::LessNode): + (JSC::GreaterNode::GreaterNode): + (JSC::LessEqNode::LessEqNode): + (JSC::GreaterEqNode::GreaterEqNode): + (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): + (JSC::InstanceOfNode::InstanceOfNode): + (JSC::InNode::InNode): + (JSC::EqualNode::EqualNode): + (JSC::NotEqualNode::NotEqualNode): + (JSC::StrictEqualNode::StrictEqualNode): + (JSC::NotStrictEqualNode::NotStrictEqualNode): + (JSC::BitAndNode::BitAndNode): + (JSC::BitOrNode::BitOrNode): + (JSC::BitXOrNode::BitXOrNode): + (JSC::LogicalOpNode::LogicalOpNode): + (JSC::ConditionalNode::ConditionalNode): + (JSC::ReadModifyResolveNode::ReadModifyResolveNode): + (JSC::AssignResolveNode::AssignResolveNode): + (JSC::ReadModifyBracketNode::ReadModifyBracketNode): + (JSC::AssignBracketNode::AssignBracketNode): + (JSC::AssignDotNode::AssignDotNode): + (JSC::ReadModifyDotNode::ReadModifyDotNode): + (JSC::AssignErrorNode::AssignErrorNode): + (JSC::CommaNode::CommaNode): + (JSC::ConstStatementNode::ConstStatementNode): + (JSC::EmptyStatementNode::EmptyStatementNode): + (JSC::DebuggerStatementNode::DebuggerStatementNode): + (JSC::ExprStatementNode::ExprStatementNode): + (JSC::VarStatementNode::VarStatementNode): + (JSC::IfNode::IfNode): + (JSC::IfElseNode::IfElseNode): + (JSC::DoWhileNode::DoWhileNode): + (JSC::WhileNode::WhileNode): + (JSC::ForNode::ForNode): + (JSC::ContinueNode::ContinueNode): + (JSC::BreakNode::BreakNode): + (JSC::ReturnNode::ReturnNode): + (JSC::WithNode::WithNode): + (JSC::LabelNode::LabelNode): + (JSC::ThrowNode::ThrowNode): + (JSC::TryNode::TryNode): + (JSC::FuncExprNode::FuncExprNode): + (JSC::FuncDeclNode::FuncDeclNode): + (JSC::SwitchNode::SwitchNode): + (JSC::ConstDeclNode::ConstDeclNode): + (JSC::BlockNode::BlockNode): + (JSC::ForInNode::ForInNode): + * parser/Nodes.cpp: + (JSC): + (JSC::StatementNode::setLoc): + (JSC::ScopeNode::ScopeNode): + (JSC::ProgramNode::ProgramNode): + (JSC::ProgramNode::create): + (JSC::EvalNode::EvalNode): + (JSC::EvalNode::create): + (JSC::FunctionBodyNode::FunctionBodyNode): + (JSC::FunctionBodyNode::create): + * parser/Nodes.h: + (Node): + (ExpressionNode): + (StatementNode): + (NullNode): + (BooleanNode): + (NumberNode): + (StringNode): + (RegExpNode): + (ThisNode): + (ResolveNode): + (ArrayNode): + (PropertyListNode): + (ObjectLiteralNode): + (BracketAccessorNode): + (DotAccessorNode): + (ArgumentListNode): + (NewExprNode): + (EvalFunctionCallNode): + (FunctionCallValueNode): + (FunctionCallResolveNode): + (FunctionCallBracketNode): + (FunctionCallDotNode): + (CallFunctionCallDotNode): + (ApplyFunctionCallDotNode): + (PrePostResolveNode): + (PostfixResolveNode): + (PostfixBracketNode): + (PostfixDotNode): + (PostfixErrorNode): + (DeleteResolveNode): + (DeleteBracketNode): + (DeleteDotNode): + (DeleteValueNode): + (VoidNode): + (TypeOfResolveNode): + (TypeOfValueNode): + (PrefixResolveNode): + (PrefixBracketNode): + (PrefixDotNode): + (PrefixErrorNode): + (UnaryOpNode): + (UnaryPlusNode): + (NegateNode): + (BitwiseNotNode): + (LogicalNotNode): + (BinaryOpNode): + (MultNode): + (DivNode): + (ModNode): + (AddNode): + (SubNode): + (LeftShiftNode): + (RightShiftNode): + (UnsignedRightShiftNode): + (LessNode): + (GreaterNode): + (LessEqNode): + (GreaterEqNode): + (ThrowableBinaryOpNode): + (InstanceOfNode): + (InNode): + (EqualNode): + (NotEqualNode): + (StrictEqualNode): + (NotStrictEqualNode): + (BitAndNode): + (BitOrNode): + (BitXOrNode): + (LogicalOpNode): + (ConditionalNode): + (ReadModifyResolveNode): + (AssignResolveNode): + (ReadModifyBracketNode): + (AssignBracketNode): + (AssignDotNode): + (ReadModifyDotNode): + (AssignErrorNode): + (CommaNode): + (ConstDeclNode): + (ConstStatementNode): + (BlockNode): + (EmptyStatementNode): + (DebuggerStatementNode): + (ExprStatementNode): + (VarStatementNode): + (IfNode): + (IfElseNode): + (DoWhileNode): + (WhileNode): + (ForNode): + (ForInNode): + (ContinueNode): + (BreakNode): + (ReturnNode): + (WithNode): + (LabelNode): + (ThrowNode): + (TryNode): + (ScopeNode): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + (FuncExprNode): + (FuncDeclNode): + (SwitchNode): + * parser/Parser.cpp: + (JSC::::parseSourceElements): + (JSC::::parseVarDeclaration): + (JSC::::parseConstDeclaration): + (JSC::::parseDoWhileStatement): + (JSC::::parseWhileStatement): + (JSC::::parseVarDeclarationList): + (JSC::::parseConstDeclarationList): + (JSC::::parseForStatement): + (JSC::::parseBreakStatement): + (JSC::::parseContinueStatement): + (JSC::::parseReturnStatement): + (JSC::::parseThrowStatement): + (JSC::::parseWithStatement): + (JSC::::parseSwitchStatement): + (JSC::::parseTryStatement): + (JSC::::parseDebuggerStatement): + (JSC::::parseBlockStatement): + (JSC::::parseStatement): + (JSC::::parseFunctionBody): + (JSC::::parseFunctionInfo): + (JSC::::parseFunctionDeclaration): + (JSC::::parseExpressionOrLabelStatement): + (JSC::::parseExpressionStatement): + (JSC::::parseIfStatement): + (JSC::::parseExpression): + (JSC::::parseAssignmentExpression): + (JSC::::parseConditionalExpression): + (JSC::::parseBinaryExpression): + (JSC::::parseProperty): + (JSC::::parseObjectLiteral): + (JSC::::parseStrictObjectLiteral): + (JSC::::parseArrayLiteral): + (JSC::::parsePrimaryExpression): + (JSC::::parseArguments): + (JSC::::parseMemberExpression): + (JSC::::parseUnaryExpression): + * parser/Parser.h: + (JSC::Parser::next): + (JSC::Parser::nextExpectIdentifier): + (JSC::Parser::tokenStart): + (JSC::Parser::tokenLine): + (JSC::Parser::tokenEnd): + (JSC::Parser::getTokenName): + (JSC::::parse): + * parser/ParserTokens.h: + (JSC::JSTokenInfo::JSTokenInfo): + (JSTokenInfo): + (JSToken): + * parser/SourceProviderCacheItem.h: + (JSC::SourceProviderCacheItem::closeBraceToken): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::makeFunctionCallNode): + (JSC::SyntaxChecker::createCommaExpr): + (JSC::SyntaxChecker::makeAssignNode): + (JSC::SyntaxChecker::makePrefixNode): + (JSC::SyntaxChecker::makePostfixNode): + (JSC::SyntaxChecker::makeTypeOfNode): + (JSC::SyntaxChecker::makeDeleteNode): + (JSC::SyntaxChecker::makeNegateNode): + (JSC::SyntaxChecker::makeBitwiseNotNode): + (JSC::SyntaxChecker::createLogicalNot): + (JSC::SyntaxChecker::createUnaryPlus): + (JSC::SyntaxChecker::createVoid): + (JSC::SyntaxChecker::thisExpr): + (JSC::SyntaxChecker::createResolve): + (JSC::SyntaxChecker::createObjectLiteral): + (JSC::SyntaxChecker::createArray): + (JSC::SyntaxChecker::createNumberExpr): + (JSC::SyntaxChecker::createString): + (JSC::SyntaxChecker::createBoolean): + (JSC::SyntaxChecker::createNull): + (JSC::SyntaxChecker::createBracketAccess): + (JSC::SyntaxChecker::createDotAccess): + (JSC::SyntaxChecker::createRegExp): + (JSC::SyntaxChecker::createNewExpr): + (JSC::SyntaxChecker::createConditionalExpr): + (JSC::SyntaxChecker::createAssignResolve): + (JSC::SyntaxChecker::createFunctionExpr): + (JSC::SyntaxChecker::createFunctionBody): + (JSC::SyntaxChecker::createArgumentsList): + (JSC::SyntaxChecker::createPropertyList): + (JSC::SyntaxChecker::createFuncDeclStatement): + (JSC::SyntaxChecker::createBlockStatement): + (JSC::SyntaxChecker::createExprStatement): + (JSC::SyntaxChecker::createIfStatement): + (JSC::SyntaxChecker::createForLoop): + (JSC::SyntaxChecker::createForInLoop): + (JSC::SyntaxChecker::createEmptyStatement): + (JSC::SyntaxChecker::createVarStatement): + (JSC::SyntaxChecker::createReturnStatement): + (JSC::SyntaxChecker::createBreakStatement): + (JSC::SyntaxChecker::createContinueStatement): + (JSC::SyntaxChecker::createTryStatement): + (JSC::SyntaxChecker::createSwitchStatement): + (JSC::SyntaxChecker::createWhileStatement): + (JSC::SyntaxChecker::createWithStatement): + (JSC::SyntaxChecker::createDoWhileStatement): + (JSC::SyntaxChecker::createLabelStatement): + (JSC::SyntaxChecker::createThrowStatement): + (JSC::SyntaxChecker::createDebugger): + (JSC::SyntaxChecker::createConstStatement): + (JSC::SyntaxChecker::appendConstDecl): + (JSC::SyntaxChecker::createGetterOrSetterProperty): + (JSC::SyntaxChecker::combineCommaNodes): + (JSC::SyntaxChecker::operatorStackPop): + +2012-08-01 Peter Wang <peter.wang@torchmobile.com.cn> + + Web Inspector: [JSC] implement setting breakpoints by line:column + https://bugs.webkit.org/show_bug.cgi?id=53003 + + Reviewed by Geoffrey Garen. + + Add a counter in lexer to record the column of each token. Debugger will use column info + in "Pretty Print" debug mode of Inspector. + + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ArrayNode::toArgumentList): + (JSC::ApplyFunctionCallDotNode::emitBytecode): + (JSC::ConditionalNode::emitBytecode): + (JSC::ConstStatementNode::emitBytecode): + (JSC::EmptyStatementNode::emitBytecode): + (JSC::DebuggerStatementNode::emitBytecode): + (JSC::ExprStatementNode::emitBytecode): + (JSC::VarStatementNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + (JSC::WithNode::emitBytecode): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + (JSC::ThrowNode::emitBytecode): + (JSC::TryNode::emitBytecode): + (JSC::ProgramNode::emitBytecode): + (JSC::EvalNode::emitBytecode): + (JSC::FunctionBodyNode::emitBytecode): + * debugger/Debugger.h: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::unwindCallFrame): + (JSC::Interpreter::throwException): + (JSC::Interpreter::debug): + * interpreter/Interpreter.h: + (Interpreter): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_debug): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::createCommaExpr): + (JSC::ASTBuilder::createLogicalNot): + (JSC::ASTBuilder::createUnaryPlus): + (JSC::ASTBuilder::createVoid): + (JSC::ASTBuilder::thisExpr): + (JSC::ASTBuilder::createResolve): + (JSC::ASTBuilder::createObjectLiteral): + (JSC::ASTBuilder::createArray): + (JSC::ASTBuilder::createNumberExpr): + (JSC::ASTBuilder::createString): + (JSC::ASTBuilder::createBoolean): + (JSC::ASTBuilder::createNull): + (JSC::ASTBuilder::createBracketAccess): + (JSC::ASTBuilder::createDotAccess): + (JSC::ASTBuilder::createRegExp): + (JSC::ASTBuilder::createNewExpr): + (JSC::ASTBuilder::createConditionalExpr): + (JSC::ASTBuilder::createAssignResolve): + (JSC::ASTBuilder::createFunctionExpr): + (JSC::ASTBuilder::createFunctionBody): + (JSC::ASTBuilder::createGetterOrSetterProperty): + (JSC::ASTBuilder::createArgumentsList): + (JSC::ASTBuilder::createPropertyList): + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::createBlockStatement): + (JSC::ASTBuilder::createExprStatement): + (JSC::ASTBuilder::createIfStatement): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::createEmptyStatement): + (JSC::ASTBuilder::createVarStatement): + (JSC::ASTBuilder::createReturnStatement): + (JSC::ASTBuilder::createBreakStatement): + (JSC::ASTBuilder::createContinueStatement): + (JSC::ASTBuilder::createTryStatement): + (JSC::ASTBuilder::createSwitchStatement): + (JSC::ASTBuilder::createWhileStatement): + (JSC::ASTBuilder::createDoWhileStatement): + (JSC::ASTBuilder::createLabelStatement): + (JSC::ASTBuilder::createWithStatement): + (JSC::ASTBuilder::createThrowStatement): + (JSC::ASTBuilder::createDebugger): + (JSC::ASTBuilder::createConstStatement): + (JSC::ASTBuilder::appendConstDecl): + (JSC::ASTBuilder::combineCommaNodes): + (JSC::ASTBuilder::appendBinaryOperation): + (JSC::ASTBuilder::createAssignment): + (JSC::ASTBuilder::createNumber): + (JSC::ASTBuilder::makeTypeOfNode): + (JSC::ASTBuilder::makeDeleteNode): + (JSC::ASTBuilder::makeNegateNode): + (JSC::ASTBuilder::makeBitwiseNotNode): + (JSC::ASTBuilder::makeMultNode): + (JSC::ASTBuilder::makeDivNode): + (JSC::ASTBuilder::makeModNode): + (JSC::ASTBuilder::makeAddNode): + (JSC::ASTBuilder::makeSubNode): + (JSC::ASTBuilder::makeLeftShiftNode): + (JSC::ASTBuilder::makeRightShiftNode): + (JSC::ASTBuilder::makeURightShiftNode): + (JSC::ASTBuilder::makeBitOrNode): + (JSC::ASTBuilder::makeBitAndNode): + (JSC::ASTBuilder::makeBitXOrNode): + (JSC::ASTBuilder::makeFunctionCallNode): + (JSC::ASTBuilder::makeBinaryNode): + (JSC::ASTBuilder::makeAssignNode): + (JSC::ASTBuilder::makePrefixNode): + (JSC::ASTBuilder::makePostfixNode): + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::internalShift): + (JSC::::shift): + (JSC::::lex): + * parser/Lexer.h: + (Lexer): + (JSC::Lexer::currentColumnNumber): + (JSC::::lexExpectIdentifier): + * parser/NodeConstructors.h: + (JSC::Node::Node): + (JSC::ExpressionNode::ExpressionNode): + (JSC::StatementNode::StatementNode): + (JSC::NullNode::NullNode): + (JSC::BooleanNode::BooleanNode): + (JSC::NumberNode::NumberNode): + (JSC::StringNode::StringNode): + (JSC::RegExpNode::RegExpNode): + (JSC::ThisNode::ThisNode): + (JSC::ResolveNode::ResolveNode): + (JSC::ArrayNode::ArrayNode): + (JSC::PropertyListNode::PropertyListNode): + (JSC::ObjectLiteralNode::ObjectLiteralNode): + (JSC::BracketAccessorNode::BracketAccessorNode): + (JSC::DotAccessorNode::DotAccessorNode): + (JSC::ArgumentListNode::ArgumentListNode): + (JSC::NewExprNode::NewExprNode): + (JSC::EvalFunctionCallNode::EvalFunctionCallNode): + (JSC::FunctionCallValueNode::FunctionCallValueNode): + (JSC::FunctionCallResolveNode::FunctionCallResolveNode): + (JSC::FunctionCallBracketNode::FunctionCallBracketNode): + (JSC::FunctionCallDotNode::FunctionCallDotNode): + (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): + (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): + (JSC::PrePostResolveNode::PrePostResolveNode): + (JSC::PostfixResolveNode::PostfixResolveNode): + (JSC::PostfixBracketNode::PostfixBracketNode): + (JSC::PostfixDotNode::PostfixDotNode): + (JSC::PostfixErrorNode::PostfixErrorNode): + (JSC::DeleteResolveNode::DeleteResolveNode): + (JSC::DeleteBracketNode::DeleteBracketNode): + (JSC::DeleteDotNode::DeleteDotNode): + (JSC::DeleteValueNode::DeleteValueNode): + (JSC::VoidNode::VoidNode): + (JSC::TypeOfResolveNode::TypeOfResolveNode): + (JSC::TypeOfValueNode::TypeOfValueNode): + (JSC::PrefixResolveNode::PrefixResolveNode): + (JSC::PrefixBracketNode::PrefixBracketNode): + (JSC::PrefixDotNode::PrefixDotNode): + (JSC::PrefixErrorNode::PrefixErrorNode): + (JSC::UnaryOpNode::UnaryOpNode): + (JSC::UnaryPlusNode::UnaryPlusNode): + (JSC::NegateNode::NegateNode): + (JSC::BitwiseNotNode::BitwiseNotNode): + (JSC::LogicalNotNode::LogicalNotNode): + (JSC::BinaryOpNode::BinaryOpNode): + (JSC::MultNode::MultNode): + (JSC::DivNode::DivNode): + (JSC::ModNode::ModNode): + (JSC::AddNode::AddNode): + (JSC::SubNode::SubNode): + (JSC::LeftShiftNode::LeftShiftNode): + (JSC::RightShiftNode::RightShiftNode): + (JSC::UnsignedRightShiftNode::UnsignedRightShiftNode): + (JSC::LessNode::LessNode): + (JSC::GreaterNode::GreaterNode): + (JSC::LessEqNode::LessEqNode): + (JSC::GreaterEqNode::GreaterEqNode): + (JSC::ThrowableBinaryOpNode::ThrowableBinaryOpNode): + (JSC::InstanceOfNode::InstanceOfNode): + (JSC::InNode::InNode): + (JSC::EqualNode::EqualNode): + (JSC::NotEqualNode::NotEqualNode): + (JSC::StrictEqualNode::StrictEqualNode): + (JSC::NotStrictEqualNode::NotStrictEqualNode): + (JSC::BitAndNode::BitAndNode): + (JSC::BitOrNode::BitOrNode): + (JSC::BitXOrNode::BitXOrNode): + (JSC::LogicalOpNode::LogicalOpNode): + (JSC::ConditionalNode::ConditionalNode): + (JSC::ReadModifyResolveNode::ReadModifyResolveNode): + (JSC::AssignResolveNode::AssignResolveNode): + (JSC::ReadModifyBracketNode::ReadModifyBracketNode): + (JSC::AssignBracketNode::AssignBracketNode): + (JSC::AssignDotNode::AssignDotNode): + (JSC::ReadModifyDotNode::ReadModifyDotNode): + (JSC::AssignErrorNode::AssignErrorNode): + (JSC::CommaNode::CommaNode): + (JSC::ConstStatementNode::ConstStatementNode): + (JSC::EmptyStatementNode::EmptyStatementNode): + (JSC::DebuggerStatementNode::DebuggerStatementNode): + (JSC::ExprStatementNode::ExprStatementNode): + (JSC::VarStatementNode::VarStatementNode): + (JSC::IfNode::IfNode): + (JSC::IfElseNode::IfElseNode): + (JSC::DoWhileNode::DoWhileNode): + (JSC::WhileNode::WhileNode): + (JSC::ForNode::ForNode): + (JSC::ContinueNode::ContinueNode): + (JSC::BreakNode::BreakNode): + (JSC::ReturnNode::ReturnNode): + (JSC::WithNode::WithNode): + (JSC::LabelNode::LabelNode): + (JSC::ThrowNode::ThrowNode): + (JSC::TryNode::TryNode): + (JSC::FuncExprNode::FuncExprNode): + (JSC::FuncDeclNode::FuncDeclNode): + (JSC::SwitchNode::SwitchNode): + (JSC::ConstDeclNode::ConstDeclNode): + (JSC::BlockNode::BlockNode): + (JSC::ForInNode::ForInNode): + * parser/Nodes.cpp: + (JSC::StatementNode::setLoc): + (JSC): + (JSC::ScopeNode::ScopeNode): + (JSC::ProgramNode::ProgramNode): + (JSC::ProgramNode::create): + (JSC::EvalNode::EvalNode): + (JSC::EvalNode::create): + (JSC::FunctionBodyNode::FunctionBodyNode): + (JSC::FunctionBodyNode::create): + * parser/Nodes.h: + (Node): + (JSC::Node::columnNo): + (ExpressionNode): + (StatementNode): + (JSC::StatementNode::column): + (NullNode): + (BooleanNode): + (NumberNode): + (StringNode): + (RegExpNode): + (ThisNode): + (ResolveNode): + (ArrayNode): + (PropertyListNode): + (ObjectLiteralNode): + (BracketAccessorNode): + (DotAccessorNode): + (ArgumentListNode): + (NewExprNode): + (EvalFunctionCallNode): + (FunctionCallValueNode): + (FunctionCallResolveNode): + (FunctionCallBracketNode): + (FunctionCallDotNode): + (CallFunctionCallDotNode): + (ApplyFunctionCallDotNode): + (PrePostResolveNode): + (PostfixResolveNode): + (PostfixBracketNode): + (PostfixDotNode): + (PostfixErrorNode): + (DeleteResolveNode): + (DeleteBracketNode): + (DeleteDotNode): + (DeleteValueNode): + (VoidNode): + (TypeOfResolveNode): + (TypeOfValueNode): + (PrefixResolveNode): + (PrefixBracketNode): + (PrefixDotNode): + (PrefixErrorNode): + (UnaryOpNode): + (UnaryPlusNode): + (NegateNode): + (BitwiseNotNode): + (LogicalNotNode): + (BinaryOpNode): + (MultNode): + (DivNode): + (ModNode): + (AddNode): + (SubNode): + (LeftShiftNode): + (RightShiftNode): + (UnsignedRightShiftNode): + (LessNode): + (GreaterNode): + (LessEqNode): + (GreaterEqNode): + (ThrowableBinaryOpNode): + (InstanceOfNode): + (InNode): + (EqualNode): + (NotEqualNode): + (StrictEqualNode): + (NotStrictEqualNode): + (BitAndNode): + (BitOrNode): + (BitXOrNode): + (LogicalOpNode): + (ConditionalNode): + (ReadModifyResolveNode): + (AssignResolveNode): + (ReadModifyBracketNode): + (AssignBracketNode): + (AssignDotNode): + (ReadModifyDotNode): + (AssignErrorNode): + (CommaNode): + (ConstDeclNode): + (ConstStatementNode): + (BlockNode): + (EmptyStatementNode): + (DebuggerStatementNode): + (ExprStatementNode): + (VarStatementNode): + (IfNode): + (IfElseNode): + (DoWhileNode): + (WhileNode): + (ForNode): + (ForInNode): + (ContinueNode): + (BreakNode): + (ReturnNode): + (WithNode): + (LabelNode): + (ThrowNode): + (TryNode): + (ScopeNode): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + (FuncExprNode): + (FuncDeclNode): + (SwitchNode): + * parser/Parser.cpp: + (JSC::::parseSourceElements): + (JSC::::parseVarDeclaration): + (JSC::::parseConstDeclaration): + (JSC::::parseDoWhileStatement): + (JSC::::parseWhileStatement): + (JSC::::parseVarDeclarationList): + (JSC::::parseConstDeclarationList): + (JSC::::parseForStatement): + (JSC::::parseBreakStatement): + (JSC::::parseContinueStatement): + (JSC::::parseReturnStatement): + (JSC::::parseThrowStatement): + (JSC::::parseWithStatement): + (JSC::::parseSwitchStatement): + (JSC::::parseTryStatement): + (JSC::::parseDebuggerStatement): + (JSC::::parseBlockStatement): + (JSC::::parseStatement): + (JSC::::parseFunctionBody): + (JSC::::parseFunctionInfo): + (JSC::::parseFunctionDeclaration): + (JSC::::parseExpressionOrLabelStatement): + (JSC::::parseExpressionStatement): + (JSC::::parseIfStatement): + (JSC::::parseExpression): + (JSC::::parseAssignmentExpression): + (JSC::::parseConditionalExpression): + (JSC::::parseBinaryExpression): + (JSC::::parseProperty): + (JSC::::parseObjectLiteral): + (JSC::::parseStrictObjectLiteral): + (JSC::::parseArrayLiteral): + (JSC::::parsePrimaryExpression): + (JSC::::parseArguments): + (JSC::::parseMemberExpression): + (JSC::::parseUnaryExpression): + * parser/Parser.h: + (JSC::Parser::next): + (JSC::Parser::nextExpectIdentifier): + (JSC::Parser::tokenStart): + (JSC::Parser::tokenLine): + (JSC::Parser::tokenEnd): + (JSC::Parser::tokenLocation): + (Parser): + (JSC::Parser::getTokenName): + (JSC::::parse): + * parser/ParserTokens.h: + (JSC::JSTokenLocation::JSTokenLocation): + (JSTokenLocation): + (JSToken): + * parser/SourceProviderCacheItem.h: + (JSC::SourceProviderCacheItem::closeBraceToken): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::makeFunctionCallNode): + (JSC::SyntaxChecker::createCommaExpr): + (JSC::SyntaxChecker::makeAssignNode): + (JSC::SyntaxChecker::makePrefixNode): + (JSC::SyntaxChecker::makePostfixNode): + (JSC::SyntaxChecker::makeTypeOfNode): + (JSC::SyntaxChecker::makeDeleteNode): + (JSC::SyntaxChecker::makeNegateNode): + (JSC::SyntaxChecker::makeBitwiseNotNode): + (JSC::SyntaxChecker::createLogicalNot): + (JSC::SyntaxChecker::createUnaryPlus): + (JSC::SyntaxChecker::createVoid): + (JSC::SyntaxChecker::thisExpr): + (JSC::SyntaxChecker::createResolve): + (JSC::SyntaxChecker::createObjectLiteral): + (JSC::SyntaxChecker::createArray): + (JSC::SyntaxChecker::createNumberExpr): + (JSC::SyntaxChecker::createString): + (JSC::SyntaxChecker::createBoolean): + (JSC::SyntaxChecker::createNull): + (JSC::SyntaxChecker::createBracketAccess): + (JSC::SyntaxChecker::createDotAccess): + (JSC::SyntaxChecker::createRegExp): + (JSC::SyntaxChecker::createNewExpr): + (JSC::SyntaxChecker::createConditionalExpr): + (JSC::SyntaxChecker::createAssignResolve): + (JSC::SyntaxChecker::createFunctionExpr): + (JSC::SyntaxChecker::createFunctionBody): + (JSC::SyntaxChecker::createArgumentsList): + (JSC::SyntaxChecker::createPropertyList): + (JSC::SyntaxChecker::createFuncDeclStatement): + (JSC::SyntaxChecker::createBlockStatement): + (JSC::SyntaxChecker::createExprStatement): + (JSC::SyntaxChecker::createIfStatement): + (JSC::SyntaxChecker::createForLoop): + (JSC::SyntaxChecker::createForInLoop): + (JSC::SyntaxChecker::createEmptyStatement): + (JSC::SyntaxChecker::createVarStatement): + (JSC::SyntaxChecker::createReturnStatement): + (JSC::SyntaxChecker::createBreakStatement): + (JSC::SyntaxChecker::createContinueStatement): + (JSC::SyntaxChecker::createTryStatement): + (JSC::SyntaxChecker::createSwitchStatement): + (JSC::SyntaxChecker::createWhileStatement): + (JSC::SyntaxChecker::createWithStatement): + (JSC::SyntaxChecker::createDoWhileStatement): + (JSC::SyntaxChecker::createLabelStatement): + (JSC::SyntaxChecker::createThrowStatement): + (JSC::SyntaxChecker::createDebugger): + (JSC::SyntaxChecker::createConstStatement): + (JSC::SyntaxChecker::appendConstDecl): + (JSC::SyntaxChecker::createGetterOrSetterProperty): + (JSC::SyntaxChecker::combineCommaNodes): + (JSC::SyntaxChecker::operatorStackPop): + +2012-08-01 Filip Pizlo <fpizlo@apple.com> + + DFG should hoist structure checks + https://bugs.webkit.org/show_bug.cgi?id=92696 + + Reviewed by Gavin Barraclough. + + This hoists structure checks in the same way that we would hoist array checks, but with added + complexity to cope with the fact that the structure of an object may change. This is handled + by performing a side effects analysis over the region in which the respective variable is + live. If a structure clobbering side effect may happen then we either hoist the structure + checks and fall back on structure transition watchpoints (if the watchpoint set is still + valid), or we avoid hoisting altogether. + + Doing this required teaching the CFA that we may have an expectation that an object has a + particular structure even after structure clobbering happens, in the sense that structure + proofs that were cobbered can be revived using watchpoints. CFA must know about this so that + OSR entry may know about it, since we cannot allow entry to happen if the variable has a + clobbered structure proof, will have a watchpoint to revive the proof, and the variable in + the baseline JIT has a completely unrelated structure. + + This is mostly performance neutral. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::isSet): + (JSC::ValueRecovery::operator!): + (ValueRecovery): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::clobberWorld): + (DFG): + (JSC::DFG::AbstractState::clobberCapturedVars): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::clear): + (JSC::DFG::AbstractValue::isClear): + (JSC::DFG::AbstractValue::makeTop): + (JSC::DFG::AbstractValue::isTop): + (JSC::DFG::AbstractValue::set): + (JSC::DFG::AbstractValue::operator==): + (JSC::DFG::AbstractValue::merge): + (JSC::DFG::AbstractValue::filter): + (JSC::DFG::AbstractValue::validate): + (JSC::DFG::AbstractValue::validateForEntry): + (AbstractValue): + (JSC::DFG::AbstractValue::checkConsistency): + (JSC::DFG::AbstractValue::dump): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::checkStructureLoadElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::vote): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToStructureTransitionWatchpoint): + (Node): + (JSC::DFG::Node::hasStructureSet): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::speculationCheckWithConditionalDirection): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::gpr): + (SpeculateCellOperand): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: Added. + (DFG): + (StructureCheckHoistingPhase): + (JSC::DFG::StructureCheckHoistingPhase::StructureCheckHoistingPhase): + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + (JSC::DFG::StructureCheckHoistingPhase::clobber): + (CheckData): + (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData): + (JSC::DFG::performStructureCheckHoisting): + * dfg/DFGStructureCheckHoistingPhase.h: Added. + (DFG): + * dfg/DFGVariableAccessData.h: + (VariableAccessData): + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeStructureCheckHoistingFailed): + (JSC::DFG::VariableAccessData::structureCheckHoistingFailed): + (JSC::DFG::VariableAccessData::clearVotes): + (JSC::DFG::VariableAccessData::vote): + (JSC::DFG::VariableAccessData::voteRatio): + (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): + * runtime/Options.h: + (JSC): + +2012-08-01 Filip Pizlo <fpizlo@apple.com> + + DFG should distinguish between PutByVal's that clobber the world and ones that don't + https://bugs.webkit.org/show_bug.cgi?id=92923 + + Reviewed by Mark Hahnenberg. + + This is performance-neutral. I also confirmed that it's neutral if we make the + clobbering variant (PutByValSafe) clobber all knowledge of what is an array, + which should feed nicely into work on removing uses of ClassInfo. + + * bytecode/DFGExitProfile.h: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkStructureLoadElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + (JSC::DFG::CSEPhase::putByOffsetStoreElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-08-01 Jian Li <jianli@chromium.org> + + Add new CSS property "-webkit-widget-region" to expose dashboard region support for other port + https://bugs.webkit.org/show_bug.cgi?id=90298 + + Reviewed by Adam Barth. + + * Configurations/FeatureDefines.xcconfig: Add ENABLE_WIDGET_REGION define. + +2012-08-01 Patrick Gansterer <paroga@webkit.org> + + Replace WTF::getCurrentLocalTime() with GregorianDateTime::setToCurrentLocalTime() + https://bugs.webkit.org/show_bug.cgi?id=92286 + + Reviewed by Geoffrey Garen. + + Add a method to GregorianDateTime to set its values to the current locale time. + Replacing all occurrences of getCurrentLocalTime with the new function allows + us to remove getCurrentLocalTime in a next step. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-08-01 Mark Hahnenberg <mhahnenberg@apple.com> + + C++ code should get ClassInfo from the Structure + https://bugs.webkit.org/show_bug.cgi?id=92892 + + Reviewed by Geoffrey Garen. + + In our march to remove ClassInfo from our JSCell object headers, we can switch + C++ code over to grabbing the ClassInfo from the Structure since it is finally + safe to do so now that Structure access is safe during finalization/destruction. + The remaining JIT code changes can be done in a separate patch. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::callDestructor): We don't want to clear the Structure any more + since the Structure should still be valid at this point. + * heap/WeakSetInlines.h: + (JSC::WeakBlock::finalize): Ditto. + * runtime/JSCell.h: + (JSC): + * runtime/Structure.h: + (JSC::JSCell::classInfo): Move JSCell's classInfo() to Structure.h so it can be + inline. Use a different method of getting the JSCell's Structure based on + whether we're in GC_VALIDATION mode or not, since always using get() will cause + infinite recursion in GC_VALIDATION mode. + (JSC): + +2012-07-31 Mark Hahnenberg <mhahnenberg@apple.com> + + MarkedBlock::sweep() should sweep another block if it can't sweep a Structure block + https://bugs.webkit.org/show_bug.cgi?id=92819 + + Reviewed by Geoffrey Garen. + + If we are forced to allocate a new block for Structures because we are unable to safely + sweep our pre-existing Structure blocks, we should sweep another random block so that we + can start sweeping Structure blocks sooner. + + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doSweep): Change to use sweepNextBlock. + (JSC): + (JSC::IncrementalSweeper::sweepNextBlock): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): When we can't safely sweep + our Structure blocks, call sweepNextBlock instead. + +2012-07-31 Sam Weinig <sam@webkit.org> + + Fix the Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Maybe fix the GCC build. + + * heap/HeapBlock.h: + (HeapBlock): Accommodate incorrect parsing in GCC. + +2012-07-31 Sam Weinig <sam@webkit.org> + + Stop masking 8 bits off of the visited link hash. We need all the bits! + https://bugs.webkit.org/show_bug.cgi?id=92799 + + Reviewed by Anders Carlsson. + + * runtime/Identifier.cpp: + (JSC::IdentifierCStringTranslator::hash): + (JSC::IdentifierLCharFromUCharTranslator::hash): + * runtime/Identifier.h: + (JSC::IdentifierCharBufferTranslator::hash): + Update for new function names. + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Maybe break the Windows build. + + Reviewed by Anders Carlsson. + + Formally objected to by Sam Weinig. + + * heap/HeapBlock.h: + (HeapBlock): Try to slightly improve this because we don't want Windows to control our lives. + +2012-07-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Structures should be swept after all other objects + https://bugs.webkit.org/show_bug.cgi?id=92679 + + Reviewed by Filip Pizlo. + + In order to get rid of ClassInfo from our objects, we need to be able to safely get the + ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the + Structure, but currently it is not safe to do so because the order of destruction of objects + is not guaranteed to sweep objects before their corresponding Structure. We can fix this by + sweeping Structures after everything else. + + * heap/Heap.cpp: + (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures. + If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is + safe to sweep structures since we'll always do Structures last anyways due to the ordering of + MarkedSpace::forEachBlock. + (JSC): + (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now + calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out + these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() + calls during lastChanceToFinalize(). + * heap/Heap.h: + (Heap): + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures. + This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping + the first time. + (JSC): + (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we + make our first pass. We now null out the slots as we sweep them so that we can quickly find the + Structures during the second pass. + (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index. + (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify + the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can + assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock + iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds. + (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index. + * heap/IncrementalSweeper.h: Add declarations for new stuff. + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and + if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing + the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that + will sweep some number of other blocks in place of the current block to mitigate the cost of the floating + Structure garbage. + (JSC::MarkedAllocator::addBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no + longer valid to allocate from, so we set the current block to null. + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures + at an unsafe time. + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping. + (JSC): + * heap/MarkedSpace.h: + (JSC): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown. + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Fix all the other builds I just broke. Maybe fix the Windows build. + + * heap/HeapBlock.h: + (HeapBlock): WTF? + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Maybe fix the Windows build. + + * heap/HeapBlock.h: + (HeapBlock): WTF? + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Maybe fix the Windows build. + + * heap/HeapBlock.h: + (HeapBlock): WTF? + +2012-07-31 Geoffrey Garen <ggaren@apple.com> + + Removed some public data and casting from the Heap + https://bugs.webkit.org/show_bug.cgi?id=92777 + + Reviewed by Oliver Hunt. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::releaseFreeBlocks): + (JSC::BlockAllocator::blockFreeingThreadMain): Use the DeadBlock class + since HeapBlock is a template, and not a class, now. Call destroy() + instead of monkeying around with DeadBlock's internal data because + encapsulation is good. + + * heap/BlockAllocator.h: + (DeadBlock): Added a class to represent a dead block, since HeapBlock is + a template now, and can't be instantiated directly. + + (JSC::DeadBlock::DeadBlock): + (JSC::DeadBlock::create): + (BlockAllocator): + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::deallocate): Use the DeadBlock class because + encapsulation is good. + + * heap/CopiedBlock.h: + (CopiedBlock::destroy): No need for a destroy() function, since we + inherit one now. + + (JSC::CopiedBlock::CopiedBlock): + (JSC::CopiedBlock::payloadEnd): + (JSC::CopiedBlock::capacity): Updated for some encapsulation inside + HeapBlock. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::~CopiedSpace): + (JSC::CopiedSpace::doneCopying): + (JSC::CopiedSpace::size): + (JSC::CopiedSpace::capacity): + (JSC::isBlockListPagedOut): Removed a bunch of casting. This is no longer + necessary, now that our list and its nodes have the right type. + + * heap/CopiedSpace.h: Use the right type in our data structures because + it improves clarity. + + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::startedCopying): Use swap to avoid duplicating it. + + * heap/HeapBlock.h: + (HeapBlock): Made this a class template so we can return the right type + in linked list operations. Made our data private because encapsulation + is good. + + (JSC::HeapBlock::destroy): Since we know our type, we can also eliminate + duplicate destroy() functions in our subclasses. + + (JSC::HeapBlock::allocation): Added an accessor so we can hide our data. + By using const, this accessor prevents clients from accidentally deleting + our allocation. + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::isPagedOut): + (JSC::MarkedAllocator::tryAllocateHelper): + (JSC::MarkedAllocator::removeBlock): Removed a bunch of casting. This is + no longer necessary, now that our list and its nodes have the right type. + + * heap/MarkedAllocator.h: + (MarkedAllocator): + (JSC::MarkedAllocator::reset): + (JSC::MarkedAllocator::forEachBlock): Use the right type, do less casting. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::destroy): Removed this function because our parent + class provides it for us now. + + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::capacity): Updated for encapsulation. + +2012-07-31 Filip Pizlo <fpizlo@apple.com> + + DFG OSR exit profiling has unusual oversights + https://bugs.webkit.org/show_bug.cgi?id=92728 + + Reviewed by Geoffrey Garen. + + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-07-31 Chao-ying Fu <fu@mips.com> + + Add MIPS add32 function + https://bugs.webkit.org/show_bug.cgi?id=91522 + + Reviewed by Oliver Hunt. + + Add isCompactPtrAlignedAddressOffset. + Add a new version of add32 that accepts AbsoluteAddress as inputs. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::isCompactPtrAlignedAddressOffset): New. + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::add32): Support AbsoluteAddress as inputs. + +2012-07-30 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r124123. + http://trac.webkit.org/changeset/124123 + https://bugs.webkit.org/show_bug.cgi?id=92700 + + ASSERT crashes terminate webkit Layout tests (Requested by + msaboff on #webkit). + + * heap/Heap.cpp: + * heap/Heap.h: + (Heap): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doSweep): + (JSC::IncrementalSweeper::startSweeping): + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): + (JSC::MarkedAllocator::addBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::zapFreeList): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweepHelper): + * heap/MarkedSpace.cpp: + * heap/MarkedSpace.h: + (JSC::MarkedSpace::sweep): + (JSC): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::~JSGlobalData): + +2012-07-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Structures should be swept after all other objects + https://bugs.webkit.org/show_bug.cgi?id=92679 + + Reviewed by Filip Pizlo. + + In order to get rid of ClassInfo from our objects, we need to be able to safely get the + ClassInfo during the destruction of objects. We'd like to get the ClassInfo out of the + Structure, but currently it is not safe to do so because the order of destruction of objects + is not guaranteed to sweep objects before their corresponding Structure. We can fix this by + sweeping Structures after everything else. + + * heap/Heap.cpp: + (JSC::Heap::isSafeToSweepStructures): Add a function that checks if it is safe to sweep Structures. + If the Heap's IncrementalSweeper member is null, that means we're shutting down this VM and it is + safe to sweep structures since we'll always do Structures last anyways due to the ordering of + MarkedSpace::forEachBlock. + (JSC): + (JSC::Heap::didStartVMShutdown): Add this intermediate function to the Heap that ~JSGlobalData now + calls rather than calling the two HeapTimer objects individually. This allows the Heap to null out + these pointers after it has invalidated them to prevent accidental use-after-free in the sweep() + calls during lastChanceToFinalize(). + * heap/Heap.h: + (Heap): + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::structuresCanBeSwept): Determines if it is currently safe to sweep Structures. + This decision is based on whether we have gotten to the end of the vector of blocks that need sweeping + the first time. + (JSC): + (JSC::IncrementalSweeper::doSweep): We add a second pass over the vector to sweep Structures after we + make our first pass. We now null out the slots as we sweep them so that we can quickly find the + Structures during the second pass. + (JSC::IncrementalSweeper::startSweeping): Initialize our new Structure sweeping index. + (JSC::IncrementalSweeper::willFinishSweeping): Callback that is called by MarkedSpace::sweep to notify + the IncrementalSweeper that we are going to sweep all of the remaining blocks in the Heap so it can + assume that everything is taken care of in the correct order. Since MarkedSpace::forEachBlock + iterates over the Structure blocks after all other blocks, the ordering property for sweeping Structures holds. + (JSC::IncrementalSweeper::IncrementalSweeper): Initialize Structure sweeping index. + * heap/IncrementalSweeper.h: Add declarations for new stuff. + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): We now check if the current block only contains structures and + if so and it isn't safe to sweep Structures according to the Heap, we just return early instead of doing + the normal lazy sweep. If this proves to be too much of a waste in the future we can add an extra clause that + will sweep some number of other blocks in place of the current block to mitigate the cost of the floating + Structure garbage. + (JSC::MarkedAllocator::addBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::zapFreeList): When we zap the free list in the MarkedAllocator, the current block is no + longer valid to allocate from, so we set the current block to null. + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweepHelper): Added a couple assertions to make sure that we weren't trying to sweep Structures + at an unsafe time. + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::sweep): Notify the IncrementalSweeper that the MarkedSpace will finish all currently remaining sweeping. + (JSC): + * heap/MarkedSpace.h: + (JSC): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::~JSGlobalData): Call the new Heap::didStartVMShutdown. + +2012-07-29 Filip Pizlo <fpizlo@apple.com> + + PropertyNameArray::m_shouldCache is only assigned and never used + https://bugs.webkit.org/show_bug.cgi?id=92598 + + Reviewed by Dan Bernstein. + + * runtime/PropertyNameArray.h: + (JSC::PropertyNameArray::PropertyNameArray): + (PropertyNameArray): + +2012-07-29 Rik Cabanier <cabanier@adobe.com> + + Add ENABLE_CSS_COMPOSITING flag + https://bugs.webkit.org/show_bug.cgi?id=92553 + + Reviewed by Dirk Schulze. + + Adds compiler flag CSS_COMPOSITING to build systems to enable CSS blending and compositing. See spec https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html + + * Configurations/FeatureDefines.xcconfig: + +2012-07-27 Mark Hahnenberg <mhahnenberg@apple.com> + + Split functionality of MarkedAllocator::m_currentBlock + https://bugs.webkit.org/show_bug.cgi?id=92550 + + Reviewed by Filip Pizlo. + + MarkedAllocator::m_currentBlock serves two purposes right now; it indicates the block that is currently + being used for allocation and the beginning of the list of blocks that need to be swept. We should split + these two functionalities into two separate fields. + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::tryAllocateHelper): Use m_blocksToSweep instead of m_currentBlock as the + initializer/reference of the loop. Only change m_currentBlock when we know what the result will be. + (JSC::MarkedAllocator::addBlock): When we add a new block we know that both m_blocksToSweep and + m_currentBlock are null. In order to preserve the invariant that m_currentBlock <= m_blocksToSweep, + we assign both of them to point to the new block. + (JSC::MarkedAllocator::removeBlock): We need a separate check to see if the block we're removing is + m_blocksToSweep and if so, advance it to the next block in the list. + * heap/MarkedAllocator.h: + (MarkedAllocator): Initialize m_blocksToSweep. + (JSC::MarkedAllocator::MarkedAllocator): + (JSC::MarkedAllocator::reset): We set m_blocksToSweep to be the head of our list. This function is called + at the end of a collection, so all of the blocks in our allocator need to be swept. We need to sweep a + block before we can start allocating, so m_currentBlock is set to null. We also set the freeList to + the empty FreeList to emphasize the fact that we can't start allocating until we do some sweeping. + +2012-07-27 Mark Hahnenberg <mhahnenberg@apple.com> + + Increase inline storage for JSFinalObjects by one + https://bugs.webkit.org/show_bug.cgi?id=92526 + + Reviewed by Geoffrey Garen. + + Now that we've removed the inheritorID from objects, we can increase our inline storage for JSFinalObjects on + 64-bit platforms by 1. + + * llint/LowLevelInterpreter.asm: Change the constant. + * runtime/PropertyOffset.h: Change the constant. + (JSC): + +2012-07-27 Jer Noble <jer.noble@apple.com> + + Support a rational time class for use by media elements. + https://bugs.webkit.org/show_bug.cgi?id=88787 + + Re-export WTF::MediaTime from JavaScriptCore. + + Reviewed by Eric Carlson. + + * JavaScriptCore.order: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-07-26 Filip Pizlo <fpizlo@apple.com> + + JSObject::reallocateStorageIfNecessary is neither used nor defined + https://bugs.webkit.org/show_bug.cgi?id=92417 + + Reviewed by Mark Rowe. + + * runtime/JSObject.h: + (JSObject): + +2012-07-26 Mark Hahnenberg <mhahnenberg@apple.com> + + Allocate Structures in a separate part of the Heap + https://bugs.webkit.org/show_bug.cgi?id=92420 + + Reviewed by Filip Pizlo. + + To fix our issue with destruction/finalization of Structures before their objects, we can move Structures to a separate + part of the Heap that will be swept after all other objects. This first patch will just be separating Structures + out into their own separate MarkedAllocator. Everything else will behave identically. + + * heap/Heap.h: New function to allocate Structures in the Heap. + (Heap): + (JSC): + (JSC::Heap::allocateStructure): + * heap/MarkedAllocator.cpp: Pass whether or not we're allocated Structures to the MarkedBlock. + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedAllocator.h: Add tracking for whether or not we're allocating only Structures. + (JSC::MarkedAllocator::onlyContainsStructures): + (MarkedAllocator): + (JSC::MarkedAllocator::MarkedAllocator): + (JSC::MarkedAllocator::init): + * heap/MarkedBlock.cpp: Add tracking for whether or not we're allocating only Structures. We need this to be able to + distinguish the various MarkedBlock types in MarkedSpace::allocatorFor(MarkedBlock*). + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::onlyContainsStructures): + (JSC): + * heap/MarkedSpace.cpp: Include the new Structure allocator in all the places that all the other allocators are used/modified. + (JSC::MarkedSpace::MarkedSpace): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::canonicalizeCellLivenessData): + (JSC::MarkedSpace::isPagedOut): + * heap/MarkedSpace.h: Add new MarkedAllocator just for Structures. + (MarkedSpace): + (JSC::MarkedSpace::allocatorFor): + (JSC::MarkedSpace::allocateStructure): + (JSC): + (JSC::MarkedSpace::forEachBlock): + * runtime/Structure.h: Move all of the functions that call allocateCell<Structure> down below the explicit template specialization + for allocateCell<Structure>. The new inline specialization for allocateCell directly calls the allocateStructure() function in the + Heap. + (Structure): + (JSC::Structure): + (JSC): + (JSC::Structure::create): + (JSC::Structure::createStructure): + +2012-07-26 Filip Pizlo <fpizlo@apple.com> + + JSArray has methods that are neither used nor defined + https://bugs.webkit.org/show_bug.cgi?id=92416 + + Reviewed by Simon Fraser. + + * runtime/JSArray.h: + (JSArray): + +2012-07-26 Zoltan Herczeg <zherczeg@webkit.org> + + [Qt][ARM]ARMAssembler needs buildfix afert r123417 + https://bugs.webkit.org/show_bug.cgi?id=92086 + + Reviewed by Csaba Osztrogonác. + + The ARM implementation of this should be optimized code path + is covered by a non-optimized code path. This patch fixes this, + and adds a new function which returns with the offset range. + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::readPointer): + (ARMAssembler): + (JSC::ARMAssembler::repatchInt32): + (JSC::ARMAssembler::repatchCompact): + * assembler/MacroAssemblerARM.h: + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::isCompactPtrAlignedAddressOffset): + (JSC::MacroAssemblerARM::load32WithCompactAddressOffsetPatch): + +2012-07-25 Mark Hahnenberg <mhahnenberg@apple.com> + + Build fix for 32-bit after r123682 + + * runtime/JSObject.h: Need to pad out JSObjects on 32-bit so that they're the correct size since + we only removed one 4-byte word and we need to be 8-byte aligned. + (JSObject): + +2012-07-25 Filip Pizlo <fpizlo@apple.com> + + JSC GC object copying APIs should allow for greater flexibility + https://bugs.webkit.org/show_bug.cgi?id=92316 + + Reviewed by Mark Hahnenberg. + + It's now the case that visitChildren() methods can directly pin and allocate in new space during copying. + They can also do the copying and marking themselves. This new API is only used for JSObjects for now. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/MarkStack.cpp: + (JSC::SlotVisitor::allocateNewSpaceSlow): + (JSC::SlotVisitor::allocateNewSpaceOrPin): + (JSC): + (JSC::SlotVisitor::copyAndAppend): + * heap/MarkStack.h: + (MarkStack): + (JSC::MarkStack::appendUnbarrieredValue): + (JSC): + * heap/SlotVisitor.h: + * heap/SlotVisitorInlineMethods.h: Added. + (JSC): + (JSC::SlotVisitor::checkIfShouldCopyAndPinOtherwise): + (JSC::SlotVisitor::allocateNewSpace): + * runtime/JSObject.cpp: + (JSC::JSObject::visitOutOfLineStorage): + (JSC): + (JSC::JSObject::visitChildren): + (JSC::JSFinalObject::visitChildren): + * runtime/JSObject.h: + (JSObject): + +2012-07-25 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove JSObject::m_inheritorID + https://bugs.webkit.org/show_bug.cgi?id=88378 + + Reviewed by Filip Pizlo. + + This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), + and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). + Instead use a private named value in the object's property storage. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): No need m_inheritorID to initialize! + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): No need m_inheritorID to initialize! + * llint/LowLevelInterpreter.asm: No need m_inheritorID to initialize! + * runtime/JSGlobalData.h: + (JSGlobalData): Added private name 'm_inheritorIDKey'. + * runtime/JSGlobalThis.cpp: + (JSC::JSGlobalThis::setUnwrappedObject): resetInheritorID is now passed a JSGlobalData&. + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): No m_inheritorID to be marked. + (JSC::JSFinalObject::visitChildren): No m_inheritorID to be marked. + (JSC::JSObject::createInheritorID): Store the newly created inheritorID in the property map. Make sure + it's got the DontEnum attribute!! + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::resetInheritorID): Remove the inheritorID from property storage. + (JSC): + (JSC::JSObject::inheritorID): Read the inheritorID from property storage. + +2012-07-25 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> + + Create a specialized pair for use in HashMap iterators + https://bugs.webkit.org/show_bug.cgi?id=92137 + + Reviewed by Ryosuke Niwa. + + Update a couple of sites that relied on the fact that "contents" of iterators were + std::pairs. + + * profiler/Profile.cpp: + (JSC): This code kept a vector of the pairs that were the "contents" of the iterators. This + is changed to use a KeyValuePair. We make use HashCount's ValueType (which represents only + the key) to get the proper key parameter for KeyValuePair. + * tools/ProfileTreeNode.h: + (ProfileTreeNode): Use HashMap::ValueType to declare the type of the contents of the hash + instead of declaring it manually. This will make use of the new KeyValuePair. + +2012-07-25 Patrick Gansterer <paroga@webkit.org> + + REGRESSION(r123505): Date.getYear() returns the same as Date.getFullYear() + https://bugs.webkit.org/show_bug.cgi?id=92218 + + Reviewed by Csaba Osztrogonác. + + * runtime/DatePrototype.cpp: + (JSC::dateProtoFuncGetYear): Added the missing offset of 1900 to the return value. + +2012-07-24 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r123417): It made tests assert/crash on 32 bit + https://bugs.webkit.org/show_bug.cgi?id=92088 + + Reviewed by Mark Hahnenberg. + + The pointer arithmetic was wrong, because negative numbers are hard to think about. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + +2012-07-24 Patrick Gansterer <paroga@webkit.org> + + Store the full year in GregorianDateTime + https://bugs.webkit.org/show_bug.cgi?id=92067 + + Reviewed by Geoffrey Garen. + + Use the full year instead of the offset from year 1900 + for the year member variable of GregorianDateTime. + + * runtime/DateConstructor.cpp: + (JSC::constructDate): + (JSC::dateUTC): + * runtime/DateConversion.cpp: + (JSC::formatDate): + (JSC::formatDateUTCVariant): + * runtime/DatePrototype.cpp: + (JSC::formatLocaleDate): + (JSC::fillStructuresUsingDateArgs): + (JSC::dateProtoFuncToISOString): + (JSC::dateProtoFuncGetFullYear): + (JSC::dateProtoFuncGetUTCFullYear): + (JSC::dateProtoFuncSetYear): + * runtime/JSDateMath.cpp: + (JSC::gregorianDateTimeToMS): + (JSC::msToGregorianDateTime): + +2012-07-24 Patrick Gansterer <paroga@webkit.org> + + [WIN] Build fix after r123417. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-07-23 Patrick Gansterer <paroga@webkit.org> + + Move GregorianDateTime from JSC to WTF namespace + https://bugs.webkit.org/show_bug.cgi?id=91948 + + Reviewed by Geoffrey Garen. + + Moving GregorianDateTime into the WTF namespace allows us to us to + use it in WebCore too. The new class has the same behaviour as the + old struct. Only the unused timeZone member has been removed. + + * runtime/DateConstructor.cpp: + * runtime/DateConversion.cpp: + * runtime/DateConversion.h: + * runtime/DateInstance.h: + * runtime/DatePrototype.cpp: + * runtime/JSDateMath.cpp: + * runtime/JSDateMath.h: + +2012-07-23 Filip Pizlo <fpizlo@apple.com> + + Property storage should grow in reverse address direction, to support butterflies + https://bugs.webkit.org/show_bug.cgi?id=91788 + + Reviewed by Geoffrey Garen. + + Changes property storage to grow to the left, and changes the property storage pointer to point + one 8-byte word (i.e. JSValue) to the right of the first value in the storage. + + Also improved debug support somewhat, by adding a describe() function to the jsc command-line, + and a slow mode of object access in LLInt. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::repatchCompact): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::isCompactPtrAlignedAddressOffset): + (JSC::MacroAssemblerARMv7::load32WithCompactAddressOffsetPatch): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::isCompactPtrAlignedAddressOffset): + (JSC::MacroAssemblerX86Common::repatchCompact): + * assembler/X86Assembler.h: + (JSC::X86Assembler::repatchCompact): + * bytecode/CodeBlock.cpp: + (JSC::dumpStructure): + * bytecode/GetByIdStatus.h: + (JSC::GetByIdStatus::GetByIdStatus): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * heap/ConservativeRoots.cpp: + (JSC::ConservativeRoots::genericAddPointer): + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::pinIfNecessary): + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::compileGetDirectOffset): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::compileGetDirectOffset): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCacheGetByID): + * jsc.cpp: + (GlobalObject::finishCreation): + (functionDescribe): + * llint/LLIntCommon.h: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + (JSC::JSFinalObject::visitChildren): + (JSC::JSObject::growOutOfLineStorage): + * runtime/JSObject.h: + (JSC::JSObject::getDirectLocation): + (JSC::JSObject::offsetForLocation): + * runtime/JSValue.h: + (JSValue): + * runtime/PropertyOffset.h: + (JSC::offsetInOutOfLineStorage): + +2012-07-23 Filip Pizlo <fpizlo@apple.com> + + DFG is too aggressive in performing the specific value optimization on loads + https://bugs.webkit.org/show_bug.cgi?id=92034 + + Reviewed by Mark Hahnenberg. + + This ensures that we don't do optimizations based on a structure having a specific + value, if there is no way to detect that the value is despecified. This is the + case for dictionaries, since despecifying a value in a dictionary does not lead to + a transition and so cannot be caught by either structure checks or structure + transition watchpoints. + + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + (JSC::GetByIdStatus::computeForChain): + (JSC::GetByIdStatus::computeFor): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + +2012-07-23 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r123169): It made fast/js/dfg-inline-arguments-use-from-uninlined-code.html fail on 32 bit platforms + https://bugs.webkit.org/show_bug.cgi?id=92002 + + Reviewed by Mark Hahnenberg. + + In the process of changing the nature of local variable typing, I forgot to modify one of the places where + we glue the DFG's notion of variable prediction to the runtime's notion of variable tagging. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-07-23 Simon Fraser <simon.fraser@apple.com> + + Part 2 of: Implement sticky positioning + https://bugs.webkit.org/show_bug.cgi?id=90046 + + Reviewed by Ojan Vafai. + + Turn on ENABLE_CSS_STICKY_POSITION. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-23 Patrick Gansterer <paroga@webkit.org> + + Move JSC::parseDate() from DateConversion to JSDateMath + https://bugs.webkit.org/show_bug.cgi?id=91982 + + Reviewed by Geoffrey Garen. + + Moveing this function into the other files removes the dependency + on JSC spcific classes in DateConversion.{cpp|h}. + + * runtime/DateConversion.cpp: + * runtime/DateConversion.h: + (JSC): + * runtime/JSDateMath.cpp: + (JSC::parseDate): + (JSC): + * runtime/JSDateMath.h: + (JSC): + +2012-07-23 Simon Fraser <simon.fraser@apple.com> + + Part 1 of: Implement sticky positioning + https://bugs.webkit.org/show_bug.cgi?id=90046 + + Reviewed by Ojan Vafai. + + Add ENABLE_CSS_STICKY_POSITION, defaulting to off initially. + + Sort the ENABLE_CSS lines in the file. Make sure all the flags + are in FEATURE_DEFINES. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-23 Yong Li <yoli@rim.com> + + [BlackBerry] Implement GCActivityCallback with platform timer + https://bugs.webkit.org/show_bug.cgi?id=90175 + + Reviewed by Rob Buis. + + Use JSLock when performing GC to avoid assertions. + + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC::DefaultGCActivityCallback::doWork): + +2012-07-23 Kent Tamura <tkent@chromium.org> + + Rename ENABLE_METER_TAG and ENABLE_PROGRESS_TAG to ENABLE_METER_ELEMENT and ENABLE_PROGRESS_ELEMENT respectively + https://bugs.webkit.org/show_bug.cgi?id=91941 + + Reviewed by Kentaro Hara. + + A flag name for an elmement should be ENABLE_*_ELEMENT. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-22 Kent Tamura <tkent@chromium.org> + + Rename ENABLE_DETAILS to ENABLE_DETAILS_ELEMENT + https://bugs.webkit.org/show_bug.cgi?id=91928 + + Reviewed by Kentaro Hara. + + A flag name for an elmement should be ENABLE_*_ELEMENT. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-21 Patrick Gansterer <paroga@webkit.org> + + [WIN] Use GetDateFormat and GetTimeFormat instead of strftime + https://bugs.webkit.org/show_bug.cgi?id=83436 + + Reviewed by Brent Fulgham. + + The MS CRT implementation of strftime calls the same two functions. + Using them directly avoids the overhead of parsing the format string and removes + the dependency on strftime() for WinCE where this function does not exist. + + * runtime/DatePrototype.cpp: + (JSC::formatLocaleDate): + +2012-07-20 Kent Tamura <tkent@chromium.org> + + Rename ENABLE_DATALIST to ENABLE_DATALIST_ELEMENT + https://bugs.webkit.org/show_bug.cgi?id=91846 + + Reviewed by Kentaro Hara. + + A flag name for an elmement should be ENABLE_*_ELEMENT. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-20 Han Shen <shenhan@google.com> + + [Chromium] Compilation fails under gcc 4.7 + https://bugs.webkit.org/show_bug.cgi?id=90227 + + Reviewed by Tony Chang. + + Disable warnings about c++0x compatibility in gcc newer than 4.6. + + * JavaScriptCore.gyp/JavaScriptCore.gyp: + +2012-07-18 Filip Pizlo <fpizlo@apple.com> + + DFG cell checks should be hoisted + https://bugs.webkit.org/show_bug.cgi?id=91717 + + Reviewed by Geoffrey Garen. + + The DFG has always had the policy of hoisting array and integer checks to + the point of variable assignment. Eventually, we added doubles and booleans + to the mix. But cells should really be part of this as well, particularly + for 32-bit where accessing a known-type variable is dramatically cheaper + than accessing a variable whose types is only predicted but otherwise + unproven. + + This appears to be a definite speed-up for V8 on 32-bit, a possible speed-up + for Kraken, and a possible slow-down for V8 on 64-bit (around 0.2% if at + all). Any slow-downs can, and should, be addressed by making the hoisting + logic cognizant of variables that are never used in a manner that requires + type checks, and by sinking argument checks to the point(s) of first use. + + To make this work I had to change some OSR machinery, and special-case the + type predictions of the 'this' argument for constructors. OSR exit normally + assumes that arguments are boxed, which happens to be true because the + type prediction used for check hoisting is LUB'd with the type of the + argument that was passed in - so either the arguments are always stored to + with the full tag+payload, or if only the payload is stored then the tag + matches whatever the caller would have set. But not so with the 'this' + argument for constructors, which is not initialized by the caller. We + could make this more precise by having argument types for OSR be inferred + using similar machinery to other locals, but I figured that for this patch + I should use the surgical fix. + + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::branchTestPtr): + (MacroAssemblerX86_64): + * assembler/X86Assembler.h: + (JSC::X86Assembler::testq_rm): + (X86Assembler): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::execute): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::isCreatedThisArgument): + (Graph): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGValueSource.h: + (JSC::DFG::ValueSource::forSpeculation): + +2012-07-19 Filip Pizlo <fpizlo@apple.com> + + Fast path of storage resize should be removed from property storage reallocation, since it is only useful for arrays + https://bugs.webkit.org/show_bug.cgi?id=91796 + + Reviewed by Geoffrey Garen. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * runtime/JSObject.cpp: + (JSC::JSObject::growOutOfLineStorage): + +2012-07-19 Mark Lam <mark.lam@apple.com> + + Bug fixes and enhancements for OfflineASM annotation system. + https://bugs.webkit.org/show_bug.cgi?id=91690 + + Reviewed by Filip Pizlo. + + * offlineasm/armv7.rb: added default handling of Instruction lower(). + * offlineasm/asm.rb: added more support for annotations and more pretty printing. + * offlineasm/ast.rb: added more support for annotations. + * offlineasm/config.rb: added $preferredCommentStartColumn, simplified $enableInstrAnnotations. + * offlineasm/parser.rb: added more support for annotations. + * offlineasm/transform.rb: added more support for annotations. + * offlineasm/x86.rb: added default handling of Instruction lower(). + +2012-07-19 Patrick Gansterer <paroga@webkit.org> + + [WIN] Fix compilation of JSGlobalData.h with ENABLE(DFG_JIT) + https://bugs.webkit.org/show_bug.cgi?id=91243 + + Reviewed by Geoffrey Garen. + + Disable MSVC warning 4200 "zero-sized array in struct/union" for JSC::ScratchBuffer. + + * runtime/JSGlobalData.h: + (JSC): + +2012-07-19 Mark Lam <mark.lam@apple.com> + + Fixed broken ENABLE_JIT=0 build. + https://bugs.webkit.org/show_bug.cgi?id=91725 + + Reviewed by Oliver Hunt. + + * bytecode/Watchpoint.cpp: + * heap/JITStubRoutineSet.h: + (JSC): + (JITStubRoutineSet): + (JSC::JITStubRoutineSet::JITStubRoutineSet): + (JSC::JITStubRoutineSet::~JITStubRoutineSet): + (JSC::JITStubRoutineSet::add): + (JSC::JITStubRoutineSet::clearMarks): + (JSC::JITStubRoutineSet::mark): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + (JSC::JITStubRoutineSet::traceMarkedStubRoutines): + +2012-07-19 Kristóf Kosztyó <kkristof@inf.u-szeged.hu> + + [Qt] Unreviewed buildfix after r123042. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpRegisters): + +2012-07-18 Filip Pizlo <fpizlo@apple.com> + + DFG should emit inline code for property storage (re)allocation + https://bugs.webkit.org/show_bug.cgi?id=91597 + + Reviewed by Oliver Hunt. + + This adds two new ops to the DFG IR: AllocatePropertyStorage and + ReallocatePropertyStorage. It enables these to interact properly with + CSE so that a GetPropertyStorage on something for which we have + obviously done a (Re)AllocatePropertyStorage will result in the + GetPropertyStorage being eliminated. Other than that, the code + emitted for these ops is identical to the code we were emitting in + the corresponding PutById stub. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasStructureTransitionData): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (DFG): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/Structure.cpp: + (JSC::nextOutOfLineStorageCapacity): + * runtime/Structure.h: + (JSC): + +2012-07-16 Oliver Hunt <oliver@apple.com> + + dumpCallFrame is broken in ToT + https://bugs.webkit.org/show_bug.cgi?id=91444 + + Reviewed by Gavin Barraclough. + + Various changes have been made to the SF calling convention, but + dumpCallFrame has not been updated to reflect these changes. + That resulted in both bogus information, as well as numerous + assertions of sadness. + + This patch makes dumpCallFrame actually work again and adds the + wonderful feature of telling you the name of the variable that a + register reflects, or what value it contains. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::nameForRegister): + A really innefficient mechanism for finding the name of a local register. + This should only ever be used by debug code so this should be okay. + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + Debug builds no longer throw away a functions symbol table, this allows + us to actually perform a register# to name mapping + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + We weren't propogating the bytecode offset here leading to assertions + in debug builds when dumping bytecode of DFG compiled code. + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + Rework to actually be correct. + (JSC::getCallerInfo): + Return the byteocde offset as well now, given we have to determine it + anyway. + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (Interpreter): + * jsc.cpp: + (GlobalObject::finishCreation): + (functionDumpCallFrame): + Give debug builds of JSC a method for calling dumpCallFrame so we can + inspect a callframe without requiring us to break in a debugger. + +2012-07-18 Filip Pizlo <fpizlo@apple.com> + + DFG 32-bit PutById transition stub storage reallocation case copies the first pointer of each JSValue instead of the whole JSValue + https://bugs.webkit.org/show_bug.cgi?id=91599 + + Reviewed by Geoffrey Garen. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutTransitionStub): + +2012-07-17 Filip Pizlo <fpizlo@apple.com> + + DFG 32-bit PutById transition stub passes the payload/tag arguments to a DFG operation in the wrong order + https://bugs.webkit.org/show_bug.cgi?id=91576 + + Reviewed by Gavin Barraclough. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutTransitionStub): + +2012-07-17 Filip Pizlo <fpizlo@apple.com> + + [Qt] REGRESSION(r122768, r122771): They broke jquery/data.html and inspector/elements/edit-dom-actions.html + https://bugs.webkit.org/show_bug.cgi?id=91476 + + Reviewed by Mark Hahnenberg. + + The 32-bit repatching code was not correctly adapted to the new world where there may not always + be an available scratch register. Fixed it by ensuring that the scratch register we select does + not overlap with the value tag. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + +2012-07-17 Gabor Rapcsanyi <rgabor@webkit.org> + + Unreviewed buildfix from Zoltan Herczeg after 122768. + + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + +2012-07-17 David Barr <davidbarr@chromium.org> + + Introduce ENABLE_CSS_IMAGE_ORIENTATION compile flag + https://bugs.webkit.org/show_bug.cgi?id=89055 + + Reviewed by Kent Tamura. + + The css3-images module is at candidate recommendation. + http://www.w3.org/TR/2012/CR-css3-images-20120417/#the-image-orientation + + Add a configuration option for CSS image-orientation support, disabling it by default. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-16 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, roll out 122790 because it broke the Windows build. I'm not + sure what to do with exported symbols that are predicated on NDEBUG. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * bytecode/CodeBlock.cpp: + (JSC): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + (JSC::getCallerInfo): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (Interpreter): + * jsc.cpp: + (GlobalObject::finishCreation): + +2012-07-16 Oliver Hunt <oliver@apple.com> + + dumpCallFrame is broken in ToT + https://bugs.webkit.org/show_bug.cgi?id=91444 + + Reviewed by Gavin Barraclough. + + Various changes have been made to the SF calling convention, but + dumpCallFrame has not been updated to reflect these changes. + That resulted in both bogus information, as well as numerous + assertions of sadness. + + This patch makes dumpCallFrame actually work again and adds the + wonderful feature of telling you the name of the variable that a + register reflects, or what value it contains. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::nameForRegister): + A really innefficient mechanism for finding the name of a local register. + This should only ever be used by debug code so this should be okay. + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + Debug builds no longer throw away a functions symbol table, this allows + us to actually perform a register# to name mapping + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + We weren't propogating the bytecode offset here leading to assertions + in debug builds when dumping bytecode of DFG compiled code. + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + Rework to actually be correct. + (JSC::getCallerInfo): + Return the byteocde offset as well now, given we have to determine it + anyway. + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (Interpreter): + * jsc.cpp: + (GlobalObject::finishCreation): + (functionDumpCallFrame): + Give debug builds of JSC a method for calling dumpCallFrame so we can + inspect a callframe without requiring us to break in a debugger. + +2012-07-16 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, adding forgotten files. + + * dfg/DFGRegisterSet.h: Added. + (DFG): + (RegisterSet): + (JSC::DFG::RegisterSet::RegisterSet): + (JSC::DFG::RegisterSet::asPOD): + (JSC::DFG::RegisterSet::copyInfo): + (JSC::DFG::RegisterSet::set): + (JSC::DFG::RegisterSet::setGPRByIndex): + (JSC::DFG::RegisterSet::clear): + (JSC::DFG::RegisterSet::get): + (JSC::DFG::RegisterSet::getGPRByIndex): + (JSC::DFG::RegisterSet::getFreeGPR): + (JSC::DFG::RegisterSet::setFPRByIndex): + (JSC::DFG::RegisterSet::getFPRByIndex): + (JSC::DFG::RegisterSet::setByIndex): + (JSC::DFG::RegisterSet::getByIndex): + (JSC::DFG::RegisterSet::numberOfSetGPRs): + (JSC::DFG::RegisterSet::numberOfSetFPRs): + (JSC::DFG::RegisterSet::numberOfSetRegisters): + (JSC::DFG::RegisterSet::setBit): + (JSC::DFG::RegisterSet::clearBit): + (JSC::DFG::RegisterSet::getBit): + * dfg/DFGScratchRegisterAllocator.h: Added. + (DFG): + (ScratchRegisterAllocator): + (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator): + (JSC::DFG::ScratchRegisterAllocator::lock): + (JSC::DFG::ScratchRegisterAllocator::allocateScratch): + (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR): + (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR): + (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters): + (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing): + (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping): + (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize): + (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): + (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): + +2012-07-15 Filip Pizlo <fpizlo@apple.com> + + DFG PutById transition should handle storage allocation, and inline it + https://bugs.webkit.org/show_bug.cgi?id=91337 + + Reviewed by Oliver Hunt. + + This enables the patching of DFG PutById to handle the out-of-line storage + allocation case. Furthermore, it inlines out-of-line storage allocation (and + reallocation) into the generated stubs. + + To do this, this patch adds the ability to store the relevant register + allocation state (i.e. the set of in-use registers) in the structure stub + info so that the stub generation code can more flexibly select scratch + registers: sometimes it needs none, sometimes one - or sometimes up to + three. Moreover, to make the stub generation register allocation simple and + maintainable, this patch introduces a reusable scratch register allocator + class. This register allocator understands that some registers are in use by + the main path code and so must be spilled as necessary, other registers are + locked for use in the stub itself and so cannot even be spilled, while still + others may be allocated for scratch purposes. A scratch register that is + used must be spilled. If a register is locked, it cannot be used as a + scratch register. If a register is used, it can be used as a scratch + register so long as it is spilled. + + This is a sub-1% speed-up on V8 and neutral elsewhere. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * assembler/MacroAssemblerCodeRef.h: + (FunctionPtr): + (JSC::FunctionPtr::FunctionPtr): + * bytecode/StructureStubInfo.h: + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGGPRInfo.h: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * dfg/DFGJITCompiler.h: + (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord): + (PropertyAccessRecord): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGRegisterBank.h: + (JSC::DFG::RegisterBank::isInUse): + (RegisterBank): + * dfg/DFGRegisterSet.h: Added. + (DFG): + (RegisterSet): + (JSC::DFG::RegisterSet::RegisterSet): + (JSC::DFG::RegisterSet::asPOD): + (JSC::DFG::RegisterSet::copyInfo): + (JSC::DFG::RegisterSet::set): + (JSC::DFG::RegisterSet::setGPRByIndex): + (JSC::DFG::RegisterSet::clear): + (JSC::DFG::RegisterSet::get): + (JSC::DFG::RegisterSet::getGPRByIndex): + (JSC::DFG::RegisterSet::getFreeGPR): + (JSC::DFG::RegisterSet::setFPRByIndex): + (JSC::DFG::RegisterSet::getFPRByIndex): + (JSC::DFG::RegisterSet::setByIndex): + (JSC::DFG::RegisterSet::getByIndex): + (JSC::DFG::RegisterSet::numberOfSetGPRs): + (JSC::DFG::RegisterSet::numberOfSetFPRs): + (JSC::DFG::RegisterSet::numberOfSetRegisters): + (JSC::DFG::RegisterSet::setBit): + (JSC::DFG::RegisterSet::clearBit): + (JSC::DFG::RegisterSet::getBit): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::tryBuildPutByIdList): + * dfg/DFGScratchRegisterAllocator.h: Added. + (DFG): + (ScratchRegisterAllocator): + (JSC::DFG::ScratchRegisterAllocator::ScratchRegisterAllocator): + (JSC::DFG::ScratchRegisterAllocator::lock): + (JSC::DFG::ScratchRegisterAllocator::allocateScratch): + (JSC::DFG::ScratchRegisterAllocator::allocateScratchGPR): + (JSC::DFG::ScratchRegisterAllocator::allocateScratchFPR): + (JSC::DFG::ScratchRegisterAllocator::didReuseRegisters): + (JSC::DFG::ScratchRegisterAllocator::preserveReusedRegistersByPushing): + (JSC::DFG::ScratchRegisterAllocator::restoreReusedRegistersByPopping): + (JSC::DFG::ScratchRegisterAllocator::desiredScratchBufferSize): + (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): + (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::usedRegisters): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * heap/CopiedAllocator.h: + (CopiedAllocator): + (JSC::CopiedAllocator::fastPathShouldSucceed): + (JSC): + +2012-07-16 Patrick Gansterer <paroga@webkit.org> + + Add dfg switch to create_jit_stubs script + https://bugs.webkit.org/show_bug.cgi?id=91256 + + Reviewed by Geoffrey Garen. + + * create_jit_stubs: Add a switch to enable or disable the generation of + stub functions in #if ENABLE(DFG_JIT) conditions. + +2012-07-16 Gabor Rapcsanyi <rgabor@webkit.org> + + Unreviewed buildfix after r122729. Typo fix. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::add32): + +2012-07-16 Gabor Rapcsanyi <rgabor@webkit.org> + + Unreviewed buildfix from Zoltan Herczeg after r122677. + Implement missing add32 function to MacroAssemblerARM. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::add32): + (MacroAssemblerARM): + +2012-07-14 Filip Pizlo <fpizlo@apple.com> + + DFG PutByVal opcodes should accept more than 3 operands + https://bugs.webkit.org/show_bug.cgi?id=91332 + + Reviewed by Oliver Hunt. + + Turned PutByVal/PutByValAlias into var-arg nodes, so that we can give them + 4 or more operands in the future. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixDoubleEdge): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + (JSC::DFG::Graph::varArgNumChildren): + (Graph): + (JSC::DFG::Graph::numChildren): + (JSC::DFG::Graph::varArgChild): + (JSC::DFG::Graph::child): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-07-14 Filip Pizlo <fpizlo@apple.com> + + Rationalize and optimize storage allocation + https://bugs.webkit.org/show_bug.cgi?id=91303 + + Reviewed by Oliver Hunt. + + This implements a backwards bump allocator for copied space storage + allocation, shown in pseudo-code below: + + pointer bump(size) { + pointer tmp = allocator->remaining; + tmp -= size; + if (tmp < 0) + fail; + allocator->remaining = tmp; + return allocator->payloadEnd - tmp - size; + } + + The advantage of this allocator is that it: + + - Only requires one comparison in the common case where size is known to + not be huge, and this comparison can be done by checking the sign bit + of the subtraction. + + - Can be implemented even when only one register is available. This + register is reused for both temporary storage during allocation and + for the result. + + - Preserves the behavior that memory in a block is filled in from lowest + address to highest address, which allows for a cheap reallocation fast + path. + + - Is resilient against the block used for allocation being the last one + in virtual memory, thereby otherwise leading to the risk of overflow + in the bump pointer, despite only doing one branch. + + In order to implement this allocator using the smallest possible chunk + of code, I refactored the copied space code so that all of the allocation + logic is in CopiedAllocator, and all of the state is in either + CopiedBlock or CopiedAllocator. This should make changing the allocation + fast path easier in the future. + + In order to do this, I needed to add some new assembler support, + particularly for various forms of add(address, register) and negPtr(). + + This is performance neutral. The purpose of this change is to facilitate + further inlining of storage allocation without having to reserve + additional registers or emit too much code. + + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::addPtr): + (MacroAssembler): + (JSC::MacroAssembler::negPtr): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::add32): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::add32): + (MacroAssemblerX86): + * assembler/MacroAssemblerX86_64.h: + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::addPtr): + (JSC::MacroAssemblerX86_64::negPtr): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::addl_mr): + (JSC::X86Assembler::addq_mr): + (JSC::X86Assembler::negq_r): + * heap/CopiedAllocator.h: + (CopiedAllocator): + (JSC::CopiedAllocator::isValid): + (JSC::CopiedAllocator::CopiedAllocator): + (JSC::CopiedAllocator::tryAllocate): + (JSC): + (JSC::CopiedAllocator::tryReallocate): + (JSC::CopiedAllocator::forceAllocate): + (JSC::CopiedAllocator::resetCurrentBlock): + (JSC::CopiedAllocator::setCurrentBlock): + (JSC::CopiedAllocator::currentCapacity): + * heap/CopiedBlock.h: + (CopiedBlock): + (JSC::CopiedBlock::create): + (JSC::CopiedBlock::zeroFillWilderness): + (JSC::CopiedBlock::CopiedBlock): + (JSC::CopiedBlock::payloadEnd): + (JSC): + (JSC::CopiedBlock::payloadCapacity): + (JSC::CopiedBlock::data): + (JSC::CopiedBlock::dataEnd): + (JSC::CopiedBlock::dataSize): + (JSC::CopiedBlock::wilderness): + (JSC::CopiedBlock::wildernessEnd): + (JSC::CopiedBlock::wildernessSize): + (JSC::CopiedBlock::size): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateSlowCase): + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocate): + (JSC::CopiedSpace::doneFillingBlock): + (JSC::CopiedSpace::doneCopying): + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::startedCopying): + (JSC::CopiedSpace::allocateBlockForCopyingPhase): + (JSC::CopiedSpace::allocateBlock): + (JSC::CopiedSpace::tryAllocate): + (JSC): + * heap/MarkStack.cpp: + (JSC::SlotVisitor::startCopying): + (JSC::SlotVisitor::allocateNewSpace): + (JSC::SlotVisitor::doneCopying): + * heap/SlotVisitor.h: + (JSC::SlotVisitor::SlotVisitor): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicStorage): + (JSC::JIT::emitAllocateJSArray): + +2012-07-13 Mark Lam <mark.lam@apple.com> + + OfflineASM Pretty printing and commenting enhancements. + https://bugs.webkit.org/show_bug.cgi?id=91281 + + Reviewed by Filip Pizlo. + + Added some minor pretty printing in the OfflineASM. + Also added infrastruture for adding multiple types of comments and + annotations with the ability to enable/disable them in the generated + output as desired. + + * GNUmakefile.list.am: add new file config.rb. + * llint/LLIntOfflineAsmConfig.h: + Added OFFLINE_ASM_BEGIN, OFFLINE_ASM_END, and OFFLINE_ASM_LOCAL_LABEL macros. + This will allow us to redefine these for other backends later. + * llint/LowLevelInterpreter32_64.asm: + Add a small example of instruction annotations for now. + * llint/LowLevelInterpreter64.asm: + Add a small example of instruction annotations for now. + * offlineasm/armv7.rb: Added handling of annotations. + * offlineasm/asm.rb: + Added machinery to dump the new comments and annotations. + Also added some indentations to make the output a little prettier. + * offlineasm/ast.rb: Added annotation field in class Instruction. + * offlineasm/backends.rb: + * offlineasm/config.rb: Added. + Currently only contains commenting options. This file is meant to be + a centralized place for build config values much like config.h for + JavaScriptCore. + * offlineasm/generate_offset_extractor.rb: + * offlineasm/instructions.rb: + * offlineasm/offsets.rb: + * offlineasm/opt.rb: + * offlineasm/parser.rb: Parse and record annotations. + * offlineasm/registers.rb: + * offlineasm/self_hash.rb: + * offlineasm/settings.rb: + * offlineasm/transform.rb: + * offlineasm/x86.rb: Added handling of annotations. + +2012-07-13 Filip Pizlo <fpizlo@apple.com> + + ASSERTION FAILED: use.useKind() != DoubleUse + https://bugs.webkit.org/show_bug.cgi?id=91082 + + Reviewed by Geoffrey Garen. + + The implementation of Branch() was unwisely relying on register allocation state + to decide what speculations to perform. That's never correct. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-07-13 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r122640. + http://trac.webkit.org/changeset/122640 + https://bugs.webkit.org/show_bug.cgi?id=91298 + + LLInt apparently does not expect to mark these (Requested by + olliej on #webkit). + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::visitStructures): + (JSC::CodeBlock::stronglyVisitStrongReferences): + +2012-07-13 Oliver Hunt <oliver@apple.com> + + LLInt fails to mark structures stored in the bytecode + https://bugs.webkit.org/show_bug.cgi?id=91296 + + Reviewed by Geoffrey Garen. + + LLInt stores structures in the bytecode, so we need to visit the appropriate + instructions as we would if we were running in the classic interpreter. + This requires adding additional checks for the LLInt specific opcodes, and + the lint specific variants of operand ordering. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::visitStructures): + (JSC::CodeBlock::stronglyVisitStrongReferences): + +2012-07-13 Yong Li <yoli@rim.com> + + [BlackBerry] Implement GCActivityCallback with platform timer + https://bugs.webkit.org/show_bug.cgi?id=90175 + + Reviewed by Rob Buis. + + Implement GCActivityCallback and HeapTimer for BlackBerry port. + + * heap/HeapTimer.cpp: + (JSC): + (JSC::HeapTimer::HeapTimer): + (JSC::HeapTimer::~HeapTimer): + (JSC::HeapTimer::timerDidFire): + (JSC::HeapTimer::synchronize): + (JSC::HeapTimer::invalidate): + (JSC::HeapTimer::didStartVMShutdown): + * heap/HeapTimer.h: + (HeapTimer): + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::didAllocate): + (JSC::DefaultGCActivityCallback::willCollect): + (JSC::DefaultGCActivityCallback::cancel): + +2012-07-13 Patrick Gansterer <paroga@webkit.org> + + [WIN] Fix compilation of DFGRepatch.cpp + https://bugs.webkit.org/show_bug.cgi?id=91241 + + Reviewed by Geoffrey Garen. + + Use intptr_t instead of uintptr_t when calling CodeLocationCommon::dataLabelPtrAtOffset(int) + to fix MSVC "unary minus operator applied to unsigned type, result still unsigned" warning. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + +2012-07-13 Patrick Gansterer <paroga@webkit.org> + + Fix ARM_TRADITIONAL JIT for COMPILER(MSVC) and COMPILER(RVCT) after r121885 + https://bugs.webkit.org/show_bug.cgi?id=91238 + + Reviewed by Zoltan Herczeg. + + r121885 changed the assembler instruction only for COMPILER(GCC). + Use the same instructions for the other compilers too. + + * jit/JITStubs.cpp: + (JSC::ctiTrampoline): + (JSC::ctiTrampolineEnd): + (JSC::ctiVMThrowTrampoline): + +2012-07-12 Filip Pizlo <fpizlo@apple.com> + + DFG property access stubs should use structure transition watchpoints + https://bugs.webkit.org/show_bug.cgi?id=91135 + + Reviewed by Geoffrey Garen. + + This adds a Watchpoint subclass that will clear a structure stub (i.e. + a property access stub) when fired. The DFG stub generation code now + uses this optimization. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::resetStub): + (JSC::CodeBlock::resetStubInternal): + * bytecode/CodeBlock.h: + (JSC): + (CodeBlock): + * bytecode/StructureStubClearingWatchpoint.cpp: Added. + (JSC): + (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint): + (JSC::StructureStubClearingWatchpoint::push): + (JSC::StructureStubClearingWatchpoint::fireInternal): + (JSC::WatchpointsOnStructureStubInfo::~WatchpointsOnStructureStubInfo): + (JSC::WatchpointsOnStructureStubInfo::addWatchpoint): + (JSC::WatchpointsOnStructureStubInfo::ensureReferenceAndAddWatchpoint): + * bytecode/StructureStubClearingWatchpoint.h: Added. + (JSC): + (StructureStubClearingWatchpoint): + (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint): + (WatchpointsOnStructureStubInfo): + (JSC::WatchpointsOnStructureStubInfo::WatchpointsOnStructureStubInfo): + (JSC::WatchpointsOnStructureStubInfo::codeBlock): + (JSC::WatchpointsOnStructureStubInfo::stubInfo): + * bytecode/StructureStubInfo.h: + (JSC::StructureStubInfo::reset): + (JSC::StructureStubInfo::addWatchpoint): + (StructureStubInfo): + * dfg/DFGRepatch.cpp: + (JSC::DFG::addStructureTransitionCheck): + (DFG): + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::emitPutTransitionStub): + * jit/JumpReplacementWatchpoint.h: + +2012-07-12 Filip Pizlo <fpizlo@apple.com> + + DFG CFA may get overzealous in loops that have code that must exit + https://bugs.webkit.org/show_bug.cgi?id=91188 + + Reviewed by Gavin Barraclough. + + Ensure that if the CFA assumes that an operation must exit, then it will always exit + no matter what happens after. That's necessary to preserve soundness. + + Remove a broken fixup done by the DFG simplifier, where it was trying to say that the + variable-at-head was the first access in the second block in the merge, if the first + block did not read the variable. That's totally wrong, if the first block was in fact + doing a phantom read. I removed that fixup and instead hardened the rest of the + compiler. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::endBasicBlock): + * dfg/DFGBasicBlock.h: + (JSC::DFG::BasicBlock::BasicBlock): + (BasicBlock): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::performBlockCFA): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase): + (JSC::DFG::ConstantFoldingPhase::run): + (ConstantFoldingPhase): + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + +2012-07-12 Allan Sandfeld Jensen <allan.jensen@nokia.com> + + [Qt] Implement MemoryUsageSupport + https://bugs.webkit.org/show_bug.cgi?id=91094 + + Reviewed by Adam Barth. + + Compile in MemoryStatistics so we can make use of the interface. + + * Target.pri: + +2012-07-12 Csaba Osztrogonác <ossy@webkit.org> + + Remove dead code after r122392. + https://bugs.webkit.org/show_bug.cgi?id=91049 + + Reviewed by Filip Pizlo. + + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + +2012-07-11 Adenilson Cavalcanti <cavalcantii@gmail.com> + + Build fix + remove dead code + https://bugs.webkit.org/show_bug.cgi?id=91039 + + Reviewed by Filip Pizlo. + + An unused variable was breaking compilation (thanks to warnings being treated as errors). + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + +2012-07-11 Mark Rowe <mrowe@apple.com> + + <http://webkit.org/b/91024> Build against the latest SDK when targeting older OS X versions. + + Reviewed by Dan Bernstein. + + The deployment target is already set to the version that we're targeting, and it's that setting + which determines which functionality from the SDK is available to us. + + * Configurations/Base.xcconfig: + +2012-07-11 Filip Pizlo <fpizlo@apple.com> + + DFG should have fast virtual calls + https://bugs.webkit.org/show_bug.cgi?id=90924 + + Reviewed by Gavin Barraclough. + + Implements virtual call support in the style of the old JIT, with the + caveat that we still use the same slow path for both InternalFunction + calls and JSFunction calls. Also rationalized the way that our + CodeOrigin indices tie into exception checks (previously it was a + strange one-to-one mapping with fairly limited assertions; now it's a + one-to-many mapping for CodeOrigins to exception checks, respectively). + I also took the opportunity to clean up + CallLinkInfo::callReturnLocation, which previously was either a Call or + a NearCall. Now it's just a NearCall. As well, exceptions during slow + path call resolution are now handled by returning an exception throwing + thunk rather than returning null. And finally, I made a few things + public that were previously private-with-lots-of-friends, because I + truly despise the thought of listing each thunk generating function as + a friend of JSValue and friends. + + * bytecode/CallLinkInfo.cpp: + (JSC::CallLinkInfo::unlink): + * bytecode/CallLinkInfo.h: + (CallLinkInfo): + * bytecode/CodeOrigin.h: + (JSC::CodeOrigin::CodeOrigin): + (JSC::CodeOrigin::isSet): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::AssemblyHelpers): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::CCallHelpers): + * dfg/DFGGPRInfo.h: + (GPRInfo): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JSC::DFG::CallBeginToken::CallBeginToken): + (JSC::DFG::CallBeginToken::~CallBeginToken): + (CallBeginToken): + (JSC::DFG::CallBeginToken::set): + (JSC::DFG::CallBeginToken::registerWithExceptionCheck): + (JSC::DFG::CallBeginToken::codeOrigin): + (JSC::DFG::CallExceptionRecord::CallExceptionRecord): + (CallExceptionRecord): + (JSC::DFG::JITCompiler::currentCodeOriginIndex): + (JITCompiler): + (JSC::DFG::JITCompiler::beginCall): + (JSC::DFG::JITCompiler::notifyCall): + (JSC::DFG::JITCompiler::prepareForExceptionCheck): + (JSC::DFG::JITCompiler::addExceptionCheck): + (JSC::DFG::JITCompiler::addFastExceptionCheck): + * dfg/DFGOperations.cpp: + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgLinkFor): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + * dfg/DFGThunks.cpp: + (JSC::DFG::emitPointerValidation): + (DFG): + (JSC::DFG::throwExceptionFromCallSlowPathGenerator): + (JSC::DFG::slowPathFor): + (JSC::DFG::linkForThunkGenerator): + (JSC::DFG::linkCallThunkGenerator): + (JSC::DFG::linkConstructThunkGenerator): + (JSC::DFG::virtualForThunkGenerator): + (JSC::DFG::virtualCallThunkGenerator): + (JSC::DFG::virtualConstructThunkGenerator): + * dfg/DFGThunks.h: + (DFG): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + (JSC::JIT::linkFor): + * runtime/Executable.h: + (ExecutableBase): + (JSC::ExecutableBase::offsetOfJITCodeFor): + (JSC::ExecutableBase::offsetOfNumParametersFor): + * runtime/JSValue.h: + (JSValue): + +2012-07-11 Filip Pizlo <fpizlo@apple.com> + + Accidentally used the wrong license (3-clause instead of 2-clause) in some + files I just committed. + + Rubber stamped by Oliver Hunt. + + * bytecode/Watchpoint.cpp: + * bytecode/Watchpoint.h: + * jit/JumpReplacementWatchpoint.cpp: + * jit/JumpReplacementWatchpoint.h: + +2012-07-11 Filip Pizlo <fpizlo@apple.com> + + Watchpoints and jump replacement should be decoupled + https://bugs.webkit.org/show_bug.cgi?id=91016 + + Reviewed by Oliver Hunt. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/AbstractMacroAssembler.h: + (JSC): + (Label): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::appendWatchpoint): + (JSC::CodeBlock::watchpoint): + (DFGData): + * bytecode/Watchpoint.cpp: + (JSC): + * bytecode/Watchpoint.h: + (JSC::Watchpoint::Watchpoint): + (Watchpoint): + (JSC::Watchpoint::fire): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + * jit/JumpReplacementWatchpoint.cpp: Added. + (JSC): + (JSC::JumpReplacementWatchpoint::correctLabels): + (JSC::JumpReplacementWatchpoint::fireInternal): + * jit/JumpReplacementWatchpoint.h: Added. + (JSC): + (JumpReplacementWatchpoint): + (JSC::JumpReplacementWatchpoint::JumpReplacementWatchpoint): + (JSC::JumpReplacementWatchpoint::setDestination): + +2012-07-11 Kevin Ollivier <kevino@theolliviers.com> + + [wx] Unreviewed build fix. Don't try to build udis86_itab.c since it's included by + another file. + + * wscript: + +2012-07-11 Chao-ying Fu <fu@mips.com> + + Add MIPS convertibleLoadPtr and other functions + https://bugs.webkit.org/show_bug.cgi?id=90714 + + Reviewed by Oliver Hunt. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::labelIgnoringWatchpoints): + (MIPSAssembler): + (JSC::MIPSAssembler::replaceWithLoad): + (JSC::MIPSAssembler::replaceWithAddressComputation): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::convertibleLoadPtr): + (MacroAssemblerMIPS): + +2012-07-11 Anders Carlsson <andersca@apple.com> + + Add -Wtautological-compare and -Wsign-compare warning flags + https://bugs.webkit.org/show_bug.cgi?id=90994 + + Reviewed by Mark Rowe. + + * Configurations/Base.xcconfig: + +2012-07-11 Benjamin Poulain <bpoulain@apple.com> + + Simplify the copying of JSC ARMv7's LinkRecord + https://bugs.webkit.org/show_bug.cgi?id=90930 + + Reviewed by Filip Pizlo. + + The class LinkRecord is used by value everywhere in ARMv7Assembler. The compiler uses + memmove() to move the objects. + + The problem is memmove() is overkill for this object, moving the value can be done with + 3 load-store. This patch adds an operator= to the class doing more efficient copying. + This reduces the link time by 19%. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::LinkRecord::LinkRecord): + (JSC::ARMv7Assembler::LinkRecord::operator=): + (JSC::ARMv7Assembler::LinkRecord::from): + (JSC::ARMv7Assembler::LinkRecord::setFrom): + (JSC::ARMv7Assembler::LinkRecord::to): + (JSC::ARMv7Assembler::LinkRecord::type): + (JSC::ARMv7Assembler::LinkRecord::linkType): + (JSC::ARMv7Assembler::LinkRecord::setLinkType): + (JSC::ARMv7Assembler::LinkRecord::condition): + +2012-07-11 Andy Wingo <wingo@igalia.com> + + jsc: Parse options before creating global data + https://bugs.webkit.org/show_bug.cgi?id=90975 + + Reviewed by Filip Pizlo. + + This patch moves the options parsing in "jsc" before the creation + of the JSGlobalData, so that --useJIT=no has a chance to take + effect. + + * jsc.cpp: + (CommandLine::parseArguments): Refactor to be a class, and take + argc and argv as constructor arguments. + (jscmain): Move arg parsing before JSGlobalData creation. + +2012-07-10 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r122166): It made 170 tests crash on 32 bit platforms + https://bugs.webkit.org/show_bug.cgi?id=90852 + + Reviewed by Zoltan Herczeg. + + If we can't use the range filter, we should still make sure that the + address is remotely sane, otherwise the hashtables will assert. + + * jit/JITStubRoutine.h: + (JSC::JITStubRoutine::passesFilter): + +2012-07-10 Filip Pizlo <fpizlo@apple.com> + + DFG recompilation heuristics should be based on count, not rate + https://bugs.webkit.org/show_bug.cgi?id=90146 + + Reviewed by Oliver Hunt. + + Rolling r121511 back in after fixing the DFG's interpretation of op_div + profiling, with Gavin's rubber stamp. + + This removes a bunch of code that was previously trying to prevent spurious + reoptimizations if a large enough majority of executions of a code block did + not result in OSR exit. It turns out that this code was purely harmful. This + patch removes all of that logic and replaces it with a dead-simple + heuristic: if you exit more than N times (where N is an exponential function + of the number of times the code block has already been recompiled) then we + will recompile. + + This appears to be a broad ~1% win on many benchmarks large and small. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::couldTakeSpecialFastCase): + (CodeBlock): + (JSC::CodeBlock::osrExitCounter): + (JSC::CodeBlock::countOSRExit): + (JSC::CodeBlock::addressOfOSRExitCounter): + (JSC::CodeBlock::offsetOfOSRExitCounter): + (JSC::CodeBlock::adjustedExitCountThreshold): + (JSC::CodeBlock::exitCountThresholdForReoptimization): + (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): + (JSC::CodeBlock::shouldReoptimizeNow): + (JSC::CodeBlock::shouldReoptimizeFromLoopNow): + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::setThreshold): + * bytecode/ExecutionCounter.h: + (ExecutionCounter): + (JSC::ExecutionCounter::clippedThreshold): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::makeDivSafe): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compileBody): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGOSRExitCompiler.cpp: + (JSC::DFG::OSRExitCompiler::handleExitCounts): + * dfg/DFGOperations.cpp: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/Options.h: + (JSC): + +2012-07-09 Matt Falkenhagen <falken@chromium.org> + + Add ENABLE_DIALOG_ELEMENT and skeleton files + https://bugs.webkit.org/show_bug.cgi?id=90521 + + Reviewed by Kent Tamura. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-09 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, roll out http://trac.webkit.org/changeset/121511 + It made in-browser V8v7 10% slower. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::countSpeculationSuccess): + (JSC::CodeBlock::countSpeculationFailure): + (JSC::CodeBlock::speculativeSuccessCounter): + (JSC::CodeBlock::speculativeFailCounter): + (JSC::CodeBlock::forcedOSRExitCounter): + (JSC::CodeBlock::addressOfSpeculativeSuccessCounter): + (JSC::CodeBlock::addressOfSpeculativeFailCounter): + (JSC::CodeBlock::addressOfForcedOSRExitCounter): + (JSC::CodeBlock::offsetOfSpeculativeSuccessCounter): + (JSC::CodeBlock::offsetOfSpeculativeFailCounter): + (JSC::CodeBlock::offsetOfForcedOSRExitCounter): + (JSC::CodeBlock::largeFailCountThreshold): + (JSC::CodeBlock::largeFailCountThresholdForLoop): + (JSC::CodeBlock::shouldReoptimizeNow): + (JSC::CodeBlock::shouldReoptimizeFromLoopNow): + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::setThreshold): + * bytecode/ExecutionCounter.h: + (ExecutionCounter): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compileBody): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGOSRExitCompiler.cpp: + (JSC::DFG::OSRExitCompiler::handleExitCounts): + * dfg/DFGOperations.cpp: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/Options.h: + (JSC): + +2012-07-09 Filip Pizlo <fpizlo@apple.com> + + DFG may get stuck in an infinite fix point if it constant folds a mispredicted node + https://bugs.webkit.org/show_bug.cgi?id=90829 + <rdar://problem/11823843> + + Reviewed by Oliver Hunt. + + If a node is shown to have been mispredicted during CFA, then don't allow constant + folding to make the graph even more degenerate. Instead, pull back on constant folding + and allow the normal OSR machinery to fix our profiling so that a future recompilation + doesn't see the same mistake. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::trySetConstant): + (AbstractState): + * dfg/DFGPhase.h: + (JSC::DFG::Phase::name): + (Phase): + (JSC::DFG::runAndLog): + (DFG): + (JSC::DFG::runPhase): + +2012-07-09 Filip Pizlo <fpizlo@apple.com> + + It should be possible to jettison JIT stub routines even if they are currently running + https://bugs.webkit.org/show_bug.cgi?id=90731 + + Reviewed by Gavin Barraclough. + + This gives the GC awareness of all JIT-generated stubs for inline caches. That + means that if you want to delete a JIT-generated stub, you don't have to worry + about whether or not it is currently running: if there is a chance that it might + be, the GC will kindly defer deletion until non-running-ness is proved. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/Instruction.h: + (JSC): + (PolymorphicStubInfo): + (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set): + (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList): + * bytecode/PolymorphicPutByIdList.cpp: + (JSC::PutByIdAccess::fromStructureStubInfo): + * bytecode/PolymorphicPutByIdList.h: + (JSC::PutByIdAccess::transition): + (JSC::PutByIdAccess::replace): + (JSC::PutByIdAccess::stubRoutine): + (PutByIdAccess): + (JSC::PolymorphicPutByIdList::currentSlowPathTarget): + * bytecode/StructureStubInfo.h: + (JSC::StructureStubInfo::reset): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::tryBuildGetByIDProtoList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::tryBuildPutByIdList): + * heap/ConservativeRoots.cpp: + (JSC): + (DummyMarkHook): + (JSC::DummyMarkHook::mark): + (JSC::ConservativeRoots::add): + (CompositeMarkHook): + (JSC::CompositeMarkHook::CompositeMarkHook): + (JSC::CompositeMarkHook::mark): + * heap/ConservativeRoots.h: + (JSC): + (ConservativeRoots): + * heap/Heap.cpp: + (JSC::Heap::markRoots): + (JSC::Heap::deleteUnmarkedCompiledCode): + * heap/Heap.h: + (JSC): + (Heap): + * heap/JITStubRoutineSet.cpp: Added. + (JSC): + (JSC::JITStubRoutineSet::JITStubRoutineSet): + (JSC::JITStubRoutineSet::~JITStubRoutineSet): + (JSC::JITStubRoutineSet::add): + (JSC::JITStubRoutineSet::clearMarks): + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + (JSC::JITStubRoutineSet::traceMarkedStubRoutines): + * heap/JITStubRoutineSet.h: Added. + (JSC): + (JITStubRoutineSet): + (JSC::JITStubRoutineSet::mark): + * heap/MachineStackMarker.h: + (JSC): + * interpreter/RegisterFile.cpp: + (JSC::RegisterFile::gatherConservativeRoots): + * interpreter/RegisterFile.h: + (JSC): + * jit/ExecutableAllocator.cpp: + (JSC::DemandExecutableAllocator::DemandExecutableAllocator): + * jit/ExecutableAllocator.h: + (JSC): + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC): + (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): + * jit/GCAwareJITStubRoutine.cpp: Added. + (JSC): + (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): + (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine): + (JSC::GCAwareJITStubRoutine::observeZeroRefCount): + (JSC::GCAwareJITStubRoutine::deleteFromGC): + (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal): + (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): + (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): + (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): + (JSC::createJITStubRoutine): + * jit/GCAwareJITStubRoutine.h: Added. + (JSC): + (GCAwareJITStubRoutine): + (JSC::GCAwareJITStubRoutine::markRequiredObjects): + (MarkingGCAwareJITStubRoutineWithOneObject): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITStubRoutine.cpp: Added. + (JSC): + (JSC::JITStubRoutine::~JITStubRoutine): + (JSC::JITStubRoutine::observeZeroRefCount): + * jit/JITStubRoutine.h: Added. + (JSC): + (JITStubRoutine): + (JSC::JITStubRoutine::JITStubRoutine): + (JSC::JITStubRoutine::createSelfManagedRoutine): + (JSC::JITStubRoutine::code): + (JSC::JITStubRoutine::asCodePtr): + (JSC::JITStubRoutine::ref): + (JSC::JITStubRoutine::deref): + (JSC::JITStubRoutine::startAddress): + (JSC::JITStubRoutine::endAddress): + (JSC::JITStubRoutine::addressStep): + (JSC::JITStubRoutine::canPerformRangeFilter): + (JSC::JITStubRoutine::filteringStartAddress): + (JSC::JITStubRoutine::filteringExtentSize): + (JSC::JITStubRoutine::passesFilter): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC::getPolymorphicAccessStructureListSlot): + +2012-07-09 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r122107. + http://trac.webkit.org/changeset/122107 + https://bugs.webkit.org/show_bug.cgi?id=90794 + + Build failure on Mac debug bots (Requested by falken_ on + #webkit). + + * Configurations/FeatureDefines.xcconfig: + +2012-07-09 Matt Falkenhagen <falken@chromium.org> + + Add ENABLE_DIALOG_ELEMENT and skeleton files + https://bugs.webkit.org/show_bug.cgi?id=90521 + + Reviewed by Kent Tamura. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-08 Ryosuke Niwa <rniwa@webkit.org> + + gcc build fix after r121925. + + * runtime/JSObject.h: + (JSC::JSFinalObject::finishCreation): + +2012-07-08 Zoltan Herczeg <zherczeg@webkit.org> + + [Qt][ARM] Implementing missing macro assembler instructions after r121925 + https://bugs.webkit.org/show_bug.cgi?id=90657 + + Reviewed by Csaba Osztrogonác. + + Implementing convertibleLoadPtr, replaceWithLoad and + replaceWithAddressComputation. + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::replaceWithLoad): + (ARMAssembler): + (JSC::ARMAssembler::replaceWithAddressComputation): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::convertibleLoadPtr): + (MacroAssemblerARM): + +2012-07-06 Filip Pizlo <fpizlo@apple.com> + + WebKit Version 5.1.7 (6534.57.2, r121935): Double-click no longer works on OpenStreetMap + https://bugs.webkit.org/show_bug.cgi?id=90703 + + Reviewed by Michael Saboff. + + It turns out that in my object model refactoring, I managed to fix get_by_pname in all + execution engines except 64-bit baseline JIT. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_pname): + +2012-07-06 Pravin D <pravind.2k4@gmail.com> + + Build Error on Qt Linux build + https://bugs.webkit.org/show_bug.cgi?id=90699 + + Reviewed by Laszlo Gombos. + + * parser/Parser.cpp: + (JSC::::parseForStatement): + Removed unused boolean variable as this was causing build error on Qt Linux. + +2012-07-06 Nuno Lopes <nlopes@apple.com> + + Fix build with recent clang. + https://bugs.webkit.org/show_bug.cgi?id=90634 + + Reviewed by Oliver Hunt. + + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::SpecializedThunkJIT): + (SpecializedThunkJIT): + * jit/ThunkGenerators.cpp: + (JSC::charCodeAtThunkGenerator): + (JSC::charAtThunkGenerator): + (JSC::fromCharCodeThunkGenerator): + (JSC::sqrtThunkGenerator): + (JSC::floorThunkGenerator): + (JSC::ceilThunkGenerator): + (JSC::roundThunkGenerator): + (JSC::expThunkGenerator): + (JSC::logThunkGenerator): + (JSC::absThunkGenerator): + (JSC::powThunkGenerator): + * parser/ASTBuilder.h: + (JSC::ASTBuilder::createAssignResolve): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::makeAssignNode): + (JSC::ASTBuilder::makePrefixNode): + (JSC::ASTBuilder::makePostfixNode): + * parser/NodeConstructors.h: + (JSC::PostfixErrorNode::PostfixErrorNode): + (JSC::PrefixErrorNode::PrefixErrorNode): + (JSC::AssignResolveNode::AssignResolveNode): + (JSC::AssignErrorNode::AssignErrorNode): + (JSC::ForNode::ForNode): + (JSC::ForInNode::ForInNode): + * parser/Nodes.h: + (FunctionCallResolveNode): + (PostfixErrorNode): + (PrefixErrorNode): + (ReadModifyResolveNode): + (AssignResolveNode): + (AssignErrorNode): + (ForNode): + (ForInNode): + * parser/Parser.cpp: + (JSC::::parseVarDeclarationList): + (JSC::::parseForStatement): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::createAssignResolve): + (JSC::SyntaxChecker::createForLoop): + +2012-07-06 Zoltan Herczeg <zherczeg@webkit.org> + + [Qt][ARM] REGRESSION(r121885): It broke 30 jsc tests, 500+ layout tests + https://bugs.webkit.org/show_bug.cgi?id=90656 + + Reviewed by Csaba Osztrogonác. + + Typo fixes. + + * assembler/MacroAssemblerARM.cpp: + (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): + Rename getOp2Byte() -> getOp2Half() + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::convertibleLoadPtr): + Add a necessary space. + * jit/JITStubs.cpp: + (JSC): + Revert INLINE_ARM_FUNCTION macro. + +2012-07-05 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r121925): It broke 5 sputnik tests on x86 platforms + https://bugs.webkit.org/show_bug.cgi?id=90658 + + Reviewed by Zoltan Herczeg. + + Under the new object model, out-of-line property accesses such as those + in ResolveGlobal must account for the fact that the offset to the Kth + property is represented by K + inlineStorageCapacity. Hence, the property + loads in ResolveGlobal must have an additional -inlineStorageCapacity * + sizeof(JSValue) offset. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-07-05 Csaba Osztrogonác <ossy@webkit.org> + + [Qt] Unreviewed 64 bit buildfix after r121925. + + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFromLLInt): + +2012-07-05 Michael Saboff <msaboff@apple.com> + + JSString::tryHashConstLock() fails to get exclusive lock + https://bugs.webkit.org/show_bug.cgi?id=90639 + + Reviewed by Oliver Hunt. + + Added check that the string is already locked even before compare and swap. + + * heap/MarkStack.cpp: + (JSC::JSString::tryHashConstLock): + +2012-07-04 Filip Pizlo <fpizlo@apple.com> + + Inline property storage should not be wasted when it is exhausted + https://bugs.webkit.org/show_bug.cgi?id=90347 + + Reviewed by Gavin Barraclough. + + Previously, if we switched an object from using inline storage to out-of-line + storage, we would abandon the inline storage. This would have two main implications: + (i) all accesses to the object, even for properties that were previously in inline + storage, must now take an extra indirection; and (ii) we waste a non-trivial amount + of space since we must allocate additional out-of-line storage to hold properties + that would have fit in the inline storage. There's also the copying cost when + switching to out-of-line storage - we must copy all inline properties into ouf-of-line + storage. + + This patch changes the way that object property storage works so that we can use both + inline and out-of-line storage concurrently. This is accomplished by introducing a + new notion of property offset. This PropertyOffset is a 32-bit signed integer and it + behaves as follows: + + offset == -1: invalid offset, indicating a property that does not exist. + + 0 <= offset <= inlineStorageCapacity: offset into inline storage. + + inlineStorageCapacity < offset: offset into out-of-line storage. + + Because non-final objects don't have inline storage, the only valid PropertyOffsets + for those objects' properties are -1 or > inlineStorageCapacity. + + This now means that the decision to use inline or out-of-line storage for an access is + made based on the offset, rather than the structure. It also means that any access + where the offset is a variable must have an extra branch, unless the type of the + object is also known (if it's known to be a non-final object then we can just assert + that the offset is >= inlineStorageCapacity). + + This looks like a big Kraken speed-up and a slight V8 speed-up. + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::ldrWide8BitImmediate): + (JSC::ARMv7Assembler::replaceWithLoad): + (JSC::ARMv7Assembler::replaceWithAddressComputation): + * assembler/AbstractMacroAssembler.h: + (AbstractMacroAssembler): + (ConvertibleLoadLabel): + (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel): + (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::isSet): + (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints): + (JSC::AbstractMacroAssembler::replaceWithLoad): + (JSC::AbstractMacroAssembler::replaceWithAddressComputation): + * assembler/CodeLocation.h: + (JSC): + (CodeLocationCommon): + (CodeLocationConvertibleLoad): + (JSC::CodeLocationConvertibleLoad::CodeLocationConvertibleLoad): + (JSC::CodeLocationCommon::convertibleLoadAtOffset): + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + * assembler/LinkBuffer.h: + (LinkBuffer): + (JSC::LinkBuffer::locationOf): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::convertibleLoadPtr): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::convertibleLoadPtr): + (MacroAssemblerX86): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::convertibleLoadPtr): + (MacroAssemblerX86_64): + * assembler/RepatchBuffer.h: + (RepatchBuffer): + (JSC::RepatchBuffer::replaceWithLoad): + (JSC::RepatchBuffer::replaceWithAddressComputation): + (JSC::RepatchBuffer::setLoadInstructionIsActive): + * assembler/X86Assembler.h: + (JSC::X86Assembler::replaceWithLoad): + (X86Assembler): + (JSC::X86Assembler::replaceWithAddressComputation): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printGetByIdOp): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::finalizeUnconditionally): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + (JSC::GetByIdStatus::computeForChain): + (JSC::GetByIdStatus::computeFor): + * bytecode/GetByIdStatus.h: + (JSC::GetByIdStatus::GetByIdStatus): + (JSC::GetByIdStatus::offset): + (GetByIdStatus): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFromLLInt): + (JSC::PutByIdStatus::computeFor): + * bytecode/PutByIdStatus.h: + (JSC::PutByIdStatus::PutByIdStatus): + (JSC::PutByIdStatus::offset): + (PutByIdStatus): + * bytecode/ResolveGlobalStatus.cpp: + (JSC): + (JSC::computeForStructure): + * bytecode/ResolveGlobalStatus.h: + (JSC::ResolveGlobalStatus::ResolveGlobalStatus): + (JSC::ResolveGlobalStatus::offset): + (ResolveGlobalStatus): + * bytecode/StructureSet.h: + (StructureSet): + * bytecode/StructureStubInfo.h: + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * dfg/DFGJITCompiler.h: + (JSC::DFG::PropertyAccessRecord::PropertyAccessRecord): + (PropertyAccessRecord): + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgRepatchByIdSelfAccess): + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::tryBuildGetByIDProtoList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::tryBuildPutByIdList): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::compile): + * heap/MarkStack.cpp: + (JSC::visitChildren): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::tryCacheGetByID): + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + (JSC::PropertyStubCompilationInfo::copyToStubInfo): + * jit/JIT.h: + (JSC::PropertyStubCompilationInfo::PropertyStubCompilationInfo): + (JSC::JIT::compileGetByIdProto): + (JSC::JIT::compileGetByIdSelfList): + (JSC::JIT::compileGetByIdProtoList): + (JSC::JIT::compileGetByIdChainList): + (JSC::JIT::compileGetByIdChain): + (JSC::JIT::compilePutByIdTransition): + (JIT): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_resolve_global): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_resolve_global): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::compileGetDirectOffset): + (JSC::JIT::emit_op_method_check): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::emit_op_put_by_id): + (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::patchGetByIdSelf): + (JSC::JIT::patchPutByIdReplace): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_method_check): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::emit_op_put_by_id): + (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::compileGetDirectOffset): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::patchGetByIdSelf): + (JSC::JIT::patchPutByIdReplace): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + (JSC::JIT::emit_op_get_by_pname): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCacheGetByID): + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/x86.rb: + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::functionNameOffset): + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + (JSC): + (JSC::JSFinalObject::visitChildren): + (JSC::JSObject::put): + (JSC::JSObject::deleteProperty): + (JSC::JSObject::getPropertySpecificValue): + (JSC::JSObject::removeDirect): + (JSC::JSObject::growOutOfLineStorage): + (JSC::JSObject::getOwnPropertyDescriptor): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::getDirect): + (JSC::JSObject::getDirectLocation): + (JSC::JSObject::hasInlineStorage): + (JSC::JSObject::inlineStorageUnsafe): + (JSC::JSObject::inlineStorage): + (JSC::JSObject::outOfLineStorage): + (JSC::JSObject::locationForOffset): + (JSC::JSObject::offsetForLocation): + (JSC::JSObject::getDirectOffset): + (JSC::JSObject::putDirectOffset): + (JSC::JSObject::putUndefinedAtDirectOffset): + (JSC::JSObject::addressOfOutOfLineStorage): + (JSC::JSObject::finishCreation): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC::JSNonFinalObject::finishCreation): + (JSFinalObject): + (JSC::JSFinalObject::finishCreation): + (JSC::JSFinalObject::JSFinalObject): + (JSC::JSObject::offsetOfOutOfLineStorage): + (JSC::JSObject::setOutOfLineStorage): + (JSC::JSObject::JSObject): + (JSC): + (JSC::JSCell::fastGetOwnProperty): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): + (JSC::JSObject::putDirectWithoutTransition): + (JSC::offsetRelativeToPatchedStorage): + (JSC::indexRelativeToBase): + (JSC::offsetRelativeToBase): + * runtime/JSPropertyNameIterator.cpp: + (JSC::JSPropertyNameIterator::create): + * runtime/JSPropertyNameIterator.h: + (JSPropertyNameIterator): + (JSC::JSPropertyNameIterator::getOffset): + (JSC::JSPropertyNameIterator::finishCreation): + * runtime/JSValue.cpp: + (JSC::JSValue::putToPrimitive): + * runtime/Operations.h: + (JSC::normalizePrototypeChain): + * runtime/Options.cpp: + (JSC): + (JSC::Options::initialize): + * runtime/PropertyMapHashTable.h: + (PropertyMapEntry): + (JSC::PropertyMapEntry::PropertyMapEntry): + (PropertyTable): + (JSC::PropertyTable::PropertyTable): + (JSC::PropertyTable::getDeletedOffset): + (JSC::PropertyTable::addDeletedOffset): + (JSC::PropertyTable::nextOffset): + (JSC): + (JSC::PropertyTable::sizeInMemory): + * runtime/PropertyOffset.h: Added. + (JSC): + (JSC::checkOffset): + (JSC::validateOffset): + (JSC::isValidOffset): + (JSC::isInlineOffset): + (JSC::isOutOfLineOffset): + (JSC::offsetInInlineStorage): + (JSC::offsetInOutOfLineStorage): + (JSC::offsetInRespectiveStorage): + (JSC::numberOfOutOfLineSlotsForLastOffset): + (JSC::numberOfSlotsForLastOffset): + (JSC::nextPropertyOffsetFor): + (JSC::firstPropertyOffsetFor): + * runtime/PropertySlot.h: + (JSC::PropertySlot::cachedOffset): + (JSC::PropertySlot::setValue): + (JSC::PropertySlot::setCacheableGetterSlot): + (JSC::PropertySlot::clearOffset): + * runtime/PutPropertySlot.h: + (JSC::PutPropertySlot::setExistingProperty): + (JSC::PutPropertySlot::setNewProperty): + (JSC::PutPropertySlot::cachedOffset): + (PutPropertySlot): + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::nextOutOfLineStorageCapacity): + (JSC::Structure::growOutOfLineCapacity): + (JSC::Structure::suggestedNewOutOfLineStorageCapacity): + (JSC::Structure::addPropertyTransitionToExistingStructure): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::removePropertyTransition): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::addPropertyWithoutTransition): + (JSC::Structure::removePropertyWithoutTransition): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::get): + (JSC::Structure::putSpecificValue): + (JSC::Structure::remove): + * runtime/Structure.h: + (Structure): + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::previousID): + (JSC::Structure::outOfLineCapacity): + (JSC::Structure::outOfLineSizeForKnownFinalObject): + (JSC::Structure::outOfLineSizeForKnownNonFinalObject): + (JSC::Structure::outOfLineSize): + (JSC::Structure::hasInlineStorage): + (JSC::Structure::inlineCapacity): + (JSC::Structure::inlineSizeForKnownFinalObject): + (JSC::Structure::inlineSize): + (JSC::Structure::totalStorageSize): + (JSC::Structure::totalStorageCapacity): + (JSC::Structure::firstValidOffset): + (JSC::Structure::lastValidOffset): + (JSC::Structure::isValidOffset): + (JSC::Structure::isEmpty): + (JSC::Structure::transitionCount): + (JSC::Structure::get): + +2012-07-05 Oliver Hunt <oliver@apple.com> + + JSObjectCallAsFunction should thisConvert the provided thisObject + https://bugs.webkit.org/show_bug.cgi?id=90628 + + Reviewed by Gavin Barraclough. + + Perform this conversion on the provided this object. + + * API/JSObjectRef.cpp: + (JSObjectCallAsFunction): + +2012-07-05 Zoltan Herczeg <zherczeg@webkit.org> + + [Qt] Unreviewed buildfix after r121886. Typo fix. + + * assembler/MacroAssemblerARM.cpp: + (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): + +2012-07-05 Zoltan Herczeg <zherczeg@webkit.org> + + Port DFG JIT to traditional ARM + https://bugs.webkit.org/show_bug.cgi?id=90198 + + Reviewed by Filip Pizlo. + + This patch contains the macro assembler part of the + DFG JIT support on ARM systems with fixed 32 bit instruction + width. A large amount of old code was refactored, and the ARMv4 + or lower support is removed from the macro assembler. + + Sunspider is improved by 8%, and V8 is 92%. + + * assembler/ARMAssembler.cpp: + (JSC::ARMAssembler::dataTransfer32): + (JSC::ARMAssembler::baseIndexTransfer32): + (JSC): + (JSC::ARMAssembler::dataTransfer16): + (JSC::ARMAssembler::baseIndexTransfer16): + (JSC::ARMAssembler::dataTransferFloat): + (JSC::ARMAssembler::baseIndexTransferFloat): + (JSC::ARMAssembler::executableCopy): + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::ARMAssembler): + (JSC::ARMAssembler::emitInst): + (JSC::ARMAssembler::vmov_f64_r): + (ARMAssembler): + (JSC::ARMAssembler::vabs_f64_r): + (JSC::ARMAssembler::vneg_f64_r): + (JSC::ARMAssembler::ldr_imm): + (JSC::ARMAssembler::ldr_un_imm): + (JSC::ARMAssembler::dtr_u): + (JSC::ARMAssembler::dtr_ur): + (JSC::ARMAssembler::dtr_d): + (JSC::ARMAssembler::dtr_dr): + (JSC::ARMAssembler::dtrh_u): + (JSC::ARMAssembler::dtrh_ur): + (JSC::ARMAssembler::dtrh_d): + (JSC::ARMAssembler::dtrh_dr): + (JSC::ARMAssembler::fdtr_u): + (JSC::ARMAssembler::fdtr_d): + (JSC::ARMAssembler::push_r): + (JSC::ARMAssembler::pop_r): + (JSC::ARMAssembler::poke_r): + (JSC::ARMAssembler::peek_r): + (JSC::ARMAssembler::vmov_vfp64_r): + (JSC::ARMAssembler::vmov_arm64_r): + (JSC::ARMAssembler::vmov_vfp32_r): + (JSC::ARMAssembler::vmov_arm32_r): + (JSC::ARMAssembler::vcvt_u32_f64_r): + (JSC::ARMAssembler::vcvt_f64_f32_r): + (JSC::ARMAssembler::vcvt_f32_f64_r): + (JSC::ARMAssembler::clz_r): + (JSC::ARMAssembler::bkpt): + (JSC::ARMAssembler::bx): + (JSC::ARMAssembler::blx): + (JSC::ARMAssembler::labelIgnoringWatchpoints): + (JSC::ARMAssembler::labelForWatchpoint): + (JSC::ARMAssembler::label): + (JSC::ARMAssembler::getLdrImmAddress): + (JSC::ARMAssembler::replaceWithJump): + (JSC::ARMAssembler::maxJumpReplacementSize): + (JSC::ARMAssembler::getOp2Byte): + (JSC::ARMAssembler::getOp2Half): + (JSC::ARMAssembler::RM): + (JSC::ARMAssembler::RS): + (JSC::ARMAssembler::RD): + (JSC::ARMAssembler::RN): + * assembler/AssemblerBufferWithConstantPool.h: + (JSC::AssemblerBufferWithConstantPool::ensureSpaceForAnyInstruction): + * assembler/MacroAssemblerARM.cpp: + (JSC::MacroAssemblerARM::load32WithUnalignedHalfWords): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::add32): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::and32): + (JSC::MacroAssemblerARM::lshift32): + (JSC::MacroAssemblerARM::mul32): + (JSC::MacroAssemblerARM::neg32): + (JSC::MacroAssemblerARM::rshift32): + (JSC::MacroAssemblerARM::urshift32): + (JSC::MacroAssemblerARM::xor32): + (JSC::MacroAssemblerARM::load8): + (JSC::MacroAssemblerARM::load8Signed): + (JSC::MacroAssemblerARM::load16): + (JSC::MacroAssemblerARM::load16Signed): + (JSC::MacroAssemblerARM::load32): + (JSC::MacroAssemblerARM::load32WithAddressOffsetPatch): + (JSC::MacroAssemblerARM::store32WithAddressOffsetPatch): + (JSC::MacroAssemblerARM::store8): + (JSC::MacroAssemblerARM::store16): + (JSC::MacroAssemblerARM::store32): + (JSC::MacroAssemblerARM::move): + (JSC::MacroAssemblerARM::jump): + (JSC::MacroAssemblerARM::branchAdd32): + (JSC::MacroAssemblerARM::mull32): + (JSC::MacroAssemblerARM::branchMul32): + (JSC::MacroAssemblerARM::nearCall): + (JSC::MacroAssemblerARM::compare32): + (JSC::MacroAssemblerARM::test32): + (JSC::MacroAssemblerARM::sub32): + (JSC::MacroAssemblerARM::call): + (JSC::MacroAssemblerARM::loadFloat): + (JSC::MacroAssemblerARM::loadDouble): + (JSC::MacroAssemblerARM::storeFloat): + (JSC::MacroAssemblerARM::storeDouble): + (JSC::MacroAssemblerARM::moveDouble): + (JSC::MacroAssemblerARM::addDouble): + (JSC::MacroAssemblerARM::divDouble): + (JSC::MacroAssemblerARM::subDouble): + (JSC::MacroAssemblerARM::mulDouble): + (JSC::MacroAssemblerARM::absDouble): + (JSC::MacroAssemblerARM::negateDouble): + (JSC::MacroAssemblerARM::convertInt32ToDouble): + (JSC::MacroAssemblerARM::convertFloatToDouble): + (JSC::MacroAssemblerARM::convertDoubleToFloat): + (JSC::MacroAssemblerARM::branchTruncateDoubleToInt32): + (JSC::MacroAssemblerARM::branchTruncateDoubleToUint32): + (JSC::MacroAssemblerARM::truncateDoubleToInt32): + (JSC::MacroAssemblerARM::truncateDoubleToUint32): + (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): + (JSC::MacroAssemblerARM::branchDoubleNonZero): + (JSC::MacroAssemblerARM::branchDoubleZeroOrNaN): + (JSC::MacroAssemblerARM::invert): + (JSC::MacroAssemblerARM::replaceWithJump): + (JSC::MacroAssemblerARM::maxJumpReplacementSize): + (JSC::MacroAssemblerARM::call32): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::label): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::debugCall): + (JSC::DFG::AssemblyHelpers::boxDouble): + (JSC::DFG::AssemblyHelpers::unboxDouble): + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArguments): + * dfg/DFGFPRInfo.h: + (DFG): + * dfg/DFGGPRInfo.h: + (DFG): + (GPRInfo): + * dfg/DFGOperations.cpp: + (JSC): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): + (JSC::DFG::SpeculativeJIT::appendCallSetResult): + * jit/JITStubs.cpp: + (JSC): + * jit/JITStubs.h: + (JITStackFrame): + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + +2012-07-04 Anthony Scian <ascian@rim.com> + + Web Inspector [JSC]: Implement ScriptCallStack::stackTrace + https://bugs.webkit.org/show_bug.cgi?id=40118 + + Reviewed by Yong Li. + + Added member functions to expose function name, urlString, and line #. + Refactored toString to make use of these member functions to reduce + duplicated code for future maintenance. + + Manually tested refactoring of toString by tracing thrown exceptions. + + * interpreter/Interpreter.h: + (JSC::StackFrame::toString): + (JSC::StackFrame::friendlySourceURL): + (JSC::StackFrame::friendlyFunctionName): + (JSC::StackFrame::friendlyLineNumber): + +2012-07-04 Andy Wingo <wingo@igalia.com> + + [GTK] Enable parallel GC + https://bugs.webkit.org/show_bug.cgi?id=90568 + + Reviewed by Martin Robinson. + + * runtime/Options.cpp: Include <algorithm.h> for std::min. + +2012-07-04 John Mellor <johnme@chromium.org> + + Text Autosizing: Add compile flag and runtime setting + https://bugs.webkit.org/show_bug.cgi?id=87394 + + This patch renames Font Boosting to Text Autosizing. + + Reviewed by Adam Barth. + + * Configurations/FeatureDefines.xcconfig: + +2012-07-03 Michael Saboff <msaboff@apple.com> + + Enh: Hash Const JSString in Backing Stores to Save Memory + https://bugs.webkit.org/show_bug.cgi?id=86024 + + Reviewed by Oliver Hunt. + + During garbage collection, each marking thread keeps a HashMap of + strings. While visiting via MarkStack::copyAndAppend(), we check to + see if the string we are visiting is already in the HashMap. If not + we add it. If so, we change the reference to the current string we're + visiting to the prior string. + + To reduce the performance impact of this change, two throttles have + ben added. 1) We only try hash consting if a significant number of new + strings have been created since the last hash const. Currently this is + set at 100 strings. 2) If a string is unique at the end of a marking + it will not be checked during further GC phases. In some cases this + won't catch all duplicates, but we are trying to catch the growth of + duplicate strings. + + * heap/Heap.cpp: + (JSC::Heap::markRoots): + * heap/MarkStack.cpp: + (JSC::MarkStackThreadSharedData::resetChildren): + (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): + (JSC::MarkStackThreadSharedData::reset): + (JSC::MarkStack::setup): Check to see if enough strings have been created + to hash const. + (JSC::MarkStack::reset): Added call to clear m_uniqueStrings. + (JSC::JSString::tryHashConstLock): New method to lock JSString for + hash consting. + (JSC::JSString::releaseHashConstLock): New unlock method. + (JSC::JSString::shouldTryHashConst): Set of checks to see if we should + try to hash const the string. + (JSC::MarkStack::internalAppend): New method that performs the hash consting. + (JSC::SlotVisitor::copyAndAppend): Changed to call the new hash + consting internalAppend(). + * heap/MarkStack.h: + (MarkStackThreadSharedData): + (MarkStack): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::haveEnoughNewStringsToHashConst): + (JSC::JSGlobalData::resetNewStringsSinceLastHashConst): + * runtime/JSString.h: + (JSString): Changed from using bool flags to using an unsigned + m_flags field. This works better with the weakCompareAndSwap in + JSString::tryHashConstLock(). Changed the 8bitness setting and + checking to use new accessors. + (JSC::JSString::JSString): + (JSC::JSString::finishCreation): + (JSC::JSString::is8Bit): Updated for new m_flags. + (JSC::JSString::setIs8Bit): New setter. + New hash const flags accessors: + (JSC::JSString::isHashConstSingleton): + (JSC::JSString::clearHashConstSingleton): + (JSC::JSString::setHashConstSingleton): + (JSC::JSRopeString::finishCreation): + (JSC::JSRopeString::append): + +2012-07-03 Tony Chang <tony@chromium.org> + + [chromium] Unreviewed, update .gitignore to handle VS2010 files. + + * JavaScriptCore.gyp/.gitignore: + +2012-07-03 Mark Lam <mark.lam@apple.com> + + Add ability to symbolically set and dump JSC VM options. + See comments in runtime/Options.h for details on how the options work. + https://bugs.webkit.org/show_bug.cgi?id=90420 + + Reviewed by Filip Pizlo. + + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + * assembler/LinkBuffer.h: + (JSC): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::shouldOptimizeNow): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::likelyToTakeSlowCase): + (JSC::CodeBlock::couldTakeSlowCase): + (JSC::CodeBlock::likelyToTakeSpecialFastCase): + (JSC::CodeBlock::likelyToTakeDeepestSlowCase): + (JSC::CodeBlock::likelyToTakeAnySlowCase): + (JSC::CodeBlock::jitAfterWarmUp): + (JSC::CodeBlock::jitSoon): + (JSC::CodeBlock::reoptimizationRetryCounter): + (JSC::CodeBlock::countReoptimization): + (JSC::CodeBlock::counterValueForOptimizeAfterWarmUp): + (JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp): + (JSC::CodeBlock::optimizeSoon): + (JSC::CodeBlock::exitCountThresholdForReoptimization): + (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): + * bytecode/ExecutionCounter.h: + (JSC::ExecutionCounter::clippedThreshold): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + * dfg/DFGCapabilities.h: + (JSC::DFG::mightCompileEval): + (JSC::DFG::mightCompileProgram): + (JSC::DFG::mightCompileFunctionForCall): + (JSC::DFG::mightCompileFunctionForConstruct): + (JSC::DFG::mightInlineFunctionForCall): + (JSC::DFG::mightInlineFunctionForConstruct): + * dfg/DFGCommon.h: + (JSC::DFG::shouldShowDisassembly): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): + * heap/MarkStack.cpp: + (JSC::MarkStackSegmentAllocator::allocate): + (JSC::MarkStackSegmentAllocator::shrinkReserve): + (JSC::MarkStackArray::MarkStackArray): + (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): + (JSC::SlotVisitor::donateKnownParallel): + (JSC::SlotVisitor::drain): + (JSC::SlotVisitor::drainFromShared): + * heap/MarkStack.h: + (JSC::MarkStack::mergeOpaqueRootsIfProfitable): + (JSC::MarkStack::addOpaqueRoot): + * heap/SlotVisitor.h: + (JSC::SlotVisitor::donate): + * jit/JIT.cpp: + (JSC::JIT::emitOptimizationCheck): + * jsc.cpp: + (printUsageStatement): + (parseArguments): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): + * runtime/JSGlobalData.cpp: + (JSC::enableAssembler): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + * runtime/Options.cpp: + (JSC): + (JSC::overrideOptionWithHeuristic): + (JSC::Options::initialize): + (JSC::Options::setOption): + (JSC::Options::dumpAllOptions): + (JSC::Options::dumpOption): + * runtime/Options.h: + (JSC): + (Options): + (EntryInfo): + +2012-07-03 Jocelyn Turcotte <jocelyn.turcotte@nokia.com> Joel Dillon <joel.dillon@codethink.co.uk> + + [Qt][Win] Fix broken QtWebKit5.lib linking + https://bugs.webkit.org/show_bug.cgi?id=88321 + + Reviewed by Kenneth Rohde Christiansen. + + The goal is to have different ports build systems define STATICALLY_LINKED_WITH_WTF + when building JavaScriptCore, if both are packaged in the same DLL, instead + of relying on the code to handle this. + The effects of BUILDING_* and STATICALLY_LINKED_WITH_* are currently the same + except for a check in Source/JavaScriptCore/config.h. + + Keeping the old way for the WX port as requested by the port's contributors. + For non-Windows ports there is no difference between IMPORT and EXPORT, no + change is needed. + + * API/JSBase.h: + JS symbols shouldn't be included by WTF objects anymore. Remove the export when BUILDING_WTF. + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: + Make sure that JavaScriptCore uses import symbols of WTF for the Win port. + * runtime/JSExportMacros.h: + +2012-07-02 Filip Pizlo <fpizlo@apple.com> + + DFG OSR exit value recoveries should be computed lazily + https://bugs.webkit.org/show_bug.cgi?id=82155 + + Reviewed by Gavin Barraclough. + + This change aims to reduce one aspect of DFG compile times: the fact + that we currently compute the value recoveries for each local and + argument on every speculation check. We compile many speculation checks, + so this can add up quick. The strategy that this change takes is to + have the DFG save just enough information about how the compiler is + choosing to represent state, that the DFG::OSRExitCompiler can reify + the value recoveries lazily. + + This appears to be an 0.3% SunSpider speed-up and is neutral elsewhere. + + I also took the opportunity to fix the sampling regions profiler (it + was missing an export macro) and to put in more sampling regions in + the DFG (which are disabled so long as ENABLE(SAMPLING_REGIONS) is + false). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::CodeBlock::shrinkDFGDataToFit): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::minifiedDFG): + (JSC::CodeBlock::variableEventStream): + (DFGData): + * bytecode/Operands.h: + (JSC::Operands::hasOperand): + (Operands): + (JSC::Operands::size): + (JSC::Operands::at): + (JSC::Operands::operator[]): + (JSC::Operands::isArgument): + (JSC::Operands::isVariable): + (JSC::Operands::argumentForIndex): + (JSC::Operands::variableForIndex): + (JSC::Operands::operandForIndex): + (JSC): + (JSC::dumpOperands): + * bytecode/SamplingTool.h: + (SamplingRegion): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::parse): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::performCFA): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::performCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::performFixup): + * dfg/DFGGenerationInfo.h: + (JSC::DFG::GenerationInfo::GenerationInfo): + (JSC::DFG::GenerationInfo::initConstant): + (JSC::DFG::GenerationInfo::initInteger): + (JSC::DFG::GenerationInfo::initJSValue): + (JSC::DFG::GenerationInfo::initCell): + (JSC::DFG::GenerationInfo::initBoolean): + (JSC::DFG::GenerationInfo::initDouble): + (JSC::DFG::GenerationInfo::initStorage): + (GenerationInfo): + (JSC::DFG::GenerationInfo::noticeOSRBirth): + (JSC::DFG::GenerationInfo::use): + (JSC::DFG::GenerationInfo::spill): + (JSC::DFG::GenerationInfo::setSpilled): + (JSC::DFG::GenerationInfo::fillJSValue): + (JSC::DFG::GenerationInfo::fillCell): + (JSC::DFG::GenerationInfo::fillInteger): + (JSC::DFG::GenerationInfo::fillBoolean): + (JSC::DFG::GenerationInfo::fillDouble): + (JSC::DFG::GenerationInfo::fillStorage): + (JSC::DFG::GenerationInfo::appendFill): + (JSC::DFG::GenerationInfo::appendSpill): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGMinifiedGraph.h: Added. + (DFG): + (MinifiedGraph): + (JSC::DFG::MinifiedGraph::MinifiedGraph): + (JSC::DFG::MinifiedGraph::at): + (JSC::DFG::MinifiedGraph::append): + (JSC::DFG::MinifiedGraph::prepareAndShrink): + (JSC::DFG::MinifiedGraph::setOriginalGraphSize): + (JSC::DFG::MinifiedGraph::originalGraphSize): + * dfg/DFGMinifiedNode.cpp: Added. + (DFG): + (JSC::DFG::MinifiedNode::fromNode): + * dfg/DFGMinifiedNode.h: Added. + (DFG): + (JSC::DFG::belongsInMinifiedGraph): + (MinifiedNode): + (JSC::DFG::MinifiedNode::MinifiedNode): + (JSC::DFG::MinifiedNode::index): + (JSC::DFG::MinifiedNode::op): + (JSC::DFG::MinifiedNode::hasChild1): + (JSC::DFG::MinifiedNode::child1): + (JSC::DFG::MinifiedNode::hasConstant): + (JSC::DFG::MinifiedNode::hasConstantNumber): + (JSC::DFG::MinifiedNode::constantNumber): + (JSC::DFG::MinifiedNode::hasWeakConstant): + (JSC::DFG::MinifiedNode::weakConstant): + (JSC::DFG::MinifiedNode::getIndex): + (JSC::DFG::MinifiedNode::compareByNodeIndex): + (JSC::DFG::MinifiedNode::hasChild): + * dfg/DFGNode.h: + (Node): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler.h: + (OSRExitCompiler): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::performPredictionPropagation): + * dfg/DFGRedundantPhiEliminationPhase.cpp: + (JSC::DFG::performRedundantPhiElimination): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::SpeculativeJIT): + (DFG): + (JSC::DFG::SpeculativeJIT::fillStorage): + (JSC::DFG::SpeculativeJIT::noticeOSRBirth): + (JSC::DFG::SpeculativeJIT::compileMovHint): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + * dfg/DFGSpeculativeJIT.h: + (DFG): + (JSC::DFG::SpeculativeJIT::use): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::spill): + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::recordSetLocal): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGValueRecoveryOverride.h: Added. + (DFG): + (ValueRecoveryOverride): + (JSC::DFG::ValueRecoveryOverride::ValueRecoveryOverride): + * dfg/DFGValueSource.cpp: Added. + (DFG): + (JSC::DFG::ValueSource::dump): + * dfg/DFGValueSource.h: Added. + (DFG): + (JSC::DFG::dataFormatToValueSourceKind): + (JSC::DFG::valueSourceKindToDataFormat): + (JSC::DFG::isInRegisterFile): + (ValueSource): + (JSC::DFG::ValueSource::ValueSource): + (JSC::DFG::ValueSource::forPrediction): + (JSC::DFG::ValueSource::forDataFormat): + (JSC::DFG::ValueSource::isSet): + (JSC::DFG::ValueSource::kind): + (JSC::DFG::ValueSource::isInRegisterFile): + (JSC::DFG::ValueSource::dataFormat): + (JSC::DFG::ValueSource::valueRecovery): + (JSC::DFG::ValueSource::nodeIndex): + (JSC::DFG::ValueSource::nodeIndexFromKind): + (JSC::DFG::ValueSource::kindFromNodeIndex): + * dfg/DFGVariableEvent.cpp: Added. + (DFG): + (JSC::DFG::VariableEvent::dump): + (JSC::DFG::VariableEvent::dumpFillInfo): + (JSC::DFG::VariableEvent::dumpSpillInfo): + * dfg/DFGVariableEvent.h: Added. + (DFG): + (VariableEvent): + (JSC::DFG::VariableEvent::VariableEvent): + (JSC::DFG::VariableEvent::reset): + (JSC::DFG::VariableEvent::fillGPR): + (JSC::DFG::VariableEvent::fillPair): + (JSC::DFG::VariableEvent::fillFPR): + (JSC::DFG::VariableEvent::spill): + (JSC::DFG::VariableEvent::death): + (JSC::DFG::VariableEvent::setLocal): + (JSC::DFG::VariableEvent::movHint): + (JSC::DFG::VariableEvent::kind): + (JSC::DFG::VariableEvent::nodeIndex): + (JSC::DFG::VariableEvent::dataFormat): + (JSC::DFG::VariableEvent::gpr): + (JSC::DFG::VariableEvent::tagGPR): + (JSC::DFG::VariableEvent::payloadGPR): + (JSC::DFG::VariableEvent::fpr): + (JSC::DFG::VariableEvent::virtualRegister): + (JSC::DFG::VariableEvent::operand): + (JSC::DFG::VariableEvent::variableRepresentation): + * dfg/DFGVariableEventStream.cpp: Added. + (DFG): + (JSC::DFG::VariableEventStream::logEvent): + (MinifiedGenerationInfo): + (JSC::DFG::MinifiedGenerationInfo::MinifiedGenerationInfo): + (JSC::DFG::MinifiedGenerationInfo::update): + (JSC::DFG::VariableEventStream::reconstruct): + * dfg/DFGVariableEventStream.h: Added. + (DFG): + (VariableEventStream): + (JSC::DFG::VariableEventStream::appendAndLog): + * dfg/DFGVirtualRegisterAllocationPhase.cpp: + (JSC::DFG::performVirtualRegisterAllocation): + +2012-07-02 Filip Pizlo <fpizlo@apple.com> + + DFG::ArgumentsSimplificationPhase should assert that the PhantomArguments nodes it creates are not shouldGenerate() + https://bugs.webkit.org/show_bug.cgi?id=90407 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + +2012-07-02 Gavin Barraclough <barraclough@apple.com> + + Array.prototype.pop should throw if property is not configurable + https://bugs.webkit.org/show_bug.cgi?id=75788 + + Rubber Stamped by Oliver Hunt. + + No real bug here any more, but the error we throw sometimes has a misleading message. + + * runtime/JSArray.cpp: + (JSC::JSArray::pop): + +2012-06-29 Filip Pizlo <fpizlo@apple.com> + + JSObject wastes too much memory on unused property slots + https://bugs.webkit.org/show_bug.cgi?id=90255 + + Reviewed by Mark Hahnenberg. + + Rolling back in after applying a simple fix: it appears that + JSObject::setStructureAndReallocateStorageIfNecessary() was allocating more + property storage than necessary. Fixing this appears to resolve the crash. + + This does a few things: + + - JSNonFinalObject no longer has inline property storage. + + - Initial out-of-line property storage size is 4 slots for JSNonFinalObject, + or 2x the inline storage for JSFinalObject. + + - Property storage is only reallocated if it needs to be. Previously, we + would reallocate the property storage on any transition where the original + structure said shouldGrowProperyStorage(), but this led to spurious + reallocations when doing transitionless property adds and there are + deleted property slots available. That in turn led to crashes, because we + would switch to out-of-line storage even if the capacity matched the + criteria for inline storage. + + - Inline JSFunction allocation is killed off because we don't have a good + way of inlining property storage allocation. This didn't hurt performance. + Killing off code is better than fixing it if that code wasn't doing any + good. + + This looks like a 1% progression on V8. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_func): + (JSC): + (JSC::JIT::emit_op_new_func_exp): + * runtime/JSFunction.cpp: + (JSC::JSFunction::finishCreation): + * runtime/JSObject.h: + (JSC::JSObject::isUsingInlineStorage): + (JSObject): + (JSC::JSObject::finishCreation): + (JSC): + (JSC::JSNonFinalObject::hasInlineStorage): + (JSNonFinalObject): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC::JSNonFinalObject::finishCreation): + (JSC::JSFinalObject::hasInlineStorage): + (JSC::JSFinalObject::finishCreation): + (JSC::JSObject::offsetOfInlineStorage): + (JSC::JSObject::setPropertyStorage): + (JSC::Structure::inlineStorageCapacity): + (JSC::Structure::isUsingInlineStorage): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): + (JSC::JSObject::putDirectWithoutTransition): + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::nextPropertyStorageCapacity): + (JSC): + (JSC::Structure::growPropertyStorageCapacity): + (JSC::Structure::suggestedNewPropertyStorageSize): + * runtime/Structure.h: + (JSC::Structure::putWillGrowPropertyStorage): + (Structure): + +2012-06-29 Filip Pizlo <fpizlo@apple.com> + + Webkit crashes in DFG on Google Docs when creating a new document + https://bugs.webkit.org/show_bug.cgi?id=90209 + + Reviewed by Gavin Barraclough. + + Don't attempt to short-circuit Phantom(GetLocal) if the GetLocal is for a + captured variable. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-06-30 Zan Dobersek <zandobersek@gmail.com> + + Unreviewed, rolling out r121605. + http://trac.webkit.org/changeset/121605 + https://bugs.webkit.org/show_bug.cgi?id=90336 + + Changes caused flaky crashes in sputnik/Unicode tests on Apple + WK1 and GTK Linux builders + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC::JIT::emitAllocateJSFinalObject): + (JSC): + (JSC::JIT::emitAllocateJSFunction): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_func): + (JSC::JIT::emitSlow_op_new_func): + (JSC): + (JSC::JIT::emit_op_new_func_exp): + (JSC::JIT::emitSlow_op_new_func_exp): + * runtime/JSFunction.cpp: + (JSC::JSFunction::finishCreation): + * runtime/JSObject.h: + (JSC::JSObject::isUsingInlineStorage): + (JSObject): + (JSC::JSObject::finishCreation): + (JSC): + (JSNonFinalObject): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC::JSNonFinalObject::finishCreation): + (JSFinalObject): + (JSC::JSFinalObject::finishCreation): + (JSC::JSObject::offsetOfInlineStorage): + (JSC::JSObject::setPropertyStorage): + (JSC::Structure::isUsingInlineStorage): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::putDirectWithoutTransition): + (JSC::JSObject::transitionTo): + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC): + (JSC::Structure::growPropertyStorageCapacity): + (JSC::Structure::suggestedNewPropertyStorageSize): + * runtime/Structure.h: + (JSC::Structure::shouldGrowPropertyStorage): + (JSC::Structure::propertyStorageSize): + +2012-06-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove warning about protected values when the Heap is being destroyed + https://bugs.webkit.org/show_bug.cgi?id=90302 + + Reviewed by Geoffrey Garen. + + Having to do book-keeping about whether values allocated from a certain + VM are or are not protected makes the JSC API much more difficult to use + correctly. Clients should be able to throw an entire VM away and not have + to worry about unprotecting all of the values that they protected earlier. + + * heap/Heap.cpp: + (JSC::Heap::lastChanceToFinalize): + +2012-06-29 Filip Pizlo <fpizlo@apple.com> + + JSObject wastes too much memory on unused property slots + https://bugs.webkit.org/show_bug.cgi?id=90255 + + Reviewed by Mark Hahnenberg. + + This does a few things: + + - JSNonFinalObject no longer has inline property storage. + + - Initial out-of-line property storage size is 4 slots for JSNonFinalObject, + or 2x the inline storage for JSFinalObject. + + - Property storage is only reallocated if it needs to be. Previously, we + would reallocate the property storage on any transition where the original + structure said shouldGrowProperyStorage(), but this led to spurious + reallocations when doing transitionless property adds and there are + deleted property slots available. That in turn led to crashes, because we + would switch to out-of-line storage even if the capacity matched the + criteria for inline storage. + + - Inline JSFunction allocation is killed off because we don't have a good + way of inlining property storage allocation. This didn't hurt performance. + Killing off code is better than fixing it if that code wasn't doing any + good. + + This looks like a 1% progression on V8. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_func): + (JSC): + (JSC::JIT::emit_op_new_func_exp): + * runtime/JSFunction.cpp: + (JSC::JSFunction::finishCreation): + * runtime/JSObject.h: + (JSC::JSObject::isUsingInlineStorage): + (JSObject): + (JSC::JSObject::finishCreation): + (JSC): + (JSC::JSNonFinalObject::hasInlineStorage): + (JSNonFinalObject): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC::JSNonFinalObject::finishCreation): + (JSC::JSFinalObject::hasInlineStorage): + (JSC::JSFinalObject::finishCreation): + (JSC::JSObject::offsetOfInlineStorage): + (JSC::JSObject::setPropertyStorage): + (JSC::Structure::inlineStorageCapacity): + (JSC::Structure::isUsingInlineStorage): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): + (JSC::JSObject::putDirectWithoutTransition): + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::nextPropertyStorageCapacity): + (JSC): + (JSC::Structure::growPropertyStorageCapacity): + (JSC::Structure::suggestedNewPropertyStorageSize): + * runtime/Structure.h: + (JSC::Structure::putWillGrowPropertyStorage): + (Structure): + +2012-06-28 Filip Pizlo <fpizlo@apple.com> + + DFG recompilation heuristics should be based on count, not rate + https://bugs.webkit.org/show_bug.cgi?id=90146 + + Reviewed by Oliver Hunt. + + This removes a bunch of code that was previously trying to prevent spurious + reoptimizations if a large enough majority of executions of a code block did + not result in OSR exit. It turns out that this code was purely harmful. This + patch removes all of that logic and replaces it with a dead-simple + heuristic: if you exit more than N times (where N is an exponential function + of the number of times the code block has already been recompiled) then we + will recompile. + + This appears to be a broad ~1% win on many benchmarks large and small. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::osrExitCounter): + (JSC::CodeBlock::countOSRExit): + (CodeBlock): + (JSC::CodeBlock::addressOfOSRExitCounter): + (JSC::CodeBlock::offsetOfOSRExitCounter): + (JSC::CodeBlock::adjustedExitCountThreshold): + (JSC::CodeBlock::exitCountThresholdForReoptimization): + (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): + (JSC::CodeBlock::shouldReoptimizeNow): + (JSC::CodeBlock::shouldReoptimizeFromLoopNow): + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::setThreshold): + * bytecode/ExecutionCounter.h: + (ExecutionCounter): + (JSC::ExecutionCounter::clippedThreshold): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compileBody): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGOSRExitCompiler.cpp: + (JSC::DFG::OSRExitCompiler::handleExitCounts): + * dfg/DFGOperations.cpp: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/Options.cpp: + (Options): + (JSC::Options::initializeOptions): + * runtime/Options.h: + (Options): + +2012-06-28 Mark Lam <mark.lam@apple.com> + + Adding a commenting utility to record BytecodeGenerator comments + with opcodes that are emitted. Presently, the comments can only + be constant strings. Adding comments for opcodes is optional. + If a comment is added, the comment will be printed following the + opcode when CodeBlock::dump() is called. + + This utility is disabled by default, and is only meant for VM + development purposes. It should not be enabled for product builds. + + To enable this utility, set ENABLE_BYTECODE_COMMENTS in CodeBlock.h + to 1. + + https://bugs.webkit.org/show_bug.cgi?id=90095 + + Reviewed by Geoffrey Garen. + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): Dumps the comment. + (JSC): + (JSC::CodeBlock::printUnaryOp): Add comment dumps. + (JSC::CodeBlock::printBinaryOp): Add comment dumps. + (JSC::CodeBlock::printConditionalJump): Add comment dumps. + (JSC::CodeBlock::printCallOp): Add comment dumps. + (JSC::CodeBlock::printPutByIdOp): Add comment dumps. + (JSC::CodeBlock::dump): Add comment dumps. + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::commentForBytecodeOffset): + Finds the comment for an opcode if available. + (JSC::CodeBlock::dumpBytecodeComments): + For debugging whether comments are collected. + It is not being called anywhere. + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::bytecodeComments): + * bytecode/Comment.h: Added. + (JSC): + (Comment): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::emitOpcode): Calls emitComment(). + (JSC): + (JSC::BytecodeGenerator::emitComment): Adds comment to CodeBlock. + (JSC::BytecodeGenerator::prependComment): + Registers a comment for emitComemnt() to use later. + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + (JSC::BytecodeGenerator::emitComment): + (JSC::BytecodeGenerator::prependComment): + These are inlined versions of these functions that nullify them + when ENABLE_BYTECODE_COMMENTS is 0. + (JSC::BytecodeGenerator::comments): + +2012-06-28 Oliver Hunt <oliver@apple.com> + + 32bit DFG incorrectly claims an fpr is fillable even if it has not been proven double + https://bugs.webkit.org/show_bug.cgi?id=90127 + + Reviewed by Filip Pizlo. + + The 32-bit version of fillSpeculateDouble doesn't handle Number->fpr loads + correctly. This patch fixes this by killing the fill info in the GenerationInfo + when the spillFormat doesn't guarantee the value is a double. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + +2012-06-28 Kent Tamura <tkent@chromium.org> + + Classify form control states by their owner forms + https://bugs.webkit.org/show_bug.cgi?id=89950 + + Reviewed by Hajime Morita. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + Expose WTF::StringBuilder::canShrink() + +2012-06-27 Michael Saboff <msaboff@apple.com> + + [Win] jscore-tests flakey + https://bugs.webkit.org/show_bug.cgi?id=88118 + + Reviewed by Jessie Berlin. + + jsDriver.pl on windows intermittently doesn't get the returned value from jsc, + instead it gets 126. Added a new option to jsc (-x) which prints the exit + code before exiting. jsDriver.pl uses this option on Windows and parses the + exit code output for the exit code, removing it before comparing the actual + and expected outputs. Filed a follow on "FIXME" defect: + [WIN] Intermittent failure for jsc return value to propagate through jsDriver.pl + https://bugs.webkit.org/show_bug.cgi?id=90119 + + * jsc.cpp: + (CommandLine::CommandLine): + (CommandLine): + (printUsageStatement): + (parseArguments): + (jscmain): + * tests/mozilla/jsDriver.pl: + (execute_tests): + +2012-06-27 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r121359. + http://trac.webkit.org/changeset/121359 + https://bugs.webkit.org/show_bug.cgi?id=90115 + + Broke many inspector tests (Requested by jpfau on #webkit). + + * interpreter/Interpreter.h: + (JSC::StackFrame::toString): + +2012-06-27 Filip Pizlo <fpizlo@apple.com> + + Javascript SHA-512 gives wrong hash on second and subsequent runs unless Web Inspector Javascript Debugging is on + https://bugs.webkit.org/show_bug.cgi?id=90053 + <rdar://problem/11764613> + + Reviewed by Mark Hahnenberg. + + The problem is that the code was assuming that the recovery should be Undefined if the source of + the SetLocal was !shouldGenerate(). But that's wrong, since the DFG optimizer may skip around a + UInt32ToNumber node (hence making it !shouldGenerate()) and keep the source of that node alive. + In that case we should base the recovery on the source of the UInt32ToNumber. The logic for this + was already in place but the fast check for !shouldGenerate() broke it. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + +2012-06-27 Filip Pizlo <fpizlo@apple.com> + + DFG disassembly should be easier to read + https://bugs.webkit.org/show_bug.cgi?id=90106 + + Reviewed by Mark Hahnenberg. + + Did a few things: + + - Options::showDFGDisassembly now shows OSR exit disassembly as well. + + - Phi node dumping doesn't attempt to do line wrapping since it just made the dump harder + to read. + + - DFG graph disassembly view shows a few additional node types that turn out to be + essential for understanding OSR exits. + + Put together, these changes reinforce the philosophy that anything needed for computing + OSR exit is just as important as the machine code itself. Of course, we still don't take + that philosophy to its full extreme - for example Phantom nodes are not dumped. We may + revisit that in the future. + + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + * assembler/LinkBuffer.h: + (JSC): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dumpBlockHeader): + * dfg/DFGNode.h: + (JSC::DFG::Node::willHaveCodeGenOrOSR): + * dfg/DFGOSRExitCompiler.cpp: + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + +2012-06-25 Mark Hahnenberg <mhahnenberg@apple.com> + + JSLock should be per-JSGlobalData + https://bugs.webkit.org/show_bug.cgi?id=89123 + + Reviewed by Geoffrey Garen. + + * API/APIShims.h: + (APIEntryShimWithoutLock): + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): Added an extra parameter to the constructor to + determine whether we should ref the JSGlobalData or not. We want to ref all the time except for in the + HeapTimer class because timerDidFire could run after somebody has started to tear down that particular + JSGlobalData, so we wouldn't want to resurrect the ref count of that JSGlobalData from 0 back to 1 after + its destruction has begun. + (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): + (JSC::APIEntryShim::APIEntryShim): + (APIEntryShim): + (JSC::APIEntryShim::~APIEntryShim): + (JSC::APIEntryShim::init): Factored out common initialization code for the various APIEntryShim constructors. + Also moved the timeoutChecker stop and start here because we need to start after we've grabbed the API lock + and before we've released it, which can only done in APIEntryShim. + (JSC::APICallbackShim::~APICallbackShim): We no longer need to synchronize here. + * API/JSContextRef.cpp: + (JSGlobalContextCreate): + (JSGlobalContextCreateInGroup): + (JSGlobalContextRelease): + (JSContextCreateBacktrace): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateSlowCase): + * heap/Heap.cpp: + (JSC::Heap::protect): + (JSC::Heap::unprotect): + (JSC::Heap::collect): + (JSC::Heap::setActivityCallback): + (JSC::Heap::activityCallback): + (JSC::Heap::sweeper): + * heap/Heap.h: Changed m_activityCallback and m_sweeper to be raw pointers rather than OwnPtrs because they + are now responsible for their own lifetime. Also changed the order of declaration of the GCActivityCallback + and the IncrementalSweeper to make sure they're the last things that get initialized during construction to + prevent any issues with uninitialized memory in the JSGlobalData/Heap they might care about. + (Heap): + * heap/HeapTimer.cpp: Refactored to allow for thread-safe operation and shutdown. + (JSC::HeapTimer::~HeapTimer): + (JSC::HeapTimer::invalidate): + (JSC): + (JSC::HeapTimer::didStartVMShutdown): Called at the beginning of ~JSGlobalData. If we're on the same thread + that the HeapTimer is running on, we kill the HeapTimer ourselves. If not, then we set some state in the + HeapTimer and schedule it to fire immediately so that it can notice and kill itself. + (JSC::HeapTimer::timerDidFire): We grab our mutex and check our JSGlobalData pointer. If it has been zero-ed + out, then we know the VM has started to shutdown and we should kill ourselves. Otherwise, grab the APIEntryShim, + but without ref-ing the JSGlobalData (we don't want to bring the JSGlobalData's ref-count from 0 to 1) in case + we were interrupted between releasing our mutex and trying to grab the APILock. + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doWork): We no longer need the API shim here since HeapTimer::timerDidFire handles + all of that for us. + (JSC::IncrementalSweeper::create): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateSlowCase): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::reap): + * jsc.cpp: + (functionGC): + (functionReleaseExecutableMemory): + (jscmain): + * runtime/Completion.cpp: + (JSC::checkSyntax): + (JSC::evaluate): + * runtime/GCActivityCallback.h: + (DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::create): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): Signals to the two HeapTimers (GCActivityCallback and IncrementalSweeper) + that the VM has started shutting down. It then waits until the HeapTimer is done with whatever activity + it needs to do before continuing with any further destruction. Also asserts that we do not currently hold the + APILock because this could potentially cause deadlock when we try to signal to the HeapTimers using their mutexes. + (JSC::JSGlobalData::sharedInstance): Protect the initialization for the shared instance with the GlobalJSLock. + (JSC::JSGlobalData::sharedInstanceInternal): + * runtime/JSGlobalData.h: Change to be ThreadSafeRefCounted so that we don't have to worry about refing and + de-refing JSGlobalDatas on separate threads since we don't do it that often anyways. + (JSGlobalData): + (JSC::JSGlobalData::apiLock): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::~JSGlobalObject): + (JSC::JSGlobalObject::init): + * runtime/JSLock.cpp: + (JSC): + (JSC::GlobalJSLock::GlobalJSLock): For accessing the shared instance. + (JSC::GlobalJSLock::~GlobalJSLock): + (JSC::JSLockHolder::JSLockHolder): MutexLocker for JSLock. Also refs the JSGlobalData to keep it alive so that + it can successfully unlock it later without it disappearing from underneath it. + (JSC::JSLockHolder::~JSLockHolder): + (JSC::JSLock::JSLock): + (JSC::JSLock::~JSLock): + (JSC::JSLock::lock): Uses the spin lock for guarding the lock count and owner thread fields. Uses the mutex for + actually waiting for long periods. + (JSC::JSLock::unlock): + (JSC::JSLock::currentThreadIsHoldingLock): + (JSC::JSLock::dropAllLocks): + (JSC::JSLock::dropAllLocksUnconditionally): + (JSC::JSLock::grabAllLocks): + (JSC::JSLock::DropAllLocks::DropAllLocks): + (JSC::JSLock::DropAllLocks::~DropAllLocks): + * runtime/JSLock.h: + (JSC): + (GlobalJSLock): + (JSLockHolder): + (JSLock): + (DropAllLocks): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::set): + * testRegExp.cpp: + (realMain): + +2012-06-27 Filip Pizlo <fpizlo@apple.com> + + x86 disassembler confuses immediates with addresses + https://bugs.webkit.org/show_bug.cgi?id=90099 + + Reviewed by Mark Hahnenberg. + + Prepend "$" to immediates to disambiguate between immediates and addresses. This is in + accordance with the gas and AT&T syntax. + + * disassembler/udis86/udis86_syn-att.c: + (gen_operand): + +2012-06-27 Filip Pizlo <fpizlo@apple.com> + + Add a comment clarifying Options::showDisassembly versus Options::showDFGDisassembly. + + Rubber stamped by Mark Hahnenberg. + + * runtime/Options.cpp: + (JSC::Options::initializeOptions): + +2012-06-27 Anthony Scian <ascian@rim.com> + + Web Inspector [JSC]: Implement ScriptCallStack::stackTrace + https://bugs.webkit.org/show_bug.cgi?id=40118 + + Reviewed by Yong Li. + + Added member functions to expose function name, urlString, and line #. + Refactored toString to make use of these member functions to reduce + duplicated code for future maintenance. + + Manually tested refactoring of toString by tracing thrown exceptions. + + * interpreter/Interpreter.h: + (StackFrame): + (JSC::StackFrame::toString): + (JSC::StackFrame::friendlySourceURL): + (JSC::StackFrame::friendlyFunctionName): + (JSC::StackFrame::friendlyLineNumber): + +2012-06-27 Oswald Buddenhagen <oswald.buddenhagen@nokia.com> + + [Qt] Remove redundant c++11 warning suppression code + + This is already handled in default_post. + + Reviewed by Tor Arne Vestbø. + + * Target.pri: + +2012-06-26 Tor Arne Vestbø <tor.arne.vestbo@nokia.com> + + [Qt] Add missing heades to HEADERS + + For JavaScriptCore there aren't any Qt specific files, so we include all + headers for easy editing in Qt Creator. + + Reviewed by Simon Hausmann. + + * Target.pri: + +2012-06-26 Dominic Cooney <dominicc@chromium.org> + + [Chromium] Remove unused build scripts and empty folders for JavaScriptCore w/ gyp + https://bugs.webkit.org/show_bug.cgi?id=90029 + + Reviewed by Adam Barth. + + * gyp: Removed. + * gyp/generate-derived-sources.sh: Removed. + * gyp/generate-dtrace-header.sh: Removed. + * gyp/run-if-exists.sh: Removed. + * gyp/update-info-plist.sh: Removed. + +2012-06-26 Geoffrey Garen <ggaren@apple.com> + + Reduced (but did not eliminate) use of "berzerker GC" + https://bugs.webkit.org/show_bug.cgi?id=89237 + + Reviewed by Gavin Barraclough. + + (PART 2) + + This part turns off "berzerker GC" and turns on incremental shrinking. + + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doSweep): Free or shrink after sweeping to + maintain the behavior we used to get from the occasional berzerker GC, + which would run all finalizers and then free or shrink all blocks + synchronously. + + * heap/MarkedBlock.h: + (JSC::MarkedBlock::needsSweeping): Sweep zapped blocks, too. It's always + safe to sweep a zapped block (that's the point of zapping), and it's + sometimes profitable. For example, consider this case: Block A does some + allocation (transitioning Block A from Marked to FreeListed), then GC + happens (transitioning Block A to Zapped), then all objects in Block A + are free, then the incremental sweeper visits Block A. If we skipped + Zapped blocks, we'd skip Block A, even though it would be profitable to + run its destructors and free its memory. + + * runtime/GCActivityCallback.cpp: + (JSC::DefaultGCActivityCallback::doWork): Don't sweep eagerly; we'll do + this incrementally. + +2012-06-26 Filip Pizlo <fpizlo@apple.com> + + DFG PutByValAlias is too aggressive + https://bugs.webkit.org/show_bug.cgi?id=90026 + <rdar://problem/11751830> + + Reviewed by Gavin Barraclough. + + For CSE on normal arrays, we now treat PutByVal as impure. This does not appear to affect + performance by much. + + For CSE on typed arrays, we fix PutByValAlias by making GetByVal speculate that the access + is within bounds. This also has the effect of making our out-of-bounds handling consistent + with WebCore. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + +2012-06-26 Yong Li <yoli@rim.com> + + [BlackBerry] Add JSC statistics into about:memory + https://bugs.webkit.org/show_bug.cgi?id=89779 + + Reviewed by Rob Buis. + + Fix non-JIT build on BlackBerry broken by r121196. + + * runtime/MemoryStatistics.cpp: + (JSC::globalMemoryStatistics): + +2012-06-25 Filip Pizlo <fpizlo@apple.com> + + DFG::operationNewArray is unnecessarily slow, and may use the wrong array + prototype when inlined + https://bugs.webkit.org/show_bug.cgi?id=89821 + + Reviewed by Geoffrey Garen. + + Fixes all array allocations to use the right structure, and hence the right prototype. Adds + inlining of new Array(...) with a non-zero number of arguments. Optimizes allocations of + empty arrays. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/JSArray.h: + (JSC): + (JSC::constructArray): + * runtime/JSGlobalObject.h: + (JSC): + (JSC::constructArray): + +2012-06-26 Filip Pizlo <fpizlo@apple.com> + + New fast/js/dfg-store-unexpected-value-into-argument-and-osr-exit.html fails on 32 bit + https://bugs.webkit.org/show_bug.cgi?id=89953 + + Reviewed by Zoltan Herczeg. + + DFG 32-bit JIT was confused about the difference between a predicted type and a + proven type. This is easy to get confused about, since a local that is predicted int32 + almost always means that the local must be an int32 since speculations are hoisted to + stores to locals. But that is less likely to be the case for arguments, where there is + an additional least-upper-bounding step: any store to an argument with a weird type + may force the argument to be any type. + + This patch basically duplicates the functionality in DFGSpeculativeJIT64.cpp for + GetLocal: the decision of whether to load a local as an int32 (or as an array, or as + a boolean) is made based on the AbstractValue::m_type, which is a type proof, rather + than the VariableAccessData::prediction(), which is a predicted type. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-06-25 Filip Pizlo <fpizlo@apple.com> + + JSC should try to make profiling deterministic because otherwise reproducing failures is + nearly impossible + https://bugs.webkit.org/show_bug.cgi?id=89940 + + Rubber stamped by Gavin Barraclough. + + This rolls out the part of http://trac.webkit.org/changeset/121215 that introduced randomness + into the system. Now, instead of randomizing the tier-up threshold, we always set it to an + artificially low (and statically predetermined!) value. This gives most of the benefit of + threshold randomization without actually making the system behave completely differently on + each invocation. + + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::setThreshold): + * runtime/Options.cpp: + (Options): + (JSC::Options::initializeOptions): + * runtime/Options.h: + (Options): + +2012-06-22 Filip Pizlo <fpizlo@apple.com> + + Value profiling should use tier-up threshold randomization to get more coverage + https://bugs.webkit.org/show_bug.cgi?id=89802 + + Reviewed by Gavin Barraclough. + + This patch causes both LLInt and Baseline JIT code to take the OSR slow path several + times before actually doing OSR. If we take the OSR slow path before the execution + count threshold is reached, then we just call CodeBlock::updateAllPredictions() to + compute the current latest least-upper-bound SpecType of all values seen in each + ValueProfile. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::stronglyVisitStrongReferences): + (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): + (JSC): + (JSC::CodeBlock::updateAllPredictions): + (JSC::CodeBlock::shouldOptimizeNow): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::llintExecuteCounter): + (JSC::CodeBlock::jitExecuteCounter): + (CodeBlock): + (JSC::CodeBlock::updateAllPredictions): + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::setThreshold): + (JSC::ExecutionCounter::status): + (JSC): + * bytecode/ExecutionCounter.h: + (JSC::ExecutionCounter::count): + (ExecutionCounter): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGOperations.cpp: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::jitCompileAndSetHeuristics): + (JSC::LLInt::entryOSR): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::weakRandomInteger): + * runtime/Options.cpp: + (Options): + (JSC::Options::initializeOptions): + * runtime/Options.h: + (Options): + * runtime/WeakRandom.h: + (WeakRandom): + (JSC::WeakRandom::seedUnsafe): + +2012-06-25 Yong Li <yoli@rim.com> + + [BlackBerry] Add JSC statistics into about:memory + https://bugs.webkit.org/show_bug.cgi?id=89779 + + Reviewed by Rob Buis. + + Add MemoryStatistics.cpp into build, and fill JITBytes for BlackBerry port. + + * PlatformBlackBerry.cmake: + * runtime/MemoryStatistics.cpp: + (JSC::globalMemoryStatistics): + +2012-06-23 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r121058. + http://trac.webkit.org/changeset/121058 + https://bugs.webkit.org/show_bug.cgi?id=89809 + + Patch causes plugins tests to crash in GTK debug builds + (Requested by zdobersek on #webkit). + + * API/APIShims.h: + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): + (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): + (APIEntryShimWithoutLock): + (JSC::APIEntryShim::APIEntryShim): + (APIEntryShim): + (JSC::APICallbackShim::~APICallbackShim): + * API/JSContextRef.cpp: + (JSGlobalContextCreate): + (JSGlobalContextCreateInGroup): + (JSGlobalContextRelease): + (JSContextCreateBacktrace): + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateSlowCase): + * heap/Heap.cpp: + (JSC::Heap::protect): + (JSC::Heap::unprotect): + (JSC::Heap::collect): + (JSC::Heap::setActivityCallback): + (JSC::Heap::activityCallback): + (JSC::Heap::sweeper): + * heap/Heap.h: + (Heap): + * heap/HeapTimer.cpp: + (JSC::HeapTimer::~HeapTimer): + (JSC::HeapTimer::invalidate): + (JSC::HeapTimer::timerDidFire): + (JSC): + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doWork): + (JSC::IncrementalSweeper::create): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateSlowCase): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::reap): + * jsc.cpp: + (functionGC): + (functionReleaseExecutableMemory): + (jscmain): + * runtime/Completion.cpp: + (JSC::checkSyntax): + (JSC::evaluate): + * runtime/GCActivityCallback.h: + (DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::create): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + (JSC::JSGlobalData::sharedInstance): + (JSC::JSGlobalData::sharedInstanceInternal): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::~JSGlobalObject): + (JSC::JSGlobalObject::init): + * runtime/JSLock.cpp: + (JSC): + (JSC::createJSLockCount): + (JSC::JSLock::lockCount): + (JSC::setLockCount): + (JSC::JSLock::JSLock): + (JSC::JSLock::lock): + (JSC::JSLock::unlock): + (JSC::JSLock::currentThreadIsHoldingLock): + (JSC::JSLock::DropAllLocks::DropAllLocks): + (JSC::JSLock::DropAllLocks::~DropAllLocks): + * runtime/JSLock.h: + (JSC): + (JSLock): + (JSC::JSLock::JSLock): + (JSC::JSLock::~JSLock): + (DropAllLocks): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::set): + * testRegExp.cpp: + (realMain): + +2012-06-22 Alexandru Chiculita <achicu@adobe.com> + + [CSS Shaders] Re-enable the CSS Shaders compile time flag on Safari Mac + https://bugs.webkit.org/show_bug.cgi?id=89781 + + Reviewed by Dean Jackson. + + Added ENABLE_CSS_SHADERS flag as enabled by default on Safari for Mac. + + * Configurations/FeatureDefines.xcconfig: + +2012-06-22 Filip Pizlo <fpizlo@apple.com> + + DFG tier-up should happen in prologues, not epilogues + https://bugs.webkit.org/show_bug.cgi?id=89752 + + Reviewed by Geoffrey Garen. + + This change has two outcomes: + + 1) Slightly reduces the likelihood that a function will be optimized both + standalone and via inlining. Previously, if you had a call sequence like foo() + calls bar() exactly once, and nobody else calls bar(), then bar() would get + optimized first (because it returns first) and then foo() gets optimized. If foo() + can inline bar() then that means that bar() gets optimized twice. But now, if we + optimize in prologues, then foo() will be optimized first. If it inlines bar(), + that means that there will no longer be any calls to bar(). + + 2) It lets us kill some code in JITStubs. Epilogue tier-up was very different from + loop tier-up, since epilogue tier-up should not attempt OSR. But prologue tier-up + requires OSR (albeit really easy OSR since it's the top of the compilation unit), + so it becomes just like loop tier-up. As a result, we now have one optimization + hook (cti_optimize) instead of two (cti_optimize_from_loop and + cti_optimize_from_ret). + + As a consequence of not having an optimization check in epilogues, the OSR exit + code must now trigger reoptimization itself instead of just signaling the epilogue + check to fire. + + This also adds the ability to count the number of DFG compilations, which was + useful for debugging this patch and might be useful for other things in the future. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::reoptimize): + (JSC): + * bytecode/CodeBlock.h: + (CodeBlock): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGDriver.cpp: + (DFG): + (JSC::DFG::getNumCompilations): + (JSC::DFG::compile): + * dfg/DFGDriver.h: + (DFG): + * dfg/DFGOSRExitCompiler.cpp: + (JSC::DFG::OSRExitCompiler::handleExitCounts): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * jit/JIT.cpp: + (JSC::JIT::emitOptimizationCheck): + * jit/JIT.h: + * jit/JITCall32_64.cpp: + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + (JSC::JIT::emit_op_enter): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_enter): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + +2012-06-20 Mark Hahnenberg <mhahnenberg@apple.com> + + JSLock should be per-JSGlobalData + https://bugs.webkit.org/show_bug.cgi?id=89123 + + Reviewed by Gavin Barraclough. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * API/APIShims.h: + (APIEntryShimWithoutLock): + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): Added an extra parameter to the constructor to + determine whether we should ref the JSGlobalData or not. We want to ref all the time except for in the + HeapTimer class because timerDidFire could run after somebody has started to tear down that particular + JSGlobalData, so we wouldn't want to resurrect the ref count of that JSGlobalData from 0 back to 1 after + its destruction has begun. + (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): Now derefs if it also refed. + (JSC::APIEntryShim::APIEntryShim): + (APIEntryShim): + (JSC::APIEntryShim::~APIEntryShim): + (JSC::APIEntryShim::init): Factored out common initialization code for the various APIEntryShim constructors. + Also moved the timeoutChecker stop and start here because we need to start after we've grabbed the API lock + and before we've released it, which can only done in APIEntryShim. + (JSC::APICallbackShim::~APICallbackShim): We no longer need to synchronize here. + * API/JSContextRef.cpp: + (JSGlobalContextCreate): + (JSGlobalContextCreateInGroup): + (JSGlobalContextRelease): + (JSContextCreateBacktrace): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateSlowCase): + * heap/Heap.cpp: + (JSC::Heap::protect): + (JSC::Heap::unprotect): + (JSC::Heap::collect): + (JSC::Heap::setActivityCallback): + (JSC::Heap::activityCallback): + (JSC::Heap::sweeper): + * heap/Heap.h: Changed m_activityCallback and m_sweeper to be raw pointers rather than OwnPtrs because they + are now responsible for their own lifetime. Also changed the order of declaration of the GCActivityCallback + and the IncrementalSweeper to make sure they're the last things that get initialized during construction to + prevent any issues with uninitialized memory in the JSGlobalData/Heap they might care about. + (Heap): + * heap/HeapTimer.cpp: Refactored to allow for thread-safe operation and shutdown. + (JSC::HeapTimer::~HeapTimer): + (JSC::HeapTimer::invalidate): + (JSC): + (JSC::HeapTimer::didStartVMShutdown): Called at the beginning of ~JSGlobalData. If we're on the same thread + that the HeapTimer is running on, we kill the HeapTimer ourselves. If not, then we set some state in the + HeapTimer and schedule it to fire immediately so that it can notice and kill itself. + (JSC::HeapTimer::timerDidFire): We grab our mutex and check our JSGlobalData pointer. If it has been zero-ed + out, then we know the VM has started to shutdown and we should kill ourselves. Otherwise, grab the APIEntryShim, + but without ref-ing the JSGlobalData (we don't want to bring the JSGlobalData's ref-count from 0 to 1) in case + we were interrupted between releasing our mutex and trying to grab the APILock. + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::doWork): We no longer need the API shim here since HeapTimer::timerDidFire handles + all of that for us. + (JSC::IncrementalSweeper::create): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateSlowCase): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::reap): + * jsc.cpp: + (functionGC): + (functionReleaseExecutableMemory): + (jscmain): + * runtime/Completion.cpp: + (JSC::checkSyntax): + (JSC::evaluate): + * runtime/GCActivityCallback.h: + (DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::create): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): Signals to the two HeapTimers (GCActivityCallback and IncrementalSweeper) + that the VM has started shutting down. It then waits until the HeapTimer is done with whatever activity + it needs to do before continuing with any further destruction. Also asserts that we do not currently hold the + APILock because this could potentially cause deadlock when we try to signal to the HeapTimers using their mutexes. + (JSC::JSGlobalData::sharedInstance): Protect the initialization for the shared instance with the GlobalJSLock. + (JSC::JSGlobalData::sharedInstanceInternal): + * runtime/JSGlobalData.h: Change to be ThreadSafeRefCounted so that we don't have to worry about refing and + de-refing JSGlobalDatas on separate threads since we don't do it that often anyways. + (JSGlobalData): + (JSC::JSGlobalData::apiLock): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::~JSGlobalObject): + (JSC::JSGlobalObject::init): + * runtime/JSLock.cpp: + (JSC): + (JSC::GlobalJSLock::GlobalJSLock): For accessing the shared instance. + (JSC::GlobalJSLock::~GlobalJSLock): + (JSC::JSLockHolder::JSLockHolder): MutexLocker for JSLock. Also refs the JSGlobalData to keep it alive so that + it can successfully unlock it later without it disappearing from underneath it. + (JSC::JSLockHolder::~JSLockHolder): + (JSC::JSLock::JSLock): + (JSC::JSLock::~JSLock): + (JSC::JSLock::lock): Uses the spin lock for guarding the lock count and owner thread fields. Uses the mutex for + actually waiting for long periods. + (JSC::JSLock::unlock): + (JSC::JSLock::currentThreadIsHoldingLock): + (JSC::JSLock::dropAllLocks): + (JSC::JSLock::dropAllLocksUnconditionally): + (JSC::JSLock::grabAllLocks): + (JSC::JSLock::DropAllLocks::DropAllLocks): + (JSC::JSLock::DropAllLocks::~DropAllLocks): + * runtime/JSLock.h: + (JSC): + (GlobalJSLock): + (JSLockHolder): + (JSLock): + (DropAllLocks): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::set): + * testRegExp.cpp: + (realMain): + +2012-06-22 Peter Beverloo <peter@chromium.org> + + [Chromium] Disable c++0x compatibility warnings in JavaScriptCore.gyp when building for Android + https://bugs.webkit.org/show_bug.cgi?id=88853 + + Reviewed by Steve Block. + + The Android exclusions were necessary to fix a gyp generation error, as + the gcc_version variable wasn't being defined for Android. Remove these + exceptions when Chromium is able to define the gcc_version variable. + + * JavaScriptCore.gyp/JavaScriptCore.gyp: + +2012-06-21 Filip Pizlo <fpizlo@apple.com> + + op_resolve_global should not prevent DFG inlining + https://bugs.webkit.org/show_bug.cgi?id=89726 + + Reviewed by Gavin Barraclough. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::shrinkToFit): + * bytecode/GlobalResolveInfo.h: + (JSC::GlobalResolveInfo::GlobalResolveInfo): + (GlobalResolveInfo): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineOpcode): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-06-20 Filip Pizlo <fpizlo@apple.com> + + DFG should inline 'new Array()' + https://bugs.webkit.org/show_bug.cgi?id=89632 + + Reviewed by Geoffrey Garen. + + This adds support for treating InternalFunction like intrinsics. The code + to do so is actually quite clean, so I don't feel bad about perpetuating + the InternalFunction vs. JSFunction-with-NativeExecutable dichotomy. + + Currently this newfound power is only used to inline 'new Array()'. + + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): + (DFG): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::isInternalFunctionConstant): + (JSC::DFG::Graph::valueOfInternalFunctionConstant): + +2012-06-21 Mark Hahnenberg <mhahnenberg@apple.com> + + Adding copyrights to new files. + + * heap/HeapTimer.cpp: + * heap/HeapTimer.h: + * heap/IncrementalSweeper.cpp: + * heap/IncrementalSweeper.h: + +2012-06-21 Arnaud Renevier <arno@renevier.net> + + make sure headers are included only once per file + https://bugs.webkit.org/show_bug.cgi?id=88922 + + Reviewed by Alexey Proskuryakov. + + * bytecode/CodeBlock.h: + * heap/MachineStackMarker.cpp: + * runtime/JSVariableObject.h: + +2012-06-21 Ryuan Choi <ryuan.choi@gmail.com> + + [EFL][WK2] Make WebKit2/Efl headers and resources installable. + https://bugs.webkit.org/show_bug.cgi?id=88207 + + Reviewed by Chang Shu. + + * shell/CMakeLists.txt: Use ${EXEC_INSTALL_DIR} instead of hardcoding "bin" + +2012-06-20 Geoffrey Garen <ggaren@apple.com> + + Reduced (but did not eliminate) use of "berzerker GC" + https://bugs.webkit.org/show_bug.cgi?id=89237 + + Reviewed by Gavin Barraclough. + + (PART 1) + + This patch turned out to be crashy, so I'm landing the non-crashy bits + first. + + This part is pre-requisite refactoring. I didn't actually turn off + "berzerker GC" or turn on incremental shrinking. + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::removeBlock): Make sure to clear the free list when + we throw away the block we're currently allocating out of. Otherwise, we'll + allocate out of a stale free list. + + * heap/MarkedSpace.cpp: + (JSC::Free::Free): + (JSC::Free::operator()): + (JSC::Free::returnValue): Refactored this functor to use a shared helper + function, so we can share our implementation with the incremental sweeper. + + Also changed to freeing individual blocks immediately instead of linking + them into a list for later freeing. This makes the programming interface + simpler, and it's slightly more efficient to boot. + + (JSC::MarkedSpace::~MarkedSpace): Updated for rename. + + (JSC::MarkedSpace::freeBlock): + (JSC::MarkedSpace::freeOrShrinkBlock): New helper functions to share behavior + with the incremental sweeper. + + (JSC::MarkedSpace::shrink): Updated for new functor behavior. + + * heap/MarkedSpace.h: Statically typed languages are awesome. + +2012-06-20 Filip Pizlo <fpizlo@apple.com> + + DFG should optimize ResolveGlobal + https://bugs.webkit.org/show_bug.cgi?id=89617 + + Reviewed by Oliver Hunt. + + This adds inlining of ResolveGlobal accesses that are known monomorphic. It also + adds the specific function optimization to ResolveGlobal, when it is inlined. And, + it makes internal functions act like specific functions, since that will be the + most common use-case of this optimization. + + This is only a slighy speed-up (sub 1%), since we don't yet do the obvious thing + with this optimization, which is to completely inline common "globally resolved" + function and constructor calls, like "new Array()". + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::globalResolveInfoForBytecodeOffset): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::numberOfGlobalResolveInfos): + * bytecode/GlobalResolveInfo.h: + (JSC::getGlobalResolveInfoBytecodeOffset): + (JSC): + * bytecode/ResolveGlobalStatus.cpp: Added. + (JSC): + (JSC::computeForStructure): + (JSC::computeForLLInt): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: Added. + (JSC): + (ResolveGlobalStatus): + (JSC::ResolveGlobalStatus::ResolveGlobalStatus): + (JSC::ResolveGlobalStatus::state): + (JSC::ResolveGlobalStatus::isSet): + (JSC::ResolveGlobalStatus::operator!): + (JSC::ResolveGlobalStatus::isSimple): + (JSC::ResolveGlobalStatus::takesSlowPath): + (JSC::ResolveGlobalStatus::structure): + (JSC::ResolveGlobalStatus::offset): + (JSC::ResolveGlobalStatus::specificValue): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (DFG): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + * runtime/JSObject.cpp: + (JSC::getCallableObjectSlow): + (JSC): + (JSC::JSObject::put): + (JSC::JSObject::putDirectVirtual): + (JSC::JSObject::putDirectAccessor): + * runtime/JSObject.h: + (JSC): + (JSC::getCallableObject): + (JSC::JSObject::putOwnDataProperty): + (JSC::JSObject::putDirect): + (JSC::JSObject::putDirectWithoutTransition): + +2012-06-20 Filip Pizlo <fpizlo@apple.com> + + Functions on global objects should be specializable + https://bugs.webkit.org/show_bug.cgi?id=89615 + + Reviewed by Oliver Hunt. + + I tested to see if this brought back the bug in https://bugs.webkit.org/show_bug.cgi?id=33343, + and it didn't. Bug 33343 was the reason why we disabled global object function specialization + to begin with. So I'm guessing this is safe. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::init): + +2012-06-20 Filip Pizlo <fpizlo@apple.com> + + build-webkit failure due to illegal 32-bit integer constants in code + generated by offlineasm + https://bugs.webkit.org/show_bug.cgi?id=89347 + + Reviewed by Geoffrey Garen. + + The offending constants are the magic numbers used by offlineasm to find + offsets in the generated machine code. Added code to turn them into what + the C++ compiler will believe to be valid 32-bit values. + + * offlineasm/offsets.rb: + +2012-06-19 Geoffrey Garen <ggaren@apple.com> + + Made the incremental sweeper more aggressive + https://bugs.webkit.org/show_bug.cgi?id=89527 + + Reviewed by Oliver Hunt. + + This is a pre-requisite to getting rid of "berzerker GC" because we need + the sweeper to reclaim memory in a timely fashion, or we'll see a memory + footprint regression. + + * heap/IncrementalSweeper.h: + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::scheduleTimer): Since the time slice is predictable, + no need to use a data member to record it. + + (JSC::IncrementalSweeper::doSweep): Sweep as many blocks as we can in a + small time slice. This is better than sweeping only one block per timer + fire because that strategy has a heavy timer overhead, and artificially + delays memory reclamation. + +2012-06-20 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to print disassembly interleaved with the IR + https://bugs.webkit.org/show_bug.cgi?id=89551 + + Reviewed by Geoffrey Garen. + + This change also removes running Dominators unconditionally on every DFG + compile. Dominators are designed to be computed on-demand, and currently + the only demand is graph dumps. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::labelIgnoringWatchpoints): + (ARMv7Assembler): + * assembler/AbstractMacroAssembler.h: + (AbstractMacroAssembler): + (JSC::AbstractMacroAssembler::labelIgnoringWatchpoints): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::labelIgnoringWatchpoints): + * dfg/DFGCommon.h: + (JSC::DFG::shouldShowDisassembly): + (DFG): + * dfg/DFGDisassembler.cpp: Added. + (DFG): + (JSC::DFG::Disassembler::Disassembler): + (JSC::DFG::Disassembler::dump): + (JSC::DFG::Disassembler::dumpDisassembly): + * dfg/DFGDisassembler.h: Added. + (DFG): + (Disassembler): + (JSC::DFG::Disassembler::setStartOfCode): + (JSC::DFG::Disassembler::setForBlock): + (JSC::DFG::Disassembler::setForNode): + (JSC::DFG::Disassembler::setEndOfMainPath): + (JSC::DFG::Disassembler::setEndOfCode): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::amountOfNodeWhiteSpace): + (DFG): + (JSC::DFG::Graph::printNodeWhiteSpace): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::dumpBlockHeader): + * dfg/DFGGraph.h: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::JITCompiler): + (DFG): + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JITCompiler): + (JSC::DFG::JITCompiler::setStartOfCode): + (JSC::DFG::JITCompiler::setForBlock): + (JSC::DFG::JITCompiler::setForNode): + (JSC::DFG::JITCompiler::setEndOfMainPath): + (JSC::DFG::JITCompiler::setEndOfCode): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::willHaveCodeGen): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * runtime/Options.cpp: + (Options): + (JSC::Options::initializeOptions): + * runtime/Options.h: + (Options): + +2012-06-19 Filip Pizlo <fpizlo@apple.com> + + JSC should be able to show disassembly for all generated JIT code + https://bugs.webkit.org/show_bug.cgi?id=89536 + + Reviewed by Gavin Barraclough. + + Now instead of doing linkBuffer.finalizeCode(), you do + FINALIZE_CODE(linkBuffer, (... explanation ...)). FINALIZE_CODE() then + prints your explanation and the disassembled code, if + Options::showDisassembly is set to true. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/LinkBuffer.cpp: Added. + (JSC): + (JSC::LinkBuffer::finalizeCodeWithoutDisassembly): + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + (JSC::LinkBuffer::linkCode): + (JSC::LinkBuffer::performFinalization): + (JSC::LinkBuffer::dumpLinkStatistics): + (JSC::LinkBuffer::dumpCode): + * assembler/LinkBuffer.h: + (LinkBuffer): + (JSC): + * assembler/MacroAssemblerCodeRef.h: + (JSC::MacroAssemblerCodeRef::tryToDisassemble): + (MacroAssemblerCodeRef): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGThunks.cpp: + (JSC::DFG::osrExitGenerationThunkGenerator): + * disassembler/Disassembler.h: + (JSC): + (JSC::tryToDisassemble): + * disassembler/UDis86Disassembler.cpp: + (JSC::tryToDisassemble): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITCode.h: + (JSC::JITCode::tryToDisassemble): + * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::privateCompileCTINativeCall): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::finalize): + * jit/ThunkGenerators.cpp: + (JSC::charCodeAtThunkGenerator): + (JSC::charAtThunkGenerator): + (JSC::fromCharCodeThunkGenerator): + (JSC::sqrtThunkGenerator): + (JSC::floorThunkGenerator): + (JSC::ceilThunkGenerator): + (JSC::roundThunkGenerator): + (JSC::expThunkGenerator): + (JSC::logThunkGenerator): + (JSC::absThunkGenerator): + (JSC::powThunkGenerator): + * llint/LLIntThunks.cpp: + (JSC::LLInt::generateThunkWithJumpTo): + (JSC::LLInt::functionForCallEntryThunkGenerator): + (JSC::LLInt::functionForConstructEntryThunkGenerator): + (JSC::LLInt::functionForCallArityCheckThunkGenerator): + (JSC::LLInt::functionForConstructArityCheckThunkGenerator): + (JSC::LLInt::evalEntryThunkGenerator): + (JSC::LLInt::programEntryThunkGenerator): + * runtime/Options.cpp: + (Options): + (JSC::Options::initializeOptions): + * runtime/Options.h: + (Options): + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::compile): + +2012-06-19 Mark Hahnenberg <mhahnenberg@apple.com> + + [Qt][Mac] REGRESSION(r120742): It broke the build + https://bugs.webkit.org/show_bug.cgi?id=89516 + + Reviewed by Geoffrey Garen. + + Removing GCActivityCallbackCF.cpp because it doesn't mesh well with cross-platform + code on Darwin (e.g. Qt). We now use plain ol' vanilla ifdefs to handle platforms + without CF support. These if-defs will probably disappear in the future when we + use cross-platform timers in HeapTimer. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * runtime/GCActivityCallback.cpp: + (JSC): + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::scheduleTimer): + (JSC::DefaultGCActivityCallback::cancelTimer): + (JSC::DefaultGCActivityCallback::didAllocate): + (JSC::DefaultGCActivityCallback::willCollect): + (JSC::DefaultGCActivityCallback::cancel): + * runtime/GCActivityCallbackCF.cpp: Removed. + +2012-06-19 Filip Pizlo <fpizlo@apple.com> + + DFG CFA forgets to notify subsequent phases of found constants if it proves LogicalNot to be a constant + https://bugs.webkit.org/show_bug.cgi?id=89511 + <rdar://problem/11700089> + + Reviewed by Geoffrey Garen. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2012-06-19 Mark Lam <mark.lam@apple.com> + + CodeBlock::needsCallReturnIndices() is no longer needed. + https://bugs.webkit.org/show_bug.cgi?id=89490 + + Reviewed by Geoffrey Garen. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::needsCallReturnIndices): removed. + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + +2012-06-19 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, try to fix Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: + +2012-06-17 Filip Pizlo <fpizlo@apple.com> + + It should be possible to look at disassembly + https://bugs.webkit.org/show_bug.cgi?id=89319 + + Reviewed by Sam Weinig. + + This imports the udis86 disassembler library. The library is placed + behind an abstraction in disassembler/Disassembler.h, so that we can + in the future use other disassemblers (for other platforms) whenever + appropriate. As a first step, the disassembler is being invoked for + DFG verbose dumps. + + If we ever want to merge a new version of udis86 in the future, I've + made notes about changes I made to the library in + disassembler/udis86/differences.txt. + + * CMakeLists.txt: + * DerivedSources.make: + * GNUmakefile.list.am: + * JavaScriptCore.pri: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * disassembler: Added. + * disassembler/Disassembler.h: Added. + (JSC): + (JSC::tryToDisassemble): + * disassembler/UDis86Disassembler.cpp: Added. + (JSC): + (JSC::tryToDisassemble): + * disassembler/udis86: Added. + * disassembler/udis86/differences.txt: Added. + * disassembler/udis86/itab.py: Added. + (UdItabGenerator): + (UdItabGenerator.__init__): + (UdItabGenerator.toGroupId): + (UdItabGenerator.genLookupTable): + (UdItabGenerator.genLookupTableList): + (UdItabGenerator.genInsnTable): + (genItabH): + (genItabH.UD_ITAB_H): + (genItabC): + (genItab): + (main): + * disassembler/udis86/optable.xml: Added. + * disassembler/udis86/ud_opcode.py: Added. + (UdOpcodeTables): + (UdOpcodeTables.sizeOfTable): + (UdOpcodeTables.nameOfTable): + (UdOpcodeTables.updateTable): + (UdOpcodeTables.Insn): + (UdOpcodeTables.Insn.__init__): + (UdOpcodeTables.Insn.__init__.opcode): + (UdOpcodeTables.parse): + (UdOpcodeTables.addInsnDef): + (UdOpcodeTables.print_table): + (UdOpcodeTables.print_tree): + * disassembler/udis86/ud_optable.py: Added. + (UdOptableXmlParser): + (UdOptableXmlParser.parseDef): + (UdOptableXmlParser.parse): + (printFn): + (parse): + (main): + * disassembler/udis86/udis86.c: Added. + (ud_init): + (ud_disassemble): + (ud_set_mode): + (ud_set_vendor): + (ud_set_pc): + (ud): + (ud_insn_asm): + (ud_insn_off): + (ud_insn_hex): + (ud_insn_ptr): + (ud_insn_len): + * disassembler/udis86/udis86.h: Added. + * disassembler/udis86/udis86_decode.c: Added. + (eff_adr_mode): + (ud_lookup_mnemonic): + (decode_prefixes): + (modrm): + (resolve_operand_size): + (resolve_mnemonic): + (decode_a): + (decode_gpr): + (resolve_gpr64): + (resolve_gpr32): + (resolve_reg): + (decode_imm): + (decode_modrm_reg): + (decode_modrm_rm): + (decode_o): + (decode_operand): + (decode_operands): + (clear_insn): + (resolve_mode): + (gen_hex): + (decode_insn): + (decode_3dnow): + (decode_ssepfx): + (decode_ext): + (decode_opcode): + (ud_decode): + * disassembler/udis86/udis86_decode.h: Added. + (ud_itab_entry_operand): + (ud_itab_entry): + (ud_lookup_table_list_entry): + (sse_pfx_idx): + (mode_idx): + (modrm_mod_idx): + (vendor_idx): + (is_group_ptr): + (group_idx): + * disassembler/udis86/udis86_extern.h: Added. + * disassembler/udis86/udis86_input.c: Added. + (inp_buff_hook): + (inp_file_hook): + (ud): + (ud_set_user_opaque_data): + (ud_get_user_opaque_data): + (ud_set_input_buffer): + (ud_set_input_file): + (ud_input_skip): + (ud_input_end): + (ud_inp_next): + (ud_inp_back): + (ud_inp_peek): + (ud_inp_move): + (ud_inp_uint8): + (ud_inp_uint16): + (ud_inp_uint32): + (ud_inp_uint64): + * disassembler/udis86/udis86_input.h: Added. + * disassembler/udis86/udis86_itab_holder.c: Added. + * disassembler/udis86/udis86_syn-att.c: Added. + (opr_cast): + (gen_operand): + (ud_translate_att): + * disassembler/udis86/udis86_syn-intel.c: Added. + (opr_cast): + (gen_operand): + (ud_translate_intel): + * disassembler/udis86/udis86_syn.c: Added. + * disassembler/udis86/udis86_syn.h: Added. + (mkasm): + * disassembler/udis86/udis86_types.h: Added. + (ud_operand): + (ud): + * jit/JITCode.h: + (JITCode): + (JSC::JITCode::tryToDisassemble): + +2012-06-19 Mark Hahnenberg <mhahnenberg@apple.com> + + GCActivityCallback and IncrementalSweeper should share code + https://bugs.webkit.org/show_bug.cgi?id=89400 + + Reviewed by Geoffrey Garen. + + A lot of functionality is duplicated between GCActivityCallback and IncrementalSweeper. + We should extract the common functionality out into a separate class that both of them + can inherit from. This refactoring will be an even greater boon when we add the ability + to shut these two agents down in a thread-safe fashion + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * heap/Heap.cpp: + (JSC::Heap::Heap): Move initialization down so that the JSGlobalData has a valid Heap when + we're initializing the GCActivityCallback and the IncrementalSweeper. + * heap/Heap.h: + (Heap): + * heap/HeapTimer.cpp: Added. + (JSC): + (JSC::HeapTimer::HeapTimer): Initialize the various base class data that + DefaultGCActivityCallback::commonConstructor() used to do. + (JSC::HeapTimer::~HeapTimer): Call to invalidate(). + (JSC::HeapTimer::synchronize): Same functionality as the old DefaultGCActivityCallback::synchronize(). + Virtual so that non-CF subclasses can override. + (JSC::HeapTimer::invalidate): Tears down the runloop timer to prevent any future firing. + (JSC::HeapTimer::timerDidFire): Callback to pass to the timer function. Casts and calls the virtual doWork(). + * heap/HeapTimer.h: Added. This is the class that serves as the common base class for + both GCActivityCallback and IncrementalSweeper. It handles setting up and tearing down run loops and synchronizing + across threads for its subclasses. + (JSC): + (HeapTimer): + * heap/IncrementalSweeper.cpp: Changes to accomodate the extraction of common functionality + between IncrementalSweeper and GCActivityCallback into a common ancestor. + (JSC): + (JSC::IncrementalSweeper::doWork): + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::cancelTimer): + (JSC::IncrementalSweeper::create): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * runtime/GCActivityCallback.cpp: + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + * runtime/GCActivityCallback.h: + (GCActivityCallback): + (JSC::GCActivityCallback::willCollect): + (JSC::GCActivityCallback::GCActivityCallback): + (JSC): + (DefaultGCActivityCallback): Remove the platform data struct. The platform data should be kept in + the class itself so as to be accessible by doWork(). Most of the platform data for CF is kept in + HeapTimer anyways, so we only need the m_delay field now. + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC): + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::didAllocate): + * runtime/GCActivityCallbackCF.cpp: + (JSC): + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::scheduleTimer): + (JSC::DefaultGCActivityCallback::cancelTimer): + (JSC::DefaultGCActivityCallback::didAllocate): + (JSC::DefaultGCActivityCallback::willCollect): + (JSC::DefaultGCActivityCallback::cancel): + + +2012-06-19 Mike West <mkwst@chromium.org> + + Introduce ENABLE_CSP_NEXT configuration flag. + https://bugs.webkit.org/show_bug.cgi?id=89300 + + Reviewed by Adam Barth. + + The 1.0 draft of the Content Security Policy spec is just about to + move to Last Call. We'll hide work on the upcoming 1.1 spec behind + this ENABLE flag, disabled by default. + + Spec: https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html + + * Configurations/FeatureDefines.xcconfig: + +2012-06-18 Mark Lam <mark.lam@apple.com> + + Changed JSC to always record line number information so that error.stack + and window.onerror() can report proper line numbers. + https://bugs.webkit.org/show_bug.cgi?id=89410 + + Reviewed by Geoffrey Garen. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::lineNumberForBytecodeOffset): + (JSC::CodeBlock::shrinkToFit): m_lineInfo is now available unconditionally. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::addLineInfo): + (JSC::CodeBlock::hasLineInfo): Unused. Now removed. + (JSC::CodeBlock::needsCallReturnIndices): + (CodeBlock): + (RareData): Hoisted m_lineInfo out of m_rareData. m_lineInfo is now + filled in unconditionally. + + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::addLineInfo): + +2012-06-18 Andy Estes <aestes@apple.com> + + Fix r120663, which didn't land the change that was reviewed. + +2012-06-18 Andy Estes <aestes@apple.com> + + [JSC] In JSGlobalData.cpp, enableAssembler() sometimes leaks two CF objects + https://bugs.webkit.org/show_bug.cgi?id=89415 + + Reviewed by Sam Weinig. + + In the case where canUseJIT was a non-NULL CFBooleanRef, + enableAssembler() would leak both canUseJITKey and canUseJIT by + returning before calling CFRelease. Fix this by using RetainPtr. + + * runtime/JSGlobalData.cpp: + (JSC::enableAssembler): + +2012-06-17 Geoffrey Garen <ggaren@apple.com> + + GC copy phase spends needless cycles zero-filling blocks + https://bugs.webkit.org/show_bug.cgi?id=89128 + + Reviewed by Gavin Barraclough. + + We only need to zero-fill when we're allocating memory that might not + get fully initialized before GC. + + * heap/CopiedBlock.h: + (JSC::CopiedBlock::createNoZeroFill): + (JSC::CopiedBlock::create): Added a way to create without zero-filling. + This is our optimization. + + (JSC::CopiedBlock::zeroFillToEnd): + (JSC::CopiedBlock::CopiedBlock): Split zero-filling out from creation, + so we can sometimes create without zero-filling. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::init): + (JSC::CopiedSpace::tryAllocateSlowCase): + (JSC::CopiedSpace::doneCopying): Renamed addNewBlock to allocateBlock() + to clarify that the new block is always newly-allocated. + + (JSC::CopiedSpace::doneFillingBlock): Make sure to zero-fill to the end + of a block that might be used in the future for allocation. (Most of the + time, this is a no-op, since we've already filled the block completely.) + + (JSC::CopiedSpace::getFreshBlock): Removed this function because the + abstraction of "allocation must succeed" is no longer useful. + + * heap/CopiedSpace.h: Updated declarations to match. + + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::allocateBlockForCopyingPhase): New function, which + knows that it can skip zero-filling. + + Added tighter scoping to our lock, to improve parallelism. + + (JSC::CopiedSpace::allocateBlock): Folded getFreshBlock functionality + into this function, for simplicity. + + * heap/MarkStack.cpp: + (JSC::SlotVisitor::startCopying): + (JSC::SlotVisitor::allocateNewSpace): Use our new zero-fill-free helper + function for great good. + +2012-06-17 Filip Pizlo <fpizlo@apple.com> + + DFG should attempt to use structure watchpoints for all inlined get_by_id's and put_by_id's + https://bugs.webkit.org/show_bug.cgi?id=89316 + + Reviewed by Oliver Hunt. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + +2012-06-15 Yong Li <yoli@rim.com> + + [BlackBerry] Put platform-specific GC policy in GCActivityCallback + https://bugs.webkit.org/show_bug.cgi?id=89236 + + Reviewed by Rob Buis. + + Add GCActivityCallbackBlackBerry.cpp and implement platform-specific + low memory GC policy there. + + * PlatformBlackBerry.cmake: + * heap/Heap.h: + (JSC::Heap::isSafeToCollect): Added. + * runtime/GCActivityCallbackBlackBerry.cpp: Added. + (JSC): + (JSC::DefaultGCActivityCallbackPlatformData::DefaultGCActivityCallbackPlatformData): + (DefaultGCActivityCallbackPlatformData): + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::~DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::didAllocate): + (JSC::DefaultGCActivityCallback::willCollect): + (JSC::DefaultGCActivityCallback::synchronize): + (JSC::DefaultGCActivityCallback::cancel): + +2012-06-15 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to set watchpoints on structure transitions in the + method check prototype chain + https://bugs.webkit.org/show_bug.cgi?id=89058 + + Adding the same assertion to 32-bit that I added to 64-bit. This change + does not affect correctness but it's a good thing for assertion coverage. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-06-13 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to set watchpoints on structure transitions in the + method check prototype chain + https://bugs.webkit.org/show_bug.cgi?id=89058 + + Reviewed by Gavin Barraclough. + + This adds the ability to set watchpoints on Structures, and then does + the most modest thing we can do with this ability: the DFG now sets + watchpoints on structure transitions in the prototype chain of method + checks. + + This appears to be a >1% speed-up on V8. + + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFromLLInt): + (JSC::PutByIdStatus::computeFor): + * bytecode/StructureSet.h: + (JSC::StructureSet::containsOnly): + (StructureSet): + * bytecode/Watchpoint.cpp: + (JSC::WatchpointSet::WatchpointSet): + (JSC::InlineWatchpointSet::add): + (JSC): + (JSC::InlineWatchpointSet::inflateSlow): + (JSC::InlineWatchpointSet::freeFat): + * bytecode/Watchpoint.h: + (WatchpointSet): + (JSC): + (InlineWatchpointSet): + (JSC::InlineWatchpointSet::InlineWatchpointSet): + (JSC::InlineWatchpointSet::~InlineWatchpointSet): + (JSC::InlineWatchpointSet::hasBeenInvalidated): + (JSC::InlineWatchpointSet::isStillValid): + (JSC::InlineWatchpointSet::startWatching): + (JSC::InlineWatchpointSet::notifyWrite): + (JSC::InlineWatchpointSet::isFat): + (JSC::InlineWatchpointSet::fat): + (JSC::InlineWatchpointSet::inflate): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.h: + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::isCellConstant): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::addWeakReferences): + (JITCompiler): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasStructure): + (Node): + (JSC::DFG::Node::structure): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCachePutByID): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * runtime/Structure.cpp: + (JSC::Structure::Structure): + * runtime/Structure.h: + (JSC::Structure::transitionWatchpointSetHasBeenInvalidated): + (Structure): + (JSC::Structure::transitionWatchpointSetIsStillValid): + (JSC::Structure::addTransitionWatchpoint): + (JSC::Structure::notifyTransitionFromThisStructure): + (JSC::JSCell::setStructure): + * runtime/SymbolTable.cpp: + (JSC::SymbolTableEntry::attemptToWatch): + +2012-06-13 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to set watchpoints on global variables + https://bugs.webkit.org/show_bug.cgi?id=88692 + + Reviewed by Geoffrey Garen. + + Rolling back in after fixing Windows build issues, and implementing + branchTest8 for the Qt port's strange assemblers. + + This implements global variable constant folding by allowing the optimizing + compiler to set a "watchpoint" on globals that it wishes to constant fold. + If the watchpoint fires, then an OSR exit is forced by overwriting the + machine code that the optimizing compiler generated with a jump. + + As such, this patch is adding quite a bit of stuff: + + - Jump replacement on those hardware targets supported by the optimizing + JIT. It is now possible to patch in a jump instruction over any recorded + watchpoint label. The jump must be "local" in the sense that it must be + within the range of the largest jump distance supported by a one + instruction jump. + + - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node + that records the location where a jump must be inserted and the + destination to which it should jump. Watchpoints can be added to a + WatchpointSet. The WatchpointSet can be fired all at once, which plants + all jumps. WatchpointSet also remembers if it had ever been invalidated, + which allows for monotonicity: we typically don't want to optimize using + watchpoints on something for which watchpoints had previously fired. The + act of notifying a WatchpointSet has a trivial fast path in case no + Watchpoints are registered (one-byte load+branch). + + - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(), + except that you don't have to emit branches. But, you need to know what + WatchpointSet to add the resulting Watchpoint to. Not everything that + you could write a speculationCheck() for will have a WatchpointSet that + would get notified if the condition you were speculating against became + invalid. + + - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can + do so without incurring any space overhead for those entries that don't + have WatchpointSets. + + - The bytecode generator infers all global function variables to be + watchable, and makes all stores perform the WatchpointSet's write check, + and marks all loads as being potentially watchable (i.e. you can compile + them to a watchpoint and a constant). + + Put together, this allows for fully sleazy inlining of calls to globally + declared functions. The inline prologue will no longer contain the load of + the function, or any checks of the function you're calling. I.e. it's + pretty much like the kind of inlining you would see in Java or C++. + Furthermore, the watchpointing functionality is built to be fairly general, + and should allow setting watchpoints on all sorts of interesting things + in the future. + + The sleazy inlining means that we will now sometimes inline in code paths + that have never executed. Previously, to inline we would have either had + to have executed the call (to read the call's inline cache) or have + executed the method check (to read the method check's inline cache). Now, + we might inline when the callee is a watched global variable. This + revealed some humorous bugs. First, constant folding disagreed with CFA + over what kinds of operations can clobber (example: code path A is dead + but stores a String into variable X, all other code paths store 0 into + X, and then you do CompareEq(X, 0) - CFA will say that this is a non- + clobbering constant, but constant folding thought it was clobbering + because it saw the String prediction). Second, inlining would crash if + the inline callee had not been compiled. This patch fixes both bugs, + since otherwise run-javascriptcore-tests would report regressions. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::ARMv7Assembler): + (JSC::ARMv7Assembler::labelForWatchpoint): + (JSC::ARMv7Assembler::label): + (JSC::ARMv7Assembler::replaceWithJump): + (JSC::ARMv7Assembler::maxJumpReplacementSize): + * assembler/AbstractMacroAssembler.h: + (JSC): + (AbstractMacroAssembler): + (Label): + (JSC::AbstractMacroAssembler::watchpointLabel): + (JSC::AbstractMacroAssembler::readPointer): + * assembler/AssemblerBuffer.h: + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::branchTest8): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::replaceWithJump): + (JSC::MacroAssemblerARM::maxJumpReplacementSize): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::load8Signed): + (JSC::MacroAssemblerARMv7::load16Signed): + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::replaceWithJump): + (JSC::MacroAssemblerARMv7::maxJumpReplacementSize): + (JSC::MacroAssemblerARMv7::branchTest8): + (JSC::MacroAssemblerARMv7::jump): + (JSC::MacroAssemblerARMv7::makeBranch): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::branchTest8): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::replaceWithJump): + (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::branchTest8): + (MacroAssemblerSH4): + (JSC::MacroAssemblerSH4::replaceWithJump): + (JSC::MacroAssemblerSH4::maxJumpReplacementSize): + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::branchTest8): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::replaceWithJump): + (MacroAssemblerX86Common): + (JSC::MacroAssemblerX86Common::maxJumpReplacementSize): + * assembler/MacroAssemblerX86_64.h: + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::branchTest8): + * assembler/X86Assembler.h: + (JSC::X86Assembler::X86Assembler): + (X86Assembler): + (JSC::X86Assembler::cmpb_im): + (JSC::X86Assembler::testb_im): + (JSC::X86Assembler::labelForWatchpoint): + (JSC::X86Assembler::label): + (JSC::X86Assembler::replaceWithJump): + (JSC::X86Assembler::maxJumpReplacementSize): + (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::dump): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::appendOSRExit): + (JSC::CodeBlock::appendSpeculationRecovery): + (CodeBlock): + (JSC::CodeBlock::appendWatchpoint): + (JSC::CodeBlock::numberOfWatchpoints): + (JSC::CodeBlock::watchpoint): + (DFGData): + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + (JSC::DFG::exitKindIsCountable): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeForChain): + * bytecode/Instruction.h: + (Instruction): + (JSC::Instruction::Instruction): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/Watchpoint.cpp: Added. + (JSC): + (JSC::Watchpoint::~Watchpoint): + (JSC::Watchpoint::correctLabels): + (JSC::Watchpoint::fire): + (JSC::WatchpointSet::WatchpointSet): + (JSC::WatchpointSet::~WatchpointSet): + (JSC::WatchpointSet::add): + (JSC::WatchpointSet::notifyWriteSlow): + (JSC::WatchpointSet::fireAllWatchpoints): + * bytecode/Watchpoint.h: Added. + (JSC): + (Watchpoint): + (JSC::Watchpoint::Watchpoint): + (JSC::Watchpoint::setDestination): + (WatchpointSet): + (JSC::WatchpointSet::isStillValid): + (JSC::WatchpointSet::hasBeenInvalidated): + (JSC::WatchpointSet::startWatching): + (JSC::WatchpointSet::notifyWrite): + (JSC::WatchpointSet::addressOfIsWatched): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixResolveNode::emitBytecode): + (JSC::PrefixResolveNode::emitBytecode): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::clobberStructures): + * dfg/DFGAbstractState.h: + (AbstractState): + (JSC::DFG::AbstractState::didClobber): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArguments): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGCorrectableJumpPoint.h: + (JSC::DFG::CorrectableJumpPoint::isSet): + (CorrectableJumpPoint): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifierNumberForCheck): + (Node): + (JSC::DFG::Node::identifierNumberForCheck): + (JSC::DFG::Node::hasRegisterPointer): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::appendCall): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_put_global_var_check): + (JSC): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_put_global_var_check): + (JSC): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (LLInt): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSObject.cpp: + (JSC::JSObject::removeDirect): + * runtime/JSObject.h: + (JSObject): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/SymbolTable.cpp: Added. + (JSC): + (JSC::SymbolTableEntry::copySlow): + (JSC::SymbolTableEntry::freeFatEntrySlow): + (JSC::SymbolTableEntry::couldBeWatched): + (JSC::SymbolTableEntry::attemptToWatch): + (JSC::SymbolTableEntry::addressOfIsWatched): + (JSC::SymbolTableEntry::addWatchpoint): + (JSC::SymbolTableEntry::notifyWriteSlow): + (JSC::SymbolTableEntry::inflateSlow): + * runtime/SymbolTable.h: + (JSC): + (SymbolTableEntry): + (Fast): + (JSC::SymbolTableEntry::Fast::Fast): + (JSC::SymbolTableEntry::Fast::isNull): + (JSC::SymbolTableEntry::Fast::getIndex): + (JSC::SymbolTableEntry::Fast::isReadOnly): + (JSC::SymbolTableEntry::Fast::getAttributes): + (JSC::SymbolTableEntry::Fast::isFat): + (JSC::SymbolTableEntry::SymbolTableEntry): + (JSC::SymbolTableEntry::~SymbolTableEntry): + (JSC::SymbolTableEntry::operator=): + (JSC::SymbolTableEntry::isNull): + (JSC::SymbolTableEntry::getIndex): + (JSC::SymbolTableEntry::getFast): + (JSC::SymbolTableEntry::getAttributes): + (JSC::SymbolTableEntry::isReadOnly): + (JSC::SymbolTableEntry::watchpointSet): + (JSC::SymbolTableEntry::notifyWrite): + (FatEntry): + (JSC::SymbolTableEntry::FatEntry::FatEntry): + (JSC::SymbolTableEntry::isFat): + (JSC::SymbolTableEntry::fatEntry): + (JSC::SymbolTableEntry::inflate): + (JSC::SymbolTableEntry::bits): + (JSC::SymbolTableEntry::freeFatEntry): + (JSC::SymbolTableEntry::pack): + (JSC::SymbolTableEntry::isValidIndex): + +2012-06-13 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r120172. + http://trac.webkit.org/changeset/120172 + https://bugs.webkit.org/show_bug.cgi?id=88976 + + The patch causes compilation failures on Gtk, Qt and Apple Win + bots (Requested by zdobersek on #webkit). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::nop): + (JSC::ARMv7Assembler::label): + (JSC::ARMv7Assembler::readPointer): + (ARMv7Assembler): + * assembler/AbstractMacroAssembler.h: + (JSC): + (AbstractMacroAssembler): + (Label): + * assembler/AssemblerBuffer.h: + * assembler/MacroAssemblerARM.h: + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::nop): + (JSC::MacroAssemblerARMv7::jump): + (JSC::MacroAssemblerARMv7::makeBranch): + * assembler/MacroAssemblerMIPS.h: + * assembler/MacroAssemblerSH4.h: + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::moveWithPatch): + * assembler/MacroAssemblerX86Common.h: + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::branchTest8): + * assembler/X86Assembler.h: + (JSC::X86Assembler::cmpb_im): + (JSC::X86Assembler::codeSize): + (JSC::X86Assembler::label): + (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::appendOSRExit): + (JSC::CodeBlock::appendSpeculationRecovery): + (DFGData): + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + (JSC::DFG::exitKindIsCountable): + * bytecode/Instruction.h: + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/Watchpoint.cpp: Removed. + * bytecode/Watchpoint.h: Removed. + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixResolveNode::emitBytecode): + (JSC::PrefixResolveNode::emitBytecode): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::clobberStructures): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArguments): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGCorrectableJumpPoint.h: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasRegisterPointer): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::appendCallSetResult): + (JSC::DFG::SpeculativeJIT::speculationCheck): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITPropertyAccess.cpp: + * jit/JITPropertyAccess32_64.cpp: + * jit/JITStubs.cpp: + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSObject.cpp: + (JSC::JSObject::removeDirect): + * runtime/JSObject.h: + (JSObject): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/SymbolTable.cpp: Removed. + * runtime/SymbolTable.h: + (JSC): + (JSC::SymbolTableEntry::isNull): + (JSC::SymbolTableEntry::getIndex): + (SymbolTableEntry): + (JSC::SymbolTableEntry::getAttributes): + (JSC::SymbolTableEntry::isReadOnly): + (JSC::SymbolTableEntry::pack): + (JSC::SymbolTableEntry::isValidIndex): + +2012-06-12 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to set watchpoints on global variables + https://bugs.webkit.org/show_bug.cgi?id=88692 + + Reviewed by Geoffrey Garen. + + This implements global variable constant folding by allowing the optimizing + compiler to set a "watchpoint" on globals that it wishes to constant fold. + If the watchpoint fires, then an OSR exit is forced by overwriting the + machine code that the optimizing compiler generated with a jump. + + As such, this patch is adding quite a bit of stuff: + + - Jump replacement on those hardware targets supported by the optimizing + JIT. It is now possible to patch in a jump instruction over any recorded + watchpoint label. The jump must be "local" in the sense that it must be + within the range of the largest jump distance supported by a one + instruction jump. + + - WatchpointSets and Watchpoints. A Watchpoint is a doubly-linked list node + that records the location where a jump must be inserted and the + destination to which it should jump. Watchpoints can be added to a + WatchpointSet. The WatchpointSet can be fired all at once, which plants + all jumps. WatchpointSet also remembers if it had ever been invalidated, + which allows for monotonicity: we typically don't want to optimize using + watchpoints on something for which watchpoints had previously fired. The + act of notifying a WatchpointSet has a trivial fast path in case no + Watchpoints are registered (one-byte load+branch). + + - SpeculativeJIT::speculationWatchpoint(). It's like speculationCheck(), + except that you don't have to emit branches. But, you need to know what + WatchpointSet to add the resulting Watchpoint to. Not everything that + you could write a speculationCheck() for will have a WatchpointSet that + would get notified if the condition you were speculating against became + invalid. + + - SymbolTableEntry now has the ability to refer to a WatchpointSet. It can + do so without incurring any space overhead for those entries that don't + have WatchpointSets. + + - The bytecode generator infers all global function variables to be + watchable, and makes all stores perform the WatchpointSet's write check, + and marks all loads as being potentially watchable (i.e. you can compile + them to a watchpoint and a constant). + + Put together, this allows for fully sleazy inlining of calls to globally + declared functions. The inline prologue will no longer contain the load of + the function, or any checks of the function you're calling. I.e. it's + pretty much like the kind of inlining you would see in Java or C++. + Furthermore, the watchpointing functionality is built to be fairly general, + and should allow setting watchpoints on all sorts of interesting things + in the future. + + The sleazy inlining means that we will now sometimes inline in code paths + that have never executed. Previously, to inline we would have either had + to have executed the call (to read the call's inline cache) or have + executed the method check (to read the method check's inline cache). Now, + we might inline when the callee is a watched global variable. This + revealed some humorous bugs. First, constant folding disagreed with CFA + over what kinds of operations can clobber (example: code path A is dead + but stores a String into variable X, all other code paths store 0 into + X, and then you do CompareEq(X, 0) - CFA will say that this is a non- + clobbering constant, but constant folding thought it was clobbering + because it saw the String prediction). Second, inlining would crash if + the inline callee had not been compiled. This patch fixes both bugs, + since otherwise run-javascriptcore-tests would report regressions. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::ARMv7Assembler): + (JSC::ARMv7Assembler::labelForWatchpoint): + (JSC::ARMv7Assembler::label): + (JSC::ARMv7Assembler::replaceWithJump): + (JSC::ARMv7Assembler::maxJumpReplacementSize): + * assembler/AbstractMacroAssembler.h: + (JSC): + (AbstractMacroAssembler): + (Label): + (JSC::AbstractMacroAssembler::watchpointLabel): + * assembler/AssemblerBuffer.h: + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::replaceWithJump): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::maxJumpReplacementSize): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::replaceWithJump): + (JSC::MacroAssemblerARMv7::maxJumpReplacementSize): + (JSC::MacroAssemblerARMv7::branchTest8): + (JSC::MacroAssemblerARMv7::jump): + (JSC::MacroAssemblerARMv7::makeBranch): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::replaceWithJump): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::replaceWithJump): + (MacroAssemblerSH4): + (JSC::MacroAssemblerSH4::maxJumpReplacementSize): + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::branchTest8): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::replaceWithJump): + (MacroAssemblerX86Common): + (JSC::MacroAssemblerX86Common::maxJumpReplacementSize): + * assembler/MacroAssemblerX86_64.h: + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::branchTest8): + * assembler/X86Assembler.h: + (JSC::X86Assembler::X86Assembler): + (X86Assembler): + (JSC::X86Assembler::cmpb_im): + (JSC::X86Assembler::testb_im): + (JSC::X86Assembler::labelForWatchpoint): + (JSC::X86Assembler::label): + (JSC::X86Assembler::replaceWithJump): + (JSC::X86Assembler::maxJumpReplacementSize): + (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::appendOSRExit): + (JSC::CodeBlock::appendSpeculationRecovery): + (CodeBlock): + (JSC::CodeBlock::appendWatchpoint): + (JSC::CodeBlock::numberOfWatchpoints): + (JSC::CodeBlock::watchpoint): + (DFGData): + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + (JSC::DFG::exitKindIsCountable): + * bytecode/Instruction.h: + (Instruction): + (JSC::Instruction::Instruction): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/Watchpoint.cpp: Added. + (JSC): + (JSC::Watchpoint::~Watchpoint): + (JSC::Watchpoint::correctLabels): + (JSC::Watchpoint::fire): + (JSC::WatchpointSet::WatchpointSet): + (JSC::WatchpointSet::~WatchpointSet): + (JSC::WatchpointSet::add): + (JSC::WatchpointSet::notifyWriteSlow): + (JSC::WatchpointSet::fireAllWatchpoints): + * bytecode/Watchpoint.h: Added. + (JSC): + (Watchpoint): + (JSC::Watchpoint::Watchpoint): + (JSC::Watchpoint::setDestination): + (WatchpointSet): + (JSC::WatchpointSet::isStillValid): + (JSC::WatchpointSet::hasBeenInvalidated): + (JSC::WatchpointSet::startWatching): + (JSC::WatchpointSet::notifyWrite): + (JSC::WatchpointSet::addressOfIsWatched): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixResolveNode::emitBytecode): + (JSC::PrefixResolveNode::emitBytecode): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::clobberStructures): + * dfg/DFGAbstractState.h: + (AbstractState): + (JSC::DFG::AbstractState::didClobber): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArguments): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGCorrectableJumpPoint.h: + (JSC::DFG::CorrectableJumpPoint::isSet): + (CorrectableJumpPoint): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifierNumberForCheck): + (Node): + (JSC::DFG::Node::identifierNumberForCheck): + (JSC::DFG::Node::hasRegisterPointer): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::appendCall): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_put_global_var_check): + (JSC): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_put_global_var_check): + (JSC): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITStubs.cpp: + (JSC::JITThunks::JITThunks): + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (LLInt): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSObject.cpp: + (JSC::JSObject::removeDirect): + * runtime/JSObject.h: + (JSObject): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/SymbolTable.cpp: Added. + (JSC): + (JSC::SymbolTableEntry::copySlow): + (JSC::SymbolTableEntry::freeFatEntrySlow): + (JSC::SymbolTableEntry::couldBeWatched): + (JSC::SymbolTableEntry::attemptToWatch): + (JSC::SymbolTableEntry::addressOfIsWatched): + (JSC::SymbolTableEntry::addWatchpoint): + (JSC::SymbolTableEntry::notifyWriteSlow): + (JSC::SymbolTableEntry::inflateSlow): + * runtime/SymbolTable.h: + (JSC): + (SymbolTableEntry): + (Fast): + (JSC::SymbolTableEntry::Fast::Fast): + (JSC::SymbolTableEntry::Fast::isNull): + (JSC::SymbolTableEntry::Fast::getIndex): + (JSC::SymbolTableEntry::Fast::isReadOnly): + (JSC::SymbolTableEntry::Fast::getAttributes): + (JSC::SymbolTableEntry::Fast::isFat): + (JSC::SymbolTableEntry::SymbolTableEntry): + (JSC::SymbolTableEntry::~SymbolTableEntry): + (JSC::SymbolTableEntry::operator=): + (JSC::SymbolTableEntry::isNull): + (JSC::SymbolTableEntry::getIndex): + (JSC::SymbolTableEntry::getFast): + (JSC::SymbolTableEntry::getAttributes): + (JSC::SymbolTableEntry::isReadOnly): + (JSC::SymbolTableEntry::watchpointSet): + (JSC::SymbolTableEntry::notifyWrite): + (FatEntry): + (JSC::SymbolTableEntry::FatEntry::FatEntry): + (JSC::SymbolTableEntry::isFat): + (JSC::SymbolTableEntry::fatEntry): + (JSC::SymbolTableEntry::inflate): + (JSC::SymbolTableEntry::bits): + (JSC::SymbolTableEntry::freeFatEntry): + (JSC::SymbolTableEntry::pack): + (JSC::SymbolTableEntry::isValidIndex): + +2012-06-12 Filip Pizlo <fpizlo@apple.com> + + Unreviewed build fix for ARMv7 debug builds. + + * jit/JITStubs.cpp: + (JSC::JITThunks::JITThunks): + +2012-06-12 Geoffrey Garen <ggaren@apple.com> + + Build fix for case-sensitive file systems: use the right case. + + * heap/ListableHandler.h: + +2012-06-11 Geoffrey Garen <ggaren@apple.com> + + GC should be 1.7X faster + https://bugs.webkit.org/show_bug.cgi?id=88840 + + Reviewed by Oliver Hunt. + + I profiled, and removed anything that showed up as a concurrency + bottleneck. Then, I added 3 threads to our max thread count, since we + can scale up to more threads now. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + (JSC::BlockAllocator::~BlockAllocator): + (JSC::BlockAllocator::releaseFreeBlocks): + (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): + (JSC::BlockAllocator::waitForRelativeTime): + (JSC::BlockAllocator::blockFreeingThreadMain): + * heap/BlockAllocator.h: + (BlockAllocator): + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::deallocate): Use a spin lock for the common case + where we're just popping a linked list. (A pthread mutex would sleep our + thread even if the lock were only contended for a microsecond.) + + Scope the lock to avoid holding it while allocating VM, since that's a + slow activity and it doesn't modify any of our data structures. + + We still use a pthread mutex to handle our condition variable since we + have to, and it's not a hot path. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::CopiedSpace): + (JSC::CopiedSpace::doneFillingBlock): + * heap/CopiedSpace.h: + (JSC::CopiedSpace::CopiedSpace): Use a spin lock for the to space lock, + since it just guards linked list and hash table manipulation. + + * heap/MarkStack.cpp: + (JSC::MarkStackSegmentAllocator::MarkStackSegmentAllocator): + (JSC::MarkStackSegmentAllocator::allocate): + (JSC::MarkStackSegmentAllocator::release): + (JSC::MarkStackSegmentAllocator::shrinkReserve): Use a spin lock, since + we're just managing a linked list. + + (JSC::MarkStackArray::donateSomeCellsTo): Changed donation to be proportional + to our current stack size. This fixes cases where we used to donate too + much. Interestingly, donating too much was starving the donor (when it + ran out of work later) *and* the recipient (since it had to wait on a + long donation operation to complete before it could acquire the lock). + + In the worst case, we're still guaranteed to donate N cells in roughly log N time. + + This change also fixes cases where we used to donate too little, since + we would always keep a fixed minimum number of cells. In the worst case, + with N marking threads, would could have N large object graph roots in + our stack for the duration of GC, and scale to only 1 thread. + + It's an interesting observation that a single object in the mark stack + might represent an arbitrarily large object graph -- and only the act + of marking can find out. + + (JSC::MarkStackArray::stealSomeCellsFrom): Steal in proportion to idle + threads. Once again, this fixes cases where constants could cause us + to steal too much or too little. + + (JSC::SlotVisitor::donateKnownParallel): Always wake up other threads + if they're idle. We can afford to do this because we're conservative + about when we donate. + + (JSC::SlotVisitor::drainFromShared): + * heap/MarkStack.h: + (MarkStackSegmentAllocator): + (MarkStackArray): + (JSC): + * heap/SlotVisitor.h: Merged the "should I donate?" decision into a + single function, for simplicity. + + * runtime/Options.cpp: + (minimumNumberOfScansBetweenRebalance): Reduced the delay before donation + a lot. We can afford to do this because, in the common case, donation is + a single branch that decides not to donate. + + (cpusToUse): Use more CPUs now, since we scale better now. + + * runtime/Options.h: + (Options): Removed now-unused variables. + +2012-06-12 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(120121): inspector tests crash in DFG + https://bugs.webkit.org/show_bug.cgi?id=88941 + + Reviewed by Geoffrey Garen. + + The CFG simplifier has two different ways of fixing up GetLocal, Phantom, and Flush. If we've + already fixed up the node one way, we shouldn't try the other way. The reason why we shouldn't + is that the second way depends on the node referring to other nodes in the to-be-jettisoned + block. After fixup they potentially will refer to nodes in the block being merged to. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-06-12 Leo Yang <leo.yang@torchmobile.com.cn> + + Dynamic hash table in DOMObjectHashTableMap is wrong in multiple threads + https://bugs.webkit.org/show_bug.cgi?id=87334 + + Reviewed by Geoffrey Garen. + + Add a copy member function to JSC::HasTable. This function will copy all data + members except for *table* which contains thread specific data that prevents + up copying it. When you want to copy a JSC::HashTable that was constructed + on another thread you should call JSC::HashTable::copy(). + + * runtime/Lookup.h: + (JSC::HashTable::copy): + (HashTable): + +2012-06-12 Filip Pizlo <fpizlo@apple.com> + + DFG should not ASSERT if you have a double use of a variable that is not revealed to be a double + until after CFG simplification + https://bugs.webkit.org/show_bug.cgi?id=88927 + <rdar://problem/11513971> + + Reviewed by Geoffrey Garen. + + Speculation fixup needs to run if simplification did things, because simplification can change + predictions - particularly if you had a control flow path that stored weird things into a + variable, but that path got axed by the simplifier. + + Running fixup in the fixpoint requires making it idempotent, which it previously wasn't. Only + one place needed to be changed, namely the un-MustGenerate-ion of ValueToInt32. + + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2012-06-12 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r119779): Javascript TypeError: 'undefined' is not an object + https://bugs.webkit.org/show_bug.cgi?id=88783 + <rdar://problem/11640299> + + Reviewed by Geoffrey Garen. + + If you don't keep alive the base of an object access over the various checks + you do for the prototype chain, you're going to have a bad time. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleGetById): + +2012-06-12 Hojong Han <hojong.han@samsung.com> + + Property names of the built-in object cannot be retrieved + after trying to delete one of its properties + https://bugs.webkit.org/show_bug.cgi?id=86461 + + Reviewed by Gavin Barraclough. + + * runtime/JSObject.cpp: + (JSC::getClassPropertyNames): + (JSC::JSObject::getOwnPropertyNames): + +2012-06-11 Gyuyoung Kim <gyuyoung.kim@samsung.com> + + [CMAKE][EFL] Remove duplicated executable output path + https://bugs.webkit.org/show_bug.cgi?id=88765 + + Reviewed by Daniel Bates. + + CMake files for EFL port have redefined executable output path. However, EFL port doesn't + need to define again because it is already defined in top-level CMake file. + + * shell/CMakeLists.txt: + +2012-06-11 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck issues. + + * GNUmakefile.list.am: Remove non existent header file. + +2012-06-10 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for !ENABLE(JIT) after r119844 and r119925. + + * runtime/Executable.h: + (ExecutableBase): + (JSC::ExecutableBase::clearCodeVirtual): + +2012-06-10 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for !ENABLE(JIT) after r119844. + + * runtime/Executable.h: + (ExecutableBase): + (JSC): + +2012-06-09 Dominic Cooney <dominicc@chromium.org> + + [Chromium] Remove JavaScriptCore dependencies from gyp + https://bugs.webkit.org/show_bug.cgi?id=88510 + + Reviewed by Adam Barth. + + Chromium doesn't support JSC any more and there doesn't seem to be + a strong interest in using GYP as the common build system in other + ports. + + * JavaScriptCore.gyp/JavaScriptCore.gyp: WebCore still depends on YARR interpreter. + * JavaScriptCore.gypi: Only include YARR source. + * gyp/JavaScriptCore.gyp: Removed. + * gyp/gtk.gyp: Removed. + +2012-06-09 Geoffrey Garen <ggaren@apple.com> + + Unreviewed, rolling back in part2 of r118646. + + This patch removes eager finalization. + + Weak pointer finalization should be lazy + https://bugs.webkit.org/show_bug.cgi?id=87599 + + Reviewed by Sam Weinig. + + * heap/Heap.cpp: + (JSC::Heap::collect): Don't finalize eagerly -- we'll do it lazily. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): Do sweep weak sets when sweeping a block, + since we won't get another chance. + + * heap/MarkedBlock.h: + (JSC::MarkedBlock::sweepWeakSet): + * heap/MarkedSpace.cpp: + (MarkedSpace::WeakSetSweep): + * heap/MarkedSpace.h: + (JSC::MarkedSpace::sweepWeakSets): Removed now-unused code. + +2012-06-09 Sukolsak Sakshuwong <sukolsak@google.com> + + Add UNDO_MANAGER flag + https://bugs.webkit.org/show_bug.cgi?id=87908 + + Reviewed by Tony Chang. + + * Configurations/FeatureDefines.xcconfig: + +2012-06-08 Geoffrey Garen <ggaren@apple.com> + + Unreviewed, rolling back in part1 of r118646. + + This patch includes everything necessary for lazy finalization, but + keeps eager finalization enabled for the time being. + + Weak pointer finalization should be lazy + https://bugs.webkit.org/show_bug.cgi?id=87599 + + Reviewed by Sam Weinig. + + * heap/MarkedBlock.cpp: + * heap/MarkedBlock.h: + (JSC::MarkedBlock::resetAllocator): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::resetAllocators): + * heap/MarkedSpace.h: + (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore. + It will happen automatically when a weak set is swept. It's simpler to + have only one canonical way for this to happen, and it wasn't buying + us anything to do it eagerly. + * heap/WeakBlock.cpp: + (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know + the sweep would be a no-op. If even one finalizer is pending, we need to + run it, since we won't get another chance. + * heap/WeakSet.cpp: + (JSC::WeakSet::sweep): This loop can be simpler now that + WeakBlock::sweep() does what we mean. + Reset our allocator after a sweep because this is the optimal time to + start trying to recycle old weak pointers. + (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an + allocator because we've swept already, and forcing a new sweep would be + wasteful. + * heap/WeakSet.h: + (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink + because the shrink may have removed the block the allocator was going to + allocate out of. + +2012-06-08 Gavin Barraclough <barraclough@apple.com> + + Unreviewed roll out r119795. + + This broke jquery/core.html + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + * llint/LowLevelInterpreter.asm: + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalThis.cpp: + (JSC::JSGlobalThis::setUnwrappedObject): + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + (JSC::JSObject::createInheritorID): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::resetInheritorID): + (JSC): + (JSC::JSObject::offsetOfInheritorID): + (JSC::JSObject::inheritorID): + +2012-06-08 Filip Pizlo <fpizlo@apple.com> + + PredictedType should be called SpeculatedType + https://bugs.webkit.org/show_bug.cgi?id=88477 + + Unreviewed, fix a renaming goof from http://trac.webkit.org/changeset/119660. + I accidentally renamed ByteCodeParser::getPrediction to + ByteCodeParser::getSpeculation. That was not the intent. This changes it + back. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::addCall): + (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): + (JSC::DFG::ByteCodeParser::getPrediction): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::parseBlock): + +2012-06-08 Andy Wingo <wingo@igalia.com> + + Explictly mark stubs called by JIT as being internal + https://bugs.webkit.org/show_bug.cgi?id=88552 + + Reviewed by Filip Pizlo. + + * dfg/DFGOSRExitCompiler.h: + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * jit/HostCallReturnValue.h: + * jit/JITStubs.cpp: + * jit/JITStubs.h: + * jit/ThunkGenerators.cpp: + * llint/LLIntSlowPaths.h: Mark a bunch of stubs as being + WTF_INTERNAL. Change most calls to SYMBOL_STRING_RELOCATION to + LOCAL_REFERENCE, or GLOBAL_REFERENCE in the case of the wrappers + to truly global symbols. + * offlineasm/asm.rb: Generate LOCAL_REFERENCE instead of + SYMBOL_STRING_RELOCATION. + +2012-06-08 Geoffrey Garen <ggaren@apple.com> + + Don't rely on weak pointers for eager CodeBlock finalization + https://bugs.webkit.org/show_bug.cgi?id=88465 + + Reviewed by Gavin Barraclough. + + This is incompatible with lazy weak pointer finalization. + + I considered just making CodeBlock finalization lazy-friendly, but it + turns out that the heap is already way up in CodeBlock's business when + it comes to finalization, so I decided to finish the job and move full + responsibility for CodeBlock finalization into the heap. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Maybe this + will build. + + * debugger/Debugger.cpp: Updated for rename. + + * heap/Heap.cpp: + (JSC::Heap::deleteAllCompiledCode): Renamed for consistency. Fixed a bug + where we would not delete code for a code block that had been previously + jettisoned. I don't know if this happens in practice -- I mostly did + this to improve consistency with deleteUnmarkedCompiledCode. + + (JSC::Heap::deleteUnmarkedCompiledCode): New function, responsible for + eager finalization of unmarked code blocks. + + (JSC::Heap::collect): Updated for rename. Updated to call + deleteUnmarkedCompiledCode(), which takes care of jettisoned DFG code + blocks too. + + (JSC::Heap::addCompiledCode): Renamed, since this points to all code + now, not just functions. + + * heap/Heap.h: + (Heap): Keep track of all user code, not just functions. This is a + negligible additional overhead, since most code is function code. + + * runtime/Executable.cpp: + (JSC::*::finalize): Removed these functions, since we don't rely on + weak pointer finalization anymore. + + (JSC::FunctionExecutable::FunctionExecutable): Moved linked-list stuff + into base class so all executables can be in the list. + + (JSC::EvalExecutable::clearCode): + (JSC::ProgramExecutable::clearCode): + (JSC::FunctionExecutable::clearCode): All we need to do is delete our + CodeBlock -- that will delete all of its internal data structures. + + (JSC::FunctionExecutable::clearCodeIfNotCompiling): Factored out a helper + function to improve clarity. + + * runtime/Executable.h: + (JSC::ExecutableBase): Moved linked-list stuff + into base class so all executables can be in the list. + + (JSC::NativeExecutable::create): + (NativeExecutable): + (ScriptExecutable): + (JSC::ScriptExecutable::finishCreation): + (JSC::EvalExecutable::create): + (EvalExecutable): + (JSC::ProgramExecutable::create): + (ProgramExecutable): + (FunctionExecutable): + (JSC::FunctionExecutable::create): Don't use a finalizer -- the heap + will call us back to destroy our code block. + + (JSC::FunctionExecutable::discardCode): Renamed to clearCodeIfNotCompiling() + for clarity. + + (JSC::FunctionExecutable::isCompiling): New helper function, for clarity. + + (JSC::ScriptExecutable::clearCodeVirtual): New helper function, since + the heap needs to make polymorphic calls to clear code. + + * runtime/JSGlobalData.cpp: + (JSC::StackPreservingRecompiler::operator()): + * runtime/JSGlobalObject.cpp: + (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): Updated for + renames. + +2012-06-07 Filip Pizlo <fpizlo@apple.com> + + DFG should inline prototype chain accesses, and do the right things if the + specific function optimization is available + https://bugs.webkit.org/show_bug.cgi?id=88594 + + Reviewed by Gavin Barraclough. + + Looks like a 3% win on V8. + + * bytecode/CodeBlock.h: + (JSC::Structure::prototypeForLookup): + (JSC): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + (JSC): + (JSC::GetByIdStatus::computeForChain): + (JSC::GetByIdStatus::computeFor): + * bytecode/GetByIdStatus.h: + (JSC::GetByIdStatus::GetByIdStatus): + (JSC::GetByIdStatus::isSimple): + (JSC::GetByIdStatus::chain): + (JSC::GetByIdStatus::specificValue): + (GetByIdStatus): + * bytecode/StructureSet.h: + (StructureSet): + (JSC::StructureSet::singletonStructure): + * bytecode/StructureStubInfo.h: + (JSC::StructureStubInfo::initGetByIdProto): + (JSC::StructureStubInfo::initGetByIdChain): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleGetById): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCacheGetByID): + * runtime/JSGlobalObject.h: + (JSC::Structure::prototypeForLookup): + (JSC): + * runtime/Structure.h: + (Structure): + +2012-06-07 Gavin Barraclough <barraclough@apple.com> + + Remove JSObject::m_inheritorID + https://bugs.webkit.org/show_bug.cgi?id=88378 + + Reviewed by Geoff Garen. + + This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), + and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). + Instead use a private named value in the object's property storage. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + - No need m_inheritorID to initialize! + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + - No need m_inheritorID to initialize! + * llint/LowLevelInterpreter.asm: + - No need m_inheritorID to initialize! + * runtime/JSGlobalData.h: + (JSGlobalData): + - Added private name 'm_inheritorIDKey'. + * runtime/JSGlobalThis.cpp: + (JSC::JSGlobalThis::setUnwrappedObject): + - resetInheritorID is now passed a JSGlobalData&. + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + - No m_inheritorID to be marked. + (JSC::JSObject::createInheritorID): + - Store the newly created inheritorID in the property map. + * runtime/JSObject.h: + (JSC::JSObject::resetInheritorID): + - Remove the inheritorID from property storage. + (JSC::JSObject::inheritorID): + - Read the inheritorID from property storage. + +2012-06-07 Gavin Barraclough <barraclough@apple.com> + + Math.pow on iOS does not support denormal numbers. + https://bugs.webkit.org/show_bug.cgi?id=88592 + + Reviewed by Filip Pizlo. + + Import an implementation from fdlibm, detect cases where it is safe to use the system + implementation & where we should fall back to fdlibm. + + * runtime/MathObject.cpp: + (JSC::isDenormal): + (JSC::isEdgeCase): + (JSC::mathPow): + - On iOS, detect cases where denormal support may be required & use fdlibm in these cases. + (JSC::mathProtoFuncPow): + - Changed to use mathPow. + (JSC::fdlibmScalbn): + (JSC::fdlibmPow): + - These functions imported from fdlibm; original style retained to ease future merging. + +2012-06-07 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for !ENABLE(JIT) after r119441. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::privateExecute): + +2012-06-07 Andy Wingo <wingo@igalia.com> + + Unreviewed build fix after r119593. + + * llint/LLIntOfflineAsmConfig.h (OFFLINE_ASM_GLOBAL_LABEL): Fix + uses of "name" to be "label", the macro's parameter. Otherwise we + serialize mentions of the literal symbol "name" into the objcode. + Causes a build error using GNU ld (not gold). + +2012-06-06 Ryosuke Niwa <rniwa@webkit.org> + + Chromium build fix attempt. Why do we need to list these files in gyp!? + + * JavaScriptCore.gypi: + +2012-06-06 Filip Pizlo <fpizlo@apple.com> + + PredictedType should be called SpeculatedType + https://bugs.webkit.org/show_bug.cgi?id=88477 + + Rubber stamped by Gavin Barraclough. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::shouldOptimizeNow): + (JSC::CodeBlock::dumpValueProfiles): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::prediction): + * bytecode/LazyOperandValueProfile.h: + (LazyOperandValueProfileParser): + * bytecode/PredictedType.cpp: Removed. + * bytecode/PredictedType.h: Removed. + * bytecode/SpeculatedType.cpp: Copied from Source/JavaScriptCore/bytecode/PredictedType.cpp. + (JSC::speculationToString): + (JSC::speculationToAbbreviatedString): + (JSC::speculationFromClassInfo): + (JSC::speculationFromStructure): + (JSC::speculationFromCell): + (JSC::speculationFromValue): + * bytecode/SpeculatedType.h: Copied from Source/JavaScriptCore/bytecode/PredictedType.h. + (JSC): + (JSC::isAnySpeculation): + (JSC::isCellSpeculation): + (JSC::isObjectSpeculation): + (JSC::isFinalObjectSpeculation): + (JSC::isFinalObjectOrOtherSpeculation): + (JSC::isFixedIndexedStorageObjectSpeculation): + (JSC::isStringSpeculation): + (JSC::isArraySpeculation): + (JSC::isFunctionSpeculation): + (JSC::isInt8ArraySpeculation): + (JSC::isInt16ArraySpeculation): + (JSC::isInt32ArraySpeculation): + (JSC::isUint8ArraySpeculation): + (JSC::isUint8ClampedArraySpeculation): + (JSC::isUint16ArraySpeculation): + (JSC::isUint32ArraySpeculation): + (JSC::isFloat32ArraySpeculation): + (JSC::isFloat64ArraySpeculation): + (JSC::isArgumentsSpeculation): + (JSC::isActionableIntMutableArraySpeculation): + (JSC::isActionableFloatMutableArraySpeculation): + (JSC::isActionableTypedMutableArraySpeculation): + (JSC::isActionableMutableArraySpeculation): + (JSC::isActionableArraySpeculation): + (JSC::isArrayOrOtherSpeculation): + (JSC::isMyArgumentsSpeculation): + (JSC::isInt32Speculation): + (JSC::isDoubleRealSpeculation): + (JSC::isDoubleSpeculation): + (JSC::isNumberSpeculation): + (JSC::isBooleanSpeculation): + (JSC::isOtherSpeculation): + (JSC::isEmptySpeculation): + (JSC::mergeSpeculations): + (JSC::mergeSpeculation): + * bytecode/StructureSet.h: + (JSC::StructureSet::speculationFromStructures): + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::ValueProfileBase): + (JSC::ValueProfileBase::dump): + (JSC::ValueProfileBase::computeUpdatedPrediction): + (ValueProfileBase): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeStateAtTail): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::speculateInt32Unary): + (JSC::DFG::AbstractState::speculateNumberUnary): + (JSC::DFG::AbstractState::speculateBooleanUnary): + (JSC::DFG::AbstractState::speculateInt32Binary): + (JSC::DFG::AbstractState::speculateNumberBinary): + * dfg/DFGAbstractValue.h: + (JSC::DFG::StructureAbstractValue::filter): + (JSC::DFG::StructureAbstractValue::speculationFromStructures): + (JSC::DFG::AbstractValue::AbstractValue): + (JSC::DFG::AbstractValue::clear): + (JSC::DFG::AbstractValue::isClear): + (JSC::DFG::AbstractValue::makeTop): + (JSC::DFG::AbstractValue::clobberStructures): + (JSC::DFG::AbstractValue::isTop): + (JSC::DFG::AbstractValue::set): + (JSC::DFG::AbstractValue::merge): + (JSC::DFG::AbstractValue::filter): + (JSC::DFG::AbstractValue::validateIgnoringValue): + (JSC::DFG::AbstractValue::validate): + (JSC::DFG::AbstractValue::checkConsistency): + (JSC::DFG::AbstractValue::dump): + (AbstractValue): + * dfg/DFGArgumentPosition.h: + (JSC::DFG::ArgumentPosition::ArgumentPosition): + (JSC::DFG::ArgumentPosition::mergeArgumentAwareness): + (JSC::DFG::ArgumentPosition::prediction): + (ArgumentPosition): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::addCall): + (JSC::DFG::ByteCodeParser::getSpeculationWithoutOSRExit): + (JSC::DFG::ByteCodeParser::getSpeculation): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::fixVariableAccessSpeculations): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixDoubleEdge): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::nameOfVariableAccessData): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::predictArgumentTypes): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::getJSConstantSpeculation): + (JSC::DFG::Graph::isPredictedNumerical): + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::getSpeculation): + * dfg/DFGNode.h: + (JSC::DFG::Node::Node): + (JSC::DFG::Node::getHeapPrediction): + (JSC::DFG::Node::predictHeap): + (JSC::DFG::Node::prediction): + (JSC::DFG::Node::predict): + (JSC::DFG::Node::shouldSpeculateInteger): + (JSC::DFG::Node::shouldSpeculateDouble): + (JSC::DFG::Node::shouldSpeculateNumber): + (JSC::DFG::Node::shouldSpeculateBoolean): + (JSC::DFG::Node::shouldSpeculateFinalObject): + (JSC::DFG::Node::shouldSpeculateFinalObjectOrOther): + (JSC::DFG::Node::shouldSpeculateArray): + (JSC::DFG::Node::shouldSpeculateArguments): + (JSC::DFG::Node::shouldSpeculateInt8Array): + (JSC::DFG::Node::shouldSpeculateInt16Array): + (JSC::DFG::Node::shouldSpeculateInt32Array): + (JSC::DFG::Node::shouldSpeculateUint8Array): + (JSC::DFG::Node::shouldSpeculateUint8ClampedArray): + (JSC::DFG::Node::shouldSpeculateUint16Array): + (JSC::DFG::Node::shouldSpeculateUint32Array): + (JSC::DFG::Node::shouldSpeculateFloat32Array): + (JSC::DFG::Node::shouldSpeculateFloat64Array): + (JSC::DFG::Node::shouldSpeculateArrayOrOther): + (JSC::DFG::Node::shouldSpeculateObject): + (JSC::DFG::Node::shouldSpeculateCell): + (Node): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::setPrediction): + (JSC::DFG::PredictionPropagationPhase::mergePrediction): + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::fillStorage): + (JSC::DFG::SpeculativeJIT::writeBarrier): + (JSC::DFG::GPRTemporary::GPRTemporary): + (JSC::DFG::FPRTemporary::FPRTemporary): + (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + (JSC::DFG::SpeculativeJIT::compileGetTypedArrayLength): + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + (JSC::DFG::SpeculativeJIT::compileAdd): + (JSC::DFG::SpeculativeJIT::compileArithSub): + (JSC::DFG::SpeculativeJIT::compileArithNegate): + (JSC::DFG::SpeculativeJIT::compileArithMul): + (JSC::DFG::SpeculativeJIT::compileArithMod): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): + (JSC::DFG::SpeculativeJIT::compileRegExpExec): + * dfg/DFGSpeculativeJIT.h: + (DFG): + (JSC::DFG::ValueSource::forSpeculation): + (SpeculativeJIT): + (GPRTemporary): + (FPRTemporary): + (JSC::DFG::SpecDoubleOperand::SpecDoubleOperand): + (JSC::DFG::SpecDoubleOperand::~SpecDoubleOperand): + (JSC::DFG::SpecDoubleOperand::fpr): + (JSC::DFG::SpecCellOperand::SpecCellOperand): + (JSC::DFG::SpecCellOperand::~SpecCellOperand): + (JSC::DFG::SpecCellOperand::gpr): + (JSC::DFG::SpecBooleanOperand::SpecBooleanOperand): + (JSC::DFG::SpecBooleanOperand::~SpecBooleanOperand): + (JSC::DFG::SpecBooleanOperand::gpr): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpecDouble): + (JSC::DFG::SpeculativeJIT::fillSpecCell): + (JSC::DFG::SpeculativeJIT::fillSpecBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileDoubleCompare): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpecDouble): + (JSC::DFG::SpeculativeJIT::fillSpecCell): + (JSC::DFG::SpeculativeJIT::fillSpecBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileDoubleCompare): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::predict): + (JSC::DFG::VariableAccessData::nonUnifiedPrediction): + (JSC::DFG::VariableAccessData::prediction): + (JSC::DFG::VariableAccessData::argumentAwarePrediction): + (JSC::DFG::VariableAccessData::mergeArgumentAwarePrediction): + (JSC::DFG::VariableAccessData::shouldUseDoubleFormatAccordingToVote): + (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat): + (VariableAccessData): + +2012-06-06 Filip Pizlo <fpizlo@apple.com> + + Global object variable accesses should not require an extra load + https://bugs.webkit.org/show_bug.cgi?id=88385 + + Reviewed by Gavin Barraclough and Geoffrey Garen. + + Previously, if you wanted to access a global variable, you'd first have + to load the register array from the appropriate global object and then + either load or store at an offset to the register array. This is because + JSGlobalObject inherited from JSVariableObject, and JSVariableObject is + designed with the pessimistic assumption that its register array may + point into the call stack. This is never the case for global objects. + Hence, even though the global object may add more registers at any time, + it does not need to store them in a contiguous array. It can use a + SegmentedVector or similar. + + This patch refactors global objects and variable objects as follows: + + - The functionality to track variables in an indexable array using a + SymbolTable to map names to indices is moved into JSSymbolTableObject, + which is now a supertype of JSVariableObject. JSVariableObject is now + just a holder for a registers array and implements the registerAt() + method that is left abstract in JSSymbolTableObject. Because all users + of JSVariableObject know whether they are a JSStaticScopeObject, + JSActivation, or JSGlobalObject, this "abstract" method is not virtual; + instead the utility methods that would call registerAt() are now + template functions that require you to know statically what subtype of + JSSymbolTableObject you're using (JSVariableObject or something else), + so that registerAt() can be statically bound. + + - A new class is added called JSSegmentedVariableObject, which only + differs from JSVariableObject in how it allocates registers. It uses a + SegmentedVector instead of manually managing a pointer to a contiguous + slab of registers. This changes the interface somewhat; for example + with JSVariableObject if you wanted to add a register you had to do + it yourself since the JSVariableObject didn't know how the registers + array ought to be allocated. With JSSegmentedVariableObject you can + just call addRegisters(). JSSegmentedVariableObject preserves the + invariant that once you get a pointer into a register, that pointer + will continue to be valid so long as the JSSegmentedVariableObject is + alive. This allows the JITs and interpreters to skip the extra load. + + - JSGlobalObject now inherits from JSSegmentedVariableObject. For now + (and possibly forever) it is the only subtype of this new class. + + - The bytecode format is changed so that get_global_var and + put_global_var have a pointer to the register directly rather than + having an index. A convenience method is provided in + JSSegmentedVariableObject to get the index given a a pointer, which is + used for assertions and debug dumps. + + This appears to be a 1% across the board win. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Instruction.h: + (Instruction): + (JSC::Instruction::Instruction): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::registerPointer): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::retrieveLastUnaryOp): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (ResolveResult): + (BytecodeGenerator): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarLoadElimination): + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::globalObjectFor): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasVarNumber): + (Node): + (JSC::DFG::Node::hasRegisterPointer): + (JSC::DFG::Node::registerPointer): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * heap/Heap.h: + (Heap): + (JSC::Heap::isWriteBarrierEnabled): + (JSC): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + (JSC::Interpreter::privateExecute): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSGlobalObject.cpp: + (JSC): + (JSC::JSGlobalObject::put): + (JSC::JSGlobalObject::putDirectVirtual): + (JSC::JSGlobalObject::defineOwnProperty): + (JSC::JSGlobalObject::visitChildren): + (JSC::JSGlobalObject::addStaticGlobals): + (JSC::JSGlobalObject::getOwnPropertySlot): + (JSC::JSGlobalObject::getOwnPropertyDescriptor): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::JSGlobalObject): + (JSC): + (JSC::JSGlobalObject::hasOwnPropertyForWrite): + * runtime/JSSegmentedVariableObject.cpp: Added. + (JSC): + (JSC::JSSegmentedVariableObject::findRegisterIndex): + (JSC::JSSegmentedVariableObject::addRegisters): + (JSC::JSSegmentedVariableObject::visitChildren): + * runtime/JSSegmentedVariableObject.h: Added. + (JSC): + (JSSegmentedVariableObject): + (JSC::JSSegmentedVariableObject::registerAt): + (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): + (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): + (JSC::JSSegmentedVariableObject::finishCreation): + * runtime/JSStaticScopeObject.cpp: + (JSC::JSStaticScopeObject::put): + (JSC::JSStaticScopeObject::putDirectVirtual): + (JSC::JSStaticScopeObject::getOwnPropertySlot): + * runtime/JSSymbolTableObject.cpp: Added. + (JSC): + (JSC::JSSymbolTableObject::destroy): + (JSC::JSSymbolTableObject::deleteProperty): + (JSC::JSSymbolTableObject::getOwnPropertyNames): + (JSC::JSSymbolTableObject::putDirectVirtual): + (JSC::JSSymbolTableObject::isDynamicScope): + * runtime/JSSymbolTableObject.h: Added. + (JSC): + (JSSymbolTableObject): + (JSC::JSSymbolTableObject::symbolTable): + (JSC::JSSymbolTableObject::JSSymbolTableObject): + (JSC::JSSymbolTableObject::finishCreation): + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/JSVariableObject.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + (JSC::JSVariableObject::JSVariableObject): + (JSC::JSVariableObject::finishCreation): + (JSC): + * runtime/WriteBarrier.h: + +2012-06-06 Filip Pizlo <fpizlo@apple.com> + + DFG arguments access slow path should not crash if the arguments haven't been created + https://bugs.webkit.org/show_bug.cgi?id=88471 + + Reviewed by Gavin Barraclough. + + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-06-06 Michael Saboff <msaboff@apple.com> + + ENH: Add Logging to GC Marking Phase + https://bugs.webkit.org/show_bug.cgi?id=88364 + + Reviewed by Filip Pizlo. + + Log GC marking to stderr or a file. The logging in controlled + with the define ENABLE_OBJECT_MARK_LOGGING in wtf/Platform.h. + If DATA_LOG_TO_FILE in wtf/DataLog.cpp is set to 1, output is + logged to a file otherwise it is logged to stderr. + + When logging is enabled, the GC is built single threaded since the + log output from the various threads isn't buffered and output in a + thread safe manner. + + * heap/Heap.cpp: + (JSC::Heap::markRoots): + * heap/MarkStack.cpp: + (JSC::MarkStackThreadSharedData::resetChildren): + (JSC::MarkStackThreadSharedData::childVisitCount): + (JSC::MarkStackThreadSharedData::markingThreadMain): + (JSC::MarkStackThreadSharedData::markingThreadStartFunc): + (JSC::MarkStackThreadSharedData::MarkStackThreadSharedData): + (JSC::MarkStackThreadSharedData::reset): + * heap/MarkStack.h: + (MarkStackThreadSharedData): + (MarkStack): + (JSC::MarkStack::sharedData): + (JSC::MarkStack::resetChildCount): + (JSC::MarkStack::childCount): + (JSC::MarkStack::incrementChildCount): + * runtime/JSArray.cpp: + (JSC::JSArray::visitChildren): + * runtime/JSCell.cpp: + (JSC::JSCell::className): + * runtime/JSCell.h: + (JSCell): + (JSC::JSCell::visitChildren): + * runtime/JSString.cpp: + (JSC::JSString::visitChildren): + * runtime/JSString.h: + (JSString): + * runtime/Structure.h: + (JSC::MarkStack::internalAppend): + +2012-06-06 Gavin Barraclough <barraclough@apple.com> + + Assigning to a static property should not change iteration order + https://bugs.webkit.org/show_bug.cgi?id=88401 + + Reviewed by Geoff Garen. + + A specific iteration order is not defined by the spec, but test-262 somewhat tenuously + requires that it is at least stable, e.g. ch10/10.4/10.4.2/S10.4.2_A1.1_T1.js + + Whilst it is not clear that this behavior really arises from the specification, it + would seem like common sense to conform to this. + + The problem here is that we allow properties in the structure to shadow those in the + static table, and we iterate the properties in the structure first - which means that + as values of existing properties are modified, their iteration order changes too. + + The easy fix is to iterate the properties from the static table first. This has a + further benefit, since it will mean that user added properties will come after those + present in the static table (respected the expected insertion-order). + + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertyNames): + - Iterate static properties first. + +2012-06-06 Andy Wingo <wingo@igalia.com> + + Ensure consistent order of evaluation in LLInt slow paths + https://bugs.webkit.org/show_bug.cgi?id=88409 + + Reviewed by Geoffrey Garen. + + * llint/LLIntSlowPaths.cpp: + (slow_path_mul) + (slow_path_sub) + (slow_path_div) + (slow_path_mod) + (slow_path_lshift) + (slow_path_rshift) + (slow_path_urshift) + (slow_path_bitand) + (slow_path_bitor) + (slow_path_bitxor): Avoid calling toNumber, toInt32, or toUInt32 + multiple times without intervening sequence points. Fixes + fast/js/exception-sequencing-binops.html with GCC 4.7 on x86-64 + Linux, which reordered evaluation of the arguments to fmod. + +2012-06-06 Andy Wingo <wingo@igalia.com> + + [GTK] Enable the LLInt + https://bugs.webkit.org/show_bug.cgi?id=88315 + + Reviewed by Filip Pizlo. + + * GNUmakefile.am: Add rules to generate LLIntDesiredOffsets.h and + LLIntAssembly.h. + * GNUmakefile.list.am: Add offlineasm and llint files to the + dist. Add LLInt source files to the build. + * llint/LowLevelInterpreter.asm (crash): Generate a store of + 0xbbadbeef to a register, not to a constant. Otherwise, gas was + failing to assemble result. + * offlineasm/asm.rb (labelReference): Generate a + SYMBOL_STRING_RELOCATION instead of a SYMBOL_STRING, so that we go + through the PLT on ELF systems. + +2012-06-06 Andy Wingo <wingo@igalia.com> + + REGRESSION (r106478): None of the Paper.js JavaScript examples work + https://bugs.webkit.org/show_bug.cgi?id=87158 + + Reviewed by Michael Saboff. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolve): If we have to bail out to + dynamicResolve(), only skip static scopes from the head of the + scope chain. Before, we were also skipping activations with + direct eval as well, which was incorrect. + +2012-06-06 Dan Bernstein <mitz@apple.com> + + Reverted r119567, the fix for <http://webkit.org/b/88378>, because it broke the 32-bit build. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + * llint/LowLevelInterpreter.asm: + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalThis.cpp: + (JSC::JSGlobalThis::setUnwrappedObject): + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + (JSC::JSObject::createInheritorID): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::resetInheritorID): + (JSC): + (JSC::JSObject::offsetOfInheritorID): + (JSC::JSObject::inheritorID): + +2012-06-05 Yuqiang Xian <yuqiang.xian@intel.com> + + Improve Math.round and Math.floor intrinsic + https://bugs.webkit.org/show_bug.cgi?id=88314 + + Reviewed by Filip Pizlo. + + Currently we call a native function from the JIT code to complete the + "round" and "floor" operations. We could inline some fast paths + especially for those positive values on the platforms where floating + point truncation is supported. + This brings 3% gain on Kraken, especially 32% on audio-oscillator, + and slight win on SunSpider, measured on IA32. + + * jit/ThunkGenerators.cpp: + (JSC::floorThunkGenerator): + (JSC): + (JSC::roundThunkGenerator): + +2012-06-05 Gavin Barraclough <barraclough@apple.com> + + Remove JSObject::m_inheritorID + https://bugs.webkit.org/show_bug.cgi?id=88378 + + Reviewed by Geoff Garen. + + This is rarely used, and not performance critical (the commonly accessed copy is cached on JSFunction), + and most objects don't need an inheritorID (this value is only used if the object is used as a prototype). + Instead use a private named value in the object's property storage. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + - No need m_inheritorID to initialize! + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + - No need m_inheritorID to initialize! + * llint/LowLevelInterpreter.asm: + - No need m_inheritorID to initialize! + * runtime/JSGlobalData.h: + (JSGlobalData): + - Added private name 'm_inheritorIDKey'. + * runtime/JSGlobalThis.cpp: + (JSC::JSGlobalThis::setUnwrappedObject): + - resetInheritorID is now passed a JSGlobalData&. + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + - No m_inheritorID to be marked. + (JSC::JSObject::createInheritorID): + - Store the newly created inheritorID in the property map. + * runtime/JSObject.h: + (JSC::JSObject::resetInheritorID): + - Remove the inheritorID from property storage. + (JSC::JSObject::inheritorID): + - Read the inheritorID from property storage. + +2012-06-05 Filip Pizlo <fpizlo@apple.com> + + DFG CFG simplification should not attempt to deref nodes inside of an unreachable subgraph + https://bugs.webkit.org/show_bug.cgi?id=88362 + + Reviewed by Gavin Barraclough. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::fixPhis): + (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): + +2012-06-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Entry into JSC should CRASH() if the Heap is busy + https://bugs.webkit.org/show_bug.cgi?id=88355 + + Reviewed by Geoffrey Garen. + + Interpreter::execute() returns jsNull() right now if we try to enter it while + the Heap is busy (e.g. with a collection), which is okay, but some code paths + that call Interpreter::execute() allocate objects before checking if the Heap + is busy. Attempting to execute JS code while the Heap is busy should not be + allowed and should be enforced by a release-mode CRASH() to prevent vague, + unhelpful backtraces later on if somebody makes a mistake. Normally, recursively + executing JS code is okay, e.g. for evals, but it should not occur during a + Heap allocation or collection because the Heap is not guaranteed to be in a + consistent state (especially during collections). We are protected from + executing JS on the same Heap concurrently on two separate threads because + they must each take a JSLock first. However, we are not protected from reentrant + execution of JS on the same thread because JSLock allows reentrancy. Therefore, + we should fail early if we detect an entrance into JS code while the Heap is busy. + + * heap/Heap.cpp: Changed Heap::collect so that it sets the m_operationInProgress field + at the beginning of collection and then unsets it at the end so that it is set at all + times throughout the duration of a collection rather than sporadically during various + phases. There is no reason to unset during a collection because our collector does + not currently support running additional JS between the phases of a collection. + (JSC::Heap::getConservativeRegisterRoots): + (JSC::Heap::markRoots): + (JSC::Heap::collect): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): Crash if the Heap is busy. + * runtime/Completion.cpp: Crash if the Heap is busy. We do it here before we call + Interpreter::execute() because we do some allocation prior to calling execute() which + could cause Heap corruption if, for example, that allocation caused a collection. + (JSC::evaluate): + +2012-06-05 Dongwoo Im <dw.im@samsung.com> + + Add 'isProtocolHandlerRegistered' and 'unregisterProtocolHandler'. + https://bugs.webkit.org/show_bug.cgi?id=73176 + + Reviewed by Adam Barth. + + Two more APIs are added in Custom Scheme Handler specification. + http://dev.w3.org/html5/spec/Overview.html#custom-handlers + One is 'isProtocolHandlerRegistered' to query whether the specific URL + is registered or not. + The other is 'unregisterProtocolHandler' to remove the registered URL. + + * Configurations/FeatureDefines.xcconfig: Add a macro 'ENABLE_CUSTOM_SCHEME_HANDLER'. + +2012-06-04 Filip Pizlo <fpizlo@apple.com> + + DFG CFG simplification should correct the variables at the head of the predecessor block + https://bugs.webkit.org/show_bug.cgi?id=88284 + + Reviewed by Geoffrey Garen. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-06-04 Geoffrey Garen <ggaren@apple.com> + + Unreviewed. + + Rolled out r119364 because it's still causing crashes (when running + v8-earley in release builds of DRT) + + This time for sure! + + * heap/Heap.cpp: + (JSC::Heap::collect): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::resetAllocator): + (JSC): + * heap/MarkedSpace.cpp: + (JSC::ResetAllocator::operator()): + (JSC): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::sweepWeakSets): + * heap/MarkedSpace.h: + (MarkedSpace): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::sweep): + * heap/WeakSet.cpp: + (JSC::WeakSet::sweep): + (JSC::WeakSet::tryFindAllocator): + * heap/WeakSet.h: + (JSC::WeakSet::shrink): + +2012-06-04 Filip Pizlo <fpizlo@apple.com> + + DFG arguments simplification should have rationalized handling of TearOffArguments + https://bugs.webkit.org/show_bug.cgi?id=88206 + + Reviewed by Geoffrey Garen. + + - Accesses to the unmodified arguments register ought to have the same effect on + alias/escape analysis of arguments as accesses to the mutable arguments register. + + - The existence of TearOffArguments should not get in the way of arguments aliasing. + + - TearOffArguments should be eliminated if CreateArguments is eliminated. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + +2012-06-04 Gavin Barraclough <barraclough@apple.com> + + Remove enabledProfilerReference + https://bugs.webkit.org/show_bug.cgi?id=88258 + + Reviewed by Michael Saboff. + + Make the enabled profiler a member of JSGlobalData, and switch code that accesses it to do so directly + via the JSGlobalData, rather than holding a Profiler** reference to it. Do not pass the Profiler** + reference to JIT code. This patch does not change the stack layout on entry into JIT code (passing an + unused void* instead), since this is an intrusive change better handled in a separate patch. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::privateExecute): + * jit/JITCode.h: + (JSC::JITCode::execute): + - Don't pass Profiler** to JIT code. + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_profile_will_call): + (JSC::JIT::emit_op_profile_did_call): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_profile_will_call): + (JSC::JIT::emit_op_profile_did_call): + * jit/JITStubs.cpp: + (JSC): + (JSC::ctiTrampoline): + (JSC::ctiVMThrowTrampoline): + (JSC::ctiOpThrowNotCaught): + (JSC::JITThunks::JITThunks): + (JSC::DEFINE_STUB_FUNCTION): + - For ARM_THUMB2, rename ENABLE_PROFILER_REFERENCE_OFFSET to FIRST_STACK_ARGUMENT (which is how it is being used). + - For MIPS, remove ENABLE_PROFILER_REFERENCE_OFFSET. + * jit/JITStubs.h: + (JITStackFrame): + (JSC): + - Renamed enabledProfilerReference to unusedX. + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * profiler/Profiler.cpp: + (JSC): + (JSC::Profiler::startProfiling): + (JSC::Profiler::stopProfiling): + * profiler/Profiler.h: + (Profiler): + - Removed s_sharedEnabledProfilerReference, enabledProfilerReference(). + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSC): + (JSC::JSGlobalData::enabledProfiler): + (JSGlobalData): + - Added m_enabledProfiler, enabledProfiler(). + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::~JSGlobalObject): + +2012-06-04 Filip Pizlo <fpizlo@apple.com> + + get_argument_by_val should be profiled everywhere + https://bugs.webkit.org/show_bug.cgi?id=88205 + + Reviewed by Geoffrey Garen. + + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + +2012-06-04 Filip Pizlo <fpizlo@apple.com> + + DFG arguments simplification takes unkindly to direct accesses to the arguments register + https://bugs.webkit.org/show_bug.cgi?id=88261 + + Reviewed by Geoffrey Garen. + + Fixed arguments simplification for direct accesses to the arguments register, which may + arise if CSE had not run. Fixed CSE so that it does run prior to arguments simplification, + by making it a full-fledged member of the fixpoint. Fixed other issues in arguments + simplification, like realizing that it needs to bail if there is a direct assignment to + the arguments register, and failing to turn CreateArguments into PhantomArguments. Also + fixed CSE's handling of store elimination of captured locals in the presence of a + GetMyArgumentByVal (or one of its friends), and fixed CSE to correctly fixup variables at + tail if the Flush it removes is the last operation on a local in a basic block. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::run): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + (CSEPhase): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + +2012-06-04 Anders Carlsson <andersca@apple.com> + + Fix a struct/class mismatch. + + * heap/Handle.h: + (Handle): + +2012-06-04 David Kilzer <ddkilzer@apple.com> + + BUILD FIX: FeatureDefines.xcconfig should match across projects + + * Configurations/FeatureDefines.xcconfig: + - Add missing ENABLE_LEGACY_CSS_VENDOR_PREFIXES. + +2012-06-02 Geoffrey Garen <ggaren@apple.com> + + Weak pointer finalization should be lazy + https://bugs.webkit.org/show_bug.cgi?id=87599 + + Reviewed by Sam Weinig. + + This time for sure! + + * heap/Heap.cpp: + (JSC::Heap::collect): Don't sweep eagerly -- we'll sweep lazily instead. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): Sweep our weak set before we sweep our other + destructors -- this is our last chance to run weak set finalizers before + we recycle our memory. + + * heap/MarkedBlock.h: + (JSC::MarkedBlock::resetAllocator): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::resetAllocators): + * heap/MarkedSpace.h: + (JSC::MarkedSpace::resetAllocators): Don't force allocator reset anymore. + It will happen automatically when a weak set is swept. It's simpler to + have only one canonical way for this to happen, and it wasn't buying + us anything to do it eagerly. + + * heap/WeakBlock.cpp: + (JSC::WeakBlock::sweep): Don't short-circuit a sweep unless we know + the sweep would be a no-op. If even one finalizer is pending, we need to + run it, since we won't get another chance. + + * heap/WeakSet.cpp: + (JSC::WeakSet::sweep): This loop can be simpler now that + WeakBlock::sweep() does what we mean. + + Reset our allocator after a sweep because this is the optimal time to + start trying to recycle old weak pointers. + + (JSC::WeakSet::tryFindAllocator): Don't sweep when searching for an + allocator because we've swept already, and forcing a new sweep would be + wasteful. + + * heap/WeakSet.h: + (JSC::WeakSet::shrink): Be sure to reset our allocator after a shrink + because the shrink may have removed the block the allocator was going to + allocate out of. + +2012-06-02 Filip Pizlo <fpizlo@apple.com> + + If the DFG bytecode parser detects that op_method_check has gone polymorphic, it + shouldn't revert all the way to GetById/GetByIdFlush + https://bugs.webkit.org/show_bug.cgi?id=88176 + + Reviewed by Geoffrey Garen. + + Refactored the code so that the op_method_check case of the parser gracefully falls + through to all of the goodness of the normal op_get_by_id case. + + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleGetById): + (DFG): + (JSC::DFG::ByteCodeParser::parseBlock): + +2012-06-02 Filip Pizlo <fpizlo@apple.com> + + DFG CSE should be able to eliminate unnecessary flushes of arguments and captured variables + https://bugs.webkit.org/show_bug.cgi?id=87929 + + Reviewed by Geoffrey Garen. + + Slight speed-up on V8. Big win (up to 50%) on programs that inline very small functions. + + This required a bunch of changes: + + - The obvious change is making CSE essentially ignore whether or not the set of + operations between the Flush and the SetLocal can exit, and instead focus on whether or + not that set of operations can clobber the world or access local variables. This code + is now refactored to return a set of flags indicating any of these events, and the CSE + decides what to do based on those flags. If the set of operations is non-clobbering + and non-accessing, then the Flush is turned into a Phantom on the child of the + SetLocal. This expands the liveness of the relevant variable but virtually guarantees + that it will be register allocated and not flushed to the stack. So, yeah, this patch + is a lot of work to save a few stores to the stack. + + - Previously, CheckArgumentsNotCreated was optimized "lazily" in that you only knew if + it was a no-op if you were holding onto a CFA abstract state. But this would make the + CSE act pessimistically, since it doesn't use the CFA. Hence, this patch changes the + constant folding phase into something more broad; it now fixes up + CheckArgumentsNotCreated nodes by turning them into phantoms if it knows that they are + no-ops. + + - Arguments simplification was previously relying on this very strange PhantomArguments + node, which had two different meanings: for normal execution it meant the empty value + but for OSR exit it meant that the arguments should be reified. This produces problems + when set SetLocals to the captured arguments registers are CSE'd away, since we'd be + triggering reification of arguments without having initialized the arguments registers + to empty. The cleanest solution was to fix PhantomArguments to have one meaning: + namely, arguments reification on OSR exit. Hence, this patch changes arguments + simplification to change SetLocal of CreateArguments on the arguments registers to be + a SetLocal of Empty. + + - Argument value recoveries were previously derived from the value source of the + arguments at the InlineStart. But that relies on all SetLocals to arguments having + been flushed. It's possible that we could have elided the SetLocal to the arguments + at the callsite because there were subsequent SetLocals to the arguments inside of the + callee, in which case the InlineStart would get the wrong information. Hence, this + patch changes argument value recovery computation to operate over the ArgumentPositions + directly. + + - But that doesn't actually work, because previously, there was no way to link an + InlineStart back to the corresponding ArgumentPositions, at least not without some + ugliness. So this patch instates the rule that the m_argumentPositions vector consists + of disjoint subsequences such that each subsequence corresponds to an inline callsite + and can be identified by its first index, and within each subsequence are the + ArgumentPositions of all of the arguments ordered by argument index. This required + flipping the order in which ArgumentPositions are added to the vector, and giving + InlineStart an operand that indicates the start of that inline callsite's + ArgumentPosition subsequence. + + - This patch also revealed a nasty bug in the reification of arguments in inline call + frames on OSR exit. Since the reification was happening after the values of virtual + registers were recovered, the value recoveries of the inline arguments were wrong. + Hence using operationCreateInlinedArguments is wrong. For example a value recovery + might say that you have to box a double, but if we had already boxed it then boxing + it a second time will result in garbage. The specific case of this bug was this patch + uncovered was that now it is possible for an inline call frame to not have any valid + value recoveries for any inline arguments, if the optimization elides all argument + flushes, while at the same time optimizing away arguments creation. Then OSR exit + would try to recover the arguments using the inline call frame, which had bogus + information, and humorous crashes would ensue. This patch fixes this issue by moving + arguments reification to after call frame reification, so that arguments reification + can always use operationCreateArguments instead of operationCreateInlinedArguments. + + - This patch may turn a Flush into a Phantom. That's kind of the whole point. But that + broke forward speculation checks, which knew to look for a Flush prior to a SetLocal + but didn't know that there could alternatively be a Phantom in place of the Flush. + This patch fixes that by augmenting the forward speculation check logic. + + - Finally, in the process of having fun with all of the above, I realized that my DFG + validation was not actually running on every phase like I had originally designed it + to. In fact it was only running just after bytecode parsing. I initially tried to + make it run in every phase but found that this causes some tests to timeout + (specifically the evil fuzzing ones), so I decided on a compromise where: (i) in + release mode validation never runs, (ii) in debug mode validation will run just + after parsing and just before the backend, and (iii) it's possible with a simple + switch to enable validation to run on every phase. + + Luckily all of the above issues were already covered by the 77 or so DFG-specific + layout tests. Hence, this patch does not introduce any new tests despite being so + meaty. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentPosition.h: + (JSC::DFG::ArgumentPosition::prediction): + (JSC::DFG::ArgumentPosition::doubleFormatState): + (JSC::DFG::ArgumentPosition::shouldUseDoubleFormat): + (ArgumentPosition): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::SetLocalStoreEliminationResult::SetLocalStoreEliminationResult): + (SetLocalStoreEliminationResult): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.h: + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::hasArgumentPositionStart): + (JSC::DFG::Node::argumentPositionStart): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGPhase.cpp: + (DFG): + * dfg/DFGPhase.h: + (Phase): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-06-02 Geoffrey Garen <ggaren@apple.com> + + DOM string cache should hash pointers, not characters + https://bugs.webkit.org/show_bug.cgi?id=88175 + + Reviewed by Phil Pizlo and Sam Weinig. + + * heap/Weak.h: + (JSC::weakAdd): + (JSC::weakRemove): Made these function templates slightly more generic + to accommodate new client types. + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should know that PutByVal can clobber the world + https://bugs.webkit.org/show_bug.cgi?id=88155 + + Reviewed by Gavin Barraclough. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should mark basic blocks as having constants if local accesses yield constants + https://bugs.webkit.org/show_bug.cgi?id=88153 + + Reviewed by Gavin Barraclough. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG arguments simplification phase uses a node.codeOrigin after appending a node + https://bugs.webkit.org/show_bug.cgi?id=88151 + + Reviewed by Geoffrey Garen. + + The right thing to do is to save the CodeOrigin before appending to the graph. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG should not emit unnecessary speculation checks when performing an int32 to double conversion on + a value that is proved to be a number, predicted to be an int32, but not proved to be an int32 + https://bugs.webkit.org/show_bug.cgi?id=88146 + + Reviewed by Gavin Barraclough. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG constant folding search for the last local access skips the immediately previous local access + https://bugs.webkit.org/show_bug.cgi?id=88141 + + Reviewed by Michael Saboff. + + If you use a loop in the style of: + + for (i = start; i--;) + + then you need to remember that the first value of 'i' that the loop body will see is 'start - 1'. + Hence the following is probably wrong: + + for (i = start - 1; i--;) + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + +2012-06-01 Filip Pizlo <fpizlo@apple.com> + + DFG constant folding should be OK with GetLocal of captured variables having a constant + https://bugs.webkit.org/show_bug.cgi?id=88137 + + Reviewed by Gavin Barraclough. + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + +2012-05-31 Mark Hahnenberg <mhahnenberg@apple.com> + + JSGlobalObject does not mark m_privateNameStructure + https://bugs.webkit.org/show_bug.cgi?id=88023 + + Rubber stamped by Gavin Barraclough. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::visitChildren): We need to mark this so it doesn't get + inadvertently garbage collected. + +2012-05-31 Erik Arvidsson <arv@chromium.org> + + Make DOM Exceptions Errors + https://bugs.webkit.org/show_bug.cgi?id=85078 + + Reviewed by Oliver Hunt. + + WebIDL mandates that exceptions should have Error.prototype on its prototype chain. + + For JSC we have access to the Error.prototype from the binding code. + + For V8 we set a field in the WrapperTypeInfo and when the constructor function is created we + set the prototype as needed. + + Updated test: fast/dom/DOMException/prototype-object.html + + * JavaScriptCore.xcodeproj/project.pbxproj: + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + * runtime/JSGlobalObject.h: + (JSC): + (JSGlobalObject): + (JSC::JSGlobalObject::errorPrototype): + +2012-05-31 Andy Wingo <wingo@igalia.com> + + Fix reference to unset variable in debug mode + https://bugs.webkit.org/show_bug.cgi?id=87981 + + Reviewed by Geoffrey Garen. + + * runtime/JSONObject.cpp (Stringifier::Holder::Holder): + Initialize m_size in debug mode, as we check it later in an assert. + +2012-05-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Heap should sweep incrementally + https://bugs.webkit.org/show_bug.cgi?id=85429 + + We shouldn't have to wait for the opportunistic GC timer to fire in order + to call object destructors. Instead, we should incrementally sweep some + subset of the blocks requiring sweeping periodically. We tie this sweeping + to a timer rather than to collections because we want to reclaim this memory + even if we stop allocating. This way, our memory usage scales smoothly with + actual use, regardless of whether we've recently done an opportunistic GC or not. + + Reviewed by Geoffrey Garen. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC::Heap::collect): We no longer sweep during a full sweep. We only shrink now, + which we will switch over to being done during incremental sweeping too as soon as + all finalizers can be run lazily (and, by extension, incrementally). + (JSC::Heap::sweeper): + (JSC): + * heap/Heap.h: + (JSC): + (Heap): + * heap/IncrementalSweeper.cpp: Added. + (JSC): + (JSC::IncrementalSweeper::timerDidFire): The IncrementalSweeper works very similarly to + GCActivityCallback. It is tied to a run-loop based timer that fires periodically based + on how long the previous sweep increment took to run. The IncrementalSweeper doesn't do + anything if the platform doesn't support CoreFoundation. + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::~IncrementalSweeper): + (JSC::IncrementalSweeper::create): + (JSC::IncrementalSweeper::scheduleTimer): + (JSC::IncrementalSweeper::cancelTimer): + (JSC::IncrementalSweeper::doSweep): Iterates over the snapshot of the MarkedSpace taken + during the last collection, checking to see which blocks need sweeping. If it successfully + gets to the end of the blocks that need sweeping then it cancels the timer. + (JSC::IncrementalSweeper::startSweeping): We take a snapshot of the Heap and store it in + a Vector that the incremental sweep will iterate over. We also reset our index into this Vector. + * heap/IncrementalSweeper.h: Added. + (JSC): + (IncrementalSweeper): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::needsSweeping): If a block is in the Marked state it needs sweeping + to be usable and to run any destructors that need to be run. + +2012-05-30 Patrick Gansterer <paroga@webkit.org> + + [WINCE] Fix JSString after r115516. + https://bugs.webkit.org/show_bug.cgi?id=87892 + + Reviewed by Geoffrey Garen. + + r115516 splitted JSString into two classes, with addition nested classes. + Add a workaround for the WinCE compiler since it can't resolve the friend class + declerations corretly and denies the access to protected members of JSString. + + * runtime/JSString.h: + (JSC::JSRopeString::RopeBuilder::append): + (JSC::JSRopeString::append): + (JSRopeString): + +2012-05-30 Oliver Hunt <oliver@apple.com> + + Really provide error information with the inspector disabled + https://bugs.webkit.org/show_bug.cgi?id=87910 + + Reviewed by Filip Pizlo. + + Don't bother checking for anything other than pre-existing error info. + In the absence of complete line number information you'll only get the + line a function starts on, but at least it's something. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::throwException): + +2012-05-30 Filip Pizlo <fpizlo@apple.com> + + LLInt broken on x86-32 with JIT turned off + https://bugs.webkit.org/show_bug.cgi?id=87906 + + Reviewed by Geoffrey Garen. + + Fixed the code to not clobber registers that contain important things, like the call frame. + + * llint/LowLevelInterpreter32_64.asm: + +2012-05-30 Filip Pizlo <fpizlo@apple.com> + + ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it + https://bugs.webkit.org/show_bug.cgi?id=87887 + + Reviewed by Darin Adler. + + Better fix - we now never call SourceProvider::asID() if SourceProvider* is 0. + + * parser/Nodes.h: + (JSC::ScopeNode::sourceID): + * parser/SourceCode.h: + (JSC::SourceCode::providerID): + (SourceCode): + * parser/SourceProvider.h: + (SourceProvider): + (JSC::SourceProvider::asID): + * runtime/Executable.h: + (JSC::ScriptExecutable::sourceID): + +2012-05-30 Filip Pizlo <fpizlo@apple.com> + + ScriptDebugServer wants sourceIDs that are non-zero because that's what HashMaps want, so JSC should placate it + https://bugs.webkit.org/show_bug.cgi?id=87887 + + Reviewed by Geoffrey Garen. + + * parser/SourceProvider.h: + (JSC::SourceProvider::asID): + +2012-05-30 Oliver Hunt <oliver@apple.com> + + DFG does not correctly handle exceptions caught in the LLInt + https://bugs.webkit.org/show_bug.cgi?id=87885 + + Reviewed by Filip Pizlo. + + Make the DFG use genericThrow, rather than reimplementing a small portion of it. + Also make the LLInt slow paths validate that their PC is correct. + + * dfg/DFGOperations.cpp: + * llint/LLIntSlowPaths.cpp: + (LLInt): + +2012-05-29 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should infer types and values of captured variables + https://bugs.webkit.org/show_bug.cgi?id=87813 + + Reviewed by Gavin Barraclough. + + Slight speed-up in V8/earley-boyer (~1%). + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::argumentsAreCaptured): + (JSC::CodeBlock::argumentIsCaptured): + (CodeBlock): + * dfg/DFGAbstractState.cpp: + (DFG): + (JSC::DFG::AbstractState::beginBasicBlock): + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::clobberWorld): + (JSC::DFG::AbstractState::clobberStructures): + (JSC::DFG::AbstractState::mergeStateAtTail): + (JSC::DFG::AbstractState::merge): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::variables): + (AbstractState): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-30 Patrick Gansterer <paroga@webkit.org> + + Unreviewed. Build fix for !ENABLE(JIT) after r117823. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + +2012-05-30 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r118868. + http://trac.webkit.org/changeset/118868 + https://bugs.webkit.org/show_bug.cgi?id=87828 + + introduced ~20 crashes on Mac and Qt bots (Requested by pizlo_ + on #webkit). + + * heap/Heap.cpp: + (JSC::Heap::collect): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::sweepWeakSet): + (JSC): + * heap/MarkedSpace.cpp: + (JSC::SweepWeakSet::operator()): + (JSC): + (JSC::MarkedSpace::sweepWeakSets): + * heap/MarkedSpace.h: + (MarkedSpace): + +2012-05-29 Geoffrey Garen <ggaren@apple.com> + + Rolled back in r118646, now that + https://bugs.webkit.org/show_bug.cgi?id=87784 is fixed. + + http://trac.webkit.org/changeset/118646 + https://bugs.webkit.org/show_bug.cgi?id=87599 + + * heap/Heap.cpp: + (JSC::Heap::collect): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): + * heap/MarkedBlock.h: + (JSC): + * heap/MarkedSpace.cpp: + (JSC): + * heap/MarkedSpace.h: + (MarkedSpace): + +2012-05-29 Filip Pizlo <fpizlo@apple.com> + + DFG should keep captured variables alive until the (inline) return. + https://bugs.webkit.org/show_bug.cgi?id=87205 + + Reviewed by Gavin Barraclough. + + Changes the way we do flushing for captured variables and arguments. Instead of flushing + each SetLocal immediately, we flush at kill points. So a SetLocal will cause a Flush of + whatever was live in the variable previously, and a return will cause a Flush of all + captured variables and all arguments. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::setDirect): + (JSC::DFG::ByteCodeParser::set): + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::findArgumentPositionForArgument): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): + (JSC::DFG::ByteCodeParser::findArgumentPosition): + (JSC::DFG::ByteCodeParser::flush): + (JSC::DFG::ByteCodeParser::flushDirect): + (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + +2012-05-29 Geoffrey Garen <ggaren@apple.com> + + WeakGCMap should be lazy-finalization-safe + https://bugs.webkit.org/show_bug.cgi?id=87784 + + Reviewed by Darin Adler. + + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::get): Since this is a map of raw WeakImpl pointers, and + not Weak<T>, we need to verify manually that the WeakImpl is live before + we return its payload. + +2012-05-29 Mark Hahnenberg <mhahnenberg@apple.com> + + CopiedSpace::doneCopying could start another collection + https://bugs.webkit.org/show_bug.cgi?id=86538 + + Reviewed by Geoffrey Garen. + + It's possible that if we don't have anything at the head of to-space + after a collection and the BlockAllocator doesn't have any fresh blocks + to give us right now we could start another collection while still in + the middle of the first collection when we call CopiedSpace::addNewBlock(). + + One way to resolve this would be to have Heap::shouldCollect() check that + m_operationInProgress is NoOperation. This would prevent the path in + getFreshBlock() that starts the collection if we're already in the middle of one. + + I could not come up with a test case to reproduce this crash on ToT. + + * heap/Heap.h: + (JSC::Heap::shouldCollect): We shouldn't collect if we're already in the middle + of a collection, i.e. the current operation should be NoOperation. + +2012-05-29 David Barr <davidbarr@chromium.org> + + Introduce ENABLE_CSS_IMAGE_RESOLUTION compile flag + https://bugs.webkit.org/show_bug.cgi?id=87685 + + Reviewed by Eric Seidel. + + Add a configuration option for CSS image-resolution support, disabling it by default. + + * Configurations/FeatureDefines.xcconfig: + +2012-05-28 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r118646. + http://trac.webkit.org/changeset/118646 + https://bugs.webkit.org/show_bug.cgi?id=87691 + + broke V8 raytrace benchmark (Requested by pizlo_ on #webkit). + + * heap/Heap.cpp: + (JSC::Heap::collect): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::sweepWeakSet): + (JSC): + * heap/MarkedSpace.cpp: + (JSC::SweepWeakSet::operator()): + (JSC): + (JSC::MarkedSpace::sweepWeakSets): + * heap/MarkedSpace.h: + (MarkedSpace): + +2012-05-28 Filip Pizlo <fpizlo@apple.com> + + DFG should not generate code for code that the CFA proves to be unreachable + https://bugs.webkit.org/show_bug.cgi?id=87682 + + Reviewed by Sam Weinig. + + This also fixes a small performance bug where CFA was not marking blocks + as having constants (and hence not triggering constant folding) if the only + constants were on GetLocals. + + And fixing that bug revealed another bug: constant folding was assuming that + a GetLocal must be the first access to a local in a basic block. This isn't + true. The first access may be a Flush. This patch fixes that issue using the + safest approach possible, since we don't need to be clever for something that + only happens in one of our benchmarks. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::run): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::noticeOSREntry): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-28 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing header file. + +2012-05-27 Geoffrey Garen <ggaren@apple.com> + + Weak pointer finalization should be lazy + https://bugs.webkit.org/show_bug.cgi?id=87599 + + Reviewed by Darin Adler. + + * heap/Heap.cpp: + (JSC::Heap::collect): Don't force immediate finalization -- it will + happen lazily. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweep): Sweep a block's weak set when sweeping the + block. The weak set may not have been swept yet, and this is our last + chance to run weak finalizers before we recycle the memory they reference. + + * heap/MarkedBlock.h: + * heap/MarkedSpace.cpp: + (JSC::MarkedBlock::sweepWeakSets): + * heap/MarkedSpace.h: + (JSC::MarkedSpace::sweepWeakSets): Nixed sweepWeakSets because it's unused + now. + +2012-05-26 Geoffrey Garen <ggaren@apple.com> + + WebKit should be lazy-finalization-safe (esp. the DOM) v2 + https://bugs.webkit.org/show_bug.cgi?id=87581 + + Reviewed by Oliver Hunt. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::callDestructor): + * heap/WeakBlock.h: + * heap/WeakSetInlines.h: + (JSC::WeakBlock::finalize): Since we don't guarantee destruction order, + it's not valid to access GC pointers like the Structure pointer during + finalization. We NULL out the structure pointer in debug builds to try + to make this programming mistake more obvious. + + * API/JSCallbackConstructor.cpp: + (JSC::JSCallbackConstructor::destroy): + * API/JSCallbackObject.cpp: + (JSC::::destroy): + (JSC::JSCallbackObjectData::finalize): + * runtime/Arguments.cpp: + (JSC::Arguments::destroy): + * runtime/DateInstance.cpp: + (JSC::DateInstance::destroy): + * runtime/Error.cpp: + (JSC::StrictModeTypeErrorFunction::destroy): + * runtime/Executable.cpp: + (JSC::ExecutableBase::destroy): + (JSC::NativeExecutable::destroy): + (JSC::ScriptExecutable::destroy): + (JSC::EvalExecutable::destroy): + (JSC::ProgramExecutable::destroy): + (JSC::FunctionExecutable::destroy): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::destroy): + * runtime/JSPropertyNameIterator.cpp: + (JSC::JSPropertyNameIterator::destroy): + * runtime/JSStaticScopeObject.cpp: + (JSC::JSStaticScopeObject::destroy): + * runtime/JSString.cpp: + (JSC::JSString::destroy): + * runtime/JSVariableObject.cpp: + (JSC::JSVariableObject::destroy): + * runtime/NameInstance.cpp: + (JSC::NameInstance::destroy): + * runtime/RegExp.cpp: + (JSC::RegExp::destroy): + * runtime/RegExpConstructor.cpp: + (JSC::RegExpConstructor::destroy): + * runtime/Structure.cpp: + (JSC::Structure::destroy): + * runtime/StructureChain.cpp: + (JSC::StructureChain::destroy): Use static_cast instead of jsCast because + jsCast does Structure-based validation, and our Structure is not guaranteed + to be alive when we get finalized. + +2012-05-22 Filip Pizlo <fpizlo@apple.com> + + DFG CSE should eliminate redundant WeakJSConstants + https://bugs.webkit.org/show_bug.cgi?id=87179 + + Reviewed by Gavin Barraclough. + + Merged r118141 from dfgopt. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::weakConstantCSE): + (CSEPhase): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGNode.h: + (JSC::DFG::Node::weakConstant): + +2012-05-22 Filip Pizlo <fpizlo@apple.com> + + DFG CSE should do redundant store elimination + https://bugs.webkit.org/show_bug.cgi?id=87161 + + Reviewed by Oliver Hunt. + + Merge r118138 from dfgopt. + + This patch adds redundant store elimination. For example, consider this + code: + + o.x = 42; + o.x = 84; + + If o.x is speculated to be a well-behaved field, the first assignment is + unnecessary, since the second just overwrites it. We would like to + eliminate the first assignment in these cases. The need for this + optimization arises mostly from stores that our runtime requires. For + example: + + o = {f:1, g:2, h:3}; + + This will have four assignments to the structure for the newly created + object - one assignment for the empty structure, one for {f}, one for + {f, g}, and one for {f, g, h}. We would like to only have the last of + those assigments in this case. + + Intriguingly, doing so for captured variables breaks the way arguments + simplification used to work. Consider that prior to either arguments + simplification or store elimination we will have IR that looks like: + + a: SetLocal(r0, Empty) + b: SetLocal(r1, Empty) + c: GetLocal(r0) + d: CreateArguments(@c) + e: SetLocal(r0, @d) + f: SetLocal(r1, @d) + + Then redundant store elimination will eliminate the stores that + initialize the arguments registers to Empty, but then arguments + simplification eliminates the stores that initialize the arguments to + the newly created arguments - and at this point we no longer have any + stores to the arguments register, leading to hilarious crashes. This + patch therefore changes arguments simplification to replace + CreateArguments with JSConstant(Empty) rather than eliminating the + SetLocals. But this revealed bugs where arguments simplification was + being overzealous, so I fixed those bugs. + + This is a minor speed-up on V8/early and a handful of other tests. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::uncheckedActivationRegister): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::putByOffsetStoreElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::uncheckedActivationRegisterFor): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::isPhantomArguments): + (Node): + (JSC::DFG::Node::hasConstant): + (JSC::DFG::Node::valueOfJSConstant): + (JSC::DFG::Node::hasStructureTransitionData): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-21 Filip Pizlo <fpizlo@apple.com> + + DFG ConvertThis should just be a CheckStructure if the structure is known + https://bugs.webkit.org/show_bug.cgi?id=87057 + + Reviewed by Gavin Barraclough. + + Merged r118021 from dfgopt. + + This gives ValueProfile the ability to track singleton values - i.e. profiling + sites that always see the same value. + + That is then used to profile the structure in op_convert_this. + + This is then used to optimize op_convert_this into a CheckStructure if the + structure is always the same. + + That then results in better CSE in inlined code that uses 'this', since + previously we couldn't CSE accesses on 'this' from different inline call frames. + + Also fixed a bug where we were unnecessarily flushing 'this'. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::stronglyVisitStrongReferences): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions): + * bytecode/LazyOperandValueProfile.h: + (CompressedLazyOperandValueProfileHolder): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::ValueProfileBase): + (JSC::ValueProfileBase::dump): + (JSC::ValueProfileBase::computeUpdatedPrediction): + (ValueProfileBase): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::parseBlock): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_convert_this): + (JSC::JIT::emitSlow_op_convert_this): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_convert_this): + (JSC::JIT::emitSlow_op_convert_this): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSValue.h: + (JSValue): + * runtime/Structure.h: + (JSC::JSValue::structureOrUndefined): + (JSC): + +2012-05-24 Tim Horton <timothy_horton@apple.com> + + Add feature defines for web-facing parts of CSS Regions and Exclusions + https://bugs.webkit.org/show_bug.cgi?id=87442 + <rdar://problem/10887709> + + Reviewed by Dan Bernstein. + + * Configurations/FeatureDefines.xcconfig: + +2012-05-24 Geoffrey Garen <ggaren@apple.com> + + WebKit should be lazy-finalization-safe (esp. the DOM) + https://bugs.webkit.org/show_bug.cgi?id=87456 + + Reviewed by Filip Pizlo. + + Lazy finalization adds one twist to weak pointer use: + + A HashMap of weak pointers may contain logically null entries. + (Weak pointers behave as-if null once their payloads die.) + Insertion must not assume that a pre-existing entry is + necessarily valid, and iteration must not assume that all + entries can be dereferenced. + + (Previously, I thought that it also added a second twist: + + A demand-allocated weak pointer may replace a dead payload + before the payload's finalizer runs. In that case, when the + payload's finalizer runs, the payload has already been + overwritten, and the finalizer should not clear the payload, + which now points to something new. + + But that's not the case here, since we cancel the old payload's + finalizer when we over-write it. I've added ASSERTs to verify this + assumption, in case it ever changes.) + + * API/JSClassRef.cpp: + (OpaqueJSClass::prototype): No need to specify null; that's the default. + + * API/JSWeakObjectMapRefPrivate.cpp: Use remove, since take() is gone. + + * heap/PassWeak.h: + (WeakImplAccessor::was): This is no longer a debug-only function, since + it's required to reason about lazily finalized pointers. + + * heap/Weak.h: + (JSC::weakAdd): + (JSC::weakRemove): + (JSC::weakClear): Added these helper functions for the common idioms of + what clients want to do in their weak pointer finalizers. + + * jit/JITStubs.cpp: + (JSC::JITThunks::hostFunctionStub): Use the new idioms. Otherwise, we + would return NULL for a "zombie" executable weak pointer that was waiting + for finalization (item (2)), and finalizing a dead executable weak pointer + would potentially destroy a new, live one (item (1)). + + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::lookupOrCreate): + (JSC::RegExpCache::finalize): Ditto. + + (JSC::RegExpCache::invalidateCode): Check for null while iterating. (See + item (2).) + + * runtime/Structure.cpp: + (JSC::StructureTransitionTable::contains): + (JSC::StructureTransitionTable::add): Use get and set instead of add and + contains, since add and contains are not compatible with lazy finalization. + + * runtime/WeakGCMap.h: + (WeakGCMap): + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::remove): Removed a bunch of code that was incompatible with + lazy finalization because I didn't feel like making it compatible, and I had + no way to test it. + +2012-05-24 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r118013-r118031): Loops/Reloads under www.yahoo.com, quits after three tries with error + https://bugs.webkit.org/show_bug.cgi?id=87327 + + Reviewed by Geoffrey Garen. + + If you use AbstractValue::filter(StructureSet) to test subset relationships between TOP and a + set containing >=2 elements, you're going to have a bad time. + + That's because AbstractValue considers a set with >=2 elements to be equivalent to TOP, in order + to save space and speed up convergence. So filtering has no effect in this case, which made + the code think that the abstract value was proving that the structure check was unnecessary. + The correct thing to do is to use isSubsetOf() on the StructureAbstractValue, which does the + right thingies for TOP and >=2 elements. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-24 Filip Pizlo <fpizlo@apple.com> + + new test fast/js/dfg-arguments-mixed-alias.html fails on JSVALUE32_64 + https://bugs.webkit.org/show_bug.cgi?id=87378 + + Reviewed by Gavin Barraclough. + + - Captured variable tracking forgot did not consistently handle arguments, leading to OSR + badness. + + - Nodes capable of exiting were tracked in a non-monotonic way, leading to compiler errors. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (CSEPhase): + (JSC::DFG::performCSE): + * dfg/DFGCSEPhase.h: + (DFG): + * dfg/DFGCommon.h: + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::resetExitStates): + (DFG): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGPhase.h: + (DFG): + (JSC::DFG::runPhase): + +2012-05-24 Geoffrey Garen <ggaren@apple.com> + + Made WeakSet per-block instead of per-heap + https://bugs.webkit.org/show_bug.cgi?id=87401 + + Reviewed by Oliver Hunt. + + This allows us fast access to the set of all weak pointers for a block, + which is a step toward lazy finalization. + + No performance change. + + * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC::Heap::lastChanceToFinalize): Removed the per-heap weak set, since + it's per-block now. + + (JSC::Heap::markRoots): Delegate weak set visiting to the marked space, + since it knows how to iterate all blocks. + + (JSC::Heap::collect): Moved the reaping outside of markRoots, since it + doesn't mark anything. + + Make sure to reset allocators after shrinking, since shrinking may + deallocate the current allocator. + + * heap/Heap.h: + (Heap): No more per-heap weak set, since it's per-block now. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC::MarkedBlock::lastChanceToFinalize): Migrated finalization logic + here from the heap, so the heap doesn't need to know about our internal + data structures like our weak set. + + (JSC::MarkedBlock::heap): + (JSC::MarkedBlock::weakSet): + (JSC::MarkedBlock::shrink): + (JSC::MarkedBlock::resetAllocator): + (JSC::MarkedBlock::visitWeakSet): + (JSC::MarkedBlock::reapWeakSet): + (JSC::MarkedBlock::sweepWeakSet): + * heap/MarkedSpace.cpp: + (JSC::VisitWeakSet::VisitWeakSet): + (JSC::VisitWeakSet::operator()): + (VisitWeakSet): + (JSC): + (JSC::ReapWeakSet::operator()): + (JSC::SweepWeakSet::operator()): + (JSC::LastChanceToFinalize::operator()): + (JSC::MarkedSpace::lastChanceToFinalize): + (JSC::ResetAllocator::operator()): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::visitWeakSets): + (JSC::MarkedSpace::reapWeakSets): + (JSC::MarkedSpace::sweepWeakSets): + (JSC::Shrink::operator()): + (JSC::MarkedSpace::shrink): + * heap/MarkedSpace.h: + (MarkedSpace): Make sure to account for our weak sets when sweeping, + shrinking, etc. + + * heap/WeakSet.cpp: + (JSC): + * heap/WeakSet.h: + (WeakSet): + (JSC::WeakSet::heap): + (JSC): + (JSC::WeakSet::lastChanceToFinalize): + (JSC::WeakSet::visit): + (JSC::WeakSet::reap): + (JSC::WeakSet::shrink): + (JSC::WeakSet::resetAllocator): Inlined some things since they're called + once per block now instead of once per heap. + + * heap/WeakSetInlines.h: + (JSC::WeakSet::allocate): Use the per-block weak set since there is no + per-heap weak set anymore. + +2012-05-24 Gavin Barraclough <barraclough@apple.com> + + Fix arm build + + Rubber stamped by Geoff Garen + + * dfg/DFGGPRInfo.h: + (GPRInfo): + +2012-05-24 Gavin Barraclough <barraclough@apple.com> + + Move cacheFlush from ExecutableAllocator to Assembler classes + https://bugs.webkit.org/show_bug.cgi?id=87420 + + Reviewed by Oliver Hunt. + + Makes more sense there, & remove a pile of #ifdefs. + + * assembler/ARMAssembler.cpp: + (JSC): + (JSC::ARMAssembler::cacheFlush): + * assembler/ARMAssembler.h: + (ARMAssembler): + (JSC::ARMAssembler::cacheFlush): + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::relinkJump): + (JSC::ARMv7Assembler::cacheFlush): + (ARMv7Assembler): + (JSC::ARMv7Assembler::setInt32): + (JSC::ARMv7Assembler::setUInt7ForLoad): + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::cacheFlush): + * assembler/LinkBuffer.h: + (JSC::LinkBuffer::performFinalization): + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::relinkJump): + (JSC::MIPSAssembler::relinkCall): + (JSC::MIPSAssembler::repatchInt32): + (JSC::MIPSAssembler::cacheFlush): + (MIPSAssembler): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::repatchCompact): + (JSC::SH4Assembler::cacheFlush): + (SH4Assembler): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::cacheFlush): + * jit/ExecutableAllocator.cpp: + (JSC): + * jit/ExecutableAllocator.h: + (ExecutableAllocator): + +2012-05-24 John Mellor <johnme@chromium.org> + + Font Boosting: Add compile flag and runtime setting + https://bugs.webkit.org/show_bug.cgi?id=87394 + + Reviewed by Adam Barth. + + Add ENABLE_FONT_BOOSTING. + + * Configurations/FeatureDefines.xcconfig: + +2012-05-24 Allan Sandfeld Jensen <allan.jensen@nokia.com> + + cti_vm_throw gets kicked out by gcc 4.6 -flto + https://bugs.webkit.org/show_bug.cgi?id=56088 + + Reviewed by Darin Adler. + + Add REFERENCED_FROM_ASM to functions only referenced from assembler. + + * dfg/DFGOperations.cpp: + * jit/HostCallReturnValue.h: + * jit/JITStubs.h: + * jit/ThunkGenerators.cpp: + +2012-05-24 Filip Pizlo <fpizlo@apple.com> + + Incorrect merge of r117542 from dfg opt branch in r118323 is leading to fast/js/dfg-arguments-osr-exit.html failing + https://bugs.webkit.org/show_bug.cgi?id=87350 + + Reviewed by Maciej Stachowiak. + + The dfgopt branch introduced the notion of a local variable being killed because it was aliased + to the Arguments object as in cases like: + + var a = arguments; + return a.length; + + This required changes to OSR exit handling - if the variable is dead but aliased to arguments, then + OSR exit should reify the arguments. But meanwhile, in tip of tree we introduced special handling for + dead variables on OSR exit. When the two were merged in r118323, the structure of the if/else branches + ended up being such that we would treat dead arguments variables as totally dead as opposed to treating + them as variables that need arguments reification. + + This fixes the structure of the relevant if/else block so that variables that are dead-but-arguments + end up being treated as reified arguments objects, while variables that are dead but not aliased to + arguments are treated as tip of tree would have treated them (initialize to Undefined). + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-24 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed 32 bit buildfix after r118325. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): Use ASSERT_UNUSED instead ASSERT. + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + DFG operationTearOffActivation should return after handling the null activation case + https://bugs.webkit.org/show_bug.cgi?id=87348 + <rdar://problem/11522295> + + Reviewed by Oliver Hunt. + + * dfg/DFGOperations.cpp: + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, merge the arguments fix in r118138 to get bots green. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + +2012-05-20 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should record if a node can OSR exit + https://bugs.webkit.org/show_bug.cgi?id=86905 + + Reviewed by Oliver Hunt. + + Merged r117931 from dfgopt. + + Adds a NodeFlag that denotes nodes that are known to not have OSR exits. + This ought to aid any backwards analyses that need to know when a + backward flow merge might happen due to a side exit. + + Also added assertions into speculationCheck() that ensure that we did not + mark a node as non-exiting and then promptly compile in an exit. This + helped catch some minor bugs where we were doing unnecessary speculation + checks. + + This is a perf-neutral change. The speculation checks that this removes + were not on hot paths of major benchmarks. + + * bytecode/PredictedType.h: + (JSC): + (JSC::isAnyPrediction): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::speculateInt32Unary): + (AbstractState): + (JSC::DFG::AbstractState::speculateNumberUnary): + (JSC::DFG::AbstractState::speculateBooleanUnary): + (JSC::DFG::AbstractState::speculateInt32Binary): + (JSC::DFG::AbstractState::speculateNumberBinary): + * dfg/DFGNode.h: + (JSC::DFG::Node::mergeFlags): + (JSC::DFG::Node::filterFlags): + (Node): + (JSC::DFG::Node::setCanExit): + (JSC::DFG::Node::canExit): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-20 Filip Pizlo <fpizlo@apple.com> + + DFG should not do unnecessary indirections when storing to objects + https://bugs.webkit.org/show_bug.cgi?id=86959 + + Reviewed by Oliver Hunt. + + Merged r117819 from dfgopt. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-17 Filip Pizlo <fpizlo@apple.com> + + DFG should optimize aliased uses of the Arguments object of the current call frame + https://bugs.webkit.org/show_bug.cgi?id=86552 + + Reviewed by Geoff Garen. + + Merged r117542 and r117543 from dfgopt. + + Performs must-alias and escape analysis on uses of CreateArguments, and if + a variable is must-aliased to CreateArguments and does not escape, then we + turn all uses of that variable into direct arguments accesses. + + 36% speed-up on V8/earley leading to a 2.3% speed-up overall in V8. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::uncheckedArgumentsRegister): + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::argumentsThatWereNotCreated): + (ValueRecovery): + (JSC::ValueRecovery::dump): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAdjacencyList.h: + (AdjacencyList): + (JSC::DFG::AdjacencyList::removeEdgeFromBag): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (ArgumentsSimplificationPhase): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::argumentsRegisterFor): + (AssemblyHelpers): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): + * dfg/DFGGPRInfo.h: + (GPRInfo): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::collectGarbage): + (DFG): + * dfg/DFGGraph.h: + (Graph): + (JSC::DFG::Graph::executableFor): + (JSC::DFG::Graph::argumentsRegisterFor): + (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasHeapPrediction): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler.h: + (JSC::DFG::OSRExitCompiler::OSRExitCompiler): + (OSRExitCompiler): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::ValueSource::dump): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + * dfg/DFGSpeculativeJIT.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): + (VariableAccessData): + (JSC::DFG::VariableAccessData::isArgumentsAlias): + * jit/JITOpcodes.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + DFGCapabilities should not try to get an arguments register from code blocks that don't have one + https://bugs.webkit.org/show_bug.cgi?id=87332 + + Reviewed by Andy Estes. + + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineOpcode): + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + DFG should have sparse conditional constant propagation + https://bugs.webkit.org/show_bug.cgi?id=86580 + + Reviewed by Oliver Hunt. + + Merged r117370 from dfgopt. + + This enhances CFA so that if it suspects at any point during the fixpoint that a + branch will only go one way, then it only propagates in that one way. + + This vastly increases the opportunities for CFG simplification. For example, it + enables us to evaporate this loop: + + for (var i = 0; i < 1; ++i) doThings(i); + + As a result, it uncovered loads of bugs in the CFG simplifier. In particular: + + - Phi fixup was assuming that all Phis worth fixing up are shouldGenerate(). + That's not true; we also fixup Phis that are dead. + + - GetLocal fixup was assuming that it's only necessary to rewire links to a + GetLocal, and that the GetLocal's own links don't need to be rewired. Untrue, + because the GetLocal may not be rewirable (first block has no GetLocal for r42 + but second block does have a GetLocal), in which case it will refer to a Phi + in the second block. We need it to refer to a Phi from the first block to + ensure that subsequent transformations work. + + - Tail operand fixup was ignoring the fact that Phis in successors may contain + references to the children of our tail variables. Hence, successor Phi child + substitution needs to use the original second block variable table as its + prior, rather than trying to reconstruct the prior later (since by that point + the children of the second block's tail variables will have been fixed up, so + we will not know what the prior would have been). + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::beginBasicBlock): + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::reset): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::branchDirectionToString): + (AbstractState): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): + (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::OperandSubstitution): + (OperandSubstitution): + (JSC::DFG::CFGSimplificationPhase::skipGetLocal): + (JSC::DFG::CFGSimplificationPhase::recordPossibleIncomingReference): + (CFGSimplificationPhase): + (JSC::DFG::CFGSimplificationPhase::fixTailOperand): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::changeEdge): + +2012-05-23 Ojan Vafai <ojan@chromium.org> + + add back the ability to disable flexbox + https://bugs.webkit.org/show_bug.cgi?id=87147 + + Reviewed by Tony Chang. + + * Configurations/FeatureDefines.xcconfig: + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix Windows build. + + * bytecode/CodeBlock.h: + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canCompileOpcodes): + * dfg/DFGCommon.h: + (DFG): + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + DFG should optimize inlined uses of arguments.length and arguments[i] + https://bugs.webkit.org/show_bug.cgi?id=86327 + + Reviewed by Gavin Barraclough. + + Merged r117017 from dfgopt. + + Turns inlined uses of arguments.length into a constant. + + Turns inlined uses of arguments[constant] into a direct reference to the + argument. + + Big win on micro-benchmarks. Not yet a win on V8 because the hot uses of + arguments.length and arguments[i] are aliased. I'll leave the aliasing + optimizations to a later patch. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/DFGExitProfile.h: + (FrequentExitSite): + (JSC::DFG::FrequentExitSite::FrequentExitSite): + (JSC::DFG::QueryableExitProfile::hasExitSite): + (QueryableExitProfile): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentsSimplificationPhase.cpp: Added. + (DFG): + (ArgumentsSimplificationPhase): + (JSC::DFG::ArgumentsSimplificationPhase::ArgumentsSimplificationPhase): + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::performArgumentsSimplification): + * dfg/DFGArgumentsSimplificationPhase.h: Added. + (DFG): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::executableFor): + (DFG): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::Graph): + (JSC::DFG::Graph::executableFor): + (Graph): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToConstant): + (JSC::DFG::Node::convertToGetLocalUnlinked): + (Node): + (JSC::DFG::Node::unlinkedLocal): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-13 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to optimize foo.apply(bar, arguments) + https://bugs.webkit.org/show_bug.cgi?id=86306 + + Reviewed by Gavin Barraclough. + + Merge r116912 from dfgopt. + + Enables compilation of op_jneq_ptr and some forms of op_call_varargs. + + Also includes a bunch of bug fixes that were made necessary by the increased + pressure on the CFG simplifier. + + This is a 1-2% win on V8. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::CodeBlock): + (JSC::ProgramCodeBlock::canCompileWithDFGInternal): + (JSC::EvalCodeBlock::canCompileWithDFGInternal): + (JSC::FunctionCodeBlock::canCompileWithDFGInternal): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::canCompileWithDFG): + (JSC::CodeBlock::canCompileWithDFGState): + (ProgramCodeBlock): + (EvalCodeBlock): + (FunctionCodeBlock): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::processPhiStack): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::fixTailOperand): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (CSEPhase): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::debugFail): + (DFG): + (JSC::DFG::canHandleOpcodes): + (JSC::DFG::canCompileOpcodes): + (JSC::DFG::canInlineOpcodes): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + (DFG): + (JSC::DFG::canCompileOpcodes): + (JSC::DFG::canCompileEval): + (JSC::DFG::canCompileProgram): + (JSC::DFG::canCompileFunctionForCall): + (JSC::DFG::canCompileFunctionForConstruct): + * dfg/DFGCommon.h: + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGValidate.cpp: + (Validate): + (JSC::DFG::Validate::validate): + (JSC::DFG::Validate::checkOperand): + (JSC::DFG::Validate::reportValidationContext): + * jit/JIT.cpp: + (JSC::JIT::emitOptimizationCheck): + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): + * jit/JIT.h: + * jit/JITArithmetic.cpp: + (JSC::JIT::compileBinaryArithOp): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + * tools/CodeProfile.cpp: + (JSC::CodeProfile::sample): + +2012-05-23 Geoffrey Garen <ggaren@apple.com> + + Refactored WeakBlock to use malloc, clarify behavior + https://bugs.webkit.org/show_bug.cgi?id=87318 + + Reviewed by Filip Pizlo. + + We want to use malloc so we can make these smaller than 4KB, + since an individual MarkedBlock will usually have fewer than + 4KB worth of weak pointers. + + * heap/Heap.cpp: + (JSC::Heap::markRoots): Renamed visitLiveWeakImpls to visit, since + we no longer need to distinguish from "visitDeadWeakImpls". + + Renamed "visitDeadWeakImpls" to "reap" because we're not actually + doing any visiting -- we're just tagging things as dead. + + * heap/WeakBlock.cpp: + (JSC::WeakBlock::create): + (JSC::WeakBlock::destroy): + (JSC::WeakBlock::WeakBlock): Malloc! + + (JSC::WeakBlock::visit): + (JSC::WeakBlock::reap): Renamed as above. + + * heap/WeakBlock.h: + (WeakBlock): Reduced to 3KB, as explained above. + + * heap/WeakSet.cpp: + (JSC::WeakSet::visit): + (JSC::WeakSet::reap): + * heap/WeakSet.h: + (WeakSet): Updated for renames, and to match WebKit style. + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + Use after free in JSC::DFG::ByteCodeParser::processPhiStack + https://bugs.webkit.org/show_bug.cgi?id=87312 + <rdar://problem/11518848> + + Reviewed by Oliver Hunt. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::processPhiStack): + (JSC::DFG::ByteCodeParser::parse): + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + It should be possible to make C function calls from DFG code on ARM in debug mode + https://bugs.webkit.org/show_bug.cgi?id=87313 + + Reviewed by Gavin Barraclough. + + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2012-05-11 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to inline functions that use arguments reflectively + https://bugs.webkit.org/show_bug.cgi?id=86132 + + Reviewed by Oliver Hunt. + + Merged r116838 from dfgopt. + + This turns on inlining of functions that use arguments reflectively, but it + does not do any of the obvious optimizations that this exposes. I'll save that + for another patch - the important thing for now is that this contains all of + the plumbing necessary to make this kind of inlining sound even in bizarro + cases like an inline callee escaping the arguments object to parts of the + inline caller where the arguments are otherwise dead. Or even more fun cases + like where you've inlined to an inline stack that is three-deep, and the + function on top of the inline stack reflectively accesses the arguments of a + function that is in the middle of the inline stack. Any subsequent + optimizations that we do for the obvious cases of arguments usage in inline + functions will have to take care not to break the baseline functionality that + this patch plumbs together. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::dump): + * bytecode/CodeBlock.h: + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::argumentsRegisterFor): + (AssemblyHelpers): + * dfg/DFGByteCodeParser.cpp: + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineOpcode): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/CallFrame.cpp: + (JSC): + (JSC::CallFrame::someCodeBlockForPossiblyInlinedCode): + * interpreter/CallFrame.h: + (ExecState): + (JSC::ExecState::someCodeBlockForPossiblyInlinedCode): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::retrieveArgumentsFromVMCode): + * runtime/Arguments.cpp: + (JSC::Arguments::tearOff): + (JSC): + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/Arguments.h: + (Arguments): + (JSC::Arguments::create): + (JSC::Arguments::finishCreation): + (JSC): + +2012-05-23 Filip Pizlo <fpizlo@apple.com> + + Every OSR exit on ARM results in a crash + https://bugs.webkit.org/show_bug.cgi?id=87307 + + Reviewed by Geoffrey Garen. + + * dfg/DFGThunks.cpp: + (JSC::DFG::osrExitGenerationThunkGenerator): + +2012-05-23 Geoffrey Garen <ggaren@apple.com> + + Refactored heap tear-down to use normal value semantics (i.e., destructors) + https://bugs.webkit.org/show_bug.cgi?id=87302 + + Reviewed by Oliver Hunt. + + This is a step toward incremental DOM finalization. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::~CopiedSpace): + * heap/CopiedSpace.h: + (CopiedSpace): Just use our destructor, instead of relying on the heap + to send us a special message at a special time. + + * heap/Heap.cpp: + (JSC::Heap::Heap): Use OwnPtr for m_markListSet because this is not Sparta. + + (JSC::Heap::~Heap): No need for delete or freeAllBlocks because normal + destructors do this work automatically now. + + (JSC::Heap::lastChanceToFinalize): Just call lastChanceToFinalize on our + sub-objects, and assume it does the right thing. This improves encapsulation, + so we can add items requiring finalization to our sub-objects. + + * heap/Heap.h: Moved m_blockAllocator to get the right destruction order. + + * heap/MarkedSpace.cpp: + (Take): + (JSC): + (JSC::Take::Take): + (JSC::Take::operator()): + (JSC::Take::returnValue): Moved to the top of the file so it can be used + in another function. + + (JSC::MarkedSpace::~MarkedSpace): Delete all outstanding memory, like a good + destructor should. + + (JSC::MarkedSpace::lastChanceToFinalize): Moved some code here from the heap, + since it pertains to our internal implementation details. + + * heap/MarkedSpace.h: + (MarkedSpace): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::lastChanceToFinalize): + * heap/WeakBlock.h: + (WeakBlock): + * heap/WeakSet.cpp: + (JSC::WeakSet::lastChanceToFinalize): + * heap/WeakSet.h: + (WeakSet): Stop using a special freeAllBlocks() callback and just implement + lastChanceToFinalize. + +2011-05-22 Geoffrey Garen <ggaren@apple.com> + + Encapsulated some calculations for whether portions of the heap are empty + https://bugs.webkit.org/show_bug.cgi?id=87210 + + Reviewed by Gavin Barraclough. + + This is a step toward incremental DOM finalization. + + * heap/Heap.cpp: + (JSC::Heap::~Heap): Explicitly call freeAllBlocks() instead of relying + implicitly on all blocks thinking they're empty. In future, we may + choose to tear down the heap without first setting all data structures + to "empty". + + * heap/MarkedBlock.h: + (JSC::MarkedBlock::isEmpty): + (JSC::MarkedBlock::gatherDirtyCells): Renamed markCountIsZero to isEmpty, + in preparation for making it check for outstanding finalizers in addition + to marked cells. + + * heap/MarkedSpace.cpp: + (Take): + (JSC::Take::Take): + (JSC::Take::operator()): + (JSC::Take::returnValue): + (JSC::MarkedSpace::shrink): + (JSC::MarkedSpace::freeAllBlocks): Refactored the "Take" functor to support + a conditional isEmpty check, so it dould be shared by shrink() and freeAllBlocks(). + + * heap/WeakBlock.cpp: + (JSC::WeakBlock::WeakBlock): + (JSC::WeakBlock::visitLiveWeakImpls): + (JSC::WeakBlock::visitDeadWeakImpls): + * heap/WeakBlock.h: + (WeakBlock): + (JSC::WeakBlock::isEmpty): + * heap/WeakSet.cpp: + (JSC::WeakSet::sweep): + (JSC::WeakSet::shrink): Use isEmpty(), in preparation for changes in + its implementation. + +2012-05-23 Oswald Buddenhagen <oswald.buddenhagen@nokia.com> + + [Qt] Remove references to $$QT_SOURCE_TREE + + With a modularized Qt, it's ambigious. What we really want is qtbase, + which qtcore is a proxy for (we assume it will always live in qtbase). + + Reviewed by Tor Arne Vestbø. + + * JavaScriptCore.pri: + * Target.pri: + +2012-05-09 Filip Pizlo <fpizlo@apple.com> + + DFG should allow inlining in case of certain arity mismatches + https://bugs.webkit.org/show_bug.cgi?id=86059 + + Reviewed by Geoff Garen. + + Merge r116620 from dfgopt. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleInlining): + +2012-05-08 Filip Pizlo <fpizlo@apple.com> + + DFG variable capture analysis should work even if the variables arose through inlining + https://bugs.webkit.org/show_bug.cgi?id=85945 + + Reviewed by Oliver Hunt. + + Merged r116555 from dfgopt. + + This just changes how the DFG queries whether a variable is captured. It does not + change any user-visible behavior. + + As part of this change, I further solidified the policy that the CFA behaves in an + undefined way for captured locals and queries about their values will not yield + reliable results. This will likely be changed in the future, but for now it makes + sense. + + One fun part about this change is that it recognizes that the same variable may + be both captured and not, at the same time, because their live interval spans + inlining boundaries. This only happens in the case of arguments to functions that + capture their arguments, and this change treats them with just the right touch of + conservatism: they will be treated as if captured by the caller as well as the + callee. + + Finally, this also adds captured variable reasoning to the InlineCallFrame, which + I thought might be useful for later tooling. + + This is perf-neutral, since it does it does not make the DFG take advantage of this + new functionality in any way. In particular, it is still the case that the DFG will + not inline functions that use arguments reflectively or that create activations. + + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::needsActivation): + (JSC::CodeBlock::argumentIsCaptured): + (JSC::CodeBlock::localIsCaptured): + (JSC::CodeBlock::isCaptured): + * bytecode/CodeOrigin.h: + (InlineCallFrame): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::merge): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::newVariableAccessData): + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::flushArgument): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::processPhiStack): + (JSC::DFG::ByteCodeParser::fixVariableAccessPredictions): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCFGSimplificationPhase.cpp: + (CFGSimplificationPhase): + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::fixTailOperand): + * dfg/DFGCommon.h: + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::nameOfVariableAccessData): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::needsActivation): + (JSC::DFG::Graph::usesArguments): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsCaptured): + (VariableAccessData): + (JSC::DFG::VariableAccessData::isCaptured): + +2012-05-08 Filip Pizlo <fpizlo@apple.com> + + DFG should support op_get_argument_by_val and op_get_arguments_length + https://bugs.webkit.org/show_bug.cgi?id=85911 + + Reviewed by Oliver Hunt. + + Merged r116467 from dfgopt. + + This adds a simple and relatively conservative implementation of op_get_argument_by_val + and op_get_arguments_length. We can optimize these later. For now it's great to have + the additional coverage. + + This patch appears to be perf-neutral. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::addressFor): + (JSC::DFG::AssemblyHelpers::tagFor): + (JSC::DFG::AssemblyHelpers::payloadFor): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasHeapPrediction): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_get_argument_by_val): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_get_argument_by_val): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-05-07 Filip Pizlo <fpizlo@apple.com> + + DFG should support op_tear_off_arguments + https://bugs.webkit.org/show_bug.cgi?id=85847 + + Reviewed by Michael Saboff. + + Merged r116378 from dfgopt. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-05-22 Mark Hahnenberg <mhahnenberg@apple.com> + + CopiedSpace::contains doesn't check for oversize blocks + https://bugs.webkit.org/show_bug.cgi?id=87180 + + Reviewed by Geoffrey Garen. + + When doing a conservative scan we use CopiedSpace::contains to determine if a particular + address points into the CopiedSpace. Currently contains() only checks if the address + points to a block in to-space, which means that pointers to oversize blocks may not get scanned. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocateOversize): + (JSC::CopiedSpace::doneFillingBlock): + (JSC::CopiedSpace::doneCopying): + * heap/CopiedSpace.h: Refactored CopiedSpace so that all blocks (oversize and to-space) are + in a single hash set and bloom filter for membership testing. + (CopiedSpace): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::contains): We check for the normal block first. Since the oversize blocks are + only page aligned, rather than block aligned, we have to re-mask the ptr to check if it's in + CopiedSpace. Also added a helper function of the same name that takes a CopiedBlock* and checks + if it's in CopiedSpace so that check isn't typed out twice. + (JSC): + (JSC::CopiedSpace::startedCopying): + (JSC::CopiedSpace::addNewBlock): + +2012-05-22 Geoffrey Garen <ggaren@apple.com> + + CopiedBlock and MarkedBlock should have proper value semantics (i.e., destructors) + https://bugs.webkit.org/show_bug.cgi?id=87172 + + Reviewed by Oliver Hunt and Phil Pizlo. + + This enables MarkedBlock to own non-trivial sub-objects that require + destruction. It also fixes a FIXME about casting a CopiedBlock to a + MarkedBlock at destroy time. + + CopiedBlock and MarkedBlock now accept an allocation chunk at create + time and return it at destroy time. Their client is expected to + allocate, recycle, and destroy these chunks. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::releaseFreeBlocks): + (JSC::BlockAllocator::blockFreeingThreadMain): Don't call MarkedBlock::destroy + because we expect that to be called before a block is put on our free + list now. Do manually deallocate our allocation chunk because that's + our job now. + + * heap/BlockAllocator.h: + (BlockAllocator): + (JSC::BlockAllocator::allocate): Allocate never fails now. This is a + cleaner abstraction because only one object does all the VM allocation + and deallocation. Caching is an implementation detail. + + (JSC::BlockAllocator::deallocate): We take an allocation chunk argument + instead of a block because we now expect the block to have been destroyed + before we recycle its memory. For convenience, we still use the HeapBlock + class as our linked list node. This is OK because HeapBlock is a POD type. + + * heap/CopiedBlock.h: + (CopiedBlock): + (JSC::CopiedBlock::create): + (JSC::CopiedBlock::destroy): + (JSC::CopiedBlock::CopiedBlock): Added proper create and destroy functions, + to match MarkedBlock. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocateOversize): + (JSC::CopiedSpace::doneCopying): + (JSC::CopiedSpace::getFreshBlock): + (JSC::CopiedSpace::freeAllBlocks): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::recycleBlock): Make sure to call destroy before + returning a block to the BlockAllocator. Otherwise, our destructors + won't run. (If we get this wrong now, we'll get a compile error.) + + * heap/HeapBlock.h: + (JSC::HeapBlock::HeapBlock): const! + + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateBlock): No need to distinguish between + create and recycle -- MarkedBlock always accepts memory allocated by + its client now. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::create): Don't allocate memory -- we assume that we're + passed already-allocated memory, to clarify the responsibility for VM + recycling. + + (JSC::MarkedBlock::destroy): Do run our destructor before giving back + our VM -- that is the whole point of this patch. + + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (MarkedBlock): + * heap/MarkedSpace.cpp: const! + + (JSC::MarkedSpace::freeBlocks): Make sure to call destroy before + returning a block to the BlockAllocator. Otherwise, our destructors + won't run. (If we get this wrong now, we'll get a compile error.) + +== Rolled over to ChangeLog-2012-05-22 == |