RFR: 8307348 - Parallelize heap walk for ObjectCount(AfterGC) JFR event collection [v4]

[Thomas Schatzl]

On Thu, 4 May 2023 17:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > How does that affect another caller, `VM_GC_HeapInspection::doit`? Unclear to me how one can get gc-workers in that context.
> 
> I think `safepoint_workers` is "fine" to use from `VM_GC_HeapInspection`. That VMOp does not know the status of GC threads when executing the VM op. The GC threads might be currently parked at STS and not available. `safepoint_workers` are supposed to be separate from normal (concurrent) GC workers then.

I agree.

> 
> So, the contract for `safepoint_workers` is relatively safe for doing this the object count heap walk too. I agree it would be cleaner to use the GC workers, though. The problem that I see there is that `report_object_count_after_gc` is called from rather generic places like `GenMarkSweep::mark_sweep_phase1`, where we don't know how many workers do we have (or even which exact GC we are running). That would probably require lifting `workers()` straight to `CollectedHeap`.

Can you elaborate about this? From what I can see, the callers of `report_object_count_after_gc` other than heap inspection always have GC workers available. As for `GenMarkSweep::mark_sweep_phase1` specifically - this is serial gc. There are no workers for it, and it's not supposed to use multiple threads. One would just pass `nullptr` here I assume.

  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/13774#issuecomment-1535795378