Ouch this is why we will have to think hard on our next priorities. Stef
On Jul 9, 2013, at 3:49 PM, Esteban Lorenzano <esteba...@gmail.com> wrote: > In fact, problem is even worst. I wanted to watch how the GC behaves over > 500m of memory occupied. > I though on a test that would create/destroy objects in a regular basis, > after filling the memory. > > So, to start I ran this simple script (it was just a start, not the real test > I thought): > > objectQuantity := 1024 * 1024. > objectSize := 1024. > objects := Array new: objectQuantity. > > 1 to: objectQuantity do: [ :index | objects at: index put: (ByteArray new: > objectSize) ]. > > objects inspect. > > FileStream stdout > << Smalltalk vm statisticsReport > << '=================' << String cr. > > > The idea is to keep in memory a real big array with elements of 1024 bytes > size each. That should fill memory up to 1G+size of array+rest of the system. > > Well, this are the results: > > OSX: VM crash (in 530m) > Linux: VM crash (in ~1G) > Win: Didn't even tried. > > Same script with: > > objectQuantity := 512 * 1024. > > OSX: VM crash (in 530m) > Linux: PASSES! > Win: Didn't even tried. > > Same script with: > > objectQuantity := 248 * 1024. > > OSX: PASSES! > Linux: PASSES! > Win: Didn't tried, but it should pass since memory is < 512m. > > Anyway... situation is far from good, IMO. > > Esteban > > > On Jul 9, 2013, at 10:11 AM, Stéphane Ducasse <stephane.duca...@inria.fr> > wrote: > >>>> >>>> >>> >>> If you reserve most of memory for objects, think how you could use things >>> like >>> freetype, opengl, cairo & any other library which allocates memory on >>> conventional heap. >>> also, think that DLLs and kernel needs breathing space as well. >> >> But is it not the same on mac? >> I thought that it was a problem with the memory fragmentation on windows. >> >> Stef > >
