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 22:15:30 UTC 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