Static methods and GC

[marcin.rzeznicki]

Hello,
I've run into memory leak problem in my Java app. Before I start memory
profiling to know for sure I just wanted to ask You whether it is
reasonable to think that static methods can be causing this problem.
App design is as follows:

public static void main() {
...
for(...)
theStaticFunction();
...
}

private static void theStaticFunction() {
...
T[] memoryConsumingArray = ....
MyThread t = new MyThread(memoryConsumingArray);
t.start();
...
}

I'll provide you little explanation: In Main function some function
which is private and static is executed in loop, possibly many times.
Function creates local array which consumes a lot of heap memory (not
only because it has many elements but also every element contains large
object graph). Next this array is paased to thread constructor and
thread does further processing. Array or its elements are not assigned
to any static fields, they exist only in theStaticFunction, so should
be not reachable from roots of gc as soon as all threads finish they
work. Yet, program crashes with OutOfMemory from time to time unless it
is given 1GB of RAM or so, which is little too much So I am trying
to examine potential memory leaks. The first suspect is this array, as
it is dominating factor of memory consumption. Do you think that
problem might lie in large array being used from static function?

 

[Patricia Shanahan]

Hello,
I've run into memory leak problem in my Java app. Before I start memory
profiling to know for sure I just wanted to ask You whether it is
reasonable to think that static methods can be causing this problem.
App design is as follows:

public static void main() {
...
for(...)
theStaticFunction();
...
}

private static void theStaticFunction() {
...
T[] memoryConsumingArray = ....
MyThread t = new MyThread(memoryConsumingArray);
t.start();
...
}

I'll provide you little explanation: In Main function some function
which is private and static is executed in loop, possibly many times.
Function creates local array which consumes a lot of heap memory (not
only because it has many elements but also every element contains large
object graph). Next this array is paased to thread constructor and
thread does further processing. Array or its elements are not assigned
to any static fields, they exist only in theStaticFunction, so should
be not reachable from roots of gc as soon as all threads finish they
work. Yet, program crashes with OutOfMemory from time to time unless it
is given 1GB of RAM or so, which is little too much So I am trying
to examine potential memory leaks. The first suspect is this array, as
it is dominating factor of memory consumption. Do you think that
problem might lie in large array being used from static function?

I don't see the static method as being an issue. It looks as though you
only have one activation of it at a time, and each activation can
reference at most one T[] at a time.

I'd worry more about the threads. Is there anything that prevents all
the threads from existing, and each referencing its own T[], at the same
time? If not, how much memory would it take?

Patricia

 

[Marcin Rzeznicki]

Patricia Shanahan napisal(a):

Hi Patricia,
Thank you for your reply

I don't see the static method as being an issue. It looks as though you
only have one activation of it at a time, and each activation can
reference at most one T[] at a time.

Yes, that's true

I'd worry more about the threads. Is there anything that prevents all
the threads from existing, and each referencing its own T[], at the same
time? If not, how much memory would it take?

Well, it is not shown in my post but after static method forks
execution it does some processing of its own and then blocks in waiting
for created thread to finish. So, after the method exits thread is sure
to be dead. Then I assume that local array is soon to be gc-ed, because
every thread referencing it is finished and it is local variable of
method which stack frame is being dropped. Do you agree with this
reasoning?

 

[Robert Klemme]

Well, it is not shown in my post but after static method forks
execution it does some processing of its own and then blocks in waiting
for created thread to finish. So, after the method exits thread is sure
to be dead. Then I assume that local array is soon to be gc-ed, because
every thread referencing it is finished and it is local variable of
method which stack frame is being dropped. Do you agree with this
reasoning?

Theoretically yes. But it is difficult to tell without seeing the real
code. And then there is also the question how many active threads you
have at a time. Is that number limited?

Kind regards

robert

 

[Marcin Rzeznicki]

Robert Klemme napisal(a):

Theoretically yes. But it is difficult to tell without seeing the real
code. And then there is also the question how many active threads you
have at a time. Is that number limited?

Hi Robert, thanks for your reply.
So, do you think that 'static' can have anything to do with this? Would
you recommend memory profiling?
As for active threads at a time - yes, this number is limited and this
number is constant at any point of execution, this is not a "pool"
model where number of threads would be dependent on data being
processed.

 

[Robert Klemme]

Robert Klemme napisal(a):

Hi Robert, thanks for your reply.
So, do you think that 'static' can have anything to do with this? Would
you recommend memory profiling?

Well, you can do that. Maybe you find out it's not the large array you
suspect but some completely unrelated other piece of code which is
responsible for the OOME. You might as well try running in the debugger
which will easily tell you whether threads do actually terminate the way
you intend / think.

As for active threads at a time - yes, this number is limited and this
number is constant at any point of execution, this is not a "pool"
model where number of threads would be dependent on data being
processed.

Note, typically it is the pool models that limit the number of threads.

At the moment it is practically next to impossible to come up with more
advice because we know too little of your code / problem.

Regards

robert

 

[Marcin Rzeznicki]

Robert Klemme napisal(a):

Well, you can do that. Maybe you find out it's not the large array you
suspect but some completely unrelated other piece of code which is
responsible for the OOME. You might as well try running in the debugger
which will easily tell you whether threads do actually terminate the way
you intend / think.

Yes, possibly - I think that this is the best way to go

Note, typically it is the pool models that limit the number of threads.

Total, yes - but number of active threads depend on data (bounded by
pool size) I think eg. in model with a shared queue where pooled
threads sleep waiting for items to be processed and choose it for
processing with round robin fashion. Number of active threads then is
determined indirectly by "load factor" of the queue. This is not my
case - in my problem number of active threads is limited and constant,
it does not matter how many items are in the array, there is always
predefined number of threads working

At the moment it is practically next to impossible to come up with more
advice because we know too little of your code / problem.

Yes, I am aware of that. Actually only problem I want to solve with
your kind help is whether fact that method in question is static might
be causing any problems. How do you think?
ert

 

[Robert Klemme]

Yes, I am aware of that. Actually only problem I want to solve with
your kind help is whether fact that method in question is static might
be causing any problems. How do you think?
ert

Static methods are no different with regard to GC than non static ones. It
all depends on what objects they create and where they store references.
You can create a memory leak with a static as well as with a non static
method.

robert