[concurrency-interest] ForkJoinPool for async http calls?

Boehm, Hans hans.boehm at hp.com
Fri May 11 16:14:05 EDT 2012


Most modern (64 bit) Linux distributions seems to top out at about 30000 threads in their default configuration.  The running time for simple microbenchmarks seem to increase superlinearly with the number of threads created.  Thus there seem to be some weak evidence that this is not completely fixable simply by bumping up kernel parameters.  I don’t see a reason why JVM limits should be lower.  (The C++ committee is interested in closely related issues, which prompted me to experiment a little.)


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of viktor ?lang
Sent: Friday, May 11, 2012 7:55 AM
To: Mark Thornton
Cc: concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] ForkJoinPool for async http calls?

On Fri, May 11, 2012 at 9:46 AM, Mark Thornton <mthornton at optrak.com<mailto:mthornton at optrak.com>> wrote:
On 11/05/12 04:03, Zhong Yu wrote:

Yes thread-per-connection doesn't work, today. My question is, could
OS/VM do some optimization to make it work? Or there are reasons
prohibiting that?

There have been VMs designed to run tens of thousands of threads even in a 32 bit system. One of the critical resources in a VM like HotSpot is the address reserved for each thread's stack. Typically this is 256K in a 32 bit system. This clearly limits the number of threads you can have. I remember a VM which allocated much smaller stacks initially (8K perhaps) and then expanded the stack if it became full  (expensive, but hopefully rare). The rationale here was to permit the one thread per connection model to scale to very large numbers of connections

10s of thousands is still a low number though. We currently run ~2.5 million Actors per GB of heap.


Mark Thornton

Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>

Viktor Klang

Akka Tech Lead
Typesafe<http://www.typesafe.com/> - The software stack for applications that scale

Twitter: @viktorklang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120511/6d671739/attachment.html>

More information about the Concurrency-interest mailing list