From hs at tagtraum.com  Fri Aug  1 08:18:15 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 1 Aug 2014 10:18:15 +0200
Subject: Application name in About, Hide, and Quit menu items
Message-ID: <55EEE327-0590-48EF-96E8-2697B2443395@tagtraum.com>

Hi,

I'm bundling my app using the InfiniteKind AppBundler, which works great.

There is just a little discrepancy, I'm wondering about how to get rid off.

The application menu (right next to the Apple menu) is named the way I want it - not sure whether this is the app bundle's name or the CFBundleName from the Info.plist. Both are the same and that's fine.

However, in the application menu there are the items "About <APPNAME>", "Hide <APPNAME>", and "Quit <APPNAME>".
All of them are not set to the bundle name, but to the main classname. So the application menu looks like this:

[BundleName]
[About Classname]
[Hide Classname]
...
[Quit Classname]

In my case BundleName and Classname are not identical.

I'm under the impression that the classname is set by the JVM, as only the fully qualified classname is passed into jli_LaunchFxnPtr. The bundle name on the other hand, seems to be set some other way.

Is there a way to make sure that the About, Hide, and Quit menu items are also set to the bundle name, without having to change the classname?

Or in other words: wouldn't it make sense, to always make sure that the appname used in About, Hide, and Quit matches the name of the Application menu, i.e. the bundle name?

Cheers,

-hendrik

From Sergey.Bylokhov at oracle.com  Fri Aug  1 12:08:51 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 01 Aug 2014 16:08:51 +0400
Subject: FW: A small Aqua Swing bug report--how/where to file?
In-Reply-To: <CFE57599.334DF%ebakke@mit.edu>
References: <CFDC49EF.3327F%ebakke@mit.edu> <CFE57599.334DF%ebakke@mit.edu>
Message-ID: <53DB8353.2070903@oracle.com>

Hello, Erik.
What version of jdk did you use? Can you check it on the latest version 
of jdk 8u20?
https://jdk8.java.net/download.html
Thanks.

On 7/11/14 7:12 PM, Eirik Bakke wrote:
> (Resending without image attachment--I don't think my first message got
> through.)
>
> I have a small bug to file against the Aqua L&F in OpenJDK. What's the
> place/procedure for filing such bugs? (It seems that
> https://bugs.openjdk.java.net/browse/JDK does not permit the general
> public to create new bugs, and I'm not sure if it's the place for
> Aqua-related bugs either.)
>
> The bug is a variation of bug #5046173 mentioned in [1], "JTextFields had
> clipped focus rings". The aforementioned bug was partially resolved, but
> is still present in cases where the JTextField has the
> "JTextField.variant" client property set to "search". A minimal example is
> provided in [2]; when run on MacOS and the text field is in focus, text
> field is clipped by one or two pixels on all four sides (though you have
> to look closely to see it).
>
> -- Eirik
>
> [1]
> http://www.filibeto.org/unix/macos/lib/dev/releasenotes/Java/JavaLeopardRN/
> JavaLeopardRN.pdf
> [2] https://gist.github.com/anonymous/662976ce8f6a942a3b9b
>


-- 
Best regards, Sergey.


From philip.race at oracle.com  Fri Aug  1 13:24:57 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 01 Aug 2014 06:24:57 -0700
Subject: FW: A small Aqua Swing bug report--how/where to file?
In-Reply-To: <53DB8353.2070903@oracle.com>
References: <CFDC49EF.3327F%ebakke@mit.edu> <CFE57599.334DF%ebakke@mit.edu>
	<53DB8353.2070903@oracle.com>
Message-ID: <53DB9529.9000209@oracle.com>

.. and bugs can be filed here :- http://bugreport.java.com/bugreport/

-phil.

On 8/1/14 5:08 AM, Sergey Bylokhov wrote:
> Hello, Erik.
> What version of jdk did you use? Can you check it on the latest 
> version of jdk 8u20?
> https://jdk8.java.net/download.html
> Thanks.
>
> On 7/11/14 7:12 PM, Eirik Bakke wrote:
>> (Resending without image attachment--I don't think my first message got
>> through.)
>>
>> I have a small bug to file against the Aqua L&F in OpenJDK. What's the
>> place/procedure for filing such bugs? (It seems that
>> https://bugs.openjdk.java.net/browse/JDK does not permit the general
>> public to create new bugs, and I'm not sure if it's the place for
>> Aqua-related bugs either.)
>>
>> The bug is a variation of bug #5046173 mentioned in [1], "JTextFields 
>> had
>> clipped focus rings". The aforementioned bug was partially resolved, but
>> is still present in cases where the JTextField has the
>> "JTextField.variant" client property set to "search". A minimal 
>> example is
>> provided in [2]; when run on MacOS and the text field is in focus, text
>> field is clipped by one or two pixels on all four sides (though you have
>> to look closely to see it).
>>
>> -- Eirik
>>
>> [1]
>> http://www.filibeto.org/unix/macos/lib/dev/releasenotes/Java/JavaLeopardRN/ 
>>
>> JavaLeopardRN.pdf
>> [2] https://gist.github.com/anonymous/662976ce8f6a942a3b9b
>>
>
>


From ebakke at MIT.EDU  Fri Aug  1 14:57:04 2014
From: ebakke at MIT.EDU (Eirik Bakke)
Date: Fri, 1 Aug 2014 14:57:04 +0000
Subject: A small Aqua Swing bug report--how/where to file?
Message-ID: <D001218A.33C6D%ebakke@mit.edu>

I saw the bug in 1.8.0_20-ea-b05, but now tried the latest version
1.8.0_20-ea-b23 from the site you linked, and the bug is gone! (I compared
it side-by-side with the screenshot I took on the previous version.)

Great--thanks!

-- Eirik

On 8/1/14, 8:08 AM, "Sergey Bylokhov" <Sergey.Bylokhov at oracle.com> wrote:

>Hello, Erik.
>What version of jdk did you use? Can you check it on the latest version
>of jdk 8u20?
>https://jdk8.java.net/download.html
>Thanks.
>
>On 7/11/14 7:12 PM, Eirik Bakke wrote:
>> (Resending without image attachment--I don't think my first message got
>> through.)
>>
>> I have a small bug to file against the Aqua L&F in OpenJDK. What's the
>> place/procedure for filing such bugs? (It seems that
>> https://bugs.openjdk.java.net/browse/JDK does not permit the general
>> public to create new bugs, and I'm not sure if it's the place for
>> Aqua-related bugs either.)
>>
>> The bug is a variation of bug #5046173 mentioned in [1], "JTextFields
>>had
>> clipped focus rings". The aforementioned bug was partially resolved, but
>> is still present in cases where the JTextField has the
>> "JTextField.variant" client property set to "search". A minimal example
>>is
>> provided in [2]; when run on MacOS and the text field is in focus, text
>> field is clipped by one or two pixels on all four sides (though you have
>> to look closely to see it).
>>
>> -- Eirik
>>
>> [1]
>> 
>>http://www.filibeto.org/unix/macos/lib/dev/releasenotes/Java/JavaLeopardR
>>N/
>> JavaLeopardRN.pdf
>> [2] https://gist.github.com/anonymous/662976ce8f6a942a3b9b
>>
>
>
>-- 
>Best regards, Sergey.
>


From sreilly at seanreilly.com  Fri Aug  1 16:29:15 2014
From: sreilly at seanreilly.com (Sean Reilly)
Date: Fri, 1 Aug 2014 12:29:15 -0400
Subject: Application name in About, Hide, and Quit menu items
Message-ID: <072D6774-10B3-427E-BCCF-6B6581C92A1D@seanreilly.com>

Hi Hendrik,

In my app bundle ant file I?ve set a few options with the <bundleapp> tag including these:
          <option value="-Dcom.apple.mrj.application.apple.menu.about.name=${bundle.name}"/>
          <option value="-Dapple.awt.application.name=${bundle.name}"/>

Maybe they will help in your case?

I agree that it would make sense to use the bundle name, at least as a default.  If you get a chance to correct it, please feel free to fork it and send a pull request: http://bitbucket.org/infinitekind/appbundler

Cheers,
Sean


> Hi,
> 
> I'm bundling my app using the InfiniteKind AppBundler, which works great.
> 
> There is just a little discrepancy, I'm wondering about how to get rid off.
> 
> The application menu (right next to the Apple menu) is named the way I want it - not sure whether this is the app bundle's name or the CFBundleName from the Info.plist. Both are the same and that's fine.
> 
> However, in the application menu there are the items "About <APPNAME>", "Hide <APPNAME>", and "Quit <APPNAME>".
> All of them are not set to the bundle name, but to the main classname. So the application menu looks like this:
> 
> [BundleName]
> [About Classname]
> [Hide Classname]
> ...
> [Quit Classname]
> 
> In my case BundleName and Classname are not identical.
> 
> I'm under the impression that the classname is set by the JVM, as only the fully qualified classname is passed into jli_LaunchFxnPtr. The bundle name on the other hand, seems to be set some other way.
> 
> Is there a way to make sure that the About, Hide, and Quit menu items are also set to the bundle name, without having to change the classname?
> 
> Or in other words: wouldn't it make sense, to always make sure that the appname used in About, Hide, and Quit matches the name of the Application menu, i.e. the bundle name?
> 
> Cheers,
> 
> -hendrik



--
Sean Reilly
infinitekind.com





From florian.bruckner at 3kraft.com  Mon Aug  4 15:40:12 2014
From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft))
Date: Mon, 04 Aug 2014 17:40:12 +0200
Subject: java2d performance java7 / java8
Message-ID: <53DFA95C.6040507@3kraft.com>

Hi,

to start with a disclaimer: I know that this list is not for end user support - I'm not looking for 
support but would like to offer my help in fixing an issue with graphics performance on osx.

With java6, graphics performance was fine on my MacBook Pro Early 2011. Starting with Java7, 
graphics performance has been worse by an order of a magnitude, and it is even getting worse with a 
big screen attached (2560x1440). There also seems to be a dependency on the number of java processes 
running. For example running NetBeans on the big screen in that configuration with java7 or java8 is 
just slow but still usable, it starts to become a nightmare if SQLDeveloper is started at the same 
time. If just enough java processes are launched it gets as bad as a full lockup, only a hard reset 
would help in that case.

If this had been the case with java6 as well I would not be concerned and just jump over to an apple 
store to get a new machine. The interesting part is that with java6 everything is fine, but not with 
java7+.

Browsing through JIRA and NetBeans Bugzilla, I have found this ticket that may be related to this: 
https://bugs.openjdk.java.net/browse/JDK-8029253

Note that this talks about a retina display (which my machine does not have). Running OpenGL 
profiler on my machine exhibits at least similar data to the data attached to the ticket. So there 
seems to be a dependency on the screen resolution.

Another note here is that also JFX on java7 influences performance/exhibits bad performance (which, 
to my knowledge, should not use Java2D, but maybe the backend implementation is the same?)

Are you guys aware of a performance regression from java6 on osx? Is this something you think is 
worth investigating?

If yes - I can offer systematic testing on a range of different MBP models, starting with 
pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get comparable 
results. Building and modifying the rendering pipeline is unfortunately beyond my capabilities (at 
least without your support).

Just let me know what you think.

thanks and regards,

Florian

From tobi at ultramixer.com  Tue Aug  5 07:32:24 2014
From: tobi at ultramixer.com (Tobias Bley)
Date: Tue, 5 Aug 2014 09:32:24 +0200
Subject: java2d performance java7 / java8
In-Reply-To: <53DFA95C.6040507@3kraft.com>
References: <53DFA95C.6040507@3kraft.com>
Message-ID: <B24C511E-BB1D-40F9-BDF7-859108A81423@ultramixer.com>

Hi,

I?m glad to see that you fetch this topic again? 

I try to summarise the bug:

Starting with JDK7 Apples Quartz based rendering pipeline isn?t available anymore. So JDK7 and higher uses the OpenGL based pipeline on MacOSX. After hours of analysing my conclusion is that BufferedImage isn?t implemented via VolatileImage anymore (but it was in Apples JDK6). 

So if you render BufferedImages in JDK7/8/9 the rendering performance is very slow. The only solution right now is to use VolatileImages directly.

So what?s missing in JDK7/8/9 is the VolatileImage based implementation of BufferedImages?.This leads to an unusable JDK on Mac OS X right now. By the way: That?s the reason why big Java based desktop software like IntelliJ doesn?t provide a JRE 7/8 bundle IntelliJ for Mac OS X at the moment?

So my conclusion is: JDK7 and JDK8 are not in beta stage and not finished on Mac OS X! I don?t understand why Oracle has released it as ready?.

Hope to see a solution in the near future, otherwise we can?t use Java Swing on Desktop on Mac OS X anymore?

Best regards,
Tobi



> Am 04.08.2014 um 17:40 schrieb Florian Bruckner (3kraft) <florian.bruckner at 3kraft.com>:
> 
> Hi,
> 
> to start with a disclaimer: I know that this list is not for end user support - I'm not looking for support but would like to offer my help in fixing an issue with graphics performance on osx.
> 
> With java6, graphics performance was fine on my MacBook Pro Early 2011. Starting with Java7, graphics performance has been worse by an order of a magnitude, and it is even getting worse with a big screen attached (2560x1440). There also seems to be a dependency on the number of java processes running. For example running NetBeans on the big screen in that configuration with java7 or java8 is just slow but still usable, it starts to become a nightmare if SQLDeveloper is started at the same time. If just enough java processes are launched it gets as bad as a full lockup, only a hard reset would help in that case.
> 
> If this had been the case with java6 as well I would not be concerned and just jump over to an apple store to get a new machine. The interesting part is that with java6 everything is fine, but not with java7+.
> 
> Browsing through JIRA and NetBeans Bugzilla, I have found this ticket that may be related to this: https://bugs.openjdk.java.net/browse/JDK-8029253
> 
> Note that this talks about a retina display (which my machine does not have). Running OpenGL profiler on my machine exhibits at least similar data to the data attached to the ticket. So there seems to be a dependency on the screen resolution.
> 
> Another note here is that also JFX on java7 influences performance/exhibits bad performance (which, to my knowledge, should not use Java2D, but maybe the backend implementation is the same?)
> 
> Are you guys aware of a performance regression from java6 on osx? Is this something you think is worth investigating?
> 
> If yes - I can offer systematic testing on a range of different MBP models, starting with pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get comparable results. Building and modifying the rendering pipeline is unfortunately beyond my capabilities (at least without your support).
> 
> Just let me know what you think.
> 
> thanks and regards,
> 
> Florian


From Sergey.Bylokhov at oracle.com  Tue Aug  5 13:37:19 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 05 Aug 2014 17:37:19 +0400
Subject: java2d performance java7 / java8
In-Reply-To: <53DFA95C.6040507@3kraft.com>
References: <53DFA95C.6040507@3kraft.com>
Message-ID: <53E0DE0F.5070507@oracle.com>

Hi, Florian.
On 04.08.2014 19:40, Florian Bruckner (3kraft) wrote:
> Are you guys aware of a performance regression from java6 on osx? Is 
> this something you think is worth investigating?
>
> If yes - I can offer systematic testing on a range of different MBP 
> models, starting with pre-unibody MBP up until quite recent retina 
> MBPs, all attached to the same screen to get comparable results. 
> Building and modifying the rendering pipeline is unfortunately beyond 
> my capabilities (at least without your support).
Yes, we already have some reports on this problem, but not all of them 
can be reproduced by us locally.
It would be good to find the bottleneck using a native profilers(ex 
TimeProfiler which is part of XCode), on different systems with 
different video cards/screen size.
In your case would be good to know the differences in profiler results 
between before/after SQLDeveloper is started.
>
> thanks and regards,
>
> Florian


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Aug  5 13:39:17 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 05 Aug 2014 17:39:17 +0400
Subject: java2d performance java7 / java8
In-Reply-To: <B24C511E-BB1D-40F9-BDF7-859108A81423@ultramixer.com>
References: <53DFA95C.6040507@3kraft.com>
	<B24C511E-BB1D-40F9-BDF7-859108A81423@ultramixer.com>
Message-ID: <53E0DE85.2080701@oracle.com>

Hi, Tobias.
Can you share the test case, which will show that a BufferedImage is not 
cached using VI.

On 05.08.2014 11:32, Tobias Bley wrote:
> ?
>
> So my conclusion is: JDK7 and JDK8 are not in beta stage and not finished on Mac OS X! I don?t understand why Oracle has released it as ready?.
>
> Hope to see a solution in the near future, otherwise we can?t use Java Swing on Desktop on Mac OS X anymore?
>
> Best regards,
> Tobi
>
>
>
>> Am 04.08.2014 um 17:40 schrieb Florian Bruckner (3kraft) <florian.bruckner at 3kraft.com>:
>>
>> Hi,
>>
>> to start with a disclaimer: I know that this list is not for end user support - I'm not looking for support but would like to offer my help in fixing an issue with graphics performance on osx.
>>
>> With java6, graphics performance was fine on my MacBook Pro Early 2011. Starting with Java7, graphics performance has been worse by an order of a magnitude, and it is even getting worse with a big screen attached (2560x1440). There also seems to be a dependency on the number of java processes running. For example running NetBeans on the big screen in that configuration with java7 or java8 is just slow but still usable, it starts to become a nightmare if SQLDeveloper is started at the same time. If just enough java processes are launched it gets as bad as a full lockup, only a hard reset would help in that case.
>>
>> If this had been the case with java6 as well I would not be concerned and just jump over to an apple store to get a new machine. The interesting part is that with java6 everything is fine, but not with java7+.
>>
>> Browsing through JIRA and NetBeans Bugzilla, I have found this ticket that may be related to this: https://bugs.openjdk.java.net/browse/JDK-8029253
>>
>> Note that this talks about a retina display (which my machine does not have). Running OpenGL profiler on my machine exhibits at least similar data to the data attached to the ticket. So there seems to be a dependency on the screen resolution.
>>
>> Another note here is that also JFX on java7 influences performance/exhibits bad performance (which, to my knowledge, should not use Java2D, but maybe the backend implementation is the same?)
>>
>> Are you guys aware of a performance regression from java6 on osx? Is this something you think is worth investigating?
>>
>> If yes - I can offer systematic testing on a range of different MBP models, starting with pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get comparable results. Building and modifying the rendering pipeline is unfortunately beyond my capabilities (at least without your support).
>>
>> Just let me know what you think.
>>
>> thanks and regards,
>>
>> Florian


-- 
Best regards, Sergey.


From tobi at ultramixer.com  Tue Aug  5 18:42:54 2014
From: tobi at ultramixer.com (Tobias Bley)
Date: Tue, 5 Aug 2014 20:42:54 +0200
Subject: java2d performance java7 / java8
In-Reply-To: <53E0DE85.2080701@oracle.com>
References: <53DFA95C.6040507@3kraft.com>
	<B24C511E-BB1D-40F9-BDF7-859108A81423@ultramixer.com>
	<53E0DE85.2080701@oracle.com>
Message-ID: <B0DB7E67-9D28-43C3-B54D-B73F6FC6A254@ultramixer.com>

Hi,

I have no test case, I can only show you our software which renders slow when using BufferedImages and which renders fast when using VolatileImages on JDK7/8/9.

Additionally I recently found that it renders faster when using BufferedImages and setting property ?-Dswing.volatileImageBufferEnabled=false? to false?

Best regards,
Tobi


> Am 05.08.2014 um 15:39 schrieb Sergey Bylokhov <sergey.bylokhov at oracle.com>:
> 
> Hi, Tobias.
> Can you share the test case, which will show that a BufferedImage is not cached using VI.
> 
> On 05.08.2014 11:32, Tobias Bley wrote:
>> ?
>> 
>> So my conclusion is: JDK7 and JDK8 are not in beta stage and not finished on Mac OS X! I don?t understand why Oracle has released it as ready?.
>> 
>> Hope to see a solution in the near future, otherwise we can?t use Java Swing on Desktop on Mac OS X anymore?
>> 
>> Best regards,
>> Tobi
>> 
>> 
>> 
>>> Am 04.08.2014 um 17:40 schrieb Florian Bruckner (3kraft) <florian.bruckner at 3kraft.com>:
>>> 
>>> Hi,
>>> 
>>> to start with a disclaimer: I know that this list is not for end user support - I'm not looking for support but would like to offer my help in fixing an issue with graphics performance on osx.
>>> 
>>> With java6, graphics performance was fine on my MacBook Pro Early 2011. Starting with Java7, graphics performance has been worse by an order of a magnitude, and it is even getting worse with a big screen attached (2560x1440). There also seems to be a dependency on the number of java processes running. For example running NetBeans on the big screen in that configuration with java7 or java8 is just slow but still usable, it starts to become a nightmare if SQLDeveloper is started at the same time. If just enough java processes are launched it gets as bad as a full lockup, only a hard reset would help in that case.
>>> 
>>> If this had been the case with java6 as well I would not be concerned and just jump over to an apple store to get a new machine. The interesting part is that with java6 everything is fine, but not with java7+.
>>> 
>>> Browsing through JIRA and NetBeans Bugzilla, I have found this ticket that may be related to this: https://bugs.openjdk.java.net/browse/JDK-8029253
>>> 
>>> Note that this talks about a retina display (which my machine does not have). Running OpenGL profiler on my machine exhibits at least similar data to the data attached to the ticket. So there seems to be a dependency on the screen resolution.
>>> 
>>> Another note here is that also JFX on java7 influences performance/exhibits bad performance (which, to my knowledge, should not use Java2D, but maybe the backend implementation is the same?)
>>> 
>>> Are you guys aware of a performance regression from java6 on osx? Is this something you think is worth investigating?
>>> 
>>> If yes - I can offer systematic testing on a range of different MBP models, starting with pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get comparable results. Building and modifying the rendering pipeline is unfortunately beyond my capabilities (at least without your support).
>>> 
>>> Just let me know what you think.
>>> 
>>> thanks and regards,
>>> 
>>> Florian
> 
> 
> -- 
> Best regards, Sergey.
> 


From florian.bruckner at 3kraft.com  Thu Aug  7 08:48:33 2014
From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft))
Date: Thu, 07 Aug 2014 10:48:33 +0200
Subject: java2d performance java7 / java8
In-Reply-To: <53E0DE0F.5070507@oracle.com>
References: <53DFA95C.6040507@3kraft.com> <53E0DE0F.5070507@oracle.com>
Message-ID: <53E33D61.50202@3kraft.com>

Hi Sergey,

what a timing - while preparing for some test runs, my big screen died.

I am waiting for a replacement to arrive and will then continue with testing, but this may take 
another week or so.

with best regards,

Florian

On 05.08.14 15:37, Sergey Bylokhov wrote:
> Hi, Florian.
> On 04.08.2014 19:40, Florian Bruckner (3kraft) wrote:
>> Are you guys aware of a performance regression from java6 on osx? Is this something you think is 
>> worth investigating?
>>
>> If yes - I can offer systematic testing on a range of different MBP models, starting with 
>> pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get 
>> comparable results. Building and modifying the rendering pipeline is unfortunately beyond my 
>> capabilities (at least without your support).
> Yes, we already have some reports on this problem, but not all of them can be reproduced by us 
> locally.
> It would be good to find the bottleneck using a native profilers(ex TimeProfiler which is part of 
> XCode), on different systems with different video cards/screen size.
> In your case would be good to know the differences in profiler results between before/after 
> SQLDeveloper is started.
>>
>> thanks and regards,
>>
>> Florian
>
>


From dcommander at users.sourceforge.net  Thu Aug  7 09:07:29 2014
From: dcommander at users.sourceforge.net (DRC)
Date: Thu, 07 Aug 2014 04:07:29 -0500
Subject: Java 2D drawing performance is 5x slower with Java 7 than with Java
	6 on OS X
Message-ID: <53E341D1.3060707@users.sourceforge.net>

I have an app that does a fairly simple image drawing operation in Java 
2D.  When I run the app under Java 6 (from the Apple Java Developer 
package), it draws at about 130 Mpixels/sec.  When I run the same app 
under either Oracle JDK 7 or my own build of OpenJDK 7 (from the 
macosx-port-dev Mercurial branch), it draws at about 20 Mpixels/sec.

You can build enough of the app to demonstrate this issue by doing:

   svn co svn://svn.code.sf.net/p/turbovnc/code/trunk/java java
   cd java
   javac com/turbovnc/vncviewer/ImageDrawTest.java
   java -Dsun.java2d.trace=count -cp . com.turbovnc.vncviewer.ImageDrawTest

Results from Java 6:
--------------------

Graphics device supports HW acceleration.
Window size: 1240 x 900
129.607164 Mpixels/sec
130.089516 Mpixels/sec
4768 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre)

Results from Java 7:
--------------------

Graphics device supports HW acceleration.
Window size: 1240 x 900
19.109939 Mpixels/sec
20.604652 Mpixels/sec
19.849651 Mpixels/sec
316 calls to sun.java2d.opengl.OGLSwToSurfaceBlit::Blit(IntRgb, 
AnyAlpha, "OpenGL Surface")
2 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
317 calls to sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit("OpenGL 
Surface (render-to-texture)", AnyAlpha, "OpenGL Surface")
6 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
641 total calls to 4 different primitives

It seems clear that Java 7 is using OpenGL by default to implement Java 
2D drawing, and this path is apparently slow on my machine (probably 
others as well.  I'm using a Mac Mini with nVidia GeForce 9400 and OS X 
10.8.5.)  But there appears to be no way to get back the faster loops 
that were used in Java 6.  I'd love to be able to just do 
-Dsun.java2d.opengl=false, but no luck there.  If I could figure out how 
to make the OpenGL drawing faster, that would be acceptable as well.

Any help is greatly appreciated.

From florian.bruckner at 3kraft.com  Mon Aug 18 14:05:13 2014
From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft))
Date: Mon, 18 Aug 2014 16:05:13 +0200
Subject: java2d performance java7 / java8
In-Reply-To: <53E0DE0F.5070507@oracle.com>
References: <53DFA95C.6040507@3kraft.com> <53E0DE0F.5070507@oracle.com>
Message-ID: <53F20819.2020300@3kraft.com>

Hi Sergey,

I have built a minimalistic test case that exposes the problem. It creates a JFrame with an editor 
pane in it to show some HTML content (a javadoc page). The test is to just scroll from the bottom to 
the top and back to the bottom by mouse wheel as quickly as possible, I did 5 iterations in each 
test run.

Wall clock timing was approx. 15 seconds with Java 6 and approx 45 seconds with java 8. As the 
problem worsens with increased screen resolutions I decided to use the full resolution of my new UHD 
display (which is 3840x2160), the machine is a

MacBook Pro
15-inch, Early 2011
Processor  2 GHz Intel Core i7
Memory  16 GB 1333 MHz DDR3
Graphics  AMD Radeon HD 6490M 256 MB
Software  OS X 10.9.4 (13E28)

These are the java versions:

$ java -version
java version "1.8.0_11"
Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)

$ /System/Library/Frameworks/JavaVM.framework/Home/bin/java -version
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

With java 6, the application felt agile and responding, whereas with java 8 it was barely usable.

Attachments were rejected from the list, therefore I have uploaded them to our web storage (this 
link expires Aug 31st):

https://owncloud.3kraft.com/public.php?service=files&t=ae0f609d6bd42b27a5ea38261507a38c

Please let me know if those results are usable for you.

regards,

Florian

On 05.08.14 15:37, Sergey Bylokhov wrote:
> Hi, Florian.
> On 04.08.2014 19:40, Florian Bruckner (3kraft) wrote:
>> Are you guys aware of a performance regression from java6 on osx? Is this something you think is
>> worth investigating?
>>
>> If yes - I can offer systematic testing on a range of different MBP models, starting with
>> pre-unibody MBP up until quite recent retina MBPs, all attached to the same screen to get
>> comparable results. Building and modifying the rendering pipeline is unfortunately beyond my
>> capabilities (at least without your support).
> Yes, we already have some reports on this problem, but not all of them can be reproduced by us
> locally.
> It would be good to find the bottleneck using a native profilers(ex TimeProfiler which is part of
> XCode), on different systems with different video cards/screen size.
> In your case would be good to know the differences in profiler results between before/after
> SQLDeveloper is started.
>>
>> thanks and regards,
>>
>> Florian
>
>

From dcommander at users.sourceforge.net  Mon Aug 18 14:16:57 2014
From: dcommander at users.sourceforge.net (DRC)
Date: Mon, 18 Aug 2014 09:16:57 -0500
Subject: java2d performance java7 / java8
In-Reply-To: <53F20819.2020300@3kraft.com>
References: <53DFA95C.6040507@3kraft.com> <53E0DE0F.5070507@oracle.com>
	<53F20819.2020300@3kraft.com>
Message-ID: <53F20AD9.6040201@users.sourceforge.net>

I am wondering if this is the same issue I'm experiencing:

http://mail.openjdk.java.net/pipermail/macosx-port-dev/2014-August/006700.html

If so, it's because Java 7 and later are defaulting to OpenGL drawing on 
Macs, which is slow, and there appears to be no way to change this 
behavior.  Java 6 uses some other form of drawing.  This can be revealed 
by adding -Dsun.java2d.trace=count to the java command line and noting 
the differences in the output between Java 6 and Java 7/8.


On 8/18/14 9:05 AM, Florian Bruckner (3kraft) wrote:
> Hi Sergey,
>
> I have built a minimalistic test case that exposes the problem. It
> creates a JFrame with an editor pane in it to show some HTML content (a
> javadoc page). The test is to just scroll from the bottom to the top and
> back to the bottom by mouse wheel as quickly as possible, I did 5
> iterations in each test run.
>
> Wall clock timing was approx. 15 seconds with Java 6 and approx 45
> seconds with java 8. As the problem worsens with increased screen
> resolutions I decided to use the full resolution of my new UHD display
> (which is 3840x2160), the machine is a
>
> MacBook Pro
> 15-inch, Early 2011
> Processor  2 GHz Intel Core i7
> Memory  16 GB 1333 MHz DDR3
> Graphics  AMD Radeon HD 6490M 256 MB
> Software  OS X 10.9.4 (13E28)
>
> These are the java versions:
>
> $ java -version
> java version "1.8.0_11"
> Java(TM) SE Runtime Environment (build 1.8.0_11-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode)
>
> $ /System/Library/Frameworks/JavaVM.framework/Home/bin/java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>
> With java 6, the application felt agile and responding, whereas with
> java 8 it was barely usable.
>
> Attachments were rejected from the list, therefore I have uploaded them
> to our web storage (this link expires Aug 31st):
>
> https://owncloud.3kraft.com/public.php?service=files&t=ae0f609d6bd42b27a5ea38261507a38c
>
>
> Please let me know if those results are usable for you.
>
> regards,
>
> Florian

From hs at tagtraum.com  Thu Aug 21 08:10:52 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 21 Aug 2014 10:10:52 +0200
Subject: Crash in Java2D Queue Flusher, OGLSD_SetScratchSurface
Message-ID: <8CEBBD73-73BD-4D5A-B712-2C3CB576EE7C@tagtraum.com>

Hey,

I was wondering what is the best way to submit crash logs of non-repeatable VM crashes?

E.g. I have this crash log containing:

OS Version:      Mac OS X 10.9.4 (13E28)

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

[...]

Thread 24:: Java: AWT-Shutdown
0   libsystem_kernel.dylib        	0x00007fff96923716 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff8eeeec3b _pthread_cond_wait + 727
2   libjvm.dylib                  	0x00000001047ca2c8 os::PlatformEvent::park() + 192
3   libjvm.dylib                  	0x00000001047c2c2e ObjectMonitor::wait(long, bool, Thread*) + 748
4   libjvm.dylib                  	0x0000000104875a40 ObjectSynchronizer::wait(Handle, long, Thread*) + 202
5   libjvm.dylib                  	0x000000010469cd44 JVM_MonitorWait + 156
6   ???                           	0x0000000105c175a8 0 + 4391531944
7   ???                           	0x00000001066d0204 0 + 4402774532
8   ???                           	0x00000001054069d2 0 + 4383074770
9   ???                           	0x00000001053ff4e7 0 + 4383044839
10  libjvm.dylib                  	0x00000001046452ce JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710
11  libjvm.dylib                  	0x0000000104645a5c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356
12  libjvm.dylib                  	0x0000000104645c08 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
13  libjvm.dylib                  	0x000000010469665b thread_entry(JavaThread*, Thread*) + 124
14  libjvm.dylib                  	0x00000001048a6a81 JavaThread::thread_main_inner() + 155
15  libjvm.dylib                  	0x00000001048a81c4 JavaThread::run() + 450
16  libjvm.dylib                  	0x00000001047ce38a java_start(Thread*) + 246
17  libsystem_pthread.dylib       	0x00007fff8eeec899 _pthread_body + 138
18  libsystem_pthread.dylib       	0x00007fff8eeec72a _pthread_start + 137
19  libsystem_pthread.dylib       	0x00007fff8eef0fc9 thread_start + 13

Thread 25 Crashed:: Java: Java2D Queue Flusher
0   libsystem_kernel.dylib        	0x00007fff96923866 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff8eeed35c pthread_kill + 92
2   libsystem_c.dylib             	0x00007fff8e64bb1a abort + 125
3   libjvm.dylib                  	0x00000001047cdb37 os::abort(bool) + 25
4   libjvm.dylib                  	0x00000001048e9d56 VMError::report_and_die() + 2260
5   libjvm.dylib                  	0x00000001047cf6aa JVM_handle_bsd_signal + 1131
6   libjvm.dylib                  	0x00000001047cbb6b signalHandler(int, __siginfo*, void*) + 47
7   libsystem_platform.dylib      	0x00007fff952f75aa _sigtramp + 26
8   libawt_lwawt.dylib            	0x00000001220044cc OGLSD_SetScratchSurface + 51
9   libawt_lwawt.dylib            	0x00000001220245ae Java_sun_java2d_opengl_OGLRenderQueue_flushBuffer + 1594
10  ???                           	0x0000000106786d6a 0 + 4403522922
11  ???                           	0x0000000107a84a24 0 + 4423436836

[...]

Thread 25 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000124fce000  rcx: 0x0000000124fccef8  rdx: 0x0000000000000000
  rdi: 0x000000000000d307  rsi: 0x0000000000000006  rbp: 0x0000000124fccf20  rsp: 0x0000000124fccef8
   r8: 0x0000000000000040   r9: 0x0000000124fcce00  r10: 0x0000000008000000  r11: 0x0000000000000206
  r12: 0x0000000104c29270  r13: 0x00000006c05a5570  r14: 0x0000000000000006  r15: 0x00000001047d2ed4
  rip: 0x00007fff96923866  rfl: 0x0000000000000206  cr2: 0x0000000124ecb068
  
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133

[...]

The full log is at http://www.beatunes.com/download/ogl.crash

There seems to be something wrong with OGLSD_SetScratchSurface, but I have no way to reproduce this.
This happened with the last 1.8.0_20-ea before the actual release of U20.

Is this something you are interested in looking into, or should I just file a bug report at Oracle?

Cheers,

-hendrik

From hs at tagtraum.com  Fri Aug 22 09:56:06 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 22 Aug 2014 11:56:06 +0200
Subject: Crash in Java2D Queue Flusher, OGLSD_SetScratchSurface
In-Reply-To: <8CEBBD73-73BD-4D5A-B712-2C3CB576EE7C@tagtraum.com>
References: <8CEBBD73-73BD-4D5A-B712-2C3CB576EE7C@tagtraum.com>
Message-ID: <7BB5FFAE-B1CC-407C-A162-7E8EE4DCEC03@tagtraum.com>

On Aug 21, 2014, at 10:10, Hendrik Schreiber <hs at tagtraum.com> wrote:

> I was wondering what is the best way to submit crash logs of non-repeatable VM crashes?

Alright - I simply filed a bunch of bugs.

But I really think it would be beneficial, if there was a way one could automatically send crashlogs to some sort of database. Basically what Apple CrashReporter does.

It seems that Apple is willing to share crash logs with third parties, if not now, then in the future. Are you guys receiving those crash logs?

-hendrik


From hs at tagtraum.com  Fri Aug 22 09:59:37 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 22 Aug 2014 11:59:37 +0200
Subject: java2d performance java7 / java8
In-Reply-To: <53F20819.2020300@3kraft.com>
References: <53DFA95C.6040507@3kraft.com> <53E0DE0F.5070507@oracle.com>
	<53F20819.2020300@3kraft.com>
Message-ID: <023FA89F-A112-49A8-B234-18F97785969F@tagtraum.com>

On Aug 18, 2014, at 16:05, Florian Bruckner (3kraft) <florian.bruckner at 3kraft.com> wrote:

> I have built a minimalistic test case that exposes the problem. It creates a JFrame with an editor pane in it to show some HTML content (a javadoc page). The test is to just scroll from the bottom to the top and back to the bottom by mouse wheel as quickly as possible, I did 5 iterations in each test run.
> 
> Wall clock timing was approx. 15 seconds with Java 6 and approx 45 seconds with java 8. As the problem worsens with increased screen resolutions I decided to use the full resolution of my new UHD display (which is 3840x2160), the machine is a

[...]

Thanks for coming up with some sort of test.

Hopefully the folks at Oracle find the time to look into this, perhaps do their own performance testing, and find ways to improve the 2D pipeline.

Cheers,

-hendrik

From hs at tagtraum.com  Thu Aug 28 13:59:42 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 28 Aug 2014 15:59:42 +0200
Subject: Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop (called
	with NULL argument)
Message-ID: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>

Hey guys,

in the current release, i.e.

java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

there is a bug that causes crashes, because some code calls Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop with NULL as mediatorObject (i.e. argument).

I have filed this bug already on 8/25/2014 for 1.8.0_20-ea at http://bugreport.java.com. There it received review id JI-9014527 and was not seen ever since.

The crash has re-appeared in the final 1.8.0_20 (the version above). A full crash log can be found at http://www.beatunes.com/download/stopAWTRunLoop.crash
The most important part is:

Application Specific Information:
*** CFRelease() called with NULL ***

Thread 30 Crashed:: Java: AWT-EventQueue-0
0   com.apple.CoreFoundation      	0x00007fff863404c4 CFRelease + 724
1   libawt_lwawt.dylib            	0x00000001256fe6b6 Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop + 72
2   ???                           	0x000000010fe14714 0 + 4561389332
3   ???                           	0x000000010fe0698d 0 + 4561332621
4   ???                           	0x000000010fe069d2 0 + 4561332690
5   ???                           	0x000000010fe0698d 0 + 4561332621
6   ???                           	0x0000000111f3f204 0 + 4596167172
7   ???                           	0xf4bbddf7f8000b3f 0 + 17634932822986722111

Could someone with access to the bug system please attach the provided crash log to the original bug?
And also add the additional info, that this time it happened with the final 1.8.0_20 release?

I have 

Thank you - your help is much appreciated.

-hendrik


From anthony.petrov at oracle.com  Thu Aug 28 18:16:53 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Thu, 28 Aug 2014 22:16:53 +0400
Subject: Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop (called
	with NULL argument)
In-Reply-To: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>
References: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>
Message-ID: <53FF7215.3070105@oracle.com>

Hi Hendrik,

JI-9014527 was closed as Incomplete "Not enough information.", 
supposedly because there's not a reproducible test case and instructions 
to reproduce the issue.

If you come up with a simple test that crashes easily, we can re-open 
that bug.

BTW, from the full stack trace in the bug report I can see you're 
running some accessibility software on your system because the crash 
happens during an a11y callback. This may be a contributing factor to 
the crash. You will need to test with and without a11y on, and also 
perhaps try another assistive technology (e.g. the built-in VoiceOver 
vs. a third-party software) to see if this changes anything.

--
best regards,
Anthony

On 8/28/2014 5:59 PM, Hendrik Schreiber wrote:
> Hey guys,
>
> in the current release, i.e.
>
> java version "1.8.0_20"
> Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
>
> there is a bug that causes crashes, because some code calls Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop with NULL as mediatorObject (i.e. argument).
>
> I have filed this bug already on 8/25/2014 for 1.8.0_20-ea at http://bugreport.java.com. There it received review id JI-9014527 and was not seen ever since.
>
> The crash has re-appeared in the final 1.8.0_20 (the version above). A full crash log can be found at http://www.beatunes.com/download/stopAWTRunLoop.crash
> The most important part is:
>
> Application Specific Information:
> *** CFRelease() called with NULL ***
>
> Thread 30 Crashed:: Java: AWT-EventQueue-0
> 0   com.apple.CoreFoundation      	0x00007fff863404c4 CFRelease + 724
> 1   libawt_lwawt.dylib            	0x00000001256fe6b6 Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop + 72
> 2   ???                           	0x000000010fe14714 0 + 4561389332
> 3   ???                           	0x000000010fe0698d 0 + 4561332621
> 4   ???                           	0x000000010fe069d2 0 + 4561332690
> 5   ???                           	0x000000010fe0698d 0 + 4561332621
> 6   ???                           	0x0000000111f3f204 0 + 4596167172
> 7   ???                           	0xf4bbddf7f8000b3f 0 + 17634932822986722111
>
> Could someone with access to the bug system please attach the provided crash log to the original bug?
> And also add the additional info, that this time it happened with the final 1.8.0_20 release?
>
> I have
>
> Thank you - your help is much appreciated.
>
> -hendrik
>

From hs at tagtraum.com  Fri Aug 29 12:45:58 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 29 Aug 2014 14:45:58 +0200
Subject: Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop
	(called with NULL argument)
In-Reply-To: <53FF7215.3070105@oracle.com>
References: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>
	<53FF7215.3070105@oracle.com>
Message-ID: <A36ACA60-CB34-44F5-B34E-5F2097EFD639@tagtraum.com>

On Aug 28, 2014, at 20:16, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> JI-9014527 was closed as Incomplete "Not enough information.", supposedly because there's not a reproducible test case and instructions to reproduce the issue.

That is correct. I erroneously assumed that people reviewing bug reports would be interested in crashes, and their crashlogs, even if they do not contain step-by-step instructions on how to reproduce the issue.

> If you come up with a simple test that crashes easily, we can re-open that bug.

I wish I could.

> BTW, from the full stack trace in the bug report I can see you're running some accessibility software on your system because the crash happens during an a11y callback. This may be a contributing factor to the crash. You will need to test with and without a11y on, and also perhaps try another assistive technology (e.g. the built-in VoiceOver vs. a third-party software) to see if this changes anything.

Digging into the source code it becomes clear that

Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop is only called from 

 - sun.lwawt.macosx.CToolkitThreadBlockedHandler and
 - sun.lwawt.macosx.LWCToolkit


The call from LWCToolkit is coded defensively, i.e. it has a 0-check:

if (mediator != 0) {
    stopAWTRunLoop(mediator);
}

Therefore it cannot lead to the failure described in http://www.beatunes.com/download/stopAWTRunLoop.crash

The call from CToolkitThreadBlockedHandler is NOT coded defensively. To the contrary, it relies on the implicit contract, that the  exit() method is called at most once after the enter() method is called:

    public void exit() {
        if (!isOwned()) {
            throw new IllegalMonitorStateException();
        }
        LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
        awtRunLoopMediator = 0;
    }

It might be a good idea to simply guard against other classes using enter()/exit() in unintended ways by rewriting it defensively like this:

    public void enter() {
        if (!isOwned()) {
            throw new IllegalMonitorStateException();
        }
        if (awtRunLoopMediator != 0) {
            throw new IllegalStateException("Call exit() first.");
        }
        awtRunLoopMediator = LWCToolkit.createAWTRunLoopMediator();
        unlock();
        LWCToolkit.doAWTRunLoop(awtRunLoopMediator, processEvents);
        lock();
    }

    public void exit() {
        if (!isOwned()) {
            throw new IllegalMonitorStateException();
        }
        if (awtRunLoopMediator != 0) {
            LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
            awtRunLoopMediator = 0;
        }
    }

That said, enter() and exit() are only called from one place, sun.awt.datatransfer.DataTransferer#convertData(...).
My guess is, that for some reason getToolkitThreadBlockedHandler().exit(); is either called multiple times or LWCToolkit.createAWTRunLoopMediator() in CToolkitThreadBlockedHandler#enter() returns 0 for whatever reason.

Frankly, I don't quite understand how it can happen that the dataConverter Runnable in DataTransferer#convertData(...) is executed multiple times, but clearly it is a problem, as the code tries to guard against it. It does not do so in a threadsafe way though.

Anyhow.

I would appreciate it, if you considered reviewing both my suggestion for improving sun.lwawt.macosx.CToolkitThreadBlockedHandler and perhaps the code in sun.awt.datatransfer.DataTransferer to improve the stability of the Java VM on OS X.

Thank you.

-hendrik


From anthony.petrov at oracle.com  Fri Aug 29 13:01:59 2014
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 29 Aug 2014 17:01:59 +0400
Subject: Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop (called
	with NULL argument)
In-Reply-To: <A36ACA60-CB34-44F5-B34E-5F2097EFD639@tagtraum.com>
References: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>	<53FF7215.3070105@oracle.com>
	<A36ACA60-CB34-44F5-B34E-5F2097EFD639@tagtraum.com>
Message-ID: <540079C7.9010503@oracle.com>

Wow, that's a good analysis of the problem, Hendrik. Thank you.

Would you like to investigate this a bit deeper and come up with a fix 
for JDK? We would gladly accept a contribution from you. You can find 
more information on how to get started here: 
http://openjdk.java.net/contribute/ Also, the patch would need to be 
reviewed on the awt-dev@ mailing list.

Otherwise, I could only add those comments to the bug report and move it 
to the JDK project in JIRA so that it becomes visible, but I'm afraid we 
won't be able to do much on this issue any time soon because we don't 
have a test app that we could use to reproduce the crash and then 
confirm whether we've fixed anything or not.

--
best regards,
Anthony

On 8/29/2014 4:45 PM, Hendrik Schreiber wrote:
> On Aug 28, 2014, at 20:16, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> JI-9014527 was closed as Incomplete "Not enough information.", supposedly because there's not a reproducible test case and instructions to reproduce the issue.
>
> That is correct. I erroneously assumed that people reviewing bug reports would be interested in crashes, and their crashlogs, even if they do not contain step-by-step instructions on how to reproduce the issue.
>
>> If you come up with a simple test that crashes easily, we can re-open that bug.
>
> I wish I could.
>
>> BTW, from the full stack trace in the bug report I can see you're running some accessibility software on your system because the crash happens during an a11y callback. This may be a contributing factor to the crash. You will need to test with and without a11y on, and also perhaps try another assistive technology (e.g. the built-in VoiceOver vs. a third-party software) to see if this changes anything.
>
> Digging into the source code it becomes clear that
>
> Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop is only called from
>
>   - sun.lwawt.macosx.CToolkitThreadBlockedHandler and
>   - sun.lwawt.macosx.LWCToolkit
>
>
> The call from LWCToolkit is coded defensively, i.e. it has a 0-check:
>
> if (mediator != 0) {
>      stopAWTRunLoop(mediator);
> }
>
> Therefore it cannot lead to the failure described in http://www.beatunes.com/download/stopAWTRunLoop.crash
>
> The call from CToolkitThreadBlockedHandler is NOT coded defensively. To the contrary, it relies on the implicit contract, that the  exit() method is called at most once after the enter() method is called:
>
>      public void exit() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
>          awtRunLoopMediator = 0;
>      }
>
> It might be a good idea to simply guard against other classes using enter()/exit() in unintended ways by rewriting it defensively like this:
>
>      public void enter() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          if (awtRunLoopMediator != 0) {
>              throw new IllegalStateException("Call exit() first.");
>          }
>          awtRunLoopMediator = LWCToolkit.createAWTRunLoopMediator();
>          unlock();
>          LWCToolkit.doAWTRunLoop(awtRunLoopMediator, processEvents);
>          lock();
>      }
>
>      public void exit() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          if (awtRunLoopMediator != 0) {
>              LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
>              awtRunLoopMediator = 0;
>          }
>      }
>
> That said, enter() and exit() are only called from one place, sun.awt.datatransfer.DataTransferer#convertData(...).
> My guess is, that for some reason getToolkitThreadBlockedHandler().exit(); is either called multiple times or LWCToolkit.createAWTRunLoopMediator() in CToolkitThreadBlockedHandler#enter() returns 0 for whatever reason.
>
> Frankly, I don't quite understand how it can happen that the dataConverter Runnable in DataTransferer#convertData(...) is executed multiple times, but clearly it is a problem, as the code tries to guard against it. It does not do so in a threadsafe way though.
>
> Anyhow.
>
> I would appreciate it, if you considered reviewing both my suggestion for improving sun.lwawt.macosx.CToolkitThreadBlockedHandler and perhaps the code in sun.awt.datatransfer.DataTransferer to improve the stability of the Java VM on OS X.
>
> Thank you.
>
> -hendrik
>

From mik3hall at gmail.com  Fri Aug 29 21:39:22 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 29 Aug 2014 16:39:22 -0500
Subject: Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop
	(called with NULL argument)
In-Reply-To: <A36ACA60-CB34-44F5-B34E-5F2097EFD639@tagtraum.com>
References: <16CCD64E-E5F6-4503-B9CF-33B67471B028@tagtraum.com>
	<53FF7215.3070105@oracle.com>
	<A36ACA60-CB34-44F5-B34E-5F2097EFD639@tagtraum.com>
Message-ID: <85DFF7C4-F266-4938-8458-78DC1299C3F7@gmail.com>

On Aug 29, 2014, at 7:45 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:

>    public void exit() {
>        if (!isOwned()) {
>            throw new IllegalMonitorStateException();
>        }
>        LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
>        awtRunLoopMediator = 0;
>    }

What does isOwned() do? Doesn't it ensure that clearing the loop mediator is only done by the owning thread? If some other thread successfully runs through exit doesn't it mean this is not working correctly?

Also, looking at 
http://code.metager.de/source/xref/openjdk/jdk8/jdk/src/macosx/native/sun/awt/LWCToolkit.m

/*
 * Class:     sun_lwawt_macosx_LWCToolkit
 * Method:    stopAWTRunLoop
 * Signature: (J)V
 */

JNIEXPORT void JNICALL Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop

(
JNIEnv *env, jclass clz, jlong mediator
)
{

JNF_COCOA_ENTER(env
);

    
AWTRunLoopObject* mediatorObject = (AWTRunLoopObject*)jlong_to_ptr(mediator
);

    [
ThreadUtilities performOnMainThread:@selector(endRunLoop) on:mediatorObject withObject:nil waitUntilDone:NO
];

    
CFRelease(mediatorObject
);


JNF_COCOA_EXIT(env
);
}

Wouldn't it be simpler and safer to fix it in the JNI?
if (mediatorObject) CFRelease(mediatorObject);

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From mik3hall at gmail.com  Sun Aug 31 01:44:11 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Sat, 30 Aug 2014 20:44:11 -0500
Subject: Application name in About, Hide, and Quit menu items
In-Reply-To: <072D6774-10B3-427E-BCCF-6B6581C92A1D@seanreilly.com>
References: <072D6774-10B3-427E-BCCF-6B6581C92A1D@seanreilly.com>
Message-ID: <19C9BD54-86B7-4A88-A3D0-BF662DC4ACDC@gmail.com>

On Aug 1, 2014, at 11:29 AM, Sean Reilly <sreilly at seanreilly.com> wrote:

> Hi Hendrik,
> 
> In my app bundle ant file I?ve set a few options with the <bundleapp> tag including these:
>          <option value="-Dcom.apple.mrj.application.apple.menu.about.name=${bundle.name}"/>

Trying to make sure my own understanding of OS X java applications is more correct these days I just chased this down.
This property no longer seems to work. In the plist with -D or with System.setProperty later.
What does work is
-Xdock:name=APPNAME
in the plist.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter