RFR: JDK-8200358 Remove mapfiles for JDK executables

[Erik Joelsson]

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.
>