AllocationTest >> #testOutOfMemorySignal

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

>
>