Intent to Ship: Resizable ArrayBuffer and growable SharedArrayBuffer

[Marja Hölttä]

Contact emails

ma...@chromium.org, s...@chromium.org

Explainer

https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md

Specification

https://tc39.es/proposal-resizablearraybuffer/

Summary

Extend the ArrayBuffer constructors to take an additional maximum length that allows in-place growth and shrinking of buffers. Similarly, SharedArrayBuffer is extended to take an additional maximum length that allows in-place growth.

Blink component

Blink>JavaScript>Language

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interop risk exists in that resizing and growing the backing store, as well as reserving the initial virtual memory, are platform and OS-dependent. To that end the spec draft recommends implementation guidelines: https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026) Assumed positive because this proposal is Stage 3 in TC39.

WebKit: Positive Assumed positive because this proposal is Stage 3 in TC39.

Web developers: No signals

Other signals: -

Security

ArrayBuffers and TypedArrays are a leading vector of attack. The feature has been designed to be implementable with a fixed data pointer to the backing store. See https://github.com/tc39/proposal-resizablearraybuffer#security The security review has been done by the V8 Security team.

WebView application risks

-

Debuggability

DevTools can already debug ArrayBuffers and SharedArrayBuffers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Tested by test262

Flag name

--harmony-rab-gsab

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=11111

Estimated milestones

M110

Anticipated spec changes

Included in the proposal's spec

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4668361878274048

This intent message was generated by Chrome Platform Status.

--

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian.

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Yoav Weiss]

On Fri, Nov 18, 2022 at 1:59 PM Marja Hölttä <ma...@chromium.org> wrote:

Contact emails

ma...@chromium.org, s...@chromium.org

Explainer

https://github.com/tc39/proposal-resizablearraybuffer/blob/master/README.md

Specification

https://tc39.es/proposal-resizablearraybuffer/

Summary

Extend the ArrayBuffer constructors to take an additional maximum length that allows in-place growth and shrinking of buffers. Similarly, SharedArrayBuffer is extended to take an additional maximum length that allows in-place growth.

Blink component

Blink>JavaScript>Language

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interop risk exists in that resizing and growing the backing store, as well as reserving the initial virtual memory, are platform and OS-dependent. To that end the spec draft recommends implementation guidelines: https://tc39.es/proposal-resizablearraybuffer/#sec-maxbytelength-guidelines

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1670026) Assumed positive because this proposal is Stage 3 in TC39.

WebKit: Positive Assumed positive because this proposal is Stage 3 in TC39.

Do you know what their shipping plans are? Otherwise, what's the backwards compat story? Is there feature detection for this new capability?

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAED6dUCUWtDVcF%3DvvLvZcC1ng2CDgtn0UufjjCCoj9kK9%2BqaOg%40mail.gmail.com.

[Marja Hölttä]

Other engines: At least Apple has started implementing this feature, but this is a big feature, so it'll take some time. We've pushed for test262 coverage, so hopefully getting the feature into production will take less time for them than it did for us.

Web sites can feature-detect this feature, e.g., by checking the existence of ArrayBuffer.prototype.resize and SharedArrayBuffer.prototype.grow.

The potential backwards compatibility problem is the names 'resize' and 'grow' colliding. This can always happen when adding new methods, although the risk here is lower than w/ adding methods to Array.prototype. Based on the past, we won't find out about such problems until we ship.

[Yoav Weiss]

LGTM1

On Tue, Nov 22, 2022 at 2:14 PM Marja Hölttä <ma...@chromium.org> wrote:

Other engines: At least Apple has started implementing this feature, but this is a big feature, so it'll take some time. We've pushed for test262 coverage, so hopefully getting the feature into production will take less time for them than it did for us.

Web sites can feature-detect this feature, e.g., by checking the existence of ArrayBuffer.prototype.resize and SharedArrayBuffer.prototype.grow.

The potential backwards compatibility problem is the names 'resize' and 'grow' colliding. This can always happen when adding new methods, although the risk here is lower than w/ adding methods to Array.prototype. Based on the past, we won't find out about such problems until we ship.

In case of such a collision, wouldn't the userland name win?

I guess we could run e.g. ClusterTelemetry with that change and see if the usecounters are hit (or something similar), just to be extra cautious.

[Marja Hölttä]

Thanks for the LGTM!

Re: "wouldn't the userland name win" - typically the situation is more complicated than that. E.g., one part of the user code marks objects by adding a property 'foo' and another part checks whether my_object.foo != undefined. If we now add 'foo' somewhere in the prototype chain, this logic breaks: it will think that an unmarked object is actually marked. -> Adding properties like this can break user code in arbitrary ways.

[Yoav Weiss]

On Tue, Nov 22, 2022 at 6:54 PM Marja Hölttä <ma...@chromium.org> wrote:

Thanks for the LGTM!

Re: "wouldn't the userland name win" - typically the situation is more complicated than that. E.g., one part of the user code marks objects by adding a property 'foo' and another part checks whether my_object.foo != undefined. If we now add 'foo' somewhere in the prototype chain, this logic breaks: it will think that an unmarked object is actually marked. -> Adding properties like this can break user code in arbitrary ways.

Yeah, makes sense! 

[Mike West]

LGTM2.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWRUYSV9WQAwUR%2BMPUkZW8aWR7xkzEjpz_%3DfMdsEwjkKw%40mail.gmail.com.

[Daniel Bratell]

LGTM3.

Also happy to see the technical term "super slow" get some use. :)

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeXPz1KZiS4vkK0a7r%2BvuKsJ%3DtzGneAuYY%2B2E%3DiZFgufw%40mail.gmail.com.