The previous %StringCharCodeAt runtime entry (and the inlined intrinsic)
are obsolete and not used anymore (except in dedicated tests for this
runtime function), so remove it. And rename the %StringCharCodeAtRT
function, which is actually used to %StringCharCodeAt instead to have
a consistent naming scheme for runtime fallbacks.

Bug: v8:5049
Change-Id: I619429ef54f6efea61fc51ab9ed1d5cfe4417f99
Reviewed-on: https://chromium-review.googlesource.com/657719
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47928}

JavaScript is a dynamically typed language. But most code is 
written with fixed types in mind. When debugging JavaScript, 
it is helpful to know the types of variables and parameters 
at runtime. It is often hard to infer types for complex code. 
Type profiling provides this information at runtime.

Node.js uses the inspector protocol. This CL allows Node.js users 
to access and analyse type profile for via Node modules or the
in-procress api. Type Profile helps developers to analyze 
their code for correctness and performance.  

Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing

Add `takeTypeProfile` to the inspector protocol. It returns a list
of TypeProfileForScripts, which in turn contains the type profile for
each function. We can use TypeProfile data to annotate JavaScript code. 

Sample script with data from TypeProfile:
function f(/*Object, number, undefined*/a, 
           /*Array, number, null*/b, 
           /*boolean, Object, symbol*/c) {
  return 'bye';
/*string*/};
f({}, [], true);
f(3, 2.3, {a: 42});
f(undefined, null, Symbol('hello'));/*string*/

Bug: v8:5933
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d
Reviewed-on: https://chromium-review.googlesource.com/508588
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47920}

Bug: v8:6333
Change-Id: Ibc704172ebc796977b8d8cfae6976666d186f12c
Reviewed-on: https://chromium-review.googlesource.com/652450
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47890}

There are two main reasons to move DeserializeLazy to ASM:

1. We avoid complications around the distinction between Call/Construct
   cases by making sure relevant registers (e.g. new_target) remain
   unclobbered.

2. We can avoid the tail-call through CodeFactory::Call/Construct by
   jumping directly to the deserialized code object.

Bug: v8:6624
Change-Id: Idef8fa73d804e16d510f62766c735d1891729b81
Reviewed-on: https://chromium-review.googlesource.com/652472Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47876}

Given that we no longer need to iterate over lists of optimized JS functions 
(c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can 
remove this field. Thus saving the size of one pointer per function.

Bug: v8:6637
Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8
Reviewed-on: https://chromium-review.googlesource.com/652373Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#47875}

- Convert S.p.{trim, trimLeft, trimRight} to TFJ
  - Fast paths for one/two byte strings
  - Added StringTrimAssembler
- Added helper kStringTrim runtime to handle slow paths

Quick measurements show >2.7x improvement:
https://github.com/peterwmwong/v8-perf/tree/master/string-trim

Bug: v8:6680
Change-Id: I79929129aa3d5dea20f094d648afe46adbf61a49
Reviewed-on: https://chromium-review.googlesource.com/647647Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47853}

Always return to the InterpreterEntryTrampoline rather than calling the
InterpreterExitTrampoline from the Return bytecode handler. This fixes a
regression which occured if we upset the call/return stack by skipping the
return to the InterpreterEntryTrampoline from the return bytecode handler.

BUG=chromium:759390,chromium:753705

Change-Id: Ib625654a4a5072ac6c8d8e9611d1b9c0bbced4ca
Reviewed-on: https://chromium-review.googlesource.com/649517
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47826}

Using the Builtins::Name type doesn't give use any range safety benefits
over simply using int id's, and it complicates use sites by always
forcing a static_cast<Builtins::Name>(id).

Bug: v8:6624
Change-Id: Id5fcf6800c781c637145ab1d00d821f9ad473321
Reviewed-on: https://chromium-review.googlesource.com/650247
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47823}

This adds support for lazy deserialization of JS-linkage (TFJ) builtins,
still gated behind the --lazy-deserialization flag. If enabled, we
proceed as follows:

During isolate initialization, only eager builtins are deserialized. All
references to lazy builtins are replaced by the DeserializeLazy builtin.
In particular, this happens in the builtin table (Builtins::builtins_)
and in SharedFunctionInfo objects.

When calling into a not-yet deserialized function (i.e. the JSFunction's
code object is the DeserializeLazy builtin), the DeserializeLazy builtin
takes over.  It checks the builtin table to see if the target builtin
(determined by looking at the builtin id stored on the
SharedFunctionInfo) has already been deserialized. If so, it simply
copies the builtin code object to the JSFunction and SharedFunctionInfo.
Otherwise, we enter Runtime::kDeserializeLazy to deserialize the
builtin.

With --lazy-deserialization, isolate deserialization is 11% faster
(1.5ms vs.  1.7ms), and code_space->Size() is 33% lower (984K vs.
1475K).

Moving relocation infos & handler tables out of the partial snapshot
cache would additionally let us save up to 30K per isolate. Adding code
stubs to that list increases further potential savings to 262K.

Bug: v8:6624
Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb
Reviewed-on: https://chromium-review.googlesource.com/649166
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47818}

R=petermarshall@chromium.org

Bug: 
Change-Id: Id7187d9e323951e66655d1c6df4676a8e94787dd
Reviewed-on: https://chromium-review.googlesource.com/649247Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47815}

This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
 
We needed to change/remove the cctests that used to check
something on this list.
 
Working in x64, ia32, arm64, arm, mips64 and mips. 
 

Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}

This reverts commit 84c2dfce.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876

Original change's description:
> Remove weak-list of optimized JS functions.
> 
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
> 
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
> 
> We needed to change/remove the cctests that used to check
> something on this list.
> 
> Working in x64, ia32, arm64, arm, mips64 and mips. 
> 
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}

TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com

Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}

This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.

No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.

We needed to change/remove the cctests that used to check
something on this list.

Working in x64, ia32, arm64, arm, mips64 and mips. 

Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}

This is a reland of a9f517e2
Original change's description:
> [builtins] Port Proxy set trap to CSA
> 
> Bug: v8:6560, v8:6557
> Change-Id: I329794607e8de324fc696652555aaaeafcf519ec
> Reviewed-on: https://chromium-review.googlesource.com/625940
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Cr-Commit-Position: refs/heads/master@{#47760}

Bug: v8:6560, v8:6557
Change-Id: I1b32992eac6cc5583a44703eed901e4ad15f1947
Reviewed-on: https://chromium-review.googlesource.com/647447
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47772}

This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}

This reverts commit a9f517e2.

Reason for revert: Makes array sort flaky? https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/17894/steps/OptimizeForSize%20%28flakes%29/logs/array-sort

Original change's description:
> [builtins] Port Proxy set trap to CSA
> 
> Bug: v8:6560, v8:6557
> Change-Id: I329794607e8de324fc696652555aaaeafcf519ec
> Reviewed-on: https://chromium-review.googlesource.com/625940
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Cr-Commit-Position: refs/heads/master@{#47760}

TBR=neis@chromium.org,franzih@chromium.org,ishell@chromium.org,bmeurer@chromium.org,mslekova@google.com

Change-Id: Ibebf5e694945e59bd2808841108e6686af51efaf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6560, v8:6557
Reviewed-on: https://chromium-review.googlesource.com/646169Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47764}

This adds support for lowering {JSCreateArguments} within outermost
frames of type {CreateArgumentsType::kMappedArguments}. It will hence
enable escape analysis to work with such objects and allow for further
optimization.

This also adds a new {NewMappedArgumentsElements} simplfied operator.
Note that escape analysis support for this new operator will be done as
a follow-up.

R=tebbi@chromium.org

Change-Id: I0e2fac25c654f796433f57b116964053b6b68635
Reviewed-on: https://chromium-review.googlesource.com/641454
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47761}

Bug: v8:6560, v8:6557
Change-Id: I329794607e8de324fc696652555aaaeafcf519ec
Reviewed-on: https://chromium-review.googlesource.com/625940Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#47760}

This adds an initial implementation of the DeserializeLazy builtin and
runtime function, as well as --lazy-deserialization and
--trace-lazy-deserialization feature flags.

Since lazy deserialization itself isn't implemented yet, DeserializeLazy
simply replaces itself with the appropriate builtin. The builtin_id is
loaded from the SFI, and the builtin itself is loaded from the Builtins
table.

Bug: v8:6624
Change-Id: I4ef8c3030a8cda19a086b8e569a24d97213b5ed8
Reviewed-on: https://chromium-review.googlesource.com/643289Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47757}

Bug: v8:6704
Change-Id: I77388b91061f934943a707a645080dfdcf481836
Reviewed-on: https://chromium-review.googlesource.com/645951Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47756}

Change-Id: Ibfc5dcd012073f9e3e3b000a90eab706b29189d8
Reviewed-on: https://chromium-review.googlesource.com/646329
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47750}

Bug: v8:6704
Change-Id: If636bdd682d76a6d58d36fc9bfbf1302a32468ab
Reviewed-on: https://chromium-review.googlesource.com/641671
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47732}

heap-inl.h exposes the whole world, which is fine from other inline
files but not from regular headers.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I09ec67c6558682cb0d5181031bc39341a3f4c5bf
Reviewed-on: https://chromium-review.googlesource.com/643294Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47729}

This patch introduces a new container type ScriptOrModule which
provides the name and the host defined options of the script/module.

This patch also introduces a new PrimitivesArray that can hold
Primitive values, which the embedder can use to store metadata.

The HostDefinedOptions is passed to V8 through the ScriptOrigin, and
passed back to the embedder through HostImportModuleDynamically for
module loading.

Bug: v8:5785, v8:6658, v8:6683
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I56c26fc9a680b273ac0a6691e5ad75f15b8dc80a
Reviewed-on: https://chromium-review.googlesource.com/622158Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47724}

Bug: chromium:760268
Change-Id: Id9b24ddee61926a5d1324d7da12efccf2c1eb9c2
Reviewed-on: https://chromium-review.googlesource.com/642798Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#47704}

Introduce a proper empty_descriptor_array, which has the proper layout
(length is 2 and the two fields are set properly). Also add a special
EnumCache class and a matching empty_enum_cache. The contract now is
that we only need to check the EnumLength on the map to know whether we
are allowed to use the enum cache. This greatly simplifies the handling
of the enum cache (and also the descriptor arrays), especially for the
future work on optimizing keyed access via the enum cache indices.

Bug: v8:6702
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83
Reviewed-on: https://chromium-review.googlesource.com/641030
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47697}

No need to reassign those JSTypedArrays.

Bug: v8:6704
Change-Id: Ide1f8bb119285b57ea85b8e710358c917244f801
Reviewed-on: https://chromium-review.googlesource.com/641474
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47693}

Bug: v8:6333
Change-Id: I6292bc6b31c696dddd3e3361a519e7275404b144
Reviewed-on: https://chromium-review.googlesource.com/631879Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47663}

As part of J2V8 development (https://github.com/eclipsesource/J2V8),
we realized that we had a subtle bug in how Isolate scope was created
and it's lifetime managed, see:
https://github.com/eclipsesource/J2V8/issues/313.

Mentioned above bug was fixed, however, what we also noticed is that
V8 API has been constantly and slowly moving to such an API, in which
one has to pass Isolate explicitly to methods and/or constructors. We
found two more places that might have been overlooked. This contribution
adds passing of Isolate pointer explicitly to constructors of
String::Utf8Value and String::Value classes.

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I61984285f152aba5ca922100cf3df913a9cb2cea
Reviewed-on: https://chromium-review.googlesource.com/593309
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47656}

This reverts commit f6d73509.

Reason for revert: Perf regressions https://crbug.com/758126

Original change's description:
> [csa] Refactor large-object handling in string allocation
> 
> CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
> allocate very large strings. This CL refactors both methods to use
> AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
> to specify explicitly if large-object allocation is possible or not.
> 
> Bug: chromium:636391
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
> Reviewed-on: https://chromium-review.googlesource.com/625738
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47504}

TBR=cbruni@chromium.org,jgruber@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:636391
Change-Id: Iab88ce400f489a677df821d4053bd3678289ae2e
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/637392Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47639}

This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.

Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.

BUG=chromium:753705

Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}

Bug: v8:6333
Change-Id: Iad2fdb7670dd01d19ed25c48a0091969cddb01c8
Reviewed-on: https://chromium-review.googlesource.com/632257Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47592}

This also removes the IS_GLOBAL macro from macros.py, which did
not work correctly for Remote objects/contexts.

Bug: v8:6413
Change-Id: I90690bdd0d8e8fed581bc4c9f5c60168d785f096
Reviewed-on: https://chromium-review.googlesource.com/633872Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47585}

This timer imposes a high overhead and does not give us the data we'd
like. Disabling for now until we can develop a better solution.

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

- Convert S.p.includes builtin from CPP to TFJ
  - Fast paths S.p.includes(str) and S.p.includes(str, smi)
- Add Runtime kStringIncludes
- Add StringIncludesIndexOfAssembler (Generate is based on
  StringPrototypeIndexOf builtin)
- S.p.includes and S.p.indexOf both use StringIncludesIndexOfAssembler

Quick measurements show 3x improvement for S.p.includes(str).
More about the measurements: https://gist.github.com/peterwmwong/7a2a96f3171a52f16ca8125a089f38e7

Bug: v8:6680
Change-Id: I79cb8dbe2b79e6df15aa734e128eee25c7e6aaf5
Reviewed-on: https://chromium-review.googlesource.com/620150Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47546}

R=ishell@chromium.org
BUG=v8:6409

Change-Id: Ic01d4f1a8b251bb5480840d4943d9ebec713b9c1
Reviewed-on: https://chromium-review.googlesource.com/626016Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47534}

CSA::AllocateSeq{One,Two}ByteString used its own home-grown handling to
allocate very large strings. This CL refactors both methods to use
AllocationFlags::kAllowLargeObjectAllocation instead. Callers now need
to specify explicitly if large-object allocation is possible or not.

Bug: chromium:636391
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I0b7ffb0b083f4e977cea42c500f8f2ee1c60519f
Reviewed-on: https://chromium-review.googlesource.com/625738Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47504}

There's no need for these to be static.

Bug: v8:5717
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia704cdcb9ee9666c7724b78d58c56217cd5876ae
Reviewed-on: https://chromium-review.googlesource.com/624869
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47490}

This no longer causes allocation, so it's safe to unhandlify.

This will allow us to use directly call into C++ (via CallCFunction)
to calculate the hash instead of going through the runtime (via
%GenericHash).

Bug: v8:5717
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia561efb4d89d7a3d10c28913537b45b3ce477bb3
Reviewed-on: https://chromium-review.googlesource.com/624519Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47489}

This feature is a stage 3 proposal implemented as a
wrapper around ICU that categorizes singular/plural/etc
grammatical forms based on a number and locale.

Based on littledan's work started here:
https://codereview.chromium.org/2736543002/

Bug: v8:5601
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4107cd28be72413ec43aa1ff0f4fe6e181a290f4
Reviewed-on: https://chromium-review.googlesource.com/562298
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47485}