crossgen2: Report CORINFO_FLG_NOGCCHECK back for internal calls

[jakobbotsch]

When there are loops or tailcalls in a function the JIT will check for
a dominating call that is a GC safepoint to figure out if the function
needs to be marked fully interruptible or not. Methods with the
InternalCall flag may turn into fcalls that are not hijackable and thus
not GC safepoints, so in this case JIT should still mark the function
fully interruptible, but was not doing so because crossgen2 was not
reporting this flag back.

Fix #64980

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When there are loops or tailcalls in a function the JIT will check for
a dominating call that is a GC safepoint to figure out if the function
needs to be marked fully interruptible or not. Methods with the
InternalCall flag may turn into fcalls that are not hijackable and thus
not GC safepoints, so in this case JIT should still mark the function
fully interruptible, but was not doing so because crossgen2 was not
reporting this flag back.

Fix #64980

Author:	jakobbotsch
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[jakobbotsch]

I have tried for a while to create a simple regression test, but with checked bits the following case has very long suspension times and sometimes hits the timeout, even though FcallInLoop is fully interruptible.

using System;
using System.Threading;

public class Program
{
    public static void Main()
    {
        Program p = new Program();
        Thread hijack = new Thread(p.FcallInLoop);
        hijack.Start();
        p.GCInLoop();
        hijack.Join();
    }

    private readonly object _doneObj = new object();
    private object _state;

    public void FcallInLoop()
    {
        while (true)
        {
            object oldVal = Interlocked.CompareExchange(ref _state, null, null);
            if (oldVal == _doneObj)
                break;
        }
    }

    public void GCInLoop()
    {
        Thread.Sleep(50);

        System.Console.WriteLine("Starting GCInLoop");
        for (int i = 0; i < 10; i++)
        {
            System.Console.WriteLine("GC {0}", i + 1);
            GC.Collect();
            Thread.Sleep(1);
        }

        _state = _doneObj;
    }
}

With release bits it seems to be much better, presumably because it spends more time in FcallInLoop relatively to the fcall.

@jkotas Is this what you meant when you said that the story around GC suspension and fcalls is not perfect even for the JIT case?

[jkotas]

@jkotas Is this what you meant when you said that the story around GC suspension and fcalls is not perfect even for the JIT case?

Yes. Ideally, we would emit an explicit GC suspension check after each FCall, similar to what we are doing for PInvokes with SuppressGCTransition.

[jkotas]

Thanks