yjit VS vox

> I’m curious how the impact affects development, deployment, etc.

YJIT is pretty much transparent in production, if not it's likely a bug.

When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase.

But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy.

The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps.

As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default.

[0] https://github.com/Shopify/yjit/issues/87

Just want to temper expectations because YJIT is still new. But if you run into crashes or bugs, please open an issue with as much detail as you can: https://github.com/Shopify/yjit

You raised a point that the compiler only does a subset. That's actually what I would expect from a new project. I don't expect a full implementation to start. It takes time for a compiler to be mature enough to be general purpose. Here is another Ruby compiler in its infancy: https://github.com/Shopify/yjit.

We allocate our own chunk of executable memory and append/rewrite the end of it as we compile new blocks. We have our own in-memory assembler that's implemented here. It's x86 only right now, totally not portable, but over the course of the summer we're going to work on a backend that can open up the possibility of ARM64 support and some lower-level optimizations.

Yes. I put some suggestions here. I realize that not all of them are practical, but refactoring specific hot methods could make a difference.

Yes we are in touch with the Ruby core devs. They seem open to collaborating. k0kubun (working on MJIT) has contributed to the project: https://github.com/Shopify/yjit/pull/60

I chase the same goal with Vox, although it is written in D.

Looking for contributors to Vox programming language/compiler: Statically typed, compiled and embeddable language, primarily focused on gamedev. It uses custom backend to keep low compile-times and small size. Written in D language.

https://github.com/MrSmith33/vox

Because it is easier to have a free-list in a dedicated array arena, so you could reuse memory when you free it (and you need to grow arrays when you fill them). I was lazy and did 13 array arenas each dedicated to allocating fixed size chunks, from 16 bytes to 64k bytes. Bigger sizes currently go to malloc/free. And I restrict arrays to PoT sizes, so they only request PoT sized chunks from array arenas.

I do this in Vox

I use this approach in Vox compiler. Everything is stored in arenas including AST nodes and IR. I'm in the process of documenting the design, but I added a bit of description on memory management and IR storage

Here is the algo in more detail: https://github.com/MrSmith33/vox/blob/master/source/be/reg_alloc/linear_scan.d#L891-L918

Tip: Should probably use the Github permalink https://github.com/MrSmith33/vox/blob/35ec440d0c9a475cd4add6093d122cd249b03be9/source/be/reg_alloc/linear_scan.d#L891-L918 so later readers do not go to some random line after you change that file :)

Here is a CI build