Swap issue also on Update 4 ?

[Hypex]

What I don't understand is why this "feature" affects normal operating conditions. IIRC OS4 VM was so that when memory was low it could be swapped to disk and also allow programs to virtually allocate larger chunks of memory for files and have the OS load file chunks in when needed. As well as the VM mapping logical to physical which OS4.0 had.

In other words, if the memory is too full then why does OS4 allow this to happen? Without swap OS4 worked fine. So why doesn't OS4 reserve some real memory to compensate? I could also ask the same about low VRAM conditions where OS3 had emergency chip RAM reserved.

The way I see it, if the system is overloaded and is about to go into a Windows style HD thrashing fest, then OS4 should deny an allocation and return NULL. OF course there is the size of swap which would determine maximum amount of virtual memory or at least what space it had. OS4 does need some overhead to manage the swaps so they don't get out of hand.

Now as to the RAM disk, swapping this to disk doesn't make sense, because the point of the RAM disk was to be in memory. With VM I can see a conflict in that arrangement. And can see that as it has a dynamic size it would be hard to allocate a large virtual size in place. Though if possible it did that instead it might be more manageable. Even if we then had to deal with memory fragmentation.

Abusing of MEMF_PUBLIC also comes into this equation along with the introduced MEMF_SHARED to compensate for that. Though with 68K "abusing" programs restricted to their own space (64MB was it?) and OS4 programs being compliant (how can we check?) this should be less of an issue.

Now, after all that, an immediate solution becomes apparent. Simply disable the swap partition!

And it has been said that with 2GB of RAM OS4 doesn't need swap memory. So perhaps what would be best is if an extra 2GB could be bolted onto the hardware and use that!

[Deniil]

Yes, one of the problems is the type of storage that RAM uses (MEMF_SHARED). If it were MEMF_PRIVATE, then the memory occupied by the RAM Disk could be swapped out to allow other data into RAM. But that means a quantum change in the way that RAM has been understood in the past - for instance, what happens if you load a program into RAM, execute it from RAM, and the first thing it does is to fill the RAM disk with big photos? Can the program itself be swapped out? What happens if it is? How can you prevent it being swapped out? The program is only another file, after all.

Of course the program can be swapped out. If it has already been executed it is irrelevant what happens to the executable file, wherever it is. Remember that you are also allowed to detele a running executable from disk, so swapping it out is no problem. And even if it would be swapped out and is later needed (by for example the Grim Reaper) it would simply be swapped in again transparantly. That's how swapping is (supposed to be) working.

Unfortunately, RAM's storage is only part of it. I've tried changing RAM to allocate only MEMF_PRIVATE, and it is not a cure-all, there are other effects still there, that may not be caused by the ram-handler.

As I said, a simple change won't fix the problem.
We're working on it.

I'm not surprised there may be side-effects to the ram-handler using private memory, but it's good to hear you're working on it.

But back to the root point: AmigaOS should never freeze when it runs out of memory!!!!! It should return NULL to the caller forcing it into a deadend corner instead of doing whatever it does, looping forever trying to free something or whatever it does causing the freeze. I mean when trying to allocate something huge, like 500MB with only 10MB free it does return NULL, but not when someone allocates many small chunks until it runs out.