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

51–60 of 245 posts

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

#51

Post by readittwice »

Jweb_Guru wrote: post #33
pjmlp wrote: post #23

Earlier quoted context omitted.

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…

> - 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 really an advantage of tracing at all.

Not sure I agree with that. Copying references between local variables and reads/writes from heap all require expensive atomic operations for RC when they can't be optimized away. That's a major performance problem for languages like Swift. I do not say that one is better than the other, but this is exactly where tracing GC's shine compared to RC.

In the case of ZGC these doesn't require atomic operations, you need a read barrier for reading references from the heap though. But do not conflate tracing GC's read & write barriers with atomic barriers.

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

#54

Post by readittwice »

Jweb_Guru wrote: post #50
dllthomas wrote: post #46

Earlier quoted context omitted.

With refcount you need to sync every time you add/remove a reference to an object. For many (most?) workloads that's going to be quite substantially more frequent than tracing collections. Whether one or the other wins out probably depends a lot on your use case. More generally, I think the parent comment was not aiming to say that reference counting is never appropriate, but that blindly going with reference countin…

> With refcount you need to sync every time you add/remove a reference to an object. For many (most?) workloads that's going to be quite substantially more frequent than tracing collections. Whether one or the other wins out probably depends a lot on your use case. That's not actually true of deferred reference counting with update coalescing. Instead, it defers the refcount increments and decrements to periodic inte…

How many languages use this approach though? This probably also removes one major advantage of RC'ed systems though: deterministic destruction (e.g. close resource as soon as last reference disappears). And suddenly you need some kind of runtime too.

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

#55

Post by ridiculous_fish »

ahamez wrote: post #8
M_Bakhtiari wrote: post #6

I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.

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

In addition to what others have said, the choice of memory management schemes has big knock-on effects. It influences how much runtime metadata you need to retain (e.g. stack maps), it has lots of implications for the FFI, and may constrain various tricks like unions, tagged pointers, NaN boxing, etc. So narrowly comparing schemes in terms of just allocation throughput won't paint the whole picture.

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

#56

Post by hinkley »

M_Bakhtiari wrote: post #6

I'm glad they didn't buy into the refcount meme that's so inexplicably popular these days.

A lot of the early Java press about their use of GC involved decrying the state of other interpreted languages that were still stuck on reference counting, and the problem of circular references.

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

#57

Post by [deleted] »

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.

[deleted]

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

#58

Post by phakding »

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.

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.

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

#59

Post by shaftway »

pitaj wrote: post #37
DSMan195276 wrote: post #30

Earlier quoted context omitted.

Agreed - I'd go farther to say it only works for addresses in the userspace half, so on Linux you lose an extra bit and only get 47 (I don't know how the mappings are setup for Windows/OSX, sorry). It also might be worth pointing out that you now need 16x the page mappings (Since every mapping needs 15 duplicates for the possible flag states) - I don't know how Java does it's memory management but if it does lots of…

> It also might be worth pointing out that you now need 16x the page mappings (Since every mapping needs 15 duplicates for the possible flag states) Nope. They went into this in the article: > Since by design only one of remap, mark0 and mark1 can be 1 at any point in time, it’s possible to do this with three mappings. There’s a nice diagram[1] in the ZGC source for this. [1]: http://hg.openjdk.java.net/zgc/zgc/file/…

And it looks like you only need 3 mappings for the entire space. It's not like you need one per object in memory. Unless I misunderstood the gist of the article.

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

#60

Post by gct »

obl wrote: post #7

The memory mapping trick they use on x86 to avoid masking only works up to the maximum 48 bits of addressable virtual memory, so there is much less than 22 free bits in that case. It's also not quite free since it takes up TLB space.

x86 caches uses virtual address for indexing (physical bits for tag), so this'll increase cache pressure too.
Post reply on HN