블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'CLR'에 해당되는 글 2

  1. 2010.05.12 CLR 메모리 구조 (노트)
  2. 2010.05.11 자바개발자가 본 .NET 프레임웍
 

CLR 메모리 구조 (노트)

프로그래밍/C# & .NET | 2010.05.12 00:01 | Posted by 조대협

CLR 메모리 참고 자료
http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/
에 있는데, JVM이 client모드와 server모드가 있듯이 workstation 모드와 server 모드 두개를 가지고 있다. (current and synchronous). 간략하게 정리하자면 concurrent mode는 JVM의 concurrent GC 모드와 유사하게 pause time을 최소화하는 것이고 주로 desk ap에서 응답 시간 위주로 튜닝하고자할때 사용되고, synchronous 모드는 JVM의 Thoughput collector와 비슷한 원리 같은데, pause를 주더라도 collection을 빨리하는 데 목적을 두고, 주로 Server ap에서(ASP.NET과 같은) 디폴트로 설정된다.
일단 GC 방법은 JVM과 유사한것 같고

The .NET collector has two main modes of operation: concurrent and synchronous (sometimes known as workstation and server). Concurrent garbage collection is used in desktop applications and synchronous is used in server applications such as ASP.NET by default.

In concurrent mode, .NET will try to avoid stopping the running program while a collection is in progress. This means that the total amount that the application can get done in a given period of time is less but the application won’t pause. It’s good for interactive applications where it’s important to give the impression to the user that the application is responding immediately.

In synchronous mode, .NET will suspend the running application while the garbage collector is running. This is actually more efficient overall than concurrent mode - garbage collection takes the same amount of time, but it doesn’t have to contend with the program continuing to run - but means that there can be noticeable pauses when a full collection has to be done.


메모리 Layout 역시 GC후에 Compaction 작업이 일어나면 Old Object를 Lower address로 옮긴다. 이렇게 해서 객체의 이동을 좀 줄이는 방식 같은데..  이 역시 Compaction을 사용하고 알고리즘은 JVM과 같게 Mark & Sweep을 사용한다.



위의 그림처럼 Heap 영역을 g0,g1,g2로 나누고 Old Object일수록 g2쪽에 놓는다. JVM의 New/Eden/Old 영역 사상과 좀 유사하다.어쨌거나  자세한 아키텍쳐는 뜯어봐야 겠고, Native Code에 의해서 Allocate되는등 특정 Address 위치에 Object가 Allocation되면 Pinned Object라고 해서 Fragmentation을 유발한다. 이건 Native Code도 같이 쓰니까는 어쩔 수 없는 것 같고.

GC 알고리즘이야 Root 객체에서 부터 Graph Traverse해가는 방식이라서 이건 유사한듯 보인다.
JVM에 Minor GC와 Full GC가 있는것 처럼 CLR에도 Partial Collection과  Full GC가 있다.
참고 : http://msdn.microsoft.com/en-us/library/ms973837.aspx
JVM에서 Minor GC가 New 영역을 Collection하는 거라면 CLR에서는 New한 Generation을 Collection 하는게 Partial Collection으로 이해된다. (g0 영역을 collection 하면 Partial)

Partial Collections

Unfortunately, the full garbage collection is simply too expensive to do every time, so now it's appropriate to discuss how having generations in the collection helps us out.

First let's consider an imaginary case where we are extraordinarily lucky. Let's suppose that there was a recent full collection and the heap is nicely compacted. Program execution resumes and some allocations happen. In fact, lots and lots of allocations happen and after enough allocations the memory management system decides it's time to collect.

Now here's where we get lucky. Suppose that in all of the time we were running since the last collection we didn't write on any of the older objects at all, only newly allocated, generation zero (gen0), objects have been written to. If this were to happen we would be in a great situation because we can simplify the garbage collection process massively.

Instead of our usual full collect we can just assume that all of the older objects (gen1, gen2) are still live—or at least enough of them are alive that it isn't worth looking at those objects. Furthermore, since none of them were written (remember how lucky we are?) there are no pointers from the older objects to the newer objects. So what we can do is look at all the roots like usual, and if any roots point to old objects just ignore those ones. For other roots (those pointing into gen0) we proceed as usual, following all the pointers. Whenever we find an internal pointer that goes back into the older objects, we ignore it.

When that process is done we will have visited every live object in gen0 without having visited any objects from the older generations. The gen0 objects can then be condemned as usual and we slide up just that region of memory, leaving the older objects undisturbed.

Now this is really a great situation for us because we know that most of the dead space is likely to be in younger objects where there is a great deal of churn. Many classes create temporary objects for their return values, temporary strings, and assorted other utility classes like enumerators and whatnot. Looking at just gen0 gives us an easy way to get back most of the dead space by looking at only very few of the objects.

Unfortunately, we're never lucky enough to use this approach, because at least some older objects are bound to change so that they point to new objects. If that happens it's not sufficient to just ignore them.


http://dotnetperls.com/garbage-collection 요건 .NET GC 내용을 그래프로 보는것 (HP JVM의 Jtune와 비슷)

조금 색다른것 중에 하나가 CLR 은 메모리 관리에 있어서 작은 객체영역과 85K가 넘는 대형 객체를 위한 영역을 나눠서 관리한다는 것이다. 일반적인 객체는 작은 객체 영역인 SOH (Small Object Heap)에 Allocation이 되고, 큰 객체(85K)이상은 LOH (Large Object Heap)에 Allocation이 된다. LOH는 G2 영역에 Allocation이 된다. Large Object는 오래 사용될것으로 예상되고 Collection상의 Overhead가 크기 때문에 Full GC 시에만 Collecting하기 위함이다.
LOH 영역은 Collection이 된후에도 Compaction이 되지 않고 Free Block으로 남아있고, LOH는 이 Free Block에 대한 List로 관리가 된다. 만약에 Free Block의 크기가 Allocation을 시도하고자 하는 Object 크기 보다 작을 경우 (Fragmentation으로 인해서) 추가로 메모리 Allocation을 요청할 수 있다. (이 메커니즘은 아직 이해안됨..). 모 하여간 이런 Large Object가 발생하는거는 주로 Buffer나 Array인 경우니까는 튜닝 가이드 보니까, 이런 Large Object에 의한 Fragmentation을 막기 위해서 Buffer는 되도록이면 재사용하라고 나와 있네 그랴.. 일단 LOH에 대한 상세한 자료는 http://msdn.microsoft.com/en-us/magazine/cc534993.aspx 여기

일단 호기심에서 한시간 정도 쭈욱 훝어보고 메모해놨는데, 실제 튜닝할려면 몇일 더 봐야 할듯.. 일단 다른것도 쭈욱 훝어 봐야 하니.. 링크만 걸어놓고..
패쓰~~

참고 자료
http://msdn.microsoft.com/en-us/library/ms973837.aspx
http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

'프로그래밍 > C# & .NET' 카테고리의 다른 글

Windows 7에서 IIS 설치하기  (1) 2010.05.13
.NET 튜닝 옵션  (0) 2010.05.12
CLR 메모리 구조 (노트)  (0) 2010.05.12
자바개발자가 본 .NET 프레임웍  (0) 2010.05.11
ApplicationDomain  (0) 2010.05.11
Microsoft Sync Framework (MSF)  (1) 2010.05.10

자바개발자가 본 .NET 프레임웍

프로그래밍/C# & .NET | 2010.05.11 23:21 | Posted by 조대협
.NET 프레임웍이란?

MS에서 개발한 프레임웍으로
  • 개발 환경 : 다양한 컴파일 환경과, C#,VB등의 언어를 지원하고 있다.
  • 개발 프레임웍
    • 다양한 라이브러리들을 제공한다. ASP.NET과 같은 MVC기반의 웹개발환경
    • WebForm과 같은 웹 UI환경
    • WPF와 같은 클라이언트 UI개발
    • WCF와 같은 통신 프레임웍
    •  ADO.NET과 같은 DB 접근용 개발 프레임웍등을 제공한다.
  • 런타임 프레임웍 : 자바와 유사하게, Virtual Machine과 같은 런타임환경을 지원한다.

이다.


.NET 프레임웍의 런타임 동작 방식
.NET으로 만들어진 프로그램은 컴파일된후 .exe 파일로 존재하는데, 이 exe 파일은 실제 실행 파일이 아니라 자바의 .class 파일 처럼 Machine에 종속적이지 않은 byte code와 같은 형태로 존재한다.  .NET에서는 byte code와 같은 중간 컴파일된 코드를 Managed Code라고 한다. C++이나 C를 이용해서 Machine depedent된 Native Code를 UnManaged Code라고 한다.
이 Managed Code는 일종의 Assembly 코드 처럼 Instruction들로 이루어 지는데, 이 Instruction을  MSIL (Microsoft Intermediate Language)라고 한다. C#,COBOL,VB등의 다양한 언어로 애플리케이션을 작성했다 하더라도, 1차 컴파일이 되면, 이 MSIL로 구성된 Managed Code로 컴파일이 되는 것이다. 이런 특징 때문에, .NET에서 제공되는 모든 라이브러리는 .NET 프레임웍을 사용하는 모든 언어에 공통적으로 재사용될 수 있다.

이 IL은 런타임에 JIT 컴파일러에 의해서 Machine code로 바뀌어서 실행이된다. .NET이 일종의 Runtime 실행환경(JVM처럼)이 되는 것인데, 이런 .NET의 Runtime 실행환경을 CLR (Common Lnauage Run-time)이라고 한다.
CLR은 JIT 컴파일러 이외에도 자체적인 가상 메모리 관리,Garbage Collection, Thread관리와 같이 .NET 애플리케이션에 대한 전반적인 실행환경을 제공하는데, 이러한 Runtime 환경이 있기 때문에, 이 포스트에 앞서 설명한 Application Domain같은 것이 구현이 가능하다.

전체적으로 구성을 보면 자바와 매우 유사하다. JVM과 같은 CLR 런타임 환경이 있고, CLR이 GC를 수행하는것도 상당히 유사하다. 또한 컴파일된 코드가 자바에서 byte code로 컴파일되는것 처럼 Managed Code라는 형태로 컴파일 된후에, Runtime에서 JIT에 의해서 Machine 코드로 컴파일되는 것도 유사하다.

아키텍쳐 상으로만 봤을때는 앞서 설명한(이전 포스트) Application Domain과 같은 Runtime 환경은 .NET쪽이 좀더 진보적인 형태같고, Hotspot 방식의 컴파일러를 사용하는 자바가 Runtime 컴파일 환경에서는 조금더 발전하지 않은가 싶다.

조금 의문이 있는 것은 자바의 경우 GC 타임에 대한 성능적 이슈가 크기 때문에, GC 튜닝이 매우 중요한데 반해서, GC를 사용하는 .NET에서는 GC 타임이나 튜닝에 대해서 들어본적이 없다. GC 성능이 매우 좋을 경우에나 가능한 일인데.. 이건 좀 더 찾아봐야 할듯..

참고 자료
http://www.devhood.com/training_modules/dist-a/Intro.NET/Intro.NET_pres_files/frame.htm


'프로그래밍 > C# & .NET' 카테고리의 다른 글

.NET 튜닝 옵션  (0) 2010.05.12
CLR 메모리 구조 (노트)  (0) 2010.05.12
자바개발자가 본 .NET 프레임웍  (0) 2010.05.11
ApplicationDomain  (0) 2010.05.11
Microsoft Sync Framework (MSF)  (1) 2010.05.10
ildasm (C# 디컴파일러)  (3) 2010.05.10