How does a garbage collector avoid an infinite loop here?

Question

Consider the following C# program, I submitted it on codegolf as an answer to create a loop without looping:

class P{
    static int x=0;
    ~P(){
        System.Console.WriteLine(++x);
        new P();
    }
    static void Main(){
        new P();
    }
}

This program looks like an infinite loop in my inspection, but it seems to run for several thousand iterations, and then the program terminates successfully without error (No errors are thrown). Is it a spec violation that the finalizer for P eventually is not called?

Clearly this is stupid code, that should never appear, but I am curious as to how the program could ever complete.

Original code golf post:: https://codegolf.stackexchange.com/questions/33196/loop-without-looping/33218#33218

That a finalizer isn't called is [certainly within the realm of valid behavior](http://blogs.msdn.com/b/oldnewthing/archive/2010/08/09/10047586.aspx). I don't know why it bothers to run several thousand iterations though, I'd expect zero invocations. — , Jul 09 '14 at 19:45
I get approximately 40,000 iterations. I'm guessing there's a timeout on finalizer threads. I'm going to have to try this on Mono when I get home. :) — David Crowell, Jul 09 '14 at 19:46
The CLR has protection against the finalizer thread never being able to finish its job. It forcefully terminates it after 2 seconds. — Hans Passant, Jul 09 '14 at 19:49
So the real answer to your question in the title is that it avoids it by just letting the infinite loop run for 40 seconds and then it is terminated. — Lasse V. Karlsen, Jul 09 '14 at 19:54
Pretty much. I'm guessing it's too difficult to inspect arbitrary code that could instantiate new objects. — Michael B, Jul 09 '14 at 19:57
What happens if you spawn off new threads in the constructor... which creates more objects? — David Crowell, Jul 09 '14 at 21:02
From trying it, it seems that the program just kills everything after 2 seconds no matter what. Actually if you keep spawning threads it'll last quite a bit longer :) — Michael B, Jul 09 '14 at 21:22
Hmmm. I'm surprised that ending the program triggers finalizers in that way. I thought you'd only get one pass. — Joshua, Jul 10 '14 at 01:17
@delnan: Just because finalizers aren't guaranteed doesn't mean it won't /try/, just that they aren't reliable. I can't think of many sane use cases for this, frankly, but there's no sense in not trying. — Phoshi, Jul 10 '14 at 08:48
@Phoshi I expected zero invocations because I expected no major GC before process shutdown, and hence no objects being put in the finalizer queue. Of course finalizers will be invoked sometimes. — , Jul 10 '14 at 09:00

Eric Scherrer · Accepted Answer · 2014-07-25T13:11:39.470

111

As per Richter in the second edition of CLR via C# (yes I need to update):

Page 478

For (The CLR is shutting down) each Finalize method is given approximately two seconds to return. If a Finalize method doesn't return within two seconds, the CLR just kills the process - no more Finalize methods are called. Also, if it takes more then 40 seconds to call all objects' Finalize methods, again, the CLR just kills the process.

Also, as Servy mentions, it has its own thread.

edited Jul 25 '14 at 13:11

answered Jul 09 '14 at 19:52

Eric Scherrer

3,328
1
19
34

5

Each finalize method in this code takes dramatically under 40 seconds per object. That a new object is created and then eligible for finalization is not relevant to the current finalizer. – Jacob Krall Jul 10 '14 at 16:09
2

This isn't actually what gets the job done. There's also a timeout on the freachable queue getting emptied at shutdown. Which is what this code fails on, it keeps adding new objects to that queue. – Hans Passant Jul 24 '14 at 23:20
Just thinking about this, isn't emptying the freachable queue the same as "Also, if it takes more then 40 seconds to call all objects' Finalize methods, again, the CLR just kills the process." – Eric Scherrer Jul 25 '14 at 13:08

score 23 · Answer 2 · edited Jul 09 '14 at 19:51

23

The finalizer doesn't run in the main thread. The finalizer has its own thread that runs code, and it's not a foreground thread that would keep the application running. The main thread completes effectively right away, at which point the finalizer thread simply runs as many times as it gets a chance to before the process gets torn down. Nothing is keeping the program alive.

edited Jul 09 '14 at 19:51

Nate Cook

92,417
32
217
178

answered Jul 09 '14 at 19:49

Servy

202,030
26
332
449

If the finalizer hasn't completed 40 seconds after the program should've exited due to no main thread being alive, it will be terminated and the process will terminate. These are old values though so Microsoft might have tweaked the actual numbers or even the whole algorithm by now. Se http://blog.stephencleary.com/2009/08/finalizers-at-process-exit.html – Lasse V. Karlsen Jul 09 '14 at 19:52
@LasseV.Karlsen Is that documented behavior of the language, or simply how MS chose to implement their finalizers as an implementation detail? I would expect the latter. – Servy Jul 09 '14 at 19:55
I expect the latter as well. The most official reference to this behavior I've seen is what Eric above posted in his answer, from the book CLR via C# by Jeffrey Richter. – Lasse V. Karlsen Jul 09 '14 at 19:55

Willem Van Onsem · Answer 3 · 2014-07-09T19:57:09.513

A garbage collector is not an active system. It runs "sometimes" and mostly on demand (for instance when all pages offered by the OS are full).

Most garbage collectors run in a breadth-first generation-like manner in a subthread. In most cases it can take hours before the object is recycled.

The only problem occurs when you want to terminate the program. However that's not really a problem. When you use kill an OS will ask politely to terminate processes. When the process however remains active, one can use kill -9 where the Operating System removes all control.

When I ran your code in the interactive csharp environment, I've got:

csharp>  

1
2

Unhandled Exception:
System.NotSupportedException: Stream does not support writing
  at System.IO.FileStream.Write (System.Byte[] array, Int32 offset, Int32 count) [0x00000] in <filename unknown>:0 
  at System.IO.StreamWriter.FlushBytes () [0x00000] in <filename unknown>:0 
  at System.IO.StreamWriter.FlushCore () [0x00000] in <filename unknown>:0 
  at System.IO.StreamWriter.Write (System.Char[] buffer, Int32 index, Int32 count) [0x00000] in <filename unknown>:0 
  at System.IO.CStreamWriter.Write (System.Char[] buffer, Int32 index, Int32 count) [0x00000] in <filename unknown>:0 
  at System.IO.CStreamWriter.Write (System.Char[] val) [0x00000] in <filename unknown>:0 
  at System.IO.CStreamWriter.Write (System.String val) [0x00000] in <filename unknown>:0 
  at System.IO.TextWriter.Write (Int32 value) [0x00000] in <filename unknown>:0 
  at System.IO.TextWriter.WriteLine (Int32 value) [0x00000] in <filename unknown>:0 
  at System.IO.SynchronizedWriter.WriteLine (Int32 value) [0x00000] in <filename unknown>:0 
  at System.Console.WriteLine (Int32 value) [0x00000] in <filename unknown>:0 
  at P.Finalize () [0x00000] in <filename unknown>:0

Thus your program crashes because stdout is blocked by the termintation of the environment.

When removing the Console.WriteLine and killing the program. It after five second the program terminates (in other words, the garbage collector gives up and simply will free all memory without taking finalizers into account).

This is fascinating that the interactive csharp blows up for entirely different reasons. The original program snippet didn't have the console writeline, I'm curious if it would terminate too. — Michael B, Jul 09 '14 at 19:59
@MichaelB: I've tested this as well (see comment below). It waits for five second and then terminates. I guess the finalizer of the first `P` instance simply timed out. — Willem Van Onsem, Jul 09 '14 at 20:01

How does a garbage collector avoid an infinite loop here?

3 Answers3