요번 포스팅에는 저번 포스팅에 이어 HotspotJVM의 Garbage Collector에 대해 알아보도록 하겠다. 


HotspotJVM의 Garbage Collector에는 5가지 종류의 Collector들이 존재한다. 


1.Serial Collector 

2.Parallel Collector

3.Parallel Compaction Collector 

4. CMS Collector 

5. Garbage First Collector 


제일 먼저 Serial Collector에 대해 알아보자. 


1.Serial Collector 


Young Generation과 Old Generation의 Garbage Collection  모두를  Serial로 처리하는 방식이다. 

1개의 Thread를 가지고 GC수행하고, Hotspot JVM의 가장 기본적인 collector이다. 


Young Generation – Generational Algorithm의 동작원리를 살펴볼까?


Minor GC가  발생 하면  


Minor GC가  발생결과 


old Generation – Mark and Compacting 알고리즘의 동작원리를 살펴볼까?


Serial Collector가 나온 이후 IT환경이 급변하여, heap의 크기를 점점 크게 설정해야 하는 상황이 도래함에 따라 Serial Collector의 한계가 드러나기 시작하였다.가장 큰 문제는 GC를 수행 하는 중에 나타나는 suspend현상인데 

heap이 커짐에 따라 suspend현상은 두드러졌고 application은 점점 실시간에 가까운 성능을 요구하고 있었다. 


그래서 두가지 전략으로 분화 되었다.


*Throughput Collector

모든 리소스를 투입하여 garbage collector를 빨리 끝내자는 전략.

이는 대용량의 heap에 적합하며,

이 전략을 채택한 garbage collector는 병렬 처리를 수행하는 방법으로 채택. 


*Low Pause Collector 

Suspend를 분산시켜 체감 pause time을 줄이자는 전략. 

실시간을 요구하는 application에 적합. 이 전략을 채택한 Garbage Collector는 GC를 수행하는

동시에 application의 작업도 수행(concurrent)하는 방식을 사용하고 있음.


2.Parallel Collector 


Throughput Collector중 하나이다.
많은 CPU를 동원하여 Garbage Collection시간을 단축 시키자는 아이디어가 parallel collector로 구체화 되었고.
Multi-Thread가 동시에 Garbage Collection을 수행한다. 단 young generation에만 국한된다.

Young Generation은 Parallel Copy Algorithm을 사용한다.


*여기서 잠깐 


메모리의 특성상 같은 메모리 공간을 두 Thread혹은 Process가 접근하게 되면 Corruption이 발생!

이러한 Corruption을 회피하기 위해 동기화 작업이 수반되어야 하는데 이 경우 promotion의 성능이 떨어진다. 


Hotspot은 이를 위해 PLAB(Parallel Local Allocation Buffer)이라는 Promotion Buffer를 마련하였다.

Promotion Buffer란 Garbage Collection Thread가 Promotion시 배타적으로 사용하기 위해 Thread마다 

Old Generation의 일정 부분을 할당해 놓는 것을 말한다.



하지만 많은 수의 Thread가 자신의 buffer를 할당 받은 채 사용되지 않거나 

어쩔 수 없이 발생하는 buffer내의 자투리 공간이 heap단편화의 원인이 될 수도 있다.

이 문제가 발생할 경우 GC Thread를 감소 시키거나 Old Generation의 size를 늘이는 방범으로 문제를 회피할 수 있다.


Old Generation은 Mark-and-Compating 알고리즘을 사용한다.


3.Parallel Compaction Collector


Parallel Collector에서 Old Generation에 새로운 algorithm을 추가한 업그레이드 개념이다.

Oracle에서도 향후 Parallel Collector를 대체 할 수 있다는 전망을 내놓고 있다.

Multi CPU에 유리하고 Old Generation의 Collection시간을 감소시켜 전체적인 효율을 증가시킨다. 


Young Generation은 Parallel Copy Algorithm을 사용한다.

Old Generation은 Parallel Compaction Algorithm을 사용한다. 









4. CMS Collector


Pause Time Goal에 맞는 collector이다.

CMS Collector는 Garbage Collection시 수반되는 suspend time을 적절하게 분산하여 응답시간을 개선하는 방식을 사용한다.

Young Generation에서는 Parallel Collector와 동일한 Parallel Copy Algorithm

Old Generation에서는 Concurrent Mark-Sweep Algorithm을 사용한다. 





하지만 단편화 문제 발생, 이를 해결하기 위해 freelist를 사용하여 young generation에서 promotion된 

object와 크기가 비슷한 free space를 탐색하는 방법 고안하였다.

그러나 Young Generation의 부담만 가중되었다.





5. Garbage First Collector 


CMS GC를 대체하기 위해서 만들어 졌다. 

물리적인 Generation의 구분을 없애고 전체 Heap을   1Mb~32Mb단위의 Region으로 재편하였다.

Garbage First라는 말대로 Garbage로만 꽉 차있는 Region부터 GC를 시작한다.

Concurrent + Parallel + Compacting의 조합이다.



이렇게 Hotspot JVM의 Garbage Collector의 종류의 대해 알아보았다. 

끝!




참조문헌 

http://blog.takipi.com/garbage-collectors-serial-vs-parallel-vs-cms-vs-the-g1-and-whats-new-in-java-8/

http://www.omsn.de/blog/brief-comparison-of-java-7-hotspot-garbage-collectors

Java Performance Fundamental 김한도 지음 ㈜엑셈 

http://helloworld.naver.com/helloworld/textyle/1329

http://blog.jelastic.com/2013/01/24/the-truth-about-paas-vertical-scaling-and-why-you-are-being-oversold/

https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2Ftech%2Findex-jsp-140228.html&ei=MMXaVL2TJOe5mwWZnoCADw&usg=AFQjCNHhFj3D5-BfVBPuZ6JL7JF7PCX-UA&sig2=z4gqAR4bu7LA-7IN2lLwbg&bvm=bv.85761416,d.dGc&cad=rja

http://www.infoq.com/articles/Java_Garbage_Collection_Distilled

http://blog.novatec-gmbh.de/g1-action-better-cms/


 




Posted by 알 수 없는 사용자
,

오랫만에 크롬 웹스토어를 둘러보던중 MS Office관련 앱들을 발견하였다. 

OneDrive에서 연동도 가능하고, Word, OneNote, PowerPointer, Excel등 MS Office의 주요 프로그램들을 각각 사용 가능하다. 구글에서 제공하는 Google Docs는 편집의 한계가 있어서 조금 아쉬웠는데, 마침 이 문서 편집기를 알게 되었다. 

이번 포스팅에서는 Word Online에 대해 리뷰해 보겠다.


크롬 웹스토어에서 MS Office라고 검색을 해 보았다. Word Online을 크롭 앱에 추가한다.

<그림1. 크롬 웹스토어와 앱 실행>


Word Online을 시작하게 되면 아래와 같은 페이지가 뜬다. OneDrive를 사용하게 되면 파일 업로드도 가능하며, 새 파일을 만들수도 있다.

<그림 2. Word Online 실행>


우리가 봐왔던 MS Office Word와 똑같다!!!!! 

<그림 3. 새문서>

우와, 훌륭하다! 우클릭 편집이 가능하다. 이정도의 퀄리티라면 사용해줄 가치가 있다.

<그림 4. 우클릭 편집 옵션>

기존에 편집된 파일을 클릭을하게되면 컴퓨터에 설치된 Word프로그램에서 편집할것인지 Word Online에서 편집할것인지 선택이 가능하다.

<그림 5. 편집프로그램 선택>


Word Online을 선택하여 재편집이 가능하고, 파일은 One Drive에 자동 저장이 된다. 

<그림 6. 재편집>

<그림 7. 표 삽입>

<그림 8. 이미지 삽입>

<그림 9. 이미지 편집>


Word의 기본적인 기능을 제공하기 때문에, MS Office가 익숙한 사용자들에게는 유용한 프로그램인것같다.

특히, 데스크톱에 MS Office가 없는데 급히 문서 수정을 하거나 문서를 열람해야 되는 상황이 발생한경우, 크롬브라우저하나면 해결 가능하기때문에 아주 매력적인 온라인 문서 편집기라고 생각된다. 

크롬브라우저를 사용한다면, Must have App이라고 추천한다.

'Newbie's Log' 카테고리의 다른 글

phpMyAdmin 설치 및 사용하기  (0) 2015.02.26
Garbage Collection -part 2  (0) 2015.02.25
Garbage Collection -part 1  (0) 2015.02.25
POST vs PUT  (1) 2015.02.08
Unity 3D 인터페이스3  (0) 2014.12.09
Posted by 알 수 없는 사용자
,

2014년 하고 싶은 일 중 하나가 전공 관련 스터디 해보기였다. 

그러던 중 한 개발자 커뮤니티에서 스터디원을 모집했는데  ‘JAVA 그리고 JVM’이라는 스터디를 선택했고,

6개월간의 스터디 기간 동안 배웠던 내용 중 하나가 바로 Garbage Collection이다.

그래서 오늘은 배운내용도 공유할겸 Garbage Collection에 대해 간단히 소개해 보는 시간을 갖도록 하겠다. 


1.Garbage Collection이란 ? 


“Heap storage for objects is reclaimed by an automatic

storage management system(typically a garbage collector);

objects are never explicitly deallocated.”

--Java Virtual Machine Speculation, Section 3.5.3[JVMS2 1999]


2.Garbage Collection의 대상


Garbage Collection은 Garbage를 모으는 작업이다.

그럼 Garbage를 정의하고 넘어가면, Heap과 Method Area에서 사용되지 않는 Object를 의미하는데,

사용되지 않는 다는 의미를 어디까지 볼 것이냐는 문제가 있다.

현재 사용 여부는 Root Set과의 관계로 판단하는데  

Root Set에서 어떤 식으로든 Reference관계가 있다면 Reachable Object.

즉 현재 사용하고 있는 Object로 간주하고 이렇게 판단해서 Reachable Object가 아니면 Garbage

Collection의 대상이 된다.




*여기서 Root Set이란 

한 객체는 여러 다른 객체를 참조하고, 참조된 다른 객체들도 마찬가지로 또 다른 객체들을 참조할 수 있

으므로 객체들은 참조 사슬을 이룬다. 이런 상황에서 유효한 참조 여부를 파악하려면 항상 유효한 최초

의 참조가 있어야 하는데 이를 객체 참조의 root set이라고 한다.


3.Garbage Collection과 단편화 문제

새로운 Object의 할당을 위해 한정된 Heap공간을 재활용하려는 목적으로 수행한다.

재활용을 위해 수행된 메모리의 해지는 할당한 그 자리에서 이루어지기 때문에 Garbage가 빠져 나간자

리는 듬성듬성 해지는데 Heap의 단편화(Fragmentation)발생한다.  

이러한 현상을 방지하기 위해 Compaction과 같은 Algorithm을 사용한다. 


다시한번 정리하면 Garbage Collection이란 

Heap을 재활용하기 위해 Root Set에서 참조되지 않는 Object를 없애 

가용한 공간을 만드는 작업을 말한다.  


이제는 Hotspot JVM의 Garbage Collection 소개해볼까 한다. 

Garbage Collector는 두 가지 가설 하에 만들어지는데 아래와 같다. 



--대부분의 객체는 금방 접근 불가능 상태가 된다. – high infant mortality

--오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.


이러한 가설을 ‘weak generational Hypothesis’이라 하고 

이러한 가설의 장점을 최대한 살리기 위해 Hotspot JVM에서는 크게 2개로 물리적 공간을 나누었다. 



Young 영역(Yong Generation 영역):

  


새롭게 생성한 객체의 대부분이 여기에 위치.대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많

은 객체가 Young 영역에 생성되었다가 사라짐.이 영역에서 객체가 사라질때 Minor GC가 발생한다고 말함.



Old 영역(Old Generation 영역): 


접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사됨. 대부분 Young 영역보다 크

게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생. 이 영역에서 객체가 사라질 때 Major GC(혹

은 Full GC)가 발생한다고 말함.




*여기서 잠깐 


Old 영역에 있는 객체가 Young 영역의 객체를 참조하는 경우가 있을 때에는 어떻게 처리될까?


Card Table이라는 장치를 마련했는데  

Card Table 이란 Old Generation의 메모리를 대표하는 별도의 메모리 구조를 의미한다. 

만약  Young Object를 참조한 Old Object가 있다면 그 Old Object 시작주소에 해당하는 카드를 Dirty로 

표시하고, 만약 이 Reference가 해제되면 Dirty 표시가 사라진다.

Card Table에 Card들을 늘어 놓고 뒤집어 가며 Reference의 존재 여부를 한 눈에 파악할 수 있게 해준다.


여기까지 정리하고,

다음시간에는 Hotspot JVM의 Garbage Collector에 대해 알아보도록 하겠다. 


참조문헌:


•http://blog.takipi.com/garbage-collectors-serial-vs-parallel-vs-cms-vs-the-g1-and-whats-new-in-java-8/

•http://www.omsn.de/blog/brief-comparison-of-java-7-hotspot-garbage-collectors

•Java Performance Fundamental 김한도 지음 ㈜엑셈

•http://helloworld.naver.com/helloworld/textyle/1329

•http://blog.jelastic.com/2013/01/24/the-truth-about-paas-vertical-scaling-and-why-you-are-being-oversold/

•https://www.google.co.kr/urlsa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CCUQFjAA&url=http%3A%2F%2Fwww.oracle.com%2Ftechnetwork%2Fjava%2Fjavase%2Ftech%2Findex-jsp-140228.html&ei=MMXaVL2TJOe5mwWZnoCADw&usg=AFQjCNHhFj3D5-BfVBPuZ6JL7JF7PCX-UA&sig2=z4gqAR4bu7LA-7IN2lLwbg&bvm=bv.85761416,d.dGc&cad=rja

•http://www.infoq.com/articles/Java_Garbage_Collection_Distilled


'Newbie's Log' 카테고리의 다른 글

Garbage Collection -part 2  (0) 2015.02.25
크롬 브라우저로 MS Office 사용하기.  (0) 2015.02.25
POST vs PUT  (1) 2015.02.08
Unity 3D 인터페이스3  (0) 2014.12.09
Unity 3D 인터페이스2  (0) 2014.12.08
Posted by 알 수 없는 사용자
,

POST vs PUT

Newbie's Log 2015. 2. 8. 19:31

얼마전에 어떤분께서 REST의 POST와 PUT의 차이점을 물어보았다. POST는 들어도 보고 사용도 해보았지만, PUT은 처음 들은 용어였다. 솔직히 POST와 PUT이 무엇인지 몰라서 잘 모르겠다고 대답하였다. 

그게 뭐냐고 되물었더니 다음과 같이 말했다.

POST와 PUT은 CRUD로직중 Create와 Update의 속성을 가진 http메소드 입니다.


위의 설명만으로는 조금 이해하기 어려웠다.  더 구체적인 설명을 찾기 위해 구글검색을 통해 알아보았다. 일단 POST와 PUT은 REST에서 사용되는 Method이다. REST에 대한 설명은 아주 자세히 많은 포스팅에 나와있었다. 

이번 포스팅에서는 POST와 PUT에 관련된 내용을 이야기 해 보겠다.


REST란 무엇일까? 

REST란, REpresentational State Transfer 의 약자로, 통신 규약이나 표준 또는 스펙이 아니라 분산 하이퍼미디어 시스템을 위한 www 같은 소프트웨어 아키텍처의 한 형식이며 네트워크 상에서 클라이언트와 서버 사이의 통신 방식이다. REST 라는 용어는 2000년 로이필딩(Roy Fielding) 박사의 논문에서 처음 소개되었다.

REST는 표준이 아니고, HTTP통신 모델만 지원한다. 하지만 플랫폼과 프로그래밍 언어에 독립적이고, 개발하기 단순하기 때문에 많이 사용되고 있다.

REST는 기본 HTTP 프로토콜의 메소드인 GET/PUT/POST/DELETE를 이용하여 서비스 제공자에게 서비스를 요청하는 방식이다. 서비스 제공자는 요청받은 서비스의 리소스를 다양한 형태(JSON, XML, RSS)로 반환해준다.

Method 

CRUD 

 Idempotent

POST

Update

No

GET

Read

Yes

PUT

Create

Yes

DELETE

Delete

Yes

<표 1. Method, CRUD, Idempotent>


위의 테이블에서도 볼 수 있듯이, POST는 생성, PUT은 업데이트를 할 수 있다.

하지만 언제 POST와 PUT을 사용하여야 할까?

두가지가 혼동된다면 크게 두가지를 생각하면 된다.

1) 멱등성 

2) 리소스 결정권

멱등성 (Idempotent)

Idempotent는 여러 번 수행을 해도 결과가 같은 경우를 의미한다. 예를 들면, a++는 Idempotent 하지 않다. (호출시마다 값이 증가 되기 때문에) 하지만, a=4와 같은 명령은 반복적으로 수행해도 Idempotent하다. (값이 같기 때문에)

POST 연산의 경우에는 리소스를 추가하는 연산이기 때문에, Idempotent하지 않지만 PUT은 반복 수행해도 Idempotent 하다. 

리소스 결정권

URI가 "서버"에 의해 결정되는가?   “클라이언트"에 의해 결정되는가?”의 두가지 물음에따라 POST 또는 PUT으로 결정된다.

 POST의 경우에는 클라이언트가 실제 저장해야할 리소스 위치를 모르므로 서버에서 처리 하도록 하게 한다. 

POST /articles HTTP/1.1 

<article>
    <title>blue stapler</title> 
    <price currency="eur">7.50</price> 
</article>
HTTP/1.1 201 Created Location: /articles/63636 

PUT을 사용하면 클라이언트가 이미 변경 대상 리소스의 위치를 알고 있어서, 특정 업데이트 대상 리소스를 갱신할 수 있다.

PUT /article/1234 HTTP/1.1 

<article>
    <title>red stapler</title>
    <price currency="eur">12.50</price>
</article>


결론

멱등성을 갖지 않고 리소스를 서버가 결정해주면 POST, 멱등성을 가지고 있으면서 리소스를 클라이언트가 결정하면 PUT이다. 헷갈릴 수 있는 주제이지만, 멱등성과 리소스 결정권만 잘 생각해 보면 POST와 PUT의 구분은 쉽게 할 수 있을 것 같다.


참고 자료:

http://ko.wikipedia.org/wiki/REST

http://www.slideshare.net/yjaeseok/soap-rest

http://gis.seoul.go.kr/GisWebDataStore/Gis_Edu/html/S1112/SGIS-HTML.jsp?sgis=1112&pgis=0203

http://www.devblog.kr/r/8y0gFPAvJ2Y8X93raWlrmu9ZEIWcsKEvfFjKV

http://blog.geekple.com/2012/11/26/http-put-post/

http://restcookbook.com/HTTP%20Methods/put-vs-post/

'Newbie's Log' 카테고리의 다른 글

크롬 브라우저로 MS Office 사용하기.  (0) 2015.02.25
Garbage Collection -part 1  (0) 2015.02.25
Unity 3D 인터페이스3  (0) 2014.12.09
Unity 3D 인터페이스2  (0) 2014.12.08
Java와 JVM -4  (0) 2014.12.06
Posted by 알 수 없는 사용자
,


이번 포스팅에서는 Unity 인터페이스에 대한 긴 여정의 끝이 되겠다. 툴바와 피봇/센터, 단축키 설정을 설명하고 Unity 인터페이스에 대한 설명은 마치도록 하겠다. (지난 인터페이스에 대한 설명을 참조하고 싶다면 여기를 클릭!)

아래 그림이 기억나지 않는다면 지난 포스팅들을 다시 보고오길 바란다. 벌써 세번째 나오는 그림으로 Unity의 기본 인터페이스 이다.

가운데에 있는 뷰에대한 설명은 지난 포스팅으로써 막을 내렸고, 이번 포스팅에서는 먼저 가장 위에 보이는 툴바에대해 설명하도록 하겠다.



 Unity 인터페이스 3


툴바 (Tool bar)

툴바는 아래 그림과 같이 다섯개의 기능으로 나누어져 있다.

Transform 툴

Transform 툴은 디자인시 가장 많이 사용하는 버튼으로서 단축키를 알아두면 엄청 편리하다! 단축키는 왼쪽부터 Q, W, E, R이다.

  • 이동 툴 버튼 : 마우스 커서가 손가락 모양으로 바뀌며, Scene 뷰의 화면을 이동시킬 수 있다. (단축키 Q)

 

  • Transform 툴 버튼 : 선택한 게임 오브젝트의 3차원 좌표축이 표시되고, 해당 축을 클릭 후 드래그하면 선택한 축의 방향으로 이동 시킬 수 있다. (단축키 W)

 

  • Rotate 툴 버튼 : 선택한 객체를 회전 시킨다. (단축키 E)


  • Scale 툴 버튼 : 선택한 객체의 스케일을 변경시킨다. (단축키 R)


피봇 (Pivot) / 센터 (Center)


피봇/센터 툴 버튼은 선택한 3D모델의 중심 좌표를 어떻게 표시할 것인지에 대한 옵션이다. 토글 방식으로 전환되고, 피봇 옵션은 3D 모델링 툴에서 모델링 할 때 설정한 원점 좌표의 좌표축에 표시되며, 센터 옵션으로 설정하면 3D 모델의중앙에 좌표축을 표시한다. 단축키는 Z이며, 실행시 영향을 미치지 않는다.


(1) 로컬/글로벌(Local/Global)

로컬/글로벌 툴 버튼은 선택한 게임 오브젝트의 좌표축을 로컬 좌표(Local Coordinate) 또는 글로벌 좌표(Global Coordinate)로 표시하는 옵션이다. 토클 방식으로 전환되며 글로벌 좌표는 Scene 뷰의 오른쪽 상단에있는 기즈모로 표시한다. 


(2) 레이어(Layers)

Scene 뷰에 있는 모든 오브젝트는 레이어를 지정할 수 있다. 툴 바의 레이어 옵션은 특정 레이어만 선택적으로 Scene 뷰에 표시할 수 있다.

만약 Nothing으로 설정하면 Scene 뷰에 아무것도 표시되지 않으므로 주의해야 한다.


(3) 레이아웃(Layout)

툴바의 오른쪽 상단에 레이아웃 옵션을 클릭하면 여러 형태의 레이아웃을 드롭다운 메뉴에서 선택할수 있으며, 이렇게 뷰를 자유롭게 배치할 수 있다는 것이 Unity의 장점 중 하나이기도 하다.

자신이 레이아웃을 저장하면, 레이아웃 드롭다운 메뉴에 표시되며 선택하면 저장된 레이아웃으로 유니티 IDE가 변경된다.


단축키 설정

 Unity 단축키 설정은 'Unity Preferences'창에서 설정한다. 맥은 'Unity → Preferences...', 윈도우는 'Edit → Preferences...'으로 들어갈 수 있다. Unity Preferences창의 Keys 탭에서는 기본적인 단축키를 설정할 수 있다.


마무리하며..

총 세번을 걸쳐 Unity에 대한 인터페이스를 자세하게 알아보았다. 다음 시간에는 이를 바탕으로 예제를 하나 구현해 볼까 한다. 처음 해보는 예제이기 때문에 너무 복잡하고 어렵지 않으니 잘 따라올 수 있으리라 생각한다.




출처   절대강좌! 유니티4, 위키북스 출판, 이재현 지음

'Newbie's Log' 카테고리의 다른 글

Garbage Collection -part 1  (0) 2015.02.25
POST vs PUT  (1) 2015.02.08
Unity 3D 인터페이스2  (0) 2014.12.08
Java와 JVM -4  (0) 2014.12.06
2014 공개 소프트웨어 <실시간 데이터분석 오픈소스 프로젝트> 참가 후기  (0) 2014.11.24
Posted by 알 수 없는 사용자
,

지난 포스팅에 이어 Unity 3D의 인터페이스에대해 알아보도록 하겠다. 

지난 포스팅에서는 Unity의 인터페이스 중 뷰에대해 다루었으며, 그중에서도 Project 뷰와 Scene 뷰에대해 알아보았다. 이번 포스팅에서는 Project 뷰와 Scene 뷰에 이어 Hierarchy 뷰와 Inspector 뷰, Console 뷰에대해 알아보겠으며, 다음 포스팅에서 툴바와 피봇/센터, 단축키 설정을 설명하고 인터페이스에 대해 마치도록하겠다.


 Unity 인터페이스 2


아래 그림은 지난 포스팅에서도 보았던 그림으로 Unity의 기본 인터페이스이다. 먼저 1)툴바 2)뷰영역 3)상태바 3가지의 영역중 2)뷰 영역의 Hierarchy 뷰 영역을 살펴보자.


(1) Hierarchy 뷰

Hierarchy 뷰는 Scene 뷰에 배치한 모든 객체를 계층 구조로 나열하여 보여준다. Scene 뷰에서 마우스로 클릭하여 선택하기 어렵거나 찾기 어려울 때에도 Hierarchy 뷰에서 쉽게 선택할 수 있다. 또는, 컨트롤 바의 검색 기능을 이용할 수도 있다.

Hierarchy 뷰에 나열된 요소는 모두 게임 오브젝트이다. 게임 오브젝트는 Scene 뷰에 가져다 놓을 수 있는 모든 것을 의미하며, 가장 기본이 되는 단위를 말한다. Hierarchy 뷰는 하나의 게임 오브젝트를 다른 게임오브젝트로 드래그하여 그룹화할 수 있는 기능이 있다. 이 기능을 페어런팅(Parenting)이라 한다.


(2) Inspector 뷰

Inspector 뷰는 현재 선택된 게임 오브젝트의 속성을 보여주는 뷰로서 해당 오브젝트의 속성을 조회, 수정할 때 사용하는 뷰이다. 같은 속성에 한해서 동시에 여러 개의 게임 오브젝트를 선택하고 Inspector 뷰에서 수정할 수 있다.


(3) Game 뷰

Game 뷰는 개발 진행 중 게임을 실행하여 미리 볼수있는 뷰로서 Scene 뷰에 있는 메인 카메라의 시야로 렌더링해서 보여준다. 해당 프로젝트를 빌드하여 실행하며, 모바일에서 구동할 때 보이는 화면과 동일하도록 설정 가능하다. 또한 Game  뷰에 있는 컨트롤 바의 해상도를 선택하면 다양한 해상도로 볼 수 있다.


(4) Console 뷰

Console 뷰는 디버깅(Debugging) 시 로그(Log)를 출력하는 뷰로서 출력하는 메시지는 정보(Information), 경고(Warning), 오류(Error),로 분류하여 메시지 타입별로 필터링도 가능한 뷰이다.

Console 뷰는 개발시 자주 보게되는 뷰이기 때문에 단축키를 기억해두면 사용하기 훨씬 편라하다. (Console 뷰 Mac OS 단축키 : command + shift + C, Windows 단축키 : ctrl + shift + C

또한, 에러 메시지가 여러개 표시되었을 경우 맨 위에 있는 에러 메시지부터 해결해야 한다.


마무리하며..

이번 포스팅에서는 Project 뷰와 Scene 뷰에 이어 Hierarchy 뷰와 Inspector 뷰, Console 뷰에대해 알아보았으며, 다음포스팅에는 이번 포스팅에 이어 남은 인터페이스인 툴바와 피봇/센터, 단축키 설정을 설명하고 Unity의 인터페이스에 대해 마치도록하겠다.




출처   절대강좌! 유니티4, 위키북스 출판, 이재현 지음


'Newbie's Log' 카테고리의 다른 글

POST vs PUT  (1) 2015.02.08
Unity 3D 인터페이스3  (0) 2014.12.09
Java와 JVM -4  (0) 2014.12.06
2014 공개 소프트웨어 <실시간 데이터분석 오픈소스 프로젝트> 참가 후기  (0) 2014.11.24
Java와 JVM -3  (0) 2014.11.09
Posted by 알 수 없는 사용자
,

Java와 JVM -4

Newbie's Log 2014. 12. 6. 22:01


Runtime Data Areas는 Process로서의 JVM이 프로그램을 수행하기 위해 OS로부터 할당 받는 메모리 영역이라고 정의 내릴수 있는데 각각의 목적에 따라 5개의 영역으로 나뉜다. 

1.PC Registers

2.Java Virtual Machine Stacks

3.Native Method Stacks

4.Method Area

5.Heap


이렇게 말이다. PC Registers와 Java Virtual Machine Stacks, Native Method Stacks 각 Thread 별로 생성이 되고, Method Area와 Heap은 모든 Thread에게 공유된다. 




요번 포스팅에서 위에 5개 영역중 PC Registers에 대해 알아보도록 하자.


프로그램의 실행은 CPU에서 명령어,즉 instruction을 수행하는 과정으로 이루어진다. CPU는 이러한 Instruction을 수행하는 동안 필요한 정보를 레지스터라고 하는 CPU내의 기억장치를 사용한다. 

1+2라는 연산을 수행하는 경우 이것을 최소단위로 쪼개보면 연산의 대상이 되는 1과 2도 있을 것이고 더하라는 연산도 있을 것이다. 연산을 하나씩 수행해 보면 먼저 1이라는 값을 받고 다시 2라는 값을 받은 후 이 두 숫자를 더한 결과값을 내는 과정으로 진행될 것이다. 그런데 1을 받고 2를 받을 때 먼저 받아 놓은 1이라는 상수는 2를 받는 행위를 할 동안 이 값들은 CPU에 잠시 기억된다. 


1과 2처럼 명령 실행에 사용되는 데이터를 Operand라고 하며, 더하라는 연산 명령과 같은 add Instruction도 존재한다. CPU는 이것도 미리 기억을 하고 있었어야 한다. 그리고 이 연산의 결과인 3이라는 Operand도 메모리로 전달하기 전에 CPU 어딘가에 잠시 머무르도록 해야 한다. 


이때 사용하는 CPU내의 기억장치를 레지스터라 한다. 


하지만 Runtime Data Area의 메모리 영역인 PC Register는 이것과는 다르다. Java는 Register-Base로 구동되는 방식이 아니라 Stack-Base로 작동한다. JVM은 CPU에 직접 Instruction을 수행하지 않고 Stack에서 Operand를 뽑아 내어 이를 별도의 메모리 공간에 저장하는 방식을 취하고 있는데 이것이 PC Register이다.



Java는 플랫폼에 독립적이기는 하나 OS나 CPU의 입장에서 보면 하나의 프로세스에 지나지 않기 때문에 머신의 리소스를 사용해야 하는 것이 당연하다. 그렇기 때문에 Java도 현재 작업하는 내용을 CPU에 Instruction으로 제공해야 했고 이를 위한 버퍼공간으로서 PC Register라는 메모리 영역을 생성한 것이다. 


PC Register는 각 Thread마다 하나씩 존재하며 Thread가 시작할 때 생성된다. 

만약 Thread가 Java Method를 수행하고 있으면 Java Virtual Machine Instruction의 주소를 가지고 있게 된다. 만약 C언어등으로 Native Method를 수행하고 있다면 PC Registers는 undefined 상태로 있게 된다.왜냐하면 앞으로 배울 Native Method Stack에서 따로 처리하기때문이다. 이 PC Register에 저장되는 Instruction의 주소는 Native Pointer일 수도 있고 Method Bytecode의 시작점 일 수도 있다. Native Method를 수행할 때는 JVM을 거치지 않고 바로 수행하게 된다. 어차피 Native Code는 Platform에 종속 될 수 밖에 없기 때문에 JVM을 경유할 필요가 없기 때문이다. 



이렇게 PC Register에 설명해 보았다. 

다음 포스팅은 Java Virtual Machine Stacks에 대해 설명하도록 하겠다.


참고 Java performance Fundamental(김한도 저)

 



Posted by 알 수 없는 사용자
,

2014년 11월 22일 2014 공개 소프트웨어 <실시간 데이터분석 오픈소스 프로젝트>에 참가하게 되었습니다. 


총 5가지의 세션으로 이루어졌고 세미나는 오후 1시에서 6시까지 진행되었습니다. 


저는 5가지 세션중 1가지 세션이 기억에 많이 남았는데요. 


그건 바로 실시간스트리밍 데이터분석을 위한 인프라운영입니다.




실시간으로 데이터를 분석 하는 것은 부담이 많이 되는 작업입니다.  그래서 이러한 작업을 하면서 목표로 하는 것은 어떠한 트래픽에도 문제 없이 돌아갈 수 있도록 하는 것인데요. 


발표자 안명호씨는 이러한 목표를 이루기 위해서는 아래의 3가지가 필요하다고 하셨습니다.


1. Dynamic 

2. More Management 

3. Scalability


그리고 이러한 목적을 이루는데 도움이 되는 것으로  클라우드가 많이 언급되었습니다. 


첫번째. Dynamic 


물리적인 서버에서는 불가능 하지만 클라우에서는 가상 서버, 가상 네트워크, 가상 스토리지를 동적(Dynamic)으로 생성 소멸이 가능하다는 점 입니다. 

이러한 점을 잘 활용한 곳이 Netflix라는 기업이라고 합니다.

이에 관해서 구글신에 검색해 보니 아래와 같은 글이 있어 링크 첨부합니다 ^^

Why Netflix is one of the most important cloud computing companies


두번째. Management


물리적인 구성에서는 하나하나 관리하기가 힘들지만 클라우드에서는 가상 인프라로 통합관리(Management)가 가능하다는 점입니다.


세번째. Scalability


발표자는 Scalability라는 것을 집고 넘어갔는데, 

Scalability라는 것은 클라우드에서 얼마나 많은 인스턴스들이 돌아가느냐가 아니라 얼마나 많은 인스턴스들을 클라우드에서 동시에 생성할수 있느냐가 맞으며,  얼마나 많은 노드를 가지고 있느냐가 아니라 많은 노드를 생성하는데 얼마나 걸리냐가 맞는 것이라고 했습니다. 


위에 세가지를 말했는데, 간단하게 말하면 클라우드를 통해 Automation를 실현시킬수 있다고 합니다.

소프트웨어기반은 표준화가 가능하고 결국 표준에 맞게 작성할수 있는데,  사용자가 템플릿을 작성하면 동적으로 만들어 Resource Management가 가능하고,  사람이 하지 않고, 자동화 도구(즉, 소프트웨어)를 통해서 Configuration Management를 실현할 수 있다고 합니다. 



발표를 들으면서 100% 완전히 이해 된 것은 아니지만 이를 통해 민기부장님이 내주신 숙제가 생각 났었는데요. 

아래와 같습니다. 

투표를 한 유저정보를 최대 5초내로 다른 시스템에 http call하게 해달라.

B 업체에선 http call해서 받은 데이터를 디비에 저장한다.

회사에서 어떠한 것이든 지원해준다 생각하고 설계를 해 보아라.


제가 생각해낸 방법은 아래 링크에 기록되어 있습니다. 


https://docs.google.com/document/d/1pGt4cRLB2UHsVXr1bKMY-EzowDyADmRe3MPBALbIog0/edit?usp=sharing


결론(물론 정답은 아니지만 ^^;)을 도출하기까지 과정이 적힌 간단한 스케치지만 이 발표를 들으면서 제가 내린 결론에서 확장해서(Azure같은 것을 생각해보며 ^^;) 생각해보는 계기가 되었습니다. 



그외 나머지 5가지 세션들은 BigStorage,Fastcatsearch 등등 제품 설명으로 이루어지는 시간이었습니다.

발표자료 하나가 slideshare에 공유되어 있길래 첨부해 놓았습니다.^^




이상으로 소은양의 <실시간 데이터분석 오픈소스 프로젝트> 참가 후기글을 마치겠습니다.


'Newbie's Log' 카테고리의 다른 글

Unity 3D 인터페이스2  (0) 2014.12.08
Java와 JVM -4  (0) 2014.12.06
Java와 JVM -3  (0) 2014.11.09
Unity 3D 설치 및 인터페이스  (0) 2014.11.05
Java와 JVM -2  (0) 2014.10.18
Posted by 알 수 없는 사용자
,

Java와 JVM -3

Newbie's Log 2014. 11. 9. 15:26

저번 포스팅에서 아래의 4가지 기술중  The Java Programming Language,The Java Class File Format 에 대해 알아보았다. 


- The Java Programming Language

- The Java Class File Format

- The Java Application Interface

- The Java Virtual Machine(JVM)


오늘은 The Java Application Interface와 The Java Virtual Machine(JVM)에 대해 자세히 알아보자. 


The Java Application Interface


Java Application Interface,즉 Java API는 한마디로 Runtime Library의 집합이라고 할 수 있다. 앞서 Class파일을 수행하기 위해서는 JRE가 필요하다고 하였다. 이 JRE는 말 그대로 Java 실행 환경이다. 여기에는 Java Virtual Machine과 Java API,그리고 Native Method등이 포함되어 있다. 

Java API는 OS 시스템과 Java 프로그램의 사이를 이어주는 가교의 역할을 한다. Java API는 Native Method를 통해 OS자원과 연계되어 있고 다른 한 편으로는 Java프로그램과 맞닥뜨리고 있다. 그야말로 Interface의 역할을 하고 있는 셈이다. 


만약 java.io.InputStream 이라는 클래스를 사용하여 특정 파일시스템의 정보를 읽어 온다고 가정해 보자. 파일시스템은 Platform에 따라 동일한 것을 사용하지 않는다. FAT를 사용할 수도 있고 JFS를 사용할 수도 있다.


그러나 Java를 사용하는 한 파일 시스템의 특정 정보를 읽기 위해서 Platform에 대해 고민할 필요는 없다. 그저 java.io.InputStream를 사용하기만 파일시스템에서 원하는 정보를 가져올 수 있기 때문이다. 


Java에서는 Class파일 내에 있는 java.io.InputStream이 Symbolic Reference를 이용하여 Runtime시 해당 Instance에 접근하게 된다. 그러면 이 Instance에 대한 내용, 즉 실제 File에 대한 접근은 Native Method를 통해 OS에 명령을 전달하게 된다. 이후 OS는 실제 File IO를 일으키게 되고, 이 File IO의 결과는 다시 Native Method를 통해 Java API로 전달되는 과정을 거쳐 프로그램이 실행되는 것이다. 



The Java Virtual Machine(JVM)


흔히 JVM을 computer in computer라고도 하는데 Java의 4가지 구성요소 중 가장 핵심적인 것이다. 

Java Virtual Machine은 그 이름에 자신의 모든 특성을 담고 있다. 

'JVM이 무엇이냐?'라고 하는 질문이 들어온다면 이 질문의 답은 JVM은 하나의 개념,스펙에 지나지 않는 것이라고 밖에 대답할 수 없다.JVM은 그 누구도 자세한 설계도를 만들어 제공하지 않는다.단지 JVM은 이렇게 저렇게 해야 한다는 식의 정의만으로 존재할 뿐이다. 표준화된 정의가 나오면 각 JVM 벤더들은 이에 맞도록 자신들의 JVM을 구현한다. 이 뿐이다. 그렇기 때문에 지구상 어디에도 정통 JVM이라는 것은 없다. 이것이 JVM의 가장 중요한 특징이다. 

종합해 보면 JVM은 정의된 Specification을 구현한 하나의 독자적인 Runtime Instance라고 할 수 있다. 여기서 하나의 독자적인 Instance라는 것은 하나의 프로세스 형태로 구동한다는 점을 강조한 것이다. 




위에 그림은 JVM의 기본적인 Architecture를 도식화한 것이다. JVM은 Class Loader System을 통해 Class 파일들을 JVM으로 로딩한다. 로딩된 Class파일들은 Execution Engine을 통해 해석된다. 이렇게 해석된 프로그램은 Runtime Data Areas에 배치되어 실질적인 수행이 이루어지게 된다. 이러한 실행 과정 속에서 JVM은 필요에 따라 Thread Synchronization과 Garbage Collection 같은 관리작업을 수행하게 된다. 


다음 포스팅에는 Runtime Data Areas의 구조의 각각의 모듈에 대해 설명하고자 한다. 그때까지 see you soon!


참고

Java Perfomance Fundamental(김한도 저)

'Newbie's Log' 카테고리의 다른 글

Java와 JVM -4  (0) 2014.12.06
2014 공개 소프트웨어 <실시간 데이터분석 오픈소스 프로젝트> 참가 후기  (0) 2014.11.24
Unity 3D 설치 및 인터페이스  (0) 2014.11.05
Java와 JVM -2  (0) 2014.10.18
Java와 JVM -1  (0) 2014.10.06
Posted by 알 수 없는 사용자
,


 Unity는 위와 같이 많은 히트작의 바탕이 되었다. Unity가 아무리 쉽다 한들, 걸음마도 떼지 못했는데 뛸수는 없는법 ^^! 우리도 히트작을 만들기 위해서는 바탕이 되는 Unity에 대해 조금은 공부를 할 필요가 있다. 글쓴이는 지난 포스팅 부터 Unity 걸음마법에 대해 포스팅 중이다. 본 포스팅은 '절대강좌! 유니티4 위키북스'를 참조하였다.

지난 포스팅에서는 Unity에 대한 간단한 특징을 살펴보았으며, 이번 포스팅은 지난번 포스팅에서 말했듯이 Unity 설치 및 인터페이스에 대해 알아보도록 하겠다.

사실 Unity 설치라고 해봤자 거창할것 하나없이 민망할 정도로 간단하고 편리하다. 밑에서 살펴보도록 하자.


 Unity 설치


1. Unity 내려받기

 Unity 설치 파일은 Unity 홈페이지에서 다운받을수 있다. 한글 홈페이지에 링크를 걸어두었으니 참고하고 싶다면 여기  또는 그림을 클릭하길 바란다.
걸어둔 링크로 들어간다면 아래와 같은 화면이 보일 것이다. 본인의 OS가 Windows라면 Windows버전을,  Mac이라면 Mac OS X 버전을 다운받으면 된다.


2. Unity 설치

다운 받은 파일로 설치를 진행 한다. Unity 설치는 특별한 것이 없으므로 "계속"을 선택하며 설치하면 순조로울 것이다. 





 Unity 인터페이스


Unity 기본 인터페이스

Unity의 기본 인터페이스는 다음과 같이 구성되어 있다. 

먼저 맨 위의 1)툴바 가운대의 2)뷰 영역 맨 아래의 3) 상태바로  총 3가지 영역으로 나눌수 있다. 각 영역 하나하나 아래에서 살펴 보도록 하자.

뷰 (View)

각 탭으로 분리된 창을 뷰라 한다. 각 뷰의 명칭은 탭에 표기되어 있으며, 이 탭을 드래그하여 어디든 자유롭게 배치할 수 있다. 

(1) Project 뷰

Project Browser라 하기도 하며, 이 뷰는 게임 제작에 필요한 모든 에셋을 모아두는 곳이기도 하다.

Project뷰는 다른 뷰와는 다르게 하나의 칼럼(Column) 또는 두개의 칼럼으로 분리 할 수 있으며 이 옵션은 사용자가 선택 가능하다.

이래와 같이 뷰탭에서 마우스 오른쪽을 클릭하여 변경하거나 메뉴에서 마우스 왼쪽을 클릭하여 두개의 칼럼에서 하나의 칼럼으로 변경 가능하다. (물론, 하나의 칼럼에서 두개의 칼럼으로 변경하는 것도 가능하다.^^) 

Project 뷰는 모든 에셋을 저장하고, Project 뷰에 나열된 폴더 구조와 파일들은 'Assets'폴더 하위에 저장되며, 파일 탐색기에서 확인할 수 있다.

(2) Scene 뷰

Scene 뷰는 3차원 공간을 표현하고 있으며, 스테이지를 디자인 하고 플레이어 또는 장애물을 배치할수있는 공간으로, Project 뷰에 있는 에셋을 Scene 뷰로 드래그 하여 배치할 수 있다.

Scene 뷰의 헤더에 있는 바를 컨트롤 바(Control Bar)라고 하며, 컨트롤 바에는 드로우 모드(Draw Mode)와 렌더 모드(Render Mode)의 옵션을 변경할 수 있는 드롭다운 버튼이 있다. 개발 시 여러 옵션으로 변경해 볼 수 있고, 이는 실행시에 영향을 미치지 않는다.

드로우 모드의 옵션에 따라 Scene 뷰의 화면은 다음과 같이 바뀐다.

  • Textured : 기본옵션으로 3D모델의 표면에 텍스처를 입혀서 보여준다. 실제 게임을 실행했을 때 보이는 화면과 같다.



  • Wireframe : 텍스처는 제외한 3D모델의 메쉬(Mesh)만 보여준다.


  • Textured Wire : 텐스처와 메쉬를 동시에 표현하는 옵션이다.


  • Render Paths : 렌더링 방식에 따라 다른 색상으로 표현한다.

    -  색상에 따른 렌더링 방식

    Render Paths 색상 

    렌더링 방식

    녹색 

    Deferred lighting 

    노란색

    Forward rendering 

    빨간색

    Vertex Lit 


  • Lightmap Resolution : 라이트맵(Lightmap)을 베이크했을 때 적절한 해상도 여부를 판단하기 위해 화면에 격자무늬가 오버레이(Overlay) 되어 표현된다.
    화면상으로는 Textured모드와 Lightmap Resolution모드가 별차이 없어보인다.

    다음으로 렌더 모드 옵션에 대해 설명하겠다. 렌더 모드의 옵션은 Scene의 다양한 렌더링 정보를 조회할 수 있는 기능을 제공한다.


    렌더 모드의 옵션에 따라 Scene 뷰의 화면은 다음과 같이 바뀐다.

  • RGB : 정상적인 색상으로 렌더링된 화면을 보여준다.

  • Alpha : 투명 처리된 세이더를 사용하는 3D모델을 표현하기 위해 흑백으로 보여준다.

  • Overdraw : 오버드로우가 발생하는 지점에 색상을 중첩하여 진하게 보여준다. 오버드로우란 카메라의 시야에 보이지 않는 곳에서 중첩하여 드로우(Draw)가 발생하는 것을 말하며, 이는 성능 저하의 원인이 된다.

  • Mipmaps : 카메라로부터 거리가 멀어질수록 텍스처의 품질을 낮추어 렌더링 부하를 줄이는 것을 밉맵(Mipmap) 처리된 텍스처라 한다. 이 모드는 밉맵처리된 텍스처의 사이즈가 적절한지를 판단할 수 있다. 빨간색은 텍스처가 필요 이상으로 크다는 의미이고, 파란색은 작다는 의미이다.

    컨트롤 바에있는 다른 옵션은 다음과 같다.

  • 2D/3D 화면전환 : Scene 뷰 화면을 2D와 3D로 전환한다.

  • 조명 효과 : 조명 효과의 적용 여부를 선택할 수 있다.

  • 음향 효과 : 음향 효과의 적용 여부를 선택할 수 있다.

  • 이펙트(Effect) : Skybox, Fog, Flares, Animated Materials 효과의 적용 여부를 선택할 수 있다.

  • 기즈모(Gizmos) : Scene 뷰에 있는 특정 오브젝트에 아이콘을 표시하여 쉽게 식별할 수 있게 해주는 기능으로 아이콘의 크기와 표시 여부를 설정할 수 있다.



마무리하며..

 이번 포스팅에서는 유니티의 설치 및 인터페이스에 대해 알아보았으며, 다음포스팅에는 이번 포스팅에 이어 남은 인터페이스가 어떤것들이 있는지 알아보도록 하겠다.




출처   절대강좌! 유니티4, 위키북스 출판, 이재현 지음


Posted by 알 수 없는 사용자
,