C# - Is it possible to pool boxes?

Question

Boxing converts a value type to an object type. Or as MSDN puts it, boxing is an "operation to wrap the struct inside a reference type object on the managed heap."

But if you try to drill into that by looking at the IL code, you only see the magic word "box."

Speculating, I guess that the runtime has some sort of generics-based secret class up its sleeve, like Box<T> with a public T Value property, and boxing an int would look like:

int i = 5;
Box<int> box = new Box<int>;
box.Value = 5;

Unboxing the int would be far cheaper: return box.Value;

Unfortunately, my performance-hungry server application does a fair bit of boxing, specifically of decimals. Worse, these boxes are short-lived, which makes me suspect I pay twice, once for instanciating the box and then again for garbage collecting the box after I'm done with it.

If I was alloacting this memory myself, I would consider the use of an object pool here. But since the actual object creation is hidden behind a magic word in the IL, what are my options?

My specific questions:

• Is there an existing mechanism for inducing the runtime to take boxes from a pool rather than instanciating them?
• What is the type of the instance created during boxing? Is it possible to manually take control of the boxing process, yet still be compatible with unboxing?

If that last question seems strange, what I mean is that I could create my own Box<T> or DecimalBox class, pool it, and box/unbox manually. But I don't want to have to go and modify the various places in the code that consume the boxed value (aka unbox it).

Answer 1

Speculating, I guess that the runtime has some sort of generics-based secret class up its sleeve

Your speculation is almost right. Logically you can think of a box as being a magical Box<T> type that behaves as you describe (with a few more bits of magic; for instance, the way that nullable value types box is a bit unusual.) As an actual implementation detail, the runtime does not do it with generic types. Boxing existed in CLR v1, which was before generic types were added to the type system.

my performance-hungry server application does a fair bit of boxing, specifically of decimals.

If it hurts when you do that then stop doing that. Rather than trying to make boxing cheaper, stop doing it in the first place. Why are you boxing a decimal?

Worse, these boxes are short-lived, which makes me suspect I pay twice, once for instanciating the box and then again for garbage collecting the box after I'm done with it.

Short-lived is better than long lived; with short-lived heap objects you pay to collect them once and then they're dead. With long-lived heap objects you pay that cost over and over again as the object continues to survive.

Of course, the cost you are probably worried about regarding short-lived objects is not the cost of collection per se. Rather, it is the collection pressure; more short-lived objects allocated equals more frequent garbage collections.

The allocation cost is pretty minimal. Move a pointer on the GC heap, copy the decimal into that location, done.

If I was alloacting this memory myself, I would consider the use of an object pool here.

Right; you pay the cost of collecting the long-lived object more, but you do fewer collections total because less collection pressure is produced. That can be a win.

Is there an existing mechanism for inducing the runtime to take boxes from a pool rather than instanciating them?

Nope.

What is the type of the instance created during boxing? Is it possible to manually take control of the boxing process, yet still be compatible with unboxing?

The type of the box is the type of the thing being boxed. Just ask it by calling GetType; it'll tell you. Boxes are magical; they are the type of the thing that they contain.

Like I said before, rather than trying to make boxing cheaper, just don't do it in the first place.

Answer 2

The runtime does pretty much what you describe, however generics is not involved, as generics was not part of the original framework.

There isn't much that you can do about boxing, if you are using some code that expects boxed values. You could create an object that uses the same syntax to return a value by overriding implicit conversion, but that would still need to be an object, and you would basically do the same amount of work anyway.

Trying to pool boxed values will most likely degrade the performance rather than increasing it. The garbage collector is specially made to handle short lived objects efficiently, and if you put the objects in a pool they will be long lived objects instead. When objects survive a garbage collection, they will be moved to the next heap, which involves copying the object from one place in memory to another. So, by pooling the object you may actually cause a lot more work for the garbage collector instead of less.