port 9dcd0857d6 (r34571)
original commit message:
Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.
This CL attempts to improve this by:
* Ensuring that there are only two fundamentally different
types of frames, a "standard" frame and a "typed" frame.
Standard frames, as before, contain both a context and
function pointer. Typed frames contain only a minimum
of a smi marker in the position immediately below the fp
where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
TurboFan JavaScript frames use the "standard" format. All
other frames use the type frame format with an explicit
marker.
* Typed frames can contain one or more values below the
type marker. There is new magic macro machinery in
frames.h that simplifies defining the offsets of these fields
in typed frames.
* A new flag in the CallDescriptor enables specifying whether
a frame is a standard frame or a typed frame. Secondary
register location spilling is now only enabled for standard
frames.
* A zillion places in the code have been updated to deal with
the fact that most code stubs and internal frames use the
typed frame format. This includes changes in the
deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
(CommonFrameConstants::kContextOrFrameTypeOffset
and StandardFrameConstants::kFrameOffset are now used
in its stead).
BUG=
Review URL: https://codereview.chromium.org/1774353002
Cr-Commit-Position: refs/heads/master@{#34648}
This flag bans illegal (and likely useless) constructs like
for (;;) function f() {}
R=adamk
BUG=v8:4824
LOG=Y
Review URL: https://codereview.chromium.org/1781653005
Cr-Commit-Position: refs/heads/master@{#34646}
Port c29a4560bb
Original commit message:
In case when F was called with incompatible number of arguments (and therefore
the arguments adator frame was created), F inlines a tail call of G which then
deopts the deoptimizer should also remove the arguments adaptor frame for F.
This CL adds required machinery to the deoptimizer.
R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1775393004
Cr-Commit-Position: refs/heads/master@{#34644}
Port 9dcd0857d6
Original commit message:
Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.
This CL attempts to improve this by:
* Ensuring that there are only two fundamentally different
types of frames, a "standard" frame and a "typed" frame.
Standard frames, as before, contain both a context and
function pointer. Typed frames contain only a minimum
of a smi marker in the position immediately below the fp
where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
TurboFan JavaScript frames use the "standard" format. All
other frames use the type frame format with an explicit
marker.
* Typed frames can contain one or more values below the
type marker. There is new magic macro machinery in
frames.h that simplifies defining the offsets of these fields
in typed frames.
* A new flag in the CallDescriptor enables specifying whether
a frame is a standard frame or a typed frame. Secondary
register location spilling is now only enabled for standard
frames.
* A zillion places in the code have been updated to deal with
the fact that most code stubs and internal frames use the
typed frame format. This includes changes in the
deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
(CommonFrameConstants::kContextOrFrameTypeOffset
and StandardFrameConstants::kFrameOffset are now used
in its stead).
R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1778713002
Cr-Commit-Position: refs/heads/master@{#34643}
When an Array subclass is used as the receiver for concat, or with
certain usages of @@species, the output that's constructed is of
a different type with new slow path logic. This slow path still
made references to elements, so it's important that bounds checking
for a too-long result still be done. This patch repairs that bounds
checking.
R=cbruni
LOG=Y
BUG=chromium:592340
Review URL: https://codereview.chromium.org/1782443002
Cr-Commit-Position: refs/heads/master@{#34636}
Reading the registers' values back from the FrameDescription
should use the same offset computation as storing them into it.
The offsets must also match what the deoptimizer expects, which
is rx at offset rx.code() * kDoubleSize, even if some registers
are not saved (leaving gaps).
BUG=v8:4800
LOG=n
R=danno@chromium.org
Review URL: https://codereview.chromium.org/1769833006
Cr-Commit-Position: refs/heads/master@{#34633}
Port 9d0cf920bd
Bug Descriptions:
1. We are missing drotr32 instruction
2. Ror Macro should also handle values less than zero or bigger than 31, as WASM instruction kExprI32Rol will generate shifting operands beyond [0 .. 31] range.
3. Same as Dror.
4. drotrv instruction in simulator is incorrect.
BUG=
TEST=cctest/test-run-wasm/Run_WasmInt32Binops,cctest/test-run-wasm/Run_WasmInt64Binops
Review URL: https://codereview.chromium.org/1776623002
Cr-Commit-Position: refs/heads/master@{#34632}
- Eliminate stubs with a variable number of arguments.
(That only worked due to their very limited use. These
stubs' interface descriptors were basically lying
about their number of args, which will fail when used
generically.)
- Fix all CallApi*Stubs' interface descriptors to no
longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
FunctionWithFixedArgs.
(Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
*ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
parameters exceeds the supported number of args.
BUG=
Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
Cr-Commit-Position: refs/heads/master@{#34614}
Review URL: https://codereview.chromium.org/1748123003
Cr-Commit-Position: refs/heads/master@{#34627}
The CharacterRange constructor checks the input for validity. However,
CharacterRange::Singleton also uses the constructor and may have
kEndMarker as input, causing the check to fail.
The solution is to move the check to CharacterRange::Range and
consistently use it across the code base.
R=jkummerow@chromium.org
BUG=chromium:593282
LOG=N
Review URL: https://codereview.chromium.org/1776013003
Cr-Commit-Position: refs/heads/master@{#34626}
Reason for revert:
Breaks Chromium.
Original issue's description:
> Rework CallApi*Stubs.
>
> - Eliminate stubs with a variable number of arguments.
> (That only worked due to their very limited use. These
> stubs' interface descriptors were basically lying
> about their number of args, which will fail when used
> generically.)
> - Fix all CallApi*Stubs' interface descriptors to no
> longer lie about their arguments.
> - Unify CallApi*Stub, for * in Function, Accessor,
> FunctionWithFixedArgs.
> (Since these are now all doing the same thing.)
> - Rename the unified stub (and interface descriptors) to
> *ApiCallback*, since that's really what they're doing.
> - Refuse inlining an API callback if its number of
> parameters exceeds the supported number of args.
>
> BUG=
>
> Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
> Cr-Commit-Position: refs/heads/master@{#34614}
TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@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/1775933005
Cr-Commit-Position: refs/heads/master@{#34624}
I used a new category "v8.runtime" and all events are disabled by
default, so there shouldn't be any perf impact.
BUG=none
R=fmeawad@chromium.org,cbruni@chromium.org
Review URL: https://codereview.chromium.org/1770353002
Cr-Commit-Position: refs/heads/master@{#34620}
If left or right is guaranteed at compile-time to be an undetectable object, use HIsUndetectableAndBranch on the other side.
BUG=
Review URL: https://codereview.chromium.org/1775163005
Cr-Commit-Position: refs/heads/master@{#34616}
- Eliminate stubs with a variable number of arguments.
(That only worked due to their very limited use. These
stubs' interface descriptors were basically lying
about their number of args, which will fail when used
generically.)
- Fix all CallApi*Stubs' interface descriptors to no
longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
FunctionWithFixedArgs.
(Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
*ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
parameters exceeds the supported number of args.
BUG=
Review URL: https://codereview.chromium.org/1748123003
Cr-Commit-Position: refs/heads/master@{#34614}
This CL allows the sweeper to free up all memory >= free list item size (3 words). This may reduce memory consumption (especially in map space), but may be worse for allocation order as soon as we start using the tiny category.
This CL is just a first step in the right direction. A follow up CL will add customizable free list categories for each old space.
BUG=chromium:587026
LOG=n
Review URL: https://codereview.chromium.org/1774953003
Cr-Commit-Position: refs/heads/master@{#34612}
In case when F was called with incompatible number of arguments (and therefore
the arguments adator frame was created), F inlines a tail call of G which then
deopts the deoptimizer should also remove the arguments adaptor frame for F.
This CL adds required machinery to the deoptimizer.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1768263004
Cr-Commit-Position: refs/heads/master@{#34610}
The current implementation does not consider the case when the context of
the control scope and the current context differ. It is possible that they are
different in some cases for example: with statements. This cl fixes this.
BUG=v8:4280,v8:4680
LOG=N
Review URL: https://codereview.chromium.org/1768123002
Cr-Commit-Position: refs/heads/master@{#34609}
After fixing the memory barrier for maps (https://codereview.chromium.org/1714513003), we are using a temp register for the map case. The temp register should not be aliased with the stored value (otherwise we perform the mem barrier check with a wrong value). This CL makes sure it is not aliased.
BUG=chromium:590074
LOG=n
Review URL: https://codereview.chromium.org/1775083002
Cr-Commit-Position: refs/heads/master@{#34607}
With this, the test runner automatically merges sancov
files after testing. There's no need to do this by some
external infrastructure.
In a future CL, we could even merge during testing to lift
harddisk pressure.
BUG=chromium:568949
LOG=n
NOTRY=true
Review URL: https://codereview.chromium.org/1776123002
Cr-Commit-Position: refs/heads/master@{#34606}
This CL modifies the following to be LEB128:
* Function table indices
* Import table signature indices
* Export table function indices
* Function signature param count
* br/br_if break depth
* br_table target count
* block/loop expression count
Still to do:
* Import/export names (LEB128 count + inline data)
* Data segments (LEB128 offset + size + inline data)
* Function header stuff (should seperate into function sig and body sections)
* Memory access alignment + offset (still discussing)
BUG=
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1775873002
Cr-Commit-Position: refs/heads/master@{#34603}
This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
function.prototype = {
method: function() { ... }
}
Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
BUG=chromium:593008
LOG=n
Review URL: https://codereview.chromium.org/1772423002
Cr-Commit-Position: refs/heads/master@{#34602}
A previous spec compliance fix for TypedArrays caused a ~4x performance
regression. This patch removes the regression by calling out
to a path within the runtime which implements array copying more
efficiently.
BUG=chromium:592007
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1767893002
Cr-Commit-Position: refs/heads/master@{#34601}
