RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang

[Kim Barrett]

> On Oct 1, 2018, at 2:27 AM, David Holmes <david.holmes at oracle.com> 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.