On 14 January 2012 14:41, Milan Mimica <milan.mimica@gmail.com> wrote:
The 2Gb limit has nothing to do with where the image is stored. The limit is in the image itself. The image on the SSD drive cannot be your working image because Pharo works on a *copy* of the image, not on the image itself. That is by design - otherwise you wouldn't have the possibility to rollback to a last saved image.
VM just loads an image from file into memory, and then just continues running it. And once it started you can delete file on disk without any consequences. In other words, it is not important where you get the object memory snapshot from: be it file on hard drive or downloaded from network node or residing in ROM. It used only at booting stage of VM, and then it operates with it in memory, without accessing external storage anymore. But this is squeak VM. A Gemstone one constantly using external storage for loading/storing modified pages of object memory, so it not necessary needs to hold a full object memory in RAM, only portion of it. And yes, it allows Giga-Terrabytes big "images" i.e. object memory size.
On 14 January 2012 14:08, Guido Stepken <gstepken@googlemail.com> wrote:
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls?
Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com>:
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net
-- Milan Mimica http://sparklet.sf.net
-- Best regards, Igor Stasenko.