Menu
That's how full gc with verbose gc enabled looks like -
13463.547: [Full GC [PSYoungGen: 323053K->0K(325952K)]
[PSOldGen: 653170K->331738K(655360K)] 976224K->331738K(981312K)
[PSPermGen: 238715K->238715K(264448K)], 385.4631490 secs]
[Times: user=2.19 sys=1.35, real=385.50 secs]
How can the real time be so much bigger than user + sys?
My first thought was that garbage collector is waiting for a resource, but this resource does not seem to be IO or CPU, as "top" output doesn't show any cpu or memory problems when the gc occurs.
552
In normal (all most all) GC events, user time will be greater than sys time. It's because, in a GC event, most of the time is spent within the JVM code and only very less time is spent in the kernel.
Drawbacks of garbage collection in Java Garbage collectors bring some runtime overhead that is out of the programmer's control. This could lead to performance problems for large applications that scale large numbers of threads or processors, or sockets that consume a large amount of memory.
Java garbage collection is an automatic process. The programmer does not need to explicitly mark objects to be deleted. The garbage collection implementation lives in the JVM. Each JVM can implement garbage collection however it pleases; the only requirement is that it meets the JVM specification.
Yes, garbage must be handled in a deterministic manner in real-time systems. One approach is to schedule a certain amount of garbage collection time during each memory allocation. This is called "work-based garbage collection." The idea is that in the absence of leaks, allocation and collection should be proportional.
For a full collection to occur, you need to stop all the threads. (One of the reasons it call a stop the world collection)
Stopping all your threads can take a long time, esp if you have thousands of them. Each thread has to reach a "safepoint" to stop it.
This sort of behaviour usually means you have too many threads. You might also consider ConcurrenntMarkSweep collector or the new G1 collector which doesn't need to stop the application as often.
101
Try reading this (more links included to whitepaper): Java 1.5 GC Internals.
I guess most things are still valid for Java's 1.6 VM and it gives a great insight as how the GC works.
Also, read this: Tuning JVM's 1.6 Heap space
( there is also another white paper link with an illustrative benchmark but I just can't find it :( :/
I'll try and see if it pops up somewhere but I guess it's located somewhere in Oracle's website )
In general, don't get freaky. Try and experiment with different options based by some rationale and see how it works. Unless you have a > 10% performance gain and your application is critical try not to mingle with a lot of details.
The reason is simple: A simple code rewrite in just a few LOCs may change dramatically your GC's behaviour.
Take your time and have fun! :)
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
