JDK-8026293 : Schedule part of G1 pre-barrier late
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-10-10
  • Updated: 2015-07-10
  • Resolved: 2013-10-16
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.
JDK 7 JDK 8 Other
7u60Fixed 8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8130918 - G1 barriers are laid out in full on critical path
Description
A large part of the G1 write barrier is only used during marking, hence the code it not commonly executed.

To make the active code segments smaller and better fit the cache these unused segments should be schedule outside of the common path.

Setting the the first branch of the pre-barrier check to be unlikely will make the compiler treat the barrier code as cold and hence schedule it outside of the hot path.

This helps to improve the performance of the generated when no concurrent marking is running.
Comments
The C2 graph involving AllocateNode and InitializeNode was introduced in JDK-6337834 and tweaked in JDK-6506252 to remove card marks and other redundant operations in a peephole neighborhood of an allocation. It is likely that the complex G1 barriers are obscuring this peephole analysis. We should investigate repairing that analysis.
22-01-2014