Strange freeze in FloatFFT_2D.realForwardFull when array reaches certain size

[jmpFCE2]

I am experiencing a very strange "freeze". Originally in a larger application, I have reduced my test case to the code below. The "freeze" occurred with JTransforms-3.1-with-dependencies. To pinpoint where the freeze occurs, I downloaded the source of both JTransforms and JLargeArrays from github / gitlab on January 9th and created fresh jars. I added a couple of "println"s to JTransforms and JLargeArrays. Aside from pinpointing the location of the freeze, these also confirm that these jars are being used instead of another version potentially lurking in my classpath (to the best of my knowledge I removed all versions of JTransforms/JLargeArrays from the classpath).

The test code is:

 import pl.edu.icm.jlargearrays.*;
 import org.jtransforms.fft.*;
 import java.util.Arrays;

 public class Jttest {

  public static void main(String[] args) {
    test();
  }

  public static void test() {
    int dims[] = { 4097, 4097 };

    FloatLargeArray extra[] = new FloatLargeArray[3];

    int ix=0;
    while( true ) {
      int nel = 2*dims[0]*dims[1];
      FloatLargeArray data = new FloatLargeArray(nel);
      // allocate a few extra arrays to show that we have not run out of memory.
      // the behaviour is the same with the following lines in place or not
      for ( int ii=0; ii<extra.length; ii++ ){
        extra[ii] = new FloatLargeArray(nel);
      }
      // this is the size that is reported just before the code hangs.
      // I allocated a same-size array here to verify it is not the specific
      // size that is the issue
      FloatLargeArray dummy = new FloatLargeArray(16793604);
      System.out.format("data length=%d   dims=%s\n",data.length(),Arrays.toString(dims));
  
      FloatFFT_2D dft2d = new FloatFFT_2D( dims[0], dims[1] );
      System.out.println("Invoking dft2d");
      dft2d.realForwardFull( data );
      System.out.println("Done");
      // alternatingly increase the x- or y-size of the 2D array
      dims[ix]+=1;
      ix=1-ix;
    }
  }
}

On my machine, this code freezes as soon as dims reaches [4098,4097]. Suspiciously close to the nice power-of-two size [4096,4096] of course, but nothing indicates that this in fact has anything to do with it. The output is:

...
allocating 16789506
new FloatLargeArray done
allocated pl.edu.icm.jlargearrays.FloatLargeArray@7023090a
Done
...

data length=33579012   dims=[4098, 4097]
Invoking dft2d
JT: RFF
JT: RFF (mixed)
allocating 16793604
new FloatLargeArray done

Interestingly, I am pretty sure the process was shown as idle before ("0% cpu") one every attemp yesterday, but as I tried it just now it shows "100% cpu". Top also states "12.1% memory", so again the process cannot be running out of memory.

The key "print" statements are in:

FloatFFT2D.java:

    private void mixedRadixRealForwardFull(final FloatLargeArray a)
    {
        final long rowStride = 2 * columnsl;
        final long n2d2 = columnsl / 2 + 1;
        System.out.format("allocating %d\n",n2d2 * 2 * rowsl);
        final FloatLargeArray temp = new FloatLargeArray(n2d2 * 2 * rowsl);
        System.out.format("allocated %s\n",temp.toString());

If successful, the last line outputs something like allocated pl.edu.icm.jlargearrays.FloatLargeArray@7023090a. However, when the code freezes, it does so before reaching the second System.out.format statement.

In FloatLargeArray.java:

   public FloatLargeArray(long length)
    {
        this(length, true);
        System.out.println("new FloatLargeArray done");
    }

Checking the output of the code, it appears that the FloatLargeArray constructor works up to and including the println I added, but the code then freezes.

Finally, system details, Fedora 27 64bit Linux, 8Gb memory, with:

java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

• Any idea what might be going on?
• Can anyone reproduce this behaviour?
• Let me know if any extra information is required

Regards, Michael