This doesn't support "lookup after interceptor", but that should be unnecessary by now since we have non-masking interceptors.
BUG=
Change-Id: I8650a47ab2ce6fa314de25d0c4775b5c165df179
Reviewed-on: https://chromium-review.googlesource.com/453376
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43766}
This generally shouldn't hit since prototypes are supposed to be fast; but it makes it more uniform anyway.
This CL also drops the limitation not supporting keyed loads with normal access. There's no point in returning the slow stub there.
BUG=
Change-Id: I5578269f6c64762610e885740a692d1e91aa6aa2
Reviewed-on: https://chromium-review.googlesource.com/447698
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43508}
This is mostly prework to also support prototype chain checks using data handlers
BUG=
Change-Id: I70aac1e86e45c78dfdc9f02d06b7e821494a4c9c
Reviewed-on: https://chromium-review.googlesource.com/447679
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43495}
This reverts commit 8307ab709d.
Reason for revert: Breaks TSAN
Original change's description:
> [Counters] Add HistorgramTimers for optimized compile.
>
> Will be used for UMA to track time spent optimizing code in the wild.
>
> Change-Id: Ibc01540552eac4cb9224f1cb6cc11a55aae5834d
> Reviewed-on: https://chromium-review.googlesource.com/444345
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43374}
TBR=rmcilroy@chromium.org,mvstanton@chromium.org,machenbach@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I1cfc2ee599b9ba0132e69c8a61b21ff32c74f68e
Reviewed-on: https://chromium-review.googlesource.com/446360
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43396}
Will be used for UMA to track time spent optimizing code in the wild.
Change-Id: Ibc01540552eac4cb9224f1cb6cc11a55aae5834d
Reviewed-on: https://chromium-review.googlesource.com/444345
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43374}
These counters were used during the initial implementation to gather
statistics about comparative effectiveness of the two escape analysis
approaches in practice. The counters are not thread-safe and cannot be
used for the analysis any longer as it is now running off main thread.
We deprecate the counters in question in favor of maintaining deferred
statistics until the need for such statistics arises again.
R=bmeurer@chromium.org
BUG=chromium:685942
Review-Url: https://codereview.chromium.org/2667453003
Cr-Commit-Position: refs/heads/master@{#42808}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42667}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Original-Commit-Position: refs/heads/master@{#42026}
Committed: b0e9116d59
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42042}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/13358
Original issue's description:
> [Compiler] Track Ignition background compilation separately in RuntimeStats.
>
> Tracks background compilation of Ignition in a separate bucket from main thread
> compilation. Also add some more compilation buckets for functions which can take a
> significant proportion of compilation.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2577263002
> Cr-Commit-Position: refs/heads/master@{#42026}
> Committed: b0e9116d59TBR=jochen@chromium.org,cbruni@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2609773003
Cr-Commit-Position: refs/heads/master@{#42031}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42026}
Currently, to find out a Promise's status and result, one has to use the
debug context. This is for example done in Node.js. This new API is a
better replacement, also in the context of the debug context being
deprecated eventually.
R=franzih@chromium.org, gsathya@chromium.org, jochen@chromium.org
BUG=v8:5764
Review-Url: https://codereview.chromium.org/2589113002
Cr-Commit-Position: refs/heads/master@{#41855}
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}
Reason for revert:
Wronged it even more.
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
> Cr-Commit-Position: refs/heads/master@{#41142}
TBR=ishell@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/2519073002
Cr-Commit-Position: refs/heads/master@{#41150}
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@{#41142}
In the lightweight mode it only maintains pseudo stack and does not
collect timing information. It can be used in the sampling mode.
BUG=chromium:660428
Review-Url: https://codereview.chromium.org/2472193002
Cr-Commit-Position: refs/heads/master@{#40812}
This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40745}
Reason for revert:
Static-Initializers failed on Ubuntu-12.04
Original issue's description:
> [Tracing] Use TracingCategoryObserver in runtime statistics
>
> This patch is a follow-up patch to enable runtime statistics to use
> TracingCategoryObserver.
>
> BUG=v8:5590
TBR=cbruni@chromium.org,fmeawad@chromium.org,alph@chromium.org,bmeurer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2469403005
Cr-Commit-Position: refs/heads/master@{#40743}
This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.
BUG=v8:5590
Review-Url: https://codereview.chromium.org/2460973003
Cr-Commit-Position: refs/heads/master@{#40742}
Make RuntimeCallTimer::parent_ and RuntimeCallStats::current_timer_
fields atomic as they are accessed from the signal handler.
BUG=chromium:660428
Review-Url: https://codereview.chromium.org/2464973002
Cr-Commit-Position: refs/heads/master@{#40709}
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}
Previously we reset runtime counters and dump them when we enter, exit top level
trace events respectively. However, there is gap between two top level trace
events and runtime counters may be activated, resetting the counters makes the
accumulated time inaccurate, and we may end up with negative time due to the
nature of how we accumulate time.
This patch fixes this problem by only resetting counters when there's no
counters active, and before dump counters, we traverse current active counters
to calculate their time, and then restart their timer.
BUG=chromium:658145
Review-Url: https://codereview.chromium.org/2457523002
Cr-Commit-Position: refs/heads/master@{#40653}