<br>Hi Kirk -- Interesting questions... I will try and answer (albeit only partially) the last two questions  in your email, letting others address the other questions (as well as add to the following as appropriate).<br><br>
<div class="gmail_quote">On Fri, Aug 31, 2012 at 1:49 AM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>... <br></div></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px"><div style="margin:0px">
<font face="Menlo"><span style="font-size:11px"><br></span></font></div><div style="margin:0px"><font face="Menlo"><span style="font-size:11px">One other thing that I found interesting is that when using ParNew with CMS in combination with NewRatio. What I've seen is that when the VM is loaded in low ram Heap will resize young gen. However, for some unknown reason, the resize never happens when the VM is loaded higher up in memory. I first noticed this while running a benchmark at a conference. </span></font><span style="font-family:Menlo;font-size:11px">The demo worked as expected prior to my talk, failed during the talk, and then worked after the talk. The difference in the runs was that during the talk I had keynote and Chrome and a PDF reader and a few other things running. They were idle but they were (of course) consuming quite a bit of memory. After a little bit of experimentation I noted that the adaptivity of the JVM is some affected by where it lies in memory. In my case it wasn't swapping but maybe being higher ram causes enough extra work with the pointers that you end up with this side effect????? Pure speculation but would be interested in any thoughts.</span></div>
</div></div></blockquote><div><br>I don't think that would be the case.<br><br>If you can recreate the conditions and run with a debug build you'd probably get more info. My guess is that you are short on swap as might happen when running with more active processes, you are unable to reserve swap for committing the expansion of the heap. So the expansion fails and you are unable to resize. The debug build of the JVM, from what i recall, issues a message indicating its inability to expand the heap. You might then try configuring more swap (and possibly RAM to avoid actually swapping) and see if the resize then happens with all of the programs in memory. What OS was this on?<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px"><div style="margin:0px"><span style="font-family:Menlo;font-size:11px"><br>
</span></div><div style="margin:0px"><font face="Menlo"><span style="font-size:11px"><br></span></font></div><div style="margin:0px"><font face="Menlo"><span style="font-size:11px">One last thing, while spelunking through the code I ran into this.</span></font></div>
<div style="margin:0px"><font face="Menlo"><span style="font-size:11px"><br></span></font></div><div style="margin:0px"><font face="Menlo"><span style="font-size:11px"><br></span></font></div><div style="margin:0px"><div style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">
// This method currently does not expect to expand into eden (i.e.,</div><div style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">// the virtual space boundaries is expected to be consistent</div><div style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(0,132,0)">
// with the eden boundaries..</div><div style="margin:0px;font-size:11px;font-family:Menlo"><span style="color:rgb(187,44,162)">void</span> PSYoungGen::post_resize() {</div><div style="margin:0px;font-size:11px;font-family:Menlo">
  assert_locked_or_safepoint(Heap_lock);</div><div style="margin:0px;font-size:11px;font-family:Menlo">  assert((eden_space()->bottom() < to_space()->bottom()) &&</div><div style="margin:0px;font-size:11px;font-family:Menlo">
         (eden_space()->bottom() < from_space()->bottom()),</div><div style="margin:0px;font-size:11px;font-family:Menlo;color:rgb(209,47,27)"><span style="color:rgb(0,0,0)">         </span>"Eden is assumed to be below the survivor spaces"<span style="color:rgb(0,0,0)">);</span></div>
<div style="margin:0px;font-size:11px;font-family:Menlo;min-height:13px"><br></div><div style="margin:0px;font-size:11px;font-family:Menlo">  MemRegion cmr((HeapWord*)virtual_space()->low(),</div><div style="margin:0px;font-size:11px;font-family:Menlo">
                (HeapWord*)virtual_space()->high());</div><div style="margin:0px;font-size:11px;font-family:Menlo">  Universe::heap()->barrier_set()->resize_covered_region(cmr);</div><div style="margin:0px;font-size:11px;font-family:Menlo">
  space_invariants();</div><div style="margin:0px;font-size:11px;font-family:Menlo">}</div><div style="margin:0px;font-size:11px;font-family:Menlo"><br></div><div style="margin:0px;font-size:11px;font-family:Menlo">The assertion, as I understand it, is asking if the bottom of to_space and from_space are both higher up in memory than the bottom of eden. Wouldn't you want to make sure that to or from is higher in memory than the top of eden?</div>
</div></div></div></blockquote><div><br>You are right, but in fact the assert can and should be even stronger than even that, namely that the _end_ of  Eden (which is higher than its _top_ which is equal to its _bottom_, if Eden is empty, which it usually is at the end of a scavenge) is lower (smaller virtual address) than the _bottom_ of  the survivor spaces. Recall that top is the where new allocation occurs, and end is the absolute end of the space that new allocation cannot cross.<br>
<br>PS: Disclaimer: this is from memory, i haven't looked at the code in a while, just remembering the naming conventions used in the code as i remember it.<br><br>-- ramki<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div style="margin:0px"><div style="margin:0px"><div style="margin:0px;font-size:11px;font-family:Menlo"><br></div><div style="margin:0px;font-size:11px;font-family:Menlo">Regards,</div><div style="margin:0px;font-size:11px;font-family:Menlo">
Kirk</div></div></div></div></blockquote></div><br>