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.ducasse@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