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

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.