Hace poco escribimos sobre qué trucos hizo Alibaba para hacer la vida con OpenJDK más aceptable. Hubo comentarios como "resulta que si bien estamos sufriendo con Java común, los chinos ya han hecho su propio especial". Alibaba, por supuesto, es impresionante, pero Rusia también tiene sus propios proyectos fundamentales, donde también hacen "Java especial".
En Novosibirsk, durante 18 años, han estado haciendo su propia JVM , escrita de manera completamente independiente y en demanda mucho más allá de las fronteras de Rusia. No es solo una especie de horquilla HotSpot que hace lo mismo, sino un poco mejor. Excelsior JET es un conjunto de soluciones que le permite hacer cosas completamente diferentes en términos de compilación AOT. "Pff, AOT está en GraalVM", puedes decir. Pero GraalVM sigue siendo algo muy exploratorio, y JET es una solución comprobada para su uso en producción.
Esta es una entrevista con uno de los desarrolladores de Excelsior JET. Espero que sea especialmente interesante para todos los que quieran descubrir cosas nuevas que se pueden hacer con Java. O las personas interesadas en la vida de los ingenieros de JVM y ellos mismos quieren participar en esto.
En el otoño, volé a una de las conferencias Java de Novosibirsk, nos sentamos con Ivan Uglyansky dbg_nsk y Nikita Lipsky pjBooms (uno de los desarrolladores de JET) y grabamos esta entrevista. Ivan se dedica al tiempo de ejecución JET: GC, carga de clases, soporte de subprocesamiento múltiple, creación de perfiles, complemento para GDB. Nikita, uno de los iniciadores del proyecto JET, participó en la investigación y el desarrollo de casi todos los componentes del producto desde el kernel hasta las propiedades del producto. Bota de primavera y así sucesivamente.
Oleg Chirukhin: ¿Puedes decirle a las personas ignorantes acerca de tu producto?
Nikita Lipsky: Es sorprendente, por supuesto, que hemos estado en el mercado durante 18 años y no sabemos mucho. Estamos haciendo una JVM inusual. Inusual en las apuestas en la compilación AOT, es decir Intentamos compilar bytecode Java en código de máquina de antemano.
Inicialmente, la idea del proyecto era hacer que Java fuera rápido. La productividad es con lo que fuimos al mercado. Y mientras caminábamos, Java todavía se interpretaba, y la compilación estática en el código de la máquina prometía mejorar el rendimiento de Java, incluso a veces, pero por órdenes de magnitud. Pero incluso en presencia de JIT, si compila todo por adelantado, no gasta recursos en tiempo de ejecución en la compilación y, por lo tanto, puede gastar más tiempo y memoria y, finalmente, obtener un código más optimizado.
Además del rendimiento, un efecto secundario de la compilación de bytecode estático es la protección de las aplicaciones Java contra la descompilación. Debido a que después de la compilación no queda ningún código de bytes, solo queda el código de máquina. Es mucho más difícil descompilar en código fuente que el código de bytes de Java. De hecho, imposible. Es decir, se puede desmontar, pero no dará origen a los códigos fuente. Pero el código fuente de Java se puede generar desde bytecode hasta nombres de variables fácilmente, hay muchas herramientas para esto.
Además, una vez se supuso que Java está instalado en todas las computadoras, distribuye sus aplicaciones Java en forma de código de bytes, y se ejecutan igual en todas partes. Pero en realidad, todo no fue tan bueno, porque uno tiene un Java, el otro tiene otro. Debido a esto, si distribuía el programa en forma de código de bytes, podrían ocurrir todo tipo de sorpresas, comenzando con el hecho de que el usuario simplemente no podía iniciar su programa, y terminando con un comportamiento extraño que no podía mostrar en usted mismo. Nuestro producto siempre ha tenido la ventaja de que distribuye su aplicación Java simplemente como una aplicación nativa. No tiene ninguna dependencia en el tiempo de ejecución que el usuario es (o no vale).
Ivan Uglyansky: Generalmente, no es necesario que se instale Java.
Oleg: Sigue habiendo una dependencia del sistema operativo, ¿verdad?
Nikita: bien. Muchos critican que si compila en código nativo, entonces su eslogan "Escribir una vez, ejecutar en cualquier lugar" deja de funcionar. Pero esto no es así. Periódicamente lo cuento en mis informes que "escribir una vez" suena como "escribir una vez" y no "construir una vez". Es decir, puede construir su aplicación Java en cada plataforma, y funcionará en todas partes.
Oleg: ¿Directo a todas partes, a todas partes?
Nikita: Donde sea que sea compatible. Tenemos una solución compatible con Java. Si escribe en Java, funcionará donde funciona Java. Y si utiliza el compilado por nosotros, entonces donde lo admitimos: Windows, Linux, Mac, x86, amd64, ARM32. Pero donde no lo admitimos, aún puede usar Java normal para sus aplicaciones, es decir, la portabilidad de sus aplicaciones Java en este sentido no se ve afectada.
Oleg: ¿Existen tales diseños que se implementan de manera diferente en diferentes plataformas? Piezas de la plataforma que no están completamente implementadas, algunas bibliotecas estándar.
Ivan: Sucede, pero no es específico de JET. Puede ver, por ejemplo, la implementación de AsynchronousFileChannel en el JDK en sí, es completamente diferente en Windows y Posix, lo cual es lógico. Algunas cosas se implementan solo en ciertas plataformas, soporte para SCTP (ver sun.nio.ch.sctp.SctpChannelImpl en Windows) y SDP (ver sun.net.sdp.SdpSupport). No existe una contradicción particular en esto, pero realmente resulta que "Escribir una vez, correr en cualquier lugar" no es del todo cierto.
Hablando específicamente sobre la implementación de la JVM, entonces, en diferentes sistemas operativos, la diferencia, por supuesto, puede ser enorme. ¿Cuál es el hecho de que en OS X en el hilo principal necesita ejecutar el bucle de eventos Cocoa, por lo que el lanzamiento allí es diferente del resto?
Nikita: Sin embargo, desde el exterior, para el usuario, todo se ve y funciona casi igual.
Oleg: ¿Qué pasa con el rendimiento? ¿Es lo mismo en todas las plataformas?
Nikita: hay una diferencia. Por ejemplo, un sistema de archivos de Linux funciona mejor y más rápido que un sistema de archivos de Windows.
Oleg: ¿Y portar entre procesadores?
Nikita: ¡ Esta es una actividad divertida! Todo el equipo de repente comienza a babor. El entretenimiento suele ser de seis meses a un año.
Oleg: ¿Sucede que algún código en otra plataforma comienza a disminuir más?
Ivan: Esto puede deberse al hecho de que simplemente no tuvimos tiempo para hacer o adaptar algún tipo de optimización. Funcionó bien en x86, luego cambiamos a AMD64 y simplemente no logramos adaptarlo. Debido a esto, puede ser más lento.
Otro ejemplo de rendimiento. ARM tiene un modelo de memoria débil, debe colocar muchas más barreras para que todo funcione correctamente. Teníamos AMD64, algunos lugares trabajaron, piensen, gratis entonces, porque allí el modelo de memoria es diferente. En ARM, debe poner más barreras, pero esto no es gratis.
Oleg: Hablemos del tema candente en este momento: "Java en dispositivos integrados".
Digamos que estoy haciendo un avión que vuela con control en una Raspberry Pi. ¿Cuáles son algunos problemas típicos que tiene una persona cuando hace esto? ¿Y cómo pueden ayudar JET y, en general, la compilación AOT en este asunto?
Nikita: El avión en la Raspberry Pi es, por supuesto, un tema interesante. Hicimos ARM32, y ahora JET está en la Raspberry Pi. Tenemos un número ilimitado de clientes para embebidos, pero no hay tantos para hablar sobre sus problemas "típicos". Aunque tienen algunos problemas con Java, no es difícil de adivinar.
Ivan: ¿Cuáles son los problemas con Java en Raspberry Pi? Hay un problema con el consumo de memoria. Si lo necesita demasiado, entonces la aplicación y la JVM tienen dificultades para vivir en la pobre Raspberry Pi. Además, es importante tener un inicio rápido en los dispositivos integrados para que la aplicación no se acelere allí por mucho tiempo. AOT resuelve bien estos dos problemas, por lo que estamos trabajando para mejorar el soporte integrado. Específicamente, con respecto a la Raspberry Pi, vale la pena mencionar a Bellsoft , que ahora participa activamente en esto con HotSpot. Java normal está completamente presente allí.
Nikita: Además, hay pocos recursos en sistemas embebidos; el compilador JIT no tiene dónde implementar. En consecuencia, la compilación AOT por sí misma acelera el rendimiento.
Una vez más, los dispositivos integrados no se conectan a la red, con una batería. ¿Por qué hay una batería para el compilador JIT si puede ensamblar todo por adelantado?
Oleg: ¿Qué características tienes? Entiendo que JET es un sistema complejo muy grande con un montón de todo. Tiene una compilación AOT, es decir, puede compilar un ejecutable. Que mas ¿De qué componentes interesantes vale la pena hablar?
Ivan: Tenemos una serie de características relacionadas con el rendimiento.
Recientemente, hablé sobre PGO, nuestra característica relativamente nueva. Tenemos un generador de perfiles incorporado directamente en la JVM, así como un conjunto de optimizaciones basadas en el perfil que recopila. Después de volver a compilar según el perfil, a menudo recibimos un gran aumento del rendimiento. El hecho es que la información de rendimiento se agrega a nuestros poderosos análisis estáticos y optimizaciones. Es un enfoque ligeramente híbrido para sacar lo mejor de la compilación JIT y AOT.
Tenemos dos características maravillosas para una aceleración de lanzamiento aún más rápida. La primera es cuando observa el orden en que las páginas de memoria se perforan inicialmente, simplemente lo supervisa y vincula el ejecutable en consecuencia.
Nikita: Segundo: cuando ejecutas el ejecutable, entiendes qué piezas de memoria se están extrayendo, y luego, en lugar de tirar de ellas en cualquier orden, inmediatamente extraes la pieza deseada. También acelera enormemente el lanzamiento.
Ivan: Estas son características individuales de comestibles.
Nikita: El primero se llama Startup Optimizer y el segundo es Startup Accelerator. Las funciones funcionan de manera diferente. Para usar el primero, debe ejecutar la aplicación antes de la compilación, recordará en qué orden se ejecutó el código. Luego, en el orden correcto, este código se vinculará. Y el segundo es iniciar su aplicación después de la compilación, luego ya sabemos qué fue dónde y dónde, y después de eso perforamos todo en el orden correcto en el lanzamiento.
Además de las características relacionadas con el rendimiento, hay una serie de características del producto que hacen que JET sea más conveniente de usar.
Por ejemplo, podemos empacar, por ejemplo, distribuciones de Windows. Una vez, y obtuve un instalador de Windows. Puede distribuir aplicaciones Java como aplicaciones nativas reales. Hay mucho mas Por ejemplo, existe un problema estándar con los compiladores AOT y Java cuando una aplicación usa sus propios cargadores de clases. Si tiene su propio cargador de clases, ¿no está claro qué clases compilaremos? Porque allí la lógica de resolución entre clases puede ser cualquier cosa. En consecuencia, ni un solo compilador AOT de Java, excepto el nuestro, funciona con cargadores de clases no estándar. Tenemos soporte especial en AOT para algunas clases de aplicaciones, donde sabemos cómo funcionan sus cargadores personalizados, cómo se resuelven los enlaces entre clases. Por ejemplo, tenemos soporte para Eclipse RCP y hay clientes que escriben aplicaciones de escritorio en Eclipse RCP y compilan con nosotros. Hay soporte para Tomcat, los cargadores personalizados también se utilizan allí. Puede compilar aplicaciones Tomcat con nosotros. También lanzamos recientemente una versión Spring Boot JET lista para usar.
Oleg: ¿Qué servidor hay "debajo"?
Nikita: lo que quieras. Qué soporte de Spring Boot funcionará con esto. Tomcat, Undertow, Jetty, Webflux.
Ivan: Aquí es necesario mencionar que para Jetty no tenemos el soporte de sus cargadores de clases personalizados.
Nikita: Jetty, como servidor web independiente, tiene un cargador de clases personalizado. Pero existe algo como Jetty Embedded, que puede funcionar sin cargadores personalizados. Jetty Embedded se ejecuta silenciosamente en Excelsior JET. Dentro de Spring Boot, Jetty funcionará en la próxima versión, como cualquier otro servidor compatible con Spring Boot.
Oleg: ¿De hecho, la interfaz de usuario con JET es javac y Java, o algo más?
Ivan: no. Para el usuario, tenemos varias opciones para usar JET. En primer lugar, esta es una GUI en la que el usuario perfora todas las funciones, luego presiona un botón y compila su aplicación. Cuando quiere hacer algún instalador para que el usuario pueda instalar la aplicación, vuelve a presionar los botones. Pero este enfoque está un poco desactualizado (las GUI se desarrollaron en 2003), por lo que ahora tenemos a Nikita desarrollando y desarrollando complementos para Maven y Gradle, que son mucho más convenientes y familiares para los usuarios modernos.
Nikita: Sustituye siete líneas en pom.xml o build.gradle, di mvn jet:build , y tienes un palo de salchicha en la salida.
Oleg: Y ahora todos aman a Docker y Kubernetes, ¿puedes construir para ellos?
Nikita: Docker es el siguiente tema. Tenemos ese parámetro: empaquetado en complementos Maven / Gradle. Puedo agregar aplicaciones de empaque para Docker.
Ivan: Esto todavía está en progreso. Pero, en general, probamos las aplicaciones compiladas con JET para ejecutarlas en Docker.
Nikita: funciona. Sin Java Linux desnudo, pegue la aplicación compilada JET allí, y comienza.
Oleg: Y con el empaque del acoplador, ¿cuál será el resultado? ¿Para empujar un contenedor o un ejecutable con las manos en el archivo Docker?
Nikita: Ahora solo escribes un archivo Docker específico para JET, estas son tres líneas. Además, todo funciona a través de las herramientas normales de Docker.
Estoy jugando con microservicios en este momento. Los compilo con JET, los ejecuto, se descubren, se comunican. La JVM no tuvo que hacer nada por esto.
Oleg: Ahora, todo tipo de proveedores de la nube han lanzado cosas como Amazon Lambda, Google Cloud Functions, ¿puedo usarlo allí?
Nikita: Creo que tenemos que ir a los proveedores de todas estas cosas y decir que si nos usas, todas tus lambdas funcionarán más rápido. Pero esto sigue siendo solo una idea.
Oleg: ¡Entonces realmente funcionarán más rápido!
Nikita: Sí, lo más probable es que se necesite más trabajo en esta dirección.
Oleg: Veo un problema en el tiempo de compilación lambda. ¿Cuál es tu tiempo de compilación?
Ivan: Existe, y este es un problema en el que los usuarios de JVM ordinarios con JIT no piensan. Por lo general, después de todo, cómo: inicié la aplicación, funciona (aunque al principio lentamente debido a la compilación). Y aquí viene un paso separado para compilar AOT toda la aplicación. Esto puede ser sensible, por lo que estamos trabajando para acelerar esta fase. Por ejemplo, tenemos una recompilación incremental cuando solo se vuelven a compilar las partes modificadas de la aplicación. Lo llamamos recompilación inteligente. Acabamos de hacer esto en el último período virgen con Nikita, estábamos emparejados.
Nikita: Existen ciertos problemas con Java y con la recompilación inteligente, por ejemplo, dependencias circulares dentro de las aplicaciones Java: están en todas partes.
Ivan: Hay muchos problemas bastante obvios allí, hasta que pienses en esta tarea. Si tiene un compilador AOT estático que realiza varias optimizaciones globales, entonces no es tan fácil calcular exactamente qué se necesita volver a compilar. Necesita recordar todas estas optimizaciones. Y las optimizaciones pueden ser no triviales. Por ejemplo, podría hacer todo tipo de desviaciones complejas, en línea, algo que el diablo sabe dónde. Si cambiaste un clásico o un JAR, esto no significa que solo sea necesario volver a compilar y listo. No, todo esto es mucho más confuso. Necesita calcular y recordar todas las optimizaciones que ha realizado el compilador.
Nikita: En realidad, haciendo lo mismo que JIT cuando toma una decisión sobre la des-optimización, pero solo en el compilador AOT. Solo la solución no será sobre desoptimización, sino sobre recompilación.
Oleg: sobre la velocidad de la compilación inteligente. Si tomo "Hola, Mundo", compilarlo, luego cambiar las dos letras en la palabra "Hola" ...
Nikita: Se compila rápidamente.
Oleg: Quiero decir, ¿ni un minuto?
Nikita: segundos.
Ivan: Pero aún depende de si incluimos clases de plataforma en el ejecutable.
Oleg: ¿Y qué es posible sin esto?
Nikita: Sí, de manera predeterminada, nuestra plataforma está aserrada en varias DLL. Implementamos Jigsaw desde el principio :-) Es decir, vimos clases de Java SE en componentes hace mucho tiempo, en unos 90 años más o menos.
Ivan: El punto es que nuestras clases de tiempo de ejecución más plataforma, todas están precompiladas por nosotros, y sí, están divididas en DLL. Cuando ejecuta la aplicación compilada por JET, el tiempo de ejecución y toda la plataforma se presentan en forma de estas DLL. Es decir, como resultado, se ve así: tomas "Hola, mundo", compilas, realmente compilas una clase. Esto sucede en unos segundos.
Nikita: En 4 segundos, si está en el global; en un par de segundos, si no en el global. "Global" es cuando se vincula: todas las clases de plataforma compiladas en código nativo en un gran ejecutable.
Oleg: ¿Puedo hacer una recarga en caliente?
Nikita: no.
Oleg: ¿no? Tristeza Pero sería posible generar una DLL, vincularla nuevamente y luego ...
Nikita: Ya que tenemos JIT (por cierto, sí, ¡también tenemos JIT!), Por supuesto, puedes cargar, descargar y recargar piezas de código. Por ejemplo, todo el código que funciona a través de nuestro JIT está en el mismo OSGI; puede volver a cargarlo si lo desea. Pero aquí está la recarga en caliente que HotSpot tiene, cuando te sientas en el depurador y cambias el código sobre la marcha, no lo hacemos. Esto no se puede hacer sin pérdida de rendimiento.
Oleg: En la etapa de desarrollo, el rendimiento no es tan importante.
Nikita: En la etapa de desarrollo, usas HotSpot y no necesitas nada más. Somos una solución compatible con Java. Si usa HotSpot y usa la recarga en caliente en la depuración, todo está bien. JET depurado, compilado, y todo funciona como en HotSpot. Debería ser así. Por lo general así. Si no, escribe para apoyar, lo entendemos.
Oleg: ¿Qué pasa con la depuración en JET? JVM TI? ¿Cuánto se admite todo?
Ivan: Uno de los valores centrales del uso de JET es la seguridad. El código personalizado no estará disponible para nadie. Porque todo está compilado en nativo. Hay algunas contradicciones con esto, ¿apoyamos JVM TI? Si apoyamos, significa que cualquier desarrollador desarrollado que sepa cómo funciona JVM TI podrá acceder rápidamente a cualquier cosa. No admitimos JVM TI en este momento.
Nikita: este es un elemento de especificación opcional. Puede ser compatible con los implementadores de la plataforma, puede que no sea compatible.
Ivan: Hay muchas razones. Es opcional y viola la seguridad, lo que significa que los usuarios no nos dirán "gracias". Y ella está adentro es muy específica de HotSpot. No hace mucho tiempo, nuestros muchachos apoyaron a JVM TI como un proyecto experimental, llegaron a una cierta etapa, pero todo el tiempo se enfrentaron con el hecho de que estaba muy centrado en HotSpot. En principio, esto es posible, pero ¿qué tarea empresarial se resolverá?
Nikita: Después de que ganaste dinero en HotSpot, pero no ganaste dinero en un avión, este no es tu problema. Este es nuestro problema.
Oleg: lo tengo. ¿Tiene alguna característica adicional que
no en HotSpot, pero ¿tiene uno y requieren control directo? Lo que me gustaría depurar, ordenarlos.
Nikita: Exactamente una característica. Tenemos una extensión oficial de la plataforma llamada Servicios de Windows, es decir, puede compilar aplicaciones Java en forma de servicios reales de Windows que serán monitoreados a través de herramientas estándar de Windows para servicios de Windows, etc. En este caso, debe recoger nuestro propio JAR para compilar dichas aplicaciones.
Oleg: Este no es el mayor problema.
Nikita: La interfaz es muy simple para estos servicios. Y para la depuración, utiliza los métodos para iniciar su propia aplicación no como un Servicio de Windows, sino a través de main. Algún tipo de depuración específica del servicio, no sé si es necesario.
Oleg: Supongamos que un nuevo desarrollador que trabajó anteriormente para HotSpot quiere desarrollar algo usando JET, ¿necesita aprender algo, entender algo en general sobre la vida o sobre JET?
Ivan: Necesita copiar siete líneas en pom.xml, si se usa Maven, luego ejecuta jet: build, y si JET está en la máquina, la aplicación Java se compilará en un ejecutable. La idea es que es simple, no haces nada especial, solo lo tomas, obtienes un ejecutable, y eso es todo.
Nikita: O conoces la línea de comando con la que se inicia tu aplicación, luego pones esta línea de comando en nuestra GUI, lo resolverá. Le das el comando de construcción, obtienes el ejecutable, eso es todo.
Ivan: Es muy simple, no necesitas inventar nada nuevo. Cómo funciona el Hotspot AOT, usted mismo mostró en el informe que necesita obtener una lista de todos los métodos en un archivo, barrerlo, transformarlo; no necesitamos hacer algo así. Simplemente tome su línea de lanzamiento en HotSpot, péguelo en una GUI especial o agregue una pequeña pieza a pom.xml y, un momento después (porque todavía es una compilación AOT), obtendrá un archivo exe, que se puede ejecutar
Oleg: ¿Necesito aprender a trabajar con GC?
Nikita: Sí, tenemos nuestro propio GC, necesitamos ajustarlo de una manera diferente, no como en HotSpot. Tenemos muy pocos corrales públicos.
Oleg: ¿Hay un bolígrafo "para hacer bien" o "no hacer"?
Ivan: Hay una pluma así. Hay un bolígrafo "set Xmx", hay un bolígrafo "establece el número de trabajadores" ... Muchos bolígrafos, pero ¿por qué necesita saber acerca de ellos? Si te sucede algo inesperado, escribe.
Por supuesto, tenemos muchas cosas que configurar para GC. Podemos sintonizar la generación más joven, podemos frecuencia de llegada de GC. Todo esto está ajustado, pero estas no son opciones generalmente aceptadas. Entendemos que las personas conocen -Xmx y lo señalan, así que lo analizamos. Hay algunas opciones más generalmente aceptadas que funcionan con JET, pero en general, todo es diferente.
Nikita: También tenemos una opción pública que le permite establecer cuánto le permite al GC pasar tiempo en su aplicación.
Oleg: ¿porcentaje?
Nikita: En décimas de un por ciento. Nos dimos cuenta de que el interés es demasiado, grosero.
Ivan: Si gastas interés en GC, algo está mal contigo.
Oleg: Y aquí están todas estas personas de empresas que hacen todo lo que hacen durante el horario laboral: abren una copia impresa del trabajo de GC con el horario y meditan. ¿Puedes meditar?
Nikita: Tenemos personas especiales dentro de la empresa que meditan.
Ivan: Tenemos nuestro propio formato de registro, por lo que es poco probable que la gente entienda algo de él. Aunque, ¿nunca se sabe? Si lo miran durante mucho tiempo, tal vez puedan entender. Todo está escrito allí. Pero, lo más probable, es mejor enviarnos, y meditaremos.
Oleg: Pero por supuesto, lo harás por el dinero, pero puedes buscar un obsequio tú mismo.
Nikita: Si usted es nuestro cliente, entonces tiene soporte, y lo hacemos, por supuesto, como parte del soporte.
Ivan: Pero si tienes algún problema obvio, incluso podemos decir sin apoyo.
Oleg: ¿Si esto es algún tipo de error?
Nikita: Si es un error, entonces, por supuesto, aceptamos de todos y siempre. Esto no es así, "hasta que compre, no solucionaremos el error". Si es un error, lo arreglamos. En general, los usuarios adoran nuestro apoyo. Por lo general, dicen que es de muy alta calidad y que no han visto nada igual en ninguna parte. Quizás el hecho es que nosotros mismos estamos en apoyo, rotamos a su vez.
Oleg: ¿Quiénes son ellos mismos?
Nikita: desarrolladores, ingenieros de JVM.
Oleg: ¿con qué frecuencia?
Nikita: La frecuencia es diferente. Por lo general, nos sentamos por turnos durante dos semanas. Pero si está obligado a hacer un megapha en un cierto número de días, en ese momento recibirá inmunidad de apoyo para que pueda concentrarse en esta tarea.
Ivan: En teoría, todos deberían hacer esto a su vez. Pero a veces alguien toma heroicamente la segunda dosis y lo apoya durante un mes o más, y no dos semanas. Personalmente, me gusta apoyar, pero si haces esto por mucho tiempo, entonces olvidas un poco lo que haces en la vida, porque solo comienzas a responder cartas. Pero aún quieres embutir la JVM. Por lo tanto, después de un tiempo debe regresar.
Oleg: Y tienes una jerarquía, ¿cuántos niveles de gestión? 20 o más?
Nikita: ¿Qué eres? Somos solo 10 personas en un equipo.
Ivan: 15 con los estudiantes.
Oleg: ¿Quiero decir que las autoridades están involucradas en esto o simplemente mirando?
Nikita: Sobre los jefes. Por supuesto, hay una persona principal, y hay muchos líderes locales.
Oleg: ¿Cada persona tiene su propia área?
Nikita: una persona que asume una gran tarea y la maneja. También gira. Puedes asumir una gran tarea y liderar una vez, y la próxima vez te guiarán.
Ivan: En general, no tenemos una gran jerarquía. Tenemos un nivel de jefes. Y sobre mirar desde arriba, absolutamente no. A veces, nuestros jefes asumen heroicamente el apoyo si hay una liberación cerca.
Nikita: Los jefes son una persona, su nombre es Vitaly Mikheev.
Oleg: ¿Puedes verlo en alguna parte? ¿En conferencias o en otro lugar?
Nikita: En general, mis discursos en las conferencias comenzaron con el hecho de que el Día de San Petersburgo en Java nos llegó en Novosibirsk, fue organizado por Belokrylov de Oracle, que ahora está en Bellsoft. Preguntó si nos gustaría hablar, y luego actuamos junto con Vitaly. Luego le sugerí que continuara actuando juntos, pero decidió que ya no quería hacerlo.
Oleg: ¿Y qué tipo de informe?
Nikita: "La historia de una JVM en imágenes" .
Ivan: Recuerdo este informe, luego fui pasante o simplemente dejé de serlo. Y sigo pensando que este es uno de los mejores informes que he visto.
Nikita: Quizás fue el "efecto de estreno" cuando actúas por primera vez en tu vida, presionas bien con energía.
Oleg: ¿De qué estabas hablando?
Nikita: Hablaron juntos sobre JET de principio a fin durante 20 minutos.
Oleg: ¿Para dos, solo 20 minutos? Por lo general, cuando hay varias personas, el tiempo para un informe solo aumenta.
Nikita: Hablamos muy vigorosa y animadamente sobre todos los temas clave.
Oleg: Vanya, ¿esto afectó tu decisión sobre qué hacer a continuación? ¿Trabajas para la empresa?
Ivan: ¡Podría ser!
Oleg: Es solo que la gente suele preguntar por qué asistir a conferencias, presentaciones, por qué escuchar algo, si puedes googlearlo.
Nikita: Por supuesto, en mi opinión, asistir a una conferencia es muy útil. Cuando tienes contacto directo, participación directa, no es en absoluto lo que ver en YouTube. Es importante que usted esté participando directamente, no virtualmente. Estás en contacto con la fuente. La diferencia es casi lo mismo que asistir a un concierto en vivo o escucharlo en una grabación. Probablemente incluso grande, porque ¿cuánto puedes hablar con tu artista favorito después del concierto? Pero en la conferencia puede encontrar al orador que necesita y pedirle todo lo que necesita, no hay problemas.
Ivan: Por cierto, con respecto a la decisión de "permanecer en la empresa", esta es una historia diferente. Tenemos un sistema de reclutamiento bastante único para empleados / pasantes. Tomamos pasantes para 2-3 cursos, generalmente de la facultad o del departamento de física. Los alumnos están muy inmersos en el tema, los curadores los ayudan a comprender varios mecanismos de VM, detalles de implementación, etc. Cuesta mucho.
Después de un tiempo, comienzan a dar misiones de combate, escriben código real en producción. Realiza cambios en la JVM, realiza revisiones, pruebas, puntos de referencia, verifica que no estén caídos. Te comprometes por primera vez. Después de eso, te enfocas en tu diploma. Por lo general, un diploma también es una parte genial de la investigación experimental JVM. Esto generalmente lo hacen los estudiantes. Entonces puede producirlo, o tal vez no. Nunca había visto algo así, de modo que se dedicara tanto tiempo a los pasantes. Y personalmente lo aprecio mucho, porque recuerdo cuánto tiempo pasé conmigo. La salida es un ingeniero JVM. ¿Dónde más hay una fábrica de producción de ingenieros de JVM?
Oleg: ¿Y no tienes miedo de la filtración de información de los pasantes, entonces ellos describirán abiertamente todo esto en un diploma?
Nikita: Esto no es un problema, porque tememos que se filtre en el extranjero, y especialmente nadie leerá ruso, es una protección, una ofuscación :-)
Ivan: Tenía un estudiante defendiendo este año, era el líder y había un problema que no todos querían escribir en un diploma. Revelamos algo de un tema completamente cerrado y, por ejemplo, un revisor nos preguntó por qué no estábamos hablando de ciertas cosas. Le dije que no puedes hablar de eso, es muy secreto, no podemos. Lo es, te lo diré al oído, pero no irá a ningún otro lado. Así que tenemos un poco de miedo de esto, pero en general, puedes encontrar muchas cosas interesantes en los diplomas.
Oleg: ¿Y cómo buscar diplomas que involucren a Excelsior?
Nikita: Ven a la oficina del decano y pide leer ese diploma.
Ivan: Tenemos una lista de diplomas defendidos con éxito en nuestro sitio, pero solo nombres, sin enlaces. Y no tenemos defensores sin éxito.
Oleg: Mueren o se defienden.
Ivan: lo es! Tenemos un puntaje promedio de 5.0 graduados, hay quienes simplemente no van a un diploma.
Oleg: En este entrenamiento, la fábrica de ingenieros de JVM, ¿cuáles son las etapas para convertirse en Jedi? Cuando te dan un sable de luz, ¿cuándo puedes empezar a agitarlos?
Nikita: bastante rápido. Ahora los jóvenes se están volviendo dolorosamente rápidos como Jedi, estoy orgulloso de ellos.
Ivan: Por cierto, Nikita fue mi primer curador cuando era pasante. En cuanto a la pasantía: primero pasa por una selección: resuelve problemas, viene a una o más entrevistas. Si todo está bien, entonces te conviertes en un aprendiz. Al principio, lee artículos científicos sobre temas que probablemente estén relacionados con su futuro diploma, o solo sobre temas de JVM en inglés para obtener el contexto. Usted lee, escribe un ensayo sobre ellos, explica lo que está sucediendo allí. Son muy duros con él. Algunos estudiosos envidiarían tal revisión y tal preparación de ensayos. Resulta artículos completos en ruso. Después de eso, es hora de que escriba el código, y poco a poco se le está presentando la esencia del asunto: cómo funciona todo.
Nikita: Y aquí es donde termina la ciencia.
Ivan: ¡ No necesariamente!
Nikita: Es una pena, al principio del cero publicamos artículos que llevamos a las revistas ACM.
Ivan: Bueno, lo estamos haciendo ahora, ¿cuál es el problema?
Nikita: ¿Cuál fue nuestro último artículo en la revista ACM?
Ivan: Entonces, en ACM, ¡simplemente no lo intentamos! Ahora estamos blogueando : es lo mismo, solo las personas lo leen. Esta es una actividad similar.
Volviendo al tema Jedi, después de esto, la primera vez que haces algo en producción bajo estricto control. Se necesita una pequeña tarea que no esté relacionada con su futuro diploma.
Oleg: Por ejemplo, escribir un comentario.
Ivan: no. Verdadera funcionalidad El estudiante debe hacer su primera contribución real para que permanezca en el producto. , - , . , -, — . , . , JVM-.
: ? ? - , , - ? ?
: , . - — - , , , , , , JVM. , , , . , : « !». .
: JET?
: , JVM .
: - , JET — JET. , - , : baseline-. , . , , JET .
: ?
: , . , .
: - , baseline .
: , baseline JIT. , JIT , . , baseline. . - , baseline, .
: - UI-? .
: . . Windows.
: , . , Mac.
: Android ?
: . , Android Linux-, Linux . Linux Android . - . .
: ?
: ? No
: 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 ). , ? Pero nada , - - , . JVM , . , .
Java . , , — . Loom Metropolis, Java. - JVM, , , , , . Loom , , . . , — .
. , Java — , 5-6 Java- JPoint . , Java- (Simon Ritter, Rafael Winterhalter). , Call for Papers 31 . . , YouTube. JPoint!