2 ms·

I think you're a bit confused about the basic idea. > every node already has? No every node doesn't already have it. That's the point. One node computes on be

I think you're a bit confused about the basic idea. > every node already has? No every node doesn't already have it. That's the point. One node computes on behalf of everyone. > you'd still need the capacity to run lots of compilations along not-yet-optimized code during startup Well no - nodes also have interpreters so they don't wait. And it's not any slower for someone else to run the compilation on your behalf - the result comes in the same time. And most code doesn't change between redeploys so doesn't need to be recompiled.

usrusr 5y ago
Every node already has the bytecode and the interpreter, or more likely fast, superficial JIT without expensive optimisation. But that's slow, so when you need to serve a given load you'll need more nodes before they have settled into a hot optimization state. Regarding unchanged code after redeploy, usage patterns might change a lot even for code that hasn't changed at all. With profile guided optimizations (which I'd expect to be more norm than exception for something like azul), this would mean that nominally unchanged code could suffer hard from running in a version optimized for a different calling environment (the previous version of the application). In the grand scheme of things, I'd assume that this would be the main benefit and goal of a JIT outcome sharing mechanism like this: allowing nodes to cooperate by each profiling a different part of their shared code, kind of like becoming experts in a tiny specialization, and then sharing that expertise.