Category: .Net Stuff

Looking through the slides for this presentation.  I found a few things interesting.

‘Server GC’ in .Net 4.5 now supports background garbage collection, so it is now more useful for desktop apps as well as pure-throughput apps.  It also supports better distributing the mark phase of mark-sweep across multiple cores allowing garbage collection to scale better.

Profile guided optimization can now be done with managed code, and the resultant information annotated into IL for improved startup-time and reduced memory usage.  Apparently.

On Windows 8 only, .Net 4.5 will ‘auto-NGen’.  No need to think about whether you should NGen or not, its all automatically done in the background based on observed assembly usage.

And finally quite possibly my favourite.  Profiler hooks can now rewrite methods and request a rejit.  So you can inject instrumentation to methods which have already been jitted, or disable instrumentation without a process re-start.

WinRT, so much new and interesting… so much old and broken?  I’ve read a few articles now, watched a couple of talk recordings – nothing great and in-depth but I think I’ve picked up a few details.

WinRT is effectively the combination of ‘COM done better’ and ‘OS API done using the result’.

On the COM done better side we get, nicer integration into more languages.  Along with that is a metadata format which is shipped with the code.  Metadata which includes versioning information to try and avoid some of the COM interface versioning hell.  You get better runtime reflection – every WinRT type can tell you what interfaces it implements and provide some kind of name.  Apparently there is type inheritance (although apparently only the WinRT core is allowed to use it…), and generics and better handling of events and asynchronous callbacks.  A new better type of string, simple structs and collection types built into the core that everyone can consistently use as part of their own APIs.  Each app apparently even has its own COM(I mean WinRT) registry, so no conflict issues.

OS API done using the result gives opportunities to do things the way they should be done.  It also allows for namespacing and componentization, which when mixed with the metadata mean much improved discoverability and general developer experience.  No need to call clean-up methods, because they are automatically called when the associated type is released…

Which brings us to the ‘old and broken’ part of this story.  WinRT shows its COM roots, everything is IUnknown, the same IUnknown from COM.  This means AddRef and Release.  The real bonus here however is that this is all hidden away from c#/VB/javascript and even c++ if you use the c++/cx extension approach to dealing with WinRT.  I say bonus somewhat dubiously as fully-automatic reference counting results in fully-automatic memory leaks.

Take for example the PropertySet in WinRT.  Using this from c# in VS11 the only vaguely apparent suggestion that this isn’t a .Net type is its namespace.  I can easily see developers thinking that this was a replacement for StringDictionary (which has conveniently been removed from the .Net 4.5 core runtime).  But you will see the difference if you create a circle of references between PropertySets.  You have to manually break the circle or the PropertySet memory will never be released!

As a bonus to this post, I’ll end by mentioning that WinRT apparently does not support exceptions!  This may seem strange to anyone who has used it, since calling WinRT APIs certainly throws exceptions, but this is entirely language integration, under the hood an error is limited to a 32bit integer – a HRESULT.  This means WinRT components cannot provide useful error details directly through their APIs without mangling those APIs to provide a bunch of output parameters that are normally never used.

I was watching one of the WinRT talks where they decided to describe a ‘feature’ that if an error occurs in the WinRT core libraries, it can directly tell the attached debugger additional details, since they cannot be returned to the calling code! (One can only hope that they provide a way for custom written components to do this too, it is going to be bad enough that when ComponentArt 19 for Metro comes out every error returned to your code is ‘COMException’ at runtime, not being able to find out useful details while debugging would be a nightmare.)  Almost makes one wish for the return of GetLastError…

So I went through the 17meg file looking for the changes I found most interesting.  So here they are… in no particular order.

• SQL Server connection string now supports an option called ‘application intention’ – lets you specify whether you intend on performing any modifications.  All the documentation I could find on this topic talks about primary/secondary replicas and denying access to secondary replicas if the intention isn’t read-only – but it seems like a great opportunity for a simple approach to reducing attack-surface.
• MethodImpl attribute has gained a new option ‘AggressiveInlining’ – documentation says the method will be inlined if possible.
• New assembly mode Preferred32bit – documentation seems to suggest that this is the new Require32bit, only it won’t break when Microsoft releases an OS with no WOW64 mode… or maybe that if you invoke it from a 64bit context it will still load…
• Reflection.TypeInfo – this is a bit of a strange one.  In .Net 4.5 Core, it is practically ‘the’ place to go to get all your type reflection information needs, it has most of the APIs they removed from Type, and some simpler methods and properties for working via reflection.  In .Net 4.5 Full, it still has those simpler methods/properties, but all the APIs are still back on Type instead.
• Regular expressions now have an option for ‘match timeout’ to stop runaway regular expressions with infinite recursive backtracking or similar.
• Threading.Tasks.DataFlow – a higher-level approach to defining how threads send data to each other, rather than writing your own queue or thread-pool.  Apparently it has been released as a CTP before and is based off of an existing part of the c++ TPL.
• Threading.Volatile.Read/Write – Documentation here is that this provides volatile semantics to visual basic, but apparently also for array elements in c#.  I think there might be some use for it in crazy corner cases to implement ‘partial’ volatile as well to improve performance.
• WeakReference<T> – typed weak references.  Does not support trying to take a reference to a struct (oddly enough)!  But it does provide a combined test and retrieve method to avoid calling IsAlive only to receive nothing from GetValue.
• Windows.Shell.WindowChrome – WPF gets access to custom Aero UI features.  Now I too can create really annoying glass windows…
• Runtime.ProfileOptimization.StartProfile – this could be my new favourite.  Putting this at the start of application causes method JITs to be recorded, and if the application has been run more than once, it also causes a background thread to spin up and JIT methods from the previous recording, speeding up the application start-up so long as the application behaviour is relatively predictable.
• IReadOnlyList – a read only interface for List<T> (but not IList<T>…).  This interface is covariant so it can be cast, but it also cannot have the Contains or IndexOf methods. (The CopyTo method is missing for no apparent reason, except that maybe it might as well be an extension method.)
• IReadOnlyDictionary – a read only interface for Dictionary<TKey, TValue> (but not IDictionary<TKey,TValue>).  This interface is not covariant or contravariant in any way, despite only ever taking the key as an input parameter and the value as an output parameter.  I wonder if that is an oversight.  There is also an IDictionary wrapper which presents this interface – presumably to ensure someone doesn’t just cast away your read-only-ness.
• CultureInfo.DefaultThreadCurrentCulture – appears you can change which culture new threads get given – very nice in some areas I can imagine.
• Zip file support through Compression.ZipArchive, and supposedly gzip compression which is significantly improved.
• IProgress<T> – little interface with just one method Report(T progress). Progress<T>, a default implementation which raises an event which report is called. Odd little thing, not sure what it is doing…
• New interop types – IInspectable and HString.  These are apparently windows runtime types…
• Monitor.IsEntered – just in case you forgot? (Guess threading code can get complicated at times…)
• Threading.Timeout.InfiniteTimeSpan – finally, no more converting -1ms and hoping it works?
• Improved virtualization support in WPF. (Pixel level scrolling and pre-post caching.) (Much more interesting than the ribbon!)
• Async support is everywhere… not just streams/web requests/dns queries/database access – it is also in xml parsing (presumably to support the scenario where the underlying stream is a file).

Edit: watching some talks I discover that something that didn’t seem interesting at the time actually is.  ThreadLocal<T> had an IEnumerable<T> GetValues method added to it.  This actually lets you see all of the values currently allocated across all threads.  Not sure how often I’ll use it, but it is cool.

So I, like apparently many others, downloaded the windows 8 developer preview.

Plenty of interesting stuff under the hood, but I decided to jump into .Net 4.5.  In the dev preview there is a VS 11 Express edition, for Metro apps. I quickly discovered that .Net 4.5 ‘Core’ Edition, which is what you can use in Metro, is quite a bit different. (How many hours did I spend trying to write the word hello to a file…)

So I decided to do a version comparison. Enter RuntimeVersionCompare.html.  Note this is a 17MB html document, so it may take a little while to download – and I may have to find somewhere else to host it if it becomes popular…

There are 4 colours used.  Red means ‘Only in .Net 4’, Green means ‘Only in .Net 4.5’, Yellow means ‘Missing from .Net 4.5 Core’ and white is whatever else is left over.  With 5 flags (since I included the client profiles), there are potentially 31 scenarios for colouring, but I was lazy.  Each entry does contain numbers mapping to which version contains the specific API, so if you don’t like the colours as they stand, a simple re-parse and output should fix that.  (You could even risk it and try and do such a change using regular expressions…)

You will see a lot of yellow – in part this is because of the absence of WinRT API in the output which Metro can use in addition to .Net 4.5 Core.  WinRT API is missing mostly because it is described using winmd files, which I haven’t yet attempted to reverse-engineer. (Hopefully they are actually .Net metadata-only dll files in disguise and ildasm will process them just fine…)

Also note that this analysis was all done using custom code which parses the output of IlDasm – as such it almost certainly contains errors, strange syntax in the output and many other flaws (not the least of which is that I didn’t use good CSS style in my output HTML).

Feel free to do whatever you like with this document, although attribution would be nice, and please try to avoid downloading it more than once…

A simple pattern I have implemented myself, seen in many places and often results in problems is the following.

We need a buffer to hold some data before we process it, so we allocate an array large enough to hold the data.  To avoid continual garbage we keep this array and reuse it.  If the data we need to buffer is too large, we throw away the current buffer and make a new larger one.  We might even go fancy and ensure that the new buffer is greater in size than the current one by a minimum percentage margin, to ensure we don’t suffer from mass garbage from a 1,2,3,4,5,6 attack.

Where the problem comes in is the spike.  A single extraordinarily large piece of data is sent.  In response we successfully allocate a huge buffer, maybe taking up almost half of the entire available memory space.  Because of our design we never let this go.  Now if we are multi-threaded and have multiple processing queues each with their own buffer, a well crafted scenario will take up almost all available memory just with these buffers, until rather than failing due to an OOM exception somewhere we can catch it, the runtime itself throws OOM and kills the process.

Solution? Well we could simply outlaw all large data sets, but if you have multiple processing queues the threshold you have to place can be very low, to the point where normal processing is no longer feasible.  Another idea is a bit of a compromise, have a high maximum, and a lower ‘spike threshold’.  Any data set over the spike threshold is considered an anomaly and the buffer is not kept for reuse.

A bit more complicated is the reverse extension of the minimum margin of growth.  If more than ‘k’ buffer uses in a row are less than the current size reduced by a percentage ‘p’, throw the current buffer away and use a smaller buffer.  Question in my mind here is whether k is a constant, or a number which decreases as the buffer gets larger.  I think probably the later results in best behaviour, but some theoretical analysis for random and worst case scenarios would be in order.

And the reason I brought this topic up at all?  System.Data.SqlClient.  Large string values to or from the database are internally handled using a buffer of doom.  There is one buffer per database connection.  You have to be careful with large data or you end up allocating almost all available memory to database connection buffers…

I think this is a bit of an interesting combination – SuppressFinalize works on a specific object telling the garbage collector not to call the finalize method and context bound object means that references to that object are remoting proxies, so there are technically multiple objects which could be the one that the runtime calls finalize on.

Edit: Turns out I made a mistake in my original analysis (rather of silly of me, running different pieces of code on the different versions of .Net runtime), apparently GC.SuppressFinalize has never worked in a way which is useful with ContextBoundObject.  However the Windows 7 SP1 change now means that the finalizer is called via the proxy, not magically directly on the underlying object.  So if you had code for intercepting calls via the proxy and it didn’t handle the finalizer (because previously it didn’t have to), you have a new code path to which could go horribly wrong…

When I first heard about this attribute I was excited, the refactoring potential was great!

Then I read a bit more and was disappointed to see that while you could forward types, they had to maintain their full type name, including namespace, only the assembly could change.  This was disappointing but acceptable.

Today I discover that you can’t move types to assemblies you don’t reference.  This is because the TypeForwardedTo attribute takes a Type, not a string containing a type name.  There is no way to define a type which resolves at compile time without referencing the containing assembly.  This was a bit surprising to me since the metadata for a custom attribute which has a parameter of type Type, stores the fully qualified type name, not a reference qualified type name, so you don’t need a reference in order to create the required metadata.  In fact based on similarities in description I suspect the runtime basically calls the exact equivalent of Type.GetType(string) passing the deserialised metadata directly, during assembly load.  The reason I know that it doesn’t use a reference qualified type name is because I have many times in the past disassembled an assembly changed the versions of its references and reassembled it.  This usually works quite well, but it doesn’t fix custom attributes, which can occasionally cause problems.

For now I think a work around of referencing a pre-compiled version of the assembly using an alias (to avoid accidental use of that assembly by developers outside of the declaration of the TypeForwardedTo attributes) is going to have to suffice, but I just wanted to post that I think that c# syntax is lacking in the declaration of type based attributes.  While I suspect it would be an unusual case, I think that Type.GetType(string) should be considered a compile time constant for attribute parameters, or some other nicer syntax which does the same thing.

So I’m a couple of weeks behind the times but the final silverlight 4 tools were released, so it was time to give it a spin.

The result is http://www.themissingdocs.net/LoopDeLoop.html

Its a cut-down version of my win forms LoopDeLoop, but it also has a couple of features the old one didn’t – like click-drag to apply changes to multiple locations, and proper fix position support (ctrl-F/ctrl-R/ctrl-U).

Silverlight 4 is noticeably better than Silverlight 2, but the errors on the designer when your custom controls fail in design mode, are a bit cryptic.  It also took me a while to work out my ellipses were not showing because I hadn’t measured them during the measure phase.

I haven’t made any serious changes to my actual game engine, other than having to replace SortedDictionary with something else. (I reimplemented my approximatepointset using a dictionary an equality comparer which used fmod to round values, not quite as correct but it seems to still work well enough.)

It was interesting to see that attempting to manually capture a stacktrace (which happens just fine when you throw an exception) throws a security exception.  Also Debug.WriteLine caused me some grief, had to remove those.
Also it might be my imagination, but it seems like the silverlight runtime is noticeably slower than the normal .Net runtime.  And the fact that ctrl-f5 on a page containing a silverlight object doesn’t cause cache-invalidation of the silverlight object itself is quite annoying.

Was investigating a bug today and found some very peculiar behaviour in the 64bit .Net runtime.

Lets say we have a thread running the following loop.

while (true)
{
 try
 {
  Thread.Sleep(10000);
 }
 catch
 {
 }
 try
 {
 }
 catch
 {
 }
}

Okay so that code is not something you would write, I’ve reduced it down to the bare essentials to demonstrate the problem.

If you throw a thread abort at this thread (for whatever reason…) most likely that is going to land in the sleep statement.  Thread will be woken up and the catch block invoked, then at the end of the catch thread abort rethrown and the thread will exit … right?  Not on 64bit runtime.  On 64bit runtime with some strategic debugging you can see that the thread abort does not get rethrown (something to do with the second try catch block… since if you take it away it works), not until the while loop has gone round and you hit the sleep statement.  The net result is a tight loop continually throwing ThreadAbortException.  If you put some code in the try section of the second try catch, that will often cause ThreadAbort to get rethrown and the loop terminates.  Unless the code is in a finally block or is somehow otherwise not suitable for thread abort raising, in which case it won’t raise ThreadAbort and the loop continues.  The second try catch block can be a try finally instead and it still loops forever.

Final trick, if you step through in the debugger rather than letting the code run, it behaves correctly!

All in all a strange bug, it affects both the .Net 2 and .Net 4 runtimes, although i’ve only checked the most recent releases of both on windows 7/2k8r2 environments.

Its out… I’ll write more here later but…
Complex numbers!
StringBuilder.Clear!
Guid.TryParse!
And they finally realized their mistake… ISet 😛