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 at 10:25:30, Sven Panne wrote:
Hmmm, returning this by reference is not nice: Looking at the use
sites of this function, I fail to see why it is even correct, i.e. why
the CompilationInfo is still alive at that point. Even if it *was*
correct, let's not do this, reasoning globally about tricky lifetimes is
a recipe for bugs later: Just return this by value, there should only be
a tiny handful of entries in it (AFAICT).
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).
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.
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.
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.
