Page History

...

But this code in AdoptOpenJDK 8 ThreadPoolExecutor.execute() looks like it would perform just fine if the workQueue was a non-synchronous queue:

Perhaps a quick test is needed here to confirm Darrel Schneider's recollection…

Update 1: well this 2007 commit introduced the arrangement in question: 050a62da28157ba4d146d2acb9521a3a14e557ab

That commit mentions bug 37091 which we were able to dig up:

Interim Bug ID:  070706-111344-darrel-zeus
Bug-Number:      37091
Submitted by:    darrel
Date:            Friday July 6 2007 11:13
Priority:        R2
Customer / HR:
Bug Comment:     If BridgeServer.SELECTOR is enabled server connection threads timeout and are constantly recreated if when system is busy
Product Line:    GemFire
Version:         5.0.2
Build:
Bug Description:
If the SELECTOR is enabled and the actual number of clients is less then the configured thread pool size then extra threads are constantly created and get timed out and recreated. The expected behaviour is for the thread pool to grow to the number of clients, in this case, and hold steady at that size without creating extra threads.
Assign to: darrel
Keywords:
Audit/Repair:
Stone Host/OS:
Gem   Host/OS:
Dbf   Host/OS:
Private cache:
Module:
Script/QC test:
Gemstone login:
Cc List:
Workaround:
Keep the the thread pool size <= to the number of clients.

It's not entirely clear how/why the synchronous work queue prevents threads timing out when there are fewer clients than threads in the pool.

But this article: provides insight into the way that the thread pool's "core pool size" relates to queueing behavior: Java ThreadPoolExecutor BlockingQueue Example from HowToDoInJava. From that article:

BlockingQueue works on following rules:

• If fewer than corePoolSize threads are running, the Executor always prefers adding a new thread rather than queuing.
• If corePoolSize or more threads are running, the Executor always prefers queuing a request rather than adding a new thread.

Since our core pool size is always 0 or 1 we'd almost always have the executor preferring queuing over running immediately if we were using a non-synchronous work queue. It's hard to see the relationship between this theory and the subject of bug 37091 above.