Discussion:
In Java 7 (or 8) is it still more expensive to create/destroy threads instead of using a thread pool?
David Karr
2014-04-18 17:37:56 UTC
Permalink
It is "common knowledge" that simple parallel processing should use a
thread pool instead of creating and destroying threads on the fly, if
performance is the only concern.

However, it's reasonable to ask every once in a while, has Java thread
creation/destruction overhead decreased to a point where the performance
difference is less or negligible?

Has anyone done experiments with either Java 7 or Java 8 to see what the
tradeoffs are today?
Douglas Pearson
2014-04-18 19:20:11 UTC
Permalink
I've not done that sort of testing David, but I thought the thinking had
shifted more from thread pools to executors. Which means you think more in
terms of submitting a set of tasks and then you can optimize the number of
threads independently of the task set.

If you create your own thread, the normal assumption is one thread - one
task.

The executor model is setup so you can get the preferred number of threads
for the hardware - people often seem to talk in terms of 2 x number of
cores as being a useful guideline - which is unrelated to the number of
tasks to complete.

So for me it's less about thread start/stop and more about how tasks are
assigned to threads.

Doug
Post by David Karr
It is "common knowledge" that simple parallel processing should use a
thread pool instead of creating and destroying threads on the fly, if
performance is the only concern.
However, it's reasonable to ask every once in a while, has Java thread
creation/destruction overhead decreased to a point where the performance
difference is less or negligible?
Has anyone done experiments with either Java 7 or Java 8 to see what the
tradeoffs are today?
Jason Osgood
2014-04-18 20:50:35 UTC
Permalink
Has anyone done experiments with either Java 7 or Java 8 to see what the tradeoffs are today?
A recent blog post claimed Java 8 has a concurrency performance regression. The commentariat piled on, pointing out the folly of micro benchmarks.

My takeaway was the importance of profiling and verification.

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/seajug/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/seajug/join
(Yahoo! ID required)

<*> To change settings via email:
seajug-digest-***@public.gmane.org
seajug-fullfeatured-***@public.gmane.org

<*> To unsubscribe from this group, send an email to:
seajug-unsubscribe-***@public.gmane.org

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
Mat Gessel
2014-04-18 21:15:00 UTC
Permalink
I can't speak to Windows, but for Mac OS and Linux, each Java thread is
backed by a native Posix thread (pthread). This has not changed in recent
JREs.

You can see this in Linux by invoking "top" and pressing Shift-H. This
shows "lightweight processes", a.k.a. threads. *Tip*: you can take the
process id (PID), convert it to hex and correlate to the native id (NID) in
the thread dump generated by jstack. Great way to track down infinite
loops.

-= Mat
Post by David Karr
It is "common knowledge" that simple parallel processing should use a
thread pool instead of creating and destroying threads on the fly, if
performance is the only concern.
However, it's reasonable to ask every once in a while, has Java thread
creation/destruction overhead decreased to a point where the performance
difference is less or negligible?
Has anyone done experiments with either Java 7 or Java 8 to see what the
tradeoffs are today?
Mat Gessel
http://www.asquare.net
s***@public.gmane.org
2014-04-18 21:44:56 UTC
Permalink
<head>

<style type="text/css">
<!--

/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}

div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}

div.attach-table div.attach-row {
clear: both;
}

div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}

p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}

div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}

div.attach-table div.attach-row div div span {
font-weight: normal;
}

div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html><body>


<!-- |**|begin egp html banner|**| -->

<br><br>

<!-- |**|end egp html banner|**| -->


<span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>Could you elaborate on that worked "backed"? Do you mean a single thread created by a java application is implemented with a single pthread?</div><div><br></div><div>Due to the micro-kernel "feature" in Windows (last I checked about 10 years ago -- I doubt any thing has changed), windows threading is ugly. In contrast to most linux implementations, micro-kernel architectures like windows move a lot of functionality out of the kernel into special auxiliary (aux) processes. The result of this is horrible! Instead of doing a single user-mode to kernel-mode context switch for I/O (for example), windows often does a process context switch to the aux system process and that aux process then does a user-to-kernel context switc
h to execute the kernel mode function (and of course we have to context switch back to the aux process and then back to the application process).&nbsp;</div><div><br></div><div>This is in contrast to a single user-to-kernel mode context switch in Linux (can anyone confirm this?).</div><div><br></div><div>But wait! It gets uglier!</div><div>If you are writing multi-threaded applications in windows, every thread you create in your application also allocates precious kernel mode thread-control-block memory *AND* a shadow kernel thread! Yikes! This makes sense when you think about it: If you are doing parallel asynchronous threading in your application and are making requests that are implemented in a different (aux) system process, that aux process must also have shadow threads run in paral
lel too. Otherwise there would be no benefit to multi-threading in an application if all there threads had to wait on the kernel and aux processes.</div><div><br></div><div>If you use the free tools for process monitoring, you can see the gazillions of threads that common apps like Microsoft Outlook use. While working for Microsoft, we were strongly encouraged to use thread-pools so we don't have acres of idle threads like some Microsoft apps have.</div><div><br></div><div>Now as I recall, most Linux applications create processes very efficiently and the implementation of the create-thread function in linux is very similar to the create-process feature in terms of elapse time, CPU time and processor time. Can anyone confirm this? This makes me wonder, since processes are relatively heavy
weight compared to threads, if Linux thread-creation could be optimized.</div><div><br></div><div>Because Dave Cutler wrote VAX/VMS and (much later) Windows, creating processes in Windows is very slow. The way it worked in VAX/VMS (and probably windows) is that the entire process image is laid out on disk and the process is swapped (or paged in in the case of windows) on demand. This is very slow compared to the Linux/Unix strategy.</div><div><br></div><div>Hurray for faster disks and faster silicon!&nbsp;</div><div><br></div><div><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [seajug] In Java 7 (or 8) is it still more expensive to<br>
create/destroy threads instead of using a thread pool?<br>
From: Mat Gessel &lt;<a href="mailto:mat.gessel-***@public.gmane.org">mat.gessel-***@public.gmane.org</a>&gt;<br>
Date: Fri, April 18, 2014 2:15 pm<br>
To: <a href="mailto:seajug-***@public.gmane.org">seajug-***@public.gmane.org</a><br>
<br>
<span style="display:none">&nbsp;</span> <div id="ygrp-mlmsg" style="position:relative;"> <div id="ygrp-msg" style="z-index: 1;"> <div id="ygrp-text"> <div></div><div dir="ltr"><div>I can't speak to Windows, but for Mac OS and Linux, each Java thread is backed by a native Posix thread (pthread). This has not changed in recent JREs. <br><br></div><div>You can see this in Linux by invoking "top" and pressing Shift-H. This shows "lightweight processes", a.k.a. threads. <i>Tip</i>: you can take the process id (PID), convert it to hex and correlate to the native id (NID) in the thread dump generated by jstack. Great way to track down infinite loops. <br> </div><div><br></div>-= Mat<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 18, 2014 at 10:37 AM, D
avid Karr <span dir="ltr">&lt;<a href="mailto:davidmichaelkarr-***@public.gmane.org" target="_blank">davidmichaelkarr-***@public.gmane.org</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="border-left:1px #ccc solid;"> <u></u> <div> <span>&nbsp;</span> <div> <div> <div> <div></div><div dir="ltr"><div><div>It is "common knowledge" that simple parallel processing should use a thread pool instead of creating and destroying threads on the fly, if performance is the only concern.<br> <br></div>However, it's reasonable to ask every once in a while, has Java thread creation/destruction overhead decreased to a point where the performance difference is less or negligible?<br> <br></div>Has anyone done experiments with either Java 7 or Java 8 to see what the tradeoffs are today?<br></div> <div></div> </d
iv><br></div></div></div></blockquote></div>Mat Gessel<br><a target="_blank" href="http://www.asquare.net">http://www.asquare.net</a> </div></div></div></div> <div></div> </div> <div style="color: #fff; height: 0;"></div> <style type="text/css">
#wmQuoteWrapper #ygrp-mkp { border: 1px solid #d8d8d8; font-family: Arial; margin: 10px 0; padding: 0 10px; }
#wmQuoteWrapper #ygrp-mkp hr { border: 1px solid #d8d8d8; }
#wmQuoteWrapper #ygrp-mkp #hd { color: #628c2a; font-size: 85%; font-weight: 700; line-height: 122%; margin: 10px 0; }
#wmQuoteWrapper #ygrp-mkp #ads { margin-bottom: 10px; }
#wmQuoteWrapper #ygrp-mkp .ad { padding: 0 0; }
#wmQuoteWrapper #ygrp-mkp .ad p { margin: 0; }
#wmQuoteWrapper #ygrp-mkp .ad a { color: #0000ff; text-decoration: none; }
#wmQuoteWrapper #ygrp-sponsor #ygrp-lc { font-family: Arial; }
#wmQuoteWrapper #ygrp-sponsor #ygrp-lc #hd { margin: 10px 0px; font-weight: 700; font-size: 78%; line-height: 122%; }
#wmQuoteWrapper #ygrp-sponsor #ygrp-lc .ad { margin-bottom: 10px; padding: 0 0; }
#wmQuoteWrapper #actions { font-family: Verdana; font-size: 11px; padding: 10px 0; }
#wmQuoteWrapper #activity { background-color: #e0ecee; float: left; font-family: Verdana; font-size: 10px; padding: 10px; }
#wmQuoteWrapper #activity span { font-weight: 700; }
#wmQuoteWrapper #activity span:first-child { text-transform: uppercase; }
#wmQuoteWrapper #activity span a { color: #5085b6; text-decoration: none; }
#wmQuoteWrapper #activity span span { color: #ff7900; }
#wmQuoteWrapper #activity span .underline { text-decoration: underline; }
#wmQuoteWrapper .attach { clear: both; display: table; font-family: Arial; font-size: 12px; padding: 10px 0; width: 400px; }
#wmQuoteWrapper .attach div a { text-decoration: none; }
#wmQuoteWrapper .attach img { border: none; padding-right: 5px; }
#wmQuoteWrapper .attach label { display: block; margin-bottom: 5px; }
#wmQuoteWrapper .attach label a { text-decoration: none; }
#wmQuoteWrapper blockquote { margin: 0 0 0 4px; }
#wmQuoteWrapper .bold { font-family: Arial; font-size: 13px; font-weight: 700; }
#wmQuoteWrapper .bold a { text-decoration: none; }
#wmQuoteWrapper dd.last p a { font-family: Verdana; font-weight: 700; }
#wmQuoteWrapper dd.last p span { margin-right: 10px; font-family: Verdana; font-weight: 700; }
#wmQuoteWrapper dd.last p span.yshortcuts { margin-right: 0; }
#wmQuoteWrapper div.attach-table div div a { text-decoration: none; }
#wmQuoteWrapper div.attach-table { width: 400px; }
#wmQuoteWrapper div.file-title a, #wmQuoteWrapper div.file-title a:active, #wmQuoteWrapper div.file-title a:hover, #wmQuoteWrapper div.file-title a:visited { text-decoration: none; }
#wmQuoteWrapper div.photo-title a, #wmQuoteWrapper div.photo-title a:active, #wmQuoteWrapper div.photo-title a:hover, #wmQuoteWrapper div.photo-title a:visited { text-decoration: none; }
#wmQuoteWrapper div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight: normal; }
#wmQuoteWrapper .green { color: #628c2a; }
#wmQuoteWrapper .MsoNormal { margin: 0 0 0 0; }
#wmQuoteWrapper o { font-size: 0; }
#wmQuoteWrapper #photos div { float: left; width: 72px; }
#wmQuoteWrapper #photos div div { border: 1px solid #666666; height: 62px; overflow: hidden; width: 62px; }
#wmQuoteWrapper #photos div label { color: #666666; font-size: 10px; overflow: hidden; text-align: center; white-space: nowrap; width: 64px; }
#wmQuoteWrapper #reco-category { font-size: 77%; }
#wmQuoteWrapper #reco-desc { font-size: 77%; }
#wmQuoteWrapper .replbq { margin: 4px; }
#wmQuoteWrapper #ygrp-actbar div a:first-child { /* border-right: 0px solid #000;*/ margin-right: 2px; padding-right: 5px; }
#wmQuoteWrapper #ygrp-mlmsg { font-size: 13px; font-family: Arial, helvetica,clean, sans-serif; *font-size: small; *font: x-small; }
#wmQuoteWrapper #ygrp-mlmsg table { font-size: inherit; font: 100%; }
#wmQuoteWrapper #ygrp-mlmsg select, #wmQuoteWrapper input, #wmQuoteWrapper textarea { font: 99% Arial, Helvetica, clean, sans-serif; }
#wmQuoteWrapper #ygrp-mlmsg pre, #wmQuoteWrapper code { font:115% monospace; *font-size:100%; }
#wmQuoteWrapper #ygrp-mlmsg * { line-height: 1.22em; }
#wmQuoteWrapper #ygrp-mlmsg #logo { padding-bottom: 10px; }
#wmQuoteWrapper #ygrp-msg p a { font-family: Verdana; }
#wmQuoteWrapper #ygrp-msg p#attach-count span { color: #1E66AE; font-weight: 700; }
#wmQuoteWrapper #ygrp-reco #reco-head { color: #ff7900; font-weight: 700; }
#wmQuoteWrapper #ygrp-reco { margin-bottom: 20px; padding: 0px; }
#wmQuoteWrapper #ygrp-sponsor #ov li a { font-size: 130%; text-decoration: none; }
#wmQuoteWrapper #ygrp-sponsor #ov li { font-size: 77%; list-style-type: square; padding: 6px 0; }
#wmQuoteWrapper #ygrp-sponsor #ov ul { margin: 0; padding: 0 0 0 8px; }
#wmQuoteWrapper #ygrp-text { font-family: Georgia; }
#wmQuoteWrapper #ygrp-text p { margin: 0 0 1em 0; }
#wmQuoteWrapper #ygrp-text tt { font-size: 120%; }
#wmQuoteWrapper #ygrp-vital ul li:last-child { border-right: none !important; }

</style>
</div>
</blockquote></span>



<!-- |**|begin egp html banner|**| -->

<br>


<br>

<!-- |**|end egp html banner|**| -->


<div width="1" style="color: white; clear: both;"/>__._,_.___</div>





<!-- Start Recommendations -->
<!-- End Recommendations -->



<!-- |**|begin egp html banner|**| -->

<img src="http://geo.yahoo.com/serv?s=97476590/grpId=2267342/grpspId=1705006905/msgId=20630/stime=1397857499" width="1" height="1"> <br>

<!-- |**|end egp html banner|**| -->


<!-- |**|begin egp html banner|**| -->

<br>






<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

<span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/seajug/info;_ylc=X3oDMTJlamVtdnZzBF9TAzk3MzU5NzE0BGdycElkAzIyNjczNDIEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTM5Nzg1NzQ5OQ--" style="text-decoration: none;">Visit Your Group</a></span>

<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
</ul>
</div>


<div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;">
<a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkMG84ZGNkBF9TAzk3NDc2NTkwBGdycElkAzIyNjczNDIEZ3Jwc3BJZAMxNzA1MDA2OTA1BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMzk3ODU3NDk5" style="float: left;"><img src="Loading Image..." height="15" width="<? ol var!Pref.EmailFooterLogo.FullFeatured.Width ?>" alt="Yahoo! Groups" style="border: 0;"/></a>
<div style="color: #747575; float: right;"> &bull; <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> &bull; <a href="mailto:seajug-unsubscribe-***@public.gmane.org?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> &bull; <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div>
</div>

<!-- |**|end egp html banner|**| -->

</div> <!-- ygrp-msg -->




<br>

<!-- |**|end egp html banner|**| -->


<div style="color: white; clear: both;"/>__,_._,___</div>
</body></html>
Mat Gessel
2014-04-20 22:50:29 UTC
Permalink
By "backed", I mean that each java.lang.Thread object "owns" a native
thread throughout its lifetime. All instructions run on a Java thread will
always execute on its associated native thread.

-= Mat
Post by s***@public.gmane.org
Could you elaborate on that worked "backed"? Do you mean a single thread
created by a java application is implemented with a single pthread?
Due to the micro-kernel "feature" in Windows (last I checked about 10
years ago -- I doubt any thing has changed), windows threading is ugly. In
contrast to most linux implementations, micro-kernel architectures like
windows move a lot of functionality out of the kernel into special
auxiliary (aux) processes. The result of this is horrible! Instead of doing
a single user-mode to kernel-mode context switch for I/O (for example),
windows often does a process context switch to the aux system process and
that aux process then does a user-to-kernel context switch to execute the
kernel mode function (and of course we have to context switch back to the
aux process and then back to the application process).
This is in contrast to a single user-to-kernel mode context switch in
Linux (can anyone confirm this?).
But wait! It gets uglier!
If you are writing multi-threaded applications in windows, every thread
you create in your application also allocates precious kernel mode
thread-control-block memory *AND* a shadow kernel thread! Yikes! This makes
sense when you think about it: If you are doing parallel asynchronous
threading in your application and are making requests that are implemented
in a different (aux) system process, that aux process must also have shadow
threads run in parallel too. Otherwise there would be no benefit to
multi-threading in an application if all there threads had to wait on the
kernel and aux processes.
If you use the free tools for process monitoring, you can see the
gazillions of threads that common apps like Microsoft Outlook use. While
working for Microsoft, we were strongly encouraged to use thread-pools so
we don't have acres of idle threads like some Microsoft apps have.
Now as I recall, most Linux applications create processes very efficiently
and the implementation of the create-thread function in linux is very
similar to the create-process feature in terms of elapse time, CPU time and
processor time. Can anyone confirm this? This makes me wonder, since
processes are relatively heavy weight compared to threads, if Linux
thread-creation could be optimized.
Because Dave Cutler wrote VAX/VMS and (much later) Windows, creating
processes in Windows is very slow. The way it worked in VAX/VMS (and
probably windows) is that the entire process image is laid out on disk and
the process is swapped (or paged in in the case of windows) on demand. This
is very slow compared to the Linux/Unix strategy.
Hurray for faster disks and faster silicon!
-------- Original Message --------
Subject: Re: [seajug] In Java 7 (or 8) is it still more expensive to
create/destroy threads instead of using a thread pool?
Date: Fri, April 18, 2014 2:15 pm
I can't speak to Windows, but for Mac OS and Linux, each Java thread is
backed by a native Posix thread (pthread). This has not changed in recent
JREs.
You can see this in Linux by invoking "top" and pressing Shift-H. This
shows "lightweight processes", a.k.a. threads. *Tip*: you can take the
process id (PID), convert it to hex and correlate to the native id (NID) in
the thread dump generated by jstack. Great way to track down infinite
loops.
-= Mat
Post by David Karr
It is "common knowledge" that simple parallel processing should use a
thread pool instead of creating and destroying threads on the fly, if
performance is the only concern.
However, it's reasonable to ask every once in a while, has Java thread
creation/destruction overhead decreased to a point where the performance
difference is less or negligible?
Has anyone done experiments with either Java 7 or Java 8 to see what the
tradeoffs are today?
Mat Gessel
http://www.asquare.net
--
Mat Gessel
http://www.asquare.net
Loading...