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

David Holmes david.holmes at oracle.com
Fri Sep 13 09:12:14 UTC 2019

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().

  - hotspot runtime
  - Tiers 1-3


More information about the hotspot-dev mailing list