RFR: 8283710: JVMTI: Use BitSet for object marking [v4]

[Thomas Schatzl]

On Thu, 7 Apr 2022 15:11:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> A general thought, maybe for a future RFE:
>
>We now have BitMap and BitSet, which do almost the same thing. Instead of having a new class BitSet, whose job is to be sparse, we could give BitMap the ability to be sparse. We'd save code, reuse the rich BitMap interface and get all the test code for free.
>
>One way to do that would be to make BitMap responsible for committing its underlying backing memory, in chunks, on-demand only. To do that BitMap would need a secondary map - a commit map - to remember which fragments of its backing memory are committed. Commit map would have a bit per 64M fragment.

Please don't do this. `BitMap` (well, `BitMapView`) is also used as a lightweight way to overlay it on arbitrary memory temporarily (i.e. remembered sets bitmaps). This typically boils down to no additional memory usage (and overhead) at all.
So any additional memory usage or initialization should not be added lightly.
Also in most other cases, `BitMap` is used for very tiny bitmaps anyway, this would just add unnecessary functionality (and overhead) for 99% of the usage of `BitMap`.

Further GCs are using `BitMap` to implement such sparse bit sets already, managing their memory with the corresponding Java heap memory; so adding this functionality at the `BitMap` level would just duplicate functionality with probably not-so-hilarious side effects.

I also *do* think that the use cases for a dense `BitMap` are significantly different from (huge) sparse "BitMap"s to warrant its own separate class (not saying that one couldn't use the other internally, or that if that `BitSet` could be reused in GCs if configurable enough).

I am also not sure that the automatic lazy backing of the OS isn't sufficient for these use cases (e.g. JVMTI) too.

Thanks,
  Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/7964