RFR: JDK-8200358 Remove mapfiles for JDK executables (original) (raw)
Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Mar 28 21:48:49 UTC 2018
- Previous message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Next message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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):
Removing the mapfiles will affect performance negatively
The exported symbols from executables are a public API and the change therefore require a CSR.
To this I reply:
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.
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
- Previous message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Next message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]