Fix the invalid array length check, replacing it with a check of
the elements pointer similar to TransitionElementsKindStub.
Refactor common code from ElementsTransitionAndStoreStub and TransitionElementsKindStub into BuildTransitionElementsKind() helper method.
Add test case for the MD5 computation that used to crash before,
and a small test case for the specific issue.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/19367003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stub used to check the length of the JS array to see if
there's a need to duplicate the elements backing store. This
way it will not duplicate the elements array when going from
double to object even if the elements array is not the empty
fixed array. Later on it will then store pointers into a
FixedDoubleArray.
The native code stub used to check whether elements points to
the empty_fixed_array singleton instead of testing the length.
The Hydrogen stub does that as well now.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/19289009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15701 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Further refinement to semantics that I have missed in previous change.
Both Blink and Firefox are permissive with arguments to .set method.
However, when first argument to "set" is a number, all implementations
throw, so that users know that
a.set(0,27)
does not assign 27 to 0th element of a, not 0 to 27th element of a.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/19210002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch allows callbacks to lazily allocate the InternalArray which is used to store pendingChangeRecords. This moves some of the expense of observation to the case where changes actually occurred.
When there are no pendingChangeRecords, the callbackInfo structure is a number which is the callbacks priority. Whenever a changeRecord is enqueued to the callback, it "normalizes" to be an InternalArray with a priority property. Immediately before its changeRecords are delivered, it returns to its optimized state.
---
Note: Naming confusion resolved:
This patch corrects some naming confusion in object-observe.js. Previously, we used the terms "callback" and "observer" to mean roughly the same thing, and overloaded the term "observer" to be both the callback itself and the *registration* on a object to observe (which now includes an accept map).
This patch resolves this confusion:
"object" (objectInfo, objectInfoMap): This refers to the observed object and its structures
"callback" (callbackInfo, callbackInfoMap): This refers to the callback to whom change records may be delivered
"observer" (objectInfo.changeObservers): This refers to a registration to observe a given object by a given callback with the specified accept list.
---
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/19132002
Patch from Rafael Weinstein <rafaelw@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15682 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This essentially relands r14930 and r14935 with adaptions to the current
code base. It models the instantiation of an implicit receiver for
CallNew nodes in hydrogen using HAllocate together with generic stores
instead of one specialized HAllocateObject instruction, hence creating a
single choking point for inlined allocation in optimized code.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/19207002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The code previously assumed that an array with fast properties must have
a writable length property. But Object.freeze() now exposes a way to make
length read-only without moving the object into slow mode. This patch
simply adds a !is_frozen check to the IC code. Any future optimizations
to attribute-setting on JSArrays will need to make similar accomodations.
R=danno
BUG=v8:2711,259548
Review URL: https://chromiumcodereview.appspot.com/19115002
Patch from Adam Klein <adamk@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15651 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
properly when it is called with a function pointer in the type cell,
instead assuming that an AllocationSite object should be present. The
case where this can happen is if the cell is uninitialized, then the
first constructor call made is to the Array function of a different
context. In that case, we'll store the function pointer in the cell,
and then go ahead and call the array constructor stub too. The bug is
fixed by checking for the AllocationSite object map. If not found, the
constructor stub goes forward with a default ElementsKind, just as in
several other cases.
A test in allocation-site-info.js was beefed up to make sure the state
chain described above is traversed.
BUG=
R=hpayer@chromium.org, hpayer@google.com
Review URL: https://codereview.chromium.org/18277006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) report line number even if a script has no resource_name (evals);
a) do that for already compiled functions in log.cc;
b) do that for fresh evals in compiler.cc;
2) Implement the test for LineNumbers and make it fast and stable, otherwise we have to wait for tick samples;
a) move processor_->Join() call into new Processor::StopSynchronously method;
b) Process all the CodeEvents even if we are stopping Processor thread;
c) make getters for generator and processor;
3) Fix the test for Jit that didn't expect line numbers;
4) Minor refactoring:
a) in ProcessTicks;
b) rename enqueue_order_ to last_code_event_id_ for better readability;
c) rename dequeue_order_ to last_processed_code_event_id_ and make it a member for better readability;
BUG=
TEST=test-profile-generator/LineNumber
R=jkummerow@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/18058008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15530 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
