2009-02-05 6 views
15

jvm이 간단한 hello 환경을 위해 약 10MB의 메모리를 필요로하지만 clr이 필요하지 않은 이유는 무엇입니까? 여기서 트레이드 오프는 무엇입니까? 즉,이를 통해 JVM이 얻는 이득은 무엇입니까?jvm 디자인 결정

나는 내 머리 속에있는 질문을 전달하지 않기 때문에 조금 명확하게 설명하겠습니다. jvm과 clr 런타임 사이에는 구조적인 차이가 있습니다. jvm은 clr보다 상당히 큰 메모리 풋 프린트를 가지고 있습니다. 나는이 오버 헤드에 어떤 이점이 있다고 가정합니다. 그렇지 않으면 왜 존재할 것입니까? 나는이 두 가지 설계에서 절충점이 무엇인지 묻고있다. jvm이 메모리 오버 헤드에서 얻는 이점은 무엇입니까?

+1

오버 헤드가 있음을 어떻게 알 수 있습니까? 각각의 스켈레톤 프로그램을 만들어서 실행 했습니까? 작업 관리자에 따라 시작시 -Xmx256m -Xms256m을 사용하는 경우에도 약 7MB 정도만 가져갈 수 있습니다. –

+0

둘 다 사용했던 테스트 수업을 제공 할 수 있습니까? 이것은 문제를 재연하는 데 도움이 될 것이므로 좋은 대답을 줄 것입니다. –

+0

내 질문이 명확하지 않아서 방금 편집했다고 생각하지 않습니다. 테스트 클래스의 경우 간단한 HelloWorld 앱을 사용하십시오. – jshen

답변

6

나는 Java가 모든 것을 자체적으로 (플랫폼 독립성의 또 다른 측면) 수행해야한다는 한 가지 이유를 추측합니다. 예를 들어, Swing은 자신의 구성 요소를 처음부터 끌어오고, OS에 의존하지 않습니다. 그것은 모두 기억 속에 자리 잡아야합니다. 윈도우즈가 할 수있는 많은 것들이 있지만, 리눅스는 완전히 자바에 포함되어서는 안되며 (또는 다르게), 둘 다 똑같이 작동해야합니다.

Java는 항상 전체 라이브러리가 "링크되어 있으며"사용할 수 있다고 주장합니다. DLL을 사용하지 않기 때문에 (모든 플랫폼에서 사용 가능하지는 않을 것입니다.) 모든 것이 java에 의해로드되고 추적되어야합니다.

자바는 FPU가 종종 받아 들일 수없는 것으로 여겨지는 다른 결과를주기 때문에 자체의 부동 소수점을 사용합니다.

그래서 C#이 OS에 위임 할 수있는 모든 것들을 생각하면 Java가 OS에 대해 보상해야하는 모든 것들과 그 차이가 예상됩니다.

저는 2 개의 임베디드 플랫폼에서 java 앱을 실행했습니다. 하나는 실제로 스펙트럼을 그린 스펙트럼 분석기이고, 다른 하나는 셋톱 케이블 박스입니다.

두 경우 모두 최소한의 메모리 사용량은 문제가되지 않았습니다. Java 관련 문제가 있었지만 그 중 하나는 아니 었습니다. 인스턴스화 된 객체의 수와 스윙 페인팅 속도는이 경우 더 큰 이슈였습니다.

1

CLR은 OS의 일부로 계산되므로 작업 관리자는 응용 프로그램 프로세스에서 메모리 소비를보고하지 않습니다.

+0

유닉스에서 모노를 사용하는 경우 jvm의 경우 30에 비해 몇 메가 밖에 사용하지 않습니다 – jshen

+2

CLR이 각 프로세스 내부에서 시작되므로이 대답이 정확한지 의심 스럽습니다. – Austin

+1

오스틴 : 각 프로세스에는 CLR 인스턴스가 있습니다. CLR과 JRE 모두 읽기 전용 코드가 프로세스간에 공유됩니다. 질문은 다음과 같습니다. 코드가 각 프로세스 또는 프로세스가없는 것으로 계산됩니다. –

2

JVM은 메모리를 사용하는지 여부에 상관없이 모든 공유 라이브러리를 계산합니다.

작업 관리자는 프로그램의 메모리 사용량을보고 할 때 오히려 신뢰할 수 없습니다. 가이드로 받아 들여야합니다.

+1

요즘에도 4GB Vista 머신에 메모리가 부족하여 메모리가 부족합니다. 응용 프로그램에서 사용하는 1GB 미만을 표시합니다. –

+0

작업 관리자를 사용하지 않으므로 창을 사용하지 않습니다. – jshen

5

자바와 비슷하게 보입니다. 가상 메모리입니다.

USER  PID %CPU %MEM VSZ RSS TTY  STAT START TIME COMMAND 
amwise 20598 0.0 0.5 22052 5624 pts/3 Sl+ 14:59 0:00 mono Test.exe 
amwise 20601 0.0 0.7 214312 7284 pts/2 Sl+ 15:00 0:00 java Program 

"test"문자열을 인쇄하고 입력을 기다리는 테스트 프로그램을 C# 및 Java에서 만들었습니다. 필자는 RSS (Resident Set Size) 값이 메모리 사용량을보다 정확하게 표시한다고 생각합니다. 가상 메모리 사용 (VSZ)은 덜 의미가 있습니다.

내가 아는 것처럼 응용 프로그램은 실제로 실제 메모리를 사용하지 않고도 많은 가상 메모리를 예약 할 수 있습니다. 예를 들어 Windows의 VirtualAlloc 기능에 가상 메모리를 예약하거나 커밋하도록 요청할 수 있습니다.

편집 : alt text http://awise.us/images/mem.png

각 응용 프로그램은 getchar가 다음에 간단한의 printf했다 : 여기

내 창 상자에서 예쁜 그림이다. Java 및 CLR에 의한 많은 가상 메모리 사용. C 버전은 거의 아무것도 사용하지 않으므로 메모리 사용량은 상대적으로 적습니다.

나는 그것이 어느 쪽이든 정말로 중요하다고 생각하지 않습니다. 더 친숙한 플랫폼을 선택한 다음 메모리 낭비적인 끔찍한 코드를 작성하지 마십시오. 나는 그것이 잘 될 것이라고 확신한다.

편집 :

Microsoft에서 제공하는이 VMMap tool 메모리가가는 곳을 figureing에 유용 할 수 있습니다.

+2

유휴 프로세스의 RSS는 큰 방법이 아닙니다. –

+0

나는 어떤 플랫폼을 사용하는 것이 더 나은지 결정하려고하지 않습니다. 나는 그들이 왜 jvm 측에서 한 디자인 결정을했고, 그것으로 얻은 결과가 궁금합니다. – jshen

+0

프로세스 공간에서의 모든 메모리 사용은 가상입니다 (적어도 Windows에서는). 32 비트 OS에서 주소 공간은 2GB 코드와 2GB 데이터로 나뉩니다. Total Private bytes는 응용 프로그램의 데이터 주소 공간에 할당 된 양을 나타냅니다. OS는이 할당이 물리적 메모리와 어떻게 관련되는지를 관리합니다. –

5

Hello World 응용 프로그램의 초기 메모리 사용량 또는 사용 공간이 중요한지 여부는 알 수 없습니다. 차이점은 JVM/CLR이로드하는 라이브러리의 수와 크기 때문일 수 있습니다. 또한 가비지 콜렉션 풀에 사전 할당 된 많은 양의 메모리가있을 수 있습니다.

내가 아는 모든 응용 프로그램은 Hello World 기능을 훨씬 더 많이 사용합니다. 그러면 응용 프로그램을 실행하는 동안 수천 번 메모리가로드되고 해제됩니다.당신이 CLR 대 JVM의 메모리 사용률의 차이에 관심이 있다면, 여기

http://benpryor.com/blog/2006/05/04/jvm-vs-clr-memory-allocation/

Memory Management Case study (JVM & CLR)

메모리 관리 사례 연구는 파워 포인트에 좋은 정보와 링크의 몇 가지 있습니다. 매우 흥미로운 발표.

+0

분명히 분명히 내 질문을 말하지 않고있다. 나는 메모리 이용의 차이에 관심이 없다. 나는 왜 jvm이 필자가 사용했던 다른 모든 프로그래밍 언어 런타임보다 본질적으로 더 많은 메모리를 필요로하는지 알아 내려고하고있다. 나는 그것에 대한 이유가 있다고 가정하고, 그것이 무엇인지 궁금합니다. – jshen

+0

나는 그것이 너무 의도적인지 의심 스럽다. 응용 프로그램이 비즈니스 논리를 구현하고 일정 기간 동안 실행될 때 가상 컴퓨터 기반 언어의 진정한 힘이 표시됩니다. 시작 매개 변수 (초기 메모리 사용 및 시작 시간)는 일반적으로 2 차적인 중요성으로 간주됩니다. 내가 생각할 수있는 한 가지는 시작시로드되는 라이브러리의 초기 개수가 JVM과 CLR간에 다를 수 있다는 것입니다. JVM은 CLR로드를 더 많이 요구할 때 더 많이로드 할 수 있습니다. 더 오랜 시간 동안, 그다지 큰 차이는 없습니다. –

2

JVM은 rt.jar에서 실행할 때마다 불필요한 코어 클래스를 많이로드합니다. 안타깝게도, 내부 - 종속성 (java.lang < -> java.io) 자바 패키지는 부분적인 런타임 초기화를 어렵게 만든다. rt.jar 자체는 40MB 이상이 아니며 조회 및 압축 해제에 많은 시간이 필요합니다.

포스트 자바 6u10은 조금 더 똑똑한 것들을로드하는 것처럼 보입니다. (메모리에 필요한 데이터를 저장하고 빠른 시작을하기위한 jqs.exe = 자바 빠른 스타터 서비스가 있습니다.) 여전히 Java 7이 더 좋다고합니다.

Windows의 프로세스 탐색기는 개인 바이트를 올바르게보고합니다 (개인 바이트는 모든 dll에서 공유하지 않는 메모리 영역입니다).

약간 더 큰 성가심은 10 년 후에도 JVM이 여전히 64MB 메모리 사용을 기본값으로한다는 것입니다. 거의 언제나 -Xmx를 사용하는 것이 귀찮습니다. 파일 확장 지정 명령을 변경하지 않는 한 간단한 더블 클릭으로 항아리에서 까다로운 프로그램을 실행할 수 없습니다.