Garbage Collector

Résolu
romagny13 Messages postés 687 Date d'inscription lundi 10 janvier 2005 Statut Membre Dernière intervention 27 août 2014 - 25 juil. 2007 à 23:18
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 26 juil. 2007 à 18:54
Bonsoir,

au niveau du Garbage Collector jen'ai pas trop bien compris

GC

.SuppressFinalize(
this);
est ce que cette méthode detruit automatiquement l'objet passé ? en fait ce n'est pas tres clair (pour moi lol) apparemment la méthode fait que le finaliseur de l'objet ne sera pas appelé ?? en fait je comprends pas trop

est ce que l'on peut forcer la destruction d'objets grace à GC ? (qui me serait peut etre utile pour la destruction d'objets d'un cache)

GC.RemoveMemoryPressure()

GC.AddMemoryPressure()

je comprends pas tres bien a quoi servent ces methodes

existe t'il d'autres classes permettant d'interagir avec le garbage collector ?

merci
++

Se poser les bonnes questions ;) 
apporter les réponses
A voir également:

3 réponses

Lutinore Messages postés 3246 Date d'inscription lundi 25 avril 2005 Statut Membre Dernière intervention 27 octobre 2012 41
26 juil. 2007 à 07:35
Salut,
 
Pas de destruction déterministe en C#, c-à-d que tu ne peux pas choisir le moment ou ton objet sera réellement détruit. Ce qui pose un gros problème car par exemple en C++ on est habitué à libérer des ressources critiques dans le destructeur de la classe, fermer une connexion, fermer un fichier etc..

Les concepteurs de .NET on proposé l'interface IDisposable et sa méthode Dispose pour jouer le rôle en sorte de destructeur mais ce n'est qu'une "convention" après tout n'importe qu'elle fonction nommée "Destroy" ou "Kill" ferait aussi bien. ( l'interface IDisposable a quand même un avantage, le mot clé using. ).

Le problème de la fonction Dispose c'est que l'utilisateur de la classe ne doit pas oublier de l'appeler, ce n'est pas automatique, du coup on libère aussi les ressources dans le destructeur ( une sorte de 2ème chance ). Plutôt que de recopier 2 fois le même code on appelle Dispose dans le dtor.


~DeviceData( ) // dtor
{
    Dispose( false );
}


public void Dispose( )
{
    Dispose( true );
    GC.SuppressFinalize( this );
}


private void Dispose( bool disposing )
{
    if ( disposing )
    {
       // ..
    }




    // Libère les ressources critiques.
    if ( hGlobal != IntPtr.Zero )
    {
        Marshal.FreeHGlobal( hGlobal );
        hGlobal = IntPtr.Zero;
    }
}


Si l'utilisateur a déja appelé Dispose, le destructeur devient donc inutile, c'est le rôle de la méthode GC.SuppressFinalize( ) qui supprime l'appele au dtor, ( le runtime n'exécutera jamais le dtor ) ce qui est très utile car finaliser un objet avec un dtor c'est assez couteux pour le GC.

Imagine maintenant que tu alloues bcp de mémoire non-managée avec une fonction Win32 par exemple dans un tout petit objet managé, le GC lui il ne voit pas la mémoire non-managée, il ne la connait pas, pour lui tu n'utilises presque pas de mémoire et il n'est donc pas pressé de libérer ton objet. AddMemoryPressure( ) permet d'indiquer que ton objet est en fait plus lourd que ce que pense le GC. Une fois la mémoire non-managée supprimée ( dans dispose ou dans le dtor donc ) on utilise RemoveMemoryPressure.
3
romagny13 Messages postés 687 Date d'inscription lundi 10 janvier 2005 Statut Membre Dernière intervention 27 août 2014 3
25 juil. 2007 à 23:26
a oui et puis pendant que j'y suis pour WeakReference

pareil lol je n'ai pas tout compris appremment on met un objet refrence par target
et tant que l'objet specifié na pas ete detruit par le garbage collector il peut etre "ressuscité " ?? même apres lui avoir affecter null ?
:p

Se poser les bonnes questions ;) 
apporter les réponses
0
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 101
26 juil. 2007 à 18:54
Salut,

Pour la référence faible : si tu perd la référence à l'instance de WeakReference, comment veux tu y accéder pour récupérer ta valeur ? Donc non.

Concernant la définition d'un finaliseur, faites quand même bien attention de ne pas faire de traitements bloquants dedans, histoire de ne pas bloquer le thread du finaliseur. Je déconseillerais même d'y faire des traitements particulièrement lents.
Et pensez à bien gérer les exceptions : si je me souviens bien il y a une différence majeure dans la gestion des exceptions dans le thread du finaliseur entre les CLR 1.1 et 2.0 : en 1.1 les autres finaliseurs étaient executés, alors qu'en 2.0 l'application se termine (A vérifier).

/*
coq
MVP Visual C#
CoqBlog
*/
0
Rejoignez-nous