Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-714

Massive increase in time to execute VM.boot

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Highest
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      r15151("Fix for RVM-700, failure for ServerSockets to work.") has caused a large amount of class loading to occur during VM.boot. This has increased the boot time by a factor of 10 on my system (0.5s to 5s).

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              dgrove David Grove added a comment -

              The classloading seems to be triggered by the appearance of Foo.class.getName() for most of the crypto classes.

              Interestingly, all we have to do to allow class.getName to complete is to load & resolve the class (we aren't instantiating it). A sleazy trick would be to add another list of classes to the primordials which would be loaded and resolved, but not instantiated/initialized. This would reduce the work done during booting without having to handle re-running static initializers.

              Show
              dgrove David Grove added a comment - The classloading seems to be triggered by the appearance of Foo.class.getName() for most of the crypto classes. Interestingly, all we have to do to allow class.getName to complete is to load & resolve the class (we aren't instantiating it). A sleazy trick would be to add another list of classes to the primordials which would be loaded and resolved, but not instantiated/initialized. This would reduce the work done during booting without having to handle re-running static initializers.
              Hide
              pizlo Filip Pizlo added a comment -

              We (Daniel and I) found the reason. It's InetAddress's static initializer. That was the fix for RVM-700 - running it eagerly. It turns out this static initializer takes a few seconds, because it tries to resolve 0.0.0.0 to a name (getHostByAddr), which on all of our machines at least, takes a long time.

              This is a classpath bug. InetAddress should be initialized at some point no matter how you look at it. And it shouldn't take that long.

              The fix I would propose is to put an entry of 0.0.0.0 into java.net.ResolverCache, at least, provided that we know, for all reasonable platforms, what 0.0.0.0's name is "supposed" to be according to Java.

              -F

              Show
              pizlo Filip Pizlo added a comment - We (Daniel and I) found the reason. It's InetAddress's static initializer. That was the fix for RVM-700 - running it eagerly. It turns out this static initializer takes a few seconds, because it tries to resolve 0.0.0.0 to a name (getHostByAddr), which on all of our machines at least, takes a long time. This is a classpath bug. InetAddress should be initialized at some point no matter how you look at it. And it shouldn't take that long. The fix I would propose is to put an entry of 0.0.0.0 into java.net.ResolverCache, at least, provided that we know, for all reasonable platforms, what 0.0.0.0's name is "supposed" to be according to Java. -F
              Hide
              ianrogers Ian Rogers added a comment -

              Makes sense. I'm also not sure we should be doing so much static initialization as this implies loading, linking and compilation. The trace above gives more details.

              Show
              ianrogers Ian Rogers added a comment - Makes sense. I'm also not sure we should be doing so much static initialization as this implies loading, linking and compilation. The trace above gives more details.
              Hide
              pizlo Filip Pizlo added a comment -

              FYI. This happens on Ubuntu but not on Fedora.

              On my Ubuntu box:

              [pizlo@dethklok test] time ~/Programs/RVM-trunk/dist/BaseBaseMarkSweep_x86_64-linux/rvm hello
              hello!

              real 0m5.682s
              user 0m0.604s
              sys 0m0.060s

              Over 5 seconds to print hello. On the Fedora box, it's half a second for the same configuration.

              I'm poking around with this to see if I can come up with an elegant solution on our end...

              Show
              pizlo Filip Pizlo added a comment - FYI. This happens on Ubuntu but not on Fedora. On my Ubuntu box: [pizlo@dethklok test] time ~/Programs/RVM-trunk/dist/BaseBaseMarkSweep_x86_64-linux/rvm hello hello! real 0m5.682s user 0m0.604s sys 0m0.060s Over 5 seconds to print hello. On the Fedora box, it's half a second for the same configuration. I'm poking around with this to see if I can come up with an elegant solution on our end...
              Hide
              dgrove David Grove added a comment -

              I believe Daniel fixed this in r15699.

              Show
              dgrove David Grove added a comment - I believe Daniel fixed this in r15699.

                People

                • Assignee:
                  zyridium Daniel Frampton
                  Reporter:
                  ianrogers Ian Rogers
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: