C#

Luc Pattyn wrote:

You should implement IDisposable if your object is likely to hold large amounts of
(managed) memory that you want to make collectable immediately

ObjectWithHugeArray obj = new ObjectWithHugeArray();
obj.GetSomeData();
obj.DisplayTheData();
GetSomeUserInput();
obj.Dispose();
// the memory is not collectable until here
obj = null;

ObjectWithHugeArray obj = new ObjectWithHugeArray();
obj.GetSomeData();
obj.DisplayTheData();
// the memory is collectable here already
GetSomeUserInput();
obj = null;

Guffa wrote:

ObjectWithHugeArray obj = new ObjectWithHugeArray();
obj.GetSomeData();obj.DisplayTheData();
// the memory is collectable here already
GetSomeUserInput();
obj = null;

Luc Pattyn wrote:

with obj
a class member, not a local variable.

Luc Pattyn wrote:

the "obj=null;" statement would be chopped out
by the optimizer

Luc Pattyn wrote:

I assume you intend the example to be the code of a single method, with obj
a class member, not a local variable.

Luc Pattyn wrote:

Not having an obj.Dispose(); ends the life of the obj value sooner when
looking at the code in the method itself; IMO that on its own is insufficient to
expect the compiler to move "obj=null;" upwards.

Luc Pattyn wrote:

So I expect the obj variable be present on the stack, and be cleared only
after returning from the Input method; hence the GC would find the hugeobject
reference, and would have to keep it alive (together with its huge array, for
which my Dispose() would have removed the only reference).

Guffa wrote:

the object only have to be alive as long as there is a used reference to it. The garbage collector sees where the reference to the object is last used

Luc Pattyn wrote:

You assign magic powers to the GC; it does not understand your program

Luc Pattyn wrote:

it can't
predict whether an existing reference is still needed or not.

Luc Pattyn wrote:

The local ref-type variable is located on the stack (or JIT-optimized into a
register). If it is not null, the object it refers to is alive, even if the
program does not intend to use it any more.

using System;
using System.Collections.Generic;

namespace TestConsole {

	class Program {

		static List<WeakReference> refs; 

		static void Main(string[] args) {
			refs = new List<WeakReference>();
			byte[] ref1, ref2, ref3, ref4, ref5, ref6, ref7, ref8, ref9, ref10;

			ref1 = Create();
			ref2 = Create();
			ref3 = Create();
			ref4 = Create();
			ref5 = Create();
			ref6 = Create();
			ref7 = Create();
			ref8 = Create();
			ref9 = Create();
			ref10 = Create();

			int index = 1;
			foreach (WeakReference r in refs) {
				Console.WriteLine("Item {0} : {1}", index, r.IsAlive);
			}
		}

		static byte[] Create() {
			byte[] r = new byte[100000000];
			refs.Add(new WeakReference(r));
			return r;
		}

	}

}

Luc Pattyn wrote:

Now my problem was: why would the compiler actually generate code to assign
null to it, since there is no further use for it; a regular non-CLR compiler
(say a C compiler) would optimize it away immediately. But it seems the C# compiler
designer has not optimized assignments that far that "obj=null;" would be
removed. (Unfortunately he also did not remove useless val-type assignments,
try ending a method on int a=12; and watch its MSIL).

Guffa wrote:

Almost all optimising is done by the JIT compiler, so you should look at the actual code generated, not the IL code.