Review Request (XS): CR 6895788 - G1: SATB and update buffer allocation code allocates too much space

john cuthbertson - Sun Microsystems John.Cuthbertson at Sun.COM
Tue Nov 3 14:15:30 PST 2009


Hi Everyone,

Can I have a couple of volunteers to review the code changes for this 
CR? The webrev can can be found at 
http://cr.openjdk.java.net/~johnc/6895788/webrev.0/

The issue here was that the code that allocates the actual buffers for 
the SATB and dirty card queues allocates more space than is required. 
For the SATB buffers, for example, the value of the _sz field of the 
relevant SATBQueueSet class is set to be G1SATBLogBufferSize * oopSize 
during VM initialization. With the default value of G1SATBLogBufferSize 
(1K) this sets _sz = 8*1K or 4*1K. 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).

The buffers are indexed using the value of the _index field which s 
initialized to the value of _sz (8*1K) from the corresponding queue set. 
In the barrier code value of _index is decremented by oopSize. In 
ptrQueue.[ch]pp they are indexed by a helper routine: 
byte_index_to_index. This function takes the given index (the value of 
the _index field) and divides it by oopSize to give an index into the 
buffer array.  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] (i.e. 8K bytes) but we 
have allocated a buffer with enough space to hold _sz entries (i.e. 64K 
bytes).

Testing: OpenDS, SPECjbb2005, refworkload, and jprt.

Thanks,

JohnC

PS I also noticed that we weren't decrementing the size of the free 
buffer list when we were reducing the number of free buffers.


More information about the hotspot-gc-dev mailing list