2015의 게시물 표시

소프트웨어 전문 기업에서 연구 방법

최근 신입 연구원 지망자들을 면접하면서 소프트웨어를 직업으로 삼으려는 학생들 수준이 예전보다 많이 높아졌음을 느낀다. 국민적으로 소프트웨어의 중요성에 대한 평가가 그만큼 올라갔고, 또 소프트웨어를 통한 자기 실현의 기회가 상대적으로 많아졌기 때문인 것 같다. 아래는 소프트웨어 전문 기업의 연구소를 이끌면서 느끼는 개인적 감흥이라고 할 수 있겠다. 너무 당연한 이야기일지 모르지만, 실제로는 잘 되지 않는 것들에 대한 기록이다. 연구원별 과제 선정 소프트웨어 기업의 연구소는 어느 수준 이상의 연구개발 능력이 필요한 곳이다. 연구원들은 모두 동일한 능력을 갖지 않는다. 지적 노동을 하는 연구원들은 수준이 천차만별이지만, 일단 연구원으로서 연구개발 업무를 수행하기 위해서 필요한 기본 수준은 만족해야 한다. 우수한 인재 매우 우수한 사람은 흥미를 잃지 않을 주제를 주면 알아서 잘 한다. 이런 경우에는 어떤 가치 있는 주제를 기업 차원에서 연구해야 하는지 고민하고 이를 연구원과 잘 컨센서스를 이루는 것이 중요하다. 연구 주제에 흥미를 잃거나 포커스를 놓치게 되면 동기 부여에 실패하여 퍼포먼스가 급격하게 떨어지고, 타 회사로 이직을 고민하게 되는 경우가 있다. 연구의 가치와 방향에 대해서 항상 잘 조율이 되어 있어야 하고 초기에 궤도에 오를 때까지 주제와 방향을 잘 공유해야 한다. 평범한 인재 반면 상대적으로 평범한 연구원들도 많이 있다. 보통의 연구원들은 주제를 정해준다고 해서 충분히 방향을 잘 정하지 못하는 경우가 많다. 연구원의 능력에 따라 주제와 범위, 그리고 해결에 대한 방향까지 제시해줘야 하는 경우가 종종 생긴다. 이런 연구원들은 코칭이 늘 필요하고, 수준에 맞게 연구 수준과 범위를 좁혀줄 필요가 있다. 잠깐만 방향을 잃어도 퍼포먼스가 급격하게 떨어지는 경우가 많으므로 관리는 시간적으로 더 자주 일어나야 한다. 매니저와 연구원 연구 과제는 연구소에서는 누구나 진행할 필요가 있다. 단순 관리자가 필요하지 않은 연구소의 특성

[Java] Java 관련한 간단한 테스트

문득 생각나서 몇 가지 간단한 Java  테스트 1. private static method의 코드 블록 크기가 작을 경우 javac는 가볍게 inline 시켜줌. (즉, 해당 method는 바이트코드에서 사라져버리고 caller method에 inline됨.) 2. instanceof 연산자가 getClass()를 ==비교하는 것보다 훨씬 빠름. (instanceof는 child class여부까지 체크해야 함에도 불구하고) 3. instanceof 연산을 할 때 exact class에 대해 호출하는 것이 parent class나 interface에 대해 호출하는 것보다 더 빠름. (당연!) 4. java.lang.Object의 clone() 메소드를 사용하여 객체를 shallow copy하는 것은 그다지 효율적으로 구현되지 않아서 직접 copy() 메소드를 구현하여 멤버값들을 복사해주는 것이 대부분 더 빠름. (자바는 C의 struct처럼value object 개념이 없어 메모리 복사만으로 clone할 수 없으므로)

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다. 일단 생소하기 때문에 어렵다. 그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다. 먼저 G1GC를 이해하는 데 유용한 사이트이다. Garbage-First Collector Getting Started with the G1 Garbage Collector Understanding G1 GC Logs Tuning Garbage Collection for Mission-Critical Java Applications Controlling GC pauses with the GarbageFirst Collector G1: One Garbage Collector To Rule Them All Garbage First (G1) Garbage Collection Options compare JVM options for public 메일 :  G1 GC clean up time is too long JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다. (새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.) 지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다. 즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다. 앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다. 둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들에 대한

[자바] FileChannel에서 map을 하면 내부적으로 unmap은 언제 일어날까? Finalizer를 PhantomReference가 대체할 수 있나?

1. java.nio.FileChannel에서 map을 호출한 다음에 unmap은 언제 이루어질까? 언뜻 생각해보면 FileChannel에서 mmap을 호출하므로 FileChannel을 close할 때 명시적으로 unmap을 해주는 게 효율적인 구현이 아니었을까 생각이 들긴 합니다.. 하지만, 실제 JDK 구현은 그렇게 하지 않았습니다. openjdk v6 코드를 보면 {openjdk6}/jdk/src/share/classes/sun/nio/ch/FileChannelImpl.java 에 해당 구현이 되어 있습니다. channel을 close하면 내부적으로 implCloseChannel 메소드가 호출이 되는데 여기에서는 mmap 관련한 일은 행하지 않습니다. 명시적으로 unmap을 하는 경우는 transferTo나 transferFrom이 호출된 경우 일시적으로 사용된 mmap을 바로 munmap해줍니다. 실제 MappedByteBuffer는 Unmapper라는 unmap을 위한 객체를 매번 따로 만들어서 해당 MappedByteBuffer에 대한 참조가 없으면 PhantomReference 방식으로 청소를 해줍니다. 코드를 쫓아가보면 결과적으로 {openjdk6}/jdk/src/share/classes/sun/misc/Cleaner.java 객체에 Unmapper 객체를 넘겨주는 형태입니다. 그냥 MappedByteBuffer 클래스에 finalize() 메소드를 구현하지 않고 PhantomReference 방식으로 복잡하게 처리한 것은 finalize() 메소드를 호출하는 Finalizer 쓰레드의 오버헤드를 줄이기 위한 것으로 보입니다. Finalizer 쓰레드에서 JNI 통해 munmap 시스템 콜을 하는 게 부담스러웠던 것입니다. 다시 문제로 돌아가서 왜 file channel을 close할 때 unmap을 하지 않았을까 생각해보면 원래 유닉스 시스템 콜에서도 fd를 close() 하는 것과 파일의 영역을 가상 메모리에

소프트웨어 혹은 SW 정책 관련하여 몇 가지 주장들에 대한 의견.

소프트웨어를 하는 사람으로서 의견을 표하고 싶은 몇 가지 소프트웨어 정책들이 있어서 얘기를 해보려고 한다. 소프트웨어는 국내에서는 스마트 혁명이라고 할 아이폰의 등장 이후 너무 갑작스레 중요한 화두가 되어버린 것 같다. 스티브 잡스의 말했던 기술(technology)과 인문 교양(liberal arts)의 교차로라는 말 또한 지나치게 이상하게 비틀려 확대 해석되는 일까지 생겼다. 그리고 IT 선진국이지만 Software는 그닥 선진국일 수 없는 국내 현실을 두고 여러 가지 의견과 진단들이 나왔다. 이러한 현상은 소프트웨어를 알지 못하는 (혹은 알 수 없고 알 필요도 없는) 공공 부문과 하드웨어 방식의 기업들에 의해 뒤틀린 또하나의 갈라파고스 현상이라고 생각한다. 현실에서 존재하지 않는 망상적인 "한국적 소프트웨어"라고 할까? 국내의 몇 가지 현상들에 대해 의견을 제시하려고 하는데 먼저 한 가지 확실히 해둘 것이 있다. 소프트웨어에 대한 문제는 국가의 경제 상태나 정책과 밀접하게 연결된 부분이 많아서 정치적인 문제가 개입될 수 있다. 내 의견은 정치적 관점과 완전히 무관하지는 않다. 하지만, 분명하게 해두고 싶은 부분은 내 의견의 가장 기본적인 출발점은 "사실이란 정치적 관점 등의 해석에 의해 바뀔 수 없다"라는 과학적 사고이다. 과학적 사고란 가설을 세우고 실험을 통해 검증 가능한 것들을 다룬다. 물론 실험이 어렵고 검증이 어려운 영역도 있지만, 정치적 관점이 사실을 정의하지 않는다는 것이다. "어떤 정치적 입장에 유리한 것을 사실이라고 보는" 듯한 전도된 사고는 사절이다. 특히 SNS는 매우 전파력이 강하기 때문에 감성적으로 가까운 것들이 사실인 것처럼 쉽게 전파되는 경향이 있다. 감성적으로 전파되는 것들에 대한 논리적인 필터들 역시 쉽게 전파될 수 있으면 좋겠지만, 사람이란 모든 사안들에 대해 이성적 검증에 시간을 투입할 여유가 많지 않으므로 감성적 공감을 통해