On Wed, 17 Jan 2024 10:07:15 GMT, Andrew Haley <a...@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
