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

181–190 of 270 posts

Re: Java Virtual Threads Preview

#181

Post by kaba0 »

kjeetgill wrote: post #136
shrewduser wrote: post #52

Earlier quoted context omitted.

Lambda's seem like one of the least interesting features of kotlin. There's so much more going on in the kotlin world than lambdas. it seems to me that kotlin is leading the way and java is following, but the delta between them is quite large and possibly growing.

I'm not disagreeing with what you're saying here — at all. But what I am claiming is that when it comes to interest for and adoption of Kotlin within the JVM community that pull is smaller and shrinking. And that lambdas in Java are a big part of the reason for that.

Kotlin never had any real pull on the behemoth that is Java. It’s an insignificant language (outside android, where java is not the real deal to begin with). If anything, JS and C# and other major high level languages could hurt java, but fortunately it has been developing in a fast pace, implementing whatever is worthy and was experimented by other languages.

Re: Java Virtual Threads Preview

#182

Post by rbanffy »

sandGorgon wrote: post #30
vbezhenar wrote: post #26

Earlier quoted context omitted.

Java still eats like 5x ram compared to node, Java tools are slow, Java frameworks are gargantuan, even those claiming "lean". Java is fine if you don't care about RAM and start time, though.

https://quarkus.io/guides/building-native-image You should try Quarkus. It is a production framework built by Redhat. It uses Java-GraalVM under the cover to compile your entire webapp to an executable (like golang does). It's just as fast. Java is the highest performance and most tuned VM there is. I think you're really thinking of java from a long time ago, if ur thinking this

> Java is the highest performance and most tuned VM there is.

Not defending the opposite argument, but V8 is also pretty impressive. It's rooted in work done for Smalltalk long before JavaScript was a thing.

Re: Java Virtual Threads Preview

#183

Post by xxs »

closeparen wrote: post #4
abraxas wrote: post #3

Far fewer applications need this than many are led to believe. That said, this is always a welcome addition although this really doesn't add more than syntax over the stuff we've had in java.nio for a couple of decades

You can always write a callback oriented program, but this is much nicer!

It will still suck compared to NIO & DirectBuffers - and if you really need NIO, this won't be a replacement.

Using non-blocking read/write pretty quickly expands to writing your own scheduler with all the needed quirks/boosts/etc.

Re: Java Virtual Threads Preview

#184

Post by jonathanstrange »

strictfp wrote: post #142
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.

But doesn't that depend entirely on the synchronization mechanisms and how safe they are? For example, contrary to what you suggest I'd say that Go's stateless green threads are hard to debug (though there are good tools) and easily lead to deadlocks. That's because the available synchronization mechanisms finitely buffered channels, non-re-entrant mutexes, and a few atomic operations are hard to use correctly. Higher level constructs like actors or transactional memory are in my opinion less error prone.

The point is that e.g. futures are just some threads with a global synchronization mechanism for obtaining the result. Whatever makes the future stall will also make a low-level thread + your own synchronization stall. Or do you mean some more advanced failure-tolerant threading like in Erlang as compared to less advanced threading primitives like futures?

Re: Java Virtual Threads Preview

#185

Post by kaba0 »

bborud wrote: post #168
kaba0 wrote: post #148

Earlier quoted context omitted.

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 i…

Multithreading isn't synonymous with concurrency. Java was one step along the way, but let's say it had adequate representation of heavy-handed tools we already had in C/C++ that made some forms of concurrency somewhat easier. But it was still some ways from promoting concurrency in that threads were pretty costly and you still depended on locking to move state between threads. And it isn't like CSP hadn't been thoug…

Java exposes the low-level details of parallelism, but it also allows for high level abstractions on top. Thanks to that there are indeed libraries like Akka to provide something for those that prefer the actor model, but also clojure with its immutable data structure-using concurrency and anything in between like reactive libs. Of course concurrency has never been easy in practice so the low level details are hard to get right, but they are there in a sane and easy to use way, so if not the main point of the language, I would absolutely mention it as one of the most important plus features.

Re: Java Virtual Threads Preview

#186

Post by aembleton »

jpgvm wrote: post #171
Twisol wrote: post #56

Earlier quoted context omitted.

Yes, Java is finally becoming a language I don't cry myself to sleep over. I've still got other languages I (vastly) prefer, but I don't feel like I'm fighting the system nearly as much anymore. (Though, tail-call optimization would mean I don't have to obfuscate so many algorithms that are naturally recursive... it's part of Loom's charter, so maybe after virtual threads.)

I prefer Kotlin for a number of reasons but still use Java heavily as it's still a better choice in many places. I think this will be of massive benefit to both languages. Kotlin coroutines will probably be mostly relegated to multiplatform and JS backends but that is fine, server side Kotlin will take full advantage of virtual threads. :D

Where is Java a better choice than Kotlin?

Re: Java Virtual Threads Preview

#187

Post by native_samples »

pjmlp wrote: post #131
pkulak wrote: post #113

Earlier quoted context omitted.

What if the company that makes Kotlin is the one that makes the Java IDE?

They make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather. IBM does Java and the IDE (Eclipse). Red-Hat and Microsoft do Java and the IDE (VSCode).

They contribute to the JDK, mostly via the Swing project. For instance they're a major contributor to Project Lanai.

Re: Java Virtual Threads Preview

#188

Post by aardvark179 »

_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…

So in Java we know a few things about the stack that are not true for other languages. We know nothing on the stack is a pointer into a Java stack frame, and nothing on the heap points into a Java stack frame. These facts allow us to mount virtual threads onto carrier threads by copying portions of the stack to and from the heap. This is normally less memory than you’d expect because although you might have a pretty deep stack most of the work will happen in just a few stack frames, so the rest can be left on the heap until the stack unwinds to that point.

The big advantage of this over CSP is that you can take existing blocking code and run it on a virtual thread and get all the advantages, there is no function colouring limiting what you can call (give or take a couple of restrictions related to calling native code).

Re: Java Virtual Threads Preview

#189

Post by kaba0 »

didibus wrote: post #121
wruza wrote: post #78

Earlier quoted context omitted.

You (or a language) don’t have to yield-to another coroutine. You may resume and yield-from as in: coroutine producer forever while no full packet resume recv into buffer on eof return null yield (extract packet) coroutine consumer while packet = (resume producer) if packet is null break process packet which is more like a green or lightweight thread. It means that it can be pre-emptively paused and resumed, it doesn…

Wikipedia: https://en.m.wikipedia.org/wiki/Coroutine In your example, it seems to still be cooperative, you simply yield to the scheduler which is itself a coroutine and will then decide what other coroutine to yield back too. Here's a naive coroutine scheduler : ArrayList coroutines; coroutine scheduler for i = 0;; i = i++ % coroutines.size() yield coroutines[i] It's still voluntary yielding though, preemptive would…

> With a preemptive scheme like Java virtual thread, you will still have to protect shared data and have ways to coordinate and synchronize like mutex, locks and all that.

As far as I know there is nothing preventing race conditions and dead/live locks in case of coroutines either, isn’t there? Like of course if you have 1 thread these issues won’t come up, but with true parallelism, this model in itself doesn’t protect anything.

Re: Java Virtual Threads Preview

#190

Post by amitport »

clhodapp wrote: post #77
amitport wrote: post #68

Does anyone know if delimited continuations are on the roadmap with this? Potentially, virtual threads enable them (assuming a serializable environment) (co routines are also enough for this, the serialization capability is what I find interesting). This will enable a complete freeze of an execution to be stored and even send over the network to be completed somewhere else.

The idea of serializing suspended computation across a network seems extremely attractive to a lot of people but I've never understood why it's so appealing versus the more typical approach of sending whole binaries and defining messaging protocols. Could you possibly elaborate on why this capability is exciting?

For me. Code expressiveness and Simplicity.

If you can just send the computation around your basically don't need the entire message/protocol boilerplate in your execution code.

For example, think of a game engine that allows to write code with loops and calling function that may wait for an event or a rule to be true. Imagine that your game can be paused stored in case of a connection lost, synced between different server or both at a server and at a client for fast response. Now without this language feature your basic game logic code gets, you can just have a wait statement inside a loop etc., How will you return to the same place on resume? You need more code, storing the entire execution state.. on every condition or a loop you either need to store something or have code that looks like a state machine etc., With this feature you don't need special design pattern, just write it, and the mess is in the language level.

Post reply on HN