Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

.NET 5+ 환경에서 P/Invoke의 성능을 높이기 위한 SuppressGCTransition 특성

오호~~~ 재미있는 트윗이 하나 올라왔군요. ^^


...I did some research on the SuppressGCTransition attribute....
; https://twitter.com/KooKiz/status/1692127734854459426?s=20

SuppressGCTransition
; https://minidump.net/suppressgctransition-b9a8a774edbd

위의 글을 정리해 볼까요? ^^

SuppressGCTransition 특성은 .NET 5부터 추가된 것으로, DllImport를 적용한 P/Inovke API에 함께 적용할 수 있습니다.

[DllImport("NativeLib.dll")]
[SuppressGCTransition]
static extern int Increment(int value);

이것을 적용하면 (저자가 작성한 테스트 함수의 경우) 4배 정도의 속도 향상이 있었다고 하는데요, 그럴 수밖에 없는 것이 해당 특성으로 인해 P/Invoke의 Transition 관련 코드들이 없어지기 때문입니다. 이에 대해서는 전에 몇 번 언급한 적이 있군요. ^^

P/Invoke의 성능을 높이기 위해 C++/CLI가 선택되려면?
; https://www.sysnet.pe.kr/2/0/1229

windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석
; https://www.sysnet.pe.kr/2/0/12065

하지만, SuppressGCTransition이 항상 좋은 것은 아닌데요, 원문의 글에서도 나오듯이 P/Invoke API의 실행 시간을 일부러 100ms 지연시킨 경우에는 반대로 2배의 속도 저하가 생깁니다.




속도 저하의 원인을 설명하기 위해서는 스레드의 2가지 상태, Preemptive와 Cooperative를 알아야 합니다.

.NET Thread 상태가 Cooperative일 때 GC hang 현상 재현 방법
; https://www.sysnet.pe.kr/2/0/11634

닷넷 세계에서, P/Invoke를 통해 진입한 비-관리 코드는 GC에 방해를 하지 않는 Preemptive 상태입니다. 이러한 상태 변화는 P/Invoke 대상이 되는 API의 앞/뒤로 실행되는 Transition 관리 코드에서 처리하는데요, 대충 이런 식입니다.

...[닷넷 코드를 수행 중인 Cooperative 상태의 스레드가 P/Invoke 호출]...
[transition - 스레드를 Preemptive 상태로 마킹]
Native API 호출
[transition - 스레드를 Cooperative 상태로 마킹]
...[닷넷 코드를 계속 수행(Cooperative 상태)]...

하지만 SuppressGCTransition 특성을 지정하면 transition 코드가 없어지기 때문에,

...[닷넷 코드를 수행 중인 Cooperative 상태의 스레드가 P/Invoke 호출]...
Native API 호출 (여전히 Cooperative 상태)
...[닷넷 코드를 계속 수행(Cooperative 상태)]...

Native API 실행 중에도 Cooperative로 남게 되는 것입니다.

저런 변화를 GC에 엮어서 설명해 볼까요?

GC는, Preemptive 상태의 스레드는 무시하고 수행할 수 있습니다. P/Invoke의 상황을 예로 들면, 일단 Preemptive로 표시된 후 Native API가 호출되는 동안에 GC는 그 스레드와 병렬로 수행될 수 있습니다. 그렇다면 GC가 수행되는 사이 Native API 호출이 완료되고 Cooperative 모드의 닷넷 코드 영역으로 넘어가면 문제가 되지 않을까요? ^^

그럴 수가 없는 것이, Native API 호출 이후 현재 GC가 수행 중이면 닷넷 코드로 진입하기 전에 blocking을 하기 때문입니다.

자, 그럼 SuppressGCTransition 특성이 왜 성능에 영향을 미치는지 예상할 수 있습니다. Native API 전/후의 transition 코드를 없애기 때문에 스레드는 계속 Cooperative 상태로 머물게 되고, 이때 GC는 그 스레드와 병렬로 수행할 수 없습니다. 결국 GC는 Cooperative 스레드를 안전한 위치의 코드를 수행 중인 지 확인하기 위해 suspend 시켜, 1) 만약 안전한 영역이라면 그대로 (suspend 상태로) GC를 수행하지만, 2) 안전하지 않은 영역을 수행 중이면 안전한 영역으로 나올 때까지 다시 resume 시킨 후 GC는 "대기"를 하게 됩니다.

정리하면, SuppressGCTransition으로 인해 GC는 모든 .NET 스레드를 중지시킨 체로 대기하다가 P/Invoke API의 호출이 완료돼 해당 스레드가 중지되어서야 비로소 GC 작업을 하기 때문에 성능에 영향을 미치게 되는 것입니다.




SuppressGCTransition 적용의 또 다른 부작용은 디버거가 정상적으로 P/Invoke로 들어선 스레드의 호출 스택을 보여줄 수 없다는 것입니다. 아마도 이것은 차차 개선되지 않을까 싶은데요, 현재의 SOS Debugger 확장은 Transition이 당연히 있는 것으로 가정하고 !clrstack의 결과를 찾기 때문에 SuppressGCTransition이 있는 P/Invoke 호출에 대해서는 정상적인 풀이를 못하는 듯합니다. (순전히 제 의견입니다. ^^)

문서에 따르면, P/Invoke로 호출하는 native 함수 안에서 예외를 던져서도 안 된다고 합니다. 원문의 저자가 수행한 테스트로는 별다른 부작용을 발견할 수는 없었지만, 아무튼 문서에 따르는 것이 좋겠다는 의견입니다.

또한, P/Invoke 내에서 닷넷 측으로의 콜백(Reverse P/Invokes)도 해서는 안 된다고 합니다. 이것은 Transition 층이 없어지는 것으로 인한 부작용인데요, 예를 들어 기존에는 다음과 같은 호출과 스레드 상태 변경이 있었는데,

// SuppressGCTransition 미지정
.net code -> (transition) ->  p/invoke code -> (transition) -> (callback to) .net code -> (transition) -> p/invoke code
[Cooperative]      ->         [Preemptive]           ->                      [Cooperative]      ->        [Preemptive]

보는 바와 같이 p/invoke에서 콜백을 호출하기 전/후 동일하게 [Preemptive] 상태로 일치합니다. 반면 SuppressGCTransition으로 transition 코드가 빠진 경우에는,

// SuppressGCTransition 지정

.net code ->  p/invoke code -> (transition) -> (callback to) .net code -> (transition) -> p/invoke code
[Cooperative]                      ->                        [Cooperative]    ->          [Preemptive]

콜백 호출 전에는 Cooperative 모드였는데, 콜백을 완료하고 나서는 Preemptive 모드로 바뀌었습니다. 따라서 GC로 하여금 안전한 상태로 판정받기 때문에 별다른 조치가 없는 상태에서 P/Invoke 호출을 빠져나와 곧바로 .NET Code를 수행하는 시점에 자칫 (아마도) ExecutionEngineException 오류가 발생할 수 있습니다.

기타 "Stack spill"에 대해서도 설명하지만 어차피 이것은 Transition 코드가 갖는 오버헤드이므로 딱히 중요한 것은 아닙니다.

마지막으로, 문서에는 SuppressGCTransition에 대한 사용 지침을 알려주고 있으니 참고하시고,

  • 가능한 1us(1마이크로 초) 안에 수행될 함수에 대해서만 SuppressGCTransition 지정 (권장)
  • 닷넷 코드로의 callback이 없어야 하고 (필수),
  • 예외를 발생시켜서는 안 되고 (필수),
  • (블록킹을 발생할 수 있는) lock을 다루지 않아야 함 (권장)

덕분에 재미있는 것을 알게 되었습니다. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/21/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2023-08-20 01시09분
좋은 글 감사합니다!
이승후

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13521정성태1/11/20241473닷넷: 2199. C# - 한국투자증권 KIS Developers OpenAPI의 WebSocket Ping, Pong 처리
13520정성태1/10/20241301오류 유형: 888. C# - Unable to resolve service for type 'Microsoft.Extensions.ObjectPool.ObjectPool`....'
13519정성태1/10/20241359닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출파일 다운로드1
13518정성태1/9/20241484닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
13517정성태1/8/20241413스크립트: 63. Python - 공개 패키지를 이용한 위성 이미지 생성 (pystac_client, odc.stac)
13516정성태1/7/20241515닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
13515정성태1/6/20241773닷넷: 2195. async 메서드 내에서 C# 7의 discard 구문 활용 사례 [1]
13514정성태1/5/20241518개발 환경 구성: 702. IIS - AppPool의 "Disable Overlapped Recycle" 옵션
13513정성태1/5/20241439닷넷: 2194. C# - WebActivatorEx / System.Web의 PreApplicationStartMethod 특성
13512정성태1/4/20241442개발 환경 구성: 701. IIS - w3wp.exe 프로세스의 ASP.NET 런타임을 항상 Warmup 모드로 유지하는 preload Enabled 설정
13511정성태1/4/20241421닷넷: 2193. C# - ASP.NET Web Application + OpenAPI(Swashbuckle) 스펙 제공
13510정성태1/3/20241371닷넷: 2192. C# - 특정 실행 파일이 있는지 확인하는 방법 (Linux)
13509정성태1/3/20241412오류 유형: 887. .NET Core 2 이하의 프로젝트에서 System.Runtime.CompilerServices.Unsafe doesn't support netcoreapp2.0.
13508정성태1/3/20241467오류 유형: 886. ORA-28000: the account is locked
13507정성태1/2/20242186닷넷: 2191. C# - IPGlobalProperties를 이용해 netstat처럼 사용 중인 Socket 목록 구하는 방법파일 다운로드1
13506정성태12/29/20231624닷넷: 2190. C# - 닷넷 코어/5+에서 달라지는 System.Text.Encoding 지원
13505정성태12/27/20231799닷넷: 2189. C# - WebSocket 클라이언트를 닷넷으로 구현하는 예제 (System.Net.WebSockets)파일 다운로드1
13504정성태12/27/20231674닷넷: 2188. C# - ASP.NET Core SignalR로 구현하는 채팅 서비스 예제파일 다운로드1
13503정성태12/27/20231582Linux: 67. WSL 환경 + mlocate(locate) 도구의 /mnt 디렉터리 검색 문제
13502정성태12/26/20231667닷넷: 2187. C# - 다른 프로세스의 환경변수 읽는 예제파일 다운로드1
13501정성태12/25/20231508개발 환경 구성: 700. WSL + uwsgi - IPv6로 바인딩하는 방법
13500정성태12/24/20231551디버깅 기술: 194. Windbg - x64 가상 주소를 물리 주소로 변환
13498정성태12/23/20231835닷넷: 2186. 한국투자증권 KIS Developers OpenAPI의 C# 래퍼 버전 - eFriendOpenAPI NuGet 패키지
13497정성태12/22/20231654오류 유형: 885. Visual Studiio - error : Could not connect to the remote system. Please verify your connection settings, and that your machine is on the network and reachable.
13496정성태12/21/20231590Linux: 66. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (gdb)
13495정성태12/20/20231533Linux: 65. clang++로 공유 라이브러리의 -static 옵션 빌드가 가능할까요?
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...