Too bad we can't design some protocol for applications to "work together" to ensure each has the memory they need. Like some sort of "application collective memory management" where each application has certain memory it needs/wants and depending on the priority of that need and the current priorities of the other applications, it could know to reduce memory usage during those times when some other application has a higher priority. For one, it would help in your case, because background video processing might be a lower priority, or perhaps you want it to finish as fast as possible, so that Firefox and etc. just "freeze" themselves for a while and drop as much memory as is practicable (ie: deleting currently rendered pages from memory and re-rendering them later, or paging those out to disk for a while).
The E/Agoric people have been trying to steer the whole thing in the cryptocurrency direction for about 35 years now, some of them for more than 50 years. If you are enthusiastic about their previous work, consider that possibly they might have been right about this, however unfashionable cryptocurrency might be on HN this year.
Eh. They’ve certainly always foresaw people using capability systems they were building to sell computing services to each other, but I don’t see anything pointing to the particular stylized flavour of computing of cryptographic smart contracts before those developed independently(?) over the last decade.
While I’ll admit that I find the corporate gloss of the Agoric website thoroughly repulsive, I would actually like to see cryptocurrencies succeed as a boring payment instrument. It’s just that my interests have always lain more in userspace resource allocation (etc.) among applications on a single machine, and in that context both E and the original agoric papers are completely separable from their money aspects, while any developments in the cryptographic consensus direction seem unlikely to be. Conversely, it’s not like the original object-capability work seems universally attractive to me—Shapiro advocated some system mechanisms that are, as far as I can tell, DRM-complete. But those are, again, separable from the rest of the ideas.
It's definitely true that E smart contracts were conceived to run on a secured server (or in tamperproof hardware), which was known to be feasible, rather than via a decentralized consensus mechanism, which was not. But they've been building smart contracts since last millennium.
Moreover, they didn't just foresee people selling computing services to each other; some of them built what we would call cloud computing platforms where the platform owner sold computation and the platform users could sell services to each other on it, starting in 01968, which was successful for decades: https://en.wikipedia.org/wiki/Tymshare
That's the experience that gave rise to the object-capability approach in the first place.
And, as far as I know, the Digital Silk Road paper from Agorics was the first workable proposal for a secure decentralized digital money.
It doesn't work very well and can't be made to work better. free()ing memory doesn't return memory to the system fast enough and it's easy to accidentally create more memory pressure while trying to respond to this (like by touching a page that's compressed/swapped out).
The only safe thing you can do is free entire pages at once, but that's not necessarily effective.
Of course you can only return pages at a time. That is the minimum size virtual memory works in.
You don't want malloc to instantly release memory to the system on free(), and malloc() is then constrained by the same page multiple at a time restriction as anything else so it can't release fragmented memory.
What you should be doing is trying to save state so that you can return to original state, not fighting to keep going.
