By tweaking the plist on OSX I was able to allocate much more than what you mention. See other mails in the list. Phil On Tue, Jul 9, 2013 at 9:09 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
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 <estebanlm@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.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