Activity

1. gopherbot

   added

   Proposal

   on Mar 17, 2026
2. gopherbot

   added this to the Proposal milestone on Mar 17, 2026
3. carli2

   added 2 commits that reference this issue on Mar 17, 2026

   runtime/jit: add user frame support for JIT compilers and VMs

   ...

   This issue will close once commit 96cc45b is merged into the 'master' branch.

   96cc45b

   runtime/jit: add user frame support for JIT compilers and VMs

   ...

   This issue will close once commit 3698617 is merged into the 'master' branch.

   3698617
4. gabyhelp commented on Mar 17, 2026

   

   gabyhelp

   on Mar 17, 2026

   More actions

   Related Issues

   • runtime: "unexpected return pc" with JIT-generated code #20123 (closed)
   • runtime: expose morestack (or equivalent) to make calling into JIT'ed code easier (and less hacky) #29857
   • runtime: rewrite gentraceback as an iterator API #54466 (closed)

   _{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}
5. gabyhelp

   added

   LibraryProposalIssues describing a requested change to the Go standard library or x/ libraries, but not to a toolIssues describing a requested change to the Go standard library or x/ libraries, but not to a tool

   on Mar 17, 2026
6. prattmic commented on Mar 19, 2026

   

   prattmic

   on Mar 19, 2026

   Member

   More actions

   The most critical aspect of traceback is that it precisely traces all Go frames and jumps past foreign frames in the case of calls from Go to foreign code and back then back to Go. Without this, the GC cannot scan all Go stack frames.

   It's not clear to me how your proposal achieves this (looking at your implementation is it that Region.Next is required to correctly report the Go caller into the region?).

   The second important aspect of calling foreign synchronization is coordination with the Go scheduler to ensure we can promptly preempt goroutines running foreign code. Your proposal doesn't cover this at all. It is a bit of a separate concern, but it is a prerequisite for safely running foreign code.

   The cgo call infrastructure in the Go runtime (runtime.cgocall, runtime.cgocallback) already handles both of these cases. Despite c in the name, the runtime support is not specific to C, it is really about calling any foreign.

   From that perspective, I don't see C code and JIT code as fundamentally different. Both are foreign to the runtime, and in my opinion should go through the same interface.

   For symbolization, once you are using cgo we already have an interface for symbolization via runtime.SetCgoCallback, though the API is admittedly awkward.

   The final hurdle I see is that today actually calling something via runtime.cgocall without reaching into the runtime does require using import "C" and thus the cgo portion of the toolchain, which is a bit annoying if you don't actually otherwise need C. We have recently been thinking more about an ability to call foreign functions without the cgo toolchain, along the lines of #38917. That is quite hard for dynamically linked C code, but completely standalone JIT'd code would presumably be more straightforward.

   ❤️React with ❤️2Reacted by Tom Thorogood and Marcos Alcantara
7. carli2 commented on Mar 19, 2026

   

   carli2

   on Mar 19, 2026

   Author

   More actions

   Thanks for the detailed feedback, @prattmic!

   On traceback precision and Region.Next:

   Yes, Region.Next is exactly the mechanism that reports the Go caller. When the unwinder encounters a PC inside a registered region, it calls Next(pc, sp) which returns the caller's PC/SP — typically read from a shadow stack or a known location where the JIT trampoline saved the return address. The unwinder then continues from that Go frame as usual. This means every Go frame is precisely traced and every foreign frame is skipped, same guarantee as cgocall.

   On scheduler preemption:

   You're right that the current proposal doesn't cover this, and I agree it's a prerequisite. I've added preemption support — a lightweight cooperative Preempt() bool function that JIT code calls at safepoints (loop back-edges, function entries). It reads gp.preempt directly from the current goroutine with no synchronization overhead. When it returns true, JIT returns to Go, and the function prologue handles the actual yield.

   The goroutine stays in _Grunning while executing JIT code. The GC/scheduler set gp.preempt = true before sending async preemption signals, so the flag is always visible to Preempt(). JIT code that frequently calls Go functions (like MemCP's per-row callbacks) doesn't need explicit checks — the Go function prologues already handle preemption.

   On using cgocall instead:

   I considered this path but don't think it's the right fit for JIT. The key differences:

   1. JIT code is not a black box. C code is opaque to the runtime — cgocall must assume the worst (save signal masks, release P, switch stacks). JIT code is generated by Go code and can cooperate with the runtime: it can embed safepoints, follow known calling conventions, and report pointer maps via callbacks. Treating it as opaque foreign code leaves performance on the table.

   2. cgocall can't scale to thousands of functions. A JIT compiler generates thousands of specialized functions at runtime (e.g., one per query plan, one per table schema). With cgocall, each of these would need to be wrapped as a cgo-callable function, and every Go callback from JIT code would need a corresponding cgocallback stub. The runtime/jit approach registers one region for the entire code arena and lets the JIT handle per-function dispatch internally.

   3. The overhead is prohibitive for our use case. MemCP JIT-compiles SQL query scans that call back into Go per row for column access. At millions of rows per second, the ~40ns per cgocall/cgocallback transition adds up fast. runtime/jit adds zero overhead when no regions are registered (single atomic load returning nil) and a single atomic load + binary search when regions exist — no syscalls, no P release, no stack switch.

   4. The cgo toolchain is unnecessary baggage. The JIT code is generated entirely in Go via mmap + direct machine code emission. Requiring import "C" and a C compiler just to satisfy the runtime's foreign-call interface adds build complexity for no benefit. You mentioned proposal: cmd/cgo: add support for pre-compiled cgo packages #38917 as a possible path, but that's been open since 2020 without a concrete design, and solving it for dynamically linked C is much harder than the JIT case.

   I see runtime/jit and cgocall as complementary, not competing: cgocall is the right interface for calling opaque pre-compiled C/foreign libraries. runtime/jit is the right interface for cooperative dynamically generated code where the generator and the runtime can work together.

   Updated implementation: The proposal and implementation now include Preempt() with tests. See the updated proposal and implementation.

   👍React with 👍1Reacted by Lucas de Souza Santos
8. glycerine commented on Apr 15, 2026

   

   glycerine

   on Apr 15, 2026

   Last edited by glycerine

   More actions

   I'm working on a JIT similar to https://github.com/libriscv/libriscv (C++) but in Go; so I am interested in support for JIT interposed code; and in avoiding CGO overhead.

   No allocation in callbacks: All callbacks run on the system stack and must not allocate Go memory.

   This is the hardest part of the proposal for me to grasp. First because it is almost impossible to avoid allocating in Go code while doing anything interesting. Second because the restriction to the system thread seems both hard to do and rather harshly restrictive. I'm not sure what this condition has to do with helping stack scanning runtime code; nor how to do anything interesting from JIT code calling back to Go code under this restrictive covenant.
9. glycerine commented on Apr 16, 2026

   

   glycerine

   on Apr 16, 2026

   More actions

   @carli2 I went looking for your Prempt() proposal, but it 404s (https://github.com/carli2/go/blob/jit-foreign-frames/proposal.md) can you update? thanks!
10. carli2 commented on Apr 16, 2026

    

    carli2

    on Apr 16, 2026

    Author

    More actions

    Proposal: runtime/jit — User Frame Support for JIT Compilers and VMs

    Author(s): Carl-Philip Hänsch

    Last updated: 2026-03-19

    Discussion at https://go.dev/issue/78189.

    Abstract

    We propose a new standard library package runtime/jit that allows
    programs to register regions of dynamically generated executable code
    (JIT-compiled code, WASM engines, embedded VMs) with the Go runtime.
    This enables Go's stack unwinder, panic/recover mechanism, and garbage
    collector to handle frames from such code gracefully instead of crashing
    with "unknown pc" or "unexpected return pc".

    Background

    Go compiles ahead of time (AOT). The runtime's stack unwinder
    (traceback.go) assumes every PC on the stack belongs to a Go function
    registered in moduledata at link time. When the unwinder encounters a
    PC that does not belong to any known module — for example, because a Go
    function was called from JIT-compiled code — it throws a fatal error:

    runtime: unexpected return pc for somefunc called from 0x7f4a12340010
    fatal error: unknown caller pc
    

    This affects any Go program that:

    • Embeds a JIT compiler (e.g., a database query engine compiling SQL to
      native code at runtime)
    • Hosts a WASM runtime that calls back into Go
    • Uses FFI with dynamic code generation (trampolines, thunks)
    • Embeds a scripting language VM (Lua, Scheme) that calls Go functions

    Today, the only workaround is to avoid calling Go functions from
    dynamically generated code entirely, or to use intermediate C frames
    via cgo (which adds overhead and requires the cgo toolchain).

    This problem has been reported in #20123
    ("runtime: unexpected return pc with JIT-generated code").

    Existing mechanisms

    Go already has partial support for non-Go frames via SetCgoTraceback,
    which registers callbacks for C frames in cgo binaries. However, this
    mechanism is specific to cgo: it relies on the cgocallback marker
    function and the g.cgoCtxt context stack. It cannot be used for
    arbitrary dynamically generated code.

    Proposal

    Add a new package runtime/jit with the following API:

    package jit
    
    // UnwindMode controls how the runtime handles user frames during
    // stack unwinding.
    type UnwindMode uint8
    
    const (
        // UnwindStop ends the traceback at the user frame boundary.
        UnwindStop UnwindMode = iota
    
        // UnwindSkip skips user frames and continues unwinding past them
        // using the Next callback. User frames do not appear in tracebacks.
        UnwindSkip
    
        // UnwindDeclare is like UnwindSkip, but user frames also appear
        // in tracebacks via the Describe callback.
        UnwindDeclare
    )
    
    // Region describes a range of executable memory containing user code.
    type Region struct {
        Start    uintptr
        End      uintptr
        Unwind   UnwindMode
    
        // Describe returns human-readable frame info for tracebacks.
        // Only called when Unwind is UnwindDeclare.
        // Must not allocate Go memory. May be nil.
        Describe func(pc uintptr) (name, file string, line int, ok bool)
    
        // Next returns the caller's PC and SP for a frame at the given
        // PC and SP. This allows the runtime to unwind past user frames.
        // Required for UnwindSkip and UnwindDeclare.
        // Must not allocate Go memory. May be nil for UnwindStop.
        //
        // The callback runs on the system stack during stack unwinding.
        // It receives:
        //   pc: the return address pointing into user code
        //   sp: the frame pointer of the Go callee
        // It returns:
        //   callerPC: the return address of the Go caller above the user frame
        //   callerSP: the SP of the Go caller
        //   callerBP: reserved for future use
        Next func(pc, sp uintptr) (callerPC, callerSP, callerBP uintptr, ok bool)
    
        // ScanStack is called during garbage collection to report Go
        // pointers held in user stack frames or shadow stacks.
        // Must not allocate Go memory. May be nil.
        ScanStack func(report func(ptr uintptr))
    }
    
    // Handle represents a registered user frame region.
    type Handle struct { /* unexported */ }
    
    // Register makes the runtime aware of a user code region.
    // The address range [Start, End) must not overlap with any previously
    // registered region or with Go text segments.
    func Register(r Region) Handle
    
    // Unregister removes the user frame region from the runtime.
    func (h Handle) Unregister()
    
    // Preempt reports whether the Go runtime is requesting the current
    // goroutine to yield (e.g., for garbage collection or scheduling).
    // JIT code should call this at regular safepoints and return to Go
    // when it returns true.
    func Preempt() bool

    Runtime changes

    Internally, the runtime maintains a sorted registry of user frame
    regions using a copy-on-write snapshot scheme:

    • Writers (Register/Unregister) allocate a new immutable snapshot
      via persistentalloc and publish it with an atomic pointer store.
    • Readers (findUserFrameRegion, called from the unwinder) load
      the snapshot pointer atomically. No lock is needed, which is critical
      because the unwinder runs on the system stack during signals and panics.

    The unwinder (traceback.go) is patched in two places:

    1. initAt(): When the initial PC is not in any Go module, check
       if it belongs to a user frame region. If the region provides a Next
       callback, use it to resolve the caller's PC/SP and continue unwinding
       from there.

    2. next(): When the return address (frame.lr) points into a
       user frame region, use Next to skip past the user frame and
       continue with the Go caller above it.

    Both paths fall back gracefully: if Next is nil or returns ok=false,
    the unwinder stops without crashing.

    Scheduler coordination

    When a goroutine runs JIT-compiled code, the Go scheduler must be able
    to preempt it for garbage collection and scheduling. Unlike opaque
    foreign code (C via cgo), JIT-compiled code is generated by Go code and
    can cooperate with the runtime. The Preempt function enables this
    cooperation.

    How it works:

    1. The goroutine remains in _Grunning status while executing JIT code.
       It keeps its P and is visible to the scheduler and GC like any other
       running goroutine.

    2. When the GC or scheduler wants to preempt the goroutine, it sets
       gp.preempt = true and gp.stackguard0 = stackPreempt, then sends
       an async preemption signal. These flags are set before the signal
       is delivered.

    3. JIT code checks these flags via Preempt() at regular safepoints
       (loop back-edges, function entries). When Preempt() returns true,
       the JIT code should return to its Go caller promptly.

    4. Once back in Go code, the function prologue's stack check detects
       stackPreempt and yields the goroutine to the scheduler.

    When Preempt is not needed:

    JIT code that frequently calls Go functions does not need explicit
    Preempt() checks. Each Go function call includes a prologue that
    checks for preemption. For example, a JIT-compiled SQL scan that calls
    Go functions per row is implicitly preemptible at each callback.

    Preempt() is primarily needed for tight JIT loops that do not call
    back into Go — for example, a pure-compute kernel that processes a
    batch of rows before returning.

    Why not cgocall:

    The runtime.cgocall mechanism transitions the goroutine to _Gsyscall
    status, which releases the P, saves/restores the signal mask, and
    switches stacks. This is appropriate for opaque C functions that may
    block and that the runtime cannot inspect. It costs ~40ns per transition.

    JIT code is different: it is generated by Go code, runs on the
    goroutine's behalf, and can cooperate with the runtime via Preempt().
    The cgocall overhead is unjustified, and its requirement for the cgo
    toolchain is unnecessary since JIT code is produced entirely at runtime.

    Arena-based design for efficiency

    A JIT compiler typically allocates code in large arenas (e.g., 2 MB
    mmap'd pages). Each arena is registered as one Region. The runtime
    only searches a small sorted list of arenas (typically < 10), not
    individual functions. Per-function metadata is the JIT's responsibility,
    accessed through the Next and Describe callbacks.

    Rationale

    Why not extend SetCgoTraceback?

    SetCgoTraceback is tightly coupled to cgo: it hooks into the
    cgocallback marker function and assumes the C/Go boundary follows
    cgo's calling convention. JIT code does not use cgo and does not
    produce cgocallback frames.

    Why not use moduledata?

    moduledata is an internal ABI contract between the Go compiler,
    linker, and runtime. It encodes pclntab, funcdata, stackmaps, and
    other structures whose format changes between Go versions. Requiring JIT
    compilers to produce valid moduledata would be extremely fragile and
    would couple them to Go's internal implementation details.

    Our approach uses high-level callbacks instead, letting the runtime
    evolve its internals freely while the JIT provides frame information
    through a stable public API.

    Why three unwind modes?

    • UnwindStop is the simplest and safest default. It prevents
      crashes without requiring the JIT to provide any frame metadata.
    • UnwindSkip enables panic/recover to work across JIT boundaries,
      which is essential for production use.
    • UnwindDeclare enables meaningful stack traces that include JIT
      function names, which is essential for debugging and profiling.

    Why callbacks instead of static tables?

    JIT compilers generate code at runtime and maintain their own metadata
    in various formats. A callback-based API lets each JIT provide frame
    information in whatever way is natural for its design, without imposing
    a specific table format.

    The callbacks have strict constraints (must not allocate, must not grow
    the stack) because they run on the system stack during unwinding.

    Compatibility

    This proposal adds a new package with no changes to existing public
    APIs. Existing programs are unaffected.

    The runtime/jit package would be covered by the Go 1 compatibility
    guarantee once released. The API is deliberately minimal: one type
    (Region), one enum (UnwindMode), one pair of operations
    (Register/Unregister), and one handle type (Handle).

    The internal runtime changes (unwinder patches) are additive: when no
    user frame regions are registered, the code path is a single atomic
    load returning nil, adding negligible overhead.

    Implementation

    The implementation is complete and available at:
    https://github.com/carli2/go/tree/jit-foreign-frames

    It has been validated in production use by the MemCP database engine,
    which uses runtime/jit to register JIT-compiled SQL query functions.

    Summary of changes

    File	Lines	Description
    runtime/userframe.go	~240	Region registry with COW snapshots, atomic reads, GC scanning
    runtime/traceback.go	+75	Unwinder patches in initAt(), next(), and traceback2() for Describe
    runtime/mgcmark.go	+5	Fixed root for ScanStack callbacks
    runtime/jit/jit.go	~170	Public API surface with GC-visible closure retention
    runtime/jit/jit_test.go	~500	15 tests covering all features
    runtime/jit/trampoline_*_test.go	~800	ISA-specific JIT trampolines for all 13 Linux architectures
    internal/goexperiment/flags.go	+3	JIT experiment flag
    api/next/20123.txt	14	Public API tracking

    Architecture support

    The runtime code (userframe.go, traceback.go) is pure Go with no
    architecture-specific logic. Tests include JIT trampolines for all
    architectures supported on Linux: amd64, arm64, 386, arm, riscv64,
    loong64, s390x, ppc64, ppc64le, mips64, mips64le, mips, mipsle.

    Gating

    The feature is gated behind GOEXPERIMENT=jit, following the
    established experiment pattern (internal/goexperiment/flags.go).
    All runtime/jit source files require //go:build goexperiment.jit.
    Without the experiment flag, the package is completely excluded from
    builds — no runtime overhead, no binary size increase.

    The runtime-internal code (userframe.go, traceback.go patches,
    mgcmark.go hook) is always compiled but has negligible cost when
    no regions are registered: a single atomic load returning nil.

    Release plan

    1. Go 1.28 (or next): land behind GOEXPERIMENT=jit for early adopters
    2. Go 1.29: promote to default-on if no issues found
    3. Go 1.30: remove experiment flag, fully stable

    Open issues

    1. Async preemption in JIT regions: The current cooperative
       preemption via Preempt() requires JIT code to check for preemption
       at regular intervals. If JIT code runs a tight loop without checking,
       GC stop-the-world is delayed until the next check. A future
       enhancement could extend the async preemption signal handler to
       recognize JIT regions and preempt them directly, similar to how Go
       code can be async-preempted at any safe point. This would require
       the JIT to mark unsafe instruction sequences (analogous to the
       compiler's unsafe-point annotations).

    2. Signal safety: The Next and Describe callbacks should
       ideally be callable from signal handlers (for SIGQUIT stack dumps).
       Currently, signal-context tracebacks that encounter user frames
       fall back to UnwindStop behavior because the callbacks may not
       be async-signal-safe. A future enhancement could add a SignalSafe
       flag to Region.

    3. Profiling integration: pprof currently does not know about
       user frames. Frames skipped by UnwindSkip are invisible to the
       profiler. A future enhancement could emit synthetic pprof locations
       for UnwindDeclare regions.

    4. Windows/Plan9 test coverage: The current tests use
       syscall.Mmap with MAP_ANONYMOUS, which is Unix-only. Tests
       need platform-specific allocation for Windows (VirtualAlloc)
       and may not be feasible on Plan9. The runtime code itself is
       platform-independent.

    👍React with 👍3Reacted by Sam, black23eep and Lucas de Souza Santos
11. glycerine commented on Apr 29, 2026

    

    glycerine

    on Apr 29, 2026

    Last edited by glycerine

    More actions

    I've drafted an alternative which I think is simpler and more general. I've requested early feedback on golang-dev to flush out any blindspots in the design.

    https://groups.google.com/g/golang-dev/c/mABYStr5aYs

    I don't want to hijack this thread any more than this mention, but I would appreciate @carli2 your thoughts there on whether the self-describing frame would work for your needs. I think it is strictly more general, while also exposing just a single extra API call in the runtime package, rather than an entirely new runtime/jit package.
12. carli2 commented on Apr 30, 2026

    

    carli2

    on Apr 30, 2026

    Author

    More actions

    I've drafted an alternative which I think is simpler and more general. I've requested early feedback on golang-dev to flush out any blindspots in the design.

    https://groups.google.com/g/golang-dev/c/mABYStr5aYs

    I don't want to hijack this thread any more than this mention, but I would appreciate @carli2 your thoughts there on whether the self-describing frame would work for your needs. I think it is strictly more general, while also exposing just a single extra API call in the runtime package, rather than an entirely new runtime/jit package.

    Have the golang maintainers already reviewed your proposal? I would switch to whatever variant which gets streamlined into official go. Having a JIT engine means >200% more performance on memcp (https://github.com/launix-de/memcp). But we can only activate this feature when go does not crash during GC runs.
13. carli2 commented on May 17, 2026

    

    carli2

    on May 17, 2026

    Author

    More actions

    What's the general plan to integrate this approach or a similar functionality? We need streamline golang integration for this feature ASAP. Otherwise we cannot publish our JIT feature in https://github.com/launix-de/memcp
14. glycerine commented on Jun 3, 2026

    

    glycerine

    on Jun 3, 2026

    More actions

    Hi @carli2 Carl-Philip, I did not get any feedback on my pre-proposal, so I don't have any further information at this time.
15. jerbob92 commented on Aug 19, 2026

    

    jerbob92

    on Aug 19, 2026

    More actions

    Strong +1 to this proposal, with a production use case and measurements, plus one capability I'd like to see explicitly in scope: recovering a synchronous hardware fault whose PC is inside a registered JIT region.

    Use case

    I maintain go-pdfium, which has a WebAssembly runtime based on wazero (a pure-Go wasm runtime with a JIT compiler), running a ~5 MB PDFium module. Hardware-fault-based wasm runtimes (wasmtime, V8, JSC) eliminate per-access memory bounds checks with virtual memory: reserve an 8 GiB PROT_NONE region per guest memory so that any u32 base + u32 offset + size lands inside it, commit only the actual memory, and let out-of-bounds accesses fault. The trap costs nothing until it happens.

    A pure-Go JIT cannot do this today, because a fault at a JIT PC is fatal:

    runtime: unexpected return pc for runtime.sigpanic called from 0x...
    fatal error: unknown caller pc
    

    debug.SetPanicOnFault only covers faults at Go PCs. And there is no signal-forwarding escape hatch: sigfwdgo forwards synchronous signals to a pre-installed C handler only when the fault occurs on a non-Go thread or inside a cgo call. JIT code executing on an ordinary goroutine fails that test, so even a constructor-installed C handler is never consulted.

    The measured cost

    Implementing guard-page memory in wazero and benchmarking PDFium-compiled-to-wasm over a corpus of real PDF documents (Apple M5, benchstat n=6, interleaved): removing per-access bounds checks is worth −22% geomean render time, up to −37% on image-heavy documents, moving the workload from ~2.04× to ~1.6× the speed of the equivalent native library. SSA-level check elision can't recover most of this: the hot accesses are dynamic base + induction-variable addresses in pixel loops, fresh values every iteration.

    We have a working proof of concept of the only route available today (jerbob92/wazero#2, with the full design, benchmarks, and rationale): an opt-in cgo package whose C handler, installed after runtime init (interposing in front of the Go runtime and chaining back to it, per the os/signal rules), classifies the fault and rewrites the ucontext PC to a JIT-compiled trap-exit sequence. It works (the full WebAssembly spec test suite passes, with every out-of-bounds trap assertion going through the hardware fault path), but it isn't something we're eager to actually ship: it drags cgo into otherwise pure-Go programs and it's exactly the kind of runtime-version-sensitive machinery this proposal could obsolete. It's also hard to see it ever landing upstream: wazero's headline promise is literally "It has zero dependencies, and doesn't rely on CGO", so a cgo-based handler runs against the project's core identity even as an opt-in. Native runtime support would make the cgo approach unnecessary before it ever reaches users.

    The ask: specify (and test) fault-at-JIT-PC recovery, which the design may already cover

    Having read the design doc: the fatal error in our scenario occurs in the panic unwinder, which this proposal patches. Concretely, with debug.SetPanicOnFault enabled, a SIGSEGV at a JIT PC today does get sigpanic injected; the process then dies in (*_panic).nextFrame → unwinder.next on the JIT return PC, i.e. exactly the traceback.go path the proposal fixes. So the composition

    guard fault at a PC inside a Region (UnwindSkip) + SetPanicOnFault + Next mapping the JIT frame to its Go caller → recoverable panic in the Go frames below

    should work with the proposal as written, no new API needed. For wazero, Next is straightforward and allocation-free: our entry trampoline records the Go caller's PC/SP in a per-call execution context, so Next(pc, sp) is a lookup keyed by the (separate) wasm stack the fault occurred on. And panic-based recovery is fully sufficient here: an out-of-bounds trap is the guest's error path, so its cost is irrelevant.

    What I'd ask is that this becomes specified behavior rather than an emergent one, since today it hangs on incidental details:

    1. The doc's Next contract says sp is "the frame pointer of the Go callee", but in the fault case there is no Go callee; the innermost frame is the interrupted JIT frame (with sigpanic synthesized above it). It would help to specify what pc/sp a Region receives in that case (the interrupted PC and SP, presumably).
    2. That sigpanic injection happens at all for a non-Go PC is, as far as I can tell, not documented behavior. The proposal could state: a synchronous memory fault at a PC inside a registered region, with SetPanicOnFault enabled, produces a recoverable runtime.Error panic (and keep today's fatal behavior for unregistered PCs, so wild jumps still crash loudly).
    3. A test for exactly this sequence (fault inside a registered region, recover in the Go caller below) would pin the behavior. Happy to contribute it: the wazero guard-page PR (jerbob92/wazero#2) is a complete, working consumer (currently via the cgo handler) that we could port to GOEXPERIMENT=jit to validate the whole path end to end, with the benchmark corpus above.
16. carli2 commented on Aug 31, 2026

    

    carli2

    on Aug 31, 2026

    Author

    More actions

    Implementation/status update from MemCP

    The maintained implementation now lives in the project organization rather than only in a personal fork:

    • Go fork: https://github.com/launix-de/go
    • current Go 1.27 patch branch: https://github.com/launix-de/go/tree/jit-foreign-frames-go1.27.0
    • production consumer: https://github.com/launix-de/memcp
    • MemCP build documentation: docs: explain experimental JIT build launix-de/memcp#686

    The runtime side is implemented, not merely a design sketch. The branch provides registered foreign/JIT frame regions, precise stack-map scanning for pointers held by JIT frames, cooperative preemption state, and a dynamically growing region registry. On the published branch, GOEXPERIMENT=jit go test runtime/jit and GOEXPERIMENT=jit go test runtime both pass with the patched go1.27.0-X:jit toolchain.

    MemCP now uses this facility for native Scheme code generation, including query-planner code loaded through its normal import path and native self recursion. Current measurements on the MemCP integration show:

    • a self-recursive JIT microbenchmark improving by roughly 30–33x, with allocations dropping from 1,543 to 1;
    • the complete MemCP Scheme and SQL regression workload completing in 8m31s with JIT enabled, versus the usual 11–13 minutes without JIT, approximately 1.29–1.53x end-to-end.

    These are deliberately two different measurements: the microbenchmark shows the attainable gain once interpretation and call overhead disappear, while the full-suite result includes startup, storage, HTTP, parsing, and tests that are not yet JIT-dominated. The remaining MemCP work is expanding JIT coverage and fusing parser/query pipelines, not proving that the runtime API can work.

    The integration is safely gated. MemCP's runtime integration is selected only by the goexperiment.jit build constraint. A build with the official unpatched Go compiler remains valid and uses the interpreter; JIT code is inactive. Setting GOEXPERIMENT=jit requires the patched fork today because vanilla Go does not yet define the experiment. This is exactly why landing the already implemented runtime support behind an official Go experiment would be valuable: real consumers could test and iterate without maintaining a compiler fork, while default Go builds would remain unaffected.
17. carli2 commented on Aug 31, 2026

    

    carli2

    on Aug 31, 2026

    Author

    More actions

    Follow-up: the upstream merge candidate is now based on current golang/go master, not on the Go 1.27 release snapshot: #81237. The jit-foreign-frames-go1.27.0 branch remains only the reproducible compiler branch used by MemCP; jit-foreign-frames-master is the reviewed/mergeable line. Porting to master also exposed and fixed caller-frame-pointer relocation during JIT stack growth, and the master-based runtime/jit and runtime test suites pass.
18. carli2

    added a commit that references this issue on Sep 2, 2026

    runtime/jit: add user frame support for JIT compilers and VMs

    ...

    This issue will close once commit dc3807d is merged into the 'master' branch.

    dc3807d
19. gopherbot commented on Sep 2, 2026

    

    gopherbot

    on Sep 2, 2026

    Contributor

    More actions

    Change https://go.dev/cl/826384 mentions this issue: runtime/jit: add user frame support for JIT compilers and VMs
20. carli2

    added 3 commits that reference this issue on Sep 3, 2026

    runtime/jit: harden nested frame and tail layouts

    ...

    946caf2

    runtime/jit: add user frame support for JIT compilers and VMs

    ...

    b040cd9

    runtime/jit: harden nested frame and tail layouts

    ...

    8408466
21. carli2 commented on Sep 6, 2026

    

    carli2

    on Sep 6, 2026

    Author

    More actions

    The proposal body has now been rewritten to match the current implementation.
    In particular, the old Next and ScanStack callback design has been replaced
    by copied, declarative StackMap metadata, so GC stack scanning and stack
    relocation do not call JIT-owned code. The text now also covers split-stack
    checks, cooperative preemption, nested generated frames, and the current
    production consumer.

    The merge candidate has been rebased onto current Go master. On linux/amd64,
    GOEXPERIMENT=jit go test runtime/jit, GOEXPERIMENT=jit go test runtime, and
    GOEXPERIMENT=jit go test cmd/api pass. The runtime/jit test package also
    cross-compiles for all architectures covered by its trampolines on Linux and
    for 386, amd64, and arm64 on Windows.

    Two scope questions are called out explicitly in the revised proposal:

    1. whether the precisely typed variable-tail allocation API used by MemCP's
       JIT closure environments should stay in this proposal or be split out; and
    2. whether recovery from a synchronous hardware fault at a generated PC should
       be specified and tested here or in a follow-up.

    The code review remains at https://go.dev/cl/826384.
22. carli2

    added 2 commits that reference this issue on Oct 9, 2026

    runtime/jit: add user frame support for JIT compilers and VMs

    ...

    This issue will close once commit 7a41846 is merged into the 'master' branch.

    7a41846

    runtime/jit: harden nested frame and tail layouts

    ...

    This issue will close once commit ee8735a is merged into the 'master' branch.

    ee8735a
23. carli2 commented on Oct 9, 2026

    

    carli2

    on Oct 9, 2026

    Author

    More actions

    @prattmic, following up on your earlier concerns: MemCP has now used this JIT integration in production for several months, and it has proven stable in that workload.

    The implementation has evolved since your feedback. Generated code now publishes declarative unwind recipes and precise pointer maps. The runtime uses these to reach enclosing Go frames, scan generated frames, and relocate their pointers during stack growth, including consecutive JIT frames.

    Scheduler coordination is cooperative: generated loops check Preempt at safepoints and return to Go when requested; calls into Go also reach its stack/preemption checks. This relies on the JIT honoring those safepoint obligations.

    The updated implementation is in https://go.dev/cl/826384 (GitHub PR #81237). The branch has just been rebased onto current Go master. On linux/amd64, the runtime/jit, runtime (with and without JIT), cmd/api, and runtime/jit race tests pass.

    Would these contracts address your concerns, or are additional guarantees or tests needed?