Objetos Distribuidos

> 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

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

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

>
> >http://www.clubSmalltalk.org

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

http://www.clubSmalltalk.org

2010/10/13 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...

No. Por lo que entiendo, Ephemerons tiene que ver mas que nada con la finalizacion de los objetos y un punto medio al GC. Algo más parecido a los WeakRegistry no?

Lo mio (vah, mi idea) es mas bien parecido a LOOM (large object oriented memory) o a lo que se conoce comunmente como memoria virtual.

2010/10/13 Mariano Martinez Peck <[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...

No. Por lo que entiendo, Ephemerons tiene que ver mas que nada con la finalizacion de los objetos y un punto medio al GC. Algo más parecido a los WeakRegistry no?

Lo mio (vah, mi idea) es mas bien parecido a LOOM (large object oriented memory) o a lo que se conoce comunmente como memoria virtual.

Por curiosidad, cual es la motivacion? 

Pregunto porque me parece que la tendencia es al revés - es decir, traer todos los objetos a memoria. 

- Francisco

 

--

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

> Con esto podes cambiar Monticello por ejemplo, para que grabde/cargue cosas binarias y un .cs de mierda donde necesita un Compilador y ecnima es re lento. Eso hicieron en el Store de VW.

Podrias decir esto con mas detalle?

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

>> Por curiosidad, cual es la motivacion?
>
> Tratar de usar menos memoria.
>
> Poder usar Smalltalk en robots, smart card o cualquier tipo de hardware
> limitiado. Incluso en servers deployando web applications.

Y pero entonces lo mejor no es swappear la basura, lo mejor es nunca
crear los objetos que no necesitas...

> Hicimos un par de experimentos en una PharoCore despues de haberle heacho el
> clean para produccion, donde cargamos una web app hecha en
> seaside.....navegamos la app de punta a punta, con varios usuarios y
> blah...y sabes que porcentaje de objetos estabamos usando? menos del 10%. Y
> representaban el 15% de la memoria.   Y no es que hacia falta un GC. eso lo
> hicimos antes.

Si no sabes que hay en la imagen (porque no hay una especificacion
para construirla desde cero), entonces es mucho mas dificil hacer la
contabilidad a posteriori.  Ademas, solo basta que alguien vaya y
cambie algo en la imagen con la que habias empezado a limpiar, y
potencialmente todo el procedimiento de limpieza se vuelve invalido...
es jodido ese tema.

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

Ok, pero a veces no te queda otra que recompilar, particularmente si
cambias el compilador (por ejemplo, si Cog pone bytecodes nuevos).

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

>
>
> 2010/10/14 Andres Valloud <[hidden email]>
>>
>> > Con esto podes cambiar Monticello por ejemplo, para que grabde/cargue
>> > cosas binarias y un .cs de mierda donde necesita un Compilador y ecnima es
>> > re lento. Eso hicieron en el Store de VW.
>>
>
> Puedo intentarlo ;)  pero no se si servirá de mucho....
>
> Hoy en día, con Monticello tenes un gran problema y es que es lento (además
> de varios otros problemas). Porqué es lento? CREO que mayoritariamente
> porque en Monticello, cuando vos comiteas te genera un .mcz, que si lo
> descomprimis, y lo ves, no es mas que un zip con un .cs adentro. O
> sea....comiteas código. A la hora de cargar, dos problemas: 1) es lento
> porque tenes que compilar; 2) necesitas un compilador.
>
> En Pharo queremos tener un PharoKernel por ejemplo, donde ni siquiera existe
> un Compiler y le puedas ir cargando cosas. Con Monticello no podemos, con
> esto si.
>
> Con respecto a la velocidad, Eliot Miranda et all, implementario Parcels.
> Basicamente es un arhivo binario, pero definieron un formato de arhivo, y
> varias cosas mas. Es un serializador de objetos, pero la intencion es que
> sobretodo el loading sea rápido. El archivo está escrito pensado de esta
> forma. Se que cuando integrarion esto al Store, la performance subió
> impresionantemente.
>
> Parcels paper:
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.68.3541
>
> saludos
>
> Mariano
>
>> Podrias decir esto con mas detalle?
>>
>> 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
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--

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

http://www.clubSmalltalk.org

2010/10/13 Francisco Garau <[hidden email]>

Hola Mariano,

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

Gracias.
 

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?

Te soy sincero, no tuve tiempo de mirarlo :(
El tema es que yo me "desligué" un poco del tema de la serialización. Yo me estoy encargando de los proxies, del swapping, del tracing de los objetos no usados, detectar subgrafos, etc....
Pero hay un equipo acá en mi lab que están haciendo un nuevo serializador. Depués de analizar varios approaches distintos, el más parecido es Parcles. Parcles también es binario, y el "problema/feature" que tiene es que está pensado para que la escritura tal vez tarde un poco mas, pero que cargarlo sea realmente rápido. Con esto podes cambiar Monticello por ejemplo, para que grabde/cargue cosas binarias y un .cs de mierda donde necesita un Compilador y ecnima es re lento. Eso hicieron en el Store de VW.

En fin, les voy a recordar a estos flacos sobre SRP y ver si pueden sacar algo de ahi. BTW, uno de los muchahos es argentino, Martín Días, de la UBA.

Saludos

MAriano

 

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

Mariano:

Algo que es bastante alucinante son las SLLs de Visual Smalltalk, no
se si pretenden llegar a algo parecido.

Con respecto al file-in en Pharo tienen razon que es extremadamente
lento. No se por qué, supongo que el compilador es lento.

En Dolphin el compilador es tan rapido que creo que nadie se molesta
por este tipo de cosas, de hecho cuando porte Seaside era muy evidente
esa diferencia. Aunque me gustaria poder generar SLL's :)

Saludos
 GallegO




El día 13 de octubre de 2010 20:15, Mariano Martinez Peck
<[hidden email]> escribió:

>
>
> 2010/10/14 Andres Valloud <[hidden email]>
>>
>> > Con esto podes cambiar Monticello por ejemplo, para que grabde/cargue
>> > cosas binarias y un .cs de mierda donde necesita un Compilador y ecnima es
>> > re lento. Eso hicieron en el Store de VW.
>>
>
> Puedo intentarlo ;)  pero no se si servirá de mucho....
>
> Hoy en día, con Monticello tenes un gran problema y es que es lento (además
> de varios otros problemas). Porqué es lento? CREO que mayoritariamente
> porque en Monticello, cuando vos comiteas te genera un .mcz, que si lo
> descomprimis, y lo ves, no es mas que un zip con un .cs adentro. O
> sea....comiteas código. A la hora de cargar, dos problemas: 1) es lento
> porque tenes que compilar; 2) necesitas un compilador.
>
> En Pharo queremos tener un PharoKernel por ejemplo, donde ni siquiera existe
> un Compiler y le puedas ir cargando cosas. Con Monticello no podemos, con
> esto si.
>
> Con respecto a la velocidad, Eliot Miranda et all, implementario Parcels.
> Basicamente es un arhivo binario, pero definieron un formato de arhivo, y
> varias cosas mas. Es un serializador de objetos, pero la intencion es que
> sobretodo el loading sea rápido. El archivo está escrito pensado de esta
> forma. Se que cuando integrarion esto al Store, la performance subió
> impresionantemente.
>
> Parcels paper:
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.68.3541
>
> saludos
>
> Mariano
>
>> Podrias decir esto con mas detalle?
>>
>> 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
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

--

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

http://www.clubSmalltalk.org

2010/10/14 Francisco Garau <[hidden email]>

2010/10/13 Mariano Martinez Peck <[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...

No. Por lo que entiendo, Ephemerons tiene que ver mas que nada con la finalizacion de los objetos y un punto medio al GC. Algo más parecido a los WeakRegistry no?

Lo mio (vah, mi idea) es mas bien parecido a LOOM (large object oriented memory) o a lo que se conoce comunmente como memoria virtual.

Por curiosidad, cual es la motivacion? 

Tratar de usar menos memoria.

Poder usar Smalltalk en robots, smart card o cualquier tipo de hardware limitiado. Incluso en servers deployando web applications.
Porque que una imagen te ocupa 100mb en disco cuando en realidad frecuentemente usa el 20% ?

Hicimos un par de experimentos en una PharoCore despues de haberle heacho el clean para produccion, donde cargamos una web app hecha en seaside.....navegamos la app de punta a punta, con varios usuarios y blah...y sabes que porcentaje de objetos estabamos usando? menos del 10%. Y representaban el 15% de la memoria.   Y no es que hacia falta un GC. eso lo hicimos antes.
 

Pregunto porque me parece que la tendencia es al revés - es decir, traer todos los objetos a memoria. 

Tendencia de quien? prevalencia?  Lo que si es verdad, y es muy interesante es el otro approach, el estilo gemstone: los objetos viven siempre en disco, y solamente cuando se necesitan se pasan a ram, se usan, y luego vuelven al disco. Esto si es intersante y es la "solucion opuesta a la nuestra".

saludos

Mariano
 

- Francisco

 

--

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

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

Hola gente!

Algo offtopic, por eso lo hago breve, pero levemente relacionado, en esta interesantisima discusion/exposicion: No puedo dejar de recordar al Sistema Pick (tal vez alguno trabajo aca en Argentina con equipos Microdata). Todo (archivos, memoria, registros de un proceso) estaba en sectores. Cada sector tenia una direccion (como un bloque de "memoria"). Que un sector estuviera en memoria o en disco o en lo que sea, dependia del sistema operativo, segun el uso de esa parte del espacio de sectores. Uno podia cambiar el contenido de un archivo o de un bloque de memoria, simplemente apuntando a un byte con una direccion es ese espacio.

No se si eso fue parte de toda implementacion de Pick OS, pero lo vi en la implementacion Reality de Microdata.

Cada decada que pasa, vuelvo a pensar que era una gran solucion. Lamentablemente no se transformo en mainstream, y Robert Pick murio en los noventa.

http://en.wikipedia.org/wiki/Pick_operating_system
http://www.youtube.com/watch?v=6ms0yvJAUAk

Otro tema: Hmmm... me quede pensando en el objeto intermedio que comentaba Mariano Martinez Peck en algun email, para implementar become:

y tambien remocion de memoria de objetos menos usados o por algun criterio... Escribo post sobre algunas ideas sobre eso, algo de implementacion, y aviso por aca.

Nos leemos!

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

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

2010/10/14 Francisco Garau <[hidden email]>

2010/10/13 Mariano Martinez Peck <[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...

No. Por lo que entiendo, Ephemerons tiene que ver mas que nada con la finalizacion de los objetos y un punto medio al GC. Algo más parecido a los WeakRegistry no?

Lo mio (vah, mi idea) es mas bien parecido a LOOM (large object oriented memory) o a lo que se conoce comunmente como memoria virtual.

Por curiosidad, cual es la motivacion? 

Tratar de usar menos memoria.

Poder usar Smalltalk en robots, smart card o cualquier tipo de hardware limitiado. Incluso en servers deployando web applications.
Porque que una imagen te ocupa 100mb en disco cuando en realidad frecuentemente usa el 20% ?

Hicimos un par de experimentos en una PharoCore despues de haberle heacho el clean para produccion, donde cargamos una web app hecha en seaside.....navegamos la app de punta a punta, con varios usuarios y blah...y sabes que porcentaje de objetos estabamos usando? menos del 10%. Y representaban el 15% de la memoria.   Y no es que hacia falta un GC. eso lo hicimos antes.
 

Pregunto porque me parece que la tendencia es al revés - es decir, traer todos los objetos a memoria. 

Tendencia de quien? prevalencia?  Lo que si es verdad, y es muy interesante es el otro approach, el estilo gemstone: los objetos viven siempre en disco, y solamente cuando se necesitan se pasan a ram, se usan, y luego vuelven al disco. Esto si es intersante y es la "solucion opuesta a la nuestra".

saludos

Mariano
 

- Francisco

 

--

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