JDK-6910247 : G1: Refactor code in g1BlockOffsetTable.[ch]pp with that of other collectors
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7,7-pool
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2009-12-14
  • Updated: 2019-02-11
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
tbdUnresolved
Related Reports
Relates :  
Description
There is currently a good deal of duplicated code in g1BlockOffsetTable.[ch]pp and the block offset code used by the other collectors (blockOffsetTable.[ch]pp). This should be cleaned up and refactored if possible.

The main issue is that with G1 the "default" version of block_start has the side effect of updating entries for objects that point too far backwards i.e. to the value recored in the last alloc_block call. The code used by the other collectors does not have this side effect. As a result their routines are typically defined as "const" where G1 routine are not. Here is a relevant comment from g1BlockOffsetTable.hpp:

// While generally mirroring the structure of the BOT for GenCollectedHeap,
// the following types are tailored more towards G1's uses; these should,
// however, be merged back into a common BOT to avoid code duplication
// and reduce maintenance overhead.
//
//    G1BlockOffsetTable (abstract)
//    -- G1BlockOffsetArray                (uses G1BlockOffsetSharedArray)
//       -- G1BlockOffsetArrayContigSpace
//
// A main impediment to the consolidation of this code might be the
// effect of making some of the block_start*() calls non-const as
// below. Whether that might adversely affect performance optimizations
// that compilers might normally perform in the case of non-G1
// collectors needs to be carefully investigated prior to any such
// consolidation.