Modify c# language to optimize boxing of boolean values

[tkreindler]

This issue has been brought up many times in the past in the runtime and in Roslyn:
dotnet/roslyn#39314
dotnet/runtime#7079

The key issue that it keeps coming back to is that the current behavior of boxing small values (mostly bool) is extremely ineffective both for allocations/GC churn and for CPU/latency.

Years ago in Exchange/Substrate it was discovered that the action of boxing bools was contributing 2-5% of allocations in various processes, with some as high as 5% like Exchange Web Services. This led to higher GC churn and higher COGs overall. To counter this we now use a BoxedConstants class in our code wherever possible - and would suggest other services do similar.

In a micro benchmark the results are quite evident:

Method	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
Regular	431.31 ms	8.089 ms	7.566 ms	10000.0000	9000.0000	1000.0000	240000736 B
BoxedConstant	87.50 ms	1.395 ms	1.606 ms	-	-	-	384 B

Micro benchmarks aren't everything but combining the dump investigation from a few years ago and this micro benchmark in .Net 7 makes it pretty clear that this is still an issue.

All of the other posts were closed because it would involve the runtime going out of spec:

Boxing a value of a non_nullable_value_type consists of allocating an object instance and copying the non_nullable_value_type value into that instance.

So, would it be absolutely crazy to change the wording of the spec here in some way to allow the runtime or compiler to consider ways to optimize this situation? I'm sure it would break one person's unit test somewhere, but it seems pretty reasonable to me considering some other breaking changes that have been allowed.

[HaloFour]

This doesn't feel like a C# language issue? It'd be up to the runtime to interpret boxing differently for bools or other value types.

I do wonder if the runtime couldn't manage two singleton instances of boxed bools that they could then swap out instead of allocating whatever the current value was? Same with maybe a range of numeric value types? That'd be similar to how Java handle boxing, although that's a much more manual affair.

[KennethHoff]

Both the issues they linked was closed due to "Following csharp spec" which tells me that this is in fact an issues related to the spec

[HaloFour]

Sounds like it's required in both the language and runtime specs. It also sounds like it's technically possible to modify the boxed value type, which might make such an optimization dangerous, if only in theory. There's also the problem of identity, as the boxed values have reference identity and such optimizations would be observable.

Either way, it sounds like something that can't really be easily addressed and would involve breaking changes. An analyzer could be used to warn about boxing value types and refer to a helper to opt-in to shared instances where appropriate, but it doesn't sound like the language or runtime teams want to make any changes here? Although it's been a few years, maybe the calculus has changed.

[FaustVX]

Maybe with some SG magic to detect something like this

void M(object passABoolHere)
{ }

M(true);
M(false);
M(my_bool);

and generate

static class BoxedBool
{
  public static readonly object True = true;
  public static readonly object False = false;
}

[InterceptorLocation(…)]
void MBool(bool passABoolHere)
=> M(passABoolHere ? BoxedBool.True : BoxedBool.False);

And maybe emit some warnings

M(true); // Box001: Value type boxed, interceptor kicks in
M(false); // Box001: Value type boxed, interceptor kicks in
M(my_bool); // Box001: Value type boxed, interceptor kicks in

[ufcpp]

Does Unsafe.Unbox cause problems?

using System.Runtime.CompilerServices;

object boxedTrue = true;

Unsafe.Unbox<bool>(boxedTrue) = false;

Console.WriteLine(boxedTrue); // false

[HaloFour]

Kinda like using reflection to change String.Empty? 😀

[ufcpp]

It may be even more difficult than that, since it is the protection of contents of instances.
However, a similar problem already exists today with the use of Unsafe for const strings.

var x = "abc";

unsafe
{
    fixed (char* p = x)
        p[0] = 'd';
}

Console.WriteLine("abc"); // dbc

[AartBluestoke]

does Does Unsafe.<something> allow something causes problems?
why of course, that is its purpose :D
I don't want to speak for the LDT, but i suspect that "this would allow people screwing with unsafe commands on runtime internals to mess stuff up even more" wouldn't be a design consideration - i'm sure you can mess up the 'empty' singletons at the moment ...