Projects/jscmerge
< Projects
| Proposed for Deletion |
|---|
This page has been proposed for deletion for the following reason:
|
------------------------------------------------------------------------ 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. ------------------------------------------------------------------------