Intent to implement: Early, experimental support for application/javascript+binast

[David Teller]

# Summary

JavaScript parsing and compilation are performance bottlenecks. The
JavaScript Binary AST is a domain-specific content encoding for
JavaScript, designed to speed up parsing and compilation of JavaScript,
as well as to allow streaming compilation of JavaScript (and possibly
streaming startup interpretation).

We already get a 30-50% parsing improvement by just switching to this
format, without any streaming code optimization, and we believe that we
can go much further. We wish to implement
`application/javascript+binast` so as to start experiments with partners.


# Bug

Bug 1451344


# Link to standard

This content encoding is a JS VM technology, with an entry point for
loading in the DOM.

- DOM level: No proposal yet.
https://github.com/binast/ecmascript-binary-ast/issues/27
- JS level (high): https://binast.github.io/ecmascript-binary-ast/
- JS level (low): No proposal yet.
https://binast.github.io/binjs-ref/binjs_io/multipart/index.html#overview


# Platform coverage

All.


# Estimated or target release

For the moment, no target release. We are still in the experimentation
phase.


# Preference behind which this will be implemented

dom.script.enable.application_javascript_binast


# Is this feature enabled by default in sandboxed iframes?

This is just a compression format, should make no change wrt security.

# DevTools bug

Bug 1454990


# Do other browser engines implement this?

Not yet. We are still in the experimentation phase.


# web-platform-tests

No web platform specification yet.


# Secure contexts

Let's restrict this to secure contexts.

[Dave Townsend]

This is awesome. I understand that we already do some kind of pre-compile
for our chrome code, is there any plan/benefit to switch to this eventually
there?

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[David Teller]

No plans yet, but it's a good idea. The only reason not to do this (that
I can think of) is that we might prefer switching to the Bytecode Cache,
which would probably give us even better speed ups.

I understand that we can't use the Bytecode Cache for our chrome code
yet due to the fact that it uses a very different path in Necko, which
is the Source of Truth for the Bytecode Cache, but I may be wrong, and
it might be fixable.

Cheers,
David

[Honza Bambas]

On 2018-04-18 19:13, David Teller wrote:
> No plans yet, but it's a good idea. The only reason not to do this (that
> I can think of) is that we might prefer switching to the Bytecode Cache,
> which would probably give us even better speed ups.
>
> I understand that we can't use the Bytecode Cache for our chrome code
> yet due to the fact that it uses a very different path in Necko, which
> is the Source of Truth for the Bytecode Cache, but I may be wrong, and
> it might be fixable.

ByteCode cache is implemented "natively" only for http:// urls through
http channels talking to http cache.

There is an effort to implement the alternative-data bits of the caching
channel interface (implemented by the http channel now) also for
channels handling chrome: and I think resource: urls.  There is lately
not much progress on that bug(s) to my knowledge, though.

-hb-

>
> Cheers,
> David
>
> On 18/04/2018 19:09, Dave Townsend wrote:
>> This is awesome. I understand that we already do some kind of
>> pre-compile for our chrome code, is there any plan/benefit to switch to
>> this eventually there?