RFR: 8327093: Add slice function to BitMap API

[Ioi Lam]

On Tue, 5 Mar 2024 09:11:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> That `truncate(n)` is `[n:]` and not `[:n]` does not feel intuitive to me. Maybe having a `truncate_start` as well as `truncate_end` which covers both the explicit cases.

The current treatment of the 1-parameter case is similarly to the Java API of [`String.substring(int start)`](https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#substring-int-), or the JavaScript [`slice()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice) API for arrays. So if we want the current behavior, it might be better to rename the function as `subset()` or `slice()`.

However,  `subset()` or `slice()` usually mean making a copy of an existing BitMap. Yet, with the current usage of C++ templates in bitMap.hpp, that's very difficult to make a copy of the BitMap object itself. E.g, many of the BitMaps are currently stack-allocated. It's unclear where a "copy" of such a BitMap object should live. (Note: `BitMapWithAllocator::allocate()` allocates a `bm_word_t` array, not a BitMap object).

I think  the name`truncate()` will align with the existing `resize()` API -- both of them modify the BitMap object in-place.

However, a `truncate(n)` that means `[:n]` would do the exact same thing as `resize(n)`. It would be confusing to have two APIs that do the same thing.

But I agree that a `truncate(n)` that means `[n:]` is also non-intuiative.

So I think the best compromise is simply to not offer a single parameter version of `truncate(n)`. It would be fairly easy for the caller to specify `truncate(0, n)` or `truncate(n, bitmap->size_in_bits())` to indicate exactly what is needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18092#issuecomment-1979240338