Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe Lephay
"Sylfelin" a écrit dans le message de news:
Je sais c'est le gc qui le fait mais si je fait
ObjetComm obj = new ObjetComm();
puis
obj = null;
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le comportement du gc ?
L'objet créé par 'instruction new ObjetComm() sera supprimé de la mémoire au prochain Collect du GB s'il n'a pas été référencé auparavant (par exemple via un ObjetComm obj2 = obj; avant l'instruction obj=null;).
Tu ne peux rien supposer sur le moment où cette suppression aura lieu, et donc sur l'appel du dstructeur s'il existe, sauf si tu déclanches toi-même le ramassage via GC.Collect() (déconseillé).
Quant à l'impact sur la mémoire, le gc va vraissemblablement conserver la mémoire libérée pour un usage ultérieur.
"Sylfelin" <sylfelin_EN_TROP_@cegetel.net> a écrit dans le message de news:
mn.930d7d7a02cadc56.60937@cegetel.net...
Je sais c'est le gc qui le fait mais si je fait
ObjetComm obj = new ObjetComm();
puis
obj = null;
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le
comportement du gc ?
L'objet créé par 'instruction new ObjetComm() sera supprimé de la mémoire au
prochain Collect du GB s'il n'a pas été référencé auparavant (par exemple
via un ObjetComm obj2 = obj; avant l'instruction obj=null;).
Tu ne peux rien supposer sur le moment où cette suppression aura lieu, et
donc sur l'appel du dstructeur s'il existe, sauf si tu déclanches toi-même
le ramassage via GC.Collect() (déconseillé).
Quant à l'impact sur la mémoire, le gc va vraissemblablement conserver la
mémoire libérée pour un usage ultérieur.
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le comportement du gc ?
L'objet créé par 'instruction new ObjetComm() sera supprimé de la mémoire au prochain Collect du GB s'il n'a pas été référencé auparavant (par exemple via un ObjetComm obj2 = obj; avant l'instruction obj=null;).
Tu ne peux rien supposer sur le moment où cette suppression aura lieu, et donc sur l'appel du dstructeur s'il existe, sauf si tu déclanches toi-même le ramassage via GC.Collect() (déconseillé).
Quant à l'impact sur la mémoire, le gc va vraissemblablement conserver la mémoire libérée pour un usage ultérieur.
Le Thu, 18 Oct 2007 17:21:38 +0200, Sylfelin a écrit:
avant l'instruction obj=null;)
=null détruit donc l'objet ?
Non...
C'est le GC qui le fera plus-tard, s'il n'existe aucune référence à votre objet...
Cordialement
-- Gilles TOURREAU
S.A.R.L. P.O.S Le spécialiste en motoculture depuis + de 30 ans ! http://www.pos.fr
Patrick Philippot
Bonjour,
obj = null;
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le comportement du gc ?
obj = null n'a aucun effet sur le GC. Le GC de .Net ne travaille pas comme le COM par comptage de références. On vérifie en permanence l'accessibilité d'une instance via les différentes références qui pointent sur elle. Si l'instance n'est plus accessible, elle est candidate au garbage collect. Quand ce garbage collect aura lieu dépend de la génération dans laquelle se trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce principe s'applique également au programmeur - et plus il a de chances de se trouver en génération 1 ou 2 et plus en génération 0. Ce qui a pour conséquence de retarder encore plus le moment où le GC va se décider à l'évacuer.
Le principe est qu'on ne libère pas de mémoire si on n'a pas besoin de le faire. Cela rend l'action du GC discrète, rapide, opportune et efficace.
Ce principe général s'applique donc au RCW (Runtime Callable Wrapper), objet .Net qui encapsule l'objet COM. Le release ne sera fait sur l'objet COM que lorsque le RCW sera garbage collecté. Cependant, on peut forcer le release au sens COM du terme en appelant Marshal.ReleaseCOmObject(obj) ce qui a pour effet de décrémenter le reference count de l'objet COM encapsulé. ReleaseComObject retournant le nouveau reference count, un moyen radical d'évacuer l'objet COM est de faire
while (Marshal.ReleaseComObject(obj) > 0) {}
Cela provoquera l'évacuation de l'objet COM encapsulé. Cependant, la "coquille" (le RCW) sera toujours vivante. C'est le GC qui décidera de sa destruction.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
obj = null;
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le
comportement du gc ?
obj = null n'a aucun effet sur le GC. Le GC de .Net ne travaille pas comme
le COM par comptage de références. On vérifie en permanence l'accessibilité
d'une instance via les différentes références qui pointent sur elle. Si
l'instance n'est plus accessible, elle est candidate au garbage collect.
Quand ce garbage collect aura lieu dépend de la génération dans laquelle se
trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet
a vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce
principe s'applique également au programmeur - et plus il a de chances de se
trouver en génération 1 ou 2 et plus en génération 0. Ce qui a pour
conséquence de retarder encore plus le moment où le GC va se décider à
l'évacuer.
Le principe est qu'on ne libère pas de mémoire si on n'a pas besoin de le
faire. Cela rend l'action du GC discrète, rapide, opportune et efficace.
Ce principe général s'applique donc au RCW (Runtime Callable Wrapper), objet
.Net qui encapsule l'objet COM. Le release ne sera fait sur l'objet COM que
lorsque le RCW sera garbage collecté. Cependant, on peut forcer le release
au sens COM du terme en appelant Marshal.ReleaseCOmObject(obj) ce qui a pour
effet de décrémenter le reference count de l'objet COM encapsulé.
ReleaseComObject retournant le nouveau reference count, un moyen radical
d'évacuer l'objet COM est de faire
while (Marshal.ReleaseComObject(obj) > 0) {}
Cela provoquera l'évacuation de l'objet COM encapsulé. Cependant, la
"coquille" (le RCW) sera toujours vivante. C'est le GC qui décidera de sa
destruction.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Quelle sont le résultat de ce code sur la mémoire, l'objet et sur le comportement du gc ?
obj = null n'a aucun effet sur le GC. Le GC de .Net ne travaille pas comme le COM par comptage de références. On vérifie en permanence l'accessibilité d'une instance via les différentes références qui pointent sur elle. Si l'instance n'est plus accessible, elle est candidate au garbage collect. Quand ce garbage collect aura lieu dépend de la génération dans laquelle se trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce principe s'applique également au programmeur - et plus il a de chances de se trouver en génération 1 ou 2 et plus en génération 0. Ce qui a pour conséquence de retarder encore plus le moment où le GC va se décider à l'évacuer.
Le principe est qu'on ne libère pas de mémoire si on n'a pas besoin de le faire. Cela rend l'action du GC discrète, rapide, opportune et efficace.
Ce principe général s'applique donc au RCW (Runtime Callable Wrapper), objet .Net qui encapsule l'objet COM. Le release ne sera fait sur l'objet COM que lorsque le RCW sera garbage collecté. Cependant, on peut forcer le release au sens COM du terme en appelant Marshal.ReleaseCOmObject(obj) ce qui a pour effet de décrémenter le reference count de l'objet COM encapsulé. ReleaseComObject retournant le nouveau reference count, un moyen radical d'évacuer l'objet COM est de faire
while (Marshal.ReleaseComObject(obj) > 0) {}
Cela provoquera l'évacuation de l'objet COM encapsulé. Cependant, la "coquille" (le RCW) sera toujours vivante. C'est le GC qui décidera de sa destruction.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Sylfelin
> trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce principe s'applique également au programmeur -
Joli trait d'humour; Merci pour tes explications.
--
-------------------------- Merci Sylfelin
> trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet a
vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce
principe s'applique également au programmeur -
> trouve actuellement l'instance et de nombreux autres facteurs. Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j'adorerais que ce principe s'applique également au programmeur -
Joli trait d'humour; Merci pour tes explications.
--
-------------------------- Merci Sylfelin
Delf
On 18 oct, 18:44, "Patrick Philippot" wrote:
Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j 'adorerais que ce principe s'applique également au programmeur - et plus il a de c hances de se trouver en génération 1 ou 2 et plus en génération 0. Ce qu i a pour conséquence de retarder encore plus le moment où le GC va se décide r à l'évacuer.
Et si la mémoire venait à manquer sur l'OS, est-ce-que le GC libèrerait les objets 'à hautes générations' ? Merci.
-- Delf
On 18 oct, 18:44, "Patrick Philippot"
<patrick.philip...@mainsoft.xx.fr> wrote:
Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j 'adorerais
que ce principe s'applique également au programmeur - et plus il a de c hances
de se trouver en génération 1 ou 2 et plus en génération 0. Ce qu i a pour
conséquence de retarder encore plus le moment où le GC va se décide r à
l'évacuer.
Et si la mémoire venait à manquer sur l'OS, est-ce-que le GC
libèrerait les objets 'à hautes générations' ?
Merci.
Plus l'objet a vécu, plus il a de chances de vivre encore longtemps - j 'adorerais que ce principe s'applique également au programmeur - et plus il a de c hances de se trouver en génération 1 ou 2 et plus en génération 0. Ce qu i a pour conséquence de retarder encore plus le moment où le GC va se décide r à l'évacuer.
Et si la mémoire venait à manquer sur l'OS, est-ce-que le GC libèrerait les objets 'à hautes générations' ? Merci.
