Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8029891

Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

    Details

      Description

       java/lang/ClassLoader/deadlock/GetResource.java fails by timeout

      win32, jdk8 b119 and macos, pit jdk8 b120 (fastdebug).

      See jtrs attached.

      deadlock?
      1. GetResource-mac.jtr
        9 kB
        Dmitry Fazunenko
      2. GetResource-win.jtr
        9 kB
        Dmitry Fazunenko

        Issue Links

          Activity

          Hide
          plevart Peter Levart added a comment -
          @Mandy - The Serializable javadoc says:

           * Classes that require special handling during the serialization and
           * deserialization process must implement special methods with these exact
           * signatures:
           *
           * <PRE>
           * private void writeObject(java.io.ObjectOutputStream out)
           * throws IOException
           * private void readObject(java.io.ObjectInputStream in)
           * throws IOException, ClassNotFoundException;
           * private void readObjectNoData()
           * throws ObjectStreamException;
           * </PRE>

          ...so one can not inherit or override readObject/writeObject from a superclass. Since those two methods are meant to (de)serialize object state belonging to a particular class (without super or sub class state), this is understandable. To keep the Properties serialization format unchanged, it is important that the part of stream that gets (de)serialized as Hashtable class state is written/read as part of Hashtable.[writeObject,readObject] methods. In proposed patched Properties this state is moved to the embedded CHM, but must nevertheless be (de)serialized as part of Hashtable.[writeObject,readObject] methods. I think what I have proposed is the most simple way to achieve that.
          Show
          plevart Peter Levart added a comment - @Mandy - The Serializable javadoc says:  * Classes that require special handling during the serialization and  * deserialization process must implement special methods with these exact  * signatures:  *  * <PRE>  * private void writeObject(java.io.ObjectOutputStream out)  * throws IOException  * private void readObject(java.io.ObjectInputStream in)  * throws IOException, ClassNotFoundException;  * private void readObjectNoData()  * throws ObjectStreamException;  * </PRE> ...so one can not inherit or override readObject/writeObject from a superclass. Since those two methods are meant to (de)serialize object state belonging to a particular class (without super or sub class state), this is understandable. To keep the Properties serialization format unchanged, it is important that the part of stream that gets (de)serialized as Hashtable class state is written/read as part of Hashtable.[writeObject,readObject] methods. In proposed patched Properties this state is moved to the embedded CHM, but must nevertheless be (de)serialized as part of Hashtable.[writeObject,readObject] methods. I think what I have proposed is the most simple way to achieve that.
          Hide
          bchristi Brent Christian added a comment - - edited
          I've written a test to detect if methods are added to Map or Hashtable, but not overridden in Properties.
          I plan to move forward with a fix, based on Peter's webrev. Thanks.

          Show
          bchristi Brent Christian added a comment - - edited I've written a test to detect if methods are added to Map or Hashtable, but not overridden in Properties. I plan to move forward with a fix, based on Peter's webrev. Thanks.
          Hide
          bchristi Brent Christian added a comment -
          All the method overrides needed to embed a CHM within Properties causes something of an explosion of additional JavaDoc. See http://cr.openjdk.java.net/~bchristi/8029891/webrev.3/specdiff-plain/Properties.html.

          It would be preferable to wait for something like a @nodoc tag, as suggested in JDK-8073100.
          Show
          bchristi Brent Christian added a comment - All the method overrides needed to embed a CHM within Properties causes something of an explosion of additional JavaDoc. See http://cr.openjdk.java.net/~bchristi/8029891/webrev.3/specdiff-plain/Properties.html . It would be preferable to wait for something like a @nodoc tag, as suggested in JDK-8073100 .
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0
          User: bchristi
          Date: 2016-05-19 23:25:51 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0 User: bchristi Date: 2016-05-19 23:25:51 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/01a8615439f0
          User: lana
          Date: 2016-05-25 17:36:43 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/01a8615439f0 User: lana Date: 2016-05-25 17:36:43 +0000

            People

            • Assignee:
              bchristi Brent Christian
              Reporter:
              dfazunen Dmitry Fazunenko (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: