Teaching an old dog new tricks: GC fun in Whidbey

RE: Teaching an old dog new tricks: GC fun in Whidbey

MartinJ — Sun, 14 Dec 2003 10:41:00 GMT

I would love to see managed code be informed when the GC is about to kick off a collection. Or, some way to determine when memory is starting to run low. That way, I could implement my own form of data caching that can give up references when things get tight. I realize that someone might abuse this ability to make the GC deterministic. But, the benefits could allow for applications that don't become such memory hogs. -MartinJ

RE: Teaching an old dog new tricks: GC fun in Whidbey

Dejan Jelovic — Mon, 15 Dec 2003 00:08:00 GMT

Brad, HandleCollector is a half-assed fix that will simply not fix the issue: 1. GC is asynchrnous and there are plenty of ways to run out of handles before GC has time to free them through finalization. 2. It's expensive, as forces collection along both dimensions (resources and memory) even though only one may be reaching its limits. But you guys are writing a new operating system. Why not dispense with archaic limits? There is no reason for pens, brushes, bitmaps and most other GDI (plus a few User) resources to be limited by anything but the memory they take up. (Fonts are probably an exception.) Also, some resource management patterns need to be built into the framework and checked by FxCop so that scew-ups like the one I described at http://www.jelovic.com/weblog/e119.htm don't happen too often. Dejan

RE: Teaching an old dog new tricks: GC fun in Whidbey

Jeremy Spiller — Sat, 20 Dec 2003 20:23:00 GMT

I think there is a large potential for really messing the system up by mismatching calls to GC.AddMemoryPressure and GC.RemoveMemoryPressure. It would be *very* hard to figure out where the problem is. How about a single member function (maybe you'd have to inherit from some base object): this.SetMemoryPressure(int n) Now the GC knows how much memory the object is using at all times, and there is no chance of a library (someone else's, of course:) messing up the system. In addition, the GC might use the information to call a finalizer earlier than it would otherwise. Maybe the GC could "keep an eye" on huge objects. -Jeremy

re: Teaching an old dog new tricks: GC fun in Whidbey

Justin Rogers — Sun, 21 Mar 2004 02:15:00 GMT

First comment, does .AddMemoryPressure work on a global level (adding more maximum memory consumed), or does it attach this information to the instance in question. I'm assuming you might grab the class instance and assign the new memory pressure value to the class itself under the covers, but I want to make sure.

Does .AddMemoryPressure scale to inheritance situations where a parent object (Bitmap), might set pressure based on the file size and then say a TwoLayerBitmap would get the chance to add additional pressure based on some secondary unmanaged buffers it creates?

Memory pressure can get removed during the Dispose method or during Finalization. I'm assuming that you would need to do a RemoveMemoryPressure during a Dispose/Close operation, but during a Finalize, the GC should assume a RemoveMemoryPressure?

As for the HandleCollector, is there anything this is buying us that we haven't already done ourselves as .NET programmers? Is this just a helper class that handles calling the GC for us? Does it force the GC to only collect specific types of objects? It doesn't appear so based on the code.

The new face of the GC in Whidbey... I'm not sure this is a pretty face...

Justin Rogers, DigiTec Web Consultants, LLC. — Sun, 21 Mar 2004 05:36:00 GMT

Discussion on GC in Whidbey

Brad Abrams — Tue, 23 Mar 2004 08:26:00 GMT

re: Teaching an old dog new tricks: GC fun in Whidbey

mihailik — Tue, 23 Mar 2004 07:35:00 GMT

Now Add/RemoveMemoryPressure don't attach the pressure amount to object instance. I don't know why. This 'agnostic' style really will produce bugs.

What can be done? Just we need is wrapper base class, that will automatically ensure AddPressure/RemovePressure called in right scenario. I think, MS must ship such class in Widbey to prevent our bugs.

Below is my vision. Just automatically Add in ctor and Remove in Dispose.

This code is just simple demo. It need be tuned for locking/threading and for checking Add/Remove pair matches.

public abstract class UnmanagedResource : IDisposable
{
readonly int m_PressureAmount;

public UnmanagedResource(int pressureAmount)
: this( pressureAmount, true )
{ }

public UnmanagedResource(int pressureAmount, bool addPressureNow)
{
this.m_PressureAmount=pressureAmount;
if( addPressureNow )
ResourceAllocated();
}

protected void ResourceAllocated()
{
GC.AddMemoryPressure(PressureAmount);
}

protected void ResourceReleased()
{
GC.RemoveMemoryPressure(PressureAmount);
}

protected int PressureAmount
{
get { return m_PressureAmount; }
}

public void Dispose()
{
Dispose(true);
}

protected virtual void Dispose(bool disposing)
{
ResourceReleased();

if( disposing )
{
GC.SuppressFinalize();
}
}

~UnmanagedResource()
{
Dispose(false);
}
}

re: Teaching an old dog new tricks: GC fun in Whidbey

Yves Reynhout — Tue, 23 Mar 2004 09:20:00 GMT

Not directly related, but has the GC version (srv and wks) been changed for Windows Services? I mean, if there is one place where we really need the server version it's in Windows Services!

[.NET]Teaching an old dog new tricks: GC fun in Whidbey

おがわみつぎのBLOG — Tue, 23 Mar 2004 13:28:00 GMT

[.NET]Teaching an old dog new tricks: GC fun in Whidbey

re: Teaching an old dog new tricks: GC fun in Whidbey

Brad Abrams — Tue, 23 Mar 2004 13:04:00 GMT

Yves, the runtime will choose what GC to load based on the machine we are running on... Multiproc get the server GC for example. You can also customize it on each process via a config file

Items of interest pt6

Andrew Stopford's Weblog — Wed, 24 Mar 2004 10:50:00 GMT

Items of interest pt6

Andrew Stopford's Weblog — Wed, 24 Mar 2004 10:51:00 GMT

re: Teaching an old dog new tricks: GC fun in Whidbey

Flier Lu — Thu, 25 Mar 2004 06:28:00 GMT

Why not use IoC pattern connected the managed object and the unmanaged resource? For example, define an interface IUnmanagedResource, which support GC got the unmanaged resource size with IUnmanagedResource.GetUnmanagedResourceSize function.

public interface IUnmanagedResource
{
uint GetUnmanagedResourceSize();
};

The managed object implement the interface, and register itself to GC UnmanagedResource list with GC.RegisterForUnmanagedResource, like GC Finalizer list.

// GC.RegisterForUnmanagedResource(IUnmanagedResource res)

class Bitmap : IUnmanagedResource
{
private long _size;

uint GetUnmanagedResourceSize()
{
return _size;
}

Bitmap (string path )
{
_size = new FileInfo(path).Length;

GC.RegisterForUnmanagedResource(this);

// other work
}
}
So GC could calculate the unmanaged size, and known which unreachable object has how many unmanaged resource.

re: Teaching an old dog new tricks: GC fun in Whidbey

Robin Maffeo — Thu, 25 Mar 2004 18:27:00 GMT

A minor correction to Brad's comment on wks/svr GC selection... As he mentioned, we added a new config flag in Whidbey and v1.1 SP1 where you can choose which flavor of the collector you want. However, absent any guidance, workstation GC is still the default. The runtime won't automatically select server GC for you since the assumption is an interactive application unless otherwise specified.

re: Teaching an old dog new tricks: GC fun in Whidbey

Antonello Tesoro — Sat, 27 Mar 2004 16:02:00 GMT

Assume we've implemented the Dispose Pattern in our type which holds references to un unmanaged scarce resource.
When the HandleCollector wants to free as much of our unmanaged resource as it can ( because for instance we've reached the minThreshold ) it has no other choices but to perform a "Full Collection" so that the Finlize method of the instances of our type will be called. This carries on the undesired consequences we're all well aware of, such as incorrect Generation promotion of some objetcs, the performance penalty of a full GC collection, the Finalization of objetcs of other types we didn't need to Finalize at this time; all This, just to have the Finalize method of all the live instances of our type to be called!

What is really needed in those cases is something like:

public static void GC.FinalizeType( Type typeToFinalize, bool runSync );

This method should suspend all the threads and walk the managed heap using the very same algorithms the GC already uses in the standard Collection, to find out which instances of our types aren't reachable; and only call the Finalize mthod on those instances without performing a full collection or reclaiming any memory. The second flag asks the method to wait until all those objects have been fully finalized ( this is needed if we really ran out of resources and cannot continue the execution of our program without freing any ).
I Belive this kind of solution will get the same result of the GC.Collect without the side effects and the performance penalties of a full collection.

AddMemoryPressure

Cook Computing — Thu, 18 Nov 2004 11:47:00 GMT

Avnrao's Blog has a post GC on small managed resource holding large unmanaged resources... By default small objects will have a low priority as far as GC is concerned but in Whidbey onwards you can boost this by calling GC.AddMemoryPressure....

Performance Guideline: Use AddMemoryPressure while consuming Unmanaged Objects through COM Interop

J.D. Meier's Blog — Tue, 10 Oct 2006 02:56:55 GMT

Here's the next .NET Framework 2.0 performance guideline for review from Prashant Bansode, Bhavin Raichura,

Performance Guideline: Use HandleCollector API when Managing Expensive Unmanaged Resource Handles

J.D. Meier's Blog — Sat, 14 Oct 2006 01:20:02 GMT

Here's the next .NET Framework 2.0 performance guideline for review from Prashant Bansode, Bhavin Raichura,

Brad Abrams Teaching an old dog new tricks GC fun in Whidbey | work from home

Brad Abrams Teaching an old dog new tricks GC fun in Whidbey | work from home — Tue, 16 Jun 2009 15:13:56 GMT

PingBack from http://workfromhomecareer.info/story.php?id=18132