Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Garbage collection

Reply
Thread Tools

Garbage collection

 
 
Crouchez
Guest
Posts: n/a
 
      01-25-2008
When exactly does it run? Is it a scheduled thing or when memory hits a
certain point? And what effect does manually calling System.gc() have on the
process?


 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      01-25-2008
Crouchez <(E-Mail Removed)> wrote:
> When exactly does it run? Is it a scheduled thing or when memory hits a
> certain point? And what effect does manually calling System.gc() have on the
> process?


You can consider the GC a friend of yours:
You can tell him: now, and now, and then again now is a
good time to clean up, but he's neither obliged to do
so every time, nor obliged to wait until your next hint.
Casually he will say: well, I wouldn't have done it right
now, but if you think ... - That's why System.gc() even
exists.

Situations, where "minding GC's business" was really
necessary are rare, but still existing.

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-25-2008
Crouchez wrote:
> When exactly does it run? Is it a scheduled thing or when memory hits a
> certain point? And what effect does manually calling System.gc() have on the
> process?


Different JVM's have different policies about when and how
to carry out garbage collection. So the answer to "exactly
when" is "whenever it likes," and the answer to "is it scheduled
or is it triggered" is "yes." All you can truly rely on is that
the JVM will not throw OutOfMemoryError without attempting a
garbage collection first.

System.gc() does what its Javadoc says: It "suggests" that
the JVM collect some garbage, and the JVM will make a "best
effort" to do so before the method returns. However, there's no
precise definition of what a "best effort" is: If the JVM decides
that a garbage collection would be inconvenient at the moment,
its "best effort" might amount to ignoring the "suggestion."

The prevailing wisdom is that System.gc() is very seldom a
good idea, particularly in code that is expected to run on a
variety of different JVM implementations with different garbage
collectors. In limited circumstances when the code is running on
one well-researched version of one specific JVM it may make sense,
but that's about it. Calling System.gc() is, in essence, making
a static decision based on predicted conditions instead of letting
the JVM make a dynamic decision based on actual conditions. You
may be smarter than the JVM, but the JVM has much more information
than you do.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      01-25-2008
Eric Sosman wrote :
> The prevailing wisdom is that System.gc() is very seldom a
> good idea, particularly in code that is expected to run on a
> variety of different JVM implementations with different garbage
> collectors. In limited circumstances when the code is running on
> one well-researched version of one specific JVM it may make sense,
> but that's about it. Calling System.gc() is, in essence, making
> a static decision based on predicted conditions instead of letting
> the JVM make a dynamic decision based on actual conditions. You
> may be smarter than the JVM, but the JVM has much more information
> than you do.


True, though I have code which does call it. The code manipulates
images in a Web server environment. Image processing takes a LOT of
memory, so I put in a counter which which calls System.gc() every ten
runs. That way the user doing the tenth manipulation takes the
(possible) time hit.

--
Wojtek


 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-25-2008
Eric Sosman wrote:

>
> The prevailing wisdom is that System.gc() is very seldom a
> good idea, particularly in code that is expected to run on a
> variety of different JVM implementations with different garbage
> collectors. In limited circumstances when the code is running on
> one well-researched version of one specific JVM it may make sense,
> but that's about it. Calling System.gc() is, in essence, making
> a static decision based on predicted conditions instead of letting
> the JVM make a dynamic decision based on actual conditions. You
> may be smarter than the JVM, but the JVM has much more information
> than you do.


As always, there are exceptions. Say you have a program that:

1. Interacts with the user
2. When asked to, runs some time and memory-intensive processing
3. Interacts with the user some more

It makes sense to call System.gc() at the end of step 2, so that the
time required for the GC doesn't interrupt the user interaction.


 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      01-25-2008
On Fri, 25 Jan 2008 15:45:08 GMT, "Crouchez" <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>When exactly does it run? Is it a scheduled thing or when memory hits a
>certain point? And what effect does manually calling System.gc() have on the
>process?


see http://mindprod.com/jgloss/garbagecollection.html
--
Roedy Green, Canadian Mind Products
The Java Glossary, http://mindprod.com
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-25-2008
Mike Schilling wrote:
> Eric Sosman wrote:
>
>> The prevailing wisdom is that System.gc() is very seldom a
>> good idea, particularly in code that is expected to run on a
>> variety of different JVM implementations with different garbage
>> collectors. In limited circumstances when the code is running on
>> one well-researched version of one specific JVM it may make sense,
>> but that's about it. Calling System.gc() is, in essence, making
>> a static decision based on predicted conditions instead of letting
>> the JVM make a dynamic decision based on actual conditions. You
>> may be smarter than the JVM, but the JVM has much more information
>> than you do.

>
> As always, there are exceptions. Say you have a program that:
>
> 1. Interacts with the user
> 2. When asked to, runs some time and memory-intensive processing
> 3. Interacts with the user some more
>
> It makes sense to call System.gc() at the end of step 2, so that the
> time required for the GC doesn't interrupt the user interaction.


Note that I wrote "very seldom," not "never."

You, I think, should have written "may make sense" instead
of "makes sense." The fact that Step 2 is time-intensive is
irrelevant, and the fact that it is memory-intensive matters
only if (1) a lot of garbage has accumulated and (2) a collection
is imminent anyhow. Both (1) and (2) are difficult or impossible
to know at coding time, when you're deciding whether to call
System.gc() or not. Also, if the first thing the user does in
Step 3 is click the "Quit" button, the time spent on anticipatory
GC is very likely wasted.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Crouchez
Guest
Posts: n/a
 
      01-25-2008
So it varies depending on what type of VM you're using?


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      01-25-2008
Crouchez wrote:
> So it [GC schedule] varies depending on what type of VM you're using?


It varies depending on the type of VM, on the options applied to the VM (all
commercial VMs have a host of GC-tuning options), and on the run-time profile
of the code running in the VM.

--
Lew
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      01-26-2008
Eric Sosman wrote:
> Mike Schilling wrote:
>> Eric Sosman wrote:
>>
>>> The prevailing wisdom is that System.gc() is very seldom a
>>> good idea, particularly in code that is expected to run on a
>>> variety of different JVM implementations with different garbage
>>> collectors. In limited circumstances when the code is running on
>>> one well-researched version of one specific JVM it may make sense,
>>> but that's about it. Calling System.gc() is, in essence, making
>>> a static decision based on predicted conditions instead of letting
>>> the JVM make a dynamic decision based on actual conditions. You
>>> may be smarter than the JVM, but the JVM has much more information
>>> than you do.

>>
>> As always, there are exceptions. Say you have a program that:
>>
>> 1. Interacts with the user
>> 2. When asked to, runs some time and memory-intensive processing
>> 3. Interacts with the user some more
>>
>> It makes sense to call System.gc() at the end of step 2, so that
>> the
>> time required for the GC doesn't interrupt the user interaction.

>
> Note that I wrote "very seldom," not "never."
>
> You, I think, should have written "may make sense" instead
> of "makes sense." The fact that Step 2 is time-intensive is
> irrelevant,


Not at all. If the user is already expecting to wait for the
processing to complete, the added wait for GC becomes invisible, which
is the point.

> and the fact that it is memory-intensive matters
> only if (1) a lot of garbage has accumulated and (2) a collection
> is imminent anyhow.


The point is that, the wait at the end of 2 being invisible to the
user, it's worth doint to avoid a visible wait later. An insurance
premium, if you like.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Collection problems (create Collection object, add data to collection, bind collection to datagrid) Řyvind Isaksen ASP .Net 1 05-18-2007 09:24 AM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM
Garbage Collection kamran MCSD 1 04-04-2005 10:04 PM
Garbage Collection and Manage Code? Laser Lu ASP .Net 5 01-27-2004 03:48 AM
Debbugging help! (.NET 1.1 Framework Garbage Collection Problems) Cheung, Jeffrey Jing-Yen ASP .Net 3 07-10-2003 07:29 PM



Advertisments