Servo: Inside Mozilla's mission to reinvent the web browser (ZDNet)

Google has suggested in their PR that we were involved, but we never really were. My feedback to them was to base their APIs on the already-standardized Web platform APIs (i.e. make PNaCl an execution environment which simply bound to some subset of the Web platform APIs), but at that point they'd already written some code and didn't want to change anything.

> Also could you specify which part of Pepper API you consider Chrome
> specific and difficult to implement in other browser?

It's not that the API is Chrome-specific. It just doesn't map directly to Firefox internals, so we'd be writing a bunch of code to overcome the impedance mismatch. Anyway I'll concede this point since it's not so important.

> I assume you agree with me that if we were going to make a high
> performance compiler we weren't translating C to dynamic typed language
> (discarding type information) and then perform optimization on it.

Of course, but making a high performance compiler is not the end goal; we're trying to create a stable code distribution format for C and C++-like programs for consumption by Web browsers.

> Are you planning to extent JS with notion of undefined behavior?

No.

> If not (I assume you are not), how are you going perform these
> optimizations to match the performance of regular compiler?

I'm not working on this directly, so I don't know all the details, but for unaligned SIMD operations I think we'd take an approach where JS SIMD operations always work but there's a performance penalty when unaligned. AVX already provides this in hardware and I think that's the way all hardware will go. In the meantime, for architectures that fault on aligned accesses, we could handle the fault, emulate the instructions, and reduce the performance penalty by recompiling the faulting code with dynamic alignment checks.

> Is it true that in asm.js double derefence of pointer (**p) leads to
> bound checking? If so, how are you going to overcome this problem?

On 64-bit machines we allocate 4GB of virtual address space for the heap array and no bounds checks are required. On 32-bit machines we have to do bounds checks, but we use range analysis to avoid most of them.

> Curious, which API they needed for Flash and why it can not be provided
> for regular PPAPI client?

I don't know. My information comes from Brian Smith:
https://groups.google.com/forum/#!topic/mozilla.dev.platf...

> As I understand startup performance occured not because JS is compiled
> faster, but because not entire program is compiled.

That's not correct for Firefox. We compile asm.js code fully ahead-of-time. This reduces run-time overhead and makes execution speed more predictable.

> LLVM IR is relatively clean and I don't see big difficulties to write a
> standard.

OK, but it hasn't been done. Also you don't have a good spec until someone has built an independent reimplementation of it.

> I don't see a problem with UB. The only thing browser must enforce is
> that exploiting UB should not allow breaking sandbox.

It's quite a big problem that any Chrome update (i.e. every six weeks or less) is allowed to break any PNaCl application that accidentally relies on undefined behavior (which is to say, most large C and C++ applications).

> Also you always could redefine specific operations to remove UB (but you
> will lose some optimizations in this case).

Google seems to disagree that it's fixable:
> PNaCl’s goal is that a single pexe should work reliably in the same
> manner on all architectures, irrespective of runtime parameters and
> through Chrome updates. This goal is unfortunately not attainable;

asm.js operates on the assembler level when there is no undefined behavior as every instruction has precise meaning. Nothing prevents a compiler that targets asm.js to take advantage of the undefined behavior in the original source to generate better asm.js.

As regarding SSE instructions and vectorization, asm.js still can support them via generating perhaps calls to new functions in Math that will carry out the operations in the same way calls to Math.imul() and Math.fround() are done currently. For JavaScript engines that do not support the new functions an implementation in pure JS will be provided.

> Is it true that in asm.js double derefence of pointer (**p) leads to bound checking?

Each memory dereference in asm.js leads to an explicit bound check in the machine code unless the engine can optimize the check away or there is a hardware support for doing that like segmented registers on x86. This is not different from PNaCl that also generates extra code on platforms without CPU support for bound checking. As I wrote above, a particular way to enforce bound checking in PNaCl is slightly faster, but asm.js can be adjusted in backward-compatible way if it would not be possible to overcome that advantage by other means.