JVM

JVM하면은 음.. 자바소스파일을 실행시켜주는머신이고

장점은 운영체제에 상관없이 음.. 그다음은

단점은 느리다는거.. 왜? -> 음..

그리고 가비지컬렉터가 힙을 관리해주기 때문에 자원반납을 지정안해줘도 된다.

이정도로 알고있다.

일단 우리가 만든 자바파일을 컴파일해야한다.

javac로 바이트코드로 만들어야 한다.

javac C:\Users\PC\eclipse-workspace\jvmTest\src\jvmTest\plusC.java

그러면 .class파일이 나온다.

실행 :

java C:\Users\PC\eclipse-workspace\jvmTest\src\jvmTest.plusC   <- 프로젝트명.패키지명.클래스파일명해줘야함 (\로 들어가면 찾을수없다고 나옴)

바이트코드를 확인하려면

javap -c C:\Users\PC\eclipse-workspace\jvmTest\src\jvmTest.plusC  입력한다.

Compiled from "plusC.java"

public class jvmTest.plusC {

  public jvmTest.plusC();

    Code:

       0: aload_0

       1: invokespecial #1                  // Method java/lang/Object."<init>":()V

       4: return

  public static void main(java.lang.String[]) throws java.io.IOException;

    Code:

       0: new           #2                  // class java/io/BufferedReader

       3: dup

       4: new           #3                  // class java/io/InputStreamReader

       7: dup

       8: getstatic     #4                  // Field java/lang/System.in:Ljava/io/InputStream;

      11: invokespecial #5                  // Method java/io/InputStreamReader."<init>":(Ljava/io/InputStream;)V

      14: invokespecial #6                  // Method java/io/BufferedReader."<init>":(Ljava/io/Reader;)V

      17: astore_1

      18: new           #7                  // class java/util/StringTokenizer

      21: dup

      22: aload_1

      23: invokevirtual #8                  // Method java/io/BufferedReader.readLine:()Ljava/lang/String;

      26: invokespecial #9                  // Method java/util/StringTokenizer."<init>":(Ljava/lang/String;)V

      29: astore_2

      30: aload_2

      31: invokevirtual #10                 // Method java/util/StringTokenizer.nextToken:()Ljava/lang/String;

      34: invokestatic  #11                 // Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

      37: istore_3

      38: aload_2

      39: invokevirtual #10                 // Method java/util/StringTokenizer.nextToken:()Ljava/lang/String;

      42: invokestatic  #11                 // Method java/lang/Integer.parseInt:(Ljava/lang/String;)I

      45: istore        4

      47: getstatic     #12                 // Field java/lang/System.out:Ljava/io/PrintStream;

      50: iload_3

      51: iload         4

      53: iadd

      54: invokevirtual #13                 // Method java/io/PrintStream.println:(I)V

      57: return

}

이게  jvm이 실행시킬 파일의 코드이다.

그래서 윈도우에서 컴파일한걸 리눅스에서 실행시킬 수 있다. 왜냐면 운영체제에상관없이 바이트코드로 컴파일하니까.

https://m.blog.naver.com/PostView.nhn?blogId=2feelus&logNo=220738480797&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F 

이는 프로그램을 처음 실행 하기 전에 모든 코드를 기계어로 컴파일하는 기존 컴파일러와는 대조적입니다.

바꾸어 말하면, 기존의 컴파일러는 처음 프로그램을 실행하기 전에 전체 프로그램을 EXE 파일로 작성합니다. 최신 스타일의 프로그램의 경우 어셈블리는 의사 코드 (p 코드)로 생성됩니다. OS에서 프로그램을 실행 한 후에 (예 : 아이콘을 두 번 클릭하면) JIT 컴파일러가 Intel 기반 프로세서 또는 무엇이든간에 이해할 수있는 기계 코드 (m 코드)를 생성합니다.

처음에는 컴파일러가 높은 수준의 언어 (어셈블러보다 상위 레벨로 정의 됨)를 오브젝트 코드 (기계 명령어)로 변환 한 다음 링커에서 실행 파일로 링크했습니다.

언어 발전의 한 지점에서 컴파일러는 고급 언어를 의사 코드로 컴파일 한 다음 인터프리터가 해석하여 프로그램을 실행합니다. 이로 인해 목적 코드와 실행 파일이 제거되고 이러한 언어를 여러 운영 체제와 하드웨어 플랫폼으로 이식 할 수있게되었습니다. Pascal (P-Code로 컴파일 된) 파스칼은 첫 번째 코드 중 하나였습니다. Java와 C #은 최근의 예입니다. 결국 P-Code라는 용어는 바이트 코드로 대체되었는데, 대부분의 의사 연산은 바이트 길이이기 때문입니다.

JIT (Just-In-Time) 컴파일러는 런타임 인터프리터의 기능으로, 메소드가 호출 될 때마다 바이트 코드를 해석하는 대신 바이트 코드를 실행중인 시스템의 기계어 명령으로 컴파일 한 다음이를 호출합니다 대신 개체 코드. 이상적으로는 실행되는 객체 코드의 효율성은 실행될 때마다 프로그램을 다시 컴파일하는 비 효율성을 극복 할 것입니다.