Live data from Hacker News

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

opsian.com

181–190 of 245 posts

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

#181

> today AWS will happily rent you an x1e.32xlarge with 128 vCPUs and an incredible 3,904GB of ram. > ... > ZGC restricts itself to 4Tb heaps Isn't a 4TB heap limit short-sighted for a GC intended to last over a decade?

4TB uses 42 bits of address space. It leaves you with 22 bits, out of which ZGC uses 4. If anything, borrow a few more bits, and you should easily be able to address petabytes.

> 4TB uses 42 bits of address space.

Can't you compress that into less than 42 bits?

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

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

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…

I agree that it definitely can't be completely without cost. But I'll speculate that they may have arranged for the don't-care bits in the pointers to all be 0 when GC is not running and doesn't need the bits. If so, that could mitigate the TLB waste during periods when GC isn't running.

In other words, just because the alternate mappings exist doesn't mean the pointers always have values that actually use them.

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

#183

Earlier quoted context omitted.

1.2 TB Xmx (Java heap) here, reporting in from LinkedIn not fintech. Basically, graphs are hard to shard ... what if we didn't bother? You can query an in memory graph pretty quickly out into the 2nd or 3rd degree. Even G1 (untuned) only pauses for 250ms once every few minuets. It's not perfect but good enough to ignore.

250ms is atrocious for finance. Need a small handful of microseconds to not be noticed.

Of course. But this is with zero tuning in place. This is just what the default G1 gets you on that heap size. I'm sure with 2 or 3 flags we could bring that down easily. Given how infrequently we're seeing them (one every few minutes) it's fine for what we're doing.

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

#184

Earlier quoted context omitted.

That’s not much of an answer. If anything, it seems to me like Oracle is seeding more control to the community. I could be wrong though, I don’t follow this stuff as close as some.

Coming sometime this winter they will require a license to use java 9 and up. Below is a link for the downvoters and skeptics: https://www.aspera.com/en/blog/oracle-will-charge-for-java-s...

The first sentence from your link:

> Oracle has announced that, effective January 2019, Java SE 8 public updates will no longer be available for "Business, Commercial or Production use" without a commercial license.

Anything you can get now is still free and GPL open sourced. All they're doing is no longer publishing NEW CODE (in the form of backports and bug fixes) to the OpenJDK 8 branch. Instead they're publishing it to OracleJDK.

They're not trying to kill GPL anymore than Redhat is trying to Linux.

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

#186

Earlier quoted context omitted.

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.

Yeah, implementation is under way for value types; the project is called Valhalla - https://en.wikipedia.org/wiki/Project_Valhalla_(Java_languag...

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

#187

Earlier quoted context omitted.

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

You can do that, and people do. However a GC language doesn't normally give you the flexibility of getting a block of memory and doing whatever you want inside it, instead you use things like object pools.

You can allocate a block of memory with `ByteBuffer.allocate()` or, if you want it outside the JVM heap, `ByteBuffer.allocateDirect()`.

You lose all the object/memory management features, though there are some projects around to provide struct-like APIs: https://github.com/alaisi/nalloc

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

#188
An interesting fact is that the hotspot team went back on their 20-year conviction that load-barriers reduce performance too much. I guess improvements in CPU and VM designs has changed their minds.

This is a big deal, and a major departure.

I'm hoping this will improve things, this new architecture more closely resembles Azul's C4. Java and large heaps with non-conforming object allocation patterns (medium aged objects are the most troublesome) sucks really badly.

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

#189

Earlier quoted context omitted.

4TB uses 42 bits of address space. It leaves you with 22 bits, out of which ZGC uses 4. If anything, borrow a few more bits, and you should easily be able to address petabytes.

> 4TB uses 42 bits of address space. Can't you compress that into less than 42 bits?

No, compression only works when you don't need to represent every possibility, or can use less bytes for some inputs and more bytes for others.

https://en.wikipedia.org/wiki/Pigeonhole_principle#Uses_and_...

Post reply on HN