¿Cómo evita un recolector de basura un bucle infinito aquí?

Considere el siguiente programa C #, lo envié en codegolf como respuesta para crear un bucle sin bucle:

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

Este programa parece un bucle infinito en mi inspección, pero parece ejecutarse durante varios miles de iteraciones, y luego el programa termina con éxito sin errores (no se lanzan errores). ¿Es una infracción de especificación para la que Pfinalmente no se llama al finalizador ?

Claramente, este es un código estúpido, que nunca debería aparecer, pero tengo curiosidad por saber cómo podría completarse el programa.

Código original de la publicación de golf: /codegolf/33196/loop-without-looping/33218#33218

Según Richter en la segunda edición de CLR a través de C # (sí, necesito actualizar):

Página 478

Para (El CLR se está apagando), cada método Finalize tiene aproximadamente dos segundos para regresar. Si un método Finalize no regresa en dos segundos, CLR simplemente mata el proceso; no se llaman más métodos Finalize . Además, si se necesitan más de 40 segundos para llamar a los métodos Finalize de todos los objetos , nuevamente, CLR simplemente mata el proceso.

Además, como menciona Servy, tiene su propio hilo.

El finalizador no se ejecuta en el hilo principal. El finalizador tiene su propio subproceso que ejecuta código, y no es un subproceso en primer plano que mantendría la aplicación en ejecución. El hilo principal se completa de forma efectiva de inmediato, momento en el que el hilo del finalizador simplemente se ejecuta tantas veces como tenga la oportunidad antes de que el proceso se detenga. Nada mantiene vivo el programa.

Un recolector de basura no es un sistema activo. Se ejecuta "a veces" y principalmente a pedido (por ejemplo, cuando todas las páginas que ofrece el sistema operativo están llenas).

La mayoría de los recolectores de basura se ejecutan de manera similar a la primera generación en un subproceso. En la mayoría de los casos, pueden pasar horas antes de que el objeto se recicle.

El único problema ocurre cuando desea terminar el programa. Sin embargo, eso no es realmente un problema. Cuando utilice killun sistema operativo le pedirá cortésmente que finalice los procesos. Sin embargo, cuando el proceso permanece activo, se puede usar kill -9donde el sistema operativo elimina todo el control.

Cuando ejecuté su código en el csharpentorno interactivo , obtuve:

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

Por lo tanto, su programa se bloquea porque stdoutestá bloqueado por la terminación del entorno.

Al eliminar Console.WriteLiney matar el programa. Después de cinco segundos, el programa termina (en otras palabras, el recolector de basura se rinde y simplemente liberará toda la memoria sin tener en cuenta a los finalizadores).