RFR(XS): 8008188: Add regression test for 8005875

[Bengt Rutisson]

Leonid,

On 2/14/13 2:15 PM, Leonid Mesnik wrote:
> On 02/14/2013 04:47 PM, Bengt Rutisson wrote:
>>
>> Leonid,
>>
>> On 2/14/13 1:27 PM, Leonid Mesnik wrote:
>>> John
>>>
>>> This test should start failing in non-G1 baseline. Even 
>>> "IgnoreUnrecognizedVMOptions" is added I think it should fail 
>>> because of incompatible GC combinations.
>>
>> Actually it won't fail. The test checks that the output "G1 Parallel 
>> Marking Threads" is *not* present, which it won't be for any other 
>> collectors.
>>
>> It is kind of a waste to run this test for other collectors but it 
>> won't fail. However, since the testing framework is limited and can't 
>> handle that we need to write tests for specific GCs I think this is 
>> how we have to write our tests.
> Shouldn't fail here: (./share/vm/runtime/arguments.cpp)
> // Check consistency of GC selection
> bool Arguments::check_gc_consistency() {
>   check_gclog_consistency();
>   bool status = true;
>   // Ensure that the user has not selected conflicting sets
>   // of collectors. [Note: this check is merely a user convenience;
>   // collectors over-ride each other so that only a non-conflicting
>   // set is selected; however what the user gets is not what they
>   // may have expected from the combination they asked for. It's
>   // better to reduce user confusion by not allowing them to
>   // select conflicting combinations.
>   uint i = 0;
>   if (UseSerialGC)                       i++;
>   if (UseConcMarkSweepGC || UseParNewGC) i++;
>   if (UseParallelGC || UseParallelOldGC) i++;
>   if (UseG1GC)                           i++;
>   if (i > 1) {
>     jio_fprintf(defaultStream::error_stream(),
>                 "Conflicting collector combinations in option list; "
>                 "please refer to the release notes for the combinations "
>                 "allowed\n");
>     status = false;
>   }
>
>   return status;
> }

Yes, you are probably correct. This is why we need this bug fixe as soon 
as possible:

INTJDK-7185557: Tests written for specific collector need to ignore 
global settings
https://jbs.oracle.com/bugs/browse/INTJDK-7185557

It is a P2 that has not been touched for half a year.

Bengt

>
>
>
>>
>>> Also I think that investigation parent process from child is not 
>>> safe and make analysis harder if something going wrong.
>>>
>>> Also there was a bug  15947151 - JDK6 JMAP -HEAP LOCKS post 6u29.
>>> Here are comments from Kevin:
>>>
>>> /@ Using Runtime.exec to launch a child process which then attaches 
>>> back to the/
>>> /@ parent to run diagnostics just sounds risky.  Diagnostics may 
>>> need to suspend/
>>> /@ the parent JVM.  The child needs the parent to read buffers such 
>>> that the /
>>> /@ child may write.  Buffering usually lets this succeed, but there 
>>> could/
>>> /@ be some risk./
>>>
>>>
>>> So I would prefer to avoid such schemes if we don't want to test them.
>>
>> Yes, this is an interesting problem. If the buffer for the 
>> OutputAnalyzer gets full before the jmap call returns we will have a 
>> deadlock.
>>
>> Would you suggest that the test should spawn two processes?
> Yes
>> How do they do the handshaking to find out when it is safe to do a 
>> jmap call from one to the other?
> We use DTonga for similar tmtools tests which includes task 
> synchronization. Also we have network-based sync for jdi/other 
> debugging tests.
> May be jps could be used to find process and be sure that java is 
> initialized or just make jmap in a loop until it returns results.
>
> Unfortunately there is no easy and generic synchronization I think.
>
> Think comments below are for John.
>
> Leonid
>> Looking at this test again reminded me of a few more minor things:
>>
>> * It would be good if the test had the "@key gc" tag that I am just 
>> about to add. See:
>> http://cr.openjdk.java.net/~brutisso/8006398/webrev.01/
>>
>> * You don't need -XX:+IgnoreUnrecognizedVMOptions in the @run command
>>
>> * The test is in a directory called 8005875/. I again think this is 
>> obsolete if we use the @bug tag. I would prefer to name the folder 
>> something meaningful.
>>
>> Thanks,
>> Bengt
>>
>>>
>>> Leonid
>>>
>>> On 02/14/2013 04:51 AM, John Cuthbertson wrote:
>>>> Hi Everyone,
>>>>
>>>> Can I have a couple of volunteers review the regression test for 
>>>> 8005875 - the webrev can be found at: 
>>>> http://cr.openjdk.java.net/~johnc/8008188/webrev.0/
>>>>
>>>> The test is very simple and issues "jcmd <pid> Thread.print" 
>>>> against itself. With G1 and PGCT=0, and before the fix for 8005875, 
>>>> this command crashes the VM.
>>>>
>>>> Testing:
>>>> jdk8 build (b76) with fix for 8005875; jdk8 build (b71) without fix 
>>>> for 8005875; Changed the test options to run the test with the 
>>>> invalid flag -XX:+UseG2GC.
>>>>
>>>> Thanks,
>>>>
>>>> JohnC
>>>
>>>
>>> -- 
>>> Leonid Mesnik
>>> JVM SQE
>>
>
>
> -- 
> Leonid Mesnik
> JVM SQE

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