(disclaimer: current V8 team member replying to senior ex-V8 team member)
I'd say there were a lot more things problematic in practice with SoN than not relaxing effect edges enough - I'd argue that the bigger problem was that a single effect chain was not enough to represent the flexibility that SoN promised, while keeping the costs, and getting that flexibility would mean effectively extending the effect chain to one effect colour per object per field. Maybe this was a JS specific idiosyncrasy, but my experience was that the effect chain became almost homomorphic to the control chain (and when it wasn't, we had bugs), and then you may as well merge the two into a CFG - if you have to skip over links in your effect chain to skip over certain kinds of effect then you can equally well skip over zero effect nodes too. With SoN, we got all the costs and (almost none) of the benefits, hoisting really isn't so difficult that you have to design your whole IR around it.
As for IR design and TFs good architectural decision, idk, I don't think it's all that different from what we ended up with in maglev. All those classes are just convenience views onto a consistent node layout (with e.g. the same trick as TF of putting inputs behind the node), and so far we haven't had issues with it - time will tell I suppose.
Overall, this narrative that TF, with it's SoN and other serial decisions, was super clever and built by very smart senior engineers that just all moved on and left behind just us dummies that don't get it -- I've honestly never argued against it. Hell, I can even agree with it, same as I totally believe Cliff when he says that he could easily solve every problem we struggled with (likely by doing it in the scheduler). Tony Stark built one in a cave with a bunch of scraps, but unfortunately I'm not Tony Stark, and we've ended up choosing human comprehension (instead of superhuman) as a design constraint so that us dummies can still work on it after all the senior engineers got promoted away or bored. I think this is a good decision and I stand by it.
Well obviously I don't think that you're a bunch of dummies so please don't throw out strawmen like that.
I don't know if Cliff is on the same page w.r.t. how much speculation is necessary (and when) to make JS go fast. In particular, inserting speculative guards has the nice property of improving downstream information for dominated control flow paths. Dominated control flow paths are few and far between when the control chain is very relaxed (in fact, that's the point of a relaxed dependency representation--the graph doesn't have induced dominance information, just dependencies). So relaxing ordering actually works against making use of speculation decisions, because speculation decisions have all these downstream (forward) benefits. It actually makes a lot of sense to work out what speculations are going to be done and propagate their effects on a fully-scheduled CFG[1].
The case is not the same in Java. In C2, afaict, all speculation happens at graph build time, which is driven by abstract interpretation of the bytecode, which follows the control flow order. That means it can make use of dominance information.
AFAIK Graal does scheduling multiple times, whenever it needs to know explicit control information. This allows its speculations to propagate forward to dominated paths.
> Maybe this was a JS specific idiosyncrasy, but my experience was that the effect chain became almost homomorphic to the control chain (and when it wasn't, we had bugs), and then you may as well merge the two into a CFG - if you have to skip over links in your effect chain to skip over certain kinds of effect then you can equally well skip over zero effect nodes too. With SoN, we got all the costs and (almost none) of the benefits, hoisting really isn't so difficult that you have to design your whole IR around it.
I think this is the core of the problem. Control and effects are different things and it wasn't until long after TurboFan that I understood this well enough to even articulate it to myself, let alone to others. The only nodes that really need control inputs are those that have write effects or could diverge (not terminate). Reads of mutable state don't need control, they just need to have an effect input to order them w.r.t. writes. Writes don't need to depend on reads, like they did in TF IR; they are anti-dependencies that can be treated differently. From conversations with Cliff, I think C2 does treat antidependencies differently. Truth be told, writes don't even need to have control dependencies if the scheduler replicates code to make sure that different versions of the world are not simultaneously live (i.e. they are affine resources). The control dependencies in TF graphs were basically a CFG embedded in the graph and making writes depend on control more or less achieved that affine-ness.
While JS has far too many things that can change the world, it's clearly not the case that all the effect chains were linear, because load elimination would never happen, and no code motion would ever be possible. While it's hard to know how you think of "multiple effect chains"--it doesn't have to be represented by a multiple of edges in the graph. You can still have a single effect edge per node in most cases.
In the end it seemed like some people were really intent on only thinking about optimization from a CFG perspective and chaining a CFG through all effectful things, completely defeating the purpose of a dependency graph. People think about IRs in different ways, sure, but the dependency graph view and mindset is inherent in the sea of nodes representation. "Walking the code forward" is a common mental mode for CFG optimizations but is just alien to sea of nodes.
[1] To cut to the chase, and hindsight is 20/20, I think the best design for JS optimization is to use a CFG for a lot of frontend and middle optimizations, before lowering, to use it to insert speculations, and then to thread only a minimal effect / control chain to make a sea of nodes graph, run all the optimizations again, and reschedule it to a CFG. TBH I am not sure whether lowering should happen on a CFG or SoN--it does matter, but I don't think there's a definitive answer. But definitely run GVN on SoN after lowering--there's a bazillion common subexpressions to find then. It'd be great if optimizations can be written to be independent of whether a node is hooked up in a CFG or a SoN, to allow reuse between the two different representations. Or if the representation was sufficiently parametric that nodes could be hooked up in either configuration.
The dummies phrasing is my own, and I stand by it - I simply find the CFG way of thinking much easier to reason about than the SoN way, and I find myself falling back into it no matter how hard I try to follow what I totally (abstractly) appreciate is a more mathematically beautiful dependency/anti-dependency graph - I think that's a limitation of my ability to maintain that concept in my mind and that other people can do it better than me. I find it far easier to reason on CFG terms most of the time, and to raise the CFG temporarily into some dependency representation for doing eliminations/hoisting/LICM, than I do maintaining that dependency representation across all phases and accurately reasoning in each of those about what concrete dependency I forgot about when writing the reduction (concrete recent example, I tried to make reading from holes segfault by unmapping the hole, to force potential holey field access to always first compare against the sentinel, but I was foiled by TF since the load had no dependency on the hole compare branch and could be hosted above it). Implying that this was simply "some people" insisting on only thinking one way without trying to think the SoN way, or that it was some sort of CFG prejudice, is the actual strawman here.
I've been quite smitten with Destination-Driven Code Generation and its separate data and control destinations feeding through to the sub-trees letting everyone know what's expected to happen to the data they're computing and where to go next. Makes a super-simple CPS converter as destinations == continuations and I can feed the CPS IR straight into a Click-inspired optimizer to do the things. It's actually fairly close to the design from TFA just based around continuations and whatnot instead of a SSA IR.
Be careful to check whether you're in a glass house before throwing stones - "layoff" used to mean a temporary release from employment for seasonal labour before it meant a permanent one (https://www.etymonline.com/word/layoff). "Standard" as an adjective also used to mean "being held to a standard of excellence" rather than "normal" or "average". It's ok for words to change meaning over time.
The complex parts of JavaScript are the semantics, not the syntax. You could reasonably easily spec a bytecode for JS to get rid of the syntax part, but nothing would change in the complexity (almost all modern engines parse to bytecode as the first step and operate on bytecode from then on).
If you wanted to implement JS in wasm, you'd either need a bunch of wasm extensions for JS semantics (dynamic object shape, prototypal inheritance, etc), or you'd need to implement them in wasm from scratch and basically ship a JS runtime written in wasm. Either that, or you need to change the language, which means de facto adding a new language since the old JS still has to stick around for old pages.
I admit I don't have depth of knowledge with how JS and Wasm work behind the scenes, but you can already compile JS to wasm. Forgive the ignorance, but what am I missing here? When you compile JS to wasm, aren't the semantics and language behaviors already addressed?
My understanding was that things like DOM manipulation APIs would need to be (and are) exposed to the WASM runtime so that the JS-to-WASM compiler could do all the right bytecode "linking".
My idea is that if JS itself was require to in WASM, and native JS support didn't exist, the complexity in browsers would be reduced dramatically. And developers will be free to use different languages. Browsers will focus on APIs instead of language semantics. no more V8!
You can't currently "compile JS to Wasm", you can compile a JS engine (likely written in C++) to Wasm and run JS inside that (almost certainly at lower speed). So instead of "no more V8", it's closer to "ship V8 as part of the website, instead of part of the browser". Exposing DOM APIs to Wasm is a completely different question, though even those would actually have to be new APIs with a new API design that works for Wasm, since the existing DOM APIs are effectively defined in terms of JS objects being passed around.
I didn't know this, thanks for explaining. If DOM APIs could be reworked for wasm support, and JS can work with those APIs, that would suffice. It won't get sites off normal JS any time soon. As far as speed, is it an optimization problem? I'd think just running bytecode is faster than interpreting a script. It doesn't need to be backwards compatible with existing JS code, it just needs to be possible to write front end code in JS for WASM. Migrating to the new approach could be similar to migrating away from Flash, ActiveX and Applets, but at a much larger scale.
10-20 years from now, is it really ok to be stuck with JS and CSS? The complexity is compounding, ever newer webapi's get encoded as JS APIs, and the dependency mess will only increase. Browsers are about as complex in some ways as an operating system. If we think about the world in terms of decades, what is the plan? This is a very serious issue, because of how much the world depends on browser tech, and effectively, Google is the arbiter and overseer of that technology. I don't think this will work out well, unless there is some timely foresight in the architecture.
Ah that looks like a great tool, will try to keep it in mind if I run into those kinds of issues again.
Couldn't have caught one of the worst bug I had to track down that was a memory corruption on the PS2, we had some dynamic async loading that used DMA channels and someone had carelessly released memory used by these async loads.
Back then memory addresses was fairly deterministic so I thought I could add a memory breakpoint to catch it (i thought), bewildered me when I first witnessed the memory addresses with breakpoints being corrupted... until it clicked and became the clue that it had to be caused by a system (DMA) that didn't care about the systems hardware memory breakpoints.
The signed length fields pre-date the sandbox, and at that point being able to corrupt the string length meant you already had an OOB write primitive and didn't need to get one via strings. The sandbox is the new weird thing, where now these in-sandbox corruptions can sometimes be promoted into out-of-sandbox corruptions if code on the boundary doesn't handle these sorts of edge cases.
Not exactly. It's the nature of a sandbox that it doesn't remove bugs, it only reduces their blast radius. The Truffle architecture actually removes bugs by changing how you write the language VM to begin with.
I said it "protects" against bugs, not that it "removes" them. The Truffle architecture removes mismatches between JIT and interpreted code (when it doesn't have bugs itself, which is not guaranteed either), but it doesn't remove runtime or object model logic errors that affect both.
