Otro thread de GC

> ¿Las cuestiones del Marking son aprovechando algún tipo de localidad
> de paginas, o algo así? Es impresionante el aumento de la velocidad

Si sabes que en cierta region de memoria solo hay objetos que nunca
son basura, entonces basicamente no hay que gastarse en ir a ver si
estan marcados o no.  Ejemplo tipico: clases en perm space.  Por lo
menos un ahorro por objeto!  Lo mismo con objetos como nil, que casi
siempre en VW van a terminar en perm space.

Despues otras cuestiones como no poner objetos sin punteros en la cola
de marcado, o no marcar cosas varias veces, o no marcar objetos sin
punteros para que cuando haya overflow se los escanee de nuevo, etc.

Muchas de estas optimizaciones ya las habia hecho para el IGC, ahora
estan en el GC tambien.

> Lo de crear objetos en un espacio determinado esta piola para los
> test. Quizás después te cuente algunos problemas que tuvimos/tenemos,
> que no se si te sirva para algo.

Dale, conta!

Andres.

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

> Si sabes que en cierta region de memoria solo hay objetos que nunca
> son basura, entonces basicamente no hay que gastarse en ir a ver si
> estan marcados o no.  Ejemplo tipico: clases en perm space.  Por lo
> menos un ahorro por objeto!  Lo mismo con objetos como nil, que casi
> siempre en VW van a terminar en perm space.

Para ser mas conciso... imaginate, un cache line read en una direccion
mas o menos cualquiera para ir a mirar un bit que ya sabias que era
1...

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

2011/6/6 Andres Valloud <[hidden email]>:
>> ¿Las cuestiones del Marking son aprovechando algún tipo de localidad
>> de paginas, o algo así? Es impresionante el aumento de la velocidad
>
> Si sabes que en cierta region de memoria solo hay objetos que nunca
> son basura, entonces basicamente no hay que gastarse en ir a ver si
> estan marcados o no.  Ejemplo tipico: clases en perm space.  Por lo
> menos un ahorro por objeto!  Lo mismo con objetos como nil, que casi
> siempre en VW van a terminar en perm space.
Esto esta bueno. Te hago una pregunta: ¿tendrías que reocrrer primero
las clases del perm, no? Justamente como estos objetos nunca son
basura, las referencias por estos contenidos tampoco -je, volvimos a
la clausura transitiva-. Es interesante, por que entre esto, y el
rememberedSet se trata de llevar el scavenger a que trabaje con
subgraphs. (un poco, de cierta manera, y visto con cariño). No pude
pensar mucho sobre eso, pero creo que trabajar sobre subgraph
disjuntos puede ser interesante para multithreading scavenging


--
" To be is to do " ( Socrates )
" To be or not to be " ( Shakespeare )
" To do is to be " ( Sartre )
" Do be do be do " ( Sinatra )

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

> Esto esta bueno. Te hago una pregunta: ¿tendrías que reocrrer primero
> las clases del perm, no?

En realidad no.  Como dije en la charla de Smalltalks 2010, de perm a
old esta el old remembered table, asi que solo tenes que recorrer el
oldRT y marcar todo lo que no este en perm (y meterlo en la cola del
mark para escanear).  Por eso, una vez visto el oldRT, antes de
dereferenciar un puntero te fijas si esta en perm.  Si es asi, ni lo
miras y seguis viaje.

Del mismo modo, de perm y old a new esta el rt comun (esto sirve para
el scavenge de new space).

> Justamente como estos objetos nunca son
> basura, las referencias por estos contenidos tampoco -je, volvimos a
> la clausura transitiva-.

Exactamente.  Y por ejemplo, si tenes un ephemeron y el key esta en
perm, ya sabes que ese ephemeron no se puede finalizar en este GC
(porque si el key esta en perm entonces asumis que no es basura ==
asumis que esta marcado).

> Es interesante, por que entre esto, y el
> rememberedSet se trata de llevar el scavenger a que trabaje con
> subgraphs. (un poco, de cierta manera, y visto con cariño).

Si...

> No pude
> pensar mucho sobre eso, pero creo que trabajar sobre subgraph
> disjuntos puede ser interesante para multithreading scavenging

Puede ser, pero no me queda claro como se puede hacer para irse
acordando que grafos relativamente grandes estan disjuntos.  Si la
memoria de objetos estuviera particionada, entonces por definicion los
grafos estarian separados y entonces si podrias tener multithreaded
GC, y multithreaded codigo nativo, etc.  Un tema dificil, aparte de la
"trivialidad" de hacer un JIT multithreaded, es como hacer que la
imagen entienda todo ese quilombo.  Por ejemplo, se asume todo el
tiempo que un proceso de prioridad X > Y siempre interrumpe a un
proceso de prioridad Y.  Pero, en una VM multithreaded, que pasa si el
proceso de prioridad Y se va a una primitiva que tarda mil años (pero
que progresa y usa memoria etc por ejemplo LargeInteger>>*), y
entonces salta el proceso X.  Que se hace con la primitiva del proceso
de prioridad Y?  Y si no se puede deshacer el progreso ya realizado
por la primitiva?  Es un bardo.

Andres.

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org