On Tue, 30 Jan 2024 10:27:08 GMT, Andrew Haley <a...@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
