RFR: 8329488: Move OopStorage code from safepoint cleanup and remove safepoint cleanup code [v3]

[Kim Barrett]

On Mon, 8 Apr 2024 14:00:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The ServiceThread loops because it has a fixed wait timeout now.  It won't process these every time it's notified which can be more frequent.  This comment seems to say that there's more work, so do it next time.  I guess resetting the permit time to zero would prevent these cleanups from getting behind.  Are there tests for this condition?
>
> If you can't delete the last block, you don't really want the service thread to try to clean up right away though?  Only if you hit the limit of blocks to delete?

Never mind. I misremembered how the work limiting operated. It's not a fixed
limit on how much work to do. Rather, it's (roughly) process at most the
number of blocks as there were in the list on entry. The point is that if
other threads are allocating and then emptying blocks while we're working,
that can't cause us to keep working for some potentially arbitrary amount of
time.

Also, the result indicating more work to do is unused by the ServiceThread.
It is used by the gtest for delete_empty_blocks, but I think will never be
true as used there.

We could change ServiceThread to pay attention to the result, but that would
make that code a bit more complicated, and because of how the "work limit"
works I don't think there's much benefit to that.  There would be if the "work
limit" were some arbitrary fixed count, like 10 blocks or something, but since
it's not...

So I think just further updating the comment is sufficient.  I think just keep
the first sentence ("Exceeded ... last block.") and delete the rest, about
making the ServiceThread loop.

I might file a new RFE to do something useful with that bool result or
eliminate it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18375#discussion_r1558034765