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

[Ioi Lam]

On Tue, 30 Jan 2024 10:27:08 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > > Maybe we could live with symbol redefinition using #define (conditionally for static linking in OpenJDK, as Coleen suggested earlier) for now, until the tooling can support symbol localizing better. Then localizing symbols using tools like `objcopy` can be the longer term and cleaner solution, instead of using namespace. What's your thoughts on that?
> > > 
> > > 
> > > I suppose so, but why?
> > > Why should any of this have to work on old systems? If their binutils is broken, static linking of openjdk won't work there.
> > 
> > 
> > We ran into issues with older gcc on linux-aarch for partial linking, but the problem may not be older gcc only(?). At the current stage, limiting static/hermetic Java runtime support to only the platforms that support partial linking and `objcopy` seems to be overly restrictive (it does simplify the requirements significantly however :-)):
> > The duplicate symbol problems are mostly found in JDK natives and have been resolved already. We've found very few symbol issues with hotspot code so far. As there are portable alternative solutions that can resolve the symbol issues in hotspot, choosing a less portable solution seems not too attractive currently.
> 
> I believe this to be a mistake. HotSpot, by design, exports only the symbols intended for use by other components. Many of the symbol names are highly generic, and will conflict with application code.
> 
> Sure, you have enough to be able to do some prototyping, but for real-world deployment you must be able to control symbol exports.

I agree with Andrew. We don't want the perfect to be the enemy of the good.

The only "perfect" solution is putting the HotSpot code in a namespace. This is going to be a huge undertaking. I don't think we have enough interest in the OpenJDK community to make such a change now.

I think partial linking with objcopy is a clean solution that's good enough for the actual use cases.

If someone wants to use `#define`, they can just make a local branch and add a few `#define` lines in their globalDefinitions.hpp. I suspect the configure script also allows adding C compiler options like `-DThread=HSThread`.

 `#define` is going to be a whack-a-mole hack. Google may need to isolate the `Thread` symbol, but other people may need to isolate things like `Symbol`, etc. It's not a good idea to add arbitrary `#define` in the HotSpot source code just because someone doesn't like it.

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

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