Trying to place a grid of boxes, slows down exponentially

I have the following code to create boxes with a physics node from JMEphysics. I use a simple nested for loop to draw/place a 32x32 grid of these boxes on a textured 1000x1000 floor.

The first row of boxes is placed lightning fast, as expected. The second slows down, the third one crawls, and the fourth one is like molasses through a straw. If I wait long enough, it even crashes. What am I doing wrong here? Am I leaking something?

public void createCube(int x, int y) {
   Box b = new Box("My Box", new Vector3f(0,0,0), new Vector3f(1,1,1));
      b.rotateUpTo(new Vector3f(0,0,-1));
      b.setModelBound(new BoundingSphere());
        PhysicsNode box = getPhysicsSpace().createStaticNode();
           box.setLocalTranslation(new Vector3f(x,0,y)); // middle one is vertical?!! WTF
         box.createBox("falling box"); //simple physicsbox

How many boxes do you want to create? 3232 like 1024?

If i set gravity to 0 i can create a Wall of 30
30 Boxes, but this only works because they don't collide.

As soon as you add gravity and the boxes collide it will either crash ode or the framerate will be too low to be useful.

To avoid the crash, you can increase the native stacksize with "-Xss1m".

Assuming there are no pruning heuristics, the work a physics system needs to do goes up with the square of the number of moving objects its controlling as it has to test every moving object for collision with every other object in its world every frame.  If you are exetring gravity, then all the objects are in motion.

So, your seeing exactly what is expected if you are cpu-bound (and it sounds like you are.)

Most of the solutions involve bounding volumes and spatial subdivision so you can eliminate pairs quickly and without a full collision test.

what you can do is play with the PhysicsSpace.setAutoRestThreshold() value, i think this could help quite a bit in your case.