Announcement

Collapse
No announcement yet.

Servo Driving Modularity To Support Different JavaScript Engines

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Developer12 View Post

    Writing a JS engine in rust isn't sufficient when JIT is involved.

    While a rust non-JIT JS engine would probably be quite secure, JIT means dynamically generating x86 (etc) assembly code from JS code and then executing it. This assembly is highly optimized through the use of a lot of assumptions/predictions about the JS code which aren't universally valid, and which no sane compiler developer would include in a compiler for languages like C/C++/Rust/etc. Part of the reason this works is that for the weird corner cases where assumptions don't hold the generated assembly can be made to fall back to the slower non-JIT interpreter.

    The end result is that there have been many logic bugs in javascript engines' optimization passes that result in unsafe assembly code, memory corruption, and JS engine sandbox escape. Rust's compiler can protect against that stuff for rust code which is compiled up-front, but it can't provide any assurances for random JIT'd code that your code generates later. There also (in general) isn't really a lot of stuff you can do to prevent these kinds of logic bugs, even on a theoretical level. It took a long time for just the theory behind Rust's borrow checker to emerge.
    So no hopes to end the JavaScript hell of bugs?

    Comment


    • #32
      Originally posted by timofonic View Post

      So no hopes to end the JavaScript hell of bugs?
      there will never be hope T.T

      Comment


      • #33
        Originally posted by bug77 View Post
        I believe all that. But I still think there should be a better way.
        Gawds how I wish there could be. JS is so entrenched it's basically impossible to undo the bad decisions.

        If I were an evil dictator I'd spec "HTML6" as the divorce from the traditional HTML/JS/CSS trio as-is. Gear it all towards a breakaway simplified engine design with a goal of energy efficiency and minimizing requests. Fold the scripting and styling into a unified language, with some annotations. Remove all semantic tags from the standard, as well as script, style, and CSS link tags. Essentially, turn rendering engines into low-level build-a-spec systems where the unified stylescripts are HTML5 components on steroids.

        Then, over time, build a legacy renderer on top of the new renderer, loading a browsers built-in implementation of the old spec on the new spec when the doctype is old, running things like JS and CSS parsers in webassembly. Somewhat like how OpenGL runs on Vulkan via Zink.

        Good thing I'm not a dictator.

        Comment


        • #34
          Originally posted by timofonic View Post

          So no hopes to end the JavaScript hell of bugs?
          If you want totally, properly secure JS, you would need to sacrifice a significant chunk of performance and run with a non-JIT interpreter. The modern web punishes this heavily, with massively over-complicated webpages that do huge amounts of heavylift processing on the client side, just to assemble the layout of a page that is essentially static anyway.

          Chrome are making some musings about memory-isolated JS engines, but I don't think it's going to make any meaningful difference. At most it's a speedbump. The tools for sandboxing in the way they need don't really exist. The closest thing might be containers (which it sounds like they're NOT using), but those would be an extremely awkward solution that would be very hard to get right and would be hard to port between platforms anyway. (good luck getting containers to work on windows and provide meaningful security)

          Comment


          • #35
            Generally speaking modularity is usually good.
            Maybe the ability to use different JavaScript engines simultaneously could be developed?
            Maybe even using different JavaScript engines for different content in the same page?!

            Comment

            Working...
            X