What’s your point? memmove() is just an overlap-safe memcpy(), trivially implemented with variable direction and atomic width.

Handling OOM in a complex application is so difficult that I think it’s more honest to make the default be a panic–that’s what most of the complex C code bases I’ve worked in do, either explicitly or (ugh) by missing enough null checks that they’re going to fault quickly anyway. It is often a better strategy to just panic and let the supervisor start over than to attempt to actually handle every possible OOM in a stable way.

Yes, but it’s important to point out that there’s an opt out strategy available. It definitely won’t make everyone happy of course right now, but it’s there! :-)

Big and complex applications often have lots of freeable data floating around for a purpose. Like, look at your browser. It caches tons of stuff for performance. But as soon as that memory is really needed for something, they can just drop it.

Games, mapping applications, image editors, etcetra tend to have lots of data and assets that are worth keeping loaded in memory if there’s enough if it, but can always be reloaded if needed.

Another example would be a chat client that keeps logs. It’s a nice feature, but it’s not cool to crash when an alloc failed because there’s a gigabyte of history.

Some of these applications often self-regulate by imposing some arbitrary limit on the caches, history, etc. But it is more about being nice (not consuming too many resources, for arbitrary definition of too many) and optimistic (“if we only use this much, we probably won’t run out of memory.. on a system that doesn’t run a lot of other stuff”) than it is a solution.

Some applications cache data to the disk to conserve memory. It’s a shame we don’t have good apis for having a little discussion about memory use with the system; it would be nice if we could let applications either allow the system to swap data out for them, or let them voluntarily go of that data to make room for others.

I don’t know why people keep perpetuating the myth that there’s practically nothing you can do about OOM. If anything, I think dealing with memory exhaustion should be more important today than ever before as applications have grown in complexity and often can slurp as much RAM as they are given while people run on them multitasking systems with more than order-of-magnitude differences on the available memory. The said systems are often busy with a multitude of such memory hungry applications simultaneously.

Ideally, if an application that really can’t recover from OOM by freeing stuff of its own, the system could ask the browser and the games and other stuff to make some room, which should amount to the same procedure that they’d run themselves when an alloc of their own fails.

The solutions we use now are pretty spartan and frankly shit. Linux with overcommit grabs the OOM killer and kills random shit, which is absurd, except maybe as a last resort after other, better solutions have been exhausted. Other systems actually let allocs fail, and may employ rlimits to constrain the processes and hopefully leave enough breathing room for everyone. It might or might not help. But it’s hard to make rlimits right when an application can use anywhere between 50 megabytes and a dozen gigabytes, on a system that might have 512MB or 32GB. It helps even less when so many applications are written with the prevailing mentality from GNU/Linux land. What hurts me most is that people keep perpetuating the myth and discouraging people from actually caring about memory exhaustion and recovery.

A “please collect your garbage now” signal (with a size hint?) could be a good start.

People downvoting this to zero might consider asking themselves how it is that C and C++ programs, or Python and Ruby servers with their heavy heap usage and 100s of megabytes of short-lived garbage generated per-request, nevertheless somehow manage to survive in production with months or more of uptime without being crippled by the dread spectre of physical memory fragmentation due to their total lack of memory compaction.

[Comment removed by author]

Before my time, I’m not sure.

I note that the Russian government has expressed interest in ReactOS, and funded developers. Russia also has an indigenous CPU architecture too, that’s VLIW and good at emulating x86, like a Transmeta CPU. (In fact, there’s a link between Transmeta and MCST - see if you can find it…)

Right, I guess I should ask Apache.

Copy and paste can be productive. Go lacks a lot of the generalized abstractions that make it a good language, but in my experience it’s as fast, or faster to write in Go vs JavaScript or Python.

I don’t defend Go because I like it, mind you. But, I can’t ignore the speed in which I and others have developed pretty high quality, and scalable stuff with it, either.

I’m somewhat surprised by the existence of large projects written in go.

The language is <10 years old - either someone wrote a lot of code in a very short period of time, or we have different definitions of large (my first job after uni had >1million SLOC and ‘unrefactorable mess’ did not begin to cover it).

Go offers several ways to avoid repeating code. Each has its own tradeoffs. Sometimes copy and paste is the most appropriate, but its hardly the default.

Re: large systems. I’m just getting there with Go and to remain effective I’ve rewritten a few packages multiple times. I see no evidence unrefactorable messes are inevitable.

This is a favorite video of mine, for a couple of reasons:

• The acknowledgment that languages readily steal from each other
• The fact that these language researchers/developers are friendly with each other (it’s easy to get into this world of language mono-culture where your language is the one true language and the other languages are evil. It’s good to remember that this is silly)
• No one puts down any other language (in fact, Simon Peyton Jones is quite self-deprecating toward Haskell, in calling it useless)