RFR (S): 8148563: compiler/compilercontrol/jcmd/StressAddMultiThreadedTest.java timesout

[Pavel Punegov]

Thanks for review, Nils

new webrev with prepended Xmixed: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.04/ <http://cr.openjdk.java.net/~ppunegov/8148563/webrev.04/>

> On 01 Mar 2016, at 12:46, Nils Eliasson <nils.eliasson at oracle.com> wrote:
> 
> Hi Pavel,
> 
> Prepend -Xmixed to inner test VM (the one runnning BaseAction launched by process builder). (Or do that as a separate change)
> 
> Otherwise it looks good!
> 
> Best regards,
> Nils Eliasson
> 
> 
> On 2016-02-25 18:54, Pavel Punegov wrote:
>> HI,
>> 
>> I updated a webrev according to discussion:  <http://cr.openjdk.java.net/%7Eppunegov/8148563/webrev.02/>http://cr.openjdk.java.net/~ppunegov/8148563/webrev.02/ <http://cr.openjdk.java.net/~ppunegov/8148563/webrev.02/>
>> 
>> 1. Remove sequential test.
>> 2. As in previous webrev use different commands, not only Compiler.directives_add.
>> 3. Make test execute only 20 commands, and not more than 30 seconds (controlled by TimeLimitedRunner).
>> 4. Make test execute diagnostic commands in the fixed set of 5 threads.
>> 
>> — Pavel.
>> 
>>> On 22 Feb 2016, at 18:00, Nils Eliasson < <mailto:nils.eliasson at oracle.com>nils.eliasson at oracle.com <mailto:nils.eliasson at oracle.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> I posted my own webrev for the same issue before reading this thread. I didn't see when the bug changed owner.
>>> 
>>> My reflections are:
>>> 
>>> 1) The sequantial test is redudant - the multi version tests everything.
>>> 2) Very good that you added more that just the add command!
>>> 3) Making this test run for 120 second is way too much in my opinion. 20 seconds should be more than enough each night. We are testing a stack guarded by a lock. 
>>> 4) Are you sure "Runtime.getRuntime().availableProcessors()" don't return all processors on a system (regardless of how many our image are allowed to use). I would limit to four threads or so - just to make sure there are possibilities for concurrent operations.
>>> 
>>> Best regards,
>>> Nils Eliasson
>>> 
>>> 
>>> On 2016-02-20 13:25, Pavel Punegov wrote:
>>>> Vladimir,
>>>> 
>>>> Test generated 5 directives of size 1000 directives before.
>>>> Previously test added them to directives stack one after another, making VM fail with native OOM (JDK-8144246 <https://bugs.openjdk.java.net/browse/JDK-8144246>). CompilerDirectivesLimit flag was added with default value of 50. Since that test began to add directives on the stack failing every time.
>>>> 
>>>> I changed the test to create only one file (999 directives) to reach the limit of 1000 (set by option). So it still can try to add directives over the limit, but it also executes other commands like "clear", "remove" and "print".
>>>> 
>>>> Added Nils to CC. Nils, could you please take a look also?
>>>> 
>>>> On 19.02.2016 23:45, Vladimir Kozlov wrote:
>>>>> Seems fine. What size of directive files was before and after this fix? JBS does not have this information. 
>>>>> 
>>>>> Thanks, 
>>>>> Vladimir 
>>>>> 
>>>>> On 2/19/16 9:04 AM, Pavel Punegov wrote: 
>>>>>> Hi, 
>>>>>> 
>>>>>> please review the fix for a test bug. 
>>>>>> 
>>>>>> Issue: 
>>>>>> 1. Test timeouts because it executes a lot of jcmd processes. Number of 
>>>>>> threads is calculated as number of processors (cores) * 10, that led to 
>>>>>> an enormous number of jcmds executed on hosts with lots of CPUs/cores. 
>>>>>> 2. Test also spends a lot of time to generate 5 huge directive files, 
>>>>>> that were tried to be added on to the directives stack. Directive stack 
>>>>>> has a limit (default 50, controlled by  CompilerDirectivesLimit). 
>>>>>> 
>>>>>> Fix: 
>>>>>> 1. Calculate number of threads as a log of the number of CPUs/cores * 10. 
>>>>>> 2. Generate only one file that is less than specified 
>>>>>> CompilerDirectivesLimit. 
>>>>>> 3. Add different commands to execute (add, clear, remove and print) and 
>>>>>> generate them on demand. 
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8148563/webrev.00/ <http://cr.openjdk.java.net/%7Eppunegov/8148563/webrev.00/> 
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148563 <https://bugs.openjdk.java.net/browse/JDK-8148563> 
>>>>>> 
>>>>>> — Pavel. 
>>>>>> 
>>>> 
>>>> -- 
>>>> Thanks,
>>>> Pavel Punegov
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160301/637f429d/attachment.html>