Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2259633002:
Blink-compatible serialization of arrays, both dense and sparse. (Closed)
|
Created:
4 years, 4 months ago by jbroman Modified:
4 years, 4 months ago Reviewers:
Jakob Kummerow CC:
v8-reviews_googlegroups.com Base URL:
https://chromium.googlesource.com/v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
DescriptionBlink-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
Committed: https://crrev.com/2d3a53c9c813173080eaab45141aaf80cd07f052
Cr-Original-Commit-Position: refs/heads/master@{#38729}
Cr-Commit-Position: refs/heads/master@{#38732}
Patch Set 1 #Patch Set 2 : mostly more unit tests #Patch Set 3 : Micro-tweak: let NewJSArray construct the elements. #
Total comments: 24
Patch Set 4 : address review comments #Patch Set 5 : Merge branch 'master' into vs6 #Patch Set 6 : further review comments #Patch Set 7 : trivial fix for compiler initialization warning #
Messages
Total messages: 43 (30 generated)
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Blink-compatible serialization of arrays, both dense and sparse. The current format is not expressive enough to correctly serialize all arrays, 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 ========== to ========== 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 ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
jbroman@chromium.org changed reviewers: + jkummerow@chromium.org
As before, there are several possible fast paths here, but I've tried to write the slow path first. A handful of these tests cover cases according to the spec (and in accord with Firefox), even in some cases where Chromium currently does not comply with the spec. I _think_ I've gotten my braces right this time around, but I guess we'll see. ;)
LGTM, mostly nits. Happy to take another look if you end up making nontrivial changes. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc File src/value-serializer.cc (right): https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:298: // the format currently does not provide for properly distinguishing between The deserializer implementation below treats every |undefined| as if it was the hole, so that's not a reason to skip holey elements here. However, a holey array can have an arbitrary number of holes in it, so sparse serialization might be vastly more efficient. Your test cases are examples of this: "new Array(100000)" gives you a FAST_HOLEY_SMI_ELEMENTS array containing 100K holes, where the sparse serialization would be an empty list of pairs, whereas the dense serialization would be a very long sequence of "_" tags. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:303: array->HasFastElements() && !array->HasFastHoleyElements(); Given that the array could transition to slow or holey elements at any time, this is but a crude heuristic... https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:314: LookupIterator it(isolate_, array, i, array, LookupIterator::OWN); Please add a comment: // Recursively serializing the array's elements can have arbitrary // side effects, so we can't rely on still having fast packed elements. (Otherwise it's surprising that you're not just using "Handle<Object> element(array->elements()->get(i), isolate_);" here; but doing so would be a bug. You'd have to be very careful about checking in every iteration that the backing store hasn't changed.) https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:333: WriteVarint<uint32_t>(length); Any particular reason why |length| is written twice? https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:633: FAST_HOLEY_ELEMENTS, length, length, INITIALIZE_ARRAY_ELEMENTS_WITH_HOLE); It's a bit sad that deserialized arrays will always have FAST_HOLEY_ELEMENTS, but I suppose it's OK for a generic slow path implementation. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:641: if (element->IsUndefined(isolate_)) continue; This is inconsistent with the serializer. Are you sure you want to serialize but then forget explicitly present but undefined values? Specifically, a RoundTripTest on "[undefined,undefined]" would return "[<hole>, <hole>]" currently. https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... File test/unittests/value-serializer-unittest.cc (right): https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... test/unittests/value-serializer-unittest.cc:722: "(() => { var x = new Array(100000); x[5000] = 42; return x; })()", Fun fact: "new Array(10)" is just as sparse (or dense) as "new Array(100000)". Consider making the sparse-array tests more memory efficient by dropping a few zeroes. https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... test/unittests/value-serializer-unittest.cc:1002: // Same for sparse arrays. Installing getters transitions the array's elements to a dictionary backing store anyway, so this is really the same as the test above.
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
PTAL; I've responded to some of your comments, and I'd like to be certain we're on the same page. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc File src/value-serializer.cc (right): https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:298: // the format currently does not provide for properly distinguishing between On 2016/08/18 at 13:49:56, Jakob wrote: > The deserializer implementation below treats every |undefined| as if it was the hole, so that's not a reason to skip holey elements here. That's fair enough. I'd originally had the deserializer read it as undefined, before I realized Chrome currently does the opposite. > However, a holey array can have an arbitrary number of holes in it, so sparse serialization might be vastly more efficient. Your test cases are examples of this: "new Array(100000)" gives you a FAST_HOLEY_SMI_ELEMENTS array containing 100K holes, where the sparse serialization would be an empty list of pairs, whereas the dense serialization would be a very long sequence of "_" tags Sparse serialization is currently used for such cases. (The tests naturally get noticeably slower if I do not.) https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:303: array->HasFastElements() && !array->HasFastHoleyElements(); On 2016/08/18 at 13:49:56, Jakob wrote: > Given that the array could transition to slow or holey elements at any time, this is but a crude heuristic... A more principled heuristic would be used_elements >= length / 4 (because a missing element takes one byte to encode but an explicit integer key takes 2-5 bytes, say 3 typically, to encode). Doing this, however, requires explicitly enumerating first the elements first (in case some are non-enumerable). If there are no holes, it's pretty convenient, because every element must be enumerable (IIUC, a non-enumerable element would cause dictionary elements, and a hole would cause holey or dictionary elements). A proliferation of fast paths are possible. e.g., for fast holey elements, we could use a bit vector to record where the holes are, and then if skip indices that originally had holes; or if there are too many holes we can do a sparse serialization, but still more efficiently than the slow path, except of course it still has to have the escape hatch if a getter changes the backing store. I don't have a good sense for what the typical elements kinds are in practice (I'd expect that in practice most arrays likely to be serialized are fast non-holey arrays, but I don't know). This seemed like the quickest way of opting most stuff into a reasonably fast path without yet going down the road of adding various fast paths. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:314: LookupIterator it(isolate_, array, i, array, LookupIterator::OWN); On 2016/08/18 at 13:49:56, Jakob wrote: > Please add a comment: > // Recursively serializing the array's elements can have arbitrary > // side effects, so we can't rely on still having fast packed elements. > > (Otherwise it's surprising that you're not just using "Handle<Object> element(array->elements()->get(i), isolate_);" here; but doing so would be a bug. You'd have to be very careful about checking in every iteration that the backing store hasn't changed.) Done. That's why I left taking advantage of the elements being fast to a subsequent CL. (Also, doesn't that require an additional check that it isn't fast double elements; the elements aren't necessarily a FixedArray, right?) https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:333: WriteVarint<uint32_t>(length); On 2016/08/18 at 13:49:56, Jakob wrote: > Any particular reason why |length| is written twice? Compatibility with the existing format. Some of this redundancy could certainly be removed with a revision of the wire format, but if the deserializer wants to handle existing serialized objects (which may be stored in IndexedDB) it has to handle this, so for now I've been making the serializer fully compatible. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:633: FAST_HOLEY_ELEMENTS, length, length, INITIALIZE_ARRAY_ELEMENTS_WITH_HOLE); On 2016/08/18 at 13:49:56, Jakob wrote: > It's a bit sad that deserialized arrays will always have FAST_HOLEY_ELEMENTS, but I suppose it's OK for a generic slow path implementation. Probably logic to use FAST_ELEMENTS if there are no holes could be added later (though I'd have to figure out the map transitions for that case, as the JSArray has to be created before we deserialize the elements). Efficiently knowing more in advance would require wire format changes. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:641: if (element->IsUndefined(isolate_)) continue; On 2016/08/18 at 13:49:56, Jakob wrote: > This is inconsistent with the serializer. Are you sure you want to serialize but then forget explicitly present but undefined values? Specifically, a RoundTripTest on "[undefined,undefined]" would return "[<hole>, <hole>]" currently. In fact I don't want to, but the existing wire format doesn't provide for representing holes in the wire format. I intend to add a tag for a hole (as distinct from undefined) in a future version of the wire format, but indeed today if you postMessage([undefined,undefined], '*') in Chrome, you will get [<hole>,<hole>] on the other side. I have to interpret undefined as either undefined or a hole, so for consistency I've chosen the hole because Chrome does so today. https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... File test/unittests/value-serializer-unittest.cc (right): https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... test/unittests/value-serializer-unittest.cc:722: "(() => { var x = new Array(100000); x[5000] = 42; return x; })()", On 2016/08/18 at 13:49:56, Jakob wrote: > Fun fact: "new Array(10)" is just as sparse (or dense) as "new Array(100000)". Consider making the sparse-array tests more memory efficient by dropping a few zeroes. Can do; reduced to 1000. I thought I'd seen logic that used dictionary elements for that case, but I must have misread. https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... test/unittests/value-serializer-unittest.cc:1002: // Same for sparse arrays. On 2016/08/18 at 13:49:56, Jakob wrote: > Installing getters transitions the array's elements to a dictionary backing store anyway, so this is really the same as the test above. I realize that, but if in the future we do decide to serialize the former densely regardless of the input's ElementsKind (it would be entirely reasonable to, considering the array is dense even if it takes some time to make certain of that), I'd like to keep the test coverage.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_presubmit on master.tryserver.v8 (JOB_FAILED, no build URL)
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Yup, same page. LGTM. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc File src/value-serializer.cc (right): https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:298: // the format currently does not provide for properly distinguishing between On 2016/08/18 15:03:03, jbroman wrote: > Sparse serialization is currently used for such cases. Yes, I know. I meant my review comment as considerations for putting a more accurate comment into the source (sorry, I should have been clearer about that). I'd write something like: // To keep things simple, we decide between dense and sparse serialization // format based on elements kind: fast packed elements use the dense // format. A more advanced heuristic could determine the actual array // density by counting its elements. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:303: array->HasFastElements() && !array->HasFastHoleyElements(); On 2016/08/18 15:03:04, jbroman wrote: > A more principled heuristic would be used_elements >= length / 4 (because a > missing element takes one byte to encode but an explicit integer key takes 2-5 > bytes, say 3 typically, to encode). Yes, something like that. Doing that later (if at all) is fine. > Doing this, however, requires explicitly enumerating first the elements first > (in case some are non-enumerable). If there are no holes, it's pretty > convenient, because every element must be enumerable (IIUC, a non-enumerable > element would cause dictionary elements, and a hole would cause holey or > dictionary elements). Correct. (For the record: holey arrays can have holes, but no non-enumerable elements. Only dictionary elements can have the DONT_ENUM flag set.) > A proliferation of fast paths are possible. e.g., for fast holey elements, we > could use a bit vector to record where the holes are, and then if skip indices > that originally had holes; or if there are too many holes we can do a sparse > serialization, but still more efficiently than the slow path, except of course > it still has to have the escape hatch if a getter changes the backing store. You can't precompute/cache much, as everything can change. The bit vector idea, for that reason, doesn't make much sense to me. Also, comparing elements against the hole isn't any harder/slower than checking a bit vector's bits. > I don't have a good sense for what the typical elements kinds are in practice > (I'd expect that in practice most arrays likely to be serialized are fast > non-holey arrays, but I don't know). Hard to say, because that obviously depends a lot on the application. Arrays with HOLEY elements kinds but no actual holes are probably pretty common too. > This seemed like the quickest way of opting > most stuff into a reasonably fast path without yet going down the road of adding > various fast paths. Sadly, using the LookupIterator/GetProperty() for every element lookup is not particularly fast; but at least it's safe so it's a reasonable choice for this implementation. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:314: LookupIterator it(isolate_, array, i, array, LookupIterator::OWN); On 2016/08/18 15:03:04, jbroman wrote: > (Also, doesn't that require an additional check that it isn't > fast double elements; the elements aren't necessarily a FixedArray, right?) Yes. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:641: if (element->IsUndefined(isolate_)) continue; On 2016/08/18 15:03:03, jbroman wrote: > In fact I don't want to, but the existing wire format doesn't provide for > representing holes in the wire format. I intend to add a tag for a hole (as > distinct from undefined) in a future version of the wire format, but indeed > today if you postMessage([undefined,undefined], '*') in Chrome, you will get > [<hole>,<hole>] on the other side. I have to interpret undefined as either > undefined or a hole, so for consistency I've chosen the hole because Chrome does > so today. I'm aware of the wire format's limitation. I was just pointing out the inconsistency. If that's intentional, fine. https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... File test/unittests/value-serializer-unittest.cc (right): https://codereview.chromium.org/2259633002/diff/40001/test/unittests/value-se... test/unittests/value-serializer-unittest.cc:722: "(() => { var x = new Array(100000); x[5000] = 42; return x; })()", On 2016/08/18 15:03:04, jbroman wrote: > I thought I'd seen logic that used dictionary elements > for that case, but I must have misread. There may be remnants of that; 100K used to be the threshold. But since quite a while, V8 has been trusting developers more: if you allocate a "new Array(1e8)", you probably know what you're doing, and we'll give you a FAST_SMI_ELEMENTS backing store of the requested capacity.
Thank you for the thorough review. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc File src/value-serializer.cc (right): https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:298: // the format currently does not provide for properly distinguishing between On 2016/08/18 at 17:42:28, Jakob wrote: > On 2016/08/18 15:03:03, jbroman wrote: > > Sparse serialization is currently used for such cases. > > Yes, I know. > > I meant my review comment as considerations for putting a more accurate comment into the source (sorry, I should have been clearer about that). I'd write something like: > > // To keep things simple, we decide between dense and sparse serialization > // format based on elements kind: fast packed elements use the dense > // format. A more advanced heuristic could determine the actual array > // density by counting its elements. Reworded the comment to that effect, and expanded to add detail about what I was getting at with a bit vector below. https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:303: array->HasFastElements() && !array->HasFastHoleyElements(); On 2016/08/18 at 17:42:28, Jakob wrote: > On 2016/08/18 15:03:04, jbroman wrote: > > A more principled heuristic would be used_elements >= length / 4 (because a > > missing element takes one byte to encode but an explicit integer key takes 2-5 > > bytes, say 3 typically, to encode). > > Yes, something like that. Doing that later (if at all) is fine. > > > Doing this, however, requires explicitly enumerating first the elements first > > (in case some are non-enumerable). If there are no holes, it's pretty > > convenient, because every element must be enumerable (IIUC, a non-enumerable > > element would cause dictionary elements, and a hole would cause holey or > > dictionary elements). > > Correct. (For the record: holey arrays can have holes, but no non-enumerable elements. Only dictionary elements can have the DONT_ENUM flag set.) I've reworded the comment to (hopefully) be clearer on this point. What I meant was, indices occupied by holes would not be among the enumerable own property keys (and so those indices should not be serialized). > > A proliferation of fast paths are possible. e.g., for fast holey elements, we > > could use a bit vector to record where the holes are, and then if skip indices > > that originally had holes; or if there are too many holes we can do a sparse > > serialization, but still more efficiently than the slow path, except of course > > it still has to have the escape hatch if a getter changes the backing store. > > You can't precompute/cache much, as everything can change. The bit vector idea, for that reason, doesn't make much sense to me. Also, comparing elements against the hole isn't any harder/slower than checking a bit vector's bits. Except this thing _should_ be precomputed, per spec. Technically, the own property names (except for symbols) are enumerated before we begin serializing any elements. As a result, if a hole is filled in during serialization, that index should be skipped (at least, per spec and per Firefox's implementation; I doubt any web content actually relies on this). Definitely agreed that we have to be careful about precomputation. > > I don't have a good sense for what the typical elements kinds are in practice > > (I'd expect that in practice most arrays likely to be serialized are fast > > non-holey arrays, but I don't know). > > Hard to say, because that obviously depends a lot on the application. Arrays with HOLEY elements kinds but no actual holes are probably pretty common too. > > > This seemed like the quickest way of opting > > most stuff into a reasonably fast path without yet going down the road of adding > > various fast paths. > > Sadly, using the LookupIterator/GetProperty() for every element lookup is not particularly fast; but at least it's safe so it's a reasonable choice for this implementation. It's still faster than what Blink is doing today. :) https://codereview.chromium.org/2259633002/diff/40001/src/value-serializer.cc... src/value-serializer.cc:641: if (element->IsUndefined(isolate_)) continue; On 2016/08/18 at 17:42:28, Jakob wrote: > On 2016/08/18 15:03:03, jbroman wrote: > > In fact I don't want to, but the existing wire format doesn't provide for > > representing holes in the wire format. I intend to add a tag for a hole (as > > distinct from undefined) in a future version of the wire format, but indeed > > today if you postMessage([undefined,undefined], '*') in Chrome, you will get > > [<hole>,<hole>] on the other side. I have to interpret undefined as either > > undefined or a hole, so for consistency I've chosen the hole because Chrome does > > so today. > > I'm aware of the wire format's limitation. I was just pointing out the inconsistency. If that's intentional, fine. It's unfortunate but intentional, yes.
The CQ bit was checked by jbroman@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from jkummerow@chromium.org Link to the patchset: https://codereview.chromium.org/2259633002/#ps100001 (title: "further review comments")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== 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 ========== to ========== 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} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/2e000127df2e88e31d352ef70af397741d1f2298 Cr-Commit-Position: refs/heads/master@{#38729}
Message was sent while issue was closed.
A revert of this CL (patchset #6 id:100001) has been created in https://codereview.chromium.org/2255313002/ by jbroman@chromium.org. The reason for reverting is: Broke MIPS compile due to an uninitialization warning: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder....
The CQ bit was checked by jbroman@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by jbroman@chromium.org
Going to reland with the (trivial) fix.
The patchset sent to the CQ was uploaded after l-g-t-m from jkummerow@chromium.org Link to the patchset: https://codereview.chromium.org/2259633002/#ps120001 (title: "trivial fix for compiler initialization warning")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #7 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== 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} ========== to ========== 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 Committed: https://crrev.com/2d3a53c9c813173080eaab45141aaf80cd07f052 Cr-Original-Commit-Position: refs/heads/master@{#38729} Cr-Commit-Position: refs/heads/master@{#38732} ==========
Message was sent while issue was closed.
Patchset 7 (id:??) landed as https://crrev.com/2d3a53c9c813173080eaab45141aaf80cd07f052 Cr-Commit-Position: refs/heads/master@{#38732} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
