¿La máquina virtual de Java de mover objetos en la memoria, y si es así, ¿cómo?

Question

¿La máquina virtual de Java mover objetos en la memoria, y si es así, ¿cómo manejar la actualización de referencias al objeto que se mueve?

Lo pregunto porque estoy explorando una idea de almacenar los objetos de manera distribuida (es decir.a través de múltiples servidores), pero tengo la capacidad para mover objetos entre los servidores por razones de eficiencia.Los objetos deben ser capaces de contener punteros a cada uno de los otros, incluso a los objetos en servidores remotos.Estoy tratando de pensar en la mejor manera de actualizar las referencias para mover objetos.

Mis dos ideas hasta el momento son:

1. Mantener una referencia direccionamiento indirecto en algún lugar que no se mueve por la vida del objeto, que se actualiza si el objeto se mueve.Pero - ¿cómo son estas indirections administrado?
2. Mantenga una lista de inversa de referencias de cada objeto, así que sabemos lo que tiene que ser actualizado en caso de que el objeto se mueve.Por supuesto, esto crea una sobrecarga de rendimiento.

Yo estaría interesado en la retroalimentación sobre estos enfoques, y cualquier sugerencia de enfoques alternativos.

Answer 1

En referencia al comentario anterior sobre la manera de caminar del montón.

GC diferente a hacerlo de diferentes maneras.

Normalmente la copia de los coleccionistas cuando llegue el montón, no andan todos los objetos en el heap.En lugar de caminar los objetos en el heap.La implicación es que si no es accesible desde la "raíz" del objeto, el objeto es en vivo.

Así, en esta etapa se tiene que tocar todos los objetos de todos modos, como copia de la antigua montón para el nuevo montón.Una vez que la copia de los objetos activos se hace, todo lo que queda en el montón de edad son los objetos ya copiado, o la basura.En ese punto de la edad del montón puede ser descartada por completo.

Las dos principales ventajas de este tipo de colectores son los pactos de la pila durante la fase de copia, y que sólo copias de vida de los objetos.Esto es importante para muchos sistemas, ya que con este tipo de colector, la asignación de objetos es muy barato, literalmente, poco más que incrementar un puntero de pila.Cuando GC ocurre, ninguno de los "muertos" se copian los objetos, por lo que no retardar el colector de abajo.También resulta en la dinámica de los sistemas que hay mucho más pequeño y temporal de la basura, que es de larga data de la basura.

También, al caminar por el objeto directo del gráfico, se puede ver cómo la GC puede "saber" acerca de cada objeto, y hacer un seguimiento de ellos para cualquier dirección de ajuste a los efectos de realizar durante la copia.

Este no es el foro para hablar profundamente sobre GC mecánica, ya que no es un problema trivial, pero que los fundamentos de cómo una copia de obras del colector.

Un generacional copia de GC pondrá "edad" de los objetos en diferentes montones, y aquellos que terminan siendo recogidos con menos frecuencia que los "nuevos" montones.La teoría es que la larga duración de los objetos se promovió para las generaciones mayores, y conseguir recopilar menos y menos, mejorando el rendimiento de GC.

Answer 2

(Prácticamente) Cualquier basura que se recoge el sistema tiene que mover los objetos en la memoria para empacar más densamente y evitar problemas de fragmentación.

Lo que estamos viendo es un tema vasto y complejo.Te sugiero leer sobre remota existente estilo de objeto de la API:.NET remoting y yendo más atrás de tecnologías como CORBA

Cualquier solución para el seguimiento de las referencias será complicado por tener que lidiar con todos los modos de falla que existe en los sistemas distribuidos.La JVM no tiene que preocuparse de repente se da cuenta que no puede ver la mitad de su montón debido a un conmutador de red glitched.

Al profundizar en el diseño creo que mucho de esto se vendrá abajo a cómo desea manejar diferentes fracaso de los casos.

Respuesta a los comentarios:

Su pregunta habla sobre el almacenamiento de objetos de manera distribuida, que es exactamente lo que .NET remoting y CORBA dirección.Es cierto que ni la tecnología es compatible con la migración de estos objetos (AFAIK).Pero ambos tratan extensamente con los conceptos de la identidad de los objetos que es una parte crucial de cualquier sistema de objetos distribuidos:¿cómo las diferentes partes del sistema saben que los objetos que están hablando.

No estoy demasiado familiarizado con los detalles de la Java recolector de basura, y estoy seguro de que el Java y .NET recolectores de basura tienen un gran grado de complejidad en ellos para lograr el máximo rendimiento con el mínimo impacto en la aplicación.

Sin embargo, la idea básica para la recolección de basura es:

• La VM se detiene todos los hilos de ejecución de código administrado
• Se realiza un análisis de la accesibilidad de la del conjunto de la conocida 'raíces':las variables estáticas, las variables locales en todos los hilos.Para cada objeto se encuentra de la siguiente manera todas las referencias dentro del objeto.
• Cualquier objeto no identificado por el análisis de la accesibilidad de la basura.
• Los objetos que están todavía vivos pueden ser movidas hacia abajo en la memoria para empacar densamente.Esto significa que todas las referencias a estos objetos también tienen que estar actualizados con la nueva dirección.Mediante el control de cuando recoger la basura puede ocurrir la VM es capaz de garantizar que no existen referencias de objeto 'en el aire' (es decir.se celebra en una máquina de registro) que podrían causar un problema.
• Una vez completado el proceso de VM empieza los hilos de ejecución de nuevo.

Como un refinamiento de este proceso de la VM puede realizar generacional de recolección de basura, donde montones separados se mantienen basado en la "edad" de un objeto.Los objetos de inicio en el montón 0 y, si sobreviven varios GCs, a continuación, migrar a montón 1 y, finalmente, a montón 2 (y así sucesivamente - .NET es compatible con 3 generaciones solo).La ventaja de esto es que la GC puede ejecutar montón 0 colecciones con mucha frecuencia, y no tiene que preocuparse de hacer el trabajo para demostrar la larga duración de los objetos (que ha terminado en el montón 2) todavía están vivos (que seguramente lo son).

Hay otras mejoras para el apoyo simultáneo de recolección de basura, y los detalles en torno a los subprocesos que son en realidad la ejecución de código no administrado cuando el GC está previsto que añadir más complejidad a esta área.

Answer 3

Me interesaría saber más acerca de sus requerimientos.Como otra respuesta sugiere, Terracota puede ser exactamente lo que usted está buscando.

Hay una sutil diferencia entre lo que Terracota ofrece, y lo que usted está pidiendo, así que mi investigación.

La diferencia es que como que a ti respecta, Terracota no proporciona "remoto" las referencias a objetos - en realidad, toda la "distancia" de la noción de RMI, JMS, etc.está totalmente ausente cuando el uso de la Terracota.

Más bien, en Terracota, todos los objetos que residen en grandes virtual montón.Hilos, si en el Nodo 1, Nodo 2 Nodo 3 Nodo 4, etc todos tienen acceso a cualquier objeto en el virtual montón.

No hay una programación especial para aprender, o APIs especiales, objetos en el "virtual" del montón tiene exactamente el mismo comportamiento que los objetos en el local del montón.

En resumen, lo que Terracota proporciona un modelo de programación para varias Jvm que opera exactamente de la misma como el modelo de programación para una sola JVM.Hilos en distintos nodos actúan como hilos de un solo nodo - objeto de las mutaciones, sincronizado, esperar, notificar a todos se comportan exactamente de la misma a través de los nodos como a través de los subprocesos - no hay ninguna diferencia.

Además, a diferencia de cualquier solución a llegado antes, las referencias a objetos se mantiene a través de los nodos - lo que significa que puede utilizar ==.Todo es una forma de mantener la Memoria de Java Modelo de todo el grupo, que es el requisito fundamental para hacer de "regular" Java (por ejemplo,POJOs, sincronizado, esperar/notify) trabajo (nada de esto funciona si no / no se puede preservar la identidad de los objetos a través del cluster).

Así que la pregunta viene de nuevo a usted para perfeccionar sus requiements - żpara qué se necesita la "distancia" de los punteros?

Answer 4

La palabra que buscas es "recolector de compactación".Jvm está permitido el uso de uno, lo que significa que los objetos pueden ser reubicados.Consulte a su JVM manual para averiguar si el tuyo la tiene, y a ver si hay alguna de las opciones de línea de comandos que le afectan.

El conceptualmente la forma más sencilla de explicar la compactación es asumir que el recolector de basura se congela todos los hilos, se traslada el objeto, las búsquedas montón y de la pila de todas las referencias a ese objeto, y las actualiza con la nueva dirección.En realidad es más complejo que eso, ya que por motivos de rendimiento no desea realizar un barrido completo con hilos estancado, por lo que un incremento en el recolector de basura de hacer el trabajo en la preparación para la compactación, siempre que sea posible.

Si usted está interesado en referencias indirectas, usted podría comenzar por la investigación de débil y blando referencias en Java, y también el control remoto referencias utilizadas por los diversos sistemas RPC.

Answer 5

suena como que usted está buscando para una caché distribuida, algo así como la terracota o de java de oracle objece caché (anteriormente tangersol).

Answer 6

Si usted está dispuesto a ir más profundo, puedes echar un vistazo a JBoss Cache arquitectura docs y tomar un poco de su código fuente como referencia.

Esto no es exactamente lo que usted describe, pero funciona muy similares.

Aquí está el enlace.

http://www.jboss.org/jbosscache/

Espero que esto ayude.