Fwd: Latency in starting threads on Mac OS X

[Dr Heinz M. Kabutz]

"I know 7u6 was the first version of JDK to fully support OS X."

I think that's the key to the puzzle, David!  It is definitely an OS X 
issue.  I didn't see this happen on any other platform.

Regards

Heinz
-- 
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Sun Java Champion
IEEE Certified Software Development Professional
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz 



David Holmes wrote:
> 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
>