En Java, hace «código binario» significa lo mismo que «bytecode de Java?»

Es este el flujo en Java ?

Archivo Java (.java) -> [javac] ->
Archivo De Código De Bytes (.clase) -> [JVM/Java
Intérprete] -> Ejecutar(por primera
convertirlo en código binario
específico para la máquina)

Gracias!

  • En qué contexto le hizo ver que el término «código binario?»
  • He leído en alguna parte del código java se convierte independientes de la máquina de código de bytes, mientras que algunos dijeron, se convierte a código binario. Así que estoy un poco confundido.
  • Todo es «código binario»!!! Oh noes!!
  • editado tu pregunta: he sustituido «javac.exe» con «javac» porque en Linux, OS X y todos los otros sistemas unix Java funciona en el Windowsy-idiosynchratic «.exe» no tiene mucho sentido 😉
  • Tenga en cuenta que en la mayoría del Mundo Real [TM] Jvm de Java no es «interpretado» de la misma manera real de lenguajes interpretados son interpretados. Para empezar (y eso es un hecho en cualquier JVM) es, como se señaló, no el código fuente, pero el bytecode que es «interpretado» (esto sólo hace ya un muy extraña definición de «interpretar» porque es increíblemente más eficiente que el código fuente de interpretación), la mayoría del Mundo Real [TM] Jvm son «JIT». JIT significa la compilación. De esta forma se hace incluso más raro definición/uso de «interpretar».
  • Así que, aunque no es totalmente falso decir que Java es interpretado es muy engañosa (y normalmente hecho por la gente que recurrir a todo tipo de otros errores lógicos con el fin de socavar Java). Una vez más, la mayoría del Mundo Real [TM] Jvm, ejecutando Mundo Real [TM] programas, hacer JIT. Y JIT significa la compilación. Y a mí me suena un enorme «lógico-falacia-troll-tratar-a-minar-Java-troll» signo cuando leí a alguien decir que Java es realmente un lenguaje interpretado. Puntos de referencia en el gran lenguaje de penaltis de acuerdo conmigo en que uno cuando se trata de comparar interpreta-vs-lenguajes compilados 😉
  • Es que no engañen a todos: java.sun.com/docs/white/langenv/Intro.doc2.html leer 1.2.5. El hecho de que la JVM no muy inteligente JIT gimnasia para escupir el rendimiento que puede competir con C y C++ no significa que el bytecode no se interpreta, porque lo es. Cuando Java JIT, también es necesario que se caliente (y por lo general hace varios interpretación de ciclos antes de que se cambia JIT, por lo general en el desempeño crítico bloques de código).
  • Titarenco: nunca me dijo que no era «interpretar». Me dijo refiriéndose a ella como un lenguaje interpretado es muy engañosa, porque engaña a la gente en el pensamiento de una) es el código que es interpretado y b) no hay JIT involucrados. Y el JIT «gimnasia» es casi una pieza central de cualquier Mundo Real [TM] máquina virtual de Java de hoy en día. Su comentario muestra exactamente ¿qué tiene de malo llamar a Java un lenguaje interpretado. Por cierto, también existen los nativos de Java de la CPU como los de Ajile sistemas donde el código se ejecuta de forma nativa….
  • Titarenco: El hecho de que hay CPUs que se pueden ejecutar nativo de Java bytecode que muestra cómo cerrar el metal, el bytecode de Java es. Llamar a Java un lenguaje interpretado, porque es bytecode, que tiene un uno-a-uno de mapeo para muchos de sus instrucciones en código de máquina en muchos arquitectura, se interpreta la SE muy engañosa. Sé que los dioses del Sol llamado así, pero creo que es muy triste que decidió ir con ese nombre tonto, dando Java una mala rep e innumerables, sin sentido, desinformados «Java es interpretado»* comentarios. Código que importa es JITed y es NO interpretarse más.
  • Pero incluso el código que se JITed se interpreta antes de que sea JITed (hasta el JIT se activa). No estoy discutiendo cómo de cerca o de lejos Java es, desde el metal, creo que es importante entender los principios básicos del lenguaje de diseño que esta pregunta dirigida – de los principios que hacen de Java y C++ (por ejemplo) idiomas muy diferentes desde un punto de vista teórico. Estoy de acuerdo, sin embargo, que la declaración general de «Java es un lenguaje interpretado» puede ser un nombre poco apropiado.
  • Titarenco, @SyntaxT3rr0r: chicos, usted habla de la JVM como es «real» del programa, y sólo tiene una aplicación… Hay diferentes comerciales y de libre Jvm, y trabajan en diferentes… «JRockit no incluye un intérprete; por lo que la compilación JIT del byte de código en código máquina nativo tiene que ocurrir antes de que un método se ejecuta» – no la interpretación, no se caliente, sólo JIT 🙂 la Comprensión de JIT. Por favor, cuando se discute, nos dicen que la aplicación que quieres decir (HotSpot, JRockit, J9)

InformationsquelleAutor | 2011-01-30

6 Comentarios

  1. 28

    La respuesta depende de a qué te refieres por binary code.

    Java bytecode es un formato de datos binario que incluye la carga de la información y de ejecución de instrucciones de la máquina virtual de Java. En ese sentido, Java bytecode es un tipo especial de código binario.

    Cuando se utiliza el término «código binario» para referirse a las instrucciones de la máquina para una real procesadores de la arquitectura (como IA-32 o Sparc), entonces es diferente.

    Java bytecode no es un código binario en ese sentido. No es específico del procesador.

  2. 12

    JVM es muy complejo programa, y el caudal es en cierto nivel impredecible. E. g. el flujo dentro de la JVM HotSpot es algo como lo siguiente:

    1) toma su bytecode y lo interpreta

    2) si algún método se ejecuta con bastante frecuencia (una cierta cantidad de veces durante algún período de tiempo) es marcado como «caliente» método y JVM horarios de su compilación a la plataforma dependía del código de la máquina (que es lo que ustedes han llamado código binario?). Que el flujo se parece a la siguiente:

    ByteCode
    --> Hige-level Intermediate Representation (HIR)
      --> Middle-level Intermediate Representation (MIR)
        --> Low-level Intermediate Representation (LIR)
          --> Register Allocation
            --> EMIT (platform dependent machine code)

    Cada paso en que el flujo es importante y ayuda a JVM realizar algunas optimizaciones de código. No cambia su algoritmo de curso de optimización, sólo significa que algunas secuencias de código puede ser detectado y se intercambia con mejor rendimiento código (que producen el mismo resultado). A partir de la LIR etapa, el código se convierte en dependiente de la plataforma (!).

    Código de bytes puede ser bueno para la interpretación, pero no lo suficiente como para ser fácilmente transformadas en el código nativo de la máquina. HIR toma el cuidado de él y su propósito es transformar rápidamente de código de bytes en una representación intermedia. MIR transforma todas las operaciones en los tres operandos de la operación; código se basa en la pila de operación:

    iload_0
    iload_1
    iand

    que fue bytecode para simple and operación, y el nivel medio de representación para esto se clasificar de la siguiente:

    and v0 v1 -> v2

    LIR depende de la plataforma, teniendo en cuenta nuestro sencillo ejemplo con and operación, y la especificación de nuestra plataforma x86, entonces nuestro fragmento de código será:

    x86_and v1 v0 -> v1
    x86_move v1 -> v2

    porque and operación tiene dos operandos, una primera es el destino, la otra es la fuente y, a continuación, ponemos el valor del resultado a otra «variable». La próxima etapa es la de «asignación de registro», porque la plataforma x86 (y probablemente la mayoría de los otros) trabajar con los registros, y no variables (como representación intermedia), ni de la pila (como código de bytes). Aquí nuestro fragmento de código debe ser similar a la siguiente:

    x86_and eax ecx -> eax

    y aquí se puede notar la ausencia de un «movimiento» de la operación. Nuestro código contenía sólo una línea y JVM descubierto que la creación de un nuevo virtual variable no fue necesario; podemos reutilizar el eax registro. Si el código es lo suficientemente grande, tener muchas variables y trabajar con ellos intensivo (por ejemplo, mediante la utilización de eax en algún lugar debajo, por lo que no puede cambiar su valor), entonces usted va a ver la operación de desplazamiento a la izquierda en código máquina. Que de nuevo acerca de la optimización 🙂

    Que fue JIT flujo, pero dependiendo de la implementación de la VM puede ser un paso más – si el código fue compilado (por ser «caliente»), y aún así ejecutado, muchas, muchas veces, JVM horarios de optimización de código (por ejemplo, usando inline).

    Bien, la conclusión es que la ruta de acceso de bytecode a código máquina es bastante interesante, un poco imprevisible, y depende de muchas cosas.

    por cierto, el proceso descrito anteriormente se llama «modo Mixto de la interpretación» (cuando la JVM primero interpreta el bytecode, y, a continuación, utiliza la compilación JIT), ejemplo de JVM HotSpot. Algunos Jvm (como JRockit de Oracle) el uso de la compilación JIT solo.

    Esta fue una simple descripción de lo que está pasando allí. Espero que ayude a entender el flujo dentro de la JVM en un nivel muy alto, así como los objetivos de la pregunta acerca de las diferencias entre bytecode y código binario. Para referencias, y otras cuestiones que no se mencionan aquí y relacionados con ese tema, por favor, lea el tema similar «¿Por qué se compilan los archivos de clase Java menor que C archivos compilados?«.

    También siéntase libre de crítica a esta respuesta, que me señale los errores o malentendidos de la mina, siempre estoy dispuesta a mejorar mis conocimientos sobre la JVM 🙂

    • gracias, me alegro de que aquí no estaba perdiendo el tiempo 😉
  3. 7

    No hay tal cosa como «independiente de la máquina-bytecode» (que no tendría ningún sentido si se piensa). Código de bytes (para los efectos de esta respuesta) que se utiliza para cosas como máquinas virtuales. VMs (tales como la JVM) INTERPRETAR el código de bytes y el uso inteligente y complicado en tiempo de compilación (que ES de máquina y/o dependientes de la plataforma) para dar el producto final.

    Entonces, en un sentido, las respuestas son el bien y el mal. El compilador de Java compila el código en Java bytecode (independiente de la máquina). El *.class archivos a los que el código se encuentra en son binarias – que son ejecutables, después de todo. La máquina Virtual más tarde interpreta estas binario *.class archivos (nota: cuando se describen los archivos binarios, es algo de un nombre inapropiado) y hace varias cosas increíbles. Más a menudo que no, la JVM utiliza algo llamado JIT (justo-a-tiempo de compilación), que genera específico de la plataforma, o de la máquina de instrucciones específicas de que la velocidad de diversas partes de la ejecución. JIT es otro tema para otro día, sin embargo.

    Editar:

    Java File (.java) -> [javac.exe] -> ByteCode File (.class) -> [JVM/Java Interpreter] -> Running it(by first converting it into binary code specific to the machine)

    Esto es incorrecto. La JVM no «convertir» a cualquier cosa. Simplemente interpreta el bytecode. La única parte de la JVM que «convierte» bytecode es cuando el compilador JIT se invoca, que es un caso especial y no deben ser generalizados.

    • Usted acaba de decir,» compilación JIT» es independientes de la máquina. Pero he leído que la JVM es específico para cada máquina, a diferencia de un código de bytes.
    • La compilación JIT es una pequeña parte de cómo la JVM obras (y la ÚNICA parte que «re-escribe» código para una máquina en particular/plataforma). La máquina virtual es una plataforma/máquina específica intérprete, pero el código NO.
    • Titerenco: tal vez no fui su «justo-a-tiempo de compilación (que ES la máquina/independiente de la plataforma)», pero la compilación JIT es dependiente de la plataforma, a partir de la LIR etapa en el flujo que produce depende de la plataforma de código! El resultado de la compilación es nativo depende de la plataforma en código de máquina, por lo que no puede ser independiente… bytecode es de cource independiente de la plataforma…
    • eso es un error, lo siento. JIT ES dependiente de la plataforma.
  4. 4

    Tanto de C/C++ (para tomar un ejemplo) y los programas de Java se compilan en Código Binario. Este término genérico que significa que el nuevo archivo creado no codifica las instrucciones en un formato legible manera. (es decir, Usted no será capaz de abrir el archivo compilado en un programa de texto y leerlo).

    Por otro lado, lo que el Binario de 0 y 1 es encode (o representar), depende de lo que el compilador genera. En el caso de Java, se genera instrucciones llamado Bytecode, que son interpretados por la JVM. En otros casos, para otros idiomas, puede generar IA-32 o SPARC instrucciones.

    En conclusión, la manera en que los términos código Binario y bytecode de Java se oponen la una a la otra es engañosa. La razón era para hacer la distinción entre lo normal código binario, que es el equipo a su cargo, y el bytecode de Java (también un código binario), que no es.

  5. 1

    Respuesta que he encontrado hoy de la pregunta anterior:

    Fuente: JLS

    De carga se refiere al proceso de encontrar la forma binaria de una clase o tipo de interfaz con un nombre en particular, tal vez por la computación en la marcha, pero por lo general mediante la recuperación de una representación binaria previamente calculada a partir del código fuente por un compilador de Java, y de la construcción, de la que forma binaria, un objeto de la Clase para representar a la clase o interfaz.

    La semántica precisa de la carga están dadas en el Capítulo 5 de La Especificación de la Máquina Virtual de Java, Java SE 7 Edición. Aquí presentamos una visión general del proceso desde el punto de vista del lenguaje de programación Java.

    El formato binario de una clase o interfaz de es normalmente la clase de archivo de formato que se describe en La Especificación de la Máquina Virtual de Java, Java SE 7 Edición citada, pero otros formatos son posibles, siempre que cumplan los requisitos especificados en el artículo 13.1. El método defineClass de clase cargador de clases puede ser utilizado para la construcción de los objetos de la Clase de representaciones binarias en la clase de formato de archivo.

  6. 0

    Cuando la charla acerca de los programas, a continuación, término código binario suele denotar programa ejecutable en formato binario (codifica como una secuencia de bits).
    En otras palabras código binario es cualquier programa compilado frente a scripts que se distribuye y se ejecuta (interpreta) en forma de texto.

    Código binario puede ser de dos tipos: código de la máquina y el código de byte. Código máquina es un programa codificado de acuerdo a la especificación de hardware real del microprocesador. Por lo tanto, puede ser ejecutado directamente por el destino microprocesador sin la mediación de ningún otro software. En contraste, bytecode es un programa codificado de acuerdo a la especificación de algunos virtual microprocesador (máquina virtual). Por lo tanto, para la ejecución puede ser interpretado o traducido a código máquina y, a continuación, ejecuta directamente.

    De esta manera, cada bytecode es un código binario, pero no todos los código binario es bytecode. En el contexto de tu pregunta, «bytecode de Java» es incondicional de un «código binario», pero «código binario» no es necesario ser «bytecode de Java», pero puede ser «bytecode de Java».

Dejar respuesta

Please enter your comment!
Please enter your name here