<div dir="ltr"><div dir="ltr">Am Di., 10. Okt. 2023 um 12:56 Uhr schrieb Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...]<br>
Are the virtual threads executing compilation tasks in this usage? How <br>
many of them are running concurrently? I'm trying to see if this is a <br>
good use of virtual threads or not.<br></blockquote><div><br></div><div>There are three kinds of threads involved that vary somewhat in their processing:</div><div><br></div><div>* A namespace thread starts with I/O reading the source file, parses it, then starts processing forms.  If the namespace begins with imports of unseen or unfinished namespaces this thread blocks almost immediately, otherwise it compiles top-level content of the file and starts threads for every function it encounters.  With most action happening in functions, this kind of thread is not CPU heavy.  Because of imports and macro expansion, it may have to wait for tasks to complete at unpredictable points.</div><div><br></div><div>* Function threads typically cover a smaller scope of text, handle the conversion to the intermediate representation, and recursively start threads for nested functions.  Short lived, they do the bulk of the compilation work, and send of their results into a queue.  If unfinished macros are involved, they may block as well.  These threads account for the bulk of the thread count, say >80%.</div><div><br></div><div>* Every namespace thread is accompanied by an emitter thread that assembles the pieces send over by the two prior kinds, decides on the higher level translation patterns, generates class files via the Class-file API, and defines them into the appropriate classloader.  My impression is that this kind of thread is mostly waiting, with short bursts of action whenever a class file must be generated.</div><div><br></div><div>None of these thread kinds is particular cpu heavy, each may block because some prior compilation steps must complete first, and there is only moderate I/O involved (both Clojure input files and class files tend to the smaller side).</div><div><br></div><div>As for how many are running in parallel, I can only say: it varies.  For example, the bootstrap scenario starts with the core library (the largest input file of all), and nothing else can be started until this is finished.  Afterwards the compiler can go wider and work on several namespaces in parallel, but this depends on how these are interrelated.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On HT, this is a good topic. We've had one report where limiting the <br>
number of carrier threads to half the number of hardware threads <br>
improved performance. I think we need more usage on these systems to see <br>
if the ergonomics and defaults should be tuned for these processors.<br></blockquote><div><br></div><div>Is there a way to change the number of carrier threads?  Something like "this line in this .java file" would suffice for me to make images and compare the effect.<br></div><div><br></div><div>-- mva</div><div><br></div></div></div>