> Most VMs are not simple, predictable systems that would ever reach a "steady state"—they're dynamic systems that are constantly executing different parts of t

> Most VMs are not simple, predictable systems that would ever reach a "steady state"—they're dynamic systems that are constantly executing different parts of the codebase and taking wildly different codepaths at different times. V8 is a great example of this—the type of code executed on a page changes wildly depending on what you're doing and what actions you take. That is already the exact point being made by Laurie and Edd's research. > Why would we even want to optimize it for "reaching a steady state", when different parts of the codebase may be more or less useful at different times? A steady state for whatever the application is doing right now. Not a single, statically known steady state, without considering what it's doing. > It seems more important to me to work on optimizations that can allow us to deoptimize parts of the codebase that we don't think we will be useful again, to save on memory, even if it involves sacrificing this theoretical notion of a "steady state" I think that's a completely solved problem isn't it? You can GC a compiled method. What more do you want?