Yeah, I'm sure if you just read the Darwin kernel there's a '#define USE_LOTS_OF_MEMORY 1' in there that you can change.
The class of problems described in the original post are not the sort of thing you 'just find' by glancing at kernel source code. The problems described sound like they could be an issue of poorly tuned heuristics/thresholds, or necessitate some extra machinery inside the OS X memory manager that isn't there currently. It's not like you can send Apple a pull request on github.
> everyone is all positive about "open source" until they have to dive into a few millions lines of complicated system-level C code and then...
Does anyone doubt that 99% of open source users never read a line of the source code which they are using? The point is, they have the opportunity to, and more importantly, the 1% (or whatever) with the skills and resources are able to actually do something about it.
If you don't have the ability to change or examine the source code, then there is little incentive to do any runtime analysis which might illuminate the problem.
The class of problems described in the original post are not the sort of thing you 'just find' by glancing at kernel source code. The problems described sound like they could be an issue of poorly tuned heuristics/thresholds, or necessitate some extra machinery inside the OS X memory manager that isn't there currently. It's not like you can send Apple a pull request on github.