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
