2010-09-26 15 views
9

Los recolectores de basura en movimiento, como los recolectores generacionales, incurren en un código generado adicional para almacenar y volver a cargar referencias en los puntos seguros de GC. ¿Alguien ha cuantificado el costo de rendimiento de esta sobrecarga en comparación con un colector que no se mueve?Costo de un recolector de basura en movimiento

Pregunto porque estoy interesado en diseñar un colector que pueda reciclar valores efímeros de manera eficiente sin tener que moverlos.

+0

también intente en http://cstheory.stackexchange.com/ – oluies

+1

¿Están interesados ​​en las mediciones de rendimiento allí? –

Respuesta

6

La compensación de movimiento vs. no movimiento es compleja. No conozco ningún estudio en particular sobre el aspecto que mencionas; de hecho, no estoy seguro de entenderlo por completo: un GC preciso siempre necesita saber dónde están todos los indicadores, así que quizás estés hablando de conservador GC no móvil? Conservative GC en mi opinión es una mala elección si tienes suficiente control sobre la ruta de compilación para poder hacer un GC preciso.

Los otros aspectos que afectan al rendimiento de mover vs GC no se mueve son: Velocidad de

  • asignación. GC no móvil podría tener que asignarse desde una lista libre, mientras que el GC compulsivo puede usar la asignación de bump-puntero. Los esquemas híbridos como Immix intentan lograr una mejor compensación entre los dos.

  • Comportamiento de la localidad y el caché. Hay muchos estudios sobre esto para GC tanto móvil como no móvil; ver el GC Bibliography. En general, la compactación es buena para la memoria caché, aunque la copia de GC suele ser de amplitud, lo que es una mala elección (los patrones de acceso tienden a ser primero en profundidad), por lo que hay una gran cantidad de investigación en esta área tratando de reorganizar objetos para que coincidan con el patrón de acceso .

Mi opinión personal es que para apoyar la asignación muy rápido que necesita un vivero-L2 tamaño con la colección de la copia y bump-puntero de asignación. Si hace algo más, la asignación se vuelve más costosa, lo que distorsiona muchas cosas: la optimización para reducir las asignaciones se vuelve más importante, por lo que termina gastando esfuerzos allí y haciendo las cosas más complejas. Prefiero hacer la asignación realmente muy barata y luego no preocuparme por eso.

+0

Veo, esa fue mi impresión también. Estaba hablando de GC no móviles precisos (no conservadores) como el de HLVM en este momento. Sabe exactamente dónde están todas las raíces globales y los punteros en el montón pero, como nunca se mueven, puede mantenerlos en registros a través de puntos seguros y nunca tiene que iterar sobre ellos actualizándolos después de una colección en movimiento. Hmm, debe haber alguna manera de obtener lo mejor de ambos mundos ... tal vez necesites todas las referencias indirectas a objetos en movimiento a través de un LUT global ... –

+0

@JonHarrop: Desde que comencé a programar el Macintosh "clásico", Me impresionó el poder de los mangos dobles indirectos. Pensaría que con un poco de soporte de hardware, un modelo así podría ofrecer algunas buenas ventajas (por ejemplo, poder tener un recolector de basura eficiente que no bloquearía ningún hilo a menos que intentara escribir en un objeto mientras se movía, en En ese caso, ese hilo solo se bloquearía hasta que se completara ese movimiento en particular). También pensé que los objetos grandes deberían alinearse en los límites de 4K y usar la reubicación virtual en lugar de la física. – supercat

Cuestiones relacionadas