<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Great, then one someone who runs CPU-heavy jobs that are appropriate for virtual threads presents a problem the’ve encountered that could be solved by some form of time-sharing, we’ll take a look. For the time being, we have a hypothesis that one or more problems
could occur, and a further hypothesis that some class of solutions might fix or mitigate them. Unfortunately, theses hypotheses are not presently actionable.
<div class=""><br class="">
</div>
<div class="">I don’t know what problem Go’s maintainers solve with time-sharing. Maybe they just want to solve Go’s lack of convenient access to a scheduler with time-sharing even in the case of background processing tasks — a problem that Java doesn’t have
— or perhaps they’ve managed to identify common server workloads that could be helped by time-sharing, in which case we’d love to see those workloads so that we can make sure our fix works.
<div class=""><br class="">
</div>
<div class="">I am not at all resistant to adding time-sharing to the virtual thread scheduler. I am resistant to fixing bugs that have not been reported. I have said many times — and not just on the mailing lists — that the best and often only way to get a
some change made to Java is to report a problem. You might have noticed that all JEPs start with a motivation section that attempts to clearly present a problem that’s encountered by Java’s users (and sometimes maintainers) and analyse its relative severity
to justify the proposed solution. That is usually the JEP’s most important section (and the section we typically spend most time writing) because the most important thing is to understand the problem you’re trying to tackle. Every change has a cost. A feature
might add overhead that harms workloads that don’t benefit from it, and it certainly has an opportunity cost. Neither of these is disqualifying, but we simply cannot judge the pros and cons of doing something until we can weigh some problem against another,
and we can’t even get started on this process until we have a problem in front of us.</div>
<div class=""><br class="">
</div>
<div class="">We *have* been presented with a problem that some specific kind of time-sharing can solve (postponing a batch job that’s consuming resources to run at a much later time), and it is one of the reasons we’ve added custom schedulers that will be
able to employ it to our roadmap. It is certainly possible that the lack of time-sharing causes problems that need addressing in the default (currently only) virtual-thread scheduler — I am not at all dismissing that possibility — but there’s not much we can
do until those problems are actually reported to us, which would allow us to know more about when those problems occur, how frequently, and what kind of time-sharing can assist in which circumstances and to what degree. There’s no point in trying to convince
us of something we are already convinced of, namely that the possibility exists that some virtual thread workloads could be significantly helped by time-sharing. In fact, I’ve mentioned that possibility on this mailing list a few times already.</div>
<div class=""><br class="">
</div>
<div class="">If the problems are common, now that more people are giving virtual threads a try, I expect they will be reported by someone soon enough and we could start the process of tackling them.</div>
<div class=""><br class="">
</div>
<div class="">— Ron<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 9 Jan 2023, at 08:48, Sam Pullara <<a href="mailto:spullara@gmail.com" class="">spullara@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Ron, I think you are being purposefully obtuse by not recognizing that some folks are going to run high CPU jobs in vthreads. The proof is with the folks using Go that already encountered it and fixed it.</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 9, 2023 at 12:46 AM Arnaud Masson <<a href="mailto:arnaud.masson@fr.ibm.com" class="">arnaud.masson@fr.ibm.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="msg3665960158538358729">
<div lang="FR" style="overflow-wrap: break-word;" class="">
<div class="m_3665960158538358729WordSection1">
<p class="MsoNormal"><span lang="EN-US" class="">Side note : it seems “more” preemptive time sharing was added for goroutines in Go 1.14 to avoid the kind of scheduling starvation we discussed:<u class=""></u><u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class=""><u class=""></u> <u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class=""><a href="https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c" target="_blank" class="">https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c</a><u class=""></u><u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class=""><u class=""></u> <u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class="">Thanks<u class=""></u><u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class="">Arnaud<u class=""></u><u class=""></u></span></p>
<p class="MsoNormal"><span lang="EN-US" class=""><u class=""></u> <u class=""></u></span></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>