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

RESOLVED FIXED in Firefox 64

Status

()

enhancement
P2
normal
RESOLVED FIXED
10 months ago
10 months ago

People

(Reporter: lth, Assigned: lth)

Tracking

unspecified
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

10 months ago
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.
Assignee

Updated

10 months ago
Blocks: 1487329
Assignee

Comment 1

10 months ago
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.
Flags: needinfo?(luke)

Comment 2

10 months ago
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?
Flags: needinfo?(luke)
Assignee

Comment 3

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

Comment 4

10 months ago
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.
Assignee: nobody → lhansen
Status: NEW → ASSIGNED
Attachment #9005589 - Flags: review?(luke)
Assignee

Comment 5

10 months ago
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

10 months ago
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()?
Attachment #9005589 - Flags: review?(luke) → review+
Assignee

Comment 7

10 months ago
(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

10 months ago
Pushed by lhansen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c91d997687bf
Custom section for opting in to GC feature work.  r=luke

Comment 9

10 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c91d997687bf
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Backed out for breaking beta (see bug 1488395):

https://hg.mozilla.org/mozilla-central/rev/034c5ef24e98b0ce85fa849face079f568eb397c
Status: RESOLVED → REOPENED
Flags: needinfo?(lhansen)
Resolution: FIXED → ---
Target Milestone: mozilla63 → ---

Comment 11

10 months ago
Pushed by lhansen@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e99f9ea18046
Custom section for opting in to GC feature work.  r=luke
Assignee

Updated

10 months ago
Duplicate of this bug: 1488395
Assignee

Comment 13

10 months ago
Resubmitted with tests for test cases that broke.
Flags: needinfo?(lhansen)

Comment 14

10 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e99f9ea18046
Status: REOPENED → RESOLVED
Closed: 10 months ago10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.