RFR: 8036128 Remove deprecated VM flag UseVMInterruptibleIO

David Holmes david.holmes at oracle.com
Fri Mar 7 04:40:40 UTC 2014

Hi Fred,

This looks good to me! Great to see the cleanup happen.


This comment block seems redundant now:

5264       /*
5265       * XXX: is the following call interruptible? If so, this might
5266       * need to go through the INTERRUPT_IO() wrapper as for other
5267       * blocking, interruptible calls in this file.
5268       */


Aside: arguments.cpp - I guess we can file an RFE to get rid of 
obsolete_jvm_flags now that hsx is dead. ;-)


On 7/03/2014 2:12 AM, frederic parain wrote:
> Greetings,
> The UseVMInterruptibleIO flag removal has been
> scheduled a long time ago:
> https://bugs.openjdk.java.net/browse/JDK-4385444
> Now, it's time to effectively remove this flag and
> its associated code.
> Removing this feature includes removing all the
> macros used to deal with interruptible I/Os, which
> could make the reading of the webrev hard and painful.
> I conservatively preserved the asserts that were
> inserted by the INTERRUPTIBLE macros, with one
> notable exception for os::read(). The original
> asserts checked that the current ThreadState
> was not _thread_in_native nor _thread_blocked.
> I changed it into an assert checking that the
> current thread state is _thread_in_vm. The
> rational for that is that the only real usage
> of os::read() on Solaris is in the
> ClassPathDirEntry::open_stream() method, which
> is always called with ThreadState ==_thread_in_vm.
> This change makes the TreadStateTransition simpler
> and avoid having to store the previous ThreadState.
> This choice could be revisited once the rules
> for ThreadStateTransition around system calls
> when ThreadState is _thread_in_vm are clarified
> (Solaris is currently the only platform doing
> this kind of transition for os::read()).
> The CR:
> https://bugs.openjdk.java.net/browse/JDK-8036128
> The webrev:
> http://cr.openjdk.java.net/~fparain/8036128/webrev.00/
> Tested with vm.quick.testlist and JPRT hotspot job.
> Thanks,
> Fred

More information about the hotspot-runtime-dev mailing list