RFR: 8324649: Shenandoah: refactor implementation of free set [v32]

[Kelvin Nilsen]

On Mon, 1 Apr 2024 16:06:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Was trying to avoid impacting beyond the boundaries of Shenandoah.  I can tackle this if we think it preferable.  But also trying to work toward "timely integration".
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17561#discussion_r1556291273