JDK-6896525 : PerMethodTrapLimit and PerBytecodeRecompilationCutoff should be different values
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs17
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2009-10-29
  • Updated: 2010-04-02
  • Resolved: 2010-01-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
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.