현재 저는 jvm을 커널 공간에서 (아마도 Linux) 커널 모듈로 실행하는 아이디어를 연구 중입니다. 나는 이 아이디어에 많은 장점이 있다고 본다.
물론 이러한 시스템의 가장 큰 장점은 커널 공간 개발이 크게 단순화된다는 것입니다. 그러나 이는 다양한 측면으로 인해 발생합니다.
1) 상대적으로 낮은 수준의 지식을 가진 모든 Java 개발자는 커널 모듈을 개발할 수 있습니다. 예, 이것은 확실히 좋은 가능성은 아닙니다 :-), 특히 대부분의 오픈 소스 Java 사용자 공간 프로젝트의 현재 코드 품질을 보면... 하지만... 커널 공간에서 동일한 일이 일어날 필요는 없습니다.
2) (또한 실제 의도된 목표): JVM은 커널 개발의 가장 큰 문제인 메모리 보호 부족을 해결할 수 있습니다. 다른 문제(fe jit 컴파일러 오류 또는 낮은 수준의 하드웨어 문제)가 없는 경우 Java에서 컴파일된 바이너리 코드 세그먼트는 해당 범위 외부의 데이터 구조에 손상을 입히지 않습니다. 단, 이러한 바이너리 코드의 런타임 안전 확인으로 인해 오류가 발생할 수 있습니다. 긍정적인 효과가 크다. 속도면에서 명백한 단점이 있습니다.
첫째, 자바 바이트코드 인터프리터일 필요도 없습니다. JIT(Just-In-Time 컴파일러)는 시스템 사용자 공간에 상주할 수 있으며 컴파일된 바이너리(실제로는 커널 모듈)만 커널 공간에 매핑합니다. 네임스페이스 관리자와 가비지 수집기만 커널 공간에서 실행하면 됩니다.
둘째, 크거나 느리거나 무서울 필요는 없습니다. 이는 사용자 공간 JVM의 경우 크고 비효율적으로 사용되는 라이브러리가 사용되며 다음과 같은 경우 동일한 라이브러리를 사용할 이유가 없기 때문입니다.Java로 작성된 드라이버.
내가 볼 수 있는 유일한 단계는 라이브 기능입니다. 물론 Java에서 이 작업을 수행하는 것은 메모리 관리의 사소한 세부 사항에 대한 제어 권한이 훨씬 적기 때문에 훨씬 더 어렵습니다.
그러한 프로젝트가 이미 존재하는지(?#1), 그렇지 않은 경우 명백한 주요 대체(?#2)가 있는지 궁금합니다.
답변1
JVM 구현이 필요하기 때문에 이것은 매우 큰 프로젝트가 될 것이라고 생각합니다.C로 작성됨커널 API의 사용자 정의 부분을 사용하십시오. openjdk의 핫스팟은 다음과 같습니다.분명히 250K+ LOCC와 C++에서. Linux 커널에서는 C++를 사용할 수 없습니다.
나는 이것이 많은 문제를 해결할 수 있다고 생각한다.사람 년구현. 공식 소스 트리에 포함될 가능성은 낮지만, 큰 문제는 아닙니다.
"가장 큰 장점"이라고 부르는 것과 관련된 규모를 고려하면 다음과 같습니다.
물론 이러한 시스템의 가장 큰 장점은 커널 공간 개발이 크게 단순화된다는 것입니다.
무슨 뜻인지 잘 모르겠습니다. Java로 코드를 작성할 수 있지만 C는 작성할 수 없는 분들에게는 이것이 분명히 사실이라고 생각합니다. 하지만 일반적인 의미에서 그런 뜻이라면 왜 그런지 모르겠습니다. 나는 C와 Java 모두에 익숙하며 둘 중 하나를 선호하지 않습니다(컨텍스트나 다른 사람들이 나를 위해 결정을 내리는 경향이 있음). 예를 들어 MM을 수행할 필요가 없기 때문에(하지만 MM이 정말 그렇게 어려운가요?) Java가 사용하기 약간 더 쉬울 수도 있습니다. 하지만 제 생각에는 더 어색하고 제한적으로 보일 수도 있습니다.
개인적으로 추구할 만한 일은 아니라고 생각하지만, 불가능하거나 나쁜 생각은 아닙니다. 당신의 가장 큰 장애물은 기여할 다른 사람을 찾는 것입니다.
답변2
커널 내 JVM을 사용한다고 해서 많은 문제가 해결되는 것 같지 않습니다. 포인터가 없기 때문에 독립적인 코드 조각을 합리적으로 격리할 수 있지만 Java 바이트코드 해석기(항상 기본 코드보다 느림) 또는 JIT 컴파일러(처음에는 매우 느림)도 도입됩니다. 나는 가비지 수집기에 대해 언급하지 않았습니다. 아마도 일부 문제를 자동으로 해결하고 싶을 수도 있지만 그렇지 않을 것입니다.
해결해야 할 또 다른 문제는 하드웨어를 연결하는 것입니다. Java 코드가 네트워크 카드, SATA, (i)SCSI, USB, 파이버 채널 및 수많은 기타 컨트롤러, 사운드 카드 및 (가장 까다로운 부분 중 하나인 것 같습니다) 그래픽 가속기에 액세스할 수 있도록 상당히 복잡한 코드 조각이 필요합니다. . 이로 인해 많은 코드가 베어 메탈에 더 가까운 다른 언어(어셈블리이든 C/C++이든 상관없이 실제로는 더 높은 수준의 추상화를 갖춘 더 읽기 쉬운 어셈블리 언어일 뿐입니다)로 작성됩니다.
마지막으로 Java로 커널 코드를 작성하는 것이 최종 목표라면 약간 다른 작업을 수행하기로 결정할 수도 있습니다. 즉, Java로 커널 코드를 작성하고 네이티브 코드로 직접 컴파일하는 것입니다.
1) 상대적으로 낮은 수준의 지식을 가진 모든 Java 개발자는 커널 모듈을 개발할 수 있습니다.
90%의 경우 커널 모듈 작성예하드웨어와 관련되려면 "사소한" 하드웨어 지식 이상이 필요합니다. Java를 알고 있지만 C에 대해 깊이 알지 못하는 사람은 확실히 하드웨어 드라이버(또는 다른 커널 모듈)를 작성하기에 적합한 사람이 아닙니다.
다른 관점에서 보면: 가장 중요한 데이터(이러한 커널에 의해 제어되는 생명 유지에 대해서는 말하는 것이 아닙니다)를 커널에서 실행되는 데이터에 신뢰합니까?C나 어셈블리를 모르는 사람이 작성한 것입니다.합리적인 드라이버를 작성하는 것으로 충분합니까?
2) (또한 실제 의도된 목표): JVM은 커널 개발의 가장 큰 문제인 메모리 보호 부족을 해결할 수 있습니다. 다른 문제(fe jit 컴파일러 오류 또는 낮은 수준의 하드웨어 문제)가 없는 경우 Java에서 컴파일된 바이너리 코드 세그먼트는 해당 범위 외부의 데이터 구조에 손상을 입히지 않습니다. 단, 이러한 바이너리 코드의 런타임 안전 확인으로 인해 오류가 발생할 수 있습니다. 긍정적인 효과가 크다. 속도면에서 명백한 단점이 있습니다.
메모리 보호를 위해 JIT를 사용하시나요? 페이지가 쓰기 가능하고 실행 가능해야 합니다. 직접적인 메모리 액세스가 부족하더라도(포인터를 사용할 수 있다는 의미에서) 이는 보안상 악몽입니다.
보안(및 기타 코드 격리)에 관심이 있다면 마이크로커널이 적합합니다. 하나 가질 수도 있어요정식 검증. 그리고 다시 말하지만, 코드는 최악의 프로그래머만큼 훌륭하며, 최상의 경우에는 코드가 여전히 존재합니다. 언어 자체가 중요한 것이 아니라, 그것을 사용하는 사람이 중요합니다.
그건 그렇고, 나는 읽는 것을 적극 권장합니다다양한 언어로 된 시스템 프로그래밍에 대한 답변입니다.그게 다야.