Don't assume objects don't escape in pure helpers.

[erozenfeld]

We can't assume objects don't escape in helpers marked as pure for the following reasons:

1. The helpers may call user code that may make objects escape, e.g.,
   

   coreclr/src/vm/jithelpers.cpp

   Line 2371 in c94d8e6

   CALL_MANAGED_METHOD(fCast, BOOL, args);

2. The helpers usually protect gc pointers with GCPROTECT_BEGIN() so the pointers are reported as normal pointers to the gc.
   Pointers to stack-allocated objects need to be reported as interior so they have to be protected with
   GCPROTECT_BEGININTERIOR().

3. The helpers may cause these asserts in ValidateInner on stack-allocated objects:
   

   coreclr/src/vm/object.cpp

   Line 723 in c94d8e6

   CHECK_AND_TEAR_DOWN(bSmallObjectHeapPtr || bLargeObjectHeapPtr);

   
   

   coreclr/src/vm/object.cpp

   Line 730 in c94d8e6

   CHECK_AND_TEAR_DOWN(GetHeader()->Validate(bVerifySyncBlock));

[erozenfeld]

@AndyAyersMS @echesakov @dotnet/jit-contrib PTAL

[AndyAyersMS]

Do you have a sense of how often being conservative here will block stack allocation?

I'm wondering if we might want to revisit this someday.

[CarolEidt]

@AndyAyersMS - by revisiting this, I presume you mean refining the way we mark the helpers so that we can identify those that are truly "pure" in their handling of stack-allocated objects?

[CarolEidt]

@erozenfeld - is there a tracking issue for this TODO?

[erozenfeld]

@CarolEidt It's one of the items in todo list in https://github.com/dotnet/coreclr/issues/20253#issue-366568135 :

• special case calls to helpers where arguments don't escape (this will require ensuring that the helpers report gc arguments as interior to gc)

[AndyAyersMS]

Yes... wonder how costly/risky it would be to update helpers to have more flexible expectations.

[erozenfeld]

@AndyAyersMS Yes, I think we'll have to address this. There are two aspects:

1. Identify helpers where params are guaranteed not to escape.
2. Either change those helpers to report gc params as interior or, if that approach is not acceptable for perf reasons, create additional versions of the helpers that report params as interior and are only called when gc args may be stack-allocated.

We may decide to do this for a subset of the helpers, I haven't done analysis on cost/benefit tradeoff yet.