Re: [9] Review request for JDK-8165555: [macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent)

[Sergey Bylokhov]

Hi, Manajit.
It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance" 
returns the new object per invocation, so it is not really 
sharedInstance. I am not sure I understand what is wrong in the current 
code, from the my point of view this is a correct singleton. It it true 
that the problem is in access to broken "instance" and not to 
"javaToMacKeyMap" inside the "instance"? If not then "javaToMacKeyMap" 
should be changed to "self.javaToMacKeyMap".

Do you have a test case to reproduce the bug?

On 19.09.16 15:26, Manajit Halder wrote:

Hi All,

Kindly review the fix for JDK9.

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

Webrev:
http://cr.openjdk.java.net/~mhalder/816/webrev.00/

Issue:
[macosx] VM crashes on second attempt to execute JCK interactive tests
that use Robot (single JVM, agent)

Cause:
While executing the JCK test for the second time the robot was getting
initialised once again and old instance of CRobotKeyCodeMapping was not
available.
Crash was observed while trying to access invalid instance of
CRobotKeyCodeMapping.

Fix:
A new instance of CRobotKeyCodeMapping is created when robot is initialised.

Regards,
Manajit



--
Best regards, Sergey.

Re: Best workaround for OSX Window leak? (JDK-8029147)

[Sergey Bylokhov]

On 19.09.16 23:02, Andy Lee wrote:

In JDK 9 the problem seems to be partially fixed; only the most recently
closed JFrame leaks (ie, a temporary leak).  I was unable to get Visual
VM to connect to the Java 9 process so I'm not exactly sure what was
preventing the last JFrame from being GC'd.


Can you place the code which uses JFrame somewhere? It seems that some 
of the related bugs were not backported, like:

https://bugs.openjdk.java.net/browse/JDK-8156116

I will check which one.



The Java 9 behavior would be sufficient to solve most of our major
issues, but it will be quite some time before it becomes feasible to
move our application to Java 9 so it doesn't really help us.

On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
> wrote:

On 19.09.16 19:13, Andy Lee wrote:

Yes, I just tried my test case on JDK 8u112 and I can still
reproduce
the JFrame leak.


And what about the latest jdk9?
https://jdk9.java.net/download


On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov

>> wrote:

Hi, Andy.
I suggest to check the latest jdk9 and jdk8. Do you able to
reproduce this bug on jdk8u112?


On 19.09.16 17:19, Andy Lee wrote:

Not sure if this is the best place to ask, but I'm
looking for
good way
to prevent the JFrame/JDialog memory leaks caused
by https://bugs.openjdk.java.net/browse/JDK-8029147

>

The best solution I've found so far is to use reflection
to dig
in and
null out the 'target' fields on the LWComponentPeer and
CPlatformWindow
after disposing.  This at least allows the JDialog/JFrame
instance to be
GC'd (along with any heavier objects they may
reference), but isn't
optimal since ultimately the LWComponentPeer and
CPlatformWindow
instances still end up leaking.  Another problem with this
approach is
that we have hundreds of uses of JFrames/JDialogs across our
codebase
and this workaround would require each one of them to be
modified to add
this special cleanup logic; I'd like to avoid that if at all
possible~

Any suggestions?

~Andy Lee



--
Best regards, Sergey.




--
Best regards, Sergey.





--
Best regards, Sergey.

Re: Best workaround for OSX Window leak? (JDK-8029147)

[Andy Lee]

In JDK 9 the problem seems to be partially fixed; only the most recently
closed JFrame leaks (ie, a temporary leak).  I was unable to get Visual VM
to connect to the Java 9 process so I'm not exactly sure what was
preventing the last JFrame from being GC'd.

The Java 9 behavior would be sufficient to solve most of our major issues,
but it will be quite some time before it becomes feasible to move our
application to Java 9 so it doesn't really help us.

On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov  wrote:

> On 19.09.16 19:13, Andy Lee wrote:
>
>> Yes, I just tried my test case on JDK 8u112 and I can still reproduce
>> the JFrame leak.
>>
>
> And what about the latest jdk9?
> https://jdk9.java.net/download
>
>
>> On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>> > wrote:
>>
>> Hi, Andy.
>> I suggest to check the latest jdk9 and jdk8. Do you able to
>> reproduce this bug on jdk8u112?
>>
>>
>> On 19.09.16 17:19, Andy Lee wrote:
>>
>> Not sure if this is the best place to ask, but I'm looking for
>> good way
>> to prevent the JFrame/JDialog memory leaks caused
>> by https://bugs.openjdk.java.net/browse/JDK-8029147
>> 
>>
>> The best solution I've found so far is to use reflection to dig
>> in and
>> null out the 'target' fields on the LWComponentPeer and
>> CPlatformWindow
>> after disposing.  This at least allows the JDialog/JFrame
>> instance to be
>> GC'd (along with any heavier objects they may reference), but
>> isn't
>> optimal since ultimately the LWComponentPeer and CPlatformWindow
>> instances still end up leaking.  Another problem with this
>> approach is
>> that we have hundreds of uses of JFrames/JDialogs across our
>> codebase
>> and this workaround would require each one of them to be
>> modified to add
>> this special cleanup logic; I'd like to avoid that if at all
>> possible~
>>
>> Any suggestions?
>>
>> ~Andy Lee
>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>>
>>
>
> --
> Best regards, Sergey.
>

Re: [8u/9] Review request 8156116 : [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m

[Sergey Bylokhov]

Hi, Anton.
Should we backport it to jdk8u?

On 20.05.16 12:12, Anton Tarasov wrote:

Thank you!

Anton.


On 18 May 2016, at 18:54, Alexander Zvegintsev 
 wrote:

Looks fine to me too.

Thanks,

Alexander.

On 05/17/2016 06:36 PM, Anton Tarasov wrote:

Would anyone else please review the fix?

Thanks
Anton.

On 5/5/2016 12:45 PM, Sergey Bylokhov wrote:

Looks fine.

On 05.05.16 10:50, Anton Tarasov wrote:

Hello,

Please, review a simple fix:

webrev: http://cr.openjdk.java.net/~ant/JDK-8156116/jdk9/webrev.0
bug: https://bugs.openjdk.java.net/browse/JDK-8156116

Thanks,
Anton.












--
Best regards, Sergey.

Re: Best workaround for OSX Window leak? (JDK-8029147)

[Sergey Bylokhov]

On 19.09.16 19:13, Andy Lee wrote:

Yes, I just tried my test case on JDK 8u112 and I can still reproduce
the JFrame leak.


And what about the latest jdk9?
https://jdk9.java.net/download



On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
> wrote:

Hi, Andy.
I suggest to check the latest jdk9 and jdk8. Do you able to
reproduce this bug on jdk8u112?


On 19.09.16 17:19, Andy Lee wrote:

Not sure if this is the best place to ask, but I'm looking for
good way
to prevent the JFrame/JDialog memory leaks caused
by https://bugs.openjdk.java.net/browse/JDK-8029147


The best solution I've found so far is to use reflection to dig
in and
null out the 'target' fields on the LWComponentPeer and
CPlatformWindow
after disposing.  This at least allows the JDialog/JFrame
instance to be
GC'd (along with any heavier objects they may reference), but isn't
optimal since ultimately the LWComponentPeer and CPlatformWindow
instances still end up leaking.  Another problem with this
approach is
that we have hundreds of uses of JFrames/JDialogs across our
codebase
and this workaround would require each one of them to be
modified to add
this special cleanup logic; I'd like to avoid that if at all
possible~

Any suggestions?

~Andy Lee



--
Best regards, Sergey.





--
Best regards, Sergey.

Re: Best workaround for OSX Window leak? (JDK-8029147)

[Andy Lee]

Yes, I just tried my test case on JDK 8u112 and I can still reproduce the
JFrame leak.

On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov <
sergey.bylok...@oracle.com> wrote:

> Hi, Andy.
> I suggest to check the latest jdk9 and jdk8. Do you able to reproduce this
> bug on jdk8u112?
>
>
> On 19.09.16 17:19, Andy Lee wrote:
>
>> Not sure if this is the best place to ask, but I'm looking for good way
>> to prevent the JFrame/JDialog memory leaks caused
>> by https://bugs.openjdk.java.net/browse/JDK-8029147
>>
>> The best solution I've found so far is to use reflection to dig in and
>> null out the 'target' fields on the LWComponentPeer and CPlatformWindow
>> after disposing.  This at least allows the JDialog/JFrame instance to be
>> GC'd (along with any heavier objects they may reference), but isn't
>> optimal since ultimately the LWComponentPeer and CPlatformWindow
>> instances still end up leaking.  Another problem with this approach is
>> that we have hundreds of uses of JFrames/JDialogs across our codebase
>> and this workaround would require each one of them to be modified to add
>> this special cleanup logic; I'd like to avoid that if at all possible~
>>
>> Any suggestions?
>>
>> ~Andy Lee
>>
>
>
> --
> Best regards, Sergey.
>

Re: Best workaround for OSX Window leak? (JDK-8029147)

[Sergey Bylokhov]

Hi, Andy.
I suggest to check the latest jdk9 and jdk8. Do you able to reproduce 
this bug on jdk8u112?


On 19.09.16 17:19, Andy Lee wrote:

Not sure if this is the best place to ask, but I'm looking for good way
to prevent the JFrame/JDialog memory leaks caused
by https://bugs.openjdk.java.net/browse/JDK-8029147

The best solution I've found so far is to use reflection to dig in and
null out the 'target' fields on the LWComponentPeer and CPlatformWindow
after disposing.  This at least allows the JDialog/JFrame instance to be
GC'd (along with any heavier objects they may reference), but isn't
optimal since ultimately the LWComponentPeer and CPlatformWindow
instances still end up leaking.  Another problem with this approach is
that we have hundreds of uses of JFrames/JDialogs across our codebase
and this workaround would require each one of them to be modified to add
this special cleanup logic; I'd like to avoid that if at all possible~

Any suggestions?

~Andy Lee



--
Best regards, Sergey.

Best workaround for OSX Window leak? (JDK-8029147)

[Andy Lee]

Not sure if this is the best place to ask, but I'm looking for good way to
prevent the JFrame/JDialog memory leaks caused by
https://bugs.openjdk.java.net/browse/JDK-8029147

The best solution I've found so far is to use reflection to dig in and null
out the 'target' fields on the LWComponentPeer and CPlatformWindow after
disposing.  This at least allows the JDialog/JFrame instance to be GC'd
(along with any heavier objects they may reference), but isn't optimal
since ultimately the LWComponentPeer and CPlatformWindow instances still
end up leaking.  Another problem with this approach is that we have
hundreds of uses of JFrames/JDialogs across our codebase and this
workaround would require each one of them to be modified to add this
special cleanup logic; I'd like to avoid that if at all possible~

Any suggestions?

~Andy Lee

Re: Review request for JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java

[Semyon Sadetsky]

+1

--Semyon


On 9/19/2016 3:32 PM, Ajit Ghaisas wrote:


The fix looks good.

Regards,

Ajit

*From:* Ambarish Rapte
*Sent:* Monday, September 19, 2016 4:15 PM
*To:* Sergey Bylokhov; Semyon Sadetsky; Ajit Ghaisas; 
awt-dev@openjdk.java.net
*Subject:* Review request for JDK-8166015: [PIT][TEST_BUG] stray 
character in 
java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java


Hi,

Please review this test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/ 



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

Issue:An unwanted character causes compiler error.

Fix: Removed the character & did few small corrections as 
guidelines.


Regards,

Ambarish

Re: Review request for JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java

[Ajit Ghaisas]

The fix looks good.

 

Regards,

Ajit

 

From: Ambarish Rapte 
Sent: Monday, September 19, 2016 4:15 PM
To: Sergey Bylokhov; Semyon Sadetsky; Ajit Ghaisas; awt-dev@openjdk.java.net
Subject: Review request for JDK-8166015: [PIT][TEST_BUG] stray character in 
java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java

 

Hi,

 

Please review this test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/

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

 

 

Issue:An unwanted character causes compiler error.

Fix: Removed the character & did few small corrections as guidelines.

 

 

Regards,

Ambarish

 

[9] Review request for JDK-8165555: [macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent)

[Manajit Halder]

Hi All,

Kindly review the fix for JDK9.

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


Webrev: 
http://cr.openjdk.java.net/~mhalder/816/webrev.00/ 


Issue: 
[macosx] VM crashes on second attempt to execute JCK interactive tests that use 
Robot (single JVM, agent)

Cause: 
While executing the JCK test for the second time the robot was getting 
initialised once again and old instance of CRobotKeyCodeMapping was not 
available.
Crash was observed while trying to access invalid instance of 
CRobotKeyCodeMapping.

Fix: 
A new instance of CRobotKeyCodeMapping is created when robot is initialised.

Regards,
Manajit

Re: [9] Review Request for 8041519: JVM crash on second DnD after modal dialog opened during Swing DnD operation

[Alexander Zvegintsev]

Looks good to me.


On 7/17/15 7:27 PM, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8041519
webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/

This is regression from JDK-6342381. When a modal dialog blocks drop 
operation in progress state consequent mouse events clear the drop 
context variables (this clearing was introduced by JDK-6342381). The 
solution is to avoid clearing if drop operation is in progress.
Test scenario for this case would be too hard and unstable. Since the 
fix is pretty simple I left it as noreg.


--Semyon




--
Thanks,
Alexander.

Review request for JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java

[Ambarish Rapte]

Hi,

 

Please review this test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/

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

 

 

Issue:An unwanted character causes compiler error.

Fix: Removed the character & did few small corrections as guidelines.

 

 

Regards,

Ambarish

 

Re: [9] Review request for 8161910: [PIT] regression: HW/LW mixing seems broken on Unity

[Alexander Zvegintsev]

Looks good to me.


On 8/30/16 7:18 PM, Semyon Sadetsky wrote:

Sorry for inconvenience, but I have to update this fix once again.

http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.02

I have found the main root cause of the issue. In the 8036815 I have 
missed one insets_corrected = true; statement  in the RaparentNotify 
handler. In my new Unity algo for establishing frame dimensions the 
insets correction should be postponed until the frame extent property 
is set. This is corrected in the updated fix.


Also the frame insets correction optimization is restored with only 
one exclusion when the client area is not set to ensure that the 
target frame will receive the final size and location update.


--Semyon


On 8/24/2016 4:24 PM, Semyon Sadetsky wrote:
The fix was amended to 
http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/


Because Unity WM may change initial window location (for example when 
window overlaps desktop bars) I removed the optimization that skipped 
frame bounds revalidation in case of the initial frame insets was 
correct. This should guaranty the ConfigureNotify event always to 
come after the extent size event.


--Semyon

On 8/22/2016 9:19 PM, Semyon Sadetsky wrote:

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8161910

webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/

A regression of the 8036915 in which a new frame dimensioning algo 
was introduced for the Unity WM because the latter differs from 
other WMs a lot.  The algo has a flaw in some scenarios when the 
extent size event is delayed while the initial frame insets were 
established correctly, therefore the frame dimensions do not require 
any tuning. In this case the content window need to be notified 
right in the extent event handler to let the content to receive its 
new dimensions because subsequent XConfigureNotify event may be 
omitted.


--Semyon








--
Thanks,
Alexander.