[Pharo-project] Memory usage
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 <lewis@mail.msen.com> 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"
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 <lewis@mail.msen.com> 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
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
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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com> 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 <lewis@mail.msen.com>
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 <lewis@mail.msen.com> 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
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, phil@highoctane.be 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 <lewis@mail.msen.com>
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 <lewis@mail.msen.com> 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
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 On Tue, Jul 31, 2012 at 11:01 AM, David T. Lewis <lewis@mail.msen.com>wrote:
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, phil@highoctane.be 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 <lewis@mail.msen.com>
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 <lewis@mail.msen.com> 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
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 ===========================================================================
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
Thank you ! I will try it in few days. Cheers, Jannik On Aug 1, 2012, at 8:35 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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
--- Jannik Laval
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 <lewis@mail.msen.com> 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
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? -- View this message in context: http://forum.world.st/Memory-usage-tp4641108p4642349.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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 <stephane.ducasse@inria.fr>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 <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 ===========================================================================
On 1 August 2012 14:57, John McIntosh <johnmci@smalltalkconsulting.com> 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 <stephane.ducasse@inria.fr> 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 <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com iPhone Apps. http://www.wikiserver.com Twitter: squeaker68882 ===========================================================================
-- Best regards, Igor Stasenko.
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 <stephane.ducasse@inria.fr>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
Hi, I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm. The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb. I will try the 64bits vm, and see. Cheers, Jannik On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik was the system usable? Because the problem with more memory is that you need specific GCes. Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
On Aug 2, 2012, at 10:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik
was the system usable? Because the problem with more memory is that you need specific GCes.
It seems. I built a DSM on a 1300 packages system. Jannik
Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
--- Jannik Laval
Not bad :) Doru On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval@gmail.com> wrote:
On Aug 2, 2012, at 10:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik
was the system usable? Because the problem with more memory is that you need specific GCes.
It seems. I built a DSM on a 1300 packages system.
Jannik
Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
--- Jannik Laval
-- www.tudorgirba.com "Every thing has its own flow"
so this means that the comment of Fabrizio about the limit of 500 mb was only for windows. Stef
Not bad :)
Doru
On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval@gmail.com> wrote:
On Aug 2, 2012, at 10:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik
was the system usable? Because the problem with more memory is that you need specific GCes.
It seems. I built a DSM on a 1300 packages system.
Jannik
Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
--- Jannik Laval
-- www.tudorgirba.com
"Every thing has its own flow"
Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(. But, I think the experiment of Jannik was done with the special 64-bit VM. Jannik, am I right? Cheers, Doru On 3 Aug 2012, at 15:00, Stéphane Ducasse wrote:
so this means that the comment of Fabrizio about the limit of 500 mb was only for windows.
Stef
Not bad :)
Doru
On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval@gmail.com> wrote:
On Aug 2, 2012, at 10:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik
was the system usable? Because the problem with more memory is that you need specific GCes.
It seems. I built a DSM on a 1300 packages system.
Jannik
Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
--- Jannik Laval
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."
No, no, The experiment was made with the VM included in the one-click Moose, in a MacOs X 10.8. For now, I do not succeed to use the 64bit VM and build a usable 64bit image. Jannik On Aug 3, 2012, at 10:09 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(.
But, I think the experiment of Jannik was done with the special 64-bit VM. Jannik, am I right?
Cheers, Doru
On 3 Aug 2012, at 15:00, Stéphane Ducasse wrote:
so this means that the comment of Fabrizio about the limit of 500 mb was only for windows.
Stef
Not bad :)
Doru
On Fri, Aug 3, 2012 at 8:11 AM, jannik.laval <jannik.laval@gmail.com> wrote:
On Aug 2, 2012, at 10:28 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 2, 2012, at 10:17 PM, jannik.laval wrote:
Hi,
I tried the VM included in Moose (moosetechnology.org). If I remember well, it is a cog vm.
The maximal heap size is (precisely): 2138046463 bytes. Why this number ? I don't know. But I will need more than 2Gb.
HI jannik
was the system usable? Because the problem with more memory is that you need specific GCes.
It seems. I built a DSM on a 1300 packages system.
Jannik
Stef
I will try the 64bits vm, and see.
Cheers, Jannik
On Aug 1, 2012, at 7:51 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 <stephane.ducasse@inria.fr>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
--- Jannik Laval
--- Jannik Laval
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."
--- Jannik Laval
Yes, for Windows, 500MB is a rather hard limit with Cog. I bump into it all the time :(.
I imagine well, believe me and I'm a bit sad about all the story around VMs. I see all the infrastructure that igor built and there is not much cooperation around it even if esteban happily uses it and build on top. I see igor's fixes not even commented by other VM maintainers, probably too busy. So I have the impression that soon or later we will have to take our responsibilities but I would have preferred another situation with more collaboration. Anyway this is like that and we have to grow our knowledge on VMs. Because we can be the best on image side, if there is nobody to improve the VMs we will all be dead. Funnily google contacted igor, esteban and camillo to work on VMs for them. Now we will see I hope that the consortium will bring enough money to pay one guy to work on that. RMOD will put 6 months salary on the table for sure to pay igor. Stef
participants (8)
-
David T. Lewis -
Igor Stasenko -
jannik.laval -
John McIntosh -
johnmci
-
phil＠highoctane.be -
Stéphane Ducasse -
Tudor Girba