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

... 91  92  93  [94]  95  96  97  98  99  100  101  102  103  104  105  ...
NoWriterDateCnt.TitleFile(s)
11456정성태2/17/201825459.NET Framework: 731. C# - await을 Task 타입이 아닌 사용자 정의 타입에 적용하는 방법 [7]파일 다운로드1
11455정성태2/17/201814811오류 유형: 451. ASP.NET Core - An error occurred during the compilation of a resource required to process this request.
11454정성태2/12/201823581기타: 71. 만료된 Office 제품 키를 변경하는 방법
11453정성태1/31/201815264오류 유형: 450. Azure Cloud Services(classic) 배포 시 "Certificate with thumbprint ... doesn't exist." 오류 발생
11452정성태1/31/201820933기타: 70. 재현 가능한 최소한의 예제 프로젝트란? [3]파일 다운로드1
11451정성태1/24/201815524디버깅 기술: 111. windbg - x86 메모리 덤프 분석 시 닷넷 메서드의 호출 인자 값 확인
11450정성태1/24/201830013Windows: 146. PowerShell로 원격 프로세스(EXE, BAT) 실행하는 방법 [1]
11449정성태1/23/201818306오류 유형: 449. 단위 테스트 - Could not load file or assembly 'Microsoft.VisualStudio.QualityTools.VideoRecorderEngine' or one of its dependencies. [1]
11448정성태1/20/201815197오류 유형: 448. Fakes를 포함한 단위 테스트 프로젝트를 빌드 시 CS0619 관련 오류 발생
11447정성태1/20/201816713.NET Framework: 730. dotnet user-secrets 명령어 [2]파일 다운로드1
11446정성태1/20/201817977.NET Framework: 729. windbg로 살펴보는 GC heap의 Segment 구조 [2]파일 다운로드1
11445정성태1/20/201815486.NET Framework: 728. windbg - 눈으로 확인하는 Workstation GC / Server GC
11444정성태1/19/201816260VS.NET IDE: 125. Visual Studio에서 Selenium WebDriver를 이용한 웹 브라우저 단위 테스트 구성파일 다운로드1
11443정성태1/18/201816026VC++: 124. libuv 모듈 살펴 보기
11442정성태1/18/201814503개발 환경 구성: 353. ASP.NET Core 프로젝트의 "Enable unmanaged code debugging" 옵션 켜는 방법
11441정성태1/18/201813471오류 유형: 447. ASP.NET Core 배포 오류 - Ensure that restore has run and that you have included '...' in the TargetFrameworks for your project.
11440정성태1/17/201816518.NET Framework: 727. ASP.NET의 HttpContext.Current 구현에 대응하는 ASP.NET Core의 IHttpContextAccessor/HttpContextAccessor 사용법파일 다운로드1
11439정성태1/17/201820580기타: 69. C# - CPU 100% 부하 주는 프로그램파일 다운로드1
11438정성태1/17/201815805오류 유형: 446. Error CS0234 The type or namespace name 'ITuple' does not exist in the namespace
11437정성태1/17/201814847VS.NET IDE: 124. Platform Toolset 설정에 따른 Visual C++의 헤더 파일 기본 디렉터리
11436정성태1/16/201816823개발 환경 구성: 352. ASP.NET Core (EXE) 프로세스가 IIS에서 호스팅되는 방법 - ASP.NET Core Module(AspNetCoreModule) [4]
11435정성태1/16/201817799개발 환경 구성: 351. OWIN 웹 서버(EXE)를 IIS에서 호스팅하는 방법 - HttpPlatformHandler (Reverse Proxy)파일 다운로드2
11434정성태1/15/201818178개발 환경 구성: 350. 사용자 정의 웹 서버(EXE)를 IIS에서 호스팅하는 방법 - HttpPlatformHandler (Reverse Proxy)파일 다운로드2
11433정성태1/15/201816326개발 환경 구성: 349. dotnet ef 명령어 사용을 위한 준비
11432정성태1/11/201821070.NET Framework: 726. WPF + Direct2D + SharpDX 출력 C# 예제파일 다운로드2
11431정성태1/11/201819723.NET Framework: 725. C# - 동기 방식이면서 비동기 메서드(awaitable)처럼 구현한 사례 [9]
... 91  92  93  [94]  95  96  97  98  99  100  101  102  103  104  105  ...