RFR: 8319048: Monitor deflation unlink phase prolongs time to safepoint [v7]

Mon Nov 20 07:17:32 UTC 2023

On Fri, 17 Nov 2023 16:03:31 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> > @fisk I like the suggestion. One question: do we really need a `_purge_next` field? The only walkers of the `_in_use_list` is the MonitorDeflationThread and the VMThread and there are defined yield points from the former to the latter. It sounds like we could reuse the `_next_om` field.
> 
> I thought we walked it to find what JNI monitors to unlock at thread exit as well. Maybe that has moved. If that is the case, then yeah we probably don't need an extra field.

AFAICT we still walk it concurrently in JavaThread exit. 

There are many padding bits in the ObjectMonitor. Given that this purge list is only ever used for already deflated monitors it should be acceptable to store the list link inside these. We already do this with the WeakHandle, which is cleared (incorrectly) today after deflation but before the ObjectMonitors are phased out of the system. So it seems like there is little cost to doing this. And it keeps the memory usage the same. (Deflation will also not use any extra resource area memory like it does today).

I created a little poc 4707c7c679ec00d0fa3a80b4cb377fc412145cb4. Based it on @stefank's refactoring(5ec4de2c4a7a42a5b0466aa76931eeca57faec2e) which makes the code a lot more readable.

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

PR Comment: https://git.openjdk.org/jdk/pull/16412#issuecomment-1818358260