Fwd: Latency in starting threads on Mac OS X

David Holmes david.holmes at oracle.com
Wed Apr 17 01:27:41 UTC 2013


As I've pointed out to Heinz on the concurrency-interest list there are 
a couple of flawed assumptions in his test:

a) when you start() a new thread the OS scheduler may switch to it 
immediately (this depends on the scheduler semantics)

b) Thread.join only signifies logical termination of the Java thread. 
The native thread still has to exit the VM and the OS and so can 
encounter additional bottlenecks that result in many more threads being 
existent than expected and which can interfere with the creation of new 
threads.

I don't know specifically what may have changed between 7u5 and 7u6 in 
that regard but I think it would be a hotspot issue more than a 
libraries issue. I know 7u6 was the first version of JDK to fully 
support OS X.

David

On 17/04/2013 2:52 AM, Kurchi Subhra Hazra wrote:
> Forwarding to core-libs.
>
> - Kurchi
>
> -------- Original Message --------
> Subject:     Latency in starting threads on Mac OS X
> Date:     Tue, 16 Apr 2013 15:57:06 +0300
> From:     Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
> Organization:     JavaSpecialists.eu
> To:     macosx-port-dev at openjdk.java.net
>
>
>
> Good day my fellow Mac OS X users!
>
> Yesterday, whilst teaching my Concurrency Specialist Course, I wanted to
> demonstrate to my class how slow it was starting threads and how much
> better it is to use a FixedThreadPool.  The question that I wanted to
> answer was: How many microseconds does it take on average to start a
> simple thread and what is the maximum time it could take?
>
> We all know that it can take in the milliseconds range to do the following:
>
> Thread t = new Thread(); // even without it actually doing anything
> t.start();
>
> This is one of the reasons why the fixed thread pool only starts the
> threads as we submit jobs to it, since the up-front cost might not be
> worth the wait.
>
> But how long do you think the *maximum* was that I had to wait for
> t.start() to return?  100ms?  200ms?
>
> Actually, the longest I had to wait turned out to be about 250 seconds.
> Yes.  That is *seconds*, not *milliseconds*.  Just to start a single
> thread.
>
> This is most certainly a bug in the OpenJDK on Mac OS X.  We did not see
> this behaviour on Linux nor on Windows 7.
>
> The bug started in OpenJDK 1.7.0_06.  Prior to that it hardly ever took
> longer than 30ms to start a single thread.
>
> java version "1.7.0_05"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 4
> time = 2, threads = 346
> time = 4, threads = 7378
> time = 7, threads = 9614
> time = 12, threads = 10027
> time = 14, threads = 10063
> time = 17, threads = 26965
> time = 38, threads = 27013
> time = 39, threads = 452053
>
> java version "1.7.0_06"
> heinz$ java ThreadLeakMac2
> time = 1, threads = 6
> time = 2, threads = 256
> time = 6, threads = 373
> *snip*
> time = 111, threads = 42592
> time = 200, threads = 49419
> time = 333, threads = 58976
> *snip*
> time = 3245, threads = 202336
> time = 3706, threads = 203702
> *snip*
> time = 5835, threads = 267872
> time = 6455, threads = 269238
> time = 9170, threads = 270603
>
> In my code, I make sure that the thread has stopped before creating the
> next one by calling join().
>
> public class ThreadLeakMac2 {
>     public static void main(String[] args) throws InterruptedException {
>         long threads = 0;
>         long max = 0;
>         while(true) {
>             long time = System.currentTimeMillis();
>             Thread thread = new Thread();
>             thread.start(); // should finish almost immediately
>             time = System.currentTimeMillis() - time;
>             thread.join(); // short delay, hopefully
>             threads++;
>             if (time>  max) {
>                 max = time;
>                 System.out.println("time = " + time +
>                                    ", threads = " + threads);
>             }
>         }
>     }
> }
>
> This would be another nice test case for Alexey's concurrency stress
> test harness.
>
> (I also posted this to the concurrency-interest list.)
>
> Regards
>
> Heinz



More information about the core-libs-dev mailing list