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

Jiangli Zhou jiangli at openjdk.org
Wed Jan 17 17:20:53 UTC 2024


On Wed, 17 Jan 2024 10:07:15 GMT, Andrew Haley <aph 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.
>
> Hooboy, this is an ugly solution, with some nasty side effects such as confusing error mesasges for developers and a very confusing debugger experience. Let's try to find a solution with a smaller blast radius.

Hi @theRealAph Thanks for looking into this! https://github.com/openjdk/jdk/pull/14808 comments touched on several options:

1. Using namespace, in smaller scope for specific class such as `StringTable` or for all hotspot code in a global scope.

   Most seem to prefer using a specific namespace for all hotspot code, but there were still concerns.

2. Using #define to redefine the symbol (using in the current PR)

   This is a somewhat hacky solution. It requires small changes without touching many source code for renaming. 

3. Redefine symbol at build/compile time. This is similar to the above. 

4. Direct rename in the source 

Earlier discussions and feedback seem to prefer options requiring non-large scale change (except hotspot namespace solution). If acceptable by everyone, direct renaming would be the least confusion causing option. Any other suggestions and ideas for resolving the `Thread` issue?

Thanks!

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

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


More information about the serviceability-dev mailing list