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