jolt/jolt-core/jolt
Dmitri Sotnikov a31c1af8c4
Devirt: cache the resolved impl in a per-site cell (inline cache) (#237)
A devirtualized protocol call resolved its impl with devirt-resolve on EVERY call
— but the tag/proto/method are compile-time constants, so the resolved fn is a
runtime constant (closed world). That per-call find-protocol-method (three
hashtable lookups) was the cost: on mono-dispatch, dispatch was ~75% of the time
(ablation: same arithmetic direct-call 166ms vs dispatch 673ms).

Resolve once. When emitting a direct-link def, each devirt site gets a fresh cache
cell, bound to #f in a let wrapping the def (so it persists across calls and is
shared by every invocation); the site resolves into it on first use ((or cell
(let ((_f (devirt-resolve ..))) (set! cell _f) _f))) and reuses it after — the
inline cache the JVM gets for free. First call still passes the real receiver, so
the Object/host-tag fallback (devirt-resolve) is unchanged.

mono-dispatch 673ms -> 214ms (~3.15x), 47.5x -> ~15x JVM, near the 166ms
direct-call floor. run-devirt.ss gains the cached-path checks (cell present, 1st
call caches + 2nd reuses, both == dispatch). make test / shakesmoke green, selfhost
holds, 0 new divergences.

Co-authored-by: Yogthos <yogthos@gmail.com>
2026-06-26 18:34:13 +00:00
..
passes Nilable record types + flow-sensitive nil narrowing (#235) 2026-06-26 17:16:16 +00:00
analyzer.clj Source locations: reader positions, error locations, native stack traces (#218) 2026-06-26 02:14:34 +00:00
backend_scheme.clj Devirt: cache the resolved impl in a per-site cell (inline cache) (#237) 2026-06-26 18:34:13 +00:00
deps.clj host interop + deps fixes for running ring-defaults on jolt 2026-06-25 04:42:35 -04:00
ir.clj Run core.memoize's test suite on jolt 2026-06-25 13:23:05 -04:00
main.clj Tree-shaking: drop library code unreachable from -main (lever 3/4) 2026-06-23 19:45:13 -04:00
nrepl.clj nREPL: make the built-in server middleware-extensible 2026-06-22 15:37:14 -04:00
passes.clj Hintless whole-program double inference (#230) 2026-06-26 14:18:10 +00:00