ES2305316T3 - Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. - Google Patents
Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. Download PDFInfo
- Publication number
- ES2305316T3 ES2305316T3 ES02782563T ES02782563T ES2305316T3 ES 2305316 T3 ES2305316 T3 ES 2305316T3 ES 02782563 T ES02782563 T ES 02782563T ES 02782563 T ES02782563 T ES 02782563T ES 2305316 T3 ES2305316 T3 ES 2305316T3
- Authority
- ES
- Spain
- Prior art keywords
- files
- file
- class
- cod
- information
- 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
- 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/445—Program loading or initiating
- G06F9/44557—Code layout in executable memory
- G06F9/44563—Sharing
-
- 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/44—Encoding
- G06F8/447—Target code generation
-
- 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/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Warehouses Or Storage Devices (AREA)
- Television Signal Processing For Recording (AREA)
- Peptides Or Proteins (AREA)
- Debugging And Monitoring (AREA)
- Transceivers (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Electrotherapy Devices (AREA)
- Electrically Operated Instructional Devices (AREA)
- Navigation (AREA)
Abstract
Un dispositivo (400), que comprende: una unidad de memoria (404); una unidad de computación (402) conectada a la unidad de memoria (404), siendo capaz la unidad de computación (404) de ejecutar una Máquina Virtual Java; y uno o más ficheros (406) almacenados en la unidad de memoria (404), siendo el o los ficheros directamente interpretables por la Máquina Virtual Java, siendo generados el o los ficheros (406) a partir de una pluralidad de ficheros de clase (100A-100F) para reducir el espacio de almacenamiento, en el que un fichero dado (200) del o de los ficheros (406), comprende: una bolsa (202) de constantes, creada combinando entradas de bolsa de constantes de dos o más (100A, 100B) de la pluralidad de ficheros de clase (100A-100F) sin duplicación de entradas; una estructura (204) de información y de códigos de bytes creada combinando entradas de estructura de información y de códigos de bytes de los dos o más (100A, 100B) de la pluralidad de ficheros de clase (100A-100F); y una tabla de organización (208) para proporcionar información a la Máquina Virtual Java para resolver al menos una entrada del fichero dado en el momento del enlace.
Description
Método para generar un código interpretable para
el almacenamiento en un dispositivo que tiene el espacio de
almacenamiento limitado.
Los ficheros en código fuente Java (ficheros
java) son compilados para obtener ficheros con extensión
".class" mediante el compilado Java. Estos ficheros con
extensión ".class" pueden ser leídos en memoria mediante la
máquina virtual Java (VM) en un formato "en memoria" que
resulta adecuado para ser interpretado por la VM. Los ficheros con
extensión ".class" son luego enlazados con otros ficheros con
extensión ".class" que han sido leídos en forma similar. Las
referencias entre los ficheros ".class" se resuelven
simbólicamente, utilizando cadenas de caracteres. Estas cadenas de
caracteres aparecen tanto en el fichero ".class" que contiene
la definición como en el fichero ".class" que hace referencia
a la definición. Por tanto, la presencia de referencias entre
ficheros ".class" puede incrementar el tamaño de los
mismos.
Las ficheros Java ".class" pueden
archivarse (y, opcionalmente, comprimirse) en un fichero con
extensión ".jar". Sin embargo, los ficheros ".jar" no son
directamente interpretables por la VM Java y los ficheros
".class" deben extraerse (y descomprimirse, de ser aplicable)
del fichero ".jar" (y leerse en la memoria) con el fin de que
puedan ser enlazados, resueltos e interpretados por la VM Java.
Si bien los ficheros ".jar" que comprenden
ficheros ".class" archivados y comprimidos son menores que los
propios ficheros ".class" (y, por tanto, son más adecuados para
ser transmitidos entre dispositivos de comunicación), es necesario
disponer, en el entorno donde ha de ejecutarse la aplicación, de
espacio de almacenamiento para los ficheros ".class" extraídos
(y descomprimidos, si ha lugar), de manera que la VM Java pueda
acceder a los ficheros ".class". En consecuencia, una solución
que incluya ficheros ".jar" puede no representar un ahorro de
espacio de almacenamiento. De hecho, una solución que incluya
ficheros ".jar" puede exigir espacio adicional para
almacenamiento, tanto para los ficheros ".jar" como para los
ficheros ".class" extraídos. Los ficheros ".class"
extraídos no tienen que conservarse una vez que han sido cargados en
memoria, enlazados y resueltos. Sin embargo, deben conservarse
tanto el fichero ".jar" como las representaciones en memoria de
los ficheros ".class". En un entorno con un espacio de
almacenamiento limitado, cuando éste escasea, puede ser preferible,
por tanto, almacenar sólo los ficheros ".class" y no utilizar
una solución que incluya ficheros ".jar". Sin embargo, como se
ha explicado en lo que antecede, el tamaño de los ficheros
".class" aumenta cuando aumenta el número de referencias entre
ficheros ".class".
El documento US2002/0170047 (Swetland) publicado
el 14 de Noviembre de 2002, describe un objeto de programación
unificado que tiene una bolsa de constantes compartida con entradas
a la bolsa de constantes global correlacionadas respecto de
entradas a la bolsa de constantes local de dos o más ficheros de
clase, y una pluralidad de copias de código objeto de dos o más
ficheros de clase al objeto de programación unificado e
identificadas por las entradas a la bolsa de constantes global.
La solicitud de patente PCT WO 99/49392
(Baentsch y otros) publicada el 30 de Septiembre de 1999, describe
un sistema Java en tiempo de ejecución que comprende un
interpretador basado en pilas que ejecuta un programa que comprende
códigos de bytes y estructuras de clase. El sistema comprende,
además, una bolsa de constantes modificada con información interna
de uso sólo durante el enlace y con información externa a conservar
para ulterior asociación de códigos. La información interna es
retirada de la bolsa de constantes modificada tras el enlace.
Por tanto, sería beneficioso generar ficheros
directamente interpretables que tuvieran un tamaño similar al de
los ficheros ".class", al tiempo que se proporciona una
solución a las referencias entre ficheros ".class".
En un aspecto, una realización del invento
proporciona un dispositivo que comprende: una unidad de memoria;
una unidad de computación conectada a la unidad de memoria, siendo
capaz la unidad de computación de ejecutar una Máquina Virtual
Java; y uno o más ficheros almacenados en la unidad de memoria,
siendo el o los ficheros directamente interpretables por la Maquina
Virtual Java, siendo generados el o los ficheros a partir de una
pluralidad de ficheros de clase para reducir el espacio de
almacenamiento, en el que un fichero dado del o de los ficheros
mencionados, comprende: una bolsa de constantes creada por
combinación de entradas de bolsa de constantes de dos o más de la
pluralidad de ficheros de clase sin que exista duplicación de
entradas; una estructura de información y de códigos de bytes
creada combinando entradas de la estructura de información y de
códigos de bytes a partir de los dos o más ficheros mencionados de
la pluralidad de ficheros de clase; y una tabla de organización
para proporcionar información a la Máquina Virtual Java para
resolver al menos una entrada en el fichero dado en el momento del
enlace.
En otro aspecto, una realización del invento
proporciona un método para generar uno o más ficheros a partir de
una pluralidad de ficheros de clase, comprendiendo el método:
identificar los ficheros de clase con entradas comunes en bolsas de
constantes de los ficheros de clase; generar una bolsa de constantes
para un fichero generado dado combinando entradas de bolsa de
constantes procedentes de los ficheros de clase con entradas
comunes sin duplicación; generar la estructura de información y
códigos de bytes para el fichero generado dado combinando entradas
de la estructura de información y los códigos de bytes procedentes
de los ficheros de clase; y generar una tabla de organización para
proporcionar información a una Máquina Virtual Java para resolver,
al menos, una entrada en el fichero dado en el momento del
enlace.
En todavía otro aspecto, una realización del
invento proporciona un producto de programa de ordenador para
generar uno o más ficheros a partir de una pluralidad de ficheros de
clase, combinando elementos procedentes de la pluralidad de
ficheros de clase sin duplicación de entradas a fin de reducir el
espacio de almacenamiento, comprendiendo el producto de programa de
ordenador un medio legible por ordenador que incorpora medios de
código de programa ejecutables mediante un procesador de una unidad
de computación para llevar a la práctica el método del invento.
La materia considerada como objeto del invento
se señala particularmente y se reivindica en forma distintiva en la
parte de las conclusiones de la memoria descriptiva. Sin embargo, el
invento, tanto en lo que respecta a la organización como en lo que
atañe al método de trabajo, junto con sus objetos, características y
ventajas, puede comprenderse del mejor modo haciendo referencia a
la siguiente descripción detallada cuando se lee en conjunto con
los dibujos anejos, en los que:
las figs. 1A y 1B son ilustraciones
simplificadas de la técnica anterior de seis ficheros ".class"
ilustrativos;
las figs. 2A y 2B son ilustraciones
simplificadas de ficheros con extensión ".cod" ilustrativos, de
acuerdo con algunas realizaciones del presente invento;
la fig. 3 es una ilustración, en forma de
gráfico de flujo, de un método para generar ficheros ".cod" de
acuerdo con algunas realizaciones del presente invento; y
la fig. 4 es una ilustración, en forma de
diagrama de bloques simplificado de un dispositivo que tiene una
unidad de computación y una memoria directamente accesible, de
acuerdo con algunas realizaciones del presente invento.
\vskip1.000000\baselineskip
Se apreciará que, para simplificar y por
claridad de la ilustración, los elementos mostrados en las figuras
no se han dibujado, necesariamente, a escala. Por ejemplo, por
claridad, las dimensiones de algunos de los elementos pueden ser
exageradas con relación a las de otros elementos. Además, cuando se
considera apropiado, los números de referencia pueden repetirse en
diversas figuras para indicar elementos correspondientes o
análogos.
En la siguiente descripción detallada, se
describen numerosos detalles específicos con el fin de proporcionar
una total comprensión del invento. Sin embargo, los expertos
normales en la técnica comprenderán que el presente invento puede
ser llevado a la práctica en ausencia de estos detalles específicos.
En otros casos, no se han descrito con detalle métodos,
procedimientos ni componentes bien conocidos para no disminuir la
claridad del presente invento.
Los ficheros de código fuente Java (ficheros con
extensión ".java") se compilan para obtener ficheros con
extensión ".class" mediante el compilador Java. Estos ficheros
".class", una vez leídos a memoria, pueden ser enlazados,
resueltos e interpretados por la Máquina Virtual (VM) Java. Las
figs. 1A y 1B son ilustraciones simplificadas de la técnica
anterior de seis ficheros ".class" ilustrativos -fichero 100
Aa.class, fichero 100B Bb.class, fichero 100C Cc.class, fichero
100D Dd.class, fichero 100E Ee.class y fichero 100F Ff.clas- a los
que se hará referencia, en forma colectiva, como fichero 100.
La estructura del fichero ".class" está
bien documentada y no se describirá con detalle en este documento.
El fichero 100 se ilustra en formato simplificado en aras de la
claridad de la explicación; sin embargo, los expertos normales en
la técnica comprenderán que este formato simplificado no constituye
una representación exacta de la estructura del fichero 100. Cada
fichero 100 comprende una bolsa de constantes 102. La bolsa 102 de
constantes comprende entradas cp_info indexadas, algunas de las
cuales comprenden cadenas de caracteres que indican los nombre de
los ficheros ".class" y ".class" padre, los nombres de
métodos, el tipo de métodos, los nombres de campos, el tipo de
campos, etc., con referencia al interior de la estructura ClassFile
(fichero de clase). Cada fichero 100 comprende, también,
"estructuras de información y códigos de bytes" 104
relacionadas con las propiedades de la clase, los métodos, campos y
atributos de la clase y sus tipos. Estas estructuras pueden señalar
a entradas de la bolsa de constantes 102 utilizando números de
índice ordinales.
En el fichero 100 Aa.class, el método G incluye
una referencia a otro método, el método K, encontrado en la clase
Bb. De hecho, el método G se define en el fichero ".class" como
una estructura method_info (método_información) que comprende,
entre otras cosas, índices de entradas en la bolsa de constantes
102A. Sin embargo, por claridad de la descripción, la definición
del método G y su referencia al método K se muestran en la fig. 1A
en un formato simplificado. Por tanto, las cadenas de caracteres
"K" y "Bb" se incluyen en la bolsa de constantes 102A. La
inclusión de "K" y "bb" en la bolsa de constantes 102A
aparece, realmente, como parte de varias estructuras cp_info. Sin
embargo, por claridad de la descripción solamente, las cadenas de
caracteres "K" y "Bb" se ilustran en la fig. 1A. Como el
argumento del método K es de tipo entero, el carácter "I"
BaseType (tipo de base) se incluye en la bolsa de constantes 102A.
La referencia simbólica al método K por el método G en las
estructuras de información y códigos de bytes 104A comprende los
índices de las estructuras cp_info pertinentes en la bolsa de
constantes 102A.
Similarmente, en el fichero 100B Bb.class, el
método K se define en la clase Bb, de modo que la bolsa de
constantes 102B incluye todas las cadenas "Bb", "K" y el
carácter "I" BaseType (que representa el tipo "int").
Las figs. 2A y 2B son ilustraciones
simplificadas de ficheros ".cod" ilustrativos, cuya generación
se describirá en lo que sigue con respecto a la fig. 3. Los
ficheros ".cod" son ficheros directamente interpretables que
comprenden la información de los ficheros ".class" en una
manera que requiere menos espacio de almacenamiento que los propios
ficheros ".class". Los ficheros ".cod" pueden ser ficheros
".cod" "sólo" o ficheros ".cod" "hermanos",
como se explicará con mayor detalle en lo que sigue.
En el ejemplo mostrado en la fig. 2B el fichero
".cod" sólo 220 se denomina "EeFf.cod" para indicar que es
el resultado de combinar los ficheros Ee.class y Ff.class, si bien
el alcance del presente invento no está limitado a este aspecto. El
fichero EeFf.cod sólo 220 comprende una bolsa de constantes 222, una
o más tablas de organización 228 y "estructuras de información y
de códigos de bytes" 224 relativas a las propiedades de la
clase, los métodos, campos y atributos de la clase, y sus tipos.
La fig. 3 es una ilustración en forma de
diagrama de flujo simplificada de un método para la generación de
ficheros ".cod" a partir de una colección de ficheros
".java" o de ficheros ".class". El método puede ser
llevado a la práctica mediante software ejecutable en un ordenador
para uso general, estando provisto el software, por ejemplo, como
parte de un kit de desarrollador de software (SDK).
Se recibe una lista de ficheros ".java" o
de ficheros ".class" (paso 300). Si la entrada consiste en
ficheros ".java", entonces se aplica un compilador Java a los
mismos para producir los correspondientes ficheros ".class"
(paso 302). Alternativamente, aunque esto no se muestra en la fig.
3, podrían recibirse uno o más ficheros ".jar" y, a partir de
ellos, podría extraerse información relativa a los ficheros
".class" archivados.
El software ejecutable identifica las entradas
comunes de las bolsas de constantes de los ficheros ".class"
(paso 304). Por ejemplo, en la fig. 1B, la cadena de caracteres del
nombre de la clase madre "java/lang/Object"
(java/leng/Objeto), la cadena de caracteres "T" del nombre del
método y el carácter "C" BaseType (Tipo de base) (que
representa el tipo "char" (carácter)) son comunes al fichero
100E Ee.class y al fichero 100F Ff.class.
El software ejecutable identifica las
referencias cruzadas entre clases, métodos y campos en los ficheros
".class" (paso 306). Por ejemplo, en la fig. 1B, al método Ee.T
se hace referencia a través de método Ff.U.
El software ejecutable genera entonces el
fichero ".cod" combinando elementos de los ficheros
".class" (paso 308). A diferencia de los algoritmos de
compresión estándar que comprimen los datos independientemente de
su contenido, la combinación de elementos de los ficheros
".class" en el fichero ".cod" se realiza de forma
diferente basándose en el tipo de elemento y en su contenido. Por
ejemplo, el fichero ".cod" comprende una bolsa de constantes
cuyas entradas incluyen la información almacenada en las bolsas de
constantes de los ficheros ".class", pero sin duplicaciones de
entradas redundantes. En el fichero ".cod" generado, la bolsa
de constantes contiene, únicamente, una sola copia de las entradas
comunes identificadas en el paso 304. Por ejemplo, en la fig. 2B,
la bolsa de constantes 222 del fichero EeFf.cod sólo comprende
únicamente una instancia de cadenas de caracteres
"java/lang/Object" y "T" y una instancia del carácter
"C" BaseType.
El software ejecutable utiliza desplazamientos
fijos en el fichero ".cod" sólo generado para referencias
cruzadas entre clases y métodos definidos en los ficheros
".class" que se combinan. Por ejemplo, en la fig. 2B, la
referencia al método Ee.T por el método Ff.U en las "estructuras
de información y códigos de bytes" 224 comprende un
desplazamiento fijo, HO_{Ee.T}, que especifica la situación de la
definición del método Ee.T dentro del fichero EeFf.cod sólo 220.
Este desplazamiento fijo no tiene que ser resuelto ni puesto en
contexto por la VM Java en el momento del enlace.
El uso, anteriormente descrito, de un
desplazamiento fijo en un fichero ".cod" puede contrastarse con
el uso de desplazamientos en ficheros ".DLL" de
Windows^{MR}. Las referencias en los ficheros ".DLL" de
Windows^{MR} pueden ser en términos de un nombre simbólico o un
número ordinal. El número ordinal se utiliza como índice en una
tabla de desplazamientos. Las realizaciones del presente invento
utilizan los desplazamientos fijos directamente en el fichero
".cod", proporcionando una representación más compacta. Además,
los ficheros ".DLL" de Windows^{MR}. son utilizados para
código compilado, mientras que los ficheros ".cod" son
utilizados para Java interpretado.
El software ejecutable utiliza referencias
simbólicas en el fichero ".cod" sólo generado para referencias
cruzadas entre las clases recibidas en el paso 300 y otras clases.
En el presente ejemplo, la clase E y la clase Ff amplían la clase
java.lang.Object. Por tanto, cada una de las bolsas de constantes
102E, 102F y 222, comprende una única instancia de nombre de clase
"java/lang/Object" de forma que las definiciones de las clases
pueden hacer referencia a esta clase madre. En el fichero Eeff.cod
sólo 220, la bolsa 222 de constantes comprende la cadena
"java/lang/Object", y la referencia a la clase java.lang.Object
en las definiciones de las clases en las "estructuras de
información y códigos de bytes" 224 es una referencia simbólica
(utilizando el índice de la cadena en la bolsa 222 de constantes)
que ha de ser resuelta por la VM Java en el momento del enlace
utilizando información almacenada en la tabla de organización
228.
El software ejecutable puede llevar a cabo
acciones adicionales que no se han ilustrado en la fig. 3, Por
ejemplo, pueden utilizarse otras técnicas de ahorro de espacio para
reducir aún más el tamaño de los ficheros ".cod" sólo.
Los expertos normales en la técnica apreciarán
que cuando se modifican los ficheros de código fuente Ee.java y
Ff.java, es necesario invocar al software ejecutable para generar un
nuevo fichero EeFf.cod o, alternativamente, invocar al software
ejecutable en los ficheros java modificados o ".class" junto
con uno o más ficheros ".java" o ".class" adicionales,
para generar un nuevo fichero EeFfxxx.cod, donde "x" indica las
clases adicionales.
Los expertos normales en la técnica también
apreciarán que si fuese posible generar un único fichero ".cod"
sólo para todos los ficheros ".class" a utilizar en una
aplicación particular, entonces la VM Java no necesitaría resolver
referencias simbólicas entre clases, métodos y campos, ya que tales
referencias aparecerían en el fichero ".cod" como
desplazamientos fijos. Además, tal fichero ".cod" podría ser
significativamente más pequeño que el tamaño total de los ficheros
".class", ya que en el fichero ".cod" se eliminarían las
duplicaciones de información de los ficheros ".class". Tal
fichero ".cod" único será, también, más pequeño que los
múltiples ficheros ".cod" sólo debido a la reducción de la
información duplicada.
Sin embargo, a diferencia de los ficheros
".DLL" de Windows^{MR}. que tienen un tamaño relativamente
ilimitado, en ocasiones existen limitaciones importantes sobre el
tamaño de un único fichero ".cod". Por ejemplo, la fig. 4
muestra un dispositivo 400 que comprende una unidad de computación
402 capaz de ejecutar una VM Java y una memoria 404 directamente
accesible que tiene uno o más ficheros ".cod" 406 almacenados
en ella. Si bien el alcance del presente invento no se limita a
este aspecto, la unidad de computación 402 puede ser un
microprocesador para uso general o cualquier unidad de computación
capaz de ejecutar una VM Java, y el dispositivo 400 puede ser una
cámara digital, una grabadora de vídeo portátil, un teléfono
celular, un asistente digital personal, un ordenador portátil, un
reproductor de MP3, un reproductor de CD, un dispositivo de juegos
portátil, un avisador telefónico, un avisador telefónico
bidireccional, etc. Aunque el alcance del presente invento no está
limitado en este aspecto, la memoria 404 directamente accesible
puede ser una memoria relámpago No-O (NOR) cuyo
esquema físico imponga un límite superior de 64 Kb al tamaño de cada
fichero ".cod" almacenado en ella.
Si hubiese de almacenarse una aplicación
exclusivamente como ficheros ".cod" sólo en un medio de
almacenamiento que impusiese un límite sobre el tamaño de los
ficheros ".cod" individuales, entonces cada fichero ".cod"
comprendería, probablemente, muchas referencias simbólicas a cuenta
de las referencias cruzadas entre clases en esos ficheros
".cod" y clases en otros ficheros ".cod" sólo. Como las
referencias simbólicas requieren más espacio de almacenamiento en
el fichero ".cod" que los desplazamientos fijos, el tamaño
global de la representación ".cod" sólo de la aplicación puede
ser muy grande.
Como alternativa al uso exclusivo de ficheros
".cod" sólo en la representación de una aplicación, pueden
utilizarse ficheros ".cod" hermanos cuando los ficheros
".cod" han de almacenarse en un medio de almacenamiento que
imponga un límite sobre el tamaño de los ficheros ".cod"
individuales. El desarrollador de software puede agrupar juntos
ficheros ".java" o ficheros ".class" en grupos hermanos.
Este agrupamiento puede basarse en el conocimiento del
desarrollador de software sobre lo intrincado de las referencias
cruzadas entre las clases representadas en los ficheros. A partir
de estos ficheros ".java" o ".class" puede generarse un
fichero ".cod" y, si después de haberse combinado parte de los
ficherois ".java" o de los ficheros ".class" en un fichero
".cod", el tamaño de éste superase un limite predeterminado, y
hubiese de combinarse otro fichero ".java" u otro fichero
".class" en el fichero ".cod", entonces se crearían uno o
más ficheros ".cod" hermanos para los restantes ficheros
".java" o ".class" del grupo de hermanos. Las clases no
cruzan los límites de los ficheros ".cod" dividiéndose.
Los expertos normales en la técnica apreciarán
que para un grupo dado de ficheros ".class", el empaquetamiento
de los ficheros ".class" en dos ficheros ".cod" hermanos
constituirá una representación más compacta que el empaquetamiento
de los ficheros ".class" en tres ficheros ".cod" hermanos.
Por tanto, es deseable empaquetar los ficheros ".class" del
grupo en tan pocos ficheros ".cod" como sea posible,
manteniendo al tiempo la restricción de tamaño de los ficheros
".cod" individuales. El problema de cómo dividir un grupo de
clases con referencias cruzadas entre ficheros ".cod" hermanos
es similar al bien conocido "problema de empaquetado" en la
técnica de la ingeniería de software. Pueden utilizarse diversas
técnicas para reducir al mínimo el tamaño global de la
representación ".cod" de una aplicación.
La fig. 2A es una ilustración simplificada de
dos ficheros ".cod" ilustrativos de acuerdo con algunas
realizaciones del presente invento. Un fichero ".cod" hermano
200 recibe el nombre de "AaBb.cod" para indicar que es el
resultado de combinar los ficheros Aa.class y Bb.class, aunque el
alcance del presente invento no se limita a este aspecto.
Similarmente, un fichero ".cod" hermano 210 recibe el nombre de
"CcDd.cod" para indicar que es el resultado de combinar los
ficheros Cc.class y Dd.class.
Cada fichero ".cod" hermano comprende una
lista de sus hermanos. Por ejemplo, una lista 206 de hermanos del
fichero ".cod" AaBb.cod 200 comprende "CcDd" para indicar
que el fichero CcDd.cod 210 es un hermano del fichero AaBb.cod 200.
Similarmente, una lista 216 de hermanos del fichero CcDd.cod 210
comprende "AaBb" para indicar que el fichero AaBb.cod 200 es
hermano del fichero CcDd.cod 210.
El fichero AaBb.cod hermano 200 comprende,
también, una bolsa 202 de constantes, "estructuras de información
y de códigos de bytes" 204 y una o más tablas 208 de
organización. Similarmente, el fichero CcDd.cod hermano 210
comprende, también, una bolsa 212 de constantes, "estructuras de
información y de códigos de bytes" 214 y una o más tablas 218 de
organización. Las tablas de organización 208, 218 pueden incluir
indicaciones de los lugares del fichero ".cod" donde la VM
Java ha de realizar el trabajo de resolución en el momento del
enlace. Las tablas de organización pueden incluir punteros que
señalen al nombre de otro fichero ".cod", si es necesario al
nombre de la clase que contiene el símbolo, si es necesario al
nombre del método o campo dentro de la clase a que se hace
referencia, y a la información sobre tipo de campo o de método.
La fig. 3 es una ilustración, en forma de
diagrama de flujo simplificado, de un método para la generación de
ficheros ".cod" a partir de una colección de ficheros
".java" o de ficheros ".class". El método puede llevarse
a cabo mediante software ejecutable o un ordenado para uso general,
siendo proporcionado el software, por ejemplo, como parte de un kit
de desarrollador de software (SDK).
Se recibe una lista de ficheros ".java" o
de ficheros ".class" (paso 300). Si la entrada consiste en
ficheros ".java", entonces se aplica un compilador Java a los
ficheros ".java" para producir los ficheros ".class"
correspondientes (paso 302). Alternativamente, si bien esto no se
muestra en la fig. 3, podrían recibirse uno o más ficheros
".jar" y, de ellos, podría extraerse la información relacionada
con los ficheros ".class" archivados.
El software ejecutable identifica entradas
comunes en las bolsas de constantes de los ficheros ".class"
(paso 304).
El software ejecutable identifica referencias
cruzadas entre clase, métodos y campos en los ficheros ".class"
(paso 306).
El software ejecutable genera entonces ficheros
".cod" hermanos combinando elementos de los ficheros
".class" (paso 308). En el fichero ".cod" hermano
generado, la bolsa de constantes contiene solamente una única copia
de las entradas comunes identificadas en el paso 304. Por ejemplo,
en la fig. 2A, la bolsa 202 de constantes del fichero AaBb.cod
hermano 200 comprende únicamente una instancia de las cadenas de
caracteres "Bb" y "K" y una instancia del carácter
"I" BaseType. En otro ejemplo, la bolsa 212 de constantes del
fichero CcDd.cod hermano 210 comprende sólo una instancia de las
cadenas de caracteres "Cc" y "P" y una instancia del
carácter "I" BaseType.
El software ejecutable utiliza desplazamientos
fijos en el fichero ".cod" hermano generado para referencias
cruzadas entre clases cuyos ficheros ".cod" se encuentren en el
mismo grupo de hermanos. El software ejecutable emplea referencias
simbólicas en el fichero ".cod" hermano generado para
referencias cruzadas entre clases cuyos ficheros ".cod"
pertenecen a diferentes grupos de hermanos y entre clases que tienen
ficheros ".cod" sólo.
Esto se comprende mejor a través de
ejemplos:
- 1)
- Como se muestra en la fig. 1A, el método Aa.G comprende una referencia al método Bb.K. Por tanto, como se muestra en la fig. 2A, esta referencia aparece en la definición del método Aa.G en "estructuras de información y códigos de bytes" 204 del fichero AaBb.cod hermano 200 como un desplazamiento fijo, HO_{Bb.K}, que especifica la situación de la definición del método Bb.K dentro del fichero AaBb.cod hermano 200. Este desplazamiento fijo no tiene que ser resuelto ni puesto en contexto por la VM Java en el momento del enlace.
- 2)
- Similarmente, como se muestra en la fig. 1B, el método Dd.Q comprende una referencia al método Cc.P. Por tanto, como se muestra en la fig. 2A, esta referencia aparece en la definición del método Dd.Q en "estructuras de información y códigos de bytes" 214 del fichero CcDd.cod hermano 210 como un desplazamiento fijo HO_{Cc.P}, que especifica la situación de la definición del método Cc.P dentro del fichero CcDd.cod hermano 210. Este desplazamiento fijo no tiene que ser resuelto ni puesto en contexto por la VM Java en el momento del enlace.
- 3)
- Como se muestra en la fig. 1A, el método Bb.I comprende una referencia al método Cc.N. Por tanto, como se muestra en la fig. 2A, esta referencia aparece en la definición del método Bb.L en "estructuras de información y códigos de bytes" 204 del fichero AaBb.cod hermano 200 como un desplazamiento fijo HO_{Cc.N}, que especifica la situación de la definición del método Cc.N dentro del fichero CcDd.cod hermano 210. Este desplazamiento fijo ha de ser puesto en contexto por la VM Java en el momento del enlace utilizando información almacenada en la tabla de organización 208. Por ejemplo, la tabla de organización 208 puede comprender un puntero que señale al nombre del fichero CcDd.cod hermano junto con el lugar de la referencia en el método Bb.I al método Cc.N, de forma que la VM Java separa qué fichero ".cod" hermano contiene el método Cc.N en el desplazamiento fijo especificado.
- 4)
- Como se muestra en las figs. 1A y 1B, el método Cc.M comprende una referencia al método Ff.U. El fichero ".cod" para la clase Ff está fuera del grupo de hermanos del fichero CcDd.cod 210. Por tanto, como se muestra en la fig. 2A, esta referencia aparece en la definición del método Cc.M en "estructuras de información y códigos de bytes" 214 del fichero CcDd.cod hermano 210 como referencia simbólica al método Ff.U y su argumento o argumentos. Esta referencia simbólica ha de ser resuelta por la VM Java en el momento del enlace utilizando la información almacenada en la tabla de organización 218. Por ejemplo, la tabla de organización 218 puede comprender un puntero que señale al nombre del fichero ".cod" para la clase en que se define el método Ff.U (por ejemplo, "EeFf.cod"), un puntero que señale al nombre de la clase donde se define el método Ff.U (por ejemplo, "Ff"), un puntero que señale al nombre del método (por ejemplo, "U") y un puntero que señale al nombre de la información que clasifica el método (por ejemplo "I").
\vskip1.000000\baselineskip
Los expertos normales en la técnica apreciarán
que cuando se modifica cualquiera de los ficheros de código fuente
Cc.java y Dd.java, es necesario invocar el software ejecutable para
generar un nuevo fichero CcDd.cod o, alternativamente, invocar el
software ejecutable sobre los ficheros ".java" o ".class"
modificados junto con uno o más de los ficheros ".java" o
".class" adicionales para generar un nuevo fichero CcDdxxx.cod,
donde "x" indica las clases adicionales. Si se ha generado un
nuevo fichero CcDd.cod o un nuevo fichero CcDdxxx.cod, entonces el
desplazamiento fijo HO_{Cc.N} que aparece en el fichero AaBb.cod
200 resuelto ya no describe con precisión la situación de los
códigos de bytes ni de otra información para el método N en el nuevo
fichero CcDd.cod o el nuevo fichero CcDdxxx.cod.
En consecuencia, cuando se actualiza un fichero
".cod", se actualizan simultáneamente todos sus ficheros
".cod" hermanos. Si bien el alcance del presente invento no
está limitado en este aspecto esto se realiza, generalmente,
tomando todo el grupo de ficheros ".class" y regenerando todos
los ficheros ".cod" hermanos de salida. Como algunas de las
clases han cambiado, la división de clases entre los ficheros
".cod" hermanos recién generados puede ser diferente de la de
los ficheros ".cod" hermanos originales.
Si bien se han ilustrado y descrito en esta
memoria ciertas características del invento, a los expertos normales
en la técnica se les ocurrirán ahora muchas modificaciones,
sustituciones, cambios y equivalentes. Por tanto, ha de
comprenderse que las reivindicaciones adjuntas están destinadas a
cubrir todas las citadas modificaciones y cambios que caigan dentro
del alcance de las reivindicaciones anejas.
Claims (15)
1. Un dispositivo (400), que comprende:
una unidad de memoria (404);
una unidad de computación (402) conectada a la
unidad de memoria (404), siendo capaz la unidad de computación
(404) de ejecutar una Máquina Virtual Java; y
uno o más ficheros (406) almacenados en la
unidad de memoria (404), siendo el o los ficheros directamente
interpretables por la Máquina Virtual Java, siendo generados el o
los ficheros (406) a partir de una pluralidad de ficheros de clase
(100A-100F) para reducir el espacio de
almacenamiento, en el que un fichero dado (200) del o de los
ficheros (406), comprende:
- una bolsa (202) de constantes, creada combinando entradas de bolsa de constantes de dos o más (100A, 100B) de la pluralidad de ficheros de clase (100A-100F) sin duplicación de entradas; una estructura (204) de información y de códigos de bytes creada combinando entradas de estructura de información y de códigos de bytes de los dos o más (100A, 100B) de la pluralidad de ficheros de clase (100A-100F); y
- una tabla de organización (208) para proporcionar información a la Máquina Virtual Java para resolver al menos una entrada del fichero dado en el momento del enlace.
\vskip1.000000\baselineskip
2. El dispositivo de la reivindicación 1, en el
que la unidad de memoria (404) incluye software ejecutable y la
unidad de computación (402) está dispuesta para ejecutar el software
ejecutable con el fin de generar el o los ficheros (406) a partir
de la pluralidad de ficheros de clase (100A-100F)
combinando elementos de la pluralidad de ficheros de clase
(100A-100F) sin duplicación de entradas para reducir
el espacio de almacenamiento, en el que el número de ficheros (406)
generados a partir de la pluralidad de ficheros de clase
(100A-100F) es menor que el número de la pluralidad
de ficheros de clase (100A-100F).
3. El dispositivo (400) de la reivindicación 1 o
de la reivindicación 2, en el que la información de la tabla de
organización (208) comprende la situación de los datos necesarios
para resolver una referencia simbólica del fichero dado (200).
4. El dispositivo (400) de una cualquiera de las
reivindicaciones 1 a 3, en el que hay al menos dos ficheros (406),
del número de ficheros (406) generados a partir de la pluralidad de
ficheros de clase (100A-100F), definidos como
ficheros hermanos (200, 210) en un grupo de hermanos comunes,
comprendiendo cada uno de los ficheros hermanos (200, 210) una
lista (206, 216) de hermanos para enumerar otros ficheros hermanos
en el grupo de hermanos comunes, en el que las referencias cruzadas
entre los ficheros hermanos (200, 210) del grupo de hermanos
comunes, se indican utilizando desplazamientos fijos, y las
referencias a ficheros que no son parte del grupo de hermanos
comunes se indican utilizando referencias simbólicas.
5. El dispositivo (400) de la reivindicación 4,
en el que la información de la tabla de organización (208) de un
fichero hermano (200) dado comprende la situación de los datos de un
fichero hermano (210) al que se hace referencia cruzada para poner
en contexto, en el momento del enlace, uno de los desplazamientos
fijos que corresponde al fichero hermano (210) al que se hace
referencia cruzada.
6. El dispositivo de cualquiera de las
reivindicaciones precedentes, en el que para el fichero dado (200),
la estructura (204) de información y de códigos de bytes incluye un
segundo desplazamiento fijo para hacer referencia cruzada a un
método incluido en el fichero dado (200) al que se hizo referencia
previamente de manera simbólica.
7. El dispositivo (400) de la reivindicación 4 o
de la reivindicación 6, en el que al menos uno de los
desplazamientos fijos no tiene que ser resuelto ni puesto en
contexto por la Máquina Virtual Java en el momento del enlace.
8. Un método de generar uno o más ficheros (406)
a partir de una pluralidad de ficheros de clase
(100A-100F), cuyo método comprende:
- identificar ficheros de clase (100A, 100B) con entradas comunes en bolsas de constantes (102A, 102B) de los ficheros de clase (100A, 100B);
- generar una bolsa de constantes (202) para un fichero generado dado (200) combinando entradas de bolsa de constantes de los ficheros de clase (100A, 100B) con entradas comunes sin duplicaciones;
- generar la estructura (204) de información y de códigos de bytes para el fichero generado dado (200) combinando entradas de estructura (204) de información y de códigos de bytes de los ficheros de clase (100A, 100B); y
- generar una tabla de organización (208) para proporcionar información a una Máquina Virtual Java para resolver al menos una entrada del fichero generado dado (200) en el momento del enlace.
9. El método de la reivindicación 8, que
comprende, además, generar el o los ficheros (406) a partir de una
pluralidad de ficheros de clase (100A-100F)
combinando elementos de la pluralidad de ficheros de clase
(100A-100B) sin duplicación de entradas para
reducir el espacio de almacenamiento, en el que el número de
ficheros (406) generados a partir de la pluralidad de ficheros de
clase (100A-100F) es menor que el número de la
pluralidad de ficheros de clase (100A-100F).
10. El método de la reivindicación 8 o de la
reivindicación 9, cuyo método incluye, además, proporcionar la
situación de los datos necesarios para resolver una referencia
simbólica del fichero generado dado (200) como información de la
tabla de organización (208).
11. El método de una cualquiera de las
reivindicaciones 8 a 10, cuyo método incluye, además, identificar
las referencias cruzadas entre los ficheros de clase (100A, 100B) y
definir al menos dos ficheros (406) a partir del número de ficheros
(406) generados a partir de la pluralidad de ficheros de clase
(100A-100F) como ficheros hermanos (200, 210) en un
grupo de hermanos comunes, comprendiendo cada uno de los ficheros
hermanos (200, 210) una lista de hermanos (206, 216) para enumerar
otros ficheros hermanos del grupo de hermanos comunes, indicar las
referencias cruzadas entre los ficheros hermanos (200, 210) del
grupo de hermanos comunes utilizando desplazamientos fijos, e
indicar las referencias a ficheros que no forman parte del grupo de
hermanos comunes utilizando referencias simbólicas.
12. El método de la reivindicación 11, cuyo
método incluye, además, proporcionar la situación de datos de un
fichero hermano (210) para el que existe una referencia cruzada,
como la información de la tabla de organización (208) de un fichero
hermano dado (200) para poner en contexto, en el momento del enlace,
uno de los desplazamientos fijos que corresponde al fichero hermano
(210) al que se hace referencia cruzada.
13. El método de una cualquiera de las
reivindicaciones 8 a 12, cuyo método incluye, además, para el
fichero generado dado (200), proporcionar un segundo desplazamiento
fijo en la estructura (204) de información y códigos de bytes, para
hacer referencia cruzada a un método ahora incluido en el fichero
generado dado (200) al que, previamente, se hizo referencia
simbólicamente.
14. El método de la reivindicación 11 o la
reivindicación 13, cuyo método incluye, además, proporcionar al
menos uno de los desplazamiento fijos de una manera que no necesite
se resuelto ni puesto en contexto por la Máquina Virtual Java en el
momento del enlace.
15. Un producto de programa de ordenador para
generar uno o más ficheros (406) a partir de una pluralidad de
ficheros de clase (100A-100F) combinando elementos
de la pluralidad de ficheros de clase (100A-100F)
sin duplicación de entradas para reducir el espacio de
almacenamiento, comprendiendo el producto de programa de ordenador
un medio legible por ordenador que incorpora medios de código de
programa ejecutables por un procesador de una unidad de computación
(402) para llevar a la práctica el método de cualquiera de las
reivindicaciones 8 a 14.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CA2002/001841 WO2004051468A1 (en) | 2002-11-29 | 2002-11-29 | Method for generating interpretable code for storage in a device having limited storage |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2305316T3 true ES2305316T3 (es) | 2008-11-01 |
Family
ID=32399660
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02782563T Expired - Lifetime ES2305316T3 (es) | 2002-11-29 | 2002-11-29 | Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US7761861B2 (es) |
| EP (2) | EP1909174B1 (es) |
| CN (1) | CN100395703C (es) |
| AT (2) | ATE396452T1 (es) |
| AU (1) | AU2002347146A1 (es) |
| CA (1) | CA2507371C (es) |
| DE (2) | DE60226786D1 (es) |
| ES (1) | ES2305316T3 (es) |
| HK (1) | HK1081294A1 (es) |
| WO (1) | WO2004051468A1 (es) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2305316T3 (es) * | 2002-11-29 | 2008-11-01 | Research In Motion Limited | Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. |
| US20050155024A1 (en) * | 2004-01-14 | 2005-07-14 | Jeffrey Wannamaker | Method of transforming java bytecode into a directly interpretable compressed format |
| WO2006031049A2 (en) * | 2004-09-13 | 2006-03-23 | Lg Electronics Inc. | Method and apparatus for reproducing data from recording medium using local storage |
| EP1789958A4 (en) * | 2004-09-13 | 2009-12-09 | Lg Electronics Inc | METHOD AND DEVICE FOR REPRODUCING DATA RECORDED IN A RECORDING MEDIUM USING A LOCAL STORAGE |
| US20060077817A1 (en) * | 2004-09-13 | 2006-04-13 | Seo Kang S | Method and apparatus for reproducing data from recording medium using local storage |
| KR20060047549A (ko) * | 2004-10-12 | 2006-05-18 | 엘지전자 주식회사 | 로컬 스토리지를 이용한 기록매체 재생방법 및 재생장치 |
| BRPI0517651A (pt) * | 2004-11-08 | 2008-10-14 | Lg Electronics Inc | método e aparelho para reproduzir dados de meio de gravação, método para atualizar dados de armazenagem local, método para formar pacote virtual |
| KR20060063601A (ko) * | 2004-12-03 | 2006-06-12 | 엘지전자 주식회사 | 로컬 스토리지에 데이터를 다운로드/업데이트 하는 방법 및장치 |
| KR20060081323A (ko) * | 2005-01-07 | 2006-07-12 | 엘지전자 주식회사 | 로컬 스토리지를 이용한 기록매체 재생방법 및 재생장치 |
| US8018609B2 (en) | 2005-09-13 | 2011-09-13 | Sony Corporation | Information processing device, information recording medium manufacturing device, information recording medium, methods therefore, and computer program |
| US8813041B2 (en) * | 2008-02-14 | 2014-08-19 | Yahoo! Inc. | Efficient compression of applications |
| US8060476B1 (en) | 2008-07-14 | 2011-11-15 | Quest Software, Inc. | Backup systems and methods for a virtual computing environment |
| US8046550B2 (en) | 2008-07-14 | 2011-10-25 | Quest Software, Inc. | Systems and methods for performing backup operations of virtual machine files |
| US8429649B1 (en) | 2008-09-25 | 2013-04-23 | Quest Software, Inc. | Systems and methods for data management in a virtual computing environment |
| US8996468B1 (en) | 2009-04-17 | 2015-03-31 | Dell Software Inc. | Block status mapping system for reducing virtual machine backup storage |
| US9778946B2 (en) * | 2009-08-07 | 2017-10-03 | Dell Software Inc. | Optimized copy of virtual machine storage files |
| CA2785048C (en) | 2009-12-21 | 2015-06-30 | Kik Interactive Inc. | Systems and methods for accessing and controlling media stored remotely |
| US9569446B1 (en) | 2010-06-08 | 2017-02-14 | Dell Software Inc. | Cataloging system for image-based backup |
| US8898114B1 (en) | 2010-08-27 | 2014-11-25 | Dell Software Inc. | Multitier deduplication systems and methods |
| KR101788061B1 (ko) * | 2011-06-16 | 2017-10-19 | 엘지전자 주식회사 | 가상 머신이 탑재된 디스플레이 장치 및 그 제어 방법 |
| US9042266B2 (en) | 2011-12-21 | 2015-05-26 | Kik Interactive, Inc. | Methods and apparatus for initializing a network connection for an output device |
| US9311375B1 (en) | 2012-02-07 | 2016-04-12 | Dell Software Inc. | Systems and methods for compacting a virtual machine file |
| JP2017126293A (ja) * | 2016-01-15 | 2017-07-20 | キヤノン株式会社 | 情報処理装置及びリソース管理方法 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5966702A (en) * | 1997-10-31 | 1999-10-12 | Sun Microsystems, Inc. | Method and apparatus for pre-processing and packaging class files |
| HUP0101368A3 (en) | 1998-03-23 | 2004-04-28 | Ibm | Java runtime system with modified constant pool |
| US6336122B1 (en) * | 1998-10-15 | 2002-01-01 | International Business Machines Corporation | Object oriented class archive file maker and method |
| GB2343021A (en) * | 1998-10-19 | 2000-04-26 | Ibm | Class loading model for object oriented programming |
| EP1207454A1 (en) * | 2000-11-15 | 2002-05-22 | International Business Machines Corporation | Java run-time system with modified linking identifiers |
| US20020170047A1 (en) * | 2001-02-23 | 2002-11-14 | Brian Swetland | System and method for transforming object code |
| US6732108B2 (en) * | 2001-07-12 | 2004-05-04 | International Business Machines Corporation | Class file archives with reduced data volume |
| ES2305316T3 (es) * | 2002-11-29 | 2008-11-01 | Research In Motion Limited | Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. |
-
2002
- 2002-11-29 ES ES02782563T patent/ES2305316T3/es not_active Expired - Lifetime
- 2002-11-29 WO PCT/CA2002/001841 patent/WO2004051468A1/en active IP Right Grant
- 2002-11-29 AU AU2002347146A patent/AU2002347146A1/en not_active Abandoned
- 2002-11-29 CN CNB028299620A patent/CN100395703C/zh not_active Expired - Lifetime
- 2002-11-29 DE DE60226786T patent/DE60226786D1/de not_active Expired - Lifetime
- 2002-11-29 EP EP07124065A patent/EP1909174B1/en not_active Expired - Lifetime
- 2002-11-29 CA CA2507371A patent/CA2507371C/en not_active Expired - Lifetime
- 2002-11-29 AT AT02782563T patent/ATE396452T1/de not_active IP Right Cessation
- 2002-11-29 EP EP02782563A patent/EP1570347B1/en not_active Expired - Lifetime
- 2002-11-29 AT AT07124065T patent/ATE496330T1/de not_active IP Right Cessation
- 2002-11-29 DE DE60239024T patent/DE60239024D1/de not_active Expired - Lifetime
- 2002-11-29 US US10/536,745 patent/US7761861B2/en active Active
-
2006
- 2006-02-23 HK HK06102409A patent/HK1081294A1/xx not_active IP Right Cessation
-
2010
- 2010-07-19 US US12/838,542 patent/US20100281470A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| EP1909174B1 (en) | 2011-01-19 |
| US20100281470A1 (en) | 2010-11-04 |
| EP1570347B1 (en) | 2008-05-21 |
| CN1695117A (zh) | 2005-11-09 |
| CA2507371A1 (en) | 2004-06-17 |
| US20060020932A1 (en) | 2006-01-26 |
| AU2002347146A1 (en) | 2004-06-23 |
| CN100395703C (zh) | 2008-06-18 |
| DE60226786D1 (de) | 2008-07-03 |
| EP1570347A1 (en) | 2005-09-07 |
| HK1081294A1 (en) | 2006-05-12 |
| EP1909174A1 (en) | 2008-04-09 |
| ATE496330T1 (de) | 2011-02-15 |
| ATE396452T1 (de) | 2008-06-15 |
| US7761861B2 (en) | 2010-07-20 |
| DE60239024D1 (de) | 2011-03-03 |
| WO2004051468A1 (en) | 2004-06-17 |
| CA2507371C (en) | 2012-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2305316T3 (es) | Metodo para generar un codigo interpretable para el almacenamiento en un dispositivo que tiene el espacio de almacenamiento limitado. | |
| ES2680147T3 (es) | Instrucción para cargar datos hasta una frontera de memoria especificada indicada por la instrucción | |
| Hapala et al. | Efficient stack-less bvh traversal for ray tracing | |
| JP4913302B2 (ja) | 言語サブセットの妥当性検査 | |
| CN108932406A (zh) | 虚拟化软件保护方法和装置 | |
| WO2024045382A1 (zh) | 区块链中实现反射机制 | |
| CN110147239A (zh) | 游戏安装包体的多重压缩的方法、设备及存储介质 | |
| Hitchens | Java NIO: Regular Expressions and High-Performance I/O | |
| EP3384406A1 (en) | Combining hashes of data blocks | |
| Serna | CVE-2012-0769, the case of the perfect info leak | |
| CN106445546B (zh) | 一种事件系统的创建方法及装置 | |
| ES2927748T3 (es) | Optimización de huella de memoria de aplicación de tarjeta java | |
| JP2005507103A (ja) | Ｊａｖａヒープを実現するフレームワーク | |
| CN106687978A (zh) | 对栈破坏利用的抑制 | |
| Cardelli | The amber machine | |
| Blyth et al. | ProIO: An event-based I/O stream format for protobuf messages | |
| JP2005521117A (ja) | Ｊａｖａプログラミング環境におけるオブジェクトの表現のための２ティアのクラスタ | |
| CN101770368B (zh) | .net文件中命名空间的压缩方法和装置 | |
| Cooke et al. | Strong cryptography in the Linux kernel | |
| Zheng et al. | Solidity basics | |
| Nita et al. | Jdk 17: New features | |
| CN108614687A (zh) | 一种在c++程序中实现反射的方法、存储介质及计算设备 | |
| CN109492353B (zh) | 应用加固方法、装置、电子设备和存储介质 | |
| CN118035958A (zh) | 基于动态链接库提高源码安全的方法、装置、设备及介质 | |
| CN114741131B (zh) | 动态库导出符号的隐藏方法、装置、设备及存储介质 |