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

11–20 of 77 posts

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

#11

Post by wiradikusuma »

capableweb wrote: post #2

Now I'm no Java expert, far from it, so would appreciate any answers to this. I'm interacting with bunch of CLIs that are either in Java or using the JVM otherwise (Clojure mostly), how much of the startup time for this things can be attributed to the GC? It's mentioned in the article that short-running programs (almost all CLIs I use) could use Epsilon since the heap is cleared on exit anyways. But wondering how muc…

If you have access to the source code, you can try to recompile it with Graal Native and make it, well, native executable. It will shave off the load times considerably. But if you have a dozen of them, each of them will have their own JRE embedded so you'll waste disk space

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

#12

Post by jelllyounf »

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.

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

#13

Post by fhars »

mike_hock wrote: post #3

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

I do remember some perl scripts where I would send a SIGKILL to itself as the last instruction. Cut the total runtime of the script almost in half...

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

#14

Post by _lbaq »

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

If you want to read more about these new GCs, this is a great post: https://blog.plan99.net/modern-garbage-collection-part-2-1c8...

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

#15

Post by emmericp »

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.

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

#16

Post by dmos62 »

capableweb wrote: post #2

Now I'm no Java expert, far from it, so would appreciate any answers to this. I'm interacting with bunch of CLIs that are either in Java or using the JVM otherwise (Clojure mostly), how much of the startup time for this things can be attributed to the GC? It's mentioned in the article that short-running programs (almost all CLIs I use) could use Epsilon since the heap is cleared on exit anyways. But wondering how muc…

I was working with Clojure a lot some years back, and I'm sure there's been a lot of progress in the ecosystem since then. However, what I learned then was that Clojure had an inherent startup overhead, because it had to get the language itself ready. The reason why you don't see this with for example Scala, which also runs on JVM, is because Clojure is very dynamic, as far as JVM languages go. Compare it to Java, for which the JVM was designed. These dynamic qualities come in part at the cost of the startup time.

I was especially frustrated by this, because I had spent some time writting a Clojure program that had to be able to cold-start fast. Decompiling the program's JAR and pruning out unnecessary classes gave a considerable speed-up, but it was not enough.

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

#19

Post by kasperni »

capableweb wrote: post #2

Now I'm no Java expert, far from it, so would appreciate any answers to this. I'm interacting with bunch of CLIs that are either in Java or using the JVM otherwise (Clojure mostly), how much of the startup time for this things can be attributed to the GC? It's mentioned in the article that short-running programs (almost all CLIs I use) could use Epsilon since the heap is cleared on exit anyways. But wondering how muc…

I think the overhead of GC is negligible for many small programs. Claes Redestad @ Oracle gives a good overview here. https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...

I would look into GraalVM native images if you want fast startup.

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

#20

Post by mike_hock »

capableweb wrote: post #7
mike_hock wrote: post #3

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

It's not a issue? It's one of the cases where it does make sense to use Epsilon as the heap is cleared anyway on program exit. From the post: > There is a strong temptation to use Epsilon on deployed programs, rather than to confine it to performance tuning work. As a rule, the Java team discourages this use, with two exceptions. Short-running programs, like all programs, invoke the garbage collector at the end of th…

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?
Post reply on HN