On Wed, Mar 28, 2018 at 2:48 PM, Magnus Ihse Bursie < magnus.ihse.bur...@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.bur...@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.
