Re: Garbage collection question?

John C. Bollinger wrote: 
Knute Johnson wrote:

I normally don't even think about garbage collection. I know it works and works well. I'm working on a very large application (for me anyway) that will have to run continuously for months. A small leak over a long period of time could end up a big break in the dam. So I got to wondering how it would be possible to write code that would not be able to be garbage collected. Since I really don't know how it works, that was my first question.

So for my second question, you often see code like this:

for (;;) {
    Object o = new Object();
    ....
}

You could potentially create lots of objects. When you make the first pass through the loop a new Object is created. On subsequent passes is the previous then marked for garbage collection?


An object automatically becomes eligible for garbage collection when it ceases to be reachable from any live thread via a chain of strong (normal) references. That is the only criterion. Modern VMs typically do not monitor assignment statements to make that determination; instead they periodically trace reference chains to find which objects need to be /kept/.

In the example you present, the Object created at the top of each loop iteration becomes eligible for GC as soon as a new reference is assigned to variable o, *provided that* the old Object's reference has not been assigned to some object that persists across loop iterations. (For example, if the loop added the object to a List then the Object would not become eligible for GC before the List did.)

Is the reference o created on the stack too and is it reused?


Local variables occupy space on the stack, but the number of local variable slots in a stack frame is determined by the compiler. Almost certainly, each iteration of the loop will use the same slot to represent variable o. Even if different slots were used, the stack frame size is fixed at compile time, so an infinite loop will quickly have to start reusing variable slots, so you will not get a memory leak from this direction.

Do references get garbage collected?


When a thread returns from a method, its stack frame for that method invocation is popped, freeing all the memory occupied by the local variables of that method for that invocation. This isn't garbage collection per se, but I think it addresses your concern even better.


Thanks John and everybody else that answered. I appreciate the time and effort for my enlightenment.

--

Knute Johnson
email s/nospam/knute/
.

Relevant Pages

  • Re: accessing records
    ... ISTM the assembler translates the outer procedure local variable ... This results in [ebp - X], where X depends on which variable ... The outer procedure should always have a stack frame (i'm quite sure ... Therefore you can fetch local variables from it's ...
    (borland.public.delphi.language.basm)
  • Re: Why does returning from a block cause a LocalJumpError
    ... If I understand correctly, even though b is defined inside the loop, a ... and b are both stored in the same stack frame when this method is ... I see your logic -- you're trying to look at how the language runtime ... Maybe I'm perseverating on this point, but I'm curious about how Ruby ...
    (comp.lang.ruby)
  • Re: Go To Statement Considered Harmful
    ... -> variables on a stack. ... including the local variables of an outer or ... In this case, it's not the FOR loop that has its own local variables, ... If you use a GOSUB instead: ...
    (comp.lang.basic.misc)
  • Re: Code efficiency - declare variable sinside or outdie a loop.
    ... > MY concern was that inside the loop, ... > Was trying to avoid allocate/deallocate loop ... The compiler will allocate stack frame slots according ...
    (comp.lang.java.programmer)
  • Re: vector performance: iterator versus subscripting
    ... loading the value of strvec.endor strvec.sizeinto ... |> saved to local variables before? ... you can not store the endbefore the loop starts. ... is a first choice if a functor can be provided easily. ...
    (comp.lang.cpp)