Normative: make SharedArrayBuffer optional

[bakkot]

See #1435.

We could do the whole host hook song and dance, but that seems like overkill.

This PR takes the approach of making the SharedArrayBuffer property of the global object optional for hosts which do not provide concurrent access to SAB objects. There's no other way of getting a SharedArrayBuffer object (in this spec, certainly), so I think that's sufficient.

cc @erights @annevk @syg

Closes #1435.

[devsnek]

I think there's a test in test262 somewhere that asserts the properties of the global object which would need to be updated.

[syg]

Is there? I don't think test262 needs updates. A quick grep shows all the tests that use SharedArrayBuffer has features: [SharedArrayBuffer].

[devsnek]

Ah you're right, the test is not exhaustive (https://github.com/tc39/test262/blob/master/test/built-ins/global/global-object.js)

[erights]

LGTM (though of course I am not an editor)

[annevk]

I've always thought of HTML (or the browser) as a single host. Is the idea instead that each agent cluster instantiating thing is a host? So if you have inter-agent-cluster communication you really have inter-host communication? Seems confusing.

This is a roundabout way of saying that HTML will only sometimes not expose the constructor. The note might also be confusing as there still will be ways to get at a SharedArrayBuffer instance through Wasm.

[erights]

The note might also be confusing as there still will be ways to get at a SharedArrayBuffer instance through Wasm.

Good point! The same issue applies to wasm. Those doing wasm on blockchain have already stated, independently but for exactly the same reason, that wasm on blockchain will not support shared state concurrency. Therefore SharedArrayBuffer is meaningless to wasm in those environments too.

I would also expect that browser contexts that deny shared-state concurrency to JS would also deny it to wasm. But I'll let y'all speak for browser.

[syg]

This is a roundabout way of saying that HTML will only sometimes not expose the constructor. The note might also be confusing as there still will be ways to get at a SharedArrayBuffer instance through Wasm.

Hm, I figured how it talks about concurrent access vs the constructor would avoid that confusion. What's the confusion exactly?

I would also expect that browser contexts that deny shared-state concurrency to JS would also deny it to wasm. But I'll let y'all speak for browser.

@erights To clarify, the current proposal is that without opting in to cross-origin isolation, you can't postMessage SABs. On top of that, the SharedArrayBuffer constructor would be omitted without opt-in for back compat reasons, because there's feature detection code that conflates "can I construct a SAB" with "can I share a SAB". Wasm doesn't have that back compat baggage, so there's no reason to disallow construction of shared wasm memories. Sharing SABs via postMessage is still disallowed without opting in to cross-origin isolation.

[annevk]

What's a host? If HTML / browsers are a reasonable host, they do allow threaded access, but conditionally. Allowing hosts to delete the constructor if circumstances warrant it seems more appropriate. (As for the confusion, e.g., Mark above who is equating SAB access with threaded access.)

[syg]

What's a host? If HTML / browsers are a reasonable host [...]

I'm now convinced that it is important editorially to distinguish hosts and implementations, even if ecma262 has no "use" for distinguishing them.

I want the norm to be that when a reader reads host, the instinct is to assume an upstream specification specifies the behavior. A host may have its own implementations, and those implementations must conform to what the host says.

An implementation is any implementation of ecma262 in itself (which wouldn't be very useful) or of a host that uses ecma262. I want the norm to be that when a reader reads implementation, the instinct is to assume "any program that executes JS may behave differently here".

So the high-order bit editorially is to use the terms to convey a sense of "how likely is interop". If something is defined in ecma262, all conformant implementations of JS interop (e.g., all browsers, node, and XS's embedded environment). If something is host-defined, all conformant implementations to that host interop (e.g. all browsers). If something is implementation-defined, there may be no interop.

[syg]

@annevk I'm confused, is your objection that the "hosts" language is confusing in this PR? To me the current version reads like what you want: that HTML is a host, and any host is able to omit on the condition of providing or not providing concurrent access. Or is the confusion perhaps that providing concurrent access is a dynamic property, and not a host property?

[ljharb]

If something is host-defined, all conformant implementations to that host interop (e.g. all browsers).

To me, this seems like a guarantee you don't actually have, unless the host has a spec that mandates it - iow, you have the same "If something is implementation-defined, there may be no interop." guarantee unless you go read another document (the HTML spec, in this case). I'm still not seeing the difference between the two terms.

[syg]

That's why it's an editorial, not normative, and I worded it as "likelihood". Lack of an airtight guarantee doesn't mean that it's not a useful signal to give to readers.

[ljharb]

I'm skeptical that an unreliable signal is useful.

[allenwb]

for symmetry, my thoughts here #1524 (comment)

@syg What would you say for situations where there is no host (or a host does not deal with a specific requirement). It is certainly possible to build an ES engine that directly interfaces ES programs to an operating system much like, C or Lisp or even Java.

[syg]

I'm skeptical that an unreliable signal is useful.

It's only unreliable theoretically. In practice, I mean, a lot of the readers of the spec work on browsers so it's a good signal for them to go read the HTML spec.

@syg What would you say for situations where there is no host (or a host does not deal with a specific requirement). It is certainly possible to build an ES engine that directly interfaces ES programs to an operating system much like, C or Lisp or even Java.

Oh certainly! I say that's the degenerate case when host and implementation are not distinguished in practice. Look, I'm not arguing guarantees -- I agree we can't guarantee anything materially different between hosts and implementations. I'm saying that as a reader of the spec who is trying to implement stuff, I know what host I'm working on. If it's the web, it's useful for me to know if something is delegated to the HTML spec (like module loading), or is in fact delegated to the JS engine (like exponentiation). If it's a direct-to-OS implementation, I know I don't need to care about that difference.

[allenwb]

I'm saying that as a reader of the spec who is trying to implement stuff, I know what host I'm working on. If it's the web, it's useful for me to know if something is delegated to the HTML spec (like module loading), or is in fact delegated to the JS engine (like exponentiation).

And if you are providing an ES scripting engine for a spreadsheet what do you usefully know when ECMA-262 says "host-defined"

When the Web platform makes specific requirements upon an integrated ECMAScript implementation it seems appropriate for there to be a Web platform document that specifies what
the Web platform requires such an ES implementation to do for each place (that the platform cares about) in the ES spec that says something is implementation defined.

[syg]

And if you are providing an ES scripting engine for a spreadsheet what do you usefully know when ECMA-262 says "host-defined"

That depends on if that spreadsheet application has its own spec or doesn't. Why is this hypothetical useful to discuss? As an editor, I am interested in serving the readers of today over the readers of tomorrow, unless doing the former somehow harms the latter. One subgroup of the readers of today have repeatedly said they find the distinction useful.

Edit: I am speaking above as a single editor, and not representative of the current editor group. I imagine we'll discuss this at the next editor meeting.

When the Web platform makes specific requirements upon an integrated ECMAScript implementation it seems appropriate for there to be a Web platform document that specifies what
the Web platform requires such an ES implementation to do for each place (that the platform cares about) in the ES spec that says something is implementation defined.

Again, I'm talking about editorial distinction to signal where to look next for the requirements not present in ecma262. I am quite bemused that this is controversial. The web platform does document and will continue to document.

[bakkot]

Not relevant to the above discussion:

Apparently in the web platform it is still possible to get a hold of the SharedArrayBuffer constructor by doing new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor, so this PR needs to be reworded slightly to make it more explicit that the change permitted of hosts is specifically omitting the SharedArrayBuffer property of the global object.

[ljharb]

I'm confused; if it's still possible to get the constructor in JS on the web, of what benefit is hiding the global property on the web? Is it just to discourage casual usage, and/or to allow feature detection?

[annevk]

It's a web compatibility concern. People assuming that postMessage() works if the constructor is there. (I mentioned this in #1903 (comment) btw and in many other places. Shu did as well.)

[bakkot]

I've reworded this PR so that it now talks about omitting the SharedArrayBuffer property of the global object, rather than omitting the constructor itself.

[annevk]

HTML violates this, right? It's a single host that does allow concurrent access to SAB objects. It does vary between its agent clusters, but they're all part of the same host.

[bakkot]

The way I was looking at it was that HTML only sometimes provides concurrent access to SAB objects. In the cases where it does provide concurrent it must include the SharedArrayBuffer global, and in the cases where it does not provide concurrent access it may omit it.

Would it help to say "whenever" rather than "if"?

[annevk]

Can we make it explicit and say "If a host does not provide concurrent access to SAB objects within an agent cluster, ..."?

Although even then we might not want to consistently hide it within the entire cluster. We decided to do that for now, but I personally would like to keep the door open to still exposing it in worklets and workers and eventually everywhere again (it's clear that everywhere is allowed though). But perhaps the "may" is good enough for that.

[syg]

I think @annevk's point is valid, and I also think "whenever" + "may" suffices to convey enough latitude without extra wording about where exactly that property may be not present.

[bakkot]

Changed to "whenever".

[syg]

lgtm with change of "If" -> "Whenever"

[syg]

I think @annevk's point is valid, and I also think "whenever" + "may" suffices to convey enough latitude without extra wording about where exactly that property may be not present.