<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Done, I get this<br>
<br>
The "Leaky program" bit is stupid simple test program that slowly
leaks memory, mostly to test the jvm simply<br>
<br>
Printf's for commint memory and anon_mmap added<br>
<br>
I notice that we get this one -> anon_mmap addr=0x5bae00000
bytes=9749659648 fixed=0<br>
<br>
greg@localhost
~/projects/openjdk/jdk7/build/linux-amd64-fastdebug/j2sdk-image $
./bin/java -Xms512m -Xmx9g -XX:+LockHeapInMemory test<br>
VM option '+LockHeapInMemory'<br>
commit_memory addr=0x7f2d66c49000 bytes=12288<br>
anon_mmap addr=(nil) bytes=50331648 fixed=0<br>
commit_memory addr=0x7f2d60bb5000 bytes=2555904<br>
anon_mmap addr=(nil) bytes=786432 fixed=0<br>
commit_memory addr=0x7f2d66b89000 bytes=40960<br>
anon_mmap addr=0x5bae00000 bytes=9749659648 fixed=0<br>
anon_mmap addr=(nil) bytes=19046400 fixed=0<br>
commit_memory addr=0x7f2d60bb4000 bytes=4096<br>
commit_memory addr=0x740000000 bytes=178913280<br>
commit_memory addr=0x7f2d605b4000 bytes=352256<br>
commit_memory addr=0x5c0000000 bytes=357957632<br>
anon_mmap addr=(nil) bytes=12582912 fixed=0<br>
commit_memory addr=0x7f2d5f9b4000 bytes=700416<br>
commit_memory addr=0x7f2d5ed8b000 bytes=700416<br>
commit_memory addr=0x5bae00000 bytes=21757952<br>
anon_mmap addr=(nil) bytes=167936 fixed=0<br>
commit_memory addr=0x7f2d5f98b000 bytes=45056<br>
commit_memory addr=0x7f2d5ed62000 bytes=45056<br>
commit_memory addr=0x7f2d5d7e5000 bytes=12288<br>
commit_memory addr=0x7f2d5d6e4000 bytes=12288<br>
commit_memory addr=0x7f2d5d3f5000 bytes=12288<br>
commit_memory addr=0x7f2d5d2f4000 bytes=12288<br>
commit_memory addr=0x7f2d5d1f3000 bytes=12288<br>
commit_memory addr=0x7f2d5d0f2000 bytes=12288<br>
Leaking program is slowly leaking 1<br>
Leaking program is slowly leaking 2<br>
Leaking program is slowly leaking 3<br>
....<br>
^Ccommit_memory addr=0x7f2d5cef0000 bytes=12288<br>
<br>
On 22/05/12 13:35, Vitaly Davidovich wrote:
<blockquote
cite="mid:CAHjP37HTgXs8qHWaQ=-oHP7+nSrpepxV7pj4xcw_w7v8MJGkeA@mail.gmail.com"
type="cite">
<p>can you add a print statement to commit_memory() to see what
arguments are being passed to it? I'm sure someone on this
mailing list will have a better suggestion, but that's what I'd
try just to establish that some code is indeed trying to expand
the heap to its max allotted size.</p>
<p>Sent from my phone</p>
<div class="gmail_quote">On May 22, 2012 4:08 PM, "Greg Bowyer"
<<a moz-do-not-send="true"
href="mailto:gbowyer@fastmail.co.uk">gbowyer@fastmail.co.uk</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> Yes thats basically it
<br>
<br>
java -Xms512m -Xmx9g test<br>
<br>
On 22/05/12 12:27, Vitaly Davidovich wrote:
<blockquote type="cite">
<p>Hi Greg,</p>
<p>As an aside, in os::commit_memory, I think the tertiary
condition that sets the flags is inverted - you want
MAP_LOCKED if LockHeapInMemory is set, I believe.</p>
<p>As to your question, what args are being passed to the
above function in your run? I take it -Xms is less than
Xmx in your trial?</p>
<p>Sent from my phone</p>
<div class="gmail_quote">On May 22, 2012 3:07 PM, "Greg
Bowyer" <<a moz-do-not-send="true"
href="mailto:gbowyer@fastmail.co.uk" target="_blank">gbowyer@fastmail.co.uk</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;"> Not sure if this is the right
venue for this, or if I am insane<br>
<br>
I have been playing with the openjdk code with a view
to lock the heap in memory (or at least suggest to the
OS that it wants to be locked in memory).<br>
<br>
My use case is for java processes that are greedy in
memory and typically have a virtual size larger than
physical ram. This is not where an end user allocates
a java heap beyond ram but rather things like Lucene /
Cassandra, where typically the JVM heap is large but
limited to say 1/4 of the total physical ram and the
rest of the process virtual size is taken up with
mmap()'d files.<br>
<br>
There are java projects that currently do this with a
call out via JNA / JNI to mlockall()<br>
<br>
Asking the OS to use the MAP_LOCKED flag in the mmap
calls in os_linux.cpp effectively does an mlock /
mlockall which I think means that when the OS chooses
pages to page out; then it should (for some measure of
should) avoid paging out the JVM heap.<br>
<br>
This means that horrors between CMS and paging do not
cause hateful pauses (hopefully)<br>
<br>
The thing I cant understand is that when I start a new
VM with this code (attached) it appears to lock the
full size of the heap (-Xmx) (even though the given
memory is not used by the VM), this seems to make the
entire space resident.<br>
<br>
any ideas ?<br>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a moz-do-not-send="true"
href="mailto:hotspot-gc-use@openjdk.java.net"
target="_blank">hotspot-gc-use@openjdk.java.net</a><br>
<a moz-do-not-send="true"
href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use"
target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>