Portando o jvm no espaço do kernel?

Question

Atualmente estou jogando com a idéia de um jvm rodando no espaço do kernel, como um módulo do kernel (talvez linux). Eu vejo muita vantagem da ideia.

É claro que a maior vantagem de um sistema desse tipo foi a grande simplificação do desenvolvimento do espaço do kernel. Mas isso aconteceu porque diferentes aspectos:

1) todos os desenvolvedores java com um conhecimento relativamente baixo de baixo nível conseguiram desenvolver um módulo do kernel. Sim, não é uma boa possibilidade :-), especialmente se nós vermos a qualidade atual do código da maioria dos projetos openspace java userspace, mas ... não há necessidade de acontecer o mesmo no kernelspace também. / p>

2) (E é o objetivo realmente pretendido): uma JVM poderia resolver o maior problema do desenvolvimento do kernel, e é a falta de proteção da memória. Um segmento de código binário compilado de java nunca causou nenhum dano a estruturas de dados fora de seu escopo, se não houver outro problema (erro de compilador fe jit ou problema de baixo nível hw), embora as verificações de segurança de um código binário causem um poço desvantagem mensurável na velocidade.

Primeiro, ele não precisa ser um intérprete de bytecode java também. Um JIT (just in time compiler) poderia existir no espaço do usuário do sistema, mapeando apenas os arquivos binários compilados (praticamente: módulos do kernel) no espaço do kernel. Apenas o gerenciador de namespace e o coletor de lixo precisam ser executados no espaço do kernel.

Em segundo lugar, não precisa ser grande, lento e monstruoso. É porque as bibliotecas grandes, inefetivamente usadas no caso do userspace jvms, e não há motivo para o mesmo no caso de, por exemplo, um driver escrito em java .

O único fallback que eu posso ver foi com a funcionalidade em tempo real. É claro que foi muito mais difícil fazer com o java, porque temos muito menos controle sobre os pequenos detalhes do gerenciamento de memória.

Que tal eu estou curioso, se um projeto desse tipo já existe (? # 1), e há algum grande problema visível sobre isso, se não (? # 2).

    

Answer 1

Acho que este seria um projeto muito grande, já que você precisaria de uma implementação da JVM escrita em C com partes customizadas usando a API do kernel. O hotspot openjdk é aparentemente 250K + LOC em C e C ++. Note que você não pode usar o C ++ com o kernel do linux.

Methinks que poderiam funcionar em um número de pessoa-anos para implementar. É muito improvável que você possa incluí-lo na árvore de fontes oficiais, mas isso não é tão importante.

Considerando essa escala em relação ao que você chama de "a maior vantagem":

Of course the biggest advantage of a such system were the major simplification of the kernel space development.

Não tenho certeza do que você quer dizer com isso. Para as pessoas que podem codificar em Java, mas não em C, suponho que isso seja obviamente verdadeiro. Mas se você quer dizer em um sentido geral, não vejo como isso seria. Estou confortável com C e Java e não tenho uma strong preferência por um sobre o outro (contexto, ou alguém, tende a tomar essa decisão por mim). Talvez Java seja um pouco mais fácil de usar, por exemplo, você não precisa fazer MM (mas MM é realmente tão difícil?), Etc. - mas o IMO também pode parecer mais estranho e restrito.

Pessoalmente, não considero isso uma tarefa que valha a pena, mas isso não significa que seja impossível, ou uma má ideia. Seu maior obstáculo será encontrar outras pessoas para contribuir.

    

Answer 2

Ter JVMs no kernel não parece resolver muito. Embora seja verdade que a falta de ponteiros fornece isolamento razoável de partes independentes de código, ele também extrai o interpretador de bytecode Java (que é permanentemente mais lento que o código nativo) ou um compilador JIT (que é extremamente lento no início). E eu não estou mencionando o coletor de lixo, que eu suspeito que você esteja esperando resolver automaticamente alguns problemas (o que não será).

Outro problema a resolver seria a interface de qualquer hardware. Você precisaria de um trecho de código não trivial que permitiria que o código Java acessasse, placa de rede, SATA, (i) SCSI, USB, FibreChannel e miríades de outros controladores, placa de áudio e (um dos bits mais complicados, suponho) um acelerador gráfico. Isso levaria a uma parte substancial do código sendo escrita em outra linguagem mais próxima do bare metal (seja assembly ou C / C ++ - que na verdade não é muito mais do que uma montagem mais legível com maior nível de abstração).

No final, se escrever o código do kernel em Java fosse o objetivo final, provavelmente o faria de forma ligeiramente diferente: escrevê-lo em Java e compilar diretamente em código nativo.

1) every java developer with a relative minor lowlevel knowledge were able to develop a kernel module.

Escrever um módulo do kernel, que em 90% dos casos é relacionado a hardware, requer mais do que um conhecimento "menor" de hardware. Pessoas que conhecem Java, mas não entendem C profundamente, definitivamente não são os candidatos certos para escrever drivers de hardware (ou qualquer outro módulo do kernel).

Coloque em outra perspectiva: você confiaria em seus dados mais importantes (e eu nem estou falando sobre estar no suporte de vida controlado por tal kernel) a algo rodando em um kernel escrito por pessoas que não o fazem? entendeu C e assembly o suficiente para escrever um driver razoável?

2) (And it is the really intended goal): a JVM could solve the greatest problem of the kernel development, and it is the lack of the memory protection. A binary code segment compiled from java never caused any harm to data structures out of its scope, if there isn't another problem (f.e. jit compiler error or lowlevel hw problem), although the runtime safety checks of a such binary code caused a well measurable drawback in speed.

Proteção de memória com JIT? Requer que as páginas sejam graváveis e executáveis. Isso é um pesadelo de segurança, mesmo quando não tem acesso direto à memória (no sentido de poder usar ponteiros).

Se a segurança (e, portanto, o isolamento do código entre outros) for sua preocupação, os microkernels são o que você procura. Você pode até ter uma que seja formalmente verificada . Mais uma vez, o código só pode ser tão bom quanto o pior programador cujo código ainda está em - no melhor dos casos. A linguagem como tal não é de longe tão importante quanto as pessoas que a usam.

A propósito, sugiro strongmente que você leia esta resposta sobre a programação do sistema em vários idiomas no SO.