Hi Kim,
On 1/10/2018 1:21 PM, Kim Barrett wrote:
On Sep 30, 2018, at 4:51 PM, David Holmes <david.hol...@oracle.com> 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
