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

Deprecate -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P3 P3
    • 10
    • hotspot
    • None
    • behavioral
    • low
    • Hide
      It is possible that these flags are in use but deprecating them will provide a warning, notifying users to fix their class loaders. Parallel-capable class loader support has been available since JDK-7 shipped in 2011. So, users of these options have had ample time to convert their code.
      Show
      It is possible that these flags are in use but deprecating them will provide a warning, notifying users to fix their class loaders. Parallel-capable class loader support has been available since JDK-7 shipped in 2011. So, users of these options have had ample time to convert their code.
    • add/remove/modify command line option
    • Implementation

      Summary

      Deprecate the related -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options. UnsyncloadClass enabled custom class loaders to avoid synchronization, preventing certain deadlocks in multithreaded cyclic custom class loaders. MustCallLoadClassInternal provided custom class loaders with a migration path towards adopting the preferred solution for these class loader deadlocks. This solution is described here: http://openjdk.java.net/groups/core-libs/ClassLoaderProposal.html

      Problem

      Both -XX:+Unsyncloadclass and -XX:+MustCallLoadClassInternal options were provided as temporary mechanisms for dealing with deadlocks in multithreaded custom class loaders that did not have an acyclic delegation model. The intent was for these options to go away once a better solution for the deadlock problem was available and users had time to migrate to this solution.

      (The deadlock scenario is described here: http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html)

      The UnsyncloadClass option means do not acquire the class loader lock even for class loaders that are not parallel capable. This was a risky transitional flag for diagnostic purposes only. It is risky to call custom class loaders without synchronization. Its default is FALSE (off).

      Option MustCallLoadClassInternal reverts to locking the class loader lock before invoking a custom class loader's findClass() or loadClass() method, even for class loaders that register as parallel capable. It was intended as a migration aid and expected to ship in product for one or two releases until it can be deprecated and safely removed. Its default is FALSE (off).

      Solution

      A better solution (parallel capable class loaders) for the class loader deadlock problem was provided as the fix for JDK-4670071 and has been available since JDK-7. So, options -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal should be deprecated for JDK-10 and eventually removed in a subsequent release.

      Specification

      . Relevant documentation is attached and can also be found here:

      http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html
      http://openjdk.java.net/groups/core-libs/ClassLoaderProposal.html

      Use of these deprecated options in JDK-10 will result in the following warnings:

      Java HotSpot(TM) 64-Bit Server VM warning: Option MustCallLoadClassInternal was deprecated in version 10.0 and will likely be removed in a future release.
      Java HotSpot(TM) 64-Bit Server VM warning: Option UnsyncloadClass was deprecated in version 10.0 and will likely be removed in a future release.

            hseigel Harold Seigel (Inactive)
            coleenp Coleen Phillimore
            Karen Kinnear (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: