3 ms·
In Loom we can make some trade offs around our knowledge of the Java stack and the standard library. 1. We know that no JVM frame contains a raw pointer to any
by aardvark179 6y ago
In Loom we can make some trade offs around our knowledge of the Java stack and the standard library.
1. We know that no JVM frame contains a raw pointer to anywhere else in the stack.
2. We know which stack frames are JVM frames, and which are native frames.
3. We know that there are unlikely to be native frames in the portion of the stack between the point where we yield control and the point we want to yield to.
4. We can change the standard library to check if we are in our new lightweight thread or not and act appropriately.
Knowing these we can avoid function coloring and push the complex management of green threads into the standard library, and reuse existing task scheduler code to manage these virtual threads, and we can work to make thread local variables etc work seamlessly with this new concurrency abstraction.
This puts us in a very different design space. We can move a portion of the stack to the heap when a thread is unmounted, and we can change things about the GC and other internal systems to make them aware of this new thing that can be in the heap.
This type of approach would be much harder in a language like swift that tends to coexist with C and other languages that use raw pointers or a non-moving GC, so I think the question is not which is the better approach but which is the better approach within your language ecosystem.
- didibus 6y agoIf Loom ever comes out :p, at this point I am starting to wonder if this is a case of "the right thing" against "worse is better" and maybe we just will never see the light of Loom.
- spullara 6y agoYou can download loom and use it right now. I am pretty sure it will one day be released.
- pron 6y agoJava is at a stage where it's clear it will continue to be a popular platform and language for decades to come. It can afford to do "the right thing" because the question it's facing is not how to attract more developers now, but how to avoid mistakes its numerous developers will pay for, and build solid foundations for many years to come. It's a common difference between young and established languages, and, naturally, Java made its own fair share of design mistakes when it was young. Of course, there are technical differences that make certain design choices easier or harder in different languages. As aardvark179 mentions above, Java doesn't have pointers into the stack, and intermediate FFI frames are extremely rare (also due to the platform's established and large ecosystem). (I'm the technical lead for OpenJDK's Project Loom)
- specialist 6y agoAccording to Johnny Rotten, rock & roll died in the 70s. Narking on grandpa's compiler is just what some kids do.
- didibus 6y agoI'm very excited about Loom. I've also been waiting 3 years for it, and am probably getting impatient. I think it worries me that there still isn't any scheduled release date. And what has happened is as a user of Java, no framework has been able to develop in that time around a fiber or coroutine model, where in other languages, like C#, the TAP model has had ample time to develop and for libraries and framework to transition to it, best practices to occur, etc. While on Java we're still waiting. Now, I actually still believe Java is doing the right thing (hence the name). And the right thing if successful is more right, thus the name. And you make a good point in that Java is already popular and can probably afford to take a really long time to bring a better async story to its table. But lately I've been wondering if Loom can fail? It seems to still somewhat be experimental, is there any chance it wouldn't ship? That after all the hard work, it doesn't get merged into OpenJDK? Maybe it turns out to be more hassle, break too much user code, be too difficult to bring back to Graal, or fail to be natively compiled by Substrate, etc. Hopefully not, and I'm sure you're more aware then anyone of the risks here. And I trust you and the team working on Loom. But sometimes seeing what's happening and being done in C# and other languages, I do stop and wonder if worse is better, but when Loom does arrive (if ever?), I'll probably be happy that this was the route Java took.