Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2006

Tip: Looking for answers? Try searching our database.

Static methods and GC

Thread view: 
marcin.rzeznicki@gmail.com - 28 Oct 2006 12:58 GMT
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 - 28 Oct 2006 14:38 GMT
> Hello,
> I've run into memory leak problem in my Java app. Before I start memory
[quoted text clipped - 30 lines]
> 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 - 28 Oct 2006 14:46 GMT
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?

> Patricia
Robert Klemme - 28 Oct 2006 17:21 GMT
> 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
[quoted text clipped - 3 lines]
> 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 - 28 Oct 2006 17:41 GMT
Robert Klemme napisal(a):
> > 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
[quoted text clipped - 7 lines]
> 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 - 29 Oct 2006 12:29 GMT
> Robert Klemme napisal(a):
>>> Well, it is not shown in my post but after static method forks
[quoted text clipped - 11 lines]
> 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 - 29 Oct 2006 13:14 GMT
Robert Klemme napisal(a):

> > Hi Robert, thanks for your reply.
> > So, do you think that 'static' can have anything to do with this? Would
[quoted text clipped - 5 lines]
> 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

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

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 - 29 Oct 2006 16:44 GMT
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.