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?
Hence my question.
Epsilon: The JDK’s Do-Nothing Garbage Collector
21–30 of 77 posts
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#22Earlier quoted context omitted.
Why do you need to clean up if your program is about to exit?
Hence my question.
I still don't understand your question, sorry:
> can't the regular GCs just not clean up on program exit
Why do you need to clean up your memory - at all, GC or otherwise - on program exit? The process and all its resources will be gone.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#23To 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.
[deleted]
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#24Earlier quoted context omitted.
Hence my question.
I still don't understand your question, sorry: > can't the regular GCs just not clean up on program exit Why do you need to clean up your memory - at all, GC or otherwise - on program exit? The process and all its resources will be gone.
The question was rhetorical; you and OP are saying the same thing.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#25Earlier quoted context omitted.
Hence my question.
I still don't understand your question, sorry: > can't the regular GCs just not clean up on program exit Why do you need to clean up your memory - at all, GC or otherwise - on program exit? The process and all its resources will be gone.
I think the concern is those resources might be external and not cleaning up correctly leaves them in an inconsistent state. Not saying this is best practice but I've seen it done.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#26To 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...
Heh.
That script could probably have used POSIX::_exit() to get the same speedup without the calling process thinking it crashed.
uWSGI, a web application container for Python, Perl and other languages has an option for that:
--skip-atexit-teardown
- Unreferencing objects recursively, therefore tracing all objects.
- Calling destructor functions.
- Potentially doubling idle memory use due to copy-on-write as all the objects are written to.
When a web application server restarts all its child processes, the third item in particular can result in a large spike in memory use.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#27Related: 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.
It'd be interesting to see a version of that graph with just Episilon/Shenandoah. It's hard to tell but it looks like Epsilon may actually have lower average latency but Shenandoah may have lower jitter & max latency.
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#28Earlier quoted context omitted.
I still don't understand your question, sorry: > can't the regular GCs just not clean up on program exit Why do you need to clean up your memory - at all, GC or otherwise - on program exit? The process and all its resources will be gone.
I think the concern is those resources might be external and not cleaning up correctly leaves them in an inconsistent state. Not saying this is best practice but I've seen it done.
Finalisers are not guaranteed to be called by GC in theory, and in practice they run asynchronously even if they are going to be called, so aren't likely to be called if you GC and then exit.
So how does calling GC help with anything?
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#29To 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.
At least on unix systems, process termination implicitly calls close() on every file descriptor anyway. There should be no need to call it explicitly.
(You won't get the chance to log any write errors reported by close() or react to the errors, though.)
Re: Epsilon: The JDK’s Do-Nothing Garbage Collector
#30It'd be nice to have a per-thread mode for this.