Garbage collector in java

Hi all,
How does a garbage collector knows, when it should deallocate the memory of an
object ?. And How can we make ready an object to deallocate it's memory by garbage collector ?.

Hi all, Hi!
How does a garbage collector knows, when it
should deallocate the memory of an
object ?.Objects are kept in a memory heap, and the objects that are having references are called dirty objects, and objects with no references are called clean objects(I think so, don't believe me).
clean objects (and objects with weak references) are liable for garbage collection.
there are certain thresold conditions (which I don't know), when they are reached, gc runs.
These thresold conditions are jvm specific(jvm optimization), one could be when jvm feels it is going to get out of memory(again, don't believe me). You would have to go into details of jvm for that(I don't want to go there as I have lots of other things to learn).
And How can we make ready an object
to deallocate it's memory by garbage collector ?.there is no way you can control gc mechanism manually, because jvm have to take care of a lots of optimizations. so you can't predict when your object will be collected by gc.
(that's why people don't beleave on finalize method).

Similar Messages

Help understand garbage collector behavour in case..

Here is the case:
class B{
// members and methods
class A{
B memberAB;
// other members and methods
class C{
B memberCB;
public void takeAndKeep_B()
A objA = new A();
memberCB = objA.memberAB;
//some code
// other members and methods
After takeAndKeep_B() finishes its job,
garbage collector will not release
memory occupied by objA
(because there is still a reference to it's member memberAB, I think)
Am I getting it right? Or the reason of memory leak is totaly unrelated to this case and I should look for it in some other place?
I would appreciate any oppinions so mush.

Here's how the garbage collector works: it collects any objects that the program cannot access. If an object cannot be accessed, it will be collected by the garbage collector if needed.
In your code, after takeAndKeep_B() finishes, there are no references to the new A object that the objA reference points to. Thus, the A object can be collected by the garbage collector.
Look at it this way: if the A class had a member named i that was an int, could your program access the i field of the A object you created after takeAndKeep_B() finishes? No, because the reference objA ceases to exist at the end of the method. Therefore, the object is unreachable and may be collected.
There is no way for an unreferenced object not to be collected by the garbage collector. Java cannot leak memory in this way.

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.

How the protected finalize method is called by garbage collector

Dear All,
I have a double regarding the calling mechanism of finalize method. The access specifier of finalize method is protected, not only that if a class overrides this method then also the finalize method can be protected in the subclass of Object. But the concept of protected access specifier is, from outside of the package it can be accessed only from subclass.
The program (may be part of Garbage collector), which calls this (finalize) method mast not be in the same package (that is java.jang) nor it is a subclass of the class (whose finalize method it calls).
Then how the finalize method is getting called by the garbage collector when it is protected?
Regards,
Gourab

Refer to following link for the details
http://www.me.umn.edu/~shivane/blogs/cafefeed/2005/09/why-is-finalize-method-protected.html
The link gives answer to how a protected/private members are accessible to JVM or GC and why finalize is declared protected.

Get Garbage Collector Details

Hi,
I'm using ALBPM 6.0.4 standalone on a windows 2003.
I'm tunning the application, but when i trying to get the garbage collector details i don't get the log file.
i already set this arguments -Xloggc:../log/engine-max-gc.log -XX:+PrintGCDetails on Additional java arguments used in startup on execution tab.
I'm not sure if the engine takes this arguments on start up.
i'm doing something wrong?
Thanks in advance,
Helios.

See the javadocs for DatabaseMetaData class under java.sql

Inefficient garbage collector process - WLS 8.1 SP6 - JVM jdk142_13 (SUN)

Hi all,
I am trying to perform some tuning operations in my server (maestroServer_01) because the application uses the total amount of heap size and the garbage collector process is not running fine. The arguments used on this VM are:
-server -Xms2048m -Xmx2048m -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy -XX:NewRatio=8 -XX:SurvivorRatio=12 -Xverify:none -Xnoclassgc -XX:+DisableExplicitGC -XX:+PrintGCDetails -Dweblogic.webservice.i18n.charset=utf-8 -Duser.timezone=$JAVA_TZ -DejbURL='t3://localhost:9081' -DjpdURL='http://localhost:9081'
Please let me know if I can change these parameters in the WLS:
Services -> Bridge -> Messaging Bridge Thread Pool Size -> from 5 to 20
Configuration -> Tuning -> Socket Readers -> from 33 to 60, and disable "Enable Native IO" option.
I got some informations from internet about some parameters that can be used to improve the memory utilization of this JVM. The parameters are described in the link below:
http://java.sun.com/performance/reference/whitepapers/tuning.html
Does anyone know what can be done? The WLS needs to be restarted every day!
Thanks!

yes regularely .. :-) (as you can see from the posts..)
to your problem, the connectstring seems perfectly valid for a oracle light db installation (which we install within the bpel installation)
can you check if this polite process is running?
HTH clemens

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.

Understanding garbage collector output

Hi all.
My application uses an increasing amount of memory, and in order to solve the problem I have turned on the -verbosegc option. The output is as follows:
<GC: managing allocation failure: need 1040 bytes, type=1, action=1>
<GC: 504 milliseconds since last GC>
<GC: freed 6530 objects, 288432 bytes in 10 ms, 35% free (661616/1887424)>
<GC: init&scan: 1 ms, scan handles: 7 ms, sweep: 2 ms, compact: 0 ms>
<GC: 4 register-marked objects, 7 stack-marked objects>
<GC: 8 register-marked handles, 136 stack-marked handles>
<GC: refs: soft 0 (age >= 32), weak 0, final 1, phantom 0>
<GC: managing allocation failure: need 1040 bytes, type=1, action=2>
<GC: 10 milliseconds since last GC>
<GC: expanded object space by 1048576 to 2936000 bytes, 58% free>
<GC: need to expand mark bits to cover 2560 bytes>Is any one able to explain this output for me? My problem is that the object space is expanded regularly and eventually the garbage collector writes "totally out of heap space" and an OutOfMemoryError occurs.
My -version is
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition
Classic VM (build 1.3.0-1, native threads, jit)running on UNIX, Digital Alpha.
Regards,
Torben Lange

Just a follow up on my memory leak problem which I have solved now.
I had created a class which handles database connections. The constructor looked something like this:
Connection connection;
public DBConnection() {
DriverManager.registerdriver(new myDriver());
connection = DriverManager.getConnection(...);
}My application creates an object of this class, uses it and then closes the object. This goes on all the time. (Yes, it could be handled another way by pooling database access or simply keep the connection open without closing it - but it isn't.)
It seems that the registration of the driver in the constructor eventually will fill the memory - apparently the same driver is registered several times.
Problem was solved when changing the code into the following:Connection connection;
static boolean isRegistered = false;
public DBConnection() {
if (! isRegistered) {
DriverManager.registerdriver(new myDriver());
isRegistered = true;
connection = DriverManager.getConnection(...);
}Hope this could help others in the same situation.
Regards,
Torben Poort Lange

Error "The current garbage collector has no nursery"

Has anybody any information on the error message "The current garbage collector has no nursery"? We received the following error message after starting the WLS in production mode:
<2006-jan-25 kl 17:57 CET> <Error> <Management> <BEA-140001> <An error occurred while getting attribute TotalNurserySize on MBean se-i-ld09:Location=se-i-ld09-c01-s01,Name=se-i-ld09-c01-s01,ServerRuntime=se-i-ld09-c01-s01,Type=JRockitRuntime. Method: public long weblogic.t3.srvr.JRockitRuntime.getTotalNurserySize(). Exception: com.bea.jvm.NotAvailableException: The current garbage collector has no nursery..
com.bea.jvm.NotAvailableException: The current garbage collector has no nursery.
     at jrockit.management.jvm.GarbageCollectorImpl.getNurserySize()J(Unknown Source)
     at weblogic.t3.srvr.JRockitRuntime.getTotalNurserySize()J(JRockitRuntime.java:112)
     at jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lang.Object;[Ljava.lang.Object&amp)Ljava.lang.Object;(Unknown Source)
     at jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object&amp)Ljava.lang.Object;(Optimized Method)
     at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object&amp)Ljava.lang.Object;(Optimized Method)
     at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Optimized Method)
     at weblogic.management.internal.DynamicMBeanImpl.getAttribute(Ljava.lang.String&amp)Ljava.lang.Object;(DynamicMBeanImpl.java:574)
     at com.sun.management.jmx.MBeanServerImpl.getAttribute(Ljava.lang.Object;Ljava.lang.String&amp)Ljava.lang.Object;(MBeanServerImpl.java:1183)
     at com.sun.management.jmx.MBeanServerImpl.getAttribute(Ljavax.management.ObjectName;Ljava.lang.String&amp)Ljava.lang.Object;(MBeanServerImpl.java:1153)
     at weblogic.management.internal.RemoteMBeanServerImpl.getAttribute(Ljavax.management.ObjectName;Ljava.lang.String&amp)Ljava.lang.Object;(RemoteMBeanServerImpl.java:287)
     at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(ILweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object&amp)Lweblogic.rmi.spi.OutboundResponse;(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse&amp)V(BasicServerRef.java:477)
     at weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(BasicServerRef.java:420)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.subject.AbstractSubject;Ljava.security.PrivilegedExceptionAction&amp)Ljava.lang.Object;(AuthenticatedSubject.java:363)
     at weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.internal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedExceptionAction&amp)Ljava.lang.Object;(SecurityManager.java:144)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest&amp)V(BasicServerRef.java:415)
     at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread&amp)V(BasicExecuteRequest.java:30)
     at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest&amp)V(ExecuteThread.java:219)
     at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
     at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread&amp)V(Unknown Source)>
Thanks in advance for your help - it is much appreciated!
    Cheers, Jonas

This exception is thrown by the JRockit Management API when querying the nursery size of a GC that has no nursery (single-generational GC). The logical place to catch the error would be in the weblogic.t3.srvr.JRockitRuntime.getTotalNurserySize() method, which implies that it is a WLS issue.
Maybe it has been fixed in a later WLS 8.1 service pack?
If you run with a generational GC, i.e. "-Xgc:gencon" the error will go away, but that has larger implications on the behavior of your app so it should not be used as a workaround.

Problem with garbage collector -

I'm experiencing a problem with the Java Garbage Collector.
It simply doesn't work when I try to free the memory that is used
by an object in my program...
I explicitly declared this object as null, and called System.gc, but it seems it isn't working.
What might be the reason?
This object uses a lot of memory. Therefore, I MUST destroy it after it's no longer
needed.

Ok. I'll try to be more specific...
My "situation" seems something like that
class Program {
Xclass class1;
void method1() {
class1 = new Xclass();
} (End of class Program)
class Xclass {
Yclass class2;
Public Xclass( ) {
class2 = new Yclass();
add(class2);
} (end of class Xclass)
class Yclass {
Public Yclass(Container parent) {
(no explicit reference to Xclass or Program classes or any variable or instantiations of said classes);
} (end of class Yclass)
Well, I know that the gc is not being done because the first time I call method1 everything goes fine. But When I try it again an OutOfMemoryError happens...
I tried to do the following (I know, it's not elegant, but I just wanted to get some results):
void method1() {
class1 = null;
System.gc();
class1 = new Xclass();
Again it worked in the first time. But later...

Strange garbage collector behaviour

Hello,
I am seeing quite a strange behaviour from the garbage collector in one of our applications.
The application is a standalone Java app, it receives requests over a TCP socket and responds to them. It is basically a kind of a cache before the database. There is a constant request flow of 10-100 requests per second. Average response time is below 50ms. It is running on a multiprocessor Sun machine, JDK 1.4.1_02.
The problem arises when the app has been running for a while. Depending on the allowed maximum memory size - with 256mb after about half a day, with 512mb after about a day, the garbage collector seems to be running most of the time. We turned on GC logging and from the log I can see that initially for a long period only the DefNew collector is used. The GC times are ~0.05sec then. Then after some time old generation collections start taking place. These collections take 3-4 seconds. The old gen collections then become more frequent until all that is going on, is one collection after another. About 3-4seconds for the collection, then after another 3-4 seconds the same thing again.
Can anyone please help in understanding what can cause this kind of behaviour? I am quite sure that the app is stable in a sense that it doesn't start to eat up extra memory at some point.
Any help greatly appreciated,
erik
Here are some excerpts from the GC log:
After startup:
100.264: [GC 100.264: [DefNew: 83488K->1290K(84800K), 0.0487560 secs] 87278K->5080K(259584K), 0.0490613 secs]
107.439: [GC 107.439: [DefNew: 83530K->1299K(84800K), 0.0526107 secs] 87320K->5178K(259584K), 0.0528313 secs]
111.554: [GC 111.554: [DefNew: 83539K->1207K(84800K), 0.0539021 secs] 87418K->5230K(259584K), 0.0541348 secs]
119.724: [GC 119.724: [DefNew: 83447K->1359K(84800K), 0.0561691 secs] 87470K->5382K(259584K), 0.0564463 secs]
125.576: [GC 125.576: [DefNew: 83599K->1366K(84800K), 0.0622342 secs] 87622K->5504K(259584K), 0.0624880 secs]
130.987: [GC 130.987: [DefNew: 83606K->1331K(84800K), 0.0586104 secs] 87744K->5607K(259584K), 0.0588732 secs]
138.695: [GC 138.695: [DefNew: 83571K->1296K(84800K), 0.0588720 secs] 87847K->5697K(259584K), 0.0591136 secs]
144.413: [GC 144.413: [DefNew: 83536K->1246K(84800K), 0.0607789 secs] 87937K->5790K(259584K), 0.0612128 secs]
150.661: [GC 150.661: [DefNew: 83486K->1279K(84800K), 0.0486299 secs] 88030K->5823K(259584K), 0.0488933 secs]
157.186: [GC 157.187: [DefNew: 83519K->1410K(84800K), 0.0545036 secs] 88063K->5954K(259584K), 0.0547557 secs]
162.937: [GC 162.937: [DefNew: 83650K->1230K(84800K), 0.0590144 secs] 88194K->5998K(259584K), 0.0592747 secs]
171.555: [GC 171.555: [DefNew: 83470K->1334K(84800K), 0.0554568 secs] 88238K->6101K(259584K), 0.0557090 secs]
175.416: [GC 175.416: [DefNew: 83574K->1315K(84800K), 0.0584964 secs] 88341K->6178K(259584K), 0.0587433 secs]
182.616: [GC 182.616: [DefNew: 83555K->1307K(84800K), 0.0709417 secs] 88418K->6234K(259584K), 0.0712034 secs]
And then in the end:
13177.7: [GC 13177.7: [DefNew: 82240K->82240K(84800K), 0.0000487 secs]13177.7: [Tenured: 95861K->96094K(174784K), 3.7160279 secs] 178101K->96094K(259584K), 3.7165109 secs]
13183.9: [GC 13183.9: [DefNew: 82240K->82240K(84800K), 0.0000459 secs]13183.9: [Tenured: 96094K->96268K(174784K), 3.6973634 secs] 178334K->96268K(259584K), 3.6978356 secs]
13193: [GC 13193: [DefNew: 82240K->82240K(84800K), 0.0000534 secs]13193: [Tenured: 96268K->95923K(174784K), 4.6233189 secs] 178508K->95923K(259584K), 4.6237995 secs]
13201.2: [GC 13201.2: [DefNew: 82240K->82240K(84800K), 0.0000531 secs]13201.2: [Tenured: 95923K->96100K(174784K), 3.7120306 secs] 178163K->96100K(259584K), 3.7125165 secs]
13208.6: [GC 13208.6: [DefNew: 82240K->82240K(84800K), 0.0000502 secs]13208.6: [Tenured: 96100K->96268K(174784K), 3.6950267 secs] 178340K->96268K(259584K), 3.6955072 secs]
13218.1: [GC 13218.1: [DefNew: 82240K->82240K(84800K), 0.0000582 secs]13218.1: [Tenured: 96268K->96442K(174784K), 3.7476890 secs] 178508K->96442K(259584K), 3.7481875 secs]
13225.8: [GC 13225.8: [DefNew: 82240K->82240K(84800K), 0.0002743 secs]13225.8: [Tenured: 96442K->96200K(174784K), 4.9092106 secs] 178682K->96200K(259584K), 4.9103437 secs]
13234.4: [GC 13234.4: [DefNew: 82240K->82240K(84800K), 0.0000541 secs]13234.4: [Tenured: 96200K->96409K(174784K), 3.7423712 secs] 178440K->96409K(259584K), 3.7428506 secs]
13240.6: [GC 13240.6: [DefNew: 82240K->82240K(84800K), 0.0000528 secs]13240.6: [Tenured: 96409K->96633K(174784K), 3.6245501 secs] 178649K->96633K(259584K), 3.6250124 secs]
13273.7: [GC 13273.7: [DefNew: 82240K->82240K(84800K), 0.0000651 secs]13273.7: [Tenured: 96633K->96799K(174784K), 3.7021988 secs] 178873K->96799K(259584K), 3.7027242 secs]
13283: [GC 13283: [DefNew: 82240K->82240K(84800K), 0.0000510 secs]13283: [Tenured: 96799K->96620K(174784K), 4.9944806 secs] 179039K->96620K(259584K), 4.9949444 secs]
I can provide the whole log if neccessary.

The most likely cause of this problem is a memory leak in your application. As the memory reaches close to its limit the GC has to run for longer, more often to get free memory.
The runtime before going slow being proportional to the memory size.
Can you have the program log the System.freeMemory() and System.totalMemory()

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 in java

Similar Messages

Maybe you are looking for