Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You need to keep in mind that the Garbage Collector does a lot more than just collecting unreachable objects. It also optimizes the heap space and keeps track of <a href="http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf" rel="nofollow noreferrer"><em>exactly</em> where there is memory available</a> to allocate for the creation of new objects.</p> <p>Knowing immediately where there is free memory makes the allocation of new objects into the young generation efficient, and prevents the need to run back and forth to the underlying OS. The JIT compiler also optimizes such allocations away from the JVM layer, according to Sun's Jon Masamitsu:</p> <blockquote> <p>Fast-path allocation does not call into the JVM to allocate an object. The JIT compilers know how to allocate out of the young generation and code for an allocation is generated in-line for object allocation. The interpreter also knows how to do the allocation without making a call to the VM.</p> </blockquote> <p>Note that the JVM goes to great lengths to try to get large contiguous memory blocks as well, which likely have <a href="http://www.idiom.com/~zilla/Computer/javaCbenchmark.html" rel="nofollow noreferrer">their own performance benefits</a> (See "The Cost of Missing the Cache"). I imagine calls to <code>malloc</code> (or the alternatives) have a limited likelihood of providing contiguous memory across calls, but maybe I missed something there.</p> <p>Additionally, by maintaining the memory itself, the Garbage Collector can make allocation optimizations based on usage and access patterns. Now, I have no idea to what extent it does this, but given that there's a registered Sun <a href="http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&amp;Sect2=HITOFF&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=1&amp;f=G&amp;l=50&amp;d=PALL&amp;RefSrch=yes&amp;Query=PN%2F6799191" rel="nofollow noreferrer">patent for this concept</a>, I imagine they've done something with it.</p> <p>Keeping these memory blocks allocated also provides a safeguard for the Java program. Since the garbage collection is hidden from the programmer, they can't tell the JVM "No, keep that memory; I'm done with these objects, but I'll need the space for new ones." By keeping the memory, the GC doesn't risk giving up memory it won't be able to get back. Naturally, you can always get an <code>OutOfMemoryException</code> either way, but it seems more reasonable not to needlessly give memory back to the operating system every time you're done with an object, since you already went to the trouble to get it for yourself.</p> <p>All of that aside, I'll try to directly address a few of your comments:</p> <blockquote> <p>Often, they consume more and more memory over runtime.</p> </blockquote> <p>Assuming that this isn't just what the program is doing (for whatever reason, maybe it has a leak, maybe it has to keep track of an increasing amount of data), I imagine that it has to do with the free hash space ratio defaults set by the (Sun/Oracle) JVM. The default value for <code>-XX:MinHeapFreeRatio</code> is 40%, while <code>-XX:MaxHeapFreeRatio</code> is 70%. This means that any time there is only 40% of the heap space remaining, the heap will be resized by claiming more memory from the operating system (provided that this won't exceed <code>-Xmx</code>). Conversely, it will only* free heap memory back to the operating system if the free space exceeds 70%.</p> <p>Consider what happens if I run a memory-intensive operation in Eclipse; profiling, for example. My memory consumption will shoot up, resizing the heap (likely multiple times) along the way. Once I'm done, the memory requirement falls back down, but it likely won't drop so far that 70% of the heap is free. That means that there's now a lot of underutilized space allocated that the JVM has no intention of releasing. This is a major drawback, but you might be able to work around it by customizing the percentages to your situation. To get a better picture of this, you really should profile your application so you can see the utilized versus allocated heap space. I personally use <a href="http://www.yourkit.com/" rel="nofollow noreferrer">YourKit</a>, but there are many good alternatives to choose from. </p> <p><sub>*I don't know if this is actually the <em>only</em> time and how this is observed from the perspective of the OS, but <a href="http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html" rel="nofollow noreferrer">the documentation says</a> it's the "maximum percentage of heap free after GC to <strong>avoid shrinking</strong>," which seems to suggest that.</sub></p> <blockquote> <p>Even some very small sample demo applications load huge amounts of memory.</p> </blockquote> <p>I guess this depends on what kind of applications they are. I feel that Java GUI applications run memory-heavy, but I don't have any evidence one way or another. Did you have a specific example that we could look at?</p> <blockquote> <p>But why is it needed to load the library for each Java instance?</p> </blockquote> <p>Well, how would you handle loading multiple Java applications if not creating new JVM processes? The isolation of the processes is a good thing, which means independent loading. I don't think that's so uncommon for processes in general, though.</p> <p>As a final note, the slow start times you asked about in another question likely come from several intial heap reallocations necessary to get to the baseline application memory requirement (due to <code>-Xms</code> and <code>-XX:MinHeapFreeRatio</code>), depending what the default values are with your JVM.</p>
    singulars
    1. This table or related slice is empty.
    1. POJava: why does it uses a fixed amount of memory? or how does it manage the memory?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USTim Stone
    1. USTim Stone
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POJava: why does it uses a fixed amount of memory? or how does it manage the memory?
      singulars
      1. PTQuestion
    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. This table or related slice is empty.
 

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