<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="FR" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span lang="EN-US">What Virtual Threads change is that it’s now considered as cheap to block a thread.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If a blocked thread stack retains more unused objects than the async approach (until JIT threshold at least), that’s not as cheap as it could.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Of course, if we assume that memory sensitive code will be always quickly JIT-ed (and assuming any JIT is aggressive about stack cleanup), there is no problem. (Is this assumption true?...)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I don’t think stack-based allocation impact much here because typically this would be small objects that would be flattened on the stack, no? so no big surprise.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Arnaud<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">>But that’s just how HotSpot works, and virtual threads didn’t change that. There are other memory-related optimisations in the JIT, too. For example, every `new Foo`, when running in the interpreter, will allocate memory
in the heap. But when compiled, the object could be allocated on the stack (scalar-replaced) or even not at all (which means there can be cases where JITted code consumes zero heap memory, while the same code, when interpreted, consumes an unbounded amount,
i.e. will OOME at any heap size). So the memory profile of Java applications running on OpenJDK can be very different depending on JIT behaviour. This might become even more pronounced with Valhalla.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">>In this case, the behaviour has nothing to do with virtual threads or with “capture.” The optimising compiler simply analyses the method and sees that the bigBuffer variable is unused after the call to slowIO so it optimises
it away (and with the local gone, the GC will not find the buffer and it will be collected).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">>If the interpreter were to perform this or other similar optimisations based on analysing the method before interpreting it, then it wouldn’t be doing its job as the mechanism that quickly starts execution or the mechanism
used when debugging. Even when some optimisations are possible in the interpreter, it’s rarely worth it to invest much time in that because the interpreter runs little code over the program’s overall execution.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">>It does, however, mean that microbenchmarks need to be done carefully.<o:p></o:p></span></p>
<p class="MsoNormal">><o:p> </o:p></p>
<p class="MsoNormal">>— Ron<o:p></o:p></p>
</div>
</div>
<DIV>
Unless otherwise stated above:<BR>
<BR>
Compagnie IBM France<BR>
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex<BR>
RCS Nanterre 552 118 465<BR>
Forme Sociale : S.A.S.<BR>
Capital Social : 664 069 390,60 €<BR>
SIRET : 552 118 465 03644 - Code NAF 6203Z<BR>
</DIV></body>
</html>