4 ms·
There's a lot of ignorance in this thread around the JVM, which is forgivable I suppose since it's not the hot new thing atm :) The parameters they are tuning
by winrid 4y ago
There's a lot of ignorance in this thread around the JVM, which is forgivable I suppose since it's not the hot new thing atm :)
The parameters they are tuning are available in any good VM with a JIT. You won't see these tuning knobs with Go because there's no JIT. These are trade offs. Scala is also known to create more garbage than Java.
The reason for the CPU spikes are code is getting compiled via JIT which takes CPU. If isn't enough space for JIT compiled code then you'll be recompiling code often, burning CPU.
This is similar to database cache tuning. Too little cache and you burn CPU and IOPS. Too much cache and you don't leave enough memory for other operations.
These parameters have good defaults but large apps can surpass them. It's important it's not automatic as this could have dire consequences (oom etc).
- kevincox 4y ago> If isn't enough space for JIT compiled code then you'll be recompiling code often, burning CPU. This sounds like a bug to me. If you are out of space for compiled code stop compiling. Or at least start slowly raising the threshold at which you recompile something so that the compilation cost is amortized over time. If your recompiling is using more CPU than was being used before it started something is wrong. You should only be compiling code when it is expected to save CPU long-term.
- winrid 4y agoThat could be. Also this is VM dependent, and there are a handful :) I wonder if it would be easier for them to just use GraalVM.