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

[Roman Kennke]

On Thu, 24 Mar 2022 10:50:51 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

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

Right. The current implementation also allocates native memory, in needs to preserve object headers of locked objects. It's probably very small, though.
 
> 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.

Hmm, yeah.

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

I would say, the marking bits in object header is GC concern, and managing a marking bitmap for heapwalk would also be a GC concern (it requires knowledge of heap layout, even more so if we wanted to implement your proposed optimizations).

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

Yes. Let me implement a little abstraction in GC and a single implementation (which uses object header) for the start. I will do the bitmap-based heapwalk in the Shenandoah patch, and we can implement optimizations then.

Thank you!
Roman

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

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