Hacker News Reader

Comment by singularity2001 | Hacker News Reader

singularity2001

Now please expose a loadFromByteCode api so that we can target bytecode instead of transpiling to js.

Suprised no one has posted https://blog.cloudflare.com/binary-ast/ . Its not bytecode but its still a great idea

Oh wow!! In a way it's even better than bytecode because it allows marking unused functions for lazy loading, giving speedups of 97% (in theoretical settings;)

Must read.

https://github.com/binast/binjs-ref from below is part of this!

WASM's (abandoned, because brotli is good enough) Binary Encoding proposal was essentially a binary AST compression system that worked for both JS trees (esprima) and wasm ASTs.

You get pretty good improvements by converting ASTs into SoA representation, interleaving them, and then compressing them. Fast to decode, too.

https://github.com/WebAssembly/design/issues/1180

The bytecode is an implementation detail that can, and does change. Making it an API would necessarily make changes (like this one) impossible.

some standardization wouldn't harm. Then we can do loadFromByteCodeV1 and later loadFromByteCodeV2

No, it absolutely would.

Because then any changes require duplicating the byte code parsers, and adding translation logic to manage those changes.

You must understand: any change would be an API break, and API cannot change. Deprecating an API takes years. You also can't change/add API in security updates, which means if a security fix required changing some aspect of the bytecode that change couldn't be made.

Lets say you change numbering of registers? Thats an API change.

Lets say you change number of opcodes? API change.

Any new API in macOS and iOS requires weeks of review cycle to ensure:

* It solves a problem in a generic manner: e.g. it doesn't solve a very specific version of a general issue

* It can be kept stable: e.g. it doesn't expose implementation details that may change

* It is ABI stable: direct memory access APIs cannot expose layout that can vary based on any internal details.

Shipping API is incredibly difficult if you care about ABI stability for software.

OK got it, thanks.

So hopefully https://blog.cloudflare.com/binary-ast/ will become a standard.

Already part of Firefox Nightly! about:config, unrestricted BinaryAST

binary-ast doesn't give any significant benefits over JS, potentially a small reduction in size vs standard gzip responses, but I've yet to see compelling evidence binast offers any significant time saving to first execution.

It's important to realize: binary-ast is no more readily executable than plain JS, it is no more trustable than plain JS, and even if they were parsing is not been a significant part of ttfe in JSC in a long time. It's the interpreter codgen that eats up time, and the execution speed difference between AST (which JSC used for a looonng time, and the final builds beat the contemporary bytecode interpreters of other engines when it was replaced). The performance of an AST is so much slower than bytecode interpreter that you require a tiny amount of JS before the cost of codegen+execution beats just execution using the AST.

JSC makes breaking changes to the bytecode format on a regular basis. It’s an internal implementation detail and isn’t going to be exposed to standards.

Also the bytecode format has no memory safety guarantees so standardizing it wouldn’t be a great idea. It’s only trusted to obey basic VM invariants if we know that we generated it ourselves.

Don't the existing plans to expose GC [1] and ECMAScript objects [2] to WebAssembly cover this?

[1] - https://github.com/WebAssembly/proposals/issues/16 [2] - https://github.com/WebAssembly/webidl-bindings/blob/master/p...

Possibly. I'm a bit discouraged that ref's are opaque and cannot be mapped to wasm memory but maybe I missed something.

I was thinking along the same lines as you, but kannanvijayan helpfully pointed out to me that it isn't that simple:

https://news.ycombinator.com/item?id=19966100

This will never happen because it turns internal IR (subject to change) into a formalized format that people will depend on every detail of, including bugs.

If you want bytecode, use wasm.

Chrome and Facebook are testing such a thing. I’ll look for the reference link. Maybe one of them can pipe up.

This is, give or take, what web assembly is supposed to do, no?

Wasm is a bytecode, but not js bytecode. In fact compiling js to wasm is very nontrivial / requires compiling it with a whole VM.

Reply on news.ycombinator.com