Secrets of WPF Memory Allocation

The way WPF manages memory is a bit of a mystery. It all appears to be nicely garbage collected and everything, but I know there are unmanaged resources under there. How does it know when to garbage collect them?

This is especially important for my application, since I have to manage MANY photos on the screen at once. I’m pretty comfortable with the Dispose() idiom – I kind of like knowing where the memory is going when I’m using such large chunks. But with WPF it’s been a mystery.

Enter: .Net Reflector! Not that I would use such a thing. But supposing I did. (Incidentally, I think I owe Lutz Roeder several beers because of this program)

For those that don’t know, there’s a native code library called ‘milcore’ that WPF is built upon. It has a number of handle types. These are wrapped in .NET by subclasses of SafeMILHandle. This is where things become clear – each of these handle wrappers manually puts pressure on the garbage collector according to the estimated size of the object in question. It uses something called MemoryPresssure.Add() to do this.

Which, it turns out, is not actually a way to influence the garbage collector. It’s in PresentationCore.dll: MS.Internal.MemoryPressure. It uses a funny time/size based heuristic to manually call GC.Collect, which we all know and love. So, depending on what you’re doing with MIL Handles and how you’re doing it, WPF will force garbage collection when it feels like it.

Now, I don’t know a whole lot about garbage collectors, but… how can this possibly work? It seems fine in simple cases (allocate a whole ton of memory, null out your references, repeat). But doesn’t it break the useful heuristics that makes gc perform well? For the case of bitmaps especially, it seems that it’s important for GC to know that these are large objects that should be released as soon as possible. More bang for the buck there. (The large object heap comes to mind, but I think that’s to prevent heap fragmentation)

It’s interesting to observe that the base SafeHandle class *does* implement IDisposable. But the MIL handles themselves aren’t publicly accessible, so they can’t be directly used. But an adventurous/insane person might use reflection to pull the MIL Handle out, replace it with null at the source, type it as an IDisposable, and dispose it manually. I may resort to such measures if this memory pressure thing turns out to be as fishy as it smells.

Android SDK: First Impressions

I’ve spent the evening going through some of the tutorials for the newly released Android SDK.  I won’t beat around the bush about my motivaion: I want money!  I’ve spent about two hours playing with it so far.   

My impressions so far are mixed.  The packaging is fairly nice – the eclipse plugin integrates things together well, including debugging in the emulator.  It’s a little rough around the edges but quite usable.   

I’m not altogether impressed with the code itself so far.  The xml layouts are quite verbose – I think I’ve written ‘android:layout_height=”wrap_content”‘ about 10 times in the past hour.  (Why did they choose such a long default namespace prefix for all the examples?  I’m using ‘a’. )   There’s nothing particularly novel about the way these are done.  Perhaps it’s the ‘it works on a phone’ part that’s cool?  Having never developed for these things, I don’t know.  /me is spoiled, undoubtedly.   

I also don’t yet understand why there are constants being used for so many things.  This code has serious public-static-final-int-itis.  Doesn’t java have strongly typed enums?  My java friends says that yes, it does, as of 1.5.  Perhaps this is based on an older compiler?  The attributes in the examples tell me otherwise.   

I do like the resource mechanism, as I currently see it.  Being able to access resources from the code in a strongly-typed way is a big win. (ala ResXCodeFileGen)  It feels like it’ll make for a good localization mechanism as well.  I would like to see better ide integration for this kind of thing.  Imagine thinking: “I need a new string resource for this”, hitting the hot key, filling out a little form, and having the string added with the key you specified and the reference already in place.   

This is all, of course, FWIW.  I’m sure my opinions will change as I learn more.  

Aggregation + Composition = Headache

I hereby banish the words ‘aggregation’ and ‘composition’ from all of software.

Am I allowed to do that?

Think about it. The last time you drew a UML diagram, did you use hollow diamonds or filled-in diamonds? If you used both, did anybody know what you meant? I’ll bet the answer is no. And if you used those words in conversation, there was probably a 10-minute discussion about what their meaning. This discussion happens EVERY time.

There’s a good reason for this – the distinction of aggregation vs. composition simply is not useful enough to stick in people’s brains. Some feel the need to use it because it’s part of the modeling tool they spent so much money on. Others like it because it makes them look smart.  But it’s not worth it. (nor is the modeling tool, IMHO)

So join the movement! Run sed -e ‘s/(aggregation|composition)/association/g’ over all your documentation and emails! Get rid of those stupid diamonds and use arrows instead! Spend your time thinking about the problem you’re trying to solve instead of explaining useless concepts.