Hola Javier, ¿Y cómo determinas cuando lso JIT pueden correr en paralelo y cuando no?
Una manera trivial de hacer eso sería tener varias VMs corriendo simultáneamente y comunicarlas mediante sockets. Por ejemplo tener una VM para el filesystem, una para la pantalla, otra para los dispositivos, otra para cada aplicación, etc. Cuando quieres comunicarlas, necesariamente invocan a otra que recibe mensajes mediante sockets. La ventaja de los sockets es que naturalmente funcionan como una cola y serializan los mensajes desde el punto de vista del receptor. Separar dentro de una misma VM varios espacios de objetos me parece innecesariamente complejo. No creo que se ahorre memoria ni que anda más rápido, puedo estar equivocado, pero eso me suena a una reimplementación de los threads en Smalltalk, algo así como feature envy. Un poco como reimplementar el ambiente de ventanas de Smalltalk en Mesa (Object Pascal), según Alan Kay por el mismo esfuerzo se podría haber implementado JIT en Smalltalk 80 en vez de haber tenido que esperar a Parc Place. Saludos, Guillermo. 2011/6/27 Javier Burroni <[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 > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
