This is just a rename change with the exception of a bug found along the way in
CodeStubGraphBuilder<FastCloneShallowArrayStub>::BuildCodeStub(). There, the
intent is to get the boilerplate object from an AllocationSite. But the wrong
HObjectAccess was used. It only succeeds because it happened to be the same
offset :).
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/19595004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes the isolate=>heap=>isolate nonsense and has the additional bonus
that it re-enables printing of code objects in GDB. NOT: To make the latter
work, one has to adapt GDB any macros using FindCodeObject! Keeping things as it
is and outlining Isolate::heap() was not really an option...
Side note: Currently we are lucky that we still have Isolate::Current()
available in GDB, although it is marked as INLINE. :-}
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/19785004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15770 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
These methods have been superceeded by equivalents accepting object arguments exposing more details.
This is exactly the same change as r15708 which was reverted in r15710 due to pending Blink changes. Now that Blink is rolled to 154493 it should be safe to land this (required Blink change is 154386).
BUG=None
TBR=yangguo@chromium.org
Review URL: https://codereview.chromium.org/19541005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15769 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change fixes data race described in the bug by adding Acquire_Load to SamplingCircularQueue::StartDequeue and Acquire_Store to SamplingCircularQueue::Enqueue.
Also the queue implementation imposed a constraint on the records it stored: the first AtomicWord in each record was a marker. For that purpose TickSampleEventRecord had filter field of type int. This approach is error prone, e.g. on x64 sizeof(AtomicWord) is 8 while sizeof(int) is 4. Moreover the queue needs such marker only at the beginning of chunk. I changed the queue so that it stores the marker explicitly as the first Cell in chunk and removed the filter field.
BUG=251218
R=loislo@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/19642002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15750 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
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
In Blink, JSTypedArray and JSDataView objects act as "wrappers" for C++
objects. Wrapping protocol in Blink requires all wrapper JavaScript objects
to have a certain amount of internal fields that Blink uses for
book-keeping (essentially a pointer to C++ object and some type
information). This change adds those internal fields to JSTypedArray and
JSDataView, in a similiar way to how it is done for JSArrayBuffer.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/18695004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15511 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Their values are not used neither by the tick processor nor by CpuProfiler so it is just a waste of space.
TickSample used to be a transport for grabbed register values to TickSample::Trace, now they are passed in a special structure RegisterState which is allocated on the stack for the sampling period.
Some common pieces were moved from platform-dependent code into Sampler::SampleStack and TickSample::Init.
BUG=None
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/18620002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15484 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
