I’ve been having regular lag spikes in my FPS game, but only when I shoot a lot of bullets.
I looked into it and it’s not because of Java’s garbage collection, so that narrowed it down to bullet’s physics bodies. When I disabled them, the bullets stopped colliding but no more lag spikes, so that’s probably causing the issue.
Currently the bullets are constructed by the same 2-3 sphere collision bodies (cubes could work, if they’re faster to destroy?). I use 1 rigid body per bullet, and they’re very similar to each other. The bullets have a special contact flag (only on the server) that listen for collisions then look up the body in a hashmap to find the scenenode associated to destroy it. The issue is on the server side because after I pooled the client’s rendering of bullet objects, everything was okay on the client.
Here’s a dump from [icode]-XX:+PrintGCDetails[/icode]
[GC (Allocation Failure) [PSYoungGen: 480432K->149488K(422912K)] 835048K->579015K(880128K), 0.1422026 secs] [Times: user=0.91 sys=0.15, real=0.14 secs]
[Full GC (Ergonomics) [PSYoungGen: 149488K->119117K(422912K)] [ParOldGen: 429527K->456998K(727040K)] 579015K->576116K(1149952K), [Metaspace: 20826K->20826K(1069056K)], 1.3909805 secs] [Times: user=10.41 sys=0.04, real=1.39 secs]
So it’s clear Garbage collection is the issue, and it’s something I don’t know much about. Bullet could be causing the issue, but could it be my lazy allocation of vectors and objects? Should I be pooling more classes (they’re a bitch to set up)?
EDIT: Here’s some info from after 2 mins of gameplay
Heap
PSYoungGen total 422912K, used 224087K [0x00000000d6500000, 0x0000000100000000, 0x0000000100000000)
eden space 273408K, 38% used [0x00000000d6500000,0x00000000dcb825d8,0x00000000e7000000)
from space 149504K, 79% used [0x00000000f6e00000,0x00000000fe2537f8,0x0000000100000000)
to space 204800K, 0% used [0x00000000e7000000,0x00000000e7000000,0x00000000f3800000)
ParOldGen total 727040K, used 456998K [0x0000000082e00000, 0x00000000af400000, 0x00000000d6500000)
object space 727040K, 62% used [0x0000000082e00000,0x000000009ec49ac0,0x00000000af400000)
Metaspace used 20865K, capacity 21197K, committed 21376K, reserved 1069056K
class space used 2045K, capacity 2139K, committed 2176K, reserved 1048576K