It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
Debugging in the Multiverse
51–60 of 62 posts
Re: Debugging in the Multiverse
#52Antithesis employee here. Happy to jump in and answer any burning questions people might have about multiverse debugging.
Is the hypervisor multicore? How do you handle shared memory non-determinism? What is the runtime slowdown for shared memory multicore (lets say 16 cores if you need a concrete example) execution?
This is just a standard replay engine from what I can tell.
Re: Debugging in the Multiverse
#53Earlier quoted context omitted.
Is the hypervisor multicore? How do you handle shared memory non-determinism? What is the runtime slowdown for shared memory multicore (lets say 16 cores if you need a concrete example) execution?
Found the answer in a different post [1]. The hypervisor and virtual machines are single-core only. The talk also indicates that all I/O operations need to be manually rewritten to use the instrumented mechanism, so it demands a highly paravirtualized guest OS. Logically, that means there are probably no cross-VM shared memory interfaces either. So, no shared memory and thus no need to deal with shared memory non-det…
It also is not in any sense a replay engine. We don’t need to record anything except the inputs!
Re: Debugging in the Multiverse
#54It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
From the little I have seen, most programming language folks don't seem to care much about debugging. They care a lot about bugs not happening in the first place, which is good, testability is sometimes taken in consideration, but not much about what to do after a bug happened. No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the b…
Re: Debugging in the Multiverse
#55Earlier quoted context omitted.
Found the answer in a different post [1]. The hypervisor and virtual machines are single-core only. The talk also indicates that all I/O operations need to be manually rewritten to use the instrumented mechanism, so it demands a highly paravirtualized guest OS. Logically, that means there are probably no cross-VM shared memory interfaces either. So, no shared memory and thus no need to deal with shared memory non-det…
No, we don’t require any paravirtualization at all, and nothing needs to be manually rewritten. I’m not sure where you got that impression. It also is not in any sense a replay engine. We don’t need to record anything except the inputs!
This is exactly a replay engine (or I guess you could say replay engines are deterministic simulators). How do you think you replay a recording except with a deterministic execution system that injects the non-deterministic inputs at precise execution points? This is literally how all replay engines work. Furthermore, how do you think recordings work except by recording the inputs? That is literally how all recording systems designed to feed replay engines work. The only distinction is what constitutes non-determinism in a given context. At the whole hypervisor level, it is just I/O into the guest; at the process level, it is just system calls that write into the process; at the threading level, it is all writes into the process. These distinctions are somewhat interesting at a implementation level, but do not change the fundamental character of the solution which is that they are all a replay engine or deterministic simulator, whatever you want to call it.
Re: Debugging in the Multiverse
#56Earlier quoted context omitted.
From the little I have seen, most programming language folks don't seem to care much about debugging. They care a lot about bugs not happening in the first place, which is good, testability is sometimes taken in consideration, but not much about what to do after a bug happened. No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the b…
Coming out of the games industry, I am constantly amazed by how rarely people outside of games use debuggers. And, how slow they are to debug everything because of that...
And Antithesis is (theoretically) one solution to that, which is very neat!
(I know modern games are also often operating in a distributed environment, but to generalize very broadly, there’s a lot more happening “in one place”)
Re: Debugging in the Multiverse
#57It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
From the little I have seen, most programming language folks don't seem to care much about debugging. They care a lot about bugs not happening in the first place, which is good, testability is sometimes taken in consideration, but not much about what to do after a bug happened. No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the b…
If the spec is written in the language itself, then some languages certainly will.
See Lean, Rocq, Isabelle, etc
Re: Debugging in the Multiverse
#58Re: Debugging in the Multiverse
#59Antithesis employee here. Happy to jump in and answer any burning questions people might have about multiverse debugging.
Re: Debugging in the Multiverse
#60Earlier quoted context omitted.
From the little I have seen, most programming language folks don't seem to care much about debugging. They care a lot about bugs not happening in the first place, which is good, testability is sometimes taken in consideration, but not much about what to do after a bug happened. No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the b…
> No language will prevent you from misimplementing the specs If the spec is written in the language itself, then some languages certainly will. See Lean, Rocq, Isabelle, etc