Java – after GC applications run slowly

I have an application (game) running on the JVM

The game's update logic (run 60 times / second) is complete, about 25% use its "time slice" (1 / 60 second), and then sleep the remaining 75% However, when the GC collector is running, it will rise to 75-200% and remain unchanged for the rest of the execution

The game uses a heap of about 70mb and grows by about 1-2mb / s. when GC runs, it will return to 70mb, so there is no real memory leak I will try to reduce this number in the future, but it should not be a problem in this range

I'm using JVM 8 without runtime parameters or flags. I'm not sure which GC will give me

I've tried to set the heap to a different size, but it won't affect this phenomenon

I have two theories about why this happens:

>GC inadvertently segmented my heap, resulting in cache obsolescence in the update cycle I have logic. It can benefit from data proximity because it loops and updates it Maybe it reorganizes some data into old areas while retaining some young people (nurseries)? > The sudden GC processing triggered my operating system and made it realize that my main update step did not require as much CPU resources as now, reducing its priority However, even if I skip thread. Sleep () to sleep unused CPU usage, this phenomenon still exists

What's your opinion? Are my theories reasonable, what can I do about them, or do I need to switch to C? My knowledge of GC is limited

Attachment: as a note, update () usually ends at 75% after GC When I get 200% of the number, I use Vsync

Solution

The first theory seems reasonable, but the second theory is not

You can improve by:

>Increase the maximum heap size. > Switch to low pause collector. > Performance optimization based on analytic application results. > Try to reduce the rate of garbage generation

C and C will give you more predictable behavior because nothing can move objects If you have the skills and work hard, you should be able to get better performance in C and C, especially when graphics / rendering However, these are big "ifs"