The gist of it is that we intercept the Rust linking phase and then drive `rustc` manually. There's some diffing logic that compares assembly between compiles and then a linking phase where we patch symbols against the running process. Works across macOS, Windows, Linux, iOS, Android, and WASM. On my m4 I can get 130ms compile-patch times, quite wicked stuff.
We handle the hard parts that the traditional dylib-reloading doesn't including TLS, statics, constructors, etc.
I've been posting demos of it to our twitter page (yes twitter, sorry...)
- With bevy: https://x.com/dioxuslabs/status/1924762773734511035
- On iOS: https://x.com/dioxuslabs/status/1920184030173278608
- Frontend + backend (axum): https://x.com/dioxuslabs/status/1913353712552251860
- Ratatui (tui apps): https://x.com/dioxuslabs/status/1899539430173786505
Our unfinished release notes are here:
https://github.com/DioxusLabs/dioxus/releases/tag/v0.7.0-alp...
More details to come!
Edit: or, I guess since this doesn't seem to be something intended for use in prod, maybe that's not necessary. You can just bloat the runtime process more or less indefinitely.
I was curious because IIUC Linux kernel livepatches handle this via something related to RCU, which I guess is not possible in this context.
It's a little specific to how dioxus uses axum today, but we plan to release an axum-only integration in the future.
Basically, julia is dynamically typed, but inside a function it acts like a statically type language within a fixed world-age. So that means that based on the input types to a function, the compiler is able to know that the method table is not allowed to change, const-global, and types also can't change.
Between world-ages however, anything goes. You can redefine methods, redefine structs, etc. What's especailly nice is that old data doesn't become invalid, it's just living in an old world, and if you get a Foo struct you can know what world it comes from.
We have an invokelatest and invoke_in_world functions for advancing the world-age inside functions, and users creating something like an event loop just wrap their event loop iterations in an `invokelatest` and suddenly everything hot reloads automatically as you change code in your editor.
From the docs Subsecond looks almost perfect. The only downside I found is that (if I understood correctly) you have to modify the function call in the source code of every function you want to hotpatch.
It is a bit mitigated in that the change does not cost anything in release builds, but it still is a big thing. Do I want sprinkle my code with call for every function I might potentially have to patch in a debugging session?
Currently Dioxus and Bevy have subsecond integration so they get automatic hot-patching without any end-user setup.
We hope to release some general purpose adapters for axum, ratatui, egui, etc.
As someone who used a lot of hotpatching and now can't...
This isn't aimed at production, but ... Hotpatching is essential to update code without losing program state. A lot of people work in http request/response stuff and program state lasts the duration of the request/response; you don't usually need hotpatching for that unless your responses are very long --- there's lots of ways to swap in new code where requests after some time hit the new code and requests that started in old code finish and that's usually what you want.
If you've got something with long requests and you might want to change things during the request, hot patching is needed. If you've got something with long running connections or some other elaborate session, hot patching eliminates a lot of disconnect/reconnect session movement and lets you get everything running on the new version with a lot less hassle; as long as you accept the hassles of hot patching.
The goal is that frameworks just bake `subsecond::current` into their `tick()` function and end-users get hot-patching for free.
Also, didn't the article say explicitly that struct layout changes aren't supported??
Metaprogramming that maintenance burden seems like it should be relatively straight-forward, if you've written a linker already.
I looked into liveplusplus a lot and their unreal integration also requires a broker to get the most out of it. If you're building a game engine and want to support struct layout and alignment changes, you'll need to do some re-instancing. Hiding a `subsecond::call` deep in the bowels of the host framework hides it from the user and lets the framework handle any complicated state management it needs during hotpatches.
I wouldn't say it's purity - the first version of subsecond actually did do in-process modification - but after playing around with it for a while, I much preferred the light runtime integration. The dioxus integration was about 5 lines of code, so it's quite minimal.
My current day job @ Gel has me working on a Rust socket frontend for some pretty complex code and that could also be pretty interesting.
It seems to require that you choose a good "cutover" point in your codebase, but TBH that's probably not too hard to pick. The HTTP service handler in a webserver, the socket handlers in non-web serving code, etc.
It does appear to have a limitation where it will only allow the main crate to be hotpatched. That's less than ideal, but I suppose the convenience might justify some code structure changes to allow that.
https://docs.rs/subsecond/0.7.0-alpha.1/subsecond/index.html...
"In practice, frameworks that implement subsecond patching properly will throw out the old state and thus you should never witness a segfault due to misalignment or size changes. Frameworks are encouraged to aggressively dispose of old state that might cause size and alignment changes."
https://www.erlang.org/docs/24/man/gen_server#Module:code_ch...
Perhaps I'm missing something, maybe subsecond is a good tool for toy apps or for a developer workflow. But for anything serious, I'd think that managing layout of structs is a primary concern.
That being said, bevy is using bevy-reflect to implement proper struct hot-reloading between hot-patches.
debug_assertions is usually only enabled in the development phase (release build default to debug_assertions=false), so yes this is not intended for production workloads
makes it sound like it's actually not super rust specific, just a ton of squinting at assembly dumps. I do wonder if there are some "reproducible builds" traps hiding in this, but maybe it just needs to be selective about what it patches, and that turns out to be the really hard problem
I didn't follow the tick() problem cited elsewhere, but my mental model is that, sure, one should not patch currently executing code without expecting "well that didn't do what I wanted" type shenanigans
[1] https://github.com/andreivasiliu/demimud/tree/master/netcore