[dead]
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
531–540 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#532[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#533[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#534[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#535[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#536[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#537[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#538[dead]
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#539Earlier quoted context omitted.
> I mean, it’s also less verbose Are we talking about the same language? Or maybe you consider writing "if err != nil" every few seconds as good exercise for your fingers... I think we shouldn't point fingers at Java when it comes to Go's verbosity. I can simply do dict.contains("foo") in Java vs having to go through a verbose hoop: if val, ok := dict["foo"]; ok { //do something here } Common operations like filterin…
Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again. But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort u…
Name one FactoryFactory in the JDK
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#540Earlier quoted context omitted.
Virtual thread stacks reference the objects that local variables on the stack reference, but they are not themselves GC roots. GC roots are special objects that the GC starts its scan of the heap from, and they tend to be particularly costly, at least for most of OpenJDK's GCs. Virtual threads are just ordinary heap objects that can reference other objects. > I could imagine that by having fewer physical threads runn…
As long as virtual threads retain an entrypoint of control flow (e.g. return point from an I/O call), they will also be GC roots. They might not be very deep but they are GC roots. When a call returns, locals and parameters back up the stack will be expected to be live. Since there's no way in general to create a reference to a stack using JVM instructions (unlike .NET), the stack of every live thread must be a GC ro…
No, they are most certainly not GC roots, a fact you can actually observe in a program as described in the JEP (https://openjdk.org/jeps/444#Memory-use-and-interaction-with...).
If you want some more detail, when a virtual thread is in the runnable state, it is reachable from the scheduler (which itself is a Java object, and not a GC root); when it is blocked on a lock or IO, then the lock object or the IO mechanism must retain a reference to it, or there would be no way to unblock it. The thread object has a reference to the stack, which is a heap object (actually, it could be made up of several heap objects).
A thread that is not strongly reachable can provably no longer make progress -- it must be blocked but there's no way to unblock it -- and will be collected even if it has not terminated. It may live forever in our hearts, but not in the heap.