[xfalcox]

> YJIT works fine with Puma and Webrick. I don't think anybody's tried it seriously with less-common servers like Falcon or Thin, but I'd expect it to work -- file a bug if it doesn't, because it should.

Have you tried it with Unicorn?

[byroot]

Yes, it work fine with Unicorn, YJIT is currently serving a small portion of Shopify storefront traffic, and that app runs with Unicorn.

Of course since each of the unicorn process will generate its own executable code, the memory usage difference with Puma is even bigger, and copy on write can't help here.

[xfalcox]

Yeah, I was trying to come up with an idea for this. We try to eagerly load as much as we can before fork, so most of the memory is shared between the forked unicorns, but this won't work with YJIT right?

Ideally we would be able to eventually do the forks of a "mature" unicorn child an hour or so after all is JITed...

[byroot]

Beside the operational nightmare that it would be to deploy with such a strategy, it wouldn't work long term.

JITed code can be invalidated and recompiled, so your forks would still drift over time.

I'm a big proponent of unicorn (and forking setups in general) for various operational reasons, but I think JIT might be the last nail in the coffin.

[joelbluminator]

Im out of my depth here but why can't they share the JITed code?

[byroot]

Because JITed code will inline things like the address of some specific objects (typically constants) etc. To share code between processes you'd need to ensure all these references are exactly the same in each process.