The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

Post by Already__Taken » Fri, Aug 30, 2019, 6:04 PM UTC

mumblemumble wrote: post #38

gok wrote: post #13

Javascript engines gave up on interpreters too quickly. JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. JS was never meant to be a high performance language. Plus all the heroic work on exotic optimization has just resulted in induced demand. Web pages have just grown to contain so much Javascript that they're even s…

> Browser vendors should agree to make JS slow and safe again Not gonna happen. There's one browser vendor in particular who has 2/3 of the browser market, 96% of the ad network market, 87% of mobile, and a similar lock on online office software, email, mapping/navigation, etc. etc. They have every incentive to use their commanding service in providing both the services and the means of access to those services to co…

Post by chao- » Fri, Aug 30, 2019, 6:10 PM UTC

the_duke wrote: post #12

The Mozilla tech blogs are always a good read. Informative and easy to digest. I can only think of one other company blogging with similar consistency/quality: Cloudflare. Firefox performance has seen tremendous gains since their Project Quantum efforts. It mostly feels on par with Chrome for me pretty much everywhere. There is one glaring omission though: a single company where I have problems with FF on multiple ap…

Post by Quekid5 » Fri, Aug 30, 2019, 6:15 PM UTC

gok wrote: post #65

Quekid5 wrote: post #21

Earlier quoted context omitted.

> JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. Do you have numbers to back that up? There certainly have been 1 or more security holes in JITs, but AFAICT most of the browser vulnerabilities have more to with bad (new) APIs. The level where a JIT operates really has nothing to do with the surface syntax of JS, so…

> Do you have numbers to back that up? Hm hard to come up with a number that shows JS optimizations are hard, but you can peruse a collection of Javascript engine CVEs: https://github.com/tunz/js-vuln-db Notice how many are JIT or optimization issues, or are in esoteric features like async generators or the spread operator.

Post by hk__2 » Fri, Aug 30, 2019, 6:25 PM UTC

devwastaken wrote: post #62

the_duke wrote: post #35

Earlier quoted context omitted.

Diversity and multiple implementations are essential for the web IMO. V8/Blink/Chromium are not independent community projects, but firmly in the hands of Google. Chromium being the only viable implementation would put too much control in the hands of a single company (regardless of which company that is, Firefox being the only implementation would be just as bad). It's redundant effort, but it also enforces consensu…

If that diversity doesn't lead to better results then it isn't necessary. I wouldn't consider the oligarchs of Js engines to be diversity, nor inherently innovative. In the past there has no doubt been innovation, but currently it has significantly stagnated. Wasm was not what was promised. Mozilla and the other vendors just translated the wasm bytecode to js bytecode. All it did was skip a few steps. Yet the actual…

Post by XCSme » Fri, Aug 30, 2019, 6:30 PM UTC

_bxg1 wrote: post #68

Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Given that we often have it on hand already (TypeScript) or could integrate it into our build process (webpack). Obviously plain JS needs to still work without all that, but it could be a compelling point of optimization for large-scale apps. Perhaps the JS byte…