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

[Thomas Stuefe]

On Thu, 24 Mar 2022 10:28:12 GMT, Roman Kennke <rkennke 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.

Right, thanks.

> > 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.

Sure, but in OOM situations you may not have that memory. E.g. cloudfoundry jvmkill does a jvmti heapwalk before killing the VM due to OOM.

It is not an argument against your patch, especially since it just costs 1/64th. Just saying, it may degrade usefulness of jvmti heap walk. There are ways around it though, and possible optimizations later.

> 
> > 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. ?

Up to you. I think it's fine as it is, and leaving this in jvmti has its charm too.

Personally, I probably would prefer a more generic solution, e.g. a bitmap which on the fly commits pages with set bits. Bitmap clear would be super simple, just uncommit the whole area. getbit() would return false for uncommitted areas. It is simpler in that you have no dependencies to GC or anything else, easier to reuse, saves more memory (since you only commit what is set, not what is committed). It would be an optimization one could do later though.

> Thanks, Roman

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

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