Why is this test failing?

Can you show the code of the test?

 

Ahhh, right. What's happening there is that NUnit has a standard way of displaying constraint failures - it shows you the constraint (in this case, 'not allocates GC memory') and the 'value' that did not meet the constraint, in this case a delegate that was generated from the function you passed in. The fact that it's reporting that constraint as having failed means that the delegate you passed is indeed causing GC memory to be allocated when it is invoked.

The message could definitely be improved... I'm a little puzzled because it looks like the code for AllocatingGCMemoryResult does override the method for generating the output, it should be producing a message like "The provided delegate made 3 GC allocations" or similar. We do have tests that are checking

AssertionException.Message

for a string along those lines, so it might be a bug in the way NUnit generates the final result for the console.

 

One thing to check - if you execute the delegate once first, and then do the assertion for it, do you still see it fail? I think I've seen issues in the past on Mono where the initial JIT of the code can cause GC allocations.

 

We can't guarantee that the delegate will not have side effects, so it's not safe for us to just execute it for you automatically.

I think we might be able to force JIT of the delegate itself, which will help with some cases, but I don't think there is any way for us to guarantee that no JIT happens at all during the assertion. At the very least we should mention this in the docs though. Let me see what I can do about that...

 

I've opened a PR that will replace the 'NUnit.Framework.TestDelegate' with something more useful like '3 GC allocations', as well as improving the docs a bit. Hopefully this can ship in the next release of the test framework.

Looking at the IL for your code, the using line is doing this:

Code (csharp):

1.  
2.                 IL_0024: ldarg.0
3.                 IL_0025: ldstr "Svelto.ECS - Entities Submission"
4.                 IL_002a: newobj instance void PlatformProfiler::.ctor(string)
5.                 IL_002f: stfld valuetype PlatformProfiler NewTestScript/'<UsingTest>d__1'::'<>7__wrap1'
6.  

The

newobj

is what is causing the allocation. I think it's because your

UsingTest

method is an iterator block; if I change it so that it is not, the IL changes to this:

Code (csharp):

1.  
2.         IL_0000: ldloca.s 0
3.         IL_0002: ldstr "Svelto.ECS - Entities Submission"
4.         IL_0007: call instance void PlatformProfiler::.ctor(string)
5.  

 

You're right - I thought perhaps it was an iterator block issue, but writing the same thing out explicitly results in the same IL.

True; if the warmup trick works then it does imply what we should be looking for is a one-time operation, not something in the IL that would run every time.

One thing you could try is to use

Marshal.GetFunctionPointerForDelegate

to force the delegate to be JITted, without actually executing it. If doing that eliminates the allocation from the assert, then I think we can conclude that the allocation is coming from the JIT process itself.