... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
Blink uses access checks to be sure that objects from one context doesn't access objects in another. Heap profiler uses current context to call this checks, we need to be sure that current context is empty to allow heap profiler collect all objects without crash.
BUG=chromium:661223
R=alph@chromium.org,ulan@chromium.org
Review-Url: https://codereview.chromium.org/2669393002
Cr-Commit-Position: refs/heads/master@{#42939}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
Reason for revert:
Blocks roll, ASan detects leaking ExternalStrings.
Original issue's description:
> Internalize strings in-place (reland^2)
>
> using newly introduced ThinStrings, which store a pointer to the actual,
> internalized string they represent.
>
> BUG=v8:4520
>
> (Previously landed as #42168 / af51befe69)
> (Previously landed as #42193 / 4c699e349a)
>
> Review-Url: https://codereview.chromium.org/2549773002
> Cr-Commit-Position: refs/heads/master@{#42235}
> Committed: ec45e6ed2eTBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4520
Review-Url: https://codereview.chromium.org/2626893005
Cr-Commit-Position: refs/heads/master@{#42271}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
(Previously landed as #42168 / af51befe69)
(Previously landed as #42193 / 4c699e349a)
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42235}
Reason for revert:
blocks roll, see: https://codereview.chromium.org/2628733002/
Debug mode runs into an Abort("External string expected, but not found").
Original issue's description:
> Internalize strings in-place (reland)
>
> using newly introduced ThinStrings, which store a pointer to the actual,
> internalized string they represent.
>
> BUG=v8:4520
>
> (Previously landed as #42168 / af51befe69.
>
> Review-Url: https://codereview.chromium.org/2549773002
> Cr-Commit-Position: refs/heads/master@{#42193}
> Committed: 4c699e349aTBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4520
Review-Url: https://codereview.chromium.org/2625073002
Cr-Commit-Position: refs/heads/master@{#42212}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
(Previously landed as #42168 / af51befe69.
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42193}
using newly introduced ThinStrings, which store a pointer to the actual,
internalized string they represent.
BUG=v8:4520
Review-Url: https://codereview.chromium.org/2549773002
Cr-Commit-Position: refs/heads/master@{#42168}
This patch fixes OOM crash that happens for large heap where
the total size of edges exceeds 2GB, which is the hard limit
for v8::internal::List allocated using tcmalloc.
BUG=chromium:675911
Review-Url: https://codereview.chromium.org/2595003002
Cr-Commit-Position: refs/heads/master@{#42004}
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}
RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.
BUG=
Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41254}
Reason for revert:
The test is very flaky on the bots, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/17031https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14776
Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Committed: https://crrev.com/491651792d7818aed04eaeffb9890b5a309b543e
> Cr-Original-Commit-Position: refs/heads/master@{#41142}
> Cr-Commit-Position: refs/heads/master@{#41214}
TBR=ishell@chromium.org,fmeawad@chromium.org,lpy@chromium.org,cbruni@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2526843002
Cr-Commit-Position: refs/heads/master@{#41229}
RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.
BUG=
Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
Review-Url: https://codereview.chromium.org/2511093002
Cr-Original-Commit-Position: refs/heads/master@{#41142}
Cr-Commit-Position: refs/heads/master@{#41214}
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}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
These are added to the sampler stack trace when RCS are
enabled.
Resource name for a RCS frame is reported as "V8Runtime".
Counter names match ones from src/counters.h
BUG=chromium:660428
Review-Url: https://codereview.chromium.org/2461003002
Cr-Commit-Position: refs/heads/master@{#40658}
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}
matching function, creates a hashmap the specialises the case of keys
that simply check pointer equality.
I measure an average ~1% improvement on Octane code-load.
Review-Url: https://codereview.chromium.org/2369963002
Cr-Commit-Position: refs/heads/master@{#39920}
Make MatchFun a template parameter in TemplateHashMapImpl, moving the
PointersMatch function down to an implementation which extends
TemplateHashMapImpl to void* key and value (i.e. the same as the current
HashMap and ZoneHashMap typedefs).
This will allow other instantiations of TemplateHashMapImpl, with
different MatchFun values, e.g. std::equal_to, to have their key
equality test inlined, rather than calling a function pointer,
Review-Url: https://codereview.chromium.org/2354593002
Cr-Commit-Position: refs/heads/master@{#39868}
Tracing CPU profiler allows V8 to automatically collect CPU profile when tracing
is started with category v8.cpu_profile2 enabled.
BUG=chromium:406277
Review-Url: https://codereview.chromium.org/2378143003
Cr-Commit-Position: refs/heads/master@{#39855}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.
Subsequent CL will add stats counter for GC reason.
BUG=
Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}
The only remaining use of this VariableMode is for the names of sloppy
named function expressions. This patch instead uses CONST for such
bindings (just as we do in strict mode) and instead marks those
Variables specially. During code generation a new helper method,
Variable::throw_on_const_assignment(), is called to decide whether
to throw or silently ignore the assignment.
Review-Url: https://codereview.chromium.org/2233673003
Cr-Commit-Position: refs/heads/master@{#39052}
This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.
BUG=
Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}
With --ignition-preserve-bytecode, we don't have the guarantee that
SharedFunctionInfo::abstract_code() returns the code we deopt to.
R=mstarzinger@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2239773003
Cr-Commit-Position: refs/heads/master@{#38614}
This patch is based on alph's CL https://codereview.chromium.org/2128613004/.
This patch makes GetStackSample propogate the register state when using
simulator helper, and adds argument to avoid using register state from simulator
when pass the native register state.
BUG=v8:4789
LOG=N
Review-Url: https://codereview.chromium.org/2189513002
Cr-Commit-Position: refs/heads/master@{#38554}
1. Do not mark code_cache as a weak container.
2. Support layout_descriptor field.
Review-Url: https://codereview.chromium.org/2204133002
Cr-Commit-Position: refs/heads/master@{#38285}
introduced in https://crrev.com/72f884a19fa4434bba6fc0e013ec4ea0a2366893
The regression comes from adding the next weak field of AllocationSite
as a hidden reference into the snapshot.
Before 72f884 the reference was implicitly ignored because the body
descriptor of AllocationSite did not include it.
This patch explicitly skip the next weak field of AllocationSite.
BUG=chromium:630027
Review-Url: https://codereview.chromium.org/2189643004
Cr-Commit-Position: refs/heads/master@{#38211}
This reduces the size of GetStrongGcSubrootName() from 77 KB to 10KB.
BUG=5240
Review-Url: https://codereview.chromium.org/2189633003
Cr-Commit-Position: refs/heads/master@{#38123}
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}
So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.
Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2161543002
Cr-Commit-Position: refs/heads/master@{#37823}
When it is in executing JS state there should be a JS stack.
Having no stack means something is wrong with frame pointer, so
just skip the bogus sample.
Review-Url: https://codereview.chromium.org/2151103002
Cr-Commit-Position: refs/heads/master@{#37802}
We want to eventually move the profiling functionality out of V8 as library,
this patch exposes TickSample and its APIs in v8-profiler.h so that when
embedders use library, they can have more details.
Minor change: Rename tick-sample.[h|cc] to simulator-helper.[h|cc].
BUG=v8:4789
LOG=N
Review-Url: https://codereview.chromium.org/2105943002
Cr-Commit-Position: refs/heads/master@{#37564}
Currently there are two logic in Ticker, one is to try to request a
pre-allocated TickSample from CpuProfiler and then initialize it, and if the
request fails, it will initialize a local TickSample. The other is it will pass
an initialized TickSample to Profiler to log into v8.log.
This patch splits Ticker into two samplers, the first one remains in log.cc to
collect samples and pass to Profiler for logging, the second one will be called
by ProfilerEventsProcessor, and only use the circular queue only.
BUG=v8:4789
LOG=N
Review-Url: https://codereview.chromium.org/2108393002
Cr-Commit-Position: refs/heads/master@{#37506}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
Reason for revert:
Looks like this breaks on nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/7626
Original issue's description:
> [builtins] New frame type for exits to C++ builtins
>
> Prior to this commit, calls to C++ builtins created standard exit
> frames, which are skipped when constructing JS stack traces. In order to
> show these calls on traces, we introduce a new builtin exit frame type.
>
> Builtin exit frames contain target and new.target on the stack and are
> not skipped during stack trace construction.
>
> BUG=v8:4815
> R=bmeurer@chromium.org, yangguo@chromium.org
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
> Cr-Commit-Position: refs/heads/master@{#37384}
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4815
Review-Url: https://codereview.chromium.org/2106113002
Cr-Commit-Position: refs/heads/master@{#37394}
Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.
Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.
BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review-Url: https://codereview.chromium.org/2090723005
Cr-Commit-Position: refs/heads/master@{#37384}
The main fix is to mark stack memory the SafeStackFrameIterator
accesses as initialied.
Drive-by: Make sure we bail out when the simulator is in the
process of updating FP/SP registers.
BUG=v8:5156
Review-Url: https://codereview.chromium.org/2104763002
Cr-Commit-Position: refs/heads/master@{#37315}
Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
from Logger, constructs and stores CodeEventsContainer. This patch is part of
the effort to split the logic of CodeEventListener as ProfilerListener out of
the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
to code events, construct code event to CodeEventsContainer and pass it to code
event handler.
The reason we refactor CpuProfiler is that eventually we want to move
CpuProfiler as part of sampler library and code event listener should stay
inside V8.
Main changes:
1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
functionality and the ProfilerListener listening to code events from Logger.
2. Created CodeEventObserver and made CpuProfiler inherit from it.
ProfilerListener will have a list of observers and call CodeEventHandler once a
code event is created.
3. Moved code entry list from CodeEntry to ProfilerListener.
Minor changes:
1. Moved static code entry as part of CodeEntry.
2. Added ProfilerListener to Logger.
BUG=v8:4789
Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
Review-Url: https://codereview.chromium.org/2053523003
Cr-Original-Commit-Position: refs/heads/master@{#37112}
Cr-Commit-Position: refs/heads/master@{#37195}
Reason for revert:
MIPS compilation error.
Original issue's description:
> Refactor CpuProfiler.
>
> Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
> from Logger, constructs and stores CodeEventsContainer. This patch is part of
> the effort to split the logic of CodeEventListener as ProfilerListener out of
> the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
> to code events, construct code event to CodeEventsContainer and pass it to code
> event handler.
>
> The reason we refactor CpuProfiler is that eventually we want to move
> CpuProfiler as part of sampler library and code event listener should stay
> inside V8.
>
> Main changes:
> 1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
> functionality and the ProfilerListener listening to code events from Logger.
> 2. Created CodeEventObserver and made CpuProfiler inherit from it.
> ProfilerListener will have a list of observers and call CodeEventHandler once a
> code event is created.
> 3. Moved code entry list from CodeEntry to ProfilerListener.
>
> Minor changes:
> 1. Moved static code entry as part of CodeEntry.
> 2. Added ProfilerListener to Logger.
>
> BUG=v8:4789
>
> Committed: https://crrev.com/cb59fc1facc9b390e2c7544b4da56a4e0a9b3222
> Cr-Commit-Position: refs/heads/master@{#37112}
TBR=alph@chromium.org,jochen@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2079273003
Cr-Commit-Position: refs/heads/master@{#37113}
Currently CpuProfiler is a subclass of CodeEventListener, it listens code events
from Logger, constructs and stores CodeEventsContainer. This patch is part of
the effort to split the logic of CodeEventListener as ProfilerListener out of
the profiling functionality logic in CpuProfiler. A ProfilerListener will listen
to code events, construct code event to CodeEventsContainer and pass it to code
event handler.
The reason we refactor CpuProfiler is that eventually we want to move
CpuProfiler as part of sampler library and code event listener should stay
inside V8.
Main changes:
1. Refactored CpuProfiler into two parts, the CpuProfiler with profling
functionality and the ProfilerListener listening to code events from Logger.
2. Created CodeEventObserver and made CpuProfiler inherit from it.
ProfilerListener will have a list of observers and call CodeEventHandler once a
code event is created.
3. Moved code entry list from CodeEntry to ProfilerListener.
Minor changes:
1. Moved static code entry as part of CodeEntry.
2. Added ProfilerListener to Logger.
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2053523003
Cr-Commit-Position: refs/heads/master@{#37112}
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}
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.log1p() as TurboFan builtin and use that operator to also
inline Math.log1p() into optimized TurboFan functions.
Also unify the handling of the special IEEE 754 functions somewhat in
the TurboFan backends. At some point we can hopefully express this
completely in the InstructionSelector (once we have an idea what to do
with the ST(0) return issue on IA-32/X87).
Drive-by-fix: Add some more test coverage for the log function.
R=yangguo@chromium.org
BUG=v8:5086,v8:5092
Review-Url: https://codereview.chromium.org/2060743002
Cr-Commit-Position: refs/heads/master@{#36914}
This switches Math.log to use an fdlibm based version of log, imported
as base::ieee754::log, and use that consistently everywhere, i.e. change
the Float64Log TurboFan operators on Intel to use the C++ implementation
as well (same for Crankshaft).
R=yangguo@chromium.org
BUG=v8:5065,v8:5086
Review-Url: https://codereview.chromium.org/2053893003
Cr-Commit-Position: refs/heads/master@{#36880}
We ported hashmap.h into libsampler as a workaround before, so the main focus of
this patch is to reduce code duplication. This patch moves the hashmap into
src/base as well as creates DefaultAllocationPolicy using malloc and free.
BUG=v8:5050
LOG=n
Review-Url: https://codereview.chromium.org/2010243003
Cr-Commit-Position: refs/heads/master@{#36873}
Reason for revert:
Make MSAN arm bot flaky
Original issue's description:
> Move stack trace extraction code out of TickSample::Init
>
> Make it a part of V8 API GetStackSample function.
> Also expose external_callback_entry in SampleInfo to break dependency
> of clients on internal V8 structures.
>
> BUG=v8:4789
>
> Committed: https://crrev.com/70acfe39c07322144f5fe9b40bb584a8b1099ffd
> Cr-Commit-Position: refs/heads/master@{#36831}
TBR=yangguo@chromium.org,lpy@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2049903002
Cr-Commit-Position: refs/heads/master@{#36835}
Make it a part of V8 API GetStackSample function.
Also expose external_callback_entry in SampleInfo to break dependency
of clients on internal V8 structures.
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2007343003
Cr-Commit-Position: refs/heads/master@{#36831}
Using the isolate to check for IsUndefined and IsTheHole is roughly at least
20% faster in the worst-case and up to a factor 2x in the best case.
BUG=
Review-Url: https://codereview.chromium.org/2031533002
Cr-Commit-Position: refs/heads/master@{#36787}
Passing in the isolate and pointer compare the instnance against the
corresponding constant is always faster than decoding the instance types.
BUG=
Review-Url: https://codereview.chromium.org/2028983002
Cr-Commit-Position: refs/heads/master@{#36744}
We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.
BUG=
Review-Url: https://codereview.chromium.org/1906823002
Cr-Commit-Position: refs/heads/master@{#36539}
This patch does five things:
1. Extracts sampler as libsampler to provide sampling functionality support.
2. Makes SampleStack virtual so embedders can override the behaviour of sample collecting.
3. Removes sampler.[h|cc].
4. Moves sampling thread into log.cc as workaround to keep the --prof functionality.
5. Creates SamplerManager to manage the relationship between samplers and threads.
The reason we port hashmap.h is that in debug mode, STL containers are using
mutexes from a mutex pool, which may lead to deadlock when using asynchronously
signal handler.
Currently libsampler is used in V8 temporarily.
BUG=v8:4789
LOG=n
Committed: https://crrev.com/06cc9b7c176a6223971deaa9fbcafe1a05058c7b
Cr-Commit-Position: refs/heads/master@{#36527}
Review-Url: https://codereview.chromium.org/1922303002
Cr-Commit-Position: refs/heads/master@{#36532}
Reason for revert:
V8 Linux64 TSAN failure because ThreadSanitizer indicated data race.
Original issue's description:
> Create libsampler as V8 sampler library.
>
> This patch does five things:
>
> 1. Extracts sampler as libsampler to provide sampling functionality support.
> 2. Makes SampleStack virtual so embedders can override the behaviour of sample collecting.
> 3. Removes sampler.[h|cc].
> 4. Moves sampling thread into log.cc as workaround to keep the --prof functionality.
> 5. Creates SamplerManager to manage the relationship between samplers and threads.
>
> The reason we port hashmap.h is that in debug mode, STL containers are using
> mutexes from a mutex pool, which may lead to deadlock when using asynchronously
> signal handler.
>
> Currently libsampler is used in V8 temporarily.
>
> BUG=v8:4789
> LOG=n
>
> Committed: https://crrev.com/06cc9b7c176a6223971deaa9fbcafe1a05058c7b
> Cr-Commit-Position: refs/heads/master@{#36527}
TBR=jochen@chromium.org,alph@chromium.org,fmeawad@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4789
Review-Url: https://codereview.chromium.org/2000323007
Cr-Commit-Position: refs/heads/master@{#36529}
