1487327 - Opt-in mechanism for experimental struct types and other ref functionality

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, enhancement, P2)

Description

[Lars T Hansen [:lth]]

While we are experimenting with the GC types (and for that matter the ref types, though they seem more stable) it may be useful to have an opt-in mechanism so that breaking changes can advertise themselves to any existing content.

For example, we could have an opt-in instruction "ref.opt_in <version>" where <version> is a constant that states the version of the proposal that we're opting in to.  This would either have the effect of setting a flag on the module's tls that says we've opted in to the <version>'s semantics, or, if those semantics are not supported, it traps.

For another example, we could have a custom section containing the version preceding the first appearance of any gc/ref related work that says that the module is opting in to the version in question, this would allow not just semantic changes but also changes in available opcodes and their layout.  (The section could be "custom" in the traditional sense with an ID=0 and a distinguished name, eg, "GCProposalOptIn", or it could be "custom" in the sense that we temporarily or permanently allocate a new section ID to it; the bikeshedding potential is significant.  There's a tie-in here to the "feature detection" debate too.)

Once we reach 1.0 for refs/gc we'd presumably no longer require the section, or the instruction.

I'm inclined to think that a section is better, since it is more flexible.

Comment 1

[Lars T Hansen [:lth]]

Luke, how do you feel about going with a custom-section idea as outlined above while we're experimenting?  Low cost, high yield, and if we allocate a new section ID it'll instantly make content not runnable in other implementations.  Also, it neatly solves at least part of bug 1487329, which is a short-term issue.

Comment 2

[Luke Wagner [:luke]]

I agree with your reasoning; a custom section (perhaps required to be the very first of the module) seems like a nice reliable way to solve the baseline-only / no-stack-maps problem and get a usable prototype.

And just to confirm: the gate for GC is (#ifdef NIGHTLY and custom section), no pref / env-var?

Comment 3

[Lars T Hansen [:lth]]

Yes, the eventual goal is to have just the #ifdef to enable the feature and then the custom section to activate it.

Comment 4

[Lars T Hansen [:lth]]

Attachment: bug1487327-custom-section-opt-in.patch

The bulk of this patch is just changes to test cases.  See commit msg for much more information.

The new section's textual name is "gc_feature_opt_in".  This is unwieldy but impossible to mistake and not an actual hardship so I decided not to futz with it; "gcfeature" is prettier but so what?  Opinions welcome.

As noted in a comment the documentation for the various versions will be hosted on https://github.com/lars-t-hansen/moz-gc-experiments for the time being.

Comment 5

[Lars T Hansen [:lth]]

BTW the motivation for the naming change from "gcTypesEnabled" to "gcTypesConfigured" in some spots is to separate the value of the --wasm-gc flag (now uniformly "gcTypesConfigured") from the computed value that denotes whether the GC feature is enabled during a compilation (everywhere "gcTypesEnabled").  The flag that denotes the presence of the opt-in section is called "gcFeatureOptIn".  This confusion will be reduced once the --wasm-gc flag disappears.

Comment 6

[Luke Wagner [:luke]]

Comment on attachment 9005589 [details] [diff] [review]
bug1487327-custom-section-opt-in.patch

Review of attachment 9005589 [details] [diff] [review]:
-----------------------------------------------------------------

Nice and clean, thanks.  So if someone (external) wants to experiment with this, I guess their best best is to build SM and use wasmTextToBinary()?

Comment 7

[Lars T Hansen [:lth]]

(In reply to Luke Wagner [:luke] from comment #6)
> Comment on attachment 9005589 [details] [diff] [review]
> bug1487327-custom-section-opt-in.patch
> 
> Review of attachment 9005589 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> So if someone (external) wants to experiment with
> this, I guess their best best is to build SM and use wasmTextToBinary()?

For simple experiments, yes.  Otherwise they'd want to emit their own binary wasm, in which case it's easy to emit this is as a preamble.  (Wabt and binaryen won't work anyway, as they have no support for ref types and structs and the new instructions - a much larger job.)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c91d997687bf
Custom section for opting in to GC feature work.  r=luke

Comment 9

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/c91d997687bf

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for breaking beta (see bug 1488395):

https://hg.mozilla.org/mozilla-central/rev/034c5ef24e98b0ce85fa849face079f568eb397c

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e99f9ea18046
Custom section for opting in to GC feature work.  r=luke

Comment 13

[Lars T Hansen [:lth]]

Resubmitted with tests for test cases that broke.

Comment 14

[Tiberius Oros[:tiberius_oros]]

https://hg.mozilla.org/mozilla-central/rev/e99f9ea18046