Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deps: update V8 to 5.7 #11752

Merged
merged 10 commits into from
Mar 25, 2017
Prev Previous commit
Next Next commit
deps: cherry-pick V8 ValueSerializer changes
Refs: #11048

Below is the list of commits:

deps: cherry-pick 78c0be52d from V8 upstream

Original commit message:

  ValueSerializer: Promote scheduled exceptions from wasm::ErrorThrower.

  wasm::ErrorThrower doesn't actually throw exceptions, it just schedules them.
  As a result, this exception isn't handled properly by code which expects
  ValueDeserializer to actually throw. For instance, the unit tests use a
  TryCatch to catch and handle expected exceptions in unit tests.

  Before this patch, I see local unit test failures because a wasm decode test
  schedules one, but it isn't caught (and instead causes Context::New to fail
  at the beginning of the next test).

  BUG=685713

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

deps: cherry-pick 966355585 from V8 upstream

Original commit message:

  [d8] Use ValueSerializer for postMessage (instead of ad-hoc serializer)

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

deps: cherry-pick bf511b426 from V8 upstream

Original commit message:

  ValueSerializer: Support efficiently reading and writing one-byte strings.

  memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
  serializing and deserializing long ASCII strings, according to
  blink_perf.bindings -- and these are already in a fast path where the entire
  string is known to be ASCII (but this has to be checked). The win may be
  larger for strings in Latin-1 but not ASCII (though I suspect this is an
  uncommon case).

  A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
  survive wire format version number changes.

  This is the first of a series of wire format changes from the previous Blink
  format. The deserializer continues to be able to read the old format, but
  Chromium M56 will no longer be able to read the messages written by this, in M58.

  BUG=chromium:686159

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

deps: cherry-pick 6f1639ed1 from V8 upstream

Original commit message:

  ValueSerializer: Distinguish between 'undefined' and an absent property.

  Dealing with this case requires a wire format change. It is possible that an
  element can be absent even in an array where the dense format was chosen
  (because the array initially had no holes), if the elements are modified while
  they are being serialized. In this case, a new tag for the "hole" is emitted.

  The logic to treat undefined in dense arrays as an absent property is restricted
  to versions of the wire format that this tag did not exist.

  BUG=chromium:686159,chromium:665820

  Review-Url: https://codereview.chromium.org/2660093002
  Cr-Original-Commit-Position: refs/heads/master@{#42784}
  Committed: https://chromium.googlesource.com/v8/v8/+/dc85f4c8338c1c824af4f7ee3274dc9f95d14e49
  Review-Url: https://codereview.chromium.org/2660093002
  Cr-Commit-Position: refs/heads/master@{#42800}

deps: cherry-pick c3856de37 from V8 upstream

Original commit message:

  ValueSerializer: Check for zero length before casting to FixedDoubleArray.

  Even though the elements kind is FAST_DOUBLE_ELEMENTS, if length is zero
  the isolate's empty_fixed_array is used. It's illegal to cast this to
  FixedDoubleArray, so we avoid the cast.

  BUG=chromium:686479

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

deps: cherry-pick 591cc0b4c from V8 upstream

Original commit message:

  ValueSerializer: Share string encoding code with String and RegExp objects.

  This avoids the need to pull in the UTF-8 encoding code from the public API,
  and allows it to take advantage of any supported way that i::String can be
  encoded (one- or two-byte).

  Backward compatibility is maintained, but this is the behavior beginning
  with this version.

  BUG=chromium:686159

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

deps: cherry-pick 79837f5f6 from V8 upstream

Original commit message:

  Improve ValueSerializer perf regression after 96635558

  BUG=687196
  R=jbroman@chromium.org

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

deps: cherry-pick 8990399dc from V8 upstream

Original commit message:

  ValueDeserializer: Only allow valid keys when deserializing object properties.

  The serializer won't ever write a more complex object. Not validating this
  allows other things to be used as keys, and converted to string when the
  property set actually occurs. It turns out this gives an opportunity to trigger
  OOM by giving an object a key which is a very large sparse array (whose string
  representation is very large).

  This case is now rejected by the deserializer.

  BUG=chromium:686511

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

deps: cherry-pick 68960eeb7 from V8 upstream

Original commit message:

  ValueDeserializer: Make sure that an exception is the legacy path.

  The entry points to the deserializer are responsible for ensuring that an
  exception is pending by the time they return. Some failures throw exceptions
  themselves, while others (like errors in the format) are exceptions caused by
  the deserializer, not coming from the runtime.

  Like the non-legacy path, a default deserialization exception should be thrown
  in such cases.

  BUG=chromium:693411

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

deps: cherry-pick 3b15d950e from V8 upstream

Original commit message:
  ValueSerializer: Add SetTreatArrayBufferViewsAsHostObjects() flag

  Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
  instructs the `ValueSerializer` to treat ArrayBufferView objects as
  host objects.

  BUG=v8:5926

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

deps: cherry-pick 654351997 from V8 upstream

Original commit message:

  ValueSerializer: Add an explicit tag for host objects.

  This makes it no longer necessary to ensure that V8 and Blink have non-colliding
  tags, which makes it easier for them to evolve independently, and also makes
  the wire format more suitable for other V8 embedders, who would not
  necessarily be surveyed before V8 introduced a new tag that might collide
  with theirs.

  BUG=chromium:686159

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

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
  • Loading branch information
addaleax authored and targos committed Mar 25, 2017
commit 83bf2975ec7a105c1e08caba21e5c4cccd9beabb
13 changes: 13 additions & 0 deletions deps/v8/include/v8.h
Original file line number Diff line number Diff line change
@@ -1726,6 +1726,10 @@ class V8_EXPORT ValueSerializer {
* Allocates memory for the buffer of at least the size provided. The actual
* size (which may be greater or equal) is written to |actual_size|. If no
* buffer has been allocated yet, nullptr will be provided.
*
* If the memory cannot be allocated, nullptr should be returned.
* |actual_size| will be ignored. It is assumed that |old_buffer| is still
* valid in this case and has not been modified.
*/
virtual void* ReallocateBufferMemory(void* old_buffer, size_t size,
size_t* actual_size);
@@ -1781,6 +1785,15 @@ class V8_EXPORT ValueSerializer {
uint32_t transfer_id,
Local<SharedArrayBuffer> shared_array_buffer));

/*
* Indicate whether to treat ArrayBufferView objects as host objects,
* i.e. pass them to Delegate::WriteHostObject. This should not be
* called when no Delegate was passed.
*
* The default is not to treat ArrayBufferViews as host objects.
*/
void SetTreatArrayBufferViewsAsHostObjects(bool mode);

/*
* Write raw data in various common formats to the buffer.
* Note that integer types are written in base-128 varint format, not with a
4 changes: 4 additions & 0 deletions deps/v8/src/api.cc
Original file line number Diff line number Diff line change
@@ -3130,6 +3130,10 @@ ValueSerializer::~ValueSerializer() { delete private_; }

void ValueSerializer::WriteHeader() { private_->serializer.WriteHeader(); }

void ValueSerializer::SetTreatArrayBufferViewsAsHostObjects(bool mode) {
private_->serializer.SetTreatArrayBufferViewsAsHostObjects(mode);
}

Maybe<bool> ValueSerializer::WriteValue(Local<Context> context,
Local<Value> value) {
PREPARE_FOR_EXECUTION_PRIMITIVE(context, ValueSerializer, WriteValue, bool);
Loading