Yes Männistö, I'm aware of that, that's why I said for user applications in a comment on page 1
and some guy snired back with a comment "So, the answer is: Go to windows server".
However, to my understanding, applications need to be hardcoded with for LARGEADDRESSAWARE
and the kernel flag for the OS needs to be set to use that. It's a lot of hassle that no one goes through, that's why in the case of Chrome it's not valid. Chrome uses caches in disk, other than Virtual Memory to avoid using workaround for large memory usage.
The issues, however come from bugs, especially when using ABP, Tampermonkey, Stylish etc. So these memory hogs are not counted in when devs actually prepare Chrome for release, and a clean Chrome would rarely make issues like these.
Don't know if it's a feature, nor can I personally call it stupid. If a bug as mentioned just earlier, makes an application eat up large amounts of RAM you don't know how fast that dumping goes to VM
in order to tell of the actual RAM is freed up (dumped to page file) fast enough than it is filled by the leak. In such cases, reaching the bounds of that trigger is well within the realm of possibility.
Features like this, as I've said before, are meant for average user systems, 1 or 2 GB of RAM, in no way is an 8GB or, let alone, 16GB average. For these systems we have settings at hand to manage what
we don't like.
Also why bother changing the limit? It's better to disable this feature all together and use some RAM cleanup tool if it hits an upper limit. If RAM is eaten by leakey applications, then
such tools would basically "fix" the leaks by freeing up wasted memory.