Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

2018-01-24 Thread Alan Bateman



On 23/01/2018 22:28, Andrey Nazarov wrote:

Hi,

After offline discussion with Leonid and with Igor in JBS we decided to skip 
test in case of -Xcomp option presence and do not increase timeout. Issue was 
faced in our build and test system only with -Xcomp flag.

see updated patch http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.02/

This looks okay. On the >= 2g check then we should separately see if 
these tests can run without needing 1g of heap.


-Alan


Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

2018-01-23 Thread Andrey Nazarov
Hi,

After offline discussion with Leonid and with Igor in JBS we decided to skip 
test in case of -Xcomp option presence and do not increase timeout. Issue was 
faced in our build and test system only with -Xcomp flag.

see updated patch http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.02/ 

—Andrei

> On 22 Jan 2018, at 16:12, Andrey Nazarov  wrote:
> 
> 
> 
>> On 22 Jan 2018, at 15:33, Andrey Nazarov  wrote:
>> 
>> 
>> 
>>> On 22 Jan 2018, at 13:07, Joseph D. Darcy  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm wary of increasing the timeout to 5 minutes. When such tests are run on 
>>> CI servers, the effective timeout can be 10 minutes or more given a timeout 
>>> factor used for the test run.
>> We can move them to later tiers. On my Macbook pro 2015 + SSD JlinkTest.java 
>> runs around 40 seconds. It could easily be more than 2 min with HDD, working 
>> McAfee/indexer, slower hardware. So I think default timeout =  2 minutes is 
>> not enough. 
>>> 
>>> Should using 1GB of memory on the @run line have an earlier @requires guard 
>>> for an amount of memory on the system?
>> I think it should. Although it’s not related to the original issue, i’ll 
>> update patch with @requires 
> Updated http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.01/
>>> 
>>> Cheers,
>>> 
>>> -Joe
>>> 
>>> On 1/22/2018 12:58 PM, Andrey Nazarov wrote:
 Hi,
 please review Jlink tests.
 
 I’ve increased default timeout to 5 minutes and skip tests in “-Xcomp” VM 
 mode.
 
 CR: http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.00/ 
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8161348 
 
 
 —Andrei
>>> 
>> 
> 



Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

2018-01-22 Thread Andrey Nazarov


> On 22 Jan 2018, at 15:33, Andrey Nazarov  wrote:
> 
> 
> 
>> On 22 Jan 2018, at 13:07, Joseph D. Darcy  wrote:
>> 
>> Hello,
>> 
>> I'm wary of increasing the timeout to 5 minutes. When such tests are run on 
>> CI servers, the effective timeout can be 10 minutes or more given a timeout 
>> factor used for the test run.
> We can move them to later tiers. On my Macbook pro 2015 + SSD JlinkTest.java 
> runs around 40 seconds. It could easily be more than 2 min with HDD, working 
> McAfee/indexer, slower hardware. So I think default timeout =  2 minutes is 
> not enough. 
>> 
>> Should using 1GB of memory on the @run line have an earlier @requires guard 
>> for an amount of memory on the system?
> I think it should. Although it’s not related to the original issue, i’ll 
> update patch with @requires 
Updated http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.01/
>> 
>> Cheers,
>> 
>> -Joe
>> 
>> On 1/22/2018 12:58 PM, Andrey Nazarov wrote:
>>> Hi,
>>> please review Jlink tests.
>>> 
>>> I’ve increased default timeout to 5 minutes and skip tests in “-Xcomp” VM 
>>> mode.
>>> 
>>> CR: http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.00/ 
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161348 
>>> 
>>> 
>>> —Andrei
>> 
> 



Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

2018-01-22 Thread Andrey Nazarov


> On 22 Jan 2018, at 13:07, Joseph D. Darcy  wrote:
> 
> Hello,
> 
> I'm wary of increasing the timeout to 5 minutes. When such tests are run on 
> CI servers, the effective timeout can be 10 minutes or more given a timeout 
> factor used for the test run.
We can move them to later tiers. On my Macbook pro 2015 + SSD JlinkTest.java 
runs around 40 seconds. It could easily be more than 2 min with HDD, working 
McAfee/indexer, slower hardware. So I think default timeout =  2 minutes is not 
enough. 
> 
> Should using 1GB of memory on the @run line have an earlier @requires guard 
> for an amount of memory on the system?
I think it should. Although it’s not related to the original issue, i’ll update 
patch with @requires 
> 
> Cheers,
> 
> -Joe
> 
> On 1/22/2018 12:58 PM, Andrey Nazarov wrote:
>> Hi,
>> please review Jlink tests.
>> 
>> I’ve increased default timeout to 5 minutes and skip tests in “-Xcomp” VM 
>> mode.
>> 
>> CR: http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.00/ 
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161348 
>> 
>> 
>> —Andrei
> 



Re: RFR: JDK-8161348 Several tools/jlink tests failed due to time out

2018-01-22 Thread Joseph D. Darcy

Hello,

I'm wary of increasing the timeout to 5 minutes. When such tests are run 
on CI servers, the effective timeout can be 10 minutes or more given a 
timeout factor used for the test run.


Should using 1GB of memory on the @run line have an earlier @requires 
guard for an amount of memory on the system?


Cheers,

-Joe

On 1/22/2018 12:58 PM, Andrey Nazarov wrote:

Hi,
please review Jlink tests.

I’ve increased default timeout to 5 minutes and skip tests in “-Xcomp” VM mode.

CR: http://cr.openjdk.java.net/~anazarov/JDK-8161348/webrev.00/ 

Bug: https://bugs.openjdk.java.net/browse/JDK-8161348 


—Andrei