Re: [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

2017-04-07 Thread Sergey Bylokhov 

> 6 апр. 2017 г., в 23:26, Semyon Sadetsky  
> написал(а):
> 
> On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:
>>> Sergey, could you replace CountDownLatch::await() call with its limited 
>>> wait time analog. If the test fails it blocks execution for 2 minutes in 
>>> the current version.
>>> 
>> 2 minutes is a default time out for jtreg tests, if something goes wrong 
>> like something hangs, then we wait 2 minutes and interrupt the test.
>> After interruption the jtreg will generate the dump for all threads which 
>> can be useful to check why the event was not generated by the robot.
> You are able to print out this useful information after timeout in the catch 
> block.

We already have a mechanism which kills the tests after timeout, we also have a 
default timeout of 2 minutes.
I am not sure how to get dump of all threads from the catch block.

> I would prefer to avoid any infinite waiting because if the listener is not 
> triggered in several second it will unlikely be triggered at all. But if a 
> number of such tests fails for some reason the execution time becomes so long 
> that the test report cannot be obtained in a reasonable time.
>> 
>>> 
>>> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
 Here is an updated version:
 http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
 
 It will save 5 sec per test, so probably the simpler .00 version can be 
 reevaluated.
 
> 
> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
>>> sun.java2d.win.uiScaleX/Y is only applicable to windows which is likely 
>>> why the test had 
>>> @requires (os.family == "windows") even if it was not the right name.
>>> 
>>> Now you are running unconditionally with those properties on all 
>>> platforms which
>>> seems to be a waste of time.
>> Yes, if we know that uiScaleX/Y are windows specific then 2 modes out of 
>> 5 is noop. But I do not like to exclude them, instead I would like to 
>> fuzz the tests by supported/unsupported properties, in the same way as 
>> 2d-tests are executed using different supported/unsupprted 
>> "sun.java2d.XXX" pipelines.
>   The test can be separated on two tests: one is Windows specific and 
> another is general.
> 
>   Thanks,
>   Alexandr.
>> 
>>> 
>>> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
 Hello,
 Please review the fix for jdk9.
 
 Initially I found a typo in the HiDPIRobotMouseClick.java. It contains 
 the «Dsun.java2d.win.uiScale» option, which should be 
 Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
 But when I verified the fix, the test fails if executed w/o any 
 options (my system has 125% DPI).
 
 So I decided to update it and related HiDPIRobotScreenCaptureTest to 
 validated more modes.
 
 - Default(w/o options), useful if the system has some default scale.
 - scale = 1 is useful when the tests are executed on HiDPI systems.
 
 I am not sure why these tests sets the Windows L because it uses 
 only awt Frame.  
 I’ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 
 
 Webrev can be found at: 
 http://cr.openjdk.java.net/~serb/8177841/webrev.00 
 
>> 
> 
 
>>> 
>> 
>

Re: [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

2017-04-07 Thread Semyon Sadetsky 

On 04/07/2017 10:42 AM, Sergey Bylokhov wrote:



We already have a mechanism which kills the tests after timeout, we 
also have a default timeout of 2 minutes.

I am not sure how to get dump of all threads from the catch block.
But shouldn't the time frame when a mouse click may come be limited? 
Will it be correct when the click triggered after 2 minutes delay 
makes the test passed anyway?


If timeout will occur and the test still was not complete, then it 
will be killed, all frames will be closed, the dump of all threads 
will be generated. So the test cannot pass after timeout.
I meant when the listener is triggered right before the 2 minutes 
timeout, for example in 1 minute 59 seconds. In the current logic the 
test passes in this case and no dumps were generated for any thread. But 
actually this means an issue because event shouldn't be delayed for that 
amount of time or this event is not generated by the test.




I would prefer to avoid any infinite waiting because if the 
listener is not triggered in several second it will unlikely be 
triggered at all. But if a number of such tests fails for some 
reason the execution time becomes so long that the test report 
cannot be obtained in a reasonable time.




On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:

Here is an updated version:
http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 

It will save 5 sec per test, so probably the simpler .00 version 
can be reevaluated.




On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
sun.java2d.win.uiScaleX/Y is only applicable to windows which 
is likely why the test had
@requires (os.family == "windows") even if it was not the 
right name. Now you are running unconditionally with those 
properties on all platforms which seems to be a waste of time.
Yes, if we know that uiScaleX/Y are windows specific then 2 
modes out of 5 is noop. But I do not like to exclude them, 
instead I would like to fuzz the tests by 
supported/unsupported properties, in the same way as 2d-tests 
are executed using different supported/unsupprted 
"sun.java2d.XXX" pipelines.
  The test can be separated on two tests: one is Windows 
specific and another is general.


  Thanks,
  Alexandr.




On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:

Hello,
Please review the fix for jdk9.

Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the 
«Dsun.java2d.win.uiScale» option, which should be Dsun.java2d.uiScale or 
Dsun.java2d.win.uiScaleX/Y.
But when I verified the fix, the test fails if executed w/o any options (my 
system has 125% DPI).

So I decided to update it and related HiDPIRobotScreenCaptureTest to validated 
more modes.

- Default(w/o options), useful if the system has some default scale.
- scale = 1 is useful when the tests are executed on HiDPI systems.

I am not sure why these tests sets the Windows L because it uses only awt 
Frame.
I’ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.

Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00

Re: [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

2017-04-07 Thread Sergey Bylokhov 
>> 
>> We already have a mechanism which kills the tests after timeout, we also 
>> have a default timeout of 2 minutes.
>> I am not sure how to get dump of all threads from the catch block.
> But shouldn't the time frame when a mouse click may come be limited? Will it 
> be correct when the click triggered after 2 minutes delay makes the test 
> passed anyway?

If timeout will occur and the test still was not complete, then it will be 
killed, all frames will be closed, the dump of all threads will be generated. 
So the test cannot pass after timeout.

>> 
>>> I would prefer to avoid any infinite waiting because if the listener is not 
>>> triggered in several second it will unlikely be triggered at all. But if a 
>>> number of such tests fails for some reason the execution time becomes so 
>>> long that the test report cannot be obtained in a reasonable time.
 
> 
> On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:
>> Here is an updated version:
>> http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 
>> 
>> It will save 5 sec per test, so probably the simpler .00 version can be 
>> reevaluated.
>> 
>>> 
>>> On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
> sun.java2d.win.uiScaleX/Y is only applicable to windows which is 
> likely why the test had 
> @requires (os.family == "windows") even if it was not the right name.
> 
> Now you are running unconditionally with those properties on all 
> platforms which
> seems to be a waste of time.
 Yes, if we know that uiScaleX/Y are windows specific then 2 modes out 
 of 5 is noop. But I do not like to exclude them, instead I would like 
 to fuzz the tests by supported/unsupported properties, in the same way 
 as 2d-tests are executed using different supported/unsupprted 
 "sun.java2d.XXX" pipelines.
>>>   The test can be separated on two tests: one is Windows specific and 
>>> another is general.
>>> 
>>>   Thanks,
>>>   Alexandr.
 
> 
> On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:
>> Hello,
>> Please review the fix for jdk9.
>> 
>> Initially I found a typo in the HiDPIRobotMouseClick.java. It 
>> contains the «Dsun.java2d.win.uiScale» option, which should be 
>> Dsun.java2d.uiScale or Dsun.java2d.win.uiScaleX/Y.
>> But when I verified the fix, the test fails if executed w/o any 
>> options (my system has 125% DPI).
>> 
>> So I decided to update it and related HiDPIRobotScreenCaptureTest to 
>> validated more modes.
>> 
>> - Default(w/o options), useful if the system has some default scale.
>> - scale = 1 is useful when the tests are executed on HiDPI systems.
>> 
>> I am not sure why these tests sets the Windows L because it uses 
>> only awt Frame.  
>> I’ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177841 
>> 
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8177841/webrev.00 
>> 
 
>>> 
>> 
> 
 
>>> 
>> 
>

Re: [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

2017-04-07 Thread Semyon Sadetsky 

On 04/07/2017 04:42 AM, Sergey Bylokhov wrote:



6 апр. 2017 г., в 23:26, Semyon Sadetsky > написал(а):


On 04/06/2017 01:09 PM, Sergey Bylokhov wrote:


Sergey, could you replace CountDownLatch::await() call with its 
limited wait time analog. If the test fails it blocks execution for 
2 minutes in the current version.


2 minutes is a default time out for jtreg tests, if something goes 
wrong like something hangs, then we wait 2 minutes and interrupt the 
test.
After interruption the jtreg will generate the dump for all threads 
which can be useful to check why the event was not generated by the 
robot.
You are able to print out this useful information after timeout in 
the catch block.


We already have a mechanism which kills the tests after timeout, we 
also have a default timeout of 2 minutes.

I am not sure how to get dump of all threads from the catch block.
But shouldn't the time frame when a mouse click may come be limited? 
Will it be correct when the click triggered after 2 minutes delay makes 
the test passed anyway?


I would prefer to avoid any infinite waiting because if the listener 
is not triggered in several second it will unlikely be triggered at 
all. But if a number of such tests fails for some reason the 
execution time becomes so long that the test report cannot be 
obtained in a reasonable time.




On 04/06/2017 10:57 AM, Sergey Bylokhov wrote:

Here is an updated version:
http://cr.openjdk.java.net/~serb/8177841/webrev.01/ 

It will save 5 sec per test, so probably the simpler .00 version 
can be reevaluated.




On 3/30/2017 10:27 PM, Sergey Bylokhov wrote:
sun.java2d.win.uiScaleX/Y is only applicable to windows which 
is likely why the test had
@requires (os.family == "windows") even if it was not the right 
name. Now you are running unconditionally with those properties 
on all platforms which seems to be a waste of time.
Yes, if we know that uiScaleX/Y are windows specific then 2 
modes out of 5 is noop. But I do not like to exclude them, 
instead I would like to fuzz the tests by supported/unsupported 
properties, in the same way as 2d-tests are executed using 
different supported/unsupprted "sun.java2d.XXX" pipelines.
  The test can be separated on two tests: one is Windows specific 
and another is general.


  Thanks,
  Alexandr.




On 03/30/2017 12:11 PM, Sergey Bylokhov wrote:

Hello,
Please review the fix for jdk9.

Initially I found a typo in the HiDPIRobotMouseClick.java. It contains the 
«Dsun.java2d.win.uiScale» option, which should be Dsun.java2d.uiScale or 
Dsun.java2d.win.uiScaleX/Y.
But when I verified the fix, the test fails if executed w/o any options (my 
system has 125% DPI).

So I decided to update it and related HiDPIRobotScreenCaptureTest to validated 
more modes.

- Default(w/o options), useful if the system has some default scale.
- scale = 1 is useful when the tests are executed on HiDPI systems.

I am not sure why these tests sets the Windows L because it uses only awt 
Frame.
I’ll file a separate bug for HiDPIRobotMouseClick.java + 125% DPI.

Bug:https://bugs.openjdk.java.net/browse/JDK-8177841
Webrev can be found at:http://cr.openjdk.java.net/~serb/8177841/webrev.00