Okas, gracias por la data/explicación!!
Saludos,
Andrés
Andres Valloud escribió:
Buenasssss...
2010/10/21 andres <[email protected]>:
Que hacés Valloud, sabía que ibas a responder :).
Pero como se te ocurre semejante cosa!??!?!... jajajaja!!!
No se si cambió algo en 7.7.1 (estoy con 7.6 por ahora),
Y, mas o menos... basicamente reimplemente MemoryPolicy. Fijate en el
doc de 7.7.1 porque ese archivo tambien esta re-escrito...
Ahora, desde el punto de vista teórico, que debería suceder?
Si los objetos esos se quedan en large space, entonces el compacting
GC (o el data compactor) no los tiene que andar moviendo de aca para
alla.
Digo, así uno
aprende un poco mas sobre el GC. Recuerdo en algunas cosas que implementé
que VW andaba como piña en eso de reusar objetos "muertos" del mismo tamaño
(lease, dejar de referenciar un array de 10 slots y crear uno nuevo de ese
tamaño era mas barato que cachearlo a mano, cosa que me sorpendió bastante).
Puede ser, pero si eso sucede demasiado frecuentemente entonces hay
que contabilizar el costo del scavenge y del IGC para boletear el
objeto viejo.
La pregunta es, eso funca igual en large space? En las pasadas de scavenge
del GC hasta debería ser mas rápido un array solo (ya que sólo queda el
header en eden/survivor) lo que me da un poco de miedo es que se termine
llamando al compacting gc muchas veces por la creación de muchas matrices.
Pero eso va a suceder solo si empezas a usar mucho old space, con lo
que si large space es suficientemente grande, listo.
Dicho sea de paso, la configuracion por defecto de 7.7.1 es muchisimo
mejor que todo lo anterior por dos razones. Primero, no hay mas
colgazos de la VM porque MemoryPolicy no cumple sus responsabilidades
(principalmente: asegurarse de que el scavenge siempre es posible),
tampoco hay memory emergencies que no son tales, y si el IGC aborta
entonces el IGC ahora puede recuperarse (fijate referencias a los
simbolos #aborted y #aborting). Segundo, tu amigo tocayo se gasto
escribiendo tests y otras yerbas, con los cuales el susodicho optimizo
la configuracion por defecto en terminos de velocidad. Por ejemplo,
antes de todo este trabajo los stress tests terminaban en ~2.25 horas
(si terminaban, claro). Ahora terminan en ~20 minutos...
En fin. De esto y otras cosas trata mi propuesta de charla para
Smalltalks 2010. Vamos a ver si me meto en el schedule, las charlas
que hay son grosas. Ya sabes como es esto, no hay hijo del vecino que
valga...
Andres.
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
