We've been discussing this many times over the years, so we're kinda aware of it - we just were not aware of it being still so serious, Thorsten just raised the same issue on the devel list...
And I happened to add a summary to the wiki just a couple of days ago, to make this a bit more prominent:
http://wiki.flightgear.org/Subsystem-le ... BackgroundA while back, I started preparing a patch to add the corresponding diagnostics (RAM usage tracking) to FG so that we can better identify problematic features, and either fix them or at least provide feature-scaling support if necessary. Back then, this was unfortunately ignored and disregarded - recently, this is getting some more attention again, so we'll probably revisit the issue during the 3.2 release cycle. The first step really is getting "live" memory usage details, and exposing this via the property tree - so that we can tell 1) how much RAM is there, 2) how much RAM is being used by fgfs, 3) and: are we swapping ?
These three things are trivial to implement, I provided a patch doing this on Linux and it only took 20-30 minutes - so this could be done for Windows & Mac/OSX, too - and it would be straightforward.
That alone will not yet improve things - it will just show us that there is a problem.
The next step would involve doing the whole thing at a more fine-grained level, i.e. for each subsystem - so that we would have a list of subsystems, analogous to ThorstenB's system monitor, but see how much RAM is being used, allocated and freed per minute/5 minutes/10 minutes etc - analogous to how htop/top work
That should give us a list of problematic subsystems, which would either need to be fixed, or made more configurable.
Basically, we fully understand what's involved - it just hasn't been on anybody's plate recently, and even I had forgotten about it, until some folks around here posted crash reports despite having 10+ gb of physical RAM.
So, yeah - we do have a real problem here, but it surely won't be fixed in time for 3.0 unfortunately .. too late for that I'm afraid, we all worked on different features, and most of us tend to belong to the camp of people with really powerful computers, so that we won't necessarily notice such things - keep in mind that many of the people able to "fix" such problems are also the ones who happen to primarily DEVELOP the sim, not really USE it in the sense of spending many hours each month flying around and letting FG gobble up GBs of memory.
Overall, if you want to help with this, please provide feedback - feel free to use the issue tracker, you have found a real bug here, and a critical one, that needs to be addressed during the 3.2 release cycle - you can also help by updating and maintaining the wiki article, and adding your figures there.
But don't expect this to be fixed anytime soon - people using lots of resource-hungry features need to be aware that even powerful computers may no longer suffice at some point ...
Bottom line being, we need to add some hooks to expose memory usage stats to the property tree, of the whole process, but also of each subsystem - and provide a mechanism to do dynamic feature scaling in response to these numbers, i.e. to tell subsystems "STOP USING RAM NOW" - and we really need to do some kind of regression testing to watch these numbers for each release, i.e. using either prerecorded flights or replay/flight recorder profiles and watch memory usage with different settings (AI/MP, route manager etc)