O sun.misc.Unsafe dá acesso ao sistema ou apenas à JVM?

5

Por favor, note : Embora esta questão envolva microcontroladores, ela é fundamental, uma pergunta Java , e então eu acredito que ela pode ser respondida por qualquer Java cansado de batalha guru.

Eu tropecei em este blog falando sobre sun.misc.Unsafe e estava tentando entender suas capacidades completas para ver se era apropriado para um projeto de hobby meu.

Na vista de 30.000 pés, estou tentando programar um chip ARM (Arduino Due - um ARM SAM3X8E MCU) para acionar alguns periféricos IO (piscar alguns LEDs, servos de acionamento, etc.) em um dispositivo eletrônico simples. Para um bom esporte, eu amaria fazer isso em Java puro, se possível. Até ler esse artigo, eu nem achei que isso fosse possível, e imaginei que teria que fazer a maioria, se não toda a programação em C. Porque esse sabor do ARM pode suportar o Linux, especialmente um "estilo unikernel" despojado "do Linux, eu gostaria de escrever meu programa controlador inteiramente em Java e implementá-lo em um local (digamos, /opt/myapp ) em uma imagem do Linux que eu possa, então, piscar para o chip ARM. Com um pouco de mexer / hackear, eu conseguiria que o chip ARM rodasse o aplicativo Java quando o dispositivo for ligado.

Minha pergunta

Para acionar os periféricos de IO do meu dispositivo, preciso acessar endereços de memória específicos que existirão fora do processo da JVM que está executando meu aplicativo. Até agora eu estava com a impressão de que as JVMs " sandbox " seus aplicativos residentes, impedindo-os de acessar qualquer coisa diretamente na memória do sistema. E então meu plano foi escrever um monte de código C (que na verdade direciona os periféricos, pisca LEDs, etc.) e então fazer com que meu aplicativo invoque esse código C através do JNI.

Mas se eu estou lendo o blog corretamente, parece que sun.misc.Unsafe me dá acesso à memória do sistema fora da JVM. Se isso for verdade, então tecnicamente não preciso de nenhum código em C. É claro que estou cometendo todo tipo de falta de segurança, tornando meu código não portátil, etc. Mas tudo bem: esse é apenas um projeto de hobby executado em uma plataforma específica que não pretendo alterar.

Então, eu pergunto: estou entendendo Unsafe corretamente e, em caso afirmativo, há outras ressalvas / restrições / limitações que eu deva considerar ao usá-lo?

    
por smeeb 19.05.2015 / 03:24
fonte

2 respostas

4

sun.misc.Unsafe não faz parte do padrão Java. Assim, sua primeira tarefa será determinar se a implementação Java que você estará executando no chip ARM a suporta.

Se a resposta acima for sim, você deve se perguntar se os endereços de E / S que você precisa acessar estão mapeados no processo da JVM . Inseguro permite que você escape do modelo usual de memória Java, mas não tem nenhum recurso para escapar do espaço de endereço do processo da JVM. Não seria incomum que os endereços de E / S de hardware fossem graváveis somente a partir do espaço de endereço do kernel, mas sua plataforma pode ser diferente.

Supondo que você tenha os endereços de E / S mapeados no processo da JVM, o último obstáculo é verificar se todos os protocolos que você planeja usar são lentos ou flexíveis o suficiente com o tempo que você pode guiá-los a partir de um processo Java. pode estar sujeito à coleta de lixo mundial e a outros fatores que o tornam não-mesmo-remotamente em tempo real.

Se tudo isso der certo, parece um projeto interessante.

Ah, espere, você também precisa descobrir uma maneira de encaixar o Linux e uma JVM em 512 KB de memória flash ... e executá-los em 100 KB de RAM. Parece que você precisaria atualizar para um chip significativamente mais potente para realizar este conceito, provavelmente um com um controlador DRAM para poder anexar quantidades razoáveis de RAM.

    
por 19.05.2015 / 11:46
fonte
2

Se você quiser programar um chip barato (32 bits) ARM em Java (que provavelmente não é uma boa idéia ) e se você aceitar código contra uma versão antiga da linguagem de programação Java, você pode considerar usar gcj , o compilador Java à frente do tempo dentro de algumas versões do GCC .

(Cuidado, o suporte Java no GCC parece ter sido eliminado em 2015, ou pelo menos está se tornando menos importante para a comunidade do GCC)

No entanto, você pode querer usar outro idioma. Se a coleta de lixo for significativa para você, use D , ou , ou até mesmo use (talvez portando-o para o metal) a coletor de lixo conservador Boehm em C (ou mesmo em C ++, veja this - que é usado por gcj . Você também pode considerar a codificação em Ocaml , consulte MirageOS . E o Rust não é coletado como lixo, mas pode ser útil em um pequeno chip ARM.

Leia também a página wiki em Java em tempo real

    
por 19.05.2015 / 12:09
fonte

Tags