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

221–230 of 245 posts

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

#221

Post by repolfx »

ryanobjc wrote: post #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 obje…

They do reduce performance a lot. I think what changed is there are now classes of customers who are willing to take a huge performance hit for reliably low pause times or reliably huge heaps. Whereas in the past heaps were smaller and perhaps latency tails were something people cared about less.

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

#222

Post by repolfx »

Sir_Cmpwn wrote: post #89
geezerjay wrote: post #73

Earlier quoted context omitted.

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

Google basically won that, didn't they? Despite cloning another companies technology from scratch without paying any kind of licensing fees at all.

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

#223

Post by [deleted] »

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/…

[deleted]

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

#224

Post by lylecubed »

danShumway wrote: post #215
jblow wrote: post #207

Earlier quoted context omitted.

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!…

> That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. This is a good point. I've spent a fair amount of time trying to build performant stuff on the web, and my conclusion has been that if you really care about memory management, garbage collection is not your friend. You spend more time than is necessary trying to convince the engine not to a…

> I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself.

Do you have any good references you can share regarding Chrome's garbage collection? This is a topic I would like to learn more about.

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

#225

Post by danShumway »

lylecubed wrote: post #224
danShumway wrote: post #215

Earlier quoted context omitted.

> That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. This is a good point. I've spent a fair amount of time trying to build performant stuff on the web, and my conclusion has been that if you really care about memory management, garbage collection is not your friend. You spend more time than is necessary trying to convince the engine not to a…

> I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself. Do you have any good references you can share regarding Chrome's garbage collection? This is a topic I would like to learn more about.

Unfortunately not - there are probably good resources out there, but most of what I know has come out of manual profiling in Chrome, different experiments, and the occasional StackOverflow post that explains a weird behavior or two.

At some point in the future I will probably write a blog post about good techniques for taking back control of JS memory management from the browser, but it probably won't be for a while.

The short answer though is that browsers try to defer garbage collection until it looks like the page isn't doing much; and the problem is that games don't ever really stop doing stuff. This encourages the browser to put off garbage collection and handle it in chunks, which in turn leads to dropped frames because you're doing a lot of deallocation at once.

This is why if you profile a Chrome app that's doing a lot of allocations very quickly, your memory usage will kind of sawtooth all over the place. And you get around that by getting rid of as many allocations as possible.

IMO the lack of garbage collection in WASM is the most exciting thing about it, but different languages have different tradeoffs and WASM isn't appropriate for every application.

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

#226

Post by openasocket »

I'm not entirely sure what the point of the multi-mapping is. It says that it means you don't have to do any pointer bitmasking to dereference, but you already have load barriers, which have to at least check to see what phase you are in and possibly do work every time you dereference a pointer, so how much extra latency would doing the bitmask really add? And the problem with the multi-mapping is you will be resolving more virtual addresses, increasing the working set for the TLB. Seems like there could be increased TLB thrashing.

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

#227

Post by jjnoakes »

cryptonector wrote: post #213
gravypod wrote: post #206

Earlier quoted context omitted.

This sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed. Also has it really been a decade since Braid? Wow.

Wait, why have a GC if you're going to work around it and end up with manual memory management anyways?

So that when you make a mistake, instead of random memory corruption, you get a leak or a slower GC cycle.

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

#228

Post by divan »

kalleboo wrote: post #211
sdinsn wrote: post #153

Earlier quoted context omitted.

He's just trying to bash Java. HN readers hate Java for some reason.

Everyone I know in tech hates Java. They've all had to suffer through terrible poorly-performing Java desktop apps (or worse, applets) which has tainted the image of the language for a generation.

Not supporting bashing language in this thread, but this was a reason I never wanted to develop in Java. This terrible desktop experience created a notable bias towards Java, and only later I learned that it's not that slow for networking services (but it was too late).

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

#229

Post by phakding »

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.

It's not either/or. Everything needs to be tuned to achieve the final latency requirements. This includes tuning java code to eliminate creating "garbage", immutable string objects mostly, unnecessary object creation, creating short lived objects compared to long lived etc. The other part right sizing jvm generational partitions, using right gc algo etc. Next part would be to find out the code path with lowest latency requirement and making it hot/jitting. Even next part would be to tune OS for things like thread pinning etc etc. You can go further and tune the network layer. Every little thing counts.

You can go even further and employ what's called mechanical sympathy (https://mechanical-sympathy.blogspot.com/) and write your code in a way that makes it easier for the processor to process faster.

I've never worked with application that use off-heap allocations or no-gc requirements.

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

#230

Post by pjmlp »

jblow wrote: post #207
gravypod wrote: post #206

Earlier quoted context omitted.

This sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed. Also has it really been a decade since Braid? Wow.

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!…

Although I would argue that in games, memory safety is the door to game cheats, bots and piracy.
Post reply on HN