This looks awesome for game development! Short feedback loops are a superpower.
Hot-code reloading on macOS/arm64 with Zig
21–30 of 57 posts
Re: Hot-code reloading on macOS/arm64 with Zig
#22Why not simply use MAP_JIT? There is no need to do these weird tricks, plus you’re putting your process and the rest of the system at risk by elevating privilege and using task-for-pid.
Hey, author of the article here. Thanks for the suggestion! I actually didn't know about the MAP_JIT flag to mmap before and will defo consider it. As to elevating your privs - this is just a temp solution until I work out how to add this entitlement https://developer.apple.com/documentation/bundleresources/en... to the Zig compiler. I wrote the default Zig's MachO linker from scratch and it can embed the adhoc code…
I was just thinking to myself, “The author probably didn’t know about MAP_JIT…” after reading the parent comment. I sure didn’t know about it.
There’s just so much software out there and so many little bits of information one can gather.
Re: Hot-code reloading on macOS/arm64 with Zig
#23Earlier quoted context omitted.
It is a bit crazy if you do it for hot code reloading, though, as the logic has now changed. In the case of JIT, it may swap the bytecode but the flow of execution remains the same. Hot code reloading usually requires a different approach.
In the case of JIT, it may swap the Bytecode but the flow of execution remains the same. Are you able to elaborate on this further? 1a. Does this mean the process gets restarted during reload? 1b. If no restart, how are active threads handled? What if a thread should no longer exist post-reload?
JITs don’t need to reload code, they run the same code and tier it up to an optimized implementation when it gets hot. No execution context is lost, at least semantically.
Re: Hot-code reloading on macOS/arm64 with Zig
#24Earlier quoted context omitted.
In the case of JIT, it may swap the Bytecode but the flow of execution remains the same. Are you able to elaborate on this further? 1a. Does this mean the process gets restarted during reload? 1b. If no restart, how are active threads handled? What if a thread should no longer exist post-reload?
JITs don’t need to reload code, they run the same code and tier it up to an optimized implementation when it gets hot. No execution context is lost, at least semantically.
> JITs don’t need to reload code
If I've inlined a method, and someone redefines that method in a language that allows that, then I'm going to need to reload that code.
Re: Hot-code reloading on macOS/arm64 with Zig
#25This looks awesome for game development! Short feedback loops are a superpower.
I have implemented live reload (in a much simpler and naive way) for my little game engine/framework written in C a few years ago, as a "scene" is essentially a reloadable shared library there. When it worked it was a huge productivity booster and time saver indeed, but I've eventually stopped using this feature that much once I started relying more and more on passing function pointers around as callbacks - so things break pretty bad when the function address changes. I had some ideas on how to tackle that, but never got around to implementing it so far. Language level support looks very neat.
Re: Hot-code reloading on macOS/arm64 with Zig
#26This looks awesome for game development! Short feedback loops are a superpower.
This is exactly what I'm aiming to use Zig for: I'm working on a game engine in Zig[0] that I hope to leverage hot code reloading with
Re: Hot-code reloading on macOS/arm64 with Zig
#27This seems like it would just crash or make your program get into an inconsistent state. What happens if you are executing a transaction but mid transaction your binary gets updated and your transaction now has done half of what's needed by the old version and half of what's needed by the new version. I don't think it would be that hard to get into an inconsistent state.
Yeah, I've never been a huge fan of hot-code reloading for that reason -- when I'm writing code I'm often trying to get something stable, and if it's having funky issues I don't want to be second-guessing whether it's the HCR or my own error. I've never found a HCR that's stable enough for me to not have that worry, and I don't think it's possible for the reason you mentioned.
Re: Hot-code reloading on macOS/arm64 with Zig
#28I love the feature but I am a little worried about how much more complex it would make the toolchain. How many extra LOC does this add to the compiler and linker (and how big are they now)?
It's a great feature that might become one of the killer features of zig, among others. Very much worth the extra complexity.
Re: Hot-code reloading on macOS/arm64 with Zig
#29Earlier quoted context omitted.
JITs don’t need to reload code, they run the same code and tier it up to an optimized implementation when it gets hot. No execution context is lost, at least semantically.
> JITs don’t need to reload code If I've inlined a method, and someone redefines that method in a language that allows that, then I'm going to need to reload that code.
Yes, but if a called function redefines its own parent, it still returns to the old code, not the new code.
Re: Hot-code reloading on macOS/arm64 with Zig
#30This looks awesome for game development! Short feedback loops are a superpower.
If you watch some of Notch’s old game jam live streams; this is exactly how he used his Java environment and is probably why he was so invested in it.
You can see some examples here when he just tests logic changes:
(Though, he restarts often since he’s editing preloaded assets also)