4 ms·

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

by singularity2001 7y ago

olliej 7y ago
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.
- singularity2001 7y ago
  OK got it, thanks. So hopefully https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ will become a standard. Already part of Firefox Nightly! about:config, unrestricted BinaryAST
  - olliej 7y ago
    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.
pizlonator 7y ago
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.

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.

singularity2001 7y ago
OK got it, thanks. So hopefully https://blog.cloudflare.com/binary-ast/ https://blog.cloudflare.com/binary-ast/ will become a standard. Already part of Firefox Nightly! about:config, unrestricted BinaryAST
- olliej 7y ago
  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.

pizlonator 7y ago

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.