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

41–50 of 245 posts

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

#41

Post by mysterydip »

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.

For a subset of developers, definitely. Overall I don't think it would lead to significantly more adoption, as the main draw (write once deploy everywhere) is already accomplished by engines like Unity.

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

#42

Post by pjmlp »

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.

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#.

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

#43

Post by nicktelford »

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 think a lack of value types also hurts Java significantly here. Though I believe they're also on the roadmap.

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

#44

Post by pjmlp »

stuff4ben wrote: post #34

Interested to know what workloads are using multi-TB heap sizes? Largest I've used has only been in the 48-64GB size and even then it seemed like a waste.

I have only heard about it in the context of Fintech, where they keep all transaction data around.

At least they seem to be Azul´s biggest customer base.

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

#45

Post by gok »

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…

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 actually shared. GC'd languages usually have semantics that require tracing for every allocation.

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

#46

Post by dllthomas »

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…

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 counting because it's now "ew, GC" is misguided.

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

#47

Post by jwr »

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)

From the hacker folklore (AI koans, available at http://catb.org/jargon/html/koans.html):

Moon instructs a student

One day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.”

Moon patiently told the student the following story:

“One day a student came to Moon and said: ‘I understand how to make a better garbage collector...

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

#48

Post by HohPum1l »

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.

On smaller heaps it was already possible to get 5-10ms pauses with the (now deprecated) CMS collector. Unlike Z it was a non-compacting collector though and had some ugly worst-case behaviors.

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

#49

Post by tw3lv3 »

waterbear wrote: post #5

Isn’t Java a pay-to-play runtime now? I thought Oracle changed the licensing model after Java 8?

Woah, buddy. Asking questions? Here on HN? Look at all these downvotes. Every single frowning disapproval is totally justified.

Because you’re useless.

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

#50

Post by Jweb_Guru »

dllthomas wrote: post #46
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…

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 intervals, much like optimized tracing implementations defer tracing to periodic intervals. This avoids reference count storms on the same objects and (especially for new objects) means much less work overall.

Post reply on HN