Linked by Thom Holwerda on Mon 10th Jul 2017 18:27 UTC
Windows

This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching - sometimes locking up for seconds at a time.

So I did what I always do - I grabbed an ETW trace and analyzed it. The result was the discovery of a serious process-destruction performance bug in Windows 10.

Great story.

Thread beginning with comment 646568
To read all comments associated with this story, please click here.
2 questions
by feamatar on Tue 11th Jul 2017 08:22 UTC
feamatar
Member since:
2014-02-25

As a humble Java programmer, can I ask 2 questions:

- What is the need for such high number of threads? Couldn't a threadpool provide better utilization?
- Could fibers be used instead of threads in this case?

Reply Score: 2

RE: 2 questions
by Lennie on Tue 11th Jul 2017 09:59 in reply to "2 questions"
Lennie Member since:
2007-09-22

The point of the article is: Windows has always been slow for this use case. Other operating systems don't have this problem (as bad).

Even older versions of the operating system don't have it this bad.

Edited 2017-07-11 10:01 UTC

Reply Parent Score: 1

RE[2]: 2 questions
by feamatar on Tue 11th Jul 2017 10:37 in reply to "RE: 2 questions"
feamatar Member since:
2014-02-25

I understand that, but because there are many readers on this side with great technical insight, I am interested if someone knows why thread creation is used instead of fibres or a threadpool when threads are expensive either way.

Reply Parent Score: 2

RE: 2 questions
by The123king on Tue 11th Jul 2017 10:02 in reply to "2 questions"
The123king Member since:
2009-05-28

In order to compile code, the compiler will generate a thread for every snippet of code. A large amount of threads will be created and destroyed due to the massive amounts of code snippets in a project the size of Chrome. A threadpool probably wouldn't help much due to the quantity of threads being created and destroyed.

Fibers are Java exclusive feature, and a really just threads restricted to usermode.

I understand you're a java programmer. If any of the terms used (such as "compiler", or "code") confuse you, i can try to explain it in simpler english if you like.

Edited 2017-07-11 10:02 UTC

Reply Parent Score: 1

RE[2]: 2 questions
by feamatar on Tue 11th Jul 2017 10:19 in reply to "RE: 2 questions"
feamatar Member since:
2014-02-25

1. Don't need to be a douche.
2. Fibre is not part of Java, that is part of Windows API.
3. The point of a threadpool is not to create threads.
4. You don't have kernel locks in user mode.
5. If terms used(such as "douche") confuse you, i can try to explain it in simpler english if you like.

Reply Parent Score: 5

RE[2]: 2 questions
by boudewijn on Tue 11th Jul 2017 11:46 in reply to "RE: 2 questions"
boudewijn Member since:
2006-03-05

Not thread: process. The distinction is important.

Reply Parent Score: 2

RE: 2 questions
by ahferroin7 on Tue 11th Jul 2017 12:42 in reply to "2 questions"
ahferroin7 Member since:
2015-10-30

It's not threads, but processes. Java is an odd case for a compiled language in that the compiler is inherently multi-threaded and does a good job of parallelizing things itself (haskell is an example of another language that does this (at least, GHC does), although it's not as good at parallelization). Chrome is however written in C and C++, where you traditionally spawn a compiler for each source file (because they're not-multi-threaded, and for other reasons that I won't go into). The issue arises in the fact that Windows 10 for some reason is serializing the teardown of the process contexts when each process dies (I'd be more than willing to bet the serialization involves memory management somehow), while older versions, and pretty much every other OS in existence, have no such locking constraint (or at least, they aren't locking such a large section of code that it causes issues).

Reply Parent Score: 5

RE[2]: 2 questions
by dionicio on Tue 11th Jul 2017 21:41 in reply to "RE: 2 questions"
dionicio Member since:
2006-07-12

"...The issue arises in the fact that Windows 10 for some reason is serializing the teardown of the process contexts when each process dies..."

Audit reasons? See no reasoning, on "continuous" audit.

Reply Parent Score: 2