1. 22 Mar, 2013 8 commits
    • 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
  2. 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
    • 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
    • rgabor@webkit.org's avatar
      Implement LLInt for CPU(ARM_TRADITIONAL) · e757a7a4
      rgabor@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=97589
      
      Reviewed by Zoltan Herczeg.
      
      Enable LLInt for ARMv5 and ARMv7 traditional as well.
      
      Source/JavaScriptCore:
      
      * llint/LLIntOfflineAsmConfig.h:
      * llint/LowLevelInterpreter.asm:
      * llint/LowLevelInterpreter32_64.asm:
      * offlineasm/arm.rb:
      * offlineasm/backends.rb:
      * offlineasm/instructions.rb:
      
      Source/WTF:
      
      * wtf/Platform.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146459 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e757a7a4
  3. 20 Mar, 2013 10 commits
    • commit-queue@webkit.org's avatar
      [QNX][ARM] REGRESSION(r135330): Various failures in Octane · 89c06604
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112863
      
      Patch by Cosmin Truta <ctruta@blackberry.com> on 2013-03-20
      Reviewed by Yong Li.
      
      This was fixed in http://trac.webkit.org/changeset/146396 on Linux only.
      Enable this fix on QNX.
      
      * assembler/ARMv7Assembler.h:
      (ARMv7Assembler):
      (JSC::ARMv7Assembler::replaceWithJump):
      (JSC::ARMv7Assembler::maxJumpReplacementSize):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146429 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      89c06604
    • fpizlo@apple.com's avatar
      Fix indentation of JSString.h · 494f2d9a
      fpizlo@apple.com authored
      Rubber stamped by Mark Hahnenberg.
      
      * runtime/JSString.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146407 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      494f2d9a
    • fpizlo@apple.com's avatar
      "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion · 7e5ed6ed
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112845
      
      Reviewed by Mark Hahnenberg.
              
      I like to do "" + x. So I decided to make DFG recognize it, and related idioms.
      
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::fixupToPrimitive):
      (FixupPhase):
      (JSC::DFG::FixupPhase::fixupToString):
      (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::resultOfToPrimitive):
      (DFG):
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGPredictionPropagationPhase.h:
      (DFG):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146400 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e5ed6ed
    • zherczeg@webkit.org's avatar
      ARMv7 replaceWithJump ASSERT failure after r135330. · c3cdf5ff
      zherczeg@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=103146
      
      Reviewed by Filip Pizlo.
      
      On Linux, the 24 bit distance range of jumps sometimes does not
      enough to cover all targets addresses. This patch supports jumps
      outside of this range using a mov/movt/bx 10 byte long sequence.
      
      * assembler/ARMv7Assembler.h:
      (ARMv7Assembler):
      (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
      (JSC::ARMv7Assembler::nopw):
      (JSC::ARMv7Assembler::label):
      (JSC::ARMv7Assembler::replaceWithJump):
      (JSC::ARMv7Assembler::maxJumpReplacementSize):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146396 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c3cdf5ff
    • mhahnenberg@apple.com's avatar
      Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo: · 57c522f3
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112832
      
      Reviewed by Geoffrey Garen.
      
      If either the m_constructor or m_prototype (but not both) is collected, we will call 
      allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one 
      that was collected, but at the end of the method we call release on both of them. 
      This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be 
      reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool.
      
      * API/JSWrapperMap.mm:
      (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method,
      which autoreleases for us.
      (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the 
      constructor or prototype JSValues.
      * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146392 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      57c522f3
    • fpizlo@apple.com's avatar
      It's called "Hash Consing" not "Hash Consting" · 8fa6e667
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112768
      
      Rubber stamped by Mark Hahnenberg.
              
      See http://en.wikipedia.org/wiki/Hash_consing
      
      * heap/GCThreadSharedData.cpp:
      (JSC::GCThreadSharedData::GCThreadSharedData):
      (JSC::GCThreadSharedData::reset):
      * heap/GCThreadSharedData.h:
      (GCThreadSharedData):
      * heap/SlotVisitor.cpp:
      (JSC::SlotVisitor::SlotVisitor):
      (JSC::SlotVisitor::setup):
      (JSC::SlotVisitor::reset):
      (JSC::JSString::tryHashConsLock):
      (JSC::JSString::releaseHashConsLock):
      (JSC::JSString::shouldTryHashCons):
      (JSC::SlotVisitor::internalAppend):
      * heap/SlotVisitor.h:
      (SlotVisitor):
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData):
      * runtime/JSGlobalData.h:
      (JSGlobalData):
      (JSC::JSGlobalData::haveEnoughNewStringsToHashCons):
      (JSC::JSGlobalData::resetNewStringsSinceLastHashCons):
      * runtime/JSString.h:
      (JSC::JSString::finishCreation):
      (JSString):
      (JSC::JSString::isHashConsSingleton):
      (JSC::JSString::clearHashConsSingleton):
      (JSC::JSString::setHashConsSingleton):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146383 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8fa6e667
    • fpizlo@apple.com's avatar
      DFG implementation of op_strcat should inline rope allocations · 4463e44f
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112780
      
      Reviewed by Oliver Hunt.
              
      This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
      take either two or three operands, and allocates a rope string with either two or
      three fibers. (The magic choice of three children for non-VarArg nodes happens to
      match exactly with the magic choice of three fibers for rope strings.)
              
      ValueAdd on KnownString is replaced with MakeRope with two children.
              
      StrCat gets replaced by an appropriate sequence of MakeRope's.
              
      MakeRope does not do the dynamic check to see if its children are empty strings.
      This is replaced by a static check, instead. The downside is that we may use more
      memory if the strings passed to MakeRope turn out to dynamically be empty. The
      upside is that we do fewer checks in the cases where either the strings are not
      empty, or where the strings are statically known to be empty. I suspect both of
      those cases are more common, than the case where the string is dynamically empty.
              
      This also results in some badness for X86. MakeRope needs six registers if it is
      allocating a three-rope. We don't have six registers to spare on X86. Currently,
      the code side-steps this problem by just never usign three-ropes in optimized
      code on X86. All other architectures, including X86_64, don't have this problem.
              
      This is a shocking speed-up. 9% progressions on both V8/splay and
      SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
      on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGAdjacencyList.h:
      (AdjacencyList):
      (JSC::DFG::AdjacencyList::removeEdge):
      * dfg/DFGArgumentsSimplificationPhase.cpp:
      (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
      * dfg/DFGBackwardsPropagationPhase.cpp:
      (JSC::DFG::BackwardsPropagationPhase::propagate):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::putStructureStoreElimination):
      (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGDCEPhase.cpp:
      (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (JSC::DFG::FixupPhase::createToString):
      (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
      (JSC::DFG::FixupPhase::convertStringAddUse):
      (FixupPhase):
      (JSC::DFG::FixupPhase::convertToMakeRope):
      (JSC::DFG::FixupPhase::fixupMakeRope):
      (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileAdd):
      (JSC::DFG::SpeculativeJIT::compileMakeRope):
      (DFG):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      (SpeculativeJIT):
      (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
      (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
      (JSC::DFG::SpeculateCellOperand::gpr):
      (JSC::DFG::SpeculateCellOperand::use):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * runtime/JSString.h:
      (JSRopeString):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146382 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4463e44f
    • commit-queue@webkit.org's avatar
      Implement and32 on MIPS platform · d880e5b8
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112665
      
      Patch by Peter Gal <galpeter@inf.u-szeged.hu> on 2013-03-20
      Reviewed by Zoltan Herczeg.
      
      * assembler/MacroAssemblerMIPS.h:
      (JSC::MacroAssemblerMIPS::and32): Added missing method.
      (MacroAssemblerMIPS):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146339 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d880e5b8
    • mark.lam@apple.com's avatar
      Source/JavaScriptCore: Fix incorrect debugger column number value. · faa53933
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112741.
      
      Reviewed by Oliver Hunt.
      
      1. In lexer, parser, and debugger code, renamed column to charPosition.
      2. Convert the charPosition to the equivalent column number before
         passing it to the debugger.
      3. Changed ScopeNodes to take both a startLocation and an endLocation.
         This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit
         correct debug hooks with correct starting line and column numbers.
      4. Fixed the Lexer to not reset the charPosition (previously
         columnNumber) in Lexer::lex().
      
      * JavaScriptCore.order:
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
      * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::emitDebugHook):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::BytecodeGenerator::emitExpressionInfo):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::ArrayNode::toArgumentList):
      (JSC::ConstStatementNode::emitBytecode):
      (JSC::EmptyStatementNode::emitBytecode):
      (JSC::DebuggerStatementNode::emitBytecode):
      (JSC::ExprStatementNode::emitBytecode):
      (JSC::VarStatementNode::emitBytecode):
      (JSC::IfNode::emitBytecode):
      (JSC::IfElseNode::emitBytecode):
      (JSC::DoWhileNode::emitBytecode):
      (JSC::WhileNode::emitBytecode):
      (JSC::ForNode::emitBytecode):
      (JSC::ForInNode::emitBytecode):
      (JSC::ContinueNode::emitBytecode):
      (JSC::BreakNode::emitBytecode):
      (JSC::ReturnNode::emitBytecode):
      (JSC::WithNode::emitBytecode):
      (JSC::SwitchNode::emitBytecode):
      (JSC::LabelNode::emitBytecode):
      (JSC::ThrowNode::emitBytecode):
      (JSC::TryNode::emitBytecode):
      (JSC::ProgramNode::emitBytecode):
      (JSC::EvalNode::emitBytecode):
      (JSC::FunctionBodyNode::emitBytecode):
      * interpreter/Interpreter.cpp:
      (JSC::Interpreter::debug):
      - convert charPosition to column for the debugger.
      * interpreter/Interpreter.h:
      * jit/JITStubs.cpp:
      (DEFINE_STUB_FUNCTION(void, op_debug)):
      * llint/LLIntSlowPaths.cpp:
      (LLINT_SLOW_PATH_DECL(slow_op_debug)):
      * parser/ASTBuilder.h:
      (JSC::ASTBuilder::createFunctionExpr):
      (JSC::ASTBuilder::createFunctionBody):
      (JSC::ASTBuilder::createGetterOrSetterProperty):
      (JSC::ASTBuilder::createFuncDeclStatement):
      (JSC::ASTBuilder::createBlockStatement):
      (JSC::ASTBuilder::createExprStatement):
      (JSC::ASTBuilder::createIfStatement):
      (JSC::ASTBuilder::createForLoop):
      (JSC::ASTBuilder::createForInLoop):
      (JSC::ASTBuilder::createVarStatement):
      (JSC::ASTBuilder::createReturnStatement):
      (JSC::ASTBuilder::createBreakStatement):
      (JSC::ASTBuilder::createContinueStatement):
      (JSC::ASTBuilder::createTryStatement):
      (JSC::ASTBuilder::createSwitchStatement):
      (JSC::ASTBuilder::createWhileStatement):
      (JSC::ASTBuilder::createDoWhileStatement):
      (JSC::ASTBuilder::createWithStatement):
      (JSC::ASTBuilder::createThrowStatement):
      (JSC::ASTBuilder::createDebugger):
      (JSC::ASTBuilder::createConstStatement):
      * parser/Lexer.cpp:
      (JSC::::setCode):
      (JSC::::internalShift):
      (JSC::::shift):
      (JSC::::lex):
      * parser/Lexer.h:
      (JSC::Lexer::currentCharPosition):
      (Lexer):
      (JSC::::lexExpectIdentifier):
      * parser/NodeConstructors.h:
      (JSC::Node::Node):
      * parser/Nodes.cpp:
      (JSC::StatementNode::setLoc):
      (JSC::ScopeNode::ScopeNode):
      (JSC::ProgramNode::ProgramNode):
      (JSC::ProgramNode::create):
      (JSC::EvalNode::EvalNode):
      (JSC::EvalNode::create):
      (JSC::FunctionBodyNode::FunctionBodyNode):
      (JSC::FunctionBodyNode::create):
      * parser/Nodes.h:
      (JSC::Node::charPosition):
      (Node):
      (StatementNode):
      (JSC::StatementNode::lastLine):
      (ScopeNode):
      (JSC::ScopeNode::startLine):
      (JSC::ScopeNode::startCharPosition):
      (ProgramNode):
      (EvalNode):
      (FunctionBodyNode):
      * parser/Parser.cpp:
      (JSC::::Parser):
      (JSC::::parseFunctionBody):
      (JSC::::parseFunctionInfo):
      * parser/Parser.h:
      (JSC::::parse):
      * parser/ParserTokens.h:
      (JSC::JSTokenLocation::JSTokenLocation):
      (JSTokenLocation):
      * parser/SyntaxChecker.h:
      (JSC::SyntaxChecker::createFunctionBody):
      
      Source/WTF: Introducing String::reverseFindLineTerminator().
      https://bugs.webkit.org/show_bug.cgi?id=112741.
      
      Reviewed by Oliver Hunt.
      
      This is needed by the JSC debugger code for computing column numbers.
      
      * wtf/text/StringImpl.cpp:
      (WTF::StringImpl::reverseFindLineTerminator):
      * wtf/text/StringImpl.h:
      (StringImpl):
      (WTF::reverseFindLineTerminator):
      * wtf/text/WTFString.h:
      (WTF::String::reverseFindLineTerminator):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146318 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      faa53933
    • ossy@webkit.org's avatar
      REGRESSION(r146089): It broke 20 sputnik tests on ARM traditional and Thumb2 · 38657a40
      ossy@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112676
      
      Rubber-stamped by Filip Pizlo.
      
      Add one more EABI_32BIT_DUMMY_ARG to make DFG JIT ARM EABI compatible
      again after r146089 similar to https://bugs.webkit.org/show_bug.cgi?id=84449
      
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146309 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      38657a40
  4. 19 Mar, 2013 5 commits
  5. 18 Mar, 2013 9 commits
    • fpizlo@apple.com's avatar
      DFG ToString generic cases should work correctly · 8dc0753d
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112654
      <rdar://problem/13447250>
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      
      LayoutTests: 
      
      * fast/js/dfg-to-string-on-cell-expected.txt: Added.
      * fast/js/dfg-to-string-on-cell.html: Added.
      * fast/js/dfg-to-string-on-value-expected.txt: Added.
      * fast/js/dfg-to-string-on-value.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-to-string-on-cell.js: Added.
      (foo):
      * fast/js/script-tests/dfg-to-string-on-value.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146179 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8dc0753d
    • msaboff@apple.com's avatar
      Unreviewed build fix for 32 bit builds. · 6db99296
      msaboff@apple.com authored
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146178 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      6db99296
    • msaboff@apple.com's avatar
      EFL: Unsafe branch detected in compilePutByValForFloatTypedArray() · e41d7f5d
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112609
      
      Reviewed by Geoffrey Garen.
      
      Created local valueFPR and scratchFPR and filled them with valueOp.fpr() and scratch.fpr()
      respectively so that if valueOp.fpr() causes a spill during allocation, it occurs before the
      branch and also to follow convention.  Added register allocation checks to FPRTemporary.
      Cleaned up a couple of other places to follow the "AllocatVirtualRegType foo, get machine
      reg from foo" pattern.
      
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::fprAllocate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::convertToDouble):
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146174 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e41d7f5d
    • fpizlo@apple.com's avatar
      DFG should inline binary string concatenations (i.e. ValueAdd with string children) · 8d225914
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112599
      
      Reviewed by Oliver Hunt.
              
      This does as advertised: if you do x + y where x and y are strings, you'll get
      a fast inlined JSRopeString allocation (along with whatever checks are necessary).
      It also does good things if either x or y (or both) are StringObjects, or some
      other thing like StringOrStringObject. It also lays the groundwork for making this
      fast if either x or y are numbers, or some other reasonably-cheap-to-convert
      value.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::executeEffects):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      (FixupPhase):
      (JSC::DFG::FixupPhase::isStringObjectUse):
      (JSC::DFG::FixupPhase::convertStringAddUse):
      (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileAdd):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      (SpeculativeJIT):
      (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
      (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
      * runtime/JSString.h:
      (JSC::JSString::offsetOfFlags):
      (JSString):
      (JSRopeString):
      (JSC::JSRopeString::offsetOfFibers):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146164 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8d225914
    • fpizlo@apple.com's avatar
      JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name,... · afa61e0c
      fpizlo@apple.com authored
      JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name, which is unsafe if name was already #define'd to something else
      https://bugs.webkit.org/show_bug.cgi?id=112639
      
      Reviewed by Michael Saboff.
      
      Change it to take a string instead.
      
      * runtime/JSObject.h:
      (JSC):
      * runtime/ObjectPrototype.cpp:
      (JSC::ObjectPrototype::finishCreation):
      * runtime/StringPrototype.cpp:
      (JSC::StringPrototype::finishCreation):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146157 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      afa61e0c
    • bfulgham@webkit.org's avatar
      [WinCairo] Get build working under VS2010. · c9a74223
      bfulgham@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112604
      
      Reviewed by Tim Horton.
      
      * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Use CFLite-specific
      build target (standard version links against CoreFoundation.lib
      instead of CFLite.lib).
      * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Added.
      * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Added.
      * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146144 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c9a74223
    • roger_fong@apple.com's avatar
      AppleWin VS2010 Debug configuration build fix.. · 89b0a9a9
      roger_fong@apple.com authored
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * WebCore.vcxproj/WebCore.vcxproj:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146131 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      89b0a9a9
    • bfulgham@webkit.org's avatar
      [WinCairo] Get build working under VS2010. · 711a0945
      bfulgham@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=112604
      
      Reviewed by Tim Horton.
      
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add build targets for
      Debug_WinCairo and Release_WinCairo using CFLite.
      * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Added.
      * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Added.
      * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
      Add Debug_WinCairo and Release_WinCairo build targets to
      make sure headers are copied to proper build folder.
      * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Ditto.
      * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Added.
      * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
      Add Debug_WinCairo and Release_WinCairo build targets to
      make sure headers are copied to proper build folder.
      * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
      Ditto.
      * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
      Ditto.
      * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto.
      * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto.
      * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146123 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      711a0945
    • msaboff@apple.com's avatar
      Potentially unsafe register allocations in DFG code generation · 4bf9c30e
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=112477
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Moved allocation of temporary GPRs to be before any generated branches in the functions below.
      
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
      (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
      
      LayoutTests: 
      
      New tests added to verify proper operation of
      SpeculativeJIT::compileObjectToObjectOrOtherEquality,
      SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality
      and SpeculativeJIT::compileObjectOrOtherLogicalNot.
      
      * fast/js/dfg-compare-final-object-to-final-object-or-other-expected.txt: Added.
      * fast/js/dfg-compare-final-object-to-final-object-or-other.html: Added.
      * fast/js/dfg-logical-not-final-object-or-other-expected.txt: Added.
      * fast/js/dfg-logical-not-final-object-or-other.html: Added.
      * fast/js/dfg-peephole-compare-final-object-to-final-object-or-other-expected.txt: Added.
      * fast/js/dfg-peephole-compare-final-object-to-final-object-or-other.html: Added.
      * fast/js/script-tests/dfg-compare-final-object-to-final-object-or-other.js: Added.
      * fast/js/script-tests/dfg-logical-not-final-object-or-other.js: Added.
      * fast/js/script-tests/dfg-peephole-compare-final-object-to-final-object-or-other.js: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146100 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4bf9c30e