Memory "leak"?

[Guest]

I'm doing a while true loop that never sets the boolean to false (ie I want
this program to run endlessly).

I've noticed after my thread sleeps for 30 seconds and wakes back up to
continue, the memory used by the system goes up by 4K.

Obviosly over days and weeks this will all mount up, so I really need to
understand about how to deal with garbage collection.

I null all my variables at the end of each loop and have created the
variables as private outside of the method I'm calling them in, in the main
class, but still the problem persists.

The code is rather long so I'd rather not post it in its entirety and have
to explain it all, but essentially the code goes:

while (true) {

checkThis();
thenCheckThis();
thenCheckThis();
Thread.sleep(30000);

}

all checkThis() does is:
{
go to a folder;
loops through folder;
anything with a certain file extension gets sent to another method;
}

That method just moves it the file from one place to another, deleting the
file from the original folder then thats it.

Why always 4K? Is this because java has a memory leak when running a loop,
or is it my code?

TIA for any pointers where to start looking!

 

[Patricia Shanahan]

I'm doing a while true loop that never sets the boolean to false (ie I want
this program to run endlessly).

I've noticed after my thread sleeps for 30 seconds and wakes back up to
continue, the memory used by the system goes up by 4K.

Obviosly over days and weeks this will all mount up, so I really need to
understand about how to deal with garbage collection.

I null all my variables at the end of each loop and have created the
variables as private outside of the method I'm calling them in, in the main
class, but still the problem persists.

As a test, try putting a System.gc() call inside the loop. Does the
memory use still tend to climb?

Patricia

 

[Guest]

As a test, try putting a System.gc() call inside the loop. Does the

memory use still tend to climb?

Thanks Patricia - I like simple litle gems like that.

The memory used stepped up quite quickly after I guess the first
System.gc(); line was called, but after that it climbed by 4KB only once and
now a full 10 minutes later, the memory usage is still the same. So in
conclusion, the memory went up by around 500KB by using the garbage
collector and then a further 4KB after the next loop, but then stabilised
(or at least as far as I can see).

Let's hope it stays that way. I'll check back on it in a few hours and if it
climbs again, I'll post back, but it seems that this might be fixed. Thanks
once again for that brilliant suggestion!

 

[Andreas Leitgeb]

Thanks Patricia - I like simple litle gems like that.
The memory used stepped up quite quickly after I guess the first
System.gc(); line was called, but after that it climbed by 4KB only
once and now a full 10 minutes later, the memory usage is still the
same.

How long have you been watching your program before posting
your initial question?

My guess is, that without the gc() call it would slowly
grow until to that same size of about 500kb, and then the
growth would probably come to an end, anyway.

If 500kb is more than you think the app should take, then you
can play with some extra parameters to the "java program" (the jvm).
see: "java -X", especially: "-Xmx".

 

[Patricia Shanahan]

Thanks Patricia - I like simple litle gems like that.

The memory used stepped up quite quickly after I guess the first
System.gc(); line was called, but after that it climbed by 4KB only once and
now a full 10 minutes later, the memory usage is still the same. So in
conclusion, the memory went up by around 500KB by using the garbage
collector and then a further 4KB after the next loop, but then stabilised
(or at least as far as I can see).

Let's hope it stays that way. I'll check back on it in a few hours and if it
climbs again, I'll post back, but it seems that this might be fixed. Thanks
once again for that brilliant suggestion!

Note that you may not need the System.gc() call. If it is effective, it
means that the climbing memory is due to finalizable, but unfinalized,
objects. The JVM would have done GC anyway before running out of memory.

The explicit call is a quick way of finding out whether that GC call
would have found memory it could free, and the result suggests that it
could.

That said, it is possible that your trade-offs call for more time spent
doing GC and less memory use than the JVM's trade-offs. If so, it may be
worth doing GC once every N iterations, for some value of N.

Patricia