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

Java Virtual Threads Preview

openjdk.java.net

Post reply on HN
Print view View original

141–150 of 270 posts

Re: Java Virtual Threads Preview

#141

Post by bborud »

I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems.

I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages really suck because they are no longer a single language. You get islands of different practices and a partitioned set of practitioners. And they can't always use each other's code (C++ being the most extreme and painful example).

This makes me kind of glad I switched to Go 5-6 years ago. And it makes me wonder when the (good) intentions of the Go designers to not absorb every idea that comes along will go out the window and Go will start to grow knobbly bits all over.

Re: Java Virtual Threads Preview

#142

Post by strictfp »

cryptonector wrote: post #64

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…

My biggest gripe with continuations, futures and callbacks is the propensity for stalls; if the programmer makes a mistake it's quite likely that the program will just stall, with very little insight available as to why that happened.

With threads, green or not, you have a much clearer failure model and is easier to debug.

Re: Java Virtual Threads Preview

#143

Post by dastbe »

bborud wrote: post #141

I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM ) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages r…

your comment surprises me, because this kind of development is explicitly trying to avoid bifurcating the language. i would argue that the async io/futures libraries that exist in java are the bifurcation because programming with them is very jarring compared to threaded java.

Re: Java Virtual Threads Preview

#144

Post by kccqzy »

cryptonector wrote: post #64

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…

> With CPS you manually compress state into tuned structures. With threads you store state all over the stack in very inefficient ways because all those stack frames take extra space.

On the other hand, these stack frames can be thought of as a large arena allocator for what would otherwise be lots of smaller objects allocated on the heap.

Re: Java Virtual Threads Preview

#145

Post by _0w8t »

pkulak wrote: post #13
vlovich123 wrote: post #11

Earlier quoted context omitted.

Am I understanding correctly that this is basically goroutines for Java?

Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well. Also, there's no new syntax, so you're stuck with all the sam…

In Go one can block the native thread via using API that use blocking OS calls, like Linux file IO. In this case Go runtime allocates more native threads to run other language threads.

Re: Java Virtual Threads Preview

#146

Post by [deleted] »

cryptonector wrote: post #64

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…

[deleted]

Re: Java Virtual Threads Preview

#147

Post by kccqzy »

bborud wrote: post #141

I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM ) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages r…

Does Go have closures? Yes it does. Therefore you can start writing everything in an async style, manually passing closures around. Then build an executor interface. Voilà. Here's an utterly alien Go codebase that doesn't use green threads.

It has nothing to do with language. It has everything to do with how other libraries (especially standard libraries) structure their code.

Re: Java Virtual Threads Preview

#148

Post by kaba0 »

bborud wrote: post #141

I've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM ) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages r…

I think you can say that for any language, other than Java. It is a deliberately slow moving language, with very few keywords and concepts going for it. It was always meant to be a simple language on top of a very high-end runtime — and indeed they manage to implement loom with no language change. Also, concurrency not being inherent to java? It was the first major language with good support for multithreading with its synchronized keyword.

Re: Java Virtual Threads Preview

#149

Post by The_rationalist »

_0w8t wrote: post #139
bodhiandpysics1 wrote: post #124

Earlier quoted context omitted.

Maybe? it depends how you use them... any asynchronous operation will require memory, and that memory has to go somewhere. In CPS it goes on the heap... in the threaded style you have a stack you can put it on. This probably will waste some memory, though not as much as you might think. On the other hand, you can also reclaim the stack memory as soon as the operation finishes. The CPS technique creates garbage that a…

Green threads by definition cannot use OS stack and must allocate their stack memory on heap. Although this memory can be reused, as it is known from Go to avoid performance bottlenecks at least for Go code is better to allocate the stack as single continues block and copy the stack to a bigger block when thread’s stack reaches the current stack size. But then the whole stack space is pinned to the thread and cannot…

Java can create its own stack, it doesn't matter if it's on the heap if semantically and optimization wise it behave like the stack. See also: the metaspace

Re: Java Virtual Threads Preview

#150

Post by The_rationalist »

Skinney wrote: post #104
sandGorgon wrote: post #37

Interestingly, Kotlin Coroutines have been available and in production for a LONG time now. https://github.com/Kotlin/kotlinx.coroutines In fact, Kotlin Coroutines are an brilliant on the android platform. We are talking severely memory and CPU constrained architectures here. That said, Kotlin Coroutines are popularly used in production on server side - https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/ I dou…

> I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. Switching to virtual threads will, at least in the microservices I work with, involve changing a few lines (Executors.newUncachedThreadPool() -> Executors.newVirtualThreadPool()). Switching to Kotlin coroutines will involve re-writing a large part of our codebase, which is why it hasn't been done. It would surprise me if people did…

No you can use a few lines of kotlin coroutines in an otherwise java codebase.
Post reply on HN