(claro que si hubiera diferentes object spaces entonces no importa porque los procesos de un object space no deberian (asi a primera vista) influenciar los procesos de otros object spaces... es decir, seria el mismo modelo de ahora pero en N threads simultaneos y logicamente disjuntos)...
2011/6/27 Andres Valloud <[email protected]>: > Ahh, vos decias compilar a codigo nativo en otro thread. Eso creo que > en general no se puede hacer porque se viola el modelo multithreading > de Smalltalk (por ejemplo, que pasa si colgas un proceso de prioridad > X mientras le compilas metodos a codigo nativo en un thread y mientras > tanto se ejecuta un proceso de prioridad X - 1 en el otro thread). > > 2011/6/27 Javier Burroni <[email protected]>: >> Ah, había entendido otra cosa. Pensé que solamente querías JITear en >> paralelo, y por eso me había parecido que con una especie de >> Breadth-first podía llegar a andar >> >> 2011/6/27 Andres Valloud <[email protected]>: >>> Yh, porque hay pila de cosas que se rompen inmediatamente si haces >>> eso. Ademas, primero habria que programar que los objetos esten >>> realmente separados, asi que habria que reprogramar todo el memory >>> manager de nuevo (allocations, gc, los RTs, etc). Ademas, estaria >>> bueno que se pudiera compartir el perm space, pero entonces hay que >>> programar mas aun... etc etc etc... y despues de eso hay que ver como >>> reacciona la imagen si por ejemplo permitis que todas las primitivas >>> sean concurrentes. Por ejemplo, que pasa si dos threads tratan de >>> abrir un archivo al mismo tiempo. O que pasa cuando alguna de las >>> imagenes dice primSnapshot. O Delay wait:. Etc etc etc... es un >>> rebardo. Y ademas esa clase de cambios te va a exponer a todas las >>> suposiciones con que el codigo esta escrito que se invalidan y >>> entonces todo se rompe inmediatamente o... gulp... "appears to >>> work"... >>> >>> 2011/6/27 Javier Burroni <[email protected]>: >>>> Hola, >>>> >>>> 2011/6/27 Andres Valloud <[email protected]>: >>>>> Grrr... posta que cuando pueda deberia tratar de trabajar en esto... >>>>> te imaginaras que si hay espacios de objetos entonces podes poner JITs >>>>> a correr en paralelo porque no hay conflicto posible... bueh. Ahora >>>>> cuando termine con el tema de los bugs del GC, punto flotante y >>>>> hashing (estos que comente en otro mail), deberia empezar a hacer >>>>> lobby para trabajar en esto. Estaria *muy* bueno... >>>> pregunto (es un problema que me da curiosidad, pero no se la >>>> respuesta): ¿Por que no se puede tener ahora JITs en paralelo, para >>>> ciertos casos? Por ejemplo, estas mandando un mensaje a un objeto, y >>>> JITeas ese mensaje para ese receptor, y los mensaje que se le envían a >>>> self en ese método (preemtivamete). Creo que habíamos estado hablando >>>> sobre algo así en la ultima Smalltalks >>>>> >>>>> 2011/6/27 Andres Valloud <[email protected]>: >>>>>> Claro, por ejemplo esto. Y tambien estaria bueno que hubiera una >>>>>> separacion real entre los espacios de objetos, y que la maquina >>>>>> virtual pudiera ser usada para, por ejemplo, debuggear "remotamente" >>>>>> un espacio de objetos desde otro espacio de objetos. Estas >>>>>> facilidades estan buenas porque por ejemplo hoy el debugger del >>>>>> Smalltalk de turno sera muy bueno y todo lo que quieras pero es >>>>>> imposible debuggear codigo arbitrario --- justamente porque la imagen >>>>>> no puede partirse en dos, una parte observada y otra parte que >>>>>> observa. Pero si el debugger estuviera en una imagen y el coso que >>>>>> estas debuggeando estuviera en otra imagen, entonces no habria >>>>>> problema y podrias debuggear por ejemplo la tabla de simbolos sin >>>>>> colgar la imagen mientras estas adentro de aSemaphore critical: [... >>>>>> blah...]. Y ejemplos asi hay bocha... por ejemplo como debuggear la >>>>>> GUI usando la GUI para el debugger... >>>>>> >>>>>> 2011/6/27 pocho <[email protected]>: >>>>>>> Este tema de la metacircularidad es más que interesante. Hay un paper >>>>>>> que viene justo al caso de lo que mencionabas: >>>>>>> >>>>>>> Object Spaces for Safe Image Surgery >>>>>>> http://www.marcusdenker.de/publications/Casa09aObjectSpaces.pdf >>>>>>> >>>>>>> que probablemente sea un camino a investigar en el futuro >>>>>>> >>>>>>> Saludos, >>>>>>> Javier. >>>>>>> >>>>>>> On Jun 24, 7:00 pm, Andres Valloud <[email protected]> wrote: >>>>>>>> Ah, mira vos... pense que al final lo habian resuelto desde la imagen >>>>>>>> pero sin tener que usar page faults... o sea, vaciar un espacio de >>>>>>>> memoria, y usar objetos ahi para grabar el resto de la imagen (pero >>>>>>>> sin grabar los objetos nuevos que se van creando para grabar la >>>>>>>> imagen). >>>>>>>> >>>>>>>> Mirandolo un poco desde mas lejos, me sigue dando la impresion de que >>>>>>>> tener todo en la imagen, y pretender que la imagen resuelva toda clase >>>>>>>> de metaproblemas circulares de manera imperativa, a la larga es una >>>>>>>> desventaja. Ahora por ejemplo me va a tocar trabajar con dos >>>>>>>> problemas que tienen muchisimo que ver con esto, y la verdad me >>>>>>>> encantaria no tener que andar preocupandome de como voy a hacer la >>>>>>>> cirugia de cerebro en la imagen sin que reviente todo. O como podrian >>>>>>>> hacer los usuarios para deshacer los cambios si prefieren el codigo >>>>>>>> viejo para sus aplicaciones, de nuevo sin que reviente todo. Son >>>>>>>> problemas que no son faciles, y quiza por eso mas o menos divertidos >>>>>>>> de resolver porque al final cuando te salen decis "ja, groso!"... >>>>>>>> aunque cada vez les veo menos la gracia. Capaz que estaria bueno >>>>>>>> resolver TODOS los problemas metacirculares una vez y para siempre. >>>>>>>> >>>>>>>> 2011/6/24 Hernan Wilkinson <[email protected]>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > por si les interesa... >>>>>>>> >>>>>>>> > ---------- Forwarded message ---------- >>>>>>>> > From: Hernan Wilkinson <[email protected]> >>>>>>>> > Date: 2011/6/24 >>>>>>>> > Subject: Defensa de Tesis de Licenciatura - Persistencia en SqueakNOS >>>>>>>> > To: docentes <[email protected]>, alumnos <[email protected]> >>>>>>>> >>>>>>>> > 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: [email protected] >>>>>>>> > site: http://www.10Pines.com >>>>>>>> >>>>>>>> > -- >>>>>>>> > To post to this group, send email to [email protected] >>>>>>>> > To unsubscribe from this group, send email to >>>>>>>> > [email protected] >>>>>>>> >>>>>>>> >http://www.clubSmalltalk.org >>>>>>> >>>>>>> -- >>>>>>> To post to this group, send email to [email protected] >>>>>>> To unsubscribe from this group, send email to >>>>>>> [email protected] >>>>>>> >>>>>>> http://www.clubSmalltalk.org >>>>>> >>>>> >>>>> -- >>>>> To post to this group, send email to [email protected] >>>>> To unsubscribe from this group, send email to >>>>> [email protected] >>>>> >>>>> http://www.clubSmalltalk.org >>>> >>>> >>>> >>>> -- >>>> " To be is to do " ( Socrates ) >>>> " To be or not to be " ( Shakespeare ) >>>> " To do is to be " ( Sartre ) >>>> " Do be do be do " ( Sinatra ) >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> http://www.clubSmalltalk.org >>> >>> -- >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> http://www.clubSmalltalk.org >> >> >> >> -- >> " To be is to do " ( Socrates ) >> " To be or not to be " ( Shakespeare ) >> " To do is to be " ( Sartre ) >> " Do be do be do " ( Sinatra ) >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
