Re: [12] RFR JDK-8214241: Problem list com/sun/jndi/ldap/LdapTimeoutTest.java on all platforms

[Amy Lu]

Thank you Vyom and Max for your quick review!

Pushed.

Thanks,
Amy

On 2018/11/23 12:39 PM, Weijun Wang wrote:



On Nov 23, 2018, at 12:10 PM, vyom tewari  wrote:

looks OK to me.

+1.

--Max


Vyom

On 23/11/18 9:28 AM, Amy Lu wrote:

Please review the patch to problem list com/sun/jndi/ldap/LdapTimeoutTest.java

This test fails frequently, originally observed on linux-x64 but recently also 
on other platforms, and should be problem listed before JDK-8151678 fixed.

bug: https://bugs.openjdk.java.net/browse/JDK-8214241
webrev: http://cr.openjdk.java.net/~amlu/8214241/webrev.00/

Thanks,
Amy

--- old/test/jdk/ProblemList.txt2018-11-23 11:53:27.0 +0800
+++ new/test/jdk/ProblemList.txt2018-11-23 11:53:26.0 +0800
@@ -876,7 +876,7 @@

  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 
linux-i586,macosx-all,windows-x64

-com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all
+com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 generic-all

  com/sun/jndi/dns/ConfigTests/PortUnreachable.java 7164518 macosx-all

Re: [12] RFR JDK-8214241: Problem list com/sun/jndi/ldap/LdapTimeoutTest.java on all platforms

[Weijun Wang]

> On Nov 23, 2018, at 12:10 PM, vyom tewari  wrote:
> 
> looks OK to me.

+1.

--Max

> 
> Vyom
> 
> On 23/11/18 9:28 AM, Amy Lu wrote:
>> Please review the patch to problem list 
>> com/sun/jndi/ldap/LdapTimeoutTest.java
>> 
>> This test fails frequently, originally observed on linux-x64 but recently 
>> also on other platforms, and should be problem listed before JDK-8151678 
>> fixed.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8214241
>> webrev: http://cr.openjdk.java.net/~amlu/8214241/webrev.00/
>> 
>> Thanks,
>> Amy
>> 
>> --- old/test/jdk/ProblemList.txt2018-11-23 11:53:27.0 +0800
>> +++ new/test/jdk/ProblemList.txt2018-11-23 11:53:26.0 +0800
>> @@ -876,7 +876,7 @@
>> 
>>  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 
>> linux-i586,macosx-all,windows-x64
>> 
>> -com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all
>> +com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 generic-all
>> 
>>  com/sun/jndi/dns/ConfigTests/PortUnreachable.java 7164518 macosx-all
>> 
>> 
>> 

Re: [12] RFR JDK-8214241: Problem list com/sun/jndi/ldap/LdapTimeoutTest.java on all platforms

[vyom tewari]

looks OK to me.

Vyom

On 23/11/18 9:28 AM, Amy Lu wrote:
Please review the patch to problem list 
com/sun/jndi/ldap/LdapTimeoutTest.java


This test fails frequently, originally observed on linux-x64 but 
recently also on other platforms, and should be problem listed before 
JDK-8151678 fixed.


bug: https://bugs.openjdk.java.net/browse/JDK-8214241
webrev: http://cr.openjdk.java.net/~amlu/8214241/webrev.00/

Thanks,
Amy

--- old/test/jdk/ProblemList.txt    2018-11-23 11:53:27.0 +0800
+++ new/test/jdk/ProblemList.txt    2018-11-23 11:53:26.0 +0800
@@ -876,7 +876,7 @@

 com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 
linux-i586,macosx-all,windows-x64


-com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all
+com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 generic-all

 com/sun/jndi/dns/ConfigTests/PortUnreachable.java 7164518 macosx-all

[12] RFR JDK-8214241: Problem list com/sun/jndi/ldap/LdapTimeoutTest.java on all platforms

[Amy Lu]

Please review the patch to problem list 
com/sun/jndi/ldap/LdapTimeoutTest.java


This test fails frequently, originally observed on linux-x64 but 
recently also on other platforms, and should be problem listed before 
JDK-8151678 fixed.


bug: https://bugs.openjdk.java.net/browse/JDK-8214241
webrev: http://cr.openjdk.java.net/~amlu/8214241/webrev.00/

Thanks,
Amy

--- old/test/jdk/ProblemList.txt    2018-11-23 11:53:27.0 +0800
+++ new/test/jdk/ProblemList.txt    2018-11-23 11:53:26.0 +0800
@@ -876,7 +876,7 @@

 com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 
linux-i586,macosx-all,windows-x64


-com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 linux-all
+com/sun/jndi/ldap/LdapTimeoutTest.java 8151678 generic-all

 com/sun/jndi/dns/ConfigTests/PortUnreachable.java 7164518 macosx-all

Re: RFR(XXS): 8214161: java.lang.IllegalAccessError: class jdk.internal.event.X509CertificateEvent (in module java.base) cannot access class jdk.jfr.internal.handlers.EventHandler (in module jdk.jfr)

[David Holmes]

Hi Markus,

Thanks for the explanation of the problem.

Reviewed.

Thanks,
David

On 23/11/2018 1:01 am, Markus Gronlund wrote:

Greetings,

Please review the following small fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214161
Webrev: http://cr.openjdk.java.net/~mgronlun/8214161/webrev01/

diff -r 0a77b7e41322 -r cec1604a9b89 
src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp
--- a/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp   
Thu Nov 22 11:15:53 2018 +0100
+++ b/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp   
Thu Nov 22 15:18:50 2018 +0100
@@ -447,6 +447,7 @@
if (registered_symbol == NULL) {
  registered_symbol = SymbolTable::lookup_only(registered_constant, sizeof 
registered_constant - 1, unused_hash);
  if (registered_symbol == NULL) {
+  untypedEventHandler = true;
return false;
  }
}

Description:

Events in module java.base can't refer to types in module "jdk.jfr" before the 
jdk.jfr module is loaded and valid read edges established.
Unfortunately, there exist an uncovered exit path in the code that leaves the 
eventHandler field "jdk.jfr"-typed, when it should not be.

Javap output:

Existing:
public final class jdk.internal.event.X509CertificateEvent extends 
jdk.internal.event.Event
...
   private static jdk.jfr.internal.handlers.EventHandler eventHandler;
 descriptor: Ljdk/jfr/internal/handlers/EventHandler;
 flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC

Fix:
public final class jdk.internal.event.X509CertificateEvent extends 
jdk.internal.event.Event
...
   private static java.lang.Object eventHandler;
 descriptor: Ljava/lang/Object;
 flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC

Tests: open/test/jdk/:jdk_jfr

Thanks
Markus

-jar option and the modulepath

[Richard Hillegas]

Can I scribble something in a jar file manifest which will cause "java 
-jar" to boot with a modulepath rather than a classpath? I do not see 
any support for a modulepath attribute in the Java 9 jar file 
documentation at 
https://docs.oracle.com/javase/9/docs/specs/jar/jar.html. My sense is 
that the -jar option commits the JVM to using a classpath.


Thanks,
-Rick

Re: RFR: JDK-8214223: tools/jdeps/listdeps/ListModuleDeps.java failed due to missing Lib2 file

[Alan Bateman]

On 22/11/2018 18:11, Mandy Chung wrote:

This adds test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
that is missing in the changeset for JDK-8213909.

Looks good.

Re: RFR: JDK-8214223: tools/jdeps/listdeps/ListModuleDeps.java failed due to missing Lib2 file

[Lance Andersen]

+1
> On Nov 22, 2018, at 1:11 PM, Mandy Chung  wrote:
> 
> This adds test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
> that is missing in the changeset for JDK-8213909.
> 
> Mandy
> 
> diff --git a/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java 
> b/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
> new file mode 100644
> --- /dev/null
> +++ b/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 only, as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * version 2 for more details (a copy is included in the LICENSE file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +package lib2;
> +
> +import java.lang.management.ManagementFactory;
> +
> +public class Lib2 {
> +public static long getPid() {
> +return ManagementFactory.getRuntimeMXBean().getPid();
> +}
> +}

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

RFR: JDK-8214223: tools/jdeps/listdeps/ListModuleDeps.java failed due to missing Lib2 file

[Mandy Chung]

This adds test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
that is missing in the changeset for JDK-8213909.

Mandy

diff --git a/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java 
b/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java

new file mode 100644
--- /dev/null
+++ b/test/langtools/tools/jdeps/listdeps/src/lib2/Lib2.java
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version

+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+package lib2;
+
+import java.lang.management.ManagementFactory;
+
+public class Lib2 {
+    public static long getPid() {
+    return ManagementFactory.getRuntimeMXBean().getPid();
+    }
+}

Re: RFR(XXS): 8214161: java.lang.IllegalAccessError: class jdk.internal.event.X509CertificateEvent (in module java.base) cannot access class jdk.jfr.internal.handlers.EventHandler (in module jdk.jfr)

[Erik Gahlin]

Looks good.

Erik

> On 22 Nov 2018, at 16:01, Markus Gronlund  wrote:
> 
> Greetings,
> 
> Please review the following small fix.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214161 
> Webrev: http://cr.openjdk.java.net/~mgronlun/8214161/webrev01/ 
> 
> diff -r 0a77b7e41322 -r cec1604a9b89 
> src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp
> --- a/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp  
>  Thu Nov 22 11:15:53 2018 +0100
> +++ b/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp  
>  Thu Nov 22 15:18:50 2018 +0100
> @@ -447,6 +447,7 @@
>   if (registered_symbol == NULL) {
> registered_symbol = SymbolTable::lookup_only(registered_constant, sizeof 
> registered_constant - 1, unused_hash);
> if (registered_symbol == NULL) {
> +  untypedEventHandler = true;
>   return false;
> }
>   }
> 
> Description:
> 
> Events in module java.base can't refer to types in module "jdk.jfr" before 
> the jdk.jfr module is loaded and valid read edges established.
> Unfortunately, there exist an uncovered exit path in the code that leaves the 
> eventHandler field "jdk.jfr"-typed, when it should not be.
> 
> Javap output:
> 
> Existing:
> public final class jdk.internal.event.X509CertificateEvent extends 
> jdk.internal.event.Event 
> ... 
>   private static jdk.jfr.internal.handlers.EventHandler eventHandler; 
> descriptor: Ljdk/jfr/internal/handlers/EventHandler; 
> flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC 
> 
> Fix: 
> public final class jdk.internal.event.X509CertificateEvent extends 
> jdk.internal.event.Event 
> ... 
>   private static java.lang.Object eventHandler; 
> descriptor: Ljava/lang/Object; 
> flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC  
> 
> Tests: open/test/jdk/:jdk_jfr
> 
> Thanks
> Markus

RFR(XXS): 8214161: java.lang.IllegalAccessError: class jdk.internal.event.X509CertificateEvent (in module java.base) cannot access class jdk.jfr.internal.handlers.EventHandler (in module jdk.jfr) beca

[Markus Gronlund]

Greetings,

Please review the following small fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214161 
Webrev: http://cr.openjdk.java.net/~mgronlun/8214161/webrev01/ 

diff -r 0a77b7e41322 -r cec1604a9b89 
src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp
--- a/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp   
Thu Nov 22 11:15:53 2018 +0100
+++ b/src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp   
Thu Nov 22 15:18:50 2018 +0100
@@ -447,6 +447,7 @@
   if (registered_symbol == NULL) {
 registered_symbol = SymbolTable::lookup_only(registered_constant, sizeof 
registered_constant - 1, unused_hash);
 if (registered_symbol == NULL) {
+  untypedEventHandler = true;
   return false;
 }
   }

Description:

Events in module java.base can't refer to types in module "jdk.jfr" before the 
jdk.jfr module is loaded and valid read edges established.
Unfortunately, there exist an uncovered exit path in the code that leaves the 
eventHandler field "jdk.jfr"-typed, when it should not be.

Javap output:

Existing:
public final class jdk.internal.event.X509CertificateEvent extends 
jdk.internal.event.Event 
... 
  private static jdk.jfr.internal.handlers.EventHandler eventHandler; 
descriptor: Ljdk/jfr/internal/handlers/EventHandler; 
flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC 

Fix: 
public final class jdk.internal.event.X509CertificateEvent extends 
jdk.internal.event.Event 
... 
  private static java.lang.Object eventHandler; 
descriptor: Ljava/lang/Object; 
flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC  

Tests: open/test/jdk/:jdk_jfr

Thanks
Markus

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

[Volker Simonis]

On Thu, Nov 22, 2018 at 3:00 PM Adam Farley8  wrote:
>
> Hi Volker,
>
> 1) Here is the "reasonable" code in the generated 
> jdk_internal_jimage_NativeImageBuffer.h
>
> --
> /* DO NOT EDIT THIS FILE - it is machine generated */
> #include 
> /* Header for class jdk_internal_jimage_NativeImageBuffer */
>
> #ifndef _Included_jdk_internal_jimage_NativeImageBuffer
> #define _Included_jdk_internal_jimage_NativeImageBuffer
> #ifdef __cplusplus
> extern "C" {
> #endif
> /*
>  * Class: jdk_internal_jimage_NativeImageBuffer
>  * Method:getNativeMap
>  * Signature: (Ljava/lang/String;)Ljava/nio/ByteBuffer;
>  */
> JNIEXPORT jobject JNICALL 
> Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap
>   (JNIEnv *, jclass, jstring);
>
> #ifdef __cplusplus
> }
> #endif
> #endif
> --
>
>
> 2) I have not yet reported this as a bug to the xlc developers. I will contact
> them now.
>
> 3) I did some experimenting, and it seems that the NativeImageBuffer.cpp 
> change
> is the only thing standing between us and a successful compilation on aix 
> using
> xlc 13.1 (assuming you're using source that compiles on aix with xlc 12.1).
>
> With that change (plus the jni_md change), the compilation completes.
>
> Without that change (after you've added the jni_md change though), the build
> will fail with this error message:
>
> --
> 12:19:58 
> "/workspace/build/aix-ppc64-normal-server-release/support/headers/java.base/jdk_internal_jimage_NativeImageBuffer.h",
>  line 15.27: 1540-0040 (S) The text 
> "Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap" is unexpected.  
> "visibility" may be undeclared or ambiguous.
> 12:19:59 CoreLibraries.gmk:192: recipe for target 
> '/workspace/build/aix-ppc64-normal-server-release/support/native/java.base/libjimage/NativeImageBuffer.o'
>  failed
> --
>

Can you please do the following:
 - take the command line from
/workspace/build/aix-ppc64-normal-server-release/support/native/java.base/libjimage/NativeImageBuffer.o.cmdline
 - replace '-c' with '-E' to get the preprocessor output
 - have a look at the offending line (e.g. have JNIEXPORT / JNICALL
been correctly expanded ?)

Unfortunately I don't have a version of XLC 13 to test this.

> Best Regards
>
> Adam Farley
> IBM Runtimes
>
> P.S. Tried making a small, stand-alone example and it failed to reproduce the 
> problem.
> Will keep trying, and I'll supply a further update in the event of a) results,
> or b) a response from the xlc guys.
>
>
> Volker Simonis  wrote on 21/11/2018 14:07:07:
>
> > From: Volker Simonis 
> > To: adam.far...@uk.ibm.com
> > Cc: Java Core Libs , "Stuefe,
> > Thomas" 
> > Date: 21/11/2018 14:07
> > Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> > using the xlc 13.1 compiler
> >
> > On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8  wrote:
> > >
> > > Hi Volker,
> > >
> > > The NativeImageBuffer.cpp changes are best explained by the full text of
> > > the referenced GitHub Pull Request, copied here for simplicity:
> > >
> > > -
> > > Define JNIEXPORT and JNIIMPORT for xlc version 13.1 or newer. Without 
> > > this,
> > > almost no symbols are exported from shared libraries due to use of
> > > -qvisibility=hidden as specified in make/lib/LibCommon.gmk. The symptoms
> > > are reported in eclipse/openj9#2468.
> > >
> > > Unfortunately, this encounters a bug in xlc: it fails to parse what seems
> > > to be reasonable code.
> >
> > Sorry, but I don't see how this answers my question.
> >
> > 1. Which "reasonable code" does xlc fails to parse. A stand-alone
> > example would be nice.
> >
> > 2. Have you reported this as bug to the xlc developers? What did they say?
> >
> > 3. "jdk_internal_jimage_NativeImageBuffer.h" doesn't seem to be
> > special. It's a plain, generated JNI header file as generated by
> > 'javah' or 'javac -h'. If XLC 13 has problems parsing it, there should
> > be much more places which need fixing. So what's special about
> > "jdk_internal_jimage_NativeImageBuffer.h".
> >
> > In the referenced pull request
> > (https://urldefense.proofpoint.com/v2/url?
> > u=https-3A__github.com_eclipse_openj9_issues_2468&d=DwIFaQ&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=P5m8KWUXJf-
> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=sgfFd6mB1EYM4nOM89rgFFzUyX7B21XbckIY7L0kUNU&s=TJ-4nr8ikZKImwDygirRTxLybsnQWBN71nEZCwZ59NQ&e=
> > ) I can only see linker
> > errors (and no compiler errors). The linker errors are for both
> > libjsig and libjava. They are related to the symbol ".sigaction" in
> > jsig.o and I don't see how this should be related to
> > NativeImageBuffer.cpp or "jdk_internal_jimage_NativeImageBuffer.h".
> > NativeImageBuffer.cpp is only used to create libjimage and not related
> > in any way to libjsig or libjava.
> >
> > It seems wired to do the change to N

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

[Adam Farley8]

Hi Volker,

1) Here is the "reasonable" code in the generated 
jdk_internal_jimage_NativeImageBuffer.h

--
/* DO NOT EDIT THIS FILE - it is machine generated */
#include 
/* Header for class jdk_internal_jimage_NativeImageBuffer */

#ifndef _Included_jdk_internal_jimage_NativeImageBuffer
#define _Included_jdk_internal_jimage_NativeImageBuffer
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class: jdk_internal_jimage_NativeImageBuffer
 * Method:getNativeMap
 * Signature: (Ljava/lang/String;)Ljava/nio/ByteBuffer;
 */
JNIEXPORT jobject JNICALL 
Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap
  (JNIEnv *, jclass, jstring);

#ifdef __cplusplus
}
#endif
#endif
--


2) I have not yet reported this as a bug to the xlc developers. I will 
contact 
them now.

3) I did some experimenting, and it seems that the NativeImageBuffer.cpp 
change 
is the only thing standing between us and a successful compilation on aix 
using 
xlc 13.1 (assuming you're using source that compiles on aix with xlc 
12.1). 

With that change (plus the jni_md change), the compilation completes.

Without that change (after you've added the jni_md change though), the 
build
will fail with this error message:

--
12:19:58 
"/workspace/build/aix-ppc64-normal-server-release/support/headers/java.base/jdk_internal_jimage_NativeImageBuffer.h",
 
line 15.27: 1540-0040 (S) The text 
"Java_jdk_internal_jimage_NativeImageBuffer_getNativeMap" is unexpected. 
"visibility" may be undeclared or ambiguous.
12:19:59 CoreLibraries.gmk:192: recipe for target 
'/workspace/build/aix-ppc64-normal-server-release/support/native/java.base/libjimage/NativeImageBuffer.o'
 
failed
--

Best Regards

Adam Farley 
IBM Runtimes

P.S. Tried making a small, stand-alone example and it failed to reproduce 
the problem. 
Will keep trying, and I'll supply a further update in the event of a) 
results, 
or b) a response from the xlc guys.


Volker Simonis  wrote on 21/11/2018 14:07:07:

> From: Volker Simonis 
> To: adam.far...@uk.ibm.com
> Cc: Java Core Libs , "Stuefe, 
> Thomas" 
> Date: 21/11/2018 14:07
> Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while 
> using the xlc 13.1 compiler
> 
> On Wed, Nov 21, 2018 at 1:46 PM Adam Farley8  
wrote:
> >
> > Hi Volker,
> >
> > The NativeImageBuffer.cpp changes are best explained by the full text 
of
> > the referenced GitHub Pull Request, copied here for simplicity:
> >
> > -
> > Define JNIEXPORT and JNIIMPORT for xlc version 13.1 or newer. Without 
this,
> > almost no symbols are exported from shared libraries due to use of
> > -qvisibility=hidden as specified in make/lib/LibCommon.gmk. The 
symptoms
> > are reported in eclipse/openj9#2468.
> >
> > Unfortunately, this encounters a bug in xlc: it fails to parse what 
seems
> > to be reasonable code.
> 
> Sorry, but I don't see how this answers my question.
> 
> 1. Which "reasonable code" does xlc fails to parse. A stand-alone
> example would be nice.
> 
> 2. Have you reported this as bug to the xlc developers? What did they 
say?
> 
> 3. "jdk_internal_jimage_NativeImageBuffer.h" doesn't seem to be
> special. It's a plain, generated JNI header file as generated by
> 'javah' or 'javac -h'. If XLC 13 has problems parsing it, there should
> be much more places which need fixing. So what's special about
> "jdk_internal_jimage_NativeImageBuffer.h".
> 
> In the referenced pull request
> (INVALID URI REMOVED
> 
u=https-3A__github.com_eclipse_openj9_issues_2468&d=DwIFaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=sgfFd6mB1EYM4nOM89rgFFzUyX7B21XbckIY7L0kUNU&s=TJ-4nr8ikZKImwDygirRTxLybsnQWBN71nEZCwZ59NQ&e=
> ) I can only see linker
> errors (and no compiler errors). The linker errors are for both
> libjsig and libjava. They are related to the symbol ".sigaction" in
> jsig.o and I don't see how this should be related to
> NativeImageBuffer.cpp or "jdk_internal_jimage_NativeImageBuffer.h".
> NativeImageBuffer.cpp is only used to create libjimage and not related
> in any way to libjsig or libjava.
> 
> It seems wired to do the change to NativeImageBuffer.cpp which you've
> proposed without understanding the real cause of the problem.
> 
> Regards,
> Volker
> 
> > A workaround is required in just one place:
> > src/java.base/share/native/libjimage/NativeImageBuffer.cpp.
> > -
> >
> > Best Regards
> >
> > Adam Farley
> > IBM Runtimes
> >
> >
> > Volker Simonis  wrote on 20/11/2018 
17:50:41:
> >
> > > From: Volker Simonis 
> > > To: "Stuefe, Thomas" 
> > > Cc: adam.far...@uk.ibm.com, Java Core Libs  d...@openjdk.java.net>
> > > Date: 20/11/2018 17:59
> > > Subject: Re: RFR: JDK-8214063: OpenJDK will not build on AIX while
> > > using the xlc 13.1 compiler
> 

Re: 8214195: Align stdout messages in test/jdk/java/math/BigInteger/PrimitiveConversionTests.java

[Lance Andersen]

Looks fine Brian

Happy Thanksgiving
> On Nov 21, 2018, at 5:43 PM, Brian Burkhalter  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8214195
> http://cr.openjdk.java.net/~bpb/8214195/webrev.00/
> 
> Print statements are different for float and double but should be the same.
> 
> Thanks,
> 
> Brian

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

[Alan Bateman]

On 22/11/2018 10:54, Nick Gasson wrote:

Have you looked at replacing the remaining usages of stat changed to
stat64 instead?

I've tried this just now and it also resolves the issue. I can
test on some more platforms and update the webrev if this is the
preferred solution?

I'd say this is preferred to adding compiler flags, yes. The code will
make it unambiguously clear that it's correct.

Here is the updated webrev that uses stat64:

http://cr.openjdk.java.net/~njian/8214077/webrev.1/


Can you fix the stat usages in TimeZonone_md.c too?

-Alan

RE: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

[Nick Gasson]

> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> > I've tried this just now and it also resolves the issue. I can
> > test on some more platforms and update the webrev if this is the
> > preferred solution?
> I'd say this is preferred to adding compiler flags, yes. The code will
> make it unambiguously clear that it's correct.

Here is the updated webrev that uses stat64:

http://cr.openjdk.java.net/~njian/8214077/webrev.1/

Thanks,
Nick

> -Original Message-
> From: Magnus Ihse Bursie 
> Sent: 21 November 2018 20:00
> To: Nick Gasson ; Alan Bateman
> ; build-dev ; core-
> libs-...@openjdk.java.net
> Cc: nd 
> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
> ARM32
> 
> On 2018-11-21 11:08, Nick Gasson wrote:
> 
> > Hi Alan,
> >
> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> > I've tried this just now and it also resolves the issue. I can
> > test on some more platforms and update the webrev if this is the
> > preferred solution?
> I'd say this is preferred to adding compiler flags, yes. The code will
> make it unambiguously clear that it's correct.
> 
> /Magnus
> >
> > Thanks,
> > Nick
> >
> >> -Original Message-
> >> From: Alan Bateman 
> >> Sent: Wednesday, November 21, 2018 4:55 PM
> >> To: Nick Gasson ; build-dev  >> d...@openjdk.java.net>; core-libs-dev@openjdk.java.net
> >> Cc: nd 
> >> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
> >> ARM32
> >>
> >> On 21/11/2018 02:46, Nick Gasson wrote:
> >>> Hi,
> >>>
> >>> Can someone please help me review this small makefile patch to
> >>> fix an issue with java.io.File::setLastModified on 32-bit
> >>> systems?
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8214077
> >>> http://cr.openjdk.java.net/~njian/8214077/webrev.0/
> >>>
> >>> If the file size is > 2GB so that the size won't fit in a signed
> >>> 32-bit off_t all stat() calls will fail with EOVERFLOW. This causes
> >>> the native method UnixFileSystem::setLastModifiedTime to fail as it
> >>> uses stat() to preserve the access time. It also causes other methods
> >>> like File::length and File::lastModified to return 0.
> >>>
> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> >>
> >> -Alan