<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Hi Thomas,<br>
<br>
The code change looks good.<br>
<br>
One question about the test. I know that the current failure was
with G1, but all of our GC should work with all the supported
ObjectAlignments, right? Why do we only want to test this with G1?
Maybe we could just remove "
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
-XX:+UseG1GC" from the command line and get testing for all GCs?
In that case I guess you probably don't need to use the
ProcessTools either. You could have serveral @run commands
instead.<br>
<br>
Bengt<br>
<br>
On 7/31/13 9:37 PM, Thomas Schatzl wrote:<br>
</div>
<blockquote cite="mid:1375299470.2557.23.camel@cirrus" type="cite">
<pre wrap="">Hi,
On Wed, 2013-07-31 at 12:05 -0700, Vladimir Kozlov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am not familiar with createJavaProcessBuilder API. Do we need to
specify -d64 flag for created process to run 64-bit VM? Or it will use
the same VM as main process?
</pre>
</blockquote>
<pre wrap="">
it will use the same VM as the main process (if you start with @run
main yourtest; also in case of @run main/othervm it uses another
instance of the same VM afaik).
However in case of 32 bit VMs the test immediately returns without
error. So 32 bit VMs do not try to use the -XX:ObjectAlignmentInBytes
flags (if that was your concern). Because in 32bit environments you
cannot guarantee that a 64 bit one is available.
This is a workaround because afaik there is no way to specify to exclude
running a particular test on some types of VM at the moment.
This also helps avoiding running this test on any VM that does not
support 32 bit, as all non-32 bit VMs supposedly support G1 (i.e.
include all gcs). This is another as of yet unsolved issue of the test
system. (Although that could probably be fixed by the VM exposing some
API to query that, but still we would need to just return in that case)
The test of course assumes that it will eventually be run by all
available VMs, so that everything is tested. 32 bit VMs just return
without error, 64 bit VMs perform the test.
This is also the reason for the original @run main/othervm tag: before
doing the test this way using the createjavaprocessbuilder API I had
several lines of
@run main/othervm -XX:+UseG1GC ... -XX:ObjectAlignmentInBytes={8 .. 256}
<testcase>
However this would have given immediate failures on VMs without G1, and
we already have enough of those.
Hth,
Thomas
</pre>
<blockquote type="cite">
<pre wrap="">On 7/31/13 12:02 PM, Thomas Schatzl wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
On Wed, 2013-07-31 at 10:29 -0700, Vladimir Kozlov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The fix looks good.
About test. You don't need "@run main/othervm TestObjectAlignment" line.
First, you don't need /othervm since you don't use any options with main
test. Second, as was explained me recently, jtreg will execute simple
"@run main TestObjectAlignment" by itself so you don't need to specify it.
</pre>
</blockquote>
<pre wrap="">
Changed; I do not like this automatism as I've been tripped over it
least once (e.g. as soon as you add a masked @run statement like @build,
the test is not automatically run any more), so I left the @run
statement.
You are correct though about both issues, and I do not really have a
strong opinion about this. I've updated the webrevs at
hs24: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/">http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/</a>
hs25: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/">http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>