Probably good for running Java on your cruise missile.
Epsilon: The JDK’s Do-Nothing Garbage Collector
41–50 of 77 posts
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#42Earlier quoted context omitted.
But regular GCs DO run at the end of the program, so my question was, why don't they just skip the final cleanup.
> But regular GCs DO run at the end of the program Which GCs do that? I'm not aware of any.
The article (apparently falsely) claims that default JVM GC does that:
"Short-running programs, like all programs, invoke the garbage collector at the end of their run."
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#43Now 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…
Application startup time usually is dominated by class loading, JITs and actual application initialization code. GC overhead should be fairly small unless the heap is badly sized.
You might be able to shave off a few milliseconds by tuning the GC, but the lion's share is somewhere else.
You could try OpenJ9 for CLI tools which claims to offer faster startup times out of the box compared to openjdk. Tweaking the JIT behavior (number of compiler threads, compilation thresholds for the tiers etc.) or using CDS can help too.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#44Now 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, fo…
These days you can cut out most of that with jlink to trim down the jvm, and ClassDataSharing (CDS) and AppCDS. This post goes into it: https://blog.gilliard.lol/2017/10/04/AppCDS-and-Clojure.html
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#45Now 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…
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.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#46Now 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…
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.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#47Speaking 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 graph much much faster by virtue of needing to access far fewer memory pages, and increased likelihood that those pages will be in a fast cpu cache most of the time.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#48To 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.
Who would do that? Effective Java specifically says not to rely on finalizers.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#49Speaking 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.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#50Earlier quoted context omitted.
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?
The default GC's do already behave this way. They don't run GC on exit. Why on earth would they?