Why don't reference types go on the stack?

When I was in school I was taught that heap allocation was expensive and stack allocation was cheap.
I was learning C / C++ at the time and that was (and is) true for C / C++.
This is not the case for C#...allocation to the stack and heap is about the same, thanks to the magic sauce of garbage collection.

Check out this 2 part post by Eric Lippert on his blog for an interesting read about what you thought you knew about value and reference types.
http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx

Understanding .NET Delegates

Recently, Jesper and I have been trying to understand the concept of Delegates in C# (or .NET in general). Both of us are learing the Microsoft stack and feel this concept is vital. We've found a few useful resources that have helped explain this concept.

For some high level overview action, check out these MSDN articles:
http://msdn.microsoft.com/en-us/library/17sde2xt.aspx
http://msdn.microsoft.com/en-us/library/9aackb16.aspx

But, then I ran across this article which REALLY helped with my understanding. Big thanks to the author for such a great resource:

http://www.codeproject.com/KB/cs/NETDelegatesAndEvents.aspx

I/O Other and I/O Other Bytes

Have you ever opened up Windows Task Manager and looked at all the nifty columns you can add through the options menu item?

Recently I was forced to do this and we noticed that IO Other and IO Other Bytes were spiking at alarming rates (along with our CPU usage). There are other columns for IO Reads and IO Writes, those are pretty self explanatory (and they weren't moving). But I had no idea what would cause those IO Other and IO Other Bytes columns to even accumulate data so I did some investigating.

Accessing file information like exists, canRead, canWrite, lastModified, directory listing, etc is what causes IO Other to increase. Basically accessing attributes on the file.

Accessing file pointers and seeking to a new location in the file will cause the IO Other Bytes column to increase. Basically "moving over" or maybe "counting" bytes without reading actually reading them.

Depending on which object I was using, getting the length had an effect also. The java class File.length() caused the IO Other to go up, while the java class RandomAccessFile.length() caused the IO Other Bytes to go up.

This was not exhaustive by any means, but it did give me a good idea on what those values mean and why they would accumulate.

Visual VM

Yesterday Visual VM released an updated profiler for Java.

https://visualvm.dev.java.net/download.html

It's pretty awesome. You can sample data from remote applications now which you couldn't do very effectively in the past.

You used to have to run the profiler on the same machine as the application if you wanted method level cpu information (which they now call "sampling"). This was always a sticking point for me. I used the BEA jrockit profiler in the past and you could always get that kind of information from remote applications. Course, I couldn't complain too much since Visual VM IS free :D

But now I get all my eggs in one free basket.

What it now labels "profiler" can still only be run on the same machine as the app being profiled, but I haven't played much with this option. The one time I ran it it seemed to interact with my ecplise IDE where I was running the app from, so that's either really cool or not. I'm definitely planning to play around more with it though.

Above Average Programmers

Here's an interesting article on "Above Average Programmers," a category I happily represent ;)

http://www.lessonsoffailure.com/developers/problem-above-average-programmers/

Unfortunately, I don't do a lot of outside learning. I'm pretty comfortable in my current job and I've got a variety of things at home to keep me busy between wife, kids, and a new house to take care of. (Not to mention WoW and SC2 which comes out in 2 weeks). I also feel that I'm much too busy at work to spend the time reading a lot of blogs or insights into programming in general.

Yet somehow I still happily answer "above average" when asked to rank my skills.

Maybe I'll have to justify it by saying all those 12 year old facebook app devs are bringing down the curve enough that I'm on top, or at least, above average. Whew, I feel better about myself already. Thanks facebook!

stackoverflow.com

This is a quick one! Every developer should have an account at, and participate in, stackoverflow.com. The site is an awesome resource for developers. It's all questions and answers about development. So, if you don't have an account, go make one and get into the mix asap!

Heres my account: Marshall Alsup

Multithreading vs Hyperthreading

I was curious about the difference between multithreading and hyperthreading so I did a little digging. I've linked the article at the end of the post.

When a process forks it creates a copy of itself, in a mulithreading environment this means the thread is duplicated.

When I learned about multithreading in school I learned about temporal multithreading, this is where the processor gives a slice of time to each thread. Only one thread is ever running at any given time but the processor switches between threads so rapidly that it appears that the threads are running concurrently.

There have been some improvements.

There are 3 main ways to do multithreading:

1. coarse-grain (sometimes called block threading)

2. vertical

3. Simultaneous (Intel calls it hyperthreading, Sun calls it coolthreads)

Coarse-grain multithreading runs instructions on a thread until it comes across an instruction that is going to take a long time (like disk I/O for example), when this happens it switches to a different thread while it waits for the high latency task to complete. The disavantage of this type of multithreading is that all of the threads use the same instruction pipleline and when the processor switches to a different thread all of the instructions behind the high latency instruction are flushed.

Vertical threading (VT) and Simultaneous multithreading (SMT) do not suffer from the high cost of switching between threads. The difference between VT and SMT is that in a single CPU cycle a VT processor issues instructions on one thread and an SMT issues instructions on multiple threads.

Obviosly if an application isn't written to handle multiple threads there is little advantage to be gained from running on a multithreaded processor.

JB

link to article

A friend at work is always saying how important it is to unit test. His main argument is that unit testing makes refactoring easier. This is something I've heard before but never really thought about. I have refactored lots of code and written lots of unit tests, but I've never really thought deeply about their relationship with each other. Today I decided it was time to consider this issue. So I did some Googleing. I found the following link which is a short blog post where someone discusses the relationship. This solidified my understanding. So, if you want to start thinking about the link between unit testing and refactoring have a look:

Refactoring and Unit Tests @ artima.com

-Marshall