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

Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P3 P3
    • 20
    • hotspot
    • None
    • behavioral
    • medium
    • Hide
      If an application using non-parallel capable loaders that depend on this legacy parallel class loading behavior, they will have to run with ` -XX:+EnableWaitForParallelLoad` flag. In addition, those custom class loaders need to migrate to parallel-capable class loaders with multi-threading support as soon as possible.
      Show
      If an application using non-parallel capable loaders that depend on this legacy parallel class loading behavior, they will have to run with ` -XX:+EnableWaitForParallelLoad` flag. In addition, those custom class loaders need to migrate to parallel-capable class loaders with multi-threading support as soon as possible.
    • add/remove/modify command line option
    • JDK

      Summary

      Deprecate and disable the legacy parallel class loading workaround for non-parallel-capable class loaders.

      Problem

      Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock (see [1] for details). A workaround was added in the VM in JDK 6 to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. In addition, the VM also supports a common workaround at the time that some customers explicitly issue a wait() on the class loader lock.

      Parallel-capable class loaders (CCC-4735126) are defined in Java SE 7 to support parallel class loading to implement a deadlock-free class loader using non-hierarchical class delegation model. [1] and [2] describe how to migrate those class loaders depending on this workaround to be multi-threaded parallel-capable class loaders. The workaround was intended to allow those customers to migrate to the new mechanism. It has been 11 years since JDK 7 and it's expected that those deadlock-prone custom class loaders should have migrated to the parallel-capable class loaders.

      It is time to deprecate and remove this workaround as it is an impediment to the project to eliminate the object monitors from pinning for virtual threads.

      [1] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html

      [2] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html

      Solution

      Deprecate and disable the legacy parallel class loading workaround for non-parallel-capable class loaders. -XX:+EnableWaitForParallelLoad can be used to enable this legacy workaround. This VM flag will be removed in a future release.

      Specification

        product(bool, EnableWaitForParallelLoad, false,               \
                "(Deprecated) Enable legacy parallel classloading logic for "     \
                "class loaders not registered as parallel capable")               \

      EnableWaitForParallelLoad is false by default. -XX:+EnableWaitForParallelLoad can be used to enable this legacy workaround. This VM flag will be removed in a future release.

            mchung Mandy Chung
            mchung Mandy Chung
            Coleen Phillimore, David Holmes
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: