25G.story

JIT 세가지 버전 32-bit 클라이언트 버전 32-bit 서버 버전 64-bit 서버 버전 64-bit 서버 컴파일러는 티어드 컴파일을 지원하기 위해 클라이언트 컴파일도 가지고 있습니다. 32bit 운영체제를 가지고 있다면 JVM도 32bit를 사용해야 합니다. 64bit 운영체제를 가지고 있다면 JVM은 32bit 또는 64bit를 사용할 수 있습니다. 만약 힙 크기가 3GB보다 작다면 32bit 버전의 자바가 더 빠르게 동작할 수 있습니다. 당연하게 메모리 참조가 32bit 이므로 64bit 보다는 비용이 싸기 때문입니다. 만약 long이나 double 같은 64bit 변수를 광범위하게 사용하는게 아니고 전체 프로세스 크기가 4GB 미만이라면 32bit 컴파일러를 사용하는게 더 성능상의 우위가 있..

기본 튜닝 JIT 컴파일러는 두가지 형태로 나뉩니다. 사용할 형태는 흔히 애플리케이션이 실행되고 있을때 해야할 컴파일러 튜닝에 따라 결정됩니다. 두개의 컴파일러는 클라이언트와 서버로 알려져 있습니다. JVM 개발자 들은 흔히 c1(컴파일러 1, 클라이언트 컴파일러) 와 c2(컴파일러 2, 서버 컴파일러) 라는 이름으로 부릅니다. 두 컴파일러의 주요 차이점은 코드 컴파일에 있어서의 적극성 유무입니다. 클라이언트 컴파일러 서버 컴파일러보다 먼저 컴파일을 하기 시작합니다. 이는 서버 컴파일러보다 상대적으로 많은 코드를 컴파일한다는 의미이며 코드가 실행되기 시작하는 시간동안 클라이언트 컴파일러가 보다 더 빠를것입니다. 서버 컴파일러 클라이어트 컴파일러보다 더 많은 정보를 바탕으로 컴파일을 하고 더 나은 최적화를..

핫스팟 컴파일 핫스팟이란 이름은 코드 컴파일에 대한 접근법에서 유래했다고 합니다. 일반적인 프로그램은 전체 코드 중 일부만 자주 실행되며 애플리케이션의 성능은 이 일부가 얼마나 빠르게 실행되는가에 의해 좌우됩니다. 이 중요한 영역을 애플리케이션의 핫 스팟 이라고 합니다. 해당 영역의 코드가 많이 실행될 수 록 더욱 핫해집니다. 이런이유로 JVM은 코드를 실행할 때 바로 코드 컴파일을 하지 않습니다. 여기에는 기본적인 이유가 두가지가 있습니다. 코드가 한번만 실행된다면 컴파일은 헛수고가 됩니다. 컴파일해서 컴파일된 코드를 한번만 실행하는 것 보다 자바 바이트 코드를 인터프리트하는 편이 더 빠를 것입니다. 최적화 때문입니다. JVM이 특정 메소드나 루프를 실행하는 시간이 길어질 수록 코드에대해 얻어지는 정보..

JIT 컴파일러란? JIT (just-in-time,JIT) 컴파일러는 JVM의 핵심입니다. JVM내에서 컴파일러보다 성능에 더 영향을 주는 요소는 없습니다. 대부분의 상황에서 티어드 컴파일(tiered compilation)을 사용하기만 해도 튜닝할 필요는 거의 없습니다. 컴파일과 인터프리트 CPU는 어셈블리나 바이너리 코드라고 불리는 특정 명령어만 실행시킬 수 있습니다. 그 말은 CPU가 실행하는 모든 프로그램은 이 명령어 들로 변환이 가능합니다. C++같은 언어들은 바이너리로 컴파일된 코드로 실행되어 컴파일형 언어라고 불립니다. 즉 프로그램이 작성되고 정적 컴파일러는 바이너리를 생성합니다. 그 바이너리 내의 어셈블리 코드는 특정 CPU만을 대상으로 합니다. 반면 PHP나 Perl과 같은 언어는 인터..

String text = "안녕하세요"; String [] charSet = {"utf-8","euc-kr","ksc5601","iso-8859-1","x-windows-949"}; for (int i=0; i

자바에서 프로그램을 설계할때 가장 중요한것 main을 가진 클래스가 모든 객체(heap)의 정보를 가지고 있다. main을 가진 클래스를 context(문맥)를 가지고 있다고한다 즉 그 프로그램의 모든정보를 main이 들고있다.

어댑터 패턴 일상생활에서의 어댑터는 일반적으로 걸러내는 역할을 한다. 인터페이스가 너무 많은 행위의 제약을 가지고 있으면 경우에 따라서 걸러내기 위해서 추상 클래스로 걸러낼 메서드를 오버라이드 해서 해당 인터페이스를 상속받으면 경우에따라서 행위의 제약을 벗어 날 수 있다. 하지만! 자바는 다중상속을 재한 하기 때문에 어댑터 패턴의 단점은 분명하다. 그래서 나온것이 interface내부에서 default라는 문법이 생겨 난 것이다. default는 인터페이스도 몸체가 있는 메서드를 만들 수 있다. 왜 이 문법이 생겼냐?! (다중 상속이 안 되는 것이 많기 때문이다.) 그래서 최근의 자바버전에선 어댑터 패턴 대신에 default를 사용하는 것이 좋다

컴퓨터에서 우리가 응용프로그램을 사용하면 기본적으로 OS의 통제 내에서 동작을 하게 돼 있다. 어떠한 GUI 환경에 리스너는 OS에서 어떠한 프로그램을 계속 주시하다가 프로그램을 사용하는 유저가 키보드나 마우스를 조작하게 됐을 때 그 움직임을 체크해서 어떠한 메모리공간에 저장을 한다. 이 움직임을 체크해서 순차적으로 기록해 두는 메모리 공간을 "이벤트 루프"(큐)라고 한다. 그리고 이벤트 루프에 기록해 놓은 명령을 실행하기 위해서 "이벤트 핸들러"가 호출이 된다. 이벤트핸들러는 Stack공간인데 즉 리스너 내부에 메서드가 호출된다는 뜻이다.(메서드 실행) 여기서 중요한 점은 대부분의 GUI 환경의 메커니즘이 위 내용과 같이 흘러가는데 java에서 GUI프로그램을 구축할 때 굉장히 중요한 규칙이 있다. 1..

일대일로 소켓통신을 하는 것은 한 방향으로만 이루어진다. 쓰는 쪽(클라이언트)과 읽는 쪽(서버). 일대일 방식의 소켓통신을 그림으로 표현해 봤는데 여기서 먼저 개선해야 할 부분은 클라이언트가 메시지 한 개만 보내면 프로그램이 종료되는 것이다. 이럴 때 종료되지 않고 "반복"되게 하기 위해서 while을 사용해서 메시지를 보내더라도 프로그램이 계속 돌도록 해본다. 자 그럼 이제 하나의 문제점을 개선했는데 개선을 해놓고 보니 클라이언트만 일방적으로 메시지를 보내고 서버는 그 메시지를 읽기만 한다. 완전한 단방향 통신이다. 이를 어떻게 개선해야 할까? 이문제를 개선하기 위해서는 먼저 스레드에 대해서 생각을 해 봐야 한다. 지금 현제 위 프로그램에서 java는 main스레드 하나가 동기적으로 열심히 쓰고 읽고를..

소켓통신을 일대일 방식으로 하려면 두 개의 소캣이 필요하다 서버 소켓과 클라이언트소켓 그럼 이 두 개의 소켓을 ByteStream으로 연결하는데 ip주소로 서로 통신할 수 있도록 할 것입니다. 포트를 양 끝단에 달고 하는 통신(소켓통신) 다음과 같은 방식으로 통신이 이루어집니다. 위 그림에는 빠져있지만 클라이언트 소켓은 메시지를 쓰는 쪽이기 때문에 키보드와 연결하는 스트림이 하나 더 있어야 합니다.(클라이언트 파일 소스코드 참고) 서버 소켓 파일 import java.io.BufferedReader; import java.io.InputStreamReader; import java.net.ServerSocket; import java.net.Socket; public class ServerFile { /..