1

Topic: Strangeness with GC.Collect after the last auto-update.Net

All greetings! After  the last update in Windows (in which was also updates for.Net) the test fell off. After simplification the following code which is had began to work on another... static void Main (string [] args) {var obj1 = new object (); var wr = new WeakReference (obj1); Console. WriteLine (wr. IsAlive); obj1 = null; GC.Collect (); Console. WriteLine (wr. IsAlive); Console. ReadKey ();} one week ago True False that has been expected and is true. Became True True WTF??? ps in  the project costs Target framework =. Net 4 and the assembly debug, at release to the assembly , but at  too should be !?

2

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: MH> All greetings! MH> after  the last update in Windows (in which was also updates for.Net) the test fell off. MH> after simplification the following code which is had began to work on another... MH> MH> static void Main (string [] args) {MH> var obj1 = new object (); MH> var wr = new WeakReference (obj1); MH> Console. WriteLine (wr. IsAlive); MH> obj1 = null; MH> GC.Collect (); MH> Console. WriteLine (wr. IsAlive); MH> Console. ReadKey (); MH>} MH> Yes, after setting.net 4.7.2 on Win7 the behavior changed. Became as at you that is strange and it is not good.

3

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: MH> ps in  the project costs Target framework =. Net 4 and the assembly debug, at release to the assembly , but at  too should be !? It is said that the behavior changed in it : https://github.com/dotnet/coreclr/pull/9231 In most  it was necessary because of it tests : https://github.com/dotnet/corefx/pull/16595

4

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, nikov, you wrote: N> It is said that the behavior changed in it : https://github.com/dotnet/coreclr/pull/9231 N> In most  it was necessary because of it tests : https://github.com/dotnet/corefx/pull/16595 Thanks for links! Esteemed everything, but did not understand what exactly changed? That is why GC.Collect did not pick up object on which already precisely there are no links? Someone continues to hold the link? But who? I looked a generated IL-code -  there like all is expected, object creation, then assignment null. The garbage collector began somehow to another to work? But how? After all the specification of method GC.Collect - garbage collection in all generations. If you understood in what business, I will be grateful if educate

5

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: MH> Thanks for links! Esteemed everything, but did not understand what exactly changed? That is why GC.Collect did not pick up object on which already precisely there are no links? Debug-assemblage +  + changes in logician JIT.

6

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: MH> WTF??? Formally it does not contradict the standard. To forgive and correct the test.

7

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, m2l, you wrote: m2l> it is formal does not contradict the standard. To forgive and correct the test. I see the following contradiction - object references more are not present, G.Collect collects all garbage in all generations (according to the documentation). That is our object there was garbage, but  declared behavior G.Collect, it has not been collected. That is the behavior contradicts declared behavior G.Collect

8

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: MH> I see the following contradiction - object references more are not present, G.Collect collects all garbage in all generations (according to the documentation). Nope. At disconnected  JIT can not  with lifetime tracking and to hold object in gc roots up to the method end. Together with  surprises For check turn out: static void Main (string [] args) {var wr = TestWr (); GC.Collect (); Console. WriteLine (wr. IsAlive); Console. ReadKey ();} [MethodImpl (MethodImplOptions. NoInlining)] private static WeakReference TestWr () {var obj1 = new object (); var wr = new WeakReference (obj1); Console. WriteLine (wr. IsAlive); GC.KeepAlive (obj1); return wr;}

9

Re: Strangeness with GC.Collect after the last auto-update.Net

Hello, MadHuman, you wrote: m2l>> it is formal does not contradict the standard. To forgive and correct the test. MH> I see the following contradiction - object references more are not present, G.Collect collects all garbage in all generations (according to the documentation). MH> that is our object there was garbage, but  declared behavior G.Collect, it has not been collected. MH> that is the behavior contradicts declared behavior G.Collect Your example a bit incorrect without WaitForPendingFinalizers - as a variant, at multi-threaded garbage collection GC could place object in queue for removal of other flow, and there had not time to cause Finalize to your the second IsAlive. If to approach to method Collect it is very formal - you do not have "open" warranties between language, IL, JIT, CLR. For example to an output from area of visibility JIT can clamp the link or GC to consider that it is "almost root object or still something similar. GC.Collect Guarantees check of all objects and collection leaked, and the assembly from them, only on whom there are no links. But, note, not the assembly of all objects on which there are no links. And not the assembly of all objects quitted area of visibility of contexts of execution of a source language of programming. And still described by you an example something very much bears a faint resemblance to a specification example. Ecma-334 8.9 Automatic memory management, the last piece of the code and an explanation under it of availability of an object reference after GC. Probably at you similar effects?