On 2015/03/24 at 12:09:18, loislo wrote:
On 2015/03/24 at 10:56:55, svenpanne wrote:
> https://codereview.chromium.org/1013143003/diff/190001/src/compiler.h
> File src/compiler.h (right):
>
>
https://codereview.chromium.org/1013143003/diff/190001/src/compiler.h#newcode352
> src/compiler.h:352: const std::vector<InlinedFunctionInfo>&
inlined_function_infos() {
> On 2015/03/24 10:46:34, loislo wrote:
> > 1) We pass CompilationInfo to logger when we finished compilation, so
it
is
> > alive.
> >
> > 2) Profiler copies the inlining info into CodeCreateEvent (it used to
take
the
> > ownership in the previous versions of the patch).
>
> To be exact: It doesn't copy the inlining info at all, it just puts a
reference to CompilationInfo's internal field into the event (i.e. basically
copying a pointer).
We takes a const ref to vector<InliningInfo> and pass it to
set_inlining_function_infos method.
In this method we do the copy of the content of the infos argument into
CodeEvent::inlined_function_infos_
See http://en.cppreference.com/w/cpp/container/vector/operator%3D
>
> > 3) event processor processes all the events (CodeCreate, CodeDeopt,
Sample
with
> > stacktrace, etc) and copies the inlining info into CodeEntry objects
when
it
> > processes CodeCreateEvents. (it used to take the ownership in the
previous
> > versions of the patch). JFYI: CodeEntry maps to Code object one to
one.
>
> Hopefully the CompilationInfo is still alive here. :-)
>
> > 4) event processor resolves a stack of addresses (stacktrace) into a
stack
of
> > CodeEntries.
> >
> > 5) event processor appends the stack of CodeEntries to the profiler
tree,
> > construct new ProfileNodes if necessary, creates DeoptInfo with help
of
> > pc_offset and the InliningInfo and puts it into top-level
ProfileNode. We
always
> > have a stack which finishes in the deopted code because we explicitly
create
> > StackTrace in order of logging the deopt event.
>
> I still don't like this, but I don't want to hold up your progress and
CompilationInfo needs to be refactored heavily, anyway (e.g. the current
part
we're talking about is totally Crankshaft-specific), so let's land this,
but at
least put your reasoning as a comment here if you still want to keep using
the
reference.
Actually turbofan part of code is a terra incognita for me, but I hope I'd
be
able to get the inlining info from it. :)
https://codereview.chromium.org/1013143003/
--
--
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.
