RFR: JDK-8200358 Remove mapfiles for JDK executables

Wed Apr 4 07:42:16 UTC 2018

On 2018-04-03 23:16, Erik Joelsson wrote:
> Looks good to me at least. Exporting symbols from executables seems 
> wrong so applying hidden as default seems good to me.
Unfortunately, it was not this easy. :-(

Out of paranoia, I also started a test run on Windows, even though it 
should not have been affected. Well, "should not". The added JNIEXPORT 
turns into a __declspec(dllexport) on Windows, which causes the 
Microsoft linker to behave like when linking a dll, so it creates a .lib 
and .exp for each binary, in the bin directory.

*sigh*

I see two ways out of this.

1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
main function, or by declaring something like EXEC_EXPORT instead, and 
let it be empty on Windows.

2) Let the part of SetupNativeCompilation that handles executables 
behave more like the one for shared libraries, and setting -implib, etc. 
I'm not sure what happens if you pass in -implib when linking an 
executable which does *not* have any dllexport decorations. If it 
breaks, then this does not really seem like a way forward. Otherwise, 
it's probably the safest choice, since it will make sure we never leak 
any *.lib or *.exp for a potential future executable.

What do you think?

/Magnus

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