RFR: Do not visit gc threads during shutdown
William Kemper
wkemper at openjdk.org
Tue Mar 21 01:04:41 UTC 2023
On Tue, 21 Mar 2023 00:49:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:
>> 1. The shutdown sequence doesn't need to iterate over the threads.
>> 2. The crashing thread wasn't "gone", but it's termination had been requested. It crashed in a call to get the thread's clock time (pthread_getcpuclockid). The thread's native handle should still have been valid. I didn't fully root cause the crash.
>> 3. In this case, it was the control thread itself that was trying to iterate the threads. The fix here will stop the control thread from starting an iteration of the threads _after_ the shutdown sequence has begun, but it is not so robust to cover a shut down during an iteration of the threads.
>
>> 1. The shutdown sequence doesn't need to iterate over the threads.
>
> Good!
>
>> 2. The crashing thread wasn't "gone", but it's termination had been requested. It crashed in a call to get the thread's clock time (pthread_getcpuclockid). The thread's native handle should still have been valid. I didn't fully root cause the crash.
>
> I assume you meant "the _GC thread that the control thread was iterating over_ wasn't gone, but its termination had been requested"? I'd consider that as good as gone, absent any interlocking between the iteration and the termination of the target thread.
>
>> 3. In this case, it was the control thread itself that was trying to iterate the threads. The fix here will stop the control thread from starting an iteration of the threads _after_ the shutdown sequence has begun, but it is not so robust to cover a shut down during an iteration of the threads.
>
> May be one then needs a handshake/interlock with the control thread during the shutdown sequence if it's the only thread that iterates over these threads. (Or their termination could be delegated to the control thread, which is morally equivalent, and perhaps cleaner.) Is the case then that you have by your change above substantially narrowed the window of vulnerability, but not completely closed it? Or did I misunderstand?
The `core` file I had was on `/tmp` and was lost in one of the power outages last week. I meant that the control thread's termination was requested and it was the control thread itself that was iterating the other threads. I don't recall which visited thread caused the crash. As I think on this, I'd like to make another small change to make it more robust.
Yes, that's fair. This change narrows the window, but doesn't completely close it.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/228#discussion_r1142807659
More information about the shenandoah-dev
mailing list