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}
Reason for revert:
Seems to block rolling:
https://codereview.chromium.org/2447393005/
Original issue's description:
> [heap] Concurrent store buffer processing.
>
> BUG=chromium:648973, chromium:648568
TBR=ulan@chromium.org,mlippautz@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:648973, chromium:648568
Review-Url: https://codereview.chromium.org/2449853010
Cr-Commit-Position: refs/heads/master@{#40650}
This is useful for things that don't ever change, but we don't want to
eagerly compute the result.
Doing this from the embedder is difficult, using DefineOwnProperty would
read the property to get the property descriptor, creating an endless
recursion.
R=verwaest@chromium.org,haraken@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2449783006
Cr-Commit-Position: refs/heads/master@{#40648}
The order is important for DEFINE_IMPLICATION to ensure transitive
implication: predictable => single_threaded => !concurrent_sweeping.
BUG=5580
Review-Url: https://codereview.chromium.org/2456323002
Cr-Commit-Position: refs/heads/master@{#40644}
The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.
This cuts down bytecode size by roughly 1% (measured on Octane and Top25).
Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
... because the latter unlike the former records meaningful position.
BUG=
Review-Url: https://codereview.chromium.org/2456193005
Cr-Commit-Position: refs/heads/master@{#40640}
This flag is on by default for now. Whenever heuristics in the compiler
pipeline decide to use Ignition+TurboFan, then {BytecodeGraphBuilder} is
active. Removing the flag reduces maintenance overhead.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2437103002
Cr-Commit-Position: refs/heads/master@{#40639}
This CL adds simple implementation of break and stepping-related functionality
as required by the debug-step.js test. This includes
* stepOver, stepInto, stepOut
* setBreakPoint
* clearBreakPoint
* evaluate
Some of these, e.g. setBreakPoint are not fully implemented for all cases but
only for the ones we need right now.
One interesting result of this is that using the inspector protocol is roughly
14x slower for debug-step.js (14s instead of 0.5s). One cause of this seems to
be iteration over all object properties in toProtocolValue, which is used to
serialize JS objects before being sent over the wire (e.g. FrameMirrors). This
is something that should be fixed at some point. In the meantime, the test now
runs 100 instead of 1000 iterations.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2447073007
Cr-Commit-Position: refs/heads/master@{#40636}
This adds a wrapper class around the inspector protocol for use in
debugger tests. The interface is intended to stay similar to the
currently exposed DebuggerContext.
Right now, we support adding a listener, (partial) handling of the
AfterCompile event, and enabling/disabling the debugger.
BUG=v8:5530
Review-Url: https://codereview.chromium.org/2451153003
Cr-Commit-Position: refs/heads/master@{#40635}
In the asm.js to wasm pipeline, we generate an entry function with
BUILTIN code, but still attached to a TYPE_NORMAL script.
This fix avoids trying to set a breakpoint there, resulting in a crash
on DCHECK(shared->HasDebugInfo()).
Also add two inspector tests to track regressions.
BUG=v8:5568
R=titzer@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2457433002
Cr-Commit-Position: refs/heads/master@{#40633}
port 7d383be9da (r40608)
original commit message:
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
BUG=
Review-Url: https://codereview.chromium.org/2450093007
Cr-Commit-Position: refs/heads/master@{#40632}
The reasons are:
1) Type feedback vectors are not shared between different native contexts and
therefore the IC handler created for one native context will not be reused
in other native context.
2) Access rights revocation is not supported at all, therefore given (1) once
we pass the access check we don't have to check access rights again.
BUG=v8:5561
Review-Url: https://codereview.chromium.org/2455953002
Cr-Commit-Position: refs/heads/master@{#40627}
The assumptions that OSR code is installed on {JSFunction} objects no
longer holds with TurboFan and hence {assertOptimized} can report a
different result dependeing on how OSR code is treated. This is working
as intended.
R=mythria@chromium.org
Review-Url: https://codereview.chromium.org/2453313002
Cr-Commit-Position: refs/heads/master@{#40624}
Unlike other variable allocation logic, MODULE allocation does
not depend on resolution. So in order to give hole check elimination
(which runs during resolution) access to the information "is this
variable an import", simply allocate all modules variables prior
to resolution.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2458653002
Cr-Commit-Position: refs/heads/master@{#40621}
The latter was left from a previous commit and not updated later to reflect the new name.
Review-Url: https://codereview.chromium.org/2447023004
Cr-Commit-Position: refs/heads/master@{#40620}
This patch moves promise specific runtime functions
to runtime-promise.cc from runtime-internal.cc
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2452833003
Cr-Commit-Position: refs/heads/master@{#40618}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2443573002
Cr-Commit-Position: refs/heads/master@{#40617}
This patch refactors most of FulfillPromise runtime call out to a separate
function so that we can to it from PromiseReject runtime call.
This patch adds a PromiseStatus enum.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2451163003
Cr-Commit-Position: refs/heads/master@{#40615}
We used to point elsewhere, for instance the right-hand-side of an assignment.
Small limitation: Since variable proxies only have a start position, not an end
position, the best we can do is point at the first character. (We cannot rely
on the scanner's last token position because Declare may be called long after
the variable has been scanned.)
R=adamk@chromium.org
BUG=v8:5572
Review-Url: https://codereview.chromium.org/2447143005
Cr-Commit-Position: refs/heads/master@{#40613}
Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.
BUG=v8:5512
Review-Url: https://codereview.chromium.org/2448933002
Cr-Commit-Position: refs/heads/master@{#40612}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
port df981a9ff5 (r40577)
original commit message:
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.
Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).
This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.
BUG=
Review-Url: https://codereview.chromium.org/2456503003
Cr-Commit-Position: refs/heads/master@{#40607}
