JDK-6474240 : Check unhandled oops is too slow and hard to debug in jvmg
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 7
- Priority: P4
- Status: Closed
- Resolution: Fixed
- OS: solaris
- CPU: generic
- Submitted: 2006-09-22
- Updated: 2012-10-08
- Resolved: 2006-11-14
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.
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.
| JDK 6 | JDK 7 | Other |
|---|---|---|
6u4Fixed  |
7Fixed |
hs10Fixed |
Description
Title says it all. CHECK_UNHANDLED_OOPS code is slow in jvmg because the studio compilers don't inline away the constructor destructor calls for oop so it's much slower than fastdebug just running without the option. Also, if you're building a jvmg (debug) version of the VM, you usually want to debug the oops and they're hard to debug with a level of indirection. Having this functionality is good for testing a fastdebug VM with but not jvmg, so it's only going to be enabled for fastdebug vm.
Comments
|