showing memory used by a Java app in the app itself

[alexandre_paterson]

Hi,

some Java applications display the memory used by the
application itself.

This is the case, for example, in the IntelliJ IDEA IDE
(best Java app ever written in my opinion if I had to
choose one but that's another topic).

And surely enough if you change the heap settings by
(-Xmx et al. JVM parameters) this correctly reflect in
IntelliJ (e.g. it shows "100 M out of 256 M" used).

Note that I know how to use a profiler (I'm using
JProfiler) as well as how to obtain information about
the memory used from the OS point and view but this
is not the topic of my post: my question is not about
how/where to find memory leaks or how to use the OS
to see how much memory is used.

I really want to know how a Java program can obtain
memory usage information about itself.

Do I have to go into tricky reference counting and
approximating the size of all objects or are there
any convenient methods to call ?

I've tried to search the group's archive but didn't
find much (my Google-fu may not be very strong),

Alex

 

[alexandre_paterson]

On Feb 7, 7:29 am, (e-mail address removed) wrote:
....

This is the case, for example, in the IntelliJ IDEA IDE
(best Java app ever written in my opinion if I had to
choose one but that's another topic).

Responding to myself:

This is also the case for Eclipse, for example the plugin
called 'freemem' does exactly that too.

I'm not looking after how much memory is used by the OS but
about how much heap space (and what the max heap space is)
is currently used (and want to update that regularly), in
summary just like IntelliJ IDEA does and just like 'freemem'
does for Eclipse.

This is for a Java 1.6 application.

 

[Mark Space]

I really want to know how a Java program can obtain
memory usage information about itself.

java.lang.Runtime.freeMemory();
java.lang.Runtime.totalMemory();

<http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html>

 

[alexandre_paterson]

java.lang.Runtime.freeMemory();
java.lang.Runtime.totalMemory();

They're not static methods apparently but...

Excellent

My Google-fu certainly ain't very strong

Thank you for the quick answer,

Alex

 

[Lew]

They're not static methods apparently but...

Why does that matter? Do you need static methods? Would referencing the
Runtime instance cause you trouble?

 

[Daniel Pitts]

Why does that matter? Do you need static methods? Would referencing
the Runtime instance cause you trouble?

If you don't know how to get the runtime, it might

Without bothering to google it, I think it is easy System.getRuntime()
or Runtime.getRuntime(). Google will answer you.

 

[Lew]

If you don't know how to get the runtime, it might

Without bothering to google it, I think it is easy System.getRuntime()
or Runtime.getRuntime(). Google will answer you.

Actually, I found the Javadocs to be a virtually instantaneous source of the
relevant information.

I still want to know why the fact that the methods aren't static is a problem.
Why is that?

 

[Daniel Pitts]

Actually, I found the Javadocs to be a virtually instantaneous source of
the relevant information.

I still want to know why the fact that the methods aren't static is a
problem. Why is that?

Entry points are sometimes hard to find. You can't just use
"new Runtime().freeMemory();", you have to find the correct runtime
instance. Reading the docs will indeed imbue one with that information,
but that wasn't the point I was making.

 

[Lew]

Entry points are sometimes hard to find. You can't just use
"new Runtime().freeMemory();", you have to find the correct runtime
instance. Reading the docs will indeed imbue one with that information,
but that wasn't the point I was making.

But why are static methods a requirement for the OP?

 

[RedGrittyBrick]

But why are static methods a requirement for the OP?

Perhaps the OP's "They're not static methods apparently" was merely a
passing remark to the effect that Mark's
"java.lang.Runtime.freeMemory();" had the superficial appearance of a
static method whereas it is really an instance method.

Perhaps if Mark had written "Runtime.getRuntime().freeMemory()" the OP
wouldn't have commented? I must admit I often use the
Classname.methodname() shorthand to refer to instance methods, so I'm
not criticizing Mark, just hypothesising about the OP's remark.

 

[Daniele Futtorovic]

Perhaps the OP's "They're not static methods apparently" was merely a
passing remark to the effect that Mark's
"java.lang.Runtime.freeMemory();" had the superficial appearance of a
static method whereas it is really an instance method.

Perhaps if Mark had written "Runtime.getRuntime().freeMemory()" the
OP wouldn't have commented? I must admit I often use the
Classname.methodname() shorthand to refer to instance methods, so I'm
not criticizing Mark, just hypothesising about the OP's remark.

I usually use a number sign (#) prefix to denote instance members and a
dot prefix to denote class members. IIRC, I picked up that habit from
the Javadoc engine, which would interpret this notation that way.
Wouldn't this be a viable alternative?

 

[Lew]

Perhaps the OP's "They're not static methods apparently" was merely a
passing remark to the effect that Mark's
"java.lang.Runtime.freeMemory();" had the superficial appearance of a
static method whereas it is really an instance method.

Perhaps if Mark had written "Runtime.getRuntime().freeMemory()" the OP
wouldn't have commented? I must admit I often use the
Classname.methodname() shorthand to refer to instance methods, so I'm
not criticizing Mark, just hypothesising about the OP's remark.

Mark shouldn't be criticized - referring to the method from the class, as I
pointed out upthread, is a standard way to communicate about the Javadocs.
Since instances are meaningless in the context of documentation, it would be
improper to infer that a static method is intended.