java - temas - manual de programacion android pdf

Temas de Java vs Temas de OS (4)

Cada Thread recibirá un Thread OS nativo para RUN que puede ejecutarse en una CPU diferente, pero como Java se interpreta, ¿estos threads requerirán interactuar con la JVM una y otra vez para convertir el código de bytes en instrucciones de la máquina? Estoy en lo cierto

Estás mezclando dos cosas diferentes; JIT realizado por la máquina virtual y el soporte de subprocesos ofrecido por la máquina virtual. En el fondo, todo lo que haces se traduce en algún tipo de código nativo. Una instrucción de código de bytes que utiliza un hilo no es diferente de un código JIT que accede a los hilos.

Si es así, que para los programas más pequeños, los subprocesos de Java no serán una gran ventaja.

Define pequeño aquí. Para procesos de corta duración, sí, los hilos no hacen una gran diferencia ya que su ejecución secuencial es lo suficientemente rápida. Tenga en cuenta que esto nuevamente depende del problema que se resuelva. Para los kits de herramientas de la interfaz de usuario, no importa lo pequeña que sea la aplicación, se requiere algún tipo de ejecución de subprocesos / asíncrono para mantener la interfaz de usuario receptiva.

El enhebrado también tiene sentido cuando tienes cosas que se pueden ejecutar en paralelo. Un ejemplo típico sería hacer IO pesado en el hilo y el cálculo en otro. Realmente no querrías bloquear tu procesamiento solo porque tu hilo principal está bloqueado haciendo IO.

Una vez que el Hotspot compila ambas rutas de ejecución, ¿ambas pueden ser tan buenas como las de los hilos nativos? Estoy en lo cierto

Mira mi primer punto.

En realidad, el subprocesamiento no es una bala de plata, especialmente cuando se trata del error común de "usar hilos para que este código vaya más rápido". Un poco de lectura y experiencia será tu mejor apuesta. ¿Puedo recomendar obtener una copia de este impresionante libro ? :-)

@Sanjay: De hecho, ahora puedo replantear mi pregunta. Si tengo un subproceso cuyo código no ha sido JIT, ¿cómo lo ejecuta el subproceso del sistema operativo?

Nuevamente lo diré, el enhebrado es un concepto completamente diferente del JIT. Vamos a tratar de ver la ejecución de un programa en términos simples:

java pkg.MyClass -> VM localiza el método a ejecutar -> Comience a ejecutar el byte-code para el método línea por línea -> convierta cada instrucción de byte-code a su contraparte nativa -> instrucción ejecutada por OS -> instrucción ejecutada por máquina

Cuando JIT ha puesto en marcha:

java pkg.MyClass -> VM localiza el método a ejecutar que ha sido JIT''ed -> localiza el código nativo asociado para ese método -> instrucción ejecutada por OS -> instrucción ejecutada por máquina

Como puede ver, independientemente de la ruta que siga, la instrucción de VM debe asignarse a su homólogo nativo en algún momento. Si ese código nativo se almacena para reutilizarlo o desecharlo si es algo diferente (optimización, ¿recuerdas?).

Por lo tanto, para responder a su pregunta, cada vez que escriba un código de subprocesos, se traduce al código nativo y lo ejecuta el sistema operativo. Ya sea que la traducción se realice sobre la marcha o se busque en ese momento, es un tema completamente diferente.

Parece que me he equivocado con Java Threads / OS Threads y el lenguaje interpretado.

Antes de comenzar, entiendo que los subprocesos verdes son subprocesos de Java en los que JVM se encarga de los subprocesos y que todo el proceso de Java se ejecuta solo como un único subproceso del sistema operativo. Por lo tanto, en un sistema multiprocesador es inútil.

Ahora mis preguntas son. Tengo dos subprocesos A y B. Cada uno con 100 mil líneas de código independiente. Ejecuto estos hilos en mi programa Java en un sistema multiprocesador. Cada Thread recibirá un Thread OS nativo para RUN que puede ejecutarse en una CPU diferente, pero como Java se interpreta, ¿estos threads requerirán interactuar con la JVM una y otra vez para convertir el código de bytes en instrucciones de la máquina? Estoy en lo cierto Si es así, que para los programas más pequeños, los subprocesos de Java no serán una gran ventaja.

Una vez que el Hotspot compila ambas rutas de ejecución, ¿ambas pueden ser tan buenas como las de los hilos nativos? Estoy en lo cierto

[EDITAR]: una pregunta alternativa puede ser, asumiendo que tiene un solo subproceso de Java cuyo código no está compilado JIT, usted crea ese subproceso y lo inicia (). ¿Cómo interactúan Thread y JVM del sistema operativo para ejecutar ese Bytecode?

Gracias

y todo el proceso de Java se ejecuta solo como un único hilo de sistema operativo

Esto no es verdad. Por lo tanto, no se especifica, a menudo vemos, que los subprocesos de Java son en realidad subprocesos nativos del sistema operativo y que las aplicaciones Java de múltiples subprocesos realmente hacen uso de procesadores de múltiples núcleos o plataformas de múltiples procesadores.

Una recomendación común es utilizar un grupo de subprocesos donde el número de subprocesos es proporcional al número de núcleos (factor 1-1.5). Esta es otra sugerencia, que la JVM no está restringida a un solo hilo / proceso del sistema operativo.

De wkipedia:

En Java 1.1, los hilos verdes eran el único modelo de subprocesos utilizado por la JVM, [4] al menos en Solaris. Como las hebras verdes tienen algunas limitaciones en comparación con las hebras nativas, las versiones posteriores de Java las descartaron en favor de las hebras nativas .

Ahora, en 2010 con Java 7 en desarrollo y Java 8 planeado, ¿estamos realmente interesados en los "hilos verdes" históricos?

Algunas implementaciones de Java pueden crear subprocesos verdes como usted lo describe (la programación realizada por la JVM en un único subproceso nativo), pero las implementaciones normales de Java en la PC usan múltiples núcleos.
Es posible que la propia JVM ya use diferentes subprocesos para el trabajo (recolección de basura, carga de clases, verificación de códigos de bytes, compilador JIT).
El sistema operativo ejecuta un programa llamado JVM. La JVM ejecuta el Java Bytecode. Si cada Java-Thread tiene un subproceso nativo asociado (eso tiene sentido y parece ser el caso en implementaciones de PC), entonces el código JVM en ese subproceso ejecuta el código Java - JITed o interpretado - como en un solo subproceso -programa. No hay diferencia aquí a través de multiproceso.

Subprocesos y ejecución de un código de byte son temas separados. JVM utiliza las hebras verdes en plataformas que no tienen soporte nativo de hebras. (En mi humilde opinión no sé qué plataforma no admite subprocesos).

El código de bytes se interpreta en tiempo real y se ejecuta en la plataforma nativa mediante JVM. JVM decide cuáles son los fragmentos de código más populares y realiza la llamada compilación justo a tiempo de estos fragmentos, por lo que no tiene que compilarlos una y otra vez. Esto es independiente en el enhebrado. Si, por ejemplo, tiene un hilo que ejecuta el mismo fragmento de código en bucle, este fragmento será almacenado en caché por el compilador justo a tiempo.

En pocas palabras: no te preocupes por el rendimiento y los hilos. Java es lo suficientemente fuerte como para ejecutar todo lo que estás codificando.