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

Nils Eliasson nils.eliasson at oracle.com
Tue Mar 1 09:46:07 UTC 2016


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/~ppunegov/8148563/webrev.02/ 
> <http://cr.openjdk.java.net/%7Eppunegov/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 <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/
>>>>> bug: 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/a9396b29/attachment.html>


More information about the hotspot-compiler-dev mailing list