RVM
  1. RVM
  2. RVM-714

Massive increase in time to execute VM.boot

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      2

      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).

      1. verbose.out
        47 kB
        Ian Rogers
      2. VM.java
        71 kB
        Ian Rogers

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          David Grove added a comment -

          I believe Daniel fixed this in r15699.

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved: