[Solved] GDX Bullet - Lag Spikes

Newbie & Debugging Questions
#1

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
#2

Just another update, I doubt this problem has anything to do with bullet anymore. I believe it’s because of the quick destruction / allocation of game-bullet objects (not the physics engine).

But it is a major problem in the game, for example here’s a GC that took 1.3 seconds.
[icode][GC (Allocation Failure) [PSYoungGen: 435184K->87520K(435200K)] 637269K->377023K(727552K), 0.1319983 secs] [Times: user=0.67 sys=0.14, real=0.13 secs]
[Full GC (Ergonomics) [PSYoungGen: 87520K->81929K(435200K)] [ParOldGen: 289503K->291954K(486912K)] 377023K->373884K(922112K), [Metaspace: 19473K->19473K(1067008K)], 1.3118031 secs] [Times: user=9.42 sys=0.06, real=1.32 secs][/icode]

Is there a reason I’d be getting such high garbage? I’ve noticed garbage only collects badly on the client, which I’m investigating…

Any insight on garbage collection in general is good too, honestly anything to stop this frustrating spike.

#3

Well, try running some memory profiling using VisualVM. It can log stack traces of all allocations you do.

#4

One of these things is not like the other…

698×332 7.45 KB

Thanks again agentd ::slight_smile:

#5

Wait, so your issue was just a crapload of hashmap insertion? =P

#6

After removing particles…

[GC (Allocation Failure) [PSYoungGen: 266512K->2345K(424960K)] 271318K->10588K(510976K), 0.0068641 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 419625K->1088K(425472K)] 427868K->11496K(511488K), 0.0067553 secs] [Times: user=0.02 sys=0.01, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 418368K->1120K(399872K)] 428776K->12265K(485888K), 0.0063036 secs] [Times: user=0.02 sys=0.01, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 399456K->736K(381440K)] 410601K->12697K(467456K), 0.0056724 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 381152K->704K(364032K)] 393113K->13160K(450048K), 0.0037251 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]

The problem was particles were only removed from the tracking Hashmap when complete (and many of my particles don’t complete).
So yes !

VirtualVM is a sweet tool, I really should have heard about it earlier. Thanks!

#7

ViSualVM is awesome, yeah. It’s really good for finding out where your garbage is coming from and can give you a good indicator of hotspots in your code. It can however sometimes be a bit confusing though and the profiler generally makes games drop to 0.01 FPS or so. =/