Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
Locked
123
123
Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
 
|
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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
Hernán,
Què interesante. La ùnica duda que me surgió es si al hacerlo sìncrono significa que la imagen Smalltalk queda suspendida hasta que se resuelve o bien que otros threads de la misma imagen pueden seguir ejecutando mientras tanto. Todo esto lo pregunto porque resolver un acceso a disco con la tecnología actual (sin SSD) es del orden de entre 10 y 100 veces más caro que un acceso a RAM.
-- Saludos, Guillermo. 2011/6/24 Hernan Wilkinson <[hidden email]> por si les interesa... -- 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
|
|
pero no es un problema trivial para vos?
2011/6/24 Guillermo Schwarz <[hidden email]> Hernán, -- 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 hernan.wilkinson
Que alegría de escuchar un trabajo así con SqueakNOS. Es un proyecto realmente interesante, que deshace el viejo concepto de sistema operativo y archivos.
Hay algo más de info, y en ingles, como para publicarla en el sitio? Gracias Saludos, Hernán.- 2011/6/24 Hernan Wilkinson <[hidden email]> por si les interesa... -- 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
|
|
Gente:
Una pregunta. En el resumen dice: SqueakNOS es una reificación de los conceptos de "Computadora" y de "Sistema Operativo" dentro del dialecto Squeak del lenguaje de programación Smalltalk. Porque entonces no le cambian el nombre a SqueakOS ? Saludos GallegO El día 24 de junio de 2011 17:38, Hernán Galante <[hidden email]> escribió: > Que alegría de escuchar un trabajo así con SqueakNOS. Es un proyecto > realmente interesante, que deshace el viejo concepto de sistema operativo y > archivos. > Hay algo más de info, y en ingles, como para publicarla en el sitio? > Gracias > > Saludos, > Hernán.- > > 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
|
|
por que la idea es que por más que SquakNos tenga algún comportamiento similar a un SO no lo sea realmente... o por lo menos por lo que clasicamente conocemos como SO.
2011/6/24 GallegO <[hidden email]> Gente: -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Guillermo Schwarz
Cuando se graba la imagen, como en todo smalltalk común, la misma se freeza. Pero uno de los grandes problemas que tuvieron que resolver los chicos fue el tema de la circularidad... o sea, como grabar los objetos que graban? :-)
2011/6/24 Guillermo Schwarz <[hidden email]> Hernán, -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by Guillermo Schwarz
Hola Guillermo,
La sincronicidad tiene que ver con la atencion de interrupciones. SqueakNOS previo a nuestro trabajo atendia todas las interrupciones de hardware de manera asincronica. A bajo nivel se signalea un semaforo de alto nivel y se retomo el curso de ejecucion anterior, el cual ingresa a la vm y en ese momento la interrupcion es atendida desde Smalltalk, Esto no era posible para resolver fallos de pagina, ya que de no resolverse la interrupcion de hardware "en el momento" el procesador no puede seguir su curso de ejecucion. Sin embargo esto no quiere decir que la imagen queda suspendida ya que el fallo de pagina se resuelve desde Smalltalk.
Saludos, Guido. El 24 de junio de 2011 17:18, Guillermo Schwarz <[hidden email]> escribió: Hernán, 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 Hernan Wilkinson-3
Gallego, diste en la tecla...
Richie, uno de los creadores de SqueakNOS, disiente un poco con esa frase que pusimos nosotros. Para ser mas exactos, no se reifica sistema operativo, pero si muchos de sus componentes. Algunos pueden verlo como un sistema operativo, otros no. Hay para debatir al respecto...Igualmente, cualquier sugerencia de cambio de nombre deberia ser dirigida a Gera que es el fundador.
Como nota de color..hay un proyecto similar en Java, que se llama JavaOS. Ya solo por hacerles la contra dejaria el NOS.. :P Saludos, Guido.
El 24 de junio de 2011 18:05, Hernan Wilkinson <[hidden email]> escribió: por que la idea es que por más que SquakNos tenga algún comportamiento similar a un SO no lo sea realmente... o por lo menos por lo que clasicamente conocemos como SO. 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 Hernan Wilkinson-3
Que mal che, yo tenia la esperanza de sacar el SqueakOS para alguna
tablet que se venda a millones y así hacernos populares. Vamos a tener que esperar la próxima ola ;) Saludos El día 24 de junio de 2011 18:05, Hernan Wilkinson <[hidden email]> escribió: > por que la idea es que por más que SquakNos tenga algún comportamiento > similar a un SO no lo sea realmente... o por lo menos por lo que > clasicamente conocemos como SO. > > 2011/6/24 GallegO <[hidden email]> >> >> Gente: >> >> Una pregunta. >> >> En el resumen dice: >> SqueakNOS es una reificación de los conceptos de "Computadora" y de >> "Sistema Operativo" dentro del dialecto Squeak del lenguaje de >> programación Smalltalk. >> >> Porque entonces no le cambian el nombre a SqueakOS ? >> >> Saludos >> GallegO >> >> El día 24 de junio de 2011 17:38, Hernán Galante >> <[hidden email]> escribió: >> > Que alegría de escuchar un trabajo así con SqueakNOS. Es un proyecto >> > realmente interesante, que deshace el viejo concepto de sistema >> > operativo y >> > archivos. >> > Hay algo más de info, y en ingles, como para publicarla en el sitio? >> > Gracias >> > >> > Saludos, >> > Hernán.- >> > >> > 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 > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: [hidden email] > site: http://www.10Pines.com > Address: Paraguay 523, Floor 7 N, 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 |
Re: Fwd: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
|
|
In reply to this post by hernan.wilkinson
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
|
|
In reply to this post by Hernan Wilkinson-3
Hernán,
Está bueno, creo que no es factible solucionarlo en Smalltalk dado como se manejan las tareas.
-- En Java, cuando habìan GreenThreads en vez de threads del sistema operativo pasaba lo mismo y lo resolvieron justamente usando threads del sistema operativo.
Lo que encuentro interesante del asunto es que el modelo de programación en Smalltalk es lineal, como si los threads/tareas no existieran, a excepción del "yield" ocasional que dice "ahora sí me pueden interrumpir". Otro modelo similar pero sin yield es el de los EJBs. Lo interesante es que en el mnundo J2EE se prohibe el uso de threads y de sincronización, sin embargo por debajo todo corre con threads, de modo que se podrìa decir que un programador de EJBs es un progrmador de Smalltalk que actúa de manera completamente ignorante de que por debajo todo ejecuta en paralelo, y eso es posible porque no puede ocupar un singleton (que serìa la memoria compartida), ni ocupar synchronized ni nada de eso, sino que todo debe pasar por la base de datos.
Ahora bien, la base de datos es un sistema más. Si lo tienes programado por ejemplo en H2, todo sigue estando en Java y ejecutando en threads, de modo que ¿còmo se resuelven los temas de sincronización? Lo ùnco que has hecho es trasladar el problema del espacio Java de los EJBs al espacio de las transacciones en BD, pero sigue siendo el mismo problema y sigue siendo un problema a resolver en Java... y está resuelto. ¿Cómo lo hace entonces?
Entonces te encuentras con que en el mundo de las BD este tema tiene 2 modos de resolución: 1. El sistema típico que pasan introducción a las BD en la U en el que se bloquean los registros de las tablas y en caso de deadlock se mata una transacción y luego se rehace, o bien se establece un orden por tabla y por registro para tomar locks y evitar los deadlocks.
2. El sistema que no es tan típico pero que es más eficiente, conocido como versionamiento de registros o lock free synchronization, en los que se minimiza el uso de locks (en el tiempo y en el espacio), de modo que casi nunca se topan 2 locks y cuando se topan, se sigue la misma estrategia del punto 1.
De ahí tengo la intuición que debería poder hacerse algo parecido en Smalltalk, sòlo que deberìa ser necesario construir un modelo de programación similar a EJB SLSB (Stateless Session Beans) en la que el estado se maneje en una BD necesariamente, y luego esa BD sea implementada de nuevo en Smalltalk con transacciones con lock free synchronization.
La experiencia que he tenido con los EJBs es que si los haces funcionar así funcionan rapidísimo y es muy escalable, quizás no tanto como Terracotta (acá hablan de 80 mil transacciones por segundo http://www.theserverside.com/news/1364132/Terracottas-Scalability-Story), pero sigue siendo impresionante.
Saludos, Guillermo. 2011/6/24 Hernan Wilkinson <[hidden email]> Cuando se graba la imagen, como en todo smalltalk común, la misma se freeza. Pero uno de los grandes problemas que tuvieron que resolver los chicos fue el tema de la circularidad... o sea, como grabar los objetos que graban? :-) -- 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
|
|
Usaste GemStone?
2011/6/24 Guillermo Schwarz <[hidden email]>: > Hernán, > Está bueno, creo que no es factible solucionarlo en Smalltalk dado como se > manejan las tareas. > En Java, cuando habìan GreenThreads en vez de threads del sistema operativo > pasaba lo mismo y lo resolvieron justamente usando threads del sistema > operativo. > Lo que encuentro interesante del asunto es que el modelo de programación en > Smalltalk es lineal, como si los threads/tareas no existieran, a excepción > del "yield" ocasional que dice "ahora sí me pueden interrumpir". Otro modelo > similar pero sin yield es el de los EJBs. Lo interesante es que en el mnundo > J2EE se prohibe el uso de threads y de sincronización, sin embargo por > debajo todo corre con threads, de modo que se podrìa decir que un > programador de EJBs es un progrmador de Smalltalk que actúa de manera > completamente ignorante de que por debajo todo ejecuta en paralelo, y eso es > posible porque no puede ocupar un singleton (que serìa la memoria > compartida), ni ocupar synchronized ni nada de eso, sino que todo debe pasar > por la base de datos. > Ahora bien, la base de datos es un sistema más. Si lo tienes programado por > ejemplo en H2, todo sigue estando en Java y ejecutando en threads, de modo > que ¿còmo se resuelven los temas de sincronización? Lo ùnco que has hecho es > trasladar el problema del espacio Java de los EJBs al espacio de las > transacciones en BD, pero sigue siendo el mismo problema y sigue siendo un > problema a resolver en Java... y está resuelto. ¿Cómo lo hace entonces? > Entonces te encuentras con que en el mundo de las BD este tema tiene 2 modos > de resolución: > 1. El sistema típico que pasan introducción a las BD en la U en el que se > bloquean los registros de las tablas y en caso de deadlock se mata una > transacción y luego se rehace, o bien se establece un orden por tabla y por > registro para tomar locks y evitar los deadlocks. > 2. El sistema que no es tan típico pero que es más eficiente, conocido como > versionamiento de registros o lock free synchronization, en los que se > minimiza el uso de locks (en el tiempo y en el espacio), de modo que casi > nunca se topan 2 locks y cuando se topan, se sigue la misma estrategia del > punto 1. > De ahí tengo la intuición que debería poder hacerse algo parecido en > Smalltalk, sòlo que deberìa ser necesario construir un modelo de > programación similar a EJB SLSB (Stateless Session Beans) en la que el > estado se maneje en una BD necesariamente, y luego esa BD sea implementada > de nuevo en Smalltalk con transacciones con lock free synchronization. > La experiencia que he tenido con los EJBs es que si los haces funcionar así > funcionan rapidísimo y es muy escalable, quizás no tanto como Terracotta > (acá hablan de 80 mil transacciones por > segundo http://www.theserverside.com/news/1364132/Terracottas-Scalability-Story), > pero sigue siendo impresionante. > Saludos, > Guillermo. > 2011/6/24 Hernan Wilkinson <[hidden email]> >> >> Cuando se graba la imagen, como en todo smalltalk común, la misma se >> freeza. Pero uno de los grandes problemas que tuvieron que resolver los >> chicos fue el tema de la circularidad... o sea, como grabar los objetos que >> graban? :-) >> >> 2011/6/24 Guillermo Schwarz <[hidden email]> >>> >>> Hernán, >>> Què interesante. La ùnica duda que me surgió es si al hacerlo sìncrono >>> significa que la imagen Smalltalk queda suspendida hasta que se resuelve o >>> bien que otros threads de la misma imagen pueden seguir ejecutando mientras >>> tanto. Todo esto lo pregunto porque resolver un acceso a disco con la >>> tecnología actual (sin SSD) es del orden de entre 10 y 100 veces más caro >>> que un acceso a RAM. >>> Saludos, >>> Guillermo. >>> >>> 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 >>> >>> >>> -- >>> 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 >> >> >> -- >> Hernán Wilkinson >> Agile Software Development, Teaching & Coaching >> Mobile: +54 - 911 - 4470 - 7207 >> email: [hidden email] >> site: http://www.10Pines.com >> Address: Paraguay 523, Floor 7 N, 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 > > > -- > 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 -- 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
Hola gente!
Hmmm.... sigue siendo lineal en Smalltalk el tema "threads"? Pense que ya en estos anios cada Processor (disculpen, no conozco el termino exacta), se ejecutaba en un thread de usuario por lo menos. Cuales Smalltalk (implementaciones) hacen eso? Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2011/6/24 Guillermo Schwarz <[hidden email]> Hernán, -- 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
> Está bueno, creo que no es factible solucionarlo en Smalltalk dado como se
> manejan las tareas. Fijate mejor, en la tesis hay una solucion y acabo de escribir otra hace un ratito. -- 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
Hola GUido, Primero que nada felicitaciones. NO he visto còmo lo hicieron pero debe ser fascinante. Claro desde el punto de vista de mirar el código uno ve: primero ejecuta esto, la memoria accedida no está en RAM sino en disco, se produce una interrupciòn y ejecuta código Smalltalk para rescatar la página del disco, de modo que está todo el tiempo ejecutando SMaltlalk, pero si se pudiera graficar cuànto tiempo ejecuta Smalltalk durante el proceso, la mayor parte del tiempo està leyendo del disco, es decir, la CPU està desocupada (ok en un OS moderno probablemente hay 20 procesos haciendo cosas inùtiles), pero en SqueakNOS no habría nada ejecutando nada, a menos que SqueakNOS tenga un modelo de varias imágenes ejecutando simultáneamente, algo parecido a lo que sería un hypervisor, que por cierto creo que sería una buena idea para ejecutar SqueakNOS.
Saludos, Guillermo.
-- 2011/6/24 Guido Chari <[hidden email]> Hola Guillermo, -- 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
Hola Andres, como andas?
El 24 de junio de 2011 19:00, Andres Valloud <[hidden email]> escribió: Ah, mira vos... pense que al final lo habian resuelto desde la imagen Esta fue la idea que surgió charlando con gente en la ultima Smalltalks y a partir de haber conocido un poco mas sobre garbage collector general y sobre el gc de la vm de squeak particularmente. Sin embargo, al hacer la prueba y poner toda la imagen en readonly menos el "eden" vimos que se generaban pagefaults. Esto nos dio la pauta que habia cosas en la parte freezada que se estaban modificando y podian generar inconsistencias. Metiendonos un poquito mas adentro vimos varios casos que hacen que se modifiquen objetos en el medio del proceso de grabado. En este momento me acuerdo por ejemplo del gc, semaforos internos que generan cambio de contexto en la imagen, etc. Con lo cual este camino resulto insatisfactorio, porque era muy complicado llegar a probar que estos cambios no iban a generar una imagen con propiedades distintas a la requerida.
En esta parte no te logro seguir del todo. Nuestro desarrollo y los problemas que surgieron no tuvieron una relacion tan directa con la metacircularidad. Si, intentamos llevar lo mas posible del lado de la imagen pero los resultados nos parecen bastante buenos. Por ejemplo, el tener modelado un administrador de memoria en alto nivel, nos permitio utilizar la paginacion para implementar copy on write de manera directa y haciendo un uso intensivo de las herramientas que provee el procesador. Sin embargo el modelo esta casi completamente hecho en smalltalk.
Saludos, Guido. 2011/6/24 Hernan Wilkinson <[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 Andres Valloud-5
Andres,
Yo nunca. No sé si hay una versión gratuita.
-- Saludos, Guillermo. 2011/6/24 Andres Valloud <[hidden email]> Usaste GemStone? -- 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 Guido Chari
> Esta fue la idea que surgió charlando con gente en la ultima Smalltalks y a
> partir de haber conocido un poco mas sobre garbage collector general y sobre > el gc de la vm de squeak particularmente. Sin embargo, al hacer la prueba y > poner toda la imagen en readonly menos el "eden" vimos que se generaban > pagefaults. Esto nos dio la pauta que habia cosas en la parte freezada que > se estaban modificando y podian generar inconsistencias. Metiendonos un > poquito mas adentro vimos varios casos que hacen que se modifiquen objetos > en el medio del proceso de grabado. En este momento me acuerdo por ejemplo > del gc Y si, mientras se graba la imagen no podria haber GC, asi que habria que tener mucho cuidado con la manera en que estuviera escrito. Ademas, tampoco se podrian crear referencias a objetos nuevos desde objetos viejos porque entonces habria que cambiar el RT. Debe haber mas de estas. > semaforos internos que generan cambio de contexto en la imagen, etc. Ahh, esto es molesto. Por ejemplo, esta el semaforo de los delays. En VW existe la manera de registrar objetos con la VM. Si quisiera seguir este camino, entonces habria que hacer mas laburo. Basicamente, la imagen tendria que tener modos de ejecucion diferentes donde por ejemplo se pueda decir cosas como "durante este tiempo no hay delays". Esto en VW no seria imposible (ojo que ni ahi estoy diciendo que sea "facil") ya que esta modelado el tema de los subsistemas. Entonces, al grabar la imagen, tendrias que cambiar el modo de ejecucion, grabar, y despues volver al modo "developer". > Con lo cual este camino resulto insatisfactorio, porque era muy complicado > llegar a probar que estos cambios no iban a generar una imagen con > propiedades distintas a la requerida. Y si, este es un problema porque como sabes el codigo que esta en la imagen y que es lo que esta haciendo? Por ejemplo, se puede grabar la imagen mientras el MessageTally esta midiendo al proceso que graba la imagen? A esta clase de cosas iba con lo que dije despues... > En esta parte no te logro seguir del todo. Nuestro desarrollo y los > problemas que surgieron no tuvieron una relacion tan directa con la > metacircularidad. Si, intentamos llevar lo mas posible del lado de la imagen > pero los resultados nos parecen bastante buenos. Por ejemplo, el tener > modelado un administrador de memoria en alto nivel, nos permitio utilizar la > paginacion para implementar copy on write de manera directa y haciendo un > uso intensivo de las herramientas que provee el procesador. Sin embargo el > modelo esta casi completamente hecho en smalltalk. Quiza funciona hoy, pero mañana? Se puede demostrar que este mecanismo funciona en presencia de codigo y objetos arbitrarios en la imagen? Y si no se puede, entonces no conviene que el mecanismo no este en *la misma imagen*? En general eso se pone en la VM, pero tambien podria estar en otra imagen (como dice Guillermo con lo del modo "hypervisor", aunque habria que pensarlo mas --- por ejemplo habria que ir tipo a 1996 y ver que querian hacer los de Digitalk con Firewall --- y desde ya ni siquiera se puede hablar de que esto es un problema simplemente "dificil"). Aca hay un par de problemas mas modestos. El primero es que hay que cambiar identityHash. Eso quiere decir que por ejemplo cambia el lookup de namespaces mientras la imagen sigue corriendo. Como se hace la cirugia de cerebro para que no se rompa todo? Y como se demuestra que es correcto en presencia de codigo y objetos arbitrarios? El segundo es que hay que cambiar el printString de numeros de punto flotante. En particular, hay que cambiar la cantidad de cifras, y las cifras mismas. Fijate lo que pasa si haces algo como esto: Double pi = (Double readFrom: Double pi printString readStream) Da false (!!!). Pero, sin embargo, Double pi printString = (Double readFrom: Double pi printString readStream) printString es true (!!!). Cuantas veces nosotros como programadores hicimos copy paste de un workspace y metimos codigo en el browser con numeros de punto flotante? Bueno, todo eso esta probablemente mal. Y tambien es probable que esten mal todos los archivos con numeros de punto flotante escritos con printString (pero en VW el NumberPrintPolicy tambien esta mal para punto flotante por razones diferentes, y entonces te puede pasar que 1234.5 se imprima como 1234.499993). Pero bueno, mal que mal, los programas y los tests pasan. Que pasa si arreglo los numeros de punto flotante? Cuanto se rompen las cosas, mas alla de que el cambio sea necesario? Es aceptable tener que volver a recompilar ***todo*** el codigo que esta publicado en binario? Y como hacen los usuarios para cargar el codigo nuevo (o el viejo) si, entre otras cosas, voy a cambiar como se interpretan los literals en el codigo? 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. 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 Guillermo Schwarz
Si, hay versiones gratuitas.
2011/6/24 Guillermo Schwarz <[hidden email]>: > Andres, > Yo nunca. No sé si hay una versión gratuita. > Saludos, > Guillermo. > > 2011/6/24 Andres Valloud <[hidden email]> >> >> Usaste GemStone? >> >> 2011/6/24 Guillermo Schwarz <[hidden email]>: >> > Hernán, >> > Está bueno, creo que no es factible solucionarlo en Smalltalk dado como >> > se >> > manejan las tareas. >> > En Java, cuando habìan GreenThreads en vez de threads del sistema >> > operativo >> > pasaba lo mismo y lo resolvieron justamente usando threads del sistema >> > operativo. >> > Lo que encuentro interesante del asunto es que el modelo de programación >> > en >> > Smalltalk es lineal, como si los threads/tareas no existieran, a >> > excepción >> > del "yield" ocasional que dice "ahora sí me pueden interrumpir". Otro >> > modelo >> > similar pero sin yield es el de los EJBs. Lo interesante es que en el >> > mnundo >> > J2EE se prohibe el uso de threads y de sincronización, sin embargo por >> > debajo todo corre con threads, de modo que se podrìa decir que un >> > programador de EJBs es un progrmador de Smalltalk que actúa de manera >> > completamente ignorante de que por debajo todo ejecuta en paralelo, y >> > eso es >> > posible porque no puede ocupar un singleton (que serìa la memoria >> > compartida), ni ocupar synchronized ni nada de eso, sino que todo debe >> > pasar >> > por la base de datos. >> > Ahora bien, la base de datos es un sistema más. Si lo tienes programado >> > por >> > ejemplo en H2, todo sigue estando en Java y ejecutando en threads, de >> > modo >> > que ¿còmo se resuelven los temas de sincronización? Lo ùnco que has >> > hecho es >> > trasladar el problema del espacio Java de los EJBs al espacio de las >> > transacciones en BD, pero sigue siendo el mismo problema y sigue siendo >> > un >> > problema a resolver en Java... y está resuelto. ¿Cómo lo hace entonces? >> > Entonces te encuentras con que en el mundo de las BD este tema tiene 2 >> > modos >> > de resolución: >> > 1. El sistema típico que pasan introducción a las BD en la U en el que >> > se >> > bloquean los registros de las tablas y en caso de deadlock se mata una >> > transacción y luego se rehace, o bien se establece un orden por tabla y >> > por >> > registro para tomar locks y evitar los deadlocks. >> > 2. El sistema que no es tan típico pero que es más eficiente, conocido >> > como >> > versionamiento de registros o lock free synchronization, en los que se >> > minimiza el uso de locks (en el tiempo y en el espacio), de modo que >> > casi >> > nunca se topan 2 locks y cuando se topan, se sigue la misma estrategia >> > del >> > punto 1. >> > De ahí tengo la intuición que debería poder hacerse algo parecido en >> > Smalltalk, sòlo que deberìa ser necesario construir un modelo de >> > programación similar a EJB SLSB (Stateless Session Beans) en la que el >> > estado se maneje en una BD necesariamente, y luego esa BD sea >> > implementada >> > de nuevo en Smalltalk con transacciones con lock free synchronization. >> > La experiencia que he tenido con los EJBs es que si los haces funcionar >> > así >> > funcionan rapidísimo y es muy escalable, quizás no tanto como Terracotta >> > (acá hablan de 80 mil transacciones por >> > >> > segundo http://www.theserverside.com/news/1364132/Terracottas-Scalability-Story), >> > pero sigue siendo impresionante. >> > Saludos, >> > Guillermo. >> > 2011/6/24 Hernan Wilkinson <[hidden email]> >> >> >> >> Cuando se graba la imagen, como en todo smalltalk común, la misma se >> >> freeza. Pero uno de los grandes problemas que tuvieron que resolver los >> >> chicos fue el tema de la circularidad... o sea, como grabar los objetos >> >> que >> >> graban? :-) >> >> >> >> 2011/6/24 Guillermo Schwarz <[hidden email]> >> >>> >> >>> Hernán, >> >>> Què interesante. La ùnica duda que me surgió es si al hacerlo sìncrono >> >>> significa que la imagen Smalltalk queda suspendida hasta que se >> >>> resuelve o >> >>> bien que otros threads de la misma imagen pueden seguir ejecutando >> >>> mientras >> >>> tanto. Todo esto lo pregunto porque resolver un acceso a disco con la >> >>> tecnología actual (sin SSD) es del orden de entre 10 y 100 veces más >> >>> caro >> >>> que un acceso a RAM. >> >>> Saludos, >> >>> Guillermo. >> >>> >> >>> 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 >> >>> >> >>> >> >>> -- >> >>> 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 >> >> >> >> >> >> -- >> >> Hernán Wilkinson >> >> Agile Software Development, Teaching & Coaching >> >> Mobile: +54 - 911 - 4470 - 7207 >> >> email: [hidden email] >> >> site: http://www.10Pines.com >> >> Address: Paraguay 523, Floor 7 N, 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 >> > >> > >> > -- >> > 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 >> >> -- >> To post to this group, send email to [hidden email] >> To unsubscribe from this group, send email to >> [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 > [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 |
«
Return to Español (Spanish)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |