JVM Data:
One of the important pieces of information required for any
monitoring tools is the operating system information and the
extent to which these operating system resources are used by the
JVM. This becomes tricky as Java applications run on a variety
of platforms and operating systems. Some of the mandatory
operating system information required by monitoring applications
is the operating system name, version and arch. Other JVM
specific information that is mandatory is the VM name, version,
vendor, specification version, specification name, Java class
path, Java library path, etc. The specification proposes that
the monitoring model use as much information as the operating
system can provide and then it will add the platform specific
extensions to get the other kinds of information required for
monitoring.
Apart from information from the JVM itself another source of
monitoring data is the components within an application.
Individual components can provide valuable information on
threads, CPU utilization time, JIT compilation time, deadlock
information etc. Information about these individual components
may be difficult and expensive to retrieve, as these components
may have varied implementations. Since these components usually
run as separate threads on the JVM, data about these threads
could be a good indicator of the performance of these
components. Monitoring agents would require thread information
like total number of threads created since the JVM started,
current number of live threads, peak number of live threads,
number of daemon threads, etc. Added to this is, specific
information about the individual threads that can be used to
know more about the application. Data like, Thread identifiers,
thread state, the monitor the thread is blocked on, the thread
that blocks the monitor, total number of contentions, and the
thread stack trace can be used to identify deadlocks and thereby
improve performance.
One of the most important indicators of the health of the system
is the memory usage. The JVM contains three memory pools and two
memory managers to help in monitoring. One pool is for object
allocation managed by a mark and sweep compact collector. The
second one is for method area which is also managed by a mark
and sweep compact collector. The third one is for native
compiled code managed by a malloc/free manager. The first pool
belongs to the heap memory and the rest of them belong to the
non heap memory. The heap memory is a runtime data heap used by
the JVM to store class instances and array objects. The memory
in the heap is subject to automatic garbage collection by the
garbage collector. The heap memory is defined by the JVM
specification and will be uniform across multiple
implementations of the JVM. However JVMs can use non heap memory
to store data other than those stored in the heap. These can be
runtime field and method data. Some JVM implementations can
allocate resources on to the non heap memory to improve
performance. These allocations are not specifically prohibited
by the JVM specification.
For the JVM the memory pools and memory managers are abstract
entities. The JVM would at least have one memory pool and it can
create or remove additional pools at runtime. In the same way
the JVM can have one or more memory mangers and it has the
ability to add or remove new memory mangers at runtime. The JVM
can gather data about these memory pools and memory mangers and
pass it on to the monitoring tool for analysis. Some of the
information that the monitoring tool requires from the memory
pool are the list of memory pools, size of the pool when it was
initialized, size used, the size that is guaranteed by the JVM,
and/or the maximum size of the pool. The memory manger should
provide information of the name of the manager and the details
of all the pools managed by the memory manager. Heap attributes
required by the monitoring tools are the initial memory
allocated on the heap, memory already used, maximum memory the
JVM can use on the heap and more.
API Requirements:
The API will have the ability to be used in a production
environment with minimal intrusion. It will have access to all
the mandatory data and the optional data discussed in the above
section. The API will have on demand monitoring capability and
will be pluggable without a restart of the system. The interface
shall support multiple threads. The API shall provide the above
mentioned facilities using JMX Mbeans. The API shall be
extensible so that platform specific support can be provided.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
