Previously the String constructor and the Symbol.prototype.toString
methods had to compute the descriptive string for a Symbol on the fly,
which can produce a lot of garbage when this happens a lot, i.e. when
the String representation of a Symbol is used often. Now instead of
doing this on-demand we can just do it upfront when creating the Symbol.

That way we also ensure that we won't throw an exception when accessing
the descriptive string of a Symbol, due to potential String length
overflow, but have the exception during Symbol creation upfront, which
is a lot less surprising behavior.

BUG=v8:6278,v8:6344,v8:6350
TBR=mlippautz@chromium.org
R=ishell@chromium.org

Review-Url: https://codereview.chromium.org/2900703002
Cr-Commit-Position: refs/heads/master@{#45479}

Validation normally happens while generating the turbofan graph of a
wasm function. For lazy compilation (behind the flag
--wasm-lazy-compilation), we skip this graph generation step during
module generation. Thus we need to validate explicitely.

R=ahaas@chromium.org
BUG=chromium:724851

Change-Id: Ic70887c0d823460a272d0bb636dc98b2b7a7e55e
Reviewed-on: https://chromium-review.googlesource.com/509574Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45478}

Add a new "v8_perf_prof_unwinding_info" option to gn that translates to building
the snapshot with "--perf-prof-unwinding-info". It allows unwinding TF generated
code from the snapshot.

Additionally, add a warning if one uses the option along with a snapshot which
was not build with unwinding information.

Running tests in this configuration revealed an issue in the checks performed
when accessing the stub cache. We would assume that the `Code::Flags` bitfield
only contains the `Kind` and `ExtraICState` fields, when there is also a
`HasUnwindingInfo` field which can now be set for stubs.

BUG=

Review-Url: https://codereview.chromium.org/2887783002
Cr-Commit-Position: refs/heads/master@{#45477}

The validation of utf8 strings in WebAssembly modules used the character
kBadChar = 0xFFFD to indicate a validation error. However, this
character can appear in a valid utf8 string. This CL fixes this problem
by duplicating some of the code in {Utf8::CalculateValue} and inlining
it directly into Utf8::Validate. Note that Utf8::Validate is used only
for WebAssembly.

Tests for this change are in the WebAssembly spec tests, which I will
update in a separate CL.

R=vogelheim@chromium.org

Change-Id: I8697b9299f3e98a8eafdf193bff8bdff90efd7dc
Reviewed-on: https://chromium-review.googlesource.com/509534Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45476}

This is to avoid ClusterFuzz picking up and using those calls.
With the proper syntax (no whitespace), they are recognized as runtime
calls and will be checked against a whitelist.

R=mstarzinger@chromium.org
BUG=chromium:724459

Change-Id: I5533f066feeb66f622230b12f79f9d227e2b2465
Reviewed-on: https://chromium-review.googlesource.com/509575Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45475}

After this cl: https://chromium-review.googlesource.com/c/508668/
the decisions on inlining polymorphic functions are done per
function. This regresses Octane/raytrace. Tuning the inlining 
heuristics to fix the regression.

Bug: chromium:724924
Change-Id: I027563de84723e4e39af4de49f85507468b96af3
Reviewed-on: https://chromium-review.googlesource.com/509554Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45474}

Bug: v8:6055
Change-Id: Ib14dcef7f30bab88fad92b1a7329163beea50503
Reviewed-on: https://chromium-review.googlesource.com/511682Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45473}

Security feature: pick compiled functions randomly

Bug: v8:6417
Change-Id: Ibcef9ba94e3730a47cd43d2a59b23d5cee3fad40
Reviewed-on: https://chromium-review.googlesource.com/511842
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45472}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1caf3a6..b19d8a0

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: I1816fe20864835c2615f09f11666165b0776cf9e
Reviewed-on: https://chromium-review.googlesource.com/511743Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45471}

- reduce boilerplate;
- encapsulate V8Inspector inside IsolateData;
- remove extra interfaces and classes.

BUG=none

Review-Url: https://codereview.chromium.org/2901523003
Cr-Commit-Position: refs/heads/master@{#45470}

TBR=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2898043002
Cr-Commit-Position: refs/heads/master@{#45469}

TryHandleSignal was originally limited by conditional compilation to only
platforms where the WebAssembly trap handler is supported. This caused build
problems, because not all the macros we needed were defined everywhere.

Instead, we make TryHandleSignal available on all POSIX platforms, but it
unconditionally returns false if the trap handler is not supported.

Bug: 
Change-Id: Iab4baf39b1708989edecc4ecfb51b926d8f7fe8d
Reviewed-on: https://chromium-review.googlesource.com/508838Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45468}

Currently the UnreachableObjectsFilter does not work if incremental
marking is in progress since they both use the same markbits.

This patch changes the UnreachableObjectsFilter to use local markbits.

BUG=

Review-Url: https://codereview.chromium.org/2901553002
Cr-Commit-Position: refs/heads/master@{#45467}

Change-Id: Ia900c6c21d1ff330088a6566f8f6c7719c887ccf
Reviewed-on: https://chromium-review.googlesource.com/509256
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45466}

If the maximum number of memory pages is raised using
--wasm-max-mem-pages, we might allocate more than kMaxInt bytes for
wasm memory. The byte length is stored as int in JSArrayBuffer, hence
this can lead to failures.
Thus, we now additially check against kMaxInt, and fail instantiation
if this check fails.

Drive-by: Add/fix more bounds checks.

R=ahaas@chromium.org
BUG=chromium:724846

Change-Id: Id8e1a1e13e15f4aa355ab9414b4b950510e5e88a
Reviewed-on: https://chromium-review.googlesource.com/509255Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45465}

It was used before as a placeholder in Result<DecodeStruct*> to
communicate that no value was returned. We actually only created a
Results holding {nullptr} when returning such values. Thus, the whole
struct is not needed, and we return Result<nullptr_t> instead, which
clearly communicates that this result does not hold any value.

An alternative would be to use Result<void>, but this would require
partial specialization of the Result template, which would be overkill
here.

R=ahaas@chromium.org

Change-Id: Ib07d2c4fe716c735839675d11146c47f97997d40
Reviewed-on: https://chromium-review.googlesource.com/509551Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45464}

Bug: 
Change-Id: I472cc64bfbbef5ce6643b506b1fcb56c1cee5f24
Reviewed-on: https://chromium-review.googlesource.com/509715Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45463}

NOTRY=true

Change-Id: I74ba0860e33d954a864476a01bd829f0e91e527e
Reviewed-on: https://chromium-review.googlesource.com/509533
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45462}

For the Scavenger we require a first pass over global handles for identifying
unmodified nodes because the Scavenger might have already written forwarding
pointers during scanning, making it hard to perform the proper checks.

The minor MC does not mutate the object graph during marking and can thus merge
this phase into the regular phase executed during marking roots.

Furthermore, moves processing into the parallel marking phase of the minor MC
collector.

Bug: chromium:720477, chromium:651354
Change-Id: Id33552124264e3ab0bdf34d22ac30c19c1522707
Reviewed-on: https://chromium-review.googlesource.com/509550
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45461}

It will be re-enabled when slots recording is implemented.

BUG=chromium:694255

Review-Url: https://codereview.chromium.org/2897813004
Cr-Commit-Position: refs/heads/master@{#45460}

This reverts commit bdf70aa0.

Reason for revert: Breaks perf testing. Comma missing in json.

Original change's description:
> [Interpreter] Improve handling of a === true / false.
> 
> Add support for direct jumping on True/False for strict equals of boolean
> literals. This improves the score for such comparisons by around 75% on
> baseline code, and by around 40x on optimized code for the added performance
> test.
> 
> Bug=v8:6403
> 
> Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb
> Reviewed-on: https://chromium-review.googlesource.com/509570
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45450}

TBR=rmcilroy@chromium.org,mythria@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug=v8:6403

Change-Id: I12b1868ba22354d056f38fe36e3c1e5fae5aa1b5
Reviewed-on: https://chromium-review.googlesource.com/509577Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45459}

Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9
Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45458}

This patch fixes the below compilation error with a static_cast.

../src/arm/disasm-arm.cc:689:72:
    error: format specifies type 'void *' but the argument has type
    'v8::internal::byte *' (aka 'unsigned char *') [-Werror,-Wformat-pedantic]
    out_buffer_pos_ += SNPrintF(out_buffer_ + out_buffer_pos_, "%p", addr);

R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2900663002
Cr-Commit-Position: refs/heads/master@{#45457}

Bug fixed:

- Remove builtins/builtins-<arch>.cc from v8_base.
- Add missing builtins/builtins-x87.cc to v8_builtins_generators.

Bug: v8:6055
Change-Id: I55da82f740df9294d83ec188770ee7a6e0e60941
Reviewed-on: https://chromium-review.googlesource.com/509429Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45456}

Introduce a new Symbol comparison feedback bit in the lattice and
collect that feedback on Equal/StrictEqual in Ignition. Utilize this
feedback in TurboFan by adding a dedicated CheckSymbol operator to
check for symbol inputs. This way we can optimize Symbol comparison
where TurboFan doesn't know anything statically about either side, or
abstract equality comparisons where TurboFan doesn't statically know
anything about one side.

BUG=v8:6278,v8:6344,v8:6423
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2893263002
Cr-Commit-Position: refs/heads/master@{#45455}

Most of the plumbing is already present in the non-public API. According to
ES2016, Symbols are also accepted in calls to getOwnProperty(), and taking
them is required in Blink for proper record<K,V> WebIDL conversions.

R=jochen@chromium.org,verwaest@chromium.org

Bug: chromium:724481
Change-Id: I0dfe0e57f6d811f04ecbfd8ec0c97e44c9f02c96
Reviewed-on: https://chromium-review.googlesource.com/509611Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#45454}

Special cases addition expressions where one of the sides is known to be a
string to enable chains of string additions to be transformed into a series
of ToPrimitiveToString operations followed by a single string concatenation 
at the end of the chain of additions. This should avoid creating temporary
strings for each of the string additions (in essence this is an automated
string builder).

BUG=v8:6243

Change-Id: I44977d6dad00ee906f251c4bd9cab27e160c09d1
Reviewed-on: https://chromium-review.googlesource.com/493966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45453}

This makes sure that function imports without a single call site within
the asm.js module are still preserved in the WebAssembly module, hence
preserving intended JavaScript semantics during module instantiation.

R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-722348
BUG=chromium:722348

Change-Id: I624d0e52b32b864c1e3002187a99a0a63834a4b0
Reviewed-on: https://chromium-review.googlesource.com/509450Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45452}

BUG=

Review-Url: https://codereview.chromium.org/2890613003
Cr-Commit-Position: refs/heads/master@{#45451}

Add support for direct jumping on True/False for strict equals of boolean
literals. This improves the score for such comparisons by around 75% on
baseline code, and by around 40x on optimized code for the added performance
test.

Bug=v8:6403

Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb
Reviewed-on: https://chromium-review.googlesource.com/509570
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45450}

With this CL we do not spawn a FinishCompilationUnit foreground task for
every WebAssembly function we compile, but instead spawn one foreground
task which finishes all existing compilation units
(FinishCompilationUnits). A new FinishCompilationUnits task is spawned
whenever a compilation task sees that there in no FinishCompilationUnits
to finish its compilation unit.

In addition the FinishCompilationUnits task gets a time limit. Whenever
it is executed for longer than 1ms (this value is also used by the GC),
then the task stops and reschedules itself. Thereby we make sure that
we do not block the main thread for too long.

Change-Id: Ib4f2aed91c60f9c8952b6ba4dd7e5052301417a3
Reviewed-on: https://chromium-review.googlesource.com/508708
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45449}

BUG: v8:6211
Change-Id: Ief28872f6ce97ff326f9a86367f872e321b2612a
Bug: 
Reviewed-on: https://chromium-review.googlesource.com/508650
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45448}

R=danno@chromium.org
CC=sshruthi@chromium.org
TBR=verwaest@chromium.org,bmeurer@chromium.org,yangguo@chromium.org,rossberg@chromium.org

Change-Id: I32e09193fa6e847ac3336eab62b6d85c46d71164
Reviewed-on: https://chromium-review.googlesource.com/509508
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45447}

Only FullCodegen code ever gets flushed by code flushing. Since we are
deprecating the old pipeline, the added complexity introduced by code
flushing is no longer worth it. This CL removes it (but keeps code aging,
which is used to unlink SFIs from the compilation cache).

BUG=v8:6389,v8:6379,v8:6409

Change-Id: I90de113a101f86dbeaaf0511c61a090ef12aa365
Reviewed-on: https://chromium-review.googlesource.com/507388
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45446}

Revert of [csa] Add assertions to CSA (patchset #14 id:260001 of https://codereview.chromium.org/2847923003/ )

Reason for revert:
Linux-nosnap failures:

https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13282

Original issue's description:
> [csa] Add assertions to CSA
>
> This adds a bunch of assertions to CSA, mostly about documenting and checking
> parameter types.
>
> Drive-by-change: Removed unused function.
>
> BUG=v8:6325
>
> Review-Url: https://codereview.chromium.org/2847923003
> Cr-Original-Commit-Position: refs/heads/master@{#45398}
> Committed: https://chromium.googlesource.com/v8/v8/+/b14a981496ad1f841683479d2f9188dfa2d6b4bd
> Review-Url: https://codereview.chromium.org/2847923003
> Cr-Commit-Position: refs/heads/master@{#45443}
> Committed: https://chromium.googlesource.com/v8/v8/+/62b0de1ef53816d6dae3fa519a846f942b701dda

TBR=cbruni@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6325

Review-Url: https://codereview.chromium.org/2893253002
Cr-Commit-Position: refs/heads/master@{#45445}

An oversight in Friday's CL. Thx to neis@chromium.org for the tip!

BUG=v8:6351
TBR=rmcilroy@chromium.org

Review-Url: https://codereview.chromium.org/2893223002
Cr-Commit-Position: refs/heads/master@{#45444}

This adds a bunch of assertions to CSA, mostly about documenting and checking
parameter types.

Drive-by-change: Removed unused function.

BUG=v8:6325

Review-Url: https://codereview.chromium.org/2847923003
Cr-Original-Commit-Position: refs/heads/master@{#45398}
Committed: https://chromium.googlesource.com/v8/v8/+/b14a981496ad1f841683479d2f9188dfa2d6b4bd
Review-Url: https://codereview.chromium.org/2847923003
Cr-Commit-Position: refs/heads/master@{#45443}

BUG=

Review-Url: https://codereview.chromium.org/2892153003
Cr-Commit-Position: refs/heads/master@{#45442}

BUG=none

Review-Url: https://codereview.chromium.org/2894773003
Cr-Commit-Position: refs/heads/master@{#45441}

Currently SIMD integer comparison ops are implemented using Lt/Le, this is
sub-optimal on Intel, because all compares are done using pcmpgt(d/w/b) that
clobber the destination register, and will need additional instructions to
when using Lt/Le as the base implementation. This CL proposes moving to Gt/Ge
as the underlying implementation as this will only require swapping operands
on MIPS and is consistent with x86/ARM instructions.

BUG=v8:6020

R=bbudge@chromium.org, bmeurer@chromium.org, bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2874403002
Cr-Commit-Position: refs/heads/master@{#45440}