Projects/jscmerge: Difference between revisions

Latest revision as of 12:36, 15 May 2019

Proposed for Deletion
This page has been proposed for deletion for the following reason: Project is dead.
Projects/KJSstuff
------------------------------------------------------------------------
r25681 | bdash | 2007-09-21 07:06:33 -0400 (Fri, 21 Sep 2007) | 10 lines | MO: Follow up to 25534, likely-merge

2007-09-21  Mark Rowe  <[email protected]>

        Reviewed by Antti Koivisto.

        http://bugs.webkit.org/show_bug.cgi?id=15250
        <rdar://problem/5496942> REGRESSION: Reproducible crash in Safari when evaluating script in Drosera console (15250)

        * kjs/function.cpp:
        (KJS::GlobalFuncImp::callAsFunction): Null-check thisObj before passing it to interpreterForGlobalObject.

------------------------------------------------------------------------
r25541 | ggaren | 2007-09-13 14:52:29 -0400 (Thu, 13 Sep 2007) | 25 lines | MO: maybe-merge, platform-bound

2007-09-12  Geoff Garen  <[email protected]>

        Reviewed by Sam Weinig.

        Fixed <rdar://problem/5429064> 141885 Safari JavaScript: Math.random() slightly less randomly distributed than on Safari / Mac

        Math.random was skewed slightly upward because it assumed that RAND_MAX was outside the range of
        values that rand() might return. This problem was particularly pronounced on Windows because
        the range of values returned by rand() on Windows is 2^16 smaller than the range of values
        return by rand() on Mac.

        Fixed by accounting for RAND_MAX return values. Also, switched Windows over to rand_s, which has
        a range that's equal to rand()'s range on Mac.

        * kjs/config.h:

        * kjs/math_object.cpp:
        (MathFuncImp::callAsFunction): Use the new new thing.

        * wtf/MathExtras.h: Platform abstraction for random numbers, to cover over differences on Windows.
        (wtf_random_init):
        (wtf_random):



------------------------------------------------------------------------
r25535 | antti | 2007-09-13 10:50:22 -0400 (Thu, 13 Sep 2007) | 25 lines | MO: follow up to r25534

JavaScriptCore:

        Reviewed by Maciej.
        
        Small addition to previous path to cover
        http://bugs.webkit.org/show_bug.cgi?id=11399
        window.eval runs in the global scope of the calling window
        
        Switch variable scope as well.

        * kjs/function.cpp:
        (KJS::GlobalFuncImp::callAsFunction):

LayoutTests:

        Reviewed by Maciej.
        
        Change test case to cover
        http://bugs.webkit.org/show_bug.cgi?id=11399
        too.

        * fast/js/window-eval-context-expected.txt:
        * fast/js/window-eval-context.html:


------------------------------------------------------------------------
r25534 | antti | 2007-09-13 09:54:12 -0400 (Thu, 13 Sep 2007) | 35 lines  | MO: merge, after review, likely outstanding BR; need discussion
                                                                          | MO: also may need support in KHTML. May be better to hold off
                                                                          | MO: until GlobalImp. Not sure about what I did with the TC, either

JavaScriptCore:

        Reviewed by Geoff, Maciej.
        
        Fix <rdar://problem/5445058>
        REGRESSION: Unable to upload picture to eBay auction due to domain security check
        
        eBay uses window.eval() between windows. In Firefox window.eval() switches execution
        and security context to the target window, something WebKit did not do. With WebKit
        security tightening in r24781, this broke picture uploads.
        
        Fix by making WebKit switch context in window.eval().
        
        * kjs/Context.cpp:
        (KJS::Context::Context):
        (KJS::Context::~Context):
        * kjs/context.h:
        Save and restore interpreter context independently from calling context.
        
        * kjs/function.cpp:
        (KJS::GlobalFuncImp::callAsFunction):
        If eval is called for global object different than current one, switch execution context
        to that object and push it to scope.

LayoutTests:

        Reviewed by Geoff, Maciej.
        
        Test for <rdar://problem/5445058>
        REGRESSION: Unable to upload picture to eBay auction due to domain security check

        * fast/js/window-eval-context-expected.txt: Added.
        * fast/js/window-eval-context.html: Added.

------------------------------------------------------------------------
r25409 | mjs | 2007-09-06 22:53:23 -0400 (Thu, 06 Sep 2007) | 21 lines | MO:  Not interesting, but an irrelevant cleanup

        Reviewed by Darin.
        
        - Remove single-threaded optimization for FastMalloc. 
        
        It does not appear to help anywhere but Mac OS X on PPC, due to
        pthread_getspecific being slow there. On Intel, removing the
        optimization results in a ~1.5% PLT speedup, a ~1-5% JS iBench
        speedup, and a ~1.5% HTML iBench speedup. On PPC this change is a
        speedup on some benchmarks, a slight hit on others.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * kjs/collector.cpp:
        (KJS::Collector::registerThread):
        * wtf/FastMalloc.cpp:
        (WTF::TCMalloc_ThreadCache::GetCache):
        (WTF::TCMalloc_ThreadCache::GetCacheIfPresent):
        (WTF::TCMalloc_ThreadCache::CreateCacheIfNecessary):
        (WTF::do_malloc):
        * wtf/FastMallocInternal.h: Removed.

------------------------------------------------------------------------
r25365 | mjs | 2007-09-05 01:01:03 -0400 (Wed, 05 Sep 2007) | 54 lines | MO: maybe-merge irrelevant cleanup (the KJS version)

        Reviewed by Darin.
        
        - Added Vector::appendRange(), which appends to a vector based on a given start and end iterator
        - Added keys() and values() functions to HashMap iterators, which give keys-only and values-only iterators
        
        Together, these allow easy copying of a set, or the keys or values of a map, into a Vector. Examples:
        
        HashMap<int, int> map;
        HashSet<int> set;
        Vector<int> vec;
        // ...
        vec.appendRange(set.begin(), set.end());
        vec.appendRange(map.begin().keys(), map.end().keys());
        vec.appendRange(map.begin().values(), map.end().values());

        This also allows for a slightly nicer syntax when iterating a map. Instead of saying 
        (*it)->first, you can say *it.values(). Similarly for keys. Example:
        
        HashMap<int, int>::const_iterator end = map.end();
        for (HashMap<int, int>::const_iterator it = map.begin(); it != end; ++it)
        printf(" [%d => %d]", *it.keys(), *it.values());

------------------------------------------------------------------------
r25296 | bdash | 2007-08-29 13:35:50 -0400 (Wed, 29 Aug 2007) | 10 lines | MO: merge, follow up tiny cleanup for portability fix

2007-08-29  Ryan Leavengood <[email protected]>

        Reviewed by Maciej.

        http://bugs.webkit.org/show_bug.cgi?id=15043
        - posix_memalign takes a void** as its first parameter. My port makes use of this function call.

        * kjs/collector.cpp:
        (KJS::allocateBlock):

------------------------------------------------------------------------
r25078 | darin | 2007-08-14 18:19:04 -0400 (Tue, 14 Aug 2007) | 12 lines | MO: follow up to 24919

        Reviewed by Sam.

        - fix <rdar://problem/5410570> Global initializer introduced by use of std::numeric_limits in r24919

        * kjs/ustring.cpp:
        (KJS::overflowIndicator): Turned into a function.
        (KJS::maxUChars): Ditto.
        (KJS::allocChars): Use the functions.
        (KJS::reallocChars): Ditto.
        (KJS::UString::expandedSize): Ditto.


------------------------------------------------------------------------
r25026 | darin | 2007-08-12 22:42:17 -0400 (Sun, 12 Aug 2007) | 47 lines | MO: merge, bugfix

JavaScriptCore:

        Reviewed by Maciej.

        - fix http://bugs.webkit.org/show_bug.cgi?id=14931
          <rdar://problem/5403816> JavaScript regular expression non-participating capturing parentheses
          fail in 3 different ways

        Test: fast/js/regexp-non-capturing-groups.html

        * kjs/string_object.cpp:
        (KJS::replace): Add missing code to handle undefined backreferences; before we'd get the empty string
        instead of a JavaScript "undefined" value.
        (KJS::StringProtoFunc::callAsFunction): Implemented backreference support for split.
        * pcre/pcre_exec.c: (match): Made backreferences to undefined groups match the empty string instead
        of always failing. Only in JAVASCRIPT mode.

        * tests/mozilla/expected.html: Add a new expected test success, since this fixed one test result.

LayoutTests:

        Reviewed by Maciej.

        - test for http://bugs.webkit.org/show_bug.cgi?id=14931
          JavaScript regular expression non-participating capturing groups behave incorrectly in edge cases

        * fast/js/regexp-non-capturing-groups-expected.txt: Added.
        * fast/js/regexp-non-capturing-groups.html: Added.
        * fast/js/resources/regexp-non-capturing-groups.js: Added.

        * fast/js/resources/js-test-pre.js: Updated to add a special case for array
        results, since there are some array results in the test. Also cut down on the
        verbosity of failures when the type of the actual result is the same as the type
        of the expected result. And get rid of the special case function just for NaN.

        * fast/js/regexp-unicode-overflow.html: Let the make-js-test-wrappers script
        regenerate this file (it removed one of the trailing newlines).

        * fast/js/kde/encode_decode_uri-expected.txt: This test now passes. I'm not sure
        why it was failing before.

        * fast/js/char-at-expected.txt: Removed all the periods at the end of NaN
        test PASS messages; they are now consistent with all the other tests.
        * fast/js/date-parse-comments-test-expected.txt: Ditto.
        * fast/js/date-parse-test-expected.txt: Ditto.

------------------------------------------------------------------------
r24919 | darin | 2007-08-07 20:45:39 -0400 (Tue, 07 Aug 2007) | 38 lines | MO: followup, probably defer, complex

        Reviewed by Adele.

        - fix <rdar://problem/5383104> REGRESSION: XHR.responseText is null instead of empty string
          in http/tests/xmlhttprequest/zero-length-response.html

        The new code to handle out of memory conditions was turning a "" into a null string.

        * kjs/ustring.h: Removed UCharReference, which has long been obsolete and unused.
        Removed copyForWriting, which was only used for the upper/lowercasing code and for
        UCharReference.
        * kjs/ustring.cpp:
        (KJS::allocChars): Removed special case that made this fail (return 0) when passed 0.
        Instead assert that we're not passed 0. Also added an overflow check for two reasons:
        1) for sizes that aren't checked this prevents us from allocating a buffer that's too
        small, and 2) for sizes where we overflowed in the expandedSize function and returned
        overflowIndicator, it guarantees we fail.
        (KJS::reallocChars): Ditto.
        (KJS::UString::expandedSize): Return a large number, overflowIndicator, rather than 0
        for cases where we overflow.
        (KJS::UString::spliceSubstringsWithSeparators): Added a special case for empty string so
        we don't call allocChars with a length of 0.
        (KJS::UString::operator=): Added special characters for both 0 and empty string so we
        match the behavior of the constructor. This avoids calling allocChars with a length of 0
        and making a null string rather than an empty string in that case, and also matches the
        pattern used in the rest of the functions.
        (KJS::UString::operator[]): Made the return value const so code that tries to use the
        operator to modify the string will fail.

        * kjs/string_object.cpp: (KJS::StringProtoFunc::callAsFunction): Rewrote uppercasing and
        lowercasing functions so they don't need copyForWriting any more -- it wasn't really doing
        any good for optimization purposes. Instead use a Vector and releaseBuffer.

        * wtf/unicode/icu/UnicodeIcu.h: Eliminate one of the versions of toLower/toUpper -- we now
        only need the version where both a source and destination buffer is passed in, not the one
        that works in place.
        * wtf/unicode/qt4/UnicodeQt4.h: Ditto.


------------------------------------------------------------------------
r24897 | bdash | 2007-08-06 21:45:53 -0400 (Mon, 06 Aug 2007) | 17 lines | MO: irrelevant, could be merged to sync

2007-08-07  Mark Rowe  <[email protected]>

        Reviewed by Maciej.

        <rdar://problem/5388774> REGRESSION: Hang occurs after clicking "Attach a file " link in a new .Mac message

        Attempting to acquire the JSLock inside CollectorHeap::forceLock can lead to a deadlock if the thread currently
        holding the lock is waiting on the thread that is forking.  It is not considered safe to use system frameworks
        after a fork without first execing[*] so it is not particularly important to ensure that the collector and
        fastMalloc allocators are unlocked in the child process.  If the child process wishes to use JavaScriptCore it
        should exec after forking like it would to use any other system framework.
        [*]: <http://lists.apple.com/archives/Cocoa-dev/2005/Jan/msg00676.html>

        * kjs/CollectorHeapIntrospector.cpp: Remove forceLock and forceUnlock implementations.
        * kjs/CollectorHeapIntrospector.h: Stub out forceLock and forceUnlock methods.
        * wtf/FastMalloc.cpp: Ditto.

------------------------------------------------------------------------
r24881 | pewtermoose | 2007-08-06 01:48:32 -0400 (Mon, 06 Aug 2007) | 6 lines | MO: follow up compile check, merge if applies

        Not reviewed, build fix.

        * kjs/string_object.cpp:
        (KJS::StringProtoFunc::callAsFunction):


------------------------------------------------------------------------
r24874 | darin | 2007-08-05 06:16:41 -0400 (Sun, 05 Aug 2007) | 14 lines | MO: may be merge. Nice asserts, may need adjustment for non-thread build

        Reviewed by Maciej.

        - fix <rdar://problem/5371862> crash in Dashcode due to Quartz Composer JavaScript garbage collector reentrancy

        * API/JSBase.cpp: (JSGarbageCollect): Don't call collector() if isBusy() returns true.

        * kjs/collector.h: Added isBusy(), removed the unused return value from collect()
        * kjs/collector.cpp: Added an "operation in progress" flag to the allocator.
        (KJS::Collector::allocate): Call abort() if an operation is already in progress. Set the new flag instead
        of using the debug-only GCLock.
        (KJS::Collector::collect): Ditto.
        (KJS::Collector::isBusy): Added.


------------------------------------------------------------------------
r24873 | mjs | 2007-08-05 01:20:35 -0400 (Sun, 05 Aug 2007) | 11 lines | MO: follow up to string cost accounting. must-merge if that's merged

        Reviewed by Darin and Adam.
        
        <rdar://problem/5368990> REGRESSION: newsgator.com sign-on 6x slower than Safari 3 beta due to GC changes (14808)

        * kjs/string_object.cpp:
        (KJS::replace): if the string didn't change (very common in some cases) reuse the original string value.
        (KJS::StringProtoFunc::callAsFunction): Pass in the StringImp* when replacing, not just the UString.
        * kjs/string_object.h:
        (KJS::StringInstance::internalValue): covariant override to return StringImp for convenience


------------------------------------------------------------------------
r24868 | bdash | 2007-08-04 04:58:35 -0400 (Sat, 04 Aug 2007) | 33 lines | no-merge, no CollectorHeapIntrospector for us

2007-08-04  Mark Rowe  <[email protected]>

        Reviewed by Oliver Hunt.

        <rdar://problem/5385145> r24843 introduces a crash on calling fork() (14878)
        http://bugs.webkit.org/show_bug.cgi?id=14878

        Provide nooop functions for all members of the malloc_zone_t and malloc_introspection_t structures that we
        register to avoid crashes in system code that assumes they will be non-null.
------------------------------------------------------------------------
r24843 | bdash | 2007-08-03 12:21:44 -0400 (Fri, 03 Aug 2007) | 59 lines | MO: no-merge, seems platform specific -- but may be can be used to teach VG things

2007-08-02  Mark Rowe  <[email protected]>

        Reviewed by Geoff Garen.

        <rdar://problem/4212199> 'leaks' reports false leaks in WebKit (because the WTF allocator uses mmap?)

        Implement malloc zone introspection routines to allow leaks, heap, and friends to request information
        about specific memory regions that were allocated by FastMalloc or the JavaScriptCore collector.

------------------------------------------------------------------------
r24821 | bdash | 2007-08-02 05:49:12 -0400 (Thu, 02 Aug 2007) | 7 lines | MO: follow up, merge is r23820 merged

2007-08-02  Mark Rowe  <[email protected]>

        Build fix.

        * kjs/ustring.cpp:
        (KJS::UString::expandedSize):  Use std::numeric_limits<size_t>::max() rather than the non-portable SIZE_T_MAX.

------------------------------------------------------------------------
r24820 | bdash | 2007-08-02 05:33:22 -0400 (Thu, 02 Aug 2007) | 39 lines | MO: MUST MERGE, security implications (but want more asserts)

2007-08-02  Mark Rowe  <[email protected]>

        Reviewed by Maciej.

        <rdar://problem/5352887> "Out of memory" error during repeated JS string concatenation leaks hundreds of MBs of RAM

        A call to fastRealloc was failing which lead to UString::expandCapacity leaking the buffer it was trying to reallocate.
        It also resulted in the underlying UString::rep having both a null baseString and buf field, which meant that attempting
        to access the contents of the string after the failed memory reallocation would crash.

        A third issue is that expandedSize size was calculating the new length in a way that led to an integer overflow occurring.
        Attempting to allocate a string more than 190,000,000 characters long would fail a the integer overflow would lead to a
        memory allocation of around 3.6GB being attempted rather than the expected 390MB.  Sizes that would lead to an overflow
        are now  returned as zero and callers are updated to treat this as though the memory allocation has failed.

        * kjs/array_object.cpp:
        (ArrayProtoFunc::callAsFunction): Check whether the append failed and raise an "Out of memory" exception if it did.
        * kjs/ustring.cpp:
        (KJS::allocChars): Wrapper around fastMalloc that takes a length in characters.  It will return 0 when asked to allocate a zero-length buffer.
        (KJS::reallocChars): Wrapper around fastRealloc that takes a length in characters.  It will return 0 when asked to allocate a zero-length buffer.
        (KJS::UString::expandedSize): Split the size calculation in two and guard against overflow during each step.
        (KJS::UString::expandCapacity): Don't leak r->buf if reallocation fails.  Instead free the memory and use the null representation.
        (KJS::UString::expandPreCapacity): If fastMalloc fails then use the null representation rather than crashing in memcpy.
        (KJS::UString::UString): If calls to expandCapacity, expandPreCapacity or fastMalloc fail then use the null representation rather than crashing in memcpy.
        (KJS::UString::append): Ditto.
        (KJS::UString::operator=): Ditto.
        * kjs/ustring.h: Change return type of expandedSize from int to size_t.

2007-08-02  Mark Rowe  <[email protected]>

        Reviewed by Maciej.

        <rdar://problem/5352887> "Out of memory" error during repeated JS string concatenation leaks hundreds of MBs of RAM

        Update test to check that accessing the string after the "Out of memory" exception was raised does not crash.

        * fast/js/resources/string-concatenate-outofmemory.js:
        * fast/js/string-concatenate-outofmemory-expected.txt:

------------------------------------------------------------------------
r24715 | hausmann | 2007-07-27 04:34:00 -0400 (Fri, 27 Jul 2007) | 2 lines | MO: maybe-merge, portability fix

Fix compilation with Qt on Windows with MingW: Implemented currentThreadStackBase() for this platform.

------------------------------------------------------------------------
r24714 | hausmann | 2007-07-27 04:33:49 -0400 (Fri, 27 Jul 2007) | 2 lines | MO: not sure, date stuff

Fix compilation with Qt on Windows with MingW: The MingW headers do not provide a prototype for a reentrant version of localtime. But since we don't use multiple threads for the Qt build we can use the plain localtime() function.

------------------------------------------------------------------------
r24710 | hausmann | 2007-07-27 04:33:05 -0400 (Fri, 27 Jul 2007) | 2 lines | MO: not sure, we probably don't want Qt platform to avoid confusion

Implemented currentTime() in the interpreter by using QDateTime, so that we don't need timeGetTime() on Windows and therefore also don't need to link against Winmm.dll.

------------------------------------------------------------------------
r24637 | mjs | 2007-07-25 21:50:54 -0400 (Wed, 25 Jul 2007) | 24 lines | MO: follow up, merge is 24633 is

JavaScriptCore:

        Reviewed by Mark.

        - follow-up to previous change
        
        * kjs/ustring.cpp:
        (KJS::UString::operator=): Make sure to reset the length when
        replacing the buffer contents for a single-owned string.

WebCore:

        Reviewed by Mark.

        - follow-up to previous change to avoid assertion failures in debug
        
        * xml/XMLHttpRequest.cpp:
        (WebCore::XMLHttpRequest::getResponseText): hold JSLock when needed
        (WebCore::XMLHttpRequest::open): ditto
        (WebCore::XMLHttpRequest::didFinishLoading): ditto
        (WebCore::XMLHttpRequest::didReceiveData): ditto
        * xml/XMLHttpRequest.h:


------------------------------------------------------------------------
r24633 | mjs | 2007-07-25 17:50:00 -0400 (Wed, 25 Jul 2007) | 133 lines  | MO: very nice change (with follow ups), r24637, r24919, 24873, but
                                                                         | MO: perhaps post-4.0, need to asses BC implications

JavaScriptCore:

        Reviewed by Darin.
        
        - JavaScriptCore part of fix for <rdar://problem/5300291> Optimize GC to reclaim big, temporary objects (like XMLHttpRequest.responseXML) quickly
        
        Also, as a side effect of optimizations included in this patch:
        - 7% speedup on JavaScript iBench
        - 4% speedup on "Celtic Kane" JS benchmark
        
        The basic idea is explained in a big comment in collector.cpp. When unusually 
        large objecs are allocated, we push the next GC closer on the assumption that
        most objects are short-lived.
        
        I also did the following two optimizations in the course of tuning
        this not to be a performance regression:

        1) Change UString::Rep to hold a self-pointer as the baseString in
        the unshared case, instead of a null pointer; this removes a
        number of null checks in hot code because many places already
        wanted to use the rep itself or the baseString as appropriate.
        
        2) Avoid creating duplicate StringImpls when creating a
        StringInstance (the object wrapper for a JS string) or calling
        their methods. Since a temporary wrapper object is made every time
        a string method is called, this resulted in two useless extra
        StringImpls being allocated for no reason whenever a String method
        was invoked on a string value. Now we bypass those.
        
        * kjs/collector.cpp:
        (KJS::):
        (KJS::Collector::recordExtraCost): Basics of the extra cost mechanism.
        (KJS::Collector::allocate): ditto
        (KJS::Collector::collect): ditto
        * kjs/collector.h:
        (KJS::Collector::reportExtraMemoryCost): ditto
        * kjs/array_object.cpp:
        (ArrayInstance::ArrayInstance): record extra cost
        * kjs/internal.cpp:
        (KJS::StringImp::toObject): don't create a whole new StringImpl just
        to be the internal value of a StringInstance! StringImpls are immutable
        so there's no point tot his.
        * kjs/internal.h:
        (KJS::StringImp::StringImp): report extra cost
        * kjs/string_object.cpp:
        (KJS::StringInstance::StringInstance): new version that takes a StringImp
        (KJS::StringProtoFunc::callAsFunction): don't create a whole new StringImpl
        just to convert self to string! we already have one in the internal value
        * kjs/string_object.h: report extra cost        
        * kjs/ustring.cpp: All changes to handle baseString being self instead of null in the 
        unshared case.
        (KJS::):
        (KJS::UString::Rep::create):
        (KJS::UString::Rep::destroy):
        (KJS::UString::usedCapacity):
        (KJS::UString::usedPreCapacity):
        (KJS::UString::expandCapacity):
        (KJS::UString::expandPreCapacity):
        (KJS::UString::UString):
        (KJS::UString::append):
        (KJS::UString::operator=):
        (KJS::UString::copyForWriting):
        * kjs/ustring.h:
        (KJS::UString::Rep::baseIsSelf): new method, now that baseString is
        self instead of null in the unshared case we can't just null check.
        (KJS::UString::Rep::data): adjusted as mentioned above
        (KJS::UString::cost): new method to compute the cost for a UString, for
        use by StringImpl.

        * kjs/value.cpp:
        (KJS::jsString): style fixups.
        (KJS::jsOwnedString): new method, use this for strings allocated from UStrings
        held by the parse tree. Tracking their cost as part of string cost is pointless,
        because garbage collecting them will not actually free the relevant string buffer.
        * kjs/value.h: prototyped jsOwnedString.
        * kjs/nodes.cpp:
        (StringNode::evaluate): use jsOwnedString as appropriate
        (RegExpNode::evaluate): ditto
        (PropertyNameNode::evaluate): ditto
        (ForInNode::execute): ditto
        
        * JavaScriptCore.exp: Exported some new symbols.

WebCore:

        Reviewed by Darin.

        - fixed <rdar://problem/5300291> Optimize GC to reclaim big, temporary objects (like XMLHttpRequest.responseXML) quickly
        
        With this plus related JavaScriptCore changes, a number of XMLHttpRequest situations that
        result in huge data sets are addressed, including a single huge responseXML on an XMR done
        repeatedly, or accessing responseText repeatedly during loading of a single large XHR.
        
        In addition to the GC changes in JavaScriptCore, I changed responseText to be stored as a
        KJS::UString instead of a WebCore::String so that the JavaScript responseText value can
        share the buffer (indeed multiple intermediate responseTexts can share its buffer).

        
        First of all, here's some manual test cases that will each blow out the process VM without this fix,
        but will settle into decent steady state with.
        
        * manual-tests/memory: Added.
        * manual-tests/memory/MessageUidsAlreadyDownloaded2: Added.
        * manual-tests/memory/string-growth.html: Added.
        * manual-tests/memory/xhr-multiple-requests-responseText.html: Added.
        * manual-tests/memory/xhr-multiple-requests-responseXML.html: Added.
        * manual-tests/memory/xhr-multiple-requests.html: Added.
        * manual-tests/memory/xhr-repeated-string-access.xml: Added.

        And here's the actual code changes:
        
        * WebCore.xcodeproj/project.pbxproj:
        * bindings/js/JSDocumentCustom.cpp:
        (WebCore::toJS): Record extra cost if the document is frameless (counting the nodes
        doesn't make a measurable performance difference here in any case I could find)
        * bindings/js/JSXMLHttpRequest.cpp:
        (KJS::JSXMLHttpRequest::getValueProperty): Adjust for the fact that ressponseText
        is now stored as a UString.
        * bindings/js/kjs_binding.cpp:
        (KJS::jsOwnedStringOrNull): New helper.
        * bindings/js/kjs_binding.h:
        * xml/XMLHttpRequest.cpp:
        (WebCore::XMLHttpRequest::getResponseText): It's a UString!
        (WebCore::XMLHttpRequest::getResponseXML): handle the fact that m_responseText
        is a UString.
        (WebCore::XMLHttpRequest::XMLHttpRequest): ditto.
        (WebCore::XMLHttpRequest::abort): call dropProtection
        (WebCore::XMLHttpRequest::didFinishLoading): call dropProtection
        (WebCore::XMLHttpRequest::dropProtection): after removing our GC protection,
        report extra cost of this XHR's responseText buffer.
        * xml/XMLHttpRequest.h:


------------------------------------------------------------------------
r24534 | mjs | 2007-07-23 06:26:02 -0400 (Mon, 23 Jul 2007) | 8 lines | MO: looks questionable, likely to be irrelevant with VarDeclNode execution fixes

        Reviewed by Oliver.
        
        - fix remaining problems with Window shadowing

        * kjs/nodes.cpp:
        (VarDeclNode::evaluate): Tweak the special case a little.


------------------------------------------------------------------------
r24533 | mjs | 2007-07-23 04:48:04 -0400 (Mon, 23 Jul 2007) | 8 lines | MO: looks questionable, likely to be irrelevant with VarDeclNode execution fixes

        Reviewed by Oliver.
        
        - fix Window shadowing regressions caused by the previous commit.

        * kjs/nodes.cpp:
        (VarDeclNode::evaluate): Handle the case of global scope specially.


------------------------------------------------------------------------
r24532 | mjs | 2007-07-23 03:10:35 -0400 (Mon, 23 Jul 2007) | 20 lines | MO: redundant w/how I'd merge other code.

        Reviewed by Darin.

        -fixed <rdar://problem/5353293> REGRESSION (r24287): 1% i-Bench JS slowdown from JavaScript compatibility fix (14719)
        http://bugs.webkit.org/show_bug.cgi?id=14719
        
        My fix for this actually resulted in JS iBench being 1% faster than before the regression
        and the Celtic Kane benchmark being 5% faster than before the regression.
        
        * kjs/nodes.cpp:
        (VarDeclNode::handleSlowCase): factored out the slow code path to be out of line.
        (VarDeclNode::evaluate): I did a couple of things:
        (1) Don't check if the variable is already declared by looking for the property in
        the variable object, that code path was dead code.
        (2) Special-case the common case where the top of the scope and the variable object
        are the same; in that case the variable must always be in the variable object.
        (3) Don't return a jsString() of the variable name, nothing uses the return value
        from this node types evaluate method.
        * kjs/nodes.h:

------------------------------------------------------------------------
r24287 | bdash | 2007-07-14 13:04:03 -0400 (Sat, 14 Jul 2007) | 32 lines | MO: sorta merge -- tied in fix fixing up VarDeclNode and catch scoping. Testcases! Testcases! Get your hot new testcases!

2007-07-14  Cameron Zwarich  <[email protected]>

        Reviewed by Darin.

        Fixes http://bugs.webkit.org/show_bug.cgi?id=13517,
              http://bugs.webkit.org/show_bug.cgi?id=14237, and
              the failure of test js1_5/Scope/regress-185485.js

        Bug 13517: DOM Exception 8 in finance.aol.com sub-page
        Bug 14237: Javascript "var" statement interprets initialization in the topmost function scope

        * kjs/nodes.cpp:
        (VarDeclNode::evaluate):
        * tests/mozilla/expected.html:

2007-07-14  Cameron Zwarich  <[email protected]>

        Reviewed by Darin.

        Added tests for the following bugs:
        http://bugs.webkit.org/show_bug.cgi?id=13517
        http://bugs.webkit.org/show_bug.cgi?id=14237

        Bug 13517: DOM Exception 8 in finance.aol.com sub-page
        Bug 14237: Javascript "var" statement interprets initialization in the topmost function scope

        * fast/js/resources/vardecl-blocks-init.js: Added.
        * fast/js/resources/vardecl-preserve-arguments.js: Updated.
        * fast/js/vardecl-blocks-init-expected.txt: Added.
        * fast/js/vardecl-blocks-init.html: Added.
        * fast/js/vardecl-preserve-arguments-expected.txt: Updated result.

------------------------------------------------------------------------
r24198 | zimmermann | 2007-07-11 08:56:05 -0400 (Wed, 11 Jul 2007) | 5 lines | MO: merge after additional analysis

Reviewed by Mark.

Forwardport the hash table fix from CodeGeneratorJS.pm to create_hash_table.
Reran run-jsc-tests, couldn't find any regressions. Suggested by Darin.

------------------------------------------------------------------------
r23675 | bdash | 2007-06-20 20:00:12 -0400 (Wed, 20 Jun 2007) | 21 lines | MO: merge, bugfix

2007-06-20  Mark Rowe  <[email protected]>

        Reviewed by Mitz.

        Fix http://bugs.webkit.org/show_bug.cgi?id=14244
        Bug 14244: Data corruption when using a replace() callback function with data containing "$"

        * kjs/string_object.cpp:
        (KJS::replace):  When 'replacement' is a function, do not replace $n placeholders in its return value.
        This matches the behaviour described in ECMA 262 3rd Ed section 15.5.4.1, and as implemented in Firefox.

2007-06-20  Mark Rowe  <[email protected]>

        Reviewed by Mitz.

        Test for http://bugs.webkit.org/show_bug.cgi?id=14244
        Bug 14244: Data corruption when using a replace() callback function with data containing "$"

        * fast/js/resources/string-replace-2.js: Update to test with 'replaceValue' being a function returning strings with "$n" placeholders.
        * fast/js/string-replace-2-expected.txt:

------------------------------------------------------------------------
r21122 | ddkilzer | 2007-04-26 17:15:26 -0400 (Thu, 26 Apr 2007) | 11 lines | MO: maybe-merge, but irrelevant

2007-04-25  David Kilzer  <[email protected]>

        Reviewed by Maciej.

        Add assertions for debug builds.

        * kjs/JSLock.cpp:
        (KJS::JSLock::lock): Assert the return value of pthread_mutex_lock() in debug builds.
        (KJS::JSLock::unlock): Assert the return value of pthread_mutex_unlock() in debug builds.

------------------------------------------------------------------------
r21076 | oliver | 2007-04-24 17:06:14 -0400 (Tue, 24 Apr 2007) | 7 lines | MO: maybe-merge, BC impact 

        GTK Build fix, ::findEntry->KJS::findEntry

        * kjs/lookup.cpp:
        (KJS::Lookup::findEntry):
        (KJS::Lookup::find):

------------------------------------------------------------------------
r20970 | bdash | 2007-04-20 03:50:14 -0400 (Fri, 20 Apr 2007) | 10 lines | MO: maybe-merge, should be right as-is

2007-04-20  Mark Rowe  <[email protected]>

        Reviewed by Anders.

        Improve FreeBSD compatibility, as suggested by Alexander Botero-Lowry.

        * kjs/collector.cpp:
        (KJS::currentThreadStackBase): FreeBSD requires that pthread_attr_t's are
        initialized via pthread_attr_init before being used in any context.

------------------------------------------------------------------------
r20835 | ggaren | 2007-04-10 18:27:26 -0400 (Tue, 10 Apr 2007) | 17 lines | MO: likely no-merge, platform fuzz

        Reviewed by John Sullivan, Darin Adler.
        
        Fixed <rdar://problem/5121899> JavaScript garbage collection leads to 
        later crash under Rosetta (should abort or leak instead?)
        
        Log an error message and crash if the kernel reports failure during GC.
        We decided to do this instead of just leaking because we don't want people
        to get the mistaken impression that running in Rosetta is a supported
        configurtion.
        
        The CRASH macro will also hook into CrashReporter, which will tell us if 
        many (any?) users run into this issue.

        * kjs/collector.cpp:
        (KJS::getPlatformThreadRegisters):

------------------------------------------------------------------------
r20361 | zack | 2007-03-21 05:30:26 -0400 (Wed, 21 Mar 2007) | 2 lines | MO: not sure, I don't know what's the best way to handle the collector + threads ultra-mess

Fix the compile when USE(MULTIPLE_THREADS) isn't defined

------------------------------------------------------------------------
r20353 | thatcher | 2007-03-20 20:11:36 -0400 (Tue, 20 Mar 2007) | 1 line | MO: see above

Build fix.
------------------------------------------------------------------------
r20351 | mjs | 2007-03-20 19:57:01 -0400 (Tue, 20 Mar 2007) | 52 lines | MO: see above

        Reviewed by Geoff and Adam.
        
        - make USE(MULTIPLE_THREADS) support more portable
        http://bugs.webkit.org/show_bug.cgi?id=13069
        
        - fixed a threadsafety bug discovered by testing this
        
        - enhanced threadsafety assertions in collector

        * API/JSCallbackObject.cpp:
        (KJS::JSCallbackObject::~JSCallbackObject): This destructor can't
        DropAllLocks around the finalize callback, because it gets called
        from garbage collection and we can't let other threads collect!

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * kjs/JSLock.cpp:
        (KJS::JSLock::currentThreadIsHoldingLock): Added new function
        to allow stronger assertions than just that the lock is held
        by some thread (you can now assert that the current thread is
        holding it, given the new JSLock design).
        * kjs/JSLock.h:
        * kjs/collector.cpp: Refactored for portability plus added some
        stronger assertions.
------------------------------------------------------------------------