On 2014/09/15 09:52:06, Denis Pravdin wrote:
On 2014/09/12 13:46:28, yurys wrote:
> On 2014/09/11 08:14:44, Denis Pravdin wrote:
> >
>
https://codereview.chromium.org/424973004/diff/200001/test/cctest/test-cpu-profiler.cc
> > File test/cctest/test-cpu-profiler.cc (right):
> >
> >
>
https://codereview.chromium.org/424973004/diff/200001/test/cctest/test-cpu-profiler.cc#newcode1099
> > test/cctest/test-cpu-profiler.cc:1099: if
(func->code()->is_optimized_code())
> {
> > On 2014/09/10 08:05:14, yurys wrote:
> > > You can use "%NeverOptimizeFunction(func)" or
%OptimizeFunctionOnNextCall
to
> > > make this more deterministic.
> >
> > The test should check optimized code also. I suggest to stay as is
because
to
> > test both optimized and non-optimized version of function.
>
> In that case the test should always check both versions while current
> implementation will behave differently depending on --no-crankshaft
flag. Do
we
> have any bots that run tests with that flag? If no then we will always
test
only
> one of the two paths. Also if the test depends on some command line
flag you
can
> explicitly set it right in the test.
>
>
https://codereview.chromium.org/424973004/diff/200001/src/profile-generator.cc
> File src/profile-generator.cc (right):
>
>
https://codereview.chromium.org/424973004/diff/200001/src/profile-generator.cc#newcode688
> src/profile-generator.cc:688: if (src_line_not_found && *entry) {
> On 2014/09/11 08:14:44, Denis Pravdin wrote:
> > On 2014/09/10 08:05:14, yurys wrote:
> > > With this approach we may end up with top entry being pc_entry while
> src_line
> > > will be calculated for another entry which is wrong. We should also
check
> here
> > > that current entry is the first one non-null in the path.
> >
> > pc_offset that used to calculate src_line is taken for the first
non-null
> entry
> > in the path only. Exactly this entry will represent a node in profile
(when
> the
> > path and src_line go to AddPathToCurrentProfiles).
>
> If src_line = pc_entry->GetSourceLine(pc_offset); (line 652) returns
> kNoLineNumberInfo you will end up calculating line number for the first
non-null
> entry after it here. This will result in entries = [pc_entry, entry1,
> entry2,...NULL] and src_line calculated for entry1 or am I missing
something?
Yes, you got it right - line number is calculated for the first non-null
entry
in the stack but not for sample frame. For example, it may happen when a
sampled
JS function does not have line number info (positions in reloc info). Is
it
possible situation for JS function?
I'm not sure if, but I think it might happen for some functions loaded from
the
snapshot, also functions with hand-written code will not have such info I
guess.
To fix we can use line_number() method of Code object if pc_entry does not
have
line number info. If pc_entry->line_number() returns kNoLineNumberInfo
that
src_line = 0.
Will it work?
Yes, I think that should be fine to attribute all hits to the first line
for the
code objects that don't have line info.
https://codereview.chromium.org/424973004/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
