From david.holmes at oracle.com  Sun Sep 30 20:51:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 1 Oct 2018 06:51:16 +1000
Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for
 Mac/clang
In-Reply-To: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com>
References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com>
Message-ID: <c69cc576-7a30-da4e-0c31-7912a2d31875@oracle.com>

Hi Kim,

On 30/09/2018 11:23 AM, Kim Barrett wrote:
> Please review this change to HotSpot build options and code to
> eliminate the suppression of deprecation warnings when building with
> clang.

Just as a historical note the no-deprecation-warning was only applied to 
os_bsd.cpp in the distant past. No idea when it became global.

> There are two code changes:
> 
> (1) Replace calls to finite() with C99 isfinite().  This also affects
> gcc-based builds, but isfinite has been supported there for a long
> time too.

Ok.

> (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.

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.

So I'd say this either has to be removed completely or else left alone.

Thanks,
David

> CR:
> https://bugs.openjdk.java.net/browse/JDK-8211296
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8211296/open.00/
> 
> Testing:
> Mach5 tier1, tier1-5 on MacOSX.
> 
>