Ah!
Gracias por la info, ire a verla. Lo que yo estaba pensando en el desayuno de hoy, es esto: Los slots de los objetos, tienen “puntero” a objeto intermedio (en esta jerga de este thread, lo que describio Mariano). Ese objeto intermedio apunta al objeto real. Una de las ventajas, es implementar become: Lo que pensaba implementar es: OI à ObjetoReal (eso es lo de arriba) Pero si necesito depurar las llamads del ObjetoReal, no lo pongo en el OI, sino que pongo en el medio, un Nuevo intermedio, especializado en depurar, loguear, lo que sea: OI -> Depurador/Logueador -> ObjetoReal El OI lo dejaria para lo minimo, tal vez, para implementar lo de objeto menos usado para serializarlo en algun momento, para liberar memoria. (podria llamar al Depurador/Logueador un Decorator en design patterns?) Si el dia de maniana, quiero tener lazy loading del objeto real OI -> ObjetoQueTieneTodoParaHacerLazyLoading del objeto real Cuando serialize el objeto a disco, por cualquier cosa que decide: OI -> ObjetoQueTieneLaInformacionDeSerializacion Cuando el objeto lo migre a otra maquina, y no quiero que quede como local (es decir, migramos una copia, pero la original local quiero que derive a la migrada en otro nodo): OI -> ObjetoProxyANodoRemoto Si estoy depurando localmente: OI -> Depurador -> ObjetoProxyANodoremoto En casi de que un Slot en un objeto X apunte a OI: ObjetoX/SlotN à OI Y en una transaccion T1 modifico ese eslot, pero la transaccion T2 todavia necesita ver el valor original, quedaria ObjetoX/SlotN -> MultiValue Y ese MultiValue me va a: MultiValue -> OIOriginal Cuando estoy en T2, y me va a: MultiValue -> OINuevoDeT1 Cuando estoy en T1. No es fino? ;-) En resumen, podriamos encadenar objetos. En mi implementacion, todos serian implementacion de IObject (de hecho, podria poner un objeto intermedia ahora mismo, cambiando unas pocas lineas, corriendo los tests, y voila). Algunas veces, el objeto intermedio tendra mas objetos “a la derecha” de la cadena. El unico caso que vi digamos “contraviarante”, es tener un objeto a izquierda de IO, es lo que discutimos del tema transacciones en otro thread. Nos leemos! Angel “Java” Lopez http://www.ajlopez.com http://twitter.com/ajlopez From: [email protected] [mailto:[email protected]] On Behalf Of Mariano Martinez Peck Sent: Thursday, October 14, 2010 11:14 AM To: [email protected] Subject: Re: [clubSmalltalk] Objetos Distribuidos 2010/10/14 Angel Java Lopez <[email protected]> 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: En realidad eso era solamente una de las ventajas :) Lo groso es que podes lograr reflexion de la puta madre. O sea, tal vez, podrías (habría que pensarlo y ver si se puede pero seguro que si), darle comportamiento a ese objeto intermedio. Podrías decir de que clase son, implementar algun handler (al estilo run:with:in , cannotInterpret: o algo asi), y que te permita, no se...sacar estadisticas, logear, hacer de proxy, etc. Acá en mi lab lo están haciendo para tener "read only" memory y poder soportar mejor memoria transaccional y blah. Adrian Lienhard hizo algo parecido para su tesis, de puta madre dicho sea de paso. Les recomiendo a todos que la lean si tienen tiempo: http://www.iam.unibe.ch/~scg/Archive/PhD/lienhard-phd.pdf 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 <[email protected]> 2010/10/14 Francisco Garau <[email protected]> 2010/10/13 Mariano Martinez Peck <[email protected]> 2010/10/13 Andres Valloud <[email protected]> > 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 [email protected] To unsubscribe from this group, send email to [email protected] <mailto:clubsmalltalk%[email protected]> http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] <mailto:clubsmalltalk%[email protected]> http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] <mailto:clubsmalltalk%[email protected]> http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
