There's indeed a connection between record/replay and deterministic execution, but there's a difference worth mentioning, too. Both can tell you about the past, but only deterministic execution can tell you about alternate histories. And that's very valuable both for bug search (fuzzing works better) and for debugging (see for example the graphs where we show when a bug became likely to occur, seconds before it actually occurred).
(Also, you won't be able to usefully record a hypervisor with jockey or rr, because those operate in userspace and the actual execution of guest code does not. You could probably record software cpu execution with qemu, but it would be slow)
I have been down this road a little bit, applying the ideas from jockey to write and ship a deterministic HFT system, so I have some understanding of the difficulties here.
We needed that for fault tolerance, so we could have a hot synced standby. We did have to record all inputs (and outputs for sanity checking) though.
We did also get a good taste of the debugging superpowers you mention in your blog article. We could pull down a trace from a days trading and replay on our own machines, and skip back and forth in time and find the root cause of anything.
It sounds like what you have done is something similar, but with your own (AMD64) virtual machine implementation, making it fully deterministic and replayable, and providing useful and custom hardware impls (networking, clock, etc).
That sounds like a lot of hard but also fun work.
I am missing something though, in that you are not using it just for lockstep sync or deterministic replays, but you are using it for fuzzing. That is, you are altering the replay somehow to find crashes or assertion failures.
Ah, I think perhaps you are running a large number of sims with a different seed (for injecting faults or whatnot) for your VM, and then just recording that seed when something fails.
I assume deterministic execution also lets you do failing test case reduction.
I've found this sort of high volume random testing w. test case reduction is just a game changer for compiler testing, where there's much the same effect at quickly flushing out newly introduced bugs.
Birdi runs drone capture projects across Australia. We acquire and process drone imagery, and provide an online platform for our customers to interact with rich geospatial data.
We are a fully remote, growing and highly experienced team that moves fast and builds flexible and powerful solutions to real problems.
Birdi | Senior Front-End | Remote | Full-time | https://www.birdi.io/careers | Australian working rights required.
Birdi runs drone capture projects across Australia. We acquire and process drone imagery, and provide an online platform for our customers to interact with rich geospatial data.
We are a fully remote, growing and highly experienced team that moves fast and builds flexible and powerful solutions to real problems.
Birdi runs drone capture projects across Australia. We acquire and
process drone imagery, and provide an online platform for our customers to interact with rich geospatial data.
We are a fully remote, growing and highly experienced team that moves fast and builds flexible and powerful solutions to real problems.
I used to play this 2D flick-screen CGA DOS helicopter game as a kid, and I remember enjoying the simple presentation combined with what would now be called sandbox elements.
I thought it was really cool that you could eject from the helicopter and still run around and do things as a little sprite dude, and then get back in and fly off.
When I saw that the source was available, and had a poke around, I decided it wouldn't take (too) much effort to do a modern port, and make the game natively playable on today's machines.
It was a fun little project, certainly easier than my previous game restoration (Space Invaders in C), and it was interesting to explore the creation of a young Mark Currie, cranking out a
bedroom coded game in Turbo Pascal.
So, here it is, a modern port of "Chopper Commando" from early 90s Turbo Pascal on DOS, to C and SDL running on modern unix (linux/mac) and the web.
Incidentally, that's why I'm not interested in playing any games using a streaming service like OnLive, Google Stadia, etc.
Ever since PCs have had DVI and consoles have had HDMI, gaming has been pristine lossless imagery. Go to IP video streaming and have compression artefacts taking a dump on every single frame? No thanks!
I'm glad to see that others remember this fondly as well.
The Pascal to C translation was a bit gruelling. I'd like to say that I'd written a fancy transpiler for it, but it came down to a 20 line ruby script, some vim macros and a ton of elbow grease.
I added the functions to emulate the Turbo Pascal library as I went. This was a bit more fun, because I got to play around with implementing line drawing, circle drawing and flood filling, and really low level stuff like that.
The final stages, adding in threading to handle emulating the keyboard buffer, framebuffer and PC speaker was also a lot of fun.
I plan to cover at least some of these things in part two.
With these restoration projects, I am usually looking to maximise code portability and minimise dependencies, which for me means C.
Sticking with Pascal would have been more authentic to the original source code, but I think that would have been more painful for me to deal with, and come with a lot of unknown unknowns.
I would likely also have been sacrificing my ability to port it onto the web and other interesting targets.
Yeah, that makes sense, I mentioned freepascal specifically because it has pretty broad platform support (and can generate LLVM bitcode). But, maybe the cost of translating to C is worth it.
I loved this game as a kid. I think I only ever had a demo, because I don't remember being able to play different missions, but I played that simple demo a lot, and revisited it over the years. It had just enough free control and different actions to make screwing around rewarding and fun.
https://www.cs.purdue.edu/homes/xyzhang/spring07/Papers/HPL-...