TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

State of Loom

202 点作者 mxschumacher大约 5 年前

19 条评论

ceronman大约 5 年前
This is my favorite JVM project and I think it&#x27;s going to be huge!<p>This model of concurrency is so much better than the async&#x2F;await model used by many other languages. No more colored functions [1], or worse Completable&lt;Future&gt;, promises et al. Nice stacktraces, debuggers that work plus no need for thread pools anymore. I can&#x27;t wait for this to be ready for production.<p>Only drawback seems to be when calling native code. I guess it&#x27;s the same problem that Golang has. Good thing is that the Java ecosystem is not that dependent on native stuff, so I think it&#x27;s a fair tradeoff to make.<p>[1] <a href="https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">https:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-...</a>
评论 #23202812 未加载
评论 #23203321 未加载
评论 #23203226 未加载
评论 #23202658 未加载
jmartrican大约 5 年前
I been waiting for this project for a while. I saw an amazing demo of this on youtube video. In the demo a regular Jetty server running a simple endpoint that slept for 1 sec was DOSd with multiple concurrent requests. You can see as the number of concurrent requests increased, the execution time increased. The presenter then changed the code of the Jetty server to create a new Fiber vs a Thread. Then reproduced the test and this time there was no increase in execution time.<p>What I really like about this project is that we can keep Spring MVC applications in non-reactive form. Spring MVC came out with reactive framework for implementing APIs. But I&#x27;m not a fan of this style for a few reasons, plus there is millions of LOC doing it the non react implementation. By utilizing project Loom, we do not have to switch over to the Spring reactive way, and we can increase the performance of existing code.<p>EDIT: Here is the video: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Csc2JRs6470" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=Csc2JRs6470</a>:<p>- he goes into Loom at 19:30.<p>- he goes into the demo at 24:00.
MrBuddyCasino大约 5 年前
&gt; A virtual thread is a Thread — in code, at runtime, in the debugger and in the profiler.<p>To explain: if you debug async code on Kotlin right now, you cannot single-step in a debugger, because the debugger attaches to a thread. But coroutines get scheduled on different threads all the time!<p>I wonder what this means for ThreadLocals and Locks? Will they work as before? If so, that is huge! Because locks don&#x27;t work with async code either, for obvious reasons. The consequence is that the whole ecosystem is split in two parts! You cannot just use a Guava cache in Kotlin coroutine-based code.<p>If Loom manages to avoid all of this, this is fantastic news.
评论 #23202637 未加载
评论 #23203127 未加载
评论 #23202696 未加载
doctor_eval大约 5 年前
I was reading about Go threads just the other day and the article mentioned that Go uses green threads because they are more efficient.<p>I thought this was weird because IIRC Java 1.0 used green threads in Linux and it was a big deal when they moved to OS threads.<p>I’ve long believed that the IT world moves in cycles but this is a very clear example of exactly that. Java has gone from green threads to Posix threads and now back to green threads.<p>I do think it’s awesome (I love goroutines) and Threads in Java have become a but of a nightmare, made a little easier with executors and CompletableFutures. So this further improvement is great news.<p>But still... call me when the builder pattern is dead.
评论 #23203275 未加载
评论 #23203456 未加载
nahuel0x大约 5 年前
How Loom manages killing a vthread from another vthread? In Erlang you can do it safely and without needing to check a cancellation signal in the process to be killed. Also, Erlang has per-process heaps, an usually overlooked feature that gives soft-realtime capabilities, avoiding GC hiccups. JVM+Loom seems to be closer to Go than Erlang.
评论 #23212466 未加载
评论 #23208186 未加载
klysm大约 5 年前
I&#x27;m really excited to see how this impacts the performance of akka and other stream-like things in the JVM ecosystem. I&#x27;ve spent far too much time tinkering with thread pools and digging through profiles with Unsafe.park everywhere.
dang大约 5 年前
See also:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17646169" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17646169</a> from 2018<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15599854" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15599854</a> from 2017<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23194215" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23194215</a> - 3 comments from a few days ago
评论 #23208723 未加载
aidenn0大约 5 年前
Does Loom make JNI unusable [edit] C-f JNI is my friend. They pin a fibre to an OS thread for the dynamic extent of a JNI call.
pizlonator大约 5 年前
This is great. If I grok right this is basically the best of native threads and the best of green threads put together.<p>I think I proposed this at a crazy idea talk at VEE a long ass time ago (10 years or more). It’s still a good idea but I guess not crazy anymore.
e12e大约 5 年前
&gt; A server can handle upward of a million concurrent open sockets, yet the operating system cannot efficiently handle more than a few thousand active (non-idle) threads.<p>Does anyone have a reference to some up to date notes on the state of scalability of Linux and&#x2F;or free-&#x2F;dragonfly-bsd scalability at the process level?<p>I don&#x27;t doubt processes are a bit heavy for scaling to a million active threads of execution - but it&#x27;d be nice to see what one could expect on a low end server (say 16 cores, 64gb ram) today?
评论 #23208440 未加载
artemonster大约 5 年前
Can Loom be used to simulate RTL &amp; verification language on top of that (similar to SV or e)? I mean practically (since theoretically the answer is yes)
haspok大约 5 年前
Why is there still no timeline? I don&#x27;t see any previews, let alone GA features in JDK15, which means that by JDK17 probably nothing&#x27;s going to be released. Which is sad, because that pushes the GA to the next LTS a extra few years down the line... (2023&#x2F;2024 the earliest) :(
评论 #23221347 未加载
elric大约 5 年前
In case anyone else is confused about some of the internal links appearing to be broken (e.g. the Scope Variables link), the content is on the second page.
eiopa大约 5 年前
This reminds me a lot of python’s gevent.<p>I often wish the language had adopted it instead of the C#-like await async, since it’s just more straightforward.
评论 #23207953 未加载
The_rationalist大约 5 年前
Are there still legitimate use cases of using real threads vs virtual threads?
chewbacha大约 5 年前
Hmm I love having cake...<p>...and eating it too
MattTse大约 5 年前
Anyone else read this, and read it as google&#x27;s Project Loon, and wonder what java has to do with it?
Igelau大约 5 年前
Anyone else disappointed this wasn&#x27;t about Lucasarts Loom (1990)?
评论 #23208057 未加载
评论 #23208195 未加载
jayd16大约 5 年前
Seems fine but I&#x27;m confused by the async&#x2F;await hate. At least in C# it seems to me thee is already a superset of Loom through async&#x2F;await.<p><pre><code> Thread.startVirtualThread(() -&gt; {}); </code></pre> Starts a new virtual thread that will run a synchronous method. Ok cool. C# already has:<p><pre><code> Task.Run(()=&gt;{}) </code></pre> This will run synchronously on the shared thread pool. Tasks are futures and can return objects. Same as the Loom proposal.<p>Optionally you can decide to opt into the await unboxing sugar by adding async to your method signature. There&#x27;s arguably some double dipping with the async keyword on a method. It allows the await keyword to be used inside the method but also forces the caller into a different calling style. You can argue this shows API intent for cooperative threading. That said, you can still use async and sync interchangeably.<p>The syntax seems very similar to me.<p>Is there something else going on in Loom that I&#x27;m missing? Is it a matter of how the virtual threads are scheduled&#x2F;preempted vs how other languages with async&#x2F;await schedule their tasks?
评论 #23205772 未加载
评论 #23205726 未加载