ES2209947T3 - Metodo y sistema para la distribucion de programas de ordenador orientados a objetos. - Google Patents
Metodo y sistema para la distribucion de programas de ordenador orientados a objetos.Info
- Publication number
- ES2209947T3 ES2209947T3 ES00953341T ES00953341T ES2209947T3 ES 2209947 T3 ES2209947 T3 ES 2209947T3 ES 00953341 T ES00953341 T ES 00953341T ES 00953341 T ES00953341 T ES 00953341T ES 2209947 T3 ES2209947 T3 ES 2209947T3
- Authority
- ES
- Spain
- Prior art keywords
- code
- virtual processor
- native
- processor
- class
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/47—Retargetable compilers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
Abstract
Un método para distribuir un programa de ordenado, orientado a objetos, caracterizado porque: (a) traduce el codigobyte del programa (210) en un código de procesador virtual independiente de la máquina (213), que utiliza un conjunto de instrucciones de un procesador virtual; (b) transmite el código del procesador virtual desde un servidor (410) a un dispositivo cliente (430); y (c) porque traduce el código del procesador virtual a código nativo (242), el cual utiliza un conjunto de instrucciones de un procesador físico el dispositivo cliente.
Description
Método y sistema para la distribución de
programas de ordenador orientados a objetos.
La invención está relacionada generalmente con
métodos y sistemas de ordenador para traducir (o traducir y
ejecutar) programas de ordenador orientados a objetos. Más
específicamente, aunque no en forma exclusiva, la invención está
relacionada con programas orientados a objetos en los cuales se
proporciona el código en la forma de ficheros de clases.
Un ejemplo bien conocido de un lenguaje de
programación orientado a objetos es el lenguaje "Java" (marca
registrada de Sun Microsystems Inc.). Una "implementación Java"
es un sistema de software que permite la aplicación del software
consistente en uno o más ficheros de clases a ejecutar. Estos
ficheros de clases tienen que estar conformes con alguna versión de
la Especificación de Máquina Virtual Java, tal como se publica por
Sun Microsystems Inc. Un fichero de clases define los datos y el
código de programa necesarios para una clase particular.
Aunque existe alguna interacción, la
implementación Java puede dividirse conceptualmente en dos
partes:
- \bullet
- La Máquina Virtual Java (JVM). Esta lee los ficheros de clase y ejecuta las instrucciones contenidas dentro de los mismos de una forma que esté conforme con alguna versión de la Especificación de Máquina Virtual Java de Sun. Algunas de las instrucciones contenidas dentro de una clase pueden hacer referencia a los datos o al código de programa de otras clases; la JVM gestiona también dicha relaciones entre las clases.
- \bullet
- La Librería de Clases Java. Esta es un conjunto de clases predefinidas con datos y código de programas que actúa de una forma que esté conforme con la Especificación de Librería de Clases Java de Sun. Estas librerías de clases podrían ser implementadas de alguna forma distinta a la correspondiente a los ficheros de clases reales, por ejemplo utilizando los lenguajes de programación C o Ensamblador, en cuyo caso, la JVM tiene que asegurar que hace referencia a sus datos y a la tarea del código de programa de la mismo forma que hace referencia a las clases que se originaron a partir de los ficheros de clases reales.
El código de programa en un fichero de clases es
un formato de instrucción conocido como códigobyte Java (JBC), o
simplemente como códigobyte. Cada método en la clase tiene su propia
secuencia del códigobyte. El códigobyte para un método consiste en
una secuencia de instrucciones JBC.
Existen dos esquemas que utilizan las JVM para
ejecutar el códigobyte:
- \bullet
- Un intérprete. En este esquema, la JVM (Máquina Virtual Java) contiene un intérprete, el cual es una pieza del código de programa que ejecuta el códigobyte mediante la observación en cada instrucción JBC por turno, decodificándola, y ejecutando las acciones demandadas por la misma. Aunque esta solución es la más sencilla de implementar, su inconveniente es que es más lenta que la alternativa, puesto que se requieren muchas etapas del programa interpretador para interpretar una única instrucción JBC.
- \bullet
- Un compilador. En este esquema, la JVM convierte las instrucciones JBC del códigobyte en instrucciones de código máquina comprendidas por la CPU que esté en ejecución (código máquina nativo), antes de que se inicie cualquier ejecución. A continuación, para ejecutar el código del programa para un método, el código máquina compilado se ejecuta en su lugar. Existe un intervalo de tiempo para la compilación inicial a partir de las instrucciones JBC hasta las instrucciones de código máquina, aunque esto puede realizarse durante la preparación de la aplicación en lugar de hacerlo cuando se inicie la aplicación. Una vez que haya sido ejecutada la compilación, el código del programa del método se ejecuta mucho más rápido, a una velocidad comparable con otros lenguajes compilados tradicionalmente, tal como el lenguaje C. Un caso especial del esquema del compilador es un compilador "justo a tiempo" (JIT), en el cual se compila el códigobyte para una clase justo antes de que se utilice primeramente.
Algunas JVM utilizan una combinación de los dos
esquemas, en los que solo el código de programa que se está
ejecutando muchas veces es compilado, y el resto es
interpretado.
El enlazado es el proceso mediante el cual se
resuelve una referencia desde una clase C1 a otra clase C2 (o los
datos o un método en C2). Si C2 no está cargada todavía, se carga,
y se compila si se utiliza el esquema del compilador, y se enlaza en
sí. A continuación, la referencia en C1 a C2 (o alguna unidad de
datos o un método en C2) se modifica de forma tal que existe ahora
un puntero directo a cualquiera sea lo que se esté refiriendo en
C2.
La Especificación de la Máquina Virtual Java de
Sun permite un rango determinado de esquemas de enlazado.
- \bullet
- Enlazado estático: La carga y enlazado de todas las clases de la aplicación se ejecuta cuando la aplicación está preparada. Este esquema se utiliza típicamente cuando una aplicación está incrustada permanentemente en un dispositivo.
- \bullet
- Enlazado de tiempo de carga dinámico: La clase C2 es cargada cuando la otra clase por vez primera se carga con referencia a C2 (o algún dato o método dentro de C2).
- \bullet
- Unión tardía dinámica: La clase C2 se carga en la primera vez que una instrucción JBC (o su equivalente compilado) que se refiera a C2 (o algún dato o método dentro de C2) sea ejecutada.
Durante la operación, cuando se invoca un método
en particular de una clase en particular, la clase en particular
requerida puede estar o no ya residente en la JVM. Si la clase
requerida no es residente, entonces el fichero de clases para dicha
clase tiene que ser primeramente cargado desde el exterior de la
JVM (por ejemplo desde un disco o desde una red), enlazado e
inicializado en la JVM. A continuación, el método requerido puede
ser encontrado mediante la observación de la lista de los métodos
para la clase. Una vez que haya sido encontrado el método
requerido, el códigobyte de dicho método es ejecutado hasta que se
encuentre un retorno, con lo cual termina el método y el control es
devuelto al invocador del método. La invocación de un método puede
ser concluida también por una excepción que se lance que no esté
captada en el método.
La figura 1 muestra una implementación típica del
arte previo en la que la JVM hace uso de un compilador JIT. El
compilador JIT 120 adquiere el códigobyte de clase 110, justo
antes de ser utilizado, y lo traduce al código nativo 130 listo para
su ejecución en un procesador específico. El resto de las clases
140 (o posiblemente la totalidad de la clase) permanece disponible
en la memoria en caso de que el código nativo 130 tener que
referirse al mismo mientras que esté en ejecución.
La figura 3 muestra una típica implementación JVM
del arte previo en un entorno de multiprocesador. Un servidor 210
mantiene un almacenamiento de clases 220 para retener el códigobyte
de distintas clases que puedan ser necesarias por los procesadores
cliente 230, 240. En este ejemplo, los procesadores 230, 240 son
de dos tipos, es decir, cliente tipo 1 y cliente tipo 2,
respectivamente. El servidor suministra los ficheros de clases,
según sea necesario, a través de la red de comunicaciones
generalmente indicada en 250 hacia los clientes 230, 240. Cada uno
de los clientes 230, 240 mantiene su propio JIT, respectivamente
231, 241, permitiéndole compilar el fichero de clases a su propia
versión del código nativo, y almacenándolo en su propio
almacenamiento de código nativo 232, 242. El código nativo puede
entonces ser ejecutado en los clientes individuales.
Un problema existente con la configuración
anterior es que precisa de un entorno de gran ejecución en cada uno
de los clientes. Los compiladores JIT son típicamente grandes, y
puede ser difícil si no imposible proporcionar el espacio necesario
en el cliente, particularmente en un sistema incrustado en el cual
el cliente comprende, por ejemplo, un teléfono móvil. Una solución
alternativa (no mostrada) sería llevar a cabo la compilación JIT en
el servidor, y suministrar a los clientes la versión nativa de cada
clase, según sea necesaria. Aunque esto requiere menos espacio en
cada uno de los clientes, tiene otros inconvenientes, es decir, una
complejidad adicional substancial en el servidor. Puesto que cada
JIT depende del procesador, el servidor tendría una configuración
tal que mantuviera un JIT distinto para cada tipo de procesador que
pudiera ser atendido. Aunque ello podría ser posible en una red
fija, es realístico por ejemplo en un sistema de telefonía móvil en
donde un gran numero de teléfonos distintos, de diferentes tipos y
marcas, se encuentran constantemente conectándose y desconectándose
con el servidor. Los propietarios del servidor tendrían la tarea
extremadamente difícil de mantener operaciones de JIT de todos los
tipos conocidos de teléfonos móviles, y manteniendo una
actualización de los JIT conforme se incorporaran nuevos teléfonos
al mercado. Por dicha razón, es preferible para el servidor
mantener sencillamente un almacenamiento de clases genéricas 220, y
para los clientes individuales llevar a cabo las traducciones
dependientes del procesador. Tal como se expuso anteriormente, no
obstante, esto se ha probado que es difícil de implementar en la
práctica debido a las memorias limitadas disponibles dentro de
sistemas incrustados.
El arte previo más reciente está expuesto en el
documento EP-A-0913769 (SUN
MICROSYSTEMS, Inc.), que expone la descarga de ficheros de clases
desde un servidor a una plataforma cliente, y ejecutando el
códigobyte bien sea directamente por medio de un intérprete o
utilizando un JIT. Las características relevantes están configuradas
en las partes de precaracterización de las reivindicaciones
adjuntas. Un documento adicional del arte previo es de Bertil
Folliot y otros: "Máquinas Virtuales Virtuales", Cabernet
Radicals Workshop,
17-Septiembre-1997, XP0002135231
Creta.
Es un objeto de la presente invención al menos
mitigar algunos de los problemas del arte previo antes
mencionados.
De acuerdo con un primer aspecto de la invención,
se proporciona un método para traducir un programa de ordenador
orientado a objetos tal como se configura en la parte de
caracterización de la reivindicación 1. De acuerdo con un segundo
aspecto de la invención, se proporciona un sistema distribuido de
ordenador tal como se configura en la parte de caracterización de
la reivindicación 19.
Se comprenderá, por supuesto, que en la
descripción y en las reivindicaciones, la palabra "código"
incluye a los datos en los que los datos son parte del programa en
sí. En consecuencia, aunque sin limitación, la expresión
"código" incluye cosas tales como las constantes, nombres
variables y tipos, banderas, punteros, nombres de objetos y así
sucesivamente.
En una realización preferida, el programa de
ordenador orientado a objetos está escrito en Java (marca registrada
de Sun Microsystems Inc.) y está diseñado para ser implementado en
una máquina virtual Java (JVM).
Se utilice o no Java, no obstante, el proceso de
traducción de dos etapas de la presente invención proporciona una
primera etapa, la cual es totalmente independiente de la plataforma
y una segunda etapa que es dependiente de la plataforma. El código
del Procesador Virtual que resulta de la primera traducción es
independiente de la máquina, y por tanto es totalmente portable. La
tarea requerida en la escritura de nuevo traductor para traducir el
código del Procesador Virtual a una nueva plataforma es
significativamente mucho menor que lo que seria preciso para
transportar el códigobyte JIT a la nueva plataforma. Si se utiliza
Java, las nuevas aplicaciones pueden ser escritas directamente en
Java, mediante programadores con experiencia en Java, quienes no
tienen conocimiento alguno en el código del Procesador Virtual. Se
precisa un nuevo traductor nativo para traducir el código del
Procesador Virtual al código nativo, aunque no para cada programa
nuevo de aplicación, sino solo para cada nueva plataforma sobre la
cual tenga que ejecutarse el programa. Esto da lugar a unos ahorros
de tiempo significativos para los programadores de aplicaciones. Se
prevé que los traductores nativos estarán disponibles fácilmente
para tipo común de procesador, por lo que los proveedores de
aplicaciones necesitan solamente adquirir los traductores
relevantes para los procesadores sobre los cuales las aplicaciones
estén diseñadas para ser ejecutadas en los mismos;
alternativamente, los traductores nativos podrían ser suministrados
como estándar con las propias máquinas de usuario finales.
En una realización, la presente invención es
particularmente útil cuando una aplicación común tenga que ser
ejecutada en varios procesadores conectados en red. La traducción
del códigobyte al código del Procesador Virtual puede llevarse a
cabo en un servidor central, el cual pueden proporcionar también
verificación de los ficheros de clases del Procesador Virtual. Una
vez que haya sido verificado el código del Procesador Virtual, puede
ser distribuido a los procesadores cliente individuales, bien por
medio de una difusión en red o alternativamente bajo demanda. Cada
procesador cliente mantiene su propio traductor nativo, el cual lo
utiliza para traducir el código del Procesador Virtual en su propia
variedad particular de código nativo. Los dispositivos cliente
conectados en red pueden ser heterogéneos, es decir que pueden
utilizar tipos diferentes de procesadores. Ello no es un problema
en la realización preferida de la invención, puesto que cada
dispositivo cliente traducirá al código nativo apropiado según su
propio tipo de procesador.
Con dicha configuración, el servidor necesita
solamente mantener el código del procesador virtual. No se precisa
conocer ni tener cuidado sobre cual es el tipo de procesador o
procesadores que se estén utilizando en los dispositivos cliente
conectados en red.
Se espera que la presente invención tenga
aplicación en particular en el campo de las comunicaciones
radioeléctricas, (redes cliente radioeléctricas), y específicamente
aunque no en forma exclusiva en el campo de las redes telefónicas de
teléfonos móviles celulares. En una realización preferida de la
invención, el software de aplicación en cada teléfono móvil será
automáticamente actualizado, de una forma que sea totalmente
transparente para el usuario, mediante la descarga de las
actualizaciones necesarias del código del Procesador Virtual desde
el servidor central. La descarga podría efectuarse a intervalos
regulares, o bajo demanda, o según sea necesario, por ejemplo cuando
el usuario intente utilizar por vez primera alguna funcionalidad
específica que el teléfono no tenga todavía programada. Una
solución similar puede tomarse con otros dispositivos conectados en
red tales como los ordenadores portátiles (sin limitación),
consolas de juegos, cámaras, o realmente cualquier otro tipo de
dispositivo conectado en red o conectable en red. En una
realización, la red puede consistir o incluir una red
radioeléctrica, mientras que en otras realizaciones puede incluir
una red fija privada o pública, o bien Internet. Cuando los
dispositivos cliente no sean capaces de la comunicación
radioeléctrica, puede hacerse provisión para que se acoplen a
Internet según sea preciso (por ejemplo a través de un módem
estándar, o un enlace ISDN). De esta forma, la invención podría
ser aplicable a una amplia gama de dispositivos incrustados,
incluyendo por ejemplo cámaras, televisores, máquinas de lavar,
vehículos a motor, o en realidad virtualmente cualquier otro tipo
de dispositivo operado por ordenador que pueda concebirse.
La invención se extiende a un sistema de
ordenador para llevar a cabo cualquiera de los métodos descritos, y
a un ordenador correspondiente esté incrustado o no en un soporte
de datos. La invención se extiende además a un flujo de datos
representativo de un programa de ordenador para llevar a cabo el
método descrito.
La invención puede ser llevada a la práctica de
varias formas, y se describirá a continuación una realización
específica, a modo de ejemplo, con referencia a los dibujos
adjuntos en los que:
La figura 1 muestra la operación de un compilador
JIT convencional dentro de una JVM (máquina virtual Java);
la figura 2 muestra el proceso de traducción de
dos etapas de la realización preferida de la presente invención;
la figura 3 muestra un sistema típico de
cliente/servidor del arte previo;
la figura 4 muestra la operación de la
realización preferida de la invención dentro de un sistema
cliente/servidor;
la figura 5 muestra la operación de la presente
invención dentro de una red radioeléctrica; y
la figura 6 muestra ciertos aspectos de la
traducción del código al código del procesador virtual intermedio de
acuerdo con una realización preferida de la invención.
La figura 1, que ya ha sido descrita
anteriormente, muestra la forma en la que un compilador JIT dentro
de una máquina virtual Java (JVM) traduce desde el códigobyte
independiente del procesador al código nativo dependiente del
procesador para ser ejecutado en un procesador en particular. En la
presente invención, la conversión desde el códigobyte al código
nativo tiene lugar en dos etapas independientes:
- 1.
- Conversión desde el fichero de clases a un formato intermedio independiente del procesador. Esto se denominará como el código del Procesador Virtual o VP. El convertidor en sí es conocido en la implementación preferida como el "traductor de jcódigo".
- 2.
- Conversión desde el formato intermedio VP al código máquina nativo. El convertidor será conocido aquí como el "traductor nativo".
La figura 2 muestra con más detalle la traducción
desde el códigobyte al código nativo. El códigobyte de clases 210 es
primeramente comprobado para ver si tiene validez mediante un
verificador de clases 211. Este comprueba no solo los bytes
individuales en sí, sino también comprueba si son válidas las
referencias internas y externas. El verificador de clases si es
necesario carga las clases adicionales para comprobar las
referencias externas.
Una vez que se ha comprobado el código, se pasa
al traductor de jcódigo 212, el cual convierte el mismo, según se
describe con más detalle más adelante, en el código VP 213. El
código VP 213 es convertido entonces por el traductor nativo 214 en
el código nativo 230.
Es importar apreciar que el verificador de clases
211, el traductor de jcódigo 212 y el código VP 213 son todos
independientes del procesador. Es solo el traductor nativo 214 y
por supuesto el código nativo final 230, los que son específicos
para el procesador.
El uso de la realización preferida dentro del
entorno multiprocesador heterogéneo se muestra esquemáticamente en
la figura 4. Esto deberá ser comparado con la solución
correspondiente del arte previo mostrada en la figura 3.
En la figura 4, el servidor 410 está atendiendo a
dos clientes 430, 440 (que tienen procesadores diferentes), a
través de una red de comunicaciones 450. Todo el cálculo
independiente del procesador se lleva a cabo en el servidor; en
particular, el servidor mantiene un almacenamiento de clases 420,
un verificador de clases 421, un traductor de jcódigo 422 y un
almacenamiento VP 423. El código VP (independiente del procesador)
puede ser atendido, según se precise, a través de la red 450 a los
clientes individuales. El código VP es entonces traducido por los
traductores cliente individuales 424, 425, y el código nativo para
el procesador específico almacenado dentro de los almacenamientos
de código nativo 432, 442.
El uso del VP en el servidor, tal como se muestra
en la figura 4, permite la verificación de los ficheros de clases y
que se ejecute la primera etapa de la compilación (la conversión a
código VP) solo mediante el servidor. A continuación, solo la
traducción nativa (que difiere según el tipo de procesador) necesita
ser ejecutada por el dispositivo cliente antes de la ejecución.
Dicha configuración hace que sea fácil suministrar clases
actualizadas en el servidor, sin que el servidor necesite tener
conocimiento sobre los detalles de los clientes particulares que
deseen hacer uso de dichas clases. Una clase actualizada necesita
ser modificada solo una vez, en el códigobyte de clases, y después
traducida una vez solamente en el VP. El VP se transmite a los
dispositivos cliente, según sea necesario, y la traducción final al
código nativo puede llevarse a cabo de forma que sea totalmente
transparente para el usuario final. Adicionalmente, no se precisa
modificación alguna en el servidor o en el código VP en el caso de
que entre un nuevo tipo de cliente en el mercado que requiera un
código nativo diferente. El fabricante del cliente proporciona
sencillamente el cliente con un traductor nativo apropiado, y el
dispositivo deberá operar sin ninguna intervención manual en el
servidor.
Una implementación específica, mostrada en la
figura 5, es la de una red de teléfonos móviles. Los teléfonos
móviles individuales 530, 550 que utilizan la red incluyen cada uno
un traductor nativo respectivo 524, 525, y un almacenamiento de
código nativo 532, 542. Cuando sea preciso actualizar la
funcionalidad de los teléfonos, se suministra el código VP
actualizado desde un almacenamiento VP 523 en un servidor central
520. El código VP actualizado es enviado a través de una red de
comunicaciones terrestres 511 un transmisor radioeléctrico 512. El
código es entonces empaquetado y enviado a través de un enlace
radioeléctrico 513 a los teléfonos individuales. A la recepción, el
código VP es traducido automáticamente a nativo, y siendo
almacenado en el almacenamiento de código nativo. El proceso
completo puede ser transparente para el usuario del teléfono; o
alternativamente, el código actualizado puede ser enviado a la
recepción de una petición específica del usuario del teléfono, a
través del enlace radioeléctrico 513.
Volviendo ahora de nuevo a la figura 2, se darán
detalles adicionales de la traducción en dos etapas desde el
códigobyte de clases 210 al código nativo 230. Tal como se expuso
anteriormente, el verificador de clases 211 comprueba la validez
del códigobyte de clases. El verificador de clases puede en ciertas
realizaciones ser incorporado dentro del traductor de jcódigo, en
cuyo caso el códigobyte de clases 210 se hace pasar directamente al
traductor de jcódigo 212 tal como se muestra mediante la flecha
240.
La JVM y las instrucciones del códigobyte que la
implementan están basadas en una pila, lo que significa que los
operandos (números, punteros a objetos) se guardan en una pila,
sobre la cual la última instrucción que se introdujo será la primera
que será extraída fuera de la pila. Una instrucción de códigobyte
extrae típicamente uno o más operandos de la pila, ejecuta alguna
acción, y presiona el operando del resultado (si lo hubiere) sobre
la pila. Por el contrario, el VP está basado en registros, porque
tiene un conjunto de registros que están direccionados directamente
por las instrucciones VP. Una instrucción típicamente adquiere su
operando(s) del registro(s) especificado en la
instrucción, ejecuta una cierta acción, y coloca el operando del
resultado (si lo hubiere) dentro de un registro adicional
especificado en la instrucción. Esta arquitectura, basada en
registros, es más similar a la mayoría de los procesadores reales,
excepto en que el VP tiene un número muy grande de registros
suficientemente grandes para que cualquier sistema que convierta al
VP no necesite preocuparse sobre el número de registros que
existen.
Las instrucciones del VP están basadas en tono a
expresiones. Una sola instrucción típicamente tiene uno o dos
operandos, y cada operando puede ser una constante, un registro, o
una expresión. Una expresión tiene entonces uno o dos operandos,
cada uno de los cuales puede ser una constante, un registro o una
expresión. De esta forma, puede construirse una instrucción
arbitrariamente compleja.
Sigue a continuación ahora una descripción más
detallada de la forma en que se convierten las partes de una clase.
La descripción utiliza el término "arreglo"; este es una
unidad pequeña de datos, fijada en un punto en particular del código
o datos de salida del compilador, la cual ordena la JVM que el
código o datos en dicho punto necesita ser modificado de alguna
forma antes de que pueda ser utilizado. Los arreglos se utilizan
para cambiar una instrucción nativa o una unidad de datos de forma
tal que el código nativo pueda obtener una referencia directa a otra
clase, o a un campo o método.
Un fichero de clases Java comprende las partes
siguientes:
- \bullet
- Una unidad de memoria constante, la cual contenga los números constantes y nombres en las otras partes del fichero de clases, en lugar de un nombre, existiendo una referencia a un nombre que esté almacenado aquí.
- \bullet
- Información tal como el nombre de esta clase, de la superclase y de cualesquiera superinterfaces directas.
- \bullet
- Una lista de campos, con información en cada uno.
- \bullet
- Una lista de métodos, con información en cada uno. Esta información incluye su sección de código. Así pues, existen varias secciones de código, una para cada método.
El fichero de clases Java se convierte a las
herramientas VP de la forma siguiente:
- \bullet
- Una herramienta de datos. A pesar de su nombre, esto no tiene nada que ver con los datos a utilizar por la clase. En su lugar, contiene información sobre una clase, incluyendo aunque sin limitación los nombres, parámetros y tipos de todos los constructores, campos, métodos y demás entidades que conforman el API de una clase. Un uso típico para esto sería la reflexión (es decir, la funcionalidad en java.lang.reflect en una Librería Java). La reflexión es una interfaz programática para permitir que un programador pueda enumerar y manipular los constructores, campos, métodos y otras entidades que pertenezcan a una clase. La herramienta de datos se utiliza también por los traductores de verificación del jcódigo, en situaciones en que el fichero de clases no está disponible, o cuando el fichero de clases haya sido ya traducido. Cuando la clase está escrita en VP, no existe fichero de clases en modo alguno.
- \bullet
- Una herramienta de clases. Esta contiene alguna información de mantenimiento utilizada por la JVM (incluyendo el tamaño del objeto a asignar, el tamaño de los datos estáticos de la clase sí los hubiere, y la superclase y las superinterfaces), y el código para ninguno, algunos o todos los métodos.
- \bullet
- Cero o más herramientas de métodos. Los métodos que no aparecen en la herramienta de clases tienen sus propias herramientas individuales. La decisión de sí colocar un método en su propia herramienta puede estar basada en varios factores tales como el tamaño del método.
- \bullet
- Una herramienta de arreglo. Una herramienta de arreglo devuelve típicamente un valor de arreglo constante, el cual utiliza para determinar el desplazamiento dentro de un campo en particular. La herramienta es invocada en el instante de arreglo para proporcionar el desplazamiento, y el enlazador incrusta este desplazamiento en el código que precisa su utilización. Se utiliza así para implementar tanto la "obtención de un campo" como para "situar un campo" en el códigobyte. Más en general, la herramienta de arreglo devuelve los datos utilizados para los arreglos. Esto puede ser determinado solamente en el instante del arreglo, y no en el instante de la compilación. Los datos pueden incluir, aunque sin limitación, el tamaño de una instancia de clase, y el desplazamiento dentro de una instancia de clase de un campo.
La herramienta de datos puede ser omitida si se
sabe que la aplicación Java no utiliza ciertas funciones (en gran
medida la reflexión), y la herramienta de arreglo puede ser
omitida si la aplicación Java tiene que ser incrustada en un
dispositivo que no cargue dinámicamente más clases Java.
El código VP no implementa directamente los
mecanismos de los ficheros de clases para acceder a otra clase,
método o campo desde dentro del códigobyte. En el códigobyte
existen instrucciones, aunque sin limitación, para llamar a un
método (en ésta o en otra clase), obteniendo el contenido de un
campo (en ésta o en otra clase), presionando un valor sobre la
pila, expulsando un valor fuera de la pila y configurando el
contenido de un campo. El traductor jcódigo convierte éstos en las
instrucciones VP, las cuales pueden ejecutar una de las siguientes
funciones (esta no es una lista exhaustiva):
- \bullet
- Llamar a un método no estático (es decir, uno al cual tenga que ser pasado un puntero de objetos) en una clase. El VP tiene el concepto de una clase con métodos, el cual se utiliza para implementar clases Java. Dichos métodos pueden ser llamados virtualmente (el método real llamado depende de la clase del objeto cuyo puntero haya sido pasado) o no virtualmente (el método llamado está en la clase especificada en la llamada).
- \bullet
- Llamar a una subrutina. Esto se emplea para implementar la llamada del códigobyte de un método estático (es decir, uno al cual no se necesite pasar el puntero del objeto), y en ciertos casos un método no estático.
- \bullet
- Obtener el valor de arreglo constante desde la unidad de memoria del arreglo.
La unidad de memoria constante dentro de un
fichero de clases es convertida de la forma siguiente:
- \bullet
- Una entrada a la unidad de memoria constante conteniendo un número constante (entero o de coma flotante) que se encuentra incorporada en la versión compilada de la instrucción JBC, que hace referencia al número constante.
- \bullet
- Una entrada de la unidad de memoria constante que contiene datos de cadenas que se utilizan directamente por una instrucción JBC, que es copiada en los datos anexos al código de salida del compilador.
- \bullet
- Otras entradas de la unidad de memoria constante que contienen datos de cadenas que no se utilizan directamente, pero que se emplean al ser referidas por los tipos de unidades de memoria constantes expuestas más adelante, o por otras partes del fichero de clases.
- \bullet
- Una entrada de la unidad de memoria constante que hace referencia a una clase C, que provoca una referencia de arreglo de la clase C (o el nombre interno de la JVM para la clase) para ser anexada al código/datos de salida del compilador, de forma tal que una instrucción JBC que utilice esta entrada de la unidad de memoria constante de referencia a C, sea compilada a una secuencia de código nativo, la cual después de aplicar el arreglo, pueda obtener el acceso al código y datos de la clase C.
- \bullet
- Una entrada de la unidad de memoria constante que hace referencia a un campo F en una clase C, que provoque un arreglo que haga referencia de F en C (o el nombre interno de la JVM para F en C) a anexar al código/datos de salida del compilador, de forma tal que una instrucción JBC que utilice esta entrada de la unidad de memoria constante para referirse a F, sea compilada a una secuencia de código nativo, la cual después de aplicar el arreglo pueda obtener el acceso al campo F.
- \bullet
- Una entrada a la unidad de memoria constante que haga referencia a un método M en una clase C, que provoque un arreglo de referencia de M en C (o el nombre interno de la JVM para M en C) a anexar al código/datos de salida del compilador, de forma tal que una instrucción JBC que utilice esta entrada de la unidad de memoria constante que se refiera a M, sea compilada a una secuencia de código nativo, la cual después de aplicar el arreglo pueda obtener el acceso al método M.
- \bullet
- Una entrada a la unidad de memoria constante proporcionando un nombre y tipo de un campo o método que no se utiliza directamente., pero que se emplea al ser referida por otros tipos de entrada a la unidad de memoria constante o de otras partes del fichero de clases.
La sección del código dentro de un fichero de
clases es convertida según se expone a continuación:
- \bullet
- El código que efectúa simplemente los cálculos numéricos (es decir, cuando no existe referencia a un método externo) es traducido directamente desde el códigobyte a una herramienta correspondiente en VP.
- \bullet
- Tal como se muestra en la figura 6, si el códigobyte 600 tiene una referencia 610 a un campo, se convertirá en un instante de arreglo mediante la llamada 611 a la herramienta de arreglo. La llamada a la herramienta de arreglo devuelve un valor que hace referencia a la asignación del campo. Así pues, en el momento de ejecutar la instrucción se incrusta para que contenga el desplazamiento correcto.
- \bullet
- El método estático 620 se convierte a una herramienta VP correspondiente, pero con el código de arreglo 621 añadido.
- \bullet
- Al método no estático 630 se le ha añadido un arreglo para una llamada al método (es decir, una referencia al nombre del método). Eventualmente, esto llegará a ser un átomo en el código nativo final.
- \bullet
- Las convenciones de llamada son más bien diferentes en el códigobyte y en el VP. En el códigobyte convencional tal como el códigobyte de Java, los parámetros a pasar a una subrutina se colocan en la pila, seguido por una referencia al método a llamar. Se ejecuta entonces una instrucción de códigobyte para llamar a un método, el cual toma la referencia del método de la pila, la resuelve e inicia la ejecución del nuevo método con los parámetros de la pila. El control se devuelve al método original cuando se ejecutan las instrucciones de retorno. Esto se convierte al VP, el cual carga todos los parámetros en los registros del VP antes de ejecutar la instrucción GOS (ir a la subrutina), la cual ha sido arreglado para que apunte al método de destino (este arreglo puede ser unido estadística o dinámicamente). La ejecución se hace pasar a la subrutina y retorna cuando se ejecuta una instrucción de "retorno".
Las demás partes del fichero se convierten de la
forma siguiente:
- \bullet
- El nombre de la clase determina el nombre utilizado por la JVM para referirse al código y a la salida de datos por el compilador.
- \bullet
- El nombre de la superclase llega a ser cierta referencia a la superclase dentro del código y de la entrada de datos por el compilador. En la implementación preferida, los datos de salida contienen un puntero con un arreglo anexado, de forma tal que después del enlazado, el puntero apunta al código y a los datos de la superclase.
- \bullet
- El nombre de cada interfaz llega a ser cierta referencia a la interfaz dentro del código y datos de salida. En la implementación preferida, los datos de salida contienen un puntero para cada interfaz con un arreglo anexado, de forma tal que después del enlazado, el puntero apunta al código y datos de la interfaz.
- \bullet
- La información de la depuración fijada a cada método (y el nombre de fichero fuente que está almacenado en el fichero de clases), cuando esté presente, se convierte a un formado adecuado para el entorno en el cual está ejecutándose la JVM. En la implementación preferida, la información de depuración es convertida al mismo formato utilizado por las partes no Java del sistema.
La clase VP final comprende una o más
herramientas nominadas, incluyendo normalmente al menos la
herramienta de datos, la herramienta de clases, la herramienta de
arreglo y cero o más herramientas de métodos. Los nombres de las
herramientas se generan automáticamente mediante el traductor
jcodigo, estando cada uno relacionado con el nombre de la clase y
la función de cada herramienta dentro de la implementación de dicha
clase.
Volviendo de nuevo a la figura 2, se darán ahora
detalles adicionales del traductor nativo que traduce el código VP
al código nativo. Se comprenderá, por supuesto, que el código VP no
se ejecuta en sí nunca directamente en una aplicación en tiempo
real; siempre se convierte por el traductor nativo dependiente del
procesador en el código nativo apropiado para el procesador en el
cual se tiene que ejecutar.
El traductor nativo 214 es totalmente una pequeña
pieza de código (aproximadamente 150k, dependiendo del procesador),
de forma que pueda ser fácilmente almacenado en la memoria dentro de
un sistema incrustado. El traductor 214 correlaciona los registros
del VP con los registros del procesador en particular que se
utilice. El traductor 214 utiliza su conocimiento de la
arquitectura de registros del procesador real para decidir en que
punto en el código nativo de salida, los cuales son los registros
VP que deberán ser correlacionados con los registros del procesador
real, y cuales son los que deberán mantenerse en la memoria (los que
sean más lentos para su acceso). El traductor proporciona también
la optimización de las funciones dependiente de la máquina. Hasta
que el código nativo esté unido, todavía contendrá normalmente
secciones del código de arreglo. Al unir (o en ocasiones en la
ejecución) el código de arreglo será reemplazado con las
instrucciones apropiadas dependientes de la máquina. Por ejemplo,
el arreglo para un método no estático será convertido a un átomo en
el código nativo.
Tanto el traductor de jcodigo como el traductor
nativo están en sí escritos preferiblemente en codigo VP, y por
tanto pueden ser traducidos (utilizando el traductor nativo en sí)
para ejecutarse en cualquier plataforma deseada. A partir de dicho
código VP inicial, las versiones compiladas de ambos traductores
pueden ser suministradas en código nativo, optimizado para el
procesador en particular sobre el cual se ejecute el traductor.
Para compilar el código VP para el traductor de jcodigo, dicho
código se hace pasar a través del traductor nativo. Para compilar el
código VP para el traductor nativo, dicho código se hace pasar a
través del traductor nativo en sí.
Aunque la realización preferida utiliza la
Maquina Virtual Java, el concepto de la invención global es más
general, y no es esencial utilizar la JVM, o realmente Java en
absoluto. Cuando se utilice Java, no obstante, la invención descrita
permite a los programadores experimentados de aplicaciones Java
desarrollar programas en su lenguaje preferido, sin tener que
comprender, ni incluso conocer nada sobre el código VP. El único
requisito es que pueda existir un traductor de código nativo para
procesador físico sobre el cual se ejecute la aplicación. Se prevé
que dichos traductores nativos estarán generalmente disponibles, y
que los traductores apropiados podrían ser adquiridos por el
desarrollador de la aplicación o bien suministrados
alternativamente como un estándar en los dispositivos clientes
individuales, tal como los teléfonos móviles o las consolas de
juegos.
Claims (30)
1. Un método para distribuir un programa de
ordenador, orientado a objetos, caracterizado porque:
- (a)
- traduce el códigobyte del programa (210) en un código de procesador virtual independiente de la máquina (213), que utiliza un conjunto de instrucciones de un procesador virtual;
- (b)
- transmite el código del procesador virtual desde un servidor (410) a un dispositivo cliente (430); y
- (c)
- porque traduce el código del procesador virtual a código nativo (242), el cual utiliza un conjunto de instrucciones de un procesador físico el dispositivo cliente.
2. Un método según la reivindicación 1 en el
cual el códigobyte del programa incluye un fichero de clases, siendo
el fichero de clases convertido a una o más herramientas del
procesador virtual que utilizan el conjunto de instrucciones del
procesador virtual.
3. Un método según la reivindicación 2, en el
cual el fichero de clases incluye una pluralidad de métodos, y en
los que algunos o todos los métodos en el fichero de clases son
convertidos a una respectiva herramienta del procesador virtual.
4. Un método según la reivindicación 2 en el que
el fichero de clases incluye una llamada a un método, y en los que
el código del procesador virtual proporciona una llamada a una
herramienta correspondiente.
5. Un método según la reivindicación 2, en el que
el fichero de clases incluye una referencia a un campo (610), y en
el cual el código del procesador virtual proporciona una herramienta
de arreglo (611) para su utilización en la asignación del
campo.
6. Un método según la reivindicación 5 en el cual
la herramienta de arreglo está configurada para que devuelva un
valor de arreglo constante, el cual es representativo del
desplazamiento del mencionado campo dentro de un objeto.
7. Un método según la reivindicación 6 que
incluye el enlace del código del procesador virtual y determinando
el valor de arreglo constante en dependencia del código del
procesador virtual, el cual se ha trasladado desde otro fichero de
clases.
8. Un método según la reivindicación 6 ó 7, en el
cual la herramienta de arreglo devuelve un valor que se utiliza para
insertar un método que obtiene o coloca el valor de un campo.
9. Un método según la reivindicación 2, en el
cual el código del procesador virtual tiene instrucciones de arreglo
incluidas dentro del mismo en una pluralidad de puntos, que indican
que el código en los mencionados puntos tiene que modificarse por
la respectiva instrucción de arreglo con antelación a su
utilización.
10. Un método según la reivindicación 7, en el
cual las instrucciones de arreglo proporcionan instrucciones de cómo
el código nativo puede hacer referencia a otra clase, o un campo o
un método en otra clase.
11. Un método según la reivindicación 9 ó 10, en
el cual las instrucciones de arreglo son transferidas,
substancialmente inalteradas en sus funciones, por el traductor
nativo al código nativo; siendo reemplazadas las instrucciones de
arreglo con instrucciones nativas cuando el código nativo está unido
sobre el mencionado procesador físico real.
12. Un método según cualquiera de las
reivindicaciones 1 a 11, en el cual el códigobyte está basado en una
pila, y en el cual el código del procesador virtual está basado en
registros.
13. Un método de ejecución de un programa de
ordenador orientado a objetos que comprende la traducción del
programa al código nativo según cualquiera de las reivindicaciones
anteriores, y ejecutando el código nativo en el procesador
físico.
14. Un método según la reivindicación 13 cuando
sea dependiente de la reivindicación 2, incluyendo la unión de las
herramientas trasladadas en una tarea, y ejecutando la tarea en
código nativo en el procesador físico.
15. Un método según cualquiera de las
reivindicaciones 1 a 12, que incluye además:
- (d)
- transmitir el código del procesador virtual desde el servidor a un segundo dispositivo cliente (440); y
- (e)
- traducir el código del procesador virtual al código nativo distinto que utiliza un conjunto de instrucciones de un procesados físico del segundo dispositivo cliente.
16. Un método según la reivindicación 13 ó 14,
incluyendo la ejecución del código nativo distinto en los
procesadores físicos de los distintos dispositivos clientes.
17. Un sistema distribuido de ordenador que
comprende un servidor (410) y una pluralidad de dispositivos
clientes remotos (430, 440), en comunicación con el servidor,
incluyendo cada dispositivo cliente un procesador cliente,
caracterizado porque el servidor incluye un almacenamiento
para almacenar el código del procesador virtual (423), siendo el
mencionado código una representación dependiente de la máquina de
un programa de ordenador orientado a objetos, utilizando un conjunto
de instrucciones de un procesador virtual, y mediante un traductor
nativo (424, 425) configurado para traducir el código del
procesador virtual en el código nativo que utilice el conjunto de
instrucciones del respectivo procesador cliente, y un almacenamiento
de código nativo (432, 442); y porque el sistema incluye medios de
transmisión (450) para transmitir el código del procesador virtual
desde el servidor a los dispositivos clientes.
18. Un sistema distribuido de ordenador según la
reivindicación 17, en el cual los medios de transmisión comprenden o
incluyen una red radioeléctrica (513).
19. Un sistema distribuido de ordenador según la
reivindicación 18, en el cual los dispositivos son teléfonos móviles
(530, 550).
20. Un sistema distribuido de ordenador según la
reivindicación 18, en el cual los dispositivos con ordenadores
portátiles.
21. Un sistema distribuido de ordenador según la
reivindicación 17 ó 18, en el cual los dispositivos clientes son
consolas de juegos portátiles.
22. Un sistema distribuido de ordenador según la
reivindicación 17, en el cual al menos uno de los dispositivos
clientes incluye un primer tipo de procesador cliente y en el cual
al menos otro de los dispositivos clientes incluye un segundo tipo
de procesador cliente, utilizando un conjunto de instrucciones
distinto al del primer tipo.
23. Un sistema distribuido de ordenador según
cualquiera de las reivindicaciones 17 a 22, en el cual el servidor
está configurado además para traducir el programa del ordenador
orientado a objetos desde el códigobyte al código del procesador
virtual.
24. Un método según cualquiera de las
reivindicaciones 2 a 11, o la reivindicación 12 cuando sea
dependiente de la reivindicación 2, incluyendo la verificación de la
integridad del códigobyte de clases, y de cualquiera de las
llamadas externas.
25. Un método según cualquiera de las
reivindicaciones 2 a 11, o la reivindicación 12 cuando sea
dependiente de la reivindicación 2, en el cual el fichero de clases
es un fichero de clases Java.
26. Un método según cualquiera de las
reivindicaciones 1 a 12, 24 ó 25, en el cual la etapa de traducir el
códigobyte del programa al código del procesador virtual se lleva
a cabo mediante un primer programa traductor, el cual está en sí
mismo escrito en código del procesador virtual.
27. Un método según cualquiera de las
reivindicaciones 1 a 12, 24, 25 ó 26, en el cual la etapa de
traducir el código del procesador virtual al código nativo se lleva
a cabo mediante un segundo programa traductor, el cual está en sí
mismo escrito en el código del procesador virtual.
28. Un programa de ordenador para ejecutar un
método según cualquiera de las reivindicaciones 1 a 12 ó 24 a
27.
29. Un soporte de datos que transporta un
programa de ordenador para ejecutar un método según cualquiera de
las reivindicaciones 1 a 12 ó 24 a 27.
30. Un flujo de datos representativo de un
programa de ordenador para ejecutar un método según cualquiera de
las reivindicaciones 1 a 12 ó 24 a 27.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB9920676.5A GB9920676D0 (en) | 1999-09-01 | 1999-09-01 | Translating and executing object-oriented computer programs |
| GB9920676 | 1999-09-01 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2209947T3 true ES2209947T3 (es) | 2004-07-01 |
Family
ID=10860172
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00953341T Expired - Lifetime ES2209947T3 (es) | 1999-09-01 | 2000-08-16 | Metodo y sistema para la distribucion de programas de ordenador orientados a objetos. |
Country Status (12)
| Country | Link |
|---|---|
| US (1) | US20040015911A1 (es) |
| EP (1) | EP1214645B1 (es) |
| JP (1) | JP2003508844A (es) |
| KR (1) | KR20020085872A (es) |
| AT (1) | ATE253748T1 (es) |
| AU (1) | AU777773B2 (es) |
| CA (1) | CA2383884A1 (es) |
| DE (1) | DE60006410T2 (es) |
| ES (1) | ES2209947T3 (es) |
| GB (1) | GB9920676D0 (es) |
| HK (1) | HK1048527B (es) |
| WO (1) | WO2001016700A2 (es) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7836395B1 (en) | 2000-04-06 | 2010-11-16 | International Business Machines Corporation | System, apparatus and method for transformation of java server pages into PVC formats |
| US6658656B1 (en) * | 2000-10-31 | 2003-12-02 | Hewlett-Packard Development Company, L.P. | Method and apparatus for creating alternative versions of code segments and dynamically substituting execution of the alternative code versions |
| AU2002235232B2 (en) | 2000-12-18 | 2006-01-12 | Ack Ventures Holdings, Llc | A system and method for delivering content to mobile devices |
| US7082597B2 (en) * | 2001-06-20 | 2006-07-25 | Sun Microsystems, Inc. | Representation of objects in a Java programming environment |
| US7036120B2 (en) * | 2001-07-31 | 2006-04-25 | Sun Microsystems, Inc. | Two tier clusters for representation of objects in Java programming environments |
| FI113709B (fi) | 2001-12-10 | 2004-05-31 | Nokia Corp | Menetelmä sulautetussa ympäristössä etälaitteen toiminnallisuuden järjestämiseksi |
| WO2004073376A2 (en) * | 2003-02-20 | 2004-09-02 | Koninklijke Philips Electronics N.V. | Translation of a series of computer instructions |
| GB0316531D0 (en) * | 2003-07-15 | 2003-08-20 | Transitive Ltd | Method and apparatus for performing native binding |
| JP2007510987A (ja) * | 2003-10-27 | 2007-04-26 | アメリカン パワー コンバージョン コーポレイション | ソフトウェアプログラムを更新するためのシステムおよび方法 |
| US20050108690A1 (en) * | 2003-11-17 | 2005-05-19 | Tira Wireless Inc. | System and method of generating applications for mobile devices |
| US7085680B2 (en) * | 2004-01-16 | 2006-08-01 | Innova Electronics Corporation | Vehicle diagnostic tool |
| US7278122B2 (en) * | 2004-06-24 | 2007-10-02 | Ftl Systems, Inc. | Hardware/software design tool and language specification mechanism enabling efficient technology retargeting and optimization |
| KR100597414B1 (ko) | 2004-10-21 | 2006-07-05 | 삼성전자주식회사 | 데이터 처리 장치 및 이를 이용한 레지스터 할당 방법 |
| DE102004058882A1 (de) * | 2004-12-06 | 2006-06-08 | Giesecke & Devrient Gmbh | Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode |
| DE102004063688A1 (de) * | 2004-12-28 | 2006-07-13 | Vodafone Holding Gmbh | System und Verfahren zur Vermittlung von Daten zwischen einem Datenanbieter und einem Mobilfunkteilnehmer |
| US7496895B1 (en) * | 2004-12-29 | 2009-02-24 | The Mathworks, Inc. | Multi-domain unified debugger |
| KR100763177B1 (ko) * | 2005-04-21 | 2007-10-04 | 삼성전자주식회사 | 자바 가상 머신의 명령어 수행 방법 및 그 장치 |
| US20060277231A1 (en) * | 2005-06-06 | 2006-12-07 | Javaground Usa, Inc. | Integrated software development and porting system for wireless devices |
| US20060277209A1 (en) * | 2005-06-06 | 2006-12-07 | Javaground Usa, Inc. | Efficient and automatic software application development system for wireless devices |
| US8849968B2 (en) * | 2005-06-20 | 2014-09-30 | Microsoft Corporation | Secure and stable hosting of third-party extensions to web services |
| KR100862937B1 (ko) * | 2005-12-05 | 2008-10-14 | 한국전자통신연구원 | 임베디드 시스템용 자바 라이브러리의 재구조화 방법 및장치 |
| WO2007137403A1 (en) * | 2006-05-26 | 2007-12-06 | Tira Wireless Inc. | System and method of generating applications for mobile devices |
| US8789063B2 (en) * | 2007-03-30 | 2014-07-22 | Microsoft Corporation | Master and subordinate operating system kernels for heterogeneous multiprocessor systems |
| US20080244507A1 (en) * | 2007-03-30 | 2008-10-02 | Microsoft Corporation | Homogeneous Programming For Heterogeneous Multiprocessor Systems |
| US20090125611A1 (en) * | 2007-11-08 | 2009-05-14 | Barsness Eric L | Sharing loaded java classes among a plurality of nodes |
| US8397225B2 (en) | 2008-04-24 | 2013-03-12 | International Business Machines Corporation | Optimizing just-in-time compiling for a java application executing on a compute node |
| US8539464B2 (en) * | 2008-10-30 | 2013-09-17 | International Business Machines Corporation | Distributed just-in-time compilation |
| AU2011363943A1 (en) * | 2011-03-31 | 2013-10-24 | Irdeto B.V. | Method of securing non-native code |
| WO2013132767A1 (ja) * | 2012-03-09 | 2013-09-12 | パナソニック株式会社 | プロセッサ、マルチプロセッサシステム、コンパイラ、ソフトウェアシステム、メモリ制御システムおよびコンピュータシステム |
| US10540148B2 (en) * | 2014-06-12 | 2020-01-21 | Oracle International Corporation | Complex constants |
| US20180275957A1 (en) * | 2017-03-27 | 2018-09-27 | Ca, Inc. | Assistive technology for code generation using voice and virtual reality |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5339419A (en) * | 1990-06-25 | 1994-08-16 | Hewlett-Packard Company | ANDF compiler using the HPcode-plus compiler intermediate language |
| JP3602857B2 (ja) * | 1991-04-23 | 2004-12-15 | 株式会社日立製作所 | 多機種対応型情報処理システム、および、方法 |
| GB2272085A (en) * | 1992-10-30 | 1994-05-04 | Tao Systems Ltd | Data processing system and operating system. |
| US6704923B1 (en) * | 1994-12-20 | 2004-03-09 | Sun Microsystems, Inc. | System and method for pre-verification of stack usage in bytecode program loops |
| US5668999A (en) * | 1994-12-20 | 1997-09-16 | Sun Microsystems, Inc. | System and method for pre-verification of stack usage in bytecode program loops |
| US5946487A (en) * | 1996-06-10 | 1999-08-31 | Lsi Logic Corporation | Object-oriented multi-media architecture |
| JPH113225A (ja) * | 1997-06-13 | 1999-01-06 | Nec Corp | 情報処理装置 |
| US6233733B1 (en) * | 1997-09-30 | 2001-05-15 | Sun Microsystems, Inc. | Method for generating a Java bytecode data flow graph |
| US6349344B1 (en) * | 1997-12-16 | 2002-02-19 | Microsoft Corporation | Combining multiple java class files into a run-time image |
| US6539433B1 (en) * | 1998-09-30 | 2003-03-25 | Matsushita Electric Industrial Co., Ltd. | System for distributing native program converted from Java bytecode to a specified home appliance |
| US6389590B1 (en) * | 1999-06-22 | 2002-05-14 | Microsoft Corporation | Indefinite-size variables within an intermediate language |
| US6704926B1 (en) * | 2000-09-28 | 2004-03-09 | International Business Machines Corporation | Bimodal Java just-in-time complier |
-
1999
- 1999-09-01 GB GBGB9920676.5A patent/GB9920676D0/en not_active Ceased
-
2000
- 2000-08-16 KR KR1020027002858A patent/KR20020085872A/ko not_active Application Discontinuation
- 2000-08-16 WO PCT/GB2000/003172 patent/WO2001016700A2/en active IP Right Grant
- 2000-08-16 ES ES00953341T patent/ES2209947T3/es not_active Expired - Lifetime
- 2000-08-16 EP EP00953341A patent/EP1214645B1/en not_active Expired - Lifetime
- 2000-08-16 AT AT00953341T patent/ATE253748T1/de not_active IP Right Cessation
- 2000-08-16 DE DE60006410T patent/DE60006410T2/de not_active Expired - Fee Related
- 2000-08-16 AU AU65852/00A patent/AU777773B2/en not_active Ceased
- 2000-08-16 CA CA002383884A patent/CA2383884A1/en not_active Abandoned
- 2000-08-16 JP JP2001520588A patent/JP2003508844A/ja active Pending
-
2002
- 2002-02-25 US US10/084,780 patent/US20040015911A1/en not_active Abandoned
- 2002-11-25 HK HK02108520.0A patent/HK1048527B/zh not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| AU6585200A (en) | 2001-03-26 |
| EP1214645B1 (en) | 2003-11-05 |
| US20040015911A1 (en) | 2004-01-22 |
| ATE253748T1 (de) | 2003-11-15 |
| HK1048527A1 (en) | 2003-04-04 |
| CA2383884A1 (en) | 2001-03-08 |
| HK1048527B (zh) | 2004-10-15 |
| KR20020085872A (ko) | 2002-11-16 |
| AU777773B2 (en) | 2004-10-28 |
| WO2001016700A2 (en) | 2001-03-08 |
| WO2001016700A3 (en) | 2001-09-20 |
| DE60006410D1 (de) | 2003-12-11 |
| EP1214645A2 (en) | 2002-06-19 |
| JP2003508844A (ja) | 2003-03-04 |
| DE60006410T2 (de) | 2004-09-16 |
| GB9920676D0 (en) | 1999-11-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2209947T3 (es) | Metodo y sistema para la distribucion de programas de ordenador orientados a objetos. | |
| US7191434B2 (en) | Loading object-oriented computer programs | |
| ES2559638T3 (es) | Método y equipo para la compilación de un lenguaje interpretativo para televisión interactiva | |
| KR101534037B1 (ko) | 컴퓨팅 플랫폼의 이종 프로세서들 간의 공유 가상 메모리에서의 가상 함수들의 공유 | |
| JP4050764B2 (ja) | コンパイルシステム | |
| Caracas et al. | Mote runner: A multi-language virtual machine for small embedded devices | |
| CN106796521B (zh) | 独立于产品发布的api版本控制 | |
| ES2209538T3 (es) | Carga de programas de ordenador orientado a objetos. | |
| CN112416418A (zh) | 应用组件的生成方法、装置、计算机设备和可读存储介质 | |
| Hsueh et al. | EcoExec: An interactive execution framework for ultra compact wireless sensor nodes | |
| CN113467861A (zh) | 文件调用方法和装置、存储介质及电子设备 | |
| CN115543332A (zh) | 编译时提前链接的方法 | |
| Hahn et al. | Nucleos: a runtime system for ultra-compact wireless sensor nodes | |
| Mike et al. | HiNRG Technical Report: 21-09-2008 A Modular Approach for WSN Applications | |
| Trebacz | Single-Chip-Linux-Computer for the HADES-experiment Data-Acquisition | |
| Regmi | TinyHive: Dynamic virtual machine for sensor networks |