Reconcile how LOH allocations are tracked in allocation contexts

[VSadov]

Alloc uses per-thread context
AllocLHeap uses per-heap context.

We probably should use only one way. Using per-heap context consistently is attractive, since we can make allocation contexts smaller by removing alloc_bytes_loh

However, consider GetAllocatedBytesForCurrentThread API - does it actually see allocations done via AllocLHeap ? Should it?

[Suchiman]

However, consider GetAllocatedBytesForCurrentThread API - does it actually see allocations done via AllocLHeap ?

It appears that it does not, if you attempt to allocate an array that crosses the LOH threshold, it is not measured, which would explain why the allocations did not show in my benchmark in #13451 .
Following program will print 45648 for before and after.

using System;

class Program
{
    static void Main(string[] args)
    {
        long before = GC.GetAllocatedBytesForCurrentThread();

        var result = new char[50000];

        long after = GC.GetAllocatedBytesForCurrentThread();

        Console.WriteLine(before);
        Console.WriteLine(after);
    }
}

a new string(new char[50000]) interestingly enough gets measured (but only for the string allocation)

Should it?

Why shouldn't it? I would expect that it shows all allocations made on my current thread.

[Maoni0]

the reason why AllocLHeap was there was to allocate objects smaller than LOH threshold on LOH. I have not looked at your PR yet, but I hope that was kept in mind.

[VSadov]

@Maoni0 - yes, forcing allocations of smaller objects to go into LOH is still possible. I also plan to use a similar mechanism (flags) as a way to request POH allocations.
Thanks for reviewing!!

[VSadov]

Fixed in #33402