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.
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.