<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I tried your reproducer on 7u21 and it had no complaint.<br>
<br>
jdk/1.7.0_21/bin/java -XX:+UseParallelGC -Xmx4092M -version<br>
<br>
java version "1.7.0_21-ea"<br>
Java(TM) SE Runtime Environment (build 1.7.0_21-ea-b01)<br>
Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode)<br>
<br>
Note that 4092M < 4G.<br>
<br>
What was the symptom you got? How large is the tested machine's
memory?<br>
<br>
Thanks.<br>
Tao <br>
<br>
<br>
On 5/1/13 2:30 AM, Vladimir Kempik wrote:
<blockquote
cite="mid:A44E157E-1CAF-4752-B738-A0EA8C23AAB7@oracle.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>ParallelScavange and 7u21.</div>
<div><br>
</div>
<div>What was happening - gc, when allocating memory, was
overwriting some of it's own code and then calling bunch of
zeroes.</div>
<div><br>
</div>
<div>So I think safe memory increase and overflow check, from the
patch, fixed the problem.</div>
<div><br>
</div>
<div>Vladimir<br>
<br>
<br>
</div>
<div><br>
01.05.2013, в 1:52, Tao Mao <<a moz-do-not-send="true"
href="mailto:tao.mao@oracle.com">tao.mao@oracle.com</a>>
написал(а):<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
IMHO, what the customer reported could be a similar but
different bug.<br>
<br>
What version did they use, and what gc?<br>
<br>
Thanks.<br>
Tao<br>
<br>
On 4/30/13 1:22 PM, Vladimir Kempik wrote:
<blockquote
cite="mid:DA4CF70D-8526-4216-9B14-6AEBDC3F4189@oracle.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div>Hi</div>
<div><br>
</div>
<div>It has easy reproducer.</div>
<div><br>
</div>
<div>In solaris sparc, run 32-bit java</div>
<div><br>
</div>
<div>java -Xmx4092M -version</div>
<div><br>
</div>
<div>Java6/7 crashes. With patch from webrev.03 it works as
it should, saying it has not enough memory .<br>
Vladimir</div>
<div><br>
30.04.2013, в 22:11, Tao Mao <<a moz-do-not-send="true"
href="mailto:tao.mao@oracle.com">tao.mao@oracle.com</a>>
написал(а):<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hi Vladimir,<br>
<br>
Can you point me to your bug you think it's associated
with?<br>
<br>
Thanks.<br>
Tao<br>
<br>
On 4/30/13 3:33 AM, Vladimir Kempik wrote:
<blockquote cite="mid:517F9E14.8050707@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hello.<br>
<br>
I have a customer with non-escalated bug that is
duplicate of this bug. I checked with patch from
webrev.03 and can confirm that fixed the bug.<br>
<br>
Could you guys approve it if it's fine?<br>
<div class="moz-cite-prefix"><br>
Thanks. Vladimir.<br>
On 24.04.2013 22:35, Tao Mao wrote:<br>
</div>
<blockquote cite="mid:517825D4.4020505@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
For 32-bit builds: The current changeset provides
the first "protection" of heap size handling. Then
comes handling whether we can allocate a certain
amount of a heap.<br>
<br>
For 64-bit builds: a machine with 512M-1GB memory
should fail in many other tests as well, due to
inability to lauch jvm.<br>
<br>
Anyway, I ran the test and it passed. <br>
<br>
--------------------------------------------------<br>
Simply,<br>
<br>
-bash-4.1$ ulimit -v 134217728 (128m for human
reading)<br>
-bash-4.1$ ulimit -m 134217728 (128m FHR)<br>
<br>
(cannot limit virtual memory to zero or set
vm.swappiness=0, in which case the server would hang
immediately w/o even launching jvm. But, the setting
should satisfy your question.)<br>
<br>
Then, run jtreg. Then, pass.<br>
--------------------------------------------------<br>
<br>
BTW, since you've jumped in this thread ^_^ can you
check the way I get system property through
"test.java.opts"
<meta charset="utf-8">
to set inside jvm process? It's in
test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java<br>
<br>
Thank you.<br>
Tao<br>
<br>
On 4/24/13 3:36 AM, Leonid Mesnik wrote:
<blockquote cite="mid:5177B599.3050604@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 04/22/2013 10:07
PM, Tao Mao wrote:<br>
</div>
<blockquote cite="mid:51757C74.9000605@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
This should be handled by a separate CR
(probably by this CR <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://jbs.oracle.com/bugs/browse/JDK-7112912">https://jbs.oracle.com/bugs/browse/JDK-7112912</a>)<br>
<br>
</blockquote>
Why this? I mean should your test pass on hosts
with *small* amount of memory. <br>
<br>
Leonid<br>
<blockquote cite="mid:51757C74.9000605@oracle.com"
type="cite"> Thanks.<br>
Tao<br>
<br>
On 4/22/13 2:46 AM, Leonid Mesnik wrote:
<blockquote
cite="mid:517506EE.5030000@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Tao <br>
<br>
This is not review, just question. <br>
<br>
Should you test pass on hosts with 512M-1GB
memory and no swap? <br>
<br>
Leonid<br>
On 04/19/2013 09:27 PM, Tao Mao wrote:<br>
</div>
<blockquote
cite="mid:51717E6E.4020806@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
1. check overflow routine is wrapped up.<br>
<br>
2. The reduction of code duplication is
adopted.<br>
<br>
3. Develop a way to intake 0~multiple
external vm options in jtreg main(). Hope it
helps others implement similar
functionality.<br>
<br>
webrev:<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Etamao/6761744/webrev.02/">http://cr.openjdk.java.net/~tamao/6761744/webrev.02/</a><br>
<br>
test:<br>
JTREG: passed.<br>
jtreg -jdk:/home/tamao/jdk1.7.0_04-i586
-vmoptions:"-tamao <GC_OPTION>"
/home/tamao/src/6761744CrashIfProcessSizeLimitExceeded_hsx24/test/gc/init/TestHandleExceedingProcessSizeLimitIn32BitBuilds.java<br>
<br>
where GC_OPTION rotates in
-XX:+UseParallelGC -XX:+UseG1GC
-XX:+UseSerialGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC<br>
<br>
<br>
Thanks.<br>
Tao<br>
<br>
On 4/15/13 1:37 AM, Bengt Rutisson wrote:
<blockquote
cite="mid:516BBC64.6060509@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
Hi Tao,<br>
<br>
I agree with John. The changes look fine
and I'm ok with them. But it would look
nicer to add the
CollectedHeap::add_and_verify_no_overflow()
method.<br>
<br>
Also, regarding the test, a couple of
minor things.<br>
<br>
First, with the new naming convention I
think the test should be called
something like:<br>
<br>
test/gc/init/TestHandleExceedingProcessSizeLimitOn32BitSystems.java<br>
<br>
Then I think you can reduce the code
duplication a bit. You create the same
ProcessBuilder and OutputAnalyzer in
both 32 and 64 bit cases. So maybe it
could look like this instead:<br>
<br>
<tt>public class
TestHandleExceedingProcessSizeLimitOn32BitSystems
{</tt><tt><br>
</tt><tt> public static void
main(String args[]) throws Exception {</tt><tt><br>
</tt><tt> ProcessBuilder pb =</tt><tt><br>
</tt><tt>
ProcessTools.createJavaProcessBuilder(System.getProperty("test.vm.opts"),</tt><tt><br>
</tt><tt>
"-Xmx3072m",</tt><tt><br>
</tt><tt>
"-XX:MaxPermSize=1024m",</tt><tt><br>
</tt><tt>
"-version");</tt><tt><br>
</tt><tt> OutputAnalyzer output = new
OutputAnalyzer(pb.start());</tt><tt><br>
</tt><tt><br>
</tt><tt> String dataModel =
System.getProperty("sun.arch.data.model");</tt><tt><br>
</tt><tt> if (dataModel.equals("32"))
{</tt><tt><br>
</tt><tt> output.shouldContain("The
size of the object heap + perm gen
exceeds the maximum representable
size");</tt><tt><br>
</tt><tt> if (output.getExitValue()
== 0) {</tt><tt><br>
</tt><tt> throw new
RuntimeException("Not expected to get
exit value 0");</tt><tt><br>
</tt><tt> }</tt><tt><br>
</tt><tt> } else if
(dataModel.equals("64")) {</tt><tt><br>
</tt><tt>
output.shouldHaveExitValue(0);</tt><tt><br>
</tt><tt> }</tt><tt><br>
</tt><tt> }</tt><tt><br>
</tt><tt>}</tt><tt><br>
</tt><br>
There is also a small bug in the test.
If you run JTreg without passing any
vmoptions the test will fail. The reason
is that
System.getProperty("test.vm.opts") will
evaluate to the empty string. This will
be passed as the first argument to the
Java process, which will assume that
this is the class name. So, it fails to
start because it can't load the class
<empty string>.<br>
<br>
To reproduce the problem use this
command line:<br>
<br>
java -jar
<path_to_jtreg>/lib/jtreg.jar
test/gc/6761744/TestHandleExceedingProcessSizeLimitOn32BitSystems.java<br>
<br>
I guess the fix is to check that
System.getProperty("test.vm.opts") is
not empty before passing it on to
createJavaProcessBuilder().<br>
<br>
Thanks,<br>
Bengt<br>
<br>
On 4/13/13 3:15 AM, John Cuthbertson
wrote:<br>
</div>
<blockquote
cite="mid:5168B1AD.7060302@oracle.com"
type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
Hi Tao,<br>
<br>
This looks OK to me.<br>
<br>
I can see what Thomas is saying though.
All of the checks involve something
like:<br>
<br>
total += some_value;<br>
if (total < some_value) {<br>
// We must have overflowed<br>
vm_exit(...);<br>
}<br>
<br>
So a function in CollectedHeap (the base
class of SharedHeap and
ParallelScavengeHeap) might make sense.
For example:<br>
<br>
total_reserved = 0;<br>
total_reserved =
add_and_verify_no_overflow(total_reserved,
max_heap_size);<br>
total_reserved =
add_and_verify_no_overflow(total_reserved,
max_perm_size);<br>
<br>
Where the function is:<br>
<br>
size_t add_and_verify_no_overflow(size_t
x, size_t y) {<br>
const char* msg = "...";<br>
x += y;<br>
if (x < y) {<br>
vm_exit(msg);<br>
}<br>
return x;<br>
}<br>
<br>
But I can live with your current
changes.<br>
<br>
JohnC<br>
<br>
<div class="moz-cite-prefix">On
4/10/2013 9:52 AM, Tao Mao wrote:<br>
</div>
<blockquote
cite="mid:516598D3.1020809@oracle.com"
type="cite">
<meta content="text/html;
charset=UTF-8"
http-equiv="Content-Type">
Hi Bengt,<br>
<br>
Thank you for reviewing. A new webrev
is updated.<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Etamao/6761744/webrev.01/">http://cr.openjdk.java.net/~tamao/6761744/webrev.01/</a><br>
<br>
Cheers,<br>
Tao<br>
<br>
On 4/10/13 1:54 AM, Bengt Rutisson
wrote:
<blockquote
cite="mid:516528C2.8080709@oracle.com"
type="cite">
<meta content="text/html;
charset=UTF-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix"><br>
Hi Tao,<br>
<br>
This change looks good. Thanks for
adding the JTReg test, it looks
good!<br>
<br>
One minor nit:<br>
<br>
In
src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
I would suggest to
<meta http-equiv="content-type"
content="text/html;
charset=UTF-8">
store "(size_t)
align_size_up(pgs->max_size(),
HeapRegion::GrainBytes)" in a
local variable rather than
duplicating the calculation.<br>
<br>
Thanks,<br>
Bengt<br>
<br>
On 4/8/13 7:22 AM, Tao Mao wrote:<br>
</div>
<blockquote
cite="mid:51625424.4050209@oracle.com"
type="cite">
<meta http-equiv="content-type"
content="text/html;
charset=UTF-8">
6761744 Hotspot crashes if process
size limit is exceeded<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://jbs.oracle.com/bugs/browse/JDK-6761744">https://jbs.oracle.com/bugs/browse/JDK-6761744</a><br>
<br>
webrev:<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Etamao/6761744/webrev.00/">http://cr.openjdk.java.net/~tamao/6761744/webrev.00/</a><br>
<br>
changeset:<br>
The fix only needs to go to hsx24
since there's no perm gen in
hotspot-25. Thus, the webrev is
based on hsx24 repo.<br>
<br>
It provides for 32-bit builds a
preventive check of the size of
"the object heap + perm gen"
before reserving VM memory. The
total size should not exceed
4096MB (i.e. 4GB) for 32-bit
builds; otherwise, the total
doesn't make sense and, what's
worse, overflow occurs. It will
consequentially trigger anther
error of memory access violation,
which was not protected<span
style="color: rgb(0, 0, 0);
font-family: Arial, FreeSans,
Helvetica, sans-serif;
font-size: 12.727272033691406px;
font-style: normal;
font-variant: normal;
font-weight: normal;
letter-spacing: normal;
line-height:
15.454545021057129px; orphans:
auto; text-align: start;
text-indent: 0px;
text-transform: none;
white-space: normal; widows:
auto; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;
background-color: rgb(240, 240,
240); display: inline
!important; float: none;"></span>.<br>
<br>
jtreg testing java code is also
written, checking both 32-bit and
(trivially) 64-bit builds.<br>
<br>
testing:<br>
check jtreg tests with flags
-XX:+UseParallelGC, -XX:+UseG1GC,
-XX:+UseParNewGC,
-XX:+UseConcMarkSweepGC,
-XX:+UseSerialGC and builds of
32-bit and 64-bit. All passed.<br>
<br>
Needs JPRT test when pushing.<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Leonid Mesnik
JVM SQE</pre>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Leonid Mesnik
JVM SQE</pre>
</blockquote>
</blockquote>
<br>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
</body>
</html>