RFR: 8017234: Hotspot should stop using mapfiles
Magnus Ihse Bursie
ihse at openjdk.org
Thu Feb 22 09:48:54 UTC 2024
On Thu, 22 Feb 2024 07:44:48 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves, [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was created in 2013. Even back then the use of mapfiles in Hotspot was dated, so this is really good riddance with old rubbish.
>>
>> This code touches on central but not well understood parts of the Hotspot dynamic library, which has contributed to why this bug has stayed unresolved for so long. I will need to explain this fix in more detail than usually necessary. (Please bare with me if this gets long.) I also anticipate that not all solutions that I've picked will be accepted, and we'll have to discuss how to proceed. I think it is better to have actual concrete code to discuss around, rather than starting by an abstract discussion. To keep this description short, I will post the discussion as a comment to the PR.
>>
>> I have run this PR through tier 1-3 in our CI system. I have also carefully checked how the resulting dynamic library differs with this patch (not much; see discussion below). For build system changes, this is often the most relevant metric.
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 74:
>
>> 72:
>> 73: #if defined(TARGET_COMPILER_gcc)
>> 74: #undef JNIEXPORT
>
> Based on the suggestion in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8017234?focusedId=14601421&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14601421), I think we can remove JNIEXPORT from all the functions in this file.
>
> We need to keep the JNICALL though; the deprecated Win32 port needs it, not sure if it's used anywhere else.
I think so too.
However, I would *really* like to do that separately as a follow up. My goal with this PR has been to make no changes in the product. Consider what would happen if we removed this, and there was some strange failure down the line. There is a high risk the entire PR would be backed out.
If instead we remove the JNIEXPORT in a separate change, and this causes failures, then it is a much easier backout, and we would be much better informed at exactly what failed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17955#discussion_r1498956646
More information about the build-dev
mailing list