RFR(S): 8031968 : Mac OS X: VM starts the agent by calling both Agent_OnAttach and Agent_OnAttach_L functions if its agent library is dynamically linked.
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Jan 22 05:46:23 PST 2014
On 1/22/14 2:06 AM, David Holmes wrote:
> On 22/01/2014 6:26 PM, Staffan Larsen wrote:
>>
>> On 22 jan 2014, at 02:53, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 22/01/2014 12:39 AM, Staffan Larsen wrote:
>>>> Here is a new version with #ifdef in os_bsd.cpp:
>>>> http://cr.openjdk.java.net/~sla/8031968/webrev.01/
>>>
>>> But why not simply put the ifdef in os_posix.cpp and avoid the
>>> refactoring? We already have platform ifdefs in there.
>>
>> We have one platform #ifdef in os_posix.cpp. I would like to avoid
>> adding more. On the other hand os_bsd.cpp is a combination file for
>> both Apple and other BSD flavors so it makes sense to have #ifdefs in
>> there.
>
> Yes but to apply that ifdef you had to move a function out of
> os_posix.cpp and replicate it in three other files - which is moving
> things in the wrong direction :(
I don't think putting more #ifdef's into os_posix.cpp is the right
direction.
Dan
>
> David
>
>> /Staffan
>>
>>
>>
>>> David
>>>
>>>> I did experiment with RTLD_FIRST on solaris, but had some problems
>>>> testing it out. I do think it is more correct, but I also think
>>>> RTLD_LAZY will work correctly there because we dlopen() agent
>>>> libraries with RTLD_LOCAL (which makes them invisible when calling
>>>> dlopen(0, RTLD_LAZY).
>>>>
>>>> /Staffan
>>>>
>>>> On 21 jan 2014, at 14:59, Dmitry Samersoff
>>>> <dmitry.samersoff at oracle.com> wrote:
>>>>
>>>>> Staffan,
>>>>>
>>>>> I think we should use RTLD_FIRST when it available (i.e. on Solaris
>>>>> too), because it's more correct in this case - we are interesting in
>>>>> symbols from current image only, not from all loaded libraries.
>>>>>
>>>>> But if you have concerns, I'm fain with #ifdef __APPLE__ in
>>>>> os_bsd.cpp
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2014-01-21 17:45, Staffan Larsen wrote:
>>>>>> RTLD_FIRST is also defined on solaris, but we don’t want to use
>>>>>> it there (I think).
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>> On 21 jan 2014, at 14:36, Dmitry Samersoff
>>>>>> <dmitry.samersoff at oracle.com> wrote:
>>>>>>
>>>>>>> Staffan,
>>>>>>>
>>>>>>> It might be better to place
>>>>>>>
>>>>>>> #ifdef RTLD_FIRST
>>>>>>> return (void*)::dlopen(NULL, RTLD_FIRST);
>>>>>>> #else
>>>>>>> return (void*)::dlopen(NULL, RTLD_LAZY);
>>>>>>> #endif
>>>>>>>
>>>>>>> to os_posix.cpp rather than duplicate code because BSDs besides
>>>>>>> Apple
>>>>>>> use RTLD_LAZY.
>>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>> On 2014-01-21 17:13, Staffan Larsen wrote:
>>>>>>>> Please review the following fix for how statically linked JVMTI
>>>>>>>> libraries are initialized.
>>>>>>>>
>>>>>>>> The problem is that dlopen() works differently on OS X than on
>>>>>>>> Linux/Solaris. We are using dlopen(NULL, RTLD_LAZY) to get a
>>>>>>>> handle for the main program. On OS X, the call should be
>>>>>>>> dlopen(NULL, RTLD_FIRST).
>>>>>>>>
>>>>>>>> The consequence of this is that on OS X if an agent defines
>>>>>>>> Agent_OnAttach_L but is not statically linked, the JVM will not
>>>>>>>> find that symbol the first time the agent is loaded (which is
>>>>>>>> as expected), but the second time the same agent is loaded, the
>>>>>>>> symbol will already exists in the process and now the JVM will
>>>>>>>> call it (which is not expected).
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8031968/webrev.00/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8031968
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> /Staffan
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Dmitry Samersoff
>>>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>>>> * I would love to change the world, but they won't give me the
>>>>>>> sources.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Samersoff
>>>>> Oracle Java development team, Saint Petersburg, Russia
>>>>> * I would love to change the world, but they won't give me the
>>>>> sources.
>>>>
>>
>
More information about the hotspot-runtime-dev
mailing list