Remove memory resizing from the MVP

[kripken]

Followup to #285, #288.

The docs currently say that memory can be resized in the MVP. But as mentioned in those issues, we know that memory resizing in asm.js is not fast on Chrome and Safari.

Since we want the MVP to contain things that polyfill, and polyfill well, to JS, it makes sense to remove memory resizing, same as we did to some other existing things in asm.js. After the MVP, we are moving to things that diverge and cannot be polyfilled, and memory resizing makes more sense to add at that point in time.

The discussion in the prior issues appears to have ended with @lukewagner asking for further clarification from @titzer and @pizlonator about the performance of asm.js memory resizing in their respective browsers.

[jfbastien]

We should solve this issue (moving resizing out of MVP) by also figuring out how heap size is specified in MVP.

[kripken]

Do you have anything in mind for that? A few obvious options seem to be

1. A bss in the data segment. Basically declares zero-initialized area, and with that the data segment would define the entire size of memory.
2. A method that must be called during startup, before memory is touched, giveMeThisMuchMemoryPlease(..).

[MikeHolman]

IMO memory issues were kind of a big deal for asm.js usability, and I really don't like the idea of punting on resizable memory for MVP, since the capability is already there to alleviate this. I especially don't like doing this without a compelling reason. And relegating this to a future feature due to a couple perf bugs that we have at least half a year to fix (that I admittedly don't know the exact complexity of) is pretty disappointing.

[kg]

Heap re-sizing is important for a bunch of scenarios so I also don't like the idea of punting on it for the MVP. I'd be okay with an approach that constrains it somehow if that will make it possible for it to run well in Chrome and Safari, but I'd rather we make applications run great in the mid-term even if it means JS engines have to adapt a bit.

I think it's plausible that the necessary JS work could happen to make the polyfill work well in resize scenarios before we'd actually get to it if we punt. The polyfill will also be in use for the forseeable future, so either way this feature will need to work right in native JS. The fact that re-sizing is also a desirable feature for emscripten/asm.js can help motivate JS engine teams to deliver it so we can use it.

[kripken]

I agree memory resizing is important. Hopefully @titzer and @pizlonator can provide information on the current slowdown and status of plans to remedy that.

But unless things have improved since last we heard, the slowdowns are significant, and we've known about them for quite some time now. Emscripten has not turned memory resizing on by default because of them.

I think it's also important to mention that asm.js without memory resizing is still very useful. It started without it, and was still fine for many games and applications.

[qwertie]

Possible compromises:

1. Limit the difference between "min" and "max" memory size to be a factor of two, then have the polyfill will always allocate the "max". The factor-of-two limit ensures that the polyfill doesn't overallocate in an extreme way.
2. Define a flag that means "allocate max memory size if necessary for performance". If the flag is on, then the polyfill preallocates the max if it helps performance; if the flag is off then performance is not considered critical and the slowdown for dynamic resizing is allowed.
3. Have a third parameter besides min and max, which is a fixed size to use in case of polyfill. If this parameter is zero, the polyfill uses dynamic resizing at the risk of low performance.

[kripken]

@qwertie: all of those create large differences between the polyfill and the native implementation. I think our goal is to minimize or not even have any such differences at the MVP point in time.

[kripken]

Meanwhile I found the v8 bug. Status is still 'assigned'. I don't see a WebKit bug, might not be one filed.

[kripken]

Re-ping @titzer and @pizlonator for information on the state of asm.js heap resizing performance in their JITs.

[pizlonator]

Hi Alon,

Having looked at the ArrayBuffer.transfer ideas, which I understand to be the proposed mechanism for asm.js heap growth, I’ve decided that I don’t think that this is a good idea. It would require WebKit to recognize the “use asm” pragma, which I don’t really want to do, because it’s kind of ugly. Our existing optimizations for JavaScript happen to do the right thing for asm.js code without the pragma. But when you do ArrayBuffer.transfer, our monotonic approach to the the inference of constant variables causes us to believe that the HEAP variables are truly variables. I believe that it’s good for our inference to believe that a variable is not a constant when it is overwritten.

If you have some proposal for how to make memory resizing fast that doesn’t require recognizing “use asm” and still makes things run fast without breaking JavaScript optimizations, then we would be happy to consider it.

Anyway, it’s probably an oversight that there is no bugs.webkit.org http://bugs.webkit.org/ bug for this. You should file one! ;-)

-Filip

On Aug 20, 2015, at 3:56 PM, Alon Zakai notifications@github.com wrote:

Re-ping @titzer https://github.com/titzer and @pizlonator https://github.com/pizlonator for information on the state of asm.js heap resizing performance in their JITs.

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

[kripken]

Thanks for the info, I filed a bug.

Is the slowdown significant when memory growth makes the VM infer they are truly variables?

My position here is that if asm.js memory growth is inefficient on WebKit and Blink, then we might as well remove it from the MVP, as we'll have a proper memory resizing solution after the MVP that works for WebAssembly across all browsers. (And having it in the MVP, when it's slow in >50% of the market, just makes the MVP look bad.) It's a shame to remove it from the MVP, but in the long term, no big loss.

[lukewagner]

@pizlonator FWIW, asm.js heap resizing doesn't explicitly depend on ArrayBuffer.transfer which isn't even shipping in FF (it's locked to Nightly and will stay so unless it gets standardized). Without ArrayBuffer.transfer, Emscripten will just create a new ArrayBuffer, copy over the old one, and then call the asm.js change-heap function (gross, I know) to swap it in. This is roughly what Emscripten originally did for heap resizing before asm.js temporarily took away the ability.

But the main question wasn't whether JSC/V8 would add special asm.js optimizations for heap resizing but, rather, does the loss of the singleton property destroy performance so terribly that the polyfill wouldn't be viable.

We can just measure this, though. Alon, perhaps you could send me some benchmark builds w/ and w/o heap resizing? Also, if the only big problem is Turbo-asm mode and not CrankShaft or JSC, we can just do what Ben suggested and have "use asm 2" which stays in CrankShaft.

[pizlonator]

On Aug 20, 2015, at 5:02 PM, Alon Zakai notifications@github.com wrote:

Thanks for the info, I filed a bug https://bugs.webkit.org/show_bug.cgi?id=148267.

Is the slowdown significant when memory growth makes the VM infer they are truly variables?

I haven’t measured it, but I would assume it to be pretty bad.

My position here is that if asm.js memory growth is inefficient on WebKit and Blink, then we might as well remove it from the MVP, as we'll have a proper memory resizing solution after the MVP that works for WebAssembly across all browsers. (And having it in the MVP, when it's slow in >50% of the market, just makes the MVP look bad.) It's a shame to remove it from the MVP, but in the long term, no big loss.

Whether WebKit has fast asm.js heap resizing may be a moot point since our WebAssembly implementation is coming along swimmingly. Even if someone took action on the bug you filed, it seems unlikely that they would finish that any sooner than the WebAssembly implementation.

-Filip