4 ms·
One aspect of virtual threads that has gone somewhat unappreciated so far is that if you (ab)use some internal APIs you can probably implement the testing techn
by mike_hearn 3y ago
One aspect of virtual threads that has gone somewhat unappreciated so far is that if you (ab)use some internal APIs you can probably implement the testing technique used by FoundationDB.
For those who don't know, FoundationDB is a horizontally scalable transactional (KV) database used by Apple for their cloud services. It's famous primarily for its testing approach in which they can run the entire set of microservices in a simulator that can both inject faults, but also completely control the scheduling of work. In this way they make the system entirely deterministic, and can then pseudo-randomize simulations to uncover race conditions and the like.
To do this they created a custom DSL on top of C++ called Flow which is compiled to coroutines.
https://www.youtube.com/watch?v=4fFDFbi3toc https://www.youtube.com/watch?v=4fFDFbi3toc
Flow and what it enables is considered (by them at least) to be a key competitive advantage over other database engines.
With Loom the JVM now happens to support the very same thing, just not officially. That's because the JVM makes file and network IO fully "pluggable", virtual threads can be supplied with a custom scheduler, and classloaders can be used to run multiple programs within the same JVM (with some caveats). So if you wanted to make a deterministic simulation of your microservice based system then you could do that now.
The above would be a rather advanced project for intrepid developers only, but it'd be interesting to see someone explore that at some point.
- slantedview 3y agoInteresting idea. Are there any implementations of this sort of thing in the wild?
- deleted 3y ago[deleted]
- papercrane 3y agoIt was explored a bit in a blog article with some sample code. One big issue with this approach right now is that the scheduler is not officially user replaceable. It's possible using reflection to do so though, at least is was in 2022, the internal code may have changed since then. There's been some indication from the OpenJDK team that this might be an officially supported feature in the future. Blog article: https://jbaker.io/2022/05/09/project-loom-for-distributed-systems/ https://jbaker.io/2022/05/09/project-loom-for-distributed-sy... HN discussion: https://news.ycombinator.com/item?id=31314006 https://news.ycombinator.com/item?id=31314006
- _benedict 3y agoCassandra has a deterministic testing framework in this vein that will support Loom before too long. Loom is more of an efficiency enhancement, however, permitting you to run a simulation with a single operating system thread, avoiding the overhead of managing which thread the OS is permitted to run. The framework already intercepts all of these operations and ensures they are executed deterministically.
- bbatha 3y agoRust's tokio has a project called loom as well which can do permutation testing of async code: https://github.com/tokio-rs/loom https://github.com/tokio-rs/loom
- _a_a_a_ 3y agoIsn't that a kind of half baked, guaranteed-incomplete kind of model checking?
- jsmith45 3y agoSure. That is not the sort of thing that is guaranteed to catch all bugs. Model checking approaches are better at providing proofs of non-trivial properties. The problem is that model checking checks a model which often fails to properly match the actual implementation. Plenty of people have used model proven algorithms but had implementation bugs that mean that the highly desired properties proven for the model are not upheld. Being able to automatically check the implementation against specific race conditions (etc.) helps to provide confidence in the implementation working correctly, which means your model proven results are more likely correct for the actual implementation.