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

Responder a