Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.9.0, 2.9.0.1, 2.9.1, 2.9.2
    • Fix Version/s: 1000
    • Component/s: Runtime
    • Labels:
      None
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      JikesRVM should unload classes that are no longer in use. I finally have a benchmark that needs it

      One of the candidate benchmarks for the next release of dacapo is Apache Derby. When running the PseudoJDBCBench benchmark with Derby, dynamic SQL statements such as

      Stmt.executeUpdate("UPDATE tellers SET Tbalance = Tbalance + " + delta + " WHERE Tid = " + tid);

      result in on-the-fly creation of classes, eventually resulting in the JTOC filling up and the world ending. Running hotspot with the same benchmark and -verbose:class, we see this kind of thing

      [Loaded org.apache.derby.exe.acc87100b8x0115xea15x7ebex00000026a740c4 from org.apache.derby.impl.services.reflect.ReflectLoaderJava2]
      [Loaded org.apache.derby.exe.acc87100b8x0115xea15x7ebex00000026a740c5 from org.apache.derby.impl.services.reflect.ReflectLoaderJava2]
      [Unloading class org.apache.derby.exe.ac6dd780d4x0115xea15x7ebex00000026a74043]
      [Unloading class org.apache.derby.exe.ac1d6e40d2x0115xea15x7ebex00000026a74061]

      The problem can be reproduced by
      svn co https://dacapobench.svn.sf.net/svnroot/dacapobench/benchmarks/trunk dacapo
      cd dacapo
      ant derby.source
      ant derby jar.quick
      rvm -jar dacapo.jar derby

        Issue Links

          Activity

          Hide
          Ian Rogers added a comment -

          We need to do this, it's a fundamental bit of underlying RVM design that is wrong. From my pov I think we need to associate statics with classes and possibly do something more akin to how JNI passes around classes with static methods. We still need the JTOC for certain literals, but some of these should be either associated with a class or class loader. The cost of this needn't be devastating as classes are literals that we can fold away. Obviously we also need to hang compiled methods off of classes/class loaders to make some of this work. It's likely to have quite severe performance implications. There is also the question as to whether we can use weak references to make the reclamation of the class loader automatic, or whether we need to hand craft GC support for unloading classes.

          I think this is a big job and shouldn't be scheduled for the release of 3.0 unless someone is prepared to take charge of it.

          Related issues from SF's RFE tracker:
          1571462: Replace JTOC with per-classloader static segments
          https://sourceforge.net/tracker/index.php?func=detail&aid=1571462&group_id=128805&atid=712771
          1571374: Type dictionaries should be per-classloader, not global
          https://sourceforge.net/tracker/index.php?func=detail&aid=1571374&group_id=128805&atid=712771
          1147162: Reduce JTOC pressure of constants/static final fields
          https://sourceforge.net/tracker/index.php?func=detail&aid=1147162&group_id=128805&atid=712771

          Show
          Ian Rogers added a comment - We need to do this, it's a fundamental bit of underlying RVM design that is wrong. From my pov I think we need to associate statics with classes and possibly do something more akin to how JNI passes around classes with static methods. We still need the JTOC for certain literals, but some of these should be either associated with a class or class loader. The cost of this needn't be devastating as classes are literals that we can fold away. Obviously we also need to hang compiled methods off of classes/class loaders to make some of this work. It's likely to have quite severe performance implications. There is also the question as to whether we can use weak references to make the reclamation of the class loader automatic, or whether we need to hand craft GC support for unloading classes. I think this is a big job and shouldn't be scheduled for the release of 3.0 unless someone is prepared to take charge of it. Related issues from SF's RFE tracker: 1571462: Replace JTOC with per-classloader static segments https://sourceforge.net/tracker/index.php?func=detail&aid=1571462&group_id=128805&atid=712771 1571374: Type dictionaries should be per-classloader, not global https://sourceforge.net/tracker/index.php?func=detail&aid=1571374&group_id=128805&atid=712771 1147162: Reduce JTOC pressure of constants/static final fields https://sourceforge.net/tracker/index.php?func=detail&aid=1147162&group_id=128805&atid=712771
          Hide
          David Grove added a comment -

          Moving off of 3.0 fix target.

          This is a major piece of re-engineering. We should do it, but we should also expect it to take months if we want to do it "right" since pretty much all of the global data structures of the VM would need to be redone to localize entries on a per-classloader basis.

          It will also have rippling impact on PPC, since it probably means we have to abandon the simple "all global data is in the jtoc" strategy and PPC doesn't have as efficient ISA support for address literals as IA32 does.

          Show
          David Grove added a comment - Moving off of 3.0 fix target. This is a major piece of re-engineering. We should do it, but we should also expect it to take months if we want to do it "right" since pretty much all of the global data structures of the VM would need to be redone to localize entries on a per-classloader basis. It will also have rippling impact on PPC, since it probably means we have to abandon the simple "all global data is in the jtoc" strategy and PPC doesn't have as efficient ISA support for address literals as IA32 does.
          Hide
          Ian Rogers added a comment -

          The size of the hash maps in VM_Statics is causing us to go over the boot image size. Ideally we'd like to remove the hashmaps and just use an efficient search of the JTOC. We're discussing how literals should be organized. As literals are pulled in during the class loading process, possibly we want to think about how changes to the literals can fit in with class unloading.

          Show
          Ian Rogers added a comment - The size of the hash maps in VM_Statics is causing us to go over the boot image size. Ideally we'd like to remove the hashmaps and just use an efficient search of the JTOC. We're discussing how literals should be organized. As literals are pulled in during the class loading process, possibly we want to think about how changes to the literals can fit in with class unloading.
          Hide
          Ian Rogers added a comment -

          One way to handle literals is to place them with the code they represent, this would allow visibility using instruction pointer relative addressing.

          Show
          Ian Rogers added a comment - One way to handle literals is to place them with the code they represent, this would allow visibility using instruction pointer relative addressing.
          Hide
          Ian Rogers added a comment -

          An inefficient way to avoid placing a reference to a class in the header of the compiled code is to:

          1) get the CMID
          2) use the CMID to look up the compiled method
          3) from the compiled method lookup the method
          4) from the method get the class
          5) from the class get the statics or literals

          Problems with placing a class reference in the header to compiled code are:

          1) object model layout
          2) IA32 and PowerPC have no direct way to get the program counter/instruction pointer (Q: are static accesses so rare we can ignore this?)

          When tracing we need to start with the active compiled code and see what classes and thereby class loaders are reachable.

          Show
          Ian Rogers added a comment - An inefficient way to avoid placing a reference to a class in the header of the compiled code is to: 1) get the CMID 2) use the CMID to look up the compiled method 3) from the compiled method lookup the method 4) from the method get the class 5) from the class get the statics or literals Problems with placing a class reference in the header to compiled code are: 1) object model layout 2) IA32 and PowerPC have no direct way to get the program counter/instruction pointer (Q: are static accesses so rare we can ignore this?) When tracing we need to start with the active compiled code and see what classes and thereby class loaders are reachable.

            People

            • Assignee:
              Unassigned
              Reporter:
              Robin Garner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: