There was a v8 fork a long time ago that had persistence built in. You could kill the process, & start a new one & everything was just as it was.
I love this kind of stuff. Programming languages are boring, hardly any different from one another. But building an interesting enriching runtime that makes it more clear what is happening, what is going on? Thatcs awesome. That's how computing starts to level up. Long hope but some day i believe software will better be able to say what it's doing so much more elegantly that software itself will become more interesting, that we'll start to see more incidental curiosity & exploration, some bridging of thr gulf between user & developer.
I had a Google Summer of Code project under Codehaus, many years ago, adding some similar instrumentation to Mono & .NET. A bunch of stupid bytecode rewriting, nowhere near this cool. But tickles me to see!
Yes I did... Revell's Visible V8 Engine model kit is very well known among a special group of nerds: Those who build their own replicas of props from the original Star Wars movies. (I am one of those nerds ...)
Parts in the kit had been used as "greeblies", glued onto lots of different props in The Empire Strikes Back and The Return of the Jedi.
This includes droids, helmets, rank badges and other applications on clothing, and "blasters" (guns): most popularly, the pistols used by the popular characters Han Solo, Luke Skywalker and Boba Fett.
This seems like it’s positioned for a very specific use case, understanding obfuscated code. But it seems like the same capabilities could be exceedingly useful for a lot of more mundane code analysis tasks. Determining actual code paths accessed and possible types at runtime in JS is challenging even if you manually provide a lot of that information to eg TypeScript. Getting even confirmation of a subset of that information and additional insight into the dynamic superset from real runtime JIT analysis could be invaluable for understanding a codebase if it’s inscrutable, and even for designing static optimization tooling.
Better would be to record V8 with rr and debug using https://pernos.co/. Maybe a combination of the two would be helpful, as I think you would be able to click a log line in Pernosco and timewarp to the call that printed it for further debugging.
I mean it would be "better" in fidelity maybe but it definitely would be a worse experience out-of-the-box because it'll be debugging at one level "below" the state you actually care about, which is the JavaScript rather than the VM.
I love this kind of stuff. Programming languages are boring, hardly any different from one another. But building an interesting enriching runtime that makes it more clear what is happening, what is going on? Thatcs awesome. That's how computing starts to level up. Long hope but some day i believe software will better be able to say what it's doing so much more elegantly that software itself will become more interesting, that we'll start to see more incidental curiosity & exploration, some bridging of thr gulf between user & developer.
I had a Google Summer of Code project under Codehaus, many years ago, adding some similar instrumentation to Mono & .NET. A bunch of stupid bytecode rewriting, nowhere near this cool. But tickles me to see!