I worked on this years ago. Gcj did support loading and interpreting bytecode alongside the AOT-compiled code. libffi's closures were originally implemented to support calling interpreted methods from AOT-compiled code, because a class's vtable could include a mix of AOT-compiled and interpreted methods. You could also compile jar files directly into .so files, which would get loaded and used at runtime if a classloader ever loaded the corresponding jar.

VISA open sourced an expense-to-run harness they developed under glasswing, and I used that as the basis of a skill that I've found to be pretty effective with Claude Code: https://github.com/atgreen/secscan-skill

TBH, the complexity of this step grew over time, and the overhead snuck up on us. The prep step does useful work (eg. determine stack space requirements). It's just that we don't have to do it again.

Something I should have mentioned is that we could have avoided the new APIs if only there was space in the ffi_cif to stash a plan pointer. And I didn't want to break ABIs for this.

Yes, that's part of what was done here. So, create a plan, and then for some subset of plans, create AOT-compiled templates. The analogies are: a) original implementation is like interpreting via walking a syntax tree b) building/caching an execution plan is like interpreting by executing bytecode generated from the syntax tree c) using an AOT-compiled template is like execution from qemu's old TCG template system But we only do (c) for a popular subset of function signatures. The biggest win was (b), but (c) is still an improvement over (b).

Here's another option.. I created an optimizing eBPF compiler in Common Lisp for a lisp-ish DSL. It's nice because you can compile and load your eBPF code all in-process in lisp (even from your REPL) without any external tooling. https://github.com/atgreen/Whistler

Don't disagree, but there are eBPF mitigations that work as alternatives to unloading kernel modules.

Can you elaborate on that?

Have a look at https://github.com/atgreen/rhel-block-copyfail

I was aware of commercial antivirus vendors (Crowdstrike) doing something like this, but this is the first I've seen it published by somebody in the open!

Have you considered writing up a blog post and submitting this to HN?

Thanks!

From the sound of it, the same mitigations for Copy Fail 1 are also effective here.

No, they are different. I just bundled them together for convenience in this POC. The only real thing in common is that they both use eBPF.

Got it, thanks!

I created something similar earlier today: https://github.com/atgreen/block-copyfail

This is not my experience. I've been experimenting with something very similar to vera. However my language transpiles into multiple languages (Java, Typescript, Common Lisp, Rust, C++, Python, C# and Swift). The transpiler is written in the language itself (there's a separate bootstrap transpiler written in Common Lisp). But where I'm going is that Claude, at least, is extremely capable at writing decent code in my new language with barely any prompting; just minimal guidance on the language itself and no examples.

That's simply not true. That's just not the way LLMs work. LLMs are not magic.

LLMs are stateless, they don't "remember" your bespoke programming language manual and examples between completion calls, so you have to repeatedly include all that with each and every completion call, which balloons the number of tokens used, reduces how much useful work you can do with the remaining tokens and attention, and is a costly waste of tokens and electricity and money.

That isn't anywhere near as effective or efficient as using the LLM's pre-existing training on billions of lines of well known programming languages, manuals, tutorials, examples, code bases, stack overflow discussions, books, github repos, pr's, etc.

What is your extraordinary evidence for your extraordinary claims? Have you empirically measured how well it works, or is it just vibes and handwaving?

I enjoyed reading this. Thank you for sharing.

I learned Common Lisp years ago while working in the AI lab at the University of Toronto, and parts of this article resonated strongly with me.

However, if you abandon the idea of REPL-driven development, then the frontier models from Anthropic and OpenAI are actually very capable of writing Lisp code. They struggle sometimes editing it (messing up parens)), but usually the first pass is pretty good.

I've been on an LLM kick the past few months, and two of my favorite AI-coded (mostly) projects are, interestingly, REPL-focused. icl (https://github.com/atgreen/icl) is a TUI and browser-based front end for your CL REPL designed to make REPL programming for humans more fun, whether you use it stand-alone, or as an Emacs companion. Even more fun is whistler (https://github.com/atgreen/whistler), which allows you to write/compile/load eBPF code in lisp right from your REPL. In this case, the AI wrote the highly optimizing SSA-based compiler from scratch, and it is competitive against (and sometimes beating) clang -O2. I mean... I say the AI wrote it... but I had to tell it what I wanted in some detail. I start every project by generating a PRD, and then having multiple AIs review that until we all agree that it makes sense, is complete enough, and is the right approach to whatever I'm doing.

Thank you!