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

Java’s new garbage collector promises low pause times on multi-terabyte heaps

opsian.com

Post reply on HN
Print view View original

101–110 of 245 posts

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#101

Post by dnomad »

pkulak wrote: post #80
nicktelford wrote: post #43

Earlier quoted context omitted.

I think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.

With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.

It doesn't matter nearly as much as people believe. Value objects at this point are a kind of red herring. The JVM does aggressive escape analysis and is also very good at capturing short-lived objects. In the big picture, pointer chasing and memory latency is kind of the last frontier of performance grumps. It really becomes an issue is with very large object arrays that must be iterated over quickly. In that case it's straightforwards to implement your own value-types using code-gen or use excellent libraries like Chronicle-Values [1].

[1] https://github.com/OpenHFT/Chronicle-Values

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#102

Post by devonkim »

dnomad wrote: post #92
eikenberry wrote: post #83

Earlier quoted context omitted.

With those latency requirements why did you use Java?

Plenty of people are writing low-latency trading applications in Java where the latency budget is under 100 microseconds. This has been the case for several years now. It's by no means new or even especially difficult these days. The resulting code is far more maintainable and robust than C++ solutions.

I’ve heard a pretty effective, lazy strategy for this scenario is to oversize the heap to avoid GCs through the trading day and to simply restart the application before the next day. Unsure if it’s viable for all trading platforms, but it makes sense for some I’m sure.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#103

Post by Tuna-Fish »

pkulak wrote: post #80
nicktelford wrote: post #43

Earlier quoted context omitted.

I think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.

With generational GC, does this even matter? Generation 0 is pretty much a stack as far as performance and operation go.

When you embed a composite object into another composite object, in Java there always needs to be a pointer indirection between them. Even if GC and allocation is free, this is a massive performance loss. (For example, if you have something that would fit into 4 bytes, now you have to fit a 8-byte pointer, and the minimum created object is probably 16 bytes.)

Alternatively you can just flatten everything into a single object, but this loses out on abstraction.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#105

Post by Tarean »

There is also an interesting trick added for Shenandoah to make thread synchronization time bounded.

Basically, you don't want to check for gc in each (allocation free) loop iteration. On top of the overhead it makes optimization harder. But if you have 32+ threads then some are probably stuck in loops for a good while which means spinlocks for everyone waiting for the stop-the-world gc.

The trick to avoid this is to add an inner loop that does a fixed number of iterations and then do a gc check between each inner loop https://bugs.openjdk.java.net/browse/JDK-8186027

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#106

Post by branchless »

snaky wrote: post #67
phakding wrote: post #58

Earlier quoted context omitted.

I worked for a company where we had a 100-150 microseconds order latency. We had to tune jvm to extremes. But it is very doable to optimize Java gc for low gc pause times.

If you used to tune JVM only, that might be interesting. Most often the Java code is what being tuned - to the point where there is no point to use Java - with (almost) no gc, off-the-heap memory allocations and all that jazz.

There are more java developers you can educate to do this than good c++ dev. Plus the tooling is better in java.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#107

Post by slavapestov »

pkulak wrote: post #79
shanxS wrote: post #76

Earlier quoted context omitted.

Can you please elaborate?

It's just an object that lives on the stack, not the heap. In lots of languages when you create an object, it's pretty explicit where you're putting it. When Java was created, they wanted to get rid of that complexity, so primitives always go on the stack and objects always* go on the heap. * I think Java has escape analysis, which means that if it can determine that an object you created doesn't leave its context, i…

> It's just an object that lives on the stack, not the heap.

That's not quite correct. A reference type might contain a value type field, in which case the value type will still live on the heap.

Conversely, a local variable's type might be a value type, and _still_ involve a heap allocation. For example, std::vector in C++ is a value type but the array storage is heap-allocated.

So it's really about semantics, and not memory layout. Accessing an lvalue with a value type produces a copied rvalue; with reference types you're only copying the reference itself.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#108

Post by Jweb_Guru »

pjmlp wrote: post #93
Jweb_Guru wrote: post #88

Earlier quoted context omitted.

It's worth noting that Go's value types are not actually memory safe, however, since it allows nontrivial concurrent mutations to shared multiword objects (as described in https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... ). Unless that got fixed recently somehow? I believe in most of the other languages you mention, value types are restricted in various ways to avoid that problem (for instance, mutatio…

With the exception of Go and C#, there are no limitation on value types. All those languages are GC enabled systems programming languages. Regarding Go the memory safety in multithreaded code is orthogonal to having support for value types or not.

It's not orthogonal at all. Nontrivial mutations to multi-word sized values are inherently racy operations that can lead to UB if you don't have restrictions on how value types can be used. D isn't memory safe; Active Oberon employs mandatory object locking on writes (which is a rather heavy runtime solution); Cedar values are either immutable, or always valid with respect to word sized mutations (as far as I can tell, unions, for example, can only exist behind a pointer indirection). Modula 3 objects are not, as far as I can tell, value types (i.e. they must be heap-allocated and mutation creates a new record), and those are the only types it has where a "tearing" mutation could invalidate the runtime representation.

So, I disagree: all of the languages you mentioned either are memory unsafe when you use multiword value types concurrently, have one of the restrictions I mentioned, or (in the case of Active Oberon) conservatively lock on all writes. These value types are not "unrestricted" compared to primitives, all of which can be mutated in-place without allocating or locking, or to heap objects, which can be updated atomically even for interesting values at the cost of an allocation. Moreover, the issue is intimately tied to GC, or more accurately to the programmer not having to explicitly keep track of whether objects are uniquely owned or not (which is generally the function of a GC). As a result, if garbage collected objects can hold references to nontrivial value types, there is almost no way to avoid this problem.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#109

Post by slavapestov »

pjmlp wrote: post #23
ahamez wrote: post #8

Earlier quoted context omitted.

Could you elaborate? Why would refcount be a bad idea ? (genuine question)

Many think that refcount isn't a GC algorithm and that it is faster than GC. Well, refcounting is the basic way of implementing GC and is listed as GC algorithm in any serious CS book about GC algorithms like "The Garbage Collection Handbook". What many refer as GC is actually the GC algorithms that fall under the umbrella of tracing GC. Then refcounting is only faster than GC in very constrained scenarios: - no shar…

> Then refcounting is only faster than GC in very constrained scenarios:

Throughput is not the only concern when designing a memory management strategy though.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#110

Post by jlg23 »

pjmlp wrote: post #42
earenndil wrote: post #39

Earlier quoted context omitted.

I wonder if that would make java more suitable to game development since pauses need to be <8ms, ideally.

Java is already suitable for game development, specially with LibGDX. Not everyone needs to try to write the next Crisis in it. It certainly has higher performace than all those HTML 5 and Flash games. The biggest problem is that jMonkey is the only RAD tooling available and no match against any of engines that make use of C#.

> Java is already suitable for game development, specially with LibGDX.

I think it is safe to assume that under "game development" most people understand rather high performance demands, not a solitaire clone (esp since the comment you responded to pointed out pause-times as crucial).

Post reply on HN