Objetos Distribuidos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Objetos Distribuidos

Angel Java Lopez
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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Angel Java Lopez
Hola gente!

Ah! Yo, por lo menos, nunca mencione GemStone (que alguien bueno de Sugar (Smalltalk Users Group de Argentina) me comento en los noventa, el bueno de Leandro Caniglia, recuerdo su implementacion en Luchetti, que recuerde).

Lo que me gustaria (tengo codigo, pero no tengo test, asi que nada de publicado ahora), es:

anObject msg: par1 ....

y anObject sea un proxy local, que deriva a un objeto residente en otra maquina ese mensaje. El programador puede haberlo creado local (como para probar su algoritmo en una sola maquina) o puede haberlo creado en otro nodo de una red. En los casos de uso que tengo en mente, el programador sabe que hay un costo en eso, asi que no esta conversando con esos objetos a cada milisegundo. Es mas: te doy una tarea, despues, llegado el caso, en algun momento, por otro canal, recibire una respuesta.

Tambien quiero implementar:

anObject msg: par1 ...

y que anObject por abajo, derive el mensaje a uno, a todos, o a algunos de otros objetos, remotos o locales.

Y algo ortogonal a todo eso, que tengo implementando, pero tendria que unirlo con lo de remoting:

anObject msg: par1 ...

que anObject reciba el mensaje, y lo atienda en su propio thread. Recibe el mensaje, lo coloca en una cola en memoria, y lo atiende en su propio thread, cuando este disponible. El objeto que envie el mensaje sigue su camino. Esto permite implementar algoritmos en paralelo, sin el tema "te envio algo, y te espero a que termines para seguir yo".

Interesante el paper que enviaste, lo conocia, pero no lo recordaba. Ya lo mando a twitter.

No entendi si "si es esto a lo que Mariano se referia", y "Si eso es lo que aca", digo, no entendi "si esto" en la primera frase se refiere a lo mismo a lo que se refiere "si eso", en la segunda.

Nos leemos!

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

2010/10/11 Andres Valloud <[hidden email]>
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

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
Ah, para clarificar.

>> Che, si es esto

esto = "tener proxies y mandar mensajes remotos a objetos sin perder
la identidad del objeto", por ejemplo...

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

eso = "resolver el problema de distribucion de mensajes a objetos
distribuidos de manera razonablemente general, como por ejemplo lo
hace GemStone"...

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

Andres.


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

> Hola gente!
>
> Ah! Yo, por lo menos, nunca mencione GemStone (que alguien bueno de Sugar
> (Smalltalk Users Group de Argentina) me comento en los noventa, el bueno de
> Leandro Caniglia, recuerdo su implementacion en Luchetti, que recuerde).
>
> Lo que me gustaria (tengo codigo, pero no tengo test, asi que nada de
> publicado ahora), es:
>
> anObject msg: par1 ....
>
> y anObject sea un proxy local, que deriva a un objeto residente en otra
> maquina ese mensaje. El programador puede haberlo creado local (como para
> probar su algoritmo en una sola maquina) o puede haberlo creado en otro nodo
> de una red. En los casos de uso que tengo en mente, el programador sabe que
> hay un costo en eso, asi que no esta conversando con esos objetos a cada
> milisegundo. Es mas: te doy una tarea, despues, llegado el caso, en algun
> momento, por otro canal, recibire una respuesta.
>
> Tambien quiero implementar:
>
> anObject msg: par1 ...
>
> y que anObject por abajo, derive el mensaje a uno, a todos, o a algunos de
> otros objetos, remotos o locales.
>
> Y algo ortogonal a todo eso, que tengo implementando, pero tendria que
> unirlo con lo de remoting:
>
> anObject msg: par1 ...
>
> que anObject reciba el mensaje, y lo atienda en su propio thread. Recibe el
> mensaje, lo coloca en una cola en memoria, y lo atiende en su propio thread,
> cuando este disponible. El objeto que envie el mensaje sigue su camino. Esto
> permite implementar algoritmos en paralelo, sin el tema "te envio algo, y te
> espero a que termines para seguir yo".
>
> Interesante el paper que enviaste, lo conocia, pero no lo recordaba. Ya lo
> mando a twitter.
>
> No entendi si "si es esto a lo que Mariano se referia", y "Si eso es lo que
> aca", digo, no entendi "si esto" en la primera frase se refiere a lo mismo a
> lo que se refiere "si eso", en la segunda.
>
> Nos leemos!
>
> Angel "Java" Lopez
> http://www.ajlopez.com
> http://twitter.com/ajlopez
>
> 2010/10/11 Andres Valloud <[hidden email]>
>>
>> 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
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Mariano Martinez Peck
In reply to this post by Angel Java Lopez
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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
> - 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.

Lo peor es que en general cuando bajas objetos no bajas las clases.
Asi que las instancias que creas cuando volver a cargar los objetos
podran tener las mismas variables de instancia pero diferente
conducta.  Por lo tanto, si reimplementaste = / hash en la clase
nueva, entonces el includes: que antes daba true, ahora capaz que te
da false.  Por eso GemStone usa versiones de clases, y la migracion de
objetos es manual.

Andres.

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Guillermo Schwarz
In reply to this post by Mariano Martinez Peck
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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
> ¿La idea es hacer que los objetos "transparentemente" sean remoteados?
> No imagino un caso de uso que realmente requiera eso

En GemStone, es super util usar forwarders para evitar replicar
objetos enormes solamente para mandarles un par de mensajes.  Por
ejemplo, historicalInvoiceDictionary atInvoiceNumber: 1.  Es
totalmente al divino boton bajarse todas las facturas para hacer eso.
Los forwarders existen desde el tiempo de ñáupa...

... bueno, en realidad desde el tiempo de páupa, páupa, páupa, paren
che, páupa...

Andres.

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Angel Java Lopez
In reply to this post by Mariano Martinez Peck
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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
In reply to this post by Mariano Martinez Peck
> - Es muy dificil hacer un serializador que sea rapido. Acá en mi lab están
> haciendo una implementación parecida a Parcels (de VW)

Fijate BOSS que esta refactorizado en la ultima version de VWNC.
Ahora el codigo se puede leer.  Tambien hay un preview de un formato
nuevo para 64 bits.

Ahhh, otro problema.  Si grabas objetos en imagenes de 32 bits y los
levantas en imagenes de 64 bits (o al reves), entonces te puede pasar
que un small integer pase a ser un large integer, o viceversa.

Y cual es el problema, no?  Al final, son integers igual.

Bueno, pero no, porque si a1 y a2 son small integers y b1 y b2 son
large integers, entonces si el codigo por un lado dice a1 == a2,
entonces con b1 == b2 se rompe.  Si tenias small integers en un
identity dictionary o identity set, ahora resulta que no los podes
encontrar.  Y si bajas small integers grandes de 64 bits a una imagen
de 32 bits, los tenes que convertir a large integers pero
preferentemente haciendo solamente una instancia de cada valor asi por
lo menos sigue valiendo el == y el identityHash.  Algo parecido pasa
con los small doubles.

Ah, y ademas, en versiones anteriores de VisualWorks se encodeaban
bytecodes con un small integer en el ultimo literal de los metodos
compilados de entre 4 y 6 bytecodes.  Pero si tenes un large integer
al final del metodo compilado en una imagen de 32 bits, y resulta que
ese large integer es un small integer en la imagen de 64 bits, ahora
resulta que el JIT falla (de manera mas o menos razonable, una especie
de DNU pero que se llama badBytecodeAt:) con los metodos compilados en
imagenes de 32 bits.  Resultado: no podias cargar parcels de 32 bits
en una imagen de 64 bits.

Que divertida la serializacion, no?  Sigh... no es facil!!! :)

Andres.

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Mariano Martinez Peck
In reply to this post by Guillermo Schwarz


2010/10/13 Guillermo Schwarz <[hidden email]>
Hola Mariano,

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


Si, mas o menos.

 
No imagino un caso de uso que realmente requiera eso,

yo :)

Yo quiero poder detectar objetos que no están siendo usados (aunque referenciados y por eso el GC no se los lleva), reemplazarlos por un proxy y swapearlos a disco. En caso de que se necesiten, automaticamente se traen a memoria.
 
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


Ahh si. Esto en algún momento lo había anotado para mirar pero me olvidé. Gracias por el recordatorio. Lo voy a mirar.
 
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

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Mariano Martinez Peck
In reply to this post by Angel Java Lopez


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)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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Mariano Martinez Peck
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)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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Angel Java Lopez
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)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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Mariano Martinez Peck


2010/10/13 Angel Java Lopez <[hidden email]>
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.

Este punto, que parece trivial, es un bardo. La diferencia entre si el objeto o subgrafo de objectos va a cargar o no en la misma image, es todo un tema.
Definamos que entendemos por serializar un objecto:  object header + slots (Smallintegers o OOP) , o bueno, en el caso de objetos de clase variables, un chuck de memoria.
ahora bien, para esos casos de oop...serializas tambien esas variables de instancias o no?
En caso de que no, que pasa con si X en M1 apunta a Y y Z y alguno de esos NO está presente en M2. Que pasa cuando lo cargas?
Si tambien serializas Y y Z, que pasa si alguno de ellos esta TAMBIEN apuntado desde objetos de otro lugar (fuera de tu subgrafo) ?  tambien tenes que crear proxies para ellos? como sabes que objetos estan siendo "tambien apuntados desde afuer" ?  tenes que hacer un traverse de toda la mamoria o alguna otra magia.
 
- 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:

Si, igual el #== fue solo un ejemplo. Deben haber varios problemas.
 

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


ok, bien.
 
- 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.


ok
 
- 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 #+).

Si, mira lo que te de deveulve en Squeak/pharo Smalltalk specialSelectors y todos esos tienen asociado un bytecode special. Igual no todos esos bytecodes te cagan. Algunos simplemente hacen optimizaciones y luego terminan llamando al "normalSend".
 

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


no entendi

 

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.


Si, primitiveChangeClass en squeak, desde la imagen: Object >> primitiveChangeClassTo: anObject

 

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

jajajajjaja
 

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

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



Igualmente, a ver si entendy, to become as late binding. O sea, todo el resto de los punteros al objeto que apuntas, solamente van a ser actualizados o cuadno lo accedan (en el mejor de los casos) o cuando se salve la imagen. No?    El unico problema es cuando queres hacerlo inmediato, o sea, como funciona el become ahora. Entendi bien?

 
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


creo que mas o menos entendi. tengo que pensarlo jajajaj
 
Bien, temas interesantes. Espero que la longitud del email, sea compensada por lo (espero) interesante de la discusion.


sipi :)
 

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

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
In reply to this post by Mariano Martinez Peck
> Yo quiero poder detectar objetos que no están siendo usados (aunque
> referenciados y por eso el GC no se los lleva), reemplazarlos por un proxy y
> swapearlos a disco. En caso de que se necesiten, automaticamente se traen a
> memoria.

Ephemerons...

Andres.

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

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Guillermo Schwarz
ST/X hacía algo parecido pero con las clases que no habías instanciado:

Había un Proxy con el nombre de la clase. Al tratar de instanciarla, leía el fuente de la clase, la compilaba y hacía un become: para reemplazar el proxy genérico con la clase recién cargada.

Eso ahorraba bastante memoria casi sin sacrificar nada de tiempo.

Lo que tú dices, IMHO es más como dedicarse a swappear objetos entre RAM y disco. Se volvería super lento a menos que los objetos sean super grandes. ¿Cómo saber si un objeto referenciado está siendo usado o no? ;-)

Saludos,
Guillermo.

2010/10/13 Andres Valloud <[hidden email]>
> Yo quiero poder detectar objetos que no están siendo usados (aunque
> referenciados y por eso el GC no se los lleva), reemplazarlos por un proxy y
> swapearlos a disco. En caso de que se necesiten, automaticamente se traen a
> memoria.

Ephemerons...

Andres.

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

http://www.clubSmalltalk.org



--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

--
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
 
http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Javier Burroni
In reply to this post by Andres Valloud-5
2010/10/13 Andres Valloud <[hidden email]>:
>> Yo quiero poder detectar objetos que no están siendo usados (aunque
>> referenciados y por eso el GC no se los lleva), reemplazarlos por un proxy y
>> swapearlos a disco. En caso de que se necesiten, automaticamente se traen a
>> memoria.
>
> Ephemerons...
Esta interesante la relación, aunque es mas complejo, ya que casi todo
lo de ephemerons ocurre durante el GC -y lo que no, es un "side
effect" del uso del sistema-, y aca, supongo, habría que agregar
comportamiento durante el funcionamiento del sistema que sea exclusivo
para esto.
Mariano, esto es lo que presentaste en ESUG? esta muy bueno :)

--
" 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 [hidden email]
To unsubscribe from this group, send email to [hidden email]

http://www.clubSmalltalk.org
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Andres Valloud-5
En realidad los ephemerons se finalizan despues del GC (cuando el GC
detecta que el key del ephemeron no esta referenciado por nadie
excepto por otros ephemerons [mas o menos, hay que mirar bien el paper
de Bosworth, creo que era el]).  En VisualWorks se ponen en el
finalization queue (ahora sin su propiedad de ser ephemeron, asi no se
tira a la basura el objeto que era referenciado debilmente), y
entonces les podes mandar finalize.

Quiza con un poco de trabajo se pueda adaptar este mecanismo para que
"finalizar" signifique "proxificar".  Pero tal vez no sirva.

2010/10/13 Javier Burroni <[hidden email]>:

> 2010/10/13 Andres Valloud <[hidden email]>:
>>> Yo quiero poder detectar objetos que no están siendo usados (aunque
>>> referenciados y por eso el GC no se los lleva), reemplazarlos por un proxy y
>>> swapearlos a disco. En caso de que se necesiten, automaticamente se traen a
>>> memoria.
>>
>> Ephemerons...
> Esta interesante la relación, aunque es mas complejo, ya que casi todo
> lo de ephemerons ocurre durante el GC -y lo que no, es un "side
> effect" del uso del sistema-, y aca, supongo, habría que agregar
> comportamiento durante el funcionamiento del sistema que sea exclusivo
> para esto.
> Mariano, esto es lo que presentaste en ESUG? esta muy bueno :)
>
> --
> " 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 [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
Reply | Threaded
Open this post in threaded view
|

Re: Objetos Distribuidos

Francisco Garau
In reply to this post by Mariano Martinez Peck
Hola Mariano,

Muy interesante (y gracias por compartir lo que estas haciendo).

Con respecto a la serializacion, hace rato que tengo ganas de mirar el
SRP de Baumann.Iba a pasarte los links, pero veo ya estuviste
preguntando en la lista de VW. Podes contar que tal te parecio? Ese
framework permite serializar en forma binaria, cierto?

Saludos,
Francisco


On Oct 12, 11:30 pm, Mariano Martinez Peck <[hidden email]>
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
> > [hidden email]<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 [hidden email]

http://www.clubSmalltalk.org
1234