[la_barba]

Well.. I don't know what to say, I guess you should report those bugs to the appropriate vendors then. I don't believe a memory leak means we tell people to buy more memory :)

>"Primarily because any modern OS will throttle crazy runaway threads to ensure UI responsiveness" seems like you have a particular OS in mind, and I would be interested in hearing more.

Sure. You should read up about thread scheduling and how an OS scheduler works. I don't think I can explain that in a comment, and I'd do a poor job anyway.

>I do not observe that behaviour on Debian 9 (and other Linux distros), Mac OS X, and Windows 7/8. I regularly bring any of those to UI stuttering/freeze from various workloads. Webapps only really breaks the lesser ones singlehandedly though (most of my other systems are 4+ core with 32GB+ RAM).

I don't observe that behavior. Just for fun I ran a CPU Stress test (https://silver.urih.com/) as I'm typing this comment. CPU pegged at 100%. Not feeling a thing... https://imgur.com/a/J0l9VaP

[xemdetia]

CPU utilization is an extremely poor indicator for whether or not your system will feel stuttering or freezing. What makes your system freeze is having more tasks to complete than can be reasonably scheduled in a time frame to as to appear continuous/realtime. Most OS schedulers that I am aware of do not provide special treatment to UI processes and defer to the fact that most modern UI's require many programs to respond in a timely fashion to provide a user interface and do not assign priority unless specially instructed. Most provide (relatively) even priority and have high priority interrupts like Window's ctrl-alt-delete and higher priority to kernel threads.

In Linux actual scenarios for stuttering/freezing are generally represented as a load average >1, and stuttering for me generally starts to happen when I get above 3 and I assure you no Linux system will work without observable stutter when you start getting into the 20+ load average range.

In earnest I have no idea why you tried to use a JavaScript based benchmark to support your point. Even after observing it the number of nonvoluntary ctxt switches barely even registered from baseline, probably from the variety of ways browsers do their own internal threading strategies. I could not see how to change that JavaScript benchmark to make it actually provide an interesting load on my system, so I'll just leave it at that.

[la_barba]

I have no idea what happens under the hood in Linux, but I have never observed my Linux desktop 'crawling to a halt' because of some silly webapp. This is normal expected behavior. I know for a fact that ensuring responsiveness of GUI apps has been in the NT scheduler for decades. Look up dynamic priority groups. There is really no point rehashing and arguing over basic design issues that anyone can lookup and as such this thread is not really productive for either of us. Hope you have a nice day, Goodbye!