RFR: 8256302: releasing oopStorage when deflating allows for faster deleting [v3]

[Robbin Ehn]

On Sat, 3 Dec 2022 07:02:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Just to make sure I'm understanding things correctly - it's not
>> OopStorage::release that has thread state requirements, it's
>> WeakHandle::release. The WeakHandle operation needs to ensure the pointee has
>> been nulled out (before calling the OopStorage operation), invoking GC
>> barriers.
>> 
>> If the claim is that OopStorage::release has thread state requirements, I'd
>> like more info, since that function is intentionally trying to be low on
>> requirements.
>
>> > Doing a os::free which may call NMT while the thread is in the blocked state is probably okay, but I think you should check this out. There may be a dcmd that runs at safepoint that does NMT things.
>> 
>> That's an interesting question. I can't imagine that this is the first call to os::free() that can run in parallel with a safepoint. Normally, I would ask Zhengyu, but he's not working on this stuff anymore.
> 
> That is fine. In summary mode, NMT record_free will just decrease atomic counters. In detail mode, it will look up an entry from the malloc site table and decrease its atomic counters. Malloc site table is lockless. There is nothing that should block, or require safepoint-less-ness.

> Just to make sure I'm understanding things correctly - it's not OopStorage::release that has thread state requirements, it's WeakHandle::release. The WeakHandle operation needs to ensure the pointee has been nulled out (before calling the OopStorage operation), invoking GC barriers.
> 
> If the claim is that OopStorage::release has thread state requirements, I'd like more info, since that function is intentionally trying to be low on requirements.

Hi Kim, no it's not about "OopStorage::release", it's about what the GC expect during a safepoint.
AFAICT we should never use any of the "NativeAccess<>::oop_store(_obj, (oop)NULL);" during a safepoint from a safepoint safe thread.
Which in practice means we can never use OopStorage::release in such case, since we always need to clear it first.

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

PR: https://git.openjdk.org/jdk/pull/11296