2009-03-25 9 views
7

Estoy tratando de implementar una colección de objetos similar a un caché. El objetivo es tener acceso rápido a estos objetos a través de la localidad en memoria, ya que probablemente leeré varios objetos a la vez. Actualmente solo almaceno objetos en un objeto de colecciones java como vector o deque. Pero no creo que esto haga uso de la memoria contigua.tratando de almacenar objetos Java en la memoria contigua

Sé que esto se puede hacer en C, pero ¿se puede hacer en Java? Estos objetos pueden ser de diferentes longitudes (ya que pueden contener cadenas). ¿Hay alguna manera de asignar memoria contigua a través de Java? ¿Hay un objeto de colecciones Java que lo haga?

Háganme saber.

Gracias, JBU

+2

¿Qué le permitirá almacenarlo en la memoria contigua? –

+2

búsquedas más rápidas, menos fallas de página – jbu

+0

¿Esto se ha demostrado a través del perfilado? –

Respuesta

14

No se puede forzar. Si asigna todos los objetos en sucesión rápida, son probablemente contiguos, pero si los está almacenando en una colección, no hay garantía de que la recopilación sea local a los valores reales. (La colección tendrá referencias a los objetos, en lugar de contener los objetos en sí).

Además, la compactación del GC moverá valores en la memoria.

¿De verdad ha perfilado su aplicación y encontró que esto es un cuello de botella? En la mayoría de los casos, espero que otras optimizaciones puedan ayudarlo de una manera más confiable.

+1

sí, perfórela primero, para que no pierda el tiempo arreglando lo que no está roto. –

+0

Lo secundaré.Si esto realmente es un cuello de botella para su aplicación, probablemente lo esté escribiendo en el idioma equivocado. –

4

¿Has escrito este código aún en Java? Y si es así, ¿lo ha perfilado? Yo diría que probablemente no tenga que preocuparse por los objetos que se encuentran en la memoria contigua: la JVM es mejor en la administración de memoria que en un entorno recolectado.

Si realmente está preocupado por el rendimiento, tal vez Java no es la herramienta adecuada para el trabajo, pero mi instinto es decirle que está preocupado por la optimización demasiado pronto, y que una versión de Java de su código, trabajando con memoria no contigua, probablemente se adapte a sus necesidades.

+0

tiene razón, la optimización debe venir después de la implementación y el perfil correctos. Solo estaba tratando de pensar en el futuro. Aunque todavía sirve como una lección en la teoría de Java. – jbu

8

No, no puede garantizar esta localidad de referencia. Al asignar una matriz de bytes o utilizar un búfer de bytes asignado de los paquetes nio, puede obtener un trozo de memoria contigua, desde la que puede decodificar los datos que desee (deserializando efectivamente los objetos de interés de este trozo de memoria). Sin embargo, si accede repetidamente a los mismos objetos, la sobrecarga de deserialización probablemente anulará el propósito.

+0

por lo que parece que la matriz de primitivas se puede almacenar en la memoria contigua pero no en una matriz de objetos. ¿Es eso correcto? – jbu

+1

Las matrices son contiguas, pero si tiene una matriz como Foo [] eso significa una matriz de referencias Foo *, no Foo * objects *. Java no tiene tipos de valores definidos por el usuario. –

-1

Sugiero usar un HashMap (sin rosca) o Hashtable (roscado) para su caché. Ambos almacenan un objeto en una matriz en el sol jvm. Como todos los objetos en java se pasan por referencia, esto se debe representar como una matriz de punteros en c. Mi apuesta es que estás realizando una optimización prematura.

Si es absolutamente necesario tener esto, usted tiene dos opciones:

1) el uso de JNI y escribirla en c. 2) Obtenga un búfer de bytes GRANDES y use ObjectOutputStream para escribir objetos en él. Es probable que sea MUY LENTO en comparación con el uso de una tabla hash.

+1

Los objetos no se pasan por referencias. Las referencias (y todos los otros argumentos también) se pasan por valor. Hay una gran diferencia, y vale la pena ser preciso.

Cuestiones relacionadas