RFR: 8311661: Resolve duplicate symbol of StringTable::StringTable with JDK static linking [v4]

[Jiangli Zhou]

On Fri, 14 Jul 2023 02:46:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I am concerned that something that [JDK-8303796](https://bugs.openjdk.org/browse/JDK-8303796) claimed to be a small enhancement is in fact requiring a lot of changes in different areas of the codebase. 

@dholmes-ora, sorry for the slow response, I was OOO. The fixes and enhancements for JDK-8303796 include:

- duplicate symbol fixes
- Make file changes to create the full set of static libraries
- Runtime fixes open sourced at https://github.com/jianglizhou/jdk/tree/static-java
  - Fix runtime crashes
  - Enhance builtin libraries lookup
  - Use runtime checks to detect JDK static build. Allow removing STATIC_BUILD macro and building static and dynamic libraries without rebuild .o files

The overall changes are not small. Individually each fix or enhancement, poetically the symbol fix is relatively small and non-complicated (except the built-in libraries lookup changes). Handling them as separate bugs and enhancements seems to be reasonable. 

The built-in library lookup and runtime changes may be suitable for a new JEP or putting in a Leyden project repo and propose later. It's built on top of the existing JEP 178: Statically-Linked JNI Libraries. To me, handling it with a new JEP as an enhancement on top of  JEP 178 is reasonable. Any thoughts on that?

> There are already a number of "duplicate symbol definition" issues that have been filed and fixed in an ad-hoc manner in the JDK, which is the kind of whack-a-mole approach that we should not be taking. If static linking requires symbol isolation then a generally applicable approach to doing that should be investigated (in a separate project? Leyden?) and then brought to mainline via a JEP (not just for the hotspot aspect as currently suggested).

The duplicated symbol issues consist three parts:

1. Symbol conflicts among the JDK native libraries and hotspot 
    Each issue is different and has been fixed in an ad-hoc manner. All issues have fixed by bugs linked with JDK-8303796. With enabling static JDK build (not yet done currently), we will be able to detect and prevent introducing new symbol issues in the future.

2. Symbol conflicts between hotspot and user code
    This is discussed by the thread in this PR. Moving hotspot code to hotspot unique namespace as suggested by @JornVernee is a good general solution.

3. Symbol conflicts between JDK library and user code
    With our prototype we found about 5 of those. I think these are outliers. Either fixing them as individually bugs or putting them in a Leyden repo and proposing together seems ok. Since the number is small enough, fixing individually might be slightly cleaner. Please let me know your thoughts. The JNI code defines APIs with naming convention consisting Java package and class names. There is no symbol issue with those. To prevent future issues, following the same naming style for helper methods and variables in JDK native code would work.

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

PR Comment: https://git.openjdk.org/jdk/pull/14808#issuecomment-1638622132