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.bur...@oracle.com <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
<magnus.ihse.bur...@oracle.com
<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.
