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

61–70 of 77 posts

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

#61

Post by etaioinshrdlu »

kjeetgill wrote: post #59
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…

This is a really cool idea. Just spitballing, but I suspect the issue would be that you now lose the objects locality when reading/following/writing references in conjunction with data. The GC algorithm will be crawling much less than your program will hopefully so it might be a net loss. Just speculation!

Yes I agree. Perhaps the pointers should be stored twice in memory? With the updates to the compact graph being done asynchronously buffered by a shared lock-free queue? This is a mouthful and starting to sound like an obnoxious design.

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

#62

Post by z92 »

BLanen wrote: post #52

I think this article about Instagram turning off Python's garbage collecting is somewhat relevant and interesting: https://instagram-engineering.com/dismissing-python-garbage-...

Read it. It's still garbage collecting, but doing it through reference counting. There was an extra GC for circular reference collecting. That one was disabled as well as object freeing up before termination.

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

#63

Post by abecedarius »

etaioinshrdlu wrote: post #54
tom_mellior wrote: post #51

Earlier quoted context omitted.

How do you envision compressing the graph? One thing you can do, if you know that all your objects will live in one arena, and the maximum size of that arena is https://wiki.openjdk.java.net/display/HotSpot/CompressedOops

Yes storing them as just smaller integers is a main thing. Frequently referenced pointers could also be given an even shorter coding, kind of like entropy coding.

I thought about tackling this while visiting Recurse Center last year. My angle was that this could probably be most practical for a language like Erlang which comes closest to never mutating any runtime datastructure. (You might think of languages like Haskell first, but lazy evaluation cashes out to mutations in the implementation.) I seem to have misplaced my notes, or I'd link to them. Haven't gotten to trying to do this yet.

Someone at RC suggested using succinct data structures and I spent a little while studying them, but they seemed to me like they'd have more niche-y properties than a more obvious approach would.

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

#64

Post by ufo »

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.

The latest version of LuaJIT is still using the old GC. As far as I know the new GC design is in limbo, with no plan to implement it in the near future.

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

#65

Post by lightgreen »

kjeetgill wrote: post #57
_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…

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 other heap execution and GC). There were talks about it years ago, but nobody is working on it AFAIU.

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

#66

Post by kjeetgill »

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…

I always had good experiences with G1 generally.

ZGC and Shenandoah are Oracle and Redhat's respective projects with similar goals. I like the options and activies around GC all personally.

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

#67

Post by matheusmoreira »

pjc50 wrote: post #17

See also Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... - who quotes the story of a piece of embedded software which accepted leaking since it would be used in the runtime of a missile.

If the amount of memory needed can be calculated ahead of time, shouldn't it also be possible to allocate it statically?

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

#68

Post by CoolGuySteve »

emmericp wrote: post #15

Related: I ran some benchmarks for all GCs in OpenJDK 12 some time ago: https://github.com/ixy-languages/ixy-languages/blob/master/J... Epsilon tied on speed but lost to Shenandoah on latency because never freeing memory isn't ideal either, even if you never run out of memory.

Ya if you allocate/deallocate onto a stack, the most recently freed memory is more likely to be hot in the cache for the next allocation, reducing overall latency.

It’s something I do all the time in C++.

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

#69

Post by CoolGuySteve »

kjeetgill wrote: post #59
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…

This is a really cool idea. Just spitballing, but I suspect the issue would be that you now lose the objects locality when reading/following/writing references in conjunction with data. The GC algorithm will be crawling much less than your program will hopefully so it might be a net loss. Just speculation!

Presumably the compact representation would be hot in the cache all the time due to frequent access but it would take up otherwise available cache space.

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

#70

Post by fulafel »

jwhitlark wrote: post #46
fulafel wrote: post #45

Earlier quoted context omitted.

GC is not the bottleneck in Clojure startup time. There has been a fair bit written about it. You can use GraalVM to build fast startup Clojure binaries.

CDS and AppCDS, along with jlink, are also great for this.

The published AppCDS + Clojure results show a much smaller speedup and require a higher degree of customization int he build. Like 1.5s -> 0.5s for AppCDS+AOT vs 1.5s -> 0.005s for Graal. And you can just use the clj or leiningen native-image plugins/templates. The minuses of Graal include some compatibility snags and being an Oracle product.
Post reply on HN