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

81–90 of 245 posts

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

#81

Post by chrisseaton »

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…

You mention it in your footnote, but objects don't necessarily live on the heap - they can also live on the stack, or in registers, or in vector pipelines, or not at all.

Also an interesting aside is that objects are never 'allocated on the stack'. As in you won't find the same layout of memory on the stack as you do on the heap. Instead objects are turned into data edges in the compiler's graph. It's much more abstract than literally doing an alloca.

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

#82

Post by [deleted] »

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…

[deleted]

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

#83

Post by eikenberry »

phakding wrote: post #58
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.

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.

With those latency requirements why did you use Java?

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

#84

Post by Jweb_Guru »

readittwice wrote: post #51
Jweb_Guru wrote: post #33

Earlier quoted context omitted.

> - no sharing across threads, otherwise locking is required for refcount updates That is not true. Most atomic refcount implementations are lockfree (you do need synchronization though). This optimization has nothing to do with tracing. Given that you also need synchronization for tracing garbage collection (including frequent stop the world pauses in most cases, albeit brief ones), I don't think this is even really…

>> - no sharing across threads, otherwise locking is required for refcount updates >That is not true. Most atomic refcount implementations are lockfree (you do need synchronization though). This optimization has nothing to do with tracing. Given that you also need synchronization for tracing garbage collection (including frequent stop the world pauses in most cases, albeit brief ones), I don't think this is even real…

ZGC is interesting because it has a read barrier instead of a write barrier, yeah. But that's usually a tradeoff you make to reduce pause times, not improve throughput (IIRC it usually reduces throughput and fixing the barrier often requires an atomic write anyway, right?). For deferred / coalesced update RC the atomic overhead is amortized using (essentially) a write barrier (it only triggers at most once per object between reference counting collections, and does a similar amount of work to a traditional write barrier), and loads don't immediately require incrementing a reference count, so you end up in pretty much the same contention ballpark as a typical generational collector.

Again, the optimizations I'm describing are mostly distinct from turning RC into tracing, just applying the same sorts of optimizations we expect from production garbage collectors. The only exception is probably how in RCImmix, heavily referenced objects (4 bits are enough to precisely track something like 99.8% of objects, so "heavily referenced" refers to the other 0.2%) have their reference counts frozen so they don't pay anything until the backup trace starts. But it seems like most of the win from freezing reference counts comes from using fewer bits for the count, not avoiding the updates per se.

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

#85

Post by gok »

pjmlp wrote: post #68
gok wrote: post #45

Earlier quoted context omitted.

This is a straw man. Yes, of course, given the same code and allocation pattern, there are many cases where tracing GC will give you higher throughput than reference counting, particularly once you add in cycle detection. But in GC'd languages and non-GC'd languages you write code with completely different allocation patterns. In non-GC'd environments you only need to refcount the small set of allocations that are ac…

Plenty of GC languages have value types and support for manual memory management. Mesa/Cedar, Active Oberon, Modula-3, D, System C#, Go, C#

Sure, even Java lets you manually allocate memory via JNI, but negligible amounts of code written in those languages actually uses manual management. Reference counting is uncompetitive in those languages because idiomatic Java/C#/Go make lots of allocations and pass around lots of pointers with no lifetime semantics.

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

#86

Post by skybrian »

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.

The GC still has to move objects that survive, and this isn't deterministic. It's fine for a lot of code, but for inner loops when latency matters, you want better guarantees than that.

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

#87

Post by humbleMouse »

amelius wrote: post #52

Nice. But unfortunately, it's owned by Oracle. Use it, and you'll be constantly worrying what their lawyers are up to next.

Openjdk8 or get out! Seriously though I am concerned about the future of Java. I am keeping everything openjdk8 personally.

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

#88

Post by Jweb_Guru »

pjmlp wrote: post #68
gok wrote: post #45

Earlier quoted context omitted.

This is a straw man. Yes, of course, given the same code and allocation pattern, there are many cases where tracing GC will give you higher throughput than reference counting, particularly once you add in cycle detection. But in GC'd languages and non-GC'd languages you write code with completely different allocation patterns. In non-GC'd environments you only need to refcount the small set of allocations that are ac…

Plenty of GC languages have value types and support for manual memory management. Mesa/Cedar, Active Oberon, Modula-3, D, System C#, Go, C#

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, mutations are only allowed to value types on the stack that don't escape, or multiword value types can only be updated in ways that preserve data structure validity even if updates "tear", or multiword value types are immutable).

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

#89

Post by Sir_Cmpwn »

geezerjay wrote: post #73
amelius wrote: post #61

Earlier quoted context omitted.

Doesn't matter. Our legal system is such that Oracle can still burn you down, even if you are right.

> Our legal system is such that Oracle can still burn you down, even if you are right. Do you happen to know of any real-world case that's similar to the scenario you've described?

Google v Oracle comes to mind.

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

#90

Post by VikingCoder »

earenndil wrote: post #39
nicktelford wrote: post #4

> GC’s SPECjbb 2015 throughput numbers are roughly comparable with the Parallel GC (which optimises for throughput) but with an average pause time of 1ms and a max of 4ms. This is in contrast to G1 and Parallel who had average pause times in excess of 200ms. Not bad! Looking forward to seeing how this performs with a diverse range of workloads as it matures.

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

Hrm, I would think that if you were developing a game in a GC environment, where GC timing turned out to be a problem, you would get rid of dynamic memory allocation, and try to do everything much more like embedded system programming with fixed memory blocks...?

I suppose at the complexity of modern games that's simply not possible anymore...

Post reply on HN