Workweek alt js

• zwarich: Various people have suggested creating an alternate engine to SM for various reasons. Off the top of my head: make something with less memory usage (if Servo is particularly focused on memory footprint); security implications of architecture of modern engines - multi-tier + caching + property access + state machines for objects, combination leads to security vulnerabilities due to complexity; SM has taken path of binding external code that is complicated and hard to do right. Difficult to enforce restrictions using Rust type system and maintain performance. Common opinion among browser devs that lots of heavy JIT compilation is not useful for browsing the web and interpreter should be enough with less overhead. Even including sites like gmail and facebook, while benchmarks will show 2x-5x reduction. Something else that came up this week is that we may want to experiment with engine using UTF8 internally (or + lone surrogates); could we come up with better DOM bindings, etc. Unify DOM on Rust heap with JS reflectors, too - all of this is easier to experiment in a new engine, rather than tying in to large existing codebase.
• jack: TOR browser turns lots of features off, including JS. If we had interpreter in Rust that was safe, might those projects feel comfortable turning it on?
• zwarich: Doubtful that we get good enough performance in memsafe rust.
• kmc: Not just about safety. Lots of exploits about lack of isolation between JS contexts. If we write impl concerned about security, could have paranoid mode that checks these things.
• pcwalton: Haven't looked at sec-high instead of sec-crit, so haven't analyzed that claim. Haven't looked in detail at counting vulns in JIT vs. GC. Not sure if numbers are skewed towards later bugs during Ion construction vs now. Do know that vast number of vulnerabilities are GC/JIT related. Should think about how to do GC properly to avoid problems. Either go to conservative GC or use Azul's GC patches and integrate with language.
• zwarich: Just start of solution, not solution on their own.
• kmc: GC question is interesting since we use it to manage DOM. We could write our own GC that would be optimized for DOM stuff.
• jack: Isn't SM optimized for that?
• kmc: It doesn't control DOM.
• zwarich: Making perf a goal doesn't make sense when comparing against full-features engines. Even if you have a new idea, can't compete.
• kmc: Doesn't have to beat other engine, just has to be usable on real websites. Having a tiny, self-contained interpreter with some perf hit is worth that.
• dherman: I don't see how to do this without jeapordizing everything else you're doing. Servo is already a large-scale reimplementation project, you're talking about adding the next largest reimplmentation project. That said, I think talk about JITs being useless is folklore and confirmation bias. I think things on the web wouldn't have happened without JIT wars. Nobody claims existing benchmarks reflect reality. That aside, the things you're saying are technically true, but I don't see how this fits within existing priorities.
• pcwalton: Not talking about schedule risk/headcount, I'm looking at what the gains are. In Servo we're focusing on parallel layout (and everything). For JS we have nothing similar - no ideas that would require massive rewrite of the engine. Not sure if there are any ideas out there in general.
• dherman: It's clear that one possible market for Servo is embedded where memory matters a lot. Not clear if you can't just disable JITs to gain memory, tune heuristics. Big leap to say let's rewrite the engine to get the memory profile we need.
• pcwalton: We have this thing parallelizing parts of the browser that we don't think can be done in other engines, hence why we're doing it in the first place. JS has nothing similar.
• dherman: There's a paper out there; I haven't looked at it much. Sony partnered with a PHD student who did a parallel thing in an engine and saw lots of speedups, but suspicious.
• pcwalton: We can talk about writing one with better security, but not clear how to do it. Really hard.
• dherman: Security perfection is also not the goal here. HAve to be better than the competition, but not one billion times. Not going to make a difference for viability of the product.
• pcwalton: I think security may be more important to market than...
• dherman: Not saying not important, but diference between better and much better is much less than better and worse. Hard to quantify, but if we can say that we do all the same things as competition and doing better in pwn2own etc., we're seen as best-of-breed. Big win. Difference between that and hardening the JIT better than everyone else, much smaller. End of day, if we get pwned way less...
• pcwalton: Point is relating to JS specifically. I don't see ways Rust can help write better engine. We could write a secure engine using RefCell/Rc, but that would not be fast at all. Lots of dynamic checks, lots of sacrifices. Layout is a different beast than JS; we can control the representation of things like layout tree and restructure algorithms to fit into Rust type system. Lots of benefit there since only the output matters. Don't know how to do that for JS; everything is mutable, everything can reference everything else, whole model is GC, and that strikes me as hard. Maybe Rust of tomorrow with better GC integration with solution for massively aliased data without RefCell could be more compelling, but I don't see using Rust of today.
• jack: It sounds like you're arguing both ways; don't see how Rust can get us there, but also perfect project to figure out what changes to Rust are required to enable this. If Servo is Rust 1.0 proof of concept, it sounds like this might be interesting for Rust 2.0 seed.
• pcwalton: If we can focus on proper GC support... our bindings aren't any worse than any other engine right now. Solving the managed/unmanaged divide should be a goal going forward. Dealing with relocating, knowing about JS objects would be a big leap forward. I could see that paving the way towards integrating into the JS engine, since if compiler knows about GC stuff you can apply that to the JS engine, but I don't know if that would take the form of rewriting the JS engine or just adding more hooks. I see avenues for improving SM going forward based on better compiler support in Rust, but I think writing a new engine right now would be jumping to conclusions. We shoudln't declare defeat and that SM's security problems are things we'll need to deal with forever, but I also don't think we should try to recreate the engine.
• dherman: We shouldn't treat it as a black box. We should talk to the SM team about ways it could do things better. There are people happy to collaborate and brainstorm to improve architecture, bindings, etc.
• pcwalton: If we want a secure engine, we can turn off JITs and write interpreter in Rust, but does that buy us anything?
• zwarich: It's not any worse for us, but everything else in Servo is expressed so well, this stands out.
• dherman: This is something we need to work on with our relationship with the SM team. Part of that is having them pay more attention to us, and part of that is proving that we're real.
• pcwalton: The team did what they needed to. Moving GC is a good thing. This is an opportunity; moving GC makes it much harder to integrate, but if the compiler can provide extra information... the right solution is to have moving GC and have compiler aware and able to handle it. The JS engine can now do it, but C++ can't meet them halfway. Rust could rise to the challenge and complete the picture. We're uniquely positioned to achieve this since we have our own language.
• cgaebel: Are you proposing deeply integrating SpiderMonkey with Rust?
• pcwalton: I'm proposing using Azul's patches to use smart pointers and language integration with moving GCs.
• kmc: Exact GC, not just moving GC. If Rust could plug in a GC, this would be a big deal. Worth effort if we have the resources.
• zwarich: Difficult when you have precise and moving, not just precise. Moving is essential here. Azul does deal with that.
• dherman: Already on the radar of Rust team. pnkfelix and nmaktsakis have been interested for a long time.
• pcwalton: That's the place I see JS effort being able to achieve generational leap. It's not just rewriting for the sake of rewriting, but for tangible benefit. Security and performance. It's also less work than rewriting a full engine.
• dherman: Chrome comic book boasted about specific things they showed off for big innovations. We have a couple - end to end parallel engine; Rust may not be comic-book level.
• pcwalton: Servo would not have nearly as much mindshare without Rust. We shouldn't shy away from that.
• dherman: Being able to say we had clean and performance solution to briding managed/unmanaged heaps would be big. All browsers stymied by that.
• pcwalton: Having looked at 500 Gecko security bugs, I'm feeling good about claiming that Rust elimintes 50% of those. You want to be clear that security isn't black or white, so maybe speak in language of statistics. Message that we're making decisions based on data. Not saying all security vulns, but 48.5% based on our data.
• kmc: Gets attention, since it's big enough to raise heads but not selling snake oil.
• zwarich: Still, what if something in DOM that violates Rust safety model and causes one of those to occur...
• dherman: Key thing about safe language that allows access to FFI is surface area. When something is a violation, the fault can be pinpinted to unsafe surface area. In Servo, that area is much smaller. Shrinking TCB reduces probability of exploits, but also easier to respond to chemspill since less area to audit. All of these are subtle arguments.
• kmc: In Servo it's not just percentage of unsafe code, but we also have a solid core of unsafe code, so other people working on higher-level stuff don't have to worry about memory safety.
• zwarich: Tricky thing about unsafe code is that if it accidentally introduces data race or whatever... we don't have boundaries. It can make anything in the safe part unsafe.
• kmc: We have boundaries, but the boundaries aren't safety-checked.
• zwarich: Not even dynamically checked.
• dherman: We've said that it's your problem not to violate memory safety, but we haven't stated what the rules are.
• zwarich: Until there's a formal model of unsafe code...
• dherman: We had a PhD student doing that... lots of students with formal modelling skills, so I think we'll get there. That's something we can farm out to academia productively. I totally agree that's a gaping hole right now.
• zwarich: I think the best statistical claim is one we can't make on initial release - over time better than competitors.
• dherman: Same with things like process isolation at first release. Have to convince people of coolness and correctness first.
• pcwalton: Despite me being one of the people quoting folklore about disabling JIT, I don't see how we can ship a production engine without a JIT.
• kmc: Not for desktop mobile, but for embedded...
• dherman: Until we have someone willing to make a deal with us, we lose focus if we think about that. I don't think now is that time.
• mbrubeck: There's someone writing a JavaScript JIT in Rust; definitely toy/Robinson quality, so not necessarily useful to us, but maybe useful for experiments? https://github.com/TomBebbington/js.rs
• pcwalton: I don't think we can just handwave away the (???). JITs are all about doing tricks with type information in memory. It's about omitting type checks.
• jack: Multiple reasons to write JS engine in Rust. One is to quickly experiment. SM is far away from a research project; everything they do gets measured. If we go to them with wild requests, they don't have freedom to do experiments that would affect our critical path. Any experiment - fused bindings, different DOM access strategies.
• zwarich: For exmaple, different object layout on heap. That's everywhere in the engine.
• jack: These experiments don't need to ship; Servo would probably still ship with SM. But if we can show validity of experiments, maybe it makes sense to do them in SM.
• dherman: JS is like C; seems small, but turns out...
• jack: Not arguing we have resources, but maybe when we do budgeting for 2016 we make requests for such resources. The argument that we need to make progress; that's why we started rewriting the browser.
• dherman: Maybe JS engine is less big and risky than Servo, but it's at the same level.
• jack: The goal of doing experiments may be to convince SpiderMonkey to change its design.
• pcwalton: Rewards of UTF8 and fused DOM bindings won't yield massive safety/performance beneifts.
• kmc: In practice, I think we have many other places we want to spend headcount and risk budget. IF we're done with layout in next couple years, there are many other places.
• zwarich: I think the number one problem after layout is the DOM binding safety one.
• dherman: We have an alternate path we think is plausible.
• zwarich: Idea that we add features to the language to use GC stack information and add that to SM; not clear what the actual features look like.
• pcwalton: Until Azul patches land upstream it's always in limbo.
• zwarich: There's a branch on github. The Rust people are pretty busy for the next few months, too. It does seem like it would be possible to make it work, but whether you're writing the right Rust code...
• jack: Should we table the alt-js discussion until mid-2015? We certainly don't have the resources to do this right now. We'll bring this up next year and see where we're at.