回复：Virtual thread hang and all threads stop running on JDK21

[何品(虎鸣)]

> What you are doing seems very risky at this point in release cycle of virtual threads. I would return to my original question of what are you trying to accomplish and maybe people can help with a simpler and supported way of doing that.
What I want to do: Using virtual thread to make code simpler, otherwise I have to make use of `Future.reduce/traverse` thing, and make code faster (blocking HTTP client)/
What's unexpected, when it hang, the JVM makes no progress , jcmd no responding too.
------------------------------------------------------------------
发件人：robert engels <rengels at ix.netcom.com>
发送时间：2024年6月4日(星期二) 22:07
收件人："何品(虎鸣)"<hepin.p at alibaba-inc.com>
抄　送："loom-dev"<loom-dev at openjdk.org>
主　题：Re: Virtual thread hang and all threads stop running on JDK21
This might cause everything to hang - because if all “carriers” in the pool end up blocked, no compensation threads will be added, leading to carrier thread starvation. Not saying that is the underlying cause though.
What you are doing seems very risky at this point in release cycle of virtual threads. I would return to my original question of what are you trying to accomplish and maybe people can help with a simpler and supported way of doing that.
On Jun 4, 2024, at 9:00 AM, robert engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com >> wrote:
If you look at the Blocker class, if your virtual thread carrier thread is not an instance of CarrierThread, then code like this will not do what is expected:
 public static long begin() {
 if (VM.isBooted()
 && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) {
 ct.beginBlocking();
 boolean completed = false;
 try {
 long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool());
 assert currentCarrierThread() == ct;
 completed = true;
 return comp;
 } finally {
 if (!completed) {
 ct.endBlocking();
 }
 }
 }
 return -1;
 }
I am surprised that anything works at all. You may have success if you make your executor create instances of CarrierThread - which is public.
On Jun 4, 2024, at 8:44 AM, robert engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com >> wrote:
What are you trying to do? I am pretty sure the current scheduler is tied directly to the implementation and if you change it, I am not surprised that things don’t work. The default scheduler creates instances of CarrierThread which has special properties. It is doubtful yours does.
On Jun 4, 2024, at 8:29 AM, 何品(虎鸣) <hepin.p at alibaba-inc.com <mailto:hepin.p at alibaba-inc.com >> wrote:
Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump.
We try to separate the Virtual Thread's scheduler with reflections. but that does not work too.
Our userbase are pretty simple:
A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get`
B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads)
Even if A and B are using Different backing ThreadPool, they all stop responding。
```java
public static Executor virtualize(final String prefix,
final boolean enabled,
final Executor executor) {
if (!enabled) {
return executor;
}
try {
final var builder = Thread.ofVirtual();
if (executor != null) {
final var clazz = builder.getClass();
final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup);
final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class);
 schedulerFieldSetter.invoke(builder, executor);
}
builder.name(prefix + "-virtual-thread-", 0L);
final var factory = builder.factory();
return Executors.newThreadPerTaskExecutor(factory);
} catch (Throwable e) {
log.error("Error when virtualize a executor", e);
return executor;
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240605/cec08bfd/attachment.htm>