Disable JIT byte code recompilation cutoffs in default jvm.config

[shubhamtagra]

Setting PerMethodRecompilationCutoff and PerBytecodeRecompilationCutoff to 10000
effectively disables these cutoff limits and JIT always recompiles code on hitting
"uncommon-trap". Without this, after hitting these cutoff limits JVM may enter a state
where it wastes CPU cycles in "uncommon-trap" handling but taking no action out of it.

This is based on this work) and we have seen this issue in java8 and these configs helped out.

[sopel39]

according to: https://docs.google.com/viewer?a=v&pid=forums&srcid=MTc4Njc1ODQ2NjUwMjMyMTg5MDgBMDI1NjY5NTA0OTU3NDE4MjA2MzABeVZ2NFEweGRCUUFKATAuMQEBdjI&authuser=0

Of course, fixing JVM is the right solution. But for a quick workaround, we can increase
PerMethodRecompilationCutoff and PerBytecodeRecompilationCutoff to some insane large
numbers so we never hit the threshold. (The default value for
PerMethodRecompilationCutoff is 400, which means 201 recompiles can lead to a deopt
storm).

I wonder if 10000 are insane enough

[shubhamtagra]

according to: https://docs.google.com/viewer?a=v&pid=forums&srcid=MTc4Njc1ODQ2NjUwMjMyMTg5MDgBMDI1NjY5NTA0OTU3NDE4MjA2MzABeVZ2NFEweGRCUUFKATAuMQEBdjI&authuser=0

Of course, fixing JVM is the right solution. But for a quick workaround, we can increase
PerMethodRecompilationCutoff and PerBytecodeRecompilationCutoff to some insane large
numbers so we never hit the threshold. (The default value for
PerMethodRecompilationCutoff is 400, which means 201 recompiles can lead to a deopt
storm).

I wonder if 10000 are insane enough

As per the findings in https://groups.google.com/g/presto-users/c/RCVd_UVMW5I/m/3LgcT0RXBQAJ 2500 should be good enough. This issue is hard to repro and we never got to try 2500 after 10000 gave us the improvements.

[findepi]

Do PerMethodRecompilationCutoff or PerBytecodeRecompilationCutoff affect https://github.com/martint/jittest?

[sopel39]

I'm not sure https://github.com/martint/jittest tests the issue mentioned in doc. doc has a code snipped for testing the issue

[shubhamtagra]

https://github.com/martint/jittest seems to be focused on code cache.

[shubhamtagra]

I revisited the notes, the goal of these settings is not to get infinite recompilations but to prevent the JIT state where lot of work is done and no action is taken. These settings would ensure that JIT will not hit the PerMethodRecompilationCutoff or PerBytecodeRecompilationCutoff because of PerMethodTrapLimit=100 (with #traps=25) always hitting first and preventing any more recompilation attempts (with last recompiled version having no uncommon-traps). I will reword the commit accordingly.

[martint]

Do PerMethodRecompilationCutoff or PerBytecodeRecompilationCutoff affect https://github.com/martint/jittest?

No, that code was to repro a bug in Java 7 related to how the code cache was being managed. It was fixed in Java 8.

[martint]

@stagraqubole, have you been able to reproduce the problem in Java 11+?

[sopel39]

@martint I was able to repro the problem with snipped attached in the doc

[shubhamtagra]

@martint In production we have only seen it with java8 but as @sopel39 mentioned this can be seen on java11 and even java14 with the code in the doc.