GC's haven't freed us from manual memory management, you just do all that manual work with environment variables, or making sure to "pick the right collector for the job", or debugging performance or heap size issues, or chasing down weak references or confused finalizers.

▲

pron 3 days ago | parent [-]

> you just do all that manual work with environment variables

You really don't anymore. For the past several years, Java's GCs mostly pick the right settings automatically, except for heap size, which will be taken care of soon (https://openjdk.org/jeps/8377305). The reason heap size isn't automatic is that with moving collectors it determines the CPU/RAM tradeoff, and doing that in a more natural way isn't trivial, but we have the algorithm now and will merge it soon.

> or making sure to "pick the right collector for the job"

There are really only four options, most of which are easy to choose among: Parallel for batch jobs where only throughput matters, ZGC for interactive applications where latency matters a lot, and then consider either G1 or Serial if there's a problem with those choices.

As someone who's worked for a long, long time solving manual memory management issues, the amount of effort required isn't just in a different ballpark, but in a different city. Sure, spending a few hours a year to reconsider your settings isn't nothing, but it isn't even remotely in the same category of pain with manual memory management (or even automatic memory management, but with malloc/free underneath).

▲

hedora 3 days ago | parent [-]

Concretely, what are current tail latencies, worst case?

Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load.

Most servers I work with run on big machines and are the only process, so figure a 100-250GB heap that lives for months, all async, small requests, so insane amounts of Future and String allocation spam.

Optimizing that stuff away in Java is harder than writing Rust, so assume idiomatic Java.

Also, is there any work on statically enforcing data race freedom in Java? That’s a bigger rust selling point than memory safety for me. I think swift has done some interesting work in that space. It would be nice to get those sorts of safety properties without manually writing borrow checker annotations.

	▲	stmw 3 days ago \| parent \| next [-]
		As the OC, I think my view is somewhere in the middle - I am neither as optimistic about it being "great now" nor do I think that "rewrite in C++" 10 years ago was easier. My reason for disagreeing with the former view is that improvements in physical RAM available and tendency towards smaller workloads have allowed many Java (or other GC runtimes) to essentially "fix their problems because hardware got better". So you can waste more RAM, waste more cycles, but "it doesn't matter", and likely it is fine in many cases - but it's is not the same thing as claiming the GC algorithms are responsivle for that outcome. We have been 3 years away from GC solving memory management for at least 30 years. My reason for disagreeing with the latter view is that for those who don't have 100-250 GB long-lived heaps (or whatever the contemporary version of that is), the pain level is far lower than rewriting in C++ or Rust, or likely the pain level of hiring enough engineers who can do either. It's a completely different engineering culture.
	▲	pron 3 days ago \| parent \| prev [-]
		> Concretely, what are current tail latencies, worst case? Well under 1ms for ZGC (to the point that OS-caused hiccups are of similar magnitudes). > Ten years ago, “rewrite in C++” was definitely easier than getting the Java GC to stay up under server load. Both could have been hard in some cases, but open-source "pauseless" GCs are only 3 years old (and all of the JDK's GCs are nothing like what they were ten years ago). > Optimizing that stuff away in Java is harder than writing Rust, so assume idiomatic Java. Quite the opposite. Performance issues due to memory management are, in practice, more serious in Rust than they are in modern Java. > Also, is there any work on statically enforcing data race freedom in Java? There isn't much demand for that atm. If we see growing demand, we could prioritise it.