Submitted by Asm.js deserves closer inspection for two reasons. First, it’s the one “native browser VM” that doesn’t massively reinvent wheels. Second, it’s the only time a browser vendor’s “next-gen JS” attempts have actually gotten everybody else to pay attention. But what are we transitioning into exactly?
And in a big ironic backslash, their website about Mozilla’s asm.js doesn’t work on my Firefox (I get a black screen).
Fix your shit. Works fine in Iceweasel here.
Same here.
The entire article and the future it paints makes me cringe. I just want to lift everyone involved in these ginormous hacks up and shake them around.
For chrissake think of what you’re doing. With web browsers and web technology moving so fast, we should settle on funneling the world’s languages into freaking JavaScript? Unbelievable.
Probably because JS has the most development behind it so its sandboxing is getting the most attention.
I’d prefer Rust in the long run, but what would you suggest, not the secure impossibility that is C?
Why not a kind of sandboxed C?
Most C code can be converted to Asm.js, effectively making sandboxed C.
Since asm.js is a limited subset of JS, they can be mapped more directly to machine code, so it all works out pretty well.
Yes, but would be nice to have a C or C++ API accessing to the DOM. Something like:
<script language=”c++11″>
int main()
{
std::string text = “hello world”;
getDocument().getElementById(“my_button”).setInnerHtml(text);
}
</script>
Sandboxing C isn’t as easy as sandboxing JS (which is obviously hard because there are still problems found from time to time).
Having only one language API to sandbox across all the browsers seems doable; having 3-5 browsers all sandboxing multiple languages doesn’t seem like it would work very well.
Compiling any language to the single language (in this case, a subset of Javascript called Asm.js) should be a pretty effective middle-ground for the next 5-10 years I think.
Now, your example could work and still be relatively safe if the browser compiled that C into Asm.js and then executed it via the same path as pre-compiled Asm.js…
But do you really want every browser to have a different compiler to convert your C code to Asm.js?
Can you imagine how differently each one would implement importing of libraries and accessing the DOM even? Also, tack on the compilation time for every single visitor to your site for every blurb of code, multiplied by every programming language.
It took 15 years for them to get to almost parity on regular javascript / ecmascript; multiply that per language that isn’t their only focus and see what happens.
I’d suggest to just use a pre-processor, like people already do for CSS (LESS / SASS), to convert any non-JS in your code to asm.js… Done
Edited 2014-10-29 20:49 UTC
intangible,
I strongly agree. I don’t think adding more languages one by one into browsers is wise. There will inevitably be spotty language support, different versions, different bugs, etc. I’d rather have a generic standardized VM well supported by all browsers which languages can compile into.
Yea, asm.js gives us this capability today. Google’s PNaCl does as well, and it gives us a far more direct path to “sandboxed native execution” than asm.js can, but who else is going to support it? While I think PNaCl may be the superior solution, I don’t believe the politics between apple/ms/google/mozilla/etc lend themselves to it’s success.
This is why my money’s on asm.js: cross-browser development will proceed without any cooperation amongst competing venders, which is really what’s holding us back more than anything else. The lack of vendor collaboration on native code sandboxing will result in asm.js being the defacto winner.
This was also kind of funny:
https://www.youtube.com/watch?v=tMEH9OMYmsQ
The part where he talks about how asm.js can be fasterr than native was kind of cool too.
Lennie,
I didn’t watch it completely yet but it’s definitely making me laugh!
Glad you are enjoying it.
Obviously with faster than native I meant:
Running an app in a Javascript VM in kernel space (ring 0) instead of userspace will save on context switches making it faster than the usual code running in userspace (ring 3).
I didn’t want to ruin the surprise.
Some people believe it is a fight between native and the web. This is an example of someone who talks about this:
https://www.youtube.com/watch?v=XzRBgj1AJYA
I do believe platforms like Apple and Windows are getting more closed. And Android isn’t truly open either.
Native will be first. But the web had already partly killed the desktop before the smartphone existed.
As hardware gets faster and more capable and the web gets good enough again in time, it could win again.
Edited 2014-11-01 19:35 UTC
Lennie,
I think he pulled those numbers out of thin air for the video, but I do agree that a kernel using VM isolation semantics rather than user-space/kernel-space isolation would be possible.
This is quite a deja vu for me, I had this discussion with Neolander here on osnews! We had such long discussions back then:
http://www.osnews.com/thread?461247
http://www.osnews.com/thread?461309
We sort of went into it more on his blog, along with lots of other ideas.
http://theosperiment.wordpress.com/2013/06/17/on-rpc-and-its-integr…
Back in 2011 I was pretty confident that a VM based isolation model would perform well for exactly the reasons you give: save on the context switching caused by IPC/scheduling. Of course in his entertaining fictitious style, John Corser’s talk focuses exclusively on Javascript as the VM, but Javascript is not central to the argument IMHO.
No, they are real numbers from Microsoft Research, I believe it was from: http://research.microsoft.com/en-us/projects/singularity/
Yes, an interesting discussion.
In his blog he talks about Ada and messages and as the first commenter mentioned, it makes me think of the Actor model and Erlang green threads-like solution.
In your comment you say: “I don’t know exactly why, but it’s much more prevalent in windows world”
The reason for this is Unix/Linux has always been about processes. And launching many processes in Windows has a lot of overhead/is slow.
Well, except for one thing. The programmers of the language are used to having their code run inside a VM without access to the filesystem. 🙂
And of course, no language has as many languages as it’s compile target:
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-tha…
Obviously there are other ways to get rid of the context switches:
– for long running calculations the Linux kernel can almost offer a completely dedicated CPU for a single process without any interruptions:
http://lwn.net/Articles/549580/
– running drivers in userspace for high performance (high interrupt) devices. Here is an example:
http://blog.ipspace.net/2014/06/snabb-switch-and-nfv-on-openstack-i…
http://blog.ipspace.net/2014/09/snabb-switch-deep-dive-on-software-…
https://twitter.com/lukego/status/309642479056060417
Lennie,
I know he quoted those numbers as well, he even made fun of microsoft’s numbers by saying they were unsurprisingly wrong, but at that point I think he was pulling numbers out of thin air for the purpose of his narrative. I could be wrong of course; it’s hard to tell what was part of the act versus what was supposed to be factual.
But that’s more a property of client side web development in general than anything to do with javascript though. Consider that mozilla’s javascript engine does have optional filesystem access when running on the server.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonk…
Isn’t this completely expected given that javascript has a complete browser monopoly?
Haha, I suppose your probably very tired of my responding this way. Can we agree that what makes javascript special is it’s monopoly in web browsers rather than anything intrinsic to javascript as a language?
You and your long youtube clips and podcasts
Very interesting stuff, but I just don’t have that much time to watch it, the kids are calling for me…
I don’t know why he would pull number out of thin air. The part about overhead seemed reasonable.
OK, I had a look around, here someone has a blogpost about it:
http://ebroder.net/2010/01/02/fast-computing-in-the-kernel/
Singularity:
without context switching: 80 365 1,041 388,162
with context switching: 304 638 2,580 830,999
This sound like a feasible approach.
I wonder if it could be possible to do something like that for Linux containers when they have been made secure.
As the blog post is from 2010, I wonder if modern VMs do this. I mean they didn’t call it KVM (Kernel-based VM) for nothing. Which uses hardware assistance for separation/security.
Obviously the most popular way to have Javascript with fileaccess is:
http://nodejs.org/
Yes, of course this is what makes Javascript special.
And the advantage of the web is the software delivery system:
nothing to install, just visit a URL, run code straight from the Internet.
I can go on for days thinking of arguments. Obviously the quality, frequency or significance will go down. 😉
I forgot an other factor. Because of the browser wars, we get speed:
Javascript VM’s are among the top 3 or 4 language VMs ? (java, microsoft clr, luajit)
http://www.i-programmer.info/news/167-javascript/6734-asmjs-gets-fa…
Now this is kind of cool, I had not seen this page from 2013 yet. What if you take Javascript benchmarks and ran them with C, Java, asm.js and Javascript. Which do you think would win ? Hint, Sunspider is a benchmark very frequently used to benchmark Javascript VMs:
http://www.i-programmer.info/news/167-javascript/6238-java-asmjs-or…
https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-da…
I’m certain your kids are more important to you.
Edited 2014-11-02 08:59 UTC
Lennie,
That was the vision: Not just microkernel drivers, but all of userspace running in “ring 0”. Isolation would be provided through the managed VM semantics. I think it’s a good idea at least academically, but the trouble is not all software is managed code. For unmanaged code we’re forced to incur the overhead of either hardware barriers or software containment like QEMU.
I think it’d be really interesting to have QEMU (software based) in the kernel to run individual processes and even entire operating systems with no context switching. Removing hardware barriers results in new security risks, but in theory it ought to be possible to do securely.
Funny, I’m usually the one criticizing GCC for generating sub optimal code
It’s true though, one cannot assume native code will be optimal simply because it’s written in C. GCC is behind intel’s proprietary compiler, also the libc malloc can be a notably poor performer. C compilers are not forgiving for inefficiently written code. The comments after the benchmarks suggest that there is an excessive use of malloc/free, which makes a big difference in C. Unlike a managed language that can transparently allocate between the heap and stack, in C it is the programmer’s responsibility.
I’d be interested in seeing the best C implementations compete against the best JS implementations, just out of curiosity. But never the less it is a fair point.
Having a JIT has some advantages. It can adapt to code profiling on the fly. A static compiler needs to have explicit profiling runs to do similar kinds of optimization.
Another significant issue with C is pointer aliasing. The C language allows for pointers to be aliases of one another. This is a huge handicap for C optimization. I find this tragic since the vast majority of the time pointers are not aliases and could benefit from register optimization, yet C won’t do it unless you explicitly tell it to using the “restrict” keyword on all pointers. This is why ADA regularly outperforms C, even under the same GCC compiler.
Optimization is a fun topic for me, or at least it used to be when I took pride in such things. These skills aren’t much appreciated.
Yeah, but you compile everything as asm.js to solve that now. 😉
I don’t know, with the Internet-of-Things and mobile, at least some people probably think it useful.
Lennie,
Again, I see no reason to use “asm.js” in an environment where we are not tethered to javascript to satisfy backwards compatibility requirements. An OS is not a browser. It just doesn’t make sense to express all computer code in extremely quirky javascript syntax outside of a browser use case.
What would probably happen is that asm.js would get forked, the useless bits thrown out and the useful VM bits optimized for use in a kernel. This VM would be added to LLVM as a target and the relatively useless “asm.js” code representation would be completely bypassed since it is doesn’t serve a purpose in operating system development. Would you be opposed if this happened?
Edited 2014-11-03 01:25 UTC
Google took down the video that started this thread
http://www.osnews.com/thread?598790
This is the original location. I didn’t want to send to much traffic his way:
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-java…
And to make matters worse, Firefox on my PC goes into a coma so often, I had to set up an Autohotkey macro to restart it so I wouldn’t have to manually give it the 3 finger salute every time it happens. I wish they’d concentrate on making the actual browser stable before trying to figure out how to run Unreal inside of it.
(And because I know someone is going to ask, I dislike Chrome even more than the instability of Firefox, so I put up with it.)
I’m not entirely sure what he wants. I agree that compiling things to javascript is kind of insane, but what else?
If we really are to aim for efficiency, the best would be to define an actual sandboxed but lowlevel VM that different languages can be compiled for. Pick some typed modern language without pointer manipulation as the default choice, and you’ve … reinvented Java/JVM and C#/CLR.
The other way to go would be to replace javascript with some other language that’s easy to sandbox but also easier to JIT into efficient code. It would need a stricter type system, at least – I haven’t looked at Rust, but it could plausibly be this kind of thing. It would need to be a lot better in all ways to get all vendors to agree to switching, though; especially given how much performance the modern javascript engines manage to eke out of the language.
dnebdal,
Strong typing would help, but IMHO supporting specific languages like rust in the browser isn’t the way to go. We’ve got it totally backwards with javascript and I wouldn’t want to repeat that. Javascript should be built on top of a supported VM, rather than VMs being built on top of javascript.
Actually google’s PNaCl works differently than Java or .Net VMs, it’s truly a native sandbox which executes directly on the target CPU – there’s no “VM” or managed memory involved. So, while java’s VM can provide isolation via software containment and code analysis, PNaCl uses the platform’s native user process isolation and doesn’t care what the process does inside. The approaches are radically different in implementation.
Whichever approach, my main goal for inclusion in a browser would be for it to be future proof and language agnostic.