From: <bil...@mi...> - 2012-09-25 18:06:02
|
I've been using macports to generate a threads image for MacOSX: sbcl @1.0.58_0+threads This seems to work ok, but I'm having a problem with saved images using up heap space. If I save the image and run it on my machine, it will quickly fail, running out of heap. If I save the image using :save-runtime-options T, it doesn't run out of heap space. My machine is a dual core. If I ship the image (the one saved using :save-runtime-options T) to a quad core, it again quickly runs out of heap space. I'm using mcclim (latest as downloaded and installed using quicklisp), and I've been using threads, but my code should start no more than 2 threads, yet all 4 cores are getting used heavily when the interface is doing nothing but waiting for some heavy computing in my application to run (in no more than 2 threads that I'm starting explicitly). Thoughts? Anyone else see anything like this? Specific info that would be useful? Thanks |
From: Nikodemus S. <nik...@ra...> - 2012-09-26 06:11:26
|
On Tuesday, September 25, 2012, wrote: > I've been using macports to generate a threads image for MacOSX: sbcl > @1.0.58_0+threads > > This seems to work ok, but I'm having a problem with saved images using up > heap space. If I save the image and run it on my machine, it will quickly > fail, running out of heap. If I save the image using :save-runtime-options > T, it doesn't run out of heap space. Saving runtime options saves any --dynamic-space-size you've set. Possibly you're providing that in wrong part of the commandline when running the app? You can check the size of the heap using (sb-ext:dynamic-space-size). My machine is a dual core. If I ship the image (the one saved using > :save-runtime-options T) to a quad core, it again quickly runs out of heap > space. No ideas here. I'm using mcclim (latest as downloaded and installed using quicklisp), and > I've been using threads, but my code should start no more than 2 threads, > yet all 4 cores are getting used heavily when the interface is doing > nothing but waiting for some heavy computing in my application to run (in > no more than 2 threads that I'm starting explicitly). - n > > Monitor (sb-thread:list-all-threads) to verify the number of threads? -- Sent from a tablet, sorry about the top-post and sloppy editing. |