JDK-6895788 : G1: SATB and Update buffer allocation code allocates too much space
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs16,hs17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86,sparc
  • Submitted: 2009-10-27
  • Updated: 2013-09-18
  • Resolved: 2010-01-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.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs16Fixed
Related Reports
Duplicate :  
Description
While investigating 6889740 it was discovered that the code that allocates the buffers that are used for the SATB and Update processing allocates too much space.

For the SATB buffers we set the size of the SATB Queue set (the _sz field) to be G1SATBLogBufferSize * oopSize during VM initialization. With the default value of G1SATBLogBufferSize (1K) this gives _sz = 8*1K or 4*1K (for 32 bit). The actual buffers are allocated using NEW_C_HEAP_ARRAY and given void* as the type. This means that size requested of the allocation routine is 8K*8 = 64K (or 4K*4 = 16K for 32 bit).

This seenms to be incorrect. The buffers are indexed using a helper routine byte_index_to_index which takes an index (usually the value of the _index field) and divides it by oopSize to give an index into the buffer array. The _index field is initialized to the value of _sz (8*1K). Suppose we have _index == 8184 (_sz - oopSize), the value of byte_index_to_index for 8184 gives 1023. So we assign into _buf[1023].

So we assign values into _buf[0..(_sz/oopSize)-1] but we have allocated a buffer with enough space to hold 8K entries (64K bytes). 

The fix is relatively simple: the code in allocate_buffer and deallocate_buffer should be changed to use:

   (void**)NEW_C_HEAP_ARRAY(char, _sz);

This will give 8K byte buffers - which looks like what was intended from the generated barrier code and the indexing code in the flush routine.

Comments
EVALUATION http://hg.openjdk.java.net/hsx/hsx16/master/rev/9f7d1f6201ab
13-11-2009

EVALUATION http://hg.openjdk.java.net/hsx/hsx16/baseline/rev/9f7d1f6201ab
12-11-2009

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5f932a151fd4
06-11-2009

SUGGESTED FIX The fix is relatively simple: the code in allocate_buffer and deallocate_buffer should be changed to use: (void**)NEW_C_HEAP_ARRAY(char, _sz); This will give 8K byte buffers - which looks like what was intended from the generated barrier code and the indexing code in the flush routine.
03-11-2009

EVALUATION PrintMallocFree flag confirms that we seem to be allocating more space for the SATB and update buffers than what we actually index.
03-11-2009