In Java, there is a method called System.gc(), which calls the garbage collector (or rather, "suggests" to the JVM to run the GC).
Are there valid reasons to call this method? I'm thinking that it would be evident of bad software design.
3
closed as too broad by gnat, user40980, Bart van Ingen Schenau, Ampt, jwenting Aug 6 '14 at 7:07
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
-
1As its written, this question is rather poll-like and is getting answers that are two sentences long. Do you think you could modify it so that it encourages answers that are fully explained rather than "how about ${something else}"? – user40980 Aug 1 '14 at 21:03
-
@MichaelT Yes, I'll make an edit. – Ryan Aug 1 '14 at 21:08
8
How about a benchmarking suite? Rather than letting the GC run at any random time, you might want to make it run between sets of tests, to (possibly) create more consistent conditions for each set.
-
-
Could you elaborate on this? Do any benchmarking frameworks do this? How would it help? – user40980 Aug 1 '14 at 21:04
-
3Since it isn't guaranteed when the GC does its magic, how would this be reliable? It might make the GC run in the middle of your execution or it might not, but won't it impair the performance of your tests if you, say, have 5 tests which usually won't trigger a GC but now it gets executed twice because you call
System.gc()each time? I understand it's somewhat random in both situations but then I'd rather have it be random in the way I expect: after many tests there will be GC's; this could let me take that into account. – Jeroen Vannevel Aug 1 '14 at 21:14 -
@JeroenVannevel, the answers depend completely on the details of your JVM's implementation. I don't know if this "trick" will make test results more consistent on current, popular JVMs, but I have used it with a different programming language, and it did help. In any case, I am really just trying to show that there are special, rare situations where something like this might actually make sense, depending on how your JVM handles it. – Alex D Aug 2 '14 at 4:49
-
@JeroenVannevel - It's useful if you know the behavior of your particular JVM. The documentation is written for the lowest common denominator. And if you relied strictly on documentation, you'd have to assume that your JVM might not even have garbage collection. – kdgregory Aug 2 '14 at 12:42
6
What about a game where you want to control gc pauses. You could then call gc right before a level starts after assets are loaded.
answered Aug 1 '14 at 20:23
-
1This used to be a common Swing technique: you trigger GC when you're minimized. With compacting garbage collectors, this would reduce the number of heap pages that could be swapped to disk, and therefore improve restore time. – kdgregory Aug 2 '14 at 12:41
0
In general, there isn't a good reason to call System.gc(). Especially since the system might ignore it. But here are some plausible reasons.
- As mentioned, in a benchmark
- You just freed up a ton of large Objects and otherwise "things are quiet", the queues are empty, etc... Now is a good time to get the maintenance work done.
- You are about to allocate a ton of large Objects and otherwise "things are quiet".
- You are about to enter speed sensitive code where low latency is desired. Get the garbage collection "out of the way" now, before the climactic fight vs. the super-fast 28 Days Later Zombies in 3D and 4K resolution. :-)
