Java – recursive code that runs slowly on the UNIX box but fast on windows

I have a java code, which is a combination of while loop and recursion The problem we face is that for the UNIX box [HP ProLiant BL460c G7], the time required to call the following methods is almost 8 times that of the windows box [Intel Xeon CPU e5-1650,64 bit Windows 7] Any ideas on how to improve execution time in UNIX boxes

protected Date abc(int n,Date date) 
{
    long tStart = System.currentTimeMillis();

    if (n > 0) 
    {
          while (n > 0)
          {
                --n;
                date = getNextExchangeDateUnadjusted(date);
          }

          return date;
    }
    else 
    {

          Date nextExchangeDate = getNextExchangeDateUnadjusted(date);

          Date prevIoUsExchangeDate = getNextExchangeDateUnadjusted(date);

          while (!abc( -n + 1,prevIoUsExchangeDate).equals(nextExchangeDate)) 
          {

                date = date.addDays( -14);

                prevIoUsExchangeDate = getNextExchangeDateUnadjusted(date);

          }

          return prevIoUsExchangeDate;
    }
}

Edit:

The following is the code of the getnextexchangedateunadjusted method called above

public Date getNextExchangeDateUnadjusted(Date date) {
    // Third Wednesday of each month
    Date thirdWednesdayInMonth = date.getThirdWednesdayInMonth();
    if (thirdWednesdayInMonth.after(date)) {     
      return thirdWednesdayInMonth;
    }
    return date.addMonths(1).getThirdWednesdayInMonth();
  }
}

Also want to add the code that will take the most time in this section:

while (!abc( -n + 1,prevIoUsExchangeDate).equals(nextExchangeDate)) 
      {

            date = date.addDays( -14);

            prevIoUsExchangeDate = getNextExchangeDateUnadjusted(date);

      }

EDIT2：

With the progress of the process, we have performed many heap dumps on UNIX machines and found that the "reserved heap" has increased from about 1MB to 450MB, so the stack size is increasing significantly Not sure if this will cause performance degradation We will now dump the heap in windows and will also try to change the stack size using XSS

Solution

Adopt a multi pronged approach to solve this problem:

>We exclude any IO or remote calls that cause unnecessary delays. > Get the heap dump through visual VM to view any abnormal behavior in the process and compare it between UNIX and windows The main thread we can trace here occupies 4.5mb of stack space, but it is the same in UNIX and windows. > Now the only option left is to check whether there is any gap between the JVM on UNIX and windows, and whether there is any optimization gap between 2

The problem is found in part 3. The following is the gap when we run the command Java - version

>On Windows

Java version "1.6.0_43"

Java (TM) se runtime environment (version 1.6.0_43-b01)

Java hotspot (TM) 64 bit server VM (built-in 20.14-b01, mixed mode) > on UNIX

Java version "1.6.0_43"

Java (TM) se runtime environment (version 1.6.0_43-b01)

Java hotspot (TM) 64 bit server VM (version 20.14-b01, interpretation mode)

You can see the obvious difference of JVM hotspot mode between UNIX and windows In further investigation, we found that the JVM running in interpreted did not optimize the code [described in detail in this article: https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-1-jvm-types-and-compiler-modes/ ]So we started our process on the UNIX machine, marked - xmixed, which forced the JVM to work in mixed mode This solves our problem. UNIX and windows have the same performance

Edit:

Due to this parameter in the UNIX box, the JVM is pushed to the interpretation mode: - DJava compiler = NONE