8022594: Potential deadlock in <clinit> of sun.nio.ch.Util/IOUtil

Chris Hegarty chris.hegarty at oracle.com
Wed Aug 28 05:48:33 PDT 2013


The changes look good to me Alan.

I verified that the removal (IO)Util.load should be fine where you have 
done it, as those classes don't have native methods.

Trivially, I don't think SctpMultiChannelImpl or SctpServerChannelImpl 
need to call IOUtil.load ( or load libsctp ) as they don't have any 
native methods, but I appreciate you fixing these and understand if you 
don't want to change them as part of this changeset.

-Chris.

On 26/08/2013 09:54, Alan Bateman wrote:
>
> Jeremy Manson recently reported a sighting of a deadlock at startup in
> the static initializers that are involved in loading libnio/equivalent [1].
>
> Digging through the JDK 1.4/1.5 era history then it seems there were
> other issues that lead to the current implementation. Looking at now and
> since sun.nio.ch.Util doesn't have any native methods then the simplest
> thing to do (but not the only solution) is to move the loading of the
> native libraries to IOUtil. That eliminates the need for the additional
> locking.
>
> The webrev with the changes is here:
>
> http://cr.openjdk.java.net/~alanb/8022594/webrev/
>
> The patch does not include a test as this is a deadlock at startup that
> just isn't easy to reproduce (at least not on the systems that I tried).
>
> -Alan
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019630.html
>


More information about the nio-dev mailing list