Wednesday Aug 07, 2013

Garbage First Garbage Collector Tuning

A new article, now up on otn/java, titled “Garbage First Garbage Collector Tuning,”
by Monica Beckwith, Principal Member of Technical Staff at Oracle, and performance lead for the Java HotSpot VM's Garbage First Garbage Collector (G1 GC), shows how to adapt and tune the G1 GC for evaluation, analysis, and performance.

As Beckwith explains, the Garbage First Garbage Collector is the low-pause, server-style generational garbage collector for Java HotSpot VM. It uses both concurrent and parallel phases to achieve its target pause time and maintain good throughput. A garbage collector is a memory management tool. When G1 GC determines that a garbage collection is necessary, it first collects the regions with the least live data – known as garbage first.

Beckwith describes the collection phases and marking cycles, lists default tuning devices, offers recommendations about how to fine tune and evaluate garbage collection, and shows how to respond to overflow and exhausted log messages.

She concludes her article as follows:

“G1 GC is a regionalized, parallel-concurrent, incremental garbage collector that provides more predictable pauses compared to other HotSpot GCs. The incremental nature lets G1 GC work with larger heaps and still provide reasonable worst-case response times. The adaptive nature of G1 GC just needs a maximum soft-real time pause-time goal along-with the desired maximum and minimum size for the Java heap on the JVM command line.”

Check it out here.

Tuesday Oct 25, 2011

Perspectives on Garbage Collection

In a new article, part of the Developer Insight series, and titled “The Developer Insight Series, Part 6: Perspectives on Garbage Collection,” now up on otn/java, three leading Java developers offer insight into garbage collection.

Oracle Lab’s Ron Goldman notes, that, “Although automatic memory management has existed for more than 50 years, a lot of people still don't want it in their systems because it seems inelegant. It just strikes people as wrong – ‘It's my memory. I should be releasing it when I know it's no longer being used.’ Theoretically, that might be true, but in practice, programmers continue to forget to free up memory when they are done with it, or, even worse, try to free it up while it's still in use. The results? Buggy code that is apt to crash unexpectedly.”

Java Champion Kirk Pepperdine observes that, “Even though collection of very short-lived objects is almost free, high rates of object churn can still result in very inefficient GC numbers. Sometimes, the problem is simply that the Java Virtual Machine (JVM) doesn't have enough heap space. Monitoring GC activity will give you the hints you need for a successful heap-sizing exercise…”

And Oracle’s GC expert Tony Printesiz takes on eight myths about garbage collection, four of which are:

1. Reference counting GC will solve all my latency problems.
2. malloc and free will always perform better than GC.
3. Finalizers should be called promptly, as soon as objects become unreachable.
4. GC will eliminate all memory leaks.

The article provides a good context for developers to collect their thoughts about garbage. ;)

Read the complete article here.

About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
2
5
6
7
12
13
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today