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

81–90 of 120 posts

Re: Thread Pools on the JVM

#81

Post by elric »

> you're almost always going to have some sort of singleton object somewhere in your application which just has these three pools, pre-configured for use

I'm bemused by this statement, and I can't figure out whether this is an assertion rooted in supreme confidence, or just idle, wishful thinking.

That being said, giving threading advice in a virtualized and containerized world is tricky. And while these three categories seem sensible, mapping the functions of any non-trivial system onto them is going to be difficult, unless the system was specifically designed around it.

Re: Thread Pools on the JVM

#82

Post by AzzieElbab »

jackcviers3 wrote: post #12

Author mentions scala. Both ZIO[1] and Cats-Effect[2] provide fibers (coroutines) over these specific threadpool designs today, without the need for Project Loom, and give the user the capability of selecting the pool type to use without explicit reference. They are unusable from Java, sadly, as the schedulers and ExecutionContexts and runtime are implicitly provided in sealed companion objects and are therefore priv…

That gist is from D.J. Spiewak - one of the authors of cats effect :)

Re: Thread Pools on the JVM

#83

Post by Nullabillity »

azth wrote: post #64
Nullabillity wrote: post #55

Earlier quoted context omitted.

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.

True, but Loom won't really help you there since that already CompletableFuture.runAsync already uses a pooling scheduler. Same for cats-effect and zio, for that matter.

(And that's aside from CompletableFuture having its own separate problems, like the obtrude methods)

Re: Thread Pools on the JVM

#84

Post by ackfoobar »

hamandcheese wrote: post #74
ackfoobar wrote: post #65

Earlier quoted context omitted.

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.

Scala for-expressions make it pretty easy to write "direct style" code. Someone on the team should probably understand whats going on, though. I've had decent success with ZIO on my team, and it seems perfectly teachable/learnable.

I am the someone who "understand whats going on". My experience of the knowledge transfer was not pleasant at all. Maybe it's my ability of explaining, maybe it's my teammates, maybe it's ZIO having better names for combinators than Cats.

For-comprehension does help. But the alternative is callback hell all the way, so that's not saying much. It is still clunky compared to the regular syntax.

Re: Thread Pools on the JVM

#85

Post by derefr »

Nullabillity wrote: post #83
azth wrote: post #64

Earlier quoted context omitted.

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.

True, but Loom won't really help you there since that already CompletableFuture.runAsync already uses a pooling scheduler. Same for cats-effect and zio, for that matter. (And that's aside from CompletableFuture having its own separate problems, like the obtrude methods)

> already uses a pooling scheduler

A bounded pooling scheduler. (The ForkJoinPool.commonPool.)

Loom, I believe, "dummies out" the ForkJoinPool.commonPool — ForkJoinTasks/CompletableFutures/etc. by default just execute on Loom's unbounded virtual-thread executor.

(Which happens to be built on top of a ForkJoinPool, because it's a good scheduler. Don't fix what ain't broke.)

Re: Thread Pools on the JVM

#86

Post by vips7L »

_old_dude_ wrote: post #80
vips7L wrote: post #78

Earlier quoted context omitted.

What about pron's comments here then? https://news.ycombinator.com/item?id=27885569 > Second, Loom's virtual threads can also be forcibly preempted by the scheduler at any safepoint to implement time sharing

For me, preemption by the Java scheduler is not currently supported but may be added in the future, after all the goroutine were not preempted at the beginning in Go. The whole quote > Second, Loom's virtual threads can also be forcibly preempted by the scheduler at any safepoint to implement time sharing. Currently, this capability isn't exposed because we're yet to find a use-case for it I believe it's a reference…

> The whole quote

Sorry I was skimming! Thanks!

Re: Thread Pools on the JVM

#87

Post by dimitrov »

jeffbee wrote: post #41
jfoutz wrote: post #9

I'm wary of unbounded thread pools. Production has a funny way of showing that threads always consume resources. A fun example is file descriptors. An unexpected database reboot is often a short outage, but it's crazy how quickly unbounded thread pools can amplify errors and delay recovery. Anyway, they have their place, but if you've got a fancy chain of micro services calling out to wherever, think hard before putt…

Unbounded thread pools are bad, bounded thread pool executors with unbounded work queues are bad, and bounded thread pools with bounded queues, FIFO policies, and silent drops are also bad. There are many bad ways to do this.

> and bounded thread pools with bounded queues, FIFO policies, and silent drops are also bad.

Care to elaborate please? Seems like the author is recommending unbounded thread pools with bounded queues for blocking IO. Isn't that pretty similar?

Re: Thread Pools on the JVM

#88

Post by WatchDog »

sudhirj wrote: post #26
Spivak wrote: post #22

Earlier quoted context omitted.

You are ignoring the downside to green threads which is that it’s cooperative. If the thread doesn’t yield control back to the event loop then the real OS thread backing the loop is now stuck. Which leads to dirty things like inserting sleep 0 at the top of loops and dealing with really unbalanced scheduling of threads don’t hit yields often enough. Plus with loom it might not be obvious that some function is a yield…

Sleep 0 sounds like quite a hack, Go has the neater https://pkg.go.dev/runtime#Gosched instead, and I assume there will be a Java equivalent as well. And if most stdlib methods and all blocking methods call it, it's going to be pretty difficult to hang a green thread.

FWIW, Java has had `Thread#yield()`[0] since inception.

[0]: https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.h...()

Re: Thread Pools on the JVM

#89

Post by paulddraper »

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…

Yep.

Granted there are scenarios where you want 100,000 "threads of execution." And that clearly is going to be impractical for system threads.

But if your worried about the overhead of your pool of 50 threads, stop it.

Post reply on HN