RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

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.