Microsoft MVP성태의 닷넷 이야기
.NET Framework: 640. 닷넷 - 배열 크기의 한계 [링크 복사], [링크+제목 복사],
조회: 29985
글쓴 사람
정성태 (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 소스 코드를 봐야 알 수 있지 않을까 싶습니다. 이참에 '정환나라'님이 한번 보시고... 정리해 주시면... ^^
정성태

... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...
NoWriterDateCnt.TitleFile(s)
11274정성태8/22/201719329.NET Framework: 674. Thread 타입의 Suspend/Resume/Join 사용 관련 예외 처리
11273정성태8/22/201721624오류 유형: 415. 윈도우 업데이트 에러 Error 0x80070643
11272정성태8/21/201724748VS.NET IDE: 120. 비주얼 스튜디오 2017 버전 15.3.1 - C# 7.1 공개 [2]
11271정성태8/19/201719172VS.NET IDE: 119. Visual Studio 2017에서 .NET Core 2.0 프로젝트 환경 구성하는 방법
11270정성태8/17/201730626.NET Framework: 673. C#에서 enum을 boxing 없이 int로 변환하기 [2]
11269정성태8/17/201721426디버깅 기술: 93. windbg - 풀 덤프에서 .NET 스레드의 상태를 알아내는 방법
11268정성태8/14/201721007디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
11267정성태8/10/201725081.NET Framework: 672. 모노 개발 환경
11266정성태8/10/201724882.NET Framework: 671. C# 6.0 이상의 소스 코드를 Visual Studio 설치 없이 명령행에서 컴파일하는 방법
11265정성태8/10/201753127기타: 66. 도서: 시작하세요! C# 7.1 프로그래밍: 기본 문법부터 실전 예제까지 [11]
11264정성태8/9/201724016오류 유형: 414. UWP app을 signtool.exe로 서명 시 0x8007000b 오류 발생
11263정성태8/9/201719485오류 유형: 413. The C# project "..." is targeting ".NETFramework, Version=v4.0", which is not installed on this machine. [3]
11262정성태8/5/201718205오류 유형: 412. windbg - SOS does not support the current target architecture. [3]
11261정성태8/4/201720788디버깅 기술: 91. windbg - 풀 덤프 파일로부터 강력한 이름의 어셈블리 추출 후 사용하는 방법
11260정성태8/3/201718880.NET Framework: 670. C# - 실행 파일로부터 공개키를 추출하는 방법
11259정성태8/2/201718128.NET Framework: 669. 지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법
11258정성태8/1/201718897.NET Framework: 668. 지연 서명된 DLL과 서명된 DLL의 차이점파일 다운로드1
11257정성태7/31/201719129.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명파일 다운로드1
11256정성태7/25/201720594디버깅 기술: 90. windbg의 lm 명령으로 보이지 않는 .NET 4.0 ClassLibrary를 명시적으로 로드하는 방법 [1]
11255정성태7/18/201723165디버깅 기술: 89. Win32 Debug CRT Heap Internals의 0xBAADF00D 표시 재현 [1]파일 다운로드3
11254정성태7/17/201719487개발 환경 구성: 322. "Visual Studio Emulator for Android" 에뮬레이터를 "Android Studio"와 함께 쓰는 방법
11253정성태7/17/201719769Math: 21. "Coding the Matrix" 문제 2.5.1 풀이 [1]파일 다운로드1
11252정성태7/13/201718417오류 유형: 411. RTVS 또는 PTVS 실행 시 Could not load type 'Microsoft.VisualStudio.InteractiveWindow.Shell.IVsInteractiveWindowFactory2'
11251정성태7/13/201717078디버깅 기술: 88. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 (2)
11250정성태7/13/201720663디버깅 기술: 87. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 [1]
11249정성태7/12/201718467오류 유형: 410. LoadLibrary("[...].dll") failed - The specified procedure could not be found.
... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...