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

Similar Messages

  • Redirect garbage collector output to a historical file

    Hello to you all,
    I know how to redirect the garbage collector output to a file with the parameter -Xloggc:<file> but there is a problem: Everytime the jvm is rebooted, that file is reset, deleting all the information generated before.
    I would like the jvm to append the new information to that file instead of deleting the old one.
    Is there anyway to configure the jvm to do that?

    Hi you all again,
    Probably I didn't explain my problem correctly in the previous post.
    I'm using J2SDK 1.4.1_02 on a Windows 2K SP1 platform .
    I've read the JVM documentation and I've learnt a lot about tuning garbage collection but almost nothing about how to solve the problem I have.
    I know how to generate the verbosegc output with the parameter '-verbosegc' and how to redirect it to a file with the parameter '-Xloggc:<file>' but everytime the JMV is restarted the content of that file is deleted.
    Is it possible to append content to that file instead of overwriting it and can anyone give me a clue to do this?
    Thank you in advance.

  • 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.

  • I have a memory leak, objective-c 2.0, and garbage collector...

    the code i am using is a modification of the code/problem found in "Cocoa with Objective-C", chapter 3.
    i have tried to use the objective-c 2.0 garbage collector methodology, using @property, @synthesize, etc. when i run the code as listed below i get a leaking message.
    [Session started at 2008-02-01 23:33:37 -0500.]
    2008-02-01 23:33:38.070 SongsFoundationTool[28876:10b] * _NSAutoreleaseNoPool(): Object 0x2040 of class NSCFString autoreleased with no pool in place - just leaking
    Stack: (0x96b10178 0x96a3e0f8)
    2008-02-01 23:33:38.075 SongsFoundationTool[28876:10b] Song 1: We Have Exposive
    2008-02-01 23:33:38.076 SongsFoundationTool[28876:10b] * _NSAutoreleaseNoPool(): Object 0x2060 of class NSCFString autoreleased with no pool in place - just leaking
    Stack: (0x96b10178 0x96a3e0f8)
    2008-02-01 23:33:38.078 SongsFoundationTool[28876:10b] Song 2: Loops of Fury
    The Debugger has exited with status 0.
    when i include the commented out section, in the implementation file section, the description method, and use song1 and song2, in main, instead of song1.name and song2.name the program seems to run fine.
    The Debugger has exited with status 0.
    [Session started at 2008-02-01 23:38:24 -0500.]
    2008-02-01 23:38:24.375 SongsFoundationTool[28936:10b] Song 1: We Have Exposive
    2008-02-01 23:38:24.379 SongsFoundationTool[28936:10b] Song 2: Loops of Fury
    The Debugger has exited with status 0.
    please help me understand what's happening here.
    also, why was it necessary to use
    @property(copy, readwrite) NSString *name;
    @property(copy, readwrite) NSString *artist;
    instead of
    @property(readwrite) NSString *name;
    @property(readwrite) NSString *artist;
    thanks everyone, the code is below.
    // ....................... header file ...............
    #import <Cocoa/Cocoa.h>
    @interface Song : NSObject {
    NSString *name;
    NSString *artist;
    @property(copy, readwrite) NSString *name;
    @property(copy, readwrite) NSString *artist;
    @end
    //.................... the implementation file ..................
    #import "Song.h"
    @implementation Song
    @synthesize name;
    @synthesize artist;
    -(NSString *) description
    return [ self name ];
    @end
    //................................ main............................
    #import <Foundation/Foundation.h>
    #import "Song.h"
    int main (int argc, const char * argv[]) {
    Song *song1 = [ [ Song alloc ] init ];
    song1.name= @"We Have Exposive" ;
    [ song1 setArtist: @"The Future Sound Of Londown" ];
    Song *song2 = [ [ Song alloc ] init ];
    [ song2 setName: @"Loops of Fury" ];
    [ song2 setArtist: @"The Chemical Brothers" ];
    // Display Object
    NSLog( @"Song 1: %@", song1.name );
    NSLog( @"Song 2: %@", song2.name );
    // include statements below if -description method is uncommented
    // then comment out the two statements above. no memory leak if the code
    // is used from the statements below and - description is not commented out and
    // the two NSLog statements above are commented out.
    NSLog( @"Song 1: %@", song1 );
    NSLog( @"Song 2: %@", song2 );
    return 0;
    }

    Normally, your main only has a call to NSApplicationMain(). If you aren't doing a traditional MacOS X application, you will still want at least NSApplicationLoad() to get enough of the runtime to avoid those messages.
    I don't know for sure about the syntax of Objective-C 2.0. That stuff is all new. What error message are you getting that indicated that (copy, readwrite) is required? Could you provide a link to the actual example source? I did a quick check and assign and readwrite are the defaults. It is possible that readwrite by itself makes no sense. But I'm just guessing.

  • Logging Garbage collector for an OC4J with 2JVM

    Hi, I have one OC4J with two JVM setted.
    If I put -verbose:gc it logs in the std Output file.
    I trying to log the garbage collector in two different file each one for one JVM.
    Anyone as an idea?

    Don't create massive amounts garbage memory. It's that simple. You should try to limit the creation of memory inside your animation loop. If there is a process inside the loop that creates memory, there is definitely some way to create that item staticly, rather than allocating new memory with each iteration. There shouldn't be any kind of problem that would involve the creation of THIS much memory, and it's deallocation. If you read about how the garbage collector is implemented, you'll notice that it stores all of it's memory on a single conveyor belt. This is for ALL memory in the program. Therefor once the garbage collector has gone through and marked all of the memory that needs to be reclaimed, it performs it's sweep and must feeze the entire program because that conveyor belt can not be manipulated while it's re-arranging the memory. The garbage collector will eliminate MOST memory leaks, but it does not eliminate any thought on the part of the programmer about memory.
    -Jason Thomas.

  • 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 and verbose GC

    Hi, we are getting strange behavior with the garbage collector if the verbosegc is enabled. The gc still report it is collecting memory but none is ever freed. If the option is not enabled the problem disapear. Has anyone experience something similar?
    We are running on Sun 5.8 with weblogic 5.1 sp 8 and jdk 1.2.2_09

    Can you post some of the verbosegc output? Output with -XX:+PrintGCDetails might
    help a little more.

  • Garbage Collector in 5.0

    I have nevver known, how the garbage collector internally works. Now a memory problem forces me to understand it. I read several articles but I do not understand them.
    I have a simple question:
    Is it possible, that my application will get an OutOfMemoryError even if a garbage-collect would free most of the memory?
    In other words:
    Is it assured, that garbage collector will always run before an OutOfMemoryError occurs?
    I have an application, which parses hundreds of MB of data. However it is assured, that parsed data wont be hold in memory for long time. Normally my application would run with less then 64 MB.
    In Java 1.4.2 I have not encountered any memory problems. But in Java 5.0 I encountered the following problem:
    My application runs a very long period of time. During this time, the memory usage is about 16 MB. After that period the memory usage suddenly increases and does not stop increasing until a OutOfMemory Error occurs (this is mostly about 260 MB if I set -Xmx265m).
    I am sure that I do not hold references to that much data in my application.
    Why does the garbage collector not free the memory?
    Is the garbage collector in 5.0 different from the one in 1.4.2? If yes, can I set the garbage collector to be that one of 1.4.2???
    Thanks and regards
    Fatih Coskun

    Is it assured, that garbage collector will always run
    before an OutOfMemoryError occurs?Yes, an OutOfMemoryError is the GC failing to free enough memory.
    Why does the garbage collector not free the memory?
    Is the garbage collector in 5.0 different from the one
    in 1.4.2? If yes, can I set the garbage collector to
    be that one of 1.4.2???Tiger (JDK 5.0) has introduced some "ergonomics" based on the machine the application is run on:
    http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
    Also, you may want to use jconsole and other new tools in tiger:
    http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#debug
    -Alexis
    >
    Thanks and regards
    Fatih Coskun

  • Can someone explain how garbage collector works in this program ?

    class Chair {
    static boolean gcrun = false;
    static boolean f = false;
    static int created = 0;
    static int finalized = 0;
    int i;
    Chair() {
    i = ++created;
    if(created == 47)
    System.out.println("Created 47");
    public void finalize() {
    if(!gcrun) {
    // The first time finalize() is called:
    gcrun = true;
    System.out.println(
    "Beginning to finalize after " +
    created + " Chairs have been created");
    if(i == 47) {
    System.out.println(
    "Finalizing Chair #47, " +
    "Setting flag to stop Chair creation");
    f = true;
    finalized++;
    if(finalized >= created)
    System.out.println(
    "All " + finalized + " finalized");
    public class Garbage {
    public static void main(String[] args) {
    // As long as the flag hasn't been set,
    // make Chairs and Strings:
    while(!Chair.f) {
    new Chair();
    new String("To take up space");
    System.out.println(
    "After all Chairs have been created:\n" +
    "total created = " + Chair.created +
    ", total finalized = " + Chair.finalized);
    // Optional arguments force garbage
    // collection & finalization:
    if(args.length > 0) {
    if(args[0].equals("gc") ||
    args[0].equals("all")) {
    System.out.println("gc():");
    System.gc();
    if(args[0].equals("finalize") ||
    args[0].equals("all")) {
    System.out.println("runFinalization():");
    System.runFinalization();
    System.out.println("bye!");
    } ///:~
    This code is From Bruce Eckel's "thinking in Java"
    Here is what I understand and what I don't
    At a certain point during the execution of the while loop (in the method main), the garbage collector kicks in and will call the method finalize() -
    I am at a loss as to what happens afterwards -
    Do the chairs continue to get created (which means the variable i keeps incrementing) and the finalize method keep getting called (which means finalized keeps incrementing) till the system realizes it is really low on memory and starts reclaiming memory ie i now starts decrementing ?
    What I would like to know is the exact flow or execution of the code after the garbage collector starts kicking in ie. what happens to the variables "i" (does it increment and then decrement), "created" (does it keep incrementing ), "finalized" (does it keep incrementing) and when is the if i==47{ } statement within finalize() get executed.
    There is no part of the code where i is being decremented (so I am guessing that it is the garbage collector reclaiming object memory that must be decrementing it).
    I am really confused -unfortunately there's very little in the book that really explains the flow of execution after the garbage collector kicks in and finalize() is called.
    Any help would be greatly appreciated

    Nice example, but Bruce chose some suboptimal names, I think.
    "i" can be thought of as the "ID" of a given Chair (note that it is not static). It is neither incremented nor decremented - it's just assigned from "created". This lets us identify specific chairs (like, say, "Chair #47").
    "created" is a running total of the number of times the Chair constructor has been called.
    "finalized" is a running total of the number of Chairs that have been finalized.
    The process starts creating Chairs as fast as it can. Eventually, memory gets low, and gc() starts collecting Chairs. While that's happening, chairs are still being created in the main Thread. So "created" and "finalized" may both be incrementing at the same time.
    When gc() picks Chair#47, the finalizer code sets a flag that causes new Chairs to stop being created. This causes the program to fall out of the while() loop, and the program spits out its data and exits.
    On my machine, the program created 29,542 chairs before exiting.
    Remember - often, gc() runs only when/if the JVM decides it's running low on memory. Specifics depend on the JVM and the startup options you use - some JVMs are very, very clever about doing incremental garbage-collection these days.
    Does that make more sense?
    Grant
    (PS - it's very, very good that you posted a working code sample. But learn about the \[code\] and \[code\] tags, please - makes your sample WAY easier to read...)

  • Force Garbage Collector calling

    Hello
    I have simple, static, single thread program. But it's a lot of memory demanding (large SortedSet, about one million items). After I finish working with this big SortedSet, I call "clear()" on it, for safe. Function uses this Set exits, and reference to this Set dies. Problem is, when this function exits, it's called multiple times again (same function), but unreferenced memory is still occupied, and heap usage grows and grows.
    I need to force calling Garbage Collector and HALT MAIN PROCESS until GC refreshes all of unref. memory.
    I tried calling "System.gc()" - without effect, parameter "-Xincgc" - without effect.
    Thank you very much for help.
    Pleas excuse my poor English, but I hope you understand me.
    Tony (Czech Republic)

    Why is this growing heap a problem, and why do you feel compelled to force gc?
    Virtually all non-trivial applications experience growing and growing heap usage.
    But the JVM should run gc when it is running out of memory anyway.
    Did you get an OutOfMemoryError?
    If you did, then you should review either your JVM heap settings, or in the worst case, your code. Your program may unintentionnally hold on to objects after being done with them (a java 'memory leak').
    If you didn't get an OutOfMemoryError, then I suggest you don't worry about it.

  • * How about flash play 8 Garbage Collector working?

    Hi, I need to add some Image controls dynamically, yes,the
    number of those are unpredictable.
    My code to create them like this:
    quote:
    public function addImg(name:String, x:Number, y:Number):void
    var sm1:Image = new Image();
    sm1.source = "imgs/down_medium.gif";
    sm1.name = name;
    sm1.x = x;
    sm1.y = y;
    this.addChild(sm1);
    Then, it appeared in my application. if I add numbers of
    Image in my stage, they eat my memory crazily.
    so I want to kill some Image which is not in use, but I
    crashed.
    An Image named "img4kill" in stage, it's index in
    this.getChildren() is4, and it holds a image which size is about
    230K.
    I tried to kill it like this:
    quote:
    this.removeChildAt(4);
    yes, it's remove from the stage in faith, but I watched the
    memory that the browser using, before and after killing it.
    I found the memory it takes is not released.
    How can I kill it from both the stage and memory ? I tried
    the global function "delete" ,but failed too.
    I know that flash play 8.5 and later use a powerfull
    GC(garbage collector), but in the sample above, it dose't work for
    me.
    who can save me from this mud layer?any ideas?
    thanks a lot .
    (sorry about my ugly english)
    [email protected]

    Don't worry, the garbage collector will work very well in this case (and in every other case too :) ). It will only collect an object when no more references are pointing to it. Your array still holds a reference to all the items it contains (unless you explicitly do array[index] = null).
    There are only three ways that I know of to destroy a reference to an Object: 1). Set the reference to null 2). Let the reference fall out of scope 3) reassign the reference to another object
    The garbage collector will also be able to collect objects that have a cyclical references as long as none of the objects in the cycle are reachable.
    It pays to understand the ins and outs of garbage collection and memory management in the VM. Knowing that will let you know, for example, that allocating an Object in Java is a very cheap operation (while it is pretty expensive in C/C++).
    Check http://www.ibm.com/developerworks/java/library/j-jtp10283/ and http://www.ibm.com/developerworks/java/library/j-jtp11253/ and for more details about the GC
    Also don't worry about the performance impact of setters and getters, either the javac compiler or the Virtual Machines Just In Time Compiler will inline those small methods.
    In short don't worry about such low level performance problems and concentrate on your coding style and algorithms. The Hotspot JVM is an amazingly efficient piece of software. It also include a lot of optimizations that work very well in optimizing "standard" code. The more normally you code, the faster your program will be, so don't try clever optimizations tricks, they probably won't work well in java.
    Read the following articles for some discussion about performance in Java:
    http://www.ibm.com/developerworks/java/library/j-jtp04223.html
    http://www.ibm.com/developerworks/java/library/j-jtp09275.html
    http://www.ibm.com/developerworks/java/library/j-jtp01274.html

  • JNI - Garbage Collector Problem ?

    Hi,
    I've got a JNI methode, which ceate and lauch a Process in c++ (a process to make VoIP).
    - this methode is returning an int=the pointer to the instance (which implement this process) so that othet JNI methode can have access to the main instance.
    Under windows, everything works fine, but
    Using linux:
    I add a memory wathcher on my program to see the memory used by the application / memory available for the JVM.
    The memory used by the application is growing (this is normal at this point), but when the GC is callled (by the system) the Java application is frozen (no error message), and I have to kill it. On the oter side, the Dll is running normally !
    My theory is that under Linux, the GC is "feeing" the memory used by the c++ process , then java is trying to write on it, but have no access, or somehing like that.
    Is there any option to be check this theory: as Java is retunring no error, but just freezing, it is not very clear to understand.
    I tried, using JNI, but removing the Process in it, just calling a basic operation, and there is no bug.
    Is there a special procedure to do on LINUX, for managing the Garbage Collector with JNI ?
    Here is a piece of code :
    /***********Java Side******************/
    //The JNI def:
    public class JNIWrapper {
         public JNIWrapper() {
         // create the h323 Process
    public native int create();
    ///The class managing the JNI methodes and containing the pointer to the dll main class
    public class CallControlH323 implements CallControl {
         int h323StackPtr; //Pointer to the h323stack, needed in the c++ side
         JNIWrapper myJNIWrapper;
         String options; //option for the CallControl configuration
         public CallControlH323(){
              myJNIWrapper = new JNIWrapper();
         public void configure(String options, String codecs) {
              h323StackPtr = myJNIWrapper.create();
    /*************************C++ side*****************/
    //JNI functions (file JNITerminal.cxx)
    #include "JNITerminal.h"
    #include <stdio.h>
    // Java Global Variables
    jobject jobj;
    JavaVM *jvm;
    /** Create the MainInterface **/
    JNIEXPORT jint JNICALL Java_ca_sess_voicesess_terminal_JNIWrapper_create
         (JNIEnv *env, jobject obj)
         // Make object a Global Reference
         jobj = env->NewGlobalRef(obj);
         // Get Java VM
         env->GetJavaVM(&jvm);
         //create and start the main Process
         MainInterface * mainInterface;
         mainInterface = new MainInterface();
         return ( ( jint ) mainInterface );
    MainInterface inherite from PProcess (from Pwlib), it is the top process of the dll application
    MainInterface::MainInterface():PProcess("", "", MAJOR_VERSION, MINOR_VERSION, BUILD_TYPE, BUILD_NUMBER)
    #ifdef MSCVER
    #pragma warning(disable:4355)
    #endif
    #ifdef MSCVER
    #pragma warning(default:4355)
    #endif
         ShowOutputs("H323Lib: Create Main Interface");
    void MainInterface::Main () {}
    MainInterface::~MainInterface()
    /////////////////////////////////////////////////////////////////////////7
    If you have any suggestion, comment, help, don hesitate !!
    Thanks for your help
    Bart

    I also added the option -verbosegc to the java command.
    I noticed that the bug arrived after a Full gc:
    [Full GC 23301K->12351K(24844K), 0.3737040 secs]

  • How to run garbage collector???????

    I have to run garbage collector to enlarge totalmemory during runtime. I added code like System.gc( ), but it did nothing! the totalmemory stayed as before gc run.
    anybody has idea or suggestion?
    thanks a lot

    Are you sure that there are no lingering references to
    your objects. gc can only remove objects which have no
    references to them remaining.No, this is not how garbage collection works in Java. Garbage collection collects unreachable objects, not objects with no references to them.
    To understand the difference, look at this code:
    Vector v = new Vector();
    v.add(v);
    v = new Vector();The original Vector object is unreachable at the end of this code, and is available for garbage collection. This is despite the fact that there exists a reference to the Vector, which is inside the Vector itself.
    Some implementations of garbage collection, such as reference counting, really do collect only objects that have no references to them. Java's garbage collection is superior to these collectors: it collects all unreachable objects.

Maybe you are looking for