|
|
You're in the
dotnet clr
group:GC SuppressFinalize and ReRegisterForFinalize
dotnet clr:
I am having trouble understanding the code below.
(From http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ Figure 9) I am looking for an explanation about how the SuppressFinalize calls work. From reading the documentation, i get the idea that SuppressFinalize would remove the obj from the finalization table, so wouldnt it remove all the entries for a obj as i am operating on the same object? If it toggles a flag on the obj, how come finalize gets called two times? void method() { // The MyObj type has a Finalize method defined for it // Creating a MyObj places a reference to obj on the finalization table. MyObj obj = new MyObj(); // Append another 2 references for obj onto the finalization table. GC.ReRegisterForFinalize(obj); GC.ReRegisterForFinalize(obj); // There are now 3 references to obj on the finalization table. // Have the system ignore the first call to this object's Finalize // method. GC.SuppressFinalize(obj); // Have the system ignore the first call to this object's Finalize // method. GC.SuppressFinalize(obj); // In effect, this line does absolutely // nothing! obj = null; // Remove the strong reference to the object. // Force the GC to collect the object. GC.Collect(); // The first call to obj's Finalize method will be discarded but // two calls to Finalize are still performed. }
Hi Priyesh
In the article you point to, Jeffrey explains that SuppressFinalize sets a flag in the object to not run the finalizer. So if you have 3 references to the same object on the finalization queue, the GC will set the bit when it reaches that object on the queue, then discard it. After that, when the GC reaches the object a second time onthe queue, the flag gets reset "this flag is reset when the runtime determines that it's time to call a Finalize method", so that's why the finalizer is run twice in the sample you provided. That being said, I can't think of a valid scenario when someone would want to reregister a live object, so I don't expect this scenario cropping up much in real life. Also, for what it's worth, that article is pretty outdated, and contains some inaccurate information. For example, it's not possible to override Finalize in C#, and it's impossible to explicitly call an object's Finalization method. Also, an object's parent's finalizer is called automatically (check out the IL to see for yourself). Hope that helps -Chris -------------------- [quoted text, click to view] >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> >Subject: GC SuppressFinalize and ReRegisterForFinalize >Date: Sun, 25 Jul 2004 12:11:35 -0700 >Lines: 39 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> >Newsgroups: microsoft.public.dotnet.framework.clr >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net 216.222.33.194 >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11293 >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > >I am having trouble understanding the code below. >(From http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ Figure 9) > >I am looking for an explanation about how the SuppressFinalize calls work. >From reading the documentation, i get the idea that SuppressFinalize would >remove the obj from the finalization table, so wouldnt it remove all the >entries for a obj as i am operating on the same object? If it toggles a flag >on the obj, how come finalize gets called two times? > >void method() { > // The MyObj type has a Finalize method defined for it > // Creating a MyObj places a reference to obj on the finalization table. > MyObj obj = new MyObj(); > > // Append another 2 references for obj onto the finalization table. > GC.ReRegisterForFinalize(obj); > GC.ReRegisterForFinalize(obj); > > // There are now 3 references to obj on the finalization table. > > // Have the system ignore the first call to this object's Finalize > // method. > GC.SuppressFinalize(obj); > > // Have the system ignore the first call to this object's Finalize > // method. > GC.SuppressFinalize(obj); // In effect, this line does absolutely > // nothing! > > obj = null; // Remove the strong reference to the object. > > // Force the GC to collect the object. > GC.Collect(); > > // The first call to obj's Finalize method will be discarded but > // two calls to Finalize are still performed. >} > > > -- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
Thanks for your explanation and the points about the correctness of the
article. I understand that this is a theoretical scenario to explain some of the GC functionality available. I was thinking that there is some sort of reference counting mechanism for the same object in the finalization queue. Since the example operates on a single object, i got myself into thinking SuppressFinalize call on that object would affect that one object and would not let any further Finalize calls. From your explanation, it seems that the finalization queue contains a separate structure which has a pointer to the object to be finalized. When ReRegisterForFinalize is called on an object, is there another memory structure created in the finalization queue? If so, how does the SuppressFinalize determine which reference in the queue to apply the suppress to? (Does it apply to the first reference in queue all the time?) Is there a way to get rid of all pending finalization requests? I would really appreciate your follow up on these questions. [quoted text, click to view] ""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message flag in the object to not run the finalizer. So if you have 3 references tonews:V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl... > Hi Priyesh > > In the article you point to, Jeffrey explains that SuppressFinalize sets a the same object on the finalization [quoted text, click to view] > queue, the GC will set the bit when it reaches that object on the queue, then discard it. After that, when the GC reaches the object a second timeonthe queue, the flag gets reset [quoted text, click to view] > "this flag is reset when the runtime determines that it's time to call a Finalize method", so that's why the finalizer is run twice in the sample youprovided. [quoted text, click to view] > to reregister a live object, so I don't expect this scenario cropping up> That being said, I can't think of a valid scenario when someone would want much in real life. [quoted text, click to view] > some inaccurate information. For example, it's not possible to override> Also, for what it's worth, that article is pretty outdated, and contains Finalize in C#, and it's impossible to [quoted text, click to view] > explicitly call an object's Finalization method. Also, an object's parent's finalizer is called automatically (check out the IL to see foryourself). [quoted text, click to view] > message are best directed to the newsgroup/thread from which they> Hope that helps > -Chris > > > -------------------- > >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> > >Subject: GC SuppressFinalize and ReRegisterForFinalize > >Date: Sun, 25 Jul 2004 12:11:35 -0700 > >Lines: 39 > >X-Priority: 3 > >X-MSMail-Priority: Normal > >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 > >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> > >Newsgroups: microsoft.public.dotnet.framework.clr > >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net 216.222.33.194 > >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl > >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11293 > >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > > > >I am having trouble understanding the code below. > >(From http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ Figure 9) > > > >I am looking for an explanation about how the SuppressFinalize calls work. > >From reading the documentation, i get the idea that SuppressFinalize would > >remove the obj from the finalization table, so wouldnt it remove all the > >entries for a obj as i am operating on the same object? If it toggles a flag > >on the obj, how come finalize gets called two times? > > > >void method() { > > // The MyObj type has a Finalize method defined for it > > // Creating a MyObj places a reference to obj on the finalization table. > > MyObj obj = new MyObj(); > > > > // Append another 2 references for obj onto the finalization table. > > GC.ReRegisterForFinalize(obj); > > GC.ReRegisterForFinalize(obj); > > > > // There are now 3 references to obj on the finalization table. > > > > // Have the system ignore the first call to this object's Finalize > > // method. > > GC.SuppressFinalize(obj); > > > > // Have the system ignore the first call to this object's Finalize > > // method. > > GC.SuppressFinalize(obj); // In effect, this line does absolutely > > // nothing! > > > > obj = null; // Remove the strong reference to the object. > > > > // Force the GC to collect the object. > > GC.Collect(); > > > > // The first call to obj's Finalize method will be discarded but > > // two calls to Finalize are still performed. > >} > > > > > > > > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm > > Note: For the benefit of the community-at-large, all responses to this originated. [quoted text, click to view] >
Hi Chris,
Thanks for the reply. Here is what i understand from your explanation. 1. The finalization queue will keep on adding references to the same object to match ReRegisterForFinalize calls on the same object. 2. SuppressFinalize will set the "run my finalizer bit" in the obj. When GC reaches a reference in the finalization queue, it checks this bit and if the bit is not set, wont move that to the f-reachable. GC would set the bit on the object so that the object references pending in the finalization queue will be moved to f-reachable and eventually the Finalize method will be called. Please tell me if i understood it right. Thanks Priyesh [quoted text, click to view] ""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message SuppressFinalize(obj) affects the first reference to obj on the queue, sonews:J5Cv5a$cEHA.3204@cpmsftngxa10.phx.gbl... > Hi Priyesh > > No, there's no reference counting involved on the finalization queue. calling it several times in a row has [quoted text, click to view] > no added effect, regardless of how many times obj is on the queue. (strong) reference to the object in memory. In the object's header is the> > The finalization queue doesn't have a seperate structure, rather a "run my finalizer" bit. When [quoted text, click to view] > suppressis called, the GC scans the queue from the front and and stops at the first reference to obj (when called again, it starts from the front ofthe queue again). That bit is set [quoted text, click to view] > in the header of the object obj points to. When reregister is called on obj, another reference to the object is placed at the end of the (FIFO)queue), so Suppress will never reach [quoted text, click to view] > past the first reference (which is why, as Richter states, you cannot have a suppress after every call to reregister. Short of that, maybebalance out several calls to Rereg with Suppress). > > The only I can think of to remove all pending finalization requestsis to setting a flag in your finalizer to say [quoted text, click to view] > your object has already been finalized would remove redundant cleanup, but cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12wouldn't stop the object from being put on the queue. > > Hope that helps > -Chris > > > -------------------- > >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> > >References: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> <V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl> > >Subject: Re: GC SuppressFinalize and ReRegisterForFinalize > >Date: Tue, 27 Jul 2004 07:20:18 -0700 > >Lines: 126 > >X-Priority: 3 > >X-MSMail-Priority: Normal > >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 > >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > >Message-ID: <uS5cvV#cEHA.244@TK2MSFTNGP12.phx.gbl> > >Newsgroups: microsoft.public.dotnet.framework.clr > >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net 216.222.33.194 > >Path: ..phx.gbl [quoted text, click to view] > >Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:11372
> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > > > >Thanks for your explanation and the points about the correctness of the > >article. I understand that this is a theoretical scenario to explain some of > >the GC functionality available. > > > >I was thinking that there is some sort of reference counting mechanism for > >the same object in the finalization queue. Since the example operates on a > >single object, i got myself into thinking SuppressFinalize call on that > >object would affect that one object and would not let any further Finalize > >calls. From your explanation, it seems that the finalization queue contains > >a separate structure which has a pointer to the object to be finalized. > > > >When ReRegisterForFinalize is called on an object, is there another memory > >structure created in the finalization queue? > >If so, how does the SuppressFinalize determine which reference in the queue > >to apply the suppress to? (Does it apply to the first reference in queue all > >the time?) > >Is there a way to get rid of all pending finalization requests? > > > >I would really appreciate your follow up on these questions. > > > > > > > >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message > >news:V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl... > >> Hi Priyesh > >> > >> In the article you point to, Jeffrey explains that SuppressFinalize sets a > >flag in the object to not run the finalizer. So if you have 3 references to > >the same object on the finalization > >> queue, the GC will set the bit when it reaches that object on the queue, > >then discard it. After that, when the GC reaches the object a second time > >onthe queue, the flag gets reset > >> "this flag is reset when the runtime determines that it's time to call a > >Finalize method", so that's why the finalizer is run twice in the sample you > >provided. > >> > >> That being said, I can't think of a valid scenario when someone would want > >to reregister a live object, so I don't expect this scenario cropping up > >much in real life. > >> > >> Also, for what it's worth, that article is pretty outdated, and contains > >some inaccurate information. For example, it's not possible to override > >Finalize in C#, and it's impossible to > >> explicitly call an object's Finalization method. Also, an object's > >parent's finalizer is called automatically (check out the IL to see for > >yourself). > >> > >> Hope that helps > >> -Chris > >> > >> > >> -------------------- > >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> > >> >Subject: GC SuppressFinalize and ReRegisterForFinalize > >> >Date: Sun, 25 Jul 2004 12:11:35 -0700 > >> >Lines: 39 > >> >X-Priority: 3 > >> >X-MSMail-Priority: Normal > >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 > >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > >> >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> > >> >Newsgroups: microsoft.public.dotnet.framework.clr > >> >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net > >216.222.33.194 > >> >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl > >> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11293 > >> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > >> > > >> >I am having trouble understanding the code below. > >> >(From http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ Figure 9) > >> > > >> >I am looking for an explanation about how the SuppressFinalize calls > >work. > >> >From reading the documentation, i get the idea that SuppressFinalize > >would > >> >remove the obj from the finalization table, so wouldnt it remove all the > >> >entries for a obj as i am operating on the same object? If it toggles a > >flag > >> >on the obj, how come finalize gets called two times? > >> > > >> >void method() { > >> > // The MyObj type has a Finalize method defined for it > >> > // Creating a MyObj places a reference to obj on the finalization
Thankyou. I really appreciate it.
[quoted text, click to view] ""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message that reference is removed from the queue, at which point the GC resets thenews:kBCnAbCdEHA.3204@cpmsftngxa10.phx.gbl... > Hi Priyesh > > 1. Yes, that's right. > > 2. Yes. SuppressFinalizer sets the "run my finalizer" bit to false, and bit to true. Now when the next [quoted text, click to view] > reference to the same object is encountered on the queue, the object is
moved to the f-reachable queue where its finalizer gets run. > > I think we're on the same page now :) > > -Chris > > -------------------- > > > > >Hi Chris, > >Thanks for the reply. Here is what i understand from your explanation. > > > >1. The finalization queue will keep on adding references to the same object > >to match ReRegisterForFinalize calls on the same object. > > > >2. SuppressFinalize will set the "run my finalizer bit" in the obj. When GC > >reaches a reference > >in the finalization queue, it checks this bit and if the bit is not set, > >wont move that to the f-reachable. GC would set the bit on the object so > >that the object references pending in the finalization queue will be moved > >to f-reachable and eventually the Finalize method will be called. > > > >Please tell me if i understood it right. > > > >Thanks > >Priyesh > > > >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message > >news:J5Cv5a$cEHA.3204@cpmsftngxa10.phx.gbl... > >> Hi Priyesh > >> > >> No, there's no reference counting involved on the finalization queue. > >SuppressFinalize(obj) affects the first reference to obj on the queue, so > >calling it several times in a row has > >> no added effect, regardless of how many times obj is on the queue. > >> > >> The finalization queue doesn't have a seperate structure, rather a > >(strong) reference to the object in memory. In the object's header is the > >"run my finalizer" bit. When > >> suppressis called, the GC scans the queue from the front and and stops at > >the first reference to obj (when called again, it starts from the front of > >the queue again). That bit is set > >> in the header of the object obj points to. When reregister is called on > >obj, another reference to the object is placed at the end of the (FIFO) > >queue), so Suppress will never reach > >> past the first reference (which is why, as Richter states, you cannot > >balance out several calls to Rereg with Suppress). > >> > >> The only I can think of to remove all pending finalization requestsis to > >have a suppress after every call to reregister. Short of that, maybe > >setting a flag in your finalizer to say > >> your object has already been finalized would remove redundant cleanup, but > >wouldn't stop the object from being put on the queue. > >> > >> Hope that helps > >> -Chris > >> > >> > >> -------------------- > >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> > >> >References: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> > ><V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl> > >> >Subject: Re: GC SuppressFinalize and ReRegisterForFinalize > >> >Date: Tue, 27 Jul 2004 07:20:18 -0700 > >> >Lines: 126 > >> >X-Priority: 3 > >> >X-MSMail-Priority: Normal > >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 > >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > >> >Message-ID: <uS5cvV#cEHA.244@TK2MSFTNGP12.phx.gbl> > >> >Newsgroups: microsoft.public.dotnet.framework.clr > >> >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net > >216.222.33.194 > >> >Path: > >cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1 2 > >.phx.gbl > >> >Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:11372 > >> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > >> > > >> >Thanks for your explanation and the points about the correctness of the > >> >article. I understand that this is a theoretical scenario to explain some > >of > >> >the GC functionality available. > >> > > >> >I was thinking that there is some sort of reference counting mechanism > >for > >> >the same object in the finalization queue. Since the example operates on > >a > >> >single object, i got myself into thinking SuppressFinalize call on that > >> >object would affect that one object and would not let any further > >Finalize > >> >calls. From your explanation, it seems that the finalization queue > >contains > >> >a separate structure which has a pointer to the object to be finalized. > >> > > >> >When ReRegisterForFinalize is called on an object, is there another > >memory > >> >structure created in the finalization queue? > >> >If so, how does the SuppressFinalize determine which reference in the > >queue > >> >to apply the suppress to? (Does it apply to the first reference in queue > >all > >> >the time?) > >> >Is there a way to get rid of all pending finalization requests? > >> > > >> >I would really appreciate your follow up on these questions. > >> > > >> > > >> > > >> >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message > >> >news:V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl... > >> >> Hi Priyesh > >> >> > >> >> In the article you point to, Jeffrey explains that SuppressFinalize > >sets a > >> >flag in the object to not run the finalizer. So if you have 3 references > >to > >> >the same object on the finalization > >> >> queue, the GC will set the bit when it reaches that object on the > >queue, > >> >then discard it. After that, when the GC reaches the object a second > >time > >> >onthe queue, the flag gets reset > >> >> "this flag is reset when the runtime determines that it's time to call > >a > >> >Finalize method", so that's why the finalizer is run twice in the sample > >you > >> >provided. > >> >> > >> >> That being said, I can't think of a valid scenario when someone would > >want > >> >to reregister a live object, so I don't expect this scenario cropping up > >> >much in real life. > >> >> > >> >> Also, for what it's worth, that article is pretty outdated, and > >contains > >> >some inaccurate information. For example, it's not possible to override > >> >Finalize in C#, and it's impossible to > >> >> explicitly call an object's Finalization method. Also, an object's > >> >parent's finalizer is called automatically (check out the IL to see for > >> >yourself). > >> >> > >> >> Hope that helps > >> >> -Chris > >> >> > >> >> > >> >> -------------------- > >> >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> > >> >> >Subject: GC SuppressFinalize and ReRegisterForFinalize > >> >> >Date: Sun, 25 Jul 2004 12:11:35 -0700 > >> >> >Lines: 39 > >> >> >X-Priority: 3 > >> >> >X-MSMail-Priority: Normal > >> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 > >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 > >> >> >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl>
Hi Priyesh
No, there's no reference counting involved on the finalization queue. SuppressFinalize(obj) affects the first reference to obj on the queue, so calling it several times in a row has no added effect, regardless of how many times obj is on the queue. The finalization queue doesn't have a seperate structure, rather a (strong) reference to the object in memory. In the object's header is the "run my finalizer" bit. When suppressis called, the GC scans the queue from the front and and stops at the first reference to obj (when called again, it starts from the front of the queue again). That bit is set in the header of the object obj points to. When reregister is called on obj, another reference to the object is placed at the end of the (FIFO) queue), so Suppress will never reach past the first reference (which is why, as Richter states, you cannot balance out several calls to Rereg with Suppress). The only I can think of to remove all pending finalization requestsis to have a suppress after every call to reregister. Short of that, maybe setting a flag in your finalizer to say your object has already been finalized would remove redundant cleanup, but wouldn't stop the object from being put on the queue. Hope that helps -Chris -------------------- [quoted text, click to view] >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com>
>References: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> <V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl> >Subject: Re: GC SuppressFinalize and ReRegisterForFinalize >Date: Tue, 27 Jul 2004 07:20:18 -0700 >Lines: 126 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 >Message-ID: <uS5cvV#cEHA.244@TK2MSFTNGP12.phx.gbl> >Newsgroups: microsoft.public.dotnet.framework.clr >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net 216.222.33.194 >Path: cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl >Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:11372 >X-Tomcat-NG: microsoft.public.dotnet.framework.clr > >Thanks for your explanation and the points about the correctness of the >article. I understand that this is a theoretical scenario to explain some of >the GC functionality available. > >I was thinking that there is some sort of reference counting mechanism for >the same object in the finalization queue. Since the example operates on a >single object, i got myself into thinking SuppressFinalize call on that >object would affect that one object and would not let any further Finalize >calls. From your explanation, it seems that the finalization queue contains >a separate structure which has a pointer to the object to be finalized. > >When ReRegisterForFinalize is called on an object, is there another memory >structure created in the finalization queue? >If so, how does the SuppressFinalize determine which reference in the queue >to apply the suppress to? (Does it apply to the first reference in queue all >the time?) >Is there a way to get rid of all pending finalization requests? > >I would really appreciate your follow up on these questions. > > > >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message >news:V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl... >> Hi Priyesh >> >> In the article you point to, Jeffrey explains that SuppressFinalize sets a >flag in the object to not run the finalizer. So if you have 3 references to >the same object on the finalization >> queue, the GC will set the bit when it reaches that object on the queue, >then discard it. After that, when the GC reaches the object a second time >onthe queue, the flag gets reset >> "this flag is reset when the runtime determines that it's time to call a >Finalize method", so that's why the finalizer is run twice in the sample you >provided. >> >> That being said, I can't think of a valid scenario when someone would want >to reregister a live object, so I don't expect this scenario cropping up >much in real life. >> >> Also, for what it's worth, that article is pretty outdated, and contains >some inaccurate information. For example, it's not possible to override >Finalize in C#, and it's impossible to >> explicitly call an object's Finalization method. Also, an object's >parent's finalizer is called automatically (check out the IL to see for >yourself). >> >> Hope that helps >> -Chris >> >> >> -------------------- >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> >> >Subject: GC SuppressFinalize and ReRegisterForFinalize >> >Date: Sun, 25 Jul 2004 12:11:35 -0700 >> >Lines: 39 >> >X-Priority: 3 >> >X-MSMail-Priority: Normal >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 >> >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> >> >Newsgroups: microsoft.public.dotnet.framework.clr >> >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net >216.222.33.194 >> >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl >> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11293 >> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr >> > >> >I am having trouble understanding the code below. >> >(From http://msdn.microsoft.com/msdnmag/issues/1100/GCI/ Figure 9) >> > >> >I am looking for an explanation about how the SuppressFinalize calls >work. >> >From reading the documentation, i get the idea that SuppressFinalize >would >> >remove the obj from the finalization table, so wouldnt it remove all the >> >entries for a obj as i am operating on the same object? If it toggles a >flag >> >on the obj, how come finalize gets called two times? >> > >> >void method() { >> > // The MyObj type has a Finalize method defined for it >> > // Creating a MyObj places a reference to obj on the finalization >table. >> > MyObj obj = new MyObj(); >> > >> > // Append another 2 references for obj onto the finalization table. >> > GC.ReRegisterForFinalize(obj); >> > GC.ReRegisterForFinalize(obj); >> > >> > // There are now 3 references to obj on the finalization table. >> > >> > // Have the system ignore the first call to this object's Finalize >> > // method. >> > GC.SuppressFinalize(obj); >> > >> > // Have the system ignore the first call to this object's Finalize >> > // method. >> > GC.SuppressFinalize(obj); // In effect, this line does absolutely >> > // nothing! >> > >> > obj = null; // Remove the strong reference to the object. >> > >> > // Force the GC to collect the object. >> > GC.Collect(); >> > >> > // The first call to obj's Finalize method will be discarded but >> > // two calls to Finalize are still performed. >> >} >> > >> > >> > >> >> >> -- >>
Hi Priyesh
1. Yes, that's right. 2. Yes. SuppressFinalizer sets the "run my finalizer" bit to false, and that reference is removed from the queue, at which point the GC resets the bit to true. Now when the next reference to the same object is encountered on the queue, the object is moved to the f-reachable queue where its finalizer gets run. I think we're on the same page now :) -Chris -------------------- [quoted text, click to view] >
>Hi Chris, >Thanks for the reply. Here is what i understand from your explanation. > >1. The finalization queue will keep on adding references to the same object >to match ReRegisterForFinalize calls on the same object. > >2. SuppressFinalize will set the "run my finalizer bit" in the obj. When GC >reaches a reference >in the finalization queue, it checks this bit and if the bit is not set, >wont move that to the f-reachable. GC would set the bit on the object so >that the object references pending in the finalization queue will be moved >to f-reachable and eventually the Finalize method will be called. > >Please tell me if i understood it right. > >Thanks >Priyesh > >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message >news:J5Cv5a$cEHA.3204@cpmsftngxa10.phx.gbl... >> Hi Priyesh >> >> No, there's no reference counting involved on the finalization queue. >SuppressFinalize(obj) affects the first reference to obj on the queue, so >calling it several times in a row has >> no added effect, regardless of how many times obj is on the queue. >> >> The finalization queue doesn't have a seperate structure, rather a >(strong) reference to the object in memory. In the object's header is the >"run my finalizer" bit. When >> suppressis called, the GC scans the queue from the front and and stops at >the first reference to obj (when called again, it starts from the front of >the queue again). That bit is set >> in the header of the object obj points to. When reregister is called on >obj, another reference to the object is placed at the end of the (FIFO) >queue), so Suppress will never reach >> past the first reference (which is why, as Richter states, you cannot >balance out several calls to Rereg with Suppress). >> >> The only I can think of to remove all pending finalization requestsis to >have a suppress after every call to reregister. Short of that, maybe >setting a flag in your finalizer to say >> your object has already been finalized would remove redundant cleanup, but >wouldn't stop the object from being put on the queue. >> >> Hope that helps >> -Chris >> >> >> -------------------- >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> >> >References: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> ><V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl> >> >Subject: Re: GC SuppressFinalize and ReRegisterForFinalize >> >Date: Tue, 27 Jul 2004 07:20:18 -0700 >> >Lines: 126 >> >X-Priority: 3 >> >X-MSMail-Priority: Normal >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 >> >Message-ID: <uS5cvV#cEHA.244@TK2MSFTNGP12.phx.gbl> >> >Newsgroups: microsoft.public.dotnet.framework.clr >> >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net >216.222.33.194 >> >Path: >cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12 >.phx.gbl >> >Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.clr:11372 >> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr >> > >> >Thanks for your explanation and the points about the correctness of the >> >article. I understand that this is a theoretical scenario to explain some >of >> >the GC functionality available. >> > >> >I was thinking that there is some sort of reference counting mechanism >for >> >the same object in the finalization queue. Since the example operates on >a >> >single object, i got myself into thinking SuppressFinalize call on that >> >object would affect that one object and would not let any further >Finalize >> >calls. From your explanation, it seems that the finalization queue >contains >> >a separate structure which has a pointer to the object to be finalized. >> > >> >When ReRegisterForFinalize is called on an object, is there another >memory >> >structure created in the finalization queue? >> >If so, how does the SuppressFinalize determine which reference in the >queue >> >to apply the suppress to? (Does it apply to the first reference in queue >all >> >the time?) >> >Is there a way to get rid of all pending finalization requests? >> > >> >I would really appreciate your follow up on these questions. >> > >> > >> > >> >""Chris Lyon [MSFT]"" <clyon@online.microsoft.com> wrote in message >> >news:V8GuP12cEHA.1520@cpmsftngxa10.phx.gbl... >> >> Hi Priyesh >> >> >> >> In the article you point to, Jeffrey explains that SuppressFinalize >sets a >> >flag in the object to not run the finalizer. So if you have 3 references >to >> >the same object on the finalization >> >> queue, the GC will set the bit when it reaches that object on the >queue, >> >then discard it. After that, when the GC reaches the object a second >time >> >onthe queue, the flag gets reset >> >> "this flag is reset when the runtime determines that it's time to call >a >> >Finalize method", so that's why the finalizer is run twice in the sample >you >> >provided. >> >> >> >> That being said, I can't think of a valid scenario when someone would >want >> >to reregister a live object, so I don't expect this scenario cropping up >> >much in real life. >> >> >> >> Also, for what it's worth, that article is pretty outdated, and >contains >> >some inaccurate information. For example, it's not possible to override >> >Finalize in C#, and it's impossible to >> >> explicitly call an object's Finalization method. Also, an object's >> >parent's finalizer is called automatically (check out the IL to see for >> >yourself). >> >> >> >> Hope that helps >> >> -Chris >> >> >> >> >> >> -------------------- >> >> >From: "Priyesh" <PriyeshPadmavilasom@cougarmtn.com> >> >> >Subject: GC SuppressFinalize and ReRegisterForFinalize >> >> >Date: Sun, 25 Jul 2004 12:11:35 -0700 >> >> >Lines: 39 >> >> >X-Priority: 3 >> >> >X-MSMail-Priority: Normal >> >> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1437 >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 >> >> >Message-ID: <ONj5JvncEHA.3480@TK2MSFTNGP11.phx.gbl> >> >> >Newsgroups: microsoft.public.dotnet.framework.clr >> >> >NNTP-Posting-Host: wireless-216-222-33-194.boi.velocitus.net >> >216.222.33.194 >> >> >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl >> >> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.clr:11293 >> >> >X-Tomcat-NG: microsoft.public.dotnet.framework.clr >> >> > >> >> >I am having trouble understanding the code below.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |