Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
Locked
123
123
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
 
|
Hola Guillermo, La diferencia con un sistema operativo moderno sera simplemente que estos tienen soporte multi-thread nativo. Entonces ante un fallo de pagina, mientras la pagina de memoria es transferida desde el disco, este podria llegar a cambiar de thread. Sinceramente no conosco la implementacion, si alguno conoce como se resuelve este detalle en un sistema operativo moderno bienvenido su aporte. Tampoco estoy seguro que eso sea bueno en todos los casos, habria que switchear a un thread que no genere otro fallo de pagina...(?).No lo se...
Pero si estoy seguro que el St queda esperando la pagina de disco es una limitacion de la vm con la que trabajamos que en caso es la de Squeak/Pharo, que de ser superada podria cambiarse tambien si es que cambiar de thread mejorase el throughput. Tener un hypervisor o una vm que controle a la/las otras creo que siempre fue una idea que estuvo dando vueltas en SqNOS. Pero para los temas que estamos hablando en este thread, creo que en algun punto podria verse como una forma de implementar el multithreading y seguro seria mas "caro" que otras implementaciones.
Saludos, Guido.
-- El 24 de junio de 2011 19:11, Guillermo Schwarz <[hidden email]> escribió:
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
Para clarificar:
Meter todo en la ***misma*** imagen hace dificil (y en algunos casos sospecho que imposible) que el sistema reflexione acerca de si mismo, simplemente porque no se puede observar a si mismo con claridad. 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
Ahora entiendo tu punto.
-- Respecto a la solucion que nosotros le dimos en Sqnos, acoto simplemente que creo que se podria llegar a una prueba formal del correcto funcionamiento ya que el procesador te asegura que siempre que intentes modificar el objeto mientras se esta ejecutando este no lo va a permitir. Aqui hay un hibrido interesante entre imagen y la herramienta que te asegura la correctitud. Igual despues habria que ver que pasa con los buffers donde haces el copy antes de volver a dejar la pagina como escribible y puede que aca si aparescan cuestiones como las que mencionas y una demostracion formal sea mas compleja... Ya que nombraste Newspeak como posible solucion a alguno de los problemas...NewspeakNos no? jeje Saludos, Guido. El 24 de junio de 2011 19:45, Andres Valloud <[hidden email]> escribió:
To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
> Ya que nombraste Newspeak como posible solucion a alguno de los
> problemas...NewspeakNos no? jeje Y si... por ejemplo... -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Guido Chari
Guido,
Los threads son implementados a nivel del sistema operativo, pero tambièn tienen soporte en la CPU, de otra manera no tendrìan ninguna ventaja en cuanto a tiempo de ejecución. De hecho creo que el tema está resuelto desde el procesador x86 con los manejadores de interrupciones, lo que no estaba resuelto era el manejo de memoria, ya que toda la memoria era real y no era factible determinar cuando un proceso accede a la memoria de otro.
A nivel de hardware incluso para el acceso a memoria hay modo kernel y modo usuario, lo que signfica que la memoria se accede en modo real (las direcciones son reales) o modo protegido (las direcciones son ficticias y deben ser traducidas). Cuando está en modo protegido cada acceso a memoria debe traducir el espacio de memoria a modo real, de modo que cuando tienes varios procesos, todos pueden hacer referencia a la misma direcciòn protegida de memoria sin producir un segmentation fault ya que la direcciòn real es otra. Además si estás en modo protegido, puede que la memoria estè en una pàgina en disco y es el hardware que se da cuenta y llama a la señal para recuperar la pàgina. Esa llamada lllega al sistema operativo mediante un pedazo de còdigo que està en un àrea de memoria que no puede ser "paged out".
¿Es obvio porquè, no? Si estuviera en disco no habrìa còdigo para traerlo de vuelta. Imagino que ese es el problema al que te referìas anteriomente. Se supone que eso està resuelto a nivel de hardware y sòlo es necesario indicar cuàl es el còdigo que hace el page in e indicar que no debe ser paged out. En el antiguo procesador 8086 habìa un par de instrucciones parecidas que se llamaban STI y CLI. Si no me equivoco STI era para decir "no me interrumpan porque estoy en un segmento de còdigo delicado" y CLI era lo contrario. ¿Porquè digo que es parecido? Porque si estoy resolviendo un page in, no puedo generar otro page in (o quizàs sì si tuviera un stack de page in por resolver). En el caso del STI y CLI es lo mismo, si estoy manejando una interrupciòn no quiero que me interrumpan, pero podrìamos usar u stack tambièn, aunque por otro lado puede que sea una mala idea si tengo un tiempo limitado para atenderla.
El problema en Smalltalk, imagino, es que gracias al polimorfismo tomas un dato que es un entero y de pronto ese paràmetro puede recibir cualquier clase que acepte el mismo protocolo, lo que significarìa que podrìa ejecutar còdigo arbitrario que si estoy resolviendo un page in, no quiero que me cause otro page in, ¿no?. Algo menciona Alan Kay cuando crearon Squeak en Smalltalk respecto de que implementaron un pequeño traductor de Smalltalk a C (de un sobconjunto de Smalltalk) y que era factible implementar el intèrprete de Smalltalk en ese subconjunto. Imagino que ese subconjunto de Smalltalk es justamente el subconjunto que:
1. No tiene polimorfismo. 2. Permite ejecutar el intèrprete de Smalltalk. 3. Es el que necesitas para ejecutar tu proceso de page in en Smalltalk. 4. Al escribirlo en Smalltalk, lo puedes convertir a C...
Creo que justamente el chiste del hypervisor es que es como VMWare, permite ejecutar un OS encima al simular un hardware, salvo que no requiere un sistema operativo debajo, ya que el hypervisor ejecuta sobre el metal.
-- Puedes usar el hypervisor hecho por Xen por ejemplo (http://www.xen.org/) de modo que podrìas ejecutar varias instancias de SqueakNOS, cada una creyendo que està funcionando sobre el metal.
Ahora bien, lo que propone Andy Tannenbaum, el creador de Minix, es que en el futuro todos los sistemas operativos seràn hypervisors y cada driver correrà como si estuviera en su propio sistema operativo. Lo dificil ahì no es que ejecute, ni que si se cae el driver no se caiga el sistema operativo. Todo eso ya estarìa resuelto. Lo dificl serìa còmo comunicar los distintos procesos y creo que la respuesta obvia es a travès de sockets.
Hacer una VM con threading no me parece una buena idea porque estàs cambiando un modelo simple que funciona. Saludos, Guillermo.
2011/6/24 Guido Chari <[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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
>
> Bueno, todos estos problemas no existirian si la imagen no se > estuviera ejecutando mientras se carga el codigo. O si tuvieramos > divisiones al estilo Newspeak. Pero... aqui estamos... la esencia del > problema es que un ente no se puede observar a si mismo excepto > dividiendose en la parte que observa y la parte observada. Meter todo > en la imagen hace dificil (y en algunos casos sospecho que imposible) > que el sistema reflexione acerca de si mismo, simplemente porque no se > puede observar a si mismo con claridad. Que buenas las problematicas narcisisticas de la imagen (ups, esto se resignifico). Digamos que la VM se queda fascinada mirando su propia imagen. Muy bueno el thread, y la tesis! Ahí estaré con los trapos de SqueakNOS jb -- " 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Algunos puntos, tal vez alejado del tema de este thread, pero no tanto de Smalltalk, en este sabado de frio aqui en Buenos Aires.
Creo que algo ya habia planteado en esta lista, en un breve thread con @HernanWilkinson: - Los objetos envian mensajes. Deberia habiar la posibilidad de enviar mensaje "fire and forget", sin esperar retorno - Los objetos pueden ser como celulas: no cobran vida cuando llega un mensaje, siempre "estan haciendo algo". Podemos llamarlos agentes? actores? No tienen que ser todos los objetos asi. - Los objetos "estan" en cualquier lugar y se levantan en cualquier lugar. Que esten en esta computadora o en aquella, seria un accidente - No es facil, y no siempre es deseable, tener esa "location transparency", un punto a discutir. Habria que conseguir que los objetos que mas conversen entre si, se vayan "amuchando" en una maquina/s cercanas. - Deberia haber algo como en los 70/80 era el Sistema Pick (de Richard Pick): todo estaba en algun sector: estado de registros, memoria de trabajo, datos de un archivo. Y los sectores vivian en memoria de acceso rapido (una RAM p.ej.), o en disco, indistintamente. Expandir eso a memorias y cpus de varias maquinas, trabajando en conjunto. - Por ejemplo, en los 90 lei un articulo en la Dr. Dobb's que proponia que todo elemento tuviera un GUID: objeto, archivo, metodo, etc... Habia que resolver como recuperar un elemento por el GUID, y como almacenarlo (tal vez en varias maquinas/discos/memorias). - Sino se puede eso, habria que investigar NoSql y soluciones parecidas. Tener todo en memoria (en varias memorias/maquinas) ir grabando con consistencia eventual, solo por si se corta la luz :-) - Vi con interes que aca se trato el tema SSD (Solid State Disks). Un camino a usar. - En HPC (High Performance Computing) vi memoria de acceso rapido compartida entre varias maquinas/cpus. Lo vi tambien en procesamiento en paralelo sobre GPU, pero me parece eso mas orientado a algunos algoritmos en particular. - De alguna forma, todo esto propone: la disolucion de "memoria para una maquina", "cpu en una maquina", etc. Juntando todo eso, no hay temas a resolver como "salvar la imagen a disco". The network is the application. The living image is everywhere ;-) Jeje, no digo que sea facil ;-) Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez
2011/6/25 Javier Burroni <[hidden email]>
-- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Guillermo Schwarz
> ¿Es obvio porquè, no? Si estuviera en disco no habrìa còdigo para traerlo de
> vuelta. Imagino que ese es el problema al que te referìas anteriomente. Se > supone que eso està resuelto a nivel de hardware y sòlo es necesario indicar > cuàl es el còdigo que hace el page in e indicar que no debe ser paged out. > En el antiguo procesador 8086 habìa un par de instrucciones parecidas que se > llamaban STI y CLI. Si no me equivoco STI era para decir "no me interrumpan > porque estoy en un segmento de còdigo delicado" y CLI era lo contrario. > ¿Porquè digo que es parecido? Porque si estoy resolviendo un page in, no > puedo generar otro page in (o quizàs sì si tuviera un stack de page in por > resolver). En el caso del STI y CLI es lo mismo, si estoy manejando una > interrupciòn no quiero que me interrumpan, pero podrìamos usar u stack > tambièn, aunque por otro lado puede que sea una mala idea si tengo un tiempo > limitado para atenderla. Conste que el modo protegido asi como lo conocemos hoy aparecio con el 386. > El problema en Smalltalk, imagino, es que gracias al polimorfismo tomas un > dato que es un entero y de pronto ese paràmetro puede recibir cualquier > clase que acepte el mismo protocolo, lo que significarìa que podrìa ejecutar > còdigo arbitrario que si estoy resolviendo un page in, no quiero que me > cause otro page in, ¿no?. No entendi. > Ahora bien, lo que propone Andy Tannenbaum, el creador de Minix, es que en > el futuro todos los sistemas operativos seràn hypervisors y cada driver > correrà como si estuviera en su propio sistema operativo. Lo dificil ahì no > es que ejecute, ni que si se cae el driver no se caiga el sistema operativo. > Todo eso ya estarìa resuelto. Pero claro, esto es simplemente una cuestion de sentarse y programar :). Punto aparte, no me termina de convencer poner tantos cores en un CPU... tarde o temprano la probabilidad de falla catastrofica sera suficientemente grande como para que el sistema en conjunto no sea confiable. Por ejemplo, por mas RAID que pongas, tarde o temprano no es posible copiar un array de discos suficientemente grande sin fallas. O tampoco es posible hacer un backup de dicho array sin fallas. 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Angel Java Lopez
> - De alguna forma, todo esto propone: la disolucion de "memoria para una
> maquina", "cpu en una maquina", etc. Puede ser. Tambien hay que tener en cuenta que diferentes topologias de computo sirven para diferentes problemas. Por ejemplo, seguir acumulando cores en un CPU no sirve para nada si no hay ancho de banda de memoria para mantenerlos ocupados. De hecho, al pelearse entre si para usar la memoria, la computadora va a ir mas lento al tener mas cores. or ejemplo, un CPU con 16 cores va a ir mas lento que un CPU con 8 cores. Pero depende del problema. A mi gusto, tarde o temprano estos niveles de abstraccion estan buenos para no pensar en esos problemas, pero tarde o temprano se paga con ineficiencia. -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
Hola Andrés,
2011/6/25 Andres Valloud <[hidden email]> Saludos cordiales,
El polimorfismo tiene varios efectos. De partida cuando creas que un método así: add: aNumber ^self + aNumber entonces le peudes pasar como parámetro un integer, un float o una matriz (asumiendo que la clase Matrix entendiera el operador +). Ahora bien, cuál es el tipo de aNumber. No lo sabemos. Podemos asumir que el programador pensó en un clase que descendiera de Number, pero nada lo obliga.
La premisa que puse arriba (y que no aparece en el texto que dejaste) es que estamos ejecutando código Smalltalk que se encuentra en un área de memoria que está marcada como que no se puede hacer page out. ¿Cómo se eso? Porque el sistema operativo puede marcar las áreas de memoria como "esto se puede hacer page out" o "esto no". Para eso, el código de page out simplemente revisa si el área está marcada o no, y sólo hace page out de lo que está marcado. Hasta ahí trivial. (Oops, no debí haber dicho eso no se vaya a molestar alguien :-)...
Entonces el código de pageIn es la misma cuestión. Detecta que el código está paged out (eso lo hace el hardware), a través de una interrupción echa a andar el código que hace page in. Ahora este códgo está en Smalltalk, entonces si uso polimorfismo, puede que reciba un parámetro que no corresponde, o mejor dicho, que ejecute código esté paged out, entonces puede caer en un ciclo infinito, gatillando la interrupción adínfinitum.
Al revés. Si se cae el driver se cae el sistema operativo, pero este corre dentro de una VM que es el VMWare, de modo que se echa a andar de nuevo inmediatamente.
¿Qué dices? Por ejemplo, por mas RAID que pongas, tarde o temprano no Ah.sí claro. Si todos los discos tienen un MTBF, entonces llega un momento que si tengo un millón de discos, al menos un byte sale errado. Por suerte ya existen las memorias con autocorreción de errores. Primero dectan el error y luego lo corrigen. Y de nuevo el algoritmo es trivial ;-D
Claro que sobre 8 bits, pueden corregir uno, utilizando 2 adiconales. El algoritmo se llama ECC. Acá hay un ejemplo: http://en.wikipedia.org/wiki/BCH_code
Ahora si tienes eso, puedes aplicar el algortimo varias veces y proteger cada vez más los datos, aumentando en un 25% el costo en $$$ cada vez que lo aplicas.
O tampoco es posible hacer un backup de dicho array sin Es lo mismo que dijiste antes, un caso particular. -- 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 Andres Valloud-5
Este tema de la metacircularidad es más que interesante. Hay un paper
que viene justo al caso de lo que mencionabas: Object Spaces for Safe Image Surgery http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf que probablemente sea un camino a investigar en el futuro Saludos, Javier. On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: > Ah, mira vos... pense que al final lo habian resuelto desde la imagen > pero sin tener que usar page faults... o sea, vaciar un espacio de > memoria, y usar objetos ahi para grabar el resto de la imagen (pero > sin grabar los objetos nuevos que se van creando para grabar la > imagen). > > Mirandolo un poco desde mas lejos, me sigue dando la impresion de que > tener todo en la imagen, y pretender que la imagen resuelva toda clase > de metaproblemas circulares de manera imperativa, a la larga es una > desventaja. Ahora por ejemplo me va a tocar trabajar con dos > problemas que tienen muchisimo que ver con esto, y la verdad me > encantaria no tener que andar preocupandome de como voy a hacer la > cirugia de cerebro en la imagen sin que reviente todo. O como podrian > hacer los usuarios para deshacer los cambios si prefieren el codigo > viejo para sus aplicaciones, de nuevo sin que reviente todo. Son > problemas que no son faciles, y quiza por eso mas o menos divertidos > de resolver porque al final cuando te salen decis "ja, groso!"... > aunque cada vez les veo menos la gracia. Capaz que estaria bueno > resolver TODOS los problemas metacirculares una vez y para siempre. > > 2011/6/24 Hernan Wilkinson <[hidden email]>: > > > > > > > > > por si les interesa... > > > ---------- Forwarded message ---------- > > From: Hernan Wilkinson <[hidden email]> > > Date: 2011/6/24 > > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS > > To: docentes <[hidden email]>, alumnos <[hidden email]> > > > Defensa de Tesis de Licenciatura > > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. > > Título: Persistencia en SqueakNOS > > Alumnos: Guido Chari y Javier Pimás > > Directores: Hernán Wilkinson y Gerardo Richiarte > > Jurado: Máximo Prieto y Gabriela Arevalo. > > Resumen: > > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema > > Operativo" dentro del dialecto Squeak del lenguaje de programación > > Smalltalk. > > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse > > completamente en Smalltalk, utilizando código de bajo nivel únicamente en > > los casos en que no sea posible utilizar Smalltalk o que el deterioro de > > rendimiento sea extremadamente ostensible. > > El proyecto es un trabajo aún en desarrollo, y como tal, varias > > funcionalidades comunes a los Sistemas Operativos no han sido implementadas > > aún debido a su complejidad. Es por ello que esta investigación se centra en > > analizar varios interrogantes relacionados con la persistencia de los > > objetos, interrogantes que se presentan al momento de querer grabar el grafo > > de objetos que representa el modelo desarrollado. > > Para poder responder estos interrogantes, se desarrolló un controlador de > > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo > > que brinda compatibilidad con otros sistemas operativos y con el entorno > > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los > > métodos y se avanza hacia el grabado de la imagen, característica que aún no > > estaba disponible en el sistema. > > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era > > la simplicidad y su principal desventaja el requerir una utilización > > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue > > el primer paso para lograr la atomicidad necesaria para grabar los objetos > > mientras estos estaban siendo modificados. > > Finalmente, se implementó un esquema de manejo de memoria basado en > > paginación, modificando el mecanismo de manejo de interrupciones original de > > SqueakNos para que pudiera funcionar en forma sincrónica, requisito > > indispensable para resolver los fallos de página. Esta solución > > permitió resolver los fallos de página completamente desde Smalltalk, lo > > cual dio lugar a la experimentación y al desarrollo de formas novedosas de > > utilización del mismo. Gracias a esto, resultó posible por ejemplo, > > implementar una técnica alternativa de persistencia de la imagen, que > > utiliza mucha menos memoria que la original debido a la asistencia del > > mecanismo de paginación y la utilización de la técnica de copy on write. > > Por último, se analizan aspectos relacionados con la manera de trabajar en > > este tipo de entornos y plataformas, sus ventajas, sus dificultades y > > complicaciones. > > > -- > > Hernán Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: [hidden email] > > site: http://www.10Pines.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 -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una
separacion real entre los espacios de objetos, y que la maquina virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" un espacio de objetos desde otro espacio de objetos. Estas facilidades estan buenas porque por ejemplo hoy el debugger del Smalltalk de turno sera muy bueno y todo lo que quieras pero es imposible debuggear codigo arbitrario --- justamente porque la imagen no puede partirse en dos, una parte observada y otra parte que observa. Pero si el debugger estuviera en una imagen y el coso que estas debuggeando estuviera en otra imagen, entonces no habria problema y podrias debuggear por ejemplo la tabla de simbolos sin colgar la imagen mientras estas adentro de aSemaphore critical: [... blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la GUI usando la GUI para el debugger... 2011/6/27 pocho <[hidden email]>: > Este tema de la metacircularidad es más que interesante. Hay un paper > que viene justo al caso de lo que mencionabas: > > Object Spaces for Safe Image Surgery > http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf > > que probablemente sea un camino a investigar en el futuro > > Saludos, > Javier. > > On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: >> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >> pero sin tener que usar page faults... o sea, vaciar un espacio de >> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >> sin grabar los objetos nuevos que se van creando para grabar la >> imagen). >> >> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >> tener todo en la imagen, y pretender que la imagen resuelva toda clase >> de metaproblemas circulares de manera imperativa, a la larga es una >> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >> problemas que tienen muchisimo que ver con esto, y la verdad me >> encantaria no tener que andar preocupandome de como voy a hacer la >> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >> hacer los usuarios para deshacer los cambios si prefieren el codigo >> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >> problemas que no son faciles, y quiza por eso mas o menos divertidos >> de resolver porque al final cuando te salen decis "ja, groso!"... >> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >> resolver TODOS los problemas metacirculares una vez y para siempre. >> >> 2011/6/24 Hernan Wilkinson <[hidden email]>: >> >> >> >> >> >> >> >> > por si les interesa... >> >> > ---------- Forwarded message ---------- >> > From: Hernan Wilkinson <[hidden email]> >> > Date: 2011/6/24 >> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >> > To: docentes <[hidden email]>, alumnos <[hidden email]> >> >> > Defensa de Tesis de Licenciatura >> > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >> > Título: Persistencia en SqueakNOS >> > Alumnos: Guido Chari y Javier Pimás >> > Directores: Hernán Wilkinson y Gerardo Richiarte >> > Jurado: Máximo Prieto y Gabriela Arevalo. >> > Resumen: >> > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema >> > Operativo" dentro del dialecto Squeak del lenguaje de programación >> > Smalltalk. >> > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse >> > completamente en Smalltalk, utilizando código de bajo nivel únicamente en >> > los casos en que no sea posible utilizar Smalltalk o que el deterioro de >> > rendimiento sea extremadamente ostensible. >> > El proyecto es un trabajo aún en desarrollo, y como tal, varias >> > funcionalidades comunes a los Sistemas Operativos no han sido implementadas >> > aún debido a su complejidad. Es por ello que esta investigación se centra en >> > analizar varios interrogantes relacionados con la persistencia de los >> > objetos, interrogantes que se presentan al momento de querer grabar el grafo >> > de objetos que representa el modelo desarrollado. >> > Para poder responder estos interrogantes, se desarrolló un controlador de >> > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo >> > que brinda compatibilidad con otros sistemas operativos y con el entorno >> > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >> > métodos y se avanza hacia el grabado de la imagen, característica que aún no >> > estaba disponible en el sistema. >> > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era >> > la simplicidad y su principal desventaja el requerir una utilización >> > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >> > el primer paso para lograr la atomicidad necesaria para grabar los objetos >> > mientras estos estaban siendo modificados. >> > Finalmente, se implementó un esquema de manejo de memoria basado en >> > paginación, modificando el mecanismo de manejo de interrupciones original de >> > SqueakNos para que pudiera funcionar en forma sincrónica, requisito >> > indispensable para resolver los fallos de página. Esta solución >> > permitió resolver los fallos de página completamente desde Smalltalk, lo >> > cual dio lugar a la experimentación y al desarrollo de formas novedosas de >> > utilización del mismo. Gracias a esto, resultó posible por ejemplo, >> > implementar una técnica alternativa de persistencia de la imagen, que >> > utiliza mucha menos memoria que la original debido a la asistencia del >> > mecanismo de paginación y la utilización de la técnica de copy on write. >> > Por último, se analizan aspectos relacionados con la manera de trabajar en >> > este tipo de entornos y plataformas, sus ventajas, sus dificultades y >> > complicaciones. >> >> > -- >> > Hernán Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: [hidden email] >> > site: http://www.10Pines.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 > > -- > 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Grrr... posta que cuando pueda deberia tratar de trabajar en esto...
te imaginaras que si hay espacios de objetos entonces podes poner JITs a correr en paralelo porque no hay conflicto posible... bueh. Ahora cuando termine con el tema de los bugs del GC, punto flotante y hashing (estos que comente en otro mail), deberia empezar a hacer lobby para trabajar en esto. Estaria *muy* bueno... 2011/6/27 Andres Valloud <[hidden email]>: > Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una > separacion real entre los espacios de objetos, y que la maquina > virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" > un espacio de objetos desde otro espacio de objetos. Estas > facilidades estan buenas porque por ejemplo hoy el debugger del > Smalltalk de turno sera muy bueno y todo lo que quieras pero es > imposible debuggear codigo arbitrario --- justamente porque la imagen > no puede partirse en dos, una parte observada y otra parte que > observa. Pero si el debugger estuviera en una imagen y el coso que > estas debuggeando estuviera en otra imagen, entonces no habria > problema y podrias debuggear por ejemplo la tabla de simbolos sin > colgar la imagen mientras estas adentro de aSemaphore critical: [... > blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la > GUI usando la GUI para el debugger... > > 2011/6/27 pocho <[hidden email]>: >> Este tema de la metacircularidad es más que interesante. Hay un paper >> que viene justo al caso de lo que mencionabas: >> >> Object Spaces for Safe Image Surgery >> http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf >> >> que probablemente sea un camino a investigar en el futuro >> >> Saludos, >> Javier. >> >> On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: >>> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >>> pero sin tener que usar page faults... o sea, vaciar un espacio de >>> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >>> sin grabar los objetos nuevos que se van creando para grabar la >>> imagen). >>> >>> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >>> tener todo en la imagen, y pretender que la imagen resuelva toda clase >>> de metaproblemas circulares de manera imperativa, a la larga es una >>> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >>> problemas que tienen muchisimo que ver con esto, y la verdad me >>> encantaria no tener que andar preocupandome de como voy a hacer la >>> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >>> hacer los usuarios para deshacer los cambios si prefieren el codigo >>> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >>> problemas que no son faciles, y quiza por eso mas o menos divertidos >>> de resolver porque al final cuando te salen decis "ja, groso!"... >>> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >>> resolver TODOS los problemas metacirculares una vez y para siempre. >>> >>> 2011/6/24 Hernan Wilkinson <[hidden email]>: >>> >>> >>> >>> >>> >>> >>> >>> > por si les interesa... >>> >>> > ---------- Forwarded message ---------- >>> > From: Hernan Wilkinson <[hidden email]> >>> > Date: 2011/6/24 >>> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>> > To: docentes <[hidden email]>, alumnos <[hidden email]> >>> >>> > Defensa de Tesis de Licenciatura >>> > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>> > Título: Persistencia en SqueakNOS >>> > Alumnos: Guido Chari y Javier Pimás >>> > Directores: Hernán Wilkinson y Gerardo Richiarte >>> > Jurado: Máximo Prieto y Gabriela Arevalo. >>> > Resumen: >>> > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema >>> > Operativo" dentro del dialecto Squeak del lenguaje de programación >>> > Smalltalk. >>> > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse >>> > completamente en Smalltalk, utilizando código de bajo nivel únicamente en >>> > los casos en que no sea posible utilizar Smalltalk o que el deterioro de >>> > rendimiento sea extremadamente ostensible. >>> > El proyecto es un trabajo aún en desarrollo, y como tal, varias >>> > funcionalidades comunes a los Sistemas Operativos no han sido implementadas >>> > aún debido a su complejidad. Es por ello que esta investigación se centra en >>> > analizar varios interrogantes relacionados con la persistencia de los >>> > objetos, interrogantes que se presentan al momento de querer grabar el grafo >>> > de objetos que representa el modelo desarrollado. >>> > Para poder responder estos interrogantes, se desarrolló un controlador de >>> > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo >>> > que brinda compatibilidad con otros sistemas operativos y con el entorno >>> > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>> > métodos y se avanza hacia el grabado de la imagen, característica que aún no >>> > estaba disponible en el sistema. >>> > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era >>> > la simplicidad y su principal desventaja el requerir una utilización >>> > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >>> > el primer paso para lograr la atomicidad necesaria para grabar los objetos >>> > mientras estos estaban siendo modificados. >>> > Finalmente, se implementó un esquema de manejo de memoria basado en >>> > paginación, modificando el mecanismo de manejo de interrupciones original de >>> > SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>> > indispensable para resolver los fallos de página. Esta solución >>> > permitió resolver los fallos de página completamente desde Smalltalk, lo >>> > cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>> > utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>> > implementar una técnica alternativa de persistencia de la imagen, que >>> > utiliza mucha menos memoria que la original debido a la asistencia del >>> > mecanismo de paginación y la utilización de la técnica de copy on write. >>> > Por último, se analizan aspectos relacionados con la manera de trabajar en >>> > este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>> > complicaciones. >>> >>> > -- >>> > Hernán Wilkinson >>> > Agile Software Development, Teaching & Coaching >>> > Mobile: +54 - 911 - 4470 - 7207 >>> > email: [hidden email] >>> > site: http://www.10Pines.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 >> >> -- >> 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Hola,
2011/6/27 Andres Valloud <[hidden email]>: > Grrr... posta que cuando pueda deberia tratar de trabajar en esto... > te imaginaras que si hay espacios de objetos entonces podes poner JITs > a correr en paralelo porque no hay conflicto posible... bueh. Ahora > cuando termine con el tema de los bugs del GC, punto flotante y > hashing (estos que comente en otro mail), deberia empezar a hacer > lobby para trabajar en esto. Estaria *muy* bueno... pregunto (es un problema que me da curiosidad, pero no se la respuesta): ¿Por que no se puede tener ahora JITs en paralelo, para ciertos casos? Por ejemplo, estas mandando un mensaje a un objeto, y JITeas ese mensaje para ese receptor, y los mensaje que se le envían a self en ese método (preemtivamete). Creo que habíamos estado hablando sobre algo así en la ultima Smalltalks > > 2011/6/27 Andres Valloud <[hidden email]>: >> Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una >> separacion real entre los espacios de objetos, y que la maquina >> virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" >> un espacio de objetos desde otro espacio de objetos. Estas >> facilidades estan buenas porque por ejemplo hoy el debugger del >> Smalltalk de turno sera muy bueno y todo lo que quieras pero es >> imposible debuggear codigo arbitrario --- justamente porque la imagen >> no puede partirse en dos, una parte observada y otra parte que >> observa. Pero si el debugger estuviera en una imagen y el coso que >> estas debuggeando estuviera en otra imagen, entonces no habria >> problema y podrias debuggear por ejemplo la tabla de simbolos sin >> colgar la imagen mientras estas adentro de aSemaphore critical: [... >> blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la >> GUI usando la GUI para el debugger... >> >> 2011/6/27 pocho <[hidden email]>: >>> Este tema de la metacircularidad es más que interesante. Hay un paper >>> que viene justo al caso de lo que mencionabas: >>> >>> Object Spaces for Safe Image Surgery >>> http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf >>> >>> que probablemente sea un camino a investigar en el futuro >>> >>> Saludos, >>> Javier. >>> >>> On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: >>>> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >>>> pero sin tener que usar page faults... o sea, vaciar un espacio de >>>> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >>>> sin grabar los objetos nuevos que se van creando para grabar la >>>> imagen). >>>> >>>> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >>>> tener todo en la imagen, y pretender que la imagen resuelva toda clase >>>> de metaproblemas circulares de manera imperativa, a la larga es una >>>> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >>>> problemas que tienen muchisimo que ver con esto, y la verdad me >>>> encantaria no tener que andar preocupandome de como voy a hacer la >>>> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >>>> hacer los usuarios para deshacer los cambios si prefieren el codigo >>>> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >>>> problemas que no son faciles, y quiza por eso mas o menos divertidos >>>> de resolver porque al final cuando te salen decis "ja, groso!"... >>>> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >>>> resolver TODOS los problemas metacirculares una vez y para siempre. >>>> >>>> 2011/6/24 Hernan Wilkinson <[hidden email]>: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> > por si les interesa... >>>> >>>> > ---------- Forwarded message ---------- >>>> > From: Hernan Wilkinson <[hidden email]> >>>> > Date: 2011/6/24 >>>> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>> > To: docentes <[hidden email]>, alumnos <[hidden email]> >>>> >>>> > Defensa de Tesis de Licenciatura >>>> > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>>> > Título: Persistencia en SqueakNOS >>>> > Alumnos: Guido Chari y Javier Pimás >>>> > Directores: Hernán Wilkinson y Gerardo Richiarte >>>> > Jurado: Máximo Prieto y Gabriela Arevalo. >>>> > Resumen: >>>> > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema >>>> > Operativo" dentro del dialecto Squeak del lenguaje de programación >>>> > Smalltalk. >>>> > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse >>>> > completamente en Smalltalk, utilizando código de bajo nivel únicamente en >>>> > los casos en que no sea posible utilizar Smalltalk o que el deterioro de >>>> > rendimiento sea extremadamente ostensible. >>>> > El proyecto es un trabajo aún en desarrollo, y como tal, varias >>>> > funcionalidades comunes a los Sistemas Operativos no han sido implementadas >>>> > aún debido a su complejidad. Es por ello que esta investigación se centra en >>>> > analizar varios interrogantes relacionados con la persistencia de los >>>> > objetos, interrogantes que se presentan al momento de querer grabar el grafo >>>> > de objetos que representa el modelo desarrollado. >>>> > Para poder responder estos interrogantes, se desarrolló un controlador de >>>> > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo >>>> > que brinda compatibilidad con otros sistemas operativos y con el entorno >>>> > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>>> > métodos y se avanza hacia el grabado de la imagen, característica que aún no >>>> > estaba disponible en el sistema. >>>> > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era >>>> > la simplicidad y su principal desventaja el requerir una utilización >>>> > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >>>> > el primer paso para lograr la atomicidad necesaria para grabar los objetos >>>> > mientras estos estaban siendo modificados. >>>> > Finalmente, se implementó un esquema de manejo de memoria basado en >>>> > paginación, modificando el mecanismo de manejo de interrupciones original de >>>> > SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>>> > indispensable para resolver los fallos de página. Esta solución >>>> > permitió resolver los fallos de página completamente desde Smalltalk, lo >>>> > cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>>> > utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>>> > implementar una técnica alternativa de persistencia de la imagen, que >>>> > utiliza mucha menos memoria que la original debido a la asistencia del >>>> > mecanismo de paginación y la utilización de la técnica de copy on write. >>>> > Por último, se analizan aspectos relacionados con la manera de trabajar en >>>> > este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>>> > complicaciones. >>>> >>>> > -- >>>> > Hernán Wilkinson >>>> > Agile Software Development, Teaching & Coaching >>>> > Mobile: +54 - 911 - 4470 - 7207 >>>> > email: [hidden email] >>>> > site: http://www.10Pines.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 >>> >>> -- >>> 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 -- " 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Hola Javier,
¿Y cómo determinas cuando lso JIT pueden correr en paralelo y cuando no? Una manera trivial de hacer eso sería tener varias VMs corriendo simultáneamente y comunicarlas mediante sockets. Por ejemplo tener una VM para el filesystem, una para la pantalla, otra para los dispositivos, otra para cada aplicación, etc. Cuando quieres comunicarlas, necesariamente invocan a otra que recibe mensajes mediante sockets. La ventaja de los sockets es que naturalmente funcionan como una cola y serializan los mensajes desde el punto de vista del receptor.
-- Separar dentro de una misma VM varios espacios de objetos me parece innecesariamente complejo. No creo que se ahorre memoria ni que anda más rápido, puedo estar equivocado, pero eso me suena a una reimplementación de los threads en Smalltalk, algo así como feature envy. Un poco como reimplementar el ambiente de ventanas de Smalltalk en Mesa (Object Pascal), según Alan Kay por el mismo esfuerzo se podría haber implementado JIT en Smalltalk 80 en vez de haber tenido que esperar a Parc Place.
Saludos, Guillermo. 2011/6/27 Javier Burroni <[hidden email]> Hola, -- 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Javier Burroni
Yh, porque hay pila de cosas que se rompen inmediatamente si haces
eso. Ademas, primero habria que programar que los objetos esten realmente separados, asi que habria que reprogramar todo el memory manager de nuevo (allocations, gc, los RTs, etc). Ademas, estaria bueno que se pudiera compartir el perm space, pero entonces hay que programar mas aun... etc etc etc... y despues de eso hay que ver como reacciona la imagen si por ejemplo permitis que todas las primitivas sean concurrentes. Por ejemplo, que pasa si dos threads tratan de abrir un archivo al mismo tiempo. O que pasa cuando alguna de las imagenes dice primSnapshot. O Delay wait:. Etc etc etc... es un rebardo. Y ademas esa clase de cambios te va a exponer a todas las suposiciones con que el codigo esta escrito que se invalidan y entonces todo se rompe inmediatamente o... gulp... "appears to work"... 2011/6/27 Javier Burroni <[hidden email]>: > Hola, > > 2011/6/27 Andres Valloud <[hidden email]>: >> Grrr... posta que cuando pueda deberia tratar de trabajar en esto... >> te imaginaras que si hay espacios de objetos entonces podes poner JITs >> a correr en paralelo porque no hay conflicto posible... bueh. Ahora >> cuando termine con el tema de los bugs del GC, punto flotante y >> hashing (estos que comente en otro mail), deberia empezar a hacer >> lobby para trabajar en esto. Estaria *muy* bueno... > pregunto (es un problema que me da curiosidad, pero no se la > respuesta): ¿Por que no se puede tener ahora JITs en paralelo, para > ciertos casos? Por ejemplo, estas mandando un mensaje a un objeto, y > JITeas ese mensaje para ese receptor, y los mensaje que se le envían a > self en ese método (preemtivamete). Creo que habíamos estado hablando > sobre algo así en la ultima Smalltalks >> >> 2011/6/27 Andres Valloud <[hidden email]>: >>> Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una >>> separacion real entre los espacios de objetos, y que la maquina >>> virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" >>> un espacio de objetos desde otro espacio de objetos. Estas >>> facilidades estan buenas porque por ejemplo hoy el debugger del >>> Smalltalk de turno sera muy bueno y todo lo que quieras pero es >>> imposible debuggear codigo arbitrario --- justamente porque la imagen >>> no puede partirse en dos, una parte observada y otra parte que >>> observa. Pero si el debugger estuviera en una imagen y el coso que >>> estas debuggeando estuviera en otra imagen, entonces no habria >>> problema y podrias debuggear por ejemplo la tabla de simbolos sin >>> colgar la imagen mientras estas adentro de aSemaphore critical: [... >>> blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la >>> GUI usando la GUI para el debugger... >>> >>> 2011/6/27 pocho <[hidden email]>: >>>> Este tema de la metacircularidad es más que interesante. Hay un paper >>>> que viene justo al caso de lo que mencionabas: >>>> >>>> Object Spaces for Safe Image Surgery >>>> http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf >>>> >>>> que probablemente sea un camino a investigar en el futuro >>>> >>>> Saludos, >>>> Javier. >>>> >>>> On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: >>>>> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >>>>> pero sin tener que usar page faults... o sea, vaciar un espacio de >>>>> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >>>>> sin grabar los objetos nuevos que se van creando para grabar la >>>>> imagen). >>>>> >>>>> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >>>>> tener todo en la imagen, y pretender que la imagen resuelva toda clase >>>>> de metaproblemas circulares de manera imperativa, a la larga es una >>>>> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >>>>> problemas que tienen muchisimo que ver con esto, y la verdad me >>>>> encantaria no tener que andar preocupandome de como voy a hacer la >>>>> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >>>>> hacer los usuarios para deshacer los cambios si prefieren el codigo >>>>> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >>>>> problemas que no son faciles, y quiza por eso mas o menos divertidos >>>>> de resolver porque al final cuando te salen decis "ja, groso!"... >>>>> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >>>>> resolver TODOS los problemas metacirculares una vez y para siempre. >>>>> >>>>> 2011/6/24 Hernan Wilkinson <[hidden email]>: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > por si les interesa... >>>>> >>>>> > ---------- Forwarded message ---------- >>>>> > From: Hernan Wilkinson <[hidden email]> >>>>> > Date: 2011/6/24 >>>>> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>>> > To: docentes <[hidden email]>, alumnos <[hidden email]> >>>>> >>>>> > Defensa de Tesis de Licenciatura >>>>> > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>>>> > Título: Persistencia en SqueakNOS >>>>> > Alumnos: Guido Chari y Javier Pimás >>>>> > Directores: Hernán Wilkinson y Gerardo Richiarte >>>>> > Jurado: Máximo Prieto y Gabriela Arevalo. >>>>> > Resumen: >>>>> > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema >>>>> > Operativo" dentro del dialecto Squeak del lenguaje de programación >>>>> > Smalltalk. >>>>> > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse >>>>> > completamente en Smalltalk, utilizando código de bajo nivel únicamente en >>>>> > los casos en que no sea posible utilizar Smalltalk o que el deterioro de >>>>> > rendimiento sea extremadamente ostensible. >>>>> > El proyecto es un trabajo aún en desarrollo, y como tal, varias >>>>> > funcionalidades comunes a los Sistemas Operativos no han sido implementadas >>>>> > aún debido a su complejidad. Es por ello que esta investigación se centra en >>>>> > analizar varios interrogantes relacionados con la persistencia de los >>>>> > objetos, interrogantes que se presentan al momento de querer grabar el grafo >>>>> > de objetos que representa el modelo desarrollado. >>>>> > Para poder responder estos interrogantes, se desarrolló un controlador de >>>>> > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo >>>>> > que brinda compatibilidad con otros sistemas operativos y con el entorno >>>>> > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>>>> > métodos y se avanza hacia el grabado de la imagen, característica que aún no >>>>> > estaba disponible en el sistema. >>>>> > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era >>>>> > la simplicidad y su principal desventaja el requerir una utilización >>>>> > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >>>>> > el primer paso para lograr la atomicidad necesaria para grabar los objetos >>>>> > mientras estos estaban siendo modificados. >>>>> > Finalmente, se implementó un esquema de manejo de memoria basado en >>>>> > paginación, modificando el mecanismo de manejo de interrupciones original de >>>>> > SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>>>> > indispensable para resolver los fallos de página. Esta solución >>>>> > permitió resolver los fallos de página completamente desde Smalltalk, lo >>>>> > cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>>>> > utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>>>> > implementar una técnica alternativa de persistencia de la imagen, que >>>>> > utiliza mucha menos memoria que la original debido a la asistencia del >>>>> > mecanismo de paginación y la utilización de la técnica de copy on write. >>>>> > Por último, se analizan aspectos relacionados con la manera de trabajar en >>>>> > este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>>>> > complicaciones. >>>>> >>>>> > -- >>>>> > Hernán Wilkinson >>>>> > Agile Software Development, Teaching & Coaching >>>>> > Mobile: +54 - 911 - 4470 - 7207 >>>>> > email: [hidden email] >>>>> > site: http://www.10Pines.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 >>>> >>>> -- >>>> 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 > > > > -- > " 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 -- To post to this group, send email to [hidden email] To unsubscribe from this group, send email to [hidden email] http://www.clubSmalltalk.org |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Guillermo Schwarz
> ¿Y cómo determinas cuando lso JIT pueden correr en paralelo y cuando no?
> Una manera trivial de hacer eso sería tener varias VMs corriendo > simultáneamente y comunicarlas mediante sockets. Si, tan trivial que se llama GemStone y existe hace ~25 años. Si esto es en la misma maquina, podes usar memoria shareada con transacciones y asi no tenes que usar TCP/IP... > Por ejemplo tener una VM > para el filesystem, una para la pantalla, otra para los dispositivos, otra > para cada aplicación, etc. Cuando quieres comunicarlas, necesariamente > invocan a otra que recibe mensajes mediante sockets. La ventaja de los > sockets es que naturalmente funcionan como una cola y serializan los > mensajes desde el punto de vista del receptor. La desventaja es, me parece, el throughput, el overhead de usar TCP/IP en vez de (esencialmente) memcpy() (y acordate de la fragmentacion de paquetes, blah blah blah), y tener que serializar todo. Si tenes memoria shareada, entonces no hay que serializar. Serializar y des-serializar es costoso. > Separar dentro de una misma VM varios espacios de objetos me parece > innecesariamente complejo. Si queres hacer un fork, crear otro thread seria mucho mas rapido que levantar otro proceso de maquina virtual. 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
Ah, había entendido otra cosa. Pensé que solamente querías JITear en
paralelo, y por eso me había parecido que con una especie de Breadth-first podía llegar a andar 2011/6/27 Andres Valloud <[hidden email]>: > Yh, porque hay pila de cosas que se rompen inmediatamente si haces > eso. Ademas, primero habria que programar que los objetos esten > realmente separados, asi que habria que reprogramar todo el memory > manager de nuevo (allocations, gc, los RTs, etc). Ademas, estaria > bueno que se pudiera compartir el perm space, pero entonces hay que > programar mas aun... etc etc etc... y despues de eso hay que ver como > reacciona la imagen si por ejemplo permitis que todas las primitivas > sean concurrentes. Por ejemplo, que pasa si dos threads tratan de > abrir un archivo al mismo tiempo. O que pasa cuando alguna de las > imagenes dice primSnapshot. O Delay wait:. Etc etc etc... es un > rebardo. Y ademas esa clase de cambios te va a exponer a todas las > suposiciones con que el codigo esta escrito que se invalidan y > entonces todo se rompe inmediatamente o... gulp... "appears to > work"... > > 2011/6/27 Javier Burroni <[hidden email]>: >> Hola, >> >> 2011/6/27 Andres Valloud <[hidden email]>: >>> Grrr... posta que cuando pueda deberia tratar de trabajar en esto... >>> te imaginaras que si hay espacios de objetos entonces podes poner JITs >>> a correr en paralelo porque no hay conflicto posible... bueh. Ahora >>> cuando termine con el tema de los bugs del GC, punto flotante y >>> hashing (estos que comente en otro mail), deberia empezar a hacer >>> lobby para trabajar en esto. Estaria *muy* bueno... >> pregunto (es un problema que me da curiosidad, pero no se la >> respuesta): ¿Por que no se puede tener ahora JITs en paralelo, para >> ciertos casos? Por ejemplo, estas mandando un mensaje a un objeto, y >> JITeas ese mensaje para ese receptor, y los mensaje que se le envían a >> self en ese método (preemtivamete). Creo que habíamos estado hablando >> sobre algo así en la ultima Smalltalks >>> >>> 2011/6/27 Andres Valloud <[hidden email]>: >>>> Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una >>>> separacion real entre los espacios de objetos, y que la maquina >>>> virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" >>>> un espacio de objetos desde otro espacio de objetos. Estas >>>> facilidades estan buenas porque por ejemplo hoy el debugger del >>>> Smalltalk de turno sera muy bueno y todo lo que quieras pero es >>>> imposible debuggear codigo arbitrario --- justamente porque la imagen >>>> no puede partirse en dos, una parte observada y otra parte que >>>> observa. Pero si el debugger estuviera en una imagen y el coso que >>>> estas debuggeando estuviera en otra imagen, entonces no habria >>>> problema y podrias debuggear por ejemplo la tabla de simbolos sin >>>> colgar la imagen mientras estas adentro de aSemaphore critical: [... >>>> blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la >>>> GUI usando la GUI para el debugger... >>>> >>>> 2011/6/27 pocho <[hidden email]>: >>>>> Este tema de la metacircularidad es más que interesante. Hay un paper >>>>> que viene justo al caso de lo que mencionabas: >>>>> >>>>> Object Spaces for Safe Image Surgery >>>>> http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf >>>>> >>>>> que probablemente sea un camino a investigar en el futuro >>>>> >>>>> Saludos, >>>>> Javier. >>>>> >>>>> On Jun 24, 7:00 pm, Andres Valloud <[hidden email]> wrote: >>>>>> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >>>>>> pero sin tener que usar page faults... o sea, vaciar un espacio de >>>>>> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >>>>>> sin grabar los objetos nuevos que se van creando para grabar la >>>>>> imagen). >>>>>> >>>>>> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >>>>>> tener todo en la imagen, y pretender que la imagen resuelva toda clase >>>>>> de metaproblemas circulares de manera imperativa, a la larga es una >>>>>> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >>>>>> problemas que tienen muchisimo que ver con esto, y la verdad me >>>>>> encantaria no tener que andar preocupandome de como voy a hacer la >>>>>> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >>>>>> hacer los usuarios para deshacer los cambios si prefieren el codigo >>>>>> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >>>>>> problemas que no son faciles, y quiza por eso mas o menos divertidos >>>>>> de resolver porque al final cuando te salen decis "ja, groso!"... >>>>>> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >>>>>> resolver TODOS los problemas metacirculares una vez y para siempre. >>>>>> >>>>>> 2011/6/24 Hernan Wilkinson <[hidden email]>: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > por si les interesa... >>>>>> >>>>>> > ---------- Forwarded message ---------- >>>>>> > From: Hernan Wilkinson <[hidden email]> >>>>>> > Date: 2011/6/24 >>>>>> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>>>> > To: docentes <[hidden email]>, alumnos <[hidden email]> >>>>>> >>>>>> > Defensa de Tesis de Licenciatura >>>>>> > Aula 2, Pab I, 1ro de Julio de 2011, de 17hrs. a 18hrs. >>>>>> > Título: Persistencia en SqueakNOS >>>>>> > Alumnos: Guido Chari y Javier Pimás >>>>>> > Directores: Hernán Wilkinson y Gerardo Richiarte >>>>>> > Jurado: Máximo Prieto y Gabriela Arevalo. >>>>>> > Resumen: >>>>>> > SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema >>>>>> > Operativo" dentro del dialecto Squeak del lenguaje de programación >>>>>> > Smalltalk. >>>>>> > La filosofía de SqueakNOS establece que el desarrollo del mismo debe hacerse >>>>>> > completamente en Smalltalk, utilizando código de bajo nivel únicamente en >>>>>> > los casos en que no sea posible utilizar Smalltalk o que el deterioro de >>>>>> > rendimiento sea extremadamente ostensible. >>>>>> > El proyecto es un trabajo aún en desarrollo, y como tal, varias >>>>>> > funcionalidades comunes a los Sistemas Operativos no han sido implementadas >>>>>> > aún debido a su complejidad. Es por ello que esta investigación se centra en >>>>>> > analizar varios interrogantes relacionados con la persistencia de los >>>>>> > objetos, interrogantes que se presentan al momento de querer grabar el grafo >>>>>> > de objetos que representa el modelo desarrollado. >>>>>> > Para poder responder estos interrogantes, se desarrolló un controlador de >>>>>> > discos ATA y un modelo de filesystem FAT32 completamente en Smalltalk, lo >>>>>> > que brinda compatibilidad con otros sistemas operativos y con el entorno >>>>>> > Squeak genérico. Así por ejemplo, se logra acceder al código fuente de los >>>>>> > métodos y se avanza hacia el grabado de la imagen, característica que aún no >>>>>> > estaba disponible en el sistema. >>>>>> > Luego, se desarrolló una técnica de persistencia cuyo objetivo principal era >>>>>> > la simplicidad y su principal desventaja el requerir una utilización >>>>>> > importante y de manera ineficaz de memoria. A pesar de sus desventajas, fue >>>>>> > el primer paso para lograr la atomicidad necesaria para grabar los objetos >>>>>> > mientras estos estaban siendo modificados. >>>>>> > Finalmente, se implementó un esquema de manejo de memoria basado en >>>>>> > paginación, modificando el mecanismo de manejo de interrupciones original de >>>>>> > SqueakNos para que pudiera funcionar en forma sincrónica, requisito >>>>>> > indispensable para resolver los fallos de página. Esta solución >>>>>> > permitió resolver los fallos de página completamente desde Smalltalk, lo >>>>>> > cual dio lugar a la experimentación y al desarrollo de formas novedosas de >>>>>> > utilización del mismo. Gracias a esto, resultó posible por ejemplo, >>>>>> > implementar una técnica alternativa de persistencia de la imagen, que >>>>>> > utiliza mucha menos memoria que la original debido a la asistencia del >>>>>> > mecanismo de paginación y la utilización de la técnica de copy on write. >>>>>> > Por último, se analizan aspectos relacionados con la manera de trabajar en >>>>>> > este tipo de entornos y plataformas, sus ventajas, sus dificultades y >>>>>> > complicaciones. >>>>>> >>>>>> > -- >>>>>> > Hernán Wilkinson >>>>>> > Agile Software Development, Teaching & Coaching >>>>>> > Mobile: +54 - 911 - 4470 - 7207 >>>>>> > email: [hidden email] >>>>>> > site: http://www.10Pines.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 >>>>> >>>>> -- >>>>> 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 >> >> >> >> -- >> " 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 > > -- > 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 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Andres Valloud-5
2011/6/27 Andres Valloud <[hidden email]>
Buenio GemStone no es open source, de modo que no sabemos cómo implementa las transacciones. En el caso de las bases de datos relacionales, todos los objetos "tocados" o "vistos" por una transacción son considerados como bloqueados o versionados, dependiendo del modo en que la base de datos logra la sincronización.
imagino que GemStone podría hacer lo mismo con los objetos que viven dentro de su imagen (de todas formas uno podría considerar que una base de datos relacional también es una VM con objetos viviendo dentro, si al fin y al cabo una BD relacional requiere de un proceso activo en RAM al igual que una VM).
Claro de 10 a 100 veces más lento, pero por otro lado, ¿cuál es el objetivo de una BD local? Desde hace 15 años que todas las BD son remotas con la tecnología cliente/servidor.
Si lo que quieres es tener tecnología cliente/servidor pero con la velocidad de un servidor local, debes usar cachés, buffers, etc. Eso lo hacen los drivers de BD de todas maneras. (y acordate de la fragmentacion de Eso es como de principios de los 90's. Hoy en día es normal tener en tu casa 6 Gb. En 10 años más será normal bajar películas "on demand". y tener que serializar todo. Si tenes Pero casi todo lo que hacemos "serializa". Hoy en día hasta mandar fotos de un dispositivo celular es rápido y supongo que en 10 años más hasta enviar video por celular será rápido.
Serializar y Creo que depende de la aplicación que estemos hablando. Incluso supongo que uno podría tener objetos "siempre serializados" de mod oque el caso de uso más común, serializar, sea rápido, mientras que lo menos común y que menos demora, hacer cálculos internos, tenga que recorrer el objeto serializado para hacer el cálculo. Puedo estar equivocado, pero la RAM será tan barata que mantener los objetos con ambas representaciones "serializado y no serializado" debería ser barato también.
MMmhh, sí eso ví en el paper que mandaron. Se ve genial. Ahora bien crear un thread es llamar a createThread y crear un nuevo proceso es llamar a fork(). Fork es más caro, pero siempre puedes llamar a vfork() que es tan rápido como createThread.
-- 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
> Buenio GemStone no es open source, de modo que no sabemos cómo implementa
> las transacciones. Si bueno, Oracle y Windows tampoco son open source, no se que tiene que ver. > En el caso de las bases de datos relacionales, todos los objetos "tocados" o > "vistos" por una transacción son considerados como bloqueados o versionados, > dependiendo del modo en que la base de datos logra la sincronización. > imagino que GemStone podría hacer lo mismo con los objetos que viven dentro > de su imagen (de todas formas uno podría considerar que una base de datos > relacional también es una VM con objetos viviendo dentro, si al fin y al > cabo una BD relacional requiere de un proceso activo en RAM al igual que una > VM). En vez de imaginar, creo que es mejor que mires GemStone :). > Claro de 10 a 100 veces más lento, pero por otro lado, ¿cuál es el objetivo > de una BD local? Desde hace 15 años que todas las BD son remotas con la > tecnología cliente/servidor. Pero no estabamos hablando de una BD local... el tema es que la comunicacion via sockets y que se yo ya esta implementada, se llama GemStone. Tambien podes usar la version que ni siquiera tiene base de datos, se llama GemFire. La cuestion es que, para una imagen con varios object spaces, esta mejor no usar sockets porque estas asumiendo que todos los object spaces estan en el mismo address space (basicamente). > Pero casi todo lo que hacemos "serializa". Hoy en día hasta mandar fotos de > un dispositivo celular es rápido y supongo que en 10 años más hasta enviar > video por celular será rápido. Si, y es lento. Por supuesto esta bueno hacer que el software sea ineficiente asi necesitas un procesador mas rapido blah blah blah... > Creo que depende de la aplicación que estemos hablando. Incluso supongo que > uno podría tener objetos "siempre serializados" de mod oque el caso de uso > más común, serializar, sea rápido, mientras que lo menos común y que menos > demora, hacer cálculos internos, tenga que recorrer el objeto serializado > para hacer el cálculo. Puedo estar equivocado, pero la RAM será tan barata > que mantener los objetos con ambas representaciones "serializado y no > serializado" debería ser barato también. Acordate que en los CPUs de hoy en dia, importa un monton no usar memoria al divino boton porque acceder RAM es lentisimo comparado con los caches etc. >> > Separar dentro de una misma VM varios espacios de objetos me parece >> > innecesariamente complejo. >> >> Si queres hacer un fork, crear otro thread seria mucho mas rapido que >> levantar otro proceso de maquina virtual. > > MMmhh, sí eso ví en el paper que mandaron. Se ve genial. Ahora bien crear un > thread es llamar a createThread y crear un nuevo proceso es llamar a fork(). > Fork es más caro, pero siempre puedes llamar a vfork() que es tan rápido > como createThread. Nono, no fork(), fork de Smalltalk. Y llamar a fork() / vfork() sera rapidisimo y todo lo que quieras, pero inicializar una VM tarda tiempo asi que la latencia para cosas rapidas que se benefician al usar multicore seria un problema serio. Empezar otro thread JIT (basicamente) es muchisimo mas rapido que levantar una VM desde cero. 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 |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |