Assertion failed 'curSize < maxSplitSize' during 'Emit code'

[kunalspathak]

// Found by Antigen


using System;
public class TestClass
{
    public static void Main(string[] args)
    {
    }
}
/*
Environment:

set COMPlus_JitSplitFunctionSize=4

Assert failure(PID 5728 [0x00001660], Thread: 10212 [0x27e4]): Assertion failed 'curSize < maxSplitSize' in '(dynamicClass):InvokeStub_EventAttribute.set_Level(System.Object,System.Object,ulong):System.Object' during 'Emit code' (IL size 25; hash 0x433e37b5; FullOpts)
    File: D:\a\_work\1\s\src\coreclr\jit\emit.cpp Line: 3146
    Image: e:\kpathak\CORE_ROOT\corerun.exe
*/

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

Issue Details

---

// Found by Antigen


using System;
public class TestClass
{
    public static void Main(string[] args)
    {
    }
}
/*
Environment:

set COMPlus_JitSplitFunctionSize=4

Assert failure(PID 5728 [0x00001660], Thread: 10212 [0x27e4]): Assertion failed 'curSize < maxSplitSize' in '(dynamicClass):InvokeStub_EventAttribute.set_Level(System.Object,System.Object,ulong):System.Object' during 'Emit code' (IL size 25; hash 0x433e37b5; FullOpts)
    File: D:\a\_work\1\s\src\coreclr\jit\emit.cpp Line: 3146
    Image: e:\kpathak\CORE_ROOT\corerun.exe
*/


<table>
  <tr>
    <th align="left">Author:</th>
    <td>kunalspathak</td>
  </tr>
  <tr>
    <th align="left">Assignees:</th>
    <td>-</td>
  </tr>
  <tr>
    <th align="left">Labels:</th>
    <td>

`area-CodeGen-coreclr`

</td>
  </tr>
  <tr>
    <th align="left">Milestone:</th>
    <td>-</td>
  </tr>
</table>
</details>

[kunalspathak]

I see this and few other issues with COMPlus_JitSplitFunctionSize. Also see this on arm. We should evaluate how important it is to try out this environment variable and such issues. If it is less important, I can reduce its weight (or remove) from Antigen. Let me know @BruceForstall

[BruceForstall]

I think it's important this stress mode works for any given value, and we use it, even if (and because) the actual scenario requiring splitting is very rare.

[jakobbotsch]

The assert (but not the problem) is new with #90246, but likely the problem is just that we cannot support a JitSplitFunctionSize that is smaller than a certain size due to how the splitting only works on IG boundaries.

The minimal size we can support splitting is probably something like the max size of a prolog + the max size of an IG + the max size of an epilog to guarantee we can always find a split point.

[BruceForstall]

the problem is just that we cannot support a JitSplitFunctionSize that is smaller than a certain size

There is logic that is supposed to allow splitting above the specified size if necessary (and thus allow any size to be specified); perhaps it's not working.

[jakobbotsch]

There is logic that is supposed to allow splitting above the specified size if necessary (and thus allow any size to be specified); perhaps it's not working.

Well, if we want a "best-effort" thing for testing purposes then the assert I added should likely just be relaxed or removed again. Under normal operation emitSplit is not allowed to be best effort, though, so should we really allow it when testing?

[BruceForstall]

The actual required split size (512KB or 1MB) is always greater than our required minimum (max size of prolog, etc.), so in reality it's not a problem. I wanted to allow you to say JitSplitFunctionSize=1 (for example) to force the maximum amount of splitting, without worrying about what the actual practical JIT minimum number is.

[jakobbotsch]

I guess we can do multiple things then:

• Revert the assertion I added and keep it best-effort for testing purposes
• Have the JIT raise the split size to a value we always expect we'd be able to split at when too small (e.g. minSupportedSplitSize = max prolog size + max IG size + max epilog size)
• Just relax the assertion to something like assert(curSize <= max(maxSplitSize, minSupportedSplitSize)) which keeps us splitting as much as possible, but still keeps some validation on the "hard requirements"