From volker.simonis at gmail.com  Sun Apr  1 14:39:20 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sun, 01 Apr 2018 14:39:20 +0000
Subject: Problem building openjdk using cygwin
In-Reply-To: <CAPGOCT8vKhcfF+9M9pRaY7dmF-GjGQWjOtvye3bS3zgnbfYbQA@mail.gmail.com>
References: <CAPGOCT-hpsL8a_PxjVjKwWjD9GUiptyP7ZTmP69uCdwKiwOJ1A@mail.gmail.com>
 <CA+3eh103eAynoEakhfnxsU5ZLV29XPDR1fpHY=gqg5EUy+z04A@mail.gmail.com>
 <CAPGOCT8vKhcfF+9M9pRaY7dmF-GjGQWjOtvye3bS3zgnbfYbQA@mail.gmail.com>
Message-ID: <CA+3eh11GW_cAqBnuiUui_L-0TdLzgsMrfMN0CnmwEAMyhaUa-w@mail.gmail.com>

Hi Alireza,

sorry if my answer (and especially the link which I provided) have been
unclear. You don?t have to create any junctions. You just have to enable
short (i.e. ?8.3? filenames) for the drive /directory where you have
installed Visual Studio. Afterwards you must copy ?microsoft visual studio?
to a temporary directory and finally copy it back to ?microsoft visual
studio?. This should create a short name for that directpry.

You can find more information about how to enable/disable short filenames
here:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/ff621566(v=ws.11)

https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions

Regards,
Volker


Alireza Mohamadi <dangersd at gmail.com> schrieb am Sa. 31. M?rz 2018 um 09:50:

> Hi Volker, gratitude for answering my question.
> After reading Q&A link you provided I realized how to make junctions but I
> don't know which source should be attached to the target?
> As you've mentioned `:/cygdrive/c/progra~2/microsoft: No such file or
> directory` means there are no links available for "C:\Program Files
> (x86)\Microsoft Visual Studio",
> so I tried
> ```
> C:\WINDOWS\system32>mklink /j "C:\progra~2\microsoft~7" "C:\Program Files
> (x86)\Microsoft Visual Studio"
> Junction created for C:\progra~2\microsoft~7 <<===>> C:\Program Files
> (x86)\Microsoft Visual Studio
> ```
> but it seems not working because I get the same error. Can you give some
> tips please? Sorry if I'm newbie, I'm just interested in some JEPs and want
> to test them in a project to see if I can deploy it later.
> Many thanks.
>
> On Thu, Mar 29, 2018 at 11:55 AM, Volker Simonis <volker.simonis at gmail.com
> > wrote:
>
>> Hi Alireza,
>>
>> it seems you don?t have short file names enabled for the ?Program Files?
>> directory. Notice that you have short file names enabled for ?c:\? (i.e.
>> you have ?progra~2?).
>>
>> You have to first enable short file names for the ?Program Files?
>> directory (see for example
>>
>> https://superuser.com/questions/681330/how-to-force-short-name-8dot3-generation
>> ).
>>
>> Afterwards you must copy ?microsoft visual studio? to a temporary
>> directory and finally copy it back to ?microsoft visual studio?. This
>> should create a short name for that directory.
>>
>> Regards,
>> Volker
>>
>> Alireza Mohamadi <dangersd at gmail.com> schrieb am Do. 29. M?rz 2018 um
>> 06:08:
>>
>>> Hi. I wanted to build OpenJDK in windows using cygwin, and I set VC
>>> compiler path, but due to whitespaces in the path I can't build, with the
>>> following error:
>>> ```
>>> configure: Rewriting CC to "/cygdrive/c/progra~2/microsoft visual
>>> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl"
>>> checking resolved symbolic links for CC... no symlink
>>> configure: The C compiler (located as /cygdrive/c/progra~2/microsoft
>>> visual
>>> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl) does
>>> not seem to be the required microsoft compiler.configure: error: A
>>> microsoft compiler is reconfigure: The result from running it was:
>>> "/home/SuNova/jdk/build/.configure-support/generated-configure.sh: line
>>> 35050: /cygdrive/c/progra~2/microsoft: No such file or directory"
>>> configure exiting with result code 1
>>> ```
>>> Well it's not in my hands to set compiler path while installing VS2017
>>> and
>>> it does this automatically, so what can I do in this case?
>>>
>>>
>>> --
>>> Sometimes the best results can be achieved in the worst conditions
>>> Wish you the bests :)
>>> Alireza
>>>
>>
>
>
> --
> Sometimes the best results can be achieved in the worst conditions
> Wish you the bests :)
> Alireza
>


From abhi.saha at oracle.com  Mon Apr  2 18:58:09 2018
From: abhi.saha at oracle.com (Abhijit Saha)
Date: Mon, 2 Apr 2018 11:58:09 -0700
Subject: RFR: 8200586: Update JDK11 release date to 2018-09-25
Message-ID: <c9e41a26-4c0e-cee4-6d53-aaa62369a38c@oracle.com>

Release date for jdk11 seems incorrectly shown as '2018-09-18' while
it should be '2018-09-25'. Need to update the configuration accordingly.

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

Change:

--- a/make/autoconf/version-numbers
+++ b/make/autoconf/version-numbers
@@ -29,7 +29,7 @@
  DEFAULT_VERSION_INTERIM=0
  DEFAULT_VERSION_UPDATE=0
  DEFAULT_VERSION_PATCH=0
-DEFAULT_VERSION_DATE=2018-09-18
+DEFAULT_VERSION_DATE=2018-09-25
  DEFAULT_VERSION_CLASSFILE_MAJOR=55  # "`$EXPR $DEFAULT_VERSION_FEATURE 
+ 44`"
  DEFAULT_VERSION_CLASSFILE_MINOR=0
  DEFAULT_ACCEPTABLE_BOOT_VERSIONS="9 10 11"


Thanks,
Abhijit


From dangersd at gmail.com  Mon Apr  2 20:16:44 2018
From: dangersd at gmail.com (Alireza Mohamadi)
Date: Tue, 3 Apr 2018 00:46:44 +0430
Subject: Problem building openjdk using cygwin
In-Reply-To: <CA+3eh11GW_cAqBnuiUui_L-0TdLzgsMrfMN0CnmwEAMyhaUa-w@mail.gmail.com>
References: <CAPGOCT-hpsL8a_PxjVjKwWjD9GUiptyP7ZTmP69uCdwKiwOJ1A@mail.gmail.com>
 <CA+3eh103eAynoEakhfnxsU5ZLV29XPDR1fpHY=gqg5EUy+z04A@mail.gmail.com>
 <CAPGOCT8vKhcfF+9M9pRaY7dmF-GjGQWjOtvye3bS3zgnbfYbQA@mail.gmail.com>
 <CA+3eh11GW_cAqBnuiUui_L-0TdLzgsMrfMN0CnmwEAMyhaUa-w@mail.gmail.com>
Message-ID: <CAPGOCT-Z6Hk=LROptwkXd3GRLyNeTeWURCXmzsFuYf9rB6sSYQ@mail.gmail.com>

Thanks Volker you are awesome!
After reading resources you've mentioned and doing some research I became
able to set short name for "Micrisoft Visual Studio" directory using:
`fsutil file setshortname "C:\Program Files (x86)\Microsoft Visual Studio"
msvs`, without even enabling 8dot3name globally. Now I'm building openjdk.
Gratitude. Keep on the great job :)

On Sun, Apr 1, 2018 at 7:09 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Alireza,
>
> sorry if my answer (and especially the link which I provided) have been
> unclear. You don?t have to create any junctions. You just have to enable
> short (i.e. ?8.3? filenames) for the drive /directory where you have
> installed Visual Studio. Afterwards you must copy ?microsoft visual studio?
> to a temporary directory and finally copy it back to ?microsoft visual
> studio?. This should create a short name for that directpry.
>
> You can find more information about how to enable/disable short filenames
> here:
>
> https://docs.microsoft.com/en-us/previous-versions/windows/
> it-pro/windows-server-2012-R2-and-2012/ff621566(v=ws.11)
>
> https://support.microsoft.com/en-us/help/121007/how-to-
> disable-8-3-file-name-creation-on-ntfs-partitions
>
> Regards,
> Volker
>
>
> Alireza Mohamadi <dangersd at gmail.com> schrieb am Sa. 31. M?rz 2018 um
> 09:50:
>
>> Hi Volker, gratitude for answering my question.
>> After reading Q&A link you provided I realized how to make junctions but
>> I don't know which source should be attached to the target?
>> As you've mentioned `:/cygdrive/c/progra~2/microsoft: No such file or
>> directory` means there are no links available for "C:\Program Files
>> (x86)\Microsoft Visual Studio",
>> so I tried
>> ```
>> C:\WINDOWS\system32>mklink /j "C:\progra~2\microsoft~7" "C:\Program Files
>> (x86)\Microsoft Visual Studio"
>> Junction created for C:\progra~2\microsoft~7 <<===>> C:\Program Files
>> (x86)\Microsoft Visual Studio
>> ```
>> but it seems not working because I get the same error. Can you give some
>> tips please? Sorry if I'm newbie, I'm just interested in some JEPs and want
>> to test them in a project to see if I can deploy it later.
>> Many thanks.
>>
>> On Thu, Mar 29, 2018 at 11:55 AM, Volker Simonis <
>> volker.simonis at gmail.com> wrote:
>>
>>> Hi Alireza,
>>>
>>> it seems you don?t have short file names enabled for the ?Program Files?
>>> directory. Notice that you have short file names enabled for ?c:\? (i.e.
>>> you have ?progra~2?).
>>>
>>> You have to first enable short file names for the ?Program Files?
>>> directory (see for example
>>> https://superuser.com/questions/681330/how-to-force-
>>> short-name-8dot3-generation).
>>>
>>> Afterwards you must copy ?microsoft visual studio? to a temporary
>>> directory and finally copy it back to ?microsoft visual studio?. This
>>> should create a short name for that directory.
>>>
>>> Regards,
>>> Volker
>>>
>>> Alireza Mohamadi <dangersd at gmail.com> schrieb am Do. 29. M?rz 2018 um
>>> 06:08:
>>>
>>>> Hi. I wanted to build OpenJDK in windows using cygwin, and I set VC
>>>> compiler path, but due to whitespaces in the path I can't build, with
>>>> the
>>>> following error:
>>>> ```
>>>> configure: Rewriting CC to "/cygdrive/c/progra~2/microsoft visual
>>>> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl"
>>>> checking resolved symbolic links for CC... no symlink
>>>> configure: The C compiler (located as /cygdrive/c/progra~2/microsoft
>>>> visual
>>>> studio/2017/community/vc/tools/msvc/14.13.26128/bin/hostx86/x64/cl)
>>>> does
>>>> not seem to be the required microsoft compiler.configure: error: A
>>>> microsoft compiler is reconfigure: The result from running it was:
>>>> "/home/SuNova/jdk/build/.configure-support/generated-configure.sh: line
>>>> 35050: /cygdrive/c/progra~2/microsoft: No such file or directory"
>>>> configure exiting with result code 1
>>>> ```
>>>> Well it's not in my hands to set compiler path while installing VS2017
>>>> and
>>>> it does this automatically, so what can I do in this case?
>>>>
>>>>
>>>> --
>>>> Sometimes the best results can be achieved in the worst conditions
>>>> Wish you the bests :)
>>>> Alireza
>>>>
>>>
>>
>>
>> --
>> Sometimes the best results can be achieved in the worst conditions
>> Wish you the bests :)
>> Alireza
>>
>


-- 
Sometimes the best results can be achieved in the worst conditions
Wish you the bests :)
Alireza


From christian.tornqvist at oracle.com  Mon Apr  2 20:04:19 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 2 Apr 2018 16:04:19 -0400
Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests
In-Reply-To: <5ABDA3C0.8050902@oracle.com>
References: <5ABAF57B.6050005@oracle.com>
 <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com>
 <e3a70729-b8fe-9b17-c952-f5c09ff82964@oracle.com>
 <bdec2817-7e6d-5206-392e-34f5836886b1@oracle.com>
 <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com>
 <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com>
 <5ABDA3C0.8050902@oracle.com>
Message-ID: <B8E6462C-CF0F-4EEE-A189-80C8925A4677@oracle.com>

Hi Misha,

This looks good, thanks for doing this.

Thanks,
Christia

> On Mar 29, 2018, at 10:41 04PM, Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com> wrote:
> 
> While testing I discovered build errors on Mac and Solaris. The following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm" was added to a Linux-only block. I have updated the make file to add this for any platform w/o conditions; the " exesigtest.c" is excluded from Windows anyway down below in the make file. I am not 100% sure this is the correct way to modify the make file; if not please advise the correct way.
> With this fix all 4 builds pass.
> 
> Here is the updated webrev:
>    http://cr.openjdk.java.net/~mseledtsov/8200126.02.open/index.html
> 
> Thank you,
> Misha
> 
> 
> On 3/29/18, 4:00 PM, mikhailo wrote:
>> I have addressed feedback from Christian, David and Magnus. Here is the updated webrev:
>> 
>> http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html
>> 
>> 
>> I have also confirmed that output from exesigtest.c printf() is logged into .jtr files.
>> 
>>      Grepped for "signal", I can see the output such as:
>>          TestSigxfsz.jtr:SIGXFSZ: signal handler using function 'sigset' has been set
>>          TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has been processed
>>          TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully
>>          TestSigxfsz.jtr:SIGXFSZ: signal has been received
>>      Also can see other output from the printf, such as all initVM logs.
>> 
>> 
>> Thank you,
>> Misha
>> 
>> On 03/29/2018 02:49 PM, mikhailo wrote:
>>> Magnus,
>>> 
>>> Thank you for advice. I have updated the makefile accordingly. Will post updated webrev shortly.
>>> 
>>> 
>>> Misha
>>> 
>>> 
>>> On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote:
>>>> Yes, you seem to have based this off an old version of JtregNativeHotspot.gmk.
>>>> 
>>>> If you update the file I think you see how you should do it, but I'll give you some help:
>>>> 
>>>> ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>  BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT
>>>>  BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c
>>>> endif
>>> 
>> 



From tim.bell at oracle.com  Mon Apr  2 23:38:39 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 02 Apr 2018 16:38:39 -0700
Subject: RFR: 8200586: Update JDK11 release date to 2018-09-25
In-Reply-To: <c9e41a26-4c0e-cee4-6d53-aaa62369a38c@oracle.com>
References: <c9e41a26-4c0e-cee4-6d53-aaa62369a38c@oracle.com>
Message-ID: <5AC2BEFF.7020805@oracle.com>

Abhijit:

> Release date for jdk11 seems incorrectly shown as '2018-09-18' while
> it should be '2018-09-25'. Need to update the configuration accordingly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200586
>
> Change:
>
> --- a/make/autoconf/version-numbers
> +++ b/make/autoconf/version-numbers
> @@ -29,7 +29,7 @@
>   DEFAULT_VERSION_INTERIM=0
>   DEFAULT_VERSION_UPDATE=0
>   DEFAULT_VERSION_PATCH=0
> -DEFAULT_VERSION_DATE=2018-09-18
> +DEFAULT_VERSION_DATE=2018-09-25
>   DEFAULT_VERSION_CLASSFILE_MAJOR=55  # "`$EXPR $DEFAULT_VERSION_FEATURE
> + 44`"
>   DEFAULT_VERSION_CLASSFILE_MINOR=0
>   DEFAULT_ACCEPTABLE_BOOT_VERSIONS="9 10 11"

Looks good.

Tim




From david.holmes at oracle.com  Tue Apr  3 00:45:11 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Apr 2018 10:45:11 +1000
Subject: RFR: 8200586: Update JDK11 release date to 2018-09-25
In-Reply-To: <c9e41a26-4c0e-cee4-6d53-aaa62369a38c@oracle.com>
References: <c9e41a26-4c0e-cee4-6d53-aaa62369a38c@oracle.com>
Message-ID: <63c670b5-8be9-32b1-90ed-e2a2e0eaef2f@oracle.com>

Looks fine.

Thanks,
David

On 3/04/2018 4:58 AM, Abhijit Saha wrote:
> Release date for jdk11 seems incorrectly shown as '2018-09-18' while
> it should be '2018-09-25'. Need to update the configuration accordingly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200586
> 
> Change:
> 
> --- a/make/autoconf/version-numbers
> +++ b/make/autoconf/version-numbers
> @@ -29,7 +29,7 @@
>  ?DEFAULT_VERSION_INTERIM=0
>  ?DEFAULT_VERSION_UPDATE=0
>  ?DEFAULT_VERSION_PATCH=0
> -DEFAULT_VERSION_DATE=2018-09-18
> +DEFAULT_VERSION_DATE=2018-09-25
>  ?DEFAULT_VERSION_CLASSFILE_MAJOR=55? # "`$EXPR $DEFAULT_VERSION_FEATURE 
> + 44`"
>  ?DEFAULT_VERSION_CLASSFILE_MINOR=0
>  ?DEFAULT_ACCEPTABLE_BOOT_VERSIONS="9 10 11"
> 
> 
> Thanks,
> Abhijit


From magnus.ihse.bursie at oracle.com  Tue Apr  3 09:48:28 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 11:48:28 +0200
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <c65a22a5-07c2-0e40-5c66-431838694b91@oracle.com>
References: <CAA-vtUxX_uAPwwMBdzFDuGh-2N01eCrt3O=L5Mva5ZLwPivOLg@mail.gmail.com>
 <CAA-vtUyugMfWjRr4tgR2ucCJrcqyVh1nqVfh5MC-V9SeasNO=w@mail.gmail.com>
 <c65a22a5-07c2-0e40-5c66-431838694b91@oracle.com>
Message-ID: <d882ef04-e570-a549-a6bd-be66ed30a9b2@oracle.com>


On 2018-03-27 18:44, Phil Race wrote:
> As I said I prefer the make file change, since this is a change to an 
> upstream library.
Newtons fourth law: For every reviewer, there's an equal and opposite 
reviewer. :)

Here I am, advocating a source code fix. As Thomas says, the compiler 
complaint seems reasonable, and disabling it might cause us to miss 
other future errors.

Why can't we push the source code fix, and also submit it upstream?

/Magnus

> I've looked at jpeg-9c and it still looks identical to what we have in 
> 6b, so this code
> seems to have stood the test of time. I'm also unclear why the 
> compiler would
> complain about that and not the one a few lines later
>
>   819   while (bits[i] == 0)          /* find largest codelength still in use */
>   820     i--;
>
> A push to jchuff.c will get blown away if/when we upgrade.
> A tool-chain specific fix in the makefile with an appropriate comment is more targeted.
>
> -phil.
>
> On 03/27/2018 05:44 AM, Thomas St?fe wrote:
>> Hi all,
>>
>> just a friendly reminder. I would like to push this tiny fix because 
>> tripping over this on our linux s390x builds is annoying (yes, we can 
>> maintain patch queues, but this is a constant error source).
>>
>> I will wait for 24 more hours until a reaction. If no serious 
>> objections are forcoming, I want to push it (tier1 tests ran thru, 
>> and me and Christoph langer are both Reviewers).
>>
>> Thanks! Thomas
>>
>> On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe 
>> <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>     Hi all,
>>
>>     may I please have another review for this really trivial change.
>>     It fixes a gcc warning on s390 and ppc. Also, it is probably a
>>     good idea to fix this.
>>
>>     bug: https://bugs.openjdk.java.net/browse/JDK-8200052
>>     <https://bugs.openjdk.java.net/browse/JDK-8200052>
>>     webrev:
>>     http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/
>>     <http://cr.openjdk.java.net/%7Estuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/>
>>
>>     This was contributed by Adam Farley at IBM.
>>
>>     I already reviewed this. I also test-built on zlinux and it works.
>>
>>     Thanks, Thomas
>>
>>
>



From adam.farley at uk.ibm.com  Tue Apr  3 12:07:22 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 3 Apr 2018 13:07:22 +0100
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <d882ef04-e570-a549-a6bd-be66ed30a9b2@oracle.com>
References: <CAA-vtUxX_uAPwwMBdzFDuGh-2N01eCrt3O=L5Mva5ZLwPivOLg@mail.gmail.com>
 <CAA-vtUyugMfWjRr4tgR2ucCJrcqyVh1nqVfh5MC-V9SeasNO=w@mail.gmail.com>
 <c65a22a5-07c2-0e40-5c66-431838694b91@oracle.com>
 <d882ef04-e570-a549-a6bd-be66ed30a9b2@oracle.com>
Message-ID: <OF3AA10960.3D043A14-ON00258264.00407BC1-80258264.0042980F@notes.na.collabserv.com>

I also advocate the source code fix, as Make isn't meant to use the sort 
of logic required 
to properly analyse the toolchain version string. 

e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, 
and Make doesn't
seem to do substring stuff unless you mess around with shells.

Plus, as people have said, it's better to solve problem x (or work around 
a specific 
instance of x) than to ignore the exception, even if the ignoring code is 
toolchain-
specific.

- Adam Farley

> On 2018-03-27 18:44, Phil Race wrote:
> 
>> As I said I prefer the make file change, since this is a change to an 
upstream library.
> 
> Newtons fourth law: For every reviewer, there's an equal and opposite 
reviewer. :) 
> 
> Here I am, advocating a source code fix. As Thomas says, the compiler 
complaint seems reasonable, and disabling it might cause us to miss other 
future errors.
> 
> Why can't we push the source code fix, and also submit it upstream?
> 
> /Magnus
> 
> 
> I've looked at jpeg-9c and it still looks identical to what we have in 
6b, so this code
> seems to have stood the test of time. I'm also unclear why the compiler 
would
> complain about that and not the one a few lines later 
> 
> 
>  819   while (bits[i] == 0)          /* find largest codelength still in 
use */
>  820     i--;
> 
> A push to jchuff.c will get blown away if/when we upgrade.
> A tool-chain specific fix in the makefile with an appropriate comment is 
more targeted.
> 
> 
> -phil.
> 
> 
> On 03/27/2018 05:44 AM, Thomas St?fe wrote:
> 
> Hi all, 
> 
> 
> just a friendly reminder. I would like to push this tiny fix because 
tripping over this on our linux s390x builds is annoying (yes, we can 
maintain patch queues, but this is a constant error source).
> 
> 
> I will wait for 24 more hours until a reaction. If no serious objections 
are forcoming, I want to push it (tier1 tests ran thru, and me and 
Christoph langer are both Reviewers).
> 
> 
> Thanks! Thomas
> 
> 
> On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe <thomas.stuefe at gmail.com> 
wrote:
> 
> Hi all, 
> 
> 
> may I please have another review for this really trivial change. It 
fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to 
fix this.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> webrev: 
http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/
> 
> 
> This was contributed by Adam Farley at IBM.
> 
> 
> I already reviewed this. I also test-built on zlinux and it works.
> 
> 
> Thanks, Thomas
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From magnus.ihse.bursie at oracle.com  Tue Apr  3 12:37:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 14:37:12 +0200
Subject: [11] Review Request: 8200146 Remove the appletviewer launcher
In-Reply-To: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com>
References: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com>
Message-ID: <cc5820f3-bd41-8c22-6273-a867d81936d8@oracle.com>

On 2018-03-31 00:52, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200146
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8200146/webrev.00
Build changes look good.

/Magnus

> CSR: https://bugs.openjdk.java.net/browse/JDK-8200549
>
> Fix description:
> ?- The appletviewer launcher was removed from jdk/bin
> ?- The man pages were removed
> ?- Two tests which used appletviewer launcher directly were removed
>
> Note that the appletviewer was deprecated in in jdk9:
> https://bugs.openjdk.java.net/browse/JDK-8074165
>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 12:38:04 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 14:38:04 +0200
Subject: RFR(XXS) : 8200538 : cl : Command line warning D9014 : invalid
 value '2220' for '/wd'
In-Reply-To: <27B6D243-F391-4C9D-BED2-10C7AE67C81B@oracle.com>
References: <27B6D243-F391-4C9D-BED2-10C7AE67C81B@oracle.com>
Message-ID: <ccdae5b6-abc3-9a3c-7fe0-c6f7c5f18b02@oracle.com>


On 2018-03-31 00:10, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8200538/webrev.00/
>> 1 line changed: 0 ins; 0 del; 1 mod;
> Hi all,
>
> could you please review this one-liner change which removes C2220 from disabled warning on windows? C2220 is "warning treated as error" compiler error, which isn't a real compiler warning/error, so it can't be used in /wd as a result, we get warning D9014.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8200538/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8200538
> testing: built windows, windows-debug (including open only) and grepped for D9014 in log
Looks good. Thanks for fixing this, it was very annoying!

/Magnus

>
> Thanks,
> -- Igor
>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 12:15:29 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 14:15:29 +0200
Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests
In-Reply-To: <5b97f219-e3ea-d7cf-dd99-8d2f5c860e21@oracle.com>
References: <5ABAF57B.6050005@oracle.com>
 <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com>
 <e3a70729-b8fe-9b17-c952-f5c09ff82964@oracle.com>
 <bdec2817-7e6d-5206-392e-34f5836886b1@oracle.com>
 <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com>
 <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com>
 <5ABDA3C0.8050902@oracle.com>
 <5b97f219-e3ea-d7cf-dd99-8d2f5c860e21@oracle.com>
Message-ID: <65882e88-baaa-335b-8cb2-8e31da4cf620@oracle.com>

On 2018-03-31 09:30, David Holmes wrote:
> Hi Misha.
>
> This all seems okay.
>
> On 30/03/2018 12:41 PM, Mikhailo Seledtsov wrote:
>> While testing I discovered build errors on Mac and Solaris. The 
>> following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest 
>> := -ljvm" was added to a Linux-only block. I have updated the make 
>> file to add this for any platform w/o conditions; the " exesigtest.c" 
>> is excluded from Windows anyway down below in the make file. I am not 
>> 100% sure this is the correct way to modify the make file; if not 
>> please advise the correct way.
>
> That works for me. I'm not sure how Magnus envisaged this being used 
> though. An alternative would be:
>
> ? ifeq ($(OPENJDK_TARGET_OS), windows)
> ????? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT
> +???? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c
> + else
> +???? BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm
> ? endif
>
> but I think your version is more future-proof.

Either works. If I "envisaged" anything, I think it was more in lines of 
David's suggestion here, but it really doesn't matter. The current 
version is fine as it is.

So, build changes looks good to me.

/Magnus


>
> Thanks,
> David
>
>> With this fix all 4 builds pass.
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~mseledtsov/8200126.02.open/index.html
>>
>> Thank you,
>> Misha
>>
>>
>> On 3/29/18, 4:00 PM, mikhailo wrote:
>>> I have addressed feedback from Christian, David and Magnus. Here is 
>>> the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html
>>>
>>>
>>> I have also confirmed that output from exesigtest.c printf() is 
>>> logged into .jtr files.
>>>
>>> ????? Grepped for "signal", I can see the output such as:
>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler using function 
>>> 'sigset' has been set
>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has 
>>> been processed
>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully
>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been received
>>> ????? Also can see other output from the printf, such as all initVM 
>>> logs.
>>>
>>>
>>> Thank you,
>>> Misha
>>>
>>> On 03/29/2018 02:49 PM, mikhailo wrote:
>>>> Magnus,
>>>>
>>>> Thank you for advice. I have updated the makefile accordingly. Will 
>>>> post updated webrev shortly.
>>>>
>>>>
>>>> Misha
>>>>
>>>>
>>>> On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote:
>>>>> Yes, you seem to have based this off an old version of 
>>>>> JtregNativeHotspot.gmk.
>>>>>
>>>>> If you update the file I think you see how you should do it, but 
>>>>> I'll give you some help:
>>>>>
>>>>> ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>> ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT
>>>>> ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c
>>>>> endif
>>>>
>>>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 13:11:44 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 15:11:44 +0200
Subject: RFR: JDK-8200267 a.out created at top dir by Solaris build
Message-ID: <dd04acda-0821-4253-74ab-35602c3d72f0@oracle.com>

There's an unwanted a.out in the top directory when building with Solaris.

This one was actually a bit tricky to hunt down. It is created by ld 
when extracting the version information, but only when the output of ld 
is piped to head. I'm guessing this has something to do with how Solaris 
handles pipes; perhaps head closes the pipe "forcefully" after it has 
recieved it's single line, causing ld to not being able to clean up the 
temporary a.out that it has created. The patch below solves the issue, 
at any rate.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200267
Patch inline:
diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
--- a/make/autoconf/toolchain.m4
+++ b/make/autoconf/toolchain.m4
@@ -597,8 +597,9 @@

 ???? # solstudio cc requires us to have an existing file to pass as 
argument,
 ???? # but it need not be a syntactically correct C file, so just use
-??? # ourself. :)
-??? LINKER_VERSION_STRING=`$LD -Wl,-V $TOPDIR/configure 2>&1 | $HEAD -n 
1 | $SED -e 's/ld: //'`
+??? # ourself. :) The intermediate 'cat' is needed to stop ld from leaving
+??? # a lingering a.out (!).
+??? LINKER_VERSION_STRING=`$LD -Wl,-V $TOPDIR/configure 2>&1 | $CAT | 
$HEAD -n 1 | $SED -e 's/ld: //'`
 ???? # Extract version number
 ???? [ LINKER_VERSION_NUMBER=`$ECHO $LINKER_VERSION_STRING | \
 ???????? $SED -e 's/.* 
\([0-9][0-9]*\.[0-9][0-9]*\)-\([0-9][0-9]*\.[0-9][0-9]*\)/\1.\2/'` ]

/Magnus


From magnus.ihse.bursie at oracle.com  Tue Apr  3 13:04:13 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 15:04:13 +0200
Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries
In-Reply-To: <CA+kOe08bkip2eGy8rn8viwtQ3eDP8GQYqRUBnsN02WWV6MqwcA@mail.gmail.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>
 <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com>
 <CA+kOe08bkip2eGy8rn8viwtQ3eDP8GQYqRUBnsN02WWV6MqwcA@mail.gmail.com>
Message-ID: <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com>

(pruning cc-list somewhat)

On 2018-03-29 08:16, Martin Buchholz wrote:
> That surprises me. I'm quite certain that javah (or rather, java -h 
> nowadays) generate header files with JNIEXPORT and JNICALL.
>
>
>     As you can see in the jni.h and jni_md.h files, JNIEXPORT equals
>     __attribute__((visibility("default"))) for compilers that support
>     it (gcc and friends), and __declspec(dllexport) for Windows. This
>     means, that the symbol should be exported. (And it's ignored if
>     you use mapfiles aka linker scripts.)
>
>     As for JNICALL, it's empty on most compilers, but evaluates to
>     __stdcall on Windows. This defines the calling convention to use.
>     This is required for JNI calls from Java. (Ask the JVM team why.)
>     While it's not technically required for calling from one dll to
>     another, it's good practice to use it all time to be consistent.
>     In any way, it doesn't hurt us.
>
>
> Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do 
> they */mean?/*
>
> For example, one might expect from the JNI prefix that these macros 
> are exclusively for use by JNI linking, i.e. unsupported except in the 
> output of javac -h.? But of course in practice they are used with 
> arbitrary symbols to communicate between components of user native 
> code, not just to communicate with the JVM.? Is that a bug?
I think I see your point. JNIEXPORT currently has a dual role in 
OpenJDK. The primary role is as part of the JNI interface, as generated 
by javac -h. Since we have multiple native libraries definiting JNI 
entry points from Java, this is a proper usage. As such, it is "well 
defined", at least in the sense that the code is generated by javac, and 
can be assumed to be correct and not subject to user modifications.

But we also use JNIEXPORT for symbol visibility for native 
library-to-native library calls, including calling the JVM. While this 
"works", it would be more proper to define a separate symbol for this 
use, e.g. JDK_EXPORT. Then JDK_EXPORT would have a well-defined meaning, 
and be used only internally in the OpenJDK project.

If this is what you mean, I agree. I'm not sure I'm willing to put the 
time into separating between these two issues, however, but if you get 
backing from the rest of the project, and chose to persue this, I'll 
support you. :-)

/Magnus


From magnus.ihse.bursie at oracle.com  Tue Apr  3 13:40:20 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 15:40:20 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <CAA-vtUyhr120ovH7Lu_nCxks8PcHdAnQj0yPrzKdj5hBpc9dOA@mail.gmail.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <CAA-vtUwkCqUB+DGMxPrOsUeBz5vOVDbCd=qdsGsFhZawLDsGZA@mail.gmail.com>
 <d0fda6bb-c366-19b3-8eb9-f842bc90361d@oracle.com>
 <CAA-vtUzyEgPFNGj6EUWdNMGhoX6=zVdDC9CPs2so3XOuABSSUA@mail.gmail.com>
 <CAA-vtUyhr120ovH7Lu_nCxks8PcHdAnQj0yPrzKdj5hBpc9dOA@mail.gmail.com>
Message-ID: <c13c2201-591e-9106-01a5-dd821ff647e2@oracle.com>



On 2018-03-29 14:51, Thomas St?fe wrote:
> Hi Magnus,
>
> On Thu, Mar 29, 2018 at 8:47 AM, Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>
>
>     On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie
>     <magnus.ihse.bursie at oracle.com
>     <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>
>         On 2018-03-28 21:21, Thomas St?fe wrote:
>>         Hi Magnus,
>>
>>         I had a closer look at the changes, especially at jsig.c. It
>>         all comes slowly back. The AIX version has been almost
>>         comically wrong.
>>
>>         About NSIG, I remember that we had coding in our port which
>>         needed to know the max number of signals, and this was
>>         surprisingly hard since on some platforms. Sometimes NSIG
>>         does not contain the real time signals. Or it did not even
>>         exist. I think we ended up hardcoding an own max signal limit .
>>
>>         So wherever you access sact with a signal number as index,
>>         I'd like to see a bounds check. Or at least an assert - since
>>         this is plain C, a C-assert would do for me (see
>>         http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html
>>         <http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html>).
>>         This also would guard against user parameter error.
>         That's probably a good improvement. Do you think it could be
>         handled as a follow-up bug?
>
>
>     A simple bounds check would suffice for me. At the start of the
>     external sigaction() and sigset(), just do a:
>
>     if (sig < 0 || sig >= NSIG) {
>     ? return -1;
>     }
>
Okay. I've added something like this (a cast was also needed, and we 
should set errno if returning an error, to mimick system behaviour).

>
>     In the external signal(), do a:
>
>     if (sig < 0 || sig >= NSIG) {
>     return SIGERR;
>     }
>
>>
>>         I also wonder whether this coding could not be simplified
>>         quite a bit by not calling the OS versions of signal() at all
>>         but instead doing all signal work via OS sigaction: after
>>         all, signal() can be implemented in terms of sigaction()
>>         (with the flag SA_SIGINFO cleared), and so can sigset(). This
>>         would remove the necessity of reentry-handling for macos, and
>>         also remove the need for save_signal_handler().
>         That also sounds like an excellent suggestion. Do you think it
>         could be handled as a follow-up bug?
>
>
>     Sure!
>
>>
>>         I will test this version on AIX tomorrow. After that, I'll
>>         have some vacation, but maybe someone else from my team will
>>         take over.
>>
>>         I like this work, this is a good simplification.
>         Thanks. :)
>
>         However, it's a bit outside what I normally do. :) Not that I
>         dislike writing some good old C for a change, but I'm really
>         trying to focus on cleaning up the flag handling in the build
>         system. This was just a side-track when I was going to make a
>         change in the jsig.c files (for adding JNIEXPORT) and realized
>         it was four almost identical copies. I thought it would be
>         trivial to unify them, and if it's trivial, it's better to do
>         it yourself right away, than to file a bug on someone else, or
>         so my motto goes. :)
>
>
>         However, it turned out to be more work than I expected, and
>         I'm losing interest in pushing this any further. Still, it
>         would be a shame if the work I've done so far go to waste, but
>         I'd really prefer it if someone else could pick up this patch
>         and finish it.
>
>
>     You are almost there. Lets finish this.
>
Oookay, I'll give it a few more cycles :)

>
>     The source looks good to me, if you add above mentioned bounds
>     checks. I'll build it on AIX later today (I just found out your
>     8200357 - which I need to build on AIX - does not apply to hs, and
>     I need to switch to jdk/jdk. Sigh. The unification of hs/jdk
>     cannot come too early.)
>
>
> I'm about to give up.
>
> I cannot build jdk/jdk on AIX since it misses a number of fixes for 
> all include changes which happened in hotspot lately.
> On jdk/hs your libjsig change won't apply.
>
> So I am stuck here and a bit out of time. If you want to press it, go 
> on push it and we fix any follow up errors on AIX after easter. I am 
> fine with the look of the change (modulo the sig bounds check 
> mentioned earlier).

I'm in no hurry to push this.

Here's an updated webrev with the bounds check in place. Let me know 
if/when you can try it on AIX, and/or if you need help to get the patch 
to apply. You might also have noticed that the signal tests are being 
open sourced, right now, which will definitively help you. (Just a lucky 
coincidence!)

Webrev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.07

/Magnus



>
> Best Regards,
>
> Thomas
>
>
>     ..Thomas
>
>         /Magnus
>
>
>>
>>         Thanks, Thomas
>>
>>
>>
>>
>>         On Wed, Mar 28, 2018 at 12:15 PM, Magnus Ihse Bursie
>>         <magnus.ihse.bursie at oracle.com
>>         <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>>
>>             On 2018-03-27 18:24, Thomas St?fe wrote:
>>>             Hi Magnus,
>>>
>>>             just a cursory look, will look in greater detail tomorrow.
>>>
>>>             This is good, thanks for doing this.
>>>
>>>             As I wrote offlist, please remove the painfully wrong
>>>             AIX "workarounds". I do not know why we did this - the
>>>             original code is quite old - my assumption is that
>>>             dlsym(RTLD_NEXT) was not working as expected on older
>>>             AIX versions. Well, it should work now according to IBMs
>>>             manpages. Will test later.
>>             Ok.
>>>
>>>             __thread is not Posix. I would prefer
>>>             pthread_get/set_specific instead, which is more portable.
>>
>>             I have surrounded this code with #ifdef MACOSX now.
>>
>>             Here is an updated webrev. It includes the changes
>>             requested by you and David:
>>
>>             * No more AIX workarounds
>>             * Solaris use pthreads
>>             * The "reentry" code is #ifdef MACOSX.
>>
>>             I also assumed that NSIG is available and working on
>>             Solaris. I'll let David decide if he is happy with that.
>>             The alternative is to go back to the Solaris-specific
>>             code that allocates sact on the heap.
>>
>>             Webrev:
>>             http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>             <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.05>
>>
>>             Once again, here is also a webrev that shows the
>>             difference between the original files and the new,
>>             unified file. Even if it's hard to read, it shows what
>>             the effects will be for each platform.
>>
>>             Webrev:
>>             http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
>>             <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.04/>
>>
>>             /Magnus
>>
>>>
>>>             Thanks!
>>>
>>>             Thomas
>>>
>>>
>>>
>>>
>>>
>>>             On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie
>>>             <magnus.ihse.bursie at oracle.com
>>>             <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>
>>>                 When I was about to update jsig.c, I noticed that
>>>                 the four copies for aix, linux, macosx and solaris
>>>                 were basically the same, with only small
>>>                 differences. Some of the differences were not even
>>>                 well motivated, but were likely the result of this
>>>                 code duplication causing the code to diverge.
>>>
>>>                 A better solution is to unify them all into a single
>>>                 unix version, with the few platform-specific changes
>>>                 handled on a per-platform basis.
>>>
>>>                 I've made the following notable changes:
>>>
>>>                 * I have removed the version check for Solaris. All
>>>                 other platforms seem to do fine without it, and in
>>>                 general, we don't mistrust other JDK libraries. An
>>>                 alternative is to add this version check to all
>>>                 other platforms instead. If you think this is the
>>>                 correct course of action, let me know and I'll fix it.
>>>
>>>                 * Solaris used to have a dynamically allocated sact,
>>>                 instead of a statically allocated array as all other
>>>                 platforms have. It's not likely to be large, and the
>>>                 size is known at compile time, so there seems to be
>>>                 no good reason for this.
>>>
>>>                 * Linux and macosx used a uint32_t/uint64_t instead
>>>                 of sigset_t for jvmsigs, as aix and solaris do. This
>>>                 is a less robust solution, and the added checks show
>>>                 that it has failed in the past. Now all platforms
>>>                 use sigset_t/sigismember().
>>>
>>>                 Also worth noting:
>>>
>>>                 * Solaris is not using pthreads, but it's own thread
>>>                 library, which accounts for most of the #ifdef SOLARIS.
>>>
>>>                 * In general, if an implementation was needed on one
>>>                 platform, but has no effect or is harmless on
>>>                 others, I've kept it on all platforms instead of
>>>                 sprinkling the code with #ifdefs.
>>>
>>>                 To facilitate code review, here is a specially
>>>                 crafted webrev that shows the differences compared
>>>                 to each of the individual, original per-OS versions
>>>                 of jsig.c:
>>>                 http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>>                 <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01>
>>>
>>>                 Bug:
>>>                 https://bugs.openjdk.java.net/browse/JDK-8200298
>>>                 <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>                 WebRev:
>>>                 http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>>                 <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03>
>>>
>>>                 /Magnus
>>>
>>>
>>
>>
>
>
>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 13:44:47 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 15:44:47 +0200
Subject: a.out left in root directory when configuring
 --with-toolchain-type=clang
In-Reply-To: <5b3e29c0-be0f-c39e-417d-d65f542328dc@oracle.com>
References: <CA+kOe0-XJsOVEyjUVatrohq=5FHoXWL_Df5e+ciujFb0whBjPA@mail.gmail.com>
 <5b3e29c0-be0f-c39e-417d-d65f542328dc@oracle.com>
Message-ID: <52304cb1-9cba-5402-fc10-aa19b197ad72@oracle.com>

Actually, the clang issue is different. The fix for JDK-8200267 is 
solstudio only.

Martin: I cannot reproduce the behaviour with "bash configure 
--with-toolchain-type=clang 
--with-toolchain-path=/usr/lib/llvm-3.9/bin". No a.out file for me. Is 
this repeatable? Are you sure you didn't accidentally hit ctrl-c at some 
point?

/Magnus

On 2018-03-27 22:11, Erik Joelsson wrote:
> https://bugs.openjdk.java.net/browse/JDK-8200267
>
>
> On 2018-03-27 12:35, Martin Buchholz wrote:
>> I notice that running bash ./configure ... leaves an a.out file in 
>> the root
>> directory of the jdk, but only after adding configure flags
>>
>> --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin
>>
>> (i.e. not when building with default gcc)
>>
>> Probably there's a test compilation whose output does not go into the
>> build/ directory, and whose output is not cleaned up.
>



From erik.joelsson at oracle.com  Tue Apr  3 17:30:48 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 10:30:48 -0700
Subject: space.inline.hpp build failure
In-Reply-To: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
References: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
Message-ID: <5c17779e-c069-0f6b-de07-1a5784426d97@oracle.com>

Hello Peter,

Forwarding this to hotspot-dev as it's an issue with hotspot.

/Erik


On 2018-03-29 23:36, Peter Johnson wrote:
> When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the
> following linker error:
> /tmp/cc7TKVtK.ltrans2.ltrans.o: In function
> `OffsetTableContigSpace::block_start_const(void const*) const':
> <artificial>:(.text+0x26e4): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> /tmp/cc7TKVtK.ltrans13.ltrans.o: In function
> `OffsetTableContigSpace::verify() const':
> <artificial>:(.text+0x2ca6): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> collect2: error: ld returned 1 exit status
>
> This appears to be due to a missing include in space.inline.hpp.  Applying
> the following patch fixes the build for me.
>
> Thanks,
> Peter
>
> diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp
> --- a/src/share/vm/gc/shared/space.inline.hpp   Fri Sep 08 18:24:18 2017
> +0000
> +++ b/src/share/vm/gc/shared/space.inline.hpp   Thu Mar 29 23:25:25 2018
> -0700
> @@ -26,6 +26,7 @@
>   #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP
>
>   #include "gc/serial/markSweep.inline.hpp"
> +#include "gc/shared/blockOffsetTable.inline.hpp"
>   #include "gc/shared/collectedHeap.hpp"
>   #include "gc/shared/generation.hpp"
>   #include "gc/shared/space.hpp"



From erik.joelsson at oracle.com  Tue Apr  3 17:40:48 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 10:40:48 -0700
Subject: RFR: JDK-8200267 a.out created at top dir by Solaris build
In-Reply-To: <dd04acda-0821-4253-74ab-35602c3d72f0@oracle.com>
References: <dd04acda-0821-4253-74ab-35602c3d72f0@oracle.com>
Message-ID: <c8c6d809-e96e-35b1-83e2-28f61db61e3c@oracle.com>

Looks good!

/Erik


On 2018-04-03 06:11, Magnus Ihse Bursie wrote:
> There's an unwanted a.out in the top directory when building with 
> Solaris.
>
> This one was actually a bit tricky to hunt down. It is created by ld 
> when extracting the version information, but only when the output of 
> ld is piped to head. I'm guessing this has something to do with how 
> Solaris handles pipes; perhaps head closes the pipe "forcefully" after 
> it has recieved it's single line, causing ld to not being able to 
> clean up the temporary a.out that it has created. The patch below 
> solves the issue, at any rate.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200267
> Patch inline:
> diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4
> --- a/make/autoconf/toolchain.m4
> +++ b/make/autoconf/toolchain.m4
> @@ -597,8 +597,9 @@
>
> ???? # solstudio cc requires us to have an existing file to pass as 
> argument,
> ???? # but it need not be a syntactically correct C file, so just use
> -??? # ourself. :)
> -??? LINKER_VERSION_STRING=`$LD -Wl,-V $TOPDIR/configure 2>&1 | $HEAD 
> -n 1 | $SED -e 's/ld: //'`
> +??? # ourself. :) The intermediate 'cat' is needed to stop ld from 
> leaving
> +??? # a lingering a.out (!).
> +??? LINKER_VERSION_STRING=`$LD -Wl,-V $TOPDIR/configure 2>&1 | $CAT | 
> $HEAD -n 1 | $SED -e 's/ld: //'`
> ???? # Extract version number
> ???? [ LINKER_VERSION_NUMBER=`$ECHO $LINKER_VERSION_STRING | \
> ???????? $SED -e 's/.* 
> \([0-9][0-9]*\.[0-9][0-9]*\)-\([0-9][0-9]*\.[0-9][0-9]*\)/\1.\2/'` ]
>
> /Magnus



From martinrb at google.com  Tue Apr  3 17:55:30 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Apr 2018 10:55:30 -0700
Subject: a.out left in root directory when configuring
 --with-toolchain-type=clang
In-Reply-To: <52304cb1-9cba-5402-fc10-aa19b197ad72@oracle.com>
References: <CA+kOe0-XJsOVEyjUVatrohq=5FHoXWL_Df5e+ciujFb0whBjPA@mail.gmail.com>
 <5b3e29c0-be0f-c39e-417d-d65f542328dc@oracle.com>
 <52304cb1-9cba-5402-fc10-aa19b197ad72@oracle.com>
Message-ID: <CA+kOe0_furw_FOZnRSXsK4vAV_OMdavqz1jHRW1GCQGKkvsxOw@mail.gmail.com>

It's some kind of weird race.

 $ rm -f a.out; bash configure --with-toolchain-type=clang
--with-toolchain-path=/usr/lib/llvm-3.9/bin >&/dev/null; ls -l a.out; file
a.out
bash configure --with-toolchain-type=clang  >&/dev/null  5.04s user 3.81s
system 94% cpu 9.323 total
-rw-r--r-- 1 martin martin 568 Apr  3 10:32 a.out
a.out: data

but then I run it again

 $ rm -f a.out; bash configure --with-toolchain-type=clang
--with-toolchain-path=/usr/lib/llvm-3.9/bin >&/dev/null; ls -l a.out; file
a.out
bash configure --with-toolchain-type=clang  >&/dev/null  5.30s user 2.72s
system 92% cpu 8.625 total
ls: cannot access 'a.out': No such file or directory
a.out: cannot open `a.out' (No such file or directory)

(on my personal Ubuntu machine)

 $ readelf -ld a.out
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start

What is this crazy phantom file?

 $ hd a.out
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
*
00000040  06 00 00 00 05 00 00 00  40 00 00 00 00 00 00 00
|........ at .......|
00000050  40 00 40 00 00 00 00 00  40 00 40 00 00 00 00 00
|@. at .....@. at .....|
00000060  f8 01 00 00 00 00 00 00  f8 01 00 00 00 00 00 00
|................|
00000070  08 00 00 00 00 00 00 00  03 00 00 00 04 00 00 00
|................|
00000080  38 02 00 00 00 00 00 00  38 02 40 00 00 00 00 00  |8.......8.@
.....|
00000090  38 02 40 00 00 00 00 00  1c 00 00 00 00 00 00 00  |8.@
.............|
000000a0  1c 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00
|................|
000000b0  01 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00
|................|
000000c0  00 00 40 00 00 00 00 00  00 00 40 00 00 00 00 00
|.. at .......@.....|
000000d0  44 06 00 00 00 00 00 00  44 06 00 00 00 00 00 00
|D.......D.......|
000000e0  00 00 20 00 00 00 00 00  01 00 00 00 06 00 00 00  |..
.............|
000000f0  10 0e 00 00 00 00 00 00  10 0e 60 00 00 00 00 00
|..........`.....|
00000100  10 0e 60 00 00 00 00 00  20 02 00 00 00 00 00 00  |..`.....
.......|
00000110  28 02 00 00 00 00 00 00  00 00 20 00 00 00 00 00  |(.........
.....|
00000120  02 00 00 00 06 00 00 00  28 0e 00 00 00 00 00 00
|........(.......|
00000130  28 0e 60 00 00 00 00 00  28 0e 60 00 00 00 00 00
|(.`.....(.`.....|
00000140  d0 01 00 00 00 00 00 00  d0 01 00 00 00 00 00 00
|................|
00000150  08 00 00 00 00 00 00 00  04 00 00 00 04 00 00 00
|................|
00000160  54 02 00 00 00 00 00 00  54 02 40 00 00 00 00 00  |T.......T.@
.....|
00000170  54 02 40 00 00 00 00 00  20 00 00 00 00 00 00 00  |T. at .....
.......|
00000180  20 00 00 00 00 00 00 00  04 00 00 00 00 00 00 00  |
...............|
00000190  50 e5 74 64 04 00 00 00  44 05 00 00 00 00 00 00
|P.td....D.......|
000001a0  44 05 40 00 00 00 00 00  44 05 40 00 00 00 00 00  |D. at .....D.@
.....|
000001b0  2c 00 00 00 00 00 00 00  2c 00 00 00 00 00 00 00
|,.......,.......|
000001c0  04 00 00 00 00 00 00 00  51 e5 74 64 06 00 00 00
|........Q.td....|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
*
000001f0  00 00 00 00 00 00 00 00  10 00 00 00 00 00 00 00
|................|
00000200  52 e5 74 64 04 00 00 00  10 0e 00 00 00 00 00 00
|R.td............|
00000210  10 0e 60 00 00 00 00 00  10 0e 60 00 00 00 00 00
|..`.......`.....|
00000220  f0 01 00 00 00 00 00 00  f0 01 00 00 00 00 00 00
|................|
00000230  01 00 00 00 00 00 00 00                           |........|
00000238

On Tue, Apr 3, 2018 at 6:44 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Actually, the clang issue is different. The fix for JDK-8200267 is
> solstudio only.
>
> Martin: I cannot reproduce the behaviour with "bash configure
> --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin".
> No a.out file for me. Is this repeatable? Are you sure you didn't
> accidentally hit ctrl-c at some point?
>
> /Magnus
>
>
> On 2018-03-27 22:11, Erik Joelsson wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8200267
>>
>>
>> On 2018-03-27 12:35, Martin Buchholz wrote:
>>
>>> I notice that running bash ./configure ... leaves an a.out file in the
>>> root
>>> directory of the jdk, but only after adding configure flags
>>>
>>> --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin
>>>
>>> (i.e. not when building with default gcc)
>>>
>>> Probably there's a test compilation whose output does not go into the
>>> build/ directory, and whose output is not cleaned up.
>>>
>>
>>
>


From martinrb at google.com  Tue Apr  3 18:16:00 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Apr 2018 11:16:00 -0700
Subject: RFR: JDK-8200178 Remove mapfiles for JDK native libraries
In-Reply-To: <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com>
References: <9b6ec99a-1f75-3302-36cb-679b59291a20@oracle.com>
 <CA+kOe09d+oua_9zBrSu8Du48kiY+ZzMT=ytW5iEopwB28pNv0w@mail.gmail.com>
 <5e7f7a0c-bf52-e095-ede6-a2599376cb22@oracle.com>
 <CA+kOe08bkip2eGy8rn8viwtQ3eDP8GQYqRUBnsN02WWV6MqwcA@mail.gmail.com>
 <177cf215-9c5d-0834-1b1e-edb15515e344@oracle.com>
Message-ID: <CA+kOe081FbeQB-CUDDHLSENwWVgBPYCASEq2fe=dya65sJwdqg@mail.gmail.com>

On Tue, Apr 3, 2018 at 6:04 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> (pruning cc-list somewhat)
>
> On 2018-03-29 08:16, Martin Buchholz wrote:
>
> That surprises me. I'm quite certain that javah (or rather, java -h
> nowadays) generate header files with JNIEXPORT and JNICALL.
>
>>
>> As you can see in the jni.h and jni_md.h files, JNIEXPORT equals
>> __attribute__((visibility("default"))) for compilers that support it
>> (gcc and friends), and __declspec(dllexport) for Windows. This means, that
>> the symbol should be exported. (And it's ignored if you use mapfiles aka
>> linker scripts.)
>>
>> As for JNICALL, it's empty on most compilers, but evaluates to __stdcall
>> on Windows. This defines the calling convention to use. This is required
>> for JNI calls from Java. (Ask the JVM team why.) While it's not technically
>> required for calling from one dll to another, it's good practice to use it
>> all time to be consistent. In any way, it doesn't hurt us.
>>
>
> Sure, I can see how JNIEXPORT and JNICALL are implemented, but what do
> they *mean?*
>
> For example, one might expect from the JNI prefix that these macros are
> exclusively for use by JNI linking, i.e. unsupported except in the output
> of javac -h.  But of course in practice they are used with arbitrary
> symbols to communicate between components of user native code, not just to
> communicate with the JVM.  Is that a bug?
>
> I think I see your point. JNIEXPORT currently has a dual role in OpenJDK.
> The primary role is as part of the JNI interface, as generated by javac -h.
> Since we have multiple native libraries definiting JNI entry points from
> Java, this is a proper usage. As such, it is "well defined", at least in
> the sense that the code is generated by javac, and can be assumed to be
> correct and not subject to user modifications.
>
> But we also use JNIEXPORT for symbol visibility for native
> library-to-native library calls, including calling the JVM. While this
> "works", it would be more proper to define a separate symbol for this use,
> e.g. JDK_EXPORT. Then JDK_EXPORT would have a well-defined meaning, and be
> used only internally in the OpenJDK project.
>
> If this is what you mean, I agree. I'm not sure I'm willing to put the
> time into separating between these two issues, however, but if you get
> backing from the rest of the project, and chose to persue this, I'll
> support you. :-)
>

Yes, I think we're in agreement.
Even if JNIEXPORT is a purely internal mechanism - there should be some
documentation.
Since there is no other convenient mechanism in the C sources for creating
"public native library symbols", it was probably inevitable that JNIEXPORT
got repurposed.

JNI support in the JDK needs a lot of love, but I'm already overcommitted
elsewhere.


From erik.joelsson at oracle.com  Tue Apr  3 18:14:02 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 11:14:02 -0700
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
Message-ID: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>

This patch changes the default devkit used to produce builds for Linux 
x64 at Oracle. The new devkit is based on GCC 7.3.0.

Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/

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

/Erik



From mikhailo.seledtsov at oracle.com  Tue Apr  3 19:04:26 2018
From: mikhailo.seledtsov at oracle.com (mikhailo)
Date: Tue, 3 Apr 2018 12:04:26 -0700
Subject: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests
In-Reply-To: <65882e88-baaa-335b-8cb2-8e31da4cf620@oracle.com>
References: <5ABAF57B.6050005@oracle.com>
 <637d6d9e-e59a-165f-c9ba-ca1ffa85933d@oracle.com>
 <e3a70729-b8fe-9b17-c952-f5c09ff82964@oracle.com>
 <bdec2817-7e6d-5206-392e-34f5836886b1@oracle.com>
 <21376b33-cf1e-5690-40f5-a3bfd1da0afc@oracle.com>
 <6ec5e0b0-c550-5918-3671-47dfa2e966cc@oracle.com>
 <5ABDA3C0.8050902@oracle.com>
 <5b97f219-e3ea-d7cf-dd99-8d2f5c860e21@oracle.com>
 <65882e88-baaa-335b-8cb2-8e31da4cf620@oracle.com>
Message-ID: <fb8c92b3-d36a-6d21-fdb7-430c1969296f@oracle.com>

David, Christian, Magnus,

Thank you for review.


Misha


On 04/03/2018 05:15 AM, Magnus Ihse Bursie wrote:
> On 2018-03-31 09:30, David Holmes wrote:
>> Hi Misha.
>>
>> This all seems okay.
>>
>> On 30/03/2018 12:41 PM, Mikhailo Seledtsov wrote:
>>> While testing I discovered build errors on Mac and Solaris. The 
>>> following statement " 
>>> BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm" was added 
>>> to a Linux-only block. I have updated the make file to add this for 
>>> any platform w/o conditions; the " exesigtest.c" is excluded from 
>>> Windows anyway down below in the make file. I am not 100% sure this 
>>> is the correct way to modify the make file; if not please advise the 
>>> correct way.
>>
>> That works for me. I'm not sure how Magnus envisaged this being used 
>> though. An alternative would be:
>>
>> ? ifeq ($(OPENJDK_TARGET_OS), windows)
>> ????? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT
>> +???? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c
>> + else
>> +???? BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm
>> ? endif
>>
>> but I think your version is more future-proof.
>
> Either works. If I "envisaged" anything, I think it was more in lines 
> of David's suggestion here, but it really doesn't matter. The current 
> version is fine as it is.
>
> So, build changes looks good to me.
>
> /Magnus
>
>
>>
>> Thanks,
>> David
>>
>>> With this fix all 4 builds pass.
>>>
>>> Here is the updated webrev:
>>> http://cr.openjdk.java.net/~mseledtsov/8200126.02.open/index.html
>>>
>>> Thank you,
>>> Misha
>>>
>>>
>>> On 3/29/18, 4:00 PM, mikhailo wrote:
>>>> I have addressed feedback from Christian, David and Magnus. Here is 
>>>> the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~mseledtsov/8200126.01.open/index.html
>>>>
>>>>
>>>> I have also confirmed that output from exesigtest.c printf() is 
>>>> logged into .jtr files.
>>>>
>>>> ????? Grepped for "signal", I can see the output such as:
>>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler using function 
>>>> 'sigset' has been set
>>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal handler for signal 25 has 
>>>> been processed
>>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been sent successfully
>>>> ????????? TestSigxfsz.jtr:SIGXFSZ: signal has been received
>>>> ????? Also can see other output from the printf, such as all initVM 
>>>> logs.
>>>>
>>>>
>>>> Thank you,
>>>> Misha
>>>>
>>>> On 03/29/2018 02:49 PM, mikhailo wrote:
>>>>> Magnus,
>>>>>
>>>>> Thank you for advice. I have updated the makefile accordingly. 
>>>>> Will post updated webrev shortly.
>>>>>
>>>>>
>>>>> Misha
>>>>>
>>>>>
>>>>> On 03/28/2018 03:26 PM, Magnus Ihse Bursie wrote:
>>>>>> Yes, you seem to have based this off an old version of 
>>>>>> JtregNativeHotspot.gmk.
>>>>>>
>>>>>> If you update the file I think you see how you should do it, but 
>>>>>> I'll give you some help:
>>>>>>
>>>>>> ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>> ? BUILD_HOTSPOT_JTREG_EXECUTABLES_CFLAGS_exeFPRegs := -MT
>>>>>> ? BUILD_HOTSPOT_JTREG_EXCLUDE += exesigtest.c
>>>>>> endif
>>>>>
>>>>
>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 19:38:38 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 21:38:38 +0200
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
In-Reply-To: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
References: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
Message-ID: <65c97bc2-d764-22af-f0bd-428c2b145254@oracle.com>

On 2018-04-03 20:14, Erik Joelsson wrote:
> This patch changes the default devkit used to produce builds for Linux 
> x64 at Oracle. The new devkit is based on GCC 7.3.0.

Woho! :) The future is here. What a leap, 4.9.2 -> 7.3.0.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/
Looks good to me.

/Magnus
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200375
>
> /Erik
>



From magnus.ihse.bursie at oracle.com  Tue Apr  3 19:43:31 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 21:43:31 +0200
Subject: a.out left in root directory when configuring
 --with-toolchain-type=clang
In-Reply-To: <CA+kOe0_furw_FOZnRSXsK4vAV_OMdavqz1jHRW1GCQGKkvsxOw@mail.gmail.com>
References: <CA+kOe0-XJsOVEyjUVatrohq=5FHoXWL_Df5e+ciujFb0whBjPA@mail.gmail.com>
 <5b3e29c0-be0f-c39e-417d-d65f542328dc@oracle.com>
 <52304cb1-9cba-5402-fc10-aa19b197ad72@oracle.com>
 <CA+kOe0_furw_FOZnRSXsK4vAV_OMdavqz1jHRW1GCQGKkvsxOw@mail.gmail.com>
Message-ID: <6aa4b756-5637-c8bf-2f30-195d73e0e76f@oracle.com>

On 2018-04-03 19:55, Martin Buchholz wrote:
> It's some kind of weird race.
Weird. I can't help you out here, since I cannot reproduce.

I can tell you what I did to find the strange a.out file for solaris -- 
I opened one terminal with a "while true; do ls -l a.out; done", and one 
running configure, and then I pressed ctrl-c on configure as soon as the 
a.out appeared. I checked the output, and that gave me an end limit on 
where the file appeared from. Then I started breaking the script in 
various places just ahead of that (by inserting "exit 1" in suitable 
places), and bisected to find the problematic line.

If you have a race and it's not fully reproducible, maybe it's not so 
easy for you.

If this is a recent regression, maybe the problems lies in the same 
place, that is, in the new TOOLCHAIN_EXTRACT_LD_VERSION function?

/Magnus

>
> ?$ rm -f a.out; bash configure --with-toolchain-type=clang 
> --with-toolchain-path=/usr/lib/llvm-3.9/bin >&/dev/null; ls -l a.out; 
> file a.out
> bash configure --with-toolchain-type=clang >&/dev/null? 5.04s user 
> 3.81s system 94% cpu 9.323 total
> -rw-r--r-- 1 martin martin 568 Apr? 3 10:32 a.out
> a.out: data
>
> but then I run it again
>
> ?$ rm -f a.out; bash configure --with-toolchain-type=clang 
> --with-toolchain-path=/usr/lib/llvm-3.9/bin >&/dev/null; ls -l a.out; 
> file a.out
> bash configure --with-toolchain-type=clang >&/dev/null? 5.30s user 
> 2.72s system 92% cpu 8.625 total
> ls: cannot access 'a.out': No such file or directory
> a.out: cannot open `a.out' (No such file or directory)
>
> (on my personal Ubuntu machine)
>
> ?$ readelf -ld a.out
> readelf: Error: Not an ELF file - it has the wrong magic bytes at the 
> start
>
> What is this crazy phantom file?
>
> ?$ hd a.out
> 00000000? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00? 
> |................|
> *
> 00000040? 06 00 00 00 05 00 00 00 40 00 00 00 00 00 00 00? 
> |........ at .......|
> 00000050? 40 00 40 00 00 00 00 00 40 00 40 00 00 00 00 00? 
> |@. at .....@. at .....|
> 00000060? f8 01 00 00 00 00 00 00 f8 01 00 00 00 00 00 00? 
> |................|
> 00000070? 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00? 
> |................|
> 00000080? 38 02 00 00 00 00 00 00 38 02 40 00 00 00 00 00? 
> |8.......8. at .....|
> 00000090? 38 02 40 00 00 00 00 00 1c 00 00 00 00 00 00 00? 
> |8. at .............|
> 000000a0? 1c 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00? 
> |................|
> 000000b0? 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00? 
> |................|
> 000000c0? 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00? 
> |.. at .......@.....|
> 000000d0? 44 06 00 00 00 00 00 00 44 06 00 00 00 00 00 00? 
> |D.......D.......|
> 000000e0? 00 00 20 00 00 00 00 00 01 00 00 00 06 00 00 00? |.. 
> .............|
> 000000f0? 10 0e 00 00 00 00 00 00 10 0e 60 00 00 00 00 00? 
> |..........`.....|
> 00000100? 10 0e 60 00 00 00 00 00 20 02 00 00 00 00 00 00? |..`..... 
> .......|
> 00000110? 28 02 00 00 00 00 00 00 00 00 20 00 00 00 00 00? |(......... 
> .....|
> 00000120? 02 00 00 00 06 00 00 00 28 0e 00 00 00 00 00 00? 
> |........(.......|
> 00000130? 28 0e 60 00 00 00 00 00 28 0e 60 00 00 00 00 00? 
> |(.`.....(.`.....|
> 00000140? d0 01 00 00 00 00 00 00 d0 01 00 00 00 00 00 00? 
> |................|
> 00000150? 08 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00? 
> |................|
> 00000160? 54 02 00 00 00 00 00 00 54 02 40 00 00 00 00 00? 
> |T.......T. at .....|
> 00000170? 54 02 40 00 00 00 00 00 20 00 00 00 00 00 00 00? |T. at ..... 
> .......|
> 00000180? 20 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00? | 
> ...............|
> 00000190? 50 e5 74 64 04 00 00 00 44 05 00 00 00 00 00 00? 
> |P.td....D.......|
> 000001a0? 44 05 40 00 00 00 00 00 44 05 40 00 00 00 00 00? 
> |D. at .....D.@.....|
> 000001b0? 2c 00 00 00 00 00 00 00 2c 00 00 00 00 00 00 00? 
> |,.......,.......|
> 000001c0? 04 00 00 00 00 00 00 00 51 e5 74 64 06 00 00 00? 
> |........Q.td....|
> 000001d0? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00? 
> |................|
> *
> 000001f0? 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00? 
> |................|
> 00000200? 52 e5 74 64 04 00 00 00 10 0e 00 00 00 00 00 00? 
> |R.td............|
> 00000210? 10 0e 60 00 00 00 00 00 10 0e 60 00 00 00 00 00? 
> |..`.......`.....|
> 00000220? f0 01 00 00 00 00 00 00 f0 01 00 00 00 00 00 00? 
> |................|
> 00000230? 01 00 00 00 00 00 00 00 ? ? ? ? ? ? ? ? ? ? ? ? ?|........|
> 00000238
>
> On Tue, Apr 3, 2018 at 6:44 AM, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>> 
> wrote:
>
>     Actually, the clang issue is different. The fix for JDK-8200267 is
>     solstudio only.
>
>     Martin: I cannot reproduce the behaviour with "bash configure
>     --with-toolchain-type=clang
>     --with-toolchain-path=/usr/lib/llvm-3.9/bin". No a.out file for
>     me. Is this repeatable? Are you sure you didn't accidentally hit
>     ctrl-c at some point?
>
>     /Magnus
>
>
>     On 2018-03-27 22:11, Erik Joelsson wrote:
>
>         https://bugs.openjdk.java.net/browse/JDK-8200267
>         <https://bugs.openjdk.java.net/browse/JDK-8200267>
>
>
>         On 2018-03-27 12:35, Martin Buchholz wrote:
>
>             I notice that running bash ./configure ... leaves an a.out
>             file in the root
>             directory of the jdk, but only after adding configure flags
>
>             --with-toolchain-type=clang
>             --with-toolchain-path=/usr/lib/llvm-3.9/bin
>
>             (i.e. not when building with default gcc)
>
>             Probably there's a test compilation whose output does not
>             go into the
>             build/ directory, and whose output is not cleaned up.
>
>
>
>



From tim.bell at oracle.com  Tue Apr  3 20:18:39 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 03 Apr 2018 13:18:39 -0700
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
In-Reply-To: <65c97bc2-d764-22af-f0bd-428c2b145254@oracle.com>
References: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
 <65c97bc2-d764-22af-f0bd-428c2b145254@oracle.com>
Message-ID: <5AC3E19F.6030406@oracle.com>

Erik:

On 04/03/18 12:38, Magnus Ihse Bursie wrote:
> On 2018-04-03 20:14, Erik Joelsson wrote:
>> This patch changes the default devkit used to produce builds for Linux
>> x64 at Oracle. The new devkit is based on GCC 7.3.0.
>
> Woho! :) The future is here. What a leap, 4.9.2 -> 7.3.0.

Indeed.

>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/
> Looks good to me.
>
> /Magnus
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200375

Looks good to me as well.

/Tim




From magnus.ihse.bursie at oracle.com  Tue Apr  3 20:25:19 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 22:25:19 +0200
Subject: RFR: JDK-8200658 Fix incremental builds of hotspot on solaris
Message-ID: <29399495-164a-21ca-543a-7d52a2637de4@oracle.com>

On solaris, jvmciCompilerToVMInit.cpp is always recompiling when 
building incrementally.

The reason is a combination of broken code in NativeCompilation.gmk and 
special options that trigger this on solaris. (OPTIMIZATION := NONE, 
which caused OPT_C[XX]FLAGS to be empty)

Bug: https://bugs.openjdk.java.net/browse/JDK-8200658
Patch inline:
diff --git a/make/common/NativeCompilation.gmk 
b/make/common/NativeCompilation.gmk
--- a/make/common/NativeCompilation.gmk
+++ b/make/common/NativeCompilation.gmk
@@ -292,8 +292,7 @@
 ???? endif

 ???? ifneq ($$(strip $$($1_CFLAGS) $$($1_CXXFLAGS) $$($1_OPTIMIZATION)), )
-????? $1_VARDEPS := $$($1_CFLAGS) $$($1_CXXFLAGS) $$($1_OPT_CFLAGS) \
-????????? $$($1_OPT_CXXFLAGS)
+????? $1_VARDEPS := $$($1_CFLAGS) $$($1_CXXFLAGS) $$($1_OPTIMIZATION)
 ?????? $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, 
$$($1_OBJ).vardeps)
 ???? endif

/Magnus


From erik.joelsson at oracle.com  Tue Apr  3 20:28:37 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 13:28:37 -0700
Subject: RFR: JDK-8200658 Fix incremental builds of hotspot on solaris
In-Reply-To: <29399495-164a-21ca-543a-7d52a2637de4@oracle.com>
References: <29399495-164a-21ca-543a-7d52a2637de4@oracle.com>
Message-ID: <556482ab-2f01-041f-c1db-e1fd45825c2b@oracle.com>

Looks good.

/Erik


On 2018-04-03 13:25, Magnus Ihse Bursie wrote:
> On solaris, jvmciCompilerToVMInit.cpp is always recompiling when 
> building incrementally.
>
> The reason is a combination of broken code in NativeCompilation.gmk 
> and special options that trigger this on solaris. (OPTIMIZATION := 
> NONE, which caused OPT_C[XX]FLAGS to be empty)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200658
> Patch inline:
> diff --git a/make/common/NativeCompilation.gmk 
> b/make/common/NativeCompilation.gmk
> --- a/make/common/NativeCompilation.gmk
> +++ b/make/common/NativeCompilation.gmk
> @@ -292,8 +292,7 @@
> ???? endif
>
> ???? ifneq ($$(strip $$($1_CFLAGS) $$($1_CXXFLAGS) 
> $$($1_OPTIMIZATION)), )
> -????? $1_VARDEPS := $$($1_CFLAGS) $$($1_CXXFLAGS) $$($1_OPT_CFLAGS) \
> -????????? $$($1_OPT_CXXFLAGS)
> +????? $1_VARDEPS := $$($1_CFLAGS) $$($1_CXXFLAGS) $$($1_OPTIMIZATION)
> ?????? $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, 
> $$($1_OBJ).vardeps)
> ???? endif
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Tue Apr  3 20:42:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 22:42:14 +0200
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
Message-ID: <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>

Here's an updated webrev that uses the same pattern as for native shared 
libraries to hide non-exported symbols, for executables as well.

I hope you're happy now :-)

WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02

I know there's a bit of redundancy now for setting -fvisibility=hidden 
and friends. I'll clean that up going forward.

/Magnus

On 2018-03-29 07:48, Martin Buchholz wrote:
>
>
> On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie 
> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>> 
> wrote:
>
>     On 2018-03-28 22:39, Martin Buchholz wrote:
>>
>>
>>     On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
>>     <magnus.ihse.bursie at oracle.com
>>     <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>>
>>         Anyway, with this patch all symbols in executables will be
>>         visible, so there should be no problem anyway.
>>
>>
>>     The symbols visible in the main executable are a sort-of-public
>>     interface. The difference is visible via e.g. nm -D, or any
>>     native code that does dlsym(NULL, symbolName) (yes, we do
>>     this!).? The behavior of native code is likely to be affected if
>>     there is a symbol conflict.? The larger the exported symbol
>>     table, the more overhead there will be at startup (probably). The
>>     theory is that changing an interface requires a CSR.
>
>     If I understand your objections correctly, you are claiming
>     (correct me if I'm misunderstanding you):
>
>     1) Removing the mapfiles will affect performance negatively
>
>     2) The exported symbols from executables are a public API and the
>     change therefore require a CSR.
>
>     To this I reply:
>
>     1) While theoretically this might affect startup time, I can't for
>     the life of me think this would even be measurable. I think any
>     uncertainities in the measurement of the startup of "java" will
>     dwarf any changes due to loading with a different set of exported
>     symbols, in several orders of magnitude. If you claim otherwise, I
>     challenge you to do the measurements.
>
>
> It's true the performance loss here is very small - every java program 
> might be a microsecond slower to start up.
>
>     2) If this is a public API, then show me the documentation. If
>     there is no documentation, then this is not a public interface.
>     Just the fact that you might have used "nm" to locate symbols in a
>     native file and use it, does not mean it's a public interface that
>     requires a CSR to change. If that would be the case, then we could
>     not ever do any change to any native file without filing a CSR,
>     which is obviously absurd.
>
>
> Jigsaw team just spent 10 years working to prevent people from 
> accessing Java internals.? But here the proposal for ELF symbols is 
> "just make everything public" Every ELF symbol that is needlessly 
> exported is something that someone might build a dependency on or 
> might cause a name conflict.? ELF files don't have much encapsulation 
> - all they have is public and? private.
>
>     If you have code that are dependent on a certain set of symbols or
>     whatnot, and you want it to keep functioning, then I recommend
>     that you file a bug and submit a patch to get it into mainline. If
>     you're just collecting a bunch of downstream patches, and this
>     change make your life harder, well, then, sorry, that's not my
>     problem.
>
>
> No, actually making everything public/exporting all symbols will 
> probably make Google local changes easier to maintain - no map files!
>
> I would prefer if build team worked on generating map files with 
> minimal symbols exported, instead of removing them entirely.



From erik.joelsson at oracle.com  Tue Apr  3 21:16:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 14:16:52 -0700
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
Message-ID: <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>

Looks good to me at least. Exporting symbols from executables seems 
wrong so applying hidden as default seems good to me.

/Erik


On 2018-04-03 13:42, Magnus Ihse Bursie wrote:
> Here's an updated webrev that uses the same pattern as for native 
> shared libraries to hide non-exported symbols, for executables as well.
>
> I hope you're happy now :-)
>
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02
>
> I know there's a bit of redundancy now for setting -fvisibility=hidden 
> and friends. I'll clean that up going forward.
>
> /Magnus
>
> On 2018-03-29 07:48, Martin Buchholz wrote:
>>
>>
>> On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com 
>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>> ??? On 2018-03-28 22:39, Martin Buchholz wrote:
>>>
>>>
>>> ??? On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
>>> ??? <magnus.ihse.bursie at oracle.com
>>> ??? <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>
>>>
>>> ??????? Anyway, with this patch all symbols in executables will be
>>> ??????? visible, so there should be no problem anyway.
>>>
>>>
>>> ??? The symbols visible in the main executable are a sort-of-public
>>> ??? interface. The difference is visible via e.g. nm -D, or any
>>> ??? native code that does dlsym(NULL, symbolName) (yes, we do
>>> ??? this!).? The behavior of native code is likely to be affected if
>>> ??? there is a symbol conflict.? The larger the exported symbol
>>> ??? table, the more overhead there will be at startup (probably). The
>>> ??? theory is that changing an interface requires a CSR.
>>
>> ??? If I understand your objections correctly, you are claiming
>> ??? (correct me if I'm misunderstanding you):
>>
>> ??? 1) Removing the mapfiles will affect performance negatively
>>
>> ??? 2) The exported symbols from executables are a public API and the
>> ??? change therefore require a CSR.
>>
>> ??? To this I reply:
>>
>> ??? 1) While theoretically this might affect startup time, I can't for
>> ??? the life of me think this would even be measurable. I think any
>> ??? uncertainities in the measurement of the startup of "java" will
>> ??? dwarf any changes due to loading with a different set of exported
>> ??? symbols, in several orders of magnitude. If you claim otherwise, I
>> ??? challenge you to do the measurements.
>>
>>
>> It's true the performance loss here is very small - every java 
>> program might be a microsecond slower to start up.
>>
>> ??? 2) If this is a public API, then show me the documentation. If
>> ??? there is no documentation, then this is not a public interface.
>> ??? Just the fact that you might have used "nm" to locate symbols in a
>> ??? native file and use it, does not mean it's a public interface that
>> ??? requires a CSR to change. If that would be the case, then we could
>> ??? not ever do any change to any native file without filing a CSR,
>> ??? which is obviously absurd.
>>
>>
>> Jigsaw team just spent 10 years working to prevent people from 
>> accessing Java internals.? But here the proposal for ELF symbols is 
>> "just make everything public" Every ELF symbol that is needlessly 
>> exported is something that someone might build a dependency on or 
>> might cause a name conflict.? ELF files don't have much encapsulation 
>> - all they have is public and? private.
>>
>> ??? If you have code that are dependent on a certain set of symbols or
>> ??? whatnot, and you want it to keep functioning, then I recommend
>> ??? that you file a bug and submit a patch to get it into mainline. If
>> ??? you're just collecting a bunch of downstream patches, and this
>> ??? change make your life harder, well, then, sorry, that's not my
>> ??? problem.
>>
>>
>> No, actually making everything public/exporting all symbols will 
>> probably make Google local changes easier to maintain - no map files!
>>
>> I would prefer if build team worked on generating map files with 
>> minimal symbols exported, instead of removing them entirely.
>



From magnus.ihse.bursie at oracle.com  Wed Apr  4 07:42:16 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 4 Apr 2018 09:42:16 +0200
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
 <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>
Message-ID: <ede6f1ed-0677-0375-df31-1df27dc69f2a@oracle.com>

On 2018-04-03 23:16, Erik Joelsson wrote:
> Looks good to me at least. Exporting symbols from executables seems 
> wrong so applying hidden as default seems good to me.
Unfortunately, it was not this easy. :-(

Out of paranoia, I also started a test run on Windows, even though it 
should not have been affected. Well, "should not". The added JNIEXPORT 
turns into a __declspec(dllexport) on Windows, which causes the 
Microsoft linker to behave like when linking a dll, so it creates a .lib 
and .exp for each binary, in the bin directory.

*sigh*

I see two ways out of this.

1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
main function, or by declaring something like EXEC_EXPORT instead, and 
let it be empty on Windows.

2) Let the part of SetupNativeCompilation that handles executables 
behave more like the one for shared libraries, and setting -implib, etc. 
I'm not sure what happens if you pass in -implib when linking an 
executable which does *not* have any dllexport decorations. If it 
breaks, then this does not really seem like a way forward. Otherwise, 
it's probably the safest choice, since it will make sure we never leak 
any *.lib or *.exp for a potential future executable.

What do you think?

/Magnus

>
> /Erik
>
>
> On 2018-04-03 13:42, Magnus Ihse Bursie wrote:
>> Here's an updated webrev that uses the same pattern as for native 
>> shared libraries to hide non-exported symbols, for executables as well.
>>
>> I hope you're happy now :-)
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02
>>
>> I know there's a bit of redundancy now for setting 
>> -fvisibility=hidden and friends. I'll clean that up going forward.
>>
>> /Magnus
>>
>> On 2018-03-29 07:48, Martin Buchholz wrote:
>>>
>>>
>>> On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com 
>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>
>>> ??? On 2018-03-28 22:39, Martin Buchholz wrote:
>>>>
>>>>
>>>> ??? On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
>>>> ??? <magnus.ihse.bursie at oracle.com
>>>> ??? <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>
>>>>
>>>> ??????? Anyway, with this patch all symbols in executables will be
>>>> ??????? visible, so there should be no problem anyway.
>>>>
>>>>
>>>> ??? The symbols visible in the main executable are a sort-of-public
>>>> ??? interface. The difference is visible via e.g. nm -D, or any
>>>> ??? native code that does dlsym(NULL, symbolName) (yes, we do
>>>> ??? this!).? The behavior of native code is likely to be affected if
>>>> ??? there is a symbol conflict.? The larger the exported symbol
>>>> ??? table, the more overhead there will be at startup (probably). The
>>>> ??? theory is that changing an interface requires a CSR.
>>>
>>> ??? If I understand your objections correctly, you are claiming
>>> ??? (correct me if I'm misunderstanding you):
>>>
>>> ??? 1) Removing the mapfiles will affect performance negatively
>>>
>>> ??? 2) The exported symbols from executables are a public API and the
>>> ??? change therefore require a CSR.
>>>
>>> ??? To this I reply:
>>>
>>> ??? 1) While theoretically this might affect startup time, I can't for
>>> ??? the life of me think this would even be measurable. I think any
>>> ??? uncertainities in the measurement of the startup of "java" will
>>> ??? dwarf any changes due to loading with a different set of exported
>>> ??? symbols, in several orders of magnitude. If you claim otherwise, I
>>> ??? challenge you to do the measurements.
>>>
>>>
>>> It's true the performance loss here is very small - every java 
>>> program might be a microsecond slower to start up.
>>>
>>> ??? 2) If this is a public API, then show me the documentation. If
>>> ??? there is no documentation, then this is not a public interface.
>>> ??? Just the fact that you might have used "nm" to locate symbols in a
>>> ??? native file and use it, does not mean it's a public interface that
>>> ??? requires a CSR to change. If that would be the case, then we could
>>> ??? not ever do any change to any native file without filing a CSR,
>>> ??? which is obviously absurd.
>>>
>>>
>>> Jigsaw team just spent 10 years working to prevent people from 
>>> accessing Java internals.? But here the proposal for ELF symbols is 
>>> "just make everything public" Every ELF symbol that is needlessly 
>>> exported is something that someone might build a dependency on or 
>>> might cause a name conflict.? ELF files don't have much 
>>> encapsulation - all they have is public and private.
>>>
>>> ??? If you have code that are dependent on a certain set of symbols or
>>> ??? whatnot, and you want it to keep functioning, then I recommend
>>> ??? that you file a bug and submit a patch to get it into mainline. If
>>> ??? you're just collecting a bunch of downstream patches, and this
>>> ??? change make your life harder, well, then, sorry, that's not my
>>> ??? problem.
>>>
>>>
>>> No, actually making everything public/exporting all symbols will 
>>> probably make Google local changes easier to maintain - no map files!
>>>
>>> I would prefer if build team worked on generating map files with 
>>> minimal symbols exported, instead of removing them entirely.
>>
>



From david.holmes at oracle.com  Wed Apr  4 07:59:12 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Apr 2018 17:59:12 +1000
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
Message-ID: <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>

Hi Magnus,

Sorry for the delay ...

On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
> 
> On 2018-03-27 18:24, Thomas St?fe wrote:
>> Hi Magnus,
>>
>> just a cursory look, will look in greater detail tomorrow.
>>
>> This is good, thanks for doing this.
>>
>> As I wrote offlist, please remove the painfully wrong AIX 
>> "workarounds". I do not know why we did this - the original code is 
>> quite old - my assumption is that dlsym(RTLD_NEXT) was not working as 
>> expected on older AIX versions. Well, it should work now according to 
>> IBMs manpages. Will test later.
> Ok.
>>
>> __thread is not Posix. I would prefer pthread_get/set_specific 
>> instead, which is more portable.
> 
> I have surrounded this code with #ifdef MACOSX now.
> 
> Here is an updated webrev. It includes the changes requested by you and 
> David:
> 
> * No more AIX workarounds
> * Solaris use pthreads
> * The "reentry" code is #ifdef MACOSX.

That all seems good.

> I also assumed that NSIG is available and working on Solaris. I'll let 
> David decide if he is happy with that. The alternative is to go back to 
> the Solaris-specific code that allocates sact on the heap.

Unfortunately NSIG is a problem on Solaris:

http://austingroupbugs.net/view.php?id=741

It's use also precludes the use of the real-time signals - which limits 
Linux as well. But I'm not completely clear on exactly how signals may 
be numbered in their entirety so I wouldn't necessarily suggest trying 
to use SIGRTMAX+1 as the number of available signals, other than on Solaris.

Thanks,
David

> Webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
> 
> Once again, here is also a webrev that shows the difference between the 
> original files and the new, unified file. Even if it's hard to read, it 
> shows what the effects will be for each platform.
> 
> Webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
> 
> /Magnus
> 
>>
>> Thanks!
>>
>> Thomas
>>
>>
>>
>>
>>
>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>> 
>> wrote:
>>
>> ??? When I was about to update jsig.c, I noticed that the four copies
>> ??? for aix, linux, macosx and solaris were basically the same, with
>> ??? only small differences. Some of the differences were not even well
>> ??? motivated, but were likely the result of this code duplication
>> ??? causing the code to diverge.
>>
>> ??? A better solution is to unify them all into a single unix version,
>> ??? with the few platform-specific changes handled on a per-platform
>> ??? basis.
>>
>> ??? I've made the following notable changes:
>>
>> ??? * I have removed the version check for Solaris. All other
>> ??? platforms seem to do fine without it, and in general, we don't
>> ??? mistrust other JDK libraries. An alternative is to add this
>> ??? version check to all other platforms instead. If you think this is
>> ??? the correct course of action, let me know and I'll fix it.
>>
>> ??? * Solaris used to have a dynamically allocated sact, instead of a
>> ??? statically allocated array as all other platforms have. It's not
>> ??? likely to be large, and the size is known at compile time, so
>> ??? there seems to be no good reason for this.
>>
>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>> ??? solution, and the added checks show that it has failed in the
>> ??? past. Now all platforms use sigset_t/sigismember().
>>
>> ??? Also worth noting:
>>
>> ??? * Solaris is not using pthreads, but it's own thread library,
>> ??? which accounts for most of the #ifdef SOLARIS.
>>
>> ??? * In general, if an implementation was needed on one platform, but
>> ??? has no effect or is harmless on others, I've kept it on all
>> ??? platforms instead of sprinkling the code with #ifdefs.
>>
>> ??? To facilitate code review, here is a specially crafted webrev that
>> ??? shows the differences compared to each of the individual, original
>> ??? per-OS versions of jsig.c:
>> ??? http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>     
>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01>
>>
>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>> ??? <https://bugs.openjdk.java.net/browse/JDK-8200298>
>> ??? WebRev:
>> ??? http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>     
>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03>
>>
>> ??? /Magnus
>>
>>
> 


From magnus.ihse.bursie at oracle.com  Wed Apr  4 07:59:28 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 4 Apr 2018 09:59:28 +0200
Subject: RFR 8200468: Port the native GSS-API bridge to Windows
In-Reply-To: <D6ED2330-7F10-4495-8974-5534E0E08C31@oracle.com>
References: <D6ED2330-7F10-4495-8974-5534E0E08C31@oracle.com>
Message-ID: <b51e46ff-31bd-eed5-5455-a3ce41dce774@oracle.com>

Hi Max,

On 2018-04-04 04:19, Weijun Wang wrote:
> Hi All
>
> Please take a review at
>
>    http://cr.openjdk.java.net/~weijun/8200468/webrev.00/

The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines 
in the "$(eval $(call SetupJdkLibrary" stanza should still be indented 
four spaces. See the makefile style guide: 
http://openjdk.java.net/groups/build/doc/code-conventions.html

Please always cc build-dev when making changes to makefiles.

/Magnus





>
> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this:
>
>   java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ...
>
> You can manually test the change with
>
>   jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java
>
> Thanks
> Max
>
> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html.



From weijun.wang at oracle.com  Wed Apr  4 08:17:10 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 4 Apr 2018 16:17:10 +0800
Subject: RFR 8200468: Port the native GSS-API bridge to Windows
In-Reply-To: <C67B08AA-71E4-4917-940B-9C4912D17F2A@oracle.com>
References: <D6ED2330-7F10-4495-8974-5534E0E08C31@oracle.com>
 <b51e46ff-31bd-eed5-5455-a3ce41dce774@oracle.com>
 <C67B08AA-71E4-4917-940B-9C4912D17F2A@oracle.com>
Message-ID: <5C07D2E2-AD4A-45C7-8FE1-77F26D7BA28E@oracle.com>

I've updated the patch in its original URL. Please confirm it's correct now.

Thanks
Max

> On Apr 4, 2018, at 4:06 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>> 
>> Hi Max,
>> 
>> On 2018-04-04 04:19, Weijun Wang wrote:
>>> Hi All
>>> 
>>> Please take a review at
>>> 
>>>  http://cr.openjdk.java.net/~weijun/8200468/webrev.00/
>> 
>> The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html
> 
> So this is for "2. If a line must be broken, use four spaces for indentation". Right?
> 
>> 
>> Please always cc build-dev when making changes to makefiles.
> 
> I'll remember it.
> 
> Thanks
> Max
> 
>> 
>> /Magnus
>> 
>> 
>> 
>> 
>> 
>>> 
>>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this:
>>> 
>>> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ...
>>> 
>>> You can manually test the change with
>>> 
>>> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java
>>> 
>>> Thanks
>>> Max
>>> 
>>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html.
>> 
> 



From weijun.wang at oracle.com  Wed Apr  4 08:06:40 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 4 Apr 2018 16:06:40 +0800
Subject: RFR 8200468: Port the native GSS-API bridge to Windows
In-Reply-To: <b51e46ff-31bd-eed5-5455-a3ce41dce774@oracle.com>
References: <D6ED2330-7F10-4495-8974-5534E0E08C31@oracle.com>
 <b51e46ff-31bd-eed5-5455-a3ce41dce774@oracle.com>
Message-ID: <C67B08AA-71E4-4917-940B-9C4912D17F2A@oracle.com>



> On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> Hi Max,
> 
> On 2018-04-04 04:19, Weijun Wang wrote:
>> Hi All
>> 
>> Please take a review at
>> 
>>   http://cr.openjdk.java.net/~weijun/8200468/webrev.00/
> 
> The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html

So this is for "2. If a line must be broken, use four spaces for indentation". Right?

> 
> Please always cc build-dev when making changes to makefiles.

I'll remember it.

Thanks
Max

> 
> /Magnus
> 
> 
> 
> 
> 
>> 
>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this:
>> 
>>  java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ...
>> 
>> You can manually test the change with
>> 
>>  jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java
>> 
>> Thanks
>> Max
>> 
>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html.
> 



From magnus.ihse.bursie at oracle.com  Wed Apr  4 10:00:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 4 Apr 2018 12:00:25 +0200
Subject: RFR 8200468: Port the native GSS-API bridge to Windows
In-Reply-To: <C67B08AA-71E4-4917-940B-9C4912D17F2A@oracle.com>
References: <D6ED2330-7F10-4495-8974-5534E0E08C31@oracle.com>
 <b51e46ff-31bd-eed5-5455-a3ce41dce774@oracle.com>
 <C67B08AA-71E4-4917-940B-9C4912D17F2A@oracle.com>
Message-ID: <fb341f07-83cd-1d01-6d56-79216c8c3081@oracle.com>


On 2018-04-04 10:06, Weijun Wang wrote:
>
>> On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>
>> Hi Max,
>>
>> On 2018-04-04 04:19, Weijun Wang wrote:
>>> Hi All
>>>
>>> Please take a review at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8200468/webrev.00/
>> The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html
> So this is for "2. If a line must be broken, use four spaces for indentation". Right?
Yes. 2 spaces for "logical" indentations (such as in an if statement), 
and 4 spaces for broken lines.

>
>> Please always cc build-dev when making changes to makefiles.
> I'll remember it.
Thanks!

/Magnus

>
> Thanks
> Max
>
>> /Magnus
>>
>>
>>
>>
>>
>>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this:
>>>
>>>   java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ...
>>>
>>> You can manually test the change with
>>>
>>>   jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java
>>>
>>> Thanks
>>> Max
>>>
>>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html.



From magnus.ihse.bursie at oracle.com  Wed Apr  4 11:35:37 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 4 Apr 2018 13:35:37 +0200
Subject: RFR: JDK-8200727 linux-aarch64 profile should use bundled freetype
Message-ID: <f0eae89b-c568-fde1-1901-3790cfd53b6d@oracle.com>

To facilitate cross-compiling, the linux-aarch64 jib profile should use 
--with-freetype=bundled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200727
Patch inline:
diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js
--- a/make/conf/jib-profiles.js
+++ b/make/conf/jib-profiles.js
@@ -472,7 +472,7 @@
 ???????????? build_cpu: "x64",
 ???????????? dependencies: ["devkit", "autoconf", "build_devkit", "cups"],
 ???????????? configure_args: [
-??????????????? "--openjdk-target=aarch64-linux-gnu"
+??????????????? "--openjdk-target=aarch64-linux-gnu", 
"--with-freetype=bundled",
 ???????????? ],
 ???????? },


/Magnus

From bren at juanantonio.info  Wed Apr  4 10:29:31 2018
From: bren at juanantonio.info (bren at juanantonio.info)
Date: Wed, 04 Apr 2018 12:29:31 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5 Soft
 Float
Message-ID: <209e831bd10929184afdbedb7e811652@juanantonio.info>

Good morning,

Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
libraries for Lego Mindstorms EV3, an ARM5 robotics device and recently, 
we build OpenJDK 9 with success but with OpenJDK 10, we have found some 
problems when we execute some Java programs.

Repository to build OpenJDK 9/10 for ARM5 Soft Float:
https://github.com/ev3dev-lang-java/openjdk-ev3

To test the JVM, I am using the following repo to test the VM:
https://github.com/ev3dev-lang-java/vmbenchmarks

And this is the output with the error:

robot at ev3dev:~$ java -jar benchmarks.jar -f 1
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
(file:/home/robot/benchmarks.jar) to field java.io.Console.cs
WARNING: Please consider reporting this to the maintainers of 
org.openjdk.jmh.util.Utils
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future 
release
=============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
platform ================

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


=============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
platform ================

[thread 4430 also had an error]
[error occurred during error reporting ((null)), id 0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing fatal error message), 
id 0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing type of error), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing stack bounds), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing native stack), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing Java stack), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing target Java thread 
stack), id 0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing siginfo), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (CDS archive access warning), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[error occurred during error reporting (printing register info), id 
0xe0000000]

=============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
platform ================


[Too many errors, abort]
Aborted

I think that in OpenJDK10 changed something in compare to OpenJDK9 in 
relation to ARM5 support.

Any idea?

Many thanks in advance.

Cheers

Juan Antonio



From glaubitz at physik.fu-berlin.de  Wed Apr  4 15:06:02 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 4 Apr 2018 17:06:02 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <209e831bd10929184afdbedb7e811652@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
Message-ID: <4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>

CC'ing hotspot-dev

On 04/04/2018 12:29 PM, bren at juanantonio.info wrote:
> I think that in OpenJDK10 changed something in compare to OpenJDK9 in relation to ARM5 support.

It was OpenJDK9 which dropped support for ARM CPUs prior ARMv7. If you are
using ARMv5, you have to resort to OpenJDK Zero, i.e. the unoptimized, generic
implementation of the JVM.

As for the atomic operation, I'm not sure whether Zero supports this particular
atomic operation. I will have to dig into the code myself.

Would it be possible that you provide sample code that helps reproduce the problem?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Wed Apr  4 15:25:30 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 08:25:30 -0700
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <ede6f1ed-0677-0375-df31-1df27dc69f2a@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
 <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>
 <ede6f1ed-0677-0375-df31-1df27dc69f2a@oracle.com>
Message-ID: <19023a7d-6374-6a0d-77d8-0b9920add1e8@oracle.com>


On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
> On 2018-04-03 23:16, Erik Joelsson wrote:
>> Looks good to me at least. Exporting symbols from executables seems 
>> wrong so applying hidden as default seems good to me.
> Unfortunately, it was not this easy. :-(
>
> Out of paranoia, I also started a test run on Windows, even though it 
> should not have been affected. Well, "should not". The added JNIEXPORT 
> turns into a __declspec(dllexport) on Windows, which causes the 
> Microsoft linker to behave like when linking a dll, so it creates a 
> .lib and .exp for each binary, in the bin directory.
>
> *sigh*
>
> I see two ways out of this.
>
> 1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
> main function, or by declaring something like EXEC_EXPORT instead, and 
> let it be empty on Windows.
>
> 2) Let the part of SetupNativeCompilation that handles executables 
> behave more like the one for shared libraries, and setting -implib, 
> etc. I'm not sure what happens if you pass in -implib when linking an 
> executable which does *not* have any dllexport decorations. If it 
> breaks, then this does not really seem like a way forward. Otherwise, 
> it's probably the safest choice, since it will make sure we never leak 
> any *.lib or *.exp for a potential future executable.
>
> What do you think?
>
I really don't know which I would prefer. Would be good to find out what 
happens in 2.

/Erik


From erik.joelsson at oracle.com  Wed Apr  4 15:27:10 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 08:27:10 -0700
Subject: RFR: JDK-8200727 linux-aarch64 profile should use bundled freetype
In-Reply-To: <f0eae89b-c568-fde1-1901-3790cfd53b6d@oracle.com>
References: <f0eae89b-c568-fde1-1901-3790cfd53b6d@oracle.com>
Message-ID: <412c90c7-5482-10e1-8df5-70cb86d6f269@oracle.com>

Looks good.

/Erik


On 2018-04-04 04:35, Magnus Ihse Bursie wrote:
> To facilitate cross-compiling, the linux-aarch64 jib profile should 
> use --with-freetype=bundled.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200727
> Patch inline:
> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js
> --- a/make/conf/jib-profiles.js
> +++ b/make/conf/jib-profiles.js
> @@ -472,7 +472,7 @@
> ???????????? build_cpu: "x64",
> ???????????? dependencies: ["devkit", "autoconf", "build_devkit", 
> "cups"],
> ???????????? configure_args: [
> -??????????????? "--openjdk-target=aarch64-linux-gnu"
> +??????????????? "--openjdk-target=aarch64-linux-gnu", 
> "--with-freetype=bundled",
> ???????????? ],
> ???????? },
>
>
> /Magnus


From martinrb at google.com  Wed Apr  4 16:09:02 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 4 Apr 2018 09:09:02 -0700
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
Message-ID: <CA+kOe08b45QUkhoxpeB6y2TuZR4V=p-Xxd-zZZVC-Q+p94VVRA@mail.gmail.com>

On Tue, Apr 3, 2018 at 1:42 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> Here's an updated webrev that uses the same pattern as for native shared
> libraries to hide non-exported symbols, for executables as well.
>
> I hope you're happy now :-)
>
>
Thanks for your efforts!  I know it's not easy.


From bob.vandette at oracle.com  Wed Apr  4 16:15:38 2018
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 4 Apr 2018 12:15:38 -0400
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>
Message-ID: <AE5E3644-C06D-4114-9020-C414DD170294@oracle.com>

I believe the problem is that the VM is now using more atomic load/store of java longs
and we don?t support these operations on multi-processing ARMv5 systems due to the
lack of low level atomic instructions.  On non MP ARMv5 systems, we use load/store multiple
instructions.

If you can determine that your ARMv5 processor?s implementation of ldmia/stmia are
indeed atomic, you could try to use these instructions by altering the code below.

Otherwise, you might want to investigate gcc atomic intrinsics and see if 8 byte atomics
are supported on your platform.  There?s a set of kernel helper routines that we use
for atomic exchange of 8 bytes, maybe they now have atomic 8 byte loads/stores.

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt


In open/src/hotspot/cpu/arm/stubGenerator_arm.cpp, these two functions would need to be
fixed to provide these low level operations.

  address generate_atomic_load_long() {
    address start;

    StubCodeMark mark(this, "StubRoutines", "atomic_load_long");
    start = __ pc();
    Register result_lo = R0;
    Register result_hi = R1;
    Register src       = R0;

    if (!os::is_MP()) {
      __ ldmia(src, RegisterSet(result_lo, result_hi));
      __ bx(LR);
    } else if (VM_Version::supports_ldrexd()) {
      __ ldrexd(result_lo, Address(src));
      __ clrex(); // FIXME: safe to remove?
      __ bx(LR);
    } else {
      __ stop("Atomic load(jlong) unsupported on this platform");
      __ bx(LR);
    }

    return start;
  }

  address generate_atomic_store_long() {
    address start;

    StubCodeMark mark(this, "StubRoutines", "atomic_store_long");
    start = __ pc();
    Register newval_lo = R0;
    Register newval_hi = R1;
    Register dest      = R2;
    Register scratch_lo    = R2;
    Register scratch_hi    = R3;  /* After load from stack */
    Register result    = R3;

    if (!os::is_MP()) {
      __ stmia(dest, RegisterSet(newval_lo, newval_hi));
      __ bx(LR);
    } else if (VM_Version::supports_ldrexd()) {
      __ mov(Rtemp, dest);  // get dest to Rtemp
      Label retry;
      __ bind(retry);
      __ ldrexd(scratch_lo, Address(Rtemp));
      __ strexd(result, R0, Address(Rtemp));
      __ rsbs(result, result, 1);
      __ b(retry, eq);
      __ bx(LR);
    } else {
      __ stop("Atomic store(jlong) unsupported on this platform");
      __ bx(LR);
    }

    return start;
  }

Bob.

> On Apr 4, 2018, at 11:06 AM, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
> 
> CC'ing hotspot-dev
> 
> On 04/04/2018 12:29 PM, bren at juanantonio.info wrote:
>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in relation to ARM5 support.
> 
> It was OpenJDK9 which dropped support for ARM CPUs prior ARMv7. If you are
> using ARMv5, you have to resort to OpenJDK Zero, i.e. the unoptimized, generic
> implementation of the JVM.
> 
> As for the atomic operation, I'm not sure whether Zero supports this particular
> atomic operation. I will have to dig into the code myself.
> 
> Would it be possible that you provide sample code that helps reproduce the problem?
> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



From gary.adams at oracle.com  Wed Apr  4 18:18:35 2018
From: gary.adams at oracle.com (Gary Adams)
Date: Wed, 04 Apr 2018 14:18:35 -0400
Subject: RFR: JDK-8199782: Fix compilation warnings detected by Solaris
 Developer Studio 12.6
Message-ID: <5AC516FB.9010101@oracle.com>

Getting the sources ready for the next Solaris developer studio toolchain.

   Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
   Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/

This update conditionally disables some new error checks, if the
new toolchain is used.


From erik.joelsson at oracle.com  Wed Apr  4 18:30:08 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 11:30:08 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
Message-ID: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>

This patch changes the values for the macosx version min and max 
settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to 
libc++ (explicitly for Hotspot and implicitly everywhere else). This 
change is necessary to keep up with newer toolchain versions on Macosx 
where using the old and no longer maintained libstdc++ has been 
deprecated. This is done in preparation for bumping the preferred Xcode 
version used for builds at Oracle.

The switch has been tested for both Hotspot and client.

The switch triggered some new deprecation warnings which have been 
silenced and followup bugs have been filed on the concerned team.

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

Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html

/Erik



From serguei.spitsyn at oracle.com  Wed Apr  4 18:41:07 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 4 Apr 2018 11:41:07 -0700
Subject: RFR: JDK-8199782: Fix compilation warnings detected by Solaris
 Developer Studio 12.6
In-Reply-To: <5AC516FB.9010101@oracle.com>
References: <5AC516FB.9010101@oracle.com>
Message-ID: <3d192086-7fdd-4bc3-337a-6e2e34b1e99f@oracle.com>

Hi Gary,

It looks reasonable.
I'm not very familiar with the concrete SolStudio versions.

Thanks,
Serguei


On 4/4/18 11:18, Gary Adams wrote:
> Getting the sources ready for the next Solaris developer studio 
> toolchain.
>
> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
> ? Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/
>
> This update conditionally disables some new error checks, if the
> new toolchain is used.



From tim.bell at oracle.com  Wed Apr  4 19:36:53 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 04 Apr 2018 12:36:53 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <5AC52955.1000306@oracle.com>

Erik:

> This patch changes the values for the macosx version min and max
> settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to
> libc++ (explicitly for Hotspot and implicitly everywhere else). This
> change is necessary to keep up with newer toolchain versions on Macosx
> where using the old and no longer maintained libstdc++ has been
> deprecated. This is done in preparation for bumping the preferred Xcode
> version used for builds at Oracle.
>
> The switch has been tested for both Hotspot and client.
>
> The switch triggered some new deprecation warnings which have been
> silenced and followup bugs have been filed on the concerned team.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html

Looks good.

/Tim



From gerard.ziemski at oracle.com  Wed Apr  4 20:11:12 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Wed, 4 Apr 2018 15:11:12 -0500
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>

hi Erik,

Thanks for doing this.

I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs.

Just a quick verification question (not very familiar with the makefiles), in line like this:

DISABLED_WARNINGS_clang := deprecated-declarations

I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler?


cheers

> On Apr 4, 2018, at 1:30 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle.
> 
> The switch has been tested for both Hotspot and client.
> 
> The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
> 
> /Erik
> 



From erik.joelsson at oracle.com  Wed Apr  4 20:27:54 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 13:27:54 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
 <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>
Message-ID: <f93eda1e-d89d-3c58-90db-1e7708e26908@oracle.com>

On 2018-04-04 13:11, Gerard Ziemski wrote:
> hi Erik,
>
> Thanks for doing this.
>
> I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs.
>
> Just a quick verification question (not very familiar with the makefiles), in line like this:
>
> DISABLED_WARNINGS_clang := deprecated-declarations
>
> I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler?
Yes, (to be more precise -Wno-deprecated-declarations) this is the 
preferred way of disabling warnings in the build.

/Erik
>
> cheers
>
>> On Apr 4, 2018, at 1:30 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle.
>>
>> The switch has been tested for both Hotspot and client.
>>
>> The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
>>
>> /Erik
>>



From erik.joelsson at oracle.com  Wed Apr  4 20:54:00 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 13:54:00 -0700
Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10
In-Reply-To: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
Message-ID: <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>

Updating the bootjdk requirement for JDK 11 was controversial. Instead I 
propose that for now, we just update the bootjdk used for building JDK 
11 at Oracle to JDK 10 and let compatibility with JDK 9 be a best effort 
from the parts of the community that wants to support it.

Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/

/Erik


On 2018-03-21 14:51, Erik Joelsson wrote:
> Now that JDK 10 has been officially released we can update the boot 
> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
> awareness of this rather disruptive change.
>
> This patch changes the requirement on boot jdk version in configure 
> (and updates the configuration that controls what JDK to use as boot 
> in Oracle's internal build system).
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>
> /Erik
>



From erik.joelsson at oracle.com  Wed Apr  4 20:55:04 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 13:55:04 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
Message-ID: <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>

Resending with corrected title.


On 2018-04-04 13:54, Erik Joelsson wrote:
> Updating the bootjdk requirement for JDK 11 was controversial. Instead 
> I propose that for now, we just update the bootjdk used for building 
> JDK 11 at Oracle to JDK 10 and let compatibility with JDK 9 be a best 
> effort from the parts of the community that wants to support it.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/
>
> /Erik
>
>
> On 2018-03-21 14:51, Erik Joelsson wrote:
>> Now that JDK 10 has been officially released we can update the boot 
>> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
>> awareness of this rather disruptive change.
>>
>> This patch changes the requirement on boot jdk version in configure 
>> (and updates the configuration that controls what JDK to use as boot 
>> in Oracle's internal build system).
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>
>> /Erik
>>
>



From jonathan.gibbons at oracle.com  Wed Apr  4 21:00:36 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 04 Apr 2018 14:00:36 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
Message-ID: <5AC53CF4.10007@oracle.com>

Erik,

Why bother?  What are you trying to achieve?

Either the boot JDK is JDK 9, or it is JDK 10.  This should be a clear 
decision.

If internally at Oracle, we use 10, then as soon as code creeps in that 
relies on 10 features, we've broken the commitment to the community for 
allowing 9 as a boot JDK.

-- Jon

On 04/04/2018 01:55 PM, Erik Joelsson wrote:
> Resending with corrected title.
>
>
> On 2018-04-04 13:54, Erik Joelsson wrote:
>> Updating the bootjdk requirement for JDK 11 was controversial. 
>> Instead I propose that for now, we just update the bootjdk used for 
>> building JDK 11 at Oracle to JDK 10 and let compatibility with JDK 9 
>> be a best effort from the parts of the community that wants to 
>> support it.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/
>>
>> /Erik
>>
>>
>> On 2018-03-21 14:51, Erik Joelsson wrote:
>>> Now that JDK 10 has been officially released we can update the boot 
>>> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
>>> awareness of this rather disruptive change.
>>>
>>> This patch changes the requirement on boot jdk version in configure 
>>> (and updates the configuration that controls what JDK to use as boot 
>>> in Oracle's internal build system).
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>>
>>> /Erik
>>>
>>
>



From david.holmes at oracle.com  Wed Apr  4 22:12:35 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 08:12:35 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <209e831bd10929184afdbedb7e811652@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
Message-ID: <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>

Hi,

This was already reported as:

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

to which I have responded and closed the bug as this is not a supported 
platform.

As per the bug report this may be due to the change to AssumeMP to be 
true, but there is no MP support for ARMv5.

David

On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
> Good morning,
> 
> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
> libraries for Lego Mindstorms EV3, an ARM5 robotics device and recently, 
> we build OpenJDK 9 with success but with OpenJDK 10, we have found some 
> problems when we execute some Java programs.
> 
> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
> https://github.com/ev3dev-lang-java/openjdk-ev3
> 
> To test the JVM, I am using the following repo to test the VM:
> https://github.com/ev3dev-lang-java/vmbenchmarks
> 
> And this is the output with the error:
> 
> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
> WARNING: Please consider reporting this to the maintainers of 
> org.openjdk.jmh.util.Utils
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
> platform ================
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
> platform ================
> 
> [thread 4430 also had an error]
> [error occurred during error reporting ((null)), id 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing fatal error message), 
> id 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing type of error), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing stack bounds), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing native stack), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing Java stack), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing target Java thread 
> stack), id 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing siginfo), id 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (CDS archive access warning), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [error occurred during error reporting (printing register info), id 
> 0xe0000000]
> 
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
> platform ================
> 
> 
> [Too many errors, abort]
> Aborted
> 
> I think that in OpenJDK10 changed something in compare to OpenJDK9 in 
> relation to ARM5 support.
> 
> Any idea?
> 
> Many thanks in advance.
> 
> Cheers
> 
> Juan Antonio
> 


From erik.joelsson at oracle.com  Wed Apr  4 23:06:53 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 16:06:53 -0700
Subject: RFR: JDK-8199539: Provide a standard way for the build to filter
 un-needed legal .md files
Message-ID: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>

When bundling legal files, we need to filter them according to what 3rd 
party components are actually included in the build. Several components, 
such as zlib, libjpeg and freetype can be linked with system libraries 
instead, and if so, we should also exclude the legal files for that 
component.

This patch introduces a optional copy/filter step in the <module>-copy 
targets. Since there are only two affected modules at this time I didn't 
bother unifying this into one implementation. Instead the short logic is 
duplicated between the two.

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

Webrev: http://cr.openjdk.java.net/~erikj/8199539/webrev.01/index.html

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

/Erik



From martinrb at google.com  Wed Apr  4 23:18:37 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 4 Apr 2018 16:18:37 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
Message-ID: <CA+kOe0-vXe7QXO1b3V_c=4wfh8=53Z9DGj2cH3ds4aZ3VUP4yA@mail.gmail.com>

I'm a big fan of portability and flexibility, so I would want to test with
all the supported boot jdks, perhaps even chosen randomly.
But if you test with only one boot jdk, then it should be the recommended
version.


From david.holmes at oracle.com  Thu Apr  5 00:00:02 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 10:00:02 +1000
Subject: RFR: JDK-8199782: Fix compilation warnings detected by Solaris
 Developer Studio 12.6
In-Reply-To: <5AC516FB.9010101@oracle.com>
References: <5AC516FB.9010101@oracle.com>
Message-ID: <d8b01f42-1fc7-cd06-69ca-27c9efcae82d@oracle.com>

Hi Gary,

On 5/04/2018 4:18 AM, Gary Adams wrote:
> Getting the sources ready for the next Solaris developer studio toolchain.
> 
>  ? Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
>  ? Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/
> 
> This update conditionally disables some new error checks, if the
> new toolchain is used.

This looks odd:

  231     DISABLED_WARNINGS_solstudio := $(DISABLED_WARNINGS_solstudio), \

as it is self-referential. Should you use a different variable name? Is 
there an issue if this variable has not been set?

Otherwise seems okay.

Thanks,
David


From david.holmes at oracle.com  Thu Apr  5 00:05:35 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 10:05:35 +1000
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
In-Reply-To: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
References: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
Message-ID: <7110b119-bbeb-cac4-bb44-793e1dae6cdd@oracle.com>

On 4/04/2018 4:14 AM, Erik Joelsson wrote:
> This patch changes the default devkit used to produce builds for Linux 
> x64 at Oracle. The new devkit is based on GCC 7.3.0.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/

What does the final part of gcc7.3.0-OEL6.4+1.0 refer to? It was 1.3 and 
is now 1.0.

David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8200375
> 
> /Erik
> 


From erik.joelsson at oracle.com  Thu Apr  5 00:08:26 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 17:08:26 -0700
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
In-Reply-To: <7110b119-bbeb-cac4-bb44-793e1dae6cdd@oracle.com>
References: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
 <7110b119-bbeb-cac4-bb44-793e1dae6cdd@oracle.com>
Message-ID: <ed54d3fb-502c-213e-6972-3f009e6f45b1@oracle.com>

On 2018-04-04 17:05, David Holmes wrote:
> On 4/04/2018 4:14 AM, Erik Joelsson wrote:
>> This patch changes the default devkit used to produce builds for 
>> Linux x64 at Oracle. The new devkit is based on GCC 7.3.0.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/
>
> What does the final part of gcc7.3.0-OEL6.4+1.0 refer to? It was 1.3 
> and is now 1.0.
>
It's an internal version string for the devkit. I bump it when making 
changes that aren't changing the compiler or sysroot versions, like 
adding another library to the sysroot (e.g. libffi, freetype). I figured 
restarting it at 1.0 at times like this makes sense.

/Erik
> David
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200375
>>
>> /Erik
>>



From erik.joelsson at oracle.com  Thu Apr  5 00:05:43 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 17:05:43 -0700
Subject: RFR: JDK-8199782: Fix compilation warnings detected by Solaris
 Developer Studio 12.6
In-Reply-To: <d8b01f42-1fc7-cd06-69ca-27c9efcae82d@oracle.com>
References: <5AC516FB.9010101@oracle.com>
 <d8b01f42-1fc7-cd06-69ca-27c9efcae82d@oracle.com>
Message-ID: <f303b48c-4e16-6e5d-75bb-d33e985bfc77@oracle.com>

On 2018-04-04 17:00, David Holmes wrote:
> Hi Gary,
>
> On 5/04/2018 4:18 AM, Gary Adams wrote:
>> Getting the sources ready for the next Solaris developer studio 
>> toolchain.
>>
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/
>>
>> This update conditionally disables some new error checks, if the
>> new toolchain is used.
>
> This looks odd:
>
> ?231???? DISABLED_WARNINGS_solstudio := $(DISABLED_WARNINGS_solstudio), \
>
> as it is self-referential. Should you use a different variable name? 
> Is there an issue if this variable has not been set?
>
This construct may look a bit weird but is fine. The named parameter 
will get translated behind the scenes to 
BUILD_LIBJVM_DISABLED_WARNINGS_solstudio so it's not actually self 
referential (and even if it was, it would still work as expected, even 
if it looks a bit weird).

/Erik
> Otherwise seems okay.
>
> Thanks,
> David



From martinrb at google.com  Thu Apr  5 00:31:10 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 4 Apr 2018 17:31:10 -0700
Subject: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle
In-Reply-To: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
References: <e295df03-be99-757d-9f4d-2a8671b6070a@oracle.com>
Message-ID: <CA+kOe097138cpxG3Nga+tyfPrd8e1GLaY3_DR0_+Q2wegJVCLQ@mail.gmail.com>

I presume build folk are aware that older compilers produce more portable
binaries.
My own rule of thumb is to use 5 year old compilers - battle tested, well
aged, but haven't turned to vinegar yet.

On Tue, Apr 3, 2018 at 11:14 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> This patch changes the default devkit used to produce builds for Linux x64
> at Oracle. The new devkit is based on GCC 7.3.0.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200375
>
> /Erik
>
>


From Sergey.Bylokhov at oracle.com  Thu Apr  5 00:33:54 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 4 Apr 2018 17:33:54 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <5fa6cb00-7070-cd2a-c5d9-ad256b17c5f9@oracle.com>

Looks fine.

On 04/04/2018 11:30, Erik Joelsson wrote:
> This patch changes the values for the macosx version min and max 
> settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to 
> libc++ (explicitly for Hotspot and implicitly everywhere else). This 
> change is necessary to keep up with newer toolchain versions on Macosx 
> where using the old and no longer maintained libstdc++ has been 
> deprecated. This is done in preparation for bumping the preferred Xcode 
> version used for builds at Oracle.
> 
> The switch has been tested for both Hotspot and client.
> 
> The switch triggered some new deprecation warnings which have been 
> silenced and followup bugs have been filed on the concerned team.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
> 
> /Erik
> 


-- 
Best regards, Sergey.


From david.holmes at oracle.com  Thu Apr  5 00:03:49 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 10:03:49 +1000
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <5AC53CF4.10007@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
Message-ID: <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>

On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
> Erik,
> 
> Why bother?? What are you trying to achieve?
> 
> Either the boot JDK is JDK 9, or it is JDK 10.? This should be a clear 
> decision.
> 
> If internally at Oracle, we use 10, then as soon as code creeps in that 
> relies on 10 features, we've broken the commitment to the community for 
> allowing 9 as a boot JDK.

I have to agree. There can't be two bootJDK versions.

David

> -- Jon
> 
> On 04/04/2018 01:55 PM, Erik Joelsson wrote:
>> Resending with corrected title.
>>
>>
>> On 2018-04-04 13:54, Erik Joelsson wrote:
>>> Updating the bootjdk requirement for JDK 11 was controversial. 
>>> Instead I propose that for now, we just update the bootjdk used for 
>>> building JDK 11 at Oracle to JDK 10 and let compatibility with JDK 9 
>>> be a best effort from the parts of the community that wants to 
>>> support it.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/
>>>
>>> /Erik
>>>
>>>
>>> On 2018-03-21 14:51, Erik Joelsson wrote:
>>>> Now that JDK 10 has been officially released we can update the boot 
>>>> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
>>>> awareness of this rather disruptive change.
>>>>
>>>> This patch changes the requirement on boot jdk version in configure 
>>>> (and updates the configuration that controls what JDK to use as boot 
>>>> in Oracle's internal build system).
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>>>
>>>> /Erik
>>>>
>>>
>>
> 


From bren at juanantonio.info  Thu Apr  5 01:26:10 2018
From: bren at juanantonio.info (bren at juanantonio.info)
Date: Thu, 05 Apr 2018 03:26:10 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
Message-ID: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>

Good night David,

It is the first time that I report a Bug on OpenJDK and I didn?t receive 
any notification so I didn?t know the status of the Issue that I 
reported.

Many thanks with the link about the Platforms supported:
http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html

We will try to do Compilation with the solution.

--- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
+++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
@@ -298,6 +298,15 @@
      FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
    }

+ if (arm_arch() == 5) {
+ if (FLAG_IS_DEFAULT(AssumeMP)) {
+ FLAG_SET_DEFAULT(AssumeMP, false);
+ else if (AssumeMP) {
+ warning("AssumeMP can not be true for ARMv5 as there is only 
uniprocessor support");
+ FLAG_SET_DEFAULT(AssumeMP, false);
+ }
+ }
+
    _is_initialized = true;
  }

Runtime workaround: java -XX:-AssumeMP

In our case, I would like to continue maintaining this support for the 
Device.
What is the advice that you could give us?
What is AssumeMP?

For education, this device is pretty interesting for the whole Java 
community, this is the reason.

I will inform with the results.

Many thanks in advance.

Cheers

Juan Antonio

El 2018-04-05 00:12, David Holmes escribi?:
> Hi,
> 
> This was already reported as:
> 
> https://bugs.openjdk.java.net/browse/JDK-8200580
> 
> to which I have responded and closed the bug as this is not a
> supported platform.
> 
> As per the bug report this may be due to the change to AssumeMP to be
> true, but there is no MP support for ARMv5.
> 
> David
> 
> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>> Good morning,
>> 
>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and 
>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we have 
>> found some problems when we execute some Java programs.
>> 
>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>> https://github.com/ev3dev-lang-java/openjdk-ev3
>> 
>> To test the JVM, I am using the following repo to test the VM:
>> https://github.com/ev3dev-lang-java/vmbenchmarks
>> 
>> And this is the output with the error:
>> 
>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>> WARNING: Please consider reporting this to the maintainers of 
>> org.openjdk.jmh.util.Utils
>> WARNING: Use --illegal-access=warn to enable warnings of further 
>> illegal reflective access operations
>> WARNING: All illegal access operations will be denied in a future 
>> release
>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
>> platform ================
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
>> platform ================
>> 
>> [thread 4430 also had an error]
>> [error occurred during error reporting ((null)), id 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing fatal error message), 
>> id 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing type of error), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing stack bounds), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing native stack), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing Java stack), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing target Java thread 
>> stack), id 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing siginfo), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (CDS archive access warning), 
>> id 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [error occurred during error reporting (printing register info), id 
>> 0xe0000000]
>> 
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this 
>> platform ================
>> 
>> 
>> [Too many errors, abort]
>> Aborted
>> 
>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in 
>> relation to ARM5 support.
>> 
>> Any idea?
>> 
>> Many thanks in advance.
>> 
>> Cheers
>> 
>> Juan Antonio
>> 


From martinrb at google.com  Thu Apr  5 01:56:54 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 4 Apr 2018 18:56:54 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <5AC53CF4.10007@oracle.com> <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
Message-ID: <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>

On Wed, Apr 4, 2018 at 5:03 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
>
>>
>> I have to agree. There can't be two bootJDK versions.


I have to disagree.  You could design openjdk to be buildable by any set of
boot JDKs.
It's only the fact that javac happens to be written in java that creates a
boot jdk requirement at all.


From david.holmes at oracle.com  Thu Apr  5 02:01:47 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 12:01:47 +1000
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
 <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
 <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
Message-ID: <bd022f8d-0205-02e9-5440-96e425e17710@oracle.com>

On 5/04/2018 11:56 AM, Martin Buchholz wrote:
> On Wed, Apr 4, 2018 at 5:03 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
> 
> 
>     I have to agree. There can't be two bootJDK versions.
> 
> 
> I have to disagree.? You could design openjdk to be buildable by any set 
> of boot JDKs.
> It's only the fact that javac happens to be written in java that creates 
> a boot jdk requirement at all.

The point is you can't require two different bootJDK versions. As Jon 
said as soon as someone relies on a JDK 10 feature** you can no longer 
use a JDK 9 boot JDK.

** This isn't quite as broad as it sounds. Only critical bootstrapping 
parts of the build are limited to the capabilities of the bootJDK. The 
other parts will be built with the interim javac.

David


From david.holmes at oracle.com  Thu Apr  5 02:23:14 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 12:23:14 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>

On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
> Good night David,
> 
> It is the first time that I report a Bug on OpenJDK and I didn?t receive 
> any notification so I didn?t know the status of the Issue that I reported.

Sorry about that. You should have received some form of notification.

> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
> 
> 
> We will try to do Compilation with the solution.
> 
> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> @@ -298,6 +298,15 @@
>  ???? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>  ?? }
> 
> + if (arm_arch() == 5) {
> + if (FLAG_IS_DEFAULT(AssumeMP)) {
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + else if (AssumeMP) {
> + warning("AssumeMP can not be true for ARMv5 as there is only 
> uniprocessor support");
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + }
> + }
> +
>  ?? _is_initialized = true;
>  ?}
> 
> Runtime workaround: java -XX:-AssumeMP
> 
> In our case, I would like to continue maintaining this support for the 
> Device.
> What is the advice that you could give us?

You would have to keep the local copy of your source code patched and 
produce your own builds. But if you also try to update with the mainline 
OpenJDK code then you will very soon hit problems. In fact I'd be very 
surprised if this works today, even if it builds, as we have not 
provided any updates to ARM32 in a long time. The only supported way to 
run on ARM32 is using the Zero interpreter as Adrian replied.

> What is AssumeMP?

Assume Multi-Processor.

When running on a MP system the VM has to use and generate code that 
provides the correct level of atomicity and memory consistency - none of 
which is necessary on a uniprocessor system. MP systems are the norm and 
in the rare case we issue the additional memory synchronization 
instructions they should be no-ops on a uniprocessor, so we are heading 
towards stripping out uniprocessor support and only build in MP support 
so that we don't need dynamic checks through the code to see if we are 
MP or not. Switching AssumeMP to true was the first step in that process 
(and avoided problems where the VM may be started with only one 
processor available but then had additional ones added later.)

In any case there has never been any support for ARMv5 multiprocessors.

Cheers,
David

> For education, this device is pretty interesting for the whole Java 
> community, this is the reason.


> I will inform with the results.
> 
> Many thanks in advance.
> 
> Cheers
> 
> Juan Antonio
> 
> El 2018-04-05 00:12, David Holmes escribi?:
>> Hi,
>>
>> This was already reported as:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>
>> to which I have responded and closed the bug as this is not a
>> supported platform.
>>
>> As per the bug report this may be due to the change to AssumeMP to be
>> true, but there is no MP support for ARMv5.
>>
>> David
>>
>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>> Good morning,
>>>
>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and 
>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we 
>>> have found some problems when we execute some Java programs.
>>>
>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>
>>> To test the JVM, I am using the following repo to test the VM:
>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>
>>> And this is the output with the error:
>>>
>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>> WARNING: An illegal reflective access operation has occurred
>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>> WARNING: Please consider reporting this to the maintainers of 
>>> org.openjdk.jmh.util.Utils
>>> WARNING: Use --illegal-access=warn to enable warnings of further 
>>> illegal reflective access operations
>>> WARNING: All illegal access operations will be denied in a future 
>>> release
>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
>>> platform ================
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this 
>>> platform ================
>>>
>>> [thread 4430 also had an error]
>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing fatal error 
>>> message), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing type of error), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing stack bounds), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing native stack), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing Java stack), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing target Java thread 
>>> stack), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing siginfo), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (CDS archive access warning), 
>>> id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing register info), id 
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>> this platform ================
>>>
>>>
>>> [Too many errors, abort]
>>> Aborted
>>>
>>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in 
>>> relation to ARM5 support.
>>>
>>> Any idea?
>>>
>>> Many thanks in advance.
>>>
>>> Cheers
>>>
>>> Juan Antonio
>>>


From bren at juanantonio.info  Thu Apr  5 03:30:57 2018
From: bren at juanantonio.info (bren at juanantonio.info)
Date: Thu, 05 Apr 2018 05:30:57 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
Message-ID: <4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>

Hi David,

Many thanks for the comments.

In relation to the ARMV5 support, in the past Oracle released a version 
for Mindstorms:
http://www.oracle.com/technetwork/java/embedded/downloads/javase/javaseemeddedev3-1982511.html

but if you observe that release was Java 8.

For Java 9, we could build JDK and JRI (Java Runtime Images)
https://github.com/ev3dev-lang-java/openjdk-ev3/releases/tag/v0.4.5

I wish with your local path suggestion, we could build OpenJDK 10.
Later, we will try with OpenJDK11.

I have to see how to automate the whole process on Travis CI.

Cheers

Juan Antonio

El 2018-04-05 04:23, David Holmes escribi?:
> On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
>> Good night David,
>> 
>> It is the first time that I report a Bug on OpenJDK and I didn?t 
>> receive any notification so I didn?t know the status of the Issue that 
>> I reported.
> 
> Sorry about that. You should have received some form of notification.
> 
>> Many thanks with the link about the Platforms supported:
>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
>> We will try to do Compilation with the solution.
>> 
>> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>> @@ -298,6 +298,15 @@
>>  ???? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>>  ?? }
>> 
>> + if (arm_arch() == 5) {
>> + if (FLAG_IS_DEFAULT(AssumeMP)) {
>> + FLAG_SET_DEFAULT(AssumeMP, false);
>> + else if (AssumeMP) {
>> + warning("AssumeMP can not be true for ARMv5 as there is only 
>> uniprocessor support");
>> + FLAG_SET_DEFAULT(AssumeMP, false);
>> + }
>> + }
>> +
>>  ?? _is_initialized = true;
>>  ?}
>> 
>> Runtime workaround: java -XX:-AssumeMP
>> 
>> In our case, I would like to continue maintaining this support for the 
>> Device.
>> What is the advice that you could give us?
> 
> You would have to keep the local copy of your source code patched and
> produce your own builds. But if you also try to update with the
> mainline OpenJDK code then you will very soon hit problems. In fact
> I'd be very surprised if this works today, even if it builds, as we
> have not provided any updates to ARM32 in a long time. The only
> supported way to run on ARM32 is using the Zero interpreter as Adrian
> replied.
> 
>> What is AssumeMP?
> 
> Assume Multi-Processor.
> 
> When running on a MP system the VM has to use and generate code that
> provides the correct level of atomicity and memory consistency - none
> of which is necessary on a uniprocessor system. MP systems are the
> norm and in the rare case we issue the additional memory
> synchronization instructions they should be no-ops on a uniprocessor,
> so we are heading towards stripping out uniprocessor support and only
> build in MP support so that we don't need dynamic checks through the
> code to see if we are MP or not. Switching AssumeMP to true was the
> first step in that process (and avoided problems where the VM may be
> started with only one processor available but then had additional ones
> added later.)
> 
> In any case there has never been any support for ARMv5 multiprocessors.
> 
> Cheers,
> David
> 
>> For education, this device is pretty interesting for the whole Java 
>> community, this is the reason.
> 
> 
>> I will inform with the results.
>> 
>> Many thanks in advance.
>> 
>> Cheers
>> 
>> Juan Antonio
>> 
>> El 2018-04-05 00:12, David Holmes escribi?:
>>> Hi,
>>> 
>>> This was already reported as:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>> 
>>> to which I have responded and closed the bug as this is not a
>>> supported platform.
>>> 
>>> As per the bug report this may be due to the change to AssumeMP to be
>>> true, but there is no MP support for ARMv5.
>>> 
>>> David
>>> 
>>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>>> Good morning,
>>>> 
>>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
>>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and 
>>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we 
>>>> have found some problems when we execute some Java programs.
>>>> 
>>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>> 
>>>> To test the JVM, I am using the following repo to test the VM:
>>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>> 
>>>> And this is the output with the error:
>>>> 
>>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>>> WARNING: An illegal reflective access operation has occurred
>>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
>>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>>> WARNING: Please consider reporting this to the maintainers of 
>>>> org.openjdk.jmh.util.Utils
>>>> WARNING: Use --illegal-access=warn to enable warnings of further 
>>>> illegal reflective access operations
>>>> WARNING: All illegal access operations will be denied in a future 
>>>> release
>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> [thread 4430 also had an error]
>>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing fatal error 
>>>> message), id 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing type of error), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing stack bounds), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing native stack), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing Java stack), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing target Java thread 
>>>> stack), id 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing siginfo), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (CDS archive access warning), 
>>>> id 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [error occurred during error reporting (printing register info), id 
>>>> 0xe0000000]
>>>> 
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>> this platform ================
>>>> 
>>>> 
>>>> [Too many errors, abort]
>>>> Aborted
>>>> 
>>>> I think that in OpenJDK10 changed something in compare to OpenJDK9 
>>>> in relation to ARM5 support.
>>>> 
>>>> Any idea?
>>>> 
>>>> Many thanks in advance.
>>>> 
>>>> Cheers
>>>> 
>>>> Juan Antonio
>>>> 


From david.holmes at oracle.com  Thu Apr  5 03:39:19 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 13:39:19 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
 <4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>
Message-ID: <6d3224d7-edcb-56a9-81f0-04317277d367@oracle.com>

On 5/04/2018 1:30 PM, bren at juanantonio.info wrote:
> Hi David,
> 
> Many thanks for the comments.
> 
> In relation to the ARMV5 support, in the past Oracle released a version 
> for Mindstorms:
> http://www.oracle.com/technetwork/java/embedded/downloads/javase/javaseemeddedev3-1982511.html 
> 
> 
> but if you observe that release was Java 8.

Yes we started scaling back Java SE Embedded after 8 GA. Later 8u 
versions do not support the same set of platforms. Java SE Embedded does 
not exist in 9+

David
-----

> For Java 9, we could build JDK and JRI (Java Runtime Images)
> https://github.com/ev3dev-lang-java/openjdk-ev3/releases/tag/v0.4.5
> 
> I wish with your local path suggestion, we could build OpenJDK 10.
> Later, we will try with OpenJDK11.
> 
> I have to see how to automate the whole process on Travis CI.
> 
> Cheers
> 
> Juan Antonio
> 
> El 2018-04-05 04:23, David Holmes escribi?:
>> On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
>>> Good night David,
>>>
>>> It is the first time that I report a Bug on OpenJDK and I didn?t 
>>> receive any notification so I didn?t know the status of the Issue 
>>> that I reported.
>>
>> Sorry about that. You should have received some form of notification.
>>
>>> Many thanks with the link about the Platforms supported:
>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
>>> We will try to do Compilation with the solution.
>>>
>>> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>>> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>>> @@ -298,6 +298,15 @@
>>> ????? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>>> ??? }
>>>
>>> + if (arm_arch() == 5) {
>>> + if (FLAG_IS_DEFAULT(AssumeMP)) {
>>> + FLAG_SET_DEFAULT(AssumeMP, false);
>>> + else if (AssumeMP) {
>>> + warning("AssumeMP can not be true for ARMv5 as there is only 
>>> uniprocessor support");
>>> + FLAG_SET_DEFAULT(AssumeMP, false);
>>> + }
>>> + }
>>> +
>>> ??? _is_initialized = true;
>>> ??}
>>>
>>> Runtime workaround: java -XX:-AssumeMP
>>>
>>> In our case, I would like to continue maintaining this support for 
>>> the Device.
>>> What is the advice that you could give us?
>>
>> You would have to keep the local copy of your source code patched and
>> produce your own builds. But if you also try to update with the
>> mainline OpenJDK code then you will very soon hit problems. In fact
>> I'd be very surprised if this works today, even if it builds, as we
>> have not provided any updates to ARM32 in a long time. The only
>> supported way to run on ARM32 is using the Zero interpreter as Adrian
>> replied.
>>
>>> What is AssumeMP?
>>
>> Assume Multi-Processor.
>>
>> When running on a MP system the VM has to use and generate code that
>> provides the correct level of atomicity and memory consistency - none
>> of which is necessary on a uniprocessor system. MP systems are the
>> norm and in the rare case we issue the additional memory
>> synchronization instructions they should be no-ops on a uniprocessor,
>> so we are heading towards stripping out uniprocessor support and only
>> build in MP support so that we don't need dynamic checks through the
>> code to see if we are MP or not. Switching AssumeMP to true was the
>> first step in that process (and avoided problems where the VM may be
>> started with only one processor available but then had additional ones
>> added later.)
>>
>> In any case there has never been any support for ARMv5 multiprocessors.
>>
>> Cheers,
>> David
>>
>>> For education, this device is pretty interesting for the whole Java 
>>> community, this is the reason.
>>
>>
>>> I will inform with the results.
>>>
>>> Many thanks in advance.
>>>
>>> Cheers
>>>
>>> Juan Antonio
>>>
>>> El 2018-04-05 00:12, David Holmes escribi?:
>>>> Hi,
>>>>
>>>> This was already reported as:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>>>
>>>> to which I have responded and closed the bug as this is not a
>>>> supported platform.
>>>>
>>>> As per the bug report this may be due to the change to AssumeMP to be
>>>> true, but there is no MP support for ARMv5.
>>>>
>>>> David
>>>>
>>>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>>>> Good morning,
>>>>>
>>>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java 
>>>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and 
>>>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we 
>>>>> have found some problems when we execute some Java programs.
>>>>>
>>>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>>>
>>>>> To test the JVM, I am using the following repo to test the VM:
>>>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>>>
>>>>> And this is the output with the error:
>>>>>
>>>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>>>> WARNING: An illegal reflective access operation has occurred
>>>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils 
>>>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>>>> WARNING: Please consider reporting this to the maintainers of 
>>>>> org.openjdk.jmh.util.Utils
>>>>> WARNING: Use --illegal-access=warn to enable warnings of further 
>>>>> illegal reflective access operations
>>>>> WARNING: All illegal access operations will be denied in a future 
>>>>> release
>>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>> [thread 4430 also had an error]
>>>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing fatal error 
>>>>> message), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing type of error), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing stack bounds), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing native stack), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing Java stack), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing target Java thread 
>>>>> stack), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing siginfo), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (CDS archive access 
>>>>> warning), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing register info), id 
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on 
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [Too many errors, abort]
>>>>> Aborted
>>>>>
>>>>> I think that in OpenJDK10 changed something in compare to OpenJDK9 
>>>>> in relation to ARM5 support.
>>>>>
>>>>> Any idea?
>>>>>
>>>>> Many thanks in advance.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Juan Antonio
>>>>>


From magnus.ihse.bursie at oracle.com  Thu Apr  5 07:00:03 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 09:00:03 +0200
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <bd022f8d-0205-02e9-5440-96e425e17710@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
 <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
 <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
 <bd022f8d-0205-02e9-5440-96e425e17710@oracle.com>
Message-ID: <86652a19-fdb0-4ee9-c274-f06251af0f91@oracle.com>

On 2018-04-05 04:01, David Holmes wrote:
> On 5/04/2018 11:56 AM, Martin Buchholz wrote:
>> On Wed, Apr 4, 2018 at 5:03 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
>>
>>
>> ??? I have to agree. There can't be two bootJDK versions.
>>
>>
>> I have to disagree.? You could design openjdk to be buildable by any 
>> set of boot JDKs.
>> It's only the fact that javac happens to be written in java that 
>> creates a boot jdk requirement at all.
>
> The point is you can't require two different bootJDK versions. As Jon 
> said as soon as someone relies on a JDK 10 feature** you can no longer 
> use a JDK 9 boot JDK.

So why don't we do a compromise?

Let configure accept JDK 9 or JDK 10 as boot JDK. But if JDK 9 is 
selected, a warning is display that this might not work. At some point 
in time, changes may happen in javac code that will prohibit this from 
working. But up until that point, it is still possible to use JDK 9 to 
build JDK 11, so we do not hinder that upfront in configure.

This makes it clear that you are supposed to use JDK 10. But it will 
still allow the community time to adjust. And it will not hamper the 
javac development.

Reasonable?

/Magnus



>
> ** This isn't quite as broad as it sounds. Only critical bootstrapping 
> parts of the build are limited to the capabilities of the bootJDK. The 
> other parts will be built with the interim javac.
>
> David



From Alan.Bateman at oracle.com  Thu Apr  5 08:18:09 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 5 Apr 2018 09:18:09 +0100
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <5AC53CF4.10007@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
Message-ID: <810430b0-ca38-1812-6061-233c39abd4e5@oracle.com>

On 04/04/2018 22:00, Jonathan Gibbons wrote:
> Erik,
>
> Why bother?? What are you trying to achieve?
>
> Either the boot JDK is JDK 9, or it is JDK 10.? This should be a clear 
> decision.
>
> If internally at Oracle, we use 10, then as soon as code creeps in 
> that relies on 10 features, we've broken the commitment to the 
> community for allowing 9 as a boot JDK.
I agree, it's asking for trouble to have some people using JDK N-2 as 
the boot JDK, others using JDK N-1. This is on top of keeping boot cycle 
builds working where JDK N rebuilds itself, keeping the jrtfs and jimage 
support classes buildable with --release 8, and all the other build 
complexities. Using JDK N-1 as the boot JDK for the mainstream ports is 
hardly a burden as the required boot JDK is readily available. I could 
imagine it might be awkward for some ports that don't cross build but 
surely that shouldn't dictate how the mainstream builds.

-Alan


From david.holmes at oracle.com  Thu Apr  5 08:30:36 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 18:30:36 +1000
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
Message-ID: <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>

On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
> 
> 
> On 2018-04-04 09:59, David Holmes wrote:
>> Hi Magnus,
>>
>> Sorry for the delay ...
>>
>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>
>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>> Hi Magnus,
>>>>
>>>> just a cursory look, will look in greater detail tomorrow.
>>>>
>>>> This is good, thanks for doing this.
>>>>
>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>> "workarounds". I do not know why we did this - the original code is 
>>>> quite old - my assumption is that dlsym(RTLD_NEXT) was not working 
>>>> as expected on older AIX versions. Well, it should work now 
>>>> according to IBMs manpages. Will test later.
>>> Ok.
>>>>
>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>> instead, which is more portable.
>>>
>>> I have surrounded this code with #ifdef MACOSX now.
>>>
>>> Here is an updated webrev. It includes the changes requested by you 
>>> and David:
>>>
>>> * No more AIX workarounds
>>> * Solaris use pthreads
>>> * The "reentry" code is #ifdef MACOSX.
>>
>> That all seems good.
> Good. :)
> 
>>
>>> I also assumed that NSIG is available and working on Solaris. I'll 
>>> let David decide if he is happy with that. The alternative is to go 
>>> back to the Solaris-specific code that allocates sact on the heap.
>>
>> Unfortunately NSIG is a problem on Solaris:
>>
>> http://austingroupbugs.net/view.php?id=741
>>
>> It's use also precludes the use of the real-time signals - which 
>> limits Linux as well. But I'm not completely clear on exactly how 
>> signals may be numbered in their entirety so I wouldn't necessarily 
>> suggest trying to use SIGRTMAX+1 as the number of available signals, 
>> other than on Solaris.
> Ok. I hope I understand you correctly. I have replaced NSIG with 
> MAX_SIGNALS, which is defined as NSIG on all platforms except Solaris, 
> where it is defined as SIGRTMAX+1.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
> 
> (8th time's a charm..?)

Nope - you can't use SIGRTMAX+1 to allocate a static array as it is not 
a constant expression. That's why Solaris uses malloc.

David


> /Magnus
> 
>>
>> Thanks,
>> David
>>
>>> Webrev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>>
>>> Once again, here is also a webrev that shows the difference between 
>>> the original files and the new, unified file. Even if it's hard to 
>>> read, it shows what the effects will be for each platform.
>>>
>>> Webrev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
>>>
>>> /Magnus
>>>
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>> <magnus.ihse.bursie at oracle.com 
>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>
>>>> ??? When I was about to update jsig.c, I noticed that the four copies
>>>> ??? for aix, linux, macosx and solaris were basically the same, with
>>>> ??? only small differences. Some of the differences were not even well
>>>> ??? motivated, but were likely the result of this code duplication
>>>> ??? causing the code to diverge.
>>>>
>>>> ??? A better solution is to unify them all into a single unix version,
>>>> ??? with the few platform-specific changes handled on a per-platform
>>>> ??? basis.
>>>>
>>>> ??? I've made the following notable changes:
>>>>
>>>> ??? * I have removed the version check for Solaris. All other
>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>> ??? version check to all other platforms instead. If you think this is
>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>
>>>> ??? * Solaris used to have a dynamically allocated sact, instead of a
>>>> ??? statically allocated array as all other platforms have. It's not
>>>> ??? likely to be large, and the size is known at compile time, so
>>>> ??? there seems to be no good reason for this.
>>>>
>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>> ??? solution, and the added checks show that it has failed in the
>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>
>>>> ??? Also worth noting:
>>>>
>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>
>>>> ??? * In general, if an implementation was needed on one platform, but
>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>
>>>> ??? To facilitate code review, here is a specially crafted webrev that
>>>> ??? shows the differences compared to each of the individual, original
>>>> ??? per-OS versions of jsig.c:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>
>>>>
>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>> ??? <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>> ??? WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>
>>>>
>>>> ??? /Magnus
>>>>
>>>>
>>>
> 


From magnus.ihse.bursie at oracle.com  Thu Apr  5 08:07:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 10:07:23 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
Message-ID: <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>



On 2018-04-04 09:59, David Holmes wrote:
> Hi Magnus,
>
> Sorry for the delay ...
>
> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>
>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>> Hi Magnus,
>>>
>>> just a cursory look, will look in greater detail tomorrow.
>>>
>>> This is good, thanks for doing this.
>>>
>>> As I wrote offlist, please remove the painfully wrong AIX 
>>> "workarounds". I do not know why we did this - the original code is 
>>> quite old - my assumption is that dlsym(RTLD_NEXT) was not working 
>>> as expected on older AIX versions. Well, it should work now 
>>> according to IBMs manpages. Will test later.
>> Ok.
>>>
>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>> instead, which is more portable.
>>
>> I have surrounded this code with #ifdef MACOSX now.
>>
>> Here is an updated webrev. It includes the changes requested by you 
>> and David:
>>
>> * No more AIX workarounds
>> * Solaris use pthreads
>> * The "reentry" code is #ifdef MACOSX.
>
> That all seems good.
Good. :)

>
>> I also assumed that NSIG is available and working on Solaris. I'll 
>> let David decide if he is happy with that. The alternative is to go 
>> back to the Solaris-specific code that allocates sact on the heap.
>
> Unfortunately NSIG is a problem on Solaris:
>
> http://austingroupbugs.net/view.php?id=741
>
> It's use also precludes the use of the real-time signals - which 
> limits Linux as well. But I'm not completely clear on exactly how 
> signals may be numbered in their entirety so I wouldn't necessarily 
> suggest trying to use SIGRTMAX+1 as the number of available signals, 
> other than on Solaris.
Ok. I hope I understand you correctly. I have replaced NSIG with 
MAX_SIGNALS, which is defined as NSIG on all platforms except Solaris, 
where it is defined as SIGRTMAX+1.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08

(8th time's a charm..?)

/Magnus

>
> Thanks,
> David
>
>> Webrev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>
>> Once again, here is also a webrev that shows the difference between 
>> the original files and the new, unified file. Even if it's hard to 
>> read, it shows what the effects will be for each platform.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
>>
>> /Magnus
>>
>>>
>>> Thanks!
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com 
>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>
>>> ??? When I was about to update jsig.c, I noticed that the four copies
>>> ??? for aix, linux, macosx and solaris were basically the same, with
>>> ??? only small differences. Some of the differences were not even well
>>> ??? motivated, but were likely the result of this code duplication
>>> ??? causing the code to diverge.
>>>
>>> ??? A better solution is to unify them all into a single unix version,
>>> ??? with the few platform-specific changes handled on a per-platform
>>> ??? basis.
>>>
>>> ??? I've made the following notable changes:
>>>
>>> ??? * I have removed the version check for Solaris. All other
>>> ??? platforms seem to do fine without it, and in general, we don't
>>> ??? mistrust other JDK libraries. An alternative is to add this
>>> ??? version check to all other platforms instead. If you think this is
>>> ??? the correct course of action, let me know and I'll fix it.
>>>
>>> ??? * Solaris used to have a dynamically allocated sact, instead of a
>>> ??? statically allocated array as all other platforms have. It's not
>>> ??? likely to be large, and the size is known at compile time, so
>>> ??? there seems to be no good reason for this.
>>>
>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>> ??? solution, and the added checks show that it has failed in the
>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>
>>> ??? Also worth noting:
>>>
>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>
>>> ??? * In general, if an implementation was needed on one platform, but
>>> ??? has no effect or is harmless on others, I've kept it on all
>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>
>>> ??? To facilitate code review, here is a specially crafted webrev that
>>> ??? shows the differences compared to each of the individual, original
>>> ??? per-OS versions of jsig.c:
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01>
>>>
>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>> ??? <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>> ??? WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03>
>>>
>>> ??? /Magnus
>>>
>>>
>>



From magnus.ihse.bursie at oracle.com  Thu Apr  5 08:45:05 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 10:45:05 +0200
Subject: RFR: JDK-8199539: Provide a standard way for the build to filter
 un-needed legal .md files
In-Reply-To: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>
References: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>
Message-ID: <c04f6f07-95e6-6ae3-9f09-8283ba9d7b23@oracle.com>

On 2018-04-05 01:06, Erik Joelsson wrote:
> When bundling legal files, we need to filter them according to what 
> 3rd party components are actually included in the build. Several 
> components, such as zlib, libjpeg and freetype can be linked with 
> system libraries instead, and if so, we should also exclude the legal 
> files for that component.
>
> This patch introduces a optional copy/filter step in the <module>-copy 
> targets. Since there are only two affected modules at this time I 
> didn't bother unifying this into one implementation. Instead the short 
> logic is duplicated between the two.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>
> Webrev: http://cr.openjdk.java.net/~erikj/8199539/webrev.01/index.html
Looks good to me.

/Magnus
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>
> /Erik
>



From kevin.walls at oracle.com  Thu Apr  5 08:46:18 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 5 Apr 2018 09:46:18 +0100
Subject: RFR (8u): 8034788: Rewrite toolchain.m4 to support multiple
 toolchains per platform
Message-ID: <3d07a97c-e879-bfbe-33e2-fe19e7502795@oracle.com>

Hi,

I'd like to get a technical review of a backport to jdk8u:

8034788: Rewrite toolchain.m4 to support multiple toolchains per platform
JBS: https://bugs.openjdk.java.net/browse/JDK-8034788
9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/rev/b18872ff5379

8u webrev: http://cr.openjdk.java.net/~kevinw/8034788/webrev.00/

toolchain.m4 did not import, lots of manual changes there, most other 
files imported OK.

This change adds flags.m4 which we have in 9, but not in 8 until now. 
When 8151841 happened in 8u ( 
http://closedjdk.us.oracle.com/jdk8u/jdk8u-cpu/rev/73494e6ff8e5 ) it 
worked with toolchain.m4, and didn't create flags.m4.? But doing 8034788 
now, I wanted to bring 8 and 9 closer together, to make further changes 
easier, so I add flags.m4, and e.g. FLAGS_SETUP_GCC6_COMPILER_FLAGS 
moves to flags.m4.

(I updated copyright years after creating the webrev.)

Thanks
Kevin



From magnus.ihse.bursie at oracle.com  Thu Apr  5 09:16:20 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 11:16:20 +0200
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <19023a7d-6374-6a0d-77d8-0b9920add1e8@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
 <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>
 <ede6f1ed-0677-0375-df31-1df27dc69f2a@oracle.com>
 <19023a7d-6374-6a0d-77d8-0b9920add1e8@oracle.com>
Message-ID: <fb914764-cb77-a928-79bf-c16a4ff648f8@oracle.com>

On 2018-04-04 17:25, Erik Joelsson wrote:
>
> On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
>> On 2018-04-03 23:16, Erik Joelsson wrote:
>>> Looks good to me at least. Exporting symbols from executables seems 
>>> wrong so applying hidden as default seems good to me.
>> Unfortunately, it was not this easy. :-(
>>
>> Out of paranoia, I also started a test run on Windows, even though it 
>> should not have been affected. Well, "should not". The added 
>> JNIEXPORT turns into a __declspec(dllexport) on Windows, which causes 
>> the Microsoft linker to behave like when linking a dll, so it creates 
>> a .lib and .exp for each binary, in the bin directory.
>>
>> *sigh*
>>
>> I see two ways out of this.
>>
>> 1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
>> main function, or by declaring something like EXEC_EXPORT instead, 
>> and let it be empty on Windows.
>>
>> 2) Let the part of SetupNativeCompilation that handles executables 
>> behave more like the one for shared libraries, and setting -implib, 
>> etc. I'm not sure what happens if you pass in -implib when linking an 
>> executable which does *not* have any dllexport decorations. If it 
>> breaks, then this does not really seem like a way forward. Otherwise, 
>> it's probably the safest choice, since it will make sure we never 
>> leak any *.lib or *.exp for a potential future executable.
>>
>> What do you think?
>>
> I really don't know which I would prefer. Would be good to find out 
> what happens in 2.

Turns out that -implib is just ignored if not needed, so 2 is clearly 
the way to go.

This also meant that there was much overlap between the linking of 
shared libraries and executables in SetupNativeCompilation, so I 
(finally) took the time to unify them.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.03
(Only changes NativeCompilation.gmk)

/Magnus


>
> /Erik



From magnus.ihse.bursie at oracle.com  Thu Apr  5 09:31:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 11:31:54 +0200
Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager
In-Reply-To: <9ffc644d-1a2e-b4f0-4cf9-873e9b384bcf@oracle.com>
References: <f4684695-0fbf-5d75-9347-74bbc5549f47@oracle.com>
 <d850cfac-9341-00c5-5fa7-5ad6e77435fe@oracle.com>
 <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com>
 <5e0871d1-41c8-a0bb-cecb-dbb084934b27@oracle.com>
 <9ffc644d-1a2e-b4f0-4cf9-873e9b384bcf@oracle.com>
Message-ID: <6100ac6f-8a38-fa19-3afc-cf53739cddf8@oracle.com>

On 2018-03-14 22:17, Magnus Ihse Bursie wrote:
>
> On 2018-03-14 22:05, Phil Race wrote:
>>
>> >I see we used to link with libawt_headless for solaris, but removed 
>> it in >JDK-8194870. Phil remarked in that bug: "We linked against 
>> headless before then >but allowed undefined symbols JDK 9 switched 
>> this to libawt_headless when >headless apps failed." but I'm not sure 
>> I understand what this really means.
>>
>> It means that there is a long and sordid history.
>> When we introduced this code it was as it is now.
>> Some time in JDK 8 (?) it started to link against one of these libs.
>> I'd have to go back and check which one, but definitely in JDK 9 a bug
>> popped up with headless because of explicit linking to xawt .. which
>> pulls in X11. At that time the fix was to switch it to link against 
>> headless
>> but that was the wrong fix now as it is then. Somehow it worked OK 
>> though
>> as had the xawt linking so long as you had X11 .. until JDK-8194870 and
>> we realised the error. Now we are back to how it was intended in JDK 
>> 1.5 (I think).
> Thank you for the explanation!
>
> I will think about this fix for a while, and see what I can do about 
> it. For now, consider the review request cancelled.

I still need to think about how to handle the solaris case, but at least 
I can salvage the macosx cleanup from this patch.

I have verified functionality using "java -jar SwingSet2.jar" on a 
macosx machine.

Updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.02

/Magnus


>
> /Magnus
>
>>
>> > Question to Phil: Would it be possible to rewrite the code to load 
>> and reference the symbols dynamically
>>
>> Whilst it probably is possible, I really don't want to do that it is not
>> really in the spirit of what is intended here as well as being a fair 
>> amount of work.
>> This is not an "optional" library. It has to be there. We just don't 
>> know which one
>> until runtime.
>> What I'd really like here is a build linker option that at build time 
>> verifies
>> that the dependencies are actually satisfied by each of xawt and 
>> headless in turn
>> but in neither case writes that library into the produced image as a 
>> dependency.
>>
>> For the macos changes, I am supposing you mean you had to add this
>> + LIBS_macosx := -lawt_lwawt -framework CoreText -framework 
>> CoreFoundation \
>>
>> because you removed this
>>
>> - LDFLAGS_macosx := -undefined dynamic_lookup, \
>>
>> If it builds *and runs* its probably fine :-)
>>
>> Only Solaris + Linux have separate libraries for headful + headless.
>>
>> -phil.
>>
>> On 03/14/2018 01:22 PM, Magnus Ihse Bursie wrote:
>>> On 2018-03-14 15:59, Erik Joelsson wrote:
>>>> This change is unfortunately not correct for Linux and Solaris. We 
>>>> cannot link libfontmanager explicitly against either libawt_xawt or 
>>>> libawt_headless. See 
>>>> https://bugs.openjdk.java.net/browse/JDK-8196516 for my suggestion 
>>>> on a better fix than we currently have. I was hoping for Severin to 
>>>> check it out and pick it up, but he is away for a bit so that 
>>>> hasn't happened.
>>>>
>>>> The reason we cannot link explicitly is that we need to decide at 
>>>> runtime whether to pull in the headful or headless libraries. If 
>>>> one or the other is already pulled in, and we explicitly load the 
>>>> other, the runtime linker will lookup the common symbols in one or 
>>>> the other in an unpredictable way. Some users get the correct 
>>>> behavior, some get the wrong behavior. We recently had discussions 
>>>> around this on this list if you want to dive deeper into it.
>>>>
>>>> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one 
>>>> of the consequences of explicit linking here.
>>>>
>>>> I think the mac part is ok though, but Phil has to have a look. For 
>>>> Linux and Solaris, if you could remove the -lawt_headless and add 
>>>> "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for linux I 
>>>> think we should be good.
>>> Oh, this seems like a fine mess. :-(
>>>
>>> I see we used to link with libawt_headless for solaris, but removed 
>>> it in JDK-8194870. Phil remarked in that bug: "We linked against 
>>> headless before then but allowed undefined symbols JDK 9 switched 
>>> this to libawt_headless when headless apps failed." but I'm not sure 
>>> I understand what this really means.
>>>
>>> I agree it seems likely that the macosx changes is correct. I could 
>>> probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, 
>>> but that is unlikely to work on solstudio. :-( So I'm afraid we're 
>>> still stuck with the need to remove -z defs for some builds. :-(
>>>
>>> Question to Phil: Would it be possible to rewrite the code to load 
>>> and reference the symbols dynamically, using libdl? The problem here 
>>> is that the functions are declared extern, instead of loaded into a 
>>> function pointer at runtime. That's how you typically use this kind 
>>> of runtime-determined dynamic loading.
>>>
>>> /Magnus
>>>>
>>>> /Erik
>>>>
>>>> On 2018-03-14 04:45, Magnus Ihse Bursie wrote:
>>>>> This is the final LDFLAGS cleanup, which required some more work 
>>>>> to resolve.
>>>>>
>>>>> Libfontmanager had previously explicitely disabled -z defs, with 
>>>>> the result that linking did not complain about missing libraries. 
>>>>> To fix this, I had to provide the proper libraries to link with. 
>>>>> For linux and solaris, this was libawt_headless. For macosx, this 
>>>>> was libawt_lwawt, but also three system frameworks.
>>>>>
>>>>> Note that this patch has a merge conflict with JDK-8199606. The 
>>>>> end result of both patches are shown in the patch (that is, with 
>>>>> -lc removed). I will make sure to resolve the conflicts properly 
>>>>> when committing this patch.
>>>>>
>>>>> I have run COMPARE_BUILDS, with expected results. That is, no 
>>>>> changes for Windows, and a deps change for macosx, linux and 
>>>>> solaris. I also got a symbol change for linux, since the symbols 
>>>>> from libawt_headless changed from e.g. "AWTCharAdvance" to 
>>>>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do 
>>>>> linking changes, you also end up getting binary/disasm changes.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01
>>>>>
>>>>
>>>
>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr  5 09:52:31 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 11:52:31 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
Message-ID: <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>

On 2018-04-05 10:30, David Holmes wrote:
> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-04-04 09:59, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> Sorry for the delay ...
>>>
>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>
>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>
>>>>> This is good, thanks for doing this.
>>>>>
>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>> "workarounds". I do not know why we did this - the original code 
>>>>> is quite old - my assumption is that dlsym(RTLD_NEXT) was not 
>>>>> working as expected on older AIX versions. Well, it should work 
>>>>> now according to IBMs manpages. Will test later.
>>>> Ok.
>>>>>
>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>> instead, which is more portable.
>>>>
>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>
>>>> Here is an updated webrev. It includes the changes requested by you 
>>>> and David:
>>>>
>>>> * No more AIX workarounds
>>>> * Solaris use pthreads
>>>> * The "reentry" code is #ifdef MACOSX.
>>>
>>> That all seems good.
>> Good. :)
>>
>>>
>>>> I also assumed that NSIG is available and working on Solaris. I'll 
>>>> let David decide if he is happy with that. The alternative is to go 
>>>> back to the Solaris-specific code that allocates sact on the heap.
>>>
>>> Unfortunately NSIG is a problem on Solaris:
>>>
>>> http://austingroupbugs.net/view.php?id=741
>>>
>>> It's use also precludes the use of the real-time signals - which 
>>> limits Linux as well. But I'm not completely clear on exactly how 
>>> signals may be numbered in their entirety so I wouldn't necessarily 
>>> suggest trying to use SIGRTMAX+1 as the number of available signals, 
>>> other than on Solaris.
>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>> Solaris, where it is defined as SIGRTMAX+1.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>
>> (8th time's a charm..?)
>
> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
> not a constant expression. That's why Solaris uses malloc.

Duh. Right.

Oooookay. Like this, then?

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09

I have restored the calls to allocate_sact() in the same locations as in 
the original solaris version. Hopefully, those are correct. :-)

/Magnus
>
> David
>
>
>> /Magnus
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>>>
>>>> Once again, here is also a webrev that shows the difference between 
>>>> the original files and the new, unified file. Even if it's hard to 
>>>> read, it shows what the effects will be for each platform.
>>>>
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>> <magnus.ihse.bursie at oracle.com 
>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>
>>>>> ??? When I was about to update jsig.c, I noticed that the four copies
>>>>> ??? for aix, linux, macosx and solaris were basically the same, with
>>>>> ??? only small differences. Some of the differences were not even 
>>>>> well
>>>>> ??? motivated, but were likely the result of this code duplication
>>>>> ??? causing the code to diverge.
>>>>>
>>>>> ??? A better solution is to unify them all into a single unix 
>>>>> version,
>>>>> ??? with the few platform-specific changes handled on a per-platform
>>>>> ??? basis.
>>>>>
>>>>> ??? I've made the following notable changes:
>>>>>
>>>>> ??? * I have removed the version check for Solaris. All other
>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>> ??? version check to all other platforms instead. If you think 
>>>>> this is
>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>
>>>>> ??? * Solaris used to have a dynamically allocated sact, instead of a
>>>>> ??? statically allocated array as all other platforms have. It's not
>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>> ??? there seems to be no good reason for this.
>>>>>
>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>> ??? solution, and the added checks show that it has failed in the
>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>
>>>>> ??? Also worth noting:
>>>>>
>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>
>>>>> ??? * In general, if an implementation was needed on one platform, 
>>>>> but
>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>
>>>>> ??? To facilitate code review, here is a specially crafted webrev 
>>>>> that
>>>>> ??? shows the differences compared to each of the individual, 
>>>>> original
>>>>> ??? per-OS versions of jsig.c:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>
>>>>>
>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>> ??? WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>
>>>>>
>>>>> ??? /Magnus
>>>>>
>>>>>
>>>>
>>



From david.holmes at oracle.com  Thu Apr  5 10:30:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 20:30:10 +1000
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
Message-ID: <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>

On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
> On 2018-04-05 10:30, David Holmes wrote:
>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-04-04 09:59, David Holmes wrote:
>>>> Hi Magnus,
>>>>
>>>> Sorry for the delay ...
>>>>
>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>
>>>>>> This is good, thanks for doing this.
>>>>>>
>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>> "workarounds". I do not know why we did this - the original code 
>>>>>> is quite old - my assumption is that dlsym(RTLD_NEXT) was not 
>>>>>> working as expected on older AIX versions. Well, it should work 
>>>>>> now according to IBMs manpages. Will test later.
>>>>> Ok.
>>>>>>
>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>> instead, which is more portable.
>>>>>
>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>
>>>>> Here is an updated webrev. It includes the changes requested by you 
>>>>> and David:
>>>>>
>>>>> * No more AIX workarounds
>>>>> * Solaris use pthreads
>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>
>>>> That all seems good.
>>> Good. :)
>>>
>>>>
>>>>> I also assumed that NSIG is available and working on Solaris. I'll 
>>>>> let David decide if he is happy with that. The alternative is to go 
>>>>> back to the Solaris-specific code that allocates sact on the heap.
>>>>
>>>> Unfortunately NSIG is a problem on Solaris:
>>>>
>>>> http://austingroupbugs.net/view.php?id=741
>>>>
>>>> It's use also precludes the use of the real-time signals - which 
>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>> signals may be numbered in their entirety so I wouldn't necessarily 
>>>> suggest trying to use SIGRTMAX+1 as the number of available signals, 
>>>> other than on Solaris.
>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>> Solaris, where it is defined as SIGRTMAX+1.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>
>>> (8th time's a charm..?)
>>
>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>> not a constant expression. That's why Solaris uses malloc.
> 
> Duh. Right.
> 
> Oooookay. Like this, then?
> 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
> 
> I have restored the calls to allocate_sact() in the same locations as in 
> the original solaris version. Hopefully, those are correct. :-)

Yes you have restored them in the same locations.

As for correctness ... there are some preexisting issues I spotted. Do 
you really want to know? ;-) Well only one correctness issue, plus one 
unnecessary code issue:

Correctness:

83 #ifdef SOLARIS
   84   if (sact == NULL) {
   85     sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
(size_t)sizeof(struct sigaction));
   86     memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct sigaction));
   87   }
   88
   89   if (sact == NULL) {
   90     printf("%s\n", "libjsig.so unable to allocate memory");
   91     exit(0);
   92   }

The NULL check at line 89 needs to move to line 86 before we do memset 
on a NULL pointer.

Redundant code:

  142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
is_sigset) {
  143   sigset_t set;
  144
  145   allocate_sact();

There are two calls to save_signal_handler, both preceded by a call to 
allocate_sact(), so we don't need to do it again at line 145.

Thanks,
David

> /Magnus
>>
>> David
>>
>>
>>> /Magnus
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Webrev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>>>>
>>>>> Once again, here is also a webrev that shows the difference between 
>>>>> the original files and the new, unified file. Even if it's hard to 
>>>>> read, it shows what the effects will be for each platform.
>>>>>
>>>>> Webrev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>
>>>>>> ??? When I was about to update jsig.c, I noticed that the four copies
>>>>>> ??? for aix, linux, macosx and solaris were basically the same, with
>>>>>> ??? only small differences. Some of the differences were not even 
>>>>>> well
>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>> ??? causing the code to diverge.
>>>>>>
>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>> version,
>>>>>> ??? with the few platform-specific changes handled on a per-platform
>>>>>> ??? basis.
>>>>>>
>>>>>> ??? I've made the following notable changes:
>>>>>>
>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>> this is
>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>
>>>>>> ??? * Solaris used to have a dynamically allocated sact, instead of a
>>>>>> ??? statically allocated array as all other platforms have. It's not
>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>> ??? there seems to be no good reason for this.
>>>>>>
>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>
>>>>>> ??? Also worth noting:
>>>>>>
>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>
>>>>>> ??? * In general, if an implementation was needed on one platform, 
>>>>>> but
>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>
>>>>>> ??? To facilitate code review, here is a specially crafted webrev 
>>>>>> that
>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>> original
>>>>>> ??? per-OS versions of jsig.c:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>
>>>>>>
>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>> ??? WebRev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03
>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>
>>>>>>
>>>>>> ??? /Magnus
>>>>>>
>>>>>>
>>>>>
>>>
> 


From magnus.ihse.bursie at oracle.com  Thu Apr  5 10:53:38 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 12:53:38 +0200
Subject: RFR (8u): 8034788: Rewrite toolchain.m4 to support multiple
 toolchains per platform
In-Reply-To: <3d07a97c-e879-bfbe-33e2-fe19e7502795@oracle.com>
References: <3d07a97c-e879-bfbe-33e2-fe19e7502795@oracle.com>
Message-ID: <afe5b5f8-0cd3-d976-b996-dbb1b8c4d6fe@oracle.com>


On 2018-04-05 10:46, Kevin Walls wrote:
> Hi,
>
> I'd like to get a technical review of a backport to jdk8u:
>
> 8034788: Rewrite toolchain.m4 to support multiple toolchains per platform
> JBS: https://bugs.openjdk.java.net/browse/JDK-8034788
> 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/rev/b18872ff5379
>
> 8u webrev: http://cr.openjdk.java.net/~kevinw/8034788/webrev.00/
Looks good to me.

/Magnus
>
> toolchain.m4 did not import, lots of manual changes there, most other 
> files imported OK.
>
> This change adds flags.m4 which we have in 9, but not in 8 until now. 
> When 8151841 happened in 8u ( 
> http://closedjdk.us.oracle.com/jdk8u/jdk8u-cpu/rev/73494e6ff8e5 ) it 
> worked with toolchain.m4, and didn't create flags.m4.? But doing 
> 8034788 now, I wanted to bring 8 and 9 closer together, to make 
> further changes easier, so I add flags.m4, and e.g. 
> FLAGS_SETUP_GCC6_COMPILER_FLAGS moves to flags.m4.
>
> (I updated copyright years after creating the webrev.)
>
> Thanks
> Kevin
>



From magnus.ihse.bursie at oracle.com  Thu Apr  5 11:07:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 13:07:54 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
Message-ID: <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>

On 2018-04-05 12:30, David Holmes wrote:
> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>> On 2018-04-05 10:30, David Holmes wrote:
>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>
>>>>
>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> Sorry for the delay ...
>>>>>
>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>
>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>> Hi Magnus,
>>>>>>>
>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>
>>>>>>> This is good, thanks for doing this.
>>>>>>>
>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>> "workarounds". I do not know why we did this - the original code 
>>>>>>> is quite old - my assumption is that dlsym(RTLD_NEXT) was not 
>>>>>>> working as expected on older AIX versions. Well, it should work 
>>>>>>> now according to IBMs manpages. Will test later.
>>>>>> Ok.
>>>>>>>
>>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>>> instead, which is more portable.
>>>>>>
>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>
>>>>>> Here is an updated webrev. It includes the changes requested by 
>>>>>> you and David:
>>>>>>
>>>>>> * No more AIX workarounds
>>>>>> * Solaris use pthreads
>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>
>>>>> That all seems good.
>>>> Good. :)
>>>>
>>>>>
>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>> I'll let David decide if he is happy with that. The alternative 
>>>>>> is to go back to the Solaris-specific code that allocates sact on 
>>>>>> the heap.
>>>>>
>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>
>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>
>>>>> It's use also precludes the use of the real-time signals - which 
>>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>>> signals may be numbered in their entirety so I wouldn't 
>>>>> necessarily suggest trying to use SIGRTMAX+1 as the number of 
>>>>> available signals, other than on Solaris.
>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>>
>>>> (8th time's a charm..?)
>>>
>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>>> not a constant expression. That's why Solaris uses malloc.
>>
>> Duh. Right.
>>
>> Oooookay. Like this, then?
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>
>> I have restored the calls to allocate_sact() in the same locations as 
>> in the original solaris version. Hopefully, those are correct. :-)
>
> Yes you have restored them in the same locations.
>
> As for correctness ... there are some preexisting issues I spotted. Do 
> you really want to know? ;-) Well only one correctness issue, plus one 
> unnecessary code issue:
Will it ever end?! :-)

>
> Correctness:
>
> 83 #ifdef SOLARIS
> ? 84?? if (sact == NULL) {
> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
> (size_t)sizeof(struct sigaction));
> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
> sigaction));
> ? 87?? }
> ? 88
> ? 89?? if (sact == NULL) {
> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
> ? 91???? exit(0);
> ? 92?? }
>
> The NULL check at line 89 needs to move to line 86 before we do memset 
> on a NULL pointer.
>
> Redundant code:
>
> ?142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
> is_sigset) {
> ?143?? sigset_t set;
> ?144
> ?145?? allocate_sact();
>
> There are two calls to save_signal_handler, both preceded by a call to 
> allocate_sact(), so we don't need to do it again at line 145.

Ok, I'll fix it while I'm at it.

New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10

Also, here is a webrev with the same patch applied to jdk/hs. (I have 
also included the needed changes to how libjsig is compiled, which are 
pushed to jdk/jdk but not yet integrated into jdk/hs). The patch file 
from this webrev can be applied to jdk/hs, so Thomas hopefully can test 
the AIX changes.

Let's hope this is the final iteration...

/Magnus

>
> Thanks,
> David
>
>> /Magnus
>>>
>>> David
>>>
>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>>>>>
>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>> between the original files and the new, unified file. Even if 
>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>> platform.
>>>>>>
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>
>>>>>>> ??? When I was about to update jsig.c, I noticed that the four 
>>>>>>> copies
>>>>>>> ??? for aix, linux, macosx and solaris were basically the same, 
>>>>>>> with
>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>> even well
>>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>>> ??? causing the code to diverge.
>>>>>>>
>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>> version,
>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>> per-platform
>>>>>>> ??? basis.
>>>>>>>
>>>>>>> ??? I've made the following notable changes:
>>>>>>>
>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>>> this is
>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>
>>>>>>> ??? * Solaris used to have a dynamically allocated sact, instead 
>>>>>>> of a
>>>>>>> ??? statically allocated array as all other platforms have. It's 
>>>>>>> not
>>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>
>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>
>>>>>>> ??? Also worth noting:
>>>>>>>
>>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>
>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>> platform, but
>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>
>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>> webrev that
>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>> original
>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>
>>>>>>>
>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>> ??? WebRev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>
>>>>>>>
>>>>>>> ??? /Magnus
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>



From kevin.walls at oracle.com  Thu Apr  5 11:13:08 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 5 Apr 2018 12:13:08 +0100
Subject: RFR (8u): 8034788: Rewrite toolchain.m4 to support multiple
 toolchains per platform
In-Reply-To: <afe5b5f8-0cd3-d976-b996-dbb1b8c4d6fe@oracle.com>
References: <3d07a97c-e879-bfbe-33e2-fe19e7502795@oracle.com>
 <afe5b5f8-0cd3-d976-b996-dbb1b8c4d6fe@oracle.com>
Message-ID: <5acdb313-0327-c5e2-8ee6-c43ffe2b4d51@oracle.com>

That's great, thanks Magnus.


On 05/04/2018 11:53, Magnus Ihse Bursie wrote:
>
> On 2018-04-05 10:46, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to get a technical review of a backport to jdk8u:
>>
>> 8034788: Rewrite toolchain.m4 to support multiple toolchains per 
>> platform
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8034788
>> 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/rev/b18872ff5379
>>
>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8034788/webrev.00/
> Looks good to me.
>
> /Magnus
>>
>> toolchain.m4 did not import, lots of manual changes there, most other 
>> files imported OK.
>>
>> This change adds flags.m4 which we have in 9, but not in 8 until now. 
>> When 8151841 happened in 8u ( 
>> http://closedjdk.us.oracle.com/jdk8u/jdk8u-cpu/rev/73494e6ff8e5 ) it 
>> worked with toolchain.m4, and didn't create flags.m4.? But doing 
>> 8034788 now, I wanted to bring 8 and 9 closer together, to make 
>> further changes easier, so I add flags.m4, and e.g. 
>> FLAGS_SETUP_GCC6_COMPILER_FLAGS moves to flags.m4.
>>
>> (I updated copyright years after creating the webrev.)
>>
>> Thanks
>> Kevin
>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr  5 11:11:34 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 13:11:34 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
 <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
Message-ID: <8a494d99-28f0-9119-1263-556da3f30353@oracle.com>

On 2018-04-05 13:07, Magnus Ihse Bursie wrote:
> On 2018-04-05 12:30, David Holmes wrote:
>> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>>> On 2018-04-05 10:30, David Holmes wrote:
>>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>>
>>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> Sorry for the delay ...
>>>>>>
>>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>>
>>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>>> Hi Magnus,
>>>>>>>>
>>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>>
>>>>>>>> This is good, thanks for doing this.
>>>>>>>>
>>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>>> "workarounds". I do not know why we did this - the original 
>>>>>>>> code is quite old - my assumption is that dlsym(RTLD_NEXT) was 
>>>>>>>> not working as expected on older AIX versions. Well, it should 
>>>>>>>> work now according to IBMs manpages. Will test later.
>>>>>>> Ok.
>>>>>>>>
>>>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>>>> instead, which is more portable.
>>>>>>>
>>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>>
>>>>>>> Here is an updated webrev. It includes the changes requested by 
>>>>>>> you and David:
>>>>>>>
>>>>>>> * No more AIX workarounds
>>>>>>> * Solaris use pthreads
>>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>>
>>>>>> That all seems good.
>>>>> Good. :)
>>>>>
>>>>>>
>>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>>> I'll let David decide if he is happy with that. The alternative 
>>>>>>> is to go back to the Solaris-specific code that allocates sact 
>>>>>>> on the heap.
>>>>>>
>>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>>
>>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>>
>>>>>> It's use also precludes the use of the real-time signals - which 
>>>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>>>> signals may be numbered in their entirety so I wouldn't 
>>>>>> necessarily suggest trying to use SIGRTMAX+1 as the number of 
>>>>>> available signals, other than on Solaris.
>>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>>
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>>>
>>>>> (8th time's a charm..?)
>>>>
>>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>>>> not a constant expression. That's why Solaris uses malloc.
>>>
>>> Duh. Right.
>>>
>>> Oooookay. Like this, then?
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>>
>>> I have restored the calls to allocate_sact() in the same locations 
>>> as in the original solaris version. Hopefully, those are correct. :-)
>>
>> Yes you have restored them in the same locations.
>>
>> As for correctness ... there are some preexisting issues I spotted. 
>> Do you really want to know? ;-) Well only one correctness issue, plus 
>> one unnecessary code issue:
> Will it ever end?! :-)
>
>>
>> Correctness:
>>
>> 83 #ifdef SOLARIS
>> ? 84?? if (sact == NULL) {
>> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
>> (size_t)sizeof(struct sigaction));
>> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
>> sigaction));
>> ? 87?? }
>> ? 88
>> ? 89?? if (sact == NULL) {
>> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
>> ? 91???? exit(0);
>> ? 92?? }
>>
>> The NULL check at line 89 needs to move to line 86 before we do 
>> memset on a NULL pointer.
>>
>> Redundant code:
>>
>> ?142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
>> is_sigset) {
>> ?143?? sigset_t set;
>> ?144
>> ?145?? allocate_sact();
>>
>> There are two calls to save_signal_handler, both preceded by a call 
>> to allocate_sact(), so we don't need to do it again at line 145.
>
> Ok, I'll fix it while I'm at it.
>
> New webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10
>
> Also, here is a webrev with the same patch applied to jdk/hs. (I have 
> also included the needed changes to how libjsig is compiled, which are 
> pushed to jdk/jdk but not yet integrated into jdk/hs). The patch file 
> from this webrev can be applied to jdk/hs, so Thomas hopefully can 
> test the AIX changes.
... and here is the link:

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.11

/Magnus

>
> Let's hope this is the final iteration...
>
> /Magnus
>
>>
>> Thanks,
>> David
>>
>>> /Magnus
>>>>
>>>> David
>>>>
>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 
>>>>>>>
>>>>>>>
>>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>>> between the original files and the new, unified file. Even if 
>>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>>> platform.
>>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> ??? When I was about to update jsig.c, I noticed that the four 
>>>>>>>> copies
>>>>>>>> ??? for aix, linux, macosx and solaris were basically the same, 
>>>>>>>> with
>>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>>> even well
>>>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>>>> ??? causing the code to diverge.
>>>>>>>>
>>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>>> version,
>>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>>> per-platform
>>>>>>>> ??? basis.
>>>>>>>>
>>>>>>>> ??? I've made the following notable changes:
>>>>>>>>
>>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>>>> this is
>>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>>
>>>>>>>> ??? * Solaris used to have a dynamically allocated sact, 
>>>>>>>> instead of a
>>>>>>>> ??? statically allocated array as all other platforms have. 
>>>>>>>> It's not
>>>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>>
>>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of 
>>>>>>>> sigset_t
>>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>>
>>>>>>>> ??? Also worth noting:
>>>>>>>>
>>>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>>
>>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>>> platform, but
>>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>>
>>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>>> webrev that
>>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>>> original
>>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>>> ??? WebRev:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? /Magnus
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr  5 11:51:34 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 13:51:34 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
 <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
Message-ID: <671b0d9c-74d5-9ea6-4415-584fa41b5372@oracle.com>

On 2018-04-05 13:07, Magnus Ihse Bursie wrote:
> On 2018-04-05 12:30, David Holmes wrote:
>> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>>> On 2018-04-05 10:30, David Holmes wrote:
>>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>>
>>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> Sorry for the delay ...
>>>>>>
>>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>>
>>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>>> Hi Magnus,
>>>>>>>>
>>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>>
>>>>>>>> This is good, thanks for doing this.
>>>>>>>>
>>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>>> "workarounds". I do not know why we did this - the original 
>>>>>>>> code is quite old - my assumption is that dlsym(RTLD_NEXT) was 
>>>>>>>> not working as expected on older AIX versions. Well, it should 
>>>>>>>> work now according to IBMs manpages. Will test later.
>>>>>>> Ok.
>>>>>>>>
>>>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>>>> instead, which is more portable.
>>>>>>>
>>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>>
>>>>>>> Here is an updated webrev. It includes the changes requested by 
>>>>>>> you and David:
>>>>>>>
>>>>>>> * No more AIX workarounds
>>>>>>> * Solaris use pthreads
>>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>>
>>>>>> That all seems good.
>>>>> Good. :)
>>>>>
>>>>>>
>>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>>> I'll let David decide if he is happy with that. The alternative 
>>>>>>> is to go back to the Solaris-specific code that allocates sact 
>>>>>>> on the heap.
>>>>>>
>>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>>
>>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>>
>>>>>> It's use also precludes the use of the real-time signals - which 
>>>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>>>> signals may be numbered in their entirety so I wouldn't 
>>>>>> necessarily suggest trying to use SIGRTMAX+1 as the number of 
>>>>>> available signals, other than on Solaris.
>>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>>
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>>>
>>>>> (8th time's a charm..?)
>>>>
>>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>>>> not a constant expression. That's why Solaris uses malloc.
>>>
>>> Duh. Right.
>>>
>>> Oooookay. Like this, then?
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>>
>>> I have restored the calls to allocate_sact() in the same locations 
>>> as in the original solaris version. Hopefully, those are correct. :-)
>>
>> Yes you have restored them in the same locations.
>>
>> As for correctness ... there are some preexisting issues I spotted. 
>> Do you really want to know? ;-) Well only one correctness issue, plus 
>> one unnecessary code issue:
> Will it ever end?! :-)
>
>>
>> Correctness:
>>
>> 83 #ifdef SOLARIS
>> ? 84?? if (sact == NULL) {
>> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
>> (size_t)sizeof(struct sigaction));
>> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
>> sigaction));
>> ? 87?? }
>> ? 88
>> ? 89?? if (sact == NULL) {
>> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
>> ? 91???? exit(0);
>> ? 92?? }
>>
>> The NULL check at line 89 needs to move to line 86 before we do 
>> memset on a NULL pointer.
>>
>> Redundant code:
>>
>> ?142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
>> is_sigset) {
>> ?143?? sigset_t set;
>> ?144
>> ?145?? allocate_sact();
>>
>> There are two calls to save_signal_handler, both preceded by a call 
>> to allocate_sact(), so we don't need to do it again at line 145.
>
> Ok, I'll fix it while I'm at it.
>
> New webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10
>
> Also, here is a webrev with the same patch applied to jdk/hs. (I have 
> also included the needed changes to how libjsig is compiled, which are 
> pushed to jdk/jdk but not yet integrated into jdk/hs). The patch file 
> from this webrev can be applied to jdk/hs, so Thomas hopefully can 
> test the AIX changes.
>
> Let's hope this is the final iteration...
*LOL* Of course not. I forgot to press save in the editor before 
creating the webrev and starting the tests. *arrrghh* I can't believe this.

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.12

/Magnus

>
> /Magnus
>
>>
>> Thanks,
>> David
>>
>>> /Magnus
>>>>
>>>> David
>>>>
>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 
>>>>>>>
>>>>>>>
>>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>>> between the original files and the new, unified file. Even if 
>>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>>> platform.
>>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> ??? When I was about to update jsig.c, I noticed that the four 
>>>>>>>> copies
>>>>>>>> ??? for aix, linux, macosx and solaris were basically the same, 
>>>>>>>> with
>>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>>> even well
>>>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>>>> ??? causing the code to diverge.
>>>>>>>>
>>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>>> version,
>>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>>> per-platform
>>>>>>>> ??? basis.
>>>>>>>>
>>>>>>>> ??? I've made the following notable changes:
>>>>>>>>
>>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>>>> this is
>>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>>
>>>>>>>> ??? * Solaris used to have a dynamically allocated sact, 
>>>>>>>> instead of a
>>>>>>>> ??? statically allocated array as all other platforms have. 
>>>>>>>> It's not
>>>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>>
>>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of 
>>>>>>>> sigset_t
>>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>>
>>>>>>>> ??? Also worth noting:
>>>>>>>>
>>>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>>
>>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>>> platform, but
>>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>>
>>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>>> webrev that
>>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>>> original
>>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>>> ??? WebRev:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? /Magnus
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>



From david.holmes at oracle.com  Thu Apr  5 12:07:53 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 22:07:53 +1000
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
 <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
Message-ID: <3339e1f3-428f-f5aa-bdb4-f53bbd9478cd@oracle.com>



On 5/04/2018 9:07 PM, Magnus Ihse Bursie wrote:
> On 2018-04-05 12:30, David Holmes wrote:
>> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>>> On 2018-04-05 10:30, David Holmes wrote:
>>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>>
>>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> Sorry for the delay ...
>>>>>>
>>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>>
>>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>>> Hi Magnus,
>>>>>>>>
>>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>>
>>>>>>>> This is good, thanks for doing this.
>>>>>>>>
>>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>>> "workarounds". I do not know why we did this - the original code 
>>>>>>>> is quite old - my assumption is that dlsym(RTLD_NEXT) was not 
>>>>>>>> working as expected on older AIX versions. Well, it should work 
>>>>>>>> now according to IBMs manpages. Will test later.
>>>>>>> Ok.
>>>>>>>>
>>>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>>>> instead, which is more portable.
>>>>>>>
>>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>>
>>>>>>> Here is an updated webrev. It includes the changes requested by 
>>>>>>> you and David:
>>>>>>>
>>>>>>> * No more AIX workarounds
>>>>>>> * Solaris use pthreads
>>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>>
>>>>>> That all seems good.
>>>>> Good. :)
>>>>>
>>>>>>
>>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>>> I'll let David decide if he is happy with that. The alternative 
>>>>>>> is to go back to the Solaris-specific code that allocates sact on 
>>>>>>> the heap.
>>>>>>
>>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>>
>>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>>
>>>>>> It's use also precludes the use of the real-time signals - which 
>>>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>>>> signals may be numbered in their entirety so I wouldn't 
>>>>>> necessarily suggest trying to use SIGRTMAX+1 as the number of 
>>>>>> available signals, other than on Solaris.
>>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>>
>>>>> Updated webrev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>>>
>>>>> (8th time's a charm..?)
>>>>
>>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>>>> not a constant expression. That's why Solaris uses malloc.
>>>
>>> Duh. Right.
>>>
>>> Oooookay. Like this, then?
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>>
>>> I have restored the calls to allocate_sact() in the same locations as 
>>> in the original solaris version. Hopefully, those are correct. :-)
>>
>> Yes you have restored them in the same locations.
>>
>> As for correctness ... there are some preexisting issues I spotted. Do 
>> you really want to know? ;-) Well only one correctness issue, plus one 
>> unnecessary code issue:
> Will it ever end?! :-)
> 
>>
>> Correctness:
>>
>> 83 #ifdef SOLARIS
>> ? 84?? if (sact == NULL) {
>> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
>> (size_t)sizeof(struct sigaction));
>> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
>> sigaction));
>> ? 87?? }
>> ? 88
>> ? 89?? if (sact == NULL) {
>> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
>> ? 91???? exit(0);
>> ? 92?? }
>>
>> The NULL check at line 89 needs to move to line 86 before we do memset 
>> on a NULL pointer.
>>
>> Redundant code:
>>
>> ?142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
>> is_sigset) {
>> ?143?? sigset_t set;
>> ?144
>> ?145?? allocate_sact();
>>
>> There are two calls to save_signal_handler, both preceded by a call to 
>> allocate_sact(), so we don't need to do it again at line 145.
> 
> Ok, I'll fix it while I'm at it.

You don't seem to have fixed the unnecessary allocate_sact() at line 145.

David
-----

> 
> New webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10
> 
> Also, here is a webrev with the same patch applied to jdk/hs. (I have 
> also included the needed changes to how libjsig is compiled, which are 
> pushed to jdk/jdk but not yet integrated into jdk/hs). The patch file 
> from this webrev can be applied to jdk/hs, so Thomas hopefully can test 
> the AIX changes.
> 
> Let's hope this is the final iteration...
> 
> /Magnus
> 
>>
>> Thanks,
>> David
>>
>>> /Magnus
>>>>
>>>> David
>>>>
>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05
>>>>>>>
>>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>>> between the original files and the new, unified file. Even if 
>>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>>> platform.
>>>>>>>
>>>>>>> Webrev: 
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> ??? When I was about to update jsig.c, I noticed that the four 
>>>>>>>> copies
>>>>>>>> ??? for aix, linux, macosx and solaris were basically the same, 
>>>>>>>> with
>>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>>> even well
>>>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>>>> ??? causing the code to diverge.
>>>>>>>>
>>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>>> version,
>>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>>> per-platform
>>>>>>>> ??? basis.
>>>>>>>>
>>>>>>>> ??? I've made the following notable changes:
>>>>>>>>
>>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>>>> this is
>>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>>
>>>>>>>> ??? * Solaris used to have a dynamically allocated sact, instead 
>>>>>>>> of a
>>>>>>>> ??? statically allocated array as all other platforms have. It's 
>>>>>>>> not
>>>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>>
>>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of sigset_t
>>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>>
>>>>>>>> ??? Also worth noting:
>>>>>>>>
>>>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>>
>>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>>> platform, but
>>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>>
>>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>>> webrev that
>>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>>> original
>>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>>> ??? WebRev:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>>
>>>>>>>>
>>>>>>>> ??? /Magnus
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
> 


From david.holmes at oracle.com  Thu Apr  5 12:09:14 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 22:09:14 +1000
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <671b0d9c-74d5-9ea6-4415-584fa41b5372@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
 <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
 <671b0d9c-74d5-9ea6-4415-584fa41b5372@oracle.com>
Message-ID: <dbd21213-3a7b-463e-b53e-aa11fd66eeff@oracle.com>

:) V12 looks fine. Sorry I didnt see this before previous email.

David

On 5/04/2018 9:51 PM, Magnus Ihse Bursie wrote:
> On 2018-04-05 13:07, Magnus Ihse Bursie wrote:
>> On 2018-04-05 12:30, David Holmes wrote:
>>> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>>>> On 2018-04-05 10:30, David Holmes wrote:
>>>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>>>
>>>>>>
>>>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>>>> Hi Magnus,
>>>>>>>
>>>>>>> Sorry for the delay ...
>>>>>>>
>>>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>>>
>>>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>>>> Hi Magnus,
>>>>>>>>>
>>>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>>>
>>>>>>>>> This is good, thanks for doing this.
>>>>>>>>>
>>>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>>>> "workarounds". I do not know why we did this - the original 
>>>>>>>>> code is quite old - my assumption is that dlsym(RTLD_NEXT) was 
>>>>>>>>> not working as expected on older AIX versions. Well, it should 
>>>>>>>>> work now according to IBMs manpages. Will test later.
>>>>>>>> Ok.
>>>>>>>>>
>>>>>>>>> __thread is not Posix. I would prefer pthread_get/set_specific 
>>>>>>>>> instead, which is more portable.
>>>>>>>>
>>>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>>>
>>>>>>>> Here is an updated webrev. It includes the changes requested by 
>>>>>>>> you and David:
>>>>>>>>
>>>>>>>> * No more AIX workarounds
>>>>>>>> * Solaris use pthreads
>>>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>>>
>>>>>>> That all seems good.
>>>>>> Good. :)
>>>>>>
>>>>>>>
>>>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>>>> I'll let David decide if he is happy with that. The alternative 
>>>>>>>> is to go back to the Solaris-specific code that allocates sact 
>>>>>>>> on the heap.
>>>>>>>
>>>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>>>
>>>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>>>
>>>>>>> It's use also precludes the use of the real-time signals - which 
>>>>>>> limits Linux as well. But I'm not completely clear on exactly how 
>>>>>>> signals may be numbered in their entirety so I wouldn't 
>>>>>>> necessarily suggest trying to use SIGRTMAX+1 as the number of 
>>>>>>> available signals, other than on Solaris.
>>>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>>>
>>>>>> Updated webrev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08
>>>>>>
>>>>>> (8th time's a charm..?)
>>>>>
>>>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it is 
>>>>> not a constant expression. That's why Solaris uses malloc.
>>>>
>>>> Duh. Right.
>>>>
>>>> Oooookay. Like this, then?
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>>>
>>>> I have restored the calls to allocate_sact() in the same locations 
>>>> as in the original solaris version. Hopefully, those are correct. :-)
>>>
>>> Yes you have restored them in the same locations.
>>>
>>> As for correctness ... there are some preexisting issues I spotted. 
>>> Do you really want to know? ;-) Well only one correctness issue, plus 
>>> one unnecessary code issue:
>> Will it ever end?! :-)
>>
>>>
>>> Correctness:
>>>
>>> 83 #ifdef SOLARIS
>>> ? 84?? if (sact == NULL) {
>>> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
>>> (size_t)sizeof(struct sigaction));
>>> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
>>> sigaction));
>>> ? 87?? }
>>> ? 88
>>> ? 89?? if (sact == NULL) {
>>> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
>>> ? 91???? exit(0);
>>> ? 92?? }
>>>
>>> The NULL check at line 89 needs to move to line 86 before we do 
>>> memset on a NULL pointer.
>>>
>>> Redundant code:
>>>
>>> ?142 static void save_signal_handler(int sig, sa_handler_t disp, bool 
>>> is_sigset) {
>>> ?143?? sigset_t set;
>>> ?144
>>> ?145?? allocate_sact();
>>>
>>> There are two calls to save_signal_handler, both preceded by a call 
>>> to allocate_sact(), so we don't need to do it again at line 145.
>>
>> Ok, I'll fix it while I'm at it.
>>
>> New webrev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10
>>
>> Also, here is a webrev with the same patch applied to jdk/hs. (I have 
>> also included the needed changes to how libjsig is compiled, which are 
>> pushed to jdk/jdk but not yet integrated into jdk/hs). The patch file 
>> from this webrev can be applied to jdk/hs, so Thomas hopefully can 
>> test the AIX changes.
>>
>> Let's hope this is the final iteration...
> *LOL* Of course not. I forgot to press save in the editor before 
> creating the webrev and starting the tests. *arrrghh* I can't believe this.
> 
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.12
> 
> /Magnus
> 
>>
>> /Magnus
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> /Magnus
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Webrev: 
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 
>>>>>>>>
>>>>>>>>
>>>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>>>> between the original files and the new, unified file. Even if 
>>>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>>>> platform.
>>>>>>>>
>>>>>>>> Webrev: 
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>>>
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>> ??? When I was about to update jsig.c, I noticed that the four 
>>>>>>>>> copies
>>>>>>>>> ??? for aix, linux, macosx and solaris were basically the same, 
>>>>>>>>> with
>>>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>>>> even well
>>>>>>>>> ??? motivated, but were likely the result of this code duplication
>>>>>>>>> ??? causing the code to diverge.
>>>>>>>>>
>>>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>>>> version,
>>>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>>>> per-platform
>>>>>>>>> ??? basis.
>>>>>>>>>
>>>>>>>>> ??? I've made the following notable changes:
>>>>>>>>>
>>>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>>>> ??? platforms seem to do fine without it, and in general, we don't
>>>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>>>> ??? version check to all other platforms instead. If you think 
>>>>>>>>> this is
>>>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>>>
>>>>>>>>> ??? * Solaris used to have a dynamically allocated sact, 
>>>>>>>>> instead of a
>>>>>>>>> ??? statically allocated array as all other platforms have. 
>>>>>>>>> It's not
>>>>>>>>> ??? likely to be large, and the size is known at compile time, so
>>>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>>>
>>>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of 
>>>>>>>>> sigset_t
>>>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>>>> ??? solution, and the added checks show that it has failed in the
>>>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>>>
>>>>>>>>> ??? Also worth noting:
>>>>>>>>>
>>>>>>>>> ??? * Solaris is not using pthreads, but it's own thread library,
>>>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>>>
>>>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>>>> platform, but
>>>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>>>
>>>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>>>> webrev that
>>>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>>>> original
>>>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>>>> ??? WebRev:
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>>>
>>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ??? /Magnus
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
> 


From magnus.ihse.bursie at oracle.com  Thu Apr  5 12:35:45 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 14:35:45 +0200
Subject: RFR: JDK-8199782: Fix compilation warnings detected by Solaris
 Developer Studio 12.6
In-Reply-To: <5AC516FB.9010101@oracle.com>
References: <5AC516FB.9010101@oracle.com>
Message-ID: <904f24c7-0fb7-a99a-669e-fcd3277291f8@oracle.com>

On 2018-04-04 20:18, Gary Adams wrote:
> Getting the sources ready for the next Solaris developer studio 
> toolchain.
>
> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
> ? Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/
>
> This update conditionally disables some new error checks, if the
> new toolchain is used.

Looks good to me.

/Magnus




From magnus.ihse.bursie at oracle.com  Thu Apr  5 12:51:15 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 14:51:15 +0200
Subject: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c
In-Reply-To: <dbd21213-3a7b-463e-b53e-aa11fd66eeff@oracle.com>
References: <edabcaaf-985c-1649-d564-a9a287580ee3@oracle.com>
 <CAA-vtUz9SD5XbLPyRco4yG7y-uNzcvMfbCbCtR8PSrHJ7U=a-w@mail.gmail.com>
 <6bf1b97e-73f6-abd7-e3c1-0ff9e315e053@oracle.com>
 <a7688ef0-5c0d-5bf8-3a1b-59993046a816@oracle.com>
 <0d11a229-4d90-e833-b196-a1a4c598da39@oracle.com>
 <f83dcfec-1f14-83aa-4fbf-cf758116089b@oracle.com>
 <55c82847-8ca9-3768-7377-7978778a7747@oracle.com>
 <28ba33ee-8a32-c7ab-ec6c-c3d5f3343947@oracle.com>
 <3b0dd473-895c-549f-eba0-f1a429c21f0f@oracle.com>
 <671b0d9c-74d5-9ea6-4415-584fa41b5372@oracle.com>
 <dbd21213-3a7b-463e-b53e-aa11fd66eeff@oracle.com>
Message-ID: <5c48b640-cede-5605-3511-62b78b91f9b4@oracle.com>

On 2018-04-05 14:09, David Holmes wrote:
> :) V12 looks fine. Sorry I didnt see this before previous email.

Finally! :-)

I'll wait for Thomas to test on AIX as well, then I believe this is 
finally ready to push.

/Magnus

>
> David
>
> On 5/04/2018 9:51 PM, Magnus Ihse Bursie wrote:
>> On 2018-04-05 13:07, Magnus Ihse Bursie wrote:
>>> On 2018-04-05 12:30, David Holmes wrote:
>>>> On 5/04/2018 7:52 PM, Magnus Ihse Bursie wrote:
>>>>> On 2018-04-05 10:30, David Holmes wrote:
>>>>>> On 5/04/2018 6:07 PM, Magnus Ihse Bursie wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2018-04-04 09:59, David Holmes wrote:
>>>>>>>> Hi Magnus,
>>>>>>>>
>>>>>>>> Sorry for the delay ...
>>>>>>>>
>>>>>>>> On 28/03/2018 8:15 PM, Magnus Ihse Bursie wrote:
>>>>>>>>>
>>>>>>>>> On 2018-03-27 18:24, Thomas St?fe wrote:
>>>>>>>>>> Hi Magnus,
>>>>>>>>>>
>>>>>>>>>> just a cursory look, will look in greater detail tomorrow.
>>>>>>>>>>
>>>>>>>>>> This is good, thanks for doing this.
>>>>>>>>>>
>>>>>>>>>> As I wrote offlist, please remove the painfully wrong AIX 
>>>>>>>>>> "workarounds". I do not know why we did this - the original 
>>>>>>>>>> code is quite old - my assumption is that dlsym(RTLD_NEXT) 
>>>>>>>>>> was not working as expected on older AIX versions. Well, it 
>>>>>>>>>> should work now according to IBMs manpages. Will test later.
>>>>>>>>> Ok.
>>>>>>>>>>
>>>>>>>>>> __thread is not Posix. I would prefer 
>>>>>>>>>> pthread_get/set_specific instead, which is more portable.
>>>>>>>>>
>>>>>>>>> I have surrounded this code with #ifdef MACOSX now.
>>>>>>>>>
>>>>>>>>> Here is an updated webrev. It includes the changes requested 
>>>>>>>>> by you and David:
>>>>>>>>>
>>>>>>>>> * No more AIX workarounds
>>>>>>>>> * Solaris use pthreads
>>>>>>>>> * The "reentry" code is #ifdef MACOSX.
>>>>>>>>
>>>>>>>> That all seems good.
>>>>>>> Good. :)
>>>>>>>
>>>>>>>>
>>>>>>>>> I also assumed that NSIG is available and working on Solaris. 
>>>>>>>>> I'll let David decide if he is happy with that. The 
>>>>>>>>> alternative is to go back to the Solaris-specific code that 
>>>>>>>>> allocates sact on the heap.
>>>>>>>>
>>>>>>>> Unfortunately NSIG is a problem on Solaris:
>>>>>>>>
>>>>>>>> http://austingroupbugs.net/view.php?id=741
>>>>>>>>
>>>>>>>> It's use also precludes the use of the real-time signals - 
>>>>>>>> which limits Linux as well. But I'm not completely clear on 
>>>>>>>> exactly how signals may be numbered in their entirety so I 
>>>>>>>> wouldn't necessarily suggest trying to use SIGRTMAX+1 as the 
>>>>>>>> number of available signals, other than on Solaris.
>>>>>>> Ok. I hope I understand you correctly. I have replaced NSIG with 
>>>>>>> MAX_SIGNALS, which is defined as NSIG on all platforms except 
>>>>>>> Solaris, where it is defined as SIGRTMAX+1.
>>>>>>>
>>>>>>> Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.08 
>>>>>>>
>>>>>>>
>>>>>>> (8th time's a charm..?)
>>>>>>
>>>>>> Nope - you can't use SIGRTMAX+1 to allocate a static array as it 
>>>>>> is not a constant expression. That's why Solaris uses malloc.
>>>>>
>>>>> Duh. Right.
>>>>>
>>>>> Oooookay. Like this, then?
>>>>>
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.09
>>>>>
>>>>> I have restored the calls to allocate_sact() in the same locations 
>>>>> as in the original solaris version. Hopefully, those are correct. :-)
>>>>
>>>> Yes you have restored them in the same locations.
>>>>
>>>> As for correctness ... there are some preexisting issues I spotted. 
>>>> Do you really want to know? ;-) Well only one correctness issue, 
>>>> plus one unnecessary code issue:
>>> Will it ever end?! :-)
>>>
>>>>
>>>> Correctness:
>>>>
>>>> 83 #ifdef SOLARIS
>>>> ? 84?? if (sact == NULL) {
>>>> ? 85???? sact = (struct sigaction *)malloc((MAX_SIGNALS) * 
>>>> (size_t)sizeof(struct sigaction));
>>>> ? 86???? memset(sact, 0, (MAX_SIGNALS) * (size_t)sizeof(struct 
>>>> sigaction));
>>>> ? 87?? }
>>>> ? 88
>>>> ? 89?? if (sact == NULL) {
>>>> ? 90???? printf("%s\n", "libjsig.so unable to allocate memory");
>>>> ? 91???? exit(0);
>>>> ? 92?? }
>>>>
>>>> The NULL check at line 89 needs to move to line 86 before we do 
>>>> memset on a NULL pointer.
>>>>
>>>> Redundant code:
>>>>
>>>> ?142 static void save_signal_handler(int sig, sa_handler_t disp, 
>>>> bool is_sigset) {
>>>> ?143?? sigset_t set;
>>>> ?144
>>>> ?145?? allocate_sact();
>>>>
>>>> There are two calls to save_signal_handler, both preceded by a call 
>>>> to allocate_sact(), so we don't need to do it again at line 145.
>>>
>>> Ok, I'll fix it while I'm at it.
>>>
>>> New webrev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.10
>>>
>>> Also, here is a webrev with the same patch applied to jdk/hs. (I 
>>> have also included the needed changes to how libjsig is compiled, 
>>> which are pushed to jdk/jdk but not yet integrated into jdk/hs). The 
>>> patch file from this webrev can be applied to jdk/hs, so Thomas 
>>> hopefully can test the AIX changes.
>>>
>>> Let's hope this is the final iteration...
>> *LOL* Of course not. I forgot to press save in the editor before 
>> creating the webrev and starting the tests. *arrrghh* I can't believe 
>> this.
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.12
>>
>> /Magnus
>>
>>>
>>> /Magnus
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> /Magnus
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.05 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Once again, here is also a webrev that shows the difference 
>>>>>>>>> between the original files and the new, unified file. Even if 
>>>>>>>>> it's hard to read, it shows what the effects will be for each 
>>>>>>>>> platform.
>>>>>>>>>
>>>>>>>>> Webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.04/ 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /Magnus
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie 
>>>>>>>>>> <magnus.ihse.bursie at oracle.com 
>>>>>>>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> ??? When I was about to update jsig.c, I noticed that the 
>>>>>>>>>> four copies
>>>>>>>>>> ??? for aix, linux, macosx and solaris were basically the 
>>>>>>>>>> same, with
>>>>>>>>>> ??? only small differences. Some of the differences were not 
>>>>>>>>>> even well
>>>>>>>>>> ??? motivated, but were likely the result of this code 
>>>>>>>>>> duplication
>>>>>>>>>> ??? causing the code to diverge.
>>>>>>>>>>
>>>>>>>>>> ??? A better solution is to unify them all into a single unix 
>>>>>>>>>> version,
>>>>>>>>>> ??? with the few platform-specific changes handled on a 
>>>>>>>>>> per-platform
>>>>>>>>>> ??? basis.
>>>>>>>>>>
>>>>>>>>>> ??? I've made the following notable changes:
>>>>>>>>>>
>>>>>>>>>> ??? * I have removed the version check for Solaris. All other
>>>>>>>>>> ??? platforms seem to do fine without it, and in general, we 
>>>>>>>>>> don't
>>>>>>>>>> ??? mistrust other JDK libraries. An alternative is to add this
>>>>>>>>>> ??? version check to all other platforms instead. If you 
>>>>>>>>>> think this is
>>>>>>>>>> ??? the correct course of action, let me know and I'll fix it.
>>>>>>>>>>
>>>>>>>>>> ??? * Solaris used to have a dynamically allocated sact, 
>>>>>>>>>> instead of a
>>>>>>>>>> ??? statically allocated array as all other platforms have. 
>>>>>>>>>> It's not
>>>>>>>>>> ??? likely to be large, and the size is known at compile 
>>>>>>>>>> time, so
>>>>>>>>>> ??? there seems to be no good reason for this.
>>>>>>>>>>
>>>>>>>>>> ??? * Linux and macosx used a uint32_t/uint64_t instead of 
>>>>>>>>>> sigset_t
>>>>>>>>>> ??? for jvmsigs, as aix and solaris do. This is a less robust
>>>>>>>>>> ??? solution, and the added checks show that it has failed in 
>>>>>>>>>> the
>>>>>>>>>> ??? past. Now all platforms use sigset_t/sigismember().
>>>>>>>>>>
>>>>>>>>>> ??? Also worth noting:
>>>>>>>>>>
>>>>>>>>>> ??? * Solaris is not using pthreads, but it's own thread 
>>>>>>>>>> library,
>>>>>>>>>> ??? which accounts for most of the #ifdef SOLARIS.
>>>>>>>>>>
>>>>>>>>>> ??? * In general, if an implementation was needed on one 
>>>>>>>>>> platform, but
>>>>>>>>>> ??? has no effect or is harmless on others, I've kept it on all
>>>>>>>>>> ??? platforms instead of sprinkling the code with #ifdefs.
>>>>>>>>>>
>>>>>>>>>> ??? To facilitate code review, here is a specially crafted 
>>>>>>>>>> webrev that
>>>>>>>>>> ??? shows the differences compared to each of the individual, 
>>>>>>>>>> original
>>>>>>>>>> ??? per-OS versions of jsig.c:
>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.01> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8200298>
>>>>>>>>>> ??? WebRev:
>>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03 
>>>>>>>>>>
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8200298-unify-libjsig/webrev.03> 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ??? /Magnus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>



From fairoz.matte at oracle.com  Thu Apr  5 05:25:26 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Wed, 4 Apr 2018 22:25:26 -0700 (PDT)
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
 Soft Float
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <74fb02a1-e526-4ca6-b581-9f6a2ca05602@default>

Hi Juan Antonio,

> -----Original Message-----
> From: bren at juanantonio.info [mailto:bren at juanantonio.info]
> 
> Good night David,
> 
> It is the first time that I report a Bug on OpenJDK and I didn?t receive any
> notification so I didn?t know the status of the Issue that I reported.

Yes, there was some issue in the notification server, no emails sent to bug submitters. Generally you will receive e-mail, once issue is created in JDK.
Sorry about this.
Thanks David for pointing out the JDK issue.

Thanks,
Fairoz
> 
> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
> config-4417031.html
> 
> We will try to do Compilation with the solution.
> 
> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> @@ -298,6 +298,15 @@
>       FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>     }
> 
> + if (arm_arch() == 5) {
> + if (FLAG_IS_DEFAULT(AssumeMP)) {
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + else if (AssumeMP) {
> + warning("AssumeMP can not be true for ARMv5 as there is only
> uniprocessor support");
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + }
> + }
> +
>     _is_initialized = true;
>   }
> 
> Runtime workaround: java -XX:-AssumeMP
> 
> In our case, I would like to continue maintaining this support for the Device.
> What is the advice that you could give us?
> What is AssumeMP?
> 
> For education, this device is pretty interesting for the whole Java community,
> this is the reason.
> 
> I will inform with the results.
> 
> Many thanks in advance.
> 
> Cheers
> 
> Juan Antonio
> 
> El 2018-04-05 00:12, David Holmes escribi?:
> > Hi,
> >
> > This was already reported as:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8200580
> >
> > to which I have responded and closed the bug as this is not a
> > supported platform.
> >
> > As per the bug report this may be due to the change to AssumeMP to be
> > true, but there is no MP support for ARMv5.
> >
> > David
> >
> > On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
> >> Good morning,
> >>
> >> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
> >> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
> >> recently, we build OpenJDK 9 with success but with OpenJDK 10, we
> >> have found some problems when we execute some Java programs.
> >>
> >> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
> >> https://github.com/ev3dev-lang-java/openjdk-ev3
> >>
> >> To test the JVM, I am using the following repo to test the VM:
> >> https://github.com/ev3dev-lang-java/vmbenchmarks
> >>
> >> And this is the output with the error:
> >>
> >> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
> >> WARNING: An illegal reflective access operation has occurred
> >> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
> >> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
> >> WARNING: Please consider reporting this to the maintainers of
> >> org.openjdk.jmh.util.Utils
> >> WARNING: Use --illegal-access=warn to enable warnings of further
> >> illegal reflective access operations
> >> WARNING: All illegal access operations will be denied in a future
> >> release =============== DEBUG MESSAGE: Atomic load(jlong)
> unsupported
> >> on this platform ================
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
> this
> >> platform ================
> >>
> >> [thread 4430 also had an error]
> >> [error occurred during error reporting ((null)), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing fatal error
> >> message), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing type of error), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing stack bounds), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing native stack), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing Java stack), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing target Java thread
> >> stack), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing siginfo), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (CDS archive access warning),
> >> id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing register info), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [Too many errors, abort]
> >> Aborted
> >>
> >> I think that in OpenJDK10 changed something in compare to OpenJDK9 in
> >> relation to ARM5 support.
> >>
> >> Any idea?
> >>
> >> Many thanks in advance.
> >>
> >> Cheers
> >>
> >> Juan Antonio
> >>


From magnus.ihse.bursie at oracle.com  Thu Apr  5 13:05:40 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 15:05:40 +0200
Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?=
 =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?=
In-Reply-To: <CAA-vtUz1g5nB1xyaFLrr9_cgsHE9rmgsAsXS2e0PZNHqJ0u1yA@mail.gmail.com>
References: <CAA-vtUyz7dTqzy_6+ywupKP8y1FA6yuS4xnBQi6j-n+8qG7qNw@mail.gmail.com>
 <d1d782e5-3181-805d-c001-e5a179461cd8@oracle.com>
 <bf539c94-d96b-cdd4-ce5d-c94fa53a5389@oracle.com>
 <CAA-vtUz1g5nB1xyaFLrr9_cgsHE9rmgsAsXS2e0PZNHqJ0u1yA@mail.gmail.com>
Message-ID: <09687e17-3bd7-71e7-9a1b-6aebf04fa602@oracle.com>

I ran into this myself just now...

While we could, of course, disable the warning, I wonder if this is the 
right way to go. It seems to be deprecated for good reasons. See the 
readdir_r man page:

http://man7.org/linux/man-pages/man3/readdir_r.3.html

I quote:

> It is recommended that applications usereaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  instead of
>         *readdir_r*().  Furthermore, since version 2.24, glibc deprecates
>         *readdir_r*().  The reasons are as follows:
>
>         *  On systems where*NAME_MAX *is undefined, calling*readdir_r*() may be
>            unsafe because the interface does not allow the caller to specify
>            the length of the buffer used for the returned directory entry.
>
>         *  On some systems,*readdir_r*() can't read directory entries with
>            very long names.  When the glibc implementation encounters such a
>            name,*readdir_r*() fails with the error*ENAMETOOLONG */after the/
>            /final directory entry has been read/.  On some other systems,
>            *readdir_r*() may return a success status, but the returned/d_name/
>            field may not be null terminated or may be truncated.
>
>         *  In the current POSIX.1 specification (POSIX.1-2008),readdir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  is
>            not required to be thread-safe.  However, in modern
>            implementations (including the glibc implementation), concurrent
>            calls toreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  that specify different directory streams are
>            thread-safe.  Therefore, the use of*readdir_r*() is generally
>            unnecessary in multithreaded programs.  In cases where multiple
>            threads must read from the same directory stream, usingreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>
>            with external synchronization is still preferable to the use of
>            *readdir_r*(), for the reasons given in the points above.
>
>         *  It is expected that a future version of POSIX.1 will make
>            *readdir_r*() obsolete, and require thatreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  be thread-safe
>            when concurrently employed on different directory streams.

/Magnus



On 2018-03-12 08:45, Thomas St?fe wrote:
> Thanks a lot for digging this up! That may very well be.
>
> I see that we locally disable the warning in os_linux.inline.hpp. My error
> happens when compiling the jdk, among others TimeZone_md.c. I do not see
> that we pass -Wdeprecated-declarations.
>
> I am still unsure whether this is a new issue or an existing one I
> uncovered in by environment. Unfortunately I have to drive to the office
> now and will then be back in gcc 4.8 land. Have to pick this up again next
> weekend (or just install a saner Linux).
>
> Thank you!
>
> Thomas
>
>
>
>
> On Mon, Mar 12, 2018 at 8:26 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> We already dealt with this in the VM:
>>
>> http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775
>>
>> by disabling the warning.
>>
>> That suggests to me that this warning must have been disabled in the JDK
>> build too. So perhaps recent flag reworking has modified that. ??
>>
>> David
>>
>>
>> On 12/03/2018 5:15 PM, David Holmes wrote:
>>
>>> Hi Thomas,
>>>
>>> On 12/03/2018 5:02 PM, Thomas St?fe wrote:
>>>
>>>> Hi all,
>>>>
>>>> maybe someone has an idea:
>>>>
>>>> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.
>>>>
>>>> I get this error:
>>>>
>>>> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:
>>>> In function ?read_dir?:
>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
>>>> warning: ?readdir_r? is deprecated [-Wdeprecated-declarations]
>>>>        if (readdir_r(dirp, entry, &p) == 0) {
>>>>        ^~
>>>> In file included from
>>>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0,
>>>>
>>>>                    from
>>>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32,
>>>>
>>>>                    from
>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:29:
>>>> /usr/include/dirent.h:183:12: note: declared here
>>>>    extern int readdir_r (DIR *__restrict __dirp,
>>>>               ^~~~~~~~~
>>>>
>>>> I digged and was not able to pin it to any recent change. I also think  I
>>>> never successfully built on this box, so it may be my environment.
>>>>
>>>> Could it be that my gcc is too new?
>>>>
>>> We've built with gcc 7 so it can't be that on its own. May be a
>>> combination of gcc and glibc version. It was deprecated in glibc 2.24.
>>>
>>> David
>>>
>>> Thanks! Thomas
>>>>



From david.holmes at oracle.com  Thu Apr  5 13:14:31 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 23:14:31 +1000
Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?=
 =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?=
In-Reply-To: <09687e17-3bd7-71e7-9a1b-6aebf04fa602@oracle.com>
References: <CAA-vtUyz7dTqzy_6+ywupKP8y1FA6yuS4xnBQi6j-n+8qG7qNw@mail.gmail.com>
 <d1d782e5-3181-805d-c001-e5a179461cd8@oracle.com>
 <bf539c94-d96b-cdd4-ce5d-c94fa53a5389@oracle.com>
 <CAA-vtUz1g5nB1xyaFLrr9_cgsHE9rmgsAsXS2e0PZNHqJ0u1yA@mail.gmail.com>
 <09687e17-3bd7-71e7-9a1b-6aebf04fa602@oracle.com>
Message-ID: <014afaec-be76-15d5-8ed4-21d64557b130@oracle.com>

On 5/04/2018 11:05 PM, Magnus Ihse Bursie wrote:
> I ran into this myself just now...
> 
> While we could, of course, disable the warning, I wonder if this is the 
> right way to go. It seems to be deprecated for good reasons. See the 
> readdir_r man page:
> 
> http://man7.org/linux/man-pages/man3/readdir_r.3.html
> 
> I quote:

Sure, but "generally unnecessary in multithreaded programs" doesn't 
quite cut it when it comes to correctness. So we have a couple of 
obscure cases where readdir_r may do the wrong thing and we have a 
subset of cases where readdir may be thread-safe "enough"; and hopefully 
one day POSIX will specify it as thread-safe and all will be well in world.

Until such time as that happens IMHO we stick with the code we that 
seems to be working perfectly fine and disable the warning.

Cheers,
David

>> It is recommended that applications usereaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  instead of
>>         *readdir_r*().  Furthermore, since version 2.24, glibc deprecates
>>         *readdir_r*().  The reasons are as follows:
>>
>>         *  On systems where*NAME_MAX *is undefined, calling*readdir_r*() may be
>>            unsafe because the interface does not allow the caller to specify
>>            the length of the buffer used for the returned directory entry.
>>
>>         *  On some systems,*readdir_r*() can't read directory entries with
>>            very long names.  When the glibc implementation encounters such a
>>            name,*readdir_r*() fails with the error*ENAMETOOLONG */after the/
>>            /final directory entry has been read/.  On some other systems,
>>            *readdir_r*() may return a success status, but the returned/d_name/
>>            field may not be null terminated or may be truncated.
>>
>>         *  In the current POSIX.1 specification (POSIX.1-2008),readdir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  is
>>            not required to be thread-safe.  However, in modern
>>            implementations (including the glibc implementation), concurrent
>>            calls toreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  that specify different directory streams are
>>            thread-safe.  Therefore, the use of*readdir_r*() is generally
>>            unnecessary in multithreaded programs.  In cases where multiple
>>            threads must read from the same directory stream, usingreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>
>>            with external synchronization is still preferable to the use of
>>            *readdir_r*(), for the reasons given in the points above.
>>
>>         *  It is expected that a future version of POSIX.1 will make
>>            *readdir_r*() obsolete, and require thatreaddir(3) <http://man7.org/linux/man-pages/man3/readdir.3.html>  be thread-safe
>>            when concurrently employed on different directory streams.
> 
> /Magnus
> 
> 
> 
> On 2018-03-12 08:45, Thomas St?fe wrote:
>> Thanks a lot for digging this up! That may very well be.
>>
>> I see that we locally disable the warning in os_linux.inline.hpp. My error
>> happens when compiling the jdk, among others TimeZone_md.c. I do not see
>> that we pass -Wdeprecated-declarations.
>>
>> I am still unsure whether this is a new issue or an existing one I
>> uncovered in by environment. Unfortunately I have to drive to the office
>> now and will then be back in gcc 4.8 land. Have to pick this up again next
>> weekend (or just install a saner Linux).
>>
>> Thank you!
>>
>> Thomas
>>
>>
>>
>>
>> On Mon, Mar 12, 2018 at 8:26 AM, David Holmes<david.holmes at oracle.com>
>> wrote:
>>
>>> We already dealt with this in the VM:
>>>
>>> http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775
>>>
>>> by disabling the warning.
>>>
>>> That suggests to me that this warning must have been disabled in the JDK
>>> build too. So perhaps recent flag reworking has modified that. ??
>>>
>>> David
>>>
>>>
>>> On 12/03/2018 5:15 PM, David Holmes wrote:
>>>
>>>> Hi Thomas,
>>>>
>>>> On 12/03/2018 5:02 PM, Thomas St?fe wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> maybe someone has an idea:
>>>>>
>>>>> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.
>>>>>
>>>>> I get this error:
>>>>>
>>>>> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
>>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:
>>>>> In function ?read_dir?:
>>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
>>>>> warning: ?readdir_r? is deprecated [-Wdeprecated-declarations]
>>>>>        if (readdir_r(dirp, entry, &p) == 0) {
>>>>>        ^~
>>>>> In file included from
>>>>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0,
>>>>>
>>>>>                    from
>>>>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32,
>>>>>
>>>>>                    from
>>>>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>>>>> ix/native/libmanagement_ext/OperatingSystemImpl.c:29:
>>>>> /usr/include/dirent.h:183:12: note: declared here
>>>>>    extern int readdir_r (DIR *__restrict __dirp,
>>>>>               ^~~~~~~~~
>>>>>
>>>>> I digged and was not able to pin it to any recent change. I also think  I
>>>>> never successfully built on this box, so it may be my environment.
>>>>>
>>>>> Could it be that my gcc is too new?
>>>>>
>>>> We've built with gcc 7 so it can't be that on its own. May be a
>>>> combination of gcc and glibc version. It was deprecated in glibc 2.24.
>>>>
>>>> David
>>>>
>>>> Thanks! Thomas
>>>>>
> 


From erik.joelsson at oracle.com  Thu Apr  5 13:47:32 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 06:47:32 -0700
Subject: RFR: JDK-8200358 Remove mapfiles for JDK executables
In-Reply-To: <fb914764-cb77-a928-79bf-c16a4ff648f8@oracle.com>
References: <582377d2-98c8-05d2-d100-da4acf3bbcbd@oracle.com>
 <CA+kOe09r2N+2Ntvgxtg+az-pupPSNjP8x-a7szJ_Em7p0_Dejw@mail.gmail.com>
 <dad4f5b7-982c-1c6b-cd5b-cc5f5a29a022@oracle.com>
 <CA+kOe0_AzSf5JyOpdB_79VzC1QbhDBkMt4LC8=HxUHcn7OK63g@mail.gmail.com>
 <a01f428c-562f-7af9-77e9-ffca90031424@oracle.com>
 <CA+kOe09f2DsOQcEWH38O_MccKMQ5NBK9wWvP1uHFjwKzA+br5Q@mail.gmail.com>
 <b9f1400f-4e13-2738-f16c-8b00ea3eb620@oracle.com>
 <464af58f-d32d-c885-3e54-9157a953915c@oracle.com>
 <ede6f1ed-0677-0375-df31-1df27dc69f2a@oracle.com>
 <19023a7d-6374-6a0d-77d8-0b9920add1e8@oracle.com>
 <fb914764-cb77-a928-79bf-c16a4ff648f8@oracle.com>
Message-ID: <2e7aef94-e591-a503-4d53-6df23d5a2dfb@oracle.com>

This looks good, hopefully for the last time. :)

Thanks for hanging in there!

/Erik


On 2018-04-05 02:16, Magnus Ihse Bursie wrote:
> On 2018-04-04 17:25, Erik Joelsson wrote:
>>
>> On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
>>> On 2018-04-03 23:16, Erik Joelsson wrote:
>>>> Looks good to me at least. Exporting symbols from executables seems 
>>>> wrong so applying hidden as default seems good to me.
>>> Unfortunately, it was not this easy. :-(
>>>
>>> Out of paranoia, I also started a test run on Windows, even though 
>>> it should not have been affected. Well, "should not". The added 
>>> JNIEXPORT turns into a __declspec(dllexport) on Windows, which 
>>> causes the Microsoft linker to behave like when linking a dll, so it 
>>> creates a .lib and .exp for each binary, in the bin directory.
>>>
>>> *sigh*
>>>
>>> I see two ways out of this.
>>>
>>> 1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
>>> main function, or by declaring something like EXEC_EXPORT instead, 
>>> and let it be empty on Windows.
>>>
>>> 2) Let the part of SetupNativeCompilation that handles executables 
>>> behave more like the one for shared libraries, and setting -implib, 
>>> etc. I'm not sure what happens if you pass in -implib when linking 
>>> an executable which does *not* have any dllexport decorations. If it 
>>> breaks, then this does not really seem like a way forward. 
>>> Otherwise, it's probably the safest choice, since it will make sure 
>>> we never leak any *.lib or *.exp for a potential future executable.
>>>
>>> What do you think?
>>>
>> I really don't know which I would prefer. Would be good to find out 
>> what happens in 2.
>
> Turns out that -implib is just ignored if not needed, so 2 is clearly 
> the way to go.
>
> This also meant that there was much overlap between the linking of 
> shared libraries and executables in SetupNativeCompilation, so I 
> (finally) took the time to unify them.
>
> Updated webrev: 
> http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.03
> (Only changes NativeCompilation.gmk)
>
> /Magnus
>
>
>>
>> /Erik
>



From erik.joelsson at oracle.com  Thu Apr  5 13:48:58 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 06:48:58 -0700
Subject: RFR: JDK-8199608 Clean up LDFLAGS for libfontmanager
In-Reply-To: <6100ac6f-8a38-fa19-3afc-cf53739cddf8@oracle.com>
References: <f4684695-0fbf-5d75-9347-74bbc5549f47@oracle.com>
 <d850cfac-9341-00c5-5fa7-5ad6e77435fe@oracle.com>
 <7291e911-5aff-36b4-ebef-c1210d9da284@oracle.com>
 <5e0871d1-41c8-a0bb-cecb-dbb084934b27@oracle.com>
 <9ffc644d-1a2e-b4f0-4cf9-873e9b384bcf@oracle.com>
 <6100ac6f-8a38-fa19-3afc-cf53739cddf8@oracle.com>
Message-ID: <a0adcfcc-dafd-91da-01d2-2e9f5e7fcaa8@oracle.com>

Looks good.

/Erik


On 2018-04-05 02:31, Magnus Ihse Bursie wrote:
> On 2018-03-14 22:17, Magnus Ihse Bursie wrote:
>>
>> On 2018-03-14 22:05, Phil Race wrote:
>>>
>>> >I see we used to link with libawt_headless for solaris, but removed 
>>> it in >JDK-8194870. Phil remarked in that bug: "We linked against 
>>> headless before then >but allowed undefined symbols JDK 9 switched 
>>> this to libawt_headless when >headless apps failed." but I'm not 
>>> sure I understand what this really means.
>>>
>>> It means that there is a long and sordid history.
>>> When we introduced this code it was as it is now.
>>> Some time in JDK 8 (?) it started to link against one of these libs.
>>> I'd have to go back and check which one, but definitely in JDK 9 a bug
>>> popped up with headless because of explicit linking to xawt .. which
>>> pulls in X11. At that time the fix was to switch it to link against 
>>> headless
>>> but that was the wrong fix now as it is then. Somehow it worked OK 
>>> though
>>> as had the xawt linking so long as you had X11 .. until JDK-8194870 and
>>> we realised the error. Now we are back to how it was intended in JDK 
>>> 1.5 (I think).
>> Thank you for the explanation!
>>
>> I will think about this fix for a while, and see what I can do about 
>> it. For now, consider the review request cancelled.
>
> I still need to think about how to handle the solaris case, but at 
> least I can salvage the macosx cleanup from this patch.
>
> I have verified functionality using "java -jar SwingSet2.jar" on a 
> macosx machine.
>
> Updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.02 
>
>
> /Magnus
>
>
>>
>> /Magnus
>>
>>>
>>> > Question to Phil: Would it be possible to rewrite the code to load 
>>> and reference the symbols dynamically
>>>
>>> Whilst it probably is possible, I really don't want to do that it is 
>>> not
>>> really in the spirit of what is intended here as well as being a 
>>> fair amount of work.
>>> This is not an "optional" library. It has to be there. We just don't 
>>> know which one
>>> until runtime.
>>> What I'd really like here is a build linker option that at build 
>>> time verifies
>>> that the dependencies are actually satisfied by each of xawt and 
>>> headless in turn
>>> but in neither case writes that library into the produced image as a 
>>> dependency.
>>>
>>> For the macos changes, I am supposing you mean you had to add this
>>> + LIBS_macosx := -lawt_lwawt -framework CoreText -framework 
>>> CoreFoundation \
>>>
>>> because you removed this
>>>
>>> - LDFLAGS_macosx := -undefined dynamic_lookup, \
>>>
>>> If it builds *and runs* its probably fine :-)
>>>
>>> Only Solaris + Linux have separate libraries for headful + headless.
>>>
>>> -phil.
>>>
>>> On 03/14/2018 01:22 PM, Magnus Ihse Bursie wrote:
>>>> On 2018-03-14 15:59, Erik Joelsson wrote:
>>>>> This change is unfortunately not correct for Linux and Solaris. We 
>>>>> cannot link libfontmanager explicitly against either libawt_xawt 
>>>>> or libawt_headless. See 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8196516 for my suggestion 
>>>>> on a better fix than we currently have. I was hoping for Severin 
>>>>> to check it out and pick it up, but he is away for a bit so that 
>>>>> hasn't happened.
>>>>>
>>>>> The reason we cannot link explicitly is that we need to decide at 
>>>>> runtime whether to pull in the headful or headless libraries. If 
>>>>> one or the other is already pulled in, and we explicitly load the 
>>>>> other, the runtime linker will lookup the common symbols in one or 
>>>>> the other in an unpredictable way. Some users get the correct 
>>>>> behavior, some get the wrong behavior. We recently had discussions 
>>>>> around this on this list if you want to dive deeper into it.
>>>>>
>>>>> Also see https://bugs.openjdk.java.net/browse/JDK-8194870 for one 
>>>>> of the consequences of explicit linking here.
>>>>>
>>>>> I think the mac part is ok though, but Phil has to have a look. 
>>>>> For Linux and Solaris, if you could remove the -lawt_headless and 
>>>>> add "-Xlinker --unresolved-symbols=ignore-all" to LDFLAGS for 
>>>>> linux I think we should be good.
>>>> Oh, this seems like a fine mess. :-(
>>>>
>>>> I see we used to link with libawt_headless for solaris, but removed 
>>>> it in JDK-8194870. Phil remarked in that bug: "We linked against 
>>>> headless before then but allowed undefined symbols JDK 9 switched 
>>>> this to libawt_headless when headless apps failed." but I'm not 
>>>> sure I understand what this really means.
>>>>
>>>> I agree it seems likely that the macosx changes is correct. I could 
>>>> probably add -Wl,--unresolved-symbols=ignore-all for gcc on linux, 
>>>> but that is unlikely to work on solstudio. :-( So I'm afraid we're 
>>>> still stuck with the need to remove -z defs for some builds. :-(
>>>>
>>>> Question to Phil: Would it be possible to rewrite the code to load 
>>>> and reference the symbols dynamically, using libdl? The problem 
>>>> here is that the functions are declared extern, instead of loaded 
>>>> into a function pointer at runtime. That's how you typically use 
>>>> this kind of runtime-determined dynamic loading.
>>>>
>>>> /Magnus
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2018-03-14 04:45, Magnus Ihse Bursie wrote:
>>>>>> This is the final LDFLAGS cleanup, which required some more work 
>>>>>> to resolve.
>>>>>>
>>>>>> Libfontmanager had previously explicitely disabled -z defs, with 
>>>>>> the result that linking did not complain about missing libraries. 
>>>>>> To fix this, I had to provide the proper libraries to link with. 
>>>>>> For linux and solaris, this was libawt_headless. For macosx, this 
>>>>>> was libawt_lwawt, but also three system frameworks.
>>>>>>
>>>>>> Note that this patch has a merge conflict with JDK-8199606. The 
>>>>>> end result of both patches are shown in the patch (that is, with 
>>>>>> -lc removed). I will make sure to resolve the conflicts properly 
>>>>>> when committing this patch.
>>>>>>
>>>>>> I have run COMPARE_BUILDS, with expected results. That is, no 
>>>>>> changes for Windows, and a deps change for macosx, linux and 
>>>>>> solaris. I also got a symbol change for linux, since the symbols 
>>>>>> from libawt_headless changed from e.g. "AWTCharAdvance" to 
>>>>>> "AWTCharAdvance@@SUNWprivate_1.1". And of course, when you do 
>>>>>> linking changes, you also end up getting binary/disasm changes.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199608
>>>>>> WebRev: 
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8199608-clean-up-LDFLAGS-for-libfontmanager/webrev.01
>>>>>>
>>>>>
>>>>
>>>
>>
>



From matthias.baesken at sap.com  Thu Apr  5 15:20:29 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 5 Apr 2018 15:20:29 +0000
Subject: missing JNIEXPORT / JNICALL at some places in  function
 declarations/implementations
Message-ID: <3efdab7702af4f068185e400fe953357@sap.com>

Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
The implementation of functions.
While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :

e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
        e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'

(there are quite a few of these e.g. in mlib  / splashscreen etc.)


Another example is this one :

diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
--- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
+++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
@@ -126,7 +126,7 @@
  *   JImageLocationRef location = (*JImageFindResource)(image,
  *                                "java.base", "9.0", "java/lang/String.class", &size);
  */
-extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
+extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
         const char* module_name, const char* version, const char* name,
         jlong* size);


Is there some generic way to get  the  same  declarations / impementations   in the code  ?

Or should I just add a patch with my findings ?

Best regards, Matthias



From magnus.ihse.bursie at oracle.com  Thu Apr  5 15:45:06 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 17:45:06 +0200
Subject: missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations
In-Reply-To: <3efdab7702af4f068185e400fe953357@sap.com>
References: <3efdab7702af4f068185e400fe953357@sap.com>
Message-ID: <B26D48FA-BD55-4D01-8096-5A3F261985D6@oracle.com>

That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal. 

I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed. 

Please do submit your patch. 

I'm a bit surprised 32-bit Window is still buildable. :)

/Magnus

> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
> The implementation of functions.
> While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :
>  
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>         e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'
>  
> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>  
>  
> Another example is this one :
>  
> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
> @@ -126,7 +126,7 @@
>   *   JImageLocationRef location = (*JImageFindResource)(image,
>   *                                "java.base", "9.0", "java/lang/String.class", &size);
>   */
> -extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
> +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
>          const char* module_name, const char* version, const char* name,
>          jlong* size);
>  
>  
> Is there some generic way to get  the  same  declarations / impementations   in the code  ?
>  
> Or should I just add a patch with my findings ?
>  
> Best regards, Matthias
>  


From erik.joelsson at oracle.com  Thu Apr  5 15:51:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 08:51:39 -0700
Subject: RFR: JDK-8199539: Provide a standard way for the build to filter
 un-needed legal .md files
In-Reply-To: <c04f6f07-95e6-6ae3-9f09-8283ba9d7b23@oracle.com>
References: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>
 <c04f6f07-95e6-6ae3-9f09-8283ba9d7b23@oracle.com>
Message-ID: <6dec1d0e-0c0f-a442-281a-779466b9fc26@oracle.com>

Thanks, but after writing this I felt like I could so easily unify the 
implementation. Here is a new webrev:

http://cr.openjdk.java.net/~erikj/8199539/webrev.02/index.html

/Erik


On 2018-04-05 01:45, Magnus Ihse Bursie wrote:
> On 2018-04-05 01:06, Erik Joelsson wrote:
>> When bundling legal files, we need to filter them according to what 
>> 3rd party components are actually included in the build. Several 
>> components, such as zlib, libjpeg and freetype can be linked with 
>> system libraries instead, and if so, we should also exclude the legal 
>> files for that component.
>>
>> This patch introduces a optional copy/filter step in the 
>> <module>-copy targets. Since there are only two affected modules at 
>> this time I didn't bother unifying this into one implementation. 
>> Instead the short logic is duplicated between the two.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8199539/webrev.01/index.html
> Looks good to me.
>
> /Magnus
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>
>> /Erik
>>
>



From jonathan.gibbons at oracle.com  Thu Apr  5 16:15:21 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 5 Apr 2018 09:15:21 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
Message-ID: <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>

I think one aspect of this discussion that is important and has been 
overlooked is that there is no clear statement (specification?) anywhere 
of the requirements for building OpenJDK. Since forever, the unwritten 
rule has been N-1 [*] and that assumption has become pervasive. And, as 
we have seen in this discussion, there are many consequences to changing 
that assumption.

I think that the decision to change the policy about the boot JDK is too 
important to hide in an edit in an Oracle-only build configuration file.

To be clear, I'm not advocating here for any specific value of N-1, N-2, 
etc,? I'm just saying the policy should be recorded in a more public 
place than make/conf/jib-profiles.js, and should implicitly apply to all 
folk wanting to build OpenJDK in the standard way, and not be just about 
"building JDK 11 at Oracle".

-- Jon

[*] Actually, the rule has been N-1 or N, by virtue of the bootcycle 
builds that used to be more common.



On 4/4/18 1:55 PM, Erik Joelsson wrote:
> Resending with corrected title.
>
>
> On 2018-04-04 13:54, Erik Joelsson wrote:
>> Updating the bootjdk requirement for JDK 11 was controversial. 
>> Instead I propose that for now, we just update the bootjdk used for 
>> building JDK 11 at Oracle to JDK 10 and let compatibility with JDK 9 
>> be a best effort from the parts of the community that wants to 
>> support it.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.02/
>>
>> /Erik
>>
>>
>> On 2018-03-21 14:51, Erik Joelsson wrote:
>>> Now that JDK 10 has been officially released we can update the boot 
>>> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
>>> awareness of this rather disruptive change.
>>>
>>> This patch changes the requirement on boot jdk version in configure 
>>> (and updates the configuration that controls what JDK to use as boot 
>>> in Oracle's internal build system).
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>>
>>> /Erik
>>>
>>
>



From tim.bell at oracle.com  Thu Apr  5 17:10:49 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 05 Apr 2018 10:10:49 -0700
Subject: RFR: JDK-8199539: Provide a standard way for the build to filter
 un-needed legal .md files
In-Reply-To: <6dec1d0e-0c0f-a442-281a-779466b9fc26@oracle.com>
References: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>
 <c04f6f07-95e6-6ae3-9f09-8283ba9d7b23@oracle.com>
 <6dec1d0e-0c0f-a442-281a-779466b9fc26@oracle.com>
Message-ID: <5AC65899.10400@oracle.com>

Erik:

> Thanks, but after writing this I felt like I could so easily unify the
> implementation. Here is a new webrev:
>
> http://cr.openjdk.java.net/~erikj/8199539/webrev.02/index.html

Looks good.

Tim

>
> /Erik
>
>
> On 2018-04-05 01:45, Magnus Ihse Bursie wrote:
>> On 2018-04-05 01:06, Erik Joelsson wrote:
>>> When bundling legal files, we need to filter them according to what
>>> 3rd party components are actually included in the build. Several
>>> components, such as zlib, libjpeg and freetype can be linked with
>>> system libraries instead, and if so, we should also exclude the legal
>>> files for that component.
>>>
>>> This patch introduces a optional copy/filter step in the
>>> <module>-copy targets. Since there are only two affected modules at
>>> this time I didn't bother unifying this into one implementation.
>>> Instead the short logic is duplicated between the two.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8199539/webrev.01/index.html
>> Looks good to me.
>>
>> /Magnus
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>>
>>> /Erik
>>>
>>
>



From erik.joelsson at oracle.com  Thu Apr  5 17:57:27 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 10:57:27 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
Message-ID: <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>

On 2018-04-05 09:15, Jonathan Gibbons wrote:
> I think one aspect of this discussion that is important and has been 
> overlooked is that there is no clear statement (specification?) 
> anywhere of the requirements for building OpenJDK. Since forever, the 
> unwritten rule has been N-1 [*] and that assumption has become 
> pervasive. And, as we have seen in this discussion, there are many 
> consequences to changing that assumption.
>
I agree that this should be well defined. This practice is currently 
documented in the build documentation in doc/building.md. (See the 
relevant text quoted below.) It is also enforced by configure, with no 
workaround short of editing the script.
> I think that the decision to change the policy about the boot JDK is 
> too important to hide in an edit in an Oracle-only build configuration 
> file.
>
The intention of my second suggested patch was basically to keep 
allowing JDK 9 in configure for a while but being pretty sure it would 
stop working eventually. I don't like doing it that way. It's much 
better with a clear fail early error in configure, but the first 
suggested patch, that did just that, met such hard resistance and not a 
single positive review.
> To be clear, I'm not advocating here for any specific value of N-1, 
> N-2, etc,? I'm just saying the policy should be recorded in a more 
> public place than make/conf/jib-profiles.js, and should implicitly 
> apply to all folk wanting to build OpenJDK in the standard way, and 
> not be just about "building JDK 11 at Oracle".
>
Is the building doc a good enough place? If not, please suggest 
something better.

```
Paradoxically, building OpenJDK requires a pre-existing JDK. This is 
called the
"boot JDK". The boot JDK does not have to be OpenJDK, though. If you are
porting OpenJDK to a new platform, chances are that there already exists
another JDK for that platform that is usable as boot JDK.

The rule of thumb is that the boot JDK for building JDK major version *N*
should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 
would be
suitable as boot JDK. However, OpenJDK should be able to "build itself", 
so an
up-to-date build of the current OpenJDK source is an acceptable 
alternative. If
you are following the *N-1* rule, make sure you've got the latest update
version, since JDK 8 GA might not be able to build JDK 9 on all platforms.

Early in the release cycle, version *N-1* may not yet have been released. In
that case, the preferred boot JDK will be version *N-2* until version *N-1*
is available.
```

/Erik



From erik.joelsson at oracle.com  Thu Apr  5 18:11:31 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 11:11:31 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
 <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
 <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
Message-ID: <6ee5a8cc-a548-7fd6-1987-84fafa943686@oracle.com>

On 2018-04-04 18:56, Martin Buchholz wrote:
>
>
> On Wed, Apr 4, 2018 at 5:03 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
>
>
>     I have to agree. There can't be two bootJDK versions.
>
>
> I have to disagree.? You could design openjdk to be buildable by any 
> set of boot JDKs.
> It's only the fact that javac happens to be written in java that 
> creates a boot jdk requirement at all.
It could, but the whole point we are trying to get across is that it 
adds a pretty large maintenance burden. As has been said before in this 
discussion, it hampers development. Javac is no small part of OpenJDK 
and as Alan pointed out, there are other easily forgettable details that 
get more complicated. To truly support it would require frequent 
verification that all bootjdk versions work and produce the same thing. 
We are in no need of more build configurations to keep track of. Are you 
up for taking on that work?

/Erik


From magnus.ihse.bursie at oracle.com  Thu Apr  5 19:36:39 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 5 Apr 2018 21:36:39 +0200
Subject: RFR: JDK-8199539: Provide a standard way for the build to filter
 un-needed legal .md files
In-Reply-To: <6dec1d0e-0c0f-a442-281a-779466b9fc26@oracle.com>
References: <07affc2b-b5f7-f974-de42-610e8e4a54f6@oracle.com>
 <c04f6f07-95e6-6ae3-9f09-8283ba9d7b23@oracle.com>
 <6dec1d0e-0c0f-a442-281a-779466b9fc26@oracle.com>
Message-ID: <b24cd143-b00d-e8c3-0804-ad891d4469be@oracle.com>

On 2018-04-05 17:51, Erik Joelsson wrote:
> Thanks, but after writing this I felt like I could so easily unify the 
> implementation. Here is a new webrev:
>
> http://cr.openjdk.java.net/~erikj/8199539/webrev.02/index.html
Even better! :)

/Magnus

>
> /Erik
>
>
> On 2018-04-05 01:45, Magnus Ihse Bursie wrote:
>> On 2018-04-05 01:06, Erik Joelsson wrote:
>>> When bundling legal files, we need to filter them according to what 
>>> 3rd party components are actually included in the build. Several 
>>> components, such as zlib, libjpeg and freetype can be linked with 
>>> system libraries instead, and if so, we should also exclude the 
>>> legal files for that component.
>>>
>>> This patch introduces a optional copy/filter step in the 
>>> <module>-copy targets. Since there are only two affected modules at 
>>> this time I didn't bother unifying this into one implementation. 
>>> Instead the short logic is duplicated between the two.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8199539/webrev.01/index.html
>> Looks good to me.
>>
>> /Magnus
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199539
>>>
>>> /Erik
>>>
>>
>



From erik.joelsson at oracle.com  Thu Apr  5 23:42:42 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 16:42:42 -0700
Subject: (urgent) RFR: JDK-8201221: JDK-8199608 introduced a build race on
 macosx
Message-ID: <33362a56-24d1-c402-1d07-90316ab1bed3@oracle.com>

JDK-8199608 introduced a build race on macosx and is failing all our 
macosx builds. The declaration:

$(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)

does not work because the SetupNativeCompilation call for 
BUILD_LIBAWT_LWAWT is positioned further down in the file.

I propose this patch:

diff -r 149dc554808c make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk
+++ b/make/lib/Awt2dLibraries.gmk
@@ -667,7 +667,7 @@
 ?endif

 ?ifeq ($(OPENJDK_TARGET_OS), macosx)
-? $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)
+? $(BUILD_LIBFONTMANAGER): $(call FindLib, java.desktop, awt_lwawt)
 ?endif

 ?ifeq ($(FREETYPE_TO_USE), bundled)


/Erik



From jonathan.gibbons at oracle.com  Thu Apr  5 23:50:18 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 5 Apr 2018 16:50:18 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
 <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
Message-ID: <0a22cdce-64ed-d73b-f1b0-ba03ee4acf82@oracle.com>



On 4/5/18 10:57 AM, Erik Joelsson wrote:
> On 2018-04-05 09:15, Jonathan Gibbons wrote:
>> I think one aspect of this discussion that is important and has been 
>> overlooked is that there is no clear statement (specification?) 
>> anywhere of the requirements for building OpenJDK. Since forever, the 
>> unwritten rule has been N-1 [*] and that assumption has become 
>> pervasive. And, as we have seen in this discussion, there are many 
>> consequences to changing that assumption.
>>
> I agree that this should be well defined. This practice is currently 
> documented in the build documentation in doc/building.md. (See the 
> relevant text quoted below.) It is also enforced by configure, with no 
> workaround short of editing the script.
>> I think that the decision to change the policy about the boot JDK is 
>> too important to hide in an edit in an Oracle-only build 
>> configuration file.
>>
> The intention of my second suggested patch was basically to keep 
> allowing JDK 9 in configure for a while but being pretty sure it would 
> stop working eventually. I don't like doing it that way. It's much 
> better with a clear fail early error in configure, but the first 
> suggested patch, that did just that, met such hard resistance and not 
> a single positive review.

That seems bad, because you're kicking the bucket down the road in a way 
that will cause obscure failures because of parts of the system assuming 
a boot JDK of 10. I think it is better to? have the "boot JDK policy" 
discussion, and to arrive at a decision, and to then follow through on 
that decision, updating docs, scripts and source code accordingly.

If the policy is going to change from "use JDK N-1", that new policy 
needs to be documented.

If the policy is going to be that "use JDK N-1; you're on your own if 
you want to use JDK 9 as a boot JDK" then editing the configure script 
is surely going to be the least of the worries.

-- Jon

>> To be clear, I'm not advocating here for any specific value of N-1, 
>> N-2, etc,? I'm just saying the policy should be recorded in a more 
>> public place than make/conf/jib-profiles.js, and should implicitly 
>> apply to all folk wanting to build OpenJDK in the standard way, and 
>> not be just about "building JDK 11 at Oracle".
>>
> Is the building doc a good enough place? If not, please suggest 
> something better.
>
> ```
> Paradoxically, building OpenJDK requires a pre-existing JDK. This is 
> called the
> "boot JDK". The boot JDK does not have to be OpenJDK, though. If you are
> porting OpenJDK to a new platform, chances are that there already exists
> another JDK for that platform that is usable as boot JDK.
>
> The rule of thumb is that the boot JDK for building JDK major version *N*
> should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 
> would be
> suitable as boot JDK. However, OpenJDK should be able to "build 
> itself", so an
> up-to-date build of the current OpenJDK source is an acceptable 
> alternative. If
> you are following the *N-1* rule, make sure you've got the latest update
> version, since JDK 8 GA might not be able to build JDK 9 on all 
> platforms.
>
> Early in the release cycle, version *N-1* may not yet have been 
> released. In
> that case, the preferred boot JDK will be version *N-2* until version 
> *N-1*
> is available.
> ```
>
> /Erik
>



From erik.joelsson at oracle.com  Fri Apr  6 00:08:46 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Apr 2018 17:08:46 -0700
Subject: (urgent) RFR: JDK-8201222: JDK-8199539 broke the OpenJDK build
Message-ID: <6570b7a8-9b6f-0ed8-b340-d7a789c268d1@oracle.com>

The fix in JDK-8199539 works fine for OracleJDK builds but broke the 
OpenJDK build. The problem is that I used CUSTOM_ROOT as the SRC dir for 
SetupCopyFiles. This was a bit of a hack together with FLATTEN := true. 
The idea was that I didn't care about the source dir but just wanted 
each file listed copied into the dest dir. CUSTOM_ROOT is however only 
defined in the OracleJDK build so won't work in an open only build. I've 
reworked this to instead loop over the files and call SetupCopyFiles 
once for each file to be copied instead.

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

Patch:

diff -r 149dc554808c make/copy/CopyCommon.gmk
--- a/make/copy/CopyCommon.gmk
+++ b/make/copy/CopyCommon.gmk
@@ -73,11 +73,12 @@
 ?#?? EXCLUDES : List of filenames to exclude from copy
 ?SetupCopyLegalFiles = $(NamedParamsMacroTemplate)
 ?define SetupCopyLegalFilesBody
-? $$(eval $$(call SetupCopyFiles, $1, \
-????? SRC := $$(CUSTOM_ROOT), \
-????? DEST := $$(LEGAL_DST_DIR), \
-????? FILES := $$(filter-out $$(addprefix %/, $$($1_EXCLUDES)), \
-????????? $$(wildcard $$(addsuffix /*, $$(call FindModuleLegalSrcDirs, 
$$(MODULE))))), \
-????? FLATTEN := true, \
-? ))
+? $$(foreach f, $$(filter-out $$(addprefix %/, $$($1_EXCLUDES)), \
+????? $$(wildcard $$(addsuffix /*, $$(call FindModuleLegalSrcDirs, 
$$(MODULE))))), \
+??? $$(eval $$(call SetupCopyFiles, $1_$$(notdir $$f), \
+??????? DEST := $$(LEGAL_DST_DIR), \
+??????? FILES := $$f, \
+??? )) \
+??? $$(eval $1 += $$($1_$$(notdir $$f))) \
+? )
 ?endef

/Erik



From tim.bell at oracle.com  Fri Apr  6 01:17:08 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 05 Apr 2018 18:17:08 -0700
Subject: (urgent) RFR: JDK-8201221: JDK-8199608 introduced a build race
 on macosx
In-Reply-To: <33362a56-24d1-c402-1d07-90316ab1bed3@oracle.com>
References: <33362a56-24d1-c402-1d07-90316ab1bed3@oracle.com>
Message-ID: <5AC6CA94.4000809@oracle.com>

Erik:

> JDK-8199608 introduced a build race on macosx and is failing all our
> macosx builds. The declaration:
>
> $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)
>
> does not work because the SetupNativeCompilation call for
> BUILD_LIBAWT_LWAWT is positioned further down in the file.
>
> I propose this patch:
>
> diff -r 149dc554808c make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -667,7 +667,7 @@
>   endif
>
>   ifeq ($(OPENJDK_TARGET_OS), macosx)
> -  $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)
> +  $(BUILD_LIBFONTMANAGER): $(call FindLib, java.desktop, awt_lwawt)
>   endif
>
>   ifeq ($(FREETYPE_TO_USE), bundled)

Looks good.

Tim




From tim.bell at oracle.com  Fri Apr  6 01:18:28 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 05 Apr 2018 18:18:28 -0700
Subject: (urgent) RFR: JDK-8201222: JDK-8199539 broke the OpenJDK build
In-Reply-To: <6570b7a8-9b6f-0ed8-b340-d7a789c268d1@oracle.com>
References: <6570b7a8-9b6f-0ed8-b340-d7a789c268d1@oracle.com>
Message-ID: <5AC6CAE4.2040602@oracle.com>

Erik:

> The fix in JDK-8199539 works fine for OracleJDK builds but broke the
> OpenJDK build. The problem is that I used CUSTOM_ROOT as the SRC dir for
> SetupCopyFiles. This was a bit of a hack together with FLATTEN := true.
> The idea was that I didn't care about the source dir but just wanted
> each file listed copied into the dest dir. CUSTOM_ROOT is however only
> defined in the OracleJDK build so won't work in an open only build. I've
> reworked this to instead loop over the files and call SetupCopyFiles
> once for each file to be copied instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201222
>
> Patch:
>
> diff -r 149dc554808c make/copy/CopyCommon.gmk
> --- a/make/copy/CopyCommon.gmk
> +++ b/make/copy/CopyCommon.gmk
> @@ -73,11 +73,12 @@
>   #   EXCLUDES : List of filenames to exclude from copy
>   SetupCopyLegalFiles = $(NamedParamsMacroTemplate)
>   define SetupCopyLegalFilesBody
> -  $$(eval $$(call SetupCopyFiles, $1, \
> -      SRC := $$(CUSTOM_ROOT), \
> -      DEST := $$(LEGAL_DST_DIR), \
> -      FILES := $$(filter-out $$(addprefix %/, $$($1_EXCLUDES)), \
> -          $$(wildcard $$(addsuffix /*, $$(call FindModuleLegalSrcDirs,
> $$(MODULE))))), \
> -      FLATTEN := true, \
> -  ))
> +  $$(foreach f, $$(filter-out $$(addprefix %/, $$($1_EXCLUDES)), \
> +      $$(wildcard $$(addsuffix /*, $$(call FindModuleLegalSrcDirs,
> $$(MODULE))))), \
> +    $$(eval $$(call SetupCopyFiles, $1_$$(notdir $$f), \
> +        DEST := $$(LEGAL_DST_DIR), \
> +        FILES := $$f, \
> +    )) \
> +    $$(eval $1 += $$($1_$$(notdir $$f))) \
> +  )
>   endef

Looks good.

Tim




From matthias.baesken at sap.com  Fri Apr  6 07:53:44 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 6 Apr 2018 07:53:44 +0000
Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in  function declarations/implementations
Message-ID: <2681cd5c027241c3978bf3ec86f5b108@sap.com>

Hello, please review :

Bug :

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

change :

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

mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build missed it .

A difference is  src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
Where I removed   a few  declarations  (one  decl   with one without  JNIEXPORT / JNICALL ? looked a bit strange ) .

Best regards , Matthias


From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
Sent: Donnerstag, 5. April 2018 17:45
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal.

I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed.

Please do submit your patch.

I'm a bit surprised 32-bit Window is still buildable. :)

/Magnus

5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
The implementation of functions.
While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :

e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
        e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'

(there are quite a few of these e.g. in mlib  / splashscreen etc.)


Another example is this one :

diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
--- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
+++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
@@ -126,7 +126,7 @@
  *   JImageLocationRef location = (*JImageFindResource)(image,
  *                                "java.base", "9.0", "java/lang/String.class", &size);
  */
-extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
+extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
         const char* module_name, const char* version, const char* name,
         jlong* size);


Is there some generic way to get  the  same  declarations / impementations   in the code  ?

Or should I just add a patch with my findings ?

Best regards, Matthias


From magnus.ihse.bursie at oracle.com  Fri Apr  6 09:03:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Apr 2018 11:03:54 +0200
Subject: RFR: JDK-8201229 Disable warnings as errors in aarch64 jib profile
Message-ID: <f8483fa7-d619-4df2-91bb-aca445c25b96@oracle.com>

The aarch64 profile does not always build without warnings; use 
--disable-as-warnings for the profile to be usable in jib.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201229
Patch inline:
diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js
--- a/make/conf/jib-profiles.js
+++ b/make/conf/jib-profiles.js
@@ -473,6 +473,7 @@
 ???????????? dependencies: ["devkit", "autoconf", "build_devkit", "cups"],
 ???????????? configure_args: [
 ???????????????? "--openjdk-target=aarch64-linux-gnu", 
"--with-freetype=bundled",
+??????????????? "--disable-warnings-as-errors"
 ???????????? ],
 ???????? },

/Magnus

From magnus.ihse.bursie at oracle.com  Fri Apr  6 09:10:39 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Apr 2018 11:10:39 +0200
Subject: (urgent) RFR: JDK-8201221: JDK-8199608 introduced a build race on
 macosx
In-Reply-To: <33362a56-24d1-c402-1d07-90316ab1bed3@oracle.com>
References: <33362a56-24d1-c402-1d07-90316ab1bed3@oracle.com>
Message-ID: <78b88713-4413-e43e-83bb-c274aac6bf3d@oracle.com>


On 2018-04-06 01:42, Erik Joelsson wrote:
> JDK-8199608 introduced a build race on macosx and is failing all our 
> macosx builds. The declaration:
>
> $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)
>
> does not work because the SetupNativeCompilation call for 
> BUILD_LIBAWT_LWAWT is positioned further down in the file.
Darn! :( Thanks for fixing this so promptly.

/Magnus

>
> I propose this patch:
>
> diff -r 149dc554808c make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -667,7 +667,7 @@
> ?endif
>
> ?ifeq ($(OPENJDK_TARGET_OS), macosx)
> -? $(BUILD_LIBFONTMANAGER): $(BUILD_LIBAWT_LWAWT)
> +? $(BUILD_LIBFONTMANAGER): $(call FindLib, java.desktop, awt_lwawt)
> ?endif
>
> ?ifeq ($(FREETYPE_TO_USE), bundled)
>
>
> /Erik
>



From adinn at redhat.com  Fri Apr  6 09:16:32 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 6 Apr 2018 10:16:32 +0100
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
 <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
Message-ID: <cb974ee6-1af0-b710-0413-345aab730bbe@redhat.com>

Hi Erik,

On 05/04/18 18:57, Erik Joelsson wrote:
> The intention of my second suggested patch was basically to keep
> allowing JDK 9 in configure for a while but being pretty sure it would
> stop working eventually. I don't like doing it that way. It's much
> better with a clear fail early error in configure, but the first
> suggested patch, that did just that, met such hard resistance and not a
> single positive review.
I am not sure the lack of positive reviews was an indication that no one
felt positive about your suggestion. It's quite possible that many
simply did not envisage the same pain as those who raised the negative
reviews and so did not feel moved to demur.

So, after reading the discussion here and assessing the implications of
the different choices let me offer you a positive review. I believe that
a clearly stated and applied N-1 policy is the best choice.

I'll admit that I tended to that view anyway before the discussion
started. Bootstrapping, especially in the context of a language runtime,
is actually much more complex than it appears. Contrary to naive
expectation, especially by those who are only tangentially involved in
making it happen, it never really goes away. The need to bootstrap new
capability keeps on coming back to bite us (whether individually or,
occasionally and rarely, jointly) as the language and runtime evolve,
requiring continual magic to allow a step up -- or occasionally sideways
or, one hopes rarely, backwards -- from one level of functionality and
abstraction to the next.

The trade-off between keeping the ladders you climbed up on in place or
whisking them away from under your newly assumed seat of superiority has
to recognise: firstly, that the cost of maintaining even a single layer
of such scaffolding is often very high -- magic always really means a
lot of hard, behind the scenes work; secondly, that the requirement to
be able to pile such layers on top of each other frequently produces a
very rickety and fragile platform at the apex. If the price of stability
is that a few users may need to retake some of those steps slowly, one
at a time then I am for stability.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


From dalibor.topic at oracle.com  Fri Apr  6 09:50:56 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 6 Apr 2018 11:50:56 +0200
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <6ee5a8cc-a548-7fd6-1987-84fafa943686@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com> <5AC53CF4.10007@oracle.com>
 <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
 <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
 <6ee5a8cc-a548-7fd6-1987-84fafa943686@oracle.com>
Message-ID: <0eeab300-b6b3-d2bc-07d3-2a1aee31852d@oracle.com>



On 05.04.2018 20:11, Erik Joelsson wrote:
> On 2018-04-04 18:56, Martin Buchholz wrote:
>>
>>
>> On Wed, Apr 4, 2018 at 5:03 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? On 5/04/2018 7:00 AM, Jonathan Gibbons wrote:
>>
>>
>> ??? I have to agree. There can't be two bootJDK versions.
>>
>>
>> I have to disagree.? You could design openjdk to be buildable by any 
>> set of boot JDKs.
>> It's only the fact that javac happens to be written in java that 
>> creates a boot jdk requirement at all.
> It could, but the whole point we are trying to get across is that it 
> adds a pretty large maintenance burden.

[..]

> We are in no need of more build configurations to keep track of. Are you 
> up for taking on that work?

Even if someone wanted to sign up for taking on such work, I think it'd 
be better suited for an update release series under their leadership 
than for the next, in-development JDK release.

For example, if someone sufficiently qualified decided to make future 
JDK 10 updates buildable using the full range of JDK 1.0 - JDK 10, as 
Martin seemingly suggests, they could pursue that effort as future JDK 
10 update maintainers instead of trying to make it work and keep it 
working in the faster paced mainline jdk/jdk development tree.

That way an additional maintenance burden would be created only where 
it's desired and presumably, necessary.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From magnus.ihse.bursie at oracle.com  Fri Apr  6 10:57:01 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Apr 2018 12:57:01 +0200
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
Message-ID: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>

The dtrace build logic was copied straight out of the old Hotspot build 
system, and is quite convoluted.

It should be split into the separate parts it actually contains of:
1) A gensrc step which runs with other gensrc ahead of compilation
2) Two independent libraries that can be build at any time
3) Two special dtrace-generated .o files that must be linked with the JVM

I have also cleaned up includes in generateJvmOffsets.cpp.

I have verified with COMPARE_BUILD that no changes has happened in any 
native library.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01

/Magnus


From matthias.baesken at sap.com  Fri Apr  6 13:20:59 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 6 Apr 2018 13:20:59 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in  function declarations/implementations
Message-ID: <9bae15f406ed4e029233415e6a8032b8@sap.com>

Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :


  1.  The   follow up change  that removed   mapfiles for  exes  as well    leads on Win32 bit  to  this link error :

  Creating library C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : fatal error LNK1120: 1 unresolved externals


Looks like we  cannot have   JNICALL   in main.c   :

diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
--- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04 2018 -0700
+++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40 2018 +0200
@@ -93,7 +93,7 @@
     __initenv = _environ;

#else /* JAVAW */
-JNIEXPORT int JNICALL
+JNIEXPORT int
main(int argc, char **argv)
{
     int margc;



  1.  Zip-library  has runtime issues   when  symbols  are resolved  in  src/hotspot/share/classfile/classLoader.cpp.

I added  the declaration of the missing symbol, this seems to fix it .


diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
--- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04 2018 -0700
+++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40 2018 +0200
@@ -284,4 +284,7 @@
JNIEXPORT jboolean JNICALL
ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);

+JNIEXPORT jint JNICALL
+ZIP_CRC32(jint crc, const jbyte *buf, jint len);
+


Should I  prepare  another  bug,  or  add this to the existing one and    post a second webrev ?

Best regards, Matthias


From: Baesken, Matthias
Sent: Freitag, 6. April 2018 09:54
To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

Hello, please review :

Bug :

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

change :

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

mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build missed it .

A difference is  src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
Where I removed   a few  declarations  (one  decl   with one without  JNIEXPORT / JNICALL ? looked a bit strange ) .

Best regards , Matthias


From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
Sent: Donnerstag, 5. April 2018 17:45
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal.

I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed.

Please do submit your patch.

I'm a bit surprised 32-bit Window is still buildable. :)

/Magnus

5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
The implementation of functions.
While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :

e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
        e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'

(there are quite a few of these e.g. in mlib  / splashscreen etc.)


Another example is this one :

diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
--- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
+++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
@@ -126,7 +126,7 @@
  *   JImageLocationRef location = (*JImageFindResource)(image,
  *                                "java.base", "9.0", "java/lang/String.class", &size);
  */
-extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
+extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
         const char* module_name, const char* version, const char* name,
         jlong* size);


Is there some generic way to get  the  same  declarations / impementations   in the code  ?

Or should I just add a patch with my findings ?

Best regards, Matthias


From erik.joelsson at oracle.com  Fri Apr  6 15:07:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 08:07:52 -0700
Subject: RFR: JDK-8201229 Disable warnings as errors in aarch64 jib profile
In-Reply-To: <f8483fa7-d619-4df2-91bb-aca445c25b96@oracle.com>
References: <f8483fa7-d619-4df2-91bb-aca445c25b96@oracle.com>
Message-ID: <9034e237-2f14-9fab-56a0-1740cabe2a72@oracle.com>

Looks good.

/Erik


On 2018-04-06 02:03, Magnus Ihse Bursie wrote:
> The aarch64 profile does not always build without warnings; use 
> --disable-as-warnings for the profile to be usable in jib.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201229
> Patch inline:
> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js
> --- a/make/conf/jib-profiles.js
> +++ b/make/conf/jib-profiles.js
> @@ -473,6 +473,7 @@
> ???????????? dependencies: ["devkit", "autoconf", "build_devkit", 
> "cups"],
> ???????????? configure_args: [
> ???????????????? "--openjdk-target=aarch64-linux-gnu", 
> "--with-freetype=bundled",
> +??????????????? "--disable-warnings-as-errors"
> ???????????? ],
> ???????? },
>
> /Magnus


From erik.joelsson at oracle.com  Fri Apr  6 15:23:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 08:23:36 -0700
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
In-Reply-To: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
References: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
Message-ID: <5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>

Looks good in general.

In JvmDtraceObjects.gmk, comment on line 38 needs to be updated.

/Erik


On 2018-04-06 03:57, Magnus Ihse Bursie wrote:
> The dtrace build logic was copied straight out of the old Hotspot 
> build system, and is quite convoluted.
>
> It should be split into the separate parts it actually contains of:
> 1) A gensrc step which runs with other gensrc ahead of compilation
> 2) Two independent libraries that can be build at any time
> 3) Two special dtrace-generated .o files that must be linked with the JVM
>
> I have also cleaned up includes in generateJvmOffsets.cpp.
>
> I have verified with COMPARE_BUILD that no changes has happened in any 
> native library.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01
>
> /Magnus



From magnus.ihse.bursie at oracle.com  Fri Apr  6 16:33:13 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Apr 2018 18:33:13 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <9bae15f406ed4e029233415e6a8032b8@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
Message-ID: <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>

I think it's reasonable to update the existing webrev. 

/Magnus

> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>  
> The   follow up change  that removed   mapfiles for  exes  as well    leads on Win32 bit  to  this link error :
>  
>   Creating library C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : fatal error LNK1120: 1 unresolved externals
>  
>  
> Looks like we  cannot have   JNICALL   in main.c   :
>  
> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04 2018 -0700
> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40 2018 +0200
> @@ -93,7 +93,7 @@
>      __initenv = _environ;
>  
> #else /* JAVAW */
> -JNIEXPORT int JNICALL
> +JNIEXPORT int
> main(int argc, char **argv)
> {
>      int margc;
>  
>  
> Zip-library  has runtime issues   when  symbols  are resolved  in  src/hotspot/share/classfile/classLoader.cpp.
> I added  the declaration of the missing symbol, this seems to fix it .
>  
>  
> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04 2018 -0700
> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40 2018 +0200
> @@ -284,4 +284,7 @@
> JNIEXPORT jboolean JNICALL
> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
>  
> +JNIEXPORT jint JNICALL
> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> +
>  
>  
> Should I  prepare  another  bug,  or  add this to the existing one and    post a second webrev ?
>  
> Best regards, Matthias
>  
>  
> From: Baesken, Matthias 
> Sent: Freitag, 6. April 2018 09:54
> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>  
> Hello, please review :
>  
> Bug :
>  
> https://bugs.openjdk.java.net/browse/JDK-8201226
>  
> change :
>  
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>  
> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build missed it .
>  
> A difference is  src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h 
> Where I removed   a few  declarations  (one  decl   with one without  JNIEXPORT / JNICALL ? looked a bit strange ) .
>  
> Best regards , Matthias
>  
>  
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] 
> Sent: Donnerstag, 5. April 2018 17:45
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>  
> That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal. 
>  
> I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed. 
>  
> Please do submit your patch. 
>  
> I'm a bit surprised 32-bit Window is still buildable. :)
> 
> /Magnus
> 
> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
> The implementation of functions.
> While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :
>  
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>         e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'
>  
> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>  
>  
> Another example is this one :
>  
> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
> @@ -126,7 +126,7 @@
>   *   JImageLocationRef location = (*JImageFindResource)(image,
>   *                                "java.base", "9.0", "java/lang/String.class", &size);
>   */
> -extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
> +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
>          const char* module_name, const char* version, const char* name,
>          jlong* size);
>  
>  
> Is there some generic way to get  the  same  declarations / impementations   in the code  ?
>  
> Or should I just add a patch with my findings ?
>  
> Best regards, Matthias
>  


From jonathan.gibbons at oracle.com  Fri Apr  6 16:51:21 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 6 Apr 2018 09:51:21 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <cb974ee6-1af0-b710-0413-345aab730bbe@redhat.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
 <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
 <cb974ee6-1af0-b710-0413-345aab730bbe@redhat.com>
Message-ID: <60a9ed9e-4bf2-751c-eaa8-17bf0cdc261f@oracle.com>

On 4/6/18 2:16 AM, Andrew Dinn wrote:

> Hi Erik,
>
> On 05/04/18 18:57, Erik Joelsson wrote:
>> The intention of my second suggested patch was basically to keep
>> allowing JDK 9 in configure for a while but being pretty sure it would
>> stop working eventually. I don't like doing it that way. It's much
>> better with a clear fail early error in configure, but the first
>> suggested patch, that did just that, met such hard resistance and not a
>> single positive review.
> I am not sure the lack of positive reviews was an indication that no one
> felt positive about your suggestion. It's quite possible that many
> simply did not envisage the same pain as those who raised the negative
> reviews and so did not feel moved to demur.
>
> So, after reading the discussion here and assessing the implications of
> the different choices let me offer you a positive review. I believe that
> a clearly stated and applied N-1 policy is the best choice.

I think the N-1 policy should be more clearly stated as "last GA".

When we started work on JDK 11, JDK 10 had not yet shipped, and so it
was appropriate for JDK 11 to use JDK 9 as the boot jdk.? Now that JDK 10
has shipped, it becomes a candidate to be a boot JDK, and becomes
the most recent GA JDK version.

-- Jon
>
> I'll admit that I tended to that view anyway before the discussion
> started. Bootstrapping, especially in the context of a language runtime,
> is actually much more complex than it appears. Contrary to naive
> expectation, especially by those who are only tangentially involved in
> making it happen, it never really goes away. The need to bootstrap new
> capability keeps on coming back to bite us (whether individually or,
> occasionally and rarely, jointly) as the language and runtime evolve,
> requiring continual magic to allow a step up -- or occasionally sideways
> or, one hopes rarely, backwards -- from one level of functionality and
> abstraction to the next.
>
> The trade-off between keeping the ladders you climbed up on in place or
> whisking them away from under your newly assumed seat of superiority has
> to recognise: firstly, that the cost of maintaining even a single layer
> of such scaffolding is often very high -- magic always really means a
> lot of hard, behind the scenes work; secondly, that the requirement to
> be able to pile such layers on top of each other frequently produces a
> very rickety and fragile platform at the apex. If the price of stability
> is that a few users may need to retake some of those steps slowly, one
> at a time then I am for stability.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander



From erik.joelsson at oracle.com  Fri Apr  6 16:57:06 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 09:57:06 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <60a9ed9e-4bf2-751c-eaa8-17bf0cdc261f@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
 <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
 <cb974ee6-1af0-b710-0413-345aab730bbe@redhat.com>
 <60a9ed9e-4bf2-751c-eaa8-17bf0cdc261f@oracle.com>
Message-ID: <d2700c80-11d2-61c3-6260-150973370e97@oracle.com>

On 2018-04-06 09:51, Jonathan Gibbons wrote:
>
> I think the N-1 policy should be more clearly stated as "last GA".
>
> When we started work on JDK 11, JDK 10 had not yet shipped, and so it
> was appropriate for JDK 11 to use JDK 9 as the boot jdk.? Now that JDK 10
> has shipped, it becomes a candidate to be a boot JDK, and becomes
> the most recent GA JDK version.
>
I like that, but don't you mean min("last GA", N-1)?

/Erik



From jonathan.gibbons at oracle.com  Fri Apr  6 17:34:10 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 06 Apr 2018 10:34:10 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <d2700c80-11d2-61c3-6260-150973370e97@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <4e97be8b-f65f-d69a-8b0c-8d6652934892@oracle.com>
 <b65dbe4d-b5a4-f283-236c-7a97af5c87c8@oracle.com>
 <cb974ee6-1af0-b710-0413-345aab730bbe@redhat.com>
 <60a9ed9e-4bf2-751c-eaa8-17bf0cdc261f@oracle.com>
 <d2700c80-11d2-61c3-6260-150973370e97@oracle.com>
Message-ID: <5AC7AF92.8070804@oracle.com>



On 04/06/2018 09:57 AM, Erik Joelsson wrote:
> On 2018-04-06 09:51, Jonathan Gibbons wrote:
>>
>> I think the N-1 policy should be more clearly stated as "last GA".
>>
>> When we started work on JDK 11, JDK 10 had not yet shipped, and so it
>> was appropriate for JDK 11 to use JDK 9 as the boot jdk.  Now that 
>> JDK 10
>> has shipped, it becomes a candidate to be a boot JDK, and becomes
>> the most recent GA JDK version.
>>
> I like that, but don't you mean min("last GA", N-1)?
>
> /Erik
>

Yes, I guess the difference comes into play for updates, when JDK N 
might itself
be GA.

I guess you could less mathematically describe it as the "previous GA" 
policy.

-- Jon


From mikael.vidstedt at oracle.com  Fri Apr  6 22:04:26 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 6 Apr 2018 15:04:26 -0700
Subject: RFR: JDK-8201263: Traling backslash in VS120COMNTOOLS leads to ugly
 error message when running tests
Message-ID: <58300D53-4086-46ED-AB80-AB3BAAFCAE56@oracle.com>


Please review this change which addresses a minor issue when running tests on some Windows machines.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201263
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ <http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/>

* Background (from the bug)

When running tests using Make on a (Windows) machine where VS120COMNTOOLS is set an error message is generated.

/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file

The message is generated by this logic in test/TestCommon.gmk:

ifneq ($(VS120COMNTOOLS), )
  JTREG_BASIC_OPTIONS += -e:VS120COMNTOOLS=$(shell $(GETMIXEDPATH) "$(VS120COMNTOOLS)")
endif

The problem is that the VS120COMNTOOLS variable typically looks something like:

$ echo $VS120COMNTOOLS
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\

Of particular interest is the fact that it has a trailing backslash. When used in the make file that means it will all be expanded to something like:

JTREG_BASIC_OPTIONS += ... $(shell cygwin -m "c:\<path>\Common7\Tools\")

When that in turn gets executed the backslash will escape the last double quote which means that the quotes are no longer paired.


* Fix

The fix removes the trailing backslash (if there is one). I verified the fix locally, and I?m running more CI testing on it now.

Cheers,
Mikael



From alexey.ivanov at oracle.com  Fri Apr  6 22:14:20 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Fri, 6 Apr 2018 23:14:20 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
Message-ID: <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>

Hi Magnus, Matthias,

I tried to build 32 bit Windows but it fails to run for me with
Corrupted ZIP library: 
c:\work\jdk-dev\build\windows-x86-normal-server-release\jdk\bin\zip.dll

The problem is that zip.dll exports all symbols as C++ rather than C.
For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and classLoader.cpp 
cannot find the function.


I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as 
this function is correctly decorated in CRC32.c and is exported.

Regards,
Alexey

On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> I think it's reasonable to update the existing webrev.
>
> /Magnus
>
>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>>
>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>   
>> The   follow up change  that removed   mapfiles for  exes  as well    leads on Win32 bit  to  this link error :
>>   
>>    Creating library C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : fatal error LNK1120: 1 unresolved externals
>>   
>>   
>> Looks like we  cannot have   JNICALL   in main.c   :
>>   
>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04 2018 -0700
>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40 2018 +0200
>> @@ -93,7 +93,7 @@
>>       __initenv = _environ;
>>   
>> #else /* JAVAW */
>> -JNIEXPORT int JNICALL
>> +JNIEXPORT int
>> main(int argc, char **argv)
>> {
>>       int margc;
>>   
>>   
>> Zip-library  has runtime issues   when  symbols  are resolved  in  src/hotspot/share/classfile/classLoader.cpp.
>> I added  the declaration of the missing symbol, this seems to fix it .
>>   
>>   
>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04 2018 -0700
>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40 2018 +0200
>> @@ -284,4 +284,7 @@
>> JNIEXPORT jboolean JNICALL
>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
>>   
>> +JNIEXPORT jint JNICALL
>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>> +
>>   
>>   
>> Should I  prepare  another  bug,  or  add this to the existing one and    post a second webrev ?
>>   
>> Best regards, Matthias
>>   
>>   
>> From: Baesken, Matthias
>> Sent: Freitag, 6. April 2018 09:54
>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>>   
>> Hello, please review :
>>   
>> Bug :
>>   
>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>   
>> change :
>>   
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>   
>> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build missed it .
>>   
>> A difference is  src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>> Where I removed   a few  declarations  (one  decl   with one without  JNIEXPORT / JNICALL ? looked a bit strange ) .
>>   
>> Best regards , Matthias
>>   
>>   
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>> Sent: Donnerstag, 5. April 2018 17:45
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>>   
>> That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal.
>>   
>> I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed.
>>   
>> Please do submit your patch.
>>   
>> I'm a bit surprised 32-bit Window is still buildable. :)
>>
>> /Magnus
>>
>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>>
>> Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
>> The implementation of functions.
>> While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :
>>   
>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>>          e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'
>>   
>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>   
>>   
>> Another example is this one :
>>   
>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
>> @@ -126,7 +126,7 @@
>>    *   JImageLocationRef location = (*JImageFindResource)(image,
>>    *                                "java.base", "9.0", "java/lang/String.class", &size);
>>    */
>> -extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
>> +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
>>           const char* module_name, const char* version, const char* name,
>>           jlong* size);
>>   
>>   
>> Is there some generic way to get  the  same  declarations / impementations   in the code  ?
>>   
>> Or should I just add a patch with my findings ?
>>   
>> Best regards, Matthias
>>   



From erik.joelsson at oracle.com  Fri Apr  6 22:17:21 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 15:17:21 -0700
Subject: RFR: JDK-8201263: Traling backslash in VS120COMNTOOLS leads to
 ugly error message when running tests
In-Reply-To: <58300D53-4086-46ED-AB80-AB3BAAFCAE56@oracle.com>
References: <58300D53-4086-46ED-AB80-AB3BAAFCAE56@oracle.com>
Message-ID: <8ed90ef9-a8b1-a403-e9eb-d0b05df28e53@oracle.com>

Looks good.

/Erik


On 2018-04-06 15:04, Mikael Vidstedt wrote:
> Please review this change which addresses a minor issue when running tests on some Windows machines.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201263
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ <http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/>
>
> * Background (from the bug)
>
> When running tests using Make on a (Windows) machine where VS120COMNTOOLS is set an error message is generated.
>
> /bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
> /bin/sh: -c: line 1: syntax error: unexpected end of file
>
> The message is generated by this logic in test/TestCommon.gmk:
>
> ifneq ($(VS120COMNTOOLS), )
>    JTREG_BASIC_OPTIONS += -e:VS120COMNTOOLS=$(shell $(GETMIXEDPATH) "$(VS120COMNTOOLS)")
> endif
>
> The problem is that the VS120COMNTOOLS variable typically looks something like:
>
> $ echo $VS120COMNTOOLS
> C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
>
> Of particular interest is the fact that it has a trailing backslash. When used in the make file that means it will all be expanded to something like:
>
> JTREG_BASIC_OPTIONS += ... $(shell cygwin -m "c:\<path>\Common7\Tools\")
>
> When that in turn gets executed the backslash will escape the last double quote which means that the quotes are no longer paired.
>
>
> * Fix
>
> The fix removes the trailing backslash (if there is one). I verified the fix locally, and I?m running more CI testing on it now.
>
> Cheers,
> Mikael
>



From erik.joelsson at oracle.com  Fri Apr  6 23:04:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 16:04:36 -0700
Subject: RFR: JDK-8201267: Disable warnings for VS2017 to enable building
Message-ID: <ed46008e-0586-5eef-61a4-8523303ec10d@oracle.com>

We are rather close to being able to build the JDK using VS2017. There 
are still some warnings that need to be disabled (separate issues filed 
to fix them) and some other minor build tweaks that has surfaced now 
that Hotspot builds successfully.

With this patch, it should be possible to build using VS2017.

Notes on changes:

* In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all 
directories sent in here are already fixed. Calling it here messes up 
the filename of the dll, which in VS2017 is more than 8 chars.

* In NativeCompilation.gmk, this is unrelated but fixes incremental 
builds on Windows. Adlc.exe gets relinked every time otherwise.

* Reentrancy.c is a fix for JDK-8201215 suggested in bug comments there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201267
Webrev: http://cr.openjdk.java.net/~erikj/8201267/webrev.01/index.html

/Erik


From mikael.vidstedt at oracle.com  Sat Apr  7 04:24:21 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 6 Apr 2018 21:24:21 -0700
Subject: RFR: JDK-8201263: Traling backslash in VS120COMNTOOLS leads to
 ugly error message when running tests
In-Reply-To: <8ed90ef9-a8b1-a403-e9eb-d0b05df28e53@oracle.com>
References: <58300D53-4086-46ED-AB80-AB3BAAFCAE56@oracle.com>
 <8ed90ef9-a8b1-a403-e9eb-d0b05df28e53@oracle.com>
Message-ID: <B44A9288-CD7F-4505-9F17-6292E97BA3C6@oracle.com>


Testing revealed that the fix solved the immediate problem of removing the error message, but a similar problem occurred when the resulting JTREG_BASIC_OPTIONS variable is then used. Specifically the problem is that the path returned from the shell execution (still) contains spaces, so the resulting string also needs to be quoted. This version has passed the typical CI job:

http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.01/open/webrev/>

Cheers,
Mikael

> On Apr 6, 2018, at 3:17 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Looks good.
> 
> /Erik
> 
> 
> On 2018-04-06 15:04, Mikael Vidstedt wrote:
>> Please review this change which addresses a minor issue when running tests on some Windows machines.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201263
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ <http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/>
>> 
>> * Background (from the bug)
>> 
>> When running tests using Make on a (Windows) machine where VS120COMNTOOLS is set an error message is generated.
>> 
>> /bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
>> /bin/sh: -c: line 1: syntax error: unexpected end of file
>> 
>> The message is generated by this logic in test/TestCommon.gmk:
>> 
>> ifneq ($(VS120COMNTOOLS), )
>>   JTREG_BASIC_OPTIONS += -e:VS120COMNTOOLS=$(shell $(GETMIXEDPATH) "$(VS120COMNTOOLS)")
>> endif
>> 
>> The problem is that the VS120COMNTOOLS variable typically looks something like:
>> 
>> $ echo $VS120COMNTOOLS
>> C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
>> 
>> Of particular interest is the fact that it has a trailing backslash. When used in the make file that means it will all be expanded to something like:
>> 
>> JTREG_BASIC_OPTIONS += ... $(shell cygwin -m "c:\<path>\Common7\Tools\")
>> 
>> When that in turn gets executed the backslash will escape the last double quote which means that the quotes are no longer paired.
>> 
>> 
>> * Fix
>> 
>> The fix removes the trailing backslash (if there is one). I verified the fix locally, and I?m running more CI testing on it now.
>> 
>> Cheers,
>> Mikael
>> 
> 



From simon at cjnash.com  Sun Apr  8 14:30:04 2018
From: simon at cjnash.com (Simon Nash)
Date: Sun, 08 Apr 2018 15:30:04 +0100
Subject: Supported platforms (was: Re: Execution problems with Atomic
 Operations on OpenJDK10 for ARM5 Soft Float)
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <5ACA276C.7030505@cjnash.com>

On 05/04/2018 02:26, bren at juanantonio.info wrote:
> 
> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
> 
This appears to be a list of the platforms that are supported (certified) by
Oracle.  Where can I find the list of platforms that are supported by
OpenJDK?  For example, what about the following platforms that don't appear
on the Oracle list:

Windows x86
Linux x86
aarch32 (ARMv7 32-bit)
aarch64 (ARMv8 64-bit)

Are all these supported for OpenJDK 9, 10 and 11?

Simon


From martinrb at google.com  Sun Apr  8 20:22:11 2018
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 8 Apr 2018 13:22:11 -0700
Subject: RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10
In-Reply-To: <0eeab300-b6b3-d2bc-07d3-2a1aee31852d@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <758cb820-a27b-69aa-0f20-998aada5791f@oracle.com>
 <5b063633-5e7c-e9d2-5a22-dfd7b26e6294@oracle.com>
 <5AC53CF4.10007@oracle.com> <490fdde2-ed0a-6fd4-eba0-1ba2d8d51903@oracle.com>
 <CA+kOe08_4d4fhG0ymA_oy2g84wRBqHH=6_jgFmO=Vz4uCjPDKw@mail.gmail.com>
 <6ee5a8cc-a548-7fd6-1987-84fafa943686@oracle.com>
 <0eeab300-b6b3-d2bc-07d3-2a1aee31852d@oracle.com>
Message-ID: <CA+kOe0_uvreZ54BnA=X3ozmnzYzEupkaUs3bnaMYUQgXXKsiiQ@mail.gmail.com>

On Fri, Apr 6, 2018 at 2:50 AM, dalibor topic <dalibor.topic at oracle.com>
wrote:

>
> For example, if someone sufficiently qualified decided to make future JDK
> 10 updates buildable using the full range of JDK 1.0 - JDK 10, as Martin
> seemingly suggests, they could pursue that effort as future JDK 10 update
> maintainers instead of trying to make it work and keep it working in the
> faster paced mainline jdk/jdk development tree.
>

I think this is something where the project as a whole needs a policy.
People working on a project all have to agree on what programming language
they're using.
I like the "last LTS" rule, and I'm still hoping the openjdk project will
have well-defined LTS releases.


From magnus.ihse.bursie at oracle.com  Mon Apr  9 07:55:09 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 09:55:09 +0200
Subject: Supported platforms
In-Reply-To: <5ACA276C.7030505@cjnash.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <5ACA276C.7030505@cjnash.com>
Message-ID: <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>

Simon,

On 2018-04-08 16:30, Simon Nash wrote:
> On 05/04/2018 02:26, bren at juanantonio.info wrote:
>>
>> Many thanks with the link about the Platforms supported:
>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
>>
> This appears to be a list of the platforms that are supported 
> (certified) by
> Oracle.? Where can I find the list of platforms that are supported by
> OpenJDK?? For example, what about the following platforms that don't 
> appear
> on the Oracle list:
>
> Windows x86
> Linux x86
> aarch32 (ARMv7 32-bit)
> aarch64 (ARMv8 64-bit)
>
> Are all these supported for OpenJDK 9, 10 and 11?

There is actually no such thing as a "supported OpenJDK platform". While 
I hope things may change in the future, OpenJDK as an organization does 
not publicize any list of "supported" platforms. Oracle publishes a list 
of platforms they support, and I presume that Red Hat and SAP and others 
do the same, but the OpenJDK project itself does not.

With that said, platforms which were previously supported by Oracle 
(like the one's you mentioned) tend to still work more-or-less well, but 
they receive no or little testing, and is prone to bit rot.

/Magnus

>
> Simon



From magnus.ihse.bursie at oracle.com  Mon Apr  9 07:56:28 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 09:56:28 +0200
Subject: RFR: JDK-8201267: Disable warnings for VS2017 to enable building
In-Reply-To: <ed46008e-0586-5eef-61a4-8523303ec10d@oracle.com>
References: <ed46008e-0586-5eef-61a4-8523303ec10d@oracle.com>
Message-ID: <b096f64e-9f47-8b4a-28d6-4640cf47635e@oracle.com>

On 2018-04-07 01:04, Erik Joelsson wrote:
> We are rather close to being able to build the JDK using VS2017. There 
> are still some warnings that need to be disabled (separate issues 
> filed to fix them) and some other minor build tweaks that has surfaced 
> now that Hotspot builds successfully.
>
> With this patch, it should be possible to build using VS2017.
>
> Notes on changes:
>
> * In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all 
> directories sent in here are already fixed. Calling it here messes up 
> the filename of the dll, which in VS2017 is more than 8 chars.
>
> * In NativeCompilation.gmk, this is unrelated but fixes incremental 
> builds on Windows. Adlc.exe gets relinked every time otherwise.
>
> * Reentrancy.c is a fix for JDK-8201215 suggested in bug comments there.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201267
> Webrev: http://cr.openjdk.java.net/~erikj/8201267/webrev.01/index.html
Looks good to me.

/Magnus
>
> /Erik



From dalibor.topic at oracle.com  Mon Apr  9 09:57:33 2018
From: dalibor.topic at oracle.com (dalibor topic)
Date: Mon, 9 Apr 2018 11:57:33 +0200
Subject: Supported platforms
In-Reply-To: <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <5ACA276C.7030505@cjnash.com>
 <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
Message-ID: <95b4873c-1b77-bd5e-9fa2-f0a432415130@oracle.com>



On 09.04.2018 09:55, Magnus Ihse Bursie wrote:

> There is actually no such thing as a "supported OpenJDK platform". While 
> I hope things may change in the future, OpenJDK as an organization does 
> not publicize any list of "supported" platforms. Oracle publishes a list 
> of platforms they support, and I presume that Red Hat and SAP and others 
> do the same, but the OpenJDK project itself does not.

To add to that, the list of platforms supported by the latest JDK 10 
OpenJDK binaries can be found at http://jdk.java.net/10/supported .

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From matthias.baesken at sap.com  Mon Apr  9 10:46:11 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Apr 2018 10:46:11 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
Message-ID: <b61a833143884ac0a8388176df125aee@sap.com>

> 
> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> this function is correctly decorated in CRC32.c and is exported.
>

Hi  Alexey,  you are correct  on this one .   The added  declaration does  not help  with the  "Corrupted ZIP library"  error .
This  one can be  fixed  by  bringing back  the  exports  in the makefile     make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :


--- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
+++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
@@ -191,6 +191,9 @@
     DISABLED_WARNINGS_gcc := implicit-fallthrough, \
     LDFLAGS := $(LDFLAGS_JDKLIB) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
+    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -export:ZIP_FindEntry \
+        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
+        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
 ))
@@ -221,6 +224,10 @@
     CFLAGS_unix := -UDEBUG, \
     LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
         $(call SET_SHARED_LIBRARY_ORIGIN), \
+    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
+        -export:JIMAGE_PackageToModule \
+        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
+        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
     LIBS_unix := -ljvm -ldl $(LIBCXX), \
     LIBS_macosx := -lc++, \
     LIBS_windows := jvm.lib, \


I wonder why the 64bit windows build can  live without the  exports  , any ideas ?


Best regards , Matthias


> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Samstag, 7. April 2018 00:14
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> Matthias <matthias.baesken at sap.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Magnus, Matthias,
> 
> I tried to build 32 bit Windows but it fails to run for me with
> Corrupted ZIP library:
> c:\work\jdk-dev\build\windows-x86-normal-server-release\jdk\bin\zip.dll
> 
> The problem is that zip.dll exports all symbols as C++ rather than C.
> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and classLoader.cpp
> cannot find the function.
> 
> 
> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> this function is correctly decorated in CRC32.c and is exported.
> 
> Regards,
> Alexey
> 
> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> > I think it's reasonable to update the existing webrev.
> >
> > /Magnus
> >
> >> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
> <matthias.baesken at sap.com>:
> >>
> >> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> >>
> >> The   follow up change  that removed   mapfiles for  exes  as well    leads
> on Win32 bit  to  this link error :
> >>
> >>    Creating library
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> referenced in function ___tmainCRTStartup
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
> fatal error LNK1120: 1 unresolved externals
> >>
> >>
> >> Looks like we  cannot have   JNICALL   in main.c   :
> >>
> >> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04
> 2018 -0700
> >> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40
> 2018 +0200
> >> @@ -93,7 +93,7 @@
> >>       __initenv = _environ;
> >>
> >> #else /* JAVAW */
> >> -JNIEXPORT int JNICALL
> >> +JNIEXPORT int
> >> main(int argc, char **argv)
> >> {
> >>       int margc;
> >>
> >>
> >> Zip-library  has runtime issues   when  symbols  are resolved  in
> src/hotspot/share/classfile/classLoader.cpp.
> >> I added  the declaration of the missing symbol, this seems to fix it .
> >>
> >>
> >> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
> 2018 -0700
> >> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
> 2018 +0200
> >> @@ -284,4 +284,7 @@
> >> JNIEXPORT jboolean JNICALL
> >> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
> **pmsg);
> >>
> >> +JNIEXPORT jint JNICALL
> >> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >> +
> >>
> >>
> >> Should I  prepare  another  bug,  or  add this to the existing one and    post
> a second webrev ?
> >>
> >> Best regards, Matthias
> >>
> >>
> >> From: Baesken, Matthias
> >> Sent: Freitag, 6. April 2018 09:54
> >> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> >> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> >> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
> function declarations/implementations - was : RE: missing JNIEXPORT /
> JNICALL at some places in function declarations/implementations
> >>
> >> Hello, please review :
> >>
> >> Bug :
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8201226
> >>
> >> change :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>
> >> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit
> build missed it .
> >>
> >> A difference is
> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> >> Where I removed   a few  declarations  (one  decl   with one without
> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >>
> >> Best regards , Matthias
> >>
> >>
> >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >> Sent: Donnerstag, 5. April 2018 17:45
> >> To: Baesken, Matthias <matthias.baesken at sap.com>
> >> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> >> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations
> >>
> >> That's most likely a result of the new JNIEXPORT I added as part of the
> mapfile removal.
> >>
> >> I tried to match header file and C file, but I can certainly have missed
> cases. If I didn't get any warnings, it was hard to know what I missed.
> >>
> >> Please do submit your patch.
> >>
> >> I'm a bit surprised 32-bit Window is still buildable. :)
> >>
> >> /Magnus
> >>
> >> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> <matthias.baesken at sap.com>:
> >>
> >> Hello, we noticed  that  at a number  of places in the coding  ,   the
> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
> the declaration and
> >> The implementation of functions.
> >> While this is ok on most platforms, it seems to fail on Windows 32 bit and
> leads to errors like this one :
> >>
> >>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> ib_ImageConvKernelConvert.c(87) : error C2373:
> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
> >>
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> ib_image_proto.h(2630) : see declaration of
> 'j2d_mlib_ImageConvKernelConvert'
> >>
> >> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
> >>
> >>
> >> Another example is this one :
> >>
> >> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> >> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
> 09:55:16 2018 +0200
> >> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
> 05 17:07:40 2018 +0200
> >> @@ -126,7 +126,7 @@
> >>    *   JImageLocationRef location = (*JImageFindResource)(image,
> >>    *                                "java.base", "9.0", "java/lang/String.class", &size);
> >>    */
> >> -extern "C" JNIEXPORT JImageLocationRef
> JIMAGE_FindResource(JImageFile* jimage,
> >> +extern "C" JNIEXPORT JImageLocationRef JNICALL
> JIMAGE_FindResource(JImageFile* jimage,
> >>           const char* module_name, const char* version, const char* name,
> >>           jlong* size);
> >>
> >>
> >> Is there some generic way to get  the  same  declarations /
> impementations   in the code  ?
> >>
> >> Or should I just add a patch with my findings ?
> >>
> >> Best regards, Matthias
> >>


From magnus.ihse.bursie at oracle.com  Mon Apr  9 11:29:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 13:29:25 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <b61a833143884ac0a8388176df125aee@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
Message-ID: <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>

Reinstating the -export command line options is not the way forward here. As I understood it from private conversation with Alexey, the problem here is the added JNICALL decoration, which affects only win32 (and incorrectly, that is). 

/Magnus

9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:

>> 
>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>> this function is correctly decorated in CRC32.c and is exported.
>> 
> 
> Hi  Alexey,  you are correct  on this one .   The added  declaration does  not help  with the  "Corrupted ZIP library"  error .
> This  one can be  fixed  by  bringing back  the  exports  in the makefile     make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
> 
> 
> --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
> +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
> @@ -191,6 +191,9 @@
>     DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>     LDFLAGS := $(LDFLAGS_JDKLIB) \
>         $(call SET_SHARED_LIBRARY_ORIGIN), \
> +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -export:ZIP_FindEntry \
> +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> +        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> ))
> @@ -221,6 +224,10 @@
>     CFLAGS_unix := -UDEBUG, \
>     LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>         $(call SET_SHARED_LIBRARY_ORIGIN), \
> +    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
> +        -export:JIMAGE_PackageToModule \
> +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> +        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>     LIBS_unix := -ljvm -ldl $(LIBCXX), \
>     LIBS_macosx := -lc++, \
>     LIBS_windows := jvm.lib, \
> 
> 
> I wonder why the 64bit windows build can  live without the  exports  , any ideas ?
> 
> 
> Best regards , Matthias
> 
> 
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Samstag, 7. April 2018 00:14
>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>> Matthias <matthias.baesken at sap.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Hi Magnus, Matthias,
>> 
>> I tried to build 32 bit Windows but it fails to run for me with
>> Corrupted ZIP library:
>> c:\work\jdk-dev\build\windows-x86-normal-server-release\jdk\bin\zip.dll
>> 
>> The problem is that zip.dll exports all symbols as C++ rather than C.
>> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and classLoader.cpp
>> cannot find the function.
>> 
>> 
>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>> this function is correctly decorated in CRC32.c and is exported.
>> 
>> Regards,
>> Alexey
>> 
>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
>>> I think it's reasonable to update the existing webrev.
>>> 
>>> /Magnus
>>> 
>>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
>> <matthias.baesken at sap.com>:
>>>> 
>>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>>> 
>>>> The   follow up change  that removed   mapfiles for  exes  as well    leads
>> on Win32 bit  to  this link error :
>>>> 
>>>>   Creating library
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>> referenced in function ___tmainCRTStartup
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
>> fatal error LNK1120: 1 unresolved externals
>>>> 
>>>> 
>>>> Looks like we  cannot have   JNICALL   in main.c   :
>>>> 
>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04
>> 2018 -0700
>>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40
>> 2018 +0200
>>>> @@ -93,7 +93,7 @@
>>>>      __initenv = _environ;
>>>> 
>>>> #else /* JAVAW */
>>>> -JNIEXPORT int JNICALL
>>>> +JNIEXPORT int
>>>> main(int argc, char **argv)
>>>> {
>>>>      int margc;
>>>> 
>>>> 
>>>> Zip-library  has runtime issues   when  symbols  are resolved  in
>> src/hotspot/share/classfile/classLoader.cpp.
>>>> I added  the declaration of the missing symbol, this seems to fix it .
>>>> 
>>>> 
>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
>> 2018 -0700
>>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
>> 2018 +0200
>>>> @@ -284,4 +284,7 @@
>>>> JNIEXPORT jboolean JNICALL
>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
>> **pmsg);
>>>> 
>>>> +JNIEXPORT jint JNICALL
>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>>> +
>>>> 
>>>> 
>>>> Should I  prepare  another  bug,  or  add this to the existing one and    post
>> a second webrev ?
>>>> 
>>>> Best regards, Matthias
>>>> 
>>>> 
>>>> From: Baesken, Matthias
>>>> Sent: Freitag, 6. April 2018 09:54
>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function declarations/implementations - was : RE: missing JNIEXPORT /
>> JNICALL at some places in function declarations/implementations
>>>> 
>>>> Hello, please review :
>>>> 
>>>> Bug :
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>> 
>>>> change :
>>>> 
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>> 
>>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit
>> build missed it .
>>>> 
>>>> A difference is
>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>>> Where I removed   a few  declarations  (one  decl   with one without
>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>>> 
>>>> Best regards , Matthias
>>>> 
>>>> 
>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>> Sent: Donnerstag, 5. April 2018 17:45
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations
>>>> 
>>>> That's most likely a result of the new JNIEXPORT I added as part of the
>> mapfile removal.
>>>> 
>>>> I tried to match header file and C file, but I can certainly have missed
>> cases. If I didn't get any warnings, it was hard to know what I missed.
>>>> 
>>>> Please do submit your patch.
>>>> 
>>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>> 
>>>> /Magnus
>>>> 
>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>> <matthias.baesken at sap.com>:
>>>> 
>>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
>> the declaration and
>>>> The implementation of functions.
>>>> While this is ok on most platforms, it seems to fail on Windows 32 bit and
>> leads to errors like this one :
>>>> 
>>>> 
>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
>> ib_ImageConvKernelConvert.c(87) : error C2373:
>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>>>> 
>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
>> ib_image_proto.h(2630) : see declaration of
>> 'j2d_mlib_ImageConvKernelConvert'
>>>> 
>>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>>> 
>>>> 
>>>> Another example is this one :
>>>> 
>>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
>> 09:55:16 2018 +0200
>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
>> 05 17:07:40 2018 +0200
>>>> @@ -126,7 +126,7 @@
>>>>   *   JImageLocationRef location = (*JImageFindResource)(image,
>>>>   *                                "java.base", "9.0", "java/lang/String.class", &size);
>>>>   */
>>>> -extern "C" JNIEXPORT JImageLocationRef
>> JIMAGE_FindResource(JImageFile* jimage,
>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>> JIMAGE_FindResource(JImageFile* jimage,
>>>>          const char* module_name, const char* version, const char* name,
>>>>          jlong* size);
>>>> 
>>>> 
>>>> Is there some generic way to get  the  same  declarations /
>> impementations   in the code  ?
>>>> 
>>>> Or should I just add a patch with my findings ?
>>>> 
>>>> Best regards, Matthias
>>>> 
> 



From matthias.baesken at sap.com  Mon Apr  9 11:38:38 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Apr 2018 11:38:38 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
Message-ID: <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>

I did  not add   JNICALL decorations  to  any  libzip functions , please see my webrev :

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

> , the problem here
> is the added JNICALL decoration, which affects only win32 (and incorrectly,
> that is).

so I wonder  which added  JNICALL  decoration   you are refering to .

Best regards, Matthias 


> -----Original Message-----
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> Sent: Montag, 9. April 2018 13:29
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Reinstating the -export command line options is not the way forward here.
> As I understood it from private conversation with Alexey, the problem here
> is the added JNICALL decoration, which affects only win32 (and incorrectly,
> that is).
> 
> /Magnus
> 
> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> >>
> >> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >> this function is correctly decorated in CRC32.c and is exported.
> >>
> >
> > Hi  Alexey,  you are correct  on this one .   The added  declaration does  not
> help  with the  "Corrupted ZIP library"  error .
> > This  one can be  fixed  by  bringing back  the  exports  in the makefile
> make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
> >
> >
> > --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
> > +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
> > @@ -191,6 +191,9 @@
> >     DISABLED_WARNINGS_gcc := implicit-fallthrough, \
> >     LDFLAGS := $(LDFLAGS_JDKLIB) \
> >         $(call SET_SHARED_LIBRARY_ORIGIN), \
> > +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
> export:ZIP_FindEntry \
> > +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> > +        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
> >     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
> >     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> > ))
> > @@ -221,6 +224,10 @@
> >     CFLAGS_unix := -UDEBUG, \
> >     LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
> >         $(call SET_SHARED_LIBRARY_ORIGIN), \
> > +    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
> > +        -export:JIMAGE_PackageToModule \
> > +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> > +        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
> >     LIBS_unix := -ljvm -ldl $(LIBCXX), \
> >     LIBS_macosx := -lc++, \
> >     LIBS_windows := jvm.lib, \
> >
> >
> > I wonder why the 64bit windows build can  live without the  exports  , any
> ideas ?
> >
> >
> > Best regards , Matthias
> >
> >
> >> -----Original Message-----
> >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >> Sent: Samstag, 7. April 2018 00:14
> >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> >> Matthias <matthias.baesken at sap.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Magnus, Matthias,
> >>
> >> I tried to build 32 bit Windows but it fails to run for me with
> >> Corrupted ZIP library:
> >> c:\work\jdk-dev\build\windows-x86-normal-server-
> release\jdk\bin\zip.dll
> >>
> >> The problem is that zip.dll exports all symbols as C++ rather than C.
> >> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and
> classLoader.cpp
> >> cannot find the function.
> >>
> >>
> >> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >> this function is correctly decorated in CRC32.c and is exported.
> >>
> >> Regards,
> >> Alexey
> >>
> >>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> >>> I think it's reasonable to update the existing webrev.
> >>>
> >>> /Magnus
> >>>
> >>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
> >> <matthias.baesken at sap.com>:
> >>>>
> >>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> >>>>
> >>>> The   follow up change  that removed   mapfiles for  exes  as well    leads
> >> on Win32 bit  to  this link error :
> >>>>
> >>>>   Creating library
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
> object
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> >> referenced in function ___tmainCRTStartup
> >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
> :
> >> fatal error LNK1120: 1 unresolved externals
> >>>>
> >>>>
> >>>> Looks like we  cannot have   JNICALL   in main.c   :
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05
> 14:39:04
> >> 2018 -0700
> >>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06
> 15:16:40
> >> 2018 +0200
> >>>> @@ -93,7 +93,7 @@
> >>>>      __initenv = _environ;
> >>>>
> >>>> #else /* JAVAW */
> >>>> -JNIEXPORT int JNICALL
> >>>> +JNIEXPORT int
> >>>> main(int argc, char **argv)
> >>>> {
> >>>>      int margc;
> >>>>
> >>>>
> >>>> Zip-library  has runtime issues   when  symbols  are resolved  in
> >> src/hotspot/share/classfile/classLoader.cpp.
> >>>> I added  the declaration of the missing symbol, this seems to fix it .
> >>>>
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
> >> 2018 -0700
> >>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
> >> 2018 +0200
> >>>> @@ -284,4 +284,7 @@
> >>>> JNIEXPORT jboolean JNICALL
> >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen,
> char
> >> **pmsg);
> >>>>
> >>>> +JNIEXPORT jint JNICALL
> >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >>>> +
> >>>>
> >>>>
> >>>> Should I  prepare  another  bug,  or  add this to the existing one and
> post
> >> a second webrev ?
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>> From: Baesken, Matthias
> >>>> Sent: Freitag, 6. April 2018 09:54
> >>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>
> >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
> >> function declarations/implementations - was : RE: missing JNIEXPORT /
> >> JNICALL at some places in function declarations/implementations
> >>>>
> >>>> Hello, please review :
> >>>>
> >>>> Bug :
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8201226
> >>>>
> >>>> change :
> >>>>
> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>
> >>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the
> win32bit
> >> build missed it .
> >>>>
> >>>> A difference is
> >> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> >>>> Where I removed   a few  declarations  (one  decl   with one without
> >> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >>>>
> >>>> Best regards , Matthias
> >>>>
> >>>>
> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>>> Sent: Donnerstag, 5. April 2018 17:45
> >>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>
> >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
> >> declarations/implementations
> >>>>
> >>>> That's most likely a result of the new JNIEXPORT I added as part of the
> >> mapfile removal.
> >>>>
> >>>> I tried to match header file and C file, but I can certainly have missed
> >> cases. If I didn't get any warnings, it was hard to know what I missed.
> >>>>
> >>>> Please do submit your patch.
> >>>>
> >>>> I'm a bit surprised 32-bit Window is still buildable. :)
> >>>>
> >>>> /Magnus
> >>>>
> >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> >> <matthias.baesken at sap.com>:
> >>>>
> >>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
> >> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
> >> the declaration and
> >>>> The implementation of functions.
> >>>> While this is ok on most platforms, it seems to fail on Windows 32 bit
> and
> >> leads to errors like this one :
> >>>>
> >>>>
> >>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> >> ib_ImageConvKernelConvert.c(87) : error C2373:
> >> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
> modifiers
> >>>>
> >>
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> >> ib_image_proto.h(2630) : see declaration of
> >> 'j2d_mlib_ImageConvKernelConvert'
> >>>>
> >>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
> >>>>
> >>>>
> >>>> Another example is this one :
> >>>>
> >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
> >> 09:55:16 2018 +0200
> >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
> >> 05 17:07:40 2018 +0200
> >>>> @@ -126,7 +126,7 @@
> >>>>   *   JImageLocationRef location = (*JImageFindResource)(image,
> >>>>   *                                "java.base", "9.0", "java/lang/String.class", &size);
> >>>>   */
> >>>> -extern "C" JNIEXPORT JImageLocationRef
> >> JIMAGE_FindResource(JImageFile* jimage,
> >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
> >> JIMAGE_FindResource(JImageFile* jimage,
> >>>>          const char* module_name, const char* version, const char* name,
> >>>>          jlong* size);
> >>>>
> >>>>
> >>>> Is there some generic way to get  the  same  declarations /
> >> impementations   in the code  ?
> >>>>
> >>>> Or should I just add a patch with my findings ?
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >


From magnus.ihse.bursie at oracle.com  Mon Apr  9 11:42:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 13:42:23 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
Message-ID: <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>

Those were added by my patch that removed the map files. 

/Magnus

> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> I did  not add   JNICALL decorations  to  any  libzip functions , please see my webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> 
>> , the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
> 
> so I wonder  which added  JNICALL  decoration   you are refering to .
> 
> Best regards, Matthias 
> 
> 
>> -----Original Message-----
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>> Sent: Montag, 9. April 2018 13:29
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Reinstating the -export command line options is not the way forward here.
>> As I understood it from private conversation with Alexey, the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
>> 
>> /Magnus
>> 
>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>> 
>>>> 
>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>> this function is correctly decorated in CRC32.c and is exported.
>>>> 
>>> 
>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does  not
>> help  with the  "Corrupted ZIP library"  error .
>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
>> make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
>>> 
>>> 
>>> --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
>>> +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
>>> @@ -191,6 +191,9 @@
>>>    DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>>>    LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>        $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
>> export:ZIP_FindEntry \
>>> +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
>>> +        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>>>    LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>>    LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>>> ))
>>> @@ -221,6 +224,10 @@
>>>    CFLAGS_unix := -UDEBUG, \
>>>    LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>>>        $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
>>> +        -export:JIMAGE_PackageToModule \
>>> +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
>>> +        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>>>    LIBS_unix := -ljvm -ldl $(LIBCXX), \
>>>    LIBS_macosx := -lc++, \
>>>    LIBS_windows := jvm.lib, \
>>> 
>>> 
>>> I wonder why the 64bit windows build can  live without the  exports  , any
>> ideas ?
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Samstag, 7. April 2018 00:14
>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>>>> Matthias <matthias.baesken at sap.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>> 
>>>> Hi Magnus, Matthias,
>>>> 
>>>> I tried to build 32 bit Windows but it fails to run for me with
>>>> Corrupted ZIP library:
>>>> c:\work\jdk-dev\build\windows-x86-normal-server-
>> release\jdk\bin\zip.dll
>>>> 
>>>> The problem is that zip.dll exports all symbols as C++ rather than C.
>>>> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and
>> classLoader.cpp
>>>> cannot find the function.
>>>> 
>>>> 
>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>> this function is correctly decorated in CRC32.c and is exported.
>>>> 
>>>> Regards,
>>>> Alexey
>>>> 
>>>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
>>>>> I think it's reasonable to update the existing webrev.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
>>>> <matthias.baesken at sap.com>:
>>>>>> 
>>>>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>>>>> 
>>>>>> The   follow up change  that removed   mapfiles for  exes  as well    leads
>>>> on Win32 bit  to  this link error :
>>>>>> 
>>>>>>  Creating library
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
>> object
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>>>> referenced in function ___tmainCRTStartup
>>>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
>> :
>>>> fatal error LNK1120: 1 unresolved externals
>>>>>> 
>>>>>> 
>>>>>> Looks like we  cannot have   JNICALL   in main.c   :
>>>>>> 
>>>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>>>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05
>> 14:39:04
>>>> 2018 -0700
>>>>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06
>> 15:16:40
>>>> 2018 +0200
>>>>>> @@ -93,7 +93,7 @@
>>>>>>     __initenv = _environ;
>>>>>> 
>>>>>> #else /* JAVAW */
>>>>>> -JNIEXPORT int JNICALL
>>>>>> +JNIEXPORT int
>>>>>> main(int argc, char **argv)
>>>>>> {
>>>>>>     int margc;
>>>>>> 
>>>>>> 
>>>>>> Zip-library  has runtime issues   when  symbols  are resolved  in
>>>> src/hotspot/share/classfile/classLoader.cpp.
>>>>>> I added  the declaration of the missing symbol, this seems to fix it .
>>>>>> 
>>>>>> 
>>>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>>>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
>>>> 2018 -0700
>>>>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
>>>> 2018 +0200
>>>>>> @@ -284,4 +284,7 @@
>>>>>> JNIEXPORT jboolean JNICALL
>>>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen,
>> char
>>>> **pmsg);
>>>>>> 
>>>>>> +JNIEXPORT jint JNICALL
>>>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>>>>> +
>>>>>> 
>>>>>> 
>>>>>> Should I  prepare  another  bug,  or  add this to the existing one and
>> post
>>>> a second webrev ?
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Freitag, 6. April 2018 09:54
>>>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>> <martin.doerr at sap.com>
>>>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function declarations/implementations - was : RE: missing JNIEXPORT /
>>>> JNICALL at some places in function declarations/implementations
>>>>>> 
>>>>>> Hello, please review :
>>>>>> 
>>>>>> Bug :
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>> 
>>>>>> change :
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>>> 
>>>>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the
>> win32bit
>>>> build missed it .
>>>>>> 
>>>>>> A difference is
>>>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>>>>> Where I removed   a few  declarations  (one  decl   with one without
>>>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>>>>> 
>>>>>> Best regards , Matthias
>>>>>> 
>>>>>> 
>>>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>>>> Sent: Donnerstag, 5. April 2018 17:45
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>> <martin.doerr at sap.com>
>>>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>>>> declarations/implementations
>>>>>> 
>>>>>> That's most likely a result of the new JNIEXPORT I added as part of the
>>>> mapfile removal.
>>>>>> 
>>>>>> I tried to match header file and C file, but I can certainly have missed
>>>> cases. If I didn't get any warnings, it was hard to know what I missed.
>>>>>> 
>>>>>> Please do submit your patch.
>>>>>> 
>>>>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>>>> 
>>>>>> /Magnus
>>>>>> 
>>>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>>>> <matthias.baesken at sap.com>:
>>>>>> 
>>>>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
>>>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
>>>> the declaration and
>>>>>> The implementation of functions.
>>>>>> While this is ok on most platforms, it seems to fail on Windows 32 bit
>> and
>>>> leads to errors like this one :
>>>>>> 
>>>>>> 
>>>> 
>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
>>>> ib_ImageConvKernelConvert.c(87) : error C2373:
>>>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
>> modifiers
>>>>>> 
>>>> 
>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
>>>> ib_image_proto.h(2630) : see declaration of
>>>> 'j2d_mlib_ImageConvKernelConvert'
>>>>>> 
>>>>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>>>>> 
>>>>>> 
>>>>>> Another example is this one :
>>>>>> 
>>>>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
>>>> 09:55:16 2018 +0200
>>>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
>>>> 05 17:07:40 2018 +0200
>>>>>> @@ -126,7 +126,7 @@
>>>>>>  *   JImageLocationRef location = (*JImageFindResource)(image,
>>>>>>  *                                "java.base", "9.0", "java/lang/String.class", &size);
>>>>>>  */
>>>>>> -extern "C" JNIEXPORT JImageLocationRef
>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>>         const char* module_name, const char* version, const char* name,
>>>>>>         jlong* size);
>>>>>> 
>>>>>> 
>>>>>> Is there some generic way to get  the  same  declarations /
>>>> impementations   in the code  ?
>>>>>> 
>>>>>> Or should I just add a patch with my findings ?
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>> 
> 



From magnus.ihse.bursie at oracle.com  Mon Apr  9 11:47:21 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 13:47:21 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
Message-ID: <C455D5CD-4459-4750-AE08-D99B8D494CED@oracle.com>

Also, I'm not sure if I said it, but I think your original webrev looks good.

/Magnus

> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> I did  not add   JNICALL decorations  to  any  libzip functions , please see my webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> 
>> , the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
> 
> so I wonder  which added  JNICALL  decoration   you are refering to .
> 
> Best regards, Matthias 
> 
> 
>> -----Original Message-----
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>> Sent: Montag, 9. April 2018 13:29
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Reinstating the -export command line options is not the way forward here.
>> As I understood it from private conversation with Alexey, the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
>> 
>> /Magnus
>> 
>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>> 
>>>> 
>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>> this function is correctly decorated in CRC32.c and is exported.
>>>> 
>>> 
>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does  not
>> help  with the  "Corrupted ZIP library"  error .
>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
>> make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
>>> 
>>> 
>>> --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
>>> +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
>>> @@ -191,6 +191,9 @@
>>>    DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>>>    LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>        $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
>> export:ZIP_FindEntry \
>>> +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
>>> +        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>>>    LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>>    LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>>> ))
>>> @@ -221,6 +224,10 @@
>>>    CFLAGS_unix := -UDEBUG, \
>>>    LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>>>        $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
>>> +        -export:JIMAGE_PackageToModule \
>>> +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
>>> +        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>>>    LIBS_unix := -ljvm -ldl $(LIBCXX), \
>>>    LIBS_macosx := -lc++, \
>>>    LIBS_windows := jvm.lib, \
>>> 
>>> 
>>> I wonder why the 64bit windows build can  live without the  exports  , any
>> ideas ?
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Samstag, 7. April 2018 00:14
>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>>>> Matthias <matthias.baesken at sap.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>> 
>>>> Hi Magnus, Matthias,
>>>> 
>>>> I tried to build 32 bit Windows but it fails to run for me with
>>>> Corrupted ZIP library:
>>>> c:\work\jdk-dev\build\windows-x86-normal-server-
>> release\jdk\bin\zip.dll
>>>> 
>>>> The problem is that zip.dll exports all symbols as C++ rather than C.
>>>> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and
>> classLoader.cpp
>>>> cannot find the function.
>>>> 
>>>> 
>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>> this function is correctly decorated in CRC32.c and is exported.
>>>> 
>>>> Regards,
>>>> Alexey
>>>> 
>>>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
>>>>> I think it's reasonable to update the existing webrev.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
>>>> <matthias.baesken at sap.com>:
>>>>>> 
>>>>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>>>>> 
>>>>>> The   follow up change  that removed   mapfiles for  exes  as well    leads
>>>> on Win32 bit  to  this link error :
>>>>>> 
>>>>>>  Creating library
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
>> object
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>>>> referenced in function ___tmainCRTStartup
>>>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
>> :
>>>> fatal error LNK1120: 1 unresolved externals
>>>>>> 
>>>>>> 
>>>>>> Looks like we  cannot have   JNICALL   in main.c   :
>>>>>> 
>>>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>>>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05
>> 14:39:04
>>>> 2018 -0700
>>>>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06
>> 15:16:40
>>>> 2018 +0200
>>>>>> @@ -93,7 +93,7 @@
>>>>>>     __initenv = _environ;
>>>>>> 
>>>>>> #else /* JAVAW */
>>>>>> -JNIEXPORT int JNICALL
>>>>>> +JNIEXPORT int
>>>>>> main(int argc, char **argv)
>>>>>> {
>>>>>>     int margc;
>>>>>> 
>>>>>> 
>>>>>> Zip-library  has runtime issues   when  symbols  are resolved  in
>>>> src/hotspot/share/classfile/classLoader.cpp.
>>>>>> I added  the declaration of the missing symbol, this seems to fix it .
>>>>>> 
>>>>>> 
>>>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>>>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
>>>> 2018 -0700
>>>>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
>>>> 2018 +0200
>>>>>> @@ -284,4 +284,7 @@
>>>>>> JNIEXPORT jboolean JNICALL
>>>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen,
>> char
>>>> **pmsg);
>>>>>> 
>>>>>> +JNIEXPORT jint JNICALL
>>>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>>>>> +
>>>>>> 
>>>>>> 
>>>>>> Should I  prepare  another  bug,  or  add this to the existing one and
>> post
>>>> a second webrev ?
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>> From: Baesken, Matthias
>>>>>> Sent: Freitag, 6. April 2018 09:54
>>>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>> <martin.doerr at sap.com>
>>>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function declarations/implementations - was : RE: missing JNIEXPORT /
>>>> JNICALL at some places in function declarations/implementations
>>>>>> 
>>>>>> Hello, please review :
>>>>>> 
>>>>>> Bug :
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>> 
>>>>>> change :
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>>> 
>>>>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the
>> win32bit
>>>> build missed it .
>>>>>> 
>>>>>> A difference is
>>>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>>>>> Where I removed   a few  declarations  (one  decl   with one without
>>>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>>>>> 
>>>>>> Best regards , Matthias
>>>>>> 
>>>>>> 
>>>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>>>> Sent: Donnerstag, 5. April 2018 17:45
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>> <martin.doerr at sap.com>
>>>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>>>> declarations/implementations
>>>>>> 
>>>>>> That's most likely a result of the new JNIEXPORT I added as part of the
>>>> mapfile removal.
>>>>>> 
>>>>>> I tried to match header file and C file, but I can certainly have missed
>>>> cases. If I didn't get any warnings, it was hard to know what I missed.
>>>>>> 
>>>>>> Please do submit your patch.
>>>>>> 
>>>>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>>>> 
>>>>>> /Magnus
>>>>>> 
>>>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>>>> <matthias.baesken at sap.com>:
>>>>>> 
>>>>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
>>>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
>>>> the declaration and
>>>>>> The implementation of functions.
>>>>>> While this is ok on most platforms, it seems to fail on Windows 32 bit
>> and
>>>> leads to errors like this one :
>>>>>> 
>>>>>> 
>>>> 
>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
>>>> ib_ImageConvKernelConvert.c(87) : error C2373:
>>>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
>> modifiers
>>>>>> 
>>>> 
>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
>>>> ib_image_proto.h(2630) : see declaration of
>>>> 'j2d_mlib_ImageConvKernelConvert'
>>>>>> 
>>>>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>>>>> 
>>>>>> 
>>>>>> Another example is this one :
>>>>>> 
>>>>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
>>>> 09:55:16 2018 +0200
>>>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
>>>> 05 17:07:40 2018 +0200
>>>>>> @@ -126,7 +126,7 @@
>>>>>>  *   JImageLocationRef location = (*JImageFindResource)(image,
>>>>>>  *                                "java.base", "9.0", "java/lang/String.class", &size);
>>>>>>  */
>>>>>> -extern "C" JNIEXPORT JImageLocationRef
>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>>         const char* module_name, const char* version, const char* name,
>>>>>>         jlong* size);
>>>>>> 
>>>>>> 
>>>>>> Is there some generic way to get  the  same  declarations /
>>>> impementations   in the code  ?
>>>>>> 
>>>>>> Or should I just add a patch with my findings ?
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>> 
> 



From sgehwolf at redhat.com  Mon Apr  9 13:39:52 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Apr 2018 15:39:52 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing
 unresolved symbols
Message-ID: <1523281192.148486.9.camel@redhat.com>

Hi,

Could somebody please review this build fix for libfontmanager.so. The
issue for us is that with some LDFLAGS the build breaks as described in
bug JDK-8196218. However, we cannot link to a providing library at
build-time since we don't know which one it should be: libawt_headless
or libawt_xawt. That has to happen at runtime. The proposed fix filters
out relevant linker flags when libfontmanager is being built. More
details are in the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/

Testing: I've run this through submit[1] and got the following results.
SwingSet2 works fine for me on F27. I'm currently running some more
tests on RHEL 7.

---------------------
Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.

0 Failed Tests

Mach5 Tasks Results Summary

NA: 0
UNABLE_TO_RUN: 0
EXECUTED_WITH_FAILURE: 0
KILLED: 0
PASSED: 82
FAILED: 1
Test

1 Failed

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
return value: 10
--------------------

Not sure what this test failure means. Could somebody at Oracle shed
some light on this?

Thanks,
Severin


From alexey.ivanov at oracle.com  Mon Apr  9 13:51:41 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 9 Apr 2018 14:51:41 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
Message-ID: <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>

Hi Matthias, Magnus,

The problem is with JNICALL added to the functions. JNICALL expands to 
__stdcall [1] on Windows. On 64 bit, the modifier has no effect and is 
ignored. On 32 bit, the modifier changes the way parameters are pass and 
the function name is decorated with an underscore and with @ + the size 
of arguments.

If I remove JNICALL modifier from the exported functions, they're 
exported with plain name as in source code (plus, __cdecl [2] calling 
convention is used.)

zip.dll and jimage.dll are affected by this. It's because the exported 
functions are looked up by name rather than using a header file with 
JNIIMPORT. See
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l1155
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l1194

JNICALL modifier must also be removed from type declarations for 
functions from zip.dll:
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l81

I'm attaching the patch to zip and jimage as well as classLoader.cpp 
which takes these changes into account. It does not replace Matthias' 
patch but complements it.


Alternatively, if keeping JNICALL / __stdcall, it's possible to use 
pragma comments [3][4] to export undecorated names. But this is compiler 
specific and may require if's for other platforms.


Regards,
Alexey

[1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
[2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
[3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
[4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp

On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
> Those were added by my patch that removed the map files.
>
> /Magnus
>
>> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>>
>> I did  not add   JNICALL decorations  to  any  libzip functions , please see my webrev :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>
>>> , the problem here
>>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>>> that is).
>> so I wonder  which added  JNICALL  decoration   you are refering to .
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>> Sent: Montag, 9. April 2018 13:29
>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>> Reinstating the -export command line options is not the way forward here.
>>> As I understood it from private conversation with Alexey, the problem here
>>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>>> that is).
>>>
>>> /Magnus
>>>
>>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias <matthias.baesken at sap.com>:
>>>
>>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>>> this function is correctly decorated in CRC32.c and is exported.
>>>>>
>>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does  not
>>> help  with the  "Corrupted ZIP library"  error .
>>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
>>> make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
>>>>
>>>> --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
>>>> +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
>>>> @@ -191,6 +191,9 @@
>>>>     DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>>>>     LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>         $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>> +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
>>> export:ZIP_FindEntry \
>>>> +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
>>>> +        -export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>>>>     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>>>     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>>>> ))
>>>> @@ -221,6 +224,10 @@
>>>>     CFLAGS_unix := -UDEBUG, \
>>>>     LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>>>>         $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>> +    LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
>>>> +        -export:JIMAGE_PackageToModule \
>>>> +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
>>>> +        -export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>>>>     LIBS_unix := -ljvm -ldl $(LIBCXX), \
>>>>     LIBS_macosx := -lc++, \
>>>>     LIBS_windows := jvm.lib, \
>>>>
>>>>
>>>> I wonder why the 64bit windows build can  live without the  exports  , any
>>> ideas ?
>>>>
>>>> Best regards , Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Samstag, 7. April 2018 00:14
>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>>>>> Matthias <matthias.baesken at sap.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Hi Magnus, Matthias,
>>>>>
>>>>> I tried to build 32 bit Windows but it fails to run for me with
>>>>> Corrupted ZIP library:
>>>>> c:\work\jdk-dev\build\windows-x86-normal-server-
>>> release\jdk\bin\zip.dll
>>>>> The problem is that zip.dll exports all symbols as C++ rather than C.
>>>>> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and
>>> classLoader.cpp
>>>>> cannot find the function.
>>>>>
>>>>>
>>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>>>>> this function is correctly decorated in CRC32.c and is exported.
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
>>>>>> I think it's reasonable to update the existing webrev.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
>>>>> <matthias.baesken at sap.com>:
>>>>>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>>>>>>
>>>>>>> The   follow up change  that removed   mapfiles for  exes  as well    leads
>>>>> on Win32 bit  to  this link error :
>>>>>>>   Creating library
>>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
>>> object
>>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>>>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>>>>> referenced in function ___tmainCRTStartup
>>>>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
>>> :
>>>>> fatal error LNK1120: 1 unresolved externals
>>>>>>>
>>>>>>> Looks like we  cannot have   JNICALL   in main.c   :
>>>>>>>
>>>>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>>>>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05
>>> 14:39:04
>>>>> 2018 -0700
>>>>>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06
>>> 15:16:40
>>>>> 2018 +0200
>>>>>>> @@ -93,7 +93,7 @@
>>>>>>>      __initenv = _environ;
>>>>>>>
>>>>>>> #else /* JAVAW */
>>>>>>> -JNIEXPORT int JNICALL
>>>>>>> +JNIEXPORT int
>>>>>>> main(int argc, char **argv)
>>>>>>> {
>>>>>>>      int margc;
>>>>>>>
>>>>>>>
>>>>>>> Zip-library  has runtime issues   when  symbols  are resolved  in
>>>>> src/hotspot/share/classfile/classLoader.cpp.
>>>>>>> I added  the declaration of the missing symbol, this seems to fix it .
>>>>>>>
>>>>>>>
>>>>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>>>>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
>>>>> 2018 -0700
>>>>>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
>>>>> 2018 +0200
>>>>>>> @@ -284,4 +284,7 @@
>>>>>>> JNIEXPORT jboolean JNICALL
>>>>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen,
>>> char
>>>>> **pmsg);
>>>>>>> +JNIEXPORT jint JNICALL
>>>>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>>>>>> +
>>>>>>>
>>>>>>>
>>>>>>> Should I  prepare  another  bug,  or  add this to the existing one and
>>> post
>>>>> a second webrev ?
>>>>>>> Best regards, Matthias
>>>>>>>
>>>>>>>
>>>>>>> From: Baesken, Matthias
>>>>>>> Sent: Freitag, 6. April 2018 09:54
>>>>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>>> <martin.doerr at sap.com>
>>>>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function declarations/implementations - was : RE: missing JNIEXPORT /
>>>>> JNICALL at some places in function declarations/implementations
>>>>>>> Hello, please review :
>>>>>>>
>>>>>>> Bug :
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>>>
>>>>>>> change :
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>>>>
>>>>>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the
>>> win32bit
>>>>> build missed it .
>>>>>>> A difference is
>>>>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>>>>>> Where I removed   a few  declarations  (one  decl   with one without
>>>>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>>>>>> Best regards , Matthias
>>>>>>>
>>>>>>>
>>>>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>>>>> Sent: Donnerstag, 5. April 2018 17:45
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>>>>> declarations/implementations
>>>>>>> That's most likely a result of the new JNIEXPORT I added as part of the
>>>>> mapfile removal.
>>>>>>> I tried to match header file and C file, but I can certainly have missed
>>>>> cases. If I didn't get any warnings, it was hard to know what I missed.
>>>>>>> Please do submit your patch.
>>>>>>>
>>>>>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>>>>> <matthias.baesken at sap.com>:
>>>>>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
>>>>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
>>>>> the declaration and
>>>>>>> The implementation of functions.
>>>>>>> While this is ok on most platforms, it seems to fail on Windows 32 bit
>>> and
>>>>> leads to errors like this one :
>>>>>>>
>>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
>>>>> ib_ImageConvKernelConvert.c(87) : error C2373:
>>>>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
>>> modifiers
>>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
>>>>> ib_image_proto.h(2630) : see declaration of
>>>>> 'j2d_mlib_ImageConvKernelConvert'
>>>>>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>>>>>>
>>>>>>>
>>>>>>> Another example is this one :
>>>>>>>
>>>>>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>>>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
>>>>> 09:55:16 2018 +0200
>>>>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr
>>>>> 05 17:07:40 2018 +0200
>>>>>>> @@ -126,7 +126,7 @@
>>>>>>>   *   JImageLocationRef location = (*JImageFindResource)(image,
>>>>>>>   *                                "java.base", "9.0", "java/lang/String.class", &size);
>>>>>>>   */
>>>>>>> -extern "C" JNIEXPORT JImageLocationRef
>>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>>>>> JIMAGE_FindResource(JImageFile* jimage,
>>>>>>>          const char* module_name, const char* version, const char* name,
>>>>>>>          jlong* size);
>>>>>>>
>>>>>>>
>>>>>>> Is there some generic way to get  the  same  declarations /
>>>>> impementations   in the code  ?
>>>>>>> Or should I just add a patch with my findings ?
>>>>>>>
>>>>>>> Best regards, Matthias
>>>>>>>

-------------- next part --------------
diff -r b9df14155468 src/hotspot/share/classfile/classLoader.cpp
--- a/src/hotspot/share/classfile/classLoader.cpp	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/hotspot/share/classfile/classLoader.cpp	Mon Apr 09 14:36:33 2018 +0100
@@ -80,13 +80,13 @@
 
 // Entry points in zip.dll for loading zip/jar file entries
 
-typedef void * * (JNICALL *ZipOpen_t)(const char *name, char **pmsg);
-typedef void (JNICALL *ZipClose_t)(jzfile *zip);
-typedef jzentry* (JNICALL *FindEntry_t)(jzfile *zip, const char *name, jint *sizeP, jint *nameLen);
-typedef jboolean (JNICALL *ReadEntry_t)(jzfile *zip, jzentry *entry, unsigned char *buf, char *namebuf);
-typedef jzentry* (JNICALL *GetNextEntry_t)(jzfile *zip, jint n);
-typedef jboolean (JNICALL *ZipInflateFully_t)(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
-typedef jint     (JNICALL *Crc32_t)(jint crc, const jbyte *buf, jint len);
+typedef void * * (*ZipOpen_t)(const char *name, char **pmsg);
+typedef void (*ZipClose_t)(jzfile *zip);
+typedef jzentry* (*FindEntry_t)(jzfile *zip, const char *name, jint *sizeP, jint *nameLen);
+typedef jboolean (*ReadEntry_t)(jzfile *zip, jzentry *entry, unsigned char *buf, char *namebuf);
+typedef jzentry* (*GetNextEntry_t)(jzfile *zip, jint n);
+typedef jboolean (*ZipInflateFully_t)(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
+typedef jint     (*Crc32_t)(jint crc, const jbyte *buf, jint len);
 
 static ZipOpen_t         ZipOpen            = NULL;
 static ZipClose_t        ZipClose           = NULL;
diff -r b9df14155468 src/java.base/share/native/libjimage/jimage.cpp
--- a/src/java.base/share/native/libjimage/jimage.cpp	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/java.base/share/native/libjimage/jimage.cpp	Mon Apr 09 14:36:33 2018 +0100
@@ -55,7 +55,7 @@
  *   }
  *   ...
  */
-extern "C" JNIEXPORT JImageFile* JNICALL
+extern "C" JNIEXPORT JImageFile*
 JIMAGE_Open(const char *name, jint* error) {
     // TODO - return a meaningful error code
     *error = 0;
@@ -72,7 +72,7 @@
  * Ex.
  *  (*JImageClose)(image);
  */
-extern "C" JNIEXPORT void JNICALL
+extern "C" JNIEXPORT void
 JIMAGE_Close(JImageFile* image) {
     ImageFileReader::close((ImageFileReader*) image);
 }
@@ -89,7 +89,7 @@
  *  tty->print_cr(package);
  *  -> java.base
  */
-extern "C" JNIEXPORT const char* JNICALL
+extern "C" JNIEXPORT const char*
 JIMAGE_PackageToModule(JImageFile* image, const char* package_name) {
     return ((ImageFileReader*) image)->get_image_module_data()->package_to_module(package_name);
 }
@@ -108,7 +108,7 @@
  *   JImageLocationRef location = (*JImageFindResource)(image,
  *                                 "java.base", "9.0", "java/lang/String.class", &size);
  */
-extern "C" JNIEXPORT JImageLocationRef JNICALL
+extern "C" JNIEXPORT JImageLocationRef
 JIMAGE_FindResource(JImageFile* image,
         const char* module_name, const char* version, const char* name,
         jlong* size) {
@@ -155,7 +155,7 @@
  *  char* buffer = new char[size];
  *  (*JImageGetResource)(image, location, buffer, size);
  */
-extern "C" JNIEXPORT jlong JNICALL
+extern "C" JNIEXPORT jlong
 JIMAGE_GetResource(JImageFile* image, JImageLocationRef location,
         char* buffer, jlong size) {
     ((ImageFileReader*) image)->get_resource((u4) location, (u1*) buffer);
@@ -184,7 +184,7 @@
  *   }
  *   (*JImageResourceIterator)(image, ctw_visitor, loader);
  */
-extern "C" JNIEXPORT void JNICALL
+extern "C" JNIEXPORT void
 JIMAGE_ResourceIterator(JImageFile* image,
         JImageResourceVisitor_t visitor, void* arg) {
     ImageFileReader* imageFile = (ImageFileReader*) image;
@@ -226,7 +226,7 @@
  *   char path[JIMAGE_MAX_PATH];
  *    (*JImageResourcePath)(image, location, path, JIMAGE_MAX_PATH);
  */
-extern "C" JNIEXPORT bool JNICALL
+extern "C" JNIEXPORT bool
 JIMAGE_ResourcePath(JImageFile* image, JImageLocationRef locationRef,
                                     char* path, size_t max) {
     ImageFileReader* imageFile = (ImageFileReader*) image;
diff -r b9df14155468 src/java.base/share/native/libjimage/jimage.hpp
--- a/src/java.base/share/native/libjimage/jimage.hpp	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/java.base/share/native/libjimage/jimage.hpp	Mon Apr 09 14:36:33 2018 +0100
@@ -72,7 +72,7 @@
  *   ...
  */
 
-extern "C" JNIEXPORT JImageFile* JNICALL
+extern "C" JNIEXPORT JImageFile*
 JIMAGE_Open(const char *name, jint* error);
 
 typedef JImageFile* (*JImageOpen_t)(const char *name, jint* error);
@@ -87,7 +87,7 @@
  *  (*JImageClose)(image);
  */
 
-extern "C" JNIEXPORT void JNICALL
+extern "C" JNIEXPORT void
 JIMAGE_Close(JImageFile* jimage);
 
 typedef void (*JImageClose_t)(JImageFile* jimage);
@@ -106,7 +106,7 @@
  *  -> java.base
  */
 
-extern "C" JNIEXPORT const char * JNICALL
+extern "C" JNIEXPORT const char *
 JIMAGE_PackageToModule(JImageFile* jimage, const char* package_name);
 
 typedef const char* (*JImagePackageToModule_t)(JImageFile* jimage, const char* package_name);
@@ -150,7 +150,7 @@
  *  char* buffer = new char[size];
  *  (*JImageGetResource)(image, location, buffer, size);
  */
-extern "C" JNIEXPORT jlong JNICALL
+extern "C" JNIEXPORT jlong
 JIMAGE_GetResource(JImageFile* jimage, JImageLocationRef location,
         char* buffer, jlong size);
 
@@ -185,7 +185,7 @@
         const char* module_name, const char* version, const char* package,
         const char* name, const char* extension, void* arg);
 
-extern "C" JNIEXPORT void JNICALL
+extern "C" JNIEXPORT void
 JIMAGE_ResourceIterator(JImageFile* jimage,
         JImageResourceVisitor_t visitor, void *arg);
 
@@ -202,7 +202,7 @@
  *   char path[JIMAGE_MAX_PATH];
  *    (*JImageResourcePath)(image, location, path, JIMAGE_MAX_PATH);
  */
-extern "C" JNIEXPORT bool JNICALL
+extern "C" JNIEXPORT bool
 JIMAGE_ResourcePath(JImageFile* image, JImageLocationRef locationRef,
                                     char* path, size_t max);
 
diff -r b9df14155468 src/java.base/share/native/libzip/CRC32.c
--- a/src/java.base/share/native/libzip/CRC32.c	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/java.base/share/native/libzip/CRC32.c	Mon Apr 09 14:36:33 2018 +0100
@@ -54,7 +54,7 @@
     return crc;
 }
 
-JNIEXPORT jint JNICALL
+JNIEXPORT jint
 ZIP_CRC32(jint crc, const jbyte *buf, jint len)
 {
     return crc32(crc, (Bytef*)buf, len);
diff -r b9df14155468 src/java.base/share/native/libzip/zip_util.c
--- a/src/java.base/share/native/libzip/zip_util.c	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/java.base/share/native/libzip/zip_util.c	Mon Apr 09 14:36:33 2018 +0100
@@ -881,7 +881,7 @@
  * set to the error message text if msg != 0. Otherwise, *msg will be
  * set to NULL. Caller doesn't need to free the error message.
  */
-JNIEXPORT jzfile * JNICALL
+JNIEXPORT jzfile *
 ZIP_Open(const char *name, char **pmsg)
 {
     jzfile *file = ZIP_Open_Generic(name, pmsg, O_RDONLY, 0);
@@ -895,7 +895,7 @@
 /*
  * Closes the specified zip file object.
  */
-JNIEXPORT void JNICALL
+JNIEXPORT void
 ZIP_Close(jzfile *zip)
 {
     MLOCK(zfiles_lock);
@@ -1115,7 +1115,7 @@
  * Returns the zip entry corresponding to the specified name, or
  * NULL if not found.
  */
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_GetEntry(jzfile *zip, char *name, jint ulen)
 {
     if (ulen == 0) {
@@ -1238,7 +1238,7 @@
  * Returns the n'th (starting at zero) zip file entry, or NULL if the
  * specified index was out of range.
  */
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_GetNextEntry(jzfile *zip, jint n)
 {
     jzentry *result;
@@ -1439,7 +1439,7 @@
  * The current implementation does not support reading an entry that
  * has the size bigger than 2**32 bytes in ONE invocation.
  */
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_FindEntry(jzfile *zip, char *name, jint *sizeP, jint *nameLenP)
 {
     jzentry *entry = ZIP_GetEntry(zip, name, 0);
@@ -1456,7 +1456,7 @@
  * Note: this is called from the separately delivered VM (hotspot/classic)
  * so we have to be careful to maintain the expected behaviour.
  */
-JNIEXPORT jboolean JNICALL
+JNIEXPORT jboolean
 ZIP_ReadEntry(jzfile *zip, jzentry *entry, unsigned char *buf, char *entryname)
 {
     char *msg;
@@ -1515,7 +1515,7 @@
     return JNI_TRUE;
 }
 
-JNIEXPORT jboolean JNICALL
+JNIEXPORT jboolean
 ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg)
 {
     z_stream strm;
diff -r b9df14155468 src/java.base/share/native/libzip/zip_util.h
--- a/src/java.base/share/native/libzip/zip_util.h	Thu Apr 05 19:08:48 2018 -0700
+++ b/src/java.base/share/native/libzip/zip_util.h	Mon Apr 09 14:36:33 2018 +0100
@@ -241,16 +241,16 @@
  */
 #define ZIP_ENDCHAIN ((jint)-1)
 
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_FindEntry(jzfile *zip, char *name, jint *sizeP, jint *nameLenP);
 
-JNIEXPORT jboolean JNICALL
+JNIEXPORT jboolean
 ZIP_ReadEntry(jzfile *zip, jzentry *entry, unsigned char *buf, char *entrynm);
 
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_GetNextEntry(jzfile *zip, jint n);
 
-JNIEXPORT jzfile * JNICALL
+JNIEXPORT jzfile *
 ZIP_Open(const char *name, char **pmsg);
 
 jzfile *
@@ -265,10 +265,10 @@
 jzfile *
 ZIP_Put_In_Cache0(const char *name, ZFILE zfd, char **pmsg, jlong lastModified, jboolean usemmap);
 
-JNIEXPORT void JNICALL
+JNIEXPORT void
 ZIP_Close(jzfile *zip);
 
-JNIEXPORT jzentry * JNICALL
+JNIEXPORT jzentry *
 ZIP_GetEntry(jzfile *zip, char *name, jint ulen);
 JNIEXPORT void JNICALL
 ZIP_Lock(jzfile *zip);
@@ -281,7 +281,7 @@
 jlong ZIP_GetEntryDataOffset(jzfile *zip, jzentry *entry);
 jzentry * ZIP_GetEntry2(jzfile *zip, char *name, jint ulen, jboolean addSlash);
 
-JNIEXPORT jboolean JNICALL
+JNIEXPORT jboolean
 ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
 
 #endif /* !_ZIP_H_ */

From tim.bell at oracle.com  Mon Apr  9 14:24:52 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 09 Apr 2018 07:24:52 -0700
Subject: RFR: JDK-8201267: Disable warnings for VS2017 to enable building
In-Reply-To: <b096f64e-9f47-8b4a-28d6-4640cf47635e@oracle.com>
References: <ed46008e-0586-5eef-61a4-8523303ec10d@oracle.com>
 <b096f64e-9f47-8b4a-28d6-4640cf47635e@oracle.com>
Message-ID: <5ACB77B4.6010006@oracle.com>

Erik:

On 04/09/18 00:56, Magnus Ihse Bursie wrote:
> On 2018-04-07 01:04, Erik Joelsson wrote:
>> We are rather close to being able to build the JDK using VS2017. There
>> are still some warnings that need to be disabled (separate issues
>> filed to fix them) and some other minor build tweaks that has surfaced
>> now that Hotspot builds successfully.
>>
>> With this patch, it should be possible to build using VS2017.
>>
>> Notes on changes:
>>
>> * In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all
>> directories sent in here are already fixed. Calling it here messes up
>> the filename of the dll, which in VS2017 is more than 8 chars.
>>
>> * In NativeCompilation.gmk, this is unrelated but fixes incremental
>> builds on Windows. Adlc.exe gets relinked every time otherwise.
>>
>> * Reentrancy.c is a fix for JDK-8201215 suggested in bug comments there.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201267
>> Webrev: http://cr.openjdk.java.net/~erikj/8201267/webrev.01/index.html
> Looks good to me.
>
> /Magnus

Looks good to me as well.

Tim




From matthias.baesken at sap.com  Mon Apr  9 14:38:01 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Apr 2018 14:38:01 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
Message-ID: <5146b9330edd44b483780587aca1757c@sap.com>

Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations .

I created  a second  webrev :

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

-   it  adds  the diff  provided by you    (hope that?s fine with you)
-    changes  2 launchers    src/java.base/share/native/launcher/main.c    and    src/jdk.pack/share/native/unpack200/main.cpp    where we face similar issues after mapfile removal for exes  
      


Best regards , Matthias


> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Montag, 9. April 2018 15:52
> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> Matthias <matthias.baesken at sap.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias, Magnus,
> 
> The problem is with JNICALL added to the functions. JNICALL expands to
> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
> ignored. On 32 bit, the modifier changes the way parameters are pass and
> the function name is decorated with an underscore and with @ + the size
> of arguments.
> 
> If I remove JNICALL modifier from the exported functions, they're
> exported with plain name as in source code (plus, __cdecl [2] calling
> convention is used.)
> 
> zip.dll and jimage.dll are affected by this. It's because the exported
> functions are looked up by name rather than using a header file with
> JNIIMPORT. See
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l1155
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l1194
> 
> JNICALL modifier must also be removed from type declarations for
> functions from zip.dll:
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l81
> 
> I'm attaching the patch to zip and jimage as well as classLoader.cpp
> which takes these changes into account. It does not replace Matthias'
> patch but complements it.
> 
> 
> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
> pragma comments [3][4] to export undecorated names. But this is compiler
> specific and may require if's for other platforms.
> 
> 
> Regards,
> Alexey
> 
> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
> 
> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
> > Those were added by my patch that removed the map files.
> >
> > /Magnus
> >
> >> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
> <matthias.baesken at sap.com>:
> >>
> >> I did  not add   JNICALL decorations  to  any  libzip functions , please see
> my webrev :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>
> >>> , the problem here
> >>> is the added JNICALL decoration, which affects only win32 (and
> incorrectly,
> >>> that is).
> >> so I wonder  which added  JNICALL  decoration   you are refering to .
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> -----Original Message-----
> >>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>> Sent: Montag, 9. April 2018 13:29
> >>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
> >>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >>> some places in function declarations/implementations
> >>>
> >>> Reinstating the -export command line options is not the way forward
> here.
> >>> As I understood it from private conversation with Alexey, the problem
> here
> >>> is the added JNICALL decoration, which affects only win32 (and
> incorrectly,
> >>> that is).
> >>>
> >>> /Magnus
> >>>
> >>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias
> <matthias.baesken at sap.com>:
> >>>
> >>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >>>>> this function is correctly decorated in CRC32.c and is exported.
> >>>>>
> >>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does
> not
> >>> help  with the  "Corrupted ZIP library"  error .
> >>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
> >>> make/lib/CoreLibraries.gmk        (same for some  JIMAGE functions) :
> >>>>
> >>>> --- a/make/lib/CoreLibraries.gmk       Sun Apr 08 17:01:20 2018 +0800
> >>>> +++ b/make/lib/CoreLibraries.gmk       Mon Apr 09 12:44:08 2018 +0200
> >>>> @@ -191,6 +191,9 @@
> >>>>     DISABLED_WARNINGS_gcc := implicit-fallthrough, \
> >>>>     LDFLAGS := $(LDFLAGS_JDKLIB) \
> >>>>         $(call SET_SHARED_LIBRARY_ORIGIN), \
> >>>> +    LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
> >>> export:ZIP_FindEntry \
> >>>> +        -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> >>>> +        -export:ZIP_InflateFully -export:ZIP_CRC32 -
> export:ZIP_FreeEntry, \
> >>>>     LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
> >>>>     LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> >>>> ))
> >>>> @@ -221,6 +224,10 @@
> >>>>     CFLAGS_unix := -UDEBUG, \
> >>>>     LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
> >>>>         $(call SET_SHARED_LIBRARY_ORIGIN), \
> >>>> +    LDFLAGS_windows := -export:JIMAGE_Open -
> export:JIMAGE_Close \
> >>>> +        -export:JIMAGE_PackageToModule \
> >>>> +        -export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> >>>> +        -export:JIMAGE_ResourceIterator -
> export:JIMAGE_ResourcePath, \
> >>>>     LIBS_unix := -ljvm -ldl $(LIBCXX), \
> >>>>     LIBS_macosx := -lc++, \
> >>>>     LIBS_windows := jvm.lib, \
> >>>>
> >>>>
> >>>> I wonder why the 64bit windows build can  live without the  exports  ,
> any
> >>> ideas ?
> >>>>
> >>>> Best regards , Matthias
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >>>>> Sent: Samstag, 7. April 2018 00:14
> >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> >>>>> Matthias <matthias.baesken at sap.com>
> >>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >>>>> <martin.doerr at sap.com>
> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function
> >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> at
> >>>>> some places in function declarations/implementations
> >>>>>
> >>>>> Hi Magnus, Matthias,
> >>>>>
> >>>>> I tried to build 32 bit Windows but it fails to run for me with
> >>>>> Corrupted ZIP library:
> >>>>> c:\work\jdk-dev\build\windows-x86-normal-server-
> >>> release\jdk\bin\zip.dll
> >>>>> The problem is that zip.dll exports all symbols as C++ rather than C.
> >>>>> For example, ZIP_CRC32 is exported as _ZIP_CRC32 at 12, and
> >>> classLoader.cpp
> >>>>> cannot find the function.
> >>>>>
> >>>>>
> >>>>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >>>>> this function is correctly decorated in CRC32.c and is exported.
> >>>>>
> >>>>> Regards,
> >>>>> Alexey
> >>>>>
> >>>>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> >>>>>> I think it's reasonable to update the existing webrev.
> >>>>>>
> >>>>>> /Magnus
> >>>>>>
> >>>>>>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
> >>>>> <matthias.baesken at sap.com>:
> >>>>>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> >>>>>>>
> >>>>>>> The   follow up change  that removed   mapfiles for  exes  as well
> leads
> >>>>> on Win32 bit  to  this link error :
> >>>>>>>   Creating library
> >>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
> >>> object
> >>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >>>>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol
> _main
> >>>>> referenced in function ___tmainCRTStartup
> >>>>>>>
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
> >>> :
> >>>>> fatal error LNK1120: 1 unresolved externals
> >>>>>>>
> >>>>>>> Looks like we  cannot have   JNICALL   in main.c   :
> >>>>>>>
> >>>>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >>>>>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05
> >>> 14:39:04
> >>>>> 2018 -0700
> >>>>>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06
> >>> 15:16:40
> >>>>> 2018 +0200
> >>>>>>> @@ -93,7 +93,7 @@
> >>>>>>>      __initenv = _environ;
> >>>>>>>
> >>>>>>> #else /* JAVAW */
> >>>>>>> -JNIEXPORT int JNICALL
> >>>>>>> +JNIEXPORT int
> >>>>>>> main(int argc, char **argv)
> >>>>>>> {
> >>>>>>>      int margc;
> >>>>>>>
> >>>>>>>
> >>>>>>> Zip-library  has runtime issues   when  symbols  are resolved  in
> >>>>> src/hotspot/share/classfile/classLoader.cpp.
> >>>>>>> I added  the declaration of the missing symbol, this seems to fix it .
> >>>>>>>
> >>>>>>>
> >>>>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >>>>>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05
> 14:39:04
> >>>>> 2018 -0700
> >>>>>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06
> 15:16:40
> >>>>> 2018 +0200
> >>>>>>> @@ -284,4 +284,7 @@
> >>>>>>> JNIEXPORT jboolean JNICALL
> >>>>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong
> outLen,
> >>> char
> >>>>> **pmsg);
> >>>>>>> +JNIEXPORT jint JNICALL
> >>>>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >>>>>>> +
> >>>>>>>
> >>>>>>>
> >>>>>>> Should I  prepare  another  bug,  or  add this to the existing one and
> >>> post
> >>>>> a second webrev ?
> >>>>>>> Best regards, Matthias
> >>>>>>>
> >>>>>>>
> >>>>>>> From: Baesken, Matthias
> >>>>>>> Sent: Freitag, 6. April 2018 09:54
> >>>>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> >>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> >>> <martin.doerr at sap.com>
> >>>>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places
> in
> >>>>> function declarations/implementations - was : RE: missing JNIEXPORT
> /
> >>>>> JNICALL at some places in function declarations/implementations
> >>>>>>> Hello, please review :
> >>>>>>>
> >>>>>>> Bug :
> >>>>>>>
> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
> >>>>>>>
> >>>>>>> change :
> >>>>>>>
> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>>>>
> >>>>>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the
> >>> win32bit
> >>>>> build missed it .
> >>>>>>> A difference is
> >>>>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> >>>>>>> Where I removed   a few  declarations  (one  decl   with one without
> >>>>> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >>>>>>> Best regards , Matthias
> >>>>>>>
> >>>>>>>
> >>>>>>> From: Magnus Ihse Bursie
> [mailto:magnus.ihse.bursie at oracle.com]
> >>>>>>> Sent: Donnerstag, 5. April 2018 17:45
> >>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> >>> <martin.doerr at sap.com>
> >>>>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in
> function
> >>>>> declarations/implementations
> >>>>>>> That's most likely a result of the new JNIEXPORT I added as part of
> the
> >>>>> mapfile removal.
> >>>>>>> I tried to match header file and C file, but I can certainly have
> missed
> >>>>> cases. If I didn't get any warnings, it was hard to know what I missed.
> >>>>>>> Please do submit your patch.
> >>>>>>>
> >>>>>>> I'm a bit surprised 32-bit Window is still buildable. :)
> >>>>>>>
> >>>>>>> /Magnus
> >>>>>>>
> >>>>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> >>>>> <matthias.baesken at sap.com>:
> >>>>>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
> >>>>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one
> compares
> >>>>> the declaration and
> >>>>>>> The implementation of functions.
> >>>>>>> While this is ok on most platforms, it seems to fail on Windows 32
> bit
> >>> and
> >>>>> leads to errors like this one :
> >>>>>>>
> >>>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> >>>>> ib_ImageConvKernelConvert.c(87) : error C2373:
> >>>>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
> >>> modifiers
> >>>
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> >>>>> ib_image_proto.h(2630) : see declaration of
> >>>>> 'j2d_mlib_ImageConvKernelConvert'
> >>>>>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
> >>>>>>>
> >>>>>>>
> >>>>>>> Another example is this one :
> >>>>>>>
> >>>>>>> diff -r 4d98473ed33e
> src/java.base/share/native/libjimage/jimage.hpp
> >>>>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05
> >>>>> 09:55:16 2018 +0200
> >>>>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu
> Apr
> >>>>> 05 17:07:40 2018 +0200
> >>>>>>> @@ -126,7 +126,7 @@
> >>>>>>>   *   JImageLocationRef location = (*JImageFindResource)(image,
> >>>>>>>   *                                "java.base", "9.0", "java/lang/String.class",
> &size);
> >>>>>>>   */
> >>>>>>> -extern "C" JNIEXPORT JImageLocationRef
> >>>>> JIMAGE_FindResource(JImageFile* jimage,
> >>>>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
> >>>>> JIMAGE_FindResource(JImageFile* jimage,
> >>>>>>>          const char* module_name, const char* version, const char*
> name,
> >>>>>>>          jlong* size);
> >>>>>>>
> >>>>>>>
> >>>>>>> Is there some generic way to get  the  same  declarations /
> >>>>> impementations   in the code  ?
> >>>>>>> Or should I just add a patch with my findings ?
> >>>>>>>
> >>>>>>> Best regards, Matthias
> >>>>>>>


From alexey.ivanov at oracle.com  Mon Apr  9 15:14:15 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 9 Apr 2018 16:14:15 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <5146b9330edd44b483780587aca1757c@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
Message-ID: <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>

Hi Matthias,

On 09/04/2018 15:38, Baesken, Matthias wrote:
> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations .
>
> I created  a second  webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>
> -   it  adds  the diff  provided by you    (hope that?s fine with you)

Yes, that's fine with me.
There could be only one author ;)

> -    changes  2 launchers    src/java.base/share/native/launcher/main.c    and    src/jdk.pack/share/native/unpack200/main.cpp    where we face similar issues after mapfile removal for exes

I'd rather remove both JNIEXPORT and JNICALL from main().
It wasn't exported, and it shouldn't be.

Regards,
Alexey

>        
>
>
> Best regards , Matthias
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Montag, 9. April 2018 15:52
>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>> Matthias <matthias.baesken at sap.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>> Hi Matthias, Magnus,
>>
>> The problem is with JNICALL added to the functions. JNICALL expands to
>> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
>> ignored. On 32 bit, the modifier changes the way parameters are pass and
>> the function name is decorated with an underscore and with @ + the size
>> of arguments.
>>
>> If I remove JNICALL modifier from the exported functions, they're
>> exported with plain name as in source code (plus, __cdecl [2] calling
>> convention is used.)
>>
>> zip.dll and jimage.dll are affected by this. It's because the exported
>> functions are looked up by name rather than using a header file with
>> JNIIMPORT. See
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>> ssLoader.cpp#l1155
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>> ssLoader.cpp#l1194
>>
>> JNICALL modifier must also be removed from type declarations for
>> functions from zip.dll:
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>> ssLoader.cpp#l81
>>
>> I'm attaching the patch to zip and jimage as well as classLoader.cpp
>> which takes these changes into account. It does not replace Matthias'
>> patch but complements it.
>>
>>
>> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
>> pragma comments [3][4] to export undecorated names. But this is compiler
>> specific and may require if's for other platforms.
>>
>>
>> Regards,
>> Alexey
>>
>> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
>> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
>> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
>> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
>>
>> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
>>> Those were added by my patch that removed the map files.
>>>
>>> /Magnus
>>>
>>>> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
>> <matthias.baesken at sap.com>:
>>>> I did  not add   JNICALL decorations  to  any  libzip functions , please see
>> my webrev :
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>
>>>>> , the problem here
>>>>> is the added JNICALL decoration, which affects only win32 (and
>> incorrectly,
>>>>> that is).
>>>> so I wonder  which added  JNICALL  decoration   you are refering to .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>>> Sent: Montag, 9. April 2018 13:29
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
>>>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Reinstating the -export command line options is not the way forward
>> here.
>>>>> As I understood it from private conversation with Alexey, the problem
>> here
>>>>> is the added JNICALL decoration, which affects only win32 (and
>> incorrectly,
>>>>> that is).
>>>>>
>>>>> /Magnus
>>>>>
>>>>>
<SNIP>


From Derek.White at cavium.com  Mon Apr  9 15:35:34 2018
From: Derek.White at cavium.com (White, Derek)
Date: Mon, 9 Apr 2018 15:35:34 +0000
Subject: Supported platforms
Message-ID: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>

Hi Magnus,

> -----Original Message-----
> Date: Mon, 9 Apr 2018 09:55:09 +0200
> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> To: Simon Nash <simon at cjnash.com>, bren at juanantonio.info
> Cc: build-dev at openjdk.java.net, hotspot-dev developers
> 	<hotspot-dev at openjdk.java.net>
> Subject: Re: Supported platforms
> Message-ID: <4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Simon,
> 
> On 2018-04-08 16:30, Simon Nash wrote:
> > On 05/04/2018 02:26, bren at juanantonio.info wrote:
> >>
> >> Many thanks with the link about the Platforms supported:
> >>
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
> >> config-4417031.html
> >>
> > This appears to be a list of the platforms that are supported
> > (certified) by
> > Oracle.? Where can I find the list of platforms that are supported by
> > OpenJDK?? For example, what about the following platforms that don't
> > appear on the Oracle list:
> >
> > Windows x86
> > Linux x86
> > aarch32 (ARMv7 32-bit)
> > aarch64 (ARMv8 64-bit)
> >
> > Are all these supported for OpenJDK 9, 10 and 11?
> 
> There is actually no such thing as a "supported OpenJDK platform". While I
> hope things may change in the future, OpenJDK as an organization does not
> publicize any list of "supported" platforms. Oracle publishes a list of
> platforms they support, and I presume that Red Hat and SAP and others do
> the same, but the OpenJDK project itself does not.
> 
> With that said, platforms which were previously supported by Oracle (like
> the one's you mentioned) tend to still work more-or-less well, but they
> receive no or little testing, and is prone to bit rot.
> 
> /Magnus

Surely you meant to say "receive no or little testing BY ORACLE, and ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."

I haven't found a definitive list of supported OpenJDK platforms, but have an ad-hoc list of publicly available binaries:
- Major linux distros are supporting x64 and aarch64 (arm64), and probably other platforms.
- AdoptOpenJDK provides tested builds for most 64-bit platforms (x64, aarch64, ppc64, s390).
     - https://adoptopenjdk.net/releases.html
- Bellsoft provides support for 32-bit ARMv7.
    - https://bell-sw.com/products.html
- Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 and aarch64. 
    - https://www.azul.com/downloads/zulu/

I'm sure there are several others I've missed - sorry!
 - Derek


From erik.joelsson at oracle.com  Mon Apr  9 16:11:57 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 9 Apr 2018 09:11:57 -0700
Subject: RFR: JDK-8201263: Traling backslash in VS120COMNTOOLS leads to
 ugly error message when running tests
In-Reply-To: <B44A9288-CD7F-4505-9F17-6292E97BA3C6@oracle.com>
References: <58300D53-4086-46ED-AB80-AB3BAAFCAE56@oracle.com>
 <8ed90ef9-a8b1-a403-e9eb-d0b05df28e53@oracle.com>
 <B44A9288-CD7F-4505-9F17-6292E97BA3C6@oracle.com>
Message-ID: <6174c4d2-ed27-7fc8-5ed5-d65b82df3212@oracle.com>

Looks good.

/Erik


On 2018-04-06 21:24, Mikael Vidstedt wrote:
>
> Testing revealed that the fix solved the immediate problem of removing 
> the error message, but a similar problem occurred when the resulting 
> JTREG_BASIC_OPTIONS variable is then used. Specifically the problem is 
> that the path returned from the shell execution (still) contains 
> spaces, so the resulting string also needs to be quoted. This version 
> has passed the typical CI job:
>
> http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.01/open/webrev/ 
> <http://cr.openjdk.java.net/%7Emikael/webrevs/8201263/webrev.01/open/webrev/>
>
> Cheers,
> Mikael
>
>> On Apr 6, 2018, at 3:17 PM, Erik Joelsson <erik.joelsson at oracle.com 
>> <mailto:erik.joelsson at oracle.com>> wrote:
>>
>> Looks good.
>>
>> /Erik
>>
>>
>> On 2018-04-06 15:04, Mikael Vidstedt wrote:
>>> Please review this change which addresses a minor issue when running 
>>> tests on some Windows machines.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201263
>>> Webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ 
>>> <http://cr.openjdk.java.net/%7Emikael/webrevs/8201263/webrev.00/open/> 
>>> <http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ 
>>> <http://cr.openjdk.java.net/%7Emikael/webrevs/8201263/webrev.00/open/>>
>>>
>>> * Background (from the bug)
>>>
>>> When running tests using Make on a (Windows) machine where 
>>> VS120COMNTOOLS is set an error message is generated.
>>>
>>> /bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
>>> /bin/sh: -c: line 1: syntax error: unexpected end of file
>>>
>>> The message is generated by this logic in test/TestCommon.gmk:
>>>
>>> ifneq ($(VS120COMNTOOLS), )
>>> ??JTREG_BASIC_OPTIONS += -e:VS120COMNTOOLS=$(shell $(GETMIXEDPATH) 
>>> "$(VS120COMNTOOLS)")
>>> endif
>>>
>>> The problem is that the VS120COMNTOOLS variable typically looks 
>>> something like:
>>>
>>> $ echo $VS120COMNTOOLS
>>> C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
>>>
>>> Of particular interest is the fact that it has a trailing backslash. 
>>> When used in the make file that means it will all be expanded to 
>>> something like:
>>>
>>> JTREG_BASIC_OPTIONS += ... $(shell cygwin -m "c:\<path>\Common7\Tools\")
>>>
>>> When that in turn gets executed the backslash will escape the last 
>>> double quote which means that the quotes are no longer paired.
>>>
>>>
>>> * Fix
>>>
>>> The fix removes the trailing backslash (if there is one). I verified 
>>> the fix locally, and I?m running more CI testing on it now.
>>>
>>> Cheers,
>>> Mikael
>>>
>>
>



From simon at cjnash.com  Mon Apr  9 16:12:38 2018
From: simon at cjnash.com (Simon Nash)
Date: Mon, 09 Apr 2018 17:12:38 +0100
Subject: Supported platforms
In-Reply-To: <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <5ACA276C.7030505@cjnash.com>
 <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
Message-ID: <5ACB90F6.50607@cjnash.com>

On 09/04/2018 08:55, Magnus Ihse Bursie wrote:
> 
> Simon,
> 
> On 2018-04-08 16:30, Simon Nash wrote:
>> On 05/04/2018 02:26, bren at juanantonio.info wrote:
>>>
>>> Many thanks with the link about the Platforms supported:
>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 
>>>
>> This appears to be a list of the platforms that are supported 
>> (certified) by
>> Oracle.  Where can I find the list of platforms that are supported by
>> OpenJDK?  For example, what about the following platforms that don't 
>> appear
>> on the Oracle list:
>>
>> Windows x86
>> Linux x86
>> aarch32 (ARMv7 32-bit)
>> aarch64 (ARMv8 64-bit)
>>
>> Are all these supported for OpenJDK 9, 10 and 11?
> 
> There is actually no such thing as a "supported OpenJDK platform". While 
> I hope things may change in the future, OpenJDK as an organization does 
> not publicize any list of "supported" platforms. Oracle publishes a list 
> of platforms they support, and I presume that Red Hat and SAP and others 
> do the same, but the OpenJDK project itself does not.
> 
> With that said, platforms which were previously supported by Oracle 
> (like the one's you mentioned) tend to still work more-or-less well, but 
> they receive no or little testing, and is prone to bit rot.
> 
> /Magnus
> 
Magnus,
Thanks for this.  I think I should clarify what I mean by a supported
platform.  This would be a platform for which bugs affecting the ability
to build a working OpenJDK binary for that platform would be considered
valid by the OpenJDK community and a user-submitted patch to fix such a
bug would be considered for integration into the OpenJDK codebase.

Simon

>>
>> Simon
> 



From erik.joelsson at oracle.com  Mon Apr  9 16:20:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 9 Apr 2018 09:20:28 -0700
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing
 unresolved symbols
In-Reply-To: <1523281192.148486.9.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
Message-ID: <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>

Hello Severin,

I'm ok with this solution for now.

Could you please reduce the indentation on line 652. In the build system 
we like 4 spaces for continuation indent [1]

/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-04-09 06:39, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review this build fix for libfontmanager.so. The
> issue for us is that with some LDFLAGS the build breaks as described in
> bug JDK-8196218. However, we cannot link to a providing library at
> build-time since we don't know which one it should be: libawt_headless
> or libawt_xawt. That has to happen at runtime. The proposed fix filters
> out relevant linker flags when libfontmanager is being built. More
> details are in the bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
>
> Testing: I've run this through submit[1] and got the following results.
> SwingSet2 works fine for me on F27. I'm currently running some more
> tests on RHEL 7.
>
> ---------------------
> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
>
> 0 Failed Tests
>
> Mach5 Tasks Results Summary
>
> NA: 0
> UNABLE_TO_RUN: 0
> EXECUTED_WITH_FAILURE: 0
> KILLED: 0
> PASSED: 82
> FAILED: 1
> Test
>
> 1 Failed
>
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
> return value: 10
> --------------------
>
> Not sure what this test failure means. Could somebody at Oracle shed
> some light on this?
>
> Thanks,
> Severin



From neugens at redhat.com  Mon Apr  9 16:40:31 2018
From: neugens at redhat.com (Mario Torre)
Date: Mon, 9 Apr 2018 18:40:31 +0200
Subject: Supported platforms
In-Reply-To: <5ACB90F6.50607@cjnash.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <5ACA276C.7030505@cjnash.com>
 <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
 <5ACB90F6.50607@cjnash.com>
Message-ID: <CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>

On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash <simon at cjnash.com> wrote:

> Thanks for this.  I think I should clarify what I mean by a supported
> platform.  This would be a platform for which bugs affecting the ability
> to build a working OpenJDK binary for that platform would be considered
> valid by the OpenJDK community and a user-submitted patch to fix such a
> bug would be considered for integration into the OpenJDK codebase.

Being a Community project, I would say everything that is relevant for
users is relevant for the project.

Now, "everything" doesn't mean "absolutely" everything of course ;)
but within reasonable limits "almost" everything is a good bet. If you
plan in adding support for new architectures you will have better luck
with a Porting sponsored projects, if you want to fix some bugs in
some weird architecture that is already existing, or help building
with some Linux distribution not currently covered for some reason,
I'm sure that will be accepted quickly too, in all cases some
discussion would be good to have before start proposing patches.

But again, this is a case-by-case thing, so probably you can just tell
us what you are interested in contributing and see if there are
objections or other reasons not to have that code in.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From magnus.ihse.bursie at oracle.com  Mon Apr  9 17:23:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 19:23:52 +0200
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
In-Reply-To: <5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>
References: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
 <5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>
Message-ID: <04b9cfaa-61d1-3b71-8a04-45755d4c620a@oracle.com>

On 2018-04-06 17:23, Erik Joelsson wrote:
> Looks good in general.
>
> In JvmDtraceObjects.gmk, comment on line 38 needs to be updated.
Nice spotting! It was left-over from before. I deleted it, the paragraph 
above said the same thing but correctly.

/Magnus
>
> /Erik
>
>
> On 2018-04-06 03:57, Magnus Ihse Bursie wrote:
>> The dtrace build logic was copied straight out of the old Hotspot 
>> build system, and is quite convoluted.
>>
>> It should be split into the separate parts it actually contains of:
>> 1) A gensrc step which runs with other gensrc ahead of compilation
>> 2) Two independent libraries that can be build at any time
>> 3) Two special dtrace-generated .o files that must be linked with the 
>> JVM
>>
>> I have also cleaned up includes in generateJvmOffsets.cpp.
>>
>> I have verified with COMPARE_BUILD that no changes has happened in 
>> any native library.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01
>>
>> /Magnus
>



From naoto.sato at oracle.com  Mon Apr  9 20:20:02 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 9 Apr 2018 13:20:02 -0700
Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the
 SystemV variant of the timezone
Message-ID: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com>

Hello,

Please review the changes to the following issue:

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

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8189784/webrev.02/

There were two causes of the issue. One was that j.t.f.ZoneName 
contained hard coded mappings based on the old CLDR data and never been 
updated. The other reason was that CLDR's deprecated zones ("SystemV" 
ones, in this case) were not properly replaced.

I am including build-dev for the review, as the change includes 
generating ZoneName mapping at the build time from the template.

Naoto


From erik.joelsson at oracle.com  Mon Apr  9 23:15:33 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 9 Apr 2018 16:15:33 -0700
Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the
 SystemV variant of the timezone
In-Reply-To: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com>
References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com>
Message-ID: <c2615d3e-2ff1-2a41-62b5-15a40b6a1ef5@oracle.com>

Hello Naoto,

Looks good, just a style issue.

When breaking a recipe line, please add 4 additional spaces (after the 
tab) for continuation indent [1]. In this case I would also advocate 
breaking the line sooner to make side by side comparisons easier in the 
future.

/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-04-09 13:20, Naoto Sato wrote:
> Hello,
>
> Please review the changes to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8189784
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8189784/webrev.02/
>
> There were two causes of the issue. One was that j.t.f.ZoneName 
> contained hard coded mappings based on the old CLDR data and never 
> been updated. The other reason was that CLDR's deprecated zones 
> ("SystemV" ones, in this case) were not properly replaced.
>
> I am including build-dev for the review, as the change includes 
> generating ZoneName mapping at the build time from the template.
>
> Naoto



From ioi.lam at oracle.com  Tue Apr 10 00:00:41 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 9 Apr 2018 17:00:41 -0700
Subject: slowproduct build
Message-ID: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>

Sometimes I want to debug the product build (I can't bother with turning 
off all the trueInDebug options in the hotspot globals.hpp). The only 
way that I have found to do this is:

 ??? configure --with-native-debug-symbols=internal
 ??? mv spec.gmk spec.gmk.old
 ??? cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk

Is there (or should there be) a more elegant way to do it, like 
"configure --with-debug-level=slowproduct" :-)

Thanks
- Ioi



From naoto.sato at oracle.com  Tue Apr 10 01:00:18 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 9 Apr 2018 18:00:18 -0700
Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the
 SystemV variant of the timezone
In-Reply-To: <c2615d3e-2ff1-2a41-62b5-15a40b6a1ef5@oracle.com>
References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com>
 <c2615d3e-2ff1-2a41-62b5-15a40b6a1ef5@oracle.com>
Message-ID: <b2affb0d-1cc2-6acd-f83e-bebc8d3b9886@oracle.com>

Thanks, Erik. Modified GensrcCLDR.gmk as suggested:

http://cr.openjdk.java.net/~naoto/8189784/webrev.03/

Naoto

On 4/9/18 4:15 PM, Erik Joelsson wrote:
> Hello Naoto,
> 
> Looks good, just a style issue.
> 
> When breaking a recipe line, please add 4 additional spaces (after the 
> tab) for continuation indent [1]. In this case I would also advocate 
> breaking the line sooner to make side by side comparisons easier in the 
> future.
> 
> /Erik
> 
> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
> 
> On 2018-04-09 13:20, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8189784
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8189784/webrev.02/
>>
>> There were two causes of the issue. One was that j.t.f.ZoneName 
>> contained hard coded mappings based on the old CLDR data and never 
>> been updated. The other reason was that CLDR's deprecated zones 
>> ("SystemV" ones, in this case) were not properly replaced.
>>
>> I am including build-dev for the review, as the change includes 
>> generating ZoneName mapping at the build time from the template.
>>
>> Naoto
> 


From david.holmes at oracle.com  Tue Apr 10 01:16:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 11:16:32 +1000
Subject: Supported platforms
In-Reply-To: <CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
 <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
 <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
 <5ACA276C.7030505@cjnash.com>
 <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com> <5ACB90F6.50607@cjnash.com>
 <CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>
Message-ID: <d31809bb-e3de-c3c9-4ffd-39c5a8faa21a@oracle.com>

On 10/04/2018 2:40 AM, Mario Torre wrote:
> On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash <simon at cjnash.com> wrote:
> 
>> Thanks for this.  I think I should clarify what I mean by a supported
>> platform.  This would be a platform for which bugs affecting the ability
>> to build a working OpenJDK binary for that platform would be considered
>> valid by the OpenJDK community and a user-submitted patch to fix such a
>> bug would be considered for integration into the OpenJDK codebase.
> 
> Being a Community project, I would say everything that is relevant for
> users is relevant for the project.
> 
> Now, "everything" doesn't mean "absolutely" everything of course ;)
> but within reasonable limits "almost" everything is a good bet. If you
> plan in adding support for new architectures you will have better luck
> with a Porting sponsored projects, if you want to fix some bugs in
> some weird architecture that is already existing, or help building
> with some Linux distribution not currently covered for some reason,
> I'm sure that will be accepted quickly too, in all cases some
> discussion would be good to have before start proposing patches.

We are in a situation where previously "supported" platforms (by Oracle) 
are no longer supported as, AFAIK, no one has stepped up to take 
ownership of said platforms - which is a requirement for getting a new 
port accepted into mainline. Without such ownership the code may not 
only bit-rot, it may in time be stripped out completely. Any interested 
parties would then need to look at (re)forming a port project for that 
platform to keep it going in OpenJDK (or of course they are free to take 
it elsewhere).

Cheers,
David

> But again, this is a case-by-case thing, so probably you can just tell
> us what you are interested in contributing and see if there are
> objections or other reasons not to have that code in.
> 
> Cheers,
> Mario
> 


From martinrb at google.com  Tue Apr 10 05:46:53 2018
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Apr 2018 22:46:53 -0700
Subject: RFR: 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469
Message-ID: <CA+kOe0-Bqcf2vpwzfNbEtpttd6SQm0gMpiPq0tUVtD4RKPEajg@mail.gmail.com>

Hi Magnus, please review:

8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469
http://cr.openjdk.java.net/~martin/webrevs/jdk/ALSA_CFLAGS/
https://bugs.openjdk.java.net/browse/JDK-8201357


From david.holmes at oracle.com  Tue Apr 10 08:00:19 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 18:00:19 +1000
Subject: Supported platforms
In-Reply-To: <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
Message-ID: <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>

Hi Aleksei,

This is all news to me. Good news, but unexpected. As far as I was aware 
the 32-bit ARM port was dying a slow death and would eventually get 
removed. 64-bit ARM is of course very much alive and well under the 
Aarch64 porters - though I'm unclear if you are using that code for 
ARMv8 or the Oracle contributed code that used to be closed?

I'm also unclear whether you are pushing changes back up to OpenJDK for 
these platforms, or maintaining them locally? I haven't noticed anything 
(other than build tweaks) and am curious about the release of a Minimal 
VM for JDK 10 given the Minimal VM effectively died along with the 
stand-alone Client VM.

For JDK11 you will need to do some work for Condy (if not already done) 
as well as JFR and Nest-based Access Control (which you can see in the 
nestmates branch of the Valhalla repo), as you mention below. Not sure 
what else may be needed. There's been a lot of code refactoring and 
include file changes that have impact on platform specific code as well.

Cheers,
David

On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
> Hi David,
> 
> Speaking about the arm/ port, BellSoft has been releasing JCK-verified 
> binaries (as provided under the OpenJDK license) from the arm/ port for 
> the Raspberry Pi for JDK 9 [1] for a while and recently released one for 
> JDK 10 [2], including OpenJFX and Minimal VM support. On Raspberry Pi 2 
> (ARMv7) and Raspberry Pi 3 (ARMv8 chip running Raspbian) the binaries 
> produced from this port are passing all the required testing, including 
> the new features recently open-sourced by Oracle (such as AppCDS). As 
> far as JDK 11 is concerned, we are keeping track of the changes, 
> recently fixed a couple of build issues that slipped in [3, 4], are 
> working on Minimal Value Types support and, from what I can tell, will 
> need to look into JFR and Nest-Based Access Control. Please let us know 
> if we missed anything and we need to prepare for some other new features 
> for porting.
> 
> The intent is to keep the arm/ port in good shape and provide 
> well-tested binaries for the Raspberry Pi.
> 
> I believed Oracle was aware about BellSoft producing binaries from this 
> port [5], [6]. Based on twitter, it seems like at least some engineers 
> at Redhat and SAP are aware about it. Let me know if there is anything 
> else we need to do to spread the word about it with Oracle engineering. 
> For now, Boris (cced) is the engineer at BellSoft working on supporting 
> the arm/ port for the Raspberry Pi. Other than that, I really wonder 
> what "stepping up to take ownership of a port" means when it's upstream, 
> and there is some procedure we need to follow.
> 
> Thanks,
> 
> -Aleksei
> 
> [1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
> [2] https://bell-sw.com/java-for-raspberry-pi.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8200628
> [4] https://bugs.openjdk.java.net/browse/JDK-8198949
> [5] https://twitter.com/java/status/981239157874941955
> [6] https://twitter.com/DonaldOJDK/status/981874485979746304
> 
> 
>> We are in a situation where previously "supported" platforms (by Oracle)
>> are no longer supported as, AFAIK, no one has stepped up to take
>> ownership of said platforms - which is a requirement for getting a new
>> port accepted into mainline. Without such ownership the code may not
>> only bit-rot, it may in time be stripped out completely. Any interested
>> parties would then need to look at (re)forming a port project for that
>> platform to keep it going in OpenJDK (or of course they are free to take
>> it elsewhere).
>>
>> Cheers,
>> David
>>
> 
> On 09/04/2018 18:35, White, Derek wrote:
>> Hi Magnus,
>>
>>> -----Original Message-----
>>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>>> From: Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>
>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>> 	<hotspot-dev at openjdk.java.net>
>>> Subject: Re: Supported platforms
>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> Simon,
>>>
>>> On 2018-04-08 16:30, Simon Nash wrote:
>>>> On 05/04/2018 02:26,bren at juanantonio.info  wrote:
>>>>> Many thanks with the link about the Platforms supported:
>>>>>
>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
>>>>> config-4417031.html
>>>>>
>>>> This appears to be a list of the platforms that are supported
>>>> (certified) by
>>>> Oracle.? Where can I find the list of platforms that are supported by
>>>> OpenJDK?? For example, what about the following platforms that don't
>>>> appear on the Oracle list:
>>>>
>>>> Windows x86
>>>> Linux x86
>>>> aarch32 (ARMv7 32-bit)
>>>> aarch64 (ARMv8 64-bit)
>>>>
>>>> Are all these supported for OpenJDK 9, 10 and 11?
>>> There is actually no such thing as a "supported OpenJDK platform". While I
>>> hope things may change in the future, OpenJDK as an organization does not
>>> publicize any list of "supported" platforms. Oracle publishes a list of
>>> platforms they support, and I presume that Red Hat and SAP and others do
>>> the same, but the OpenJDK project itself does not.
>>>
>>> With that said, platforms which were previously supported by Oracle (like
>>> the one's you mentioned) tend to still work more-or-less well, but they
>>> receive no or little testing, and is prone to bit rot.
>>>
>>> /Magnus
>> Surely you meant to say "receive no or little testing BY ORACLE, and ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>>
>> I haven't found a definitive list of supported OpenJDK platforms, but have an ad-hoc list of publicly available binaries:
>> - Major linux distros are supporting x64 and aarch64 (arm64), and probably other platforms.
>> - AdoptOpenJDK provides tested builds for most 64-bit platforms (x64, aarch64, ppc64, s390).
>>       -https://adoptopenjdk.net/releases.html
>> - Bellsoft provides support for 32-bit ARMv7.
>>      -https://bell-sw.com/products.html
>> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 and aarch64.
>>      -https://www.azul.com/downloads/zulu/
>>
>> I'm sure there are several others I've missed - sorry!
>>   - Derek
> 


From magnus.ihse.bursie at oracle.com  Tue Apr 10 08:24:35 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 10:24:35 +0200
Subject: RFR: 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469
In-Reply-To: <CA+kOe0-Bqcf2vpwzfNbEtpttd6SQm0gMpiPq0tUVtD4RKPEajg@mail.gmail.com>
References: <CA+kOe0-Bqcf2vpwzfNbEtpttd6SQm0gMpiPq0tUVtD4RKPEajg@mail.gmail.com>
Message-ID: <1FDE608C-0778-4C2D-9BA1-AC0FC501EB7E@oracle.com>


> 10 apr. 2018 kl. 07:46 skrev Martin Buchholz <martinrb at google.com>:
> 
> Hi Magnus, please review:
> 
> 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469

Oops. Sorry. :(

> http://cr.openjdk.java.net/~martin/webrevs/jdk/ALSA_CFLAGS/

Looks good to me. Thank you for fixing this!

/Magnus

> https://bugs.openjdk.java.net/browse/JDK-8201357
> 


From david.holmes at oracle.com  Tue Apr 10 09:24:34 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 19:24:34 +1000
Subject: Supported platforms
In-Reply-To: <dbd6f182-3f5d-cfb0-4e52-f7e31ed86f3f@bell-sw.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
 <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>
 <dbd6f182-3f5d-cfb0-4e52-f7e31ed86f3f@bell-sw.com>
Message-ID: <f2a71174-4a64-9767-607a-287299d39831@oracle.com>

On 10/04/2018 7:17 PM, Aleksei Voitylov wrote:
> David,
> 
> see inline:
> 
> 
> On 10/04/2018 11:00, David Holmes wrote:
>> Hi Aleksei,
>>
>> This is all news to me. Good news, but unexpected. As far as I was 
>> aware the 32-bit ARM port was dying a slow death and would eventually 
>> get removed. 64-bit ARM is of course very much alive and well under 
>> the Aarch64 porters - though I'm unclear if you are using that code 
>> for ARMv8 or the Oracle contributed code that used to be closed?
> You are welcome :) We are doing everything possible to keep it running, 
> so I don't see any reason within OpenJDK to it being removed. Regarding 
> ARMv8 port, we are working with Cavium, Redhat, and Linaro on supporting 
> the AARCH64 port.
>>
>> I'm also unclear whether you are pushing changes back up to OpenJDK 
>> for these platforms, or maintaining them locally? I haven't noticed 
>> anything (other than build tweaks) and am curious about the release of 
>> a Minimal VM for JDK 10 given the Minimal VM effectively died along 
>> with the stand-alone Client VM.
> We push everything upstream.

I don't recall seeing anything related to 32-bit ARM, but perhaps it's 
all in areas I don't see (like compiler and gc).

> I'm not sure why you believe Minimal VM and 
> Client VM died in OpenJDK 10. From what I remember, there was some 
> decision related to Client VM for Oracle binaries, but support for C1 
> and Minimal VM was not removed from OpenJDK codebase. This is what I get 
> with BellSoft Liberica binaries built from OpenJDK on Raspberry Pi:

Sorry I was mis-remembering. Of course C1 and Minimal still exist in the 
32-bit code. Though I would be concerned that with a focus on 64-bit it 
will be easy for engineers to overlook things that should be inside one 
of the INCLUDE_XXX guards. (Particularly as we don't do any 32-bit 
builds and for the most part don't even have the capability to perform 
them.)

Cheers,
David

>> pi at rpi-3:~ $ java -version
>> openjdk version "10-BellSoft" 2018-03-20
>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>> OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
>> pi at rpi-3:~ $ java -minimal -version
>> openjdk version "10-BellSoft" 2018-03-20
>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>> OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
>> pi at rpi-3:~ $ java -client -version
>> openjdk version "10-BellSoft" 2018-03-20
>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>> OpenJDK Client VM (build 10-BellSoft+0, mixed mode)
> 
>> pi at rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
>> ???? bool C1OptimizeVirtualCallProfiling?????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1ProfileBranches??????????????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1ProfileCalls?????????????????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1ProfileCheckcasts????????????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1ProfileInlinedCalls??????????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1ProfileVirtualCalls??????????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool C1UpdateMethodData?????????????????????? = 
>> false???????????????????????????????? {C1 product} {default}
>> ???? bool InlineSynchronizedMethods??????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? bool LIRFillDelaySlots??????????????????????? = 
>> false????????????????????????????? {C1 pd product} {default}
>> ???? bool TimeLinearScan?????????????????????????? = 
>> false???????????????????????????????? {C1 product} {default}
>> ???? bool UseLoopInvariantCodeMotion?????????????? = 
>> true????????????????????????????????? {C1 product} {default}
>> ???? intx ValueMapInitialSize????????????????????? = 
>> 11??????????????????????????????????? {C1 product} {default}
>> ???? intx ValueMapMaxLoopSize????????????????????? = 
>> 8???????????????????????????????????? {C1 product} {default}
> 
> Minimal VM and Client VM include C1, and Server VM includes C1 and C2. 
> All (Client VM, Server VM, Minimal VM) were tested and work as expected.
> 
>>
>> For JDK11 you will need to do some work for Condy (if not already 
>> done) as well as JFR and Nest-based Access Control (which you can see 
>> in the nestmates branch of the Valhalla repo), as you mention below. 
>> Not sure what else may be needed. There's been a lot of code 
>> refactoring and include file changes that have impact on platform 
>> specific code as well.
> Thanks for the heads-up!
> 
> -Aleksei
>>
>> Cheers,
>> David
>>
>> On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
>>> Hi David,
>>>
>>> Speaking about the arm/ port, BellSoft has been releasing 
>>> JCK-verified binaries (as provided under the OpenJDK license) from 
>>> the arm/ port for the Raspberry Pi for JDK 9 [1] for a while and 
>>> recently released one for JDK 10 [2], including OpenJFX and Minimal 
>>> VM support. On Raspberry Pi 2 (ARMv7) and Raspberry Pi 3 (ARMv8 chip 
>>> running Raspbian) the binaries produced from this port are passing 
>>> all the required testing, including the new features recently 
>>> open-sourced by Oracle (such as AppCDS). As far as JDK 11 is 
>>> concerned, we are keeping track of the changes, recently fixed a 
>>> couple of build issues that slipped in [3, 4], are working on Minimal 
>>> Value Types support and, from what I can tell, will need to look into 
>>> JFR and Nest-Based Access Control. Please let us know if we missed 
>>> anything and we need to prepare for some other new features for porting.
>>>
>>> The intent is to keep the arm/ port in good shape and provide 
>>> well-tested binaries for the Raspberry Pi.
>>>
>>> I believed Oracle was aware about BellSoft producing binaries from 
>>> this port [5], [6]. Based on twitter, it seems like at least some 
>>> engineers at Redhat and SAP are aware about it. Let me know if there 
>>> is anything else we need to do to spread the word about it with 
>>> Oracle engineering. For now, Boris (cced) is the engineer at BellSoft 
>>> working on supporting the arm/ port for the Raspberry Pi. Other than 
>>> that, I really wonder what "stepping up to take ownership of a port" 
>>> means when it's upstream, and there is some procedure we need to follow.
>>>
>>> Thanks,
>>>
>>> -Aleksei
>>>
>>> [1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
>>> [2] https://bell-sw.com/java-for-raspberry-pi.html
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8200628
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8198949
>>> [5] https://twitter.com/java/status/981239157874941955
>>> [6] https://twitter.com/DonaldOJDK/status/981874485979746304
>>>
>>>
>>>> We are in a situation where previously "supported" platforms (by 
>>>> Oracle)
>>>> are no longer supported as, AFAIK, no one has stepped up to take
>>>> ownership of said platforms - which is a requirement for getting a new
>>>> port accepted into mainline. Without such ownership the code may not
>>>> only bit-rot, it may in time be stripped out completely. Any interested
>>>> parties would then need to look at (re)forming a port project for that
>>>> platform to keep it going in OpenJDK (or of course they are free to 
>>>> take
>>>> it elsewhere).
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>
>>> On 09/04/2018 18:35, White, Derek wrote:
>>>> Hi Magnus,
>>>>
>>>>> -----Original Message-----
>>>>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>>>>> From: Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>
>>>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>>>> ????<hotspot-dev at openjdk.java.net>
>>>>> Subject: Re: Supported platforms
>>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>>
>>>>> Simon,
>>>>>
>>>>> On 2018-04-08 16:30, Simon Nash wrote:
>>>>>> On 05/04/2018 02:26,bren at juanantonio.info? wrote:
>>>>>>> Many thanks with the link about the Platforms supported:
>>>>>>>
>>>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
>>>>>>> config-4417031.html
>>>>>>>
>>>>>> This appears to be a list of the platforms that are supported
>>>>>> (certified) by
>>>>>> Oracle.? Where can I find the list of platforms that are supported by
>>>>>> OpenJDK?? For example, what about the following platforms that don't
>>>>>> appear on the Oracle list:
>>>>>>
>>>>>> Windows x86
>>>>>> Linux x86
>>>>>> aarch32 (ARMv7 32-bit)
>>>>>> aarch64 (ARMv8 64-bit)
>>>>>>
>>>>>> Are all these supported for OpenJDK 9, 10 and 11?
>>>>> There is actually no such thing as a "supported OpenJDK platform". 
>>>>> While I
>>>>> hope things may change in the future, OpenJDK as an organization 
>>>>> does not
>>>>> publicize any list of "supported" platforms. Oracle publishes a 
>>>>> list of
>>>>> platforms they support, and I presume that Red Hat and SAP and 
>>>>> others do
>>>>> the same, but the OpenJDK project itself does not.
>>>>>
>>>>> With that said, platforms which were previously supported by Oracle 
>>>>> (like
>>>>> the one's you mentioned) tend to still work more-or-less well, but 
>>>>> they
>>>>> receive no or little testing, and is prone to bit rot.
>>>>>
>>>>> /Magnus
>>>> Surely you meant to say "receive no or little testing BY ORACLE, and 
>>>> ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>>>>
>>>> I haven't found a definitive list of supported OpenJDK platforms, 
>>>> but have an ad-hoc list of publicly available binaries:
>>>> - Major linux distros are supporting x64 and aarch64 (arm64), and 
>>>> probably other platforms.
>>>> - AdoptOpenJDK provides tested builds for most 64-bit platforms 
>>>> (x64, aarch64, ppc64, s390).
>>>> ????? -https://adoptopenjdk.net/releases.html
>>>> - Bellsoft provides support for 32-bit ARMv7.
>>>> ???? -https://bell-sw.com/products.html
>>>> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 
>>>> and aarch64.
>>>> ???? -https://www.azul.com/downloads/zulu/
>>>>
>>>> I'm sure there are several others I've missed - sorry!
>>>> ? - Derek
>>>
> 

From matthias.baesken at sap.com  Tue Apr 10 10:14:38 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 10 Apr 2018 10:14:38 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
Message-ID: <99420e261ef347578bb8099a48d6b7ec@sap.com>

Hello,  I  had to  do another small adjustment  to make jimage.hpp/cpp match.    Please review :

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

With the latest webrev I could finally    build    jdk/jdk   successfully on both  win32bit   and win64 bit .



Thanks again  to Alexey  to provide  the   incorporated patch .


Best regards, Matthias



> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Montag, 9. April 2018 17:14
> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias,
> 
> On 09/04/2018 15:38, Baesken, Matthias wrote:
> > Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations
> .
> >
> > I created  a second  webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> >
> > -   it  adds  the diff  provided by you    (hope that?s fine with you)
> 
> Yes, that's fine with me.
> There could be only one author ;)
> 
> > -    changes  2 launchers    src/java.base/share/native/launcher/main.c    and
> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
> issues after mapfile removal for exes
> 
> I'd rather remove both JNIEXPORT and JNICALL from main().
> It wasn't exported, and it shouldn't be.
> 
> Regards,
> Alexey
> 
> >
> >
> >
> > Best regards , Matthias
> >
> >
> >> -----Original Message-----
> >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >> Sent: Montag, 9. April 2018 15:52
> >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> >> Matthias <matthias.baesken at sap.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Matthias, Magnus,
> >>
> >> The problem is with JNICALL added to the functions. JNICALL expands to
> >> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
> >> ignored. On 32 bit, the modifier changes the way parameters are pass and
> >> the function name is decorated with an underscore and with @ + the size
> >> of arguments.
> >>
> >> If I remove JNICALL modifier from the exported functions, they're
> >> exported with plain name as in source code (plus, __cdecl [2] calling
> >> convention is used.)
> >>
> >> zip.dll and jimage.dll are affected by this. It's because the exported
> >> functions are looked up by name rather than using a header file with
> >> JNIIMPORT. See
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l1155
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l1194
> >>
> >> JNICALL modifier must also be removed from type declarations for
> >> functions from zip.dll:
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l81
> >>
> >> I'm attaching the patch to zip and jimage as well as classLoader.cpp
> >> which takes these changes into account. It does not replace Matthias'
> >> patch but complements it.
> >>
> >>
> >> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
> >> pragma comments [3][4] to export undecorated names. But this is
> compiler
> >> specific and may require if's for other platforms.
> >>
> >>
> >> Regards,
> >> Alexey
> >>
> >> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
> >> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
> >> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
> >> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
> >>
> >> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
> >>> Those were added by my patch that removed the map files.
> >>>
> >>> /Magnus
> >>>
> >>>> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
> >> <matthias.baesken at sap.com>:
> >>>> I did  not add   JNICALL decorations  to  any  libzip functions , please see
> >> my webrev :
> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>
> >>>>> , the problem here
> >>>>> is the added JNICALL decoration, which affects only win32 (and
> >> incorrectly,
> >>>>> that is).
> >>>> so I wonder  which added  JNICALL  decoration   you are refering to .
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>>>> Sent: Montag, 9. April 2018 13:29
> >>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
> >>>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >> function
> >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> at
> >>>>> some places in function declarations/implementations
> >>>>>
> >>>>> Reinstating the -export command line options is not the way forward
> >> here.
> >>>>> As I understood it from private conversation with Alexey, the problem
> >> here
> >>>>> is the added JNICALL decoration, which affects only win32 (and
> >> incorrectly,
> >>>>> that is).
> >>>>>
> >>>>> /Magnus
> >>>>>
> >>>>>
> <SNIP>

From martin.doerr at sap.com  Tue Apr 10 10:46:01 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 10 Apr 2018 10:46:01 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <99420e261ef347578bb8099a48d6b7ec@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
Message-ID: <e15c48bc6a5c4905b06b687cb04e9171@sap.com>

Hi Matthias,

thank you for providing the fix. I think these issues should really get fixed regardless if 32 bit is supported or not. It's not good to have inconsistent JNI declarations.

The fix looks good to me.

I guess it should get pushed to the submission forest because it contains hotspot changes. Or did Oracle run the necessary tests?

Best regards,
Martin


-----Original Message-----
From: Baesken, Matthias 
Sent: Dienstag, 10. April 2018 12:15
To: Alexey Ivanov <alexey.ivanov at oracle.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

Hello,  I  had to  do another small adjustment  to make jimage.hpp/cpp match.    Please review :

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

With the latest webrev I could finally    build    jdk/jdk   successfully on both  win32bit   and win64 bit .



Thanks again  to Alexey  to provide  the   incorporated patch .


Best regards, Matthias



> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Montag, 9. April 2018 17:14
> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias,
> 
> On 09/04/2018 15:38, Baesken, Matthias wrote:
> > Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations
> .
> >
> > I created  a second  webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> >
> > -   it  adds  the diff  provided by you    (hope that?s fine with you)
> 
> Yes, that's fine with me.
> There could be only one author ;)
> 
> > -    changes  2 launchers    src/java.base/share/native/launcher/main.c    and
> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
> issues after mapfile removal for exes
> 
> I'd rather remove both JNIEXPORT and JNICALL from main().
> It wasn't exported, and it shouldn't be.
> 
> Regards,
> Alexey
> 
> >
> >
> >
> > Best regards , Matthias
> >
> >
> >> -----Original Message-----
> >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >> Sent: Montag, 9. April 2018 15:52
> >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
> >> Matthias <matthias.baesken at sap.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Matthias, Magnus,
> >>
> >> The problem is with JNICALL added to the functions. JNICALL expands to
> >> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
> >> ignored. On 32 bit, the modifier changes the way parameters are pass and
> >> the function name is decorated with an underscore and with @ + the size
> >> of arguments.
> >>
> >> If I remove JNICALL modifier from the exported functions, they're
> >> exported with plain name as in source code (plus, __cdecl [2] calling
> >> convention is used.)
> >>
> >> zip.dll and jimage.dll are affected by this. It's because the exported
> >> functions are looked up by name rather than using a header file with
> >> JNIIMPORT. See
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l1155
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l1194
> >>
> >> JNICALL modifier must also be removed from type declarations for
> >> functions from zip.dll:
> >>
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> >> ssLoader.cpp#l81
> >>
> >> I'm attaching the patch to zip and jimage as well as classLoader.cpp
> >> which takes these changes into account. It does not replace Matthias'
> >> patch but complements it.
> >>
> >>
> >> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
> >> pragma comments [3][4] to export undecorated names. But this is
> compiler
> >> specific and may require if's for other platforms.
> >>
> >>
> >> Regards,
> >> Alexey
> >>
> >> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
> >> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
> >> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
> >> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
> >>
> >> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
> >>> Those were added by my patch that removed the map files.
> >>>
> >>> /Magnus
> >>>
> >>>> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
> >> <matthias.baesken at sap.com>:
> >>>> I did  not add   JNICALL decorations  to  any  libzip functions , please see
> >> my webrev :
> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>
> >>>>> , the problem here
> >>>>> is the added JNICALL decoration, which affects only win32 (and
> >> incorrectly,
> >>>>> that is).
> >>>> so I wonder  which added  JNICALL  decoration   you are refering to .
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>>>> Sent: Montag, 9. April 2018 13:29
> >>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
> >>>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
> >>>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >> function
> >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> at
> >>>>> some places in function declarations/implementations
> >>>>>
> >>>>> Reinstating the -export command line options is not the way forward
> >> here.
> >>>>> As I understood it from private conversation with Alexey, the problem
> >> here
> >>>>> is the added JNICALL decoration, which affects only win32 (and
> >> incorrectly,
> >>>>> that is).
> >>>>>
> >>>>> /Magnus
> >>>>>
> >>>>>
> <SNIP>

From sgehwolf at redhat.com  Tue Apr 10 11:25:36 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 10 Apr 2018 13:25:36 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
Message-ID: <1523359536.4542.2.camel@redhat.com>

Hi Erik,

On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
> Hello Severin,
> 
> I'm ok with this solution for now.

Thanks for the review!

> Could you please reduce the indentation on line 652. In the build system 
> we like 4 spaces for continuation indent [1]

Done. New webrev at:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02

Could someone from awt-dev have a look at this too? Thanks!

Cheers,
Severin

> /Erik
> 
> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
> 
> On 2018-04-09 06:39, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review this build fix for libfontmanager.so. The
> > issue for us is that with some LDFLAGS the build breaks as described in
> > bug JDK-8196218. However, we cannot link to a providing library at
> > build-time since we don't know which one it should be: libawt_headless
> > or libawt_xawt. That has to happen at runtime. The proposed fix filters
> > out relevant linker flags when libfontmanager is being built. More
> > details are in the bug.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
> > 
> > Testing: I've run this through submit[1] and got the following results.
> > SwingSet2 works fine for me on F27. I'm currently running some more
> > tests on RHEL 7.
> > 
> > ---------------------
> > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
> > 
> > 0 Failed Tests
> > 
> > Mach5 Tasks Results Summary
> > 
> > NA: 0
> > UNABLE_TO_RUN: 0
> > EXECUTED_WITH_FAILURE: 0
> > KILLED: 0
> > PASSED: 82
> > FAILED: 1
> > Test
> > 
> > 1 Failed
> > 
> > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
> > debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
> > return value: 10
> > --------------------
> > 
> > Not sure what this test failure means. Could somebody at Oracle shed
> > some light on this?
> > 
> > Thanks,
> > Severin
> 
> 


From sgehwolf at redhat.com  Tue Apr 10 11:30:56 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 10 Apr 2018 13:30:56 +0200
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with
 LDFLAGS allowing unresolved symbols
In-Reply-To: <1523281192.148486.9.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
Message-ID: <1523359856.4542.7.camel@redhat.com>

On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote:
> Hi,
> 
> Could somebody please review this build fix for libfontmanager.so. The
> issue for us is that with some LDFLAGS the build breaks as described in
> bug JDK-8196218. However, we cannot link to a providing library at
> build-time since we don't know which one it should be: libawt_headless
> or libawt_xawt. That has to happen at runtime. The proposed fix filters
> out relevant linker flags when libfontmanager is being built. More
> details are in the bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516

Latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02/

> Testing: I've run this through submit[1] and got the following results.
> SwingSet2 works fine for me on F27. I'm currently running some more
> tests on RHEL 7.

I've finished testing on RHEL 7 by manually verifying that not both
libawt_xawt and libawt_headless get loaded when running SwingSet.

Could somebody tell me what this failure below is about?

Thanks,
Severin

> ---------------------
> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
> 
> 0 Failed Tests
> 
> Mach5 Tasks Results Summary
> 
> NA: 0
> UNABLE_TO_RUN: 0
> EXECUTED_WITH_FAILURE: 0
> KILLED: 0
> PASSED: 82
> FAILED: 1
> Test
> 
> 1 Failed
> 
> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
> return value: 10
> --------------------
> 
> Not sure what this test failure means. Could somebody at Oracle shed
> some light on this?
> 
> Thanks,
> Severin


From david.holmes at oracle.com  Tue Apr 10 11:34:05 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 21:34:05 +1000
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
Message-ID: <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>

Adding in build-dev. I think the build guys need to help you figure this 
out.

Cheers,
David

On 10/04/2018 9:21 PM, John Paul Adrian Glaubitz wrote:
> On 04/10/2018 01:00 PM, John Paul Adrian Glaubitz wrote:
>> Trying to add the necessary source there now.
> 
> Hmm, I tried various ways of adding it now:
> 
> diff -r a47d1e21b3f1 make/hotspot/lib/CompileGtest.gmk
> --- a/make/hotspot/lib/CompileGtest.gmk Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:15:36 2018 +0300
> @@ -52,6 +52,14 @@
>  ??????? $(call create-mapfile)
>  ?endif
> 
> +ifeq ($(call check-jvm-feature, zero), true)
> +? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP 
> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> +? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES := 
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> +endif
> +
>  ?# Disabling undef, switch, format-nonliteral and 
> tautological-undefined-compare
>  ?# warnings for clang because of test source.
> 
> @@ -71,7 +79,8 @@
>  ???? EXCLUDES := $(JVM_EXCLUDES), \
>  ???? EXCLUDE_FILES := gtestLauncher.cpp, \
>  ???? EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
> -??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
> +??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
> +        
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
>  ???? EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
>  ???????? $(BUILD_LIBJVM_ALL_OBJS)), \
>  ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> @@ -109,7 +118,8 @@
>  ???? NAME := gtestLauncher, \
>  ???? TYPE := EXECUTABLE, \
>  ???? OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
> -??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
> +??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
> +         
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
>  ???? OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
>  ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
>  ???????? -I$(GTEST_FRAMEWORK_SRC)/include, \
> diff -r a47d1e21b3f1 make/hotspot/lib/CompileJvm.gmk
> --- a/make/hotspot/lib/CompileJvm.gmk?? Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/hotspot/lib/CompileJvm.gmk?? Tue Apr 10 14:15:36 2018 +0300
> @@ -197,6 +197,14 @@
>  ?? endif
>  ?endif
> 
> +ifeq ($(call check-jvm-feature, zero), true)
> +? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP 
> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> +? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES := 
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> +endif
> +
>  ?ifeq ($(OPENJDK_TARGET_OS), windows)
>  ?? ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)
>  ???? RC_DESC := 64-Bit$(SPACE)
> 
> It does build it, but the build system is unable to find the object files:
> 
> glaubitz at deb4g:/srv/glaubitz/hs$ find . -name 
> "memset_with_concurrent_readers_sparc.o"
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o 
> 
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o 
> 
> glaubitz at deb4g:/srv/glaubitz/hs$
> 
> Adrian
> 


From glaubitz at physik.fu-berlin.de  Tue Apr 10 11:37:34 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:37:34 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
Message-ID: <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>

On 04/10/2018 01:34 PM, David Holmes wrote:
> Adding in build-dev. I think the build guys need to help you figure this out.

Good idea.

@buildd-dev:

I need to build memset_with_concurrent_readers_sparc.cpp for Zero on SPARC as
the Zero build now bails out with linker errors:

=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" <  /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o: In function `gc_memset_with_concurrent_readers_test_Test::TestBody()':
/srv/glaubitz/hs/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp:66: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" <  /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion, bool)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n"
* For target jdk_modules_java.base__the.java.base_batch:
(/bin/grep -v -e "^Note: including file:" <  /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log || true) | /usr/bin/head -n 12
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n"

* All command lines available in /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===

Any ideas?

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From glaubitz at physik.fu-berlin.de  Tue Apr 10 11:58:50 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:58:50 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
 <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
Message-ID: <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>

On 04/10/2018 01:37 PM, John Paul Adrian Glaubitz wrote:
> @buildd-dev:
> 
> I need to build memset_with_concurrent_readers_sparc.cpp for Zero on SPARC as
> the Zero build now bails out with linker errors:
Add the source file in question to EXTRA_FILES:

glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
diff -r b3c09ab95c1a make/hotspot/lib/CompileGtest.gmk
--- a/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 12:21:58 2018 +0200
+++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:57:05 2018 +0300
@@ -71,7 +71,8 @@
      EXCLUDES := $(JVM_EXCLUDES), \
      EXCLUDE_FILES := gtestLauncher.cpp, \
      EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
-    EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
+    EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
+        $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
      EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
          $(BUILD_LIBJVM_ALL_OBJS)), \
      CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
@@ -109,7 +110,8 @@
      NAME := gtestLauncher, \
      TYPE := EXECUTABLE, \
      OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
-    EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
+    EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
+        $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
      OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
      CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
          -I$(GTEST_FRAMEWORK_SRC)/include, \
glaubitz at deb4g:/srv/glaubitz/hs$

Causes the object files to be built. But for some reason, the linker is not
picking up those object files even though they are located in the object
directories of gtest:

glaubitz at deb4g:/srv/glaubitz/hs$ find . -name "memset_with_concurrent_readers_sparc.o"
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o
glaubitz at deb4g:/srv/glaubitz/hs$

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From bhamaram at in.ibm.com  Tue Apr 10 15:44:26 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Tue, 10 Apr 2018 15:44:26 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
Message-ID: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>

A non-text attachment was scrubbed...
Name: libjvm.loadmap
Type: application/octet-stream
Size: 90786 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20180410/de79a98d/libjvm.loadmap>

From magnus.ihse.bursie at oracle.com  Tue Apr 10 16:15:53 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 18:15:53 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <99420e261ef347578bb8099a48d6b7ec@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
Message-ID: <02119D11-1DD3-4386-A9F4-1B7669CFDC95@oracle.com>


> 10 apr. 2018 kl. 12:14 skrev Baesken, Matthias <matthias.baesken at sap.com>:
> 
> Hello,  I  had to  do another small adjustment  to make jimage.hpp/cpp match.    Please review :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/

Looks good to me. 

/Magnus

> 
> With the latest webrev I could finally    build    jdk/jdk   successfully on both  win32bit   and win64 bit .
> 
> 
> 
> Thanks again  to Alexey  to provide  the   incorporated patch .
> 
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Montag, 9. April 2018 17:14
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Hi Matthias,
>> 
>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations
>> .
>>> 
>>> I created  a second  webrev :
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>> 
>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>> 
>> Yes, that's fine with me.
>> There could be only one author ;)
>> 
>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c    and
>> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
>> issues after mapfile removal for exes
>> 
>> I'd rather remove both JNIEXPORT and JNICALL from main().
>> It wasn't exported, and it shouldn't be.
>> 
>> Regards,
>> Alexey
>> 
>>> 
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Montag, 9. April 2018 15:52
>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Baesken,
>>>> Matthias <matthias.baesken at sap.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>> 
>>>> Hi Matthias, Magnus,
>>>> 
>>>> The problem is with JNICALL added to the functions. JNICALL expands to
>>>> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
>>>> ignored. On 32 bit, the modifier changes the way parameters are pass and
>>>> the function name is decorated with an underscore and with @ + the size
>>>> of arguments.
>>>> 
>>>> If I remove JNICALL modifier from the exported functions, they're
>>>> exported with plain name as in source code (plus, __cdecl [2] calling
>>>> convention is used.)
>>>> 
>>>> zip.dll and jimage.dll are affected by this. It's because the exported
>>>> functions are looked up by name rather than using a header file with
>>>> JNIIMPORT. See
>>>> 
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>>>> ssLoader.cpp#l1155
>>>> 
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>>>> ssLoader.cpp#l1194
>>>> 
>>>> JNICALL modifier must also be removed from type declarations for
>>>> functions from zip.dll:
>>>> 
>> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
>>>> ssLoader.cpp#l81
>>>> 
>>>> I'm attaching the patch to zip and jimage as well as classLoader.cpp
>>>> which takes these changes into account. It does not replace Matthias'
>>>> patch but complements it.
>>>> 
>>>> 
>>>> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
>>>> pragma comments [3][4] to export undecorated names. But this is
>> compiler
>>>> specific and may require if's for other platforms.
>>>> 
>>>> 
>>>> Regards,
>>>> Alexey
>>>> 
>>>> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
>>>> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
>>>> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
>>>> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
>>>> 
>>>>> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
>>>>> Those were added by my patch that removed the map files.
>>>>> 
>>>>> /Magnus
>>>>> 
>>>>>> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
>>>> <matthias.baesken at sap.com>:
>>>>>> I did  not add   JNICALL decorations  to  any  libzip functions , please see
>>>> my webrev :
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>>> 
>>>>>>> , the problem here
>>>>>>> is the added JNICALL decoration, which affects only win32 (and
>>>> incorrectly,
>>>>>>> that is).
>>>>>> so I wonder  which added  JNICALL  decoration   you are refering to .
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>>>>> Sent: Montag, 9. April 2018 13:29
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>>>>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; build-dev <build-
>>>>>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>> at
>>>>>>> some places in function declarations/implementations
>>>>>>> 
>>>>>>> Reinstating the -export command line options is not the way forward
>>>> here.
>>>>>>> As I understood it from private conversation with Alexey, the problem
>>>> here
>>>>>>> is the added JNICALL decoration, which affects only win32 (and
>>>> incorrectly,
>>>>>>> that is).
>>>>>>> 
>>>>>>> /Magnus
>>>>>>> 
>>>>>>> 
>> <SNIP>



From erik.joelsson at oracle.com  Tue Apr 10 16:29:20 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 09:29:20 -0700
Subject: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the
 SystemV variant of the timezone
In-Reply-To: <b2affb0d-1cc2-6acd-f83e-bebc8d3b9886@oracle.com>
References: <8f639e94-1564-17b2-d999-31f46c9a1a08@oracle.com>
 <c2615d3e-2ff1-2a41-62b5-15a40b6a1ef5@oracle.com>
 <b2affb0d-1cc2-6acd-f83e-bebc8d3b9886@oracle.com>
Message-ID: <fea8cf81-d749-5f38-e170-4647158e3e4e@oracle.com>

This looks very good. Thanks!

(reviewed build part)

/Erik


On 2018-04-09 18:00, naoto.sato at oracle.com wrote:
> Thanks, Erik. Modified GensrcCLDR.gmk as suggested:
>
> http://cr.openjdk.java.net/~naoto/8189784/webrev.03/
>
> Naoto
>
> On 4/9/18 4:15 PM, Erik Joelsson wrote:
>> Hello Naoto,
>>
>> Looks good, just a style issue.
>>
>> When breaking a recipe line, please add 4 additional spaces (after 
>> the tab) for continuation indent [1]. In this case I would also 
>> advocate breaking the line sooner to make side by side comparisons 
>> easier in the future.
>>
>> /Erik
>>
>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>
>> On 2018-04-09 13:20, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8189784
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8189784/webrev.02/
>>>
>>> There were two causes of the issue. One was that j.t.f.ZoneName 
>>> contained hard coded mappings based on the old CLDR data and never 
>>> been updated. The other reason was that CLDR's deprecated zones 
>>> ("SystemV" ones, in this case) were not properly replaced.
>>>
>>> I am including build-dev for the review, as the change includes 
>>> generating ZoneName mapping at the build time from the template.
>>>
>>> Naoto
>>



From erik.joelsson at oracle.com  Tue Apr 10 16:34:10 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 09:34:10 -0700
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing
 unresolved symbols
In-Reply-To: <1523359536.4542.2.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
Message-ID: <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>

Looks good. Thanks!

/Erik


On 2018-04-10 04:25, Severin Gehwolf wrote:
> Hi Erik,
>
> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> I'm ok with this solution for now.
> Thanks for the review!
>
>> Could you please reduce the indentation on line 652. In the build system
>> we like 4 spaces for continuation indent [1]
> Done. New webrev at:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
>
> Could someone from awt-dev have a look at this too? Thanks!
>
> Cheers,
> Severin
>
>> /Erik
>>
>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>
>> On 2018-04-09 06:39, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review this build fix for libfontmanager.so. The
>>> issue for us is that with some LDFLAGS the build breaks as described in
>>> bug JDK-8196218. However, we cannot link to a providing library at
>>> build-time since we don't know which one it should be: libawt_headless
>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters
>>> out relevant linker flags when libfontmanager is being built. More
>>> details are in the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
>>>
>>> Testing: I've run this through submit[1] and got the following results.
>>> SwingSet2 works fine for me on F27. I'm currently running some more
>>> tests on RHEL 7.
>>>
>>> ---------------------
>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
>>>
>>> 0 Failed Tests
>>>
>>> Mach5 Tasks Results Summary
>>>
>>> NA: 0
>>> UNABLE_TO_RUN: 0
>>> EXECUTED_WITH_FAILURE: 0
>>> KILLED: 0
>>> PASSED: 82
>>> FAILED: 1
>>> Test
>>>
>>> 1 Failed
>>>
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
>>> return value: 10
>>> --------------------
>>>
>>> Not sure what this test failure means. Could somebody at Oracle shed
>>> some light on this?
>>>
>>> Thanks,
>>> Severin
>>



From erik.joelsson at oracle.com  Tue Apr 10 16:36:41 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 09:36:41 -0700
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <1523359856.4542.7.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
 <1523359856.4542.7.camel@redhat.com>
Message-ID: <6ed2dd10-0363-3f26-310e-c8783ab35042@oracle.com>


On 2018-04-10 04:30, Severin Gehwolf wrote:
> On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote:
>> Hi,
>>
>> Could somebody please review this build fix for libfontmanager.so. The
>> issue for us is that with some LDFLAGS the build breaks as described in
>> bug JDK-8196218. However, we cannot link to a providing library at
>> build-time since we don't know which one it should be: libawt_headless
>> or libawt_xawt. That has to happen at runtime. The proposed fix filters
>> out relevant linker flags when libfontmanager is being built. More
>> details are in the bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> Latest webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02/
>
>> Testing: I've run this through submit[1] and got the following results.
>> SwingSet2 works fine for me on F27. I'm currently running some more
>> tests on RHEL 7.
> I've finished testing on RHEL 7 by manually verifying that not both
> libawt_xawt and libawt_headless get loaded when running SwingSet.
>
> Could somebody tell me what this failure below is about?
This was an internal infrastructure failure. I would say it's safe to 
ignore.

/Erik
> Thanks,
> Severin
>
>> ---------------------
>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
>>
>> 0 Failed Tests
>>
>> Mach5 Tasks Results Summary
>>
>> NA: 0
>> UNABLE_TO_RUN: 0
>> EXECUTED_WITH_FAILURE: 0
>> KILLED: 0
>> PASSED: 82
>> FAILED: 1
>> Test
>>
>> 1 Failed
>>
>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
>> return value: 10
>> --------------------
>>
>> Not sure what this test failure means. Could somebody at Oracle shed
>> some light on this?
>>
>> Thanks,
>> Severin



From martijnverburg at gmail.com  Tue Apr 10 16:42:23 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 10 Apr 2018 17:42:23 +0100
Subject: Supported platforms
In-Reply-To: <f2a71174-4a64-9767-607a-287299d39831@oracle.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
 <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>
 <dbd6f182-3f5d-cfb0-4e52-f7e31ed86f3f@bell-sw.com>
 <f2a71174-4a64-9767-607a-287299d39831@oracle.com>
Message-ID: <CAP7YuAQZQTT5dwMNa+UUE5G8GCF6vUENzH3qLHANoN00CurBcQ@mail.gmail.com>

Hi all,

Apologies for being late to the thread.  We're looking to provide a central
place for OpenJDK binaries to be produced and have some level of community
support for the more esoteric platforms.  Perhaps this is a place where you
can get some extra assistance in keeping a particular port vibrant (having
regularly tested builds helps)p.

See the following for details:

* https://www.github.com/adoptopejdk/TSC - Build Farm overview
* https://www.adoptopenjdk.net (end user site)
* https://www.adoptopenjdk.net/slack (join ~200 volunteers!)
* https://ci.adoptopenjdk.net (Jenkins cluster)

It's still a work in progress but many of the OpenJDK vendors you know of
today are involved (Oracle, IBM, Red Hat, SAP et al) and so we're hopeful
that the collaboration there will help the more esoteric platforms that do
gain genuine popularity and support can flourish without adding further
burden on a single vendor.

We'll be following a very strong policy of reporting and submitting patches
upstream to OpenJDK / OpenJ9 / <insert OpenJDK variant X>, exactly how it
works today with various porting and downstream implementations today.
This isn't strictly an OpenJDK effort, so please do head over to
https://www.adoptopenjdk.net/slack to find out more or ping the
adoption-discuss mailing list here at OpenJDK.

Cheers,
Martijn

On 10 April 2018 at 10:24, David Holmes <david.holmes at oracle.com> wrote:

> On 10/04/2018 7:17 PM, Aleksei Voitylov wrote:
>
>> David,
>>
>> see inline:
>>
>>
>> On 10/04/2018 11:00, David Holmes wrote:
>>
>>> Hi Aleksei,
>>>
>>> This is all news to me. Good news, but unexpected. As far as I was aware
>>> the 32-bit ARM port was dying a slow death and would eventually get
>>> removed. 64-bit ARM is of course very much alive and well under the Aarch64
>>> porters - though I'm unclear if you are using that code for ARMv8 or the
>>> Oracle contributed code that used to be closed?
>>>
>> You are welcome :) We are doing everything possible to keep it running,
>> so I don't see any reason within OpenJDK to it being removed. Regarding
>> ARMv8 port, we are working with Cavium, Redhat, and Linaro on supporting
>> the AARCH64 port.
>>
>>>
>>> I'm also unclear whether you are pushing changes back up to OpenJDK for
>>> these platforms, or maintaining them locally? I haven't noticed anything
>>> (other than build tweaks) and am curious about the release of a Minimal VM
>>> for JDK 10 given the Minimal VM effectively died along with the stand-alone
>>> Client VM.
>>>
>> We push everything upstream.
>>
>
> I don't recall seeing anything related to 32-bit ARM, but perhaps it's all
> in areas I don't see (like compiler and gc).
>
> I'm not sure why you believe Minimal VM and Client VM died in OpenJDK 10.
>> From what I remember, there was some decision related to Client VM for
>> Oracle binaries, but support for C1 and Minimal VM was not removed from
>> OpenJDK codebase. This is what I get with BellSoft Liberica binaries built
>> from OpenJDK on Raspberry Pi:
>>
>
> Sorry I was mis-remembering. Of course C1 and Minimal still exist in the
> 32-bit code. Though I would be concerned that with a focus on 64-bit it
> will be easy for engineers to overlook things that should be inside one of
> the INCLUDE_XXX guards. (Particularly as we don't do any 32-bit builds and
> for the most part don't even have the capability to perform them.)
>
> Cheers,
> David
>
> pi at rpi-3:~ $ java -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
>>> pi at rpi-3:~ $ java -minimal -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
>>> pi at rpi-3:~ $ java -client -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Client VM (build 10-BellSoft+0, mixed mode)
>>>
>>
>> pi at rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
>>>      bool C1OptimizeVirtualCallProfiling           =
>>> true                                  {C1 product} {default}
>>>      bool C1ProfileBranches                        =
>>> true                                  {C1 product} {default}
>>>      bool C1ProfileCalls                           =
>>> true                                  {C1 product} {default}
>>>      bool C1ProfileCheckcasts                      =
>>> true                                  {C1 product} {default}
>>>      bool C1ProfileInlinedCalls                    =
>>> true                                  {C1 product} {default}
>>>      bool C1ProfileVirtualCalls                    =
>>> true                                  {C1 product} {default}
>>>      bool C1UpdateMethodData                       =
>>> false                                 {C1 product} {default}
>>>      bool InlineSynchronizedMethods                =
>>> true                                  {C1 product} {default}
>>>      bool LIRFillDelaySlots                        =
>>> false                              {C1 pd product} {default}
>>>      bool TimeLinearScan                           =
>>> false                                 {C1 product} {default}
>>>      bool UseLoopInvariantCodeMotion               =
>>> true                                  {C1 product} {default}
>>>      intx ValueMapInitialSize                      =
>>> 11                                    {C1 product} {default}
>>>      intx ValueMapMaxLoopSize                      =
>>> 8                                     {C1 product} {default}
>>>
>>
>> Minimal VM and Client VM include C1, and Server VM includes C1 and C2.
>> All (Client VM, Server VM, Minimal VM) were tested and work as expected.
>>
>>
>>> For JDK11 you will need to do some work for Condy (if not already done)
>>> as well as JFR and Nest-based Access Control (which you can see in the
>>> nestmates branch of the Valhalla repo), as you mention below. Not sure what
>>> else may be needed. There's been a lot of code refactoring and include file
>>> changes that have impact on platform specific code as well.
>>>
>> Thanks for the heads-up!
>>
>> -Aleksei
>>
>>
>>> Cheers,
>>> David
>>>
>>> On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
>>>
>>>> Hi David,
>>>>
>>>> Speaking about the arm/ port, BellSoft has been releasing JCK-verified
>>>> binaries (as provided under the OpenJDK license) from the arm/ port for the
>>>> Raspberry Pi for JDK 9 [1] for a while and recently released one for JDK 10
>>>> [2], including OpenJFX and Minimal VM support. On Raspberry Pi 2 (ARMv7)
>>>> and Raspberry Pi 3 (ARMv8 chip running Raspbian) the binaries produced from
>>>> this port are passing all the required testing, including the new features
>>>> recently open-sourced by Oracle (such as AppCDS). As far as JDK 11 is
>>>> concerned, we are keeping track of the changes, recently fixed a couple of
>>>> build issues that slipped in [3, 4], are working on Minimal Value Types
>>>> support and, from what I can tell, will need to look into JFR and
>>>> Nest-Based Access Control. Please let us know if we missed anything and we
>>>> need to prepare for some other new features for porting.
>>>>
>>>> The intent is to keep the arm/ port in good shape and provide
>>>> well-tested binaries for the Raspberry Pi.
>>>>
>>>> I believed Oracle was aware about BellSoft producing binaries from this
>>>> port [5], [6]. Based on twitter, it seems like at least some engineers at
>>>> Redhat and SAP are aware about it. Let me know if there is anything else we
>>>> need to do to spread the word about it with Oracle engineering. For now,
>>>> Boris (cced) is the engineer at BellSoft working on supporting the arm/
>>>> port for the Raspberry Pi. Other than that, I really wonder what "stepping
>>>> up to take ownership of a port" means when it's upstream, and there is some
>>>> procedure we need to follow.
>>>>
>>>> Thanks,
>>>>
>>>> -Aleksei
>>>>
>>>> [1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
>>>> [2] https://bell-sw.com/java-for-raspberry-pi.html
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8200628
>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8198949
>>>> [5] https://twitter.com/java/status/981239157874941955
>>>> [6] https://twitter.com/DonaldOJDK/status/981874485979746304
>>>>
>>>>
>>>> We are in a situation where previously "supported" platforms (by Oracle)
>>>>> are no longer supported as, AFAIK, no one has stepped up to take
>>>>> ownership of said platforms - which is a requirement for getting a new
>>>>> port accepted into mainline. Without such ownership the code may not
>>>>> only bit-rot, it may in time be stripped out completely. Any interested
>>>>> parties would then need to look at (re)forming a port project for that
>>>>> platform to keep it going in OpenJDK (or of course they are free to
>>>>> take
>>>>> it elsewhere).
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>
>>>> On 09/04/2018 18:35, White, Derek wrote:
>>>>
>>>>> Hi Magnus,
>>>>>
>>>>> -----Original Message-----
>>>>>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>>>>>> From: Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>
>>>>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>>>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>>>>>     <hotspot-dev at openjdk.java.net>
>>>>>> Subject: Re: Supported platforms
>>>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>>>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>>>
>>>>>> Simon,
>>>>>>
>>>>>> On 2018-04-08 16:30, Simon Nash wrote:
>>>>>>
>>>>>>> On 05/04/2018 02:26,bren at juanantonio.info  wrote:
>>>>>>>
>>>>>>>> Many thanks with the link about the Platforms supported:
>>>>>>>>
>>>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/
>>>>>> jdk10cert
>>>>>>
>>>>>>> config-4417031.html
>>>>>>>>
>>>>>>>> This appears to be a list of the platforms that are supported
>>>>>>> (certified) by
>>>>>>> Oracle.? Where can I find the list of platforms that are supported by
>>>>>>> OpenJDK?? For example, what about the following platforms that don't
>>>>>>> appear on the Oracle list:
>>>>>>>
>>>>>>> Windows x86
>>>>>>> Linux x86
>>>>>>> aarch32 (ARMv7 32-bit)
>>>>>>> aarch64 (ARMv8 64-bit)
>>>>>>>
>>>>>>> Are all these supported for OpenJDK 9, 10 and 11?
>>>>>>>
>>>>>> There is actually no such thing as a "supported OpenJDK platform".
>>>>>> While I
>>>>>> hope things may change in the future, OpenJDK as an organization does
>>>>>> not
>>>>>> publicize any list of "supported" platforms. Oracle publishes a list
>>>>>> of
>>>>>> platforms they support, and I presume that Red Hat and SAP and others
>>>>>> do
>>>>>> the same, but the OpenJDK project itself does not.
>>>>>>
>>>>>> With that said, platforms which were previously supported by Oracle
>>>>>> (like
>>>>>> the one's you mentioned) tend to still work more-or-less well, but
>>>>>> they
>>>>>> receive no or little testing, and is prone to bit rot.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>> Surely you meant to say "receive no or little testing BY ORACLE, and
>>>>> ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>>>>>
>>>>> I haven't found a definitive list of supported OpenJDK platforms, but
>>>>> have an ad-hoc list of publicly available binaries:
>>>>> - Major linux distros are supporting x64 and aarch64 (arm64), and
>>>>> probably other platforms.
>>>>> - AdoptOpenJDK provides tested builds for most 64-bit platforms (x64,
>>>>> aarch64, ppc64, s390).
>>>>>       -https://adoptopenjdk.net/releases.html
>>>>> - Bellsoft provides support for 32-bit ARMv7.
>>>>>      -https://bell-sw.com/products.html
>>>>> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86
>>>>> and aarch64.
>>>>>      -https://www.azul.com/downloads/zulu/
>>>>>
>>>>> I'm sure there are several others I've missed - sorry!
>>>>>   - Derek
>>>>>
>>>>
>>>>
>>


From erik.joelsson at oracle.com  Tue Apr 10 16:54:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 09:54:11 -0700
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
 <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
 <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
Message-ID: <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>

I've found the problem. In JvmFeatures.gmk we have:

ifeq ($(call check-jvm-feature, zero), true)
 ? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP 
-DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
 ? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
 ? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
 ??? BUILD_LIBJVM_EXTRA_FILES := 
$(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
 ? endif
endif

The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the EXTRA_FILES 
argument to the BUILD_LIBJVM SetupNativeCompilation call. This used to 
work because there was no setting of that parameter in the actual call. 
In a recent change, that parameter is not set to something else, 
overriding the assignment above.

To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the 
EXTRA_FILES line in CompileJvm.gmk.

/Erik


On 2018-04-10 04:58, John Paul Adrian Glaubitz wrote:
> On 04/10/2018 01:37 PM, John Paul Adrian Glaubitz wrote:
>> @buildd-dev:
>>
>> I need to build memset_with_concurrent_readers_sparc.cpp for Zero on 
>> SPARC as
>> the Zero build now bails out with linker errors:
> Add the source file in question to EXTRA_FILES:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
> diff -r b3c09ab95c1a make/hotspot/lib/CompileGtest.gmk
> --- a/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 12:21:58 2018 +0200
> +++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:57:05 2018 +0300
> @@ -71,7 +71,8 @@
> ???? EXCLUDES := $(JVM_EXCLUDES), \
> ???? EXCLUDE_FILES := gtestLauncher.cpp, \
> ???? EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
> -??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
> +??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
> + 
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, 
> \
> ???? EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
> ???????? $(BUILD_LIBJVM_ALL_OBJS)), \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> @@ -109,7 +110,8 @@
> ???? NAME := gtestLauncher, \
> ???? TYPE := EXECUTABLE, \
> ???? OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
> -??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
> +??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
> + 
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, 
> \
> ???? OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> ???????? -I$(GTEST_FRAMEWORK_SRC)/include, \
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Causes the object files to be built. But for some reason, the linker 
> is not
> picking up those object files even though they are located in the object
> directories of gtest:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ find . -name 
> "memset_with_concurrent_readers_sparc.o"
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o 
>
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o 
>
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Adrian
>



From aleksei.voitylov at bell-sw.com  Tue Apr 10 07:23:15 2018
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 10 Apr 2018 10:23:15 +0300
Subject: Supported platforms
In-Reply-To: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
Message-ID: <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>

Hi David,

Speaking about the arm/ port, BellSoft has been releasing JCK-verified 
binaries (as provided under the OpenJDK license) from the arm/ port for 
the Raspberry Pi for JDK 9 [1] for a while and recently released one for 
JDK 10 [2], including OpenJFX and Minimal VM support. On Raspberry Pi 2 
(ARMv7) and Raspberry Pi 3 (ARMv8 chip running Raspbian) the binaries 
produced from this port are passing all the required testing, including 
the new features recently open-sourced by Oracle (such as AppCDS). As 
far as JDK 11 is concerned, we are keeping track of the changes, 
recently fixed a couple of build issues that slipped in [3, 4], are 
working on Minimal Value Types support and, from what I can tell, will 
need to look into JFR and Nest-Based Access Control. Please let us know 
if we missed anything and we need to prepare for some other new features 
for porting.

The intent is to keep the arm/ port in good shape and provide 
well-tested binaries for the Raspberry Pi.

I believed Oracle was aware about BellSoft producing binaries from this 
port [5], [6]. Based on twitter, it seems like at least some engineers 
at Redhat and SAP are aware about it. Let me know if there is anything 
else we need to do to spread the word about it with Oracle engineering. 
For now, Boris (cced) is the engineer at BellSoft working on supporting 
the arm/ port for the Raspberry Pi. Other than that, I really wonder 
what "stepping up to take ownership of a port" means when it's upstream, 
and there is some procedure we need to follow.

Thanks,

-Aleksei

[1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
[2] https://bell-sw.com/java-for-raspberry-pi.html
[3] https://bugs.openjdk.java.net/browse/JDK-8200628
[4] https://bugs.openjdk.java.net/browse/JDK-8198949
[5] https://twitter.com/java/status/981239157874941955
[6] https://twitter.com/DonaldOJDK/status/981874485979746304


> We are in a situation where previously "supported" platforms (by Oracle)
> are no longer supported as, AFAIK, no one has stepped up to take
> ownership of said platforms - which is a requirement for getting a new
> port accepted into mainline. Without such ownership the code may not
> only bit-rot, it may in time be stripped out completely. Any interested
> parties would then need to look at (re)forming a port project for that
> platform to keep it going in OpenJDK (or of course they are free to take
> it elsewhere).
>
> Cheers,
> David
>

On 09/04/2018 18:35, White, Derek wrote:
> Hi Magnus,
>
>> -----Original Message-----
>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> To: Simon Nash <simon at cjnash.com>, bren at juanantonio.info
>> Cc: build-dev at openjdk.java.net, hotspot-dev developers
>> 	<hotspot-dev at openjdk.java.net>
>> Subject: Re: Supported platforms
>> Message-ID: <4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Simon,
>>
>> On 2018-04-08 16:30, Simon Nash wrote:
>>> On 05/04/2018 02:26, bren at juanantonio.info wrote:
>>>> Many thanks with the link about the Platforms supported:
>>>>
>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
>>>> config-4417031.html
>>>>
>>> This appears to be a list of the platforms that are supported
>>> (certified) by
>>> Oracle.? Where can I find the list of platforms that are supported by
>>> OpenJDK?? For example, what about the following platforms that don't
>>> appear on the Oracle list:
>>>
>>> Windows x86
>>> Linux x86
>>> aarch32 (ARMv7 32-bit)
>>> aarch64 (ARMv8 64-bit)
>>>
>>> Are all these supported for OpenJDK 9, 10 and 11?
>> There is actually no such thing as a "supported OpenJDK platform". While I
>> hope things may change in the future, OpenJDK as an organization does not
>> publicize any list of "supported" platforms. Oracle publishes a list of
>> platforms they support, and I presume that Red Hat and SAP and others do
>> the same, but the OpenJDK project itself does not.
>>
>> With that said, platforms which were previously supported by Oracle (like
>> the one's you mentioned) tend to still work more-or-less well, but they
>> receive no or little testing, and is prone to bit rot.
>>
>> /Magnus
> Surely you meant to say "receive no or little testing BY ORACLE, and ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>
> I haven't found a definitive list of supported OpenJDK platforms, but have an ad-hoc list of publicly available binaries:
> - Major linux distros are supporting x64 and aarch64 (arm64), and probably other platforms.
> - AdoptOpenJDK provides tested builds for most 64-bit platforms (x64, aarch64, ppc64, s390).
>       - https://adoptopenjdk.net/releases.html
> - Bellsoft provides support for 32-bit ARMv7.
>      - https://bell-sw.com/products.html
> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 and aarch64.
>      - https://www.azul.com/downloads/zulu/
>
> I'm sure there are several others I've missed - sorry!
>   - Derek



From aleksei.voitylov at bell-sw.com  Tue Apr 10 09:17:52 2018
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 10 Apr 2018 12:17:52 +0300
Subject: Supported platforms
In-Reply-To: <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
 <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>
Message-ID: <dbd6f182-3f5d-cfb0-4e52-f7e31ed86f3f@bell-sw.com>

David,

see inline:


On 10/04/2018 11:00, David Holmes wrote:
> Hi Aleksei,
>
> This is all news to me. Good news, but unexpected. As far as I was 
> aware the 32-bit ARM port was dying a slow death and would eventually 
> get removed. 64-bit ARM is of course very much alive and well under 
> the Aarch64 porters - though I'm unclear if you are using that code 
> for ARMv8 or the Oracle contributed code that used to be closed?
You are welcome :) We are doing everything possible to keep it running, 
so I don't see any reason within OpenJDK to it being removed. Regarding 
ARMv8 port, we are working with Cavium, Redhat, and Linaro on supporting 
the AARCH64 port.
>
> I'm also unclear whether you are pushing changes back up to OpenJDK 
> for these platforms, or maintaining them locally? I haven't noticed 
> anything (other than build tweaks) and am curious about the release of 
> a Minimal VM for JDK 10 given the Minimal VM effectively died along 
> with the stand-alone Client VM.
We push everything upstream. I'm not sure why you believe Minimal VM and 
Client VM died in OpenJDK 10. From what I remember, there was some 
decision related to Client VM for Oracle binaries, but support for C1 
and Minimal VM was not removed from OpenJDK codebase. This is what I get 
with BellSoft Liberica binaries built from OpenJDK on Raspberry Pi:

> pi at rpi-3:~ $ java -version
> openjdk version "10-BellSoft" 2018-03-20
> OpenJDK Runtime Environment (build 10-BellSoft+0)
> OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
> pi at rpi-3:~ $ java -minimal -version
> openjdk version "10-BellSoft" 2018-03-20
> OpenJDK Runtime Environment (build 10-BellSoft+0)
> OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
> pi at rpi-3:~ $ java -client -version
> openjdk version "10-BellSoft" 2018-03-20
> OpenJDK Runtime Environment (build 10-BellSoft+0)
> OpenJDK Client VM (build 10-BellSoft+0, mixed mode)

> pi at rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
> ???? bool C1OptimizeVirtualCallProfiling?????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1ProfileBranches??????????????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1ProfileCalls?????????????????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1ProfileCheckcasts????????????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1ProfileInlinedCalls??????????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1ProfileVirtualCalls??????????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool C1UpdateMethodData?????????????????????? = 
> false???????????????????????????????? {C1 product} {default}
> ???? bool InlineSynchronizedMethods??????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? bool LIRFillDelaySlots??????????????????????? = 
> false????????????????????????????? {C1 pd product} {default}
> ???? bool TimeLinearScan?????????????????????????? = 
> false???????????????????????????????? {C1 product} {default}
> ???? bool UseLoopInvariantCodeMotion?????????????? = 
> true????????????????????????????????? {C1 product} {default}
> ???? intx ValueMapInitialSize????????????????????? = 
> 11??????????????????????????????????? {C1 product} {default}
> ???? intx ValueMapMaxLoopSize????????????????????? = 
> 8???????????????????????????????????? {C1 product} {default}

Minimal VM and Client VM include C1, and Server VM includes C1 and C2. 
All (Client VM, Server VM, Minimal VM) were tested and work as expected.

>
> For JDK11 you will need to do some work for Condy (if not already 
> done) as well as JFR and Nest-based Access Control (which you can see 
> in the nestmates branch of the Valhalla repo), as you mention below. 
> Not sure what else may be needed. There's been a lot of code 
> refactoring and include file changes that have impact on platform 
> specific code as well.
Thanks for the heads-up!

-Aleksei
>
> Cheers,
> David
>
> On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
>> Hi David,
>>
>> Speaking about the arm/ port, BellSoft has been releasing 
>> JCK-verified binaries (as provided under the OpenJDK license) from 
>> the arm/ port for the Raspberry Pi for JDK 9 [1] for a while and 
>> recently released one for JDK 10 [2], including OpenJFX and Minimal 
>> VM support. On Raspberry Pi 2 (ARMv7) and Raspberry Pi 3 (ARMv8 chip 
>> running Raspbian) the binaries produced from this port are passing 
>> all the required testing, including the new features recently 
>> open-sourced by Oracle (such as AppCDS). As far as JDK 11 is 
>> concerned, we are keeping track of the changes, recently fixed a 
>> couple of build issues that slipped in [3, 4], are working on Minimal 
>> Value Types support and, from what I can tell, will need to look into 
>> JFR and Nest-Based Access Control. Please let us know if we missed 
>> anything and we need to prepare for some other new features for porting.
>>
>> The intent is to keep the arm/ port in good shape and provide 
>> well-tested binaries for the Raspberry Pi.
>>
>> I believed Oracle was aware about BellSoft producing binaries from 
>> this port [5], [6]. Based on twitter, it seems like at least some 
>> engineers at Redhat and SAP are aware about it. Let me know if there 
>> is anything else we need to do to spread the word about it with 
>> Oracle engineering. For now, Boris (cced) is the engineer at BellSoft 
>> working on supporting the arm/ port for the Raspberry Pi. Other than 
>> that, I really wonder what "stepping up to take ownership of a port" 
>> means when it's upstream, and there is some procedure we need to follow.
>>
>> Thanks,
>>
>> -Aleksei
>>
>> [1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
>> [2] https://bell-sw.com/java-for-raspberry-pi.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8200628
>> [4] https://bugs.openjdk.java.net/browse/JDK-8198949
>> [5] https://twitter.com/java/status/981239157874941955
>> [6] https://twitter.com/DonaldOJDK/status/981874485979746304
>>
>>
>>> We are in a situation where previously "supported" platforms (by 
>>> Oracle)
>>> are no longer supported as, AFAIK, no one has stepped up to take
>>> ownership of said platforms - which is a requirement for getting a new
>>> port accepted into mainline. Without such ownership the code may not
>>> only bit-rot, it may in time be stripped out completely. Any interested
>>> parties would then need to look at (re)forming a port project for that
>>> platform to keep it going in OpenJDK (or of course they are free to 
>>> take
>>> it elsewhere).
>>>
>>> Cheers,
>>> David
>>>
>>
>> On 09/04/2018 18:35, White, Derek wrote:
>>> Hi Magnus,
>>>
>>>> -----Original Message-----
>>>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>>>> From: Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>
>>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>>> ????<hotspot-dev at openjdk.java.net>
>>>> Subject: Re: Supported platforms
>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>
>>>> Simon,
>>>>
>>>> On 2018-04-08 16:30, Simon Nash wrote:
>>>>> On 05/04/2018 02:26,bren at juanantonio.info? wrote:
>>>>>> Many thanks with the link about the Platforms supported:
>>>>>>
>>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
>>>>>> config-4417031.html
>>>>>>
>>>>> This appears to be a list of the platforms that are supported
>>>>> (certified) by
>>>>> Oracle.? Where can I find the list of platforms that are supported by
>>>>> OpenJDK?? For example, what about the following platforms that don't
>>>>> appear on the Oracle list:
>>>>>
>>>>> Windows x86
>>>>> Linux x86
>>>>> aarch32 (ARMv7 32-bit)
>>>>> aarch64 (ARMv8 64-bit)
>>>>>
>>>>> Are all these supported for OpenJDK 9, 10 and 11?
>>>> There is actually no such thing as a "supported OpenJDK platform". 
>>>> While I
>>>> hope things may change in the future, OpenJDK as an organization 
>>>> does not
>>>> publicize any list of "supported" platforms. Oracle publishes a 
>>>> list of
>>>> platforms they support, and I presume that Red Hat and SAP and 
>>>> others do
>>>> the same, but the OpenJDK project itself does not.
>>>>
>>>> With that said, platforms which were previously supported by Oracle 
>>>> (like
>>>> the one's you mentioned) tend to still work more-or-less well, but 
>>>> they
>>>> receive no or little testing, and is prone to bit rot.
>>>>
>>>> /Magnus
>>> Surely you meant to say "receive no or little testing BY ORACLE, and 
>>> ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>>>
>>> I haven't found a definitive list of supported OpenJDK platforms, 
>>> but have an ad-hoc list of publicly available binaries:
>>> - Major linux distros are supporting x64 and aarch64 (arm64), and 
>>> probably other platforms.
>>> - AdoptOpenJDK provides tested builds for most 64-bit platforms 
>>> (x64, aarch64, ppc64, s390).
>>> ????? -https://adoptopenjdk.net/releases.html
>>> - Bellsoft provides support for 32-bit ARMv7.
>>> ???? -https://bell-sw.com/products.html
>>> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 
>>> and aarch64.
>>> ???? -https://www.azul.com/downloads/zulu/
>>>
>>> I'm sure there are several others I've missed - sorry!
>>> ? - Derek
>>



From aleksei.voitylov at bell-sw.com  Tue Apr 10 09:48:00 2018
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 10 Apr 2018 12:48:00 +0300
Subject: Supported platforms
In-Reply-To: <f2a71174-4a64-9767-607a-287299d39831@oracle.com>
References: <BL0PR07MB3890F05345F6CA709DA05EA084BF0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <9a3c9565-9652-43a5-fac9-dfdc53547ebd@bell-sw.com>
 <0c7fae30-1dc9-2a78-6daf-99a8c3001bc6@oracle.com>
 <dbd6f182-3f5d-cfb0-4e52-f7e31ed86f3f@bell-sw.com>
 <f2a71174-4a64-9767-607a-287299d39831@oracle.com>
Message-ID: <74738daf-2b5b-de84-a4dc-55118b168520@bell-sw.com>

David,

> Sorry I was mis-remembering. Of course C1 and Minimal still exist in 
> the 32-bit code. Though I would be concerned that with a focus on 
> 64-bit it will be easy for engineers to overlook things that should be 
> inside one of the INCLUDE_XXX guards. (Particularly as we don't do any 
> 32-bit builds and for the most part don't even have the capability to 
> perform them.) 
It seems like BellSoft is not alone in building 32-bit code so we hope 
the community will notice if something gets broken. That said, it does 
not seem like too big of a deal to have, say, Linux x86 32 bit builds 
running in any build farm. This should catch most of the INCLUDE_XXX 
types of errors.

-Aleksei


On 10/04/2018 12:24, David Holmes wrote:
> On 10/04/2018 7:17 PM, Aleksei Voitylov wrote:
>> David,
>>
>> see inline:
>>
>>
>> On 10/04/2018 11:00, David Holmes wrote:
>>> Hi Aleksei,
>>>
>>> This is all news to me. Good news, but unexpected. As far as I was 
>>> aware the 32-bit ARM port was dying a slow death and would 
>>> eventually get removed. 64-bit ARM is of course very much alive and 
>>> well under the Aarch64 porters - though I'm unclear if you are using 
>>> that code for ARMv8 or the Oracle contributed code that used to be 
>>> closed?
>> You are welcome :) We are doing everything possible to keep it 
>> running, so I don't see any reason within OpenJDK to it being 
>> removed. Regarding ARMv8 port, we are working with Cavium, Redhat, 
>> and Linaro on supporting the AARCH64 port.
>>>
>>> I'm also unclear whether you are pushing changes back up to OpenJDK 
>>> for these platforms, or maintaining them locally? I haven't noticed 
>>> anything (other than build tweaks) and am curious about the release 
>>> of a Minimal VM for JDK 10 given the Minimal VM effectively died 
>>> along with the stand-alone Client VM.
>> We push everything upstream.
>
> I don't recall seeing anything related to 32-bit ARM, but perhaps it's 
> all in areas I don't see (like compiler and gc).
>
>> I'm not sure why you believe Minimal VM and Client VM died in OpenJDK 
>> 10. From what I remember, there was some decision related to Client 
>> VM for Oracle binaries, but support for C1 and Minimal VM was not 
>> removed from OpenJDK codebase. This is what I get with BellSoft 
>> Liberica binaries built from OpenJDK on Raspberry Pi:
>
> Sorry I was mis-remembering. Of course C1 and Minimal still exist in 
> the 32-bit code. Though I would be concerned that with a focus on 
> 64-bit it will be easy for engineers to overlook things that should be 
> inside one of the INCLUDE_XXX guards. (Particularly as we don't do any 
> 32-bit builds and for the most part don't even have the capability to 
> perform them.)
>
> Cheers,
> David
>
>>> pi at rpi-3:~ $ java -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
>>> pi at rpi-3:~ $ java -minimal -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
>>> pi at rpi-3:~ $ java -client -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Client VM (build 10-BellSoft+0, mixed mode)
>>
>>> pi at rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
>>> ???? bool C1OptimizeVirtualCallProfiling?????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1ProfileBranches??????????????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1ProfileCalls?????????????????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1ProfileCheckcasts????????????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1ProfileInlinedCalls??????????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1ProfileVirtualCalls??????????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool C1UpdateMethodData?????????????????????? = 
>>> false???????????????????????????????? {C1 product} {default}
>>> ???? bool InlineSynchronizedMethods??????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? bool LIRFillDelaySlots??????????????????????? = 
>>> false????????????????????????????? {C1 pd product} {default}
>>> ???? bool TimeLinearScan?????????????????????????? = 
>>> false???????????????????????????????? {C1 product} {default}
>>> ???? bool UseLoopInvariantCodeMotion?????????????? = 
>>> true????????????????????????????????? {C1 product} {default}
>>> ???? intx ValueMapInitialSize????????????????????? = 
>>> 11??????????????????????????????????? {C1 product} {default}
>>> ???? intx ValueMapMaxLoopSize????????????????????? = 
>>> 8???????????????????????????????????? {C1 product} {default}
>>
>> Minimal VM and Client VM include C1, and Server VM includes C1 and 
>> C2. All (Client VM, Server VM, Minimal VM) were tested and work as 
>> expected.
>>
>>>
>>> For JDK11 you will need to do some work for Condy (if not already 
>>> done) as well as JFR and Nest-based Access Control (which you can 
>>> see in the nestmates branch of the Valhalla repo), as you mention 
>>> below. Not sure what else may be needed. There's been a lot of code 
>>> refactoring and include file changes that have impact on platform 
>>> specific code as well.
>> Thanks for the heads-up!
>>
>> -Aleksei
>>>
>>> Cheers,
>>> David
>>>
>>> On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
>>>> Hi David,
>>>>
>>>> Speaking about the arm/ port, BellSoft has been releasing 
>>>> JCK-verified binaries (as provided under the OpenJDK license) from 
>>>> the arm/ port for the Raspberry Pi for JDK 9 [1] for a while and 
>>>> recently released one for JDK 10 [2], including OpenJFX and Minimal 
>>>> VM support. On Raspberry Pi 2 (ARMv7) and Raspberry Pi 3 (ARMv8 
>>>> chip running Raspbian) the binaries produced from this port are 
>>>> passing all the required testing, including the new features 
>>>> recently open-sourced by Oracle (such as AppCDS). As far as JDK 11 
>>>> is concerned, we are keeping track of the changes, recently fixed a 
>>>> couple of build issues that slipped in [3, 4], are working on 
>>>> Minimal Value Types support and, from what I can tell, will need to 
>>>> look into JFR and Nest-Based Access Control. Please let us know if 
>>>> we missed anything and we need to prepare for some other new 
>>>> features for porting.
>>>>
>>>> The intent is to keep the arm/ port in good shape and provide 
>>>> well-tested binaries for the Raspberry Pi.
>>>>
>>>> I believed Oracle was aware about BellSoft producing binaries from 
>>>> this port [5], [6]. Based on twitter, it seems like at least some 
>>>> engineers at Redhat and SAP are aware about it. Let me know if 
>>>> there is anything else we need to do to spread the word about it 
>>>> with Oracle engineering. For now, Boris (cced) is the engineer at 
>>>> BellSoft working on supporting the arm/ port for the Raspberry Pi. 
>>>> Other than that, I really wonder what "stepping up to take 
>>>> ownership of a port" means when it's upstream, and there is some 
>>>> procedure we need to follow.
>>>>
>>>> Thanks,
>>>>
>>>> -Aleksei
>>>>
>>>> [1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
>>>> [2] https://bell-sw.com/java-for-raspberry-pi.html
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8200628
>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8198949
>>>> [5] https://twitter.com/java/status/981239157874941955
>>>> [6] https://twitter.com/DonaldOJDK/status/981874485979746304
>>>>
>>>>
>>>>> We are in a situation where previously "supported" platforms (by 
>>>>> Oracle)
>>>>> are no longer supported as, AFAIK, no one has stepped up to take
>>>>> ownership of said platforms - which is a requirement for getting a 
>>>>> new
>>>>> port accepted into mainline. Without such ownership the code may not
>>>>> only bit-rot, it may in time be stripped out completely. Any 
>>>>> interested
>>>>> parties would then need to look at (re)forming a port project for 
>>>>> that
>>>>> platform to keep it going in OpenJDK (or of course they are free 
>>>>> to take
>>>>> it elsewhere).
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>
>>>> On 09/04/2018 18:35, White, Derek wrote:
>>>>> Hi Magnus,
>>>>>
>>>>>> -----Original Message-----
>>>>>> Date: Mon, 9 Apr 2018 09:55:09 +0200
>>>>>> From: Magnus Ihse Bursie<magnus.ihse.bursie at oracle.com>
>>>>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>>>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>>>>> ????<hotspot-dev at openjdk.java.net>
>>>>>> Subject: Re: Supported platforms
>>>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at oracle.com>
>>>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>>>
>>>>>> Simon,
>>>>>>
>>>>>> On 2018-04-08 16:30, Simon Nash wrote:
>>>>>>> On 05/04/2018 02:26,bren at juanantonio.info? wrote:
>>>>>>>> Many thanks with the link about the Platforms supported:
>>>>>>>>
>>>>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert 
>>>>>>
>>>>>>>> config-4417031.html
>>>>>>>>
>>>>>>> This appears to be a list of the platforms that are supported
>>>>>>> (certified) by
>>>>>>> Oracle.? Where can I find the list of platforms that are 
>>>>>>> supported by
>>>>>>> OpenJDK?? For example, what about the following platforms that 
>>>>>>> don't
>>>>>>> appear on the Oracle list:
>>>>>>>
>>>>>>> Windows x86
>>>>>>> Linux x86
>>>>>>> aarch32 (ARMv7 32-bit)
>>>>>>> aarch64 (ARMv8 64-bit)
>>>>>>>
>>>>>>> Are all these supported for OpenJDK 9, 10 and 11?
>>>>>> There is actually no such thing as a "supported OpenJDK 
>>>>>> platform". While I
>>>>>> hope things may change in the future, OpenJDK as an organization 
>>>>>> does not
>>>>>> publicize any list of "supported" platforms. Oracle publishes a 
>>>>>> list of
>>>>>> platforms they support, and I presume that Red Hat and SAP and 
>>>>>> others do
>>>>>> the same, but the OpenJDK project itself does not.
>>>>>>
>>>>>> With that said, platforms which were previously supported by 
>>>>>> Oracle (like
>>>>>> the one's you mentioned) tend to still work more-or-less well, 
>>>>>> but they
>>>>>> receive no or little testing, and is prone to bit rot.
>>>>>>
>>>>>> /Magnus
>>>>> Surely you meant to say "receive no or little testing BY ORACLE, 
>>>>> and ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."
>>>>>
>>>>> I haven't found a definitive list of supported OpenJDK platforms, 
>>>>> but have an ad-hoc list of publicly available binaries:
>>>>> - Major linux distros are supporting x64 and aarch64 (arm64), and 
>>>>> probably other platforms.
>>>>> - AdoptOpenJDK provides tested builds for most 64-bit platforms 
>>>>> (x64, aarch64, ppc64, s390).
>>>>> ????? -https://adoptopenjdk.net/releases.html
>>>>> - Bellsoft provides support for 32-bit ARMv7.
>>>>> ???? -https://bell-sw.com/products.html
>>>>> - Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit 
>>>>> x86 and aarch64.
>>>>> ???? -https://www.azul.com/downloads/zulu/
>>>>>
>>>>> I'm sure there are several others I've missed - sorry!
>>>>> ? - Derek
>>>>
>>



From glaubitz at physik.fu-berlin.de  Tue Apr 10 17:50:40 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 19:50:40 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
 <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
 <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
 <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
Message-ID: <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>

Hi Erik!

On 04/10/2018 06:54 PM, Erik Joelsson wrote:
> I've found the problem. In JvmFeatures.gmk we have:
> 
> ifeq ($(call check-jvm-feature, zero), true)
>  ? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
>  ? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
>  ? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
>  ??? BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
>  ? endif
> endif
> 
> The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the EXTRA_FILES argument to the BUILD_LIBJVM SetupNativeCompilation call. This used to work because there was no setting of that parameter in the actual call. In a recent change, that parameter is not set to something else, overriding the assignment above.

Aha! Do you happen to know which change was responsible for that? Then I can
adjust the bug summary accordingly.

> To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the EXTRA_FILES line in CompileJvm.gmk.

Indeed, this fixes it! Thanks so much, I was already about to give up ;).

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Tue Apr 10 18:04:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 11:04:39 -0700
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
 <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
 <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
 <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
 <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
Message-ID: <3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>



On 2018-04-10 10:50, John Paul Adrian Glaubitz wrote:
> Hi Erik!
>
> On 04/10/2018 06:54 PM, Erik Joelsson wrote:
>> I've found the problem. In JvmFeatures.gmk we have:
>>
>> ifeq ($(call check-jvm-feature, zero), true)
>> ?? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP 
>> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
>> ?? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
>> ?? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
>> ???? BUILD_LIBJVM_EXTRA_FILES := 
>> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
>> ?? endif
>> endif
>>
>> The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the 
>> EXTRA_FILES argument to the BUILD_LIBJVM SetupNativeCompilation call. 
>> This used to work because there was no setting of that parameter in 
>> the actual call. In a recent change, that parameter is not set to 
>> something else, overriding the assignment above.
>
> Aha! Do you happen to know which change was responsible for that? Then 
> I can
> adjust the bug summary accordingly.
>
"JDK-8201236 Straighten out dtrace build logic"
>> To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the 
>> EXTRA_FILES line in CompileJvm.gmk.
>
> Indeed, this fixes it! Thanks so much, I was already about to give up ;).
>
We should have been explicit with that parameter in the first place, 
then Magnus would not have missed it. Glad I could help.

/Erik
> Adrian
>



From glaubitz at physik.fu-berlin.de  Tue Apr 10 18:14:07 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 20:14:07 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
 <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
 <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
 <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
 <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
 <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
 <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
 <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
 <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
 <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
 <3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>
Message-ID: <b27394c9-465c-b074-c1ca-b15b76ce7824@physik.fu-berlin.de>

On 04/10/2018 08:04 PM, Erik Joelsson wrote:
> "JDK-8201236 Straighten out dtrace build logic"

Aye, changeset is coming up ;).

>> Indeed, this fixes it! Thanks so much, I was already about to give up ;).
>>
> We should have been explicit with that parameter in the first place, then Magnus would not have missed it. Glad I could help.

After that, I'll try to tackle the server build on linux-sparc again.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From glaubitz at physik.fu-berlin.de  Tue Apr 10 18:22:41 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 20:22:41 +0200
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
Message-ID: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>

Hi!

Please review this minor change which fixes the Zero build on linux-sparc
which got broken after "JDK-8201236 Straighten out dtrace build logic".

The change affects the Zero build on linux-sparc only since SPARC has its
own implementation of memset_with_concurrent_readers() in memset_with_\
concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).

Thanks,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Tue Apr 10 18:32:57 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 11:32:57 -0700
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
Message-ID: <ccb08f23-2126-4cee-3d9f-7895f9d1c1a7@oracle.com>

Looks good.

/Erik


On 2018-04-10 11:22, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Please review this minor change which fixes the Zero build on linux-sparc
> which got broken after "JDK-8201236 Straighten out dtrace build logic".
>
> The change affects the Zero build on linux-sparc only since SPARC has its
> own implementation of memset_with_concurrent_readers() in memset_with_\
> concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
> by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).
>
> Thanks,
> Adrian
>
>> [1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/
>



From gary.adams at oracle.com  Tue Apr 10 18:51:38 2018
From: gary.adams at oracle.com (Gary Adams)
Date: Tue, 10 Apr 2018 14:51:38 -0400
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <ccb08f23-2126-4cee-3d9f-7895f9d1c1a7@oracle.com>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
 <ccb08f23-2126-4cee-3d9f-7895f9d1c1a7@oracle.com>
Message-ID: <5ACD07BA.4020907@oracle.com>

Is any update needed for EXTRA_OBJECT_FILES?

On 4/10/18, 2:32 PM, Erik Joelsson wrote:
> Looks good.
>
> /Erik
>
>
> On 2018-04-10 11:22, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> Please review this minor change which fixes the Zero build on 
>> linux-sparc
>> which got broken after "JDK-8201236 Straighten out dtrace build logic".
>>
>> The change affects the Zero build on linux-sparc only since SPARC has 
>> its
>> own implementation of memset_with_concurrent_readers() in memset_with_\
>> concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
>> by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).
>>
>> Thanks,
>> Adrian
>>
>>> [1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/
>>
>



From glaubitz at physik.fu-berlin.de  Tue Apr 10 18:55:09 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 20:55:09 +0200
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <5ACD07BA.4020907@oracle.com>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
 <ccb08f23-2126-4cee-3d9f-7895f9d1c1a7@oracle.com>
 <5ACD07BA.4020907@oracle.com>
Message-ID: <d43b0d0f-73dc-9e6c-a6ee-cb9ba561f8f9@physik.fu-berlin.de>

On 04/10/2018 08:51 PM, Gary Adams wrote:
> Is any update needed for EXTRA_OBJECT_FILES?

No. I just made the single change Erik suggested and it builds fine for me.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From alexey.ivanov at oracle.com  Tue Apr 10 19:33:56 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 10 Apr 2018 20:33:56 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <99420e261ef347578bb8099a48d6b7ec@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
Message-ID: <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>

Hi Matthias,

On 10/04/2018 11:14, Baesken, Matthias wrote:
> Hello,  I  had to  do another small adjustment  to make jimage.hpp/cpp match.    Please review :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/

JIMAGE_FindResource doesn't have JNICALL modifier now, does it?

I've successfully built 32 bit Windows with your patch.


Please remove JNIEXPORT from main():
src/java.base/share/native/launcher/main.c
src/jdk.pack/share/native/unpack200/main.cpp

> With the latest webrev I could finally    build    jdk/jdk   successfully on both  win32bit   and win64 bit .
>
>
>
> Thanks again  to Alexey  to provide  the   incorporated patch .

You can reference both yourself and me as
Contributed-by: mbaesken, aivanov
when pushing the changeset if you don't mind.


Regards,
Alexey

>
>
> Best regards, Matthias
>
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Montag, 9. April 2018 17:14
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>> Hi Matthias,
>>
>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the  explanations
>> .
>>> I created  a second  webrev :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>
>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>> Yes, that's fine with me.
>> There could be only one author ;)
>>
>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c    and
>> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
>> issues after mapfile removal for exes
>>
>> I'd rather remove both JNIEXPORT and JNICALL from main().
>> It wasn't exported, and it shouldn't be.
>>
>> Regards,
>> Alexey
>>
>>> Best regards , Matthias


From magnus.ihse.bursie at oracle.com  Tue Apr 10 20:01:43 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 22:01:43 +0200
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
Message-ID: <0034a070-4fef-7909-e3bc-25b70251a737@oracle.com>

On 2018-04-10 20:22, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Please review this minor change which fixes the Zero build on linux-sparc
> which got broken after "JDK-8201236 Straighten out dtrace build logic".
While I agree that the fix solves your problems, maybe you could delay 
pushing this for a while?

The regression you noted was not caused by JDK-8201236, but by 
JDK-8198862 "Stop doing funky compilation stuff for dtrace". In fact, 
JDK-8201236 (which is pushed to jdk/jdk but not yet integrated into 
jdk/hs, apparently) will once again remove EXTRA_FILES from the 
SetupNativeCompilation, making zero work again.

So if you just wait until JDK-8201236 moves into jdk/hs, this will be 
fixed. Otherwise, you're just creating a merge conflict for the 
integrator. :(

/Magnus
> The change affects the Zero build on linux-sparc only since SPARC has its
> own implementation of memset_with_concurrent_readers() in memset_with_\
> concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
> by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).
>
> Thanks,
> Adrian
>
>> [1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/
>



From glaubitz at physik.fu-berlin.de  Tue Apr 10 20:05:06 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 22:05:06 +0200
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <0034a070-4fef-7909-e3bc-25b70251a737@oracle.com>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
 <0034a070-4fef-7909-e3bc-25b70251a737@oracle.com>
Message-ID: <28c87914-e78f-73c3-b9a6-3686e83eaa2d@physik.fu-berlin.de>

Hi Magnus!

On 04/10/2018 10:01 PM, Magnus Ihse Bursie wrote:
> The regression you noted was not caused by JDK-8201236, but by JDK-8198862 "Stop doing funky compilation stuff for dtrace". In fact, JDK-8201236 (which is pushed to jdk/jdk but not yet integrated into jdk/hs, apparently) will once again remove EXTRA_FILES from the SetupNativeCompilation, making zero work again.

Ok, so I will update the bug report title accordingly.

> So if you just wait until JDK-8201236 moves into jdk/hs, this will be fixed. Otherwise, you're just creating a merge conflict for the integrator. :(

Ah, even better. I don't mind waiting then and in the meantime continue
investigating on the other SPARC stuff.

Thanks,
Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From magnus.ihse.bursie at oracle.com  Tue Apr 10 20:27:07 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 22:27:07 +0200
Subject: slowproduct build
In-Reply-To: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
Message-ID: <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>

On 2018-04-10 02:00, Ioi Lam wrote:
> Sometimes I want to debug the product build (I can't bother with 
> turning off all the trueInDebug options in the hotspot globals.hpp). 
> The only way that I have found to do this is:
>
> ??? configure --with-native-debug-symbols=internal
> ??? mv spec.gmk spec.gmk.old
> ??? cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>
> Is there (or should there be) a more elegant way to do it, like 
> "configure --with-debug-level=slowproduct" :-)
I'm not entirely sure of what you want to achieve.

As I interepret your snippet above, you want no optimization and 
internal debug symbols..? How is that debugging a "product" build?

/Magnus

>
> Thanks
> - Ioi
>



From thomas.stuefe at gmail.com  Tue Apr 10 20:47:35 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 10 Apr 2018 22:47:35 +0200
Subject: slowproduct build
In-Reply-To: <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
Message-ID: <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>

If I understand Ioi correctly, he wants a build with PRODUCT and !ASSERT
but with debug symbols and no optimizations? So, no assertions and all
switches with product defaults?

I can see that this could make sense in certain scenarios.

..Thomas

On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2018-04-10 02:00, Ioi Lam wrote:
>
>> Sometimes I want to debug the product build (I can't bother with turning
>> off all the trueInDebug options in the hotspot globals.hpp). The only way
>> that I have found to do this is:
>>
>>     configure --with-native-debug-symbols=internal
>>     mv spec.gmk spec.gmk.old
>>     cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>>
>> Is there (or should there be) a more elegant way to do it, like
>> "configure --with-debug-level=slowproduct" :-)
>>
> I'm not entirely sure of what you want to achieve.
>
> As I interepret your snippet above, you want no optimization and internal
> debug symbols..? How is that debugging a "product" build?
>
> /Magnus
>
>
>> Thanks
>> - Ioi
>>
>>
>


From magnus.ihse.bursie at oracle.com  Tue Apr 10 20:54:56 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 22:54:56 +0200
Subject: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be
 turned off
Message-ID: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>

 From the bug report:

"The compile errors you get from HotSpot are quite large, and usually 
don't get entirely printed in PrintFailureReports. This has the effect 
that the goto mode to find the compilation error is to scroll past 
PrintFailureReports to get to the complete error message.

It would be nice if there was a way to turn off this feature from the 
command line."

I've solved this by adding a new LOG option, "report", which takes an 
argument: "report=default", "report=none" or "report=all". As usual, 
this can be combined with other LOG options, e.g. "LOG=info,report=all".

The "default" value is what it always been, giving you the first 
screenful of lines of each failure. "none" is what Stefan requested, and 
"all" means that there is no truncating, so in a sense, it's another way 
of giving Stefan what he wants. :-)

To make this usable in practice, I also implemented a feature I've been 
thinking about a long time, but never gotten around to. And that is to 
be able to set a default value for LOG in configure, similar to how we 
can set default values for JOBS or the default make target.

The new flag is "--with-log=<LOG value>", e.g. 
"--with-log=info,report=none". If a LOG= value is given on the command 
line, it overrides the default value provided to configure.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201320
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8201320-allow-disabling-of-exit-reports/webrev.01


/Magnus



From magnus.ihse.bursie at oracle.com  Tue Apr 10 20:57:30 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 22:57:30 +0200
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <1523359536.4542.2.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
Message-ID: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com>

On 2018-04-10 13:25, Severin Gehwolf wrote:
> Hi Erik,
>
> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> I'm ok with this solution for now.
> Thanks for the review!
>
>> Could you please reduce the indentation on line 652. In the build system
>> we like 4 spaces for continuation indent [1]
> Done. New webrev at:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
It's not nice, but there's no other way to do it right now. Approved.

(I'm working on getting to the point were I can address this in a better 
way.)

/Magnus
>
> Could someone from awt-dev have a look at this too? Thanks!
>
> Cheers,
> Severin
>
>> /Erik
>>
>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>
>> On 2018-04-09 06:39, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review this build fix for libfontmanager.so. The
>>> issue for us is that with some LDFLAGS the build breaks as described in
>>> bug JDK-8196218. However, we cannot link to a providing library at
>>> build-time since we don't know which one it should be: libawt_headless
>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters
>>> out relevant linker flags when libfontmanager is being built. More
>>> details are in the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
>>>
>>> Testing: I've run this through submit[1] and got the following results.
>>> SwingSet2 works fine for me on F27. I'm currently running some more
>>> tests on RHEL 7.
>>>
>>> ---------------------
>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
>>>
>>> 0 Failed Tests
>>>
>>> Mach5 Tasks Results Summary
>>>
>>> NA: 0
>>> UNABLE_TO_RUN: 0
>>> EXECUTED_WITH_FAILURE: 0
>>> KILLED: 0
>>> PASSED: 82
>>> FAILED: 1
>>> Test
>>>
>>> 1 Failed
>>>
>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
>>> return value: 10
>>> --------------------
>>>
>>> Not sure what this test failure means. Could somebody at Oracle shed
>>> some light on this?
>>>
>>> Thanks,
>>> Severin
>>



From ioi.lam at oracle.com  Tue Apr 10 21:08:57 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 10 Apr 2018 14:08:57 -0700
Subject: slowproduct build
In-Reply-To: <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
 <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
Message-ID: <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>

Yes that?s what I want.

Yesterday I was using gdb to step into the interpreter generation code to see what?s generated for a particular routine for MethodHandles. The debug build contains a LOT of runtime verification code in the generated code and I couldn?t figure out what?s happening. The product build just generates 10 instructions.

Thanks
Ioi

> On Apr 10, 2018, at 1:47 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> If I understand Ioi correctly, he wants a build with PRODUCT and !ASSERT but with debug symbols and no optimizations? So, no assertions and all switches with product defaults?
> 
> I can see that this could make sense in certain scenarios.
> 
> ..Thomas
> 
>> On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>>> On 2018-04-10 02:00, Ioi Lam wrote:
>>> Sometimes I want to debug the product build (I can't bother with turning off all the trueInDebug options in the hotspot globals.hpp). The only way that I have found to do this is:
>>> 
>>>     configure --with-native-debug-symbols=internal
>>>     mv spec.gmk spec.gmk.old
>>>     cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>>> 
>>> Is there (or should there be) a more elegant way to do it, like "configure --with-debug-level=slowproduct" :-)
>> I'm not entirely sure of what you want to achieve.
>> 
>> As I interepret your snippet above, you want no optimization and internal debug symbols..? How is that debugging a "product" build?
>> 
>> /Magnus
>> 
>>> 
>>> Thanks
>>> - Ioi
>>> 
>> 
> 


From stefan.karlsson at oracle.com  Tue Apr 10 21:11:22 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Apr 2018 23:11:22 +0200
Subject: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be
 turned off
In-Reply-To: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
References: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
Message-ID: <ff8af4f4-81b2-ea61-7e15-44a85493db7a@oracle.com>

Hi Magnus,

Thanks a lot for implementing this! I tested this with 
--with-log=info,report=none, and it's exactly what I want in my config 
script ;)

Thanks,
StefanK

On 2018-04-10 22:54, Magnus Ihse Bursie wrote:
> From the bug report:
>
> "The compile errors you get from HotSpot are quite large, and usually 
> don't get entirely printed in PrintFailureReports. This has the effect 
> that the goto mode to find the compilation error is to scroll past 
> PrintFailureReports to get to the complete error message.
>
> It would be nice if there was a way to turn off this feature from the 
> command line."
>
> I've solved this by adding a new LOG option, "report", which takes an 
> argument: "report=default", "report=none" or "report=all". As usual, 
> this can be combined with other LOG options, e.g. "LOG=info,report=all".
>
> The "default" value is what it always been, giving you the first 
> screenful of lines of each failure. "none" is what Stefan requested, 
> and "all" means that there is no truncating, so in a sense, it's 
> another way of giving Stefan what he wants. :-)
>
> To make this usable in practice, I also implemented a feature I've 
> been thinking about a long time, but never gotten around to. And that 
> is to be able to set a default value for LOG in configure, similar to 
> how we can set default values for JOBS or the default make target.
>
> The new flag is "--with-log=<LOG value>", e.g. 
> "--with-log=info,report=none". If a LOG= value is given on the command 
> line, it overrides the default value provided to configure.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201320
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201320-allow-disabling-of-exit-reports/webrev.01
>
>
> /Magnus
>



From magnus.ihse.bursie at oracle.com  Tue Apr 10 21:21:11 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 23:21:11 +0200
Subject: slowproduct build
In-Reply-To: <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
 <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
 <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>
Message-ID: <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>


On 2018-04-10 23:08, Ioi Lam wrote:
> Yes that?s what I want.
>
> Yesterday I was using gdb to step into the interpreter generation code 
> to see what?s generated for a particular routine for MethodHandles. 
> The debug build contains a LOT of runtime verification code in the 
> generated code and I couldn?t figure out what?s happening. The product 
> build just generates 10 instructions.
So you want to have a way to force -O0 for all compiled files? Something 
like "bash configure --with-debug-level=release 
--with-optimization=none", or possibly "make OPTIMIZATION=NONE"?

Or are you happy with the optimization level of a slowdebug build, and 
only want to adjust the value of PRODUCT and ASSERT for hotspot to match 
what's done for a release build? Something like "bash configure 
--enable-hotspot-product-build"?

/Magnus

>
> Thanks
> Ioi
>
> On Apr 10, 2018, at 1:47 PM, Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>> If I understand Ioi correctly, he wants a build with PRODUCT and 
>> !ASSERT but with debug symbols and no optimizations? So, no 
>> assertions and all switches with product defaults?
>>
>> I can see that this could make sense in certain scenarios.
>>
>> ..Thomas
>>
>> On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com 
>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>
>>     On 2018-04-10 02:00, Ioi Lam wrote:
>>
>>         Sometimes I want to debug the product build (I can't bother
>>         with turning off all the trueInDebug options in the hotspot
>>         globals.hpp). The only way that I have found to do this is:
>>
>>         ??? configure --with-native-debug-symbols=internal
>>         ??? mv spec.gmk spec.gmk.old
>>         ??? cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>>
>>         Is there (or should there be) a more elegant way to do it,
>>         like "configure --with-debug-level=slowproduct" :-)
>>
>>     I'm not entirely sure of what you want to achieve.
>>
>>     As I interepret your snippet above, you want no optimization and
>>     internal debug symbols..? How is that debugging a "product" build?
>>
>>     /Magnus
>>
>>
>>         Thanks
>>         - Ioi
>>
>>
>>



From erik.joelsson at oracle.com  Tue Apr 10 21:24:54 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 14:24:54 -0700
Subject: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be
 turned off
In-Reply-To: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
References: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
Message-ID: <b495ee7b-ca3c-4ee8-27dc-5558a8413d92@oracle.com>

Hello,

Nice feature!

Init.gmk: 229 were -> was

Otherwise looks good.

Out of curiosity, was there a reason to move the log parsing macros 
outside of has-spec block? It doesn't look like you changed where you 
call these macros from.

/Erik


On 2018-04-10 13:54, Magnus Ihse Bursie wrote:
> From the bug report:
>
> "The compile errors you get from HotSpot are quite large, and usually 
> don't get entirely printed in PrintFailureReports. This has the effect 
> that the goto mode to find the compilation error is to scroll past 
> PrintFailureReports to get to the complete error message.
>
> It would be nice if there was a way to turn off this feature from the 
> command line."
>
> I've solved this by adding a new LOG option, "report", which takes an 
> argument: "report=default", "report=none" or "report=all". As usual, 
> this can be combined with other LOG options, e.g. "LOG=info,report=all".
>
> The "default" value is what it always been, giving you the first 
> screenful of lines of each failure. "none" is what Stefan requested, 
> and "all" means that there is no truncating, so in a sense, it's 
> another way of giving Stefan what he wants. :-)
>
> To make this usable in practice, I also implemented a feature I've 
> been thinking about a long time, but never gotten around to. And that 
> is to be able to set a default value for LOG in configure, similar to 
> how we can set default values for JOBS or the default make target.
>
> The new flag is "--with-log=<LOG value>", e.g. 
> "--with-log=info,report=none". If a LOG= value is given on the command 
> line, it overrides the default value provided to configure.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201320
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201320-allow-disabling-of-exit-reports/webrev.01
>
>
> /Magnus
>



From magnus.ihse.bursie at oracle.com  Tue Apr 10 21:31:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Apr 2018 23:31:52 +0200
Subject: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be
 turned off
In-Reply-To: <b495ee7b-ca3c-4ee8-27dc-5558a8413d92@oracle.com>
References: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
 <b495ee7b-ca3c-4ee8-27dc-5558a8413d92@oracle.com>
Message-ID: <f81aa38d-b5a0-e5a7-7136-3dee807c80f0@oracle.com>


On 2018-04-10 23:24, Erik Joelsson wrote:
> Hello,
>
> Nice feature!
>
> Init.gmk: 229 were -> was
Fixed without new webrev.

>
> Otherwise looks good.
>
> Out of curiosity, was there a reason to move the log parsing macros 
> outside of has-spec block? It doesn't look like you changed where you 
> call these macros from.
Yes, there was, and yes, I have changed it. :) Right below my typo :-) I 
re-call ParseLogLevel if I get a value in DEFAULT_LOG from the spec.gmk. 
Unfortunately, this means that I now need to call ParseLogLevel both 
without a spec and with a spec, which I have hitherto treated as 
completely different scenarios in Init.gmk/InitSupport.gmk. I have 
verified that the code is suitable to run in the new situation of being 
with a spec.gmk as well. There's a fix for COMMA that's not needed when 
running with a spec, but it doesn't harm either so it's okay.

/Magnus

>
> /Erik
>
>
> On 2018-04-10 13:54, Magnus Ihse Bursie wrote:
>> From the bug report:
>>
>> "The compile errors you get from HotSpot are quite large, and usually 
>> don't get entirely printed in PrintFailureReports. This has the 
>> effect that the goto mode to find the compilation error is to scroll 
>> past PrintFailureReports to get to the complete error message.
>>
>> It would be nice if there was a way to turn off this feature from the 
>> command line."
>>
>> I've solved this by adding a new LOG option, "report", which takes an 
>> argument: "report=default", "report=none" or "report=all". As usual, 
>> this can be combined with other LOG options, e.g. "LOG=info,report=all".
>>
>> The "default" value is what it always been, giving you the first 
>> screenful of lines of each failure. "none" is what Stefan requested, 
>> and "all" means that there is no truncating, so in a sense, it's 
>> another way of giving Stefan what he wants. :-)
>>
>> To make this usable in practice, I also implemented a feature I've 
>> been thinking about a long time, but never gotten around to. And that 
>> is to be able to set a default value for LOG in configure, similar to 
>> how we can set default values for JOBS or the default make target.
>>
>> The new flag is "--with-log=<LOG value>", e.g. 
>> "--with-log=info,report=none". If a LOG= value is given on the 
>> command line, it overrides the default value provided to configure.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201320
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8201320-allow-disabling-of-exit-reports/webrev.01
>>
>>
>> /Magnus
>>
>



From erik.joelsson at oracle.com  Tue Apr 10 21:48:22 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 14:48:22 -0700
Subject: RFR: JDK-8201320 Feature request: Allow PrintFailureReports to be
 turned off
In-Reply-To: <f81aa38d-b5a0-e5a7-7136-3dee807c80f0@oracle.com>
References: <b4051b24-2cf4-8764-4d3f-30f30a7c2d84@oracle.com>
 <b495ee7b-ca3c-4ee8-27dc-5558a8413d92@oracle.com>
 <f81aa38d-b5a0-e5a7-7136-3dee807c80f0@oracle.com>
Message-ID: <2e67a77a-0569-7b85-e369-0a83a01674ce@oracle.com>

Ah it was run without spec before. Looks good then.

/Erik


On 2018-04-10 14:31, Magnus Ihse Bursie wrote:
>
> On 2018-04-10 23:24, Erik Joelsson wrote:
>> Hello,
>>
>> Nice feature!
>>
>> Init.gmk: 229 were -> was
> Fixed without new webrev.
>
>>
>> Otherwise looks good.
>>
>> Out of curiosity, was there a reason to move the log parsing macros 
>> outside of has-spec block? It doesn't look like you changed where you 
>> call these macros from.
> Yes, there was, and yes, I have changed it. :) Right below my typo :-) 
> I re-call ParseLogLevel if I get a value in DEFAULT_LOG from the 
> spec.gmk. Unfortunately, this means that I now need to call 
> ParseLogLevel both without a spec and with a spec, which I have 
> hitherto treated as completely different scenarios in 
> Init.gmk/InitSupport.gmk. I have verified that the code is suitable to 
> run in the new situation of being with a spec.gmk as well. There's a 
> fix for COMMA that's not needed when running with a spec, but it 
> doesn't harm either so it's okay.
>
> /Magnus
>
>>
>> /Erik
>>
>>
>> On 2018-04-10 13:54, Magnus Ihse Bursie wrote:
>>> From the bug report:
>>>
>>> "The compile errors you get from HotSpot are quite large, and 
>>> usually don't get entirely printed in PrintFailureReports. This has 
>>> the effect that the goto mode to find the compilation error is to 
>>> scroll past PrintFailureReports to get to the complete error message.
>>>
>>> It would be nice if there was a way to turn off this feature from 
>>> the command line."
>>>
>>> I've solved this by adding a new LOG option, "report", which takes 
>>> an argument: "report=default", "report=none" or "report=all". As 
>>> usual, this can be combined with other LOG options, e.g. 
>>> "LOG=info,report=all".
>>>
>>> The "default" value is what it always been, giving you the first 
>>> screenful of lines of each failure. "none" is what Stefan requested, 
>>> and "all" means that there is no truncating, so in a sense, it's 
>>> another way of giving Stefan what he wants. :-)
>>>
>>> To make this usable in practice, I also implemented a feature I've 
>>> been thinking about a long time, but never gotten around to. And 
>>> that is to be able to set a default value for LOG in configure, 
>>> similar to how we can set default values for JOBS or the default 
>>> make target.
>>>
>>> The new flag is "--with-log=<LOG value>", e.g. 
>>> "--with-log=info,report=none". If a LOG= value is given on the 
>>> command line, it overrides the default value provided to configure.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201320
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8201320-allow-disabling-of-exit-reports/webrev.01
>>>
>>>
>>> /Magnus
>>>
>>
>



From david.holmes at oracle.com  Tue Apr 10 21:50:53 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 07:50:53 +1000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
References: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
Message-ID: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>

Hi,

On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:

<nothing - only an attachment was present >

Based on the attachment content (see below) this seems a hotspot issue 
for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.

David
------

ld: 0711-318 ERROR: Undefined symbols were found.
	The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR 
Import-File{Shared-object}
                               RLD: Address  Section  Rld-type 
Referencing Symbol
 
----------------------------------------------------------------------------------------------
  .__ct__5frameFPlPUc       [2169]  ER PR 
/home/bhamaram/openJDK/jdk11/src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
                                    00000028 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
                                    00000044 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
ER: The return code is 8.




From Sergey.Bylokhov at oracle.com  Tue Apr 10 21:51:02 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Apr 2018 14:51:02 -0700
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing
 unresolved symbols
In-Reply-To: <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
Message-ID: <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>

LIBS_aix := -lawt_headless,
I guess that AIX team should have a similar fix.

On 10/04/2018 09:34, Erik Joelsson wrote:
> Looks good. Thanks!
> 
> /Erik
> 
> 
> On 2018-04-10 04:25, Severin Gehwolf wrote:
>> Hi Erik,
>>
>> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>>> Hello Severin,
>>>
>>> I'm ok with this solution for now.
>> Thanks for the review!
>>
>>> Could you please reduce the indentation on line 652. In the build system
>>> we like 4 spaces for continuation indent [1]
>> Done. New webrev at:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
>>
>> Could someone from awt-dev have a look at this too? Thanks!
>>
>> Cheers,
>> Severin
>>
>>> /Erik
>>>
>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>
>>> On 2018-04-09 06:39, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> Could somebody please review this build fix for libfontmanager.so. The
>>>> issue for us is that with some LDFLAGS the build breaks as described in
>>>> bug JDK-8196218. However, we cannot link to a providing library at
>>>> build-time since we don't know which one it should be: libawt_headless
>>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters
>>>> out relevant linker flags when libfontmanager is being built. More
>>>> details are in the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
>>>>
>>>> Testing: I've run this through submit[1] and got the following results.
>>>> SwingSet2 works fine for me on F27. I'm currently running some more
>>>> tests on RHEL 7.
>>>>
>>>> ---------------------
>>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds 
>>>> PASSED. Testing FAILURE.
>>>>
>>>> 0 Failed Tests
>>>>
>>>> Mach5 Tasks Results Summary
>>>>
>>>> NA: 0
>>>> UNABLE_TO_RUN: 0
>>>> EXECUTED_WITH_FAILURE: 0
>>>> KILLED: 0
>>>> PASSED: 82
>>>> FAILED: 1
>>>> Test
>>>>
>>>> 1 Failed
>>>>
>>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
>>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
>>>> return value: 10
>>>> --------------------
>>>>
>>>> Not sure what this test failure means. Could somebody at Oracle shed
>>>> some light on this?
>>>>
>>>> Thanks,
>>>> Severin
>>>
> 


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Tue Apr 10 21:55:09 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 10 Apr 2018 14:55:09 -0700
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com>
Message-ID: <21d3872a-7aeb-3b74-93ea-68b1a0be9bbb@oracle.com>

+1
On 10/04/2018 13:57, Magnus Ihse Bursie wrote:
> On 2018-04-10 13:25, Severin Gehwolf wrote:
>> Hi Erik,
>>
>> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>>> Hello Severin,
>>>
>>> I'm ok with this solution for now.
>> Thanks for the review!
>>
>>> Could you please reduce the indentation on line 652. In the build system
>>> we like 4 spaces for continuation indent [1]
>> Done. New webrev at:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
> It's not nice, but there's no other way to do it right now. Approved.
> 
> (I'm working on getting to the point were I can address this in a better 
> way.)
> 
> /Magnus
>>
>> Could someone from awt-dev have a look at this too? Thanks!
>>
>> Cheers,
>> Severin
>>
>>> /Erik
>>>
>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
>>>
>>> On 2018-04-09 06:39, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> Could somebody please review this build fix for libfontmanager.so. The
>>>> issue for us is that with some LDFLAGS the build breaks as described in
>>>> bug JDK-8196218. However, we cannot link to a providing library at
>>>> build-time since we don't know which one it should be: libawt_headless
>>>> or libawt_xawt. That has to happen at runtime. The proposed fix filters
>>>> out relevant linker flags when libfontmanager is being built. More
>>>> details are in the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
>>>>
>>>> Testing: I've run this through submit[1] and got the following results.
>>>> SwingSet2 works fine for me on F27. I'm currently running some more
>>>> tests on RHEL 7.
>>>>
>>>> ---------------------
>>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds 
>>>> PASSED. Testing FAILURE.
>>>>
>>>> 0 Failed Tests
>>>>
>>>> Mach5 Tasks Results Summary
>>>>
>>>> NA: 0
>>>> UNABLE_TO_RUN: 0
>>>> EXECUTED_WITH_FAILURE: 0
>>>> KILLED: 0
>>>> PASSED: 82
>>>> FAILED: 1
>>>> Test
>>>>
>>>> 1 Failed
>>>>
>>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
>>>> debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
>>>> return value: 10
>>>> --------------------
>>>>
>>>> Not sure what this test failure means. Could somebody at Oracle shed
>>>> some light on this?
>>>>
>>>> Thanks,
>>>> Severin
>>>
> 


-- 
Best regards, Sergey.


From bhamaram at in.ibm.com  Wed Apr 11 02:16:33 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Wed, 11 Apr 2018 02:16:33 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
References: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>,
 <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
Message-ID: <OF09EFBDCD.1F430A0F-ON0025826C.000C80B0-0025826C.000C80B9@notes.na.collabserv.com>

 Hi David,
 
Thank you. I had given some more details in my mail. But, for some reason, text in my mail was missing. Anyway, missing symbol is frame::frame(long*,unsigned char*)

ld: 0711-317 ERROR: Undefined symbol: .frame::frame(long*,unsigned char*)
ld: 0711-344 See the loadmap file /home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.

I see that definition of that function is present in src/hotspot/cpu/ppc/frame_ppc.inline.hpp

inline frame::frame(intptr_t* sp, address pc) : _sp(sp), _unextended_sp(sp) {
  find_codeblob_and_set_pc_and_deopt_state(pc); // also sets _fp and adjusts _unextended_sp
}


Thanks,
Bhaktavatsal Reddy
  

-----David Holmes <david.holmes at oracle.com> wrote: -----
To: Bhaktavatsal R Maram <bhamaram at in.ibm.com>, "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>
From: David Holmes <david.holmes at oracle.com>
Date: 04/11/2018 03:21AM
Cc: build-dev at openjdk.java.net
Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX

Hi,

On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:

<nothing - only an attachment was present >

Based on the attachment content (see below) this seems a hotspot issue 
for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.

David
------

ld: 0711-318 ERROR: Undefined symbols were found.
	The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR 
Import-File{Shared-object}
                               RLD: Address  Section  Rld-type 
Referencing Symbol
 
----------------------------------------------------------------------------------------------
  .__ct__5frameFPlPUc       [2169]  ER PR 
/home/bhamaram/openJDK/jdk11/src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
                                    00000028 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
                                    00000044 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
ER: The return code is 8.





From bhamaram at in.ibm.com  Wed Apr 11 02:27:54 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Wed, 11 Apr 2018 02:27:54 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
References: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>,
 <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
Message-ID: <OF3C24F95D.A7477C27-ON0025826C.000D8A97-0025826C.000D8A9B@notes.na.collabserv.com>

Hi David,

Thank you. I had given some more details in my mail. But, for some reason, text in my mail was missing. Anyway, missing symbol is frame::frame(long*,unsigned char*)

ld: 0711-317 ERROR: Undefined symbol: .frame::frame(long*,unsigned char*)
ld: 0711-344 See the loadmap file /home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/libjvm.loadmap for more information.

I see that definition of that function is present in src/hotspot/cpu/ppc/frame_ppc.inline.hpp

inline frame::frame(intptr_t* sp, address pc) : _sp(sp), _unextended_sp(sp) {
  find_codeblob_and_set_pc_and_deopt_state(pc); // also sets _fp and adjusts _unextended_sp
}


Thanks,
Bhaktavatsal Reddy
 

  

-----David Holmes <david.holmes at oracle.com> wrote: -----
To: Bhaktavatsal R Maram <bhamaram at in.ibm.com>, "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>
From: David Holmes <david.holmes at oracle.com>
Date: 04/11/2018 03:21AM
Cc: build-dev at openjdk.java.net
Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX

Hi,

On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:

<nothing - only an attachment was present >

Based on the attachment content (see below) this seems a hotspot issue 
for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.

David
------

ld: 0711-318 ERROR: Undefined symbols were found.
	The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR 
Import-File{Shared-object}
                               RLD: Address  Section  Rld-type 
Referencing Symbol
 
----------------------------------------------------------------------------------------------
  .__ct__5frameFPlPUc       [2169]  ER PR 
/home/bhamaram/openJDK/jdk11/src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
                                    00000028 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
                                    00000044 .text    R_RBR    [1444] 
.pd_last_frame__10JavaThreadFv
ER: The return code is 8.





From thomas.stuefe at gmail.com  Wed Apr 11 03:51:37 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Apr 2018 05:51:37 +0200
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
References: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
 <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
Message-ID: <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>

Hi,

looks like https://bugs.openjdk.java.net/browse/JDK-8200302.

Which has been fixed already in jdk-hs. Please build from there, the
current tip. If you build jdk/jdk you need to apply the patch for that fix
manually.

Best Regards, Thomas

On Tue, Apr 10, 2018 at 11:50 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi,
>
> On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:
>
> <nothing - only an attachment was present >
>
> Based on the attachment content (see below) this seems a hotspot issue for
> the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.
>
> David
> ------
>
> ld: 0711-318 ERROR: Undefined symbols were found.
>         The following symbols are in error:
>  Symbol                    Inpndx  TY CL Source-File(Object-File) OR
> Import-File{Shared-object}
>                               RLD: Address  Section  Rld-type Referencing
> Symbol
>
> ------------------------------------------------------------
> ----------------------------------
>  .__ct__5frameFPlPUc       [2169]  ER PR /home/bhamaram/openJDK/jdk11/s
> rc/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/bhamaram/
> openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/
> variant-server/libjvm/objs/thread_aix_ppc.o)
>                                    00000028 .text    R_RBR    [1444]
> .pd_last_frame__10JavaThreadFv
>                                    00000044 .text    R_RBR    [1444]
> .pd_last_frame__10JavaThreadFv
> ER: The return code is 8.
>
>
>


From ioi.lam at oracle.com  Wed Apr 11 05:12:01 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 10 Apr 2018 22:12:01 -0700
Subject: slowproduct build
In-Reply-To: <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
 <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
 <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>
 <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>
Message-ID: <3965ce5f-9121-54a8-9c7a-2f624c943612@oracle.com>



On 4/10/18 2:21 PM, Magnus Ihse Bursie wrote:
>
> On 2018-04-10 23:08, Ioi Lam wrote:
>> Yes that?s what I want.
>>
>> Yesterday I was using gdb to step into the interpreter generation 
>> code to see what?s generated for a particular routine for 
>> MethodHandles. The debug build contains a LOT of runtime verification 
>> code in the generated code and I couldn?t figure out what?s 
>> happening. The product build just generates 10 instructions.
> So you want to have a way to force -O0 for all compiled files? 
> Something like "bash configure --with-debug-level=release 
> --with-optimization=none", or possibly "make OPTIMIZATION=NONE"?
>
Hi Magnus,

I like the --with-optimization=none flag. This doesn't seem to exist 
yet. Any plans to add it?

The way I would use it is:

 ??? bash configure --with-debug-level=product --with-optimization=none

Thanks
- Ioi

> Or are you happy with the optimization level of a slowdebug build, and 
> only want to adjust the value of PRODUCT and ASSERT for hotspot to 
> match what's done for a release build? Something like "bash configure 
> --enable-hotspot-product-build"?
>
> /Magnus
>
>>
>> Thanks
>> Ioi
>>
>> On Apr 10, 2018, at 1:47 PM, Thomas St?fe <thomas.stuefe at gmail.com 
>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>
>>> If I understand Ioi correctly, he wants a build with PRODUCT and 
>>> !ASSERT but with debug symbols and no optimizations? So, no 
>>> assertions and all switches with product defaults?
>>>
>>> I can see that this could make sense in certain scenarios.
>>>
>>> ..Thomas
>>>
>>> On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com 
>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>
>>>     On 2018-04-10 02:00, Ioi Lam wrote:
>>>
>>>         Sometimes I want to debug the product build (I can't bother
>>>         with turning off all the trueInDebug options in the hotspot
>>>         globals.hpp). The only way that I have found to do this is:
>>>
>>>         ??? configure --with-native-debug-symbols=internal
>>>         ??? mv spec.gmk spec.gmk.old
>>>         ??? cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>>>
>>>         Is there (or should there be) a more elegant way to do it,
>>>         like "configure --with-debug-level=slowproduct" :-)
>>>
>>>     I'm not entirely sure of what you want to achieve.
>>>
>>>     As I interepret your snippet above, you want no optimization and
>>>     internal debug symbols..? How is that debugging a "product" build?
>>>
>>>     /Magnus
>>>
>>>
>>>         Thanks
>>>         - Ioi
>>>
>>>
>>>
>



From bhamaram at in.ibm.com  Wed Apr 11 05:29:05 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Wed, 11 Apr 2018 05:29:05 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>
References: <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>,
 <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
 <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
Message-ID: <OFE5EDFE89.E6685E57-ON0025826C.001DB766-0025826C.001E2123@notes.na.collabserv.com>

Hi Thomas,

Thank you. It worked!

One question, hotspot source in jdk/hs and jdk/jdk won't be in sync?

- Bhaktavatsal Reddy


-----"Thomas St?fe" <thomas.stuefe at gmail.com> wrote: -----
To: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>, Bhaktavatsal R Maram <bhamaram at in.ibm.com>
From: "Thomas St?fe" <thomas.stuefe at gmail.com>
Date: 04/11/2018 09:21AM
Cc: build-dev <build-dev at openjdk.java.net>, David Holmes <david.holmes at oracle.com>
Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX

Hi,

looks like https://bugs.openjdk.java.net/browse/JDK-8200302.

Which has been fixed already in jdk-hs. Please build from there, the current tip. If you build jdk/jdk you need to apply the patch for that fix manually.

Best Regards, Thomas

On Tue, Apr 10, 2018 at 11:50 PM, David Holmes <david.holmes at oracle.com> wrote:
Hi,
 
 On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:
 
 <nothing - only an attachment was present >
 
 Based on the attachment content (see below) this seems a hotspot issue for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.
 
 David
 ------
 
 ld: 0711-318 ERROR: Undefined symbols were found.
         The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR Import-File{Shared-object}
                               RLD: Address  Section  Rld-type Referencing Symbol
 
 ----------------------------------------------------------------------------------------------
  .__ct__5frameFPlPUc       [2169]  ER PR /home/bhamaram/openJDK/jdk11/src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
                                    00000028 .text    R_RBR    [1444] .pd_last_frame__10JavaThreadFv
                                    00000044 .text    R_RBR    [1444] .pd_last_frame__10JavaThreadFv
 ER: The return code is 8.
 
 
 
 



From thomas.stuefe at gmail.com  Wed Apr 11 05:41:37 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Apr 2018 07:41:37 +0200
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <OFE5EDFE89.E6685E57-ON0025826C.001DB766-0025826C.001E2123@notes.na.collabserv.com>
References: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
 <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
 <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>
 <OFE5EDFE89.E6685E57-ON0025826C.001DB766-0025826C.001E2123@notes.na.collabserv.com>
Message-ID: <CAA-vtUw2Eavb+POeFBR_=Kb_xDts9rjCD8RST8Ftdt5S4Cn_oQ@mail.gmail.com>

You are welcome! Glad it worked.

I work for SAP, not Oracle (SAP maintains the AIX port, among other
things), so I do not know the details of when the two depots get synced. I
think about once a week or so? Others may know more.

If you require a current jdk11 to work with, currently jdk-hs may be a
better choice since we mostly work in that repo (most of our work is
hotspot related) and build errors tend to get fixed faster than in jdk/jdk.
However, soon this will be a non issue hopefully, since both repos will be
merged.

Best Regards, Thomas


On Wed, Apr 11, 2018 at 7:29 AM, Bhaktavatsal R Maram <bhamaram at in.ibm.com>
wrote:

> Hi Thomas,
>
> Thank you. It worked!
>
> One question, hotspot source in jdk/hs and jdk/jdk won't be in sync?
>
> - Bhaktavatsal Reddy
>
>
> -----"Thomas St?fe" <thomas.stuefe at gmail.com> wrote: -----
> To: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.
> java.net>, Bhaktavatsal R Maram <bhamaram at in.ibm.com>
> From: "Thomas St?fe" <thomas.stuefe at gmail.com>
> Date: 04/11/2018 09:21AM
> Cc: build-dev <build-dev at openjdk.java.net>, David Holmes <
> david.holmes at oracle.com>
> Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX
>
> Hi,
>
> looks like https://bugs.openjdk.java.net/browse/JDK-8200302.
>
> Which has been fixed already in jdk-hs. Please build from there, the
> current tip. If you build jdk/jdk you need to apply the patch for that fix
> manually.
>
> Best Regards, Thomas
>
> On Tue, Apr 10, 2018 at 11:50 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> Hi,
>
>  On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:
>
>  <nothing - only an attachment was present >
>
>  Based on the attachment content (see below) this seems a hotspot issue
> for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.
>
>  David
>  ------
>
>  ld: 0711-318 ERROR: Undefined symbols were found.
>          The following symbols are in error:
>   Symbol                    Inpndx  TY CL Source-File(Object-File) OR
> Import-File{Shared-object}
>                                RLD: Address  Section  Rld-type Referencing
> Symbol
>
>  ------------------------------------------------------------
> ----------------------------------
>   .__ct__5frameFPlPUc       [2169]  ER PR /home/bhamaram/openJDK/jdk11/
> src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/
> bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-
> release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
>                                     00000028 .text    R_RBR    [1444]
> .pd_last_frame__10JavaThreadFv
>                                     00000044 .text    R_RBR    [1444]
> .pd_last_frame__10JavaThreadFv
>  ER: The return code is 8.
>
>
>
>
>
>


From matthias.baesken at sap.com  Wed Apr 11 07:44:13 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 11 Apr 2018 07:44:13 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
Message-ID: <5693830fbf6747d9a51e9cf374f63e18@sap.com>


> 
> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>

Hi  Alexey, yes that's true .

> Please remove JNIEXPORT from main():
> src/java.base/share/native/launcher/main.c
> src/jdk.pack/share/native/unpack200/main.cpp

I would  prefer to keep it for now .
I notice  some  comments  in our SAPJVM code base  about needing  JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without  mapfiles in the past already).
Maybe  that?s related to  

src/java.base/unix/native/libjli/java_md_solinux.c

where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
but I am not sure about this.
So I better keep  the JNIEXPORT  for the main functions,   could be removed in another  cleanup  if really needed.


> You can reference both yourself and me as
> Contributed-by: mbaesken, aivanov
> when pushing the changeset if you don't mind.
>


Sure .

Best regards, Matthias


> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Dienstag, 10. April 2018 21:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias,
> 
> On 10/04/2018 11:14, Baesken, Matthias wrote:
> > Hello,  I  had to  do another small adjustment  to make jimage.hpp/cpp
> match.    Please review :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> 
> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> 
> I've successfully built 32 bit Windows with your patch.
> 
> 
> Please remove JNIEXPORT from main():
> src/java.base/share/native/launcher/main.c
> src/jdk.pack/share/native/unpack200/main.cpp
> 
> > With the latest webrev I could finally    build    jdk/jdk   successfully on both
> win32bit   and win64 bit .
> >
> >
> >
> > Thanks again  to Alexey  to provide  the   incorporated patch .
> 
> You can reference both yourself and me as
> Contributed-by: mbaesken, aivanov
> when pushing the changeset if you don't mind.
> 
> 
> Regards,
> Alexey
> 
> >
> >
> > Best regards, Matthias
> >
> >
> >
> >> -----Original Message-----
> >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >> Sent: Montag, 9. April 2018 17:14
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> Bursie
> >> <magnus.ihse.bursie at oracle.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Matthias,
> >>
> >> On 09/04/2018 15:38, Baesken, Matthias wrote:
> >>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
> explanations
> >> .
> >>> I created  a second  webrev :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> >>>
> >>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
> >> Yes, that's fine with me.
> >> There could be only one author ;)
> >>
> >>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c
> and
> >> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
> >> issues after mapfile removal for exes
> >>
> >> I'd rather remove both JNIEXPORT and JNICALL from main().
> >> It wasn't exported, and it shouldn't be.
> >>
> >> Regards,
> >> Alexey
> >>
> >>> Best regards , Matthias

From sgehwolf at redhat.com  Wed Apr 11 08:17:57 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Apr 2018 10:17:57 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
 <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>
Message-ID: <1523434677.4440.8.camel@redhat.com>

On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote:
> LIBS_aix := -lawt_headless,
> I guess that AIX team should have a similar fix.

Possibly. I have no way of testing it, though. So will leave it to AIX
folk to have a look. My experience was that it isn't easily
reproducible. Some observations:

   1. Run swing app such as SwingSet2 on a headfull system. Since
      fontmanager will have a link dep on lawt_headless, and awt code
      loads libawt_xawt (headfull) on a headfull system, both libraries
      providing symbols needed by libfontmanager will be loaded. Then it
      depends whether this is a problem on that particular system or not.
      In my experience this worked on some systems and not on others.
   2. Solaris was build-time linking to libawt_headless causing bug
      8194870. So build-time linking got removed with that bug. Not sure
      why that bug is private :(

Thanks,
Severin

> On 10/04/2018 09:34, Erik Joelsson wrote:
> > Looks good. Thanks!
> > 
> > /Erik
> > 
> > 
> > On 2018-04-10 04:25, Severin Gehwolf wrote:
> > > Hi Erik,
> > > 
> > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
> > > > Hello Severin,
> > > > 
> > > > I'm ok with this solution for now.
> > > 
> > > Thanks for the review!
> > > 
> > > > Could you please reduce the indentation on line 652. In the
> > > > build system
> > > > we like 4 spaces for continuation indent [1]
> > > 
> > > Done. New webrev at:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0
> > > 2
> > > 
> > > Could someone from awt-dev have a look at this too? Thanks!
> > > 
> > > Cheers,
> > > Severin
> > > 
> > > > /Erik
> > > > 
> > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h
> > > > tml
> > > > 
> > > > On 2018-04-09 06:39, Severin Gehwolf wrote:
> > > > > Hi,
> > > > > 
> > > > > Could somebody please review this build fix for
> > > > > libfontmanager.so. The
> > > > > issue for us is that with some LDFLAGS the build breaks as
> > > > > described in
> > > > > bug JDK-8196218. However, we cannot link to a providing
> > > > > library at
> > > > > build-time since we don't know which one it should be:
> > > > > libawt_headless
> > > > > or libawt_xawt. That has to happen at runtime. The proposed
> > > > > fix filters
> > > > > out relevant linker flags when libfontmanager is being built.
> > > > > More
> > > > > details are in the bug.
> > > > > 
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> > > > > webrev: 
> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr
> > > > > ev.01/
> > > > > 
> > > > > Testing: I've run this through submit[1] and got the
> > > > > following results.
> > > > > SwingSet2 works fine for me on F27. I'm currently running
> > > > > some more
> > > > > tests on RHEL 7.
> > > > > 
> > > > > ---------------------
> > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877:
> > > > > Builds 
> > > > > PASSED. Testing FAILURE.
> > > > > 
> > > > > 0 Failed Tests
> > > > > 
> > > > > Mach5 Tasks Results Summary
> > > > > 
> > > > > NA: 0
> > > > > UNABLE_TO_RUN: 0
> > > > > EXECUTED_WITH_FAILURE: 0
> > > > > KILLED: 0
> > > > > PASSED: 82
> > > > > FAILED: 1
> > > > > Test
> > > > > 
> > > > > 1 Failed
> > > > > 
> > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-
> > > > > windows-x64-
> > > > > debug-31 SetupFailedException in setup...profile run-test-
> > > > > prebuilt' ,
> > > > > return value: 10
> > > > > --------------------
> > > > > 
> > > > > Not sure what this test failure means. Could somebody at
> > > > > Oracle shed
> > > > > some light on this?
> > > > > 
> > > > > Thanks,
> > > > > Severin
> 
> 


From alexey.ivanov at oracle.com  Wed Apr 11 09:10:54 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Apr 2018 10:10:54 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <5693830fbf6747d9a51e9cf374f63e18@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
Message-ID: <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>


On 11/04/2018 08:44, Baesken, Matthias wrote:
>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> Hi  Alexey, yes that's true .
>
>> Please remove JNIEXPORT from main():
>> src/java.base/share/native/launcher/main.c
>> src/jdk.pack/share/native/unpack200/main.cpp
> I would  prefer to keep it for now .
> I notice  some  comments  in our SAPJVM code base  about needing  JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without  mapfiles in the past already).
> Maybe  that?s related to
>
> src/java.base/unix/native/libjli/java_md_solinux.c
>
> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
> but I am not sure about this.
> So I better keep  the JNIEXPORT  for the main functions,   could be removed in another  cleanup  if really needed.

OK. Let them stay then.
Was main() exported via map files?


The change looks good to me.

Regards,
Alexey

>
>> You can reference both yourself and me as
>> Contributed-by: mbaesken, aivanov
>> when pushing the changeset if you don't mind.
>>
> Sure .
>
> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Dienstag, 10. April 2018 21:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>> Hi Matthias,
>>
>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp match. Please review :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>
>> I've successfully built 32 bit Windows with your patch.
>>
>>
>> Please remove JNIEXPORT from main():
>> src/java.base/share/native/launcher/main.c
>> src/jdk.pack/share/native/unpack200/main.cpp
>>
>>> With the latest webrev I could finally build jdk/jdk successfully on both win32bit and win64 bit.
>>>
>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>> You can reference both yourself and me as
>> Contributed-by: mbaesken, aivanov
>> when pushing the changeset if you don't mind.
>>
>>
>> Regards,
>> Alexey
>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Montag, 9. April 2018 17:14
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>> Bursie
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>>
>>>> Hi Matthias,
>>>>
>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>> explanations
>>>> .
>>>>> I created  a second  webrev :
>>>>>
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>
>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>> Yes, that's fine with me.
>>>> There could be only one author ;)
>>>>
>>>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c
>> and
>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
>>>> issues after mapfile removal for exes
>>>>
>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>> It wasn't exported, and it shouldn't be.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>> Best regards , Matthias



From matthias.baesken at sap.com  Wed Apr 11 09:20:04 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 11 Apr 2018 09:20:04 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
Message-ID: <3520f157a7d14a118a584fdeb226381e@sap.com>

>
> Was main() exported via map files?
>

Seems main was exported , I can find it in jdk10  in  e.g.  :

make/mapfiles/launchers/mapfile-sparcv9
make/mapfiles/launchers/mapfile-x86_64


Best regards, Matthias


> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Mittwoch, 11. April 2018 11:11
> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> 
> On 11/04/2018 08:44, Baesken, Matthias wrote:
> >> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> > Hi  Alexey, yes that's true .
> >
> >> Please remove JNIEXPORT from main():
> >> src/java.base/share/native/launcher/main.c
> >> src/jdk.pack/share/native/unpack200/main.cpp
> > I would  prefer to keep it for now .
> > I notice  some  comments  in our SAPJVM code base  about needing
> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
> mapfiles in the past already).
> > Maybe  that?s related to
> >
> > src/java.base/unix/native/libjli/java_md_solinux.c
> >
> > where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
> > but I am not sure about this.
> > So I better keep  the JNIEXPORT  for the main functions,   could be
> removed in another  cleanup  if really needed.
> 
> OK. Let them stay then.
> Was main() exported via map files?
> 
> 
> The change looks good to me.
> 
> Regards,
> Alexey
> 
> >
> >> You can reference both yourself and me as
> >> Contributed-by: mbaesken, aivanov
> >> when pushing the changeset if you don't mind.
> >>
> > Sure .
> >
> > Best regards, Matthias
> >
> >
> >> -----Original Message-----
> >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >> Sent: Dienstag, 10. April 2018 21:34
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> Bursie
> >> <magnus.ihse.bursie at oracle.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Matthias,
> >>
> >> On 10/04/2018 11:14, Baesken, Matthias wrote:
> >>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
> match. Please review :
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> >> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> >>
> >> I've successfully built 32 bit Windows with your patch.
> >>
> >>
> >> Please remove JNIEXPORT from main():
> >> src/java.base/share/native/launcher/main.c
> >> src/jdk.pack/share/native/unpack200/main.cpp
> >>
> >>> With the latest webrev I could finally build jdk/jdk successfully on both
> win32bit and win64 bit.
> >>>
> >>> Thanks again  to Alexey  to provide  the   incorporated patch .
> >> You can reference both yourself and me as
> >> Contributed-by: mbaesken, aivanov
> >> when pushing the changeset if you don't mind.
> >>
> >>
> >> Regards,
> >> Alexey
> >>
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >>>> Sent: Montag, 9. April 2018 17:14
> >>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> >> Bursie
> >>>> <magnus.ihse.bursie at oracle.com>
> >>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >>>> <martin.doerr at sap.com>
> >>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >> function
> >>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> at
> >>>> some places in function declarations/implementations
> >>>>
> >>>> Hi Matthias,
> >>>>
> >>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
> >>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
> >> explanations
> >>>> .
> >>>>> I created  a second  webrev :
> >>>>>
> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> >>>>>
> >>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
> >>>> Yes, that's fine with me.
> >>>> There could be only one author ;)
> >>>>
> >>>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c
> >> and
> >>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
> similar
> >>>> issues after mapfile removal for exes
> >>>>
> >>>> I'd rather remove both JNIEXPORT and JNICALL from main().
> >>>> It wasn't exported, and it shouldn't be.
> >>>>
> >>>> Regards,
> >>>> Alexey
> >>>>
> >>>>> Best regards , Matthias


From sgehwolf at redhat.com  Wed Apr 11 09:39:27 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Apr 2018 11:39:27 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
Message-ID: <1523439567.4440.17.camel@redhat.com>

On Tue, 2018-04-10 at 09:34 -0700, Erik Joelsson wrote:
> Looks good. Thanks!

Thanks, Erik.

Cheers,
Severin

> /Erik
> 
> 
> On 2018-04-10 04:25, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
> > > Hello Severin,
> > > 
> > > I'm ok with this solution for now.
> > 
> > Thanks for the review!
> > 
> > > Could you please reduce the indentation on line 652. In the build system
> > > we like 4 spaces for continuation indent [1]
> > 
> > Done. New webrev at:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
> > 
> > Could someone from awt-dev have a look at this too? Thanks!
> > 
> > Cheers,
> > Severin
> > 
> > > /Erik
> > > 
> > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.html
> > > 
> > > On 2018-04-09 06:39, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could somebody please review this build fix for libfontmanager.so. The
> > > > issue for us is that with some LDFLAGS the build breaks as described in
> > > > bug JDK-8196218. However, we cannot link to a providing library at
> > > > build-time since we don't know which one it should be: libawt_headless
> > > > or libawt_xawt. That has to happen at runtime. The proposed fix filters
> > > > out relevant linker flags when libfontmanager is being built. More
> > > > details are in the bug.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/
> > > > 
> > > > Testing: I've run this through submit[1] and got the following results.
> > > > SwingSet2 works fine for me on F27. I'm currently running some more
> > > > tests on RHEL 7.
> > > > 
> > > > ---------------------
> > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE.
> > > > 
> > > > 0 Failed Tests
> > > > 
> > > > Mach5 Tasks Results Summary
> > > > 
> > > > NA: 0
> > > > UNABLE_TO_RUN: 0
> > > > EXECUTED_WITH_FAILURE: 0
> > > > KILLED: 0
> > > > PASSED: 82
> > > > FAILED: 1
> > > > Test
> > > > 
> > > > 1 Failed
> > > > 
> > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
> > > > debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
> > > > return value: 10
> > > > --------------------
> > > > 
> > > > Not sure what this test failure means. Could somebody at Oracle shed
> > > > some light on this?
> > > > 
> > > > Thanks,
> > > > Severin
> 
> 


From sgehwolf at redhat.com  Wed Apr 11 09:41:39 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Apr 2018 11:41:39 +0200
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with
 LDFLAGS allowing unresolved symbols
In-Reply-To: <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <485e618c-e6f3-b36f-3201-f6f11fb28ace@oracle.com>
Message-ID: <1523439699.4440.19.camel@redhat.com>

Hi Magnus,

On Tue, 2018-04-10 at 22:57 +0200, Magnus Ihse Bursie wrote:
> On 2018-04-10 13:25, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
> > > Hello Severin,
> > > 
> > > I'm ok with this solution for now.
> > 
> > Thanks for the review!
> > 
> > > Could you please reduce the indentation on line 652. In the build
> > > system
> > > we like 4 spaces for continuation indent [1]
> > 
> > Done. New webrev at:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.02
> 
> It's not nice, but there's no other way to do it right now. Approved.

Thanks for the review!

Cheers,
Severin

> (I'm working on getting to the point were I can address this in a
> better 
> way.)
> 
> /Magnus
> > 
> > Could someone from awt-dev have a look at this too? Thanks!
> > 
> > Cheers,
> > Severin
> > 
> > > /Erik
> > > 
> > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.htm
> > > l
> > > 
> > > On 2018-04-09 06:39, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Could somebody please review this build fix for
> > > > libfontmanager.so. The
> > > > issue for us is that with some LDFLAGS the build breaks as
> > > > described in
> > > > bug JDK-8196218. However, we cannot link to a providing library
> > > > at
> > > > build-time since we don't know which one it should be:
> > > > libawt_headless
> > > > or libawt_xawt. That has to happen at runtime. The proposed fix
> > > > filters
> > > > out relevant linker flags when libfontmanager is being built.
> > > > More
> > > > details are in the bug.
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-819651
> > > > 6/webrev.01/
> > > > 
> > > > Testing: I've run this through submit[1] and got the following
> > > > results.
> > > > SwingSet2 works fine for me on F27. I'm currently running some
> > > > more
> > > > tests on RHEL 7.
> > > > 
> > > > ---------------------
> > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877:
> > > > Builds PASSED. Testing FAILURE.
> > > > 
> > > > 0 Failed Tests
> > > > 
> > > > Mach5 Tasks Results Summary
> > > > 
> > > > NA: 0
> > > > UNABLE_TO_RUN: 0
> > > > EXECUTED_WITH_FAILURE: 0
> > > > KILLED: 0
> > > > PASSED: 82
> > > > FAILED: 1
> > > > Test
> > > > 
> > > > 1 Failed
> > > > 
> > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-
> > > > windows-x64-
> > > > debug-31 SetupFailedException in setup...profile run-test-
> > > > prebuilt' ,
> > > > return value: 10
> > > > --------------------
> > > > 
> > > > Not sure what this test failure means. Could somebody at Oracle
> > > > shed
> > > > some light on this?
> > > > 
> > > > Thanks,
> > > > Severin
> 
> 


From christoph.langer at sap.com  Wed Apr 11 09:47:56 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Apr 2018 09:47:56 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <CAA-vtUw2Eavb+POeFBR_=Kb_xDts9rjCD8RST8Ftdt5S4Cn_oQ@mail.gmail.com>
References: <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
 <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
 <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>
 <OFE5EDFE89.E6685E57-ON0025826C.001DB766-0025826C.001E2123@notes.na.collabserv.com>
 <CAA-vtUw2Eavb+POeFBR_=Kb_xDts9rjCD8RST8Ftdt5S4Cn_oQ@mail.gmail.com>
Message-ID: <46adf9cc3e82494390cf34bdaab20cd1@sap.com>

Hi Bhaktavatsal,

As per [1], the jdk-hs repo will be closed tomorrow and finally merged with jdk. After that, only the jdk depot will continue to be active and you should not run into such type of inconsistencies any longer...

Best regards
Christoph

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001039.html

> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Mittwoch, 11. April 2018 07:42
> To: Bhaktavatsal R Maram <bhamaram at in.ibm.com>
> Cc: build-dev <build-dev at openjdk.java.net>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX
> 
> You are welcome! Glad it worked.
> 
> I work for SAP, not Oracle (SAP maintains the AIX port, among other
> things), so I do not know the details of when the two depots get synced. I
> think about once a week or so? Others may know more.
> 
> If you require a current jdk11 to work with, currently jdk-hs may be a
> better choice since we mostly work in that repo (most of our work is
> hotspot related) and build errors tend to get fixed faster than in jdk/jdk.
> However, soon this will be a non issue hopefully, since both repos will be
> merged.
> 
> Best Regards, Thomas
> 
> 
> On Wed, Apr 11, 2018 at 7:29 AM, Bhaktavatsal R Maram
> <bhamaram at in.ibm.com>
> wrote:
> 
> > Hi Thomas,
> >
> > Thank you. It worked!
> >
> > One question, hotspot source in jdk/hs and jdk/jdk won't be in sync?
> >
> > - Bhaktavatsal Reddy
> >
> >
> > -----"Thomas St?fe" <thomas.stuefe at gmail.com> wrote: -----
> > To: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-
> dev at openjdk.
> > java.net>, Bhaktavatsal R Maram <bhamaram at in.ibm.com>
> > From: "Thomas St?fe" <thomas.stuefe at gmail.com>
> > Date: 04/11/2018 09:21AM
> > Cc: build-dev <build-dev at openjdk.java.net>, David Holmes <
> > david.holmes at oracle.com>
> > Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX
> >
> > Hi,
> >
> > looks like https://bugs.openjdk.java.net/browse/JDK-8200302.
> >
> > Which has been fixed already in jdk-hs. Please build from there, the
> > current tip. If you build jdk/jdk you need to apply the patch for that fix
> > manually.
> >
> > Best Regards, Thomas
> >
> > On Tue, Apr 10, 2018 at 11:50 PM, David Holmes
> <david.holmes at oracle.com>
> > wrote:
> > Hi,
> >
> >  On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:
> >
> >  <nothing - only an attachment was present >
> >
> >  Based on the attachment content (see below) this seems a hotspot issue
> > for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.
> >
> >  David
> >  ------
> >
> >  ld: 0711-318 ERROR: Undefined symbols were found.
> >          The following symbols are in error:
> >   Symbol                    Inpndx  TY CL Source-File(Object-File) OR
> > Import-File{Shared-object}
> >                                RLD: Address  Section  Rld-type Referencing
> > Symbol
> >
> >  ------------------------------------------------------------
> > ----------------------------------
> >   .__ct__5frameFPlPUc       [2169]  ER PR
> /home/bhamaram/openJDK/jdk11/
> > src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/
> > bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-
> > release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)
> >                                     00000028 .text    R_RBR    [1444]
> > .pd_last_frame__10JavaThreadFv
> >                                     00000044 .text    R_RBR    [1444]
> > .pd_last_frame__10JavaThreadFv
> >  ER: The return code is 8.
> >
> >
> >
> >
> >
> >

From alexey.ivanov at oracle.com  Wed Apr 11 09:56:20 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Apr 2018 10:56:20 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <3520f157a7d14a118a584fdeb226381e@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
Message-ID: <34917a6d-6610-120d-2e8f-b7c54678377b@oracle.com>

The change looks good to me.

On 11/04/2018 10:20, Baesken, Matthias wrote:
>> Was main() exported via map files?
> Seems main was exported , I can find it in jdk10  in  e.g.  :
>
> make/mapfiles/launchers/mapfile-sparcv9
> make/mapfiles/launchers/mapfile-x86_64

Thank you for confirming it.
Then JNIEXPORT is better left untouched to keep main() exported.


Regards,
Alexey

> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Mittwoch, 11. April 2018 11:11
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>>
>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>> Hi  Alexey, yes that's true .
>>>
>>>> Please remove JNIEXPORT from main():
>>>> src/java.base/share/native/launcher/main.c
>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>> I would  prefer to keep it for now .
>>> I notice  some  comments  in our SAPJVM code base  about needing
>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
>> mapfiles in the past already).
>>> Maybe  that?s related to
>>>
>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>
>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>>> but I am not sure about this.
>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>> removed in another  cleanup  if really needed.
>>
>> OK. Let them stay then.
>> Was main() exported via map files?
>>
>>
>> The change looks good to me.
>>
>> Regards,
>> Alexey
>>
>>>> You can reference both yourself and me as
>>>> Contributed-by: mbaesken, aivanov
>>>> when pushing the changeset if you don't mind.
>>>>
>>> Sure .
>>>
>>> Best regards, Matthias
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Dienstag, 10. April 2018 21:34
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>> Bursie
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>>
>>>> Hi Matthias,
>>>>
>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
>> match. Please review :
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>
>>>> I've successfully built 32 bit Windows with your patch.
>>>>
>>>>
>>>> Please remove JNIEXPORT from main():
>>>> src/java.base/share/native/launcher/main.c
>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>
>>>>> With the latest webrev I could finally build jdk/jdk successfully on both
>> win32bit and win64 bit.
>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>> You can reference both yourself and me as
>>>> Contributed-by: mbaesken, aivanov
>>>> when pushing the changeset if you don't mind.
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>> Bursie
>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>> <martin.doerr at sap.com>
>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function
>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>> at
>>>>>> some places in function declarations/implementations
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>> explanations
>>>>>> .
>>>>>>> I created  a second  webrev :
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>
>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>> Yes, that's fine with me.
>>>>>> There could be only one author ;)
>>>>>>
>>>>>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c
>>>> and
>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>> similar
>>>>>> issues after mapfile removal for exes
>>>>>>
>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>>> Best regards , Matthias



From alexey.ivanov at oracle.com  Wed Apr 11 10:01:38 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Apr 2018 11:01:38 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <34917a6d-6610-120d-2e8f-b7c54678377b@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <34917a6d-6610-120d-2e8f-b7c54678377b@oracle.com>
Message-ID: <84e8c6ec-727b-33c4-f842-d2da18ef99b8@oracle.com>

I guess we also need to get an approval from core-libs (cc'd) as libzip 
and libjimage are modified.


Regards,
Alexey

On 11/04/2018 10:56, Alexey Ivanov wrote:
> The change looks good to me.
>
> On 11/04/2018 10:20, Baesken, Matthias wrote:
>>> Was main() exported via map files?
>> Seems main was exported , I can find it in jdk10? in? e.g.? :
>>
>> make/mapfiles/launchers/mapfile-sparcv9
>> make/mapfiles/launchers/mapfile-x86_64
>
> Thank you for confirming it.
> Then JNIEXPORT is better left untouched to keep main() exported.
>
>
> Regards,
> Alexey
>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Mittwoch, 11. April 2018 11:11
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>
>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>> Hi? Alexey, yes that's true .
>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>> I would? prefer to keep it for now .
>>>> I notice? some? comments? in our SAPJVM code base? about needing
>>> JNIEXPORT for? main? for Solaris? (we were running? in SAPJVM without
>>> mapfiles in the past already).
>>>> Maybe? that?s related to
>>>>
>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>
>>>> where main? is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, 
>>>> "main");
>>>> but I am not sure about this.
>>>> So I better keep? the JNIEXPORT? for the main functions, could be
>>> removed in another? cleanup? if really needed.
>>>
>>> OK. Let them stay then.
>>> Was main() exported via map files?
>>>
>>>
>>> The change looks good to me.
>>>
>>> Regards,
>>> Alexey
>>>
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>> Sure .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>> JNICALL at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>> Hello,? I? had to? do another small adjustment to make 
>>>>>> jimage.hpp/cpp
>>> match. Please review :
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>
>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>
>>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>
>>>>>> With the latest webrev I could finally build jdk/jdk successfully 
>>>>>> on both
>>> win32bit and win64 bit.
>>>>>> Thanks again? to Alexey? to provide? the?? incorporated patch .
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>>>> JNICALL
>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>> Hi? Alexey,??? thanks? for the diff provided by you, and? for? the
>>>>> explanations
>>>>>>> .
>>>>>>>> I created? a second? webrev :
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>
>>>>>>>> -?? it? adds? the diff? provided by you??? (hope that?s fine 
>>>>>>>> with you)
>>>>>>> Yes, that's fine with me.
>>>>>>> There could be only one author ;)
>>>>>>>
>>>>>>>> -??? changes? 2 launchers 
>>>>>>>> src/java.base/share/native/launcher/main.c
>>>>> and
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face
>>> similar
>>>>>>> issues after mapfile removal for exes
>>>>>>>
>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>>> Best regards , Matthias
>



From magnus.ihse.bursie at oracle.com  Wed Apr 11 10:38:43 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Apr 2018 12:38:43 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
Message-ID: <325D3529-ADD0-4E1E-A5CF-5C20F7F69F96@oracle.com>



> 11 apr. 2018 kl. 11:10 skrev Alexey Ivanov <alexey.ivanov at oracle.com>:
> 
> 
> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>> Hi  Alexey, yes that's true .
>> 
>>> Please remove JNIEXPORT from main():
>>> src/java.base/share/native/launcher/main.c
>>> src/jdk.pack/share/native/unpack200/main.cpp
>> I would  prefer to keep it for now .
>> I notice  some  comments  in our SAPJVM code base  about needing  JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without  mapfiles in the past already).
>> Maybe  that?s related to
>> 
>> src/java.base/unix/native/libjli/java_md_solinux.c
>> 
>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>> but I am not sure about this.
>> So I better keep  the JNIEXPORT  for the main functions,   could be removed in another  cleanup  if really needed.
> 
> OK. Let them stay then.
> Was main() exported via map files?

Yes. You cannot remove the export of main! Since we hide symbols by default even for executables, it would not be possible to execute if the main function is not visible. 

/Magnus

> 
> 
> The change looks good to me.
> 
> Regards,
> Alexey
> 
>> 
>>> You can reference both yourself and me as
>>> Contributed-by: mbaesken, aivanov
>>> when pushing the changeset if you don't mind.
>>> 
>> Sure .
>> 
>> Best regards, Matthias
>> 
>> 
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Dienstag, 10. April 2018 21:34
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>> 
>>> Hi Matthias,
>>> 
>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp match. Please review :
>>>> 
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>> 
>>> I've successfully built 32 bit Windows with your patch.
>>> 
>>> 
>>> Please remove JNIEXPORT from main():
>>> src/java.base/share/native/launcher/main.c
>>> src/jdk.pack/share/native/unpack200/main.cpp
>>> 
>>>> With the latest webrev I could finally build jdk/jdk successfully on both win32bit and win64 bit.
>>>> 
>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>> You can reference both yourself and me as
>>> Contributed-by: mbaesken, aivanov
>>> when pushing the changeset if you don't mind.
>>> 
>>> 
>>> Regards,
>>> Alexey
>>> 
>>>> 
>>>> Best regards, Matthias
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Montag, 9. April 2018 17:14
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>> 
>>>>> Hi Matthias,
>>>>> 
>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>> explanations
>>>>> .
>>>>>> I created  a second  webrev :
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>> 
>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>> Yes, that's fine with me.
>>>>> There could be only one author ;)
>>>>> 
>>>>>> -    changes  2 launchers    src/java.base/share/native/launcher/main.c
>>> and
>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face similar
>>>>> issues after mapfile removal for exes
>>>>> 
>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>> It wasn't exported, and it shouldn't be.
>>>>> 
>>>>> Regards,
>>>>> Alexey
>>>>> 
>>>>>> Best regards , Matthias
> 



From alexey.ivanov at oracle.com  Wed Apr 11 12:49:59 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 11 Apr 2018 13:49:59 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <325D3529-ADD0-4E1E-A5CF-5C20F7F69F96@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <325D3529-ADD0-4E1E-A5CF-5C20F7F69F96@oracle.com>
Message-ID: <00a03b3b-293e-63a5-38f2-0b3bdc6c5031@oracle.com>


On 11/04/2018 11:38, Magnus Ihse Bursie wrote:
>> 11 apr. 2018 kl. 11:10 skrev Alexey Ivanov <alexey.ivanov at oracle.com>:
>>
>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>> Hi  Alexey, yes that's true .
>>>
>>>> Please remove JNIEXPORT from main():
>>>> src/java.base/share/native/launcher/main.c
>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>> I would  prefer to keep it for now .
>>> I notice  some  comments  in our SAPJVM code base  about needing  JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without  mapfiles in the past already).
>>> Maybe  that?s related to
>>>
>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>
>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>>> but I am not sure about this.
>>> So I better keep  the JNIEXPORT  for the main functions,   could be removed in another  cleanup  if really needed.
>> OK. Let them stay then.
>> Was main() exported via map files?
> Yes. You cannot remove the export of main! Since we hide symbols by default even for executables, it would not be possible to execute if the main function is not visible.

Actually it works without JNIEXPORT modifier at main function declared in
src/java.base/share/native/launcher/main.c
src/jdk.pack/share/native/unpack200/main.cpp
at least for all 64 bit platforms built at Oracle, all tier3 tests pass.

I wouldn't have suggested removing JNIEXPORT if it hadn't.

Usually main is not exported.
Yet it was exported via map files and the code snippet provided by 
Matthias hints something may break if main is not exported.

Regards,
Alexey

>   
>
> /Magnus
>
>>
>> The change looks good to me.
>>
>> Regards,
>> Alexey
>>
>>>> You can reference both yourself and me as
>>>> Contributed-by: mbaesken, aivanov
>>>> when pushing the changeset if you don't mind.
>>>>
>>> Sure .
>>>
>>> Best regards, Matthias
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Dienstag, 10. April 2018 21:34
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>>
>>>> Hi Matthias,
>>>>
>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp match. Please review :
>>>>>
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>
>>>> I've successfully built 32 bit Windows with your patch.
>>>>
>>>>
>>>> Please remove JNIEXPORT from main():
>>>> src/java.base/share/native/launcher/main.c
>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>
>>>>> With the latest webrev I could finally build jdk/jdk successfully on both win32bit and win64 bit.
>>>>>
>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>> You can reference both yourself and me as
>>>> Contributed-by: mbaesken, aivanov
>>>> when pushing the changeset if you don't mind.
>>>>
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>> Best regards, Matthias


From bhamaram at in.ibm.com  Wed Apr 11 13:18:14 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Wed, 11 Apr 2018 13:18:14 +0000
Subject: JDK 11 hotspot build fails with "Undefined symbol" on AIX
In-Reply-To: <46adf9cc3e82494390cf34bdaab20cd1@sap.com>
References: <46adf9cc3e82494390cf34bdaab20cd1@sap.com>,
 <OFCB14B7F8.20518B4B-ON0025826B.00567732-0025826B.00567784@notes.na.collabserv.com>
 <34be6dd5-5990-6705-75de-904577f145f7@oracle.com>
 <CAA-vtUy2=H8Up2fPVW6wO8_dvBmGwT=t5D4ND6+U+GTphM7XbQ@mail.gmail.com>
 <OFE5EDFE89.E6685E57-ON0025826C.001DB766-0025826C.001E2123@notes.na.collabserv.com>
 <CAA-vtUw2Eavb+POeFBR_=Kb_xDts9rjCD8RST8Ftdt5S4Cn_oQ@mail.gmail.com>
Message-ID: <OFFB1AD584.62BB961E-ON0025826C.00491493-0025826C.004914A0@notes.na.collabserv.com>

That's a good news! Thank you.

- Bhaktavatsal Reddy


-----"Langer, Christoph" <christoph.langer at sap.com> wrote: -----
To: "Thomas St?fe" <thomas.stuefe at gmail.com>, "Bhaktavatsal R Maram" <bhamaram at in.ibm.com>
From: "Langer, Christoph" <christoph.langer at sap.com>
Date: 04/11/2018 03:18PM
Cc: build-dev <build-dev at openjdk.java.net>, "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>
Subject: RE: JDK 11 hotspot build fails with "Undefined symbol" on AIX

Hi Bhaktavatsal,



As per [1], the jdk-hs repo will be closed tomorrow and finally merged with jdk. After that, only the jdk depot will continue to be active and you should not run into such type of inconsistencies any longer...



Best regards

Christoph



[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_jdk-2Ddev_2018-2DApril_001039.html&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=nX9F1w0VCbuNwcCgx1UPEm3RXQxuNKkDf4cMeidB1JU&s=gXT8ZmSNIO0RUD1rzl0EcPEcfbKfJqIpM-z2bHh_v8E&e=



> -----Original Message-----

> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-

> bounces at openjdk.java.net] On Behalf Of Thomas St?fe

> Sent: Mittwoch, 11. April 2018 07:42

> To: Bhaktavatsal R Maram <bhamaram at in.ibm.com>

> Cc: build-dev <build-dev at openjdk.java.net>; hotspot-runtime-

> dev at openjdk.java.net

> Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX

> 

> You are welcome! Glad it worked.

> 

> I work for SAP, not Oracle (SAP maintains the AIX port, among other

> things), so I do not know the details of when the two depots get synced. I

> think about once a week or so? Others may know more.

> 

> If you require a current jdk11 to work with, currently jdk-hs may be a

> better choice since we mostly work in that repo (most of our work is

> hotspot related) and build errors tend to get fixed faster than in jdk/jdk.

> However, soon this will be a non issue hopefully, since both repos will be

> merged.

> 

> Best Regards, Thomas

> 

> 

> On Wed, Apr 11, 2018 at 7:29 AM, Bhaktavatsal R Maram

> <bhamaram at in.ibm.com>

> wrote:

> 

> > Hi Thomas,

> >

> > Thank you. It worked!

> >

> > One question, hotspot source in jdk/hs and jdk/jdk won't be in sync?

> >

> > - Bhaktavatsal Reddy

> >

> >

> > -----"Thomas St?fe" <thomas.stuefe at gmail.com> wrote: -----

> > To: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-

> dev at openjdk.

> > java.net>, Bhaktavatsal R Maram <bhamaram at in.ibm.com>

> > From: "Thomas St?fe" <thomas.stuefe at gmail.com>

> > Date: 04/11/2018 09:21AM

> > Cc: build-dev <build-dev at openjdk.java.net>, David Holmes <

> > david.holmes at oracle.com>

> > Subject: Re: JDK 11 hotspot build fails with "Undefined symbol" on AIX

> >

> > Hi,

> >

> > looks like https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200302&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=nX9F1w0VCbuNwcCgx1UPEm3RXQxuNKkDf4cMeidB1JU&s=FCs7mLsNf7r2lXIjaYru6UFB4OPjL-j7ip3yP9a9sVE&e=.

> >

> > Which has been fixed already in jdk-hs. Please build from there, the

> > current tip. If you build jdk/jdk you need to apply the patch for that fix

> > manually.

> >

> > Best Regards, Thomas

> >

> > On Tue, Apr 10, 2018 at 11:50 PM, David Holmes

> <david.holmes at oracle.com>

> > wrote:

> > Hi,

> >

> >  On 11/04/2018 1:44 AM, Bhaktavatsal R Maram wrote:

> >

> >  <nothing - only an attachment was present >

> >

> >  Based on the attachment content (see below) this seems a hotspot issue

> > for the AIX/PPC folk to fix. So moving over to hotspot-runtime-dev.

> >

> >  David

> >  ------

> >

> >  ld: 0711-318 ERROR: Undefined symbols were found.

> >          The following symbols are in error:

> >   Symbol                    Inpndx  TY CL Source-File(Object-File) OR

> > Import-File{Shared-object}

> >                                RLD: Address  Section  Rld-type Referencing

> > Symbol

> >

> >  ------------------------------------------------------------

> > ----------------------------------

> >   .__ct__5frameFPlPUc       [2169]  ER PR

> /home/bhamaram/openJDK/jdk11/

> > src/hotspot/os_cpu/aix_ppc/thread_aix_ppc.cpp(/home/

> > bhamaram/openJDK/jdk11/build/aix-ppc64-normal-server-

> > release/hotspot/variant-server/libjvm/objs/thread_aix_ppc.o)

> >                                     00000028 .text    R_RBR    [1444]

> > .pd_last_frame__10JavaThreadFv

> >                                     00000044 .text    R_RBR    [1444]

> > .pd_last_frame__10JavaThreadFv

> >  ER: The return code is 8.

> >

> >

> >

> >

> >

> >





From erik.joelsson at oracle.com  Wed Apr 11 15:33:47 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 11 Apr 2018 08:33:47 -0700
Subject: RFR: JDK-8201439: Enable linux-arm-vfp-hflt profile to be configured
 with jib again
Message-ID: <155dce7b-03c6-6c6b-01f1-c94096d0a1c5@oracle.com>

While not actively maintaining the arm port, it would be nice to at 
least be able to build it inside Oracle. I discovered that with just a 
minor tweak to the jib configuration, I could get configure to work again.

Webrev: http://cr.openjdk.java.net/~erikj/8201439/webrev.01/

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

/Erik




From kevin.walls at oracle.com  Wed Apr 11 15:38:53 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 11 Apr 2018 16:38:53 +0100
Subject: [8u] RFR: 8035495: Improvements in autoconf integration AND 8035825
Message-ID: <bf2f713d-7f99-03a9-bd02-605e119d5564@oracle.com>

Hi,

I'd like to request review of this backport from 9 to 8u:

8035495: Improvements in autoconf integration
JBS: https://bugs.openjdk.java.net/browse/JDK-8035495

9 changeset:
URL:   http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
User:  ihse
Date:  2014-02-24 12:31:07 +0000

9 review thread: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011963.html


This mostly imports to 8u, but requires some manual editing as one chunk in each of common/autoconf/autogen.sh,
common/autoconf/basics.m4, and common/autoconf/configure didn't import, plus regenerating generated-configure.sh.


There was a follow-on bug which I'll apply at the same time, which was:

8035825: Warn instead of fail when calling the configure wrapper directly
JBS: https://bugs.openjdk.java.net/browse/JDK-8035825

9 changeset:
URL:   http://hg.openjdk.java.net/jdk9/dev/rev/e7872d8abd12
User:  ihse
Date:  2014-02-27 08:20:50 +0000

9 review: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011988.html

This required some manual editing just for the change at the start of common/autoconf/configure.


8u webrev with them both applied:  http://cr.openjdk.java.net/~kevinw/8035495/webrev.00/

(8035496 is committed in there, 8035825 is not)


Many thanks!
Kevin




From philip.race at oracle.com  Wed Apr 11 15:40:27 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 11 Apr 2018 08:40:27 -0700
Subject: <AWT Dev> RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <1523434677.4440.8.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
 <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>
 <1523434677.4440.8.camel@redhat.com>
Message-ID: <8c1b2b59-16f8-9507-391d-c03a06c765ec@oracle.com>

Yes, I think this should be removed for AIX as we have
done for Solaris + Linux, and I could have done that but
I also had no way to test it .. without that capability
I ran more risk of breaking AIX than fixing a problem that
apparently hasn't been seen there. I am not sure if *headful*
tests are regularly run on AIX, although email from earlier
this week from IBM offering to contribute some input method
support for AIX strongly suggests that it is of interest :-)

-phil.

On 04/11/2018 01:17 AM, Severin Gehwolf wrote:
> On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote:
>> LIBS_aix := -lawt_headless,
>> I guess that AIX team should have a similar fix.
> Possibly. I have no way of testing it, though. So will leave it to AIX
> folk to have a look. My experience was that it isn't easily
> reproducible. Some observations:
>
>     1. Run swing app such as SwingSet2 on a headfull system. Since
>        fontmanager will have a link dep on lawt_headless, and awt code
>        loads libawt_xawt (headfull) on a headfull system, both libraries
>        providing symbols needed by libfontmanager will be loaded. Then it
>        depends whether this is a problem on that particular system or not.
>        In my experience this worked on some systems and not on others.
>     2. Solaris was build-time linking to libawt_headless causing bug
>        8194870. So build-time linking got removed with that bug. Not sure
>        why that bug is private :(
>
> Thanks,
> Severin
>
>> On 10/04/2018 09:34, Erik Joelsson wrote:
>>> Looks good. Thanks!
>>>
>>> /Erik
>>>
>>>
>>> On 2018-04-10 04:25, Severin Gehwolf wrote:
>>>> Hi Erik,
>>>>
>>>> On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>>>>> Hello Severin,
>>>>>
>>>>> I'm ok with this solution for now.
>>>> Thanks for the review!
>>>>
>>>>> Could you please reduce the indentation on line 652. In the
>>>>> build system
>>>>> we like 4 spaces for continuation indent [1]
>>>> Done. New webrev at:
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0
>>>> 2
>>>>
>>>> Could someone from awt-dev have a look at this too? Thanks!
>>>>
>>>> Cheers,
>>>> Severin
>>>>
>>>>> /Erik
>>>>>
>>>>> [1] http://openjdk.java.net/groups/build/doc/code-conventions.h
>>>>> tml
>>>>>
>>>>> On 2018-04-09 06:39, Severin Gehwolf wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could somebody please review this build fix for
>>>>>> libfontmanager.so. The
>>>>>> issue for us is that with some LDFLAGS the build breaks as
>>>>>> described in
>>>>>> bug JDK-8196218. However, we cannot link to a providing
>>>>>> library at
>>>>>> build-time since we don't know which one it should be:
>>>>>> libawt_headless
>>>>>> or libawt_xawt. That has to happen at runtime. The proposed
>>>>>> fix filters
>>>>>> out relevant linker flags when libfontmanager is being built.
>>>>>> More
>>>>>> details are in the bug.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr
>>>>>> ev.01/
>>>>>>
>>>>>> Testing: I've run this through submit[1] and got the
>>>>>> following results.
>>>>>> SwingSet2 works fine for me on F27. I'm currently running
>>>>>> some more
>>>>>> tests on RHEL 7.
>>>>>>
>>>>>> ---------------------
>>>>>> Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877:
>>>>>> Builds
>>>>>> PASSED. Testing FAILURE.
>>>>>>
>>>>>> 0 Failed Tests
>>>>>>
>>>>>> Mach5 Tasks Results Summary
>>>>>>
>>>>>> NA: 0
>>>>>> UNABLE_TO_RUN: 0
>>>>>> EXECUTED_WITH_FAILURE: 0
>>>>>> KILLED: 0
>>>>>> PASSED: 82
>>>>>> FAILED: 1
>>>>>> Test
>>>>>>
>>>>>> 1 Failed
>>>>>>
>>>>>> tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-
>>>>>> windows-x64-
>>>>>> debug-31 SetupFailedException in setup...profile run-test-
>>>>>> prebuilt' ,
>>>>>> return value: 10
>>>>>> --------------------
>>>>>>
>>>>>> Not sure what this test failure means. Could somebody at
>>>>>> Oracle shed
>>>>>> some light on this?
>>>>>>
>>>>>> Thanks,
>>>>>> Severin
>>



From tim.bell at oracle.com  Wed Apr 11 16:27:12 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 11 Apr 2018 09:27:12 -0700
Subject: RFR: JDK-8201439: Enable linux-arm-vfp-hflt profile to be
 configured with jib again
In-Reply-To: <155dce7b-03c6-6c6b-01f1-c94096d0a1c5@oracle.com>
References: <155dce7b-03c6-6c6b-01f1-c94096d0a1c5@oracle.com>
Message-ID: <5ACE3760.8000400@oracle.com>

Erik:

> While not actively maintaining the arm port, it would be nice to at
> least be able to build it inside Oracle. I discovered that with just a
> minor tweak to the jib configuration, I could get configure to work again.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8201439/webrev.01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201439

Looks good.

/Tim




From magnus.ihse.bursie at oracle.com  Wed Apr 11 18:04:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Apr 2018 20:04:12 +0200
Subject: RFR: JDK-8201439: Enable linux-arm-vfp-hflt profile to be
 configured with jib again
In-Reply-To: <155dce7b-03c6-6c6b-01f1-c94096d0a1c5@oracle.com>
References: <155dce7b-03c6-6c6b-01f1-c94096d0a1c5@oracle.com>
Message-ID: <D79EC6A9-6938-439E-9B9A-4B12E9A33B4E@oracle.com>

Lgtm. 

/Magnus

> 11 apr. 2018 kl. 17:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> While not actively maintaining the arm port, it would be nice to at least be able to build it inside Oracle. I discovered that with just a minor tweak to the jib configuration, I could get configure to work again.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8201439/webrev.01/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201439
> 
> /Erik
> 
> 



From matthias.baesken at sap.com  Thu Apr 12 07:49:35 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Apr 2018 07:49:35 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <3520f157a7d14a118a584fdeb226381e@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
Message-ID: <e35231937aed4118a7cf8879965fffdf@sap.com>

Hi,  could  someone please  sponsor  the change  now ?

And  could someone please check  what happened  to the submit-repo ?
Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no  response   so far .
Maybe  the submit repo  is not working currently  ,  not sure  about it .


Best regards , Matthias




> -----Original Message-----
> From: Baesken, Matthias
> Sent: Mittwoch, 11. April 2018 11:20
> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> <martin.doerr at sap.com>
> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> >
> > Was main() exported via map files?
> >
> 
> Seems main was exported , I can find it in jdk10  in  e.g.  :
> 
> make/mapfiles/launchers/mapfile-sparcv9
> make/mapfiles/launchers/mapfile-x86_64
> 
> 
> Best regards, Matthias
> 
> 
> > -----Original Message-----
> > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> > Sent: Mittwoch, 11. April 2018 11:11
> > To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> > <magnus.ihse.bursie at oracle.com>
> > Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> > <martin.doerr at sap.com>
> > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> > declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> > some places in function declarations/implementations
> >
> >
> > On 11/04/2018 08:44, Baesken, Matthias wrote:
> > >> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> > > Hi  Alexey, yes that's true .
> > >
> > >> Please remove JNIEXPORT from main():
> > >> src/java.base/share/native/launcher/main.c
> > >> src/jdk.pack/share/native/unpack200/main.cpp
> > > I would  prefer to keep it for now .
> > > I notice  some  comments  in our SAPJVM code base  about needing
> > JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
> > mapfiles in the past already).
> > > Maybe  that?s related to
> > >
> > > src/java.base/unix/native/libjli/java_md_solinux.c
> > >
> > > where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
> > > but I am not sure about this.
> > > So I better keep  the JNIEXPORT  for the main functions,   could be
> > removed in another  cleanup  if really needed.
> >
> > OK. Let them stay then.
> > Was main() exported via map files?
> >
> >
> > The change looks good to me.
> >
> > Regards,
> > Alexey
> >
> > >
> > >> You can reference both yourself and me as
> > >> Contributed-by: mbaesken, aivanov
> > >> when pushing the changeset if you don't mind.
> > >>
> > > Sure .
> > >
> > > Best regards, Matthias
> > >
> > >
> > >> -----Original Message-----
> > >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> > >> Sent: Dienstag, 10. April 2018 21:34
> > >> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> > Bursie
> > >> <magnus.ihse.bursie at oracle.com>
> > >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> > >> <martin.doerr at sap.com>
> > >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> > function
> > >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> at
> > >> some places in function declarations/implementations
> > >>
> > >> Hi Matthias,
> > >>
> > >> On 10/04/2018 11:14, Baesken, Matthias wrote:
> > >>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
> > match. Please review :
> > >>>
> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> > >> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> > >>
> > >> I've successfully built 32 bit Windows with your patch.
> > >>
> > >>
> > >> Please remove JNIEXPORT from main():
> > >> src/java.base/share/native/launcher/main.c
> > >> src/jdk.pack/share/native/unpack200/main.cpp
> > >>
> > >>> With the latest webrev I could finally build jdk/jdk successfully on both
> > win32bit and win64 bit.
> > >>>
> > >>> Thanks again  to Alexey  to provide  the   incorporated patch .
> > >> You can reference both yourself and me as
> > >> Contributed-by: mbaesken, aivanov
> > >> when pushing the changeset if you don't mind.
> > >>
> > >>
> > >> Regards,
> > >> Alexey
> > >>
> > >>>
> > >>> Best regards, Matthias
> > >>>
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> > >>>> Sent: Montag, 9. April 2018 17:14
> > >>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> > >> Bursie
> > >>>> <magnus.ihse.bursie at oracle.com>
> > >>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> > >>>> <martin.doerr at sap.com>
> > >>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> > >> function
> > >>>> declarations/implementations - was : RE: missing JNIEXPORT /
> JNICALL
> > at
> > >>>> some places in function declarations/implementations
> > >>>>
> > >>>> Hi Matthias,
> > >>>>
> > >>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
> > >>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
> > >> explanations
> > >>>> .
> > >>>>> I created  a second  webrev :
> > >>>>>
> > >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> > >>>>>
> > >>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
> > >>>> Yes, that's fine with me.
> > >>>> There could be only one author ;)
> > >>>>
> > >>>>> -    changes  2 launchers
> src/java.base/share/native/launcher/main.c
> > >> and
> > >>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
> > similar
> > >>>> issues after mapfile removal for exes
> > >>>>
> > >>>> I'd rather remove both JNIEXPORT and JNICALL from main().
> > >>>> It wasn't exported, and it shouldn't be.
> > >>>>
> > >>>> Regards,
> > >>>> Alexey
> > >>>>
> > >>>>> Best regards , Matthias


From aph at redhat.com  Thu Apr 12 09:15:44 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Apr 2018 10:15:44 +0100
Subject: slowproduct build
In-Reply-To: <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
 <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
 <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>
 <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>
Message-ID: <9b15d453-2669-cc2c-8500-5e33eccb4eaf@redhat.com>

On 04/10/2018 10:21 PM, Magnus Ihse Bursie wrote:
> So you want to have a way to force -O0 for all compiled files? Something 
> like "bash configure --with-debug-level=release 
> --with-optimization=none", or possibly "make OPTIMIZATION=NONE"?
> 
> Or are you happy with the optimization level of a slowdebug build, and 
> only want to adjust the value of PRODUCT and ASSERT for hotspot to match 
> what's done for a release build? Something like "bash configure 
> --enable-hotspot-product-build"?

I tell you what would be super cool: a way to turn off all of the JIT-
generated assertion code without also turning off ASSERT.  Then you could
read the JIT-generated code in a debug build.  I guess it would be no
more than a matter of finding every #ifdef ASSERT and replacing it with
ASM_ASSERT or somesuch,

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alexey.ivanov at oracle.com  Thu Apr 12 10:12:29 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 12 Apr 2018 11:12:29 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <e35231937aed4118a7cf8879965fffdf@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
Message-ID: <3214002b-0892-0ab7-7bca-958483e89108@oracle.com>

Hi Matthias,

On 12/04/2018 08:49, Baesken, Matthias wrote:
> Hi,  could  someone please  sponsor  the change  now ?

According to OpenJDK Census page [1], you have committer rights to JDK 
project.

> And  could someone please check  what happened  to the submit-repo ?
> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no  response   so far .
> Maybe  the submit repo  is not working currently  ,  not sure  about it .

I can your push to submit repo on 10 Apr 2018 08:38:56 +0200.
However, I'm not sure where the build and test job is run. I couldn't 
find it.

Anyway, I've just submitted a build job with your changeset and am 
running 32 bit Windows build.

Regards,
Alexey

[1] http://openjdk.java.net/census#mbaesken

>
>
> Best regards , Matthias
>
>
>
>
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Mittwoch, 11. April 2018 11:20
>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>>> Was main() exported via map files?
>>>
>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>>
>> make/mapfiles/launchers/mapfile-sparcv9
>> make/mapfiles/launchers/mapfile-x86_64
>>
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Mittwoch, 11. April 2018 11:11
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>
>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>> Hi  Alexey, yes that's true .
>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>> I would  prefer to keep it for now .
>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
>>> mapfiles in the past already).
>>>> Maybe  that?s related to
>>>>
>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>
>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>>>> but I am not sure about this.
>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>> removed in another  cleanup  if really needed.
>>>
>>> OK. Let them stay then.
>>> Was main() exported via map files?
>>>
>>>
>>> The change looks good to me.
>>>
>>> Regards,
>>> Alexey
>>>
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>> Sure .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>> at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
>>> match. Please review :
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>
>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>
>>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>
>>>>>> With the latest webrev I could finally build jdk/jdk successfully on both
>>> win32bit and win64 bit.
>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>> JNICALL
>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>> explanations
>>>>>>> .
>>>>>>>> I created  a second  webrev :
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>
>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>> Yes, that's fine with me.
>>>>>>> There could be only one author ;)
>>>>>>>
>>>>>>>> -    changes  2 launchers
>> src/java.base/share/native/launcher/main.c
>>>>> and
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>> similar
>>>>>>> issues after mapfile removal for exes
>>>>>>>
>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>>> Best regards , Matthias



From Alan.Bateman at oracle.com  Thu Apr 12 10:53:42 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Apr 2018 11:53:42 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <9bae15f406ed4e029233415e6a8032b8@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
Message-ID: <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>

Adding core-libs-dev as this is change code in libjava, libzip, 
libjimage, ...

Can you confirm that this is the up to date webrev:
 ?? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/

As I read it, this changes the calling convention of these functions on 
32-bit Windows but it will have no impact on 64-bit Windows (as 
__stdcall is ignored) or other platforms, is that correct?

-Alan


On 06/04/2018 14:20, Baesken, Matthias wrote:
> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>
>
>    1.  The   follow up change  that removed   mapfiles for  exes  as well    leads on Win32 bit  to  this link error :
>
>    Creating library C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : fatal error LNK1120: 1 unresolved externals
>
>
> Looks like we  cannot have   JNICALL   in main.c   :
>
> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04 2018 -0700
> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40 2018 +0200
> @@ -93,7 +93,7 @@
>       __initenv = _environ;
>
> #else /* JAVAW */
> -JNIEXPORT int JNICALL
> +JNIEXPORT int
> main(int argc, char **argv)
> {
>       int margc;
>
>
>
>    1.  Zip-library  has runtime issues   when  symbols  are resolved  in  src/hotspot/share/classfile/classLoader.cpp.
>
> I added  the declaration of the missing symbol, this seems to fix it .
>
>
> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04 2018 -0700
> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40 2018 +0200
> @@ -284,4 +284,7 @@
> JNIEXPORT jboolean JNICALL
> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char **pmsg);
>
> +JNIEXPORT jint JNICALL
> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> +
>
>
> Should I  prepare  another  bug,  or  add this to the existing one and    post a second webrev ?
>
> Best regards, Matthias
>
>
> From: Baesken, Matthias
> Sent: Freitag, 6. April 2018 09:54
> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>
> Hello, please review :
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8201226
>
> change :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>
> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit build missed it .
>
> A difference is  src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> Where I removed   a few  declarations  (one  decl   with one without  JNIEXPORT / JNICALL ? looked a bit strange ) .
>
> Best regards , Matthias
>
>
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> Sent: Donnerstag, 5. April 2018 17:45
> To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
> Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
> Subject: Re: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
>
> That's most likely a result of the new JNIEXPORT I added as part of the mapfile removal.
>
> I tried to match header file and C file, but I can certainly have missed cases. If I didn't get any warnings, it was hard to know what I missed.
>
> Please do submit your patch.
>
> I'm a bit surprised 32-bit Window is still buildable. :)
>
> /Magnus
>
> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
> Hello, we noticed  that  at a number  of places in the coding  ,   the  JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares  the declaration and
> The implementation of functions.
> While this is ok on most platforms, it seems to fail on Windows 32 bit and leads to errors like this one :
>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageConvKernelConvert.c(87) : error C2373: 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>          e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\mlib_image_proto.h(2630) : see declaration of 'j2d_mlib_ImageConvKernelConvert'
>
> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>
>
> Another example is this one :
>
> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16 2018 +0200
> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05 17:07:40 2018 +0200
> @@ -126,7 +126,7 @@
>    *   JImageLocationRef location = (*JImageFindResource)(image,
>    *                                "java.base", "9.0", "java/lang/String.class", &size);
>    */
> -extern "C" JNIEXPORT JImageLocationRef JIMAGE_FindResource(JImageFile* jimage,
> +extern "C" JNIEXPORT JImageLocationRef JNICALL JIMAGE_FindResource(JImageFile* jimage,
>           const char* module_name, const char* version, const char* name,
>           jlong* size);
>
>
> Is there some generic way to get  the  same  declarations / impementations   in the code  ?
>
> Or should I just add a patch with my findings ?
>
> Best regards, Matthias
>



From matthias.baesken at sap.com  Thu Apr 12 11:04:53 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Apr 2018 11:04:53 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
Message-ID: <7c5e68c2a023490e96ce6452fbda1700@sap.com>

Hi  Alan , this is the up to date webrev .
However we want to add   Alexey   Ivanov  as additional  author .

> 
> As I read it, this changes the calling convention of these functions on
> 32-bit Windows but it will have no impact on 64-bit Windows (as
> __stdcall is ignored) or other platforms, is that correct?
>

The  change adds  JNIEXPORT   at some places  where it is  ben forgotten , for example :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html

This might have  potential  impact  on other platforms   (fixes  the mismatches) .

Best regards, Matthias




> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Donnerstag, 12. April 2018 12:54
> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>
> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>;
> core-libs-dev at openjdk.java.net
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Adding core-libs-dev as this is change code in libjava, libzip,
> libjimage, ...
> 
> Can you confirm that this is the up to date webrev:
>  ?? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> 
> As I read it, this changes the calling convention of these functions on
> 32-bit Windows but it will have no impact on 64-bit Windows (as
> __stdcall is ignored) or other platforms, is that correct?
> 
> -Alan
> 
> 
> On 06/04/2018 14:20, Baesken, Matthias wrote:
> > Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> >
> >
> >    1.  The   follow up change  that removed   mapfiles for  exes  as well
> leads on Win32 bit  to  this link error :
> >
> >    Creating library
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> > LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> referenced in function ___tmainCRTStartup
> > C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
> fatal error LNK1120: 1 unresolved externals
> >
> >
> > Looks like we  cannot have   JNICALL   in main.c   :
> >
> > diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> > --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04
> 2018 -0700
> > +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40
> 2018 +0200
> > @@ -93,7 +93,7 @@
> >       __initenv = _environ;
> >
> > #else /* JAVAW */
> > -JNIEXPORT int JNICALL
> > +JNIEXPORT int
> > main(int argc, char **argv)
> > {
> >       int margc;
> >
> >
> >
> >    1.  Zip-library  has runtime issues   when  symbols  are resolved  in
> src/hotspot/share/classfile/classLoader.cpp.
> >
> > I added  the declaration of the missing symbol, this seems to fix it .
> >
> >
> > diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> > --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
> 2018 -0700
> > +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
> 2018 +0200
> > @@ -284,4 +284,7 @@
> > JNIEXPORT jboolean JNICALL
> > ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
> **pmsg);
> >
> > +JNIEXPORT jint JNICALL
> > +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> > +
> >
> >
> > Should I  prepare  another  bug,  or  add this to the existing one and    post a
> second webrev ?
> >
> > Best regards, Matthias
> >
> >
> > From: Baesken, Matthias
> > Sent: Freitag, 6. April 2018 09:54
> > To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> > Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> > Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
> function declarations/implementations - was : RE: missing JNIEXPORT /
> JNICALL at some places in function declarations/implementations
> >
> > Hello, please review :
> >
> > Bug :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8201226
> >
> > change :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >
> > mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit
> build missed it .
> >
> > A difference is
> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> > Where I removed   a few  declarations  (one  decl   with one without
> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >
> > Best regards , Matthias
> >
> >
> > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> > Sent: Donnerstag, 5. April 2018 17:45
> > To: Baesken, Matthias
> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
> > Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>;
> Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
> > Subject: Re: missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations
> >
> > That's most likely a result of the new JNIEXPORT I added as part of the
> mapfile removal.
> >
> > I tried to match header file and C file, but I can certainly have missed cases.
> If I didn't get any warnings, it was hard to know what I missed.
> >
> > Please do submit your patch.
> >
> > I'm a bit surprised 32-bit Window is still buildable. :)
> >
> > /Magnus
> >
> > 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
> > Hello, we noticed  that  at a number  of places in the coding  ,   the
> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
> the declaration and
> > The implementation of functions.
> > While this is ok on most platforms, it seems to fail on Windows 32 bit and
> leads to errors like this one :
> >
> >
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> ib_ImageConvKernelConvert.c(87) : error C2373:
> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
> >
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> ib_image_proto.h(2630) : see declaration of
> 'j2d_mlib_ImageConvKernelConvert'
> >
> > (there are quite a few of these e.g. in mlib  / splashscreen etc.)
> >
> >
> > Another example is this one :
> >
> > diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> > --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16
> 2018 +0200
> > +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05
> 17:07:40 2018 +0200
> > @@ -126,7 +126,7 @@
> >    *   JImageLocationRef location = (*JImageFindResource)(image,
> >    *                                "java.base", "9.0", "java/lang/String.class", &size);
> >    */
> > -extern "C" JNIEXPORT JImageLocationRef
> JIMAGE_FindResource(JImageFile* jimage,
> > +extern "C" JNIEXPORT JImageLocationRef JNICALL
> JIMAGE_FindResource(JImageFile* jimage,
> >           const char* module_name, const char* version, const char* name,
> >           jlong* size);
> >
> >
> > Is there some generic way to get  the  same  declarations / impementations
> in the code  ?
> >
> > Or should I just add a patch with my findings ?
> >
> > Best regards, Matthias
> >


From magnus.ihse.bursie at oracle.com  Thu Apr 12 11:39:20 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 13:39:20 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
Message-ID: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>

It is currently easy to add new JVM features to the JVM build, but it is 
not possible to remove features.

With this change, features can be both added or removed from the default 
set. They are added using --with-jvm-features=f1,f2 and removed using 
--with-jvm-features=-f1,-f2. The syntax can be combined, so 
--with-jvm-features=dtrace,-nmt will enable dtrace but disable native 
memory tracking.

I also included some additional code cleanup and fixes, such as printing 
the JVM feature set at the summary.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01



From magnus.ihse.bursie at oracle.com  Thu Apr 12 12:03:36 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 14:03:36 +0200
Subject: slowproduct build
In-Reply-To: <3965ce5f-9121-54a8-9c7a-2f624c943612@oracle.com>
References: <36d8f607-2100-1bdb-de2a-d52a19781fcb@oracle.com>
 <7b409dfe-cca9-0fd5-9b56-1ab6a80270a8@oracle.com>
 <CAA-vtUyogvWp95ECBwbELN6KOpDawkKZSoMfmRBTHDPN1ONDFg@mail.gmail.com>
 <A2684734-53F4-4697-AED4-198B7CEE9011@oracle.com>
 <f265dc9b-ed69-2af0-7058-273a215ce4d0@oracle.com>
 <3965ce5f-9121-54a8-9c7a-2f624c943612@oracle.com>
Message-ID: <e744686c-c527-d169-e3cd-38034cdec9f8@oracle.com>

On 2018-04-11 07:12, Ioi Lam wrote:
>
>
>
> On 4/10/18 2:21 PM, Magnus Ihse Bursie wrote:
>>
>> On 2018-04-10 23:08, Ioi Lam wrote:
>>> Yes that?s what I want.
>>>
>>> Yesterday I was using gdb to step into the interpreter generation 
>>> code to see what?s generated for a particular routine for 
>>> MethodHandles. The debug build contains a LOT of runtime 
>>> verification code in the generated code and I couldn?t figure out 
>>> what?s happening. The product build just generates 10 instructions.
>> So you want to have a way to force -O0 for all compiled files? 
>> Something like "bash configure --with-debug-level=release 
>> --with-optimization=none", or possibly "make OPTIMIZATION=NONE"?
>>
> Hi Magnus,
>
> I like the --with-optimization=none flag. This doesn't seem to exist 
> yet. Any plans to add it?

Yes, it does not exist yet. :) I'm trying out various scenarios here to 
understand what you need and how we can fix it.

I have opened https://bugs.openjdk.java.net/browse/JDK-8201485, however 
to be frank, it is of quite low priority (infrequence and odd use case, 
workaround exists) so I assume it will take a while before I or anyone 
else comes around to it.

/Magnus


>
> The way I would use it is:
>
> ??? bash configure --with-debug-level=product --with-optimization=none
>
> Thanks
> - Ioi
>
>> Or are you happy with the optimization level of a slowdebug build, 
>> and only want to adjust the value of PRODUCT and ASSERT for hotspot 
>> to match what's done for a release build? Something like "bash 
>> configure --enable-hotspot-product-build"?
>>
>> /Magnus
>>
>>>
>>> Thanks
>>> Ioi
>>>
>>> On Apr 10, 2018, at 1:47 PM, Thomas St?fe <thomas.stuefe at gmail.com 
>>> <mailto:thomas.stuefe at gmail.com>> wrote:
>>>
>>>> If I understand Ioi correctly, he wants a build with PRODUCT and 
>>>> !ASSERT but with debug symbols and no optimizations? So, no 
>>>> assertions and all switches with product defaults?
>>>>
>>>> I can see that this could make sense in certain scenarios.
>>>>
>>>> ..Thomas
>>>>
>>>> On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie 
>>>> <magnus.ihse.bursie at oracle.com 
>>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>>>
>>>>     On 2018-04-10 02:00, Ioi Lam wrote:
>>>>
>>>>         Sometimes I want to debug the product build (I can't bother
>>>>         with turning off all the trueInDebug options in the hotspot
>>>>         globals.hpp). The only way that I have found to do this is:
>>>>
>>>>         ??? configure --with-native-debug-symbols=internal
>>>>         ??? mv spec.gmk spec.gmk.old
>>>>         ??? cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk
>>>>
>>>>         Is there (or should there be) a more elegant way to do it,
>>>>         like "configure --with-debug-level=slowproduct" :-)
>>>>
>>>>     I'm not entirely sure of what you want to achieve.
>>>>
>>>>     As I interepret your snippet above, you want no optimization
>>>>     and internal debug symbols..? How is that debugging a "product"
>>>>     build?
>>>>
>>>>     /Magnus
>>>>
>>>>
>>>>         Thanks
>>>>         - Ioi
>>>>
>>>>
>>>>
>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr 12 12:05:13 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 14:05:13 +0200
Subject: [8u] RFR: 8035495: Improvements in autoconf integration AND
 8035825
In-Reply-To: <bf2f713d-7f99-03a9-bd02-605e119d5564@oracle.com>
References: <bf2f713d-7f99-03a9-bd02-605e119d5564@oracle.com>
Message-ID: <fb316b4e-e044-bc3b-9053-e57df377fea6@oracle.com>

Looks good to me.

/Magnus

On 2018-04-11 17:38, Kevin Walls wrote:
> Hi,
>
> I'd like to request review of this backport from 9 to 8u:
>
> 8035495: Improvements in autoconf integration
> JBS: https://bugs.openjdk.java.net/browse/JDK-8035495
>
> 9 changeset:
> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
> User:? ihse
> Date:? 2014-02-24 12:31:07 +0000
>
> 9 review thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011963.html
>
>
> This mostly imports to 8u, but requires some manual editing as one 
> chunk in each of common/autoconf/autogen.sh,
> common/autoconf/basics.m4, and common/autoconf/configure didn't 
> import, plus regenerating generated-configure.sh.
>
>
> There was a follow-on bug which I'll apply at the same time, which was:
>
> 8035825: Warn instead of fail when calling the configure wrapper directly
> JBS: https://bugs.openjdk.java.net/browse/JDK-8035825
>
> 9 changeset:
> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/e7872d8abd12
> User:? ihse
> Date:? 2014-02-27 08:20:50 +0000
>
> 9 review: 
> http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011988.html
>
> This required some manual editing just for the change at the start of 
> common/autoconf/configure.
>
>
> 8u webrev with them both applied: 
> http://cr.openjdk.java.net/~kevinw/8035495/webrev.00/
>
> (8035496 is committed in there, 8035825 is not)
>
>
> Many thanks!
> Kevin
>
>



From kevin.walls at oracle.com  Thu Apr 12 12:07:55 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 12 Apr 2018 13:07:55 +0100
Subject: [8u] RFR: 8035495: Improvements in autoconf integration AND
 8035825
In-Reply-To: <fb316b4e-e044-bc3b-9053-e57df377fea6@oracle.com>
References: <bf2f713d-7f99-03a9-bd02-605e119d5564@oracle.com>
 <fb316b4e-e044-bc3b-9053-e57df377fea6@oracle.com>
Message-ID: <68d6c6a6-8891-33f3-ccba-38f28e22f1a1@oracle.com>

Thanks Magnus.?? I'll also be doing the related 8035730.? That's a clean 
backport so will go straight to 8u-dev group.

Thanks
Kevin


On 12/04/2018 13:05, Magnus Ihse Bursie wrote:
> Looks good to me.
>
> /Magnus
>
> On 2018-04-11 17:38, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to request review of this backport from 9 to 8u:
>>
>> 8035495: Improvements in autoconf integration
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8035495
>>
>> 9 changeset:
>> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4
>> User:? ihse
>> Date:? 2014-02-24 12:31:07 +0000
>>
>> 9 review thread: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011963.html
>>
>>
>> This mostly imports to 8u, but requires some manual editing as one 
>> chunk in each of common/autoconf/autogen.sh,
>> common/autoconf/basics.m4, and common/autoconf/configure didn't 
>> import, plus regenerating generated-configure.sh.
>>
>>
>> There was a follow-on bug which I'll apply at the same time, which was:
>>
>> 8035825: Warn instead of fail when calling the configure wrapper 
>> directly
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8035825
>>
>> 9 changeset:
>> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/e7872d8abd12
>> User:? ihse
>> Date:? 2014-02-27 08:20:50 +0000
>>
>> 9 review: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2014-February/011988.html
>>
>> This required some manual editing just for the change at the start of 
>> common/autoconf/configure.
>>
>>
>> 8u webrev with them both applied: 
>> http://cr.openjdk.java.net/~kevinw/8035495/webrev.00/
>>
>> (8035496 is committed in there, 8035825 is not)
>>
>>
>> Many thanks!
>> Kevin
>>
>>
>



From thomas.stuefe at gmail.com  Thu Apr 12 12:11:39 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 14:11:39 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
Message-ID: <CAA-vtUyF_f4SUDTSP1qoc3-sku6h7pnm8cmVSnv9wtgRmxub+g@mail.gmail.com>

Hi Magnus,

this is nice. I would like a clearer naming though, that single dash
is easily overlooked. How about --without-jvm-features instead?

..Thomas

On Thu, Apr 12, 2018 at 1:39 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> It is currently easy to add new JVM features to the JVM build, but it is not
> possible to remove features.
>
> With this change, features can be both added or removed from the default
> set. They are added using --with-jvm-features=f1,f2 and removed using
> --with-jvm-features=-f1,-f2. The syntax can be combined, so
> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory
> tracking.
>
> I also included some additional code cleanup and fixes, such as printing the
> JVM feature set at the summary.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>


From david.holmes at oracle.com  Thu Apr 12 12:15:31 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Apr 2018 22:15:31 +1000
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
Message-ID: <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>

Hi Magnus,

On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
> It is currently easy to add new JVM features to the JVM build, but it is 
> not possible to remove features.
> 
> With this change, features can be both added or removed from the default 
> set. They are added using --with-jvm-features=f1,f2 and removed using 
> --with-jvm-features=-f1,-f2. The syntax can be combined, so 
> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native 
> memory tracking.

I need to point out that we have never tested disabling individual VM 
features likes this. They are either all on, or all off for the minimal 
VM! There may be implicit dependencies between features.

David

> I also included some additional code cleanup and fixes, such as printing 
> the JVM feature set at the summary.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
> 


From alexey.ivanov at oracle.com  Thu Apr 12 12:25:34 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 12 Apr 2018 13:25:34 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <3214002b-0892-0ab7-7bca-958483e89108@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <3214002b-0892-0ab7-7bca-958483e89108@oracle.com>
Message-ID: <a2b33610-62f3-dfee-8ef7-0719d3c6605e@oracle.com>

Hi Matthias,

On 12/04/2018 11:12, Alexey Ivanov wrote:
> Hi Matthias,
>
> On 12/04/2018 08:49, Baesken, Matthias wrote:
>> Hi,? could? someone please? sponsor? the change? now ?
>
> According to OpenJDK Census page [1], you have committer rights to JDK 
> project.
>
>> And? could someone please check? what happened? to the submit-repo ?
>> Yesterday I pushed to? the submit repo? to?? check my? change ,? but? 
>> no? response?? so far .
>> Maybe? the submit repo? is not working currently? ,? not sure about it .
>
> I can your push to submit repo on 10 Apr 2018 08:38:56 +0200.
> However, I'm not sure where the build and test job is run. I couldn't 
> find it.
>
> Anyway, I've just submitted a build job with your changeset and am 
> running 32 bit Windows build.

The build job is successful: no failures found.
My local 32 bit Windows build is also fine.
I successfully ran SwingSet2 and Java2Demo with it.


I guess we're waiting for approval from core-libs.

Regards,
Alexey

>
>
> Regards,
> Alexey
>
> [1] http://openjdk.java.net/census#mbaesken
>
>>
>> Best regards , Matthias
>>


From christian.tornqvist at oracle.com  Thu Apr 12 12:58:17 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 12 Apr 2018 08:58:17 -0400
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <e35231937aed4118a7cf8879965fffdf@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
Message-ID: <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>

Hi Matthias,


> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi,  could  someone please  sponsor  the change  now ?
> 
> And  could someone please check  what happened  to the submit-repo ?
> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no  response   so far .
> Maybe  the submit repo  is not working currently  ,  not sure  about it .

Your submit job ran without failures, we were doing maintenance on the jdk-submit repo yesterday and had turned off notifications. Sorry for the inconvenience.

Thanks,
Christian
> 
> 
> Best regards , Matthias
> 
> 
> 
> 
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Mittwoch, 11. April 2018 11:20
>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>>> 
>>> Was main() exported via map files?
>>> 
>> 
>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>> 
>> make/mapfiles/launchers/mapfile-sparcv9
>> make/mapfiles/launchers/mapfile-x86_64
>> 
>> 
>> Best regards, Matthias
>> 
>> 
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Mittwoch, 11. April 2018 11:11
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>> 
>>> 
>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>> Hi  Alexey, yes that's true .
>>>> 
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>> I would  prefer to keep it for now .
>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
>>> mapfiles in the past already).
>>>> Maybe  that?s related to
>>>> 
>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>> 
>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>>>> but I am not sure about this.
>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>> removed in another  cleanup  if really needed.
>>> 
>>> OK. Let them stay then.
>>> Was main() exported via map files?
>>> 
>>> 
>>> The change looks good to me.
>>> 
>>> Regards,
>>> Alexey
>>> 
>>>> 
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>> 
>>>> Sure .
>>>> 
>>>> Best regards, Matthias
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>> at
>>>>> some places in function declarations/implementations
>>>>> 
>>>>> Hi Matthias,
>>>>> 
>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
>>> match. Please review :
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>> 
>>>>> I've successfully built 32 bit Windows with your patch.
>>>>> 
>>>>> 
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>> 
>>>>>> With the latest webrev I could finally build jdk/jdk successfully on both
>>> win32bit and win64 bit.
>>>>>> 
>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Alexey
>>>>> 
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>> JNICALL
>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>> 
>>>>>>> Hi Matthias,
>>>>>>> 
>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>> explanations
>>>>>>> .
>>>>>>>> I created  a second  webrev :
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>> 
>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>> Yes, that's fine with me.
>>>>>>> There could be only one author ;)
>>>>>>> 
>>>>>>>> -    changes  2 launchers
>> src/java.base/share/native/launcher/main.c
>>>>> and
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>> similar
>>>>>>> issues after mapfile removal for exes
>>>>>>> 
>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>> 
>>>>>>>> Best regards , Matthias
> 



From matthias.baesken at sap.com  Thu Apr 12 13:07:48 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Apr 2018 13:07:48 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>
Message-ID: <4007f78bf6c44e0e9a6b96671493b22c@sap.com>

> Your submit job ran without failures, we were doing maintenance on the jdk-
> submit repo yesterday and had turned off notifications. Sorry for the
> inconvenience.

Hi Christian , Thanks for  the information about the submit job success.

Is there a way  to check (e.g. webpage)  that a submit job has "arrived"  and is queued for   build/test  ?
Would have been helpful  in this situation .

Best regards, Matthias


> -----Original Message-----
> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com]
> Sent: Donnerstag, 12. April 2018 14:58
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com>; build-dev <build-
> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias,
> 
> 
> > On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> >
> > Hi,  could  someone please  sponsor  the change  now ?
> >
> > And  could someone please check  what happened  to the submit-repo ?
> > Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no
> response   so far .
> > Maybe  the submit repo  is not working currently  ,  not sure  about it .
> 
> Your submit job ran without failures, we were doing maintenance on the jdk-
> submit repo yesterday and had turned off notifications. Sorry for the
> inconvenience.
> 
> Thanks,
> Christian
> >
> >
> > Best regards , Matthias
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Baesken, Matthias
> >> Sent: Mittwoch, 11. April 2018 11:20
> >> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
> >> <magnus.ihse.bursie at oracle.com>
> >> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >> <martin.doerr at sap.com>
> >> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >>>
> >>> Was main() exported via map files?
> >>>
> >>
> >> Seems main was exported , I can find it in jdk10  in  e.g.  :
> >>
> >> make/mapfiles/launchers/mapfile-sparcv9
> >> make/mapfiles/launchers/mapfile-x86_64
> >>
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> -----Original Message-----
> >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >>> Sent: Mittwoch, 11. April 2018 11:11
> >>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> Bursie
> >>> <magnus.ihse.bursie at oracle.com>
> >>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >>> <martin.doerr at sap.com>
> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >> function
> >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >>> some places in function declarations/implementations
> >>>
> >>>
> >>> On 11/04/2018 08:44, Baesken, Matthias wrote:
> >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> >>>> Hi  Alexey, yes that's true .
> >>>>
> >>>>> Please remove JNIEXPORT from main():
> >>>>> src/java.base/share/native/launcher/main.c
> >>>>> src/jdk.pack/share/native/unpack200/main.cpp
> >>>> I would  prefer to keep it for now .
> >>>> I notice  some  comments  in our SAPJVM code base  about needing
> >>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
> >>> mapfiles in the past already).
> >>>> Maybe  that?s related to
> >>>>
> >>>> src/java.base/unix/native/libjli/java_md_solinux.c
> >>>>
> >>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT,
> "main");
> >>>> but I am not sure about this.
> >>>> So I better keep  the JNIEXPORT  for the main functions,   could be
> >>> removed in another  cleanup  if really needed.
> >>>
> >>> OK. Let them stay then.
> >>> Was main() exported via map files?
> >>>
> >>>
> >>> The change looks good to me.
> >>>
> >>> Regards,
> >>> Alexey
> >>>
> >>>>
> >>>>> You can reference both yourself and me as
> >>>>> Contributed-by: mbaesken, aivanov
> >>>>> when pushing the changeset if you don't mind.
> >>>>>
> >>>> Sure .
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >>>>> Sent: Dienstag, 10. April 2018 21:34
> >>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> >>> Bursie
> >>>>> <magnus.ihse.bursie at oracle.com>
> >>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >>>>> <martin.doerr at sap.com>
> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function
> >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
> >> at
> >>>>> some places in function declarations/implementations
> >>>>>
> >>>>> Hi Matthias,
> >>>>>
> >>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
> >>>>>> Hello,  I  had to  do another small adjustment to make
> jimage.hpp/cpp
> >>> match. Please review :
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
> >>>>>
> >>>>> I've successfully built 32 bit Windows with your patch.
> >>>>>
> >>>>>
> >>>>> Please remove JNIEXPORT from main():
> >>>>> src/java.base/share/native/launcher/main.c
> >>>>> src/jdk.pack/share/native/unpack200/main.cpp
> >>>>>
> >>>>>> With the latest webrev I could finally build jdk/jdk successfully on
> both
> >>> win32bit and win64 bit.
> >>>>>>
> >>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
> >>>>> You can reference both yourself and me as
> >>>>> Contributed-by: mbaesken, aivanov
> >>>>> when pushing the changeset if you don't mind.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Alexey
> >>>>>
> >>>>>>
> >>>>>> Best regards, Matthias
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> >>>>>>> Sent: Montag, 9. April 2018 17:14
> >>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus
> Ihse
> >>>>> Bursie
> >>>>>>> <magnus.ihse.bursie at oracle.com>
> >>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
> >>>>>>> <martin.doerr at sap.com>
> >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>>>> function
> >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
> >> JNICALL
> >>> at
> >>>>>>> some places in function declarations/implementations
> >>>>>>>
> >>>>>>> Hi Matthias,
> >>>>>>>
> >>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
> >>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
> >>>>> explanations
> >>>>>>> .
> >>>>>>>> I created  a second  webrev :
> >>>>>>>>
> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
> >>>>>>>>
> >>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
> >>>>>>> Yes, that's fine with me.
> >>>>>>> There could be only one author ;)
> >>>>>>>
> >>>>>>>> -    changes  2 launchers
> >> src/java.base/share/native/launcher/main.c
> >>>>> and
> >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
> >>> similar
> >>>>>>> issues after mapfile removal for exes
> >>>>>>>
> >>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
> >>>>>>> It wasn't exported, and it shouldn't be.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Alexey
> >>>>>>>
> >>>>>>>> Best regards , Matthias
> >


From christian.tornqvist at oracle.com  Thu Apr 12 13:12:10 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 12 Apr 2018 09:12:10 -0400
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <4007f78bf6c44e0e9a6b96671493b22c@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>
 <4007f78bf6c44e0e9a6b96671493b22c@sap.com>
Message-ID: <A24347C6-A214-4F54-A494-BAB8A7938A89@oracle.com>



> On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> Your submit job ran without failures, we were doing maintenance on the jdk-
>> submit repo yesterday and had turned off notifications. Sorry for the
>> inconvenience.
> 
> Hi Christian , Thanks for  the information about the submit job success.
> 
> Is there a way  to check (e.g. webpage)  that a submit job has "arrived"  and is queued for   build/test  ?

Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help?

Thanks,
Christian

> Would have been helpful  in this situation .
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com]
>> Sent: Donnerstag, 12. April 2018 14:58
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>; build-dev <build-
>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Hi Matthias,
>> 
>> 
>>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> Hi,  could  someone please  sponsor  the change  now ?
>>> 
>>> And  could someone please check  what happened  to the submit-repo ?
>>> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no
>> response   so far .
>>> Maybe  the submit repo  is not working currently  ,  not sure  about it .
>> 
>> Your submit job ran without failures, we were doing maintenance on the jdk-
>> submit repo yesterday and had turned off notifications. Sorry for the
>> inconvenience.
>> 
>> Thanks,
>> Christian
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Mittwoch, 11. April 2018 11:20
>>>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>> some places in function declarations/implementations
>>>> 
>>>>> 
>>>>> Was main() exported via map files?
>>>>> 
>>>> 
>>>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>>>> 
>>>> make/mapfiles/launchers/mapfile-sparcv9
>>>> make/mapfiles/launchers/mapfile-x86_64
>>>> 
>>>> 
>>>> Best regards, Matthias
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Mittwoch, 11. April 2018 11:11
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>> 
>>>>> 
>>>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>> Hi  Alexey, yes that's true .
>>>>>> 
>>>>>>> Please remove JNIEXPORT from main():
>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>> I would  prefer to keep it for now .
>>>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
>>>>> mapfiles in the past already).
>>>>>> Maybe  that?s related to
>>>>>> 
>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>> 
>>>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT,
>> "main");
>>>>>> but I am not sure about this.
>>>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>>>> removed in another  cleanup  if really needed.
>>>>> 
>>>>> OK. Let them stay then.
>>>>> Was main() exported via map files?
>>>>> 
>>>>> 
>>>>> The change looks good to me.
>>>>> 
>>>>> Regards,
>>>>> Alexey
>>>>> 
>>>>>> 
>>>>>>> You can reference both yourself and me as
>>>>>>> Contributed-by: mbaesken, aivanov
>>>>>>> when pushing the changeset if you don't mind.
>>>>>>> 
>>>>>> Sure .
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>> 
>>>>>>> Hi Matthias,
>>>>>>> 
>>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>>>> Hello,  I  had to  do another small adjustment to make
>> jimage.hpp/cpp
>>>>> match. Please review :
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>>> 
>>>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>>> 
>>>>>>> 
>>>>>>> Please remove JNIEXPORT from main():
>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>>> 
>>>>>>>> With the latest webrev I could finally build jdk/jdk successfully on
>> both
>>>>> win32bit and win64 bit.
>>>>>>>> 
>>>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>>>> You can reference both yourself and me as
>>>>>>> Contributed-by: mbaesken, aivanov
>>>>>>> when pushing the changeset if you don't mind.
>>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards, Matthias
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus
>> Ihse
>>>>>>> Bursie
>>>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>>>> <martin.doerr at sap.com>
>>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>>>> function
>>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>>>> JNICALL
>>>>> at
>>>>>>>>> some places in function declarations/implementations
>>>>>>>>> 
>>>>>>>>> Hi Matthias,
>>>>>>>>> 
>>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>>>> explanations
>>>>>>>>> .
>>>>>>>>>> I created  a second  webrev :
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>>> 
>>>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>>>> Yes, that's fine with me.
>>>>>>>>> There could be only one author ;)
>>>>>>>>> 
>>>>>>>>>> -    changes  2 launchers
>>>> src/java.base/share/native/launcher/main.c
>>>>>>> and
>>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>>>> similar
>>>>>>>>> issues after mapfile removal for exes
>>>>>>>>> 
>>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>> 
>>>>>>>>>> Best regards , Matthias
>>> 
> 



From magnus.ihse.bursie at oracle.com  Thu Apr 12 13:33:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 15:33:23 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
Message-ID: <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>

On 2018-04-12 14:15, David Holmes wrote:
> Hi Magnus,
>
> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>> It is currently easy to add new JVM features to the JVM build, but it 
>> is not possible to remove features.
>>
>> With this change, features can be both added or removed from the 
>> default set. They are added using --with-jvm-features=f1,f2 and 
>> removed using --with-jvm-features=-f1,-f2. The syntax can be 
>> combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but 
>> disable native memory tracking.
>
> I need to point out that we have never tested disabling individual VM 
> features likes this. They are either all on, or all off for the 
> minimal VM! There may be implicit dependencies between features.

Well, I have. :-) However, I don't do that regularly, and changes might 
very well have crept in. As always, if you build something non-standard 
that is not regularly tested, you're on your own.

In any case, the purpose of this is not so much to disable existing JVM 
features (after all, no one has really been missing this functionality), 
as to pave the way for the upcoming patch for including/excluding 
individual GCs.

/Magnus

>
> David
>
>> I also included some additional code cleanup and fixes, such as 
>> printing the JVM feature set at the summary.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>



From magnus.ihse.bursie at oracle.com  Thu Apr 12 13:38:40 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 15:38:40 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <CAA-vtUyF_f4SUDTSP1qoc3-sku6h7pnm8cmVSnv9wtgRmxub+g@mail.gmail.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <CAA-vtUyF_f4SUDTSP1qoc3-sku6h7pnm8cmVSnv9wtgRmxub+g@mail.gmail.com>
Message-ID: <5d3b2cc2-4bba-f573-813a-a478ae8aa9b9@oracle.com>

On 2018-04-12 14:11, Thomas St?fe wrote:
> Hi Magnus,
>
> this is nice. I would like a clearer naming though, that single dash
> is easily overlooked. How about --without-jvm-features instead?

This is not possible. --without-X is internally replaced by autoconf to 
"--with-X=no". "--without-X=foo" is a syntax error (or more, technically 
correct, an attempt to run "--with-X=foo=no").

I could of course do something like "--with-disabled-jvm-features=foo" 
instead, but I do not think that is much better. A quick internal poll 
(with Erik and some guys working on the upcoming individual GC 
selection, which prompted this fix) gave the current solution as a clear 
favorite.

A compromise is to keep the currently suggested functionality, and 
*also* add a "--with-disabled-jvm-features=foo", which I would then 
treat as? "--with-jvm-features=-foo". Is that something you'd like to 
request?

/Magnus

>
> ..Thomas
>
> On Thu, Apr 12, 2018 at 1:39 PM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> It is currently easy to add new JVM features to the JVM build, but it is not
>> possible to remove features.
>>
>> With this change, features can be both added or removed from the default
>> set. They are added using --with-jvm-features=f1,f2 and removed using
>> --with-jvm-features=-f1,-f2. The syntax can be combined, so
>> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory
>> tracking.
>>
>> I also included some additional code cleanup and fixes, such as printing the
>> JVM feature set at the summary.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>



From thomas.stuefe at gmail.com  Thu Apr 12 13:48:42 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 15:48:42 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <5d3b2cc2-4bba-f573-813a-a478ae8aa9b9@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <CAA-vtUyF_f4SUDTSP1qoc3-sku6h7pnm8cmVSnv9wtgRmxub+g@mail.gmail.com>
 <5d3b2cc2-4bba-f573-813a-a478ae8aa9b9@oracle.com>
Message-ID: <CAA-vtUynTc0yaNJYeVgGqtoUvBB3foNChpftruC=k6pzOsGz=A@mail.gmail.com>

On Thu, Apr 12, 2018 at 3:38 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2018-04-12 14:11, Thomas St?fe wrote:
>>
>> Hi Magnus,
>>
>> this is nice. I would like a clearer naming though, that single dash
>> is easily overlooked. How about --without-jvm-features instead?
>
>
> This is not possible. --without-X is internally replaced by autoconf to
> "--with-X=no". "--without-X=foo" is a syntax error (or more, technically
> correct, an attempt to run "--with-X=foo=no").
>
> I could of course do something like "--with-disabled-jvm-features=foo"
> instead, but I do not think that is much better. A quick internal poll (with
> Erik and some guys working on the upcoming individual GC selection, which
> prompted this fix) gave the current solution as a clear favorite.
>
> A compromise is to keep the currently suggested functionality, and *also*
> add a "--with-disabled-jvm-features=foo", which I would then treat as
> "--with-jvm-features=-foo". Is that something you'd like to request?
>

No, never mind. I'll keep my eyes sharp for the dash, then.

Best Regards, Thomas

> /Magnus
>
>
>>
>> ..Thomas
>>
>> On Thu, Apr 12, 2018 at 1:39 PM, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> It is currently easy to add new JVM features to the JVM build, but it is
>>> not
>>> possible to remove features.
>>>
>>> With this change, features can be both added or removed from the default
>>> set. They are added using --with-jvm-features=f1,f2 and removed using
>>> --with-jvm-features=-f1,-f2. The syntax can be combined, so
>>> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native
>>> memory
>>> tracking.
>>>
>>> I also included some additional code cleanup and fixes, such as printing
>>> the
>>> JVM feature set at the summary.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>> WebRev:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>>
>


From glaubitz at physik.fu-berlin.de  Thu Apr 12 13:49:00 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 15:49:00 +0200
Subject: Invalid use of -m32 on certain targets
Message-ID: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>

Hi!

I have been playing around with Zero on new (old) architectures and one
of them is hppa, which needs some additional work due to its stack growing
from bottom to top but that's another story.

Anyway, adding hppa to platform.m4 and running configure results in the
following error message:

configure:35290: checking whether the C compiler works
configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32    -m32   conftest.c  >&5
hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
configure:35316: $? = 1
configure:35354: result: no
configure: failed program was:

Didn't we recently have the discussion about which target gcc versions
understand "-m32" and which don't? Apparently, someone thought hppa's
gcc supports that option but apparently it doesn't.

Was there any conclusion on this discussion? I remember that some
people mentioned that the current situation is not ideal.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



From thomas.stuefe at gmail.com  Thu Apr 12 14:39:02 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 16:39:02 +0200
Subject: Invalid use of -m32 on certain targets
In-Reply-To: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
References: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
Message-ID: <CAA-vtUwGyE9Bedvfc8-Dc7kJC6a9j7B7rHNZU0nTDce=OyuUow@mail.gmail.com>

Short note, internally at SAP we have a proprietary port for HPUX
parisc and yes, upward growing stack is quite a problem. We had to
make (and continue to maintain) a lot of downstream changes which deal
with that. So I doubt that even if you manage to build the VM would be
running for long.

Best regards, Thomas

On Thu, Apr 12, 2018 at 3:49 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> Hi!
>
> I have been playing around with Zero on new (old) architectures and one
> of them is hppa, which needs some additional work due to its stack growing
> from bottom to top but that's another story.
>
> Anyway, adding hppa to platform.m4 and running configure results in the
> following error message:
>
> configure:35290: checking whether the C compiler works
> configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32    -m32   conftest.c  >&5
> hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> configure:35316: $? = 1
> configure:35354: result: no
> configure: failed program was:
>
> Didn't we recently have the discussion about which target gcc versions
> understand "-m32" and which don't? Apparently, someone thought hppa's
> gcc supports that option but apparently it doesn't.
>
> Was there any conclusion on this discussion? I remember that some
> people mentioned that the current situation is not ideal.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


From erik.joelsson at oracle.com  Thu Apr 12 15:38:37 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 12 Apr 2018 08:38:37 -0700
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
Message-ID: <48c157c8-20c9-604e-bcd0-91daa41a3e14@oracle.com>

Looks good. Especially adding those # header lines in basics.m4!

I guess a future followup now is to get rid of the individual 
enable/disable args that are now redundant.

/Erik


On 2018-04-12 04:39, Magnus Ihse Bursie wrote:
> It is currently easy to add new JVM features to the JVM build, but it 
> is not possible to remove features.
>
> With this change, features can be both added or removed from the 
> default set. They are added using --with-jvm-features=f1,f2 and 
> removed using --with-jvm-features=-f1,-f2. The syntax can be combined, 
> so --with-jvm-features=dtrace,-nmt will enable dtrace but disable 
> native memory tracking.
>
> I also included some additional code cleanup and fixes, such as 
> printing the JVM feature set at the summary.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>



From iris.clark at oracle.com  Thu Apr 12 15:54:21 2018
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 12 Apr 2018 08:54:21 -0700 (PDT)
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <A24347C6-A214-4F54-A494-BAB8A7938A89@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>
 <4007f78bf6c44e0e9a6b96671493b22c@sap.com>
 <A24347C6-A214-4F54-A494-BAB8A7938A89@oracle.com>
Message-ID: <dd7c8d61-e1e3-4bc2-ad14-413b11a09df3@default>

Hi.

I believe that the internal page Christian references is for the test system.

If you want to know whether the push arrived in the repository, you could subscribe to jdk-submit-changes at openjdk.java.net.  The archive of recent push notifications is public:

    http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-April/thread.html

I wonder if the test system could be enhanced to send a brief notification when a job is queued?

Thanks,
Iris

-----Original Message-----
From: Christian Tornqvist 
Sent: Thursday, April 12, 2018 6:12 AM
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: core-libs-dev at openjdk.java.net; Alexey Ivanov <alexey.ivanov at oracle.com>; Doerr, Martin <martin.doerr at sap.com>; build-dev <build-dev at openjdk.java.net>
Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations



> On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> Your submit job ran without failures, we were doing maintenance on 
>> the jdk- submit repo yesterday and had turned off notifications. 
>> Sorry for the inconvenience.
> 
> Hi Christian , Thanks for  the information about the submit job success.
> 
> Is there a way  to check (e.g. webpage)  that a submit job has "arrived"  and is queued for   build/test  ?

Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help?

Thanks,
Christian

> Would have been helpful  in this situation .
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com]
>> Sent: Donnerstag, 12. April 2018 14:58
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; Magnus Ihse Bursie 
>> <magnus.ihse.bursie at oracle.com>; build-dev <build- 
>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>> function declarations/implementations - was : RE: missing JNIEXPORT / 
>> JNICALL at some places in function declarations/implementations
>> 
>> Hi Matthias,
>> 
>> 
>>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> 
>>> Hi,  could  someone please  sponsor  the change  now ?
>>> 
>>> And  could someone please check  what happened  to the submit-repo ?
>>> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no
>> response   so far .
>>> Maybe  the submit repo  is not working currently  ,  not sure  about it .
>> 
>> Your submit job ran without failures, we were doing maintenance on 
>> the jdk- submit repo yesterday and had turned off notifications. 
>> Sorry for the inconvenience.
>> 
>> Thanks,
>> Christian
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Baesken, Matthias
>>>> Sent: Mittwoch, 11. April 2018 11:20
>>>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie 
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>> <martin.doerr at sap.com>
>>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>> JNICALL at some places in function declarations/implementations
>>>> 
>>>>> 
>>>>> Was main() exported via map files?
>>>>> 
>>>> 
>>>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>>>> 
>>>> make/mapfiles/launchers/mapfile-sparcv9
>>>> make/mapfiles/launchers/mapfile-x86_64
>>>> 
>>>> 
>>>> Best regards, Matthias
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Mittwoch, 11. April 2018 11:11
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>> JNICALL at some places in function declarations/implementations
>>>>> 
>>>>> 
>>>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>> Hi  Alexey, yes that's true .
>>>>>> 
>>>>>>> Please remove JNIEXPORT from main():
>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>> I would  prefer to keep it for now .
>>>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM 
>>>>> without mapfiles in the past already).
>>>>>> Maybe  that?s related to
>>>>>> 
>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>> 
>>>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT,
>> "main");
>>>>>> but I am not sure about this.
>>>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>>>> removed in another  cleanup  if really needed.
>>>>> 
>>>>> OK. Let them stay then.
>>>>> Was main() exported via map files?
>>>>> 
>>>>> 
>>>>> The change looks good to me.
>>>>> 
>>>>> Regards,
>>>>> Alexey
>>>>> 
>>>>>> 
>>>>>>> You can reference both yourself and me as
>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if 
>>>>>>> you don't mind.
>>>>>>> 
>>>>>> Sure .
>>>>>> 
>>>>>> Best regards, Matthias
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places 
>>>>>>> in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>>>> JNICALL
>>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>> 
>>>>>>> Hi Matthias,
>>>>>>> 
>>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>>>> Hello,  I  had to  do another small adjustment to make
>> jimage.hpp/cpp
>>>>> match. Please review :
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>>> 
>>>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>>> 
>>>>>>> 
>>>>>>> Please remove JNIEXPORT from main():
>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>>> 
>>>>>>>> With the latest webrev I could finally build jdk/jdk 
>>>>>>>> successfully on
>> both
>>>>> win32bit and win64 bit.
>>>>>>>> 
>>>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>>>> You can reference both yourself and me as
>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if 
>>>>>>> you don't mind.
>>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards, Matthias
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus
>> Ihse
>>>>>>> Bursie
>>>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>>>>>> <martin.doerr at sap.com>
>>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some 
>>>>>>>>> places in
>>>>>>> function
>>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>>>> JNICALL
>>>>> at
>>>>>>>>> some places in function declarations/implementations
>>>>>>>>> 
>>>>>>>>> Hi Matthias,
>>>>>>>>> 
>>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>>>> explanations
>>>>>>>>> .
>>>>>>>>>> I created  a second  webrev :
>>>>>>>>>> 
>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>>> 
>>>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>>>> Yes, that's fine with me.
>>>>>>>>> There could be only one author ;)
>>>>>>>>> 
>>>>>>>>>> -    changes  2 launchers
>>>> src/java.base/share/native/launcher/main.c
>>>>>>> and
>>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>>>> similar
>>>>>>>>> issues after mapfile removal for exes
>>>>>>>>> 
>>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>> 
>>>>>>>>>> Best regards , Matthias
>>> 
> 



From magnus.ihse.bursie at oracle.com  Thu Apr 12 16:53:39 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 18:53:39 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <48c157c8-20c9-604e-bcd0-91daa41a3e14@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <48c157c8-20c9-604e-bcd0-91daa41a3e14@oracle.com>
Message-ID: <1260C418-71D1-4DA6-B85A-32A010615A45@oracle.com>


> 12 apr. 2018 kl. 17:38 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Looks good. Especially adding those # header lines in basics.m4!

Thanks!

I'm actually thinking about splitting out a utils.m4 from basics.m4, for these kinds of helper functions. Sounds ok?

> 
> I guess a future followup now is to get rid of the individual enable/disable args that are now redundant.

Yes, that is the goal. 

/Magnus

> 
> /Erik
> 
> 
>> On 2018-04-12 04:39, Magnus Ihse Bursie wrote:
>> It is currently easy to add new JVM features to the JVM build, but it is not possible to remove features.
>> 
>> With this change, features can be both added or removed from the default set. They are added using --with-jvm-features=f1,f2 and removed using --with-jvm-features=-f1,-f2. The syntax can be combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory tracking.
>> 
>> I also included some additional code cleanup and fixes, such as printing the JVM feature set at the summary.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>> 
> 



From magnus.ihse.bursie at oracle.com  Thu Apr 12 16:56:00 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 18:56:00 +0200
Subject: Invalid use of -m32 on certain targets
In-Reply-To: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
References: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
Message-ID: <793377E2-04B4-4165-831C-DE1825D2B9ED@oracle.com>


> 12 apr. 2018 kl. 15:49 skrev John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>:
> 
> Hi!
> 
> I have been playing around with Zero on new (old) architectures and one
> of them is hppa, which needs some additional work due to its stack growing
> from bottom to top but that's another story.
> 
> Anyway, adding hppa to platform.m4 and running configure results in the
> following error message:
> 
> configure:35290: checking whether the C compiler works
> configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32    -m32   conftest.c  >&5
> hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> configure:35316: $? = 1
> configure:35354: result: no
> configure: failed program was:
> 
> Didn't we recently have the discussion about which target gcc versions
> understand "-m32" and which don't? Apparently, someone thought hppa's
> gcc supports that option but apparently it doesn't.
> 
> Was there any conclusion on this discussion? I remember that some
> people mentioned that the current situation is not ideal.

I agree. It's not ideal, and should be fixed. It's on my todo list but keep sinking to the bottom. If you want, you can open a bug on it and I just might get around to it a bit quicker. :)

/Magnus

> 
> Adrian
> 
> -- 
> .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> 



From christian.tornqvist at oracle.com  Thu Apr 12 17:04:06 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 12 Apr 2018 13:04:06 -0400
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <dd7c8d61-e1e3-4bc2-ad14-413b11a09df3@default>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <4976D5AA-732B-4C95-B669-05E3DCD245C3@oracle.com>
 <4007f78bf6c44e0e9a6b96671493b22c@sap.com>
 <A24347C6-A214-4F54-A494-BAB8A7938A89@oracle.com>
 <dd7c8d61-e1e3-4bc2-ad14-413b11a09df3@default>
Message-ID: <4E4491FC-5E55-4880-A120-888356D15610@oracle.com>



> On Apr 12, 2018, at 11:54 21AM, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> I believe that the internal page Christian references is for the test system.
> 
> If you want to know whether the push arrived in the repository, you could subscribe to jdk-submit-changes at openjdk.java.net.  The archive of recent push notifications is public:
> 
>    http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-April/thread.html
> 
> I wonder if the test system could be enhanced to send a brief notification when a job is queued?

I?ve opened an enhancement for adding a notification once the job has been handed off to our build and test farm.

Thanks,
Christian
> 
> Thanks,
> Iris
> 
> -----Original Message-----
> From: Christian Tornqvist 
> Sent: Thursday, April 12, 2018 6:12 AM
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: core-libs-dev at openjdk.java.net; Alexey Ivanov <alexey.ivanov at oracle.com>; Doerr, Martin <martin.doerr at sap.com>; build-dev <build-dev at openjdk.java.net>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations
> 
> 
> 
>> On Apr 12, 2018, at 9:07 48AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
>> 
>>> Your submit job ran without failures, we were doing maintenance on 
>>> the jdk- submit repo yesterday and had turned off notifications. 
>>> Sorry for the inconvenience.
>> 
>> Hi Christian , Thanks for  the information about the submit job success.
>> 
>> Is there a way  to check (e.g. webpage)  that a submit job has "arrived"  and is queued for   build/test  ?
> 
> Unfortunately that webpage is only available internally at this point, we could look into sending an email notification that the job has been started if that would help?
> 
> Thanks,
> Christian
> 
>> Would have been helpful  in this situation .
>> 
>> Best regards, Matthias
>> 
>> 
>>> -----Original Message-----
>>> From: Christian Tornqvist [mailto:christian.tornqvist at oracle.com]
>>> Sent: Donnerstag, 12. April 2018 14:58
>>> To: Baesken, Matthias <matthias.baesken at sap.com>
>>> Cc: Alexey Ivanov <alexey.ivanov at oracle.com>; Magnus Ihse Bursie 
>>> <magnus.ihse.bursie at oracle.com>; build-dev <build- 
>>> dev at openjdk.java.net>; Doerr, Martin <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>>> function declarations/implementations - was : RE: missing JNIEXPORT / 
>>> JNICALL at some places in function declarations/implementations
>>> 
>>> Hi Matthias,
>>> 
>>> 
>>>> On Apr 12, 2018, at 3:49 35AM, Baesken, Matthias
>>> <matthias.baesken at sap.com> wrote:
>>>> 
>>>> Hi,  could  someone please  sponsor  the change  now ?
>>>> 
>>>> And  could someone please check  what happened  to the submit-repo ?
>>>> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no
>>> response   so far .
>>>> Maybe  the submit repo  is not working currently  ,  not sure  about it .
>>> 
>>> Your submit job ran without failures, we were doing maintenance on 
>>> the jdk- submit repo yesterday and had turned off notifications. 
>>> Sorry for the inconvenience.
>>> 
>>> Thanks,
>>> Christian
>>>> 
>>>> 
>>>> Best regards , Matthias
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Baesken, Matthias
>>>>> Sent: Mittwoch, 11. April 2018 11:20
>>>>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie 
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>> <martin.doerr at sap.com>
>>>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>> JNICALL at some places in function declarations/implementations
>>>>> 
>>>>>> 
>>>>>> Was main() exported via map files?
>>>>>> 
>>>>> 
>>>>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>>>>> 
>>>>> make/mapfiles/launchers/mapfile-sparcv9
>>>>> make/mapfiles/launchers/mapfile-x86_64
>>>>> 
>>>>> 
>>>>> Best regards, Matthias
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>> Sent: Mittwoch, 11. April 2018 11:11
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>>> <martin.doerr at sap.com>
>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>>> JNICALL at some places in function declarations/implementations
>>>>>> 
>>>>>> 
>>>>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>>> Hi  Alexey, yes that's true .
>>>>>>> 
>>>>>>>> Please remove JNIEXPORT from main():
>>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>>> I would  prefer to keep it for now .
>>>>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>>>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM 
>>>>>> without mapfiles in the past already).
>>>>>>> Maybe  that?s related to
>>>>>>> 
>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>>> 
>>>>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT,
>>> "main");
>>>>>>> but I am not sure about this.
>>>>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>>>>> removed in another  cleanup  if really needed.
>>>>>> 
>>>>>> OK. Let them stay then.
>>>>>> Was main() exported via map files?
>>>>>> 
>>>>>> 
>>>>>> The change looks good to me.
>>>>>> 
>>>>>> Regards,
>>>>>> Alexey
>>>>>> 
>>>>>>> 
>>>>>>>> You can reference both yourself and me as
>>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if 
>>>>>>>> you don't mind.
>>>>>>>> 
>>>>>>> Sure .
>>>>>>> 
>>>>>>> Best regards, Matthias
>>>>>>> 
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>>> Bursie
>>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>>>>> <martin.doerr at sap.com>
>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places 
>>>>>>>> in
>>>>>> function
>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>>>>> JNICALL
>>>>> at
>>>>>>>> some places in function declarations/implementations
>>>>>>>> 
>>>>>>>> Hi Matthias,
>>>>>>>> 
>>>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>>>>> Hello,  I  had to  do another small adjustment to make
>>> jimage.hpp/cpp
>>>>>> match. Please review :
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>>>> 
>>>>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please remove JNIEXPORT from main():
>>>>>>>> src/java.base/share/native/launcher/main.c
>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>>>> 
>>>>>>>>> With the latest webrev I could finally build jdk/jdk 
>>>>>>>>> successfully on
>>> both
>>>>>> win32bit and win64 bit.
>>>>>>>>> 
>>>>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>>>>> You can reference both yourself and me as
>>>>>>>> Contributed-by: mbaesken, aivanov when pushing the changeset if 
>>>>>>>> you don't mind.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Best regards, Matthias
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus
>>> Ihse
>>>>>>>> Bursie
>>>>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin 
>>>>>>>>>> <martin.doerr at sap.com>
>>>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some 
>>>>>>>>>> places in
>>>>>>>> function
>>>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>>>>> JNICALL
>>>>>> at
>>>>>>>>>> some places in function declarations/implementations
>>>>>>>>>> 
>>>>>>>>>> Hi Matthias,
>>>>>>>>>> 
>>>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>>>>> explanations
>>>>>>>>>> .
>>>>>>>>>>> I created  a second  webrev :
>>>>>>>>>>> 
>>>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>>>> 
>>>>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>>>>> Yes, that's fine with me.
>>>>>>>>>> There could be only one author ;)
>>>>>>>>>> 
>>>>>>>>>>> -    changes  2 launchers
>>>>> src/java.base/share/native/launcher/main.c
>>>>>>>> and
>>>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>>>>> similar
>>>>>>>>>> issues after mapfile removal for exes
>>>>>>>>>> 
>>>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>> 
>>>>>>>>>>> Best regards , Matthias
>>>> 
>> 
> 



From erik.joelsson at oracle.com  Thu Apr 12 17:24:22 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 12 Apr 2018 10:24:22 -0700
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <1260C418-71D1-4DA6-B85A-32A010615A45@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <48c157c8-20c9-604e-bcd0-91daa41a3e14@oracle.com>
 <1260C418-71D1-4DA6-B85A-32A010615A45@oracle.com>
Message-ID: <98f88ab9-7302-b238-5385-8fbafa75af95@oracle.com>



On 2018-04-12 09:53, Magnus Ihse Bursie wrote:
>> 12 apr. 2018 kl. 17:38 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>
>> Looks good. Especially adding those # header lines in basics.m4!
> Thanks!
>
> I'm actually thinking about splitting out a utils.m4 from basics.m4, for these kinds of helper functions. Sounds ok?
Yes, makes sense.

/Erik
>> I guess a future followup now is to get rid of the individual enable/disable args that are now redundant.
> Yes, that is the goal.
>
> /Magnus
>
>> /Erik
>>
>>
>>> On 2018-04-12 04:39, Magnus Ihse Bursie wrote:
>>> It is currently easy to add new JVM features to the JVM build, but it is not possible to remove features.
>>>
>>> With this change, features can be both added or removed from the default set. They are added using --with-jvm-features=f1,f2 and removed using --with-jvm-features=-f1,-f2. The syntax can be combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory tracking.
>>>
>>> I also included some additional code cleanup and fixes, such as printing the JVM feature set at the summary.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>>



From daniel.smith at oracle.com  Thu Apr 12 17:42:08 2018
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 12 Apr 2018 11:42:08 -0600
Subject: -Wexpansion-to-defined warnings
Message-ID: <7930A0BF-17E2-4A46-BCD7-3BB625990F7C@oracle.com>

I'm suddenly getting hundreds of these warnings when I build in macOS:

/Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:126:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
    ^
/Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
                                     ^

Not clear what triggered them, but my guess is an Xcode update.

Is this a known problem? Can anyone reproduce?



From magnus.ihse.bursie at oracle.com  Thu Apr 12 18:19:30 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 20:19:30 +0200
Subject: -Wexpansion-to-defined warnings
In-Reply-To: <7930A0BF-17E2-4A46-BCD7-3BB625990F7C@oracle.com>
References: <7930A0BF-17E2-4A46-BCD7-3BB625990F7C@oracle.com>
Message-ID: <cfbef3d4-a3a8-cc5a-53c2-b00e5e82b8d6@oracle.com>

On 2018-04-12 19:42, Dan Smith wrote:
> I'm suddenly getting hundreds of these warnings when I build in macOS:
>
> /Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:126:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
> #if HEAP_REGION_SET_FORCE_VERIFY
>      ^
> /Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>                                       ^
I think I saw a discussion about fixing this since the new Visual Studio 
compiler also complained about it, or so. It might even be fixed in jdk/hs.
> Not clear what triggered them, but my guess is an Xcode update.
If you updated Xcode, and are using that instead of jib for building, 
then yes, that's likely.

/Magnus
>
> Is this a known problem? Can anyone reproduce?
>



From henry.jen at oracle.com  Thu Apr 12 18:24:18 2018
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 12 Apr 2018 11:24:18 -0700
Subject: -Wexpansion-to-defined warnings
In-Reply-To: <cfbef3d4-a3a8-cc5a-53c2-b00e5e82b8d6@oracle.com>
References: <7930A0BF-17E2-4A46-BCD7-3BB625990F7C@oracle.com>
 <cfbef3d4-a3a8-cc5a-53c2-b00e5e82b8d6@oracle.com>
Message-ID: <D95F2D19-806A-4F9E-ABB6-F9039810193A@oracle.com>

Yes, it?s a known issue after upgrade Xcode,

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

Cheers,
Henry


> On Apr 12, 2018, at 11:19 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2018-04-12 19:42, Dan Smith wrote:
>> I'm suddenly getting hundreds of these warnings when I build in macOS:
>> 
>> /Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:126:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
>> #if HEAP_REGION_SET_FORCE_VERIFY
>>     ^
>> /Users/dan/Dev/jdk/jdk/src/hotspot/share/gc/g1/heapRegionSet.hpp:53:38: note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>>                                      ^
> I think I saw a discussion about fixing this since the new Visual Studio compiler also complained about it, or so. It might even be fixed in jdk/hs.
>> Not clear what triggered them, but my guess is an Xcode update.
> If you updated Xcode, and are using that instead of jib for building, then yes, that's likely.
> 
> /Magnus
>> 
>> Is this a known problem? Can anyone reproduce?
>> 
> 



From philip.race at oracle.com  Thu Apr 12 18:38:04 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 12 Apr 2018 11:38:04 -0700
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <e35231937aed4118a7cf8879965fffdf@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
Message-ID: <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com>

I was just directed to this look at this change.
I don't know why it is being reviewed exclusively on build-dev since no
build files are being changed.
50% of it should have been sent to 2d-dev and the rest on core-libs + 
hotspot ..

Is this the current version of the change : 
http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?

-phil.

On 04/12/2018 12:49 AM, Baesken, Matthias wrote:
> Hi,  could  someone please  sponsor  the change  now ?
>
> And  could someone please check  what happened  to the submit-repo ?
> Yesterday I pushed to  the submit repo  to   check my  change  ,  but  no  response   so far .
> Maybe  the submit repo  is not working currently  ,  not sure  about it .
>
>
> Best regards , Matthias
>
>
>
>
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Mittwoch, 11. April 2018 11:20
>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>> <martin.doerr at sap.com>
>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>>> Was main() exported via map files?
>>>
>> Seems main was exported , I can find it in jdk10  in  e.g.  :
>>
>> make/mapfiles/launchers/mapfile-sparcv9
>> make/mapfiles/launchers/mapfile-x86_64
>>
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Mittwoch, 11. April 2018 11:11
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>
>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>> Hi  Alexey, yes that's true .
>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>> I would  prefer to keep it for now .
>>>> I notice  some  comments  in our SAPJVM code base  about needing
>>> JNIEXPORT for  main  for Solaris  (we were running  in SAPJVM without
>>> mapfiles in the past already).
>>>> Maybe  that?s related to
>>>>
>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>
>>>> where main  is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main");
>>>> but I am not sure about this.
>>>> So I better keep  the JNIEXPORT  for the main functions,   could be
>>> removed in another  cleanup  if really needed.
>>>
>>> OK. Let them stay then.
>>> Was main() exported via map files?
>>>
>>>
>>> The change looks good to me.
>>>
>>> Regards,
>>> Alexey
>>>
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>> Sure .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>> Bursie
>>>>> <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>> <martin.doerr at sap.com>
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>> at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>> Hello,  I  had to  do another small adjustment to make jimage.hpp/cpp
>>> match. Please review :
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>
>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>
>>>>>
>>>>> Please remove JNIEXPORT from main():
>>>>> src/java.base/share/native/launcher/main.c
>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>
>>>>>> With the latest webrev I could finally build jdk/jdk successfully on both
>>> win32bit and win64 bit.
>>>>>> Thanks again  to Alexey  to provide  the   incorporated patch .
>>>>> You can reference both yourself and me as
>>>>> Contributed-by: mbaesken, aivanov
>>>>> when pushing the changeset if you don't mind.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>> Bursie
>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>> <martin.doerr at sap.com>
>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>> JNICALL
>>> at
>>>>>>> some places in function declarations/implementations
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>>
>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>> Hi  Alexey,    thanks  for  the diff provided by you, and  for  the
>>>>> explanations
>>>>>>> .
>>>>>>>> I created  a second  webrev :
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>
>>>>>>>> -   it  adds  the diff  provided by you    (hope that?s fine with you)
>>>>>>> Yes, that's fine with me.
>>>>>>> There could be only one author ;)
>>>>>>>
>>>>>>>> -    changes  2 launchers
>> src/java.base/share/native/launcher/main.c
>>>>> and
>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp    where we face
>>> similar
>>>>>>> issues after mapfile removal for exes
>>>>>>>
>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>>> Best regards , Matthias



From jonathan.gibbons at oracle.com  Thu Apr 12 20:15:24 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 12 Apr 2018 13:15:24 -0700
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
Message-ID: <5ACFBE5C.1080508@oracle.com>

Please review an initial implementation for the feature described in
JEP 330: Launch Single-File Source-Code Programs.

The work is described in the JEP and CSR, and falls into various parts:

  * The part to handle the new command-line options is in the native
    Java launcher code.
  * The part to invoke the compiler and subsequently execute the code
    found in the source file is in a new class in the jdk.compiler module.
  * There are some minor Makefile changes, to add support for a new
    resource file.

There are no changes to javac itself.

JEP: http://openjdk.java.net/jeps/330
JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/

-- Jon


From magnus.ihse.bursie at oracle.com  Thu Apr 12 20:17:03 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Apr 2018 22:17:03 +0200
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ACFBE5C.1080508@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
Message-ID: <d6e81ebe-dea3-dd77-08b5-04ed4a9791f2@oracle.com>

On 2018-04-12 22:15, Jonathan Gibbons wrote:
> Please review an initial implementation for the feature described in
> JEP 330: Launch Single-File Source-Code Programs.
>
> The work is described in the JEP and CSR, and falls into various parts:
>
> ?* The part to handle the new command-line options is in the native
> ?? Java launcher code.
> ?* The part to invoke the compiler and subsequently execute the code
> ?? found in the source file is in a new class in the jdk.compiler module.
> ?* There are some minor Makefile changes, to add support for a new
> ?? resource file.
>
> There are no changes to javac itself.
>
> JEP: http://openjdk.java.net/jeps/330
> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
Build changes look trivially fine.

/Magnus

>
> -- Jon



From philip.race at oracle.com  Thu Apr 12 20:42:59 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 12 Apr 2018 13:42:59 -0700
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <7c5e68c2a023490e96ce6452fbda1700@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
 <7c5e68c2a023490e96ce6452fbda1700@sap.com>
Message-ID: <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>

How can JNIEXPORT be different between 32 bit & 64 bit ?
I'm sure you saw compilation errors but I don't get why it failed for 32 
only.

JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
explain why the 32 bit compiler would complain about inconsistent 
application
of __declspec(dllexport) - ie JNIEXPORT.

Or is that part (adding JNIEXPORT) pure clean up and the compilation 
errors were all down to JNICALL ?

I was a bit puzzled at the removals I saw here :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html

.. I needed to look at the whole file to realise that you were removing 
a duplicate
declaration.

-phil.

On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
> Hi  Alan , this is the up to date webrev .
> However we want to add   Alexey   Ivanov  as additional  author .
>
>> As I read it, this changes the calling convention of these functions on
>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>> __stdcall is ignored) or other platforms, is that correct?
>>
> The  change adds  JNIEXPORT   at some places  where it is  ben forgotten , for example :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
>
> This might have  potential  impact  on other platforms   (fixes  the mismatches) .
>
> Best regards, Matthias
>
>
>
>
>> -----Original Message-----
>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>> Sent: Donnerstag, 12. April 2018 12:54
>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>;
>> core-libs-dev at openjdk.java.net
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>> Adding core-libs-dev as this is change code in libjava, libzip,
>> libjimage, ...
>>
>> Can you confirm that this is the up to date webrev:
>>      http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>
>> As I read it, this changes the calling convention of these functions on
>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>> __stdcall is ignored) or other platforms, is that correct?
>>
>> -Alan
>>
>>
>> On 06/04/2018 14:20, Baesken, Matthias wrote:
>>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>>>
>>>
>>>     1.  The   follow up change  that removed   mapfiles for  exes  as well
>> leads on Win32 bit  to  this link error :
>>>     Creating library
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>> referenced in function ___tmainCRTStartup
>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
>> fatal error LNK1120: 1 unresolved externals
>>>
>>> Looks like we  cannot have   JNICALL   in main.c   :
>>>
>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>> --- a/src/java.base/share/native/launcher/main.c        Thu Apr 05 14:39:04
>> 2018 -0700
>>> +++ b/src/java.base/share/native/launcher/main.c        Fri Apr 06 15:16:40
>> 2018 +0200
>>> @@ -93,7 +93,7 @@
>>>        __initenv = _environ;
>>>
>>> #else /* JAVAW */
>>> -JNIEXPORT int JNICALL
>>> +JNIEXPORT int
>>> main(int argc, char **argv)
>>> {
>>>        int margc;
>>>
>>>
>>>
>>>     1.  Zip-library  has runtime issues   when  symbols  are resolved  in
>> src/hotspot/share/classfile/classLoader.cpp.
>>> I added  the declaration of the missing symbol, this seems to fix it .
>>>
>>>
>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>> --- a/src/java.base/share/native/libzip/zip_util.h      Thu Apr 05 14:39:04
>> 2018 -0700
>>> +++ b/src/java.base/share/native/libzip/zip_util.h      Fri Apr 06 15:16:40
>> 2018 +0200
>>> @@ -284,4 +284,7 @@
>>> JNIEXPORT jboolean JNICALL
>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
>> **pmsg);
>>> +JNIEXPORT jint JNICALL
>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>> +
>>>
>>>
>>> Should I  prepare  another  bug,  or  add this to the existing one and    post a
>> second webrev ?
>>> Best regards, Matthias
>>>
>>>
>>> From: Baesken, Matthias
>>> Sent: Freitag, 6. April 2018 09:54
>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function declarations/implementations - was : RE: missing JNIEXPORT /
>> JNICALL at some places in function declarations/implementations
>>> Hello, please review :
>>>
>>> Bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>
>>> change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>
>>> mostly I added  JNIEXPORT / JNICALL at some places  where  the win32bit
>> build missed it .
>>> A difference is
>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>> Where I removed   a few  declarations  (one  decl   with one without
>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>> Best regards , Matthias
>>>
>>>
>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>> Sent: Donnerstag, 5. April 2018 17:45
>>> To: Baesken, Matthias
>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
>>> Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>;
>> Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations
>>> That's most likely a result of the new JNIEXPORT I added as part of the
>> mapfile removal.
>>> I tried to match header file and C file, but I can certainly have missed cases.
>> If I didn't get any warnings, it was hard to know what I missed.
>>> Please do submit your patch.
>>>
>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>
>>> /Magnus
>>>
>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
>>> Hello, we noticed  that  at a number  of places in the coding  ,   the
>> JNIEXPORT and/or   JNICALL modifiers   do not match  when one compares
>> the declaration and
>>> The implementation of functions.
>>> While this is ok on most platforms, it seems to fail on Windows 32 bit and
>> leads to errors like this one :
>>>
>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
>> ib_ImageConvKernelConvert.c(87) : error C2373:
>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers
>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
>> ib_image_proto.h(2630) : see declaration of
>> 'j2d_mlib_ImageConvKernelConvert'
>>> (there are quite a few of these e.g. in mlib  / splashscreen etc.)
>>>
>>>
>>> Another example is this one :
>>>
>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>> --- a/src/java.base/share/native/libjimage/jimage.hpp  Thu Apr 05 09:55:16
>> 2018 +0200
>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp               Thu Apr 05
>> 17:07:40 2018 +0200
>>> @@ -126,7 +126,7 @@
>>>     *   JImageLocationRef location = (*JImageFindResource)(image,
>>>     *                                "java.base", "9.0", "java/lang/String.class", &size);
>>>     */
>>> -extern "C" JNIEXPORT JImageLocationRef
>> JIMAGE_FindResource(JImageFile* jimage,
>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>> JIMAGE_FindResource(JImageFile* jimage,
>>>            const char* module_name, const char* version, const char* name,
>>>            jlong* size);
>>>
>>>
>>> Is there some generic way to get  the  same  declarations / impementations
>> in the code  ?
>>> Or should I just add a patch with my findings ?
>>>
>>> Best regards, Matthias
>>>



From maurizio.cimadamore at oracle.com  Thu Apr 12 20:46:54 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 12 Apr 2018 21:46:54 +0100
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ACFBE5C.1080508@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
Message-ID: <a96d7ce1-291b-67fc-98fc-d611451f1ba8@oracle.com>

Looks great - some initial comments (I can't really comment on the 
launcher changes):

* This logic is efficient:

int magic = (in.read() << 8) + in.read();
boolean shebang = magic == (('#' << 8) + '!');

but convoluted to read; perhaps could be improved slightly by making '#' 
<< 8) + '!' a static constant, and comparing against that.

* I note that the reading logic in general could be simplified, e.g. 
using Files.lines(Path) - but I assume that you wrote the code as is for 
performance reasons (e.g. to avoid creating too many string objects) ?

* I see that both the file manager and the class loader reasonably share 
the same context: a Map<String, byte[]>. I would make this more 
explicit, by having a Context class, whose state is the map, and then 
have the context provide two methods:

getClassLoader()
getFileManager()

This way the sharing will be automatic, no need to extract one field 
from one place and pass it over to the other place.

* Big whohoo for being able to use the enhanced diagnostic framework 
with a couple of tweaks on the makefile - I hope that would have been 
the case when I put in the support, but since we have never done it - 
wasn't 100% sure it would work ;-)


Overall I like it quite a lot and I think you went for a really clean 
design - kudos!

Maurizio



On 12/04/18 21:15, Jonathan Gibbons wrote:
> Please review an initial implementation for the feature described in
> JEP 330: Launch Single-File Source-Code Programs.
>
> The work is described in the JEP and CSR, and falls into various parts:
>
>   * The part to handle the new command-line options is in the native
>     Java launcher code.
>   * The part to invoke the compiler and subsequently execute the code
>     found in the source file is in a new class in the jdk.compiler module.
>   * There are some minor Makefile changes, to add support for a new
>     resource file.
>
> There are no changes to javac itself.
>
> JEP: http://openjdk.java.net/jeps/330
> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>
> -- Jon



From erik.joelsson at oracle.com  Thu Apr 12 21:28:43 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 12 Apr 2018 14:28:43 -0700
Subject: RFR: JDK-8201508: Macosx builds fail in GenerateLinkOptData.gmk
Message-ID: <d065bdec-a87b-0a9b-9bbc-bc7ad62fb033@oracle.com>

All macosx builds in CI currently fail. This is caused by in issue with 
JDK-8201483 which leaves the JVM_VARIANTS_server variable empty. The 
construct used to subtract one set of strings from another doesn't work 
quite as expected with bsd grep.

result=`$GREP -Fvx "$legal_values" <<< "$values_to_check" | $GREP -v '^$'`

If the set to subtract ($legal_values) is empty, gnu grep returns all 
values (as expected) while bsd grep returns nothing. To fix this I've 
added an explicit check for the base case of legal_values being empty. 
This seems to make --with-jvm-features work correctly on macosx and 
still work correctly on Linux. A verification distributed build is under 
way.

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

Webrev: http://cr.openjdk.java.net/~erikj/8201508/webrev.01/

/Erik



From david.holmes at oracle.com  Thu Apr 12 21:30:08 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Apr 2018 07:30:08 +1000
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
 <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
Message-ID: <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>

On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
> On 2018-04-12 14:15, David Holmes wrote:
>> Hi Magnus,
>>
>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>> It is currently easy to add new JVM features to the JVM build, but it 
>>> is not possible to remove features.
>>>
>>> With this change, features can be both added or removed from the 
>>> default set. They are added using --with-jvm-features=f1,f2 and 
>>> removed using --with-jvm-features=-f1,-f2. The syntax can be 
>>> combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but 
>>> disable native memory tracking.
>>
>> I need to point out that we have never tested disabling individual VM 
>> features likes this. They are either all on, or all off for the 
>> minimal VM! There may be implicit dependencies between features.
> 
> Well, I have. :-) However, I don't do that regularly, and changes might 
> very well have crept in. As always, if you build something non-standard 
> that is not regularly tested, you're on your own.

Feels to me like you've taken away the safety-fence and are encouraging 
people to attempt these unsupported configurations. Whether that was 
your intent or not.

> In any case, the purpose of this is not so much to disable existing JVM 
> features (after all, no one has really been missing this functionality), 
> as to pave the way for the upcoming patch for including/excluding 
> individual GCs.

Surely a GC selection flag would have sufficed.

David

> /Magnus
> 
>>
>> David
>>
>>> I also included some additional code cleanup and fixes, such as 
>>> printing the JVM feature set at the summary.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01 
>>>
>>>
> 


From tim.bell at oracle.com  Thu Apr 12 21:34:45 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 12 Apr 2018 14:34:45 -0700
Subject: RFR: JDK-8201508: Macosx builds fail in GenerateLinkOptData.gmk
In-Reply-To: <d065bdec-a87b-0a9b-9bbc-bc7ad62fb033@oracle.com>
References: <d065bdec-a87b-0a9b-9bbc-bc7ad62fb033@oracle.com>
Message-ID: <5ACFD0F5.6080500@oracle.com>

Erik:

> All macosx builds in CI currently fail. This is caused by in issue with
> JDK-8201483 which leaves the JVM_VARIANTS_server variable empty. The
> construct used to subtract one set of strings from another doesn't work
> quite as expected with bsd grep.
>
> result=`$GREP -Fvx "$legal_values" <<< "$values_to_check" | $GREP -v '^$'`
>
> If the set to subtract ($legal_values) is empty, gnu grep returns all
> values (as expected) while bsd grep returns nothing. To fix this I've
> added an explicit check for the base case of legal_values being empty.
> This seems to make --with-jvm-features work correctly on macosx and
> still work correctly on Linux. A verification distributed build is under
> way.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201508
>
> Webrev: http://cr.openjdk.java.net/~erikj/8201508/webrev.01/

Looks good.

Tim




From alexey.ivanov at oracle.com  Thu Apr 12 21:40:20 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 12 Apr 2018 22:40:20 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <DDBD27CA-2443-4E5B-9E13-E6A29982454D@oracle.com>
 <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com>
 <b61a833143884ac0a8388176df125aee@sap.com>
 <AA339160-0999-4943-9330-995DF6AD0099@oracle.com>
 <35e12d6d6eb24d88aadaf10e0229dd48@sap.com>
 <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com>
 <d1323d04-b482-e273-e21c-c41e3b2e5602@oracle.com>
 <5146b9330edd44b483780587aca1757c@sap.com>
 <fc5bc51d-ee16-4e2e-16e6-5925bfe37a6c@oracle.com>
 <99420e261ef347578bb8099a48d6b7ec@sap.com>
 <cfe6abdb-8947-9a03-ce91-c76f5f0cebcb@oracle.com>
 <5693830fbf6747d9a51e9cf374f63e18@sap.com>
 <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com>
 <3520f157a7d14a118a584fdeb226381e@sap.com>
 <e35231937aed4118a7cf8879965fffdf@sap.com>
 <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com>
Message-ID: <f52eb1d9-d6e7-f972-9417-ba759ad75781@oracle.com>


On 12/04/2018 19:38, Phil Race wrote:
> I was just directed to this look at this change.
> I don't know why it is being reviewed exclusively on build-dev since no
> build files are being changed.

My bad! I tried to engage core-libs when the patch was ready but I 
completely overlooked the fact that 2d libs were also affected by this 
change and I didn't cc to 2d-dev.

> 50% of it should have been sent to 2d-dev and the rest on core-libs + 
> hotspot ..
>
> Is this the current version of the change : 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?

Yes, it's the latest version to the best of my knowledge.


Regards,
Alexey

>
> -phil.
>
> On 04/12/2018 12:49 AM, Baesken, Matthias wrote:
>> Hi,? could? someone please? sponsor? the change? now ?
>>
>> And? could someone please check? what happened? to the submit-repo ?
>> Yesterday I pushed to? the submit repo? to?? check my? change ,? but? 
>> no? response?? so far .
>> Maybe? the submit repo? is not working currently? ,? not sure about it .
>>
>>
>> Best regards , Matthias
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Baesken, Matthias
>>> Sent: Mittwoch, 11. April 2018 11:20
>>> To: 'Alexey Ivanov' <alexey.ivanov at oracle.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>> <martin.doerr at sap.com>
>>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in 
>>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>> Was main() exported via map files?
>>>>
>>> Seems main was exported , I can find it in jdk10? in? e.g.? :
>>>
>>> make/mapfiles/launchers/mapfile-sparcv9
>>> make/mapfiles/launchers/mapfile-x86_64
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>> Sent: Mittwoch, 11. April 2018 11:11
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>> <martin.doerr at sap.com>
>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>> JNICALL at
>>>> some places in function declarations/implementations
>>>>
>>>>
>>>> On 11/04/2018 08:44, Baesken, Matthias wrote:
>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>> Hi? Alexey, yes that's true .
>>>>>
>>>>>> Please remove JNIEXPORT from main():
>>>>>> src/java.base/share/native/launcher/main.c
>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>> I would? prefer to keep it for now .
>>>>> I notice? some? comments? in our SAPJVM code base? about needing
>>>> JNIEXPORT for? main? for Solaris? (we were running? in SAPJVM without
>>>> mapfiles in the past already).
>>>>> Maybe? that?s related to
>>>>>
>>>>> src/java.base/unix/native/libjli/java_md_solinux.c
>>>>>
>>>>> where main? is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, 
>>>>> "main");
>>>>> but I am not sure about this.
>>>>> So I better keep? the JNIEXPORT? for the main functions, could be
>>>> removed in another? cleanup? if really needed.
>>>>
>>>> OK. Let them stay then.
>>>> Was main() exported via map files?
>>>>
>>>>
>>>> The change looks good to me.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>>>> You can reference both yourself and me as
>>>>>> Contributed-by: mbaesken, aivanov
>>>>>> when pushing the changeset if you don't mind.
>>>>>>
>>>>> Sure .
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>> Sent: Dienstag, 10. April 2018 21:34
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>> Bursie
>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>> <martin.doerr at sap.com>
>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>> function
>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL
>>> at
>>>>>> some places in function declarations/implementations
>>>>>>
>>>>>> Hi Matthias,
>>>>>>
>>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote:
>>>>>>> Hello,? I? had to? do another small adjustment to make 
>>>>>>> jimage.hpp/cpp
>>>> match. Please review :
>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it?
>>>>>>
>>>>>> I've successfully built 32 bit Windows with your patch.
>>>>>>
>>>>>>
>>>>>> Please remove JNIEXPORT from main():
>>>>>> src/java.base/share/native/launcher/main.c
>>>>>> src/jdk.pack/share/native/unpack200/main.cpp
>>>>>>
>>>>>>> With the latest webrev I could finally build jdk/jdk 
>>>>>>> successfully on both
>>>> win32bit and win64 bit.
>>>>>>> Thanks again? to Alexey? to provide? the?? incorporated patch .
>>>>>> You can reference both yourself and me as
>>>>>> Contributed-by: mbaesken, aivanov
>>>>>> when pushing the changeset if you don't mind.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>>> Best regards, Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>>>>>>> Sent: Montag, 9. April 2018 17:14
>>>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>>> Bursie
>>>>>>>> <magnus.ihse.bursie at oracle.com>
>>>>>>>> Cc: build-dev <build-dev at openjdk.java.net>; Doerr, Martin
>>>>>>>> <martin.doerr at sap.com>
>>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>>> function
>>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>>> JNICALL
>>>> at
>>>>>>>> some places in function declarations/implementations
>>>>>>>>
>>>>>>>> Hi Matthias,
>>>>>>>>
>>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote:
>>>>>>>>> Hi? Alexey,??? thanks? for the diff provided by you, and? for? 
>>>>>>>>> the
>>>>>> explanations
>>>>>>>> .
>>>>>>>>> I created? a second? webrev :
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/
>>>>>>>>>
>>>>>>>>> -?? it? adds? the diff? provided by you??? (hope that?s fine 
>>>>>>>>> with you)
>>>>>>>> Yes, that's fine with me.
>>>>>>>> There could be only one author ;)
>>>>>>>>
>>>>>>>>> -??? changes? 2 launchers
>>> src/java.base/share/native/launcher/main.c
>>>>>> and
>>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face
>>>> similar
>>>>>>>> issues after mapfile removal for exes
>>>>>>>>
>>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main().
>>>>>>>> It wasn't exported, and it shouldn't be.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>>> Best regards , Matthias
>



From alexey.ivanov at oracle.com  Thu Apr 12 21:53:10 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Thu, 12 Apr 2018 22:53:10 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
 <7c5e68c2a023490e96ce6452fbda1700@sap.com>
 <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
Message-ID: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>


On 12/04/2018 21:42, Phil Race wrote:
> How can JNIEXPORT be different between 32 bit & 64 bit ?
> I'm sure you saw compilation errors but I don't get why it failed for 
> 32 only.
>
> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
> explain why the 32 bit compiler would complain about inconsistent 
> application
> of __declspec(dllexport) - ie JNIEXPORT.
>
> Or is that part (adding JNIEXPORT) pure clean up and the compilation 
> errors were all down to JNICALL ?

Adding missing JNIEXPORT is for cleanup only.

The compiler complained about mismatched JNICALL / non-JNICALL 
declarations as the macro changes calling convention from the default 
__cdecl? to __stdcall on 32 bit Windows.

Another issue is that __stdcall decorates the functions: prefixes with 
underscore and postfixes with @ + size of parameters. Because of the 
decorations, classLoader.cpp can't lookup the required functions by name 
from zip.dll and jimage.dll. The functions are exported but with 
different name.

I hope this information adds more details to the picture.

> I was a bit puzzled at the removals I saw here :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html 
>
>
> .. I needed to look at the whole file to realise that you were 
> removing a duplicate
> declaration.

That was tricky. I could have been mentioned in the review.


Regards,
Alexey

>
> -phil.
>
> On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
>> Hi? Alan , this is the up to date webrev .
>> However we want to add?? Alexey?? Ivanov? as additional? author .
>>
>>> As I read it, this changes the calling convention of these functions on
>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>> __stdcall is ignored) or other platforms, is that correct?
>>>
>> The? change adds? JNIEXPORT?? at some places? where it is? ben 
>> forgotten , for example :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html 
>>
>>
>> This might have? potential? impact? on other platforms?? (fixes the 
>> mismatches) .
>>
>> Best regards, Matthias
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>> Sent: Donnerstag, 12. April 2018 12:54
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>;
>>> core-libs-dev at openjdk.java.net
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>> Adding core-libs-dev as this is change code in libjava, libzip,
>>> libjimage, ...
>>>
>>> Can you confirm that this is the up to date webrev:
>>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>
>>> As I read it, this changes the calling convention of these functions on
>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>> __stdcall is ignored) or other platforms, is that correct?
>>>
>>> -Alan
>>>
>>>
>>> On 06/04/2018 14:20, Baesken, Matthias wrote:
>>>> Hello, I just noticed? 2? additonal issues? regarding 
>>>> mapfile-removal :
>>>>
>>>>
>>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes? 
>>>> as well
>>> leads on Win32 bit? to? this link error :
>>>> ??? Creating library
>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and 
>>> object
>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>>> referenced in function ___tmainCRTStartup
>>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
>>> fatal error LNK1120: 1 unresolved externals
>>>>
>>>> Looks like we? cannot have?? JNICALL?? in main.c?? :
>>>>
>>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
>>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05 
>>>> 14:39:04
>>> 2018 -0700
>>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06 
>>>> 15:16:40
>>> 2018 +0200
>>>> @@ -93,7 +93,7 @@
>>>> ?????? __initenv = _environ;
>>>>
>>>> #else /* JAVAW */
>>>> -JNIEXPORT int JNICALL
>>>> +JNIEXPORT int
>>>> main(int argc, char **argv)
>>>> {
>>>> ?????? int margc;
>>>>
>>>>
>>>>
>>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are 
>>>> resolved? in
>>> src/hotspot/share/classfile/classLoader.cpp.
>>>> I added? the declaration of the missing symbol, this seems to fix it .
>>>>
>>>>
>>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
>>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05 
>>>> 14:39:04
>>> 2018 -0700
>>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06 
>>>> 15:16:40
>>> 2018 +0200
>>>> @@ -284,4 +284,7 @@
>>>> JNIEXPORT jboolean JNICALL
>>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong 
>>>> outLen, char
>>> **pmsg);
>>>> +JNIEXPORT jint JNICALL
>>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
>>>> +
>>>>
>>>>
>>>> Should I? prepare? another? bug,? or? add this to the existing one 
>>>> and??? post a
>>> second webrev ?
>>>> Best regards, Matthias
>>>>
>>>>
>>>> From: Baesken, Matthias
>>>> Sent: Freitag, 6. April 2018 09:54
>>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
>>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function declarations/implementations - was : RE: missing JNIEXPORT /
>>> JNICALL at some places in function declarations/implementations
>>>> Hello, please review :
>>>>
>>>> Bug :
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>
>>>> change :
>>>>
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
>>>>
>>>> mostly I added? JNIEXPORT / JNICALL at some places? where the win32bit
>>> build missed it .
>>>> A difference is
>>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
>>>> Where I removed?? a few? declarations (one? decl?? with one without
>>> JNIEXPORT / JNICALL ? looked a bit strange ) .
>>>> Best regards , Matthias
>>>>
>>>>
>>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>>>> Sent: Donnerstag, 5. April 2018 17:45
>>>> To: Baesken, Matthias
>>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
>>>> Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>;
>>> Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
>>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
>>> declarations/implementations
>>>> That's most likely a result of the new JNIEXPORT I added as part of 
>>>> the
>>> mapfile removal.
>>>> I tried to match header file and C file, but I can certainly have 
>>>> missed cases.
>>> If I didn't get any warnings, it was hard to know what I missed.
>>>> Please do submit your patch.
>>>>
>>>> I'm a bit surprised 32-bit Window is still buildable. :)
>>>>
>>>> /Magnus
>>>>
>>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
>>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
>>>> Hello, we noticed? that? at a number of places in the coding? ,?? the
>>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one compares
>>> the declaration and
>>>> The implementation of functions.
>>>> While this is ok on most platforms, it seems to fail on Windows 32 
>>>> bit and
>>> leads to errors like this one :
>>>>
>>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml 
>>>
>>> ib_ImageConvKernelConvert.c(87) : error C2373:
>>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type 
>>> modifiers
>>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml 
>>>
>>> ib_image_proto.h(2630) : see declaration of
>>> 'j2d_mlib_ImageConvKernelConvert'
>>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.)
>>>>
>>>>
>>>> Another example is this one :
>>>>
>>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
>>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05 
>>>> 09:55:16
>>> 2018 +0200
>>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05
>>> 17:07:40 2018 +0200
>>>> @@ -126,7 +126,7 @@
>>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image,
>>>> ??? *??????????????????????????????? "java.base", "9.0", 
>>>> "java/lang/String.class", &size);
>>>> ??? */
>>>> -extern "C" JNIEXPORT JImageLocationRef
>>> JIMAGE_FindResource(JImageFile* jimage,
>>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
>>> JIMAGE_FindResource(JImageFile* jimage,
>>>> ?????????? const char* module_name, const char* version, const 
>>>> char* name,
>>>> ?????????? jlong* size);
>>>>
>>>>
>>>> Is there some generic way to get? the? same? declarations / 
>>>> impementations
>>> in the code? ?
>>>> Or should I just add a patch with my findings ?
>>>>
>>>> Best regards, Matthias
>>>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr 12 22:54:19 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 13 Apr 2018 00:54:19 +0200
Subject: RFR: JDK-8201508: Macosx builds fail in GenerateLinkOptData.gmk
In-Reply-To: <d065bdec-a87b-0a9b-9bbc-bc7ad62fb033@oracle.com>
References: <d065bdec-a87b-0a9b-9bbc-bc7ad62fb033@oracle.com>
Message-ID: <600F5B8B-7AD9-45CE-9688-18F5E3A52F6A@oracle.com>

Looks good to me. Thanks for fixing this. I didn't think there was anything platform dependent in my fix, so I only tested it locally. :( 

/Magnus

> 12 apr. 2018 kl. 23:28 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> All macosx builds in CI currently fail. This is caused by in issue with JDK-8201483 which leaves the JVM_VARIANTS_server variable empty. The construct used to subtract one set of strings from another doesn't work quite as expected with bsd grep.
> 
> result=`$GREP -Fvx "$legal_values" <<< "$values_to_check" | $GREP -v '^$'`
> 
> If the set to subtract ($legal_values) is empty, gnu grep returns all values (as expected) while bsd grep returns nothing. To fix this I've added an explicit check for the base case of legal_values being empty. This seems to make --with-jvm-features work correctly on macosx and still work correctly on Linux. A verification distributed build is under way.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201508
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8201508/webrev.01/
> 
> /Erik
> 



From naoto.sato at oracle.com  Fri Apr 13 00:34:18 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 12 Apr 2018 17:34:18 -0700
Subject: [11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from tzdb
 at build time
Message-ID: <a0fc33b7-7adc-900c-32a8-fd87a32e2da1@oracle.com>

Hi,

Please review the fix to the subject issue. While fixing 8189784 [1], I 
noticed that not only CLDR zones but also tzdb link entries are also 
hard coded. So I further modified j.t.f.ZoneName to generate tzdb 
entries at the build time.

The issue: https://bugs.openjdk.java.net/browse/JDK-8201507
Fix: http://cr.openjdk.java.net/~naoto/8201507/webrev.00/

Like the last time, including build-dev for makefile modification review.

Naoto

[1] http://mail.openjdk.java.net/pipermail/i18n-dev/2018-April/002492.html


From mandy.chung at oracle.com  Fri Apr 13 05:20:14 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 13 Apr 2018 13:20:14 +0800
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ACFBE5C.1080508@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
Message-ID: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com>



On 4/13/18 4:15 AM, Jonathan Gibbons wrote:
> Please review an initial implementation for the feature described in
> JEP 330: Launch Single-File Source-Code Programs.
>
> The work is described in the JEP and CSR, and falls into various parts:
>
> ?* The part to handle the new command-line options is in the native
> ?? Java launcher code.
> ?* The part to invoke the compiler and subsequently execute the code
> ?? found in the source file is in a new class in the jdk.compiler module.
> ?* There are some minor Makefile changes, to add support for a new
> ?? resource file.
>
> There are no changes to javac itself.
>
> JEP: http://openjdk.java.net/jeps/330
> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/

This looks quite good to me.? One small comment on the source launcher 
Main class:

  122         } catch (InvocationTargetException e) {
  123             // leave VM to handle the stacktrace, in the standard manner
  124             throw e.getTargetException();
  125         }

  387         } catch (InvocationTargetException e) {
  388             // remove stack frames for source launcher
  389             int invocationFrames = e.getStackTrace().length;
  390             Throwable target = e.getTargetException();
  391             StackTraceElement[] targetTrace = target.getStackTrace();
  392             target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames));
  393             throw e;
  394         }

This could simply throw target instead of the InvocationTargetException
and then the main method can propagate the target, if thrown.


Mandy


From matthias.baesken at sap.com  Fri Apr 13 05:48:23 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 13 Apr 2018 05:48:23 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
 <7c5e68c2a023490e96ce6452fbda1700@sap.com>
 <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
 <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
Message-ID: <f6dbd54e78714305b78ecd3a3d232f11@sap.com>

Hi Phil/Alexey,  thanks for  adding the other lists .

> Is this the current version of the change :  http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?

Yes.

Best regards, Matthias


> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Donnerstag, 12. April 2018 23:53
> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
> hotspot-dev <hotspot-dev at openjdk.java.net>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> 
> On 12/04/2018 21:42, Phil Race wrote:
> > How can JNIEXPORT be different between 32 bit & 64 bit ?
> > I'm sure you saw compilation errors but I don't get why it failed for
> > 32 only.
> >
> > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
> > explain why the 32 bit compiler would complain about inconsistent
> > application
> > of __declspec(dllexport) - ie JNIEXPORT.
> >
> > Or is that part (adding JNIEXPORT) pure clean up and the compilation
> > errors were all down to JNICALL ?
> 
> Adding missing JNIEXPORT is for cleanup only.
> 
> The compiler complained about mismatched JNICALL / non-JNICALL
> declarations as the macro changes calling convention from the default
> __cdecl? to __stdcall on 32 bit Windows.
> 
> Another issue is that __stdcall decorates the functions: prefixes with
> underscore and postfixes with @ + size of parameters. Because of the
> decorations, classLoader.cpp can't lookup the required functions by name
> from zip.dll and jimage.dll. The functions are exported but with
> different name.
> 
> I hope this information adds more details to the picture.
> 
> > I was a bit puzzled at the removals I saw here :
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
> >
> >
> > .. I needed to look at the whole file to realise that you were
> > removing a duplicate
> > declaration.
> 
> That was tricky. I could have been mentioned in the review.
> 
> 
> Regards,
> Alexey
> 
> >
> > -phil.
> >
> > On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
> >> Hi? Alan , this is the up to date webrev .
> >> However we want to add?? Alexey?? Ivanov? as additional? author .
> >>
> >>> As I read it, this changes the calling convention of these functions on
> >>> 32-bit Windows but it will have no impact on 64-bit Windows (as
> >>> __stdcall is ignored) or other platforms, is that correct?
> >>>
> >> The? change adds? JNIEXPORT?? at some places? where it is? ben
> >> forgotten , for example :
> >>
> >>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
> p/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
> >>
> >>
> >> This might have? potential? impact? on other platforms?? (fixes the
> >> mismatches) .
> >>
> >> Best regards, Matthias
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> >>> Sent: Donnerstag, 12. April 2018 12:54
> >>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> Bursie
> >>> <magnus.ihse.bursie at oracle.com>
> >>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>;
> >>> core-libs-dev at openjdk.java.net
> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function
> >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >>> some places in function declarations/implementations
> >>>
> >>> Adding core-libs-dev as this is change code in libjava, libzip,
> >>> libjimage, ...
> >>>
> >>> Can you confirm that this is the up to date webrev:
> >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> >>>
> >>> As I read it, this changes the calling convention of these functions on
> >>> 32-bit Windows but it will have no impact on 64-bit Windows (as
> >>> __stdcall is ignored) or other platforms, is that correct?
> >>>
> >>> -Alan
> >>>
> >>>
> >>> On 06/04/2018 14:20, Baesken, Matthias wrote:
> >>>> Hello, I just noticed? 2? additonal issues? regarding
> >>>> mapfile-removal :
> >>>>
> >>>>
> >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes
> >>>> as well
> >>> leads on Win32 bit? to? this link error :
> >>>> ??? Creating library
> >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
> >>> object
> >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> >>> referenced in function ___tmainCRTStartup
> >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
> :
> >>> fatal error LNK1120: 1 unresolved externals
> >>>>
> >>>> Looks like we? cannot have?? JNICALL?? in main.c?? :
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05
> >>>> 14:39:04
> >>> 2018 -0700
> >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06
> >>>> 15:16:40
> >>> 2018 +0200
> >>>> @@ -93,7 +93,7 @@
> >>>> ?????? __initenv = _environ;
> >>>>
> >>>> #else /* JAVAW */
> >>>> -JNIEXPORT int JNICALL
> >>>> +JNIEXPORT int
> >>>> main(int argc, char **argv)
> >>>> {
> >>>> ?????? int margc;
> >>>>
> >>>>
> >>>>
> >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are
> >>>> resolved? in
> >>> src/hotspot/share/classfile/classLoader.cpp.
> >>>> I added? the declaration of the missing symbol, this seems to fix it .
> >>>>
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05
> >>>> 14:39:04
> >>> 2018 -0700
> >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06
> >>>> 15:16:40
> >>> 2018 +0200
> >>>> @@ -284,4 +284,7 @@
> >>>> JNIEXPORT jboolean JNICALL
> >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong
> >>>> outLen, char
> >>> **pmsg);
> >>>> +JNIEXPORT jint JNICALL
> >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >>>> +
> >>>>
> >>>>
> >>>> Should I? prepare? another? bug,? or? add this to the existing one
> >>>> and??? post a
> >>> second webrev ?
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>> From: Baesken, Matthias
> >>>> Sent: Freitag, 6. April 2018 09:54
> >>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>
> >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function declarations/implementations - was : RE: missing JNIEXPORT /
> >>> JNICALL at some places in function declarations/implementations
> >>>> Hello, please review :
> >>>>
> >>>> Bug :
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8201226
> >>>>
> >>>> change :
> >>>>
> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>
> >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the
> win32bit
> >>> build missed it .
> >>>> A difference is
> >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> >>>> Where I removed?? a few? declarations (one? decl?? with one without
> >>> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >>>> Best regards , Matthias
> >>>>
> >>>>
> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>>> Sent: Donnerstag, 5. April 2018 17:45
> >>>> To: Baesken, Matthias
> >>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
> >>>> Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>;
> >>> Doerr, Martin
> <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
> >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
> >>> declarations/implementations
> >>>> That's most likely a result of the new JNIEXPORT I added as part of
> >>>> the
> >>> mapfile removal.
> >>>> I tried to match header file and C file, but I can certainly have
> >>>> missed cases.
> >>> If I didn't get any warnings, it was hard to know what I missed.
> >>>> Please do submit your patch.
> >>>>
> >>>> I'm a bit surprised 32-bit Window is still buildable. :)
> >>>>
> >>>> /Magnus
> >>>>
> >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> >>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
> >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the
> >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one
> compares
> >>> the declaration and
> >>>> The implementation of functions.
> >>>> While this is ok on most platforms, it seems to fail on Windows 32
> >>>> bit and
> >>> leads to errors like this one :
> >>>>
> >>>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> >>>
> >>> ib_ImageConvKernelConvert.c(87) : error C2373:
> >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
> >>> modifiers
> >>>
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> >>>
> >>> ib_image_proto.h(2630) : see declaration of
> >>> 'j2d_mlib_ImageConvKernelConvert'
> >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.)
> >>>>
> >>>>
> >>>> Another example is this one :
> >>>>
> >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05
> >>>> 09:55:16
> >>> 2018 +0200
> >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05
> >>> 17:07:40 2018 +0200
> >>>> @@ -126,7 +126,7 @@
> >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image,
> >>>> ??? *??????????????????????????????? "java.base", "9.0",
> >>>> "java/lang/String.class", &size);
> >>>> ??? */
> >>>> -extern "C" JNIEXPORT JImageLocationRef
> >>> JIMAGE_FindResource(JImageFile* jimage,
> >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
> >>> JIMAGE_FindResource(JImageFile* jimage,
> >>>> ?????????? const char* module_name, const char* version, const
> >>>> char* name,
> >>>> ?????????? jlong* size);
> >>>>
> >>>>
> >>>> Is there some generic way to get? the? same? declarations /
> >>>> impementations
> >>> in the code? ?
> >>>> Or should I just add a patch with my findings ?
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >


From volker.simonis at gmail.com  Fri Apr 13 07:03:28 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Apr 2018 09:03:28 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing
 unresolved symbols
In-Reply-To: <1523434677.4440.8.camel@redhat.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
 <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>
 <1523434677.4440.8.camel@redhat.com>
Message-ID: <CA+3eh10srbDWk_PtajagV66QxNqQp3RaYwntkcwV_ZH-XLfzFg@mail.gmail.com>

Hi Severin,

I'm currently looking at the AIX-side of this bug.

The problem I see with your solution is that it uses LDFLAGS (which is
generic) to filter out Linux specific linker flags. If we would extend
this to AIX, we would have to add yet another substitution for AIX
which filters out "-Wl,bernotok". This is not beautiful and gets
uglier with every new platform.

But as this change has already been pushed and because (fortunately)
on AIX options which come later on the command line take precedence
over earlier ones I can easily fix this with a specific LDFLAGS_aix
setting. I've opened "8201524: [AIX] Don't link libfontmanager against
libawt_headless" [1] for it and I'll send out a new RFR for it soon.

Regards,
Volker

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


On Wed, Apr 11, 2018 at 10:17 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote:
>> LIBS_aix := -lawt_headless,
>> I guess that AIX team should have a similar fix.
>
> Possibly. I have no way of testing it, though. So will leave it to AIX
> folk to have a look. My experience was that it isn't easily
> reproducible. Some observations:
>
>    1. Run swing app such as SwingSet2 on a headfull system. Since
>       fontmanager will have a link dep on lawt_headless, and awt code
>       loads libawt_xawt (headfull) on a headfull system, both libraries
>       providing symbols needed by libfontmanager will be loaded. Then it
>       depends whether this is a problem on that particular system or not.
>       In my experience this worked on some systems and not on others.
>    2. Solaris was build-time linking to libawt_headless causing bug
>       8194870. So build-time linking got removed with that bug. Not sure
>       why that bug is private :(
>
> Thanks,
> Severin
>
>> On 10/04/2018 09:34, Erik Joelsson wrote:
>> > Looks good. Thanks!
>> >
>> > /Erik
>> >
>> >
>> > On 2018-04-10 04:25, Severin Gehwolf wrote:
>> > > Hi Erik,
>> > >
>> > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
>> > > > Hello Severin,
>> > > >
>> > > > I'm ok with this solution for now.
>> > >
>> > > Thanks for the review!
>> > >
>> > > > Could you please reduce the indentation on line 652. In the
>> > > > build system
>> > > > we like 4 spaces for continuation indent [1]
>> > >
>> > > Done. New webrev at:
>> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0
>> > > 2
>> > >
>> > > Could someone from awt-dev have a look at this too? Thanks!
>> > >
>> > > Cheers,
>> > > Severin
>> > >
>> > > > /Erik
>> > > >
>> > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h
>> > > > tml
>> > > >
>> > > > On 2018-04-09 06:39, Severin Gehwolf wrote:
>> > > > > Hi,
>> > > > >
>> > > > > Could somebody please review this build fix for
>> > > > > libfontmanager.so. The
>> > > > > issue for us is that with some LDFLAGS the build breaks as
>> > > > > described in
>> > > > > bug JDK-8196218. However, we cannot link to a providing
>> > > > > library at
>> > > > > build-time since we don't know which one it should be:
>> > > > > libawt_headless
>> > > > > or libawt_xawt. That has to happen at runtime. The proposed
>> > > > > fix filters
>> > > > > out relevant linker flags when libfontmanager is being built.
>> > > > > More
>> > > > > details are in the bug.
>> > > > >
>> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
>> > > > > webrev:
>> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr
>> > > > > ev.01/
>> > > > >
>> > > > > Testing: I've run this through submit[1] and got the
>> > > > > following results.
>> > > > > SwingSet2 works fine for me on F27. I'm currently running
>> > > > > some more
>> > > > > tests on RHEL 7.
>> > > > >
>> > > > > ---------------------
>> > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877:
>> > > > > Builds
>> > > > > PASSED. Testing FAILURE.
>> > > > >
>> > > > > 0 Failed Tests
>> > > > >
>> > > > > Mach5 Tasks Results Summary
>> > > > >
>> > > > > NA: 0
>> > > > > UNABLE_TO_RUN: 0
>> > > > > EXECUTED_WITH_FAILURE: 0
>> > > > > KILLED: 0
>> > > > > PASSED: 82
>> > > > > FAILED: 1
>> > > > > Test
>> > > > >
>> > > > > 1 Failed
>> > > > >
>> > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-
>> > > > > windows-x64-
>> > > > > debug-31 SetupFailedException in setup...profile run-test-
>> > > > > prebuilt' ,
>> > > > > return value: 10
>> > > > > --------------------
>> > > > >
>> > > > > Not sure what this test failure means. Could somebody at
>> > > > > Oracle shed
>> > > > > some light on this?
>> > > > >
>> > > > > Thanks,
>> > > > > Severin
>>
>>


From volker.simonis at gmail.com  Fri Apr 13 07:25:51 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Apr 2018 09:25:51 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
 <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
 <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
Message-ID: <CA+3eh129KP9BOGx99o4Db7pb5DxQtvv-_rjpkDnpQ5WL9Jy3qQ@mail.gmail.com>

On Thu, Apr 12, 2018 at 11:30 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
>>
>> On 2018-04-12 14:15, David Holmes wrote:
>>>
>>> Hi Magnus,
>>>
>>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>>>
>>>> It is currently easy to add new JVM features to the JVM build, but it is
>>>> not possible to remove features.
>>>>
>>>> With this change, features can be both added or removed from the default
>>>> set. They are added using --with-jvm-features=f1,f2 and removed using
>>>> --with-jvm-features=-f1,-f2. The syntax can be combined, so
>>>> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory
>>>> tracking.
>>>
>>>
>>> I need to point out that we have never tested disabling individual VM
>>> features likes this. They are either all on, or all off for the minimal VM!
>>> There may be implicit dependencies between features.
>>
>>
>> Well, I have. :-) However, I don't do that regularly, and changes might
>> very well have crept in. As always, if you build something non-standard that
>> is not regularly tested, you're on your own.
>
>
> Feels to me like you've taken away the safety-fence and are encouraging
> people to attempt these unsupported configurations. Whether that was your
> intent or not.

I think that would be great. If people would try out different
configurations AND fix them that would be a great code clean-up for
HotSpot. I've recently tried various "unsupported" configurations
(i.e. minimal plus some selected features) and found that the
resulting build failures are mostly artificial because the
corresponding features aren't correctly ifdefed.

>
>> In any case, the purpose of this is not so much to disable existing JVM
>> features (after all, no one has really been missing this functionality), as
>> to pave the way for the upcoming patch for including/excluding individual
>> GCs.
>
>
> Surely a GC selection flag would have sufficed.
>
> David
>
>
>> /Magnus
>>
>>>
>>> David
>>>
>>>> I also included some additional code cleanup and fixes, such as printing
>>>> the JVM feature set at the summary.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>>>
>>
>


From sgehwolf at redhat.com  Fri Apr 13 07:33:10 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Apr 2018 09:33:10 +0200
Subject: RFR: 8196516: libfontmanager must be built with LDFLAGS
 allowing unresolved symbols
In-Reply-To: <CA+3eh10srbDWk_PtajagV66QxNqQp3RaYwntkcwV_ZH-XLfzFg@mail.gmail.com>
References: <1523281192.148486.9.camel@redhat.com>
 <b26ac297-d14e-e462-7111-7a52d796633d@oracle.com>
 <1523359536.4542.2.camel@redhat.com>
 <f8d612d8-ffc4-00a2-3538-8785e5fc94a9@oracle.com>
 <6f11a22e-cf96-24c5-a524-2c82c0b0fc36@oracle.com>
 <1523434677.4440.8.camel@redhat.com>
 <CA+3eh10srbDWk_PtajagV66QxNqQp3RaYwntkcwV_ZH-XLfzFg@mail.gmail.com>
Message-ID: <1523604790.4177.5.camel@redhat.com>

Hi Volker,

On Fri, 2018-04-13 at 09:03 +0200, Volker Simonis wrote:
> Hi Severin,
> 
> I'm currently looking at the AIX-side of this bug.
> 
> The problem I see with your solution is that it uses LDFLAGS (which is
> generic) to filter out Linux specific linker flags. If we would extend
> this to AIX, we would have to add yet another substitution for AIX
> which filters out "-Wl,bernotok". This is not beautiful and gets
> uglier with every new platform.

Right. Note, though, that Magnus seems to be working on a more
comprehensive solution to this:
http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021625.html

FWIW, the substitution for -Wl,-z,defs was there in LDFLAGS all along
(it was missing the other syntax). Not sure if -Wl,-z,defs is generic
enough to warrant it being on LDFLAGS directly, not LDFLAGS_linux or
some other OS specific variant. Either way, that's the model I've
followed.

Thanks,
Severin

> But as this change has already been pushed and because (fortunately)
> on AIX options which come later on the command line take precedence
> over earlier ones I can easily fix this with a specific LDFLAGS_aix
> setting. I've opened "8201524: [AIX] Don't link libfontmanager against
> libawt_headless" [1] for it and I'll send out a new RFR for it soon.
> 
> Regards,
> Volker
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8201524
> 
> 
> On Wed, Apr 11, 2018 at 10:17 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > On Tue, 2018-04-10 at 14:51 -0700, Sergey Bylokhov wrote:
> > > LIBS_aix := -lawt_headless,
> > > I guess that AIX team should have a similar fix.
> > 
> > Possibly. I have no way of testing it, though. So will leave it to AIX
> > folk to have a look. My experience was that it isn't easily
> > reproducible. Some observations:
> > 
> >    1. Run swing app such as SwingSet2 on a headfull system. Since
> >       fontmanager will have a link dep on lawt_headless, and awt code
> >       loads libawt_xawt (headfull) on a headfull system, both libraries
> >       providing symbols needed by libfontmanager will be loaded. Then it
> >       depends whether this is a problem on that particular system or not.
> >       In my experience this worked on some systems and not on others.
> >    2. Solaris was build-time linking to libawt_headless causing bug
> >       8194870. So build-time linking got removed with that bug. Not sure
> >       why that bug is private :(
> > 
> > Thanks,
> > Severin
> > 
> > > On 10/04/2018 09:34, Erik Joelsson wrote:
> > > > Looks good. Thanks!
> > > > 
> > > > /Erik
> > > > 
> > > > 
> > > > On 2018-04-10 04:25, Severin Gehwolf wrote:
> > > > > Hi Erik,
> > > > > 
> > > > > On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote:
> > > > > > Hello Severin,
> > > > > > 
> > > > > > I'm ok with this solution for now.
> > > > > 
> > > > > Thanks for the review!
> > > > > 
> > > > > > Could you please reduce the indentation on line 652. In the
> > > > > > build system
> > > > > > we like 4 spaces for continuation indent [1]
> > > > > 
> > > > > Done. New webrev at:
> > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.0
> > > > > 2
> > > > > 
> > > > > Could someone from awt-dev have a look at this too? Thanks!
> > > > > 
> > > > > Cheers,
> > > > > Severin
> > > > > 
> > > > > > /Erik
> > > > > > 
> > > > > > [1] http://openjdk.java.net/groups/build/doc/code-conventions.h
> > > > > > tml
> > > > > > 
> > > > > > On 2018-04-09 06:39, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Could somebody please review this build fix for
> > > > > > > libfontmanager.so. The
> > > > > > > issue for us is that with some LDFLAGS the build breaks as
> > > > > > > described in
> > > > > > > bug JDK-8196218. However, we cannot link to a providing
> > > > > > > library at
> > > > > > > build-time since we don't know which one it should be:
> > > > > > > libawt_headless
> > > > > > > or libawt_xawt. That has to happen at runtime. The proposed
> > > > > > > fix filters
> > > > > > > out relevant linker flags when libfontmanager is being built.
> > > > > > > More
> > > > > > > details are in the bug.
> > > > > > > 
> > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
> > > > > > > webrev:
> > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webr
> > > > > > > ev.01/
> > > > > > > 
> > > > > > > Testing: I've run this through submit[1] and got the
> > > > > > > following results.
> > > > > > > SwingSet2 works fine for me on F27. I'm currently running
> > > > > > > some more
> > > > > > > tests on RHEL 7.
> > > > > > > 
> > > > > > > ---------------------
> > > > > > > Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877:
> > > > > > > Builds
> > > > > > > PASSED. Testing FAILURE.
> > > > > > > 
> > > > > > > 0 Failed Tests
> > > > > > > 
> > > > > > > Mach5 Tasks Results Summary
> > > > > > > 
> > > > > > > NA: 0
> > > > > > > UNABLE_TO_RUN: 0
> > > > > > > EXECUTED_WITH_FAILURE: 0
> > > > > > > KILLED: 0
> > > > > > > PASSED: 82
> > > > > > > FAILED: 1
> > > > > > > Test
> > > > > > > 
> > > > > > > 1 Failed
> > > > > > > 
> > > > > > > tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-
> > > > > > > windows-x64-
> > > > > > > debug-31 SetupFailedException in setup...profile run-test-
> > > > > > > prebuilt' ,
> > > > > > > return value: 10
> > > > > > > --------------------
> > > > > > > 
> > > > > > > Not sure what this test failure means. Could somebody at
> > > > > > > Oracle shed
> > > > > > > some light on this?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> > > 
> > > 


From magnus.ihse.bursie at oracle.com  Fri Apr 13 07:40:33 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 13 Apr 2018 09:40:33 +0200
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
 <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
 <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
Message-ID: <8ad25d04-d066-80e7-4283-c275a1855f98@oracle.com>

On 2018-04-12 23:30, David Holmes wrote:
> On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
>> On 2018-04-12 14:15, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>>> It is currently easy to add new JVM features to the JVM build, but 
>>>> it is not possible to remove features.
>>>>
>>>> With this change, features can be both added or removed from the 
>>>> default set. They are added using --with-jvm-features=f1,f2 and 
>>>> removed using --with-jvm-features=-f1,-f2. The syntax can be 
>>>> combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but 
>>>> disable native memory tracking.
>>>
>>> I need to point out that we have never tested disabling individual 
>>> VM features likes this. They are either all on, or all off for the 
>>> minimal VM! There may be implicit dependencies between features.
>>
>> Well, I have. :-) However, I don't do that regularly, and changes 
>> might very well have crept in. As always, if you build something 
>> non-standard that is not regularly tested, you're on your own.
>
> Feels to me like you've taken away the safety-fence and are 
> encouraging people to attempt these unsupported configurations. 
> Whether that was your intent or not.

It is always possible to configure something that does not work. :-) We 
can make it more easy to do the right thing, but if we were to make 
impossible everything that has not been tested, then we would also make 
things impossible that are needed for some use cases.

Wrt JVM features, this has *always* been possible. If you use 
"--with-jvm-variants=custom --with-jvm-features=jvmti,nmt" then you 
*are* going to build an almost (or fully?) useless JVM. In fact, this 
method made it *much* harder to try to get a functioning JVM without a 
specific feature.

I think I should update the build documentation regarding JVM features 
though, and I can definitely add some wisely worded warnings about 
unsupported combinations of features, especially if removing them.

>
>> In any case, the purpose of this is not so much to disable existing 
>> JVM features (after all, no one has really been missing this 
>> functionality), as to pave the way for the upcoming patch for 
>> including/excluding individual GCs.
>
> Surely a GC selection flag would have sufficed.
It was the common agreement of both the build team and the GC folks 
responsive for the upcoming selectively GC inclusion patch, that this 
was better handled as JVM features than a separate GC flag.

/Magnus
>
> David
>
>> /Magnus
>>
>>>
>>> David
>>>
>>>> I also included some additional code cleanup and fixes, such as 
>>>> printing the JVM feature set at the summary.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01 
>>>>
>>>>
>>



From jan.lahoda at oracle.com  Fri Apr 13 09:08:38 2018
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 13 Apr 2018 11:08:38 +0200
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ACFBE5C.1080508@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
Message-ID: <5AD07396.1050908@oracle.com>

The javac part looks OK to me.

A nit comment, in:
launcher/Main.java/MemoryFileManager#createInMemoryClassFile, there is:
return new FilterOutputStream(new ByteArrayOutputStream()) { ...

It could I think be written as:
return new ByteArrayOutputStream() {
     @Override
     public void close() throws IOException {
         super.close();
  	byte[] bytes = toByteArray();
  	map.put(className, bytes);
     }
};

(I.e. without the cast to ByteArrayOutputStream.)

Jan

On 12.4.2018 22:15, Jonathan Gibbons wrote:
> Please review an initial implementation for the feature described in
> JEP 330: Launch Single-File Source-Code Programs.
>
> The work is described in the JEP and CSR, and falls into various parts:
>
>   * The part to handle the new command-line options is in the native
>     Java launcher code.
>   * The part to invoke the compiler and subsequently execute the code
>     found in the source file is in a new class in the jdk.compiler module.
>   * There are some minor Makefile changes, to add support for a new
>     resource file.
>
> There are no changes to javac itself.
>
> JEP: http://openjdk.java.net/jeps/330
> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>
> -- Jon


From maurizio.cimadamore at oracle.com  Fri Apr 13 10:43:28 2018
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 13 Apr 2018 11:43:28 +0100
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <a96d7ce1-291b-67fc-98fc-d611451f1ba8@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
 <a96d7ce1-291b-67fc-98fc-d611451f1ba8@oracle.com>
Message-ID: <4913267c-9341-29e8-611c-b8e7766a733a@oracle.com>

One small followup question - the test SourceLauncherTest is not 
covering any shebang cases - is that deliberate? I see that those seem 
to be covered in the launcher test too, but I wonder if we should have 
tests for clearly broken stuff, such as

'#'

'#!'

'#!\n'

Another small question - I see that the shebang process essentially 
replaces the first line separator with \n - that is probably ok given 
that the file is processed internally after that - but I wonder if you 
have thought about pros and cons of preserving the original line separator.

Cheers
Maurizio


On 12/04/18 21:46, Maurizio Cimadamore wrote:
> Looks great - some initial comments (I can't really comment on the 
> launcher changes):
>
> * This logic is efficient:
>
> int magic = (in.read() << 8) + in.read();
> boolean shebang = magic == (('#' << 8) + '!');
>
> but convoluted to read; perhaps could be improved slightly by making 
> '#' << 8) + '!' a static constant, and comparing against that.
>
> * I note that the reading logic in general could be simplified, e.g. 
> using Files.lines(Path) - but I assume that you wrote the code as is 
> for performance reasons (e.g. to avoid creating too many string 
> objects) ?
>
> * I see that both the file manager and the class loader reasonably 
> share the same context: a Map<String, byte[]>. I would make this more 
> explicit, by having a Context class, whose state is the map, and then 
> have the context provide two methods:
>
> getClassLoader()
> getFileManager()
>
> This way the sharing will be automatic, no need to extract one field 
> from one place and pass it over to the other place.
>
> * Big whohoo for being able to use the enhanced diagnostic framework 
> with a couple of tweaks on the makefile - I hope that would have been 
> the case when I put in the support, but since we have never done it - 
> wasn't 100% sure it would work ;-)
>
>
> Overall I like it quite a lot and I think you went for a really clean 
> design - kudos!
>
> Maurizio
>
>
>
> On 12/04/18 21:15, Jonathan Gibbons wrote:
>> Please review an initial implementation for the feature described in
>> JEP 330: Launch Single-File Source-Code Programs.
>>
>> The work is described in the JEP and CSR, and falls into various parts:
>>
>> ? * The part to handle the new command-line options is in the native
>> ??? Java launcher code.
>> ? * The part to invoke the compiler and subsequently execute the code
>> ??? found in the source file is in a new class in the jdk.compiler 
>> module.
>> ? * There are some minor Makefile changes, to add support for a new
>> ??? resource file.
>>
>> There are no changes to javac itself.
>>
>> JEP: http://openjdk.java.net/jeps/330
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
>> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>>
>> -- Jon
>



From sgehwolf at redhat.com  Fri Apr 13 11:17:25 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Apr 2018 13:17:25 +0200
Subject: Invalid use of -m32 on certain targets
In-Reply-To: <793377E2-04B4-4165-831C-DE1825D2B9ED@oracle.com>
References: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
 <793377E2-04B4-4165-831C-DE1825D2B9ED@oracle.com>
Message-ID: <1523618245.4177.12.camel@redhat.com>

On Thu, 2018-04-12 at 18:56 +0200, Magnus Ihse Bursie wrote:
> > 12 apr. 2018 kl. 15:49 skrev John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>:
> > 
> > Hi!
> > 
> > I have been playing around with Zero on new (old) architectures and one
> > of them is hppa, which needs some additional work due to its stack growing
> > from bottom to top but that's another story.
> > 
> > Anyway, adding hppa to platform.m4 and running configure results in the
> > following error message:
> > 
> > configure:35290: checking whether the C compiler works
> > configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32    -m32   conftest.c  >&5
> > hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> > hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> > configure:35316: $? = 1
> > configure:35354: result: no
> > configure: failed program was:
> > 
> > Didn't we recently have the discussion about which target gcc versions
> > understand "-m32" and which don't? Apparently, someone thought hppa's
> > gcc supports that option but apparently it doesn't.
> > 
> > Was there any conclusion on this discussion? I remember that some
> > people mentioned that the current situation is not ideal.
> 
> I agree. It's not ideal, and should be fixed. It's on my todo list
> but keep sinking to the bottom. If you want, you can open a bug on it
> and I just might get around to it a bit quicker. :)

I've just attempted "configure" on s390 and here is what I get:
configure:35266: checking whether the C compiler works
configure:35288: /usr/bin/gcc -m32    -m32   conftest.c  >&5
gcc: error: unrecognized command line option '-m32'
gcc: error: unrecognized command line option '-m32'
configure:35292: $? = 1
configure:35330: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:35335: error: in `/jdk-hs':
configure:35337: error: C compiler cannot create executables

Indeed:
<mock-chroot> sh-4.2# gcc -m32 conftest.c 
gcc: error: unrecognized command line option ?-m32?
<mock-chroot> sh-4.2# echo $?
1
<mock-chroot> sh-4.2# gcc conftest.c
<mock-chroot> sh-4.2# echo $?
0 

This must have broken recently :( I'll take a look. As it's preventing
me to test JDK-8201495

Is there a bug for this already?

Thanks,
Severin


> /Magnus
> 
> > 
> > Adrian
> > 
> > -- 
> > .''`.  John Paul Adrian Glaubitz
> > : :' :  Debian Developer - glaubitz at debian.org
> > `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> >  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> > 
> 
> 


From sgehwolf at redhat.com  Fri Apr 13 12:16:28 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Apr 2018 14:16:28 +0200
Subject: Invalid use of -m32 on certain targets
In-Reply-To: <1523618245.4177.12.camel@redhat.com>
References: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
 <793377E2-04B4-4165-831C-DE1825D2B9ED@oracle.com>
 <1523618245.4177.12.camel@redhat.com>
Message-ID: <1523621788.4177.13.camel@redhat.com>

On Fri, 2018-04-13 at 13:17 +0200, Severin Gehwolf wrote:
> On Thu, 2018-04-12 at 18:56 +0200, Magnus Ihse Bursie wrote:
> > > 12 apr. 2018 kl. 15:49 skrev John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de>:
> > > 
> > > Hi!
> > > 
> > > I have been playing around with Zero on new (old) architectures and one
> > > of them is hppa, which needs some additional work due to its stack growing
> > > from bottom to top but that's another story.
> > > 
> > > Anyway, adding hppa to platform.m4 and running configure results in the
> > > following error message:
> > > 
> > > configure:35290: checking whether the C compiler works
> > > configure:35312: /usr/bin/hppa-linux-gnu-gcc -m32    -m32   conftest.c  >&5
> > > hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> > > hppa-linux-gnu-gcc: error: unrecognized command line option '-m32'
> > > configure:35316: $? = 1
> > > configure:35354: result: no
> > > configure: failed program was:
> > > 
> > > Didn't we recently have the discussion about which target gcc versions
> > > understand "-m32" and which don't? Apparently, someone thought hppa's
> > > gcc supports that option but apparently it doesn't.
> > > 
> > > Was there any conclusion on this discussion? I remember that some
> > > people mentioned that the current situation is not ideal.
> > 
> > I agree. It's not ideal, and should be fixed. It's on my todo list
> > but keep sinking to the bottom. If you want, you can open a bug on it
> > and I just might get around to it a bit quicker. :)
> 
> I've just attempted "configure" on s390 and here is what I get:
> configure:35266: checking whether the C compiler works
> configure:35288: /usr/bin/gcc -m32    -m32   conftest.c  >&5
> gcc: error: unrecognized command line option '-m32'
> gcc: error: unrecognized command line option '-m32'
> configure:35292: $? = 1
> configure:35330: result: no
> configure: failed program was:
> > /* confdefs.h */
> > #define PACKAGE_NAME "OpenJDK"
> > #define PACKAGE_TARNAME "openjdk"
> > #define PACKAGE_VERSION "jdk9"
> > #define PACKAGE_STRING "OpenJDK jdk9"
> > #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
> > #define PACKAGE_URL "http://openjdk.java.net"
> > /* end confdefs.h.  */
> > 
> > int
> > main ()
> > {
> > 
> >   ;
> >   return 0;
> > }
> 
> configure:35335: error: in `/jdk-hs':
> configure:35337: error: C compiler cannot create executables
> 
> Indeed:
> <mock-chroot> sh-4.2# gcc -m32 conftest.c 
> gcc: error: unrecognized command line option ?-m32?
> <mock-chroot> sh-4.2# echo $?
> 1
> <mock-chroot> sh-4.2# gcc conftest.c
> <mock-chroot> sh-4.2# echo $?
> 0 
> 
> This must have broken recently :( I'll take a look. As it's preventing
> me to test JDK-8201495
> 
> Is there a bug for this already?

Here is one:
https://bugs.openjdk.java.net/browse/JDK-8201536

Cheers,
Severin

> Thanks,
> Severin
> 
> 
> > /Magnus
> > 
> > > 
> > > Adrian
> > > 
> > > -- 
> > > .''`.  John Paul Adrian Glaubitz
> > > : :' :  Debian Developer - glaubitz at debian.org
> > > `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> > >  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> > > 
> > 
> > 


From volker.simonis at gmail.com  Fri Apr 13 13:28:53 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Apr 2018 15:28:53 +0200
Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against
 libawt_headless
Message-ID: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>

Hi,

can I please have a review for this tiny AIX cleanup:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
https://bugs.openjdk.java.net/browse/JDK-8201524

This is a follow up change of JDK-8196516 which discovered that on AIX
libfontmanager is always linked against libawt_headless at build time.
If we are running in a headfull environment, libfontmanager will
dynamically load libawt_xawt which is not good because libawt_headless
and libawt_xawt define some common symbols. If we're running in a
headless environment, libawt_headless may be loaded a second time (at
least on Linux/Solaris) which isn't good either.

Both of these scenarios haven't caused any problems on AIX yet, but I
think it's good to cleanup the AIX implementation as well and don't
link libfontmanager against libawt_headless anymore. In order to
achieve this, we have to allow unresolved symbols during the linking
of libfontmanager. This can be easily achieved by adding the additions
linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
for AIX because options which come later on the command line take
precedence
over earlier ones.

Thank you and best regards,
Volker


From david.holmes at oracle.com  Fri Apr 13 13:31:33 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Apr 2018 23:31:33 +1000
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <CA+3eh129KP9BOGx99o4Db7pb5DxQtvv-_rjpkDnpQ5WL9Jy3qQ@mail.gmail.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
 <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
 <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
 <CA+3eh129KP9BOGx99o4Db7pb5DxQtvv-_rjpkDnpQ5WL9Jy3qQ@mail.gmail.com>
Message-ID: <14c60071-8c68-192d-d5ae-7fc6f0e20a70@oracle.com>



On 13/04/2018 5:25 PM, Volker Simonis wrote:
> On Thu, Apr 12, 2018 at 11:30 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
>>>
>>> On 2018-04-12 14:15, David Holmes wrote:
>>>>
>>>> Hi Magnus,
>>>>
>>>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>> It is currently easy to add new JVM features to the JVM build, but it is
>>>>> not possible to remove features.
>>>>>
>>>>> With this change, features can be both added or removed from the default
>>>>> set. They are added using --with-jvm-features=f1,f2 and removed using
>>>>> --with-jvm-features=-f1,-f2. The syntax can be combined, so
>>>>> --with-jvm-features=dtrace,-nmt will enable dtrace but disable native memory
>>>>> tracking.
>>>>
>>>>
>>>> I need to point out that we have never tested disabling individual VM
>>>> features likes this. They are either all on, or all off for the minimal VM!
>>>> There may be implicit dependencies between features.
>>>
>>>
>>> Well, I have. :-) However, I don't do that regularly, and changes might
>>> very well have crept in. As always, if you build something non-standard that
>>> is not regularly tested, you're on your own.
>>
>>
>> Feels to me like you've taken away the safety-fence and are encouraging
>> people to attempt these unsupported configurations. Whether that was your
>> intent or not.
> 
> I think that would be great. If people would try out different
> configurations AND fix them that would be a great code clean-up for
> HotSpot. I've recently tried various "unsupported" configurations
> (i.e. minimal plus some selected features) and found that the
> resulting build failures are mostly artificial because the
> corresponding features aren't correctly ifdefed.

These features were never expected to be individually selectable. The 
minimal VM was a special case. There is likely more work needed than 
just build time ifdefs to allow this to actually work.

For fun try building on 64-bit and ask for no compiler2 to see what 
happens. It makes no sense. But there are no constraints implemented so 
you can ask for nonsensical things. That's not a good thing in my book.

David
-----


> 
>>
>>> In any case, the purpose of this is not so much to disable existing JVM
>>> features (after all, no one has really been missing this functionality), as
>>> to pave the way for the upcoming patch for including/excluding individual
>>> GCs.
>>
>>
>> Surely a GC selection flag would have sufficed.
>>
>> David
>>
>>
>>> /Magnus
>>>
>>>>
>>>> David
>>>>
>>>>> I also included some additional code cleanup and fixes, such as printing
>>>>> the JVM feature set at the summary.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>>>> WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01
>>>>>
>>>
>>


From glaubitz at physik.fu-berlin.de  Fri Apr 13 13:37:46 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 13 Apr 2018 15:37:46 +0200
Subject: Invalid use of -m32 on certain targets
In-Reply-To: <1523621788.4177.13.camel@redhat.com>
References: <be5e97d0-b7ac-af0c-eb24-577c96899508@physik.fu-berlin.de>
 <793377E2-04B4-4165-831C-DE1825D2B9ED@oracle.com>
 <1523618245.4177.12.camel@redhat.com> <1523621788.4177.13.camel@redhat.com>
Message-ID: <e26afdce-2abf-435a-ff43-1d2207872c1f@physik.fu-berlin.de>

Hi Severin!

On 04/13/2018 02:16 PM, Severin Gehwolf wrote:
>> Is there a bug for this already?
> 
> Here is one:
> https://bugs.openjdk.java.net/browse/JDK-8201536
Great, thank you. I couldn't reply earlier as I was just on my way.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From david.holmes at oracle.com  Fri Apr 13 13:40:29 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Apr 2018 23:40:29 +1000
Subject: RFR: JDK-8201483 Make it possible to disable JVM features
In-Reply-To: <8ad25d04-d066-80e7-4283-c275a1855f98@oracle.com>
References: <ccc9f875-d5ad-961b-ba9c-8841d3dbe7f0@oracle.com>
 <4bea6ae2-7f61-5c06-1957-9a4dd089dc07@oracle.com>
 <221626a1-5a7d-95eb-8d82-faeba2963899@oracle.com>
 <401023d5-f97b-45db-85de-b3051c7de2d2@oracle.com>
 <8ad25d04-d066-80e7-4283-c275a1855f98@oracle.com>
Message-ID: <c394da06-6f4b-b723-cd72-085361513193@oracle.com>



On 13/04/2018 5:40 PM, Magnus Ihse Bursie wrote:
> On 2018-04-12 23:30, David Holmes wrote:
>> On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
>>> On 2018-04-12 14:15, David Holmes wrote:
>>>> Hi Magnus,
>>>>
>>>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>>>> It is currently easy to add new JVM features to the JVM build, but 
>>>>> it is not possible to remove features.
>>>>>
>>>>> With this change, features can be both added or removed from the 
>>>>> default set. They are added using --with-jvm-features=f1,f2 and 
>>>>> removed using --with-jvm-features=-f1,-f2. The syntax can be 
>>>>> combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but 
>>>>> disable native memory tracking.
>>>>
>>>> I need to point out that we have never tested disabling individual 
>>>> VM features likes this. They are either all on, or all off for the 
>>>> minimal VM! There may be implicit dependencies between features.
>>>
>>> Well, I have. :-) However, I don't do that regularly, and changes 
>>> might very well have crept in. As always, if you build something 
>>> non-standard that is not regularly tested, you're on your own.
>>
>> Feels to me like you've taken away the safety-fence and are 
>> encouraging people to attempt these unsupported configurations. 
>> Whether that was your intent or not.
> 
> It is always possible to configure something that does not work. :-) We 
> can make it more easy to do the right thing, but if we were to make 
> impossible everything that has not been tested, then we would also make 
> things impossible that are needed for some use cases.

I don't buy that.

> Wrt JVM features, this has *always* been possible. If you use 
> "--with-jvm-variants=custom --with-jvm-features=jvmti,nmt" then you 
> *are* going to build an almost (or fully?) useless JVM. In fact, this 
> method made it *much* harder to try to get a functioning JVM without a 
> specific feature.

I have no recollection of jvm variant "custom" being introduced.

> 
> I think I should update the build documentation regarding JVM features 
> though, and I can definitely add some wisely worded warnings about 
> unsupported combinations of features, especially if removing them.

If you can document what the allowed configurations are then you should 
be able to add constraints that only allows supported sets of features. 
This is what the original set of JVM variants provided - it was fixed 
not arbitrary! As I said I don't recall you adding the "custom" option. :(

>>
>>> In any case, the purpose of this is not so much to disable existing 
>>> JVM features (after all, no one has really been missing this 
>>> functionality), as to pave the way for the upcoming patch for 
>>> including/excluding individual GCs.
>>
>> Surely a GC selection flag would have sufficed.
> It was the common agreement of both the build team and the GC folks 
> responsive for the upcoming selectively GC inclusion patch, that this 
> was better handled as JVM features than a separate GC flag.

Maybe something that affects all of hotspot should have been discussed 
more broadly.

David
-----

> /Magnus
>>
>> David
>>
>>> /Magnus
>>>
>>>>
>>>> David
>>>>
>>>>> I also included some additional code cleanup and fixes, such as 
>>>>> printing the JVM feature set at the summary.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01 
>>>>>
>>>>>
>>>
> 


From sgehwolf at redhat.com  Fri Apr 13 13:40:47 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Apr 2018 15:40:47 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390
Message-ID: <1523626847.4177.22.camel@redhat.com>

Hi,

We (Red Hat) have been building Zero on s390 for a while now. In order
to do so we needed to have this patch to reduce the maximum heap size
setting for big workloads. Otherwise we see this during (JDK 9) builds:

++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
Error occurred during initialization of VM
Could not reserve enough space for 1048576KB object heap

NOTE: JDK 9 has the same build logic than JDK 11 in terms of big
workloads' JVM switches.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201495
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.01/

Testing: Run configure on s390 and inspected the big workloads settings:

Before:
checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768

After:
checking flags for bootcycle boot jdk java command for big workloads... -Xms256M -Xmx768M -XX:ThreadStackSize=768

This should be fairly low risk, since the check is guarded by s390
archicture checks. Other architectures should be unaffected.

Thanks,
Severin


From christoph.langer at sap.com  Fri Apr 13 14:28:16 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Apr 2018 14:28:16 +0000
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against	libawt_headless
In-Reply-To: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
Message-ID: <3e0b6c7ffd77407fae20597cc28865c8@sap.com>

Hi Volker,

looks good.

Best regards
Christoph

> -----Original Message-----
> From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of
> Volker Simonis
> Sent: Freitag, 13. April 2018 15:29
> To: awt-dev <awt-dev at openjdk.java.net>; build-dev <build-
> dev at openjdk.java.net>
> Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
> against libawt_headless
> 
> Hi,
> 
> can I please have a review for this tiny AIX cleanup:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
> https://bugs.openjdk.java.net/browse/JDK-8201524
> 
> This is a follow up change of JDK-8196516 which discovered that on AIX
> libfontmanager is always linked against libawt_headless at build time.
> If we are running in a headfull environment, libfontmanager will
> dynamically load libawt_xawt which is not good because libawt_headless
> and libawt_xawt define some common symbols. If we're running in a
> headless environment, libawt_headless may be loaded a second time (at
> least on Linux/Solaris) which isn't good either.
> 
> Both of these scenarios haven't caused any problems on AIX yet, but I
> think it's good to cleanup the AIX implementation as well and don't
> link libfontmanager against libawt_headless anymore. In order to
> achieve this, we have to allow unresolved symbols during the linking
> of libfontmanager. This can be easily achieved by adding the additions
> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
> for AIX because options which come later on the command line take
> precedence
> over earlier ones.
> 
> Thank you and best regards,
> Volker

From chris.w.dennis at gmail.com  Fri Apr 13 15:23:52 2018
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Fri, 13 Apr 2018 11:23:52 -0400
Subject: Fix for JDK-8201483 broken '-' containing features
Message-ID: <48287C18-5572-4F4E-87AD-8986066A3060@gmail.com>

Hi All,

It looks like the addition of support for disabling features has broken support for enabling features that contain a ?-? in their name (amusingly this includes the 'all-gcs? feature).

Pretty sure this is the offending code is the use of 'match($i, /-.*/)? to distinguish between disabled and enabled features. That regex needs to match a ?-' only at the beginning of the line otherwise configures thinks you are disabling the ?ll-gcs? feature.

Thanks,

Chris Dennis

From erik.joelsson at oracle.com  Fri Apr 13 15:50:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 08:50:11 -0700
Subject: [11] RFR: 8201507: Generate alias entries in j.t.f.ZoneName from
 tzdb at build time
In-Reply-To: <a0fc33b7-7adc-900c-32a8-fd87a32e2da1@oracle.com>
References: <a0fc33b7-7adc-900c-32a8-fd87a32e2da1@oracle.com>
Message-ID: <60d3bcd2-f9a2-64bb-4866-c6ee881d5ab4@oracle.com>

Build changes look good.

/Erik


On 2018-04-12 17:34, Naoto Sato wrote:
> Hi,
>
> Please review the fix to the subject issue. While fixing 8189784 [1], 
> I noticed that not only CLDR zones but also tzdb link entries are also 
> hard coded. So I further modified j.t.f.ZoneName to generate tzdb 
> entries at the build time.
>
> The issue: https://bugs.openjdk.java.net/browse/JDK-8201507
> Fix: http://cr.openjdk.java.net/~naoto/8201507/webrev.00/
>
> Like the last time, including build-dev for makefile modification review.
>
> Naoto
>
> [1] 
> http://mail.openjdk.java.net/pipermail/i18n-dev/2018-April/002492.html



From erik.joelsson at oracle.com  Fri Apr 13 16:00:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 09:00:39 -0700
Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against
 libawt_headless
In-Reply-To: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
Message-ID: <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>

Hello Volker,

The change looks good, but now that we no longer link against 
libawt_headless, we should also remove the make dependency a few lines 
down. (Should have been done already for Solaris.)

/Erik


On 2018-04-13 06:28, Volker Simonis wrote:
> Hi,
>
> can I please have a review for this tiny AIX cleanup:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
> https://bugs.openjdk.java.net/browse/JDK-8201524
>
> This is a follow up change of JDK-8196516 which discovered that on AIX
> libfontmanager is always linked against libawt_headless at build time.
> If we are running in a headfull environment, libfontmanager will
> dynamically load libawt_xawt which is not good because libawt_headless
> and libawt_xawt define some common symbols. If we're running in a
> headless environment, libawt_headless may be loaded a second time (at
> least on Linux/Solaris) which isn't good either.
>
> Both of these scenarios haven't caused any problems on AIX yet, but I
> think it's good to cleanup the AIX implementation as well and don't
> link libfontmanager against libawt_headless anymore. In order to
> achieve this, we have to allow unresolved symbols during the linking
> of libfontmanager. This can be easily achieved by adding the additions
> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
> for AIX because options which come later on the command line take
> precedence
> over earlier ones.
>
> Thank you and best regards,
> Volker



From volker.simonis at gmail.com  Fri Apr 13 16:22:18 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Apr 2018 18:22:18 +0200
Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against
 libawt_headless
In-Reply-To: <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
Message-ID: <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>

Hi Erik,

thanks for looking at the patch and good catch! You're right that the
dependency can now be removed. Here's the new webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1

Regards,
Volker

On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello Volker,
>
> The change looks good, but now that we no longer link against
> libawt_headless, we should also remove the make dependency a few lines down.
> (Should have been done already for Solaris.)
>
> /Erik
>
>
>
> On 2018-04-13 06:28, Volker Simonis wrote:
>>
>> Hi,
>>
>> can I please have a review for this tiny AIX cleanup:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>> https://bugs.openjdk.java.net/browse/JDK-8201524
>>
>> This is a follow up change of JDK-8196516 which discovered that on AIX
>> libfontmanager is always linked against libawt_headless at build time.
>> If we are running in a headfull environment, libfontmanager will
>> dynamically load libawt_xawt which is not good because libawt_headless
>> and libawt_xawt define some common symbols. If we're running in a
>> headless environment, libawt_headless may be loaded a second time (at
>> least on Linux/Solaris) which isn't good either.
>>
>> Both of these scenarios haven't caused any problems on AIX yet, but I
>> think it's good to cleanup the AIX implementation as well and don't
>> link libfontmanager against libawt_headless anymore. In order to
>> achieve this, we have to allow unresolved symbols during the linking
>> of libfontmanager. This can be easily achieved by adding the additions
>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
>> for AIX because options which come later on the command line take
>> precedence
>> over earlier ones.
>>
>> Thank you and best regards,
>> Volker
>
>


From kevin.walls at oracle.com  Fri Apr 13 16:22:22 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 13 Apr 2018 17:22:22 +0100
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling on
 Linux and Solaris
Message-ID: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>

Hi,

I'd like to request review of this backport from 9 to 8u:

8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris
JBS: https://bugs.openjdk.java.net/browse/JDK-8038340

9 changesets:
base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a 
(clean import to jdk8u-dev)

JDK repo change imports cleanly.? base repo changes require some manual 
fixups in:

common/autoconf/basics.m4 addition of 
AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
common/autoconf/toolchain.m4??? ??? ??? ??? ??? ??? ??? minor change 
didn't import
make/common/NativeCompilation.gmk??? ??? ??? ??? minor change didn't import

...plus run autogen to recreate generated files.


9 review thread: 
http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
(thread starts in March, not that it's long, but I don't see a link 
there to the previous emails in the thread: 
http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )

8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/

Many thanks!
Kevin



From philip.race at oracle.com  Fri Apr 13 17:20:59 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 13 Apr 2018 10:20:59 -0700
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against libawt_headless
In-Reply-To: <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
Message-ID: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>


I suppose this potentially helps the concurrency of the build ?
I can't think of why this would be a problem now there is no 
compile-time linking
involved and it seems Linux was already fine without this,
but a jdk-submit would be prudent ..

-phil.

On 04/13/2018 09:22 AM, Volker Simonis wrote:
> Hi Erik,
>
> thanks for looking at the patch and good catch! You're right that the
> dependency can now be removed. Here's the new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
>
> Regards,
> Volker
>
> On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Hello Volker,
>>
>> The change looks good, but now that we no longer link against
>> libawt_headless, we should also remove the make dependency a few lines down.
>> (Should have been done already for Solaris.)
>>
>> /Erik
>>
>>
>>
>> On 2018-04-13 06:28, Volker Simonis wrote:
>>> Hi,
>>>
>>> can I please have a review for this tiny AIX cleanup:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>>> https://bugs.openjdk.java.net/browse/JDK-8201524
>>>
>>> This is a follow up change of JDK-8196516 which discovered that on AIX
>>> libfontmanager is always linked against libawt_headless at build time.
>>> If we are running in a headfull environment, libfontmanager will
>>> dynamically load libawt_xawt which is not good because libawt_headless
>>> and libawt_xawt define some common symbols. If we're running in a
>>> headless environment, libawt_headless may be loaded a second time (at
>>> least on Linux/Solaris) which isn't good either.
>>>
>>> Both of these scenarios haven't caused any problems on AIX yet, but I
>>> think it's good to cleanup the AIX implementation as well and don't
>>> link libfontmanager against libawt_headless anymore. In order to
>>> achieve this, we have to allow unresolved symbols during the linking
>>> of libfontmanager. This can be easily achieved by adding the additions
>>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
>>> for AIX because options which come later on the command line take
>>> precedence
>>> over earlier ones.
>>>
>>> Thank you and best regards,
>>> Volker
>>



From erik.joelsson at oracle.com  Fri Apr 13 18:28:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 11:28:36 -0700
Subject: RFR(XS): 8201524: [AIX] Don't link libfontmanager against
 libawt_headless
In-Reply-To: <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
Message-ID: <19047fbc-0d30-cc3d-e289-6a42a419a49e@oracle.com>

Looks good, thanks!

/Erik


On 2018-04-13 09:22, Volker Simonis wrote:
> Hi Erik,
>
> thanks for looking at the patch and good catch! You're right that the
> dependency can now be removed. Here's the new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
>
> Regards,
> Volker
>
> On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Hello Volker,
>>
>> The change looks good, but now that we no longer link against
>> libawt_headless, we should also remove the make dependency a few lines down.
>> (Should have been done already for Solaris.)
>>
>> /Erik
>>
>>
>>
>> On 2018-04-13 06:28, Volker Simonis wrote:
>>> Hi,
>>>
>>> can I please have a review for this tiny AIX cleanup:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>>> https://bugs.openjdk.java.net/browse/JDK-8201524
>>>
>>> This is a follow up change of JDK-8196516 which discovered that on AIX
>>> libfontmanager is always linked against libawt_headless at build time.
>>> If we are running in a headfull environment, libfontmanager will
>>> dynamically load libawt_xawt which is not good because libawt_headless
>>> and libawt_xawt define some common symbols. If we're running in a
>>> headless environment, libawt_headless may be loaded a second time (at
>>> least on Linux/Solaris) which isn't good either.
>>>
>>> Both of these scenarios haven't caused any problems on AIX yet, but I
>>> think it's good to cleanup the AIX implementation as well and don't
>>> link libfontmanager against libawt_headless anymore. In order to
>>> achieve this, we have to allow unresolved symbols during the linking
>>> of libfontmanager. This can be easily achieved by adding the additions
>>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
>>> for AIX because options which come later on the command line take
>>> precedence
>>> over earlier ones.
>>>
>>> Thank you and best regards,
>>> Volker
>>



From erik.joelsson at oracle.com  Fri Apr 13 18:31:15 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 11:31:15 -0700
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against libawt_headless
In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
 <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
Message-ID: <77be34a6-352e-7ded-7be3-a6e0b02d9a74@oracle.com>

Yes, we don't want unneeded dependencies declared as it both potentially 
slows down the build (though this removal will not have any measurable 
impact) as well as confuses humans trying to make sense of the makefiles.

This removal should be fine as we don't link to libawt_xawt on any 
platform anymore. Linking is the only reason we have those dependencies.

/Erik


On 2018-04-13 10:20, Phil Race wrote:
>
> I suppose this potentially helps the concurrency of the build ?
> I can't think of why this would be a problem now there is no 
> compile-time linking
> involved and it seems Linux was already fine without this,
> but a jdk-submit would be prudent ..
>
> -phil.
>
> On 04/13/2018 09:22 AM, Volker Simonis wrote:
>> Hi Erik,
>>
>> thanks for looking at the patch and good catch! You're right that the
>> dependency can now be removed. Here's the new webrev:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
>>
>> Regards,
>> Volker
>>
>> On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson 
>> <erik.joelsson at oracle.com> wrote:
>>> Hello Volker,
>>>
>>> The change looks good, but now that we no longer link against
>>> libawt_headless, we should also remove the make dependency a few 
>>> lines down.
>>> (Should have been done already for Solaris.)
>>>
>>> /Erik
>>>
>>>
>>>
>>> On 2018-04-13 06:28, Volker Simonis wrote:
>>>> Hi,
>>>>
>>>> can I please have a review for this tiny AIX cleanup:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>>>> https://bugs.openjdk.java.net/browse/JDK-8201524
>>>>
>>>> This is a follow up change of JDK-8196516 which discovered that on AIX
>>>> libfontmanager is always linked against libawt_headless at build time.
>>>> If we are running in a headfull environment, libfontmanager will
>>>> dynamically load libawt_xawt which is not good because libawt_headless
>>>> and libawt_xawt define some common symbols. If we're running in a
>>>> headless environment, libawt_headless may be loaded a second time (at
>>>> least on Linux/Solaris) which isn't good either.
>>>>
>>>> Both of these scenarios haven't caused any problems on AIX yet, but I
>>>> think it's good to cleanup the AIX implementation as well and don't
>>>> link libfontmanager against libawt_headless anymore. In order to
>>>> achieve this, we have to allow unresolved symbols during the linking
>>>> of libfontmanager. This can be easily achieved by adding the additions
>>>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
>>>> for AIX because options which come later on the command line take
>>>> precedence
>>>> over earlier ones.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>
>



From erik.joelsson at oracle.com  Fri Apr 13 18:39:23 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 11:39:23 -0700
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling on
 Linux and Solaris
In-Reply-To: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
Message-ID: <53f5717e-089f-f830-9ae5-b222d30d232b@oracle.com>

Looks good.

/Erik


On 2018-04-13 09:22, Kevin Walls wrote:
> Hi,
>
> I'd like to request review of this backport from 9 to 8u:
>
> 8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>
> 9 changesets:
> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a 
> (clean import to jdk8u-dev)
>
> JDK repo change imports cleanly.? base repo changes require some 
> manual fixups in:
>
> common/autoconf/basics.m4 addition of 
> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
> common/autoconf/toolchain.m4??? ??? ??? ??? ??? ??? ??? minor change 
> didn't import
> make/common/NativeCompilation.gmk??? ??? ??? ??? minor change didn't 
> import
>
> ...plus run autogen to recreate generated files.
>
>
> 9 review thread: 
> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
> (thread starts in March, not that it's long, but I don't see a link 
> there to the previous emails in the thread: 
> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>
> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>
> Many thanks!
> Kevin
>



From tim.bell at oracle.com  Fri Apr 13 19:08:31 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 13 Apr 2018 12:08:31 -0700
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling
 on Linux and Solaris
In-Reply-To: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
Message-ID: <5AD1002F.2050207@oracle.com>

Kevin - looks good in general with a few remarks (see below):

> I'd like to request review of this backport from 9 to 8u:
>
> 8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>
> 9 changesets:
> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a
> (clean import to jdk8u-dev)
>
> JDK repo change imports cleanly.  base repo changes require some manual
> fixups in:
>
> common/autoconf/basics.m4 addition of
> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
> common/autoconf/toolchain.m4                            minor change
> didn't import
> make/common/NativeCompilation.gmk                minor change didn't import
>
> ...plus run autogen to recreate generated files.
>
>
> 9 review thread:
> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
> (thread starts in March, not that it's long, but I don't see a link
> there to the previous emails in the thread:
> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>
> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>
> Many thanks!
> Kevin

common/autoconf/configure.ac

This change looks straightforward, but I don't see the file at all in 
the JDK 9 webrev...


make/common/autoconf/configure.acdevkit/Makefile

lines 91,92 ... Do you want ccache?  It is commented out in the JDK 9 
changes 
(http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/make/devkit/Makefile.frames.html)



/Tim



From volker.simonis at gmail.com  Fri Apr 13 19:44:36 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Apr 2018 19:44:36 +0000
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against libawt_headless
In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
 <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
Message-ID: <CA+3eh12KW5Mt53eTWCMwB6eZYcx7Nd2Qx1EwxDQ5Tcfoq7tU2w@mail.gmail.com>

Phil Race <philip.race at oracle.com> schrieb am Fr. 13. Apr. 2018 um 19:21:

>
> I suppose this potentially helps the concurrency of the build ?
> I can't think of why this would be a problem now there is no
> compile-time linking
> involved and it seems Linux was already fine without this,
> but a jdk-submit would be prudent ..
>

I did start Solaris and AIX builds before I left the office. I can
certainly also submit a job to JDK-submit, but at least hs-submit wasn?t
working at all (i.e. didn?t return any results).


> -phil.
>
> On 04/13/2018 09:22 AM, Volker Simonis wrote:
> > Hi Erik,
> >
> > thanks for looking at the patch and good catch! You're right that the
> > dependency can now be removed. Here's the new webrev:
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
> >
> > Regards,
> > Volker
> >
> > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson <erik.joelsson at oracle.com>
> wrote:
> >> Hello Volker,
> >>
> >> The change looks good, but now that we no longer link against
> >> libawt_headless, we should also remove the make dependency a few lines
> down.
> >> (Should have been done already for Solaris.)
> >>
> >> /Erik
> >>
> >>
> >>
> >> On 2018-04-13 06:28, Volker Simonis wrote:
> >>> Hi,
> >>>
> >>> can I please have a review for this tiny AIX cleanup:
> >>>
> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
> >>> https://bugs.openjdk.java.net/browse/JDK-8201524
> >>>
> >>> This is a follow up change of JDK-8196516 which discovered that on AIX
> >>> libfontmanager is always linked against libawt_headless at build time.
> >>> If we are running in a headfull environment, libfontmanager will
> >>> dynamically load libawt_xawt which is not good because libawt_headless
> >>> and libawt_xawt define some common symbols. If we're running in a
> >>> headless environment, libawt_headless may be loaded a second time (at
> >>> least on Linux/Solaris) which isn't good either.
> >>>
> >>> Both of these scenarios haven't caused any problems on AIX yet, but I
> >>> think it's good to cleanup the AIX implementation as well and don't
> >>> link libfontmanager against libawt_headless anymore. In order to
> >>> achieve this, we have to allow unresolved symbols during the linking
> >>> of libfontmanager. This can be easily achieved by adding the additions
> >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine
> >>> for AIX because options which come later on the command line take
> >>> precedence
> >>> over earlier ones.
> >>>
> >>> Thank you and best regards,
> >>> Volker
> >>
>
>


From kevin.walls at oracle.com  Fri Apr 13 19:51:00 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 13 Apr 2018 20:51:00 +0100
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling on
 Linux and Solaris
In-Reply-To: <5AD1002F.2050207@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
 <5AD1002F.2050207@oracle.com>
Message-ID: <aef4b10e-e2c6-6c7c-1e96-fae905ca0b8f@oracle.com>

Thanks Tim -

There's a later webrev in the review thread: 
http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ in which I see 
the common/autoconf/configure.ac change... It's in the commit in 9 
also.? I think we need it. 8-)

But that webrev.03 also has the commenting out of "Building ccache..." 
in make/devkit/Makefile , though I don't see it happening in 8038340 in 
the 9 change, or in latest jdk either. I'm thinking that ccache was 
disabled for local testing and wasn't intended as part of 8038340 - do 
let me know if you think otherwise!

Thanks
Kevin


On 13/04/2018 20:08, Tim Bell wrote:
> Kevin - looks good in general with a few remarks (see below):
>
>> I'd like to request review of this backport from 9 to 8u:
>>
>> 8038340: Cleanup and fix sysroot and devkit handling on Linux and 
>> Solaris
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>>
>> 9 changesets:
>> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
>> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a
>> (clean import to jdk8u-dev)
>>
>> JDK repo change imports cleanly.? base repo changes require some manual
>> fixups in:
>>
>> common/autoconf/basics.m4 addition of
>> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
>> common/autoconf/toolchain.m4??????????????????????????? minor change
>> didn't import
>> make/common/NativeCompilation.gmk??????????????? minor change didn't 
>> import
>>
>> ...plus run autogen to recreate generated files.
>>
>>
>> 9 review thread:
>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
>> (thread starts in March, not that it's long, but I don't see a link
>> there to the previous emails in the thread:
>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>>
>> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>>
>> Many thanks!
>> Kevin
>
> common/autoconf/configure.ac
>
> This change looks straightforward, but I don't see the file at all in 
> the JDK 9 webrev...
>
>
> make/common/autoconf/configure.acdevkit/Makefile
>
> lines 91,92 ... Do you want ccache?? It is commented out in the JDK 9 
> changes 
> (http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/make/devkit/Makefile.frames.html)
>
>
>
> /Tim
>



From erik.joelsson at oracle.com  Fri Apr 13 19:53:59 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 12:53:59 -0700
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against libawt_headless
In-Reply-To: <CA+3eh12KW5Mt53eTWCMwB6eZYcx7Nd2Qx1EwxDQ5Tcfoq7tU2w@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
 <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
 <CA+3eh12KW5Mt53eTWCMwB6eZYcx7Nd2Qx1EwxDQ5Tcfoq7tU2w@mail.gmail.com>
Message-ID: <bf2fbc26-2304-8846-b5e5-f1a547fdbf5d@oracle.com>


On 2018-04-13 12:44, Volker Simonis wrote:
>
> Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> 
> schrieb am Fr. 13. Apr. 2018 um 19:21:
>
>
>     I suppose this potentially helps the concurrency of the build ?
>     I can't think of why this would be a problem now there is no
>     compile-time linking
>     involved and it seems Linux was already fine without this,
>     but a jdk-submit would be prudent ..
>
>
> I did start Solaris and AIX builds before I left the office. I can 
> certainly also submit a job to JDK-submit, but at least hs-submit 
> wasn?t working at all (i.e. didn?t return any results).
>
hs-submit is disabled since the merge of jdk/hs to jdk/jdk.

/Erik
>
>
>     -phil.
>
>     On 04/13/2018 09:22 AM, Volker Simonis wrote:
>     > Hi Erik,
>     >
>     > thanks for looking at the patch and good catch! You're right
>     that the
>     > dependency can now be removed. Here's the new webrev:
>     >
>     > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/2018/8201524.v1>
>     >
>     > Regards,
>     > Volker
>     >
>     > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson
>     <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>     >> Hello Volker,
>     >>
>     >> The change looks good, but now that we no longer link against
>     >> libawt_headless, we should also remove the make dependency a
>     few lines down.
>     >> (Should have been done already for Solaris.)
>     >>
>     >> /Erik
>     >>
>     >>
>     >>
>     >> On 2018-04-13 06:28, Volker Simonis wrote:
>     >>> Hi,
>     >>>
>     >>> can I please have a review for this tiny AIX cleanup:
>     >>>
>     >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/2018/8201524/>
>     >>> https://bugs.openjdk.java.net/browse/JDK-8201524
>     >>>
>     >>> This is a follow up change of JDK-8196516 which discovered
>     that on AIX
>     >>> libfontmanager is always linked against libawt_headless at
>     build time.
>     >>> If we are running in a headfull environment, libfontmanager will
>     >>> dynamically load libawt_xawt which is not good because
>     libawt_headless
>     >>> and libawt_xawt define some common symbols. If we're running in a
>     >>> headless environment, libawt_headless may be loaded a second
>     time (at
>     >>> least on Linux/Solaris) which isn't good either.
>     >>>
>     >>> Both of these scenarios haven't caused any problems on AIX
>     yet, but I
>     >>> think it's good to cleanup the AIX implementation as well and
>     don't
>     >>> link libfontmanager against libawt_headless anymore. In order to
>     >>> achieve this, we have to allow unresolved symbols during the
>     linking
>     >>> of libfontmanager. This can be easily achieved by adding the
>     additions
>     >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This
>     works fine
>     >>> for AIX because options which come later on the command line take
>     >>> precedence
>     >>> over earlier ones.
>     >>>
>     >>> Thank you and best regards,
>     >>> Volker
>     >>
>



From erik.joelsson at oracle.com  Fri Apr 13 19:58:12 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Apr 2018 12:58:12 -0700
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling on
 Linux and Solaris
In-Reply-To: <aef4b10e-e2c6-6c7c-1e96-fae905ca0b8f@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
 <5AD1002F.2050207@oracle.com>
 <aef4b10e-e2c6-6c7c-1e96-fae905ca0b8f@oracle.com>
Message-ID: <5c586398-4cf4-9fc8-5de7-be39e2232b9d@oracle.com>

ccache shouldn't be commented out. That must have been a local edit 
mistake in the original webrev.

/Erik


On 2018-04-13 12:51, Kevin Walls wrote:
> Thanks Tim -
>
> There's a later webrev in the review thread: 
> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ in which I 
> see the common/autoconf/configure.ac change... It's in the commit in 9 
> also.? I think we need it. 8-)
>
> But that webrev.03 also has the commenting out of "Building ccache..." 
> in make/devkit/Makefile , though I don't see it happening in 8038340 
> in the 9 change, or in latest jdk either. I'm thinking that ccache was 
> disabled for local testing and wasn't intended as part of 8038340 - do 
> let me know if you think otherwise!
>
> Thanks
> Kevin
>
>
> On 13/04/2018 20:08, Tim Bell wrote:
>> Kevin - looks good in general with a few remarks (see below):
>>
>>> I'd like to request review of this backport from 9 to 8u:
>>>
>>> 8038340: Cleanup and fix sysroot and devkit handling on Linux and 
>>> Solaris
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>>>
>>> 9 changesets:
>>> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
>>> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a
>>> (clean import to jdk8u-dev)
>>>
>>> JDK repo change imports cleanly.? base repo changes require some manual
>>> fixups in:
>>>
>>> common/autoconf/basics.m4 addition of
>>> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
>>> common/autoconf/toolchain.m4??????????????????????????? minor change
>>> didn't import
>>> make/common/NativeCompilation.gmk??????????????? minor change didn't 
>>> import
>>>
>>> ...plus run autogen to recreate generated files.
>>>
>>>
>>> 9 review thread:
>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
>>> (thread starts in March, not that it's long, but I don't see a link
>>> there to the previous emails in the thread:
>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>>>
>>> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>>>
>>> Many thanks!
>>> Kevin
>>
>> common/autoconf/configure.ac
>>
>> This change looks straightforward, but I don't see the file at all in 
>> the JDK 9 webrev...
>>
>>
>> make/common/autoconf/configure.acdevkit/Makefile
>>
>> lines 91,92 ... Do you want ccache?? It is commented out in the JDK 9 
>> changes 
>> (http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/make/devkit/Makefile.frames.html)
>>
>>
>>
>> /Tim
>>
>



From philip.race at oracle.com  Fri Apr 13 19:59:49 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 13 Apr 2018 12:59:49 -0700
Subject: <AWT Dev> RFR(XS): 8201524: [AIX] Don't link libfontmanager
 against libawt_headless
In-Reply-To: <CA+3eh12KW5Mt53eTWCMwB6eZYcx7Nd2Qx1EwxDQ5Tcfoq7tU2w@mail.gmail.com>
References: <CA+3eh11zJ7q=3TM24tUTqd68u8HrOF=P_9839Bk0oTeEa3pMjA@mail.gmail.com>
 <cde1cb06-b21b-8101-b010-98f6b56bb922@oracle.com>
 <CA+3eh137HfgJheO0ocGjqtSHBGhJZbdU2qmGcyC+G-g2h-Fi-g@mail.gmail.com>
 <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com>
 <CA+3eh12KW5Mt53eTWCMwB6eZYcx7Nd2Qx1EwxDQ5Tcfoq7tU2w@mail.gmail.com>
Message-ID: <2e82d272-3cda-9786-f5bf-14dd188fc2ec@oracle.com>



On 04/13/2018 12:44 PM, Volker Simonis wrote:
>
> Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> 
> schrieb am Fr. 13. Apr. 2018 um 19:21:
>
>
>     I suppose this potentially helps the concurrency of the build ?
>     I can't think of why this would be a problem now there is no
>     compile-time linking
>     involved and it seems Linux was already fine without this,
>     but a jdk-submit would be prudent ..
>
>
> I did start Solaris and AIX builds before I left the office.

That should be sufficient ...

-phil.

> I can certainly also submit a job to JDK-submit, but at least 
> hs-submit wasn?t working at all (i.e. didn?t return any results).
>
>
>     -phil.
>
>     On 04/13/2018 09:22 AM, Volker Simonis wrote:
>     > Hi Erik,
>     >
>     > thanks for looking at the patch and good catch! You're right
>     that the
>     > dependency can now be removed. Here's the new webrev:
>     >
>     > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/2018/8201524.v1>
>     >
>     > Regards,
>     > Volker
>     >
>     > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson
>     <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>     >> Hello Volker,
>     >>
>     >> The change looks good, but now that we no longer link against
>     >> libawt_headless, we should also remove the make dependency a
>     few lines down.
>     >> (Should have been done already for Solaris.)
>     >>
>     >> /Erik
>     >>
>     >>
>     >>
>     >> On 2018-04-13 06:28, Volker Simonis wrote:
>     >>> Hi,
>     >>>
>     >>> can I please have a review for this tiny AIX cleanup:
>     >>>
>     >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/
>     <http://cr.openjdk.java.net/%7Esimonis/webrevs/2018/8201524/>
>     >>> https://bugs.openjdk.java.net/browse/JDK-8201524
>     >>>
>     >>> This is a follow up change of JDK-8196516 which discovered
>     that on AIX
>     >>> libfontmanager is always linked against libawt_headless at
>     build time.
>     >>> If we are running in a headfull environment, libfontmanager will
>     >>> dynamically load libawt_xawt which is not good because
>     libawt_headless
>     >>> and libawt_xawt define some common symbols. If we're running in a
>     >>> headless environment, libawt_headless may be loaded a second
>     time (at
>     >>> least on Linux/Solaris) which isn't good either.
>     >>>
>     >>> Both of these scenarios haven't caused any problems on AIX
>     yet, but I
>     >>> think it's good to cleanup the AIX implementation as well and
>     don't
>     >>> link libfontmanager against libawt_headless anymore. In order to
>     >>> achieve this, we have to allow unresolved symbols during the
>     linking
>     >>> of libfontmanager. This can be easily achieved by adding the
>     additions
>     >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This
>     works fine
>     >>> for AIX because options which come later on the command line take
>     >>> precedence
>     >>> over earlier ones.
>     >>>
>     >>> Thank you and best regards,
>     >>> Volker
>     >>
>



From kevin.walls at oracle.com  Fri Apr 13 20:15:46 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 13 Apr 2018 21:15:46 +0100
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling on
 Linux and Solaris
In-Reply-To: <5c586398-4cf4-9fc8-5de7-be39e2232b9d@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
 <5AD1002F.2050207@oracle.com>
 <aef4b10e-e2c6-6c7c-1e96-fae905ca0b8f@oracle.com>
 <5c586398-4cf4-9fc8-5de7-be39e2232b9d@oracle.com>
Message-ID: <ae69b77b-fbbc-7886-cac9-a48faf37c11c@oracle.com>

Hi Erik - thanks for clarifying.


On 13/04/2018 20:58, Erik Joelsson wrote:
> ccache shouldn't be commented out. That must have been a local edit 
> mistake in the original webrev.
>
> /Erik
>
>
> On 2018-04-13 12:51, Kevin Walls wrote:
>> Thanks Tim -
>>
>> There's a later webrev in the review thread: 
>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ in which I 
>> see the common/autoconf/configure.ac change... It's in the commit in 
>> 9 also.? I think we need it. 8-)
>>
>> But that webrev.03 also has the commenting out of "Building 
>> ccache..." in make/devkit/Makefile , though I don't see it happening 
>> in 8038340 in the 9 change, or in latest jdk either. I'm thinking 
>> that ccache was disabled for local testing and wasn't intended as 
>> part of 8038340 - do let me know if you think otherwise!
>>
>> Thanks
>> Kevin
>>
>>
>> On 13/04/2018 20:08, Tim Bell wrote:
>>> Kevin - looks good in general with a few remarks (see below):
>>>
>>>> I'd like to request review of this backport from 9 to 8u:
>>>>
>>>> 8038340: Cleanup and fix sysroot and devkit handling on Linux and 
>>>> Solaris
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>>>>
>>>> 9 changesets:
>>>> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
>>>> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a
>>>> (clean import to jdk8u-dev)
>>>>
>>>> JDK repo change imports cleanly.? base repo changes require some 
>>>> manual
>>>> fixups in:
>>>>
>>>> common/autoconf/basics.m4 addition of
>>>> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
>>>> common/autoconf/toolchain.m4 minor change
>>>> didn't import
>>>> make/common/NativeCompilation.gmk??????????????? minor change 
>>>> didn't import
>>>>
>>>> ...plus run autogen to recreate generated files.
>>>>
>>>>
>>>> 9 review thread:
>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
>>>> (thread starts in March, not that it's long, but I don't see a link
>>>> there to the previous emails in the thread:
>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>>>>
>>>> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>>>>
>>>> Many thanks!
>>>> Kevin
>>>
>>> common/autoconf/configure.ac
>>>
>>> This change looks straightforward, but I don't see the file at all 
>>> in the JDK 9 webrev...
>>>
>>>
>>> make/common/autoconf/configure.acdevkit/Makefile
>>>
>>> lines 91,92 ... Do you want ccache?? It is commented out in the JDK 
>>> 9 changes 
>>> (http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/make/devkit/Makefile.frames.html)
>>>
>>>
>>>
>>> /Tim
>>>
>>
>



From tim.bell at oracle.com  Fri Apr 13 20:41:15 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 13 Apr 2018 13:41:15 -0700
Subject: [8u] RFR: 8038340: Cleanup and fix sysroot and devkit handling
 on Linux and Solaris
In-Reply-To: <ae69b77b-fbbc-7886-cac9-a48faf37c11c@oracle.com>
References: <d7eb71e3-571f-fcb6-25ef-42712f207852@oracle.com>
 <5AD1002F.2050207@oracle.com>
 <aef4b10e-e2c6-6c7c-1e96-fae905ca0b8f@oracle.com>
 <5c586398-4cf4-9fc8-5de7-be39e2232b9d@oracle.com>
 <ae69b77b-fbbc-7886-cac9-a48faf37c11c@oracle.com>
Message-ID: <5AD115EB.5030200@oracle.com>

In that case, the review looks good.

Thanks-

Tim

On 04/13/18 13:15, Kevin Walls wrote:
> Hi Erik - thanks for clarifying.
>
>
> On 13/04/2018 20:58, Erik Joelsson wrote:
>> ccache shouldn't be commented out. That must have been a local edit
>> mistake in the original webrev.
>>
>> /Erik
>>
>>
>> On 2018-04-13 12:51, Kevin Walls wrote:
>>> Thanks Tim -
>>>
>>> There's a later webrev in the review thread:
>>> http://cr.openjdk.java.net/~erikj/8038340/webrev.root.03/ in which I
>>> see the common/autoconf/configure.ac change... It's in the commit in
>>> 9 also.  I think we need it. 8-)
>>>
>>> But that webrev.03 also has the commenting out of "Building
>>> ccache..." in make/devkit/Makefile , though I don't see it happening
>>> in 8038340 in the 9 change, or in latest jdk either. I'm thinking
>>> that ccache was disabled for local testing and wasn't intended as
>>> part of 8038340 - do let me know if you think otherwise!
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>> On 13/04/2018 20:08, Tim Bell wrote:
>>>> Kevin - looks good in general with a few remarks (see below):
>>>>
>>>>> I'd like to request review of this backport from 9 to 8u:
>>>>>
>>>>> 8038340: Cleanup and fix sysroot and devkit handling on Linux and
>>>>> Solaris
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038340
>>>>>
>>>>> 9 changesets:
>>>>> base repo: http://hg.openjdk.java.net/jdk9/dev/rev/9786ef8ca58c
>>>>> JDK: repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fdeb6a8b0f3a
>>>>> (clean import to jdk8u-dev)
>>>>>
>>>>> JDK repo change imports cleanly.  base repo changes require some
>>>>> manual
>>>>> fixups in:
>>>>>
>>>>> common/autoconf/basics.m4 addition of
>>>>> AC_DEFUN_ONCE([BASIC_SETUP_DEVKIT], fails, done manually
>>>>> common/autoconf/toolchain.m4 minor change
>>>>> didn't import
>>>>> make/common/NativeCompilation.gmk                minor change
>>>>> didn't import
>>>>>
>>>>> ...plus run autogen to recreate generated files.
>>>>>
>>>>>
>>>>> 9 review thread:
>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-April/004361.html
>>>>> (thread starts in March, not that it's long, but I don't see a link
>>>>> there to the previous emails in the thread:
>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2014-March/004333.html )
>>>>>
>>>>> 8u webrev:http://cr.openjdk.java.net/~kevinw/8038340/webrev.00/
>>>>>
>>>>> Many thanks!
>>>>> Kevin
>>>>
>>>> common/autoconf/configure.ac
>>>>
>>>> This change looks straightforward, but I don't see the file at all
>>>> in the JDK 9 webrev...
>>>>
>>>>
>>>> make/common/autoconf/configure.acdevkit/Makefile
>>>>
>>>> lines 91,92 ... Do you want ccache?  It is commented out in the JDK
>>>> 9 changes
>>>> (http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/make/devkit/Makefile.frames.html)




From aph at redhat.com  Mon Apr 16 08:47:54 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2018 09:47:54 +0100
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <1523626847.4177.22.camel@redhat.com>
References: <1523626847.4177.22.camel@redhat.com>
Message-ID: <55f8697f-c53f-5ff7-9d4e-531216e296cb@redhat.com>

On 04/13/2018 02:40 PM, Severin Gehwolf wrote:
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> Error occurred during initialization of VM
> Could not reserve enough space for 1048576KB object heap

What is the root cause of this?  Is it that the system on which the build runs
cannot allocate all that memory?  Does not have that much memory?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From magnus.ihse.bursie at oracle.com  Mon Apr 16 08:58:03 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 10:58:03 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <1523626847.4177.22.camel@redhat.com>
References: <1523626847.4177.22.camel@redhat.com>
Message-ID: <9c5b34f5-682f-1e89-1527-c4673052298d@oracle.com>

On 2018-04-13 15:40, Severin Gehwolf wrote:
> Hi,
>
> We (Red Hat) have been building Zero on s390 for a while now. In order
> to do so we needed to have this patch to reduce the maximum heap size
> setting for big workloads. Otherwise we see this during (JDK 9) builds:
>
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> Error occurred during initialization of VM
> Could not reserve enough space for 1048576KB object heap
>
> NOTE: JDK 9 has the same build logic than JDK 11 in terms of big
> workloads' JVM switches.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201495
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.01/

Hi Severin,

As I said in the bug report (didn't notice that you've already sent out 
a webrev here), I'm not really fond of adding platforms guard if they 
can be avoided. Normally, Java programs use more or less the same amount 
of heap regardless of platforms they run on, differing only by platform 
word size. So if a lower mx is enough on s390 builds, it's mostly likely 
to be enough on all platforms, and thus the guard is unnecessary, and 
will only make it harder to update the code in the future.

Also, the value of ms is typically of less concern. While mx is setting 
an upper bound on resource allocation, ms is more of a "performance 
hint" to the gc. Unless this is needed for your fix to work, I recommend 
you leave it at it's current value.

/Magnus

>
> Testing: Run configure on s390 and inspected the big workloads settings:
>
> Before:
> checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768
>
> After:
> checking flags for bootcycle boot jdk java command for big workloads... -Xms256M -Xmx768M -XX:ThreadStackSize=768
>
> This should be fairly low risk, since the check is guarded by s390
> archicture checks. Other architectures should be unaffected.
>
> Thanks,
> Severin



From goetz.lindenmaier at sap.com  Mon Apr 16 09:16:31 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 16 Apr 2018 09:16:31 +0000
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
Message-ID: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>

Hi, 

could I please get reviewes for this tiny fix? 
Grep does not grok the syntax of the replacement of space to newline.
It causes configure failures on SLES 11.

http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/

Best regards,
  Goetz.


From sgehwolf at redhat.com  Mon Apr 16 09:30:11 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 16 Apr 2018 11:30:11 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <55f8697f-c53f-5ff7-9d4e-531216e296cb@redhat.com>
References: <1523626847.4177.22.camel@redhat.com>
 <55f8697f-c53f-5ff7-9d4e-531216e296cb@redhat.com>
Message-ID: <1523871011.4046.16.camel@redhat.com>

Hi Andrew,

On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote:
> On 04/13/2018 02:40 PM, Severin Gehwolf wrote:
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > Error occurred during initialization of VM
> > Could not reserve enough space for 1048576KB object heap
> 
> What is the root cause of this?  Is it that the system on which the build runs
> cannot allocate all that memory?  Does not have that much memory?

The configure code in JDK 9+ has this:

  JVM_HEAP_LIMIT_32="1024"
  # Running a 64 bit JVM allows for and requires a bigger heap
  JVM_HEAP_LIMIT_64="1600"
  STACK_SIZE_32=768
  STACK_SIZE_64=1536
  JVM_HEAP_LIMIT_GLOBAL=`expr $MEMORY_SIZE / 2`
  if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_32"; then
    JVM_HEAP_LIMIT_32=$JVM_HEAP_LIMIT_GLOBAL
  fi
  if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_64"; then
    JVM_HEAP_LIMIT_64=$JVM_HEAP_LIMIT_GLOBAL
  fi
  if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "512"; then
    JVM_HEAP_LIMIT_32=512
    JVM_HEAP_LIMIT_64=512
  fi

  if test "x$BOOT_JDK_BITS" = "x32"; then
    STACK_SIZE=$STACK_SIZE_32
    JVM_MAX_HEAP=$JVM_HEAP_LIMIT_32
  else
    STACK_SIZE=$STACK_SIZE_64
    JVM_MAX_HEAP=$JVM_HEAP_LIMIT_64
  fi


Here's my reasoning:

If I read this right then -Xmx will be bound above by 1/2 the hardware
memory size. The set heap limit for that build was 1024M. It then
follows that 1024M was less than 1/2 the hardware memory. Yet, it still
failed to allocate required memory. So to answer your question: It
looks like it was that the system wasn't able to allocate that much
memory at the time.

Those builds run on systems I don't have access to, though. What's
more, I don't have access to the build logs of that failed build any
longer. From a successful s390 build with that patch I see:

$ grep 'Memory limit' build.log 
* Memory limit:   5906 MB

This seems suspiciously high for 32 bit (or 31 bit in this case). Maybe
it gets the hardware memory size of the 64bit host system? We know this
runs in mock chroots on s390x boxes.

Thanks,
Severin


From sgehwolf at redhat.com  Mon Apr 16 09:34:19 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 16 Apr 2018 11:34:19 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <9c5b34f5-682f-1e89-1527-c4673052298d@oracle.com>
References: <1523626847.4177.22.camel@redhat.com>
 <9c5b34f5-682f-1e89-1527-c4673052298d@oracle.com>
Message-ID: <1523871259.4046.18.camel@redhat.com>

Hi Magnus,

On Mon, 2018-04-16 at 10:58 +0200, Magnus Ihse Bursie wrote:
> On 2018-04-13 15:40, Severin Gehwolf wrote:
> > Hi,
> > 
> > We (Red Hat) have been building Zero on s390 for a while now. In order
> > to do so we needed to have this patch to reduce the maximum heap size
> > setting for big workloads. Otherwise we see this during (JDK 9) builds:
> > 
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > Error occurred during initialization of VM
> > Could not reserve enough space for 1048576KB object heap
> > 
> > NOTE: JDK 9 has the same build logic than JDK 11 in terms of big
> > workloads' JVM switches.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8201495
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.01/
> 
> Hi Severin,
> 
> As I said in the bug report (didn't notice that you've already sent out 
> a webrev here), I'm not really fond of adding platforms guard if they 
> can be avoided. Normally, Java programs use more or less the same amount 
> of heap regardless of platforms they run on, differing only by platform 
> word size. So if a lower mx is enough on s390 builds, it's mostly likely 
> to be enough on all platforms, and thus the guard is unnecessary, and 
> will only make it harder to update the code in the future.
> 
> Also, the value of ms is typically of less concern. While mx is setting 
> an upper bound on resource allocation, ms is more of a "performance 
> hint" to the gc. Unless this is needed for your fix to work, I recommend 
> you leave it at it's current value.

Thanks for the review! I'll test builds with your proposed changes and
see how it goes.

Cheers,
Severin


From volker.simonis at gmail.com  Mon Apr 16 10:01:07 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Apr 2018 12:01:07 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <1523871011.4046.16.camel@redhat.com>
References: <1523626847.4177.22.camel@redhat.com>
 <55f8697f-c53f-5ff7-9d4e-531216e296cb@redhat.com>
 <1523871011.4046.16.camel@redhat.com>
Message-ID: <CA+3eh10ka4PofRPBQFOobW-FVSkX1aJW-nNsxjMe6dm-Cj3kRg@mail.gmail.com>

On Mon, Apr 16, 2018 at 11:30 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Andrew,
>
> On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote:
>> On 04/13/2018 02:40 PM, Severin Gehwolf wrote:
>> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
>> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
>> > Error occurred during initialization of VM
>> > Could not reserve enough space for 1048576KB object heap
>>
>> What is the root cause of this?  Is it that the system on which the build runs
>> cannot allocate all that memory?  Does not have that much memory?
>
> The configure code in JDK 9+ has this:
>
>   JVM_HEAP_LIMIT_32="1024"
>   # Running a 64 bit JVM allows for and requires a bigger heap
>   JVM_HEAP_LIMIT_64="1600"
>   STACK_SIZE_32=768
>   STACK_SIZE_64=1536
>   JVM_HEAP_LIMIT_GLOBAL=`expr $MEMORY_SIZE / 2`
>   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_32"; then
>     JVM_HEAP_LIMIT_32=$JVM_HEAP_LIMIT_GLOBAL
>   fi
>   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_64"; then
>     JVM_HEAP_LIMIT_64=$JVM_HEAP_LIMIT_GLOBAL
>   fi
>   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "512"; then
>     JVM_HEAP_LIMIT_32=512
>     JVM_HEAP_LIMIT_64=512
>   fi
>
>   if test "x$BOOT_JDK_BITS" = "x32"; then
>     STACK_SIZE=$STACK_SIZE_32
>     JVM_MAX_HEAP=$JVM_HEAP_LIMIT_32
>   else
>     STACK_SIZE=$STACK_SIZE_64
>     JVM_MAX_HEAP=$JVM_HEAP_LIMIT_64
>   fi
>
>
> Here's my reasoning:
>
> If I read this right then -Xmx will be bound above by 1/2 the hardware
> memory size. The set heap limit for that build was 1024M. It then
> follows that 1024M was less than 1/2 the hardware memory. Yet, it still
> failed to allocate required memory. So to answer your question: It
> looks like it was that the system wasn't able to allocate that much
> memory at the time.
>

Where do you get the "Before:" output from your initial mail:

Before:
checking flags for bootcycle boot jdk java command for big
workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768

with '-Xmx998M' if JVM_HEAP_LIMIT_32 was "1024" before your change ?

> Those builds run on systems I don't have access to, though. What's
> more, I don't have access to the build logs of that failed build any
> longer. From a successful s390 build with that patch I see:
>
> $ grep 'Memory limit' build.log
> * Memory limit:   5906 MB
>
> This seems suspiciously high for 32 bit (or 31 bit in this case). Maybe
> it gets the hardware memory size of the 64bit host system? We know this
> runs in mock chroots on s390x boxes.
>
> Thanks,
> Severin


From sgehwolf at redhat.com  Mon Apr 16 10:13:00 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 16 Apr 2018 12:13:00 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <CA+3eh10ka4PofRPBQFOobW-FVSkX1aJW-nNsxjMe6dm-Cj3kRg@mail.gmail.com>
References: <1523626847.4177.22.camel@redhat.com>
 <55f8697f-c53f-5ff7-9d4e-531216e296cb@redhat.com>
 <1523871011.4046.16.camel@redhat.com>
 <CA+3eh10ka4PofRPBQFOobW-FVSkX1aJW-nNsxjMe6dm-Cj3kRg@mail.gmail.com>
Message-ID: <1523873580.4046.24.camel@redhat.com>

On Mon, 2018-04-16 at 12:01 +0200, Volker Simonis wrote:
> On Mon, Apr 16, 2018 at 11:30 AM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi Andrew,
> > 
> > On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote:
> > > On 04/13/2018 02:40 PM, Severin Gehwolf wrote:
> > > > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > > > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > > > Error occurred during initialization of VM
> > > > Could not reserve enough space for 1048576KB object heap
> > > 
> > > What is the root cause of this?  Is it that the system on which the build runs
> > > cannot allocate all that memory?  Does not have that much memory?
> > 
> > The configure code in JDK 9+ has this:
> > 
> >   JVM_HEAP_LIMIT_32="1024"
> >   # Running a 64 bit JVM allows for and requires a bigger heap
> >   JVM_HEAP_LIMIT_64="1600"
> >   STACK_SIZE_32=768
> >   STACK_SIZE_64=1536
> >   JVM_HEAP_LIMIT_GLOBAL=`expr $MEMORY_SIZE / 2`
> >   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_32"; then
> >     JVM_HEAP_LIMIT_32=$JVM_HEAP_LIMIT_GLOBAL
> >   fi
> >   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "$JVM_HEAP_LIMIT_64"; then
> >     JVM_HEAP_LIMIT_64=$JVM_HEAP_LIMIT_GLOBAL
> >   fi
> >   if test "$JVM_HEAP_LIMIT_GLOBAL" -lt "512"; then
> >     JVM_HEAP_LIMIT_32=512
> >     JVM_HEAP_LIMIT_64=512
> >   fi
> > 
> >   if test "x$BOOT_JDK_BITS" = "x32"; then
> >     STACK_SIZE=$STACK_SIZE_32
> >     JVM_MAX_HEAP=$JVM_HEAP_LIMIT_32
> >   else
> >     STACK_SIZE=$STACK_SIZE_64
> >     JVM_MAX_HEAP=$JVM_HEAP_LIMIT_64
> >   fi
> > 
> > 
> > Here's my reasoning:
> > 
> > If I read this right then -Xmx will be bound above by 1/2 the hardware
> > memory size. The set heap limit for that build was 1024M. It then
> > follows that 1024M was less than 1/2 the hardware memory. Yet, it still
> > failed to allocate required memory. So to answer your question: It
> > looks like it was that the system wasn't able to allocate that much
> > memory at the time.
> > 
> 
> Where do you get the "Before:" output from your initial mail:

>From a time-shared s390x box where I've created a s390 chroot manually.
 
It's not the same system as where the builds run. I don't have access
to systems running builds unfortunately.

> Before:
> checking flags for bootcycle boot jdk java command for big
> workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768
> 
> with '-Xmx998M' if JVM_HEAP_LIMIT_32 was "1024" before your change ?

Right. This particular system where I ran this on has 1997MB memory
(according to free -m). Since 1997/2 ~= 998 and 998 < 1024 that's
what's getting used.

Does that make sense?

Thanks,
Severin


From adam.farley at uk.ibm.com  Mon Apr 16 10:58:40 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Mon, 16 Apr 2018 11:58:40 +0100
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
Message-ID: <OF4FD84867.2F3F50A9-ON00258271.003C2E7F-80258271.003C4D7F@notes.na.collabserv.com>

I also advocate the source code fix, as Make isn't meant to use the sort 
of logic required 
to properly analyse the toolchain version string. 

e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, 
and Make doesn't
seem to do substring stuff unless you mess around with shells.

Plus, as people have said, it's better to solve problem x (or work around 
a specific 
instance of x) than to ignore the exception, even if the ignoring code is 
toolchain-
specific.

- Adam Farley

> On 2018-03-27 18:44, Phil Race wrote:
> 
>> As I said I prefer the make file change, since this is a change to an 
upstream library.
> 
> Newtons fourth law: For every reviewer, there's an equal and opposite 
reviewer. :) 
> 
> Here I am, advocating a source code fix. As Thomas says, the compiler 
complaint seems reasonable, and disabling it might cause us to miss other 
future errors.
> 
> Why can't we push the source code fix, and also submit it upstream?
> 
> /Magnus
> 
> 
> I've looked at jpeg-9c and it still looks identical to what we have in 
6b, so this code
> seems to have stood the test of time. I'm also unclear why the compiler 
would
> complain about that and not the one a few lines later 
> 
> 
>  819   while (bits[i] == 0)          /* find largest codelength still in 
use */
>  820     i--;
> 
> A push to jchuff.c will get blown away if/when we upgrade.
> A tool-chain specific fix in the makefile with an appropriate comment is 
more targeted.
> 
> 
> -phil.
> 
> 
> On 03/27/2018 05:44 AM, Thomas St?fe wrote:
> 
> Hi all, 
> 
> 
> just a friendly reminder. I would like to push this tiny fix because 
tripping over this on our linux s390x builds is annoying (yes, we can 
maintain patch queues, but this is a constant error source).
> 
> 
> I will wait for 24 more hours until a reaction. If no serious objections 
are forcoming, I want to push it (tier1 tests ran thru, and me and 
Christoph langer are both Reviewers).
> 
> 
> Thanks! Thomas
> 
> 
> On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe <thomas.stuefe at gmail.com> 
wrote:
> 
> Hi all, 
> 
> 
> may I please have another review for this really trivial change. It 
fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to 
fix this.
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> webrev: 
http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/
> 
> 
> This was contributed by Adam Farley at IBM.
> 
> 
> I already reviewed this. I also test-built on zlinux and it works.
> 
> 
> Thanks, Thomas
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From magnus.ihse.bursie at oracle.com  Mon Apr 16 11:50:22 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 13:50:22 +0200
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <OF4FD84867.2F3F50A9-ON00258271.003C2E7F-80258271.003C4D7F@notes.na.collabserv.com>
References: <OF4FD84867.2F3F50A9-ON00258271.003C2E7F-80258271.003C4D7F@notes.na.collabserv.com>
Message-ID: <2682b47d-7d36-2fcd-7f79-928217925c13@oracle.com>

On 2018-04-16 12:58, Adam Farley8 wrote:
> I also advocate the source code fix, as Make isn't meant to use the 
> sort of logic required
> to properly analyse the toolchain version string.
>
> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 
> 4.8.6, and Make doesn't
> seem to do substring stuff unless you mess around with shells.
>
> Plus, as people have said, it's better to solve problem x (or work 
> around a specific
> instance of x) than to ignore the exception, even if the ignoring code 
> is toolchain-
> specific.
>
> - Adam Farley
>
> > On 2018-03-27 18:44, Phil Race wrote:
> > 
> >> As I said I prefer the make file change, since this is a change to an 
> upstream library.
> > 
> > Newtons fourth law: For every reviewer, there's an equal and opposite 
> reviewer. :)
> > 
> > Here I am, advocating a source code fix. As Thomas says, the compiler 
> complaint seems reasonable, and disabling it might cause us to miss 
> other future errors.
> > 
> > Why can't we push the source code fix, and also submit it upstream?
> > 
> > /Magnus
> > 
> > 
> > I've looked at jpeg-9c and it still looks identical to what we have in 6b, 
> so this code
> > seems to have stood the test of time. I'm also unclear why the compiler would
> > complain about that and not the one a few lines later
> >  
> > 
> > ?819 ? while (bits[i] == 0) ? ? ? ? ?/* find largest codelength still in 
> use */
> > ?820 ? ? i--;
> > 
> > A push to jchuff.c will get blown away if/when we upgrade.
> > A tool-chain specific fix in the makefile with an appropriate comment 
> is more targeted.

Phil,

Returning to this.

While I understand your reluctance to patch upstream code, let me point 
out that we have not updated libjpeg a single time since the JDK was 
open sourced. We're using 6b from 27-Mar-1998. I had a look at the 
Wikipedia page on libjpeg, and this is the latest "uncontroversial" 
version of the source. Versions 7 and up have proprietary extensions, 
which in turn has resulted in multiple forks of libjpeg. As it stands, 
it seems unlikely that we will ever replace libjpeg 6b with a simple 
upgrade from upstream.

I therefore maintain my position that a source code fix would be the 
best way forward here.

/Magnus


>
> > 
> > 
> > -phil.
> > 
> > 
> > On 03/27/2018 05:44 AM, Thomas St?fe wrote:
> > 
> > Hi all,
> > 
> > 
> > just a friendly reminder. I would like to push this tiny fix because 
> tripping over this on our linux s390x builds is annoying (yes, we can 
> maintain patch queues, but this is a constant error source).
> > 
> > 
> > I will wait for 24 more hours until a reaction. If no serious objections are 
> forcoming, I want to push it (tier1 tests ran thru, and me and 
> Christoph langer are both Reviewers).
> > 
> > 
> > Thanks! Thomas
> > 
> > 
> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> > 
> > Hi all,
> > 
> > 
> > may I please have another review for this really trivial change. It fixes a 
> gcc warning on s390 and ppc. Also, it is probably a good idea to fix 
> this.
> > 
> > 
> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ <http://cr.openjdk.java.net/%7Estuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/>
> > 
> > 
> > This was contributed by Adam Farley at IBM.
> > 
> > 
> > I already reviewed this. I also test-built on zlinux and it works.
> > 
> > 
> > Thanks, Thomas
> > 
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From magnus.ihse.bursie at oracle.com  Mon Apr 16 11:59:34 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 13:59:34 +0200
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
In-Reply-To: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
References: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
Message-ID: <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>

On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
> Hi,
>
> could I please get reviewes for this tiny fix?
> Grep does not grok the syntax of the replacement of space to newline.
> It causes configure failures on SLES 11.
>
> http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/
Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)

Goetz, please try this patch instead, which uses the new 
BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works correctly on 
SLES 11 as well.

diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -443,7 +443,7 @@
 ???? AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])

 ???? # Validate features (for configure script errors, not user errors)
-??? INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}" <<< 
"${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
+??? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES, 
$JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
 ???? if test "x$INVALID_FEATURES" != x; then
 ?????? AC_MSG_ERROR([Internal configure script error. Invalid JVM 
feature(s): $INVALID_FEATURES])
 ???? fi

/Magnus


From magnus.ihse.bursie at oracle.com  Mon Apr 16 12:07:08 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 14:07:08 +0200
Subject: Fix for JDK-8201483 broken '-' containing features
In-Reply-To: <48287C18-5572-4F4E-87AD-8986066A3060@gmail.com>
References: <48287C18-5572-4F4E-87AD-8986066A3060@gmail.com>
Message-ID: <cf852ba5-e1b8-f00a-a373-a5a1bafdfca5@oracle.com>

On 2018-04-13 17:23, Chris Dennis wrote:
> Hi All,
>
> It looks like the addition of support for disabling features has broken support for enabling features that contain a ?-? in their name (amusingly this includes the 'all-gcs? feature).
>
> Pretty sure this is the offending code is the use of 'match($i, /-.*/)? to distinguish between disabled and enabled features. That regex needs to match a ?-' only at the beginning of the line otherwise configures thinks you are disabling the ?ll-gcs? feature.

You are correct. I noticed this in the follow-up bug I'm working on, to 
further clean up JVM feature handling, and thought it would be enough to 
fix it in that bug.

But since you ran into it, I'll make a high-priority fix. (I'm glad to 
see someone is actually using this code! :-) Sorry I broke it. :()
I opened https://bugs.openjdk.java.net/browse/JDK-8201591.

/Magnus


>
> Thanks,
>
> Chris Dennis



From magnus.ihse.bursie at oracle.com  Mon Apr 16 12:07:55 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 14:07:55 +0200
Subject: RFR: JDK-8201591 JVM features with "-" in name is not correctly
 handled
Message-ID: <ca2e019b-f93d-955b-6225-fed1f627d7ac@oracle.com>

JDK-8201483 caused a regression for enabling JVM features with a dash in 
the name.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201591
Patch inline:
diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -269,9 +269,9 @@
 ???? USER_JVM_FEATURE_LIST=`$ECHO $with_jvm_features | $SED -e 's/,/ /g'`
 ???? AC_MSG_RESULT([$user_jvm_feature_list])
 ???? # These features will be added to all variant defaults
-??? JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for (i=1; 
i<=NF; i++) if (!match($i, /-.*/)) print $i }'`
+??? JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for (i=1; 
i<=NF; i++) if (!match($i, /^-.*/)) print $i }'`
 ???? # These features will be removed from all variant defaults
-??? DISABLED_JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for 
(i=1; i<=NF; i++) if (match($i, /-.*/)) print substr($i, 2) }'`
+??? DISABLED_JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for 
(i=1; i<=NF; i++) if (match($i, /^-.*/)) print substr($i, 2) }'`

 ???? # Verify that the user has provided valid features
 ???? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES, $JVM_FEATURES 
$DISABLED_JVM_FEATURES, $VALID_JVM_FEATURES)

/Magnus



From goetz.lindenmaier at sap.com  Mon Apr 16 12:15:26 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 16 Apr 2018 12:15:26 +0000
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
In-Reply-To: <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>
References: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
 <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>
Message-ID: <b61befc16cf54abebd615383afab90a0@sap.com>

Hi Magnus, 

yes, that works too:
http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
Can I push this right away if I get a second review?

Best regards,
 Goetz

> -----Original Message-----
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> Sent: Montag, 16. April 2018 14:00
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; build-dev (build-
> dev at openjdk.java.net) <build-dev at openjdk.java.net>
> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> 
> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > could I please get reviewes for this tiny fix?
> > Grep does not grok the syntax of the replacement of space to newline.
> > It causes configure failures on SLES 11.
> >
> > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/
> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
> 
> Goetz, please try this patch instead, which uses the new
> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
> correctly on
> SLES 11 as well.
> 
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -443,7 +443,7 @@
>  ???? AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
> 
>  ???? # Validate features (for configure script errors, not user errors)
> -??? INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}" <<<
> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
> +??? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
>  ???? if test "x$INVALID_FEATURES" != x; then
>  ?????? AC_MSG_ERROR([Internal configure script error. Invalid JVM
> feature(s): $INVALID_FEATURES])
>  ???? fi
> 
> /Magnus

From volker.simonis at gmail.com  Mon Apr 16 12:19:56 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 16 Apr 2018 14:19:56 +0200
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
In-Reply-To: <b61befc16cf54abebd615383afab90a0@sap.com>
References: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
 <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>
 <b61befc16cf54abebd615383afab90a0@sap.com>
Message-ID: <CA+3eh12Rk7JNZCw1W5XhD1PKjLhaJyg9NCnRad-R=5KpmbxPuQ@mail.gmail.com>

Looks good!

Thanks for fixing,
Volker


On Mon, Apr 16, 2018 at 2:15 PM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi Magnus,
>
> yes, that works too:
> http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
> Can I push this right away if I get a second review?
>
> Best regards,
>  Goetz
>
>> -----Original Message-----
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>> Sent: Montag, 16. April 2018 14:00
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; build-dev (build-
>> dev at openjdk.java.net) <build-dev at openjdk.java.net>
>> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
>>
>> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
>> > Hi,
>> >
>> > could I please get reviewes for this tiny fix?
>> > Grep does not grok the syntax of the replacement of space to newline.
>> > It causes configure failures on SLES 11.
>> >
>> > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/
>> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
>>
>> Goetz, please try this patch instead, which uses the new
>> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
>> correctly on
>> SLES 11 as well.
>>
>> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
>> --- a/make/autoconf/hotspot.m4
>> +++ b/make/autoconf/hotspot.m4
>> @@ -443,7 +443,7 @@
>>       AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
>>
>>       # Validate features (for configure script errors, not user errors)
>> -    INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}" <<<
>> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
>> +    BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
>> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
>>       if test "x$INVALID_FEATURES" != x; then
>>         AC_MSG_ERROR([Internal configure script error. Invalid JVM
>> feature(s): $INVALID_FEATURES])
>>       fi
>>
>> /Magnus


From magnus.ihse.bursie at oracle.com  Mon Apr 16 12:26:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 14:26:52 +0200
Subject: <AWT Dev> [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI
 awareness for Windows 10 v1703
In-Reply-To: <ae18a893-7c7e-63fd-15c2-ec9a08d8403a@oracle.com>
References: <ae18a893-7c7e-63fd-15c2-ec9a08d8403a@oracle.com>
Message-ID: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com>

Hi Alexey,

Since this patch, I'm getting lots of warnings on Windows:

c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest 
: manifest authoring warning 81010002: Unrecognized Element 
"dpiAwareness" in namespace 
"http://schemas.microsoft.com/SMI/2016/WindowsSettings".

Seems this element is not universally recognized. Does it even work as 
intended?

Do you have any suggestion on how to address this issue?

/Magnus

On 2018-04-06 00:39, Alexey Ivanov wrote:
> Hello,
>
> Could you please review the fix for jdk11?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8199627
> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/
>
>
> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1]
>
> Java already supports "Per-Monitor v1" mode. This change extends High 
> DPI support in Java: in addition to <dpiAware> element [2], a new 
> <dpiAwareness> element [3] is added to Java launcher manifest. The 
> element <dpiAwareness> is recognized by Windows 10 v1607 and above, 
> PerMonitorV2 value is supported by Windows 10 v1703 and above.
>
> The most notable change for Java applications is that window title bar 
> is scaled correctly when application window moves from one monitor to 
> another or the scaling changes.
>
>
> When building, manifest tool generates warning for unknown 
> <dpiAwareness> element in manifest. It is because an older Windows SDK 
> is used to build JDK which does not know about an element that was 
> added later. The build succeeds despite the warning.
>
>
> Thank you in advance.
>
> Regards,
> Alexey
>
> [1] 
> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_ 
> <https://msdn.microsoft.com/library/windows/desktop/mt843498%28v=vs.85%29.aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_> 
>
> [2] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware 
> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx#dpiAware> 
>
> [3] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness 
> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx#dpiAwareness> 
>



From alexey.ivanov at oracle.com  Mon Apr 16 12:49:19 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 16 Apr 2018 13:49:19 +0100
Subject: <AWT Dev> [11] RFR for JDK-8199627: Use "Per-Monitor V2" High DPI
 awareness for Windows 10 v1703
In-Reply-To: <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com>
References: <ae18a893-7c7e-63fd-15c2-ec9a08d8403a@oracle.com>
 <2adbd191-0059-f70b-2691-833b49d6e5fd@oracle.com>
Message-ID: <ce7323e0-5a55-adf1-f4a8-15de441b7d44@oracle.com>

Hi Magnus,

I haven't found a way to suppress this warning. I tried. There's no way 
to suppress warnings from mt.exe [1] unfortunately.

We're using Visual Studio 2013 to build JDK, the element was added in 
2016. Newer versions of Windows SDK should recognise the element.

Yes, it works as intended. It's recognised by Windows 10 v1703 and later 
and changes High DPI mode. Other versions of Windows are not affected.


I should've included build-dev into the review process as it affects 
build system.
Can the output of mt.exe be redirected? If it's successful, then its 
output gets ignored.

Regards,
Alexey

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa375649(v=vs.85).aspx

On 16/04/2018 13:26, Magnus Ihse Bursie wrote:
> Hi Alexey,
>
> Since this patch, I'm getting lots of warnings on Windows:
>
> c:/cygwin64/home/magnusi/hg/sandbox/open/src/java.base/windows/native/launcher/java.manifest 
> : manifest authoring warning 81010002: Unrecognized Element 
> "dpiAwareness" in namespace 
> "http://schemas.microsoft.com/SMI/2016/WindowsSettings".
>
> Seems this element is not universally recognized. Does it even work as 
> intended?
>
> Do you have any suggestion on how to address this issue?
>
> /Magnus
>
> On 2018-04-06 00:39, Alexey Ivanov wrote:
>> Hello,
>>
>> Could you please review the fix for jdk11?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8199627
>> webrev: http://cr.openjdk.java.net/~aivanov/8199627/webrev.0/
>>
>>
>> Windows 10 v1703 provides improved High DPI mode: Per-Monitor v2. [1]
>>
>> <SNIP>
>>
>>
>> When building, manifest tool generates warning for unknown 
>> <dpiAwareness> element in manifest. It is because an older Windows 
>> SDK is used to build JDK which does not know about an element that 
>> was added later. The build succeeds despite the warning.
>>
>>
>> Thank you in advance.
>>
>> Regards,
>> Alexey
>>
>> [1] 
>> https://msdn.microsoft.com/library/windows/desktop/mt843498(v=vs.85).aspx#Per-Monitor_and_Per-Monitor__V2__DPI_Awareness_
>> [2] 
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAware
>> [3] 
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx#dpiAwareness
>



From magnus.ihse.bursie at oracle.com  Mon Apr 16 12:56:09 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 14:56:09 +0200
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
In-Reply-To: <b61befc16cf54abebd615383afab90a0@sap.com>
References: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
 <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>
 <b61befc16cf54abebd615383afab90a0@sap.com>
Message-ID: <8dfb7122-f07e-7722-b6c5-91d47cb9f96e@oracle.com>

On 2018-04-16 14:15, Lindenmaier, Goetz wrote:
> Hi Magnus,
>
> yes, that works too:
> http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
> Can I push this right away if I get a second review?
You don't need a second review for build changes, it's a hotspot team 
rule. You can push it right away now.

/Magnus
>
> Best regards,
>   Goetz
>
>> -----Original Message-----
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
>> Sent: Montag, 16. April 2018 14:00
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; build-dev (build-
>> dev at openjdk.java.net) <build-dev at openjdk.java.net>
>> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
>>
>> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> could I please get reviewes for this tiny fix?
>>> Grep does not grok the syntax of the replacement of space to newline.
>>> It causes configure failures on SLES 11.
>>>
>>> http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/01/
>> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
>>
>> Goetz, please try this patch instead, which uses the new
>> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
>> correctly on
>> SLES 11 as well.
>>
>> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
>> --- a/make/autoconf/hotspot.m4
>> +++ b/make/autoconf/hotspot.m4
>> @@ -443,7 +443,7 @@
>>   ???? AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
>>
>>   ???? # Validate features (for configure script errors, not user errors)
>> -??? INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}" <<<
>> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
>> +??? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
>> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
>>   ???? if test "x$INVALID_FEATURES" != x; then
>>   ?????? AC_MSG_ERROR([Internal configure script error. Invalid JVM
>> feature(s): $INVALID_FEATURES])
>>   ???? fi
>>
>> /Magnus



From alexey.ivanov at oracle.com  Mon Apr 16 12:59:23 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 16 Apr 2018 13:59:23 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <f6dbd54e78714305b78ecd3a3d232f11@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
 <7c5e68c2a023490e96ce6452fbda1700@sap.com>
 <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
 <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
 <f6dbd54e78714305b78ecd3a3d232f11@sap.com>
Message-ID: <c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>

Hi Matthias, Phil,

The build of 32 bit Windows is broken because of mlib_image.dll. As 
JNICALL modifier has been added to function declarations, they're 
exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. 
The functions in this library are looked up by their name [1] and 
therefore none can be found.

If you run tests in test/jdk/java/awt/image, for example 
test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail because 
ImagingLib is not available.

I'm working on a patch to fix it.


Regards,
Alexey

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60

On 13/04/2018 06:48, Baesken, Matthias wrote:
> Hi Phil/Alexey,  thanks for  adding the other lists .
>
>> Is this the current version of the change :  http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?
> Yes.
>
> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Donnerstag, 12. April 2018 23:53
>> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
>> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
>> hotspot-dev <hotspot-dev at openjdk.java.net>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>>
>> On 12/04/2018 21:42, Phil Race wrote:
>>> How can JNIEXPORT be different between 32 bit & 64 bit ?
>>> I'm sure you saw compilation errors but I don't get why it failed for
>>> 32 only.
>>>
>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
>>> explain why the 32 bit compiler would complain about inconsistent
>>> application
>>> of __declspec(dllexport) - ie JNIEXPORT.
>>>
>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation
>>> errors were all down to JNICALL ?
>> Adding missing JNIEXPORT is for cleanup only.
>>
>> The compiler complained about mismatched JNICALL / non-JNICALL
>> declarations as the macro changes calling convention from the default
>> __cdecl? to __stdcall on 32 bit Windows.
>>
>> Another issue is that __stdcall decorates the functions: prefixes with
>> underscore and postfixes with @ + size of parameters. Because of the
>> decorations, classLoader.cpp can't lookup the required functions by name
>> from zip.dll and jimage.dll. The functions are exported but with
>> different name.
>>
>> I hope this information adds more details to the picture.
>>
>>> I was a bit puzzled at the removals I saw here :
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
>>> .. I needed to look at the whole file to realise that you were
>>> removing a duplicate
>>> declaration.
>> That was tricky. I could have been mentioned in the review.
>>
>>
>> Regards,
>> Alexey
>>
>>> -phil.
>>>
>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
>>>> Hi? Alan , this is the up to date webrev .
>>>> However we want to add?? Alexey?? Ivanov? as additional? author .
>>>>
>>>>> As I read it, this changes the calling convention of these functions on
>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>
>>>> The? change adds? JNIEXPORT?? at some places? where it is? ben
>>>> forgotten , for example :
>>>>
>>>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
>>>>
>>>> This might have? potential? impact? on other platforms?? (fixes the
>>>> mismatches) .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>>>> Sent: Donnerstag, 12. April 2018 12:54
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>; core-libs-dev at openjdk.java.net
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Adding core-libs-dev as this is change code in libjava, libzip,
>>>>> libjimage, ...
>>>>>
>>>>> Can you confirm that this is the up to date webrev:
>>>>>  ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>
>>>>> As I read it, this changes the calling convention of these functions on
>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>
>>>>> -Alan
>>>>>
>>>>>
>>>>> <SNIP>



From magnus.ihse.bursie at oracle.com  Mon Apr 16 13:03:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 15:03:12 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
 places in function declarations/implementations
In-Reply-To: <c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
 <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
 <7c5e68c2a023490e96ce6452fbda1700@sap.com>
 <c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
 <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
 <f6dbd54e78714305b78ecd3a3d232f11@sap.com>
 <c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>
Message-ID: <e848b584-23c3-9690-1b2f-9c6d210ab3da@oracle.com>


On 2018-04-16 14:59, Alexey Ivanov wrote:
> Hi Matthias, Phil,
>
> The build of 32 bit Windows is broken because of mlib_image.dll. As 
> JNICALL modifier has been added to function declarations, they're 
> exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. 
> The functions in this library are looked up by their name [1] and 
> therefore none can be found.
You should most likely just be able to remove the JNICALL modifiers for 
libmlib_image.

/Magnus

>
> If you run tests in test/jdk/java/awt/image, for example 
> test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail 
> because ImagingLib is not available.
>
> I'm working on a patch to fix it.
>
>
> Regards,
> Alexey
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60
>
> On 13/04/2018 06:48, Baesken, Matthias wrote:
>> Hi Phil/Alexey,? thanks for? adding the other lists .
>>
>>> Is this the current version of the change : 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?
>> Yes.
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Donnerstag, 12. April 2018 23:53
>>> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
>>> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
>>> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
>>> hotspot-dev <hotspot-dev at openjdk.java.net>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in 
>>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>
>>> On 12/04/2018 21:42, Phil Race wrote:
>>>> How can JNIEXPORT be different between 32 bit & 64 bit ?
>>>> I'm sure you saw compilation errors but I don't get why it failed for
>>>> 32 only.
>>>>
>>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that 
>>>> doesn't
>>>> explain why the 32 bit compiler would complain about inconsistent
>>>> application
>>>> of __declspec(dllexport) - ie JNIEXPORT.
>>>>
>>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation
>>>> errors were all down to JNICALL ?
>>> Adding missing JNIEXPORT is for cleanup only.
>>>
>>> The compiler complained about mismatched JNICALL / non-JNICALL
>>> declarations as the macro changes calling convention from the default
>>> __cdecl? to __stdcall on 32 bit Windows.
>>>
>>> Another issue is that __stdcall decorates the functions: prefixes with
>>> underscore and postfixes with @ + size of parameters. Because of the
>>> decorations, classLoader.cpp can't lookup the required functions by 
>>> name
>>> from zip.dll and jimage.dll. The functions are exported but with
>>> different name.
>>>
>>> I hope this information adds more details to the picture.
>>>
>>>> I was a bit puzzled at the removals I saw here :
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
>>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
>>>> .. I needed to look at the whole file to realise that you were
>>>> removing a duplicate
>>>> declaration.
>>> That was tricky. I could have been mentioned in the review.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>> -phil.
>>>>
>>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
>>>>> Hi? Alan , this is the up to date webrev .
>>>>> However we want to add?? Alexey?? Ivanov? as additional author .
>>>>>
>>>>>> As I read it, this changes the calling convention of these 
>>>>>> functions on
>>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>>
>>>>> The? change adds? JNIEXPORT?? at some places? where it is ben
>>>>> forgotten , for example :
>>>>>
>>>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html 
>>>
>>>>>
>>>>> This might have? potential? impact? on other platforms (fixes the
>>>>> mismatches) .
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>>>>> Sent: Donnerstag, 12. April 2018 12:54
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse 
>>>>>> Bursie <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin 
>>>>>> <martin.doerr at sap.com>; core-libs-dev at openjdk.java.net
>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>>> function
>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / 
>>>>>> JNICALL at
>>>>>> some places in function declarations/implementations
>>>>>>
>>>>>> Adding core-libs-dev as this is change code in libjava, libzip,
>>>>>> libjimage, ...
>>>>>>
>>>>>> Can you confirm that this is the up to date webrev:
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>>
>>>>>> As I read it, this changes the calling convention of these 
>>>>>> functions on
>>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>>
>>>>>> -Alan
>>>>>>
>>>>>>
>>>>>> <SNIP>
>



From goetz.lindenmaier at sap.com  Mon Apr 16 13:32:06 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 16 Apr 2018 13:32:06 +0000
Subject: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
In-Reply-To: <8dfb7122-f07e-7722-b6c5-91d47cb9f96e@oracle.com>
References: <9aaa52a94c3148f79a1c6826c7bb9c2b@sap.com>
 <e2309ebd-032d-852c-f223-31e429da16f8@oracle.com>
 <b61befc16cf54abebd615383afab90a0@sap.com>
 <8dfb7122-f07e-7722-b6c5-91d47cb9f96e@oracle.com>
Message-ID: <8d22601b37fe40d3bf7aaf3a7c078a1a@sap.com>

Thanks Magnus and Volker!

Best regards,
  Goetz.

> -----Original Message-----
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> Sent: Montag, 16. April 2018 14:56
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; build-dev (build-
> dev at openjdk.java.net) <build-dev at openjdk.java.net>
> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> 
> On 2018-04-16 14:15, Lindenmaier, Goetz wrote:
> > Hi Magnus,
> >
> > yes, that works too:
> > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/
> > Can I push this right away if I get a second review?
> You don't need a second review for build changes, it's a hotspot team
> rule. You can push it right away now.
> 
> /Magnus
> >
> > Best regards,
> >   Goetz
> >
> >> -----Original Message-----
> >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >> Sent: Montag, 16. April 2018 14:00
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; build-dev (build-
> >> dev at openjdk.java.net) <build-dev at openjdk.java.net>
> >> Subject: Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483
> >>
> >> On 2018-04-16 11:16, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> could I please get reviewes for this tiny fix?
> >>> Grep does not grok the syntax of the replacement of space to newline.
> >>> It causes configure failures on SLES 11.
> >>>
> >>> http://cr.openjdk.java.net/~goetz/wr18/8201584-
> fixSLES11configure/01/
> >> Aha, that was the reason for those odd NEEDLE and STACK constructs. :-)
> >>
> >> Goetz, please try this patch instead, which uses the new
> >> BASIC_GET_NON_MATCHING_VALUES function. Hopefully, it works
> >> correctly on
> >> SLES 11 as well.
> >>
> >> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> >> --- a/make/autoconf/hotspot.m4
> >> +++ b/make/autoconf/hotspot.m4
> >> @@ -443,7 +443,7 @@
> >>   ???? AC_MSG_RESULT(["$JVM_FEATURES_FOR_VARIANT"])
> >>
> >>   ???? # Validate features (for configure script errors, not user errors)
> >> -??? INVALID_FEATURES=`$GREP -Fvx "${VALID_JVM_FEATURES// /$'\n'}"
> <<<
> >> "${JVM_FEATURES_FOR_VARIANT// /$'\n'}"`
> >> +??? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES,
> >> $JVM_FEATURES_FOR_VARIANT, $VALID_JVM_FEATURES)
> >>   ???? if test "x$INVALID_FEATURES" != x; then
> >>   ?????? AC_MSG_ERROR([Internal configure script error. Invalid JVM
> >> feature(s): $INVALID_FEATURES])
> >>   ???? fi
> >>
> >> /Magnus


From erik.joelsson at oracle.com  Mon Apr 16 15:10:34 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Apr 2018 08:10:34 -0700
Subject: RFR: JDK-8201591 JVM features with "-" in name is not correctly
 handled
In-Reply-To: <ca2e019b-f93d-955b-6225-fed1f627d7ac@oracle.com>
References: <ca2e019b-f93d-955b-6225-fed1f627d7ac@oracle.com>
Message-ID: <dee5f226-6bb3-2cc7-ee97-2f1092868e3b@oracle.com>

Looks good.

/Erik


On 2018-04-16 05:07, Magnus Ihse Bursie wrote:
> JDK-8201483 caused a regression for enabling JVM features with a dash 
> in the name.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201591
> Patch inline:
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -269,9 +269,9 @@
> ???? USER_JVM_FEATURE_LIST=`$ECHO $with_jvm_features | $SED -e 's/,/ /g'`
> ???? AC_MSG_RESULT([$user_jvm_feature_list])
> ???? # These features will be added to all variant defaults
> -??? JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for (i=1; 
> i<=NF; i++) if (!match($i, /-.*/)) print $i }'`
> +??? JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for (i=1; 
> i<=NF; i++) if (!match($i, /^-.*/)) print $i }'`
> ???? # These features will be removed from all variant defaults
> -??? DISABLED_JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for 
> (i=1; i<=NF; i++) if (match($i, /-.*/)) print substr($i, 2) }'`
> +??? DISABLED_JVM_FEATURES=`$ECHO $USER_JVM_FEATURE_LIST | $AWK '{ for 
> (i=1; i<=NF; i++) if (match($i, /^-.*/)) print substr($i, 2) }'`
>
> ???? # Verify that the user has provided valid features
> ???? BASIC_GET_NON_MATCHING_VALUES(INVALID_FEATURES, $JVM_FEATURES 
> $DISABLED_JVM_FEATURES, $VALID_JVM_FEATURES)
>
> /Magnus
>



From philip.race at oracle.com  Mon Apr 16 19:09:36 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 16 Apr 2018 12:09:36 -0700
Subject: [11] Review Request: 8200146 Remove the appletviewer launcher
In-Reply-To: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com>
References: <419d6585-fa7f-f14a-bac8-3129ceb53c8b@oracle.com>
Message-ID: <5AD4F4F0.3010502@oracle.com>

+1

-phil.

On 3/30/18, 3:52 PM, Sergey Bylokhov wrote:
> Hello.
> Please review fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200146
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8200146/webrev.00
> CSR: https://bugs.openjdk.java.net/browse/JDK-8200549
>
> Fix description:
>  - The appletviewer launcher was removed from jdk/bin
>  - The man pages were removed
>  - Two tests which used appletviewer launcher directly were removed
>
> Note that the appletviewer was deprecated in in jdk9:
> https://bugs.openjdk.java.net/browse/JDK-8074165
>


From sgehwolf at redhat.com  Tue Apr 17 07:45:53 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 17 Apr 2018 09:45:53 +0200
Subject: 8201495: [Zero] Reduce limits of max heap size for boot JDK on
 s390
In-Reply-To: <9c5b34f5-682f-1e89-1527-c4673052298d@oracle.com>
References: <1523626847.4177.22.camel@redhat.com>
 <9c5b34f5-682f-1e89-1527-c4673052298d@oracle.com>
Message-ID: <1523951153.4090.4.camel@redhat.com>

Hi Magnus,

On Mon, 2018-04-16 at 10:58 +0200, Magnus Ihse Bursie wrote:
> On 2018-04-13 15:40, Severin Gehwolf wrote:
> > Hi,
> > 
> > We (Red Hat) have been building Zero on s390 for a while now. In order
> > to do so we needed to have this patch to reduce the maximum heap size
> > setting for big workloads. Otherwise we see this during (JDK 9) builds:
> > 
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
> > Error occurred during initialization of VM
> > Could not reserve enough space for 1048576KB object heap
> > 
> > NOTE: JDK 9 has the same build logic than JDK 11 in terms of big
> > workloads' JVM switches.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8201495
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.01/
> 
> Hi Severin,
> 
> As I said in the bug report (didn't notice that you've already sent out 
> a webrev here), I'm not really fond of adding platforms guard if they 
> can be avoided. Normally, Java programs use more or less the same amount 
> of heap regardless of platforms they run on, differing only by platform 
> word size. So if a lower mx is enough on s390 builds, it's mostly likely 
> to be enough on all platforms, and thus the guard is unnecessary, and 
> will only make it harder to update the code in the future.
> 
> Also, the value of ms is typically of less concern. While mx is setting 
> an upper bound on resource allocation, ms is more of a "performance 
> hint" to the gc. Unless this is needed for your fix to work, I recommend 
> you leave it at it's current value.

Latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.02/

This now only changes -Xmx unconditionally and it bootcycle-builds
successfully on linux 32 bit, ppc (32 bit Zero) and s390 (32 bit Zero).

I haven't heard back from jdk-submit. It's radio silence since I've
pushed the branch. Not sure what's up with that.

Magnus, you've OK'ed the patch on the bug. Asking here again to
clarify. Is it OK to push this?

Thanks,
Severin

> /Magnus
> 
> > 
> > Testing: Run configure on s390 and inspected the big workloads settings:
> > 
> > Before:
> > checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768
> > 
> > After:
> > checking flags for bootcycle boot jdk java command for big workloads... -Xms256M -Xmx768M -XX:ThreadStackSize=768
> > 
> > This should be fairly low risk, since the check is guarded by s390
> > archicture checks. Other architectures should be unaffected.
> > 
> > Thanks,
> > Severin
> 
> 


From james.laskey at oracle.com  Tue Apr 17 15:55:17 2018
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 17 Apr 2018 12:55:17 -0300
Subject: Amber repo build issue on MacOSX
Message-ID: <9191E7AD-DE19-44AF-8D4C-3604A71B9995@oracle.com>

cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory
make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [generate-link-opt-data] Error 2
make[2]: *** Waiting for unfinished jobs?.


Is there a workaround for this issue?




From claes.redestad at oracle.com  Tue Apr 17 16:03:09 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 17 Apr 2018 18:03:09 +0200
Subject: Amber repo build issue on MacOSX
In-Reply-To: <9191E7AD-DE19-44AF-8D4C-3604A71B9995@oracle.com>
References: <9191E7AD-DE19-44AF-8D4C-3604A71B9995@oracle.com>
Message-ID: <a5010771-77af-ff18-e283-95590a443ddf@oracle.com>

Looks like this one: https://bugs.openjdk.java.net/browse/JDK-8201508

On 2018-04-17 17:55, Jim Laskey wrote:
> cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory
> make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [generate-link-opt-data] Error 2
> make[2]: *** Waiting for unfinished jobs?.
>
>
> Is there a workaround for this issue?
>
>



From erik.joelsson at oracle.com  Tue Apr 17 16:05:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 17 Apr 2018 09:05:09 -0700
Subject: Amber repo build issue on MacOSX
In-Reply-To: <a5010771-77af-ff18-e283-95590a443ddf@oracle.com>
References: <9191E7AD-DE19-44AF-8D4C-3604A71B9995@oracle.com>
 <a5010771-77af-ff18-e283-95590a443ddf@oracle.com>
Message-ID: <ddcdcd99-d6fe-c30c-8af2-d3d273f95a68@oracle.com>

If you have that fix, it could potentially also be that you broke 
hotspot enough to not be able to generate the classlist file.

/Erik


On 2018-04-17 09:03, Claes Redestad wrote:
> Looks like this one: https://bugs.openjdk.java.net/browse/JDK-8201508
>
> On 2018-04-17 17:55, Jim Laskey wrote:
>> cp: 
>> /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: 
>> No such file or directory
>> make[3]: *** 
>> [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] 
>> Error 1
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [generate-link-opt-data] Error 2
>> make[2]: *** Waiting for unfinished jobs?.
>>
>>
>> Is there a workaround for this issue?
>>
>>
>



From glaubitz at physik.fu-berlin.de  Tue Apr 17 19:51:11 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 21:51:11 +0200
Subject: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
In-Reply-To: <0034a070-4fef-7909-e3bc-25b70251a737@oracle.com>
References: <e06d5119-0200-eac7-f3bb-a7f4f22cec1d@physik.fu-berlin.de>
 <0034a070-4fef-7909-e3bc-25b70251a737@oracle.com>
Message-ID: <bce55149-8c04-e410-c9e2-2a4ac6aaed75@physik.fu-berlin.de>

Hi Magnus!

On 04/10/2018 10:01 PM, Magnus Ihse Bursie wrote:
> The regression you noted was not caused by JDK-8201236, but by JDK-8198862 "Stop doing funky compilation stuff for dtrace". In fact, JDK-8201236 (which is
> pushed to jdk/jdk but not yet integrated into jdk/hs, apparently) will once again remove EXTRA_FILES from the SetupNativeCompilation, making zero work again.
> 
> So if you just wait until JDK-8201236 moves into jdk/hs, this will be fixed. Otherwise, you're just creating a merge conflict for the integrator. :(

Since the jdk/jdk and jdk/hs merge was finished today, I gave Zero on linux-sparc
another shot and lo and behold, it builds fine again :-).

Will update the bug report accordingly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From alexey.ivanov at oracle.com  Wed Apr 18 12:06:57 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Apr 2018 13:06:57 +0100
Subject: [8u-dev] RFR for JDK-8179079: Incremental HotSpot builds broken on
 Windows
Message-ID: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>

Hi,

Could you please review the following backport of the build fix for Windows:

jbs: https://bugs.openjdk.java.net/browse/JDK-8179079
review: 
http://mail.openjdk.java.net/pipermail/build-dev/2017-April/019045.html
changeset: http://hg.openjdk.java.net/jdk10/jdk10/rev/6426c94ee05f

The patch does not apply to 8u:
webrev: http://cr.openjdk.java.net/~aivanov/8179079/jdk8/webrev.0/


This problem exists in 8u builds as well. If you try to rebuild 8u, 
you'll get errors:

make[2]: *** No rule to make target 
'/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/include/jni.h
', needed by 
'/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj'. 
Stop.

It's because the generated dependency file contain CR (\r) character at 
the end of the file name and make interprets it as part of the file name.


Thank you!

Regards,
Alexey


From erik.joelsson at oracle.com  Wed Apr 18 15:27:40 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 18 Apr 2018 08:27:40 -0700
Subject: [8u-dev] RFR for JDK-8179079: Incremental HotSpot builds broken
 on Windows
In-Reply-To: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>
References: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>
Message-ID: <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>

Looks good. Thanks for taking care of this backport!

/Erik


On 2018-04-18 05:06, Alexey Ivanov wrote:
> Hi,
>
> Could you please review the following backport of the build fix for 
> Windows:
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8179079
> review: 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/019045.html
> changeset: http://hg.openjdk.java.net/jdk10/jdk10/rev/6426c94ee05f
>
> The patch does not apply to 8u:
> webrev: http://cr.openjdk.java.net/~aivanov/8179079/jdk8/webrev.0/
>
>
> This problem exists in 8u builds as well. If you try to rebuild 8u, 
> you'll get errors:
>
> make[2]: *** No rule to make target 
> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/include/jni.h
> ', needed by 
> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj'. 
> Stop.
>
> It's because the generated dependency file contain CR (\r) character 
> at the end of the file name and make interprets it as part of the file 
> name.
>
>
> Thank you!
>
> Regards,
> Alexey



From erik.joelsson at oracle.com  Wed Apr 18 15:54:51 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 18 Apr 2018 08:54:51 -0700
Subject: [8u-dev] RFR for JDK-8179079: Incremental HotSpot builds broken
 on Windows
In-Reply-To: <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>
References: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>
 <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>
Message-ID: <2b5dc3c7-032f-6c15-88d2-2c2bbad16796@oracle.com>

Filed https://bugs.openjdk.java.net/browse/JDK-8201807 the deploy issue.

/Erik


On 2018-04-18 08:27, Erik Joelsson wrote:
> Looks good. Thanks for taking care of this backport!
>
> /Erik
>
>
> On 2018-04-18 05:06, Alexey Ivanov wrote:
>> Hi,
>>
>> Could you please review the following backport of the build fix for 
>> Windows:
>>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8179079
>> review: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/019045.html
>> changeset: http://hg.openjdk.java.net/jdk10/jdk10/rev/6426c94ee05f
>>
>> The patch does not apply to 8u:
>> webrev: http://cr.openjdk.java.net/~aivanov/8179079/jdk8/webrev.0/
>>
>>
>> This problem exists in 8u builds as well. If you try to rebuild 8u, 
>> you'll get errors:
>>
>> make[2]: *** No rule to make target 
>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/include/jni.h
>> ', needed by 
>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj'. 
>> Stop.
>>
>> It's because the generated dependency file contain CR (\r) character 
>> at the end of the file name and make interprets it as part of the 
>> file name.
>>
>>
>> Thank you!
>>
>> Regards,
>> Alexey
>



From alexey.ivanov at oracle.com  Wed Apr 18 17:13:34 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Apr 2018 18:13:34 +0100
Subject: [8u-dev] RFA for JDK-8179079: Incremental HotSpot builds broken on
 Windows
In-Reply-To: <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>
References: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>
 <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>
Message-ID: <00101d99-f2c3-3746-5b23-d47ab4048088@oracle.com>

Hi,

Could you please approve this backport to 8u?


Regards,
Alexey

On 18/04/2018 16:27, Erik Joelsson wrote:
> Looks good. Thanks for taking care of this backport!
>
> /Erik
>
>
> On 2018-04-18 05:06, Alexey Ivanov wrote:
>> Hi,
>>
>> Could you please review the following backport of the build fix for 
>> Windows:
>>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8179079
>> review: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/019045.html
>> changeset: http://hg.openjdk.java.net/jdk10/jdk10/rev/6426c94ee05f
>>
>> The patch does not apply to 8u:
>> webrev: http://cr.openjdk.java.net/~aivanov/8179079/jdk8/webrev.0/
>>
>>
>> This problem exists in 8u builds as well. If you try to rebuild 8u, 
>> you'll get errors:
>>
>> make[2]: *** No rule to make target 
>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/include/jni.h
>> ', needed by 
>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj'. 
>> Stop.
>>
>> It's because the generated dependency file contain CR (\r) character 
>> at the end of the file name and make interprets it as part of the 
>> file name.
>>
>>
>> Thank you!
>>
>> Regards,
>> Alexey
>



From alexey.ivanov at oracle.com  Wed Apr 18 17:21:03 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 18 Apr 2018 18:21:03 +0100
Subject: [8u-dev] RFA for JDK-8179079: Incremental HotSpot builds broken
 on Windows
In-Reply-To: <00101d99-f2c3-3746-5b23-d47ab4048088@oracle.com>
References: <1841530b-5d3f-d3d8-1e0b-b2db5c6a2e34@oracle.com>
 <afd80521-02a4-af9d-f516-a0cbc78102aa@oracle.com>
 <00101d99-f2c3-3746-5b23-d47ab4048088@oracle.com>
Message-ID: <f3040afe-2bf6-d246-7573-c11dbeddd867@oracle.com>

Sorry for duplicate request.
Kevin proposes the same changeset, I'll let Kevin proceed as he has many 
other build tweaks.

-- 
Regards,
Alexey

On 18/04/2018 18:13, Alexey Ivanov wrote:
> Hi,
>
> Could you please approve this backport to 8u?
>
>
> Regards,
> Alexey
>
> On 18/04/2018 16:27, Erik Joelsson wrote:
>> Looks good. Thanks for taking care of this backport!
>>
>> /Erik
>>
>>
>> On 2018-04-18 05:06, Alexey Ivanov wrote:
>>> Hi,
>>>
>>> Could you please review the following backport of the build fix for 
>>> Windows:
>>>
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8179079
>>> review: 
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/019045.html
>>> changeset: http://hg.openjdk.java.net/jdk10/jdk10/rev/6426c94ee05f
>>>
>>> The patch does not apply to 8u:
>>> webrev: http://cr.openjdk.java.net/~aivanov/8179079/jdk8/webrev.0/
>>>
>>>
>>> This problem exists in 8u builds as well. If you try to rebuild 8u, 
>>> you'll get errors:
>>>
>>> make[2]: *** No rule to make target 
>>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/include/jni.h
>>> ', needed by 
>>> '/cygdrive/c/ade/work/jdk8u/build/windows-x86-normal-server-release/jdk/objs/libverify/check_code.obj'. 
>>> Stop.
>>>
>>> It's because the generated dependency file contain CR (\r) character 
>>> at the end of the file name and make interprets it as part of the 
>>> file name.
>>>
>>>
>>> Thank you!
>>>
>>> Regards,
>>> Alexey
>>
>



From sgehwolf at redhat.com  Thu Apr 19 14:46:09 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Apr 2018 16:46:09 +0200
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images target
Message-ID: <1524149169.4657.55.camel@redhat.com>

Hi,

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

I'd like to get a fix in for an old discussion which already happened a
while ago:
http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html

The issue is that for bootcycle-images target a recursive call to make
is being called with 'JOBS=""' which results in a call to "make -j".
Thus, make is free to use as many jobs as it would like. This may cause
for the occasional build failure. It has for us in the past.

In this old thread above a patch like this was discouraged, unless I
misunderstood something.

diff --git a/make/Main.gmk b/make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -321,7 +321,7 @@
         ifneq ($(COMPILE_TYPE), cross)
          $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
          +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
-             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
+             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
         else
          $(call LogWarn, Boot cycle build disabled when cross compiling)
         endif

It's my understanding that such a fix would pass down the relevant JOBS
setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
call? What am I missing? If somebody wants to shoot themselves in the
foot by doing:

configure ...
make JOBS=

That should be fine as it would just result in "make -j" calls without
arguments. The common case where the JOBS setting comes from configure
would be fixed, though. bootcycle-images target would result in "make
-j <num-cores>".

Thoughts? Suggestions?

Thanks,
Severin


From erik.joelsson at oracle.com  Thu Apr 19 15:25:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 19 Apr 2018 08:25:11 -0700
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <1524149169.4657.55.camel@redhat.com>
References: <1524149169.4657.55.camel@redhat.com>
Message-ID: <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>

Hello Severin,

The suggested patch is not a good idea because by setting -j on the make 
command line in a sub make disables the job server. The job server is 
what makes it possible to do recursive make with a fixed global number 
of "jobs". If you do as you suggest, you essentially double the total 
number of available "jobs". The original make retains its number and the 
submake get a full other set of the same number of "jobs".

My suggestion was to explicitly turn off the setting of JOBS based on a 
special variable flag, just for bootcycle builds. Magnus didn't like 
that because introducing a lot of special flags everywhere will 
eventually lead to very convoluted code. He instead suggested that the 
bootcycle call should continue to set JOBS to empty, then the code in 
Init.gmk which sets the -j flag should be changed to:

$(if $(JOBS), -j=$(JOBS))

So that we only set -j if JOBS have a value. My only objection to that 
was that we then no longer support the case of letting make run with any 
number of jobs. I do agree that removing that option isn't a big deal. 
You can always work around it by setting JOBS to a very large number 
(like 1000, which is way more than any possible concurrency currently 
possible in the build anyway).

So to summarize, I think the correct solution to the bug is the snippet 
above.

/Erik


On 2018-04-19 07:46, Severin Gehwolf wrote:
> Hi,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
>
> I'd like to get a fix in for an old discussion which already happened a
> while ago:
> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
>
> The issue is that for bootcycle-images target a recursive call to make
> is being called with 'JOBS=""' which results in a call to "make -j".
> Thus, make is free to use as many jobs as it would like. This may cause
> for the occasional build failure. It has for us in the past.
>
> In this old thread above a patch like this was discouraged, unless I
> misunderstood something.
>
> diff --git a/make/Main.gmk b/make/Main.gmk
> --- a/make/Main.gmk
> +++ b/make/Main.gmk
> @@ -321,7 +321,7 @@
>           ifneq ($(COMPILE_TYPE), cross)
>            $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
>            +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
> -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
> +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
>           else
>            $(call LogWarn, Boot cycle build disabled when cross compiling)
>           endif
>
> It's my understanding that such a fix would pass down the relevant JOBS
> setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
> call? What am I missing? If somebody wants to shoot themselves in the
> foot by doing:
>
> configure ...
> make JOBS=
>
> That should be fine as it would just result in "make -j" calls without
> arguments. The common case where the JOBS setting comes from configure
> would be fixed, though. bootcycle-images target would result in "make
> -j <num-cores>".
>
> Thoughts? Suggestions?
>
> Thanks,
> Severin



From sgehwolf at redhat.com  Thu Apr 19 15:58:50 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Apr 2018 17:58:50 +0200
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
References: <1524149169.4657.55.camel@redhat.com>
 <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
Message-ID: <1524153530.4657.64.camel@redhat.com>

Hi Erik,

Thanks for the review!

On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote:
> Hello Severin,
> 
> The suggested patch is not a good idea because by setting -j on the make 
> command line in a sub make disables the job server. The job server is 
> what makes it possible to do recursive make with a fixed global number 
> of "jobs". If you do as you suggest, you essentially double the total 
> number of available "jobs". The original make retains its number and the 
> submake get a full other set of the same number of "jobs".

I'm confused. Isn't this what the status quo is? With the difference
that it's currently setting JOBS="", thus allowing sub-make to add any
number of jobs. It'll result in sub-make calling "make -j" where '-j'
won't get an argument. If that's the case it's disabling the job server
currently too, no? Then again, why would we see build failures? I must
be missing something.

> My suggestion was to explicitly turn off the setting of JOBS based on a 
> special variable flag, just for bootcycle builds. Magnus didn't like 
> that because introducing a lot of special flags everywhere will 
> eventually lead to very convoluted code. He instead suggested that the 
> bootcycle call should continue to set JOBS to empty, then the code in 
> Init.gmk which sets the -j flag should be changed to:
> 
> $(if $(JOBS), -j=$(JOBS))
> 
> So that we only set -j if JOBS have a value. My only objection to that 
> was that we then no longer support the case of letting make run with any 
> number of jobs. I do agree that removing that option isn't a big deal. 
> You can always work around it by setting JOBS to a very large number 
> (like 1000, which is way more than any possible concurrency currently 
> possible in the build anyway).
> 
> So to summarize, I think the correct solution to the bug is the snippet 
> above.

Alright. How does this webrev look to you?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201788/webrev.01/

Thanks,
Severin

> /Erik
> 
> 
> On 2018-04-19 07:46, Severin Gehwolf wrote:
> > Hi,
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
> > 
> > I'd like to get a fix in for an old discussion which already happened a
> > while ago:
> > http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
> > 
> > The issue is that for bootcycle-images target a recursive call to make
> > is being called with 'JOBS=""' which results in a call to "make -j".
> > Thus, make is free to use as many jobs as it would like. This may cause
> > for the occasional build failure. It has for us in the past.
> > 
> > In this old thread above a patch like this was discouraged, unless I
> > misunderstood something.
> > 
> > diff --git a/make/Main.gmk b/make/Main.gmk
> > --- a/make/Main.gmk
> > +++ b/make/Main.gmk
> > @@ -321,7 +321,7 @@
> >           ifneq ($(COMPILE_TYPE), cross)
> >            $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
> >            +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
> > -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
> > +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
> >           else
> >            $(call LogWarn, Boot cycle build disabled when cross compiling)
> >           endif
> > 
> > It's my understanding that such a fix would pass down the relevant JOBS
> > setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
> > call? What am I missing? If somebody wants to shoot themselves in the
> > foot by doing:
> > 
> > configure ...
> > make JOBS=
> > 
> > That should be fine as it would just result in "make -j" calls without
> > arguments. The common case where the JOBS setting comes from configure
> > would be fixed, though. bootcycle-images target would result in "make
> > -j <num-cores>".
> > 
> > Thoughts? Suggestions?
> > 
> > Thanks,
> > Severin
> 
> 


From erik.joelsson at oracle.com  Thu Apr 19 16:03:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 19 Apr 2018 09:03:28 -0700
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <1524153530.4657.64.camel@redhat.com>
References: <1524149169.4657.55.camel@redhat.com>
 <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
 <1524153530.4657.64.camel@redhat.com>
Message-ID: <3799a621-2622-96fa-fc12-57bc9ceb8b48@oracle.com>

Hello,

On 2018-04-19 08:58, Severin Gehwolf wrote:
> Hi Erik,
>
> Thanks for the review!
>
> On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote:
>> Hello Severin,
>>
>> The suggested patch is not a good idea because by setting -j on the make
>> command line in a sub make disables the job server. The job server is
>> what makes it possible to do recursive make with a fixed global number
>> of "jobs". If you do as you suggest, you essentially double the total
>> number of available "jobs". The original make retains its number and the
>> submake get a full other set of the same number of "jobs".
> I'm confused. Isn't this what the status quo is? With the difference
> that it's currently setting JOBS="", thus allowing sub-make to add any
> number of jobs. It'll result in sub-make calling "make -j" where '-j'
> won't get an argument. If that's the case it's disabling the job server
> currently too, no? Then again, why would we see build failures? I must
> be missing something.
Ah, correct, the current code is also disabling the job server, that is 
the core of the issue. :) I'm sorry I wasn't clear on that, it was just 
so obvious in my world. Any -j flag in a sub make disables the job 
server connection between the calling make an the sub make. Setting it 
to -j without argument is going to wreck a lot more havoc than setting 
it to something like close to "number-of-cpus", which your first 
suggestion does. The former more or less creates a fork bomb, while the 
latter only over allocates by a factor 2 at the worst.
>> My suggestion was to explicitly turn off the setting of JOBS based on a
>> special variable flag, just for bootcycle builds. Magnus didn't like
>> that because introducing a lot of special flags everywhere will
>> eventually lead to very convoluted code. He instead suggested that the
>> bootcycle call should continue to set JOBS to empty, then the code in
>> Init.gmk which sets the -j flag should be changed to:
>>
>> $(if $(JOBS), -j=$(JOBS))
>>
>> So that we only set -j if JOBS have a value. My only objection to that
>> was that we then no longer support the case of letting make run with any
>> number of jobs. I do agree that removing that option isn't a big deal.
>> You can always work around it by setting JOBS to a very large number
>> (like 1000, which is way more than any possible concurrency currently
>> possible in the build anyway).
>>
>> So to summarize, I think the correct solution to the bug is the snippet
>> above.
> Alright. How does this webrev look to you?
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201788/webrev.01/
Yes, this looks good. Consider it reviewed.

/Erik
> Thanks,
> Severin
>
>> /Erik
>>
>>
>> On 2018-04-19 07:46, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
>>>
>>> I'd like to get a fix in for an old discussion which already happened a
>>> while ago:
>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
>>>
>>> The issue is that for bootcycle-images target a recursive call to make
>>> is being called with 'JOBS=""' which results in a call to "make -j".
>>> Thus, make is free to use as many jobs as it would like. This may cause
>>> for the occasional build failure. It has for us in the past.
>>>
>>> In this old thread above a patch like this was discouraged, unless I
>>> misunderstood something.
>>>
>>> diff --git a/make/Main.gmk b/make/Main.gmk
>>> --- a/make/Main.gmk
>>> +++ b/make/Main.gmk
>>> @@ -321,7 +321,7 @@
>>>            ifneq ($(COMPILE_TYPE), cross)
>>>             $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
>>>             +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
>>> -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
>>> +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
>>>            else
>>>             $(call LogWarn, Boot cycle build disabled when cross compiling)
>>>            endif
>>>
>>> It's my understanding that such a fix would pass down the relevant JOBS
>>> setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
>>> call? What am I missing? If somebody wants to shoot themselves in the
>>> foot by doing:
>>>
>>> configure ...
>>> make JOBS=
>>>
>>> That should be fine as it would just result in "make -j" calls without
>>> arguments. The common case where the JOBS setting comes from configure
>>> would be fixed, though. bootcycle-images target would result in "make
>>> -j <num-cores>".
>>>
>>> Thoughts? Suggestions?
>>>
>>> Thanks,
>>> Severin
>>



From sgehwolf at redhat.com  Thu Apr 19 18:08:03 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Apr 2018 20:08:03 +0200
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <3799a621-2622-96fa-fc12-57bc9ceb8b48@oracle.com>
References: <1524149169.4657.55.camel@redhat.com>
 <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
 <1524153530.4657.64.camel@redhat.com>
 <3799a621-2622-96fa-fc12-57bc9ceb8b48@oracle.com>
Message-ID: <1524161283.4657.67.camel@redhat.com>

Hi Erik,

On Thu, 2018-04-19 at 09:03 -0700, Erik Joelsson wrote:
> Hello,
> 
> On 2018-04-19 08:58, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > Thanks for the review!
> > 
> > On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote:
> > > Hello Severin,
> > > 
> > > The suggested patch is not a good idea because by setting -j on the make
> > > command line in a sub make disables the job server. The job server is
> > > what makes it possible to do recursive make with a fixed global number
> > > of "jobs". If you do as you suggest, you essentially double the total
> > > number of available "jobs". The original make retains its number and the
> > > submake get a full other set of the same number of "jobs".
> > 
> > I'm confused. Isn't this what the status quo is? With the difference
> > that it's currently setting JOBS="", thus allowing sub-make to add any
> > number of jobs. It'll result in sub-make calling "make -j" where '-j'
> > won't get an argument. If that's the case it's disabling the job server
> > currently too, no? Then again, why would we see build failures? I must
> > be missing something.
> 
> Ah, correct, the current code is also disabling the job server, that is 
> the core of the issue. :) I'm sorry I wasn't clear on that, it was just 
> so obvious in my world. Any -j flag in a sub make disables the job 
> server connection between the calling make an the sub make. Setting it 
> to -j without argument is going to wreck a lot more havoc than setting 
> it to something like close to "number-of-cpus", which your first 
> suggestion does. The former more or less creates a fork bomb, while the 
> latter only over allocates by a factor 2 at the worst.

OK. That does make it sound like that "disabling the job server" and
creating more jobs are independent problems. I somehow thought in my
naive world that disabling the job server puts an end to the fork-bomb
;-)

Thanks for the clarification.

> > > My suggestion was to explicitly turn off the setting of JOBS based on a
> > > special variable flag, just for bootcycle builds. Magnus didn't like
> > > that because introducing a lot of special flags everywhere will
> > > eventually lead to very convoluted code. He instead suggested that the
> > > bootcycle call should continue to set JOBS to empty, then the code in
> > > Init.gmk which sets the -j flag should be changed to:
> > > 
> > > $(if $(JOBS), -j=$(JOBS))
> > > 
> > > So that we only set -j if JOBS have a value. My only objection to that
> > > was that we then no longer support the case of letting make run with any
> > > number of jobs. I do agree that removing that option isn't a big deal.
> > > You can always work around it by setting JOBS to a very large number
> > > (like 1000, which is way more than any possible concurrency currently
> > > possible in the build anyway).
> > > 
> > > So to summarize, I think the correct solution to the bug is the snippet
> > > above.
> > 
> > Alright. How does this webrev look to you?
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201788/webrev.01/
> 
> Yes, this looks good. Consider it reviewed.

Great, thanks for the review! I'm currently running this through jdk-
submit. Hopefully I'll get some response this time :)

Cheers,
Severin

> /Erik
> > Thanks,
> > Severin
> > 
> > > /Erik
> > > 
> > > 
> > > On 2018-04-19 07:46, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
> > > > 
> > > > I'd like to get a fix in for an old discussion which already happened a
> > > > while ago:
> > > > http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
> > > > 
> > > > The issue is that for bootcycle-images target a recursive call to make
> > > > is being called with 'JOBS=""' which results in a call to "make -j".
> > > > Thus, make is free to use as many jobs as it would like. This may cause
> > > > for the occasional build failure. It has for us in the past.
> > > > 
> > > > In this old thread above a patch like this was discouraged, unless I
> > > > misunderstood something.
> > > > 
> > > > diff --git a/make/Main.gmk b/make/Main.gmk
> > > > --- a/make/Main.gmk
> > > > +++ b/make/Main.gmk
> > > > @@ -321,7 +321,7 @@
> > > >            ifneq ($(COMPILE_TYPE), cross)
> > > >             $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
> > > >             +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
> > > > -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
> > > > +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
> > > >            else
> > > >             $(call LogWarn, Boot cycle build disabled when cross compiling)
> > > >            endif
> > > > 
> > > > It's my understanding that such a fix would pass down the relevant JOBS
> > > > setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
> > > > call? What am I missing? If somebody wants to shoot themselves in the
> > > > foot by doing:
> > > > 
> > > > configure ...
> > > > make JOBS=
> > > > 
> > > > That should be fine as it would just result in "make -j" calls without
> > > > arguments. The common case where the JOBS setting comes from configure
> > > > would be fixed, though. bootcycle-images target would result in "make
> > > > -j <num-cores>".
> > > > 
> > > > Thoughts? Suggestions?
> > > > 
> > > > Thanks,
> > > > Severin
> 
> 


From magnus.ihse.bursie at oracle.com  Thu Apr 19 18:58:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 19 Apr 2018 20:58:52 +0200
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <1524161283.4657.67.camel@redhat.com>
References: <1524149169.4657.55.camel@redhat.com>
 <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
 <1524153530.4657.64.camel@redhat.com>
 <3799a621-2622-96fa-fc12-57bc9ceb8b48@oracle.com>
 <1524161283.4657.67.camel@redhat.com>
Message-ID: <A9976A33-5262-4A49-BEB0-E7BBD98B05E2@oracle.com>

Looks good to me too. Thanks for doing it this way. 

/Magnus

> 19 apr. 2018 kl. 20:08 skrev Severin Gehwolf <sgehwolf at redhat.com>:
> 
> Hi Erik,
> 
>> On Thu, 2018-04-19 at 09:03 -0700, Erik Joelsson wrote:
>> Hello,
>> 
>>> On 2018-04-19 08:58, Severin Gehwolf wrote:
>>> Hi Erik,
>>> 
>>> Thanks for the review!
>>> 
>>>> On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote:
>>>> Hello Severin,
>>>> 
>>>> The suggested patch is not a good idea because by setting -j on the make
>>>> command line in a sub make disables the job server. The job server is
>>>> what makes it possible to do recursive make with a fixed global number
>>>> of "jobs". If you do as you suggest, you essentially double the total
>>>> number of available "jobs". The original make retains its number and the
>>>> submake get a full other set of the same number of "jobs".
>>> 
>>> I'm confused. Isn't this what the status quo is? With the difference
>>> that it's currently setting JOBS="", thus allowing sub-make to add any
>>> number of jobs. It'll result in sub-make calling "make -j" where '-j'
>>> won't get an argument. If that's the case it's disabling the job server
>>> currently too, no? Then again, why would we see build failures? I must
>>> be missing something.
>> 
>> Ah, correct, the current code is also disabling the job server, that is 
>> the core of the issue. :) I'm sorry I wasn't clear on that, it was just 
>> so obvious in my world. Any -j flag in a sub make disables the job 
>> server connection between the calling make an the sub make. Setting it 
>> to -j without argument is going to wreck a lot more havoc than setting 
>> it to something like close to "number-of-cpus", which your first 
>> suggestion does. The former more or less creates a fork bomb, while the 
>> latter only over allocates by a factor 2 at the worst.
> 
> OK. That does make it sound like that "disabling the job server" and
> creating more jobs are independent problems. I somehow thought in my
> naive world that disabling the job server puts an end to the fork-bomb
> ;-)
> 
> Thanks for the clarification.
> 
>>>> My suggestion was to explicitly turn off the setting of JOBS based on a
>>>> special variable flag, just for bootcycle builds. Magnus didn't like
>>>> that because introducing a lot of special flags everywhere will
>>>> eventually lead to very convoluted code. He instead suggested that the
>>>> bootcycle call should continue to set JOBS to empty, then the code in
>>>> Init.gmk which sets the -j flag should be changed to:
>>>> 
>>>> $(if $(JOBS), -j=$(JOBS))
>>>> 
>>>> So that we only set -j if JOBS have a value. My only objection to that
>>>> was that we then no longer support the case of letting make run with any
>>>> number of jobs. I do agree that removing that option isn't a big deal.
>>>> You can always work around it by setting JOBS to a very large number
>>>> (like 1000, which is way more than any possible concurrency currently
>>>> possible in the build anyway).
>>>> 
>>>> So to summarize, I think the correct solution to the bug is the snippet
>>>> above.
>>> 
>>> Alright. How does this webrev look to you?
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201788/webrev.01/
>> 
>> Yes, this looks good. Consider it reviewed.
> 
> Great, thanks for the review! I'm currently running this through jdk-
> submit. Hopefully I'll get some response this time :)
> 
> Cheers,
> Severin
> 
>> /Erik
>>> Thanks,
>>> Severin
>>> 
>>>> /Erik
>>>> 
>>>> 
>>>>> On 2018-04-19 07:46, Severin Gehwolf wrote:
>>>>> Hi,
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
>>>>> 
>>>>> I'd like to get a fix in for an old discussion which already happened a
>>>>> while ago:
>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
>>>>> 
>>>>> The issue is that for bootcycle-images target a recursive call to make
>>>>> is being called with 'JOBS=""' which results in a call to "make -j".
>>>>> Thus, make is free to use as many jobs as it would like. This may cause
>>>>> for the occasional build failure. It has for us in the past.
>>>>> 
>>>>> In this old thread above a patch like this was discouraged, unless I
>>>>> misunderstood something.
>>>>> 
>>>>> diff --git a/make/Main.gmk b/make/Main.gmk
>>>>> --- a/make/Main.gmk
>>>>> +++ b/make/Main.gmk
>>>>> @@ -321,7 +321,7 @@
>>>>>           ifneq ($(COMPILE_TYPE), cross)
>>>>>            $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image)
>>>>>            +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
>>>>> -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
>>>>> +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
>>>>>           else
>>>>>            $(call LogWarn, Boot cycle build disabled when cross compiling)
>>>>>           endif
>>>>> 
>>>>> It's my understanding that such a fix would pass down the relevant JOBS
>>>>> setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
>>>>> call? What am I missing? If somebody wants to shoot themselves in the
>>>>> foot by doing:
>>>>> 
>>>>> configure ...
>>>>> make JOBS=
>>>>> 
>>>>> That should be fine as it would just result in "make -j" calls without
>>>>> arguments. The common case where the JOBS setting comes from configure
>>>>> would be fixed, though. bootcycle-images target would result in "make
>>>>> -j <num-cores>".
>>>>> 
>>>>> Thoughts? Suggestions?
>>>>> 
>>>>> Thanks,
>>>>> Severin
>> 
>> 



From magnus.ihse.bursie at oracle.com  Thu Apr 19 19:17:22 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 19 Apr 2018 21:17:22 +0200
Subject: RFR: JDK-8201536 configure fails compiler check due to bad -m32 flag
Message-ID: <c5045157-6161-ef4b-c3ae-899320fbebc1@oracle.com>

This is intended to be a proper fix for the -m32/-m64 compiler flag on 
unsupported platforms regression due to my previous flag refactoring.

Here's my analysis of the old code, from the bug report:

The old code set the -m<bits> flag in these cases:
if OS is solaris or aix,
or if OS_TYPE is unix and build_type is reduced

While this captures incorrect aspects of the situation, it has worked 
without complaints. I think what it *really* tries to do is:
* We can only run reduced builds on platforms where we can set the 
-m<bits> flag.
* xlc and sunstudio compilers needs to have -m<bits> (or -q<bits> in the 
case of xlc) to function properly. I assume this also means it's always 
supported for those compilers on the platforms we support there.

For clang/gcc, the flag applies to x86, sparc and ppc. Maybe we should 
just set it on x86, but then again, it won't hurt to set it on all these 
three architectures.

In theory, this means that reduced builds should be able to be supported 
on all platforms that support sunstudio and xlc. However, these are, 
afaik: solaris-sparcv9, solaris-x86_64, aix-ppc64, aix-s390x, where we 
do not support a 32-bit variant anyway. I do not know if there is an 
aix-x86 and aix-x86_64? If so, we should be able to do a reduced build 
for aix-x86_64.

So in practice, reduced builds are supported only for clang/gcc on 
x86_64. (And Windows, which uses a different mechanism.)


Bug: https://bugs.openjdk.java.net/browse/JDK-8201536
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8201536-fix-m64-cflag/webrev.01

/Magnus



From erik.joelsson at oracle.com  Thu Apr 19 20:19:45 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 19 Apr 2018 13:19:45 -0700
Subject: RFR: JDK-8201536 configure fails compiler check due to bad -m32
 flag
In-Reply-To: <c5045157-6161-ef4b-c3ae-899320fbebc1@oracle.com>
References: <c5045157-6161-ef4b-c3ae-899320fbebc1@oracle.com>
Message-ID: <d12516bb-5032-ee99-e48d-69a6bdea2cc3@oracle.com>

Looks good.

/Erik


On 2018-04-19 12:17, Magnus Ihse Bursie wrote:
> This is intended to be a proper fix for the -m32/-m64 compiler flag on 
> unsupported platforms regression due to my previous flag refactoring.
>
> Here's my analysis of the old code, from the bug report:
>
> The old code set the -m<bits> flag in these cases:
> if OS is solaris or aix,
> or if OS_TYPE is unix and build_type is reduced
>
> While this captures incorrect aspects of the situation, it has worked 
> without complaints. I think what it *really* tries to do is:
> * We can only run reduced builds on platforms where we can set the 
> -m<bits> flag.
> * xlc and sunstudio compilers needs to have -m<bits> (or -q<bits> in 
> the case of xlc) to function properly. I assume this also means it's 
> always supported for those compilers on the platforms we support there.
>
> For clang/gcc, the flag applies to x86, sparc and ppc. Maybe we should 
> just set it on x86, but then again, it won't hurt to set it on all 
> these three architectures.
>
> In theory, this means that reduced builds should be able to be 
> supported on all platforms that support sunstudio and xlc. However, 
> these are, afaik: solaris-sparcv9, solaris-x86_64, aix-ppc64, 
> aix-s390x, where we do not support a 32-bit variant anyway. I do not 
> know if there is an aix-x86 and aix-x86_64? If so, we should be able 
> to do a reduced build for aix-x86_64.
>
> So in practice, reduced builds are supported only for clang/gcc on 
> x86_64. (And Windows, which uses a different mechanism.)
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201536
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8201536-fix-m64-cflag/webrev.01
>
> /Magnus
>



From mikael.vidstedt at oracle.com  Thu Apr 19 22:41:35 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 19 Apr 2018 15:41:35 -0700
Subject: RFR: JDK-8202052: Disable warnings when building libawt with VS2017	
Message-ID: <B15337B2-1E93-4808-ACA1-6CC4E33D28DC@oracle.com>


Please review the following change which disables some warnings in libawt which show up when building with VS2017:

bug: https://bugs.openjdk.java.net/browse/JDK-8202052 <https://bugs.openjdk.java.net/browse/JDK-8202052>
webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/>


Please note that I also filed an issue which covers addressing these warnings in the Right(tm) way (and then removing the disabling of the warnings):

https://bugs.openjdk.java.net/browse/JDK-8202051 <https://bugs.openjdk.java.net/browse/JDK-8202051>


I have tested this with VS2017, and will also verify that it works with the existing toolchain version (used at Oracle).

Cheers,
Mikael



From philip.race at oracle.com  Thu Apr 19 22:51:00 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 19 Apr 2018 15:51:00 -0700
Subject: [OpenJDK 2D-Dev] RFR: JDK-8202052: Disable warnings when building
 libawt with VS2017
In-Reply-To: <B15337B2-1E93-4808-ACA1-6CC4E33D28DC@oracle.com>
References: <B15337B2-1E93-4808-ACA1-6CC4E33D28DC@oracle.com>
Message-ID: <5AD91D54.40609@oracle.com>

+1

-phil.

On 4/19/18, 3:41 PM, Mikael Vidstedt wrote:
>
> Please review the following change which disables some warnings in 
> libawt which show up when building with VS2017:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8202052
> webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ 
> <http://cr.openjdk.java.net/%7Emikael/webrevs/8202062/webrev.00/open/webrev/>
>
>
> Please note that I also filed an issue which covers addressing these 
> warnings in the Right(tm) way (and then removing the disabling of the 
> warnings):
>
> https://bugs.openjdk.java.net/browse/JDK-8202051
>
>
> I have tested this with VS2017, and will also verify that it works 
> with the existing toolchain version (used at Oracle).
>
> Cheers,
> Mikael
>


From erik.joelsson at oracle.com  Thu Apr 19 22:54:43 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 19 Apr 2018 15:54:43 -0700
Subject: RFR: JDK-8202052: Disable warnings when building libawt with
 VS2017
In-Reply-To: <B15337B2-1E93-4808-ACA1-6CC4E33D28DC@oracle.com>
References: <B15337B2-1E93-4808-ACA1-6CC4E33D28DC@oracle.com>
Message-ID: <c7960431-5870-9c58-6c04-010941555b30@oracle.com>

Looks good.

/Erik


On 2018-04-19 15:41, Mikael Vidstedt wrote:
> Please review the following change which disables some warnings in libawt which show up when building with VS2017:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8202052 <https://bugs.openjdk.java.net/browse/JDK-8202052>
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/>
>
>
> Please note that I also filed an issue which covers addressing these warnings in the Right(tm) way (and then removing the disabling of the warnings):
>
> https://bugs.openjdk.java.net/browse/JDK-8202051 <https://bugs.openjdk.java.net/browse/JDK-8202051>
>
>
> I have tested this with VS2017, and will also verify that it works with the existing toolchain version (used at Oracle).
>
> Cheers,
> Mikael
>



From sgehwolf at redhat.com  Fri Apr 20 07:51:14 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 20 Apr 2018 09:51:14 +0200
Subject: RFR: 8201788: Number of make jobs wrong for bootcycle-images
 target
In-Reply-To: <A9976A33-5262-4A49-BEB0-E7BBD98B05E2@oracle.com>
References: <1524149169.4657.55.camel@redhat.com>
 <499507ac-80e6-50d6-fd9a-e2b6e902e5e3@oracle.com>
 <1524153530.4657.64.camel@redhat.com>
 <3799a621-2622-96fa-fc12-57bc9ceb8b48@oracle.com>
 <1524161283.4657.67.camel@redhat.com>
 <A9976A33-5262-4A49-BEB0-E7BBD98B05E2@oracle.com>
Message-ID: <1524210674.4098.1.camel@redhat.com>

Hi Magnus,

On Thu, 2018-04-19 at 20:58 +0200, Magnus Ihse Bursie wrote:
> Looks good to me too. Thanks for doing it this way. 

Thanks for the review, pushed (jdk-submit came back clean).

Cheers,
Severin

> /Magnus
> 
> > 19 apr. 2018 kl. 20:08 skrev Severin Gehwolf <sgehwolf at redhat.com>:
> > 
> > Hi Erik,
> > 
> > > On Thu, 2018-04-19 at 09:03 -0700, Erik Joelsson wrote:
> > > Hello,
> > > 
> > > > On 2018-04-19 08:58, Severin Gehwolf wrote:
> > > > Hi Erik,
> > > > 
> > > > Thanks for the review!
> > > > 
> > > > > On Thu, 2018-04-19 at 08:25 -0700, Erik Joelsson wrote:
> > > > > Hello Severin,
> > > > > 
> > > > > The suggested patch is not a good idea because by setting -j
> > > > > on the make
> > > > > command line in a sub make disables the job server. The job
> > > > > server is
> > > > > what makes it possible to do recursive make with a fixed
> > > > > global number
> > > > > of "jobs". If you do as you suggest, you essentially double
> > > > > the total
> > > > > number of available "jobs". The original make retains its
> > > > > number and the
> > > > > submake get a full other set of the same number of "jobs".
> > > > 
> > > > I'm confused. Isn't this what the status quo is? With the
> > > > difference
> > > > that it's currently setting JOBS="", thus allowing sub-make to
> > > > add any
> > > > number of jobs. It'll result in sub-make calling "make -j"
> > > > where '-j'
> > > > won't get an argument. If that's the case it's disabling the
> > > > job server
> > > > currently too, no? Then again, why would we see build failures?
> > > > I must
> > > > be missing something.
> > > 
> > > Ah, correct, the current code is also disabling the job server,
> > > that is 
> > > the core of the issue. :) I'm sorry I wasn't clear on that, it
> > > was just 
> > > so obvious in my world. Any -j flag in a sub make disables the
> > > job 
> > > server connection between the calling make an the sub make.
> > > Setting it 
> > > to -j without argument is going to wreck a lot more havoc than
> > > setting 
> > > it to something like close to "number-of-cpus", which your first 
> > > suggestion does. The former more or less creates a fork bomb,
> > > while the 
> > > latter only over allocates by a factor 2 at the worst.
> > 
> > OK. That does make it sound like that "disabling the job server"
> > and
> > creating more jobs are independent problems. I somehow thought in
> > my
> > naive world that disabling the job server puts an end to the fork-
> > bomb
> > ;-)
> > 
> > Thanks for the clarification.
> > 
> > > > > My suggestion was to explicitly turn off the setting of JOBS
> > > > > based on a
> > > > > special variable flag, just for bootcycle builds. Magnus
> > > > > didn't like
> > > > > that because introducing a lot of special flags everywhere
> > > > > will
> > > > > eventually lead to very convoluted code. He instead suggested
> > > > > that the
> > > > > bootcycle call should continue to set JOBS to empty, then the
> > > > > code in
> > > > > Init.gmk which sets the -j flag should be changed to:
> > > > > 
> > > > > $(if $(JOBS), -j=$(JOBS))
> > > > > 
> > > > > So that we only set -j if JOBS have a value. My only
> > > > > objection to that
> > > > > was that we then no longer support the case of letting make
> > > > > run with any
> > > > > number of jobs. I do agree that removing that option isn't a
> > > > > big deal.
> > > > > You can always work around it by setting JOBS to a very large
> > > > > number
> > > > > (like 1000, which is way more than any possible concurrency
> > > > > currently
> > > > > possible in the build anyway).
> > > > > 
> > > > > So to summarize, I think the correct solution to the bug is
> > > > > the snippet
> > > > > above.
> > > > 
> > > > Alright. How does this webrev look to you?
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201788/webrev
> > > > .01/
> > > 
> > > Yes, this looks good. Consider it reviewed.
> > 
> > Great, thanks for the review! I'm currently running this through
> > jdk-
> > submit. Hopefully I'll get some response this time :)
> > 
> > Cheers,
> > Severin
> > 
> > > /Erik
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > /Erik
> > > > > 
> > > > > 
> > > > > > On 2018-04-19 07:46, Severin Gehwolf wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
> > > > > > 
> > > > > > I'd like to get a fix in for an old discussion which
> > > > > > already happened a
> > > > > > while ago:
> > > > > > http://mail.openjdk.java.net/pipermail/build-dev/2017-April
> > > > > > /018929.html
> > > > > > 
> > > > > > The issue is that for bootcycle-images target a recursive
> > > > > > call to make
> > > > > > is being called with 'JOBS=""' which results in a call to
> > > > > > "make -j".
> > > > > > Thus, make is free to use as many jobs as it would like.
> > > > > > This may cause
> > > > > > for the occasional build failure. It has for us in the
> > > > > > past.
> > > > > > 
> > > > > > In this old thread above a patch like this was discouraged,
> > > > > > unless I
> > > > > > misunderstood something.
> > > > > > 
> > > > > > diff --git a/make/Main.gmk b/make/Main.gmk
> > > > > > --- a/make/Main.gmk
> > > > > > +++ b/make/Main.gmk
> > > > > > @@ -321,7 +321,7 @@
> > > > > >           ifneq ($(COMPILE_TYPE), cross)
> > > > > >            $(call LogWarn, Boot cycle build step 2:
> > > > > > Building a new JDK image using previously built image)
> > > > > >            +$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk
> > > > > > PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
> > > > > > -             JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk
> > > > > > main
> > > > > > +             JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-
> > > > > > spec.gmk main
> > > > > >           else
> > > > > >            $(call LogWarn, Boot cycle build disabled when
> > > > > > cross compiling)
> > > > > >           endif
> > > > > > 
> > > > > > It's my understanding that such a fix would pass down the
> > > > > > relevant JOBS
> > > > > > setting to sub-make and, thus, producing the desired 'make
> > > > > > -j <JOBS>'
> > > > > > call? What am I missing? If somebody wants to shoot
> > > > > > themselves in the
> > > > > > foot by doing:
> > > > > > 
> > > > > > configure ...
> > > > > > make JOBS=
> > > > > > 
> > > > > > That should be fine as it would just result in "make -j"
> > > > > > calls without
> > > > > > arguments. The common case where the JOBS setting comes
> > > > > > from configure
> > > > > > would be fixed, though. bootcycle-images target would
> > > > > > result in "make
> > > > > > -j <num-cores>".
> > > > > > 
> > > > > > Thoughts? Suggestions?
> > > > > > 
> > > > > > Thanks,
> > > > > > Severin
> > > 
> > > 
> 
> 


From kevin.walls at oracle.com  Fri Apr 20 20:18:51 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 20 Apr 2018 21:18:51 +0100
Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with Visual
 Studio 2013 (VS2013)
Message-ID: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com>

Hi,

I'd like to request a review of the backport from 9 to 8u:

8042707: Source changes needed to build JDK 9 with Visual Studio 2013 (VS2013)
JBS: https://bugs.openjdk.java.net/browse/JDK-8042707

9 changesets:
base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890
jdk repo:  http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad

9 review thread: http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html


Notes:
base repo:
toolchain_windows.m4: quite a bit of manual work, but no conflicts.
make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't have in 8u
flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the same change.

jdk repo:
make/copy/Copy-java.base.gmk we don't have in 8u. The other two files apply cleanly.


Clearly this backport isn't to change anything about what compilers are supported or recommended,
it's just about the build infrastructure.


8u change: webrev of the base repo changes:
http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/

Many thanks
Kevin



From kumar.x.srinivasan at oracle.com  Fri Apr 20 21:19:31 2018
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 20 Apr 2018 14:19:31 -0700
Subject: RFR: 8201259: Fix warning with VS2017 in jdk.pack
Message-ID: <5ADA5963.6030903@oracle.com>

Hello,

Please review fix [1] for VS2017 to compile pack200 native header
file,  without warnings.

Thanks
Kumar

[1] http://cr.openjdk.java.net/~ksrini/8201259/


From erik.joelsson at oracle.com  Fri Apr 20 22:27:38 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 20 Apr 2018 15:27:38 -0700
Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with
 Visual Studio 2013 (VS2013)
In-Reply-To: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com>
References: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com>
Message-ID: <e740840c-336d-4563-07f8-4b4cb9e32d8b@oracle.com>

The root repo changes look ok.

The changes in Copy-java.base.gmk applies to jdk/make/CopyFiles.gmk. 
Those changes are definitely needed.

/Erik


On 2018-04-20 13:18, Kevin Walls wrote:
> Hi,
>
> I'd like to request a review of the backport from 9 to 8u:
>
> 8042707: Source changes needed to build JDK 9 with Visual Studio 2013 
> (VS2013)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8042707
>
> 9 changesets:
> base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890
> jdk repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad
>
> 9 review thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html
>
>
> Notes:
> base repo:
> toolchain_windows.m4: quite a bit of manual work, but no conflicts.
> make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't 
> have in 8u
> flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the 
> same change.
>
> jdk repo:
> make/copy/Copy-java.base.gmk we don't have in 8u. The other two files 
> apply cleanly.
>
>
> Clearly this backport isn't to change anything about what compilers 
> are supported or recommended,
> it's just about the build infrastructure.
>
>
> 8u change: webrev of the base repo changes:
> http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/
>
> Many thanks
> Kevin
>



From erik.joelsson at oracle.com  Fri Apr 20 22:28:13 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 20 Apr 2018 15:28:13 -0700
Subject: RFR: 8201259: Fix warning with VS2017 in jdk.pack
In-Reply-To: <5ADA5963.6030903@oracle.com>
References: <5ADA5963.6030903@oracle.com>
Message-ID: <ffa077e7-dcec-12f7-643f-de4c9c63a8fc@oracle.com>

Looks good to me.

/Erik


On 2018-04-20 14:19, Kumar Srinivasan wrote:
> Hello,
>
> Please review fix [1] for VS2017 to compile pack200 native header
> file,? without warnings.
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8201259/



From gnu.andrew at redhat.com  Sat Apr 21 14:50:31 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 21 Apr 2018 15:50:31 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com>
Message-ID: <CABi63P5EqTZ5dRsgzE32nbKTHE37ocDrM02oLqyH-KSFuB6fHA@mail.gmail.com>

On 16 March 2018 at 11:05, David Holmes <david.holmes at oracle.com> wrote:
> Hi Michal,
>
> On 16/03/2018 8:48 PM, Michal Vala wrote:
>>
>> Hi,
>>
>> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile
>> error due to pragma used in function:
>
>
> That's a very old gcc. Our "official" version is 4.9.2 but we're working on
> getting gcc 7.x working as well. This code causes no problem on 4.9.2+ so to
> make any change we'd have to know it will continue to work on later
> versions.
>
> Also a google search indicates the "pragma diagnostic push" and pop weren't
> added until gcc 4.6 ??
>
> David
> -----
>

That's why PRAGMA_DIAG_PUSH/POP were defined by:

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

The mistake was in:

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

using the pragma directly, rather than via the define as elsewhere
in the codebase.

$ grep -r 'PRAGMA_DIAG_PUSH' jdk/src/hotspot/
jdk/src/hotspot/share/code/compressedStream.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/code/codeCache.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#define
PRAGMA_DIAG_PUSH             _Pragma("GCC diagnostic push")
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#ifndef PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#define PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/xmlstream.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/classfile/classFileError.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/classfile/classFileParser.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/jvmci/jvmciRuntime.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/jvmci/jvmciRuntime.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/os/linux/osContainer_linux.cpp:PRAGMA_DIAG_PUSH

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From gnu.andrew at redhat.com  Sat Apr 21 15:18:48 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 21 Apr 2018 16:18:48 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
Message-ID: <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>

On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Mar 16, 2018, at 6:48 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile error due to pragma used in function:
>>
>> /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: error: #pragma GCC diagnostic not allowed inside functions
>>
>>
>> I'm sending little patch that fixes the issue by wrapping whole function. I've also created a macro for ignoring deprecated declaration inside compilerWarnings.hpp to line up with others.
>>
>> Can someone please review? If it's ok, I would also need a sponsor.
>>
>>
>> diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp
>> --- a/src/hotspot/os/linux/os_linux.inline.hpp        Thu Mar 15 14:54:10 2018 -0700
>> +++ b/src/hotspot/os/linux/os_linux.inline.hpp        Fri Mar 16 10:50:24 2018 +0100
>> @@ -96,13 +96,12 @@
>>   return ::ftruncate64(fd, length);
>> }
>>
>> -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> -{
>> // readdir_r has been deprecated since glibc 2.24.
>> // See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>> -
>> +PRAGMA_DIAG_PUSH
>> +PRAGMA_DEPRECATED_IGNORED
>> +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> +{
>>   dirent* p;
>>   int status;
>>   assert(dirp != NULL, "just checking");
>> @@ -114,11 +113,11 @@
>>   if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
>>     errno = status;
>>     return NULL;
>> -  } else
>> +  } else {
>>     return p;
>> -
>> -#pragma GCC diagnostic pop
>> +  }
>> }
>> +PRAGMA_DIAG_POP
>>
>> inline int os::closedir(DIR *dirp) {
>>   assert(dirp != NULL, "argument is NULL");
>> diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp
>> --- a/src/hotspot/share/utilities/compilerWarnings.hpp        Thu Mar 15 14:54:10 2018 -0700
>> +++ b/src/hotspot/share/utilities/compilerWarnings.hpp        Fri Mar 16 10:50:24 2018 +0100
>> @@ -48,6 +48,7 @@
>> #define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat-nonliteral\"") \
>>                                          _Pragma("GCC diagnostic ignored \"-Wformat-security\"")
>> #define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat\"")
>> +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
>>
>> #if defined(__clang_major__) && \
>>       (__clang_major__ >= 4 || \
>>
>>
>> Thanks!
>>
>> --
>> Michal Vala
>> OpenJDK QE
>> Red Hat Czech
>
> Given that there seem to be no callers of os::readdir that share the
> DIR* among multiple threads, it would seem easier to just replace the
> use of ::readdir_r with ::readdir.  That seems to be the intent in the
> deprecation decision; use ::readdir, and either don't share a DIR*
> among threads, or use external locking when doing so.
>

That was my analysis when I looked at this as well. Something as simple as:

diff --git a/src/os/linux/vm/os_linux.inline.hpp
b/src/os/linux/vm/os_linux.inline.hpp
--- a/src/os/linux/vm/os_linux.inline.hpp
+++ b/src/os/linux/vm/os_linux.inline.hpp
@@ -116,19 +116,9 @@

 inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
 {
-  dirent* p;
-  int status;
   assert(dirp != NULL, "just checking");

-  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
-  // version. Here is the doc for this function:
-  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
-  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
-    errno = status;
-    return NULL;
-  } else
-    return p;
+  return ::readdir(dirp);
 }

 inline int os::closedir(DIR *dirp) {

has been working fine for me locally for a while. I believe Michal is going to
post an updated version of that, along with some cleanup of dbuf usage
in Linux-only code (as dbuf is now unused).

However, I wouldn't suggest backporting such a change to older JDKs.
There, we should backport the changeset to mute it, updating it to
work with older compilers. I already did so in OpenJDK 7.

> There are also problems with the patch as provided.
>
> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
> change is being made in support of, the warning would be disabled for
> all following code in any translation unit that includes this file.
> That doesn't seem good.

No, but it's really the only solution on those compilers. We have such
usage already elsewhere e.g.

// Silence -Wformat-security warning for fatal()
PRAGMA_DIAG_PUSH
PRAGMA_FORMAT_NONLITERAL_IGNORED
  fatal(buf);
PRAGMA_DIAG_POP
  return true; // silence compiler warnings
}
in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp

If there are other warnings, then they will picked up on newer compilers,
especially when building with -Werror. I don't think it's likely people are
doing development on older compilers, but rather that we have to use
them to build for older platforms.

This isn't the first time I've encountered something which built fine locally,
and then failed when building on an old version of RHEL, and I suspect
it won't be the last.

>
> (2) The default empty definition for PRAGMA_DEPRECATED_IGNORED is
> missing.  That means the macro can't be used in shared code, in which
> case having defined in (shared) compilerWarnings.hpp is questionable.
>

Yes, I don't see the need to change that line (other than for consistency)
and didn't when I made the same change in 7:
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2a2721def4a0#l7.2

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From mvala at redhat.com  Mon Apr 23 07:51:53 2018
From: mvala at redhat.com (Michal Vala)
Date: Mon, 23 Apr 2018 09:51:53 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
Message-ID: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>

Hi,

following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting 
updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 
[2].

webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/

I'm asking for the review and eventually sponsorship.

Thanks!

[1] - http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021236.html
[2] - https://bugs.openjdk.java.net/browse/JDK-8179887
-- 
Michal Vala
OpenJDK QE
Red Hat Czech


From david.holmes at oracle.com  Mon Apr 23 08:41:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Apr 2018 18:41:10 +1000
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
Message-ID: <116a3b63-1b86-6b0e-16bf-376b1d1e8ea5@oracle.com>

Hi Michal,

This was discussed in a couple of different threads. Please also see:

http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021530.html

Thanks,
David

On 23/04/2018 5:51 PM, Michal Vala wrote:
> Hi,
> 
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm 
> posting updated patch replacing deprecated readdir_r with readdir. Bug 
> ID is JDK-8179887 [2].
> 
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
> 
> I'm asking for the review and eventually sponsorship.
> 
> Thanks!
> 
> [1] - 
> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021236.html
> [2] - https://bugs.openjdk.java.net/browse/JDK-8179887


From matthias.baesken at sap.com  Mon Apr 23 12:01:14 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 23 Apr 2018 12:01:14 +0000
Subject: INCLUDE_SA/serviceability agent - support  on s390x
Message-ID: <6e27de41f1eb40ee93b1a44a5d69d775@sap.com>

Hello,   as far as I know  the serviceability agent   is not  supported on  linux s390x .
However  (unlike  on aix where it is not supported as well) ,   INCLUDE_SA=false    is not set  in the central configure  m4 files .
Should we set it  ( suggested diff below)  ?

Best regards, Matthias


hg diff
diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
--- a/make/autoconf/jdk-options.m4      Wed Apr 18 11:19:32 2018 +0200
+++ b/make/autoconf/jdk-options.m4      Mon Apr 23 13:46:17 2018 +0200
@@ -238,6 +238,9 @@
   if test "x$OPENJDK_TARGET_OS" = xaix ; then
     INCLUDE_SA=false
   fi
+  if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
+    INCLUDE_SA=false
+  fi
   AC_SUBST(INCLUDE_SA)
   # Compress jars



Best regards, Matthias


From erik.joelsson at oracle.com  Mon Apr 23 15:43:08 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Apr 2018 08:43:08 -0700
Subject: INCLUDE_SA/serviceability agent - support on s390x
In-Reply-To: <6e27de41f1eb40ee93b1a44a5d69d775@sap.com>
References: <6e27de41f1eb40ee93b1a44a5d69d775@sap.com>
Message-ID: <77a91681-c2a2-ca0d-9585-cd9ef145ac06@oracle.com>

Makes sense to me. Looks good.

/Erik


On 2018-04-23 05:01, Baesken, Matthias wrote:
>
> Hello,?? as far as I know? the serviceability agent?? is not? 
> supported on? linux s390x .
>
> However? (unlike? on aix where it is not supported as well) ,? 
> ?INCLUDE_SA=false is not set? in the central configure? m4 files .
>
> Should we set it? ( suggested diff below)? ?
>
> Best regards, Matthias
>
> hg diff
>
> diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
>
> --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
>
> +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
>
> @@ -238,6 +238,9 @@
>
> ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
>
> ???? INCLUDE_SA=false
>
> ?? fi
>
> +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
>
> +??? INCLUDE_SA=false
>
> +? fi
>
> ?? AC_SUBST(INCLUDE_SA)
>
> # Compress jars
>
> Best regards, Matthias
>



From kim.barrett at oracle.com  Mon Apr 23 19:19:44 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 15:19:44 -0400
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
 <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
Message-ID: <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>

> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>> There are also problems with the patch as provided.
>> 
>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>> change is being made in support of, the warning would be disabled for
>> all following code in any translation unit that includes this file.
>> That doesn't seem good.
> 
> No, but it's really the only solution on those compilers. We have such
> usage already elsewhere e.g.
> 
> // Silence -Wformat-security warning for fatal()
> PRAGMA_DIAG_PUSH
> PRAGMA_FORMAT_NONLITERAL_IGNORED
>  fatal(buf);
> PRAGMA_DIAG_POP
>  return true; // silence compiler warnings
> }
> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
> 
> If there are other warnings, then they will picked up on newer compilers,
> especially when building with -Werror. I don't think it's likely people are
> doing development on older compilers, but rather that we have to use
> them to build for older platforms.

I would be a lot more comfortable if the possibly do-nothing push/pop and
the associated code were in a .cpp file, rather than in a .hpp file where it
could affect some open-ended and unexpected set of code.

But I think this is moot if os::readdir can be changed to call ::readdir rather
than ::readdir_r, as appears to be the case, possibly with some documentation
about not sharing the DIR* among multiple threads, at least not without locking.

That seemed to be what Michal was planning to do, but hasn?t gotten back to
it yet.



From gnu.andrew at redhat.com  Tue Apr 24 03:27:16 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 24 Apr 2018 04:27:16 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
 <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
 <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
Message-ID: <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>

On 23 April 2018 at 20:19, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>
>> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> There are also problems with the patch as provided.
>>>
>>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>>> change is being made in support of, the warning would be disabled for
>>> all following code in any translation unit that includes this file.
>>> That doesn't seem good.
>>
>> No, but it's really the only solution on those compilers. We have such
>> usage already elsewhere e.g.
>>
>> // Silence -Wformat-security warning for fatal()
>> PRAGMA_DIAG_PUSH
>> PRAGMA_FORMAT_NONLITERAL_IGNORED
>>  fatal(buf);
>> PRAGMA_DIAG_POP
>>  return true; // silence compiler warnings
>> }
>> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>>
>> If there are other warnings, then they will picked up on newer compilers,
>> especially when building with -Werror. I don't think it's likely people are
>> doing development on older compilers, but rather that we have to use
>> them to build for older platforms.
>
> I would be a lot more comfortable if the possibly do-nothing push/pop and
> the associated code were in a .cpp file, rather than in a .hpp file where it
> could affect some open-ended and unexpected set of code.
>

Ah yes, sorry, I missed that this was a .hpp, while the others were .cpp.

> But I think this is moot if os::readdir can be changed to call ::readdir rather
> than ::readdir_r, as appears to be the case, possibly with some documentation
> about not sharing the DIR* among multiple threads, at least not without locking.
>

I think so too for OpenJDK 11, but I'm reluctant to backport such a change
to older JDKs.
I guess if we want to continue to workaround the warning there, we'll need
to move the function into the .cpp file.

> That seemed to be what Michal was planning to do, but hasn?t gotten back to
> it yet.

Indeed. He has a patch that does that, that I've already reviewed. Just waiting
for him to post it publicly :)

>



-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From david.holmes at oracle.com  Tue Apr 24 04:11:57 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Apr 2018 14:11:57 +1000
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
 <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
 <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
 <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
Message-ID: <629b25e0-fbdf-7093-1d22-e10d87e0324d@oracle.com>



On 24/04/2018 1:27 PM, Andrew Hughes wrote:
> On 23 April 2018 at 20:19, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>
>>> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> There are also problems with the patch as provided.
>>>>
>>>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>>>> change is being made in support of, the warning would be disabled for
>>>> all following code in any translation unit that includes this file.
>>>> That doesn't seem good.
>>>
>>> No, but it's really the only solution on those compilers. We have such
>>> usage already elsewhere e.g.
>>>
>>> // Silence -Wformat-security warning for fatal()
>>> PRAGMA_DIAG_PUSH
>>> PRAGMA_FORMAT_NONLITERAL_IGNORED
>>>   fatal(buf);
>>> PRAGMA_DIAG_POP
>>>   return true; // silence compiler warnings
>>> }
>>> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>>>
>>> If there are other warnings, then they will picked up on newer compilers,
>>> especially when building with -Werror. I don't think it's likely people are
>>> doing development on older compilers, but rather that we have to use
>>> them to build for older platforms.
>>
>> I would be a lot more comfortable if the possibly do-nothing push/pop and
>> the associated code were in a .cpp file, rather than in a .hpp file where it
>> could affect some open-ended and unexpected set of code.
>>
> 
> Ah yes, sorry, I missed that this was a .hpp, while the others were .cpp.
> 
>> But I think this is moot if os::readdir can be changed to call ::readdir rather
>> than ::readdir_r, as appears to be the case, possibly with some documentation
>> about not sharing the DIR* among multiple threads, at least not without locking.
>>
> 
> I think so too for OpenJDK 11, but I'm reluctant to backport such a change
> to older JDKs.
> I guess if we want to continue to workaround the warning there, we'll need
> to move the function into the .cpp file.
> 
>> That seemed to be what Michal was planning to do, but hasn?t gotten back to
>> it yet.
> 
> Indeed. He has a patch that does that, that I've already reviewed. Just waiting
> for him to post it publicly :)

He already has:

RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int 
readdir_r(DIR*, dirent*, dirent**)' is deprecated

on both the mailing lists this email has gone to.

David
-----

>>
> 
> 
> 


From archana.nogriya at uk.ibm.com  Tue Apr 24 09:44:57 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Tue, 24 Apr 2018 10:44:57 +0100
Subject: Contribution to make/Docs.gmk
In-Reply-To: <963d41da-904f-1119-cc6c-a2937e66a87e@oracle.com>
References: <OF70F93106.BE1032AA-ON0025824A.004E19D2-8025824A.0051A38C@notes.na.collabserv.com>
 <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com>
 <OF0291D502.2C215E3C-ON0025824B.0046A32D-8025824B.00477120@notes.na.collabserv.com>
 <963d41da-904f-1119-cc6c-a2937e66a87e@oracle.com>
Message-ID: <OF953C9EF3.728F679C-ON00258278.00562C3D-80258279.00359273@notes.na.collabserv.com>

Hi, 

"make/Docs.gmk", JDK_MODULES is only sorted with DOCS_MODULES, where It 
should also filter-out MODULES_FILTER for javadocs modules.

# All modules to have docs generated by docs-jdk-api target
>> -JDK_MODULES := $(sort $(DOCS_MODULES))
>> +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), 
$(DOCS_MODULES)))
 

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From mvala at redhat.com  Tue Apr 24 10:43:04 2018
From: mvala at redhat.com (Michal Vala)
Date: Tue, 24 Apr 2018 12:43:04 +0200
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <629b25e0-fbdf-7093-1d22-e10d87e0324d@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
 <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
 <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
 <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
 <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
 <629b25e0-fbdf-7093-1d22-e10d87e0324d@oracle.com>
Message-ID: <404ee925-cf0d-303f-518b-6f9e4e0215ec@redhat.com>



On 04/24/2018 06:11 AM, David Holmes wrote:
> 
> 
> On 24/04/2018 1:27 PM, Andrew Hughes wrote:
>> On 23 April 2018 at 20:19, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>>
>>>> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>> There are also problems with the patch as provided.
>>>>>
>>>>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>>>>> change is being made in support of, the warning would be disabled for
>>>>> all following code in any translation unit that includes this file.
>>>>> That doesn't seem good.
>>>>
>>>> No, but it's really the only solution on those compilers. We have such
>>>> usage already elsewhere e.g.
>>>>
>>>> // Silence -Wformat-security warning for fatal()
>>>> PRAGMA_DIAG_PUSH
>>>> PRAGMA_FORMAT_NONLITERAL_IGNORED
>>>> ? fatal(buf);
>>>> PRAGMA_DIAG_POP
>>>> ? return true; // silence compiler warnings
>>>> }
>>>> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>>>>
>>>> If there are other warnings, then they will picked up on newer compilers,
>>>> especially when building with -Werror. I don't think it's likely people are
>>>> doing development on older compilers, but rather that we have to use
>>>> them to build for older platforms.
>>>
>>> I would be a lot more comfortable if the possibly do-nothing push/pop and
>>> the associated code were in a .cpp file, rather than in a .hpp file where it
>>> could affect some open-ended and unexpected set of code.
>>>
>>
>> Ah yes, sorry, I missed that this was a .hpp, while the others were .cpp.
>>
>>> But I think this is moot if os::readdir can be changed to call ::readdir rather
>>> than ::readdir_r, as appears to be the case, possibly with some documentation
>>> about not sharing the DIR* among multiple threads, at least not without locking.
>>>
>>
>> I think so too for OpenJDK 11, but I'm reluctant to backport such a change
>> to older JDKs.
>> I guess if we want to continue to workaround the warning there, we'll need
>> to move the function into the .cpp file.
>>
>>> That seemed to be what Michal was planning to do, but hasn?t gotten back to
>>> it yet.
>>
>> Indeed. He has a patch that does that, that I've already reviewed. Just waiting
>> for him to post it publicly :)
> 
> He already has:
> 
> RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, 
> dirent*, dirent**)' is deprecated
> 
> on both the mailing lists this email has gone to.

yes, here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html

> 
> David
> -----
> 
>>>
>>
>>
>>

-- 
Michal Vala
OpenJDK QE
Red Hat Czech


From thomas.stuefe at gmail.com  Tue Apr 24 12:50:59 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 24 Apr 2018 14:50:59 +0200
Subject: strange configure error on Linux Mint 18.3
Message-ID: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>

Hi all,

I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
have not yet installed anything on that box (the only thing I
installed is autoconf).

This fails at a point where normally I would get suggestions about
which tools to install with apt-get (which, btw, is really nice).
config.log contains this:

-------

Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.5'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
configure:35364: $? = 0
configure:35353: /usr/bin/gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:35364: $? = 1
configure:35353: /usr/bin/gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:35364: $? = 1
configure:35384: checking whether the C compiler works
configure:35406: /usr/bin/gcc -m64    -m64   conftest.c  >&5
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
configure:35410: $? = 1
configure:35448: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:35453: error: in `/shared/projects/openjdk/jdk-jdk/output-fastdebug':
configure:35455: error: C compiler cannot create executables

-----------------

Weirdly enough the compiler is ran once with -qversion, which is an
AIX-only option, and once with -V, which is not valid either.

Has anyone seen this already? (Note that I used Mint18.3 as
development machine before and it just worked).

Thanks, Thomas


From glaubitz at physik.fu-berlin.de  Tue Apr 24 13:01:58 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 15:01:58 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
Message-ID: <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>

Hi Thomas!

On 04/24/2018 02:50 PM, Thomas St?fe wrote:
> I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
> have not yet installed anything on that box (the only thing I
> installed is autoconf).

Have you tried "apt build-dep openjdk-9"? This should install all the
necessary build dependencies.

> This fails at a point where normally I would get suggestions about
> which tools to install with apt-get (which, btw, is really nice).
> config.log contains this:
> (...)
> /usr/bin/ld: cannot find crt1.o: No such file or directory
> /usr/bin/ld: cannot find crti.o: No such file or directory
> /usr/bin/ld: cannot find -lc
> /usr/bin/ld: cannot find crtn.o: No such file or directory

You're missing the Debian package libc6-dev:

root at z6:~> dpkg -L libc6-dev |grep crt
/usr/lib/x86_64-linux-gnu/Mcrt1.o
/usr/lib/x86_64-linux-gnu/Scrt1.o
/usr/lib/x86_64-linux-gnu/crt1.o
/usr/lib/x86_64-linux-gnu/crti.o
/usr/lib/x86_64-linux-gnu/crtn.o
/usr/lib/x86_64-linux-gnu/gcrt1.o
/usr/lib/x86_64-linux-gnu/grcrt1.o
/usr/lib/x86_64-linux-gnu/rcrt1.o
root at z6:~>

> Weirdly enough the compiler is ran once with -qversion, which is an
> AIX-only option, and once with -V, which is not valid either.

This is perfectly normal and the way autoconf works. It tries various
compiler options and runs various tests, including test compiles,
and checks the result. autoconf cannot know in advance what toolchain
and which operating system you are using, so it has to perform these
tests. The error messages are normally just redirected to /dev/null
and only show in config.log.

> Has anyone seen this already? (Note that I used Mint18.3 as
> development machine before and it just worked).

Yes, it's perfectly normal when you try to configure OpenJDK without
any of its build dependencies installed :).

PS: If you are using a real Debian instead of Linux Mint, you get a
     free Multi-Arch environment for free and can easily cross-build
     OpenJDK for all the architectures found in Debian. Let me know
     if you want me to write up a small HowTo.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From thomas.stuefe at gmail.com  Tue Apr 24 13:25:24 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 24 Apr 2018 15:25:24 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>
Message-ID: <CAA-vtUxTz2JNm=5cQseiTB1rX=7cWaejDwyQCq1fJg_aVPodXg@mail.gmail.com>

Hi Adrian,

On Tue, Apr 24, 2018 at 3:01 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> Hi Thomas!
>
> On 04/24/2018 02:50 PM, Thomas St?fe wrote:
>>
>> I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
>> have not yet installed anything on that box (the only thing I
>> installed is autoconf).
>
>
> Have you tried "apt build-dep openjdk-9"? This should install all the
> necessary build dependencies.

This is cool! I did not know that.

Unfortunately it seems not to work on my box:

thomas at mint18 /shared/projects/openjdk/jdk-jdk/source $ sudo apt-get
build-dep openjdk-9
Reading package lists... Done
E: You must put some 'source' URIs in your sources.list

>
>> This fails at a point where normally I would get suggestions about
>> which tools to install with apt-get (which, btw, is really nice).
>> config.log contains this:
>> (...)
>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>> /usr/bin/ld: cannot find crti.o: No such file or directory
>> /usr/bin/ld: cannot find -lc
>> /usr/bin/ld: cannot find crtn.o: No such file or directory
>
>
> You're missing the Debian package libc6-dev:
>
> root at z6:~> dpkg -L libc6-dev |grep crt
> /usr/lib/x86_64-linux-gnu/Mcrt1.o
> /usr/lib/x86_64-linux-gnu/Scrt1.o
> /usr/lib/x86_64-linux-gnu/crt1.o
> /usr/lib/x86_64-linux-gnu/crti.o
> /usr/lib/x86_64-linux-gnu/crtn.o
> /usr/lib/x86_64-linux-gnu/gcrt1.o
> /usr/lib/x86_64-linux-gnu/grcrt1.o
> /usr/lib/x86_64-linux-gnu/rcrt1.o
> root at z6:~>
>
>> Weirdly enough the compiler is ran once with -qversion, which is an
>> AIX-only option, and once with -V, which is not valid either.
>
>
> This is perfectly normal and the way autoconf works. It tries various
> compiler options and runs various tests, including test compiles,
> and checks the result. autoconf cannot know in advance what toolchain
> and which operating system you are using, so it has to perform these
> tests. The error messages are normally just redirected to /dev/null
> and only show in config.log.

Ah, thanks for the explanation!

>
>> Has anyone seen this already? (Note that I used Mint18.3 as
>> development machine before and it just worked).
>
>
> Yes, it's perfectly normal when you try to configure OpenJDK without
> any of its build dependencies installed :).
>

:) Sure. As I wrote, I think the bug would be that configure does not
display nice "you should run apt-get xxxxx" messages like it used to.

> PS: If you are using a real Debian instead of Linux Mint, you get a
>     free Multi-Arch environment for free and can easily cross-build
>     OpenJDK for all the architectures found in Debian. Let me know
>     if you want me to write up a small HowTo.
>

Such a braindump from you would be surely welcome.

..Thomas

> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From glaubitz at physik.fu-berlin.de  Tue Apr 24 13:51:42 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 15:51:42 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <CAA-vtUxTz2JNm=5cQseiTB1rX=7cWaejDwyQCq1fJg_aVPodXg@mail.gmail.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>
 <CAA-vtUxTz2JNm=5cQseiTB1rX=7cWaejDwyQCq1fJg_aVPodXg@mail.gmail.com>
Message-ID: <520f3178-675f-9182-5e67-dbb04714c58e@physik.fu-berlin.de>

On 04/24/2018 03:25 PM, Thomas St?fe wrote:
>> Have you tried "apt build-dep openjdk-9"? This should install all the
>> necessary build dependencies.
> 
> This is cool! I did not know that.
> 
> Unfortunately it seems not to work on my box:
> 
> thomas at mint18 /shared/projects/openjdk/jdk-jdk/source $ sudo apt-get
> build-dep openjdk-9
> Reading package lists... Done
> E: You must put some 'source' URIs in your sources.list

You need to add the corresponding "deb-src" entries for the "deb"
entries in your /etc/apt/sources.list.

On my Debian box, it looks like this:

deb http://ftp.de.debian.org/debian unstable main contrib non-free
deb-src http://ftp.de.debian.org/debian unstable main contrib non-free

For Linux Mint, you need to use the corresponding line from the
Linux Mint mirrors. After editing the sources.list, you need to
run "apt update".

> :) Sure. As I wrote, I think the bug would be that configure does not
> display nice "you should run apt-get xxxxx" messages like it used to.
> 
>> PS: If you are using a real Debian instead of Linux Mint, you get a
>>      free Multi-Arch environment for free and can easily cross-build
>>      OpenJDK for all the architectures found in Debian. Let me know
>>      if you want me to write up a small HowTo.
>>
> 
> Such a braindump from you would be surely welcome.

I just realized I already did that:

> https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK

Needs some updating though.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From jini.george at oracle.com  Tue Apr 24 06:57:52 2018
From: jini.george at oracle.com (Jini George)
Date: Tue, 24 Apr 2018 12:27:52 +0530
Subject: INCLUDE_SA/serviceability agent - support on s390x
In-Reply-To: <6e27de41f1eb40ee93b1a44a5d69d775@sap.com>
References: <6e27de41f1eb40ee93b1a44a5d69d775@sap.com>
Message-ID: <fcfff1bc-515f-1690-6971-2c35cee0d0b4@oracle.com>

Hi Matthias,

Your change looks good to me. It might make sense to also remove the 
following lines from:

src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h

  78 #if defined(s390x)
  79 #include <asm/ptrace.h>
  80 #endif

I am not sure if the following files are required either:
src/hotspot/cpu/s390/vmStructs_s390.hpp
src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp

Thanks,
Jini (Not a Reviewer).


On 4/23/2018 5:31 PM, Baesken, Matthias wrote:
> Hello,?? as far as I know? the serviceability agent?? is not? supported 
> on? linux s390x .
> 
> However? (unlike? on aix where it is not supported as well) ,  
>  ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
> 
> Should we set it? ( suggested diff below)? ?
> 
> Best regards, Matthias
> 
> hg diff
> 
> diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
> 
> --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
> 
> +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
> 
> @@ -238,6 +238,9 @@
> 
>  ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
> 
>  ???? INCLUDE_SA=false
> 
>  ?? fi
> 
> +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
> 
> +??? INCLUDE_SA=false
> 
> +? fi
> 
>  ?? AC_SUBST(INCLUDE_SA)
> 
> # Compress jars
> 
> Best regards, Matthias
> 


From matthias.baesken at sap.com  Tue Apr 24 16:09:29 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 24 Apr 2018 16:09:29 +0000
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default -was :
 RE: INCLUDE_SA/serviceability agent - support on s390x
Message-ID: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>

Hi Jini,   the removal  of  the mentioned headers leads to build errors  so we better keep it .
Error is when the headers are removed :

/nb/linuxs390x/nightly/jdk/src/hotspot/share/runtime/vmStructs.cpp:100:31: fatal error: vmStructs_s390.hpp: No such file or directory
 #include CPU_HEADER(vmStructs)


I  uploaded a webrev for review  :  


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

bug :

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



Best regards, Matthias


> -----Original Message-----
> From: Jini George [mailto:jini.george at oracle.com]
> Sent: Dienstag, 24. April 2018 08:58
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>
> Cc: serviceability-dev at openjdk.java.net; Schmidt, Lutz
> <lutz.schmidt at sap.com>
> Subject: Re: INCLUDE_SA/serviceability agent - support on s390x
> 
> Hi Matthias,
> 
> Your change looks good to me. It might make sense to also remove the
> following lines from:
> 
> src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h
> 
>   78 #if defined(s390x)
>   79 #include <asm/ptrace.h>
>   80 #endif
> 
> I am not sure if the following files are required either:
> src/hotspot/cpu/s390/vmStructs_s390.hpp
> src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp
> 
> Thanks,
> Jini (Not a Reviewer).
> 
> 
> On 4/23/2018 5:31 PM, Baesken, Matthias wrote:
> > Hello,?? as far as I know? the serviceability agent?? is not? supported
> > on? linux s390x .
> >
> > However? (unlike? on aix where it is not supported as well) ,
> >  ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
> >
> > Should we set it? ( suggested diff below)? ?
> >
> > Best regards, Matthias
> >
> > hg diff
> >
> > diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
> >
> > --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
> >
> > +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
> >
> > @@ -238,6 +238,9 @@
> >
> >  ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
> >
> >  ???? INCLUDE_SA=false
> >
> >  ?? fi
> >
> > +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
> >
> > +??? INCLUDE_SA=false
> >
> > +? fi
> >
> >  ?? AC_SUBST(INCLUDE_SA)
> >
> > # Compress jars
> >
> > Best regards, Matthias
> >


From thomas.stuefe at gmail.com  Tue Apr 24 16:24:01 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 24 Apr 2018 18:24:01 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <520f3178-675f-9182-5e67-dbb04714c58e@physik.fu-berlin.de>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>
 <CAA-vtUxTz2JNm=5cQseiTB1rX=7cWaejDwyQCq1fJg_aVPodXg@mail.gmail.com>
 <520f3178-675f-9182-5e67-dbb04714c58e@physik.fu-berlin.de>
Message-ID: <CAA-vtUwKT7HKdwPXA2mMMY+RjR0rgPyMRp62PiMdNSDR-qd6oQ@mail.gmail.com>

Thanks Adrian!

I installed the build prereqs and now I am fine.

Wiki is good, btw.

Best Regards, Thomas

On Tue, Apr 24, 2018 at 3:51 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> On 04/24/2018 03:25 PM, Thomas St?fe wrote:
>>>
>>> Have you tried "apt build-dep openjdk-9"? This should install all the
>>> necessary build dependencies.
>>
>>
>> This is cool! I did not know that.
>>
>> Unfortunately it seems not to work on my box:
>>
>> thomas at mint18 /shared/projects/openjdk/jdk-jdk/source $ sudo apt-get
>> build-dep openjdk-9
>> Reading package lists... Done
>> E: You must put some 'source' URIs in your sources.list
>
>
> You need to add the corresponding "deb-src" entries for the "deb"
> entries in your /etc/apt/sources.list.
>
> On my Debian box, it looks like this:
>
> deb http://ftp.de.debian.org/debian unstable main contrib non-free
> deb-src http://ftp.de.debian.org/debian unstable main contrib non-free
>
> For Linux Mint, you need to use the corresponding line from the
> Linux Mint mirrors. After editing the sources.list, you need to
> run "apt update".
>
>> :) Sure. As I wrote, I think the bug would be that configure does not
>> display nice "you should run apt-get xxxxx" messages like it used to.
>>
>>> PS: If you are using a real Debian instead of Linux Mint, you get a
>>>      free Multi-Arch environment for free and can easily cross-build
>>>      OpenJDK for all the architectures found in Debian. Let me know
>>>      if you want me to write up a small HowTo.
>>>
>>
>> Such a braindump from you would be surely welcome.
>
>
> I just realized I already did that:
>
>> https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK
>
>
> Needs some updating though.
>
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From jini.george at oracle.com  Tue Apr 24 17:03:03 2018
From: jini.george at oracle.com (Jini George)
Date: Tue, 24 Apr 2018 22:33:03 +0530
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default
 -was : RE: INCLUDE_SA/serviceability agent - support on s390x
In-Reply-To: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>
References: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>
Message-ID: <8f19239b-fc06-1712-a297-5148b0df6a67@oracle.com>

Looks good to me, Matthias.

Thank you,
Jini.

On 4/24/2018 9:39 PM, Baesken, Matthias wrote:
> Hi Jini,   the removal  of  the mentioned headers leads to build errors  so we better keep it .
> Error is when the headers are removed :
> 
> /nb/linuxs390x/nightly/jdk/src/hotspot/share/runtime/vmStructs.cpp:100:31: fatal error: vmStructs_s390.hpp: No such file or directory
>   #include CPU_HEADER(vmStructs)
> 
> 
> I  uploaded a webrev for review  :
> 
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8202200/
> 
> bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8202200
> 
> 
> 
> Best regards, Matthias
> 
> 
>> -----Original Message-----
>> From: Jini George [mailto:jini.george at oracle.com]
>> Sent: Dienstag, 24. April 2018 08:58
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> dev at openjdk.java.net' <build-dev at openjdk.java.net>
>> Cc: serviceability-dev at openjdk.java.net; Schmidt, Lutz
>> <lutz.schmidt at sap.com>
>> Subject: Re: INCLUDE_SA/serviceability agent - support on s390x
>>
>> Hi Matthias,
>>
>> Your change looks good to me. It might make sense to also remove the
>> following lines from:
>>
>> src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h
>>
>>    78 #if defined(s390x)
>>    79 #include <asm/ptrace.h>
>>    80 #endif
>>
>> I am not sure if the following files are required either:
>> src/hotspot/cpu/s390/vmStructs_s390.hpp
>> src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp
>>
>> Thanks,
>> Jini (Not a Reviewer).
>>
>>
>> On 4/23/2018 5:31 PM, Baesken, Matthias wrote:
>>> Hello,?? as far as I know? the serviceability agent?? is not? supported
>>> on? linux s390x .
>>>
>>> However? (unlike? on aix where it is not supported as well) ,
>>>   ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
>>>
>>> Should we set it? ( suggested diff below)? ?
>>>
>>> Best regards, Matthias
>>>
>>> hg diff
>>>
>>> diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
>>>
>>> --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
>>>
>>> +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
>>>
>>> @@ -238,6 +238,9 @@
>>>
>>>   ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
>>>
>>>   ???? INCLUDE_SA=false
>>>
>>>   ?? fi
>>>
>>> +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
>>>
>>> +??? INCLUDE_SA=false
>>>
>>> +? fi
>>>
>>>   ?? AC_SUBST(INCLUDE_SA)
>>>
>>> # Compress jars
>>>
>>> Best regards, Matthias
>>>


From glaubitz at physik.fu-berlin.de  Tue Apr 24 18:36:27 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 20:36:27 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <CAA-vtUwKT7HKdwPXA2mMMY+RjR0rgPyMRp62PiMdNSDR-qd6oQ@mail.gmail.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <d0b1e942-a8fb-abff-1dcc-15e20c739613@physik.fu-berlin.de>
 <CAA-vtUxTz2JNm=5cQseiTB1rX=7cWaejDwyQCq1fJg_aVPodXg@mail.gmail.com>
 <520f3178-675f-9182-5e67-dbb04714c58e@physik.fu-berlin.de>
 <CAA-vtUwKT7HKdwPXA2mMMY+RjR0rgPyMRp62PiMdNSDR-qd6oQ@mail.gmail.com>
Message-ID: <913e6b1f-c823-9ed2-9fae-eab4587ae2cd@physik.fu-berlin.de>

On 04/24/2018 06:24 PM, Thomas St?fe wrote:
> Thanks Adrian!
> 
> I installed the build prereqs and now I am fine.

Great. I'm glad I was able to help :).

> Wiki is good, btw.

I have written down instructions for bootstrapping various compilers
in Debian since that happens every time we are adding a new architecture:

> https://wiki.debian.org/PortsDocs/BootstrappingFPC
> https://wiki.debian.org/PortsDocs/BootstrappingGHC
> https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK
> https://wiki.debian.org/PortsDocs/BootstrappingRust

The instructions aren't necessary complete or up-to-date, but they
should give good pointers.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From kim.barrett at oracle.com  Tue Apr 24 19:17:55 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 24 Apr 2018 15:17:55 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
Message-ID: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>

> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
> 
> Hi,
> 
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
> 
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
> 
> I'm asking for the review and eventually sponsorship.

The change to os::readdir in os_linux.inline.hpp looks fine.

I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
of those is right, and that part of the change should not be made; see
https://bugs.openjdk.java.net/browse/JDK-8134540
Much nearly duplicated code for PerfMemory support

Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
the second argument to os::readdir.
windows: unused
bsd: freebsd also deprecated readdir_r, I think for similar reasons.
solaris: doc is clear about thread safety issue being about sharing the DIR*
aix: I haven?t looked at it, but would guess it?s similar.

In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
::readdir on non-Windows.  That would all be for another RFE though.




From jonathan.gibbons at oracle.com  Wed Apr 25 00:53:11 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 24 Apr 2018 17:53:11 -0700
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
 <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com>
Message-ID: <5ADFD177.7050600@oracle.com>



On 04/12/2018 10:20 PM, mandy chung wrote:
>
>
> On 4/13/18 4:15 AM, Jonathan Gibbons wrote:
>> Please review an initial implementation for the feature described in
>> JEP 330: Launch Single-File Source-Code Programs.
>>
>> The work is described in the JEP and CSR, and falls into various parts:
>>
>>  * The part to handle the new command-line options is in the native
>>    Java launcher code.
>>  * The part to invoke the compiler and subsequently execute the code
>>    found in the source file is in a new class in the jdk.compiler 
>> module.
>>  * There are some minor Makefile changes, to add support for a new
>>    resource file.
>>
>> There are no changes to javac itself.
>>
>> JEP: http://openjdk.java.net/jeps/330
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
>> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>
> This looks quite good to me.  One small comment on the source launcher 
> Main class:
>
>   122         } catch (InvocationTargetException e) {
>   123             // leave VM to handle the stacktrace, in the standard manner
>   124             throw e.getTargetException();
>   125         }
>   387         } catch (InvocationTargetException e) {
>   388             // remove stack frames for source launcher
>   389             int invocationFrames = e.getStackTrace().length;
>   390             Throwable target = e.getTargetException();
>   391             StackTraceElement[] targetTrace = target.getStackTrace();
>   392             target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames));
>   393             throw e;
>   394         }
>
> This could simply throw target instead of the InvocationTargetException
> and then the main method can propagate the target, if thrown.
>
> Mandy

Mandy,

Yes, but that would require the execute method and its callers to 
declare that they throw Throwable,
or at least Exception. Since the exception is already wrapped, it seems 
better to propagate the
wrapped exception, and to only unwrap it at the last moment.

-- Jon


From mandy.chung at oracle.com  Wed Apr 25 03:37:31 2018
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 25 Apr 2018 11:37:31 +0800
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ADFD177.7050600@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
 <87e3bc79-aa0c-3241-d8f5-8c77850f61db@oracle.com>
 <5ADFD177.7050600@oracle.com>
Message-ID: <5b920f09-11e3-1a95-56d6-7daf66db0a91@oracle.com>



On 4/25/18 8:53 AM, Jonathan Gibbons wrote:
>
>
> On 04/12/2018 10:20 PM, mandy chung wrote:
>
>>
>> This looks quite good to me.? One small comment on the source 
>> launcher Main class:
>>
>>   122         } catch (InvocationTargetException e) {
>>   123             // leave VM to handle the stacktrace, in the standard manner
>>   124             throw e.getTargetException();
>>   125         }
>>   387         } catch (InvocationTargetException e) {
>>   388             // remove stack frames for source launcher
>>   389             int invocationFrames = e.getStackTrace().length;
>>   390             Throwable target = e.getTargetException();
>>   391             StackTraceElement[] targetTrace = target.getStackTrace();
>>   392             target.setStackTrace(Arrays.copyOfRange(targetTrace, 0, targetTrace.length - invocationFrames));
>>   393             throw e;
>>   394         }
>>
>> This could simply throw target instead of the InvocationTargetException
>> and then the main method can propagate the target, if thrown.
>>
>> Mandy
>
> Mandy,
>
> Yes, but that would require the execute method and its callers to 
> declare that they throw Throwable,
> or at least Exception. Since the exception is already wrapped, it 
> seems better to propagate the
> wrapped exception, and to only unwrap it at the last moment.
>

Either way works for me.

Mandy



From david.holmes at oracle.com  Wed Apr 25 06:17:23 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Apr 2018 16:17:23 +1000
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
Message-ID: <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>

cc'ing build-dev for the makefile change

Hi Jiangli,

On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
> 
> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731

These issues are not publicly visible, can you change them to be so?

> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/

Overall this seems fine. Thanks for explaining the logic changes below - 
much appreciated!

One query: why was UseAppCDS not removed from the tests (or at least the 
tests you were modifying anyway) ? They will all need updating before 12 
when the flag is expired.

test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java

Test 2 reference to UseAppCDS seems unnecessary now.
Test 3 is not needed as you're not using any diagnostic flag now.
Test 4 seems unnecessary now.

test/hotspot/jtreg/runtime/appcds/TestCommon.java

makeCommandLineForAppCDS should just be removed (yes that will cause 
some churn in the other tests) - but this can be a follow up test cleanup.

test/hotspot/jtreg/runtime/appcds/UseAppCDS.java

This test no longer makes much sense to me. The only tests should be 
that app classes get archived and used. It makes no sense to claim to be 
testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it 
is obsolete you don't need to test that -XX:-UseAppCDS has no affect.

Thanks,
David


> Highlights of the changes:
> * UseAppCDS is obsolete in JDK 11
> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
> * SharedArchiveFile is a product flag for all configurations in JDK 11
> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
> 
> Thanks David Holmes for his guidance on CSR process.
> 
> Following are the details for the VM and test changes:
> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
> 
> - Removed some of the CDS/AppCDS specifics from general class loading code.
> 
> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>    - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>    - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
> 
> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
> 
> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
> 
> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
> 
> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
> 
>    - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
> 
>    - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
> 
>    - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
> 
>    - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
> 
>    - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
> 
> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
> 
> Thanks,
> Jiangli
> 


From matthias.baesken at sap.com  Wed Apr 25 08:14:34 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 25 Apr 2018 08:14:34 +0000
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default
 -was :  RE: INCLUDE_SA/serviceability agent - support on s390x
Message-ID: <05e5a91232bc4957886e765126f971da@sap.com>

Hi Erik, thanks !
Can I consider this as a review ?

In the meantime I created a webrev + bug :


webrev for review  :



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



bug :



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

Regards, Matthias


From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
Sent: Montag, 23. April 2018 17:43
To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>
Cc: serviceability-dev at openjdk.java.net; Schmidt, Lutz <lutz.schmidt at sap.com>
Subject: Re: INCLUDE_SA/serviceability agent - support on s390x


Makes sense to me. Looks good.

/Erik

On 2018-04-23 05:01, Baesken, Matthias wrote:
Hello,   as far as I know  the serviceability agent   is not  supported on  linux s390x .
However  (unlike  on aix where it is not supported as well) ,   INCLUDE_SA=false    is not set  in the central configure  m4 files .
Should we set it  ( suggested diff below)  ?

Best regards, Matthias


hg diff
diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
--- a/make/autoconf/jdk-options.m4      Wed Apr 18 11:19:32 2018 +0200
+++ b/make/autoconf/jdk-options.m4      Mon Apr 23 13:46:17 2018 +0200
@@ -238,6 +238,9 @@
   if test "x$OPENJDK_TARGET_OS" = xaix ; then
     INCLUDE_SA=false
   fi
+  if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
+    INCLUDE_SA=false
+  fi
   AC_SUBST(INCLUDE_SA)
   # Compress jars



Best regards, Matthias



From shade at redhat.com  Wed Apr 25 09:06:30 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 25 Apr 2018 11:06:30 +0200
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
Message-ID: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>

Hi,

I was doing the exercise of cross-compiling from x86_64 to most OpenJDK arches, and we have
discovered the bug with endianness. Right now, compiling big-endian s390x target on little-endian
x86_64 host produces the modules blob that cannot be read on real s390x.

It seems to be a simple overlook in image building, and we should pass target-cpu endianness to
jlink. During the build, jlink is called twice: first for the interim image build, then for the
final image build. In cross-compilation, it seems only the final image build should take target-cpu
endianness.

(Aside: what is our backporting policy for build system bugs? Would love to make the jdk10 backport
for this)

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

Fix:

diff -r 5d2da44780ac make/Images.gmk
--- a/make/Images.gmk	Wed Apr 25 10:38:07 2018 +0200
+++ b/make/Images.gmk	Wed Apr 25 10:55:04 2018 +0200
@@ -117,7 +117,7 @@

 JLINK_TOOL := $(JLINK) -J-Djlink.debug=true \
     --module-path $(IMAGES_OUTPUTDIR)/jmods \
-    --endian $(OPENJDK_BUILD_CPU_ENDIAN) \
+    --endian $(OPENJDK_TARGET_CPU_ENDIAN) \
     --release-info $(BASE_RELEASE_FILE) \
     --order-resources=$(call CommaList, $(JLINK_ORDER_RESOURCES)) \
     --dedup-legal-notices=error-if-not-same-content \

Testing: x86_64 build, s390x cross-compiled build

Thanks,
-Aleksey



From magnus.ihse.bursie at oracle.com  Wed Apr 25 09:14:51 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 25 Apr 2018 11:14:51 +0200
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
In-Reply-To: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
References: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
Message-ID: <208f6157-bcf1-ad6a-da42-afeaf65bde6d@oracle.com>

On 2018-04-25 11:06, Aleksey Shipilev wrote:
> Hi,
>
> I was doing the exercise of cross-compiling from x86_64 to most OpenJDK arches, and we have
> discovered the bug with endianness. Right now, compiling big-endian s390x target on little-endian
> x86_64 host produces the modules blob that cannot be read on real s390x.
>
> It seems to be a simple overlook in image building, and we should pass target-cpu endianness to
> jlink. During the build, jlink is called twice: first for the interim image build, then for the
> final image build. In cross-compilation, it seems only the final image build should take target-cpu
> endianness.
>
> (Aside: what is our backporting policy for build system bugs? Would love to make the jdk10 backport
> for this)
The rules are the same as for all backports. Build system is no different.

>
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8202210
>
> Fix:
>
> diff -r 5d2da44780ac make/Images.gmk
> --- a/make/Images.gmk	Wed Apr 25 10:38:07 2018 +0200
> +++ b/make/Images.gmk	Wed Apr 25 10:55:04 2018 +0200
> @@ -117,7 +117,7 @@
>
>   JLINK_TOOL := $(JLINK) -J-Djlink.debug=true \
>       --module-path $(IMAGES_OUTPUTDIR)/jmods \
> -    --endian $(OPENJDK_BUILD_CPU_ENDIAN) \
> +    --endian $(OPENJDK_TARGET_CPU_ENDIAN) \
>       --release-info $(BASE_RELEASE_FILE) \
>       --order-resources=$(call CommaList, $(JLINK_ORDER_RESOURCES)) \
>       --dedup-legal-notices=error-if-not-same-content \
>
> Testing: x86_64 build, s390x cross-compiled build
Looks good to me.

/Magnus
>
> Thanks,
> -Aleksey
>



From magnus.ihse.bursie at oracle.com  Wed Apr 25 09:15:22 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 25 Apr 2018 11:15:22 +0200
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default
 -was : RE: INCLUDE_SA/serviceability agent - support on s390x
In-Reply-To: <05e5a91232bc4957886e765126f971da@sap.com>
References: <05e5a91232bc4957886e765126f971da@sap.com>
Message-ID: <f581d809-4c58-f6f6-c8ab-8ddef9d1ed83@oracle.com>


On 2018-04-25 10:14, Baesken, Matthias wrote:
>
> Hi Erik, thanks !
>
> Can I consider this as a review ?
>
> In the meantime I created a webrev + bug :
>
> webrev for review? :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8202200/ 
> <http://cr.openjdk.java.net/%7Embaesken/webrevs/8202200/>
>
Looks good to me.

/Magnus
>
> bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8202200
>
> Regards, Matthias
>
> *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com]
> *Sent:* Montag, 23. April 2018 17:43
> *To:* Baesken, Matthias <matthias.baesken at sap.com>; 
> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>
> *Cc:* serviceability-dev at openjdk.java.net; Schmidt, Lutz 
> <lutz.schmidt at sap.com>
> *Subject:* Re: INCLUDE_SA/serviceability agent - support on s390x
>
> Makes sense to me. Looks good.
>
> /Erik
>
> On 2018-04-23 05:01, Baesken, Matthias wrote:
>
>     Hello,?? as far as I know? the serviceability agent?? is not?
>     supported on linux s390x .
>
>     However? (unlike? on aix where it is not supported as well) ,
>     ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
>
>     Should we set it? ( suggested diff below)? ?
>
>     Best regards, Matthias
>
>     hg diff
>
>     diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
>
>     --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
>
>     +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
>
>     @@ -238,6 +238,9 @@
>
>     ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
>
>     INCLUDE_SA=false
>
>     ?? fi
>
>     +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
>
>     + INCLUDE_SA=false
>
>     +? fi
>
>     AC_SUBST(INCLUDE_SA)
>
>     # Compress jars
>
>     Best regards, Matthias
>



From magnus.ihse.bursie at oracle.com  Wed Apr 25 09:17:36 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 25 Apr 2018 11:17:36 +0200
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
Message-ID: <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>



On 2018-04-25 08:17, David Holmes wrote:
> cc'ing build-dev for the makefile change
>
> Hi Jiangli,
>
> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>> Please review the following changes that streamline the support for 
>> application class data sharing by eliminating the requirement of 
>> using -XX:+UseAppCDS to enable the feature. The support for 
>> application class data sharing is now enabled transparently when 
>> application classes or platform classes present in the classlist or 
>> generated archive with -Xshare:dump/on/auto.
>>
>> ????RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>> ????Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>
> These issues are not publicly visible, can you change them to be so?
>
>> ????webrev: 
>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
Build changes look good.

/Magnus
>
> Overall this seems fine. Thanks for explaining the logic changes below 
> - much appreciated!
>
> One query: why was UseAppCDS not removed from the tests (or at least 
> the tests you were modifying anyway) ? They will all need updating 
> before 12 when the flag is expired.
>
> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>
> Test 2 reference to UseAppCDS seems unnecessary now.
> Test 3 is not needed as you're not using any diagnostic flag now.
> Test 4 seems unnecessary now.
>
> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>
> makeCommandLineForAppCDS should just be removed (yes that will cause 
> some churn in the other tests) - but this can be a follow up test 
> cleanup.
>
> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>
> This test no longer makes much sense to me. The only tests should be 
> that app classes get archived and used. It makes no sense to claim to 
> be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now 
> that it is obsolete you don't need to test that -XX:-UseAppCDS has no 
> affect.
>
> Thanks,
> David
>
>
>> Highlights of the changes:
>> * UseAppCDS is obsolete in JDK 11
>> * Remove the +UnlockCommercialFeatures requirement when using 
>> application class data sharing in OracleJDK binary
>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>> * DumpLoadedClassList produces a complete classlist including all 
>> loaded library and application classes
>>
>> Thanks David Holmes for his guidance on CSR process.
>>
>> Following are the details for the VM and test changes:
>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>
>> - Removed some of the CDS/AppCDS specifics from general class loading 
>> code.
>>
>> - Removed scattered checks for non-empty directory. Dump time 
>> non-empty directory check is done at one central place, 
>> FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading 
>> all classes on the classlist. The behavior is backwards compatible:
>> ?? - If no app/platform classes are loaded, dump time only reports 
>> error if non-empty directory exists in -Xbootclasspath/a path
>> ?? - If app/platform classes are loaded, dump time reports error for 
>> any non-empty directory exists in -Xbootclasspath/a path, class path, 
>> or module path
>>
>> - Removed unnecessary ?if (!DumpSharedSpaces)? from 
>> SharedClassUtil::initialize(). The code path is only executed when 
>> UseSharedSpaces is enabled.
>>
>> - Return immediately in 
>> SystemDictionaryShared::find_or_load_shared_class() if the archive 
>> header indicates there is no app or platform classes in the shared 
>> archive. This reduces overhead in class loading if the shared archive 
>> only contains system classes. It also provides backwards 
>> compatibility in cases where shared application classes should be 
>> disabled. For example, when the default system class loader is 
>> replaced by user provided loader, archived application classes are 
>> inactive (not loaded from archive) at runtime without affecting the 
>> use of archived system classes.
>>
>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from 
>> the default classlist in JDK image, which is generated using 
>> DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>
>> - Updated various cds/appcds tests to reflect the JVM changes. The 
>> use of -XX:+UseAppCDS in tests remains unchanged.
>>
>> ?? - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>
>> ?? - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile 
>> in tests
>>
>> ?? - Updated NonBootLoaderClasses.java: ensure app/platform classes 
>> on classlist are archived without -XX:+UseAppCDS
>>
>> ?? - Updated DirClasspathTest.java: reflect the change for non-empty 
>> directory handling
>>
>> ?? - Updated MismatchedUseAppCDS.java:? -XX:-UseAppCDS has no effect
>>
>> Tested with all cds and appcds tests locally with both fastdebug and 
>> release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and 
>> jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>
>> Thanks,
>> Jiangli
>>



From magnus.ihse.bursie at oracle.com  Wed Apr 25 09:23:53 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 25 Apr 2018 02:23:53 -0700 (PDT)
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
Message-ID: <32b3ce4a-b15e-7ed2-e633-6f4a7f2b4e2c@oracle.com>

On 2018-04-24 14:50, Thomas St?fe wrote:
> Hi all,

Hi Thomas,

What does the output from configure look like? The config.log file does 
not really help tell us how far into our configure script we've come.

As John pointed out, the problem here was (likely) that you were missing 
the needed C libraries. However, we should have a test for this in 
configure, and I'm surprised it didn't alert you to the problem.

/Magnus

>
> I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
> have not yet installed anything on that box (the only thing I
> installed is autoconf).
>
> This fails at a point where normally I would get suggestions about
> which tools to install with apt-get (which, btw, is really nice).
> config.log contains this:
>
> -------
>
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 5.4.0-6ubuntu1~16.04.5'
> --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-5 --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
> --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
> --with-arch-directory=amd64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
> configure:35364: $? = 0
> configure:35353: /usr/bin/gcc -V >&5
> gcc: error: unrecognized command line option '-V'
> gcc: fatal error: no input files
> compilation terminated.
> configure:35364: $? = 1
> configure:35353: /usr/bin/gcc -qversion >&5
> gcc: error: unrecognized command line option '-qversion'
> gcc: fatal error: no input files
> compilation terminated.
> configure:35364: $? = 1
> configure:35384: checking whether the C compiler works
> configure:35406: /usr/bin/gcc -m64    -m64   conftest.c  >&5
> /usr/bin/ld: cannot find crt1.o: No such file or directory
> /usr/bin/ld: cannot find crti.o: No such file or directory
> /usr/bin/ld: cannot find -lc
> /usr/bin/ld: cannot find crtn.o: No such file or directory
> collect2: error: ld returned 1 exit status
> configure:35410: $? = 1
> configure:35448: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "OpenJDK"
> | #define PACKAGE_TARNAME "openjdk"
> | #define PACKAGE_VERSION "jdk9"
> | #define PACKAGE_STRING "OpenJDK jdk9"
> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
> | #define PACKAGE_URL "http://openjdk.java.net"
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:35453: error: in `/shared/projects/openjdk/jdk-jdk/output-fastdebug':
> configure:35455: error: C compiler cannot create executables
>
> -----------------
>
> Weirdly enough the compiler is ran once with -qversion, which is an
> AIX-only option, and once with -V, which is not valid either.
>
> Has anyone seen this already? (Note that I used Mint18.3 as
> development machine before and it just worked).
>
> Thanks, Thomas



From shade at redhat.com  Wed Apr 25 09:29:48 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 25 Apr 2018 11:29:48 +0200
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
In-Reply-To: <208f6157-bcf1-ad6a-da42-afeaf65bde6d@oracle.com>
References: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
 <208f6157-bcf1-ad6a-da42-afeaf65bde6d@oracle.com>
Message-ID: <44306e82-d235-b503-d4b9-535e6910977c@redhat.com>

On 04/25/2018 11:14 AM, Magnus Ihse Bursie wrote:
>> diff -r 5d2da44780ac make/Images.gmk
>> --- a/make/Images.gmk??? Wed Apr 25 10:38:07 2018 +0200
>> +++ b/make/Images.gmk??? Wed Apr 25 10:55:04 2018 +0200
>> @@ -117,7 +117,7 @@
>>
>> ? JLINK_TOOL := $(JLINK) -J-Djlink.debug=true \
>> ????? --module-path $(IMAGES_OUTPUTDIR)/jmods \
>> -??? --endian $(OPENJDK_BUILD_CPU_ENDIAN) \
>> +??? --endian $(OPENJDK_TARGET_CPU_ENDIAN) \
>> ????? --release-info $(BASE_RELEASE_FILE) \
>> ????? --order-resources=$(call CommaList, $(JLINK_ORDER_RESOURCES)) \
>> ????? --dedup-legal-notices=error-if-not-same-content \
>>
>> Testing: x86_64 build, s390x cross-compiled build
> Looks good to me.

Thanks!

I guess one reviewer is enough for this kind of change?
No more testing needed?

-Aleksey



From thomas.stuefe at gmail.com  Wed Apr 25 10:07:35 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Apr 2018 12:07:35 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <32b3ce4a-b15e-7ed2-e633-6f4a7f2b4e2c@oracle.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <32b3ce4a-b15e-7ed2-e633-6f4a7f2b4e2c@oracle.com>
Message-ID: <CAA-vtUwfzdax5kR7iQqsrzEjc8oVPCjtXrrr78e4W=M15W2+EA@mail.gmail.com>

Hi Magnus,

Ok I reverted the VM to the point before installing the dependencies.

Here you go:Runnable configure script is not present
Generating runnable configure script at
/shared/projects/openjdk/jdk-jdk/output-fastdebug/configure-support/generated-configure.sh
Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.69]
configure: Configuration created at Wed Apr 25 12:06:11 CEST 2018.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /bin/gunzip
checking for pigz... no
checking for gzip... /bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /bin/mktemp
checking for mv... /bin/mv
checking for nawk... /usr/bin/nawk
checking for printf... /usr/bin/printf
checking for greadlink... no
checking for readlink... /bin/readlink
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... gawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for a sed that does not truncate output... /bin/sed
checking for cygpath... no
checking for df... /bin/df
checking for cpio... /bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking openjdk-build os-cpu... linux-x86_64
checking openjdk-target os-cpu... linux-x86_64
checking compilation type... native
checking for top-level directory... /shared/projects/openjdk/jdk-jdk/source
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking for sysroot...
checking for toolchain path...
checking for extra path...
checking where to store configuration... in current directory
configure: Current directory is
/shared/projects/openjdk/jdk-jdk/output-fastdebug.
configure: Since this is not the source root, configure will output
the configuration here
configure: (as opposed to creating a configuration in
<src_root>/build/<conf-name>).
configure: However, this directory is not empty. This is not allowed,
since it could
configure: seriously mess up just about everything.
configure: Try 'cd /shared/projects/openjdk/jdk-jdk/source' and
restart configure
configure: (or create a new empty directory and cd to it).
configure: error: Will not continue creating configuration in
/shared/projects/openjdk/jdk-jdk/output-fastdebug
configure exiting with result code 1

..Thomas



On Wed, Apr 25, 2018 at 11:23 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2018-04-24 14:50, Thomas St?fe wrote:
>>
>> Hi all,
>
>
> Hi Thomas,
>
> What does the output from configure look like? The config.log file does not
> really help tell us how far into our configure script we've come.
>
> As John pointed out, the problem here was (likely) that you were missing the
> needed C libraries. However, we should have a test for this in configure,
> and I'm surprised it didn't alert you to the problem.
>
> /Magnus
>
>
>>
>> I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
>> have not yet installed anything on that box (the only thing I
>> installed is autoconf).
>>
>> This fails at a point where normally I would get suggestions about
>> which tools to install with apt-get (which, btw, is really nice).
>> config.log contains this:
>>
>> -------
>>
>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
>> 5.4.0-6ubuntu1~16.04.5'
>> --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
>> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
>> --prefix=/usr --program-suffix=-5 --enable-shared
>> --enable-linker-build-id --libexecdir=/usr/lib
>> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
>> --enable-nls --with-sysroot=/ --enable-clocale=gnu
>> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
>> --disable-vtable-verify --enable-libmpx --enable-plugin
>> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>> --enable-gtk-cairo
>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
>> --enable-java-home
>> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
>> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
>> --with-arch-directory=amd64
>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
>> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
>> --with-multilib-list=m32,m64,mx32 --enable-multilib
>> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
>> Thread model: posix
>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>> configure:35364: $? = 0
>> configure:35353: /usr/bin/gcc -V >&5
>> gcc: error: unrecognized command line option '-V'
>> gcc: fatal error: no input files
>> compilation terminated.
>> configure:35364: $? = 1
>> configure:35353: /usr/bin/gcc -qversion >&5
>> gcc: error: unrecognized command line option '-qversion'
>> gcc: fatal error: no input files
>> compilation terminated.
>> configure:35364: $? = 1
>> configure:35384: checking whether the C compiler works
>> configure:35406: /usr/bin/gcc -m64    -m64   conftest.c  >&5
>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>> /usr/bin/ld: cannot find crti.o: No such file or directory
>> /usr/bin/ld: cannot find -lc
>> /usr/bin/ld: cannot find crtn.o: No such file or directory
>> collect2: error: ld returned 1 exit status
>> configure:35410: $? = 1
>> configure:35448: result: no
>> configure: failed program was:
>> | /* confdefs.h */
>> | #define PACKAGE_NAME "OpenJDK"
>> | #define PACKAGE_TARNAME "openjdk"
>> | #define PACKAGE_VERSION "jdk9"
>> | #define PACKAGE_STRING "OpenJDK jdk9"
>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>> | #define PACKAGE_URL "http://openjdk.java.net"
>> | /* end confdefs.h.  */
>> |
>> | int
>> | main ()
>> | {
>> |
>> |   ;
>> |   return 0;
>> | }
>> configure:35453: error: in
>> `/shared/projects/openjdk/jdk-jdk/output-fastdebug':
>> configure:35455: error: C compiler cannot create executables
>>
>> -----------------
>>
>> Weirdly enough the compiler is ran once with -qversion, which is an
>> AIX-only option, and once with -V, which is not valid either.
>>
>> Has anyone seen this already? (Note that I used Mint18.3 as
>> development machine before and it just worked).
>>
>> Thanks, Thomas
>
>


From Alan.Bateman at oracle.com  Wed Apr 25 10:08:14 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Apr 2018 11:08:14 +0100
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
In-Reply-To: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
References: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
Message-ID: <50267109-4bad-aed1-d672-937b81898b12@oracle.com>



On 25/04/2018 10:06, Aleksey Shipilev wrote:
> Hi,
>
> I was doing the exercise of cross-compiling from x86_64 to most OpenJDK arches, and we have
> discovered the bug with endianness. Right now, compiling big-endian s390x target on little-endian
> x86_64 host produces the modules blob that cannot be read on real s390x.
It should still work, just less efficiently.

In any case, specifying the endianness to jlink in your update to 
Images.gmk looks right.

-Alan



From thomas.stuefe at gmail.com  Wed Apr 25 10:10:19 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Apr 2018 12:10:19 +0200
Subject: strange configure error on Linux Mint 18.3
In-Reply-To: <CAA-vtUwfzdax5kR7iQqsrzEjc8oVPCjtXrrr78e4W=M15W2+EA@mail.gmail.com>
References: <CAA-vtUzcMeUd2cD6yDKRFhefFabxWhBX04QmzK6dNEPLAC0BpQ@mail.gmail.com>
 <32b3ce4a-b15e-7ed2-e633-6f4a7f2b4e2c@oracle.com>
 <CAA-vtUwfzdax5kR7iQqsrzEjc8oVPCjtXrrr78e4W=M15W2+EA@mail.gmail.com>
Message-ID: <CAA-vtUxUs-ZU2kZmgH_o=FwRhQJzunLBms5X5F-tkpVhV-uVLw@mail.gmail.com>

Sorry, that was wrong... here you go:

Runnable configure script is not present
Generating runnable configure script at
/shared/projects/openjdk/jdk-jdk/output-fastdebug/configure-support/generated-configure.sh
Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.69]
configure: Configuration created at Wed Apr 25 12:09:25 CEST 2018.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /bin/gunzip
checking for pigz... no
checking for gzip... /bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /bin/mktemp
checking for mv... /bin/mv
checking for nawk... /usr/bin/nawk
checking for printf... /usr/bin/printf
checking for greadlink... no
checking for readlink... /bin/readlink
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... gawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for a sed that does not truncate output... /bin/sed
checking for cygpath... no
checking for df... /bin/df
checking for cpio... /bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking openjdk-build os-cpu... linux-x86_64
checking openjdk-target os-cpu... linux-x86_64
checking compilation type... native
checking for top-level directory... /shared/projects/openjdk/jdk-jdk/source
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking for sysroot...
checking for toolchain path...
checking for extra path...
checking where to store configuration... in current directory
checking what configuration name to use...
/shared/projects/openjdk/jdk-jdk/output-fastdebug
checking for apt-get... apt-get
checking for gmake... no
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Using GNU make at /usr/bin/make (version: GNU Make 4.1)
checking if make --output-sync is supported... yes
checking for output-sync value... none
checking if find supports -delete... yes
checking what type of tar was found... gnu
checking that grep (/bin/grep) -Fx handles empty lines in the pattern
list correctly... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... /usr/bin/ldd
checking for greadelf... no
checking for readelf... /usr/bin/readelf
checking for dot... no
checking for hg... /usr/bin/hg
checking for stat... /usr/bin/stat
checking for time... /usr/bin/time
checking for flock... /usr/bin/flock
checking for dtrace... no
checking for gpatch... no
checking for patch... /usr/bin/patch
checking bash version... 4.3.48
checking if bash supports pipefail... yes
checking if bash supports errexit (-e)... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for default LOG value...
checking headless only... no
checking for graphviz dot... no, cannot generate full docs
checking for pandoc... no, cannot generate full docs
checking full docs... no, missing dependencies
checking for cacerts file... default
checking if packaged modules are kept... yes (default)
checking for version string... 11-internal+0-adhoc.thomas.source
configure: Found potential Boot JDK using configure arguments
checking for Boot JDK... /shared/projects/openjdk/jdks/openjdk9
checking Boot JDK version... openjdk version "9-internal" OpenJDK
Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk) OpenJDK
64-Bit Server VM (build 9-internal+0-adhoc.jenkins.openjdk, mixed
mode)
checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javadoc in Boot JDK... ok
checking for jar in Boot JDK... ok
checking for jarsigner in Boot JDK... ok
checking if Boot JDK is 32 or 64 bits... 64
checking for local Boot JDK Class Data Sharing (CDS)... yes, created
checking for Build JDK... yes, will use output dir
configure: Using default toolchain gcc (GNU Compiler Collection)
checking for gcc... /usr/bin/gcc
checking resolved symbolic links for CC... /usr/bin/gcc-5
configure: Using gcc C compiler version 5.4.0 [gcc (Ubuntu
5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609]
checking whether the C compiler works... no
configure: error: in `/shared/projects/openjdk/jdk-jdk/output-fastdebug':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure exiting with result code 77

On Wed, Apr 25, 2018 at 12:07 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi Magnus,
>
> Ok I reverted the VM to the point before installing the dependencies.
>
> Here you go:Runnable configure script is not present
> Generating runnable configure script at
> /shared/projects/openjdk/jdk-jdk/output-fastdebug/configure-support/generated-configure.sh
> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.69]
> configure: Configuration created at Wed Apr 25 12:06:11 CEST 2018.
> checking for basename... /usr/bin/basename
> checking for bash... /bin/bash
> checking for cat... /bin/cat
> checking for chmod... /bin/chmod
> checking for cmp... /usr/bin/cmp
> checking for comm... /usr/bin/comm
> checking for cp... /bin/cp
> checking for cut... /usr/bin/cut
> checking for date... /bin/date
> checking for gdiff... no
> checking for diff... /usr/bin/diff
> checking for dirname... /usr/bin/dirname
> checking for echo... /bin/echo
> checking for expr... /usr/bin/expr
> checking for file... /usr/bin/file
> checking for find... /usr/bin/find
> checking for head... /usr/bin/head
> checking for gunzip... /bin/gunzip
> checking for pigz... no
> checking for gzip... /bin/gzip
> checking for ln... /bin/ln
> checking for ls... /bin/ls
> checking for mkdir... /bin/mkdir
> checking for mktemp... /bin/mktemp
> checking for mv... /bin/mv
> checking for nawk... /usr/bin/nawk
> checking for printf... /usr/bin/printf
> checking for greadlink... no
> checking for readlink... /bin/readlink
> checking for rm... /bin/rm
> checking for rmdir... /bin/rmdir
> checking for sh... /bin/sh
> checking for sort... /usr/bin/sort
> checking for tail... /usr/bin/tail
> checking for gtar... no
> checking for tar... /bin/tar
> checking for tee... /usr/bin/tee
> checking for touch... /usr/bin/touch
> checking for tr... /usr/bin/tr
> checking for uname... /bin/uname
> checking for uniq... /usr/bin/uniq
> checking for wc... /usr/bin/wc
> checking for which... /usr/bin/which
> checking for xargs... /usr/bin/xargs
> checking for gawk... gawk
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for a sed that does not truncate output... /bin/sed
> checking for cygpath... no
> checking for df... /bin/df
> checking for cpio... /bin/cpio
> checking for nice... /usr/bin/nice
> checking for pandoc... no
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking openjdk-build os-cpu... linux-x86_64
> checking openjdk-target os-cpu... linux-x86_64
> checking compilation type... native
> checking for top-level directory... /shared/projects/openjdk/jdk-jdk/source
> checking if custom source is suppressed (openjdk-only)... no
> checking which variant of the JDK to build... normal
> checking which debug level to use... release
> checking which variants of the JVM to build... server
> checking for sysroot...
> checking for toolchain path...
> checking for extra path...
> checking where to store configuration... in current directory
> configure: Current directory is
> /shared/projects/openjdk/jdk-jdk/output-fastdebug.
> configure: Since this is not the source root, configure will output
> the configuration here
> configure: (as opposed to creating a configuration in
> <src_root>/build/<conf-name>).
> configure: However, this directory is not empty. This is not allowed,
> since it could
> configure: seriously mess up just about everything.
> configure: Try 'cd /shared/projects/openjdk/jdk-jdk/source' and
> restart configure
> configure: (or create a new empty directory and cd to it).
> configure: error: Will not continue creating configuration in
> /shared/projects/openjdk/jdk-jdk/output-fastdebug
> configure exiting with result code 1
>
> ..Thomas
>
>
>
> On Wed, Apr 25, 2018 at 11:23 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2018-04-24 14:50, Thomas St?fe wrote:
>>>
>>> Hi all,
>>
>>
>> Hi Thomas,
>>
>> What does the output from configure look like? The config.log file does not
>> really help tell us how far into our configure script we've come.
>>
>> As John pointed out, the problem here was (likely) that you were missing the
>> needed C libraries. However, we should have a test for this in configure,
>> and I'm surprised it didn't alert you to the problem.
>>
>> /Magnus
>>
>>
>>>
>>> I got a configure error on a fresh, virgin Linux Mint 18.3 install. I
>>> have not yet installed anything on that box (the only thing I
>>> installed is autoconf).
>>>
>>> This fails at a point where normally I would get suggestions about
>>> which tools to install with apt-get (which, btw, is really nice).
>>> config.log contains this:
>>>
>>> -------
>>>
>>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
>>> 5.4.0-6ubuntu1~16.04.5'
>>> --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
>>> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
>>> --prefix=/usr --program-suffix=-5 --enable-shared
>>> --enable-linker-build-id --libexecdir=/usr/lib
>>> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
>>> --enable-nls --with-sysroot=/ --enable-clocale=gnu
>>> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
>>> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
>>> --disable-vtable-verify --enable-libmpx --enable-plugin
>>> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
>>> --enable-gtk-cairo
>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
>>> --enable-java-home
>>> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
>>> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
>>> --with-arch-directory=amd64
>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
>>> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
>>> --with-multilib-list=m32,m64,mx32 --enable-multilib
>>> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
>>> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
>>> Thread model: posix
>>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>>> configure:35364: $? = 0
>>> configure:35353: /usr/bin/gcc -V >&5
>>> gcc: error: unrecognized command line option '-V'
>>> gcc: fatal error: no input files
>>> compilation terminated.
>>> configure:35364: $? = 1
>>> configure:35353: /usr/bin/gcc -qversion >&5
>>> gcc: error: unrecognized command line option '-qversion'
>>> gcc: fatal error: no input files
>>> compilation terminated.
>>> configure:35364: $? = 1
>>> configure:35384: checking whether the C compiler works
>>> configure:35406: /usr/bin/gcc -m64    -m64   conftest.c  >&5
>>> /usr/bin/ld: cannot find crt1.o: No such file or directory
>>> /usr/bin/ld: cannot find crti.o: No such file or directory
>>> /usr/bin/ld: cannot find -lc
>>> /usr/bin/ld: cannot find crtn.o: No such file or directory
>>> collect2: error: ld returned 1 exit status
>>> configure:35410: $? = 1
>>> configure:35448: result: no
>>> configure: failed program was:
>>> | /* confdefs.h */
>>> | #define PACKAGE_NAME "OpenJDK"
>>> | #define PACKAGE_TARNAME "openjdk"
>>> | #define PACKAGE_VERSION "jdk9"
>>> | #define PACKAGE_STRING "OpenJDK jdk9"
>>> | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net"
>>> | #define PACKAGE_URL "http://openjdk.java.net"
>>> | /* end confdefs.h.  */
>>> |
>>> | int
>>> | main ()
>>> | {
>>> |
>>> |   ;
>>> |   return 0;
>>> | }
>>> configure:35453: error: in
>>> `/shared/projects/openjdk/jdk-jdk/output-fastdebug':
>>> configure:35455: error: C compiler cannot create executables
>>>
>>> -----------------
>>>
>>> Weirdly enough the compiler is ran once with -qversion, which is an
>>> AIX-only option, and once with -V, which is not valid either.
>>>
>>> Has anyone seen this already? (Note that I used Mint18.3 as
>>> development machine before and it just worked).
>>>
>>> Thanks, Thomas
>>
>>


From thomas.stuefe at gmail.com  Wed Apr 25 10:19:02 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 25 Apr 2018 12:19:02 +0200
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
In-Reply-To: <44306e82-d235-b503-d4b9-535e6910977c@redhat.com>
References: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
 <208f6157-bcf1-ad6a-da42-afeaf65bde6d@oracle.com>
 <44306e82-d235-b503-d4b9-535e6910977c@redhat.com>
Message-ID: <CAA-vtUy=kxnbE-g13mjX92gvNedYwEtgxcR9m_ue-POoszdAMA@mail.gmail.com>

Hi Aleksey,

the fix looks good.

Best Regards, Thomas

On Wed, Apr 25, 2018 at 11:29 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 04/25/2018 11:14 AM, Magnus Ihse Bursie wrote:
>>> diff -r 5d2da44780ac make/Images.gmk
>>> --- a/make/Images.gmk    Wed Apr 25 10:38:07 2018 +0200
>>> +++ b/make/Images.gmk    Wed Apr 25 10:55:04 2018 +0200
>>> @@ -117,7 +117,7 @@
>>>
>>>   JLINK_TOOL := $(JLINK) -J-Djlink.debug=true \
>>>       --module-path $(IMAGES_OUTPUTDIR)/jmods \
>>> -    --endian $(OPENJDK_BUILD_CPU_ENDIAN) \
>>> +    --endian $(OPENJDK_TARGET_CPU_ENDIAN) \
>>>       --release-info $(BASE_RELEASE_FILE) \
>>>       --order-resources=$(call CommaList, $(JLINK_ORDER_RESOURCES)) \
>>>       --dedup-legal-notices=error-if-not-same-content \
>>>
>>> Testing: x86_64 build, s390x cross-compiled build
>> Looks good to me.
>
> Thanks!
>
> I guess one reviewer is enough for this kind of change?
> No more testing needed?
>
> -Aleksey
>


From mvala at redhat.com  Wed Apr 25 10:33:05 2018
From: mvala at redhat.com (Michal Vala)
Date: Wed, 25 Apr 2018 12:33:05 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
Message-ID: <826e8757-2975-04f9-b5d6-d5e174ffede6@redhat.com>



On 04/24/2018 09:17 PM, Kim Barrett wrote:
>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>
>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>
>> I'm asking for the review and eventually sponsorship.
> 
> The change to os::readdir in os_linux.inline.hpp looks fine.
> 
> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
> of those is right, and that part of the change should not be made; see
> https://bugs.openjdk.java.net/browse/JDK-8134540
> Much nearly duplicated code for PerfMemory support
> 
> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
> the second argument to os::readdir.

That's what was I first doing. However, I have no resources to test all OSes.
I understand that this solution is not clear. However, until we remove the 
second argument and eventually merge PerfMemory code, it's useless to passing it 
on linux. That's why I did that cleanup. It can be done for all OSes under 
another bug id though.

> windows: unused
> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
> solaris: doc is clear about thread safety issue being about sharing the DIR*
> aix: I haven?t looked at it, but would guess it?s similar.
> 
> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
> ::readdir on non-Windows.  That would all be for another RFE though.
> 
> 

-- 
Michal Vala
OpenJDK QE
Red Hat Czech


From shade at redhat.com  Wed Apr 25 12:55:44 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 25 Apr 2018 14:55:44 +0200
Subject: RFR 8202210: jlink uses little-endian for big-endian
 cross-compilation targets
In-Reply-To: <50267109-4bad-aed1-d672-937b81898b12@oracle.com>
References: <c1b9d46f-5113-1196-b856-147aa69fe2a5@redhat.com>
 <50267109-4bad-aed1-d672-937b81898b12@oracle.com>
Message-ID: <ca5306cc-43b1-5316-c80f-2c2cb0997cbc@redhat.com>

On 04/25/2018 12:08 PM, Alan Bateman wrote:
> On 25/04/2018 10:06, Aleksey Shipilev wrote:
>> I was doing the exercise of cross-compiling from x86_64 to most OpenJDK arches, and we have
>> discovered the bug with endianness. Right now, compiling big-endian s390x target on little-endian
>> x86_64 host produces the modules blob that cannot be read on real s390x.
>
> It should still work, just less efficiently.

Yeah. Unfortunately, I do not have real s390x machine to debug this.

> In any case, specifying the endianness to jlink in your update to Images.gmk looks right.

Thanks for reviews!

jdk-submit came clean, so I pushed to jdk/jdk.

-Aleksey




From gnu.andrew at redhat.com  Wed Apr 25 14:51:36 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 25 Apr 2018 15:51:36 +0100
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
Message-ID: <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>

On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>
>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>
>> I'm asking for the review and eventually sponsorship.
>

The patch looks good to me.

> The change to os::readdir in os_linux.inline.hpp looks fine.
>
> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
> of those is right, and that part of the change should not be made; see
> https://bugs.openjdk.java.net/browse/JDK-8134540
> Much nearly duplicated code for PerfMemory support
>

I think, in the circumstances, Michal's solution is the best option at
this point.
8134540 looks like a more long-term change currently scheduled for 12 (is
anyone currently working on it?), whereas this fix could go into 11 and remove
a couple of unneeded memory allocations.

> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
> the second argument to os::readdir.
> windows: unused
> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
> solaris: doc is clear about thread safety issue being about sharing the DIR*
> aix: I haven?t looked at it, but would guess it?s similar.
>
> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
> ::readdir on non-Windows.  That would all be for another RFE though.
>
>

This also seems like a more in-depth separate change and not one that
can be performed
by any of us alone, as we don't test all these platforms. As it
stands, Michal's change affects
Linux and Linux alone, and the addition of the use of NULL will make
it clearer that moving
to an os:readdir is feasible on that platform.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From erik.joelsson at oracle.com  Wed Apr 25 15:30:25 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 25 Apr 2018 08:30:25 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>
Message-ID: <7e897f6d-5c22-cbd1-6f8e-9cb60614aef8@oracle.com>

Hello,

I would prefer if the .tmp file was not deleted. That will make it 
easier to debug problems in the future. We have recently had reason to 
look at the contents of the files here to figure out if the generator 
ran properly. If leaving it around, then perhaps call it .raw or 
something less temporary sounding than .tmp?

/Erik


On 2018-04-25 02:17, Magnus Ihse Bursie wrote:
>
>
> On 2018-04-25 08:17, David Holmes wrote:
>> cc'ing build-dev for the makefile change
>>
>> Hi Jiangli,
>>
>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>> Please review the following changes that streamline the support for 
>>> application class data sharing by eliminating the requirement of 
>>> using -XX:+UseAppCDS to enable the feature. The support for 
>>> application class data sharing is now enabled transparently when 
>>> application classes or platform classes present in the classlist or 
>>> generated archive with -Xshare:dump/on/auto.
>>>
>>> ????RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>> ????Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>
>> These issues are not publicly visible, can you change them to be so?
>>
>>> ????webrev: 
>>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
> Build changes look good.
>
> /Magnus
>>
>> Overall this seems fine. Thanks for explaining the logic changes 
>> below - much appreciated!
>>
>> One query: why was UseAppCDS not removed from the tests (or at least 
>> the tests you were modifying anyway) ? They will all need updating 
>> before 12 when the flag is expired.
>>
>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>
>> Test 2 reference to UseAppCDS seems unnecessary now.
>> Test 3 is not needed as you're not using any diagnostic flag now.
>> Test 4 seems unnecessary now.
>>
>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>
>> makeCommandLineForAppCDS should just be removed (yes that will cause 
>> some churn in the other tests) - but this can be a follow up test 
>> cleanup.
>>
>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>
>> This test no longer makes much sense to me. The only tests should be 
>> that app classes get archived and used. It makes no sense to claim to 
>> be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now 
>> that it is obsolete you don't need to test that -XX:-UseAppCDS has no 
>> affect.
>>
>> Thanks,
>> David
>>
>>
>>> Highlights of the changes:
>>> * UseAppCDS is obsolete in JDK 11
>>> * Remove the +UnlockCommercialFeatures requirement when using 
>>> application class data sharing in OracleJDK binary
>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>> * DumpLoadedClassList produces a complete classlist including all 
>>> loaded library and application classes
>>>
>>> Thanks David Holmes for his guidance on CSR process.
>>>
>>> Following are the details for the VM and test changes:
>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>
>>> - Removed some of the CDS/AppCDS specifics from general class 
>>> loading code.
>>>
>>> - Removed scattered checks for non-empty directory. Dump time 
>>> non-empty directory check is done at one central place, 
>>> FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading 
>>> all classes on the classlist. The behavior is backwards compatible:
>>> ?? - If no app/platform classes are loaded, dump time only reports 
>>> error if non-empty directory exists in -Xbootclasspath/a path
>>> ?? - If app/platform classes are loaded, dump time reports error for 
>>> any non-empty directory exists in -Xbootclasspath/a path, class 
>>> path, or module path
>>>
>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from 
>>> SharedClassUtil::initialize(). The code path is only executed when 
>>> UseSharedSpaces is enabled.
>>>
>>> - Return immediately in 
>>> SystemDictionaryShared::find_or_load_shared_class() if the archive 
>>> header indicates there is no app or platform classes in the shared 
>>> archive. This reduces overhead in class loading if the shared 
>>> archive only contains system classes. It also provides backwards 
>>> compatibility in cases where shared application classes should be 
>>> disabled. For example, when the default system class loader is 
>>> replaced by user provided loader, archived application classes are 
>>> inactive (not loaded from archive) at runtime without affecting the 
>>> use of archived system classes.
>>>
>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from 
>>> the default classlist in JDK image, which is generated using 
>>> DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>
>>> - Updated various cds/appcds tests to reflect the JVM changes. The 
>>> use of -XX:+UseAppCDS in tests remains unchanged.
>>>
>>> ?? - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>
>>> ?? - Removed -XX:+UnlockDiagnosticVMOptions for 
>>> -XX:SharedArchiveFile in tests
>>>
>>> ?? - Updated NonBootLoaderClasses.java: ensure app/platform classes 
>>> on classlist are archived without -XX:+UseAppCDS
>>>
>>> ?? - Updated DirClasspathTest.java: reflect the change for non-empty 
>>> directory handling
>>>
>>> ?? - Updated MismatchedUseAppCDS.java:? -XX:-UseAppCDS has no effect
>>>
>>> Tested with all cds and appcds tests locally with both fastdebug and 
>>> release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and 
>>> jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>
>>> Thanks,
>>> Jiangli
>>>
>



From ioi.lam at oracle.com  Wed Apr 25 15:36:55 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 25 Apr 2018 08:36:55 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
Message-ID: <39680f13-cd6c-7359-d857-11fc3a094de9@oracle.com>

Hi Jiangli,

The code changes look good to me. I agree with David's comments about 
the test cases.

Thanks

- Ioi


On 4/24/18 11:17 PM, David Holmes wrote:
> cc'ing build-dev for the makefile change
>
> Hi Jiangli,
>
> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>> Please review the following changes that streamline the support for 
>> application class data sharing by eliminating the requirement of 
>> using -XX:+UseAppCDS to enable the feature. The support for 
>> application class data sharing is now enabled transparently when 
>> application classes or platform classes present in the classlist or 
>> generated archive with -Xshare:dump/on/auto.
>>
>> ????RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>> ????Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>
> These issues are not publicly visible, can you change them to be so?
>
>> ????webrev: 
>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>
> Overall this seems fine. Thanks for explaining the logic changes below 
> - much appreciated!
>
> One query: why was UseAppCDS not removed from the tests (or at least 
> the tests you were modifying anyway) ? They will all need updating 
> before 12 when the flag is expired.
>
> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>
> Test 2 reference to UseAppCDS seems unnecessary now.
> Test 3 is not needed as you're not using any diagnostic flag now.
> Test 4 seems unnecessary now.
>
> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>
> makeCommandLineForAppCDS should just be removed (yes that will cause 
> some churn in the other tests) - but this can be a follow up test 
> cleanup.
>
> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>
> This test no longer makes much sense to me. The only tests should be 
> that app classes get archived and used. It makes no sense to claim to 
> be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now 
> that it is obsolete you don't need to test that -XX:-UseAppCDS has no 
> affect.
>
> Thanks,
> David
>
>
>> Highlights of the changes:
>> * UseAppCDS is obsolete in JDK 11
>> * Remove the +UnlockCommercialFeatures requirement when using 
>> application class data sharing in OracleJDK binary
>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>> * DumpLoadedClassList produces a complete classlist including all 
>> loaded library and application classes
>>
>> Thanks David Holmes for his guidance on CSR process.
>>
>> Following are the details for the VM and test changes:
>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>
>> - Removed some of the CDS/AppCDS specifics from general class loading 
>> code.
>>
>> - Removed scattered checks for non-empty directory. Dump time 
>> non-empty directory check is done at one central place, 
>> FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading 
>> all classes on the classlist. The behavior is backwards compatible:
>> ?? - If no app/platform classes are loaded, dump time only reports 
>> error if non-empty directory exists in -Xbootclasspath/a path
>> ?? - If app/platform classes are loaded, dump time reports error for 
>> any non-empty directory exists in -Xbootclasspath/a path, class path, 
>> or module path
>>
>> - Removed unnecessary ?if (!DumpSharedSpaces)? from 
>> SharedClassUtil::initialize(). The code path is only executed when 
>> UseSharedSpaces is enabled.
>>
>> - Return immediately in 
>> SystemDictionaryShared::find_or_load_shared_class() if the archive 
>> header indicates there is no app or platform classes in the shared 
>> archive. This reduces overhead in class loading if the shared archive 
>> only contains system classes. It also provides backwards 
>> compatibility in cases where shared application classes should be 
>> disabled. For example, when the default system class loader is 
>> replaced by user provided loader, archived application classes are 
>> inactive (not loaded from archive) at runtime without affecting the 
>> use of archived system classes.
>>
>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from 
>> the default classlist in JDK image, which is generated using 
>> DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>
>> - Updated various cds/appcds tests to reflect the JVM changes. The 
>> use of -XX:+UseAppCDS in tests remains unchanged.
>>
>> ?? - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>
>> ?? - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile 
>> in tests
>>
>> ?? - Updated NonBootLoaderClasses.java: ensure app/platform classes 
>> on classlist are archived without -XX:+UseAppCDS
>>
>> ?? - Updated DirClasspathTest.java: reflect the change for non-empty 
>> directory handling
>>
>> ?? - Updated MismatchedUseAppCDS.java:? -XX:-UseAppCDS has no effect
>>
>> Tested with all cds and appcds tests locally with both fastdebug and 
>> release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and 
>> jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>
>> Thanks,
>> Jiangli
>>



From adam.farley at uk.ibm.com  Wed Apr 25 15:43:03 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 25 Apr 2018 16:43:03 +0100
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
Message-ID: <OF6E36BEFB.D98AC1C0-ON0025827A.0055A173-8025827A.00565781@notes.na.collabserv.com>

Hi All,

Does anyone have an objection to pushing this tiny change in?

It doesn't break anything, it fixes a build break on two supported 
platforms, and it seems
like we never refresh the code from upstream. 

- Adam

> I also advocate the source code fix, as Make isn't meant to use the sort 
of logic required 
> to properly analyse the toolchain version string. 
> 
> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, 
and Make doesn't
> seem to do substring stuff unless you mess around with shells.
> 
> Plus, as people have said, it's better to solve problem x (or work 
around a specific 
> instance of x) than to ignore the exception, even if the ignoring code 
is toolchain-
> specific.
> 
> - Adam Farley
> 
> > On 2018-03-27 18:44, Phil Race wrote:
> > 
> >> As I said I prefer the make file change, since this is a change to an 
upstream library.
> > 
> > Newtons fourth law: For every reviewer, there's an equal and opposite 
reviewer. :) 
> > 
> > Here I am, advocating a source code fix. As Thomas says, the compiler 
complaint seems reasonable, and disabling it might cause us to miss other 
future errors.
> > 
> > Why can't we push the source code fix, and also submit it upstream?
> > 
> > /Magnus
> > 
> > 
> > I've looked at jpeg-9c and it still looks identical to what we have in 
6b, so this code
> > seems to have stood the test of time. I'm also unclear why the 
compiler would
> > complain about that and not the one a few lines later 
> > 
> > 
> >  819   while (bits[i] == 0)          /* find largest codelength still 
in use */
> >  820     i--;
> > 
> > A push to jchuff.c will get blown away if/when we upgrade.
> > A tool-chain specific fix in the makefile with an appropriate comment 
is more targeted.
> 
> Phil,
> 
> Returning to this.
> 
> While I understand your reluctance to patch upstream code, let me point 
out that we have not updated libjpeg a single time since the JDK was open 
sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia 
page on libjpeg, and this is the latest "uncontroversial" version of the 
source. Versions 7 and up have proprietary extensions, which in turn has 
resulted in multiple forks of libjpeg. As it stands, it seems unlikely 
that we will ever replace libjpeg 6b with a simple upgrade from upstream.
> 
> I therefore maintain my position that a source code fix would be the 
best way forward here.
> 
> /Magnus
> 
> > 
> > 
> > -phil.
> > 
> > 
> > On 03/27/2018 05:44 AM, Thomas St?fe wrote:
> > 
> > Hi all, 
> > 
> > 
> > just a friendly reminder. I would like to push this tiny fix because 
tripping over this on our linux s390x builds is annoying (yes, we can 
maintain patch queues, but this is a constant error source).
> > 
> > 
> > I will wait for 24 more hours until a reaction. If no serious 
objections are forcoming, I want to push it (tier1 tests ran thru, and me 
and Christoph langer are both Reviewers).
> > 
> > 
> > Thanks! Thomas
> > 
> > 
> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe 
<thomas.stuefe at gmail.com> wrote:
> > 
> > Hi all, 
> > 
> > 
> > may I please have another review for this really trivial change. It 
fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to 
fix this.
> > 
> > 
> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> > webrev: 
http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/
> > 
> > 
> > This was contributed by Adam Farley at IBM.
> > 
> > 
> > I already reviewed this. I also test-built on zlinux and it works.
> > 
> > 
> > Thanks, Thomas
> > 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From sgehwolf at redhat.com  Wed Apr 25 15:44:29 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 25 Apr 2018 17:44:29 +0200
Subject: [10] RFR: 8202262: libjsig.so not linked with extra linker flags
 from configure
Message-ID: <1524671069.4355.31.camel@redhat.com>

Hi,

Can I please get a review for this JDK 10 only fix, which prevents some
extra link flags getting injected to the build of libjsig.so. JDK 11 is
not affected. It appears to be a typo. It should be a rather low risk
change and helps us reduce downstream carried patches.

Bug: https://bugs.openjdk.java.net/browse/JDK-8202262
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202262/webrev.01/

Thanks,
Severin



From erik.joelsson at oracle.com  Wed Apr 25 15:48:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 25 Apr 2018 08:48:28 -0700
Subject: [10] RFR: 8202262: libjsig.so not linked with extra linker flags
 from configure
In-Reply-To: <1524671069.4355.31.camel@redhat.com>
References: <1524671069.4355.31.camel@redhat.com>
Message-ID: <3a6d06e6-da3d-3334-f8c2-86935515d58d@oracle.com>

The change looks good. You will need to also get approval for pushing to 
10u.

/Erik


On 2018-04-25 08:44, Severin Gehwolf wrote:
> Hi,
>
> Can I please get a review for this JDK 10 only fix, which prevents some
> extra link flags getting injected to the build of libjsig.so. JDK 11 is
> not affected. It appears to be a typo. It should be a rather low risk
> change and helps us reduce downstream carried patches.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202262
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202262/webrev.01/
>
> Thanks,
> Severin
>



From sgehwolf at redhat.com  Wed Apr 25 16:02:02 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 25 Apr 2018 18:02:02 +0200
Subject: [10] RFR: 8202262: libjsig.so not linked with extra linker
 flags from configure
In-Reply-To: <3a6d06e6-da3d-3334-f8c2-86935515d58d@oracle.com>
References: <1524671069.4355.31.camel@redhat.com>
 <3a6d06e6-da3d-3334-f8c2-86935515d58d@oracle.com>
Message-ID: <1524672122.4355.33.camel@redhat.com>

On Wed, 2018-04-25 at 08:48 -0700, Erik Joelsson wrote:
> The change looks good. You will need to also get approval for pushing to 
> 10u.

Right. Thanks for the review, Erik!

Cheers,
Severin

> /Erik
> 
> 
> On 2018-04-25 08:44, Severin Gehwolf wrote:
> > Hi,
> > 
> > Can I please get a review for this JDK 10 only fix, which prevents some
> > extra link flags getting injected to the build of libjsig.so. JDK 11 is
> > not affected. It appears to be a typo. It should be a rather low risk
> > change and helps us reduce downstream carried patches.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8202262
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202262/webrev.01/
> > 
> > Thanks,
> > Severin
> > 
> 
> 


From kumar.x.srinivasan at oracle.com  Wed Apr 25 16:38:32 2018
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Apr 2018 09:38:32 -0700
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5ACFBE5C.1080508@oracle.com>
References: <5ACFBE5C.1080508@oracle.com>
Message-ID: <5AE0AF08.10105@oracle.com>

Hi John,

I focused mainly on the native side, looks ok, except  for a couple of
minor issues.

java.c

1320                 const char *prop = "-Djdk.internal.javac.source=";
1321                 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1;
1322                 char *propValue = (char *)JLI_MemAlloc(size + 1);

I think we are allocating extra byte ^^^^^^^

1323                 JLI_StrCpy(propValue, prop);
1324                 JLI_StrCat(propValue, value);

I think we can do this, safer and neater, as follows:

size_t size = JLI_StrLen(prop) + JLI_StrLen(value);
char *propValue = (char *)JLI_MemAlloc(size + 1);
JLI_Snprintf(propValue, size, "%s%s", prop, value);

1483     if (mode == LM_SOURCE) {
1484         AddOption("--add-modules=ALL-DEFAULT", NULL);
1485         *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY;
1486         *pargc = argc + 1;
1487         *pargv = argv - 1;

A short comment perhaps ? why we are incrementing argc, and decrementing 
argv,
saves some head scratching for a casual reader.

I looked at the launcher tests, very nice.


Thanks
Kumar





On 4/12/2018 1:15 PM, Jonathan Gibbons wrote:
> Please review an initial implementation for the feature described in
> JEP 330: Launch Single-File Source-Code Programs.
>
> The work is described in the JEP and CSR, and falls into various parts:
>
>   * The part to handle the new command-line options is in the native
>     Java launcher code.
>   * The part to invoke the compiler and subsequently execute the code
>     found in the source file is in a new class in the jdk.compiler module.
>   * There are some minor Makefile changes, to add support for a new
>     resource file.
>
> There are no changes to javac itself.
>
> JEP: http://openjdk.java.net/jeps/330
> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>
> -- Jon



From jiangli.zhou at oracle.com  Wed Apr 25 17:39:28 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 25 Apr 2018 10:39:28 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
Message-ID: <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>

Hi David,

Thanks a lot for the review!

> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> cc'ing build-dev for the makefile change
> 
> Hi Jiangli,
> 
> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
> 
> These issues are not publicly visible, can you change them to be so?

Done. Thanks for noticing that!

> 
>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
> 
> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
> 
> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.

The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.

> 
> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
> 
> Test 2 reference to UseAppCDS seems unnecessary now.
> Test 3 is not needed as you're not using any diagnostic flag now.
> Test 4 seems unnecessary now.

Will do.

> 
> test/hotspot/jtreg/runtime/appcds/TestCommon.java
> 
> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.

Ok.

> 
> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
> 
> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.

Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.

Thanks!

Jiangli

> 
> Thanks,
> David
> 
> 
>> Highlights of the changes:
>> * UseAppCDS is obsolete in JDK 11
>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>> Thanks David Holmes for his guidance on CSR process.
>> Following are the details for the VM and test changes:
>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>> Thanks,
>> Jiangli



From jiangli.zhou at oracle.com  Wed Apr 25 17:40:41 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 25 Apr 2018 10:40:41 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>
Message-ID: <5618525E-D820-48B4-AC88-18A847DFAB52@oracle.com>

Hi Magnus,

Thanks a lot for the review!

Jiangli

> On Apr 25, 2018, at 2:17 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> 
> On 2018-04-25 08:17, David Holmes wrote:
>> cc'ing build-dev for the makefile change
>> 
>> Hi Jiangli,
>> 
>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>> 
>>>     RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>> 
>> These issues are not publicly visible, can you change them to be so?
>> 
>>>     webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
> Build changes look good.
> 
> /Magnus
>> 
>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>> 
>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>> 
>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>> 
>> Test 2 reference to UseAppCDS seems unnecessary now.
>> Test 3 is not needed as you're not using any diagnostic flag now.
>> Test 4 seems unnecessary now.
>> 
>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>> 
>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>> 
>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>> 
>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>> 
>> Thanks,
>> David
>> 
>> 
>>> Highlights of the changes:
>>> * UseAppCDS is obsolete in JDK 11
>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>> 
>>> Thanks David Holmes for his guidance on CSR process.
>>> 
>>> Following are the details for the VM and test changes:
>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>> 
>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>> 
>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>    - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>    - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>> 
>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>> 
>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>> 
>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>> 
>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>> 
>>>    - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>> 
>>>    - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>> 
>>>    - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>> 
>>>    - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>> 
>>>    - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>> 
>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>> 
>>> Thanks,
>>> Jiangli
>>> 
> 



From jonathan.gibbons at oracle.com  Wed Apr 25 17:58:31 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 25 Apr 2018 10:58:31 -0700
Subject: RFR: 8201274: Launch Single-File Source-Code Programs
In-Reply-To: <5AE0AF08.10105@oracle.com>
References: <5ACFBE5C.1080508@oracle.com> <5AE0AF08.10105@oracle.com>
Message-ID: <5AE0C1C7.5010300@oracle.com>

Kumar,

Thank you for your feedback;  I will incorporate it in the next webrev.

-- Jon

On 04/25/2018 09:38 AM, Kumar Srinivasan wrote:
> Hi John,
>
> I focused mainly on the native side, looks ok, except  for a couple of
> minor issues.
>
> java.c
> 1320                 const char *prop = "-Djdk.internal.javac.source=";
> 1321                 size_t size = JLI_StrLen(prop) + JLI_StrLen(value) + 1;
> 1322                 char *propValue = (char *)JLI_MemAlloc(size + 1);
>
> I think we are allocating extra byte ^^^^^^^
>
> 1323                 JLI_StrCpy(propValue, prop);
> 1324                 JLI_StrCat(propValue, value);
>
> I think we can do this, safer and neater, as follows:
>
> size_t size = JLI_StrLen(prop) + JLI_StrLen(value);
> char *propValue = (char *)JLI_MemAlloc(size + 1);
> JLI_Snprintf(propValue, size, "%s%s", prop, value);
> 1483     if (mode == LM_SOURCE) {
> 1484         AddOption("--add-modules=ALL-DEFAULT", NULL);
> 1485         *pwhat = SOURCE_LAUNCHER_MAIN_ENTRY;
> 1486         *pargc = argc + 1;
> 1487         *pargv = argv - 1;
>
> A short comment perhaps ? why we are incrementing argc, and 
> decrementing argv,
> saves some head scratching for a casual reader.
>
> I looked at the launcher tests, very nice.
>
>
> Thanks
> Kumar
>
>
>
>
>
> On 4/12/2018 1:15 PM, Jonathan Gibbons wrote:
>> Please review an initial implementation for the feature described in
>> JEP 330: Launch Single-File Source-Code Programs.
>>
>> The work is described in the JEP and CSR, and falls into various parts:
>>
>>   * The part to handle the new command-line options is in the native
>>     Java launcher code.
>>   * The part to invoke the compiler and subsequently execute the code
>>     found in the source file is in a new class in the jdk.compiler
>>     module.
>>   * There are some minor Makefile changes, to add support for a new
>>     resource file.
>>
>> There are no changes to javac itself.
>>
>> JEP: http://openjdk.java.net/jeps/330
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275
>> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/
>>
>> -- Jon
>



From jiangli.zhou at oracle.com  Wed Apr 25 18:00:43 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 25 Apr 2018 11:00:43 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <7e897f6d-5c22-cbd1-6f8e-9cb60614aef8@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <bf1a091b-6f00-bc41-78a6-a054ed00093d@oracle.com>
 <7e897f6d-5c22-cbd1-6f8e-9cb60614aef8@oracle.com>
Message-ID: <32471898-F3CD-41ED-BEB8-9AF60A912BC6@oracle.com>

Hi Erik,

> On Apr 25, 2018, at 8:30 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> I would prefer if the .tmp file was not deleted. That will make it easier to debug problems in the future. We have recently had reason to look at the contents of the files here to figure out if the generator ran properly. If leaving it around, then perhaps call it .raw or something less temporary sounding than .tmp?

Thanks for the suggestion. Sounds good to me, as long as it follows JDK build convention.

Thanks a lot for looking at this!

Jiangli

> 
> /Erik
> 
> 
> On 2018-04-25 02:17, Magnus Ihse Bursie wrote:
>> 
>> 
>> On 2018-04-25 08:17, David Holmes wrote:
>>> cc'ing build-dev for the makefile change
>>> 
>>> Hi Jiangli,
>>> 
>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>> 
>>>>     RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>> 
>>> These issues are not publicly visible, can you change them to be so?
>>> 
>>>>     webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>> Build changes look good.
>> 
>> /Magnus
>>> 
>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>> 
>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>> 
>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>> 
>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>> Test 4 seems unnecessary now.
>>> 
>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>> 
>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>> 
>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>> 
>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>> 
>>> Thanks,
>>> David
>>> 
>>> 
>>>> Highlights of the changes:
>>>> * UseAppCDS is obsolete in JDK 11
>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>> 
>>>> Thanks David Holmes for his guidance on CSR process.
>>>> 
>>>> Following are the details for the VM and test changes:
>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>> 
>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>> 
>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>    - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>    - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>> 
>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>> 
>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>> 
>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>> 
>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>> 
>>>>    - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>> 
>>>>    - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>> 
>>>>    - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>> 
>>>>    - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>> 
>>>>    - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>> 
>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>> 
>>>> Thanks,
>>>> Jiangli
>>>> 
>> 
> 



From david.holmes at oracle.com  Wed Apr 25 22:12:41 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Apr 2018 08:12:41 +1000
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
Message-ID: <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>

Hi Jiangli,

On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
> Hi David,
> 
> Thanks a lot for the review!
> 
>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> cc'ing build-dev for the makefile change
>>
>> Hi Jiangli,
>>
>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>
>> These issues are not publicly visible, can you change them to be so?
> 
> Done. Thanks for noticing that!
> 
>>
>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>
>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>
>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
> 
> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.

This sounds like you are basically testing whether obsoleting the flag 
has worked correctly. You don't need to do that through formal testing. 
A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning 
and that's that. We don't maintain an obsolete flag test the way we do 
for deprecated flags.

So IMHO there's really no reason to keep the flag in any of the tests. 
As I said they will all have to be removed when the flag is expired in 12.

Thanks,
David

>>
>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>
>> Test 2 reference to UseAppCDS seems unnecessary now.
>> Test 3 is not needed as you're not using any diagnostic flag now.
>> Test 4 seems unnecessary now.
> 
> Will do.
> 
>>
>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>
>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
> 
> Ok.
> 
>>
>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>
>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
> 
> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
> 
> Thanks!
> 
> Jiangli
> 
>>
>> Thanks,
>> David
>>
>>
>>> Highlights of the changes:
>>> * UseAppCDS is obsolete in JDK 11
>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>> Thanks David Holmes for his guidance on CSR process.
>>> Following are the details for the VM and test changes:
>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>    - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>    - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>    - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>    - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>    - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>    - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>    - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>> Thanks,
>>> Jiangli
> 


From jiangli.zhou at oracle.com  Thu Apr 26 00:24:45 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 25 Apr 2018 17:24:45 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
Message-ID: <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>

Hi David,

> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Jiangli,
> 
> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>> Hi David,
>> Thanks a lot for the review!
>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> cc'ing build-dev for the makefile change
>>> 
>>> Hi Jiangli,
>>> 
>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>> 
>>> These issues are not publicly visible, can you change them to be so?
>> Done. Thanks for noticing that!
>>> 
>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>> 
>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>> 
>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
> 
> This sounds like you are basically testing whether obsoleting the flag has worked correctly.

Right, that was part of the intention.

> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.

That sounds reasonable.

> 
> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.

Ok. I?ll remove the flag from the tests.

Thanks!

Jiangli

> 
> Thanks,
> David
> 
>>> 
>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>> 
>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>> Test 4 seems unnecessary now.
>> Will do.
>>> 
>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>> 
>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>> Ok.
>>> 
>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>> 
>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>> Thanks!
>> Jiangli
>>> 
>>> Thanks,
>>> David
>>> 
>>> 
>>>> Highlights of the changes:
>>>> * UseAppCDS is obsolete in JDK 11
>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>> Thanks David Holmes for his guidance on CSR process.
>>>> Following are the details for the VM and test changes:
>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>> Thanks,
>>>> Jiangli



From jiangli.zhou at oracle.com  Thu Apr 26 04:34:16 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Wed, 25 Apr 2018 21:34:16 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
Message-ID: <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>

Here is the incremental webrev with updates that incorporate all feedbacks:
http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/

- Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
- Removed case 2, 3 and 4 in SharedArchiveFile.java.
- Removed UseAppCDS.java test.
- Removed UseAppCDS in various tests.
- Changed to keep the original version of the classlist and renamed to classlist.raw.
- Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.

Full webrev:
http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150

Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.

Thanks for all the suggestions!

Jiangli


> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
> 
> Hi David,
> 
>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> Hi Jiangli,
>> 
>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>> Hi David,
>>> Thanks a lot for the review!
>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> cc'ing build-dev for the makefile change
>>>> 
>>>> Hi Jiangli,
>>>> 
>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>> 
>>>> These issues are not publicly visible, can you change them to be so?
>>> Done. Thanks for noticing that!
>>>> 
>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>> 
>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>> 
>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>> 
>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
> 
> Right, that was part of the intention.
> 
>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
> 
> That sounds reasonable.
> 
>> 
>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
> 
> Ok. I?ll remove the flag from the tests.
> 
> Thanks!
> 
> Jiangli
> 
>> 
>> Thanks,
>> David
>> 
>>>> 
>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>> 
>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>> Test 4 seems unnecessary now.
>>> Will do.
>>>> 
>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>> 
>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>> Ok.
>>>> 
>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>> 
>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>> Thanks!
>>> Jiangli
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>> 
>>>>> Highlights of the changes:
>>>>> * UseAppCDS is obsolete in JDK 11
>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>> Following are the details for the VM and test changes:
>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>> Thanks,
>>>>> Jiangli
> 



From david.holmes at oracle.com  Thu Apr 26 05:09:07 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Apr 2018 15:09:07 +1000
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
Message-ID: <e36bd45e-a7d2-d682-66d0-c1707b405767@oracle.com>

On 26/04/2018 2:34 PM, Jiangli Zhou wrote:
> Here is the incremental webrev with updates that incorporate all feedbacks:
> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/

Looks good.

One additional comment on 
test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems 
insufficient to just check the output for the word "dump". I would 
expect to see something more definitively associated with -Xshare:dump 
and also a check that it exited cleanly (in case we find "core dump").

Thanks,
David
-----

> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
> - Removed UseAppCDS.java test.
> - Removed UseAppCDS in various tests.
> - Changed to keep the original version of the classlist and renamed to classlist.raw.
> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
> 
> Full webrev:
> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
> 
> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
> 
> Thanks for all the suggestions!
> 
> Jiangli
> 
> 
>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>
>> Hi David,
>>
>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Jiangli,
>>>
>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>> Hi David,
>>>> Thanks a lot for the review!
>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> cc'ing build-dev for the makefile change
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>
>>>>> These issues are not publicly visible, can you change them to be so?
>>>> Done. Thanks for noticing that!
>>>>>
>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>
>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>
>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>
>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>
>> Right, that was part of the intention.
>>
>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>
>> That sounds reasonable.
>>
>>>
>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>
>> Ok. I?ll remove the flag from the tests.
>>
>> Thanks!
>>
>> Jiangli
>>
>>>
>>> Thanks,
>>> David
>>>
>>>>>
>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>
>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>> Test 4 seems unnecessary now.
>>>> Will do.
>>>>>
>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>
>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>> Ok.
>>>>>
>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>
>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>> Thanks!
>>>> Jiangli
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Highlights of the changes:
>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>> Following are the details for the VM and test changes:
>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>> Thanks,
>>>>>> Jiangli
>>
> 


From magnus.ihse.bursie at oracle.com  Thu Apr 26 08:37:27 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Apr 2018 10:37:27 +0200
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
Message-ID: <417735de-7fa6-1233-af59-1bfb842cac8b@oracle.com>

On 2018-04-26 06:34, Jiangli Zhou wrote:
> Here is the incremental webrev with updates that incorporate all feedbacks:
> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
Looks even better.

/Magnus
>
> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
> - Removed UseAppCDS.java test.
> - Removed UseAppCDS in various tests.
> - Changed to keep the original version of the classlist and renamed to classlist.raw.
> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>
> Full webrev:
> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>
> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>
> Thanks for all the suggestions!
>
> Jiangli
>
>
>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>
>> Hi David,
>>
>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Jiangli,
>>>
>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>> Hi David,
>>>> Thanks a lot for the review!
>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> cc'ing build-dev for the makefile change
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>> These issues are not publicly visible, can you change them to be so?
>>>> Done. Thanks for noticing that!
>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>
>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>> Right, that was part of the intention.
>>
>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>> That sounds reasonable.
>>
>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>> Ok. I?ll remove the flag from the tests.
>>
>> Thanks!
>>
>> Jiangli
>>
>>> Thanks,
>>> David
>>>
>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>
>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>> Test 4 seems unnecessary now.
>>>> Will do.
>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>
>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>> Ok.
>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>
>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>> Thanks!
>>>> Jiangli
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Highlights of the changes:
>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>> Following are the details for the VM and test changes:
>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>> Thanks,
>>>>>> Jiangli



From kevin.walls at oracle.com  Thu Apr 26 08:38:09 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 26 Apr 2018 09:38:09 +0100
Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with
 Visual Studio 2013 (VS2013)
In-Reply-To: <e740840c-336d-4563-07f8-4b4cb9e32d8b@oracle.com>
References: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com>
 <e740840c-336d-4563-07f8-4b4cb9e32d8b@oracle.com>
Message-ID: <31e018fb-074b-041f-05fb-b61e882fb619@oracle.com>

Thanks Erik -

I went ahead with the jdk's make/CopyFiles.gmk change, and added 
SetupCopyFiles to the base repo's make/common/MakeBase.gmk.

I updated the webrev, to include base and jdk repos:

http://cr.openjdk.java.net/~kevinw/8042707/webrev.01/

I'm getting these build OK with VS2012, but there will be further 
hotspot change at least for VS2013 to be a working option in 8u.

Thanks
Kevin
(my previous reply was not the the list, so this is the open response!)



On 20/04/2018 23:27, Erik Joelsson wrote:
> The root repo changes look ok.
>
> The changes in Copy-java.base.gmk applies to jdk/make/CopyFiles.gmk. 
> Those changes are definitely needed.
>
> /Erik
>
>
> On 2018-04-20 13:18, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to request a review of the backport from 9 to 8u:
>>
>> 8042707: Source changes needed to build JDK 9 with Visual Studio 2013 
>> (VS2013)
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8042707
>>
>> 9 changesets:
>> base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890
>> jdk repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad
>>
>> 9 review thread: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html
>>
>>
>> Notes:
>> base repo:
>> toolchain_windows.m4: quite a bit of manual work, but no conflicts.
>> make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't 
>> have in 8u
>> flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the 
>> same change.
>>
>> jdk repo:
>> make/copy/Copy-java.base.gmk we don't have in 8u. The other two files 
>> apply cleanly.
>>
>>
>> Clearly this backport isn't to change anything about what compilers 
>> are supported or recommended,
>> it's just about the build infrastructure.
>>
>>
>> 8u change: webrev of the base repo changes:
>> http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/
>>
>> Many thanks
>> Kevin
>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr 26 08:39:13 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Apr 2018 10:39:13 +0200
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <OF6E36BEFB.D98AC1C0-ON0025827A.0055A173-8025827A.00565781@notes.na.collabserv.com>
References: <OF6E36BEFB.D98AC1C0-ON0025827A.0055A173-8025827A.00565781@notes.na.collabserv.com>
Message-ID: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com>

I don't object, but it's not build code so I don't have the final say.

/Magnus

On 2018-04-25 17:43, Adam Farley8 wrote:
> Hi All,
>
> Does anyone have an objection to pushing this tiny change in?
>
> It doesn't break anything, it fixes a build break on two supported 
> platforms, and it seems
> like we never refresh the code from upstream.
>
> - Adam
>
> > I also advocate the source code fix, as Make isn't meant to use the sort of 
> logic required
> > to properly analyse the toolchain version string.
> > 
> > e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and 
> Make doesn't
> > seem to do substring stuff unless you mess around with shells.
> > 
> > Plus, as people have said, it's better to solve problem x (or work around a 
> specific
> > instance of x) than to ignore the exception, even if the ignoring code is 
> toolchain-
> > specific.
> > 
> > - Adam Farley
> > 
> > > On 2018-03-27 18:44, Phil Race wrote:
> > > 
> > >> As I said I prefer the make file change, since this is a change to an 
> upstream library.
> > > 
> > > Newtons fourth law: For every reviewer, there's an equal and opposite 
> reviewer. :)
> > > 
> > > Here I am, advocating a source code fix. As Thomas says, the compiler 
> complaint seems reasonable, and disabling it might cause us to miss 
> other future errors.
> > > 
> > > Why can't we push the source code fix, and also submit it upstream?
> > > 
> > > /Magnus
> > > 
> > > 
> > > I've looked at jpeg-9c and it still looks identical to what we have 
> in 6b, so this code
> > > seems to have stood the test of time. I'm also unclear why the 
> compiler would
> > > complain about that and not the one a few lines later
> > >  
> > > 
> > > ?819 ? while (bits[i] == 0) ? ? ? ? ?/* find largest codelength still 
> in use */
> > > ?820 ? ? i--;
> > > 
> > > A push to jchuff.c will get blown away if/when we upgrade.
> > > A tool-chain specific fix in the makefile with an appropriate comment 
> is more targeted.
> > 
> > Phil,
> > 
> > Returning to this.
> > 
> > While I understand your reluctance to patch upstream code, let me 
> point out that we have not updated libjpeg a single time since the JDK 
> was open sourced. We're using 6b from 27-Mar-1998. I had a look at the 
> Wikipedia page on libjpeg, and this is the latest "uncontroversial" 
> version of the source.Versions 7 and up have proprietary extensions, 
> which in turn has resulted in multiple forks of libjpeg. As it stands, 
> it seems unlikely that we will ever replace libjpeg 6b with a simple 
> upgrade from upstream.
> > 
> > I therefore maintain my position that a source code fix would be the 
> best way forward here.
> > 
> > /Magnus
> > 
> > > 
> > > 
> > > -phil.
> > > 
> > > 
> > > On 03/27/2018 05:44 AM, Thomas St?fe wrote:
> > > 
> > > Hi all,
> > > 
> > > 
> > > just a friendly reminder. I would like to push this tiny fix because 
> tripping over this on our linux s390x builds is annoying (yes, we can 
> maintain patch queues, but this is a constant error source).
> > > 
> > > 
> > > I will wait for 24 more hours until a reaction. If no serious 
> objections are forcoming, I want to push it (tier1 tests ran thru, and 
> me and Christoph langer are both Reviewers).
> > > 
> > > 
> > > Thanks! Thomas
> > > 
> > > 
> > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe <thomas.stuefe at gmail.com> 
> wrote:
> > > 
> > > Hi all,
> > > 
> > > 
> > > may I please have another review for this really trivial change. It fixes 
> a gcc warning on s390 and ppc. Also, it is probably a good idea to fix 
> this.
> > > 
> > > 
> > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> > > webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/> 
>
> > > 
> > > 
> > > This was contributed by Adam Farley at IBM.
> > > 
> > > 
> > > I already reviewed this. I also test-built on zlinux and it works.
> > > 
> > > 
> > > Thanks, Thomas
> > > 
> > 
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
> > 
> > 
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From magnus.ihse.bursie at oracle.com  Thu Apr 26 09:45:02 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Apr 2018 11:45:02 +0200
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>


On 2018-04-25 13:06, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed. 
> Event metadata has been consolidated into a single XML file and event 
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
Hi Erik,

When posting build changes (files in "make/*"), please always include 
build-dev. Thanks! :-)

This review is for build changes only.

* make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year 
change. It can be reverted.

* make/copy/Copy-jdk.jfr.gmk:
COPY_HOTSPOT_TRACE_FILES should be renamed to something like 
COPY_JFR_METADATA.

The second part is better off rewritten using SetupCopyFiles.

Something like this, written on-the-fly, so might not work. (Email me 
privately if it does not work and you need help.)

JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr

$(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
 ? DEST := $(LIB_DST_DIR)/jfr, \
 ? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
 ? FLATTEN := true, \
))

TARGETS += $(COPY_JFR_CONF)

* make/autoconf/hotspot.m4:
It's a bit unfortunate with the --enable-jfr option. Ideally, this 
should be handled only as a JVM feature (--with-jvm-features=jfr). Try 
this piece of code instead: (Not tested, but should work.)

diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -26,7 +26,7 @@
 ?# All valid JVM features, regardless of platform
 ?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti jvmci \
 ???? graal vm-structs jni-check services management all-gcs nmt cds \
-??? static-build link-time-opt aot"
+??? static-build link-time-opt aot jfr"

 ?# All valid JVM variants
 ?VALID_JVM_VARIANTS="server client minimal core zero custom"
@@ -313,6 +313,11 @@
 ???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature 
'all-gcs'])
 ?? fi

+? # Enable JFR by default, except on linux-sparcv9 and on minimal.
+? if test "x$OPENJDK_TARGET_OS" != xlinux || test 
"x$OPENJDK_TARGET_CPU" != xsparcv9; then
+??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
+? fi
+
 ?? # Turn on additional features based on other parts of configure
 ?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
 ???? JVM_FEATURES="$JVM_FEATURES dtrace"

Otherwise, build changes look good!

/Magnus


>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus



From thomas.stuefe at gmail.com  Thu Apr 26 09:46:40 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 11:46:40 +0200
Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile
 warning in jchuff.c
In-Reply-To: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com>
References: <OF6E36BEFB.D98AC1C0-ON0025827A.0055A173-8025827A.00565781@notes.na.collabserv.com>
 <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com>
Message-ID: <CAA-vtUxcoZtGx34ziHzrArXL=-EC99e_SsGVun75L5uS1Qck8w@mail.gmail.com>

Same here. I would like to have this fix in, but do not want to go
over Phils head.

I think Phil was the main objector, maybe he could reconsider?`

Thanks, Thomas

On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> I don't object, but it's not build code so I don't have the final say.
>
> /Magnus
>
>
> On 2018-04-25 17:43, Adam Farley8 wrote:
>
> Hi All,
>
> Does anyone have an objection to pushing this tiny change in?
>
> It doesn't break anything, it fixes a build break on two supported
> platforms, and it seems
> like we never refresh the code from upstream.
>
> - Adam
>
>> I also advocate the source code fix, as Make isn't meant to use the sort
>> of logic required
>> to properly analyse the toolchain version string.
>>
>> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6,
>> and Make doesn't
>> seem to do substring stuff unless you mess around with shells.
>>
>> Plus, as people have said, it's better to solve problem x (or work around
>> a specific
>> instance of x) than to ignore the exception, even if the ignoring code is
>> toolchain-
>> specific.
>>
>> - Adam Farley
>>
>> > On 2018-03-27 18:44, Phil Race wrote:
>> >
>> >> As I said I prefer the make file change, since this is a change to an
>> >> upstream library.
>> >
>> > Newtons fourth law: For every reviewer, there's an equal and opposite
>> > reviewer. :)
>> >
>> > Here I am, advocating a source code fix. As Thomas says, the compiler
>> > complaint seems reasonable, and disabling it might cause us to miss other
>> > future errors.
>> >
>> > Why can't we push the source code fix, and also submit it upstream?
>> >
>> > /Magnus
>> >
>> >
>> > I've looked at jpeg-9c and it still looks identical to what we have in
>> > 6b, so this code
>> > seems to have stood the test of time. I'm also unclear why the compiler
>> > would
>> > complain about that and not the one a few lines later
>> >
>> >
>> >  819   while (bits[i] == 0)          /* find largest codelength still in
>> > use */
>> >  820     i--;
>> >
>> > A push to jchuff.c will get blown away if/when we upgrade.
>> > A tool-chain specific fix in the makefile with an appropriate comment is
>> > more targeted.
>>
>> Phil,
>>
>> Returning to this.
>>
>> While I understand your reluctance to patch upstream code, let me point
>> out that we have not updated libjpeg a single time since the JDK was open
>> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page
>> on libjpeg, and this is the latest "uncontroversial" version of the source.
>> Versions 7 and up have proprietary extensions, which in turn has resulted in
>> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever
>> replace libjpeg 6b with a simple upgrade from upstream.
>>
>> I therefore maintain my position that a source code fix would be the best
>> way forward here.
>>
>> /Magnus
>>
>> >
>> >
>> > -phil.
>> >
>> >
>> > On 03/27/2018 05:44 AM, Thomas St?fe wrote:
>> >
>> > Hi all,
>> >
>> >
>> > just a friendly reminder. I would like to push this tiny fix because
>> > tripping over this on our linux s390x builds is annoying (yes, we can
>> > maintain patch queues, but this is a constant error source).
>> >
>> >
>> > I will wait for 24 more hours until a reaction. If no serious objections
>> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph
>> > langer are both Reviewers).
>> >
>> >
>> > Thanks! Thomas
>> >
>> >
>> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>> > wrote:
>> >
>> > Hi all,
>> >
>> >
>> > may I please have another review for this really trivial change. It
>> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix
>> > this.
>> >
>> >
>> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
>> > webrev:
>> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/
>> >
>> >
>> > This was contributed by Adam Farley at IBM.
>> >
>> >
>> > I already reviewed this. I also test-built on zlinux and it works.
>> >
>> >
>> > Thanks, Thomas
>> >
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>


From archana.nogriya at uk.ibm.com  Thu Apr 26 11:00:17 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Thu, 26 Apr 2018 12:00:17 +0100
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs 
Message-ID: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>

If we have a conditional variable to set "
hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately.

diff --git a/make/Main.gmk b/make/Main.gmk
index 731e9c9934..444a835cb4 100644
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -830,7 +830,8 @@ else
   docs-reference-api-modulegraph: exploded-image buildtools-modules
 
   # The gensrc steps for hotspot and jdk.jdi create html spec files.
-  docs-jdk-specs: jdk.jdi-gensrc \
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
       docs-jdk-index


######################################################################################

diff --git a/make/Docs.gmk b/make/Docs.gmk
index 644ffbf74a..73ffb8ebd2 100644
--- a/make/Docs.gmk
+++ b/make/Docs.gmk
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)
 
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical).
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
-    FILES := $(JVMTI_HTML), \
-    DEST := $(DOCS_OUTPUTDIR)/specs, \
-))
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
+    FILES := $(JVMTI_HTML), \
+    DEST := $(DOCS_OUTPUTDIR)/specs, \
+))
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
 
Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From thomas.stuefe at gmail.com  Thu Apr 26 14:03:52 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 16:03:52 +0200
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
Message-ID: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>

Hi all,

may I have reviews please:

https://bugs.openjdk.java.net/browse/JDK-8202325
http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-as-errors/webrev.00/webrev/

We decided to disable warnings as errors by default on AIX. This is a
pragmatic decision - we will never be able to fix all the many xlC
warnings and the build since long only worked when disabling
warnings-as-errors.

So, might as well make this the default.

Best regards, Thomas


From goetz.lindenmaier at sap.com  Thu Apr 26 14:12:59 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 26 Apr 2018 14:12:59 +0000
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
Message-ID: <3e3b9ca8c23b484381190901ed6af52f@sap.com>

Hi Thomas, 

this looks good and will simplify building on AIX.

Thanks,
  Goetz.

> -----Original Message-----
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Donnerstag, 26. April 2018 16:04
> To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net
> Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
> 
> Hi all,
> 
> may I have reviews please:
> 
> https://bugs.openjdk.java.net/browse/JDK-8202325
> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-
> as-errors/webrev.00/webrev/
> 
> We decided to disable warnings as errors by default on AIX. This is a
> pragmatic decision - we will never be able to fix all the many xlC
> warnings and the build since long only worked when disabling
> warnings-as-errors.
> 
> So, might as well make this the default.
> 
> Best regards, Thomas

From matthias.baesken at sap.com  Thu Apr 26 14:13:38 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 26 Apr 2018 14:13:38 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
Message-ID: <8361024dba4f44309292e73ec9ad7b83@sap.com>

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




From thomas.stuefe at gmail.com  Thu Apr 26 14:31:57 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 16:31:57 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
Message-ID: <CAA-vtUzAj+NgXDFMQn0=1D+1HNkeyyGWH+8rNpGChVEuMzUUQQ@mail.gmail.com>

Hi Matthias,

I would prefer a numerical comparison to version < 13. Otherwise the
code looks like you want to just exclude 12.1 for some reason when in
reality you want to omit the flag for any compiler older than xlc 13.

Best Regards, Thomas


On Thu, Apr 26, 2018 at 4:13 PM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> 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
>
>


From bhamaram at in.ibm.com  Thu Apr 26 14:32:04 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Thu, 26 Apr 2018 14:32:04 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
Message-ID: <OF8C121906.92A37793-ON0025827B.004FD768-0025827B.004FD771@notes.na.collabserv.com>

Hi Matthias,

Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to "-qvisibility=hidden" which hides all symbols by default. I workaround that by removing this flag

-bash-4.4$ xlC -qversion
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
Version: 13.01.0003.0000

Looks like there are many function declarations that require changes to make function visible.

Thanks,
Bhaktavatsal Reddy

  

-----"core-libs-dev" <core-libs-dev-bounces at openjdk.java.net> wrote: -----
To: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
From: "Baesken, Matthias" 
Sent by: "core-libs-dev" 
Date: 04/26/2018 07:45PM
Cc: "Simonis, Volker" <volker.simonis at 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://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=M4IJ-YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E&e=

Change :

https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Embaesken_webrevs_8202322_&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m=F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=gb0OP9fQTAWWJbBZDK6L_0gTKf1pwna8aXaYr_uVv8Q&e=


Best regards, Matthias





From matthias.baesken at sap.com  Thu Apr 26 14:37:17 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 26 Apr 2018 14:37:17 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <OF8C121906.92A37793-ON0025827B.004FD768-0025827B.004FD771@notes.na.collabserv.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <OF8C121906.92A37793-ON0025827B.004FD768-0025827B.004FD771@notes.na.collabserv.com>
Message-ID: <1ff5961701994081819d0bd7db3d3ec3@sap.com>


> Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to
> "-qvisibility=hidden" which hides all symbols by default. I workaround that by
> removing this flag

Hello,   so  it seems  that I  better  remove   the  "-qvisibility=<setting>"  completely  for xlc  (and not only for xlc12.1)   ?

(we currently  compile only  with XLC 12.1  ,   there might be more issues  with 13.1 )


Best regards, Matthias



> -----Original Message-----
> From: Bhaktavatsal R Maram [mailto:bhamaram at in.ibm.com]
> Sent: Donnerstag, 26. April 2018 16:32
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-
> port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Simonis,
> Volker <volker.simonis at sap.com>
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> Hi Matthias,
> 
> Its right in time. I am facing "Undefined Symbol" errors with XLC 13.1 due to
> "-qvisibility=hidden" which hides all symbols by default. I workaround that by
> removing this flag
> 
> -bash-4.4$ xlC -qversion
> IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
> Version: 13.01.0003.0000
> 
> Looks like there are many function declarations that require changes to make
> function visible.
> 
> Thanks,
> Bhaktavatsal Reddy
> 
> 
> 
> -----"core-libs-dev" <core-libs-dev-bounces at openjdk.java.net> wrote: -----
> To: "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-
> aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>,
> "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> From: "Baesken, Matthias"
> Sent by: "core-libs-dev"
> Date: 04/26/2018 07:45PM
> Cc: "Simonis, Volker" <volker.simonis at 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bugs.openjdk.java.net_browse_JDK-
> 2D8202322&d=DwIFAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m
> =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=M4IJ-
> YdB3dfN7lj0DEWozQbipDXmgKtSu3pEyMcJF_E&e=
> 
> Change :
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cr.openjdk.java.net_-
> 7Embaesken_webrevs_8202322_&d=DwIFAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=KUVGEwJiRVpNtQ9wUhGP6BKqzSTV1OWX31WWPdQMmqg&m
> =F6_aATE7bsRWZG5lPZhJUESHNGqST5MNbkULllIH8l4&s=gb0OP9fQTAWWJb
> BZDK6L_0gTKf1pwna8aXaYr_uVv8Q&e=
> 
> 
> Best regards, Matthias
> 
> 


From christoph.langer at sap.com  Thu Apr 26 14:38:04 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 26 Apr 2018 14:38:04 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
Message-ID: <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>

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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at 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




From matthias.baesken at sap.com  Thu Apr 26 14:52:34 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 26 Apr 2018 14:52:34 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
Message-ID: <97c60ab29a6348769169b312f55832e7@sap.com>

Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and probably not working anyway)  for the OpenJDK  build .

I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of 13.1  "might" work   for OpenJDK compilation .

And for 12.1  I want to remove the flags  .



( waiting for the feedback  of  Bhaktavatsal Reddy ,  in case he  prefers it  I remove them for all xlC versions including 13.1 )

Best regards, Matthias



From: Langer, Christoph
Sent: Donnerstag, 26. April 2018 16:38
To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>>; ppc-aix-port-dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Simonis, Volker <volker.simonis at sap.com<mailto:volker.simonis at 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




From bhamaram at in.ibm.com  Thu Apr 26 14:59:14 2018
From: bhamaram at in.ibm.com (Bhaktavatsal R Maram)
Date: Thu, 26 Apr 2018 14:59:14 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <97c60ab29a6348769169b312f55832e7@sap.com>
References: <97c60ab29a6348769169b312f55832e7@sap.com>,
 <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
Message-ID: <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>

Hi Matthias,

At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag.

Thanks,
Bhaktavatsal Reddy

  

-----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
From: "Baesken, Matthias" <matthias.baesken at sap.com>
Date: 04/26/2018 08:23PM
Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R Maram	<bhamaram at in.ibm.com>
Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

       
 Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and probably not working anyway)  for the OpenJDK  build .
 I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of 13.1  ?might? work   for OpenJDK compilation .
 And for 12.1  I want to remove the flags  .
  
 ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it  I remove them for all xlC versions including 13.1 )
  
 Best regards, Matthias
  
  
  
 
 
 
 From: Langer, Christoph 
 Sent: Donnerstag, 26. April 2018 16:38
 To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
 Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
 Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at 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
  
  
      



From volker.simonis at gmail.com  Thu Apr 26 15:16:45 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Apr 2018 17:16:45 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
Message-ID: <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>

Hi Matthias,

after Bhaktavatsal Reddy's report about the problems with
"-qvisibility" with xlC 13 and taking into account that we can't test
this anyway because we don't currently have xlC 13
 on our machines I think it would be best to completely remove this
option for now on AIX. Once we get xlC 13 we can revisit the issue.

Thanks,
Volker


On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
<bhamaram at in.ibm.com> wrote:
> Hi Matthias,
>
> At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag.
>
> Thanks,
> Bhaktavatsal Reddy
>
>
>
> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> From: "Baesken, Matthias" <matthias.baesken at sap.com>
> Date: 04/26/2018 08:23PM
> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R Maram    <bhamaram at in.ibm.com>
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>
>
>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and probably not working anyway)  for the OpenJDK  build .
>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of 13.1  ?might? work   for OpenJDK compilation .
>  And for 12.1  I want to remove the flags  .
>
>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it  I remove them for all xlC versions including 13.1 )
>
>  Best regards, Matthias
>
>
>
>
>
>
>  From: Langer, Christoph
>  Sent: Donnerstag, 26. April 2018 16:38
>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at 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
>
>
>
>


From erik.joelsson at oracle.com  Thu Apr 26 15:55:24 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 08:55:24 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
Message-ID: <0754ee5c-911c-8f1c-d377-afc87743e644@oracle.com>

Build looks good, thanks.

/Erik


On 2018-04-25 21:34, Jiangli Zhou wrote:
> Here is the incremental webrev with updates that incorporate all feedbacks:
> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>
> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
> - Removed UseAppCDS.java test.
> - Removed UseAppCDS in various tests.
> - Changed to keep the original version of the classlist and renamed to classlist.raw.
> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>
> Full webrev:
> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>
> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>
> Thanks for all the suggestions!
>
> Jiangli
>
>
>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>
>> Hi David,
>>
>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Jiangli,
>>>
>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>> Hi David,
>>>> Thanks a lot for the review!
>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> cc'ing build-dev for the makefile change
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>> These issues are not publicly visible, can you change them to be so?
>>>> Done. Thanks for noticing that!
>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>
>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>> Right, that was part of the intention.
>>
>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>> That sounds reasonable.
>>
>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>> Ok. I?ll remove the flag from the tests.
>>
>> Thanks!
>>
>> Jiangli
>>
>>> Thanks,
>>> David
>>>
>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>
>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>> Test 4 seems unnecessary now.
>>>> Will do.
>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>
>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>> Ok.
>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>
>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>> Thanks!
>>>> Jiangli
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Highlights of the changes:
>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>> Following are the details for the VM and test changes:
>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>> Thanks,
>>>>>> Jiangli



From erik.joelsson at oracle.com  Thu Apr 26 15:57:41 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 08:57:41 -0700
Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with
 Visual Studio 2013 (VS2013)
In-Reply-To: <31e018fb-074b-041f-05fb-b61e882fb619@oracle.com>
References: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com>
 <e740840c-336d-4563-07f8-4b4cb9e32d8b@oracle.com>
 <31e018fb-074b-041f-05fb-b61e882fb619@oracle.com>
Message-ID: <34c5e1e8-218b-8008-445a-fecb6fcbcc90@oracle.com>

Looks good.

/Erik


On 2018-04-26 01:38, Kevin Walls wrote:
>
> Thanks Erik -
>
> I went ahead with the jdk's make/CopyFiles.gmk change, and added 
> SetupCopyFiles to the base repo's make/common/MakeBase.gmk.
>
> I updated the webrev, to include base and jdk repos:
>
> http://cr.openjdk.java.net/~kevinw/8042707/webrev.01/
>
> I'm getting these build OK with VS2012, but there will be further 
> hotspot change at least for VS2013 to be a working option in 8u.
>
> Thanks
> Kevin
> (my previous reply was not the the list, so this is the open response!)
>
>
>
> On 20/04/2018 23:27, Erik Joelsson wrote:
>> The root repo changes look ok.
>>
>> The changes in Copy-java.base.gmk applies to jdk/make/CopyFiles.gmk. 
>> Those changes are definitely needed.
>>
>> /Erik
>>
>>
>> On 2018-04-20 13:18, Kevin Walls wrote:
>>> Hi,
>>>
>>> I'd like to request a review of the backport from 9 to 8u:
>>>
>>> 8042707: Source changes needed to build JDK 9 with Visual Studio 
>>> 2013 (VS2013)
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8042707
>>>
>>> 9 changesets:
>>> base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890
>>> jdk repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad
>>>
>>> 9 review thread: 
>>> http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html
>>>
>>>
>>> Notes:
>>> base repo:
>>> toolchain_windows.m4: quite a bit of manual work, but no conflicts.
>>> make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't 
>>> have in 8u
>>> flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the 
>>> same change.
>>>
>>> jdk repo:
>>> make/copy/Copy-java.base.gmk we don't have in 8u. The other two 
>>> files apply cleanly.
>>>
>>>
>>> Clearly this backport isn't to change anything about what compilers 
>>> are supported or recommended,
>>> it's just about the build infrastructure.
>>>
>>>
>>> 8u change: webrev of the base repo changes:
>>> http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/
>>>
>>> Many thanks
>>> Kevin
>>>
>>
>



From erik.joelsson at oracle.com  Thu Apr 26 16:03:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 09:03:39 -0700
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
 <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
Message-ID: <4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>

Should linking to the -lkstat library be conditional on jfr feature 
being set, or perhaps it doesn't matter that much. In that case, adding 
the library could be done in JvmFeatures.gmk instead.

/Erik


On 2018-04-26 02:45, Magnus Ihse Bursie wrote:
>
> On 2018-04-25 13:06, Erik Gahlin wrote:
>> Greetings,
>>
>> Could I have a review of 8199712: Flight Recorder
>>
>> As mentioned in the preview [1] the tracing backend has been removed. 
>> Event metadata has been consolidated into a single XML file and event 
>> classes are now generated by GenerateJfrFiles.java.
>>
>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>
>> For details about the feature, see the JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8199712.0/
> Hi Erik,
>
> When posting build changes (files in "make/*"), please always include 
> build-dev. Thanks! :-)
>
> This review is for build changes only.
>
> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year 
> change. It can be reverted.
>
> * make/copy/Copy-jdk.jfr.gmk:
> COPY_HOTSPOT_TRACE_FILES should be renamed to something like 
> COPY_JFR_METADATA.
>
> The second part is better off rewritten using SetupCopyFiles.
>
> Something like this, written on-the-fly, so might not work. (Email me 
> privately if it does not work and you need help.)
>
> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>
> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
> ? DEST := $(LIB_DST_DIR)/jfr, \
> ? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
> ? FLATTEN := true, \
> ))
>
> TARGETS += $(COPY_JFR_CONF)
>
> * make/autoconf/hotspot.m4:
> It's a bit unfortunate with the --enable-jfr option. Ideally, this 
> should be handled only as a JVM feature (--with-jvm-features=jfr). Try 
> this piece of code instead: (Not tested, but should work.)
>
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -26,7 +26,7 @@
> ?# All valid JVM features, regardless of platform
> ?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti 
> jvmci \
> ???? graal vm-structs jni-check services management all-gcs nmt cds \
> -??? static-build link-time-opt aot"
> +??? static-build link-time-opt aot jfr"
>
> ?# All valid JVM variants
> ?VALID_JVM_VARIANTS="server client minimal core zero custom"
> @@ -313,6 +313,11 @@
> ???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature 
> 'all-gcs'])
> ?? fi
>
> +? # Enable JFR by default, except on linux-sparcv9 and on minimal.
> +? if test "x$OPENJDK_TARGET_OS" != xlinux || test 
> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
> +??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
> +? fi
> +
> ?? # Turn on additional features based on other parts of configure
> ?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
> ???? JVM_FEATURES="$JVM_FEATURES dtrace"
>
> Otherwise, build changes look good!
>
> /Magnus
>
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>
>> Thanks
>> Erik and Markus
>



From vladimir.kozlov at oracle.com  Thu Apr 26 16:07:12 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 26 Apr 2018 09:07:12 -0700
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
 <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
 <4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>
Message-ID: <1f750f87-057b-62b4-d434-d38e5afdc219@oracle.com>

-lkstat was also used to determine SPARC CPU features as I remember.

Vladimir

On 4/26/18 9:03 AM, Erik Joelsson wrote:
> Should linking to the -lkstat library be conditional on jfr feature 
> being set, or perhaps it doesn't matter that much. In that case, adding 
> the library could be done in JvmFeatures.gmk instead.
> 
> /Erik
> 
> 
> On 2018-04-26 02:45, Magnus Ihse Bursie wrote:
>>
>> On 2018-04-25 13:06, Erik Gahlin wrote:
>>> Greetings,
>>>
>>> Could I have a review of 8199712: Flight Recorder
>>>
>>> As mentioned in the preview [1] the tracing backend has been removed. 
>>> Event metadata has been consolidated into a single XML file and event 
>>> classes are now generated by GenerateJfrFiles.java.
>>>
>>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>>
>>> For details about the feature, see the JEP:
>>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~egahlin/8199712.0/
>> Hi Erik,
>>
>> When posting build changes (files in "make/*"), please always include 
>> build-dev. Thanks! :-)
>>
>> This review is for build changes only.
>>
>> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year 
>> change. It can be reverted.
>>
>> * make/copy/Copy-jdk.jfr.gmk:
>> COPY_HOTSPOT_TRACE_FILES should be renamed to something like 
>> COPY_JFR_METADATA.
>>
>> The second part is better off rewritten using SetupCopyFiles.
>>
>> Something like this, written on-the-fly, so might not work. (Email me 
>> privately if it does not work and you need help.)
>>
>> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>>
>> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
>> ? DEST := $(LIB_DST_DIR)/jfr, \
>> ? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
>> ? FLATTEN := true, \
>> ))
>>
>> TARGETS += $(COPY_JFR_CONF)
>>
>> * make/autoconf/hotspot.m4:
>> It's a bit unfortunate with the --enable-jfr option. Ideally, this 
>> should be handled only as a JVM feature (--with-jvm-features=jfr). Try 
>> this piece of code instead: (Not tested, but should work.)
>>
>> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
>> --- a/make/autoconf/hotspot.m4
>> +++ b/make/autoconf/hotspot.m4
>> @@ -26,7 +26,7 @@
>> ?# All valid JVM features, regardless of platform
>> ?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti 
>> jvmci \
>> ???? graal vm-structs jni-check services management all-gcs nmt cds \
>> -??? static-build link-time-opt aot"
>> +??? static-build link-time-opt aot jfr"
>>
>> ?# All valid JVM variants
>> ?VALID_JVM_VARIANTS="server client minimal core zero custom"
>> @@ -313,6 +313,11 @@
>> ???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature 
>> 'all-gcs'])
>> ?? fi
>>
>> +? # Enable JFR by default, except on linux-sparcv9 and on minimal.
>> +? if test "x$OPENJDK_TARGET_OS" != xlinux || test 
>> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
>> +??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
>> +? fi
>> +
>> ?? # Turn on additional features based on other parts of configure
>> ?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
>> ???? JVM_FEATURES="$JVM_FEATURES dtrace"
>>
>> Otherwise, build changes look good!
>>
>> /Magnus
>>
>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>>
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html 
>>>
>>>
>>> Thanks
>>> Erik and Markus
>>
> 


From erik.joelsson at oracle.com  Thu Apr 26 16:08:29 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 09:08:29 -0700
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
Message-ID: <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>

Looks reasonable.

/Erik


On 2018-04-26 04:00, Archana Nogriya wrote:
> If we have a conditional variable to set 
> "hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
> alternate VMs like eclipse openj9 to extend that to set it appropriately.
>
> diff --git a/make/Main.gmk b/make/Main.gmk
> index 731e9c9934..444a835cb4 100644
> --- a/make/Main.gmk
> +++ b/make/Main.gmk
> @@ -830,7 +830,8 @@ else
> ?docs-reference-api-modulegraph: exploded-image buildtools-modules
>
> ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files.
> - ?docs-jdk-specs: jdk.jdi-gensrc \
> + ?JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
> + ?docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
> ? ?docs-jdk-index
>
>
> ###################################################################################### 
>
>
> diff --git a/make/Docs.gmk b/make/Docs.gmk
> index 644ffbf74a..73ffb8ebd2 100644
> --- a/make/Docs.gmk
> +++ b/make/Docs.gmk
> @@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
> ?JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)
>
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Note: This proposal has been tested in local.
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: archana.nogriya at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From erik.joelsson at oracle.com  Thu Apr 26 16:09:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 09:09:36 -0700
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
Message-ID: <ea2fb067-aa71-9ae2-7cb3-7d43ecfd9c3a@oracle.com>

Looks good.

/Erik


On 2018-04-26 07:03, Thomas St?fe wrote:
> Hi all,
>
> may I have reviews please:
>
> https://bugs.openjdk.java.net/browse/JDK-8202325
> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-as-errors/webrev.00/webrev/
>
> We decided to disable warnings as errors by default on AIX. This is a
> pragmatic decision - we will never be able to fix all the many xlC
> warnings and the build since long only worked when disabling
> warnings-as-errors.
>
> So, might as well make this the default.
>
> Best regards, Thomas



From erik.joelsson at oracle.com  Thu Apr 26 16:11:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 09:11:28 -0700
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <8361024dba4f44309292e73ec9ad7b83@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
Message-ID: <9637d378-1e49-df96-ccc7-b01efcbc9929@oracle.com>

Looks ok.

/Erik


On 2018-04-26 07:13, Baesken, Matthias wrote:
> 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
>
>



From thomas.stuefe at gmail.com  Thu Apr 26 17:02:55 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 17:02:55 +0000
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <ea2fb067-aa71-9ae2-7cb3-7d43ecfd9c3a@oracle.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
 <ea2fb067-aa71-9ae2-7cb3-7d43ecfd9c3a@oracle.com>
Message-ID: <CAA-vtUwc4rZQSwuxW0cCQWKUDJzw=FFkivUu3KwEYbrRPrOE6g@mail.gmail.com>

Thanks Erik!

On Thu, Apr 26, 2018, 18:09 Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Looks good.
>
> /Erik
>
>
> On 2018-04-26 07:03, Thomas St?fe wrote:
> > Hi all,
> >
> > may I have reviews please:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8202325
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-as-errors/webrev.00/webrev/
> >
> > We decided to disable warnings as errors by default on AIX. This is a
> > pragmatic decision - we will never be able to fix all the many xlC
> > warnings and the build since long only worked when disabling
> > warnings-as-errors.
> >
> > So, might as well make this the default.
> >
> > Best regards, Thomas
>
>


From thomas.stuefe at gmail.com  Thu Apr 26 17:03:17 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 17:03:17 +0000
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <3e3b9ca8c23b484381190901ed6af52f@sap.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
 <3e3b9ca8c23b484381190901ed6af52f@sap.com>
Message-ID: <CAA-vtUwht4mPComCFuBLB4JLE2CCUDviWU50cBudXp9qFW_XTQ@mail.gmail.com>

Thank you Goetz!

On Thu, Apr 26, 2018, 16:13 Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
wrote:

> Hi Thomas,
>
> this looks good and will simplify building on AIX.
>
> Thanks,
>   Goetz.
>
> > -----Original Message-----
> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> > bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> > Sent: Donnerstag, 26. April 2018 16:04
> > To: build-dev <build-dev at openjdk.java.net>; ppc-aix-port-
> > dev at openjdk.java.net
> > Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
> >
> > Hi all,
> >
> > may I have reviews please:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8202325
> > http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-
> > as-errors/webrev.00/webrev/
> >
> > We decided to disable warnings as errors by default on AIX. This is a
> > pragmatic decision - we will never be able to fix all the many xlC
> > warnings and the build since long only worked when disabling
> > warnings-as-errors.
> >
> > So, might as well make this the default.
> >
> > Best regards, Thomas
>


From calvin.cheung at oracle.com  Thu Apr 26 17:10:47 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 26 Apr 2018 10:10:47 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
Message-ID: <5AE20817.3060004@oracle.com>



On 4/25/18, 9:34 PM, Jiangli Zhou wrote:
> Here is the incremental webrev with updates that incorporate all feedbacks:
> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
Looks good.
>
> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
To address David's comment on checking the result of -Xshare:dump, you 
can replace
52         out.shouldContain("Dumping");

with
              TestCommon.checkDump(out);

checkDump() contains the following check:
     output.shouldContain("Loading classes to share");

No need to generate another webrev if you make the above change.
> - Removed UseAppCDS.java test.
Since you've removed the UseAppCDS.java, I think the UseAppCDS_Test.java 
should also be removed.
It would involve changing the GraalWithLimitedMetaspace.java; the test 
could just use the test-classes/Hello.java instead of UseAppCDS_Test.java.
This cleanup can be done later, perhaps as part of the bug you've filed.
> - Removed UseAppCDS in various tests.
> - Changed to keep the original version of the classlist and renamed to classlist.raw.
> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>
> Full webrev:
> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
I think the correct URL is: 
http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.02/ ?

thanks,
Calvin
>
> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>
> Thanks for all the suggestions!
>
> Jiangli
>
>
>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou<jiangli.zhou at Oracle.COM>  wrote:
>>
>> Hi David,
>>
>>> On Apr 25, 2018, at 3:12 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>>
>>> Hi Jiangli,
>>>
>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>> Hi David,
>>>> Thanks a lot for the review!
>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>>>>
>>>>> cc'ing build-dev for the makefile change
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>> These issues are not publicly visible, can you change them to be so?
>>>> Done. Thanks for noticing that!
>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>
>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>> Right, that was part of the intention.
>>
>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>> That sounds reasonable.
>>
>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>> Ok. I?ll remove the flag from the tests.
>>
>> Thanks!
>>
>> Jiangli
>>
>>> Thanks,
>>> David
>>>
>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>
>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>> Test 4 seems unnecessary now.
>>>> Will do.
>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>
>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>> Ok.
>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>
>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>> Thanks!
>>>> Jiangli
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Highlights of the changes:
>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>> Following are the details for the VM and test changes:
>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>> Thanks,
>>>>>> Jiangli


From magnus.ihse.bursie at oracle.com  Thu Apr 26 17:26:59 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Apr 2018 19:26:59 +0200
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
Message-ID: <6616C64E-7C1B-4614-929C-4D270F2FC724@oracle.com>

Sounds reasonable. 

The code look good but the comment "Do not change default value." seems to be more of a comment on the removed code, so I think it just looks confusing without adding anything of real value in the resulting code. Maybe rephrase "default is already set" or so, or just delete?

/Magnus

> 26 apr. 2018 kl. 16:03 skrev Thomas St?fe <thomas.stuefe at gmail.com>:
> 
> Hi all,
> 
> may I have reviews please:
> 
> https://bugs.openjdk.java.net/browse/JDK-8202325
> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-as-errors/webrev.00/webrev/
> 
> We decided to disable warnings as errors by default on AIX. This is a
> pragmatic decision - we will never be able to fix all the many xlC
> warnings and the build since long only worked when disabling
> warnings-as-errors.
> 
> So, might as well make this the default.
> 
> Best regards, Thomas



From jiangli.zhou at oracle.com  Thu Apr 26 18:20:05 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 26 Apr 2018 11:20:05 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <e36bd45e-a7d2-d682-66d0-c1707b405767@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <e36bd45e-a7d2-d682-66d0-c1707b405767@oracle.com>
Message-ID: <13E80BF1-2694-4F5B-A39E-B53FB1EA7BD6@oracle.com>


> On Apr 25, 2018, at 10:09 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 26/04/2018 2:34 PM, Jiangli Zhou wrote:
>> Here is the incremental webrev with updates that incorporate all feedbacks:
>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
> 
> Looks good.

Thanks!

> 
> One additional comment on test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems insufficient to just check the output for the word "dump". I would expect to see something more definitively associated with -Xshare:dump and also a check that it exited cleanly (in case we find "core dump?).

With other test cases being removed from appcds/SharedArchiveFile.java, I just realized that the test now essentially is the same as the jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java test. SharedArchiveFile/SharedArchiveFile.java includes more robust checks as you suggested and also tests runtime. Your comments above (and fresh morning coffee) reminded me that. :-) So I went ahead removed the appcds/SharedArchiveFile.java. Please let me know if you want to see the new webrev.

Thanks!
Jiangli

> 
> Thanks,
> David
> -----
> 
>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>> - Removed UseAppCDS.java test.
>> - Removed UseAppCDS in various tests.
>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>> Full webrev:
>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>> Thanks for all the suggestions!
>> Jiangli
>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>> 
>>> Hi David,
>>> 
>>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> Hi Jiangli,
>>>> 
>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>> Hi David,
>>>>> Thanks a lot for the review!
>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> 
>>>>>> cc'ing build-dev for the makefile change
>>>>>> 
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>> 
>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>> Done. Thanks for noticing that!
>>>>>> 
>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>> 
>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>> 
>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>> 
>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>> 
>>> Right, that was part of the intention.
>>> 
>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>> 
>>> That sounds reasonable.
>>> 
>>>> 
>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>> 
>>> Ok. I?ll remove the flag from the tests.
>>> 
>>> Thanks!
>>> 
>>> Jiangli
>>> 
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>>> 
>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>> 
>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>> Test 4 seems unnecessary now.
>>>>> Will do.
>>>>>> 
>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>> 
>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>> Ok.
>>>>>> 
>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>> 
>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>> Thanks!
>>>>> Jiangli
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>>> Highlights of the changes:
>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>> Following are the details for the VM and test changes:
>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>> Thanks,
>>>>>>> Jiangli
>>> 



From jiangli.zhou at oracle.com  Thu Apr 26 18:40:50 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 26 Apr 2018 11:40:50 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <0754ee5c-911c-8f1c-d377-afc87743e644@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <0754ee5c-911c-8f1c-d377-afc87743e644@oracle.com>
Message-ID: <C023E868-5234-4F38-9614-C65485CF2A4B@oracle.com>

Thanks, Magnus and Erik!

Jiangli

> On Apr 26, 2018, at 8:55 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Build looks good, thanks.
> 
> /Erik
> 
> 
> On 2018-04-25 21:34, Jiangli Zhou wrote:
>> Here is the incremental webrev with updates that incorporate all feedbacks:
>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>> 
>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>> - Removed UseAppCDS.java test.
>> - Removed UseAppCDS in various tests.
>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>> 
>> Full webrev:
>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>> 
>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>> 
>> Thanks for all the suggestions!
>> 
>> Jiangli
>> 
>> 
>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>> 
>>> Hi David,
>>> 
>>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> Hi Jiangli,
>>>> 
>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>> Hi David,
>>>>> Thanks a lot for the review!
>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> 
>>>>>> cc'ing build-dev for the makefile change
>>>>>> 
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>> Done. Thanks for noticing that!
>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>> 
>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>> Right, that was part of the intention.
>>> 
>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>> That sounds reasonable.
>>> 
>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>> Ok. I?ll remove the flag from the tests.
>>> 
>>> Thanks!
>>> 
>>> Jiangli
>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>> 
>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>> Test 4 seems unnecessary now.
>>>>> Will do.
>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>> 
>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>> Ok.
>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>> 
>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>> Thanks!
>>>>> Jiangli
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>>> Highlights of the changes:
>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>> Following are the details for the VM and test changes:
>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>> Thanks,
>>>>>>> Jiangli
> 



From thomas.stuefe at gmail.com  Thu Apr 26 18:51:36 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 26 Apr 2018 20:51:36 +0200
Subject: RFR(xs): 8202325: [aix] disable warnings-as-errors by default
In-Reply-To: <6616C64E-7C1B-4614-929C-4D270F2FC724@oracle.com>
References: <CAA-vtUy+1arr-LmBXyytzqjgaHBTwnN=FWoyCQMJmSiBGvKE-A@mail.gmail.com>
 <6616C64E-7C1B-4614-929C-4D270F2FC724@oracle.com>
Message-ID: <CAA-vtUwqFM+sEEaUJappkk17EwhLKUK16f11Bosd-ROvKcN1SA@mail.gmail.com>

Hi Magnus,

I think I'll just delete the comment. Thanks for the review!

Thanks, Thomas

On Thu, Apr 26, 2018 at 7:26 PM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> Sounds reasonable.
>
> The code look good but the comment "Do not change default value." seems to be more of a comment on the removed code, so I think it just looks confusing without adding anything of real value in the resulting code. Maybe rephrase "default is already set" or so, or just delete?
>
> /Magnus
>
>> 26 apr. 2018 kl. 16:03 skrev Thomas St?fe <thomas.stuefe at gmail.com>:
>>
>> Hi all,
>>
>> may I have reviews please:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8202325
>> http://cr.openjdk.java.net/~stuefe/webrevs/8202325-aix-disable-warnings-as-errors/webrev.00/webrev/
>>
>> We decided to disable warnings as errors by default on AIX. This is a
>> pragmatic decision - we will never be able to fix all the many xlC
>> warnings and the build since long only worked when disabling
>> warnings-as-errors.
>>
>> So, might as well make this the default.
>>
>> Best regards, Thomas
>


From jiangli.zhou at oracle.com  Thu Apr 26 19:00:21 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 26 Apr 2018 12:00:21 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <5AE20817.3060004@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <5AE20817.3060004@oracle.com>
Message-ID: <63A3EA81-F6CB-4691-AC73-0E2863DB2E75@oracle.com>

Hi Calvin,

> On Apr 26, 2018, at 10:10 AM, Calvin Cheung <calvin.cheung at oracle.com> wrote:
> 
> 
> 
> On 4/25/18, 9:34 PM, Jiangli Zhou wrote:
>> Here is the incremental webrev with updates that incorporate all feedbacks:
>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
> Looks good.

Thanks!

>> 
>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
> To address David's comment on checking the result of -Xshare:dump, you can replace
> 52         out.shouldContain("Dumping");
> 
> with
>             TestCommon.checkDump(out);
> 
> checkDump() contains the following check:
>    output.shouldContain("Loading classes to share");
> 
> No need to generate another webrev if you make the above change.

I removed appcds/SharedArchiveFile.java (please see my reply to David for details).

>> - Removed UseAppCDS.java test.
> Since you've removed the UseAppCDS.java, I think the UseAppCDS_Test.java should also be removed.
> It would involve changing the GraalWithLimitedMetaspace.java; the test could just use the test-classes/Hello.java instead of UseAppCDS_Test.java.
> This cleanup can be done later, perhaps as part of the bug you've filed.

Could you please specify the connection between UseAppCDS.java and UseAppCDS_Test.java?

>> - Removed UseAppCDS in various tests.
>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>> 
>> Full webrev:
>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
> I think the correct URL is: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.02/ ?

Yes.

Thanks!

Jiangli

> 
> thanks,
> Calvin
>> 
>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>> 
>> Thanks for all the suggestions!
>> 
>> Jiangli
>> 
>> 
>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou<jiangli.zhou at Oracle.COM>  wrote:
>>> 
>>> Hi David,
>>> 
>>>> On Apr 25, 2018, at 3:12 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>>> 
>>>> Hi Jiangli,
>>>> 
>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>> Hi David,
>>>>> Thanks a lot for the review!
>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>>>>> 
>>>>>> cc'ing build-dev for the makefile change
>>>>>> 
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>> Done. Thanks for noticing that!
>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>> 
>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>> Right, that was part of the intention.
>>> 
>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>> That sounds reasonable.
>>> 
>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>> Ok. I?ll remove the flag from the tests.
>>> 
>>> Thanks!
>>> 
>>> Jiangli
>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>> 
>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>> Test 4 seems unnecessary now.
>>>>> Will do.
>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>> 
>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>> Ok.
>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>> 
>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>> Thanks!
>>>>> Jiangli
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>>> Highlights of the changes:
>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>> Following are the details for the VM and test changes:
>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>> Thanks,
>>>>>>> Jiangli



From calvin.cheung at oracle.com  Thu Apr 26 19:21:19 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Thu, 26 Apr 2018 12:21:19 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <63A3EA81-F6CB-4691-AC73-0E2863DB2E75@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <5AE20817.3060004@oracle.com>
 <63A3EA81-F6CB-4691-AC73-0E2863DB2E75@oracle.com>
Message-ID: <5AE226AF.3010902@oracle.com>



On 4/26/18, 12:00 PM, Jiangli Zhou wrote:
> Hi Calvin,
>
>> On Apr 26, 2018, at 10:10 AM, Calvin Cheung<calvin.cheung at oracle.com>  wrote:
>>
>>
>>
>> On 4/25/18, 9:34 PM, Jiangli Zhou wrote:
>>> Here is the incremental webrev with updates that incorporate all feedbacks:
>>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>> Looks good.
> Thanks!
>
>>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>> To address David's comment on checking the result of -Xshare:dump, you can replace
>> 52         out.shouldContain("Dumping");
>>
>> with
>>              TestCommon.checkDump(out);
>>
>> checkDump() contains the following check:
>>     output.shouldContain("Loading classes to share");
>>
>> No need to generate another webrev if you make the above change.
> I removed appcds/SharedArchiveFile.java (please see my reply to David for details).
>
>>> - Removed UseAppCDS.java test.
>> Since you've removed the UseAppCDS.java, I think the UseAppCDS_Test.java should also be removed.
>> It would involve changing the GraalWithLimitedMetaspace.java; the test could just use the test-classes/Hello.java instead of UseAppCDS_Test.java.
>> This cleanup can be done later, perhaps as part of the bug you've filed.
> Could you please specify the connection between UseAppCDS.java and UseAppCDS_Test.java?
UseAppCDS.java dump the classlist by running the UseAppCDS_Test.
It then creates an archive based on the classlist.
It then runs the UseAppCDS_Test with the archive.

The UseAppCDS_Test simply does the following:
public class UseAppCDS_Test {
     // args are from UseAppCDS:
     // args[0] = TEST_OUT
     public static void main(String[] args) {
         System.out.println(args[0]);
     }
}

GraalWithLimitedMetaspace.java depends on UseAppCDS_Test in a similar 
way but it only performs dumping.

thanks,
Calvin
>
>>> - Removed UseAppCDS in various tests.
>>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>>>
>>> Full webrev:
>>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>> I think the correct URL is: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.02/ ?
> Yes.
>
> Thanks!
>
> Jiangli
>
>> thanks,
>> Calvin
>>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>>>
>>> Thanks for all the suggestions!
>>>
>>> Jiangli
>>>
>>>
>>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou<jiangli.zhou at Oracle.COM>   wrote:
>>>>
>>>> Hi David,
>>>>
>>>>> On Apr 25, 2018, at 3:12 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>>> Hi David,
>>>>>> Thanks a lot for the review!
>>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>>>>>
>>>>>>> cc'ing build-dev for the makefile change
>>>>>>>
>>>>>>> Hi Jiangli,
>>>>>>>
>>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>>> Done. Thanks for noticing that!
>>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>>>
>>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>>> Right, that was part of the intention.
>>>>
>>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>>> That sounds reasonable.
>>>>
>>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>>> Ok. I?ll remove the flag from the tests.
>>>>
>>>> Thanks!
>>>>
>>>> Jiangli
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>>>
>>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>>> Test 4 seems unnecessary now.
>>>>>> Will do.
>>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>>>
>>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>>> Ok.
>>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>>>
>>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>>> Thanks!
>>>>>> Jiangli
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Highlights of the changes:
>>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>>> Following are the details for the VM and test changes:
>>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>>> Thanks,
>>>>>>>> Jiangli


From jiangli.zhou at oracle.com  Thu Apr 26 19:40:06 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Thu, 26 Apr 2018 12:40:06 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <5AE226AF.3010902@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <5AE20817.3060004@oracle.com>
 <63A3EA81-F6CB-4691-AC73-0E2863DB2E75@oracle.com>
 <5AE226AF.3010902@oracle.com>
Message-ID: <0DC16187-3EB7-42B0-AFBD-585BF15C146D@oracle.com>


> On Apr 26, 2018, at 12:21 PM, Calvin Cheung <calvin.cheung at oracle.com> wrote:
> 
> 
> 
> On 4/26/18, 12:00 PM, Jiangli Zhou wrote:
>> Hi Calvin,
>> 
>>> On Apr 26, 2018, at 10:10 AM, Calvin Cheung<calvin.cheung at oracle.com>  wrote:
>>> 
>>> 
>>> 
>>> On 4/25/18, 9:34 PM, Jiangli Zhou wrote:
>>>> Here is the incremental webrev with updates that incorporate all feedbacks:
>>>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>>> Looks good.
>> Thanks!
>> 
>>>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>>>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>>> To address David's comment on checking the result of -Xshare:dump, you can replace
>>> 52         out.shouldContain("Dumping");
>>> 
>>> with
>>>             TestCommon.checkDump(out);
>>> 
>>> checkDump() contains the following check:
>>>    output.shouldContain("Loading classes to share");
>>> 
>>> No need to generate another webrev if you make the above change.
>> I removed appcds/SharedArchiveFile.java (please see my reply to David for details).
>> 
>>>> - Removed UseAppCDS.java test.
>>> Since you've removed the UseAppCDS.java, I think the UseAppCDS_Test.java should also be removed.
>>> It would involve changing the GraalWithLimitedMetaspace.java; the test could just use the test-classes/Hello.java instead of UseAppCDS_Test.java.
>>> This cleanup can be done later, perhaps as part of the bug you've filed.
>> Could you please specify the connection between UseAppCDS.java and UseAppCDS_Test.java?
> UseAppCDS.java dump the classlist by running the UseAppCDS_Test.
> It then creates an archive based on the classlist.
> It then runs the UseAppCDS_Test with the archive.
> 
> The UseAppCDS_Test simply does the following:
> public class UseAppCDS_Test {
>    // args are from UseAppCDS:
>    // args[0] = TEST_OUT
>    public static void main(String[] args) {
>        System.out.println(args[0]);
>    }
> }
> 
> GraalWithLimitedMetaspace.java depends on UseAppCDS_Test in a similar way but it only performs dumping.

Ok, since GraalWithLimitedMetaspace.java still uses UseAppCDS_Test.java, it is better to keep it for now. 

Thanks,
Jiangli

> 
> thanks,
> Calvin
>> 
>>>> - Removed UseAppCDS in various tests.
>>>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>>>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>>>> 
>>>> Full webrev:
>>>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>>> I think the correct URL is: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.02/ ?
>> Yes.
>> 
>> Thanks!
>> 
>> Jiangli
>> 
>>> thanks,
>>> Calvin
>>>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>>>> 
>>>> Thanks for all the suggestions!
>>>> 
>>>> Jiangli
>>>> 
>>>> 
>>>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou<jiangli.zhou at Oracle.COM>   wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>>> On Apr 25, 2018, at 3:12 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>>>> 
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>>>> Hi David,
>>>>>>> Thanks a lot for the review!
>>>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>>>>>> 
>>>>>>>> cc'ing build-dev for the makefile change
>>>>>>>> 
>>>>>>>> Hi Jiangli,
>>>>>>>> 
>>>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>>>> Done. Thanks for noticing that!
>>>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>>>> 
>>>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>>>> Right, that was part of the intention.
>>>>> 
>>>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>>>> That sounds reasonable.
>>>>> 
>>>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>>>> Ok. I?ll remove the flag from the tests.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Jiangli
>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>>>> 
>>>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>>>> Test 4 seems unnecessary now.
>>>>>>> Will do.
>>>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>>>> 
>>>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>>>> Ok.
>>>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>>>> 
>>>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>>>> Thanks!
>>>>>>> Jiangli
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Highlights of the changes:
>>>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>>>> Following are the details for the VM and test changes:
>>>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>>>> Thanks,
>>>>>>>>> Jiangli



From gary.adams at oracle.com  Thu Apr 26 22:49:41 2018
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Thu, 26 Apr 2018 18:49:41 -0400
Subject: Fwd: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <5AE1FFD0.1090803@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
Message-ID: <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>

Adding build-dev and hotspot-runtime-dev aliases.

-------- Forwarded Message --------
Subject: 	RFR: JDK-8202319: Fix compilation warnings in Solaris debug 
builds for DevStudio 12.6
Date: 	Thu, 26 Apr 2018 12:35:28 -0400
From: 	Gary Adams <gary.adams at oracle.com>
Reply-To: 	gary.adams at oracle.com
To: 	OpenJDK Serviceability <serviceability-dev at openjdk.java.net>



Getting the sources ready for the next Solaris developer studio toolchain.
Some additional warnings were found in the debug build.

   ?Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
    Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/

This update conditionally disables some new error checks, if the
new toolchain is used.



From kim.barrett at oracle.com  Thu Apr 26 22:55:52 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 18:55:52 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
Message-ID: <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>

> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>> 
>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>> 
>>> I'm asking for the review and eventually sponsorship.
>> 
> 
> The patch looks good to me.
> 
>> The change to os::readdir in os_linux.inline.hpp looks fine.
>> 
>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
>> of those is right, and that part of the change should not be made; see
>> https://bugs.openjdk.java.net/browse/JDK-8134540
>> Much nearly duplicated code for PerfMemory support
>> 
> 
> I think, in the circumstances, Michal's solution is the best option at
> this point.
> 8134540 looks like a more long-term change currently scheduled for 12 (is
> anyone currently working on it?), whereas this fix could go into 11 and remove
> a couple of unneeded memory allocations.
> 
>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>> the second argument to os::readdir.
>> windows: unused
>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>> aix: I haven?t looked at it, but would guess it?s similar.
>> 
>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>> ::readdir on non-Windows.  That would all be for another RFE though.
>> 
>> 
> 
> This also seems like a more in-depth separate change and not one that
> can be performed
> by any of us alone, as we don't test all these platforms. As it
> stands, Michal's change affects
> Linux and Linux alone, and the addition of the use of NULL will make
> it clearer that moving
> to an os:readdir is feasible on that platform.

I disagree, and still think the perfMemory_linux.cpp change should be
removed.

(1) The change to perfMemory_linux.cpp is entirely unnecessary to
address the problem this bug is about.

(2) It violates the (implied) protocol for os::readdir.  If
Linux-specific code wants to invoke Linux-specific behavior, it should
do so by calling a Linux-specific API, not abuse an intended to be
portable API.

(3) It minorly interferes with some desirable future work.  If there
were some significant benefit to doing so, I wouldn't give this much
weight, but I don't see a significant benefit.

(4) The only benefit is saving some rare short-term memory
allocations.  I don't think that's worth the above costs.

Note that the Windows version of os::readdir also ignores the second
argument, but all callers provide it anyway.

I've opened a new CR for general os::readdir cleanup.
https://bugs.openjdk.java.net/browse/JDK-8202353



From thomas.stuefe at gmail.com  Fri Apr 27 04:55:25 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 06:55:25 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
Message-ID: <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>

Hi,

This was added by "8200178: Remove mapfiles for JDK native libraries".
But if the flag is not accepted, what is the default behavior? Do we
now export everything?

I'd like to understand this first before removing the flag to get rid
of the warnings.

Best Regards, Thomas

On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi Matthias,
>
> after Bhaktavatsal Reddy's report about the problems with
> "-qvisibility" with xlC 13 and taking into account that we can't test
> this anyway because we don't currently have xlC 13
>  on our machines I think it would be best to completely remove this
> option for now on AIX. Once we get xlC 13 we can revisit the issue.
>
> Thanks,
> Volker
>
>
> On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> <bhamaram at in.ibm.com> wrote:
>> Hi Matthias,
>>
>> At this point, I think we can remove the flag as you found that it is not supported in XLC < 13. And with XLC 13, it require more work to use this flag.
>>
>> Thanks,
>> Bhaktavatsal Reddy
>>
>>
>>
>> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
>> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
>> From: "Baesken, Matthias" <matthias.baesken at sap.com>
>> Date: 04/26/2018 08:23PM
>> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R Maram    <bhamaram at in.ibm.com>
>> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>>
>>
>>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and probably not working anyway)  for the OpenJDK  build .
>>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of 13.1  ?might? work   for OpenJDK compilation .
>>  And for 12.1  I want to remove the flags  .
>>
>>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it  I remove them for all xlC versions including 13.1 )
>>
>>  Best regards, Matthias
>>
>>
>>
>>
>>
>>
>>  From: Langer, Christoph
>>  Sent: Donnerstag, 26. April 2018 16:38
>>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker <volker.simonis at 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
>>
>>
>>
>>


From kim.barrett at oracle.com  Fri Apr 27 05:32:04 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 01:32:04 -0400
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
 <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
Message-ID: <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>

> On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:
> 
> Adding build-dev and hotspot-runtime-dev aliases.
> 
> -------- Forwarded Message --------
> Subject: 	RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6
> Date: 	Thu, 26 Apr 2018 12:35:28 -0400
> From: 	Gary Adams <gary.adams at oracle.com>
> Reply-To: 	gary.adams at oracle.com
> To: 	OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
> 
> 
> 
> Getting the sources ready for the next Solaris developer studio toolchain.
> Some additional warnings were found in the debug build.
> 
>   Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
>   Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
> 
> This update conditionally disables some new error checks, if the
> new toolchain is used.

I looked at these, and the warnings are correct, so just disabling them is a bit troubling.

The thing is, the code in both cases is attempting to intentionally provoke a crash.
But because the code is invoking undefined behavior, executing it might actually do
anything, or nothing at all.  So while suppressing the warning might permit compilation,
it?s not at all obvious that the compilation will produce anything like the desired code.
And that?s also true for platforms that aren?t warning?



From christoph.langer at sap.com  Fri Apr 27 06:07:26 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Apr 2018 06:07:26 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
Message-ID: <db347ec5922a4e6e9e87676310fcdddf@sap.com>

Hi Thomas,

Look at this blog: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html 

if I understand it correctly, the xlc 12 default behavior should be like what we'd expect from -qvisibility=hidden.

Best regards
Christoph

> -----Original Message-----
> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of
> Thomas St?fe
> Sent: Freitag, 27. April 2018 06:55
> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> <matthias.baesken at sap.com>
> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
> dev at openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> Hi,
> 
> This was added by "8200178: Remove mapfiles for JDK native libraries".
> But if the flag is not accepted, what is the default behavior? Do we
> now export everything?
> 
> I'd like to understand this first before removing the flag to get rid
> of the warnings.
> 
> Best Regards, Thomas
> 
> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
> > Hi Matthias,
> >
> > after Bhaktavatsal Reddy's report about the problems with
> > "-qvisibility" with xlC 13 and taking into account that we can't test
> > this anyway because we don't currently have xlC 13
> >  on our machines I think it would be best to completely remove this
> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
> >
> > Thanks,
> > Volker
> >
> >
> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> > <bhamaram at in.ibm.com> wrote:
> >> Hi Matthias,
> >>
> >> At this point, I think we can remove the flag as you found that it is not
> supported in XLC < 13. And with XLC 13, it require more work to use this flag.
> >>
> >> Thanks,
> >> Bhaktavatsal Reddy
> >>
> >>
> >>
> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-
> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-
> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
> >> Date: 04/26/2018 08:23PM
> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R Maram
> <bhamaram at in.ibm.com>
> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >>
> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and
> probably not working anyway)  for the OpenJDK  build .
> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of
> 13.1  ?might? work   for OpenJDK compilation .
> >>  And for 12.1  I want to remove the flags  .
> >>
> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it
> I remove them for all xlC versions including 13.1 )
> >>
> >>  Best regards, Matthias
> >>
> >>
> >>
> >>
> >>
> >>
> >>  From: Langer, Christoph
> >>  Sent: Donnerstag, 26. April 2018 16:38
> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-
> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker
> <volker.simonis at 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
> >>
> >>
> >>
> >>

From david.holmes at oracle.com  Fri Apr 27 06:11:09 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Apr 2018 16:11:09 +1000
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
 <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
 <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>
Message-ID: <bfb03010-70b0-efe5-b59f-78f3a36b21b5@oracle.com>

On 27/04/2018 3:32 PM, Kim Barrett wrote:
>> On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:
>>
>> Adding build-dev and hotspot-runtime-dev aliases.
>>
>> -------- Forwarded Message --------
>> Subject: 	RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6
>> Date: 	Thu, 26 Apr 2018 12:35:28 -0400
>> From: 	Gary Adams <gary.adams at oracle.com>
>> Reply-To: 	gary.adams at oracle.com
>> To: 	OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
>>
>>
>>
>> Getting the sources ready for the next Solaris developer studio toolchain.
>> Some additional warnings were found in the debug build.
>>
>>    Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
>>    Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
>>
>> This update conditionally disables some new error checks, if the
>> new toolchain is used.
> 
> I looked at these, and the warnings are correct, so just disabling them is a bit troubling.
> 
> The thing is, the code in both cases is attempting to intentionally provoke a crash.
> But because the code is invoking undefined behavior, executing it might actually do
> anything, or nothing at all.  So while suppressing the warning might permit compilation,
> it?s not at all obvious that the compilation will produce anything like the desired code.
> And that?s also true for platforms that aren?t warning?

True. Perhaps we should just raise a SEGV directly?

David



From kim.barrett at oracle.com  Fri Apr 27 06:48:47 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 02:48:47 -0400
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <bfb03010-70b0-efe5-b59f-78f3a36b21b5@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
 <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
 <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>
 <bfb03010-70b0-efe5-b59f-78f3a36b21b5@oracle.com>
Message-ID: <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com>

> On Apr 27, 2018, at 2:11 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 27/04/2018 3:32 PM, Kim Barrett wrote:
>>> On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:
>>> 
>>> Adding build-dev and hotspot-runtime-dev aliases.
>>> 
>>> -------- Forwarded Message --------
>>> Subject: 	RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6
>>> Date: 	Thu, 26 Apr 2018 12:35:28 -0400
>>> From: 	Gary Adams <gary.adams at oracle.com>
>>> Reply-To: 	gary.adams at oracle.com
>>> To: 	OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
>>> 
>>> 
>>> 
>>> Getting the sources ready for the next Solaris developer studio toolchain.
>>> Some additional warnings were found in the debug build.
>>> 
>>>   Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
>>>   Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
>>> 
>>> This update conditionally disables some new error checks, if the
>>> new toolchain is used.
>> I looked at these, and the warnings are correct, so just disabling them is a bit troubling.
>> The thing is, the code in both cases is attempting to intentionally provoke a crash.
>> But because the code is invoking undefined behavior, executing it might actually do
>> anything, or nothing at all.  So while suppressing the warning might permit compilation,
>> it?s not at all obvious that the compilation will produce anything like the desired code.
>> And that?s also true for platforms that aren?t warning?
> 
> True. Perhaps we should just raise a SEGV directly?
> 
> David

I like that idea.



From thomas.stuefe at gmail.com  Fri Apr 27 07:20:38 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 09:20:38 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <db347ec5922a4e6e9e87676310fcdddf@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
 <db347ec5922a4e6e9e87676310fcdddf@sap.com>
Message-ID: <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>

Hi Christoph

On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi Thomas,
>
> Look at this blog: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>
> if I understand it correctly, the xlc 12 default behavior should be like what we'd expect from -qvisibility=hidden.
>

Where in this article do you read this?

..Thomas

> Best regards
> Christoph
>
>> -----Original Message-----
>> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of
>> Thomas St?fe
>> Sent: Freitag, 27. April 2018 06:55
>> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>
>> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
>> dev at openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>>
>> Hi,
>>
>> This was added by "8200178: Remove mapfiles for JDK native libraries".
>> But if the flag is not accepted, what is the default behavior? Do we
>> now export everything?
>>
>> I'd like to understand this first before removing the flag to get rid
>> of the warnings.
>>
>> Best Regards, Thomas
>>
>> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>> > Hi Matthias,
>> >
>> > after Bhaktavatsal Reddy's report about the problems with
>> > "-qvisibility" with xlC 13 and taking into account that we can't test
>> > this anyway because we don't currently have xlC 13
>> >  on our machines I think it would be best to completely remove this
>> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
>> >
>> > Thanks,
>> > Volker
>> >
>> >
>> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>> > <bhamaram at in.ibm.com> wrote:
>> >> Hi Matthias,
>> >>
>> >> At this point, I think we can remove the flag as you found that it is not
>> supported in XLC < 13. And with XLC 13, it require more work to use this flag.
>> >>
>> >> Thanks,
>> >> Bhaktavatsal Reddy
>> >>
>> >>
>> >>
>> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
>> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
>> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-
>> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-libs-
>> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
>> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
>> >> Date: 04/26/2018 08:23PM
>> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R Maram
>> <bhamaram at in.ibm.com>
>> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc
>> 12.1
>> >>
>> >>
>> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported  (and
>> probably not working anyway)  for the OpenJDK  build .
>> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case of
>> 13.1  ?might? work   for OpenJDK compilation .
>> >>  And for 12.1  I want to remove the flags  .
>> >>
>> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers it
>> I remove them for all xlC versions including 13.1 )
>> >>
>> >>  Best regards, Matthias
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>  From: Langer, Christoph
>> >>  Sent: Donnerstag, 26. April 2018 16:38
>> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-
>> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker
>> <volker.simonis at 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
>> >>
>> >>
>> >>
>> >>


From christoph.langer at sap.com  Fri Apr 27 07:27:45 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Apr 2018 07:27:45 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
 <db347ec5922a4e6e9e87676310fcdddf@sap.com>
 <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>
Message-ID: <216dfcffaf2a4a1ea747eb4e63890611@sap.com>

Hi Thomas,

let me cite one section from the article:

----------------------------------------------

Visibility attribute and backward compatibility on AIX

As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList. However, on Linux, symbols are, by default, with export (namely default) visibility. This brings a gap between the AIX visibility attribute and the GNU visibility attribute. To be backward compatible, on AIX, XL C/C++ would not set all the symbols to be exported like Linux. It might consider symbol without any visibility setting to be an unspecific visibility, which aligns with an old AIX implementation. For such symbols, AIX compiler, linker, and related tools would handle it as before. However, unspecific visibility does not mean that the symbol is internal or invisible at all. It is just a visibility that is specially designed to keep the compatibility.

...

----------------------------------------------

It says in the first sentence: " As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList". I guess that is why I was under the impression that with xlc12 symbols would not be visible...

Best regards
Christoph

> -----Original Message-----
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Freitag, 27. April 2018 09:21
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Simonis, Volker <volker.simonis at sap.com>;
> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
> dev at openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> Hi Christoph
> 
> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
> > Hi Thomas,
> >
> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
> aix-symbol-visibility-part2/index.html
> >
> > if I understand it correctly, the xlc 12 default behavior should be like what
> we'd expect from -qvisibility=hidden.
> >
> 
> Where in this article do you read this?
> 
> ..Thomas
> 
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf
> Of
> >> Thomas St?fe
> >> Sent: Freitag, 27. April 2018 06:55
> >> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> >> <matthias.baesken at sap.com>
> >> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> Hi,
> >>
> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
> >> But if the flag is not accepted, what is the default behavior? Do we
> >> now export everything?
> >>
> >> I'd like to understand this first before removing the flag to get rid
> >> of the warnings.
> >>
> >> Best Regards, Thomas
> >>
> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
> >> <volker.simonis at gmail.com> wrote:
> >> > Hi Matthias,
> >> >
> >> > after Bhaktavatsal Reddy's report about the problems with
> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
> >> > this anyway because we don't currently have xlC 13
> >> >  on our machines I think it would be best to completely remove this
> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
> >> >
> >> > Thanks,
> >> > Volker
> >> >
> >> >
> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> >> > <bhamaram at in.ibm.com> wrote:
> >> >> Hi Matthias,
> >> >>
> >> >> At this point, I think we can remove the flag as you found that it is not
> >> supported in XLC < 13. And with XLC 13, it require more work to use this
> flag.
> >> >>
> >> >> Thanks,
> >> >> Bhaktavatsal Reddy
> >> >>
> >> >>
> >> >>
> >> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
> >> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
> >> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-
> >> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-
> libs-
> >> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> >> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
> >> >> Date: 04/26/2018 08:23PM
> >> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R
> Maram
> >> <bhamaram at in.ibm.com>
> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> >> 12.1
> >> >>
> >> >>
> >> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported
> (and
> >> probably not working anyway)  for the OpenJDK  build .
> >> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case
> of
> >> 13.1  ?might? work   for OpenJDK compilation .
> >> >>  And for 12.1  I want to remove the flags  .
> >> >>
> >> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers
> it
> >> I remove them for all xlC versions including 13.1 )
> >> >>
> >> >>  Best regards, Matthias
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>  From: Langer, Christoph
> >> >>  Sent: Donnerstag, 26. April 2018 16:38
> >> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>;
> ppc-
> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker
> >> <volker.simonis at 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
> >> >>
> >> >>
> >> >>
> >> >>

From thomas.stuefe at gmail.com  Fri Apr 27 08:04:10 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 10:04:10 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <216dfcffaf2a4a1ea747eb4e63890611@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
 <db347ec5922a4e6e9e87676310fcdddf@sap.com>
 <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>
 <216dfcffaf2a4a1ea747eb4e63890611@sap.com>
Message-ID: <CAA-vtUziBB-s1u7zBf8ijq_1eQN4=caK2zrEpoeccVzxvNqACw@mail.gmail.com>

On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi Thomas,
>
> let me cite one section from the article:
>
> ----------------------------------------------
>
> Visibility attribute and backward compatibility on AIX
>
> As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList. However, on Linux, symbols are, by default, with export (namely default) visibility. This brings a gap between the AIX visibility attribute and the GNU visibility attribute. To be backward compatible, on AIX, XL C/C++ would not set all the symbols to be exported like Linux. It might consider symbol without any visibility setting to be an unspecific visibility, which aligns with an old AIX implementation. For such symbols, AIX compiler, linker, and related tools would handle it as before. However, unspecific visibility does not mean that the symbol is internal or invisible at all. It is just a visibility that is specially designed to keep the compatibility.
>
> ...
>
> ----------------------------------------------
>
> It says in the first sentence: " As we know from the previous article, on AIX, symbols are not visible by default unless we export them at the linking stage, either manually or with the help of CreateExportList". I guess that is why I was under the impression that with xlc12 symbols would not be visible...
>

:) Thanks for that pointer.

I did read:

"Consequently, as we have mentioned at the beginning of this article,
if the programmer does not explicitly specify the visibility attribute
for a symbol, on Linux, the visibility of the symbol could be
thedefault. But on AIX, the visibility would be unspecified."

So I thought, default is "unspecified", which is not hidden.

I just had a look at the libjvm.so from our nightly fastdebug build,
using "nm -g".

I see tons of exports listed, most of which do not have the static
keyword. So, I would expect them to be exported from their compilation
unit, but not from the linked shared library? Am I making a thinking
error here?

Anyway. I do not want to hold up this patch if you guys think it is
okay to ignore the compiler warning, so it is okay by me.

Best Regards, Thomas


> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Freitag, 27. April 2018 09:21
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; Simonis, Volker <volker.simonis at sap.com>;
>> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
>> dev at openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>>
>> Hi Christoph
>>
>> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>> <christoph.langer at sap.com> wrote:
>> > Hi Thomas,
>> >
>> > Look at this blog: https://www.ibm.com/developerworks/aix/library/au-
>> aix-symbol-visibility-part2/index.html
>> >
>> > if I understand it correctly, the xlc 12 default behavior should be like what
>> we'd expect from -qvisibility=hidden.
>> >
>>
>> Where in this article do you read this?
>>
>> ..Thomas
>>
>> > Best regards
>> > Christoph
>> >
>> >> -----Original Message-----
>> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf
>> Of
>> >> Thomas St?fe
>> >> Sent: Freitag, 27. April 2018 06:55
>> >> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> >> <matthias.baesken at sap.com>
>> >> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
>> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
>> >> dev at openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
>> 12.1
>> >>
>> >> Hi,
>> >>
>> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
>> >> But if the flag is not accepted, what is the default behavior? Do we
>> >> now export everything?
>> >>
>> >> I'd like to understand this first before removing the flag to get rid
>> >> of the warnings.
>> >>
>> >> Best Regards, Thomas
>> >>
>> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>> >> <volker.simonis at gmail.com> wrote:
>> >> > Hi Matthias,
>> >> >
>> >> > after Bhaktavatsal Reddy's report about the problems with
>> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
>> >> > this anyway because we don't currently have xlC 13
>> >> >  on our machines I think it would be best to completely remove this
>> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
>> >> >
>> >> > Thanks,
>> >> > Volker
>> >> >
>> >> >
>> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>> >> > <bhamaram at in.ibm.com> wrote:
>> >> >> Hi Matthias,
>> >> >>
>> >> >> At this point, I think we can remove the flag as you found that it is not
>> >> supported in XLC < 13. And with XLC 13, it require more work to use this
>> flag.
>> >> >>
>> >> >> Thanks,
>> >> >> Bhaktavatsal Reddy
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: -----
>> >> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
>> >> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-port-
>> >> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-
>> libs-
>> >> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
>> >> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
>> >> >> Date: 04/26/2018 08:23PM
>> >> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R
>> Maram
>> >> <bhamaram at in.ibm.com>
>> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc
>> >> 12.1
>> >> >>
>> >> >>
>> >> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported
>> (and
>> >> probably not working anyway)  for the OpenJDK  build .
>> >> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in case
>> of
>> >> 13.1  ?might? work   for OpenJDK compilation .
>> >> >>  And for 12.1  I want to remove the flags  .
>> >> >>
>> >> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he  prefers
>> it
>> >> I remove them for all xlC versions including 13.1 )
>> >> >>
>> >> >>  Best regards, Matthias
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>  From: Langer, Christoph
>> >> >>  Sent: Donnerstag, 26. April 2018 16:38
>> >> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>;
>> ppc-
>> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis, Volker
>> >> <volker.simonis at 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
>> >> >>
>> >> >>
>> >> >>
>> >> >>


From david.holmes at oracle.com  Fri Apr 27 08:43:48 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Apr 2018 18:43:48 +1000
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <13E80BF1-2694-4F5B-A39E-B53FB1EA7BD6@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <e36bd45e-a7d2-d682-66d0-c1707b405767@oracle.com>
 <13E80BF1-2694-4F5B-A39E-B53FB1EA7BD6@oracle.com>
Message-ID: <c71a0194-ef8e-44d4-f3c1-278be4cd2242@oracle.com>

On 27/04/2018 4:20 AM, Jiangli Zhou wrote:
> 
>> On Apr 25, 2018, at 10:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 26/04/2018 2:34 PM, Jiangli Zhou wrote:
>>> Here is the incremental webrev with updates that incorporate all feedbacks:
>>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>>
>> Looks good.
> 
> Thanks!
> 
>>
>> One additional comment on test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems insufficient to just check the output for the word "dump". I would expect to see something more definitively associated with -Xshare:dump and also a check that it exited cleanly (in case we find "core dump?).

I should have of course said "the word Dumping" and "in case we find 
'Dumping core'". :)

> With other test cases being removed from appcds/SharedArchiveFile.java, I just realized that the test now essentially is the same as the jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java test. SharedArchiveFile/SharedArchiveFile.java includes more robust checks as you suggested and also tests runtime. Your comments above (and fresh morning coffee) reminded me that. :-) So I went ahead removed the appcds/SharedArchiveFile.java. Please let me know if you want to see the new webrev.

No that's fine. Removing the file completely makes sense.

Thanks,
David

> Thanks!
> Jiangli
> 
>>
>> Thanks,
>> David
>> -----
>>
>>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>>> - Removed UseAppCDS.java test.
>>> - Removed UseAppCDS in various tests.
>>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>>> Full webrev:
>>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>>> Thanks for all the suggestions!
>>> Jiangli
>>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>>>
>>>> Hi David,
>>>>
>>>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Jiangli,
>>>>>
>>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>>> Hi David,
>>>>>> Thanks a lot for the review!
>>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>
>>>>>>> cc'ing build-dev for the makefile change
>>>>>>>
>>>>>>> Hi Jiangli,
>>>>>>>
>>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>>>
>>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>>> Done. Thanks for noticing that!
>>>>>>>
>>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>>>
>>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>>>
>>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>>>
>>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>>>
>>>> Right, that was part of the intention.
>>>>
>>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>>>
>>>> That sounds reasonable.
>>>>
>>>>>
>>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>>>
>>>> Ok. I?ll remove the flag from the tests.
>>>>
>>>> Thanks!
>>>>
>>>> Jiangli
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>>
>>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>>>
>>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>>> Test 4 seems unnecessary now.
>>>>>> Will do.
>>>>>>>
>>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>>>
>>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>>> Ok.
>>>>>>>
>>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>>>
>>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>>> Thanks!
>>>>>> Jiangli
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Highlights of the changes:
>>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>>> Following are the details for the VM and test changes:
>>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>>   - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>>   - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>>   - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>>   - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>>   - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>>   - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>>   - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>>> Thanks,
>>>>>>>> Jiangli
>>>>
> 


From mvala at redhat.com  Fri Apr 27 08:56:09 2018
From: mvala at redhat.com (Michal Vala)
Date: Fri, 27 Apr 2018 10:56:09 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
Message-ID: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>



On 04/27/2018 12:55 AM, Kim Barrett wrote:
>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>
>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>
>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>
>>>> I'm asking for the review and eventually sponsorship.
>>>
>>
>> The patch looks good to me.
>>
>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>
>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
>>> of those is right, and that part of the change should not be made; see
>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>> Much nearly duplicated code for PerfMemory support
>>>
>>
>> I think, in the circumstances, Michal's solution is the best option at
>> this point.
>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>> anyone currently working on it?), whereas this fix could go into 11 and remove
>> a couple of unneeded memory allocations.
>>
>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>> the second argument to os::readdir.
>>> windows: unused
>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>
>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>> ::readdir on non-Windows.  That would all be for another RFE though.
>>>
>>>
>>
>> This also seems like a more in-depth separate change and not one that
>> can be performed
>> by any of us alone, as we don't test all these platforms. As it
>> stands, Michal's change affects
>> Linux and Linux alone, and the addition of the use of NULL will make
>> it clearer that moving
>> to an os:readdir is feasible on that platform.
> 
> I disagree, and still think the perfMemory_linux.cpp change should be
> removed.
> 
> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
> address the problem this bug is about.
> 
> (2) It violates the (implied) protocol for os::readdir.  If
> Linux-specific code wants to invoke Linux-specific behavior, it should
> do so by calling a Linux-specific API, not abuse an intended to be
> portable API.
> 
> (3) It minorly interferes with some desirable future work.  If there
> were some significant benefit to doing so, I wouldn't give this much
> weight, but I don't see a significant benefit.
> 
> (4) The only benefit is saving some rare short-term memory
> allocations.  I don't think that's worth the above costs.
> 
> Note that the Windows version of os::readdir also ignores the second
> argument, but all callers provide it anyway.
> 
> I've opened a new CR for general os::readdir cleanup.
> https://bugs.openjdk.java.net/browse/JDK-8202353
> 

Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can 
be solved in JDK-8202353, which should imho include also removal of second 
argument of os::readdir, once it's unused.

For now, proposed patch looks like this:

--- old/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.498343185 +0200
+++ new/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.214342670 +0200
@@ -98,26 +98,8 @@

  inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
  {
-// readdir_r has been deprecated since glibc 2.24.
-// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
-  dirent* p;
-  int status;
    assert(dirp != NULL, "just checking");
-
-  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
-  // version. Here is the doc for this function:
-  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
-  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
-    errno = status;
-    return NULL;
-  } else
-    return p;
-
-#pragma GCC diagnostic pop
+  return ::readdir(dirp);
  }

  inline int os::closedir(DIR *dirp) {



-- 
Michal Vala
OpenJDK QE
Red Hat Czech


From david.holmes at oracle.com  Fri Apr 27 08:59:04 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Apr 2018 18:59:04 +1000
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
 <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
 <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>
 <bfb03010-70b0-efe5-b59f-78f3a36b21b5@oracle.com>
 <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com>
Message-ID: <43683acb-7f30-e79a-42dc-0d4693e2ac21@oracle.com>

On 27/04/2018 4:48 PM, Kim Barrett wrote:
>> On Apr 27, 2018, at 2:11 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 27/04/2018 3:32 PM, Kim Barrett wrote:
>>>> On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:
>>>>
>>>> Adding build-dev and hotspot-runtime-dev aliases.
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: 	RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6
>>>> Date: 	Thu, 26 Apr 2018 12:35:28 -0400
>>>> From: 	Gary Adams <gary.adams at oracle.com>
>>>> Reply-To: 	gary.adams at oracle.com
>>>> To: 	OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
>>>>
>>>>
>>>>
>>>> Getting the sources ready for the next Solaris developer studio toolchain.
>>>> Some additional warnings were found in the debug build.
>>>>
>>>>    Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
>>>>    Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
>>>>
>>>> This update conditionally disables some new error checks, if the
>>>> new toolchain is used.
>>> I looked at these, and the warnings are correct, so just disabling them is a bit troubling.
>>> The thing is, the code in both cases is attempting to intentionally provoke a crash.
>>> But because the code is invoking undefined behavior, executing it might actually do
>>> anything, or nothing at all.  So while suppressing the warning might permit compilation,
>>> it?s not at all obvious that the compilation will produce anything like the desired code.
>>> And that?s also true for platforms that aren?t warning?
>>
>> True. Perhaps we should just raise a SEGV directly?
>>
>> David
> 
> I like that idea.

Hopefully this should work:

os::signal_raise(os::get_signal_number("SEGV"));

Cheers,
David


From archana.nogriya at uk.ibm.com  Fri Apr 27 09:12:08 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Fri, 27 Apr 2018 10:12:08 +0100
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
Message-ID: <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>

Thanks Erik,

It will be great if you can sponsor for this contribution please. 


Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com



From:   Erik Joelsson <erik.joelsson at oracle.com>
To:     Archana Nogriya <archana.nogriya at uk.ibm.com>, 
build-dev at openjdk.java.net
Cc:     David Holmes <david.holmes at oracle.com>
Date:   26/04/2018 17:15
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs



Looks reasonable.
/Erik

On 2018-04-26 04:00, Archana Nogriya wrote:
If we have a conditional variable to set "
hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately. 

diff --git a/make/Main.gmk b/make/Main.gmk 
index 731e9c9934..444a835cb4 100644 
--- a/make/Main.gmk 
+++ b/make/Main.gmk 
@@ -830,7 +830,8 @@ else 
   docs-reference-api-modulegraph: exploded-image buildtools-modules 
  
   # The gensrc steps for hotspot and jdk.jdi create html spec files. 
-  docs-jdk-specs: jdk.jdi-gensrc \ 
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc 
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \ 
       docs-jdk-index 


###################################################################################### 


diff --git a/make/Docs.gmk b/make/Docs.gmk 
index 644ffbf74a..73ffb8ebd2 100644 
--- a/make/Docs.gmk 
+++ b/make/Docs.gmk 
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ 
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL) 
  
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-    FILES := $(JVMTI_HTML), \ 
-    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+    FILES := $(JVMTI_HTML), \ 
+    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
  
Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From archana.nogriya at uk.ibm.com  Fri Apr 27 10:31:32 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Fri, 27 Apr 2018 11:31:32 +0100
Subject: Contribution to make/Docs.gmk
In-Reply-To: <OF953C9EF3.728F679C-ON00258278.00562C3D-80258279.00358245@LocalDomain>
References: <OF70F93106.BE1032AA-ON0025824A.004E19D2-8025824A.0051A38C@notes.na.collabserv.com>
 <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com>
 <OF0291D502.2C215E3C-ON0025824B.0046A32D-8025824B.00477120@notes.na.collabserv.com>
 <963d41da-904f-1119-cc6c-a2937e66a87e@oracle.com>
 <OF953C9EF3.728F679C-ON00258278.00562C3D-80258279.00358245@LocalDomain>
Message-ID: <OF03FB75A4.C69B6721-ON0025827C.0039781B-8025827C.0039D606@notes.na.collabserv.com>

I am looking for reviewer and sponsor for this contribution, Is anyone who 
can review this please and happy to sponsor for this contribution as 
appropriate. 

Hi, 

"make/Docs.gmk", JDK_MODULES is only sorted with DOCS_MODULES, where It 
should also filter-out MODULES_FILTER for javadocs modules.

# All modules to have docs generated by docs-jdk-api target
>> -JDK_MODULES := $(sort $(DOCS_MODULES))
>> +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER), 
$(DOCS_MODULES)))
 

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From erik.gahlin at oracle.com  Fri Apr 27 13:25:17 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 27 Apr 2018 15:25:17 +0200
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
 <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
Message-ID: <5AE324BD.4010109@oracle.com>

Hi Magnus,

Sorry about not including build-dev.  See comments inline.

>
> On 2018-04-25 13:06, Erik Gahlin wrote:
>> Greetings,
>>
>> Could I have a review of 8199712: Flight Recorder
>>
>> As mentioned in the preview [1] the tracing backend has been removed. 
>> Event metadata has been consolidated into a single XML file and event 
>> classes are now generated by GenerateJfrFiles.java.
>>
>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>
>> For details about the feature, see the JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8199712.0/
> Hi Erik,
>
> When posting build changes (files in "make/*"), please always include 
> build-dev. Thanks! :-)
>
> This review is for build changes only.
>
> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year 
> change. It can be reverted.
>
Will fix.

> * make/copy/Copy-jdk.jfr.gmk:
> COPY_HOTSPOT_TRACE_FILES should be renamed to something like 
> COPY_JFR_METADATA.
>
Will fix.

> The second part is better off rewritten using SetupCopyFiles.
>
> Something like this, written on-the-fly, so might not work. (Email me 
> privately if it does not work and you need help.)
>
> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>
> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
>   DEST := $(LIB_DST_DIR)/jfr, \
>   FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
>   FLATTEN := true, \
> ))
>
> TARGETS += $(COPY_JFR_CONF)
>
Will look into it.

> * make/autoconf/hotspot.m4:
> It's a bit unfortunate with the --enable-jfr option. Ideally, this 
> should be handled only as a JVM feature (--with-jvm-features=jfr). Try 
> this piece of code instead: (Not tested, but should work.)
>
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -26,7 +26,7 @@
>  # All valid JVM features, regardless of platform
>  VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti 
> jvmci \
>      graal vm-structs jni-check services management all-gcs nmt cds \
> -    static-build link-time-opt aot"
> +    static-build link-time-opt aot jfr"
>
>  # All valid JVM variants
>  VALID_JVM_VARIANTS="server client minimal core zero custom"
> @@ -313,6 +313,11 @@
>      AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature 
> 'all-gcs'])
>    fi
>
> +  # Enable JFR by default, except on linux-sparcv9 and on minimal.
> +  if test "x$OPENJDK_TARGET_OS" != xlinux || test 
> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
> +    NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
> +  fi
> +
>    # Turn on additional features based on other parts of configure
>    if test "x$INCLUDE_DTRACE" = "xtrue"; then
>      JVM_FEATURES="$JVM_FEATURES dtrace"
>
Will try it.

Thanks
Erik

> Otherwise, build changes look good!
>
> /Magnus
>
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>
>> Thanks
>> Erik and Markus
>



From matthias.baesken at sap.com  Fri Apr 27 15:01:32 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 27 Apr 2018 15:01:32 +0000
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <CAA-vtUziBB-s1u7zBf8ijq_1eQN4=caK2zrEpoeccVzxvNqACw@mail.gmail.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
 <db347ec5922a4e6e9e87676310fcdddf@sap.com>
 <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>
 <216dfcffaf2a4a1ea747eb4e63890611@sap.com>
 <CAA-vtUziBB-s1u7zBf8ijq_1eQN4=caK2zrEpoeccVzxvNqACw@mail.gmail.com>
Message-ID: <6f8b83fe169c4b31a9bb459593e92d1a@sap.com>

> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?

Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it (e.g. libjvm.so)  with dump .
More than one would like to have .

However  for now I think we  should progress with the suggested patch as it is.

Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  the visibility attributes 
( as decribed in   https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html  )
 we can open a follow up item  with compiler flag adjustment and  adjust     src/java.base/unix/native/include/jni_md.h     , I think this file misses  a proper  JNIEXPORT definition for AIX / xlc 13.1  ).
 

Best regards, Matthias



> -----Original Message-----
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Freitag, 27. April 2018 10:04
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Simonis, Volker <volker.simonis at sap.com>;
> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
> dev at openjdk.java.net
> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
> 
> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
> > Hi Thomas,
> >
> > let me cite one section from the article:
> >
> > ----------------------------------------------
> >
> > Visibility attribute and backward compatibility on AIX
> >
> > As we know from the previous article, on AIX, symbols are not visible by
> default unless we export them at the linking stage, either manually or with
> the help of CreateExportList. However, on Linux, symbols are, by default,
> with export (namely default) visibility. This brings a gap between the AIX
> visibility attribute and the GNU visibility attribute. To be backward
> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
> like Linux. It might consider symbol without any visibility setting to be an
> unspecific visibility, which aligns with an old AIX implementation. For such
> symbols, AIX compiler, linker, and related tools would handle it as before.
> However, unspecific visibility does not mean that the symbol is internal or
> invisible at all. It is just a visibility that is specially designed to keep the
> compatibility.
> >
> > ...
> >
> > ----------------------------------------------
> >
> > It says in the first sentence: " As we know from the previous article, on AIX,
> symbols are not visible by default unless we export them at the linking stage,
> either manually or with the help of CreateExportList". I guess that is why I
> was under the impression that with xlc12 symbols would not be visible...
> >
> 
> :) Thanks for that pointer.
> 
> I did read:
> 
> "Consequently, as we have mentioned at the beginning of this article,
> if the programmer does not explicitly specify the visibility attribute
> for a symbol, on Linux, the visibility of the symbol could be
> thedefault. But on AIX, the visibility would be unspecified."
> 
> So I thought, default is "unspecified", which is not hidden.
> 
> I just had a look at the libjvm.so from our nightly fastdebug build,
> using "nm -g".
> 
> I see tons of exports listed, most of which do not have the static
> keyword. So, I would expect them to be exported from their compilation
> unit, but not from the linked shared library? Am I making a thinking
> error here?
> 
> Anyway. I do not want to hold up this patch if you guys think it is
> okay to ignore the compiler warning, so it is okay by me.
> 
> Best Regards, Thomas
> 
> 
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> >> Sent: Freitag, 27. April 2018 09:21
> >> To: Langer, Christoph <christoph.langer at sap.com>
> >> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> >> <matthias.baesken at sap.com>; Simonis, Volker
> <volker.simonis at sap.com>;
> >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
> build-
> >> dev at openjdk.java.net
> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> 12.1
> >>
> >> Hi Christoph
> >>
> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
> >> <christoph.langer at sap.com> wrote:
> >> > Hi Thomas,
> >> >
> >> > Look at this blog:
> https://www.ibm.com/developerworks/aix/library/au-
> >> aix-symbol-visibility-part2/index.html
> >> >
> >> > if I understand it correctly, the xlc 12 default behavior should be like
> what
> >> we'd expect from -qvisibility=hidden.
> >> >
> >>
> >> Where in this article do you read this?
> >>
> >> ..Thomas
> >>
> >> > Best regards
> >> > Christoph
> >> >
> >> >> -----Original Message-----
> >> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On
> Behalf
> >> Of
> >> >> Thomas St?fe
> >> >> Sent: Freitag, 27. April 2018 06:55
> >> >> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
> >> >> <matthias.baesken at sap.com>
> >> >> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
> >> >> dev at openjdk.java.net
> >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
> >> 12.1
> >> >>
> >> >> Hi,
> >> >>
> >> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
> >> >> But if the flag is not accepted, what is the default behavior? Do we
> >> >> now export everything?
> >> >>
> >> >> I'd like to understand this first before removing the flag to get rid
> >> >> of the warnings.
> >> >>
> >> >> Best Regards, Thomas
> >> >>
> >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
> >> >> <volker.simonis at gmail.com> wrote:
> >> >> > Hi Matthias,
> >> >> >
> >> >> > after Bhaktavatsal Reddy's report about the problems with
> >> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
> >> >> > this anyway because we don't currently have xlC 13
> >> >> >  on our machines I think it would be best to completely remove this
> >> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
> >> >> >
> >> >> > Thanks,
> >> >> > Volker
> >> >> >
> >> >> >
> >> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
> >> >> > <bhamaram at in.ibm.com> wrote:
> >> >> >> Hi Matthias,
> >> >> >>
> >> >> >> At this point, I think we can remove the flag as you found that it is
> not
> >> >> supported in XLC < 13. And with XLC 13, it require more work to use
> this
> >> flag.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Bhaktavatsal Reddy
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: ----
> -
> >> >> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
> >> >> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-
> port-
> >> >> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-
> >> libs-
> >> >> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> >> >> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
> >> >> >> Date: 04/26/2018 08:23PM
> >> >> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R
> >> Maram
> >> >> <bhamaram at in.ibm.com>
> >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
> xlc
> >> >> 12.1
> >> >> >>
> >> >> >>
> >> >> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported
> >> (and
> >> >> probably not working anyway)  for the OpenJDK  build .
> >> >> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in
> case
> >> of
> >> >> 13.1  ?might? work   for OpenJDK compilation .
> >> >> >>  And for 12.1  I want to remove the flags  .
> >> >> >>
> >> >> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he
> prefers
> >> it
> >> >> I remove them for all xlC versions including 13.1 )
> >> >> >>
> >> >> >>  Best regards, Matthias
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>  From: Langer, Christoph
> >> >> >>  Sent: Donnerstag, 26. April 2018 16:38
> >> >> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> >> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> >> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>;
> >> ppc-
> >> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> >> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis,
> Volker
> >> >> <volker.simonis at 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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>

From thomas.stuefe at gmail.com  Fri Apr 27 15:58:53 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 17:58:53 +0200
Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc
 12.1
In-Reply-To: <6f8b83fe169c4b31a9bb459593e92d1a@sap.com>
References: <8361024dba4f44309292e73ec9ad7b83@sap.com>
 <f03454ae3aa1400c9c210163dcf6fc1f@sap.com>
 <97c60ab29a6348769169b312f55832e7@sap.com>
 <OF7C88A3C7.26CC0A6D-ON0025827B.00524F33-0025827B.005253EC@notes.na.collabserv.com>
 <CA+3eh12w9R4sgmZEu86bqxtgAr21iYrCiiwgH67=bkXvnZHKZw@mail.gmail.com>
 <CAA-vtUx4LJ=c5ioJCyQg-uvivDvBqpjvxBxiUDwjd0ZPXCV3_g@mail.gmail.com>
 <db347ec5922a4e6e9e87676310fcdddf@sap.com>
 <CAA-vtUzUJE7Ma6wchFDVNKR1inP2pZOAH-Wi4ROytBrHNuUVJA@mail.gmail.com>
 <216dfcffaf2a4a1ea747eb4e63890611@sap.com>
 <CAA-vtUziBB-s1u7zBf8ijq_1eQN4=caK2zrEpoeccVzxvNqACw@mail.gmail.com>
 <6f8b83fe169c4b31a9bb459593e92d1a@sap.com>
Message-ID: <CAA-vtUyC+4_1i73YekPPkPg6Uxc86A4B_nQKOVBY6S8jQp4cYQ@mail.gmail.com>

On Fri, Apr 27, 2018 at 5:01 PM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>
> Hi Thomas , I see  "a ton"  of exported symbols as well  when looking into it (e.g. libjvm.so)  with dump .
> More than one would like to have .
>

Okay, thanks for confirming this! I was not sure if I was using nm
correctly, or if it was lying to me.

> However  for now I think we  should progress with the suggested patch as it is.
>

I agree, patch is fine. Thanks for fixing this.

> Once we switch to xlc 13  (or some follow up release of xlc)  that  supports  the visibility attributes
> ( as decribed in   https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html  )
>  we can open a follow up item  with compiler flag adjustment and  adjust     src/java.base/unix/native/include/jni_md.h     , I think this file misses  a proper  JNIEXPORT definition for AIX / xlc 13.1  ).
>

Okay, fine with me.

Best Regards, Thomas

>
> Best regards, Matthias
>
>
>
>> -----Original Message-----
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Freitag, 27. April 2018 10:04
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; Simonis, Volker <volker.simonis at sap.com>;
>> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
>> dev at openjdk.java.net
>> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1
>>
>> On Fri, Apr 27, 2018 at 9:27 AM, Langer, Christoph
>> <christoph.langer at sap.com> wrote:
>> > Hi Thomas,
>> >
>> > let me cite one section from the article:
>> >
>> > ----------------------------------------------
>> >
>> > Visibility attribute and backward compatibility on AIX
>> >
>> > As we know from the previous article, on AIX, symbols are not visible by
>> default unless we export them at the linking stage, either manually or with
>> the help of CreateExportList. However, on Linux, symbols are, by default,
>> with export (namely default) visibility. This brings a gap between the AIX
>> visibility attribute and the GNU visibility attribute. To be backward
>> compatible, on AIX, XL C/C++ would not set all the symbols to be exported
>> like Linux. It might consider symbol without any visibility setting to be an
>> unspecific visibility, which aligns with an old AIX implementation. For such
>> symbols, AIX compiler, linker, and related tools would handle it as before.
>> However, unspecific visibility does not mean that the symbol is internal or
>> invisible at all. It is just a visibility that is specially designed to keep the
>> compatibility.
>> >
>> > ...
>> >
>> > ----------------------------------------------
>> >
>> > It says in the first sentence: " As we know from the previous article, on AIX,
>> symbols are not visible by default unless we export them at the linking stage,
>> either manually or with the help of CreateExportList". I guess that is why I
>> was under the impression that with xlc12 symbols would not be visible...
>> >
>>
>> :) Thanks for that pointer.
>>
>> I did read:
>>
>> "Consequently, as we have mentioned at the beginning of this article,
>> if the programmer does not explicitly specify the visibility attribute
>> for a symbol, on Linux, the visibility of the symbol could be
>> thedefault. But on AIX, the visibility would be unspecified."
>>
>> So I thought, default is "unspecified", which is not hidden.
>>
>> I just had a look at the libjvm.so from our nightly fastdebug build,
>> using "nm -g".
>>
>> I see tons of exports listed, most of which do not have the static
>> keyword. So, I would expect them to be exported from their compilation
>> unit, but not from the linked shared library? Am I making a thinking
>> error here?
>>
>> Anyway. I do not want to hold up this patch if you guys think it is
>> okay to ignore the compiler warning, so it is okay by me.
>>
>> Best Regards, Thomas
>>
>>
>> > Best regards
>> > Christoph
>> >
>> >> -----Original Message-----
>> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> >> Sent: Freitag, 27. April 2018 09:21
>> >> To: Langer, Christoph <christoph.langer at sap.com>
>> >> Cc: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> >> <matthias.baesken at sap.com>; Simonis, Volker
>> <volker.simonis at sap.com>;
>> >> ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
>> build-
>> >> dev at openjdk.java.net
>> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
>> 12.1
>> >>
>> >> Hi Christoph
>> >>
>> >> On Fri, Apr 27, 2018 at 8:07 AM, Langer, Christoph
>> >> <christoph.langer at sap.com> wrote:
>> >> > Hi Thomas,
>> >> >
>> >> > Look at this blog:
>> https://www.ibm.com/developerworks/aix/library/au-
>> >> aix-symbol-visibility-part2/index.html
>> >> >
>> >> > if I understand it correctly, the xlc 12 default behavior should be like
>> what
>> >> we'd expect from -qvisibility=hidden.
>> >> >
>> >>
>> >> Where in this article do you read this?
>> >>
>> >> ..Thomas
>> >>
>> >> > Best regards
>> >> > Christoph
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On
>> Behalf
>> >> Of
>> >> >> Thomas St?fe
>> >> >> Sent: Freitag, 27. April 2018 06:55
>> >> >> To: Volker Simonis <volker.simonis at gmail.com>; Baesken, Matthias
>> >> >> <matthias.baesken at sap.com>
>> >> >> Cc: Simonis, Volker <volker.simonis at sap.com>; ppc-aix-port-
>> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net; build-
>> >> >> dev at openjdk.java.net
>> >> >> Subject: Re: RFR : 8202322: AIX: symbol visibility flags not support on xlc
>> >> 12.1
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> This was added by "8200178: Remove mapfiles for JDK native libraries".
>> >> >> But if the flag is not accepted, what is the default behavior? Do we
>> >> >> now export everything?
>> >> >>
>> >> >> I'd like to understand this first before removing the flag to get rid
>> >> >> of the warnings.
>> >> >>
>> >> >> Best Regards, Thomas
>> >> >>
>> >> >> On Thu, Apr 26, 2018 at 5:16 PM, Volker Simonis
>> >> >> <volker.simonis at gmail.com> wrote:
>> >> >> > Hi Matthias,
>> >> >> >
>> >> >> > after Bhaktavatsal Reddy's report about the problems with
>> >> >> > "-qvisibility" with xlC 13 and taking into account that we can't test
>> >> >> > this anyway because we don't currently have xlC 13
>> >> >> >  on our machines I think it would be best to completely remove this
>> >> >> > option for now on AIX. Once we get xlC 13 we can revisit the issue.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Volker
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Apr 26, 2018 at 4:59 PM, Bhaktavatsal R Maram
>> >> >> > <bhamaram at in.ibm.com> wrote:
>> >> >> >> Hi Matthias,
>> >> >> >>
>> >> >> >> At this point, I think we can remove the flag as you found that it is
>> not
>> >> >> supported in XLC < 13. And with XLC 13, it require more work to use
>> this
>> >> flag.
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >> Bhaktavatsal Reddy
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> -----"Baesken, Matthias" <matthias.baesken at sap.com> wrote: ----
>> -
>> >> >> >> To: "Langer, Christoph" <christoph.langer at sap.com>, "'build-
>> >> >> dev at openjdk.java.net'" <build-dev at openjdk.java.net>, "ppc-aix-
>> port-
>> >> >> dev at openjdk.java.net" <ppc-aix-port-dev at openjdk.java.net>, "core-
>> >> libs-
>> >> >> dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
>> >> >> >> From: "Baesken, Matthias" <matthias.baesken at sap.com>
>> >> >> >> Date: 04/26/2018 08:23PM
>> >> >> >> Cc: "Simonis, Volker" <volker.simonis at sap.com>, Bhaktavatsal R
>> >> Maram
>> >> >> <bhamaram at in.ibm.com>
>> >> >> >> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on
>> xlc
>> >> >> 12.1
>> >> >> >>
>> >> >> >>
>> >> >> >>  Hello Christoph,   I think  all XLC versions  < 12.1   are unsupported
>> >> (and
>> >> >> probably not working anyway)  for the OpenJDK  build .
>> >> >> >>  I am only aware   of  XLC  versions  12.1  and 13.1    which  work / in
>> case
>> >> of
>> >> >> 13.1  ?might? work   for OpenJDK compilation .
>> >> >> >>  And for 12.1  I want to remove the flags  .
>> >> >> >>
>> >> >> >>  ( waiting for the feedback  of   Bhaktavatsal Reddy ,  in case he
>> prefers
>> >> it
>> >> >> I remove them for all xlC versions including 13.1 )
>> >> >> >>
>> >> >> >>  Best regards, Matthias
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>  From: Langer, Christoph
>> >> >> >>  Sent: Donnerstag, 26. April 2018 16:38
>> >> >> >>  To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> >> >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; ppc-aix-port-
>> >> >> dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >> >> >>  Cc: Simonis, Volker <volker.simonis at 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 at openjdk.java.net' <build-dev at openjdk.java.net>;
>> >> ppc-
>> >> >> aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> >> >> >>  Cc: Langer, Christoph <christoph.langer at sap.com>; Simonis,
>> Volker
>> >> >> <volker.simonis at 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
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>


From thomas.stuefe at gmail.com  Fri Apr 27 16:26:39 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 18:26:39 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
 <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
Message-ID: <CAA-vtUzkFi-oKySpBqk7ne-NJ6AiMcz5e1FcSEqcWfoPDt9dUw@mail.gmail.com>

This patch looks fine.

I also welcome Kim's proposal of reverting back to readdir(). We
should do this for JDK libraries too, there are still open issues
(e.g. https://bugs.openjdk.java.net/browse/JDK-8166372).

Best Regards, Thomas

On Fri, Apr 27, 2018 at 10:56 AM, Michal Vala <mvala at redhat.com> wrote:
>
>
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>>
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com>
>>> wrote:
>>>
>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>>
>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm
>>>>> posting updated patch replacing deprecated readdir_r with readdir. Bug ID is
>>>>> JDK-8179887 [2].
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>>
>>>>> I'm asking for the review and eventually sponsorship.
>>>>
>>>>
>>>
>>> The patch looks good to me.
>>>
>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>>
>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to
>>>> use os::readdir in an
>>>> unusual and platform-specific way, it should instead just call ::readdir
>>>> directly.  However, neither
>>>> of those is right, and that part of the change should not be made; see
>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>> Much nearly duplicated code for PerfMemory support
>>>>
>>>
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and
>>> remove
>>> a couple of unneeded memory allocations.
>>>
>>>> Looking a bit deeper, there might be some additional follow-on that
>>>> could be done, eliminating
>>>> the second argument to os::readdir.
>>>> windows: unused
>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>> solaris: doc is clear about thread safety issue being about sharing the
>>>> DIR*
>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>>
>>>> In other words, don?t operate on the DIR* from multiple threads
>>>> simultaneously, and just use
>>>> ::readdir on non-Windows.  That would all be for another RFE though.
>>>>
>>>>
>>>
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>>
>>
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>>
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>>
>> (2) It violates the (implied) protocol for os::readdir.  If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>>
>> (3) It minorly interferes with some desirable future work.  If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>>
>> (4) The only benefit is saving some rare short-term memory
>> allocations.  I don't think that's worth the above costs.
>>
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>>
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>
>
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest
> can be solved in JDK-8202353, which should imho include also removal of
> second argument of os::readdir, once it's unused.
>
> For now, proposed patch looks like this:
>
> --- old/src/hotspot/os/linux/os_linux.inline.hpp        2018-04-20
> 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp        2018-04-20
> 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
>
>  inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>  {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more
> details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> -  dirent* p;
> -  int status;
>    assert(dirp != NULL, "just checking");
> -
> -  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the
> POSIX
> -  // version. Here is the doc for this function:
> -  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> -  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> -    errno = status;
> -    return NULL;
> -  } else
> -    return p;
> -
> -#pragma GCC diagnostic pop
> +  return ::readdir(dirp);
>  }
>
>  inline int os::closedir(DIR *dirp) {
>
>
>
>
> --
> Michal Vala
> OpenJDK QE
> Red Hat Czech


From erik.joelsson at oracle.com  Fri Apr 27 16:43:48 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 27 Apr 2018 09:43:48 -0700
Subject: Contribution to make/Docs.gmk
In-Reply-To: <OF03FB75A4.C69B6721-ON0025827C.0039781B-8025827C.0039D606@notes.na.collabserv.com>
References: <OF70F93106.BE1032AA-ON0025824A.004E19D2-8025824A.0051A38C@notes.na.collabserv.com>
 <602a6b5f-2ac9-615c-c166-1acf3ded9a44@oracle.com>
 <OF0291D502.2C215E3C-ON0025824B.0046A32D-8025824B.00477120@notes.na.collabserv.com>
 <963d41da-904f-1119-cc6c-a2937e66a87e@oracle.com>
 <OF953C9EF3.728F679C-ON00258278.00562C3D-80258279.00358245@LocalDomain>
 <OF03FB75A4.C69B6721-ON0025827C.0039781B-8025827C.0039D606@notes.na.collabserv.com>
Message-ID: <a8c58e19-fe96-9ac0-51ac-c18155b5f2f5@oracle.com>

Looks good, I will take care of this and the other contribution.

/Erik


On 2018-04-27 03:31, Archana Nogriya wrote:
> I am looking for reviewer and sponsor for this contribution, Is anyone who
> can review this please and happy to sponsor for this contribution as
> appropriate.
>
> Hi,
>
> "make/Docs.gmk", JDK_MODULES is only sorted with DOCS_MODULES, where It
> should also filter-out MODULES_FILTER for javadocs modules.
>
> # All modules to have docs generated by docs-jdk-api target
>>> -JDK_MODULES := $(sort $(DOCS_MODULES))
>>> +JDK_MODULES := $(sort $(filter-out $(MODULES_FILTER),
> $(DOCS_MODULES)))
>   
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: archana.nogriya at uk.ibm.com
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From kim.barrett at oracle.com  Fri Apr 27 16:50:04 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 12:50:04 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
 <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
Message-ID: <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>

> On Apr 27, 2018, at 4:56 AM, Michal Vala <mvala at redhat.com> wrote:
> 
> 
> 
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>> 
>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>> 
>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>> 
>>>>> I'm asking for the review and eventually sponsorship.
>>>> 
>>> 
>>> The patch looks good to me.
>>> 
>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>> 
>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>>> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
>>>> of those is right, and that part of the change should not be made; see
>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>> Much nearly duplicated code for PerfMemory support
>>>> 
>>> 
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and remove
>>> a couple of unneeded memory allocations.
>>> 
>>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>>> the second argument to os::readdir.
>>>> windows: unused
>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>> 
>>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>>> ::readdir on non-Windows.  That would all be for another RFE though.
>>>> 
>>>> 
>>> 
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>> (2) It violates the (implied) protocol for os::readdir.  If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>> (3) It minorly interferes with some desirable future work.  If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>> (4) The only benefit is saving some rare short-term memory
>> allocations.  I don't think that's worth the above costs.
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
> 
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can be solved in JDK-8202353, which should imho include also removal of second argument of os::readdir, once it's unused.
> 
> For now, proposed patch looks like this:
> 
> --- old/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
> 
> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
> {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> -  dirent* p;
> -  int status;
>   assert(dirp != NULL, "just checking");
> -
> -  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
> -  // version. Here is the doc for this function:
> -  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> -  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> -    errno = status;
> -    return NULL;
> -  } else
> -    return p;
> -
> -#pragma GCC diagnostic pop
> +  return ::readdir(dirp);
> }
> 
> inline int os::closedir(DIR *dirp) {

This looks good.



From erik.joelsson at oracle.com  Fri Apr 27 17:05:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 27 Apr 2018 10:05:44 -0700
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
 <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
Message-ID: <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>

Looking at this again, the first part, in Main.gmk, has already been 
addressed in https://bugs.openjdk.java.net/browse/JDK-8198425. The patch 
for the second part looks weird. The only real change I can see is the 
?= for the jvmti.html file. The rest looks like there is no difference 
(and I cannot think of any change needed there either).

/Erik


On 2018-04-27 02:12, Archana Nogriya wrote:
> Thanks Erik,
>
> It will be great if you can sponsor for this contribution please.
>
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: archana.nogriya at uk.ibm.com
>
>
>
> From: Erik Joelsson <erik.joelsson at oracle.com>
> To: Archana Nogriya <archana.nogriya at uk.ibm.com>, 
> build-dev at openjdk.java.net
> Cc: David Holmes <david.holmes at oracle.com>
> Date: 26/04/2018 17:15
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Looks reasonable.
> /Erik
>
> On 2018-04-26 04:00, Archana Nogriya wrote:
> If we have a conditional variable to set 
> "hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
> alternate VMs like eclipse openj9 to extend that to set it appropriately.
>
> diff --git a/make/Main.gmk b/make/Main.gmk
> index 731e9c9934..444a835cb4 100644
> --- a/make/Main.gmk
> +++ b/make/Main.gmk
> @@ -830,7 +830,8 @@ else
> ? ?docs-reference-api-modulegraph: exploded-image buildtools-modules
>
> ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files.
> - ?docs-jdk-specs: jdk.jdi-gensrc \
> + ?JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
> + ?docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
> ? ? ? ?docs-jdk-index
>
>
> ######################################################################################
>
> diff --git a/make/Docs.gmk b/make/Docs.gmk
> index 644ffbf74a..73ffb8ebd2 100644
> --- a/make/Docs.gmk
> +++ b/make/Docs.gmk
> @@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
> ?JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)
>
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ? ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ? ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Note: This proposal has been tested in local.
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: _archana.nogriya at uk.ibm.com_ <mailto:archana.nogriya at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From jiangli.zhou at oracle.com  Fri Apr 27 19:22:11 2018
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 27 Apr 2018 12:22:11 -0700
Subject: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete
In-Reply-To: <c71a0194-ef8e-44d4-f3c1-278be4cd2242@oracle.com>
References: <4419F813-6D9E-438C-9E04-0FAA614A8D28@oracle.com>
 <e998454b-f5ef-28d5-44a8-49ae46477ab4@oracle.com>
 <ACB2A5AB-2615-4480-8780-142EA74AC8C9@oracle.com>
 <0966488f-ca62-789a-6c82-957af4f5bb8f@oracle.com>
 <C9DD615A-8904-4AAD-8040-1655DBE2312E@oracle.com>
 <8EABAF6E-20ED-4EFB-B62E-9BD5065FAB89@oracle.com>
 <e36bd45e-a7d2-d682-66d0-c1707b405767@oracle.com>
 <13E80BF1-2694-4F5B-A39E-B53FB1EA7BD6@oracle.com>
 <c71a0194-ef8e-44d4-f3c1-278be4cd2242@oracle.com>
Message-ID: <0388D456-9A67-43A4-BE9F-136C912E5AEE@oracle.com>


> On Apr 27, 2018, at 1:43 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 27/04/2018 4:20 AM, Jiangli Zhou wrote:
>>> On Apr 25, 2018, at 10:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> On 26/04/2018 2:34 PM, Jiangli Zhou wrote:
>>>> Here is the incremental webrev with updates that incorporate all feedbacks:
>>>> http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev_inc.02/
>>> 
>>> Looks good.
>> Thanks!
>>> 
>>> One additional comment on test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java - it seems insufficient to just check the output for the word "dump". I would expect to see something more definitively associated with -Xshare:dump and also a check that it exited cleanly (in case we find "core dump?).
> 
> I should have of course said "the word Dumping" and "in case we find 'Dumping core'". :)
> 
>> With other test cases being removed from appcds/SharedArchiveFile.java, I just realized that the test now essentially is the same as the jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java test. SharedArchiveFile/SharedArchiveFile.java includes more robust checks as you suggested and also tests runtime. Your comments above (and fresh morning coffee) reminded me that. :-) So I went ahead removed the appcds/SharedArchiveFile.java. Please let me know if you want to see the new webrev.
> 
> No that's fine. Removing the file completely makes sense.

Thanks!

Jiangli

> 
> Thanks,
> David
> 
>> Thanks!
>> Jiangli
>>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> - Filed JDK-8202282 (https://bugs.openjdk.java.net/browse/JDK-8202282) for TestCommon.makeCommandLineForAppCDS() cleanup.
>>>> - Removed case 2, 3 and 4 in SharedArchiveFile.java.
>>>> - Removed UseAppCDS.java test.
>>>> - Removed UseAppCDS in various tests.
>>>> - Changed to keep the original version of the classlist and renamed to classlist.raw.
>>>> - Changed check_nonempty_dir_in_shared_path_table() to report all non-empty directories in the shared path table entries before exiting VM.
>>>> Full webrev:
>>>> http://java.se.oracle.com:10065/mdash/jobs/jianzhou-jdk-20180426-0406-20150
>>>> Tested all modified tests locally. Rerunning hs-tier1 ~ hs-tier5 tests.
>>>> Thanks for all the suggestions!
>>>> Jiangli
>>>>> On Apr 25, 2018, at 5:24 PM, Jiangli Zhou <jiangli.zhou at Oracle.COM> wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>>> On Apr 25, 2018, at 3:12 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Jiangli,
>>>>>> 
>>>>>> On 26/04/2018 3:39 AM, Jiangli Zhou wrote:
>>>>>>> Hi David,
>>>>>>> Thanks a lot for the review!
>>>>>>>> On Apr 24, 2018, at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> cc'ing build-dev for the makefile change
>>>>>>>> 
>>>>>>>> Hi Jiangli,
>>>>>>>> 
>>>>>>>> On 25/04/2018 10:53 AM, Jiangli Zhou wrote:
>>>>>>>>> Please review the following changes that streamline the support for application class data sharing by eliminating the requirement of using -XX:+UseAppCDS to enable the feature. The support for application class data sharing is now enabled transparently when application classes or platform classes present in the classlist or generated archive with -Xshare:dump/on/auto.
>>>>>>>>> 	RFE: https://bugs.openjdk.java.net/browse/JDK-8193213
>>>>>>>>> 	Bug: https://bugs.openjdk.java.net/browse/JDK-8182731
>>>>>>>> 
>>>>>>>> These issues are not publicly visible, can you change them to be so?
>>>>>>> Done. Thanks for noticing that!
>>>>>>>> 
>>>>>>>>> 	webrev: http://cr.openjdk.java.net/~jiangli/8193213_8182731/webrev.00/
>>>>>>>> 
>>>>>>>> Overall this seems fine. Thanks for explaining the logic changes below - much appreciated!
>>>>>>>> 
>>>>>>>> One query: why was UseAppCDS not removed from the tests (or at least the tests you were modifying anyway) ? They will all need updating before 12 when the flag is expired.
>>>>>>> The usages are left as backwards compatibility check. They also serve the testing purpose to make sure the presence of the flag does not cause any unexpected behavior. Those are the main reasons why I didn?t remove the flag usages in this webrev.
>>>>>> 
>>>>>> This sounds like you are basically testing whether obsoleting the flag has worked correctly.
>>>>> 
>>>>> Right, that was part of the intention.
>>>>> 
>>>>>> You don't need to do that through formal testing. A simple run of "java -XX:+UseAppCDS" should show the obsoletion warning and that's that. We don't maintain an obsolete flag test the way we do for deprecated flags.
>>>>> 
>>>>> That sounds reasonable.
>>>>> 
>>>>>> 
>>>>>> So IMHO there's really no reason to keep the flag in any of the tests. As I said they will all have to be removed when the flag is expired in 12.
>>>>> 
>>>>> Ok. I?ll remove the flag from the tests.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Jiangli
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>>>> 
>>>>>>>> test/hotspot/jtreg/runtime/appcds/SharedArchiveFile.java
>>>>>>>> 
>>>>>>>> Test 2 reference to UseAppCDS seems unnecessary now.
>>>>>>>> Test 3 is not needed as you're not using any diagnostic flag now.
>>>>>>>> Test 4 seems unnecessary now.
>>>>>>> Will do.
>>>>>>>> 
>>>>>>>> test/hotspot/jtreg/runtime/appcds/TestCommon.java
>>>>>>>> 
>>>>>>>> makeCommandLineForAppCDS should just be removed (yes that will cause some churn in the other tests) - but this can be a follow up test cleanup.
>>>>>>> Ok.
>>>>>>>> 
>>>>>>>> test/hotspot/jtreg/runtime/appcds/UseAppCDS.java
>>>>>>>> 
>>>>>>>> This test no longer makes much sense to me. The only tests should be that app classes get archived and used. It makes no sense to claim to be testing -XX:+UseAppCDS when that flag is obsolete. Likewise now that it is obsolete you don't need to test that -XX:-UseAppCDS has no affect.
>>>>>>> Sounds reasonable. I?ll remove UseAppCDS.java. There are existing tests that check app classes get archived and used.
>>>>>>> Thanks!
>>>>>>> Jiangli
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Highlights of the changes:
>>>>>>>>> * UseAppCDS is obsolete in JDK 11
>>>>>>>>> * Remove the +UnlockCommercialFeatures requirement when using application class data sharing in OracleJDK binary
>>>>>>>>> * SharedArchiveFile is a product flag for all configurations in JDK 11
>>>>>>>>> * DumpLoadedClassList produces a complete classlist including all loaded library and application classes
>>>>>>>>> Thanks David Holmes for his guidance on CSR process.
>>>>>>>>> Following are the details for the VM and test changes:
>>>>>>>>> - Removed various ?if (UseAppCDS)? checks and UseAppCDS asserts.
>>>>>>>>> - Removed some of the CDS/AppCDS specifics from general class loading code.
>>>>>>>>> - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible:
>>>>>>>>>  - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
>>>>>>>>>  - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path
>>>>>>>>> - Removed unnecessary ?if (!DumpSharedSpaces)? from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled.
>>>>>>>>> - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes.
>>>>>>>>> - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this.
>>>>>>>>> - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged.
>>>>>>>>>  - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests
>>>>>>>>>  - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests
>>>>>>>>>  - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS
>>>>>>>>>  - Updated DirClasspathTest.java: reflect the change for non-empty directory handling
>>>>>>>>>  - Updated MismatchedUseAppCDS.java:  -XX:-UseAppCDS has no effect
>>>>>>>>> Tested with all cds and appcds tests locally with both fastdebug and release builds. Tested with hs-teir1, hs-tier2, jdk-tier1 and jdk-tier2. The hs-tier3, hs-tier4 and hs-tier4 are in progress.
>>>>>>>>> Thanks,
>>>>>>>>> Jiangli
>>>>> 



From mvala at redhat.com  Fri Apr 27 20:26:56 2018
From: mvala at redhat.com (Michal Vala)
Date: Fri, 27 Apr 2018 22:26:56 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
 readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
 <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
 <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
 <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
 <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
 <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
Message-ID: <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com>



On 04/27/2018 06:50 PM, Kim Barrett wrote:
>> On Apr 27, 2018, at 4:56 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>>
>>
>> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>>
>>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>>>
>>>>>> I'm asking for the review and eventually sponsorship.
>>>>>
>>>>
>>>> The patch looks good to me.
>>>>
>>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>>>
>>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>>>> unusual and platform-specific way, it should instead just call ::readdir directly.  However, neither
>>>>> of those is right, and that part of the change should not be made; see
>>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>>> Much nearly duplicated code for PerfMemory support
>>>>>
>>>>
>>>> I think, in the circumstances, Michal's solution is the best option at
>>>> this point.
>>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>>> anyone currently working on it?), whereas this fix could go into 11 and remove
>>>> a couple of unneeded memory allocations.
>>>>
>>>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>>>> the second argument to os::readdir.
>>>>> windows: unused
>>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>>>
>>>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>>>> ::readdir on non-Windows.  That would all be for another RFE though.
>>>>>
>>>>>
>>>>
>>>> This also seems like a more in-depth separate change and not one that
>>>> can be performed
>>>> by any of us alone, as we don't test all these platforms. As it
>>>> stands, Michal's change affects
>>>> Linux and Linux alone, and the addition of the use of NULL will make
>>>> it clearer that moving
>>>> to an os:readdir is feasible on that platform.
>>> I disagree, and still think the perfMemory_linux.cpp change should be
>>> removed.
>>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>>> address the problem this bug is about.
>>> (2) It violates the (implied) protocol for os::readdir.  If
>>> Linux-specific code wants to invoke Linux-specific behavior, it should
>>> do so by calling a Linux-specific API, not abuse an intended to be
>>> portable API.
>>> (3) It minorly interferes with some desirable future work.  If there
>>> were some significant benefit to doing so, I wouldn't give this much
>>> weight, but I don't see a significant benefit.
>>> (4) The only benefit is saving some rare short-term memory
>>> allocations.  I don't think that's worth the above costs.
>>> Note that the Windows version of os::readdir also ignores the second
>>> argument, but all callers provide it anyway.
>>> I've opened a new CR for general os::readdir cleanup.
>>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>
>> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can be solved in JDK-8202353, which should imho include also removal of second argument of os::readdir, once it's unused.
>>
>> For now, proposed patch looks like this:
>>
>> --- old/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.498343185 +0200
>> +++ new/src/hotspot/os/linux/os_linux.inline.hpp	2018-04-20 09:16:34.214342670 +0200
>> @@ -98,26 +98,8 @@
>>
>> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> {
>> -// readdir_r has been deprecated since glibc 2.24.
>> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>> -
>> -  dirent* p;
>> -  int status;
>>    assert(dirp != NULL, "just checking");
>> -
>> -  // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
>> -  // version. Here is the doc for this function:
>> -  // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
>> -
>> -  if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
>> -    errno = status;
>> -    return NULL;
>> -  } else
>> -    return p;
>> -
>> -#pragma GCC diagnostic pop
>> +  return ::readdir(dirp);
>> }
>>
>> inline int os::closedir(DIR *dirp) {
> 
> This looks good.
> 

Thanks!
Someone to sponsor this please?

-- 
Michal Vala
OpenJDK QE
Red Hat Czech


From david.holmes at oracle.com  Fri Apr 27 23:25:51 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Apr 2018 09:25:51 +1000
Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug
 builds for DevStudio 12.6
In-Reply-To: <43683acb-7f30-e79a-42dc-0d4693e2ac21@oracle.com>
References: <5AE1FFD0.1090803@oracle.com>
 <dec8c80a-41a6-57ce-7791-351d4d5e0b32@oracle.com>
 <CD7ED9D5-901E-4ECE-B302-E96CCE13B7ED@oracle.com>
 <bfb03010-70b0-efe5-b59f-78f3a36b21b5@oracle.com>
 <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com>
 <43683acb-7f30-e79a-42dc-0d4693e2ac21@oracle.com>
Message-ID: <4df85ebd-aca1-46fe-8104-5c6f50517256@oracle.com>

We discussed this offline and Gary pointed out that, at least in the 
VMError case the attempt to SEGV by dereferencing zero is one of a 
specific number of crash inducing cases, others of which include trying 
to trigger SEGV at non-zero address and explicit signal raising. So 
changing the code to raise the signal directly is not really appropriate 
- and the code in VMError knows the attempt may not result in a crash.

So I am okay with just disabling the compilation warnings for these two 
cases.

Thanks,
David

On 27/04/2018 6:59 PM, David Holmes wrote:
> On 27/04/2018 4:48 PM, Kim Barrett wrote:
>>> On Apr 27, 2018, at 2:11 AM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> On 27/04/2018 3:32 PM, Kim Barrett wrote:
>>>>> On Apr 26, 2018, at 6:49 PM, gary.adams at oracle.com wrote:
>>>>>
>>>>> Adding build-dev and hotspot-runtime-dev aliases.
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject:???? RFR: JDK-8202319: Fix compilation warnings in Solaris 
>>>>> debug builds for DevStudio 12.6
>>>>> Date:???? Thu, 26 Apr 2018 12:35:28 -0400
>>>>> From:???? Gary Adams <gary.adams at oracle.com>
>>>>> Reply-To:???? gary.adams at oracle.com
>>>>> To:???? OpenJDK Serviceability <serviceability-dev at openjdk.java.net>
>>>>>
>>>>>
>>>>>
>>>>> Getting the sources ready for the next Solaris developer studio 
>>>>> toolchain.
>>>>> Some additional warnings were found in the debug build.
>>>>>
>>>>> ?? Issue:https://bugs.openjdk.java.net/browse/JDK-8202319
>>>>> ?? Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/
>>>>>
>>>>> This update conditionally disables some new error checks, if the
>>>>> new toolchain is used.
>>>> I looked at these, and the warnings are correct, so just disabling 
>>>> them is a bit troubling.
>>>> The thing is, the code in both cases is attempting to intentionally 
>>>> provoke a crash.
>>>> But because the code is invoking undefined behavior, executing it 
>>>> might actually do
>>>> anything, or nothing at all.? So while suppressing the warning might 
>>>> permit compilation,
>>>> it?s not at all obvious that the compilation will produce anything 
>>>> like the desired code.
>>>> And that?s also true for platforms that aren?t warning?
>>>
>>> True. Perhaps we should just raise a SEGV directly?
>>>
>>> David
>>
>> I like that idea.
> 
> Hopefully this should work:
> 
> os::signal_raise(os::get_signal_number("SEGV"));
> 
> Cheers,
> David


From fweimer at redhat.com  Mon Apr 30 10:37:32 2018
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 30 Apr 2018 12:37:32 +0200
Subject: =?UTF-8?Q?Re:_jdk_build_fails_due_to_=22warning:_=e2=80=98readdir?=
 =?UTF-8?B?X3LigJkgaXMgZGVwcmVjYXRlZCI=?=
In-Reply-To: <014afaec-be76-15d5-8ed4-21d64557b130@oracle.com>
References: <CAA-vtUyz7dTqzy_6+ywupKP8y1FA6yuS4xnBQi6j-n+8qG7qNw@mail.gmail.com>
 <d1d782e5-3181-805d-c001-e5a179461cd8@oracle.com>
 <bf539c94-d96b-cdd4-ce5d-c94fa53a5389@oracle.com>
 <CAA-vtUz1g5nB1xyaFLrr9_cgsHE9rmgsAsXS2e0PZNHqJ0u1yA@mail.gmail.com>
 <09687e17-3bd7-71e7-9a1b-6aebf04fa602@oracle.com>
 <014afaec-be76-15d5-8ed4-21d64557b130@oracle.com>
Message-ID: <981d7c54-416a-9f8a-dcab-624bbbf55127@redhat.com>

On 04/05/2018 03:14 PM, David Holmes wrote:
> Sure, but "generally unnecessary in multithreaded programs" doesn't 
> quite cut it when it comes to correctness. So we have a couple of 
> obscure cases where readdir_r may do the wrong thing and we have a 
> subset of cases where readdir may be thread-safe "enough"; and hopefully 
> one day POSIX will specify it as thread-safe and all will be well in world.
> 
> Until such time as that happens IMHO we stick with the code we that 
> seems to be working perfectly fine and disable the warning.

readdir_r does not work reliably on SMB mounts on GNU/Linux.  If you use 
it, you have a real bug.

readdir_r was introduced to deal with systems which implement opendir as 
a cast of the file descriptor to a DIR *, without allocating anything. 
Such systems do not exist anymore, and they certainly do not run OpenJDK.

Thanks,
Florian


From archana.nogriya at uk.ibm.com  Mon Apr 30 11:14:27 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Mon, 30 Apr 2018 12:14:27 +0100
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
 <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
 <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>
Message-ID: <OFBBBBB20B.4CC17008-ON0025827F.003C3F2D-8025827F.003DC3C0@notes.na.collabserv.com>

Thanks Erik agree with you, the changes from JDK11 you mentioned is very 
similar to what I propose and that will serve the purpose.

However the patch for the second part is related to locating jvmti.html, 
VM's like openj9 has it's own html specs file in different location hence 
we need extension to set it appropriately. 

#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-    FILES := $(JVMTI_HTML), \ 
-    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+    FILES := $(JVMTI_HTML), \ 
+    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 

Thanks and Regards
Archana Nogriya 




From:   Erik Joelsson <erik.joelsson at oracle.com>
To:     Archana Nogriya <archana.nogriya at uk.ibm.com>
Cc:     build-dev at openjdk.java.net, David Holmes <david.holmes at oracle.com>
Date:   27/04/2018 18:05
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs



Looking at this again, the first part, in Main.gmk, has already been 
addressed in https://bugs.openjdk.java.net/browse/JDK-8198425. The patch 
for the second part looks weird. The only real change I can see is the ?= 
for the jvmti.html file. The rest looks like there is no difference (and I 
cannot think of any change needed there either).
/Erik

On 2018-04-27 02:12, Archana Nogriya wrote:
Thanks Erik, 

It will be great if you can sponsor for this contribution please.   


Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com 



From:        Erik Joelsson <erik.joelsson at oracle.com> 
To:        Archana Nogriya <archana.nogriya at uk.ibm.com>, 
build-dev at openjdk.java.net 
Cc:        David Holmes <david.holmes at oracle.com> 
Date:        26/04/2018 17:15 
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs 



Looks reasonable. 
/Erik 

On 2018-04-26 04:00, Archana Nogriya wrote: 
If we have a conditional variable to set "
hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately. 

diff --git a/make/Main.gmk b/make/Main.gmk 
index 731e9c9934..444a835cb4 100644 
--- a/make/Main.gmk 
+++ b/make/Main.gmk 
@@ -830,7 +830,8 @@ else 
   docs-reference-api-modulegraph: exploded-image buildtools-modules 
  
   # The gensrc steps for hotspot and jdk.jdi create html spec files. 
-  docs-jdk-specs: jdk.jdi-gensrc \ 
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc 
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \ 
       docs-jdk-index 


###################################################################################### 


diff --git a/make/Docs.gmk b/make/Docs.gmk 
index 644ffbf74a..73ffb8ebd2 100644 
--- a/make/Docs.gmk 
+++ b/make/Docs.gmk 
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ 
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL) 
  
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-    FILES := $(JVMTI_HTML), \ 
-    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+    FILES := $(JVMTI_HTML), \ 
+    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
  
Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From erik.joelsson at oracle.com  Mon Apr 30 15:14:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 08:14:11 -0700
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <OFBBBBB20B.4CC17008-ON0025827F.003C3F2D-8025827F.003DC3C0@notes.na.collabserv.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
 <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
 <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>
 <OFBBBBB20B.4CC17008-ON0025827F.003C3F2D-8025827F.003DC3C0@notes.na.collabserv.com>
Message-ID: <6280d77d-6dd1-870e-ff06-cc3fddcf0fc5@oracle.com>

Hello,

On 2018-04-30 04:14, Archana Nogriya wrote:
>
> However the patch for the second partis related to locating 
> jvmti.html, VM's like openj9 has it's own html specs file in different 
> location hence we need extension to set it appropriately.
>
Yes, I see the reason for the change, but my concern was that the patch 
below looks like it's changing 6 lines, but in reality, I can only see a 
difference in one of them. That difference is also the only difference 
needed as far as I can see. I just want confirmation that that is the case.

/Erik
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ? ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ? ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Thanks and Regards
> Archana Nogriya
>
>
>
>
> From: Erik Joelsson <erik.joelsson at oracle.com>
> To: Archana Nogriya <archana.nogriya at uk.ibm.com>
> Cc: build-dev at openjdk.java.net, David Holmes <david.holmes at oracle.com>
> Date: 27/04/2018 18:05
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Looking at this again, the first part, in Main.gmk, has already been 
> addressed in _https://bugs.openjdk.java.net/browse/JDK-8198425_ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8198425&d=DwMD-g&c=jf_iaSHvJObTbx-siA1ZOg&r=-MGd855q-LKvODp9rnOf8dEjvpiN59orrOxhf9virII&m=3vzRAU-D2yC7wKbEcUUaW00BZqwtnO0QE2mLK2bedww&s=MTZyeZsgQdHG_dxjTKHpcljddxJiFvJBfxSsSxchz8k&e=>. 
> The patch for the second part looks weird. The only real change I can 
> see is the ?= for the jvmti.html file. The rest looks like there is no 
> difference (and I cannot think of any change needed there either).
> /Erik
>
> On 2018-04-27 02:12, Archana Nogriya wrote:
> Thanks Erik,
>
> It will be great if you can sponsor for this contribution please.
>
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: _archana.nogriya at uk.ibm.com_ <mailto:archana.nogriya at uk.ibm.com>
>
>
>
> From: Erik Joelsson _<erik.joelsson at oracle.com>_ 
> <mailto:erik.joelsson at oracle.com>
> To: Archana Nogriya _<archana.nogriya at uk.ibm.com>_ 
> <mailto:archana.nogriya at uk.ibm.com>, _build-dev at openjdk.java.net_ 
> <mailto:build-dev at openjdk.java.net>
> Cc: David Holmes _<david.holmes at oracle.com>_ 
> <mailto:david.holmes at oracle.com>
> Date: 26/04/2018 17:15
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Looks reasonable.
> /Erik
>
> On 2018-04-26 04:00, Archana Nogriya wrote:
> If we have a conditional variable to set 
> "hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
> alternate VMs like eclipse openj9 to extend that to set it appropriately.
>
> diff --git a/make/Main.gmk b/make/Main.gmk
> index 731e9c9934..444a835cb4 100644
> --- a/make/Main.gmk
> +++ b/make/Main.gmk
> @@ -830,7 +830,8 @@ else
> ? ?docs-reference-api-modulegraph: exploded-image buildtools-modules
>
> ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files.
> - ?docs-jdk-specs: jdk.jdi-gensrc \
> + ?JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
> + ?docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
> ? ? ? ?docs-jdk-index
>
>
> ######################################################################################
>
> diff --git a/make/Docs.gmk b/make/Docs.gmk
> index 644ffbf74a..73ffb8ebd2 100644
> --- a/make/Docs.gmk
> +++ b/make/Docs.gmk
> @@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
> ?JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)
>
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ? ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ? ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Note: This proposal has been tested in local.
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: _archana.nogriya at uk.ibm.com_ <mailto:archana.nogriya at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From erik.joelsson at oracle.com  Mon Apr 30 15:34:54 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 08:34:54 -0700
Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10
In-Reply-To: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
Message-ID: <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com>

Hello,

I'm re-starting this review with the original proposed patch. This 
changes the required boot-JDK in configure from the set "9 10 or 11" to 
"10 or 11". It also changes what Oracle uses in its automated build 
environment setup from 9 GA to 10 GA.

I do this based on the proposal [1] to retain the historical N - 1 
boot-JDK policy, which has not met any objections yet.

http://cr.openjdk.java.net/~erikj/8200083/webrev.01/

/Erik

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html

On 2018-03-21 14:51, Erik Joelsson wrote:
> Now that JDK 10 has been officially released we can update the boot 
> jdk requirement for JDK 11. Cross posting this to jdk-dev to raise 
> awareness of this rather disruptive change.
>
> This patch changes the requirement on boot jdk version in configure 
> (and updates the configuration that controls what JDK to use as boot 
> in Oracle's internal build system).
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>
> /Erik
>



From archana.nogriya at uk.ibm.com  Mon Apr 30 15:51:00 2018
From: archana.nogriya at uk.ibm.com (Archana Nogriya)
Date: Mon, 30 Apr 2018 16:51:00 +0100
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <6280d77d-6dd1-870e-ff06-cc3fddcf0fc5@oracle.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
 <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
 <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>
 <OFBBBBB20B.4CC17008-ON0025827F.003C3F2D-8025827F.003DC3C0@notes.na.collabserv.com>
 <6280d77d-6dd1-870e-ff06-cc3fddcf0fc5@oracle.com>
Message-ID: <OFA332C576.81BD0591-ON0025827F.0056AEA1-8025827F.005715C4@notes.na.collabserv.com>

Ahh I see , some reason git diff gave this wired result :).

Right so change is only one line,
JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html 


adding conditional parameter and then in our extension we can set 
JVMTI_HTML with openj9 specs html.

Thanks Erik,


Thanks and Regards
Archana Nogriya 




From:   Erik Joelsson <erik.joelsson at oracle.com>
To:     Archana Nogriya <archana.nogriya at uk.ibm.com>
Cc:     build-dev at openjdk.java.net, David Holmes <david.holmes at oracle.com>
Date:   30/04/2018 16:14
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs



Hello,
On 2018-04-30 04:14, Archana Nogriya wrote:

However the patch for the second part is related to locating jvmti.html, 
VM's like openj9 has it's own html specs file in different location hence 
we need extension to set it appropriately. 

Yes, I see the reason for the change, but my concern was that the patch 
below looks like it's changing 6 lines, but in reality, I can only see a 
difference in one of them. That difference is also the only difference 
needed as far as I can see. I just want confirmation that that is the 
case. 

/Erik
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-    FILES := $(JVMTI_HTML), \ 
-    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+    FILES := $(JVMTI_HTML), \ 
+    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 

Thanks and Regards
Archana Nogriya 




From:        Erik Joelsson <erik.joelsson at oracle.com> 
To:        Archana Nogriya <archana.nogriya at uk.ibm.com> 
Cc:        build-dev at openjdk.java.net, David Holmes 
<david.holmes at oracle.com> 
Date:        27/04/2018 18:05 
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs 



Looking at this again, the first part, in Main.gmk, has already been 
addressed in https://bugs.openjdk.java.net/browse/JDK-8198425. The patch 
for the second part looks weird. The only real change I can see is the ?= 
for the jvmti.html file. The rest looks like there is no difference (and I 
cannot think of any change needed there either). 
/Erik 

On 2018-04-27 02:12, Archana Nogriya wrote: 
Thanks Erik, 

It will be great if you can sponsor for this contribution please.   


Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com 



From:        Erik Joelsson <erik.joelsson at oracle.com> 
To:        Archana Nogriya <archana.nogriya at uk.ibm.com>, 
build-dev at openjdk.java.net 
Cc:        David Holmes <david.holmes at oracle.com> 
Date:        26/04/2018 17:15 
Subject:        Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
generate docs 



Looks reasonable. 
/Erik 

On 2018-04-26 04:00, Archana Nogriya wrote: 
If we have a conditional variable to set "
hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
alternate VMs like eclipse openj9 to extend that to set it appropriately. 

diff --git a/make/Main.gmk b/make/Main.gmk 
index 731e9c9934..444a835cb4 100644 
--- a/make/Main.gmk 
+++ b/make/Main.gmk 
@@ -830,7 +830,8 @@ else 
   docs-reference-api-modulegraph: exploded-image buildtools-modules 
  
   # The gensrc steps for hotspot and jdk.jdi create html spec files. 
-  docs-jdk-specs: jdk.jdi-gensrc \ 
+  JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc 
+  docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \ 
       docs-jdk-index 


###################################################################################### 


diff --git a/make/Docs.gmk b/make/Docs.gmk 
index 644ffbf74a..73ffb8ebd2 100644 
--- a/make/Docs.gmk 
+++ b/make/Docs.gmk 
@@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \ 
 JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL) 
  
#  Get jvmti.html from the main jvm variant (all variants' jvmti.html are 
identical). 
-JVMTI_HTML := 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
-$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
-    FILES := $(JVMTI_HTML), \ 
-    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
-)) 
-JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
+JVMTI_HTML ?= 
$(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
+$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \ 
+    FILES := $(JVMTI_HTML), \ 
+    DEST := $(DOCS_OUTPUTDIR)/specs, \ 
+)) 
+JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML) 
  
Note: This proposal has been tested in local.

Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogriya at uk.ibm.com 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From tim.bell at oracle.com  Mon Apr 30 16:33:22 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 30 Apr 2018 09:33:22 -0700
Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK
 10
In-Reply-To: <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com>
References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com>
 <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com>
Message-ID: <5AE74552.7@oracle.com>

Erik:
> I'm re-starting this review with the original proposed patch. This
> changes the required boot-JDK in configure from the set "9 10 or 11" to
> "10 or 11". It also changes what Oracle uses in its automated build
> environment setup from 9 GA to 10 GA.
>
> I do this based on the proposal [1] to retain the historical N - 1
> boot-JDK policy, which has not met any objections yet.
>
> http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>
> /Erik
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html

Looks good.

Tim



From erik.joelsson at oracle.com  Mon Apr 30 16:50:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 09:50:11 -0700
Subject: Extensionality Improvement in Main.gmk & Docs.gmk to generate docs
In-Reply-To: <OFA332C576.81BD0591-ON0025827F.0056AEA1-8025827F.005715C4@notes.na.collabserv.com>
References: <OF1DF60165.F05B2366-ON00258279.00475F55-8025827B.003C780C@notes.na.collabserv.com>
 <63462650-e1fe-3098-b46a-a13154f1dfb2@oracle.com>
 <OF29B87121.8482A32D-ON0025827C.002FFFF7-8025827C.00329115@notes.na.collabserv.com>
 <a8f07d84-bebf-c53d-52de-3b5d65f63bb3@oracle.com>
 <OFBBBBB20B.4CC17008-ON0025827F.003C3F2D-8025827F.003DC3C0@notes.na.collabserv.com>
 <6280d77d-6dd1-870e-ff06-cc3fddcf0fc5@oracle.com>
 <OFA332C576.81BD0591-ON0025827F.0056AEA1-8025827F.005715C4@notes.na.collabserv.com>
Message-ID: <212592ef-0e66-fd27-2ab9-90354556a2c5@oracle.com>

Thanks, both your changes have now been pushed to JDK 11.

/Erik


On 2018-04-30 08:51, Archana Nogriya wrote:
> Ahh I see , some reason git diff gave this wired result :).
>
> Right so change is only one line,
> JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
>
> adding conditional parameter and then in our extension we can set 
> JVMTI_HTMLwith openj9 specs html.
>
> Thanks Erik,
>
>
> Thanks and Regards
> Archana Nogriya
>
>
>
>
> From: Erik Joelsson <erik.joelsson at oracle.com>
> To: Archana Nogriya <archana.nogriya at uk.ibm.com>
> Cc: build-dev at openjdk.java.net, David Holmes <david.holmes at oracle.com>
> Date: 30/04/2018 16:14
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Hello,
> On 2018-04-30 04:14, Archana Nogriya wrote:
>
> However the patch for the second partis related to locating 
> jvmti.html, VM's like openj9 has it's own html specs file in different 
> location hence we need extension to set it appropriately.
>
> Yes, I see the reason for the change, but my concern was that the 
> patch below looks like it's changing 6 lines, but in reality, I can 
> only see a difference in one of them. That difference is also the only 
> difference needed as far as I can see. I just want confirmation that 
> that is the case.
>
> /Erik
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ? ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ? ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Thanks and Regards
> Archana Nogriya
>
>
>
>
> From: Erik Joelsson _<erik.joelsson at oracle.com>_ 
> <mailto:erik.joelsson at oracle.com>
> To: Archana Nogriya _<archana.nogriya at uk.ibm.com>_ 
> <mailto:archana.nogriya at uk.ibm.com>
> Cc: _build-dev at openjdk.java.net_ <mailto:build-dev at openjdk.java.net>, 
> David Holmes _<david.holmes at oracle.com>_ <mailto:david.holmes at oracle.com>
> Date: 27/04/2018 18:05
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Looking at this again, the first part, in Main.gmk, has already been 
> addressed in _https://bugs.openjdk.java.net/browse/JDK-8198425_ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8198425&d=DwMD-g&c=jf_iaSHvJObTbx-siA1ZOg&r=-MGd855q-LKvODp9rnOf8dEjvpiN59orrOxhf9virII&m=3vzRAU-D2yC7wKbEcUUaW00BZqwtnO0QE2mLK2bedww&s=MTZyeZsgQdHG_dxjTKHpcljddxJiFvJBfxSsSxchz8k&e=>. 
> The patch for the second part looks weird. The only real change I can 
> see is the ?= for the jvmti.html file. The rest looks like there is no 
> difference (and I cannot think of any change needed there either).
> /Erik
>
> On 2018-04-27 02:12, Archana Nogriya wrote:
> Thanks Erik,
>
> It will be great if you can sponsor for this contribution please.
>
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: _archana.nogriya at uk.ibm.com_ <mailto:archana.nogriya at uk.ibm.com>
>
>
>
> From: Erik Joelsson _<erik.joelsson at oracle.com>_ 
> <mailto:erik.joelsson at oracle.com>
> To: Archana Nogriya _<archana.nogriya at uk.ibm.com>_ 
> <mailto:archana.nogriya at uk.ibm.com>, _build-dev at openjdk.java.net_ 
> <mailto:build-dev at openjdk.java.net>
> Cc: David Holmes _<david.holmes at oracle.com>_ 
> <mailto:david.holmes at oracle.com>
> Date: 26/04/2018 17:15
> Subject: Re: Extensionality Improvement in Main.gmk & Docs.gmk to 
> generate docs
> ------------------------------------------------------------------------
>
>
>
> Looks reasonable.
> /Erik
>
> On 2018-04-26 04:00, Archana Nogriya wrote:
> If we have a conditional variable to set 
> "hotspot-$(JVM_VARIANT_MAIN)-gensrc" target then this can give way to 
> alternate VMs like eclipse openj9 to extend that to set it appropriately.
>
> diff --git a/make/Main.gmk b/make/Main.gmk
> index 731e9c9934..444a835cb4 100644
> --- a/make/Main.gmk
> +++ b/make/Main.gmk
> @@ -830,7 +830,8 @@ else
> ? ?docs-reference-api-modulegraph: exploded-image buildtools-modules
>
> ? ?# The gensrc steps for hotspot and jdk.jdi create html spec files.
> - ?docs-jdk-specs: jdk.jdi-gensrc \
> + ?JVM_DOCS_SPEC_TARGET ?= hotspot-$(JVM_VARIANT_MAIN)-gensrc
> + ?docs-jdk-specs: $(JVM_DOCS_SPEC_TARGET) jdk.jdi-gensrc \
> ? ? ? ?docs-jdk-index
>
>
> ######################################################################################
>
> diff --git a/make/Docs.gmk b/make/Docs.gmk
> index 644ffbf74a..73ffb8ebd2 100644
> --- a/make/Docs.gmk
> +++ b/make/Docs.gmk
> @@ -561,12 +561,12 @@ $(eval $(call SetupCopyFiles, COPY_JDWP_PROTOCOL, \
> ?JDK_SPECS_TARGETS += $(COPY_JDWP_PROTOCOL)
>
> # ?Get jvmti.html from the main jvm variant (all variants' jvmti.html 
> are identical).
> -JVMTI_HTML := 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> -$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> - ? ?FILES := $(JVMTI_HTML), \
> - ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> -))
> -JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
> +JVMTI_HTML ?= 
> $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/gensrc/jvmtifiles/jvmti.html
> +$(eval $(call SetupCopyFiles, COPY_JVMTI_HTML, \
> + ? ?FILES := $(JVMTI_HTML), \
> + ? ?DEST := $(DOCS_OUTPUTDIR)/specs, \
> +))
> +JDK_SPECS_TARGETS += $(COPY_JVMTI_HTML)
>
> Note: This proposal has been tested in local.
>
> Thanks and Regards
> Archana Nogriya
> IBM Java Runtime, Open Java Developer
> IBM Hursley
> Tel: Internal - 247073, External - +44 (0) 1962 81 7073
> Office Mobile: 07500095480
> Email: _archana.nogriya at uk.ibm.com_ <mailto:archana.nogriya at uk.ibm.com>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From igor.ignatyev at oracle.com  Mon Apr 30 19:03:22 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 30 Apr 2018 12:03:22 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code 
In-Reply-To: <6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
 <314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
 <6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
Message-ID: <76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>

Jerry, Misha,

thank you for your review. 

adding build-dev alias as the patch includes makefiles changes.

-- Igor

> On Apr 30, 2018, at 8:39 AM, mikhailo <mikhailo.seledtsov at oracle.com> wrote:
> 
> Changes look good to me,
> 
> Thank you,
> 
> Misha
> 
> 
> On 04/28/2018 07:34 AM, Gerald Thornbrugh wrote:
>> Hi Igor,
>> 
>> Your changes look good to me.
>> 
>> Thanks!
>> 
>> Jerry
>> 
>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>>> Hi all,
>>> 
>>> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>>> 
>>> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>>> 
>>> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>> testing:
>>>   - all tests which depend on this code
>>>   - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>>> 
>>> [*] JBS:(labels = test-opensource and component = hotspot)
>>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot 
>>> 
>>> Thanks,
>>> -- Igor
>> 
> 



From erik.joelsson at oracle.com  Mon Apr 30 19:22:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 12:22:28 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
 <314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
 <6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
 <76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>
Message-ID: <8fc744b0-a594-4dcf-53df-bc1b5800908b@oracle.com>

Build changes look good.

/Erik


On 2018-04-30 12:03, Igor Ignatyev wrote:
> Jerry, Misha,
>
> thank you for your review.
>
> adding build-dev alias as the patch includes makefiles changes.
>
> -- Igor
>
>> On Apr 30, 2018, at 8:39 AM, mikhailo <mikhailo.seledtsov at oracle.com> wrote:
>>
>> Changes look good to me,
>>
>> Thank you,
>>
>> Misha
>>
>>
>> On 04/28/2018 07:34 AM, Gerald Thornbrugh wrote:
>>> Hi Igor,
>>>
>>> Your changes look good to me.
>>>
>>> Thanks!
>>>
>>> Jerry
>>>
>>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>>>> Hi all,
>>>>
>>>> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>>>>
>>>> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>>>>
>>>> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>> testing:
>>>>    - all tests which depend on this code
>>>>    - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>>>>
>>>> [*] JBS:(labels = test-opensource and component = hotspot)
>>>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>>>>
>>>> Thanks,
>>>> -- Igor



From erik.joelsson at oracle.com  Mon Apr 30 20:19:50 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 13:19:50 -0700
Subject: RFR: JDK-8196113: Remove the Compact Profile builds
Message-ID: <e7a743a0-6abf-c10c-8908-8b58f6c58c79@oracle.com>

Compact profiles were added in JDK 8, and superceded by modules in JDK 
9. The build logic for compact profiles was left in place in 9, but as 
we head into 11 it is time to remove this. This patch removes all the 
build logic related to that.

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

Webrev: http://cr.openjdk.java.net/~erikj/8196113/webrev.01/index.html

/Erik



From tim.bell at oracle.com  Mon Apr 30 21:14:26 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 30 Apr 2018 14:14:26 -0700
Subject: RFR: JDK-8196113: Remove the Compact Profile builds
In-Reply-To: <e7a743a0-6abf-c10c-8908-8b58f6c58c79@oracle.com>
References: <e7a743a0-6abf-c10c-8908-8b58f6c58c79@oracle.com>
Message-ID: <5AE78732.5090706@oracle.com>

Erik:

> Compact profiles were added in JDK 8, and superceded by modules in JDK
> 9. The build logic for compact profiles was left in place in 9, but as
> we head into 11 it is time to remove this. This patch removes all the
> build logic related to that.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196113
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196113/webrev.01/index.html

Looks good.

Tim