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

JVM crash in custom classloader stress test, JDK 12 & 13

    Details

    • Subcomponent:
    • Resolved In Build:
      b09
    • CPU:
      x86
    • OS:
      linux

      Backports

        Description

        JVM is crashing when running a classloading and unloading stress program on JDK 12-b30, and JDK 13-b7 on Linux configured to use ZGC. Have been able to reproduce the crash on a 2 socket Westmere EP, but not on a single socket Sandy Bridge. An hs*err.log from a fast debug JVM built against the JDK 13 repo is attached.

        The stress program that runs a random number of threads, between 1 and # of hardware threads on the machine. Each thread randomly selects one of 15 jar files, and loads all classes from that jar file using a custom classloader. There is a custom classloader class for each of the 15 jar files. In other words, there are 15 custom classloader classes. Each thread creates an instance of a custom classloader that will load all classes in jar that maps to that custom classloader. There can be multiple custom classloader instances loading classes from the same jar file.
        After each class is loaded, the program asks for the list of methods in the class that has just been loaded from the jar file. Both the custom classloader instance, the names of the classes loaded and class method names are saved for potential use later. If a class (or dependent class) has already been loaded, identified by a LinkageError, a count is incremented for the jar file indicating how many classes had already been loaded. This count is also preserved. Not ideal that LinkageErrors can occur.
        Once all classes in a jar file are loaded by a custom classloader, the thread passes back the class names, their method names and number of classes already loaded to the main thread. The main thread randomly selects a set of classes that have been loaded to be preserved for a time period between 30 seconds and 3 minutes. Those that are randomly selected are given to an “aging thread”. The aging thread takes the set of classes that have been loaded and attempts to create object instances for the classes that have been loaded. The aging thread continues to do this until the "preserved time" has been exceeded. Once the "preserved time" has been exceeded, the custom classloader instance and the classes it loaded, and new instances allocated are released and eligible to be garbage collected.
        All the above continues to run for up to 6 hours.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  coleenp Coleen Phillimore
                  Reporter:
                  huntch Charlie Hunt
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: