from:"Doerr, Martin"

AW: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

2021-06-15 Thread Doerr, Martin

Hi Brian,

thanks a lot!

It may be difficult to reproduce. Maybe a slow file system helps (like NFS).
Just let us know if you have questions.

Best regards,
Martin


Von: Brian Stafford 
Datum: Dienstag, 15. Juni 2021 um 01:20
An: jdk-updates-...@openjdk.java.net , 
core-libs-dev@openjdk.java.net , Doerr, Martin 

Cc: Reka Kovacs , Aditya Mandaleeka 
, Monica Beckwith 
Betreff: RE: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes 
on Windows x64
Hi Martin,

We haven’t encountered this yet, to my knowledge, but we’ll see if we can 
reproduce it during our next sprint.

Thanks,
Brian Stafford



From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Monday, June 14, 2021 3:17 AM
To: jdk-updates-...@openjdk.java.net<mailto:jdk-updates-...@openjdk.java.net>; 
core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; Reka 
Kovacs mailto:rekakov...@microsoft.com>>; Aditya 
Mandaleeka mailto:adit...@microsoft.com>>; Monica 
Beckwith mailto:monica.beckw...@microsoft.com>>
Subject: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on 
Windows x64

Hi,

we observe crashes in jdk 11.0.12 on Windows:
https://bugs.openjdk.java.net/browse/JDK-8267440<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8267440=04%7C01%7CBrian.Stafford%40microsoft.com%7Cc92386856da54294151b08d92f715f84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637592986257024831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=LSmKaskfTKf5JUqWSt0dVxhW9BuRY86bdn1VW3j7wqI%3D=0>

I haven’t found any backport which looks like obviously causing it.

We had different theories which include:

  *   Antivirus tool which keeps the test file open.
  *   Error in handling of OVERLAPPED structures.

I was hoping that 
JDK-8184157<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8184157=04%7C01%7CBrian.Stafford%40microsoft.com%7Cc92386856da54294151b08d92f715f84%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637592986257034811%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=%2F3ZDJqKinnl6jkv%2BoGeoEY9MyumsxqkG1h7yJAYbUo4%3D=0>
 would fix it, but it doesn’t. Maybe it is incomplete?

Did anybody else notice such crashes?
Any idea?

Best regards,
Martin

[11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

2021-06-14 Thread Doerr, Martin

Hi,

we observe crashes in jdk 11.0.12 on Windows:
https://bugs.openjdk.java.net/browse/JDK-8267440

I haven’t found any backport which looks like obviously causing it.

We had different theories which include:

  *   Antivirus tool which keeps the test file open.
  *   Error in handling of OVERLAPPED structures.

I was hoping that JDK-8184157 
would fix it, but it doesn’t. Maybe it is incomplete?

Did anybody else notice such crashes?
Any idea?

Best regards,
Martin

RE: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

2021-01-25 Thread Doerr, Martin

Hi Götz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz 
Sent: Montag, 25. Januar 2021 10:49
To: Doerr, Martin ; core-libs-dev 
; jdk-updates-...@openjdk.java.net
Cc: Langer, Christoph 
Subject: RE: [11u] RFR: 7146776: deadlock between 
URLStreamHandler.getHostAddress and file.Handler.openconnection

Hi,

Thanks for downporting this, looks good.

Best regards,
  Goetz.

From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Tuesday, January 19, 2021 6:44 PM
To: core-libs-dev 
mailto:core-libs-dev@openjdk.java.net>>; 
jdk-updates-...@openjdk.java.net<mailto:jdk-updates-...@openjdk.java.net>
Cc: Lindenmaier, Goetz 
mailto:goetz.lindenma...@sap.com>>; Langer, 
Christoph mailto:christoph.lan...@sap.com>>
Subject: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress 
and file.Handler.openconnection

Hi,

JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of Copyright year changes and a minor 
difference in a hunk which gets removed by this change:
11u Code contains host.equals(""), patch wants to remove host.isEmpty() from 
URLStreamHandler.java.

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

Original change:
https://git.openjdk.java.net/jdk/commit/db9c114d

11u backport:
http://cr.openjdk.java.net/~mdoerr/7146776_windows_deadlock_11u/webrev.00/

Please review.

Best regards,
Martin

[11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

2021-01-19 Thread Doerr, Martin

Hi,

JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly because of Copyright year changes and a minor 
difference in a hunk which gets removed by this change:
11u Code contains host.equals(""), patch wants to remove host.isEmpty() from 
URLStreamHandler.java.

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

Original change:
https://git.openjdk.java.net/jdk/commit/db9c114d

11u backport:
http://cr.openjdk.java.net/~mdoerr/7146776_windows_deadlock_11u/webrev.00/

Please review.

Best regards,
Martin

RE: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module

2020-12-22 Thread Doerr, Martin

Hi Götz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz 
Sent: Dienstag, 22. Dezember 2020 13:02
To: Doerr, Martin ; core-libs-dev 
; jdk-updates-...@openjdk.java.net
Cc: Langer, Christoph 
Subject: RE: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if 
module-info.class found as resource in unnamed module

Hi Martin,

The change looks good.

The additional argument is only used for an optional printout of platform 
information,
so not relevant for this fix - besides that it is null anyways.

Best regards,
  Goetz.

From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Monday, December 21, 2020 9:54 PM
To: core-libs-dev 
mailto:core-libs-dev@openjdk.java.net>>; 
jdk-updates-...@openjdk.java.net<mailto:jdk-updates-...@openjdk.java.net>
Cc: Langer, Christoph 
mailto:christoph.lan...@sap.com>>; Lindenmaier, Goetz 
mailto:goetz.lindenma...@sap.com>>
Subject: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if 
module-info.class found as resource in unnamed module

Hi,

JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change applies cleanly, but 11u needs minor adaptation:
- Keep "import java.util.Iterator;" in Module.java.
- "toModuleInfo" has one argument less in 11u, so pass one "null" less.

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

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30

11u backport:
http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/

Manual change in detail:
diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java
--- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 
2020 +0100
+++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 
2020 +0100
@@ -42,6 +42,7 @@
import java.security.PrivilegedAction;
import java.util.HashMap;
import java.util.HashSet;
+import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Objects;
diff -r d85e41e89ed5 
src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
--- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
Thu Jun 11 07:27:22 2020 +0100
+++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
Mon Dec 21 21:23:47 2020 +0100
@@ -184,7 +184,7 @@
  * module-info.class format.
  */
 public static byte[] toBytes(ModuleDescriptor descriptor) {
-return toModuleInfo(descriptor, null, null);
+return toModuleInfo(descriptor, null);
 }

 /**

Please review.

Best regards,
Martin

[11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module

2020-12-21 Thread Doerr, Martin

Hi,

JDK-8248901 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change applies cleanly, but 11u needs minor adaptation:
- Keep "import java.util.Iterator;" in Module.java.
- "toModuleInfo" has one argument less in 11u, so pass one "null" less.

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

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/493e7c5a7c30

11u backport:
http://cr.openjdk.java.net/~mdoerr/8241770_module_11u/webrev.00/

Manual change in detail:
diff -r d85e41e89ed5 src/java.base/share/classes/java/lang/Module.java
--- a/src/java.base/share/classes/java/lang/Module.java Thu Jun 11 07:27:22 
2020 +0100
+++ b/src/java.base/share/classes/java/lang/Module.java Mon Dec 21 21:23:47 
2020 +0100
@@ -42,6 +42,7 @@
import java.security.PrivilegedAction;
import java.util.HashMap;
import java.util.HashSet;
+import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Objects;
diff -r d85e41e89ed5 
src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java
--- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
Thu Jun 11 07:27:22 2020 +0100
+++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java 
Mon Dec 21 21:23:47 2020 +0100
@@ -184,7 +184,7 @@
  * module-info.class format.
  */
 public static byte[] toBytes(ModuleDescriptor descriptor) {
-return toModuleInfo(descriptor, null, null);
+return toModuleInfo(descriptor, null);
 }

 /**

Please review.

Best regards,
Martin

RE: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag

2020-12-21 Thread Doerr, Martin

Hi Götz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz 
Sent: Montag, 21. Dezember 2020 14:44
To: Doerr, Martin ; core-libs-dev 
; jdk-updates-...@openjdk.java.net
Cc: Langer, Christoph 
Subject: RE: [11u] RFR: 8235351: Lookup::unreflect should bind with the 
original caller independent of Method's accessible flag

Hi Martin,

The change looks good.
The private methods have been called at those places before, so this is
straight forward.

Best regards,
  Goetz.

From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Monday, December 21, 2020 11:52 AM
To: core-libs-dev 
mailto:core-libs-dev@openjdk.java.net>>; 
jdk-updates-...@openjdk.java.net<mailto:jdk-updates-...@openjdk.java.net>
Cc: Langer, Christoph 
mailto:christoph.lan...@sap.com>>; Lindenmaier, Goetz 
mailto:goetz.lindenma...@sap.com>>
Subject: [11u] RFR: 8235351: Lookup::unreflect should bind with the original 
caller independent of Method's accessible flag

Hi,

JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly, because 
https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses 
hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()).

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

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce

11u backport:
http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/

This is the adaptation:
diff -r a670e0826a66 
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java   Fri Dec 
06 15:10:40 2019 -0800
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java   Fri Dec 
18 18:01:25 2020 +0100
@@ -2074,8 +2074,8 @@
  * Otherwise, if m is caller-sensitive, throw IllegalAccessException.
  */
  Lookup findBoundCallerLookup(MemberName m) throws 
IllegalAccessException {
- if (MethodHandleNatives.isCallerSensitive(m) && 
!hasFullPrivilegeAccess()) {
-// Only lookups with full privilege access are allowed to 
resolve caller-sensitive methods
+ if (MethodHandleNatives.isCallerSensitive(m) && 
!hasPrivateAccess()) {
+// Only lookups with private access are allowed to resolve 
caller-sensitive methods
 throw new IllegalAccessException("Attempt to lookup 
caller-sensitive method using restricted lookup object");
 }
 return this;
@@ -2335,9 +2335,9 @@
 if (boundCaller.allowedModes == TRUSTED || 
!MethodHandleNatives.isCallerSensitive(method))
 return mh;

-// boundCaller must have full privilege access.
+// boundCaller must have private access.
 // It should have been checked by findBoundCallerLookup. Safe to 
check this again.
-if (!boundCaller.hasFullPrivilegeAccess())
+if (!boundCaller.hasPrivateAccess())
 throw new IllegalAccessException("Attempt to lookup 
caller-sensitive method using restricted lookup object");

 MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, 
boundCaller.lookupClass);

Please review.

Best regards,
Martin

[11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag

2020-12-21 Thread Doerr, Martin

Hi,

JDK-8235351 is backported to 11.0.11-oracle. I'd like to backport it for parity.
Change doesn't apply cleanly, because 
https://bugs.openjdk.java.net/browse/JDK-8233527 is not in 11u (jdk14 uses 
hasFullPrivilegeAccess(), but older versions use hasPrivateAccess()).

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

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/4437d58547ce

11u backport:
http://cr.openjdk.java.net/~mdoerr/8235351_methodhandles_11u/webrev.00/

This is the adaptation:
diff -r a670e0826a66 
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java   Fri Dec 
06 15:10:40 2019 -0800
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java   Fri Dec 
18 18:01:25 2020 +0100
@@ -2074,8 +2074,8 @@
  * Otherwise, if m is caller-sensitive, throw IllegalAccessException.
  */
  Lookup findBoundCallerLookup(MemberName m) throws 
IllegalAccessException {
- if (MethodHandleNatives.isCallerSensitive(m) && 
!hasFullPrivilegeAccess()) {
-// Only lookups with full privilege access are allowed to 
resolve caller-sensitive methods
+ if (MethodHandleNatives.isCallerSensitive(m) && 
!hasPrivateAccess()) {
+// Only lookups with private access are allowed to resolve 
caller-sensitive methods
 throw new IllegalAccessException("Attempt to lookup 
caller-sensitive method using restricted lookup object");
 }
 return this;
@@ -2335,9 +2335,9 @@
 if (boundCaller.allowedModes == TRUSTED || 
!MethodHandleNatives.isCallerSensitive(method))
 return mh;

-// boundCaller must have full privilege access.
+// boundCaller must have private access.
 // It should have been checked by findBoundCallerLookup. Safe to 
check this again.
-if (!boundCaller.hasFullPrivilegeAccess())
+if (!boundCaller.hasPrivateAccess())
 throw new IllegalAccessException("Attempt to lookup 
caller-sensitive method using restricted lookup object");

 MethodHandle cbmh = MethodHandleImpl.bindCaller(mh, 
boundCaller.lookupClass);

Please review.

Best regards,
Martin

RE: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

2020-12-17 Thread Doerr, Martin

Hi Christoph,

thanks for the review!

Best regards,
Martin


> -Original Message-
> From: Langer, Christoph 
> Sent: Donnerstag, 17. Dezember 2020 14:45
> To: Doerr, Martin ; core-libs-dev  d...@openjdk.java.net>; jdk-updates-...@openjdk.java.net
> Subject: RE: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does
> not setup delegation when module reads automatic module
> 
> Hi Martin,
> 
> this makes sense. Thanks for doing the backport.
> 
> Best regards
> Christoph
> 
> > -Original Message-----
> > From: core-libs-dev  On Behalf Of
> > Doerr, Martin
> > Sent: Mittwoch, 16. Dezember 2020 14:39
> > To: core-libs-dev ; jdk-updates-
> > d...@openjdk.java.net
> > Subject: [CAUTION] [11u] RFR: 8211825:
> > ModuleLayer.defineModulesWithXXX does not setup delegation when
> > module reads automatic module
> >
> > Hi,
> >
> > JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for 
> > parity.
> > The original change applies cleanly, by javac from 11u has a problem with
> the
> > new AutomaticModulesTest:
> > AutomaticModulesTest.java:70: error: reference to createJarFile is
> > ambiguous
> > JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES);
> > ^
> >   both method createJarFile(Path,Path,Path...) in JarUtils and method
> > createJarFile(Path,Path,String...) in JarUtils match
> >
> > I suggest to resolve it this way:
> >
> http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.p
> > atch
> >
> >
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8211825
> >
> > Original change:
> > http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01
> >
> > 11u webrev:
> >
> http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.0
> > 0/
> >
> > Please review.
> >
> > Best regards,
> > Martin

[11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

2020-12-16 Thread Doerr, Martin

Hi,

JDK-8211825 is backported to 11.0.11-oracle. I'd like to backport it for parity.
The original change applies cleanly, by javac from 11u has a problem with the 
new AutomaticModulesTest:
AutomaticModulesTest.java:70: error: reference to createJarFile is ambiguous
JarUtils.createJarFile(LIB.resolve("alib.jar"), CLASSES);
^
  both method createJarFile(Path,Path,Path...) in JarUtils and method 
createJarFile(Path,Path,String...) in JarUtils match

I suggest to resolve it this way:
http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/test_fix.patch


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

Original change:
http://hg.openjdk.java.net/jdk/jdk/rev/a42c378b6f01

11u webrev:
http://cr.openjdk.java.net/~mdoerr/8211825_module_layer_11u/webrev.00/

Please review.

Best regards,
Martin

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-09-07 Thread Doerr, Martin

Hi Corey,

thanks for investigating.

Note that we use xlclang++ on AIX. It may possibly understand the directives as 
gcc on linux.
Gcc 7.3.1 is the minimum for BE linux.
But if you protect your code by #ifdef VM_LITTLE_ENDIAN no compiler except gcc 
>= 7.4.0 should ever look at it.

Best regards,
Martin


> -Original Message-
> From: Corey Ashford 
> Sent: Dienstag, 1. September 2020 02:17
> To: Doerr, Martin 
> Cc: Michihiro Horie ; hotspot-compiler-
> d...@openjdk.java.net; core-libs-dev ;
> Kazunori Ogata ; jos...@br.ibm.com
> Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
> API for Base64 decoding
> 
> On 8/27/20 8:07 AM, Doerr, Martin wrote:
> >>> I will use __attribute__ ((align(16))) instead of __vector, and make
> >> them arrays of 16 unsigned char.
> > Maybe __vectors works as expected, too, now. Whatever we use, I'd
> appreciate to double-check the alignment e.g. by using gdb.
> > I don't remember what we had tried and why it didn't work as desired.
> 
> 
> I just now tried on gcc-7.5.0, declaring a __vector at 1, 2, 3, 8, 9,
> and 15 byte offsets in a struct, trying to force a misalignment, but the
> compiler realigned all of them on 16-byte boundaries.
> 
> If someone decides to make the intrinsic work on AIX (big endian), and
> compiles with 7.3.1, I don't know what will happen w.r.t. alignment, so
> to be on the safe side, I will make the declarations 16-byte unsigned
> char arrays with an align attribute.
> 
> Looking a bit deeper, I see that the __vector type comes out of the C
> preprocessor as: __attribute__((altivec(vector__))). It's part of the
> compiler's basic set of predefined macros, and can be seen using this
> command:
> 
> %  gcc -dM -E - < /dev/null | grep __vector
> 
> #define __vector __attribute__((altivec(vector__)))
> 
> Some information here:
> https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Type-Attributes.html
> 
> I don't know if this is helpful or not, but it might answer part of your
> question about the meaning of __vector.
> 
> Regards,
> 
> - Corey

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-08-27 Thread Doerr, Martin

Hi Corey,

> If I make a requirement, I feel decode0 should check that the
> requirement is met, and raise some kind of internal error if it isn't.
> That actually was my first implementation, but I received some comments
> during an internal review suggesting that I just "round down" the
> destination count to the closest multiple of 3 less than or equal to the
> returned value, rather than throw an internal exception which would
> confuse users.  This "enforces" the rule, in some sense, without error
> handling.  Do you have some thoughts about this?

I think the rounding logic is hard to understand and I'm not sure if it's 
correct (you're rounding up for the 1st computation of chars_decoded).
If we don't use it, it will never get tested (because the intrinsic always 
returns a multiple of 3).
I prefer having a more simple version which is easy to understand and for which 
we can test all cases.

I think we should be able to catch violations of this requirement by adding 
good JTREG tests.
An illegal intrinsic implementation should never pass the tests. So I don't see 
a need to catch an illegal state in the Java source code in this case.
I guess this will be best for intrinsic implementors for other platforms as 
well.

I'd appreciate more opinions on this.


> I will double check that everything compiles and runs properly with gcc
> 7.3.1.
Please note that 7.3.1 is our minimum for Big Endian linux. For Little Endian 
it's 7.4.0.
You can also find this information here:
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
under "Other JDK 13 build platforms" which hasn't changed since then.

> I will use __attribute__ ((align(16))) instead of __vector, and make
> them arrays of 16 unsigned char.
Maybe __vectors works as expected, too, now. Whatever we use, I'd appreciate to 
double-check the alignment e.g. by using gdb.
I don't remember what we had tried and why it didn't work as desired.


> I was following what was done for encodeBlock, but it appears
> encodeBlock's style isn't what is used for the other intrinsics.  I will
> correct decodeBlock to use the prevailing style.  Another patch should
> be added (not part of this webrev) to correct encodeBlock's style.
In your code one '\' is not aligned with the other ones.


> Ah, this is another thing I didn't know about.  I will make some
> regression tests.
Thanks. There's some documentation available:
https://openjdk.java.net/jtreg/
I guess your colleagues can assist you with that so you don't have to figure 
out everything alone.


> Thanks for your time on this.  As you can tell, I'm inexperienced in
> writing openjdk code, so your patience and careful review is really
> appreciated.
I'm glad you work on contributions. I think we should welcome new contributors 
and assist as far as we can.

Best regards,
Martin


> -----Original Message-
> From: Corey Ashford 
> Sent: Donnerstag, 27. August 2020 00:17
> To: Doerr, Martin ; Michihiro Horie
> 
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev  d...@openjdk.java.net>; Kazunori Ogata ;
> jos...@br.ibm.com
> Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
> API for Base64 decoding
> 
> Hi Martin,
> 
> Some inline responses below.
> 
> On 8/26/20 8:26 AM, Doerr, Martin wrote:
> 
> > Hi Corey,
> >
> > I should explain my comments regarding Base64.java better.
> >
> >> Let's be precise: "should process a multiple of four" => "must process a
> >> multiple of four"
> > Did you try to support non-multiple of 4 and this was intended as
> recommendation?
> > I think making it a requirement and simplifying the logic in decode0 is
> better.
> > Or what's the benefit of the recommendation?
> 
> If I make a requirement, I feel decode0 should check that the
> requirement is met, and raise some kind of internal error if it isn't.
> That actually was my first implementation, but I received some comments
> during an internal review suggesting that I just "round down" the
> destination count to the closest multiple of 3 less than or equal to the
> returned value, rather than throw an internal exception which would
> confuse users.  This "enforces" the rule, in some sense, without error
> handling.  Do you have some thoughts about this?
> 
> >
> >>> If any illegal base64 bytes are encountered in the source by the
> >>> intrinsic, the intrinsic can return a data length of zero or any
> >>> number of bytes before the place where the illegal base64 byte
> >>> was encountered.
> >> I think this has a drawback. Somebody may use a debugger and want to
> stop
> >> when throwing IllegalArgumentException. He should se

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-08-26 Thread Doerr, Martin

Hi Corey,

I should explain my comments regarding Base64.java better.

> Let's be precise: "should process a multiple of four" => "must process a
> multiple of four"
Did you try to support non-multiple of 4 and this was intended as 
recommendation?
I think making it a requirement and simplifying the logic in decode0 is better.
Or what's the benefit of the recommendation?

> > If any illegal base64 bytes are encountered in the source by the
> > intrinsic, the intrinsic can return a data length of zero or any
> > number of bytes before the place where the illegal base64 byte
> > was encountered.
> I think this has a drawback. Somebody may use a debugger and want to stop
> when throwing IllegalArgumentException. He should see the position which
> matches the Java implementation.
This is probably hard to understand. Let me try to explain it by example:
1. 80 Bytes get processed by the intrinsic and 60 Bytes written to the 
destination array.
2. The intrinsic sees an illegal base64 Byte and it returns 12 which is allowed 
by your specification.
3. The compiled method containing the intrinsic hits a safepoint (e.g. in the 
large while loop in decodeBlockSlow).
4. A JVMTI agent (debugger) reads dp and dst.
5. The person using the debugger gets angry because more bytes than dp were 
written into dst. The JVM didn't follow the specified behavior.

I guess we can and should avoid it by specifying that the intrinsic needs to 
return the dp value matching the number of Bytes written.

Best regards,
Martin


> -Original Message-
> From: Doerr, Martin
> Sent: Dienstag, 25. August 2020 15:38
> To: Corey Ashford ; Michihiro Horie
> 
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev  d...@openjdk.java.net>; Kazunori Ogata ;
> jos...@br.ibm.com
> Subject: RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
> API for Base64 decoding
> 
> Hi Corey,
> 
> thanks for proposing this change. I have comments and suggestions
> regarding various files.
> 
> 
> Base64.java
> 
> This is the only file which needs another review from core-libs-dev.
> First of all, I like the idea to use a HotSpotIntrinsicCandidate which can
> consume as many bytes as the implementation wants.
> 
> Comment before decodeBlock:
> Let's be precise: "should process a multiple of four" => "must process a
> multiple of four"
> 
> > If any illegal base64 bytes are encountered in the source by the
> > intrinsic, the intrinsic can return a data length of zero or any
> > number of bytes before the place where the illegal base64 byte
> > was encountered.
> I think this has a drawback. Somebody may use a debugger and want to stop
> when throwing IllegalArgumentException. He should see the position which
> matches the Java implementation.
> 
> Please note that the comment indentation differs from other comments.
> 
> decode0: Final "else" after return is redundant.
> 
> 
> stubGenerator_ppc.cpp
> 
> "__vector" breaks AIX build!
> Does it work on Big Endian linux with old gcc (we require 7.3.1, now)?
> Please either support Big Endian properly or #ifdef it out.
> What exactly does it on linux?
> I remember that we had tried such prefixes but were not satisfied. I think it
> didn't enforce 16 Byte alignment if I remember correctly.
> 
> Attention: C2 does no longer convert int/bool to 64 bit values (since JDK-
> 8086069). So the argument registers for offset, length and isURL may contain
> garbage in the higher bits.
> 
> You may want to use load_const_optimized which produces shorter code.
> 
> You may want to use __ align(32) to align unrolled_loop_start.
> 
> I'll review the algorithm in detail when I find more time.
> 
> 
> assembler_ppc.hpp
> assembler_ppc.inline.hpp
> vm_version_ppc.cpp
> vm_version_ppc.hpp
> Please rebase. Parts of the change were pushed as part of 8248190: Enable
> Power10 system and implement new byte-reverse instructions
> 
> 
> vmSymbols.hpp
> Indentation looks odd at the end.
> 
> 
> library_call.cpp
> Good. Indentation style of the call parameters differs from encodeBlock.
> 
> 
> runtime.cpp
> Good.
> 
> 
> aotCodeHeap.cpp
> vmSymbols.cpp
> shenandoahSupport.cpp
> vmStructs_jvmci.cpp
> shenandoahSupport.cpp
> escape.cpp
> runtime.hpp
> stubRoutines.cpp
> stubRoutines.hpp
> vmStructs.cpp
> Good and trivial.
> 
> 
> Tests:
> I think we should have JTREG tests to check for regressions in the future.
> 
> Best regards,
> Martin
> 
> 
> > -Original Message-
> > From: Corey Ashford 
> > Sent: Mittwoch, 19. August 2020 20:11
> > To: Michihiro Horie 
> > Cc: hotspot-c

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

2020-08-25 Thread Doerr, Martin

Hi Corey,

thanks for proposing this change. I have comments and suggestions regarding 
various files.

Base64.java

This is the only file which needs another review from core-libs-dev.
First of all, I like the idea to use a HotSpotIntrinsicCandidate which can 
consume as many bytes as the implementation wants.

Comment before decodeBlock:
Let's be precise: "should process a multiple of four" => "must process a 
multiple of four"

> If any illegal base64 bytes are encountered in the source by the
> intrinsic, the intrinsic can return a data length of zero or any
> number of bytes before the place where the illegal base64 byte
> was encountered.
I think this has a drawback. Somebody may use a debugger and want to stop when 
throwing IllegalArgumentException. He should see the position which matches the 
Java implementation.

Please note that the comment indentation differs from other comments.

decode0: Final "else" after return is redundant.

stubGenerator_ppc.cpp

"__vector" breaks AIX build!
Does it work on Big Endian linux with old gcc (we require 7.3.1, now)?
Please either support Big Endian properly or #ifdef it out.
What exactly does it on linux?
I remember that we had tried such prefixes but were not satisfied. I think it 
didn't enforce 16 Byte alignment if I remember correctly.

Attention: C2 does no longer convert int/bool to 64 bit values (since 
JDK-8086069). So the argument registers for offset, length and isURL may 
contain garbage in the higher bits.

You may want to use load_const_optimized which produces shorter code.

You may want to use __ align(32) to align unrolled_loop_start.

I'll review the algorithm in detail when I find more time.

assembler_ppc.hpp
assembler_ppc.inline.hpp
vm_version_ppc.cpp
vm_version_ppc.hpp
Please rebase. Parts of the change were pushed as part of 8248190: Enable 
Power10 system and implement new byte-reverse instructions

vmSymbols.hpp
Indentation looks odd at the end.

library_call.cpp
Good. Indentation style of the call parameters differs from encodeBlock.

runtime.cpp
Good.

aotCodeHeap.cpp
vmSymbols.cpp
shenandoahSupport.cpp
vmStructs_jvmci.cpp
shenandoahSupport.cpp
escape.cpp
runtime.hpp
stubRoutines.cpp
stubRoutines.hpp
vmStructs.cpp
Good and trivial.

Tests:
I think we should have JTREG tests to check for regressions in the future.

Best regards,
Martin

> -Original Message-
> From: Corey Ashford 
> Sent: Mittwoch, 19. August 2020 20:11
> To: Michihiro Horie 
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev  d...@openjdk.java.net>; Kazunori Ogata ;
> jos...@br.ibm.com; Doerr, Martin 
> Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
> API for Base64 decoding
> 
> Michihiro Horie posted up a new iteration of this webrev for me.  This
> time the webrev includes a complete implementation of the intrinsic for
> Power9 and Power10.
> 
> You can find it here:
> http://cr.openjdk.java.net/~mhorie/8248188/webrev.02/
> 
> Changes in webrev.02 vs. webrev.01:
> 
>* The method header for the intrinsic in the Base64 code has been
> rewritten using the Javadoc style.  The clarity of the comments has been
> improved and some verbosity has been removed.  There are no additional
> functional changes to Base64.java.
> 
>* The code needed to martial and check the intrinsic parameters has
> been added, using the base64 encodeBlock intrinsic as a guideline.
> 
>* A complete intrinsic implementation for Power9 and Power10 is included.
> 
>* Adds some Power9 and Power10 assembler instructions needed by the
> intrinsic which hadn't been defined before.
> 
> The intrinsic implementation in this patch accelerates the decoding of
> large blocks of base64 data by a factor of about 3.5X on Power9.
> 
> I'm attaching two Java test cases I am using for testing and
> benchmarking.  The TestBase64_VB encodes and decodes randomly-sized
> buffers of random data and checks that original data matches the
> encoded-then-decoded data.  TestBase64Errors encodes a 48K block of
> random bytes, then corrupts each byte of the encoded data, one at a
> time, checking to see if the decoder catches the illegal byte.
> 
> Any comments/suggestions would be appreciated.
> 
> Thanks,
> 
> - Corey
> 
> On 7/27/20 6:49 PM, Corey Ashford wrote:
> > Michihiro Horie uploaded a new revision of the Base64 decodeBlock
> > intrinsic API for me:
> >
> > http://cr.openjdk.java.net/~mhorie/8248188/webrev.01/
> >
> > It has the following changes with respect to the original one posted:
> >
> >   * In the event of encountering a non-base64 character, instead of
> > having a separate error code of -1, the intrinsic can now just return
> > either 0, or the number of data bytes produced up t

RE: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit

2020-04-30 Thread Doerr, Martin

+1

Best regards,
Martin

From: Alexey Semenyuk 
Sent: Donnerstag, 30. April 2020 18:29
To: Baesken, Matthias ; core-libs-dev 

Cc: Doerr, Martin 
Subject: Re: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 
32bit

Looks good assuming the patch was tested with 64bit build.

- Alexey
On 4/30/2020 10:12 AM, Baesken, Matthias wrote:
Hello, please look into this small fix for a link error we faced on Windows 
32bit.

Currently we run into this link error :
jpackageapplauncher

* For target 
support_native_jdk.incubator.jpackage_jpackageapplauncher_BUILD_JPACKAGE_APPLAUNCHEREXE_link:
LINK : fatal error LNK1561: entry point must be defined

looks like the wWinMain signature in
src\jdk.incubator.jpackage\windows\native\applauncher\WinLauncher.cpp
has to be adjusted.

Bug/webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8244183.0/

Thanks, Matthias

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

2020-03-24 Thread Doerr, Martin

Thanks a lot for looking into this, Alan, Chris and Christoph!

We had also looked at 
"8217997: Better socket support": 
https://hg.openjdk.java.net/jdk/jdk/rev/94710bb2a5bb
which was backported as
"8218573: Better socket support": 
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480
with the spec update.
It's not so easy to understand which changes need to get backportet and we 
should make sure we don't miss anything really important.

Thanks for shedding more light into the history.

I've closed it as "Not an Issue".

Best regards,
Martin


> -Original Message-
> From: Alan Bateman 
> Sent: Dienstag, 24. März 2020 10:53
> To: Langer, Christoph ; Doerr, Martin
> ; core-libs-dev@openjdk.java.net; jdk-updates-
> d...@openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> On 24/03/2020 08:19, Langer, Christoph wrote:
> >
> > Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was 
> > derived
> from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the
> only place where I was looking for JDK-8218573, so I couldn't find it.
> I don't have time to dig into this tangled web but it does appear that a
> backport issue was used instead of the main issue in at least one case.
> That might be part of the confusion with the JBS issues. It also appears
> that JDK-8223326 has been backported to several releases where it is not
> applicable.
> 
> >
> > By spec part you mean the "@throws SecurityException" sections? Do you
> think those should not have been part of the 11u/13u change? Should these
> be even rolled back?
> >
> The spec changes to NetPermission and the protected Socket constructor
> should not be in the update releases. If a security fix involves a spec
> clarification then a good starting assumption is that the scope of the
> change for the update releases, if applicable, will be bit different.
> 
> -Alan.

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

2020-03-23 Thread Doerr, Martin

Hi Paul,

thanks for the review.

We had already asked, but this one can't get opened up. I would have preferred 
a normal backport, too.

Best regards,
Martin


> -Original Message-
> From: Hohensee, Paul 
> Sent: Montag, 23. März 2020 19:29
> To: Doerr, Martin ; core-libs-
> d...@openjdk.java.net; jdk-updates-...@openjdk.java.net
> Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> The changeset references JDK-8223326, which is private. If possible, ask
> Oracle to make it public so we can do a normal backport rather than file an
> 11u-specific issue. The backport itself looks fine.
> 
> Thanks,
> Paul
> 
> On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin"  updates-dev-boun...@openjdk.java.net on behalf of
> martin.do...@sap.com> wrote:
> 
> 
> Hi,
> 
> I'd like to backport JDK-8223326 from jdk/jdk.
> 
> 11u backport issue:
> https://bugs.openjdk.java.net/browse/JDK-8241460
> 
> Original change:
> https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
> 
> 11u backport webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
> 
> I had to integrate the change manually due to context changes. However,
> the new code fits to the 11u versions.
> 
> Please review.
> 
> Best regards,
> Martin
> 
>

[11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

2020-03-23 Thread Doerr, Martin

Hi,

I'd like to backport JDK-8223326 from jdk/jdk.

11u backport issue:
https://bugs.openjdk.java.net/browse/JDK-8241460

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc

11u backport webrev:
http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/

I had to integrate the change manually due to context changes. However, the new 
code fits to the 11u versions.

Please review.

Best regards,
Martin

RE: RFR(XS): 8239856: [ntintel] asserts about copying unaligned array element

2020-02-24 Thread Doerr, Martin

Hi Thomas,

thanks for the quick review.

ATTRIBUTE_ALIGNED is defined in hotspot. I can’t use it for 
src/jdk.jdwp.agent/share/native/libjdwp/ArrayReferenceImpl.c.

Christoph had already suggested to make it available for core libs, too, but I 
haven’t found a good place for it.

Best regards,
Martin


From: Thomas Stüfe 
Sent: Montag, 24. Februar 2020 12:52
To: Doerr, Martin 
Cc: core-libs-dev@openjdk.java.net; Lindenmaier, Goetz 
; Langer, Christoph 
Subject: Re: RFR(XS): 8239856: [ntintel] asserts about copying unaligned array 
element

Hi Martin,

maybe use ATTRIBUTE_ALIGNED instead?

Cheers, Thomas

On Mon, Feb 24, 2020 at 12:44 PM Doerr, Martin 
mailto:martin.do...@sap.com>> wrote:
Hi,

we had fixed stack array alignment for Windows 32 bit with JDK-8220348.
However, there are also stack allocated jlong and jdouble used as source for 
SetLongArrayRegion and SetDoubleArrayRegion with insufficient alignment for 
this platform.

Here’s my proposed fix:
http://cr.openjdk.java.net/~mdoerr/8239856_win32_long_double_align/webrev.00/

Please review.

Best regards,
Martin

RFR(XS): 8239856: [ntintel] asserts about copying unaligned array element

2020-02-24 Thread Doerr, Martin

Hi,

we had fixed stack array alignment for Windows 32 bit with JDK-8220348.
However, there are also stack allocated jlong and jdouble used as source for 
SetLongArrayRegion and SetDoubleArrayRegion with insufficient alignment for 
this platform.

Here’s my proposed fix:
http://cr.openjdk.java.net/~mdoerr/8239856_win32_long_double_align/webrev.00/

Please review.

Best regards,
Martin

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

2019-12-06 Thread Doerr, Martin

Hi Christoph,

that would work, but I don’t want to pollute this file with compiler specific 
defines. In addition, I don’t like introducing a macro which works on some 
platforms and does nothing on other ones (which is the case for hotspot’s 
ATTRIBUTE_ALIGNED).

Because Windows 32 bit is the only affected platform, I prefer not to touch 
other ones. Are you ok with webrev.00 as it is?

Best regards,
Martin



From: Langer, Christoph 
Sent: Donnerstag, 5. Dezember 2019 12:16
To: Doerr, Martin 
Cc: core-libs-dev@openjdk.java.net; security-dev 
; Lindenmaier, Goetz 
; Thomas Stüfe 
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

I can see that both places already include headers from 
src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. 
WindowsPreferences.c already includes it.

Best regards
Christoph

From: Doerr, Martin mailto:martin.do...@sap.com>>
Sent: Donnerstag, 5. Dezember 2019 12:00
To: Thomas Stüfe mailto:thomas.stu...@gmail.com>>; 
Langer, Christoph mailto:christoph.lan...@sap.com>>
Cc: core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; 
security-dev 
mailto:security-...@openjdk.java.net>>; 
Lindenmaier, Goetz mailto:goetz.lindenma...@sap.com>>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && 
defined (_MSC_VER)

I’d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get 
defined easily for Visual Studio and GCC, but some other compilers may be more 
difficult. Note that this macro is only defined for a selected set of compilers 
in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem 
that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job 
for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas Stüfe mailto:thomas.stu...@gmail.com>>
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin mailto:martin.do...@sap.com>>
Cc: core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net>; 
security-dev 
mailto:security-...@openjdk.java.net>>; 
Lindenmaier, Goetz mailto:goetz.lindenma...@sap.com>>
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the 
platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable 
with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin 
mailto:martin.do...@sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u 
backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated 
buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs 
to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. 
Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on 
stack?
Best regards,
Martin

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

2019-12-05 Thread Doerr, Martin

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && 
defined (_MSC_VER)

I’d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get 
defined easily for Visual Studio and GCC, but some other compilers may be more 
difficult. Note that this macro is only defined for a selected set of compilers 
in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem 
that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job 
for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas Stüfe 
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin 
Cc: core-libs-dev@openjdk.java.net; security-dev 
; Lindenmaier, Goetz 
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the 
platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable 
with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin 
mailto:martin.do...@sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u 
backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated 
buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs 
to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. 
Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on 
stack?
Best regards,
Martin

RFR(S): 8220348: [ntintel] asserts about copying unalinged array

2019-12-02 Thread Doerr, Martin

Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u 
backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated 
buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs 
to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. 
Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on 
stack?
Best regards,
Martin

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

2019-11-26 Thread Doerr, Martin

Hi Matthias and Erik,

I also think this is an interesting option.

I like the idea to generate smaller libraries. In addition to that, I could 
also imagine building with -Os (size optimized) by default and only select -O3 
for performance critical files (e.g. C2's register allocation, some gc code, 
...).

If we want to go into such a direction for all linux platforms and want to use 
this s390 only change as some kind of pipe cleaner, I think this change is fine 
and can get pushed.
Otherwise, I think building s390 differently and not intending to do the same 
for other linux platforms would be not so good.

We should only make sure the exported symbols are set up properly to avoid that 
this optimization throws out too much.

My 50 Cents.

Best regards,
Martin



> -Original Message-
> From: build-dev  On Behalf Of
> Baesken, Matthias
> Sent: Freitag, 22. November 2019 16:01
> To: Erik Joelsson ; 'build-...@openjdk.java.net'
> ; core-libs-dev@openjdk.java.net
> Subject: RE: RFR: 8234525: enable link-time section-gc for linux
> s390x to remove unused code
> 
> Hi Erik,
>yes it makes the build more chatty -
> our   linux s390   product   build  log  of  jdk/jdk   goes from  ~ 60.000  
> lines to  ~
> 123.000  lines with the patch.
> 
> However the change  is  linux s390 only so I guess it will not disturb other
> people ( in case we bring it to more platforms later on, we could remove the
> printing or make it configurable ).
> 
> Additionally the "chatty" output  is used currently for eliminating   unused
> functions + datacross-platform
> (see for example   https://bugs.openjdk.java.net/browse/JDK-8234629  ).
> 
> Best regards, Matthias
> 
> 
> 
> >
> > Hello Matthias,
> >
> > This looks like an interesting change. If you want to enable this for
> > s390x, I'm ok with it. If it works out well, perhaps we can find a way
> > to expand this to other architectures.
> >
> > Do you really want to set --print-gc-sections by default? I would assume
> > that makes the build quite chatty.
> >
> > /Erik
> >
> > On 2019-11-21 00:54, Baesken, Matthias wrote:
> > > Hello,
> > >
> > > gcc and ld can be instructed to work together to "garbage collect" unused
> > input sections.
> > > This feature eliminates unused code from native libraries. As a
> prerequisite
> > to take full advantage of the feature,
> > > the source files need to be compiled with "-ffunction-sections -fdata-
> > sections".
> > >
> > > Details on what happens can be found in the ld documentation:
> > https://linux.die.net/man/1/ld .
> > > See the description of --gc-sections and --print-gc-sections therein.
> > > For more detailed insights there is a talk available from ELC2010:
> > https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
> > >
> > > My change enables the unused code elimination on linux s390x .
> > > (on the other Linux platforms, there are still issues to be solved with 
> > > the
> > serviceability agent, but we do not have the serviceability agent  on linux
> > s390x).
> > >
> > > The change has 2 benefits :
> > > - native libs with unused code get smaller (some get alot smaller)
> > > some example lib sizes  from  linuxs390x (product build) :
> > >  default settings  / link-time gc-sections
> > > libmlib_image.so556K 536K
> > > libjavajpeg.so  300K 292K
> > > libsplashscreen.so  412K 268K
> > > libfontmanager.so   1.4M 864K
> > > libjvm.so19M  17M
> > >
> > > - the flag --print-gc-sections  outputs the removed sections when calling
> > the linker;
> > > this helps a lot to find coding "waiting for" cross-platform removal.
> > >
> > >
> > > Here is an example output of --print-gc-sections for the libnet-build 
> > > (linux
> > s390x) :
> > >
> > > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file
> > '/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <---
> > seems to be dead
> > > /bin/ld: Removing unused section '.text.NET_ReadV' in file
> > '/builddir/support/native/java.base/libnet/linux_close.o'   
> > <---
> seems
> > to be dead, I requested cross-platform removal with
> > https://bugs.openjdk.java.net/browse/JDK-8234501
> > > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname'
> in
> > file '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to
> be
> > dead
> > > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in
> > file '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to
> be
> > dead
> > > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in
> file
> > '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to 
> > be
> > dead
> > > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file
> > '/builddir/support/native/java.base/libnet/net_util_md.o'   <--- 
> > seems

RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings

2019-07-24 Thread Doerr, Martin

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  On Behalf Of 
Baesken, Matthias
Sent: Dienstag, 23. Juli 2019 17:15
To: 'hotspot-...@openjdk.java.net' ; 
core-libs-dev@openjdk.java.net; net-...@openjdk.java.net
Cc: 'ppc-aix-port-...@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

RE: [11u] RFR (Backport): 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

2019-05-31 Thread Doerr, Martin

Hi Christoph,

backport looks good.

Best regards,
Martin


> -Original Message-
> From: jdk-updates-dev  On
> Behalf Of Langer, Christoph
> Sent: Freitag, 24. Mai 2019 09:52
> To: jdk-updates-...@openjdk.java.net
> Cc: core-libs-dev 
> Subject: [11u] RFR (Backport): 8223553: Fix code constructs that
> do not compile with the Eclipse Java Compiler
> 
> Hi,
> 
> I'd like to bring this fix down to jdk11 updates. Unfortunately, the webrev 
> did
> not apply cleanly in the imports section of
> src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java, so
> I had to resolve this part manually. I also updated the copyright year. Please
> check.
> 
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223553.11u/
> 
> Thanks
> Christoph

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

2018-12-11 Thread Doerr, Martin

Hi Gustavo,

thanks for your improvements. You can also remove the trailing \t from the opto 
assembly.
Note that there's no need to re-push newer version to jdk/submit when only PPC 
files were changed. jdk/submit doesn't look at them.

Best regards,
Martin

-Original Message-
From: Gustavo Romero  
Sent: Mittwoch, 12. Dezember 2018 03:08
To: Michihiro Horie 
Cc: core-libs-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; 
Doerr, Martin ; Roger Riggs ; 
Vladimir Kozlov ; Simonis, Volker 

Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for 
isDigit/isLowerCase/isUpperCase/isWhitespace

Hi Michi,

On 12/11/2018 11:12 PM, Michihiro Horie wrote:
> Thank you for finding the issue on Power8. You do not need a check with 
> has_darn in the ppc.ad. It is better to add a check in vm_versoin_ppc.

I agree.

> I uploaded webrev.08 based on your webrev.07. (Thanks for the enhancement of 
> opto assembly and removing trailing spaces!)
> http://cr.openjdk.java.net/~mhorie/8213754/webrev.08/ 
> <http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.08/>

Thanks for the updated webrev. Looks good!
I've just pushed webrev.08 to jdk/submit expecting no failures as .07 passed 
fine.

Once I get the jdk/submit results tomorrow I'll push.

Best regards,
Gustavo

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

2018-12-11 Thread Doerr, Martin

Hi Michihiro,

the shared code looks good to me, now.

Looks like the PPC64 is not consistent any more.
Where do you enable UseCharacterCompareIntrinsics on PPC64?
Why aren't you using it for match_rule_supported in the ad file?
I think has_darn could be used to enable it in vm_version_ppc.

Best regards,
Martin


-Original Message-
From: Vladimir Kozlov  
Sent: Montag, 10. Dezember 2018 20:33
To: Michihiro Horie ; Gustavo Romero 

Cc: core-libs-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; 
Doerr, Martin ; Roger Riggs ; 
Simonis, Volker 
Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for 
isDigit/isLowerCase/isUpperCase/isWhitespace

On 12/9/18 5:28 PM, Michihiro Horie wrote:
> Hi Vladimir,
> 
> Thanks a lot for your review. I also fixed the copyright in intrinsicnode.hpp.
> 
>  >Did you look on code generated by C2 with your latest changes?
> Yes,I usually check generated code with Oprofile and they were as expected 
> like:
> :
> 90 0.0905 : 3fff64c27654: rlwinm r12,r9,24,8,31
> 12 0.0121 : 3fff64c27658: li r11,14640
> 15 0.0151 : 3fff64c2765c: cmprb cr5,0,r31,r11
> 5527 5.5587 : 3fff64c27660: setb r11,cr5
> 36010 36.2164 : 3fff64c27664: stb r11,16(r15)

Good.

> :
> 
> I found a CSR FAQ that mentions adding a diagnostic flag do not need CSR 
> process. This time I do not need CSR.
> https://wiki.openjdk.java.net/display/csr/CSR+FAQs

Thank is correct.

> 
> Hi Gustavo,
> Could I ask you to sponsor the latest change webrev.05? I would like you to 
> test it on your P9 node too.

Thanks,
Vladimir

> 
> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
> 
> Inactive hide details for Vladimir Kozlov ---2018/12/08 03:48:04---From: 
> Vladimir Kozlov  
> To: RogerVladimir Kozlov ---2018/12/08 03:48:04---From: Vladimir Kozlov 
>  To: Roger Riggs 
> , Michihiro Horie 
> 
> From: Vladimir Kozlov 
> To: Roger Riggs , Michihiro Horie 
> Cc: core-libs-dev@openjdk.java.net, hotspot-compiler-...@openjdk.java.net, 
> martin.do...@sap.com, volker.simo...@sap.com
> Date: 2018/12/08 03:48
> Subject: Re: RFR: 8213754: PPC64: Add Intrinsics for 
> isDigit/isLowerCase/isUpperCase/isWhitespace
> 
> 
> 
> 
> 
> Hi Michihiro,
> 
> Hotspot changes looks fine.
> Did you look on code generated by C2 with your latest changes?
> 
> And Copyright year change in intrinsicnode.hpp is incorrect:
> 
> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 
> Should be
> 
> * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> 
> 
> Thanks,
> Vladimir
> 
> On 12/7/18 10:08 AM, Roger Riggs wrote:
>  > Hi Michihiro,
>  >
>  > Looks fine with the updates.
>  >
>  > Its great that the change to isDigit is beneficial on other platforms too.
>  >
>  > A very small editorial:
>  >    There should be a comma  "," after the 2018 in the copyright of:
>  >    test/micro/org/openjdk/bench/java/lang/Characters.java
>  >
>  > Thanks, Roger
>  >
>  >
>  > On 12/07/2018 03:13 AM, Michihiro Horie wrote:
>  >>
>  >> Hi Roger,
>  >>
>  >> I updated my webrev.
>  >> http://cr.openjdk.java.net/~mhorie/8213754/webrev.04/ 
> <http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.04/>
>  >> <http://cr.openjdk.java.net/%7Emhorie/8213754/webrev.04/>
>  >>
>  >> >0x80 might be a good choice or 0xff.
>  >> I agree,thanks.
>  >>
>  >> >I was wondering about the performance without the PPC specific intrinsic 
> but with the
>  >> >CharacterDataLatin1.java.template code for isDigit being:
>  >> >        return '0' <= ch && ch <= '9';
>  >> I now understand your point,thanks for your explanation. Both on Power9 
> and Skylake, the
>  >> isDigit(ch)using ‘0’…’9’explicitly in CharacterDataLatin1.java.template 
> without PPC specific
>  >> intrinsicwas around 15% faster than the original code that does not 
> include my changes. I fixed my
>  >> change using ‘0’…’9’for this isDigit(ch).
>  >>
>  >>
>  >> Best regards,
>  >> --
>  >> Michihiro,
>  >> IBM Research - Tokyo
>  >>
>  >> Inactive hide details for Roger Riggs ---2018/12/07 01:23:39---Hi 
> Michihiro, On 12/06/2018 02:38
>  >> AM, Michihiro Horie wrote:Roger Riggs ---2018/12/07 01:23:39---Hi 
> Michihiro, On 12/06/2018 02:38
>  >> AM, Michihiro Horie wr

RE: [XS] RFR : JDK-8181145 : add platforms to test java/nio/ByteOrder/NativeOrder.java (test change)

2017-05-30 Thread Doerr, Martin

Hi,

thanks for providing the webrev and for reviewing.
I’ve pushed it.

Best regards,
Martin


From: Martin Buchholz [mailto:marti...@google.com]
Sent: Freitag, 26. Mai 2017 17:55
To: Baesken, Matthias <matthias.baes...@sap.com>
Cc: core-libs-dev@openjdk.java.net; Simonis, Volker <volker.simo...@sap.com>; 
Schmidt, Lutz <lutz.schm...@sap.com>; Doerr, Martin <martin.do...@sap.com>
Subject: Re: [XS] RFR : JDK-8181145 : add platforms to test 
java/nio/ByteOrder/NativeOrder.java (test change)

Looks good to me!

On Fri, May 26, 2017 at 7:43 AM, Baesken, Matthias 
<matthias.baes...@sap.com<mailto:matthias.baes...@sap.com>> wrote:
Please review this small test change .
It adds a number of platforms to the existing test  jdk10  jtreg test  
java/nio/ByteOrder/NativeOrder.java  .

Especially the porting platforms ppc64/ppc64le/s390x are added .


Webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8181145/


bug :

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


Thanks, Matthias

RE: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

2016-11-24 Thread Doerr, Martin

Hi Gustavo,

thanks for providing the webrevs.

I have ran the StrictMath jck tests which fail when building with -O3 and 
without -ffp-contract=off:
FailedTests:
api/java_lang/StrictMath/desc.html#acos 
javasoft.sqe.tests.api.java.lang.StrictMath.acos_test
api/java_lang/StrictMath/desc.html#asin 
javasoft.sqe.tests.api.java.lang.StrictMath.asin_test
api/java_lang/StrictMath/desc.html#atan 
javasoft.sqe.tests.api.java.lang.StrictMath.atan_test
api/java_lang/StrictMath/desc.html#atan2 
javasoft.sqe.tests.api.java.lang.StrictMath.atan2_test
api/java_lang/StrictMath/desc.html#cos 
javasoft.sqe.tests.api.java.lang.StrictMath.cos_test
api/java_lang/StrictMath/desc.html#exp 
javasoft.sqe.tests.api.java.lang.StrictMath.exp_test
api/java_lang/StrictMath/desc.html#log 
javasoft.sqe.tests.api.java.lang.StrictMath.log_test
api/java_lang/StrictMath/desc.html#sin 
javasoft.sqe.tests.api.java.lang.StrictMath.sin_test
api/java_lang/StrictMath/desc.html#tan 
javasoft.sqe.tests.api.java.lang.StrictMath.tan_test
api/java_lang/StrictMath/index.html#expm1 
javasoft.sqe.tests.api.java.lang.StrictMath.expm1Tests -TestCaseID ALL
api/java_lang/StrictMath/index.html#log10 
javasoft.sqe.tests.api.java.lang.StrictMath.log10Tests -TestCaseID ALL
api/java_lang/StrictMath/index.html#log1p 
javasoft.sqe.tests.api.java.lang.StrictMath.log1pTests -TestCaseID ALL

All of them have passed when building with -O3 and -ffp-contract=off (on 
linuxppc64le).

So thumbs up from my side.

Thanks and best regards,
Martin



-Original Message-
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-boun...@openjdk.java.net] On 
Behalf Of Volker Simonis
Sent: Mittwoch, 23. November 2016 15:06
To: Gustavo Romero 
Cc: build-dev ; ppc-aix-port-...@openjdk.java.net; 
Java Core Libs ; hotspot-...@openjdk.java.net
Subject: Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to 
non-optimized compilation

Hi Gustavo,

thanks a lot for tracking this down!

The change looks good and I a can sponsor it once you get another review from 
the build group and the FC Extension Request was approved.

In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK 
[2] as this contains quite a lot of additional conformance tests which can be 
quite valuable for changes like this.

Regards,
Volker

[1] http://openjdk.java.net/legal/octla-java-se-8.pdf
[2] http://openjdk.java.net/groups/conformance/JckAccess/


On Tue, Nov 22, 2016 at 1:43 AM, Gustavo Romero  
wrote:
> Hi,
>
> Could the following change be reviewed, please?
>
> webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/
> webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/
> bug:https://bugs.openjdk.java.net/browse/JDK-8170153
>
> It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds 
> up the StrictMath methods (in some cases up to 3x) on that platform.
>
> On PPC64 fdlibm optimization can be done without precision issues if 
> floating-point expression contraction is disable, i.e. if the compiler 
> does not use floating-point multiply-add (FMA). For further details 
> please refer to gcc
> bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386
>
> No regression was observed on Math and StrictMath tests:
>
> Passed: java/lang/Math/AbsPositiveZero.java
> Passed: java/lang/Math/Atan2Tests.java
> Passed: java/lang/Math/CeilAndFloorTests.java
> Passed: java/lang/Math/CubeRootTests.java
> Passed: java/lang/Math/DivModTests.java
> Passed: java/lang/Math/ExactArithTests.java
> Passed: java/lang/Math/Expm1Tests.java
> Passed: java/lang/Math/FusedMultiplyAddTests.java
> Passed: java/lang/Math/HyperbolicTests.java
> Passed: java/lang/Math/HypotTests.java
> Passed: java/lang/Math/IeeeRecommendedTests.java
> Passed: java/lang/Math/Log10Tests.java
> Passed: java/lang/Math/Log1pTests.java
> Passed: java/lang/Math/MinMax.java
> Passed: java/lang/Math/MultiplicationTests.java
> Passed: java/lang/Math/PowTests.java
> Passed: java/lang/Math/Rint.java
> Passed: java/lang/Math/RoundTests.java
> Passed: java/lang/Math/SinCosCornerCasesTests.java
> Passed: java/lang/Math/TanTests.java
> Passed: java/lang/Math/WorstCaseTests.java
> Test results: passed: 21
>
> Passed: java/lang/StrictMath/CubeRootTests.java
> Passed: java/lang/StrictMath/ExactArithTests.java
> Passed: java/lang/StrictMath/Expm1Tests.java
> Passed: java/lang/StrictMath/HyperbolicTests.java
> Passed: java/lang/StrictMath/HypotTests.java
> Passed: java/lang/StrictMath/Log10Tests.java
> Passed: java/lang/StrictMath/Log1pTests.java
> Passed: java/lang/StrictMath/PowTests.java
> Test results: passed: 8
>
> and also on the following hotspot tests:
>
> Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java
> Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java
> Passed: 
> compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java
> Passed: 
>

AW: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

[11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

RE: [11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

[11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

RE: [11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module

[11u] RFR: 8241770 Module xxxAnnotation() methods throw NCDFE if module-info.class found as resource in unnamed module

RE: [11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag

[11u] RFR: 8235351: Lookup::unreflect should bind with the original caller independent of Method's accessible flag

RE: [11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

[11u] RFR: 8211825: ModuleLayer.defineModulesWithXXX does not setup delegation when module reads automatic module

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding

RE: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

[11u] RFR(S): 8223326: Regression introduced by CPU sync: java.security.AccessControlException: access denied ("java.net.NetPermission" "setSocketImpl")

RE: RFR(XS): 8239856: [ntintel] asserts about copying unaligned array element

RFR(XS): 8239856: [ntintel] asserts about copying unaligned array element

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

RFR(S): 8220348: [ntintel] asserts about copying unalinged array

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings

RE: [11u] RFR (Backport): 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

RE: RFR: 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace

RE: [XS] RFR : JDK-8181145 : add platforms to test java/nio/ByteOrder/NativeOrder.java (test change)

RE: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

30 matches

Site Navigation

Mail list logo

Footer information