jme3-jbullet limits apps to one thread per physics space. By default, jme3-jbullet simulates physics on the render/update thread, but there’s an option (BulletAppState.ThreadingType.PARALLEL) to simulate physics on a separate thread.
For the option to have much performance benefit, each thread would have to fully utilize a CPU. For most apps, the headaches of ensuring thread safety outweigh the performance benefits.
Minie also offers the ThreadingType.PARALLEL option, with similar caveats. But it also provides a multi-threaded library that allows multiple worker threads per physics space. The two kinds of multi-threading can be used separately or combined.
Minie’s default library (“8.1.0”) is one thread per physics space. The multi-threaded library flavor (“8.1.0+mt”) implements multiple worker threads per physics space, but only for Linux and Windows—no macOS or Android. The number of worker threads per space is limited to 2.
Back in 2021, I ran some performance measurements and profiling of multi-threaded Minie. For the workload and systems I studied, there was no performance gain beyond 2 worker threads. I suspected a memory-bandwidth bottleneck:
I’d welcome further investigations of multi-threaded Minie.