From takiguc at linux.vnet.ibm.com Tue Apr 2 11:50:21 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 02 Apr 2019 20:50:21 +0900 Subject: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties Message-ID: <0bca8e5d39d87c2979c6579ee0f1a346@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file. On current implementation, Java tries to load X11 bitmap fonts even if these are not used. This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories. Just font name format should be supported. To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From philip.race at oracle.com Tue Apr 2 14:18:55 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Apr 2019 07:18:55 -0700 Subject: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <0bca8e5d39d87c2979c6579ee0f1a346@linux.vnet.ibm.com> References: <0bca8e5d39d87c2979c6579ee0f1a346@linux.vnet.ibm.com> Message-ID: <5CA36F4F.8000106@oracle.com> Before even looking at this, I ask that you re-post it to the correct list, which is 2d-dev, not awt-dev, and don't include awt-dev on that re-send. -phil. On 4/2/19, 4:50 AM, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > On AIX platform, fontconfig.properties file is used to pick up proper > fonts. > TrueType font settings are written by XLFD format on > fontconfig.properties file. > > On current implementation, Java tries to load X11 bitmap fonts even if > these are not used. > This font load work is almost name as "xlsfonts -ll". > It spends many CPU time and memories. > > Just font name format should be supported. > > To SAP representative, > I have a question about copyright year on > make/data/fontconfig/aix.fontconfig.properties. > Please let me know how I should write down copyright year. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From takiguc at linux.vnet.ibm.com Tue Apr 2 16:27:53 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 03 Apr 2019 01:27:53 +0900 Subject: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties Message-ID: Hello. (I am sorry to post it again. Previously, I posted the wrong mailing list.) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. On AIX platform, fontconfig.properties file is used to pick up proper fonts. TrueType font settings are written by XLFD format on fontconfig.properties file. On current implementation, Java tries to load X11 bitmap fonts even if these are not used. This font load work is almost name as "xlsfonts -ll". It spends many CPU time and memories. Just font name format should be supported. To SAP representative, I have a question about copyright year on make/data/fontconfig/aix.fontconfig.properties. Please let me know how I should write down copyright year. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. From volker.simonis at gmail.com Tue Apr 2 16:42:20 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Apr 2019 18:42:20 +0200 Subject: RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <0bca8e5d39d87c2979c6579ee0f1a346@linux.vnet.ibm.com> References: <0bca8e5d39d87c2979c6579ee0f1a346@linux.vnet.ibm.com> Message-ID: On Tue, Apr 2, 2019 at 1:52 PM Ichiroh Takiguchi wrote: > > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > On AIX platform, fontconfig.properties file is used to pick up proper > fonts. > TrueType font settings are written by XLFD format on > fontconfig.properties file. > > On current implementation, Java tries to load X11 bitmap fonts even if > these are not used. > This font load work is almost name as "xlsfonts -ll". > It spends many CPU time and memories. > > Just font name format should be supported. > > To SAP representative, > I have a question about copyright year on > make/data/fontconfig/aix.fontconfig.properties. > Please let me know how I should write down copyright year. > For example like here: src/jdk.attach/aix/native/libattach/VirtualMachineImpl.c: * Copyright (c) 2015, 2018, SAP SE. All rights reserved. > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From philip.race at oracle.com Wed Apr 3 16:09:29 2019 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Apr 2019 09:09:29 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: Message-ID: <5CA4DAB9.2060602@oracle.com> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: > Hello. > (I am sorry to post it again. Previously, I posted the wrong mailing > list.) > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > On AIX platform, fontconfig.properties file is used to pick up proper > fonts. > TrueType font settings are written by XLFD format on > fontconfig.properties file. > > On current implementation, Java tries to load X11 bitmap fonts even if > these are not used. I think you need to clarify what you mean here. I'd like you to provide a step by step analysis of what happens and what the effect of your proposed change is on AIX *AND* what it might mean for other X11 platforms, as I don't have time to reverse engineer the reasons for the odd-looking change. It looks like a hack to short-circuit support your syntax. Right now I am saying no to this. > This font load work is almost name as "xlsfonts -ll". > It spends many CPU time and memories. > > Just font name format should be supported. Not clear enough for me. -phil. > > To SAP representative, > I have a question about copyright year on > make/data/fontconfig/aix.fontconfig.properties. > Please let me know how I should write down copyright year. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From matthias.baesken at sap.com Tue Apr 9 07:40:15 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 07:40:15 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Message-ID: Hello, please review this small AIX related cleanup change . When recently looking into the os_perf coding , I noticed that we try to read (on AIX) cpu ticks related data from /proc/stat . However this will most likely fail, on the AIX machines I checked there is a /proc but no /proc/stat . (probably the AIX coding has been taken over from linux) The change cleans up the coding in os_perf_aix.cpp . ( there might be other ways to get the CPU ticks related info on AIX e.g. by using libperfstat or by using what has to offer, see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/proc.htm , but this should be checked and maybe added with another change in case someone is interested ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8221915 http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Apr 9 10:22:37 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 10:22:37 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Hi Matthias, the purpose of this file is only to satisfy the build. JFR is not supported on AIX. I guess almost nothing of this file works. There are more things which could get removed. E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 9. April 2019 09:40 To: 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Cc: Simonis, Volker Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Hello, please review this small AIX related cleanup change . When recently looking into the os_perf coding , I noticed that we try to read (on AIX) cpu ticks related data from /proc/stat . However this will most likely fail, on the AIX machines I checked there is a /proc but no /proc/stat . (probably the AIX coding has been taken over from linux) The change cleans up the coding in os_perf_aix.cpp . ( there might be other ways to get the CPU ticks related info on AIX e.g. by using libperfstat or by using what has to offer, see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/proc.htm , but this should be checked and maybe added with another change in case someone is interested ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8221915 http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ Thanks, Matthias From matthias.baesken at sap.com Tue Apr 9 11:22:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 11:22:35 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Hi Martin, true the functions you mentioned can be removed/reduced as well : http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 12:23 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > the purpose of this file is only to satisfy the build. JFR is not supported on > AIX. > I guess almost nothing of this file works. There are more things which could > get removed. > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 9. April 2019 09:40 > To: 'hotspot-dev at openjdk.java.net' ; ppc- > aix-port-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > Hello, please review this small AIX related cleanup change . > > When recently looking into the os_perf coding , I noticed that we try to > read (on AIX) cpu ticks related data from /proc/stat . > However this will most likely fail, on the AIX machines I checked there is a > /proc but no /proc/stat . > > (probably the AIX coding has been taken over from linux) > > The change cleans up the coding in os_perf_aix.cpp . > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > using libperfstat or by using what > has to offer, see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.files/proc.htm , but this should be checked and maybe added > with another change in case someone is interested ) > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > Thanks, Matthias From martin.doerr at sap.com Tue Apr 9 13:01:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 13:01:31 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. Thanks, Martin -----Original Message----- From: Baesken, Matthias Sent: Dienstag, 9. April 2019 13:23 To: Doerr, Martin ; 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. Hi Martin, true the functions you mentioned can be removed/reduced as well : http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 12:23 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > the purpose of this file is only to satisfy the build. JFR is not supported on > AIX. > I guess almost nothing of this file works. There are more things which could > get removed. > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 9. April 2019 09:40 > To: 'hotspot-dev at openjdk.java.net' ; ppc- > aix-port-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > Hello, please review this small AIX related cleanup change . > > When recently looking into the os_perf coding , I noticed that we try to > read (on AIX) cpu ticks related data from /proc/stat . > However this will most likely fail, on the AIX machines I checked there is a > /proc but no /proc/stat . > > (probably the AIX coding has been taken over from linux) > > The change cleans up the coding in os_perf_aix.cpp . > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > using libperfstat or by using what > has to offer, see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.files/proc.htm , but this should be checked and maybe added > with another change in case someone is interested ) > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > Thanks, Matthias From matthias.baesken at sap.com Tue Apr 9 13:04:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Apr 2019 13:04:22 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: Great , thanks for the review Martin ! Do I need a second review or does the "trivial rule" apply ? Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 15:02 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > looks good and trivial. > > Thanks, > Martin > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 9. April 2019 13:23 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Hi Martin, true the functions you mentioned can be removed/reduced as > well : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ > > > > Best regards, Matthias > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 9. April 2019 12:23 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > > [aix] > > > > Hi Matthias, > > > > the purpose of this file is only to satisfy the build. JFR is not supported on > > AIX. > > I guess almost nothing of this file works. There are more things which could > > get removed. > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 9. April 2019 09:40 > > To: 'hotspot-dev at openjdk.java.net' ; > ppc- > > aix-port-dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > > > Hello, please review this small AIX related cleanup change . > > > > When recently looking into the os_perf coding , I noticed that we try to > > read (on AIX) cpu ticks related data from /proc/stat . > > However this will most likely fail, on the AIX machines I checked there is a > > /proc but no /proc/stat . > > > > (probably the AIX coding has been taken over from linux) > > > > The change cleans up the coding in os_perf_aix.cpp . > > > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > > using libperfstat or by using what > > has to offer, see > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > > aix.files/proc.htm , but this should be checked and maybe added > > with another change in case someone is interested ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > > > > Thanks, Matthias From martin.doerr at sap.com Tue Apr 9 13:45:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Apr 2019 13:45:31 +0000 Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] In-Reply-To: References: Message-ID: > Do I need a second review or does the "trivial rule" apply ? You can push it tomorrow if there are no objections. Or if you get a 2nd review. > Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? That's a good hint. We already have libperfstat which may be helpful for a useful implementation of os_perf_aix. Best regards, Martin -----Original Message----- From: Baesken, Matthias Sent: Dienstag, 9. April 2019 15:04 To: Doerr, Martin ; 'hotspot-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Great , thanks for the review Martin ! Do I need a second review or does the "trivial rule" apply ? Btw., is there any interest on ppc-aix-port to get the os_perf related coding working on AIX (e.g. by using libperfstat) ? Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 9. April 2019 15:02 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > Hi Matthias, > > looks good and trivial. > > Thanks, > Martin > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 9. April 2019 13:23 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > [aix] > > > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > Hi Martin, true the functions you mentioned can be removed/reduced as > well : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.1/ > > > > Best regards, Matthias > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 9. April 2019 12:23 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RE: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp > > [aix] > > > > Hi Matthias, > > > > the purpose of this file is only to satisfy the build. JFR is not supported on > > AIX. > > I guess almost nothing of this file works. There are more things which could > > get removed. > > E.g. get_systemtype, get_jvm_ticks, etc. contain linux stuff. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 9. April 2019 09:40 > > To: 'hotspot-dev at openjdk.java.net' ; > ppc- > > aix-port-dev at openjdk.java.net > > Cc: Simonis, Volker > > Subject: RFR: 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] > > > > Hello, please review this small AIX related cleanup change . > > > > When recently looking into the os_perf coding , I noticed that we try to > > read (on AIX) cpu ticks related data from /proc/stat . > > However this will most likely fail, on the AIX machines I checked there is a > > /proc but no /proc/stat . > > > > (probably the AIX coding has been taken over from linux) > > > > The change cleans up the coding in os_perf_aix.cpp . > > > > ( there might be other ways to get the CPU ticks related info on AIX e.g. by > > using libperfstat or by using what > > has to offer, see > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > > aix.files/proc.htm , but this should be checked and maybe added > > with another change in case someone is interested ) > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8221915 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8221915.0/ > > > > > > Thanks, Matthias From matthias.baesken at sap.com Fri Apr 12 09:15:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Apr 2019 09:15:03 +0000 Subject: AIX : -bnorwexec linker flag Message-ID: Hello, I have a question regarding the AIX -bnorwexec linker flag . I think it is related to an AIX security feature SED , see also : https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable_flags.htm When building with the additional -bnorwexec linker flag we signal the OS that we "request" the SED feature . Please compare a patched and an unpatched java ( patched is flagged "request" while unpatched uses the "system" setting ). bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java /patched_jdk/images/images/jdk/bin/java : request bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java /normal_jdk/images/jdk/bin/java : system System config on the example machine is "normal" (default) select : bash-4.3$ sedmgr Stack Execution Disable (SED) mode: select SED configured in kernel: select In our internal tests I noticed so far no issues when setting the -bnorwexec linker flag in OpenJDK on AIX . Do you have any experience with it, do you see issues when setting the flag ? The documentation of the flag is a bit short . https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds3/ld.htm norwexec Specifies that if the system's sed_config setting is not off, the process' private data areas will have non-execute permission. Patch would be : diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -88,7 +88,7 @@ BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" elif test "x$TOOLCHAIN_TYPE" = xxlc; then - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok -btextpsize:64K \ + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok -btextpsize:64K \ -bdatapsize:64K -bstackpsize:64K" # libjvm.so has gotten too large for normal TOC size; compile with qpic=large and link with bigtoc BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Apr 12 12:51:54 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Apr 2019 12:51:54 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX Message-ID: Hello, please review the following change . It brings AIX related virtualization information into the hs_err file . While preparing the patch I wondered a bit about the libperfstat usage in OpenJDK (Hotspot compared to JDK ). In JDK we link already to libperfstat at build time , see : jdk/make/lib/Lib-java.management.gmk BUILD_LIBMANAGEMENT jdk/make/lib/Lib-jdk.management.gmk BUILD_LIBMANAGEMENT_EXT While in hotspot dlopen/dladdr is used , see jdk/src/hotspot/os/aix/libperfstat_aix.cpp 58 bool libperfstat::init() { 59 60 // Dynamically load the libperfstat porting library. 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER | RTLD_NOW); 62 if (!g_libhandle) { 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); 64 return false; 65 } we dlopen and then resolve symbols at runtime. This was probably a good thing back then when AIX 5.3 was still supported as build platform , but I am not sure if it is still needed these days on AIX 7.1/7.2 . But in case the dlopen/dladdr approach in HS is still needed/wanted , I would switch to the libperfstat:: functions . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8222280 http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ Thanks , Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Apr 12 13:29:30 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Apr 2019 06:29:30 -0700 Subject: AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: <826a337f-91e1-c228-85a0-ef56cabea337@oracle.com> From a build point of view, the patch looks good. I cannot comment on the validity of adding the flag though. /Erik On 2019-04-12 02:15, Baesken, Matthias wrote: > Hello, I have a question regarding the AIX -bnorwexec linker flag . > I think it is related to an AIX security feature SED , see also : > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.security/stack_exec_disable_flags.htm > > When building with the additional -bnorwexec linker flag we signal the OS that we "request" the SED feature . > Please compare a patched and an unpatched java ( patched is flagged "request" while unpatched uses the "system" setting ). > > bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java > /patched_jdk/images/images/jdk/bin/java : request > > > bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java > /normal_jdk/images/jdk/bin/java : system > > > System config on the example machine is "normal" (default) select : > bash-4.3$ sedmgr > Stack Execution Disable (SED) mode: select > SED configured in kernel: select > > > In our internal tests I noticed so far no issues when setting the -bnorwexec linker flag in OpenJDK on AIX . > Do you have any experience with it, do you see issues when setting the flag ? > > > The documentation of the flag is a bit short . > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.cmds3/ld.htm > > > norwexec > > Specifies that if the system's sed_config setting is not off, the process' private data areas will have non-execute permission. > > > > > Patch would be : > > diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 > --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 > +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. > +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -88,7 +88,7 @@ > BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" > elif test "x$TOOLCHAIN_TYPE" = xxlc; then > - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok -btextpsize:64K \ > + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok -btextpsize:64K \ > -bdatapsize:64K -bstackpsize:64K" > # libjvm.so has gotten too large for normal TOC size; compile with qpic=large and link with bigtoc > BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" > > > Best regards, Matthias > From matthias.baesken at sap.com Fri Apr 12 13:47:06 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Apr 2019 13:47:06 +0000 Subject: AIX : -bnorwexec linker flag In-Reply-To: <826a337f-91e1-c228-85a0-ef56cabea337@oracle.com> References: <826a337f-91e1-c228-85a0-ef56cabea337@oracle.com> Message-ID: Thanks ! Let's see what other AIX developers say about it . Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Freitag, 12. April 2019 15:30 > To: Baesken, Matthias ; ppc-aix-port- > dev at openjdk.java.net; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: AIX : -bnorwexec linker flag > > From a build point of view, the patch looks good. I cannot comment on > the validity of adding the flag though. > > /Erik > > On 2019-04-12 02:15, Baesken, Matthias wrote: > > Hello, I have a question regarding the AIX -bnorwexec linker flag . > > I think it is related to an AIX security feature SED , see also : > > > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm. > aix.security/stack_exec_disable_flags.htm > > > > When building with the additional -bnorwexec linker flag we signal the > OS that we "request" the SED feature . > > Please compare a patched and an unpatched java ( patched is flagged > "request" while unpatched uses the "system" setting ). > > > > bash-4.3$ sedmgr -d /patched_jdk/images/jdk/bin/java > > /patched_jdk/images/images/jdk/bin/java : request > > > > > > bash-4.3$ sedmgr -d /normal_jdk/images/jdk/bin/java > > /normal_jdk/images/jdk/bin/java : system > > > > > > System config on the example machine is "normal" (default) select : > > bash-4.3$ sedmgr > > Stack Execution Disable (SED) mode: select > > SED configured in kernel: select > > > > > > In our internal tests I noticed so far no issues when setting the - > bnorwexec linker flag in OpenJDK on AIX . > > Do you have any experience with it, do you see issues when setting the > flag ? > > > > > > The documentation of the flag is a bit short . > > > > > > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > aix.cmds3/ld.htm > > > > > > norwexec > > > > Specifies that if the system's sed_config setting is not off, the process' > private data areas will have non-execute permission. > > > > > > > > > > Patch would be : > > > > diff -r 0d7fb7f07134 make/autoconf/flags-ldflags.m4 > > --- a/make/autoconf/flags-ldflags.m4 Mon Apr 08 06:56:37 2019 +0100 > > +++ b/make/autoconf/flags-ldflags.m4 Mon Apr 08 10:50:07 2019 +0200 > > @@ -1,5 +1,5 @@ > > # > > -# Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. > > +# Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > # > > # This code is free software; you can redistribute it and/or modify it > > @@ -88,7 +88,7 @@ > > BASIC_LDFLAGS_JVM_ONLY="-library=%none -mt -z noversion" > > elif test "x$TOOLCHAIN_TYPE" = xxlc; then > > - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok - > btextpsize:64K \ > > + BASIC_LDFLAGS="-b64 -brtl -bnorwexec -bnolibpath -bexpall -bernotok > -btextpsize:64K \ > > -bdatapsize:64K -bstackpsize:64K" > > # libjvm.so has gotten too large for normal TOC size; compile with > qpic=large and link with bigtoc > > BASIC_LDFLAGS_JVM_ONLY="-Wl,-lC_r -bbigtoc" > > > > > > Best regards, Matthias > > From christoph.langer at sap.com Mon Apr 15 06:13:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 15 Apr 2019 06:13:01 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, I think the change is good. As regards to libperfstat usage: I think we should clean this up and try to link during the build/use the system headers. We don't need to support AIX V5.3 as build release any longer and probably all required functionality is contained in the headers of the required minimum AIX build release. This needs to be doublechecked when attempting the cleanup, though. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Freitag, 12. April 2019 14:52 > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file > on AIX > > Hello, please review the following change . It brings AIX related > virtualization information into the hs_err file . > > While preparing the patch I wondered a bit about the libperfstat usage in > OpenJDK (Hotspot compared to JDK ). > In JDK we link already to libperfstat at build time , see : > > jdk/make/lib/Lib-java.management.gmk > BUILD_LIBMANAGEMENT > > jdk/make/lib/Lib-jdk.management.gmk > BUILD_LIBMANAGEMENT_EXT > > > While in hotspot dlopen/dladdr is used , see > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > 58 bool libperfstat::init() { > 59 > 60 // Dynamically load the libperfstat porting library. > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER | > RTLD_NOW); > 62 if (!g_libhandle) { > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > 64 return false; > 65 } > > we dlopen and then resolve symbols at runtime. > This was probably a good thing back then when AIX 5.3 was still supported as > build platform , but I am not sure if it is still needed these days on AIX > 7.1/7.2 . > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > would switch to the libperfstat:: functions . > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > Thanks , Matthias From matthias.baesken at sap.com Mon Apr 15 07:09:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 15 Apr 2019 07:09:52 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review . So I stay with the direct usage perfstat API in my change . > > As regards to libperfstat usage: I think we should clean this up and try to link > during the build/use the system headers. We don't need to support AIX V5.3 > as build release any longer and probably all required functionality is > contained in the headers of the required minimum AIX build release. This > needs to be doublechecked when attempting the cleanup, though. > I think this should be done in a separate change . Can we assume minimum AIX 7.1 at build+runtime (I guess this would make things easier and it is anyway documented in the build platforms Wiki) ? Currently I see these usages of libperfstat:: os_aix.cpp 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, sizeof(psmt), 1); 1400 libperfstat::wparinfo_t wi; 1401 if (libperfstat::get_wparinfo(&wi)) { 1409 libperfstat::partitioninfo_t pi; 1410 if (libperfstat::get_partitioninfo(&pi)) { 3482 libperfstat::perfstat_reset(); 4004 // AIX: use libperfstat 4005 libperfstat::cpuinfo_t ci; 4006 if (libperfstat::get_cpuinfo(&ci)) { 4183 if (!libperfstat::init()) { Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Montag, 15. April 2019 08:13 > To: Baesken, Matthias ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Matthias, > > I think the change is good. > > As regards to libperfstat usage: I think we should clean this up and try to link > during the build/use the system headers. We don't need to support AIX V5.3 > as build release any longer and probably all required functionality is > contained in the headers of the required minimum AIX build release. This > needs to be doublechecked when attempting the cleanup, though. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Freitag, 12. April 2019 14:52 > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > file > > on AIX > > > > Hello, please review the following change . It brings AIX related > > virtualization information into the hs_err file . > > > > While preparing the patch I wondered a bit about the libperfstat usage > in > > OpenJDK (Hotspot compared to JDK ). > > In JDK we link already to libperfstat at build time , see : > > > > jdk/make/lib/Lib-java.management.gmk > > BUILD_LIBMANAGEMENT > > > > jdk/make/lib/Lib-jdk.management.gmk > > BUILD_LIBMANAGEMENT_EXT > > > > > > While in hotspot dlopen/dladdr is used , see > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > 58 bool libperfstat::init() { > > 59 > > 60 // Dynamically load the libperfstat porting library. > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", RTLD_MEMBER > | > > RTLD_NOW); > > 62 if (!g_libhandle) { > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > 64 return false; > > 65 } > > > > we dlopen and then resolve symbols at runtime. > > This was probably a good thing back then when AIX 5.3 was still supported > as > > build platform , but I am not sure if it is still needed these days on AIX > > 7.1/7.2 . > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > would switch to the libperfstat:: functions . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > Thanks , Matthias From tony.reix at atos.net Mon Apr 15 14:18:24 2019 From: tony.reix at atos.net (REIX, Tony) Date: Mon, 15 Apr 2019 14:18:24 +0000 Subject: AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: Hi Maybe that the patch is good, but the original code, though working fine, is bad. --- a/make/autoconf/flags-ldflags.m4 - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok -btextpsize:64K \ On AIX, using -brtl and -bexpall is OK for fixing issues quick and dirty. However, when building and delivering professional products, these options should be used only in last resort. On AIX, the default is to NOT export all symbols. Instead, one should build the list of needed symbols and inform the linker with -bE and -bI linker options of the list of symbols that need to be exported/imported. That's more work, but it's the good way. Using -bexpall means that all symbols contained in a library will be exported. Thus, an executable may want to load a symbol (like strcmp, which is first provided by the libc.a) from another library, breaking the upward compatibility. In addition, -bexpall creates performance issues. And also, sometimes, the linker explodes due to too many symbols. As an example, the current versions of CMake and MariaDB for AIX make use of -bexpall (and, much worse, -expfull). We are changing the code of these 2 packages in order to no more use -bexpall (nor -bexpfull). Regards, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Mon Apr 15 14:47:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 15 Apr 2019 14:47:18 +0000 Subject: AIX : -bnorwexec linker flag In-Reply-To: References: Message-ID: Hi Tony, agree the -bexpall is not good . Do you have a good (/ better) solution for the issue , do you use visibility attributes in the C/C++ or export-lists ? Maybe someone from IBM could comment on this too . Best regards, Matthias From: REIX, Tony Sent: Montag, 15. April 2019 16:18 To: Baesken, Matthias ; ppc-aix-port-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Subject: RE: AIX : -bnorwexec linker flag Hi Maybe that the patch is good, but the original code, though working fine, is bad. --- a/make/autoconf/flags-ldflags.m4 - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok -btextpsize:64K \ On AIX, using -brtl and -bexpall is OK for fixing issues quick and dirty. However, when building and delivering professional products, these options should be used only in last resort. On AIX, the default is to NOT export all symbols. Instead, one should build the list of needed symbols and inform the linker with -bE and -bI linker options of the list of symbols that need to be exported/imported. That's more work, but it's the good way. Using -bexpall means that all symbols contained in a library will be exported. Thus, an executable may want to load a symbol (like strcmp, which is first provided by the libc.a) from another library, breaking the upward compatibility. In addition, -bexpall creates performance issues. And also, sometimes, the linker explodes due to too many symbols. As an example, the current versions of CMake and MariaDB for AIX make use of -bexpall (and, much worse, -expfull). We are changing the code of these 2 packages in order to no more use -bexpall (nor -bexpfull). Regards, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.reix at atos.net Mon Apr 15 16:21:23 2019 From: tony.reix at atos.net (REIX, Tony) Date: Mon, 15 Apr 2019 16:21:23 +0000 Subject: AIX : -bnorwexec linker flag In-Reply-To: References: , Message-ID: Hi Matthias, When building on AIX packages that make use of configure/Makefile/libtool, the code of these packages is aware of AIX constraints and libtool is able to generate and use .exp export files. With the new CMake that we will deliver soon, it will be possible to do the same: now CMake knows about constraints of AIX and some changes (only for AIX) in the CMakeLists.txt files are enough for handling not-standard cases where .exp files must be exported/used explicitely. Looking at source code of OpenJDK, there are: configure.ac/Makefile.in and many .gmk files . I was unable to build in my AIX test VMs, for now. However, I guess that some changes must be made in order to build the export list of symbols of lib*.a (or lib*.so) that are required by other archive/lib*.so or by executables. Regards Cordialement, Tony Reix tony.reix at atos.net ATOS / Bull SAS ATOS Expert IBM Coop Architect & Technical Leader Office : +33 (0) 4 76 29 72 67 1 rue de Provence - 38432 ?chirolles - France www.atos.net ________________________________ De : Baesken, Matthias Envoy? : lundi 15 avril 2019 16:47:18 ? : REIX, Tony; ppc-aix-port-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Objet : RE: AIX : -bnorwexec linker flag Hi Tony, agree the -bexpall is not good . Do you have a good (/ better) solution for the issue , do you use visibility attributes in the C/C++ or export-lists ? Maybe someone from IBM could comment on this too . Best regards, Matthias From: REIX, Tony Sent: Montag, 15. April 2019 16:18 To: Baesken, Matthias ; ppc-aix-port-dev at openjdk.java.net; 'build-dev at openjdk.java.net' Subject: RE: AIX : -bnorwexec linker flag Hi Maybe that the patch is good, but the original code, though working fine, is bad. --- a/make/autoconf/flags-ldflags.m4 - BASIC_LDFLAGS="-b64 -brtl -bnolibpath -bexpall -bernotok -btextpsize:64K \ On AIX, using -brtl and -bexpall is OK for fixing issues quick and dirty. However, when building and delivering professional products, these options should be used only in last resort. On AIX, the default is to NOT export all symbols. Instead, one should build the list of needed symbols and inform the linker with -bE and -bI linker options of the list of symbols that need to be exported/imported. That's more work, but it's the good way. Using -bexpall means that all symbols contained in a library will be exported. Thus, an executable may want to load a symbol (like strcmp, which is first provided by the libc.a) from another library, breaking the upward compatibility. In addition, -bexpall creates performance issues. And also, sometimes, the linker explodes due to too many symbols. As an example, the current versions of CMake and MariaDB for AIX make use of -bexpall (and, much worse, -expfull). We are changing the code of these 2 packages in order to no more use -bexpall (nor -bexpfull). Regards, Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Apr 16 11:52:20 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Apr 2019 11:52:20 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Ping - may I get a second review for this ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 15. April 2019 09:10 > To: Langer, Christoph ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Christoph, thanks for the review . > So I stay with the direct usage perfstat API in my change . > > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > I think this should be done in a separate change . > Can we assume minimum AIX 7.1 at build+runtime (I guess this would > make things easier and it is anyway documented in the build platforms Wiki) > ? > > Currently I see these usages of libperfstat:: > > os_aix.cpp > > 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, > sizeof(psmt), 1); > 1400 libperfstat::wparinfo_t wi; > 1401 if (libperfstat::get_wparinfo(&wi)) { > 1409 libperfstat::partitioninfo_t pi; > 1410 if (libperfstat::get_partitioninfo(&pi)) { > 3482 libperfstat::perfstat_reset(); > 4004 // AIX: use libperfstat > 4005 libperfstat::cpuinfo_t ci; > 4006 if (libperfstat::get_cpuinfo(&ci)) { > 4183 if (!libperfstat::init()) { > > > Best regards, Matthias > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 15. April 2019 08:13 > > To: Baesken, Matthias ; ppc-aix-port- > > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: RFR : 8222280 : Provide virtualization related info in the > hs_error > > file on AIX > > > > Hi Matthias, > > > > I think the change is good. > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Freitag, 12. April 2019 14:52 > > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot- > dev at openjdk.java.net' > > > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > > file > > > on AIX > > > > > > Hello, please review the following change . It brings AIX related > > > virtualization information into the hs_err file . > > > > > > While preparing the patch I wondered a bit about the libperfstat usage > > in > > > OpenJDK (Hotspot compared to JDK ). > > > In JDK we link already to libperfstat at build time , see : > > > > > > jdk/make/lib/Lib-java.management.gmk > > > BUILD_LIBMANAGEMENT > > > > > > jdk/make/lib/Lib-jdk.management.gmk > > > BUILD_LIBMANAGEMENT_EXT > > > > > > > > > While in hotspot dlopen/dladdr is used , see > > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > > > 58 bool libperfstat::init() { > > > 59 > > > 60 // Dynamically load the libperfstat porting library. > > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", > RTLD_MEMBER > > | > > > RTLD_NOW); > > > 62 if (!g_libhandle) { > > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > > 64 return false; > > > 65 } > > > > > > we dlopen and then resolve symbols at runtime. > > > This was probably a good thing back then when AIX 5.3 was still > supported > > as > > > build platform , but I am not sure if it is still needed these days on AIX > > > 7.1/7.2 . > > > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > > would switch to the libperfstat:: functions . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > > > > Thanks , Matthias From martin.doerr at sap.com Tue Apr 16 13:25:07 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 16 Apr 2019 13:25:07 +0000 Subject: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX In-Reply-To: References: Message-ID: Hi Matthias, I agree with that the libperfstat_aix should be discussed separately. It was needed for 2 reasons: - Support as400/PASE where it is not available at all. - Handle changes between AIX versions. With jdk13, we currently only support AIX 7.2 so including the system header should be fine for now. I can't estimate if there will be changes in future AIX versions which make our own lib important again. But I suggest to remove our own libperfstat_aix in a follow up change with the risk that we may potentially have to add it back. I'd like to hear Thomas' opinion on this, too. We currently support neither as400 nor any other AIX, so your change looks good to me. Best regards, Martin -----Original Message----- From: ppc-aix-port-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 16. April 2019 13:52 To: ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: [CAUTION] RE: RFR : 8222280 : Provide virtualization related info in the hs_error file on AIX Ping - may I get a second review for this ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Montag, 15. April 2019 09:10 > To: Langer, Christoph ; ppc-aix-port- > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR : 8222280 : Provide virtualization related info in the hs_error > file on AIX > > Hi Christoph, thanks for the review . > So I stay with the direct usage perfstat API in my change . > > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > I think this should be done in a separate change . > Can we assume minimum AIX 7.1 at build+runtime (I guess this would > make things easier and it is anyway documented in the build platforms Wiki) > ? > > Currently I see these usages of libperfstat:: > > os_aix.cpp > > 748 const int rc = libperfstat::perfstat_memory_total(NULL, &psmt, > sizeof(psmt), 1); > 1400 libperfstat::wparinfo_t wi; > 1401 if (libperfstat::get_wparinfo(&wi)) { > 1409 libperfstat::partitioninfo_t pi; > 1410 if (libperfstat::get_partitioninfo(&pi)) { > 3482 libperfstat::perfstat_reset(); > 4004 // AIX: use libperfstat > 4005 libperfstat::cpuinfo_t ci; > 4006 if (libperfstat::get_cpuinfo(&ci)) { > 4183 if (!libperfstat::init()) { > > > Best regards, Matthias > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Montag, 15. April 2019 08:13 > > To: Baesken, Matthias ; ppc-aix-port- > > dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: RFR : 8222280 : Provide virtualization related info in the > hs_error > > file on AIX > > > > Hi Matthias, > > > > I think the change is good. > > > > As regards to libperfstat usage: I think we should clean this up and try to > link > > during the build/use the system headers. We don't need to support AIX > V5.3 > > as build release any longer and probably all required functionality is > > contained in the headers of the required minimum AIX build release. This > > needs to be doublechecked when attempting the cleanup, though. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Freitag, 12. April 2019 14:52 > > > To: ppc-aix-port-dev at openjdk.java.net; 'hotspot- > dev at openjdk.java.net' > > > > > > Subject: RFR : 8222280 : Provide virtualization related info in the hs_error > > file > > > on AIX > > > > > > Hello, please review the following change . It brings AIX related > > > virtualization information into the hs_err file . > > > > > > While preparing the patch I wondered a bit about the libperfstat usage > > in > > > OpenJDK (Hotspot compared to JDK ). > > > In JDK we link already to libperfstat at build time , see : > > > > > > jdk/make/lib/Lib-java.management.gmk > > > BUILD_LIBMANAGEMENT > > > > > > jdk/make/lib/Lib-jdk.management.gmk > > > BUILD_LIBMANAGEMENT_EXT > > > > > > > > > While in hotspot dlopen/dladdr is used , see > > > jdk/src/hotspot/os/aix/libperfstat_aix.cpp > > > > > > 58 bool libperfstat::init() { > > > 59 > > > 60 // Dynamically load the libperfstat porting library. > > > 61 g_libhandle = dlopen("/usr/lib/libperfstat.a(shr_64.o)", > RTLD_MEMBER > > | > > > RTLD_NOW); > > > 62 if (!g_libhandle) { > > > 63 trcVerbose("Cannot load libperfstat.a (dlerror: %s)", dlerror()); > > > 64 return false; > > > 65 } > > > > > > we dlopen and then resolve symbols at runtime. > > > This was probably a good thing back then when AIX 5.3 was still > supported > > as > > > build platform , but I am not sure if it is still needed these days on AIX > > > 7.1/7.2 . > > > > > > But in case the dlopen/dladdr approach in HS is still needed/wanted , I > > > would switch to the libperfstat:: functions . > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8222280 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8222280_aix_virt.0/ > > > > > > > > > Thanks , Matthias From takiguc at linux.vnet.ibm.com Thu Apr 18 06:55:56 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 18 Apr 2019 15:55:56 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <5CA4DAB9.2060602@oracle.com> References: <5CA4DAB9.2060602@oracle.com> Message-ID: <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> Hello Phil. I appreciate your reply. I put problem analysis information in JDK-8221741 [1]. The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. According to my problem analysis, In this case, Java tried to load large 11 X11 bitmap fonts via XLoadQueryFont() on Xlib. The situation can emulate by "xlsfonts -ll" command, like: $ time xlsfonts -ll -fn "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" ... real 0m2.07s user 0m0.00s sys 0m0.00s One of solution is, Unix's fontconfig.properties can support TrueType/Type1 font name format. [2] Anyway, I don't know the reason why X11 bitmap font is required for logical font. (I don't know how to use X11 bitmap font for physical font. I could not see X11 bitmap font name via GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) I just want to fix Xserver frozen issue. I appreciate your advice. (Other solutions are welcome) [1] https://bugs.openjdk.java.net/browse/JDK-8221741 [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-04-04 01:09, Philip Race wrote: > On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >> Hello. >> (I am sorry to post it again. Previously, I posted the wrong mailing >> list.) >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> On AIX platform, fontconfig.properties file is used to pick up proper >> fonts. >> TrueType font settings are written by XLFD format on >> fontconfig.properties file. >> >> On current implementation, Java tries to load X11 bitmap fonts even if >> these are not used. > > I think you need to clarify what you mean here. > > I'd like you to provide a step by step analysis of what happens and > what the effect of your proposed change is on AIX *AND* what it might > mean for other X11 platforms, as I don't have time to reverse engineer > the > reasons for the odd-looking change. > It looks like a hack to short-circuit support your syntax. > Right now I am saying no to this. > >> This font load work is almost name as "xlsfonts -ll". >> It spends many CPU time and memories. >> >> Just font name format should be supported. > > Not clear enough for me. > > -phil. >> >> To SAP representative, >> I have a question about copyright year on >> make/data/fontconfig/aix.fontconfig.properties. >> Please let me know how I should write down copyright year. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From philip.race at oracle.com Thu Apr 18 20:20:10 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Apr 2019 13:20:10 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> Message-ID: <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> On startup ? What is the Java stack trace that gets you into that call ? Is it this with any modified IBM code, or pure OpenJDK ? -phil. On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: > Hello Phil. > > I appreciate your reply. > I put problem analysis information in JDK-8221741 [1]. > > The issue is AIX's Xserver was frozen about 25 secs on my local AIX box. > According to my problem analysis, > In this case, Java tried to load large 11 X11 bitmap fonts via > XLoadQueryFont() on Xlib. > The situation can emulate by "xlsfonts -ll" command, like: > > $ time xlsfonts -ll -fn > "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" > ... > real??? 0m2.07s > user??? 0m0.00s > sys 0m0.00s > > One of solution is, Unix's fontconfig.properties can support > TrueType/Type1 font name format. [2] > > Anyway, > I don't know the reason why X11 bitmap font is required for logical font. > (I don't know how to use X11 bitmap font for physical font. > I could not see X11 bitmap font name via > GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) > > I just want to fix Xserver frozen issue. > I appreciate your advice. > (Other solutions are welcome) > > [1] https://bugs.openjdk.java.net/browse/JDK-8221741 > [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-04-04 01:09, Philip Race wrote: >> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>> Hello. >>> (I am sorry to post it again. Previously, I posted the wrong mailing >>> list.) >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> On AIX platform, fontconfig.properties file is used to pick up >>> proper fonts. >>> TrueType font settings are written by XLFD format on >>> fontconfig.properties file. >>> >>> On current implementation, Java tries to load X11 bitmap fonts even >>> if these are not used. >> >> I think you need to clarify what you mean here. >> >> I'd like you to provide a step by step analysis of what happens and >> what the effect of your proposed change is on AIX *AND* what it might >> mean for other X11 platforms, as I don't have time to reverse >> engineer the >> reasons for the odd-looking change. >> It looks like a hack to short-circuit support your syntax. >> Right now I am saying no to this. >> >>> This font load work is almost name as "xlsfonts -ll". >>> It spends many CPU time and memories. >>> >>> Just font name format should be supported. >> >> Not clear enough for me. >> >> -phil. >>> >>> To SAP representative, >>> I have a question about copyright year on >>> make/data/fontconfig/aix.fontconfig.properties. >>> Please let me know how I should write down copyright year. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> > From takiguc at linux.vnet.ibm.com Fri Apr 19 12:18:44 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 19 Apr 2019 21:18:44 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> Message-ID: Hello Phil. I'm using standard OpenJDK JDK13 b13 for AIX, like: openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) (Compiled it by myself) To see stack trace, I tried following instruction: 1. Login to AIX box from another machine 2. Login to AIX box from AIX CDE on local AIX box Japanese locale (Ja_JP) or C locale 3. Open terminal, like dtterm on local AIX box 4. Start SwingSet2 demo program 5. Check java's process id 6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side 7. Move mouse cursor on cow image to display ToolTip 8. Keep moving the mouse cursor slowly, mouse cursor may be stopped (I said this situation was "frozen".) 9. After Xserver was frozen, execute "kill -3" with java process id 10. Then stack trace is displayed "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] java.lang.Thread.State: RUNNABLE at sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native Method) at sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) at sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) at sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) at sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) ... I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. Thanks, Ichiroh Takiguchi On 2019-04-19 05:20, Phil Race wrote: > On startup ? > What is the Java stack trace that gets you into that call ? > Is it this with any modified IBM code, or pure OpenJDK ? > > -phil. > > On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I appreciate your reply. >> I put problem analysis information in JDK-8221741 [1]. >> >> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >> box. >> According to my problem analysis, >> In this case, Java tried to load large 11 X11 bitmap fonts via >> XLoadQueryFont() on Xlib. >> The situation can emulate by "xlsfonts -ll" command, like: >> >> $ time xlsfonts -ll -fn >> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >> ... >> real??? 0m2.07s >> user??? 0m0.00s >> sys 0m0.00s >> >> One of solution is, Unix's fontconfig.properties can support >> TrueType/Type1 font name format. [2] >> >> Anyway, >> I don't know the reason why X11 bitmap font is required for logical >> font. >> (I don't know how to use X11 bitmap font for physical font. >> I could not see X11 bitmap font name via >> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >> I just want to fix Xserver frozen issue. >> I appreciate your advice. >> (Other solutions are welcome) >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-04-04 01:09, Philip Race wrote: >>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>> Hello. >>>> (I am sorry to post it again. Previously, I posted the wrong mailing >>>> list.) >>>> >>>> Could you review the fix ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> On AIX platform, fontconfig.properties file is used to pick up >>>> proper fonts. >>>> TrueType font settings are written by XLFD format on >>>> fontconfig.properties file. >>>> >>>> On current implementation, Java tries to load X11 bitmap fonts even >>>> if these are not used. >>> >>> I think you need to clarify what you mean here. >>> >>> I'd like you to provide a step by step analysis of what happens and >>> what the effect of your proposed change is on AIX *AND* what it might >>> mean for other X11 platforms, as I don't have time to reverse >>> engineer the >>> reasons for the odd-looking change. >>> It looks like a hack to short-circuit support your syntax. >>> Right now I am saying no to this. >>> >>>> This font load work is almost name as "xlsfonts -ll". >>>> It spends many CPU time and memories. >>>> >>>> Just font name format should be supported. >>> >>> Not clear enough for me. >>> >>> -phil. >>>> >>>> To SAP representative, >>>> I have a question about copyright year on >>>> make/data/fontconfig/aix.fontconfig.properties. >>>> Please let me know how I should write down copyright year. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >> From philip.race at oracle.com Fri Apr 19 18:55:11 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 19 Apr 2019 11:55:11 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> Message-ID: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Something must have gone wrong upstream to have this font registered as a native font. You should trace back to find out. I suggest to start with this code in SunFontManager.java, where I am guessing you don't have the file name for some reason. ??? protected void registerFontFile(String fontFileName, String[] nativeNames, ??????????????????????????????????? int fontRank, boolean defer) { //????? REMIND: case compare depends on platform ??????? if (registeredFontFiles.contains(fontFileName)) { ??????????? return; ??????? } ??????? int fontFormat; ??????? if (ttFilter.accept(null, fontFileName)) { ??????????? fontFormat = FONTFORMAT_TRUETYPE; ??????? } else if (t1Filter.accept(null, fontFileName)) { ??????????? fontFormat = FONTFORMAT_TYPE1; ??????? } else { ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I think you are getting here, but why ? ??????? } -phil. On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: > Hello Phil. > > I'm using standard OpenJDK JDK13 b13 for AIX, like: > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) > OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) > (Compiled it by myself) > > To see stack trace, I tried following instruction: > ?1. Login to AIX box from another machine > ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale > (Ja_JP) or C locale > ?3. Open terminal, like dtterm on local AIX box > ?4. Start SwingSet2 demo program > ?5. Check java's process id > ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side > ?7. Move mouse cursor on cow image to display ToolTip > ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped > ??? (I said this situation was "frozen".) > ?9. After Xserver was frozen, execute "kill -3" with java process id > 10. Then stack trace is displayed > > "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s > tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] > ?? java.lang.Thread.State: RUNNABLE > ??? at sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native > Method) > ??? at > sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) > ??? at > sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) > ??? at > sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) > ??? at > sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) > ... > > I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. > > Thanks, > Ichiroh Takiguchi > > On 2019-04-19 05:20, Phil Race wrote: >> On startup ? >> What is the Java stack trace that gets you into that call ? >> Is it this with any modified IBM code, or pure OpenJDK ? >> >> -phil. >> >> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> I appreciate your reply. >>> I put problem analysis information in JDK-8221741 [1]. >>> >>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>> box. >>> According to my problem analysis, >>> In this case, Java tried to load large 11 X11 bitmap fonts via >>> XLoadQueryFont() on Xlib. >>> The situation can emulate by "xlsfonts -ll" command, like: >>> >>> $ time xlsfonts -ll -fn >>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>> ... >>> real??? 0m2.07s >>> user??? 0m0.00s >>> sys 0m0.00s >>> >>> One of solution is, Unix's fontconfig.properties can support >>> TrueType/Type1 font name format. [2] >>> >>> Anyway, >>> I don't know the reason why X11 bitmap font is required for logical >>> font. >>> (I don't know how to use X11 bitmap font for physical font. >>> I could not see X11 bitmap font name via >>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>> I just want to fix Xserver frozen issue. >>> I appreciate your advice. >>> (Other solutions are welcome) >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-04-04 01:09, Philip Race wrote: >>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>> mailing list.) >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>> proper fonts. >>>>> TrueType font settings are written by XLFD format on >>>>> fontconfig.properties file. >>>>> >>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>> even if these are not used. >>>> >>>> I think you need to clarify what you mean here. >>>> >>>> I'd like you to provide a step by step analysis of what happens and >>>> what the effect of your proposed change is on AIX *AND* what it might >>>> mean for other X11 platforms, as I don't have time to reverse >>>> engineer the >>>> reasons for the odd-looking change. >>>> It looks like a hack to short-circuit support your syntax. >>>> Right now I am saying no to this. >>>> >>>>> This font load work is almost name as "xlsfonts -ll". >>>>> It spends many CPU time and memories. >>>>> >>>>> Just font name format should be supported. >>>> >>>> Not clear enough for me. >>>> >>>> -phil. >>>>> >>>>> To SAP representative, >>>>> I have a question about copyright year on >>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>> Please let me know how I should write down copyright year. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>> > From takiguc at linux.vnet.ibm.com Thu Apr 25 12:10:00 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 25 Apr 2019 21:10:00 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: <02de48ec15c2446830715b1608800694@linux.vnet.ibm.com> Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote: > Something must have gone wrong upstream to have this font registered > as a native font. > You should trace back to find out. I suggest to start with this code > in SunFontManager.java, > where I am guessing you don't have the file name for some reason. > > ??? protected void registerFontFile(String fontFileName, String[] > nativeNames, > ??????????????????????????????????? > int fontRank, boolean defer) { > //????? REMIND: case compare depends on platform > ??????? if (registeredFontFiles.contains(fontFileName)) { > ??????????? return; > ??????? } > ??????? int fontFormat; > ??????? if (ttFilter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TRUETYPE; > ??????? } else if (t1Filter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TYPE1; > ??????? } else { > ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I > think you are getting here, but why ? > ??????? } > > -phil. > > On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I'm using standard OpenJDK JDK13 b13 for AIX, like: >> openjdk version "13-internal" 2019-09-17 >> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >> (Compiled it by myself) >> >> To see stack trace, I tried following instruction: >> ?1. Login to AIX box from another machine >> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >> (Ja_JP) or C locale >> ?3. Open terminal, like dtterm on local AIX box >> ?4. Start SwingSet2 demo program >> ?5. Check java's process id >> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >> ?7. Move mouse cursor on cow image to display ToolTip >> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >> ??? (I said this situation was "frozen".) >> ?9. After Xserver was frozen, execute "kill -3" with java process id >> 10. Then stack trace is displayed >> >> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s >> tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] >> ?? java.lang.Thread.State: RUNNABLE >> ??? at >> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native >> Method) >> ??? at >> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >> ??? at >> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >> ??? at >> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >> ??? at >> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >> ... >> >> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-04-19 05:20, Phil Race wrote: >>> On startup ? >>> What is the Java stack trace that gets you into that call ? >>> Is it this with any modified IBM code, or pure OpenJDK ? >>> >>> -phil. >>> >>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> I appreciate your reply. >>>> I put problem analysis information in JDK-8221741 [1]. >>>> >>>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>>> box. >>>> According to my problem analysis, >>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>> XLoadQueryFont() on Xlib. >>>> The situation can emulate by "xlsfonts -ll" command, like: >>>> >>>> $ time xlsfonts -ll -fn >>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>> ... >>>> real??? 0m2.07s >>>> user??? 0m0.00s >>>> sys 0m0.00s >>>> >>>> One of solution is, Unix's fontconfig.properties can support >>>> TrueType/Type1 font name format. [2] >>>> >>>> Anyway, >>>> I don't know the reason why X11 bitmap font is required for logical >>>> font. >>>> (I don't know how to use X11 bitmap font for physical font. >>>> I could not see X11 bitmap font name via >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>> I just want to fix Xserver frozen issue. >>>> I appreciate your advice. >>>> (Other solutions are welcome) >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-04-04 01:09, Philip Race wrote: >>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>> mailing list.) >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>> proper fonts. >>>>>> TrueType font settings are written by XLFD format on >>>>>> fontconfig.properties file. >>>>>> >>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>> even if these are not used. >>>>> >>>>> I think you need to clarify what you mean here. >>>>> >>>>> I'd like you to provide a step by step analysis of what happens and >>>>> what the effect of your proposed change is on AIX *AND* what it >>>>> might >>>>> mean for other X11 platforms, as I don't have time to reverse >>>>> engineer the >>>>> reasons for the odd-looking change. >>>>> It looks like a hack to short-circuit support your syntax. >>>>> Right now I am saying no to this. >>>>> >>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>> It spends many CPU time and memories. >>>>>> >>>>>> Just font name format should be supported. >>>>> >>>>> Not clear enough for me. >>>>> >>>>> -phil. >>>>>> >>>>>> To SAP representative, >>>>>> I have a question about copyright year on >>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>> Please let me know how I should write down copyright year. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>> >> From takiguc at linux.vnet.ibm.com Thu Apr 25 12:27:31 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 25 Apr 2019 21:27:31 +0900 Subject: [Resend] Re: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: (Sorry, please ignore previous mail, it has wrong link for "Change") Hello Phil. I appreciate your suggestion. I could find out the root cause. XLFD format font name (which was on AIX's fontconfig.properties file) is not included into fonts.dir (fonts.scale) file. It was in fonts.alias file. It seems that Java could not find font file on fonts.dir, then it tried to use XLFD format font name to load X11's font for logical font. On AIX platform, TrueType font files had been changed several times. XLFD format font names were registered into fonts.alias file for compatibility. On this condition, I think adding fonts.alias support feature is better than fixing AIX's fontconfig.properties file. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-04-20 03:55, Phil Race wrote: > Something must have gone wrong upstream to have this font registered > as a native font. > You should trace back to find out. I suggest to start with this code > in SunFontManager.java, > where I am guessing you don't have the file name for some reason. > > ??? protected void registerFontFile(String fontFileName, String[] > nativeNames, > ??????????????????????????????????? > int fontRank, boolean defer) { > //????? REMIND: case compare depends on platform > ??????? if (registeredFontFiles.contains(fontFileName)) { > ??????????? return; > ??????? } > ??????? int fontFormat; > ??????? if (ttFilter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TRUETYPE; > ??????? } else if (t1Filter.accept(null, fontFileName)) { > ??????????? fontFormat = FONTFORMAT_TYPE1; > ??????? } else { > ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I > think you are getting here, but why ? > ??????? } > > -phil. > > On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> I'm using standard OpenJDK JDK13 b13 for AIX, like: >> openjdk version "13-internal" 2019-09-17 >> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >> (Compiled it by myself) >> >> To see stack trace, I tried following instruction: >> ?1. Login to AIX box from another machine >> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >> (Ja_JP) or C locale >> ?3. Open terminal, like dtterm on local AIX box >> ?4. Start SwingSet2 demo program >> ?5. Check java's process id >> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >> ?7. Move mouse cursor on cow image to display ToolTip >> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >> ??? (I said this situation was "frozen".) >> ?9. After Xserver was frozen, execute "kill -3" with java process id >> 10. Then stack trace is displayed >> >> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms elapsed=31.90s >> tid=0x0000000113f44800 nid=0x1516 runnable [0x0000000114159000] >> ?? java.lang.Thread.State: RUNNABLE >> ??? at >> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native >> Method) >> ??? at >> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >> ??? at >> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >> ??? at >> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >> ??? at >> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >> ... >> >> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-04-19 05:20, Phil Race wrote: >>> On startup ? >>> What is the Java stack trace that gets you into that call ? >>> Is it this with any modified IBM code, or pure OpenJDK ? >>> >>> -phil. >>> >>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> I appreciate your reply. >>>> I put problem analysis information in JDK-8221741 [1]. >>>> >>>> The issue is AIX's Xserver was frozen about 25 secs on my local AIX >>>> box. >>>> According to my problem analysis, >>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>> XLoadQueryFont() on Xlib. >>>> The situation can emulate by "xlsfonts -ll" command, like: >>>> >>>> $ time xlsfonts -ll -fn >>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>> ... >>>> real??? 0m2.07s >>>> user??? 0m0.00s >>>> sys 0m0.00s >>>> >>>> One of solution is, Unix's fontconfig.properties can support >>>> TrueType/Type1 font name format. [2] >>>> >>>> Anyway, >>>> I don't know the reason why X11 bitmap font is required for logical >>>> font. >>>> (I don't know how to use X11 bitmap font for physical font. >>>> I could not see X11 bitmap font name via >>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>> I just want to fix Xserver frozen issue. >>>> I appreciate your advice. >>>> (Other solutions are welcome) >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-04-04 01:09, Philip Race wrote: >>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>> mailing list.) >>>>>> >>>>>> Could you review the fix ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>> proper fonts. >>>>>> TrueType font settings are written by XLFD format on >>>>>> fontconfig.properties file. >>>>>> >>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>> even if these are not used. >>>>> >>>>> I think you need to clarify what you mean here. >>>>> >>>>> I'd like you to provide a step by step analysis of what happens and >>>>> what the effect of your proposed change is on AIX *AND* what it >>>>> might >>>>> mean for other X11 platforms, as I don't have time to reverse >>>>> engineer the >>>>> reasons for the odd-looking change. >>>>> It looks like a hack to short-circuit support your syntax. >>>>> Right now I am saying no to this. >>>>> >>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>> It spends many CPU time and memories. >>>>>> >>>>>> Just font name format should be supported. >>>>> >>>>> Not clear enough for me. >>>>> >>>>> -phil. >>>>>> >>>>>> To SAP representative, >>>>>> I have a question about copyright year on >>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>> Please let me know how I should write down copyright year. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>> >> From philip.race at oracle.com Thu Apr 25 20:41:08 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 25 Apr 2019 13:41:08 -0700 Subject: [Resend] Re: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> Message-ID: I am not sure about this. It would seem better to fix the config file. Other config files have been carefully written to use the real XLFD and if it changes in a different release, then you provide a new one with the specific release file. Also I have no way to test this works for AIX, all I can say for sure is that it will add extra overhead on other platforms. Also I am puzzled when I see this : ?449???????????????? && "FILE_NAMES_ALIASES".equals(st.sval)) { and then go read about this unfamiliar syntax : https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html I just can't imagine what the AIX fonts.alias file must look like as your code is parsing XLFDs but that syntax is used to say that the file might not have anything like that, instead if a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is automatically an X11 alias for that font, without any XLFDs involved .. At least that's how I read it. Your code seems to expect that line at the beginning and then says "and the rest of the file is aliases I want to read". SFAICT it is perfectly legitimate to NOT have that line or have it in? a random place, and your code is broken. -phil. On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote: > (Sorry, please ignore previous mail, it has wrong link for "Change") > > Hello Phil. > > I appreciate your suggestion. > > I could find out the root cause. > XLFD format font name (which was on AIX's fontconfig.properties file) > is not included > into fonts.dir (fonts.scale) file. > It was in fonts.alias file. > It seems that Java could not find font file on fonts.dir, > then it tried to use XLFD format font name to load X11's font for > logical font. > > On AIX platform, TrueType font files had been changed several times. > XLFD format font names were registered into fonts.alias file for > compatibility. > > On this condition, I think adding fonts.alias support feature is > better than > fixing AIX's fontconfig.properties file. > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > > On 2019-04-20 03:55, Phil Race wrote: >> Something must have gone wrong upstream to have this font registered >> as a native font. >> You should trace back to find out. I suggest to start with this code >> in SunFontManager.java, >> where I am guessing you don't have the file name for some reason. >> >> ??? protected void registerFontFile(String fontFileName, String[] >> nativeNames, >> >> int fontRank, boolean defer) { >> //????? REMIND: case compare depends on platform >> ??????? if (registeredFontFiles.contains(fontFileName)) { >> ??????????? return; >> ??????? } >> ??????? int fontFormat; >> ??????? if (ttFilter.accept(null, fontFileName)) { >> ??????????? fontFormat = FONTFORMAT_TRUETYPE; >> ??????? } else if (t1Filter.accept(null, fontFileName)) { >> ??????????? fontFormat = FONTFORMAT_TYPE1; >> ??????? } else { >> ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< I >> think you are getting here, but why ? >> ??????? } >> >> -phil. >> >> On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> I'm using standard OpenJDK JDK13 b13 for AIX, like: >>> openjdk version "13-internal" 2019-09-17 >>> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >>> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed mode) >>> (Compiled it by myself) >>> >>> To see stack trace, I tried following instruction: >>> ?1. Login to AIX box from another machine >>> ?2. Login to AIX box from AIX CDE on local AIX box Japanese locale >>> (Ja_JP) or C locale >>> ?3. Open terminal, like dtterm on local AIX box >>> ?4. Start SwingSet2 demo program >>> ?5. Check java's process id >>> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >>> ?7. Move mouse cursor on cow image to display ToolTip >>> ?8. Keep moving the mouse cursor slowly, mouse cursor may be stopped >>> ??? (I said this situation was "frozen".) >>> ?9. After Xserver was frozen, execute "kill -3" with java process id >>> 10. Then stack trace is displayed >>> >>> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms >>> elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable >>> [0x0000000114159000] >>> ?? java.lang.Thread.State: RUNNABLE >>> ??? at >>> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native Method) >>> ??? at >>> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >>> ??? at >>> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >>> ??? at >>> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >>> ??? at >>> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >>> ... >>> >>> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot JVM. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2019-04-19 05:20, Phil Race wrote: >>>> On startup ? >>>> What is the Java stack trace that gets you into that call ? >>>> Is it this with any modified IBM code, or pure OpenJDK ? >>>> >>>> -phil. >>>> >>>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> I appreciate your reply. >>>>> I put problem analysis information in JDK-8221741 [1]. >>>>> >>>>> The issue is AIX's Xserver was frozen about 25 secs on my local >>>>> AIX box. >>>>> According to my problem analysis, >>>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>>> XLoadQueryFont() on Xlib. >>>>> The situation can emulate by "xlsfonts -ll" command, like: >>>>> >>>>> $ time xlsfonts -ll -fn >>>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>>> >>>>> ... >>>>> real??? 0m2.07s >>>>> user??? 0m0.00s >>>>> sys 0m0.00s >>>>> >>>>> One of solution is, Unix's fontconfig.properties can support >>>>> TrueType/Type1 font name format. [2] >>>>> >>>>> Anyway, >>>>> I don't know the reason why X11 bitmap font is required for >>>>> logical font. >>>>> (I don't know how to use X11 bitmap font for physical font. >>>>> I could not see X11 bitmap font name via >>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>>> I just want to fix Xserver frozen issue. >>>>> I appreciate your advice. >>>>> (Other solutions are welcome) >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2019-04-04 01:09, Philip Race wrote: >>>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello. >>>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>>> mailing list.) >>>>>>> >>>>>>> Could you review the fix ? >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>>> >>>>>>> I'd like to obtain a sponsor for this issue. >>>>>>> >>>>>>> On AIX platform, fontconfig.properties file is used to pick up >>>>>>> proper fonts. >>>>>>> TrueType font settings are written by XLFD format on >>>>>>> fontconfig.properties file. >>>>>>> >>>>>>> On current implementation, Java tries to load X11 bitmap fonts >>>>>>> even if these are not used. >>>>>> >>>>>> I think you need to clarify what you mean here. >>>>>> >>>>>> I'd like you to provide a step by step analysis of what happens and >>>>>> what the effect of your proposed change is on AIX *AND* what it >>>>>> might >>>>>> mean for other X11 platforms, as I don't have time to reverse >>>>>> engineer the >>>>>> reasons for the odd-looking change. >>>>>> It looks like a hack to short-circuit support your syntax. >>>>>> Right now I am saying no to this. >>>>>> >>>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>>> It spends many CPU time and memories. >>>>>>> >>>>>>> Just font name format should be supported. >>>>>> >>>>>> Not clear enough for me. >>>>>> >>>>>> -phil. >>>>>>> >>>>>>> To SAP representative, >>>>>>> I have a question about copyright year on >>>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>>> Please let me know how I should write down copyright year. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> >>>>> >>> > From sgehwolf at redhat.com Tue Apr 30 11:37:38 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Apr 2019 13:37:38 +0200 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation Message-ID: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> Hi, Could I please get a review for this 8u backport related to fdlibm optimization on Linux? The JDK 12 patch doesn't apply as-is as the JDK 8 build system is drastically different from JDK 11+. Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/jdk8/02/ The main differences to the original fix are: a) optimization level and b) additional hook for older GCC. This backport keeps the optimization level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would otherwise regress Linux ppc64{,le} which currently use -O3. As the current code has the implicit assumption of ppc64 being compiled on older GCCs too (JDK-8172053), this backport maintains compatibility in this regard. If -ffp-contract=off is not available, a machine specific set of flags is being used if the compiler supports them (-mno-fused-madd -fno-strict- aliasing). For older GCCs (< 4.6) specific machine flags are being used. That is, for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags have already been determined (See JDK-8172053). x86_64 and x86 have the same machine specific flags available, so I've used them there too[1]. Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc 4.4.7 x86_64/ppc64. Manual inspection of build logs for fdlibm files (e.g. w_asin.c). Thoughts? Thanks, Severin [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options From matthias.baesken at sap.com Tue Apr 30 12:52:02 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 30 Apr 2019 12:52:02 +0000 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> References: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> Message-ID: Hi Severin, looks okay to me (not a reviewer however). In our proprietary JVM8 we had set (on Linux) BUILD_LIBFDLIBM_OPTIMIZATION := HIGH and FDLIBM_CFLAGS += -ffp-contract=off for a long time and did not observe any issues . (but we always build with gcc 4.8.x so cannot tell much about lower gcc versions ). But I really wonder - wouldn?t it be better in the long run to go for a min. gcc versions >= 4.6 (or even 4.8) in OpenJDK8 ? Maybe some people from the distros could comment on this . Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 30. April 2019 13:38 > To: jdk8u-dev ; build-dev dev at openjdk.java.net> > Cc: ppc-aix-port-dev > Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non- > optimized compilation > > Hi, > > Could I please get a review for this 8u backport related to fdlibm > optimization on Linux? The JDK 12 patch doesn't apply as-is as the JDK > 8 build system is drastically different from JDK 11+. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210416/jdk8/02/ > > The main differences to the original fix are: a) optimization level and > b) additional hook for older GCC. This backport keeps the optimization > level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would otherwise > regress Linux ppc64{,le} which currently use -O3. As the current code > has the implicit assumption of ppc64 being compiled on older GCCs too > (JDK-8172053), this backport maintains compatibility in this regard. If > -ffp-contract=off is not available, a machine specific set of flags is > being used if the compiler supports them (-mno-fused-madd -fno-strict- > aliasing). > > For older GCCs (< 4.6) specific machine flags are being used. That is, > for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags have > already been determined (See JDK-8172053). x86_64 and x86 have the same > machine specific flags available, so I've used them there too[1]. > > Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc 4.4.7 > x86_64/ppc64. Manual inspection of build logs for fdlibm files (e.g. > w_asin.c). > > Thoughts? > > Thanks, > Severin > > [1] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64- > Options.html#i386-and-x86_002d64-Options > > > > From sgehwolf at redhat.com Tue Apr 30 13:14:53 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Apr 2019 15:14:53 +0200 Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <2dce878b0d25f63974f2988f58d022d810af81bd.camel@redhat.com> Message-ID: Hi Matthias, Thanks for the review! On Tue, 2019-04-30 at 12:52 +0000, Baesken, Matthias wrote: > Hi Severin, looks okay to me (not a reviewer however). > In our proprietary JVM8 we had set (on > Linux) BUILD_LIBFDLIBM_OPTIMIZATION := > HIGH and FDLIBM_CFLAGS += -ffp-contract=off for a long time > and did not observe any issues . Good to know. We do the same in Fedora, fwiw. > (but we always build with gcc 4.8.x so cannot tell much about lower > gcc versions ). > > But I really wonder - wouldn?t it be better in the long run to go > for a min. gcc versions >= 4.6 (or even 4.8) in OpenJDK8 ? > > Maybe some people from the distros could comment on this . Perhaps, but it's hard to effectively figure out what that minimal version should be. Note that this change for the alternative of -ffp-contract=off was introduced to JDK 8 by SAP. See: https://bugs.openjdk.java.net/browse/JDK-8172053 Reading that bug it appears that minimum gcc is version 4.3? Either way, this patch will do the right thing(tm) for both as far as I could tell. It would use -mno-fused-madd -fno-strict-aliasing over --ffp- contract=off. My focus for this backport was to not break existing behaviour. Supporting -ffp-contract=off only would also break our upstream build machinery, as for them we build on RHEL 6 with gcc 4.4.7. >From our point of view JDK 8 minimal GCC would be 4.4.7 :) Thanks, Severin > > Best regards, Matthias > > > > -----Original Message----- > > From: ppc-aix-port-dev > > On > > Behalf Of Severin Gehwolf > > Sent: Dienstag, 30. April 2019 13:38 > > To: jdk8u-dev ; build-dev > dev at openjdk.java.net> > > Cc: ppc-aix-port-dev > > Subject: [8u] RFR: 8210416: [linux] Poor StrictMath performance due > > to non- > > optimized compilation > > > > Hi, > > > > Could I please get a review for this 8u backport related to fdlibm > > optimization on Linux? The JDK 12 patch doesn't apply as-is as the > > JDK > > 8 build system is drastically different from JDK 11+. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210416 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210416/jdk8/02/ > > > > The main differences to the original fix are: a) optimization level > > and > > b) additional hook for older GCC. This backport keeps the > > optimization > > level at -O3 (HIGH) over -O2 (LOW) for JDK 8u as this would > > otherwise > > regress Linux ppc64{,le} which currently use -O3. As the current > > code > > has the implicit assumption of ppc64 being compiled on older GCCs > > too > > (JDK-8172053), this backport maintains compatibility in this > > regard. If > > -ffp-contract=off is not available, a machine specific set of flags > > is > > being used if the compiler supports them (-mno-fused-madd -fno- > > strict- > > aliasing). > > > > For older GCCs (< 4.6) specific machine flags are being used. That > > is, > > for ppc64{,le} and x86{,_64}. ppc64{,le} machine specific flags > > have > > already been determined (See JDK-8172053). x86_64 and x86 have the > > same > > machine specific flags available, so I've used them there too[1]. > > > > Testing: build/test on gcc 8.x Linux x86_64. build/test on gcc > > 4.4.7 > > x86_64/ppc64. Manual inspection of build logs for fdlibm files > > (e.g. > > w_asin.c). > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] > > https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/i386-and-x86_002d64- > > Options.html#i386-and-x86_002d64-Options > > > > > > > >