Stack Frames, Method Invocation and garbage Collection
I was studying GC. I came to know following mechanism about method invocation:
On every method Invocation in JAVA, a new Frame is created and pushed on stack. This frame contains local variables, operand stack and reference to constant pool. Frame is removed when either method has completed successfully or the method throws an uncaught exception.
And also following:
The JVM specification does not require a particular implementation for the Java stack. Frames could be allocated individually from a heap, or they could be taken from contiguous memory, or both.
My question is:
Since Frame is a part of Stack. Stack is a part of Non-Heap area. If GC only takes care of cleaning Heap Area, then how and when Stack frames which may or may not reside in Heap are removed from memory?
If Frames are not removed by GC, then there must be some other thread running to clean them up. What is it? If they are cleaned by GC, then It would simply mean that if an application is runinng into GC related problems, unnecessary method calls might be a part of problem.
I hope my question is clear.
UPDATE: Another Question related to same:
class GCA {
public static void main(String a[]) {
Object obj = new Object();
}
}
As per my understanding, in above method:
obj will be allocated on Stack Frame's local variable array. new Object() will get allocated on Heap. obj resides is not responsibility of GC. It will be synchronously done when method returns. new Object() will be cleaned up by GC. Is above understanding correct ?
Since Frame is a part of Stack. Stack is a part of Non-Heap area. If GC only takes care of cleaning Heap Area, then how and when Stack frames which may or may not reside in Heap are removed from memory?
There are two views to this. One is the way the Java application sees things. Objects get allocated on the heap, but local variables (ie primitive values and references to these objects) live on the stack. In this sense, the statement you made is correct: stack frames form the stack, distinct from the heap, and thus are not subject to garbage collection.
The other view is that of the internal workings of the JVM, and its interface to the operating system. For reasons of efficiency, it might decide to place an object on a stack even if conceptually it belongs on the heap. This is for the sake of performance, after escape analysis. Likewise it might decide to keep parts of the conceptual stack in heap-allocated memory which it manages itself, instead of the native call stack the JVM itself uses. This is what the specification refers to: the JVM doesn't have to use a stack in the low level programming sense to implement the Java call stack. But even if it uses operating system heap, that is still not part of the heap subject to GC.
If Frames are not removed by GC, then there must be some other thread running to clean them up.
No. Another thread would only be required if frames were to be freed asynchronously. But freeing a stack frame is easy: as soon as a function exits, the frame can be freed, since all its data goes out of scope. Thus the thread leaving the function is responsible for that clean-up. The asynchronous GC isn't involved at all.
链接地址: http://www.djcxy.com/p/82742.html下一篇: 堆栈框架，方法调用和垃圾收集