Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thread Pools on the JVM

gist.github.com

Post reply on HN
Print view View original

61–70 of 120 posts

Re: Thread Pools on the JVM

#61

Post by jeffbee »

dragontamer wrote: post #56
jeffbee wrote: post #49

Earlier quoted context omitted.

I don't think the question is dominated by machine state, I think it would be more of a question of stack size. They are demand-paged and 4k by default for native threads, 2k by default for goroutines but stored on a GC'd heap that defaults to 100% overhead, so it sounds like a wash to me.

Hmmm. It seems like you're taking this from a perspective of "Pthreads in C++ vs Coroutines in Go", which is correct in some respects, but different from how I was taking the discussion. I guess I was taking it from a perspective of "pthreads in C++ vs Go-like coroutines reimplemented in C++", which would be pthreads vs C++20 coroutines. (Or really: it seems like this "Loom" discussion is more of a Java thing but pro…

Right, I admit there are better ways to do it, but I don't think it's obviously true that goroutines specifically are either more compact or faster to switch between. The benefits might be imaginary. The Go runtime has a thread scheduler that kinda sucks actually (it scales badly as the number of runnable goroutines increases) and there are also ways of making native threads faster, like SwitchTo https://lkml.org/lkml/2020/7/22/1202

Re: Thread Pools on the JVM

#62

Post by dragonwriter »

jjtheblunt wrote: post #57
dragonwriter wrote: post #29

Earlier quoted context omitted.

> Are we coming full circle going back a variant of the original Java green threads? There are basically two kinds of green threads: (1) N:1, where one OS thread hosts all the application threads, and (2) M:N, where M application threads are hosted on N OS threads. Original Java (and Ruby, and lots of other systems before every microcomputer was a multicore parallel system) green threads were N:1, which provide concu…

I worked in Solaris internals for a while at Sun during the early java era, and Solaris threading definitely did multiplexing of userspace onto os, and then os onto cores. Do you have a citation (because I can't find one) specifying your assertion that original Java green threads were not analogous to Solaris user -> os -> hardware multiplexing?

> Do you have a citation (because I can't find one) specifying your assertion that original Java green threads were not analogous to Solaris user -> os -> hardware multiplexing?

I was writing from memory of second-hand after-the-fact recitations of the history. Doing some followup research prompted by your question, if I understand this document [0] correctly, Java initially had N:1 green threads on Solaris, then M:N green threads on Solaris with 1:1 native threads on Unix and Windows.

[0] https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/

Re: Thread Pools on the JVM

#63

Post by _old_dude_ »

vips7L wrote: post #51
_old_dude_ wrote: post #19

Earlier quoted context omitted.

Unlike go routine, Loom virtual threads are not preempted by the scheduler. I believe you may be able to explicitly preempt a virtual thread but the last time i checked it was not part of the public API

Unless I'm misunderstanding, virtual threads are preemptive: https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1....

By the OS, not by the scheduler see https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2....

Re: Thread Pools on the JVM

#64

Post by azth »

Nullabillity wrote: post #55
elygre wrote: post #48

Earlier quoted context omitted.

What is broken-by-design about the api?

Fundamentally, an async API is either data-oriented (Futures/Promises: tell me what data this task produced) or job-oriented (Threads: tell me when this task is done). You can think of it like functions vs subroutines. Since you typically care about the data produced by the task, threads require you to sort out your own backchannel for communicating this data back (such as: a channel, a mutexed variable, or something…

Good points, but as far as I can tell, there's nothing preventing you from spawning a bunch of Loom-thread backed `CompletableFuture`s and waiting on them.

Re: Thread Pools on the JVM

#65

Post by ackfoobar »

ovis wrote: post #14
cogman10 wrote: post #2

Loom can't land fast enough! The current issue the JVM has is that all threads have a corresponding operating system thread. That, unfortunately, is really heavy memory wise and on the OS context switcher. Loom allows java to have threads as light weight as a goroutine. It's going to change the way everything works. You might still have a dedicated CPU bound thread pool (the common fork join pool exists and probably…

What benefits does loom provide vs using something like cats-effect fibres?

For the team that I am in, I can see a huge productivity boost if my teammates can write in direct style instead of wrapping their heads around monads.

Re: Thread Pools on the JVM

#67

Post by truffdog »

hawk_ wrote: post #54
cbsmith wrote: post #53

Earlier quoted context omitted.

Java had M:N green thread models a LOOOOONG time ago. And Linux tried M:N thread implementations specifically to improve thread performance. In both cases, it turned out that just using 1:1 native threads ended up being a net win.

i am not aware of M:N thread builtin in Java even from long time ago, at least not in a way that you could control N

It was Solaris only, so there is definitely an asterisk somewhere.

Re: Thread Pools on the JVM

#69

Post by kllrnohj »

cbsmith wrote: post #52
cogman10 wrote: post #2

Loom can't land fast enough! The current issue the JVM has is that all threads have a corresponding operating system thread. That, unfortunately, is really heavy memory wise and on the OS context switcher. Loom allows java to have threads as light weight as a goroutine. It's going to change the way everything works. You might still have a dedicated CPU bound thread pool (the common fork join pool exists and probably…

> That, unfortunately, is really heavy memory wise and on the OS context switcher. So, there was a time where a broad statement like that was pretty solid. These days, I don't think so. The default stack size (on 64-bit Linux) is 1MB, and you can manipulate that to be smaller if you want. That's also the virtual memory. The actually memory usage depends on your application. There was a time where 1MB was a lot of mem…

> So, there was a time where a broad statement like that was pretty solid.

That time is approaching 20 years old at this point, too. Native threads haven't been "expensive" for a very, very long time now.

Maybe if you're in the camp of disabling overcommit it matters, but otherwise the application of green threads is definitely a specialized niche, not generally useful.

> In the broad set of use cases though, switching from a thread-based concurrency model to something else isn't going to be the big win people think it will be.

I'd go even further and say it'll be a net-loss in most cases, especially with modern complications like heterogeneous compute. If you're use case is specifically spinning up thousands of threads for IO (aka, you're a server & nothing else), then sure. But if you aren't there's no win here, just complications (like times when you need native thread isolation for FFI reasons, like using OpenGL)

Re: Thread Pools on the JVM

#70

Post by cbsmith »

truffdog wrote: post #67
hawk_ wrote: post #54

Earlier quoted context omitted.

i am not aware of M:N thread builtin in Java even from long time ago, at least not in a way that you could control N

It was Solaris only, so there is definitely an asterisk somewhere.

It was all very long ago, but the NGPT project did M:N threading on Linux (https://web.archive.org/web/20020408103057/http://www-124.ib...).

There were also a number of M:N JVM implementations that were particularly popular in the soft-realtime space back in the early 2000's.

One of the fun trends with computing is that as hardware, software, and applications evolve, ideas that were once not terribly useful suddenly become useful again. It's entirely possible that M:N threads for the JVM is one of those cases, but it's NOT a new idea.

Post reply on HN