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

[Leonid Mesnik]

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;
}



>
>> 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/9f837846/attachment.htm>