Hola gente!
Hoy, mientras leia el Smalltalk-80 the language and its implementation en el desayuno, se me ocurrio pensar: Como hace un Smalltalk para hacer un become: si hay multithreading (es decir, si hay varios threads ejecutandose)?
Pues me imagino que mientras se hace a become: b alguno otro thread puede estar operando con b o con a (por ejemplo, tomo la clase de b ANTES del become, lookup de un metodo, y luego lo aplica a b DESPUES del become)
(o, si la implementacion interna es un object table (una celda por objeto), accedo a la celda de b, tomo algo de la celda (por ejemplo, el puntero a la clase), y mientras me cambian la celda, donde esta el puntero al resto de los datos)
(tambien me puedo imaginar una implementacion por object table (una celda por objeto), donde haya menos cosas que confundan a un become: a medio hacer; por ejemplo, que tenga apenas el puntero al contenido del objeto, y ahi en el contenido este el puntero a la clase).
Bueno, no se si me explico .. Tienen idea? Me imagino respuestas: - No, los Smalltalks X, Y, Z solo manejan un thread, y todo lo demas son "green threads"
- En el Smalltalk W, hacemos become: multithreading, pero sin controlar nada (sin poner locks, semaforos o lo que sea) - En el Smalltalk T, tenemos multithread y hacemos un lindo bolonki para hacer que el become: sea thread-safe
- En el Smalltalk S, tenemos multithread y la implementacion interna (object table con celda atomica, con pocos datos; o puntero directo, o lo que sea) es tal, que el become termina siendo thread-safe por naturaleza
Cual es? Nos leemos! Angel "Java" Lopez @ajlopez To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
El día 19 de noviembre de 2012 10:39, Angel Java Lopez
<[hidden email]> escribió: > Me imagino respuestas: > > - No, los Smalltalks X, Y, Z solo manejan un thread, y todo lo demas son > "green threads" > - En el Smalltalk W, hacemos become: multithreading, pero sin controlar nada > (sin poner locks, semaforos o lo que sea) > - En el Smalltalk T, tenemos multithread y hacemos un lindo bolonki para > hacer que el become: sea thread-safe > - En el Smalltalk S, tenemos multithread y la implementacion interna (object > table con celda atomica, con pocos datos; o puntero directo, o lo que sea) > es tal, que el become termina siendo thread-safe por naturaleza > > Cual es? Habria que ver cual es el soporte de GemStone con respecto al #become:, AFAIR su uso era bastante limitado. En el caso de Dolphin tiene un object-table, y el #become: lo unico que hace es intercambiar pointers de los cuerpos de los objetos receptor y argumento, es una operación muy rápida. El #oneWayBecome: tiene que recorrer toda la object table. Igual cuando haces become, y tu objeto estaba en una hashed collection, y se "convirtió" en un objeto que devuelve un hash distinto empiezan los quilombos :D Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D A los smalltalkers no nos gusta el quilombo :) Saludos! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Preguntale a Vallould :) Saludos To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Angel Java Lopez
dependiendo de la implementacion del manejo de memoria, el become puede ser simple o complejo... en el caso de usar forward references (implementacion que usa la mayoria) el become es similar el paso del mark de un gc de mark & sweep, o sea, hay que buscar todas las referencias, y por lo tanto su implementacion sera similar a la del gc y en la mayoria de los smalltalks el gc hace un "stop the world"... tene en cuenta que la mayoria de las implementaciones usan green threads.
En el caso de gemstone que usa object table, el become es un simple swap de referencias y resuelven el conflico de concurrecia simplemente por utilizar memoria transaccional, no tienen que hacer nada raro mas alla de lo que ya proveen para trabajar concurrentemente (segun lo que entiendo, puedo estar equivocado)
Saludos Hernan. 2012/11/19 Angel Java Lopez <[hidden email]> Hola gente! Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125
Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina 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 hay cosas como generaciones, entonces become: aun con object table
es un quilombo porque te pueden quedar referencias cruzadas que no se permiten en tu implementacion. A veces puede que no te quede otra que copiar object bodies. Y ademas actualizar los remember tables de turno, hacer algo especial si esta andando el IGC, y todas esas cosas. 2012/11/20 Hernan Wilkinson <[hidden email]>: > dependiendo de la implementacion del manejo de memoria, el become puede ser > simple o complejo... en el caso de usar forward references (implementacion > que usa la mayoria) el become es similar el paso del mark de un gc de mark & > sweep, o sea, hay que buscar todas las referencias, y por lo tanto su > implementacion sera similar a la del gc y en la mayoria de los smalltalks el > gc hace un "stop the world"... tene en cuenta que la mayoria de las > implementaciones usan green threads. > > En el caso de gemstone que usa object table, el become es un simple swap de > referencias y resuelven el conflico de concurrecia simplemente por utilizar > memoria transaccional, no tienen que hacer nada raro mas alla de lo que ya > proveen para trabajar concurrentemente (segun lo que entiendo, puedo estar > equivocado) > > Saludos > Hernan. > > > 2012/11/19 Angel Java Lopez <[hidden email]> >> >> Hola gente! >> >> Hoy, mientras leia el Smalltalk-80 the language and its implementation en >> el desayuno, se me ocurrio pensar: >> >> Como hace un Smalltalk para hacer un become: si hay multithreading (es >> decir, si hay varios threads ejecutandose)? >> Pues me imagino que mientras se hace >> >> a become: b >> >> alguno otro thread puede estar operando con b o con a (por ejemplo, tomo >> la clase de b ANTES del become, lookup de un metodo, y luego lo aplica a b >> DESPUES del become) >> (o, si la implementacion interna es un object table (una celda por >> objeto), accedo a la celda de b, tomo algo de la celda (por ejemplo, el >> puntero a la clase), y mientras me cambian la celda, donde esta el puntero >> al resto de los datos) >> (tambien me puedo imaginar una implementacion por object table (una celda >> por objeto), donde haya menos cosas que confundan a un become: a medio >> hacer; por ejemplo, que tenga apenas el puntero al contenido del objeto, y >> ahi en el contenido este el puntero a la clase). >> >> Bueno, no se si me explico .. >> >> Tienen idea? >> >> Me imagino respuestas: >> >> - No, los Smalltalks X, Y, Z solo manejan un thread, y todo lo demas son >> "green threads" >> - En el Smalltalk W, hacemos become: multithreading, pero sin controlar >> nada (sin poner locks, semaforos o lo que sea) >> - En el Smalltalk T, tenemos multithread y hacemos un lindo bolonki para >> hacer que el become: sea thread-safe >> - En el Smalltalk S, tenemos multithread y la implementacion interna >> (object table con celda atomica, con pocos datos; o puntero directo, o lo >> que sea) es tal, que el become termina siendo thread-safe por naturaleza >> >> Cual es? >> >> Nos leemos! >> >> Angel "Java" Lopez >> @ajlopez >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [hidden email] >> >> http://www.clubSmalltalk.org > > > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- 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 tienes memoria transaccional y las transacciones son versionadas (optimistic locking), entonces se mantiene la coherencia transaccional de cada una de las transacciones aunque ejecuten en paralelo.
2012/11/20 Andres Valloud <[hidden email]> Si hay cosas como generaciones, entonces become: aun con object table Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Esteban A. Maringolo
Si hay forwardeo de punteros en el object table, entonces si
oneWayBecome: se puede implementar mirando el object table. Si no, hay que mirar todos los object bodies. Ahora, viste que cuando haces un oneWayBecome: de una clase a otra, las instancias del receptor no se transforman en instancias del argumento?... o que por lo menos no deberian transformarse?... que detalle, no?... 2012/11/19 Esteban A. Maringolo <[hidden email]>: > El día 19 de noviembre de 2012 10:39, Angel Java Lopez > <[hidden email]> escribió: >> Me imagino respuestas: >> >> - No, los Smalltalks X, Y, Z solo manejan un thread, y todo lo demas son >> "green threads" >> - En el Smalltalk W, hacemos become: multithreading, pero sin controlar nada >> (sin poner locks, semaforos o lo que sea) >> - En el Smalltalk T, tenemos multithread y hacemos un lindo bolonki para >> hacer que el become: sea thread-safe >> - En el Smalltalk S, tenemos multithread y la implementacion interna (object >> table con celda atomica, con pocos datos; o puntero directo, o lo que sea) >> es tal, que el become termina siendo thread-safe por naturaleza >> >> Cual es? > > Habria que ver cual es el soporte de GemStone con respecto al > #become:, AFAIR su uso era bastante limitado. > > En el caso de Dolphin tiene un object-table, y el #become: lo unico > que hace es intercambiar pointers de los cuerpos de los objetos > receptor y argumento, es una operación muy rápida. El #oneWayBecome: > tiene que recorrer toda la object table. > > Igual cuando haces become, y tu objeto estaba en una hashed > collection, y se "convirtió" en un objeto que devuelve un hash > distinto empiezan los quilombos :D > > Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D > A los smalltalkers no nos gusta el quilombo :) > > Saludos! > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Sebastian Calvo
Que?
2012/11/19 GallegO <[hidden email]>: > >> >> Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete >> cargo :D >> A los smalltalkers no nos gusta el quilombo :) >> > > Preguntale a Vallould :) > > Saludos > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to > [hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Guillermo Schwarz
El tema con la memoria transaccional es el rendimiento. Básicamente, si
tenemos un código basado en locks para proteger datos compartidos, cuando un procesador toma un lock puede modificar los datos a su antojo. En cambio, si lo hacemos mediante una transacción, es necesario guardar las dos versiones (la vieja y la nueva) por si eso falla. Esto hace que las operaciones a memoria se dupliquen, el tamaño necesario para bufferes de escritura (o undo-logs) se dispare en caso de tener transacciones grandes. De esta forma, si tenemos un código con poca "contención" en el acceso a los datos compartidos (y generalmente está optimizado para que así sea, ya que eso es el cuello de botella en programas paralelos) entonces la versión basada en locks proporcionará un rendimiento mejor. Además, tendremos numerosas llamadas al runtime que se encarga de proporcionar esas características (atomicidad, consistencia...) que enlentecen la ejecución. También hay propuestas hardware o híbridas, de Universidades o de fabricantes (como el sistema híbrido de Intel o el Rock de Sun, que también es híbrido). En estas propuestas, se pasa a algún mecanismo HW las tareas de mantenimiento de versiones, detección de colisiones, inicialización y commit de las transacciones, etc. A mi parecer, uno de los principales problemas, que creo que no se comenta en el artículo, es la falta de aplicaciones "serias" que utilicen memoria transaccional. Sí, tenemos micro-benchmarks (todos los artículos implementan de alguna manera red-black trees y linked lists), tenemos kernels de aplicaciones, pero en cualquier caso son aplicaciones generadas a base de "cambiar locks por transacciones". Una de las ventajas de las transacciones es que se pueden componer, es decir, se puede anidar una transacción dentro de otra sin ningún problema, y en cualquier orden. Esto no se puede hacer con locks, ya que puede llevar a deadlock (si dos threads pretenden tomar dos locks dados en orden inverso), lo que obliga al programador a ser consciente de todos los posibles caminos que puedan tomar los threads en el sistema. De esta forma, el diseño de una aplicación paralelo (el diseño completo, desde las estructuras de datos hasta el código de cada función) sería completamente diferente con memoria transaccional, y la mayoría de las aplicaciones de prueba que tenemos, simplemente, no son válidas. Pero ese no es el único problema, y es que la programación paralela no se simplifica tanto como se pudiera pensar en un principio. Las tareas de sincronización entre threads siguen siendo complejas, y existen estructuras de datos que son inherentemente muy paralelas utilizando locks, pero muy poco utilizando transacciones (como el acceso a un RB-tree, con congestión en la raíz). En muchos casos, un problema se soluciona de manera más sencilla utilizando un lock que una transacción (como la gestión de una cola de trabajo, a la que acceden los threads para determinar qué tienen que hacer) pero ambos sistemas, locks y transacciones, son incompatibles. De esta forma, difícilmente se pueden conseguir aplicaciones de prueba realmente válidas. Sin aplicaciones válidas para verificar la hipotética ventaja (de rendimiento, simplicidad de programación, etc) los fabricantes del hardware no se van a tirar a la piscina, y los programadores no tienen una herramienta válida (que no tarde días en ejecutar un micro-benchmark por simulación) para evaluar su sistema. Estamos en la pescadilla que se muerde la cola. Hay mucha gente y muchas empresas interesadas en que esto salga adelante (Intel, Sun, Microsoft, IBM, y muchos grupos de investigación por todo el mundo) pero la situación real no está clara. Ya veremos dentro de 15 años... Ahhh, ahora se lo que se siente ser un troll! Saludos! Andrés (el otro) Texto original: http://barrapunto.com/comments.pl?sid=79131&op=&threshold=1&commentsort=0&mode=thread&cid=1103532 On mar, 2012-11-20 at 16:57 -0300, Guillermo Schwarz wrote: > Si tienes memoria transaccional y las transacciones son versionadas > (optimistic locking), entonces se mantiene la coherencia transaccional > de cada una de las transacciones aunque ejecuten en paralelo. > > > > > 2012/11/20 Andres Valloud <[hidden email]> > Si hay cosas como generaciones, entonces become: aun con > object table > es un quilombo porque te pueden quedar referencias cruzadas > que no se > permiten en tu implementacion. A veces puede que no te quede > otra que > copiar object bodies. Y ademas actualizar los remember tables > de > turno, hacer algo especial si esta andando el IGC, y todas > esas cosas. > > 2012/11/20 Hernan Wilkinson <[hidden email]>: > > dependiendo de la implementacion del manejo de memoria, el > become puede ser > > simple o complejo... en el caso de usar forward references > (implementacion > > que usa la mayoria) el become es similar el paso del mark de > un gc de mark & > > sweep, o sea, hay que buscar todas las referencias, y por lo > tanto su > > implementacion sera similar a la del gc y en la mayoria de > los smalltalks el > > gc hace un "stop the world"... tene en cuenta que la mayoria > de las > > implementaciones usan green threads. > > > > En el caso de gemstone que usa object table, el become es un > simple swap de > > referencias y resuelven el conflico de concurrecia > simplemente por utilizar > > memoria transaccional, no tienen que hacer nada raro mas > alla de lo que ya > > proveen para trabajar concurrentemente (segun lo que > entiendo, puedo estar > > equivocado) > > > > Saludos > > Hernan. > > > > > > 2012/11/19 Angel Java Lopez <[hidden email]> > >> > >> Hola gente! > >> > >> Hoy, mientras leia el Smalltalk-80 the language and its > implementation en > >> el desayuno, se me ocurrio pensar: > >> > >> Como hace un Smalltalk para hacer un become: si hay > multithreading (es > >> decir, si hay varios threads ejecutandose)? > >> Pues me imagino que mientras se hace > >> > >> a become: b > >> > >> alguno otro thread puede estar operando con b o con a (por > ejemplo, tomo > >> la clase de b ANTES del become, lookup de un metodo, y > luego lo aplica a b > >> DESPUES del become) > >> (o, si la implementacion interna es un object table (una > celda por > >> objeto), accedo a la celda de b, tomo algo de la celda (por > ejemplo, el > >> puntero a la clase), y mientras me cambian la celda, donde > esta el puntero > >> al resto de los datos) > >> (tambien me puedo imaginar una implementacion por object > table (una celda > >> por objeto), donde haya menos cosas que confundan a un > become: a medio > >> hacer; por ejemplo, que tenga apenas el puntero al > contenido del objeto, y > >> ahi en el contenido este el puntero a la clase). > >> > >> Bueno, no se si me explico .. > >> > >> Tienen idea? > >> > >> Me imagino respuestas: > >> > >> - No, los Smalltalks X, Y, Z solo manejan un thread, y todo > lo demas son > >> "green threads" > >> - En el Smalltalk W, hacemos become: multithreading, pero > sin controlar > >> nada (sin poner locks, semaforos o lo que sea) > >> - En el Smalltalk T, tenemos multithread y hacemos un lindo > bolonki para > >> hacer que el become: sea thread-safe > >> - En el Smalltalk S, tenemos multithread y la > implementacion interna > >> (object table con celda atomica, con pocos datos; o puntero > directo, o lo > >> que sea) es tal, que el become termina siendo thread-safe > por naturaleza > >> > >> Cual es? > >> > >> Nos leemos! > >> > >> Angel "Java" Lopez > >> @ajlopez > >> > >> -- > >> To post to this group, send email to > [hidden email] > >> To unsubscribe from this group, send email to > >> [hidden email] > >> > >> http://www.clubSmalltalk.org > > > > > > > > > > -- > > Hernán Wilkinson > > Agile Software Development, Teaching & Coaching > > Phone: +54 - 011 - 6091 - 3125 > > Mobile: +54 - 911 - 4470 - 7207 > > email: [hidden email] > > site: http://www.10Pines.com > > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > > -- > > To post to this group, send email to > [hidden email] > > To unsubscribe from this group, send email to > > [hidden email] > > > > http://www.clubSmalltalk.org > > -- > To post to this group, send email to > [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org > > > > > > -- > Saludos cordiales, > > Guillermo Schwarz > Sun Certified Enterprise Architect > > > -- > To post to this group, send email to [hidden email] > To unsubscribe from this group, send email to clubSmalltalk > +[hidden email] > > http://www.clubSmalltalk.org -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Hola gente!
Muy interesante las respuestas! Por ejemplo, recien me entero por @hernanwilkinson que muchas implementaciones son "green threads". cuales son? Imagino Squeak y Pharo, es asi? otra mas?
Interesante tambien lo de las transacciones, no esperaba llegar a ese tema... pero me interesa ;-)
Bueno, en mi implementacion de una VM open source, presentada en Smalltalks 2010, tome la decision de que hay objetos transaccionales. Es decir, el programador decide QUE objetos son transaccionales. Y a esos objetos, se los decora, para que los set y los get de sus valores internos, tengan el codigo para controlar si estan en una transaccion o no. Algo escrito en:
Como tambien tengo elementos de objetos remotos
mi idea es llegar a: - Exponer para afuera, objetos que decido explicitamente que son transaccionales - El cliente remoto, interactua con esos objetos - Solo en ese caso de uso los set/get de ESOS objetos se justifica el tema de STM (Software Transactional Memory) Los demas objetos quedan pipi cucu.
Tiembla GemStone! ;-) ;-) Mis enlaces sobre STM: http://delicious.com/ajlopez/stm Tendria que recordar casos de uso de Clojure http://delicious.com/ajlopez/stm+clojure
Nos leemos! Angel "Java" Lopez @ajlopez 2012/11/20 Andrés Fortier <[hidden email]> El tema con la memoria transaccional es el rendimiento. Básicamente, si To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Andres Fortier-2
+1
En memoria RAM típicamente se usa algún tipo de non-blocking synchronization: 1. wait-free-concurrency 2. lock-free-concurrency. Típicamente se implementan usando un número de versión y primitivas a nivel de CPU conocidas como CAS y LL/SC. Casi todas las CPUs impĺementan alguna de las 2. Pero eso de tener transacciones es aún mejor. Es más grande y por ende requieres algunos de los 2 anteriores + necesitas poder volver a una versión particular para poder implementar el rollback (y automatic retry si es que se quiere).
Lo que dice ahí es que no es necesario comprar una CPU especial ni una memoria especial, sino que basta con usar algunas estructuras de datos + CAS o LL/SC y se tiene memoria trasaccional. Saludos, Guillermo. 2012/11/20 Andrés Fortier <[hidden email]> El tema con la memoria transaccional es el rendimiento. Básicamente, si Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
No responde a la pregunta original de Angel, pero, para tener un "fast become" (o por lo menos no tener que escanear toda la memoria solo para eso), mas allá de las obvias (object tables (GemStone) o direct pointers pero con los headers separados apuntando a los bodies (VW), hay una más que yo conozco para implementar el becomeForward (no become): lazy become. La idea es (por lo que yo entiendo) es que al objeto viejo le pones unos flags en el OH y le pones un pointer al nuevo. Luego (lazily) el GC se encarga de actualizar las referencias al nuevo, hasta que ya no haya nadie apuntando al viejo. Bue, por si mandé fruta, copio lo que dijo Eliot:
2012/11/20 Guillermo Schwarz <[hidden email]> +1 Mariano http://marianopeck.wordpress.com To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Ah! Gracias Mariano, interesante... muy interesante.... diria el Dr. Vicker de Supercar #soytanviejo ;-)... el "viejo truco" de usar el OH ;-)
Se me habia ocurrido algo asi en otro contexto, el anio pasado lo moleste en Smalltalks 2011 al bueno de McClure tratando de explicarlo en Anglish ;-)
Resulta que por lo que entendi de la charla de McClure, cuando en GemStone agregan una variable de instancia a una clase, como que se bailan la conga para reorganizar todos los objetos instancias (hacerle lugar a esa variable) y tener los metodos recompilados (creo que no hace falta, por lo menos al agregar una variable, puede que no haya metodos que la referencien todavia, a no ser que algun metodo tenga ese nombre de variable y la hubiera compilado como global o algo asi, bue....) Eso me hizo acordar a lo que hace Smalltalk/X que tambien, necesita recompilar o algo asi para cuando se agrega una variable de instancia a una clase ya definida.
Mi propuesta es: - x instancia de clase X. X es un objeto, como todos sabemos. - A la definicion de X le agregamos una variable de instancia, una nueva variable que tienen que tener todas sus instancias. Se crea un nuevo objeto clase X2, y X tiene un puntero (hasta entonces en 0) a la nueva X2. El diccionario Smalltalk apunta con el nombre #X a X2
- x tiene como clase a X, y esta, tiene un puntero interno (usualmente en 0) con "nueva version" a X2. X2 tiene un diccionario de metodos, los de X, recompilados para usar la nueva estructura de los objetos instancia (si es que hace falta recompilarlos, por ejemplo, no solo ante un agregado de variable, sino tambien ante una remocion de variable de instancia).
- Cuando se accede a un metodo de x, se accede a X, y ahi, la VM dice: "oia, la pucha, x tiene la estructura de X, pero X ahora tiene una nueva version, X2, aplico los cambios a la estructura interna de x (ahora tiene una nueva variable o dos o lo que sea), y luego de hacer ese cambio, ahora x tiene como clase y apunta directamente a X2.
- A medida que el sistema va funcionando, todas las instancias x1, x2, xn de X pasan a ser "refactorizadas" poco a poco, apuntan a X2, y X original no es usada por nadie, y queda pasible de recoleccion de basura
No es fino? ;-) Tambien al serializar la imagen, se podria forzar la conversion de todos las instancias x que todavia apuntan a X, pero seria volver al esquema McClure/GemStone/MeBailoLaCongaTodaDeGolpe
Angel "Lazy" Lopez
-- 2012/11/21 Mariano Martinez Peck <[hidden email]> No responde a la pregunta original de Angel, pero, para tener un "fast become" (o por lo menos no tener que escanear toda la memoria solo para eso), mas allá de las obvias (object tables (GemStone) o direct pointers pero con los headers separados apuntando a los bodies (VW), hay una más que yo conozco para implementar el becomeForward (no become): lazy become. La idea es (por lo que yo entiendo) es que al objeto viejo le pones unos flags en el OH y le pones un pointer al nuevo. Luego (lazily) el GC se encarga de actualizar las referencias al nuevo, hasta que ya no haya nadie apuntando al viejo. Bue, por si mandé fruta, copio lo que dijo Eliot: To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
In reply to this post by Andres Valloud-5
El día 20 de noviembre de 2012 17:10, Andres Valloud
<[hidden email]> escribió: > Si hay forwardeo de punteros en el object table, entonces si > oneWayBecome: se puede implementar mirando el object table. Si no, > hay que mirar todos los object bodies. En el caso de Dolphin, entiendo que es asi. > Ahora, viste que cuando haces un oneWayBecome: de una clase a otra, > las instancias del receptor no se transforman en instancias del > argumento?... o que por lo menos no deberian transformarse?... que > detalle, no?... Nunca me puesto a pensar que pasa con el receptor de oneWayBecome, seguramente se lo lleve el GC. Saludos! -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
>> Ahora, viste que cuando haces un oneWayBecome: de una clase a otra,
>> las instancias del receptor no se transforman en instancias del >> argumento?... o que por lo menos no deberian transformarse?... que >> detalle, no?... > > Nunca me puesto a pensar que pasa con el receptor de oneWayBecome, > seguramente se lo lleve el GC. En el caso de las clases no porque la clase vieja sigue teniendo instancias... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
En el caso de las clases viejas, es SystemDictionary (Smalltalk) que tiene el nombre asociado al objeto que representa la clase.
De modo que la clase vieja podría dejar de existir (ser GC) si no es porque las instancias viejas tienen punteros a la clase vieja. Cuando esas instancias ya no son referenciadas por nadie más, no se pueden activar y son GC junto con la clase vieja.
Es trivial, ¿no? En el caso de tener CPU threads accediendo a objetos Smalltalk, lo peor que puedes hacer es proteger todo. En el mejor de los casos generas "contention" (live lock) y en el peor de los casos "dead lock".
Lo mejor es lo que hace Lisp: no bloquea nada nunca, porque nunca comparte nada. Y si comparte algo es porque es inmutable. Saludos, Guillermo. 2012/11/21 Andres Valloud <[hidden email]>
Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Free forum by Nabble | Edit this page |