Skip to content
ChangeLog 580 KiB
Newer Older
2014-01-22  Mark Lam  <mark.lam@apple.com>

        Poor man's fast breakpoints for a 2.3x debugger speedup.
        <https://webkit.org/b/122836>

        Reviewed by Geoffrey Garen.

        Previously we gained back some performance (run at baseline JIT speeds)
        when the WebInspector is opened provided no breakpoints are set. This
        was achieved by simply skipping all op_debug callbacks to the debugger
        if no breakpoints are set. If any breakpoints are set, the debugger will
        set a m_needsOpDebugCallbacks flag which causes the callbacks to be
        called, and we don't get the baseline JIT speeds anymore.

        With this patch, we will now track the number of breakpoints set in the
        CodeBlock that they are set in. The LLINT and baseline JIT code will
        check CodeBlock::m_numBreakpoints to determine if the op_debug callbacks
        need to be called. With this, we will only enable op_debug callbacks for
        CodeBlocks that need it i.e. those with breakpoints set in them.

        Debugger::m_needsOpDebugCallbacks is now obsoleted. The LLINT and baseline
        JIT code still needs to check Debugger::m_shouldPause to determine if the
        debugger is in stepping mode and hence, needs op_debug callbacks enabled
        for everything until the debugger "continues" the run and exit stepping
        mode.

        Also in this patch, I fixed a regression in DOM breakpoints which relies
        Debugger::breakProgram() to pause the debugger.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        - Missed accounting for op_debug's new hasBreakpointFlag operand here when
          it was added.
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::hasOpDebugForLineAndColumn):
        - This is needed in Debugger::toggleBreakpoint() to determine if a
          breakpoint falls within a CodeBlock or not. Simply checking the bounds
          of the CodeBlock is insufficient. For example, let's say we have the
          following JS code:

              // begin global scope
              function f1() {
                  function f2() {
                     ... // set breakpoint here.
                  }
              }
              // end global scope

          Using the CodeBlock bounds alone, the breakpoint above will to appear
          to be in the global program CodeBlock, and the CodeBlocks for function
          f1() and f2(). With CodeBlock::hasOpDebugForLineAndColumn() we can
          rule out the global program CodeBlock and f1(), and only apply the
          breakpoint to f2(0 where it belongs.

          CodeBlock::hasOpDebugForLineAndColumn() works by iterating over all
          the opcodes in the CodeBlock to look for op_debug's. For each op_debug,
          it calls CodeBlock::expressionRangeForBytecodeOffset() to do a binary
          seach to get the line and column info for that op_debug. This is a
          N * log(N) algorithm. However, a quick hands on test using the
          WebInspector (with this patch applied) to exercise setting, breaking
          on, and clearing breakpoints, as well as stepping through some code
          shows no noticeable degradation of the user experience compared to the
          baseline without this patch.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::numBreakpoints):
        (JSC::CodeBlock::numBreakpointsOffset):
        (JSC::CodeBlock::addBreakpoint):
        (JSC::CodeBlock::removeBreakpoint):
        (JSC::CodeBlock::clearAllBreakpoints):
        * debugger/Breakpoint.h:
        - defined Breakpoint::unspecifiedColumn so that we can explicitly indicate
          when the WebInspector was setting a line breakpoint and did not provide
          a column value. CodeBlock::hasOpDebugForLineAndColumn() needs this
          information in order to loosen its matching criteria for op_debug
          bytecodes for the specified breakpoint line and column values provided
          by the debugger.

          Previously, we just hijack a 0 value column as an unspecified column.
          However, the WebInspector operates on 0-based ints for column values.
          Hence, 0 should be a valid column value and should not be hijacked to
          mean an unspecified column.

        * debugger/Debugger.cpp:
        (JSC::Debugger::Debugger):
        - added tracking of the VM that the debugger is used with. This is
          needed by Debugger::breakProgram().

          The VM pointer is attained from the first JSGlobalObject that the debugger
          attaches to. When the debugger detaches from the last JSGlobalObject, it
          will nullify its VM pointer to allow a new one to be set on the next
          attach.

          We were always only using each debugger instance with one VM. This change
          makes it explicit with an assert to ensure that all globalObjects that
          the debugger attaches to beongs to the same VM.

        (JSC::Debugger::attach):
        (JSC::Debugger::detach):
        (JSC::Debugger::setShouldPause):

        (JSC::Debugger::registerCodeBlock):
        (JSC::Debugger::unregisterCodeBlock):
        - registerCodeBlock() is responsible for applying pre-existing breakpoints
          to new CodeBlocks being installed. Similarly, unregisterCodeBlock()
          clears the breakpoints.

        (JSC::Debugger::toggleBreakpoint):
        - This is the workhorse function that checks if a breakpoint falls within
          a CodeBlock or not. If it does, then it can either enable or disable
          said breakpoint in the CodeBlock. In the current implementation,
          enabling/disabling the breakpoint simply means incrementing/decrementing
          the CodeBlock's m_numBreakpoints.

        (JSC::Debugger::applyBreakpoints):

        (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor):
        (JSC::Debugger::ToggleBreakpointFunctor::operator()):
        (JSC::Debugger::toggleBreakpoint):
        - Iterates all relevant CodeBlocks and apply the specified breakpoint
          if appropriate. This is called when a new breakpoint is being defined
          by the WebInspector and needs to be applied to an already installed
          CodeBlock.

        (JSC::Debugger::setBreakpoint):
        (JSC::Debugger::removeBreakpoint):
        (JSC::Debugger::hasBreakpoint):
        (JSC::Debugger::ClearBreakpointsFunctor::ClearBreakpointsFunctor):
        (JSC::Debugger::ClearBreakpointsFunctor::operator()):
        (JSC::Debugger::clearBreakpoints):

        (JSC::Debugger::breakProgram):
        - Fixed a regression that broke DOM breakpoints. The issue is that with
          the skipping of op_debug callbacks, we don't always have an updated
          m_currentCallFrame. Normally, m_currentCallFrame is provided as arg
          in the op_debug callback. In this case, we can get the CallFrame* from
          m_vm->topCallFrame.

        (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
        (JSC::Debugger::pauseIfNeeded):
        (JSC::Debugger::willExecuteProgram):
        * debugger/Debugger.h:
        (JSC::Debugger::Debugger):
        (JSC::Debugger::shouldPause):

        * heap/CodeBlockSet.h:
        (JSC::CodeBlockSet::iterate):
        * heap/Heap.h:
        (JSC::Heap::forEachCodeBlock):
        - Added utility to iterate all CodeBlocks in the heap / VM.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::debug):

        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_debug):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_debug):
        * llint/LowLevelInterpreter.asm:
        - These now checks CodeBlock::m_numBreakpoints and Debugger::m_shouldPause
          instead of Debugger::m_needsOpDebugCallbacks.

        * runtime/Executable.cpp:
        (JSC::ScriptExecutable::installCode):

2014-01-22  Myles C. Maxfield  <mmaxfield@apple.com>

        Remove CSS3_TEXT_DECORATION define
        https://bugs.webkit.org/show_bug.cgi?id=127333

        This is required for unprefixing the text-decoration-* CSS properties.

        Reviewed by Simon Fraser.

        * Configurations/FeatureDefines.xcconfig:

2014-01-22  Alexey Proskuryakov  <ap@apple.com>

        Update JS whitespace definition for changes in Unicode 6.3
        https://bugs.webkit.org/show_bug.cgi?id=127450
        <rdar://15863457>

        Reviewed by Oliver Hunt.

        Covered by existing tests when running against a Unicode back-end that supports
        Unicode 6.3 or higher.

        * runtime/JSGlobalObjectFunctions.cpp: (JSC::isStrWhiteSpace): Explicitly allow
        U+180E MONGOLIAN VOWEL SEPARATOR, because we need to keep recognizing all characters
        that used to be whitespace.

2014-01-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Registers used in writeBarrierOnOperand can cause clobbering on some platforms
        https://bugs.webkit.org/show_bug.cgi?id=127357

        Reviewed by Filip Pizlo.

        Some platforms use t0 and t1 for their first two arguments, so using those to load the 
        cell for the write barrier is a bad idea because it will get clobbered.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2014-01-21  Mark Rowe  <mrowe@apple.com>

        Mac production build fix.

        Move the shell script build phase to copy jsc into JavaScriptCore.framework
        out of the jsc target and in to the All target so that it's not run during
        production builds. Xcode appears to the parent directories of paths referenced
        in the Output Files of the build phase, which leads to problems when the
        SYMROOT for the JavaScriptCore framework and the jsc executables are later merged.

        I've also fixed the path to the Resources folder in the script while I'm here.
        On iOS the framework bundle is shallow so the correct destination is Resources/
        rather than Versions/A/Resources. This is handled by tweaking the
        JAVASCRIPTCORE_RESOURCES_DIR configuration setting to be relative rather than
        a complete path so we can reuse it in the script. The references in JSC.xcconfig
        and ToolExecutable.xcconfig are updated to prepend JAVASCRIPTCORE_FRAMEWORKS_DIR
        to preserve their former values.

        * Configurations/Base.xcconfig:
        * Configurations/JSC.xcconfig:
        * Configurations/ToolExecutable.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

2014-01-19  Andreas Kling  <akling@apple.com>

        JSC Parser: Shrink BindingNode.
        <https://webkit.org/b/127253>

        The "divot" and "end" source locations are always identical for
        BindingNodes, so store only "start" and "end" instead.

        1.19 MB progression on Membuster3.

        Reviewed by Geoff Garen.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BindingNode::bindValue):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createBindingLocation):
        * parser/NodeConstructors.h:
        (JSC::BindingNode::create):
        (JSC::BindingNode::BindingNode):
        * parser/Nodes.h:
        (JSC::BindingNode::divotStart):
        (JSC::BindingNode::divotEnd):
        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::createBindingPattern):
        * parser/SyntaxChecker.h:
        (JSC::SyntaxChecker::operatorStackPop):

2014-01-20  Filip Pizlo  <fpizlo@apple.com>

        op_captured_mov and op_new_captured_func in UnlinkedCodeBlocks should use the IdentifierMap instead of the strings directly
        https://bugs.webkit.org/show_bug.cgi?id=127311
        <rdar://problem/15853958>

        Reviewed by Andreas Kling.
        
        This makes UnlinkedCodeBlocks use 32-bit instruction streams again.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/UnlinkedCodeBlock.h:
        (JSC::UnlinkedInstruction::UnlinkedInstruction):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::addVar):
        (JSC::BytecodeGenerator::emitInitLazyRegister):
        (JSC::BytecodeGenerator::createArgumentsIfNecessary):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::watchableVariable):
        (JSC::BytecodeGenerator::hasWatchableVariable):

2014-01-20  Mark Lam  <mark.lam@apple.com>

        Removing CodeBlock::opDebugBytecodeOffsetForLineAndColumn() and friends.
        <https://webkit.org/b/127321>

        Reviewed by Geoffrey Garen.

        We're changing plans and will be going with CodeBlock level breakpoints
        instead of bytecode level breakpoints. As a result, we no longer need
        the services of CodeBlock::opDebugBytecodeOffsetForLineAndColumn() (and
        friends). This patch will remove that unused code.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/LineColumnInfo.h: Removed.
        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo):
        * bytecode/UnlinkedCodeBlock.h:

2014-01-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        CodeBlockSet::traceMarked doesn't need to visit the ownerExecutable
        https://bugs.webkit.org/show_bug.cgi?id=127301

        Reviewed by Oliver Hunt.

        We used to just call CodeBlock::visitAggregate, but now we call visitChildren 
        on the ownerExecutable, which is unnecessary. 

        * heap/CodeBlockSet.cpp:
        (JSC::CodeBlockSet::traceMarked):

andersca@apple.com's avatar
andersca@apple.com committed
2014-01-20  Anders Carlsson  <andersca@apple.com>

        Fix build.

        * heap/BlockAllocator.h:

2014-01-20  Anders Carlsson  <andersca@apple.com>

        Stop using ThreadCondition in BlockAllocator
        https://bugs.webkit.org/show_bug.cgi?id=126313

        Reviewed by Sam Weinig.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::~BlockAllocator):
        (JSC::BlockAllocator::waitForDuration):
        (JSC::BlockAllocator::blockFreeingThreadMain):
        * heap/BlockAllocator.h:
        (JSC::BlockAllocator::deallocate):

2014-01-19  Anders Carlsson  <andersca@apple.com>

        Convert GCThreadSharedData over to STL threading primitives
        https://bugs.webkit.org/show_bug.cgi?id=127256

        Reviewed by Andreas Kling.

        * heap/GCThread.cpp:
        (JSC::GCThread::waitForNextPhase):
        (JSC::GCThread::gcThreadMain):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::startNextPhase):
        (JSC::GCThreadSharedData::endCurrentPhase):
        (JSC::GCThreadSharedData::didStartMarking):
        (JSC::GCThreadSharedData::didFinishMarking):
        * heap/GCThreadSharedData.h:
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drainFromShared):

2014-01-18  Andreas Kling  <akling@apple.com>

        CodeBlock: Size m_callLinkInfos and m_byValInfos to fit earlier.
        <https://webkit.org/b/127239>

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::setNumberOfByValInfos):
        (JSC::CodeBlock::setNumberOfCallLinkInfos):

            Use resizeToFit() instead of grow() for these vectors, since
            we know the final size here.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::shrinkToFit):

            No need to shrink here anymore. We were not even shrinking
            m_byValInfo before!

2014-01-18  Andreas Kling  <akling@apple.com>

        CodeBlock: Size m_function{Exprs,Decls} to fit from creation.
        <https://webkit.org/b/127238>

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):

            Use resizeToFit() instead of grow() for m_functionExprs and
            m_functionDecls since we know they will never change size.

        (JSC::CodeBlock::shrinkToFit):

            No need to shrink them here anymore.

2014-01-18  Andreas Kling  <akling@apple.com>

        Remove unused CodeBlock::m_additionalIdentifiers member.
        <https://webkit.org/b/127237>

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.h:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::shrinkToFit):

            Remove m_additionalIdentifiers, nothing uses it.

2014-01-18  Andreas Kling  <akling@apple.com>

        Remove two unused CodeBlock functions.
        <https://webkit.org/b/127235>

        Kill copyPostParseDataFrom() and copyPostParseDataFromAlternative()
        since they are not used.

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.cpp:
        * bytecode/CodeBlock.h:

2014-01-18  Andreas Kling  <akling@apple.com>

        CodeBlock: Size m_exceptionHandlers to fit from creation.
        <https://webkit.org/b/127234>

        Avoid allocation churn for CodeBlock::m_exceptionHandlers.

        Reviewed by Anders Carlsson.

        * bytecode/CodeBlock.h:

            Removed unused CodeBlock::allocateHandlers() function.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):

            Use resizeToFit() instead of grow() for m_exceptionHandlers
            since we know it's never going to change size.

        (JSC::CodeBlock::shrinkToFit):

            No need to shrink m_exceptionHandlers here since it's already
            the perfect size.

2014-01-18  Mark Lam  <mark.lam@apple.com>

        Add a hasBreakpointFlag arg to the op_debug bytecode.
        https://bugs.webkit.org/show_bug.cgi?id=127230.

        Reviewed by Geoffrey Garen.

        This is in anticipation of upcoming changes to support bytecode level
        breakpoints. This patch adds the flag to the op_debug bytecode and
        initializes it, but does not use it yet.

        * bytecode/Opcode.h:
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):
        * llint/LowLevelInterpreter.asm:

2014-01-18  Alberto Garcia  <berto@igalia.com>

        JavaScriptCore uses PLATFORM(MAC) when it means OS(DARWIN)
        https://bugs.webkit.org/show_bug.cgi?id=99683

        Reviewed by Anders Carlsson.

        * jit/ThunkGenerators.cpp:
        * tools/CodeProfile.cpp:
        (JSC::symbolName):
        (JSC::CodeProfile::sample):

2014-01-18  Anders Carlsson  <andersca@apple.com>

        Remove ENABLE_THREADED_HTML_PARSER defines everywhere
        https://bugs.webkit.org/show_bug.cgi?id=127225

        Reviewed by Andreas Kling.

        This concludes the removal of over 8.8 million lines of threaded parser code.

        * Configurations/FeatureDefines.xcconfig:

2014-01-18  Mark Lam  <mark.lam@apple.com>

        Adding UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn()..
        https://bugs.webkit.org/show_bug.cgi?id=127127.

        Reviewed by Geoffrey Garen.

        In order to implement bytecode level breakpoints, we need a mechanism
        for computing the best fit op_debug bytecode offset for any valid given
        line and column value in the source. The "best fit" op_debug bytecode
        in this case is defined below in the comment for
        UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn().

        * GNUmakefile.list.am:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::opDebugBytecodeOffsetForLineAndColumn):
        - Convert the line and column to unlinked line and column values and
          pass them to UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn()
          to do the real work.

        * bytecode/CodeBlock.h:
        * bytecode/LineColumnInfo.h: Added.
        (JSC::LineColumnInfo::operator <):
        (JSC::LineColumnInfo::LineColumnPair::LineColumnPair):
        (JSC::LineColumnInfo::operator ==):
        (JSC::LineColumnInfo::operator !=):
        (JSC::LineColumnInfo::operator <=):
        (JSC::LineColumnInfo::operator >):
        (JSC::LineColumnInfo::operator >=):
        * bytecode/LineInfo.h: Removed.

        * bytecode/UnlinkedCodeBlock.cpp:
        (JSC::UnlinkedCodeBlock::decodeExpressionRangeLineAndColumn):
        - Factored this out of expressionRangeForBytecodeOffset() so that it can
          be called from multiple places.
        (JSC::dumpLineColumnEntry):
        (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo):
        (JSC::UnlinkedCodeBlock::dumpOpDebugLineColumnInfoList):
        - Some dumpers for debugging use only.
        (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
        (JSC::UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn):
        - Finds the earliest op_debug bytecode whose line and column matches the
          specified line and column values. If an exact match is not found, then
          finds the nearest op_debug bytecode that precedes the specified line
          and column values. If there are more than one op_debug at that preceding
          line and column value, then the earliest of those op_debug bytecodes will
          be be selected. The offset of the selected bytecode will be returned.

          We want the earliest one because when we have multiple op_debug bytecodes
          that map to a given line and column, a debugger user would expect to break
          on the first one and step through the rest thereafter if needed.

        (JSC::compareLineColumnInfo):
        (JSC::UnlinkedCodeBlock::opDebugLineColumnInfoList):
        - Creates the sorted opDebugLineColumnInfoList on demand. This list is
          stored in the UnlinkedCodeBlock's rareData.
        * bytecode/UnlinkedCodeBlock.h:

2014-01-18  Zan Dobersek  <zdobersek@igalia.com>

        Inspector scripts are not compatible with Python v3
        https://bugs.webkit.org/show_bug.cgi?id=127128

        Reviewed by Benjamin Poulain.

        * inspector/scripts/generate-combined-inspector-json.py: Turn print statements into print function calls.
        * inspector/scripts/jsmin.py: Try importing the StringIO class from the StringIO module (which will work for
        Python v2) or, on import error, import the class from the io module (which will work for Python v3).

2014-01-17  Anders Carlsson  <andersca@apple.com>

        String::is8Bit() crashes if m_impl is null, handle this.

        * API/OpaqueJSString.h:
        (OpaqueJSString::OpaqueJSString):

2014-01-17  Anders Carlsson  <andersca@apple.com>

        Try to fix the Windows build.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::~OpaqueJSString):
        (OpaqueJSString::characters):
        * API/OpaqueJSString.h:
        (OpaqueJSString::OpaqueJSString):

2014-01-17  Anders Carlsson  <andersca@apple.com>

        Get rid of OpaqueJSString::deprecatedCharacters()
        https://bugs.webkit.org/show_bug.cgi?id=127161

        Reviewed by Sam Weinig.

        Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra
        code paths for the 8-bit cases.
        
        Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer.
        Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr
        is called and the backing string is 8-bit.
        
        This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before.
        (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it
        causing an unsafe upconversion to a 16-bit string).

        * API/JSStringRef.cpp:
        (JSStringGetCharactersPtr):
        Call OpaqueJSString::characters.

        (JSStringGetUTF8CString):
        Add a code path that handles 8-bit strings.

        (JSStringIsEqual):
        Call OpaqueJSString::equal.

        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        Reformat the code to use an early return instead of putting most of the code inside the body of an if statement.

        (JSStringCopyCFString):
        Create an 8-bit CFStringRef if possible.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):
        Use nullptr.

        (OpaqueJSString::~OpaqueJSString):
        Free m_characters.

        (OpaqueJSString::characters):
        Do the up-conversion and store the result in m_characters.

        (OpaqueJSString::equal):
        New helper function.

        * API/OpaqueJSString.h:
        (OpaqueJSString::is8Bit):
        New function that returns whether a string is 8-bit or not.

        (OpaqueJSString::characters8):
        (OpaqueJSString::characters16):
        Add getters.

2014-01-17  Peter Molnar  <pmolnar.u-szeged@partner.samsung.com>

        Remove workaround for compilers not supporting deleted functions
        https://bugs.webkit.org/show_bug.cgi?id=127166

        Reviewed by Andreas Kling.

        * inspector/InspectorAgentRegistry.h:

2014-01-17  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r162185, r162186, and r162187.
        http://trac.webkit.org/changeset/162185
        http://trac.webkit.org/changeset/162186
        http://trac.webkit.org/changeset/162187
        https://bugs.webkit.org/show_bug.cgi?id=127164

        Broke JSStringCreateWithCharactersNoCopy, as evidenced by a
        JSC API test (Requested by ap on #webkit).

        * API/JSStringRef.cpp:
        (JSStringGetCharactersPtr):
        (JSStringGetUTF8CString):
        (JSStringIsEqual):
        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        (JSStringCopyCFString):
        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):
        (OpaqueJSString::identifier):
        * API/OpaqueJSString.h:
        (OpaqueJSString::create):
        (OpaqueJSString::characters):
        (OpaqueJSString::deprecatedCharacters):
        (OpaqueJSString::OpaqueJSString):

2014-01-16  Anders Carlsson  <andersca@apple.com>

        Export OpaqueJSString destructor.

        * API/OpaqueJSString.h:

andersca@apple.com's avatar
andersca@apple.com committed
2014-01-16  Anders Carlsson  <andersca@apple.com>

        Build fix.

        * API/OpaqueJSString.h:

2014-01-16  Anders Carlsson  <andersca@apple.com>

        Get rid of OpaqueJSString::deprecatedCharacters()
        https://bugs.webkit.org/show_bug.cgi?id=127161

        Reviewed by Sam Weinig.

        Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra
        code paths for the 8-bit cases.
        
        Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer.
        Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr
        is called. This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before.
        (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it
        causing an unsafe upconversion to a 16-bit string).

        * API/JSStringRef.cpp:
        (JSStringGetCharactersPtr):
        Call OpaqueJSString::characters.

        (JSStringGetUTF8CString):
        Add a code path that handles 8-bit strings.

        (JSStringIsEqual):
        Call OpaqueJSString::equal.

        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        Reformat the code to use an early return instead of putting most of the code inside the body of an if statement.

        (JSStringCopyCFString):
        Create an 8-bit CFStringRef if possible.

        * API/OpaqueJSString.cpp:
        (OpaqueJSString::create):
        Use nullptr.

        (OpaqueJSString::~OpaqueJSString):
        Free m_characters.

        (OpaqueJSString::characters):
        Do the up-conversion and store the result in m_characters.

        (OpaqueJSString::equal):
        New helper function.

        * API/OpaqueJSString.h:
        (OpaqueJSString::is8Bit):
        New function that returns whether a string is 8-bit or not.

        (OpaqueJSString::characters8):
        (OpaqueJSString::characters16):
        Add getters.

2014-01-16  Anders Carlsson  <andersca@apple.com>

        Change all uses of FINAL to final now that all our compilers support it
        https://bugs.webkit.org/show_bug.cgi?id=127142

        Reviewed by Benjamin Poulain.

        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.h:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.h:
        * inspector/scripts/CodeGeneratorInspector.py:
        (Generator.go):
        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/JSPromiseReaction.cpp:

2014-01-16  Oliver Hunt  <oliver@apple.com>

        throwing an objc object (or general binding object) triggers an assertion
        https://bugs.webkit.org/show_bug.cgi?id=127146

        Reviewed by Alexey Proskuryakov.

        This is simply a bogus assertion as we can't guarantee a bindings object
        won't intercept assignment to .stack

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwind):

2014-01-16  Peter Molnar  <pmolnar.u-szeged@partner.samsung.com>

        Remove workaround for compilers not supporting explicit override control
        https://bugs.webkit.org/show_bug.cgi?id=127111

        Reviewed by Anders Carlsson.

        Now all compilers support explicit override control, this workaround can be removed.

        * API/JSAPIWrapperObject.mm:
        * API/JSCallbackObject.h:
        * API/JSManagedValue.mm:
        * API/JSScriptRef.cpp:
        * bytecode/CodeBlock.h:
        * bytecode/CodeBlockJettisoningWatchpoint.h:
        * bytecode/ProfiledCodeBlockJettisoningWatchpoint.h:
        * bytecode/StructureStubClearingWatchpoint.h:
        * dfg/DFGArrayifySlowPathGenerator.h:
        * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
        * dfg/DFGFailedFinalizer.h:
        * dfg/DFGJITCode.h:
        * dfg/DFGJITFinalizer.h:
        * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
        * dfg/DFGSlowPathGenerator.h:
        * dfg/DFGSpeculativeJIT64.cpp:
        * heap/Heap.h:
        * heap/IncrementalSweeper.h:
        * heap/SuperRegion.h:
        * inspector/InspectorValues.h:
        * inspector/JSGlobalObjectInspectorController.h:
        * inspector/agents/InspectorAgent.h:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspectorDebuggableConnection.h:
        * inspector/scripts/CodeGeneratorInspector.py:
        (Generator.go):
        * jit/ClosureCallStubRoutine.h:
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        * jit/GCAwareJITStubRoutine.h:
        * jit/JITCode.h:
        * jit/JITToDFGDeferredCompilationCallback.h:
        * parser/Nodes.h:
        * parser/SourceProvider.h:
        * runtime/DataView.h:
        * runtime/GCActivityCallback.h:
        * runtime/GenericTypedArrayView.h:
        * runtime/JSGlobalObjectDebuggable.h:
        * runtime/JSPromiseReaction.cpp:
        * runtime/RegExpCache.h:
        * runtime/SimpleTypedArrayController.h:
        * runtime/SymbolTable.h:
        * runtime/WeakMapData.h:

2014-01-15  Joseph Pecoraro  <pecoraro@apple.com>

        [iOS] Clean up REMOTE_INSPECTOR code in OpenSource after the iOS merge
        https://bugs.webkit.org/show_bug.cgi?id=127069

        Reviewed by Timothy Hatcher.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        Export XPCConnection because it is needed by RemoteInspector.h.

        * inspector/remote/RemoteInspectorXPCConnection.h:
        * inspector/remote/RemoteInspector.h:
        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::startDisabled):
        (Inspector::RemoteInspector::shared):
        Allow RemoteInspector singleton to start disabled.

2014-01-15  Brian Burg  <bburg@apple.com>

        Web Inspector: capture probe samples on the backend
        https://bugs.webkit.org/show_bug.cgi?id=126668

        Reviewed by Joseph Pecoraro.

        Add the 'probe' breakpoint action to the protocol. Change the setBreakpoint
        commands to return a list of assigned breakpoint action identifiers
        Add a type for breakpoint action identifiers. Add an event for sending
        captured probe samples to the inspector frontend.

        * inspector/protocol/Debugger.json:

2014-01-10  Mark Hahnenberg  <mhahnenberg@apple.com>

        Copying should be generational
        https://bugs.webkit.org/show_bug.cgi?id=126555

        Reviewed by Geoffrey Garen.

        This patch adds support for copying to our generational collector. Eden collections 
        always trigger copying. Full collections use our normal fragmentation-based heuristics.

        The way this works is that the CopiedSpace now has the notion of an old generation set of CopiedBlocks
        and a new generation of CopiedBlocks. During each mutator cycle new CopiedSpace allocations reside
        in the new generation. When a collection occurs, those blocks are moved to the old generation.

        One key thing to remember is that both new and old generation objects in the MarkedSpace can
        refer to old or new generation allocations in CopiedSpace. This is why we must fire write barriers 
        when assigning to an old (MarkedSpace) object's Butterfly.

        * heap/CopiedAllocator.h:
        (JSC::CopiedAllocator::tryAllocateDuringCopying):
        * heap/CopiedBlock.h:
        (JSC::CopiedBlock::CopiedBlock):
        (JSC::CopiedBlock::didEvacuateBytes):
        (JSC::CopiedBlock::isOld):
        (JSC::CopiedBlock::didPromote):
        * heap/CopiedBlockInlines.h:
        (JSC::CopiedBlock::reportLiveBytes):
        (JSC::CopiedBlock::reportLiveBytesDuringCopying):
        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::CopiedSpace):
        (JSC::CopiedSpace::~CopiedSpace):
        (JSC::CopiedSpace::init):
        (JSC::CopiedSpace::tryAllocateOversize):
        (JSC::CopiedSpace::tryReallocateOversize):
        (JSC::CopiedSpace::doneFillingBlock):
        (JSC::CopiedSpace::didStartFullCollection):
        (JSC::CopiedSpace::doneCopying):
        (JSC::CopiedSpace::size):
        (JSC::CopiedSpace::capacity):
        (JSC::CopiedSpace::isPagedOut):
        * heap/CopiedSpace.h:
        (JSC::CopiedSpace::CopiedGeneration::CopiedGeneration):
        * heap/CopiedSpaceInlines.h:
        (JSC::CopiedSpace::contains):
        (JSC::CopiedSpace::recycleEvacuatedBlock):
        (JSC::CopiedSpace::allocateBlock):
        (JSC::CopiedSpace::startedCopying):
        * heap/CopyVisitor.cpp:
        (JSC::CopyVisitor::copyFromShared):
        * heap/CopyVisitorInlines.h:
        (JSC::CopyVisitor::allocateNewSpace):
        (JSC::CopyVisitor::allocateNewSpaceSlow):
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::didStartCopying):
        * heap/Heap.cpp:
        (JSC::Heap::copyBackingStores):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::copyLater):
        * heap/TinyBloomFilter.h:
        (JSC::TinyBloomFilter::add):

2014-01-14  Mark Lam  <mark.lam@apple.com>

        ASSERTION FAILED: !hasError() in JSC::Parser<LexerType>::createSavePoint().
        https://bugs.webkit.org/show_bug.cgi?id=126990.

        Reviewed by Geoffrey Garen.

        * parser/Parser.cpp:
        (JSC::Parser<LexerType>::parseConstDeclarationList):
        - We were missing an error check after attempting to parse an initializer
          expression. This is now fixed.

2014-01-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: For Remote Inspection link WebProcess's to their parent UIProcess
        https://bugs.webkit.org/show_bug.cgi?id=126995

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::listingForDebuggable):
        For each WebView, list the parent process. Listing the parent per WebView
        is already supported back when we supported processes that could host WebViews
        for multiple applications.

        * inspector/remote/RemoteInspectorConstants.h:
        Add a separate key for the bundle identifier, separate from application identifier.

        * inspector/remote/RemoteInspectorDebuggable.cpp:
        (Inspector::RemoteInspectorDebuggable::info):
        * inspector/remote/RemoteInspectorDebuggable.h:
        (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo):
        (Inspector::RemoteInspectorDebuggableInfo::hasParentProcess):
        If a RemoteInspectorDebuggable has a non-zero parent process identifier
        it is a proxy for the parent process.

2014-01-14  Brian J. Burg  <burg@cs.washington.edu>

        Add ENABLE(WEB_REPLAY) feature flag to the build system
        https://bugs.webkit.org/show_bug.cgi?id=126949

        Reviewed by Joseph Pecoraro.

        * Configurations/FeatureDefines.xcconfig:

2014-01-14  Peter Molnar  <pmolnar.u-szeged@partner.samsung.com>

        [EFL] FTL buildfix, add missing includes
        https://bugs.webkit.org/show_bug.cgi?id=126641

        Reviewed by Csaba Osztrogonác.

        * ftl/FTLOSREntry.cpp:
        * ftl/FTLOSRExitCompiler.cpp:

2014-01-14  Joseph Pecoraro  <pecoraro@apple.com>

        Web Inspector: RemoteInspector::updateDebuggable may miss a push
        https://bugs.webkit.org/show_bug.cgi?id=126965

        Reviewed by Timothy Hatcher.

        * inspector/remote/RemoteInspector.mm:
        (Inspector::RemoteInspector::updateDebuggable):
        Always push an update. If a debuggable went from allowed to
        not allowed, we would have missed pushing an update.

2014-01-13  Mark Hahnenberg  <mhahnenberg@apple.com>

        Performance regression on dromaeo due to generational marking
        https://bugs.webkit.org/show_bug.cgi?id=126901

        Reviewed by Oliver Hunt.

        We were seeing some performance regression with ENABLE_GGC == 0, so this patch
        ifdefs out more things to get rid of the additional overhead.

        * heap/Heap.cpp:
        (JSC::Heap::markRoots):
        (JSC::Heap::writeBarrier):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::clearMarks):
        (JSC::MarkedBlock::clearMarksWithCollectionType):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::resetAllocators):
        * heap/MarkedSpace.h:
        (JSC::MarkedSpace::didAllocateInBlock):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::reportExtraMemoryUsage):

2014-01-13  Brian Burg  <bburg@apple.com>

        Web Inspector: protocol generator should support integer-typed declarations
        https://bugs.webkit.org/show_bug.cgi?id=126828

        Reviewed by Joseph Pecoraro.