2009-06-15  Gavin Barraclough  <barraclough@apple.com>

        Rubber Stamped by Sam Weinig.

        Rename PatchBuffer to LinkBuffer.  Previously our terminology has been a little

        mixed up, but we have decided to fix on refering to the process that takes place

        at the end of code generation as 'linking', and on any modifications that take

        place later (and once the code has potentially already been executed) as 'patching'.

        However, the term 'PatchBuffer' is already in use, and needs to be repurposed.

        To try to minimize confusion, we're going to switch the terminology over in stages,

        so for now we'll refer to later modifications as 'repatching'.  This means that the

        new 'PatchBuffer' has been introduced with the name 'RepatchBuffer' instead.

        This patch renames the old 'PatchBuffer' to 'LinkBuffer'.  We'll leave ToT in this

        state for a week or so to try to avoid to much overlap of the meaning of the term

        'PatchBuffer', then will come back and rename 'RepatchBuffer'.

        * assembler/ARMv7Assembler.h:

        * assembler/AbstractMacroAssembler.h:

        (JSC::AbstractMacroAssembler::LinkBuffer::LinkBuffer):

        (JSC::AbstractMacroAssembler::LinkBuffer::~LinkBuffer):

        * jit/JIT.cpp:

        (JSC::JIT::privateCompile):

        * jit/JITPropertyAccess.cpp:

        (JSC::JIT::privateCompilePutByIdTransition):

        (JSC::JIT::privateCompilePatchGetArrayLength):

        (JSC::JIT::privateCompileGetByIdProto):

        (JSC::JIT::privateCompileGetByIdSelfList):

        (JSC::JIT::privateCompileGetByIdProtoList):

        (JSC::JIT::privateCompileGetByIdChainList):

        (JSC::JIT::privateCompileGetByIdChain):

        * yarr/RegexJIT.cpp:

        (JSC::Yarr::RegexGenerator::compile):

2009-06-15  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Sam Weinig.

        Having moved most of their functionality into the RepatchBuffer class,

        we can simplify the CodeLocation* classes.

        The CodeLocation* classes are currently a tangle of templatey and friendly

        badness, burried in the middle of AbstractMacroAssembler.  Having moved

        the ability to repatch out into RepatchBufer they are now do-nothing wrappers

        on CodePtr (MacroAssemblerCodePtr), that only exist to provide type-safety.

        Simplify the code, and move them off into their own header.

        * JavaScriptCore.xcodeproj/project.pbxproj:

        * assembler/AbstractMacroAssembler.h:

        (JSC::AbstractMacroAssembler::PatchBuffer::patch):

        * assembler/CodeLocation.h: Copied from assembler/AbstractMacroAssembler.h.

        (JSC::CodeLocationCommon::CodeLocationCommon):

        (JSC::CodeLocationInstruction::CodeLocationInstruction):

        (JSC::CodeLocationLabel::CodeLocationLabel):

        (JSC::CodeLocationJump::CodeLocationJump):

        (JSC::CodeLocationCall::CodeLocationCall):

        (JSC::CodeLocationNearCall::CodeLocationNearCall):

        (JSC::CodeLocationDataLabel32::CodeLocationDataLabel32):

        (JSC::CodeLocationDataLabelPtr::CodeLocationDataLabelPtr):

        (JSC::CodeLocationCommon::instructionAtOffset):

        (JSC::CodeLocationCommon::labelAtOffset):

        (JSC::CodeLocationCommon::jumpAtOffset):

        (JSC::CodeLocationCommon::callAtOffset):

        (JSC::CodeLocationCommon::nearCallAtOffset):

        (JSC::CodeLocationCommon::dataLabelPtrAtOffset):

        (JSC::CodeLocationCommon::dataLabel32AtOffset):

        * assembler/MacroAssemblerCodeRef.h:

        (JSC::MacroAssemblerCodePtr::operator!):

        * bytecode/CodeBlock.h:

        (JSC::getStructureStubInfoReturnLocation):

        (JSC::getCallLinkInfoReturnLocation):

        (JSC::getMethodCallLinkInfoReturnLocation):

        * bytecode/Instruction.h:

        * bytecode/JumpTable.h:

        (JSC::StringJumpTable::ctiForValue):

        (JSC::SimpleJumpTable::ctiForValue):

        * bytecode/StructureStubInfo.h:

        * bytecompiler/BytecodeGenerator.cpp:

        (JSC::BytecodeGenerator::emitCatch):

        * jit/JIT.cpp:

        (JSC::JIT::privateCompile):

        * jit/JITStubs.cpp:

        (JSC::JITStubs::DEFINE_STUB_FUNCTION):

        (JSC::JITStubs::getPolymorphicAccessStructureListSlot):

2009-06-15  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Sam Weinig.

        Having introduced the RepatchBuffer, ProcessorReturnAddress is now a do-nothing

        wrapper around ReturnAddressPtr.  Remove it.  In tugging on this piece of string

        it made sense to roll out the use of ReturnAddressPtr a little further into

        JITStubs (which had always been the intention).

        No performance impact.

        * assembler/AbstractMacroAssembler.h:

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkCallerToTrampoline):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkCallerToFunction):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkNearCallerToTrampoline):

        * assembler/MacroAssemblerCodeRef.h:

        (JSC::ReturnAddressPtr::ReturnAddressPtr):

        * bytecode/CodeBlock.h:

        (JSC::CodeBlock::getStubInfo):

        (JSC::CodeBlock::getCallLinkInfo):

        (JSC::CodeBlock::getMethodCallLinkInfo):

        (JSC::CodeBlock::getBytecodeIndex):

        * interpreter/Interpreter.cpp:

        (JSC::bytecodeOffsetForPC):

        * jit/JIT.cpp:

        (JSC::ctiPatchNearCallByReturnAddress):

        (JSC::ctiPatchCallByReturnAddress):

        * jit/JIT.h:

        (JSC::JIT::compileGetByIdProto):

        (JSC::JIT::compileGetByIdChain):

        (JSC::JIT::compilePutByIdTransition):

        (JSC::JIT::compilePatchGetArrayLength):

        * jit/JITPropertyAccess.cpp:

        (JSC::JIT::privateCompilePutByIdTransition):

        (JSC::JIT::patchGetByIdSelf):

        (JSC::JIT::patchPutByIdReplace):

        (JSC::JIT::privateCompilePatchGetArrayLength):

        (JSC::JIT::privateCompileGetByIdProto):

        (JSC::JIT::privateCompileGetByIdChain):

        * jit/JITStubs.cpp:

        (JSC::JITThunks::tryCachePutByID):

        (JSC::JITThunks::tryCacheGetByID):

        (JSC::StackHack::StackHack):

        (JSC::returnToThrowTrampoline):

        (JSC::throwStackOverflowError):

        (JSC::JITStubs::DEFINE_STUB_FUNCTION):

        * jit/JITStubs.h:

        (JSC::):

        (JSC::JITStackFrame::returnAddressSlot):

        * runtime/JSGlobalData.h:

2009-06-15  Simon Fraser  <simon.fraser@apple.com>

        Reviewed by Mark Rowe.

        <rdar://problem/6974857>

        Define ENABLE_3D_RENDERING when building on 10.6, and move ENABLE_3D_RENDERING

        switch from config.h to wtf/Platform.h.

        * Configurations/FeatureDefines.xcconfig:

        * wtf/Platform.h:

2009-06-15  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Oliver Hunt.

        Move repatching methods into a set of methods on a class.  This will allow us to

        coallesce memory reprotection calls.  Really, we want this class to be called

        PatchBuffer, we want the class PatchBuffer to be called LinkBuffer, we want both

        to be memblers of MacroAssembler rather then AbstractMacroAssembler, we don't

        want the CodeLocationFoo types anymore (they are now only really there to provide

        type safety, and that is completely undermined by the way we use offsets).  Then

        the link & patch buffers should delegate the actual patching calls to the

        architecture-specific layer of the MacroAssembler.  Landing all these changes as a

        sequence of patches.

        No performance impact.

        * assembler/AbstractMacroAssembler.h:

        (JSC::AbstractMacroAssembler::CodeLocationCall::CodeLocationCall):

        (JSC::AbstractMacroAssembler::CodeLocationNearCall::CodeLocationNearCall):

        (JSC::AbstractMacroAssembler::CodeLocationNearCall::calleeReturnAddressValue):

        (JSC::AbstractMacroAssembler::RepatchBuffer::RepatchBuffer):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relink):

        (JSC::AbstractMacroAssembler::RepatchBuffer::repatch):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkCallerToTrampoline):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkCallerToFunction):

        (JSC::AbstractMacroAssembler::RepatchBuffer::relinkNearCallerToTrampoline):

        (JSC::AbstractMacroAssembler::RepatchBuffer::repatchLoadPtrToLEA):

        * jit/JIT.cpp:

        (JSC::ctiPatchNearCallByReturnAddress):

        (JSC::ctiPatchCallByReturnAddress):

        (JSC::JIT::unlinkCall):

        (JSC::JIT::linkCall):

        * jit/JITPropertyAccess.cpp:

        (JSC::JIT::privateCompilePutByIdTransition):

        (JSC::JIT::patchGetByIdSelf):

        (JSC::JIT::patchMethodCallProto):

        (JSC::JIT::patchPutByIdReplace):

        (JSC::JIT::privateCompilePatchGetArrayLength):

        (JSC::JIT::privateCompileGetByIdProto):

        (JSC::JIT::privateCompileGetByIdSelfList):

        (JSC::JIT::privateCompileGetByIdProtoList):

        (JSC::JIT::privateCompileGetByIdChainList):

        (JSC::JIT::privateCompileGetByIdChain):

2009-06-15  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Geoff Hunt & Oliver Garen.

        We are currently generating two copies of the slow path for op_call for no reason.  Stop that.

        Originally op_call used two slow paths since the first set up the pointer to the CallLinkInfo

        for use when linking.  However this is now looked up using the return address (as we do for

        property accesses) so the two paths are now identical.

        No performance impact, reduces memory footprint.

        * bytecode/CodeBlock.h:

        * jit/JIT.cpp:

        (JSC::JIT::privateCompile):

        (JSC::JIT::linkCall):

        * jit/JIT.h:

        * jit/JITCall.cpp:

        (JSC::JIT::compileOpCallSlowCase):

        * jit/JITStubs.cpp:

        (JSC::JITStubs::DEFINE_STUB_FUNCTION):

2009-06-12  Dave Hyatt  <hyatt@apple.com>

        Reviewed by Anders Carlsson.

        https://bugs.webkit.org/show_bug.cgi?id=26373

        Add a new class to Threading in wtf called ReadWriteLock that handles single writer/multiple reader locking.

        Provide a pthreads-only implementation of the lock for now, as this class is only going to be used

        on Snow Leopard at first.

        * wtf/Threading.h:

        (WTF::ReadWriteLock::impl):

        * wtf/ThreadingPthreads.cpp:

        (WTF::ReadWriteLock::ReadWriteLock):

        (WTF::ReadWriteLock::~ReadWriteLock):

        (WTF::ReadWriteLock::readLock):

        (WTF::ReadWriteLock::tryReadLock):

        (WTF::ReadWriteLock::writeLock):

        (WTF::ReadWriteLock::tryWriteLock):

        (WTF::ReadWriteLock::unlock):

2009-06-12  Oliver Hunt  <oliver@apple.com>

        Reviewed by Geoff Garen.

        Make LiteralParser non-recursive

        Convert LiteralParser from using a simple recursive descent parser

        to a hand rolled PDA.  Relatively simple conversion, but required

        modifications to MarkedArgumentBuffer to make it more suitable as

        a generic marked vector.   I'll refactor and rename MarkedArgumentBuffer

        in future as there are many other cases where it will be useful to

        have such a class.

        * runtime/ArgList.h:

        (JSC::MarkedArgumentBuffer::MarkedArgumentBuffer):

        (JSC::MarkedArgumentBuffer::append):

        (JSC::MarkedArgumentBuffer::removeLast):

        (JSC::MarkedArgumentBuffer::last):

        * runtime/LiteralParser.cpp:

        (JSC::LiteralParser::parse):

        * runtime/LiteralParser.h:

        (JSC::LiteralParser::LiteralParser):

        (JSC::LiteralParser::tryLiteralParse):

        (JSC::LiteralParser::):

2009-06-12  David Levin  <levin@chromium.org>

        Reviewed by NOBODY (build fix for windows).

        Adjust the exports for JSC on Windows like what was done for OSX in

        the previous commit.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore_debug.def:

2009-06-12  David Levin  <levin@chromium.org>

        Reviewed by Darin Adler.

        UString shouldn't create sharedBuffer for SmallStrings.

        https://bugs.webkit.org/show_bug.cgi?id=26360

        The methods changed are not used by JSC, so there is no JS perf impact.  However,

        there is a potential DOM perf impact, so I re-ran several of the tests that

        I ran previously and ensured that the perf stay the same which caused me to

        adjust the minLengthToShare.

        * JavaScriptCore.exp:

        * runtime/UString.cpp:

        (JSC::UString::Rep::sharedBuffer):

            Determines if the buffer being shared is big enough before doing so.

            Previously, BaseString::sharedBuffer was called but it would only know

            the length of the base string (BaseString::len) which may not be the same

            as the string being shared (Rep::len).

        (JSC::UString::BaseString::sharedBuffer):

            This is now only be used by Rep::sharedBuffer. which does the length check.

        * runtime/UString.h:

2009-06-12  Dimitri Glazkov  <dglazkov@chromium.org>

        Reviewed by Eric Seidel.

        https://bugs.webkit.org/show_bug.cgi?id=26191

        Remove xmath include in MathExtras.h, because it is not needed and also

        breaks VS2008 builds with TR1 turned on.

        * wtf/MathExtras.h: Removed xmath include.

2009-06-12  Peter Kasting  <pkasting@google.com>

        Reviewed by Eric Seidel.

        * ChangeLog-2007-10-14: Change pseudonym "Don Gibson" to me (was used while Google Chrome was not public); update my email address.

2009-06-12  Kevin Ollivier  <kevino@theolliviers.com>

        wx build fix. Adding JSONObject.cpp to the build.

        * JavaScriptCoreSources.bkl:

2009-06-12  Laszlo Gombos  <laszlo.1.gombos@nokia.com>

        Reviewed by Jan Michael Alonzo.

        [Qt] Fix build break

        https://bugs.webkit.org/show_bug.cgi?id=26340

        * JavaScriptCore.pri: Add JSONObject.cpp to LUT files.

2009-06-11  Oliver Hunt  <oliver@apple.com>

        Reviewed by NOBODY (build fix).

        Lower stringify recursion limit to deal with small windows stack.

        * JavaScriptCore.xcodeproj/project.pbxproj:

        * runtime/JSONObject.cpp:

        (JSC::Stringifier::):

2009-06-11  Laszlo Gombos  <laszlo.1.gombos@nokia.com>

        Reviewed by Holger Freyther.

        Fix compilation warnings

        <https://bugs.webkit.org/show_bug.cgi?id=26015>

        * wtf/ThreadingNone.cpp:

        (WTF::ThreadCondition::wait): Fix compilation warning.

        (WTF::ThreadCondition::timedWait): Ditto.

2009-06-10  Brent Fulgham  <bfulgham@webkit.org>

        Build fix for Windows target.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

          Correct missing </File> tag after @r44550 that prevents the

          project from being loaded in the Visual Studio IDE.

2009-06-09  Gavin Barraclough  <barraclough@apple.com>

        Rubber Stamped by Mark Rowe.

        Tidy up a couple of comments.

        * assembler/ARMv7Assembler.h:

            Fix date in copyright, neaten up a couple of comments.

        * assembler/MacroAssemblerARMv7.h:

            Fix date in copyright.

2009-06-07  Oliver Hunt  <oliver@apple.com>

        Reviewed by Sam Weinig.

        Bug 26249: Support JSON.stringify

        <https://bugs.webkit.org/show_bug.cgi?id=26249>

        Implement JSON.stringify.  This patch handles all the semantics of the ES5

        JSON.stringify function, including replacer functions and arrays and both

        string and numeric gap arguments.

        Currently uses a clamped recursive algorithm basically identical to the spec

        description but with a few minor tweaks for performance and corrected semantics

        discussed in the es-discuss mailing list.

        * DerivedSources.make:

        * GNUmakefile.am:

        * JavaScriptCore.pri:

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:

        * JavaScriptCore.xcodeproj/project.pbxproj:

        * interpreter/CallFrame.h:

        (JSC::ExecState::jsonTable):

        * runtime/CommonIdentifiers.h:

           add toJSON to the list of common identifiers

        * runtime/JSGlobalData.cpp:

        (JSC::JSGlobalData::JSGlobalData):

        (JSC::JSGlobalData::~JSGlobalData):

        * runtime/JSGlobalData.h:

        * runtime/JSGlobalObject.cpp:

        (JSC::JSGlobalObject::reset):

            Add support for the JSON object lookup table

        * runtime/JSONObject.cpp: Added.

        (JSC::):

        (JSC::JSONObject::getOwnPropertySlot):

        (JSC::Stringifier::):

        (JSC::Stringifier::Stringifier):

        (JSC::Stringifier::stringify):

        (JSC::Stringifier::appendString):

        (JSC::Stringifier::StringKeyGenerator::StringKeyGenerator):

        (JSC::Stringifier::StringKeyGenerator::getKey):

        (JSC::Stringifier::IntKeyGenerator::IntKeyGenerator):

        (JSC::Stringifier::IntKeyGenerator::getKey):

            These KeyGenerator classes are used to abstract away the lazy evaluation of keys for

            toJSON and replacer functions.

        (JSC::Stringifier::toJSONValue):

        (JSC::Stringifier::stringifyArray):

        (JSC::Stringifier::stringifyObject):

        (JSC::JSONProtoFuncStringify):

        * runtime/JSONObject.h: Added.

        (JSC::JSONObject:::JSObject):

        (JSC::JSONObject::classInfo):

        (JSC::JSONObject::createStructure):

2009-06-09  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Geoff Garen.

        Enable JIT_OPTIMIZE_CALL & JIT_OPTIMIZE_METHOD_CALLS on ARMv7 platforms.

        These optimizations function correctly with no further changes.

        * wtf/Platform.h:

            Change to enable JIT_OPTIMIZE_CALL & JIT_OPTIMIZE_METHOD_CALLS.

2009-06-09  Gavin Barraclough  <barraclough@apple.com>

        Not Reviewed, build fix.

        * assembler/MacroAssemblerARMv7.h:

2009-06-09  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Geoff Garen.

        Enable JIT_OPTIMIZE_ARITHMETIC on ARMv7 platforms.

        Temporarily split support for 'branchTruncateDoubleToInt32' onto its own switch

        ('supportsFloatingPointTruncate').  See comment in MacroAssemblerARMv7, we need

        to work out wherther we are going to be able to support the current interface on

        all platforms, or whether this should be refactored.

        * assembler/MacroAssemblerARMv7.h:

        (JSC::MacroAssemblerARMv7::supportsFloatingPoint):

            Add implementation of supportsFloatingPointTruncate (returns true).

        (JSC::MacroAssemblerARMv7::supportsFloatingPointTruncate):

            Add implementation of supportsFloatingPointTruncate (returns false).

        (JSC::MacroAssemblerARMv7::loadDouble):

        (JSC::MacroAssemblerARMv7::storeDouble):

        (JSC::MacroAssemblerARMv7::addDouble):

        (JSC::MacroAssemblerARMv7::subDouble):

        (JSC::MacroAssemblerARMv7::mulDouble):

        (JSC::MacroAssemblerARMv7::convertInt32ToDouble):

        (JSC::MacroAssemblerARMv7::branchDouble):

            Implement FP code genertion operations.

        * assembler/MacroAssemblerX86.h:

        (JSC::MacroAssemblerX86::supportsFloatingPointTruncate):

            Add implementation of supportsFloatingPointTruncate (returns true).

        * assembler/MacroAssemblerX86_64.h:

        (JSC::MacroAssemblerX86_64::supportsFloatingPointTruncate):

            Add implementation of supportsFloatingPointTruncate (returns true).

        * jit/JITArithmetic.cpp:

        (JSC::JIT::emit_op_rshift):

            Changed to call supportsFloatingPointTruncate().

        (JSC::JIT::emitSlow_op_rshift):

            Changed to call supportsFloatingPointTruncate().

        * wtf/Platform.h:

            Change to enable JIT_OPTIMIZE_ARITHMETIC.

2009-06-09  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Mark Rowe & Geoff Garen.

        Enable JIT_OPTIMIZE_PROPERTY_ACCESS on ARMv7 platforms.

        Firm up interface for planting load intructions that will be repatched by

        repatchLoadPtrToLEA().  This method should now no longer be applied to just

        any loadPtr instruction.

        * assembler/MacroAssemblerARMv7.h:

        (JSC::MacroAssemblerARMv7::loadPtrWithPatchToLEA):

            Implement loadPtrWithPatchToLEA interface (plants a load with a fixed width address).

        (JSC::MacroAssemblerARMv7::move):

        (JSC::MacroAssemblerARMv7::nearCall):

        (JSC::MacroAssemblerARMv7::call):

        (JSC::MacroAssemblerARMv7::moveWithPatch):

        (JSC::MacroAssemblerARMv7::tailRecursiveCall):

            Switch to use common method 'moveFixedWidthEncoding()' to perform fixed width (often patchable) loads.

        (JSC::MacroAssemblerARMv7::moveFixedWidthEncoding):

            Move an immediate to a register, always plants movT3/movt instruction pair.

        * assembler/MacroAssemblerX86.h:

        (JSC::MacroAssemblerX86::loadPtrWithPatchToLEA):

            Implement loadPtrWithPatchToLEA interface (just a regular 32-bit load on x86).

        * assembler/MacroAssemblerX86_64.h:

        (JSC::MacroAssemblerX86_64::loadPtrWithPatchToLEA):

            Implement loadPtrWithPatchToLEA interface (just a regular 64-bit load on x86_64).

        * jit/JITPropertyAccess.cpp:

        (JSC::JIT::compileGetByIdHotPath):

        (JSC::JIT::emit_op_put_by_id):

        * wtf/Platform.h:

            Change to enable JIT_OPTIMIZE_PROPERTY_ACCESS.

2009-06-08  Gavin Barraclough  <barraclough@apple.com>

        Reviewed by Geoff Garen.

        Enable JS language JIT for ARM thumb2 platforms.  Add ARMv7 specific

        asm & constants, add appropriate configuration switches to Platform.h.

        Landing this disabled until jump linking is completed (see YARR jit patch).

        * assembler/MacroAssemblerARMv7.h:

        (JSC::MacroAssemblerARMv7::load32):

            Fix: should load pointer with ImmPtr not Imm32.

        (JSC::MacroAssemblerARMv7::store32):

            Fix: should load pointer with ImmPtr not Imm32.

        (JSC::MacroAssemblerARMv7::move):

            Fix: When moving an Imm32 that is actually a pointer, should call movT3()