PING: RFR: 8241439: jdk.NativeLibraryEvent hooks all opened regular files

[Yasumasa Suenaga]

Hi David,

On 2020/04/16 11:01, David Holmes wrote:
> Hi Yasumasa,
> 
> Not a review - sorry.
> 
> On 16/04/2020 10:30 am, Yasumasa Suenaga wrote:
>> PING: Could you review it?
>>
>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8241439
>>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8241439/webrev.01/
>>
>>
>> Yasumasa
>>
>>
>> On 2020/04/09 16:00, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> Please review this change:
>>>
>>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8241439
>>>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8241439/webrev.00/
>>>
>>> HotSpot has os::get_loaded_modules_info() to get all loaded native libraries, however it would call callback in twice on same library on Linux. Also it would call callback even if the file is not a library.
> 
> I'm not at all sure I agree with the problem as presented. If I examine a mapfile I see for example:
> 
> 7fb0400f0000-7fb0402b3000 r-xp 00000000 08:03 21081 /usr/lib64/libc-2.17.so
> 7fb0402b3000-7fb0404b3000 ---p 001c3000 08:03 21081 /usr/lib64/libc-2.17.so
> 7fb0404b3000-7fb0404b7000 r--p 001c3000 08:03 21081 /usr/lib64/libc-2.17.so
> 7fb0404b7000-7fb0404b9000 rw-p 001c7000 08:03 21081 /usr/lib64/libc-2.17.so
> 
> and I would expect to get the callback called for each of those lines because they report different mapped ranges. Is your approach consolidating this to a single callback with a contiguous range? Is that the kind of information people want to see? (I have no idea).

ELF binary has several segments which have different permission. So mapfile shows different entry for one ELF.

> As for filtering out memory-mapped files like classes.jsa ... while it is not a library as such it may be useful information to present. So perhaps the filtering should be done in the client code rather than in the os::get_loaded_modules_info() code?

os::get_loaded_modules_info() was introduced in JDK-8056242 to iterate dll/so/dylib for printing in error handler.
Thus the filtering should be done at os::get_loaded_modules_info(), and the callback should be called at once in each library.

> But this functionality was added purely for JFR so I think it is best if the JFR folk determine what is and isn't wanted here.

Considering JDK-8056242, I sent review request to both hotspot-jfr-dev and hotspot-runtime-dev.


Thanks,

Yasumasa


> Thanks,
> David
> -----
> 
>>>
>>> We can see this problem in jdk.NativeLibrary JFR event as below:
>>>
>>>
>>> ```
>>> jdk.NativeLibrary {
>>>     startTime = 16:59:06.621
>>>     name = "/usr/lib64/libc-2.30.so"
>>>     baseAddress = 0x7FDB06ACC000
>>>     topAddress = 0x7FDB06AF1000
>>> }
>>>
>>> jdk.NativeLibrary {
>>>     startTime = 16:59:06.621
>>>     name = "/usr/lib64/libc-2.30.so"
>>>     baseAddress = 0x7FDB06AF1000
>>>     topAddress = 0x7FDB06C40000
>>> }
>>>
>>>      :
>>>
>>> ```
>>>
>>> ```
>>> jdk.NativeLibrary {
>>>     startTime = 16:59:06.621
>>>     name = "/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-server-fastdebug/images/jdk/lib/server/classes.jsa"
>>>     baseAddress = 0x800000000
>>>     topAddress = 0x800007000
>>> }
>>> ```
>>>
>>> This change uses dl_iterate_phdr() to get them, so these problem has gone.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa