RFR: Inline usage of pointer_delta

William Kemper wkemper at openjdk.java.net
Thu Oct 7 18:28:35 UTC 2021


On Thu, 7 Oct 2021 17:35:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Card table sometimes erroneously triggers assert added in JDK-8260046.

The issue happens when card table computes  `_byte_map_base` as `_byte_map - (uintptr_t(whole_heap.start()) >> card_shift)`. There's nothing to prevent the kernel from putting `_byte_map` before `whole_heap.start()`, in which case `_byte_map_base` underflows and triggers the assert in `pointer_delta` later on when computing the heap address for a card. Kelvin and I worked through the math and convinced ourselves it was safe in this case:

`low_bound` here is `whole_heap.start()`.

1. By precomputing `_byte_map_base`, we avoid the need to subtract an offset every time we look up a card-table index.
2. The "unoptimized" card-table lookup would look like `byte_map[(addr - low_bound) >> _card_shift]`
3. Which by distributive property is the same as `byte_map[addr >> _card_shift - low_bound >> _card_shift]`
4. Which is  `*(_byte_map + addr >> _card_shift - low_bound >> _card_shift)`
5. Which is  `*((_byte_map - low_bound >> _card_shift) + addr >> _card_shift)`
6. Which is `*(_byte_map_base + addr >> _card_shift)` where `_byte_map_base = _byte_map - low_bound >> _card_shift`
7. Which is `byte_map_base[addr >> _card_shift]`

I'd expect this to also affect Parallel and Serial gc, but it does not happen often (and it does not cause problems for release builds).

-------------

PR: https://git.openjdk.java.net/shenandoah/pull/83


More information about the shenandoah-dev mailing list