Empty slot set buckets can leak in the following scenarios.
Scenario 1 (large object space):
1) A large array is allocated in the large object space.
2) The array is filled with old->new references, which allocates new
slot set buckets.
3) The references are overwritten with smis or old space pointers, which
make the slots set buckets empty.
4) Garbage collection (scavenge or mark-compact) iterates the slots set
of the array and pre-frees the empty buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for large object space in mark-compact.
Scenario 2 (no mark-compact):
1) A small array is allocated in the old space.
2) The array is filled with old->new references, which allocates new
slot set buckets.
3) The references are overwritten with smis or old space pointers, which
make the slots set buckets empty.
4) Scavenge iterates the slots set of the array and pre-frees the empty
buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for swept pages in scavenger.
Bug: v8:6800
TBR: mlippautz@chromium.org
Change-Id: I48d94870f5acf4f6208858271886911c895a9126
Reviewed-on: https://chromium-review.googlesource.com/668442
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48041}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a
Reviewed-on: https://chromium-review.googlesource.com/657021
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48040}
Given that the index we use is checked to be in array index range there is no
need for a costly ToString conversion. All involved helpers for lookup up
properties directly support Smi/HeapNumber indices directly.
Cleanup: Rename GotoUnlessNumberLessThan => GotoIfNumberGreaterThanOrEqual
Change-Id: Iaddc4940f5d984572aa218d568ca71bf694cee74
Reviewed-on: https://chromium-review.googlesource.com/640388
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48039}
When using Lockers and Unlockers it is possible to create a
scenario where multiple threads point to the same optimized
code object. When that happens, if one of the threads triggers
deoptimization, then the stack replacement needs to happen in
the stacks of all threads.
With this CL, the deoptimizer visits all threads to do so.
The CL also adds three tests where V8 used to crash.
Bug: v8:6563
Change-Id: Iea88f47af2f31181c0ef06d898faccde9ad14432
Reviewed-on: https://chromium-review.googlesource.com/657423
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#48033}
When accessing the buffer in 1 byte increments, the order should
be reversed for BE.
R=petermarshall@chromium.org, yangguo@chromium.org
BUG=
LOG=N
Change-Id: I27a57e12479d1c00488546a92428b9183d87f8bf
Reviewed-on: https://chromium-review.googlesource.com/667902
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48031}
This patch ensures a `TypeError` is thrown when the argument passed to
`Array.prototype.sort` or `%TypedArray%.prototype.sort` is neither a
function nor `undefined`.
Every other major JavaScript engine already threw in this case. Making
V8’s behavior match increases interoperability.
https://github.com/tc39/ecma262/pull/785
BUG=v8:6542
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I412a59810abdd118217c8d8361389ec6c2f640bd
Reviewed-on: https://chromium-review.googlesource.com/668356
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48028}
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.
In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.
Bug:v8:6785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
- Validate that atomic ops can only be called when shared memory is declared
- Throw Compile/Link erros on mismatch between declared, imported memory
- Test harness helpers for setting shared memory, tests
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I43fe3d04bb7e3e0a2cecca0528578f98844d2608
Reviewed-on: https://chromium-review.googlesource.com/665379
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48019}
This patch ensures that an object returned by AllocateRaw is marked
black if black allocation starts during the object allocation.
This fixes the following issue:
1) Generated code requests allocation of size N for folded allocation.
2) Runtime gets a free list node at address A of size N+M and sets up
a linear allocation area with top = A+N and limit = A+N+M.
3) Runtime invokes the allocation observer that starts incremental marking
and start black allocation. The area [A+N, A+N+M) is marked black.
4) Runtime returns a white object at address A as the allocation result.
5) Generated code moves the top pointer to A and does bump pointer
allocations of white objects from A to A+N+M.
6) Object allocated new A+N can have the impossible marbit pattern.
Bug: chromium:694255
Change-Id: I09ceebc97a510fa5fe4ff20706bc46a99f8b7cf4
Reviewed-on: https://chromium-review.googlesource.com/638338
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48005}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
Before we used to require compiled debugger script to report Scopes.
After migration inspection to brand-new native API we can report
Scopes all the time and remove this hidden dependency.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3530bc7ead691a51073e384aea4a4ef428dc94da
Reviewed-on: https://chromium-review.googlesource.com/662097
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47982}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
As part of that change, make ToNumber return in the accumulator.
Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
So far we didn't properly constant-fold JSToString operators in
JSTypedLowering where the input was a known number constant.
Bug: v8:6815
Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524
Reviewed-on: https://chromium-review.googlesource.com/663358
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47972}
This further reduces the amount of test-specific code. It will also
help testing the wasm baseline compiler, since it is also being called
from the {WasmCompilationUnit}.
Also, move the {RuntimeExceptionSupport} flag from the
{WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need
to store this per function builder. The {TestingModuleBuilder} then
passes it on to the {WasmCompilationUnit}, which finally sets it on the
{WasmGraphBuilder}.
R=mtrofin@chromium.org
Bug: v8:6600
Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee
Reviewed-on: https://chromium-review.googlesource.com/660239
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47970}
We were using a boolean before, which makes the meaning non-obvious
when passed as a parameter. With the enum, you actually have to use
{kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}.
R=mtrofin@chromium.org
Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49
Reviewed-on: https://chromium-review.googlesource.com/660738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47969}
Contributed by kanghua.yu@intel.com.
Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
When accessing elements of a global (constant) JSArray, whose backing
store is copy-on-write, we can just constant-fold the value and insert
a check that the backing store stays the same.
Bug: v8:6816, v8:6815
Change-Id: I090bcec7b1ce72a1f9ed8625680ed91e8c67f27f
Reviewed-on: https://chromium-review.googlesource.com/662757
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47963}
- Memory.Grow with guard pages enabled should adjust amount of allocated
memory, and not allocate a new buffer. This was disabled because previously
the backing store was freed in the MemoryFinalizer, and we needed to be sure
that the backing store is not released till the last buffer using it is
released. This is now safe as we no longer use the MemoryFinalizer
- SetProtection should use Guard/Unprotect that use mprotect underneath,
instead of CommitRegion/UncommitRegion that use mmap
- Move buffer allocation to the end to avoid inconsistent memory due to GC
BUG=v8:5886
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40
Reviewed-on: https://chromium-review.googlesource.com/629517
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47960}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.
Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
The Typer put the wrong type on String#index and String#lastIndexOf
builtins, with an off by one on the upper bound.
Bug: chromium:762874
Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932
Reviewed-on: https://chromium-review.googlesource.com/660000
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47942}
In the test case the module contained a memory which got exported by the
name 'main'. The fuzzer crashed when it tried to cast the memory to a
function to execute it. This CL checks that 'main' is a function before
doint the cast.
R=clemensh@chromium.org
Bug: chromium:763349
Change-Id: I9a21413c8038a7547f8b59057afea2870b15499a
Reviewed-on: https://chromium-review.googlesource.com/659978
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47941}
TurboFan wasn't able to inline calls to Array.prototype.push which
didn't have exactly one parameter. This was a rather artifical
limitation and was mostly due to the way the MaybeGrowFastElements
operator was implemented (which was not ideal by itself). Refactoring
this a bit, allows us to inline the operation in general, independent
of the number of values to push.
Array#push with multiple parameters is used quite a lot inside Ember (as
discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823)
and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see
https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the
SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug
(v8:6808) improves from
arrayPush0: 2422 ms.
arrayPush1: 2567 ms.
arrayPush2: 4092 ms.
arrayPush3: 4308 ms.
to
arrayPush0: 798 ms.
arrayPush1: 2563 ms.
arrayPush2: 2623 ms.
arrayPush3: 2773 ms.
with this change, effectively removing the odd 50-60% performance
cliff that was associated with going from one parameter to two or
more.
Bug: v8:2229, v8:6808
Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57
Reviewed-on: https://chromium-review.googlesource.com/657582
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47940}
If Coverage goes out of scope, ScriptData, FunctionData, or BlockData still rely on
Coverage's coverage_. Make coverage_ a shared_ptr owned by all four classes.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifab5d05184cc5db0fd0a935254b967286295e63f
Reviewed-on: https://chromium-review.googlesource.com/657381
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47938}
It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.
String.fromCharCode.apply(undefined, uint8array)
is seen quite often on the web. But there are other interesting cases
like
Math.max.apply(undefined, float64array)
to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.
This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from
stringFromCharCode: 6386 ms.
stringFromCodePoint: 8752 ms.
to
stringFromCharCode: 1932 ms.
stringFromCodePoint: 4262 ms.
which corresponds to a 2.0x-3.3x improvement.
Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
Even though we were generating additional arguments with default value
in the case that the caller was not providing enough, we then passed
the original pointer, leading to potential out-of-bounds accesses.
R=ahaas@chromium.org
Bug: chromium:763294,chromium:763297
Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17
Reviewed-on: https://chromium-review.googlesource.com/657699
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47930}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
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}
