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.
Other
hs17Resolved
Related Reports
Duplicate :  
JDK-6614597 - Performance variability in jvm2007 xml.validation
Description
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.