High GC pause times in Deterministic garbage collector

Hi all,
I opened a new topic about problem in object in Web Logic Real Time forum:
http://forums.bea.com/thread.jspa?threadID=300002813
Since deterministic GC is also related to JRockit activity, can anyone help about that problem.
Thanks in advance...!

Hi Patrizio, we'll use the WLRT forum for your thread.

Similar Messages

Garbage Collector pausing my Server for MINUTES at a time

Garbage Collection pauses are really crippling my server. Here is a grep of Full GCs from the log file. (The lines following each Full GC have a timestamp, yymmdd:hhmmss.sss)
[Full GC 876186K->169083K(222400K), 28.4152794 secs]
011120:004809.413:
[Full GC 883850K->214246K(259008K), 68.2294388 secs]
011120:033449.558: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 209.2 MB/900.0 MB (Free: 43.7 MB, Allocated: 252.9 MB)
[Full GC 881484K->300898K(347200K), 73.3787317 secs]
011120:045927.680: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 293.8 MB/900.0 MB (Free: 45.2 MB, Allocated: 339.1 MB)
[Full GC 886225K->269194K(317824K), 79.8212023 secs]
011120:055800.166: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 262.9 MB/900.0 MB (Free: 47.5 MB, Allocated: 310.4 MB)
[Full GC 890405K->261774K(338112K), 104.6192760 secs]
011120:064350.312: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 255.6 MB/900.0 MB (Free: 74.5 MB, Allocated: 330.2 MB)
[Full GC 893451K->306762K(361024K), 134.4052782 secs]
011120:073523.335: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 299.6 MB/900.0 MB (Free: 53.0 MB, Allocated: 352.6 MB)
[Full GC 896034K->286275K(350016K), 103.4689894 secs]
011120:081636.710: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 279.6 MB/900.0 MB (Free: 62.2 MB, Allocated: 341.8 MB)
[Full GC 882755K->260923K(310272K), 129.6787672 secs]
011120:093812.612: *** RECLAIMED MemoryManager( Idle ) - Memory Usage: 254.8 MB/900.0 MB (Free: 48.2 MB, Allocated: 303.0 MB)
You can see that between 12:48am and 9:38am, the Server is pausing for a combined total of TWELVE MINUTES! Often for 2 whole minutes at a time, during which the Server is completely unresponsive.
I have read Sun's GC tuning guide at http://java.sun.com/docs/hotspot/gc/index.html but it is not much help:
It says "Pauses can be minimized by using a small young generation and incremental collection, at the expense of throughput."
Well, I AM using incremental collection, and the young generation is the default size, which is quite small I believe. (32 MB max?)
It also says "Unless you have problems with pauses, try granting as much memory as possible to the JVM. The default size (64MB) is often too small."
Well I DO have problems with pauses, but I HAVE to allocate a ton of memory. The Server must support hundreds of simultaneous users, each with hundreds of K's of personal, dynamic, temporary data.
It also says "Unless you find problems with excessive major collection or pause times, grant plenty of memory to the young generation. The default MaxNewSize (32MB) is generally too small."
I AM having problems with excessive major collections and pause times, so according to this I should NOT grant more memory to young generation (eden).
What am I left with? Nothing! I am totally out to lunch here. The box this is running on is a dual P3-600 with a gig of RAM and Red Hat 6.2, with Sun JRE 1.3.1_02. My startup command line options are:
java -server -Xincgc -verbose:gc -Xms256M -Xmx900M
What should I do? The Tuning guide essentially says to screw around with generation sizes, but none of its specific tips seem to apply to me! This is a production server and I am worried about making things worse by playing around, so I was hoping someone out there might have some experience with this and concrete advice before I just start messing around with the memory map. Should I increase the young generation size? Decrease it? Something else altogether? HELP!

With default settings, I am getting horrible performance, under peak load, 25%-50% of server time is being spent with GC, approx. 11,000 minor GCs per hour! And a Full GC every hour or two which takes up several minutes. On average, I am losing 13.09 minutes per hour due to minor GC, and 54.5 seconds to major GC.
I tried your settings, Chuck, and they seemed to be working beautifully at first... minor GCs were now occuring once every few minutes for a couple seconds, instead of 3 times per second for a tenth of a second. Minor GC were now taking 1.06 minutes per hour instead of 13.09, more than a 1300% improvement!
HOWEVER...
After 7 hours, the Server started getting REALLY slow for no apparent reason. It seemed almost as if reading from sockets was suddenly becoming extremely time intensive. Then I got a HUGE minor GC that took 25.6 seconds. [GC 507410K->478034K(551296K), 25.6328459 secs], then a couple minutes later, the Server CRASHED with this output:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x40573aa7
Function name=malloc
Library=/lib/libc.so.6
Current Java thread:
Dynamic libraries:
011121:231738.194: Search ( pizzala, lzh ) returned 50 results (28 ms)
08048000-0804c000 r-xp 00000000 08:06 376904 /usr/local/java/jre1.3.1_01/bin/i386/native_threads/java
0804c000-0804d000 rw-p 00003000 08:06 376904 /usr/local/java/jre1.3.1_01/bin/i386/native_threads/java
40000000-40013000 r-xp 00000000 08:06 311298 /lib/ld-2.1.3.so
40013000-40014000 rw-p 00012000 08:06 311298 /lib/ld-2.1.3.so
40015000-40016000 r--p 00000000 08:06 2424834 /usr/share/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
40016000-40017000 r--p 00000000 08:06 2408452 /usr/share/locale/en_US/LC_MONETARY
40017000-40018000 r--p 00000000 08:06 2408454 /usr/share/locale/en_US/LC_TIME
40018000-40023000 r-xp 00000000 08:06 311344 /lib/libpthread-0.8.so
40023000-4002a000 rw-p 0000a000 08:06 311344 /lib/libpthread-0.8.so
4002b000-40034000 r-xp 00000000 08:06 1081477 /usr/local/java/jre1.3.1_01/lib/i386/native_threads/libhpi.so
40034000-40035000 rw-p 00008000 08:06 1081477 /usr/local/java/jre1.3.1_01/lib/i386/native_threads/libhpi.so
40035000-403b0000 r-xp 00000000 08:06 2769091 /usr/local/java/jre1.3.1_01/lib/i386/server/libjvm.so
403b0000-403b1000 ---p 0037b000 08:06 2769091 /usr/local/java/jre1.3.1_01/lib/i386/server/libjvm.so
403b1000-404fd000 rw-p 0037b000 08:06 2769091 /usr/local/java/jre1.3.1_01/lib/i386/server/libjvm.so
40515000-40517000 r-xp 00000000 08:06 311314 /lib/libdl-2.1.3.so
40517000-40519000 rw-p 00001000 08:06 311314 /lib/libdl-2.1.3.so
4051a000-40607000 r-xp 00000000 08:06 311305 /lib/libc-2.1.3.so
40607000-4060b000 rw-p 000ec000 08:06 311305 /lib/libc-2.1.3.so
4060f000-40621000 r-xp 00000000 08:06 311318 /lib/libnsl-2.1.3.so
40621000-40623000 rw-p 00011000 08:06 311318 /lib/libnsl-2.1.3.so
40625000-40641000 r-xp 00000000 08:06 311316 /lib/libm-2.1.3.so
40641000-40642000 rw-p 0001b000 08:06 311316 /lib/libm-2.1.3.so
40642000-40676000 r-xp 00000000 08:06 704575 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
40676000-40682000 rw-p 00033000 08:06 704575 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
40684000-40695000 r-xp 00000000 08:06 1081479 /usr/local/java/jre1.3.1_01/lib/i386/libverify.so
40695000-40697000 rw-p 00010000 08:06 1081479 /usr/local/java/jre1.3.1_01/lib/i386/libverify.so
40697000-406b8000 r-xp 00000000 08:06 1081480 /usr/local/java/jre1.3.1_01/lib/i386/libjava.so
406b8000-406ba000 rw-p 00020000 08:06 1081480 /usr/local/java/jre1.3.1_01/lib/i386/libjava.so
406bb000-406cf000 r-xp 00000000 08:06 1081481 /usr/local/java/jre1.3.1_01/lib/i386/libzip.so
406cf000-406d2000 rw-p 00013000 08:06 1081481 /usr/local/java/jre1.3.1_01/lib/i386/libzip.so
406d2000-41400000 r--s 00000000 08:06 1081510 /usr/local/java/jre1.3.1_01/lib/rt.jar
4142d000-416d2000 r--s 00000000 08:06 1081511 /usr/local/java/jre1.3.1_01/lib/i18n.jar
416d2000-416e8000 r--s 00000000 08:06 1081498 /usr/local/java/jre1.3.1_01/lib/sunrsasign.jar
77a9f000-77ab5000 r--p 00000000 08:06 2408451 /usr/share/locale/en_US/LC_CTYPE
77ab5000-77abd000 r--p 00000000 08:06 2408450 /usr/share/locale/en_US/LC_COLLATE
77abd000-77abe000 r--p 00000000 08:06 2408453 /usr/share/locale/en_US/LC_NUMERIC
77abe000-77abf000 r-xp 00000000 08:06 1622117 /usr/lib/gconv/ISO8859-1.so
77abf000-77ac0000 rw-p 00000000 08:06 1622117 /usr/lib/gconv/ISO8859-1.so
77ac1000-77ac9000 r-xp 00000000 08:06 311336 /lib/libnss_files-2.1.3.so
77ac9000-77aca000 rw-p 00007000 08:06 311336 /lib/libnss_files-2.1.3.so
77b37000-77b40000 r-xp 00000000 08:06 1081484 /usr/local/java/jre1.3.1_01/lib/i386/libnet.so
77b40000-77b41000 rw-p 00008000 08:06 1081484 /usr/local/java/jre1.3.1_01/lib/i386/libnet.so
77b41000-77b45000 r-xp 00000000 08:06 1081513 /usr/local/java/jre1.3.1_01/lib/i386/libNBIO.so
77b45000-77b46000 rw-p 00003000 08:06 1081513 /usr/local/java/jre1.3.1_01/lib/i386/libNBIO.so
77b46000-77b4f000 r-xp 00000000 08:06 311342 /lib/libnss_nisplus-2.1.3.so
77b4f000-77b51000 rw-p 00008000 08:06 311342 /lib/libnss_nisplus-2.1.3.so
77b51000-77b59000 r-xp 00000000 08:06 311340 /lib/libnss_nis-2.1.3.so
77b59000-77b5b000 rw-p 00007000 08:06 311340 /lib/libnss_nis-2.1.3.so
77b5b000-77b5e000 r-xp 00000000 08:06 311334 /lib/libnss_dns-2.1.3.so
77b5e000-77b5f000 rw-p 00002000 08:06 311334 /lib/libnss_dns-2.1.3.so
77b5f000-77b6b000 r-xp 00000000 08:06 311346 /lib/libresolv-2.1.3.so
77b6b000-77b6c000 rw-p 0000b000 08:06 311346 /lib/libresolv-2.1.3.so
Local Time = Wed Nov 21 23:17:38 2001
Elapsed Time = 26581
# The exception above was detected in native code outside the VM
# Java VM: Java HotSpot(TM) Server VM (1.3.1_01 mixed mode)
# An error report file has been saved as hs_err_pid20055.log.
# Please refer to the file for further information.
Yummy. Signal 11's really make my day fun :(. I tried restarting the Server, but it crashed again in the same way 15 minutes later. Then I switched back to default settings and it has run fine all weekend.
The Sig11 makes me think either our C lib is buggy (our Linux distro is getting a bit old), or we have a physical memory problem. Odd that it only shows up when I tried your new settings though...

Incremental Garbage Collector is halting my server for MINUTES at a time.

I have a Java server which services hundreds (currently 300-700 on average, target of 2000+) of simultaneous client connections, with a staggering number of long lived (but not permanent) objects.
The docs for incremental garbage collection state: "The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution." This is NOT true in my case. During peak load, the Server halts occasionally (once an hour or more) and entire MINUTES tick by. Average wait time is 2.5 - 3.5 minutes, the highest I have seen is 4 minutes, 10 seconds. This is entirely unnacceptable.
The server is on Red Hat Linux 6.2, kernel 2.2.14-5.0, with a gig of RAM. My current command line options are
java -server -Xincgc -Xms256M -Xmx900M
And I have just added -verbose:gc to help analyze the gc performance. I have read the gc tuning guide at http://java.sun.com/docs/hotspot/gc/index.html but still feel rather clueless about what is the optimum setup for my particular application.
I will of course start experimenting, but I was hoping to find a "wise old elf" who might give some useful pointers to accelerate the process, seeing as how the Server is already running in a production capacity, time is critical.

Are you using a Java application server like Tomcat, Dynamo, WebLogic etc. ?
In that case consider running several server instances on the machine, with the applicationserver's software load balancer. Find the amount of RAM allocated to the heap per serverinstance where garbage collection runs takes a couple of seconds, and don't allocate more than this to each server. Start as many servers as you have available RAM for.
This is the approach recommended by application server vendors such as BEA http://edocs.bea.com/wls/docs61/perform/JVMTuning.html and ATG.
A side benefit of this approach is that in case you get more concurrent users than your computer can handle, you already have the setup for spreading the load over several computers.

Garbage Collector takes long time

Hi.
I monitored Garbage Collector log at SAP EP System and I found strange things.
Minor Garbage Collector takes 75 secs. Why It taks so long ?
Anyone have idea about that ?
We are using HP IA 64 machine and JDK 1.4.2_07.
Regards, Arnold.

Hi,
There are several SAP Notes on Java performance settings. Apply them where necessary. One of the first things to do is to use a reasonable actual Java version. As yours is _07, upgrade to a newer version.
br,
Tobas

Idea about garbage collector

Hi,
I'm working in finance area and there are a lot of talks about latency last years though I never saw system that had guaranteed GC STW spikes < 2 ms
so my question why its not possible to implement smart pointer GC (like in C++) so every reference assignment would increment counter in object
and every reference removing decrement - this would add additional cost but 99 % of objects can be safely collected concurrently - sure it does not deal with circular dependencies but I suppose on some applications it would be just great so it can be used with CMS GC

It's certainly possible to use "smart pointers" to implement reference counting garbage collection. It's just that no one has figured out how to make it performant. Yet. All the counter updates have to be atomic, which hurts performance and scalability on multi-processor boxes. There are schemes to avoid the atomic counter updates, for example for pointer stores to thread stacks, but they start to get really complicated and hard to debug. How much of a performance hit are you willing to take to eliminate the stop-the-world pauses?
As you say, you still need something global to clean up cycles.
<2ms is a fairly stringent target for stop-the-world pauses, but not unthinkable. "Guaranteeing" those pauses is unthinkable, without some limitiations on what you do with your heap. You should work with your Oracle support engineers to tune your collector settings. Or post your GC logs and likely someone can come up with ideas to reduce your pause times.

Garbage Collector blocks - weird behaviour

Hi!
After launching an application we ran into weird problems with the garbage collector. It's a combo of Jetty/JGroups/Helma-Application-Server and various other libraries on a RedHat 7.3 box. The problem occurs on a machine with relativly high load (~10 requests/sec) but doesn't come along with high load automatically.
After some hours uptime the garbage collector blocks for increasingly longer intervals until the application is reachable only for seconds every few minutes. In concerns exclusivly minor GC in the new space. Each stop lasts for just 1/10000 seconds but that in a loop of 1000s times back-to-back.
The logfile created by the -Xloggc option looks like this:
20085.784: [GC 20085.785: [ParNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 71552K->0K(71616K), 0.0634410 secs] 380477K->312523K(511936K), 0.0639970 secs]
Total time for which application threads were stopped: 0.0652310 seconds
Application time: 8.7885840 seconds
Total time for which application threads were stopped: 0.0005810 seconds
Application time: 0.0005620 seconds
Total time for which application threads were stopped: 0.0006080 seconds
Application time: 0.0002630 seconds
Total time for which application threads were stopped: 0.0004410 seconds
Application time: 0.0001790 seconds
Total time for which application threads were stopped: 0.0005480 seconds
Application time: 0.0001670 seconds
Total time for which application threads were stopped: 0.0003440 seconds
Application time: 0.0001210 seconds
Total time for which application threads were stopped: 0.0004450 seconds
Application time: 0.0001590 seconds
Total time for which application threads were stopped: 0.0004220 seconds
Application time: 0.0002180 seconds
20095.265: [GC 20095.265: [ParNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 71552K->0K(71616K), 0.0753260 secs] 384282K->317322K(511936K), 0.0759450 secs]
Total time for which application threads were stopped: 0.0767720 seconds
Application time: 0.3346050 seconds
While the "Total time.." lines were printed, the app was unreachable. "Application time" usually marks the time the app was running between two garbage collections. It seems as if the garbage collector tries to stop the app, can't do it for whatever reason and tries again a moment later.
We've tested any suitable garbage collector, we've tried out j2sdk1.4.2_02, j2sdk1.4.2_07, jdk1.5.0_01, jdk1.5.0_02, we've tried different machines to exclude hardware failure. It is hard to reproduce in a test environment but we've seen a few lines like above on a windows box too (no longer blocking times, tough). There aren't any OutOfMemoryErrors, the heap management looks fine. After GC about 3/4 of the heap are freed even while the above problem occurs, so we're ruling out a memory leak.
Maybe someone here has stumbled across that problem or has any ideas what could trigger such a behaviour? After two weeks of debugging I've run out of ideas on where to look for a bug.
Yours remotely,
Stefan

hi there
Can u add -XX:+PrintHeapAtGC -XX:+PrintGC and show the portion of the log files?
You are using the -XX:+ParNewGC? Any -XX:+UseConcMarkSweepGC?
Also, add -XX:+DisableExplicitGC
Hope this helps.

Garbage Collector in JC 2.2

Help: I am trying to understand how a Passive Garbage Collector (GC) implementation works in Java Card v2.2. As I understand it, Java Card vendors have the option to implement Automatic GC or a Passive GC under version 2.2 or higher.
My question is as follows:
What if object X no longer used, and was instantiate during the install() process:
With Automatic GC: the GC would automatically reclaim memory after the process() method finish executing. If object X has no other references. Also, any other objects without any references would be reclaimed as well.
With Passive GC: In the process() method the developer must call requestObjectDelete(), and before the next APDU request, the JCRE would reclaim memory. Is this right?
What happens requestObjectDelete() is called on an object that still has references? Does it still reclaim it? In either Passive or Automatic GC?
Do any vendors supporting Automatic GC? How about Java Card version 2.2.2?
Thank you for any help
Maguar

What happens requestObjectDelete() is called on an object that still has references? Until now I haven't seen a method called "requestObjectDelete()" (and Google, too).
Are you probably referring to the static method JCSystem.requestObjectDeletion() ?
This method can not be called "on an object". It only allows to explicitly invoking the GC for freeing the memory allocated by objects that can not be accessed anymore.
This solves the problem that current JavaCards are not multi-threaded. Therefore the GC can not be started in background as it does in the J2SE environment.
By calling JCSystem.requestObjectDeletion() a JavaCard applet "voluntary" gives away CPU time to the GC. In single threaded environments this means that the caller (the JavaCard applet) is halted until the GC has finished its work.
Jan

Garbage Collector periodic rate

Hello!
In an application which I'm studying, garbage collector (opportunely configured with command line options) run on a configurable periodic time: this means that every (10 minutes for example) I call method System.gc() in my code.
If I don't explicitily call this method, Java virtual machine will intervene by itself?
Will it intervene only when a threshold amonut of memory is consumed (too many JAVA object instantiated which wait for be freed) ?
Thank you very much in advance
Diego

Does anyone knows what's the difference with Full GC
and why it intervenes ? Because you told it to. You called System.gc().
I don't think that was the question you meant. My guess is you wanted to know why the Concurrent Low Pause Garbage Collector intervened?
Off that first link I gave you was an link to an article that describes the GC output log ( http://java.sun.com/docs/hotspot/gc1.4.2/example.html ). If you read that article it describes what each of the values in the gc output means.
From that article:
[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
where
<collector> is an internal name for the collector used in the minor collection
<starting occupancy1> is the occupancy of the young generation before the collection
<ending occupancy1> is the occupancy of the young generation after the collection
<pause time1> is the pause time in seconds for the minor collection.
<starting occupancy3> is the occupancy of the entire heap before the collection
<ending occupancy3> is the occupancy of the entire heap after the collection
<pause time3> is the pause time for the entire garbage collection. This would include the time for a major collection is one was done.
The reason the Concurrent Mark Sweep(CMS) starts is also in the first link I gave you. When the Concurrent Garbage Collector thinks you are about to run out of heap it starts the CMS.
1234.306: [GC [1 CMS-initial-mark: 342810K(499712K)] 342906K(524224K), 0.0026879 secs]In your case that was when the used heap reached 342810K out of a current allocated heap of 499712K
You could describe the specific problem you are investigating. Also it would be helpful if you provided the VM parameters you have for starting your application.

Garbage collector - controlling it

The main performance problem on our website right now is from the garbage collector. Yes, our site is very 'thick', but the gc locks out other threads for 10 seconds or so regularly, and once a day or locks it up for several MINUTES. The main problem is that we have a few very large objects that never go away, but the gc still has to occasionally scan them.
I developed a way to put the two GarbageCollector threads (per vm) into the lowest priority. I've seen documentation that this is where they are supposed to be anyway, but they are really at the normal level with everything else. This works great on NT, but only works ok on Solaris. On NT, the gc still pegs the cpu, but other threads are almost unnaffected.
Anyway, my bosses are concerned about this fix, wondering what negative impact it will have or if the gc won't get enough time or whatever.
I just wondered what you all think of this fix. Has anyone else tried it?
Also, does anyone know of a way to tell the gc not to every scan certain objects?

You can also try the incremental and concurrent garbage collectors. These are enabled with the -Xincgc and -Xconcgc options to the java command, respectively. They may have lower performance overall, but generally have much shorter GC pause times.
Of course, don't forget the top tip for improving GC performance is always not to create unnecessary objects!

Garbage Collector seems not to run

Hi!
I have a problem with the garbage collector:
To free memory, I regularly run the garbage collector in my app ( System.gc() ) after releasing resources by setting the reference variable to "null". But after some time I get an "out of heap memory" error. It seems that the gc doesn't run - I get the following result on the stdout:
0 garbage collections (0 bytes collected)
Is this possible? Or can I fix this problem?
Thanks for your help

Is it that the GC was not kicking-in even when you delete the references to the objects? That is true for any GC. GC will kick in only when you need more memory to create new objects
Also, you need to tune your young generation space and increase it from default 2MB to 32MB which will avoid frequent young generation GCs. By setting Xmx to 1024 MB, VM will try to grow till 1024 MB and if it can't allocate because
of less physical memory on your system, it will throw OutOfMemory errors.
I suggest you try the following:
1. Configure young generation to 32MB and old generation to 512 MB. This is how
you start your app
java -XX:MaxNewSize=32m -XX:NewSize=16m -Xms64m -Xmx512m -verbose:gc <app>
This sets the initial heap size to 64MB. You can increase this if your initial startup memory requirement (static memory) is higher that 64MB.
With Xmx set to 512MB, if some sessions die or are closed and heap size grows to 512MB, Full GC should kick in and you should be able to release memory for new sessions. Running with -verbose:gc will show if Full GC gets kicked in or not.
2. Try can calculate the static memory required at any point of time and also how much garbage is collected in certain time period. Then using these values we can make changes in young and old generation sizes.

Garbage Collector Problems

Problem: The garbage collector on my server runs aprox every 1 min for
about 8 secs swamping the CPUs.
I started a not so big version of my "big server" using the following:
JDK 1.4
Windows NT 4.0
Compaq Proliant with 4 CPUs @ 800Mhz
4GB SDRAM
I am starting with the following parametrs:
-mx1536m -verbose:gc -XX:-DisableExplicitGC -Xrs
On start up, my server creates a lot of objects that will live forever. Over
time any time period only a few objects (in comparison) are created that
will die young. I assume that I want a large older generation and a smaller
young generation. I need enoug room in my older generation for my older
objects plus room for the minor collections since they use copy collection.
The verbose gc trace shows the collector running ~every min. Here is a snip
of the log:
17:35:57 | [Full GC 245559K->245496K(441840K), 8.2943686 secs]
17:36:35 | [Full GC 245577K->245507K(441840K), 8.2816641 secs]
17:37:13 | [Full GC 245588K->245526K(441840K), 8.3754267 secs]
17:37:52 | [Full GC 245617K->245554K(441840K), 8.2831863 secs]
17:38:30 | [Full GC 245635K->245573K(441840K), 8.2977681 secs]
I let the server run and there were hundres of these with never a minor gc.
My analysis (Are my assumtions correct?)
1. I do not see minor collections happening so I assume these full
collections are not caused by collection of the young generations.
2. Since during my test run I know that no one is hitting my server, there
should not be and are not and significant memory changes that would require
a minor collection (which is why I don't see them).
3. I am using Visobroker which, like RMI, may be making explicit gc calls.
To prevent this I tried calling -XX:+DisableExplicitGC yet the GC seems to
wants to run every minuite.
Is -XX:+DisableExplicitGC supported on JDK1.4 Win32?
Could something else be causing these Full GCs?
-Chris

I have one other suggestion, but it is a long shot. The total size of your heap is around 440M and the total in use is very close to 60% of that value.
Since the JVM by default tries will consider increasing the heap size (up to -Xmx) when the free space falls below 40% AFTER GC, perhaps it is GC-ing periodically because of that. This sounds stupid since it should adjust heap size because of GC, but it is worth a try.
You might consider this...
java -Xms440m -Xmx1536m -Xminf0.1 -Xmaxf0.9 ...
This will mean that the heap will only expand when you have less than 10% free and will contract only when you have more than 90% free, but only to value of -Xms.
You also might consider -Xincgc as well, which should eliminate the 8-second pauses in favor of a more distributed gc load. Since you are alrready getting hit by >10% GC overhead, this may give you overall greater throughput as well, but I wouldn't bet on it.
Are you using the -server JVM? If not, I'd switch to that as well.
Chuck

Possible Bug in Garbage Collector?

Hello all
I'm new to these forums but I searched for this problem and couldn't find exactly the same thing - apologies if I missed something.
I've written an image browser which displays thumbnails, and when you click on a thumbnail it loads the image in a new window. This new window is just a JFrame, with a single JLabel, with an ImageIcon in it, representing the picture. The path name of the picture is passed when this JFrame is created, and the picture is loaded within the JFrame. Therefore, when I close the JFrame, I expect the memory associated with the image to disappear.
This works. However, when I open a fairly large image (around 1500x1500 pixels), and then close the window, the garbage collector doesn't free the memory. After this, if i continue to open windows with smaller images, they too have the same problem. However, this doesn't happen with smaller images until I open a larger image.
I think this is a problem with the garbage collector, is this familiar to anyone? Can anyone help? Unfortunately I can't really paste code since this is a university assignment. But you can try it - just load a jframe with a large picture, close it, and as long as the program runs the memory will not be deallocated.
Any help would be massively appreciated.
Thanks

Since you're not willing to post your code it's very hard to comment.
One question: Are you calling System.gc() after closing these frames? In fact you should probably call it 3 times to make sure the garbage collector takes you seriously. Try this and let us know if you're still showing the leak

Intermittently nursery GC is taking very long pause time

Hi,
I have jboss application server running with JRockit R27.6.5 on RedHat Linux. I see that the nursery GC is taking very long time. Some times it takes more than 10 seconds. This causes TLA-fetch error for all the threads.
High nursery time -
[memory ][Sun Jul 10 23:10:18 2011][05730] 23340.903: parallel nursery GC 3270701K->3100453K (6144000K), 2740.705 ms
Usual nursery time -
[memory ][Sun Jul 10 23:27:23 2011][05730] 24368.799: parallel nursery GC 4361524K->4191033K (6144000K), 63.751 ms
This behavior is puzzling because it was working fine till last week. We have two applications running on this server which are totally different in nature but we see the same behaviour wrt nursery GC. This high nursery GC is happening even when there is absolutely no load on the server. It is happening every 10 minutes or so.
Infact we thought that this is something to do with hardware and we replaced it with new but we see the same behavior on the new hardware.
We have given 6GB RAM to one server and 3.5GB RAM to another server. The machine is 24 cpu.
Thanks

Thanks for the reply.
I would expect fragmentation of memory would happen over a period of time. I am also facing this problem on other servers with large heap.
But this is different. Below are JVM settings for two servers running on the same machine.
JAVA_OPTION="-Xms${6000}m -Xmx${6000}m -Xgc:gencon -Xverbosetimestamp -Xverbose:memory,cpuinfo,opt -Xgcpause -Xgcreport -Xmanagement:ssl=false,authenticate=false -Djrockit.managementserver.port=7090"
JAVA_OPTION="-Xms${3500}m -Xmx${3500}m -Xgc:gencon -Xverbosetimestamp -Xverbose:memory,cpuinfo,opt -Xgcpause -Xgcreport
The nursery pause time is high right after the server restart. Most of the time its fine but intermittently there is a spike. Sometimes spike goes all the way upto 10 seconds.
memory ][Mon Jul 11 13:40:00 2011][05730] 75525.646: parallel nursery GC 4157804K->3992995K (6144000K), 64.900 ms
[memory ][Mon Jul 11 13:40:05 2011][05730] 75530.870: parallel nursery GC 4180295K->4013796K (6144000K), 67.672 ms
[memory ][Mon Jul 11 13:40:11 2011][05730] 75536.548: parallel nursery GC 4202060K->4036425K (6144000K), 63.251 ms
[memory ][Mon Jul 11 13:40:18 2011][05730] 75541.750: parallel nursery GC 4223678K->4058628K (6144000K), 2077.272 ms
Below Full GC. It was stuck for 10 seconds. There was absolutely no activity other than below logs for full 10 seconds.
memory ][Mon Jul 11 13:44:10 2011][05730] 75775.840: parallel nursery GC 5399093K->5234267K (6144000K), 74.492 ms
[gcpause][Mon Jul 11 13:44:10 2011][05730] nursery collection pause time: 74.492000 ms
[memory ][Mon Jul 11 13:44:14 2011][05730] 75779.400: parallel nursery GC 5422405K->5258310K (6144000K), 74.616 ms
[gcpause][Mon Jul 11 13:44:14 2011][05730] nursery collection pause time: 74.616000 ms
[gcpause][Mon Jul 11 13:44:14 2011][05730] old collection phase 1 pause time: 40.657000 ms, (start time: 75779.479 s)
[memory ][Mon Jul 11 13:44:17 2011][05730] 75782.779: parallel nursery GC 5454944K->5289009K (6144000K), 50.456 ms
[gcpause][Mon Jul 11 13:44:17 2011][05730] nursery collection pause time: 50.456000 ms
[gcpause][Mon Jul 11 13:44:18 2011][05730] old collection phase 4-5 pause time: 39.760000 ms, (start time: 75783.794 s)
[gcpause][Mon Jul 11 13:44:18 2011][05730] (pause includes yc: 39.756 ms, compaction: 0.000 ms (no compaction), update ref: 0.000 ms)
[gcpause][Mon Jul 11 13:44:18 2011][05730] old collection phase 5 pause time: 0.356000 ms, (start time: 75783.879 s)
[gcpause][Mon Jul 11 13:44:18 2011][05730] old collection phase 5-0 pause time: 0.676000 ms, (start time: 75783.923 s)
[memory ][Mon Jul 11 13:44:18 2011][05730] 75779.479-75783.923: GC 5279356K->2141116K (6144000K), sum of pauses 81.449 ms

About Garbage Collector

In Java, there is one system call for garbage collector.
System.gc();
I want to know the significance of this system call for GC. Even after calling this method, garbage collector won't get started, still it will run on its own time.
If this is the thing then what's the significance of this method call?
Please let me know this.
Thanking you,
Ketan

Addendum
In a heavy data application, for instance, that stores records in memory for some purpose, then releases that memory and creates next set of records in memory, calling gc really help.
We have such application where in we tested its performance with and without calling gc. No wonder, we found better results by calling gc.

Automatic Garbage collector after JVM almost hit max value on weblogic ?

Hi All,
I have application on weblogic 10MP2. I use 4G JVM. My application getting slow when the usage of JVM hit arround 70-80% of max heap size. Unfortunatelly, the garbage collector didn't run when it hit that high. So to keep my application in good state, I need to MANUALLY hit the Perform GC to keep the JVM below 70%.
Is there any settings to tell the JVM to perform GC when the free space of the JVM hit 30%?
What will the weblogic do if one of the server in warning state? There is a settings in the weblogic to specify when it hit some percentage of free space, it will bring the server to warning state. Will it do the Garbage Collector?
Need your help on this. I am tired of hitting the Perform GC button.
Really appeciate your help.
Thanks,
Eric

I am replying to my own post because I found a tool that
helped me solve in two hours what I had been stumped on
for the past few days.
The Heap Analysis Tool.
I had a major memory leak problem. I couldn't locate
the source until I downloaded and used this tool(for free).
This tool keeps track of memory used by objects,
each objects references, objects references by each
object, and all objects instances. All of this information
can be obtained in html format for efficient traversing
of object chains. I would highly recommend looking
this tool over if you intend on doing memory intensive
programming.
In case your curious where my error was I had two problems
which are now fixed. One. I had a couple of BufferedImages
that were leaking 30MB RAM. Two. I didn't know that using
ObjectStream's to read/write objects stored references
to the objects being written(preventing garbage collection).
Deffinately worth running the Heap Analysis Tool before
pointing a finger at System.gc().

High GC pause times in Deterministic garbage collector

Similar Messages

Maybe you are looking for