7za can't allocate required memory.

[kvdman]

Tested on GCC4 hybrid rev. 38892 on Vmware.

7za version is 9.04 Beta.

I'm trying to compress a 400mb directory using this command:

7za a -t7z -mx=9 archive.7z directory

The machine with 512mb of RAM won't even start compressing the archive, returning:

'can't allocate required memory.'

I upped the memory to 1.5gb, restarted, and retried.

The same error came up with the archive compressed to 90%...

I don't think this is normal behaviour that it needs to store everything in RAM?

[anevilyak]

Do you have swap enabled?

[scottmc]

Can you try 9.13 and see if it works any better? ​http://haiku-files.org/files/optional-packages/p7zip-9.13-x86-gcc2-2010-10-07.zip ​http://haiku-files.org/files/optional-packages/p7zip-9.13-x86-gcc4-2010-10-07.zip

[kvdman]

swap was not enabled. will retry the command with 512mb physical RAM, 256mb virtual RAM, and 7za 9.13.

[kvdman]

I retried with 7za 9.13, 512mb of RAM, 32mb Swap.

I am just using a vmware image with limited disk space so couldn't up the swap.

In any case, the compression of the directory still fails with the above mentioned error.

I just find it hard to believe you can't compress a 400mb directory with 512mb of RAM and no virtual memory.

Should I try in a WinXP VM with the same RAM and swap and post results?

[kvdman]

Interesting. Using 7-Zip file manager on WinXP to compress a 450mb file, it tells you it'll will require 708mb of RAM (has a neat GUI).

I set the VM to have 512mb of RAM with no paging file.

During the compression process, a Windows System message pops up notifying me that the 'Windows Virtual Memory' is too low. Windows automatically increased the size of the virtual memory paging file during the process, and the process completed without error.

It's neat that WinXP can compensate (system wide) for situations when there isn't enough physical RAM available... I guess it shows a limitation and perhaps improvement that could be applied for Haiku's Memory manager?

So in the end, I guess the ticket is invalid.

[anevilyak]

This is primarily due to Haiku's VM currently not allowing overcommits, for which a ticket exists somewhere that I can't currently find. But yes, being able to dynamically resizing the swapfile would be nice to have eventually as well.

[axeld]

It actually does support overcommitting, but it does so only where it makes sense. It's not helpful to let an allocation succeed when the system has no means to make it work (instead of failing early on, such an application would then just crash later on).

IOW it's not a current limitation, it's the way all sane operating systems work :-)

[kvdman]

'IOW it's not a current limitation, it's the way all sane operating systems work :-)'

To me the limitation in Haiku is you can't 7zip a 400mb directory with 512mb of RAM whereas in an almost 10 year old Windows you can (automatically, simple to use and void of any unnecessary complexities).

[tangobravo]

It might be neat to automatically enable/increase the size of your swap file (which should be filed as a new enhancement).

However, you said in kvdman:

I retried with 7za 9.13, 512mb of RAM, 32mb Swap. I am just using a vmware image with limited disk space so couldn't up the swap.

...so I fail to see what you expect Haiku to do here. If you don't have enough free bytes in your RAM + disk there's no way around an "out of memory" error.

[kvdman]

I could easily increase the disk space to accomodate more virtual memory which would solve the error (manually), I'm guessing.

What I'm trying to say, is that I don't think Haiku has an automatic mechanism built-in that will attempt to a) make or enable a swap file if there isn't one in the first place b) increase the swap file if it isn't sufficient to complete a memory hungry task - as in WinXP. I could see this scenario happening in a lot of applications.

I'm not expecting Haiku to do magic, and there's obviously nothing Haiku can do if there's no memory or disk space left (that was just a bad example).