Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Erik Joelsson]

This looks good, hopefully for the last time. :)

Thanks for hanging in there!

/Erik


On 2018-04-05 02:16, Magnus Ihse Bursie wrote:

On 2018-04-04 17:25, Erik Joelsson wrote:


On 2018-04-04 00:42, Magnus Ihse Bursie wrote:

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?

I really don't know which I would prefer. Would be good to find out 
what happens in 2.


Turns out that -implib is just ignored if not needed, so 2 is clearly 
the way to go.


This also meant that there was much overlap between the linking of 
shared libraries and executables in SetupNativeCompilation, so I 
(finally) took the time to unify them.


Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.03

(Only changes NativeCompilation.gmk)

/Magnus




/Erik

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

On 2018-04-04 17:25, Erik Joelsson wrote:


On 2018-04-04 00:42, Magnus Ihse Bursie wrote:

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?

I really don't know which I would prefer. Would be good to find out 
what happens in 2.


Turns out that -implib is just ignored if not needed, so 2 is clearly 
the way to go.


This also meant that there was much overlap between the linking of 
shared libraries and executables in SetupNativeCompilation, so I 
(finally) took the time to unify them.


Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.03

(Only changes NativeCompilation.gmk)

/Magnus




/Erik

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Martin Buchholz]

On Tue, Apr 3, 2018 at 1:42 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> 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 :-)
>
>
Thanks for your efforts!  I know it's not easy.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Erik Joelsson]

On 2018-04-04 00:42, Magnus Ihse Bursie wrote:

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?

I really don't know which I would prefer. Would be good to find out what 
happens in 2.


/Erik

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

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 
> wrote:


    On 2018-03-28 22:39, Martin Buchholz wrote:



    On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
    mailto: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.

Re: 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 
> wrote:


    On 2018-03-28 22:39, Martin Buchholz wrote:



    On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie
    mailto: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.

Re: 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 
mailto: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
mailto: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.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Alan Bateman]

On 28/03/2018 22:48, Magnus Ihse Bursie wrote:



2) The exported symbols from executables are a public API and the 
change therefore require a CSR.
I don't think there are any supported/documented interfaces here. It 
would be nice if the launchers were linked without any exported symbols, 
that would avoid any misunderstanding but I don't think that is necessary.


-Alan

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Martin Buchholz]

>From https://gcc.gnu.org/wiki/Visibility

Why is the new C++ visibility support so useful?

Put simply, it hides most of the ELF symbols which would have previously
(and unnecessarily) been public. This means:

   -

   *It very substantially improves load times of your DSO (Dynamic Shared
   Object).* For example, a huge C++ template-based library which was
   tested (the TnFOX Boost.Python bindings library) now loads in eight seconds
   rather than over six minutes!
   -

   *It lets the optimiser produce better code.* PLT indirections (when a
   function call or variable access must be looked up via the Global Offset
   Table such as in PIC code) can be completely avoided, thus substantially
   avoiding pipeline stalls on modern processors and thus much faster code.
   Furthermore when most of the symbols are bound locally, they can be safely
   elided (removed) completely through the entire DSO. This gives greater
   latitude especially to the inliner which no longer needs to keep an entry
   point around "just in case".
   -

   *It reduces the size of your DSO by 5-20%.* ELF's exported symbol table
   format is quite a space hog, giving the complete mangled symbol name which
   with heavy template usage can average around 1000 bytes. C++ templates spew
   out a huge amount of symbols and a typical C++ library can easily surpass
   30,000 symbols which is around 5-6Mb! Therefore if you cut out the 60-80%
   of unnecessary symbols, your DSO can be megabytes smaller!
   -

   *Much lower chance of symbol collision.* The old woe of two libraries
   internally using the same symbol for different things is finally behind us
   with this patch. Hallelujah!

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Martin Buchholz]

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.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

On 2018-03-28 22:39, Martin Buchholz wrote:



On Wed, Mar 28, 2018 at 12:07 PM, Magnus Ihse Bursie 
mailto: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.


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.


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.


/Magnus

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Martin Buchholz]

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.

Exporting all symbols from a binary makes the product slightly less
annoying to maintain while making the end product slightly worse, which is
not usually what Java is about.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Erik Joelsson]

Looks good from a build perspective.

/Erik


On 2018-03-28 04:08, Magnus Ihse Bursie wrote:
This patch removes mapfiles for the JDK executables (launchers). 
There's really no reason to have mapfiles in the first place for 
executables. Since no-one is linking to them, what symbols they export 
is immaterial.


Bug: https://bugs.openjdk.java.net/browse/JDK-8200358
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.01


/Magnus

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

On 2018-03-28 14:19, Martin Buchholz wrote:

I'm not sure about this.

IIRC the AIX linker is able to use executables as a build-time input.  
Maybe our AIX maintainers have some expertise here.

As you heard from Thomas, this does not seem to be a problem.


I think the _dynamic_ linker will see symbols in the executable.  
Resolving them is likely to be strictly more work at startup, and it 
is likely that the symbols are visible to dlsym(NULL ...)


We have local patches at Google that involve adding symbols to these 
mapfiles to increase visibility to dlsym. Maintaining mapfiles is no 
fun, but the precise definition of symbol visibility seems in the 
Spirit of Java.


Maintaining map files is no fun. Yes indeed. I don't think the current 
presense of mapfiles is intended to be the "Spirit of Java", but rather 
"everything in the build sucked back when Java was created" (or perhaps 
"Everthing in the build was designed from how the programmers thought 
that you should do things on Solaris" -- which may or may not mean the 
same thing as the previous sentense ;-)).


Are you loading symbols from *executables* at Google? You sure about that?

Anyway, with this patch all symbols in executables will be visible, so 
there should be no problem anyway.


/Magnus



On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:


This patch removes mapfiles for the JDK executables (launchers).
There's really no reason to have mapfiles in the first place for
executables. Since no-one is linking to them, what symbols they
export is immaterial.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200358

WebRev:

http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.01



/Magnus

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Thomas Stüfe]

On Wed, Mar 28, 2018 at 2:19 PM, Martin Buchholz 
wrote:

> I'm not sure about this.
>
> IIRC the AIX linker is able to use executables as a build-time input.
> Maybe our AIX maintainers have some expertise here.
>
>
I am quite sure we do not do that in the VM. I'm running a test build with
your patch.

Thanks, Thomas


> I think the _dynamic_ linker will see symbols in the executable.  Resolving
> them is likely to be strictly more work at startup, and it is likely that
> the symbols are visible to dlsym(NULL ...)
>
> We have local patches at Google that involve adding symbols to these
> mapfiles to increase visibility to dlsym.  Maintaining mapfiles is no fun,
> but the precise definition of symbol visibility seems in the Spirit of
> Java.
>
> On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
> > This patch removes mapfiles for the JDK executables (launchers). There's
> > really no reason to have mapfiles in the first place for executables.
> Since
> > no-one is linking to them, what symbols they export is immaterial.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8200358
> > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher
> > -mapfiles/webrev.01
> >
> > /Magnus
> >
> >
>

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

[Martin Buchholz]

I'm not sure about this.

IIRC the AIX linker is able to use executables as a build-time input.
Maybe our AIX maintainers have some expertise here.

I think the _dynamic_ linker will see symbols in the executable.  Resolving
them is likely to be strictly more work at startup, and it is likely that
the symbols are visible to dlsym(NULL ...)

We have local patches at Google that involve adding symbols to these
mapfiles to increase visibility to dlsym.  Maintaining mapfiles is no fun,
but the precise definition of symbol visibility seems in the Spirit of Java.

On Wed, Mar 28, 2018 at 4:08 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> This patch removes mapfiles for the JDK executables (launchers). There's
> really no reason to have mapfiles in the first place for executables. Since
> no-one is linking to them, what symbols they export is immaterial.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200358
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher
> -mapfiles/webrev.01
>
> /Magnus
>
>