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

Java 21: The Nice, the Meh, and the Momentous

horstmann.com

Post reply on HN
Print view View original

171–180 of 191 posts

Re: Java 21: The Nice, the Meh, and the Momentous

#171

Post by hinkley »

vips7L wrote: post #148
rr808 wrote: post #103

Earlier quoted context omitted.

Scala community always thinks they're the best tool. The size of the community is at best static though, Kotlin and re-energized Java took away most of the reasons for using it. I know in my company the teams that went the Scala route complain of huge compile times and really struggle to find people, I think we'll probably port back to Java.

Scala is just too complex, the tooling too slow, and the community had way too many breaking changes.

I went through a Scala book with a reading group. Lots of incredulity all around. Much more than the Java concurrency book, which wasn't easy either.

An 'academic' language if ever there was one.

But I recall it as the first vaguely Erlang-like language on the JVM, so whenever something about threading comes up I recall it.

I'm learning Elixir instead.

Re: Java 21: The Nice, the Meh, and the Momentous

#172

Post by brabel »

munificent wrote: post #168
brabel wrote: post #118

Earlier quoted context omitted.

I don't find symbols to be pointless. They are useful as "interned strings" and that's exactly what I need sometimes. I could use `const myThing = "my thing";` for that purpose (but with symbols I don't need to declare it anywhere, just use it... for better or worse!), I suppose, but before `const` existed, I believe symbols were the only way to do that?

> They are useful as "interned strings" and that's exactly what I need sometimes. I'm not sure exactly what you mean by "need" here, but as far as I know, Dart doesn't make any promises about the memory management or efficiency of either strings or symbols. If I were you, I'd just use strings.

I had to double check this, because basically the only use of symbols in any languages is to provide a constant value you can treat as an internalized string (like Common Lisp keywords, for example). The would be entirely useless if that were not the case.

Luckily, the current Dart specification does guarantee this (section 17.8):

"Assume that i ∈ 1, 2, and that oi is the value of a constant expression which is a symbol based on the string si. If s1 == s2 then o1 and o2 is the same object. That is, symbol instances are canonicalized."

Apparently, there's even special treatment for "private symbols", which are only the same object "in the same library". TIL.

Source: https://spec.dart.dev/DartLangSpecDraft.pdf

EDIT: there's even a whole sentence justifying the existence of symbols as being related to reflection, actually... they say Dart literal Strings are already "canonicalized" so that fact about Symbols is not enough for that.... hence you're right that String literals are just as good for the use-cases I had in mind. I guess I will use String literals from now on after all.

EDIT 2: > I'm not sure exactly what you mean by "need"

Hopefully it's clear what I "needed" now... basically, interned Strings to avoid wastefully comparing bytes when a pointer comparison would suffice as all values are known at compile-time.

Re: Java 21: The Nice, the Meh, and the Momentous

#173

Post by defatigable »

Freaky wrote: post #88
defatigable wrote: post #33

Earlier quoted context omitted.

This is a niche case, but I spent months trying to upgrade one of our services from one LTS version to the next (I forget which). We encountered a weird bug where services running on the latest JRE would mysteriously corrupt fields when deserializing thrift messages, but only after running for a little while. After an enormously unpleasant debugging cycle, we realized that the JIT compiler was incorrectly eliminating…

I encountered a weird bug with deserializing JSON in a JRuby app during an OpenJDK upgrade - it would sporadically throw a parse error for no apparent reason. I was upgrading to OpenJDK 15, but another user experienced the same regression with an LTS upgrade from 8 to 11. The end result of my own investigation led to this quite satisfying thread on hotspot-compiler-dev, in which an engineer starts with my minimal rep…

fastdebug is a good tip, thanks for sharing!

Re: Java 21: The Nice, the Meh, and the Momentous

#174

Post by ackfoobar »

riku_iki wrote: post #170
nvm0n2 wrote: post #169

Earlier quoted context omitted.

Are you aware you're talking to the guy who added virtual threads to the JVM? Disagree on design if you wish, but the idea he isn't an expert in these matters is a bit silly.

He is person on salary in oracle, which is not top tier tech company. There are tons of virtual threads like frameworks were implemented in JVM and in other languages, looking at his github profile he has 5 years experience in working on this thread stuff, before that he worked on some bloated j2ee stuff, all of these doesn't qualify for some unconditional authority, so I judge him base on his expertise demonstrated…

> 5 years experience in working on this thread stuff

He had worked on "thread stuff" before working on loom on the JVM. I did a search and that's 10 years ago.

https://web.archive.org/web/20130601144756/https://blog.para...

Re: Java 21: The Nice, the Meh, and the Momentous

#175

Post by IAmLiterallyAB »

jlokier wrote: post #116
pron wrote: post #90

Earlier quoted context omitted.

> That post was written in 2021, does it still hold true today in Java 21? Yes. > Does Java Virtual Threads do the same, or does disk I/O block the carrier threads? For curiosity, does Java file APIs use io_uring on Linux if it is available? We're working on using io_uring where available, especially for filesystem IO. For now, filesystem IO blocks OS threads but we temporarily compensate by increasing the size of th…

In late 2021 I compared OS threads to io_uring for filesystem I/O at random-access reads from fast, NVMe SSDs. That measurement told me that it's not necessary to use io_uring for disk I/O performance for some workloads. It found no improvement in performance from io_uring, compared with a dynamic thread pool which tries to maintain enough I/O-blocked threads to keep the various kernel and device queues busy enough.…

> less than a page; about 1kiB IIRC

Interesting, didn't realize the kernel would let you do that. I guess it makes sense since it's up to user space to map pages for the stack. The kernel doesn't have much to do on clone except set the stack pointer.

Re: Java 21: The Nice, the Meh, and the Momentous

#176

Post by riku_iki »

ackfoobar wrote: post #174
riku_iki wrote: post #170

Earlier quoted context omitted.

He is person on salary in oracle, which is not top tier tech company. There are tons of virtual threads like frameworks were implemented in JVM and in other languages, looking at his github profile he has 5 years experience in working on this thread stuff, before that he worked on some bloated j2ee stuff, all of these doesn't qualify for some unconditional authority, so I judge him base on his expertise demonstrated…

> 5 years experience in working on this thread stuff He had worked on "thread stuff" before working on loom on the JVM. I did a search and that's 10 years ago. https://web.archive.org/web/20130601144756/https://blog.para...

which makes quality of discussion even more confusing.

Re: Java 21: The Nice, the Meh, and the Momentous

#177

Post by ackfoobar »

winrid wrote: post #114
za3faran wrote: post #110

Earlier quoted context omitted.

Do you have a citation for that? Genuinely curious.

The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway. [0] https://openjdk.org/jeps/444

> The stack for the VT requires a heap allocation

One object per stack frame of a virtual thread is cheaper than one callback object per suspension point.

Re: Java 21: The Nice, the Meh, and the Momentous

#178

Post by zmmmmm »

fulafel wrote: post #125
zmmmmm wrote: post #76

Earlier quoted context omitted.

I think virtual threads are huge. The problem with regular threads is (a) multi-kb memory stack per thread and (b) consuming a file handle. Either of those severely limits the scalability of the most "natural" parallelism constructs in Java (perhaps generally). Whole classes of application can now just be built "naturally" where previously there were whole libraries to support it (actors, rxJava, etc etc). It make ta…

You could easily have a million threads if you use multi-kb stacks. Million times multi-kb means multi-gb, that's still 3-4 orders of magnitude less than big memory servers/VMs. (and 1 order of magnitude less than a normal laptop) What do you mean by using a file handle, is this a Windows platform thing? On *ix, threads don't use up file descriptors (but you can still have a million fd's at least on linux for other s…

> On *ix, threads don't use up file descriptors

Thanks - this caused me to dig into the specific scenario where creating threads was exhausting file handles in my experience and you are correct - consuming a file handle is indeed not intrinsic to creating a new thread in Linux. It's insanely easy for literally anything you do with the thread to consume a file handle, but of course, that applies to virtual threads as well. Thanks!

Re: Java 21: The Nice, the Meh, and the Momentous

#179

Post by winrid »

ackfoobar wrote: post #177
winrid wrote: post #114

Earlier quoted context omitted.

The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway. [0] https://openjdk.org/jeps/444

> The stack for the VT requires a heap allocation One object per stack frame of a virtual thread is cheaper than one callback object per suspension point.

I guess I'm thinking of cases where I would invoke a virtual thread from a reactive framework per request in which case you need the callback regardless. I guess if you can do away with that then, maybe. I need to benchmark it.

Re: Java 21: The Nice, the Meh, and the Momentous

#180

Post by winrid »

vips7L wrote: post #146
winrid wrote: post #114

Earlier quoted context omitted.

The stack for the VT requires a heap allocation [0], which ok, not huge deal for most scenarios, but something to consider. Reactive programming will avoid that. For example, for a service that doesn't do much IO (like an in memory pubsub thing or CDN) you would still want to use reactive programming if you care about performance, since likely the code will be simple anyway. [0] https://openjdk.org/jeps/444

But what’s more expensive, some more ram? Or the hours upon hours upon hours wasted in dev salaries trying to develop and debug reactive code? Also is that VT allocation more than all of the extra allocations from reactive frameworks internally? Or all of the heap capturing lambdas that you pass to reactive libraries? Do you have a source comparing any of this?

Well I'm one person running several reactive services for fastcomments right now and I have no issues... so in my case the ram is more expensive :p but I am looking forward to benchmarks.
Post reply on HN