RFR: 8324649: Shenandoah: refactor implementation of free set [v32]
Kelvin Nilsen
kdnilsen at openjdk.org
Mon Apr 8 18:51:16 UTC 2024
On Mon, 8 Apr 2024 18:47:08 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> Like Roman, I'd prefer extending existing code and/or making it adaptable for our purposes to duplicating functionality. Let us read through the differences and see if this should be done now, or as you state allow this duplication for now in the interests of speed and expediency.
>
> Here's a rough outline of the differences between ShenandoahSimpleBitMap and src/hotspot/share/utilities/bitMap.*
> 1. ShenandoahSimpleBitMap finds next bit in the forward and backward direction. BitMap only searches in forward direction. We use backward searches when we prefer to pack certain types of objects into the high end of the heap.
> 2. ShenandoahSimpleBitMap also searches for clusters of bits, to facilitate efficient satisfaction of humongous allocation requests. BitMap only searches for a single bit. We could add this capability to BitMap.
> 4. If we were to generalize BitMap to handle reverse searches, this may have far-reaching impact on the API. The type of results and idx_t (typedef size_t). When we do backward searches, ShenandoahSimpleBitMap treats -1 as the sentinel NOT_FOUND value.
If consensus is we should not re-invent the wheel, I'll make an effort to make the additional changes required to use BitMap instead of ShenandoahSimpleBitMap.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1556297884
More information about the hotspot-gc-dev
mailing list