Is it ever necessary to call the garbage collector

[Zach Rode]

I know it isn't recommended anymore to call System.gc(), but are there situations where it might be beneficial?

-Zach

[Pete Letkeman]

In the event that you call System.gc() Java may still ignore your request and/or may not free up the memory which you want it to.
When the system does actually execute System.gc() it may or may not run the finalize method on objects which are out of scope.
However finalize is on it's way to be deprecated in Java versions greater then Java 8.

You cannot guarantee that System.gc() will do anything so it may not produce reliable results.
By that I mean it may free up different amounts of memory when it's executed.

Given all of this I do not think it would be beneficial to use it.

[Campbell Ritchie]

No.

If you want to see memory consumption before and after GC.
Well, maybe if you are about to open a file containing 10⁷ records and you are going to put them into objects and put those objects into a List and you are doing this after clicking the “Load from File” button and you are waiting for APPROVE_OPTION from your JFileChooser, so there will be several seconds when the EDT is inactive . . . .
In other circumstances, it is done automatically, so what't the point?

[Zach Rode]

I figured there was no use for it, but many things in Java appear useless to a novice while being useful in the hands of an expert.

Thank you!

[Campbell Ritchie]

That's a pleasure

[Wyatt Armstrong]

Nope.

[Campbell Ritchie]

Welcome to the Ranch

Surely in your signature you would take 3 minutes not to talk about Vim and the rest of the day to talk about it

[Tim Holloway]

Using gc to get a better idea of how much active object memory you are using is a popular thing to do.

In older times, especially in real-time applications, it was sometimes useful to call gc before starting something resource-heavy. Otherwise the user experience could be marred when an automatical gc started in the middle of things and stalled the UI.

A classic example of this was one of the early Amiga Computer demos where it opened 4 windows, each with a moving graphic in them and played music in stereo*. The Amiga was the first home-grade computer with real-time pre-emptive multitasking capabilities straight from the factory. In fact, although Linux has always had pre-emptive multi-tasking, you had to do a custom kernel build if you wanted real-time and that was over a decade later.

But real-time and ore-emptive are no match for a quick-and-dirty port of BASIC that had a blocking garbage collector, so right in the middle of the demo, it would periodically stall - while playing music - to do garbage collection.

This isn't as much of a problem with the smarter and more incremental gc processes in modern Java, but you can see why people got into the habit.

===
The Amiga was probably the only computer whose on-the-box specifications contained not only RAM and CPU speed, but stereo separation in decibels and Total Harmonic Distortion. Even today, many PCs use a separate sound card. And even when it's on the motherboard, the sound chips used depend on the motherboard manufacturer.

[Zach Rode]

Tim Holloway wrote:Using gc to get a better idea of how much active object memory you are using is a popular thing to do.

In older times, especially in real-time applications, it was sometimes useful to call gc before starting something resource-heavy. Otherwise the user experience could be marred when an automatical gc started in the middle of things and stalled the UI.

A classic example of this was one of the early Amiga Computer demos where it opened 4 windows, each with a moving graphic in them and played music in stereo*. The Amiga was the first home-grade computer with real-time pre-emptive multitasking capabilities straight from the factory. In fact, although Linux has always had pre-emptive multi-tasking, you had to do a custom kernel build if you wanted real-time and that was over a decade later.

But real-time and ore-emptive are no match for a quick-and-dirty port of BASIC that had a blocking garbage collector, so right in the middle of the demo, it would periodically stall - while playing music - to do garbage collection.

This isn't as much of a problem with the smarter and more incremental gc processes in modern Java, but you can see why people got into the habit.

===
The Amiga was probably the only computer whose on-the-box specifications contained not only RAM and CPU speed, but stereo separation in decibels and Total Harmonic Distortion. Even today, many PCs use a separate sound card. And even when it's on the motherboard, the sound chips used depend on the motherboard manufacturer.

So BASIC had automatic garbage collection too? I wonder why they didn't implement it as an option in C++

[Campbell Ritchie]

C++ is only an upgrade of C, which is intended for low‑level work, so I wouldn't expect it to have a GC utility. Sounds a nice idea, though.

[Tim Holloway]

Campbell Ritchie wrote:C++ is only an upgrade of C, which is intended for low‑level work, so I wouldn't expect it to have a GC utility. Sounds a nice idea, though.

C++ doesn't deal with "orphaned" objects the way Java does. It has explicit construction and destruction. Heap memory has been managed even before C++ came out to improve C++, but there are some serious constraints on compaction, since C/C++ objects are referenced via pointers to absolute memory addresses.

Solutions to the problem have been made many times (I did a few myself, including a String pool object). And Apple dodged the pointer problem by allocating "handles", which are pointers to the pointers to the objects, so that if the actual object needs to be relocated, only the single handle pointer needs to be changed instead of making the app programmer chase down and update individual pointer variables. But by and large, C and C++ left you to work out your own solutions.

Over the years, some more-or-less standard C++ libraries (some with memory management) have become popular to address the fact that the original C and C++ language environments were so spartan, but it's not nearly as tidy as Java or Python in that regard.