RFR(XS): 8008188: Add regression test for 8005875
Bengt Rutisson
bengt.rutisson at oracle.com
Thu Feb 14 13:57:21 UTC 2013
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>
More information about the hotspot-gc-dev
mailing list