JDK-8230459: Test failed to resume JVMCI CompilerThread

[Kim Barrett]

> On Nov 5, 2019, at 3:40 AM, Doerr, Martin <martin.doerr at sap.com> wrote:

Coming back in, because this seems to be going off into the weeds again.

>> I don't understand what you mean. If a compiler thread holds an oop, any
>> oop, it must hold it in a Handle to ensure it can't be gc'd.
> 
> The problem is not related to gc.
> My change introduces destroy_global for the handles. This means that the OopStorage portion which has held the oop can get freed.
> However, other compiler threads are running concurrently. They may execute code which reads the oop from the handle which is freed by this thread.
> Reading stale data is not a problem here, but reading freed memory may assert or even crash in general.
> I can't see how OopStorage supports reading from handles which were freed by destroy_global.

So don't do that!

OopStorage isn't magic. If you are going to look at an OopStorage
handle, you have to ensure there won't be concurrent deletion. Use
locks or some safe memory reclamation protocol. (GlobalCounter might
be used here, but it depends a lot on what the iterations are doing. A
reference counting mechanism is another possibility.) This is no
different from any other resource management.

> I think it would be safe if the freeing only occurred at safepoints, but I don't think this is the case.

Assuming the iteration didn’t happen at safepoints (which is just a way to make the iteration and
deletion not concurrent).  And I agree that isn’t the case with the current code.