Feature Detection granularity

[mtrofin]

(I realize this may be too early to discuss at this point, but can't see harm in logging the issue.)

We are considering allowing modules express dependencies on platform features (see feature test).

In one extreme, if the features are too fine grained, and browsers (or more generally, WebAssembly targets) support different mix&matches of them, we end up with a fragmented ecosystem.

In another extreme, features are coarse grained and effectivelly match the standard's (WebAssembly) versions, avoiding extra fragmentation. In this case, it may be simpler for developers to have their modules express platform dependencies as "at least version x" rather than the current, more flexible, proposal.

SIMD suggests a mix may be appropriate - have version granularity with a very small set of optional, queryable capabilities.

What concrete scenarios do we have/envision that would help guide the discussion?

[lukewagner]

This is a good question and I'll give my current thinking but definitely open to hearing other points of view. I think the unit of has_feature should match the expected atomic unit of standardization+shipping and the guiding concern for the "right" unit of granularity should be enabling devs to write apps that are able to gracefully use features that aren't 100% ubiquitous in a similar manner to how they do this on the Web today.

Now, if we wanted to be symmetric with JS, we'd give each op/type/etc an associated feature string (defined automatically ∀ ops/types/etc). This is simple and definitely gives devs the power, but it seems to me that it would encourage implementation fragmentation: a coarser feature granularity would encourage vendors to implement an entire unit and thus promote convergence/portability of WebAssembly.

Thus, I think the choice of feature names should be explicit and ad hoc in the spec: each addition to the wasm spec post-v.1 would explicitly say what new feature-names it added to has_feature and partition the new ops/types/sections amount those feature-names.

Some examples:

• SIMD we'll likely want to break into incremental releases (e.g., with SIMD v.1 at parity with the current SIMD.js proposal). Thus, I think we'd have a simd1 feature that covered SIMD v.1, and then simd2 for the next incremental release, etc.
• In general, if we had a really big feature that had multiple orthogonally-useful and shippable components, we'd want to break it up into orthogonal sub-features. As an example, "service worker" would be too big for a single feature.
• We may end up with ops that are permanently optional (there is an example with mprotect in FeatureTest.md), so each one of those would get a feature.
• Some pieces of a feature might be controversial such that we'd want to break up this otherwise-atomic feature into the noncontroversial and controversial units. (Otherwise you could get into bad situations where two browsers both claimed to have "feature-name" but the actual implemented set differed.) We'd strive to avoid this, of course.

So, considering all this, my i32.min_s example in FeatureTest.md isn't realistic; it'd probably be part of a bigger feature set.

[jfbastien]

FWIW C++ does something similar: http://wg21.link/n3694

[mtrofin]

Since both the core set of features as well as orthogonal ones (like SIMD or service workers, to use @lukewagner 's example) may reasonably evolve independently, do we see any value in explicitly representing version numbers, or do we expect that be done by having the platform say it supports both "stringName_1" and "stringName_2" (e.g. "simd v1" and "simd v2" - 2 opaque strings).

It does seem like the core set of features should have a label, too (e.g. "WebAssembly v1" "WebAssembly v2" - where new opcodes are introduced, and I use them)

[lukewagner]

So one thing I just remembered is that there already is a way to test features without has_feature, and it's the same thing JS does for features that aren't simple property tests: try to eval some code and see if it fails. (In loader milestone 0, you "eval" via (ArrayBuffer -> Blob -> Object URL -> script.src); with milestone 1 there's a proper async API.)

Thinking about the question in this issue has made me realize that it is a rather serious and subjective task to define the right set and granularity of feature names and so it might be better to just punt and let people do it themselves. This puts slightly more pressure on convergence/portability, which I think is good.

If WebAssembly did one day get some permanently-optional feature (e.g., mprotect) then has_feature would make sense and engines could decode the operator even if they didn't support it (it would trap if called). But that is quite a different use case, the set of feature names would be much smaller, and empty for the MVP.

(Technically in C++ you can do this (and autconf et al do), but it's more of a bear and harder to abstract into a simple reusable library.)

Thoughts?

[jfbastien]

@lukewagner Are you suggesting we just remove has_feature for now?

[kg]

So one thing I just remembered is that there already is a way to test features without has_feature, and it's the same thing JS does for features that aren't simple property tests: try to eval some code and see if it fails. (In loader milestone 0, you "eval" via (ArrayBuffer -> Blob -> Object URL -> script.src); with milestone 1 there's a proper async API.)

Do we actually want people to attempt to evaluate dozens of wasm modules on startup just to do feature tests? The cost/complexity profile of that seems significant compared to a JS if statement/eval statement.

It does make sense as a solution for cases where you only test for one or two features.

We have previously discussed various techniques here based on the opcode table - do we polyfill unsupported ops we encounter, or block the module entirely based on seeing them, or block invocations of functions that use the unsupported ops, etc.

Function-at-a-time feature testing instead of entire-module feature testing is likely a thing people will want, but I'm not sure it makes sense to scope into the MVP. has_feature is currently most useful for choosing a function pointer's value (or a code path to execute) based on feature detection at runtime, which will require some underlying support (i.e. being able to compile parts of a module that don't use an unsupported opcode).

It's important to remember that not every 'feature' will be a new opcode; in some cases a 'feature' may mean that a particular restriction on an opcode has been relaxed or that the engine is making a new guarantee you can rely on.

This issue seems more about managing sets of features. I think this issue can be deferred to an upper layer to define it's own feature sets based on calls to has_feature which should remain fine-grain.

I would encourage wasm implementations to work hard to minimize feature differences, and wasm might define these to coordinate work and to try and get implementations across these lines.

If the upper layers are defined by user defined code then this also needs to be able to be wasm and before compile-time calls to has_feature. Thus the upper layer will need to work without use of any optional compile-time features, but could make run-time calls to has_feature. This might impose some requirements on the design in this area.

[lukewagner]

@jfbastien I haven't yet fully decided what I think but maybe "yes"; I'm just pointing out an option that I forgot we had which makes has_feature feel less necessary.

Do we actually want people to attempt to evaluate dozens of wasm modules on startup just to do
feature tests? The cost/complexity profile of that seems significant compared to a JS if
statement/eval statement.

Maybe it will be expensive, but maybe not; we can't yet confidently make this claim or know that people are going to want to independently test 40 features. As of the MVP, there would be zero feature tests, so we wouldn't have this problem for at least a few years :)

[dschuff]

Saying that "autoconf does this" doesn't really make me want to do it :)

On Fri, Oct 16, 2015 at 3:09 PM Katelyn Gadd notifications@github.com
wrote:

So one thing I just remembered is that there already is a way to test
features without has_feature, and it's the same thing JS does for features
that aren't simple property tests: try to eval some code and see if it
fails. (In loader milestone 0, you "eval" via (ArrayBuffer -> Blob ->
Object URL -> script.src); with milestone 1 there's a proper async API.)

Do we actually want people to attempt to evaluate dozens of wasm modules
on startup just to do feature tests? The cost/complexity profile of that
seems significant compared to a JS if statement/eval statement.

This. Even aside from the cost, it seems really hacky to me. And if the
eval does fail, you might not even know why.

It's important to remember that not every 'feature' will be a new opcode;
in some cases a 'feature' may mean that a particular restriction on an
opcode has been relaxed or that the engine is making a new guarantee you
can rely on.

This is a really good point. In particular the very last possibility. If a
feature is just a new guarantee then the 'eval' trick will not work at all
because the module will load just fine, and might even run, and possibly
with not-obviously-wrong behavior.

[mtrofin]

About eval: do we expect a JavaScript execution environment to be always available wherever WebAssembly is, or do we envision WebAssembly stand-alone deployment scenarios, too? (I'm assuming "eval" refers to the JavaScript eval. Or maybe I'm missing something.)

[jfbastien]

Standalone as well, see NonWeb. That section does need improvement (PRs welcome!).

[titzer]

I echo the sentiment here that we should probably avoid a situation forcing
eval of lots of little modules to do feature detection. What we really want
is some sort of cheap way to detect if a function or section is a "valid"
section and then take steps if it is not valid. Those steps could be
declarative (e.g. use this function body for this function if this feature
is supported) or dynamic (e.g. try validating this bytecode, and if it
works, then use it, otherwise generate some other bytecode). There is
probably a graduation of things in the last category that we could explore.

On Fri, Oct 16, 2015 at 10:04 PM, JF Bastien notifications@github.com
wrote:

Standalone as well, see NonWeb
https://github.com/WebAssembly/design/blob/master/NonWeb.md. That
section does need improvement (PRs welcome!).

—
Reply to this email directly or view it on GitHub
#416 (comment).

[mtrofin]

Is there a strong reason to have this second "try validating if it works" model? I'm asking if there is a scenario where the declarative ("has_feature") model wouldn't be sufficient for what developers would want to express, and they'd benefit from this second one.

I don't understand the 'eval of lots of little modules to do feature detection' proposal? WASM appears to have no requirement to even support eval, so how would this even be possible.

@titzer Are you suggesting avoiding fine-grain features, or avoiding supporting 'eval'?

If has_feature can only (or only efficiently) make block or function level choices then it is very limited. It should be possible to make lots of fine-grain code changes based on a feature and only a macro layer can do this effectively.

[binji]

@JSStats it's not really eval; they're talking about compiling a small WASM module that uses a feature/opcode that you want to test and checking whether it succeeds (similar to autoconf).