- 11 Feb, 2019 1 commit
-
-
Alexei Filippov authored
The line number is associated with each sample along with pointer to the ProfileNode and timeDelta. Once collected line numbers are streamed as an array of integers in "ProfileChunk" trace events. If all the line numbers are zero, the array may be omitted. Otherwise the array length matches length of samples and timeDeltas arrays. BUG=chromium:925089 Change-Id: I1ef5cd1b208b03bb127f4d17b1efa74c01959542 Reviewed-on: https://chromium-review.googlesource.com/c/1459739Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59514}
-
- 21 Jan, 2019 1 commit
-
-
Peter Marshall authored
- Use unique ptrs for owned objects - Remove friendship with CpuProfiler and replace with public API - Remove unused method LogFailure() - Remove StopProfiler() which was only used by LogFailure() (removed) and one test, which can use StopProfilerThread() instead - Remove 'paused' state which was only used by the above - Remove 'engage' state. There is no reason we need this as along as users keep track of Engage/Disengage calls Drive-by cleanup: - Remove import of log.h from profile-generator.h - Remove unnecessary includes of log.h Change-Id: Ifc4ca156bef038c40953f8361ffea17788e3a59b Reviewed-on: https://chromium-review.googlesource.com/c/1424338 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58957}
-
- 15 Jan, 2019 2 commits
-
-
Maya Lekova authored
This reverts commit 48feba60. Reason for revert: Some TSAN failures reoccurred - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/24456 Original change's description: > Reland "[cpu-profiler] Add more logging to find flaky failure" > > This is a reland of 138bcfc3 > > Fixed all the data races and ran TSAN locally to confirm. > > Original change's description: > > [cpu-profiler] Add more logging to find flaky failure > > > > There is a flaky 5x failure in the tree which I can't reproduce locally. > > This extra logging will help flush out what the problem is. > > > > Bug: v8:8649 > > > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58796} > > Bug: v8:8649 > Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c > Reviewed-on: https://chromium-review.googlesource.com/c/1411633 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58833} TBR=jgruber@chromium.org,petermarshall@chromium.org Change-Id: Icd779b0bd0faf1db76a17736b70617e6b1d6584f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8649 Reviewed-on: https://chromium-review.googlesource.com/c/1412458Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#58834}
-
Peter Marshall authored
This is a reland of 138bcfc3 Fixed all the data races and ran TSAN locally to confirm. Original change's description: > [cpu-profiler] Add more logging to find flaky failure > > There is a flaky 5x failure in the tree which I can't reproduce locally. > This extra logging will help flush out what the problem is. > > Bug: v8:8649 > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58796} Bug: v8:8649 Change-Id: I53e293ef85a54d4b2b39aa3b980832031201aa0c Reviewed-on: https://chromium-review.googlesource.com/c/1411633 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58833}
-
- 14 Jan, 2019 2 commits
-
-
Michael Achenbach authored
This reverts commit 138bcfc3. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20TSAN/24434 Original change's description: > [cpu-profiler] Add more logging to find flaky failure > > There is a flaky 5x failure in the tree which I can't reproduce locally. > This extra logging will help flush out what the problem is. > > Bug: v8:8649 > > Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 > Reviewed-on: https://chromium-review.googlesource.com/c/1402787 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58796} TBR=cbruni@chromium.org,petermarshall@chromium.org Change-Id: Iea4a950ddbbbbc753cffc605f0c0da049cdad03d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8649 Reviewed-on: https://chromium-review.googlesource.com/c/1409433Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#58800}
-
Peter Marshall authored
There is a flaky 5x failure in the tree which I can't reproduce locally. This extra logging will help flush out what the problem is. Bug: v8:8649 Change-Id: If36d2ce0f4feb398d7d746d69b417bb55a714422 Reviewed-on: https://chromium-review.googlesource.com/c/1402787 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58796}
-
- 08 Jan, 2019 1 commit
-
-
Peter Marshall authored
Within an inline stack we would have multiple copies of the exact same CodeEntry object to represent an inline frame. We had one copy for every time that the frame appeared in an inline stack. One CodeEntry can have multiple inline stacks and each stack can have multiple inline frames. In the common case, the stacks overlap and repeat frames. This CL creates a single CodeEntry object to represent each inlined function as an inline frame (for a given CodeEntry with inlinings). This removes most of the duplication of inline CodeEntry objects. We still have some duplication, e.g. if we inline bar() into foo() and foo2() but they are not themselves inlined into anything, then we will have two inline CodeEntry objects for bar(). Removing all duplication is harder to achieve because the lifetime of the inlined frame CodeEntry is now no longer tied to the inliner. Get rid of the InlineEntry struct as it is now indentical to CodeEntryAndLineNumber. We store the list of canonical inline CodeEntry objects on the CodeObject of the inlining function so that it can own the lifetimes of inlined frames. Also rename inline_locations_ to inline_stacks_ to be clearer. Bug: v8:7719 Change-Id: Ied765b4cce7fd33f3290798331f1e6767cc42e8c Reviewed-on: https://chromium-review.googlesource.com/c/1396086 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#58639}
-
- 04 Jan, 2019 2 commits
-
-
Peter Marshall authored
Previously we stored the source position table, which stored a mapping of pc offsets to line numbers, and the inline_locations, which stored a mapping of pc offsets to stacks of {CodeEntry, line_number} pairs. This was slightly wasteful because we had two different tables which were both keyed on the pc offset and contained some overlapping information. This CL combines the two tables in a way. The source position table now maps a pc offset to a pair of {line_number, inlining_id}. If the inlining_id is valid, then it can be used to look up the inlining stack which is stored in inline_locations, but is now keyed by inlining_id rather than pc offset. This also has the nice effect of de-duplicating inline stacks which we previously duplicated. The new structure is similar to how this data is stored by the compiler, except that we convert 'source positions' (char offset in a file) into line numbers as we go, because we only care about attributing ticks to a given line. Also remove the helper RecordInliningInfo() as this is only actually used to add inline stacks by one caller (where it is now inlined). The other callers would always bail out or are only called from test-cpu-profiler. Remove AddInlineStack and replace it with SetInlineStacks which adds all of the stacks at once. We need to do it this way because the source pos table is passed into the constructor of CodeEntry, so we need to create it before the CodeEntry, but the inline stacks are not (they are part of rare_data which is not always present), so we need to add them after construction. Given that we calculate both the source pos table and the inline stacks before construction, it's just easier to add them all at once. Also add a print() method to CodeEntry to make future debugging easier as I'm constantly rewriting this locally. Bug: v8:8575, v8:7719, v8:7203 Change-Id: I39324d6ea13d116d5da5d0a0d243cae76a749c79 Reviewed-on: https://chromium-review.googlesource.com/c/1392195 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58554}
-
Peter Marshall authored
Currently in both kCallerLineNumbers and kLeafNodeLineNumbers modes, we correctly capture inline stacks. In leaf number mode, this is simple as we simply add the path onto the existing tree. For caller line numbers mode this is more complex, because each path through various inlined function should be represented in the tree, even when there are multiple callsites to the same function inlined. Currently we don't correctly show line numbers for inlined functions. We do actually have this information though, which is generated by turbofan and stored in the source_position_table data structure on the code object. This also changes the behavior of the SourcePositionTable class. A problem we uncovered is that the PC that the sampler provides for every frame except the leaf is the return address of the calling frame. This address is *after* the call has already happened. It can be attributed to the next line of the function, rather than the calling line, which is wrong. We fix that here by using lower_bound in GetSourceLineNumber. The same problem happens in GetInlineStack - the PC of the caller is actually the instruction after the call. The information turbofan generates assumes that the instruction after the call is not part of the call (fair enough). To fix this we do the same thing as above - use lower_bound and then iterate back by one. TBR=alph@chromium.org Bug: v8:8575, v8:8606 Change-Id: Idc4bd4bdc8fb70b70ecc1a77a1e3744a86f83483 Reviewed-on: https://chromium-review.googlesource.com/c/1374290 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58545}
-
- 28 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If405611d359d29ae1958beebd9202e068434a621 Reviewed-on: https://chromium-review.googlesource.com/c/1350286 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57918}
-
- 27 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I4da6404aa968adca1fbb49029fc304622101d6c3 Reviewed-on: https://chromium-review.googlesource.com/c/1349112 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57853}
-
- 20 Sep, 2018 1 commit
-
-
Yang Guo authored
We now clearly differentiate between: - unseeded hash for 32-bit integers - unseeded hash for 64-bit integers - seeded hash for 32-bit integers - seeded hash for strings R=bmeurer@chromium.org Bug: chromium:680662 Change-Id: I7459958c4158ee3501c962943dff8f33258bb5ce Reviewed-on: https://chromium-review.googlesource.com/1235973 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56068}
-
- 27 Jul, 2018 1 commit
-
-
Peter Marshall authored
Previously we used the start address of the AbstractCode object. This doesn't make sense for off-heap builtins, where the code isn't contained in the object itself. It also hides other potential problems - sometimes the sample.pc is inside the AbstractCode object header - this is never valid. There were a few changes necessary to make this happen: - Change the interface of CodeMoveEvent. Now 'to' and 'from' are both AbstractCode objects, which is nice because many users were taking 'to' and adding the header offset to it to try and find the instruction start address. This isn't valid for off-heap builtins. - Fix a bug in CodeMap::MoveCode where we didn't update the CodeEntry object to reflect the new instruction_start. - Rename the 'start' field in all of the CodeEventRecord sub-classes to make it clear that this is the address of the first instruction. - Fix the confusion in RecordTickSample between 'tos' and 'pc' which caused pc_offset to be calculated incorrectly. Bug: v8:7983 Change-Id: I3e9dddf74e4b2e96a5f031d216ef7008d6f184d1 Reviewed-on: https://chromium-review.googlesource.com/1148457 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#54749}
-
- 03 Jul, 2018 1 commit
-
-
Alexei Filippov authored
Using CpuProfile pointer is not safe for id as the profile objects can be recreated on the same memory address. Use sequential numbers instead. Change-Id: I7253605819055bc3396b797f9ce27669e8c2584d Reviewed-on: https://chromium-review.googlesource.com/1123325Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#54180}
-
- 24 May, 2018 1 commit
-
-
Peter Marshall authored
We store deopt inline frames for all functions when we receive the code creation event. We only ever use this information for code which is deoptimized. Given that we receive code deopt events, we can just store this information when the code is deoptimized. At the time of the code deopt event, we also know the associated deopt_id. That means we don't need to store a map of deopt_ids to vectors of frames, because we will only ever access the frames for the deopt_id that is already set. This means we store way less data, particularly for long-running processes which see fewer deopts. This saves 10MiB peak memory on the node server example. Bug: v8:7719 Change-Id: If6cf5ec413848e4c9f3c1e2106366ae2adae6fb1 Reviewed-on: https://chromium-review.googlesource.com/1050289 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53330}
-
- 23 May, 2018 3 commits
-
-
Alexei Filippov authored
The patch makes it manage a free list of released code_entries_ slots, and reuse the slots as needed. BUG=v8:7719 Change-Id: I07df1ce983fe00e0ca3d1a1ea20e1a141aabad99 Reviewed-on: https://chromium-review.googlesource.com/1062769Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53314}
-
Alexei Filippov authored
BUG=chromium:844150 Change-Id: I0f7e10fb9778b3de76591ad4819be45c8c50c8d4 Reviewed-on: https://chromium-review.googlesource.com/1064815Reviewed-by: Stephan Herhut <herhut@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53313}
-
Peter Marshall authored
The current profiling mode (called kLeafNodeLineNumbers in this CL) produces a tree, with each node representing a stack frame that is seen in one or more samples taken during profiling. These nodes refer to a particular function in a stack trace, but not to a particular line or callsite within that function. This CL adds a new more (called kCallerLineNumbers) which produces a different profile tree, where each stack trace seen during profiling, including the line number, has a unique path in the tree. The profile tree was previously keyed on CodeEntry*. Now it is keyed on the pair of CodeEntry* and line_number, meaning it has distinct nodes for those combinations which exist, and each distinct stack trace that was sampled is represented in the tree. For optimized code where we have inline frames, there are no line numbers for the inline frames in the stack trace, causing duplicate branches in the tree with kNoLineNumberInfo as the reported line number. This will be addressed in follow-ups. Bug: v8:7018 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I512e221508f5b50ec028306d212263b514a9fb24 Reviewed-on: https://chromium-review.googlesource.com/1013493 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#53298}
-
- 22 May, 2018 1 commit
-
-
Peter Marshall authored
This map is often quite small and holds small items (ints) so wastes quite a bit of overhead in the backing tree representation. This CL changes the std::map to a sorted vector of pairs. This reduces the size significantly (2.13 MiB -> 598 KiB on the node server example). Bug: v8:7719 Change-Id: Ic829693f007732ae145fae02850a1ed913cd941e Reviewed-on: https://chromium-review.googlesource.com/1064233 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53278}
-
- 18 May, 2018 1 commit
-
-
Peter Marshall authored
This was set very regularly in FillFunctionInfo, but it was almost always set to kNoReason, because the associated SFI had no bailout reason. Given that having a bailout reason is the rare case, we just assume an empty bailout reason, and use the rare_data_ struct to store the string pointer if we do need it. This saves another pointer of space on the CodeEntry object (approx 1.4 MiB on the node server example). Bug: v8:7719 Change-Id: I8e2272b572285ddf353ba0b303e6da095b7d5272 Reviewed-on: https://chromium-review.googlesource.com/1064370 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53244}
-
- 16 May, 2018 1 commit
-
-
Alexei Filippov authored
Currently ProfilerListener holds all the CodeEntries it ever created during the profiling session. It is not capable of removing entries corresponding to the code objects discarded by GC as there's no such code event. However it is sometimes possible to tell if a code object was GCed. Hook up to the CodeMap code entry removal and if the entry has never been hit by a sample we can safely delete it. As a bonus the CodeEntryInfo size has been reduced on x64, which also saves 8 x <number of code entries> bytes. BUG=v8:7719 Change-Id: I988bc5b59f3fba07157a9f472cbcf68596fcd969 Reviewed-on: https://chromium-review.googlesource.com/1054346Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53222}
-
- 11 May, 2018 1 commit
-
-
Alexei Filippov authored
Change-Id: I8b9308d7628d7efc2a2212ef3a3aa52ccddbfb36 Reviewed-on: https://chromium-review.googlesource.com/1048036 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#53133}
-
- 07 May, 2018 2 commits
-
-
Alexei Filippov authored
The RareData objects contain fields that often absent in CodeEntry'es. They are created as needed when a corresponding field is added. This reduces CodeEntry size on x64 by 40% from 136 to 80 bytes. BUG=v8:7719 Change-Id: I1f3c6255aa2f228895e835b536c743396131db31 Reviewed-on: https://chromium-review.googlesource.com/1045885Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53039}
-
Peter Marshall authored
We can save a pointer of space for each CodeEntry by removing this field which we don't really need. Instead of concatenating the name string on demand, concatenate the prefix eagerly. Reduces sizeof(CodeEntry) from 136 to 128 on 64-bit. Bug: v8:7719 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Id346a8f36794e337e8c886f8d1969431424539b0 Reviewed-on: https://chromium-review.googlesource.com/1039825Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#53014}
-
- 04 May, 2018 1 commit
-
-
Alexei Filippov authored
ProfilerListener which holds CodeEntries has been moved from Logger to CpuProfiler. This way we can clear entries when all the profiles produced by a particular CpuProfiler are deleted. BUG=v8:7719 Change-Id: I31d47dc7da44648c8fb8e87b47e2e6260d3dc5c3 Reviewed-on: https://chromium-review.googlesource.com/1043050Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#53004}
-
- 23 Apr, 2018 1 commit
-
-
Peter Marshall authored
There doesn't seem to be any reason to use our custom hashmap here, which has a more complicated interface. Change-Id: Ib08c2e400a3cb402a5984b925034aac29750c2ec Reviewed-on: https://chromium-review.googlesource.com/1019445Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#52724}
-
- 14 Apr, 2018 1 commit
-
-
Jakob Kummerow authored
The "Address" type is V8's general-purpose type for manipulating memory addresses. Per the C++ spec, pointer arithmetic and pointer comparisons are undefined behavior except within the same array; since we generally don't operate within a C++ array, our general-purpose type shouldn't be a pointer type. Bug: v8:3770 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779 Reviewed-on: https://chromium-review.googlesource.com/988657 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#52601}
-
- 12 Apr, 2018 1 commit
-
-
Peter Marshall authored
Looking up line numbers with the JITLineInfoTable would sometimes give wrong answers. Fix these bugs and add a cctest for this data structure. Also do some cleanup while we're here like inlining the (empty) constructor and destructor and removing the empty() method which is only used unnecessarily anyway, to make the contract of GetSourceLineNumber a bit clearer. Also rename the data structure to SourcePositionTable, because it doesn't just provide info for JIT code, but also bytecode, and 'Info' is pretty ambiguous. Bug: v8:7018 Change-Id: I126581c844d85df6b2b3f80f2f5acbce01c16ba1 Reviewed-on: https://chromium-review.googlesource.com/1006795Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#52571}
-
- 23 Feb, 2018 1 commit
-
-
Marja Hölttä authored
BUG=v8:7490, v8:7310 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2eb6897d9dcc72cc6f399a8752b9f30d7d7010f8 Reviewed-on: https://chromium-review.googlesource.com/934504Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#51523}
-
- 06 Feb, 2018 1 commit
-
-
Franziska Hinkelmann authored
Use unique pointers in vectors of current and finished profiles. Change-Id: Ifb78f7d3804e9883062741fd4e4e31109965d501 Reviewed-on: https://chromium-review.googlesource.com/898984 Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#51113}
-
- 05 Feb, 2018 1 commit
-
-
Franziska Hinkelmann authored
Change-Id: Ia1289985fa715ce4de66bec91675279c203afa36 Reviewed-on: https://chromium-review.googlesource.com/897811Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#51091}
-
- 02 Feb, 2018 1 commit
-
-
Franziska Hinkelmann authored
Small cleanup. Change-Id: I80f7ede4de1aed3e37c2b20cb3706cb9ef3aa9be Reviewed-on: https://chromium-review.googlesource.com/897810Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#51056}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 07 Sep, 2017 1 commit
-
-
Peter Marshall authored
Bug: v8:6333 Change-Id: Ibc704172ebc796977b8d8cfae6976666d186f12c Reviewed-on: https://chromium-review.googlesource.com/652450 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47890}
-
- 29 Aug, 2017 1 commit
-
-
Peter Marshall authored
Bug: v8:6333 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Iabaef0e63c81db503eb2f19bf63a1f77313f2a5a Reviewed-on: https://chromium-review.googlesource.com/635591 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47681}
-
- 27 Jan, 2017 1 commit
-
-
alph authored
BUG=v8:5753 Review-Url: https://codereview.chromium.org/2655963003 Cr-Commit-Position: refs/heads/master@{#42720}
-
- 19 Dec, 2016 2 commits
-
-
machenbach authored
Revert of [profiler] fix memory leak for code entries for runtime callstats. (patchset #1 id:1 of https://codereview.chromium.org/2586923002/ ) Reason for revert: Looks like the layout tests want these leaks: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/12151 See: https://github.com/v8/v8/wiki/Blink-layout-tests Original issue's description: > [profiler] fix memory leak for code entries for runtime callstats. > > Track allocated code entries and delete at the end. This is what we > do in ProfileListener too. > > R=alph@chromium.org, cbruni@chromium.org > BUG=v8:5753 > > Review-Url: https://codereview.chromium.org/2586923002 > Cr-Commit-Position: refs/heads/master@{#41793} > Committed: https://chromium.googlesource.com/v8/v8/+/d0bb789f0358851b6580a274e2b5f2a8f728f44b TBR=cbruni@chromium.org,alph@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5753 Review-Url: https://codereview.chromium.org/2590483002 Cr-Commit-Position: refs/heads/master@{#41806}
-
yangguo authored
Track allocated code entries and delete at the end. This is what we do in ProfileListener too. R=alph@chromium.org, cbruni@chromium.org BUG=v8:5753 Review-Url: https://codereview.chromium.org/2586923002 Cr-Commit-Position: refs/heads/master@{#41793}
-
- 22 Nov, 2016 1 commit
-
-
tebbi authored
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 Review-Url: https://codereview.chromium.org/2503393002 Cr-Commit-Position: refs/heads/master@{#41168}
-
- 28 Oct, 2016 1 commit
-
-
alph authored
These are added to the sampler stack trace when RCS are enabled. Resource name for a RCS frame is reported as "V8Runtime". Counter names match ones from src/counters.h BUG=chromium:660428 Review-Url: https://codereview.chromium.org/2461003002 Cr-Commit-Position: refs/heads/master@{#40658}
-