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

StringBuffer is faster on Windows (C1) than Solaris x86 (C2)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Not an Issue
    • Affects Version/s: 1.4.2, 1.4.2_04
    • Fix Version/s: None
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_9

      Description

      A simple application which creates a StringBuffer and updates it (JProva.java) is running 3 time faster on windows machines than on solaris server using 1.4.2 or 1.5.0 beta2
      It is faster on machines with a better cpu clock (no I/O in the testcase)
      Even using a multithreaded version (Test.java) it is faster on Windows (1 P4) than Solaris x86 (2 cpu, virtual 4) when running 50 threads

      HW OS java Cpu Mem 1 5 10 20 30 40 50
      ======================================================================================================================
      V65x S10_55 1.4.2_04-b05 (C2) 2xIntelXeon3GHz - 5189 16075 32148 65817 100468 136357 173739
      Oracle W2000SP3 1.4.1_02-b06 (C1) IntelXeon2.4GHz 768MB 2766 12078 23968 49922 78656 109719 144313


      JProva.java

      import java.io.*;

      class JProva {
      public static void main (String args[]) {
      int max = 0;
      long millis;

      millis = System.currentTimeMillis();
      for(int k = 0 ; k < 1000000; k++)
      {
      StringBuffer buffer = new StringBuffer(" ");
      String a1 = "cgghghghghghhhhhgd";
      String a2 = "12";
      String a3 = "XXXXXXX";
      String a4 = "";
      String a5 = "";
      String a6 = "-ggggggggggggg";
      String a7 = "-";
      String a8 = "ggggg-";
      char c;
      int i;
      int j = 0;

      String str = a1;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a2;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a3;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a4;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a5;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a6;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a7;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));
      j += 20;
      str = a8;
      for(i=0; i<str.length(); ++i) buffer.setCharAt(j+i, str.charAt(i));

      if (k==0) System.out.println(buffer);
      }
      System.out.print("Durata: ");
      System.out.println((System.currentTimeMillis()-millis));

      }

      }

      With -Xrunhprof profiling we see that 99% of the time is spent in the new StringBuffer and the StringBuffer.<init>

      See details in performance.html (JProva with a graph) and StringBuffer-Performance.html (both tests) and all the java.cpu* logs from profiling

      http://pluto.italy.sun.com/Case/COFACE/37134601/performance.html
      http://pluto.italy.sun.com/Case/COFACE/37134601/StringBuffer-Performance.html

      Solaris:

      java -server -Xrunhprof:cpu=y,file=java.cpu.loop.Test,depth=5 Test 50 prime

      TRACE 13:
          Test$Work.test(Test.java:82)
          Test$Work.run(Test.java:73)
          java.lang.Thread.run(Thread.java:534)

      TRACE 12:
          java.lang.StringBuffer.<init>(StringBuffer.java:115)
          java.lang.StringBuffer.<init>(StringBuffer.java:130)
          Test$Work.test(Test.java:82)
          Test$Work.run(Test.java:73)
          java.lang.Thread.run(Thread.java:534)

      CPU SAMPLES BEGIN (total = 338182) Mon May 24 19:14:17 2004
      rank self accum count trace method
         1 72.05% 72.05% 243645 13 Test$Work.test
         2 27.75% 99.79% 93837 12 java.lang.StringBuffer.<init>
         3 0.06% 99.85% 191 16 Test$Work.test
         4 0.05% 99.90% 178 15 Test$Work.test
         5 0.03% 99.93% 109 10 java.io.FileInputStream.readBytes
         6 0.03% 99.96% 88 17 Test$Work.test
         7 0.02% 99.98% 81 18 Test$Work.test
      CPU SAMPLES END

      Windows:

      java -Xrunhprof:cpu=y,file=javaCpuTest.txt,depth=5 Test 50 prime

      TRACE 7:
              Test$Work.test(Test.java:82)
              Test$Work.run(Test.java:73)
              java.lang.Thread.run(Thread.java:536)

      TRACE 8:
              java.lang.StringBuffer.<init>(StringBuffer.java:115)
              java.lang.StringBuffer.<init>(StringBuffer.java:130)
              Test$Work.test(Test.java:82)
              Test$Work.run(Test.java:73)
              java.lang.Thread.run(Thread.java:536)

      CPU SAMPLES BEGIN (total = 16788) Tue May 25 18:02:04 2004
      rank self accum count trace method
         1 50.36% 50.36% 8455 8 java.lang.StringBuffer.<init>
         2 49.29% 99.65% 8274 7 Test$Work.test
         3 0.33% 99.98% 56 4 java.io.FileInputStream.readBytes
      CPU SAMPLES END

      where Test.java:82 is: buffer = new StringBuffer(" ");

      Adding the test without hostspot we see that behaviour is similar on different Operating Systems

      Running: java [-server] -XX:+PrintCompilation Test prime

      Platform -client -server -Xint
      ----------------------------------------------------------------
      Blade 2x1.2GHz 8257 7043 57703
      x86 Linux P3-450Mhz 10042 7502 98358
      x86 Win2k P3-550Mhz 8140 6578 74718
      AMD =~ 2ghz 2672 ? 23829
      Opteron Linux 2x1.4GHz 2403 2065 26491
      v65xc-gmp02 3ghz? sol 5364 5185 21861

      It seems that creation and initialization of StringBuffer is slower on Solaris hotspot than Windows hotspot

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              collins Gary Collins (Inactive)
              Reporter:
              cmassi Claudio Massi (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: