RFR: JDK-8200358 Remove mapfiles for JDK executables (original) (raw)

Erik Joelsson erik.joelsson at oracle.com
Tue Apr 3 21:16:52 UTC 2018

Looks good to me at least. Exporting symbols from executables seems wrong so applying hidden as default seems good to me.

/Erik

On 2018-04-03 13:42, Magnus Ihse Bursie wrote:

Here's an updated webrev that uses the same pattern as for native shared libraries to hide non-exported symbols, for executables as well.

I hope you're happy now :-) WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02 I know there's a bit of redundancy now for setting -fvisibility=hidden and friends. I'll clean that up going forward. /Magnus On 2018-03-29 07:48, Martin Buchholz wrote:

On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com_ _<mailto:magnus.ihse.bursie at oracle.com>> wrote: On 2018-03-28 22:39, Martin Buchholz wrote:

On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com_ _<mailto:magnus.ihse.bursie at oracle.com>> wrote: Anyway, with this patch all symbols in executables will be visible, so there should be no problem anyway. The symbols visible in the main executable are a sort-of-public interface. The difference is visible via e.g. nm -D, or any native code that does dlsym(NULL, symbolName) (yes, we do this!).  The behavior of native code is likely to be affected if there is a symbol conflict.  The larger the exported symbol table, the more overhead there will be at startup (probably). The theory is that changing an interface requires a CSR. If I understand your objections correctly, you are claiming (correct me if I'm misunderstanding you): 1) Removing the mapfiles will affect performance negatively 2) The exported symbols from executables are a public API and the change therefore require a CSR. To this I reply: 1) While theoretically this might affect startup time, I can't for the life of me think this would even be measurable. I think any uncertainities in the measurement of the startup of "java" will dwarf any changes due to loading with a different set of exported symbols, in several orders of magnitude. If you claim otherwise, I challenge you to do the measurements. It's true the performance loss here is very small - every java program might be a microsecond slower to start up. 2) If this is a public API, then show me the documentation. If there is no documentation, then this is not a public interface. Just the fact that you might have used "nm" to locate symbols in a native file and use it, does not mean it's a public interface that requires a CSR to change. If that would be the case, then we could not ever do any change to any native file without filing a CSR, which is obviously absurd. Jigsaw team just spent 10 years working to prevent people from accessing Java internals.  But here the proposal for ELF symbols is "just make everything public" Every ELF symbol that is needlessly exported is something that someone might build a dependency on or might cause a name conflict.  ELF files don't have much encapsulation - all they have is public and  private. If you have code that are dependent on a certain set of symbols or whatnot, and you want it to keep functioning, then I recommend that you file a bug and submit a patch to get it into mainline. If you're just collecting a bunch of downstream patches, and this change make your life harder, well, then, sorry, that's not my problem. No, actually making everything public/exporting all symbols will probably make Google local changes easier to maintain - no map files! I would prefer if build team worked on generating map files with minimal symbols exported, instead of removing them entirely.

More information about the build-dev mailing list