Leer FW: Persistencia en SqueakNOS

>   Resumen del tema de hoy
> Grupo: http://groups.google.com/group/clubsmalltalk/topics
> * Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
> <#group_thread_0>  [25 actualizaciones]
>> Tema: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS
>> <http://groups.google.com/group/clubsmalltalk/t/ea47f40ccd2e67f3>
>>  
>>> Hernan Wilkinson <[hidden email]> Jun 24 04:37PM -0300 ^
>>> <#digest_top>
>>>  
>>>  
>>>  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 <http://www.10pines.com/>
>>> *
>>>  
>>>
>>>  
>>>  
>>>  
>>>> Guillermo Schwarz <[hidden email]> Jun 24 04:18PM -0400 ^
>>>> <#digest_top>
>>>>  
>>>>  
>>>>  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]>
>>>>  
>>>>  
>>>> --
>>>> Saludos cordiales,
>>>>  
>>>> Guillermo Schwarz
>>>> Sun Certified Enterprise Architect
>>>>  
>>>>
>>>>  
>>>>  
>>>>  
>>>>> Francisco Garau <[hidden email]> Jun 24 09:24PM +0100 ^ <#digest_top>
>>>>>  
>>>>>  
>>>>>  pero no es un problema trivial para vos?
>>>>>  
>>>>> 2011/6/24 Guillermo Schwarz <[hidden email]>
>>>>>  
>>>>>  
>>>>>
>>>>>  
>>>>>  
>>>>>  
>>>>>> "Hernán Galante" <[hidden email]> Jun 24 03:38PM -0500 ^
>>>>>> <#digest_top>
>>>>>>  
>>>>>>  
>>>>>>  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]>
>>>>>>  
>>>>>>  
>>>>>>
>>>>>>  
>>>>>>  
>>>>>>  
>>>>>>> GallegO <[hidden email]> Jun 24 05:43PM -0300 ^ <#digest_top>
>>>>>>>  
>>>>>>>  
>>>>>>>  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
>>>>>>>  
>>>>>>>
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>> Hernan Wilkinson <[hidden email]> Jun 24 06:05PM -0300 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]>
>>>>>>>>  
>>>>>>>>  
>>>>>>>> --
>>>>>>>> *Hernán Wilkinson
>>>>>>>> Agile Software Development, Teaching & Coaching
>>>>>>>> Mobile: +54 - 911 - 4470 - 7207
>>>>>>>> email: [hidden email]
>>>>>>>> site: http://www.10Pines.com <http://www.10pines.com/>*
>>>>>>>> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Hernan Wilkinson <[hidden email]> Jun 24 06:07PM -0300 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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 Wilkinson
>>>>>>>> Agile Software Development, Teaching & Coaching
>>>>>>>> Mobile: +54 - 911 - 4470 - 7207
>>>>>>>> email: [hidden email]
>>>>>>>> site: http://www.10Pines.com <http://www.10pines.com/>*
>>>>>>>> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guido Chari <[hidden email]> Jun 24 06:43PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guido Chari <[hidden email]> Jun 24 06:49PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> GallegO <[hidden email]> Jun 24 06:51PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:00PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guillermo Schwarz <[hidden email]> Jun 24 06:02PM -0400 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]>
>>>>>>>>  
>>>>>>>>  
>>>>>>>> --
>>>>>>>> Saludos cordiales,
>>>>>>>>  
>>>>>>>> Guillermo Schwarz
>>>>>>>> Sun Certified Enterprise Architect
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:06PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  Usaste GemStone?
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Angel Java Lopez <[hidden email]> Jun 24 07:06PM -0300 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:07PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>>  > 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.
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guillermo Schwarz <[hidden email]> Jun 24 06:11PM -0400 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  Hola GUido,
>>>>>>>>  
>>>>>>>> Primero que nada felicitaciones. NO he visto còmo lo hicieron pero debe
>>>>>>>> ser
>>>>>>>> fascinante.
>>>>>>>>  
>>>>>>>> Lo que dices, si te entiendo bien, es que es atendida desde Smalltalk,
>>>>>>>> lo
>>>>>>>> que significa que Smalltalk carga la página, ahora bien, esa página
>>>>>>>> está en
>>>>>>>> disco, de modo que hay una petición al hardware para que lea del disco
>>>>>>>> y
>>>>>>>> deje esa información en determinada posición en RAM, lo que implica un
>>>>>>>> buen
>>>>>>>> tiempo sin ejecutar Smaltalk.
>>>>>>>>  
>>>>>>>> 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]>
>>>>>>>>  
>>>>>>>>  
>>>>>>>> --
>>>>>>>> Saludos cordiales,
>>>>>>>>  
>>>>>>>> Guillermo Schwarz
>>>>>>>> Sun Certified Enterprise Architect
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guido Chari <[hidden email]> Jun 24 07:20PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  Hola Andres, como andas?
>>>>>>>>  
>>>>>>>>> > 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).
>>>>>>>>  
>>>>>>>> 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.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>> > 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.
>>>>>>>>  
>>>>>>>> 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.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guillermo Schwarz <[hidden email]> Jun 24 06:31PM -0400 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  Andres,
>>>>>>>>  
>>>>>>>> Yo nunca. No sé si hay una versión gratuita.
>>>>>>>>  
>>>>>>>> Saludos,
>>>>>>>> Guillermo.
>>>>>>>>  
>>>>>>>> 2011/6/24 Andres Valloud <[hidden email]>
>>>>>>>>  
>>>>>>>>  
>>>>>>>> --
>>>>>>>> Saludos cordiales,
>>>>>>>>  
>>>>>>>> Guillermo Schwarz
>>>>>>>> Sun Certified Enterprise Architect
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:45PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>>  > 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...
>>>>>>>>  
>>>>>>>>> > 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.
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:48PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  Si, hay versiones gratuitas.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guido Chari <[hidden email]> Jun 24 07:50PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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]
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 03:55PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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.
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guido Chari <[hidden email]> Jun 24 08:17PM -0300 ^ <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Andres Valloud <[hidden email]> Jun 24 04:26PM -0700 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>>  > Ya que nombraste Newspeak como posible solucion a alguno de los
>>>>>>>>> > problemas...NewspeakNos no? jeje
>>>>>>>>  
>>>>>>>> Y si... por ejemplo...
>>>>>>>>  
>>>>>>>>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  
>>>>>>>> Guillermo Schwarz <[hidden email]> Jun 25 12:19AM -0400 ^
>>>>>>>> <#digest_top>
>>>>>>>>  
>>>>>>>>  
>>>>>>>>  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
>>>>>>>>
>>>>>>>> ------ End of Forwarded Message