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().
Testing:
- hotspot runtime
- Tiers 1-3
Thanks,
David
More information about the hotspot-dev
mailing list