←back to thread

383 points hkalbasi | 2 comments | | HN request time: 0.431s | source
Show context
devit ◴[] No.42814926[source]
I think the optimal approach for development would be to not produce a traditional linked executable at all, but instead just place the object files in memory, and then produce a loader executable that hooks page faults in those memory areas and on-demand mmaps the relevant object elsewhere, applies relocations to it, and then moves it in place with mremap.

Symbols would be resolved based on an index where only updated object files are reindexed. It could also eagerly relocate in the background, in order depending on previous usage data.

This would basically make a copyless lazy incremental linker.

replies(9): >>42815042 #>>42815180 #>>42815279 #>>42815434 #>>42815474 #>>42815621 #>>42815660 #>>42815894 #>>42815895 #
fsfod ◴[] No.42815180[source]
You can sort of do that with some of LLVM's JIT systems https://llvm.org/docs/JITLink.html, I'm surprised that no one has yet made a edit and continue system using it.
replies(2): >>42815305 #>>42817971 #
1. all2 ◴[] No.42815305[source]
My parens sense is tingling. This sounds like a lisp-machine, or just standard lisp development environment.
replies(1): >>42824092 #
2. klibertp ◴[] No.42824092[source]
Maybe of interest: https://github.com/clasp-developers/clasp/ (Lisp env. that uses LLVM for compilation; new-ish, actively developed.) However, my impression (I didn't measure it) is that the compilation speed is an order of magnitude slower than in SBCL, never mind CCL.