Constants for boxed true and false values

[nschuessler]

We have performance experts going through parts of our code base looking for memory allocations for boxed 'true' and 'false' boolean values and creating constants for the boxed values.

Isn't this something that could be available in the runtime either as constants or as part of the compiler to optimize this so:

1. We can avoid boxing booleans (by using the constants)
2. We can avoid the allocations that happen as a result of boxing.

[HaloFour]

This sounds like a suggestion for the https://github.com/dotnet/runtime repository.

To me it sounds like it could be a JIT optimization to detect when a bool is being boxed and to push a reference to one of two constant instances on the heap. However, that would also make boxed bools lose reference identity.

[Joe4evr]

This would be very problematic to do now since Unsafe.Unbox<T>() can give you a mutable ref to the heap location.

using System;
using System.Runtime.CompilerServices;

class Program
{
    private static readonly object BoxedTrue = true;

    static void Main()
    {
        Console.WriteLine(BoxedTrue); //'True'
        Unsafe.Unbox<bool>(BoxedTrue) = false;
        Console.WriteLine(BoxedTrue); //'False'
    }
}

See also the discussion at dotnet/runtime#28278

[yaakov-h]

Well it is unsafe after all.

[Joe4evr]

Sure, and the docs call out that this usage is very discouraged and results in unverifiable IL, but it does work (at the moment) and if the runtime would always make boxed booleans point to the same singleton instances, some malicious API could do something akin to this and break the entire world for that process.

[jnm2]

This is already possible with e.g. strings, so how much of an added threat would it really be? If untrusted code is running within the same process, all bets are already off.

[HaloFour]

Yep, could always mutate string.Empty via reflection.

[333fred]

Yep, could always mutate string.Empty via reflection.

I've been told a good story about how accidentally passing a ref to that through COM (and then subsequent mutation) broke dev10 internal builds. Took quite a bit of sleuthing to find.

[khellang]

Duplicate of dotnet/runtime#47596?