1. 27 Mar, 2013 7 commits
  2. 26 Mar, 2013 6 commits
  3. 25 Mar, 2013 3 commits
    • tkent@chromium.org's avatar
      Rename ENABLE_INPUT_TYPE_DATETIME · 866ba1bd
      tkent@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113254
      
      Reviewed by Kentaro Hara.
      
      Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE.
      Actually I'd like to remove the code, but we shouldn't remove it yet
      because we shipped products with it on some platforms.
      
      .:
      
      * Source/autotools/SetupWebKitFeatures.m4:
      * Source/cmake/WebKitFeatures.cmake:
      * Source/cmakeconfig.h.cmake:
      
      Source/JavaScriptCore:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebCore:
      
      * Configurations/FeatureDefines.xcconfig:
      * bindings/generic/RuntimeEnabledFeatures.cpp:
      (WebCore):
      * bindings/generic/RuntimeEnabledFeatures.h:
      (RuntimeEnabledFeatures):
      * css/html.css:
      * html/DateTimeInputType.cpp:
      * html/DateTimeInputType.h:
      * html/InputType.cpp:
      (WebCore::createInputTypeFactoryMap):
      
      Source/WebKit/blackberry:
      
      * WebCoreSupport/AboutDataEnableFeatures.in:
      
      Source/WebKit/chromium:
      
      * src/WebRuntimeFeatures.cpp:
      (WebKit::WebRuntimeFeatures::enableInputTypeDateTime):
      (WebKit::WebRuntimeFeatures::isInputTypeDateTimeEnabled):
      * tests/WebViewTest.cpp:
      
      Source/WebKit/mac:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebKit2:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WTF:
      
      * wtf/FeatureDefines.h:
      
      Tools:
      
      * Scripts/webkitperl/FeatureList.pm:
      * qmake/mkspecs/features/features.pri:
      
      WebKitLibraries:
      
      * win/tools/vsprops/FeatureDefines.props:
      * win/tools/vsprops/FeatureDefines.vsprops:
      * win/tools/vsprops/FeatureDefinesCairo.props:
      * win/tools/vsprops/FeatureDefinesCairo.vsprops:
      
      LayoutTests:
      
      * platform/chromium/TestExpectations:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146847 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      866ba1bd
    • mark.lam@apple.com's avatar
      Offlineasm cloop backend compiles op+branch incorrectly. · 4b3334d4
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113146.
      
      Reviewed by Geoffrey Garen.
      
      * dfg/DFGRepatch.h:
      (JSC::DFG::dfgResetGetByID):
      (JSC::DFG::dfgResetPutByID):
      - These functions never return when the DFG is dsiabled, not just when
        asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT
        to NO_RETURN.
      * llint/LLIntOfflineAsmConfig.h:
      - Added some #defines needed to get the cloop building again.
      * offlineasm/cloop.rb:
      - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to
        emit code that unconditionally executes the specified operation before
        doing the conditional branch.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146831 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4b3334d4
    • mhahnenberg@apple.com's avatar
      JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES · 5b60e590
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113236
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore:
      
      * runtime/JSObject.cpp:
      (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types.
      
      LayoutTests:
      
      New test case that tests calling Object.freeze on Array.prototype.
      
      * fast/js/enter-dictionary-indexing-mode-with-blank-indexing-type-expected.txt: Added.
      * fast/js/enter-dictionary-indexing-mode-with-blank-indexing-type.html: Added.
      * fast/js/script-tests/enter-dictionary-indexing-mode-with-blank-indexing-type.js: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146829 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5b60e590
  4. 24 Mar, 2013 1 commit
    • mhahnenberg@apple.com's avatar
      HandleSet should use HeapBlocks for storing handles · 94b9c7da
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113145
      
      Reviewed by Geoffrey Garen.
      
      * GNUmakefile.list.am: Build project changes.
      * JavaScriptCore.gypi: Ditto.
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
      * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
      * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are 
      too many block types to include them all in the name now.
      (JSC::BlockAllocator::BlockAllocator):
      * heap/BlockAllocator.h:
      (BlockAllocator): Add the appropriate override for regionSetFor.
      (JSC::WeakBlock):
      (JSC::MarkStackSegment):
      (JSC::HandleBlock):
      * heap/HandleBlock.h: Added.
      (HandleBlock): New class for HandleBlocks.
      (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows
      us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it
      in the HandleNode.
      (JSC::HandleBlock::handleSet): Getter.
      * heap/HandleBlockInlines.h: Added.
      (JSC::HandleBlock::create):
      (JSC::HandleBlock::HandleBlock):
      (JSC::HandleBlock::payloadEnd):
      (JSC::HandleBlock::payload):
      (JSC::HandleBlock::nodes):
      (JSC::HandleBlock::nodeAtIndex):
      (JSC::HandleBlock::nodeCapacity):
      * heap/HandleSet.cpp:
      (JSC::HandleSet::~HandleSet): 
      (JSC::HandleSet::grow):
      * heap/HandleSet.h:
      (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be 
      used by HandleBlock.
      (HandleSet): Add a typedef so that Node refers to the new HandleNode class.
      (JSC::HandleSet::toHandle):
      (JSC::HandleSet::toNode):
      (JSC::HandleSet::allocate):
      (JSC::HandleSet::deallocate):
      (JSC::HandleNode::HandleNode):
      (JSC::HandleNode::slot):
      (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup 
      the HandleSet.
      (JSC::HandleNode::setPrev):
      (JSC::HandleNode::prev):
      (JSC::HandleNode::setNext):
      (JSC::HandleNode::next):
      (JSC::HandleSet::forEachStrongHandle):
      * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146734 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      94b9c7da
  5. 22 Mar, 2013 15 commits
    • ddkilzer@apple.com's avatar
      BUILD FIX (r145119): Make JSValue* properties default to (assign) · 09c84194
      ddkilzer@apple.com authored
      <rdar://problem/13380794>
      
      Reviewed by Mark Hahnenberg.
      
      Fixes the following build failures:
      
          Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
          @property JSValue *onclick;
          ^
          Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
          Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
          @property JSValue *weakOnclick;
          ^
          Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
          4 errors generated.
      
      * API/tests/testapi.mm: Default to (assign) for JSValue*
      properties.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146712 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      09c84194
    • rniwa@webkit.org's avatar
      testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac · d9579552
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=113125
      
      Reviewed by Mark Hahnenberg
      
      Remove the test added in r146682 as it's now failing on Mac.
      This is the test that was causing a compilation failure on Windows.
      
      * API/tests/testapi.c:
      (main):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146711 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d9579552
    • rniwa@webkit.org's avatar
      Fix the typo: WIN -> WINDOWS. · 223ccfb4
      rniwa@webkit.org authored
      * API/tests/testapi.c:
      (main):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146708 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      223ccfb4
    • rniwa@webkit.org's avatar
      I really can't figure out what's wrong with this one. · 365e1468
      rniwa@webkit.org authored
      Temporarily disable the test added by r146682 on Windows since it doesn't compile.
      
      * API/tests/testapi.c:
      (main):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146707 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      365e1468
    • rniwa@webkit.org's avatar
      Another build fix (after r146693) for r146682. · 9af4c5c4
      rniwa@webkit.org authored
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
      * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146698 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9af4c5c4
    • roger_fong@apple.com's avatar
      Unreviewed. AppleWin build fix. · 6b86b24f
      roger_fong@apple.com authored
      * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
      * JavaScriptCore.vcxproj/copy-files.cmd:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146693 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6b86b24f
    • mhahnenberg@apple.com's avatar
      -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled · 01534124
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113054
      
      Reviewed by Geoffrey Garen.
      
      * API/tests/testapi.mm:
      (-[TinyDOMNode dealloc]):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146688 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      01534124
    • mhahnenberg@apple.com's avatar
      opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData · ad21fd2f
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113086
      
      Reviewed by Geoffrey Garen.
      
      opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to 
      share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause 
      a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move 
      this cache to JSGlobalObject where it belongs and where it won't cause memory leaks.
      
      * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function.
      * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data.
      (OpaqueJSClass::contextData):
      * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies.
      * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts
      doesn't cause leaks of the original global object.
      (leakFinalize):
      (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking
      objects and keeping them alive, ruining the test result.
      (testLeakingPrototypesAcrossContexts):
      (main):
      * API/tests/testapi.mm: extern "C" this so we can continue using it here.
      * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff.
      (JSC::JSGlobalData::~JSGlobalData):
      * runtime/JSGlobalData.h:
      (JSGlobalData):
      * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that 
      clients who don't use the C API don't have to pay the memory cost of this extra HashMap.
      (JSGlobalObject):
      (JSGlobalObjectRareData):
      (JSC::JSGlobalObject::opaqueJSClassData):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146682 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ad21fd2f
    • mrobinson@webkit.org's avatar
      [GTK] Add support for building the WebCore bindings to the gyp build · 4bf12a55
      mrobinson@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112638
      
      Reviewed by Nico Weber.
      
      Source/JavaScriptCore:
      
      * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct
      dependents and fix the indentation of the libjavascriptcore target.
      
      Source/WebCore:
      
      Add targets, actions, and rules for building the WebCore bindings. This is
      the first part of the WebCoreGTK build.
      
      * WebCore.gyp/ConvertFileToHeaderWithCharacterArray.gypi: Added.
      * WebCore.gyp/MakeNames.gypi: Added.
      * WebCore.gyp/WebCoreGTK.gyp: Added WebCore bindings build. This has been adapted
      from the Chromium build.
      * WebCore.gypi: Updated list of derived sources files and added a parameter
      for adjusting the location of the built files. We don't want to force the
      Mac build to change, but we'd still like to reuse the scripts that the
      Chromium build uses.
      
      Source/WebKit/gtk:
      
      * gyp/Configuration.gypi.in: Added options for enabling SVG and setting the location of
      the WebCore derived sources.
      * gyp/run-gyp: Include the gyp scripts directory on the Python path and make the WebCoreGTK
      gyp file the default for the build.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146677 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4bf12a55
    • fpizlo@apple.com's avatar
      Fix some minor issues in the DFG's profiling of heap accesses · c5c0fa4e
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113010
      
      Reviewed by Goeffrey Garen.
              
      1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.
      
      2) If a CodeBlock clears a structure stub during GC, it should record this, and
      the DFG should prefer to not inline that access (i.e. treat it as if it had an
      exit site).
      
      3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
      but it chose not to, then assume that it will take slow path.
      
      4) If we frequently exited because of a structure check on a weak constant,
      don't try to inline that access in the future.
      
      5) Treat all exits that were counted as being frequent.
              
      81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::finalizeUnconditionally):
      (JSC):
      (JSC::CodeBlock::resetStubDuringGCInternal):
      (JSC::CodeBlock::reoptimize):
      (JSC::CodeBlock::jettison):
      (JSC::ProgramCodeBlock::jettisonImpl):
      (JSC::EvalCodeBlock::jettisonImpl):
      (JSC::FunctionCodeBlock::jettisonImpl):
      (JSC::CodeBlock::tallyFrequentExitSites):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      (JSC::CodeBlock::tallyFrequentExitSites):
      (ProgramCodeBlock):
      (EvalCodeBlock):
      (FunctionCodeBlock):
      * bytecode/GetByIdStatus.cpp:
      (JSC::GetByIdStatus::computeFor):
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFor):
      * bytecode/StructureStubInfo.h:
      (JSC::StructureStubInfo::StructureStubInfo):
      (StructureStubInfo):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleGetById):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGOSRExit.cpp:
      (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
      * dfg/DFGOSRExit.h:
      (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
      (OSRExit):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146669 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c5c0fa4e
    • fpizlo@apple.com's avatar
      DFG folding of PutById to SimpleReplace should consider the specialized function case · fd016b18
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=113093
      
      Reviewed by Geoffrey Garen and Mark Hahnenberg.
      
      Source/JavaScriptCore: 
      
      * bytecode/PutByIdStatus.cpp:
      (JSC::PutByIdStatus::computeFor):
      
      LayoutTests: 
      
      * fast/js/dfg-cfa-prove-put-by-id-simple-when-storing-to-specialized-function-expected.txt: Added.
      * fast/js/dfg-cfa-prove-put-by-id-simple-when-storing-to-specialized-function.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-cfa-prove-put-by-id-simple-when-storing-to-specialized-function.js: Added.
      (foo):
      (baz):
      (fuzz):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146653 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      fd016b18
    • ddkilzer@apple.com's avatar
      BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s · 0e9b1d1d
      ddkilzer@apple.com authored
      <http://webkit.org/b/112608>
      
      Fixes the following build failure:
      
          Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
          }
          ^
          1 error generated.
      
      * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s
      architecture.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146604 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0e9b1d1d
    • ddkilzer@apple.com's avatar
      Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]" · e086b1b1
      ddkilzer@apple.com authored
      This fixes a build failure introduced by this change:
      
          Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc'
              [super dealloc];
               ^     ~~~~~~~
          1 error generated.
      
      Not sure why this didn't fail locally on my Mac Pro.
      
      * API/tests/testapi.mm:
      (-[TinyDOMNode dealloc]): Remove call to [super dealloc].
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146603 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e086b1b1
    • ddkilzer@apple.com's avatar
      BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc] · a8f0ba3e
      ddkilzer@apple.com authored
      <http://webkit.org/b/112608>
      
      Fixes the following build failure:
      
          Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
          }
          ^
          1 error generated.
      
      * API/tests/testapi.mm:
      (-[TinyDOMNode dealloc]): Call [super dealloc].
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146599 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a8f0ba3e
    • rniwa@webkit.org's avatar
      Leak bots erroneously report JSC::WatchpointSet as leaking · 3340cf93
      rniwa@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=107781
      
      Reviewed by Filip Pizlo.
      
      Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate
      the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim.
      
      Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is
      initially "slim".
      
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag.
      (JSC::SymbolTableEntry::inflateSlow): Ditto.
      
      * runtime/SymbolTable.h:
      (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default.
      (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag.
      (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag
      is not set.
      
      (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default.
      (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry.
      (JSC::SymbolTableEntry::isNull): Ignore SlimFlag.
      (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag.
      (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset.
      (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore.
      (JSC::SymbolTableEntry::pack): Preserve SlimFlag.
      
      (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146568 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3340cf93
  6. 21 Mar, 2013 8 commits
    • mhahnenberg@apple.com's avatar
      Objective-C API: Need a good way to preserve custom properties on JS wrappers · 67910819
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112608
      
      Reviewed by Geoffrey Garen.
      
      Currently, we just use a weak map, which means that garbage collection can cause a wrapper to
      disappear if it isn't directly exported to JavaScript.
      
      The most straightforward and safe way (with respect to garbage collection and concurrency) is to have
      clients add and remove their external references along with their owners. Effectively, the client is
      recording the structure of the external object graph so that the garbage collector can make sure to
      mark any wrappers that are reachable through either the JS object graph of the external Obj-C object
      graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers
      will also remain alive.
      
      The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows:
      For a particular object, its references to its children should be added if:
      1. The child is referenced from JavaScript.
      2. The child contains references to other objects for which (1) or (2) are true.
      
      * API/JSAPIWrapperObject.mm:
      (JSAPIWrapperObjectHandleOwner::finalize):
      (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject
      is marked and its corresponding Objective-C object was added to the set of opaque roots.
      (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C
      objects to the set of opaque roots.
      * API/JSAPIWrapperObject.h:
      (JSAPIWrapperObject):
      * API/JSContext.mm: Moved dealloc to its proper place in the main implementation.
      (-[JSContext dealloc]):
      * API/JSVirtualMachine.h:
      * API/JSVirtualMachine.mm:
      (-[JSVirtualMachine initWithContextGroupRef:]):
      (-[JSVirtualMachine dealloc]):
      (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one.
      (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects
      owned by the owner object in that particular virtual machine.
      (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects.
      (-[JSVirtualMachine externalObjectGraph]):
      (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at
      the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their
      corresponding wrapper objects alive if they have them.
      * API/JSManagedReferenceInternal.h: Added.
      * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally
      known as that virtual machine's external object graph.
      * API/JSWrapperMap.mm:
      (-[JSWrapperMap dealloc]): We were leaking this before :-(
      (-[JSVirtualMachine initWithContextGroupRef:]):
      (-[JSVirtualMachine dealloc]):
      (-[JSVirtualMachine externalObjectGraph]):
      * API/JSVirtualMachineInternal.h:
      * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper
      doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through
      the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same
      owner doesn't cause any sort of problems.
      (+[TinyDOMNode sharedVirtualMachine]):
      (-[TinyDOMNode init]):
      (-[TinyDOMNode dealloc]):
      (-[TinyDOMNode appendChild:]):
      (-[TinyDOMNode numberOfChildren]):
      (-[TinyDOMNode childAtIndex:]):
      (-[TinyDOMNode removeChildAtIndex:]):
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * heap/SlotVisitor.h:
      (SlotVisitor):
      * heap/SlotVisitorInlines.h:
      (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a
      thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed
      to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for
      false negatives we return a TriState that's either true or mixed, but never false.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146558 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      67910819
    • mark.lam@apple.com's avatar
      Source/JavaScriptCore: Fix O(n^2) op_debug bytecode charPosition to column computation. · c649858c
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112957.
      
      Reviewed by Geoffrey Garen.
      
      The previous algorithm does a linear reverse scan of the source string
      to find the line start for any given char position. This results in a
      O(n^2) algortithm when the source string has no line breaks.
      
      The new algorithm computes a line start column table for a
      SourceProvider on first use. This line start table is used to fix up
      op_debug's charPosition operand into a column operand when an
      UnlinkedCodeBlock is linked into a CodeBlock. The initialization of
      the line start table is O(n), and the CodeBlock column fix up is
      O(log(n)).
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode): 
      (JSC::CodeBlock::CodeBlock): - do column fix up.
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::debug): - no need to do column fixup anymore.
      * interpreter/Interpreter.h:
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      * llint/LLIntSlowPaths.cpp:
      (JSC::LLInt::LLINT_SLOW_PATH_DECL):
      * parser/SourceProvider.cpp:
      (JSC::SourceProvider::lineStarts):
      (JSC::charPositionExtractor):
      (JSC::SourceProvider::charPositionToColumnNumber):
      - initialize line start column table if needed.
      - look up line start for the given char position.
      * parser/SourceProvider.h:
      
      Source/WTF: Introducing String::findNextLineStart().
      https://bugs.webkit.org/show_bug.cgi?id=112957.
      
      Reviewed by Geoffrey Garen.
      
      This is replaces String::reverseFindLineTerminator() in the JSC
      debugger's code for computing column numbers.
      
      * wtf/text/StringImpl.cpp:
      (WTF::StringImpl::findNextLineStart):
      * wtf/text/StringImpl.h:
      (WTF::findNextLineStart):
      * wtf/text/WTFString.h:
      (WTF::String::findNextLineStart):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146552 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c649858c
    • fpizlo@apple.com's avatar
      JSC profiler should have an at-a-glance report of the success of DFG optimization · 791dfcbf
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112988
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleCall):
      (JSC::DFG::ByteCodeParser::handleGetById):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * profiler/ProfilerCompilation.cpp:
      (JSC::Profiler::Compilation::Compilation):
      (JSC::Profiler::Compilation::toJS):
      * profiler/ProfilerCompilation.h:
      (JSC::Profiler::Compilation::noticeInlinedGetById):
      (JSC::Profiler::Compilation::noticeInlinedPutById):
      (JSC::Profiler::Compilation::noticeInlinedCall):
      (Compilation):
      * runtime/CommonIdentifiers.h:
      
      Tools: 
      
      * Scripts/display-profiler-output:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146548 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      791dfcbf
    • roger_fong@apple.com's avatar
      Move common props files for VS2010 solution to WebKitLibraries folder and... · 356fb46a
      roger_fong@apple.com authored
      Move common props files for VS2010 solution to WebKitLibraries folder and update all projects accordingly.
      
      * WebKit.vcxproj/FeatureDefines.props: Removed.
      * WebKit.vcxproj/FeatureDefinesCairo.props: Removed.
      * WebKit.vcxproj/WebKit/cURL.props: Removed.
      * WebKit.vcxproj/WinCairo.props: Removed.
      * WebKit.vcxproj/common.props: Removed.
      * WebKit.vcxproj/debug.props: Removed.
      * WebKit.vcxproj/debug_wincairo.props: Removed.
      * WebKit.vcxproj/debugsuffix.props: Removed.
      * WebKit.vcxproj/production.props: Removed.
      * WebKit.vcxproj/release.props: Removed.
      * win/tools/vsprops/FeatureDefines.props: Copied from ../Source/WebKit/WebKit.vcxproj/FeatureDefines.props.
      * win/tools/vsprops/FeatureDefinesCairo.props: Copied from ../Source/WebKit/WebKit.vcxproj/FeatureDefinesCairo.props.
      * win/tools/vsprops/WinCairo.props: Copied from ../Source/WebKit/WebKit.vcxproj/WinCairo.props.
      * win/tools/vsprops/cURL.props: Copied from ../Source/WebKit/WebKit.vcxproj/WebKit/cURL.props.
      * win/tools/vsprops/common.props: Copied from ../Source/WebKit/WebKit.vcxproj/common.props.
      * win/tools/vsprops/debug.props: Copied from ../Source/WebKit/WebKit.vcxproj/debug.props.
      * win/tools/vsprops/debug_wincairo.props: Copied from ../Source/WebKit/WebKit.vcxproj/debug_wincairo.props.
      * win/tools/vsprops/debugsuffix.props: Copied from ../Source/WebKit/WebKit.vcxproj/debugsuffix.props.
      * win/tools/vsprops/production.props: Copied from ../Source/WebKit/WebKit.vcxproj/production.props.
      * win/tools/vsprops/release.props: Copied from ../Source/WebKit/WebKit.vcxproj/release.props.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146530 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      356fb46a
    • mark.lam@apple.com's avatar
      Fix lexer charPosition computation when "rewind"ing the lexer. · 4f75bbeb
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112952.
      
      Reviewed by Michael Saboff.
      
      Changed the Lexer to no longer keep a m_charPosition. Instead, we compute
      currentCharPosition() from m_code and m_codeStartPlusOffset, where
      m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode
      start offset. This ensures that the charPosition is always in sync with
      m_code.
      
      * parser/Lexer.cpp:
      (JSC::::setCode):
      (JSC::::internalShift):
      (JSC::::shift):
      (JSC::::lex):
      * parser/Lexer.h:
      (JSC::Lexer::currentCharPosition):
      (JSC::::lexExpectIdentifier):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146505 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4f75bbeb
    • commit-queue@webkit.org's avatar
      [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder · eb79cda9
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112448
      
      Patch by Alberto Garcia <agarcia@igalia.com> on 2013-03-21
      Reviewed by Xan Lopez.
      
      This changed in r121381.
      
      * runtime/GCActivityCallbackBlackBerry.cpp:
      (JSC::DefaultGCActivityCallback::doWork):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146502 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      eb79cda9
    • mhahnenberg@apple.com's avatar
      Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak · ff81d056
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112856
      
      Reviewed by Geoffrey Garen.
      
      Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak 
      JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts.
      
      * API/JSAPIWrapperObject.cpp: Removed.
      * API/JSAPIWrapperObject.h:
      (JSAPIWrapperObject):
      * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an
      Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for 
      JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608.
      (JSAPIWrapperObjectHandleOwner):
      (jsAPIWrapperObjectHandleOwner):
      (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through
      the C API.
      (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize.
      (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random
      places scattered around JSWrapperMap.mm
      * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API.
      (JSObjectGetPrivate): Ditto.
      (JSObjectSetPrivate): Ditto.
      (JSObjectGetPrivateProperty): Ditto.
      (JSObjectSetPrivateProperty): Ditto.
      (JSObjectDeletePrivateProperty): Ditto.
      * API/JSValueRef.cpp: Ditto.
      (JSValueIsObjectOfClass): Ditto.
      * API/JSWrapperMap.mm: Remove wrapperClass().
      (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to 
      finalize wrapper objects.
      (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass(). 
      (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto.
      (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject.
      * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes 
      sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext.
      * CMakeLists.txt: Build file modifications.
      * GNUmakefile.list.am: Ditto.
      * JavaScriptCore.gypi: Ditto.
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
      * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
      * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms.
      (JSC::JSGlobalObject::reset): Ditto.
      (JSC::JSGlobalObject::visitChildren): Ditto.
      * runtime/JSGlobalObject.h: Ditto.
      (JSGlobalObject): Ditto.
      (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146494 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ff81d056
    • antonm@chromium.org's avatar
      Unreviewed, rolling out r146483. · 59a21b56
      antonm@chromium.org authored
      http://trac.webkit.org/changeset/146483
      https://bugs.webkit.org/show_bug.cgi?id=111695
      
      Source/JavaScriptCore: 
      
      Breaks debug builds.
      
      * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.
      
      Source/Platform: 
      
      Breaks
      
      * Platform.gypi:
      * chromium/public/Platform.h:
      (WebKit):
      (Platform):
      * chromium/public/WebSpeechSynthesisUtterance.h: Removed.
      * chromium/public/WebSpeechSynthesisVoice.h: Removed.
      * chromium/public/WebSpeechSynthesizer.h: Removed.
      * chromium/public/WebSpeechSynthesizerClient.h: Removed.
      
      Source/WebCore: 
      
      Breaks
      
      * Modules/speech/SpeechSynthesis.cpp:
      (WebCore::SpeechSynthesis::boundaryEventOccurred):
      (WebCore::SpeechSynthesis::didStartSpeaking):
      (WebCore::SpeechSynthesis::didPauseSpeaking):
      (WebCore::SpeechSynthesis::didResumeSpeaking):
      (WebCore::SpeechSynthesis::didFinishSpeaking):
      (WebCore::SpeechSynthesis::speakingErrorOccurred):
      (WebCore):
      * Modules/speech/SpeechSynthesis.h:
      (SpeechSynthesis):
      * Modules/speech/SpeechSynthesisUtterance.cpp:
      (WebCore::SpeechSynthesisUtterance::SpeechSynthesisUtterance):
      (WebCore::SpeechSynthesisUtterance::setVoice):
      * Modules/speech/SpeechSynthesisUtterance.h:
      (WebCore::SpeechSynthesisUtterance::text):
      (WebCore::SpeechSynthesisUtterance::setText):
      (WebCore::SpeechSynthesisUtterance::lang):
      (WebCore::SpeechSynthesisUtterance::setLang):
      (WebCore::SpeechSynthesisUtterance::volume):
      (WebCore::SpeechSynthesisUtterance::setVolume):
      (WebCore::SpeechSynthesisUtterance::rate):
      (WebCore::SpeechSynthesisUtterance::setRate):
      (WebCore::SpeechSynthesisUtterance::pitch):
      (WebCore::SpeechSynthesisUtterance::setPitch):
      (WebCore::SpeechSynthesisUtterance::startTime):
      (WebCore::SpeechSynthesisUtterance::setStartTime):
      (WebCore::SpeechSynthesisUtterance::platformUtterance):
      (SpeechSynthesisUtterance):
      * Modules/speech/SpeechSynthesisVoice.h:
      (SpeechSynthesisVoice):
      * WebCore.exp.in:
      * WebCore.gypi:
      * platform/PlatformSpeechSynthesis.h:
      (PlatformSpeechSynthesis):
      * platform/PlatformSpeechSynthesisUtterance.cpp:
      * platform/PlatformSpeechSynthesisUtterance.h:
      (PlatformSpeechSynthesisUtterance):
      (WebCore::PlatformSpeechSynthesisUtterance::client):
      * platform/PlatformSpeechSynthesisVoice.cpp:
      (WebCore::PlatformSpeechSynthesisVoice::create):
      (WebCore::PlatformSpeechSynthesisVoice::PlatformSpeechSynthesisVoice):
      * platform/PlatformSpeechSynthesisVoice.h:
      (PlatformSpeechSynthesisVoice):
      (WebCore::PlatformSpeechSynthesisVoice::voiceURI):
      (WebCore::PlatformSpeechSynthesisVoice::name):
      (WebCore::PlatformSpeechSynthesisVoice::lang):
      (WebCore::PlatformSpeechSynthesisVoice::localService):
      * platform/PlatformSpeechSynthesizer.cpp:
      (WebCore::PlatformSpeechSynthesizer::create):
      (WebCore::PlatformSpeechSynthesizer::PlatformSpeechSynthesizer):
      (WebCore):
      * platform/PlatformSpeechSynthesizer.h:
      (PlatformSpeechSynthesizerClient):
      (WebCore::PlatformSpeechSynthesizer::~PlatformSpeechSynthesizer):
      (PlatformSpeechSynthesizer):
      * platform/chromium/PlatformSpeechSynthesizerChromium.cpp: Removed.
      * platform/chromium/support/WebSpeechSynthesisUtterance.cpp: Removed.
      * platform/chromium/support/WebSpeechSynthesisVoice.cpp: Removed.
      * platform/chromium/support/WebSpeechSynthesizerClientImpl.cpp: Removed.
      * platform/chromium/support/WebSpeechSynthesizerClientImpl.h: Removed.
      * platform/mac/PlatformSpeechSynthesizerMac.mm:
      (-[WebSpeechSynthesisWrapper speakUtterance:WebCore::]):
      (-[WebSpeechSynthesisWrapper speechSynthesizer:didFinishSpeaking:]):
      (WebCore):
      (WebCore::PlatformSpeechSynthesizer::speak):
      * platform/mock/PlatformSpeechSynthesizerMock.cpp:
      (WebCore::PlatformSpeechSynthesizerMock::create):
      (WebCore::PlatformSpeechSynthesizerMock::PlatformSpeechSynthesizerMock):
      (WebCore::PlatformSpeechSynthesizerMock::speakingFinished):
      (WebCore::PlatformSpeechSynthesizerMock::speak):
      * platform/mock/PlatformSpeechSynthesizerMock.h:
      (PlatformSpeechSynthesizerMock):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      59a21b56