<br>Thanks, Bengt, for the super-quick turnaround!! A comment below on the choice of <= 0 for the option value....<br><br><div class="gmail_quote">On Mon, Nov 14, 2011 at 1:25 AM, Bengt Rutisson <span dir="ltr"><<a href="mailto:bengt.rutisson@oracle.com">bengt.rutisson@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Hi all,<br>
<br>
Can I have a couple of reviews for this small change?<br>
<a href="http://cr.openjdk.java.net/%7Ebrutisso/7110718/webrev.01/" target="_blank">http://cr.openjdk.java.net/~<u></u>brutisso/7110718/webrev.01/</a><br>
<br>
It is a fix for the issue that Ramki reported recently. MarkSweepAlwaysCompactCount is used for division and Hotspot crashes if it is set to 0.<br>
<br>
I choose to log an error and exit the VM if someone tries to start with -XX:<u></u>MarkSweepAlwaysCompactCount=0. An alternative is to just log a warning and set it to 1.<br>
<br>
I prefer the error way since it is not really clear what one wants to achieve with MarkSweepAlwaysCompactCount=0. Always do full compactions or never do full compactions? So I am not convinced that 1 is an appropriate value.<br>

<br>
Also, since the VM, up until now, has crashed if someone tried -XX:<u></u>MarkSweepAlwaysCompactCount=0 I think we can be sure that there are no customers that are running with that setting. It should be safe to forbid it.<br>
</blockquote><div><br>I agree with that statement. However, given that the value 0 was producing crashes, proving that no production code would have been using that setting,<br>and based on yr comment above that the 0 value could as well have been used to denote "never force full compaction", it seems as though an alternative to exiting with<br>
an error, is now to define all values <=0 to mean "never _force_ full compaction" <br><br>Especially since tolerating allowed input values and mapping them to specific non-exiting behaviours allows us to modify production JVM's on the fly<br>
without causing loss of availability. (Consider a future in which this option becomes a "manageable"; you would then be faced with the same<br>question, and it seems as though making this choice now would help maintain consistency and robustness going forward -- we could of course<br>
always throw a "illegal value exception" or such at that point, but allowing the specification of "never _force_ full compaction" (unless the JVM<br>otherwise chooses to) would appear to be a choice to allow users; mapping negative and 0 values to that setting would avoid having to<br>
throw an error.) However, I understand that this is somewhat subjective, so I am willing to go with whatever the majority consensus here<br>mght be. It just seemed more pleasant to:<br>(1) allow the specification of reasonable behaviour (i.e. never _force_ ...)<br>
(2) map the full domain of the option to a reasonable behaviour (i.e. allow <= 0 to map to never _force_ ..)<br><br>Comments?<br><br>-- ramki<br><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;">

<br>
CR:<br>
<br>
7110718 -XX:<u></u>MarkSweepAlwaysCompactCount=0 crashes the JVM<br>
<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7110718" target="_blank">http://bugs.sun.com/<u></u>bugdatabase/view_bug.do?bug_<u></u>id=7110718</a><br>
<br>
Thanks,<br><font color="#888888">
Bengt<br>
</font></blockquote></div><br>