Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It has already been explained that calling <code>system.gc()</code> <em>may</em> do nothing, and that any code that "needs" the garbage collector to run is broken.</p> <p>However, the pragmatic reason that it is bad practice to call <code>System.gc()</code> is that it is inefficient. And in the worst case, it is <strong>horribly inefficient</strong>! Let me explain.</p> <p>A typical GC algorithm identifies garbage by traversing all non-garbage objects in the heap, and inferring that any object not visited must be garbage. From this, we can model the total work of a garbage collection consists of one part that is proportional to the amount of live data, and another part that is proportional to the amount of garbage; i.e. <code>work = (live * W1 + garbage * W2)</code>. </p> <p>Now suppose that you do the following in a single-threaded application.</p> <pre><code>System.gc(); System.gc(); </code></pre> <p>The first call will (we predict) do <code>(live * W1 + garbage * W2)</code> work, and get rid of the outstanding garbage.</p> <p>The second call will do <code>(live* W1 + 0 * W2)</code> work and reclaim nothing. In other words we have done <code>(live * W1)</code> work and <em>achieved absolutely nothing</em>.</p> <p>We can model the efficiency of the collector as the amount of work needed to collect a unit of garbage; i.e. <code>efficiency = (live * W1 + garbage * W2) / garbage</code>. So to make the GC as efficient as possible, we need to <em>maximize</em> the value of <code>garbage</code> when we run the GC; i.e. wait until the heap is full. (And also, make the heap as big as possible. But that is a separate topic.)</p> <p>If the application does not interfere (by calling <code>System.gc()</code>), the GC will wait until the heap is full before running, resulting in efficient collection of garbage<sup>1</sup>. But if the application forces the GC to run, the chances are that the heap won't be full, and the result will be that garbage is collected inefficiently. And the more often the application forces GC, the more inefficient the GC becomes.</p> <p>Note: the above explanation glosses over the fact that a typical modern GC partitions the heap into "spaces", the GC may dynamically expand the heap, the application's working set of non-garbage objects may vary and so on. Even so, the same basic principal applies across the board to all true garbage collectors<sup>2</sup>. It is inefficient to force the GC to run.</p> <hr> <p><sup>1 - This is how the "throughput" collector works. Concurrent collectors such as CMS and G1 use different criteria to decide when to start the garbage collector.</sup></p> <p><sup>2 - I'm also excluding memory managers that use reference counting exclusively, but no current Java implementation uses that approach ... for good reason.</sup></p>
    singulars
    1. This table or related slice is empty.
    1. POWhy is it bad practice to call System.gc()?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USStephen C
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 Good explanation. Note however that this reasoning only applies if you care about throughput. If you want to optimize latentcy at specific points, forcing GC may make sense. E.g. (hypothetically speaking) in a game you might want to avoid delays during levels, but you don't care about delays during level load. Then it would make sense to force GC after level load. It does decrease overall throughput, but that's not what you are optimizing.
      singulars
      1. PO
      1. USsleske
    2. CO@sleske - what you say is true. However, running the GC between levels is a band-aid solution ... and doesn't solve the latency problem if the levels take long enough that you need to run the GC during a level anyway. A better approach is to use a concurrent (low pause) garbage collector ... if the platform supports it.
      singulars
      1. PO
      1. USStephen C
    3. COmarvellous explanation...
      singulars
      1. PO
      1. USMudassir Hasan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload