Mi idea para un become: rápido y para poder experimentar infinito era implementar "first class references". Esto es, en vez de que un objeto apunte directamente a otro objeto, apunta a un objeto intermedio, y ese apunta al objeto de verdad. Obviamente que hay un overhead importante (estimamos 15%, por un trabajo similar de Adrian Lienchard), y la memoria bueno....practicamente se duplica.
Lo bueno es que el become es simplemtne cambiar ese objeto intermedio y listo. Obviamente que implica bocha de cambios en la VM, esa es la paja jajajaja. saludos Mariano 2010/10/13 Mariano Martinez Peck <[email protected]> > > > 2010/10/13 Angel Java Lopez <[email protected]> > >> Hola gente! >> >> Mariano, interesantisimo tu email... Por ahora (en medio de mi cena), >> contesto solo lo sobre become:... >> >> Recuerdo que cuando vi a Squeak, me causo impresion el tema de como >> implementaban become:... se terminaban "bailando la conga", como bien >> indicas, no tenian Object Table (desconozco como sera actualmente Squeak, lo >> habre visto a fines de los noventa, no estoy seguro). >> > > > Sigue siendo asi :( > > > >> >> Lo que tengo pensado en mi implementacion, en mi pet project (no >> implementado todavia), es que become: lo que hace es: >> >> - Cambiar el "puntero" de un objeto X a su clase. >> - Esa referencia, cambia a un nuevo objeto especial en mi implementacion, >> que dice, no es una clase cualquiera, es una clase que envia todos sus >> mensajes, no al objeto original, sino a otro objeto, el parametro de lo que >> era become: >> A ver si puedo explicarme... >> > > > Entendi perfecto. > > > >> >> Si >> >> anObject become: x >> >> el anObject class cambia su clase a una "clase" especial, que hace que >> todo mensaje dirigido a anObject, se deriva al x del become: >> En cuanto guarde la imagen, puedo reemplazar toda referencia al anObject >> original al nuevo x. > > > > Este es el mayor problema de tu solucion para mi. Porque si tenes > otroObject apuntando al mismo objeto, no se va a actualizar sino hasta que > se guarde la imagen ? > > > >> Pero mientras no guarde la imagen, puedo usar el "trick" que describo (no >> se si se entendio mi explicacion) >> >> - Toda referencia a anObject no necesita cambia. Lo que pasa, que >> cualquier envio de mensaje a anObject, termina siendo redirigida al x del >> become: x. >> > > "todo menesaje" ->>> revisa bien el tema de los bytecodes. Ponele, si te > mando hago anObject become: x y despues hago anObject == otroObject > (suponiendo que otroObject apunta al mismo objeto) eso va a dar > true....execpto que te pongas a modificar todos los bytecodes speciales. > > >> >> - Cuando grabe la imagen, en vez de anObject, se graba directamente x, > > > como haces eso? > > >> entonces, al cabo de algunos dias, cuando levante la imagen, toda >> referencia a anObject, termina apuntando a x. >> >> - No tengo problemas con false, true.... terminan funcionando igual (en >> mi implementacion son bool false, y bool true, de la maquina VM de abajo, en >> este caso, .NET). Es decir, todos los false y true, serializados o no, >> funcionan igual. >> >> - Los symbol, para mi, en mi pet project, son simples String. Como la VM >> "de abajo", sea .NET o Java, identifican como "iguales" todo string que >> tenga el mismo valor, inclusi cuando se usan como keys en diccionarios. Es >> decir >> >> "pepe".Equals("pepe") >> >> no importa que "pepe" sea un objeto "distinto" (ocupando otro lugar en la >> memoria) de "pepe". >> >> Y cualquiera "pepe" tiene el mismo HashTag de cualquier otro "pepe".. y >> como todo String es inmutable.. .no hace falta distinguir entre Symbol y >> String.... por lo menos en mi implementacion (no me supe explicar del todo, >> cualquier duda, me preguntan). >> >> En caso de que fuera necesario, podria implementar Symbol como >> "pepe".intern() que transforma un string en su represatacion canonica, de >> tal forma que todo "pepe".intern() sea exactamente igual , a cualquier >> "pepe".intern() >> >> Algunos puntos mas: >> >> - Puedo serializar un metodo compilado, aunque todavia no encontre que >> fuera necesario. >> >> Bueno, escribi rapido, no se si se entendio todo... acabo de ver >> #BenditaTv, aca en Argentina, tengan piedad ... ;-) >> >> > jajajaja > > > >> Maniana, espero, pregunto sobre dudas que me quedaron del email de >> Mariano... >> >> Vermu con papa fritas, y gud show! ;-) (chiste para argentinos) >> >> >> Nos leemos! >> >> Angel "Java" Lopez >> http://www.ajlopez.com >> http://twitter.com/ajlopez >> >> >> >> 2010/10/12 Mariano Martinez Peck <[email protected]> >> >> Hola angel. Quiero opinar sobre 2 cosas que estoy laburando en mi PhD y >>> están bastante relacionados. Proxies y serializacion. Uno cree que son >>> faciles, pero ninguno de los dos es asi. >>> >>> Problemas con proxies: >>> >>> - Acordate que en ST todo son objetos. Por lo tanto el objeto que vas a >>> convertir en proxy, puede ser cualquier cosa: Clases, CompiledMethods, >>> Closures, etc. >>> >>> - Cuando en ST nos quedamos sin Object Table, el #become ES LENTO. Se >>> tiene que traversar todos los objetos de la memoria. Por esto en Gemstome el >>> become anda mas rapido (tienen object table) >>> >>> - Trataste de hacer un unaClase become: MyProxy new ? Cuando luego le >>> mandas un mensaje a una instancia de unaClase, se rompe todo. Principalmente >>> porque el proxy es un objeto no una clase (obviemos el detalle que una clase >>> es un objeto), y la VM para acceder al MethoDict accede DIRECTAMENTE al >>> offset the las variables. O sea, asume que la clase tiene X cantidad de >>> variables y que el methodDIct esta en la posicion X. >>> >>> - Muchas veces el doesNotUnderstand: no es suficiente. En varios casos >>> podes usar el hack de poner el methodDict en nil, e implementar >>> #cannotInterpret: en la superclase. >>> >>> - Lo mismo para los CompiledMethod. Poner un proxy no es igual que para >>> todo el mundo. Tenes que implementar #run:with:in: y algunos otros >>> mensajes mas. >>> >>> - Hay un montón de mensajes que no van como un bytecode send comun, sino >>> con bytecodes especiales. Por lo tanto el dnu o cannotInterpret: pueden ni >>> llamarse. Evalua "ProtoObject class" y vas a que anda..sin embargo >>> ProtoObject no implementa #class. Y asi como #class hay varios bytecodes >>> speciales que te cagan. Mira Smalltalk specialSelectors. >>> >>> - Tenes que tener mucho cuidado a lo que becomeas con un proxy. Podes >>> romper todo muy facil. Hay cosas core que no se pueden reemplazar. >>> >>> - Debugear es muy dificil porque el mismo debugger manda mensajes para >>> imprimirlos o cosas asi entonces te los vuelve a traer jjajajaj >>> >>> - Si un objecto X tiene como instancia una refencia a un objeto Y, y >>> haces un become de X a un proxy, el proxy no va a apuntar a Y. POr lo tanto, >>> si nadie mas estaba apuntando a Y, el GC te llevó a Y. ImageSegments >>> soluciona esto de una manera muy buena. >>> >>> >>> >>> Respecto a Serializacion: >>> >>> - Es muy dificil hacer un serializador que sea rapido. Acá en mi lab >>> están haciendo una implementación parecida a Parcels (de VW) y está andando >>> bien. Pero hay que tener en cuenta un monton de problemas: >>> >>> - Ciclos en el subgrafo >>> >>> - CompiledMethod, ContextPart (y subclases), Process, Continuations, etc >>> etc son dificilies de serializar >>> >>> - endianess (big or blah) >>> >>> - que haces con nil, true, false, etc? y Symbol ? A la hora de cargarlo >>> en la misma image o en otra, no podes crear duplicados, y los objetos tienen >>> que apuntar a los ya existentes. Tambien tenes que hacer un rehash de los >>> sets cuando los traes nuevamente. etc......etc etc. >>> >>> >>> Bueno, eso nomas. Muchas veces las cosas parecen más faciles no? >>> >>> saludos >>> >>> Mariano >>> >>> >>> 2010/10/11 Angel Java Lopez <[email protected]> >>> >>>> Hola gente! >>>> >>>> >>>> Interesante la discusion del Thread "Blog", pero tambien algo se fue por >>>> las ramas... Cambio de titulo en este mensaje. >>>> >>>> Estuve agregando objetos distribuidos a mi pet project [1], quedo algo >>>> asi: >>>> >>>> http://pastie.org/1213856 >>>> >>>> Tengan encuenta que no tengo libreria de clases de base, asi que tengo >>>> que comenzar desde nil subclass:... ';-) >>>> >>>> Puedo: >>>> >>>> - Levantar un servidor (tecnologia Remoting .NET), en nodo A. >>>> - Levantar un cliente remoto a ese servidor, en nodo B. >>>> - Definir una clase en nodo B. >>>> - Exportar su definicion de B a nodo A. >>>> - Ejecutar desde nodo B algo en nodo A. >>>> - Evaluar en nodo A y devolver el objeto serializado (contemplando >>>> grafos con ciclos, repeticion de objetos, etc..) a B. >>>> >>>> Me falta evaluar en nodo A y que el resultado quede en A, viajando a B >>>> una especie de proxy, de tal manera que invocando a ese objeto en B, se >>>> ejecute el mensaje en nodo A. >>>> >>>> Mi idea es que si B devuelve un objeto a A, ese resultado viaja >>>> completo. Sino, definiria algo como >>>> >>>> ^host asProxy: result. >>>> >>>> Tendria que escribir post, pero por ahora, tengo esto para mostrar. >>>> >>>> [1] http://code.google.com/p/ajtalk >>>> >>>> Nos leemos! >>>> >>>> Angel "Java" Lopez >>>> http://www.ajlopez.com >>>> http://twitter.com/ajlopez >>>> >>>> >>>> >>>> -- >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected]<clubsmalltalk%[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]<clubsmalltalk%[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]<clubsmalltalk%[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
