Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Epsilon: The JDK’s Do-Nothing Garbage Collector

blogs.oracle.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#71

Post by burtonator »

_lbaq wrote: post #14

JVM GC development has seen an upswing in the last few years, one of the most interesting new GCs are ZGC that show impressive numbers, delivers less than 10 ms pause times for any heap size, often than 1 ms for many applications, while having impressive throughput numbers. Another interesting adoption to the containerized world we live in is that GCs recently started to frequently return memory to the OS when not be…

> Another interesting adoption to the containerized world we live in is that GCs recently started to frequently return memory to the OS when not being used.

I'm wondering if there are any security implications here. Like a container could figure out the workload of another container probablistically. Thinking out loud here but sometimes these side channels are leaky.

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#72

Post by aidenn0 »

AndrewBissell wrote: post #53
dmitryminkovsky wrote: post #41

Probably good for running Java on your cruise missile.

Peter Lawrey said he had HFT clients who wrote Java and managed to get their object allocation so low that they never had a GC pause, and just waited until market close to restart the JVM.

A number of games written in managed runtimes will pre-allocate a large number of objects at the start of each level/zone, and hope they don't run out before the next level (where a GC can run).

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#73

Post by peterashford »

lightgreen wrote: post #65
kjeetgill wrote: post #57

Earlier quoted context omitted.

Don't forget Shenandoah headed by G1's lead Christine Flood! I don't know enough to compare it to ZGC but it's an exciting time in Java's GC lineup.

They promised low latency in G1, then they promised low latency in Shenandoah, now they promised it in ZGC. Okay. What JVM really really needs for performance is value types: a lot of GC problems will simply not exist with value types. Project Valhalla started five (!) years ago, and they are still working on it. JVM could also use multiple heaps per process (so multiple GCs could run independently not affecting othe…

G1 has low latency. And as someone who programs c# for a living: I DO NOT WANT value types.

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#74

Post by tom_mellior »

peterashford wrote: post #73
lightgreen wrote: post #65

Earlier quoted context omitted.

They promised low latency in G1, then they promised low latency in Shenandoah, now they promised it in ZGC. Okay. What JVM really really needs for performance is value types: a lot of GC problems will simply not exist with value types. Project Valhalla started five (!) years ago, and they are still working on it. JVM could also use multiple heaps per process (so multiple GCs could run independently not affecting othe…

G1 has low latency. And as someone who programs c# for a living: I DO NOT WANT value types.

Interesting, could you expand a bit? From what I have seem the proposal for Java seems useful.

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#75

Post by tom_mellior »

smaddox wrote: post #49
etaioinshrdlu wrote: post #47

Speaking of garbage collectors, I had a thought the other day, wondering if performance could have a huge linear speed up if the graph of object pointers was stored compactly in memory, separated from the rest of an application's memory. The object graph could be stored in a succinct compressed format to reduce it's size as much as possible, compared to actual 64 bit pointers. Then the GC algorithm could crawl the gr…

Luajit does something vaguely like this: http://wiki.luajit.org/New-Garbage-Collector#arenas_block-ma... It doesn't need to access the actual data when sweeping.

IIUC that only moves the mark bits out of the objects. It still has to access the objects while marking.

I think the parent proposed moving pointers out of the objects, so you wouldn't even have to touch the user's objects while marking.

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#76

Post by smarks »

shipilev wrote: post #39
mike_hock wrote: post #3

To address the short-running program issue, can't the regular GCs just not clean up on program exit?

The post misleads readers into thinking that JVM runs the GC before exit. It does not. When I was writing the Epsilon JEP, I meant that it might be futile to have a hundreds-of-ms-long GC cycle, when the program exits very soon anyway, and the heap would be abandoned wholesale. The important bit of trivia is that GC might be invoked long before 'the whole memory' is exhausted. There are several reasons to do this: le…

> The post misleads readers into thinking that JVM runs the GC before exit. It does not.

Yes, the article is incorrect about this. We’ll make sure it gets fixed.

These numbers are quite interesting. Thanks for doing this analysis!

Re: Epsilon: The JDK’s Do-Nothing Garbage Collector

#77

Post by peterashford »

tom_mellior wrote: post #74
peterashford wrote: post #73

Earlier quoted context omitted.

G1 has low latency. And as someone who programs c# for a living: I DO NOT WANT value types.

Interesting, could you expand a bit? From what I have seem the proposal for Java seems useful.

In the c# I dislike the extra mental load of having to work out which rules apply to the lexical thing I see being manipulated in the code. If I see references being assigned in Java I can tell that that's the case just by looking at the code. In c# I have to see the definition of the objects to tell what semantics are being expressed by the syntax. Likewise, with properties in c# a straightforward field assignment can be pretty much anything which means again, innocent looking code can be misleading and the only way to know is to read the definitions. Java is simpler to read and I value that.
Post reply on HN