[NativeAOT] thread suspension on Unix #71187

VSadov · 2022-06-23T06:37:58Z

Implements return address hijacking and asynchronous suspension at safe points on Unix.

x64
arm64 (will be in a separate change)

Contributes to: #67805

jkotas · 2022-07-01T00:42:39Z

src/coreclr/nativeaot/Runtime/unix/UnixNativeCodeManager.cpp

+// enum used by the runtime.
+GCRefKind GetGcRefKind(ReturnKind returnKind)
+{
+    static_assert((GCRefKind)ReturnKind::RT_Scalar == GCRK_Scalar, "ReturnKind::RT_Scalar does not match GCRK_Scalar");


Unix x64 ABI can return values in two registers, and so there are variants like RT_Scalar_Obj.

Do we need to handle them here? Also, it may be interesting to look into why you have not seen this problem in the tests.

The lab testing that is currently enabled for this on Unix is fairly limited, I believe, and I have a limited capacity to stress-test the change locally so we may miss some cases.

The static assert tests some cases, but GCRefKind translation is basically one-to-one, not even sure if the assert helps much here.
I am not changing GC decoding, so it may just work if it is the same data just stored/read at different location.

Perhaps more expanded libs testing will provide failures and repro cases.
I am not yet sure what I'd be adding here for multreg returns.

Thread::InternalHijack needs to be fixed to hande the new cases.

You can try to build a targeted repro that has a lot of methods that return struct { int a; object b; }. Also, check the generated code to make sure that this struct is indeed returned in rax and rdx registers (object b should be in rdx).

Will take a look. Thanks!

I kind of assumed that since we can stackwalk in scenarios that already work, we may already be handling all kinds of cases, but this is a new scenario.

MichalStrehovsky · 2022-07-01T07:05:20Z

/azp run runtime-extra-platforms

azure-pipelines · 2022-07-01T07:05:44Z

Azure Pipelines successfully started running 1 pipeline(s).

VSadov · 2022-07-18T06:29:05Z

Windows x64 failure:

Unhandled Exception: System.PlatformNotSupportedException: Operation is not supported on this platform.
   at System.Threading.Thread.InitializeCom(ApartmentState) + 0xba
   at System.Threading.Thread.StartThread(IntPtr) + 0x5d
   at System.Threading.Thread.ThreadEntryPoint(IntPtr) + 0x1a

Windows arm64 failure:

Assert.Equal() Failure
Expected: 2
Actual:   0
   at System.Threading.Threads.Tests.ThreadTests.ApartmentStateTest_ChangeBeforeThreadStarted_Windows(Func`2, Func`3, Int32) + 0x164
   at System.Threading.Thread.Tests!<BaseAddress>+0x878df4
   at System.InvokeUtils.CallDynamicInvokeMethod(Object, IntPtr, IntPtr, IntPtr, Object, Object[], BinderBundle, Boolean, Boolean) + 0xec

I do not think they are related to the change.

src/coreclr/nativeaot/Runtime/unix/UnwindHelpers.cpp

janvorli · 2022-07-18T08:32:00Z

src/coreclr/nativeaot/Runtime/unix/unixasmmacrosamd64.inc

@@ -318,7 +320,7 @@ C_FUNC(\Name):
 DEFAULT_FRAME_SAVE_FLAGS = PTFF_SAVE_ALL_PRESERVED + PTFF_SAVE_RSP

 .macro PUSH_COOP_PINVOKE_FRAME trashReg
-    push_nonvol_reg rbp                         // push RBP frame
+    push_nonvol_reg rbp                         // push RBP frame  // TODO: do we need this? not on windows.


Regarding the added TODO: I believe this is needed for unwindability. I would think that on Windows, it is needed too.

These macros are used to call GC helpers, not the user code, so I assume unwindability here would be useful for crash dumps and such.
The Windows version seems to be using RSP-based frame style, which makes it simpler as RBP is just a nonvol register. I think the pattern is unwindable, at least as much as needed for debugging.

I will keep the TODO here. I will be doing some cleanup of assembly helpers. I think we have a good deal of redundancy and will take a look at this as a part of cleanup.
Ideally we should use the same code.

I meant unwinding when debugging the code (and core dump too.)
This macro was actually changed to use RBP based frame by @jkotas in dotnet/corert#4812

I see. Thanks! Saves me time to figure if the alternative works with debuggers (I now know it does not).

I will change Windows to use the same code then (in a separate change). Even if Windows is resilient to this, it is nicer to have the same code where possible.

janvorli · 2022-07-18T08:36:07Z

src/coreclr/nativeaot/Runtime/unix/UnixNativeCodeManager.cpp

+
+    // if we are in an epilogue, there will be at least one instruction left.
+    int trailingEpilogueInstructions = 1;
+    uint8_t* NextByte = (uint8_t*)pvAddress;


A nit - can you please fix the naming convention of some of the locals (start with lowercase)?

jkotas · 2022-07-18T15:16:40Z

I do not think they are related to the change.

Yes, that's #72352

src/coreclr/nativeaot/Runtime/ICodeManager.h

jkotas · 2022-07-18T16:08:13Z

src/coreclr/nativeaot/Runtime/ICodeManager.h

+    ASSERT(returnKind <= GCRK_LastValid);
+    return (GCRefKind)(returnKind & (GCRK_Object | GCRK_Byref));
+}
+


ExtractReg1ReturnKind can be moved here as well.

src/coreclr/nativeaot/Runtime/thread.cpp

jkotas · 2022-07-18T16:12:57Z

src/coreclr/nativeaot/Runtime/thread.cpp

+{
+    reinterpret_cast<void*>(RhpGcProbeHijack)
+};
+#else // TARGET_ARM64 || TARGET_UNIX
 EXTERN_C void FASTCALL RhpGcProbeHijackScalar();


It would be nice to switch the other platforms to the one-and-only hijack target plan (in separate PR).

Yes. It occured to me that using multiple probe targets on win-x64 as a way to pass return kind to the probe is not very rewarding optimization.
Perf of suspension code would be gated by how many syscalls we make and how many iterative attempts we do, so benefits here would be fairly small in comparison.

src/coreclr/nativeaot/Runtime/thread.cpp

jkotas · 2022-07-18T16:24:31Z

src/coreclr/nativeaot/Runtime/unix/UnixNativeCodeManager.cpp

+        //
+        // Such an opcode is an unambiguous epilogue indication.
+        //
+


You may want to check for a breakpoint and give up if you see one.

(It is annoying that setting a breakpoint introduces GC crash.)

Or print debug output if you run into a breakpoint.

I think 'int 3' in regular code will be naturally handled since it is not recognized as a part of epilogue anyways.

Placing a breakpoint in epilogue might be rare and would be hard to handle reliably, since I would not know what it replaced.
I will have to think about this. I can treat int 3 as a ret if I have seen pops.

Or just return -1 if i see int 3and treat that as not-hijackable.

jkotas

LGTM modulo comments. Thank you!

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

VSadov · 2022-07-18T19:42:07Z

/azp run runtime-extra-platforms

azure-pipelines · 2022-07-18T19:42:30Z

Azure Pipelines successfully started running 1 pipeline(s).

VSadov · 2022-07-19T03:20:17Z

quic failures are #72429

VSadov · 2022-07-19T03:20:51Z

Thanks!!!

dotnet-issue-labeler bot added the area-NativeAOT-coreclr label Jun 23, 2022

ghost assigned VSadov Jun 23, 2022

VSadov force-pushed the hijackUnix branch 2 times, most recently from d5325b2 to e050f9b Compare June 23, 2022 20:56

VSadov force-pushed the hijackUnix branch from b749461 to bb14267 Compare June 30, 2022 21:01

VSadov marked this pull request as ready for review June 30, 2022 21:03

VSadov requested a review from MichalStrehovsky as a code owner June 30, 2022 21:03

VSadov requested review from jkotas and removed request for MichalStrehovsky June 30, 2022 21:04

jkotas reviewed Jul 1, 2022

View reviewed changes

VSadov force-pushed the hijackUnix branch from bb14267 to 81e950e Compare July 2, 2022 16:43

VSadov added 12 commits July 6, 2022 11:08

missing pieces

363dbee

fixes

8ad2f99

pThreadToHijack

0e8ef45

NATIVE_CONTEXT

c393715

at safe point

815cfb2

enable TestConcurrentIsBackgroundProperty

09af4f1

couple tweaks

22851f4

fixes after rebasing

349f25f

temporarily do not handle multireg returns

819706d

support single reg return hijack

d808039

disable return hijacking for ARM64

0154a90

enable safe point suspend

2499330

VSadov force-pushed the hijackUnix branch from 9ac4fc6 to 2499330 Compare July 6, 2022 18:08

VSadov added 4 commits July 6, 2022 17:07

enable multireg

8406314

make gcc happy

9c7c9ab

fixws for win-x64

c3c3f1a

Do not wait for Unhijack.

464f3a9

VSadov mentioned this pull request Jul 18, 2022

Rebaseline llvm-libunwind tree #72351

Merged

janvorli reviewed Jul 18, 2022

View reviewed changes