It always throws an exception in the cases that it fails, so throwing another
doesn't help things.
BUG=chromium:664416
Review-Url: https://codereview.chromium.org/2495393002
Cr-Commit-Position: refs/heads/master@{#40999}
This CL moves all heap-allocated WASM data structures, both ones
that are bonafide JSObjects and ones that are FixedArrays only, into a
consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness
to all places in the code.
R=ahaas@chromium.org,rossberg@chromium.org
CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2490663002
Cr-Commit-Position: refs/heads/master@{#40913}
Compatible with the current (unshipped) Blink implementation.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2471923002
Cr-Commit-Position: refs/heads/master@{#40775}
While this seems like it should be true, the array buffer is not actually
neutered until the end of cloning. This is so that, if an exception is thrown
during serialization, the original array buffer is not left neutered. As a
result, Blink will not have neutered the buffer.
This fixes some DCHECK failures during layout tests.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2466563002
Cr-Commit-Position: refs/heads/master@{#40675}
This adds more useful information to the v8-heap-stats tool.
BUG=v8:5489
Review-Url: https://codereview.chromium.org/2394213003
Cr-Commit-Position: refs/heads/master@{#40361}
Found with libfuzzer. The length is automatically converted to int (thus
large sizes could become negative, even though they are legal "array sizes").
Besides that, the length is coerced to a SMI (which is an even tighter
constraint on 32-bit systems, where it limits the legal sizes to 2^30 - 1).
Add checks that the length of a dense array is below that threshold, and also
fail fast if a length that is provided obviously could not be the correct dense
length (because there isn't enough data left in the buffer to populate such an
array).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2399873002
Cr-Commit-Position: refs/heads/master@{#40094}
Previously this would result in applying trying to find a size modulo zero,
which causes SIGFPE. This approach was preferred over adding a default case
to preserve the ability of the compiler to detect unhandled switch cases
(within the valid range of the enum).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2395073003
Cr-Commit-Position: refs/heads/master@{#40088}
Some DOM objects, like FileList, have indexed property handlers, and become
JS_SPECIAL_API_OBJECT_TYPE.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2364053003
Cr-Commit-Position: refs/heads/master@{#39686}
In practice this is a dense array, because there is currently no provision
in the format for assigning IDs other than sequentially to every object.
Thus a FixedArray is more efficient than a general dictionary.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2342293003
Cr-Commit-Position: refs/heads/master@{#39486}
This exposes an interface for the embedder to provide a delegate which can
serialize or deserialize embedder-specific objects, like Blink's DOM wrappers.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2327653002
Cr-Commit-Position: refs/heads/master@{#39422}
json-parser does the same thing. This drastically reduces GC cost when
deserializing objects large enough that multiple collections are likely
(since it saves the effort to move them to the old generation, when we
know that the objects we create will persist at least until the deserializer
finishes).
The threshold was chosen to match json-parser.
This patch reduces deserialization time on a large blob of JSON-y data
by approximately 30%.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2336973004
Cr-Commit-Position: refs/heads/master@{#39396}
v8::Isolate::Throw only schedules the exception; it is necessary to promote it
after invoking the delegate.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2332843003
Cr-Commit-Position: refs/heads/master@{#39395}
Without this cast, the integer type isn't promoted before being shifted, and so
for types larger than sizeof(int) there is data loss. This will become an issue
once the host begins using this helper to send 64-bit integers.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2326653002
Cr-Commit-Position: refs/heads/master@{#39296}
This yields a ~5% serialization time improvement on typical JSON-esque data.
The approach taken matches json-stringifier fairly closely.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2311063004
Cr-Commit-Position: refs/heads/master@{#39254}
This yields a ~20% serialization time improvement on typical JSON-esque data.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2304563004
Cr-Commit-Position: refs/heads/master@{#39221}
This restores the contract that all API methods that return Maybe<T> or
MaybeLocal<T> always throw an exception when they return nothing.
Since v8::ValueDeserializer::ReadHeader can now throw exceptions, it
needs a Local<Context> parameter so that it can set up execution state
(entering the context, etc.). The old method has been marked for
deprecation, but since this API is experimental I intend to remove it
as soon as I've removed the use from Blink.
value-serializer-unittest has been updated to expect an exception in
all decode failure cases.
BUG=chromium:148757,chromium:641964
Review-Url: https://codereview.chromium.org/2308053002
Cr-Commit-Position: refs/heads/master@{#39188}
It emits spurious -Wmaybe-uninitialized warnings. Initializing these variables
shouldn't do any harm (with an optimizing compiler), so this seems the quickest
way to mollify gcc.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2290653003
Cr-Commit-Position: refs/heads/master@{#39000}
The format of this is a little strange, and has to do with the previous
implementation maintaining a "stack" of objects as it works. As a result,
the format writes the array buffer before giving any hint that the reason
for doing so is to obtain a view wrapping it. Handling this without creating
an explicit on-heap stack requires checking whether the next tag is 'V'
after obtaining an array buffer.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2287653002
Cr-Commit-Position: refs/heads/master@{#38984}
The embedder is expected to arrange for the array buffer contents to be
transferred into a v8::ArrayBuffer in the receiving context (generally by
assuming ownership of the externalized backing store).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2275033003
Cr-Commit-Position: refs/heads/master@{#38948}
Transferral is not included in this CL, nor is SharedArrayBuffer.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2264403004
Cr-Commit-Position: refs/heads/master@{#38913}
Version 0 dense arrays cannot be deserialized by current Chromium, which
suggests that this is not necessary.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2256413002
Cr-Commit-Position: refs/heads/master@{#38754}
The current "dense" format is not expressive enough to distinguish between
an element that is not defined and one that has the value "undefined",
but in this CL the existing behaviour of Blink is used for such cases.
Format changes to fix these issues could be made later on.
Not included in this CL is compatibility with version 0 arrays.
Those will be implemented in a separate CL.
BUG=chromium:148757
Committed: https://crrev.com/2e000127df2e88e31d352ef70af397741d1f2298
Review-Url: https://codereview.chromium.org/2259633002
Cr-Original-Commit-Position: refs/heads/master@{#38729}
Cr-Commit-Position: refs/heads/master@{#38732}
Reason for revert:
Broke MIPS compile due to an uninitialization warning:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/3110/steps/compile/logs/stdio
Original issue's description:
> Blink-compatible serialization of arrays, both dense and sparse.
>
> The current "dense" format is not expressive enough to distinguish between
> an element that is not defined and one that has the value "undefined",
> but in this CL the existing behaviour of Blink is used for such cases.
> Format changes to fix these issues could be made later on.
>
> Not included in this CL is compatibility with version 0 arrays.
> Those will be implemented in a separate CL.
>
> BUG=chromium:148757
>
> Committed: https://crrev.com/2e000127df2e88e31d352ef70af397741d1f2298
> Cr-Commit-Position: refs/heads/master@{#38729}
TBR=jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2255313002
Cr-Commit-Position: refs/heads/master@{#38730}
The current "dense" format is not expressive enough to distinguish between
an element that is not defined and one that has the value "undefined",
but in this CL the existing behaviour of Blink is used for such cases.
Format changes to fix these issues could be made later on.
Not included in this CL is compatibility with version 0 arrays.
Those will be implemented in a separate CL.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2259633002
Cr-Commit-Position: refs/heads/master@{#38729}
The "version 0" format did not deal with references, and used a stack model to
deserialize objects (conceptually, a postorder tree traversal). This requires
an explicit stack, so special logic is added to decode this format.
All subsequent versions also put an object marker at the beginning, which is
equivalent to how the current version serializes.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2248893003
Cr-Commit-Position: refs/heads/master@{#38686}
As part of this CL, object reference tracking is implemented (and tested with a
self-referential object). This sort of reference tracking will be shared with
other receivers (array, date, regexp and host objects).
Not included in this CL is compatibility with version-0 objects (which don't
support a non-tree object graph, and require a little stack to correctly
deserialize).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2246093003
Cr-Commit-Position: refs/heads/master@{#38683}
This includes UTF-8 strings and two-byte strings, both length-delimited
(in bytes, not characters). Two-byte strings are written/read in host byte
order.
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2245753002
Cr-Commit-Position: refs/heads/master@{#38636}
This includes unsigned integers (encoded as base-128 varints), signed integers
(ZigZag-encoded, then varint-encoded) and doubles (written in host byte order).
BUG=chromium:148757
Review-Url: https://codereview.chromium.org/2232323004
Cr-Commit-Position: refs/heads/master@{#38630}
