RFR: JDK-8200178 Remove mapfiles for JDK native libraries
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Mar 23 15:15:35 UTC 2018
> 23 mars 2018 kl. 15:45 skrev Alan Bateman <Alan.Bateman at oracle.com>:
>> On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as _attribute__((visibility("default"))), or __declspec(dllexport)) to control symbol visibility, directly in the source code. This has historically not been present on all compilers, so we had to resort to using mapfiles (also known as linker scripts).
>> This is no longer the case. Now all compilers we use support symbol visibility directives, in one form or another. We should start using this. Since this has been the only way to control symbol visibility on Windows, for most of the shared code, we already have proper JNIEXPORT decorations in place.
>> If we fix the remaining platform-specific files to have proper JNIEXPORT tagging, then we can finally get rid of mapfiles.
> This seems like a great cleanup as the mapfile have always been a pain to maintain. Also shines a light on some technical debt too.
Very much so, yes. I've found a lot of dubious exports, everything from global variables (yuck!) to functions that does not seem to be used anymore, to lots of strange exports.
> handleSocketError in libnio is a surprise, this should not be exported and should not have been in the map file. I suspect the issue is that jdk.sctp is missing a function prototype from its header file (it has its own handleSocketError in SctpNet.c).
That might be so, yes.
> NET_Wait in libnet is another one, I can't tell why this was listed in the map file.
Neither can I. :-) Once again, my goal with this patch was to keep the produced binaries as similar to before with the mapfiles. I'll be happy to file follow-up bugs listing all suspicious symbol handling I've encountered, but I'd rather not change anything about that in this patch.
> I'm also surprised with java.dll exporting handleRead, winHandleRead, and handleLSeek. I didn't see them mentioned in your mail so I'm curious what might be using those.
They were previously exported using -export: on the command line for the Microsoft linker. This was the case for a couple other libraries as well. Yeah, I forgot to write about that, sorry. :( Been a lot to keep track of, and it went away when I cleaned up my notes.
Can I consider this a review?
More information about the core-libs-dev