0

I want to speed up my JAVA app, and come up with the following questions. Thanks in advance.

1 For HotSpot JVM young generation, is it possible to skip garbage collection (gc) for the most newly allocated objects in eden? For example, we skip the top 30% most newest objects in eden area.

2 How to reduce the time for the new generation gc? The response time of a workflow is expected to be less than 10 ms, but the copying process of gc for new generation alone takes 8 ms.

Wen-Hua
  • 11

3 Answers3

1

1 For HotSpot JVM young generation, is it possible to skip garbage collection (gc) for the most newly allocated objects in eden? For example, we skip the top 30% most newest objects in eden area.

When you clean up Eden, it is all or nothing. The newest objects are more likely to be in the survivor space and be cleaned up in the next collection.

2 How to reduce the time for the new generation gc? The response time of a workflow is expected to be less than 10 ms, but the copying process of gc for new generation alone takes 8 ms.

The JVM is not a hard real time system. This means there is always a chance it will pause for 10 ms even without a GC. Instead of saying 10 ms response, a more realistic goal is to have < 10 ms 99% of the time. This allows for some small collections.

If you want to really reduce GC pause times you can either; use Azul Zing as it has a concurrent collector (commercial), or reduce the amount of garbage you product to less than your eden size in a day. e.g. set the eden size to 24 GB and produce less than 1 GB per hour.

kittylyst
  • 5,640
  • 2
  • 23
  • 36
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
1

How to reduce the time for the new generation gc?

  • make sure you're using a multi-threaded GC algorithm (ParNew, ParallelScavenge or G1GC)
  • reduce the size of the young generation
    • this will lead more frequent but shorter young gen GCs and more promoted objects which means more frequent old gen collections
    • that can be countered by profiling the application's object allocations and optimizing hotspots to reduce the allocation rate
  • throw money at the problem: get a faster CPU / more memory bandwidth
  • throw even more money at it: azul zing
the8472
  • 40,999
  • 5
  • 70
  • 122
0

There are certain characteristics of GC that you should optimize, to reduce its overhead on application performance. Like throughput and latency, these GC characteristics should be observed over a long-running test to ensure that the application can handle variance in traffic while going through multiple GC cycles. 1. Stop-the-world collectors pause the application threads to collect garbage. The duration and frequency of these pauses should not adversely impact the application's ability to adhere to the SLA. 2. Concurrent GC algorithms contend with the application threads for CPU cycles. This overhead should not affect the application throughput. 3. Non-compacting GC algorithms can cause heap fragmentation, which leads to long stop-the-world pauses due to full GC. The heap fragmentation should be kept to a minimum. Garbage collection needs memory to work. Certain GC algorithms have a higher memory footprint than others. If the application needs a large heap, make sure the GC's memory overhead is not large. 4. A clear understanding of GC logs and commonly used JVM parameters is necessary to easily tune GC behavior should the code complexity grow or workload characteristics change.

And See this Also:

https://engineering.linkedin.com/garbage-collection/garbage-collection-optimization-high-throughput-and-low-latency-java-applications

Bipil Raut
  • 244
  • 1
  • 10