[master] RFR: JVMTI: Don't use object header for marking

[Roman Kennke]

On Thu, 24 Mar 2022 09:29:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> You reserve a bitmap to cover the whole reserved heap space, with one bit per possible object location? So the memory use would be -Xmx / 12, right? (8 bits per byte, 3 bit shift)?

No. Each bit covers one word in Java heap (or more, if object alignment is higher). Bitmap size is 1/64 of heap size.
 
> So I calculate ~90MB per GB address space. Am I thinking right?

16MB/1GB address space.
 
> This may hurt a bit for applications which use jvmti heap walk as OOM analysis tool. But I guess short term its okay.

It should only be short-lived, as long as the heap walk takes.

> Will in the course of walking every object be visited, so every bit be set eventually, or would the bitmap be more sparse? If the latter, we may reduce the footprint in the future by making a on-demand-commited bitmap, only committing pages with set bits. Would make clearing faster too.

Yes, that would be an option. I assume it would be relatively sparse: objects are larger than single words, many regions are unused, e.g. to have headroom for GC, etc.

> Do we need a bitmap for the whole reserved range, would a committed range not simpler? But probably difficult to do if multiple committed regions exist.

Yes. We do that for example in Shenandoah GC: we only commit marking bitmaps for ranges where we have committed heap regions. But it requires better integration with GC. I have been thinking to move ObjectMarker into GC, accessible by a GC interface, and possibly implemented in a GC specific manner, and then GCs could optimize this, or even keep using object-header-marking if it doesn't cause problems with the GC (I believe it only really causes troubles with Shenandoah right now). Maybe this would be preferable overall. ?

Thanks,
Roman

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

PR: https://git.openjdk.java.net/lilliput/pull/45