Re: Comparison<T, U> to Comparison<T>

On Tue, 03 Mar 2009 15:43:20 -0800, Pavel Minaev <int19h@xxxxxxxxx> wrote:

[...]
Well, it turns out that the damn thing always prints "1 objects
alive", no matter how long you wait after the Collect call, and no
matter how many objects were created! Furthermore, I've printed the
index of that object, and it's always the last object in the array -
again, regardless of the size of the array.

Does anyone has any idea of what is going on here?

Sure. You're losing your mind. :)

Actually, I'm just kidding. As near as I can tell, the issue is that when you assign into the object[] as part of the argument to the WeakReference constructor, the compiler generates a hidden local variable. This local variable continutes to refer to the most recent object instantiated, preventing it from being collected.

You can see the generated local if you inspect the IL for your sample.

The really weird parts:

-- The compiler still generates this intermediate variable even for a "Release" build. I didn't play with the various compiler switches, but I would have thought that even the default "Release" config would suppress that. Seems like someone's relying a little too much on the JITter. :)

-- Speaking of the JITter, I'm very surprised that even the JIT-ted code doesn't mark the variable as unreachable past its last use. Considering that the fact that this optimization exists, and is the very reason for having GC.KeepAlive(), I'm a bit amazed that not having GC.KeepAlive() on the hidden local variable doesn't result in the local variable's reference being collected in spite of the variable's presence.

But, anyway...if you change the code so that you assign to your "srs" array element first, and then just use that element in the constructor for your WeakReference, everything works just as you think it should.

As for whether the code example sheds any light on the question of GC.Collect() being synchronous or not, I'd suggest it does show the method is synchronous. But, absent a more invasive inspection of the execution of the code (one showing exactly when each instruction in each thread of the process is executed), I'd admit that even your code example isn't proof of that.

Pete
.

Relevant Pages

  • Re: Error *cannot return a value from method whose result type is void*
    ... > trying to do is have it output a calendar. ... compiler spots the mismatch and complains. ... the execution takes through the method. ... the compiler can then see that no matter how the isLeapYear ...
    (comp.lang.java.programmer)
  • Re: VS .NET 2003 hangs while "Generating Code..."
    ... The CArray is hit only once to get information in the execution of the ... it certainly smells like a serious compiler bug. ... > elements do you put them in an array, and you know how many elements you ... >>builds fine and release with no optimizations builds fine. ...
    (microsoft.public.vc.mfc)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)
  • Re: Windows array allocation problem
    ... array reference has to have a 64-bit index or array subscript triplet? ... to fit in one. ... That assumes, of course, that your compiler ... limits on just about anything. ...
    (comp.lang.fortran)
Loading