Java Heap and -Xms/-Xmx

[Y Srinivas Ramakrishna]

Yes, AFAIK UseISM is now obsolete, but you are right that the
request for large pages on platforms that did not support
swappable large pages did have that side-effect of essentially
pinning the heap pages in memory. I am guessing it was some artifact
of the way page table entries were maintained on the underlying
platform in those cases.

My guess is that such platforms will actually shrink in volume
going forward as more OS's start supporting large pages. So, if
there is interest in locking the heap in core, it would be better
to have explicit such options/interfaces (for power users?) than
to depend on such obscure side-effects (my personal opinion)..

Again, I am only vaguely familiar with the history of the
related code, so others should please correct.

oh and another thing i wanted to add, for Keith's original question mostly,
is that if you want to determine what (heap and other) pages are resident
(in memory) vs swapped out (vs just reserved etc.), try Solaris' pmap(1)
(see also the JDK's jmap).

-- ramki

----- Original Message -----
From: "Ciciora, Paul" <Ciciora at cboe.com>
Date: Wednesday, July 2, 2008 1:04 pm
Subject: RE: Java Heap and -Xms/-Xmx
To: hotspot-gc-dev at openjdk.java.net


> I thought UseISM was meant to lock all the pages in memory. That may
> have been deprecated. I played with it a while back.
> 
> -----Original Message-----
> From: hotspot-gc-dev-bounces at openjdk.java.net
> [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of
> hotspot-gc-dev-request at openjdk.java.net
> Sent: Wednesday, July 02, 2008 2:00 PM
> To: hotspot-gc-dev at openjdk.java.net
> Subject: hotspot-gc-dev Digest, Vol 13, Issue 3
> 
> Send hotspot-gc-dev mailing list submissions to
> 	hotspot-gc-dev at openjdk.java.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev
> or, via email, send a message with subject or body 'help' to
> 	hotspot-gc-dev-request at openjdk.java.net
> 
> You can reach the person managing the list at
> 	hotspot-gc-dev-owner at openjdk.java.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-gc-dev digest..."
> 
> 
> Today's Topics:
> 
>    1. RE: Java Heap and -Xms/-Xmx (Keith Holdaway)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 1 Jul 2008 20:22:54 -0400
> From: Keith Holdaway <Keith.Holdaway at sas.com>
> Subject: RE: Java Heap and -Xms/-Xmx
> To: "Peter B. Kessler" <Peter.Kessler at Sun.COM>, Y Srinivas Ramakrishna
> 	<Y.S.Ramakrishna at Sun.COM>
> Cc: "hotspot-gc-dev at openjdk.java.net"
> 	<hotspot-gc-dev at openjdk.java.net>,	"Jon.Masamitsu at Sun.COM"
> 	<Jon.Masamitsu at Sun.COM>
> Message-ID:
> 	
> <304E9E55F6A4BE4B910C2437D4D1B4960B1FE5687C at MERCMBX14.na.sas.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Many thanks gentlemen - much appreciated.
> 
> keith
> ________________________________________
> From: Peter.Kessler at Sun.COM [Peter.Kessler at Sun.COM]
> Sent: Tuesday, July 01, 2008 2:55 PM
> To: Y Srinivas Ramakrishna
> Cc: Keith Holdaway; hotspot-gc-dev at openjdk.java.net;
> Jon.Masamitsu at Sun.COM
> Subject: Re: Java Heap and -Xms/-Xmx
> 
> The only tweak I'd add to your explanation is that in addition
> to the -Xmx that sets the amount of virtual address space we
> reserve, and the -Xms that represented the initial (and minimum)
> amount of virtual address space that we commit, there's the
> permanent generation, which is reserved at start-up and committed
> as needed.  But it's part of the contiguous block of the "heap"
> that we need, and in some cases is a modest fraction of our total
> reservation.
> 
> One can follow how much is reserved and committed for each
> generation of the heap with the -XX:+PrintHeapAtGC flag, where
> lines like
> 
>       PSPermGen       total 16384K, used 2107K [0xcfc00000, 0xd0c00000,
> 0xd3c00000)
> 
> mean we have reserved [0xcfc00000, 0xd3c00000) and committed
> [0xcfc00000, 0xd0c00000).
> 
> Oh, and the caveat that we round reservations and commits to page
> sizes, which can also be significant on some operating systems.
> 
>                         ... peter
> 
> Y Srinivas Ramakrishna wrote:
> 
> > Hi Keith --
> >
> >> If I set -Xms1g -Xmx2g and I have 4gb RAM, then will the VM always
> >> look to commit the 2GB Java heap to RAM? Or will it simply commit 2GB
> >> to virtual memory? Opening with -Xms of 1GB to RAM, but perhaps at
> >> runtime as the heap grows, the remaining 1GB java heap could be paged
> >> out. I understand the Java heap should not be paged out by the OS on
> >> account of performance overtones, but at start up when the heap is
> not
> >> stuck, by setting -Xms < -Xmx, what happens vis-?-vis the addressable
> >> memory that is the contiguous java heap? Spread out ENTIRELY on RAM,
> >> if available, or if available, could it still be RAM and non-RAM?
> >>
> >
> > When you set -Xms1G -Xmx2G, the committed heap (i.e. the physical heap
> > that we will actually use) starts at 1 G. That means there are pages
> > of memory that contain that state of the 1 G heap. Whether those
> > pages are physically on RAM or are in swap is something that the JVM
> > does not explicitly control. It's something that the OS controls, and
> > it depends on the "environment" (memory pressure) and the state of the
> host.
> > The 2G of address space is however reserved in the virtual address
> > space of the process. In other words, that space is not available for
> > use by other things in the process, such as C-heap, thread stacks or
> > mmapped libraries. However, at the start there may not be any physical
> > state (in an abstract sense) associated with that address space,
> because
> > there is no "memory" backing it, it's uninitialized unused memory that
> > has just been reserved. It may not even be available to be had when
> > we want to use it; see below. When the JVM believes it needs to expand
> the
> > Java heap to use that space, it will "commit" some of that reserved 
> VA
> space,
> > as it expands the physical Java heap. When this happens, actual memory
> (i wanted
> > to say "physical", but it may not be RAM pages at that stage; it may
> just
> > be a swap reservation that is all) backs that virtual address space.
> > Typically, when that space is actually touched by a thread (say when
> copying
> > data into it for the first time) the OS will then allocate physical
> RAM pages
> > for it. [The swap backing that space is allocated at the time the
> process
> > "commits" that space, indicating an intention to use it -- that's how
> it
> > works in Solaris; some Linuxes will not actually reserve the swap
> space
> > until the physical pages are touched, by the way, so in those cases
> thewe may fail when actually touching the page for the first time
> because
> > we find that the swap is not to be had because we are maxed out on
> swap;
> > this can make Linuxes fragile wrt the JVM's current implementation.
> > I don't know if we catch this and translate it into a suitable OOM
> > on the vulnerable Linuxes, i suspect not. (That is my understanding
> > from a while ago; things may have changed since to deal with that
> > fragility.)
> >
> > Once again however the question of whether the committed and used heap
> > is entirely in physical RAM or on RAM and swap depends on the OS
> > and the conditions of the host with the JVM not directly controlling
> > it.
> >
> > There was some talk of adding JVM options for locking the heap in
> > core (to use an archaic term), but I don't believe that has actually
> > been done in Java SE JDK. So my guess is that in order to lock the
> > heap in core, the user would need to do that separately via
> appropriate
> > OS interfaces.
> >
> > Others please correct any mistakes I might have made in my description
> > above based on what might be somewhat obsolete
> information/understanding
> > of the JVM's status wrt these issues. (In particular there has been
> > talk on and off both with dealing with Linux's commit semantics
> > and with locking the Java heap in core via suitable JVM options.)
> >
> > thanks.
> > -- ramki
> >
> >> Hope my question is not too confusing.
> >>
> >> thanks
> >>
> >> keith
> >>
> >> Keith R Holdaway
> >> Java Development Technologies
> >>
> >> SAS The Power to Know
> >>
> >> Carpe Diem
> >>
> >>
> >> -----Original Message-----
> >> From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM]
> >> Sent: Tuesday, July 01, 2008 1:56 PM
> >> To: Keith Holdaway
> >> Cc: hotspot-gc-dev at openjdk.java.net
> >> Subject: Re: Java Heap and -Xms/-Xmx
> >>
> >> Keith,
> >>
> >> Is this your question with numbers.
> >>
> >> If flag -Xmx1g -Xms500m are set on the command line
> >> and there is 2g of physical memory, will the VM
> >> increase the maximum heap size to 2g?
> >>
> >> No, the VM would not set the maximum heap size to
> >> 2g.  In general, the user gets what is requested
> >> on the command line.
> >>
> >> Was that the question?
> >>
> >> Jon
> >>
> >> Keith Holdaway wrote:
> >>> If -Xms is set to a smaller value than -Xmx, and -Xmx is set to a
> >> value less than the total RAM, will the VM commit the -Xmx setting 
> to
> >> physical addressable space ONLY?
> >>> thanks
> >>>
> >>> Keith R Holdaway
> >>> Java Development Technologies
> >>>
> >>> SAS The Power to Know
> >>>
> >>> Carpe Diem
> >>>
> >>>
> 
> 
> 
> 
> 
> End of hotspot-gc-dev Digest, Vol 13, Issue 3
> *********************************************