Memory usage
Locked
12
12
 
|
Dear pharoers,
We are loading really big models in the Moose software analysis platform. This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. Thank you for your help. Cheers, --- Jannik Laval |
|
|
On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote:
> Dear pharoers, > > We are loading really big models in the Moose software analysis platform. > This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. > > Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. > It is possible to have an image of at least 7GB (I have done this on my PC with 8GB real memory). Currently this requires tracing the image to a 64-bit object format with SystemTracer, and running the image on an interpreter VM compiled for the 64-bit format. I expect that this will work for Moose in a Pharo image, although performance of the garbage collector is likely to become an issue as the memory grows with lots of smaller objects, and the 64-bit interpreter VM will be significantly slower than a 32-bit Cog VM. If you want to try this with one of your images, I'll try to give you some help. I believe that Eliot has longer term plans for 64-bit object formats, VMs, and improved garbage collectors. Dave |
|
|
The prospect sounds exciting.
Jannik, if you do manage to get this to work with Moose, it would be great to document it :) Cheers, Doru On Mon, Jul 23, 2012 at 2:15 PM, David T. Lewis <[hidden email]> wrote: > On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote: >> Dear pharoers, >> >> We are loading really big models in the Moose software analysis platform. >> This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. >> >> Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. >> > > It is possible to have an image of at least 7GB (I have done this on > my PC with 8GB real memory). Currently this requires tracing the image > to a 64-bit object format with SystemTracer, and running the image > on an interpreter VM compiled for the 64-bit format. > > I expect that this will work for Moose in a Pharo image, although > performance of the garbage collector is likely to become an issue > as the memory grows with lots of smaller objects, and the 64-bit > interpreter VM will be significantly slower than a 32-bit Cog VM. > > If you want to try this with one of your images, I'll try to give you > some help. > > I believe that Eliot has longer term plans for 64-bit object formats, > VMs, and improved garbage collectors. > > Dave > > -- www.tudorgirba.com "Every thing has its own flow" |
|
|
In reply to this post by David T. Lewis
Hi Dave,
Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? When I try it, it calls some methods that do not exist in Pharo. Do you have more information on how to use it ? Cheers, Jannik On Jul 23, 2012, at 2:15 PM, David T. Lewis wrote: > On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote: >> Dear pharoers, >> >> We are loading really big models in the Moose software analysis platform. >> This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. >> >> Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. >> > > It is possible to have an image of at least 7GB (I have done this on > my PC with 8GB real memory). Currently this requires tracing the image > to a 64-bit object format with SystemTracer, and running the image > on an interpreter VM compiled for the 64-bit format. > > I expect that this will work for Moose in a Pharo image, although > performance of the garbage collector is likely to become an issue > as the memory grows with lots of smaller objects, and the 64-bit > interpreter VM will be significantly slower than a 32-bit Cog VM. > > If you want to try this with one of your images, I'll try to give you > some help. > > I believe that Eliot has longer term plans for 64-bit object formats, > VMs, and improved garbage collectors. > > Dave > > --- Jannik Laval |
|
|
In reply to this post by Tudor Girba-2
Iep, I will keep all the informations and write a document.
Jannik On Jul 23, 2012, at 2:41 PM, Tudor Girba wrote: > The prospect sounds exciting. > > Jannik, if you do manage to get this to work with Moose, it would be > great to document it :) > > Cheers, > Doru > > On Mon, Jul 23, 2012 at 2:15 PM, David T. Lewis <[hidden email]> wrote: >> On Mon, Jul 23, 2012 at 09:26:18AM +0200, jannik.laval wrote: >>> Dear pharoers, >>> >>> We are loading really big models in the Moose software analysis platform. >>> This generate a lot of small objects and with the biggest model, we approach the limit of 2Gb of the VM. >>> >>> Is it possible for anyone who knows the VM to add extra memory space ? Going to 4Gb or maybe 8Gb would be a great thing. >>> >> >> It is possible to have an image of at least 7GB (I have done this on >> my PC with 8GB real memory). Currently this requires tracing the image >> to a 64-bit object format with SystemTracer, and running the image >> on an interpreter VM compiled for the 64-bit format. >> >> I expect that this will work for Moose in a Pharo image, although >> performance of the garbage collector is likely to become an issue >> as the memory grows with lots of smaller objects, and the 64-bit >> interpreter VM will be significantly slower than a 32-bit Cog VM. >> >> If you want to try this with one of your images, I'll try to give you >> some help. >> >> I believe that Eliot has longer term plans for 64-bit object formats, >> VMs, and improved garbage collectors. >> >> Dave >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > --- Jannik Laval |
|
|
In reply to this post by jannik laval
On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote:
> Hi Dave, > > Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? > When I try it, it calls some methods that do not exist in Pharo. > > Do you have more information on how to use it ? Hi Jannik, The system tracer is explained in the class comment of class SystemTracer. The comment was written by Dan Ingalls (I think), and gives credit to Ted Kaehler as the inventor of the original. Class SystemTracer2 has additional documentation including how to run the trace. SystemTracer2 is a newer version that you will actually be using, so you can think of SystemTracer as the original reference implementation, while SystemTracer2 and its subclasses are variations on the original. SystemTracer64 is the subclass that implements conversion logic for copying 32-bit objects into the experimental 64-bit object memory format. This object format is described in the SystemTracer64 class comment, and more information is available at http://squeakvm.org/squeak64. A system tracer will first put your image into a "quiet" mode, then copy and convert the running object memory to a new image file, and then wake up and return to normal. This is similar to saving your image and restarting from a disk file, except that the system tracer will trace your object memory to a new format rather than saving it unchanged. To trace your running image to a new 64-bit image file, you would do this: SystemTracer64 writeImage: 'new64bitImage.image' The last update I did to SystemTracer (SystemTracing-dtl.23) works with closure-enabled images, including Pharo at one time. I have a 64-bit Pharo 1.4 image that I made about a year and a half ago. I don't know what has changed in Pharo since then, so probably some updates will be needed, or possibly a Pharo-specific version. I know that others on the Pharo list have worked on this, so hopefully someone else can give you some pointers about that. Dave |
|
|
Hi Dave,
I begin with a small problem (is it ?): my os is the latest apple macos. It seems that there is no squeak vm 64 for macos (I did not find it). How can I build one "easily" ? Thanks, Jannik On Jul 24, 2012, at 2:04 PM, David T. Lewis <[hidden email]> wrote: > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: >> Hi Dave, >> >> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? >> When I try it, it calls some methods that do not exist in Pharo. >> >> Do you have more information on how to use it ? > > Hi Jannik, > > The system tracer is explained in the class comment of class SystemTracer. > The comment was written by Dan Ingalls (I think), and gives credit to Ted > Kaehler as the inventor of the original. Class SystemTracer2 has additional > documentation including how to run the trace. SystemTracer2 is a newer > version that you will actually be using, so you can think of SystemTracer > as the original reference implementation, while SystemTracer2 and its > subclasses are variations on the original. SystemTracer64 is the subclass > that implements conversion logic for copying 32-bit objects into the > experimental 64-bit object memory format. This object format is described > in the SystemTracer64 class comment, and more information is available at > http://squeakvm.org/squeak64. > > A system tracer will first put your image into a "quiet" mode, then copy > and convert the running object memory to a new image file, and then wake up > and return to normal. This is similar to saving your image and restarting > from a disk file, except that the system tracer will trace your object > memory to a new format rather than saving it unchanged. > > To trace your running image to a new 64-bit image file, you would do this: > > SystemTracer64 writeImage: 'new64bitImage.image' > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > closure-enabled images, including Pharo at one time. I have a 64-bit > Pharo 1.4 image that I made about a year and a half ago. I don't know > what has changed in Pharo since then, so probably some updates will be > needed, or possibly a Pharo-specific version. I know that others on the > Pharo list have worked on this, so hopefully someone else can give you > some pointers about that. > > Dave > > --- Jannik Laval |
|
|
Hi Jannik,
I am not a Mac user, and I have only ever done this on Linux, so I cannot promise that it will be easy. Possibly Esteban can give us some advice here, and correct my errors. Also, if you are going to try this, we may want to take the discussion to the vm-dev list. You will need to install the Mac tools for compiling Unix programs (sorry I do not know what this is called) and you will need to be able to compile programs using CMake and the gcc tools on a Mac. I know very little about this myself, but I'm sure others can give some tips. The actual VM that you will need to build will be an interpreter VM, and you will be building it with a preprocessor macro set to force use of the 64-bit object format. The resulting VM will be slow compared to what you are used to with Cog, and it may not have all the features that you would expect from a Mac VM (i.e. the VM that Esteban supports), but I expect that it should work on Mac and that it would allow you to run a 64-bit image prepared with the SystemTracer. As luck would have it, Ian Piumarta is in the process of updating the unix VM code right now, and this will make it easier to do the build for 64-bit images. I would say that we should wait a couple of days before starting any new work on this so that we have all of the latest updates. I'm not sure if this is something that you want to get into, and it is not what I would call "easy" ;) But if you want to try it I will do my best to step you through the process. Dave On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: > Hi Dave, > > I begin with a small problem (is it ?): my os is the latest apple macos. > It seems that there is no squeak vm 64 for macos (I did not find it). > > How can I build one "easily" ? > > Thanks, > Jannik > > On Jul 24, 2012, at 2:04 PM, David T. Lewis <[hidden email]> wrote: > > > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: > >> Hi Dave, > >> > >> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? > >> When I try it, it calls some methods that do not exist in Pharo. > >> > >> Do you have more information on how to use it ? > > > > Hi Jannik, > > > > The system tracer is explained in the class comment of class SystemTracer. > > The comment was written by Dan Ingalls (I think), and gives credit to Ted > > Kaehler as the inventor of the original. Class SystemTracer2 has additional > > documentation including how to run the trace. SystemTracer2 is a newer > > version that you will actually be using, so you can think of SystemTracer > > as the original reference implementation, while SystemTracer2 and its > > subclasses are variations on the original. SystemTracer64 is the subclass > > that implements conversion logic for copying 32-bit objects into the > > experimental 64-bit object memory format. This object format is described > > in the SystemTracer64 class comment, and more information is available at > > http://squeakvm.org/squeak64. > > > > A system tracer will first put your image into a "quiet" mode, then copy > > and convert the running object memory to a new image file, and then wake up > > and return to normal. This is similar to saving your image and restarting > > from a disk file, except that the system tracer will trace your object > > memory to a new format rather than saving it unchanged. > > > > To trace your running image to a new 64-bit image file, you would do this: > > > > SystemTracer64 writeImage: 'new64bitImage.image' > > > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > > closure-enabled images, including Pharo at one time. I have a 64-bit > > Pharo 1.4 image that I made about a year and a half ago. I don't know > > what has changed in Pharo since then, so probably some updates will be > > needed, or possibly a Pharo-specific version. I know that others on the > > Pharo list have worked on this, so hopefully someone else can give you > > some pointers about that. > > > > Dave > > > > > > --- > Jannik Laval > |
|
|
Hi guys,
I've been building the iOS StackVM for my own uses and am definitely interested in getting a 64-bit StackVM for some large data sets I'd like to load in RAM for some experiments. If there are pointers given, I am willing to test the build on my box. Phil 2012/7/31 David T. Lewis <[hidden email]> Hi Jannik, |
|
|
I don't know of anyone who has built a StackVM for the 64-bit object memory,
so this might require some development work. It would certainly be possible to do it, but I don't think that anyone has tried. Note that Eliot has plans for improved object memory formats, and the current 64-bit object memory is a "simplest thing that could possible work" conversion of the 32-bit object memory. I expect that Eliot would want to put his energy into the new object memory format(s), so a StackVM for the current 64-bit object memory would probably require someone to volunteer to do some development work. Dave On Tue, Jul 31, 2012 at 04:16:40PM +0200, [hidden email] wrote: > Hi guys, > > I've been building the iOS StackVM for my own uses and am definitely > interested in getting a 64-bit StackVM for some large data sets I'd like to > load in RAM for some experiments. > > If there are pointers given, I am willing to test the build on my box. > > Phil > > > 2012/7/31 David T. Lewis <[hidden email]> > > > Hi Jannik, > > > > I am not a Mac user, and I have only ever done this on Linux, so I cannot > > promise that it will be easy. Possibly Esteban can give us some advice > > here, > > and correct my errors. Also, if you are going to try this, we may want to > > take the discussion to the vm-dev list. > > > > You will need to install the Mac tools for compiling Unix programs (sorry > > I do not know what this is called) and you will need to be able to compile > > programs using CMake and the gcc tools on a Mac. I know very little about > > this myself, but I'm sure others can give some tips. > > > > The actual VM that you will need to build will be an interpreter VM, and > > you will be building it with a preprocessor macro set to force use of > > the 64-bit object format. The resulting VM will be slow compared to what > > you are used to with Cog, and it may not have all the features that you > > would expect from a Mac VM (i.e. the VM that Esteban supports), but I > > expect that it should work on Mac and that it would allow you to run a > > 64-bit image prepared with the SystemTracer. > > > > As luck would have it, Ian Piumarta is in the process of updating the unix > > VM code right now, and this will make it easier to do the build for 64-bit > > images. I would say that we should wait a couple of days before starting > > any new work on this so that we have all of the latest updates. > > > > I'm not sure if this is something that you want to get into, and it is not > > what I would call "easy" ;) But if you want to try it I will do my best > > to step you through the process. > > > > Dave > > > > > > On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: > > > Hi Dave, > > > > > > I begin with a small problem (is it ?): my os is the latest apple macos. > > > It seems that there is no squeak vm 64 for macos (I did not find it). > > > > > > How can I build one "easily" ? > > > > > > Thanks, > > > Jannik > > > > > > On Jul 24, 2012, at 2:04 PM, David T. Lewis <[hidden email]> wrote: > > > > > > > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: > > > >> Hi Dave, > > > >> > > > >> Should I load the SystemTracer available on SqueakSource ? The last > > version is from 2011, and seems old, no ? > > > >> When I try it, it calls some methods that do not exist in Pharo. > > > >> > > > >> Do you have more information on how to use it ? > > > > > > > > Hi Jannik, > > > > > > > > The system tracer is explained in the class comment of class > > SystemTracer. > > > > The comment was written by Dan Ingalls (I think), and gives credit to > > Ted > > > > Kaehler as the inventor of the original. Class SystemTracer2 has > > additional > > > > documentation including how to run the trace. SystemTracer2 is a newer > > > > version that you will actually be using, so you can think of > > SystemTracer > > > > as the original reference implementation, while SystemTracer2 and its > > > > subclasses are variations on the original. SystemTracer64 is the > > subclass > > > > that implements conversion logic for copying 32-bit objects into the > > > > experimental 64-bit object memory format. This object format is > > described > > > > in the SystemTracer64 class comment, and more information is available > > at > > > > http://squeakvm.org/squeak64. > > > > > > > > A system tracer will first put your image into a "quiet" mode, then > > copy > > > > and convert the running object memory to a new image file, and then > > wake up > > > > and return to normal. This is similar to saving your image and > > restarting > > > > from a disk file, except that the system tracer will trace your object > > > > memory to a new format rather than saving it unchanged. > > > > > > > > To trace your running image to a new 64-bit image file, you would do > > this: > > > > > > > > SystemTracer64 writeImage: 'new64bitImage.image' > > > > > > > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > > > > closure-enabled images, including Pharo at one time. I have a 64-bit > > > > Pharo 1.4 image that I made about a year and a half ago. I don't know > > > > what has changed in Pharo since then, so probably some updates will be > > > > needed, or possibly a Pharo-specific version. I know that others on the > > > > Pharo list have worked on this, so hopefully someone else can give you > > > > some pointers about that. > > > > > > > > Dave > > > > > > > > > > > > > > --- > > > Jannik Laval > > > > > > > |
|
|
In reply to this post by David T. Lewis
esteban has been fighting all day to compile the vm on mountain lion.
A problem with free type plugin not found dylib and friends. > Hi Jannik, > > I am not a Mac user, and I have only ever done this on Linux, so I cannot > promise that it will be easy. Possibly Esteban can give us some advice here, > and correct my errors. Also, if you are going to try this, we may want to > take the discussion to the vm-dev list. > > You will need to install the Mac tools for compiling Unix programs (sorry > I do not know what this is called) and you will need to be able to compile > programs using CMake and the gcc tools on a Mac. I know very little about > this myself, but I'm sure others can give some tips. > > The actual VM that you will need to build will be an interpreter VM, and > you will be building it with a preprocessor macro set to force use of > the 64-bit object format. The resulting VM will be slow compared to what > you are used to with Cog, and it may not have all the features that you > would expect from a Mac VM (i.e. the VM that Esteban supports), but I > expect that it should work on Mac and that it would allow you to run a > 64-bit image prepared with the SystemTracer. > > As luck would have it, Ian Piumarta is in the process of updating the unix > VM code right now, and this will make it easier to do the build for 64-bit > images. I would say that we should wait a couple of days before starting > any new work on this so that we have all of the latest updates. > > I'm not sure if this is something that you want to get into, and it is not > what I would call "easy" ;) But if you want to try it I will do my best > to step you through the process. > > Dave > > > On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: >> Hi Dave, >> >> I begin with a small problem (is it ?): my os is the latest apple macos. >> It seems that there is no squeak vm 64 for macos (I did not find it). >> >> How can I build one "easily" ? >> >> Thanks, >> Jannik >> >> On Jul 24, 2012, at 2:04 PM, David T. Lewis <[hidden email]> wrote: >> >>> On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: >>>> Hi Dave, >>>> >>>> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? >>>> When I try it, it calls some methods that do not exist in Pharo. >>>> >>>> Do you have more information on how to use it ? >>> >>> Hi Jannik, >>> >>> The system tracer is explained in the class comment of class SystemTracer. >>> The comment was written by Dan Ingalls (I think), and gives credit to Ted >>> Kaehler as the inventor of the original. Class SystemTracer2 has additional >>> documentation including how to run the trace. SystemTracer2 is a newer >>> version that you will actually be using, so you can think of SystemTracer >>> as the original reference implementation, while SystemTracer2 and its >>> subclasses are variations on the original. SystemTracer64 is the subclass >>> that implements conversion logic for copying 32-bit objects into the >>> experimental 64-bit object memory format. This object format is described >>> in the SystemTracer64 class comment, and more information is available at >>> http://squeakvm.org/squeak64. >>> >>> A system tracer will first put your image into a "quiet" mode, then copy >>> and convert the running object memory to a new image file, and then wake up >>> and return to normal. This is similar to saving your image and restarting >>> from a disk file, except that the system tracer will trace your object >>> memory to a new format rather than saving it unchanged. >>> >>> To trace your running image to a new 64-bit image file, you would do this: >>> >>> SystemTracer64 writeImage: 'new64bitImage.image' >>> >>> The last update I did to SystemTracer (SystemTracing-dtl.23) works with >>> closure-enabled images, including Pharo at one time. I have a 64-bit >>> Pharo 1.4 image that I made about a year and a half ago. I don't know >>> what has changed in Pharo since then, so probably some updates will be >>> needed, or possibly a Pharo-specific version. I know that others on the >>> Pharo list have worked on this, so hopefully someone else can give you >>> some pointers about that. >>> >>> Dave >>> >>> >> >> --- >> Jannik Laval >> > |
|
|
In reply to this post by jannik laval
David Lewis and I spent a far amount of time a few years back to make the 32 vm 4gb clean. So are you running on stale knowledge here, or does the vm crash when to goes over 2gb?
|
|
|
On Jul 31, 2012, at 11:46 PM, johnmci wrote: > David Lewis and I spent a far amount of time a few years back to make the 32 > vm 4gb clean. So are you running on stale knowledge here, or does the vm > crash when to goes over 2gb? sorry my english limit does not let me know understanding what you mean exactly. Jannik in the context of moose would like to see if we can have image larger than 500 mb (on mac it should be possible). Stef > > > > -- > View this message in context: http://forum.world.st/Memory-usage-tp4641108p4642349.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
|
|
A few years back the interpreted virtual machine was fixed to allow an image to grow to the 4 GB limit.
It is unclear to me if someone regressed the software to impose a 2GB limit again, or if the 2GB number
mentioned is based on how things worked10 years ago?
On Wed, Aug 1, 2012 at 5:01 AM, Stéphane Ducasse <[hidden email]> wrote:
=========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 =========================================================================== |
|
|
In reply to this post by David T. Lewis
I'm sure I built a vm for 64 bits a few years back, maybe not a stack one, can't remember
ya
On Tue, Jul 31, 2012 at 11:01 AM, David T. Lewis <[hidden email]> wrote: I don't know of anyone who has built a StackVM for the 64-bit object memory, =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 =========================================================================== |
|
|
In reply to this post by johnmci
On 1 August 2012 14:57, John McIntosh <[hidden email]> wrote:
> A few years back the interpreted virtual machine was fixed to allow an image > to grow to the 4 GB limit. > It is unclear to me if someone regressed the software to impose a 2GB limit > again, or if the 2GB number > mentioned is based on how things worked10 years ago? > > John, it is mainly about windows VM , where the limit is hardcoded to 512MB of virtual memory. I don't remember what exactly Andreas said about it, but he strongly does not recommends to go over that limit. (I played with the limit and tried a VM with 1GB limit.. it works fine, but i didn't tested it with images whose size is close to it) and maybe 2GB will work as well, but i haven't tried it. > On Wed, Aug 1, 2012 at 5:01 AM, Stéphane Ducasse <[hidden email]> > wrote: >> >> >> On Jul 31, 2012, at 11:46 PM, johnmci wrote: >> >> > David Lewis and I spent a far amount of time a few years back to make >> > the 32 >> > vm 4gb clean. So are you running on stale knowledge here, or does the vm >> > crash when to goes over 2gb? >> >> sorry my english limit does not let me know understanding what you mean >> exactly. >> Jannik in the context of moose would like to see if we can have image >> larger than 500 mb (on mac it should be possible). >> >> Stef >> >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Memory-usage-tp4641108p4642349.html >> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >> >> > > > > -- > =========================================================================== > John M. McIntosh <[hidden email]> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 > =========================================================================== > > > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by johnmci
Hi John,
There is no regression in the interpreter VM ... well actually there was about 6 months back, but I keep an eye on it and it's fixed again now :) The 32-bit interpreter VM will not fail on any 2GB or 4BG boundaries, and an interpreter VM compiled for the 64-bit object format can handle images greater than 7GB (probably much more, but my 8GB PC is too small to do anything larger). I'm not sure if all of the necessary fixes are in place for the StackVM and Cog. If not, I'm sure it will be addressed over time (it's just not something that I have ever checked). I believe that Jannik is interested in running very large images, at least on an experimental basis. For anything over a few GB, this requires an interpreter VM and a 64-bit image. As you know, this is sure to run into problems for the garbage collector as the number of objects increases, but it would certainly be interesting to see how far the current garbage collector can go in real world conditions before it turns to mollasses. Dave On Wed, Aug 01, 2012 at 08:57:02AM -0400, John McIntosh wrote: > A few years back the interpreted virtual machine was fixed to allow an > image to grow to the 4 GB limit. > It is unclear to me if someone regressed the software to impose a 2GB limit > again, or if the 2GB number > mentioned is based on how things worked10 years ago? > > On Wed, Aug 1, 2012 at 5:01 AM, St?phane Ducasse > <[hidden email]>wrote: > > > > > On Jul 31, 2012, at 11:46 PM, johnmci wrote: > > > > > David Lewis and I spent a far amount of time a few years back to make > > the 32 > > > vm 4gb clean. So are you running on stale knowledge here, or does the vm > > > crash when to goes over 2gb? > > > > sorry my english limit does not let me know understanding what you mean > > exactly. > > Jannik in the context of moose would like to see if we can have image > > larger than 500 mb (on mac it should be possible). > > > > Stef > > |
|
|
In reply to this post by johnmci
On Wed, Aug 01, 2012 at 09:04:20AM -0400, John McIntosh wrote:
> I'm sure I built a vm for 64 bits a few years back, maybe not a stack one, > can't remember > ya > http://lists.squeakfoundation.org/pipermail/vm-dev/2010-January/003732.html John: Thanks, I had forgotten about your 64*64 VM, I think it is probably exactly what Jannik needs :) Jannik: Please try the "64bitImage*64bitVM" image from John's site here: ftp://ftp.smalltalkconsulting.com/experimental/64bit/ If you can run that VM on your Mac, it should do exactly what you need. Try running that VM with one of your images. If it runs and gives you some sort of error message about not understanding the image format, that's good! That means all you need to do is trace your image to 64-bit object format, which should be fairly easy to do. Dave |
|
|
In reply to this post by jannik laval
Dave wrote:
>Please try the "64bitImage*64bitVM" image from John's site here: > ftp://ftp.smalltalkconsulting.com/experimental/64bit/ Loads and runs on my 10.7.3 MBA. >If you can run that VM on your Mac, it should do exactly what you need. >Try running that VM with one of your images. If it runs and gives you some >sort of error message about not understanding the image format, that's good! >That means all you need to do is trace your image to 64-bit object format, >which should be fairly easy to do. I loaded SystemTracing-dtl.23.mcz into a Pharo 1.4 one-click. SystemTracer2 writeImage: 'clone.image' results in a 88 byte clone image and hanging image, non-interuptable, caused by the popping up of a deprecation warning. Switching off the deprecation blocking leads to a debugger popup when trying to add the specialObjectArray. #'==' doesn't seem to work as a equalsBlock in Pharo. replaced by equalBlock: [:one :two | one == two]; The method SmalltalkImage extraVMMemory has been deprecated use Smalltalk vm extraVMMemory Then the tracing finishes. Trying to start the image results in 8/1/12 11:52:00.915 PM Squeak: openFile state 1 with file /Users/stephan/Documents/Sensus/sq64-dtl-32bitRGB/clone.image 8/1/12 11:52:01.098 PM Squeak: NSAlert is being used from a background thread, which is not safe. This is probably going to crash sometimes. Break on _NSAlertWarnUnsafeBackgroundThreadUsage to debug. This will be logged only once. This may break in the future. 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: Recursive not understood error encountered 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4423897840 SystemTracer2>writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4403075464 BlockClosure>ensure: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4407168048 SystemTracer2>writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4410156840 >writeImage: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4411453984 UndefinedObject>? 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4412035392 Compiler>evaluate:in:to:notifying:ifFail:logged: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4413449752 SmalltalkEditor>evaluateSelectionAndDo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414213432 BlockClosure>on:do: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414486112 SmalltalkEditor>evaluateSelectionAndDo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414725120 SmalltalkEditor>evaluateSelection 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4414946416 SmalltalkEditor>doIt 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4415487880 SmalltalkEditor>doIt: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4415621456 TextEditor>performCmdActionsWith:shifted:return: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416886344 TextEditor>dispatchCommandOn:return: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416913992 TextEditor>dispatchOn: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416972032 TextEditor>keystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4416996176 TextEditor>handleKeystrokeAction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417061696 TextEditor>handleEditionAction:fromKeyboardEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417061880 TextEditor>keystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417084280 TextMorph>basicKeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417143280 TextMorph>handleInteraction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417163504 TextMorphForEditView>handleInteraction: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417163720 TextMorph>basicKeyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417214616 TextMorph>keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417234096 >codeCompletionAround:textMorph:keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417279920 ToolRegistry>codeCompletionAround:textMorph:keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417280104 TextMorph>keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417299408 TextMorphForEditView>keyStroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417350856 TextMorph>handleKeystroke: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417369760 KeyboardEvent>sentTo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417417472 Morph>handleEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417435496 Morph>handleFocusEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417476608 HandMorph>sendFocusEvent:to:clear: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417494152 PasteUpMorph>becomeActiveDuring: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417537816 BlockClosure>on:do: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417555368 PasteUpMorph>becomeActiveDuring: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417538040 HandMorph>sendFocusEvent:to:clear: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417555608 HandMorph>sendEvent:focus:clear: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417596488 HandMorph>sendKeyboardEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417613392 HandMorph>handleEvent: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417651096 HandMorph>processEvents 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417667760 WorldState>doOneCycleNowFor: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417707560 SequenceableCollection>do: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417724176 WorldState>handsDo: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417724360 WorldState>doOneCycleNowFor: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417764312 WorldState>doOneCycleFor: 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417780816 PasteUpMorph>doOneCycle 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417817600 MorphicUIManager>spawnNewProcess 8/1/12 11:52:04.044 PM [0x0-0x3c13c1].org.squeak.Squeak: 4417833464 BlockClosure>newProcess 8/1/12 11:52:04.051 PM com.apple.launchd.peruser.501: ([0x0-0x3c13c1].org.squeak.Squeak[22436]) Exited with code: 255 Stephan |
|
|
Guillermo Polito has been updating SystemTracer to latest Pharo (and Cog). I think you should try to use that.
On Wed, Aug 1, 2012 at 11:54 PM, Stephan Eggermont <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |