Recentemente, escrevemos sobre quais truques o Alibaba fez para tornar a vida com o OpenJDK mais aceitável. Houve comentários como "acontece que enquanto estamos sofrendo com Java comum, os chineses já fizeram seu próprio especial". Alibaba, é claro, é impressionante - mas a Rússia também tem seus próprios projetos fundamentais, onde eles também fazem “Java especial”.
Em Novosibirsk, há 18 anos eles fazem sua própria JVM , escrita de forma totalmente independente e com demanda muito além das fronteiras da Rússia. Não é apenas algum tipo de garfo HotSpot fazendo a mesma coisa, mas um pouco melhor. O Excelsior JET é um conjunto de soluções que permite que você faça coisas completamente diferentes em termos de compilação AOT. “Pff, o AOT está no GraalVM”, você pode dizer. Mas o GraalVM ainda é algo muito exploratório e o JET é uma solução comprovada para uso na produção.
Esta é uma entrevista com um dos desenvolvedores do Excelsior JET. Espero que seja especialmente interessante para todos que desejam descobrir coisas novas que podem ser feitas com Java. Ou as pessoas que estão interessadas na vida dos engenheiros da JVM e elas mesmas desejam participar disso.
No outono, voei para uma das conferências Java de Novosibirsk, sentamos com Ivan Uglyansky dbg_nsk e Nikita Lipsky pjBooms (um dos desenvolvedores do JET) e gravamos esta entrevista. Ivan está envolvido no tempo de execução do JET: GC, carregamento de classe, suporte a multithreading, criação de perfil, plug-in para GDB. Nikita - um dos iniciadores do projeto JET, participou da pesquisa e desenvolvimento de quase todos os componentes do produto, do kernel às propriedades do produto - OSGi no nível da JVM, Java Runtime Slim Down (módulos Java no JET já eram em 2007), dois verificadores de bytecode, suporte Bota de mola e assim por diante.
Oleg Chirukhin: Você pode contar para pessoas ignorantes sobre o seu produto?
Nikita Lipsky: É surpreendente, é claro, que estamos no mercado há 18 anos e não sabemos muito. Estamos fazendo uma JVM incomum. Incomum nas apostas na compilação AOT, ou seja, tentamos compilar antecipadamente o bytecode Java no código da máquina.
Inicialmente, a idéia do projeto era tornar o Java rápido. Produtividade é o que fomos ao mercado. E enquanto andávamos, o Java ainda era interpretado, e a compilação estática no código da máquina prometeu melhorar o desempenho do Java nem às vezes, mas por ordens de magnitude. Mas, mesmo na presença do JIT, se você compilar tudo com antecedência, não gastará recursos em tempo de execução na compilação e, portanto, poderá gastar mais tempo e memória e, eventualmente, obter um código mais otimizado.
Além do desempenho, um efeito colateral da compilação estática de bytecodes é a proteção dos aplicativos Java da descompilação. Como após a compilação não resta nenhum bytecode, apenas o código da máquina permanece. É muito mais difícil descompilar no código-fonte do que o bytecode Java. De fato, impossível. Ou seja, pode ser desmontado, mas você não dará origem aos códigos-fonte. Mas o código-fonte Java pode ser gerado a partir do código de código até nomes de variáveis facilmente, existem muitas ferramentas para isso.
Além disso, era uma vez assumido que o Java estava instalado em todos os computadores, você distribui seus aplicativos Java na forma de bytecode e eles executam o mesmo em todos os lugares. Mas, na realidade, nem tudo era tão bom, porque um tem um Java e o outro tem outro. Por esse motivo, se você distribuir o programa na forma de bytecode, todos os tipos de surpresas poderão ocorrer, começando com o fato de o usuário simplesmente não poder iniciar o programa, terminando com um comportamento estranho que você não poderá mostrar em si mesmo. Nosso produto sempre teve a vantagem de distribuir seu aplicativo Java simplesmente como um aplicativo nativo. Você não tem nenhuma dependência do tempo de execução que o usuário vale (ou não vale).
Ivan Uglyansky: Geralmente, você não precisa exigir a instalação do Java.
Oleg: Ainda existe uma dependência do sistema operacional, certo?
Nikita: Certo. Muitos criticam que, se você compilar em código nativo, seu slogan "Escreva uma vez - execute em qualquer lugar" para de funcionar. Mas isso não é verdade. Digo periodicamente nos meus relatórios que "escrever uma vez" soa como "escrever uma vez" e não "construir uma vez". Ou seja, você pode criar seu aplicativo Java em cada plataforma, e ele funcionará em qualquer lugar.
Oleg: Direto em todo lugar, em todo lugar?
Nikita: Onde quer que seja suportado. Temos uma solução compatível com Java. Se você escrever em Java, ele funcionará onde o Java funciona. E se você usar o compilado por nós, então onde o apoiaremos - Windows, Linux, Mac, x86, amd64, ARM32. Mas onde não o suportamos, você ainda pode usar Java regular para seus aplicativos, ou seja, a portabilidade de seus aplicativos Java nesse sentido não sofre.
Oleg: Existem projetos que são implementados de maneira diferente em plataformas diferentes? Partes da plataforma que não estão totalmente implementadas, algumas bibliotecas padrão.
Ivan: Isso acontece, mas não é específico do JET. Você pode observar, por exemplo, a implementação AsynchronousFileChannel no próprio JDK, que é completamente diferente em diferentes Windows e Posix, o que é lógico. Algumas coisas são implementadas apenas em determinadas plataformas, suporte para SCTP (consulte sun.nio.ch.sctp.SctpChannelImpl no Windows) e SDP (consulte sun.net.sdp.SdpSupport). Não há nenhuma contradição específica nisso, mas realmente acontece que "Escreva uma vez, corra para qualquer lugar" não é bem verdade.
Falando especificamente sobre a implementação da JVM, em diferentes sistemas operacionais, a diferença, é claro, pode ser enorme. Qual é o fato de que no OS X no thread principal você precisa executar o loop de eventos do Cocoa, para que o lançamento seja diferente do resto.
Nikita: No entanto, do lado de fora, para o usuário, tudo parece e funciona quase da mesma forma.
Oleg: E o desempenho? É o mesmo em todas as plataformas?
Nikita: Há uma diferença. Por exemplo, um sistema de arquivos Linux funciona melhor e mais rápido que um sistema de arquivos Windows.
Oleg: E portando entre processadores?
Nikita: Esta é uma atividade divertida! De repente, toda a equipe começa a portar. O entretenimento geralmente dura de seis meses a um ano.
Oleg: Acontece que algum código em outra plataforma começa a ficar mais lento?
Ivan: Isso pode ser devido ao fato de que simplesmente não tivemos tempo para fazer ou adaptar algum tipo de otimização. Funcionou bem no x86, depois mudamos para o AMD64 e simplesmente não conseguimos adaptá-lo. Por isso, pode ser mais lento.
Outro exemplo de desempenho. O ARM possui um modelo de memória fraco; é preciso colocar muito mais barreiras para que tudo funcione corretamente. Tivemos AMD64, alguns lugares funcionaram, pensamos, livres então, porque lá o modelo de memória é diferente. No ARM, você precisa colocar mais barreiras, mas isso não é gratuito.
Oleg: Vamos falar sobre o assunto atual agora - "Java em dispositivos incorporados".
Digamos que estou fazendo um avião que voe com controle em um Raspberry Pi. Quais são alguns dos problemas típicos que uma pessoa tem quando faz isso? E como a compilação JET e geralmente AOT pode ajudar nesse assunto?
Nikita: O avião no Raspberry Pi é, obviamente, um tópico interessante. Criamos o ARM32 e agora o JET está no Raspberry Pi. Temos um número ilimitado de clientes para incorporados, mas não há muitos para falar sobre seus problemas "típicos". Embora eles tenham alguns problemas com Java, não é difícil adivinhar.
Ivan: Quais são os problemas com o Java no Raspberry Pi? Há um problema com o consumo de memória. Se você precisar demais, o aplicativo e a JVM têm dificuldade em viver com o pobre Raspberry Pi. Além disso, é importante iniciar rapidamente os dispositivos incorporados para que o aplicativo não acelere por muito tempo. A AOT resolve bem esses dois problemas, por isso estamos trabalhando para melhorar o suporte incorporado. Especificamente, em relação ao Raspberry Pi, vale a pena mencionar a Bellsoft , que agora está ativamente envolvida nisso com o HotSpot. Java normal está totalmente presente lá.
Nikita: Além disso, existem poucos recursos em sistemas embarcados; o compilador JIT não tem para onde implantar. Por conseguinte, a compilação AOT, por si só, acelera o desempenho.
Novamente, os dispositivos incorporados estão sem conexão à rede, com uma bateria. Por que existe uma bateria para o compilador JIT se você pode montar tudo com antecedência?
Oleg: Quais recursos você tem? Entendo que o JET é um sistema complexo muito grande, com um monte de tudo. Você tem uma compilação AOT, ou seja, é possível compilar um executável. O que mais? Quais são alguns componentes interessantes que vale a pena falar?
Ivan: Temos vários recursos relacionados ao desempenho.
Recentemente, falei sobre o PGO, nosso recurso relativamente novo. Temos um criador de perfil interno diretamente na JVM, bem como um conjunto de otimizações com base no perfil que ele coleta. Após recompilar com base no perfil, geralmente obtemos um sério aumento de desempenho. O fato é que as informações de desempenho são adicionadas às nossas poderosas análises e otimizações estáticas. É uma abordagem um pouco híbrida para tirar o melhor proveito da compilação JIT e AOT.
Temos dois recursos maravilhosos para uma aceleração de lançamento ainda mais rápida. A primeira é quando você olha para a ordem em que as páginas de memória são perfuradas inicialmente, simplesmente a monitora e vincula o executável de acordo.
Nikita: Segundo, quando você inicia o executável, entende quais pedaços de memória estão sendo puxados para cima e, em vez de puxá-los em qualquer ordem, puxa o pedaço desejado de uma só vez. Também acelera bastante o lançamento.
Ivan: Esses são recursos individuais de supermercado.
Nikita: O primeiro é chamado Startup Optimizer, e o segundo é Startup Accelerator. Os recursos funcionam de maneira diferente. Para usar o primeiro, você precisa executar o aplicativo antes da compilação, ele lembrará em que ordem o código foi executado. Em seguida, na ordem correta, esse código será vinculado. E o segundo é o lançamento do seu aplicativo após a compilação, então já sabemos o que foi onde e onde, e depois disso perfuramos tudo na ordem certa no lançamento.
Além dos recursos relacionados ao desempenho, existem vários recursos do produto que tornam o JET mais conveniente de usar.
Por exemplo, podemos empacotar, digamos, distribuições do Windows. Uma vez - e conseguiu um instalador do Windows. Você pode distribuir aplicativos Java como aplicativos nativos reais. Há muito mais. Por exemplo, há um problema padrão com os compiladores AOT e Java quando um aplicativo usa seus próprios carregadores de classe. Se você possui seu próprio carregador de classes, não está claro quais classes nós iremos compilar? Porque aí a lógica da resolução entre as classes pode ser qualquer coisa. Portanto, nenhum compilador Java AOT, exceto o nosso, trabalha com carregadores de classes não padrão. Temos suporte especial no AOT para algumas classes de aplicativos, onde sabemos como seus carregadores personalizados funcionam, como os links entre as classes são resolvidos. Por exemplo, temos suporte para o Eclipse RCP e existem clientes que escrevem aplicativos de desktop no Eclipse RCP e compilam conosco. Há suporte para o Tomcat, carregadores personalizados também são usados lá. Você pode compilar aplicativos Tomcat conosco. Também lançamos recentemente uma versão do Spring Boot JET pronta para uso.
Oleg: Qual servidor existe "abaixo"?
Nikita: O que você quiser. Quais Spring Boot suportam funcionarão com isso. Tomcat, Ressaca, Molhe, Webflux.
Ivan: Aqui é necessário mencionar que, para o Jetty, não temos o suporte de seus carregadores de classes personalizados.
Nikita: O Jetty, como um servidor da web independente, possui um carregador de classe personalizado. Mas existe o Jetty Embedded, que pode funcionar sem carregadores personalizados. O Jetty Embedded roda silenciosamente no Excelsior JET. Dentro do Spring Boot, o Jetty funcionará na próxima versão, como qualquer outro servidor suportado pelo Spring Boot.
Oleg: De fato, a interface do usuário com o JET é javac e Java, ou algo mais?
Ivan: Não. Para o usuário, temos várias opções para usar o JET. Primeiramente, esta é uma GUI na qual o usuário perfura todos os recursos, depois pressiona um botão e seu aplicativo é compilado. Quando ele quer fazer algum instalador para que o usuário possa instalar o aplicativo, ele mais uma vez aperta os botões. Mas essa abordagem está um pouco desatualizada (as GUIs foram desenvolvidas em 2003), então agora temos Nikita desenvolvendo e desenvolvendo plugins para Maven e Gradle, que são muito mais convenientes e familiares para os usuários modernos.
Nikita: Substitua sete linhas em pom.xml ou build.gradle, por exemplo, mvn jet:build e você terá um palito de salsicha na saída.
Oleg: E agora todo mundo ama muito o Docker e o Kubernetes, você pode construir para eles?
Nikita: Docker é o próximo tópico. Temos esse parâmetro - empacotando nos plugins Maven / Gradle. Posso adicionar aplicativos de empacotamento para o Docker.
Ivan: Isso ainda está em andamento. Mas, no geral, tentamos aplicativos compilados pelo JET para rodar no Docker.
Nikita: Funciona. Sem Java. Linux nu, cole o aplicativo compilado por JET lá e ele será iniciado.
Oleg: E com a embalagem da janela de encaixe, qual será a saída? Empurrar um contêiner ou um executável com as mãos no arquivo Docker?
Nikita: Agora você acabou de escrever um arquivo Docker específico do JET - estas são três linhas. Além disso, tudo funciona através de ferramentas regulares do Docker.
Estou jogando com microsserviços agora. Eu os compilo com o JET, corro, eles se descobrem, se comunicam. A JVM não precisou fazer nada para isso.
Oleg: Agora todos os tipos de provedores de nuvem lançaram coisas como Amazon Lambda, Google Cloud Functions, posso usá-lo lá?
Nikita: Acho que precisamos procurar os fornecedores de todas essas coisas e dizer que, se você nos usar, todas as suas lambdas funcionarão mais rapidamente. Mas isso ainda é apenas uma ideia.
Oleg: Então eles realmente trabalharão mais rápido!
Nikita: Sim, provavelmente, mais trabalho precisa ser feito nessa direção.
Oleg: Eu vejo um problema no tempo de compilação lambda. Qual é o seu tempo de compilação?
Ivan: Existe, e esse é um problema no qual os usuários de JVMs comuns com JITs não pensam. Geralmente, afinal, como - iniciei o aplicativo, ele funciona (embora lentamente no início por causa da compilação). E aqui vem uma etapa separada para compilar o aplicativo inteiro por AOT. Como isso pode ser sensível, estamos trabalhando para acelerar essa fase. Por exemplo, temos uma recompilação incremental quando apenas as partes alteradas do aplicativo são recompiladas. Chamamos isso de recompilação inteligente. Acabamos de fazer isso no último período virgem com Nikita, fomos emparelhados.
Nikita: Existem certos problemas com o Java e com a recompilação inteligente, por exemplo, dependências circulares dentro de aplicativos Java - eles estão por toda parte.
Ivan: Existem muitos problemas bastante óbvios lá, até você pensar nessa tarefa. Se você possui um compilador AOT estático que realiza várias otimizações globais, não é tão fácil calcular o que exatamente precisa ser recompilado. Você precisa se lembrar de todas essas otimizações. E as otimizações podem não ser triviais. Por exemplo, você pode fazer todos os tipos de desvirtualizações complexas, alinhar algo que o diabo sabe onde. Se você alterou um JAR clássico ou um JAR, isso não significa que apenas ele precisa ser recompilado e é isso. Não, tudo isso é muito mais confuso. Você precisa calcular e lembrar de todas as otimizações que o compilador fez.
Nikita: Na verdade, fazendo o mesmo que o JIT faz quando toma uma decisão sobre a otimização, mas apenas no compilador AOT. Somente a solução não será sobre desoptimização, mas sobre recompilação.
Oleg: Sobre a velocidade da compilação inteligente. Se eu pegar "Olá, Mundo", compile-o e altere as duas letras da palavra "Olá" ...
Nikita: Compila rapidamente.
Oleg: Quero dizer, nem um minuto?
Nikita: Segundos.
Ivan: Mas ainda depende de incluirmos classes de plataforma no executável.
Oleg: E o que é possível sem isso?
Nikita: Sim, por padrão, nossa plataforma é vista em várias DLLs. Implementamos o Jigsaw desde o início :-) Ou seja, vimos as classes Java SE em componentes há muito tempo, em cerca de 90 anos.
Ivan: O ponto é que nossas classes de tempo de execução e plataforma - todas são pré-compiladas por nós e sim - são divididas em DLLs. Quando você executa o aplicativo compilado pelo JET, o tempo de execução e a plataforma inteira são apresentados no formato dessas DLLs. Ou seja, como resultado, fica assim: você pega "Olá, mundo", compila, compila realmente uma classe. Isso acontece em alguns segundos.
Nikita: Em 4 segundos, se no global; em alguns segundos, se não no global. "Global" é quando você vincula: todas as classes de plataforma compiladas em código nativo em um grande executável.
Oleg: Posso fazer uma recarga quente?
Nikita: Não.
Oleg: Não? Tristeza. Mas seria possível gerar uma DLL, vinculá-la novamente e depois ...
Nikita: Como temos o JIT (a propósito, sim, também temos o JIT!), É claro que você pode carregar, descarregar e recarregar partes do código. Por exemplo, todo o código que funciona através do nosso JIT está no mesmo OSGI - você pode recarregá-lo, se desejar. Mas aqui está a recarga a quente que o HotSpot possui: quando você se senta no depurador e altera o código rapidamente, nós não. Isso não pode ser feito sem perda de desempenho.
Oleg: No estágio de desenvolvimento, o desempenho não é tão importante.
Nikita: Na fase de desenvolvimento, você usa o HotSpot e não precisa de mais nada. Somos uma solução compatível com Java. Se você usar o HotSpot e recarregar a quente na depuração, tudo estará bem. JET compilado e depurado, e tudo funciona como no HotSpot. Deveria ser assim. Geralmente assim. Se não, você escreve para apoiar, nós entendemos.
Oleg: E quanto à depuração no JET? JVM TI? Quanto tudo é suportado?
Ivan: Um dos principais valores do uso do JET é a segurança. O código personalizado não estará disponível para ninguém. Porque tudo é compilado em nativo. Existem algumas contradições com isso, apoiamos a JVM TI? Se suportarmos, significa que qualquer desenvolvedor desenvolvido que saiba como a JVM TI funciona poderá acessar rapidamente qualquer coisa. No momento, não oferecemos suporte à JVM TI.
Nikita: Este é um item de especificação opcional. Pode ser suportado por implementadores de plataforma, pode não ser suportado.
Ivan: Há muitas razões. É opcional e viola a segurança, o que significa que os usuários não vão dizer "obrigado" para nós. E ela está dentro é muito específico do HotSpot. Há não muito tempo atrás, nossos funcionários apoiaram a JVM TI como um projeto experimental, atingiram um certo estágio, mas o tempo todo se deparavam com o fato de estar muito focado no HotSpot. Em princípio, isso é possível, mas que tarefa comercial será resolvida?
Nikita: Depois que você ganhou dinheiro no HotSpot, mas não ganhou dinheiro em um jato - esse não é o seu problema. Esse é o nosso problema.
Oleg: Entendi. Você tem algum recurso adicional que
não no HotSpot, mas você tem um e eles exigem controle direto? O qual eu gostaria de depurar, resolva-os.
Nikita: Exatamente um recurso. Temos uma extensão oficial da plataforma chamada Windows Services, ou seja, você pode compilar aplicativos Java na forma de serviços reais do Windows que serão monitorados por meio de ferramentas padrão do Windows para serviços do Windows e assim por diante. Nesse caso, você deve escolher nosso próprio JAR para compilar esses aplicativos.
Oleg: Este não é o maior problema.
Nikita: A interface é muito simples para esses serviços. E para depuração, você usa os métodos para iniciar seu próprio aplicativo não como um Serviço do Windows, mas através do main. Algum tipo de depuração específica do serviço, não sei se é necessário.
Oleg: Suponha que um novo desenvolvedor que já trabalhou para o HotSpot queira desenvolver algo usando o JET, ele precisa aprender algo, entender algo em geral sobre a vida ou sobre o JET?
Ivan: Ele precisa copiar sete linhas no pom.xml, se o Maven for usado, execute o jet: build e se o JET estiver na máquina, o aplicativo Java será compilado em um executável. A idéia é que é simples, você não faz nada de especial, apenas aceita, obtém um executável e é isso.
Nikita: Ou você conhece a linha de comando com a qual seu aplicativo é iniciado e, em seguida, coloca essa linha de comando na nossa GUI, ela descobrirá. Você dá o comando build, você obtém o executável, só isso.
Ivan: É muito simples, você não precisa inventar nada de novo. Como o hotspot AOT funciona, você mesmo mostrou no relatório que precisa obter uma lista de todos os métodos em um arquivo, varrê-lo e transformá-lo - não precisamos fazer nada assim. Basta pegar sua linha de inicialização no HotSpot, colá-la em uma GUI especial ou adicionar um pequeno pedaço ao pom.xml e, depois de um tempo (porque ainda é uma compilação da AOT), você obtém um arquivo exe, que pode ser executado.
Oleg: Preciso aprender a trabalhar com a GC?
Nikita: Sim, nós temos nosso próprio GC, precisamos ajustá-lo de uma maneira diferente, não como no HotSpot. Temos muito poucas canetas públicas.
Oleg: Existe uma caneta para "fazer o bem" ou "não fazer"?
Ivan: Existe uma caneta. Há uma caneta "defina Xmx", há uma caneta "defina o número de trabalhadores" ... Muitas canetas, mas por que você precisa saber sobre elas? Se algo inesperado acontecer com você - escreva.
Obviamente, temos muitas coisas para configurar para o GC. Podemos ajustar a geração mais jovem, podemos frequência de chegada do GC. Tudo isso está ajustado, mas essas geralmente não são opções aceitas. Entendemos que as pessoas conhecem -Xmx e apontam isso, então analisamos. Existem algumas opções geralmente aceitas que funcionam com o JET, mas, em geral, tudo é diferente.
Nikita: Também temos uma opção pública que permite definir quanto você permite que o GC gaste tempo com seu aplicativo.
Oleg: Porcentagem?
Nikita: Em décimos de um por cento. Percebemos que o interesse é muito rude.
Ivan: Se você se interessa pelo GC, algo está errado com você.
Oleg: E aqui estão todas essas pessoas de empresas que fazem tudo o que fazem durante o horário de trabalho - elas abrem uma impressão do trabalho da GC com o cronograma e meditam. Você pode meditar?
Nikita: Temos pessoas especiais dentro da empresa que meditam.
Ivan: Temos nosso próprio formato de log, portanto é improvável que as pessoas entendam algo dele. Embora você nunca saiba? Se eles olharem para ele por um longo tempo, talvez eles possam entender. Tudo está escrito lá. Mas, provavelmente, é melhor nos enviar e meditaremos.
Oleg: Mas é claro, você fará isso pelo dinheiro, mas você também pode procurar um brinde.
Nikita: Se você é nosso cliente, então você tem suporte, e fazemos isso, é claro, como parte do suporte.
Ivan: Mas se você tiver algum problema óbvio, podemos até dizer sem apoio.
Oleg: Se isso é algum tipo de bug?
Nikita: Se for um bug, é claro que aceitamos de todos e sempre. Não é assim ", até que você compre, não corrigiremos o erro". Se um bug, então nós o corrigimos. Em geral, os usuários adoram o nosso apoio. Geralmente eles dizem que é de alta qualidade e que não viram nada parecido em nenhum lugar. Talvez o fato seja que nós mesmos estamos apoiando, giramos por sua vez.
Oleg: Quem são eles mesmos?
Nikita: desenvolvedores, engenheiros de JVM.
Oleg: Com que frequência?
Nikita: A frequência é diferente. Geralmente nos sentamos em turnos por duas semanas. Mas se você é obrigado a fazer uma megafone em um determinado número de dias, nesse momento receberá imunidade de apoio para poder se concentrar nessa tarefa.
Ivan: Em teoria, todos deveriam fazer isso por sua vez. Mas às vezes alguém heroicamente toma a segunda dose e suporta por um mês ou mais, e não duas semanas. Pessoalmente, gosto de apoiar, mas se você faz isso por muito tempo, esquece um pouco o que faz na vida, porque só começa a responder cartas. Mas você ainda deseja salsichar a JVM. Portanto, depois de algum tempo, você precisa retornar.
Oleg: E você tem uma hierarquia, quantos níveis de gerenciamento? 20 ou mais?
Nikita: O que você é, somos apenas 10 pessoas em uma equipe.
Ivan: 15 com os alunos.
Oleg: Quero dizer que as autoridades estão envolvidas nisso ou estão apenas procurando?
Nikita: Sobre os chefes. Obviamente, existe uma pessoa principal e muitos líderes locais.
Oleg: Cada pessoa tem sua própria área?
Nikita: Uma pessoa que assume uma grande tarefa e a administra. Também gira. Você pode assumir uma grande tarefa e liderar uma vez, e da próxima vez eles o liderarão.
Ivan: Em geral, não temos uma grande hierarquia. Temos um nível de chefes. E sobre olhar de cima - absolutamente não. Às vezes, nossos chefes heroicamente assumem suporte se houver um lançamento próximo.
Nikita: Os chefes são uma pessoa, o nome dele é Vitaly Mikheev.
Oleg: Você pode vê-lo em algum lugar? Em conferências ou em outro lugar?
Nikita: Em geral, meus discursos nas conferências começaram com o fato de o Dia de São Petersburgo em Java chegar até Novosibirsk, que foi organizado por Belokrylov, da Oracle, que agora está na Bellsoft. Ele perguntou se gostaríamos de conversar e depois nos apresentamos com Vitaly. Então sugeri que ele continuasse se apresentando juntos, mas ele decidiu que não queria mais.
Oleg: E que tipo de relatório?
Nikita: "A história de uma JVM em fotos . "
Ivan: Lembro-me deste relatório, então eu era estagiário ou deixei de ser um. E ainda acho que esse é um dos melhores relatórios que já vi.
Nikita: Talvez tenha sido o “efeito de estréia” quando você se apresenta pela primeira vez em sua vida, pressiona bem com energia.
Oleg: Do que você estava falando?
Nikita: Eles conversaram sobre o JET do início ao fim por 20 minutos.
Oleg: Para dois, apenas 20 minutos? Normalmente, quando existem várias pessoas, o tempo para um relatório aumenta apenas.
Nikita: Nós conversamos muito vigorosamente e animadamente sobre todos os tópicos principais.
Oleg: Vanya, isso afetou sua decisão sobre o que fazer a seguir? Você trabalha para a empresa?
Ivan: Poderia ser!
Oleg: as pessoas geralmente perguntam por que participar de conferências, apresentações, por que ouvir algo, se você pode pesquisar no Google.
Nikita: Claro, na minha opinião, participar de uma conferência é muito útil. Quando você tem contato ao vivo, participação direta, não é nada o que ver no YouTube. É importante que você esteja participando diretamente, não virtualmente. Você está em contato com a fonte. A diferença é quase a mesma que assistir a um concerto ao vivo ou ouvi-lo em uma gravação. Provavelmente até grande, porque quanto você pode falar com seu artista favorito após o show? Mas na conferência você encontra o orador de que precisa e pede a ele tudo o que precisa - não há problemas.
Ivan: A propósito, com relação à decisão de "permanecer na empresa", essa é uma história diferente. Temos um sistema de recrutamento bastante exclusivo para funcionários / estagiários. Realizamos estagiários para 2 a 3 cursos, geralmente do corpo docente ou do departamento de física. Os estagiários estão profundamente imersos no tópico, os curadores os ajudam a entender vários mecanismos de VM, detalhes de implementação etc. - custa muito.
Depois de algum tempo, eles começam a dar missões de combate, a escrever códigos reais na produção. Você faz alterações na JVM, passa por revisões, testes, benchmarks - verifique se elas não estão cedidas. Você se compromete pela primeira vez. Depois disso, você se concentra no seu diploma. Geralmente, um diploma também é uma parte interessante da pesquisa experimental da JVM. Isso geralmente é feito pelos alunos. Então você pode produzi-lo - ou talvez não. Eu nunca vi uma coisa dessas para gastar tanto tempo com estagiários. Pessoalmente, eu realmente aprecio isso, porque lembro quanto tempo gastei comigo. A saída é um engenheiro da JVM. Onde mais existe uma fábrica dessas sobre a produção de engenheiros da JVM?
Oleg: E você não tem medo do vazamento de informações dos estagiários, então eles descreverão abertamente tudo isso em um diploma?
Nikita: Isso não é um problema, porque temos medo de um vazamento no exterior e, especialmente, ninguém vai ler russo - essa é a proteção, a ofuscação :-)
Ivan: Eu tinha um aluno defendendo este ano, eu era o líder, e havia um problema que nem todo mundo queria escrever em um diploma. Revelamos algo de um tópico completamente fechado e, por exemplo, um revisor nos perguntou por que não estávamos falando sobre certas coisas. Eu disse a ele que você não pode falar sobre isso, é muito secreto, não podemos. É, eu vou te dizer no seu ouvido, mas não vai para nenhum outro lugar. Portanto, temos um pouco de medo disso, mas, em geral, você pode encontrar muitas coisas interessantes nos diplomas.
Oleg: E como procurar diplomas que envolvam Excelsior?
Nikita: Venha ao escritório do reitor e peça para ler esse diploma.
Ivan: Temos uma lista de diplomas defendidos com sucesso em nosso site, mas apenas nomes, sem links. E não temos defendidos sem sucesso.
Oleg: Eles morrem ou se defendem.
Ivan: É! Temos uma pontuação média de 5,0 graduados, há quem simplesmente não vá a um diploma.
Oleg: Neste treinamento, a fábrica de engenheiros da JVM, diz-nos quais são os estágios de se tornar um Jedi? Quando eles dão um sabre de luz, quando você pode começar a acenar?
Nikita: Muito rápido. Agora os jovens estão dolorosamente se tornando Jedi, tenho orgulho deles.
Ivan: A propósito, Nikita foi minha primeira curadora quando eu era estagiária. Em relação ao estágio: primeiro você faz uma seleção: resolve problemas, participa de uma ou mais entrevistas. Se está tudo bem, você se torna um trainee. Inicialmente, você lê artigos científicos sobre tópicos que provavelmente estão relacionados ao seu futuro diploma ou apenas sobre tópicos da JVM em inglês para obter o contexto. Você lê, escreve um ensaio sobre eles, explica o que está acontecendo lá. Eles são muito duros com ele. Alguns estudiosos invejariam essa revisão e tal preparação de ensaio. Acontece artigos completos em russo. Depois disso, é hora de você escrever o código e, lentamente, você está sendo apresentado à essência do assunto - como tudo funciona.
Nikita: E é aqui que a ciência termina.
Ivan: Não necessariamente!
Nikita: É uma pena, no início do zero, publicamos artigos que levamos para as revistas da ACM.
Ivan: Bem, estamos fazendo agora, qual é o problema?
Nikita: Qual foi nosso último artigo na revista ACM?
Ivan: Então, no ACM, simplesmente não tentamos! Agora estamos blogando - é a mesma coisa, apenas as pessoas leem. Esta é uma atividade semelhante.
Voltando ao tópico Jedi, depois disso, pela primeira vez, você faz algo em produção sob controle estrito. É necessária uma pequena tarefa que não esteja relacionada ao seu futuro diploma.
Oleg: Por exemplo, escrevendo um comentário.
Ivan: Não. Verdadeira funcionalidade. O aluno deve fazer sua primeira contribuição real para que ele permaneça no produto. , - , . , -, — . , . , JVM-.
: ? ? - , , - ? ?
: , . - — - , , , , , , JVM. , , , . , : « !». .
: JET?
: , JVM .
: - , JET — JET. , - , : baseline-. , . , , JET .
: ?
: , . , .
: - , baseline .
: , baseline JIT. , JIT , . , baseline. . - , baseline, .
: - UI-? .
: . . Windows.
: , . , Mac.
: Android ?
: . , Android Linux-, Linux . Linux Android . - . .
: ?
: ? Não.
: Android Native SDK. DLL .
: , - , . SO- - , , Linux, , , . Java Android, , SO-, Java Dalvik . 90 , , -.
: iOS ?
: . Android, iOS. , , .
: , 15 .
: iOS . , .
: , .
: ?
: , — .
: . ?
: — JVM, JVM — , , , , , — , . , . . GC - , , . , , , .
: , , , . , , . GDB .
: , . , .. , .. managed- Java/Scala, ( ) IDEA, . — GDB .
: , , unit- , !
: . . , , , . JVM. -, . , : , - « - ( ) . ».
, , — , JVM.
: ?
: .
: . . Spring Boot , JET , .
: , - . , , , — . , JIT, . , .
: JIT — , ?
: , .
: , - , .
: , ? , -, , .
: , , - -. - , , . , . , - . issue-, , . , , .
, . , — , -. , . check-in , 1.5-2 .
: Visual Source Safe, check-in. VSS , check-in . VSS, check-in .
: , JET, JVM , . 1.5-2 . JET, , . - , , , — . ? . .
: JET Scala?
: Scala.
JET Scala, JET-. JET- . , . , Scala-, scalac, …
: check-in Java- , , , .
: - , C++ ?
: , . , , .
: JVM- — , - , . — . , , , — , . , . « ». . , , , :-) — . , GC, - - . , - , , . , - . .
: , ?
: . , . , . QA-, — , . , .
: ?
: , . , , . , . C GC . , , - . , GC - — . - . ? ?
: , .
: , -, . . , — . . - .
: , , , .
: , - ?
: - , .
: JIT?
: JIT . assert, , -, , . .
: , . JCK . - JCK, , . , . UI-, GUI-, JET. - . , GitHub JET-. JET- . QA- , .
: , ? , , ?
: QA Lead — -. QA, . , . , , . , .
: , QA ? , QA-, , — , , . , , - -.
: , . , , , - . , QA Lead , . JVM-, , .
: ? - , QA- , — ?
: JCK, Oracle. Oracle , . - . JCK, - , , , .
: , JCK?
: Oracle. , JVM, - , Oracle.
: . , Open JDK, JCK.
: - , , - , — , . , , - Oracle. , , Oracle .
: ?
: . , - , «value add». JCK, Java, . JCK , — .
: ! , OpenJDK, ?
: . , 70 . , JCK, , , . , , JET , HotSpot . .
: ? .
: Oracle JVM. . « JVM» Joker.
: ?
: , . JVM. : JVM- , , , . , .
: , JCK ?
: , . mailing list, (Alex Buckley), , Java/JVM-, JVM Specification 12.
: JCK .
: JCK, Sun . , — .
: — , ?
: , . . , , CORBA. , - , . 6 , CORBA . , , HotSpot, , , .
: , — ?
: . CORBA , . Swing . JCK Swing, , . .
: « JCK».
: , , JCK . .
: ?
: , , , , , .
: , .
: - , . , . .
: , ?
: , .
: . , . : , . , JCK, Java.
, . - .
: — . , , — . , - . , . , .
: - , ? ?
: — . , - - , - - . Java - ! , GC. — — , .
: , , . (, JVM ). , ? Mas nada. , - - , . JVM , . , .
Java . , , — . Loom Metropolis, Java. - JVM, , , , , . Loom , , . . , — .
. , Java — , 5-6 Java- JPoint . , Java- (Simon Ritter, Rafael Winterhalter). , Call for Papers 31 . . , YouTube. JPoint!