I have an application which allocates a large number of objects (mostly of 3 classes) and occasionally releases these.
The ActivityMonitor Real Memory Usage only ever goes up, never down. (Indeed I have noticed this with other applications.)
Profiling shows my application has no leaks, and Garbage Collections shows objects being reclaimed.
Related
Memory is divided into "segments" called heap, stack, bss, data, and text. However, the JVM also has these concepts of stack and heap. So how are these two reconciled?
Are they different levels of abstraction, where main memory is one or two levels below the JVM, and whose "segments" maps naturally to JVM's "segments"? Since JVM is supposed to be a virtual computer, it seems to me like they emulate what happens underneath but at a higher level of abstraction.
Sounds to me like you've been reading a textbook or similar. All these terms generally have very precise definitions in books/lectures, but a lot less precise definitions in reality. Therefore what people mean when they say heap is not necessarily exactly the same as what a book etc. says.
Memory is divided into "segments" called heap, stack, bss, data, and text.
This is only true for a typical user space process. In other word this will be true for an everyday program written in c or similar, however it is not true for all programs, and definitely not true for the entire memory space.
When a program is executed the OS allocates memory for the various segments listed, except the the heap. The program can request memory from the OS while it is executing. This allows a program to use a different amount of memory depending on its needs. The heap refers to memory requested by the program usually via a function like malloc. To clarify the heap typically refers to a managed region of memory, usually managed with malloc/free. It is also possible to request memory directly from the OS, in an unmanaged fashion. Most people (Imo) would say this wouldn't count as part of the heap.
The stack is a data structure/segment which keeps track of local variables and function calls. It stores important information like where to return after a function call. In c or other "native" languages the stack is created by the OS and can grow or shrink if needed.
Java allows program to request memory during execution using new. Memory allocated to a java program using new is referred to as memory in the java heap. One could imagine that if you where implementing a Jvm you would use malloc behind the scenes of new. This would result in a java heap within a regular native heap. In reality "serious" jvms do not do this and interact directly with the OS for memory.
In Java the stack is created by the Jvm. One could imagine that this is allocated by malloc, but as with the heap this is likely not how real world jvms do it.
Edit:
A Jvm like hotspot. Would likely allocate memory directly from the OS. This memory would then get put into some kind of pool, from which it would be removed as needed. Reasons for needed memory would be needed includes new, or a stack that needs to grow.
I wrote a small document based application for OS X.
I see that every New document when created increases the memory usage (Xcode gauge) as expected, but when I close the document the memory usage is decreased only insignificantly.
Thus many New/Close operations produce memory leak ...
How to explain the leak, and how to free the memory ?
Details:
The application has a document which presents itself in a NSOutlineView with a million lines(big amount to demonstrate the memory usage change) containing the same string at every line.
I'm working on a cocoa app that receives and stores large amount data into core data ( > 500K objects with many reverse relationships). The app has to constantly run in cycles. The problem i encounter is after each cycle the allocated memory is growing by 20-40 megabytes (as indicated by xcode; of course, same tendency showed by activity monitor).
What i have so far:
wrapped methods that insert objects into context in autorelease pools;
reset context, undoManager nil, stalenessInterval 0;
recreate persistent store coordinator on cycle completion (remove-add the store);
many hours of profiling, but could not find leak causes
Thought i'll appreciate advices if this list of actions can be improved, my main question is how should i deal with system memory, which my app will eventually eat up. Because it's possible i wont be able to optimize my code any more. I must not allow the app to crash due to not enough memory; so the way i deal with it now is i relaunch the app if its memory allocation reaches some hardcoded value (lets say, 1 GB).
I don't like this solution, so hopefully someone can advice me on appropriate way to handle this. Or on ways experienced people handle such situations. Thanks
UPDATE
Adding snapshots from instruments and xcode's memory debug gauge when first cycle has finished.
Any idea why my app's memory usage does not increase whilst using Instruments profiler (searching for leaks), but does when I don't use any profiler? To the tune of 1MB per operation performed. Instruments does not show any leaks.
OS memory management is a complex thing. It is likely that when you free memory it is not returned immediately to the system, but instead it is still "attached" to your process to make any future allocations your application needs more efficient. Although it is recorded as part of your process's memory space, it would be marked as unused, and when the system is running out of memory (or when your application exits), it would then reclaim the unused memory from your application.
If Instruments isn't reporting any leaks, you should be fine.
I am developing windows application in VB.Net. My problem is after some time of running application commit size of memory get increased. I have used Memory profiler (Ant Profiler, CL R Profiler ) to identified the problem in application. it suggest me to dispose the object which is alive or not unregistered after close the form. Accordingly i dispose all the objects which can affect the memory leak.
But still cant get reduce the commit size once its go high.
Can anyone give me suggestion what to do?
The .NET garbage collector does not guarantee to free memory in any particular timeframe. It might, for example, wait until the memory is needed before freeing up used memory.
You can force a garbage collection by calling
GC.Collect
These articles explain things in a bit more depth:
http://msdn.microsoft.com/en-us/library/ms973837.aspx
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/