Skip to content

Conversation

jakobbotsch
Copy link
Member

Add ability for the VM to dynamically create continuation layout types and for the JIT to request such types to be created.

Add ability for the VM to dynamically create continuation layout types
and for the JIT to request such types to be created.
@github-actions github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Oct 4, 2025
Copy link
Contributor

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

@davidwrighton davidwrighton requested a review from noahfalk October 7, 2025 23:22
jkotas pushed a commit that referenced this pull request Oct 16, 2025
@jkotas
Copy link
Member

jkotas commented Oct 16, 2025

Test failures look related: System.InvalidProgramException: Invalid IL code in AwaitNotAsync:AsyncEntryPoint

@jakobbotsch
Copy link
Member Author

Test failures look related: System.InvalidProgramException: Invalid IL code in AwaitNotAsync:AsyncEntryPoint

I think this one was just Mono complaining about not supporting runtime async. But the 32-bit coreclr failures were related. Pushed a fix for that one, and I need to remember to revert the enabling of the testing.

@jakobbotsch
Copy link
Member Author

jakobbotsch commented Oct 16, 2025

I still need to do some final testing that verifies that the ETW events look right, but this should be ready for another look @jkotas @noahfalk @VSadov. Anything else you see here? I opened #120799 and #120800 for follow-up diagnostics work.

cc @dotnet/jit-contrib PTAL @AndyAyersMS. On the JIT side this is mostly simplifying things by removing the indirections through separate arrays stored in Continuation, and by no longer needing to store/access GC refs of locals separately.

Comment on lines +543 to -601
private static Task<T?> FinalizeTaskReturningThunk<T>()
{
Continuation finalContinuation = new Continuation();

// Note that the exact location the return value is placed is tied
// into getAsyncResumptionStub in the VM, so do not change this
// without also changing that code (and the JIT).
if (RuntimeHelpers.IsReferenceOrContainsReferences<T>())
{
finalContinuation.Flags = CorInfoContinuationFlags.CORINFO_CONTINUATION_RESULT_IN_GCDATA | CorInfoContinuationFlags.CORINFO_CONTINUATION_NEEDS_EXCEPTION;
finalContinuation.GCData = new object[1];
}
else
{
finalContinuation.Flags = CorInfoContinuationFlags.CORINFO_CONTINUATION_NEEDS_EXCEPTION;
finalContinuation.Data = new byte[Unsafe.SizeOf<T>()];
}

continuation.Next = finalContinuation;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now represent the tail with a null "next" continuation. The problem with that is figuring out where to put the result of the final continuation -- we now use the storage inside the RuntimeAsyncTask<T>.m_result as the place to put it when we get to the end.

Copy link
Member

@noahfalk noahfalk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me modulo making RuntimeAsync on by default. If there is a need to get it on by default regardless of the diagnostics I'd suggest we do it in a separate PR.

Copy link
Member

@AndyAyersMS AndyAyersMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JIT changes look good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants