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

Nils Eliasson nils.eliasson at oracle.com
Mon Feb 22 15:00:54 UTC 2016


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/20160222/79bf4604/attachment.html>

More information about the hotspot-compiler-dev mailing list