From HORIE at jp.ibm.com  Mon Sep  9 14:14:33 2019
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Mon, 9 Sep 2019 23:14:33 +0900
Subject: Memory fences in the JNI invocation on Power
Message-ID: <OF893CBE70.E7153AD4-ON00258470.004D0C7A-49258470.004E3CA0@notes.na.collabserv.com>



Hi all,

This is not a RFR. I have a client case in which a Java application invokes
JNI methods heavily on Power.

Fixing Java code is not allowed, so I?m wondering if there is any way to
enlighten the JNI invocation by replacing memory fences such as the
following diff on Power. I may miss the design around the diff, but I?m not
sure if WR order needs to be protected.
http://cr.openjdk.java.net/~mhorie/webrev_jni/
(I should fix code under the given abstractions, but wanted to share a fix
on Power in the first place.)

Best regards,
Michihiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190909/c3d23ee9/attachment.html>

From martin.doerr at sap.com  Mon Sep  9 15:33:08 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 9 Sep 2019 15:33:08 +0000
Subject: Memory fences in the JNI invocation on Power
In-Reply-To: <OF893CBE70.E7153AD4-ON00258470.004D0C7A-49258470.004E3CA0@notes.na.collabserv.com>
References: <OF893CBE70.E7153AD4-ON00258470.004D0C7A-49258470.004E3CA0@notes.na.collabserv.com>
Message-ID: <VI1PR0201MB24792E52853A0F82FEB3C74A9AB70@VI1PR0201MB2479.eurprd02.prod.outlook.com>

Hi Michihiro,

the change is incorrect.
You need a StoreLoad barrier between the thread state change and the succeeding safepoint check.
The transition state must be visible when reaching the safepoint.

Note that I've recently contributed FastJNIAccessors for PPC64:
https://bugs.openjdk.java.net/browse/JDK-8228743
But this only speeds up reading primitive fields in native code.

If there are methods which execute quickly and only need to pass primitive types and arrays of primitive types, you may want to take a look at CriticalJNINatives.
There are jtreg tests which implement JavaCritical_ native methods, e.g.:
test/hotspot/jtreg/gc/libCriticalNative.c
It's also used by src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c

Best regards,
Martin


From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On Behalf Of Michihiro Horie
Sent: Montag, 9. September 2019 16:15
To: ppc-aix-port-dev at openjdk.java.net
Subject: Memory fences in the JNI invocation on Power


Hi all,

This is not a RFR. I have a client case in which a Java application invokes JNI methods heavily on Power.

Fixing Java code is not allowed, so I'm wondering if there is any way to enlighten the JNI invocation by replacing memory fences such as the following diff on Power. I may miss the design around the diff, but I'm not sure if WR order needs to be protected.
http://cr.openjdk.java.net/~mhorie/webrev_jni/
(I should fix code under the given abstractions, but wanted to share a fix on Power in the first place.)

Best regards,
Michihiro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190909/4dd671e2/attachment.html>

From HORIE at jp.ibm.com  Tue Sep 10 05:41:14 2019
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Tue, 10 Sep 2019 14:41:14 +0900
Subject: Memory fences in the JNI invocation on Power
In-Reply-To: <VI1PR0201MB24792E52853A0F82FEB3C74A9AB70@VI1PR0201MB2479.eurprd02.prod.outlook.com>
References: <OF893CBE70.E7153AD4-ON00258470.004D0C7A-49258470.004E3CA0@notes.na.collabserv.com>
 <VI1PR0201MB24792E52853A0F82FEB3C74A9AB70@VI1PR0201MB2479.eurprd02.prod.outlook.com>
Message-ID: <OF98A2A292.C388FF3E-ON00258471.001E9519-49258471.001F3DB3@notes.na.collabserv.com>

Hi Martin,

Thanks a lot for your quick response. I see, we cannot apply this fix.
I will look for an opportunity in which FastJNIAccessor is applicable.

Best regards,
Michihiro



From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Date:	2019/09/10 00:34
Subject:	[EXTERNAL] RE: Memory fences in the JNI invocation on Power



Hi Michihiro,

the change is incorrect.
You need a StoreLoad barrier between the thread state change and the
succeeding safepoint check.
The transition state must be visible when reaching the safepoint.

Note that I?ve recently contributed FastJNIAccessors for PPC64:
https://bugs.openjdk.java.net/browse/JDK-8228743
But this only speeds up reading primitive fields in native code.

If there are methods which execute quickly and only need to pass primitive
types and arrays of primitive types, you may want to take a look at
CriticalJNINatives.
There are jtreg tests which implement JavaCritical_ native methods, e.g.:
test/hotspot/jtreg/gc/libCriticalNative.c
It?s also used by
src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c

Best regards,
Martin


From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On
Behalf Of Michihiro Horie
Sent: Montag, 9. September 2019 16:15
To: ppc-aix-port-dev at openjdk.java.net
Subject: Memory fences in the JNI invocation on Power



Hi all,

This is not a RFR. I have a client case in which a Java application invokes
JNI methods heavily on Power.

Fixing Java code is not allowed, so I?m wondering if there is any way to
enlighten the JNI invocation by replacing memory fences such as the
following diff on Power. I may miss the design around the diff, but I?m not
sure if WR order needs to be protected.
http://cr.openjdk.java.net/~mhorie/webrev_jni/
(I should fix code under the given abstractions, but wanted to share a fix
on Power in the first place.)

Best regards,
Michihiro





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190910/b80dacde/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20190910/b80dacde/graycol-0001.gif>

From christoph.langer at sap.com  Tue Sep 17 08:50:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 17 Sep 2019 08:50:22 +0000
Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer
 types and string literal conversion warnings
In-Reply-To: <AM6PR02MB5078A4042DB34CCFB1B88A7293C10@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078A1B995359982495CFB1C93C70@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <AM6PR02MB47888FB2BE46EEF137AED2229AC60@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB5078A4042DB34CCFB1B88A7293C10@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB519285A7980C7577675842738A8F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Matthias,

this seems fine to me. The change in NetworkInterface.c is correct, too.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 25. Juli 2019 15:45
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net; net-dev at openjdk.java.net
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net>
> Subject: [CAUTION] RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct
> pointer types and string literal conversion warnings
> 
> Thanks Martin .
> May I get a second review ?
> 
> Best regards, Matthias
> 
> 
> From: Doerr, Martin
> Sent: Mittwoch, 24. Juli 2019 12:14
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net; net-dev at openjdk.java.net
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net>
> Subject: RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer
> types and string literal conversion warnings
> 
> Hi Matthias,
> 
> I wouldn?t say ?looks good?, but I think it?s the right thing to do ??
> The type casts look correct to fit to the AIX headers.
> 
> libodm_aix:
> Good. Maybe we should open a new issue for freeing what?s returned by
> odm_set_path and we could also remove the AIX 5 support.
> 
> NetworkInterface.c:
> Strange, but ok. Should be reviewed by somebody else in addition.
> 
> Other files:
> No comments.
> 
> Best regards,
> Martin
> 
> 
> From: ppc-aix-port-dev <ppc-aix-port-dev-
> bounces at openjdk.java.net<mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net>> On Behalf Of Baesken, Matthias
> Sent: Dienstag, 23. Juli 2019 17:15
> To: 'hotspot-dev at openjdk.java.net' <hotspot-
> dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>>; core-libs-
> dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; net-
> dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>>
> Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types
> and string literal conversion warnings
> 
> Hello please review this patch .
> 
> It fixes a couple of  xlc16/xlclang warnings  , especially  comparison of distinct
> pointer types and string literal conversion warnings  .
> 
> When building with xlc16/xlclang, we still have a couple of warnings that have
> to be fixed :
> warning: ISO C++11 does not allow conversion from string literal to 'char *' [-
> Wwritable-strings]
> for example :
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:18: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
>                  ^
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:29: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
>                             ^
> 
> warning: comparison of distinct pointer types, for example :
> 
> /nightly/jdk/src/java.desktop/aix/native/libawt/porting_aix.c:50:14:
> warning: comparison of distinct pointer types ('void *' and 'char *') [-
> Wcompare-distinct-pointer-types]
>         addr < (((char*)p->ldinfo_textorg) + p->ldinfo_textsize)) {
>         ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> Bug/webrev :
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8228482
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8228482.1/
> 
> 
> Thanks, Matthias
> 


From takiguc at linux.vnet.ibm.com  Mon Sep 23 17:16:38 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 24 Sep 2019 02:16:38 +0900
Subject: RFR: 8230873  [AIX] GUI app does work with UTF-8 locale on minimum
 software requirements
Message-ID: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8230873
Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/

GUI application does not work with AIX's JA_JP UTF-8 locale on minimum
software requirements and settings because of following exception:
   Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
   class sun.font.CompositeFont cannot be cast to class 
sun.font.PhysicalFont
   (sun.font.CompositeFont and sun.font.PhysicalFont are in module
   java.desktop of loader 'bootstrap')

About the reasons for this exception:
1. Default physical font is not defined (like Lucida sans)
2. XLFD charset name entries for JA_JP locale have Underscore character
    (Underscore character replaces with Space character on 
fontconfig.proeprties
    (fontconfig.bfs) file loading phase.)

About "1", I'd like to handle it by JDK-8221741 [1].
About "2", OpenJDK for AIX is using fontconfig.properties 
(fontconfig.bfc) file
to find out TrueType fonts.
On AIX JCK UTF-8 locales, Java cannot find out TrueType font because
above XLFD charset name issue.

This fix only changes fontconfig.properties for AIX platform
* make/data/fontconfig/aix.fontconfig.properties

[1] https://bugs.openjdk.java.net/browse/JDK-8230873

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Tue Sep 24 07:54:20 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 24 Sep 2019 16:54:20 +0900
Subject: RFR: 8230873  [AIX] GUI app does not work with UTF-8 locale on
 minimum software requirements
In-Reply-To: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com>
References: <3a7822cae9f83a25b6d35561110f0b98@linux.vnet.ibm.com>
Message-ID: <f02ca13a06dde70b4024a123265360c1@linux.vnet.ibm.com>

Hello.

I'm sorry, I made a typo in the Subject.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8230873
Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2019-09-24 02:16, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8230873
> Change: https://cr.openjdk.java.net/~itakiguchi/8230873/webrev.00/
> 
> GUI application does not work with AIX's JA_JP UTF-8 locale on minimum
> software requirements and settings because of following exception:
>   Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:
>   class sun.font.CompositeFont cannot be cast to class 
> sun.font.PhysicalFont
>   (sun.font.CompositeFont and sun.font.PhysicalFont are in module
>   java.desktop of loader 'bootstrap')
> 
> About the reasons for this exception:
> 1. Default physical font is not defined (like Lucida sans)
> 2. XLFD charset name entries for JA_JP locale have Underscore character
>    (Underscore character replaces with Space character on 
> fontconfig.proeprties
>    (fontconfig.bfs) file loading phase.)
> 
> About "1", I'd like to handle it by JDK-8221741 [1].
> About "2", OpenJDK for AIX is using fontconfig.properties 
> (fontconfig.bfc) file
> to find out TrueType fonts.
> On AIX JCK UTF-8 locales, Java cannot find out TrueType font because
> above XLFD charset name issue.
> 
> This fix only changes fontconfig.properties for AIX platform
> * make/data/fontconfig/aix.fontconfig.properties
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8230873
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.