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
>
>