June 2018 - core-libs-dev

The store for byte strings
by Florian Weimer 10 Jun '18

10 Jun '18

Lately I've been thinking about string representation. The world turned out not to be UCS-2 or UTF-16, after all, and we often have to deal with strings generally encoded as ASCII or UTF-8, but we aren't always encoded this way (and there might not even be a charset declaration, see the ELF spec). (a) byte[] with defensive copies. Internal storage is byte[], copy is made before returning it to the caller. Quite common across the JDK. (b) byte[] without defensive copies. Internal storage is byte[], and a reference is returned. In the past, this could be a security bug, and usually, it was adjusted to (a) when noticed. Without security requirements, this can be quite efficient, but there is ample potential for API misuse. (c) java.lang.String with ISO-8859-1 decoding/encoding. Sometimes done by reconfiguring the entire JVM to run with ISO-8859-1, usually so that it is possible to process malformed UTF-8. The advantage is that there is rich API support, including regular expressions, and good optimization. There is also language support for string literals. (d) java.lang.String with UTF-8 decoding/encoding and replacement. This seems to be very common, but is not completely accurate and can lead to subtle bugs (or completely non-processible data). Otherwise has the same advantages as (c). (e) Various variants of ByteBuffer. Have not seen this much in practice (outside binary file format parsers). In the past, it needed deep defensive copies on input for security (because there isn't an immutably backed ByteBuffer), and shallow copies for access. The ByteBuffer objects themselves are also quite heavy when they can't be optimized away. For that reason, probably most useful on interfaces, and not for storage. (f) Custom, immutable ByteString class. Quite common, but has cross-library interoperability issues, and a full complement of support (matching java.lang.String) is quite hard. (g) Something based on VarHandle. Haven't seen this yet. Probably not useful for storage. Anything that I have missed? Considering these choices, what is the expected direction on the JDK side for new code? Option (d) for things generally ASCII/UTF-8, and (b) for things of a more binary nature? What to do if the choice is difficult?

3 4

Review Request: 8204648: test/jdk/tools/launchers/SourceMode.java fails with long shebang line
by mandy chung 09 Jun '18

09 Jun '18

JDK-8204588 [1] fixed the test failure caused by long paths to the Java launcher in some test execution environments, causing the shebang line to overflow the underlying system limit of 128 characters. The test needs a small tweak to the max javaCmd length to reduce from 100 to 90 since the arguments passed to java command are more than 28 characters. This is a quick fix for the test failure. A better fix would be to compute the length of the entire shebang line in each test case and determine if it should be skipped. That can be done as a follow up fix. diff --git a/test/jdk/tools/launcher/SourceMode.java b/test/jdk/tools/launcher/SourceMode.java --- a/test/jdk/tools/launcher/SourceMode.java +++ b/test/jdk/tools/launcher/SourceMode.java @@ -71,7 +71,7 @@ // limit of 120 characters for a shebang line. Path p = cwd.relativize(cmd); shortJavaCmd = (p.toString().length() < cmd.toString().length()) ? p : cmd; - skipShebangTest = shortJavaCmd.toString().length() > 100; + skipShebangTest = shortJavaCmd.toString().length() > 90; } log = System.err; thanks Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/053700.html

2 2

Re: RFR: 8199871: Deprecate pack200 and unpack200 tools
by Henry Jen 09 Jun '18

09 Jun '18

I revised the webrev to have warning only executable name for unpack200 instead of full path on Windows, which I believe is what was intended all along, the test is also revised to take unpack200.exe on the Windows platform. The updated version is at http://cr.openjdk.java.net/~henryjen/jdk11/8199871/1/webrev/ Cheers, Henry > On Jun 8, 2018, at 6:56 PM, Henry Jen <henry.jen(a)oracle.com> wrote: > > Hi, > > Please review this webrev[1] in which we mark Pack200 related API and tools deprecate, and print a warning about tools to be remove in a future JDK release. To avoid interrupt existing tools depends on the output, an option is provided to suppress the warning message. > > The option name is following the convention of javah, not the GNU style as we should. The rationale is that this is a temporary option and an existing convention would make it more consistent for users. Anyhow, if we have a strong feeling this should be changed, we can do that. > > For jar tool, the normalize option use Pack200 is also deprecated, the suppress option only available to the new GNU style option mode. As if user need to provide the option, the command line change is necessary, so without compatible mode option should not be an issue. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk11/8199871/0/webrev/

1 0

RFR: JDK-8204588: Test failures after "Launch Single-File Source-Code Programs"
by Jonathan Gibbons 08 Jun '18

08 Jun '18

Please review two test fixes related to the source launcher feature. In one test, the fix is to use File.separator to construct "golden output" for comparison. In the other test, the failure was caused by excessively long paths to the Java launcher in some test execution environments, causing the shebang line to overflow the underlying system limit of 128 characters. The fix is to skip test cases when that occurs, as well as to augment the test with more tracing information to help diagnose failures on remote build and test systems. The tests are removed from the corresponding ProblemList files. JBS: https://bugs.openjdk.java.net/browse/JDK-8204588 Webrev: http://cr.openjdk.java.net/~jjg/8204588/webrev.00/index.html -- Jon

2 1

RFR 8204565 : (spec) Document java.{vm.}?specification.version system properties' relation to $FEATURE
by Brent Christian 08 Jun '18

08 Jun '18

Hi, Please review this doc-only change. From the bug report: 'With the integration of JEP 322 "Time-Based Release Versioning" into JDK 10, VERSION_FEATURE is used to set the value of the system properties "java.specification.version" [1] and "java.vm.specification.version" [2] (though the term "major" is still used in VM code, see JDK-8193719). We can update the System.getProperties() javadoc to be more specific about the value reported in these system properties.' Issue: https://bugs.openjdk.java.net/browse/JDK-8204565 Webrev: http://cr.openjdk.java.net/~bchristi/8204565/webrev/ Thanks, -Brent 1. http://hg.openjdk.java.net/jdk/jdk/rev/d2a837cf9ff1#l6.23 2. http://hg.openjdk.java.net/jdk/jdk/rev/d2a837cf9ff1#l15.17

2 4

RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically
by Magnus Ihse Bursie 08 Jun '18

08 Jun '18

This change needs some background information. I've been working on simplifying and streamlining the compilation of native libraries of the JDK. Previously, I introduced the SetupJdkLibrary function, and started to get a better control of compiler flags. This patch continues on both paths. The original intent of this change, which I naively thought was going to be much simpler than it turned out :-) was to separate the -I flags (location of header files) from other flags, and to generate these automatically, wherever possible. Since we have a standard way of locating native code, and most libraries just want to have an -I path to their own source base and the generated Java header, we should be able to provide this in SetupJdkLibrary. This turned out to be closely related to SetupJdkLibrary being able to discover the location of the SRC directories itself, using "convention over configuration" and assuming that the library "libfoo" for "java.module" would be located in java.module/*/native/libfoo. While this sounds simple in theory, when actually trying to implement this I of course ran into all the places where some special handling was indeed needed. So even if like 90% of all libraries were simple to get to build using automated discovery of source and header directories, the 10% that did not caused me much more headaches than I had anticipated. On the other hand, now that I've sorted out all those places, the few remaining odd solutions is clearly documented and not just something that "just happens" due to strange configurations. One file deserves mentioning specifically: Awt2dLibraries.gmk. The java.desktop libraries are unfortunately quite entangled with each other, and do not readily follow the patterns that are used elsewhere in the code base. So it might just look like the file has just gone from one state of messiness, to another, which would hardly be an improvement. :-( I would still argue that the new messiness is better: It is now much clearer in what ways the libraries diverge from our standard assumption, and what course of action needs to be taken to minimize these differences. (Which is something I believe should be done -- these issues are not just cosmetic but is the root of most of the issues we always see for these libraries, when upgrading compilers, etc.) During this change, I noticed that not all native libraries include the proper generated header file. This is a dangerous coding practice, since a change in the Java part of the interface might not get picked up properly in the native part. I've added the missing includes that I've detected, and due to these changes, I'm also including the component teams in what is really only a build change. As can be seen for jdk.crypto.mscapi; there had indeed been changes that needed correcting. Since this is (basically) a pure build change, my gold standard here has been the build compare script. In essence, the build output prior to my change and with this change are 100% identical. In truth, this is a bit too strong a claim. A few changes has occurred, but none of them should matter. Here's a breakdown of the compare.sh results: * Windows-x64: No differences at all. * Solaris: Two libraries are reported to differ: libsaproc.so and libfontmanager.so, both with a disass diff on ~700 bytes. Analyzing this, I found that the object files used to link these two libraries has no disass differences. They have a slight binary difference and a difference in size, due to the include paths being different (and this is stored in the .o file, which makes it different). Somehow this apparently triggers the linker to generate a slightly different code in a few places, using a different register or so. (Weird...) * MacOS: Two libraries are reported to differ: libjava.dylib and libmlib_image.dylib, both of them just reported as a binary diff (no symbol, disass or fulldump differences). This is not really unsuspected, but I analyzed it anyway. I found that for libjava.dylib, a single .o file was different. This one was actually picked up from closed sources, and are not really relevant for OpenJDK. Anyway, the reason for the difference was the same as for the Solaris libs; the include paths had changes, which caused a binary diff. For libmlib_image.dylib, the link order had changed causing the noted binary difference. * Linux: On linux, the compare script noted differences for libextnet, libjava, libmlib_image, libprefs, libsaproc, libsplashscreen and libsunec. The differences for libextnet, libprefs, libsplashscreen and libsunec turned out to be caused by the added #include of the generated Java headers. This caused binary differences (reasonably), and for some odd reason also a symbol difference in java_awt_SplashScreen.o (clazz.10057 and mid.10058 were replaced by clazz.10015 and mid.10016). I can't claim to understand this, but I'm assuming it's some kind of generated code. libsaproc and libjava changes was caused by closed source changes, and is therefore not relevant to OpenJDK. For libmlib_image.dylib, the link order had changed causing the noted binary difference, as on MacOS. Bug: https://bugs.openjdk.java.net/browse/JDK-8204572 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8204572-autodetect-SRC-and-headers-dir… /Magnus

2 3

[11] RFR: 8202088: Japanese new era implementation
by Naoto Sato 08 Jun '18

08 Jun '18

Hi, Please review the changes to the subject issue: https://bugs.openjdk.java.net/browse/JDK-8202088 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8202088/webrev.01/ This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review: https://bugs.openjdk.java.net/browse/JDK-8202336 Naoto

5 8

RFR JDK-8204229: Formatter and String.format ignore the width with the percent modifier (%5%)
by Xueming Shen 08 Jun '18

08 Jun '18

Hi, Please help review the change for JDK-8204229. It appears to be a overlook in the implementation. We do have a method print(String, Locale) that adjust the "padding spaces" issue: https://bugs.openjdk.java.net/browse/JDK-8204229 webrev: http://cr.openjdk.java.net/~sherman/8204229/webrev Thanks, Sherman

2 1

[RFR] 8204539: improve error messages in matchJavaTZ [windows]
by Baesken, Matthias 08 Jun '18

08 Jun '18

Hi, could you please review this small change that improves the error messages in matchJavaTZ . A reason of the failure is added to the message , and also the offset where the error happened . Bug : https://bugs.openjdk.java.net/browse/JDK-8204539 Webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8204539/ Thanks, Matthias

4 9

RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
by Ichiroh Takiguchi 08 Jun '18

08 Jun '18

Hello. Could you review it ? Bug: https://bugs.openjdk.java.net/browse/JDK-8204541 Change: http://cr.openjdk.java.net/~clanger/webrevs/8204541.0/ Thanks, Ichiroh Takiguchi IBM Japan, Ltd. -------- Original Message -------- Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Date: 2018-06-07 20:43 From: "Langer, Christoph" <christoph.langer(a)sap.com> To: Ichiroh Takiguchi <takiguc(a)linux.vnet.ibm.com> Cc: "'build-dev(a)openjdk.java.net'" <build-dev(a)openjdk.java.net>, "ppc-aix-port-dev(a)openjdk.java.net" <ppc-aix-port-dev(a)openjdk.java.net>, "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net>, "Lindenmaier, Goetz" <goetz.lindenmaier(a)sap.com>, "Baesken, Matthias" <matthias.baesken(a)sap.com> Hi Ichiroh, your proposal seems to make sense. I have created a bug for this: https://bugs.openjdk.java.net/browse/JDK-8204541 Can you please generate a webrev (referencing this bug, -c option of webrev.ksh) and mail it over to me. Then I'll upload it and you can post an official RFR mail. Best regards Christoph > -----Original Message----- > From: Ichiroh Takiguchi [mailto:takiguc@linux.vnet.ibm.com] > Sent: Dienstag, 5. Juni 2018 08:59 > To: Baesken, Matthias <matthias.baesken(a)sap.com> > Cc: Langer, Christoph <christoph.langer(a)sap.com>; 'build- > dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > Goetz <goetz.lindenmaier(a)sap.com> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hello Matthias and Christoph. > Thank you for your explanations. > > I did not have enough knowledge about "visibility". > > I created following patches. > > ================================ > diff -r 02934b0d661b > src/java.base/share/native/libjimage/NativeImageBuffer.cpp > --- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp Wed > May > 30 14:46:28 2018 +0200 > +++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp Tue > Jun > 05 12:10:41 2018 +0900 > @@ -39,7 +39,9 @@ > #include "imageFile.hpp" > #include "inttypes.hpp" > #include "jimage.hpp" > +#if !defined(_AIX) > #include "osSupport.hpp" > +#endif > > #include "jdk_internal_jimage_NativeImageBuffer.h" > > diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h > --- a/src/java.base/unix/native/include/jni_md.h Wed May 30 14:46:28 > 2018 +0200 > +++ b/src/java.base/unix/native/include/jni_md.h Tue Jun 05 12:10:41 > 2018 +0900 > @@ -29,7 +29,8 @@ > #ifndef __has_attribute > #define __has_attribute(x) 0 > #endif > -#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) > +#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && > (__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \ > + || (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01))) > #ifdef ARM > #define JNIEXPORT > __attribute__((externally_visible,visibility("default"))) > #define JNIIMPORT > __attribute__((externally_visible,visibility("default"))) > ================================ > > If "osSupport.hpp" was included, XLC++ compiler complained. > I could not understand, which part was invalid... > I'm not sure, "osSupport.hpp" is really required on > NativeImageBuffer.cpp or not... > > I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. > [1] > 0xD01 means 13.1 by hexadecimal. > > I checked symbol table by "dump -Tv -X64". [2] > It seemed it was fine, some symbols were hidden. > > Does someone review my code? > > [1] > https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.i > bm.xlc1313.aix.doc/compiler_ref/xlmacros.html > [2] > https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > visibility/index.html > > On 2018-06-01 21:12, Baesken, Matthias wrote: > > Hi , my change 8202322 just handled the fact that the > > visibility - flags are not supported with xlc 12.1 , so setting > > them generated a TON of compile - time warnings . > > > > The introduction of the "-qvisibility=hidden" came with the > > mapfile removal changes : > > > > 8200358: Remove mapfiles for JDK executables > > http://hg.openjdk.java.net/jdk/jdk/rev/210cf224b690 > > > > 8200178: Remove mapfiles for JDK native libraries > > http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5 > > > > I guess it might need further testing+adjustments to make the > > "visibility hiding" work nicely with XLC13 , but currently we > > build only with XLC12 . > > > > As a workaround you might want to remove the "-qvisibility=hidden" > > setting for XLC 13 as well , like I did for XLC12 with the change > > 8202322 . > > > > > > Best regards, Matthias > > > > > > > > > >> -----Original Message----- > >> From: Langer, Christoph > >> Sent: Freitag, 1. Juni 2018 10:57 > >> To: Ichiroh Takiguchi <takiguc(a)linux.vnet.ibm.com> > >> Cc: Baesken, Matthias <matthias.baesken(a)sap.com>; 'build- > >> dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > >> dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > >> Goetz <goetz.lindenmaier(a)sap.com> > >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support > >> on xlc 12.1 > >> > >> Hi Ichiroh, > >> > >> we do not use the XLC 13 compiler on AIX yet here at SAP and I believe > >> nobody of my colleagues has played with it yet. So you are on a new > >> playground here 😊 > >> > >> However, I believe the idea in OpenJDK with the abolition of map files > >> is that > >> symbols should be invisible externally unless they are declared > >> exported, > >> e.g. JNIEXPORT. So I would think "-qvisibility=hidden" should be the > >> correct > >> default and whatever JNIEXPORT expands to should contain the right > >> attributes to get that symbol visible. > >> > >> Can you check if either my assumption is completely wrong, JNIEXPORT > >> does > >> not expand to the right thing, XLC 13 has a bug or maybe just sume > >> specific > >> required symbols are not declared correctly? > >> > >> Best regards > >> Christoph > >> > >> > -----Original Message----- > >> > From: Ichiroh Takiguchi [mailto:takiguc@linux.vnet.ibm.com] > >> > Sent: Donnerstag, 31. Mai 2018 09:55 > >> > To: Langer, Christoph <christoph.langer(a)sap.com> > >> > Cc: Baesken, Matthias <matthias.baesken(a)sap.com>; 'build- > >> > dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; ppc-aix-port- > >> > dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net; Lindenmaier, > >> > Goetz <goetz.lindenmaier(a)sap.com> > >> > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > >> > > >> > Hello. > >> > 8202322 was integrated into jdk-11+15. > >> > I'm using XLC 13.1.3 on AIX 7.1.4. > >> > Build was failed because of "-qvisibility=hidden" on > >> > make/lib/LibCommon.gmk. > >> > According to "XL C/C++ for AIX 13.1.3" documentation [1], > >> > "-qvisibility=hidden" cannot create shared libraries entry points. > >> > For example, libverify.so was there, but entry points were not resolved > >> > by "-lverify" option. > >> > I think it should be "-qvisibility=default" (I tried, it worked) > >> > or "-qvisibility=protected" (I had not tried) ? > >> > I'm not familiar with -qvisibility option, but I'd like to find out > >> > right way. > >> > > >> > [1] > >> > > >> > https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm. > >> > xlcpp1313.aix.doc/compiler_ref/opt_visibility.html > >> > > >> > On 2018-05-16 16:08, Langer, Christoph wrote: > >> > > Hi Matthias, > >> > > > >> > > yes, reviewed. > >> > > > >> > > Best regards > >> > > Christoph > >> > > > >> > > From: Baesken, Matthias > >> > > Sent: Mittwoch, 16. Mai 2018 09:06 > >> > > To: Langer, Christoph <christoph.langer(a)sap.com>; > >> > > 'build-dev(a)openjdk.java.net' <build-dev(a)openjdk.java.net>; > >> > > ppc-aix-port-dev(a)openjdk.java.net; core-libs-dev(a)openjdk.java.net > >> > > Cc: Lindenmaier, Goetz <goetz.lindenmaier(a)sap.com> > >> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > >> > > xlc 12.1 > >> > > > >> > > Hi Christoph can I add you as second reviewer (other reviewer was > >> > > Erik Joelsson) can push the change ? > >> > > > >> > > Best regards, Matthias > >> > > > >> > > > >> > > > >> > > From: Langer, Christoph > >> > > Sent: Donnerstag, 26. April 2018 16:38 > >> > > To: Baesken, Matthias > >> > > <matthias.baesken(a)sap.com<mailto:matthias.baesken@sap.com>>; > >> > > 'build-dev(a)openjdk.java.net' > >> > > <build-dev(a)openjdk.java.net<mailto:build- > dev(a)openjdk.java.net>>; > >> > > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > >> > dev(a)openjdk.java.net>; > >> > > core-libs-dev(a)openjdk.java.net<mailto:core-libs- > >> dev(a)openjdk.java.net> > >> > > Cc: Simonis, Volker > >> > > <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > >> > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > >> > > xlc 12.1 > >> > > > >> > > Hi Matthias, > >> > > > >> > > to me the change in principal looks good. > >> > > > >> > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. > >> > > extract major number before the first dot, then compare numerically) > - > >> > > but maybe it is too complicated and the current single version > compare > >> > > suits our needs ? > >> > > > >> > > Best regards > >> > > Christoph > >> > > > >> > > From: Baesken, Matthias > >> > > Sent: Donnerstag, 26. April 2018 16:14 > >> > > To: 'build-dev(a)openjdk.java.net' > >> > > <build-dev(a)openjdk.java.net<mailto:build- > dev(a)openjdk.java.net>>; > >> > > ppc-aix-port-dev(a)openjdk.java.net<mailto:ppc-aix-port- > >> > dev(a)openjdk.java.net>; > >> > > core-libs-dev(a)openjdk.java.net<mailto:core-libs- > >> dev(a)openjdk.java.net> > >> > > Cc: Langer, Christoph > >> > > <christoph.langer(a)sap.com<mailto:christoph.langer@sap.com>>; > >> Simonis, > >> > > Volker <volker.simonis(a)sap.com<mailto:volker.simonis@sap.com>> > >> > > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > >> > > 12.1 > >> > > > >> > > Hello , could you please review this small adjustment to the symbol > >> > > visibility compilation settings on AIX ? > >> > > Currently we use XLC 12.1 to compile JDK on AIX . > >> > > > >> > > However XLC 12.1 does not support the "-qvisibility=hidden" > >> > > setting currently set on AIX. > >> > > It was introduced with XLC 13.1 . Christoph found some info about it > >> > > here : > >> > > > >> > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol- > >> > visibility-part2/index.html > >> > > > >> > > Setting it only generates hundreds of warnings in the build log , > >> > > warnings look like this : > >> > > XlC12.1 > >> > > > >> > > bash-4.4$ xlC -qversion > >> > > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > >> > > Version: 12.01.0000.0019 > >> > > > >> > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> > > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > >> > > of valid options. > >> > > > >> > > Compare to XLC13.1 > >> > > > >> > > bash-3.00$ xlC -qversion > >> > > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > >> > > Version: 13.01.0000.0008 > >> > > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > >> > > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > >> > > > >> > > > >> > > So it is better to avoid setting these flags when using xlc12.1 . > >> > > Please review : > >> > > > >> > > Bug : > >> > > > >> > > https://bugs.openjdk.java.net/browse/JDK-8202322 > >> > > > >> > > Change : > >> > > > >> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > >> > > > >> > > > >> > > Best regards, Matthias

2 3