2012-07-10 10 views
12

Il codice di test che utilizza WeakReference non è riuscito a utilizzare Mono 2.11.3 (SGen) e la versione stabile 2.10.8. In un codice semplice come questostrano comportamento di WeakReference su Mono

object obj = new object(); 
WeakReference wr = new WeakReference(obj); 

Assert.IsTrue(wr.IsAlive); 

obj = null; 
GC.Collect(); 

Assert.IsFalse(wr.IsAlive); 

la seconda affermazione avrà esito negativo. L'aggiunta di GC.WaitForPendingFinalizers non aiuta. È un bug in Mono o nella mia testa? Grazie

+1

Se si tratta di un bug in la tua testa è possibile eseguire il debug remoto allegando PsychicDbg, ma terminare la sessione potrebbe rivelarsi fatale. – Polyfun

+4

Rilevante: [GC.Collect \ (\) CLR <> Mono difference.] (Http://mono.1490590.n4.nabble.com/GC-Collect-CLR-lt-gt-Mono-difference-td1536244.html) Perdo la comprensione dei 2/3 della discesa :) – AakashM

risposta

10

Non è un bug, ma un dettaglio di implementazione in cui il Mono GC si comporta diversamente dal GC MS. In questo caso, dal momento che hai creato l'oggetto obj nello stesso frame di stack, accade che venga mantenuto in vita dal codice di scansione conservativo dello stack. In codice reale (al contrario di casi di test banali come questo) questo non è un problema. Se per il vostro caso particolare è, suggerisco Allocare l'oggetto e la sua WeakReference in un metodo separato:

static WeakReference Alloc() 
{ 
    return new WeakReference (new object()); 
} 
+0

che ha funzionato, grazie – actionresult

0
[MethodImpl((MethodImplOptions.NoInlining)] 
static WeakReference Alloc() 
{ 
    return new WeakReference (new object()); 
} 

deve garantire Alloc() metodo non essere in linea quando si compila

+1

Questa risposta non risponde alla domanda dell'OP. Prendi in considerazione l'aggiunta di alcune spiegazioni alla tua risposta. – Clijsters