RFR: 8230424: Use platform independent code for Thread.interrupt support

[David Holmes]

ping!

Thanks,
David

On 13/09/2019 7:12 pm, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8230424/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8230424
> 
> The next instalment of the interruption logic refactoring.
> 
> Summary of changes:
> - the windows-specific actions in os:interrupt and os::is_interrupted 
> are pushed down into the windows-specific osThread code. This all 
> relates to the only-used-by-the-JDK _interrupt_event.
> - the POSIX variant of os::interrupt and os::is_interrupted is inlined 
> as platform-independent code in the Thread versions and those versions 
> are themselves moved to JavaThread as instance methods.
> - minor cleanups to the logic of interrupt() as we can never have NULL 
> events as we are always guaranteed to be operating on a live thread.
> - All call sites adjusted as needed.
> 
> One minor wart in this refactor is that on Windows we will execute an 
> OrderAccess::release() after setting the interrupt state in the platform 
> code, and then execute an additional fence() in the shared code. I don't 
> think this is worth trying to "fix" - and hopefully if we can get rid of 
> the Windows _interrupt_event this will all go away.
> 
> If you are wondering why Windows used OrderAccess::release while POSIX 
> used OrderAccess::fence, I have no idea, and I do not intend to change 
> either of them. The only safe change would be to use fence() in both 
> cases, which just makes the Windows wart worse - and unnecessarily so as 
> we have seen no bugs using the existing release().
> 
> Testing:
>   - hotspot runtime
>   - Tiers 1-3
> 
> Thanks,
> David