4 ms·

Could someone help me understand the logic behind this project? Actionscript runs in a VM, that's native code. It seems like Mozilla's argument is that the AS

Could someone help me understand the logic behind this project? Actionscript runs in a VM, that's native code. It seems like Mozilla's argument is that the AS VM is buggy and, thus, is/was/could be exploited often, so it's a security liability. Their solution to this problem (as far as I understood) is to interprete the SWF bytecode using JavaScript/HTML5, because JavaScript runs in a sandbox. Isn't anyone concerned that this is not the best solution to the problem? What's the difference between bugs in the AS VM and bugs in the JS VM? The JS VM is native code too, I don't see anyone rushing to replace it. If the JS VM is more mature, then this is just a matter of getting the AS VM to that maturity level. If someone wrote clang while gcc existed for many years, why can't Mozilla focus their efforts on writing a better AS VM, instead of writing an emulation layer? Given that both AS and JS are ECMAScripts, why can't AS be compiled in a way that allows it to run on the JS VMs? If the bytecode generated by the AS compiler doesn't match what a JS VM can execute, then, since the AS bytecode will necessarily mimic features available in the language (and the languages are similar), why can't we translate the AS bytecode into JS bytecode?

lucian1900 13y ago
It may be possible to translate Flash bytecode to JavaScript, but an interpreter will almost always be more accurate. In this particular case, being accurate first is important. Performance can be fixed later by adding a JIT-like mode.
- mbebenita 13y ago
  This is what Shumway does, it has both an Interpreter and a JIT.
pcwalton 13y ago
> If the bytecode generated by the AS compiler doesn't match what a JS VM can execute, then, since the AS bytecode will necessarily mimic features available in the language (and the languages are similar), why can't we translate the AS bytecode into JS bytecode? That's essentially what Shumway does. Unless things have significantly changed over the last year when I last looked at it, Shumway's AVM2 implementation is a JIT that compiles ActionScript to JavaScript (and thereby produces JS bytecode by going through "eval"). The tricky thing is that, because of extra features that ActionScript has that JS doesn't (namespaces, most notably) it has to speculate and recompile as needed to get good performance. So Shumway isn't an ahead-of-time static JIT, but it is a dynamically recompiling JIT.
AshleysBrain 13y ago
One possible advantage is it enables legacy Flash content to work on devices without Flash support like Android and iOS. Also I guess Mozilla would rather trust themselves with security than a third party with a pretty bad track record in that department.
mbebenita 13y ago
We do in fact translate AS (AVM2) bytecode into JS source. We can't target JS bytecode because we would like Shumway to run on every browser, not just Firefox. Maintaining one JS VM is a lot easier than dealing with two. Although it is fairly tricky to emulate AS features in JS, it's significantly easier than rewriting / maintaining a VM like Tamarin.

lucian1900 13y ago

It may be possible to translate Flash bytecode to JavaScript, but an interpreter will almost always be more accurate. In this particular case, being accurate first is important. Performance can be fixed later by adding a JIT-like mode.

mbebenita 13y ago
This is what Shumway does, it has both an Interpreter and a JIT.

pcwalton 13y ago

> If the bytecode generated by the AS compiler doesn't match what a JS VM can execute, then, since the AS bytecode will necessarily mimic features available in the language (and the languages are similar), why can't we translate the AS bytecode into JS bytecode? That's essentially what Shumway does. Unless things have significantly changed over the last year when I last looked at it, Shumway's AVM2 implementation is a JIT that compiles ActionScript to JavaScript (and thereby produces JS bytecode by going through "eval"). The tricky thing is that, because of extra features that ActionScript has that JS doesn't (namespaces, most notably) it has to speculate and recompile as needed to get good performance. So Shumway isn't an ahead-of-time static JIT, but it is a dynamically recompiling JIT.

AshleysBrain 13y ago

One possible advantage is it enables legacy Flash content to work on devices without Flash support like Android and iOS. Also I guess Mozilla would rather trust themselves with security than a third party with a pretty bad track record in that department.

mbebenita 13y ago

We do in fact translate AS (AVM2) bytecode into JS source. We can't target JS bytecode because we would like Shumway to run on every browser, not just Firefox. Maintaining one JS VM is a lot easier than dealing with two. Although it is fairly tricky to emulate AS features in JS, it's significantly easier than rewriting / maintaining a VM like Tamarin.