- 03 Apr, 2019 1 commit
-
-
Andrew Comminos authored
Adds the notion of a "source type" to CpuProfileNode instances, hinting at the underlying source of the function or state that resulted in the generation of the node. Bug: v8:9001 Change-Id: Ie14c54d41b99eb02f54b423fa5d939e9d7f63785 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510576 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#60590}
-
- 13 Mar, 2019 1 commit
-
-
Andrew Comminos authored
Enable cross-origin frame filtering by exposing this bit from ScriptOriginOptions. Bug: v8:8956 Change-Id: I109eec9db8b3d42d68d32abc5edd437b1c91a9b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1493294 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#60205}
-
- 23 May, 2018 1 commit
-
-
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}
-
- 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}
-
- 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}
-
- 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}
-
- 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}
-
- 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}
-
- 20 Dec, 2016 1 commit
-
-
alph authored
Revert of [profiler] Add extra CHECK to track down crbug.com/665398 (patchset #1 id:1 of https://codereview.chromium.org/2556833003/ ) Reason for revert: Not needed anymore. The bug is fixed. Original issue's description: > [profiler] Add extra CHECK to track down crbug.com/665398 > > BUG=chromium:665398 > > Committed: https://crrev.com/dfc0bb63a1bc115d39f29cfc338aed5676578c4b > Cr-Commit-Position: refs/heads/master@{#41545} TBR=yangguo@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:665398 Review-Url: https://codereview.chromium.org/2588973003 Cr-Commit-Position: refs/heads/master@{#41830}
-
- 07 Dec, 2016 1 commit
-
-
alph authored
BUG=chromium:665398 Review-Url: https://codereview.chromium.org/2556833003 Cr-Commit-Position: refs/heads/master@{#41545}
-
- 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}
-
- 06 Oct, 2016 1 commit
-
-
alph authored
A new V8 API object v8::TracingCpuProfiler is introduced. Client can create it on an isolate to enable JS CPU profiles collected during tracing session. Once the v8.cpu_profile2 tracing category is enabled the profiler emits CpuProfile and CpuProfileChunk events with the profile data. BUG=chromium:406277 Review-Url: https://codereview.chromium.org/2396733002 Cr-Commit-Position: refs/heads/master@{#40054}
-
- 19 Jul, 2016 1 commit
-
-
mstarzinger authored
This allows to pass deoptimization reasons to the profiler without the requirement of always providing a source position. The absence of deopt reasons is now communicated via a sentinel as the deopt id value. The deoptimization reasons recently added to TurboFan are now passed to the profiler. R=bmeurer@chromium.org TEST=cctest/test-cpu-profiler Review-Url: https://codereview.chromium.org/2159793002 Cr-Commit-Position: refs/heads/master@{#37852}
-
- 15 Jun, 2016 1 commit
-
-
alph authored
The patch introduces a dedicated dispatching class for JIT code events. It is set as a helper on the isolate. This allows classes across v8 to break their dependency on Logger and CpuProfiler. These two became just regular clients of the dispatcher. BUG=v8:4789 Review-Url: https://codereview.chromium.org/2061623002 Cr-Commit-Position: refs/heads/master@{#37005}
-
- 30 Nov, 2015 1 commit
-
-
jochen authored
R=vogelheim@chromium.org LOG=n BUG=v8:2487 Review URL: https://codereview.chromium.org/1474353002 Cr-Commit-Position: refs/heads/master@{#32389}
-
- 01 Oct, 2015 1 commit
-
-
alph authored
It was supposed to be used by the CPU profiler. But as long as these ranges are not built when profiler is not running, once the profiler is started there're no ranges for already compiled functions. So basically this code never worked. As long as now CPU profiler uses another approach this code is no longer needed. Review URL: https://codereview.chromium.org/1376333003 Cr-Commit-Position: refs/heads/master@{#31056}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 28 Sep, 2015 1 commit
-
-
alph authored
Drive-by: remove unnecessary includes. Review URL: https://codereview.chromium.org/1356223004 Cr-Commit-Position: refs/heads/master@{#30987}
-
- 11 Sep, 2015 1 commit
-
-
yurys authored
BUG=None LOG=N Review URL: https://codereview.chromium.org/1332683002 Cr-Commit-Position: refs/heads/master@{#30702}
-
- 27 Feb, 2015 1 commit
-
-
loislo authored
Save Unknown position as zero in RelocInfo. Remove copy constructor of SourcePosition because it is trivial. Mechanical replace int raw_position with SourcePosition position. BUG=452067 LOG=n Review URL: https://codereview.chromium.org/959203002 Cr-Commit-Position: refs/heads/master@{#26916}
-
- 20 Feb, 2015 1 commit
-
-
loislo authored
We accessed to cpu_profiler for tracking SharedFunctionInfo objects movements and used their addresses for generating function_id. Actually we could replace the manually generated shared_id by the pair script_id + position. In this case we can drop SharedFunctionInfo events support from cpu_profiler and remove the dependency. BTW GetCallUid was used as an unique identifier of the function on the front-end side. Actually it is a hash which might not be unique. So I renamed GetCallUid with GetHash and implemented GetFunctionId method. BUG=452067 LOG=n Review URL: https://codereview.chromium.org/941973002 Cr-Commit-Position: refs/heads/master@{#26775}
-
- 12 Feb, 2015 3 commits
-
-
loislo authored
1) create beefy RelocInfo table when cpu profiler is active, so if a function was optimized when profiler was active RelocInfo would get separate DeoptInfo for the each deopt case. 2) push DeoptInfo from CodeEntry to ProfileNode. When deopt happens we put the info collected on #1 into CodeEntry and record stack sample. On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list. Sample profile dump. [Top down]: 0 (root) 0 #1 1 29 #2 1 test 29 #3 2 opt_function 29 #4 2 opt_function 29 #5 deopted at 118 with reason 'not a heap number' deopted at 137 with reason 'division by zero' BUG=452067 LOG=n Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54 Cr-Commit-Position: refs/heads/master@{#26615} Review URL: https://codereview.chromium.org/919953002 Cr-Commit-Position: refs/heads/master@{#26630}
-
loislo authored
Revert of CPUProfiler: Push deopt reason further to ProfileNode. (patchset #1 id:1 of https://codereview.chromium.org/919953002/) Reason for revert: static initializers broke the build Original issue's description: > CPUProfiler: Push deopt reason further to ProfileNode. > > 1) create beefy RelocInfo table when cpu profiler is active, so if a function > was optimized when profiler was active RelocInfo would get separate DeoptInfo > for the each deopt case. > > 2) push DeoptInfo from CodeEntry to ProfileNode. > When deopt happens we put the info collected on #1 into CodeEntry and record stack sample. > On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list. > > Sample profile dump. > [Top down]: > 0 (root) 0 #1 > 1 29 #2 > 5 test 29 #3 > 3 opt_function 29 #4 > deopted at 52 with reason 'not a heap number' > deopted at 71 with reason 'division by zero' > > BUG=452067 > LOG=n > > Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54 > Cr-Commit-Position: refs/heads/master@{#26615} TBR=jarin@chromium.org,svenpanne@chromium.org,yurys@chromium.org,alph@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=452067 Review URL: https://codereview.chromium.org/915173005 Cr-Commit-Position: refs/heads/master@{#26616}
-
loislo authored
1) create beefy RelocInfo table when cpu profiler is active, so if a function was optimized when profiler was active RelocInfo would get separate DeoptInfo for the each deopt case. 2) push DeoptInfo from CodeEntry to ProfileNode. When deopt happens we put the info collected on #1 into CodeEntry and record stack sample. On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list. Sample profile dump. [Top down]: 0 (root) 0 #1 1 29 #2 5 test 29 #3 3 opt_function 29 #4 deopted at 52 with reason 'not a heap number' deopted at 71 with reason 'division by zero' BUG=452067 LOG=n Review URL: https://codereview.chromium.org/919953002 Cr-Commit-Position: refs/heads/master@{#26615}
-
- 10 Feb, 2015 1 commit
-
-
loislo authored
1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo because it also has raw position. Also the old name clashes with DeoptReason enum. 2) c_entry_fp assignment call was added to EntryGenerator::Generate So we can calculate sp and have a chance to record the stack for the deopting function. btw it makes the test stable. 3) new kind of CodeEvents was added to cpu-profiler 4) GetDeoptInfo method was extracted from PrintDeoptLocation. So it could be reused in cpu profiler. BUG=452067 LOG=n Review URL: https://codereview.chromium.org/910773002 Cr-Commit-Position: refs/heads/master@{#26545}
-
- 06 Nov, 2014 1 commit
-
-
svenpanne@chromium.org authored
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>; 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
-
- 05 Nov, 2014 1 commit
-
-
jkummerow@chromium.org authored
Shave this yak from orbit, it's the only way to be sure. BUG=chromium:427616 LOG=n R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/700963002 Cr-Commit-Position: refs/heads/master@{#25148} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25148 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Oct, 2014 2 commits
-
-
yurys@chromium.org authored
Revert of Extend CPU profiler with mapping ticks to source lines (patchset #3 id:40001 of https://codereview.chromium.org/616963005/) 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=24389 TBR=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
-
yurys@chromium.org authored
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
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Mar, 2014 1 commit
-
-
marja@chromium.org authored
- Distinguish between context bound scripts (Script) and context unbound scripts (UnboundScript). - Add ScriptCompiler (which will later contain functions for async compilation). This is a breaking change, in particular, Script::New no longer exists (it is replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a backwards-compatible shorthand for ScriptCompiler::Compile. Passing CompilerOptions with produce_data_to_cache = true doesn't do anything yet; the only way to generate the data to cache is the old preparsing API. (To be fixed in the next version.) This is a fixed version of https://codereview.chromium.org/186723005/ BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/199063003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Mar, 2014 2 commits
-
-
marja@chromium.org authored
This reverts revision 19881. Reason: WebKit build failure (will commit a fixed version shortly). BUG= Review URL: https://codereview.chromium.org/196793013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
marja@chromium.org authored
- Distinguish between context bound scripts (Script) and context unbound scripts (UnboundScript). - Add ScriptCompiler (which will later contain functions for async compilation). This is a breaking change, in particular, Script::New no longer exists (it is replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a backwards-compatible shorthand for ScriptCompiler::Compile. Passing CompilerOptions with produce_data_to_cache = true doesn't do anything yet; the only way to generate the data to cache is the old preparsing API. (To be fixed in the next version.) BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/186723005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19881 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Oct, 2013 1 commit
-
-
yurys@chromium.org authored
Otherwise the string passed as const char* may be disposed and we will end up with a dangling pointer. Also changed StringsStorage::GetCopy so that a copy is not created if the string is already in the cache. BUG=None R=alph@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/27627006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17260 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Oct, 2013 1 commit
-
-
yurys@chromium.org authored
* Removed unused CodeEntry::CopyData * Removed unnecessary INLINE macros BUG=None R=loislo@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/25382003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17180 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Oct, 2013 1 commit
-
-
yurys@chromium.org authored
CpuProfileNode currently exposes only line number which is not enough for the cases when there is more than one function on the same line. This change exposes column number on CpuProfileNode. BUG=302537 R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/25541003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17142 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Sep, 2013 1 commit
-
-
loislo@chromium.org authored
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
-