What Are Runtime.Getruntime().Totalmemory() and Freememory()

What are Runtime.getRuntime().totalMemory() and freeMemory()?

According to the API

totalMemory()

Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.
Note that the amount of memory required to hold an object of any given type may be implementation-dependent.

maxMemory()

Returns the maximum amount of memory that the Java virtual machine will attempt to use. If there is no inherent limit then the value Long.MAX_VALUE will be returned.

freeMemory()

Returns the amount of free memory in the Java Virtual Machine. Calling the gc method may result in increasing the value returned by freeMemory.

In reference to your question, maxMemory() returns the -Xmx value.

You may be wondering why there is a totalMemory() AND a maxMemory(). The answer is that the JVM allocates memory lazily. Lets say you start your Java process as such:

java -Xms64m -Xmx1024m Foo

Your process starts with 64mb of memory, and if and when it needs more (up to 1024m), it will allocate memory. totalMemory() corresponds to the amount of memory currently available to the JVM for Foo. If the JVM needs more memory, it will lazily allocate it up to the maximum memory. If you run with -Xms1024m -Xmx1024m, the value you get from totalMemory() and maxMemory() will be equal.

Also, if you want to accurately calculate the amount of used memory, you do so with the following calculation :

final long usedMem = totalMemory() - freeMemory();

Confusing results on using Runtime.getRuntime().totalMemory() and freeMemory() to calculate memory?

I guess this is because the JAVA JVM does not collect garbage in time, so the first result are more convicing. Am I right?

I don't think so. Running System.gc() is supposed to be a hint to make "best effort" to collect all garbage. Right now. The hint can be ignored, but if the GC does run, you would expect it to do a >>full<< collection, and only return when that had completed. There should be no question of the GC "keeping up".

If not, can someone provide some clues or other suggestions?

It could be due to JIT compilation and other JVM warmup effects.

When your application starts, your code's methods and all of the library methods that are used (transitively) are bytecodes, and will be interpreted by the bytecode interpreter. As the bytecodes are interpreted, the JVM gathers stats on various things (e.g. to assist branch prediction). Eventually, it decides to JIT compile the methods.

So how does this relate to your observation?

1. The stats are stored in the heap, and will be reachable ... until the JIT compiler "consumes" them.

2. The JIT compiler runs asynchronously, and when it is running it will also be using heap space to hold its data structures.

3. At startup, the JVM has to load classes, and this also consumes heap space to hold temporary objects.

4. The heap size is not constant. It will grow (and sometimes shrink) depending on how much free space is available after each GC cycle.

All of these combine to give local "highs" and "lows" in heap sizes and heap space usage, during the JVM warmup phase.

Difference between freeMemory() and totalMemory()

freeMemory() says for future, and totalMemory() says for current and future.

Literally, freeMemory() tells the memory for new allocating objects and totalMemory() tells the total memory (memory already allocated + free memory)

When to use Runtime.maxMemory() and totalMemory()

The totalMemory() returns how much memory is currently used, while the maxMemory() tells how much the JVM can allocate in total.

Note: that from this follows: totalMemory() <= maxMemory(), and you can also get 'how much memory is left' by maxMemory() - totalMemory()

One use case for this is to diagnose how much memory your program uses, and you'll use totalMemory() for it.

Note: both are referring only to heap memory, and not stack memory.

Runime.getRuntime().totalMemory() and ActivityManager.MemoryInfo()

Runtime.getRuntime().totalMemory() is

Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.

memInfo.totalMem is

The total memory accessible by the kernel. This is basically the RAM size of the device, not including below-kernel fixed allocations like DMA buffers, RAM for the baseband CPU, etc.

Note that the amount of memory required to hold an object of any given type may be implementation-dependent.

• The first one is the memory the jvm running your process holds, about 12 MB.
• The second one is the total kernel accessible system memory, about one gigabyte in your case.

The first is part of the second.

Why does Runtime.freeMemory() show more memory after constructing an object?

The currently allocated memory is the difference

Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()

Allocating an object, especially a large one, may require the JVM to obtain additional memory from the operating system. That is a relatively expensive operation, so it is more efficient for the JVM to request memory in large chunks. When it obtains more memory than the current allocation requires, both total memory and free memory will increase.

Java - Runtime.freeMemory()

I know it is not the answer you wanted - but according to the JavaDoc - freeMemory returns:

an approximation to the total amount
of memory currently available for
future allocated objects, measured in
bytes.

Just to test it - I took your code and ran twice. Once with the array size set to 10,000 - and once with 100.
I also added another print just after:

Integer intArr[]= new Integer[10000];

When running with 10,000 - I got the expected result, a decrease of 40,0016 bytes in free memory just after the array instantiation.

When running with 100 I got the exact same amount of free memory before and after array instantiation - not the desired effect.

As most answers already stated - as it is a native method - is JVM dependent and therefore can act differently on any platform.
I'm running on Windows 7 with the Eclipse built-in JVM (v3.6).

But I think the key word here is - approximation.

---

Related Topics