Can we have the same for Go, pretty please?
[deleted]
Subsecond: A runtime hotpatching engine for Rust hot-reloading
21–30 of 41 posts
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#22Interesting, but the documentation makes it sound like you have to preemptively wrap all the code you think you might want to change in a special wrapper "call" function. If true that makes this a lot less appealing than existing solutions for other languages that can modify any function without special annotations.
This is less worse than it sounds. The stuff I need hot reloading for is less than 5% of the total code base. It is usually stuff that I can't debug (ie: API response). So I am back and forth re-compiling. If I can get hot-reloading for that, that's a 95% time improvement for me. I could live with re-compiling for the rest of the code.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#23Neat but I would prefer simply using a dylib for the part of my code that I want to be reloadable.
I've used this for a toy game I was once working on [1], and it works pretty well for a while, but the problem is that sometimes the OS decides that your dlclose will be a no-op. I haven't ever found a way to force the OS to unload it, sometimes it just keeps it there.
[1] https://github.com/andreivasiliu/demimud/tree/master/netcore
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#24About structs:
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.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#25Creator here - haven't had a chance to write up a blog post yet! Stay tuned. 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, q…
The axum example looks amazingly useful! Very cool project and idea.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#26About structs: 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." I don't think "throwing out the old state" is a sensi…
It’s a developer tool to speed up rust iteration, not a production tool like erlang.
That being said, bevy is using bevy-reflect to implement proper struct hot-reloading between hot-patches.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#27About structs: 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." I don't think "throwing out the old state" is a sensi…
> Subsecond is only enabled when debug_assertions are enabled so you can safely ship your application with Subsecond enabled without worrying about the performance overhead.
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
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#28I would recommend looking into how julia handles code reloading with our builtin infrastructure and the Revise.jl package. Basically, every method to a function and as of v1.12 (currently in beta), every binding and struct definition has a "world-age" associated with it.
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.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#29Creator here - haven't had a chance to write up a blog post yet! Stay tuned. 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, q…
[How] do you track when it's safe to delete the old version of a patched piece of code?
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.
Re: Subsecond: A runtime hotpatching engine for Rust hot-reloading
#30Creator here - haven't had a chance to write up a blog post yet! Stay tuned. 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, q…
[deleted]