• Post Reply Bookmark Topic Watch Topic
  • New Topic

OutOfMemoryException  RSS feed

 
Amit Gupt
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was asked this question in one of my job interviews. I dont know the right answer so am putting it out for people to respond.

If you encounter an OutOfMemoryException then how will you be able to narrow the scope of the problem ?

I said use a profiler and see all the usefull stats like how many objects are getting created, how many are getting destroyed etc and figure out the piece of code thats causing the problem. Once you are able to narrow the scope of the problem go through the particular code and look for place where objects are getting instantiated but somehow not getting garbage collected.

To this the interviewer asked if there is a long running suite of test scripts and this error is encountered after 4 hrs since the script started executing then how would you figure out the source of the problem ?

I was not able to give a convincing answer for this question. Can someone share your experiences for this question ?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My naive answer would be: run the test script in a profiler for three and a half hours and take a look at which objects accumulated. But I'm far from being an expert.
 
Dave Wingate
Ranch Hand
Posts: 262
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've never tried this, but one idea would be to weave your long-running script together with an aspect that could log the creation of all new objects.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No need to use an aspect, the typical profiler can already do it.
 
James Treacy
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Amit, excuse me if my interpretation is wrong, but might the interviewer have wanted to know how you could quickly reproduce the exception? In that case you could reduce the maximum heap size of the JVM so that the error could be reproduced much more quickly.
 
JuanP barbancho
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I make a test with a class with 100 MB and the program run.

OutOfmemory is a problem of memory leak,

You must review your code
 
jiju ka
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Out Of Memmory occurs when there is no more memmory available to allot.

Memmory leak is caused when an unallotted memmory is referenced. Pointer is not in java. So memmory leaks too. The purpose of not having pointers is to prevent memmoryleak from happening.
 
Wagner Danda Da Silva Filho
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by jiju ka:
Memmory leak is caused when an unallotted memmory is referenced. Pointer is not in java. So memmory leaks too. The purpose of not having pointers is to prevent memmoryleak from happening.



The definition I know for memory leak is other:

"Memory leaks are often thought of as failures to release unused memory by a computer program. Strictly speaking, it is just unnecessary memory consumption. A memory leak occurs when the program loses the ability to free the memory. A memory leak diminishes the performance of the computer, as it becomes unable to use all its available memory."

"In languages providing automatic memory management, like Java, C# or LISP there can be memory leaks too. The memory management does not free an object that is strongly reachable"

Source: Wikkipedia, http://en.wikipedia.org/wiki/Memory_leak
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We just had IBM read memory dumps for us and they identified a particular application class with zillions of instances. They turned out to be right on the money.

Previously we had tried eating up memory with various sized allocations to see if the system behavior matched the production problem and determined that it was a relatively small leak over a long period of time.

We also used a tool (SWP? from IBM?) that logs any time a new object allocation is over a certain size. We set it to log over 70k and found some interesting things, but the actual leak never happened while we had this on. I'm sure it would have made the offending class pretty evident.
 
jiju ka
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to Wagner for correcting the misconception.
 
JuanP barbancho
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My expertise, says that an application generated outofmemory, and you have really egnouth memory, is a memory leak.

A simple sample:

a reference b, b reference a , c reference a.

c finalize.

a y b do not remove by the GC.

Thank
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by JuanP barbancho:

A simple sample:

a reference b, b reference a , c reference a.

c finalize.

a y b do not remove by the GC.


Sorry, but that's wrong. If both a and b aren't reachable from your code, they are eligible for gc, even if they reference each other.
 
JuanP barbancho
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

c is a singleton like a Vector.

a and b are add to the Vector.

Thanks you
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by JuanP barbancho:

c is a singleton like a Vector.

a and b are add to the Vector.


I'm sorry, I have no idea what you are talking about.
 
Virag Saksena
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Amit,
the OutOfMemoryException means the size of reachable objects is more than the max size of heap. Solving this would ideally be a three step process

#1. Find the biggest live objects -- Here big does not refer to an object's size as most of the heap will be used by String or characters of bytes. What you care about is the total size of all objects reachable from a given object.

#2. Trace the path to these objects from root. They are not getting garbage collected so they must be live.

#3. Find the code which creates the objects increasing the size

You can do all of it with JVMPI, JVMTI or bytecode instrumentation based tools in a development environment. However often the problem only appears in high throughput high concurrency environments, where the overhead of such tools might be unacceptable. Brian Goetz in a recent article, talked about the overhead of allocation in JVM being 10 machine instructions with the 142 Hotspot JVM.

All these instrumentation approaches add code on top of those 10 instruction cycles, and create new objects on top of it to track these allocations. So if your environment has enough headroom, you can track the leaks, but for a production environment at the edge, most of the instrumentation approaches will move the bottleneck (Heisenberg's uncertainty principle) and fail.

What you need is something which will provide a map of all the objects in the heap without instrumenting every new() call.
Not just their size and signature, but their relationships
so you can tell from a snapshot on how big the objects really are.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!