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

Normative: Allow Atomics methods on ArrayBuffers #1908

Open
wants to merge 3 commits into
base: master
from

Conversation

@syg
Copy link
Contributor

syg commented Mar 20, 2020

This is to align with wasm allowing atomics to work on non-shared memory.

Most methods work in the obvious deterministic way on ArrayBuffers, with the exceptions of:

  • Atomics.wait still throws on ArrayBuffers.
  • Atomics.notify always returns 0 on ArrayBuffers.
@syg syg requested a review from tc39/ecma262-editors Mar 20, 2020
spec.html Outdated Show resolved Hide resolved
spec.html Show resolved Hide resolved
spec.html Outdated
@@ -37657,7 +37657,6 @@ <h1>ValidateSharedIntegerTypedArray ( _typedArray_ [ , _waitable_ ] )</h1>
1. If ! IsUnclampedIntegerElementType(_type_) is *false* and ! IsBigIntElementType(_type_) is *false*, throw a *TypeError* exception.
1. Assert: _typedArray_ has a [[ViewedArrayBuffer]] internal slot.
1. Let _buffer_ be _typedArray_.[[ViewedArrayBuffer]].
1. If IsSharedArrayBuffer(_buffer_) is *false*, throw a *TypeError* exception.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 21, 2020

Member

this part is normative, but not part of the rename; can it be separated into its own commit?

This comment has been minimized.

Copy link
@syg

syg Mar 23, 2020

Author Contributor

Preferably not because the rename would be misleading without changing this line. The only reason it's renamed is because the AO now applies to all TypedArrays, not just SAB-backed ones.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 24, 2020

Member

Sure, but the new name isn't wrong even if it only applies to shared array buffers.

This comment has been minimized.

Copy link
@syg

syg Mar 24, 2020

Author Contributor

I don't understand why I would land a renaming PR that is less clear, separately.

Like I said, I wouldn't rename this at all without the normative change. And since there's no mechanical advantage to having a separate commit here I would not split it.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 24, 2020

Member

right, but it makes the commit separable, even if it's in the same PR. iow, this commit is normative, not editorial, as it's currently labelled.

(iow, you do have a separate commit here, labelled editorial, so if there's no mechanical advantage, why would you have the commit be separate?)

This comment has been minimized.

Copy link
@syg

syg Mar 24, 2020

Author Contributor

Are you saying you'd prefer that if this were a separate commit at all, if that separate commit must be normative, it should just be folded into the other one? That's fine with me. It ended up being a separate commit because it was a logical chunk of work.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 25, 2020

Member

mainly just that i'd prefer individual commits be atomic and labelled properly; if the intention is to fold them all up, then it doesn't matter.

spec.html Outdated Show resolved Hide resolved
@syg syg force-pushed the syg:atomics-on-abs branch from c165167 to 94a146d Mar 23, 2020
@syg

This comment has been minimized.

Copy link
Contributor Author

syg commented Mar 23, 2020

Addressed review and rebased.

syg added 3 commits Mar 20, 2020
Refactor semantic functions as used by atomic RMW operations to be
a subclass of abstract closures that are pure.

The remaining use of "semantic function" for reads-bytes-from is
changed to say "mathematical function". It is used in the axiomatic
event semantics and do not have algorithm steps.
Allow Atomics methods to work on ArrayBuffers in a fully deterministic
fashion. Atomics.wait still throws when used on ArrayBuffers, while
Atomics.notify always returns 0.
@syg syg force-pushed the syg:atomics-on-abs branch from 94a146d to 67e63a5 Mar 25, 2020
@rwaldron

This comment has been minimized.

Copy link
Contributor

rwaldron commented Mar 31, 2020

@syg I'm going to add this to the end of the priority testing queue

@rwaldron rwaldron mentioned this pull request Mar 31, 2020
0 of 12 tasks complete
@syg

This comment has been minimized.

Copy link
Contributor Author

syg commented Mar 31, 2020

@erights raised the following good question: "Are different optimization allowed between a single-agent program that uses Atomics on a non-shared SAB and a single-agent program that uses Atomics on an AB?"

If one takes different optimizations to mean different observable behavior, then the answer is no. On paper, since Atomics on ABs do not introduce SeqCst events (or, indeed, any events), an implementation is allowed to do things to Atomics on ABs that it's not allowed to do to Atomics on SABs, like coalesce writes, reorder them, etc. But it's only allowed to do that if it can prove that such changes are non-observable inside that single agent. SABs need extra guidance because observability is extended to the agent cluster -- proving single agent (non-)observability is insufficient.

However, if one takes different optimizations to mean can different codegen be observed by something outside of the spec's normative control like devtools, then the answer is yes. This is something the spec does not legislate anyhow.

In practice, I reckon the answer to both interpretations above is no. I see no reason why compiler authors would go the length of writing optimizations for Atomics used on ABs instead of reusing the same optimizations as Atomics used on SABs.

Cc @tlively and @lars-t-hansen for thoughts from the wasm side.

@tlively

This comment has been minimized.

Copy link

tlively commented Mar 31, 2020

I would expect different (semantics-preserving) optimizations to be allowed for the reasons you mention. I assume doing going out of the way to do extra optimizations of unshared atomic operations would be low priority for implementors since that is a rather niche situation. On the other hand, it might not be difficult to arrange for a compiler to notice that the atomics are not shared early in the pipeline and lower them to nonatomic operations that can subsequently be optimized using the same code paths as normal reads and writes.

@erights

This comment has been minimized.

Copy link

erights commented Apr 1, 2020

To be clear, I was asking, not advocating. If the observable behavior is already equivalent, then we're done.

I do not think that the spec for AB should be loosened in any way, to enable optimizations that we're not currently doing for AB. Such equivalence of allowed behavior is not attractive to me, even if everyone else were happy with it.

Let me ask a different question: If the allowed behavior is not equivalent: Is the allowed observable behavior on AB a subset of the allowed observable behavior on SAB? If not, I'd like to understand the difference. Until I do understand the difference, I'm still not yet advocating that anything be changed.

@syg

This comment has been minimized.

Copy link
Contributor Author

syg commented Apr 1, 2020

Let me ask a different question: If the allowed behavior is not equivalent: Is the allowed observable behavior on AB a subset of the allowed observable behavior on SAB? If not, I'd like to understand the difference.

The allowed observable single-thread behavior of AB and the allowed observable behavior of non-shared SAB are the same. What differs is what codegen is allowed, but since there are no concurrent ways to observe the SAB since it's non-shared, the differently generated code have the same observable behavior.

The only way you might observe a difference is a non-normative host-implemented observation utility like a debugger.

tl;dr The observable behavior is already equivalent given how people currently understand how to optimize single-threaded JS, so I think we're done.

@lars-t-hansen

This comment has been minimized.

Copy link
Contributor

lars-t-hansen commented Apr 2, 2020

I would expect different (semantics-preserving) optimizations to be allowed for the reasons you mention. I assume doing going out of the way to do extra optimizations of unshared atomic operations would be low priority for implementors since that is a rather niche situation. On the other hand, it might not be difficult to arrange for a compiler to notice that the atomics are not shared early in the pipeline and lower them to nonatomic operations that can subsequently be optimized using the same code paths as normal reads and writes.

I agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.