On Thu, 22 Feb 2024 00:29:55 GMT, David Holmes <dhol...@openjdk.org> wrote:
> My main concern with a change like this as that it likely has little effect > on the OpenJDK itself, but we may be changing something that 3rd party > applications linking with libjvm are relying on. I realize this is a bit > "hand wavy" but are we sure this presents the exact same view of libjvm as > before? I realize that my essay-style comment was a bit TL;DR, but I tried to answer questions like this ahead of time in it. Let me quote: > I have checked the resulting libjvm.so/jvm.dll using the COMPARE_BUILD > functionality, which (among other things) analyzes differences between native > libraries before and after a patch. This has verified that there is no change > in the symbols of the Hotspot dynamic library on macOS/x64, macOS/aarch64 or > Windows/x64. I have also gotten help from @MBaesken and @JoKern65 to > confirmed that there is no effect on AIX. On linux/x64 and linux/aarch64 there are some very minor changes: > The difference is that the data (variable) symbols __bss_start, _edata and > _end, and the text (function) symbols _fini and _init has changed from local > to global. Afaik, these are symbols created by the linker. Also, when we used > a mapfile, the symbol SUNWprivate_1.1 that was part of the mapfile definition > was included in libjvm.so, and this is no longer the case. So yes, I have worked hard to make sure the resulting libjvm.so/jvm.dll is as close as humanly possible before and after this PR. I cannot think of a way in which 3rd party applications could even spot the difference before and after this patch. (Except for a contrived counterexample like explicitly looking up the visibility of `_init` and checking that it is indeed local...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1959081384
