From david.holmes at oracle.com Mon Oct 1 06:27:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Oct 2018 16:27:32 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Message-ID: <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Hi Kim, On 1/10/2018 1:21 PM, Kim Barrett wrote: >> On Sep 30, 2018, at 4:51 PM, David Holmes wrote: >> >> Hi Kim, > > Thanks for looking at this. > >>> (2) Remove call to _dyld_bind_fully_image_containing_address, which >>> seems to have been deprecated since MacOSX 10.5. Instead use the >>> recommended replacement "dlopen(RTLD_NOW)". However, it might be we >>> don't need to do anything here anymore. I ran tier1-5 test without >>> the dlopen without any problems. But I'm not familiar with the >>> original problem, so not sure that's convincing. Perhaps another RFE >>> to determine whether this code can be deleted? >> >> The use of _dyld_bind_fully_image_containing_address, as per the comment is a workaround to force full binding of symbols in the library. I don't know where the "callbacks" referred to in the comment come from or why they may be unaligned - this seems to be day 1 code for the OS X port from 2008: >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l75.4001 >> >> I've cc'd the macosx-port-dev mailing list in case someone still subscribed there might know the answer. > > Yes, I?d noticed it was day-1 OS X port code. Thanks for cc?ing the macosx-port-dev list; I?d not thought of that. > >> If you don't have unaligned symbols then the workaround is not needed. In that case the replacement dlopen is also not needed (and it isn't needed to actually dlopen anything as you are opening the current library!). So it is not surprising that removing the dlopen causes no problem. >> >> With the dlopen in place however the code looks very strange and there's no guarantee it actually engages the workaround of the original function. > > The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW > forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the > deprecated function. The current library is libjvm and it's already opened in the appropriate way: libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 > > The following dlclose is to decrement the refcount increment associated with that dlopen, and does nothing > else since the library in question was already loaded and still has references. > >> So I'd say this either has to be removed completely or else left alone. > > The warning message is: > > _dyld_bind_fully_image_containing_address((const void *) &os::init); > note: '_dyld_bind_fully_image_containing_address' has been explicitly marked deprecated here > extern bool _dyld_bind_fully_image_containing_address(const void* address) __IOS_UNAVAILABLE __BRIDGEOS_UNAVAILABLE __OSX_DEPRECATED(10.1, 10.5, "dlopen(RTLD_NOW)"); > > The arguments in __OSX_DEPRECATED(10.1, 10.5. "dlopen(RTLD_NOW)") > indicate it was introduced in 10.1, deprecated in 10.5, and the replacement to use instead. > So I?m just using the recommended replacement (which was described in brief in the > warning message, rather than working code). > > I?m reluctant to remove this completely without a better understanding of what it is there for and why > it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive > but not definitive. I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ... Cheers, David From kim.barrett at oracle.com Mon Oct 1 03:21:30 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 30 Sep 2018 23:21:30 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Message-ID: > On Sep 30, 2018, at 4:51 PM, David Holmes wrote: > > Hi Kim, Thanks for looking at this. >> (2) Remove call to _dyld_bind_fully_image_containing_address, which >> seems to have been deprecated since MacOSX 10.5. Instead use the >> recommended replacement "dlopen(RTLD_NOW)". However, it might be we >> don't need to do anything here anymore. I ran tier1-5 test without >> the dlopen without any problems. But I'm not familiar with the >> original problem, so not sure that's convincing. Perhaps another RFE >> to determine whether this code can be deleted? > > The use of _dyld_bind_fully_image_containing_address, as per the comment is a workaround to force full binding of symbols in the library. I don't know where the "callbacks" referred to in the comment come from or why they may be unaligned - this seems to be day 1 code for the OS X port from 2008: > > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l75.4001 > > I've cc'd the macosx-port-dev mailing list in case someone still subscribed there might know the answer. Yes, I?d noticed it was day-1 OS X port code. Thanks for cc?ing the macosx-port-dev list; I?d not thought of that. > If you don't have unaligned symbols then the workaround is not needed. In that case the replacement dlopen is also not needed (and it isn't needed to actually dlopen anything as you are opening the current library!). So it is not surprising that removing the dlopen causes no problem. > > With the dlopen in place however the code looks very strange and there's no guarantee it actually engages the workaround of the original function. The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the deprecated function. The following dlclose is to decrement the refcount increment associated with that dlopen, and does nothing else since the library in question was already loaded and still has references. > So I'd say this either has to be removed completely or else left alone. The warning message is: _dyld_bind_fully_image_containing_address((const void *) &os::init); note: '_dyld_bind_fully_image_containing_address' has been explicitly marked deprecated here extern bool _dyld_bind_fully_image_containing_address(const void* address) __IOS_UNAVAILABLE __BRIDGEOS_UNAVAILABLE __OSX_DEPRECATED(10.1, 10.5, "dlopen(RTLD_NOW)"); The arguments in __OSX_DEPRECATED(10.1, 10.5. "dlopen(RTLD_NOW)") indicate it was introduced in 10.1, deprecated in 10.5, and the replacement to use instead. So I?m just using the recommended replacement (which was described in brief in the warning message, rather than working code). I?m reluctant to remove this completely without a better understanding of what it is there for and why it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive but not definitive. From kim.barrett at oracle.com Mon Oct 1 18:35:10 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Oct 2018 14:35:10 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Message-ID: > On Oct 1, 2018, at 2:27 AM, David Holmes wrote: > > On 1/10/2018 1:21 PM, Kim Barrett wrote: >> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >> deprecated function. > > The current library is libjvm and it's already opened in the appropriate way: > > libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); > > and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? > > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 The current version of LoadJavaVM (for Mac) contains: #ifndef STATIC_BUILD libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); #else libjvm = dlopen(NULL, RTLD_FIRST); #endif where STATIC_BUILD is controlled by the --enable-static-builds configure option. The --enable-static-builds option was added in JDK 9 by 8136556: Add the ability to perform static builds of MacOSX x64 binaries. So it is possible for libjava to be opened without RTLD_NOW. I think the proposed change should work correctly in that case. The dladdr should find the current object, which we'll open by name (rather than using NULL, but that should be okay), using RTLD_NOW, forcing resolution of all symbols. I'm not sure there can be any relevant unresolved symbols on this path, but then, as said before, I don't understand the point of this workaround. >> I?m reluctant to remove this completely without a better understanding of what it is there for and why >> it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive >> but not definitive. > > I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ? I thought this part of the change would be straight-forward. An alternative would be to leave the old deprecated call in place, locally disable the deprecation warning, and file an RFE for someone more knowledgable in this area and with Mac development to look at. From david.holmes at oracle.com Mon Oct 1 23:10:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Oct 2018 09:10:14 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Message-ID: <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> On 2/10/2018 4:35 AM, Kim Barrett wrote: >> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >> >> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>> deprecated function. >> >> The current library is libjvm and it's already opened in the appropriate way: >> >> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >> >> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 > > The current version of LoadJavaVM (for Mac) contains: > > #ifndef STATIC_BUILD > libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); > #else > libjvm = dlopen(NULL, RTLD_FIRST); > #endif > > where STATIC_BUILD is controlled by the --enable-static-builds > configure option. The --enable-static-builds option was added in JDK 9 > by 8136556: Add the ability to perform static builds of MacOSX x64 > binaries. Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. > So it is possible for libjava to be opened without RTLD_NOW. I think > the proposed change should work correctly in that case. The dladdr > should find the current object, which we'll open by name (rather than > using NULL, but that should be okay), using RTLD_NOW, forcing > resolution of all symbols. I'm not sure there can be any relevant > unresolved symbols on this path, but then, as said before, I don't > understand the point of this workaround. > >>> I?m reluctant to remove this completely without a better understanding of what it is there for and why >>> it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive >>> but not definitive. >> >> I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ? > > I thought this part of the change would be straight-forward. An > alternative would be to leave the old deprecated call in place, > locally disable the deprecation warning, and file an RFE for someone > more knowledgable in this area and with Mac development to look at. Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. Perhaps the old per-file flag setting can be restored. By all means file a RFE but I fear there is noone who would know the details of this any more. :( David From kim.barrett at oracle.com Tue Oct 2 20:51:40 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Oct 2018 16:51:40 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> Message-ID: <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> > On Oct 1, 2018, at 7:10 PM, David Holmes wrote: > > On 2/10/2018 4:35 AM, Kim Barrett wrote: >>> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >>> >>> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>>> deprecated function. >>> >>> The current library is libjvm and it's already opened in the appropriate way: >>> >>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>> >>> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >>> >>> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 >> The current version of LoadJavaVM (for Mac) contains: >> #ifndef STATIC_BUILD >> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >> #else >> libjvm = dlopen(NULL, RTLD_FIRST); >> #endif >> where STATIC_BUILD is controlled by the --enable-static-builds >> configure option. The --enable-static-builds option was added in JDK 9 >> by 8136556: Add the ability to perform static builds of MacOSX x64 >> binaries. > > Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? I think the MacOSX version of LoadJavaVM is here: ./java.base/macosx/native/libjli/java_md_macosx.m (Note that this appears to be an Obj-C source file.) (And no, I have no idea what build magic goes on to make this work.) This has the STATIC_BUILD stuff. There are also definitions for other platforms. ./java.base/windows/native/libjli/java_md.c // Windows ./java.base/unix/native/libjli/java_md_solinux.c // Solaris/Linux/AIX (Note that java_md_solinux.c is excluded for macosx by the build system; see LIBJLI_EXCLUDE_FILES in CoreLibraries.gmk.) > Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) I think symbol resolution can make sense with a static build, if there are other libraries that are not statically linked. I don't know whether that's the case here. I'm going to try doing a static build without this dlopen code and see what happens. > in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. > That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. I think my replacement code is equivalent to the deprecated code. I think the sequence of events may have been something like: (1) dlopen java lib without RTLD_NOW (2) run into problems that led to workaround code (3) run into further problems that led to dlopen java lib with RTLD_NOW but didn't remove the now superfluous workaround (perhaps it was forgotten?) (4) merge >> I thought this part of the change would be straight-forward. An >> alternative would be to leave the old deprecated call in place, >> locally disable the deprecation warning, and file an RFE for someone >> more knowledgable in this area and with Mac development to look at. > > Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. I agree that for the non-STATIC_BUILD case the workaround is superfluous. If a static build without any workaround code works then I think the workaround code should just be removed. Is that okay with you? From david.holmes at oracle.com Tue Oct 2 22:10:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 08:10:12 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> Message-ID: On 3/10/2018 6:51 AM, Kim Barrett wrote: >> On Oct 1, 2018, at 7:10 PM, David Holmes wrote: >> >> On 2/10/2018 4:35 AM, Kim Barrett wrote: >>>> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >>>> >>>> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>>>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>>>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>>>> deprecated function. >>>> >>>> The current library is libjvm and it's already opened in the appropriate way: >>>> >>>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>>> >>>> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >>>> >>>> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 >>> The current version of LoadJavaVM (for Mac) contains: >>> #ifndef STATIC_BUILD >>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>> #else >>> libjvm = dlopen(NULL, RTLD_FIRST); >>> #endif >>> where STATIC_BUILD is controlled by the --enable-static-builds >>> configure option. The --enable-static-builds option was added in JDK 9 >>> by 8136556: Add the ability to perform static builds of MacOSX x64 >>> binaries. >> >> Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? > > I think the MacOSX version of LoadJavaVM is here: > ./java.base/macosx/native/libjli/java_md_macosx.m > (Note that this appears to be an Obj-C source file.) > (And no, I have no idea what build magic goes on to make this work.) > This has the STATIC_BUILD stuff. Hmmm okay. But I can't find that file in the original mac port, or in 7u at all. In 7u we have jdk/src/macosx/bin/java_md_macosx.c with libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); and that was created in 2012 when the launcher was refactored under JDK-7124089. The archaeology is getting too hard. :( > There are also definitions for other platforms. > ./java.base/windows/native/libjli/java_md.c // Windows > ./java.base/unix/native/libjli/java_md_solinux.c // Solaris/Linux/AIX > (Note that java_md_solinux.c is excluded for macosx by the build > system; see LIBJLI_EXCLUDE_FILES in CoreLibraries.gmk.) > >> Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) > > I think symbol resolution can make sense with a static build, if there > are other libraries that are not statically linked. I don't know > whether that's the case here. I'm going to try doing a static build > without this dlopen code and see what happens. > >> in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. >> That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. > > I think my replacement code is equivalent to the deprecated code. I > think the sequence of events may have been something like: > > (1) dlopen java lib without RTLD_NOW > (2) run into problems that led to workaround code > (3) run into further problems that led to dlopen java lib with RTLD_NOW > but didn't remove the now superfluous workaround (perhaps it was > forgotten?) > (4) merge Perhaps. No way to know. > >>> I thought this part of the change would be straight-forward. An >>> alternative would be to leave the old deprecated call in place, >>> locally disable the deprecation warning, and file an RFE for someone >>> more knowledgable in this area and with Mac development to look at. >> >> Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. > > I agree that for the non-STATIC_BUILD case the workaround is > superfluous. If a static build without any workaround code works then > I think the workaround code should just be removed. Is that okay with > you? Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. Other opinions welcomed. David > From kim.barrett at oracle.com Tue Oct 2 23:30:45 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Oct 2018 19:30:45 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> Message-ID: <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> > On Oct 2, 2018, at 6:10 PM, David Holmes wrote: > The archaeology is getting too hard. :( No kidding! > Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. > > Other opinions welcomed. I was planning to hit it with tier1-8 and possibly other things if I can find them. JCK tests too; I saw some instructions for running those in mach5 recently. That all assumes that static build actually works at all; it doesn?t look like we test that configuration these days, so who knows what bit rot may have set in. From magnus.ihse.bursie at oracle.com Thu Oct 4 13:27:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 15:27:43 +0200 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> Message-ID: 3 okt. 2018 kl. 01:30 skrev Kim Barrett : >> On Oct 2, 2018, at 6:10 PM, David Holmes wrote: >> The archaeology is getting too hard. :( > > No kidding! > >> Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. >> >> Other opinions welcomed. > > I was planning to hit it with tier1-8 and possibly other things if I can find them. > JCK tests too; I saw some instructions for running those in mach5 recently. > > That all assumes that static build actually works at all; it doesn?t look like we > test that configuration these days, so who knows what bit rot may have set in. > No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. /Magnus From kim.barrett at oracle.com Thu Oct 4 21:18:05 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:18:05 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> Message-ID: <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> > On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie wrote: >> That all assumes that static build actually works at all; it doesn?t look like we >> test that configuration these days, so who knows what bit rot may have set in. >> > > No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. > > This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. > > The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. > > The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. > > /Magnus The "static build" doesn't build anymore. We're all shocked that this untested configuration has bit-rotted. :) LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the workaround is superfluous in that case. Given that, I'm going to delete the workaround and file an RFE [1] to fix or remove the currently broken "static build" support, with a comment there referring to this workaround code as possibly being relevant to fixing the static build. [1] https://bugs.openjdk.java.net/browse/JDK-8211732 New webrev: http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ From david.holmes at oracle.com Thu Oct 4 21:31:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Oct 2018 07:31:33 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> Message-ID: <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> Looks good! Thanks for your patience and perseverance! :) David On 5/10/2018 7:18 AM, Kim Barrett wrote: >> On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie wrote: >>> That all assumes that static build actually works at all; it doesn?t look like we >>> test that configuration these days, so who knows what bit rot may have set in. >>> >> >> No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. >> >> This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. >> >> The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. >> >> The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. >> >> /Magnus > > The "static build" doesn't build anymore. We're all shocked that this > untested configuration has bit-rotted. :) > > LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the > workaround is superfluous in that case. Given that, I'm going to > delete the workaround and file an RFE [1] to fix or remove the > currently broken "static build" support, with a comment there > referring to this workaround code as possibly being relevant to fixing > the static build. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211732 > > New webrev: > http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ > From kim.barrett at oracle.com Thu Oct 4 22:32:41 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 18:32:41 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> Message-ID: > On Oct 4, 2018, at 5:25 PM, Mikael Vidstedt wrote: >> The "static build" doesn't build anymore. We're all shocked that this >> untested configuration has bit-rotted. :) >> >> LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the >> workaround is superfluous in that case. Given that, I'm going to >> delete the workaround and file an RFE [1] to fix or remove the >> currently broken "static build" support, with a comment there >> referring to this workaround code as possibly being relevant to fixing >> the static build. > > I?m glad to see this gone. Looks good! Thanks! > > Cheers, > Mikael > >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211732 >> >> New webrev: >> http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ From kim.barrett at oracle.com Thu Oct 4 22:33:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 18:33:27 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> Message-ID: <724BAC82-812B-40F6-84F9-9327203101B3@oracle.com> > On Oct 4, 2018, at 5:31 PM, David Holmes wrote: > > Looks good! > > Thanks for your patience and perseverance! :) Thanks! And thanks for your patience and perseverance too! > > David From kim.barrett at oracle.com Wed Oct 10 01:23:02 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Oct 2018 21:23:02 -0400 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound Message-ID: <79BC1665-4524-42E8-BEE8-401323B37010@oracle.com> Please review this trivial fix of a build failure on MacOSX when compiling with C++11/14 enabled. An int value is being used in an initializer where an unsigned int is needed, which is not permitted since C++11. The solution taken is to cast the value in the initializer. A "better" solution would be to change the type of the value, but that has substantial fannout because there are many places in our code where signed ints were used instead of the unsigned ints used by the underlying MacOSX framework. CR: https://bugs.openjdk.java.net/browse/JDK-8211962 Webrev: http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ Testing: mach5 tier1 on MacOSX (really just verifying it builds). From Sergey.Bylokhov at oracle.com Thu Oct 11 01:20:48 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 10 Oct 2018 18:20:48 -0700 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: <79BC1665-4524-42E8-BEE8-401323B37010@oracle.com> References: <79BC1665-4524-42E8-BEE8-401323B37010@oracle.com> Message-ID: <39daa167-16d5-87b4-6ce5-d9d482e47188@oracle.com> Looks fine. On 09/10/2018 18:23, Kim Barrett wrote: > Please review this trivial fix of a build failure on MacOSX when > compiling with C++11/14 enabled. An int value is being used in an > initializer where an unsigned int is needed, which is not permitted > since C++11. The solution taken is to cast the value in the > initializer. A "better" solution would be to change the type of the > value, but that has substantial fannout because there are many places > in our code where signed ints were used instead of the unsigned ints > used by the underlying MacOSX framework. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8211962 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ > > Testing: > mach5 tier1 on MacOSX (really just verifying it builds). > > -- Best regards, Sergey. From kim.barrett at oracle.com Thu Oct 11 03:43:07 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Oct 2018 23:43:07 -0400 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: <39daa167-16d5-87b4-6ce5-d9d482e47188@oracle.com> References: <79BC1665-4524-42E8-BEE8-401323B37010@oracle.com> <39daa167-16d5-87b4-6ce5-d9d482e47188@oracle.com> Message-ID: <6F57FA3F-C38E-4EF2-A4D1-DF5BBB5212B9@oracle.com> > On Oct 10, 2018, at 9:20 PM, Sergey Bylokhov wrote: > > Looks fine. Thanks! > > On 09/10/2018 18:23, Kim Barrett wrote: >> Please review this trivial fix of a build failure on MacOSX when >> compiling with C++11/14 enabled. An int value is being used in an >> initializer where an unsigned int is needed, which is not permitted >> since C++11. The solution taken is to cast the value in the >> initializer. A "better" solution would be to change the type of the >> value, but that has substantial fannout because there are many places >> in our code where signed ints were used instead of the unsigned ints >> used by the underlying MacOSX framework. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8211962 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ >> Testing: >> mach5 tier1 on MacOSX (really just verifying it builds). > > > -- > Best regards, Sergey.