PerMethodTrapLimit and PerBytecodeRecompilationCutoff are currently set to the same value but this means that as soon as you cross the PerMethodTrapLimit line you will also make the method not compilable. I think this logic has never really be exercised before but if you have a lot of threads running the same code and hitting the safe uncommon trap then you can quickly overflow this when a simple recompile will end up recovering from it. The underlying problem is that the machinery for recording this doesn't have enough detail about what's really going on from a time and number of threads perspective.
- duplicates
-
JDK-6614597 Performance variability in jvm2007 xml.validation
-
- Resolved
-