However GCC applications already store data (such as browser cache) into the high area.
Only when they are programmed to do so. It looks, to me, like very few actually do that by default. Of course, you do need the ArcaOS kernel patches to be able to use it successfully, so it would be silly for programs to automatically use high shared memory since not all users have upgraded.
I wonder if it would be possible in theory to create a 'memory defragmentation' daemon that monitors memory and warns when fragments get below a specified size (or even better, defrags when needed)?
Of course, it is "possible". The problem would be to find somebody who can do it. I doubt if anybody knows enough about how it works, to be able to do anything about it.
but what is the value when you should be warned about to 'low' memory?
I use Above512 with a REXX script, that displays, and logs, the results every second. I have seen lower shared memory completely disappear from 100 MB (crash, before it logged 0 MB), and I have seen it run successfully with 1 MB left. If there was some way to intercept the request, and be sure that it would be successful, before returning to the program, a warning could be issued, and the user could be allowed to close other programs, then tell the interceptor to check again, to see if it would be successful, and return to the program if it is okay (the programs should do that themselves, but it seems that most do not, and that may not even be the programmers fault).
Arent't there set to load high by default?
Not from what I have seen (but it has been a while since I looked). You can't do that, without having a separate set of DLLs for those systems than can use upper shared memory, and for those that can't use upper shared memory.
How to know all dll's which aren't set to be loaded into high storage area?
HIGHMEM.EXE (it is included in Open Office) will tell you. It can also set DLLs to load data and/or code high, or reset them to load low. Be warned that simply setting all DLLs to load high will probably not work well, and some programs may work with individual DLLs loaded high, while others won't. I find that it is best to leave the common DLLs (in RPM/YUM) alone, and only play with the program specific DLLs (such as XUL.DLL in mozilla).
Some experimenting is required, because each user has a different set of programs that they use, in different ways.