RFR (XS): 8021823 G1: Concurrent marking crashes with -XX:ObjectAlignmentInBytes>=32 in 64bit VMs (patch for hs24+hs25)

[Bengt Rutisson]

Hi Thomas,

The code change looks good.

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 " -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.

Bengt

On 7/31/13 9:37 PM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2013-07-31 at 12:05 -0700, Vladimir Kozlov wrote:
>> 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?
>>
>   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
>
>> On 7/31/13 12:02 PM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On Wed, 2013-07-31 at 10:29 -0700, Vladimir Kozlov wrote:
>>>> 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.
>>>>
>>> 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: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs24/
>>> hs25: http://cr.openjdk.java.net/~tschatzl/8021823/webrev.2.hs25/
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130801/3e13cb5b/attachment.htm>