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

51–60 of 77 posts

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

#51

Post by tom_mellior »

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…

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

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

#53

Post by AndrewBissell »

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.

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

#54

Post by etaioinshrdlu »

tom_mellior wrote: post #51
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…

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.

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

#55

Post by zbentley »

chrisseaton wrote: post #18
mike_hock wrote: post #3

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

Why do you need to clean up if your program is about to exit?

Memory might need to be cleaned up if the program was being run embedded in something else (it's not unheard of to embed JVMs inside e.g. C++ applications, and it's very common in scripting languages to do this).

Additionally, global destructors, while not guaranteed, can be very helpful if you let them run rather than just exiting and letting the system clean up file descriptors: for example, a clean disconnect from a database is often faster overall (on the database side, e.g. freeing up a connection slot) than a dirty "client hasn't phoned in for awhile/received unexpected FIN" disconnect via hard-exit.

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

#56

Post by chrisseaton »

zbentley wrote: post #55
chrisseaton wrote: post #18

Earlier quoted context omitted.

Why do you need to clean up if your program is about to exit?

Memory might need to be cleaned up if the program was being run embedded in something else (it's not unheard of to embed JVMs inside e.g. C++ applications, and it's very common in scripting languages to do this). Additionally, global destructors, while not guaranteed, can be very helpful if you let them run rather than just exiting and letting the system clean up file descriptors: for example, a clean disconnect from…

> Memory might need to be cleaned up if the program was being run embedded in something else

Just unmap the heap pages. Don't run the GC!

> global destructors, while not guaranteed, can be very helpful if you let them run

If you want them to run on exit then you want Runtime.runFinalizersOnExit, not the GC. Finalizers are non-deterministic, asynchronous, and would take an indefinite number of GC cycles to run them for all objects.

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

#57

Post by kjeetgill »

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

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

#58

Post by pron »

jelllyounf wrote: post #12
mike_hock wrote: post #3

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

Perhaps there may be objects that depend on the finalizer callback for correctnesss. I have seen people use finalizer to do things like close file handles, and presumably not calling close may not guarantee data is persisted.

Finalizers were deprecated two years ago, and might be removed altogether in the not-too-distant-future.

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

#59

Post by kjeetgill »

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!

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

#60

Post by kjeetgill »

chrisseaton wrote: post #50
mike_hock wrote: post #20

Earlier quoted context omitted.

Yes, my point is, why do you have to explicitly select the no-op GC for this purpose, when the default GC could already behave this way?

The default GC's do already behave this way. They don't run GC on exit. Why on earth would they?

I believe you are correct but it's worth pointing out that the post above is from an oracle blog and seems to suggest they do run on exit.
Post reply on HN