From david.holmes at oracle.com Sun Dec 2 23:14:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Dec 2018 09:14:07 +1000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> Message-ID: This is probably best discussed on net-dev rather than core-libs-dev. Cheers, David On 1/12/2018 2:27 am, Volker Simonis wrote: > On Fri, Nov 30, 2018 at 12:20 PM Steve Groeger wrote: >> >> Hi Goetz, >> >> I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as >> they detected that IPv6 is not enabled and then didnt try and set the IPv6 >> options. > > Not being a network expert either, I think there's two things to > consider here. It seems that IPv6 can be disabled globally (e.g. in > the Linux kernel) or IPv6 can be enabled globally, but not all network > devices supporting it. A quick search revealed that it seems to be > fairly easy to disable IPv6 on a single interface on Linux while still > having IPv6 globally enabled (see > https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux). > @Steve Groeger can you please check if the test still succeeds on > Linux if you only disable IPv6 on the specific interface used by the > test? If it still succeeds, there's probably something to fix on AIX. > If it fails on Linux as well, there may be something to fix in the > test (i.e. to detect that the corresponding interface doesn't support > IPv6) or even in the Java network implementation (i.e. to handle both, > IPv6 and IPv4-only interfaces on an IPv6 enabled system correctly). > > Thank you and best regards, > Volker > >> I am currently unable to disable IPv6 on my AIX box to test this but would >> assume it would also work as the code checks to see whether IPv6 is >> enabled and doesnt try and set the IPV6 options. >> It seems the issue with the tests failing seems to be, if IPv6 is enabled >> but the interface doesn't have an IPv6 address associated with it, as in >> your case here: >> >> bash-4.3$ ifconfig -a >> en0: >> flags=1e084863,480 >> inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx >> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >> lo0: >> flags=e08084b,c0 >> inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx >> inet6 ::1%1/0 >> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 >> >> where you can see that the en0 interface has an inet address associated >> but doesnt have an inet6 address associated. >> I can see that IPv6 is enabled as the lo0 interface has an inet6 address >> (pointing to localhost) >> >> As I stated below, my AIX system was configured in a similar way to yours >> and the tests failed. When I was able to add an inet6 address to en0, >> everything works correctly. >> NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to >> add the inet6 address to my en0 interface. After that all tests worked. >> >> So I think the tests are working as expected, but the AIX system is not >> configured correctly, but I would like someone else to confirm this. >> >> Thanks >> Steve Groeger >> IBM Runtime Technologies >> Hursley, Winchester >> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >> Fax (44) 1962 816800 >> Lotus Notes: Steve Groeger/UK/IBM >> Internet: groeges at uk.ibm.com >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> >> >> From: "Lindenmaier, Goetz" >> To: Steve Groeger , ppc-aix-port-dev >> >> Date: 30/11/2018 10:18 >> Subject: RE: 8207404: MulticastSocket tests failing on Aix >> >> >> >> i Steve, >> >> thanks for looking at this issue. >> >>> Should these tests work without having IPV6 configured on the interface? >> In general, tests should not show errors if a system does not meet >> the requirements for the test. In such cases the test should >> be skipped somehow. Maybe only a test fix is needed. >> >> Can you check on a non-aix machine without ipv6 whether the test >> passes? >> >>> Goetz, do you have IPV6 configured on the machine you were running these >>> tests on? >> This is our test machine: >> >> bash-4.3$ ifconfig -a >> en0: >> flags=1e084863,480 >> inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx >> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >> lo0: >> flags=e08084b,c0 >> inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx >> inet6 ::1%1/0 >> tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 >> >> I think this message should be posted to core-libs-dev, too. That's also >> the list where a potential fix needs to be reviewed. >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Steve Groeger >>> Sent: Donnerstag, 29. November 2018 17:07 >>> To: ppc-aix-port-dev >>> Cc: Lindenmaier, Goetz >>> Subject: 8207404: MulticastSocket tests failing on Aix >>> >>> Hi All, >>> >>> I have been having a look at this issue: >>> >> https://bugs.openjdk.java.net/browse/JDK-8207404 >> >>> < >> https://bugs.openjdk.java.net/browse/JDK-8207404 >>> >>> which was raised by Goetz Lindenmaier. >>> >>> When I ran the tests on my AIX system I got the same results as Goetz >> listed >>> in the issue. >>> >>> Looking at the failure I noticed that it was failing on a setsockopt >> call in the >>> native code in >>> the PlainDatagramSocketImpl.c file which returned a EADDRNOTAVAIL (Can't >>> assign requested address) >>> >>> Looking at my network configuration using "ifconfig -a", I noticed that >> my >>> interface "en0" which the test >>> was trying to use did not have an inet6 address configured (see below - >> some >>> addresses have been obfuscated with x's). >>> >>> en0: >>> flags=1e084863,14c0>> CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> >>> inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx >>> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >>> >>> configuring the IPV6 on my AIX box I then had a inet6 address configured >> for >>> en0 >>> >>> en0: >>> flags=1e084863,14c0>> CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> >>> inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx >>> inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 >>> tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 >>> >>> with this configured the MulticastSocket tests all passed. >>> >>> Should these tests work without having IPV6 configured on the interface? >>> >>> Goetz, do you have IPV6 configured on the machine you were running these >>> tests on? >>> >>> Thanks >>> Steve Groeger >>> IBM Runtime Technologies >>> Hursley, UK >>> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 >>> Fax (44) 1962 816800 >>> Lotus Notes: Steve Groeger/UK/IBM >>> Internet: groeges at uk.ibm.com >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >>> 3AU >> >> >> >> >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Roger.Riggs at oracle.com Mon Dec 3 20:50:56 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 15:50:56 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> Message-ID: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Hi Ichiroh, src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: ??? I think this is no longer needed since it only has imports. ??? By the way, the style is to import each specific class and avoid wild card imports. TestIBMBugs: ? - Please use a style consistent with other methods in the class. ??? In this case spaces are needed around "{" and "}, and a space after "," comma. ? - The new method bug8212794, includes a test for x-IBM33722. ??? Is that needed since there does not appear to be a change for 33722? Regards, Roger On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: > > > On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix again ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ > I think it looks good but please let someone from core-libs review it > too. > > /Magnus >> >> I just fixed only IBM964 for JDK-8212794. >> (IBM29626C fix is not included) >> >> On non AIX platform (Linux), >> ibm-euctw alias is added for IBM964. >> >> Without fix >> $ jshell >> |? Welcome to JShell -- Version 12-ea >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> With fix >> ====== >> $ jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> On AIX platform >> IBM964 is moved to java.base module from jdk.charset module. >> >> ====== >> $ LANG=zh_TW jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.defaultCharset() >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>> Hello Alan & Magnus. >>> >>> Sorry for you confusion. >>> I did many copy actions and rename actions. >>> So you may see, I added unexpected code into non AIX platform. >>> >>> I think I should not put 2 kind of modification. >>> >>> For this bug id, I'll handle IBM964 and IBM33722. >>> (also SimpleEUCEncoder.java is required) >>> >>> I'll submit code review again. >>> >>> Additionally, I'll touch >>> make/data/charsetmapping/charsets >>> make/data/charsetmapping/stdcs-aix >>> >>> I'll not touch >>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>> >>> My build machine is not so fast, after test is done. >>> I'll post new code. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>> a build perspective, but I'm not sure of what "external" >>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>> regarding character sets in general. >>>>>> >>>>>> I think there is a good opportunity to solve many problems at the >>>>>> same time here, as long as everyone agrees on what is the >>>>>> preferred outcome. >>>>> The support in the build to configure the charsets to include in >>>>> java.base on each platform has been working well. Charsets that >>>>> aren't in java.base go into the jdk.charsets service provider >>>>> module and that has been working well too. From the result point >>>>> of view, perhaps, but definitely not from the build perspective. >>>>> ;-) But yes, I understand this is functionality that should be kept. >>>>> One thing that we lack is some way to add charsets for specific >>>>> platforms and this comes up with the IBM patches where they are >>>>> looking to adding several additional IBM charsets. One starting >>>>> point that we've touched on in several threads here is dropping >>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>> need build support. >>>> So build support for trivially adding specific charsets to specific >>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>> then? >>>> >>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>> that needs build support? >>>> >>>> /Magnus >>>>> >>>>> >>>>> -Alan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Tue Dec 4 03:30:04 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 12:30:04 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Message-ID: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Hello Roger. Thank you for your suggestion. > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > I think this is no longer needed since it only has imports. > By the way, the style is to import each specific class and > avoid wild card imports. "import sun.nio.cs.*;" is required because of SimpleEUCEncoder.java.template. SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. It means that, * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext package I could not determine which package has SimpleEUCEncoder. And same kind code is available on ISO2022_JP.java. Please let me know if you know another way. > TestIBMBugs: > - Please use a style consistent with other methods in the class. > In this case spaces are needed around "{" and "}, and a space > after "," comma. I'll changed. > - The new method bug8212794, includes a test for x-IBM33722. > Is that needed since there does not appear to be a change for > 33722? Yes, it's no need. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, Ichiroh Takiguchi On 2018-12-04 05:50, Roger Riggs wrote: > Hi Ichiroh, > > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > ??? I think this is no longer needed since it only has imports. > ??? By the way, the style is to import each specific class and > avoid wild card imports. > > TestIBMBugs: > ? - Please use a style consistent with other methods in the class. > ??? In this case spaces are needed around "{" and "}, and a space > after "," comma. > > ? - The new method bug8212794, includes a test for x-IBM33722. > ??? Is that needed since there does not appear to be a change for > 33722? > > Regards, Roger > > > On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >> >> >> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix again ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >> I think it looks good but please let someone from core-libs review it >> too. >> >> /Magnus >>> >>> I just fixed only IBM964 for JDK-8212794. >>> (IBM29626C fix is not included) >>> >>> On non AIX platform (Linux), >>> ibm-euctw alias is added for IBM964. >>> >>> Without fix >>> $ jshell >>> |? Welcome to JShell -- Version 12-ea >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> With fix >>> ====== >>> $ jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> On AIX platform >>> IBM964 is moved to java.base module from jdk.charset module. >>> >>> ====== >>> $ LANG=zh_TW jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>> Hello Alan & Magnus. >>>> >>>> Sorry for you confusion. >>>> I did many copy actions and rename actions. >>>> So you may see, I added unexpected code into non AIX platform. >>>> >>>> I think I should not put 2 kind of modification. >>>> >>>> For this bug id, I'll handle IBM964 and IBM33722. >>>> (also SimpleEUCEncoder.java is required) >>>> >>>> I'll submit code review again. >>>> >>>> Additionally, I'll touch >>>> make/data/charsetmapping/charsets >>>> make/data/charsetmapping/stdcs-aix >>>> >>>> I'll not touch >>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>> >>>> My build machine is not so fast, after test is done. >>>> I'll post new code. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> >>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>>> a build perspective, but I'm not sure of what "external" >>>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>>> regarding character sets in general. >>>>>>> >>>>>>> I think there is a good opportunity to solve many problems at the >>>>>>> same time here, as long as everyone agrees on what is the >>>>>>> preferred outcome. >>>>>> The support in the build to configure the charsets to include in >>>>>> java.base on each platform has been working well. Charsets that >>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>> module and that has been working well too. From the result point >>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>> ;-) But yes, I understand this is functionality that should be >>>>>> kept. >>>>>> One thing that we lack is some way to add charsets for specific >>>>>> platforms and this comes up with the IBM patches where they are >>>>>> looking to adding several additional IBM charsets. One starting >>>>>> point that we've touched on in several threads here is dropping >>>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>>> need build support. >>>>> So build support for trivially adding specific charsets to specific >>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>> then? >>>>> >>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>> that needs build support? >>>>> >>>>> /Magnus >>>>>> >>>>>> >>>>>> -Alan >>> >> From volker.simonis at gmail.com Tue Dec 4 08:30:58 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Dec 2018 09:30:58 +0100 Subject: RFR(XS): 8214063: [AIX] Disable symbol visibility flags In-Reply-To: References: <37b6d4e5-2065-2461-0aec-77941033d3ca@oracle.com> Message-ID: Hi Adam, I've just pushed the change: http://hg.openjdk.java.net/jdk/jdk/rev/fc54d27e58d8 Best regards, Volker On Thu, Nov 29, 2018 at 5:54 PM Adam Farley8 wrote: > > Hi All, > > The build passed on xlC 13.1 with the makefile patch I proposed (good catch on the comments Volkar!). > > With Volkar, Erik, Matthias, and Magnus all approving the change, it sounds like we're good to merge! > > Volkar, can you do the honours? > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. I approve the change too. ;) > > > Volker Simonis wrote on 29/11/2018 11:54:33: > > > From: Volker Simonis > > To: Magnus Ihse Bursie > > Cc: build-dev , ppc-aix-port- > > dev at openjdk.java.net, adam.farley at uk.ibm.com > > Date: 29/11/2018 11:54 > > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > > > On Thu, Nov 29, 2018 at 12:20 PM Magnus Ihse Bursie > > wrote: > > > > > > On 2018-11-27 16:33, Volker Simonis wrote: > > > > > > > Hi, > > > > > > > > can I please have a review for the following trivial change which > > > > simply disables the symbol visibility flags on AIX: > > > > > > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=DptrWUUtJCcpUCbCWkkBOeFJCVk5im3hm9T_DcD0Jd8&e= > > > > https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8214063&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=jBFABkJb5E5W9K8pMX794-3gnpLfPyi3oASA1kizQ7A&e= > > > Looks good to me. I am sorry for the mess I caused by optimisically > > > trying to fix things on a platform I could not compile on... :( > > > > > > > Thanks for the review and don't worry! We really appreciate your > > continued help. It's really us who should have tested and spotted the > > problems earlier :) > > > > Regards, > > Volker > > > > > This also reminds me that the visibility flags *really* should move into > > > configure/spec, not be sprinkled like this in the make files. > > > > > > /Magnus > > > > > > > > Change "8202322: AIX: symbol visibility flags not support on xlc 12.1" > > > > [1] blindly introduced these flags for all xlC compiler versions > > > > > 12.1 without ever testing it (which should not have happened). Now > > > > that people are starting to really use xlC 13 it turns out that there > > > > is more to do than just enabling the flags. This future work is > > > > covered by "8204541: Correctly support AIX xlC 13.1 symbol visibility > > > > flags". > > > > > > > > Thank you and best regards, > > > > Volker > > > > > > > > [1] https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=pd7-rH7OPxeaq2g6S0dQPmb_3-8PLi8JZFKcP_Abp6Q&e= > > > > [2] https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8204541&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=q7KHUASpF-opdcLXbTTUT1bPoKrkTeaHTtd7c2jN4rc&e= > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Tue Dec 4 10:42:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Dec 2018 11:42:30 +0100 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> On 2018-12-04 04:30, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I'm not sure I'm fully following the template intricacies here, but would this not be solved if IBM33722.java was made a template as well? Then you could do import $PACKAGE$. SimpleEUCEncoder Or so I'd think. /Magnus > >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. > >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> | Welcome to JShell -- Version 12-ea >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > From takiguc at linux.vnet.ibm.com Tue Dec 4 11:33:27 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 20:33:27 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> Message-ID: <688f9f696141dac6377b065472b79770@linux.vnet.ibm.com> Hello Magnus. IBM33722 should be in sun.nio.cs.ext package on jdk.charset module Because it's not used for default encoding on AIX platform. In case of template file, build tool checks make/data/charsetmapping/stdcs-aix file for this case. If class name is there, it will be migrated to sun.nio.cs package. About IBM33722, If IBM33722 is moved to sun.nio.cs package also, "import sun.nio.cs.*;" is no need on IBM33722.java If IBM33722 is not in stdcs-aix, "import sun.nio.cs.*;" is still required on IBM33722.java Thanks, Ichiroh Takiguchi On 2018-12-04 19:42, Magnus Ihse Bursie wrote: > On 2018-12-04 04:30, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I'm not sure I'm fully following the template intricacies here, but > would this not be solved if IBM33722.java was made a template as well? > Then you could do > import $PACKAGE$. SimpleEUCEncoder > Or so I'd think. > > /Magnus >> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. >> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-ea >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From adam.farley at uk.ibm.com Tue Dec 4 12:08:24 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 4 Dec 2018 12:08:24 +0000 Subject: RFR(XS): 8214063: [AIX] Disable symbol visibility flags In-Reply-To: References: <37b6d4e5-2065-2461-0aec-77941033d3ca@oracle.com> Message-ID: Thanks Volker. :) Best Regards Adam Farley IBM Runtimes Volker Simonis wrote on 04/12/2018 08:30:58: > From: Volker Simonis > To: adam.farley at uk.ibm.com > Cc: build-dev , Magnus Ihse Bursie > , ppc-aix-port-dev at openjdk.java.net > Date: 04/12/2018 08:31 > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > Hi Adam, > > I've just pushed the change: > > INVALID URI REMOVED > u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_fc54d27e58d8&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=NhALBBoEo6HsbPIjB8bJJj30UR8DRP- > PuJckMbmJvA0&s=gLabfGk2XJdLwimruwQdLAmjBXtCueO7qR01_xw5wuw&e= > > Best regards, > Volker > On Thu, Nov 29, 2018 at 5:54 PM Adam Farley8 wrote: > > > > Hi All, > > > > The build passed on xlC 13.1 with the makefile patch I proposed > (good catch on the comments Volkar!). > > > > With Volkar, Erik, Matthias, and Magnus all approving the change, > it sounds like we're good to merge! > > > > Volkar, can you do the honours? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. I approve the change too. ;) > > > > > > Volker Simonis wrote on 29/11/2018 11:54:33: > > > > > From: Volker Simonis > > > To: Magnus Ihse Bursie > > > Cc: build-dev , ppc-aix-port- > > > dev at openjdk.java.net, adam.farley at uk.ibm.com > > > Date: 29/11/2018 11:54 > > > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > > > > > On Thu, Nov 29, 2018 at 12:20 PM Magnus Ihse Bursie > > > wrote: > > > > > > > > On 2018-11-27 16:33, Volker Simonis wrote: > > > > > > > > > Hi, > > > > > > > > > > can I please have a review for the following trivial change which > > > > > simply disables the symbol visibility flags on AIX: > > > > > > > > > > INVALID URI REMOVED > > > > u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=DptrWUUtJCcpUCbCWkkBOeFJCVk5im3hm9T_DcD0Jd8&e= > > > > > INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8214063&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=jBFABkJb5E5W9K8pMX794-3gnpLfPyi3oASA1kizQ7A&e= > > > > Looks good to me. I am sorry for the mess I caused by optimisically > > > > trying to fix things on a platform I could not compile on... :( > > > > > > > > > > Thanks for the review and don't worry! We really appreciate your > > > continued help. It's really us who should have tested and spotted the > > > problems earlier :) > > > > > > Regards, > > > Volker > > > > > > > This also reminds me that the visibility flags *really* shouldmove into > > > > configure/spec, not be sprinkled like this in the make files. > > > > > > > > /Magnus > > > > > > > > > > Change "8202322: AIX: symbol visibility flags not support onxlc 12.1" > > > > > [1] blindly introduced these flags for all xlC compiler versions > > > > > > 12.1 without ever testing it (which should not have happened). Now > > > > > that people are starting to really use xlC 13 it turns out that there > > > > > is more to do than just enabling the flags. This future work is > > > > > covered by "8204541: Correctly support AIX xlC 13.1 symbol visibility > > > > > flags". > > > > > > > > > > Thank you and best regards, > > > > > Volker > > > > > > > > > > [1] INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=pd7-rH7OPxeaq2g6S0dQPmb_3-8PLi8JZFKcP_Abp6Q&e= > > > > > [2] INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8204541&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=q7KHUASpF-opdcLXbTTUT1bPoKrkTeaHTtd7c2jN4rc&e= > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Tue Dec 4 14:36:41 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 09:36:41 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Hi Ichiroh, On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I understand, it is because IBM33722 may or may not be in the same package as SimpleEUCEncoder. It is SimpleEUCEncoder that may be in a different package, not IBM33722. > >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. 226-227:? add a space before "{" to have the same style as line 210. > >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, looks fine. Regards, Roger > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-ea >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Tue Dec 4 15:21:12 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 00:21:12 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: Hello Roger. Thank you for your suggestion. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ Thanks, Ichiroh Takiguchi On 2018-12-04 23:36, Roger Riggs wrote: > Hi Ichiroh, > > On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I understand, it is because IBM33722 may or may not be in the same > package as SimpleEUCEncoder. > It is SimpleEUCEncoder that may be in a different package, not > IBM33722. >> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. > 226-227:? add a space before "{" to have the same style as line 210. >> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, looks fine. > > Regards, Roger > >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-ea >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From Roger.Riggs at oracle.com Tue Dec 4 16:07:22 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:07:22 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: <1c7e7226-7cda-f622-634a-77397467047d@oracle.com> Hi Ichiroh, Looks fine. I can sponsor that for you.? Tomorrow, though, to allow time for any other comments. Thanks, Roger On 12/04/2018 10:21 AM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 23:36, Roger Riggs wrote: >> Hi Ichiroh, >> >> On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >>> Hello Roger. >>> >>> Thank you for your suggestion. >>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>> "import sun.nio.cs.*;" is required because of >>> SimpleEUCEncoder.java.template. >>> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >>> it. >>> It means that, >>> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >>> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >>> package >>> I could not determine which package has SimpleEUCEncoder. >>> And same kind code is available on ISO2022_JP.java. >>> Please let me know if you know another way. >> I understand, it is because IBM33722 may or may not be in the same >> package as SimpleEUCEncoder. >> It is SimpleEUCEncoder that may be in a different package, not IBM33722. >>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>> I'll changed. >> 226-227:? add a space before "{" to have the same style as line 210. >>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>> Yes, it's no need. >>> >>> Could you review the fix again ? >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, looks fine. >> >> Regards, Roger >> >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-12-04 05:50, Roger Riggs wrote: >>>> Hi Ichiroh, >>>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>>> >>>> Regards, Roger >>>> >>>> >>>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> Could you review the fix again ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>>> I think it looks good but please let someone from core-libs review >>>>> it too. >>>>> >>>>> /Magnus >>>>>> >>>>>> I just fixed only IBM964 for JDK-8212794. >>>>>> (IBM29626C fix is not included) >>>>>> >>>>>> On non AIX platform (Linux), >>>>>> ibm-euctw alias is added for IBM964. >>>>>> >>>>>> Without fix >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-ea >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> With fix >>>>>> ====== >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> On AIX platform >>>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>>> >>>>>> ====== >>>>>> $ LANG=zh_TW jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>>> Hello Alan & Magnus. >>>>>>> >>>>>>> Sorry for you confusion. >>>>>>> I did many copy actions and rename actions. >>>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>>> >>>>>>> I think I should not put 2 kind of modification. >>>>>>> >>>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>>> (also SimpleEUCEncoder.java is required) >>>>>>> >>>>>>> I'll submit code review again. >>>>>>> >>>>>>> Additionally, I'll touch >>>>>>> make/data/charsetmapping/charsets >>>>>>> make/data/charsetmapping/stdcs-aix >>>>>>> >>>>>>> I'll not touch >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>>> >>>>>>> My build machine is not so fast, after test is done. >>>>>>> I'll post new code. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> >>>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>>> sets in the build in general. :-( I'd really like to >>>>>>>>>> modernize it. I have a, slightly fuzzy, laundry list of >>>>>>>>>> things I want to fix from a build perspective, but I'm not >>>>>>>>>> sure of what "external" requirements are coming from AIX and >>>>>>>>>> the general core-libs agenda regarding character sets in >>>>>>>>>> general. >>>>>>>>>> >>>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>>> preferred outcome. >>>>>>>>> The support in the build to configure the charsets to include >>>>>>>>> in java.base on each platform has been working well. Charsets >>>>>>>>> that aren't in java.base go into the jdk.charsets service >>>>>>>>> provider module and that has been working well too. From the >>>>>>>>> result point of view, perhaps, but definitely not from the >>>>>>>>> build perspective. ;-) But yes, I understand this is >>>>>>>>> functionality that should be kept. >>>>>>>>> One thing that we lack is some way to add charsets for >>>>>>>>> specific platforms and this comes up with the IBM patches >>>>>>>>> where they are looking to adding several additional IBM >>>>>>>>> charsets. One starting point that we've touched on in several >>>>>>>>> threads here is dropping the EBCDIC charsets from the main >>>>>>>>> stream builds. Going there will need build support. >>>>>>>> So build support for trivially adding specific charsets to >>>>>>>> specific >>>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>>> presume, >>>>>>>> then? >>>>>>>> >>>>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>>>> that needs build support? >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> -Alan >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Tue Dec 4 16:53:18 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 01:53:18 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> Message-ID: <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> Hello again. Could you give me review comment and/or suggestion ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ Thanks, Ichiroh Takiguchi On 2018-11-26 21:27, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 > Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ > > Test instructions and screen shots are in JDK-8212676. > > GUI environment for AIX platform still needs CDE support. > This fix is required to avoid unexpected working behavior on AIX > platform. > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >> Hello. >> >> This fix is really required for AIX's GUI. >> System color setting and window manager's working behavior are very >> important. >> >> I appreciate any feedback, and how I would go about obtaining a >> sponsor and contributor ? >> >> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> webrev file was extracted. >>> Please see >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>> >>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> Webrev.zip file is stored into >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>> >>>> Test programs are also stored: >>>> No testcase is available for FontUtilities.java and >>>> XDecoratedPeer.java. >>>> >>>> MotifColorUtilities.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>> Run SystemColorTest2, system colors should be displayed >>>> AIX sample is >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>> >>>> XWM.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>> On AIX CDE, isMotif and isCDE were true. >>>> On AIX MWM, every entry is false. >>>> >>>> XWindowPeer.java >>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>> frame). >>>> Window focus should not be changed because of "click on focus" >>>> feature. >>>> But input focus is moved to "Non-Focusable" window. >>>> >>>> >>>> On 2018-05-18 01:00, Phil Race wrote: >>>>> I think we'd need to see the actual proposed changes and understand >>>>> the implications >>>>> for ongoing support as we no longer support any platform which has >>>>> a >>>>> CDE desktop. >>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>>> such support rather >>>>> than adding to it. >>>>> >>>>> -phil. >>>>> >>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>> Hello, >>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>> Manager) support to OpenJDK project. >>>>>> >>>>>> I'd like contribute following 5 files: >>>>>> >>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>> M >>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>> Color) [1] >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>> XMapRaised/XMapWindow) >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>> (Detect MWM on AIX platform) >>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>> >>>>>> I appreciate any feedback please, and how I would go about >>>>>> obtaining a sponsor and contributor ? >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> [1] >>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>> From philip.race at oracle.com Tue Dec 4 18:06:52 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 4 Dec 2018 10:06:52 -0800 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> Message-ID: <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> I haven't evaluated the merits of this proposal but this https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html is not the right place to support a flag used in all these X11 files. And why is i18n-dev on the review ? I can't see any I18N related changes. -phil. On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: > Hello again. > > Could you give me review comment and/or suggestion ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 > Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ > > Thanks, > Ichiroh Takiguchi > > On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >> >> Test instructions and screen shots are in JDK-8212676. >> >> GUI environment for AIX platform still needs CDE support. >> This fix is required to avoid unexpected working behavior on AIX >> platform. >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> This fix is really required for AIX's GUI. >>> System color setting and window manager's working behavior are very >>> important. >>> >>> I appreciate any feedback, and how I would go about obtaining a >>> sponsor and contributor ? >>> >>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>> Hello Phil. >>>> >>>> webrev file was extracted. >>>> Please see >>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>> >>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> Webrev.zip file is stored into >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>> >>>>> Test programs are also stored: >>>>> No testcase is available for FontUtilities.java and >>>>> XDecoratedPeer.java. >>>>> >>>>> MotifColorUtilities.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>> Run SystemColorTest2, system colors should be displayed >>>>> AIX sample is >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>> >>>>> XWM.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>> On AIX CDE, isMotif and isCDE were true. >>>>> On AIX MWM, every entry is false. >>>>> >>>>> XWindowPeer.java >>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>> frame). >>>>> Window focus should not be changed because of "click on focus" >>>>> feature. >>>>> But input focus is moved to "Non-Focusable" window. >>>>> >>>>> >>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>> I think we'd need to see the actual proposed changes and understand >>>>>> the implications >>>>>> for ongoing support as we no longer support any platform which has a >>>>>> CDE desktop. >>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>>>> such support rather >>>>>> than adding to it. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello, >>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>> Manager) support to OpenJDK project. >>>>>>> >>>>>>> I'd like contribute following 5 files: >>>>>>> >>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>> M >>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>> Color) [1] >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>> XMapRaised/XMapWindow) >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>> (Detect MWM on AIX platform) >>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>> >>>>>>> I appreciate any feedback please, and how I would go about >>>>>>> obtaining a sponsor and contributor ? >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> >>>>>>> [1] >>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>> > From takiguc at linux.vnet.ibm.com Wed Dec 5 01:10:09 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 10:10:09 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> Message-ID: Hello Phil. > I haven't evaluated the merits of this proposal but this > https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html > is not the right place to support a flag used in all these X11 files. Could you give me your recommendation ? > And why is i18n-dev on the review ? I can't see any I18N related > changes. I thought focus issue was related input method. AIX IM was activated even if focus was moved to non focusable window (middle window). [1] So I posted this issue into I18N, but it was not good. Actually, all key events were forwarded to middle window if user clicked inside of right window. [1] https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png Thanks, Ichiroh Takiguchi On 2018-12-05 03:06, Phil Race wrote: > I haven't evaluated the merits of this proposal but this > https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html > is not the right place to support a flag used in all these X11 files. > > And why is i18n-dev on the review ? I can't see any I18N related > changes. > > -phil. > > On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >> Hello again. >> >> Could you give me review comment and/or suggestion ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212676 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>> >>> Test instructions and screen shots are in JDK-8212676. >>> >>> GUI environment for AIX platform still needs CDE support. >>> This fix is required to avoid unexpected working behavior on AIX >>> platform. >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> This fix is really required for AIX's GUI. >>>> System color setting and window manager's working behavior are very >>>> important. >>>> >>>> I appreciate any feedback, and how I would go about obtaining a >>>> sponsor and contributor ? >>>> >>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>> Hello Phil. >>>>> >>>>> webrev file was extracted. >>>>> Please see >>>>> ? http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>> >>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>> Hello Phil. >>>>>> >>>>>> Webrev.zip file is stored into >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>> >>>>>> Test programs are also stored: >>>>>> No testcase is available for FontUtilities.java and >>>>>> XDecoratedPeer.java. >>>>>> >>>>>> MotifColorUtilities.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>> Run SystemColorTest2, system colors should be displayed >>>>>> AIX sample is >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>> >>>>>> XWM.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>> On AIX MWM, every entry is false. >>>>>> >>>>>> XWindowPeer.java >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>> frame). >>>>>> Window focus should not be changed because of "click on focus" >>>>>> feature. >>>>>> But input focus is moved to "Non-Focusable" window. >>>>>> >>>>>> >>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>> I think we'd need to see the actual proposed changes and >>>>>>> understand >>>>>>> the implications >>>>>>> for ongoing support as we no longer support any platform which >>>>>>> has a >>>>>>> CDE desktop. >>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping >>>>>>> out >>>>>>> such support rather >>>>>>> than adding to it. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>> Hello, >>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>> Manager) support to OpenJDK project. >>>>>>>> >>>>>>>> I'd like contribute following 5 files: >>>>>>>> >>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>>> M >>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>> Color) [1] >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>> XMapRaised/XMapWindow) >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>> (Detect MWM on AIX platform) >>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>>> >>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>> obtaining a sponsor and contributor ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ichiroh Takiguchi >>>>>>>> IBM Japan, Ltd. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>> >> From philip.race at oracle.com Wed Dec 5 01:11:17 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Dec 2018 17:11:17 -0800 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> <5a4f9f5c7a80a5abda9edd150e19a11f@linux.vnet.ibm.com> <4addeebf-9ed8-bb63-5920-49ae6fb429b1@oracle.com> Message-ID: <5C0725B5.3080907@oracle.com> On 12/4/18, 5:10 PM, Ichiroh Takiguchi wrote: > Hello Phil. > >> I haven't evaluated the merits of this proposal but this >> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >> >> is not the right place to support a flag used in all these X11 files. > Could you give me your recommendation ? Somewhere closer to the code that needs it. > >> And why is i18n-dev on the review ? I can't see any I18N related >> changes. > I thought focus issue was related input method. No. I mean input focus is necessary for input methods but focus does not automatically mean input methods are in play. -phil > AIX IM was activated even if focus was moved to non focusable window > (middle window). [1] > So I posted this issue into I18N, but it was not good. > Actually, all key events were forwarded to middle window if user > clicked inside of right window. > > [1] > https://bugs.openjdk.java.net/secure/attachment/79986/aix-focusable.png > > Thanks, > Ichiroh Takiguchi > > On 2018-12-05 03:06, Phil Race wrote: >> I haven't evaluated the merits of this proposal but this >> https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/src/java.desktop/share/classes/sun/font/FontUtilities.java.udiff.html >> >> is not the right place to support a flag used in all these X11 files. >> >> And why is i18n-dev on the review ? I can't see any I18N related >> changes. >> >> -phil. >> >> On 12/4/18 8:53 AM, Ichiroh Takiguchi wrote: >>> Hello again. >>> >>> Could you give me review comment and/or suggestion ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-11-26 21:27, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ >>>> >>>> Test instructions and screen shots are in JDK-8212676. >>>> >>>> GUI environment for AIX platform still needs CDE support. >>>> This fix is required to avoid unexpected working behavior on AIX >>>> platform. >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-06-18 18:57, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> This fix is really required for AIX's GUI. >>>>> System color setting and window manager's working behavior are >>>>> very important. >>>>> >>>>> I appreciate any feedback, and how I would go about obtaining a >>>>> sponsor and contributor ? >>>>> >>>>> On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >>>>>> Hello Phil. >>>>>> >>>>>> webrev file was extracted. >>>>>> Please see >>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >>>>>> >>>>>> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>>>>>> Hello Phil. >>>>>>> >>>>>>> Webrev.zip file is stored into >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>>>>>> >>>>>>> Test programs are also stored: >>>>>>> No testcase is available for FontUtilities.java and >>>>>>> XDecoratedPeer.java. >>>>>>> >>>>>>> MotifColorUtilities.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>>>>>> Run SystemColorTest2, system colors should be displayed >>>>>>> AIX sample is >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>>>>>> >>>>>>> XWM.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>>>>>> On AIX CDE, isMotif and isCDE were true. >>>>>>> On AIX MWM, every entry is false. >>>>>>> >>>>>>> XWindowPeer.java >>>>>>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>>>>>> On AIX CDE, click inside of "Non-Focusable" window (not window >>>>>>> frame). >>>>>>> Window focus should not be changed because of "click on focus" >>>>>>> feature. >>>>>>> But input focus is moved to "Non-Focusable" window. >>>>>>> >>>>>>> >>>>>>> On 2018-05-18 01:00, Phil Race wrote: >>>>>>>> I think we'd need to see the actual proposed changes and >>>>>>>> understand >>>>>>>> the implications >>>>>>>> for ongoing support as we no longer support any platform which >>>>>>>> has a >>>>>>>> CDE desktop. >>>>>>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping >>>>>>>> out >>>>>>>> such support rather >>>>>>>> than adding to it. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>>>>>> Hello, >>>>>>>>> IBM would like to contribute AIX's CDE (Common Desktop >>>>>>>>> Environment) DTWM (Desktop Window Manager) /MWM (Motif Window >>>>>>>>> Manager) support to OpenJDK project. >>>>>>>>> >>>>>>>>> I'd like contribute following 5 files: >>>>>>>>> >>>>>>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>>>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>>>>>> M >>>>>>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>>>>>> >>>>>>>>> (Add High Color support on CDE, OpenJDK just supports Medium >>>>>>>>> Color) [1] >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>>>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>>>>>> XMapRaised/XMapWindow) >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>>>>>> (Detect MWM on AIX platform) >>>>>>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>>>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>>>>>> DTWM/MWM does not have enough features for ICCCM) >>>>>>>>> >>>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>>> obtaining a sponsor and contributor ? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ichiroh Takiguchi >>>>>>>>> IBM Japan, Ltd. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>>>>>> >>> > From GROEGES at uk.ibm.com Wed Dec 5 10:50:12 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 5 Dec 2018 10:50:12 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> Message-ID: Posting this to net-dev as well as ppc-aix-port-dev as this may be a more appropriate mailing list to get responses about networking. I have performed the test Volker mentioned in an earlier post (on xLinux machine, remove the ipv6 address from the ens32 interface but leaving inte6 enabled on the system). With this configuration the jdk/java/net/MulticastSocket/JoinLeave.java test still passes, whereas on AIX with a similar configuration the test fails. For those with knowledge of networking, should this MulticastSocket test pass if there is no ipv6 address enabled for the interface being used. On AIX the setsockopt the call to the mcast_set_if_by_if_v6 function in PlainDatagramSocketImpl.c returns an EADDRNOTAVAIL, whereas on xLinux it doesnt throw an error. Is this as expected? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Volker Simonis To: Steve Groeger Cc: "Lindenmaier, Goetz" , ppc-aix-port-dev at openjdk.java.net, Java Core Libs Date: 30/11/2018 16:28 Subject: Re: 8207404: MulticastSocket tests failing on Aix On Fri, Nov 30, 2018 at 12:20 PM Steve Groeger wrote: > > Hi Goetz, > > I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as > they detected that IPv6 is not enabled and then didnt try and set the IPv6 > options. Not being a network expert either, I think there's two things to consider here. It seems that IPv6 can be disabled globally (e.g. in the Linux kernel) or IPv6 can be enabled globally, but not all network devices supporting it. A quick search revealed that it seems to be fairly easy to disable IPv6 on a single interface on Linux while still having IPv6 globally enabled (see https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux ). @Steve Groeger can you please check if the test still succeeds on Linux if you only disable IPv6 on the specific interface used by the test? If it still succeeds, there's probably something to fix on AIX. If it fails on Linux as well, there may be something to fix in the test (i.e. to detect that the corresponding interface doesn't support IPv6) or even in the Java network implementation (i.e. to handle both, IPv6 and IPv4-only interfaces on an IPv6 enabled system correctly). Thank you and best regards, Volker > I am currently unable to disable IPv6 on my AIX box to test this but would > assume it would also work as the code checks to see whether IPv6 is > enabled and doesnt try and set the IPV6 options. > It seems the issue with the tests failing seems to be, if IPv6 is enabled > but the interface doesn't have an IPv6 address associated with it, as in > your case here: > > bash-4.3$ ifconfig -a > en0: > flags=1e084863,480 > inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > lo0: > flags=e08084b,c0 > inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx > inet6 ::1%1/0 > tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 > > where you can see that the en0 interface has an inet address associated > but doesnt have an inet6 address associated. > I can see that IPv6 is enabled as the lo0 interface has an inet6 address > (pointing to localhost) > > As I stated below, my AIX system was configured in a similar way to yours > and the tests failed. When I was able to add an inet6 address to en0, > everything works correctly. > NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to > add the inet6 address to my en0 interface. After that all tests worked. > > So I think the tests are working as expected, but the AIX system is not > configured correctly, but I would like someone else to confirm this. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: "Lindenmaier, Goetz" > To: Steve Groeger , ppc-aix-port-dev > > Date: 30/11/2018 10:18 > Subject: RE: 8207404: MulticastSocket tests failing on Aix > > > > i Steve, > > thanks for looking at this issue. > > > Should these tests work without having IPV6 configured on the interface? > In general, tests should not show errors if a system does not meet > the requirements for the test. In such cases the test should > be skipped somehow. Maybe only a test fix is needed. > > Can you check on a non-aix machine without ipv6 whether the test > passes? > > > Goetz, do you have IPV6 configured on the machine you were running these > > tests on? > This is our test machine: > > bash-4.3$ ifconfig -a > en0: > flags=1e084863,480 > inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > lo0: > flags=e08084b,c0 > inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx > inet6 ::1%1/0 > tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 > > I think this message should be posted to core-libs-dev, too. That's also > the list where a potential fix needs to be reviewed. > > Best regards, > Goetz. > > > > -----Original Message----- > > From: Steve Groeger > > Sent: Donnerstag, 29. November 2018 17:07 > > To: ppc-aix-port-dev > > Cc: Lindenmaier, Goetz > > Subject: 8207404: MulticastSocket tests failing on Aix > > > > Hi All, > > > > I have been having a look at this issue: > > > https://bugs.openjdk.java.net/browse/JDK-8207404 > > > < > https://bugs.openjdk.java.net/browse/JDK-8207404 > > > > which was raised by Goetz Lindenmaier. > > > > When I ran the tests on my AIX system I got the same results as Goetz > listed > > in the issue. > > > > Looking at the failure I noticed that it was failing on a setsockopt > call in the > > native code in > > the PlainDatagramSocketImpl.c file which returned a EADDRNOTAVAIL (Can't > > assign requested address) > > > > Looking at my network configuration using "ifconfig -a", I noticed that > my > > interface "en0" which the test > > was trying to use did not have an inet6 address configured (see below - > some > > addresses have been obfuscated with x's). > > > > en0: > > flags=1e084863,14c0 > CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> > > inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx > > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > > > > configuring the IPV6 on my AIX box I then had a inet6 address configured > for > > en0 > > > > en0: > > flags=1e084863,14c0 > CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> > > inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx > > inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 > > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > > > > with this configured the MulticastSocket tests all passed. > > > > Should these tests work without having IPV6 configured on the interface? > > > > Goetz, do you have IPV6 configured on the machine you were running these > > tests on? > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, UK > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Thu Dec 6 10:56:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 06 Dec 2018 19:56:25 +0900 Subject: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From GROEGES at uk.ibm.com Thu Dec 6 15:25:33 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Thu, 6 Dec 2018 15:25:33 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Message-ID: Hi all, I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 @@ -446,7 +446,7 @@ ProcessBuilder.NullOutputStream.INSTANCE : new ProcessPipeOutputStream(fds[0]); - stdout = (fds[1] == -1) ? + stdout = (fds[1] == -1 || forceNullOutputStream) ? ProcessBuilder.NullInputStream.INSTANCE : new DeferredCloseProcessPipeInputStream(fds[1]); I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Thu Dec 6 17:05:13 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 07 Dec 2018 02:05:13 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. (I'm sorry, I made a mistake, I forgot to change Subject) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From volker.simonis at gmail.com Fri Dec 7 08:05:01 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Dec 2018 09:05:01 +0100 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi Steve, thanks a lot for this fix. I'm forwarding this to core-libs-dev as well, because that's where the review has to take place. The "ppc-aix-port-dev" list is mostly a marker for the port maintainers to get their attention on relevant changes (so cross-posting is fine in this case :) On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger wrote: > > Hi all, > > I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the > jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: > > > diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 > @@ -446,7 +446,7 @@ > ProcessBuilder.NullOutputStream.INSTANCE : > new ProcessPipeOutputStream(fds[0]); > > - stdout = (fds[1] == -1) ? > + stdout = (fds[1] == -1 || forceNullOutputStream) ? > ProcessBuilder.NullInputStream.INSTANCE : > new DeferredCloseProcessPipeInputStream(fds[1]); > Your change looks good and I can sponsor it. Just as a hint for other reviewers I'd like to mention that this change, albeit in a shared Java file, is still AIX-only because it is in the "AIX" case of a switch statement. @Steve: can you please verify, that your change introduces no regression by running the complete jtreg test suite. Thank you and best regards, Volker > I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. > > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From goetz.lindenmaier at sap.com Fri Dec 7 13:51:23 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Dec 2018 13:51:23 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi Steve, Thanks for this fix! I made a webrev for it, and also would sponsor it: http://cr.openjdk.java.net/~goetz/wr18/sgroeger/8211844-aix_pipe_proc/01/ I also added a patch to remove the test from the problem list. The ProblemList is used to exclude tests known to be failing. I think this needs to be reviewed on hotspot-runtime-dev. But I'm not sure, maybe core-libs-dev is the better list. If you post there, point me to it (in case I miss it) and I'll send a formal review. I also put it into our testing. Should this be fixed for Solaris, too? I didn't see the problem there, though. Best regards, Goetz. From: Steve Groeger Sent: Thursday, December 6, 2018 4:26 PM To: ppc-aix-port-dev Cc: Lindenmaier, Goetz Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Hi all, I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 @@ -446,7 +446,7 @@ ProcessBuilder.NullOutputStream.INSTANCE : new ProcessPipeOutputStream(fds[0]); - stdout = (fds[1] == -1) ? + stdout = (fds[1] == -1 || forceNullOutputStream) ? ProcessBuilder.NullInputStream.INSTANCE : new DeferredCloseProcessPipeInputStream(fds[1]); I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From GROEGES at uk.ibm.com Fri Dec 7 14:14:57 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Fri, 7 Dec 2018 14:14:57 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi Goetz, Thanks for creating the webrev. If there are reviewers that can look at your webrev that would be great. Volker had posted this onto core-libs-dev here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057184.html I am currently running the full set of JTReg tests, as per Volker's request, and will post the results when complete. Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: "Lindenmaier, Goetz" To: 'Steve Groeger' , ppc-aix-port-dev Date: 07/12/2018 13:51 Subject: RE: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Hi Steve, Thanks for this fix! I made a webrev for it, and also would sponsor it: http://cr.openjdk.java.net/~goetz/wr18/sgroeger/8211844-aix_pipe_proc/01/ I also added a patch to remove the test from the problem list. The ProblemList is used to exclude tests known to be failing. I think this needs to be reviewed on hotspot-runtime-dev. But I?m not sure, maybe core-libs-dev is the better list. If you post there, point me to it (in case I miss it) and I?ll send a formal review. I also put it into our testing. Should this be fixed for Solaris, too? I didn?t see the problem there, though. Best regards, Goetz. From: Steve Groeger Sent: Thursday, December 6, 2018 4:26 PM To: ppc-aix-port-dev Cc: Lindenmaier, Goetz Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. Hi all, I have been investigating the issue https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz Lindenmaier which is related to the jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. Having done some investigation I have a potential fix fore the issue: diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 14:28:19 2018 +0300 +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 15:01:03 2018 +0000 @@ -446,7 +446,7 @@ ProcessBuilder.NullOutputStream.INSTANCE : new ProcessPipeOutputStream(fds[0]); - stdout = (fds[1] == -1) ? + stdout = (fds[1] == -1 || forceNullOutputStream) ? ProcessBuilder.NullInputStream.INSTANCE : new DeferredCloseProcessPipeInputStream(fds[1]); I would appreciate any feedback please, and for someone to be a sponsor for this and to contributute it to OpenJDK. Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Dec 7 14:51:13 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Dec 2018 14:51:13 +0000 Subject: JDK-8211844 [aix] ProcessBuilder: Piping between created processes does not work. In-Reply-To: References: Message-ID: Hi, To me, the change looks good, too. I just wondered whether solaris needs to be fixed, too. But I don?t see the test failing on solaris. The bug needs to be removed from the ProblemList in the change, though. See also http://cr.openjdk.java.net/~goetz/wr18/sgroeger/8211844-aix_pipe_proc/01/ I would sponsor this issue. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Volker Simonis > Sent: Friday, December 7, 2018 9:05 AM > To: Steve Groeger ; Java Core Libs dev at openjdk.java.net> > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: JDK-8211844 [aix] ProcessBuilder: Piping between created > processes does not work. > > Hi Steve, > > thanks a lot for this fix. I'm forwarding this to core-libs-dev as > well, because that's where the review has to take place. The > "ppc-aix-port-dev" list is mostly a marker for the port maintainers to > get their attention on relevant changes (so cross-posting is fine in > this case :) > > On Thu, Dec 6, 2018 at 4:26 PM Steve Groeger > wrote: > > > > Hi all, > > > > I have been investigating the issue > https://bugs.openjdk.java.net/browse/JDK-8211844 raised by Goetz > Lindenmaier which is related to the > > jdk/java/lang/ProcessBuilder/PipelineTest.java JTReg test failing on AIX. > Having done some investigation I have a potential fix fore the issue: > > > > > > diff -r 9501a7b59111 src/java.base/unix/classes/java/lang/ProcessImpl.java > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java Mon Dec 03 > 14:28:19 2018 +0300 > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java Thu Dec 06 > 15:01:03 2018 +0000 > > @@ -446,7 +446,7 @@ > > ProcessBuilder.NullOutputStream.INSTANCE : > > new ProcessPipeOutputStream(fds[0]); > > > > - stdout = (fds[1] == -1) ? > > + stdout = (fds[1] == -1 || forceNullOutputStream) ? > > ProcessBuilder.NullInputStream.INSTANCE : > > new DeferredCloseProcessPipeInputStream(fds[1]); > > > > Your change looks good and I can sponsor it. Just as a hint for other > reviewers I'd like to mention that this change, albeit in a shared > Java file, is still AIX-only because it is in the "AIX" case of a > switch statement. > > @Steve: can you please verify, that your change introduces no > regression by running the complete jtreg test suite. > > Thank you and best regards, > Volker > > > I would appreciate any feedback please, and for someone to be a sponsor > for this and to contributute it to OpenJDK. > > > > Steve Groeger > > IBM Runtime Technologies > > Hursley, Winchester > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU From Roger.Riggs at oracle.com Fri Dec 7 20:20:32 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 15:20:32 -0500 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Message-ID: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> Hi, It is a nice feature that charsets are selected at build time using the stdcs-xxx files. This change breaks that pattern and embeds os specific information in more than one place. That does not seem like an improvement.? Is there any alternative? Thanks, Roger On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote: > Hello. > (I'm sorry, I made a mistake, I forgot to change Subject) > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ > > IBM29626C charset is required for AIX default charset. > Java cannot start because of java/lang/ExceptionInInitializerError on > AIX ja_JP locale. > > To build team, > I'd like to change following charsetmapping tool. > * make/jdk/src/classes/build/tools/charsetmapping/Main.java > * make/jdk/src/classes/build/tools/charsetmapping/SPI.java > * make/jdk/src/classes/build/tools/charsetmapping/SRC.java > > build.tools.charsetmapping,Main supports "os" tag, but it seems it's > not used. > Currently, "os" supports "windows" or "unix". > I extended "os" tag's feature. > If "os aix" is there, this charset is only added into AIX platform. > (I assume "type template" should be used) > "aix" comes from "stdcs-aix" file name. > ====== > charset x-IBM29626C IBM29626C > ??? package sun.nio.cs.ext > ??? type??? template > ??? os????? aix?????? <===== > ??? alias?? cp29626C?????????????? # JDK historical > ??? alias?? ibm29626C > ??? alias?? ibm-29626C > ??? alias?? 29626C > ??? alias?? ibm-eucjp > ====== > > If cs.os is null, > this charset is stored into gensrc directory. > Charset name is added into StandardCharsets.java or ExtendedCharsets.java > If cs.os is "false", > this charset is NOT stored into gensrc directory. > Charset name is NOT added into StandardCharsets.java or > ExtendedCharsets.java > > "os" tag supports multiple entries by using ",", like "aix,linux" > Then we can store new charset into > src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory > > > $ locale charmap > IBM-eucJP > $ jshell > |? JShell????? --????? 12-internal > |??????????????????? : /help intro > > jshell> var cs = java.nio.charset.Charset.defaultCharset() > cs ==> x-IBM29626C > > jshell> cs.getClass().getName() > $2 ==> "sun.nio.cs.IBM29626C" > > jshell> System.out.println(String.join("\n", cs.aliases())) > cp29626C > ibm-29626C > ibm-eucjp > ibm29626C > 29626C > > jshell> /exit > | > $ > > I tested Linux and Windows build. > ====== > $ grep 29626 build.log > IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template? false > > $ find support/gensrc/? | grep 29626 > > $ find support/gensrc/? | grep Charsets > support/gensrc/java.base/sun/nio/cs/StandardCharsets.java > support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java > > $ find support/gensrc/? | grep Charsets | xargs grep 29626 > > $ > ====== > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >> On 2018-11-28 10:36, Alan Bateman wrote: >>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>> I'm quite unsatisfied with the current handling of character sets >>>> in the build in general. :-( I'd really like to modernize it. I >>>> have a, slightly fuzzy, laundry list of things I want to fix from a >>>> build perspective, but I'm not sure of what "external" requirements >>>> are coming from AIX and the general core-libs agenda regarding >>>> character sets in general. >>>> >>>> I think there is a good opportunity to solve many problems at the >>>> same time here, as long as everyone agrees on what is the preferred >>>> outcome. >>> The support in the build to configure the charsets to include in >>> java.base on each platform has been working well. Charsets that >>> aren't in java.base go into the jdk.charsets service provider module >>> and that has been working well too. From the result point of view, >>> perhaps, but definitely not from the build perspective. ;-) But yes, >>> I understand this is functionality that should be kept. >>> One thing that we lack is some way to add charsets for specific >>> platforms and this comes up with the IBM patches where they are >>> looking to adding several additional IBM charsets. One starting >>> point that we've touched on in several threads here is dropping the >>> EBCDIC charsets from the main stream builds. Going there will need >>> build support. >> So build support for trivially adding specific charsets to specific >> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >> then? >> >> Can you expand on the issue of dropping ebcdic? What's the problem >> that needs build support? >> >> /Magnus >>> >>> >>> -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Mon Dec 10 11:01:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 12:01:08 +0100 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> Message-ID: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> On 2018-12-07 21:20, Roger Riggs wrote: > Hi, > > It is a nice feature that charsets are selected at build time using > the stdcs-xxx files. > This change breaks that pattern and embeds os specific information in > more than one place. > That does not seem like an improvement. Is there any alternative? I agree. Why is it not enough just to add it to stdcs-aix? /Magnus > > Thanks, Roger > > > On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote: >> Hello. >> (I'm sorry, I made a mistake, I forgot to change Subject) >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 >> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ >> >> IBM29626C charset is required for AIX default charset. >> Java cannot start because of java/lang/ExceptionInInitializerError on >> AIX ja_JP locale. >> >> To build team, >> I'd like to change following charsetmapping tool. >> * make/jdk/src/classes/build/tools/charsetmapping/Main.java >> * make/jdk/src/classes/build/tools/charsetmapping/SPI.java >> * make/jdk/src/classes/build/tools/charsetmapping/SRC.java >> >> build.tools.charsetmapping,Main supports "os" tag, but it seems it's >> not used. >> Currently, "os" supports "windows" or "unix". >> I extended "os" tag's feature. >> If "os aix" is there, this charset is only added into AIX platform. >> (I assume "type template" should be used) >> "aix" comes from "stdcs-aix" file name. >> ====== >> charset x-IBM29626C IBM29626C >> package sun.nio.cs.ext >> type template >> os aix <===== >> alias cp29626C # JDK historical >> alias ibm29626C >> alias ibm-29626C >> alias 29626C >> alias ibm-eucjp >> ====== >> >> If cs.os is null, >> this charset is stored into gensrc directory. >> Charset name is added into StandardCharsets.java or >> ExtendedCharsets.java >> If cs.os is "false", >> this charset is NOT stored into gensrc directory. >> Charset name is NOT added into StandardCharsets.java or >> ExtendedCharsets.java >> >> "os" tag supports multiple entries by using ",", like "aix,linux" >> Then we can store new charset into >> src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory >> >> >> $ locale charmap >> IBM-eucJP >> $ jshell >> | JShell -- 12-internal >> | : /help intro >> >> jshell> var cs = java.nio.charset.Charset.defaultCharset() >> cs ==> x-IBM29626C >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.IBM29626C" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> cp29626C >> ibm-29626C >> ibm-eucjp >> ibm29626C >> 29626C >> >> jshell> /exit >> | >> $ >> >> I tested Linux and Windows build. >> ====== >> $ grep 29626 build.log >> IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false >> >> $ find support/gensrc/ | grep 29626 >> >> $ find support/gensrc/ | grep Charsets >> support/gensrc/java.base/sun/nio/cs/StandardCharsets.java >> support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java >> >> $ find support/gensrc/ | grep Charsets | xargs grep 29626 >> >> $ >> ====== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>> On 2018-11-28 10:36, Alan Bateman wrote: >>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>> I'm quite unsatisfied with the current handling of character sets >>>>> in the build in general. :-( I'd really like to modernize it. I >>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>> a build perspective, but I'm not sure of what "external" >>>>> requirements are coming from AIX and the general core-libs agenda >>>>> regarding character sets in general. >>>>> >>>>> I think there is a good opportunity to solve many problems at the >>>>> same time here, as long as everyone agrees on what is the >>>>> preferred outcome. >>>> The support in the build to configure the charsets to include in >>>> java.base on each platform has been working well. Charsets that >>>> aren't in java.base go into the jdk.charsets service provider >>>> module and that has been working well too. From the result point of >>>> view, perhaps, but definitely not from the build perspective. ;-) >>>> But yes, I understand this is functionality that should be kept. >>>> One thing that we lack is some way to add charsets for specific >>>> platforms and this comes up with the IBM patches where they are >>>> looking to adding several additional IBM charsets. One starting >>>> point that we've touched on in several threads here is dropping the >>>> EBCDIC charsets from the main stream builds. Going there will need >>>> build support. >>> So build support for trivially adding specific charsets to specific >>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>> then? >>> >>> Can you expand on the issue of dropping ebcdic? What's the problem >>> that needs build support? >>> >>> /Magnus >>>> >>>> >>>> -Alan >> > From Alan.Bateman at oracle.com Mon Dec 10 11:50:47 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 11:50:47 +0000 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: On 10/12/2018 11:01, Magnus Ihse Bursie wrote: > On 2018-12-07 21:20, Roger Riggs wrote: >> Hi, >> >> It is a nice feature that charsets are selected at build time using >> the stdcs-xxx files. >> This change breaks that pattern and embeds os specific information in >> more than one place. >> That does not seem like an improvement.? Is there any alternative? > I agree. Why is it not enough just to add it to stdcs-aix? My reading of the patch is that the "os" key is to avoid generating it on non-AIX platforms, it will otherwise end up in jdk.charsets on non-AIX platforms. The general direction is welcome but I think further work and discussion will be needed to get the right set of changes to support filtering in the build. It can probably be separated from the changes to add IBM-29626C to AIX's java.base. -Alan From takiguc at linux.vnet.ibm.com Mon Dec 10 12:21:23 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 10 Dec 2018 21:21:23 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: Hello Roger, Magnus and Alan. I may need to put alias information into charsets file. stdcs-xxx cannot handle this information... Still AIX needs IBM-29626C charset for default encoding... I appreciate if you give me further suggestions. Thanks, Ichiroh Takiguchi On 2018-12-10 20:50, Alan Bateman wrote: > On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >> On 2018-12-07 21:20, Roger Riggs wrote: >>> Hi, >>> >>> It is a nice feature that charsets are selected at build time using >>> the stdcs-xxx files. >>> This change breaks that pattern and embeds os specific information in >>> more than one place. >>> That does not seem like an improvement.? Is there any alternative? >> I agree. Why is it not enough just to add it to stdcs-aix? > My reading of the patch is that the "os" key is to avoid generating it > on non-AIX platforms, it will otherwise end up in jdk.charsets on > non-AIX platforms. The general direction is welcome but I think > further work and discussion will be needed to get the right set of > changes to support filtering in the build. It can probably be > separated from the changes to add IBM-29626C to AIX's java.base. > > -Alan From OGATAK at jp.ibm.com Tue Dec 11 09:00:09 2018 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 11 Dec 2018 18:00:09 +0900 Subject: [8u] RFR(v2) for backport of JDK-8188868: PPC64: Support AES intrinsics on Big Endian Message-ID: Hi, May I get reviews for revised request for enhancement backport of JDK-8188868: PPC64: Support AES intrinsics on Big Endian [12]? After the discussion in Nov. [13], I found that some older patches also need to be backported to reduce the amount of manual changes. So the following is the final list (newer one first) of backported patches, with comments how I modified them. I ran JTREG in CentOS7 BE on POWER8 using each of debug build after applying [4] and newer and the release build of [1], and found no degradation by these patches. I also verified that the code [1] was built and ran in Ubuntu ppc64le correctly. [1] 8188868: PPC64: Support AES intrinsics on Big Endian Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/9d337e48b178 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8188868/webrev.01/ Comments: No conflict. [2] 8185979: PPC64: Implement SHA2 intrinsic Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/f4962ab855b6 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185979/webrev.01/ Comments: Fixed difference of intrinsic calling convention by passing additional argument word for each Long parameter. Also modified test code support ppc. [3] 8185969: PPC64: Improve VSR support to use up to 64 registers Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/057f21a10f5f Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185969/webrev.01/ Comments: Cherry picked MTVSRWA_OPCODE from [11]. [4] 8185975: PPC64: Fix vsldoi interface according to the ISA Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/1bf8c1e8b79a Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8185975/webrev.01/ Comments: Applied cleanly. This is the same change as what Gustavo requested RFA to 8u-dev ML last week [14] (besides the copyright dates because they are already updated in the patches below). Since this patch has no conflict with other changes, we can skip this one when [14] was approved. [5] 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/f1e6a21095f5 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8166684/webrev.01/ Comments: Applied cleanly. [6] 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/987528901b83 Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8158232/webrev.01/ Comments: No conflict, but applied manually because patch command got confused and failed to find the code to apply. [7] 8154156: PPC64: improve array copy stubs by using vector instructions Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.01/ Comments: This patch cherry picked config_dscr() and its dependent code from [9,10] and has_mfdscr() from [8]. Cherry picked patches: [8] 8149655: PPC64: Implement CompactString intrinsics http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982 [9] 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" http://hg.openjdk.java.net/jdk/jdk/rev/12ccf8b26eb0 [10] 8077838: Recent developments for ppc. http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf [11] 8181809: PPC64: Leverage mtfprd/mffprd on POWER8 http://hg.openjdk.java.net/jdk/jdk/rev/3fd9b25850f4 Other references: [12] https://bugs.openjdk.java.net/browse/JDK-8188868 [13] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-November/003746.html [14] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-December/008276.html Regards, Ogata From HORIE at jp.ibm.com Wed Dec 12 14:49:46 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 12 Dec 2018 23:49:46 +0900 Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 Message-ID: Dear all, Would you please review the following change? This change supports FMA vectorization on PPC64. Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java It showed ~50% reduction in the execution time. I also tested with JTREG and there was no difference in the results compared to the original. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Wed Dec 12 15:53:25 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 12 Dec 2018 15:53:25 +0000 Subject: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: References: Message-ID: Hi Michihiro, this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. Best regards, Martin From: Michihiro Horie Sent: Mittwoch, 12. Dezember 2018 15:50 To: ppc-aix-port-dev at openjdk.java.net; hotspot compiler Cc: Gustavo Romero ; Doerr, Martin ; Simonis, Volker Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 Dear all, Would you please review the following change? This change supports FMA vectorization on PPC64. Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java It showed ~50% reduction in the execution time. I also tested with JTREG and there was no difference in the results compared to the original. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Wed Dec 12 22:39:06 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 12 Dec 2018 20:39:06 -0200 Subject: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: References: Message-ID: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: > this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. Michi, the change looks good to me too. I've tested it on POWER8 and on POWER9 and observed a reduction of ~30% on my POWER8, but on my POWER9 (Witherspoon) it was ~80%, so it can be even better on a Boston (POWER9 too) machine. Thus, thumbs up from my side. I can sponsor that change but I'll wait an ack. from SAP that it's ok for pushing. Maybe Martin wants to perform additional tests after his first review or others might want to review too... I'm wondering if it would be reasonable to run JCK/TCK against it. Would it test Math.fma() since it's a 9+ method and needs a warmed up JVM? Unfortunately I can't run the JCK/TCK against it myself if it applies here. Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Mittwoch, 12. Dezember 2018 15:50 > *To:* ppc-aix-port-dev at openjdk.java.net; hotspot compiler > *Cc:* Gustavo Romero ; Doerr, Martin ; Simonis, Volker > *Subject:* RFR: 8215262: PPC64: FMA Vectorization on PPC64 > > Dear all, > > Would you please review the following change? > This change supports FMA vectorization on PPC64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 > Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ > > Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java > It showed ~50% reduction in the execution time. > > I also tested with JTREG and there was no difference in the results compared to the original. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > From HORIE at jp.ibm.com Wed Dec 12 22:55:37 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 13 Dec 2018 07:55:37 +0900 Subject: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: References: Message-ID: Hi Martin, Thanks a lot for your review and testing on your side. Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , hotspot compiler Cc: Gustavo Romero , "Simonis, Volker" Date: 2018/12/13 00:53 Subject: RE: 8215262: PPC64: FMA Vectorization on PPC64 Hi Michihiro, this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. Best regards, Martin From: Michihiro Horie Sent: Mittwoch, 12. Dezember 2018 15:50 To: ppc-aix-port-dev at openjdk.java.net; hotspot compiler Cc: Gustavo Romero ; Doerr, Martin ; Simonis, Volker Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 Dear all, Would you please review the following change? This change supports FMA vectorization on PPC64. Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java It showed ~50% reduction in the execution time. I also tested with JTREG and there was no difference in the results compared to the original. Best regards, -- Michihiro, IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From HORIE at jp.ibm.com Wed Dec 12 23:05:05 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 13 Dec 2018 08:05:05 +0900 Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> References: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Thanks a lot. It's great to have ~80% reduction on POWER9 Witherspoon. Best regards, -- Michihiro, IBM Research - Tokyo From: "Gustavo Romero" To: "Doerr, Martin" , Michihiro Horie/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net" , "hotspot compiler" Cc: "Simonis, Volker" Date: 2018/12/13 07:39 Subject: Re: 8215262: PPC64: FMA Vectorization on PPC64 Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: > this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. Michi, the change looks good to me too. I've tested it on POWER8 and on POWER9 and observed a reduction of ~30% on my POWER8, but on my POWER9 (Witherspoon) it was ~80%, so it can be even better on a Boston (POWER9 too) machine. Thus, thumbs up from my side. I can sponsor that change but I'll wait an ack. from SAP that it's ok for pushing. Maybe Martin wants to perform additional tests after his first review or others might want to review too... I'm wondering if it would be reasonable to run JCK/TCK against it. Would it test Math.fma() since it's a 9+ method and needs a warmed up JVM? Unfortunately I can't run the JCK/TCK against it myself if it applies here. Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Mittwoch, 12. Dezember 2018 15:50 > *To:* ppc-aix-port-dev at openjdk.java.net; hotspot compiler > *Cc:* Gustavo Romero ; Doerr, Martin ; Simonis, Volker > *Subject:* RFR: 8215262: PPC64: FMA Vectorization on PPC64 > > Dear all, > > Would you please review the following change? > This change supports FMA vectorization on PPC64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 > Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ < http://cr.openjdk.java.net/%7Emhorie/8215262/webrev.00/> > > Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java < http://cr.openjdk.java.net/%7Emhorie/8215262/VFma.java> > It showed ~50% reduction in the execution time. > > I also tested with JTREG and there was no difference in the results compared to the original. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From martin.doerr at sap.com Thu Dec 13 09:24:04 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 13 Dec 2018 09:24:04 +0000 Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: References: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> Message-ID: <911546f0b35d4a72b9326af14a554a8a@sap.com> Hi Michihiro and Gustavo, most of our tests (including a subset of JCK) were running over night and I couldn't see any problems related to this change. So I think you can push it if you want to get it in jdk12. Best regards, Martin From: Michihiro Horie Sent: Donnerstag, 13. Dezember 2018 00:05 To: Gustavo Romero Cc: hotspot compiler ; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker Subject: Re: RFR: 8215262: PPC64: FMA Vectorization on PPC64 Hi Gustavo, Thanks a lot. It's great to have ~80% reduction on POWER9 Witherspoon. Best regards, -- Michihiro, IBM Research - Tokyo [Inactive hide details for "Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin]"Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: From: "Gustavo Romero" > To: "Doerr, Martin" >, Michihiro Horie/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net" >, "hotspot compiler" > Cc: "Simonis, Volker" > Date: 2018/12/13 07:39 Subject: Re: 8215262: PPC64: FMA Vectorization on PPC64 ________________________________ Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: > this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. Michi, the change looks good to me too. I've tested it on POWER8 and on POWER9 and observed a reduction of ~30% on my POWER8, but on my POWER9 (Witherspoon) it was ~80%, so it can be even better on a Boston (POWER9 too) machine. Thus, thumbs up from my side. I can sponsor that change but I'll wait an ack. from SAP that it's ok for pushing. Maybe Martin wants to perform additional tests after his first review or others might want to review too... I'm wondering if it would be reasonable to run JCK/TCK against it. Would it test Math.fma() since it's a 9+ method and needs a warmed up JVM? Unfortunately I can't run the JCK/TCK against it myself if it applies here. Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > > *Sent:* Mittwoch, 12. Dezember 2018 15:50 > *To:* ppc-aix-port-dev at openjdk.java.net; hotspot compiler > > *Cc:* Gustavo Romero >; Doerr, Martin >; Simonis, Volker > > *Subject:* RFR: 8215262: PPC64: FMA Vectorization on PPC64 > > Dear all, > > Would you please review the following change? > This change supports FMA vectorization on PPC64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 > Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ > > Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java > It showed ~50% reduction in the execution time. > > I also tested with JTREG and there was no difference in the results compared to the original. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 105 bytes Desc: image001.gif URL: From gromero at linux.vnet.ibm.com Thu Dec 13 12:29:21 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 13 Dec 2018 10:29:21 -0200 Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: <911546f0b35d4a72b9326af14a554a8a@sap.com> References: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> <911546f0b35d4a72b9326af14a554a8a@sap.com> Message-ID: <6a17e06d-964b-429f-8f09-eedde4fdd9c2@linux.vnet.ibm.com> Hi Michi, Martin On 12/13/2018 07:24 AM, Doerr, Martin wrote: > most of our tests (including a subset of JCK) were running over night and I couldn?t see any problems related to this change. > > So I think you can push it if you want to get it in jdk12. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/1c85328b7631 Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Donnerstag, 13. Dezember 2018 00:05 > *To:* Gustavo Romero > *Cc:* hotspot compiler ; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker > *Subject:* Re: RFR: 8215262: PPC64: FMA Vectorization on PPC64 > > Hi Gustavo, > > Thanks a lot. It's great to have ~80% reduction on POWER9 Witherspoon. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for "Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin "Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: > > From: "Gustavo Romero" > > To: "Doerr, Martin" >, Michihiro Horie/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net " >, "hotspot compiler" > > Cc: "Simonis, Volker" > > Date: 2018/12/13 07:39 > Subject: Re: 8215262: PPC64: FMA Vectorization on PPC64 > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > Hi Michi and Martin, > > On 12/12/2018 01:53 PM, Doerr, Martin wrote: >> this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. > > Michi, the change looks good to me too. > I've tested it on POWER8 and on POWER9 and observed a reduction of ~30% on my > POWER8, but on my POWER9 (Witherspoon) it was ~80%, so it can be even better on > a Boston (POWER9 too) machine. Thus, thumbs up from my side. > > I can sponsor that change but I'll wait an ack. from SAP that it's ok for > pushing. Maybe Martin wants to perform additional tests after his first review > or others might want to review too... ?I'm wondering if it would be reasonable > to run JCK/TCK against it. Would it test Math.fma() since it's a 9+ method and > needs a warmed up JVM? Unfortunately I can't run the JCK/TCK against it myself > if it applies here. > > Thank you. > > Best regards, > Gustavo > >> Best regards, >> >> Martin >> >> *From:*Michihiro Horie > >> *Sent:* Mittwoch, 12. Dezember 2018 15:50 >> *To:* ppc-aix-port-dev at openjdk.java.net ; hotspot compiler > >> *Cc:* Gustavo Romero >; Doerr, Martin >; Simonis, Volker > >> *Subject:* RFR: 8215262: PPC64: FMA Vectorization on PPC64 >> >> Dear all, >> >> Would you please review the following change? >> This change supports FMA vectorization on PPC64. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 >> Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ ? >> >> Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java ? >> It showed ~50% reduction in the execution time. >> >> I also tested with JTREG and there was no difference in the results compared to the original. >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> > > From HORIE at jp.ibm.com Thu Dec 13 13:10:02 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 13 Dec 2018 22:10:02 +0900 Subject: RFR: 8215262: PPC64: FMA Vectorization on PPC64 In-Reply-To: <6a17e06d-964b-429f-8f09-eedde4fdd9c2@linux.vnet.ibm.com> References: <9f565ce7-b30e-baf1-5a45-fb93f36376f0@linux.vnet.ibm.com> <911546f0b35d4a72b9326af14a554a8a@sap.com> <6a17e06d-964b-429f-8f09-eedde4fdd9c2@linux.vnet.ibm.com> Message-ID: Hi Martin, Gustavo, > most of our tests (including a subset of JCK) were running over night and I couldn?t see any problems related to this change. Thank you so much for long-running tests. >Pushed: >http://hg.openjdk.java.net/jdk/jdk/rev/1c85328b7631 Thank you, Gustavo! Best regards, -- Michihiro, IBM Research - Tokyo From: "Gustavo Romero" To: "Doerr, Martin" , Michihiro Horie/Japan/IBM at IBMJP Cc: "hotspot compiler" , "ppc-aix-port-dev at openjdk.java.net" , "Simonis, Volker" Date: 2018/12/13 21:29 Subject: Re: RFR: 8215262: PPC64: FMA Vectorization on PPC64 Hi Michi, Martin On 12/13/2018 07:24 AM, Doerr, Martin wrote: > most of our tests (including a subset of JCK) were running over night and I couldn?t see any problems related to this change. > > So I think you can push it if you want to get it in jdk12. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/1c85328b7631 Thank you. Best regards, Gustavo > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Donnerstag, 13. Dezember 2018 00:05 > *To:* Gustavo Romero > *Cc:* hotspot compiler ; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker > *Subject:* Re: RFR: 8215262: PPC64: FMA Vectorization on PPC64 > > Hi Gustavo, > > Thanks a lot. It's great to have ~80% reduction on POWER9 Witherspoon. > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for "Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin "Gustavo Romero" ---2018/12/13 07:39:15---Hi Michi and Martin, On 12/12/2018 01:53 PM, Doerr, Martin wrote: > > From: "Gustavo Romero" > > To: "Doerr, Martin" >, Michihiro Horie/Japan/IBM at IBMJP, "ppc-aix-port-dev at openjdk.java.net < mailto:ppc-aix-port-dev at openjdk.java.net>" >, "hotspot compiler" > > Cc: "Simonis, Volker" > > Date: 2018/12/13 07:39 > Subject: Re: 8215262: PPC64: FMA Vectorization on PPC64 > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > > Hi Michi and Martin, > > On 12/12/2018 01:53 PM, Doerr, Martin wrote: >> this looks good to me. We should be able to test it since it is for Power8. Maybe Gustavo would like to test in addition. > > Michi, the change looks good to me too. > I've tested it on POWER8 and on POWER9 and observed a reduction of ~30% on my > POWER8, but on my POWER9 (Witherspoon) it was ~80%, so it can be even better on > a Boston (POWER9 too) machine. Thus, thumbs up from my side. > > I can sponsor that change but I'll wait an ack. from SAP that it's ok for > pushing. Maybe Martin wants to perform additional tests after his first review > or others might want to review too... ?I'm wondering if it would be reasonable > to run JCK/TCK against it. Would it test Math.fma() since it's a 9+ method and > needs a warmed up JVM? Unfortunately I can't run the JCK/TCK against it myself > if it applies here. > > Thank you. > > Best regards, > Gustavo > >> Best regards, >> >> Martin >> >> *From:*Michihiro Horie > >> *Sent:* Mittwoch, 12. Dezember 2018 15:50 >> *To:* ppc-aix-port-dev at openjdk.java.net < mailto:ppc-aix-port-dev at openjdk.java.net>; hotspot compiler > >> *Cc:* Gustavo Romero >; Doerr, Martin >; Simonis, Volker > >> *Subject:* RFR: 8215262: PPC64: FMA Vectorization on PPC64 >> >> Dear all, >> >> Would you please review the following change? >> This change supports FMA vectorization on PPC64. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215262 >> Webrev: http://cr.openjdk.java.net/~mhorie/8215262/webrev.00/ < http://cr.openjdk.java.net/%7Emhorie/8215262/webrev.00/>?< http://cr.openjdk.java.net/%7Emhorie/8215262/webrev.00/> >> >> Microbenchmark I used is http://cr.openjdk.java.net/~mhorie/8215262/VFma.java < http://cr.openjdk.java.net/%7Emhorie/8215262/VFma.java>?< http://cr.openjdk.java.net/%7Emhorie/8215262/VFma.java> >> It showed ~50% reduction in the execution time. >> >> I also tested with JTREG and there was no difference in the results compared to the original. >> >> >> Best regards, >> -- >> Michihiro, >> IBM Research - Tokyo >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From takiguc at linux.vnet.ibm.com Fri Dec 14 09:58:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 14 Dec 2018 18:58:25 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> Message-ID: <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> Hello Alan. I opened JDK-8215333 for Charset filtering issue [1]. I cannot wait until JDK-8215333 is closed. Is it possible to put IBM-29626C charset with standard way ? [1] https://bugs.openjdk.java.net/browse/JDK-8215333 Thanks, Ichiroh Takiguchi On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > Hello Roger, Magnus and Alan. > I may need to put alias information into charsets file. > stdcs-xxx cannot handle this information... > > Still AIX needs IBM-29626C charset for default encoding... > > I appreciate if you give me further suggestions. > > Thanks, > Ichiroh Takiguchi > > On 2018-12-10 20:50, Alan Bateman wrote: >> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>> On 2018-12-07 21:20, Roger Riggs wrote: >>>> Hi, >>>> >>>> It is a nice feature that charsets are selected at build time using >>>> the stdcs-xxx files. >>>> This change breaks that pattern and embeds os specific information >>>> in more than one place. >>>> That does not seem like an improvement.? Is there any alternative? >>> I agree. Why is it not enough just to add it to stdcs-aix? >> My reading of the patch is that the "os" key is to avoid generating it >> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> non-AIX platforms. The general direction is welcome but I think >> further work and discussion will be needed to get the right set of >> changes to support filtering in the build. It can probably be >> separated from the changes to add IBM-29626C to AIX's java.base. >> >> -Alan From OGATAK at jp.ibm.com Tue Dec 18 14:41:17 2018 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Tue, 18 Dec 2018 23:41:17 +0900 Subject: [8u] RFR for backport of 8154156: PPC64: improve array copy stubs by using vector instructions Message-ID: Hi, May I get review for enhancement backport of 8154156: PPC64: improve array copy stubs by using vector instructions? To make this patch buildable (and usable by other planned backports listed in [1]), I cherry picked config_dscr() and its dependent code from [2,3] and has_mfdscr() from [4]. Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/c9d756fa846e Weberv: http://cr.openjdk.java.net/~horii/jdk8u_aes_be/8154156/webrev.01/ I confirmed it was buildable for both relase and fastdebug builds, and JTREG caused no degradation. Refs: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-December/003818.html [2] 8149655: PPC64: Implement CompactString intrinsics http://hg.openjdk.java.net/jdk/jdk/rev/6241574f5982 [3] 8080684: PPC64: Fix little-endian build after "8077838: Recent developments for ppc" http://hg.openjdk.java.net/jdk/jdk/rev/12ccf8b26eb0 [4] 8077838: Recent developments for ppc. http://hg.openjdk.java.net/jdk/jdk/rev/c703c89fddbf Regards, Ogata