[squeak-dev] AllocationTest >> #testOutOfMemorySignal

Levente Uzonyi leves at caesar.elte.hu
Thu Apr 30 11:06:29 UTC 2020


On Thu, 30 Apr 2020, Marcel Taeumel wrote:

> Hi all!
> 
> The VM 202004292351 (cog.spur 64-bit) triggers an interesting system crash on my Surface Pro 6 while having a Skype video call. At that time, the VM process uses about 11-12 GiB of memory.

I avoid running AllocationTest when possible.
#testOutOfMemorySignal and testOneGigAllocation will temporarily freeze 
the whole OS and grind your hard drive if you have enough RAM to fit a 
single allocation attempt and swap is enabled - a combination quite common 
these days.
The tests are also miscounting the allocated chunk size, because they (try 
to) allocate Arrays but calculate sizes in bytes, so they'll allocate 
(and zero fill) 4x-8x more memory than intended.
I think they only worked well on old machines because, due to the 
miscalculation of the size, a single allocation was larger than the 
available RAM. But nowadays the best they can produce is a timeout.

> 
> I have two questions:
> 
> 1. Why does primitive 254 fail when setting VM parameter 67 in 32-bit to 1688449936? It works on 64-bit. 1.6 GiB memory is not that much.
> 2. Is it really necessary to stress the system that much in AllocationTest >> #testOutOfMemorySignal ? It tries to allocate 1 terabyte of memory.
> 
> I know that the system crash is not the VM's fault. But it is mildly annoying. ;-)

Getting OutOfMemory signaled is pretty hard nowadays especially on 
machines with lots of RAM. We're getting really close to the test's 
assumption of unobtainable memory limit (4/8 TB) as you can buy machines 
with 6 TB of RAM today.

Because of those above, I suggest removing these tests unless someone is 
able to fix them.

> 
> Best,
> Marcel
> 
> P.S.: FYI, the system crashes with a blue screen because VIDEO_SCHEDULER_INTERNAL_ERROR

That's a windows bug.


Levente

> 
>


More information about the Squeak-dev mailing list