delta/qt5/qtwebkit.git/Source/JavaScriptCore/runtime, branch 5.4.1

Merge remote-tracking branch 'origin/5.3' into 5.4

2014-10-14T12:08:44+00:00

Change-Id: I509f0440296df39aece8133382aacc43a4e05f99

Fix valgrind warning about uninitialized access

2014-10-06T15:31:36+00:00

A default cache-entry has a null String and an uninitialized key. We
should therefore only try to use the key if the String is not null.

Change-Id: Icd6819b96b9b650305cf0611b6b2978c07dc9196
Reviewed-by: Michael Bruning

(un)shiftCountWithAnyIndexingType will start over in the middle of copying if it sees a hole

2014-09-30T15:48:46+00:00

https://bugs.webkit.org/show_bug.cgi?id=121717

Reviewed by Oliver Hunt.

Source/JavaScriptCore:

This bug caused the array to become corrupted. We now check for holes before we start moving things,
and start moving things only once we've determined that there are none.

* runtime/JSArray.cpp:
(JSC::JSArray::shiftCountWithAnyIndexingType):
(JSC::JSArray::unshiftCountWithAnyIndexingType):

Change-Id: I9948bfa2c9b4a345076f7f2b4e50a566f521b6fe
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156214 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reviewed-by: Jocelyn Turcotte

compileMakeRope does not emit necessary bounds checks

2014-09-26T12:02:28+00:00

https://bugs.webkit.org/show_bug.cgi?id=130684


Reviewed by Oliver Hunt.

Add string length bounds checks in a bunch of places. We should never allow a string
to have a length greater than 2^31-1 because it's not clear that the language has
semantics for it and because there is code that assumes that this cannot happen.

Also add a bunch of tests to that effect to cover the various ways in which this was
previously allowed to happen.

* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMakeRope):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileMakeRope):
* runtime/JSString.cpp:
(JSC::JSRopeString::RopeBuilder::expand):
* runtime/JSString.h:
(JSC::JSString::create):
(JSC::JSRopeString::RopeBuilder::append):
(JSC::JSRopeString::RopeBuilder::release):
(JSC::JSRopeString::append):
* runtime/Operations.h:
(JSC::jsString):
(JSC::jsStringFromRegisterArray):
(JSC::jsStringFromArguments):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncIndexOf):
(JSC::stringProtoFuncSlice):
(JSC::stringProtoFuncSubstring):
(JSC::stringProtoFuncToLowerCase):
* tests/stress/make-large-string-jit-strcat.js: Added.
(foo):
* tests/stress/make-large-string-jit.js: Added.
(foo):
* tests/stress/make-large-string-strcat.js: Added.
* tests/stress/make-large-string.js: Added.

Change-Id: If01dd2a2d2daa3d209eddf0213d2b391e94f54a0
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@167336 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reviewed-by: Jocelyn Turcotte

Flattening a dictionary can cause CopiedSpace corruption

2014-09-25T16:15:52+00:00

Reviewed by Oliver Hunt.

When we flatten an object in dictionary mode, we compact its properties. If the object
had out-of-line storage in the form of a Butterfly prior to this compaction, and after
compaction its properties fit inline, the object's Structure "forgets" that the object
has a non-zero Butterfly pointer. During GC, we check the Butterfly and reportLiveBytes
with bytes = 0, which causes all sorts of badness in CopiedSpace.

Instead, after we flatten a dictionary, if properties fit inline we should clear the
Butterfly pointer so that the GC doesn't get confused later.

This patch does this clearing, and it also adds JSObject::checkStructure, which overrides
JSCell::checkStructure to add an ASSERT that makes sure that the Structure being assigned
agrees with the whether or not the object has a Butterfly. Also added an ASSERT to check
that the number of bytes reported to SlotVisitor::copyLater is non-zero.

* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::copyLater):
* runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::genericConvertDoubleToContiguous):
(JSC::JSObject::switchToSlowPutArrayStorage):
(JSC::JSObject::setPrototype):
(JSC::JSObject::putDirectAccessor):
(JSC::JSObject::seal):
(JSC::JSObject::freeze):
(JSC::JSObject::preventExtensions):
(JSC::JSObject::reifyStaticFunctionsForDelete):
(JSC::JSObject::removeDirect):
* runtime/JSObject.h:
(JSC::JSObject::setButterfly):
(JSC::JSObject::putDirectInternal):
(JSC::JSObject::setStructure):
(JSC::JSObject::setStructureAndReallocateStorageIfNecessary):
* runtime/Structure.cpp:
(JSC::Structure::flattenDictionaryStructure):

Change-Id: Idfd8c22555f4373c1104316ff1ee28f5f84ef083
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154366 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reviewed-by: Jocelyn Turcotte

JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage does a check on the length of the ArrayStorage after possible reallocing it

2014-03-07T15:18:10+00:00

https://bugs.webkit.org/show_bug.cgi?id=120278

Reviewed by Geoffrey Garen.

Source/JavaScriptCore:

* runtime/JSObject.cpp:
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):

Change-Id: I034d6950683304d08a4e076d58fb1b999ade444b
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@154633 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reviewed-by: Jocelyn Turcotte

Setting a large numeric property on an object causes it to allocate a huge backing store

2014-03-07T15:18:05+00:00

https://bugs.webkit.org/show_bug.cgi?id=118914

Reviewed by Geoffrey Garen.

Source/JavaScriptCore:

There are two distinct actions that we're trying to optimize for:

new Array(100000);

and:

a = [];
a[100000] = 42;

In the first case, the programmer has indicated that they expect this Array to be very big,
so they should get a contiguous array up until some threshold, above which we perform density
calculations to see if it is indeed dense enough to warrant being contiguous.

In the second case, the programmer hasn't indicated anything about the size of the Array, so
we should be more conservative and assume it should be sparse until we've proven otherwise.

Currently both of those cases are handled by MIN_SPARSE_ARRAY_INDEX. We should distinguish
between them for the purposes of not over-allocating large backing stores like we see on
http://www.peekanalytics.com/burgerjoints/

The way that we'll do this is to keep the MIN_SPARSE_ARRAY_INDEX for the first case, and
introduce a new heuristic for the second case. If we are putting to an index above a certain
threshold (say, 1000) and it is beyond the length of the array, then we will use a sparse
map instead. So for example, in the second case above the empty array has a blank indexing
type and a length of 0. We put-by-val to an index > 1000 and > a.length, so we'll use a sparse map.

This fix is ~800x speedup on the accompanying regression test :-o

* runtime/ArrayConventions.h:
(JSC::indexIsSufficientlyBeyondLengthForSparseMap):
* runtime/JSObject.cpp:
(JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
(JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
(JSC::JSObject::putByIndexBeyondVectorLength):
(JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153374 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Change-Id: I1c29992d6e09c9d523a8093e76e3848a9581ce45
Reviewed-by: Jocelyn Turcotte

Fix undefined reference linker errors with MinGW

2013-10-16T11:40:47+00:00

Make sure the inline methods are defined whereever referenced. This fixes
'undefined reference' errors when linking with MinGW-builds 4.8.2 32 bit
posix dwarf rev2.

Task-number: QTBUG-34083
Change-Id: Iadc7300634780741be9d97bc889290cd113181e1
Reviewed-by: Allan Sandfeld Jensen

Fix linux-clang with clang 3.4

2013-10-04T14:10:50+00:00

Cherry-picked upstream r153965 to fix linux build with clang 3.4

Change-Id: Ib3eeb5c424c4f0ef00c228ad02b61ef87dd9b3b6
Reviewed-by: Allan Sandfeld Jensen

Fix build with MingW

2013-09-20T15:35:28+00:00

Fix wrong export/import flags in inlined methods.

Use normal GCC inline asm instead of _ReadWriteBarrier.

Change-Id: Iba6b923be383777f2807d84349044dbe5a22eb57
Reviewed-by: Allan Sandfeld Jensen