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