Pull Request: Implement Dynamic Runtime JIT Compiler Core#15
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR closes #4 transitioning the ORCHID execution daemon from a static, disk-bound Ahead-of-Time (AOT) compiler to a dynamic, memory-resident Just-In-Time (JIT) compilation subsystem. It completely eliminates the runtime dependency on the GCC compiler toolchain and writing temporary files to disk, while introducing multi-tier SIMD hardware dispatch capability to maximize performance on edge hardware.
Technical Details & Architecture
1. In-Memory JIT Compilation Subsystem (
jit/)syscall.Mmapwith write permission (PROT_READ|PROT_WRITE). Once the byte instructions are written, the page protection is transitioned to read-execute (PROT_READ|PROT_EXEC) viasyscall.Mprotectbefore calling, ensuring no page is ever concurrently writable and executable.jit_amd64.s): Maps standard Go parameter structs directly to AMD64 SysV ABI registers (RDI,RSI,RDX) and jumps execution directly to the dynamically allocated page pointer.2. Multi-Tiered Hardware Emitters (
jit_amd64.go)zmm) and 16-way integer strides when native AVX-512 capability is detected.ymm) and 8-way integer strides. It utilizes direct memory broadcasts (vpbroadcastd (%rdi,%rax,4), %ymm0) to remain 100% VEX-encoded, preventing invalid instruction crashes (SIGILL) on host CPUs lacking AVX-512 support.jit_arm64.go/jit_other.go): Implements Go-native fallback runners to guarantee execution stability and mathematical parity on non-x86_64 target architectures.Verification & Performance Metrics
1. Compilation Overhead
The JIT compiler emits and loads the executable kernel in-memory in ~20–55 microseconds, a massive reduction from the AOT compile and plugin loading pipeline which took hundreds of milliseconds.
2. Locality Benchmark Performance (AVX2 Mode)
Running the locality cache benchmark sweeps under the vectorized JIT engine yields a median speedup of ~11.5x:
3. Repository Integration & Checks
go test -v ./...docs/ARCHITECTURE.mdand rootREADME.md.