3 ms·

What do you mean by exhausting jit caches? Do other VMs limit their size somehow? JSC basically doesn’t. That doesn’t solve the problem of course. I have this

What do you mean by exhausting jit caches? Do other VMs limit their size somehow? JSC basically doesn’t. That doesn’t solve the problem of course. I have this metric that I use to philosophize about this: SIPS, or static instructions per second. If your program has low SIPS (I.e. it’s the benchmark of HotSpot’s wet dreams or OP’s post) it means that the total code is small and it runs a long time - so the JIT will go on a rampage early on and then you’re good. If the program has high SIPS, then the JIT will still be catching up when the program terminates. Most real things that aren’t web servers have low SIPS.

titzer 5y ago
Reflecting more on this. AFAIR Hotspot does have a hard limit on the amount of machine code it will generate. V8 has a hard limit on the heap size, and code pages are part of that. But both of those are pretty big numbers, so if you are hitting that you are probably huge already. But generally there are counters in the metadata for functions or classes, depending on the system, that limit how many times a given unit might be recompiled, typically to limit the damage deopt loops can do. So programs end up gradually leveling off as they hit those limits. I haven't really paid attention to V8's policies for years, but generally speaking, it still does this to some extent. I think of SIPS as basically the resident set size for code. Depending on how the system ages your code, you might be stuck with unused JIT code until it can be recycled, if at all. V8 used to have code aging and the implementation was a huge bug farm. I am not sure if that survived the switch to TurboFan/Ignition. Of course, V8 GC's code about as aggressively as it compacts the old generation.
- pizlonator 5y ago
  JSC limits recompilation only in the sense that we have exponential back off on each jettison. But that means that a sufficiently hot function will keep getting recompiled forever even if speculation is permabroken in that function. Other than that JSC has only very weak heuristics for aging out code. And on sufficiently empowered devices our JIT pool is hundreds of megs. So, we will happily compile your whole program with the jit if your whole program is warm and runs long enough.

titzer 5y ago

Reflecting more on this. AFAIR Hotspot does have a hard limit on the amount of machine code it will generate. V8 has a hard limit on the heap size, and code pages are part of that. But both of those are pretty big numbers, so if you are hitting that you are probably huge already. But generally there are counters in the metadata for functions or classes, depending on the system, that limit how many times a given unit might be recompiled, typically to limit the damage deopt loops can do. So programs end up gradually leveling off as they hit those limits. I haven't really paid attention to V8's policies for years, but generally speaking, it still does this to some extent. I think of SIPS as basically the resident set size for code. Depending on how the system ages your code, you might be stuck with unused JIT code until it can be recycled, if at all. V8 used to have code aging and the implementation was a huge bug farm. I am not sure if that survived the switch to TurboFan/Ignition. Of course, V8 GC's code about as aggressively as it compacts the old generation.

pizlonator 5y ago
JSC limits recompilation only in the sense that we have exponential back off on each jettison. But that means that a sufficiently hot function will keep getting recompiled forever even if speculation is permabroken in that function. Other than that JSC has only very weak heuristics for aging out code. And on sufficiently empowered devices our JIT pool is hundreds of megs. So, we will happily compile your whole program with the jit if your whole program is warm and runs long enough.