RFR: 8311846: Resolve duplicate 'Thread' related symbols with JDK static linking

[Jiangli Zhou]

On Wed, 17 Jan 2024 23:06:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this PR with a simple solution for resolving duplicate `Thread` symbol issue. In https://github.com/openjdk/jdk/pull/14808 comments, there was an alternative suggestion to redefine the symbol at build time, such as  using`-DThread=HotSpotThread`. That would not address issues when symbol were references as string literals. https://github.com/openjdk/jdk/pull/14808 also discussed using namespace for hotspot code, which can have multiple benefits/motivations. We could explore further using namespace with more consensus on that approach.
>> 
>> Contributed by Chuck Rasbold and @jianglizhou.
>
> I was reading through the other PR for StringTable and was wonder how difficult it would be to wrap all of hotspot in namespace hotspot {}; using namespace hotspot;  It would need a JEP as discussed in the other PR.
> 
> Alternatively if there's a #ifdef you can use for renaming the Thread to HotspotThread for static linking only, it might make this change less worrysome.

Thanks @coleenp, @dholmes-ora. For using a hotspot namespace, there are probably similar complications like the symbol usages that the current PR addresses in src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S and src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java. There might also be some complications with accessing hotspot code in JNI code. Those issues probably could be resolved relatively easily, I haven't experimented it. It seems that we may be converging on using hotspot namespace?

For just redefining the symbol only when doing static linking, it adds more differences between the static and non-static support. It's more useful when we can create both `.so` and `.a` from the same set of `.o` files without having to build two different `.o` from each c/c++ source files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17456#issuecomment-1899039171