[java] Windows XP의 Java 최대 메모리

32 비트 Windows XP (Java 1.4, 1.5 및 1.6)에서 실행되는 Java SE에 대해 항상 1400MB를 할당 할 수있었습니다.

java -Xmx1400m ...

오늘 저는 Java 1.5_16 및 1.6.0_07을 사용하는 새 Windows XP 시스템에서 동일한 옵션을 시도했지만 오류가 발생했습니다.

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

시행 착오를 통해 1200 메가 바이트가이 컴퓨터에 할당 할 수있는 최대 용량 인 것 같습니다.

한 기계가 1400을 허용하고 다른 기계가 1200 만 허용하는 이유에 대한 아이디어가 있습니까?

편집 : 컴퓨터에는 Windows가 인식 할 수있는 약 3.5GB의 4GB RAM이 있습니다.



답변

Windows에는 가상 메모리 관리 기능이 있으며 JVM 에는 주소 공간에서 연속적인 메모리 만 필요 합니다 . 따라서 시스템에서 실행되는 다른 프로그램이 반드시 힙 크기에 영향을주는 것은 아닙니다. 당신의 길을 가로막는 것은 당신의 주소 공간에로드되는 DLL들입니다. 안타깝게도 연결 중에 DLL의 재배치를 최소화하는 Windows의 최적화로 인해 주소 공간이 조각화 될 가능성이 높아집니다. 일반적인 항목 외에 주소 공간에 침입 할 가능성이있는 항목에는 보안 소프트웨어, CBT 소프트웨어, 스파이웨어 및 기타 형태의 맬웨어가 포함됩니다. 차이의 가능한 원인은 다른 보안 패치, C 런타임 버전 등입니다. 장치 드라이버 및 기타 커널 비트에는 자체 주소 공간이 있습니다 (4GB 32 비트 공간의 다른 2GB).

당신은 보다 컴팩트 한 주소 공간에 DLL의를 리베이스 노력에 당신의 JVM 과정과 모습에 DLL 바인딩을 통과하려고합니다. 재미 없지만 절망적이라면 …

또는 64 비트 Windows 및 64 비트 JVM으로 전환 할 수 있습니다. 다른 사람들이 제안한 것에도 불구하고 더 많은 RAM을 차지하지만 훨씬 더 연속적인 가상 주소 공간을 갖게되며 2GB를 연속적으로 할당하는 것은 사소한 일입니다.


답변

이것은 연속적인 메모리와 관련이 있습니다.

다음 은 “VM 신”이 전한 질문을 온라인 에서 찾은 정보입니다 .

힙에 대해 연속적인 메모리 영역이 필요한 이유는 힙의 시작부터 (스케일 된) 오프셋에 의해 인덱싱되는 여러 측면 데이터 구조가 있기 때문입니다. 예를 들어, 512 바이트의 힙마다 1 바이트가있는 “카드 표시 배열”을 사용하여 개체 참조 업데이트를 추적합니다. 힙에 참조를 저장할 때 카드 마크 배열의 해당 바이트를 표시해야합니다. 상점의 목적지 주소를 오른쪽으로 이동하고이를 사용하여 카드 마크 배열을 인덱싱합니다. 자바에서 할 수없는 재미있는 어드레싱 게임은 C ++로 플레이해야합니다.

보통 우리는 적당한 연속 영역을 얻는 데 문제가 없습니다 (Windohs에서 최대 약 1.5GB, Solaris에서 최대 약 3.8GB. YMMV.). Windohs에서 문제는 대부분 JVM이 시작되기 전에로드되어 주소 공간을 분할하는 라이브러리가 있다는 것입니다. / 3GB 스위치를 사용하면 해당 라이브러리를 리베이스하지 않으므로 여전히 문제가됩니다.

청크 힙을 만드는 방법을 알고 있지만이를 사용하는 데 약간의 오버 헤드가 있습니다. 32 비트 JVM에서 더 큰 힙보다 더 빠른 스토리지 관리에 대한 요청이 더 많습니다. 정말로 큰 힙을 원한다면 64 비트 JVM으로 전환하십시오. 우리는 여전히 연속적인 메모리가 필요하지만 64 비트 주소 공간에서 얻는 것이 훨씬 쉽습니다.


답변

Windows의 Java 힙 크기 제한은 다음과 같습니다.

  • 32 비트 Java에서 가능한 최대 힙 크기 : 1.8GB
  • 32 비트 Java에서 권장되는 힙 크기 제한 : 1.5GB (또는 / 3GB 옵션의 경우 1.8GB )

이것은 더 큰 Java 힙을 얻는 데 도움이되지 않지만 이제 이러한 값을 넘어 설 수 없다는 것을 알고 있습니다.


답변

인접하지 않은 힙을 처리 할 수있는 Oracle JRockit 은 / 3GB 스위치가있는 Windows 2003 / XP에서 2.85GB의 Java 힙 크기를 가질 수 있습니다. 단편화는 Java 힙의 크기에 상당한 영향을 미칠 수 있습니다.


답변

JVM은 연속적인 메모리를 필요로하며, 실행중인 다른 항목, 이전에 실행중인 항목 및 Windows가 메모리를 관리하는 방법에 따라 최대 1.4GB의 연속 메모리를 확보 할 수 있습니다. 64 비트 Windows는 더 큰 힙을 허용 할 것이라고 생각합니다.


답변

Sun의 JVM에는 연속적인 메모리가 필요합니다. 따라서 사용 가능한 메모리의 최대 양은 메모리 조각화에 의해 결정됩니다. 특히 드라이버의 dll은 미리 정의 된 기본 주소로로드 할 때 메모리를 조각화하는 경향이 있습니다. 따라서 하드웨어와 해당 드라이버는 얻을 수있는 메모리 양을 결정합니다.

이에 대한 두 가지 소스와 썬 엔지니어의 성명 : 포럼 블로그

어쩌면 다른 JVM? Harmony 를 사용해 보셨습니까 ? 나는 그들이 비 연속적인 기억을 허용 할 계획이라고 생각한다.


답변

이 응답에 암시 된대로 Windows가 구성되는 방식과 더 관련이 있다고 생각합니다.
Java -Xmx 옵션

추가 테스트 : 768MB의 물리적 RAM (가상 메모리 포함) 만있는 기존 Windows XP 시스템에 1300MB를 할당 할 수있었습니다. 2GB RAM 시스템에서는 1220MB 만 얻을 수 있습니다. 여러 다른 회사 컴퓨터 (구 Windows XP 사용)에서 1400MB를 얻을 수있었습니다. 1220MB 제한이있는 컴퓨터는 매우 새롭기 때문에 (방금 Dell에서 구입) 새 Windows 및 DLL (Windows XP Pro 버전 2002 SP2 실행)이있을 수 있습니다.