and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44412}
There's no need to set it so early - it's only needed when the function has
really been parsed. This way we don't need to produce and store it for skipped
inner functions.
BUG=v8:5516
Change-Id: Ibf59a8acb886ea3de9be140431a334a03b408f5b
Reviewed-on: https://chromium-review.googlesource.com/461827
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44410}
This extends the test coverage for source position tracking of ToNumber
conversion to also test conversion to "double" type. It also fixes the
discovered inconsistencies. Note that the conversion to "float" remains
untested as imported functions are not allowed have "float" return type.
R=clemensh@chromium.org
TEST=mjsunit/wasm/asm-wasm-exception-in-tonumber
BUG=v8:6127
Change-Id: I6c59b7a24456a585a814f19a86eb9447ac5098ab
Reviewed-on: https://chromium-review.googlesource.com/467251
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44409}
In the C++ wasm interpreter, we decode LEB encoded immediates each time
we execute the respective instruction. The whole instruction sequence
was validated before, thus we know that all integers are valid.
This CL refactors several Decoder methods to allow for either checked
or unchecked decoding. In the checked case, an error is set if a check
fails, in the unchecked case, a DCHECK will fail.
This improves performance of the interpreter by 20.5%.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If69efd4f6fbe19d84bfc2f4aa000f429a8e22bf5
Reviewed-on: https://chromium-review.googlesource.com/468786
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44406}
Both methods decoded a LEB128 encoded integer, but only consume_leb
incremented the pc pointer accordingly.
This CL implements consume_leb by using checked_read_leb.
It also refactors a few things:
1) It removes error_pt, which was only avaible in checked_read_leb.
2) It renames the error method to errorf, since it receives a format
string. This also avoids a name clash.
3) It implements sign extension directly in checked_read_leb instead of
doing this in the caller.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I8058f57418493861e5df26d4949041f6766d5138
Reviewed-on: https://chromium-review.googlesource.com/467150
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44405}
IdentifierStart::Is and IdentifierContinue::Is both return true for '\'.
The reason for this is lost to history.
Special-case '\' in the regexp parser to handle this.
BUG=v8:5437,v8:5868
Review-Url: https://codereview.chromium.org/2795093003
Cr-Commit-Position: refs/heads/master@{#44396}
Better demarcation between what's mutable because it is code-
specialization specific, and what is provided at initialization.
BUG=
Review-Url: https://codereview.chromium.org/2784233004
Cr-Commit-Position: refs/heads/master@{#44395}
Remove destructuring assignments (parsed during arrow function formal
parameters) from queue for rewriting if parsing a lazy top-level arrow function.
Built ontop of https://chromium-review.googlesource.com/c/464769/
BUG=chromium:706234, chromium:706761, v8:6182
R=marja@chromium.org, adamk@chromium.org, vogelheim@chromium.org
Change-Id: Ib35196b907350d1d78e4c3fcbf4cc971bf200948
Reviewed-on: https://chromium-review.googlesource.com/465415
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44393}
This enables clients like IndexedDB to know when the data format version has
decreased (i.e. the user has switched to an earlier version) and deal with the
resulting incompatibility up front.
BUG=chromium:704293
Review-Url: https://codereview.chromium.org/2772723005
Cr-Commit-Position: refs/heads/master@{#44391}
After discussion with Chrome reviewers for UMA, it was decided that we
would report array buffer allocation sizes in megabytes (not the log).
They also wanted to wait until there is proof that small array buffer
allocations would flood the histogram. Hence, all allocation sizes are
sampled.
There were several ways we could have added the notion of megabyte
samples to V8 code. None of them are a great fit. This code simply
provides a local function within the code that needs it.
Other possible solutions but rejected were:
a) Use a subclass of histogram to collect data at the megabyte level.
It has it's own Add() method that converts the size from bytes to
megabytes, and then call the generic add method AddSample(). This
solution appears to follow the conventions of subclasses of class
Histogram.
b) Use Chrome macros - Rejected because it involves changing the
counter representation of V8.
c) Add a method AddMegabyteSample() to base class Histogram. Rejected
because it may get confusing if a lot of different measures are
added the the base class of histograms.
d) Make method AddSample() virtual and override in the derived
class. Rejected in that sampling is supposed to be fast, and adding
a virtual call may be breaking that contract.
d) Do not add a derived class. Rather just do the conversions at the
call sites. Rejected because this duplicates code, and also makes
it hard to change assumptions on how to calculate.
For Chromes UMA changes see:
CL: https://codereview.chromium.org/2795463002
BUG=chromium:704922
R=bbudge@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org
Review-Url: https://codereview.chromium.org/2795763002
Cr-Commit-Position: refs/heads/master@{#44388}
This reflects both the contract in blink, as well as what we
plan to do in streamed compilation, where we'll want to lay out
bytes received such that each section and each function body is
contiguous, but they may all be separate - which entails a copy.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2797653002
Cr-Commit-Position: refs/heads/master@{#44387}
The past re-factoring inadvertently increased memory consumption for
AstConsString. This implements a micro-optimization to revert and slightly
improve beyond the original state.
Example, Zone size for parsing closure.js:
- 20,999,848 B (before refactoring)
- 21,651,056 B (after refactoring patch; 3.1% regression)
- 20,641,320 B (after this CL; 1.7% improvement over original)
(Reason: ZoneLinkedList requires 4 pointers to support
the std::list functionality (Zone*, head/tail ptr, payload ptr).
But since we only append and iterate in order and have the Zone*
available in the context, a super simple linked list (value + next ptr)
saves a bit of memory, especially for the common case of having 0 or 1
string segments.)
BUG=v8:6902, chromium:706935
Review-Url: https://codereview.chromium.org/2792353002
Cr-Commit-Position: refs/heads/master@{#44385}
When emitting a frame, we always push the old frame pointer at offset 0 relative
to the new frame pointer. However, we didn't emit DWARF opcodes to inform perf
of this.
BUG=
Review-Url: https://codereview.chromium.org/2795253002
Cr-Commit-Position: refs/heads/master@{#44384}
This reverts 1c1edda7db. I can't reproduce
the flakes locally anymore, let's see if this sticks.
BUG=v8:5619
Review-Url: https://codereview.chromium.org/2796053002
Cr-Commit-Position: refs/heads/master@{#44381}
The unwinding information we emit wrongly encodes code locations as relative
offsets. If we look at the .eh_frame section of shared object generated by "perf
inject" using "objdump -g":
~~~
00000000 0000000000000018 00000000 CIE
(snip)
0000001c 0000000000000028 00000020 FDE cie=00000000 pc=fffffffffffffee8..00000000000017f8
(snip)
00000048 ZERO terminator
~~~
We can see the range that the FDE entry covers is incorrect, it should point to
where the .text section is, at address 0x40 on a 64-bit architecture.
The reason for this was that the PerfJitLogger logs a code size that is
different from the one we've used when encoding the unwinding information. The
logger will ignore the safepoint table while the unwinding info assumes it is
part of the code.
BUG=
Review-Url: https://codereview.chromium.org/2790403002
Cr-Commit-Position: refs/heads/master@{#44378}
This makes it easier to match VariableProxys against variables in
Scopes (allocation-based prints such as local[0] or context[0] are not
unique).
R=vogelheim@chromium.org
Bug:
Change-Id: I8f86504f5e1657633286561e032805a8f6cff06e
Reviewed-on: https://chromium-review.googlesource.com/467486
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44376}
Support arbitrary arguments in %ArrayBufferNeuter without aborting for
future exposure in ClusterFuzz.
Change-Id: I3053a2139af215c9d417356bdeeda58d594d16aa
Reviewed-on: https://chromium-review.googlesource.com/465830
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44374}
Update according to new spec change at
https://github.com/tc39/ecma262/pull/856
- Call ToNumber only once in BUILTIN
- Remove unused FillNumberSlowPath
- FillImpl assumes obj_value->IsNumber() is true
- Update test
Bug:v8:5929,chromium:702902
Change-Id: Ic83e6754d043582955b81c76e68f95e1c6b7e901
Reviewed-on: https://chromium-review.googlesource.com/465646
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44373}
Getting elements, querying length or copying elements
are now const functions.
Drive-by fix: Noticed a few more getters that should be const.
Add a comment to ArrayList functions that are static functions.
BUG=
Change-Id: I5de1aed97510dea4e47cb974b3259da51ae663af
Reviewed-on: https://chromium-review.googlesource.com/467249
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44372}
Make sure that we call the destructors on all embedded object by
replacing the WasmInterpreterInternals::Delete method by an actual
destructor. This way, the compiler automatically calls destructors on
all embedded objects, in particular the IdentityMap in the CodeMap.
This change also requires to release managed objects *before*
tearing down the heap, because the wasm interpreter, referenced via
Managed<>, contains global handles. When those are destroyed, the
isolate still needs to be intact.
Drive-by: Fix include guard in managed.h.
R=ahaas@chromium.org, ulan@chromium.org, mvstanton@chromium.org
BUG=v8:5822
Change-Id: I9a067f037e013c84e4d697a1e913b27c683bb529
Reviewed-on: https://chromium-review.googlesource.com/466187
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44368}
This makes temporary variables nestable and fixes borked nesting with
function table calls by introducing a {TemporaryVariableScope} helper.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6196
BUG=v8:6196
Change-Id: Ie760f27ce9ede3d4d5dacdebdc295c56cc666970
Reviewed-on: https://chromium-review.googlesource.com/467327
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44367}
Fix ff8b1abb1a
This fixes the problem with the alignment of typed arrays in turbofan. Namely,
Float64 typed arrays weren't properly aligned on 32bit architectures,
and this causes crashes on those architectures that do not support misaligned
memory access.
TEST=mjsunit/es6/typedarray-*
BUG=v8:6075
Review-Url: https://codereview.chromium.org/2784253002
Cr-Commit-Position: refs/heads/master@{#44366}
ArrayList is a FixedArray where kFirstIndex is > 0. The
Elements() methods returns a copy of the elements starting at
kFirstIndex, i.e., without the length that is stored in the first
slot.
Drive-by fix: Rename some variables.
BUG=
Change-Id: Ia1de73c4780a179301007f2ab9080fd08e8ea99d
Reviewed-on: https://chromium-review.googlesource.com/466186
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44365}
Return a structured objet with the type profile
information.
Move the test from message to mjsunit.
BUG=v8:5933
Change-Id: I3e1c592697924d87f82d46b0ddbdb6d82d9c8467
Reviewed-on: https://chromium-review.googlesource.com/464847
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44364}
For sloppy arguments in functions with declared formal parameters, the
apply with arguments optimization in TurboFan wouldn't kick in
currently, because so far there was no guard to see if using the
arguments from the stack or the frame state is safe. One easy to check
guard here is to just check that there's no observable side-effect
between the actual arguments creation and the call to apply.
BUG=v8:5267,v8:6200
R=danno@chromium.org
Review-Url: https://codereview.chromium.org/2789113004
Cr-Commit-Position: refs/heads/master@{#44363}
