Java JVM architecture

[Andrew Cowie]

On Fri, 2012-09-07 at 15:03 -0400, William Muriithi wrote:
> I am curious if anyone have come across a good article or book that
> describe how JVM operates.

First page of search results on your subject line gives what look to be
some good references. Presumably you've read
http://www.artima.com/insidejvm/ed2/jvm.html
and
http://docs.oracle.com/javase/specs/jvms/se7/html/

>  Stuff like how it maps its allocated memory into the operating system
> virtual memory,

Allocation is done with malloc (what else) in page size chunks which are
then managed internally by the runtime. You're probably best off
grabbing the VM source code and having a read if you need more detail
than that. Open source, yo.

Based on the data we have collected over the past 13 years or so of
using Java in production, I'd have to say the JVM is fairly reasonable
about (re)using the memory it gathers, especially on large systems with
multiple CPUs and gobs of RAM.

Incidentally, what top says abuot VSZ is fairly useless. Somewhat
annoyingly, the JVM allocates linearly in virtual memory. This has
absolutely zero impact on anything; just the upper virtual address bound
grows is all, and Linux top reports 0..that as VSZ even though it has
nothing to do with number of pages in use; it _looks_ bad, to be sure.
See "writable memory" in e.g. gnome-system-monitor for a more useful
number.

>   how it manage the memory and how one can control it

There are about 4 billion different options you can feed to the hotspot
runtime to control its behaviour.
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

> , java security from the system admin point of view. 

That makes this all sound a bit spurious, to be honest.

Are you talking about ensuring that libraries in use on your system are
updated? That Java programs don't have bugs? That the standard Java
library doesn't have bugs? Java itself doesn't have buffer overflows,
for example, but if you link to native code, well, all bets are off,
right? Got nothing to do with Java at that point.

Meanwhile it's easy to write an application that has security problems;
once in a while someone will demonstrate an application that, through
misuse, can be used DoS the system (the hashtable bug, for example,
which hit every language out there except Perl), but again, that's not
really the runtime's fault, and certainly has nothing to do with memory
allocation (that one was an weakness in the implementation of hashtables
that, if used in a web facing application to store HTTP headers, turned
out to vulnerable to a crafted attack which would result in excessive
CPU load. Who knew? Ok, the Perl people, but hey).

AfC
Sydney

-- 
Andrew Frederick Cowie
Operational Dynamics
http://www.operationaldynamics.com/

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists