JDK-7173712 : G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv()
- Type: Enhancement
- Component: hotspot
- Sub-Component: gc
- Affected Version: 7u4
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2012-06-01
- Updated: 2013-09-18
- Resolved: 2012-08-07
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 7 | JDK 8 | Other |
|---|---|---|
7u40Fixed  |
8Fixed |
hs24Fixed |
Description
While looking at a collect profile that was generated for the ATG CRM demo, it was notcied that a fairly high amount of CPU time was being spent in the code for G1RemSet::par_write_ref() that had been inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv(). In the profile it was observed that the actual high CPU time was actually coming from looking up the region for the supplied object. In the profile analyzer disassembly it was observed that offending piece of code in G1RemSet::par_write_ref() duplicated code in G1UpdateRSOrPushRef::do_oop_nv(). In do_oop_nv() the same code did not seem to incur any penalty. The code in do_oop_nv() should be refactored to avoid the redundant checks that are also performed if we execute the path the calls G1RemSet::par_write_ref().
Comments
|