Objetos Distribuidos

Che, si es esto a lo que Mariano se referia, no nos olvidemos de
GemStone que hace no se, 25 años que esta con su base de objetos
(esencialmente se puede ver como una imagen compartida entre N otras
imagenes, con transacciones).  Si eso es lo que aca se describio como
"trivial", desde ya que de ninguna manera es trivial ese problema.
Trivial podra ser una primera aproximacion a la serializacion, pero
literalmente "objetos distribuidos" asi como en GemStone, ni ahi.

Ah, hablando de esto, hace poco encontre este articulo que me parecio
interesante.

http://www.rgoarchitects.com/Files/fallacies.pdf

2010/10/11 Angel Java Lopez <[hidden email]>:

> 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 [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

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 <[hidden email]>

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Hola Mariano,

¿La idea es hacer que los objetos "transparentemente" sean remoteados?

No imagino un caso de uso que realmente requiera eso,

sin mencionar que
el paper que alguien publicó en el mismo thread de alguien de Sun que
dice explícitamente que el sistema se vuelve lento y poco confiable.

Por algo los EJBs sólo publican servicios stateless. No tiene sentido
hacerlo stateful para que luego el servidor se caiga y que pierdas lo
que estabas haciendo.

Por otro lado con los EJBs todo es trivial: El remoting, la
serialización, etc.

La serialización en Smalltalk estaba resuelta el año 1994, cuando conocí
Smalltalk. Ahora parece que en Pharo no, pero al menos en GNU Smalltalk
sí:

http://forum.world.st/ObjectDumper-example-td1293043.html#a1293043

Saludos.
Guillermo.

On Wed, 2010-10-13 at 00:30 +0200, Mariano Martinez Peck wrote:
> 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 <[hidden email]>
>         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
>         [hidden email]
>         To unsubscribe from this group, send email to clubSmalltalk
>         +[hidden email]
>
>         http://www.clubSmalltalk.org
>
>
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to clubSmalltalk
> +[hidden email]
>
> http://www.clubSmalltalk.org

--
Simplex Veri Sigillum

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org

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).

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...

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.

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.

- Cuando grabe la imagen, en vez de anObject, se graba directamente x,

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 ... ;-)

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 <[hidden email]>

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 <[hidden email]>

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

2010/10/13 Angel Java Lopez <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

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 <[hidden email]>

2010/10/13 Angel Java Lopez <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

Hola gente!

Mariano: entiendo tu solucion, interesante. Interesante tambien lo de volcar en disco objetos no usados, similar a los EJB de entidad, que recuerde.

Andres: jeje... perdon que insista en mi punto, pero todos esos temas de serializacion, en Java/.NET no los tengo. Es interesante, y veo que cada vez MAS interesante, comenzar a pensar en implementar VM Smalltalk, Self u otras, sobre esas tecnologias.

Mariano, a lo de objetos volcados a disco, podria sugerir lo siguiente:

- Pensar un VM con objetos
- Pero los objetos estan en varias maquinas fisicas, algunos en una maquina M1, otros en una maquina M2
- Una VM en la cloud? ;-)
- Cuando una maquina M1 tiene mucho trabajo, puede pasar los objetos no usados a un dispositivo mas firme, como disco o base de datos.
- Y ese objeto serializado a disco, en vez de levantar en M1, quizas, la proxima vez se levante en M2.

- No es fino? ;-) ("chiste solo para argentinos" ;-)

- Tambien podria decir: "la maquina M1 la vamos a apagar, tonche, que serialize sus objetos", cuando alguna maquina requiera uno de esos objetos, cualquiera de los otros Mn levantara a ese objeto.
- Podriamos poner, como en implementaciones de NoSql, que una maquina M1, en realidad, son varias maquinas M1:1, M1:2, ... que van sincronizando sus objetos, de tal manera que si una maquina se cae, la otra tiene los objetos en un estado interesante.

Pero ya se, tengo que dejar la cerveza bock, y volver a la light ;-) (a la Liberty, aca en Argentina).

Back to topic, become.

Ahora, mi solucion al become, es como la de Mariano, pero por excepcion, digamos, como ya vimos. El pone un objeto intermedio en todos los objetos. Yo solo en los becomeados. Mas abajo, en este email, hay una solucion (en mi implementacion) sin objeto intermedio.

Mariano: En el caso que planteabas:

anObject == otherObject

Escribias

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.

hmmm... a ver si entendi. Eso de "otroObject apunta al mismo objeto" quiere decir "otroObject apunta al anObject ANTES del become", y por eso te preocupa que ahora anObject (que representa ahora x) de igual con otroObject... Bien, dos puntos:

- Tranqui puedo cambiar los bytecode (en mi pet project) porque estan todos concentrados en pequenias rutinas de .NET, bajo TDD. Una razon para ir por este camino, es justamente poder hacer cambios que YO entienda y que me resulte A MI faciles. De ahi que no tome una VM ya existente, que me parece algo "overwhelming" entenderla para despues hacer cambios rapidos y consistentes.

- Con respecto al ==, no veo que tendria que cambiar mucho. En el bloque en ejecucion, mantengo una pila de valores. Cuando evaluo anObject (que ahora su clase apunta a una clase especial que deriva a x), y lo voy a poner en la pila, ya envio en la pila a x, porque me doy cuenta que es un objeto "derivado" a otro. Asi, luego apilo otroObject (que en mi interpretacion de tu planteo, apunta directamente a x), y cuando el == se aplica a los dos al tope de la pila, se aplica x == x.

- Disculpen que coloque algo de codigo no Smalltalk ;-), pero en mi solucion puedo poner:

if (obj.Class.RealObject != null)
      executionctx.Push(obj.Class.RealObject)
else
      executionctx.Push(obj);

o, quizas ma-mejor, ponerlo en el objeto, una propiedad

RealObject { get { return this.Class.RealObject != null ? this.Class.RealObject : this } }

quedando en la ejecucion
     executionctx.Push(obj.RealObject);

Tengo pensado agregar a cada clase (que tambien es un objeto, pero decorada con algunas propiedades que puedo invocar directamente en el lenguaje de implementacion, en este caso C#) un RealObject, que solo tendra sentido para esas clases especiales. Y solo ocupa lugar para las clases especiales. Internamente, es una propiedad que devuelve null, y esta sobreescrita en la clase especial, para devolver el objeto real al que deriva el objeto "becomeado" ;-)

- Algo asi aplique en un interprete Lisp, cuando tuve que implementar un valor cuyo calculo es delayed. Al principio pense que tenia que cambiar en varios lugares, en varias primitivas, poner en varios lados la resolucion/calculo del valor delayed, pero al final, hubo que cambiar en muy pocos puntos: cuando realmente se va a usar el valor.

- Si alguna vez llego a compilar todo esto (no creo que me "de el cuero", pero podria usar Dynamic Language Runtime u otra alternativa), puedo reemplazar a la pila por variables intermedias. El "setear" una de esas variables, tendra el mismo tratamiento de arriba: los objetos "derivados" se "resuelven" al objeto que apuntan.

- Pienso que eso tambien funciona con objetos y otros bytecodes especiales que se me ocurran, como + (creo que en el Blue Book de Smalltalk-80, el + era un bytecode especial, mas que un mensaje #+).

- No recuerdo quien escribio por aca, la forma que una companiera de trabajo/tesista implemento objetos con metodos propios, en vez de metodos de instancia en la clase. Habia modificado la maquina virtual de Squeak, agregando a cada objeto un puntero. Cuando lo lei, estuve por escribir esto, pero no se si aportaba. Ahora, con mas contexto, puedo escribir: Yo hubiera usado el truco de, ni bien el objeto tenga un metodo para el solito, cambiar su referencia a su clase original, para apuntar a una nueva clase, solita para el, que a su vez termina apuntando a la clase original. Habria que determinar que hacer con la evaluacion de

anObj class

Me imagino poder poner

anObject compileMethod: '.....'

y que quede para eso objeto. Y luego, usarlo como prototipo:

anObject new

crearia un nuevo objeto que tambien apunta a la misma clase especial que tiene anObj. Hasta imagino que esto se puede hacer en Smalltalk normal, si vi, por ahi alguna vez

protoObject class: ...

cambiarle la clase a un objeto.

- Volviendo a anObject become: x. No me preocupa mucho que anObject apunte a una clase especial durante la vida de la imagen. Pero tambien puedo implementar esto: cada vez que durante la ejecucion, que encuentro en un slot (variable de instancia, indexada, de algun objeto) al consultarlo para, seguramente, apilarlo en la pila del contexto de ejecucion, si al examinarlo veo que es un objeto que deriva a otro "reseteo" ese slot al objeto derivado, de forma transparente a todo el resto del sistema.

- Como serializo el objeto que esta derivado a otro? Cada objeto tiene un metodo de serializacion unico. Tengo que modificar ese metodo, para que serialize el objeto al que fue becomeado. Si, eso, por alguna causa se complica, otro approach es: al serializar un objeto, me fijo en los slots que tiene, y si uno de eso es un objeto derivado a otro, me salteo el objeto intermedio, y serializo el otro (jeje, tambien se contempla que este otro a su vez sea become a otro... ;-)

- Pero todo esto del become: con la solucion que describi hasta ahora. Hay otro camino, mas facil, pero que tengo que pensar (la descripcion hasta ahora, algo lo tenia implementado en un interprete C++, del 2002, pero que no avanzo mucho). Internamente, cada objeto es un objeto .NET con variables privadas

private IBehavior class;
private object[] variables; // slots

Entonces, si tengo que hacer anObject become: x, lo que tengo que hacer, es intercambiar esos valores (en C#), tipo (disculpen tanto C#! ;-):

IBehavior beh = this.class;
this.class = x.class;
x.class = beh;
object[] vars = this.variables;
this.variables = x.variables;
x.variables = vars;

y voila! un objeto become el otro.

Lo unico a contemplar nuevo, es si uno de los objetos tiene variables indexadas, y el otro no. Mi primera opcion: hacer que todos los objetos, internamente, tengan un tercer dato, en general en null, pero que ocuparia el lugar de un "puntero" en TODOS los objetos (ahora, solo lo tienen los objetos de clases indexadas):

private IBehavior class;
private object[] variables; // slots
private object[] indexed; // variables indexadas

Veo que todo lo de arriba funcionaria en esta implementacion en C# (al contrario de la solucion que habia escrito para C++), porque esta vez no segui el camino de Smalltalk clasico de tener objetos con WORDS, POINTERS, BYTES y demas variantes. En Smalltalk clasico, en las VM clasicas (corrijanme si no entendi) los objetos tienen diferente implementacion interna dependiendo si representan bytes, words y asi.

Aca no. Todos los IObject (asi es la interfaz de C# que tienen que cumplir) hasta ahora, en mi implementacion, tienen la misma estructura interna (excepto el caso de indexed variables que tendre que evaluar de cambiar).

Como escribia Mariano "Implementar un become: sin object table es lento". Bueno, en mi implementacion, me aprovecho de la estructura interna para contrarrestar eso.

Y en caso que los dos objetos en 'anObject become: x' sean de estructura interna diferente, puedo pasar a la solucion que describi anteriormente. Todos los IObject tiene al menos la referencia a una clase.

Mariano, pasando a lo que escribiste proxies, no entendi todavia, pero voy a releer tranquilo tu mensaje, despues pregunto. Pero una cosa:

- 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.  

Hmmm.. Yo no necesito, en mis casos de uso que tengo pensado, combinar become: con proxy. Tendria que pensarlo, pero no lo necesito. Voy a meditar si con mi implementacion de become: igual se soluciona o no lo que planteas.

Mi idea de proxy es:

^anObject asProxy

o si quers

^aClass asProxy

es decir, obtener un nuevo objeto que sea un proxy a otro objeto. Y enviar ese proxy a otra maquina fisica. Hoy, si desde un nodo A invoco a nodo B con:

nodoB: evaluate '...expression... '

El nodo B lo evalua y devuelve un objeto, que se serializa y reifica en nodo A. Es la conducta por default. En cambio si

myObj := nodoB: evaluate '(....expresssion... ) asProxy'

lo que viaja es un proxy al objeto que resulto de la evaluacion de la expresion. Desde ahi, en nodo A, cada vez que se invoca:

myObj msg: par1

se serializan los parametros, y el simbolo del mensaje, se ejecuta en nodo B, y devuelve algo, desde B a A, o no, tal vez nil.

Si un parametro par1, digamos, no quiero que viaje serializado a B, tranquilamente:

myObj msg: par1 asProxy

Bien, temas interesantes. Espero que la longitud del email, sea compensada por lo (espero) interesante de la discusion.

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
 

2010/10/13 Mariano Martinez Peck <[hidden email]>

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 <[hidden email]>

2010/10/13 Angel Java Lopez <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>

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 [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org