gcc rejects the following snippet, clang rejects it in -std=c++11 mode:
namespace A { template<class T> class C {}; }
namespace B { template class A::C<int>; }
Indeed, the C++ standard says in 14.7.2p2 "An explicit instantiation shall
appear in an enclosing namespace of its template", so cl.exe is incorrect to
allow this.
Just move the instantiation out of the v8 namespace to fix. No intended
behavior change. Fixes building with clang-cl on Windows.
BUG=chromium:475643
LOG=N
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1073903002
Cr-Commit-Position: refs/heads/master@{#27721}
Before this patch the embedder could assign timestamp to the last interval after calling GetHeapStats. This would be slightly different from the timstamps assigned by v8 internally and written into heap snapshot. This patch allow to avoid this small discrepancy by returning timestamp along with last heap stats update.
BUG=chromium:467222
LOG=Y
Review URL: https://codereview.chromium.org/1037803002
Cr-Commit-Position: refs/heads/master@{#27466}
None of these fields is used in Blink. Embedder always can implement them using existing API.
BUG=chromium:465651
LOG=Y
Review URL: https://codereview.chromium.org/983833006
Cr-Commit-Position: refs/heads/master@{#27113}
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>;
R=svenpanne@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/682143003
Patch from Weiliang <weiliang.lin@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reason for revert:
It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
Original issue's description:
> Extend CPU profiler with mapping ticks to source lines
>
> The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
> During generation code and relocation info are generated simultaneously.
> When code generation is done you each code object has associated "relocation info".
> Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
> correspondences between the machine program counter and source locations for stack walking.
>
> This patch:
> 1. Add more source positions info in reloc info to make it suitable for source level mapping.
> The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
> (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
> I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
>
> 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
> If a source line is found that hit counter is increased by one for this line.
>
> 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
> Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
>
> 4.Add a test that checks how the samples are distributed through source lines.
> It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
>
> Patch from Denis Pravdin <denis.pravdin@intel.com>
> BUG=None
> LOG=Y
> R=svenpanne@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=24389TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/624443005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>
BUG=None
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/616963005
Patch from Denis Pravdin <denis.pravdin@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All methods for accessing collected profiles by index are deprecated. The indexed storage may well be implemented by the embedder should he need it. CpuProfiler's responsibility is just to create CpuProfile object that contains all collected data and whose lifetime can be managed by the embedder.
BUG=chromium:327298
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/117353002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The reason of that is a number of cons strings in the app.
The app constructs a json string and as a result v8 heap has
a very long chain of cons strings.
Profiler counts all these strings as plain String objects and
assign the content of the strings as node names.
It required O(n^2) time and O(n^2) memory.
Solution: I introduced two new types, kConsString and kSliced string.
They do not use the content of the string for names. So the problem disappeared.
The heap profiler usability problem will be solved on Blink side.
BUG=285770
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23460027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16611 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Current v8 implementation may disable optimization for a particular function or block it with help of dont_optimize flag.
The patch propagates the reason of that to the SharedFunctionInfo where cpu profiler can get it.
SharedFunctionInfo is a heap object so I extracted 8 bits from OptsCount for handling bailout reason code.
BUG=none
TEST=test-profile-generator/BailoutReason
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23817003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All of these values are derived from the self samples count and there is no need to evaluate them in v8 when clients can do that when needed on their side.
Also added unsigned GetHitCount() which should be used instead of double GetSelfSamplesCount(). I'm going to deprecate the latter one once Blink has switched to GetHitCount.
BUG=267595
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/22710006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16119 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t.
This way it seems more natural as we are going to support submilisecond sampling
rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test
failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22155003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t. This way it seems more natural as we are going to support submilisecond sampling rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22172002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'm going to change CPU profiler API and deprecate GetSelfTime, GetTotalTime and GetTotalSamplesCount on CpuProfileNode as all of those values are derived from self samples count and sampling rate. The sampling rate in turn is calculate based on the profiling duration so having start/end time and total sample count is enough for calculating smpling rate.
BUG=267595
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/21918002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Added instance method on v8::Isolate for retrieving instance of v8::HeapProfiler for that isolate. All static methods of v8::HeapProfiler are deprecated, corresponding instance methods are added to v8::HeapProfiler.
All static methods on v8::internal::HeapProfiler were converted into instance ones.
BUG=None
Review URL: https://codereview.chromium.org/12907006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU profiler API is extended with methods that allow to retrieve individual samples from profile. Each sample is presented as a pointer to a node in the top-down profile tree. The samples will let us tie JS performance to time.
BUG=None
Review URL: https://codereview.chromium.org/12919002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13980 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Prevously v8 put a link to each context variable into a function where
the variable is visible.
Because of that if there are N functions sharing a context having M variables
then N*M links were created for the snapshot.
The fix makes v8 to put the links into the context object.
BUG=145687
TEST=test-heap-snapshot/ManyLocalsInSharedContext
Review URL: https://codereview.appspot.com/7715044
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13936 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The stats data have only count field at the moment.
A constantly growing array of integers also can be a reason of a leak.
Ans we have to have a way to detect such kind of leaks.
Drive by fix:
FindObject and AddEntry were replaced with FindEntry/FindOrAddEntry pair.
BUG=none
TEST=HeapSnapshotObjectsStats
Review URL: https://chromiumcodereview.appspot.com/10086004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11327 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch changes the signature of the v8::HeapGraphNode::GetRetainedSize method, but it's not used in Chromium, and it should be easy for other clients (if any) to adjust to this change.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/9466014
Patch from Alexei Filippov <alexeif@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10846 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As example there are 'Detached DOM Tree' nodes in WebKit. It is very useful to be able to see all such
nodes grouped together. It can be done with help of some post processing but I did this explicitly
on v8 side because it is much faster. At the moment this kind of nodes has kNative type.
I'd like to hide these nodes from the Retainment View but I can filter them only by name.
BUG=none
TEST=HeapSnapshotRetainedObjectInfo
Review URL: https://chromiumcodereview.appspot.com/9323064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10614 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The detailed heap snapshot has two groups of nodes. The first one
is the group for v8 heap nodes and the second one is the group for
native objects. At the moment we have two different sets of native
objects. There are 'Detached DOM trees' and 'Document DOM trees' type of objects.
I think it'd be nice to replace one group containing all native objects with
separate groups for different types of native objects.
BUG=none
TEST=HeapSnapshotRetainedObjectInfo
Review URL: https://chromiumcodereview.appspot.com/9223009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
As taking a snapshot of a large heap takes noticeable time, it's
good to be able to monitor and control it.
The change itself is small, big code deletes and additions are in
fact moves. The only significant change is simplification of
approximated retained sizes calculation algorithm.
Review URL: http://codereview.chromium.org/5687003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Approximation is done by building a dominators tree for the heap graph.
Dominator nodes and retained sizes are serialized into JSON.
Removed:
- reachable size (it is useless, after all);
- HeapEntryCalculatedData (size is now stored in the node, retaining
paths in a hash map);
Review URL: http://codereview.chromium.org/5154007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5867 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
