Microsoft MVP성태의 닷넷 이야기
.NET Framework: 640. 닷넷 - 배열 크기의 한계 [링크 복사], [링크+제목 복사],
조회: 30114
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
.NET Framework: 188. .NET 64비트 응용 프로그램에서 왜 (2GB) OutOfMemoryException 예외가 발생할까?
; https://www.sysnet.pe.kr/2/0/946

.NET Framework: 266. StringBuilder에서의 OutOfMemoryException 오류 원인 분석
; https://www.sysnet.pe.kr/2/0/1171

.NET Framework: 357. .NET 4.5의 2GB 힙 한계 극복
; https://www.sysnet.pe.kr/2/0/1403

.NET Framework: 367. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리
; https://www.sysnet.pe.kr/2/0/1441

.NET Framework: 640. 닷넷 - 배열 크기의 한계
; https://www.sysnet.pe.kr/2/0/11142

.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
; https://www.sysnet.pe.kr/2/0/13294




닷넷 - 배열 크기의 한계

아래와 같은 질문이 있군요.

8GB 이상의 byte 배열 생성
; https://social.msdn.microsoft.com/Forums/ko-KR/fd578b7f-d3c8-4f00-9708-2407a03653f2/8gb-byte-?forum=visualcsharpko

위의 글에 대한 답변으로 예전에 썼던 .NET GC Heap을 2GB 넘게 사용하는 방법을 무심코 써먹었는데요. ^^;

.NET 4.5의 2GB 힙 한계 극복
; https://www.sysnet.pe.kr/2/0/1403

아쉽게도 이것은 다른 문제입니다. 정리하면, GC Heap을 2GB 넘게 사용하는 것은 gcAllowVeryLargeObjects 옵션을 이용해 가능하지만 그렇다고 해서 배열의 요소 수가 232을 넘지는 못합니다. 이에 대해서는 gcAllowVeryLargeObjects 문서에 자세하게 나와 있습니다.

<gcAllowVeryLargeObjects> Element
; https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/gcallowverylargeobjects-element

  • The maximum number of elements in an array is UInt32.MaxValue.
  • The maximum index in any single dimension is 2,147,483,591 (0x7FFFFFC7) for byte arrays and arrays of single-byte structures, and 2,146,435,071 (0X7FEFFFFF) for other types.
  • The maximum size for strings and other non-array objects is unchanged.

위의 의미를 해석해 보면!

우선, 단일 차원의 크기는 Int32.MaxValue에서 56을 뺀 2,147,483,591(0x7FFFFFC7)이 최대 값입니다.

byte[] t1 = new byte[Int32.MaxValue - 56]; // Int32.MaxValue - 56 == 2,147,483,591

또한, 다중 차원으로 하는 경우 전체 요소의 수는 UInt32.MaxValue까지 가능합니다. 따라서, 다음과 같이 배열 할당은 가능하지만,

byte[,] t = new byte[Int32.MaxValue - 56, 2]; // 2,147,483,591 * 2 <= UInt32.MaxValue (4,294,967,295)
byte[,] t = new byte[65537, 65535]; // 65,537 * 65,535 <= UInt32.MaxValue (4294967295)

다음과 같은 배열 할당은 불가능합니다.

byte[,] t = new byte[Int32.MaxValue, 1];
byte[,] t = new byte[Int32.MaxValue - 56, 3]; // 2,147,483,591 * 3 > UInt32.MaxValue (4294967295)
byte[,] t = new byte[65537, 65536]; // 65,537 * 65,536 > UInt32.MaxValue (4294967295)

마지막으로 단일 문자열의 크기는 2GB를 넘을 수 없습니다. 즉, 문자 하나의 크기가 2바이트이므로 Int32.MaxValue / 2 == 1,073,741,823개의 글자만 담을 수 있는데 실제로 테스트해 보면 32를 뺀 1,073,741,791까지만 가능합니다. 즉, 다음은 허용 가능하지만,

int len = 1073741823 - 32;
string s1 = new string('c', len);

그 이상을 할당하면,

int len = 1073741823 - 31;
string s1 = new string('c', len);

OOM(System.OutOfMemoryException) 예외가 발생합니다.

("other non-array objects"라는 것은 단일 클래스로 내부의 primitive 멤버 만으로 2GB를 넘는 경우일 텐데 이런 상황은 거의 없을 것이므로 넘어갑니다. ^^)



참고로, byte 타입의 경우 Marshal.AllocCoTaskMem / AllocHGlobal을 사용하면 Int32.MaxValue의 모든 범위를 접근 가능한 배열을 얻을 수 있습니다.

int len = Int32.MaxValue;
IntPtr pBuf = Marshal.AllocCoTaskMem(len);

byte* ptr = (byte*)pBuf.ToPointer();

int i = 0;
for (i = 0; i < len; i++)
{
    *(ptr + i) = 10;
}

Console.WriteLine(*(ptr + len - 1));
Console.WriteLine();

Marshal.FreeCoTaskMem(pBuf);

AllocCoTaskMem 메서드가 받아들이는 인자의 타입이 int이므로 어쩔 수 없이 2GB 한계는 갖게 되지만 CLR 오버헤드로 인한 56바이트의 제약은 벗어날 수 있습니다.



자... 그럼 재미있는 거 하나를 더 해볼까요? ^^

Marshal.AllocCoTaskMem 메서드는 사실 내부적으로 CoTaskMemAlloc Win32 API를 호출하는 것뿐입니다.

CoTaskMemAlloc function
; https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-cotaskmemalloc

그리고, 이 함수의 입력 인자 타입은 SIZE_T인데 64비트에서는 __int64로 정의된 64비트 타입입니다. 오호~~~ 그렇다면 닷넷에서 직접 CoTaskMemAlloc을 불러 배열의 한계를 넘는 것이 가능할 수 있습니다. 실제로 아래와 같이 UInt32.MaxValue의 크기를 갖는 메모리를 할당 후 바이트 배열로 취급하는 것이 가능합니다.

[DllImport("ole32.dll")]
static extern IntPtr CoTaskMemAlloc(long len);

[DllImport("ole32.dll")]
static extern void CoTaskMemFree(IntPtr pBuf);

private unsafe static void Alloc2Test()
{
    long len = UInt32.MaxValue;
    IntPtr pBuf = CoTaskMemAlloc(len);

    byte* ptr = (byte*)pBuf.ToPointer();

    long i = 0;
    for (i = 0; i < len; i++)
    {
        *(ptr + i) = 10;
    }

    Console.WriteLine(*(ptr + len - 1));
    Console.WriteLine();

    CoTaskMemFree(pBuf);
}

그럼, 이제 답이 나왔군요. "8GB 이상의 byte 배열 생성"은 Win32 API의 힘을 빌린다면 닷넷에서도 가능합니다. ^^

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/20/2023]

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

비밀번호

댓글 작성자
 



2017-02-14 08시41분
[정환나라] in32.maxvalue에서 56을 뺀 크기라고 했는데 56은 무엇을 의미하는것인지 힌트라도 주실 수 있나요?
[guest]
2017-04-11 06시18분
[2017-02-14 덧글 수정] 저도 그에 대한 문서를 찾을 수가 없군요. ^^ 검색해 보면, stackoverflow 등에서 단지 magic number라고만 언급하는 정도입니다. 아무 근거 없이 추측해 보자면, 64비트이니 8바이트 정렬이 되었다고 가정하고 56이 8로 나눠지는 것으로 봐서는 7개의 부가 정보가 필요한데요. 다음의 글에 보면 그중 4개가 나옵니다.

.NET Array는 왜 12bytes의 기본 메모리를 점유할까?
; http://www.sysnet.pe.kr/2/0/1173

Array 하나에 System.Object[]형에 대한 MethodTable 값, 배열의 요소 수, Element의 타입에 대한 MethodTable 값과 함께 배열의 마지막을 0으로 채운 값이 들어갑니다.

나머지 3개는... CLR 자체의 힙에 대한 기본적인 overhead일 수도 있는데, 아마도 CoreCLR 소스 코드를 봐야 알 수 있지 않을까 싶습니다. 이참에 '정환나라'님이 한번 보시고... 정리해 주시면... ^^
정성태

... 76  77  78  79  80  81  82  [83]  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
11862정성태4/7/201920173개발 환경 구성: 437. .NET EXE의 ASLR 기능을 끄는 방법
11861정성태4/6/201919629디버깅 기술: 126. windbg - .NET x86 CLR2/CLR4 EXE의 EntryPoint
11860정성태4/5/201923493오류 유형: 527. Visual C++ 컴파일 오류 - error C2220: warning treated as error - no 'object' file generated
11859정성태4/4/201920712디버깅 기술: 125. WinDbg로 EXE의 EntryPoint에서 BP 거는 방법
11858정성태3/27/201921627VC++: 129. EXE를 LoadLibrary로 로딩해 PE 헤더에 있는 EntryPoint를 직접 호출하는 방법파일 다운로드1
11857정성태3/26/201919525VC++: 128. strncpy 사용 시 주의 사항(Linux / Windows)
11856정성태3/25/201919775VS.NET IDE: 134. 마이크로소프트의 CoreCLR 프로파일러 리눅스 예제를 Visual Studio F5 원격 디버깅하는 방법 [1]파일 다운로드1
11855정성태3/25/201921948개발 환경 구성: 436. 페이스북 HTTPS 인증을 localhost에서 테스트하는 방법
11854정성태3/25/201917597VS.NET IDE: 133. IIS Express로 호스팅하는 사이트를 https로 접근하는 방법
11853정성태3/24/201920401개발 환경 구성: 435. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면? - 두 번째 이야기 [1]
11852정성태3/20/201919618개발 환경 구성: 434. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면?파일 다운로드1
11851정성태3/19/201923365Linux: 8. C# - 리눅스 환경에서 DllImport 대신 라이브러리 동적 로드 처리 [2]
11850정성태3/18/201922422.NET Framework: 813. C# async 메서드에서 out/ref/in 유형의 인자를 사용하지 못하는 이유
11849정성태3/18/201921777.NET Framework: 812. pscp.exe 기능을 C#으로 제어하는 방법파일 다운로드1
11848정성태3/17/201918515스크립트: 14. 윈도우 CMD - 파일이 변경된 경우 파일명을 변경해 복사하고 싶다면?
11847정성태3/17/201922983Linux: 7. 리눅스 C/C++ - 공유 라이브러리 동적 로딩 후 export 함수 사용 방법파일 다운로드1
11846정성태3/15/201921630Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
11845정성태3/15/201921764Linux: 5. Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency) [3]
11844정성태3/14/201923094개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정 [1]파일 다운로드1
11843정성태3/14/201918038기타: 75. MSDN 웹 사이트를 기본으로 영문 페이지로 열고 싶다면?
11842정성태3/13/201916395개발 환경 구성: 433. 마이크로소프트의 CoreCLR 프로파일러 예제를 Visual Studio CMake로 빌드하는 방법 [1]파일 다운로드1
11841정성태3/13/201916697VS.NET IDE: 132. Visual Studio 2019 - CMake의 컴파일러를 기본 g++에서 clang++로 변경
11840정성태3/13/201918320오류 유형: 526. 윈도우 10 Ubuntu App 환경에서는 USB 외장 하드 접근 불가
11839정성태3/12/201922266디버깅 기술: 124. .NET Core 웹 앱을 호스팅하는 Azure App Services의 프로세스 메모리 덤프 및 windbg 분석 개요 [3]
11838정성태3/7/201925887.NET Framework: 811. (번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes [1]파일 다운로드1
11837정성태3/6/201939815기타: 74. 도서: 시작하세요! C# 7.3 프로그래밍 [10]
... 76  77  78  79  80  81  82  [83]  84  85  86  87  88  89  90  ...