Fwd: Latency in starting threads on Mac OS X (original) (raw)

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.006. Prior to that it hardly ever took longer than 30ms to start a single thread. java version "1.7.005" 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.006" 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