From david.holmes at oracle.com Wed Feb 1 01:24:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 11:24:28 +1000 Subject: JDK 10 build broken by "8028546: Add -source 10 and -target 10 to javac" Message-ID: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> Joe, I just sync'd my jdk10 forest before pushing the version 10 update and related hotspot changes and now all builds are failing due to: warning: [options] bootstrap class path not set in conjunction with -source 1.9 error: warnings found and -Werror specified Which would appear to be due to having added the -source 10 and -target 10 support - probably in conjunction with the version update to 10. Is there a simple fix to the makefiles? Thanks, David From joe.darcy at oracle.com Wed Feb 1 01:32:51 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 31 Jan 2017 17:32:51 -0800 Subject: JDK 10 build broken by "8028546: Add -source 10 and -target 10 to javac" In-Reply-To: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> References: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> Message-ID: <5ff64412-3a2e-9bfb-9db7-205ec108d7b7@oracle.com> Hi David, I can apply my fix for JDK-8173383: Update JDK build to use -source and -target 10. For me, I see the normal builds as succeeding, but some fast debug failures, perhaps for unrelated reasons. At least on a local build, with 8028546 a local build worked and all langtools tests passed. I'll get 8173383 pushed shortly. Thanks, -Joe On 1/31/2017 5:24 PM, David Holmes wrote: > Joe, > > I just sync'd my jdk10 forest before pushing the version 10 update and > related hotspot changes and now all builds are failing due to: > > warning: [options] bootstrap class path not set in conjunction with > -source 1.9 > error: warnings found and -Werror specified > > Which would appear to be due to having added the -source 10 and > -target 10 support - probably in conjunction with the version update > to 10. > > Is there a simple fix to the makefiles? > > Thanks, > David From david.holmes at oracle.com Wed Feb 1 01:41:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 11:41:21 +1000 Subject: JDK 10 build broken by "8028546: Add -source 10 and -target 10 to javac" In-Reply-To: <5ff64412-3a2e-9bfb-9db7-205ec108d7b7@oracle.com> References: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> <5ff64412-3a2e-9bfb-9db7-205ec108d7b7@oracle.com> Message-ID: Hi Joe, On 1/02/2017 11:32 AM, joe darcy wrote: > Hi David, > > I can apply my fix for JDK-8173383: Update JDK build to use -source and > -target 10. That's exactly what I just discovered will fix things. :) It is reviewed isn't it? So I can just apply the change to my forest and commit it under your id etc and push everything together. Thanks, David > For me, I see the normal builds as succeeding, but some fast debug > failures, perhaps for unrelated reasons. > > At least on a local build, with 8028546 a local build worked and all > langtools tests passed. > > I'll get 8173383 pushed shortly. > > Thanks, > > -Joe > > > On 1/31/2017 5:24 PM, David Holmes wrote: >> Joe, >> >> I just sync'd my jdk10 forest before pushing the version 10 update and >> related hotspot changes and now all builds are failing due to: >> >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.9 >> error: warnings found and -Werror specified >> >> Which would appear to be due to having added the -source 10 and >> -target 10 support - probably in conjunction with the version update >> to 10. >> >> Is there a simple fix to the makefiles? >> >> Thanks, >> David > From joe.darcy at oracle.com Wed Feb 1 01:44:19 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 31 Jan 2017 17:44:19 -0800 Subject: JDK 10 build broken by "8028546: Add -source 10 and -target 10 to javac" In-Reply-To: References: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> <5ff64412-3a2e-9bfb-9db7-205ec108d7b7@oracle.com> Message-ID: <58913D73.5010900@oracle.com> Hi David, Just pushed the change; if you refresh your forest it will be there. Thanks, -Joe On 1/31/2017 5:41 PM, David Holmes wrote: > Hi Joe, > > On 1/02/2017 11:32 AM, joe darcy wrote: >> Hi David, >> >> I can apply my fix for JDK-8173383: Update JDK build to use -source and >> -target 10. > > That's exactly what I just discovered will fix things. :) It is > reviewed isn't it? So I can just apply the change to my forest and > commit it under your id etc and push everything together. > > Thanks, > David > >> For me, I see the normal builds as succeeding, but some fast debug >> failures, perhaps for unrelated reasons. >> >> At least on a local build, with 8028546 a local build worked and all >> langtools tests passed. >> >> I'll get 8173383 pushed shortly. >> >> Thanks, >> >> -Joe >> >> >> On 1/31/2017 5:24 PM, David Holmes wrote: >>> Joe, >>> >>> I just sync'd my jdk10 forest before pushing the version 10 update and >>> related hotspot changes and now all builds are failing due to: >>> >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.9 >>> error: warnings found and -Werror specified >>> >>> Which would appear to be due to having added the -source 10 and >>> -target 10 support - probably in conjunction with the version update >>> to 10. >>> >>> Is there a simple fix to the makefiles? >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Wed Feb 1 02:08:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 12:08:18 +1000 Subject: JDK 10 build broken by "8028546: Add -source 10 and -target 10 to javac" In-Reply-To: <58913D73.5010900@oracle.com> References: <66ae7fd9-151d-8ee7-e29c-cc7c71b4f305@oracle.com> <5ff64412-3a2e-9bfb-9db7-205ec108d7b7@oracle.com> <58913D73.5010900@oracle.com> Message-ID: <5857fc75-9430-fd68-f455-b64e43f235de@oracle.com> On 1/02/2017 11:44 AM, Joseph D. Darcy wrote: > Hi David, > > Just pushed the change; if you refresh your forest it will be there. Thanks Joe. Submitting my changes to JPRT now. Hopefully no surprises. David > Thanks, > > -Joe > > On 1/31/2017 5:41 PM, David Holmes wrote: >> Hi Joe, >> >> On 1/02/2017 11:32 AM, joe darcy wrote: >>> Hi David, >>> >>> I can apply my fix for JDK-8173383: Update JDK build to use -source and >>> -target 10. >> >> That's exactly what I just discovered will fix things. :) It is >> reviewed isn't it? So I can just apply the change to my forest and >> commit it under your id etc and push everything together. >> >> Thanks, >> David >> >>> For me, I see the normal builds as succeeding, but some fast debug >>> failures, perhaps for unrelated reasons. >>> >>> At least on a local build, with 8028546 a local build worked and all >>> langtools tests passed. >>> >>> I'll get 8173383 pushed shortly. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 1/31/2017 5:24 PM, David Holmes wrote: >>>> Joe, >>>> >>>> I just sync'd my jdk10 forest before pushing the version 10 update and >>>> related hotspot changes and now all builds are failing due to: >>>> >>>> warning: [options] bootstrap class path not set in conjunction with >>>> -source 1.9 >>>> error: warnings found and -Werror specified >>>> >>>> Which would appear to be due to having added the -source 10 and >>>> -target 10 support - probably in conjunction with the version update >>>> to 10. >>>> >>>> Is there a simple fix to the makefiles? >>>> >>>> Thanks, >>>> David >>> > From david.holmes at oracle.com Wed Feb 1 04:50:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Feb 2017 14:50:10 +1000 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> Message-ID: <002044e5-69eb-bbe3-ef5f-198aa370b75d@oracle.com> jdk10/jdk10 is finally "JDK 10" :) David On 27/01/2017 10:26 AM, David Holmes wrote: > Hi Erik, > > As now discovered the version can't be updated until quite a few changes > are made in hotspot due to deprecated/obsolete option handling. > > https://bugs.openjdk.java.net/browse/JDK-8173421 > > I would suggest that this bug be taken over by hotspot team (maybe me :) > ) and that everything is pushed to jdk10/dev instead of jdk10/hs so that > we can get this off the ground. > > Thanks, > David > > On 26/01/2017 11:56 PM, Erik Joelsson wrote: >> The default major version for the jdk 10 repos needs to be updated from >> 9 to 10. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 >> >> Patch: >> >> diff -r 07f6f1f4140e common/autoconf/version-numbers >> --- a/common/autoconf/version-numbers >> +++ b/common/autoconf/version-numbers >> @@ -25,7 +25,7 @@ >> >> # Default version numbers to use unless overridden by configure >> >> -DEFAULT_VERSION_MAJOR=9 >> +DEFAULT_VERSION_MAJOR=10 >> DEFAULT_VERSION_MINOR=0 >> DEFAULT_VERSION_SECURITY=0 >> DEFAULT_VERSION_PATCH=0 >> >> >> /Erik >> From mandy.chung at oracle.com Wed Feb 1 05:11:23 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Jan 2017 21:11:23 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: > On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch for: > > 8173607: JMX RMI connector should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8173607 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 > This mostly looks good. I?d like to see an updated webrev after you sync with JDK-8173608. I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted. Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports. java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed. java.management.rmi module-info.java 32 * @see javax.management.remote.rmi This @see is not needed. This package is listed in the exported packages table. JMXConnectorFactory.java I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good. Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here. > > Some further cleanup of java.base and java.rmi module-info.java > should become possible once JDK-8173608 is in (as well as moving > RMIExporter to java.management.rmi - which is not possible yet). > Yes. > Further cleanup of @modules in tests might become possible as > well. > Hope there will be a bulk @modules cleanup some time. Thanks Mandy From joe.darcy at oracle.com Wed Feb 1 06:52:16 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 31 Jan 2017 22:52:16 -0800 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: <002044e5-69eb-bbe3-ef5f-198aa370b75d@oracle.com> References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> <002044e5-69eb-bbe3-ef5f-198aa370b75d@oracle.com> Message-ID: <2133b78f-2c3e-cb71-5c65-3b1099848c6c@oracle.com> Thanks David! -Joe On 1/31/2017 8:50 PM, David Holmes wrote: > jdk10/jdk10 is finally "JDK 10" :) > > David > > On 27/01/2017 10:26 AM, David Holmes wrote: >> Hi Erik, >> >> As now discovered the version can't be updated until quite a few changes >> are made in hotspot due to deprecated/obsolete option handling. >> >> https://bugs.openjdk.java.net/browse/JDK-8173421 >> >> I would suggest that this bug be taken over by hotspot team (maybe me :) >> ) and that everything is pushed to jdk10/dev instead of jdk10/hs so that >> we can get this off the ground. >> >> Thanks, >> David >> >> On 26/01/2017 11:56 PM, Erik Joelsson wrote: >>> The default major version for the jdk 10 repos needs to be updated from >>> 9 to 10. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 >>> >>> Patch: >>> >>> diff -r 07f6f1f4140e common/autoconf/version-numbers >>> --- a/common/autoconf/version-numbers >>> +++ b/common/autoconf/version-numbers >>> @@ -25,7 +25,7 @@ >>> >>> # Default version numbers to use unless overridden by configure >>> >>> -DEFAULT_VERSION_MAJOR=9 >>> +DEFAULT_VERSION_MAJOR=10 >>> DEFAULT_VERSION_MINOR=0 >>> DEFAULT_VERSION_SECURITY=0 >>> DEFAULT_VERSION_PATCH=0 >>> >>> >>> /Erik >>> From Alan.Bateman at oracle.com Wed Feb 1 09:40:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 1 Feb 2017 09:40:39 +0000 Subject: Review Request: JDK-8173608: Separate JDK management agent from java.management module In-Reply-To: <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> References: <1B41EF04-9D05-4B96-BB00-B6B14F0F69C0@oracle.com> <508D6511-7443-4F5D-93D2-79D535C3838C@oracle.com> Message-ID: On 30/01/2017 23:48, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173608/webrev.00/index.html > Just catching up this. It looks like the native methods for jdk.internal.agent.FileSystemImpl have been moved to libmanagemtn_rmi.so, shouldn't this be libmanagement_agent.so? -Alan From erik.joelsson at oracle.com Wed Feb 1 11:56:59 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Feb 2017 12:56:59 +0100 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: <32acdd4e-0ec3-d76d-fd17-cb2514570f5d@oracle.com> Build changes look ok. /Erik On 2017-01-31 19:26, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > > 8173607: JMX RMI connector should be in its own module > https://bugs.openjdk.java.net/browse/JDK-8173607 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 > > This patch makes it possible to remove the requires transitive > java.rmi from the java.management module. > > For convenience here is the HTML module-level API documentation > produced by javadoc for the new java.management.rmi module: > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html > > > The patch has some temporary hacks (mainly ConnectorBootstrap.java) > that we will be able to revert when > JDK-8173608 Separate JDK management agent from java.management module > is pushed. > > The changes were mainly mechanical except for: > > ConnectorBootstrap.java: see above > JMXConnectorFactory.java/JMXConnectorServerFactory.java: > ServiceLoader is now used to load the default RMI Connector provider > as a service. There should however be no observable behavior change > to existing application. > ProxyRef.java, Unmarshal.java: are moved to a new > com.sun.jmx.remote.internal.rmi package in the new module. > ClientNotifForwarder.java: is modified to no longer depend on > java.rmi.UnmarshalException - NotSerializableException is used > instead > RMIConnector.java: fetchNotif is updated to throw > NotSerializableException instead of UnmarshalException > The PRef serialization bytes are updated to accomodate the > new ProxyRef package name. > > Some further cleanup of java.base and java.rmi module-info.java > should become possible once JDK-8173608 is in (as well as moving > RMIExporter to java.management.rmi - which is not possible yet). > > Further cleanup of @modules in tests might become possible as > well. > > Note: > JCK tests for api/javax_management and api/java_lang/management > are passing with this change. > > best regards, > > -- daniel > From erik.joelsson at oracle.com Wed Feb 1 11:58:49 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Feb 2017 12:58:49 +0100 Subject: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10 In-Reply-To: <002044e5-69eb-bbe3-ef5f-198aa370b75d@oracle.com> References: <42b8ad79-ce30-9132-9740-e7fdd68a8d83@oracle.com> <002044e5-69eb-bbe3-ef5f-198aa370b75d@oracle.com> Message-ID: <382aa9d3-fb18-326a-02a9-a32325a35388@oracle.com> Woho, thanks! /Erik On 2017-02-01 05:50, David Holmes wrote: > jdk10/jdk10 is finally "JDK 10" :) > > David > > On 27/01/2017 10:26 AM, David Holmes wrote: >> Hi Erik, >> >> As now discovered the version can't be updated until quite a few changes >> are made in hotspot due to deprecated/obsolete option handling. >> >> https://bugs.openjdk.java.net/browse/JDK-8173421 >> >> I would suggest that this bug be taken over by hotspot team (maybe me :) >> ) and that everything is pushed to jdk10/dev instead of jdk10/hs so that >> we can get this off the ground. >> >> Thanks, >> David >> >> On 26/01/2017 11:56 PM, Erik Joelsson wrote: >>> The default major version for the jdk 10 repos needs to be updated from >>> 9 to 10. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 >>> >>> Patch: >>> >>> diff -r 07f6f1f4140e common/autoconf/version-numbers >>> --- a/common/autoconf/version-numbers >>> +++ b/common/autoconf/version-numbers >>> @@ -25,7 +25,7 @@ >>> >>> # Default version numbers to use unless overridden by configure >>> >>> -DEFAULT_VERSION_MAJOR=9 >>> +DEFAULT_VERSION_MAJOR=10 >>> DEFAULT_VERSION_MINOR=0 >>> DEFAULT_VERSION_SECURITY=0 >>> DEFAULT_VERSION_PATCH=0 >>> >>> >>> /Erik >>> From chris.hegarty at oracle.com Wed Feb 1 12:00:03 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 1 Feb 2017 12:00:03 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> Message-ID: <288A5D00-E05E-4461-9E37-835368C5DA6E@oracle.com> Can someone from the build group please give the build part of this the once over. Thanks, -Chris. > On 31 Jan 2017, at 19:14, Zeller, Arno wrote: > > Hi Chris, > > thanks for all the improvements. I imported your webrev and prepared another webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ > > I have seen the multiple DIRECTs myself during testing and I think filtering on the java side is a very elegant solution. > Thanks for this! > > Best regards, > Arno > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 31. Januar 2017 12:47 >> To: Zeller, Arno >> Cc: net-dev at openjdk.java.net >> Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >> on Windows, MacOS and Gnome >> >> Arno, >> >> Thanks for doing this, and your patience so far. One more final round of >> comments from me. Mostly minor. I?ve put them in the form of a webrev so >> you can easily view and import them, if you agree. >> >> http://cr.openjdk.java.net/~chegar/8170868_additional/ >> >> 1) A few comment rewordings and formatting suggestions. >> >> 2) I see duplicate DIRECT, and a few specific proxies, in my >> testing. Maybe my environment or PAC file is returning >> duplicate entries. I suggest that, at the java-level, we filter >> out duplicates while preserving ordering. ( see above webrev ) >> >> 3) We do not use asserts in core libraries. So I replaced the usage >> with an early return NULL ( no proxy ). At a later stage we could >> throw an exception or something, but probably not all that >> interesting. >> >> I have run this change ( along with my additional suggestions ) through our >> internal build and test system. No surprises. >> >> -Chris. >> >>> On 31 Jan 2017, at 09:14, Zeller, Arno wrote: >>> >>> Hi Chris, >>> >>> thanks a lot - I did not see this case in my tests. I added your change to my >> new webrev: >>> http://cr.openjdk.java.net/~clanger/webrevs/8170868.5/ >>> >>> >>> Best regards, >>> Arno >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Montag, 30. Januar 2017 17:14 >>>> To: Zeller, Arno >>>> Cc: net-dev at openjdk.java.net >>>> Subject: Re: RFR:8170868: DefaultProxySelector should use system >>>> defaults on Windows, MacOS and Gnome >>>> >>>> Arno, >>>> >>>> I found an issue on Windows when proxies are specified per-protocol, i.e. >>>> they are returned with their optional scheme set. I believe that the >>>> scheme should be checked, at least without this change FTP proxies >>>> were being returned for HTTP URL's, on my machine. >>>> >>>> $ hg -R jdk diff >>>> diff -r 07e07fecf383 >>>> src/java.base/windows/native/libnet/DefaultProxySelector.c >>>> --- a/src/java.base/windows/native/libnet/DefaultProxySelector.c >>>> Mon Jan 30 14:09:14 2017 +0000 >>>> +++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c >>>> Mon Jan 30 16:09:23 2017 +0000 >>>> @@ -99,6 +99,7 @@ >>>> * Returns the size of the array as int. >>>> */ >>>> static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, >>>> list_item **head) { >>>> + static const wchar_t separators[] = L"\t\r\n ;"; >>>> list_item *current = NULL; >>>> int nr_elems = 0; >>>> wchar_t *context = NULL; >>>> @@ -109,13 +110,26 @@ >>>> * The proxy server list contains one or more of the following >>>> strings separated by semicolons or whitespace. >>>> * ([=]["://"][":"]) >>>> */ >>>> - current_proxy = wcstok_s(win_proxy, L"; ", &context); >>>> - while (current_proxy != NULL) { >>>> + current_proxy = wcstok_s(win_proxy, separators, &context); >>>> + while (current_proxy != NULL) { >>>> LPWSTR pport; >>>> LPWSTR phost; >>>> int portVal = 0; >>>> wchar_t *next_proxy = NULL; >>>> list_item *proxy = NULL; >>>> + wchar_t* pos = NULL; >>>> + >>>> + /* Filter based on the scheme, if there is one */ >>>> + pos = wcschr(current_proxy, L'='); >>>> + if (pos) { >>>> + *pos = L'\0'; >>>> + if (wcscmp(current_proxy, pproto) != 0) { >>>> + current_proxy = wcstok_s(NULL, separators, &context); >>>> + continue; >>>> + } >>>> + current_proxy = pos + 1; >>>> + } >>>> >>>> /* Let's check for a scheme and ignore it. */ >>>> if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ >>>> -152,7 +166,7 @@ >>>> } >>>> } >>>> /* goto next proxy if available... */ >>>> - current_proxy = wcstok_s(NULL, L"; ", &context); >>>> + current_proxy = wcstok_s(NULL, separators, &context); >>>> } >>>> return nr_elems; >>>> } >>>> @@ -268,7 +282,6 @@ >>>> if (win_proxy != NULL) { >>>> wchar_t *context = NULL; >>>> int defport = 0; >>>> - WCHAR pproto[MAX_STR_LEN]; >>>> int nr_elems = 0; >>>> >>>> /** >>>> @@ -290,10 +303,7 @@ >>>> goto noproxy; >>>> } >>>> >>>> - /* Prepare protocol string to compare with. */ >>>> - _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); >>>> - >>>> - nr_elems = createProxyList(win_proxy, pproto, &head); >>>> + nr_elems = createProxyList(win_proxy, lpProto, &head); >>>> if (nr_elems != 0 && head != NULL) { >>>> int index = 0; >>>> proxy_array = (*env)->NewObjectArray(env, nr_elems, >>>> proxy_class, NULL); >>>> >>>> -Chris. >>>> >>>> P.S. I will take a look at the latest webrev. >>>> > From erik.joelsson at oracle.com Wed Feb 1 12:35:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Feb 2017 13:35:13 +0100 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <288A5D00-E05E-4461-9E37-835368C5DA6E@oracle.com> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> <288A5D00-E05E-4461-9E37-835368C5DA6E@oracle.com> Message-ID: Hello, In NetworkingLibraries.gmk, the explicit exclusion of $(JDK_TOPDIR)/src/java.base/unix/native/libnet/DefaultProxySelector.c shouldn't be necessary. SetupNativeCompilation should pick the first found source file of the same name (or rather, that would end up as the same object) and the macro FindSrcDirsForLib should guarantee that the most specific file is found first. If this doesn't work as intended it's a bug, but please try it. (If this doesn't work and you need to keep the exclusion, please fix indentation to 2 spaces for logical indent). Other than that it looks ok. /Erik On 2017-02-01 13:00, Chris Hegarty wrote: > Can someone from the build group please give the build part of > this the once over. > > Thanks, > -Chris. > >> On 31 Jan 2017, at 19:14, Zeller, Arno wrote: >> >> Hi Chris, >> >> thanks for all the improvements. I imported your webrev and prepared another webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ >> >> I have seen the multiple DIRECTs myself during testing and I think filtering on the java side is a very elegant solution. >> Thanks for this! >> >> Best regards, >> Arno >> >>> -----Original Message----- >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>> Sent: Dienstag, 31. Januar 2017 12:47 >>> To: Zeller, Arno >>> Cc: net-dev at openjdk.java.net >>> Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >>> on Windows, MacOS and Gnome >>> >>> Arno, >>> >>> Thanks for doing this, and your patience so far. One more final round of >>> comments from me. Mostly minor. I?ve put them in the form of a webrev so >>> you can easily view and import them, if you agree. >>> >>> http://cr.openjdk.java.net/~chegar/8170868_additional/ >>> >>> 1) A few comment rewordings and formatting suggestions. >>> >>> 2) I see duplicate DIRECT, and a few specific proxies, in my >>> testing. Maybe my environment or PAC file is returning >>> duplicate entries. I suggest that, at the java-level, we filter >>> out duplicates while preserving ordering. ( see above webrev ) >>> >>> 3) We do not use asserts in core libraries. So I replaced the usage >>> with an early return NULL ( no proxy ). At a later stage we could >>> throw an exception or something, but probably not all that >>> interesting. >>> >>> I have run this change ( along with my additional suggestions ) through our >>> internal build and test system. No surprises. >>> >>> -Chris. >>> >>>> On 31 Jan 2017, at 09:14, Zeller, Arno wrote: >>>> >>>> Hi Chris, >>>> >>>> thanks a lot - I did not see this case in my tests. I added your change to my >>> new webrev: >>>> http://cr.openjdk.java.net/~clanger/webrevs/8170868.5/ >>>> >>>> >>>> Best regards, >>>> Arno >>>> >>>>> -----Original Message----- >>>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>>> Sent: Montag, 30. Januar 2017 17:14 >>>>> To: Zeller, Arno >>>>> Cc: net-dev at openjdk.java.net >>>>> Subject: Re: RFR:8170868: DefaultProxySelector should use system >>>>> defaults on Windows, MacOS and Gnome >>>>> >>>>> Arno, >>>>> >>>>> I found an issue on Windows when proxies are specified per-protocol, i.e. >>>>> they are returned with their optional scheme set. I believe that the >>>>> scheme should be checked, at least without this change FTP proxies >>>>> were being returned for HTTP URL's, on my machine. >>>>> >>>>> $ hg -R jdk diff >>>>> diff -r 07e07fecf383 >>>>> src/java.base/windows/native/libnet/DefaultProxySelector.c >>>>> --- a/src/java.base/windows/native/libnet/DefaultProxySelector.c >>>>> Mon Jan 30 14:09:14 2017 +0000 >>>>> +++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c >>>>> Mon Jan 30 16:09:23 2017 +0000 >>>>> @@ -99,6 +99,7 @@ >>>>> * Returns the size of the array as int. >>>>> */ >>>>> static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, >>>>> list_item **head) { >>>>> + static const wchar_t separators[] = L"\t\r\n ;"; >>>>> list_item *current = NULL; >>>>> int nr_elems = 0; >>>>> wchar_t *context = NULL; >>>>> @@ -109,13 +110,26 @@ >>>>> * The proxy server list contains one or more of the following >>>>> strings separated by semicolons or whitespace. >>>>> * ([=]["://"][":"]) >>>>> */ >>>>> - current_proxy = wcstok_s(win_proxy, L"; ", &context); >>>>> - while (current_proxy != NULL) { >>>>> + current_proxy = wcstok_s(win_proxy, separators, &context); >>>>> + while (current_proxy != NULL) { >>>>> LPWSTR pport; >>>>> LPWSTR phost; >>>>> int portVal = 0; >>>>> wchar_t *next_proxy = NULL; >>>>> list_item *proxy = NULL; >>>>> + wchar_t* pos = NULL; >>>>> + >>>>> + /* Filter based on the scheme, if there is one */ >>>>> + pos = wcschr(current_proxy, L'='); >>>>> + if (pos) { >>>>> + *pos = L'\0'; >>>>> + if (wcscmp(current_proxy, pproto) != 0) { >>>>> + current_proxy = wcstok_s(NULL, separators, &context); >>>>> + continue; >>>>> + } >>>>> + current_proxy = pos + 1; >>>>> + } >>>>> >>>>> /* Let's check for a scheme and ignore it. */ >>>>> if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ >>>>> -152,7 +166,7 @@ >>>>> } >>>>> } >>>>> /* goto next proxy if available... */ >>>>> - current_proxy = wcstok_s(NULL, L"; ", &context); >>>>> + current_proxy = wcstok_s(NULL, separators, &context); >>>>> } >>>>> return nr_elems; >>>>> } >>>>> @@ -268,7 +282,6 @@ >>>>> if (win_proxy != NULL) { >>>>> wchar_t *context = NULL; >>>>> int defport = 0; >>>>> - WCHAR pproto[MAX_STR_LEN]; >>>>> int nr_elems = 0; >>>>> >>>>> /** >>>>> @@ -290,10 +303,7 @@ >>>>> goto noproxy; >>>>> } >>>>> >>>>> - /* Prepare protocol string to compare with. */ >>>>> - _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); >>>>> - >>>>> - nr_elems = createProxyList(win_proxy, pproto, &head); >>>>> + nr_elems = createProxyList(win_proxy, lpProto, &head); >>>>> if (nr_elems != 0 && head != NULL) { >>>>> int index = 0; >>>>> proxy_array = (*env)->NewObjectArray(env, nr_elems, >>>>> proxy_class, NULL); >>>>> >>>>> -Chris. >>>>> >>>>> P.S. I will take a look at the latest webrev. >>>>> From chris.hegarty at oracle.com Wed Feb 1 13:27:10 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 1 Feb 2017 13:27:10 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> <288A5D00-E05E-4461-9E37-835368C5DA6E@oracle.com> Message-ID: <57BC1131-97CC-4AD1-9189-2D803B77C2B0@oracle.com> > On 1 Feb 2017, at 12:35, Erik Joelsson wrote: > > Hello, > > In NetworkingLibraries.gmk, the explicit exclusion of $(JDK_TOPDIR)/src/java.base/unix/native/libnet/DefaultProxySelector.c shouldn't be necessary. SetupNativeCompilation should pick the first found source file of the same name (or rather, that would end up as the same object) and the macro FindSrcDirsForLib should guarantee that the most specific file is found first. I can confirm that this works fine. Thanks Erik. -Chis. > /Erik > > > On 2017-02-01 13:00, Chris Hegarty wrote: >> Can someone from the build group please give the build part of >> this the once over. >> >> Thanks, >> -Chris. >> >>> On 31 Jan 2017, at 19:14, Zeller, Arno wrote: >>> >>> Hi Chris, >>> >>> thanks for all the improvements. I imported your webrev and prepared another webrev: >>> http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ >>> >>> I have seen the multiple DIRECTs myself during testing and I think filtering on the java side is a very elegant solution. >>> Thanks for this! From daniel.fuchs at oracle.com Wed Feb 1 15:29:22 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 1 Feb 2017 15:29:22 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> Message-ID: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> Hi Mandy, On 01/02/17 05:11, Mandy Chung wrote: > >> On Jan 31, 2017, at 10:26 AM, Daniel Fuchs wrote: >> >> Hi, >> >> Please find below a patch for: >> >> 8173607: JMX RMI connector should be in its own module >> https://bugs.openjdk.java.net/browse/JDK-8173607 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 >> > > This mostly looks good. I?d like to see an updated webrev after you sync with JDK-8173608. I believe you can revert test/sun/management/jdp and test/sun/management/jmxremote tests change and ConnectorBootstrap.java as you noted. Also you can run jdeps ?-check on java.rmi, java.management, and jdk.management.agent to update its requires and qualified exports. java.management should no longer require java.rmi and the qualified exports from java.rmi is not needed. Here is the updated webrev, rebased after pulling JDK-8173608, and with your feedback below integrated. I am pleased to report that java.management no longer requires java.rmi or java.naming :-) Compared to previous version, then RMIExporter has been moved to java.management.rmi, various module-info.java have been cleaned up, some @modules in tests have been updated (mostly due to the RMIExporter move). I have also improved some javadoc comments in JMXConnectorFactory.java No changes in build files compared to webrev.05 http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html best regards, -- daniel > > java.management.rmi module-info.java > 32 * @see javax.management.remote.rmi > > This @see is not needed. This package is listed in the exported packages table. > > JMXConnectorFactory.java > I like the ProviderFinder approach to look up the custom providers and platform providers; and shared code used by both JMXConnectorFactory and JMXConnectorServerFactory which is good. > > Nit: line 481-491 - this is javadoc and probably /* .. */ comment block is more appropriate here. > >> >> Some further cleanup of java.base and java.rmi module-info.java >> should become possible once JDK-8173608 is in (as well as moving >> RMIExporter to java.management.rmi - which is not possible yet). >> > > Yes. > >> Further cleanup of @modules in tests might become possible as >> well. >> > > Hope there will be a bulk @modules cleanup some time. > > Thanks > Mandy > From james.laskey at oracle.com Wed Feb 1 19:00:11 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 1 Feb 2017 15:00:11 -0400 Subject: JDK 8 cannot be built on Sierra, correct? Message-ID: <88336F1C-13E6-4F73-8C59-C7A885B0C363@oracle.com> I haven?t tried in a while, but I ran up against it today. Neither the xcode-select (xcode4) or configure --with-xcode-path work. dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation Referenced from: /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/xcodebuild Reason: no suitable image found. Did find: /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported From mandy.chung at oracle.com Thu Feb 2 02:41:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Feb 2017 18:41:42 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> Message-ID: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> > On Feb 1, 2017, at 7:29 AM, Daniel Fuchs wrote: > > Here is the updated webrev, rebased after pulling JDK-8173608, and with > your feedback below integrated. > > I am pleased to report that java.management no longer requires > java.rmi or java.naming :-) > This is great! > Compared to previous version, then RMIExporter has been moved > to java.management.rmi, various module-info.java have been > cleaned up, some @modules in tests have been updated (mostly > due to the RMIExporter move). > > I have also improved some javadoc comments in JMXConnectorFactory.java > No changes in build files compared to webrev.05 > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 Does java.management still depend on java.base/jdk.internal.module? > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html > Maybe the first sentence of @provides could be simplified to: A provider of JMXConnectorProvider for the RMI protocol. A provider of JMXConnectorServerProvider for the RMI protocol. Otherwise looks good. Mandy From erik.joelsson at oracle.com Thu Feb 2 08:00:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Feb 2017 09:00:52 +0100 Subject: JDK 8 cannot be built on Sierra, correct? In-Reply-To: <88336F1C-13E6-4F73-8C59-C7A885B0C363@oracle.com> References: <88336F1C-13E6-4F73-8C59-C7A885B0C363@oracle.com> Message-ID: <0695b0a7-b993-6800-7aec-d53d346d9a96@oracle.com> There was a discussion about this a few weeks back, but you are correct. David DeHaven suggests creating a VM to build in. http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018518.html /Erik On 2017-02-01 20:00, Jim Laskey (Oracle) wrote: > I haven?t tried in a while, but I ran up against it today. > > Neither the xcode-select (xcode4) or configure --with-xcode-path work. > > dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation > Referenced from: /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/xcodebuild > Reason: no suitable image found. Did find: > /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported > > From magnus.ihse.bursie at oracle.com Thu Feb 2 12:07:28 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 2 Feb 2017 13:07:28 +0100 Subject: RFR: JDK-8172548 unpack200 fails linking with new update of SS12u4 Message-ID: When building with Solaris Studio 12u4, linking of unpack200 fails. The fix is to include "environ" in the mapfile. This patch is contributed by Douglas Simon. Bug: https://bugs.openjdk.java.net/browse/JDK-8172548 Patch inline: diff --git a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc --- a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc +++ b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc @@ -28,6 +28,7 @@ SUNWprivate_1.1 { global: # These are needed by the c runtime in SS12u4 + environ; _environ; __environ_lock; ___Argv; /Magnus From erik.joelsson at oracle.com Thu Feb 2 12:17:12 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Feb 2017 13:17:12 +0100 Subject: RFR: JDK-8172548 unpack200 fails linking with new update of SS12u4 In-Reply-To: References: Message-ID: Looks ok to me. /Erik On 2017-02-02 13:07, Magnus Ihse Bursie wrote: > When building with Solaris Studio 12u4, linking of unpack200 fails. > The fix is to include "environ" in the mapfile. > > This patch is contributed by Douglas Simon. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172548 > Patch inline: > diff --git > a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > --- a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > +++ b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > @@ -28,6 +28,7 @@ > SUNWprivate_1.1 { > global: > # These are needed by the c runtime in SS12u4 > + environ; > _environ; > __environ_lock; > ___Argv; > > > /Magnus From magnus.ihse.bursie at oracle.com Thu Feb 2 12:24:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 2 Feb 2017 13:24:45 +0100 Subject: RFR: JDK-8173822 Remove dead code in BuildNashorn.gmk Message-ID: <5f84e8d9-2be1-3e31-1d79-c41fd4d5db16@oracle.com> There are dead code inBuildNashorn.gmk that is related to the now defunct nashorn.jar. It should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8173822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8173822-remove-nashorn-jar-cleanup/webrev.01 /Magnus From james.laskey at oracle.com Thu Feb 2 12:35:53 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 2 Feb 2017 08:35:53 -0400 Subject: JDK 8 cannot be built on Sierra, correct? In-Reply-To: <0695b0a7-b993-6800-7aec-d53d346d9a96@oracle.com> References: <88336F1C-13E6-4F73-8C59-C7A885B0C363@oracle.com> <0695b0a7-b993-6800-7aec-d53d346d9a96@oracle.com> Message-ID: <39D0433A-28CB-40E7-83DC-D97DF9B01AB2@oracle.com> Actually, just realizing I can take that idea one step further. I can install !0.8 as a VM on VMWare. Thank you. ? Jim > On Feb 2, 2017, at 4:00 AM, Erik Joelsson wrote: > > There was a discussion about this a few weeks back, but you are correct. David DeHaven suggests creating a VM to build in. > > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018518.html > > /Erik > > On 2017-02-01 20:00, Jim Laskey (Oracle) wrote: >> I haven?t tried in a while, but I ran up against it today. >> >> Neither the xcode-select (xcode4) or configure --with-xcode-path work. >> >> dyld: Library not loaded: @rpath/DVTFoundation.framework/Versions/A/DVTFoundation >> Referenced from: /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/xcodebuild >> Reason: no suitable image found. Did find: >> /Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation: cannot load '/Volumes/Elephant/Users/jlaskey/Downloads/Xcode4.app/Contents/Developer/usr/bin/../../../SharedFrameworks/DVTFoundation.framework/Versions/A/DVTFoundation' because Objective-C garbage collection is not supported >> >> > From daniel.fuchs at oracle.com Thu Feb 2 12:37:55 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 12:37:55 +0000 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> Message-ID: Hi Mandy, On 02/02/17 02:41, Mandy Chung wrote: >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 > > Does java.management still depend on java.base/jdk.internal.module? Well spotted! It doesn't. I have updated module-info.java for java.base. http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07 >> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06/java.management.rmi-summary.html >> > > Maybe the first sentence of @provides could be simplified to: > > A provider of JMXConnectorProvider for the RMI protocol. > A provider of JMXConnectorServerProvider for the RMI protocol. Done. But I think you meant A provider of JMXConnector[Server] for the RMI protocol. http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07/java.management.rmi-summary.html best regards, -- daniel > > Otherwise looks good. > Mandy > > > From doug.simon at oracle.com Thu Feb 2 13:37:22 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 2 Feb 2017 14:37:22 +0100 Subject: RFR: JDK-8172548 unpack200 fails linking with new update of SS12u4 In-Reply-To: References: Message-ID: <94631BE5-34E4-4315-B8A4-373964836BD7@oracle.com> > On 2 Feb 2017, at 13:07, Magnus Ihse Bursie wrote: > > When building with Solaris Studio 12u4, linking of unpack200 fails. The fix is to include "environ" in the mapfile. > > This patch is contributed by Douglas Simon. For full disclosure, the original patch and discovery was by Stefan Anzinger. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172548 > Patch inline: > diff --git a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > --- a/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > +++ b/make/mapfiles/libunpack/mapfile-vers-unpack200-solaris-sparc > @@ -28,6 +28,7 @@ > SUNWprivate_1.1 { > global: > # These are needed by the c runtime in SS12u4 > + environ; > _environ; > __environ_lock; > ___Argv; > > > /Magnus From erik.joelsson at oracle.com Thu Feb 2 13:59:32 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Feb 2017 14:59:32 +0100 Subject: RFR: JDK-8173822 Remove dead code in BuildNashorn.gmk In-Reply-To: <5f84e8d9-2be1-3e31-1d79-c41fd4d5db16@oracle.com> References: <5f84e8d9-2be1-3e31-1d79-c41fd4d5db16@oracle.com> Message-ID: <3bc949dd-0a26-7b6d-2b49-d3ef6a0cb5ef@oracle.com> Looks ok. /Erik On 2017-02-02 13:24, Magnus Ihse Bursie wrote: > There are dead code inBuildNashorn.gmk that is related to the now > defunct nashorn.jar. It should be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8173822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8173822-remove-nashorn-jar-cleanup/webrev.01 > > /Magnus From mandy.chung at oracle.com Thu Feb 2 16:02:11 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 08:02:11 -0800 Subject: RFR: 8173607: JMX RMI connector should be in its own module In-Reply-To: References: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com> <5ad3fe2b-be04-24c7-98bb-8bab61c3aa15@oracle.com> <3788E0D3-FEDE-4C32-9C04-B54A619AFFE3@oracle.com> Message-ID: > On Feb 2, 2017, at 4:37 AM, Daniel Fuchs wrote: > > Hi Mandy, > > On 02/02/17 02:41, Mandy Chung wrote: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06 >> >> Does java.management still depend on java.base/jdk.internal.module? > > Well spotted! It doesn't. I have updated module-info.java for java.base. > > http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.07 Looks good. Mandy From matthias.baesken at sap.com Thu Feb 2 16:25:43 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 2 Feb 2017 16:25:43 +0000 Subject: RFR [XXS] : cleanup macosx jspawnhelper build settings Message-ID: <9d610dbb0787423fac838d44a266bcfd@DEWDFE13DE14.global.corp.sap> Hello, could I please have a review for the following small change that cleans up the special macosx BUILD_JSPAWNHELPER_DST_DIR setting that is not really needed any more after CR 8066474: "Remove the lib/ directory from Linux and Solaris images" changed the default setting . Bug : https://bugs.openjdk.java.net/browse/JDK-8173834 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8173834.0/ Thanks, Matthias From erik.joelsson at oracle.com Thu Feb 2 16:45:07 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 2 Feb 2017 17:45:07 +0100 Subject: RFR [XXS] : cleanup macosx jspawnhelper build settings In-Reply-To: <9d610dbb0787423fac838d44a266bcfd@DEWDFE13DE14.global.corp.sap> References: <9d610dbb0787423fac838d44a266bcfd@DEWDFE13DE14.global.corp.sap> Message-ID: <55dcf682-039d-450e-3dc0-bb7ba71bd3ea@oracle.com> Hello Matthias, While your change is ok and can certainly be pushed on its own, there is so much more needing cleanup here. If you don't mind, here is what I think needs doing: * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since these variables aren't conditionally changed anywhere, there is really no need for the indirection. * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the compiler for a 64 bit target to produce a 64 bit binary given the standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very old and confused code * The src dir only has the one src file, no need to explicitly list it for include. * The adding of childproc.o to LIBS can be accomplished using the parameter EXTRA_OBJECT_FILES. By using that you automatically get the dependency declaration so you can remove the line "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the single conditional into it's place. Thanks /Erik On 2017-02-02 17:25, Baesken, Matthias wrote: > Hello, > could I please have a review for the following small change that cleans up the special macosx BUILD_JSPAWNHELPER_DST_DIR setting that is not really > needed any more after CR 8066474: "Remove the lib/ directory from Linux and Solaris images" changed the default setting . > > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8173834 > > webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8173834.0/ > > > Thanks, Matthias From daniel.fuchs at oracle.com Thu Feb 2 17:14:44 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 17:14:44 +0000 Subject: Heads up: Fwd: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module In-Reply-To: <201702021653.v12GrvPL028871@aojmv0008.oracle.com> References: <201702021653.v12GrvPL028871@aojmv0008.oracle.com> Message-ID: <8e7a89d7-0db0-d610-2b70-2722ec8ddec0@oracle.com> Hi, A direct consequence of this change is that you may have to either blow up your ./build directory, or run 'make clean-java' after pulling this fix. Otherwise you may see strange build failures like below: Error occurred during initialization of VM java.lang.RuntimeException: Package com.sun.jmx.remote.protocol.rmi in both module java.management.rmi and module java.management at jdk.internal.module.ModuleBootstrap.fail(java.base/ModuleBootstrap.java:699) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:329) at java.lang.System.initPhase2(java.base/System.java:1928) best regards, -- daniel -------------- next part -------------- An embedded message was scrubbed... From: daniel.fuchs at oracle.com Subject: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module Date: Thu, 02 Feb 2017 16:53:57 +0000 Size: 11020 URL: From mandy.chung at oracle.com Thu Feb 2 22:27:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 14:27:52 -0800 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent Message-ID: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. Mandy From david.holmes at oracle.com Thu Feb 2 23:58:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Feb 2017 09:58:26 +1000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: Hi Mandy, Looks reasonable. No tests that need changing? Thanks, David On 3/02/2017 8:27 AM, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy > From mandy.chung at oracle.com Fri Feb 3 00:03:59 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 2 Feb 2017 16:03:59 -0800 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: <26A44B4D-56EB-4063-BEE3-09A607EB9032@oracle.com> > On Feb 2, 2017, at 3:58 PM, David Holmes wrote: > > Hi Mandy, > > Looks reasonable. > > No tests that need changing? > No since it?s just the shared library name change. The shared library provides the native method implementation for jdk.internal.agent.FileSystem (no change there) Mandy > Thanks, > David > > On 3/02/2017 8:27 AM, Mandy Chung wrote: >> libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ >> >> This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. >> >> Mandy >> From Alan.Bateman at oracle.com Fri Feb 3 07:41:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Feb 2017 07:41:59 +0000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: <2886b79d-e238-aac9-e2a1-56b9e726d3ad@oracle.com> On 02/02/2017 22:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > Looks good. -Alan From erik.joelsson at oracle.com Fri Feb 3 09:04:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 10:04:17 +0100 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: Looks good. /Erik On 2017-02-02 23:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy From daniel.fuchs at oracle.com Fri Feb 3 10:16:23 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 3 Feb 2017 10:16:23 +0000 Subject: Review Request: JDK-8173858: Rename libmanagement_rmi to libmanagement_agent In-Reply-To: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> References: <596C819E-614E-46AE-8AD3-340A50789CBA@oracle.com> Message-ID: +1 libmanagement_agent is indeed a better name :-) best regards, -- daniel On 02/02/17 22:27, Mandy Chung wrote: > libmanagement_agent should be the proper library name for jdk.management.agent. It was an oversight with the current name. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/ > > This patch also takes out the qualified exports of java.base/jdk.internal.vm to java.management which is not needed. > > Mandy > From matthias.baesken at sap.com Fri Feb 3 11:08:45 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 3 Feb 2017 11:08:45 +0000 Subject: RFR [XXS] : cleanup macosx jspawnhelper build settings In-Reply-To: <55dcf682-039d-450e-3dc0-bb7ba71bd3ea@oracle.com> References: <9d610dbb0787423fac838d44a266bcfd@DEWDFE13DE14.global.corp.sap> <55dcf682-039d-450e-3dc0-bb7ba71bd3ea@oracle.com> Message-ID: <2c2da6d72f1743d689608c8c67fe7a8c@DEWDFE13DE14.global.corp.sap> Hi Erik, thanks for your ideas and comments. > While your change is ok and can certainly be pushed on its own, there is > so much more needing cleanup here. I would like to do the other suggested cleanups in a separate change. Is this fine, can the original change be pushed ? Best regards, Matthias > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Donnerstag, 2. Februar 2017 17:45 > To: Baesken, Matthias ; build- > dev at openjdk.java.net > Cc: Simonis, Volker > Subject: Re: RFR [XXS] : cleanup macosx jspawnhelper build settings > > Hello Matthias, > > While your change is ok and can certainly be pushed on its own, there is > so much more needing cleanup here. If you don't mind, here is what I > think needs doing: > > * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, > BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since > these > variables aren't conditionally changed anywhere, there is really no need > for the indirection. > > * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += > $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the > compiler for a 64 bit target to produce a 64 bit binary given the > standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very > old and confused code > > * The src dir only has the one src file, no need to explicitly list it > for include. > > * The adding of childproc.o to LIBS can be accomplished using the > parameter EXTRA_OBJECT_FILES. By using that you automatically get the > dependency declaration so you can remove the line > "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" > > * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the > single conditional into it's place. > > Thanks > /Erik > > On 2017-02-02 17:25, Baesken, Matthias wrote: > > Hello, > > could I please have a review for the following small change that cleans > up the special macosx BUILD_JSPAWNHELPER_DST_DIR setting that is not > really > > needed any more after CR 8066474: "Remove the lib/ directory from > Linux and Solaris images" changed the default setting . > > > > > > Bug : > > > > https://bugs.openjdk.java.net/browse/JDK-8173834 > > > > webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8173834.0/ > > > > > > Thanks, Matthias From magnus.ihse.bursie at oracle.com Fri Feb 3 12:21:02 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 3 Feb 2017 13:21:02 +0100 Subject: RFR: JDK-8059000 hgforest: pass options to serve command Message-ID: Pass options to serve command in hgforest.sh. Mostly necessary for --port option. Original patch was written by Michael Duigou, but it has bit-rotted since created so I had to adapt it to the current hgforest.sh. Bug: https://bugs.openjdk.java.net/browse/JDK-8059000 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8059000-pass-options-to-hgforest-serve/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Feb 3 12:27:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 13:27:08 +0100 Subject: RFR [XXS] : cleanup macosx jspawnhelper build settings In-Reply-To: <2c2da6d72f1743d689608c8c67fe7a8c@DEWDFE13DE14.global.corp.sap> References: <9d610dbb0787423fac838d44a266bcfd@DEWDFE13DE14.global.corp.sap> <55dcf682-039d-450e-3dc0-bb7ba71bd3ea@oracle.com> <2c2da6d72f1743d689608c8c67fe7a8c@DEWDFE13DE14.global.corp.sap> Message-ID: <26336399-2b6a-a5a8-c841-63fc95f28804@oracle.com> Fine with me. /Erik On 2017-02-03 12:08, Baesken, Matthias wrote: > Hi Erik, thanks for your ideas and comments. > >> While your change is ok and can certainly be pushed on its own, there is >> so much more needing cleanup here. > I would like to do the other suggested cleanups in a separate change. > Is this fine, can the original change be pushed ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] >> Sent: Donnerstag, 2. Februar 2017 17:45 >> To: Baesken, Matthias ; build- >> dev at openjdk.java.net >> Cc: Simonis, Volker >> Subject: Re: RFR [XXS] : cleanup macosx jspawnhelper build settings >> >> Hello Matthias, >> >> While your change is ok and can certainly be pushed on its own, there is >> so much more needing cleanup here. If you don't mind, here is what I >> think needs doing: >> >> * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, >> BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since >> these >> variables aren't conditionally changed anywhere, there is really no need >> for the indirection. >> >> * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += >> $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the >> compiler for a 64 bit target to produce a 64 bit binary given the >> standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very >> old and confused code >> >> * The src dir only has the one src file, no need to explicitly list it >> for include. >> >> * The adding of childproc.o to LIBS can be accomplished using the >> parameter EXTRA_OBJECT_FILES. By using that you automatically get the >> dependency declaration so you can remove the line >> "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" >> >> * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the >> single conditional into it's place. >> >> Thanks >> /Erik >> >> On 2017-02-02 17:25, Baesken, Matthias wrote: >>> Hello, >>> could I please have a review for the following small change that cleans >> up the special macosx BUILD_JSPAWNHELPER_DST_DIR setting that is not >> really >>> needed any more after CR 8066474: "Remove the lib/ directory from >> Linux and Solaris images" changed the default setting . >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8173834 >>> >>> webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8173834.0/ >>> >>> >>> Thanks, Matthias From erik.joelsson at oracle.com Fri Feb 3 12:28:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 13:28:17 +0100 Subject: RFR: JDK-8059000 hgforest: pass options to serve command In-Reply-To: References: Message-ID: <0d1f1326-1c66-7be6-d174-51e0d3b62b79@oracle.com> Looks good. /Erik On 2017-02-03 13:21, Magnus Ihse Bursie wrote: > Pass options to serve command in hgforest.sh. Mostly necessary for > --port option. > > Original patch was written by Michael Duigou, but it has bit-rotted > since created so I had to adapt it to the current hgforest.sh. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059000 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8059000-pass-options-to-hgforest-serve/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 3 12:59:39 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 3 Feb 2017 13:59:39 +0100 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited Message-ID: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> There is a limitation in jtreg that causes it to fail if called with -concurrency:X where X is > 50. This can happen on a multi-core machine, were we set the JOBS value to e.g. 64. Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 Patch inline: diff --git a/test/Makefile b/test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -60,7 +60,12 @@ -include $(TOPDIR)/closed/test/Makefile ifeq ($(TEST_JOBS), 0) - JDK_TEST_JOBS=$(JOBS) + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) + # JTReg cannot handle more than 50 in concurrency + JDK_TEST_JOBS=50 + else + JDK_TEST_JOBS=$(JOBS) + endif else JDK_TEST_JOBS=$(TEST_JOBS) endif /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 3 13:14:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 3 Feb 2017 14:14:45 +0100 Subject: RFR: JDK-8004842 Unify values of boolean make variables set in configure to true/false Message-ID: <1ac03bd3-9b8a-aafd-da05-f8e06f4515d5@oracle.com> Currently there are three different ways of expressing a boolean value in spec.gmk, true/false, yes/no and 1/0. We should only have one and since true/false is the most common one, we should stick to that. Since this bug was opened, most cases has been fixed but two remains: USE_PRECOMPILED_HEADER=1 ENABLE_INTREE_EC=yes Bug: https://bugs.openjdk.java.net/browse/JDK-8004842 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8004842-standardize-booleans-in-build/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Feb 3 13:31:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 14:31:10 +0100 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited In-Reply-To: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> References: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> Message-ID: <0a693eb7-0942-510a-c505-592ca2a6b4ba@oracle.com> Looks ok. /Erik On 2017-02-03 13:59, Magnus Ihse Bursie wrote: > There is a limitation in jtreg that causes it to fail if called with > -concurrency:X where X is > 50. This can happen on a multi-core > machine, were we set the JOBS value to e.g. 64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 > > Patch inline: > diff --git a/test/Makefile b/test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -60,7 +60,12 @@ > -include $(TOPDIR)/closed/test/Makefile > > ifeq ($(TEST_JOBS), 0) > - JDK_TEST_JOBS=$(JOBS) > + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) > + # JTReg cannot handle more than 50 in concurrency > + JDK_TEST_JOBS=50 > + else > + JDK_TEST_JOBS=$(JOBS) > + endif > else > JDK_TEST_JOBS=$(TEST_JOBS) > endif > > /Magnus > From erik.joelsson at oracle.com Fri Feb 3 13:32:34 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 14:32:34 +0100 Subject: RFR: JDK-8004842 Unify values of boolean make variables set in configure to true/false In-Reply-To: <1ac03bd3-9b8a-aafd-da05-f8e06f4515d5@oracle.com> References: <1ac03bd3-9b8a-aafd-da05-f8e06f4515d5@oracle.com> Message-ID: <04098959-03bc-5555-144c-d17f41c84ce2@oracle.com> Looks good. /Erik On 2017-02-03 14:14, Magnus Ihse Bursie wrote: > Currently there are three different ways of expressing a boolean value > in spec.gmk, true/false, yes/no and 1/0. We should only have one and > since true/false is the most common one, we should stick to that. > > Since this bug was opened, most cases has been fixed but two remains: > USE_PRECOMPILED_HEADER=1 > ENABLE_INTREE_EC=yes > > Bug: https://bugs.openjdk.java.net/browse/JDK-8004842 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8004842-standardize-booleans-in-build/webrev.01 > > /Magnus > From stefan.sarne at oracle.com Fri Feb 3 14:50:30 2017 From: stefan.sarne at oracle.com (Stefan Sarne) Date: Fri, 3 Feb 2017 15:50:30 +0100 Subject: RFR(S): JDK-8173894: jib reports version "" in jdk10 Message-ID: Hi, Please review and sponsor this small patch to jib profiles. It makes sure version parsing handles 10. Thanks, Stefan - - - # HG changeset patch # User ssarne # Date 1486133045 -3600 # Fri Feb 03 15:44:05 2017 +0100 # Node ID b0a2d45408861586b361cf19d6a3522f05d27bd9 # Parent d98052f2d47963a36e93f699a1cb85dc69e695be JDK-8173894: jib reports version "" in jdk10 Summary: Update getVersion function, missing \ in regexp when stripping trailing zeros. Reviewed-by: Contributed-by: stefan.sarne at oracle.com diff -r d98052f2d479 -r b0a2d4540886 common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js Tue Jan 31 21:06:43 2017 -0500 +++ b/common/conf/jib-profiles.js Fri Feb 03 15:44:05 2017 +0100 @@ -1067,7 +1067,7 @@ + "." + (minor != null ? minor : version_numbers.get("DEFAULT_VERSION_MINOR")) + "." + (security != null ? security : version_numbers.get("DEFAULT_VERSION_SECURITY")) + "." + (patch != null ? patch : version_numbers.get("DEFAULT_VERSION_PATCH")); - while (version.match(".*\.0$")) { + while (version.match(".*\\.0$")) { version = version.substring(0, version.length - 2); } return version; From erik.joelsson at oracle.com Fri Feb 3 15:02:30 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Feb 2017 16:02:30 +0100 Subject: RFR(S): JDK-8173894: jib reports version "" in jdk10 In-Reply-To: References: Message-ID: <2256e586-05f0-5353-e3ea-f17925db0b5b@oracle.com> Looks good, will push. /Erik On 2017-02-03 15:50, Stefan Sarne wrote: > Hi, > > Please review and sponsor this small patch to jib profiles. > It makes sure version parsing handles 10. > > Thanks, > Stefan > > - - - > > # HG changeset patch > # User ssarne > # Date 1486133045 -3600 > # Fri Feb 03 15:44:05 2017 +0100 > # Node ID b0a2d45408861586b361cf19d6a3522f05d27bd9 > # Parent d98052f2d47963a36e93f699a1cb85dc69e695be > JDK-8173894: jib reports version "" in jdk10 > Summary: Update getVersion function, missing \ in regexp when > stripping trailing zeros. > Reviewed-by: > Contributed-by: stefan.sarne at oracle.com > > diff -r d98052f2d479 -r b0a2d4540886 common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js Tue Jan 31 21:06:43 2017 -0500 > +++ b/common/conf/jib-profiles.js Fri Feb 03 15:44:05 2017 +0100 > @@ -1067,7 +1067,7 @@ > + "." + (minor != null ? minor : > version_numbers.get("DEFAULT_VERSION_MINOR")) > + "." + (security != null ? security : > version_numbers.get("DEFAULT_VERSION_SECURITY")) > + "." + (patch != null ? patch : > version_numbers.get("DEFAULT_VERSION_PATCH")); > - while (version.match(".*\.0$")) { > + while (version.match(".*\\.0$")) { > version = version.substring(0, version.length - 2); > } > return version; > From martinrb at google.com Fri Feb 3 15:39:49 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 3 Feb 2017 07:39:49 -0800 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited In-Reply-To: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> References: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> Message-ID: Does your jtreg have the latest javatest? https://bugs.openjdk.java.net/browse/CODETOOLS-7183756 On Fri, Feb 3, 2017 at 4:59 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > There is a limitation in jtreg that causes it to fail if called with > -concurrency:X where X is > 50. This can happen on a multi-core machine, > were we set the JOBS value to e.g. 64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 > > Patch inline: > diff --git a/test/Makefile b/test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -60,7 +60,12 @@ > -include $(TOPDIR)/closed/test/Makefile > > ifeq ($(TEST_JOBS), 0) > - JDK_TEST_JOBS=$(JOBS) > + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) > + # JTReg cannot handle more than 50 in concurrency > + JDK_TEST_JOBS=50 > + else > + JDK_TEST_JOBS=$(JOBS) > + endif > else > JDK_TEST_JOBS=$(TEST_JOBS) > endif > > /Magnus > > From openjdk at duigou.org Fri Feb 3 17:35:27 2017 From: openjdk at duigou.org (Mike Duigou) Date: Fri, 03 Feb 2017 07:35:27 -1000 Subject: RFR: JDK-8059000 hgforest: pass options to serve command In-Reply-To: References: Message-ID: <93f4f9f87631b71c9ecb818ff4f82a5b@duigou.org> Looks good! Mike On 2017-02-03 02:21, Magnus Ihse Bursie wrote: > Pass options to serve command in hgforest.sh. Mostly necessary for > --port option. > > Original patch was written by Michael Duigou, but it has bit-rotted > since created so I had to adapt it to the current hgforest.sh. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059000 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8059000-pass-options-to-hgforest-serve/webrev.01 > > /Magnus From jonathan.gibbons at oracle.com Fri Feb 3 19:13:19 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 03 Feb 2017 11:13:19 -0800 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited In-Reply-To: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> References: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> Message-ID: <5894D64F.2010701@oracle.com> I thought this was fixed a long time ago, meaning the limit was raised. -- Jon On 02/03/2017 04:59 AM, Magnus Ihse Bursie wrote: > There is a limitation in jtreg that causes it to fail if called with > -concurrency:X where X is > 50. This can happen on a multi-core > machine, were we set the JOBS value to e.g. 64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 > > Patch inline: > diff --git a/test/Makefile b/test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -60,7 +60,12 @@ > -include $(TOPDIR)/closed/test/Makefile > > ifeq ($(TEST_JOBS), 0) > - JDK_TEST_JOBS=$(JOBS) > + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) > + # JTReg cannot handle more than 50 in concurrency > + JDK_TEST_JOBS=50 > + else > + JDK_TEST_JOBS=$(JOBS) > + endif > else > JDK_TEST_JOBS=$(TEST_JOBS) > endif > > /Magnus > From david.holmes at oracle.com Mon Feb 6 03:47:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Feb 2017 13:47:25 +1000 Subject: RFR: JDK-8004842 Unify values of boolean make variables set in configure to true/false In-Reply-To: <1ac03bd3-9b8a-aafd-da05-f8e06f4515d5@oracle.com> References: <1ac03bd3-9b8a-aafd-da05-f8e06f4515d5@oracle.com> Message-ID: <2e09e05f-bbc9-80ee-65a5-100a4032fbdd@oracle.com> Hi Magnus, On 3/02/2017 11:14 PM, Magnus Ihse Bursie wrote: > Currently there are three different ways of expressing a boolean value > in spec.gmk, true/false, yes/no and 1/0. We should only have one and > since true/false is the most common one, we should stick to that. > > Since this bug was opened, most cases has been fixed but two remains: > USE_PRECOMPILED_HEADER=1 One nit: hotspot/src/share/vm/precompiled/precompiled.hpp I don't think we normally document configure args in the source code, and I would expect that we can still pass USE_PRECOMPILED_HEADERS=true/false as a make arg. So I think this should also just change 0 to false. Thanks, David > ENABLE_INTREE_EC=yes > > Bug: https://bugs.openjdk.java.net/browse/JDK-8004842 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8004842-standardize-booleans-in-build/webrev.01 > > > /Magnus > From magnus.ihse.bursie at oracle.com Mon Feb 6 09:11:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 6 Feb 2017 10:11:37 +0100 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited In-Reply-To: References: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> Message-ID: <0FB17012-BB32-479A-8953-D7D018C1C749@oracle.com> > On 2017-02-03 16:39, Martin Buchholz wrote: > Does your jtreg have the latest javatest? > > https://bugs.openjdk.java.net/browse/CODETOOLS-7183756 I can't tell how that bug was fixed, but the code I checked in did have: protected int getMaxConcurrency() { // return Parameters.ConcurrencyParameters.MAX_CONCURRENCY; return 50; } in BasicInterviewParameters.java. /Magnus > > On Fri, Feb 3, 2017 at 4:59 AM, Magnus Ihse Bursie wrote: >> There is a limitation in jtreg that causes it to fail if called with -concurrency:X where X is > 50. This can happen on a multi-core machine, were we set the JOBS value to e.g. 64. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 >> >> Patch inline: >> diff --git a/test/Makefile b/test/Makefile >> --- a/test/Makefile >> +++ b/test/Makefile >> @@ -60,7 +60,12 @@ >> -include $(TOPDIR)/closed/test/Makefile >> >> ifeq ($(TEST_JOBS), 0) >> - JDK_TEST_JOBS=$(JOBS) >> + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) >> + # JTReg cannot handle more than 50 in concurrency >> + JDK_TEST_JOBS=50 >> + else >> + JDK_TEST_JOBS=$(JOBS) >> + endif >> else >> JDK_TEST_JOBS=$(TEST_JOBS) >> endif >> >> /Magnus From jonathan.gibbons at oracle.com Mon Feb 6 19:38:51 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 06 Feb 2017 11:38:51 -0800 Subject: RFR: JDK-8172912 JTReg concurrency value must be limited In-Reply-To: <0FB17012-BB32-479A-8953-D7D018C1C749@oracle.com> References: <7cc98859-3bb0-e4d5-e1ea-b888139e44e6@oracle.com> <0FB17012-BB32-479A-8953-D7D018C1C749@oracle.com> Message-ID: <5898D0CB.1030403@oracle.com> Magnus, Hmmm, you're correct, according to what I consider to the the reference sources for jtharness. The following method is the one you quote. http://hg.openjdk.java.net/code-tools/jtharness/file/9927669dc36f/src/com/sun/javatest/interview/BasicInterviewParameters.java#l370 The confusion comes from looking at this line http://hg.openjdk.java.net/code-tools/jtharness/file/9927669dc36f/src/com/sun/javatest/Parameters.java#l882 which says: /** * The highest allowed value for the concurrency. */ static int MAX_CONCURRENCY = 256; I will work to get this fixed. -- Jon On 02/06/2017 01:11 AM, Magnus Ihse Bursie wrote: > On 2017-02-03 16:39, Martin Buchholz wrote: >> Does your jtreg have the latest javatest? >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7183756 > > I can't tell how that bug was fixed, but the code I checked in did have: > protected int getMaxConcurrency() { > // return Parameters.ConcurrencyParameters.MAX_CONCURRENCY; > return 50; > } > in BasicInterviewParameters.java. > > /Magnus > >> >> On Fri, Feb 3, 2017 at 4:59 AM, Magnus Ihse Bursie >> > > wrote: >> >> There is a limitation in jtreg that causes it to fail if called >> with -concurrency:X where X is > 50. This can happen on a >> multi-core machine, were we set the JOBS value to e.g. 64. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172912 >> >> >> Patch inline: >> diff --git a/test/Makefile b/test/Makefile >> --- a/test/Makefile >> +++ b/test/Makefile >> @@ -60,7 +60,12 @@ >> -include $(TOPDIR)/closed/test/Makefile >> >> ifeq ($(TEST_JOBS), 0) >> - JDK_TEST_JOBS=$(JOBS) >> + ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) >> + # JTReg cannot handle more than 50 in concurrency >> + JDK_TEST_JOBS=50 >> + else >> + JDK_TEST_JOBS=$(JOBS) >> + endif >> else >> JDK_TEST_JOBS=$(TEST_JOBS) >> endif >> >> /Magnus >> >> > From magnus.ihse.bursie at oracle.com Tue Feb 7 08:02:17 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 Feb 2017 09:02:17 +0100 Subject: RFR: JDK-8174064 Tab expansion broken for make Message-ID: <8c6b7070-bbeb-3355-a5da-14b656d3960b@oracle.com> With recent versions of the standard bash completion scripts for make, tab expansion targets are extracted using make -pq, while the code only checks for -qp. This fix makes the test more robust to handle both cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8174064 Patch inline: diff --git a/make/Init.gmk b/make/Init.gmk --- a/make/Init.gmk +++ b/make/Init.gmk @@ -66,7 +66,7 @@ ifeq ($(CALLED_SPEC_TARGETS), ) ONLY_GLOBAL_TARGETS := true endif - ifneq ($(findstring qp, $(MAKEFLAGS)),) + ifeq ($(findstring p, $(MAKEFLAGS))$(findstring q, $(MAKEFLAGS)), pq) ONLY_GLOBAL_TARGETS := true endif /Magnus From erik.joelsson at oracle.com Tue Feb 7 08:20:49 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Feb 2017 09:20:49 +0100 Subject: RFR: JDK-8174064 Tab expansion broken for make In-Reply-To: <8c6b7070-bbeb-3355-a5da-14b656d3960b@oracle.com> References: <8c6b7070-bbeb-3355-a5da-14b656d3960b@oracle.com> Message-ID: <6162a70a-3adc-8803-7ca4-5033d704b21d@oracle.com> Looks good. /Erik On 2017-02-07 09:02, Magnus Ihse Bursie wrote: > With recent versions of the standard bash completion scripts for make, > tab expansion targets are extracted using make -pq, while the code > only checks for -qp. This fix makes the test more robust to handle > both cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174064 > Patch inline: > diff --git a/make/Init.gmk b/make/Init.gmk > --- a/make/Init.gmk > +++ b/make/Init.gmk > @@ -66,7 +66,7 @@ > ifeq ($(CALLED_SPEC_TARGETS), ) > ONLY_GLOBAL_TARGETS := true > endif > - ifneq ($(findstring qp, $(MAKEFLAGS)),) > + ifeq ($(findstring p, $(MAKEFLAGS))$(findstring q, $(MAKEFLAGS)), pq) > ONLY_GLOBAL_TARGETS := true > endif > > /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 7 10:09:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 Feb 2017 11:09:07 +0100 Subject: RFR: JDK-8174069 Verify that bash is at least version 3.2 Message-ID: <992219b4-9398-b1d3-284d-fa63e2d80d61@oracle.com> The build system uses features in make that was not present before 3.2. Bash 3.2 was released in 2007 so only very old systems is on 3.1 or older. However, we fail with strange error messages on such old systems, so we should check the version in configure. Bug: https://bugs.openjdk.java.net/browse/JDK-8174069 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8174069-check-bash-version/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Feb 7 10:24:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Feb 2017 11:24:27 +0100 Subject: RFR: JDK-8174069 Verify that bash is at least version 3.2 In-Reply-To: <992219b4-9398-b1d3-284d-fa63e2d80d61@oracle.com> References: <992219b4-9398-b1d3-284d-fa63e2d80d61@oracle.com> Message-ID: Looks good. /Erik On 2017-02-07 11:09, Magnus Ihse Bursie wrote: > The build system uses features in make that was not present before > 3.2. Bash 3.2 was released in 2007 so only very old systems is on 3.1 > or older. However, we fail with strange error messages on such old > systems, so we should check the version in configure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174069 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8174069-check-bash-version/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 7 14:05:51 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 7 Feb 2017 15:05:51 +0100 Subject: make doesn't create failure-logs directory In-Reply-To: <7970D99C-C6DF-4081-BEB0-67ED0C762F6D@mycosystems.co.uk> References: <7970D99C-C6DF-4081-BEB0-67ED0C762F6D@mycosystems.co.uk> Message-ID: On 2017-01-30 16:28, Mike Burton wrote: > While looking at JDK-8173375 I found that `make` does not create the directory `build/linux-x86_64-normal-server-release/make-support/failure-logs` during a failed build. I couldn?t find reference to this in build-dev archives so maybe a new bug? > > Mike Burton I'm not sure why you think this is the case. In make/InitSupport.gmk, we have: define PrepareFailureLogs $(RM) -r $(MAKESUPPORT_OUTPUTDIR)/failure-logs 2> /dev/null && \ $(MKDIR) -p $(MAKESUPPORT_OUTPUTDIR)/failure-logs endef Unless rm is returning a non-0 exit code, that should work perfectly well. I've never seen it fail. Can you reproduce this problem? /Magnus From mikeb at mycosystems.co.uk Tue Feb 7 16:08:55 2017 From: mikeb at mycosystems.co.uk (Mike Burton) Date: Tue, 7 Feb 2017 16:08:55 +0000 Subject: make doesn't create failure-logs directory In-Reply-To: References: <7970D99C-C6DF-4081-BEB0-67ED0C762F6D@mycosystems.co.uk> Message-ID: <32D0A83D-B113-49B8-AF70-29531ECC0561@mycosystems.co.uk> No I can?t reproduce it, not sure why it failed before, sorry to have bothered you. Mike > On 7 Feb 2017, at 14:05, Magnus Ihse Bursie wrote: > > On 2017-01-30 16:28, Mike Burton wrote: >> While looking at JDK-8173375 I found that `make` does not create the directory `build/linux-x86_64-normal-server-release/make-support/failure-logs` during a failed build. I couldn?t find reference to this in build-dev archives so maybe a new bug? >> >> Mike Burton >> > > I'm not sure why you think this is the case. In make/InitSupport.gmk, we have: > > define PrepareFailureLogs > $(RM) -r $(MAKESUPPORT_OUTPUTDIR)/failure-logs 2> /dev/null && \ > $(MKDIR) -p $(MAKESUPPORT_OUTPUTDIR)/failure-logs > endef > > Unless rm is returning a non-0 exit code, that should work perfectly well. I've never seen it fail. Can you reproduce this problem? > > /Magnus From matthias.baesken at sap.com Wed Feb 8 08:00:46 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 8 Feb 2017 08:00:46 +0000 Subject: RFR [XS] : jspawnhelper build settings cleanup Message-ID: Hello all , Erik suggested to do further cleanups in make/launcher/Launcher-java.base.gmk In the jspawnhelper build section. Those were the suggestions : * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since these variables aren't conditionally changed anywhere, there is really no need for the indirection. * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the compiler for a 64 bit target to produce a 64 bit binary given the standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very old and confused code * The src dir only has the one src file, no need to explicitly list it for include. * The adding of childproc.o to LIBS can be accomplished using the parameter EXTRA_OBJECT_FILES. By using that you automatically get the dependency declaration so you can remove the line "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the single conditional into it's place. I prepared a webrev for this. After removing the BUILD_JSPAWNHELPER_LDFLAGS += $(COMPILER_TARGET_BITS_FLAG)64 I checked that the generated executable is still 64bit on AIX/Solaris/Mac-OSX (however the -m64 seems to be gone on Mac after this change Compared to before when generating the executable). Btw the BUILD_JEXEC in make/launcher/Launcher-java.base.gmk looks also a bit strange (similar issues as the jspawnhelper section). Bug : https://bugs.openjdk.java.net/browse/JDK-8174086 webrev jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.0/ Please review my change . Thanks ,Matthias From erik.joelsson at oracle.com Wed Feb 8 10:10:58 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 8 Feb 2017 11:10:58 +0100 Subject: RFR [XS] : jspawnhelper build settings cleanup In-Reply-To: References: Message-ID: <960a32ca-4e13-5a71-a55b-409d979ef970@oracle.com> Hello Matthias, Thanks for taking this on! You can still remove "INCLUDE_FILES := jspawnhelper.c". Another thing that struck me when looking at this is the inconsistency of sometimes using $(MODULE) and sometimes explicitly using java.base in the paths. I think $(MODULE) is better in this context. Finally you could adopt the newer formatting style of using a space after comma at line 139 and end the eval-call with ', \' after the last argument and the double parenthesis on a new line on its own. You are correct that JEXEC is suffering from many of the same issues. You are very welcome to fix that too, in this or another bug. /Erik On 2017-02-08 09:00, Baesken, Matthias wrote: > > Hello all , > > Erik suggested to do further cleanups in > make/launcher/Launcher-java.base.gmk > > In the jspawnhelper build section. > > Those were the suggestions : > > * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, > > BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since these > > variables aren't conditionally changed anywhere, there is really no need > > for the indirection. > > * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += > > $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the > > compiler for a 64 bit target to produce a 64 bit binary given the > > standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very > > old and confused code > > * The src dir only has the one src file, no need to explicitly list it > > for include. > > * The adding of childproc.o to LIBS can be accomplished using the > > parameter EXTRA_OBJECT_FILES. By using that you automatically get the > > dependency declaration so you can remove the line > > "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" > > * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the > > single conditional into it's place. > > I prepared a webrev for this. > > After removing the BUILD_JSPAWNHELPER_LDFLAGS += > $(COMPILER_TARGET_BITS_FLAG)64 > > I checked that the generated executable is still 64bit on > AIX/Solaris/Mac-OSX (however the -m64 seems to be gone on Mac after > this change > > Compared to before when generating the executable). > > Btw the BUILD_JEXEC in make/launcher/Launcher-java.base.gmk > looks also a bit strange (similar issues as the jspawnhelper section). > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8174086 > > webrev jdk10 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.0/ > > > Please review my change . > > Thanks ,Matthias > From erik.joelsson at oracle.com Wed Feb 8 11:33:03 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 8 Feb 2017 12:33:03 +0100 Subject: RFR: JDK-8174172: Race when building java.base.jmod Message-ID: When building java.base.jmod, we use --hash-modules to include hashes of all the non upgradeable jmods in java.base.jmod. The make dependencies are setup to make sure all non upgradeable jmods are built before java.base.jmod. In some cases, this risks failing because we have a non upgradeable module which depends on an upgradeable module. If this upgradeable module is not available to the jmod tool, it will fail. The solution is to add all jmods as prerequisites to building java.base.jmod instead of just the non upgradeable ones. Bug: https://bugs.openjdk.java.net/browse/JDK-8174172 Patch: diff -r 98503c50ee77 make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -654,8 +654,7 @@ # When creating a BUILDJDK, we don't need to add hashes to java.base, thus # we don't need to depend on all other jmods ifneq ($(CREATING_BUILDJDK), true) - java.base-jmod: jrtfs-jar $(filter-out java.base-jmod \ - $(addsuffix -jmod, $(call FindAllUpgradeableModules)), $(JMOD_TARGETS)) + java.base-jmod: jrtfs-jar $(filter-out java.base-jmod, $(JMOD_TARGETS)) endif # Building java.base-jmod requires all of hotspot to be built. /Erik From Alan.Bateman at oracle.com Wed Feb 8 11:39:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Feb 2017 11:39:13 +0000 Subject: RFR: JDK-8174172: Race when building java.base.jmod In-Reply-To: References: Message-ID: On 08/02/2017 11:33, Erik Joelsson wrote: > When building java.base.jmod, we use --hash-modules to include hashes > of all the non upgradeable jmods in java.base.jmod. The make > dependencies are setup to make sure all non upgradeable jmods are > built before java.base.jmod. In some cases, this risks failing because > we have a non upgradeable module which depends on an upgradeable > module. If this upgradeable module is not available to the jmod tool, > it will fail. > > The solution is to add all jmods as prerequisites to building > java.base.jmod instead of just the non upgradeable ones. This looks okay although ideally we should not have non upgradeable modules depending on upgradeable modules. -Alan. From mandy.chung at oracle.com Wed Feb 8 16:15:55 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Feb 2017 08:15:55 -0800 Subject: RFR: JDK-8174172: Race when building java.base.jmod In-Reply-To: References: Message-ID: > On Feb 8, 2017, at 3:39 AM, Alan Bateman wrote: > > On 08/02/2017 11:33, Erik Joelsson wrote: > >> When building java.base.jmod, we use --hash-modules to include hashes of all the non upgradeable jmods in java.base.jmod. The make dependencies are setup to make sure all non upgradeable jmods are built before java.base.jmod. In some cases, this risks failing because we have a non upgradeable module which depends on an upgradeable module. If this upgradeable module is not available to the jmod tool, it will fail. >> >> The solution is to add all jmods as prerequisites to building java.base.jmod instead of just the non upgradeable ones. > This looks okay although ideally we should not have non upgradeable modules depending on upgradeable modules. > The change looks fine to me. This is an odd case that FX module depending on an upgradeable module. One option is to make such FX module upgradeable but that seems to be less preferred. We will revisit this in JDK 10. Mandy From bob.vandette at oracle.com Wed Feb 8 19:29:19 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 8 Feb 2017 14:29:19 -0500 Subject: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too) Message-ID: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> SUMMARY: Please review the following set of changes that adds Ahead-of-time compilation support for Mac OSX and Windows x64 in JDK 10. Linux and Solaris x64 AOT support has also been updated to be consistent with the new 100% Java based binary container support included in this changeset. This change also removes the build and runtime dependency on the external libelf library and header files. Once this change is integrated Ahead of time support will be available for the following set of Platforms: - Linux x64 - Windows x64 - MacOSX x64 - Solaris x64 RFE: https://bugs.openjdk.java.net/browse/JDK-8172670 WEBREVS: TOP LEVEL ????? http://cr.openjdk.java.net/~bobv/8172670/webrev.01/ JDK ?? http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/ HOTSPOT ????? Full Hotspot Webrev: http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev.01/ If you?d prefer to review things in smaller chunks, here are the hotspot changes for Linux and Solaris including the libelf removal: http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-linux.01/ Files added to support Mac OSX: http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-mac.01/ Files added to provide Windows support: http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-win.01/ Changes to the jtreg tests for AOT: http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-test.01/ TESTING: 1. JPRT has been run and passes with these changes 2. jtreg AOT tests pass on all supported platforms 3. AOT compiling of java.base completes and can run basic Java programs on all supported platforms NOTE: 1. Although these test run correctly on Windows, jtreg AOT tests have been temporarily disabled for this platform. This is due to an internal JPRT system configuration issue which will hopefully get resolved soon. AOT requires access to a local toolchain and our JPRT systems do not regularly install Visual Studio. Thanks, Bob. From vladimir.kozlov at oracle.com Thu Feb 9 03:04:51 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Feb 2017 19:04:51 -0800 Subject: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too) In-Reply-To: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> References: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> Message-ID: On 2/8/17 11:29 AM, Bob Vandette wrote: > SUMMARY: > > Please review the following set of changes that adds Ahead-of-time compilation support for Mac OSX and > Windows x64 in JDK 10. Linux and Solaris x64 AOT support has also been updated to be consistent with > the new 100% Java based binary container support included in this changeset. > > This change also removes the build and runtime dependency on the external libelf library and header files. > > Once this change is integrated Ahead of time support will be available for the following set of Platforms: > > - Linux x64 > - Windows x64 > - MacOSX x64 > - Solaris x64 > > RFE: > > https://bugs.openjdk.java.net/browse/JDK-8172670 > > WEBREVS: > > TOP LEVEL > ????? > > http://cr.openjdk.java.net/~bobv/8172670/webrev.01/ Good. > > JDK > ?? > > http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/ Looks good to me but need to be reviewed by build jigsaw team. > > HOTSPOT > ????? > > Full Hotspot Webrev: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev.01/ Both AOT tool and JVM changes looks good to me. Thanks, Vladimir > > > If you?d prefer to review things in smaller chunks, here are the hotspot changes for Linux and > Solaris including the libelf removal: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-linux.01/ > > Files added to support Mac OSX: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-mac.01/ > > Files added to provide Windows support: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-win.01/ > > Changes to the jtreg tests for AOT: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-test.01/ > > > TESTING: > > 1. JPRT has been run and passes with these changes > 2. jtreg AOT tests pass on all supported platforms > 3. AOT compiling of java.base completes and can run basic Java programs on all supported platforms > > NOTE: > > 1. Although these test run correctly on Windows, jtreg AOT tests have been temporarily disabled for this platform. > This is due to an internal JPRT system configuration issue which will hopefully get resolved soon. AOT requires > access to a local toolchain and our JPRT systems do not regularly install Visual Studio. > > > Thanks, > Bob. > From mandy.chung at oracle.com Thu Feb 9 03:36:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 8 Feb 2017 19:36:28 -0800 Subject: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too) In-Reply-To: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> References: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> Message-ID: <95FC69EC-2F6C-4816-9B5C-BA6D99F2A67B@oracle.com> > On Feb 8, 2017, at 11:29 AM, Bob Vandette wrote: > > JDK > ?? > > http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/ > The jdk change looks fine. If any change to module-info.java.extra in JDK 9 for jdk.vm.compiler, we should make sure the same change applies to windows version. Mandy From erik.joelsson at oracle.com Thu Feb 9 08:39:04 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 Feb 2017 09:39:04 +0100 Subject: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too) In-Reply-To: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> References: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> Message-ID: <4d383bab-959e-f789-53d3-61f3bf40ae08@oracle.com> Hello, Looks good, just one minor comment below. On 2017-02-08 20:29, Bob Vandette wrote: > SUMMARY: > > Please review the following set of changes that adds Ahead-of-time compilation support for Mac OSX and > Windows x64 in JDK 10. Linux and Solaris x64 AOT support has also been updated to be consistent with > the new 100% Java based binary container support included in this changeset. > > This change also removes the build and runtime dependency on the external libelf library and header files. > > Once this change is integrated Ahead of time support will be available for the following set of Platforms: > > - Linux x64 > - Windows x64 > - MacOSX x64 > - Solaris x64 > > RFE: > > https://bugs.openjdk.java.net/browse/JDK-8172670 > > WEBREVS: > > TOP LEVEL > ????? > > http://cr.openjdk.java.net/~bobv/8172670/webrev.01/ hotspot.m4: The variable OPENJDK_TARGET_CPU can never have the value "amd64" so no need to test for it. (if it does, it's a bug) > > JDK > ?? > > http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/ > > HOTSPOT > ????? > > Full Hotspot Webrev: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev.01/ > > > If you?d prefer to review things in smaller chunks, here are the hotspot changes for Linux and > Solaris including the libelf removal: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-linux.01/ > > Files added to support Mac OSX: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-mac.01/ > > Files added to provide Windows support: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-win.01/ > > Changes to the jtreg tests for AOT: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-test.01/ > > > TESTING: > > 1. JPRT has been run and passes with these changes > 2. jtreg AOT tests pass on all supported platforms > 3. AOT compiling of java.base completes and can run basic Java programs on all supported platforms > > NOTE: > > 1. Although these test run correctly on Windows, jtreg AOT tests have been temporarily disabled for this platform. > This is due to an internal JPRT system configuration issue which will hopefully get resolved soon. AOT requires > access to a local toolchain and our JPRT systems do not regularly install Visual Studio. We need to discuss this, will send a separate mail. /Erik > > Thanks, > Bob. From matthias.baesken at sap.com Thu Feb 9 08:53:11 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Feb 2017 08:53:11 +0000 Subject: RFR [XS] : jspawnhelper build settings cleanup In-Reply-To: <960a32ca-4e13-5a71-a55b-409d979ef970@oracle.com> References: <960a32ca-4e13-5a71-a55b-409d979ef970@oracle.com> Message-ID: Hi Erik, after your comments, I created a new webrev , please review : http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.1/ >You are correct that JEXEC is suffering from many of the same issues. You are very welcome to fix that too, in this or another bug. I think this should go into another bug. Thanks and best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Mittwoch, 8. Februar 2017 11:11 To: Baesken, Matthias ; build-dev at openjdk.java.net Cc: Langer, Christoph Subject: Re: RFR [XS] : jspawnhelper build settings cleanup Hello Matthias, Thanks for taking this on! You can still remove "INCLUDE_FILES := jspawnhelper.c". Another thing that struck me when looking at this is the inconsistency of sometimes using $(MODULE) and sometimes explicitly using java.base in the paths. I think $(MODULE) is better in this context. Finally you could adopt the newer formatting style of using a space after comma at line 139 and end the eval-call with ', \' after the last argument and the double parenthesis on a new line on its own. You are correct that JEXEC is suffering from many of the same issues. You are very welcome to fix that too, in this or another bug. /Erik On 2017-02-08 09:00, Baesken, Matthias wrote: Hello all , Erik suggested to do further cleanups in make/launcher/Launcher-java.base.gmk In the jspawnhelper build section. Those were the suggestions : * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since these variables aren't conditionally changed anywhere, there is really no need for the indirection. * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust the compiler for a 64 bit target to produce a 64 bit binary given the standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just very old and confused code * The src dir only has the one src file, no need to explicitly list it for include. * The adding of childproc.o to LIBS can be accomplished using the parameter EXTRA_OBJECT_FILES. By using that you automatically get the dependency declaration so you can remove the line "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the single conditional into it's place. I prepared a webrev for this. After removing the BUILD_JSPAWNHELPER_LDFLAGS += $(COMPILER_TARGET_BITS_FLAG)64 I checked that the generated executable is still 64bit on AIX/Solaris/Mac-OSX (however the -m64 seems to be gone on Mac after this change Compared to before when generating the executable). Btw the BUILD_JEXEC in make/launcher/Launcher-java.base.gmk looks also a bit strange (similar issues as the jspawnhelper section). Bug : https://bugs.openjdk.java.net/browse/JDK-8174086 webrev jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.0/ Please review my change . Thanks ,Matthias From erik.joelsson at oracle.com Thu Feb 9 08:55:53 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 Feb 2017 09:55:53 +0100 Subject: RFR [XS] : jspawnhelper build settings cleanup In-Reply-To: References: <960a32ca-4e13-5a71-a55b-409d979ef970@oracle.com> Message-ID: <1b5dae13-b1ff-eced-8334-0c28f735799c@oracle.com> Thank you, looks good! /Erik On 2017-02-09 09:53, Baesken, Matthias wrote: > > Hi Erik, after your comments, I created a new webrev , please review : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.1/ > > > >You are correct that JEXEC is suffering from many of the same issues. You are very welcome > to fix that too, in this or another bug. > > I think this should go into another bug. > > Thanks and best regards, Matthias > > *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com] > *Sent:* Mittwoch, 8. Februar 2017 11:11 > *To:* Baesken, Matthias ; > build-dev at openjdk.java.net > *Cc:* Langer, Christoph > *Subject:* Re: RFR [XS] : jspawnhelper build settings cleanup > > Hello Matthias, > > Thanks for taking this on! > > You can still remove "INCLUDE_FILES := jspawnhelper.c". > > Another thing that struck me when looking at this is the inconsistency > of sometimes using $(MODULE) and sometimes explicitly using java.base > in the paths. I think $(MODULE) is better in this context. > > Finally you could adopt the newer formatting style of using a space > after comma at line 139 and end the eval-call with ', \' after the > last argument and the double parenthesis on a new line on its own. > > You are correct that JEXEC is suffering from many of the same issues. > You are very welcome to fix that too, in this or another bug. > > /Erik > > On 2017-02-08 09:00, Baesken, Matthias wrote: > > Hello all , > > Erik suggested to do further cleanups in > make/launcher/Launcher-java.base.gmk > > In the jspawnhelper build section. > > Those were the suggestions : > > * Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS, > > BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Since these > > variables aren't conditionally changed anywhere, there is really > no need > > for the indirection. > > * The whole business of "BUILD_JSPAWNHELPER_LDFLAGS += > > $(COMPILER_TARGET_BITS_FLAG)64" is confusing to me. Don't we trust > the > > compiler for a 64 bit target to produce a 64 bit binary given the > > standard CFLAGS_JDKEXE and LDFLAGS_JDKLIB? I suspect this is just > very > > old and confused code > > * The src dir only has the one src file, no need to explicitly > list it > > for include. > > * The adding of childproc.o to LIBS can be accomplished using the > > parameter EXTRA_OBJECT_FILES. By using that you automatically get the > > dependency declaration so you can remove the line > > "$(BUILD_JSPAWNHELPER): $(LINK_JSPAWNHELPER_OBJECTS)" > > * The ifeq ($(BUILD_JSPAWNHELPER), 1) is also annoying, just move the > > single conditional into it's place. > > I prepared a webrev for this. > > After removing the BUILD_JSPAWNHELPER_LDFLAGS += > $(COMPILER_TARGET_BITS_FLAG)64 > > I checked that the generated executable is still 64bit on > AIX/Solaris/Mac-OSX (however the -m64 seems to be gone on Mac > after this change > > Compared to before when generating the executable). > > Btw the BUILD_JEXEC in make/launcher/Launcher-java.base.gmk > looks also a bit strange (similar issues as the jspawnhelper > section). > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8174086 > > webrev jdk10 : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8174086.0/ > > > Please review my change . > > Thanks ,Matthias > From matthias.baesken at sap.com Thu Feb 9 11:36:43 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Feb 2017 11:36:43 +0000 Subject: jdk10 : simplify jexec build settings Message-ID: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From erik.joelsson at oracle.com Thu Feb 9 12:42:21 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 Feb 2017 13:42:21 +0100 Subject: jdk10 : simplify jexec build settings In-Reply-To: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> Message-ID: Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: > > Hello , while adjusting the jspawnhelper build settings with 8174086, > it has been noticed that the jexec build settings need some > simplification as well. > > The bug > > https://bugs.openjdk.java.net/browse/JDK-8174242 > > has been created for this. > > When looking into it, I had some questions : > > http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk > > The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris > 32bit, but is this really supported in jdk 9 or 10 ( I think it > was removed in 9 and only 64bit Solaris support remains ) ? > We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. > > ifeq ($(OPENJDK_TARGET_OS), solaris) > > ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) > > BUILD_JEXEC := 1 > > endif > > endif > > ifeq ($(OPENJDK_TARGET_OS), linux) > > BUILD_JEXEC := 1 > > endif # OPENJDK_TARGET_OS > > # > > # jdk/make/java/jexec/Makefile > > # > > ifeq ($(BUILD_JEXEC), 1) > > Then there is handling for macosx left , but the build is not enabled > for macosx, does it still make sense to include the macosx handling > (there is even a separate jexec.c for macosx) : > This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik > ifeq ($(OPENJDK_TARGET_OS), windows) > > else ifeq ($(OPENJDK_TARGET_OS), macosx) > > BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher > > else > > BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher > > endif > > Should I remove the solaris 32bit / macosx handling for jexec from > make/launcher/Launcher-java.base.gmk ? > > Regards, Matthias > From matthias.baesken at sap.com Thu Feb 9 13:10:29 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Feb 2017 13:10:29 +0000 Subject: jdk10 : simplify jexec build settings In-Reply-To: References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> Message-ID: <7f89e4612cef4c3793ef73be2a7846c6@DEWDFE13DE14.global.corp.sap> Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias ; build-dev at openjdk.java.net Cc: Langer, Christoph Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From matthias.baesken at sap.com Thu Feb 9 14:27:29 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Feb 2017 14:27:29 +0000 Subject: jdk10 : simplify jexec build settings References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> Message-ID: <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> I compared the jexec.c versions for macosx and unix ( jdk/src/java.base/macosx/native/launcher/jexec.c and jdk/src/java.base/unix/native/launcher/jexec.c ) And to me it looks like the unix version could be used for macosx too (just in case there is a need to reenable the build of jexec.c for macosx one day again). Comments / suggestions ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Februar 2017 14:10 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias >; build-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From omajid at redhat.com Thu Feb 9 17:41:09 2017 From: omajid at redhat.com (Omair Majid) Date: Thu, 9 Feb 2017 12:41:09 -0500 Subject: libjvm.so, jmods and --with-native-debug-symbols=internal Message-ID: <20170209174109.GC2814@redhat.com> Hi, I have been working on building preview versions of OpenJDK 9 for Fedora. You can see the latest build here: https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/ One thing that I just realized is that we build OpenJDK 9 using the configure option --with-native-debug-symbols=internal. As far as I understand the build, this is what happens: 1. libjvm.so is built 2. libjvm.so is not stripped of any debug information 3. a jmod - java.base.jmod - containing libjvm.so is created 4. the jmod containing libjvm.so is extracted to create images/jdk/ (and images/jre/) Then the linux packaging tools (rpmbuild in my case) take over and do the following: 5. strip libjvm.so in images/jdk/, put stripped symbols in a separate location 6. Package up images/jdk/ into the distribution package 7. make a -debuginfo package (or -dbg in case of Debian) that contains the stripped symbols from libjvm.so So now users get a libjvm.so in the default package that's stripped and less than 20MB. They also get an optional -debuginfo (or -dbg) package that contains just the debug symbols. This lets them use the small package containing libjvm and but also lets them download a large package to debug libjvm.so if they wish. This is all great so far and works like it should. One new change that happened with OpenJDK 9 only is that the jmod (java.base.jmod here) contains the original and unstripped libjvm.so. This jmod also gets included into the images/jdk/. This bumps up the images/jdk/jmods directory size to hundreds of megabytes. Anyone who now wants to use jmods now ends up installing all the unstripped debuginfo, unintentionally, eating up disk space. Is this intentional or an unintended side-effect of various changes? Is it a known issue? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From bob.vandette at oracle.com Thu Feb 9 19:51:52 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 9 Feb 2017 14:51:52 -0500 Subject: Fwd: libjvm.so, jmods and --with-native-debug-symbols=internal References: <20170209174109.GC2814@redhat.com> Message-ID: <9DC3341C-30FF-4FF7-826A-8137FC4E7CA6@oracle.com> My assumption is that this was intentional. Forwarding to the jigsaw team for clarification. The native libraries associated with java.base are needed in the jmod file in order to allow developers to run jlink to produce custom Java runtimes. So, independent of having debug information, delivering a JDK with jmods provides the additional benefit of allowing custom runtimes to be produces but comes with an increased distribution cost. I suppose we could store stripped shared libraries, but this would result in a loss of information and capability when generating custom Java runtimes with jlink. Bob. > Begin forwarded message: > > From: Omair Majid > Subject: libjvm.so, jmods and --with-native-debug-symbols=internal > Date: February 9, 2017 at 12:41:09 PM EST > To: build-dev > > Hi, > > I have been working on building preview versions of OpenJDK 9 for > Fedora. You can see the latest build here: > https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/ > > One thing that I just realized is that we build OpenJDK 9 using the > configure option --with-native-debug-symbols=internal. As far as I > understand the build, this is what happens: > > 1. libjvm.so is built > 2. libjvm.so is not stripped of any debug information > 3. a jmod - java.base.jmod - containing libjvm.so is created > 4. the jmod containing libjvm.so is extracted to create images/jdk/ (and > images/jre/) > > Then the linux packaging tools (rpmbuild in my case) take over and do > the following: > > 5. strip libjvm.so in images/jdk/, put stripped symbols in a separate > location > 6. Package up images/jdk/ into the distribution package > 7. make a -debuginfo package (or -dbg in case of Debian) that contains > the stripped symbols from libjvm.so > > So now users get a libjvm.so in the default package that's stripped and > less than 20MB. They also get an optional -debuginfo (or -dbg) package > that contains just the debug symbols. This lets them use the small > package containing libjvm and but also lets them download a large > package to debug libjvm.so if they wish. This is all great so far and > works like it should. > > One new change that happened with OpenJDK 9 only is that the jmod > (java.base.jmod here) contains the original and unstripped libjvm.so. > This jmod also gets included into the images/jdk/. This bumps up the > images/jdk/jmods directory size to hundreds of megabytes. Anyone who now > wants to use jmods now ends up installing all the unstripped debuginfo, > unintentionally, eating up disk space. > > Is this intentional or an unintended side-effect of various changes? Is > it a known issue? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From erik.joelsson at oracle.com Fri Feb 10 08:25:01 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 Feb 2017 09:25:01 +0100 Subject: libjvm.so, jmods and --with-native-debug-symbols=internal In-Reply-To: <20170209174109.GC2814@redhat.com> References: <20170209174109.GC2814@redhat.com> Message-ID: <78ca8f38-26db-92a0-3b66-e359768bf1c4@oracle.com> Hello, Oracle builds with external debuginfo and handles packaging of debuginfo in the build, so we don't have this problem. For us the jmods always contain stripped binaries. I guess nobody thought of your process so this is an unfortunate side effect. I don't have any good idea on how to solve it. /Erik On 2017-02-09 18:41, Omair Majid wrote: > Hi, > > I have been working on building preview versions of OpenJDK 9 for > Fedora. You can see the latest build here: > https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/ > > One thing that I just realized is that we build OpenJDK 9 using the > configure option --with-native-debug-symbols=internal. As far as I > understand the build, this is what happens: > > 1. libjvm.so is built > 2. libjvm.so is not stripped of any debug information > 3. a jmod - java.base.jmod - containing libjvm.so is created > 4. the jmod containing libjvm.so is extracted to create images/jdk/ (and > images/jre/) > > Then the linux packaging tools (rpmbuild in my case) take over and do > the following: > > 5. strip libjvm.so in images/jdk/, put stripped symbols in a separate > location > 6. Package up images/jdk/ into the distribution package > 7. make a -debuginfo package (or -dbg in case of Debian) that contains > the stripped symbols from libjvm.so > > So now users get a libjvm.so in the default package that's stripped and > less than 20MB. They also get an optional -debuginfo (or -dbg) package > that contains just the debug symbols. This lets them use the small > package containing libjvm and but also lets them download a large > package to debug libjvm.so if they wish. This is all great so far and > works like it should. > > One new change that happened with OpenJDK 9 only is that the jmod > (java.base.jmod here) contains the original and unstripped libjvm.so. > This jmod also gets included into the images/jdk/. This bumps up the > images/jdk/jmods directory size to hundreds of megabytes. Anyone who now > wants to use jmods now ends up installing all the unstripped debuginfo, > unintentionally, eating up disk space. > > Is this intentional or an unintended side-effect of various changes? Is > it a known issue? > > Thanks, > Omair > From erik.joelsson at oracle.com Fri Feb 10 08:48:30 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 10 Feb 2017 09:48:30 +0100 Subject: jdk10 : simplify jexec build settings In-Reply-To: <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> Message-ID: Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile. /Erik On 2017-02-09 15:27, Baesken, Matthias wrote: > > I compared the jexec.c versions for macosx and unix > > ( jdk/src/java.base/macosx/native/launcher/jexec.c and > jdk/src/java.base/unix/native/launcher/jexec.c ) > > And to me it looks like the unix version could be used for macosx > too (just in case there is a need to reenable the build of jexec.c > for macosx one day again). > > Comments / suggestions ? > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Donnerstag, 9. Februar 2017 14:10 > *To:* 'Erik Joelsson' ; > build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' > > *Cc:* Langer, Christoph > *Subject:* RE: jdk10 : simplify jexec build settings > > Hello Erik, thanks for the comments . > > >>Then there is handling for macosx left , but the build is not enabled for macosx, > does it still make sense to include the macosx handling (there is even > a separate jexec.c for macosx) : > > > > > >This is indeed weird. I don't think we ever built jexec for macosx so the > source file should likely be removed. That is however a question for > core-libs I think. > > I include core-libs-dev , can someone comment on jexec on macosx ? > > Currently jexec.c is not compiled for macosx (jdk9/10), see > jdk/make/launcher/Launcher-java.base.gmk . > > It is just compiled on linux . > > So I wonder - is it ok to remove the macosx handling in the > mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for > jexec ? > > >This will automatically look in all the directories where source files are > supposed to be and pick the most specific one if there are any with > the same name. > > >Since the share launcher dir contains more src files, you will need to > leave the INCLUDE_FILES := jexec.c this time. > > From what I observe in the linux build log, just jexec.c is > compiled into jexec.o and then this single object is used to create > the executable (?program?) jexec. > > Other src files are not used in the compilation of jexec, so just > using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be > fine (as long as macosx can be dropped). > > Best regards, Matthias > > *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com] > *Sent:* Donnerstag, 9. Februar 2017 13:42 > *To:* Baesken, Matthias >; build-dev at openjdk.java.net > > *Cc:* Langer, Christoph > > *Subject:* Re: jdk10 : simplify jexec build settings > > Hello, > > On 2017-02-09 12:36, Baesken, Matthias wrote: > > Hello , while adjusting the jspawnhelper build settings with > 8174086, it has been noticed that the jexec build settings need > some simplification as well. > > The bug > > https://bugs.openjdk.java.net/browse/JDK-8174242 > > has been created for this. > > When looking into it, I had some questions : > > http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk > > The makefile (make/launcher/Launcher-java.base.gmk ) handles > Solaris 32bit, but is this really supported in jdk 9 or 10 ( I > think it was removed in 9 and only 64bit Solaris support remains ) ? > > We do not support 32bit Solaris. The issue with jexec for Solaris was > raised a while back and the conclusion was to scrap support, so no > need to build it for Solaris at all. > > ifeq ($(OPENJDK_TARGET_OS), solaris) > > ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) > > BUILD_JEXEC := 1 > > endif > > endif > > ifeq ($(OPENJDK_TARGET_OS), linux) > > BUILD_JEXEC := 1 > > endif # OPENJDK_TARGET_OS > > # > > # jdk/make/java/jexec/Makefile > > # > > ifeq ($(BUILD_JEXEC), 1) > > Then there is handling for macosx left , but the build is not > enabled for macosx, does it still make sense to include the macosx > handling (there is even a separate jexec.c for macosx) : > > This is indeed weird. I don't think we ever built jexec for macosx so > the source file should likely be removed. That is however a question > for core-libs I think. > > The makefile logic shouldn't need to be that specific though. Our > modern pattern for this is something like this: > > SRC := $(call uniq, $(wildcard \ > $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ > $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ > $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) > > This will automatically look in all the directories where source files > are supposed to be and pick the most specific one if there are any > with the same name. Since the share launcher dir contains more src > files, you will need to leave the INCLUDE_FILES := jexec.c this time. > > For libraries, we have abstracted this construct in the macro > FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for > launchers yet. > > /Erik > > ifeq ($(OPENJDK_TARGET_OS), windows) > > else ifeq ($(OPENJDK_TARGET_OS), macosx) > > BUILD_JEXEC_SRC := > $(JDK_TOPDIR)/src/java.base/macosx/native/launcher > > else > > BUILD_JEXEC_SRC := > $(JDK_TOPDIR)/src/java.base/unix/native/launcher > > endif > > Should I remove the solaris 32bit / macosx handling for jexec > from make/launcher/Launcher-java.base.gmk ? > > Regards, Matthias > From matthias.baesken at sap.com Fri Feb 10 12:18:56 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 Feb 2017 12:18:56 +0000 Subject: jdk10 : simplify jexec build settings In-Reply-To: References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> Message-ID: <420929b535234138871e47a6019d9403@DEWDFE13DE14.global.corp.sap> Hi Eric, thanks for the comment, I think I'll remove the macosx source file . Btw. is there already some test for jexec (a "fast grep" through the jdk tests did not show me much) ? Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Freitag, 10. Februar 2017 09:49 To: Baesken, Matthias ; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph Subject: Re: jdk10 : simplify jexec build settings Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile. /Erik On 2017-02-09 15:27, Baesken, Matthias wrote: I compared the jexec.c versions for macosx and unix ( jdk/src/java.base/macosx/native/launcher/jexec.c and jdk/src/java.base/unix/native/launcher/jexec.c ) And to me it looks like the unix version could be used for macosx too (just in case there is a need to reenable the build of jexec.c for macosx one day again). Comments / suggestions ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Februar 2017 14:10 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias >; build-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From magnus.ihse.bursie at oracle.com Fri Feb 10 13:50:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 10 Feb 2017 14:50:53 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <6e58d8d7-11ca-db0d-f049-8112e63974bb@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> <54390255-64d6-0e79-8f2a-114e1b7f0ebb@oracle.com> <6e58d8d7-11ca-db0d-f049-8112e63974bb@oracle.com> Message-ID: On 2017-01-30 17:20, Chris Hegarty wrote: > Thanks Erik and Magnus, > > Since this is already pushed, I propose to file a new issue to > push these cleanups. Sounds good. Please do that. /Magnus > > diff --git a/make/Javadoc.gmk b/make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -314,7 +314,7 @@ > $1_INDEX_FILE := > $$(JAVADOC_OUTPUTDIR)/$$($1_OUTPUT_DIRNAME)/index.html > > # Rule for actually running javadoc > - $$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) > $$($1_PACKAGE_DEPS) $$($1_DEPS) > + $$($1_INDEX_FILE): $$(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) > $$($1_PACKAGE_DEPS) $$($1_DEPS) > $$(call LogWarn, Generating Javadoc from $$(words > $$($1_PACKAGES)) package(s) for $$($1_OUTPUT_DIRNAME)) > $$(call MakeDir, $$(@D)) > ifneq ($$($1_PACKAGES_FILE), ) > @@ -743,7 +743,7 @@ > > > ################################################################################ > > > -docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS) > +docs-javadoc: $(TARGETS) > > docs-copy: $(COPY_TARGETS) > > > -Chris. > > On 30/01/17 11:29, Erik Joelsson wrote: >> Hello, >> >> On 2017-01-30 11:58, Chris Hegarty wrote: >>> Magnus, >>> >>> On 26/01/17 11:45, Magnus Ihse Bursie wrote: >>>> On 2017-01-25 13:51, Chris Hegarty wrote: >>>>>> On 24 Jan 2017, at 16:44, Erik Joelsson >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Build changes look good except for one thing. In Javadoc.gmk, the >>>>>> dependency on $(BUILD_TOOLS_JDK) needs to be set for >>>>>> $$($1_INDEX_FILE) (on line 317), where the actual recipes are >>>>>> created. Setting it on the phony docs-javadoc target will not help >>>>>> incremental builds. >>>>> Updated in place >>>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>>> >>>> It's not ideal that a top-level target has dependencies from the JDK >>>> repo, but since we have no or few pre-existing top-level tools, I >>>> understand if you hesitate to add a new framework for such tools. >>>> If we >>>> ever do introduce more such tools, I think we should move this along. >>> >>> Ok. >>> >>>> I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS >>>> variable. >>>> As the documentation says, the DEFAULT_JAVADOC_TAGS is there to >>>> specify >>>> the ordering of tags in the output. Unless the -taglet options >>>> implicitly generates one or more -tag options in it's place, >>> >>> It's an inline tag, so by definition has no order. >>> >>>> that's the >>>> wrong place to put it. If it does, perhaps a comment indicating this >>>> hidden behavior would be in place. >>> >>> It seemed best to keep all tag related options together, >>> rather then spreading them across multiple variables. >>> >>>> In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) >>>> $$($1_VARDEPS_FILE) >>>> $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all >>>> variables. While technically not necessary in this particular case, >>>> it's >>>> misleading >>> >>> How so? >>> >>>> and we've had our share of bugs due to single $ in eval'd macros. >>> >>> Will this specific variable cause a problem, if so how? >>> >> No, this variable will not cause a problem, but we have sort of agreed >> (though I have been a bit slack about it) to be consistent with all >> variable references inside macro bodies that will be eval'd. The trouble >> starts if the value of such a variable contains something that make has >> a special interpretation for, like a ':' or a ',' or a '$'. Then the >> eval will re-interpret those and weird, very hard to debug errors, start >> appearing. >>>> In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please >>>> remove the reference to BUILD_TOOLS_JDK. It is not needed. >>> >>> Why is this not needed. >>> >> So we have these targets: >> >> * docs-javadoc, which is a named phony target which we use as part of >> the external API for the Javadoc.gmk makefile. >> * For each call to the SetupJavadoc macro, we have $$($1_INDEX_FILE) >> (which evaluates to something like >> build/linux-x64/images/docs/api/index.html). This is a specific file >> being generated by a recipe. All of these are added to the TARGETS >> variable through which all of them are set as prerequisites to >> docs-javadoc. >> * The targets in $(BUILD_TOOLS_JDK) represents the files generated by >> building the tools. We add these files as prerequisites to each of the >> index files so that if the build tool has changed, the javadoc will get >> regenerated. This is what we want to achieve for proper incremental >> behavior. >> >> Building the tools has no inherent value in itself, as they are not part >> of the product, they are only needed to generate proper javadocs. As >> such, it is conceptually wrong (as well as redundant) to also add the >> tools as prerequisites to the docs-javadoc target, because this target >> symbolizes building all the javadoc. Each of those javadoc runs do >> require the tools however, so each of those javadoc runs need to have >> the tools as prerequisites. >> >> I had missed that you didn't remove that change in your updated >> review btw. >> >> /Erik >> >>> -Chris. >>> >>>> /Magnus >>>> >>>> >>>>> >>>>> -Chris. >>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2017-01-24 15:08, Chris Hegarty wrote: >>>>>>> As per the guidance in JEP 11 [1], the javadoc for types in >>>>>>> incubator modules should have a clear and explicit warning >>>>>>> notice. To that end, I?ve added a simple inline taglet that can >>>>>>> be used to effectively inject a standard notice, and applied it >>>>>>> to all public types in the HTTP module ( I?ll cleanup the line >>>>>>> width formatting before pushing ). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> P.S. this work is, somewhat, in preparation for when we move >>>>>>> to a single documentation bundle [2]. >>>>>>> >>>>>>> [1] http://openjdk.java.net/jeps/11 >>>>>>> [2] http://openjdk.java.net/jeps/299 >>>> >> From joe.darcy at oracle.com Mon Feb 13 20:04:37 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 13 Feb 2017 12:04:37 -0800 Subject: JDK 9 RFR Enable doclint reference checking for the java.compiler module Message-ID: Hello, Please review the small patch below to enable the "reference" category of doclint checking (@see and @link tags, etc.) for the java.compiler module which hosts the packages javax.lang.model.*, javax.annotation.processing, and javax.tools. Thanks, -Joe diff -r 4eb77fb98952 make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk Fri Feb 10 08:21:20 2017 -0800 +++ b/make/CompileJavaModules.gmk Mon Feb 13 12:02:21 2017 -0800 @@ -85,7 +85,7 @@ ################################################################################ -java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:java.*,javax.*' ################################################################################ From bob.vandette at oracle.com Mon Feb 13 20:30:49 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 13 Feb 2017 15:30:49 -0500 Subject: FR: 8174203: Enable AOT Jtreg tests on Windows x86_64 Message-ID: <46F1628D-B824-42E1-812D-F4A517959CC3@oracle.com> Please review this change for JDK 10, that enables jtreg testing of Hotspot AOT support on Windows. This change also includes some fixes that allow JPRT to be able to run these tests. Thanks to Erik Joelsson for providing the JPRT support. CR: https://bugs.openjdk.java.net/browse/JDK-8174203 WEBREV: http://cr.openjdk.java.net/~bobv/8174203/webrev http://cr.openjdk.java.net/~bobv/8174203/hotspot/webrev Bob. From vladimir.kozlov at oracle.com Mon Feb 13 21:41:45 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Feb 2017 13:41:45 -0800 Subject: FR: 8174203: Enable AOT Jtreg tests on Windows x86_64 In-Reply-To: <46F1628D-B824-42E1-812D-F4A517959CC3@oracle.com> References: <46F1628D-B824-42E1-812D-F4A517959CC3@oracle.com> Message-ID: Hotspot changes are good. Thanks, Vladimir On 2/13/17 12:30 PM, Bob Vandette wrote: > Please review this change for JDK 10, that enables jtreg testing of Hotspot AOT support on Windows. > > This change also includes some fixes that allow JPRT to be able to run these tests. > Thanks to Erik Joelsson for providing the JPRT support. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8174203 > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8174203/webrev > http://cr.openjdk.java.net/~bobv/8174203/hotspot/webrev > > > Bob. > From erik.joelsson at oracle.com Tue Feb 14 08:14:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Feb 2017 09:14:13 +0100 Subject: JDK 9 RFR Enable doclint reference checking for the java.compiler module In-Reply-To: References: Message-ID: <3136fb32-d3b7-cd55-d5fc-388995135897@oracle.com> Looks good. /Erik On 2017-02-13 21:04, joe darcy wrote: > Hello, > > Please review the small patch below to enable the "reference" category > of doclint checking (@see and @link tags, etc.) for the java.compiler > module which hosts the packages javax.lang.model.*, > javax.annotation.processing, and javax.tools. > > Thanks, > > -Joe > > diff -r 4eb77fb98952 make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Fri Feb 10 08:21:20 2017 -0800 > +++ b/make/CompileJavaModules.gmk Mon Feb 13 12:02:21 2017 -0800 > @@ -85,7 +85,7 @@ > > ################################################################################ > > > -java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference > '-Xdoclint/package:java.*,javax.*' > +java.compiler_ADD_JAVAC_FLAGS := -Xdoclint:all/protected > '-Xdoclint/package:java.*,javax.*' > > ################################################################################ > > > From erik.joelsson at oracle.com Tue Feb 14 08:15:25 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Feb 2017 09:15:25 +0100 Subject: FR: 8174203: Enable AOT Jtreg tests on Windows x86_64 In-Reply-To: <46F1628D-B824-42E1-812D-F4A517959CC3@oracle.com> References: <46F1628D-B824-42E1-812D-F4A517959CC3@oracle.com> Message-ID: <01ff32d1-21fa-91f1-8dd4-30653c71e285@oracle.com> Looks good to me. /Erik On 2017-02-13 21:30, Bob Vandette wrote: > Please review this change for JDK 10, that enables jtreg testing of Hotspot AOT support on Windows. > > This change also includes some fixes that allow JPRT to be able to run these tests. > Thanks to Erik Joelsson for providing the JPRT support. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8174203 > > WEBREV: > > http://cr.openjdk.java.net/~bobv/8174203/webrev > http://cr.openjdk.java.net/~bobv/8174203/hotspot/webrev > > > Bob. From erik.joelsson at oracle.com Tue Feb 14 08:42:07 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Feb 2017 09:42:07 +0100 Subject: RFR: JDK-8174895: test/TestCommon.gmk: value of JTREG_TESTVM_MEMORY_OPTION is missing1/2acghpy Message-ID: There is a small bug in the new test/TestCommon.gmk that prevents the JTREG_TESTVM_MEMORY_OPTION from propagating to the jtreg command line. The fix is to append to JTREG_TEST_OPTIONS instead of overwriting the current value further down in the file. Patch provided by Amy Lu. Bug: https://bugs.openjdk.java.net/browse/JDK-8174895 Patch: diff -r 4eb77fb98952 test/TestCommon.gmk --- a/test/TestCommon.gmk +++ b/test/TestCommon.gmk @@ -370,7 +370,7 @@ # Give tests access to JT_JAVA, see JDK-8141609 JTREG_BASIC_OPTIONS += -e:JDK8_HOME=${JT_JAVA} # Set other vm and test options -JTREG_TEST_OPTIONS = $(JAVA_ARGS:%=-javaoptions:%) $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) +JTREG_TEST_OPTIONS += $(JAVA_ARGS:%=-javaoptions:%) $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) ifeq ($(IGNORE_MARKED_TESTS), true) # Option to tell jtreg to not run tests marked with "ignore" /Erik From david.holmes at oracle.com Tue Feb 14 08:53:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Feb 2017 18:53:05 +1000 Subject: RFR: JDK-8174895: test/TestCommon.gmk: value of JTREG_TESTVM_MEMORY_OPTION is missing1/2acghpy In-Reply-To: References: Message-ID: <82c15012-713d-3f91-6cee-3fcadf667a7a@oracle.com> Looks good! Thanks, David On 14/02/2017 6:42 PM, Erik Joelsson wrote: > There is a small bug in the new test/TestCommon.gmk that prevents the > JTREG_TESTVM_MEMORY_OPTION from propagating to the jtreg command line. > The fix is to append to JTREG_TEST_OPTIONS instead of overwriting the > current value further down in the file. Patch provided by Amy Lu. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174895 > > Patch: > > diff -r 4eb77fb98952 test/TestCommon.gmk > --- a/test/TestCommon.gmk > +++ b/test/TestCommon.gmk > @@ -370,7 +370,7 @@ > # Give tests access to JT_JAVA, see JDK-8141609 > JTREG_BASIC_OPTIONS += -e:JDK8_HOME=${JT_JAVA} > # Set other vm and test options > -JTREG_TEST_OPTIONS = $(JAVA_ARGS:%=-javaoptions:%) > $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) > +JTREG_TEST_OPTIONS += $(JAVA_ARGS:%=-javaoptions:%) > $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) > > ifeq ($(IGNORE_MARKED_TESTS), true) > # Option to tell jtreg to not run tests marked with "ignore" > > > /Erik > From matthias.baesken at sap.com Tue Feb 14 16:27:49 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 14 Feb 2017 16:27:49 +0000 Subject: jdk10 : simplify jexec build settings References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> Message-ID: <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap> Hello, here is the webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/ bug : https://bugs.openjdk.java.net/browse/JDK-8174242 As discussed , I deleted the macosx jexec.c . Btw. I found out that jexec does not work (fully?) in jdk8 / 9 ( seems this has to do with the change 8156478: 3 Buffer overrun defect groups in jexec.c ) Executing a helloworld.jar with jexec leads to "invalid file (bad magic number): Exec format error" . Should I open another bug for this ? Best regards, Matthias From: Baesken, Matthias Sent: Freitag, 10. Februar 2017 13:19 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hi Eric, thanks for the comment, I think I'll remove the macosx source file . Btw. is there already some test for jexec (a "fast grep" through the jdk tests did not show me much) ? Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Freitag, 10. Februar 2017 09:49 To: Baesken, Matthias >; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile. /Erik On 2017-02-09 15:27, Baesken, Matthias wrote: I compared the jexec.c versions for macosx and unix ( jdk/src/java.base/macosx/native/launcher/jexec.c and jdk/src/java.base/unix/native/launcher/jexec.c ) And to me it looks like the unix version could be used for macosx too (just in case there is a need to reenable the build of jexec.c for macosx one day again). Comments / suggestions ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Februar 2017 14:10 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias >; build-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From erik.joelsson at oracle.com Tue Feb 14 16:57:02 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Feb 2017 17:57:02 +0100 Subject: jdk10 : simplify jexec build settings In-Reply-To: <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap> References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap> Message-ID: <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com> Hello, Looks good to me. Fixing jexec is a separate issue and not really build related. /Erik On 2017-02-14 17:27, Baesken, Matthias wrote: > > Hello, here is the webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/ > > > bug : > > https://bugs.openjdk.java.net/browse/JDK-8174242 > > As discussed , I deleted the macosx jexec.c . > > Btw. I found out that jexec does not work (fully?) in jdk8 / 9 > ( seems this has to do with the change 8156478: 3 Buffer overrun > defect groups in jexec.c ) > > Executing a helloworld.jar with jexec leads to > > ?invalid file (bad magic number): Exec format error? . > > Should I open another bug for this ? > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Freitag, 10. Februar 2017 13:19 > *To:* 'Erik Joelsson' ; > build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > *Cc:* Langer, Christoph > *Subject:* RE: jdk10 : simplify jexec build settings > > Hi Eric, thanks for the comment, I think I?ll remove the macosx source > file . > > Btw. is there already some test for jexec (a ?fast grep? through the > jdk tests did not show me much) ? > > Best regards, Matthias > > *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com] > *Sent:* Freitag, 10. Februar 2017 09:49 > *To:* Baesken, Matthias >; build-dev at openjdk.java.net > ; core-libs-dev at openjdk.java.net > > *Cc:* Langer, Christoph > > *Subject:* Re: jdk10 : simplify jexec build settings > > Since the file has never been built, I would say remove the macosx > source file. You can point directly to the unix source dir if you > prefer too. No need to have dead logic for macosx in the makefile. > > /Erik > > On 2017-02-09 15:27, Baesken, Matthias wrote: > > I compared the jexec.c versions for macosx and unix > > ( jdk/src/java.base/macosx/native/launcher/jexec.c and > jdk/src/java.base/unix/native/launcher/jexec.c ) > > And to me it looks like the unix version could be used for > macosx too (just in case there is a need to reenable the build > of jexec.c for macosx one day again). > > Comments / suggestions ? > > Best regards, Matthias > > *From:*Baesken, Matthias > *Sent:* Donnerstag, 9. Februar 2017 14:10 > *To:* 'Erik Joelsson' > ; build-dev at openjdk.java.net > ; > 'core-libs-dev at openjdk.java.net > ' > > > *Cc:* Langer, Christoph > > *Subject:* RE: jdk10 : simplify jexec build settings > > Hello Erik, thanks for the comments . > > >>Then there is handling for macosx left , but the build is not enabled > for macosx, does it still make sense to include the macosx > handling (there is even a separate jexec.c for macosx) : > > > > > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely > be removed. That is however a question for core-libs I think. > > I include core-libs-dev , can someone comment on jexec on macosx ? > > Currently jexec.c is not compiled for macosx (jdk9/10), see > jdk/make/launcher/Launcher-java.base.gmk . > > It is just compiled on linux . > > So I wonder - is it ok to remove the macosx handling in the > mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for > jexec ? > > >This will automatically look in all the directories where source files are supposed to be and pick > the most specific one if there are any with the same name. > > >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES > := jexec.c this time. > > From what I observe in the linux build log, just jexec.c is > compiled into jexec.o and then this single object is used to > create the executable (?program?) jexec. > > Other src files are not used in the compilation of jexec, so just > using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be > fine (as long as macosx can be dropped). > > Best regards, Matthias > > *From:*Erik Joelsson [mailto:erik.joelsson at oracle.com] > *Sent:* Donnerstag, 9. Februar 2017 13:42 > *To:* Baesken, Matthias >; build-dev at openjdk.java.net > > *Cc:* Langer, Christoph > > *Subject:* Re: jdk10 : simplify jexec build settings > > Hello, > > On 2017-02-09 12:36, Baesken, Matthias wrote: > > Hello , while adjusting the jspawnhelper build settings with > 8174086, it has been noticed that the jexec build settings > need some simplification as well. > > The bug > > https://bugs.openjdk.java.net/browse/JDK-8174242 > > has been created for this. > > When looking into it, I had some questions : > > http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk > > The makefile (make/launcher/Launcher-java.base.gmk ) handles > Solaris 32bit, but is this really supported in jdk 9 or 10 > ( I think it was removed in 9 and only 64bit Solaris support > remains ) ? > > We do not support 32bit Solaris. The issue with jexec for Solaris > was raised a while back and the conclusion was to scrap support, > so no need to build it for Solaris at all. > > ifeq ($(OPENJDK_TARGET_OS), solaris) > > ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) > > BUILD_JEXEC := 1 > > endif > > endif > > ifeq ($(OPENJDK_TARGET_OS), linux) > > BUILD_JEXEC := 1 > > endif # OPENJDK_TARGET_OS > > # > > # jdk/make/java/jexec/Makefile > > # > > ifeq ($(BUILD_JEXEC), 1) > > Then there is handling for macosx left , but the build is not > enabled for macosx, does it still make sense to include the > macosx handling (there is even a separate jexec.c for macosx) : > > This is indeed weird. I don't think we ever built jexec for macosx > so the source file should likely be removed. That is however a > question for core-libs I think. > > The makefile logic shouldn't need to be that specific though. Our > modern pattern for this is something like this: > > SRC := $(call uniq, $(wildcard \ > $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ > $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher > \ > $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) > > This will automatically look in all the directories where source > files are supposed to be and pick the most specific one if there > are any with the same name. Since the share launcher dir contains > more src files, you will need to leave the INCLUDE_FILES := > jexec.c this time. > > For libraries, we have abstracted this construct in the macro > FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for > launchers yet. > > /Erik > > ifeq ($(OPENJDK_TARGET_OS), windows) > > else ifeq ($(OPENJDK_TARGET_OS), macosx) > > BUILD_JEXEC_SRC := > $(JDK_TOPDIR)/src/java.base/macosx/native/launcher > > else > > BUILD_JEXEC_SRC := > $(JDK_TOPDIR)/src/java.base/unix/native/launcher > > endif > > Should I remove the solaris 32bit / macosx handling for > jexec from make/launcher/Launcher-java.base.gmk ? > > Regards, Matthias > From joe.darcy at oracle.com Wed Feb 15 01:27:52 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 14 Feb 2017 17:27:52 -0800 Subject: JDK 9 RFR Enable doclint reference checking for the java.management.rmi module Message-ID: <8ea6ccf5-59b4-78b0-3b72-ac2d384e39f0@oracle.com> Hello, As a follow-up to enabling doclint reference checking in the java.compiler modules (JDK-8174945), I checked the other modules where reference checking is currently disabled and found one where the check could be turned on: java.management.rmi. Please review the patch below which does this. Thanks, -Joe diff -r 04a685edd41d make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk Tue Feb 14 09:00:43 2017 -0800 +++ b/make/CompileJavaModules.gmk Tue Feb 14 17:24:04 2017 -0800 @@ -247,7 +247,7 @@ ################################################################################ -java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:javax.*' +java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:javax.*' ################################################################################ From Lance.Andersen at oracle.com Wed Feb 15 01:54:55 2017 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Tue, 14 Feb 2017 20:54:55 -0500 Subject: JDK 9 RFR Enable doclint reference checking for the java.management.rmi module In-Reply-To: <8ea6ccf5-59b4-78b0-3b72-ac2d384e39f0@oracle.com> References: <8ea6ccf5-59b4-78b0-3b72-ac2d384e39f0@oracle.com> Message-ID: +1 -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPhone > On Feb 14, 2017, at 8:27 PM, joe darcy wrote: > > Hello, > > As a follow-up to enabling doclint reference checking in the java.compiler modules (JDK-8174945), I checked the other modules where reference checking is currently disabled and found one where the check could be turned on: java.management.rmi. > > Please review the patch below which does this. > > Thanks, > > -Joe > > diff -r 04a685edd41d make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Tue Feb 14 09:00:43 2017 -0800 > +++ b/make/CompileJavaModules.gmk Tue Feb 14 17:24:04 2017 -0800 > @@ -247,7 +247,7 @@ > > ################################################################################ > > -java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:javax.*' > +java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:javax.*' > > ################################################################################ > > From mandy.chung at oracle.com Wed Feb 15 02:20:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Feb 2017 18:20:10 -0800 Subject: JDK 9 RFR Enable doclint reference checking for the java.management.rmi module In-Reply-To: <8ea6ccf5-59b4-78b0-3b72-ac2d384e39f0@oracle.com> References: <8ea6ccf5-59b4-78b0-3b72-ac2d384e39f0@oracle.com> Message-ID: <081EFC17-D0A7-4FF5-B943-042F3C3CDFB6@oracle.com> +1 Mandy > On Feb 14, 2017, at 5:27 PM, joe darcy wrote: > > Hello, > > As a follow-up to enabling doclint reference checking in the java.compiler modules (JDK-8174945), I checked the other modules where reference checking is currently disabled and found one where the check could be turned on: java.management.rmi. > > Please review the patch below which does this. > > Thanks, > > -Joe > > diff -r 04a685edd41d make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk Tue Feb 14 09:00:43 2017 -0800 > +++ b/make/CompileJavaModules.gmk Tue Feb 14 17:24:04 2017 -0800 > @@ -247,7 +247,7 @@ > > ################################################################################ > > -java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference '-Xdoclint/package:javax.*' > +java.management.rmi_ADD_JAVAC_FLAGS := -Xdoclint:all/protected '-Xdoclint/package:javax.*' > > ################################################################################ > > From matthias.baesken at sap.com Wed Feb 15 08:37:28 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 15 Feb 2017 08:37:28 +0000 Subject: jdk10 : simplify jexec build settings In-Reply-To: <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com> References: <92a51f307d33465faca64e8d43c176bc@DEWDFE13DE14.global.corp.sap> <20161b2fc66242b6930e179f0bbdf121@DEWDFE13DE14.global.corp.sap> <13388daa72314ad6869c4235b71de083@DEWDFE13DE14.global.corp.sap> <026d9dec-a64a-bd98-d95f-7cce061819f5@oracle.com> Message-ID: ? Fixing jexec is a separate issue and not really build related. Yes that's true, I created a separate bug for this : https://bugs.openjdk.java.net/browse/JDK-8175000 Regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Dienstag, 14. Februar 2017 17:57 To: Baesken, Matthias ; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph ; Simonis, Volker Subject: Re: jdk10 : simplify jexec build settings Hello, Looks good to me. Fixing jexec is a separate issue and not really build related. /Erik On 2017-02-14 17:27, Baesken, Matthias wrote: Hello, here is the webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8174242/ bug : https://bugs.openjdk.java.net/browse/JDK-8174242 As discussed , I deleted the macosx jexec.c . Btw. I found out that jexec does not work (fully?) in jdk8 / 9 ( seems this has to do with the change 8156478: 3 Buffer overrun defect groups in jexec.c ) Executing a helloworld.jar with jexec leads to "invalid file (bad magic number): Exec format error" . Should I open another bug for this ? Best regards, Matthias From: Baesken, Matthias Sent: Freitag, 10. Februar 2017 13:19 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hi Eric, thanks for the comment, I think I'll remove the macosx source file . Btw. is there already some test for jexec (a "fast grep" through the jdk tests did not show me much) ? Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Freitag, 10. Februar 2017 09:49 To: Baesken, Matthias >; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Since the file has never been built, I would say remove the macosx source file. You can point directly to the unix source dir if you prefer too. No need to have dead logic for macosx in the makefile. /Erik On 2017-02-09 15:27, Baesken, Matthias wrote: I compared the jexec.c versions for macosx and unix ( jdk/src/java.base/macosx/native/launcher/jexec.c and jdk/src/java.base/unix/native/launcher/jexec.c ) And to me it looks like the unix version could be used for macosx too (just in case there is a need to reenable the build of jexec.c for macosx one day again). Comments / suggestions ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 9. Februar 2017 14:10 To: 'Erik Joelsson' ; build-dev at openjdk.java.net; 'core-libs-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RE: jdk10 : simplify jexec build settings Hello Erik, thanks for the comments . >>Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : > >This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. I include core-libs-dev , can someone comment on jexec on macosx ? Currently jexec.c is not compiled for macosx (jdk9/10), see jdk/make/launcher/Launcher-java.base.gmk . It is just compiled on linux . So I wonder - is it ok to remove the macosx handling in the mentioned makefile jdk/make/launcher/Launcher-java.base.gmk for jexec ? >This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. >Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. >From what I observe in the linux build log, just jexec.c is compiled into jexec.o and then this single object is used to create the executable ("program") jexec. Other src files are not used in the compilation of jexec, so just using $(JDK_TOPDIR)/src/$(MODULE)/unix/native/launcher would be fine (as long as macosx can be dropped). Best regards, Matthias From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: Donnerstag, 9. Februar 2017 13:42 To: Baesken, Matthias >; build-dev at openjdk.java.net Cc: Langer, Christoph > Subject: Re: jdk10 : simplify jexec build settings Hello, On 2017-02-09 12:36, Baesken, Matthias wrote: Hello , while adjusting the jspawnhelper build settings with 8174086, it has been noticed that the jexec build settings need some simplification as well. The bug https://bugs.openjdk.java.net/browse/JDK-8174242 has been created for this. When looking into it, I had some questions : http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/ae7afa9abe67/make/launcher/Launcher-java.base.gmk The makefile (make/launcher/Launcher-java.base.gmk ) handles Solaris 32bit, but is this really supported in jdk 9 or 10 ( I think it was removed in 9 and only 64bit Solaris support remains ) ? We do not support 32bit Solaris. The issue with jexec for Solaris was raised a while back and the conclusion was to scrap support, so no need to build it for Solaris at all. ifeq ($(OPENJDK_TARGET_OS), solaris) ifeq ($(OPENJDK_TARGET_CPU_BITS), 32) BUILD_JEXEC := 1 endif endif ifeq ($(OPENJDK_TARGET_OS), linux) BUILD_JEXEC := 1 endif # OPENJDK_TARGET_OS # # jdk/make/java/jexec/Makefile # ifeq ($(BUILD_JEXEC), 1) Then there is handling for macosx left , but the build is not enabled for macosx, does it still make sense to include the macosx handling (there is even a separate jexec.c for macosx) : This is indeed weird. I don't think we ever built jexec for macosx so the source file should likely be removed. That is however a question for core-libs I think. The makefile logic shouldn't need to be that specific though. Our modern pattern for this is something like this: SRC := $(call uniq, $(wildcard \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/$(OPENJDK_TARGET_OS_TYPE)/native/launcher \ $(JDK_TOPDIR)/src/$(MODULE)/share/native/launcher)) This will automatically look in all the directories where source files are supposed to be and pick the most specific one if there are any with the same name. Since the share launcher dir contains more src files, you will need to leave the INCLUDE_FILES := jexec.c this time. For libraries, we have abstracted this construct in the macro FindSrcDirForLib (LibCommon.gmk) but we haven't done the same for launchers yet. /Erik ifeq ($(OPENJDK_TARGET_OS), windows) else ifeq ($(OPENJDK_TARGET_OS), macosx) BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/macosx/native/launcher else BUILD_JEXEC_SRC := $(JDK_TOPDIR)/src/java.base/unix/native/launcher endif Should I remove the solaris 32bit / macosx handling for jexec from make/launcher/Launcher-java.base.gmk ? Regards, Matthias From claes.redestad at oracle.com Wed Feb 15 17:12:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 15 Feb 2017 18:12:01 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes Message-ID: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Hi, currently the file we generate at build time as input to --generate-jli-classes is lost when linking custom images, which means user generate images may perform worse in certain ways, mostly generating more classes during startup. Additionally, there's a strong assumption in --generate-jli-classes that the VM running jlink is going to generate compatible classes with the image being linked, which we can only really guarantee if the java.base in the linked image is of the same version as the java.base in the VM running jlink. This patch tightens these checks to ensure we have freedom to evolve and re-evaluate the implementation in future releases. JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8175026 Thanks! /Claes From mandy.chung at oracle.com Wed Feb 15 19:09:36 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 11:09:36 -0800 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: > On Feb 15, 2017, at 9:12 AM, Claes Redestad wrote: > > Hi, > > currently the file we generate at build time as input to > --generate-jli-classes is lost when linking custom images, which means > user generate images may perform worse in certain ways, mostly > generating more classes during startup. > > Additionally, there's a strong assumption in --generate-jli-classes that > the VM running jlink is going to generate compatible classes with the > image being linked, which we can only really guarantee if the java.base > in the linked image is of the same version as the java.base in the VM > running jlink. This patch tightens these checks to ensure we have > freedom to evolve and re-evaluate the implementation in future > releases. > > JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ > Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ This restriction sounds reasonable and we can enhance this in a future release. I think the plugin can record the configuration in its own format to be independent of the trace output format. Instead of throwing ISA, you can have a test method to return a boolean to indicate if the default trace file should be read. Instead of running java.base from the runtime, you can use Runtime.version() instead and I think comparing Version::major should be adequate. This change disables this default setting entirely if the image being created is not the same version as this plugin (defaultSpecies and defaultInvokers, etc). Is it intended? In addition, if the main argument is specified but the version does not match, it will ignore the given argument. Should it be an error instead? We are the one who will generate a trace file and specify it in the jlink plugin option. It?s okay to ignore the default trace output if no plugin option is specified and I think no warning should be printed in this case. It?s just like this plugin is disabled. You may want to add a suboption to turn on verbose that will trace what is generated and what is ignored. Mandy From cthalinger at twitter.com Wed Feb 15 22:04:32 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Wed, 15 Feb 2017 12:04:32 -1000 Subject: RFR: JDK-8172670: AOT Platform Support for Windows and Mac OS X x64 (Linux and Solaris too) In-Reply-To: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> References: <12F3770E-F647-4905-B3E9-8CE5EFA48D87@oracle.com> Message-ID: <61DE8944-4A5F-4D0C-A7B0-F26DC86EB2CA@twitter.com> This is amazing! Awesome work. I?m glad this got done so soon. > On Feb 8, 2017, at 9:29 AM, Bob Vandette wrote: > > SUMMARY: > > Please review the following set of changes that adds Ahead-of-time compilation support for Mac OSX and > Windows x64 in JDK 10. Linux and Solaris x64 AOT support has also been updated to be consistent with > the new 100% Java based binary container support included in this changeset. > > This change also removes the build and runtime dependency on the external libelf library and header files. > > Once this change is integrated Ahead of time support will be available for the following set of Platforms: > > - Linux x64 > - Windows x64 > - MacOSX x64 > - Solaris x64 > > RFE: > > https://bugs.openjdk.java.net/browse/JDK-8172670 > > WEBREVS: > > TOP LEVEL > ????? > > http://cr.openjdk.java.net/~bobv/8172670/webrev.01/ > > JDK > ?? > > http://cr.openjdk.java.net/~bobv/8172670/jdk/webrev.01/ > > HOTSPOT > ????? > > Full Hotspot Webrev: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev.01/ > > > If you?d prefer to review things in smaller chunks, here are the hotspot changes for Linux and > Solaris including the libelf removal: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-linux.01/ > > Files added to support Mac OSX: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-mac.01/ > > Files added to provide Windows support: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-win.01/ > > Changes to the jtreg tests for AOT: > http://cr.openjdk.java.net/~bobv/8172670/hotspot/webrev-test.01/ > > > TESTING: > > 1. JPRT has been run and passes with these changes > 2. jtreg AOT tests pass on all supported platforms > 3. AOT compiling of java.base completes and can run basic Java programs on all supported platforms > > NOTE: > > 1. Although these test run correctly on Windows, jtreg AOT tests have been temporarily disabled for this platform. > This is due to an internal JPRT system configuration issue which will hopefully get resolved soon. AOT requires > access to a local toolchain and our JPRT systems do not regularly install Visual Studio. > > > Thanks, > Bob. From vladimir.kozlov at oracle.com Thu Feb 16 01:37:15 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 17:37:15 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci Message-ID: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8174879 jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. Webrevs: top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Tested with RBT. Thanks, Vladimir From mandy.chung at oracle.com Thu Feb 16 04:35:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2017 20:35:32 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> > On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ The change looks fine to me. Mandy From vladimir.kozlov at oracle.com Thu Feb 16 06:09:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Feb 2017 22:09:36 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <1A3EDC42-9BFD-46E1-B8B7-04A6A781F891@oracle.com> Message-ID: <61ca272f-419b-902e-50ff-f7536f060cb7@oracle.com> Thank you, Mandy Vladimir On 2/15/17 8:35 PM, Mandy Chung wrote: > >> On Feb 15, 2017, at 5:37 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > The change looks fine to me. > > Mandy > From magnus.ihse.bursie at oracle.com Thu Feb 16 07:54:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 08:54:53 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> Message-ID: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> On 2017-02-16 02:37, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8174879 > > jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is > only of interest to VM developers (and researchers), not general Java > developers. It'd be appropriate for it to be an internal module and > not to export any API. > > Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and > jdk.internal.vm.compiler. No packages renaming. > Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. > > Webrevs: > > top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ > jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ > hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ Looks good to me. /Magnus > > Tested with RBT. > > Thanks, > Vladimir From magnus.ihse.bursie at oracle.com Thu Feb 16 07:56:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 08:56:23 +0100 Subject: RFR: JDK-8174895: test/TestCommon.gmk: value of JTREG_TESTVM_MEMORY_OPTION is missing1/2acghpy In-Reply-To: References: Message-ID: <3e9c544f-1231-6ac6-4c69-18ab161b7bf8@oracle.com> On 2017-02-14 09:42, Erik Joelsson wrote: > There is a small bug in the new test/TestCommon.gmk that prevents the > JTREG_TESTVM_MEMORY_OPTION from propagating to the jtreg command line. > The fix is to append to JTREG_TEST_OPTIONS instead of overwriting the > current value further down in the file. Patch provided by Amy Lu. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8174895 > > Patch: > Looks good to me. /Magnus > diff -r 4eb77fb98952 test/TestCommon.gmk > --- a/test/TestCommon.gmk > +++ b/test/TestCommon.gmk > @@ -370,7 +370,7 @@ > # Give tests access to JT_JAVA, see JDK-8141609 > JTREG_BASIC_OPTIONS += -e:JDK8_HOME=${JT_JAVA} > # Set other vm and test options > -JTREG_TEST_OPTIONS = $(JAVA_ARGS:%=-javaoptions:%) > $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) > +JTREG_TEST_OPTIONS += $(JAVA_ARGS:%=-javaoptions:%) > $(JAVA_OPTIONS:%=-vmoption:%) $(JAVA_VM_ARGS:%=-vmoption:%) > > ifeq ($(IGNORE_MARKED_TESTS), true) > # Option to tell jtreg to not run tests marked with "ignore" > > > /Erik > From magnus.ihse.bursie at oracle.com Thu Feb 16 08:01:06 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Feb 2017 09:01:06 +0100 Subject: RFR: 8175026: Capture build-time parameters to --generate-jli-classes In-Reply-To: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> References: <7c594b2c-a89c-8715-e65d-9442cf6005a7@oracle.com> Message-ID: <498526b6-79bb-ca0d-cb7f-536f4360a7a4@oracle.com> On 2017-02-15 18:12, Claes Redestad wrote: > Hi, > > currently the file we generate at build time as input to > --generate-jli-classes is lost when linking custom images, which means > user generate images may perform worse in certain ways, mostly > generating more classes during startup. > > Additionally, there's a strong assumption in --generate-jli-classes that > the VM running jlink is going to generate compatible classes with the > image being linked, which we can only really guarantee if the java.base > in the linked image is of the same version as the java.base in the VM > running jlink. This patch tightens these checks to ensure we have > freedom to evolve and re-evaluate the implementation in future > releases. > > JDK: http://cr.openjdk.java.net/~redestad/8175026/jdk.01/ > Top: http://cr.openjdk.java.net/~redestad/8175026/top.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8175026 > > Thanks! Build changes look good. /Magnus From doug.simon at oracle.com Thu Feb 16 10:01:19 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 11:01:19 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. -Doug > On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: > > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Feb 16 18:24:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:24:52 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> Message-ID: <678ae64e-aae8-74d3-c382-e47b17005be6@oracle.com> Thank you, Magnus Vladimir On 2/15/17 11:54 PM, Magnus Ihse Bursie wrote: > On 2017-02-16 02:37, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8174879 >> >> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and >> researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >> >> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >> >> Webrevs: >> >> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ > > Looks good to me. > > /Magnus >> >> Tested with RBT. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Thu Feb 16 18:30:59 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2017 10:30:59 -0800 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> Message-ID: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Hi Doug, Is it because of next change?: module jdk.internal.vm.ci { - exports jdk.vm.ci.services; + exports jdk.vm.ci.services to jdk.internal.vm.compiler; But you said before that your version of graal has the same module name. Why you need --add-exports? Thanks, Vladimir On 2/16/17 2:01 AM, Doug Simon wrote: > Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. > > -Doug > >> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >> >> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>> >>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>> >>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>> >>> Webrevs: >>> >>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >> >> Looks good to me. >> >> /Magnus >>> >>> Tested with RBT. >>> >>> Thanks, >>> Vladimir >> > From doug.simon at oracle.com Thu Feb 16 18:57:14 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 16 Feb 2017 19:57:14 +0100 Subject: [9] RFR[L] 8174879: Rename jdk.vm.ci to jdk.internal.vm.ci In-Reply-To: <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> References: <9556c515-1e91-fd0a-06d5-50ca7281d7c5@oracle.com> <913fdf9f-7b21-bd40-96ee-20b45afb78a9@oracle.com> <0C1A8698-0F78-4D10-ABA3-B2BEB3D666A7@oracle.com> <73ae8fc4-2641-eb1e-e1d7-34738801648f@oracle.com> Message-ID: <9B8A67FE-A748-4599-B9BC-A6D1BBF3F576@oracle.com> > On 16 Feb 2017, at 19:30, Vladimir Kozlov wrote: > > Hi Doug, > > Is it because of next change?: > > module jdk.internal.vm.ci { > - exports jdk.vm.ci.services; > + exports jdk.vm.ci.services to jdk.internal.vm.compiler; > > But you said before that your version of graal has the same module name. Why you need --add-exports? I am projecting ahead to the bug fix Mandy talks about in http://mail.openjdk.java.net/pipermail/graal-dev/2017-February/004889.html which means patching in an external version of Graal will no longer benefit from the qualified exports of JVMCI to jdk.vm.compiler. -Doug > On 2/16/17 2:01 AM, Doug Simon wrote: >> Just to note here, this means an external version of Graal will now have to use --add-exports VM options to access JVMCI. Which is ok since additional VM options are required anyway to put an external Graal on the module path. >> >> -Doug >> >>> On 16 Feb 2017, at 08:54, Magnus Ihse Bursie wrote: >>> >>> On 2017-02-16 02:37, Vladimir Kozlov wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8174879 >>>> >>>> jdk.vm.ci and jdk.vm.compiler are purely JVM internal modules that is only of interest to VM developers (and researchers), not general Java developers. It'd be appropriate for it to be an internal module and not to export any API. >>>> >>>> Rename jdk.vm.ci and jdk.vm.compiler modules to jdk.internal.vm.ci and jdk.internal.vm.compiler. No packages renaming. >>>> Exports jdk.vm.ci.services only to jdk.internal.vm.compiler. >>>> >>>> Webrevs: >>>> >>>> top: http://cr.openjdk.java.net/~kvn/8174879/webrev.top/ >>>> jdk: http://cr.openjdk.java.net/~kvn/8174879/webrev.jdk/ >>>> hotspot: http://cr.openjdk.java.net/~kvn/8174879/webrev.hs/ >>> >>> Looks good to me. >>> >>> /Magnus >>>> >>>> Tested with RBT. >>>> >>>> Thanks, >>>> Vladimir >>> >> From magnus.ihse.bursie at oracle.com Fri Feb 17 08:49:26 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 17 Feb 2017 09:49:26 +0100 Subject: RFR: JDK-8175165 Don't process JceSecurity.java.template if crypto sources is not present Message-ID: <883e4367-da05-de88-a4b2-94082aefe0a1@oracle.com> If crypto sources is not present, the rule in jdk/make/gensrc/GensrcMisc.gmk wil fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8175165 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8175165-check-if-JceSecurity-java-template-is-present/webrev.01 /Magnus From erik.joelsson at oracle.com Fri Feb 17 09:19:51 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 17 Feb 2017 10:19:51 +0100 Subject: RFR: JDK-8175165 Don't process JceSecurity.java.template if crypto sources is not present In-Reply-To: <883e4367-da05-de88-a4b2-94082aefe0a1@oracle.com> References: <883e4367-da05-de88-a4b2-94082aefe0a1@oracle.com> Message-ID: <2287b14d-4f10-82d7-da5d-77c556a1ea56@oracle.com> Looks good to me. /Erik On 2017-02-17 09:49, Magnus Ihse Bursie wrote: > If crypto sources is not present, the rule in > jdk/make/gensrc/GensrcMisc.gmk wil fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175165 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8175165-check-if-JceSecurity-java-template-is-present/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Feb 20 16:02:03 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 Feb 2017 17:02:03 +0100 Subject: RFR: JDK-8175271: Race in GenerateLinkOptData.gmk Message-ID: <21d97dcb-ef3b-960a-15ca-91862e13baa0@oracle.com> Hello, There is a missing dependency declaration in GenerateLinkOptData.gmk. A rule like the one that generates CLASSLIST_FILE and JLI_TRACE_FILE is problematic and needs extra care because make can only understand one target file per rule. In this case we have added a new rule which depends on JLI_TRACE_FILE, but make does not know this file is created by the rule for CLASSLIST_FILE so we have to explicitly add that dependency. Bug: https://bugs.openjdk.java.net/browse/JDK-8175271 Patch: diff -r a4087bc10a88 make/GenerateLinkOptData.gmk --- a/make/GenerateLinkOptData.gmk +++ b/make/GenerateLinkOptData.gmk @@ -69,7 +69,7 @@ # The jli trace is created by the same recipe as classlist. By declaring these # dependencies, make will correctly rebuild both jli trace and classlist -# incrementally using the single recpie above. +# incrementally using the single recipe above. $(CLASSLIST_FILE): $(JLI_TRACE_FILE) $(JLI_TRACE_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXE_SUFFIX) $(CLASSLIST_JAR) @@ -89,6 +89,11 @@ DEST := $(JDK_OUTPUTDIR)/modules/jdk.jlink/jdk/tools/jlink/internal/plugins, \ )) +# Because of the single recipe for jli trace and classlist above, the +# COPY_JLI_TRACE rule needs to explicitly add the classlist file as a +# prerequisite. +$(COPY_JLI_TRACE): $(CLASSLIST_FILE) + TARGETS += $(COPY_JLI_TRACE) ################################################################################ /Erik From claes.redestad at oracle.com Mon Feb 20 16:03:34 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 20 Feb 2017 17:03:34 +0100 Subject: RFR: JDK-8175271: Race in GenerateLinkOptData.gmk In-Reply-To: <21d97dcb-ef3b-960a-15ca-91862e13baa0@oracle.com> References: <21d97dcb-ef3b-960a-15ca-91862e13baa0@oracle.com> Message-ID: <8a55d305-ce48-e804-cf6c-150c674072d4@oracle.com> +1 /Claes On 02/20/2017 05:02 PM, Erik Joelsson wrote: > Hello, > > There is a missing dependency declaration in GenerateLinkOptData.gmk. > A rule like the one that generates CLASSLIST_FILE and JLI_TRACE_FILE > is problematic and needs extra care because make can only understand > one target file per rule. In this case we have added a new rule which > depends on JLI_TRACE_FILE, but make does not know this file is created > by the rule for CLASSLIST_FILE so we have to explicitly add that > dependency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175271 > > Patch: > > diff -r a4087bc10a88 make/GenerateLinkOptData.gmk > --- a/make/GenerateLinkOptData.gmk > +++ b/make/GenerateLinkOptData.gmk > @@ -69,7 +69,7 @@ > > # The jli trace is created by the same recipe as classlist. By > declaring these > # dependencies, make will correctly rebuild both jli trace and classlist > -# incrementally using the single recpie above. > +# incrementally using the single recipe above. > $(CLASSLIST_FILE): $(JLI_TRACE_FILE) > $(JLI_TRACE_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXE_SUFFIX) > $(CLASSLIST_JAR) > > @@ -89,6 +89,11 @@ > DEST := > $(JDK_OUTPUTDIR)/modules/jdk.jlink/jdk/tools/jlink/internal/plugins, \ > )) > > +# Because of the single recipe for jli trace and classlist above, the > +# COPY_JLI_TRACE rule needs to explicitly add the classlist file as a > +# prerequisite. > +$(COPY_JLI_TRACE): $(CLASSLIST_FILE) > + > TARGETS += $(COPY_JLI_TRACE) > > ################################################################################ > > > > /Erik > From magnus.ihse.bursie at oracle.com Tue Feb 21 11:32:50 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Feb 2017 12:32:50 +0100 Subject: RFR: JDK-8175271: Race in GenerateLinkOptData.gmk In-Reply-To: <21d97dcb-ef3b-960a-15ca-91862e13baa0@oracle.com> References: <21d97dcb-ef3b-960a-15ca-91862e13baa0@oracle.com> Message-ID: <5bda7134-a80b-da81-96fc-656325d0aae8@oracle.com> On 2017-02-20 17:02, Erik Joelsson wrote: > Hello, > > There is a missing dependency declaration in GenerateLinkOptData.gmk. > A rule like the one that generates CLASSLIST_FILE and JLI_TRACE_FILE > is problematic and needs extra care because make can only understand > one target file per rule. In this case we have added a new rule which > depends on JLI_TRACE_FILE, but make does not know this file is created > by the rule for CLASSLIST_FILE so we have to explicitly add that > dependency. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175271 > > Patch: > > diff -r a4087bc10a88 make/GenerateLinkOptData.gmk > --- a/make/GenerateLinkOptData.gmk > +++ b/make/GenerateLinkOptData.gmk > @@ -69,7 +69,7 @@ > > # The jli trace is created by the same recipe as classlist. By > declaring these > # dependencies, make will correctly rebuild both jli trace and classlist > -# incrementally using the single recpie above. > +# incrementally using the single recipe above. > $(CLASSLIST_FILE): $(JLI_TRACE_FILE) > $(JLI_TRACE_FILE): $(INTERIM_IMAGE_DIR)/bin/java$(EXE_SUFFIX) > $(CLASSLIST_JAR) > > @@ -89,6 +89,11 @@ > DEST := > $(JDK_OUTPUTDIR)/modules/jdk.jlink/jdk/tools/jlink/internal/plugins, \ > )) > > +# Because of the single recipe for jli trace and classlist above, the > +# COPY_JLI_TRACE rule needs to explicitly add the classlist file as a > +# prerequisite. > +$(COPY_JLI_TRACE): $(CLASSLIST_FILE) > + > TARGETS += $(COPY_JLI_TRACE) > > ################################################################################ > > Looks good to me. /Magnus > > /Erik > From erik.joelsson at oracle.com Tue Feb 21 16:23:05 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Feb 2017 17:23:05 +0100 Subject: RFR: JDK-8175311: Jib sets bad JT_JAVA on linux aarch64 Message-ID: <4760941e-eb65-a489-e3b2-cbb19a7f6844@oracle.com> Open part of Oracle specific change for the Jib configuration. Moves the definition of the boot_jdk_platform to common to make it possible to override from the closed file. Bug: https://bugs.openjdk.java.net/browse/JDK-8175311 Webrev: http://cr.openjdk.java.net/~erikj/8175311/webrev.01/ /Erik From david.dehaven at oracle.com Tue Feb 21 16:36:03 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 21 Feb 2017 08:36:03 -0800 Subject: [9] RfR: JDK-8175307: rpath macro needs to use an argument on macosx Message-ID: Please review this fairly trivial one line fix, the proposed patch is in the comments of the JBS issue, duplicated here for consistency: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -355,7 +355,7 @@ SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" JVM_CFLAGS="$JVM_CFLAGS $PICFLAG" fi - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' Existing use of the macro for macosx do not provide an argument, this results in RPATH being set to @loader_path, which is fine. New use of the macro will be consistent with linux. -DrD- From david.dehaven at oracle.com Tue Feb 21 17:58:30 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 21 Feb 2017 09:58:30 -0800 Subject: [9] RfR: JDK-8175307: rpath macro needs to use an argument on macosx In-Reply-To: References: Message-ID: <9972EB1D-1241-4AEE-9AAD-04A037F59A58@oracle.com> > Please review this fairly trivial one line fix, the proposed patch is in the comments of the JBS issue, duplicated here for consistency: > > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -355,7 +355,7 @@ > SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" > JVM_CFLAGS="$JVM_CFLAGS $PICFLAG" > fi > - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' > + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' > SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" > SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' > SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' > > Existing use of the macro for macosx do not provide an argument, this results in RPATH being set to @loader_path, which is fine. New use of the macro will be consistent with linux. Ok, so it needs to be a two line fix, different sections for gcc and clang: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -355,7 +355,7 @@ SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" JVM_CFLAGS="$JVM_CFLAGS $PICFLAG" fi - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' @@ -375,7 +375,7 @@ # Linking is different on MacOSX PICFLAG='' SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' This time I actually verified it: $ grep SET_EXECUTABLE_ORIGIN build/macosx-x64-debug/spec.gmk SET_EXECUTABLE_ORIGIN=-Wl,-rpath, at loader_path$1 -DrD- From erik.joelsson at oracle.com Wed Feb 22 07:55:13 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Feb 2017 08:55:13 +0100 Subject: [9] RfR: JDK-8175307: rpath macro needs to use an argument on macosx In-Reply-To: <9972EB1D-1241-4AEE-9AAD-04A037F59A58@oracle.com> References: <9972EB1D-1241-4AEE-9AAD-04A037F59A58@oracle.com> Message-ID: <120ea9da-9e30-8dec-4fbe-13b7de49e2ab@oracle.com> Looks good. /Erik On 2017-02-21 18:58, David DeHaven wrote: >> Please review this fairly trivial one line fix, the proposed patch is in the comments of the JBS issue, duplicated here for consistency: >> >> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 >> --- a/common/autoconf/flags.m4 >> +++ b/common/autoconf/flags.m4 >> @@ -355,7 +355,7 @@ >> SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" >> JVM_CFLAGS="$JVM_CFLAGS $PICFLAG" >> fi >> - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' >> + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' >> SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" >> SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' >> SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' >> >> Existing use of the macro for macosx do not provide an argument, this results in RPATH being set to @loader_path, which is fine. New use of the macro will be consistent with linux. > Ok, so it needs to be a two line fix, different sections for gcc and clang: > > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -355,7 +355,7 @@ > SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" > JVM_CFLAGS="$JVM_CFLAGS $PICFLAG" > fi > - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' > + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' > SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" > SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' > SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' > @@ -375,7 +375,7 @@ > # Linking is different on MacOSX > PICFLAG='' > SHARED_LIBRARY_FLAGS="-dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 $PICFLAG" > - SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path/.' > + SET_EXECUTABLE_ORIGIN='-Wl,-rpath, at loader_path[$]1' > SET_SHARED_LIBRARY_ORIGIN="$SET_EXECUTABLE_ORIGIN" > SET_SHARED_LIBRARY_NAME='-Wl,-install_name, at rpath/[$]1' > SET_SHARED_LIBRARY_MAPFILE='-Wl,-exported_symbols_list,[$]1' > > This time I actually verified it: > $ grep SET_EXECUTABLE_ORIGIN build/macosx-x64-debug/spec.gmk > SET_EXECUTABLE_ORIGIN=-Wl,-rpath, at loader_path$1 > > -DrD- > From erik.joelsson at oracle.com Wed Feb 22 14:05:20 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Feb 2017 15:05:20 +0100 Subject: RFR: JDK-8077113: Configure script do not properly detect cross-compilation gcc Message-ID: <0a143c5c-97d8-9007-a412-5e84dc1a70df@oracle.com> Hello, When doing cross-compilation, a tool like nm gets picked up like '-linux-gnu-nm' but '-linux-gnu-gcc' will not. My fix uses AC_PATH_TOOL instead of AC_PATH_PROGS when actually searching for the compilers, which will look for the prefixed version of the tool first. The only drawback is that AC_PATH_TOOL does not accept multiple program names to search for, but we don't use that anyway. For each toolchain type, we only ever expect one name for the compiler. If we need to support multiple names, we can add a loop then. Bug: https://bugs.openjdk.java.net/browse/JDK-8077113 Webrev: http://cr.openjdk.java.net/~erikj/8077133/webrev.01/ /Erik From tim.bell at oracle.com Wed Feb 22 14:25:34 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 22 Feb 2017 06:25:34 -0800 Subject: RFR: JDK-8175311: Jib sets bad JT_JAVA on linux aarch64 In-Reply-To: <4760941e-eb65-a489-e3b2-cbb19a7f6844@oracle.com> References: <4760941e-eb65-a489-e3b2-cbb19a7f6844@oracle.com> Message-ID: <6713f8bb-a659-92e0-e762-f12c53f3f342@oracle.com> Erik: > Open part of Oracle specific change for the Jib configuration. Moves the > definition of the boot_jdk_platform to common to make it possible to > override from the closed file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175311 > > Webrev: http://cr.openjdk.java.net/~erikj/8175311/webrev.01/ Looks good. Tim From tim.bell at oracle.com Wed Feb 22 14:28:52 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 22 Feb 2017 06:28:52 -0800 Subject: RFR: JDK-8077113: Configure script do not properly detect cross-compilation gcc In-Reply-To: <0a143c5c-97d8-9007-a412-5e84dc1a70df@oracle.com> References: <0a143c5c-97d8-9007-a412-5e84dc1a70df@oracle.com> Message-ID: <6e725984-ea27-b91b-9167-f68ec68a56fd@oracle.com> Erik: > When doing cross-compilation, a tool like nm gets picked up like > '-linux-gnu-nm' but '-linux-gnu-gcc' will not. My > fix uses AC_PATH_TOOL instead of AC_PATH_PROGS when actually searching > for the compilers, which will look for the prefixed version of the tool > first. The only drawback is that AC_PATH_TOOL does not accept multiple > program names to search for, but we don't use that anyway. For each > toolchain type, we only ever expect one name for the compiler. If we > need to support multiple names, we can add a loop then. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077113 > > Webrev: http://cr.openjdk.java.net/~erikj/8077133/webrev.01/ Looks good Tim From magnus.ihse.bursie at oracle.com Thu Feb 23 14:21:29 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 23 Feb 2017 15:21:29 +0100 Subject: RFR: JDK-8077113: Configure script do not properly detect cross-compilation gcc In-Reply-To: <0a143c5c-97d8-9007-a412-5e84dc1a70df@oracle.com> References: <0a143c5c-97d8-9007-a412-5e84dc1a70df@oracle.com> Message-ID: <4CA7E6A4-D5F2-4BE2-9D74-7B13F736C512@oracle.com> It was that simple? :-) Great! The fix looks good. /Magnus > 22 feb. 2017 kl. 15:05 skrev Erik Joelsson : > > Hello, > > When doing cross-compilation, a tool like nm gets picked up like '-linux-gnu-nm' but '-linux-gnu-gcc' will not. My fix uses AC_PATH_TOOL instead of AC_PATH_PROGS when actually searching for the compilers, which will look for the prefixed version of the tool first. The only drawback is that AC_PATH_TOOL does not accept multiple program names to search for, but we don't use that anyway. For each toolchain type, we only ever expect one name for the compiler. If we need to support multiple names, we can add a loop then. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077113 > > Webrev: http://cr.openjdk.java.net/~erikj/8077133/webrev.01/ > > /Erik > From ioi.lam at oracle.com Thu Feb 23 22:10:27 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 23 Feb 2017 14:10:27 -0800 Subject: RTTI on Solaris/SPARC builds Message-ID: <58AF5DD3.1040404@oracle.com> I noticed that on Solaris/SPARC, RTTI is enabled in the JVM build. Is there any reason for it? Just curious. This is what I got in dbx when looking at the first slot of a C++ vtable: (dbx) print *(int**)(0xfffffffefa20bdd0) *((int **) 18446744069316066768U) = 0xfffffffef9de5b78 (dbx) dis 0xfffffffef9de6050 0xfffffffef9de6050: __RTTI__1nFMyYYY4nMConstantPool___ : illtrap 0x0 0xfffffffef9de6054: __RTTI__1nFMyYYY4nMConstantPool___+0x0004: illtrap 0xae8 0xfffffffef9de6058: __RTTI__1nFMyYYY4nMConstantPool___+0x0008: illtrap 0x0 0xfffffffef9de605c: __RTTI__1nFMyYYY4nMConstantPool___+0x000c: illtrap 0x0 0xfffffffef9de6060: __RTTI__1nFMyYYY4nMConstantPool___+0x0010: illtrap 0x0 0xfffffffef9de6064: __RTTI__1nFMyYYY4nMConstantPool___+0x0014: illtrap 0xaf0 0xfffffffef9de6068: __RTTI__1nFMyYYY4nMConstantPool___+0x0018: ldsb [%o7 - 3854], %g7 0xfffffffef9de606c: __RTTI__1nFMyYYY4nMConstantPool___+0x001c: sethi %hi(0x7612ac00), %l1 0xfffffffef9de6070: __RTTI__1nFMyYYY4nMConstantPool___+0x0020: ldstub [%i3 + 1076], %o4 0xfffffffef9de6074: __RTTI__1nFMyYYY4nMConstantPool___+0x0024: be,a 0xfffffffefa526810 Thanks - Ioi From david.holmes at oracle.com Fri Feb 24 00:19:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2017 10:19:15 +1000 Subject: RTTI on Solaris/SPARC builds In-Reply-To: <58AF5DD3.1040404@oracle.com> References: <58AF5DD3.1040404@oracle.com> Message-ID: <3cf56f45-9b84-746b-4d36-80b256b6e8de@oracle.com> On 24/02/2017 8:10 AM, Ioi Lam wrote: > I noticed that on Solaris/SPARC, RTTI is enabled in the JVM build. Is > there any reason for it? Just curious. Probably accidental due to default compiler settings. AFAIK we do not use any C++ RTTI in hotspot and it should not be enabled. David ----- > This is what I got in dbx when looking at the first slot of a C++ vtable: > > (dbx) print *(int**)(0xfffffffefa20bdd0) > *((int **) 18446744069316066768U) = 0xfffffffef9de5b78 > (dbx) dis 0xfffffffef9de6050 > 0xfffffffef9de6050: __RTTI__1nFMyYYY4nMConstantPool___ : illtrap > 0x0 > 0xfffffffef9de6054: __RTTI__1nFMyYYY4nMConstantPool___+0x0004: illtrap > 0xae8 > 0xfffffffef9de6058: __RTTI__1nFMyYYY4nMConstantPool___+0x0008: illtrap > 0x0 > 0xfffffffef9de605c: __RTTI__1nFMyYYY4nMConstantPool___+0x000c: illtrap > 0x0 > 0xfffffffef9de6060: __RTTI__1nFMyYYY4nMConstantPool___+0x0010: illtrap > 0x0 > 0xfffffffef9de6064: __RTTI__1nFMyYYY4nMConstantPool___+0x0014: illtrap > 0xaf0 > 0xfffffffef9de6068: __RTTI__1nFMyYYY4nMConstantPool___+0x0018: ldsb > [%o7 - 3854], %g7 > 0xfffffffef9de606c: __RTTI__1nFMyYYY4nMConstantPool___+0x001c: sethi > %hi(0x7612ac00), %l1 > 0xfffffffef9de6070: __RTTI__1nFMyYYY4nMConstantPool___+0x0020: ldstub > [%i3 + 1076], %o4 > 0xfffffffef9de6074: __RTTI__1nFMyYYY4nMConstantPool___+0x0024: be,a > 0xfffffffefa526810 > > Thanks > - Ioi From volker.simonis at gmail.com Fri Feb 24 08:00:36 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Feb 2017 09:00:36 +0100 Subject: RTTI on Solaris/SPARC builds In-Reply-To: <3cf56f45-9b84-746b-4d36-80b256b6e8de@oracle.com> References: <58AF5DD3.1040404@oracle.com> <3cf56f45-9b84-746b-4d36-80b256b6e8de@oracle.com> Message-ID: As far as I can see we don't explicitly set a compatibility mode so according to the SS 12 documentation [1] we are using -compat=5, which is the default. Also, according to [1], -feature=nortti can only be used in compat mode 4. So I'm afraid we have no choice :) Regards, Volker https://docs.oracle.com/cd/E19205-01/819-5267/6n7c46ebk/index.html On Fri, Feb 24, 2017 at 1:19 AM, David Holmes wrote: > On 24/02/2017 8:10 AM, Ioi Lam wrote: >> >> I noticed that on Solaris/SPARC, RTTI is enabled in the JVM build. Is >> there any reason for it? Just curious. > > > Probably accidental due to default compiler settings. AFAIK we do not use > any C++ RTTI in hotspot and it should not be enabled. > > David > ----- > > >> This is what I got in dbx when looking at the first slot of a C++ vtable: >> >> (dbx) print *(int**)(0xfffffffefa20bdd0) >> *((int **) 18446744069316066768U) = 0xfffffffef9de5b78 >> (dbx) dis 0xfffffffef9de6050 >> 0xfffffffef9de6050: __RTTI__1nFMyYYY4nMConstantPool___ : illtrap >> 0x0 >> 0xfffffffef9de6054: __RTTI__1nFMyYYY4nMConstantPool___+0x0004: illtrap >> 0xae8 >> 0xfffffffef9de6058: __RTTI__1nFMyYYY4nMConstantPool___+0x0008: illtrap >> 0x0 >> 0xfffffffef9de605c: __RTTI__1nFMyYYY4nMConstantPool___+0x000c: illtrap >> 0x0 >> 0xfffffffef9de6060: __RTTI__1nFMyYYY4nMConstantPool___+0x0010: illtrap >> 0x0 >> 0xfffffffef9de6064: __RTTI__1nFMyYYY4nMConstantPool___+0x0014: illtrap >> 0xaf0 >> 0xfffffffef9de6068: __RTTI__1nFMyYYY4nMConstantPool___+0x0018: ldsb >> [%o7 - 3854], %g7 >> 0xfffffffef9de606c: __RTTI__1nFMyYYY4nMConstantPool___+0x001c: sethi >> %hi(0x7612ac00), %l1 >> 0xfffffffef9de6070: __RTTI__1nFMyYYY4nMConstantPool___+0x0020: ldstub >> [%i3 + 1076], %o4 >> 0xfffffffef9de6074: __RTTI__1nFMyYYY4nMConstantPool___+0x0024: be,a >> 0xfffffffefa526810 >> >> Thanks >> - Ioi From david.holmes at oracle.com Fri Feb 24 08:32:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Feb 2017 18:32:36 +1000 Subject: RTTI on Solaris/SPARC builds In-Reply-To: References: <58AF5DD3.1040404@oracle.com> <3cf56f45-9b84-746b-4d36-80b256b6e8de@oracle.com> Message-ID: On 24/02/2017 6:00 PM, Volker Simonis wrote: > As far as I can see we don't explicitly set a compatibility mode so > according to the SS 12 documentation [1] we are using -compat=5, which > is the default. Also, according to [1], -feature=nortti can only be > used in compat mode 4. So I'm afraid we have no choice :) There are always unintended consequences of compiler upgrades :( David > Regards, > Volker > > https://docs.oracle.com/cd/E19205-01/819-5267/6n7c46ebk/index.html > > On Fri, Feb 24, 2017 at 1:19 AM, David Holmes wrote: >> On 24/02/2017 8:10 AM, Ioi Lam wrote: >>> >>> I noticed that on Solaris/SPARC, RTTI is enabled in the JVM build. Is >>> there any reason for it? Just curious. >> >> >> Probably accidental due to default compiler settings. AFAIK we do not use >> any C++ RTTI in hotspot and it should not be enabled. >> >> David >> ----- >> >> >>> This is what I got in dbx when looking at the first slot of a C++ vtable: >>> >>> (dbx) print *(int**)(0xfffffffefa20bdd0) >>> *((int **) 18446744069316066768U) = 0xfffffffef9de5b78 >>> (dbx) dis 0xfffffffef9de6050 >>> 0xfffffffef9de6050: __RTTI__1nFMyYYY4nMConstantPool___ : illtrap >>> 0x0 >>> 0xfffffffef9de6054: __RTTI__1nFMyYYY4nMConstantPool___+0x0004: illtrap >>> 0xae8 >>> 0xfffffffef9de6058: __RTTI__1nFMyYYY4nMConstantPool___+0x0008: illtrap >>> 0x0 >>> 0xfffffffef9de605c: __RTTI__1nFMyYYY4nMConstantPool___+0x000c: illtrap >>> 0x0 >>> 0xfffffffef9de6060: __RTTI__1nFMyYYY4nMConstantPool___+0x0010: illtrap >>> 0x0 >>> 0xfffffffef9de6064: __RTTI__1nFMyYYY4nMConstantPool___+0x0014: illtrap >>> 0xaf0 >>> 0xfffffffef9de6068: __RTTI__1nFMyYYY4nMConstantPool___+0x0018: ldsb >>> [%o7 - 3854], %g7 >>> 0xfffffffef9de606c: __RTTI__1nFMyYYY4nMConstantPool___+0x001c: sethi >>> %hi(0x7612ac00), %l1 >>> 0xfffffffef9de6070: __RTTI__1nFMyYYY4nMConstantPool___+0x0020: ldstub >>> [%i3 + 1076], %o4 >>> 0xfffffffef9de6074: __RTTI__1nFMyYYY4nMConstantPool___+0x0024: be,a >>> 0xfffffffefa526810 >>> >>> Thanks >>> - Ioi From zhuyong.me at gmail.com Tue Feb 28 08:51:46 2017 From: zhuyong.me at gmail.com (Zhu Yong) Date: Tue, 28 Feb 2017 16:51:46 +0800 Subject: Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: References: Message-ID: Dear All, I am testing cross compile OpenJDK-9+158 for our embedded system using buildroot, I can build server and client variants successfully, but the output compact1 profile file size is too big, then I tried to build minimal variant, failed when linking libjvm.so. I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o and jvmtiEnvThreadState.o are not listed in the file (which is required from the error message below). === Output from failing command(s) repeated here === * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() [clone .local.640]': cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, int*)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetCurrentContendedMonitor::doit() [clone .local.639]': cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, _jobject**)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetOwnedMonitorInfo::doit() [clone .local.638]': cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, GrowableArray<_ jvmtiMonitorStackDepthInfo*>*)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() [clone .local.637]': cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() [clone .local.636]': cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to `JvmtiThreadState::count_frames()' cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to `JvmtiEnvThreadState::set_frame_pop(int)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() [clone .local.641]': ... (rest of output omitted) My configuration: --with-jdk-variant=normal \ --with-jvm-variants=minimal \ --with-debug-level=release \ --disable-warnings-as-errors \ --disable-hotspot-gtest \ --with-abi-profile=arm-vfp-sflt \ --openjdk-target=$(GNU_TARGET_NAME) \ --with-sys-root=$(STAGING_DIR) \ --with-tools-dir=$(HOST_DIR) \ --with-freetype-include=$(STAGING_DIR)/usr/include \ --with-freetype-lib=$(STAGING_DIR)/usr/lib \ --with-freetype=$(STAGING_DIR)/usr/ \ --with-alsa-include=$(STAGING_DIR)/usr/include \ --with-alsa-lib=$(STAGING_DIR)/usr/lib \ --with-alsa=$(STAGING_DIR)/usr/ \ --with-cups=$(STAGING_DIR)/usr/ \ --with-x=$(STAGING_DIR)/usr/include \ --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ --enable-headless-only \ --disable-freetype-bundling \ --enable-unlimited-crypto \ --with-boot-jdk=/opt/java/jdk1.8.0_102 From erik.joelsson at oracle.com Tue Feb 28 09:19:14 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Feb 2017 10:19:14 +0100 Subject: Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: References: Message-ID: <677a04c9-90c7-9e82-3b4b-00843c6c504b@oracle.com> Hello, I doubt anyone has built a minimal arm jvm with only open code recently. To me this looks like an error in the Hotspot source code and not really a build issue as such. /Erik On 2017-02-28 09:51, Zhu Yong wrote: > Dear All, > > I am testing cross compile OpenJDK-9+158 for our embedded system using > buildroot, I can build server and client variants successfully, but the > output compact1 profile file size is too big, then I tried to build minimal > variant, failed when linking libjvm.so. > > I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ > libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o > and jvmtiEnvThreadState.o are not listed in the file (which is required > from the error message below). > > > === Output from failing command(s) repeated here === > * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() > [clone .local.640]': > cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to > `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, > int*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function > `VM_GetCurrentContendedMonitor::doit() > [clone .local.639]': > cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to > `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, > _jobject**)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetOwnedMonitorInfo::doit() > [clone .local.638]': > cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to > `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, GrowableArray<_ > jvmtiMonitorStackDepthInfo*>*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() > [clone .local.637]': > cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to > `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() [clone > .local.636]': > cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to > `JvmtiThreadState::count_frames()' > cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to > `JvmtiEnvThreadState::set_frame_pop(int)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() > [clone .local.641]': > ... (rest of output omitted) > > > My configuration: > > --with-jdk-variant=normal \ > --with-jvm-variants=minimal \ > --with-debug-level=release \ > --disable-warnings-as-errors \ > --disable-hotspot-gtest \ > --with-abi-profile=arm-vfp-sflt \ > --openjdk-target=$(GNU_TARGET_NAME) \ > --with-sys-root=$(STAGING_DIR) \ > --with-tools-dir=$(HOST_DIR) \ > --with-freetype-include=$(STAGING_DIR)/usr/include \ > --with-freetype-lib=$(STAGING_DIR)/usr/lib \ > --with-freetype=$(STAGING_DIR)/usr/ \ > --with-alsa-include=$(STAGING_DIR)/usr/include \ > --with-alsa-lib=$(STAGING_DIR)/usr/lib \ > --with-alsa=$(STAGING_DIR)/usr/ \ > --with-cups=$(STAGING_DIR)/usr/ \ > --with-x=$(STAGING_DIR)/usr/include \ > --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ > --enable-headless-only \ > --disable-freetype-bundling \ > --enable-unlimited-crypto \ > --with-boot-jdk=/opt/java/jdk1.8.0_102 From david.holmes at oracle.com Tue Feb 28 09:27:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Feb 2017 19:27:11 +1000 Subject: Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: <677a04c9-90c7-9e82-3b4b-00843c6c504b@oracle.com> References: <677a04c9-90c7-9e82-3b4b-00843c6c504b@oracle.com> Message-ID: On 28/02/2017 7:19 PM, Erik Joelsson wrote: > Hello, > > I doubt anyone has built a minimal arm jvm with only open code recently. > To me this looks like an error in the Hotspot source code and not really > a build issue as such. I'm trying to track it down, but yes this may well be the first time this has been attempted since the 32-bit ARM port was opened up. David > /Erik > > > On 2017-02-28 09:51, Zhu Yong wrote: >> Dear All, >> >> I am testing cross compile OpenJDK-9+158 for our embedded system using >> buildroot, I can build server and client variants successfully, but the >> output compact1 profile file size is too big, then I tried to build >> minimal >> variant, failed when linking libjvm.so. >> >> I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ >> libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o >> and jvmtiEnvThreadState.o are not listed in the file (which is required >> from the error message below). >> >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() >> [clone .local.640]': >> cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to >> `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, >> int*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >> `VM_GetCurrentContendedMonitor::doit() >> [clone .local.639]': >> cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to >> `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, >> _jobject**)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >> `VM_GetOwnedMonitorInfo::doit() >> [clone .local.638]': >> cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to >> `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, >> GrowableArray<_ >> jvmtiMonitorStackDepthInfo*>*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() >> [clone .local.637]': >> cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to >> `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() >> [clone >> .local.636]': >> cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to >> `JvmtiThreadState::count_frames()' >> cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to >> `JvmtiEnvThreadState::set_frame_pop(int)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() >> [clone .local.641]': >> ... (rest of output omitted) >> >> >> My configuration: >> >> --with-jdk-variant=normal \ >> --with-jvm-variants=minimal \ >> --with-debug-level=release \ >> --disable-warnings-as-errors \ >> --disable-hotspot-gtest \ >> --with-abi-profile=arm-vfp-sflt \ >> --openjdk-target=$(GNU_TARGET_NAME) \ >> --with-sys-root=$(STAGING_DIR) \ >> --with-tools-dir=$(HOST_DIR) \ >> --with-freetype-include=$(STAGING_DIR)/usr/include \ >> --with-freetype-lib=$(STAGING_DIR)/usr/lib \ >> --with-freetype=$(STAGING_DIR)/usr/ \ >> --with-alsa-include=$(STAGING_DIR)/usr/include \ >> --with-alsa-lib=$(STAGING_DIR)/usr/lib \ >> --with-alsa=$(STAGING_DIR)/usr/ \ >> --with-cups=$(STAGING_DIR)/usr/ \ >> --with-x=$(STAGING_DIR)/usr/include \ >> --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ >> --enable-headless-only \ >> --disable-freetype-bundling \ >> --enable-unlimited-crypto \ >> --with-boot-jdk=/opt/java/jdk1.8.0_102 > From david.holmes at oracle.com Tue Feb 28 09:35:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Feb 2017 19:35:27 +1000 Subject: Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: References: Message-ID: On 28/02/2017 6:51 PM, Zhu Yong wrote: > Dear All, > > I am testing cross compile OpenJDK-9+158 for our embedded system using > buildroot, I can build server and client variants successfully, but the > output compact1 profile file size is too big, then I tried to build minimal > variant, failed when linking libjvm.so. > > I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ > libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o > and jvmtiEnvThreadState.o are not listed in the file (which is required > from the error message below). Right - JVM TI is not part of the Minimal VM. At the moment it looks like some service has either been enabled when it should not have been, or has not been correctly if'def in the source. Can you provide the lines from your spec.gmk that define the JVM_FEATURES_* variables please. Thanks, David ------ > > === Output from failing command(s) repeated here === > * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() > [clone .local.640]': > cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to > `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, > int*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function > `VM_GetCurrentContendedMonitor::doit() > [clone .local.639]': > cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to > `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, > _jobject**)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetOwnedMonitorInfo::doit() > [clone .local.638]': > cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to > `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, GrowableArray<_ > jvmtiMonitorStackDepthInfo*>*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() > [clone .local.637]': > cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to > `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() [clone > .local.636]': > cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to > `JvmtiThreadState::count_frames()' > cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to > `JvmtiEnvThreadState::set_frame_pop(int)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() > [clone .local.641]': > ... (rest of output omitted) > > > My configuration: > > --with-jdk-variant=normal \ > --with-jvm-variants=minimal \ > --with-debug-level=release \ > --disable-warnings-as-errors \ > --disable-hotspot-gtest \ > --with-abi-profile=arm-vfp-sflt \ > --openjdk-target=$(GNU_TARGET_NAME) \ > --with-sys-root=$(STAGING_DIR) \ > --with-tools-dir=$(HOST_DIR) \ > --with-freetype-include=$(STAGING_DIR)/usr/include \ > --with-freetype-lib=$(STAGING_DIR)/usr/lib \ > --with-freetype=$(STAGING_DIR)/usr/ \ > --with-alsa-include=$(STAGING_DIR)/usr/include \ > --with-alsa-lib=$(STAGING_DIR)/usr/lib \ > --with-alsa=$(STAGING_DIR)/usr/ \ > --with-cups=$(STAGING_DIR)/usr/ \ > --with-x=$(STAGING_DIR)/usr/include \ > --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ > --enable-headless-only \ > --disable-freetype-bundling \ > --enable-unlimited-crypto \ > --with-boot-jdk=/opt/java/jdk1.8.0_102 > From david.holmes at oracle.com Tue Feb 28 10:11:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Feb 2017 20:11:39 +1000 Subject: Fwd: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: References: Message-ID: <30b93f7d-c442-82ab-75b4-61ab10c3e3eb@oracle.com> On 28/02/2017 7:35 PM, David Holmes wrote: > On 28/02/2017 6:51 PM, Zhu Yong wrote: >> Dear All, >> >> I am testing cross compile OpenJDK-9+158 for our embedded system using >> buildroot, I can build server and client variants successfully, but the >> output compact1 profile file size is too big, then I tried to build >> minimal >> variant, failed when linking libjvm.so. >> >> I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ >> libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o >> and jvmtiEnvThreadState.o are not listed in the file (which is required >> from the error message below). > > Right - JVM TI is not part of the Minimal VM. At the moment it looks > like some service has either been enabled when it should not have been, > or has not been correctly if'def in the source. As far as I can see your error messages are complaining about missing functions that are called from the same sources as the functions that are missing! ie. undefined reference to `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, _jobject**)' /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetOwnedMonitorInfo::doit() but VM_GetOwnedMonitorInfo is defined in jvmtiEnv.cpp which should be included or excluded the same as jvmtiEnBase.cpp. Here's the logic in the makefile that controls this: ifneq ($(call check-jvm-feature, jvmti), true) JVM_CFLAGS_FEATURES += -DINCLUDE_JVMTI=0 JVM_EXCLUDE_FILES += jvmtiGetLoadedClasses.cpp jvmtiThreadState.cpp jvmtiExtensions.cpp \ jvmtiImpl.cpp jvmtiManageCapabilities.cpp jvmtiRawMonitor.cpp jvmtiUtil.cpp jvmtiTrace.cpp \ jvmtiCodeBlobEvents.cpp jvmtiEnv.cpp jvmtiRedefineClasses.cpp jvmtiEnvBase.cpp jvmtiEnvThreadState.cpp \ jvmtiTagMap.cpp jvmtiEventController.cpp evmCompat.cpp jvmtiEnter.xsl jvmtiExport.cpp \ jvmtiClassFileReconstituter.cpp endif Can you run with LOG=trace so that each compiled file is listed in the build log, then see if there are any jvmti* files listed there. Thanks, David > Can you provide the lines from your spec.gmk that define the > JVM_FEATURES_* variables please. > > Thanks, > David > ------ > >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() >> [clone .local.640]': >> cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to >> `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, >> int*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >> `VM_GetCurrentContendedMonitor::doit() >> [clone .local.639]': >> cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to >> `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, >> _jobject**)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >> `VM_GetOwnedMonitorInfo::doit() >> [clone .local.638]': >> cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to >> `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, >> GrowableArray<_ >> jvmtiMonitorStackDepthInfo*>*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() >> [clone .local.637]': >> cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to >> `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() >> [clone >> .local.636]': >> cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to >> `JvmtiThreadState::count_frames()' >> cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to >> `JvmtiEnvThreadState::set_frame_pop(int)' >> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() >> [clone .local.641]': >> ... (rest of output omitted) >> >> >> My configuration: >> >> --with-jdk-variant=normal \ >> --with-jvm-variants=minimal \ >> --with-debug-level=release \ >> --disable-warnings-as-errors \ >> --disable-hotspot-gtest \ >> --with-abi-profile=arm-vfp-sflt \ >> --openjdk-target=$(GNU_TARGET_NAME) \ >> --with-sys-root=$(STAGING_DIR) \ >> --with-tools-dir=$(HOST_DIR) \ >> --with-freetype-include=$(STAGING_DIR)/usr/include \ >> --with-freetype-lib=$(STAGING_DIR)/usr/lib \ >> --with-freetype=$(STAGING_DIR)/usr/ \ >> --with-alsa-include=$(STAGING_DIR)/usr/include \ >> --with-alsa-lib=$(STAGING_DIR)/usr/lib \ >> --with-alsa=$(STAGING_DIR)/usr/ \ >> --with-cups=$(STAGING_DIR)/usr/ \ >> --with-x=$(STAGING_DIR)/usr/include \ >> --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ >> --enable-headless-only \ >> --disable-freetype-bundling \ >> --enable-unlimited-crypto \ >> --with-boot-jdk=/opt/java/jdk1.8.0_102 >> From bob.vandette at oracle.com Tue Feb 28 15:55:56 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 28 Feb 2017 10:55:56 -0500 Subject: cross compile OpenJDK-9+158 minimal variant failed when link libjvm.so In-Reply-To: <30b93f7d-c442-82ab-75b4-61ab10c3e3eb@oracle.com> References: <30b93f7d-c442-82ab-75b4-61ab10c3e3eb@oracle.com> Message-ID: I just cloned the latest http://hg.openjdk.java.net/jdk9/dev and was able to successfully build OpenJDK with the minimalvm. Here?s my configure script. /export/users/bobv/jdk9devopenonly/configure --enable-option-checking=fatal --build=x86_64-unknown-linux-gnu --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --with-jdk-variant=normal --with-jvm-variants=minimal --with-x=/java/embedded/buildtools/gcc/linux/arm/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr/X11R6-PI --with-alsa=/java/embedded/buildtools/gcc/linux/arm/gcc-linaro-arm-linux-gnueabihf-raspbian-2012.09-20120921_linux/arm-linux-gnueabihf/libc/usr/include/alsa --with-abi-profile=arm-vfp-sflt --with-cups-include=/java/devtools/share/cups/include/ --with-devkit=/java/embedded/buildtools/gcc/linux/arm/arm-linaro-4.7 --with-build-devkit=/java/devtools/linux/devkit/gcc4.9.2-OEL6.4 --with-debug-level=release --with-freetype-lib=/java/embedded/buildtools/freetype-2.6.2/build_linux-arm//lib --with-freetype-include=/java/embedded/buildtools/freetype-2.6.2/build_linux-arm//include/freetype2 --disable-warnings-as-errors Note: I had to apply this fix in order to build arm-vfp-sflt ABI profile. This fix will be in the mainline soon. https://bugs.openjdk.java.net/browse/JDK-8175567 Bob. > On Feb 28, 2017, at 5:11 AM, David Holmes wrote: > > On 28/02/2017 7:35 PM, David Holmes wrote: >> On 28/02/2017 6:51 PM, Zhu Yong wrote: >>> Dear All, >>> >>> I am testing cross compile OpenJDK-9+158 for our embedded system using >>> buildroot, I can build server and client variants successfully, but the >>> output compact1 profile file size is too big, then I tried to build >>> minimal >>> variant, failed when linking libjvm.so. >>> >>> I checked build/linux-arm-normal-minimal-release/hotspot/variant-minimal/ >>> libjvm/objs/_BUILD_LIBJVM_objectfilenames.txt, jvmtiEnvBase.o >>> and jvmtiEnvThreadState.o are not listed in the file (which is required >>> from the error message below). >> >> Right - JVM TI is not part of the Minimal VM. At the moment it looks >> like some service has either been enabled when it should not have been, >> or has not been correctly if'def in the source. > > As far as I can see your error messages are complaining about missing functions that are called from the same sources as the functions that are missing! ie. > > undefined reference to > `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, > _jobject**)' > /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetOwnedMonitorInfo::doit() > > but VM_GetOwnedMonitorInfo is defined in jvmtiEnv.cpp which should be included or excluded the same as jvmtiEnBase.cpp. Here's the logic in the makefile that controls this: > > ifneq ($(call check-jvm-feature, jvmti), true) > JVM_CFLAGS_FEATURES += -DINCLUDE_JVMTI=0 > JVM_EXCLUDE_FILES += jvmtiGetLoadedClasses.cpp jvmtiThreadState.cpp jvmtiExtensions.cpp \ > jvmtiImpl.cpp jvmtiManageCapabilities.cpp jvmtiRawMonitor.cpp jvmtiUtil.cpp jvmtiTrace.cpp \ > jvmtiCodeBlobEvents.cpp jvmtiEnv.cpp jvmtiRedefineClasses.cpp jvmtiEnvBase.cpp jvmtiEnvThreadState.cpp \ > jvmtiTagMap.cpp jvmtiEventController.cpp evmCompat.cpp jvmtiEnter.xsl jvmtiExport.cpp \ > jvmtiClassFileReconstituter.cpp > endif > > Can you run with LOG=trace so that each compiled file is listed in the build log, then see if there are any jvmti* files listed there. > > Thanks, > David > > > >> Can you provide the lines from your spec.gmk that define the >> JVM_FEATURES_* variables please. >> >> Thanks, >> David >> ------ >> >>> >>> === Output from failing command(s) repeated here === >>> * For target hotspot_variant-minimal_libjvm_objs_BUILD_LIBJVM_link: >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetStackTrace::doit() >>> [clone .local.640]': >>> cc27HS5M.ltrans0.o:(.text+0xce5e): undefined reference to >>> `JvmtiEnvBase::get_stack_trace(JavaThread*, int, int, _jvmtiFrameInfo*, >>> int*)' >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >>> `VM_GetCurrentContendedMonitor::doit() >>> [clone .local.639]': >>> cc27HS5M.ltrans0.o:(.text+0xcec2): undefined reference to >>> `JvmtiEnvBase::get_current_contended_monitor(JavaThread*, JavaThread*, >>> _jobject**)' >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function >>> `VM_GetOwnedMonitorInfo::doit() >>> [clone .local.638]': >>> cc27HS5M.ltrans0.o:(.text+0xcf26): undefined reference to >>> `JvmtiEnvBase::get_owned_monitors(JavaThread*, JavaThread*, >>> GrowableArray<_ >>> jvmtiMonitorStackDepthInfo*>*)' >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameCount::doit() >>> [clone .local.637]': >>> cc27HS5M.ltrans0.o:(.text+0xcf8a): undefined reference to >>> `JvmtiEnvBase::get_frame_count(JvmtiThreadState*, int*)' >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_SetFramePop::doit() >>> [clone >>> .local.636]': >>> cc27HS5M.ltrans0.o:(.text+0xcfea): undefined reference to >>> `JvmtiThreadState::count_frames()' >>> cc27HS5M.ltrans0.o:(.text+0xd030): undefined reference to >>> `JvmtiEnvThreadState::set_frame_pop(int)' >>> /tmp/cc27HS5M.ltrans0.ltrans.o: In function `VM_GetFrameLocation::doit() >>> [clone .local.641]': >>> ... (rest of output omitted) >>> >>> >>> My configuration: >>> >>> --with-jdk-variant=normal \ >>> --with-jvm-variants=minimal \ >>> --with-debug-level=release \ >>> --disable-warnings-as-errors \ >>> --disable-hotspot-gtest \ >>> --with-abi-profile=arm-vfp-sflt \ >>> --openjdk-target=$(GNU_TARGET_NAME) \ >>> --with-sys-root=$(STAGING_DIR) \ >>> --with-tools-dir=$(HOST_DIR) \ >>> --with-freetype-include=$(STAGING_DIR)/usr/include \ >>> --with-freetype-lib=$(STAGING_DIR)/usr/lib \ >>> --with-freetype=$(STAGING_DIR)/usr/ \ >>> --with-alsa-include=$(STAGING_DIR)/usr/include \ >>> --with-alsa-lib=$(STAGING_DIR)/usr/lib \ >>> --with-alsa=$(STAGING_DIR)/usr/ \ >>> --with-cups=$(STAGING_DIR)/usr/ \ >>> --with-x=$(STAGING_DIR)/usr/include \ >>> --with-extra-ldflags=--sysroot=$(STAGING_DIR) \ >>> --enable-headless-only \ >>> --disable-freetype-bundling \ >>> --enable-unlimited-crypto \ >>> --with-boot-jdk=/opt/java/jdk1.8.0_102 >>>