Part of the improve error messages initiative.
Based on a resource of JSON.parse() errors found at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
added support for:
- 'Bad control character in string literal'
- 'Bad Unicode escape'
Previously JSON.parse('"a\bz"') would output:
SyntaxError: Unexpected token in JSON at position 2
Now the output is:
SyntaxError: Bad control character in string literal in
JSON at position 2
Previously JSON.parse("[\"\\t\\u") would output:
SyntaxError: Unexpected end of JSON input
Now the output is:
SyntaxError: Bad Unicode escape in JSON at position 6
Bug: v8:6551
Change-Id: I3ba5450c41b8a388643a15bc58e4e3fc75855d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652254
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Issack John <issackjohn@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80642}
args.set_at lead to a vulnerability in the past where the caller
(ignition) didn't expect the callee to overwrite the arguments.
The current usage doesn't look like an issue, but let's preemptively
remove these usages so that they don't lead to issues in the future.
Change-Id: I64e1f84ad1833b2b2f96cd7503bdde00f344404c
Bug: chromium:1268738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644965
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Stephen Röttger <sroettger@google.com>
Cr-Commit-Position: refs/heads/main@{#80641}
Specifically, move numeric conversions from WasmGraphBuilder, and add
functionality for traps.
These will be used in wasm-gc lowering phases.
Change-Id: I73f0dab28d87db8f1c4c339ea3d871f262e270ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654101
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80638}
The script compilation cache contains weak pointers to Script objects as
its keys. When doing a rehashing operation, any hash table needs the
ability to get the hash code for every entry in the table. However, if
the weak pointer was cleared from a key, there is no longer any way to
get the hash code for that entry.
In https://crrev.com/c/3597106 , I attempted to solve this problem by
deleting all entries whose keys contain cleared weak pointers prior to
rehashing, but the implementation has a bug: when resizing, the new
table is allocated after deleting the entries with cleared keys, so if
that allocation triggers a GC, the table can once again have entries
with cleared keys.
This could be solved in a variety of ways, such as:
1. Iterate the entries again and delete those with cleared keys, after
allocating the new table but before calling Rehash() to copy data
into that new table. This means we can't directly use
HashTable::EnsureCapacity, which normally does both the allocation
and the rehashing.
2. Return a bogus hash code for entries whose keys contain cleared weak
pointers. This is simple but risks poor distribution of data after
rehashing.
3. Implement custom rehashing which can avoid copying entries with
cleared keys, rather than reusing the rehashing implementation from
HashTable.
4. Include the hash value in every key, so a consistent hash value is
available even after the weak Script pointer has been cleared.
The fourth option sounds like the lowest risk to me, so this change
implements that option.
Bug: v8:12808
Change-Id: I6b19b9c8af67dcfc31b74842ba581dd141e18845
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654413
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80637}
The majority of 64-bit Android devices appear to be using a 40-bit
address space, i.e. 512GB for userspace. Allocating a 256GB sandbox
(plus 2x 32GB guard regions) may take too much of the address space and
cause the creation of other address space reservations (e.g. the cppgc
caged heap), which are created per worker, to fail later on.
In general, we should try to limit the sandbox size to less than 1/4 of
the address space, so this CL shinks the sandbox on Android to 128GB.
Bug: chromium:1327131
Change-Id: Ib48b45506ad6a7a5e15b95115c7642bf62a68fa1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652783
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80636}
As a follow-up to https://crrev.com/c/3625835, document how we
internally encode Wasm opcodes in the WasmOpcode enum. In particular,
it's important for the mapping to be bijective.
R=thibaudm@chromium.orgCC=gdeepti@chromium.org
Bug: v8:12284
Change-Id: Ic4bcd70211e83b1eabb45204bdcce3209a4432b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647360
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80635}
This fixes a few minor issues in the handling of priority top-tier
compilation units, and adds some comment.
1) We document the current design around priority top-tier units.
2) We simplify the code to increase the priority a bit, and make sure to
avoid integer overflows.
3) We reorder two statements to first increase the
outstanding_top_tier_functions_ counter before adding a new unit, in
order to avoid starting to execute a top-tier unit when the counter
is 0, which would be an inconsistent state.
R=ahaas@chromium.org
Bug: v8:12880
Change-Id: I67bd71135f34b793ea5cf064108668fb72c7e345
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654097
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80634}
Dynamic tiering is now enabled by default, and the origin trial is
expired, so the callback can be removed.
The callback was already never called, because the flag value is always
checked first.
R=ahaas@chromium.org, mlippautz@chromium.org
Bug: v8:12281
Change-Id: I58eaa210c86024128328a13ba07bb8fc1b437841
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644951
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80633}
* "volatile" on by-value params is deprecated. Remove.
* ICU has decided not to fix a warning about rewritten comparison
operators. Work around. This is ugly, but the alternative is
disabling the warning entirely for this file or all of v8, which seem
worse.
Bug: chromium:1284275
Change-Id: Ia90ae439fc56c3970da539d4ae3a64927ec4357b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652575
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80631}
The frozenness / sealednes is not yet serialized & deserialized, but
this allows prototyping web snap in contexts where frozen / sealed
elements occur.
Bug: v8:11525, v8:12820
Change-Id: I8fb788bd3d1a1ec3e6b47610c69230cc900033b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652779
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80630}
Rolling v8/build: 5b615fa..62419bc
Rolling v8/buildtools/linux64: git_revision:bf4e17dc67b2a2007475415e3f9e1d1cf32f6e35..git_revision:c547ca1497e3ff0dcbc0b2cb036b3d40380cbeeb
Rolling v8/buildtools/third_party/libc++abi/trunk: b682786..75a3853
Rolling v8/buildtools/third_party/libunwind/trunk: 44c86bb..837a94e
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ecd2da3..8111049
Rolling v8/third_party/depot_tools: 8fb649c..ab4d2e3
Rolling v8/third_party/fuchsia-sdk/sdk: version:8.20220516.3.1..version:8.20220518.3.1
Rolling v8/third_party/zlib: 7085d03..2fe249a
Rolling v8/tools/clang: 56af55b..6e492e7R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ie312502b162d4244148f4345649c3a7f1d0a7f65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3654580
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80626}
If b is S128Zero, Shuffle(a,b,s) can be optimized to
Swizzle(a,s). By setting s[i] to 0x80, we can avoid access b.
If a is S128Zero, we can swap a and b first.
If one input of I8x16Shuffle is S128Zero, this patch can save
~60% instructions(7 of 12), and more than 30% improvement is
observed in local microbenchmarks.
Change-Id: I5953fa9064e01203cd4cf423c55dd5ed33cad57e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3544992
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#80623}
Fix for the following minor issue:
```
error: variable 'first_output_index' set but not used
```
Change-Id: Iccc5e15db62a5768ba6f3742f3c4d7123f493c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652093
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80620}
Goal is to keep the tree green while the issue is investigated.
No impact on shipped product since shared-memory is flag-guarded off.
Bug: v8:12883
Change-Id: I9a434bdebc781023fa6693eef47db6dbe81cd4bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653320
Auto-Submit: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80619}
This reverts commit a76072217a.
Reason for revert: fails on GC Stress bot:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/38512/overview
Original change's description:
> Disable recompilation of existing Scripts from Isolate compilation cache
>
> My previous change https://crrev.com/c/3597106 led to some performance
> regressions in time spent on parsing and compilation. This change
> disables the ability to recompile an existing uncompiled Script, as an
> attempt to both fix the regressions and isolate which part of the
> previous change was the cause of those problems.
>
> Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
> Change-Id: Ifa086bf27070da8f4b3c0e4415af5ca7b6706b0a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652252
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#80616}
Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
Change-Id: I0f56163856d04ff49da96b0fb344fb59b5501a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653273
Auto-Submit: Adam Klein <adamk@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80617}
My previous change https://crrev.com/c/3597106 led to some performance
regressions in time spent on parsing and compilation. This change
disables the ability to recompile an existing uncompiled Script, as an
attempt to both fix the regressions and isolate which part of the
previous change was the cause of those problems.
Bug: v8:12808, chromium:1325566, chromium:1325567, chromium:1325601
Change-Id: Ifa086bf27070da8f4b3c0e4415af5ca7b6706b0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652252
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80616}
The test cctest/test-v8windbg recently started failing because the
v8windbg debugger extension is unable to read the "flags" field on a
SharedFunctionInfo instance. This occurs because one of the bitfields
within "flags" has type OSRCodeCacheStateOfSFI, which is only declared
using an "opaque enum declaration":
enum OSRCodeCacheStateOfSFI : uint8_t;
When WinDbg fails in its attempt to look up that type, v8windbg responds
by failing to construct anything at all for "flags". However, the other
17 bitfields in "flags" can be represented successfully, so a more
useful behavior is to just skip the one failed entry.
Change-Id: I40630548d21499e49f0214da28260318a38d9360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3653096
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80615}
BACKGROUND_UNPARK and BACKGROUND_SAFEPOINT were introduced in
crrev.com/c/2704075 but the LAST_GENERAL_BACKGROUND_SCOPE was
not updated, so they were not tracked properly by GCTracer.
Bug: v8:12425
Change-Id: Ibbd7f5410088c45454b6e22af4e038e8ef0dd7fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650598
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80613}
In particular use the same "location" in any call site to make grouping
OOMs easier. Move the detail information into the new OOMDetails struct.
Since we cannot construct OOMDetails via "{.detail = ...}" yet (C++20),
we add another variants of FatalProcessOutOfMemory which receives the
detail string and internally stores it in an OOMDetails struct.
R=jkummerow@chromium.orgCC=mlippautz@chromium.org
Bug: chromium:1323177
Change-Id: Ie10cde8dd060867515fab4c61c15030f9c3ccff9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652298
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80612}
There is a DCHECK in the gin platform that {ShouldYield} is not called
again after it already returned {true}.
This CL adds a similar DCHECK to the default platform to catch bugs
earlier (in d8).
R=ahaas@chromium.org, mlippautz@chromium.org
Bug: chromium:1277962
Change-Id: I4dc9d880cf6d36e3e497c5324aaf44889fe7fcee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644801
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80611}
This is a follow-up CL to https://crrev.com/c/3623542.
When updating pointers during a full GC, a page might not be swept
already. In such cases there might be invalid objects in free memory.
Since these objects might be dead, their maps might have been reclaimed
already as well.
The previous CL cached the size of invalid objects in order to avoid
accessing an invalid object's map. However, as soon as a slot is within
an invalid object, we also need to check whether this slot is still a
tagged pointer which would require map access. This CL checks marking
bits on invalid objects to skip that check on such invalid objects.
Bug: v8:12578, chromium:1316289
Change-Id: Ie1d736f897a2994dbed7bfb95ed37732cd3b0882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596123
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80609}
When call_ref has seen more than one call target, we now support
inlining all of them (constrained by budget/heuristics).
Bug: v8:7748,v8:12166
Change-Id: Iae16e74da1bad5e7a117f70efb6c61b3f39f832c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650607
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80602}
The forced allocation of fixed registers can override the arbitrary
choice of register in a previous allocation. Fix this by first
allocating fixed registers, and only afterward allocating arbitrary
registers.
Also add a DCHECK after input assignment that input locations match
their node's current location.
Bug: v8:7700
Change-Id: I262c2a1f9a3c47d5c23c84b3764569692f18f39d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644958
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80601}
