Adam Furmanek
I am Adam Furmanek and I have been working as a .NET developer for 5 years. Right now I am at Amazon working with Scala, Spark and Machine Learning. I am always interested in digging deeper, exploring machine code and going through implementation details to better understand internals of the technologies I use every day. That’s why I like debugging, decompiling and disassembling the code to understand memory models, concurrency problems and other details hidden deeply inside. In my free time I play ping-pong, watch Woody Allen’s movies and blog stuff at http://blog.adamfurmanek.pl.
Manual Memory Management in .NET Framework
We are used to having safe references and not bother with memory leaks. CLR or JVM take care of allocating objects and verifying that we do not do illegal instructions. Worst thing we can have is just an exception which usually we can catch and handle. But what if we want to take care of lower mechanisms? Do we need to use C++ or can we stick to our favorite language and trick the platform to execute any code we wish?
Since we can allocate memory and our machines usually don’t differentiate between code and data, we just need to modify few pointers to execute any code we like and allocate objects wherever we want. We can do it in C# or Java, and most likely in different languages as well. At the end it is just a bunch of bytes we run and modify.
And when it comes to C# details, during the session I will show how to allocate memory directly by hand using TypedReferences. We will see that it is possible to allocate reference type on a stack, how to hack new keyword provided by the platform to use different allocator, and how to execute any machine code using pure C#. We will examine memory dumps with WinDBG, emit IL code dynamically, and generate machine code for x86 directly in runtime.
Async Internals in .NET
In this talk I show some internals of exceptions. Examples are based on typical use cases and common mistakes. I show why calling async methods synchronously might be a bad idea, how to catch out of band exceptions or how to implement synchronization mechanisms to wait for async void. We know that we should have “async all the way” but very often we are forced to have some trickery because of frameworks we use.
I am Adam Furmanek and I have been working as a .NET developer for 5 years. Right now I am at Amazon working with Scala, Spark and Machine Learning. I am always interested in digging deeper, exploring machine code and going through implementation details to better understand internals of the technologies I use every day. That’s why I like debugging, decompiling and disassembling the code to understand memory models, concurrency problems and other details hidden deeply inside. In my free time I play ping-pong, watch Woody Allen’s movies and blog stuff at http://blog.adamfurmanek.pl.
Manual Memory Management in .NET Framework
We are used to having safe references and not bother with memory leaks. CLR or JVM take care of allocating objects and verifying that we do not do illegal instructions. Worst thing we can have is just an exception which usually we can catch and handle. But what if we want to take care of lower mechanisms? Do we need to use C++ or can we stick to our favorite language and trick the platform to execute any code we wish?
Since we can allocate memory and our machines usually don’t differentiate between code and data, we just need to modify few pointers to execute any code we like and allocate objects wherever we want. We can do it in C# or Java, and most likely in different languages as well. At the end it is just a bunch of bytes we run and modify.
And when it comes to C# details, during the session I will show how to allocate memory directly by hand using TypedReferences. We will see that it is possible to allocate reference type on a stack, how to hack new keyword provided by the platform to use different allocator, and how to execute any machine code using pure C#. We will examine memory dumps with WinDBG, emit IL code dynamically, and generate machine code for x86 directly in runtime.
Async Internals in .NET
In this talk I show some internals of exceptions. Examples are based on typical use cases and common mistakes. I show why calling async methods synchronously might be a bad idea, how to catch out of band exceptions or how to implement synchronization mechanisms to wait for async void. We know that we should have “async all the way” but very often we are forced to have some trickery because of frameworks we use.